JP6506050B2 - 端末電子機器 - Google Patents

Description

本発明は端末電子機器に関し、特に、ローカルストレージを有効に利用できるキャッシュファイルシステムを備えた端末電子機器に関する。

複数の端末電子機器が、ネットワークを介してホスト装置（サーバ）のファイルを共有する分散ファイルシステムが提案されているが、端末電子機器では、ホスト装置から取り込んだファイルを自分の記憶装置（ローカルストレージ）に保持しておく（キャッシングする）ことで、ファイルへのアクセスを高速化している。このため、端末電子機器には取り込むファイルに対する十分な記憶容量が要求される。

端末電子機器としてゲーム機を例に採れば、昨今では、ゲーム機で実行されるゲームプログラムも高度化、複雑化し、プログラム量は増える一方であり、ローカルストレージに要求される記憶容量も増大する傾向にある。

例えば、特許文献１には、端末内の記憶容量が足りなくなった場合に、優先度が低いファイルや、参照時刻が古いファイルをパージすることで記憶容量を確保する構成が開示されている。

また、端末電子機器では、ファイルを最新の状態に保つために、ホスト装置に定期的にアクセスしてファイルを更新する必要があるが、更新すべきファイルが大きくなるほどコストが増大する。

特許文献２では、ファイルの更新を効率的に行うために、サーバと端末とが対話しながらファイルの変更点の情報を交換するシステムが開示されている。

特開平７−１８２２２０号公報 特許第４７９４１４３号公報

以上説明したように分散ファイルシステムにおいては、端末電子機器に要求される記憶容量が増大する傾向にあるが、これまでは、要求に応じて記憶容量を増やすか、記憶容量が足りなくなった場合に、一部のファイルをパージするなどの対策しか行われていなかった。また、ファイルの更新に際しても、サーバと端末とが対話を繰り返すなど、非効率な方法が採られていた。

本発明は上記のような問題を解決するためになされたものであり、要求される記憶容量の増大に対応できると共に、効率的にファイルの更新が可能なキャッシュファイルシステムを備えた端末電子機器を提供することを目的とする。

本発明に係る端末電子機器の第１の態様は、ホスト装置内のファイルのデータをネットワークを介してダウンロードし、内部の記憶装置にキャッシュされたデータを管理するキャッシュファイルシステムを備えた端末電子機器であって、前記キャッシュファイルシステムは、前記記憶装置内に設けられ、前記ファイルを構成する最小管理単位どうしの繋がりを示すチェーン情報を管理する管理テーブルを備え、前記管理テーブルは、前記記憶装置の記憶容量を越える記憶容量を管理可能な行数を有し、前記記憶装置の記憶容量を越えた分の行を前記ホスト装置内の前記ファイルの前記データの管理に割り当てることで、前記記憶装置にキャッシュされた前記データと共に前記ホスト装置内の前記ファイルの前記データも管理する。

本発明に係る端末電子機器の第２の態様は、前記キャッシュファイルシステムが、前記ファイルの前記データを前記最小管理単位ごとにダウンロードし、前記管理テーブルは、前記最小管理単位ごとに、前記ホスト装置内の前記ファイルの前記データおよび前記記憶装置にキャッシュされた前記データを管理する。

本発明に係る端末電子機器の第３の態様は、前記キャッシュファイルシステムが、前記ホスト装置内の前記ファイルの前記データを逐次的にダウンロードする。

本発明に係る端末電子機器の第４の態様は、前記管理テーブルが、記憶装置内データの管理領域とホスト装置内データの管理領域とに区分され、前記記憶装置にキャッシュされた前記データは、前記記憶装置内データの管理領域で管理され、前記ホスト装置内の前記ファイルの前記データは、前記ホスト装置内データの管理領域で管理される。

本発明に係る端末電子機器の第５の態様は、前記キャッシュファイルシステムが、前記管理テーブルの前記記憶装置内データの管理領域の前記記憶装置にキャッシュされた前記データを管理する行を削除することで、前記記憶装置にキャッシュされた前記データを削除する。

本発明に係る端末電子機器の第６の態様は、前記キャッシュファイルシステムが、前記記憶装置にキャッシュされた前記データのうち、使われてから最も長い時間が経ったデータを削除する。

本発明に係る端末電子機器の第７の態様は、前記キャッシュファイルシステムが、前記記憶装置にキャッシュされた前記データのうち、使用回数が規定値より低いデータを削除する。

本発明に係る端末電子機器の第８の態様は、前記管理テーブルが、前記記憶装置内データの管理領域では、前記最小管理単位ごとに採番された番号と、次に続く前記最小管理単位の番号とが１つの行に記録され、前記ホスト装置内データの管理領域では、前記最小管理単位が連続する場合には、連続する前記最小管理単位の先頭の行に、前記最小管理単位の連続数が記載される。

本発明に係る端末電子機器の第９の態様は、前記ホスト装置が、前記ファイルに変更があった場合、その変更内容を示す更新リストを作成しリビジョン番号を付して管理し、前記キャッシュファイルシステムは、前記ホスト装置へのアクセス時に、前記ホスト装置で管理されている前記リビジョン番号を確認し、前記リビジョン番号が変更されている場合には、前記更新リストを参照して前記管理テーブルを変更する。

本発明に係る端末電子機器の第１０の態様は、前記キャッシュファイルシステムが、前記ファイルが更新された場合は、該当ファイルの全データまたは更新された部分のデータが前記ホスト装置内データの管理領域にあるように前記管理テーブルを変更する。

本発明に係る端末電子機器の第１１の態様は、前記キャッシュファイルシステムが、前記ファイルが追加された場合は、該当ファイルの全データが前記ホスト装置内データの管理領域にあるように前記管理テーブルを変更する。

本発明に係る端末電子機器の第１２の態様は、前記キャッシュファイルシステムは、前記ファイルが削除された場合は、該当ファイルの全データを削除するように前記管理テーブルを変更する。

本発明に係る端末電子機器によれば、端末電子機器の記憶装置に要求される記憶容量の増大に対応できると共に、効率的にファイルの更新が可能なキャッシュファイルシステムを備えた端末電子機器が得られる。

本発明に係るキャッシュファイルシステムを備えた端末電子機器の構成を示すブロック図である。 ローカルストレージが空の状態を示す図である。 端末電子機器で作成された初期段階のＦＡＴエントリおよびディレクトリエントリを示す図である。 サーバからのファイル読み込みを説明する図である。 サーバから逐次にダウンロードする場合のＦＡＴエントリの書き込み例と、データ領域に書き込まれるデータの例を示す図である。 ファイルの更新、追加、削除の具体例を説明する図である。 ファイルの更新、追加、削除の具体例を説明する図である。 ファイルの更新、追加、削除の具体例を説明する図である。 ファイルの更新、追加、削除の具体例を説明する図である。 ＦＡＴエントリの書き込みの変形例を説明する図である。 ＦＡＴエントリの書き込みの変形例を説明する図である。 従来的なＦＡＴエントリを説明する図である。

＜はじめに＞
発明の説明に先立って、従来的なＦＡＴ（File Allocation Table）ファイルシステムについて説明する。ＦＡＴファイルシステムでは、管理テーブル内に記憶装置に格納された実データのチェーン情報を格納している。

すなわち、ファイルはクラスタを最小管理単位として構成されているが、クラスタの記憶装内での物理的な位置は必ずしも連続しているわけではない。そのためＦＡＴによって各クラスタがどのように繋がって、１つのファイルを構成しているかの情報（チェーン情報）を管理しており、ＦＡＴの各エントリは、１つのクラスタに対応している。なお、ファイルのファイル名や、ファイルの先頭クラスタのクラスタ番号はディレクトリエントリに記録されている。

以下にＦＡＴエントリおよびディレクトリエントリの一例について、図１２を用いて説明する。

図１２においては、ファイルａ．ｂｉｎがクラスタ番号１０００から始まる場合を示しており、管理テーブル（ＦＡＴエントリ）においては、クラスタ番号１０００以下のクラスタについてのチェーン情報を格納している。

すなわち、ＦＡＴエントリには、記憶装置においてデータが格納されているクラスタ番号と、次に続くクラスタのクラスタ番号の値とが記録されている。

図１２に示すファイルａ．ｂｉｎのデータは、クラスタ番号１０００、１００１、１００２、２０００、２００１、２００２、３０００、３００１、３００２の順に記憶装置に格納されていることになる。

すなわち、クラスタ番号１０００に続くクラスタのクラスタ番号は１００１であり、クラスタ番号１００１に続くクラスタのクラスタ番号は１００２であり、クラスタ番号１００２のクラスタに続くクラスタのクラスタ番号は２０００であることが示されている。なお、図１２においては、便宜的に各クラスタの繋がりを矢印で表している。

また、クラスタ番号２０００に続くクラスタのクラスタ番号は２００１であり、クラスタ番号２００１に続くクラスタのクラスタ番号は２００２であり、クラスタ番号２００２のクラスタに続くクラスタのクラスタ番号は３０００であることが示されている。

さらに、クラスタ番号３０００に続くクラスタのクラスタ番号は３００１であり、クラスタ番号３００１に続くクラスタのクラスタ番号は３００２であり、クラスタ番号３０００のクラスタはＥＯＣ（End Of Cluster chain）であることが示されている。

通常、このテーブルはローカルストレージの記憶容量が管理できるだけの領域を持っており、例えば、ローカルストレージが１００００クラスタであれば、１００００行（要素）もしくはそれ以上のテーブルとなっている。

このように、ＦＡＴファイルシステムでは、ローカルストレージの記憶容量を管理できるだけのテーブルを準備しているが、先に説明したように、ローカルストレージに要求される記憶容量は増大する傾向にあるが、それに応じてローカルストレージの記憶容量を増やすにはコスト的に難しいと共に、コストを無視したとしても端末電子機器では、記憶容量の拡大には物理的な限界がある。

そこで、本発明は、プログラムの実行等に必要なデータの全てを格納できるローカルストレージを有さない場合であっても、チェーン情報を管理する管理テーブルには、ローカルストレージの記憶容量を越えて管理可能な行数（要素数）を持たせ、ローカルストレージの記憶容量を越えた分の行をホスト装置（サーバ）内のファイルのデータの管理に割り当てることで、ローカルストレージ内の管理テーブルで、サーバ内のファイルのデータも管理する。そして、プログラムの実行等に必要なデータは、ネットワークを介して逐次的にサーバからダウンロードして実行させるキャッシュファイルシステムを提供する。

＜実施の形態＞
以下、図１〜図９を用いて、本発明に係るキャッシュファイルシステムの実施の形態について説明する。

＜装置構成＞
図１は、本発明に係るキャッシュファイルシステムを備えた端末電子機器ＥＱの構成を示すブロック図である。図１に示すように、端末電子機器ＥＱは、インターネットなどのネットワークＮＷに接続される電子機器である。なお、ネットワークＮＷはインターネットに限定されるものではなく、ＬＡＮ（Local Area Network）や、ＷＡＮ（Wide Area Network）や、公衆網等も含まれる。

ネットワークＮＷには、端末電子機器ＥＱのホスト装置となるサーバＳＶも接続されており、端末電子機器ＥＱはネットワークＮＷを介してサーバＳＶにアクセスして、サーバＳＶ内の記憶装置ＭＲからファイルセットをダウンロードする。なお、サーバＳＶは複数の端末電子機器ＥＱとの間でもファイルを共有する。

端末電子機器ＥＱは、サーバＳＶからダウンロードしたファイルセットのデータをローカルストレージ１０内のデータ領域１２にキャッシングするが、ダウンロードに際しては、ファイルセット内のファイルのデータを、ファイル単位でダウンロードするのではなく、必要なデータだけをクラスタ単位でダウンロードしてキャッシングする。このような処理を行うためにローカルストレージ１０は本発明に係るキャッシュファイルシステム２０で管理されている。

なお、キャッシュファイルシステム２０は、例えば、図示されないＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）およびＲＯＭ（Read Only Memory）等で構成され、ＲＯＭ内に格納されたキャッシュファイルプログラムをＲＡＭに読み出し、当該プログラムをＣＰＵで実行することによって実現される。また、ローカルストレージ１０は、フラッシュメモリなどの記憶装置で構成される。なお、上記ＣＰＵに端末電子機器ＥＱのアプリケーションプログラムを実行する機能を持たせても良い。

＜ファイルシステムの動作＞
以下、キャッシュファイルシステムの動作について説明する。なお、以下においてはＦＡＴファイルシステムに適用した場合を例に採って説明するが、本発明の適用はＦＡＴファイルシステムに限定されるものではない。

＜初期状態＞
初期状態では、ローカルストレージは空の状態であるか、あるいは、サーバＳＶ内にある全てのファイルの管理情報だけが保存されており、実際のデータは全てサーバ内にのみ存在する。図２においては、ローカルストレージ１０（図１）が空の状態を示しており、管理領域１１内のディレクトリエントリにもＦＡＴエントリ（管理テーブル）にも何も書き込まれていない。これは、全てのファイルのデータがサーバＳＶ内にあることを示している。

ここで、本発明に係るキャッシュファイルシステムの特徴的な構成として、ＦＡＴエントリにはローカルストレージの記憶容量を越えて管理可能な行数（要素数）を持たせ、ＦＡＴエントリをローカルストレージ内データの管理領域とサーバ内データの管理領域とに区分することで、ＦＡＴエントリをローカルストレージ内のデータの管理だけでなくサーバ内のデータの管理にも使用する構成を採っている。このため、図２のＦＡエントリにおいては、ローカルストレージ内データの管理領域を上部側に設け、サーバ内データの管理領域を下部側に設けた構成となっている。

また、図２に示すように、サーバＳＶにはリビジョン番号ｒ１のファイルセットとしてファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎが格納されている。

端末電子機器ＥＱは、サーバＳＶにアクセスすると、サーバＳＶからファイル名、ファイルサイズおよびリビジョン番号などをダウンロードし、それらに基づいて初期段階のＦＡＴエントリおよびディレクトリエントリを作成して、初期状態のローカルストレージ１０に書き込む。なお、リビジョン番号はサーバ内のファイルおよびファイル構成に変更があった場合には変更され、端末電子機器ＥＱは、リビジョン番号が変わることで、ファイルおよびファイル構成に変更があったことを検出できる。

図３には、端末電子機器ＥＱで作成された初期段階のＦＡＴエントリおよびディレクトリエントリを示す。図３に示すように、ディレクトリエントリには、ファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎのそれぞれの先頭クラスタのクラスタ番号１１０００、１２０００および１３０００が書き込まれている。

また、ＦＡＴエントリには、ファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎのそれぞれを構成するクラスタのクラスタ番号と、次に続くクラスタのクラスタ番号の値とが書き込まれている。これらは、サーバ内データの管理領域に書き込まれており、ローカルストレージ内データの管理領域には何も書き込まれていない。これは、初期段階のＦＡＴエントリを作成した時点では、ファイルのダウンロードを行っておらず、未だ全てのファイルのデータがサーバＳＶ内にあるためである。

従って、ＦＡＴエントリはサーバ内のデータの管理だけを行っており、例えば、クラスタ番号１１０００からクラスタ番号１１００８までの９クラスタがファイルａ．ｂｉｎを構成するクラスタであり、クラスタ番号１１００８のクラスタがＥＯＣとなっている。

図３のＦＡＴエントリにおいて、例えば、クラスタ番号１１０００に対する値は１１００１とされており、クラスタ番号１１０００のクラスタに続くクラスタのクラスタ番号は１１００１であることが判る。以下、同様にしてクラスタ番号１１００８までのクラスタの繋がりが示されている。なお、図３においては、便宜的に各クラスタの繋がりを矢印で表している。

また、クラスタ番号１２０００からクラスタ番号１２００８までの９クラスタがファイルｂ．ｂｉｎを構成するクラスタであり、クラスタ番号１３０００からクラスタ番号１３００８までの９クラスタがファイルｃ．ｂｉｎを構成するクラスタである。

ここで、例えば、ファイルａ．ｂｉｎを構成するクラスタが、クラスタ番号１１０００からクラスタ番号１１００８までとなっているのは、端末電子機器ＥＱであり、端末電子機器ＥＱがサーバＳＶからダウンロードしたファイルａ．ｂｉｎのファイルサイズに基づいて、クラスタの個数を算出してそれぞれのクラスタに採番した結果であり、このクラスタ番号はサーバＳＶ内のクラスタ番号と対応するものではない。これは、ディレクトリエントリに書き込まれた先頭クラスタのクラスタ番号についても同じである。

このように、上記では、端末電子機器ＥＱがサーバＳＶからダウンロードしたファイルサイズに基づいてクラスタ番号等を決定して初期段階のＦＡＴエントリを作成する構成を説明したが、サーバＳＶからファイルごとのクラスタ数をダウンロードして、ＦＡＴエントリに書き込んでも良い。この場合も、全てのファイルのデータはサーバＳＶ内にあるので、結果として図３と同じようなＦＡＴエントリとなる。

＜サーバからのファイル読み込み＞
端末電子機器ＥＱは、初期段階のＦＡＴエントリが得られると、図４に示すように、サーバＳＶにアクセスする。この後、サーバＳＶ内の記憶装置ＭＲからファイルセットをダウンロードするが、このときにダウンロードするのはファイル全体ではなく、現状で必要な部分だけをダウンロードする。

すなわち、先に説明したようにサーバＳＶ内に格納されるファイルが大規模化しつつあるが、実際に必要となるのはその一部分でしかない場合がある。例えば、ゲームプログラムのファイルである場合、ゲームの進行に応じて要、不要のデータが変わり、あるステージでは必要なデータ（ステージデータ、キャラクタデータ、ムービーデータ）は、次のステージでは不要となる。換言すれば、次のステージで不要なデータは、例えば、現在のステージが終了する直前にダウンロードすれば良く、現在のステージでダウンロードしておく必要はない。

このように、サーバＳＶからファイルをダウンロードする際には必要な部分だけを逐次にダウンロードすることで、ダウンロードするデータ量が少なくなり、ファイル取得に要する時間が短縮されると共に、必要最小限のデータをローカルストレージ１０に保存するので、ローカルストレージ１０を有効に利用することができる。また、サーバＳＶに対する負荷を低減することもできる。すなわち、サーバＳＶには複数の端末電子機器ＥＱが同時にアクセスする場合があるが、そのような場合でも、個々の端末電子機器ＥＱがダウンロードするデータ量が少なければ、サーバＳＶに過大な負荷がかかることを抑制し、サーバＳＶが機能不全となることを抑制できる。

図５には、逐次にダウンロードする場合のＦＡＴエントリの書き込み例と、データ領域１２に書き込まれるデータの例を示す。

図５に示すように、ディレクトリエントリには、ファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎのそれぞれの先頭クラスタのクラスタ番号１０００、２０００および３０００が書き込まれている。

また、ＦＡＴエントリのローカルストレージ内データの管理領域には、ファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎの中の必要な部分のクラスタのクラスタ番号と、次に続くクラスタのクラスタ番号の値とが書き込まれている。

図５の例では、ファイルａ．ｂｉｎを構成する９クラスタのうち、６クラスタがダウンロードされてローカルストレージ１０に存在し、残りの３クラスタはサーバ内に存在している例を示している。これは、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎにおいても同じである。

すなわち、クラスタ番号１０００からクラスタ番号１００２に対応するデータがローカルストレージ１０に存在し、クラスタ番号１００２に対する値は１１００３とされており、クラスタ番号１１００２のクラスタに続くクラスタのクラスタ番号は１１００３である。そして、クラスタ番号１１００３に対応するデータはサーバＳＶに存在し、サーバＳＶにはクラスタ番号１１００３からクラスタ番号１１００５に対応するデータが存在している。そしてクラスタ番号１１００５に対する値は１５００とされており、クラスタ番号１１００５のクラスタに続くクラスタのクラスタ番号は１５００である。

クラスタ番号１５００に対応するデータはローカルストレージ１０に存在し、ローカルストレージ１０にはクラスタ番号１５００からクラスタ番号１５０２に対応するデータが存在し、クラスタ番号１５０２のクラスタがＥＯＣとなっている。

このように、クラスタ単位でデータを管理することで、クラスタ単位でのキャッシングを実現することができる。すなわち、図５のデータ領域には、サーバからダウンロードしたデータがクラスタ単位でキャッシュされた状態を示しており、例えば、クラスタ番号１０００からクラスタ番号１００２にそれぞれ対応するデータとして、ファイルａ．ｂｉｎの１クラスタ目から３クラスタ目までのデータが格納され、また、クラスタ番号１５００からクラスタ番号１５０２にそれぞれ対応するデータとして、ファイルａ．ｂｉｎの７クラスタ目から９クラスタ目までのデータが格納されている。

なお、上記ではファイルａ．ｂｉｎを構成する９クラスタのうち、６クラスタがダウンロードされてローカルストレージ１０に存在している例を示したが、ローカルストレージ１０に格納されていないデータに対しては、サーバＳＶからダウンロードする。

端末電子機器ＥＱで実行されるアプリケーション、例えばゲームからファイルａ．ｂｉｎの最初の３クラスタに対してアクセスが発生した場合、キャッシュファイルシステムは、ローカルストレージからデータを読み出してアプリケーションに与えるが、次に、ファイルａ．ｂｉｎの４クラスタ目から６クラスタ目までのデータに対するアクセスが発生した場合、キャッシュファイルシステムは、ＦＡＴエントリの書き込みに基づいて、該当するクラスタのデータをサーバからダウンロードする。

例えば、クラスタ番号１１００３からクラスタ番号１１００５に対応するデータにアクセスが発生した場合、キャッシュファイルシステムは、ＦＡＴエントリの書き込みから、それらはサーバＳＶに存在しているものと判断して、サーバＳＶに対して、ファイルａ．ｂｉｎの４クラスタ目から６クラスタ目までのデータを要求する。要求を受けたサーバＳＶは要求されたデータを端末電子機器ＥＱに送信し、キャッシュファイルシステムは、サーバＳＶから受信したデータをアプリケーションに与える。この場合、一旦、受信したデータをローカルストレージ１０に保存(キャッシング)しても良い。

なお、ローカルストレージ１０に空きがなくなると、ローカルストレージ内のデータを削除することで新たにダウンロードしたデータをキャッシュすることができる。

＜サーバ内のファイルの更新、追加、削除＞
サーバＳＶ内のファイルおよびファイル構成に変更があった場合、それを端末電子機器ＥＱ内のキャッシュファイルシステムに反映させる必要がある。サーバＳＶに格納されているファイルセットには、リビジョン番号が設定されており、サーバＳＶ内のファイルおよびファイル構成が変更されるたびにリビジョン番号が更新される。また、リビジョンごとに、どのファイルが更新、追加、削除されたかを示す更新リストも作成される。

一方、端末電子機器ＥＱでもリビジョン番号を管理しており、端末電子機器ＥＱは、サーバＳＶへのアクセス時にサーバＳＶが管理しているファイルセットのリビジョン番号と、ローカルストレージ１０で管理しているリビジョン番号とを比較する。リビジョン番号が異なっている場合、ファイルの更新リストを参照し、以下の操作を行う。

＜更新されたファイルに対しての操作＞
ローカルストレージの対応するファイルのキャッシュを全て削除し、ＦＡＴエントリを該当ファイルの全データがサーバ内にあることを示すように更新するか、更新された部分のデータがサーバ内にあることを示すように更新する。後者の場合は、ローカルストレージのキャッシュの削除は、更新された部分に対応するキャッシュのみとなる。

なお、ファイル更新時には、ファイル単位ではなく、クラスタ単位で更新情報を管理しても良い。更新前のファイルと、更新後のファイルとで差分を取り、差分のあるクラスタのみがサーバ内にデータがあることを示すようにＦＡＴエントリを作成する。なお、更新箇所が少ない場合はクラスタ単位で更新を行うが、更新箇所が多い場合はファイル全体で更新するなど、ファイル単位での更新とクラスタ単位での更新を混在させても良い。これにより、より効率的なキャッシュが実現できる。

＜追加されたファイルに対しての操作＞
ローカルストレージの管理情報に該当ファイルを追加する。また、そのファイルの全データがサーバ内にあることを示すようにＦＡＴエントリを生成する。

＜削除されたファイルに対しての操作＞
ローカルストレージの管理情報から、該当ファイルを削除する。

これらの操作により、サーバＳＶとローカルストレージ１０との間で透過的なファイルシステムを実現することが可能になる。このように、サーバＳＶとローカルストレージ１０とで、リビジョン番号を同じにすることを「同期」と呼称する。

なお、サーバＳＶ内のファイルの更新リストには、必要最小限の更新内容が書き込まれている。なお、このような更新リストは、リビジョンの更新ごとに作成される場合と、全リビジョンの更新内容が書き込まれた場合とがある。そのため、ローカルストレージ１０のリビジョン番号が何であっても、最新のリビジョン番号に同期が可能である。

以下、ファイルの更新、追加、削除の具体例について図６〜図９を用いて説明する。図５に示したようにＦＡＴエントリの書き込みが行われた後、図６に示すようにサーバＳＶ内のファイルおよびファイル構成に変更があり、ファイルセットのリビジョン番号がｒ１からｒ２に更新されたものとする。

リビジョン番号ｒ２のファイルセットでは、ファイルｃ．ｂｉｎが削除されてファイルｄ．ｂｉｎが追加されるというファイル構成の変更があり、また、ファイルｂ．ｂｉｎが全体的に変更されると共に、ファイルａ．ｂｉｎの３クラスタ目が変更されている。これらの変更については更新リストに記載されている。

図７には、ネットワークＮＷを介してサーバＳＶからダウンロードしたリビジョン番号ｒ２のファイルセットと更新リストに基づいて作成されたディレクトリエントリとＦＡＴエントリを示す。

図７に示すように、ディレクトリエントリには、ファイルａ．ｂｉｎ、ファイルｂ．ｂｉｎおよびファイルｄ．ｂｉｎのそれぞれの先頭クラスタのクラスタ番号１０００、１５０００および１６０００が書き込まれている。

また、ＦＡＴエントリのローカルストレージ内データの管理領域には、ファイルａ．ｂｉｎの中の必要な部分のクラスタのクラスタ番号と、次に続くクラスタのクラスタ番号の値とが書き込まれている。

図７の例では、ファイルａ．ｂｉｎを構成する９クラスタのうち、５クラスタがダウンロードされてローカルストレージ１０に存在し、残りの４クラスタはサーバＳＶ内に存在している例を示している。なお、ファイルａ．ｂｉｎの３クラスタ目は、クラスタ番号１４０００に置き換わってサーバＳＶ内に存在している。

すなわち、クラスタ番号１０００、クラスタ番号１００１に対応するデータがローカルストレージ１０に存在し、クラスタ番号１００１に対する値は１４０００とされており、クラスタ番号１４０００に対応するデータはサーバＳＶ内に存在している。

クラスタ番号１４０００のクラスタに続くクラスタのクラスタ番号は１１００３であって、クラスタ番号１１００３に対応するデータはサーバＳＶに存在し、サーバＳＶにはクラスタ番号１１００３からクラスタ番号１１００５に対応するデータが存在している。そしてクラスタ番号１１００５に対する値は１５００とされており、クラスタ番号１１００５のクラスタに続くクラスタのクラスタ番号は１５００である。

また、クラスタ番号１５００に対応するデータはローカルストレージ１０に存在し、ローカルストレージ１０にはクラスタ番号１５００からクラスタ番号１５０２に対応するデータが存在し、クラスタ番号１５０２のクラスタがＥＯＣとなっている。

ファイルｂ．ｂｉｎは、全体的に変更されることで９クラスタ構成から３クラスタ構成となっており、その３クラスタは全てサーバＳＶ内に存在しており、ＦＡＴエントリのサーバ内データの管理領域に書き込まれている。

すなわち、クラスタ番号１５０００からクラスタ番号１５００２に対応するデータがサーバＳＶに存在している。そしてクラスタ番号１５０００に対する値は１５００１とされており、クラスタ番号１５０００のクラスタに続くクラスタのクラスタ番号は１５００１である。また、クラスタ番号１５００１に対する値は１５００２とされており、クラスタ番号１５００１のクラスタに続くクラスタのクラスタ番号は１５００２であり、クラスタ番号１５００２のクラスタがＥＯＣとなっている。

ファイルｄ．ｂｉｎは１クラスタ構成であり、その１クラスタはサーバＳＶ内に存在しており、ＦＡＴエントリのサーバ内データの管理領域に書き込まれている。

すなわち、クラスタ番号１６０００のクラスタに対応するデータがサーバＳＶに存在しており、そのクラスタがＥＯＣとなっている。

以上説明したように、クラスタ単位でデータを管理しているので、ファイル中の一部のクラスタに変更があった場合にも対応することができ、変更を端末電子機器ＥＱ内のキャッシュファイルシステムに反映させることができる。

次に、図８に示すようにサーバＳＶ内のファイルおよびファイル構成にさらなる変更があり、ファイルセットのリビジョン番号がｒ２からｒ３に更新された場合について説明する。

リビジョン番号ｒ３のファイルセットでは、ファイルｂ．ｂｉｎ削除されるというファイル構成の変更があり、また、ファイルａ．ｂｉｎが２クラスタ拡張されるように変更されている。これらの変更については更新リストに記載されている。

図８には、ネットワークＮＷを介してサーバＳＶからダウンロードしたリビジョン番号ｒ３のファイルセットと更新リストに基づいて作成されたディレクトリエントリとＦＡＴエントリを示す。

図８に示すように、ディレクトリエントリには、ファイルａ．ｂｉｎおよびファイルｄ．ｂｉｎのそれぞれの先頭クラスタのクラスタ番号１０００および１６０００が書き込まれている。

また、ＦＡＴエントリのローカルストレージ内データの管理領域には、ファイルａ．ｂｉｎの中の必要な部分のクラスタのクラスタ番号と、次に続くクラスタのクラスタ番号の値とが書き込まれている。

図８の例では、ファイルａ．ｂｉｎを構成する１１クラスタのうち、５クラスタがダウンロードされてローカルストレージ１０に存在し、残りの６クラスタはサーバＳＶ内に存在している例を示している。なお、ファイルａ．ｂｉｎの１０クラスタ目と１１クラスタ目は、それぞれクラスタ番号１２５００およびクラスタ番号１２５０１に対応するデータとしてサーバＳＶ内に存在している。

すなわち、クラスタ番号１０００、クラスタ番号１００１に対応するデータがローカルストレージ１０に存在し、クラスタ番号１００１に対する値は１４０００とされており、クラスタ番号１４０００のクラスタはサーバＳＶ内に存在している。

クラスタ番号１４０００のクラスタに続くクラスタのクラスタ番号は１１００３であって、クラスタ番号１１００３に対応するデータはサーバＳＶに存在し、サーバＳＶにはクラスタ番号１１００３からクラスタ番号１１００５に対応するデータが存在している。そしてクラスタ番号１１００５に対する値は１５００とされており、クラスタ番号１１００５のクラスタに続くクラスタのクラスタ番号は１５００である。

また、クラスタ番号１５００に対応するデータはローカルストレージ１０に存在し、ローカルストレージ１０にはクラスタ番号１５００からクラスタ番号１５０２のクラスタが存在し、クラスタ番号１５０２に対する値は１２５００とされており、クラスタ番号１２５００に対応するデータはサーバＳＶ内に存在している。

クラスタ番号１２５００のクラスタに続くクラスタのクラスタ番号は１２５０１であって、クラスタ番号１２５０１に対応するデータはサーバＳＶに存在し、クラスタ番号１２５０１のクラスタがＥＯＣとなっている。

ファイルｄ．ｂｉｎは１クラスタ構成であり、その１クラスタはサーバＳＶ内に存在しており、ＦＡＴエントリのサーバ内データの管理領域に書き込まれている。

すなわち、クラスタ番号１６０００に対応するデータがサーバＳＶに存在しており、そのクラスタがＥＯＣとなっている。

以上の説明では、ファイルセットのリビジョン番号がｒ１からｒ２に更新され、さらにｒ３に変更された場合について、更新の順にＦＡＴエントリを変更する例を説明したが、端末電子機器ＥＱでの処理負荷を軽減するため、最新リビジョンに一気に更新する構成としても良い。

すなわち、リビジョン番号ｒ１の情報を持つ端末電子機器ＥＱが、サーバＳＶ内のリビジョン番号ｒ３のファイルと同期するには、更新リストからリビジョン番号ｒ１からリビジョン番号ｒ３への変更内容を更新ごとに取得して同期する必要がある。

それに対し、予めリビジョン番号ｒ１からリビジョン番号ｒ３への更新リストをサーバ内に生成しておけば、リビジョン番号ｒ１の情報を持つ端末電子機器ＥＱは、リビジョン番号ｒ１からリビジョン番号ｒ３への更新リストを参照すれば良く、処理負荷を低減することができる。

図９には、ネットワークＮＷを介してサーバＳＶからリビジョン番号ｒ１からリビジョン番号ｒ３への更新リストをダウンロードしてＦＡＴエントリを変更する例を示している。

図９の例では、ファイルａ．ｂｉｎの３クラスタ目が変更されると共に２クラスタ拡張されるように変更され、ファイルｂ．ｂｉｎおよびファイルｃ．ｂｉｎが削除されてファイルｄ．ｂｉｎが追加されるというファイル構成の変更が更新リストに記載されている。なお、このような更新リストに基づいて作成されたディレクトリエントリとＦＡＴエントリは、図８と同じものとなる。

なお、サーバＳＶ内のファイルおよびファイル構成の変更の確認方法は、端末電子機器ＥＱの起動時や、動作中の端末電子機器ＥＱからサーバＳＶへのアクセス発生時などに行えば良い。例えば、ゲームプログラムのファイルである場合、ゲームの進行に応じてデータのダウンロードが必要となった場合にサーバＳＶにアクセスするので、その際に変更を確認して更新すれば良い。

＜キャッシュの削除について＞
ローカルストレージ１０の記憶容量には限りがあるため、適宜、キャッシュを削除する必要がある。通常のファイルシステムであれば、キャッシュの削除はファイルの削除となるが、本発明のキャッシュファイルシステムでは、ＦＡＴエントリを操作し、ＦＡＴエントリから該当ファイルを管理する行を削除することで、該当ファイルの全データがサーバ内にあることを示すようにすれば済む。

また、どのキャッシュを削除するかについては、例えば、使われてから最も長い時間が経ったキャッシュを削除する方法が挙げられる。これは、タイムスタンプの情報を参照することで、何れのキャッシュが最も古いかを容易に判断できるので、簡便な方法である。

また、各ファイルの使用回数を保存しておき、使用回数が規定値よりも低いキャッシュを削除する方法が挙げられる。

また、サーバからの指示に基づいて削除するキャッシュを決定しても良い。例えばゲームのプログラムである場合、ゲームが進行することにより、不必要になるデータが存在するが、このようなデータは予め判っているので、ゲーム進行に応じて、サーバからの指示に基づいて対応するキャッシュを削除しても良いし、サーバ内にゲーム進行状況と必要／不要ファイルの対応リストを準備しておき、端末電子機器ＥＱがそれを参照して適宜にキャッシュを削除しても良い。

また、削除対象を決められないが、ローカルストレージ１０の記憶容量が不足しそうな場合には、ランダムに削除しても良い。なお、消去単位はファイル単位でも良いし、クラスタ単位でも良い。

なお、ローカルストレージ１０のキャッシュの削除判定は、ローカルストレージ１０の空き容量が、規定値よりも少なくなった場合や、サーバへのアクセス時に判定すれば良い。

また、ローカルストレージ１０のキャッシュファイルに対して、何らかの不正操作、例えば、プログラムの改変などを見つけた場合、サーバＳＶからそのファイルを削除する指示を与えるようにしても良い。なお、不正操作の検出は、サーバＳＶによるキャッシュファイルのＣＲＣ （Cyclic Redundancy Check）などで行うことができる。

＜ＦＡＴエントリの書き込みの変形例＞
以下、図１０、１１を用いて、ＦＡＴエントリの書き込みの変形例について説明する。

ＦＡＴエントリのサーバ内データの管理領域においては、サーバ内にあるデータについては、クラスタが連続する場合には、次に続くクラスタのクラスタ番号の値を省略し、クラスタの連続数を記録する構成としても良い。

例えば、図１０に示すＦＡＴエントリでは、ファイルａ．ｂｉｎを構成する９クラスタのうち、３クラスタがダウンロードされてローカルストレージ１０に存在し、残りの６クラスタはサーバ内に存在している例を示している。

すなわち、クラスタ番号１０００からクラスタ番号１００２に対応するデータがローカルストレージ１０に存在し、クラスタ番号１００２に対する値は１１０００とされており、クラスタ番号１００２のクラスタに続くクラスタのクラスタ番号は１１０００である。そして、クラスタ番号１１０００に対応するデータはサーバＳＶに存在している。

サーバ内データの管理領域のクラスタ番号１１０００に対応するデータにおいては、連続数６が書き込まれると共に、次のクラスタがＥＯＣであることが書き込まれている。これにより、ファイルａ．ｂｉｎの４クラスタ目から９クラスタ目はサーバ内にあり、９クラスタ目がＥＯＣ（ファイル終端）であることが表されている。

また、図１１に示すＦＡＴエントリでは、ファイルａ．ｂｉｎを構成する９クラスタのうち、６クラスタがダウンロードされてローカルストレージ１０に存在し、残りの３クラスタはサーバ内に存在している例を示している。

すなわち、クラスタ番号１０００からクラスタ番号１００２に対応するデータがローカルストレージ１０に存在し、クラスタ番号１００２に対する値は１１０００とされており、クラスタ番号１００２のクラスタに続くクラスタのクラスタ番号は１１０００である。そして、クラスタ番号１１０００に対応するデータはサーバＳＶに存在している。

サーバ内データの管理領域のクラスタ番号１１０００に対応するデータにおいては、連続数３が書き込まれると共に、次のクラスタが３０００であることが書き込まれている。これにより、ファイルａ．ｂｉｎの４クラスタ目から６クラスタ目はサーバ内にあり、７クラスタ目はローカルストレージ１０のクラスタ番号３０００に存在することが表される。

以上説明したような書き込みを採用することで、ＦＡＴエントリの表示を簡略化して、ローカルストレージ１０の記憶容量を有効に利用することができる。

＜他の適用例＞
以上説明した実施の形態においては、本発明に係るキャッシュファイルシステムをＦＡＴファイルシステムに適用した場合を例に採って説明したが、本発明の適用はＦＡＴファイルシステムに限定されるものではない。

例えば、Ｌｉｎｕｘ（登録商標）のファイルシステムであるｅｘｔ２（second extended file system）、ｅｘｔ３（third extended file system）およびｅｘｔ４（fourth extended file system）で使われるｉノードにも適用可能である。

ｉノードではクラスタのことをブロックと呼称しており、例えば、ｉノード中の「複数個のディスクブロックアドレスの配列」が実際のデータが格納されているブロック番号を表している。

ファイルのどの位置のデータがストレージ内のどこにあるかというマップを作っているという点ではＦＡＴファイルシステムと同じであり、本発明に係るキャッシュファイルシステムの適用が可能である。

例えば、ローカルストレージ内に存在するブロックが１１０００個だった場合、ｉノード中のブロック番号に１１０００以上（例えば１１００１番目のブロック）の値が指定されている場合、そのブロックのデータはローカルストレージ内ではなく、サーバ内にのみ存在することになる。

このように、ファイルのどの位置のデータがローカルストレージ内のどこにあるかというマップを作るキャッシュファイルシステムであれば、本発明の適用は可能である。

なお、本発明は、その発明の範囲内において、実施の形態を適宜、変形、省略することが可能である。

１０ ローカルストレージ
２０ キャッシュファイルシステム
ＥＱ 端末電子機器
ＳＶ サーバ
ＮＷ ネットワーク

Claims (12)

1. ホスト装置内のファイルのデータを、ネットワークを介してダウンロードし、内部の記憶装置にキャッシュされたデータを管理するキャッシュファイルシステムを備えた端末電子機器であって、
   前記キャッシュファイルシステムは、
   前記記憶装置内に設けられ、前記ファイルを構成する最小管理単位どうしの繋がりを示すチェーン情報を管理する管理テーブルを備え、
   前記管理テーブルは、
   前記記憶装置の記憶容量を越える記憶容量を管理可能な行数を有し、前記記憶装置の記憶容量を越えた分の行を前記ホスト装置内の前記ファイルの前記データの管理に割り当てることで、前記記憶装置にキャッシュされた前記データと共に前記ホスト装置内の前記ファイルの前記データも管理する、端末電子機器。
2. 前記キャッシュファイルシステムは、
   前記ファイルの前記データを前記最小管理単位ごとにダウンロードし、
   前記管理テーブルは、
   前記最小管理単位ごとに、前記ホスト装置内の前記ファイルの前記データおよび前記記憶装置にキャッシュされた前記データを管理する、請求項１記載の端末電子機器。
3. 前記キャッシュファイルシステムは、
   前記ホスト装置内の前記ファイルの前記データを逐次的にダウンロードする、請求項１記載の端末電子機器。
4. 前記管理テーブルは、
   記憶装置内データの管理領域とホスト装置内データの管理領域とに区分され、
   前記記憶装置にキャッシュされた前記データは、前記記憶装置内データの管理領域で管理され、
   前記ホスト装置内の前記ファイルの前記データは、前記ホスト装置内データの管理領域で管理される、請求項３記載の端末電子機器。
5. 前記キャッシュファイルシステムは、
   前記管理テーブルの前記記憶装置内データの管理領域の前記記憶装置にキャッシュされた前記データを管理する行を削除することで、前記記憶装置にキャッシュされた前記データを削除する、請求項４記載の端末電子機器。
6. 前記キャッシュファイルシステムは、
   前記記憶装置にキャッシュされた前記データのうち、使われてから最も長い時間が経ったデータを削除する、請求項５記載の端末電子機器。
7. 前記キャッシュファイルシステムは、
   前記記憶装置にキャッシュされた前記データのうち、使用回数が規定値より低いデータを削除する、請求項５記載の端末電子機器。
8. 前記管理テーブルは、
   前記記憶装置内データの管理領域では、
   前記最小管理単位ごとに採番された番号と、次に続く前記最小管理単位の番号とが１つの行に記録され、
   前記ホスト装置内データの管理領域では、
   前記最小管理単位が連続する場合には、
   連続する前記最小管理単位の先頭の行に、前記最小管理単位の連続数が記載される、請求項４記載の端末電子機器。
9. 前記ホスト装置は、前記ファイルに変更があった場合、その変更内容を示す更新リストを作成しリビジョン番号を付して管理し、
   前記キャッシュファイルシステムは、
   前記ホスト装置へのアクセス時に、前記ホスト装置で管理されている前記リビジョン番号を確認し、前記リビジョン番号が変更されている場合には、前記更新リストを参照して前記管理テーブルを変更する、請求項４記載の端末電子機器。
10. 前記キャッシュファイルシステムは、
    前記ファイルが更新された場合は、該当ファイルの全データまたは更新された部分のデータが前記ホスト装置内データの管理領域にあるように前記管理テーブルを変更する、請求項９記載の端末電子機器。
11. 前記キャッシュファイルシステムは、
    前記ファイルが追加された場合は、該当ファイルの全データが前記ホスト装置内データの管理領域にあるように前記管理テーブルを変更する、請求項９記載の端末電子機器。
12. 前記キャッシュファイルシステムは、
    前記ファイルが削除された場合は、該当ファイルの全データを削除するように前記管理テーブルを変更する、請求項９記載の端末電子機器。

Images