JP2019527406A - データ記憶方法及び装置 - Google Patents

Abstract

本願は、データ記憶方法及び装置を提供する。本方法は、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名の記憶領域にアプリケーションデータを記憶し、ドメイン名はジェネリックドメイン名をサポートする（１０１）、ドメイン名の記憶領域がアプリケーションデータを記憶するには不十分である場合、少なくとも１つのiframeを作成して、各iframeはドメイン名のサブドメイン名に対応するページをロードし（１０２）、少なくとも１つのサブドメイン名に対応する記憶領域に残りのアプリケーションデータを記憶する（１０３）ことを含む。本方法は、ブラウザのローカルストレージが各種容量のデータストア要求を満たすことを可能にする。【選択図】図１

Description

本願は、２０１６年６月２８日に「Ｄａｔａ Ｓｔｏｒａｇｅ Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ」と題して出願された中国特許出願第２０１６１０４９１３０３．７号に対して優先権を主張するものであり、その出願全体の内容が参照により本明細書に組み込まれる。

本発明は、コンピュータ技術に関し、特に、データ記憶方法及び装置に関する。

ブラウザにあるページをロードして実行するとき、そのページの表示に必要なリソースをブラウザのローカル記憶領域に記憶することができ、これによって次の実行時にローカルでリソースを取得できるようになる。例えば、オフライン操作をサポートするウェブアプリケーションを開発するときには、アプリケーションのオフライン操作によって必要とされるリソースファイルを、ブラウザがオンライン時にダウンロードし、ローカル記憶領域に記憶する。ユーザがアプリケーションをオフラインでアクセスする場合には、リソースファイルをローカルに取得して、自動的にロードすることによって、ユーザはオフラインでアプリケーションを正常に利用できるようになる。しかし、現在主流のブラウザのローカルストレージ容量には制限があり、多くの場合はドメイン名を介してローカルストレージ容量を制限する。例えば、あるドメイン名に対応するローカル記憶領域が５ＭＢである場合、大規模なオフラインＷｅｂアプリケーションによる大量のデータのローカル記憶要求を満たすことができない。

以上を考慮して、本発明は、データ記憶方法及び装置を提供して、ブラウザのローカルストレージが各種容量のデータストア要求を満たすことができるようにする。

例えば、本発明は、以下の技術的解決策によって実現される。

第１の態様は、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名の記憶領域にアプリケーションデータを記憶し、
ドメイン名の記憶領域がアプリケーションデータを記憶するには不十分である場合、少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名のサブドメイン名に対応するページをロードし、
少なくとも１つのサブドメイン名に対応する記憶領域に残りのアプリケーションデータを記憶する、
ことを含む、データ記憶方法を提供する。

第２の態様は、データ記憶モジュールと、ページ作成モジュールとを含むデータ記憶装置であって、
データ記憶モジュールは、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名のローカルストレージにアプリケーションデータを記憶するように構成され、ドメイン名の記憶領域がアプリケーションデータを記憶するには不十分である場合、データ記憶モジュールは、ページ作成モジュールで作成される少なくとも１つのサブドメイン名に対応する記憶領域に残りのアプリケーションデータを記憶するようにさらに構成され、
ページ作成モジュールは、ドメイン名の記憶領域がアプリケーションデータを記憶するには不十分である場合、少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名の下にサブドメイン名に対応するページをロードするように構成される、データ記憶装置を提供する。

本願の実施形態に係るデータ記憶方法及び装置は、親ページがデータを記憶するには不十分である場合、ジェネリックドメイン名のサブドメイン名に対応するプロキシページを作成することにより、サブドメイン名に対応する記憶領域にデータを配置する。ジェネリックドメイン名が無制限のサブドメイン名をサポートできるので、サブドメイン名のページは、ブラウザのローカルストレージが各種容量のデータストア要求を満たすように、ストレージニーズに応じてサブドメイン名のページを適応的に作成できる。

本発明の実施形態に係るデータ記憶方法のフローチャートである。 本発明の実施形態に係る別のデータ記憶方法のフローチャートである。 本発明の実施形態に係るデータ記憶装置の概略構成図である。 本発明の実施形態に係る別のデータ記憶装置の概略構成図である。

現在のブラウザのローカル記憶領域には制限があり、通常はドメイン名に従って制限されることが多い。各ドメイン名には最大記憶容量がある。しかし、このような容量の制限はデータストア要求、特に大規模なオフラインアプリケーションのデータをローカルに記憶するには障壁になることがある。本願の実施形態に係るデータ記憶方法は、ブラウザのこのローカル記憶領域の容量制限を解決して、ブラウザがローカルに任意のサイズのデータを記憶し、各種容量のデータストア要求を満たすことができるようになる。

上記目的を実現するために、一例では、ジェネリックドメイン名をサポートするようにアプリケーションのドメイン名を設定することができる。例えば、大規模なオフラインのアプリケーションは、ジェネリックドメイン名の解決をサポートする「*.abc.com」のドメイン名を有する。例えば、「123.abc.com」又は「234.abc.com」は、「*.abc.com」と同じＩＰアドレスを指す。上記方法は、ドメイン名が無制限のサブドメイン名をサポートすることを可能にする。例えば、「123.abc.com」、「234.abc.com」などのサブドメイン名はすべてジェネリックドメイン名の下にある。

図１は、ジェネリックドメイン名をサポートするように設定されたドメイン名に従って、本例のデータ記憶方法の例示的なプロセスフローを示す。この方法は、ブラウザにデータをローカルに記憶する必要があるアプリケーションによって実行でき、例えば、開発された大規模なオフラインアプリケーションによって実行できる。図１に示すように、この方法は以下を含むことができる。

ステップ１０１では、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名の記憶領域にアプリケーションデータを記憶する。ドメイン名はジェネリックドメイン名をサポートする。

例えば、ブラウザのローカルストレージインタフェースは、ローカルストレージ、Ｗｅｂ ＳＱＬ、Ｉｎｄｅｘ ＤＢなどのＡＰＩを含むことができる。ブラウザがオフラインアプリケーションをロードして実行すると、アプリケーションは、ブラウザが提供するローカルストレージインタフェースを呼び出し、ブラウザのローカル記憶領域にアプリケーションデータを記憶する。

しかし、ブラウザの特性によれば、ブラウザはドメイン名に従ってアプリケーションデータの記憶を制限する。例えば、ドメイン名が５ＭＢの記憶領域に対応する場合、先ずこの記憶領域にアプリケーションデータを記憶することになる。ここで、本ステップのアプリケーションデータに関して、ユーザがアプリケーションのドメイン名にアクセスする場合、アプリケーションサーバは、アプリケーションがロードする必要があるデータをドメイン名に対応する現在のページに送信できる。

ステップ１０２では、ドメイン名の記憶領域がアプリケーションデータを記憶するには不十分である場合、少なくとも１つのiframeを作成して、各iframeはドメイン名のサブドメイン名に対応するページをロードする。

例えば、現在のページに対応するドメイン名にある記憶領域は、ドメイン名に対応する記憶容量の制限があるため、アプリケーションデータを記憶するのに十分ではないとする。例えば、合計１０ＭＢのアプリケーションデータがある場合、ドメイン名にある記憶領域に５ＭＢの上限があるので、その領域にはすべてのアプリケーションデータを記憶することができない。

本例では、アプリケーションは、現在のページに少なくとも１つのiframeを作成して、各iframeは１つのページをロードすることができ、そのページはプロキシページと呼ばれる。さらに、そのプロキシページは、ステップ１０１におけるジェネリックドメイン名にあるサブドメイン名に対応する。例えば、現在のページのドメイン名は「*.abc.com」であり、本ステップで作成されたジェネリックドメイン名の下のサブドメイン名は「123.abc.com」であることができる。もちろんジェネリックドメイン名の下には他のサブドメイン名、例えば「234.abc.com」を作成することもできる。このドメイン名は、ジェネリックドメイン名をサポートすることができるので、無制限のサブドメイン名をサポートすることができる。

サブドメイン名に対応するプロキシページを作成した後、ブラウザの「ドメイン名でローカル記憶領域を制限する」という特性、例えば、５ＭＢである、に従って、このサブドメイン名は新たに対応するローカル記憶領域を生成することができる。これは、さらに５ＭＢのローカル記憶領域を追加することに相当する。残りのアプリケーションデータは、このサブドメイン名のローカル記憶領域に続けて記憶することができる。

本ステップでは、作成されるiframeの数を、データストア要求に従って決定できる。例えば、ステップ１０１で現在のページに対応する記憶領域にデータを記憶した後、６ＭＢのアプリケーションデータが残っている場合には、２つのiframeが作成することができ、各iframeにはサブドメイン名に対応するプロキシページをロードする。サブドメイン名ごとに５ＭＢのローカル記憶領域を生成すると仮定すると、その２つのiframeの作成はアプリケーションデータの記憶を完了させることができる。別の例では、ステップ１０１で１２ＭＢのアプリケーションデータが残っている場合、上記の例に従って、３つのiframeを作成して、iframeごとにサブドメイン名に対応するプロキシページをロードし、アプリケーションデータの記憶を完了させることができる。

ステップ１０３では、残りのアプリケーションデータを少なくとも１つのサブドメイン名に対応する記憶領域に記憶する。

本ステップでは、ステップ１０１で未記憶の残りのアプリケーションデータを、ステップ１０２で作成したサブドメイン名に対応するローカル記憶領域に記憶する。図１のフローでは、ステップの実行順序を制限するわけではない。例えば、少なくとも２つのiframeを作成する必要がある場合、ステップ１０２とステップ１０３を１度実行して１つのiframeを作成して、そのiframeに対応するサブドメイン名の記憶領域へのデータの記憶を行い、次にステップ１０２とステップ１０３をもう一度実行し、もう１つのiframeの作成とデータの記憶を完了する。

本例のデータ記憶方法は、現在のページに複数のiframeを作成でき、そのiframeに対応するサブドメイン名のページを導入することにより、それらのサブドメイン名はそれぞれ新しい記憶領域を生成するようになる。また、本例の方法では、iframeのページに対応するサブドメイン名は「ジェネリックドメイン名の下にあるサブドメイン名」とする。ジェネリックドメイン名の下にあるサブドメイン名の使用は、多くの極めて大きな効果をもたらす。例えば、次の３つの効果をもたらす。

第一に、ブラウザのローカル記憶領域を無限にする。

ジェネリックドメイン名は無制限のサブドメイン名をサポートできるので、ブラウザのローカル記憶領域を無制限に拡張することができる。例えば、ジェネリックドメイン名「*.abc.com」には、「123.abc.com」「234.abc.com」「456.abc.com」といった無制限のサブドメイン名を使用することができ、記憶領域がアプリケーションデータを記憶するのに十分になるまで、データストア要求に従ってiframeにはページを無制限に作成することができる。この方式は、ブラウザのローカル記憶領域を無限にして、ブラウザのローカル記憶領域の制限を解決する。

第二に、ブラウザのローカルストレージ容量を柔軟に増加させることができる。

ジェネリックドメイン名が無制限のサブドメイン名をサポートできるので、ジェネリックドメイン名にある任意のサブドメイン名を、iframeに埋め込まれたページに対して割り当てることができる。そのようなサブドメイン名は任意に取得可能であり、その操作は非常に便利である。一方で、ジェネリックドメイン名の下にサブドメイン名を作成せずに、iframeのページごとにいくつかのサブドメイン名を事前に申請する場合、すべてのサブドメイン名を利用するためには事前に申請する必要があるため、操作が煩雑になる。

また、いくつかのサブドメイン名を使用のために事前に申請する方式は、ブラウザのローカル記憶領域をカスタマイズすることに相当し、記憶領域の容量が制限されることになる。例えば、各サブドメイン名が５ＭＢの記憶領域に対応する場合、３つのサブドメイン名の事前申請は、ブラウザのローカル記憶領域を１５ＭＢまでに増加させるが、その容量よりも多くのデータは依然としてそのデータストア要求を満たすことができない。５つのサブドメイン名を事前に申請する場合、ブラウザのローカル記憶領域は２５ＭＢまで増加するが、依然としてその容量よりも大きいデータを記憶することができない。したがって、ドメイン名にあるサブドメイン名を使用しない場合には、ブラウザのローカル記憶領域は無限ではなく、記憶領域は一定容量の制限を持つ。記憶領域を追加する場合には、新たなサブドメイン名を続けて申請する必要がある。結果として、ブラウザのローカル記憶領域を増加するには相対的に柔軟ではない。

第三に、ブラウザのローカル記憶領域はデータ記憶容量の動的変化を満たすことができる。

アプリケーションデータのサイズも動的に変化する可能性がある。例えば、現在５ＭＢのデータを記憶する必要がある。使用中に大量のデータが生成され、データストア要求が２０ＭＢに増加する。本例のジェネリックドメイン名のサブドメイン名を用いた方式では、この種の動的なデータストア要求を十分に満たすことができる。データの増加の程度にかかわらず、単にデータサイズに応じてiframeの数を柔軟かつ高速に増加させる必要がある。

上記２点目に言及された方式であって、iframeごとに使用するいくつかのサブドメイン名を事前に申請する方式と類似比較がなされる。この方式は比較的静的である。データストア要求が変更された場合、事前に申請する必要がある多数のサブドメイン名は、アプリケーションデータを記憶するには不十分である。増加したデータストア要求を満たすには、いくつかの新しいサブドメイン名を申請する必要があり、非常に柔軟ではない。

本願の実施例の方法は、動的にiframeを作成する方法であり、データストア要求に従って動的かつリアルタイムに新しいサブドメイン名を導入することができる。すなわち、データストアに必要な数のサブドメイン名のiframeを作成することにより、データストア要求に適合しそれを満たすことができる。また、本方法はジェネリックドメイン名をサポートするドメイン名を設定して、そのドメイン名はその下に無制限のサブドメイン名を持つことができるようになる。データストア要求に従ってジェネリックドメイン名の下にサブドメイン名を任意の時点で作成することができ、非常に便利になる。

図２は、本願の実施例のデータ記憶方法の１つの応用例を示す。本例では、ドメイン名(またはサブドメイン名)に対応するローカル記憶領域を５ＭＢとし、ブラウザに現在のアプリケーションがローカルに記憶するアプリケーションデータを１２ＭＢと仮定する。記憶フローは次のようになる。

ステップ２０１では、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名の記憶領域にアプリケーションデータを記憶する。

例えば、現在のページは親ページと呼ぶことができる。ブラウザが提供するローカルストレージ、Ｉｎｄｅｘ ＤＢなどのＡＰＩを介して、その親ページのドメイン名に対応するローカル記憶領域にアプリケーションデータを記憶することができる。

ステップ２０２では、現在のページに対応するドメイン名の記憶領域がアプリケーションデータを記憶するために十分であるか否かを判定する。

判定結果が十分である場合、現在のページのドメイン名に対応する記憶領域にアプリケーションデータを単に記憶することにより、フローを終了することができる。

しかし、本例では、記憶するアプリケーションデータを１２ＭＢとし、現在のページのドメイン名の記憶領域を５ＭＢと仮定している。本ステップの判定結果は不十分であり、ステップ２０３を実行することができる。

ステップ２０３では、iframeを作成して、iframeにプロキシページをロードし、プロキシページはドメイン名の１つのサブドメイン名に対応する。

例えば、現在の親ページにiframeを作成して、そのiframeにプロキシページをロードする。そのプロキシページを子ページと呼ぶことができる。また、本例では、親ページの体験に影響を与えないように、作成されたiframeに埋め込まれた子ページを非表示にするように設定できる。例えば、子ページの属性を非表示に設定することによって、そのページを非表示にするように設定することができる。この子ページの作成は、その子ページに対応するサブドメイン名にある記憶領域を利用する目的で作成され、そのサブドメイン名は親ページのドメイン名にあるサブドメイン名である。

本ステップでは、iframeのプロキシページの作成に失敗した場合、ステップ２０３を再実行しiframeを再作成して、サブドメイン名に対応するプロキシページを導入する。

iframeのプロキシページの作成が成功した場合、ステップ２０４を実行する。

ステップ２０４では、ブラウザのローカルストレージインタフェースを呼び出し、サブドメイン名に対応する記憶領域にアプリケーションデータを続けて記憶する。

例えば、ステップ２０１で親ページの記憶領域にデータを記憶する場合、未記憶の残りのアプリケーションデータを子ページの記憶領域に続けて記憶する。親ページと子ページ間のデータ交換は、アプリケーションデータを子ページの記憶領域に記憶するように、親ページがアプリケーションデータを子ページに送信できることである。アプリケーションデータは、現在の親ページからサブドメイン名に対応する子ページに送信される。ドメインクロッシングデータ送信を設定するにはいくつもの方法が存在する。例えば、１つの方法では、postMessage APIを使用することができる。

次の例では、プロキシページを導入するためにiframeを作成することを示す。

iframeを作成する。
var iframeNode = document.createElement(”iframe”)
作成されたiframeにある子ページのアドレス：
iframe.src = ”http://x.alipay.net/proxy.htm
親ページは子ページを呼び出し、記憶するアプリケーションデータを子ページに送信する。
document.appendChild(iframeNode)

本ステップでは、アプリケーションデータをサブドメイン名の記憶領域に記憶する場合、サブドメイン名に対応する記憶領域がアプリケーションデータを記憶するために十分か否かを続けて判定することができる。すなわち、ステップ２０２に戻って実行できる。iframeに作成された子ページが十分である場合には、フローを終了することができる。記憶領域がアプリケーションデータを記憶するにはまだ不十分である場合、記憶領域がアプリケーションデータを記憶するために十分になるまで、ステップ３０３を実行して新しいiframeを作成して、別の新しいサブドメイン名に対応するプロキシページを導入し、それ以上新しいiframeが作成されなくなる。本例では、１２ＭＢのアプリケーションデータを記憶するために２つのiframeを作成する必要があり、各iframeに１つのサブドメイン名のプロキシページをロードする。

上記のようにiframeを作成する度にアプリケーションデータを記憶するための記憶領域が十分であるか否かを判定するのではなく、本例では、アプリケーションデータのサイズに応じて、事前に作成すべきiframeの数を計算し、その数のiframeを作成して、各iframeに１ページずつロードする。その各ページは、そのページごとに対応するジェネリックドメイン名の下の１つのサブドメイン名に対応する。例えば、アプリケーションデータのサイズが１２ＭＢとし、かつサブドメイン名ごとに対応する記憶領域が５ＭＢであると仮定する。現在のページの５ＭＢの記憶領域を使用した後、７ＭＢのデータを記憶するにはiframeを作成する必要がある。７ＭＢデータは２つのiframeの作成を要求し、ジェネリックドメイン名のサブドメイン名に対応するページをiframeごとにロードし、２つのサブドメイン名は合計１０ＭＢの記憶領域を生成することができ、それは残りの７ＭＢのアプリケーションデータを記憶するには十分である。

以上の説明から、ブラウザにアプリケーションデータをローカルに記憶する場合、データストア要求に従ってiframeを動的に作成できることが理解できる。例えば、２つのiframeがデータを記憶するために必要であれば、２つのiframeを作成する。データを記憶するために６つのiframeが必要であれば、６つのiframeを作成する。これにより、データ記憶がブラウザのドメイン名の記憶容量に制限されることなく、任意のデータストア要求を満たすことができる。さらに、ジェネリックドメイン名を設定することにより、無制限のサブドメイン名をサポートすることができる。必要に応じてサブドメイン名を作成でき、追加のドメイン名の申請を必要としないので、便利である。

また、アプリケーションデータを記憶した後、次回そのデータを使用する時、例えば、オフライン時にオフラインアプリケーションをロードし実行する場合、記憶されたアプリケーションデータをブラウザにリロードする必要があり、そのアプリケーションデータをドメイン名の記憶領域から取得することができ、記憶領域は少なくとも１つのサブドメイン名にそれぞれ対応する。ここで、子ページはpostMessage関数で親ページ関数を呼び出して、子ページに記憶されたアプリケーションデータ(すなわち、子ページに対応するサブドメイン名の記憶領域に記憶されたデータ)を親ページに送信することができ、親ページにアプリケーションデータを一括して表示する。

また、上記の例では、現在のページのドメイン名をジェネリックドメイン名として使用し、iframeにロードされたページは、そのジェネリックドメイン名にあるサブドメイン名に対応させたものである。これは一例であり、これにより特定の実施形態に限られるわけではない。例えば、作成されたiframeのページは、あるジェネリックドメイン名にあるサブドメイン名に対応しているが、そのジェネリックドメイン名は現在のページに対応するドメイン名ではない。すなわち、現在のページのドメイン名と上記のドメイン名とは異なるドメイン名である。

例えば、現在のページドメイン名はwww.123.comであり、そのページのドメイン名の記憶領域がアプリケーションデータを記憶するには十分でない場合には、iframeを作成して、そのiframeにロードされたページはジェネリックドメイン名のサブドメイン名に対応するようにする。ジェネリックドメイン名は*.abc.comであり、そのジェネリックドメイン名にある１つのサブドメイン名は456.abc.comとすることができる。この場合、現在のページのドメイン名は、iframeのページに対応するジェネリックドメイン名とは異なるが、生成されるのは依然としてジェネリックドメイン名のサブドメイン名に対応するページであることから、無限の拡張が実現でき、前述の例と同様の効果が実現できる。すなわち、任意のサイズのデータストア要求を実現できる。

上記のデータ記憶方法を実装するために、本願の実施例はさらにデータ記憶装置を提供して、以下に装置の構造を簡単に説明する。その詳細な動作原理については、本方法の実施例を参照することができる。図３に示すように、本装置は、データ記憶モジュール３１とページ作成モジュール３２とを含むことができる。

データ記憶モジュール３１は、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名にある記憶領域にアプリケーションデータを記憶する。また、ドメイン名にある記憶領域がアプリケーションデータを記憶するのに十分でない場合には、残りのアプリケーションデータをページ作成モジュールで作成した少なくとも１つのサブドメイン名に対応する記憶領域に記憶するようにさらに構成される。

ページ作成モジュール３２は、ドメイン名にある記憶領域がアプリケーションデータを記憶するために十分でない場合には、少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeにジェネリックドメイン名にあるサブドメイン名に対応する１つのページをロードする。

一例では、ページ作成モジュール３２は、現在のページに対応するドメイン名にある記憶領域がアプリケーションデータを記憶するために十分であるか否かを判定するように構成される。判定結果が十分ではない場合、iframeを作成して、iframeにプロキシページをロードし、プロキシページはドメイン名にある１つのサブドメイン名に対応する。サブドメイン名に対応する記憶領域がアプリケーションデータを記憶するにはまだ不十分である場合、新しいiframeを作成して、iframeにドメイン名の別のサブドメイン名に対応するプロキシページをロードする。

一例では、ページ作成モジュール３２は、アプリケーションデータのサイズに応じて作成すべきiframeの数を計算し、その数のiframeを作成して、各iframeにページをロードし、各ページはジェネリックドメイン名のサブドメイン名に対応するように構成される。

一例では、データ記憶モジュール３１は、残りのアプリケーションデータを少なくとも１つのサブドメイン名に対応する記憶領域に記憶するように構成され、以下を含む。サブドメイン名に対応するページとドメイン名に対応する現在のページとを、同じドメイン名に設定する。アプリケーションデータを現在のページからサブドメイン名に対応するページに送信する。

一例では、図４に示すように、本装置は、記憶されたアプリケーションデータをブラウザにロードする場合には、ドメイン名の記憶領域からアプリケーションデータを取得し、記憶領域が少なくとも１つのサブドメイン名にそれぞれ対応するように構成された、データ取得モジュール３３をさらに含む。

一例では、ジェネリックドメイン名は、現在のページに対応するドメイン名である。または、ジェネリックドメイン名は、現在のページとは異なるドメイン名である。

上記には本発明の好適な実施例のみが説明されており、本発明を限定するために実施例を用いるわけではない。本発明の精神と原則内に、いかなる修正、均等物による置換、改善などを含むべきであり、いずれも本発明の保護範囲内に含めるべきである。

Claims (10)

1. ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名の記憶領域にアプリケーションデータを記憶し、
   前記ドメイン名の前記記憶領域が前記アプリケーションデータを記憶するには不十分である場合、少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名のサブドメイン名に対応するページをロードし、
   少なくとも１つの前記サブドメイン名に対応する記憶領域に残りのアプリケーションデータを記憶する、
   ことを含む、データ記憶方法。
2. 少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名のサブドメイン名に対応するページをロードすることは、
   前記アプリケーションデータを記憶するために前記現在のページに対応する前記ドメイン名の前記記憶領域が十分であるか否かを判定し、
   判定結果が不十分である場合、iframeを作成して、前記iframeにページをロードし、前記ページは前記ドメイン名の１つのサブドメイン名に対応し、
   前記サブドメイン名に対応する前記記憶領域が前記アプリケーションデータを記憶するにはまだ不十分である場合、新しいiframeを作成して、前記ジェネリックドメイン名の下に別のサブドメイン名に対応するページを前記iframeにロードすることを含む、
   請求項１に記載の方法。
3. 少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名のサブドメイン名に対応するページをロードすることは、
   前記アプリケーションデータの前記サイズに応じて作成するiframeの数を計算し、
   前記数のiframeを作成して、各iframeにページをロードし、各ページはジェネリックドメイン名の１つのサブドメイン名に対応する、
   ことを含む、請求項１に記載の方法。
4. 前記記憶されたアプリケーションデータを前記ブラウザにロードするとき、前記ドメイン名の前記記憶領域から前記アプリケーションデータを取得し、前記記憶領域は少なくとも１つの前記サブドメイン名にそれぞれ対応することをさらに含む、請求項１に記載の方法。
5. 前記ジェネリックドメイン名は前記現在のページに対応するドメイン名であるか、または、前記ジェネリックドメイン名は前記現在のページの前記ドメイン名とは異なるドメイン名である、請求項１に記載の方法。
6. データ記憶モジュールと、ページ作成モジュールとを含むデータ記憶装置であって、
   前記データ記憶モジュールは、ブラウザのローカルストレージインタフェースを呼び出し、現在のページに対応するドメイン名のローカルストレージにアプリケーションデータを記憶するように構成され、前記ドメイン名の前記記憶領域が前記アプリケーションデータを記憶するには不十分である場合、前記データ記憶モジュールは、ページ作成モジュールで作成される少なくとも１つのサブドメイン名に対応する記憶領域に残りのアプリケーションデータを記憶するようにさらに構成され、
   前記ページ作成モジュールは、前記ドメイン名の前記記憶領域が前記アプリケーションデータを記憶するには不十分である場合、少なくとも１つのHTMLフレーム（iframe）を作成して、各iframeはジェネリックドメイン名の下にサブドメイン名に対応するページをロードするように構成される、データ記憶装置。
7. 前記ページ作成モジュールは、前記アプリケーションデータを記憶するために前記現在のページに対応する前記ドメイン名の前記記憶領域が十分であるか否かを判定し、
   判定結果が不十分である場合、iframeを作成して、前記iframeにページをロードし、前記ページは前記ドメイン名の１つのサブドメイン名に対応し、
   前記サブドメイン名に対応する前記記憶領域が前記アプリケーションデータを記憶するにはまだ不十分である場合、新しいiframeを作成して、前記ドメイン名の下に別のサブドメイン名に対応するページを前記iframeにロードするように構成される、請求項６に記載のデータ記憶装置。
8. 前記ページ作成モジュールは、前記アプリケーションデータの前記サイズに応じて作成するiframeの数を計算し、
   前記数のiframeを作成して、各iframeにページをロードし、各ページはジェネリックドメイン名の１つのサブドメイン名に対応するように構成される、請求項６に記載のデータ記憶装置。
9. データ取得モジュールは、前記記憶されたアプリケーションデータを前記ブラウザにロードするとき、前記ドメイン名の前記記憶領域から前記アプリケーションデータを取得し、前記記憶領域は少なくとも１つの前記サブドメイン名にそれぞれ対応するように構成される、請求項６に記載のデータ記憶装置。
10. 前記ジェネリックドメイン名は前記現在のページに対応するドメイン名であるか、または、前記ジェネリックドメイン名は前記現在のページの前記ドメイン名とは異なるドメイン名である、請求項６に記載のデータ記憶装置。

Images