JP2024102080A - 再帰的データトラバースモデル - Google Patents

Abstract

【課題】オブジェクトのデータキャッシュを行う方法を提供する。【解決手段】構成グラフを翻訳して要求を効率的かつ最適に構築し、データストアからデータをフェッチする。要求されたデータタイプのオブジェクトの値を用いて、データストアからデータをプリフェッチするための追加の問合せを生成する。具体的には、当該値は、別の関係するデータタイプのオブジェクトの対応するサブセットに関して問合せして取得するために用いられる。既に取得されたオブジェクトに基づいて関係するデータタイプのオブジェクトについて再帰的に問合せして取得することにより、関連するオブジェクトのデータキャッシュを構築する。キャッシュされた関連するオブジェクトは、最初の問合せの後になされる可能性のある後続の問合せにおいて有用であり得る。【選択図】図４

Description

技術分野
本開示は、再帰的データトラバースモデル（recursive data traversal model）に関する。特に、本開示は、データ取得関係を実現する再帰的データトラバースモデルに関する。

背景
クライアントデバイスは、バックエンドサーバから更新を受信し得るかまたはバックエンドサーバに更新を提出し得る。クライアントデバイスが受信または提出した更新はデータの更新を含む。

クライアントデバイスは、オンラインモードおよびオフラインモードで動作させてもよい。オンラインモードは、クライアントデバイスがネットワークを介してバックエンドサーバと通信し得るモードである。オフラインモードは、クライアントデバイスがネットワークを介してバックエンドサーバと通信することができないモードである。オンラインモードでの動作時、クライアントデバイスは、バックエンドサーバから更新を受信し得るとともに、バックエンドサーバに更新を提出し得る。オフラインモードでの動作時、クライアントデバイスは、バックエンドサーバから更新を受信すること、またはバックエンドサーバに更新を提出することができない。

本項に記載されるアプローチは、追求され得たアプローチであるが、必ずしもこれまでに想到または追求されたアプローチであるとは限らない。したがって、別段の指示がない限り、本項に記載されるアプローチのいずれも、単に本項に含まれるというだけで、先行技術として適格であると想定されるべきではない。

実施形態は、例として示されているものであって、添付の図面の図において限定することを目的としたものではない。本開示において「ある」または「１つの」実施形態と言及する場合は、それは必ずしも同じ実施形態を言及するものではなく、少なくとも１つを意味するものであることに留意されたい。

１つ以上の実施形態に従った、ネットワーク上で動作するクライアント・サーバコンピューティングシステムを示すブロック図である。 １つ以上の実施形態に従ったデータ制御モデルのコンポーネントを示すブロック図である。 １つ以上の実施形態に従った、オブジェクトタイプ定義を更新するための動作のセット例を示すブロック図である。 １つ以上の実施形態に従った、オブジェクトタイプ定義を更新するための動作のセット例を示すブロック図である。 １つ以上の実施形態に従った、エンティティと、関係するエンティティとの間の関係を示す構成グラフを示すブロック図である。 １つ以上の実施形態に従った、構成グラフにおけるエンティティのコンポーネントを示すブロック図である。 １つ以上の実施形態に従った、構成グラフにおける関係するエンティティのコンポーネントを示すブロック図である。 １つ以上の実施形態に従った、データキャッシュを更新するための動作のセット例を示すブロック図である。 １つ以上の実施形態に従ったコンピュータシステムを示すブロック図である。

詳細な説明
以下の記載では、説明を目的として、完全な理解をもたらすために多数の具体的な詳細が記載される。これらの具体的な詳細なしでも１つ以上の実施形態が実施され得る。一実施形態において説明される特徴は、別の実施形態において説明される特徴と組合わされてもよい。いくつかの例では、本発明を不必要に曖昧にすることを避けるために、周知の構造および装置をブロック図の形態を参照しつつ説明する。

１．全体概要
１つ以上の実施形態は、構成グラフを翻訳して、要求を効率的かつ最適に構築し、データストアからデータをフェッチする。要求されたデータタイプのオブジェクトの値は、データストアからデータをプリフェッチするための追加の問合せを生成するために用いられる。具体的には、これらの値は、別の関係するデータタイプのオブジェクトの対応するサブセットに関して問合わせして当該サブセットを取得するために用いられる。既に取得されたオブジェクトに基づいて関係するデータタイプのオブジェクトに関して再帰的に問合わせして当該オブジェクトを取得することにより、関連するオブジェクトのデータキャッシュを構築する。キャッシュされた関連するオブジェクトは、最初の問合せの後になされる可能性のある後続の問合せにおいて有用であり得る。

この全体概要の項において記載される実施形態以外のいくつかの実施形態が本明細書に含まれ得るとともに、添付の特許請求の範囲において記載され得る。

２．アーキテクチャの概要
図１は、１つ以上の実施形態に従った、ネットワーク１２０上で動作するクライアント・サーバコンピューティングシステム１００を例示するブロック図を示す。クライアント・サーバコンピューティングシステム１００は、ネットワーク１２０を介して通信可能に結合されたサーバ１１０およびクライアントデバイス１３０を含み得る。サーバ１１０およびクライアントデバイス１３０の各々は、コンピューティングプロセッサならびに関連付けられたメモリおよび通信回路類を含み得る。

ネットワーク１２０は、ローカルエリアネットワーク（local area network：ＬＡＮ）、ワイドエリアネットワーク（wide area network：ＷＡＮ）、イーサネット（登録商標
）ネットワーク、トークンリングネットワーク、非同期転送モード（asynchronous transfer mode：ＡＴＭ）ネットワーク、Ｗｉ－Ｆｉネットワーク、インターネット、携帯電話ネットワーク、ＧＳＭ（登録商標）エボリューションのための拡張データレート（Enhanced Data rates for GSM Evolution：ＥＤＧＥ）ネットワーク、ロングタームエボリュー
ション（long-term evolution：ＬＴＥ）ネットワーク、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）ネットワーク、または他のコンピューティング通信ネットワークを含み得る。サーバ１１０は、ネットワーク１２０を介してクライアントデバイス１３０によってアクセス可能なデータを格納するデータストア１１５を含み得る。クライアントデバイス１３０は、データストア１１５からデータを受信するかまたはデータストア１１５に格納されたデータにアクセスするクライアントアプリケーション１３５（たとえば、ソフトウェアアプリケーション）を含み得る。

ある実施形態では、クライアントデバイス１３０は、１つ以上のデジタルデバイス上に実装される。「デジタルデバイス」という語は、一般に、プロセッサを含む任意のハードウェアデバイスを指す。デジタルデバイスは、アプリケーションを実行する物理デバイスまたは仮想マシンを指すこともある。デジタルデバイスの例として、コンピュータ、タブレット、ラップトップ、デスクトップ、ネットブック、サーバ、ウェブサーバ、ネットワークポリシーサーバ、プロキシサーバ、汎用マシン、特定機能のハードウェアデバイス、ハードウェアルータ、ハードウェアスイッチ、ハードウェアファイアウォール、ハードウェアネットワークアドレストランスレータ（network address translator：ＮＡＴ）、ハードウェアロードバランサ、メインフレーム、テレビ、コンテンツ受信機、セットトップボックス、プリンタ、モバイルハンドセット、スマートフォン、携帯情報端末（personal
digital assistant：ＰＤＡ）、無線受信機および／または送信機、基地局、通信管理装置、ルータ、スイッチ、コントローラ、アクセスポイント、およびクライアントデバイスを含む。

１つ以上の実施形態では、データストア１１５は、データを格納するための任意のタイプの格納ユニットおよび／またはデバイス（たとえば、ファイルシステム、データベース、テーブルの集合、または他の任意の格納メカニズム）である。さらに、データストア１１５は、複数のさまざまな格納ユニットおよび／またはデバイスを含み得る。複数のさまざまな格納ユニットおよび／またはデバイスは、同じタイプであってもなくてもよく、または、同じ物理サイトに配置されてもされなくてもよい。代替的には、または付加的には、データストア１１５は、サーバ１１０とは別個のコンピューティングシステム上で実装または実行され得る。データストア１１５は、直接接続によって、またはネットワーク１２０を介して、サーバ１１０またはクライアントデバイス１３０に通信可能に結合され得る。

クライアントアプリケーション１３５は、ハイパーテキスト転送プロトコル（hypertext transfer protocol：ＨＴＴＰ）ユニフォームリソース識別子（uniform resource identifier：ＵＲＩ）のセット、たとえば、ＨＴＴＰ要求とともに用いられるユニフォームリソースロケータ（uniform resource locator：ＵＲＬ）を用いて、データストア１１５に格納されたデータオブジェクトにアクセスし得る。ＨＴＴＰは、クライアントアプリケーション１３５とデータストア１１５との間のデータの転送および管理を容易にするために、クライアントデバイス１３０とサーバ１１０との間の要求・応答プロトコルとして用いられてもよい。

サーバ１１０は、クライアントアプリケーション１３５から受信したＲＥＳＴ要求を提供するためのレプリゼンテーショナルステートトランスファ（representational state transfer：ＲＥＳＴ）サービスを提供し得る。ＲＥＳＴ要求は、ステートレスなＨＴＴＰ
要求の一種であり、クライアントデバイス１３０によってサーバ１１０に送信されてもよい。ＲＥＳＴ要求はＨＴＴＰ要求のサブセットである。ＲＥＳＴ要求は、予め定義された一様なステートレス動作のセットを用いてもよい。ＲＥＳＴ要求が用いられるとき、状態は要求ごとに維持されなくてもよい。サーバ１１０は、サーバ１１０の記述をＲＥＳＴサーバとして、明確に定義されたＵＲＬを通じてクライアントアプリケーション１３５に提供し得る。サーバ１１０は、この明確に定義されたＵＲＬを通じて、クライアントアプリケーション１３５が効率的にデータストア１１５からデータを取得するとともにデータストア１１５にデータをアップロードするためのメカニズムを提供し得る。

１つ以上の実施形態では、ユーザインターフェイスは、ユーザとクライアントデバイス１３０との間の通信を容易にするように構成されたハードウェアおよび／またはソフトウェアを指す。ユーザインターフェイスは、ユーザインターフェイス要素をレンダリングし、ユーザインターフェイス要素を介して入力を受信する。インターフェイスの例は、グラ
フィカルユーザインターフェイス（graphical user interface：ＧＵＩ）、コマンドラインインターフェイス（command line interface：ＣＬＩ）、触覚型インターフェイス、および音声コマンドインターフェイスを含む。ユーザインターフェイス要素の例として、チェックボックス、ラジオボタン、ドロップダウンリスト、リストボックス、ボタン、トグル、テキストフィールド、日付および時間セレクタ、コマンドライン、スライダ、ページ、およびフォームを含む。

ある実施形態では、ユーザインターフェイスのさまざまなコンポーネントはさまざまな言語で指定される。ユーザインターフェイス要素の挙動は、JavaScript（登録商標）などの動的なプログラミング言語で指定される。ユーザインターフェイス要素の内容は、ハイパーテキストマークアップ言語（hypertext markup language：ＨＴＭＬ）またはＸＭＬ
ユーザインターフェイス言語（XML User Interface Language：ＸＵＬ）などのマークア
ップ言語で指定される。ユーザインターフェイス要素のレイアウトは、カスケード・スタイルシート（Cascading Style Sheets：ＣＳＳ）などのスタイルシート言語で指定されている。代替的には、ユーザインターフェイスは、Java（登録商標）、ＣまたはＣ＋＋などの１つ以上の他の言語で指定される。

１つ以上の実施形態では、クライアント・サーバコンピューティングシステム１００は、図１に示されるコンポーネントよりも多くのコンポーネントまたは少ないコンポーネントを含んでいてもよい。図１に示すコンポーネントは、互いに対してローカルまたはリモートであってもよい。図１に示されるコンポーネントは、ソフトウェアおよび／またはハードウェアに実装され得る。各コンポーネントは、複数のアプリケーションおよび／またはマシンにわたって分散され得る。複数のコンポーネントを１つのアプリケーションおよび／またはマシンに組合わせてもよい。１つのコンポーネントに関して説明される動作が、代わりに別のコンポーネントによって実行されてもよい。

コンピュータネットワークに関係するさらなる実施形態および／または例を、以下の「コンピュータネットワークおよびクラウドネットワーク」と題される項目５に記載する。

３．適応型多形データモデル
図２は、１つ以上の実施形態に従ったデータ制御モデル２００のコンポーネントを例示するブロック図を示す。データ制御モデル２００は、適応型多形データモデルの一実施形態であり得る。データ制御モデル２００は、クライアントアプリケーション１３５が用いるデータベーススキーマを記述し得る。サーバ１１０は、データ制御モデル２００の要素をデータストア１１５からクライアントアプリケーション１３５に提供し得る。クライアントアプリケーション１３５の機能性および／または特徴は、データ制御モデル２００の機能として制御され得る。このため、クライアントアプリケーション１３５は、データ制御モデル２００のさまざまな要素を備える場合、さまざまな機能性を提供し得る。データ制御モデル２００の更新を用いることで、クライアントアプリケーション１３５の実行可能コードを更新することなく、クライアントアプリケーション１３５の機能性を更新し得る。したがって、データ制御モデル２００の新しい要素をサーバ１１０から既存のクライアントアプリケーション１３５に送信することにより、既存のクライアントアプリケーション１３５に新しい機能性が追加され得る。

一例では、単一のクライアントアプリケーション１３５を、ネットワーク上の中央アプリケーションダウンロードポータルを介してソフトウェアプロバイダの任意の顧客のために利用可能にしてもよい。ソフトウェアプロバイダの各顧客は、顧客のそれぞれのクライアントアプリケーション１３５について、他の顧客とは異なる機能性を所望する可能性もある。ソフトウェアプロバイダは、異なる実行可能クライアントアプリケーション１３５をそれぞれ異なる顧客に提供するのではなく、すべての顧客に同じ実行可能クライアント
アプリケーション１３５を提供し得る。ソフトウェアプロバイダはまた、各顧客のそれぞれのサーバ１１０から各顧客のそれぞれのクライアントアプリケーション１３５にダウンロードされるように、顧客ごとに異なるデータ制御モデル２００を提供してもよい。

たとえば、Ａ社は、Ａ社によってＡ社の従業員に発行されるクライアントデバイス１３０のセットを介してＡ社の従業員のみがアクセスできるサーバ１１０の専用インスタンスを有していてもよい。Ａ社の従業員が用いるすべてのクライアントデバイス１３０は、公に利用可能なアプリケーションポータルからクライアントアプリケーション１３５をダウンロードし得る。加えて、Ｂ社は、Ｂ社の従業員のみがアクセスできるサーバ１１０の専用インスタンスを有していてもよい。Ｂ社の従業員は、Ｂ社によってＢ社の従業員に発行されるクライアントデバイス１３０のセットを介してサーバ１１０にアクセスし得る。Ｂ社の従業員が用いるすべてのクライアントデバイス１３０は、Ａ社の従業員と同じ公に利用可能なアプリケーションポータルからクライアントアプリケーション１３５をダウンロードし得る。サーバ１１０のＡ社のインスタンスは、Ａ社のためにカスタマイズされたデータ制御モデル２００をＡ社のクライアントデバイス１３０上のクライアントアプリケーション１３５にダウンロードし得る。サーバ１１０のＢ社のインスタンスは、Ｂ社のためにカスタマイズされたデータ制御モデル２００を、Ｂ社のクライアントデバイス１３０上のクライアントアプリケーション１３５にダウンロードし得る。結果として、公に利用可能なアプリケーションポータルからダウンロードされた実行可能なクライアントアプリケーション１３５が、Ａ社のすべてのクライアントデバイス１３０およびＢ社のすべてのクライアントデバイス１３０に対して同じであったとしても、Ａ社の社員用のクライアントアプリケーション１３５は、Ｂ社の社員用のクライアントアプリケーション１３５とは異なる機能性を提供し得る。

データ制御モデル２００は、１つ以上のオブジェクトタイプ定義２３０を含み得る。各オブジェクトタイプ定義２３０はオブジェクトタイプを定義し得る。オブジェクトタイプ定義２３０は、オブジェクトタイプの属性を指定し得る。属性の例は、販売注文、配達日、数量、収益等を含み得る。オブジェクトタイプ定義２３０はまた、属性のデータフォーマット、たとえば、テキストストリング、テキストストリングの長さ、文字、整数、符号付き整数、符号なし整数、浮動小数点、倍精度浮動小数点、文字または整数配列、配列次元なども指定し得る。オブジェクトタイプ定義２３０はまた、オブジェクトタイプの属性ごとにデフォルト値を指定し得る。オブジェクトタイプ定義２３０はまた、定義されたオブジェクトタイプの各ビューに含めるのにどのフィールドが必須であるかと、定義されたオブジェクトタイプの全標準ビューに含めるのにどのフィールドが必須であるかとを指定し得る。たとえば、配達日は、販売注文データオブジェクトタイプの必須フィールドであり得る。オブジェクトタイプ定義２３０はまた、どのフィールドがクライアントアプリケーション１３５によって変更され得るかと、どのフィールドが変更されなくてもよいかとを指定し得る。たとえば、収益は、クライアントアプリケーション１３５が変更できない販売注文データオブジェクトタイプについてのフィールドであってもよい。オブジェクトタイプ定義２３０はまた、オブジェクトタイプに関して、クライアントアプリケーション１３５がサーバ１１０と通信するために使用するべき機能を指定し得る。このような機能の例は、フェッチ、更新、削除などを含み得る。オブジェクトタイプ定義２３０において指定される機能は、それぞれのオブジェクトタイプ定義２３０によって定義されたオブジェクトに関してサーバ１１０と通信するためのＵＲＬを構築するためにクライアントアプリケーション１３５によって用いられるべき情報を含む。このような通信は、オブジェクトのデータフィールドの値をデータストア１１５に送信すること、および、データストア１１５においてオブジェクトのデータフィールドの値を更新することを含み得る。データストア１１５におけるオブジェクトのデータフィールドの値を更新するためのＵＲＬが指定され得る。

データ制御モデル２００はまた、１つ以上のメタデータモジュール２３５を含み得る。メタデータモジュール２３５は、データファイルまたはデータオブジェクトとして具現化され得る。各メタデータモジュール２３５は、それぞれのオブジェクトタイプ定義２３０によって定義されるオブジェクトタイプのフィールドを識別し得る。たとえば、多数の異なるメタデータモジュール２３５は、それぞれのオブジェクトタイプ定義２３０によって定義される同じオブジェクトタイプのうち別のフィールドセットを識別し得る。同じオブジェクトに対応する別のメタデータモジュール２３５の各々は、異なるビューまたは形状のオブジェクトタイプを定義し得る。サーバ１１０は、オブジェクトタイプの完全な標準表現または全標準表現をデータストア１１５に格納し得る。クライアントアプリケーション１３５は、メタデータモジュール２３５に従って連係して機能するために、データストア１１５に格納されたオブジェクトタイプのフィールドの全セットのさまざまなサブセットをダウンロードし得る。データストア１１５から部分オブジェクトをダウンロードすることにより、ネットワーク１２０上での通信帯域幅の節約と、クライアントデバイス１３０におけるメモリ使用の節約とをもたらし得る。オブジェクトタイプのうちどの部分を動作させるべきであるかに関わらず、オブジェクトタイプを動作させるたびにオブジェクトタイプの全標準表現をダウンロードするという代替例は非効率であるかもしれない。

一例として、クライアントアプリケーション１３５は、データストア１１５からデータオブジェクトのリストをダウンロードするために、データオブジェクトタイプのフィールドの小さなサブセットを表わすメタデータモジュール２３５を用いてもよい。クライアントアプリケーション１３５は、クライアントデバイス１３０からサーバ１１０に送られたＨＴＴＰ要求を用いて、クライアントアプリケーション１３５によって指定されたサーチパラメータに一致する所与のフィールドについてのフィールド値を有するデータストア１１５内のデータオブジェクトのリストにアクセスし得る。クライアントアプリケーション１３５は、データオブジェクトの完全な標準表現または全標準表現ではなく、データオブジェクトのうちフィールドの所望のサブセットがダウンロードされるように、メタデータモジュール２３５で定義されたオブジェクトサブタイプを指定し得る。したがって、メタデータモジュール２３５において定義されるサブタイプは、クライアントアプリケーション１３５が、データストア１１５から全標準オブジェクトではなく部分オブジェクトをダウンロードすることを容易にする。

たとえば、データオブジェクトタイプは販売注文であってもよい。クライアントアプリケーション１３５は、指定された顧客、または指定された販売者、または指定された期間などの販売注文のリストをダウンロードし得る。クライアントアプリケーション１３５は、販売注文のリストをユーザインターフェイスに提示し得る。ユーザは、販売注文に関するより多くのデータを確認するために、または販売注文に対する操作を実行するために、販売注文の提示リストのうち１つ以上を選択し得る。クライアントアプリケーション１３５は、ユーザ選択に応答して、販売注文データオブジェクトタイプのフィールドのうちより大きいサブセットを表わす別のメタデータモジュール２３５を用いて、販売注文の提示リストのうち選択された１つ以上のリストに関する追加の詳細をダウンロードし得る。それぞれのオブジェクトタイプ定義２３０において定義される販売注文データオブジェクトタイプは、いくつかの異なる関連付けられたメタデータモジュール２３５を有し得る。メタデータモジュール２３５の各々は、販売注文データオブジェクトタイプについての異なるレベルの詳細を表わし得る。詳細のレベルの範囲は、最小リストビューから、販売注文データオブジェクトタイプのデータフィールドすべてを含む全標準ビューにまでわたり得る。

オブジェクトタイプ定義２３０において定義されるオブジェクトのさまざまなビューを指定することに加えて、メタデータモジュール２３５は、オブジェクトがどのように挙動するか、互いに対話するか、クライアントアプリケーション１３５のユーザインターフェ
イスと対話するか、および、サーバ１１０と対話するかを指定することもできる。メタデータモジュール２３５は、あるオブジェクトのレイアウトとあるオブジェクトの各フィールドに関連付けられた複数のオフセットとを指定し得る。

データ制御モデル２００は、１つ以上の多形エンティティ２０５を含み得る。多形エンティティ２０５は各々、データ制御モデル２００に関する別の全体的な機能性を定義してもよい。クライアントアプリケーション１３５は、１つの多形エンティティ２０５に従って動作するとき、当該クライアントアプリケーション１３５が別の多形エンティティ２０５に従って動作するときとは異なる特徴または機能性を提供し得る。

各々の多形エンティティ２０５は、１つ以上の持続エンティティ２１０を含み得る。多形エンティティ２０５のうち１つのインスタンスの持続エンティティ２１０は、多形エンティティ２０５のうち別のインスタンスの持続エンティティ２１０とは異なり得る。持続エンティティ２１０の各インスタンスは、対応するオブジェクトタイプ定義２３０において定義されるようなデータオブジェクトのインスタンスを表わし得る。

持続エンティティ２１０は、データオブジェクトの抽象表現であり得る。持続エンティティ２１０は、特定の多形エンティティ２０５内で持続エンティティ２１０の各インスタンスを一意に識別する一意識別子２１５を含み得る。持続エンティティ２１０はまた、持続エンティティ２１０によって表わされるオブジェクトタイプを定義するオブジェクトタイプ定義２２０を含み得る。オブジェクトタイプ定義２２０は、対応するオブジェクトタイプ定義２３０の一実施形態であり得る。持続エンティティ２１０はまた、複数のデータ値２２５を含み得る。複数のデータ値２２５の各々は、オブジェクトタイプ定義２２０において定義されるデータフィールド名に関連付けられてもよい。

持続エンティティ２１０は、オブジェクトタイプ定義２２０によって定義される機能を含み得る。当該機能は、データ値２２５に対して動作するとともに、オブジェクトタイプ定義２２０によって定義されるようなデータオブジェクトタイプを参照してデータストア１１５と対話するものである。持続エンティティ２１０を実装するクライアントアプリケーション１３５に含まれる実行可能コードは、オブジェクトタイプ定義２２０によって表わされるデータオブジェクトに関する情報を内蔵していない可能性もある。クライアントアプリケーション１３５に含まれる実行可能コードは、オブジェクトタイプ定義２２０に含まれるデータに従った機能性を提供し得る。ある実施形態では、持続エンティティ２１０は、クライアントアプリケーション１３５内のJava（登録商標）コードによって実装されてもよく、オブジェクトタイプ定義２２０は、データストア１１５によって提供されるJavaScript（登録商標）Object Notation（ＪＳＯＮ）表現に従って指定されてもよい。
さまざまな実施形態では、他のプログラミング言語およびデータベースフォーマットを用いて、クライアントアプリケーション１３５において持続エンティティ２１０を実装し得る。持続エンティティ２１０のためのJava（登録商標）コードは、設計時にクライアントアプリケーション１３５が設けられてもよく、オブジェクトタイプ定義２２０のＪＳＯＮ表現は、実行時にデータストア１１５を介して提供されてもよい。

たとえば、持続エンティティ２１０のインスタンスは、販売注文データタイプに対する動作のための方法を含むクラスに従って定義される販売注文データタイプのインスタンスであるオブジェクトであってもよい。当該クラスは、オブジェクトタイプ定義２３０によって定義され得る。クラス定義に従うと、持続エンティティ２１０は、販売注文データオブジェクトをフェッチすること、販売注文データオブジェクトを更新すること等を含め、データストア１１５に格納された販売注文データオブジェクトとともに作用するように、適宜、ＨＴＴＰ要求を構築することができてもよい。データストア１１５に格納されたデータオブジェクトに対して作用する持続エンティティ２１０によって提供される機能は、
一般に、データストア１１５に格納された任意のタイプのデータオブジェクトに対して作用するように定義され得る。持続エンティティ２１０によって提供される機能は、持続エンティティ２１０がオブジェクトタイプ定義２２０に従って定義されるクラスにおいて提供される方法によって呼出されてもよい。クライアントアプリケーション１３５の実行可能コードは、たとえば、「収益（Revenue）」オブジェクトに対してのみ作用するように
定義されるGetRevenue(<object identifier>)という名前のハードコード化関数ではなく
、Get()という名前のハードコード化関数を含み得る。このGet()という名前のハードコード化関数は、Get(Revenue,<object identifier>)として「収益」という名前のフィールド上の販売注文データタイプ持続エンティティ２１０に対応するクラスの方法によって呼び出され得る。この場合、<object identifier>は、対応する持続エンティティ２１０の一
意識別子２１５である。

一例では、クライアントアプリケーション１３５がデータストア１１５から販売注文データオブジェクトのリストをフェッチする場合、戻される販売注文オブジェクトは各々、持続エンティティ２１０のうち別々に定義されたインスタンスによって表わされてもよい。リストに戻された販売注文データオブジェクトは、販売注文データオブジェクトタイプのリストに対応するメタデータモジュール２３５に従って、データストア１１５に格納された全標準販売注文データタイプのサブタイプとして表わされてもよい。ユーザは、リスト内の販売注文データオブジェクトのうちの１つを選択して、関連付けられた「収益」フィールド値を要求し得る。「収益」フィールドは、リストに対応するメタデータモジュール２３５に応じて販売注文データタイプのサブタイプに含まれなくてもよい。Get(Revenue,<identifier>)関数は、選択された販売注文データオブジェクトに対応する持続エンテ
ィティ２１０によって実行されてもよい。Ｇｅｔ関数は、持続エンティティのオブジェクトタイプ定義２２０内の「収益」フィールドをルックアップして、「収益」フィールドがどのような種類のデータを含むかを判定し、データ値２２５内のフィールドに関する値をルックアップし得る。当該値がデータ値２２５に含まれていない場合、Ｇｅｔ関数は、販売注文データオブジェクトタイプについてのフィールド「収益」を含むメタデータモジュール２３５に従ってデータストア１１５にＨＴＴＰ要求を発行し得る。「収益」データフィールドと、Ｇｅｔ関数によって用いられるメタデータモジュール２３５によって定義される任意の他のデータフィールドとを受信した後、Ｇｅｔ関数は、オブジェクトタイプ定義２２０によって指定されるとおり、Ｇｅｔ関数に対応する方法のクラス定義に従って「収益」データ値に対する処理を実行してもよい。次いで、持続エンティティ２１０は、Ｇｅｔ関数によって戻された「収益」データ値を、クライアントアプリケーション１３５のユーザインターフェイスを介してユーザに提示し得る。

ソフトウェアプロバイダの各顧客は、顧客のそれぞれのクライアントアプリケーション１３５のために他の顧客とは異なる機能性を所望する可能性がある。ソフトウェアプロバイダは、さまざまな実行可能クライアントアプリケーション１３５をそれぞれ異なる顧客に提供するのではなく、すべての顧客に同じ実行可能クライアントアプリケーション１３５を提供し得る。ソフトウェアプロバイダはまた、各顧客のそれぞれのサーバ１１０から各顧客のそれぞれのクライアントアプリケーション１３５にダウンロードされるように異なるデータ制御モデル２００を各顧客に提供してもよい。

ある実施形態では、クライアントアプリケーション１３５を特定の顧客に提供するソフトウェアプロバイダの特定の顧客は、特定の顧客によって用いられるかまたは特定の顧客の制御下で用いられるクライアントアプリケーション１３５の機能性を更新することを所望することもある。更新された機能性は、（たとえば、新しい域内の倉庫データオブジェクトについての）新しいデータオブジェクトタイプ定義２３０、新しいメタデータモジュール２３５、既存のデータオブジェクトタイプ定義２３０およびメタデータモジュール２３５のいずれかまたは両方の更新などを含み得る。特定の顧客は、ソフトウェアツールを
用いて、特定の顧客のサーバ１１０においてデータ制御モデル２００を更新し得る。特定の顧客は、更新されたデータ制御モデル２００を、特定の顧客の制御下にあるさまざまなクライアントデバイス１３０上の特定の顧客のクライアントアプリケーション１３５の特定の顧客の１つ以上のインスタンスに送信してもよい。特定の顧客の制御下にあるさまざまなクライアントデバイス１３０上の特定の顧客のクライアントアプリケーション１３５の特定の顧客の更新は、ソフトウェアプロバイダによってソフトウェアプロバイダの他の顧客に提供されるクライアントアプリケーション１３５のインスタンスに影響を与える可能性はないだろう。ソフトウェアプロバイダの顧客はすべて、同じ実行可能クライアントアプリケーション１３５をインストールして用いてもよい。特定の顧客は、クライアントアプリケーション１３５の他のいずれのインスタンスにも影響を及ぼすことなく、クライアントアプリケーション１３５の特定の顧客のインスタンスによって用いられるデータ制御モデル２００を更新し得る。

ある実施形態では、販売者は、販売機会のリストを表示するためにクライアントアプリケーション１３５を用いてもよい。販売機会の各々は、クライアントアプリケーション１３５のデータ制御モデル２００内のオブジェクトタイプ「機会（Opportunities）」によ
って表わされてもよい。クライアントアプリケーション１３５は、販売者からの要求に応答して、販売者の基準を満たす「機会」オブジェクトからのデータフィールドの値のリストを表示してもよい。クライアントアプリケーション１３５は、クライアントアプリケーション１３５の構成に基づいて、顧客名および顧客電話番号のみが機会のリストビューに表示されていると判定し得る。クライアントアプリケーション１３５は、オブジェクトタイプ「機会」に対応するメタデータモジュール２３５を分析し得る。クライアントアプリケーション１３５は、オブジェクトタイプ「機会」に対応するメタデータモジュール２３５が、表示されるべきフィールド、顧客名および顧客電話番号を含むと判定し得る。クライアントアプリケーション１３５は、対応するメタデータモジュール２３５において識別されたフィールドに関する値をデータストア１１５から取得し得る。表示されるべきフィールドが対応するメタデータモジュール２３５に含まれているので、クライアントアプリケーション１３５は、データストア１１５に格納されたタイプ「機会」のオブジェクトから顧客名および顧客電話番号に関する値を取得し得る。クライアントアプリケーション１３５は、さまざまな機会ごとに取得された情報をリストビューにて表示し得る。

顧客名および顧客番号についての値を格納することに加えて、データストア１１５は、オブジェクトタイプ「機会」におけるフィールド顧客予算についての値を格納してもよい。しかしながら、顧客予算はクライアントアプリケーション１３５によって用いられる対応するメタデータモジュール２３５において識別されないので、クライアントアプリケーション１３５は顧客予算に対応する値のコピーを獲得しなくてもよい。

ある実施形態では、クライアントアプリケーション１３５は、対応するメタデータモジュール２３５に含まれていないオブジェクトのフィールドの値についてのユーザ要求を受信し得る。クライアントアプリケーション１３５は、指定されたオブジェクトタイプに関する要求されたフィールドを含む別の対応するメタデータモジュール２３５を求めてメタデータモジュール２３５をサーチし得る。次いで、クライアントアプリケーション１３５は、要求されたフィールドを含む他の対応するメタデータモジュール２３５に従ってデータストア１１５からオブジェクトをダウンロードし得る。クライアントアプリケーション１３５は、指定されたオブジェクトタイプに関する要求されたフィールドを含む他の対応するメタデータモジュール２３５に対応する、データストア１１５から獲得されたフィールドおよび値を含むように、それまでにサーバから取得されたオブジェクトについてのローカルに格納された部分コピーを修正し得る。

上述の例を続けて参照すると、クライアントアプリケーション１３５は、クライアント
アプリケーション１３５がリストビューに機会を表示しているときに、販売者から特定の機会の選択を受信し得る。クライアントアプリケーション１３５は、ある機会の選択を受信したことに応答して当該機会の詳細なビューを示すように構成されてもよい。クライアントアプリケーション１３５は、機会の詳細なビューが顧客名、顧客電話番号および顧客予算を含んでいると判定し得る。クライアントアプリケーション１３５は、対応するメタデータモジュール２３５の分析に基づいて、対応するメタデータモジュール２３５が顧客名および顧客電話番号のフィールドを識別すると判定し得る。クライアントアプリケーション１３５はさらに、対応するメタデータモジュール２３５がフィールド顧客予算を識別しないと判定し得る。対応するメタデータモジュール２３がフィールド顧客予算を識別しないので、対応するメタデータモジュール２３５に従ってクライアントアプリケーションによって格納される、特定の機会に対応する任意のバージョンのオブジェクトは、フィールド顧客予算についての値を含まないものと判定され得る。クライアントアプリケーション１３５は、所望のフィールド顧客予算を含むオブジェクトタイプ「機会」に対応する、データ制御モデル２００内の別のメタデータモジュール２３５を識別し得る。次いで、クライアントアプリケーション１３５は、サーバ１１０上のデータストア１１５から、フィールド顧客予算を含む別のメタデータモジュール２３５内で識別されたフィールドに対応する値を要求し得る。具体的には、クライアントアプリケーション１３５は、販売者によって選択された特定の機会に対応するタイプ「機会」のオブジェクトを要求し得る。クライアントアプリケーション１３５は、要求の送信に応答して、販売者によって選択された特定の機会に対応するタイプ「機会」のオブジェクトを受信し得る。当該オブジェクトは、ここでは、顧客名、顧客番号および顧客予算についての値を含んでもよく、これらの値はすべて、特定のオブジェクトのビューを定義するために現在選択されているクライアントアプリケーション１３５によって維持される上記別のメタデータモジュール２３５において識別される。代替的には、データストア１１５から受信されたオブジェクトは、顧客名および顧客番号についての値がクライアントアプリケーション１３５によって最後に受信されてから変更されていなければ、当該値を含まなくてもよい。クライアントアプリケーション１３５は、特定の機会に対応する、格納済みのいずれかの以前のバージョンのオブジェクトを置換え得るかまたは上書きし得る。クライアントアプリケーション１３５は、顧客名、顧客電話番号および顧客予算を含むとともに特定の機会に対応する新しいバージョンのオブジェクトを格納し得る。クライアントアプリケーション１３５は、販売者によって選択された特定の機会の詳細なビューを表示してもよい。クライアントアプリケーション１３５によって表示される詳細なビューは、顧客名、顧客番号および顧客予算を含み得る。

ある実施形態では、サーバ１１０上のアプリケーションは、データストア１１５に格納されたタイプ「機会」のオブジェクトに関するタイプ「コミッション（Commission）」の新しい整数フィールドを作成するようにとの要求を受信し得る。フィールドタイプ「コミッション」は、このとき、クライアントアプリケーション１３５によって維持されるかまたはサーバ１１０によって維持される任意のオブジェクトタイプ定義２３０またはメタデータモジュール２３５においてフィールドとして識別されない可能性がある。サーバ１１０は、オブジェクトタイプ「機会」に対応するオブジェクトタイプ定義２３０と、クライアントアプリケーション１３５によって維持される１つ以上の対応するメタデータモジュール２３５とを更新し得る。具体的には、オブジェクトタイプ「機会」および１つ以上の対応するメタデータモジュール２３５の更新は、タイプ「コミッション」の新しい整数フィールドを含む。データストア１１５およびクライアントアプリケーション１３５は、タイプ「コミッション」の新しいフィールドの追加を反映するために、タイプ「コミッション」のフィールドについての値を格納し得る。クライアントアプリケーション１３５はまた、ユーザインターフェイス上でフィールド「コミッション」に対応する値を取得して表示してもよい。

ある実施形態では、サーバ１１０は、データストア１１５および／またはクライアントアプリケーション１３５に格納された任意のオブジェクトのタイプとは異なる新しいタイプのオブジェクトを生成するようにとの要求を受信し得る。サーバ１１０は、新しいタイプのオブジェクトを生成するようにとの要求に応答して、（ａ）新しいオブジェクトタイプ定義２３０を生成し得るとともに、（ｂ）新しいオブジェクトタイプに対応する１つ以上の新しいメタデータモジュール２３５を生成し得る。オブジェクトタイプ定義２３０は、新しいタイプのオブジェクトに含まれるべき１つ以上のデータフィールドを含み得るとともに、１つ以上のメタデータモジュール２３５は、新しいタイプのオブジェクトに含まれるべき１つ以上のデータフィールドのさまざまなサブセットを指定し得る。サーバ１１０は、クライアントアプリケーション１３５のデータ制御モデルを更新することによって、新しいオブジェクトタイプ定義２３０および新しい１つ以上のメタデータモジュール２３５をクライアントアプリケーション１３５と同期させ得る。したがって、サーバ１１０およびクライアントアプリケーション１３５は、オブジェクトタイプ定義２３０およびメタデータモジュール２３５を用いて、新しいオブジェクトタイプを定義し得る。サーバ１１０は、サーバ１１０によって定義されるとともにクライアントアプリケーション１３５によって用いられるオブジェクトタイプの集合に新しいオブジェクトタイプを追加し得る。

上述の例を続けて参照すると、サーバ１１０は、タイプNetworkingEventの新しいオブ
ジェクトを作成するようにとの要求を受信し得る。当該要求はさらに、タイプNetworkingEventのオブジェクトのフィールドとして、３つのフィールド「日付（Date）」、「時間
（Time）」および「場所（Location）」を指定し得る。クライアントアプリケーション１３５もサーバ１１０も、タイプNetworkingEventの任意のオブジェクトを定義するオブジ
ェクトタイプ定義２３０またはメタデータモジュール２３５を含まなくてもよい。サーバ１１０は、要求を受信したことに応じて、オブジェクトタイプNetworkingEventに対応す
るオブジェクトタイプ定義２３０および１つ以上のメタデータモジュール２３５を生成し得る。オブジェクトタイプNetworkingEventに対応するオブジェクトタイプ定義２３０お
よび１つ以上のメタデータモジュール２３５は、少なくとも３つのフィールド「日付」、「時間」および「場所」を識別し得る。サーバ１１０は、オブジェクトタイプNetworkingEventの定義を提供するために、オブジェクトタイプ定義２３０および１つ以上のメタデ
ータモジュール２３５をクライアントアプリケーション１３５に送信し得る。クライアントアプリケーション１３５はまた、タイプNetworkingEventのオブジェクトを生成し、当
該オブジェクトを同期のためにサーバ１１０に送信してもよい。

４．例示的な実施形態
明確にするために詳細な例を以下に記載する。以下に記載するコンポーネントおよび／または動作は、特定の実施形態に適用可能とはなり得ない具体例として理解されるべきである。したがって、以下に記載するコンポーネントおよび／または動作は、添付の特許請求のいずれかの範囲を限定するものと解釈されるべきではない。

４．１ 多形データモデルの修正
図３は、１つ以上の実施形態に従った、オブジェクトタイプ定義を更新するための動作３００のセット例を例示するブロック図を示す。図３に示される１つ以上の動作は、すべてまとめて修正、再配置または省略されてもよい。したがって、図３に示される動作の特定のシーケンスは１つ以上の実施形態の範囲を限定するものとして解釈されるべきではない。

動作３０５において、クライアントアプリケーション１３５は、データストア１１５から第１のオブジェクトタイプ定義２３０を受信し得る。第１のオブジェクトタイプ定義２３０は、データストア１１５をホストするサーバ１１０から、クライアントアプリケーシ
ョン１３５がネットワーク１２０を介して実行するクライアントデバイス１３０によって受信され得る。第１のオブジェクトタイプ定義２３０は、クライアントアプリケーション１３５の機能性を制御するデータ制御モデル２００において用いられるべき第１のオブジェクトタイプを定義し得る。第１のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプの１つ以上のデータフィールドを定義し得る。定義されたデータフィールドは各々、データフィールド名およびデータフィールド値を含み得る。一例として、オブジェクトタイプは、「機会」、たとえば販売機会、であってもよい。オブジェクトタイプ「機会」は、多数のデータフィールド、たとえば、「顧客名（Customer Name）」フィールドお
よび「顧客電話番号（Customer Phone Number）」フィールドを含むように、第１のオブ
ジェクトタイプ定義２３０によって定義されてもよい。

動作３１０において、第１のオブジェクトタイプの第１のオブジェクトは、受信された第１のオブジェクトタイプ定義２３０に従って処理され得る。たとえば、クライアントアプリケーション１３５は、第１のオブジェクトタイプ定義２３０に従って第１のオブジェクトのインスタンスを表わすために持続エンティティ２１０を生成し得る。生成された持続エンティティ２１０は、クライアントアプリケーション１３５によって用いられるスキーマを表わす多形エンティティ２０５内の第１のオブジェクトを一意に識別する一意識別子２１５を含み得る。生成された持続エンティティ２１０はまた、生成された持続エンティティ２１０が基づいている第１のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含み得る。持続エンティティ２１０はまた、オブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上のデータフィールドを含み得る。別の例として、クライアントアプリケーション１３５のユーザインターフェイスは、第１のオブジェクトの１つ以上のデータフィールド値を表示し得る。持続エンティティ２１０はまた、持続エンティティ２１０によって表わされる第１のオブジェクトに対して作用するように、オブジェクトタイプ定義２２０によって定義されるクラスに関連付けられた１つ以上の方法を実行してもよい。

動作３１５において、クライアントアプリケーション１３５は、データストア１１５から第１のオブジェクトタイプ定義２３０の更新を受信し得る。当該更新は、第２のオブジェクトタイプ定義２３０を含み得る。第２のオブジェクトタイプ定義２３０は、クライアントアプリケーション１３５の機能性を制御するデータ制御モデル２００において用いられるべき第２のオブジェクトタイプを定義し得る。第２のオブジェクトタイプ定義２３０は、第２のオブジェクトタイプの１つ以上のデータフィールドを定義し得る。定義されたデータフィールドは各々、データフィールド名およびデータフィールド値を含み得る。一例として、オブジェクトタイプは「倉庫（Warehouse）」であってもよい。オブジェクト
タイプ「倉庫」は、多数のデータフィールド、たとえば、「倉庫住所（Warehouse Address）」フィールドおよび「倉庫電話番号（Warehouse Phone Number）」フィールドを含む
ように、第２のオブジェクトタイプ定義２３０によって定義され得る。別の例として、第２のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプ定義２３０の更新済みバージョンであってもよく、クライアントアプリケーション１３５のデータ制御モデル２００内の第１のオブジェクトタイプ定義２３０を置換えてもよい。第２のオブジェクトタイプ定義２３０は、「機会」、たとえば販売機会であってもよい。更新された第２のオブジェクトタイプ「機会」は、多数のデータフィールド、たとえば、「顧客名」フィールド、「顧客電話番号」フィールド、および「顧客予算（Customer Budget）」フィールドを
含むように、第２のオブジェクトタイプ定義２３０によって定義され得る。この例では、第２のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプ定義２３０に含まれない追加のデータフィールドおよび値を含む。

動作３２０において、第２のオブジェクトタイプの第２のオブジェクトは、受信された第２のオブジェクトタイプ定義２３０に従って処理され得る。たとえば、クライアントア
プリケーション１３５は、第２のオブジェクトタイプ定義２３０に従って第２のオブジェクトのインスタンスを表わすために持続エンティティ２１０を生成し得る。生成された持続エンティティ２１０は、クライアントアプリケーション１３５によって用いられるスキーマを表わす多形エンティティ２０５内の第２のオブジェクトを一意に識別する一意識別子２１５を含み得る。生成された持続エンティティ２１０はまた、生成された持続エンティティ２１０が基づいている第２のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含み得る。持続エンティティ２１０はまた、オブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上のデータフィールドを含み得る。別の例として、クライアントアプリケーション１３５のユーザインターフェイスは、第２のオブジェクトの１つ以上のデータフィールド値を表示し得る。持続エンティティ２１０はまた、持続エンティティ２１０によって表わされる第２のオブジェクトに対して作用するように、オブジェクトタイプ定義２２０によって定義されるクラスに関連付けられた１つ以上の方法を実行し得る。別の例として、第２のオブジェクトタイプ定義２３０が第１のオブジェクトタイプ定義２３０の更新済みバージョンであって、クライアントアプリケーション１３５のデータ制御モデル２００内で第１のオブジェクトタイプ定義２３０を置換える場合、第１のオブジェクトタイプの第１のオブジェクトを表わす持続エンティティ２１０は、第２のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含むとともにそれに応じて第２のオブジェクトタイプの第２のオブジェクトのインスタンスを表わすように更新されてもよい。持続エンティティ２１０はまた、更新されたオブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上の追加のデータフィールドを含むように更新され得る。

動作３２５において、クライアントアプリケーション１３５は、第２のオブジェクトのデータフィールド値をデータストア１１５に送信し得る。たとえば、クライアントアプリケーション１３５は、第２のオブジェクトタイプが「倉庫」である場合に「倉庫電話番号」の値を送信し得るとともに、これにより、データストア１１５内の「倉庫」オブジェクトについて格納された「倉庫電話番号」を更新し得る。別の例として、クライアントアプリケーション１３５は、データストア１１５内の「機会」オブジェクトに格納された「顧客予算」の値を更新し得る。クライアントアプリケーション１３５は、第２のオブジェクトタイプが第１のオブジェクトタイプと比べて、データフィールドの更新済みリストを有する「機会」である場合、「顧客予算」の値を送信し得る。

動作３３０において、クライアントアプリケーション１３５は、データストア１１５から１つ以上のメタデータモジュール２３５を受信し得る。メタデータモジュール２３５は、第２のオブジェクトタイプ定義２３０によって定義される第２のオブジェクトタイプのサブタイプを定義し得る。たとえば、第１のメタデータモジュール２３５は、「顧客名」フィールド、「顧客電話番号」フィールド、および「顧客予算」フィールドを含む「機会」オブジェクトタイプの全標準サブタイプを定義し得る。第２のメタデータモジュール２３５は、「顧客名」フィールドおよび「顧客電話番号」フィールドを含む「機会」オブジェクトタイプのサブセットサブタイプを定義し得る。第３のメタデータモジュール２３５は、「顧客名」フィールドのみを含む「機会」オブジェクトタイプのリストサブタイプを定義し得る。「機会」オブジェクトタイプのための方法は、リストサブタイプメタデータモジュール２３５に従って「機会」オブジェクトのリストをダウンロードして、クライアントデバイス１３０におけるデータ送信オーバーヘッドおよびデータ記憶オーバーヘッドを最小限にし得る。「顧客名」フィールドのみをクライアントアプリケーション１３５のユーザインターフェイスに提示する必要がある場合、「機会」オブジェクトの全標準表現は不要となる可能性があり、リストサブタイプがより効率的となり得る。「機会」オブジェクトタイプのための別の方法は、全標準サブタイプメタデータモジュール２３５に従って、選択された「機会」オブジェクトの全標準表現をダウンロードし得る。「機会」オブジェクトのリスト内の１つの「機会」オブジェクトが、選択された「機会」オブジェクト
のデータフィールドをすべて閲覧および／または編集するために選択される場合、「機会」オブジェクトの全標準表現が必要となる可能性があり、リストサブタイプが不十分となる可能性がある。

動作３４０において、クライアントアプリケーション１３５は、第２のオブジェクトタイプ定義２３０に従って作成される新しいオブジェクトが、たとえば、「機会」オブジェクトタイプのリストサブタイプに従って作成された第１のサブタイプであるか、または、たとえば、「機会」オブジェクトタイプの全標準サブタイプに従って作成された第２のサブタイプであるかに関する判定を行ない得る。

動作３４５において、新しいオブジェクトが動作３４０において第２のオブジェクトタイプ定義２３０の第１のサブタイプに対応すると判定された場合、クライアントアプリケーション１３５は、第１のサブタイプに対応するデータフィールドの値をデータストア１１５からフェッチし得る。たとえば、「機会」オブジェクトタイプの第１のサブタイプがリストサブタイプである場合、クライアントアプリケーション１３５は、データストア１１５から「顧客名」データフィールドの値をフェッチし得る。

動作３５０において、新しいオブジェクトが動作３４０において第２のオブジェクトタイプ定義２３０の第２のサブタイプに対応すると判定された場合、クライアントアプリケーション１３５は、第２のサブタイプに対応するデータフィールドの値をデータストア１１５からフェッチし得る。たとえば、「機会」オブジェクトタイプの第２のサブタイプが全標準サブタイプである場合、クライアントアプリケーション１３５は、データストア１１５から「顧客予算」データフィールドの値をフェッチし得る。

動作３５５において、クライアントアプリケーション１３５は、動作３４５または動作３５０のいずれかでフェッチされたデータフィールドの値を処理し得る。たとえば、クライアントアプリケーション１３５は、フェッチされたデータフィールドの値を、クライアントアプリケーション１３５のユーザインターフェイスに表示し得る。クライアントアプリケーション１３５は、フェッチされたデータフィールドの値に対して数学的計算を実行し得るとともに、当該数学的計算の結果をクライアントアプリケーション１３５のユーザインターフェイスに表示し得る。

動作３６０において、クライアントアプリケーション１３５は、動作３５５で処理されたデータフィールドの値をデータストア１１５において更新させ得る。クライアントアプリケーション１３５は、持続エンティティ２１０のオブジェクトタイプ定義２２０において表わされた第２のオブジェクトタイプ定義２３０によって定義される方法を実行し得る。当該実行される方法は、動作３５５におけるフェッチされたデータフィールドの値の処理結果に従って、動作３４５および３５０のうちの１つにおいてフェッチされたデータフィールドの値を更新するようにとのＨＴＴＰ要求をデータストア１１５に送信するステップを含み得る。

図４は、１つ以上の実施形態に従った、オブジェクトタイプ定義を更新するための動作４００のセット例を例示するブロック図を示す。図４に示される１つ以上の動作は、すべてまとめて修正、再配置、または省略されてもよい。したがって、図４に示される動作の特定のシーケンスは、１つ以上の実施形態の範囲を限定するものとして解釈されるべきではない。

動作４０５において、クライアントアプリケーション１３５は、第１のデータベーススキーマ、たとえば、クライアントアプリケーション１３５の機能性を制御するデータ制御モデル２００を、データストア１１５から受信し得る。第１のデータベーススキーマは、
クライアントアプリケーション１３５がネットワーク１２０を介して実行するクライアントデバイス１３０によって、データストア１１５をホストするサーバ１１０から受信され得る。第１のデータベーススキーマは、第１のオブジェクトタイプを定義する第１のオブジェクトタイプ定義２３０を含み得る。第１のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプの１つ以上のデータフィールドを定義し得る。定義されたデータフィールドは各々、データフィールド名およびデータフィールド値を含み得る。一例として、オブジェクトタイプは、「機会」、たとえば販売機会であってもよい。オブジェクトタイプ「機会」は、多数のデータフィールド、たとえば、「顧客名」フィールドおよび「顧客電話番号」フィールドを含むように、第１のオブジェクトタイプ定義２３０によって定義され得る。第１のデータベーススキーマはまた、第１のオブジェクトタイプ定義２３０によって定義される第１のオブジェクトタイプのビューを各々が定義する１つ以上のメタデータモジュール２３５を含み得る。１つ以上のメタデータモジュール２３５の各々は、それぞれのビューに含まれるべき第１のオブジェクトタイプの全標準表現に含まれるデータフィールドの別のサブセットを指定し得る。一例として、メタデータモジュール２３５のうちの１つによって定義される１つのビューは、全標準「機会」オブジェクトタイプによって指定されるさまざまなフィールドから含めるべき「顧客名」フィールドのみを指定し得る。上記メタデータモジュール２３５のうちの別のメタデータモジュール２３５によって定義される別のビューは、全標準「機会」オブジェクトタイプによって指定されるさまざまなフィールドから「顧客名」フィールドおよび「顧客電話番号」フィールドの両方が含められるべきであることを指定し得る。

動作４１０において、第１のオブジェクトタイプの第１のオブジェクトは、受信された第１のデータベーススキーマに従って処理され得る。たとえば、クライアントアプリケーション１３５は、第１のオブジェクトタイプ定義２３０に従って第１のオブジェクトのインスタンスを表現するために持続エンティティ２１０を生成し得る。生成された持続エンティティ２１０は、クライアントアプリケーション１３５によって用いられる第１のデータベーススキーマを表わす多形エンティティ２０５内の第１のオブジェクトを一意に識別する一意識別子２１５を含み得る。生成された持続エンティティ２１０はまた、生成された持続エンティティ２１０が基づいている第１のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含み得る。持続エンティティ２１０はまた、オブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上のデータフィールドを含み得る。別の例として、クライアントアプリケーション１３５のユーザインターフェイスは、第１のオブジェクトの１つ以上のデータフィールド値を表示し得る。持続エンティティ２１０はまた、持続エンティティ２１０によって表わされる第１のオブジェクトに対して作用するように、オブジェクトタイプ定義２２０によって定義されるクラスに関連付けられた１つ以上の方法を実行してもよい。

動作４１５において、クライアントアプリケーション１３５は、データストア１１５から第１のデータベーススキーマの更新を受信し得る。第１のデータベーススキーマの更新は、第１のデータベーススキーマとは異なる第２のデータベーススキーマを含み得る。当該更新は、第２のオブジェクトタイプ定義２３０を含み得る。第２のオブジェクトタイプ定義２３０は、クライアントアプリケーション１３５の機能性を制御するデータ制御モデル２００で用いられるべき第２のオブジェクトタイプを定義し得る。第２のオブジェクトタイプ定義２３０は、第２のオブジェクトタイプの１つ以上のデータフィールドを定義し得る。定義されたデータフィールドは各々、データフィールド名およびデータフィールド値を含み得る。一例として、オブジェクトタイプは「倉庫」であってもよい。オブジェクトタイプ「倉庫」は、多数のデータフィールド、たとえば、「倉庫住所」フィールドおよび「倉庫電話番号」フィールドを含むように、第２のオブジェクトタイプ定義２３０によって定義されてもよい。別の例として、第２のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプ定義２３０の更新済みバージョンであり得るとともに、クライアント
アプリケーション１３５のデータ制御モデル２００内の第１のオブジェクトタイプ定義２３０を置換え得る。第２のオブジェクトタイプ定義２３０は、「機会」、たとえば販売機会であってもよい。更新された第２のオブジェクトタイプ「機会」は、多数のデータフィールド、たとえば、「顧客名」フィールド、「顧客電話番号」フィールド、および「顧客予算」フィールドを含むように、第２のオブジェクトタイプ定義２３０によって定義され得る。この例では、第２のオブジェクトタイプ定義２３０は、第１のオブジェクトタイプ定義２３０に含まれない追加のデータフィールドおよび値を含む。

動作４２０において、第２のオブジェクトタイプの第２のオブジェクトは、受信された第２のデータベーススキーマに従って処理され得る。たとえば、クライアントアプリケーション１３５は、第２のオブジェクトタイプ定義２３０に従って第２のオブジェクトのインスタンスを表わすために持続エンティティ２１０を生成し得る。生成された持続エンティティ２１０は、クライアントアプリケーション１３５によって用いられるスキーマを表わす多形エンティティ２０５内の第２のオブジェクトを一意に識別する一意識別子２１５を含み得る。生成された持続エンティティ２１０はまた、生成された持続エンティティ２１０が基づいている第２のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含み得る。持続エンティティ２１０はまた、オブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上のデータフィールドを含み得る。別の例として、クライアントアプリケーション１３５のユーザインターフェイスは、第２のオブジェクトのうち１つ以上のデータフィールド値を表示し得る。持続エンティティ２１０はまた、持続エンティティ２１０によって表わされる第２のオブジェクトに対して作用するように、オブジェクトタイプ定義２２０によって定義されるクラスに関連付けられた１つ以上の方法を実行し得る。別の例として、第２のオブジェクトタイプ定義２３０が第１のオブジェクトタイプ定義２３０の更新済みバージョンであるとともに、クライアントアプリケーション１３５のデータ制御モデル２００内の第１のオブジェクトタイプ定義２３０を置換える場合、第１のオブジェクトタイプの第１のオブジェクトを表わす持続エンティティ２１０は、第２のオブジェクトタイプ定義２３０のコピーに基づくオブジェクトタイプ定義２２０を含むとともにそれに応じて第２のオブジェクトタイプの第２のオブジェクトのインスタンスを表わすように更新されてもよい。持続エンティティ２１０はまた、更新されたオブジェクトタイプ定義２２０に従って、関連付けられたデータ値２２５を有する１つ以上の追加のデータフィールドを含むように更新されてもよい。

動作４２５において、クライアントアプリケーション１３５は、第２のオブジェクトのデータフィールド値をデータストア１１５に送信し得る。たとえば、クライアントアプリケーション１３５は、第２のオブジェクトタイプが「倉庫」である場合、「倉庫電話番号」の値を送信し得るとともに、これにより、データストア１１５内の「倉庫」オブジェクトについて格納された「倉庫電話番号」を更新し得る。別の例として、クライアントアプリケーション１３５は、第２のオブジェクトタイプが第１のオブジェクトタイプと比べて、データフィールドの更新されたリストを有する「機会」である場合、「顧客予算」の値を送信し得るとともに、これにより、データストア１１５内の「機会」オブジェクトに格納された「顧客予算」の値を更新し得る。

動作４３０において、クライアントアプリケーション１３５は、データストア１１５から１つ以上のメタデータモジュール２３５を受信し得る。メタデータモジュール２３５は、第２のオブジェクトタイプ定義２３０によって定義される第２のオブジェクトタイプのサブタイプを定義し得る。たとえば、第１のメタデータモジュール２３５は、「顧客名」フィールド、「顧客電話番号」フィールド、および「顧客予算」フィールドを含む「機会」オブジェクトタイプの全標準サブタイプを定義し得る。第２のメタデータモジュール２３５は、「顧客名」フィールドおよび「顧客電話番号」フィールドを含む「機会」オブジェクトタイプのサブセットサブタイプを定義し得る。第３のメタデータモジュール２３５
は、「顧客名」フィールドのみを含む「機会」オブジェクトタイプのリストサブタイプを定義し得る。「機会」オブジェクトタイプのための方法は、クライアントアプリケーション１３５のユーザインターフェイスにおいて「顧客名」フィールドのみを提示する必要がある場合、リストサブタイプメタデータモジュール２３５に従って「機会」オブジェクトのリストをダウンロードして、クライアントデバイス１３０におけるデータ送信オーバーヘッドおよびデータ記憶オーバーヘッドを最小限にし得る。「機会」オブジェクトタイプのための別の方法は、「機会」オブジェクトのリスト内の１つの「機会」オブジェクトが、選択された「機会」オブジェクトのデータフィールドをすべて閲覧および／または編集するために選択された場合、全標準サブタイプメタデータモジュール２３５に従って、選択されたある「機会」オブジェクトの全標準表現をダウンロードし得る。

動作４４０において、クライアントアプリケーション１３５は、第２のオブジェクトタイプ定義２３０に従って作成された新しいオブジェクトが、たとえば、「機会」オブジェクトタイプのリストサブタイプに従って作成された第１のサブタイプであるか、または、たとえば、「機会」オブジェクトタイプの全標準サブタイプに従って作成された第２のサブタイプであるかに関する判定を行ない得る。

動作４４５において、新しいオブジェクトが動作４４０において第２のオブジェクトタイプ定義２３０の第１のサブタイプに対応すると判定された場合、クライアントアプリケーション１３５は、第１のサブタイプに対応するデータフィールドの値をデータストア１１５からフェッチし得る。たとえば、「機会」オブジェクトタイプの第１のサブタイプがリストサブタイプである場合、クライアントアプリケーション１３５は、データストア１１５から「顧客名」データフィールドの値をフェッチし得る。

動作４５０において、新しいオブジェクトが動作４４０において第２のオブジェクトタイプ定義２３０の第２のサブタイプに対応すると判定された場合、クライアントアプリケーション１３５は、第２のサブタイプに対応するデータフィールドの値をデータストア１１５からフェッチし得る。たとえば、「機会」オブジェクトタイプの第２のサブタイプが全標準サブタイプである場合、クライアントアプリケーション１３５は、「顧客予算」データフィールドの値をデータストア１１５からフェッチし得る。

動作４５５において、クライアントアプリケーション１３５は、動作４４５または動作４５０のいずれかにおいてフェッチされたデータフィールドの値を処理し得る。たとえば、クライアントアプリケーション１３５は、フェッチされたデータフィールドの値をクライアントアプリケーション１３５のユーザインターフェイスに表示してもよく、または、クライアントアプリケーション１３５は、フェッチされたデータフィールドの値に対して数学的計算を実行し、当該数学的計算の結果をクライアントアプリケーション１３５のユーザインターフェイスに表示してもよい。

動作４６０において、クライアントアプリケーション１３５は、動作４５５において処理されたデータフィールドの値をデータストア１１５において更新させ得る。クライアントアプリケーション１３５は、持続エンティティ２１０のオブジェクトタイプ定義２２０において表わされた第２のオブジェクトタイプ定義２３０によって定義される方法を実行し得る。当該実行される方法は、動作４５５におけるフェッチされたデータフィールドの値の処理結果に従って、動作４４５および動作４５０のうちの１つにおいてフェッチされたデータフィールドの値を更新するようにとのＨＴＴＰ要求をデータストア１１５に送信するステップを含み得る。

４．２ 再帰的データトラバースモデル
多くの場合、クライアントアプリケーション１３５についてのアプリケーションデータ
および特徴は、さまざまなビジネス目的およびユーザ経験の向上のために、オンザフライで構成可能であることが望ましい。実行時拡張機能は、アプリケーションデータおよび特徴が、クライアントデバイス１３０またはサーバ１１０を介してシームレスに構成可能となることを容易にし得る。加えて、クライアントデバイス１３０がネットワーク１２０を介してサーバ１１０に接続することができないときに、オフラインアクセスにより、アプリケーションデータおよび特徴がクライアントアプリケーション１３５において利用可能になることを容易にし得る。ユーザが実行時にクライアントアプリケーション１３５内のアプリケーションデータまたは機能性にアクセスするためのフローを定義しようと試みても、対応する設計時間エンティティがクライアントデバイス１３０上で利用できない場合、クライアントアプリケーション１３５のユーザの使用が制限される可能性がある。

一例として、さまざまな産業にわたるクライアントアプリケーション１３５の顧客が、同期プロセスによって、それらのさまざまなビジネスワークフローに特有の構成に関する詳細な情報を要求する場合が該当し得る。一実施形態は、クライアントアプリケーション１３５についての定義ファイルの一部としてオブジェクトアグノスティックデータトラバースモデルを用いてこの問題に対処する。オブジェクトアグノスティックデータトラバースモデルは、オンザフライでのクライアントアプリケーション１３５の定義の変更に応じて作用する、実行時における変更を容易にする多形挙動を特徴とし得る。このオブジェクトアグノスティックデータトラバースモデルの一実施形態は、サーバ１１０上でホストされるデータストア１１５に対するシームレスな接続または切断の間、トラバース手段によってサーバ１１０上でホストされるデータストア１１５にデータを要求して、設計時または実行時のいずれかにおいて定義されたアプリケーションデータおよび特徴へのアクセスを提供するために、実行時に変化する可能性のあるグラフ構成をクライアントアプリケーション１３５がリアルタイムで翻訳することを容易にする。

クライアントアプリケーション１３５は、設計時または実行時のいずれかに定義されたアプリケーションデータおよび特徴にアクセスするために、グラフ構成モデルを含み得るとともに、翻訳し得るとともに、用い得る。グラフ構成モデルは、オブジェクトに依存する可能性はなく、定義されたエンティティ上で指定された一意識別子を含み得る。これらの一意識別子は、後続の要求を発行するためにエンティティ上で定義されたメタデータプロパティと併せて用いられてもよい。各特徴は、識別子の下の抽象オブジェクト定義として持続されてもよく、一致する一意識別子を指定するアクションが呼び出された時、引き続き取得されてもよい。グラフ構成モデルにおけるさまざまなエンティティ間のデータ取得関係は、対応するエンティティの一意識別子に従ってメタデータプロパティにおいて指定されてもよい。データ取得関係は、対応するエンティティによって表わされるさまざまなオブジェクトタイプを静的にリンクするマッピングであってもよい。データ取得関係は、実質的には、第１のオブジェクトタイプに基づいてどの記録が取得されるべきかを判定するためにクライアントアプリケーション１３５によって用いられる任意のマッピングであり得る。データ取得関係は、第１のオブジェクトタイプの関数として第２のオブジェクトタイプを識別し得る。次いで、クライアントアプリケーション１３５は、この第２のオブジェクトタイプの記録をサーバ１１０上のデータストア１１５から取得し得る。キャッシュされたデータ取得の複数のモードは、ＵＲＩまたは実行時インデックスのいずれかを用いてサポートされ得る。

クライアントアプリケーション１３５は、実行時に変化し得る構成グラフをリアルタイムで翻訳して、データストア１１５にデータを要求し得る。構成グラフは、クライアントアプリケーション１３５が、データストア１１５からデータをフェッチするようにとの要求を効率的かつ最適に構築することを容易にし得る。構成グラフは、標準スキーマに準拠するメタデータにセグメント化されてもよく、抽象エンティティについて定義された一意修飾子によって識別される抽象エンティティの集合としてメモリに格納されてもよい。当
該修飾子を、エンティティについて定義されたプロパティと併用して、情報を要求してもよい。データの要求は、再帰的データトラバースによるものであってもよく、データストア１１５に接続されているかまたはデータストア１１５から切断されている間、クライアントアプリケーション１３５の設計時またはクライアントアプリケーション１３５の実行時のいずれかにおいて定義されたデータおよび特徴へのアクセスを提供し得る。データは、ユーザアクセスの前にクライアントデバイス１３０上でキャッシュされてもよく、これより、ユーザ経験をリアルタイムで最適化し得る。要求に対する応答は、クライアントデバイス１３０上のデータストレージに受信されて持続され得る。

クライアントアプリケーション１３５は、グラフ構成モデルを翻訳して用いることで、クライアントアプリケーション１３５の設計時または実行時のいずれかにおいて定義された特徴についてのデータにアクセスし得る。オブジェクトアグノスティックモデルによって定義されるエンティティに関して指定された一意識別子は、後続の要求を発行するためにエンティティ上で定義されたメタデータプロパティとともに使用されてもよい。各特徴は、識別子の下の抽象的なオブジェクト定義として持続され得るとともに、その後、一致した一意識別子を指定するアクションが呼び出されたときに取得され得る。

図５は、１つ以上の実施形態に従った、エンティティ５１０と、関係するエンティティ５２０との間の関係を示す構成グラフ５００を例示するブロック図を示す。各エンティティ５１０は、１つ以上の関係するエンティティ５２０とのデータ取得関係５１５を有し得る。同様に、各々の関係するエンティティ５２０は、１つ以上の他の関係するエンティティ５２０とのデータ取得関係５２５を有し得る。構成グラフ５００は、構成データファイルに格納され得るかまたはメモリに格納されたデータ構造に格納され得る。

図６は、１つ以上の実施形態に従った、構成グラフにおけるエンティティ６００のコンポーネントを例示するブロック図を示す。エンティティ６００は、図５に示されるエンティティ５１０の一実施形態であり得る。エンティティ６００は、一意識別子６１０、データ６２０、タイプ定義６３０、１つ以上の関係するエンティティ６４０へのポインタ、および、さまざまな問合せプロパティ６５０を含み得る。一意識別子６１０は、エンティティ６００がクライアントアプリケーション１３５および／またはクライアントデバイス１３０において持続されている場合、エンティティ６００に対応する持続エンティティ２１０の一意識別子２１５に対応し得る。データ６２０は、対応する持続エンティティ２１０のデータ値２２５に対応し得るとともに、タイプ定義６３０は、対応する持続エンティティ２１０のタイプ定義２２０に対応し得る。

関係するエンティティ６４０は、１つ以上の関係するエンティティ７００に関連付けられた一意識別子７１０のリスト（図７を参照）を含み得る。関係するエンティティ６４０は、問合せプロパティ６５０において指定され得る多数のさまざまな基準のいずれかに従ってエンティティ６００に関係付けられてもよい。問合せプロパティ６５０はまた、関係するエンティティ６４０がサーバ１１０のデータストア１１５において問合せされるときに、結果のリストにおいて関係するエンティティ６４０をどのように順序付けるべきかを指定することもできる。

図７は、１つ以上の実施形態に従った構成グラフにおける関係するエンティティ７００のコンポーネントを例示するブロック図を示す。関係するエンティティ７００は、図５に示される関係するエンティティ５２０の一実施形態であり得る。関係するエンティティ７００は、一意識別子７１０、データ７２０、タイプ定義７３０、１つ以上の他の関係するエンティティ７４０へのポインタ、および、さまざまな問合せプロパティ７５０を含み得る。一意識別子７１０は、関係するエンティティ７００がクライアントアプリケーション１３５および／またはクライアントデバイス１３０において持続されている場合、関係す
るエンティティ７００に対応する持続エンティティ２１０の一意識別子２１５に対応し得る。データ７２０は、対応する持続エンティティ２１０のデータ値２２５に対応し得るとともに、タイプ定義７３０は、対応する持続エンティティ２１０のタイプ定義２２０に対応し得る。

関係するエンティティ７４０は、１つ以上の他の関係するエンティティ７００に関連付けられた一意識別子７１０のリストを含み得る。関係するエンティティ７４０は、問合せプロパティ７５０において指定され得るいくつかの異なる基準のいずれかに従って、関係するエンティティ７００に関係付けられてもよい。問合せプロパティ７５０は、実行された問合せに関連付けられた問合せプロパティ６５０に従って１つ以上の関係するエンティティ６４０を戻すためにエンティティ６００に対して実行された問合せの結果に対応し得る。問合せプロパティ７５０はまた、関係するエンティティ７４０がサーバ１１０のデータストア１１５において問合せされるときに、結果のリストにおいて当該関係するエンティティ７４０をどのように順序付けるべきかを指定することもできる。問合せプロパティ７５０はまた、関係するエンティティ７００に親として関連付けられるエンティティ６００のＰａｒｅｎｔＩＤまたは一意識別子７１０と、所与の問合せ基準を関係するエンティティ７００と一致させる基数またはいくつかの関係するエンティティ７００とを含む。

図８は、１つ以上の実施形態に従った、データキャッシュを更新するための動作８００のセット例を例示するブロック図を示す。動作８００のセットは、図１に示されるように、クライアントデバイス１３０上のクライアントアプリケーション１３５によって実行され得る。図８に示される１つ以上の動作は、すべてまとめて修正、再配置、または省略されてもよい。したがって、図８に示される動作の特定のシーケンスは、１つ以上の実施形態の範囲を限定するものとして解釈されるべきではない。明確にするために詳細な例を以下に記載する。以下に記載するコンポーネントおよび／または動作は、特定の実施形態に適用可能でない可能性もある一具体例として理解されるべきである。したがって、以下に記載するコンポーネントおよび／または動作は、添付の特許請求のいずれかの範囲を限定するものと解釈されるべきではない。さまざまな実施形態において、動作８００は、図１～図９を参照して上述したシステムおよびコンポーネントを用いて実行されてもよい。

構成グラフ、たとえば構成グラフ５００は、データファイルまたはメモリ内のデータ構造に格納され得る。構成グラフは、データストア１１５から取得されるとともにクライアントアプリケーション１３５によってクライアントデバイス１３０に格納されるべきデータのサブセットを定義し得る。クライアントデバイス１３０が含み得るメモリ容量はデータストア１１５のメモリ容量よりもはるかに少なくてもよく、データストア１１５からクライアントデバイス１３０にデータを送信するためにネットワーク１２０において利用可能なデータ帯域幅は限られている可能性がある。構成グラフ（たとえば、構成グラフ５００）において定義されるデータは、本明細書で図２を参照して説明した持続エンティティ２１０に対応するエンティティ（たとえば、エンティティ５１０）および関係するエンティティ（たとえば、関係するエンティティ５２０）を含み得る。構成グラフはまた、クライアントアプリケーション１３５の特徴、たとえば、定義されたさまざまな基準に合致するデータを取得するためにデータストア１１５に格納されたデータに対して実行されるべき問合せ、を定義してもよい。構成グラフのデータおよびアプリケーションは、メタデータに格納された情報を含み得る。メタデータに基づいて、クライアントアプリケーション１３５は、関係するエンティティ５２０を識別し、エンティティ５１０の値を用いてメタデータ内で識別された関係するエンティティ５２０に関する問合せを生成し、次いで、データストア１１５からエンティティ５１０および関係するエンティティ５２０を取得し得る。

一例として、構成グラフ５００におけるエンティティ５１０は、オブジェクトタイプ「
製品（Product）」についてのタイプ定義６３０を有する第１のオブジェクトタイプに関
連付けられ得る。「製品」オブジェクトタイプは、クライアントデバイス１３０上のクライアントアプリケーション１３５を用いる販売者が販売するために訪問することとなる会社によって提供される１つ以上の製品に関するものであってもよい。構成グラフ５００は、販売者の会社によって提供される指定された製品に関する指定済み問合せプロパティ６５０に一致する、データストア１１５内のオブジェクトタイプ「機会」に関するタイプ定義６３０を有するすべての第２のオブジェクトタイプをサーチして取得するために、問合せプロパティ６５０とともにメタデータに問合せを含み得る。「機会」オブジェクトタイプは、会社によって提供される指定済み製品についての１つ以上の販売機会に関するものであってもよい。販売機会は、連絡先担当者の名前、電話番号、住所、電話番号、購入を所望されている製品、予想される必要ユニット数、配送に必要な予想される時間帯などの情報を含み得る。クライアントアプリケーション１３５は、指定された製品と関連付けられた販売機会との間の関係を、第１のオブジェクトタイプに関連付けられてメタデータに格納されたデータ取得関係として分析し得る（動作８１０）。この例では、第１のオブジェクトタイプは「製品」オブジェクトタイプであってもよい。

クライアントアプリケーション１３５がデータ取得関係を分析した後、クライアントアプリケーション１３５は、第１のオブジェクトタイプの記録に基づいて、データストア１１５から取得すべき記録があるかどうかを判定し得る（動作８２０）。この例における動作８１０の分析に従うと、クライアントアプリケーション１３５は、会社によって提供される指定済み製品に基づいて、データストア１１５から取得すべき販売機会があると判定し得る。

記載されている例においては、クライアントアプリケーション１３５は、販売者が売込みのために訪問する際に必要となるであろう会社の製品に関連付けられたすべての販売機会記録を取得するために、データストア１１５に対する問合せを実行する準備を開始し得る。これらの準備のうちの１ステップとして、クライアントアプリケーション１３５は、データストア１１５から販売機会が取得されるであろう対象となる１つ以上の製品の各々の製品名を識別し得る。言い換えれば、クライアントアプリケーション１３５は、第１のオブジェクトタイプの製品名フィールドに対応する、第１のオブジェクトタイプ、たとえば「製品」オブジェクトタイプ、についての１つ以上の記録から１つ以上の値を識別し得る（動作８３０）。

次いで、クライアントアプリケーション１３５は、データストア１１５から販売機会が取得されるであろう対象となる１つ以上の製品の各々についての１つ以上の製品名を用いて、１つ以上の問合せのセットを生成し得る。これらの問合せは、製品に対応するエンティティ６００内の問合せプロパティ６５０に基づいて生成されてもよい。問合せのセットは、特定のエンティティ６００に関係付けられた関係するエンティティ６４０を取得するために生成され得る。たとえば、１つの製品名に対して１つの問合せ、別の製品名に対して別の１つの問合せなどのように２つ以上の問合せセットが生成されてもよい。言い換えれば、クライアントアプリケーション１３５は、第２のオブジェクトタイプの記録の第２のセットのうち第１のサブセットおよび第２のサブセットを取得するために、１つ以上の問合せのセットを生成し得る（動作８４０）。１つ以上の問合せを生成する動作は、問合せを表わす１つ以上のＵＲＩを生成する動作を含み得る。第２のオブジェクトタイプの記録の第２のセットのうち第１のサブセットおよび第２のサブセットは、それぞれ、第２のオブジェクトタイプの第２のフィールドに関係する第１の値および第２の値を含み得る。たとえば、販売機会記録の第１のサブセットおよび第２のサブセットは、それぞれ、販売機会の対応するサブセットの製品名フィールドに関係する第１の製品名および第２の製品名を含み得る。問合せのセットは、データストア１１５から第１の製品名に関する販売機会の第１のサブセットおよび第２の製品名に関する販売機会の第２のサブセットを取得す
るために生成され得る。次いで、クライアントアプリケーション１３５は、１つ以上の問合せのセットを実行して、第２のオブジェクトタイプの記録の第２のセットのうち第１のサブセットおよび第２のサブセットを取得し得る（動作８５０）。

問合せを実行した後、クライアントアプリケーション１３５は、第２のオブジェクトタイプの記録の第２のセットのうち第１のサブセットおよび第２のサブセットでクライアントアプリケーション１３５内のキャッシュを更新することによって、データストア１１５から取得されたデータをクライアントデバイス１３０に格納し得る（動作８６０）。たとえば、クライアントアプリケーション１３５は、データストア１１５上で実行された問合せにおいて名前が識別された製品に関係付けられた販売機会を、クライアントデバイス１３０のデータキャッシュにローカルに格納し得る。

以下の表１に、動作８５０における指定済み製品の製品名に関する問合せの実行に従ってデータストア１１５から取得されるべき製品および関係する販売機会についての記録によって表わされる例示的な構成グラフ５００を示す。製品記録は、問合せによってアクセスされるべき、データストア１１５に格納されたデータを示す。

表１に示されるように、製品記録は、対応する販売機会記録内の対応する製品名フィールドと一致する製品名フィールド値を有する。特定の製品に関係付けられた販売機会記録についての問合せは、販売機会記録が関係付けられている特定の製品の製品名値に一致する特定の製品名値を有する製品名フィールドをサーチし得る。製品と販売機会との間の関係は、たとえば、潜在的な顧客が製品に関心を表わしており、その関心が顧客に関連付けられた関連する販売機会記録へのエントリとしてデータストア１１５内に取込まれるたびに確立され得る。当該関心は、販売者、ウェブサイトフォーム、手書きの情報カードからのデータ入力などによって取込まれてもよい。

表１．静的にリンクされた関係する販売機会記録を含む製品記録を表わす例示的な構成グラフ５００

以下の表２に、関係するエンティティ間の動的にリンクされた関係を用いて製品記録が格納されていることを除いて、動作８５０における指定済み製品の製品名に関する問合せの実行に従ってデータストア１１５から取得されるべき製品および関係する販売機会についての記録を含む構成グラフ５００についての同様の例を示す。エンティティと当該関係するエンティティとの間で共有されるフィールドの名前によって関係が識別されている表１に示される静的にリンクされた関係とは対照的に、表２の動的にリンクされた関係は、エンティティと当該関係するエンティティとの間の動的リンクデータ構造によって確立される。関係が変化すると、クライアントアプリケーション１３５は、クライアントデバイス１３０に搭載されたデータキャッシュのデータ構造内のリンクを修正し得る。クライアントアプリケーション１３５は、構成グラフ５００を実行して、データストア１１５に格納されたデータからクライアントデバイス１３０に搭載されたデータキャッシュも更新し得る。

表２．動的にリンクされた関係する販売機会記録を有する製品記録を含む例示的な構成グラフ５００

一実施形態では、構成グラフ５００は、販売者が販売している製品に関係付けられた販売出張旅行で販売者が訪問しようとしている地理的範囲に関するすべての販売機会を含み得る。構成グラフ５００は、販売者が手動で行なわなくても自動的に、販売者にとって次回の販売出張旅行に必要となる情報でクライアントデバイス１３０を更新し得る。販売者は、販売者の販売出張旅行前にクライアントデバイス１３０のデータキャッシュを自動的に更新するために、構成グラフ５００を含むデータファイルを販売出張旅行前にクライアントアプリケーション１３５にロードしてもよい。

さまざまな実施形態において、構成グラフ５００は、クライアントデバイス１３０上にローカルに格納されたデータが、必要に応じて予測される前に自動的に更新されることを容易にし得る。そうすることにより、データが必要なときにクライアントアプリケーション１３５によるデータストア１１５へのアクセスが遅くなるかまたはアクセスができなくなるという問題を回避し得る。

さまざまな実施形態において、構成グラフ５００はクライアントアプリケーション１３５内のメモリに格納されており、これにより、販売者がクライアントアプリケーション１３５に署名するたびに、構成グラフ５００がトｓラバースされ、クライアントデバイス１３０のデータキャッシュがデータストア１１５に格納された現在のデータに従って更新されてから、販売者がクライアントアプリケーション１３５を使用し始めることとなる。

さまざまな実施形態において、構成グラフ５００内のあるエンティティ５１０に対応す
る持続エンティティ２１０がクライアントアプリケーション１３５において更新されるたびに構成グラフ５００がトラバースされ得ることで、データストア１１５からダウンロードされたデータによる持続エンティティ２１０の更新によって影響を受ける任意のエンティティ６００および／または関係するエンティティ６４０をリフレッシュまたは更新し得る。

構成グラフ５００は、データストア１１５からダウンロードされたデータから、クライアントデバイス１３０上に残っているデータの効率的な更新を容易にする。これは、クライアントデバイス１３０が含むデータ用メモリおよび記憶空間の量がデータストア１１５の場合よりもかなり少ないことと、クライアントデバイス１３０とデータストア１１５をホストするサーバ１１０との間のネットワーク１２０が有する帯域幅が限られており、このネットワーク１２０がしばしば利用できなくなることとを考慮すると、重要であるとともに有用である。

５．コンピュータネットワークおよびクラウドネットワーク
１つ以上の実施形態では、コンピュータネットワークは、１組のノード間の接続性を提供する。これらのノードは、互いにローカルおよび／またはリモートであってもよい。これらのノードは、１組のリンクによって接続される。リンクの例は、同軸ケーブル、無被覆ツイストケーブル、銅ケーブル、光ファイバ、および仮想リンクを含む。

ノードのサブセットはコンピュータネットワークを実装する。そのようなノードの例は、スイッチ、ルータ、ファイアウォール、およびネットワークアドレストランスレータ（network address translator：ＮＡＴ）を含む。ノードの他のサブセットはコンピュータネットワークを用いる。そのようなノード（「ホスト」とも呼ばれる）は、クライアントプロセスおよび／またはサーバプロセスを実行し得る。クライアントプロセスは、コンピューティングサービス（たとえば、特定のアプリケーションの実行、および／または特定の量のデータの格納など）についての要求を行なう。サーバプロセスは、要求されたサービスを実行することによって、および／または対応するデータを返すことによって応答する。

コンピュータネットワークは、物理的リンクによって接続された物理的ノードを含む物理的ネットワークであってもよい。物理的ノードとは任意のデジタルデバイスである。物理的ノードは、ハードウェアスイッチ、ハードウェアルータ、ハードウェアファイアウォール、およびハードウェアＮＡＴなどの特定機能のハードウェアデバイスであってもよい。これに加えて、またはこれに代えて、物理的ノードは、それぞれの機能を実行するさまざまな仮想マシンおよび／またはアプリケーションを実行するように構成された汎用マシンであってもよい。物理的リンクとは、２つ以上の物理的ノードを接続する物理的媒体である。リンクの例は、同軸ケーブル、無被覆ツイストケーブル、銅ケーブル、および光ファイバを含む。

コンピュータネットワークは、オーバーレイネットワークであってもよい。オーバーレイネットワークとは、別のネットワーク（物理的ネットワークなど）の上に実装された論理的ネットワークである。オーバーレイネットワークにおける各ノードは、下位ネットワークにおけるそれぞれのノードに対応する。よって、オーバーレイネットワークにおける各ノードは、（オーバーレイノードをアドレス指定するための）オーバーレイアドレスと、（オーバーレイノードを実現するアンダーレイノードをアドレス指定するための）アンダーレイアドレスとの双方に関連付けられる。オーバーレイノードは、デジタルデバイスおよび／またはソフトウェアプロセス（仮想マシン、アプリケーションインスタンス、またはスレッドなど）であってもよい。オーバーレイノード同士を接続するリンクは、下位ネットワークを通るトンネルとして実現される。トンネルの両端のオーバーレイノードは
、当該オーバーレイノード同士の間の下位マルチホップ経路を、単一の論理的リンクとして扱う。カプセル化および非カプセル化によってトンネリングが実行される。

ある実施形態では、クライアントは、コンピュータネットワークに対してローカルおよび／またはリモートであってもよい。クライアントは、コンピュータネットワークに、プライベートネットワークまたはインターネットなどの他のコンピュータネットワークを介してアクセスしてもよい。クライアントは、ＨＴＴＰなどの通信プロトコルを用いて、コンピュータネットワークに要求を通信してもよい。要求は、クライアントインターフェイス（ウェブブラウザなど）、プログラムインターフェイス、またはアプリケーションプログラミングインターフェイス（application programming interface：ＡＰＩ）といった
インターフェイスを通して通信される。

ある実施形態では、コンピュータネットワークは、クライアントとネットワークリソースとの間に接続性を提供する。ネットワークリソースは、サーバプロセスを実行するように構成されたハードウェアおよび／またはソフトウェアを含む。ネットワークリソースの例は、プロセッサ、データ記憶装置、仮想マシン、コンテナ、および／またはソフトウェアアプリケーションを含む。ネットワークリソースは、複数のクライアント間で共有される。クライアントは互いから独立して、コンピュータネットワークにコンピューティングサービスを要求する。ネットワークリソースは、オンデマンドベースで要求および／またはクライアントに動的に割り当てられる。各要求および／またはクライアントに割り当てられたネットワークリソースは、たとえば、（ａ）特定のクライアントによって要求されたコンピューティングサービス、（ｂ）特定のテナントによって要求された、集約されたコンピューティングサービス、および／または、（ｃ）コンピュータネットワークに要求された、集約されたコンピューティングサービス、に基づいて拡大または縮小されてもよい。そのようなコンピュータネットワークは「クラウドネットワーク」とも称され得る。

ある実施形態では、サービスプロバイダは、クラウドネットワークを１人以上のエンドユーザに提供する。ソフトウェア・アズ・ア・サービス（Software-as-a-Service：Ｓａ
ａＳ）、プラットフォーム・アズ・ア・サービス（Platform-as-a-Service：ＰａａＳ）
、およびインフラストラクチャ・アズ・ア・サービス（Infrastructure-as-a-Service ：ＩａａＳ）を含むもののそれらに限定されない、さまざまなサービスモデルが、クラウドネットワークによって実現され得る。ＳａａＳでは、サービスプロバイダは、ネットワークリソース上で実行されるサービスプロバイダのアプリケーションを使用する能力を、エンドユーザに提供する。ＰａａＳでは、サービスプロバイダは、ネットワークリソース上にカスタムアプリケーションを配備する能力を、エンドユーザに提供する。カスタムアプリケーションは、サービスプロバイダによってサポートされるプログラミング言語、ライブラリ、サービス、およびツールを用いて作成され得る。ＩａａＳでは、サービスプロバイダは、ネットワークリソースによって提供される処理、記憶、ネットワーク、および他の基本的コンピューティングリソースをプロビジョニングする能力を、エンドユーザに提供する。オペレーティングシステムを含む任意のアプリケーションが、ネットワークリソース上に配備され得る。

ある実施形態では、プライベートクラウド、パブリッククラウド、およびハイブリッドクラウドを含むもののそれらに限定されない、さまざまな配備モデルがコンピュータネットワークによって実現され得る。プライベートクラウドでは、ネットワークリソースは、１つ以上のエンティティからなる特定のグループによる独占的使用のためにプロビジョニングされる（ここで用いられる「エンティティ」という語は、企業、組織、人または他のエンティティを指す）。ネットワークリソースは、エンティティからなる特定のグループの構内に対してローカルおよび／またはリモートであってもよい。パブリッククラウドでは、クラウドリソースは、互いに独立した複数のエンティティ（「テナント」または「顧
客」とも称される）のためにプロビジョニングされる。コンピュータネットワークおよびそのネットワークリソースは、異なるテナントに対応するクライアントによってアクセスされる。そのようなコンピュータネットワークは、「マルチテナントコンピュータネットワーク」と称されることもある。いくつかのテナントは、異なる時間に、および／または同じ時間に、同じ特定のネットワークリソースを用いてもよい。ネットワークリソースは、テナントの構内に対してローカルおよび／またはリモートであってもよい。ハイブリッドクラウドでは、コンピュータネットワークは、プライベートクラウドとパブリッククラウドとを含む。プライベートクラウドとパブリッククラウドとの間のインターフェイスが、データおよびアプリケーション可搬性を可能にする。プライベートクラウドに格納されたデータと、パブリッククラウドに格納されたデータとは、インターフェイスを通して交換されてもよい。プライベートクラウドで実現されるアプリケーションと、パブリッククラウドで実現されるアプリケーションとは、互いに対する従属性を有していてもよい。プライベートクラウドにおけるアプリケーションからパブリッククラウドにおけるアプリケーションへの（逆もまた同様）呼出しが、インターフェイスを通して実行されてもよい。

ある実施形態では、マルチテナントコンピュータネットワークのテナントは互いに独立している。たとえば、１つのテナントのビジネスまたは事業は、別のテナントのビジネスまたは事業とは別のものであり得る。さまざまなテナントが、コンピュータネットワークに対してさまざまなネットワーク要件を要求し得る。ネットワーク要件の例は、処理速度、データ記憶量、セキュリティ要件、性能要件、スループット要件、待ち時間要件、回復力要件、サービス品質（Quality of Service：ＱｏＳ）要件、テナント分離、および／または一貫性を含む。同じコンピュータネットワークが、さまざまなテナントによって要求されるさまざまなネットワーク要件を実現する必要があり得る。

１つ以上の実施形態では、マルチテナントコンピュータネットワークにおいて、さまざまなテナントのアプリケーションおよび／またはデータが互いに共有されないことを確実にするために、テナント分離が実現される。さまざまなテナント分離アプローチが用いられてもよい。

ある実施形態では、各テナントは、テナントＩＤに関連付けられる。マルチテナントコンピュータネットワークの各ネットワークリソースが、テナントＩＤでタグ付けされる。テナントと特定のネットワークリソースとが同じテナントＩＤに関連付けられている場合のみ、テナントは、特定のネットワークリソースへのアクセスを許可される。

ある実施形態では、各テナントはテナントＩＤに関連付けられている。コンピュータネットワークによって実現された各アプリケーションが、テナントＩＤでタグ付けされている。これに加えて、またはこれに代えて、コンピュータネットワークによって格納された各データ構造および／またはデータセットが、テナントＩＤでタグ付けされている。テナントと特定のアプリケーション、データ構造、および／またはデータセットとが同じテナントＩＤに関連付けられている場合のみ、テナントは、特定のアプリケーション、データ構造、および／またはデータセットへのアクセスを許可される。

一例として、マルチテナントコンピュータネットワークによって実現される各データベースはテナントＩＤでタグ付けされてもよい。対応するテナントＩＤに関連付けられたテナントのみが、特定のデータベースのデータにアクセスしてもよい。別の例として、マルチテナントコンピュータネットワークによって実現されたデータベースにおける各エントリが、テナントＩＤでタグ付けされてもよい。対応するテナントＩＤに関連付けられたテナントのみが、特定のエントリのデータにアクセスしてもよい。しかしながら、データベースは複数のテナントによって共有されてもよい。

ある実施形態では、サブスクリプションリストは、どのテナントがどのアプリケーションにアクセスするための認証を有するかを示す。アプリケーションごとに、アプリケーションへのアクセスを認証されたテナントのテナントＩＤのリストが格納されている。テナントのテナントＩＤが、特定のアプリケーションに対応する申し込みリストに含まれる場合のみ、テナントは、特定のアプリケーションへのアクセスを許可される。

ある実施形態では、異なるテナントに対応するネットワークリソース（デジタルデバイス、仮想マシン、アプリケーションインスタンス、およびスレッドなど）同士は、マルチテナントコンピュータネットワークによって維持されるテナント特有オーバーレイネットワークに分離される。一例として、テナントオーバーレイネットワークにおける任意の発信元デバイスからのパケットは、同じテナントオーバーレイネットワーク内の他のデバイスにのみ送信され得る。テナントオーバーレイネットワーク上の発信元デバイスから他のテナントオーバーレイネットワークにおけるデバイスへの送信をいずれも禁止するために、カプセル化トンネルが使用される。具体的には、発信元デバイスから受信されたパケットは、外部パケット内でカプセル化される。外部パケットは、（テナントオーバーレイネットワークにおける発信元デバイスと通信する）第１のカプセル化トンネルエンドポイントから、（テナントオーバーレイネットワークにおける宛先デバイスと通信する）第２のカプセル化トンネルエンドポイントへ送信される。第２のカプセル化トンネルエンドポイントは、発信元デバイスによって送信された元のパケットを取得するために、外部パケットを非カプセル化する。元のパケットは、第２のカプセル化トンネルエンドポイントから、同じ特定のオーバーレイネットワークにおける宛先デバイスへ送信される。

６．その他；拡張
実施形態は、ハードウェアプロセッサを含むとともに本明細書に記載された動作および／または添付の特許請求の範囲のいずれかに列挙される動作のいずれかを実行するように構成された、１つ以上のデバイスを含むシステムを対象とする。

ある実施形態では、非一時的コンピュータ可読記憶媒体は、１つ以上のハードウェアプロセッサによって実行されると、本明細書に記載される動作および／または特許請求の範囲のいずれかに列挙される動作のいずれかを実行させる命令を備える。

ここに説明された特徴と機能性との任意の組合せが、１つ以上の実施形態に従って用いられてもよい。前述の明細書では、実施形態は、実現例ごとに異なり得る多くの具体的詳細を参照して説明されてきた。したがって、明細書および添付の図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。本発明の範囲の唯一かつ排他的な指標、および、出願人によって本発明の範囲であることが意図されるものは、任意の後の補正を含めて、そのような特許請求の範囲が生じる特定の形態での、本願から生じる特許請求の範囲のセットの文字通りかつ同等の範囲である。

７．ハードウェア概要
一実施形態に従うと、ここに説明される手法は、１つ以上の専用コンピューティングデバイスによって実現される。これらの専用コンピューティングデバイスは、これらの手法を実行するためにハードワイヤードされてもよく、もしくは、これらの手法を実行するように永続的にプログラムされた１つ以上の特定用途向け集積回路（application-specific
integrated circuit：ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate array：ＦＰＧＡ）、もしくはネットワーク処理ユニット（network processing unit：ＮＰＵ）といったデジタル電子デバイスを含んでいてもよく、または、フ
ァームウェア、メモリ、他の記憶装置、もしくはそれらの組合せにおいてプログラム命令に従ってこれらの手法を実行するようにプログラムされた１つ以上の汎用ハードウェアプロセッサを含んでいてもよい。そのような専用コンピューティングデバイスはまた、これ
らの手法を遂行するために、カスタムハードワイヤードロジック、ＡＳＩＣ、ＦＰＧＡ、またはＮＰＵをカスタムプログラミングと組合わせてもよい。当該専用コンピューティングデバイスは、デスクトップコンピュータシステム、ポータブルコンピュータシステム、手持ち型デバイス、ネットワーキングデバイス、または、これらの手法を実現するためにハードワイヤードロジックおよび／もしくはプログラムロジックを組込んだ任意の他のデバイスであってもよい。

たとえば、図９は、本発明の一実施形態が実現され得るコンピュータシステム９００を示すブロック図である。コンピュータシステム９００は、情報を通信するためのバス９０２または他の通信機構と、情報を処理するためにバス９０２と結合されるハードウェアプロセッサ９０４とを含む。ハードウェアプロセッサ９０４は、たとえば、汎用マイクロプロセッサであってもよい。

コンピュータシステム９００はまた、プロセッサ９０４によって実行されるべき命令および情報を格納するためにバス９０２に結合された、ランダムアクセスメモリ（random access memory：ＲＡＭ）または他の動的記憶装置などのメインメモリ９０６を含む。メインメモリ９０６はまた、プロセッサ９０４によって実行されるべき命令の実行中に一時的な変数または他の中間情報を格納するために使用されてもよい。そのような命令は、プロセッサ９０４にアクセス可能な非一時的記憶媒体に格納されると、コンピュータシステム９００を、命令で特定された動作を実行するようにカスタマイズされた専用マシンにする。

コンピュータシステム９００はさらに、プロセッサ９０４のための静的情報および命令を格納するためにバス９０２に結合された読出専用メモリ（read only memory：ＲＯＭ）９０８または他の静的記憶装置を含む。磁気ディスクまたは光ディスクなどの記憶装置９１０が設けられ、情報および命令を格納するためにバス９０２に結合される。

コンピュータシステム９００は、情報をコンピュータユーザへ表示するための陰極線管（cathode ray tube：ＣＲＴ）などのディスプレイ９１２に、バス９０２を介して結合され得る。英数字キーおよび他のキーを含む入力装置９１４が、情報およびコマンド選択をプロセッサ９０４へ通信するためにバス９０２に結合される。別のタイプのユーザ入力装置は、方向情報およびコマンド選択をプロセッサ９０４へ通信するための、ならびに、ディスプレイ９１２上のカーソル移動を制御するための、マウス、トラックボール、またはカーソル方向キーなどのカーソル制御装置９１６である。この入力装置は典型的には、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）という２つの軸において２つの自由度を有しており、これにより、当該装置が平面における位置を特定することを可能にする。

コンピュータシステム９００は、コンピュータシステムと組合されることでコンピュータシステム９００を専用マシンにするかまたは専用マシンになるようプログラムする、カスタマイズされたハードワイヤードロジック、１つ以上のＡＳＩＣもしくはＦＰＧＡ、ファームウェアおよび／またはプログラムロジックを用いて、ここに説明された手法を実現してもよい。一実施形態に従うと、本明細書中の手法は、メインメモリ９０６に含まれる１つ以上の命令の１つ以上のシーケンスをプロセッサ９０４が実行することに応答して、コンピュータシステム９００によって実行される。このような命令は記憶装置９１０などの別の記憶媒体からメインメモリ９０６に読込まれてもよい。メインメモリ９０６に含まれる命令のシーケンスを実行することにより、ここに説明されたプロセスステップをプロセッサ９０４に実行させる。代替的な実施形態では、ハードワイヤード回路が、ソフトウェア命令の代わりに、またはソフトウェア命令と組合わせて使用されてもよい。

本明細書中において用いられる「記憶媒体」という語は、マシンを特定の態様で動作させるデータおよび／または命令を格納する任意の非一時的媒体を指す。そのような記憶媒体は、不揮発性媒体および／または揮発性媒体を含み得る。不揮発性媒体は、たとえば、記憶装置９１０などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ９０６などのダイナミックメモリを含む。記憶媒体の一般的な形態は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、ソリッドステートドライブ、磁気テープ、または任意の他の磁気データ記憶媒体、ＣＤ－ＲＯＭ、任意の他の光学データ記憶媒体、穴のパターンを有する任意の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ－ＥＰＲＯＭ、ＮＶＲＡＭ、任意の他のメモリチップまたはカートリッジ、連想メモリ（content-addressable memory：ＣＡＭ）、および３値連想メモリ（ternary content-addressable memory：ＴＣＡＭ）を含む。

記憶媒体は伝送媒体とは異なるが、伝送媒体とともに用いられてもよい。伝送媒体は、記憶媒体間の情報の転送に関与する。たとえば、伝送媒体は、バス９０２を構成するワイヤを含む、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体はまた、電波通信および赤外線データ通信時に生成されるような音波または光波の形態を取ることもできる。

さまざまな形態の媒体が、１つ以上の命令の１つ以上のシーケンスを実行のためにプロセッサ９０４へ搬送することに関与し得る。たとえば、命令は最初、リモートコンピュータの磁気ディスクまたはソリッドステートドライブ上で搬送され得る。リモートコンピュータは、そのダイナミックメモリに命令をロードし、モデムを用いて電話回線を介して命令を送信し得る。コンピュータシステム９００に対してローカルなモデムが、電話回線を介してデータを受信し、赤外線送信機を用いてデータを赤外線信号に変換し得る。赤外線検出器が、赤外線信号で搬送されたデータを受信し得るとともに、適切な回路がデータをバス９０２上に配置し得る。バス９０２はデータをメインメモリ９０６へ搬送し、そこから、プロセッサ９０４が命令を取出して実行する。メインメモリ９０６が受信した命令は、任意には、プロセッサ９０４による実行の前または後に、記憶装置９１０上に格納されてもよい。

コンピュータシステム９００はまた、バス９０２に結合された通信インターフェイス９１８を含む。通信インターフェイス９１８は、ローカルネットワーク７２２に接続されたネットワークリンク９２０への双方向データ通信結合を提供する。たとえば、通信インターフェイス９１８は、総合サービスデジタル網（integrated services digital network
：ＩＳＤＮ）カード、ケーブルモデム、衛星モデム、または、対応するタイプの電話回線へのデータ通信接続を提供するためのモデムであってもよい。別の例として、通信インターフェイス９１８は、互換性のあるＬＡＮへのデータ通信接続を提供するためのローカルエリアネットワーク（local area network：ＬＡＮ）カードであってもよい。無線リンクが実現されてもよい。任意のそのような実現例では、通信インターフェイス９１８は、さまざまなタイプの情報を表わすデジタルデータストリームを搬送する電気信号、電磁信号、または光信号を送受信する。

ネットワークリンク９２０は典型的には、１つ以上のネットワークを通して、他のデータデバイスにデータ通信を提供する。たとえば、ネットワークリンク９２０は、ローカルネットワーク９２２を介して、ホストコンピュータ９２４に、またはインターネットサービスプロバイダ（Internet Service Provider：ＩＳＰ）９２６によって操作されるデー
タ機器に接続し得る。ＩＳＰ９２６は次に、現在一般的に「インターネット」９２８と称されている全世界的パケットデータ通信ネットワークを通して、データ通信サービスを提供する。ローカルネットワーク９２２およびインターネット９２８はともに、デジタルデータストリームを搬送する電気信号、電磁信号または光信号を用いる。さまざまなネットワークを通る信号、および、通信インターフェイス９１８を通るネットワークリンク９２
０上の信号はコンピュータシステム９００との間でデジタルデータを搬送するものであって、伝送媒体の例示的な形態である。

コンピュータシステム９００は、ネットワーク、ネットワークリンク９２０、および通信インターフェイス９１８を通して、メッセージを送信し、プログラムコードを含むデータを受信し得る。インターネットの例では、サーバ９３０が、インターネット９２８、ＩＳＰ９２６、ローカルネットワーク９２２、および通信インターフェイス９１８を通して、アプリケーションプログラムのための要求されたコードを送信し得る。

受信されたコードは、受信時にプロセッサ９０４によって実行されてもよく、および／または、後で実行するために記憶装置９１０または他の不揮発性記憶装置に格納されてもよい。

上述の明細書では、本発明の実施形態は、実現例によって異なり得る多くの具体的詳細を参照して説明されてきた。したがって、明細書および添付の図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。本発明の範囲の唯一かつ排他的な指標、および、出願人によって本発明の範囲であることが意図されるものは、任意の後の補正を含めて、そのような特許請求の範囲が生じる特定の形態での、本願から生じる特許請求の範囲のセットの文字通りかつ同等の範囲である。

Claims (20)

1. １つ以上のプロセッサによって実行されると以下の動作を実行させる命令を格納する１つ以上の非一時的な機械可読媒体であって、前記以下の動作は、
   第１のオブジェクトタイプに基づいてデータキャッシュを更新する動作を含み、前記更新する動作は、少なくとも、
   メタデータに格納されるとともに前記第１のオブジェクトタイプに関連付けられた第１のデータ取得関係を識別することと、
   前記第１のデータ取得関係を分析して、前記第１のオブジェクトタイプの記録に基づいて前記データキャッシュを更新するために第２のオブジェクトタイプの記録を取得するべきであると判定することと、
   前記第１のオブジェクトタイプの第１の複数の記録から、前記第１のオブジェクトタイプの第１のフィールドに対応する第１の複数の値を識別すること、とによって行なわれ、
   前記第１の複数の値は第１の値および第２の値を含み、前記以下の動作はさらに、
   １つ以上の問合せの第１のセットを生成して、
   （ａ）前記第２のオブジェクトタイプの第２の複数の記録のうち、前記第２のオブジェクトタイプの第２のフィールドに関係する前記第１の値を含む第１のサブセットと、
   （ｂ）前記第２のオブジェクトタイプの前記第２の複数の記録のうち、前記第２のオブジェクトタイプの前記第２のフィールドに関係する前記第２の値を含む第２のサブセットとを取得する動作と、
   前記１つ以上の問合せの第１のセットを実行して、前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得する動作と、
   前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新する動作とを含む、１つ以上の非一時的な機械可読媒体。
2. 前記以下の動作はさらに、
   前記第１の複数の値を識別する前に、
   前記第１のオブジェクトタイプのすべての記録に関して問合せを実行して、前記第１のオブジェクトタイプの前記第１の複数の記録を取得する動作を含む、請求項１に記載の１つ以上の非一時的な機械可読媒体。
3. 前記第１の複数の記録を取得する動作は、前記第１のオブジェクトタイプに依存しない（agnostic）、請求項２に記載の１つ以上の非一時的な機械可読媒体。
4. 前記１つ以上の問合せは、前記第２のオブジェクトタイプに依存しない、請求項１に記載の１つ以上の非一時的な機械可読媒体。
5. 前記第２のオブジェクトタイプの前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新する動作に応じて、前記第２のオブジェクトタイプに基づいて前記データキャッシュを再帰的に更新する動作を含み、前記更新する動作は、少なくとも、
   前記メタデータに格納されるとともに前記第２のオブジェクトタイプに関連付けられた第２のデータ取得関係を識別することと、
   前記第２のデータ取得関係を分析して、前記第２のオブジェクトタイプの記録に基づいて前記データキャッシュを更新するために第３のオブジェクトタイプの記録を取得するべきであると判定すること、とによって行なわれ、さらに、
   前記第２のオブジェクトタイプの前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットから第２の複数の値を識別する動作を含み、
   前記第２の複数の値は第３の値および第４の値を含み、さらに、
   １つ以上の問合せの第２のセットを生成して、
   （ａ）前記第３のオブジェクトタイプの第３の複数の記録のうち、前記第３のオブジェクトタイプの第３のフィールドに関係する前記第３の値を含む第１のサブセットと、
   （ｂ）前記第３のオブジェクトタイプの前記第３の複数の記録のうち、前記第３のオブジェクトタイプの前記第３のフィールドに関係する前記第４の値を含む第２のサブセットと、を取得する動作と、
   前記１つ以上の問合せの第２のセットを実行して、前記第３の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得する動作と、
   前記第３の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新する動作とを含む、請求項１に記載の１つ以上の非一時的な機械可読媒体。
6. 前記１つ以上の問合せは、前記第２のオブジェクトタイプを前記第１のオブジェクトタイプに関係付けるメタデータに基づいている、請求項１に記載の１つ以上の非一時的な機械可読媒体。
7. 前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得する動作は、ユーザによる前記第２の複数の記録のうち１つの記録についての要求の前に実行される、請求項１に記載の１つ以上の非一時的な機械可読媒体。
8. 前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得する動作は、データストアから前記第１の複数の記録のうちの少なくとも１つにアクセスするためにユニフォームリソースロケータ（uniform resource locator：ＵＲＬ）を指定する動作を含む、請求項１に記載の１つ以上の非一時的な機械可読媒体。
9. １つ以上のプロセッサによって実行されると、前記第２の複数の記録の各々を表わすように第２の持続エンティティを作成させる命令をさらに格納する、請求項１に記載の１つ以上の非一時的な機械可読媒体。
10. 前記第１の複数の記録の各々は第１の持続エンティティによって表わされ、
    前記第２の持続エンティティに従って前記第２の複数の記録を処理するのと同じ実行可能命令のセットが、前記第１の持続エンティティに従って前記第１の複数の記録を処理する、請求項９に記載の１つ以上の非一時的な機械可読媒体。
11. 前記第２のオブジェクトタイプの前記第２の複数の記録のうち前記第１のサブセットは、前記第１のオブジェクトタイプの前記第１の複数の記録に静的にリンクされている、請求項１に記載の１つ以上の非一時的な機械可読媒体。
12. 前記第２のオブジェクトタイプの前記第２の複数の記録のうち前記第１のサブセットは、前記第１のオブジェクトタイプの前記第１の複数の記録に動的にリンクされている、請求項１に記載の１つ以上の非一時的な機械可読媒体。
13. 再帰的データトラバースの方法であって、
    第１のオブジェクトタイプに基づいてデータキャッシュを更新するステップを含み、前記データキャッシュを更新するステップは、少なくとも、
    メタデータに格納されるとともに前記第１のオブジェクトタイプに関連付けられた第１のデータ取得関係を識別することと、
    前記第１のデータ取得関係を分析して、前記第１のオブジェクトタイプの記録に基づいて前記データキャッシュを更新するために第２のオブジェクトタイプの記録を取得するべきであると判定することと、
    前記第１のオブジェクトタイプの第１の複数の記録から、前記第１のオブジェクトタイプの第１のフィールドに対応する第１の複数の値を識別すること、とによって行なわれ、
    前記第１の複数の値は第１の値および第２の値を含み、前記方法はさらに、
    １つ以上の問合せの第１のセットを生成して、
    （ａ）前記第２のオブジェクトタイプの第２の複数の記録のうち、前記第２のオブジェクトタイプの第２のフィールドに関係する前記第１の値を含む第１のサブセットと、
    （ｂ）前記第２のオブジェクトタイプの前記第２の複数の記録のうち、前記第２のオブジェクトタイプの前記第２のフィールドに関係する前記第２の値を含む第２のサブセットと、を取得するステップと、
    前記１つ以上の問合せの第１のセットを実行して、前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得するステップと、
    前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新するステップと含む、方法。
14. 前記第１の複数の値を識別する前に、
    前記第１のオブジェクトタイプのすべての記録に関して問合せを実行して、前記第１のオブジェクトタイプの前記第１の複数の記録を取得するステップをさらに含む、請求項１３に記載の方法。
15. 前記第１の複数の記録を取得するステップは前記第１のオブジェクトタイプに依存しない、請求項１４に記載の方法。
16. 前記１つ以上の問合せは前記第２のオブジェクトタイプに依存しない、請求項１３に記載の方法。
17. 前記第２のオブジェクトタイプの前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新するステップに応じて、前記第２のオブジェクトタイプに基づいて前記データキャッシュを再帰的に更新するステップを含み、前記データキャッシュを再帰的に更新するステップは、少なくとも、
    メタデータに格納されるとともに前記第２のオブジェクトタイプに関連付けられた第２のデータ取得関係を識別することと、
    前記第２のデータ取得関係を分析して、前記第２のオブジェクトタイプの記録に基づいて前記データキャッシュを更新するために第３のオブジェクトタイプの記録を取得するべきであると判定することと、
    前記第２のオブジェクトタイプの前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットから第２の複数の値を識別すること、とによって行なわれ、
    前記第２の複数の値は第３の値および第４の値を含み、さらに、
    １つ以上の問合せの第２のセットを生成して、
    （ａ）前記第３のオブジェクトタイプの第３の複数の記録のうち、前記第３のオブジェクトタイプの第３のフィールドに関係する前記第３の値を含む第１のサブセットと、
    （ｂ）前記第３のオブジェクトタイプの前記第３の複数の記録のうち、前記第３のオブジェクトタイプの前記第３のフィールドに関係する前記第４の値を含む第２のサブセットと、を取得するステップと、
    前記１つ以上の問合せの第２のセットを実行して、前記第３の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得するステップと、
    前記第３の複数の記録の前記第１のサブセットおよび前記第２のサブセットで前記データキャッシュを更新するステップとを含む、請求項１３に記載の方法。
18. 前記１つ以上の問合せは、前記第２のオブジェクトタイプを前記第１のオブジェクトタ
    イプに関係付けるメタデータに基づいている、請求項１３に記載の方法。
19. 前記第２の複数の記録の前記第１のサブセットおよび前記第２のサブセットを取得するステップは、ユーザによる前記第２の複数の記録のうち１つの記録についての要求の前に実行される、請求項１３に記載の方法。
20. 前記第２の複数の記録の各々を表わすように第２の持続エンティティを作成するステップをさらに含み、
    前記第１の複数の記録の各々は、第１の持続エンティティによって表わされ、
    前記第２の持続エンティティに従って前記第２の複数の記録を処理するのと同じ実行可能命令のセットが、前記第１の持続エンティティに従って前記第１の複数の記録を処理する、請求項１３に記載の方法。

Images