JP2016537697A - オフライン可能なモデルグラフを定義するための方法およびシステム - Google Patents

Abstract

オフライン可能なモデルグラフを定義するための方法およびシステムである。この方法の一実施形態では、モバイル装置によって要求が生成される。モバイル装置は、要求に対する応答を受信する。モバイル装置は、モバイル装置のメモリに格納された複数のテーブルを更新し、更新するステップは、応答のコンポーネントを複数のテーブルのうちの第１のテーブルに追加するステップを含む。

Description

関連出願
本願は、「オフライン可能なモデルグラフを定義するための方法およびシステム」（Method and System for Defining an Offlinable Model Graph）と題され、２０１３年９月２１日に出願された米国仮特許出願連続番号第６１／８８０，９０１号、ならびに「オフライン可能なモデルグラフを定義するための方法およびシステム」と題され、２０１３年１０月３１日に出願された米国特許出願連続番号第１４／０６８，７９０号の、米国特許法第１１９条（ｅ）による国内利益を主張する。当該出願は全体として、およびあらゆる目的のために、ここに完全にかつ十分に述べられているかのようにこれによって引用により援用される。

発明の背景
企業アプリケーションは、顧客関係管理（customer relationship management：ＣＲＭ）、資源計画、人材管理などを含む有益なサービスを企業に提供する。この発明は、セールスサービスおよびマーケティングサービスを提供する例示的なＣＲＭに関して説明されるが、この発明はそれに限定されるべきでないということが理解されるであろう。

ＣＲＭは、会社と顧客とのやりとりを管理するために広く実施されている戦略である。ＣＲＭサービスは、モバイル装置（たとえば、スマートフォンまたはタブレットコンピュータ）を通してアクセスされ得る。この発明は、ユーザのモバイル装置を介してユーザにＣＲＭサービスを提供することに関して説明されるが、この発明はそれに限定されるべきでないということが理解されるであろう。

要約
オフライン可能なモデルグラフを定義するための方法およびシステムである。この方法の一実施形態では、モバイル装置によって要求が生成される。モバイル装置は、要求に対する応答を受信する。モバイル装置は、モバイル装置のメモリに格納された複数のテーブルを更新し、更新するステップは、応答のコンポーネントを複数のテーブルのうちの第１のテーブルに追加するステップを含む。

モバイルＣＲＭを採用する例示的なシステムの関連コンポーネントを示すブロック図である。 図１で採用された例示的なサーバの関連コンポーネントのブロック図である。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 例示的なモバイル装置の関連コンポーネントを示すブロック図である。 図６で採用されたモバイル装置上のメモリにおける例示的なデータストアを図式化した図である。 図６で採用されたモバイル装置上のメモリにおける例示的なデータストアを図式化した図である。 図６で採用されたモバイル装置上のメモリにおける例示的なデータストアを図式化した図である。 図６で採用されたモバイル装置上のメモリにおける例示的なデータストアを図式化した図である。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートである。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートである。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートの一部である。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートの一部である。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートである。 図６のモバイル装置によって実施されるプロセスの関連局面を示すフローチャートである。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。 図１で採用されたモバイル装置上に表示される例示的なページを図式化した図である。

異なる図面における同じ参照符号の使用は、同様または同一の項目を示す。
詳細な説明
今日のセールス労働力は、かつてないほどモバイルである。モバイルのセールス労働力をよりよく支援するために、多くの企業がモバイルＣＲＭを採用しており、それは、ユーザが、モバイル装置上に表示されるユーザインターフェイスまたは「ビュー」を通して、セールス案件（sales opportunities）、セールスアカウント、連絡先、行事予定などを作成し、見直し、および／または更新するといったＣＲＭサービスをより効率的に使用できるようにする。

図１は、モバイルＣＲＭを提供する例示的なシステム１００の関連コンポーネントをブロック図の形で示す。システム１００は、サーバ１０６上で実行されるＣＲＭと無線データ通信するモバイル装置（たとえば、スマートフォン）１０４を含む。ＣＲＭによって提供されるサービスは、モバイル装置１０４によって表示されるビューを通してアクセスされ得る。

一実施形態では、ＣＲＭは、モデル・ビュー・コントローラ・アーキテクチャを実現する。ＣＲＭは、モバイル装置１０４によって表示され得るビューの基礎を形成する複数のページ定義を含む状態駆動アプリケーションを含む。モバイル装置１０４からのビュー要求の受信に応答して、ＣＲＭは、論理データモデルからのコンポーネント（たとえば、アカウント名、連絡先名など）を、選択されたページ定義と併合または結合し、その結果が、追加処理（たとえば、ユニバーサルリソースロケータ（universal resource locator：ＵＲＩ）挿入、アーカイビング、レンダリングおよび／またはシリアライゼーション（serialization））後に返答でビュー定義としてモバイル装置１０４に送信される。モバイル装置１０４はビュー定義を受信し、表示のためにレンダリングする。説明の目的のため、この開示は、モバイル装置によって受信されたどのビュー定義も、レンダリングおよび次の表示のための状態にある併合されたコンポーネント（たとえば、アカウント名、連絡先名など）を含む、と仮定する。モバイル装置は、ビュー定義が次の表示のためにレンダリングされる前に、前処理（たとえば、デシリアライゼーション、データ一致、ローカルストレージ更新など）を行なってもよい。

図１を引き続き参照して、図２は、関連コンポーネントがブロック図の形で示されたサーバ１０６の一例を示す。メモリ２０２は、ＣＲＭのためのアプリケーション定義を格納する。アプリケーション定義はページ定義を含み、それらのうちのいくつかはメモリ２０２に表わされる。論理データモデル内のミニアプリケーションまたは高レベルビジネスオブジェクトへのユーザアクセスを可能にする、モバイル装置上での表示用のスプリングボードビューをレンダリングするために、「スプリングボード」ページ定義が使用可能である。アカウント、案件および連絡先の名前をそれぞれリストフォーマットで提示する、モバイル装置上での表示用のビューをレンダリングするために、「アカウント集合（Accounts）」、「案件集合（Opportunities）」および「連絡先集合（Contacts）」ページ定義が使用可能である。アカウント、案件および連絡先についての詳細な情報をそれぞれあるフォームフォーマットで提供する、表示用のビューをレンダリングするために、「アカウント（Account）」、「案件（Opportunity）」および「連絡先（Contact）」ページ定義が使用可能である。アカウント、案件および連絡先についての情報をそれぞれユーザが編集可能なフォームで提供する、表示用のビューをレンダリングするために、「アカウントフォーム」、「案件フォーム」および「連絡先フォーム」ページ定義が使用可能である。メモリ２０２における他のページ定義が考えられる。一般に、ページ定義は、論理データモデル２０４を、モバイル装置上に表示されるビューを介したモバイル装置のユーザによるやりとりにとってより好適なフォームへとレンダリングするために使用可能である。ある意味では、論理データモデル２０４は、アカウント集合、連絡先集合、案件集合などを含むビジネスオブジェクトへのアクセスを提供しており、それらのうちのいくつかを図２に示す。

メモリ２０２におけるアプリケーション定義は、Ｊａｖａ（登録商標）サーバ・フェイシズ（Java Server Faces：ＪＳＦ）技術を使用して構築される状態駆動アプリケーションとして実現可能であるが、この発明はそれに限定されるべきでないということが理解されるであろう。ＪＳＦは、ビューのためのページを作成するための再使用可能な標準コンポーネントを提供する。ＪＳＦは、ビュー定義を増強するための有用な特殊タグを提供する。以下により十分に説明されるように、この発明は、ビュー定義がモバイル装置に送信される前に新しいタイプのタグ（たとえばＵＲＩ）をビュー定義に挿入することを可能にする新しい特徴を用いて、ＪＳＦ（または、状態駆動アプリケーションを構築するための同様の技術）を拡張することができる。これらの新しいタグは、以下により十分に説明されるように、複数の特徴を可能にする。たとえば、モバイル装置が「オフライン」である場合、またはＣＲＭとのデータ通信を欠く場合に、タグはモバイル装置がビューからモデルデータを抽出することを可能にし、また、タグはモバイル装置がビューを表示することを可能にする。

プロセッサ上で実行される命令の形を取り得る制御論理２０６は、アプリケーション定義とデータ通信する。制御論理２０６は、インターフェイス２０８を介してモバイル装置１０４からビュー要求を受信できる。ビュー要求の受信に応答して、制御論理２０６は、返答を作成するのに適切なページ定義を選択するために、メモリ２０２におけるアプリケーション定義またはビューナビゲーションスタック（図示せず）にアクセスしてもよい。ページ定義は、ビュー要求に含まれる情報および他の情報に基づいて選択され得る。

ページ定義は、論理データモデル２０４から返答を作成するために必要とされるコンポーネント（たとえば、アカウント名、連絡先名など）を選択するために使用され得るメタデータを含む。制御論理２０６は、必要とされるビューコンポーネントを検索するために、論理データモデル２０４に呼出しを行なうことができる。制御論理２０６は次に、選択されたページ定義を検索されたコンポーネントと結合または併合でき、その結果が、何らかの追加処理後に返答でビュー定義として要求元のモバイル装置に送信される。返答はまた、以下により十分に説明されるアーカイブを含んでいてもよい。図３〜５は、ＣＲＭからの返答での対応するビュー定義の受信に応答してモバイル装置１０４によって表示される例示的なビューを示す。

図２を引き続き参照して、図３は、ユーザがＣＲＭとのモバイルセッションを初めて呼出したことに応答してモバイル装置１０４のタッチセンシティブスクリーン３００上に表示される例示的なビュー３０２を示す。より特定的には、ユーザがモバイルセッションを最初に呼出すと、モバイル装置１０４は、スプリングボードビューに対する要求を生成して送信する。要求の受信に応答して、制御論理２０６は、メモリ２０２におけるスプリングボードページ定義を選択する。何らかの処理後、制御論理２０６は、返答でスプリングボードビュー定義をモバイル装置に送信する。返答を受信後、モバイル装置１０４は、アクション可能なスプリングボードビューコンポーネント３０６〜３１０を有するビュー３０２を受信し、次に表示する。

スプリングボードビュー３０２がモバイル装置１０４によって表示されると、ユーザは、スプリングボードビューコンポーネント３０６〜３１０の起動を介して、モバイル装置１０４上での表示用の追加のビューを要求できる。例示すると、ユーザは、見直しのために連絡先集合リストを検索するために、「連絡先集合」を起動できる。連絡先集合の起動に応答して、モバイル装置１０４は、連絡先集合リストビューに対する要求を生成してＣＲＭに送信する。ビュー要求は、ＣＲＭとモバイル装置１０４とのセッションを一意的に識別するセッション識別または他の情報を含んでいてもよい。ＣＲＭおよび／または制御論理２０６は、それぞれのモバイル装置のためのビューナビゲーションスタックを管理するためにセッション識別を使用でき、それらは次に、返答を形成するために必要とされる適当なページ定義およびコンポーネントを選択するために使用され得る。

例示された例を続けると、制御論理２０６は、モバイル装置１０４から連絡先集合リストビュー要求を受信し、それに応答して、メモリ２０２から連絡先集合リストページ定義を選択する。制御論理２０６は、返答のために必要とされる、モデル２０４からのコンポーネント（たとえば、連絡先名）を選択して併合する。コンポーネント選択は、選択されたページ定義における情報および／または他の情報に基づいていてもよい。現在の例では、制御論理２０６は、連絡先集合ページ定義によって直接的にまたは間接的に識別された連絡先名を選択する。選択され検索されたコンポーネントは、ビュー定義を作成するために、制御論理２０６によって連絡先集合ページ定義と併合される。作成の際、ビュー制御論理２０６はまた、ページ定義、ページ定義との併合のために選択されたコンポーネントなどに基づいてＵＲＩを選択的にかつ論理的に挿入してもよく、それからビュー定義は返答でモバイル装置に送信される。制御論理２０６は、何らかの追加処理後に連絡先集合ビュー定義を含む返答をモバイル装置１０４に送信する。この追加処理は、アーカイブを返答に追加することを含んでいてもよい。アーカイブは、１つ以上の追加の既存ビュー定義、または制御論理２０６によって作成されたビュー定義を含んでいてもよい。

挿入されたＵＲＩを含む、返答でモバイル装置１０４に送信された例示的な連絡先集合リストビュー定義の関連部分を、以下に提供する。

連絡先集合リストビュー定義

連絡先集合ビュー定義を含むことに加えて、制御論理２０６によって送信された返答は、連絡先集合動的クライアントビュー（dynamic client view：ＤＣＶ）を含むアーカイブも含んでいてもよい。以下により十分に説明されるように、ＤＣＶは、モバイル装置がオフラインである間、またはＣＲＭとのデータ通信を欠く間に、モバイル装置上で実行されると、モバイル装置が動的ビューを作成して表示することを可能にする、実行可能な命令またはステートメント（たとえば、ＥＬステートメント）を含む。ＤＣＶは、モバイル装置がオフラインモードにある間、モバイル装置が、ローカルに格納された連絡先集合、アカウント集合、案件集合などのコンポーネントを（たとえばアルファベット順に）ソートして表示すること、ローカルに格納されたコンポーネントを検索してその結果を表示することなどを可能にし得る。連絡先集合ビュー要求に対する例示された返答のアーカイブに含まれる例示的な連絡先集合ＤＣＶの関連部分を、以下に提供する。

連絡先集合ＤＣＶ

アーカイブのコンテンツは、少なくとも最初は、表示のためにレンダリングされていない。むしろ、それらは、以下により十分に説明されるように、モバイル装置上のメモリに格納され得る。ＤＣＶはビュー定義として識別され得るが、ＤＣＶはレンダリングされず、モバイル装置上に表示されない。むしろ、ＤＣＶは、モバイル装置がオフライン状態にある間、次のレンダリングおよび表示のためのビューを生成するために実行され得る。

図４は、モバイル装置１０４がＣＲＭから例示された返答を受信した後に表示する、例示的な連絡先集合リストビュー４０２を示す。ビューに表示される多くのコンポーネントは、アクション可能である。たとえば、「Labron James」というコンポーネントは、Labron Jamesについての連絡先詳細を提供する対応するビューを要求するために、ユーザ起動され得る（たとえば「クリックされ得る」）。例示すると、起動に応答して、モバイル装置１０４は、Labron James詳細ビューに対する要求を生成してＣＲＭに送信する。制御論理２０６はこの要求を受信し、この要求における情報に基づいて連絡先ページ定義を選択する。制御論理２０６は、連絡先ページ定義によって直接的にまたは間接的に識別されたコンポーネント（たとえば、連絡先に関連付けられたアカウント名）を選択する。選択されたコンポーネントは連絡先ページ定義と併合され、ＵＲＩが追加され、その結果が何らかの追加処理後に返答でモバイル装置１０４に送信される。モバイル装置１０４によって受信されたLabron Jamesについての例示的な連絡先ビュー定義の関連部分を、以下に提供する。

Labron James連絡先ビュー定義

図１および図２を引き続き参照して、図５は、モバイル装置１０４がＣＲＭから返答を受信してレンダリングした後に表示するLabron James連絡先ビュー５０２の一例を示す。ビュー５０２は、あるフォームフォーマットで表示された詳細連絡先コンポーネントを示す。ビュー５０２は、図４に示すビュー４０２など、モバイル装置１０４によって表示される他のビューの外観および雰囲気を有する。たとえば、ビュー４０２および５０２は双方とも、前のビューへと逆戻りしてナビゲートするために使用され得る「戻る」ボタンを含む。ビュー５０２の「戻る」ボタンが起動されると、モバイル装置１０４は、「戻る」要求を生成してＣＲＭに送信するであろう。一実施形態では、いずれかのビューにおけるいずれかの「戻る」ボタンが起動されるたびに、同じ包括的な「戻る」要求がモバイル装置１０４によって送信される。「戻る」要求に応答して、制御論理２０６は、ビューナビゲーションスタックから最後の項目を取出すことができ、その項目はビュー５０２に関連する情報を含む。次に、制御論理２０６は、最も新しく追加されたスタック項目におけるページ定義（たとえば、連絡先集合ページ定義）と、モデルからのコンポーネントとを使用して、ビュー４０２をもたらした返答を再作成することができる。返答は、モバイル装置１０４への次の送信のために再作成される。ビューの再表示は、その間に変化した論理データモデルからのあらゆるコンポーネントを除き、同じであるべきである。

上述の連絡先集合ビュー定義の例および連絡先集合ＤＣＶの例と同様に、Labron James連絡先ビュー定義の例は、ビューＵＲＩ、ターゲットビューＵＲＩ、およびモデルＵＲＩなどのＵＲＩを含む。より十分に説明されるように、モバイル装置１０４のようなモバイル装置は、ビューのオフラインレンダリングおよび表示を可能にするために、上述の連絡先集合ＤＣＶ、連絡先集合リストビュー定義、およびLaBron James連絡先ビュー定義の例のようなＣＲＭからのビュー定義およびＤＣＶをローカルメモリに格納できる。

ビューＵＲＩおよびターゲットビューＵＲＩは、ユーザのモバイル装置がオフラインである間、ユーザが自分のモバイル装置上でビュー間をナビゲートできるようにする、ビュー間の関係を定義するビューグラフを提供できる。ターゲットビューＵＲＩは、ビュー定義内のアクション可能なコンポーネントにリンクされる。たとえば、上述の「Acme Bike Corp」というコンポーネントは、「view:/accounts/201#detail」というターゲットビューＵＲＩにリンクされる。モバイル装置がオフラインである間にユーザが表示されたビューコンポーネントをクリックすると、ターゲットビューＵＲＩにリンクされたビュー定義がローカルメモリから検索され、次に表示のためにレンダリングされ得る。

モデルＵＲＩは、モバイル装置１０４のメモリにおけるモデルグラフを可能にする。一実施形態では、モデルグラフは、ＳＱＬステートメントによってアクセス可能なデータベーステーブルの形を取ってもよい。モデルグラフは、モバイル装置１０４がオフラインである間、モバイル装置が、複合ビュー定義を作成すること、コンポーネントを検索して結果を表示すること、コンポーネントをソートして結果を表示すること、コンポーネントを一致させることなどをできるようにする。

大抵の場合、図１に示すモバイル装置１０４などのモバイル装置は、サーバ１０６上で実行されるＣＲＭなどのＣＲＭとデータ通信する。「オンライン」またはデータ通信中、モバイル装置は、次のレンダリングおよび表示のためにＣＲＭからビュー定義を受信できる。しかしながら、ＣＲＭとモバイル装置とのデータ通信は、自発的にまたは非自発的に中断される場合がある。たとえば、モバイル装置１０４は、ユーザが無線通信を自発的に不能にできるようにする特徴（たとえば「機内モード」）を有する場合があり、または、モバイル装置は、通信塔から遠過ぎて無線信号通信を交換できない場合がある。

図６は、この発明の一実施形態に従った、ＣＲＭデータおよび／またはサービスへのオフラインアクセスを可能にするモバイル装置１０４の関連コンポーネントを示す。より特定的には、図６は、ビューコントローラ６０２およびモバイルＣＲＭクライアント６０６とデータ通信するビュー要求ハンドラ６０４をブロック図の形で示す。一実施形態では、コンポーネント６０２〜６０６は、モバイル装置１０４の１つ以上のプロセッサ上で実行される命令の形を取ってもよい。加えて、図６は、ファイルシステム６１２とデータストア６１４とを格納するように構成されたメモリ６１０を示す。一実施形態では、ファイルシステム６１２はビューコントローラ６０２によってアクセス可能であり、それぞれのＵＲＬまたはアドレスによって識別されたそれぞれのファイルにビュー定義を格納するように構成される。データストア６１４は、以下により十分に説明されるビューテーブルなどの１つ以上のテーブルを格納するデータベースの形を取ってもよい。データベーステーブルはビューコントローラ６０２によってアクセス可能であり、上述のモデルグラフを格納するように構成される。

図７Ａは、初期状態または空の状態でデータストア６１４に格納された、テーブル７０２〜７２０を含む例示的なテーブルを示す。他の実施形態では、追加のまたはより少ないテーブルが考えられる。ビューテーブル７０２は、ビューＵＲＩを、ビューＵＲＩに対応するビュー定義を格納するファイルシステム６１２におけるファイルのためのＵＲＬにマッピングする。テーブル７０４〜７２０は、モデルＵＲＩを格納する。収集テーブル７０４およびエンティティテーブル７０６といった、これらのテーブルのうちのいくつかは、モデルＵＲＩを１つだけ有するエントリを含む。残りのテーブル７１０〜７２０は、モデルＵＲＩを、他のモデルＵＲＩ、値（たとえば、ビューコンポーネント）、および／またはビューＵＲＩにマッピングするエントリを含む。たとえば、フィールドテーブル７１０は、フィールドＵＲＩを、フィールド名ＵＲＩ、コンポーネント値、およびソースＵＲＩにマッピングする。なお、フィールドテーブル７１０内では、フィールドＵＲＩは、値またはソースＵＲＩのいずれかにマッピングされるが、双方にはマッピングされない。収集＿エンティティテーブル７１２、エンティティ＿フィールドテーブル７１４、収集＿ビューテーブル７１６、およびエンティティ＿ビューテーブル７２０は、モデルＵＲＩまたはビューＵＲＩをマッピングする１対多の交差テーブルである。これらのテーブルは、それらのタイトルによって示されるようにＵＲＩをマッピングする。言い換えれば、収集＿エンティティテーブル７１２は収集ＵＲＩをエンティティＵＲＩにマッピングし、エンティティ＿ビューテーブル７２０は、エンティティＵＲＩをビューＵＲＩにマッピングする。

モバイルＣＭＲクライアント６０６は、表示されたアクション可能なビューコンポーネントのユーザ起動に応答して、上述の連絡先集合リストビューに対する要求など、ビューに対する要求を生成する。モバイル装置１０４がオンラインであるかまたはサーバ１０６とデータ通信する場合、要求ハンドラ６０４は要求を受信して、要求をＣＲＭに転送するように構成される。その他の場合、以下により十分に説明されるように、要求ハンドラ６０４はビュー要求をビューコントローラ６０２に転送する。

図８は、ＣＲＭデータおよび／またはサービスへのオフラインアクセスを可能にするためにビューコントローラ６０２および要求ハンドラ６０４によって採用される例示的なプロセスを示す。このプロセスは、モバイル装置１０４のユーザがレンダリングされたビュー定義の表示されたアクション可能なビューコンポーネントを起動する（たとえばクリックする）と、始まる。起動されたビューコンポーネントは、ターゲットビューＵＲＩを介して別のビュー定義にリンクされると仮定される。ユーザ起動に応答して、モバイルＣＲＭ６０６は、起動されたビューコンポーネントに対応するビュー要求を生成する。起動されたコンポーネントにリンクされたビュー定義が、要求ハンドラ６０４によって受信された要求に含まれていてもよい。

ビュー要求が受信されると、要求ハンドラ６０４は、モバイル装置１０４がオンラインモードで動作するかオフラインモードで動作するかを判断する。モバイル装置１０４がオンラインモードで動作する場合、プロセスは、要求ハンドラ６０４がビュー要求をサーバ１０６に送信するステップ８０６に進み、最終的に、ビューコントローラ６０２は、要求されたビューのためのビュー定義を含む返答を受信するであろう。加えて、返答は、上述の例示的な連絡先集合ＤＣＶなどのＤＣＶを含む追加のビュー定義を含むアーカイブを含んでいてもよい、最初、アーカイブ内に含まれるビュー定義は表示されない。しかしながら、それらは、受信されると、データストア６１４および／またはファイルシステム６１２を更新するために使用される。

ステップ８１０で、ビューコントローラ６０２は、ファイルシステム６１２およびデータストア６１４を返答ビュー定義のコンテンツで更新する。ファイルシステム６１２およびデータストア６１４をビュー定義のコンテンツで更新するための例示的な手順は、図１１および図１２を参照してより十分に説明されるであろう。ビューコントローラ６０２がファイルシステム６１２およびデータストア６１４を一旦更新すると、図８に示すプロセスは、返答がアーカイブを含むかどうかをビューコントローラ６０２が判断するステップに進む。アーカイブが返答に含まれる場合、ビューコントローラ６０２は、図１１および図１２に示すプロセスを使用して、ファイルシステム６１２およびデータストア６１４をアーカイブにおける各ビュー定義で更新する。返答がアーカイブを欠く場合、８１６に示すように、返答のビュー定義は、レンダリングおよび次の表示のためにモバイルＣＲＭクライアント６０６に提示され、プロセスは終了する。

オフラインモードにある間にプロセスハンドラ６０４がモバイルＣＲＭクライアント６０６からビュー要求を受信すると、要求ハンドラ６０４は要求をビューコントローラ６０２に転送し、それは次に、ビュー要求のビューＵＲＩにマッピングされたＵＲＬを読出すためにビューテーブル７０２にアクセスする。このＵＲＬを使用して、ＵＲＬによって識別されたファイルに含まれるビュー定義がファイルシステム６１２から読出され、ビューコントローラ６０２に提供される。ステップ８２２に示すように、ビューコントローラ６０２は、ビュー定義がＤＣＶであるかどうかを判断する。ＤＣＶではない場合、ビューコントローラ６０２は、レンダリングおよび表示のためにビュー定義をモバイルＣＲＭクライアントに転送する。一実施形態では、ビューコントローラがビュー定義を転送する前に、ビューコントローラ６０２は、以下により十分に説明されるような図１４に示す例示的な一致プロセスなどの一致プロセスを使用して、ビュー定義におけるコンポーネントをデータストア６１４におけるコンポーネントと一致させることができる。

ファイルがＤＣＶを含む場合、図８に示すプロセスは、ＤＣＶがビューコントローラ６０２によって実現されるステップ８２４に進む。図示されていないものの、ビューコントローラは、ＤＣＶの命令を実行するエンジン（たとえば、ＥＬエンジン）を含んでいてもよい。さらに、図示されていないものの、ビューコントローラ６０２は、データストア６１４内のテーブルにアクセスするために使用されるクエリー（たとえば、ＳＱＬクエリー）を生成するデータベース管理システムを含んでいてもよい。これらのクエリーのうちのいくつかは、ＥＬエンジンによって実行された命令に従って、ＥＬエンジンによって生成され得る。ＤＣＶを実行する間、ビューコントローラ６０２は結果ビュー定義を生成でき、それは次に、次のレンダリングおよび表示のためにモバイルＣＲＭ６０６に提供される。

上述のように、図１１および図１２は、図８のステップ８１０または８１４でのファイルシステム６１２およびデータストア６１４を更新するための例示的なプロセスを示す。図１１におけるプロセスは、ビューテーブル７０２およびファイルシステム６１２を更新するために使用される。図１２におけるプロセスは、データストア６１４におけるテーブルを更新するために使用される。

図１１に示すプロセスは、ビューコントローラ６０２がビューテーブル７０２にアクセスして、それがビュー定義の各ターゲットビューＵＲＩのためのエントリを含むかどうかを判断することで始まる。ステップ１１０４で、ビューコントローラは、ビュー定義内に含まれる各新規ターゲットビューＵＲＩのために、ビューテーブル７０２において新規エントリを作成する。言い換えれば、ビューテーブル７０２がビュー定義のターゲットビューＵＲＩのためのエントリを欠く場合、ビューコントローラ６０２は、新規ターゲットビューＵＲＩが追加されるビューテーブルにおいて新規エントリを作成する。最終的に、ビュー定義のターゲットビューＵＲＩが処理された後で、プロセスは、ビューテーブルがビュー定義のためのビューＵＲＩを含むかどうかをビューコントローラ６０２が判断するステップ１１０６に進む。ビューテーブルがこのＵＲＩを欠く場合、ビューコントローラは、ビューＵＲＩが追加されるビューテーブルにおいて新規エントリを作成する。ビューコントローラ６０２は、当該ビュー定義のコピーをファイルシステム６１２に格納する。ビューコントローラ６０２は次に、ビューＵＲＩを、ビュー定義コピーが格納されたファイルのためのＵＲＬにマッピングする。その後、プロセスは図１２に進み、それは以下により十分に説明される。

しかしながら、ステップ１１０６で、ビューテーブル７０２がビュー定義のためのビューＵＲＩを含むと判断される場合、プロセスは、ビューコントローラ６０２がビューテーブルにアクセスして、ＵＲＬがビュー定義のためのＵＲＩにマッピングされているかどうかを確かめるステップ１１２０に進む。このＵＲＩにマッピングされたＵＲＬがある場合、プロセスは、ＵＲＬによって識別されたコンテンツがビュー定義で上書きされるステップ１１２６に進む。なお、このステップでは、上述の例示的な連絡先集合ＤＣＶなどのＤＣＶが、上述の連絡先集合リストビュー定義の例などのビュー定義を上書きしてもよい（双方の定義がサーバ１０６からの同じ返答に含まれる場合）。

ビューテーブルがビュー定義のビューＵＲＩにマッピングされたＵＲＬを欠く場合、ビューコントローラ６０２はＵＲＬによって識別されたファイルにビュー定義を格納し、ビューコントローラ６０２はビューテーブルにおいてＵＲＬをビューＵＲＩにマッピングする。ステップ１１２４の後、またはステップ１２２６でのビュー定義の前のバージョンの上書きに応答して、ビューコントローラ６０２は、以下により十分に説明される図１２に示すプロセスに従って、ビュー定義のモデルＵＲＩを処理する。

図１２は、モデルＵＲＩテーブルをビュー定義のコンテンツで更新するための例示的なプロセスを示す。モデルテーブルは、オフライン検索、オフラインソーティング、オフラインコンポーネント一致、動的ビューのオフライン作成などを含む、オフラインモバイルＣＲＭ処理の多くの特徴を可能にする。上述の例示的なLabron James連絡先定義に関して、図１２のプロセスは、ビューコントローラ６０２がビュー定義の第１のエントリ（たとえば、コンポーネント「Labron James」を含むエントリ）を選択すると始まる。なお、一実施形態では、ビュー定義の各エントリは、「Labron James」などの単一のビュー定義コンポーネントを含む。

ステップ１２０４で、ビューコントローラ６０２は、選択されたコンポーネントの第１のモデルＵＲＩを選択する。これは、フィールドＵＲＩ、フィールド名ＵＲＩ、ソースＵＲＩ、エンティティＵＲＩ、または収集ＵＲＩであり得る。他のモデルＵＲＩが考えられる。ビューコントローラ６０２は、選択されたモデルＵＲＩのタイプを判断できる。選択されたモデルＵＲＩがフィールドＵＲＩである場合、プロセスは、ビューコントローラ６０２が選択されたモデルＵＲＩをフィールドＵＲＩとしてフィールドテーブル７１０に追加する（テーブルが、選択されたモデルＵＲＩを有するエントリを既に含む場合を除く）ステップ１２１０に進む。ステップ１２１２で、ビューコントローラは、選択されたエントリがソースフィールドＵＲＩを含むかどうかをステップ１２１２で判断する。含まない場合、ビューコントローラ６０２は、選択されたビュー定義エントリのコンポーネント値およびフィールド名ＵＲＩをフィールドＵＲＩに追加してマッピングする。

ステップ１２１２で、選択されたビュー定義エントリがソースフィールドＵＲＩを有するとビューコントローラ６０２が判断した場合、ステップ１２１４〜１２２０が実施される。これらのステップは、以下により十分に説明されるであろう図１４に示すプロセスに従って値を一致させるようにフィールドテーブルを構成する。ステップ１２１４で、ビューコントローラ６０２は、必要であれば、フィールドテーブルにおいてソースフィールドＵＲＩをフィールドＵＲＩにマッピングする。なお、図１２内に示すプロセスの以前の実施により、ステップ１２１４より前に、テーブル内においてフィールドＵＲＩがソースＵＲＩにマッピングされてもよい。ステップ１２１６で、ビューコントローラ６０２は、選択されたエントリのソースフィールドＵＲＩをフィールドＵＲＩとしてフィールドテーブルに追加する（ステップ１２１６より前にソースフィールドＵＲＩがフィールドＵＲＩとしてビューテーブルに存在する場合を除く）。ステップ１２２０で、選択されたビュー定義エントリのコンポーネントおよびそのフィールド名ＵＲＩが、フィールドＵＲＩ列にソースフィールドＵＲＩを含むビューテーブルエントリに追加される。一実施形態では、フィールドテーブルにおける既存のコンポーネント値は、選択されたエントリのコンポーネント値で更新される（これらのコンポーネント値が異なる場合）。ステップ１２２０または１２２６に応答して、ビューコントローラ６０２は、選択されたモデルＵＲＩを選択されたビュー定義エントリのエンティティＵＲＩにマッピングするエンティティ＿フィールドテーブル７２４に、新規エントリを追加する（エントリが以前にテーブルに含まれていた場合を除く）。

ステップ１２０６で、選択されたモデルＵＲＩがフィールドＵＲＩではないと判断された場合、プロセスは、選択されたモデルＵＲＩが収集ＵＲＩであるかどうかをビューコントローラ６０２が判断するステップ１２２４に進む。収集ＵＲＩである場合、ビューコントローラはステップ１２２８〜１２３２を実施する。収集ＵＲＩではない場合、プロセスは、選択されたＵＲＩがエンティティＵＲＩであるかどうかをビューコントローラ６０２が判断するステップ１２３４に進む。この条件が満たされると仮定すると、ステップ１２３６〜１２４２が実施される。エンティティＵＲＩではない場合、またはステップ１２４２の実施に応答して、ステップ１２４４でビューコントローラ６０２は、選択されたビュー定義エントリ内に追加のモデルＵＲＩが含まれるかどうかを判断する。別のモデルＵＲＩがある場合、それはステップ１２５０で選択され、ステップ１２０６〜１２４４が、新たに選択されたモデルＵＲＩで繰り返される。選択されたビュー定義エントリにモデルＵＲＩがこれ以上ない場合、ビューコントローラ６０２は、ビュー定義が追加のエントリを含むかどうかを判断する。追加のエントリを含む場合、ステップ１２５２で次のエントリが選択され、ステップ１２０４〜１２４６が、新たに選択されたビュー定義エントリで繰り返される。

図７Ｂは、ビューコントローラ６０２が図８、図１１および図１２に従って上述の例示的な連絡先集合リストビュー定義の例を処理した後の、図７Ａにおけるデータストアを示す。連絡先集合リストビュー定義の例を含む例示された例の返答は、上述の例示的なＤＣＶを有するアーカイブも含む。図８の処理に従って、ＵＲＬ＝file://…contacts#listによって識別されたファイルは、最初は連絡先集合リストビュー定義を含むものの、後で例示的なＤＣＶで上書きされるであろう。図７Ｃは、ビューコントローラ６０２が図８、図１１および図１２に従って上述の例示的なLabron James連絡先ビュー定義を処理した後の、図７Ｂにおけるデータストアを示す。

図７Ｃには図示されていないが、モバイル装置１０４のファイルシステム６１２は、図３に示すスプリングボードビューのためのビュー定義を格納する。モバイル装置１０４がオフラインモードにある間、このビュー定義はレンダリングされ、モバイル装置１０４上に表示され得る。この表示されたスプリングボードビューは、図３に示すものと同様であるべきである。ビューコントローラ６０２、ファイルシステム６１２、およびデータストア６１４は、モバイル装置１０４上でのビューのオフライン表示を含むオフラインＣＲＭサービスを可能にする。例示するために、モバイル装置１０４がオフラインモードにある間、モバイル装置１０４のユーザがスプリングボードの「連絡先集合」（図３参照）を起動すると仮定する。これに応答して、モバイルＣＲＭクライアント６０６は、連絡先集合ビュー定義に対する要求を生成する。この要求は、レンダリングされたスプリングボードビュー定義の連絡先集合ビューコンポーネントにリンクされたビューＵＲＩ（すなわち、views://contacts#list)を含むであろう。モバイル装置１０４はオフラインであるため、要求ハンドラ６０４は、図８に示すプロセスに従って、モバイルＣＲＭクライアントからビューコントローラ６０２に要求を転送するであろう。これに応答して、ビューコントローラ６０２は、要求のビューＵＲＩ（すなわち、views://contacts#list）にマッピングされているＵＲＬ（すなわち、file://...contacts#list）を読出すために、図７Ｃに示すビューテーブル７０２にアクセスする。ビューコントローラ６０２は、マッピングされたＵＲＬで格納された連絡先集合リストビュー定義を検索する。しかしながら、このビュー定義はＤＣＶ（すなわち、上述の例示的な連絡先集合ＤＣＶ）である。ビューコントローラは、以下により十分に説明されるであろう図１３に示されるプロセスに従って、このＤＣＶを実現できる。究極的には、ビューコントローラは結果ビュー定義を生成するであろう。それは最終的に、レンダリングおよび表示のためにモバイルＣＲＭクライアント６０６に転送される。

図９は、モバイル装置１０４によって表示される例示的な連絡先集合リストビューを示す。ビュー定義がレンダリングされ、表示される前に、ビューコントローラ６０２は、ＵＲＬにマッピングされている、ビュー定義におけるターゲットビューＵＲＩを識別するために、ビューテーブル７０２にアクセスできる。表示されたビュー定義は、アクション可能なビューコンポーネント、すなわち、ビューテーブル７０２においてＵＲＬにマッピングされているとしてビューコントローラ６０２によって以前に識別されたターゲットビューＵＲＩにマッピングされたコンポーネントを識別する視覚表示を含むであろう。一実施形態では、表示されたアクション可能なビューコンポーネントは、モバイル装置１０４によって太字で示される。図９に示す例では、LaBron James連絡先ビューコンポーネントが太字で示されており、こうしてこのコンポーネントがアクション可能であることを示す。

図９に表示されたLaBron Jamesコンポーネントなどのアクション可能なコンポーネントをユーザが起動するのに応答して、図８に示すプロセスに従って作用するモバイルＣＲＭ６０６は、LaBron James連絡先定義ビューに対するビュー要求を生成する。この要求は、レンダリングされ、表示された連絡先集合リストビュー定義内の「LaBron James」コンポーネントにリンクされたビューＵＲＩ（すなわち、view//contacts/101#detail）を含むであろう。モバイル装置１０４はオフラインであるため、この要求はビューコントローラ６０２に提供され、それは次に、マッピングされたＵＲＬ（すなわち、file://...contacts/101#detail）でファイルシステム定義からLaBron James連絡先ビュー定義を読出す。この連絡先ビュー定義は、次のレンダリングおよび表示のためにモバイルＣＲＭクライアント６０６に転送される。図１０は、モバイル装置１０４がオフラインモードにある間にモバイル装置１０４によって表示されるLaBron James連絡先ビューを示す。

モバイル装置がオフラインモードで動作する間、次のレンダリングおよび表示のためのビュー定義を生成するために、ＤＣＶがビューコントローラ６０２によって実行され得る。ビュー定義は、モバイル装置１０４を介してユーザによって提供される入力に依存する場合があり、ビューコントローラ６０２上で実行されるＤＣＶへの異なる入力は、異なるビュー定義をもたらす場合がある。ＤＣＶを実行する際、ビューコントローラ６０２は、何らかの選択基準（すべての連絡先、または「Ｌ」で始まるすべての連絡先を選択するなど）に従って、フィールドテーブル７１０の値列からコンポーネントを選択し、オプションで選択されたコンポーネントを別の基準に従ってソートし（たとえば、アルファベット順にソートし）、選択されたコンポーネントをそれぞれ含むエントリを用いて結果ビュー定義を作成することができる。一旦作成されると、結果ビュー定義は、モバイル装置１０４上での表示のためにレンダリングされ得る。図９は、ビューコントローラ６０２が上述の例示的なＤＣＶを実現するのに応答して表示された例示的なビューを示す。

図１３は、上述の例示的なＤＣＶなどのＤＣＶの実現に応答してビューコントローラ６０２によって行なわれる例示的なプロセスを示す。図８のステップ８２０に従ってＤＣＶがファイルシステム６１２から読出されると、ステップ１３０２に示すように、ビューコントローラ６０２は収集＿エンティティテーブルにアクセスして、ＤＣＶにおいて特定された収集ＵＲＩにマッピングされたすべてのエンティティＵＲＩを収集する。例示すると、上述の例示的なＤＣＶにおける特定された収集ＵＲＩは、「連絡先集合」である。ステップ１３０４で、ビューコントローラ６０２はエンティティ＿フィールドテーブルにアクセスして、ステップ１３０２で収集されたエンティティＵＲＩにそれぞれマッピングされたフィールドＵＲＩを収集する。フィールドＵＲＩのこの収集は、結果ビュー定義に配置され得る１つ以上のコンポーネントを識別するために使用され得る。

図９に示すビューなどのいくつかのオフラインビューでは、ユーザが検索語を入力できる検索フィールドが利用可能である。検索語を入力し、検索ボタンを起動した後で、検索語は、図１３に示すプロセスで使用するためにビューコントローラ６０２に提供される。より特定的には、ビューコントローラ６０２はフィールドテーブル７１０にアクセスして、ステップ１３０４からのフィールドＵＲＩによって識別され、かつモバイル装置１０４のユーザによって入力された検索語を満たすコンポーネントを、値列から収集する。検索語がユーザによって入力されていない場合、ヌルが仮定され、ステップ１３０６で、ビューコントローラは、ステップ１３０４で収集されたフィールドＵＲＩにそれぞれマッピングされた値をすべて収集する。ヌルの検索語が使用される場合、ビューコントローラ６０２は、ステップ１３０６で収集されたコンポーネントをソートしてもよい。一実施形態では、コンポーネントはアルファベット順にソートされる。

ステップ１３０６で収集された値ごとに、ビューコントローラは結果ビュー定義においてエントリを作成し、ステップ１３０６で収集されたそれぞれのコンポーネントを追加する。ステップ１３１２で、ビューコントローラ６０２はフィールドテーブル７１０にアクセスして、ステップ１３０６で収集されたコンポーネントにそれぞれマッピングされたエンティティＵＲＩを収集する。その後、ビューコントローラ６０２はエントリ＿ビューテーブル７２０にアクセスして、ステップ１３１２で収集されたエンティティＵＲＩにそれぞれマッピングされたビューＵＲＩを収集する。ビューテーブル７０２は、ステップ１３１４で収集されたビューＵＲＩにそれぞれマッピングされたＵＲＬがあれば、それらを収集するためにアクセスされ、これらのＵＲＬは、アクション項目として、結果ビュー定義の適切なエントリに追加される。最終的に、最重要コンポーネントおよびコマンドコンポーネントも、結果ビュー定義のエントリに追加される。結果ビュー定義は、レンダリングおよび表示のために、ビューコントローラ６０２によってモバイルＣＲＭクライアントに提供される。

上述のように、モバイル装置１０４は、ＤＣＶビューを処理しない場合でも、データストア６１４における最近または最新のコンポーネントがユーザに提示されることを保証するように、ビューコンポーネントを一致させることができる。図１４は、ビューをレンダリングし、表示する際にコンポーネントを一致させるためにビューコントローラ６０２によって実施される例示的なプロセスを示す。このプロセスは、図８のステップ８１６または８３０でビューコントローラがレンダリングおよび表示のために要求されたビュー定義をモバイルＣＲＭクライアント６０６に転送する前に、ビューコントローラによって実施され得る。図１４に示すプロセスを例示するために、モバイル装置１０４が、上述の例示的な連絡先集合リストビュー定義および例示的なLabron James連絡先ビュー定義を受信した後に、サーバ１０６から以下の例示的なアカウントビュー定義を受信すると仮定する。

Acme Corpビュー定義

Acme Corpビュー定義は、図８、図１１および図１２に示すプロセスに従って、ビューコントローラ６０２によって処理される。図７Ｄは、ビューコントローラ６０２が図１２に示すプロセスに従って上述の例示的なAcme Corp連絡先ビュー定義を処理した後の、図７Ｃにおけるデータストア６１４を示す。図１２に示すプロセスを実行する際、ビューコントローラ６０２は、図７Ｄに示すように「Acme Bike Corp」を「Acme Corp」で上書きすることによってフィールドテーブル７１０を更新する。図１５は、例示的なAcme Corpビュー定義に対応するビューを示す。このビューは、Labron Jamesが、図１０に示すような「Acme Bike Corp」ではなく、「Acme Corp」の連絡先であることを示す。

モバイル装置１０４が次にオフラインになり、ユーザがスプリングボードビューの「連絡先集合」コンポーネントを起動し、次に、連絡先集合の起動に応答して表示される連絡先集合リストビューの「Labron James」コンポーネントを起動する、と推測する。モバイル装置１０４は、図８に示すプロセスを実施し、ステップ８３０に示すようにファイルシステム６１２から読出されたビュー定義をレンダリングすることができる。しかしながら、ビュー定義がレンダリングおよび表示のために転送される前に、ビューコントローラ６０２は、図１４の一致プロセスを行なう。図１６は、図１４に示すプロセスを実施した後のビューを示す。図示されるように、アカウント名は、図１０に示すような「Acme Bike Corp」ではなく、「Acme Corp」になるように更新されている。

モバイル装置１０４は、ユーザがいくつかの関連するビュー定義をダウンロードしてローカルに格納することを可能にする、「エクスポート・データ」と呼ばれる特徴を有していてもよい。たとえば、ユーザは、特定のアカウントに関連付けられたビュー（連絡先、案件、行事予定など）のための大抵のまたはすべてのビュー定義をダウンロードしようとしてもよい。これらのビュー定義、またはそれらのコンポーネントは、オフラインモードにある間にモバイル装置１０４によってレンダリングされ、表示され得る。このため、ユーザがこの特徴を起動すると、モバイル装置は、たとえばアカウントに対するビュー要求、およびすべての関連付けられたビュー定義を生成できる。サーバ１０６は、アカウントビュー定義を含む返答と、アカウントに関連付けられたそれぞれの連絡先、案件などのためのビュー定義を含むアーカイブとを、モバイル装置に送信するであろう。ビューコントローラ６０２は、図１１および図１２に示すプロセスに従って、ファイルシステム６１２およびデータストア６１４をアーカイブのビュー定義のコンテンツで更新できる。

いくつかの実施形態に関連してこの発明を説明してきたが、この発明は、ここに述べられた特定の形に限定されるよう意図されてはいない。逆に、この発明は、そのような代替、修正および均等物を、添付された請求項によって定義されるようなこの発明の範囲に妥当に含まれ得るとして網羅するよう意図されている。

Claims (20)

1. モバイル装置によって要求を生成するステップと、
   前記要求に対する応答を受信するステップと、
   前記モバイル装置のメモリに格納された複数のテーブルを更新するステップとを含む、方法であって、
   前記更新するステップは、前記応答のコンポーネントを前記複数のテーブルのうちの第１のテーブルに追加するステップを含む、方法。
2. 前記更新するステップは、前記応答の第１のタグを前記第１のテーブルに追加するステップをさらに含む、請求項１に記載の方法。
3. 前記更新するステップは、前記第１のタグを前記複数のテーブルのうちの第２のテーブルに追加するステップをさらに含む、請求項２に記載の方法。
4. 前記応答の一部またはすべてを、前記モバイル装置のメモリに、あるアドレスで格納するステップと、
   前記複数のテーブルのうちの第３のテーブルにおいて、前記アドレスを識別子にマッピングするステップとをさらに含む、請求項１に記載の方法。
5. 前記識別子は前記応答に含まれる、請求項４に記載の方法。
6. 前記更新するステップは、前記識別子を前記複数のテーブルのうちの別のテーブルに追加するステップをさらに含む、請求項５に記載の方法。
7. 前記更新するステップは、前記応答の第２のタグを前記複数のテーブルのうちの第２のテーブルに追加するステップと、前記識別子を前記第２のテーブルに追加するステップとをさらに含む、請求項４に記載の方法。
8. 命令を格納するメモリであって、モバイル装置が前記命令の実行に応答して方法を実施し、前記方法は、
   要求を生成するステップと、
   前記要求に対する応答を受信するステップと、
   前記モバイル装置のメモリに格納された複数のテーブルを更新するステップとを含み、
   前記更新するステップは、前記応答のコンポーネントを前記複数のテーブルのうちの第１のテーブルに追加するステップを含む、メモリ。
9. 前記更新するステップは、前記応答の第１のタグを前記第１のテーブルに追加するステップをさらに含む、請求項８に記載のメモリ。
10. 前記更新するステップは、前記第１のタグを前記複数のテーブルのうちの第２のテーブルに追加するステップをさらに含む、請求項９に記載のメモリ。
11. 前記方法は、
    前記応答の一部またはすべてを、前記モバイル装置のメモリに、あるアドレスで格納するステップと、
    前記複数のテーブルのうちの第３のテーブルにおいて、前記アドレスを識別子にマッピングするステップとをさらに含む、請求項８に記載のメモリ。
12. 前記識別子は前記応答に含まれる、請求項１１に記載のメモリ。
13. 前記更新するステップは、前記識別子を前記複数のテーブルのうちの別のテーブルに追加するステップをさらに含む、請求項１２に記載のメモリ。
14. 前記更新するステップは、前記応答の第２のタグを前記複数のテーブルのうちの第２のテーブルに追加するステップと、前記識別子を前記第２のテーブルに追加するステップとをさらに含む、請求項１１に記載のメモリ。
15. 命令をモバイル装置に、そのメモリへの格納のために送信するステップを含む、方法であって、前記モバイル装置は、前記命令の実行に応答して別の方法を実施するように構成されており、前記別の方法は、
    要求を生成するステップと、
    前記要求に対する応答を受信するステップと、
    前記モバイル装置のメモリに格納された複数のテーブルを更新するステップとを含み、
    前記更新するステップは、前記応答のコンポーネントを前記複数のテーブルのうちの第１のテーブルに追加するステップを含む、方法。
16. 前記更新するステップは、前記応答の第１のタグを前記第１のテーブルに追加するステップをさらに含む、請求項１５に記載の方法。
17. 前記更新するステップは、前記第１のタグを前記複数のテーブルのうちの第２のテーブルに追加するステップをさらに含む、請求項１６に記載の方法。
18. 前記別の方法は、
    前記応答の一部またはすべてを、前記モバイル装置のメモリに、あるアドレスで格納するステップと、
    前記複数のテーブルのうちの第３のテーブルにおいて、前記アドレスを識別子にマッピングするステップとをさらに含む、請求項１５に記載の方法。
19. 前記識別子は前記応答に含まれる、請求項１８に記載の方法。
20. 前記更新するステップは、前記識別子を前記複数のテーブルのうちの別のテーブルに追加するステップをさらに含む、請求項１５に記載の方法。

Images