(57)【要約】キャッシュテーブルは、１組のアクセスパラメータと１組のデータ列とを含む。キャッシュテーブルの１つ以上のインスタンスがモバイルコンピューティング機器に記憶される。各インスタンスは、引数（アクセスパラメータについての一意的な１組の値）と、結果セット（データ列についての１組の値）とを含む。このため、結果セットの各結果は、引数と対応する列値とを含む。キャッシュされた結果セットは有効性の特定された期間を有しており、無効となった後で使用可能となってもよく、ならなくてもよい。データソース（たとえばデータまたはアプリケーションサーバ）にとって接続が利用可能であるか否かにかかわらず、キャッシュされた有効なデータは使用されてもよい。データソースにとって接続が利用可能でない場合、無効データが或る期間使用されてもよい。キャッシュテーブル内のデータは、ローカルデータベース全体と同期することなく、データソースから選択的に更新されてもよい。
2005533324.tif 000002
【特許請求の範囲】
【請求項１】
不連続的に利用可能な通信リンクでデータソースに結合されたモバイルコンピューティング機器において、データソースからのデータのキャッシングを容易にする方法であって、
モバイルコンピューティング機器のデータベース内にキャッシュテーブルを構成するステップを含み、前記キャッシュテーブルは、
データソース上のデータセットの第１の組の列を含むアクセスパラメータと、
データセットの第１の組の列とは異なる、データセットの第２の組の列を含む結果列とを含み、前記方法はさらに、
データベース内に前記キャッシュテーブルの１つ以上のインスタンスを生成するステップを含み、各前記キャッシュテーブルインスタンスは１組の行を含み、各前記行は、
引数を含み、前記引数はアクセスパラメータの各列についての値を含み、各前記行はさらに、
結果列の各列についての値を含む結果セットを含み、１組の行における各行は同じ引数を含む、方法。
【請求項２】
各前記キャッシュテーブルインスタンスについて、前記キャッシュテーブルインスタンスの前記結果セットがデータ動作のために使用されるかどうかを判断するための１つ以上のパラメータを記憶させるステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記パラメータは、前記結果セットがデータソースから受取られた時を示す応答日を含む、請求項２に記載の方法。
【請求項４】
前記パラメータは、前記結果セットがデータソースにおいて最後に修正された時を示す最終修正日を含む、請求項２に記載の方法。
【請求項５】
前記パラメータは、前記結果セットがその間有効である第１の期間を示すよう構成された有効期間パラメータを含み、
前記結果セットは前記第１の期間の終わりに無効となる、請求項２に記載の方法。
【請求項６】
不連続的に利用可能な通信リンクが利用可能であるか否かにかかわらず、前記結果セットが有効であれば、前記結果セットは前記データ動作のために使用される、請求項５に記載の方法。
【請求項７】
前記結果セットが無効である場合に限り、前記結果セットのための置換え結果セットがデータソースから検索される、請求項５に記載の方法。
【請求項８】
前記結果セットが無効である場合に限り、前記結果セットについての更新がデータソースから検索される、請求項５に記載の方法。
【請求項９】
前記パラメータは、前記結果セットが使用可能な、前記第１の期間に続く第２の期間を示すよう構成された古さパラメータを含み、
前記結果セットは前記第２の期間の終わりに古くなる、請求項５に記載の方法。
【請求項１０】
前記結果セットが使用可能で、かつ不連続的に利用可能な通信リンクが利用できない場合、前記結果セットは前記データ動作のために使用される、請求項９に記載の方法。
【請求項１１】
第１のキャッシュテーブルインスタンスに関する第１のデータ動作を受取るステップと、
（ａ）  前記第１のキャッシュテーブルインスタンスの前記結果セットが有効である場合、または
（ｂ）  前記第１のキャッシュテーブルインスタンスの前記結果セットが無効で、かつ
（１）  前記第１のキャッシュテーブルインスタンスの前記結果セットが使用可能であり、かつ
（２）  連続的とはいえない利用可能な通信リンクが利用できない場合に、前記第１のキャッシュテーブルインスタンスの前記結果セットを使用するステップとをさらに含む、請求項９に記載の方法。
【請求項１２】
前記第１のキャッシュテーブルインスタンスの前記結果セットが無効である場合に限り、前記第１のキャッシュテーブルインスタンスの前記結果セットについて更新を検索するステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
前記第１のキャッシュテーブルインスタンスの前記結果セットが無効である場合に限り、前記第１のキャッシュテーブルインスタンスの前記結果セットのための置換え結果セットを検索するステップをさらに含む、請求項１１に記載の方法。
【請求項１４】
前記第１のキャッシュテーブルインスタンスの前記結果セットが無効で、
前記第１のキャッシュテーブルインスタンスの前記結果セットが古く、かつ、
連続的とはいえない利用可能な通信リンクが利用できない場合に、エラーを合図するステップをさらに含む、請求項１１に記載の方法。
【請求項１５】
前記データセットはデータベーステーブルおよびビューのうちの１つである、請求項１に記載の方法。
【請求項１６】
コンピュータにより実行されると、連続的とはいえない利用可能な通信リンクでデータソースに結合されたモバイルコンピューティング機器においてデータソースからのデータのキャッシングを容易にする方法をコンピュータに行なわせる命令を記憶する、コンピュータ読み取り可能なストレージ媒体であって、前記方法は、
モバイルコンピューティング機器のデータベース内にキャッシュテーブルを構成するステップを含み、前記キャッシュテーブルは、
データソース上のデータセットの第１の組の列を含むアクセスパラメータと、
データセットの第１の組の列とは異なる、データセットの第２の組の列を含む結果列とを含み、前記方法はさらに、
データベース内に前記キャッシュテーブルの１つ以上のインスタンスを生成するステップを含み、各前記キャッシュテーブルインスタンスは１組の行を含み、各前記行は、
引数を含み、前記引数はアクセスパラメータの各列についての値を含み、各前記行はさらに、
結果列の各列についての値を含む結果セットを含み、１組の行における各行は同じ引数を含む、コンピュータ読み取り可能なストレージ媒体。
【請求項１７】
データサーバに不連続的に結合されたモバイルコンピューティング機器でのデータキャッシングを容易にする方法であって、
データサーバ上の１つ以上の論理データテーブルを識別するステップと、
各論理データテーブルについて、モバイルコンピューティング機器から論理テーブルへのアクセスを提供するよう構成されたテーブルデータプロセッサを保持するステップと、
モバイルコンピューティング機器からデータサーバにおける引数を受取るステップとを含み、引数は第１の論理テーブルの１つ以上の列についての値を含み、前記方法はさらに、
第１の論理テーブルの１組の行を識別するステップを含み、１組の行における各行は引
数を含み、前記方法はさらに、
１組の行をフィルタリングするステップを含み、前記フィルタリングするステップは、
引数がモバイルコンピューティング機器から受取られた最後の時点以降修正されていないいずれの行も除外するステップと、
引数に対応する１つ以上の列を行から除去するステップとを含み、前記方法はさらに、
引数に応答して、フィルタリングされた１組の行をモバイルコンピューティング機器に戻すステップを含む、方法。
【請求項１８】
コンピュータにより実行されると、データサーバに不連続的に結合されたモバイルコンピューティング機器でのデータキャッシングを容易にする方法をコンピュータに行なわせる命令を記憶する、コンピュータ読み取り可能なストレージ媒体であって、前記方法は、
データサーバ上の１つ以上の論理データテーブルを識別するステップと、
各論理データテーブルについて、モバイルコンピューティング機器から論理テーブルへのアクセスを提供するよう構成されたテーブルデータプロセッサを保持するステップと、
モバイルコンピューティング機器からデータサーバにおける引数を受取るステップとを含み、引数は第１の論理テーブルの１つ以上の列についての値を含み、前記方法はさらに、
第１の論理テーブルの１組の行を識別するステップを含み、１組の行における各行は引数を含み、前記方法はさらに、
１組の行をフィルタリングするステップを含み、前記フィルタリングするステップは、
引数がモバイルコンピューティング機器から受取られた最後の時点以降修正されていないいずれの行も除外するステップと、
引数に対応する１つ以上の列を行から除去するステップとを含み、前記方法はさらに、
引数に応答して、フィルタリングされた１組の行をモバイルコンピューティング機器に戻すステップを含む、コンピュータ読み取り可能なストレージ媒体。
【請求項１９】
モバイルコンピューティング機器においてデータをキャッシュする方法であって、モバイルコンピューティング機器は不連続的に利用可能な無線リンクを介してデータソースに接続可能であり、前記方法は、
モバイルコンピューティング機器においてキャッシュされた第１の組のデータに関する第１の動作を受取るステップと、
前記第１の組のデータが有効かどうかを判断するステップと、
前記第１の組のデータが無効である場合、前記不連続的に利用可能な無線リンクが利用可能かどうかを判断するステップと、
前記第１の組のデータが無効で、かつ前記連続的とはいえない利用可能な無線リンクが利用できない場合、前記第１の組のデータが使用可能かどうかを判断するステップと、
前記第１の組のデータが無効で、かつ前記連続的とはいえない利用可能な無線リンクが利用可能な場合に限り、前記第１の組のデータについての更新をデータソースから検索するステップとを含む、方法。
【請求項２０】
前記第１の組のデータが第１のトランザクションによってロックされているかどうかを判断するステップをさらに含み、
前記第１の動作は前記第１のトランザクションによって開始されたものである、請求項１９に記載の方法。
【請求項２１】
前記第１の組のデータ上で第１のトランザクションによってアクティブカーソルが開かれているかどうかを判断するステップをさらに含み、
前記第１の動作は前記第１のトランザクションによって開始されたものである、請求項
１９に記載の方法。
【請求項２２】
前記第１の組のデータが有効かどうかを判断する前記ステップは、
前記第１の組のデータに関連する有効性パラメータにアクセスするステップを含み、前記有効性パラメータは、前記第１の組のデータが無効になる第１の時点を示すよう構成されており、判断する前記ステップはさらに、
前記第１の動作の時点を前記第１の時点と比較するステップを含み、
前記第１の組のデータは前記第１の時点の前で有効である、請求項１９に記載の方法。
【請求項２３】
前記第１の組のデータが使用可能かどうかを判断する前記ステップは、
前記第１の組のデータに関連する古さパラメータにアクセスするステップを含み、前記古さパラメータは、前記第１の組のデータが古くなる、前記第１の時点の後の第２の時点を示すよう構成されており、判断する前記ステップはさらに、
前記第１の動作の前記時点を前記第２の時点と比較するステップを含み、
前記第１の組のデータは前記第１の時点と前記第２の時点との間で使用可能である、請求項２２に記載の方法。
【請求項２４】
第１の動作を受取る前記ステップの前に、
前記第１の組のデータを含むデータをキャッシュするためにモバイルコンピューティング機器にキャッシュテーブルを構成するステップをさらに含み、前記キャッシュテーブルは、
データソース上のデータセットの第１の組の列を含む１組のアクセスパラメータと、
データセットの第２の組の列とによって定義される、請求項１９に記載の方法。
【請求項２５】
第１の動作を受取る前記ステップの前に、
前記キャッシュテーブルの１つ以上のインスタンスを生成するステップをさらに含み、各前記キャッシュテーブルインスタンスは、
前記１組のアクセスパラメータについての一意的な１組の値を含む引数と、
前記第２の組の列についての値を含む結果セットとを含み、
前記第１の組のデータは第１のキャッシュテーブルインスタンスの第１の結果セットを含む、請求項２４に記載の方法。
【請求項２６】
前記第１の組のデータが有効である場合、または、
前記第１の組のデータが無効で、前記連続的とはいえない利用可能な無線リンクが利用できず、かつ前記第１の組のデータが使用可能である場合に、
前記第１の動作のために前記第１の組のデータを使用するステップをさらに含む、請求項１９に記載の方法。
【請求項２７】
コンピュータにより実行されると、モバイルコンピューティング機器においてデータをキャッシュする方法をコンピュータに行なわせる命令を記憶する、コンピュータ読み取り可能なストレージ媒体であって、モバイルコンピューティング機器は不連続的に利用可能な無線リンクを介してデータソースに接続可能であり、前記方法は、
モバイルコンピューティング機器においてキャッシュされた第１の組のデータに関する第１の動作を受取るステップと、
前記第１の組のデータが有効かどうかを判断するステップと、
前記第１の組のデータが無効である場合、前記連続的とはいえない利用可能な無線リンクが利用可能かどうかを判断するステップと、
前記第１の組のデータが無効で、かつ前記不連続的に利用可能な無線リンクが利用できない場合、前記第１の組のデータが使用可能かどうかを判断するステップと、
前記第１の組のデータが無効で、かつ前記連続的とはいえない利用可能な無線リンクが
利用可能な場合に限り、前記第１の組のデータについての更新をデータソースから検索するステップとを含む、コンピュータ読み取り可能なストレージ媒体。
【請求項２８】
モバイル機器においてデータをキャッシュするためのデータベースであって、
無線通信接続を介してアクセス可能なデータソースの第１の組の属性に対応する１組のアクセスパラメータと、データソースの第２の組の属性とによって定義されるキャッシュテーブルを含み、データベースは無線通信接続を介して中央データソースに不連続的に接続され、前記データベースはさらに、
前記キャッシュテーブルの１つ以上のインスタンスを含み、各前記キャッシュテーブルインスタンスは、
引数を含み、前記引数は前記アクセスパラメータについての一意的な１組の値を含み、各前記キャッシュテーブルインスタンスはさらに、
前記第２の組の属性についての値を含む結果セットを含み、前記データベースはさらに、
各前記キャッシュテーブルインスタンスについて、前記結果セットがモバイル機器において使用可能な期間を判断するための情報を含む、データベース。
【請求項２９】
前記結果セットがその間使用可能な前記期間は、前記結果セットがその間有効な第１の期間を含む、請求項２８に記載のデータベース。
【請求項３０】
データベースは、前記第１の期間中、中央データベースから前記結果セットを検索しないよう構成されている、請求項２９に記載のデータベース。
【請求項３１】
前記結果セットがその間使用可能な前記期間はさらに、前記結果セットがその間無効であるもののまだ古くなってはいない第２の期間を含み、
前記第２の期間は前記第１の期間の直後に続く、請求項２９に記載のデータベース。
【請求項３２】
前記結果セットがデータベーストランザクションによってロックされている場合、または、
データベーストランザクションが前記結果セット上で開かれたアクティブカーソルを有する場合を除き、
前記結果セットは、前記第２の期間の後、データベーストランザクションによって使用できない、請求項３１に記載のデータベース。
【請求項３３】
前記情報は、
前記結果セットがいつ無効になるかを示すよう構成された第１のパラメータと、
前記結果セットがいつ古くなるかを示すよう構成された第２のパラメータとを含む、請求項２８に記載のデータベース。
【請求項３４】
データソースへの動作の送信前に、前記１つ以上のキャッシュテーブルインスタンスに動作を記憶させるよう構成された待ち行列をさらに含み、
データソースが無線通信接続を介してアクセス可能ではない場合、動作は前記待ち行列に記憶される、請求項２８に記載のデータベース。
【請求項３５】
無線リンクを介して中央データソースに接続可能なモバイルコンピューティング機器においてデータをキャッシュするためのシステムであって、
中央データソースに対し、オンラインモードおよびオフラインモードのいずれかで選択的に動作するよう構成されたデータベースと、
データベース内の、データソースの第１の組の属性に対応する１組のアクセスパラメータと中央データソースの第２の組の属性とによって定義されたキャッシュテーブルと、
データベース内の、前記キャッシュテーブルの１つ以上のインスタンスとを含み、各前記キャッシュテーブルインスタンスは、
前記アクセスパラメータの各々についての値を含む引数と、
１組の結果とを含み、各前記結果はデータソースの前記第２の組の属性の各々についての値を含み、前記システムはさらに、
各前記キャッシュテーブルインスタンスについて、前記結果セットが使用可能かどうかを判断するための情報を含む、システム。
【請求項３６】
第１のキャッシュテーブルインスタンスの第１の結果セットについての前記情報は、
前記第１の結果セットがデータソースからデータベースに最後に提供された時を示すよう構成された応答日パラメータ、
前記第１の結果セットがデータソースで最後に修正された時を示すよう構成された最終修正日パラメータ、
前記第１の結果セットがその間有効である第１の期間を示すよう構成され、前記第１の結果セットが有効であれば前記第１の結果セットは使用可能である、有効期間パラメータ、および、
前記第１の結果セットがその間使用可能である、前記第１の期間の満了時に始まる第２の期間を示すよう構成された古さパラメータのうちの１つ以上を含む、請求項３５に記載のシステム。
【請求項３７】
前記第１のキャッシュテーブルインスタンスに関する第１の動作が時点Ｏで受取られ、
前記第１の期間が時点Ｖで終わり、
前記第２の時点が時点Ｕで終わり、
ＯがＶより早い場合、または、ＯがＶより遅く、ＯがＵより早く、かつ前記データベースがデータソースに対してオフラインモードで動作される場合に、前記結果セットは前記第１の動作のために使用可能である、請求項３６に記載のシステム。
【請求項３８】
前記第１の結果セットがデータベースに存在しない場合、または、
前記第１の結果セットがデータベースに存在するが使用できない場合に限り、
前記データベースは、第１のキャッシュテーブルインスタンスについての第１の結果セットを受取るために中央データソースとオンラインモードで動作する、請求項３５に記載のシステム。
【請求項３９】
第１のキャッシュテーブルインスタンスの第１の結果セットが有効である場合、前記データベースは、中央データソースへの無線リンクが利用可能であるか否かにかかわらず、前記第１のキャッシュテーブルインスタンスに関する動作中、オフラインモードで動作する、請求項３５に記載のシステム。
【請求項４０】
モバイルコンピューティング機器においてデータをキャッシュするためのシステムであって、モバイルコンピューティング機器は中央データソースへの不連続な基準での接続用に構成されており、前記システムは、
モバイルコンピューティング機器において、中央データソースからデータをキャッシュするよう構成されたキャッシュテーブルと、
前記キャッシュテーブルにおける１つ以上の入力とを含み、各前記入力は中央データソースからの１組のデータを含み、前記システムはさらに、
前記キャッシュテーブルにおける各入力用の、前記１組のデータがその間有効である期間を判断するための有効性パラメータと、
前記キャッシュテーブルにおける各入力用の、前記１組のデータがその間有効な前記期間の後で前記１組のデータが使用可能かどうかを判断するための使用可能性パラメータと、
モバイルコンピューティング機器を中央データソースに、連続的とはいえない基準で接続するよう構成された通信モジュールとを含む、システム。
【請求項４１】
前記有効性パラメータは、前記１組のデータが無効になる第１の時点を識別するよう構成されており、
前記第１の時点までに、前記１組のデータは、モバイルコンピューティング機器が中央データソースに接続されているか否かにかかわらず、前記キャッシュテーブル入力に関する動作のために使用される、請求項４０に記載のシステム。
【請求項４２】
前記使用可能性パラメータは、前記１組のデータが古くなる第２の時点を識別するよう構成されており、
前記第１の時点の後、かつ前記第２の時点までに、前記１組のデータは、モバイルコンピューティング機器が中央データソースに接続されていない場合に限り、前記キャッシュテーブル入力に関する動作のために使用される、請求項４０に記載のシステム。
【請求項４３】
前記通信モジュールは、一度に最大１つのキャッシュテーブル入力動作のためにモバイルコンピューティング機器を中央データソースに接続するよう構成されている、請求項４０に記載のシステム。
【請求項４４】
モバイルコンピューティング機器は、有効なキャッシュテーブル入力に関する動作のために中央データソースに接続されない、請求項４３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
背景
この発明はコンピュータシステムの分野に関する。より特定的には、モバイル機器にデータをキャッシュするためのシステムおよび方法が提供される。
【背景技術】
【０００２】
モバイル機器（たとえばラップトップコンピュータ、携帯情報端末、携帯電話）上で動作するアプリケーションは一般に、オンライン使用またはオフライン使用のいずれかのために設計されてきた。双方のタイプのモバイルアプリケーションは、ユーザと対話するために或る種のブラウザを使用する傾向にある。オンラインアプリケーションは、企業サーバ（たとえば中央データベースサーバ）への連続的なアクセスを享受する。これに対し、オフラインアプリケーションは、企業サーバとは最小限の接触で、または全く接触せずに動作する。
【０００３】
より具体的には、オンラインモバイルアプリケーションは、必要であればいつでも企業サーバ上のデータにアクセスすることができ、それにより、データをローカルに記憶する必要性をおそらくなくす。しかしながら、オンラインモバイルアプリケーションの「常時接続された」性質のため、（たとえば無線通信時間に対する）接続費はかなり高くなり得る。
【０００４】
また、オンラインモバイルアプリケーションは一般に、予測不能な待ち時間を被る。オンラインアプリケーションがサーバに要求を送信すると、応答時間は、サーバでの任意の輻輳に加え、モバイル機器の無線ネットワークの使用レベルに依存する。さらに、オンラインアプリケーションの使用は、無線ネットワークの範囲に依存して地理的に制限される場合があり、場所によっては（たとえば飛行機、病院）禁止される場合がある。
【０００５】
さらに、オンラインモバイルアプリケーションはしばしば、ウェブページ全体、データテーブルといった、セットになったデータにアクセスする。或るデータ項目を置き換える必要がある場合、その１つの項目のみを置き換えるというよりもむしろ、そのデータセット全体が置き換えられる場合がある。これは非効率的で、アプリケーションを動作させるコストを増加させる可能性がある。
【０００６】
モバイルアプリケーションがセットになったデータ（たとえばウェブページ全体）にアクセスしがちである１つの理由は、データがデータのプレゼンテーションと緊密に結びついていることにある。特に、データがモバイルアプリケーション用にクライアント機器にコピーまたはダウンロードされる場合、データの各集合（たとえばテーブル、１組のデータベース行またはフィールド）は通常、それが表示されるページ内で伝搬される。このため、そのページを除いてデータをクライアント上に表示することはできない。データの各セットまたは集合が表示ページ全体とともに記憶され、それらのカプセル化されたデータを除いて多くのページが同一であるかもしれないために、クライアント上の多くのストレージが浪費される場合がある。
【０００７】
オンラインアプリケーションとは対照的に、オフラインモバイルアプリケーションは、企業サーバにより維持されるデータへの連続的なアクセスを享受していない。企業サーバからの或るデータ（たとえばスナップショット）は、モバイル機器上にコピーされるかまたは複製される場合がある。オフラインアプリケーションは（たとえばサーバからオフラ
インである場合に）常に使用可能であり得るものの、常に新鮮なデータを有しているとは限らず、それにコピーされたデータにアクセスすることしかできない。
【０００８】
データスナップショットを使用するよう構成されたオフラインモバイルアプリケーションは普通、時々または定期的に（たとえば１日に１回）その記憶されたオフラインデータを企業サーバと同期させる必要がある。同期の頻度は一般に、データ項目がモバイル機器上でアクセスまたは修正される頻度とは無関係である。このため、多くのトランザクションまたは動作が古いデータを用いてモバイル機器上で実行される場合がある。そして、変更されたことがなくリフレッシュされる必要がないデータでさえ、大量のデータがしばしば交換されるため、同期は大きいオーバーヘッドを必然的に伴う場合がある。たとえば、或るページのたった１つのデータ項目を更新する必要がある場合ですら、ウェブページ全体またはウェブページのセットがダウンロードまたは交換される場合がある。
【０００９】
オフラインモバイルアプリケーションは、データ同期が頻繁には起こらないため、非常に動的なデータでの使用には適さない。加えて、オフラインモバイルアプリケーションはしばしば、同期を容易にするために、アプリケーションによってなされたすべてのデータ変更のトランザクションログを保持する必要がある。
【００１０】
一般に、モバイルアプリケーションで使用されるモバイル機器に記憶された企業データは、さまざまな寿命を有する場合がある。長期間有効なデータポイントまたは項目（たとえば製品説明、アドレス）もあれば、ほんの比較的短期間の後で無効になるデータポイントまたは項目（たとえば株価、通貨変換レート）もある。既存のモバイルアプリケーションおよびクライアントデータベースは通常、ダウンロードされたデータの寿命を認識または検討するよう構成されてはいない。
【００１１】
さらに、ユーザに多大な機能性を与えようと試みるモバイルクライアントアプリケーションは、頑強なソフトウェアおよび／またはハードウェアコンフィギュレーション（たとえばJava（登録商標）仮想マシン、ＨＴＴＰリスナ、サーブレットエンジン）を必要とする傾向にある。そのような要件は、携帯情報端末（ＰＤＡ）またはスマート電話といったより小さくより抑制されたクライアント機器の使用を妨げ、また、クライアント動作にオーバーヘッドを追加する。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
要約
この発明の一実施例では、第三世代の無線ネットワークまたは他の企業ネットワークで使用されるよう構成されたモバイル（たとえば無線）機器上で実行されるアプリケーションで使用されるデータのきめ細かいキャッシングのためのシステムおよび方法が提供される。この実施例では、機器は、データの中央ソースまたはマスタソース（たとえばデータサーバ、ウェブサーバまたはアプリケーションサーバ）に常にアクセスする必要はなく、キャッシュされたデータをオンラインモードまたはオフラインモードで使用することができる。モバイル機器上でキャッシュされるデータは必要に応じて選択的にリフレッシュされ得るため、機器とデータソースとの間での伝統的な同期動作は不必要である。このため、動作の双方のモードの利点（たとえば新鮮なデータ、許容可能な接続費）が得られる。
【００１３】
この発明の一実施例では、データは、モバイル機器のローカルＤＢＭＳ（データベース管理システム）の一部として実現されたキャッシュテーブルにキャッシュされる。この実施例では、キャッシュテーブルとは、その内容（たとえば行）が必要に応じてサーバから検索され、内容に関連するキャッシュ制御命令に従ってローカルにキャッシュされるテーブルである。キャッシュテーブルの列（または属性）のサブセットは、キャッシュテーブ
ルの「アクセスパラメータ」として指定される。データをキャッシュテーブルから検索するために、アクセスパラメータの各々に対して或る値が提供される。これらの値は、キャッシュテーブルの１つのインスタンスについての引数を構成する。これらの引数値を有する行がローカルデータベースにない場合、または期限切れになった場合、ＤＢＭＳはその行を検索しキャッシュするために対応するサーバに接触する。
【００１４】
たとえば、キャッシュテーブルが或る特定の部品番号に応じてさまざまな倉庫立地についての在庫数を報告するよう構成されている場合、キャッシュテーブルの列は、部品番号、倉庫番号、および対応する倉庫に保管された部品の量を含むかもしれない。照会の一部として供給される部品番号は、キャッシュテーブルについてのアクセスパラメータであるかもしれない。一意的な各部品番号に対し、キャッシュテーブルの別個のインスタンスは、各倉庫に保管された部品の量を報告する１組の行（結果セット）を含む。
【００１５】
この発明の一実施例では、データキャッシング方針をキャッシュテーブル内にカプセル化することにより、データキャッシングはアプリケーション論理から分けられる。これは、アプリケーション論理の一部としてキャッシング方針を符号化しなければならないことからアプリケーション開発者を解放し、データベース管理者がキャッシング方針を定義できるようにする。
【００１６】
この発明の別の実施例では、キャッシュテーブルのデータおよびトランザクショナルな意味論を、データベーストランザクションのＡＣＩＤ（原子性、一貫性、独立性および永続性）特性と一貫性があるように定義するアルゴリズムが提供される。特に、キャッシュテーブルに記憶されたデータは関連する有効期間を有しており、それは、データを得たデータソースによって特定されるかもしれない。データはまた、サーバへの接続が利用不可能な場合、データが無効となった後で使用されるかどうか、およびどのくらいの期間使用されるかを示す、関連するキャッシュ制御情報も有するかもしれない。ローカルデータベース動作がキャッシュテーブルに影響を与えると、アルゴリズムが適用されて、キャッシュされたデータを使用するか、またはデータソースからデータをリフレッシュしようとするかを判断する。アルゴリズムは、接続がデータソースにとって利用可能かどうか、データが同じまたは別のトランザクションによってロックされているかどうか、データが無効かどうか、関連するキャッシュ制御情報によりデータが無効であっても使用できるようになっているかどうかなどを検討するかもしれない。
【００１７】
例示的には、この発明の一実施例は、モバイル機器およびアプリケーションがローカルデータにオフラインでアクセスし、必要に応じて特定のデータ（たとえばキャッシュテーブル結果セット）を選択的にリフレッシュすることができるようにする。その結果、（たとえばデータソースへの）接続費、および古いデータの使用が最小限に抑えられる。そして、キャッシュテーブルがテーブルであるため、すべてのモバイルデータベースアプリケーションは、追加コードをアプリケーション論理で書く必要なくキャッシュテーブルによって与えられる恩恵を得ることができる。
【発明を実施するための最良の形態】
【００１８】
詳細な説明
以下の説明は、当業者がこの発明を成し、用いることを可能にするために提示されており、この発明の特定の用途およびそれらの要件の状況において提供される。開示された実施例へのさまざまな修正は当業者には容易に明らかであり、ここに定義された一般原理はこの発明の範囲から逸脱することなく他の実施例および用途に適用されてもよい。このため、この発明は示された実施例に限定されるよう意図されてはおらず、ここに開示された原理および特徴と一貫性のある最も幅広い範囲が与えられるべきである。
【００１９】
この発明のこの実施例が実行されるプログラム環境は、例示的には、汎用コンピュータ、または、モバイルコンピュータ、ＰＤＡ（携帯情報端末）、電話といった特定用途機器を実現する。そのような機器の詳細（たとえばプロセッサ、メモリ、データストレージ、ディスプレイ）は明瞭にするために省略され得る。
【００２０】
また、この発明の手法がさまざまな技術を用いて実現され得ることも理解されるべきである。たとえば、ここに説明される方法は、コンピュータシステム上で実行されるソフトウェアにおいて実現されてもよく、または、マイクロプロセッサの組合せ、もしくは他の特別に設計された特定用途向け集積回路、プログラマブル論理デバイスあるいはそれらのさまざまな組合せのいずれかを利用するハードウェアにおいて実現されてもよい。特に、ここに説明される方法は、好適なコンピュータ読み取り可能な媒体上に存在する一連のコンピュータにより実行可能な命令によって実現されてもよい。好適なコンピュータ読み取り可能な媒体は、揮発性（たとえばＲＡＭ）および／または不揮発性（たとえばＲＯＭ、ディスク）メモリ、搬送波、および通信媒体（たとえば銅線、同軸ケーブル、光ファイバ媒体）を含んでいてもよい。例示的な搬送波は、ローカルネットワーク、インターネットなどの公的にアクセス可能なネットワーク、または他の通信リンクに沿ってデジタルデータストリームを伝搬する電気信号、電磁信号または光信号の形を取ってもよい。
【００２１】
序文
この発明の一実施例では、モバイル機器上での、機器で実行されるアプリケーションにより使用されるデータのきめ細かなキャッシングのためのシステムおよび方法が提供される。この実施例では、アプリケーションデータは、キャッシュされたデータの有効性および／または使用可能性を監視するよう構成された１つ以上のキャッシュテーブルを含むデータベース（たとえばＤＢＭＳ）に記憶される。
【００２２】
この実施例では、キャッシュテーブルは、１つ以上のデータ行をキャッシュするだけでなく、データの有効性、データの新鮮なコピーをどこでまたはどのように入手するか、などを説明するキャッシュ制御情報も記憶しており、またはその情報にも関連している。アプリケーションがキャッシュテーブルにアクセスすると、ローカルＤＢＭＳは所望のデータを検査し、まだ有効であればそれを供給する。キャッシュされたデータがもはや有効ではない場合、ローカルＤＢＭＳは、サーバへの接続が利用可能であればサーバから更新されたデータを要求する。単一の（無効な）データ行を更新するために大きな１組のデータを検索する代わりに、その行だけが検索され得る。
【００２３】
この発明の一実施例では、キャッシュテーブルは、データソース（たとえば企業サーバ、データベースサーバ、ウェブサーバ、アプリケーションサーバ）から必要に応じて検索され、ローカル（たとえばモバイル）機器に記憶され得るデータのデータベーステーブルである。サーバと機器との間の通信は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＳＯＡＰ（シンプルオブジェクトアクセスプロトコル）、ＷＡＰ（ワイヤレスアクセスプロトコル）などの任意の好適なプロトコルを採用してもよい。データソースをホストするサーバは、ここに説明されるキャッシュテーブル仕様と関連するインターフェイスを実現するよう、ＣＧＩ（共通ゲートウェイインターフェイス）プログラム、サーブレット、アプレット、Java（登録商標）方法または他のモジュールを実行するよう構成されてもよい。
【００２４】
この発明の一実施例では、キャッシュテーブルはデータベースプログラミングモデルと互換性があり、そのためモバイルアプリケーションは、ＯＤＢＣ（オープンデータベースコネクティビティ）またはＪＤＢＣ（Java（登録商標）データベースコネクティビティ）などの標準インターフェイスを介して、キャッシュされたデータにアクセスすることができる。キャッシュテーブルのローカルデータベースを使用するモバイルアプリケーション
はしたがって、通常のデータベースモデルおよびインターフェイスを用いて書くことができる。データベースは、そのキャッシュテーブルを介して、データ有効性を管理し、無効なデータについて更新を検索したりする。キャッシュテーブルのデータおよびトランザクショナルな意味論は、業界標準のトランザクショナルな意味論に従うよう設計されてもよい。
【００２５】
モバイル機器が企業サーバ（または他の中央／マスタデータソース）と常にアクティブに通信しているとは限らず、かつ、データ検索が無効なデータ項目のみに限定可能であるために、通信費を比較的低く保つことができる。そして、企業サーバに行なう必要があるアクセス数が限定されるために、予測不能な待ち時間から生じる不規則な動作はそれほど問題ではない。
【００２６】
この発明の別の実施例では、モバイルコンピューティング機器（たとえば個人情報端末（ＰＤＡ）、ラップトップまたはノートブックコンピュータ、スマート電話）上で実行されるオフラインアプリケーションの動作を向上させるために、インテリジェントクライアントエージェントが提供される。この実施例では、クライアントエージェントは、オンラインアクセスを選択的に可能にし、アプリケーション内容をその内容のプレゼンテーションフォーマットから分けることによって、オフラインアプリケーションの動作を向上させる。内容とプレゼンテーションとは、アプリケーションページのプレゼンテーション記述またはフォーマットとは別に（たとえばキャッシュテーブル、スナップショットまたは正規のデータベーステーブルに）データを記憶することによって分けられてもよい。オフラインアプリケーションが或るページを必要とする場合、クライアントエージェントは、ローカルデータベースに記憶されたデータおよびプレゼンテーション記述からアプリケーションページを再構築する。クライアントエージェントは、オンライン化して有効データおよび／または古いデータを検索してもよく、クライアントエージェントはまた、サーバとのクライアントスナップショットの同期を容易にしてもよい。さらに、クライアントエージェントは、サーバが情報をクライアントキャッシュテーブルまたはデータベースに（たとえばプッシュリスナを用いて）プッシュできるようにし、また、クライアントアプリケーションとの音声ベースの対話をサポートしてもよい。
【００２７】
図１は、この発明の一実施例が実現され得る例示的なモバイルコンピューティング／通信環境を示している。この実施例では、企業サーバ１５０は、直接無線リンク１３０および／またはインターネットを含み得るネットワーク１４０を介してアクセス可能である。モバイル機器１０２ａ−１０２ｄのユーザはしたがって、サーバ１５０に、直接、または一連の通信リンクを介してアクセスする。ユーザのモバイル機器は、ラップトップまたは他のポータブルコンピュータ、ＰＤＡ、電話、双方向ページャ、または他の機器であってもよい。
【００２８】
この発明の一実施例では、クライアントデータベースまたはＤＢＭＳは、任意のキャッシュテーブルに加え、サーバデータの１つ以上のスナップショットを含んでいてもよい。この実施例では、キャッシュテーブルは、データの有効性に関する情報とともに、（たとえばクライアント、任意の遠隔サーバまたは他のシステムなどの）どこにでも生じたかもしれないデータを記憶する。スナップショットは、サーバまたはサーバと明確に同期する他のソースからデータを記憶する。例示的には、スナップショットデータはオフラインの際には常に利用可能であり、一方、キャッシュテーブルは、データの有効性に依存して、オフラインで使用可能な場合もあれば使用できない場合もある。最後に、クライアントにより生成された、および／または使用されただけのデータを記憶するために、正規のデータベーステーブルが用いられてもよい。
【００２９】
キャッシュテーブルの概念
図２は、この発明の一実施例の実現に好適なモバイルクライアント機器のブロック図である。機器２００は、モバイルアプリケーション２１０、データベース２２０、および通信モジュール２３０を含む。
【００３０】
モバイルアプリケーション２１０は、データベース２２０に記憶されたデータを使用または利用するアプリケーションである。データベース２２０は、アプリケーション２１０により使用される任意の種類のデータ（たとえば文字、数字、図表、映像）を記憶するよう構成されてもよい。データベース２２０は、キャッシュテーブル２２２といった、データをキャッシュするための１つ以上のキャッシュテーブルを含む。データベース２２０はまた、関連するキャッシュ制御情報２２４も含む。キャッシュテーブルおよびキャッシュ制御情報に関するさらなる詳細を、以下に提供する。
【００３１】
通信モジュール２３０は、データベース２２０にキャッシュされたデータの現在のバージョンまたはマスタバージョンを記憶するサーバまたはデータソースにアクセスするよう構成されている。このため、以下に説明するように、データベース２２０は、新規データ、新鮮なデータ、キャッシュされたデータへの更新などをダウンロードするために、通信モジュール２３０を介して定期的にサーバにアクセスしてもよい。通信モジュール２３０はデータベースによって直接動作されてもよく、または、データベースはアプリケーション２１０、オペレーションシステムまたは他のエンティティを介して通信モジュールにアクセスしてもよい。このため、通信モジュール２３０は、データベース２２０に加え、またはデータベース２２０の代わりに、モバイルアプリケーション２１０に結合されていてもよい。
【００３２】
ここに説明される発明の実施例では、データベース２２０は、オラクル・コーポレイション（Oracle Corporation）により提供される、オラクル９ｉ  ＬＩＴＥ（ライト）などのＤＢＭＳ（データベース管理システム）製品である。
【００３３】
この発明の一実施例では、キャッシュテーブルを＜Ｓ，Ｃ，Ｏ，Ｐ＞の形の４タプルによって特徴付けることができる。この形では、Ｓはキャッシュテーブルのスキーマまたは構造を定義し、Ｃはキャッシュテーブルに置かれた制約を定義し、Ｏは１組のサポートされた動作を表わし、Ｐは（たとえばモバイル機器がデータソースに接続されている場合、または間欠的に接続されている場合に）キャッシュテーブル内容を検索または更新するための１組のプロトコルを表わしている。
【００３４】
キャッシュテーブルスキーマ
この発明の一実施例では、キャッシュテーブルのスキーマＳは、キャッシュテーブルの名前、キャッシュテーブルの構造を説明する列定義のリスト、およびアクセスパラメータのリストという３つのものによって定義される。キャッシュテーブル名はＳＱＬ（構造化照会言語）データベースのテーブル命名規則に準拠していてもよい。
【００３５】
列定義は識別子と関連するデータタイプとを含む。各識別子はキャッシュテーブルの列名に対応しており、列命名規則に従っていてもよい。アクセスパラメータリストは、キャッシュテーブルの列識別子のサブセットの順序付けられたリストである。
【００３６】
キャッシュテーブルスキーマＳがキャッシュテーブルの構造を説明するため、それはキャッシュテーブルの各インスタンスの構造も定義する。この発明のこの実施例では、キャッシュテーブルインスタンスは、アクセスパラメータのアクセスパラメータ列について同一の値を有するキャッシュテーブルのすべての行を含む。引数は、キャッシュテーブルの各アクセスパラメータにつき１つの値のリストを含む。このため、インスタンスは、同じ引数を有するキャッシュテーブルの１組の行である。
【００３７】
キャッシュテーブルインスタンスの結果セットはインスタンスの１組の行を含み、各行はアクセスパラメータにはない列のリストを含む。つまり、結果セットは、キャッシュテーブルの非アクセスパラメータ列に対するキャッシュテーブルインスタンスの投影である。キャッシュテーブルの或る特定のインスタンスは、キャッシュテーブルの名前、次に対応する引数値によって示されてもよい。
【００３８】
図６は、この発明の一実施例に従った例示的なキャッシュテーブルを示している。在庫キャッシュテーブル６００は、部品♯６０２、倉庫♯６０４、および手持ち量（ＱＯＨ）６０６という３つの列を含む。このキャッシュテーブルでは、アクセスパラメータは部品♯６０２のみを含む。このため、値１２３４および値９８７６という２つの引数が示されている。
【００３９】
これら２つの引数に基づいて、在庫キャッシュテーブルの２つのインスタンスが示されている。一方のインスタンスは部品♯１２３４を有する３つの行を含み、他方は部品♯９８７６を有する２つの行を含む。アクセスパラメータの一部ではないキャッシュテーブル６００の列は、これら２つのインスタンスについての結果セットを形成する。
【００４０】
この発明のこの実施例では、例示的なキャッシュテーブルは、以下のＳＱＬ（構造化照会言語）構文に従って定義されてもよい。
【００４１】
【数１】
2005533324.tif 000003
【００４２】
この例示的なＳＱＬ構文を用いて、サンプルキャッシュテーブルが以下のように定義されてもよい。
【００４３】
【数２】
2005533324.tif 000004
【００４４】
例示されたキャッシュテーブルのスキーマＳは“Inventory（part♯char（４），warehouse char（８），qty number（１０））”である。１つのアクセスパラメータがpart♯と特定される。キャッシュテーブルについての結果セットは１組の行を含み、その各々は
、倉庫識別子と倉庫に保管された特定の部品の量という２つの列を含む。以下のサブセクションは、このサンプルキャッシュテーブル定義の一部をさらに詳細に説明する。
【００４５】
一般に、キャッシュテーブルＴについてのスキーマは、Ｔ（ａ1，…，ａm，ｒ1，…，ｒn）として書かれてもよく、ここでＴはキャッシュテーブル名であり、ａ1，…，ａmはアクセスパラメータのリストであり、ｒ1，…，ｒnはキャッシュテーブル結果セット列である。このため、サンプルキャッシュテーブルは、Inventory（part♯，warehouse，qty）として表わされてもよい。
【００４６】
キャッシュテーブルのインスタンスはＴ（ｖ1，…，ｖm）として書かれてもよく、ここでｖiはアクセスパラメータａiについての値である。このインスタンスでは、タプル＜ｖ1，…，ｖm＞は或る特定のキャッシュテーブルインスタンスの引数を構成しており、対応する結果セットの各行は＜ｒ1，…，ｒn＞の形である。結果セットの各行は別個の結果として考えられてもよい。「キャッシュテーブル」という用語はここでは、或る特定の構造（スキーマ）を有するキャッシュテーブル、またはそのキャッシュテーブルのインスタンスを指すために使用される。
【００４７】
キャッシュテーブルの１組のインスタンスは、そのキャッシュテーブルの「拡張」と呼ばれてもよい。キャッシュテーブルの拡張は、ローカルデータベースまたはＤＢＭＳに記憶されたキャッシュテーブルの全インスタンスを含むよう定義される。キャッシュテーブルＴの拡張はＥ（Ｔ）と書かれてもよい。
【００４８】
１つのキャッシュテーブルについて、isValidおよびisUsableという２つの述語がその拡張の各行に関連して定義される。以下により詳細に説明するように、isValid述語は（たとえば照会実行の時点で）行が有効であるかどうかを判断するために使用され、一方、isUsableはその行が使用可能かどうかを判断するために使用されてもよい。例示的には、行が有効であればそれは使用可能であるが、それが無効であれば、それは使用可能であるかもしれないし、使用できないかもしれない。
【００４９】
この発明の一実施例では、キャッシュテーブルはＳＱＬステートメントにおいて多数の方法で使用されてもよい。キャッシュテーブル名のみ（たとえばInventory）への参照は、キャッシュテーブルの拡張への参照として解釈される。このため、“Select*from Inventory”というＳＱＬステートメントは、現在ローカルデータベースに記憶されているキャッシュテーブルInventoryの全インスタンスの全結果セットのすべての行を戻す。ローカルＤＢＭＳは、行の使用可能性の有効性についてチェックしないかもしれず、キャッシュテーブルインスタンスをリフレッシュしようとしないかもしれない。例示的には、この種の参照は照会に限定される場合があり、更新用には使用可能でないかもしれない。それはキャッシュテーブルの「汚れた読出」と考えられ得る。
【００５０】
アクセスパラメータ用の引数値（たとえば定数）のフルセットを含むキャッシュテーブルへの参照は、キャッシュテーブルの１つのインスタンスを戻す。このため、ステートメントSelect*from Inventory（‘Ｐ１２３’）は、部品番号‘Ｐ１２３’についての“part♯”、“warehouse”および“qty”データのテーブルを戻す。この種の参照では、ローカルＤＢＭＳは（以下に説明する）図３Ａおよび図３Ｂに示すフローチャートを用いて、インスタンスを必要に応じてリフレッシュする。
【００５１】
ＳＱＬステートメント内でのキャッシュテーブルへの別の参照は、引数内に少なくとも１つの変数を含むかもしれない。（たとえば照会における）参照が有効である（つまり、値が変数と結合可能である）場合、この種の参照はキャッシュテーブルの１つ以上のインスタンスを戻す。このため、ステートメントSelect p♯，partName，warehouse，qty Fro
m part P，Inventory（P.p♯）を用いて、部品テーブルの部品番号についての在庫の結果セットを得ることができる。どの値も変数に結合できない場合、照会は無効と考えられる。この種の参照では、ローカルＤＢＭＳは図３Ａおよび図３Ｂに示すフローチャートを用いて、インスタンスを必要に応じてリフレッシュする。
【００５２】
以上の例は、キャッシュテーブルアクセスパラメータが、別のキャッシュテーブルの結果セットを含む別のテーブルの列または式にいかに結合され得るかを実証している。例示的には、キャッシュテーブル列の十分に適格な列仕様は、以下のように、キャッシュテーブル名についてのエイリアスを使用してもよい。
【００５３】
【数３】
2005533324.tif 000005
【００５４】
制約
この発明の一実施例では、任意のキャッシュテーブル拡張（つまりキャッシュテーブルインスタンスのセット）に対して制約が定義されてもよい。このため、キャッシュテーブルの列リストを用いてキャッシュテーブルに対する制約を定義することができる。たとえば、一次キー制約および外部キー制約は、（たとえばそれらが単一の属性キーであるならば）キャッシュテーブルの列の定義において定義されてもよく、または、キャッシュテーブル定義の制約部分における一次キーまたは外部キー句において定義されてもよい。
【００５５】
上に定義されたサンプルInventoryキャッシュテーブルは１つの制約、つまりpart♯およびwarehouseを含む一次キーを含んでいる。これは、所与のpart♯に対し、結果セットが多くの行または結果を含む場合があるものの、結果セットのどの２つの行も同じwarehouse値を持たないということを意味する。
【００５６】
キャッシュテーブルの制約Ｃを定義する場合、いくつかの選択肢がある。たとえば、単一の一次キーを、アクセスパラメータのすべての組合せとして、またはアクセスパラメータのすべてといくつかの結果セット識別子との組合せとして定義してもよい。例示的には、Inventoryキャッシュテーブルのアクセスパラメータ‘part♯’がキャッシュテーブルの一次キーとして定義された場合、‘part♯’の或る特定の値について戻されたデータは多くて単一の行を含み得る。これに対し、一次キーが‘part♯’と‘warehouse’の組合せとして定義された場合、‘part♯’の所与の値に対して多数の行が戻され得るものの、‘warehouse’についての値は‘part♯’の各値について一意的である。
【００５７】
この発明の一実施例におけるすべてのキャッシュテーブルに対し、ナルでないシステム制約が各アクセスパラメータについて自動的に定義される。キャッシュテーブルの拡張に対してさらなる制約が定義されてもよい。結果セットがデータソースから受取られ、インスタンスがそれらから構築された場合にはいつでも、ＤＢＭＳはこれらの制約に基づいてデータ完全性チェックを実行する。完全性制約はまた、キャッシュテーブルのストレージを最適化するためにも使用されてもよい。たとえば、および上述のように、一次キーがキャッシュテーブルのアクセスパラメータのいずれか（またはすべて）に対して定義された場合、各結果セットは引数に対して多くて１つの行を含み、キャッシュテーブルの拡張は１つの物理的テーブルに記憶されてもよい。
【００５８】
概念上、キャッシュテーブルＴに対する制約は、Ｅ（Ｔ）に対して定義された制約であ
る。この発明の一実施例では、一次キーがキャッシュテーブルのアクセスパラメータのいずれか（またはすべて）に対して定義されている場合、ＤＢＭＳはＥ（Ｔ）を単一の物理的テーブルに記憶してもよい。そのキャッシュテーブルに対して定義されるすべての制約はＥ（Ｔ）に対する制約と考えられてもよい。
【００５９】
例示的には、キャッシュテーブルインスタンスをリフレッシュすることは、インスタンスの結果セットをデータソースの対応するＴＤＰ（テーブルデータプロセッサ、以下に説明する）から検索し、各結果についての引数から行を作成し、その行をＥ（Ｔ）に挿入することを含む。制約チェックは、Ｅ（Ｔ）に対する挿入、削除および更新動作のために正規の態様で実行されてもよい。
【００６０】
キャッシュテーブルが別のキャッシュテーブルの引数全体を含む一次キーを参照する外部キーを有する場合、ＤＢＭＳは、第２のキャッシュテーブルのインスタンス上でカーソルを開くことによって外部キー制約をチェックしてもよい。インスタンスが存在し、かつ有効であるまたはロックされている場合、制約は満たされていると考えられる。インスタンスが存在しない場合、または無効である場合、ＤＢＭＳは結果セットをデータソースから検索またはリフレッシュしようとする。データソースが結果を戻す場合、それはキャッシュされ、制約は満たされていると考えられる。データソースへの接続がない場合、エラーが報告される。
【００６１】
動作
この発明の一実施例では、キャッシュテーブルについてサポートされる動作Ｏは、キャッシュテーブル定義の“Using”句において定義されてもよい。例示的には、Using句は、データソースの名前、テーブルデータプロセッサ（ＴＤＰ）の名前、およびＴＤＰのタイプを特定してもよい。
【００６２】
キャッシュテーブル動作の実現化例は、データソースをホストし、かつモバイルアプリケーションに定期的にアクセス可能なサーバまたは他の位置に存在する。実現化例は、対応する動作がキャッシュテーブル上で行なわれると、ローカルＤＢＭＳによって呼出される。また、これに代えて、いくつかの動作実現化例がモバイル機器上に存在していてもよい。
【００６３】
この発明の一実施例では、キャッシュテーブル作成のUsing句部分は、以下のＳＱＬ構文を採用してもよい。
【００６４】
【数４】
2005533324.tif 000006
【００６５】
この発明のこの実施例では、読出専用および修正可能という２種類のＴＤＰがサポートされている。修正可能なＴＤＰは、挿入可能、削除可能、および更新可能の任意の組合せであってもよい。挿入可能なＴＤＰは、行がキャッシュテーブル拡張に挿入されるようにし、行がキャッシュテーブルインスタンスに挿入された後でローカルＤＢＭＳが読出す挿入方法を実現する。同様に、削除可能なＴＤＰは削除方法を実現して、行がキャッシュテーブルから削除されるようにし、更新可能なＴＤＰは更新方法を実現して、（たとえば列値を変更するために）行が更新されるようにする。上述のように、ＴＤＰはキャッシュテーブル上で行なわれ得る動作をモデル化する。
【００６６】
例示的には、読出専用ＴＤＰは「選択」方法のみを実現しており、それは引数（つまり、キャッシュテーブルのアクセスパラメータについての値のセット）を取って、結果セットを含む１組の行を戻す。使用され得るプロトコルを以下のセクションで説明する。
【００６７】
これに対し、修正可能なＴＤＰは、「選択」方法だけでなく、対応するUsing句において宣言されたＴＤＰの種類に依存して「挿入」、「削除」および／または「更新」方法も実現しなければならない。この発明の一実施例では、クライアント機器またはアプリケーションがキャッシュテーブルを更新しようとする場合、ローカルデータベースはまず、内容がまだ有効かどうかを（以下に示すように）判断する。有効である場合、内容は更新され、ＴＤＰ上の対応する方法が呼出される。方法が失敗を戻すと、更新は動作が始まる前の点にロールバックされる。内容が無効であった場合、データベースはＴＤＰに要求（たとえば挿入、削除、更新）を送信し、新しい結果セットが戻されるべきであることを示す。
【００６８】
“data source name”フィールドは、ローカルデータベースとは別個であってもよいデータソースを指す。データソースはローカルＤＢＭＳに十分な情報を提供して、ＤＢＭＳがソースの能力およびプロトコルを理解できるようにするよう構成されている。データソースはまた、キャッシュテーブルインスタンスの結果セットの有効性および／または使用可能性の期間も特定してもよい。例示的には、データソースはウェブサーバ、アプリケーションサーバ、データベースサーバまたは他のソースを含んでいてもよい。
【００６９】
データソースは１つ以上のＴＤＰを実現してもよく、各ＴＤＰは、キャッシュテーブルの代わりに、動作を容易にする１つ以上の方法をデータソース上に提供する。この発明のこの実施例では、各ＴＤＰは、クライアントＤＢＭＳによって呼出された場合にキャッシュテーブルインスタンスの結果セットを供給する責任がある。ＴＤＰは挿入、削除、更新、および／または他の動作を行なう論理を実現してもよい。
【００７０】
上述のサンプルキャッシュテーブル作成（キャッシュテーブル“Inventory”）に関連して、データソースは以下の拡張されたＳＱＬ構文を用いて定義されてもよい。
【００７１】
【数５】
2005533324.tif 000007
【００７２】
“data source name”フィールドはデータベーススキーマ内で一意的である。
【００７３】
データソースＴＹＰＥフィールドは、データソースの能力（たとえばlocal、basic、au
th、database）を規定する。
【００７４】
例示的には、“local”データソースは、クライアント（モバイル）機器上で実現されるデータサーバであってもよく、ＰＩＭ（個人情報管理）データベース、電子メール、アドレスブックなどにアクセスするために使用されてもよい。ローカルＤＢＭＳは、所与のクライアント機器のためにローカルデータソースを予めロードしてもよい。この実施例では、（上述の“protocol name”フィールドにおいて特定される）ローカルデータソース用に採用されるプロトコルは、ＯＭＣ（オラクルモバイルクライアント）である。
【００７５】
“basic”データソースは、http、ウェブサービス要求、または同様の要求を受付けることができる単純なデータソースである。それは一般にセッションレスサーバであり、要求元を認証したりトランザクションをサポートすることはないかもしれない。したがって、＜authentication＞句はbasicデータソースについては削除されてもよい。
【００７６】
この実施例では、“auth”データソースは、クライアント認証（たとえばクライアントはログインしてセッションオブジェクトを入手しなければならない）を要求するデータソースである。authデータソースについての＜authentication＞句は、ソースにログインするためのユーザ名およびパスワードを提供する。authデータソースを提供するサーバはログインおよびログアウト方法をサポートし、ログイン方法はセッションオブジェクトを戻す。
【００７７】
“database”データソースは、「トランザクション開始」、「コミット準備」、「コミット」および「ロールバック」といったデータベース動作をサポートし得る認証データソースである。サーバがキャッシュテーブル更新（たとえばキャッシュテーブルにおける行の挿入、削除または更新）をサポートする少なくとも１つのＴＤＰをホストする場合、データソースはトランザクショナルであってもよい。
【００７８】
上に例示したキャッシュテーブル作成に関連して、キャッシュテーブル作成のUsing句において識別されたデータソースMyCompanyDSは以下のように定義されてもよい。
【００７９】
【数６】
2005533324.tif 000008
【００８０】
プロトコル
この発明の一実施例では、ローカルＤＢＭＳとデータソースまたはＴＤＰとの間で通信するためのプロトコルは、キャッシュテーブルの４タプルの部分Ｐで定義される。特に、Ｐは、１つ以上のプロトコル（たとえばＳＯＡＰ、ＨＴＴＰなど）、および、データソースまたはＴＤＰからの応答に用いられるＸＭＬタグまたは他の仕組み（たとえばＨＴＭＬタグ）を識別する。
【００８１】
クライアントＤＢＭＳは、サポートされたプロトコルのうちのいずれか１つを用いてデータソースと通信してもよい。用いられるプロトコルにかかわらず、この発明の一実施例では、クライアントＤＢＭＳは表１のデータ項目のいずれかまたはすべてをデータソースと交換してもよい。
【００８２】
【表１】
2005533324.tif 000009
【００８３】
用いられるプロトコルがＨＴＴＰである場合、キャッシュテーブルインスタンスの引数はＰＯＳＴ法の一部としてＸＭＬ文書で送られてもよい。選択方法の結果は、ヘッダおよび本文を含むＸＭＬ（拡張可能マークアップ言語）文書であってもよい。ヘッダはキャッシュ制御情報を含んでいてもよく、本文は結果セットを構成する１組の行を含んでいてもよい。例示的には、本文はＯＭＣキャッシュテーブル結果セットフォーマットに準拠したＸＭＬ文書として符号化されてもよく、または、それはよりコンパクトなオラクルライトＣＳＶ（コンマで区切られた値）ファイルとして符号化されてもよい。
【００８４】
挿入および削除方法は、引数（つまりアクセスパラメータ値のセット）と、クライアントがキャッシュテーブルへ挿入したい、または以前に挿入した単一の行を表わす列値のリストとを受付けてもよい。更新方法は、引数と、単一の古い行を表わす列値のリストと、更新を表わす別のリストとを取ってもよい。すべての方法についての全データは、ＨＴＴＰ  ＰＯＳＴ法でＸＭＬ文書として送られる。
【００８５】
この発明の一実施例では、要求フォーマットはＨＴＴＰ  ＰＯＳＴ要求であり、用いられるＵＲＬはデータソースのそれである。ユーザエージェントストリングは“Oracle Lite”である。そのためたとえば、引数‘ｐ１２３’についてのInventoryキャッシュテーブルのインスタンスを得るＨＴＴＰ要求は、以下のようになってもよい。
【００８６】
【数７】
2005533324.tif 000010
【００８７】
要求ヘッダはIf-Modified-Sinceなどのいくつかの追加情報を含んでいてもよい。
【００８８】
要求への応答は、ヘッダと本文とを含むＸＭＬ文書である。応答についてのフォーマットは付録Ｂで説明される。
【００８９】
この発明の一実施例における応答ヘッダは、以下の情報のいずれかまたはすべてを含んでいてもよい。
【００９０】
応答日（Response Date）−データソースクロックに従った、３つのＨＴＴＰフォーマット（たとえばＲＦＣ１１２３）での応答の日付
最終修正（Last-Modified）−データがデータソース上で（同様にＨＴＴＰ日付フォーマットにおいて）最後に修正された日付
満了（または満了日）（ExpiresまたはExpiration Date）−データがその日まで有効であると考えられるべき日付
有効期間（Time-To-Live）−データがどれぐらいの期間有効であると考えられ得るかを示し、秒単位で表わされる
古さ（Staleness）−結果セットをリフレッシュするネットワーク接続がない場合に、古い（期限切れの）結果セットが使用可能かどうか、およびどれぐらいの期間使用可能かを示す、ゼロよりも大きい整数である。古さ値１がデフォルトであり、古い結果セットが全く使用できないことを示している。古さ値がｎである場合、それは、古い結果セットが有効期間値のｎ倍まで使用可能であることを示す。
【００９１】
表１に示すように、図７〜１１は、クライアント機器とデータソースとの間で通信するために使用可能なＸＭＬ文書のサンプルフォームを示している。
【００９２】
図７Ａ−Ｂは、サンプルの応答文書フォーマット７０２、７０４を示している。各フォーマットはヘッダと本文とを含む。ヘッダは、サーバ識別情報、クライアント識別情報、キャッシュ情報（たとえば日付、最終修正、満了、有効期間、古さ）、ＴＤＰ名、結果セットについての引数、キャッシュテーブルスキーマ、日付フォーマットなどを含んでいてもよい。本文は１つ以上の行セットを含み、その各々は、行セットフォーマット、作用（たとえば置き換え、挿入、削除、更新）、区切り文字などを識別してもよい。応答フォー
マット７０２の本文はＸＭＬフォーマットであり、一方、応答フォーマット７０４の本文はＣＳＶフォーマットである。
【００９３】
図８は、サンプルの選択要求文書８００を示している。図９はサンプルの挿入要求文書９００を示している。図１０はサンプルの削除要求文書１０００を示している。図１１はサンプルの更新要求文書１１００を示している。
【００９４】
キャッシュテーブル動作
上述のように、この発明の一実施例では、クライアントアプリケーションがキャッシュテーブルに関する動作（たとえば照会）を発行すると、ローカルデータベースまたはＤＢＭＳは、所与のセットのアクセスパラメータを有するキャッシュテーブルについてのインスタンスが既にキャッシュされているか、および依然として有効かどうかを判断する。そうである場合、キャッシュされた結果セットを動作に使用してもよい。その他の場合、ちょうど上述したように、データベースは、結果セットを検索するために、キャッシュテーブルについて定義されたＴＤＰに対して選択方法を呼出す。ＴＤＰからの応答は、前のセクションで述べたキャッシュ制御パラメータのいずれかまたはすべてを含むヘッダを含んでいてもよい。
【００９５】
図３Ａ−Ｂは、この発明の一実施例に従った、キャッシュテーブルインスタンスを更新、検索またはリフレッシュするかどうかを判断するためのアルゴリズムを示すフローチャートを含んでいる。このアルゴリズムでは、現在の日付（Current Date）はクライアントマシン上での現在の日付／時間を指している。
【００９６】
図３Ａ−Ｂのアルゴリズムでは、キャッシュテーブルのキャッシュされたインスタンスは、それが（たとえば有効期間パラメータまたは満了日パラメータにより定義されるように）その満了前に使用される場合、「有効」として考えられてもよい。このインスタンスは、（１）それが「有効」である場合、（２）それがトランザクションによりロックされている場合、または（３）それは満了しているが（データソースへの通信リンクが利用できないため）（古さパラメータから計算されるように）古くなる前に使用中である場合に、トランザクションによって「使用可能」であると考えられてもよい。より正式には、以下のようになる。
【００９７】
【数８】
2005533324.tif 000011
【００９８】
状態３００で、動作（たとえば照会）がローカルデータベースまたはＤＢＭＳ（データベース管理システム）によって受取られる。動作は、データベースが記憶するよう構成されている１つ以上のキャッシュテーブルインスタンスにかかわるものである。
【００９９】
状態３０２で、ＤＢＭＳは、これが動作の一部として提供された引数に関する最初の動作であるかどうかを判断する。より一般的には、ＤＢＭＳは、結果セットが有効か、使用可能か、古いか、または何か他の状態にあるか否かにかかわらず、引数に対応する結果セットをそれが有しているかどうかを判断してもよい。これがこの引数についての最初の動作である場合（たとえばデータベースが引数に関する結果セットを含んでいない場合）、例示された方法は状態３０４で継続する。その他の場合、方法は状態３１０へ進む。
【０１００】
状態３０４で、ＤＢＭＳは、キャッシュテーブルに関連するテーブルデータプロセッサ
へ向けられるべき、引数に対応する結果セットに対する要求を、データソースへ発行する。
【０１０１】
状態３０６で、結果セットに対し、新しいキャッシュテーブルインスタンスがＤＢＭＳにおいて生成され、動作を満たすために使用される。例示的には、キャッシングヘッダはクライアント機器上に記憶されてもよい。方法はそこで終了する。（たとえば状態３０４において）データソースに接触して結果セットを得ることができない場合、データベースによってエラーが合図されてもよい。
【０１０２】
状態３１０では、引数に関する以前の結果セットがキャッシュテーブル内に配置されており、ＤＢＭＳは、それが現在のトランザクションによって現在ロックされているかどうかを判断する。この発明のこの実施例では、現在のトランザクションのトランザクション分離レベルが「反復可能読出」または「直列可能」（ロックされている結果セットを勘案）である場合、ＤＢＭＳは現在のトランザクションについて結果セットをリフレッシュしない。現在のトランザクションが結果セットを既にロックしている場合、例示された方法は状態３１６に進む。
【０１０３】
その他の場合、状態３１２で、ＤＢＭＳは、現在のトランザクションがキャッシュされた結果セット上にアクティブカーソルを有するかどうかを判断する。この発明のこの実施例では、現在のトランザクションのトランザクション分離レベルが「読出コミット済」（アクティブカーソルおよびノーロックを勘案）である場合、ＤＢＭＳは読出一貫性およびカーソル安定性を提供するために結果セットを更新しない。現在のトランザクションが結果セット上で開かれたアクティブカーソルを有する場合、方法は状態３１６に進む。
【０１０４】
その他の場合、状態３１４で、ＤＢＭＳは、キャッシュされた結果セットが有効かどうかを判断する。上で特定されたように、結果セットについての有効期間パラメータまたは満了日がまだ超過されていない場合（たとえばResponse Date＋Time-To-Live≧Current Date）、結果セットは有効であると考えられてもよい。キャッシュされた結果セットが有効でない場合、例示された方法は状態３１６で継続する。その他の場合、方法は状態３２２へ進む。
【０１０５】
状態３１６で、ＤＢＭＳは、キャッシュテーブルに関連するデータソース（たとえばＴＤＰ）にとって接続が利用可能かどうかを判断する。接続が利用可能である場合、方法は状態３２４へ進む。
【０１０６】
状態３１８では、データソースにとって接続が利用可能ではなく、キャッシュされた結果セットが無効であることがわかっており、そのためデータベースは、結果セットが使用可能かまたは古いかを判断する。例示的には、（Response Date＋（Time-To-Live*Staleness）＜Current Date）である場合、結果セットは古いと考えられてもよい。キャッシュされた結果セットがまだ古くなっていない場合、方法は状態３２２へ継続する。
【０１０７】
その他の場合、キャッシュされた結果セットは有効ではなく、古くなっており、かつ、キャッシュテーブルインスタンスをリフレッシュできるデータソースにとって接続が利用可能ではない。したがって、状態３２０でＤＢＭＳはエラーを合図し、方法は終了する。
【０１０８】
状態３２２で、現在の動作を満たすためにＤＢＭＳの既存の結果セットが用いられる。手順はここで終了する。
【０１０９】
状態３２４で、現在キャッシュされている結果セットは無効であると考えられるが、データソースにとって接続が利用可能であり、そのためリフレッシュ動作が要求される。例
示的には、リフレッシュ要求は、結果セットの以前のリフレッシュの最終修正日を反映するIf-Modified-Sinceヘッダを含んでいてもよい。最終修正日が最終リフレッシュまたは更新から利用できない場合、代わりに応答日が使用されてもよい。
【０１１０】
状態３２６で、ＤＢＭＳは、要求に応答して何らかの更新が受取られたかどうかを判断する。例示的には、結果セットが最後にローカルＤＢＭＳに提供されてから更新されていないことをＴＤＰが（データソースを介して）見つけた場合、更新は送られない。何らかの更新が受取られた場合、例示された方法は状態３３０へ進む。
【０１１１】
その他の場合、更新が受取られなかったため、状態３２８において、キャッシュ制御情報が適切に更新され、キャッシュされた結果セットが現在の動作に用いられる。例示的には、応答で受取られた任意のキャッシュ制御情報を用いて、既存のキャッシュ制御情報を更新または上書きする。方法はそこで終了する。
【０１１２】
状態３３０で、ＤＢＭＳは、キャッシュされた結果セットが現在別のトランザクションによって使用中かどうかを判断する。
【０１１３】
状態３３２では、結果セットが使用中で、そのためＤＢＭＳはそれをコピーし、そのコピーを結果セットの最新バージョンとしてマークする。最新バージョン以外のコピーは、それらを使用するトランザクションが終了すると削除されるようマークされてもよい。
【０１１４】
次に、状態３３４で、ＤＢＭＳは、データソースから受取られた更新に従って結果セットを更新し、更新された結果セットを現在の動作に使用する。例示された方法はここで終了する。
【０１１５】
ローカルクロックとサーバ（データソース）クロックとの同期が問題であるこの発明の一実施例では、応答日の代わりにローカル日付値が計算および使用されてもよい。また、（応答に含まれない場合）有効期間値を計算するために、応答日または満了日が使用されてもよい。
【０１１６】
読出専用キャッシュテーブル
この発明の一実施例では、照会または他のキャッシュテーブル動作がキャッシュテーブルＴを名前のみによって（つまり引数なしで）参照する場合、Ｅ（Ｔ）（つまりキャッシュテーブルの拡張）上でカーソルが開かれる。カーソルは、インスタンスが使用可能かどうかにかかわらず、Ｅ（Ｔ）内の各インスタンスの最新バージョンを通って繰り返す。ローカルＤＢＭＳはインスタンスをリフレッシュまたはロックしようとしない。しかしながら、何か他のトランザクションがその上でカーソルを開く場合、Ｅ（Ｔ）内のインスタンスはリフレッシュされてもよい。更新動作は引数を提供しなければならず、したがってキャッシュテーブルを名前のみによって参照しないことを思い出すべきである。
【０１１７】
照会が或る特定のキャッシュテーブルインスタンス、たとえばＴ（ｖ1，…，ｖm）（ここで各ｖiは定数である）を参照する場合、ＤＢＭＳはインスタンスが使用可能かどうかをチェックする。そうであれば、カーソルがその上で開かれ、そうでない場合、ＤＢＭＳはそれをリフレッシュしようとする。必要なデータソースにとって接続が利用できない場合、エラーが戻されてもよい。
【０１１８】
この発明の一実施例では、キャッシュに対して照会を発行するトランザクションが「読出コミット済」分離レベルにある場合、その照会は引数を含んでおり、影響を受けるキャッシュテーブルインスタンスにロックはかからない。トランザクションが「反復可能読出」分離レベルにある場合、読出ロックがインスタンスにかかる。トランザクションが「直
列可能」分離レベルにある場合、読出ロックはインスタンスおよびＥ（Ｔ）にかかってもよい。
【０１１９】
所与のトランザクションがキャッシュテーブル上でカーソルを閉じ、次にそれを再び開く場合、リフレッシュ方針はトランザクション分離レベルに依存してもよい。例示的には、トランザクション分離レベルが読出コミット済であれば、カーソルが再び開かれる前にキャッシュが使用不可能となった場合に、キャッシュされた内容はリフレッシュされる。トランザクションレベルが反復可能読出または直列可能のいずれか（読出ロックがインスタンスにかかっている）である場合、内容が満了したかどうかにかかわらず、再び開かれたカーソルについて同じ内容が使用されてもよい。
【０１２０】
キャッシュテーブルＴについて、異なるインスタンスは有効性の異なる期間を有していてもよい。たとえば、キャッシュテーブルインスタンスＴ1（ｖ1，…，ｖm）の有効性の期間は１時間で、一方、キャッシュテーブルインスタンスＴ2（ｕ1，…，ｕm）の有効性の期間は３０分であってもよい。この例では、（ｖ1，…，ｖm）および（ｕ1，…，ｕm）は引数である。例示的には、インスタンスの有効性期間は結果セットを得たデータソースによって設定され、クライアントＤＢＭＳは、依然として有効なキャッシュテーブル内容をリフレッシュしないかもしれない。
【０１２１】
この発明の一実施例では、ローカルＤＢＭＳは、結果セットの有効性期間に関する閉世界仮説を立て、キャッシュテーブル内容（結果セット）が依然として有効であればリフレッシュしない。それはまた、リフレッシュ中にデータソースから得られたどの内容もソースでコミットされたデータを含むということを仮定している。
【０１２２】
更新可能なキャッシュテーブル
更新可能なキャッシュテーブルについては、この発明の一実施例では、たった１つのトランザクションが一度に１つのキャッシュテーブルインスタンスを更新してもよい。この実施例では、更新されたキャッシュテーブルインスタンスに書込ロックがかかる。
【０１２３】
トランザクションが更新可能なキャッシュテーブルインスタンスを更新すると、更新はまず、結果セットが依然として有効である場合、または既にこのトランザクションについてロックされている場合には、結果セットに適用される。次に、ＴＤＰの対応する更新方法がデータソースで呼出される。例示的には、方法が失敗すると更新は失敗する。
【０１２４】
キャッシュテーブルインスタンスが更新されるときにデータソースへの接続が利用可能でなければ、エラーが報告される。そして、更新の適用中に何らかのエラーがある場合には、ＤＢＭＳはデータソースでトランザクションをロールバックする。
【０１２５】
キャッシュテーブルＴのインスタンスは、照会のための読出一貫性、カーソルの安定性の一単位であり、この実施例では、更新可能なキャッシュテーブルの並行処理制御のためにロックされ得る最小オブジェクトである。正式には、キャッシュテーブルインスタンスはＥ（Ｔ）のサブセットであり、サブセットの全行は同じ引数を有する。
【０１２６】
【数９】
2005533324.tif 000012
【０１２７】
キャッシュテーブルインスタンスは、この実施例では、インスタンス上で開かれるカー
ソルが、応答日と有効期間との合計によりマークされる期間の終了前に開かれた場合、およびその場合に限り、有効である。
【０１２８】
【数１０】
2005533324.tif 000013
【０１２９】
キャッシュテーブルインスタンスの結果セットは、この実施例では、それが（１）有効である場合、（２）更新のためのトランザクションによってロックされている場合、または（３）カーソルがインスタンス上で開かれ、かつインスタンスがその古さ制限をまだ超えていないときに、データソースにとって接続が利用できない場合、およびその場合に限り、使用可能である。
【０１３０】
【数１１】
2005533324.tif 000014
【０１３１】
この発明の一実施例では、カーソルがインスタンスの行に位置付けられている場合はいつでも、そのインスタンスは修正できない。別のトランザクションが同じインスタンス上でカーソルを開こうとすると、ローカルＤＢＭＳはそのインスタンスについての結果セットをデータソースから検索し、新しいインスタンスを生成する。新しいインスタンスはインスタンスの最新バージョンとなり、他のすべてのバージョンはそれらのカーソルが動かされるとパージされる。
【０１３２】
インテリジェントクライアントエージェント
この発明の一実施例では、モバイルクライアント機器上でのオフラインまたはモバイルアプリケーションの動作を容易にするために、インテリジェントクライアントエージェントが提供される。より特定的には、この実施例では、クライアントエージェントは、ユーザとの音声対話、サーバからクライアントへのデータのプッシング、および遠隔データ（つまりクライアント上以外の場所に記憶されたデータ）への選択的なオンラインアクセスといった、１つ以上の特徴を有するモバイルアプリケーションを向上させる。
【０１３３】
クライアントエージェントはまた、ユーザに提示されるべき内容の、その内容が提示されるべきフォーマットからの分離を可能にしてもよい。例示的には、後者の利点により、クライアントは、特定されたプレゼンテーションフォーマットおよびそのフォーマットを用いて表示され得るデータの１つ以上の組から、実行中にページを生成できるようになる。ページは次に、好適なクライアントブラウザによって表示されてもよい。
【０１３４】
たとえば、在庫データへのアクセスに関するモバイルアプリケーションのために実現されるこの発明の一実施例では、クライアントエージェントは、このデータについてのプレゼンテーション記述またはフォーマットが在庫データとは別個に記憶されるようにする。このため、プレゼンテーションフォーマットは、所与の部品番号について、部品名、記述、価格、手持ち量などの情報を提示するよう構成されていてもよい。データはデータベー
ス、キャッシュ、キャッシュテーブルまたは他の構造に記憶されてもよい。ユーザが或る特定の部品番号を提供すると、対応するデータが検索され、プレゼンテーションフォーマットと組合されてユーザに表示される。
【０１３５】
例示的には、プレゼンテーションフォーマットまたはプレゼンテーション記述ページには、変数、フィールド名、またはデータおよび内容項目を表わす他のプレースホルダ、および、ローカルデータベース内のデータがプレースホルダを置き換えるためにいかに使用可能かを制御するために使用され得るスプリクト言語でのコマンドが配置されてもよい。インテリジェントクライアントエージェントのスクリプトエンジンは、ページにおいてスクリプト言語を実行し、ページがブラウザに戻される前にプレースホルダを実際の値と置き換える。
【０１３６】
当業者であれば、以前のモバイルアプリケーションまたはオフラインアプリケーションが、内容をプレゼンテーションフォーマットと組合せる静的なモノリシックのページを記憶するよう構成されていたことを理解するであろう。その結果、内容の各セットは別個のページとして記憶され、それにより、より大きな記憶容量を必要とし、より低い柔軟性を提供していた。たとえば、記憶されたページのたった１つのデータ項目のみを更新する必要がある場合、その項目を含むページ全体を検索しなければならなかった。そして、その１つの項目が多数のページの一部であった場合には、それらのページの各々を検索しなければならなかった。
【０１３７】
モバイルクライアント機器においてキャッシュテーブルとともにインテリジェントクライアントエージェントを実現することは、データにローカルに（たとえばオフラインで）アクセスするものの、選択された（たとえば揮発性の高い）データへのオンラインアクセスも利用可能であるハイブリッドオンライン／オフラインアプリケーションの開発および使用を容易にする。モバイルアプリケーションはまた、十分にオフラインで動作され、オンラインに戻されたときにデータ変更、完了したフォームおよび他の情報を提出してもよい。さらに、内容およびアプリケーションは動的にダウンロードされ、クライアントにプッシュすらされてもよい（たとえば新しい旅程、１組のタスクへの変更）。
【０１３８】
この発明の一実施例では、モバイルクライアント機器に記憶された内容は、予め定められたスキーマに従って記憶されてもよい。そのスキーマに従って、内容はデータベーステーブル、データサーバ内容のスナップショット、キャッシュテーブルまたは他の構造に記憶されてもよい。たとえば、データをデータベーステーブルに記憶することにより、クライアントエージェントは容易に、かつ明確にデータをロードおよびリフレッシュできる。データをスナップショットに記憶させることは、（以下により詳細に説明されるような）サーバからクライアントへの新規／更新データのプッシュを容易にするかもしれない。前のセクションで説明されたような、データをキャッシュテーブルに記憶させることは、データのためのインテリジェントリフレッシュ方針の使用、および実質上任意のソース（たとえばサーバ）からのオンデマンドローディングを可能にする。スキーマは、検索、ロード、更新などされるべきデータの場所を示すＵＲＬ（ユニフォームリソースロケータ）を含んでいてもよく、またはそれと関連付けられていてもよい。
【０１３９】
上述のように、内容をその内容についてのプレゼンテーションフォーマットから分けることに加え、クライアントエージェントの一実施例は、ユーザが音声を用いてモバイルアプリケーションと対話することを可能にしている。上述の例では、たとえば、ユーザが部品番号を話し、モバイルアプリケーションが関連する在庫データを話すことによって応答してもよい。これは、ユーザが車両を操作している場合、または他の状態で自分の目または手を別のタスクからそらすことができない場合に特に価値があり得る。クライアントエージェントのこの実施例では、音声ユーティリティ、または音声からテキストへの、およ
びテキストから音声への変換器の構成要素（たとえば文法チェッカー、音素）がクライアント機器のオペレーティングシステムの一部として、またはモバイルアプリケーションの一部としてインストールされてもよい。
【０１４０】
この発明の一実施例のためのクライアント機器を構成するプロセスは、１組のアプリケーションページまたはモジュール、そのアプリケーションについての内容またはデータ、スキーマページ、ユーティリティ（たとえば音声アプリケーションまたはユーティリティ）、ブラウザなどをその機器にダウンロードすることを伴うかもしれない。ユーザからデータまたは内容を引出すよう、もしくはデータまたは内容をユーザに提供するよう設計されたアプリケーションページは、（上述のような）プレゼンテーション記述またはフォーマットとして表現されてもよい。この発明のこの実施例に従って構成されたモバイルアプリケーションについては、ダウンロードページは、アプリケーションページ（プレゼンテーションフォーマット）、音声ファイル、スキーマページなどのいくつかまたはすべてを識別してもよい。ダウンロードページのローディングまたはブラウジングは、各構成要素のローディングまたは検索を自動的にトリガしてもよい。
【０１４１】
この発明の一実施例では、ダウンロードページは好適なスクリプト言語で書かれたプログラムを含んでいる。プログラムは、ダウンロードすべき項目および行なうべき動作を識別する特別なタグまたはマーカ（たとえば「インポート」、「スキーマ」）を含んでいる。このため、ダウンロードページは、キャッシュされるべきページまたは他の内容の単なるリスト以上のものである。
【０１４２】
図４は、この発明の一実施例に従った、インテリジェントクライアントエージェントが備わったモバイルクライアント機器を示している。この実施例では、クライアント機器４００は、ＰＤＡ、スマート電話、ハンドヘルド、ラップトップまたはノートブックコンピュータ、もしくは何か他のモバイルコンピューティング機器であってもよい。
【０１４３】
クライアント４００は、データベース４２０、クライアントエージェント４４０、およびブラウザを含む。クライアントブラウザは、ＨＴＭＬ（ハイパーテキストマークアップ言語）、ＸＭＬ（拡張可能マークアップ言語）、または現在公知のもしくはこれから開発される任意の他のマークアップ言語と互換性があってもよい。ブラウザは、以下に説明されるような好適なプロトコル識別および取扱いを有して構成される。クライアントエージェント４４０は、ＯＤＢＣ（オープンデータベースコネクティビティ）、ＪＤＢＣ（Java（登録商標）データベースコネクティビティ）または何か他のインターフェイスを用いて、データベース４２０と対話する。
【０１４４】
クライアントエージェント４４０はしばしばオフラインモードで動作してもよいが、それは必要であれば（たとえば以下に説明されるように）オンラインで動作してもよく、そのとき、それは無線（または有線）ネットワークを介して１つ以上のサーバと連動してもよい。クライアントエージェント４４０は、クライアント４００上にJava（登録商標）バーチャルマシン（ＶＭ）を必要とせずに、この発明の１つ以上の実施例のために以下に説明されるように動作してもよい。
【０１４５】
データベース４２０は、前のセクションで説明された１つ以上のキャッシュテーブル４２２と、対応するキャッシュ制御情報４２４とを含む。データベースはまた、サーバからコピーされたデータの１つ以上のスナップショット４２６と、データテーブル４２８とを含んでいてもよい。例示的には、データベース４２０は、Oracle 9i、9iLite、またはオラクル・コーポレイションにより提供される別のＤＢＭＳであってもよい。
【０１４６】
この発明の例示された実施例の一実現化例では、テーブル４２８などのデータベーステ
ーブルは、データサーバと同期していない、ローカルに有用なデータを含んでいる。スナップショット４２６は、データサーバと周期的に同期するかもしれない（データサーバからの）データのサブセットを含んでいる。キャッシュテーブル４２２は、有効性の特定された期間を有するデータを含んでおり、（たとえば要求されたキャッシュテーブル内容が古い場合に）前のセクションで説明されたようにリフレッシュされてもよい。
【０１４７】
クライアントエージェント４４０のキャッシュ４４２は、ブラウザにより表示されるべきページのプレゼンテーション記述またはフォーマットを記憶するよう構成されている。上述のように、プレゼンテーションフォーマットには、内容の多数の異なるセットが必要に応じて配置されてもよく、それにより、アセンブルされた各ページを記憶する必要性がなくなる。キャッシュ４４２はまた、データベース４２０から選択されたデータをキャッシュしてもよい。
【０１４８】
ディスパッチャ４４４は、ブラウザによって定義されたインターフェイスを実現して、それ自体をプロトコルハンドラとして登録する。ディスパッチャはブラウザからページ要求を受取り、アセンブルされたページをブラウザに渡す。この発明の一実施例では、ディスパッチャ４４４は、１つ以上の特定されたプロトコルに対応するページ要求のみを受取る。たとえば、ブラウザはオラクルモバイルクライアント（ＯＭＣ）プロトコルに対するページ要求をディスパッチャに送るよう構成されていてもよく、そのような要求は“omc://www.oracle.com”の形のＵＲＬを含んでいてもよい。例示的には、正規のＨＴＴＰ（ハイパーテキスト転送プロトコル）要求（たとえば“http://www.oracle.com”）がディスパッチャによってサーバに（たとえば無線ネットワークを介して）提出されてもよい。要求されたページがキャッシュされる場合、ディスパッチャ４４４はアセンブルされたページをブラウザに送る。要求されたページがキャッシュされない場合、要求は遠隔サーバに送られてもよい。遠隔サーバに送られた要求は要求元４５０により取扱われてもよく、および／または待ち行列４５２を介して処理されてもよい。
【０１４９】
ディスパッチャは、ページをブラウザに供給する前に、要求に、およびそのページのヘッダに含まれる、そのページのＭＩＭＥ（多目的インターネットメール拡張）タイプといった情報を検査し、適切な要求ハンドラを呼出す。要求ハンドラは適切な動作を行ない、それはブラウザによってサポートされているマークアップ言語で有効なページを生成し、それは次にディスパッチャによってブラウザに与えられてもよい。クライアントエージェント４４０は、データベーステーブル、スナップショットおよび／またはキャッシュテーブルを参照するＳＱＬ（構造化照会言語）タグを含み得るタグを使用するＯＴＬ（オフラインタグライブラリ）ページ用の要求ハンドラを有して構成されてもよい。図４では、スクリプトエンジン４４６はＯＴＬ  ＭＩＭＥタイプ用のハンドラを含んでいてもよい。
【０１５０】
この発明の例示された実施例では、スクリプトエンジン４４６は、ブラウザを介して（つまり音声を介さずに）ユーザに図で提示されるべきページのアセンブリを実行する。スクリプトエンジンが（たとえばディスパッチャ４４４から）キャッシュされたページについての要求を受取ると、それは（たとえばキャッシュ４４２から）そのページのプレゼンテーションフォーマットを検索し、（たとえばデータベース４２０から）適切なデータを検索する。データは次にプレゼンテーションフォーマットの対応する変数またはプレースホルダに向けられ、アセンブルされたページが生成される。アセンブルされたページは次にディスパッチャに戻されて、クライアントブラウザに渡されてもよい。
【０１５１】
スクリプトエンジン４４６は音声エンジン４４８と作動するよう構成されている。スクリプトエンジンが＜say…＞または＜prompt…＞などの音声タグに遭遇すると、それは音声エンジンの適切な方法への引数を準備し、方法を呼出す。音声エンジンは次に、方法呼出に聴覚的に応答し、方法呼出の制御および結果をスクリプトエンジンに戻す。
【０１５２】
ページ要求元４５０は、要求されたページ（たとえばプレゼンテーションフォーマット）、および／またはローカルに記憶されていない内容、もしくはローカルに記憶されているが古くなっている内容を検索するために、遠隔システム（たとえばデータサーバ）との対話を取扱う。待ち行列４５２は、遠隔システムと交換すべき要求および／または他の通信を記憶してもよい。
【０１５３】
プッシュリスナ４５４は、プッシュされた内容、ページ（たとえばプレゼンテーションフォーマット）、ダウンロードページ、アプリケーションページ、および／または他の項目を聞くよう構成されていてもよい。プッシュは、ＳＭＳ（ショートメッセージサービス）通信として、またはクライアント４００により認識可能な何か他のフォーマットで受取られてもよい。プッシュのほんの一例として、データサーバは一連のＳＱＬステートメントを含むＳＭＳメッセージをプッシュしてもよい。プッシュリスナ４５４はそのステートメントを実行するか、または、それらを実行のためにディスパッチャ４４４またはクライアントエージェント４４０の何か他の構成要素に渡してもよい。例示的には、ステートメントは、新規または更新データをデータベース４２０に記憶させてもよい。
【０１５４】
図５Ａ−Ｃは、この発明の一実施例に従った、インテリジェントクライアントエージェントを用いてモバイルアプリケーションを動作する方法を示している。この実施例では、モバイルアプリケーションは（図４のクライアント機器４００などの）モバイルまたはポータブル（たとえば無線）コンピューティング機器上で実行される。モバイルアプリケーションは（たとえば遠隔サーバまたは他のコンピュータシステムへのアクティブな接続なしで）オフライン動作用に構成されているが、古い、または利用できない（たとえばモバイル機器上に記憶されていない）データを検索するために利用可能な接続を利用することができる。
【０１５５】
図５Ａは、ディスパッチャ（たとえば図４のディスパッチャ４４４）を動作させる方法を示している。図５Ｂ−Ｃは、スクリプトエンジン（たとえば図４のスクリプトエンジン４４６）を動作させる方法を示している。
【０１５６】
図５Ａの状態５０２では、インテリジェントクライアントエージェント（たとえば図４のディスパッチャ４４４）は、呼出元、通常クライアントブラウザから要求を受取る。例示的には、この要求はクライアントエージェントに関連する１組の予め定められたプロトコル（たとえばＯＭＣ）のうちの１つで提出されてもよい。
【０１５７】
状態５０４で、ディスパッチャは、要求されたページまたは他の項目が現在キャッシュされているかどうかを判断する。特に、ディスパッチャは、クライアントエージェントキャッシュ（たとえば図４のキャッシュ４４２）を調べ、それが要求されたページについてのプレゼンテーション記述またはフォーマットを含むかどうかを判断する。要求されたページについてのフォーマットがキャッシュ内にある場合、例示された方法は状態５１０に進む。
【０１５８】
その他の場合、キャッシュされていなければ、次に状態５０６で、クライアントエージェントは要求を要求元（たとえば図４の要求元４５０）に送り、遠隔システムに渡す。モバイル機器が現在オフラインである場合、この状態は、接続が利用可能となるまで要求を待ち行列に入れることを必然的に伴い得る。
【０１５９】
状態５０８で、遠隔サーバから戻されたページ（たとえばプレゼンテーションページ）がキャッシュに入れられる。
【０１６０】
状態５１０で、ディスパッチャは、要求されたページがそのまま呼出元（たとえばブラウザ）に戻されるべきかどうか、またはそれがさらなる処理のためにハンドラのうちの１つに送られるべきかどうかを判断する。例示的には、ページがＯＴＬページである場合、ディスパッチャはスクリプトエンジンを呼出し、それはＯＴＬページのハンドラとして作動する。さらなる処理が必要でない場合、例示された方法は状態５１６に進む。
【０１６１】
状態５１２で、ディスパッチャはページを処理するためにハンドラ（たとえばスクリプトエンジン）を呼出す。図５Ｂは、スクリプトエンジンが動作し得る際に従う一方法を示している。
【０１６２】
状態５１４で、ディスパッチャはハンドラがページを戻したかどうかをチェックする。戻していない場合、方法は状態５１８に進む。
【０１６３】
状態５１６で、要求されたページが呼出元に送られる。例示されたディスパッチャ方法はここで終了する。
【０１６４】
状態５１８で、ディスパッチャはエラーを合図してもよく、こうしてこの方法を終了させる。または、ディスパッチャはハンドラによって提供されるべきページをさらなる期間待ってもよく、または動作を再試行してもよい。
【０１６５】
図５Ｂは、この発明の一実施例に従った、図４のスクリプトエンジン４４６などのＯＴＬハンドラの動作を示している。この実施例では、スクリプトエンジンはＯＴＬページを入力として受取る。ＯＴＬページは通常、ページのプレゼンテーションフォーマットを含んでいる。プレゼンテーションフォーマットは一種のページテンプレートとして機能してもよい。しかしながら、実際のデータを含む代わりに、データは、それらの変数、フィールドまたは列名、テーブル名もしくは他のプレースホルダによって表わされる。ＯＴＬページは、他のページまたはリソース（たとえば画像ファイル）をダウンロードするタグ、必要に応じてデータベーススキーマを生成するタグ、音声エンジンと相互作用するタグ、ＳＱＬステートメントを実行して結果を変数に結びつけるタグ、変数の値を出力ファイルに書込むタグ、および出力ページの生成をプログラムするのに必要なフロー制御を提供するタグを含んでいてもよい。
【０１６６】
状態５３０で、ＯＴＬハンドラは空の出力ページを生成する。例示された方法が進むにつれ、出力ページには入力ページからの内容および／または他の内容が配置される。
【０１６７】
状態５３２で、それは入力ページまたは内容をスキャンし始める。例示的には、スキャニングはタグごとに行なわれてもよい。
【０１６８】
状態５３４で、それはタグがＯＴＬタグかどうかを調べる。それがＯＴＬタグである場合、方法は状態５４０で継続する。
【０１６９】
その他の場合、状態５３６では、タグはＯＴＬタグではなく、そのためスクリプトエンジンは、ＯＴＬタグが入力に生じるまで、またはページの最後に到達するまで、入力ページから出力ページへ文字をコピーする。ＯＴＬタグに到達すると、方法は状態５４０に進む。
【０１７０】
その他の場合、入力の最後に到達すると、状態５３８で出力ページは閉じられて呼出元（たとえばディスパッチャ）に戻され、方法は終了する。出力ページは空であってもよい。
【０１７１】
状態５４０で、スクリプトエンジンはタグが「ダウンロード」タグかどうかを調べる。そうでない場合、方法は状態５４４で継続する。
【０１７２】
しかしながら、タグがダウンロードタグであれば、次に状態５４２で、スクリプトエンジンは、ダウンロードタグへの属性として与えられたＵＲＬにあるページをダウンロードするためにディスパッチャを呼出す。この発明の例示された実施例では、ダウンロードされたページはこの時点ではパーズまたは実行されない。ページをダウンロードした後、スクリプトエンジンは状態５３２に戻る。
【０１７３】
状態５４４で、タグはそれが「インポート」タグであるかどうかを調べられる。そうでない場合、方法は状態５４８に進む。
【０１７４】
その他の場合、タグがインポートタグであれば、状態５４６で、インポートタグへの属性として提供されたＵＲＬに関連するページをインポートするためにディスパッチャが呼出される。
【０１７５】
例示的には、スクリプトエンジンはインポートモードを「オン」にセットする。インポートモードを「オン」にすることは、ディスパッチャに、そして（ディスパッチャがスクリプトエンジンに呼出を行なっている場合には）おそらくスクリプトエンジンに、それがインポートページを処理中であることを示す。スクリプトエンジンは次に、再帰呼出をディスパッチャに行ない、インポートされるべきページのＵＲＬを提供する。ディスパッチャが制御をスクリプトエンジンに戻すと、インポートモードは「オフ」にセットされ、例示された方法は状態５３２で再び始まる。
【０１７６】
状態５４８では、タグが「インポート」タグでない場合、スクリプトエンジンはタグが「スキーマ」タグかどうかを調べる。スキーマタグでない場合、方法は状態５５４に進む。
【０１７７】
状態５５０で、スクリプトエンジンは、スキーマが既に存在するかどうかローカルデータベースを調べる。存在する場合、方法は状態５３２に戻る。
【０１７８】
その他の場合、状態５５２で、スクリプトエンジンは「スキーマ」タグにより与えられたＵＲＬにあるページを処理するためにディスパッチャを呼出す。状態５５２の後、方法は状態５３２に戻る。
【０１７９】
状態６４０で、スクリプトエンジンはインポートモードがオンかオフかを判断する。インポートモードがオンである場合、これは、処理中のページがダウンロードページであることを示している。したがって、スクリプトエンジンはそのページにおける他のタグを処理しようとはせず、代わりに状態５２０から動作を再び始める。例示的には、これは、インポートされたページがすぐには実行されないこと、および、それらが依存する任意のページもダウンロードまたはインポートされ、それらが依存する任意のスキーマが生成されることを、確実にする手助けをする。
【０１８０】
状態５５６で、ＯＴＬタグが「ＳＱＬ」タグかどうかが調べられる。そうでない場合、方法は状態５６２に進む。
【０１８１】
その他の場合、状態５５８で、スクリプトエンジンは、タグを伴う待ち行列を実行するためにクライアントＤＢＭＳを呼出す。
【０１８２】
次に、状態５６０で、スクリプトエンジンは、待ち行列（たとえばテーブル）の結果を
「ＳＱＬ」タグに含まれる変数と結びつける。方法は次に状態５３２に戻り、そこでそれは入力ページのスキャニングを継続する。
【０１８３】
状態５６２で、生じたタグが「提出」タグでない場合、スクリプトエンジンは状態５６６に進む。
【０１８４】
その他の場合、状態５６４で、スクリプトエンジンは、出力ページを待ち行列（たとえば図４の待ち行列４５２）に提出することによって提出タグに応答し、待ち行列はページを特定されたサーバに送る。
【０１８５】
この発明のこの実施例では、提出タグは少なくとも３つの属性を有する。第１の属性は、ページが提出されるサーバのＵＲＬである。第２の属性は、成功した提出を示す、サーバからの戻りコードを識別する。第３の属性は、サーバからの戻りコードが第２の属性において識別されたコード以外のものである場合に呼出されるページのＵＲＬである。
【０１８６】
待ち行列がサーバへの接続を有すると、それは待ち行列に入れられた任意の要求を提出する。エラーがあれば、それはエラー取扱いページを呼出して、それにサーバのＵＲＬと戻されたコードとを渡す。
【０１８７】
状態５６６で、タグはそれが音声タグであるかどうかを調べられる。そうでない場合、例示された方法は状態５７０に進む。
【０１８８】
その他の場合、それが音声タグであれば、状態５６８で、スクリプトエンジンは、必要な音声エンジン方法を呼出すためにスクリプト内の変数からパラメータ値を準備する。方法を呼出した結果、音声エンジンは（音声タグが“say”タグであった場合には）ユーザにメッセージを話し掛け、または（タグが“prompt”タグであった場合には）ユーザに入力を聴覚的に促す。タグがプロンプトである場合、音声エンジンは聴覚入力を受付け、次にそれを認識してテキスト文字列に変換しようとする。このテキスト文字列は方法の結果として戻される。スクリプトエンジンは次に状態５３２に戻って、入力ページのスキャニングを継続する。
【０１８９】
状態５７０で、スクリプトエンジンは、タグが「アウト」タグかどうかを調べる。「アウト」タグはスクリプトエンジンに、値（変数に結び付けられた定数または値）を出力するよう告げる。
【０１９０】
タグが「アウト」タグである場合、状態５７２で、スクリプトエンジンは値を出力ページに書込み、次に状態５３２に戻る。
【０１９１】
タグが「アウト」タグではない場合、状態５７４で、スクリプトエンジンは、それがサポートするステートメントの１つとしてそれを処理し、次に状態５３２に戻る。
【０１９２】
図５Ｂ−Ｃの方法を実現する間、スクリプトエンジンは要求されたページについてのデータを検索する。たとえば、データが現在クライアントデータベース（たとえばテーブル、キャッシュテーブルまたはスナップショット）に記憶され、かつ有効である場合、それらは状態５５８中にデータベースから検索されてもよい。しかしながら、データ項目が現在データベースにない場合、または必要なデータ項目が古い場合、クライアントエンジンは１つ以上のデータ項目を検索するために遠隔システムへの接続を開始してもよい。この発明のこの方法では、必要なデータのみを検索することによって、遠隔システムへの接続が最小限に抑えられていることが注目され得る。特に、クライアントエンジンは、要求されたページの他のデータ（たとえばローカルに利用可能でかつ古くないデータ）および非
データ構成要素（たとえばプレゼンテーション記述またはフォーマット）をダウンロードすることを回避し得る。
【０１９３】
この発明の実施例の前述の説明は、例示および説明の目的のためにのみ提示されてきた。それらは網羅的であるよう、または開示された形にこの発明を限定するよう意図されてはいない。したがって、上述の開示はこの発明を限定する意図はなく、この発明の範囲は添付された特許請求の範囲によって定義される。
【図面の簡単な説明】
【０１９４】
【図１】この発明の一実施例の実現に好適なモバイルコンピューティング環境を示すブロック図である。
【図２】この発明の一実施例に従った、モバイルコンピューティング機器上でデータをキャッシュするよう構成されたクライアント機器のブロック図である。
【図３Ａ】この発明の一実施例に従った、キャッシュテーブルを使用およびリフレッシュする一方法を示すフローチャートである。
【図３Ｂ】この発明の一実施例に従った、キャッシュテーブルを使用およびリフレッシュする一方法を示すフローチャートである。
【図４】この発明の一実施例に従った、インテリジェントクライアントエージェントを搭載したモバイルクライアント機器を示す図である。
【図５Ａ】この発明の一実施例に従った、要求されたページを処理するためにインテリジェントクライアントエージェント内でディスパッチャを動作させる方法を示すフローチャートである。
【図５Ｂ】この発明の一実施例に従った、スクリプトエンジンがインテリジェントクライアントエージェント内でページをアセンブルする方法を示すフローチャートである。
【図５Ｃ】この発明の一実施例に従った、スクリプトエンジンがインテリジェントクライアントエージェント内でページをアセンブルする方法を示すフローチャートである。
【図６】この発明の一実施例に従ったキャッシュテーブルを示す図である。
【図７】この発明の一実施例に従った、キャッシュテーブルを動作させるクライアント機器とキャッシュテーブルに関連するデータソースとの間の通信のための例示的なフォーマットを示す図である。
【図８】この発明の一実施例に従った、キャッシュテーブルを動作させるクライアント機器とキャッシュテーブルに関連するデータソースとの間の通信のための例示的なフォーマットを示す図である。
【図９】この発明の一実施例に従った、キャッシュテーブルを動作させるクライアント機器とキャッシュテーブルに関連するデータソースとの間の通信のための例示的なフォーマットを示す図である。
【図１０】この発明の一実施例に従った、キャッシュテーブルを動作させるクライアント機器とキャッシュテーブルに関連するデータソースとの間の通信のための例示的なフォーマットを示す図である。
【図１１】この発明の一実施例に従った、キャッシュテーブルを動作させるクライアント機器とキャッシュテーブルに関連するデータソースとの間の通信のための例示的なフォーマットを示す図である。
【図１】
2005533324.tif 000015
【図２】
2005533324.tif 000016
【図３Ａ】
2005533324.tif 000017
【図３Ｂ】
2005533324.tif 000018
【図４】
2005533324.tif 000019
【図５Ａ】
2005533324.tif 000020
【図５Ｂ】
2005533324.tif 000021
【図５Ｃ】
2005533324.tif 000022
【図６】
2005533324.tif 000023
【図７Ａ】
2005533324.tif 000024
【図７Ｂ】
2005533324.tif 000025
【図８】
2005533324.tif 000026
【図９】
2005533324.tif 000027
【図１０】
2005533324.tif 000028
【図１１】
2005533324.tif 000029
【国際調査報告】
2005533324.tif 000030
2005533324.tif 000031
2005533324.tif 000032