JP2012221025A - フラッシュメモリ保持データのバックアップ通知システム、その方法およびプログラム - Google Patents

Abstract

【課題】
端末装置に搭載されたフラッシュメモリについて、メーカが保証する消去回数よりも多く使用することができ、また、端末装置のユーザにバックアップをする必要がある旨を確実に通知できるようにする。
【解決手段】
ネットワークを介して相互に通信可能な端末装置とサーバ装置とを備えるシステムであって、端末装置はフラッシュメモリのリフレッシュを実施する場合にフラッシュメモリ特性情報をサーバ装置へ送信して、サーバ装置は予め設定されたフラッシュメモリ特性情報を基準として、端末装置から送信されたフラッシュメモリ特性情報を比較し、フラッシュメモリの使用限界を予測し、フラッシュメモリの寿命が近いと判断した場合に寿命が近い旨の通知を端末装置へ送信する。
【選択図】 図１

Description

本発明は、フラッシュメモリ保持データのバックアップ通知システム、その方法およびプログラムに関する。

近年、半導体メモリ装置は、高集積化、大容量化、高速化、省電力化、低価格化等が急激に進み、広く普及するに至っている。また、半導体メモリ装置は応用範囲も広いので、半導体メモリ装置が組み込まれた電子機器も多様化が進んでいる。

フラッシュメモリは、電源を切ってもデータが消去されない不揮発性の半導体メモリ装置の一つであり、ブロック単位でのリード、ライトが可能であるため、例えば、デジタル カメラ、携帯端末、パーソナルコンピュータ、通信機等の記録媒体としての用途に好適であり、注目を集めている。

ところで、フラッシュメモリは、あるメモリセルからのデータリードを行うと、そのセルとワード線が共通であるために非選択状態の別のメモリセルに電子が蓄積されるというリードディスターブ現象が発生する。これが繰り返されると非選択状態のセルの保持するデータ値が変化する現象があるため、注意する必要がある。

このようなデータ化け防止策として、特許文献１には、データのエラー訂正符号（以下、「ＥＣＣ」という。）および消去、再ライト（以下、「リフレッシュ」という。）を用いたものが記載されている。

前述したリードディスターブ現象についてはＥＣＣおよびリフレッシュで対策できるものの、特許文献２に示すように、リードディスターブは消去回数に影響され、消去回数が増加するとリードディスターブ特性は悪化し、データライト後にそのデータ値を正しくリードできる回数が減少する。そのような事情から、フラッシュメモリにはメーカが推奨する保証消去回数が設けられている。

特開２００４−３２６８６７号公報 特開２００９−１２９０７０号公報

しかしながら、リードディスターブ現象についてリフレッシュで対策する場合、予め消去可能な回数が分かっていれば、フラッシュメモリのブロックの残り消去回数が予測することができるので、寿命が近づいたときには端末機器のユーザへデータのバックアップを促すこともできるが、メーカが保障する消去回数は一律に設定されているため、実際に消去可能な回数より少なく、実際の寿命まで使い切ることができないという問題を生じていた。

そこで本発明は、メーカが保証する消去回数よりも多く使用することができ、かつ、端末機器のユーザに対しデータバックアップが必要であることを確実に通知することができるフラッシュメモリ保持データのバックアップ通知システム、その方法およびプログラムを提供することを目的とする。

上記目的達成のため、請求項１に係る発明は、
ネットワークを介して相互に通信可能な端末装置とサーバ装置とを備えるフラッシュメモリ保持データのバックアップ通知システムであって、
前記端末装置は、
データを保持するフラッシュメモリを有する記憶手段と、
前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御手段と、
前記指令に基づいてリフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信手段と、
を有し、
前記サーバ装置は、
予め所定のフラッシュメモリ特性情報が設定された記録手段と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御手段と、
前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信手段と、
を有することを特徴とするフラッシュメモリ保持データのバックアップ通知システムである。

請求項７に係る発明は、
ネットワークを介して相互に通信可能な、フラッシュメモリを有する端末装置と、サーバ装置とによって実行されるフラッシュメモリ保持データのバックアップ通知方法であって、
前記端末装置のコンピュータが実行する処理として、
フラッシュメモリにデータを保持する記憶工程と、
前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御工程と、
リフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信工程と、
を含み、
前記サーバ装置のコンピュータが実行する処理として、
所定のフラッシュメモリ特性情報を予め設定する記録工程と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御工程と、
前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信工程と、
を含むことを特徴とするフラッシュメモリ保持データのバックアップ通知方法である。

請求項８に係る発明は、
前記端末装置のコンピュータに、
フラッシュメモリにデータを保持する記憶処理と、
前記フラッシュメモリのリフレッシュを実施する際に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御処理と、
前記指令に基づいて、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信処理と、
を実行させることを特徴とするプログラムである。

請求項９に係る発明は、
前記サーバ装置のコンピュータに、
所定のフラッシュメモリ特性情報を予め設定する記録処理と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御処理と、
前記指令に基づいて、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信処理と、
を実行させることを特徴とするプログラムである。

本発明によれば、端末機器に搭載されたフラッシュメモリについて、メーカが保証する消去回数よりも多く使用することができ、かつ、端末装置のユーザに対し、データバックアップが必要であることを確実に通知することができる。

本発明の実施形態に係るフラッシュメモリ保持データのバックアップ通知システムの全体構成図である。 端末装置の回路構成を示すブロック図である。 フラッシュメモリの記憶領域の構造を示す概略図である。 リフレッシュによる効果を示す概略図である。 端末装置からサーバ装置へ送信するフラッシュメモリ特性情報の一例を示す図である。 あるサンプルについての所定のブロック消去回数におけるリフレッシュ時のリード回数とエラービット数との関係を示す概略図である。 端末装置がフラッシュメモリからデータリードする時の動作を示すフローチャートである。 サーバ装置に記録されたサンプルのフラッシュメモリ特性情報を示す図である。 サーバ装置がフラッシュメモリの寿命となるブロック消去回数を予測する処理を示すフローチャートである。 あるサンプルのリード回数とエラービット数の傾きと領域分けを示す概略図である。 サーバ装置がネットワークを経由してデータバックアップが必要である旨の通知を直接端末装置へ送信する時の動作を示すフローチャートである。 複数サンプルのリード回数とエラービット数の傾きと領域分けを示す概略図である。 サーバ装置に記録されたフラッシュメモリ特性情報を示す図である。 サーバ装置がデータバックアップが必要である旨のメールを端末装置へ送信する時の動作を示すフローチャートである。 端末装置がサーバ装置から送信されたバックアップ要求文を表示画面上に表示する時の動作を示すフローチャートである。 付記１の構成図である。

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本実施形態に係るフラッシュメモリ保持データのバックアップ通知システムの全体構成図である。図１に示すように、本発明に係るフラッシュメモリ保持データのバックアップ通知システムは、基地局４，５，６を設けたネットワーク７を介して相互に通信可能な、端末装置１，２，３およびサーバ装置８から構成されている。

ここで、端末装置は、図１に示すもの以外にも複数のものが存在するが、説明の都合上、端末装置１，２，３を示している。そして、以下の説明では、端末装置１を代表例として説明していく。よって、その他の端末装置の構成および動作も同様である。
同様に、基地局も、図１に示すもの以外にも複数のものが存在するが、説明の都合上、基地局４，５，６を示している。以下の説明では、基地局４を代表例として説明していく。

ネットワーク７は、端末装置１とサーバ装置８が相互に通信可能な有線または無線の電気通信網をいう。なお、以下の説明では、ネットワーク７を公衆回線網として説明するが、飽くまで一例に過ぎず、端末装置１とサーバ装置８が相互に通信可能であれば公衆回線網でなくても良く、ローカルエリアネットワーク等であっても良い。

端末装置１は、無線通信が可能な携帯型または据置型の端末機器であり、例えば、フラッシュメモリを搭載した通信機能を持つデジタルカメラ、携帯情報端末、パーソナルコンピュータ、通信機等が該当するが、以下では、携帯電話に適用した例を説明する。

図１に示すように、端末装置１は、アンテナ部を有する基地局４を介してネットワーク７に通信可能に接続することにより、ネットワーク７に接続したサーバ装置８と通信することができる。

図２は、端末装置１の回路構成を示すブロック図である。
図２に示すように、端末装置１の電子回路はＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、フラッシュメモリ２０４、無線モジュール２０５、アンテナ２０６およびバス２０７等から構成されている。

ＣＰＵ２０１は中央処理演算装置であり、端末装置１の本来の動作に必要な各種制御処理を行う他、フラッシュメモリ特性情報に関する制御処理を行う。例えば、フラッシュメモリ２０４のリフレッシュを実施する場合に後述するフラッシュメモリ特性情報をサーバ装置８に送信するよう指令を出す処理を行う。ＲＡＭ２０２はランダムアクセスメモリであり、ＣＰＵ２０１がプログラムを実行する際に必要となるデータを保持したり、ワーキングメモリとして使用される。ＲＯＭ２０３はリードオンリメモリであり、ＲＯＭ２０３にはＣＰＵ２０１が実行する各種制御プログラムやデータが格納されている。

フラッシュメモリ２０４は不揮発性の半導体メモリ装置の一つであり、電源を切ってもデータは消去されない。また、データのリード、ライトが可能であり、データの消去も可能である等の点から、端末装置１のデータを保持するために使用される。なお、ＣＰＵ２０１が実行するプログラムやデータの全てがフラッシュメモリ２０４に格納されていても良い。この場合、前述のＲＯＭ２０３はなくても良い。

無線モジュール２０５は端末装置１がネットワーク７を介して送信するデータを変調し、またネットワーク７を介して受信したデータを復調する。アンテナ２０６は端末装置１とネットワーク７とが無線によりデータをやり取りするための送受信用アンテナであり、外部アンテナのほか内蔵アンテナであっても良い。バス２０７は、それに接続されたＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、フラッシュメモリ２０４、無線モジュール２０５同士がデータをやり取りするための汎用バスである。

ここで、端末装置１において、フラッシュメモリ２０４はデータを保持する記憶手段、またＣＰＵ２０１、ＲＡＭ２０２およびＲＯＭ２０３等はフラッシュメモリ２０４のリフレッシュを実施するか判定し、実施する場合には後述するフラッシュメモリ特性情報をサーバ装置８へ送信するよう指令を出す制御手段、さらに無線モジュール２０５およびアンテナ２０６は前記指令に基づいて後述するフラッシュメモリ特性情報をサーバ装置８へ送信したり、サーバ装置８からフラッシュメモリ２０４のデータバックアップが必要である旨の通知を受信する通信手段をそれぞれ構成している。

また、端末装置１の動作は、ＲＯＭ２０３等に格納されたプログラム等がＣＰＵ２０１に読み込まれ、上述した記憶手段、制御手段、通信手段が機能することによって実現されている。そのプログラムの処理フローについては後述する。

次に、サーバ装置８の実施形態を説明する。
図１に示すように、サーバ装置８はネットワーク７に通信可能に接続されており、端末装置１や他の端末装置との間で個別にデータの送受信をすることができる。
また、サーバ装置８は、いずれも図示していないが、ＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスクドライブ、ネットワークモジュール、ネットワークケーブル等を有する。

ＣＰＵは中央処理演算装置であり、サーバ装置８の本来の動作に必要な各種制御処理を行う他、端末装置１のフラッシュメモリ２０４の寿命予測や端末装置１へのフラッシュメモリ２０４のデータバックアップが必要である旨の通知に関する制御処理を行う。例えば、後述するが、予め記録された所定のフラッシュメモリ特性情報を基準として、端末装置１から送信されたフラッシュメモリ特性情報を比較することによりフラッシュメモリ２０４の寿命を予測し、寿命が近い場合には端末装置１へフラッシュメモリ２０４のデータバックアップが必要である旨の通知をするように指令を出す処理を行う。ＲＡＭはランダムアクセスメモリであり、ＣＰＵがプログラムを実行する際に必要となるデータを保持したり、ワーキングメモリとして使用される。ＲＯＭはリードオンリメモリであり、ＲＯＭにはＣＰＵが実行する各種制御プログラムやデータが格納されている。

ハードディスクドライブは情報の記録、読出が可能な大容量の記憶装置であり、後述する所定のフラッシュメモリ特性情報を記録する特性情報データベースを構築する。また、必要に応じて、端末装置１のメールアドレス等の端末情報を記録する端末情報データベース等を構築しても良い。さらに、上述の説明ではＣＰＵが読み取り可能なプログラムやデータは前述のＲＯＭに格納されているが、ハードディスクドライブに格納されていても良い。また、ハードディスクドライブは１台に限らず、複数のハードディスクドライブを使用しても良い。また、情報の記録、読出が可能なものであれば、ハードディスクドライブ以外のディスクドライブを併存させて使用しても良い。

ネットワークモジュールはネットワーク７を介して送信するデータを変調し、ネットワーク７を介して受信したデータを復調する。ネットワークケーブルはサーバ装置８とネットワーク７とがデータをやり取りするための通信ケーブルである。

ここで、サーバ装置８において、ハードディスクドライブ等は所定のフラッシュメモリ特性情報を記録する特性情報データベースや端末情報を記録する端末情報データベース等を有する記録手段、またＣＰＵ、ＲＡＭおよびＲＯＭ等は、後述のように、予め記録された所定のフラッシュメモリ特性情報を基準として、端末装置１から送信されたフラッシュメモリ特性情報を比較して、フラッシュメモリ２０４の使用限界を予測し、寿命が近いと判断した場合には端末装置１へフラッシュメモリ２０４のデータバックアップが必要である旨の通知をするように指令を出す制御手段、さらにネットワークモジュールおよびネットワークケーブルは前記指令に基づいて端末装置１へフラッシュメモリ２０４のデータバックアップが必要である旨の通知を送信したり、端末装置１から送信されたフラッシュメモリ特性情報を受信する通信手段をそれぞれ構成している。

サーバ装置８の動作は、ＲＯＭ等に格納されたプログラム等がＣＰＵに読み込まれ、上述した記録手段、制御手段および通信手段が機能することによって実現されている。そのプログラムの処理フローについては後述する。

図３は、フラッシュメモリ２０４の記憶領域の構造を示す概略図である。
図３に示すように、フラッシュメモリ２０４の記憶領域はブロックＢ１からブロックＢＮ（Ｎは整数）までのＮ個のブロックで管理される。フラッシュメモリ２０４のデータ消去はブロック単位で行われる。したがって、ブロックの一部だけを単位として消去されることはなく、ブロック全体を単位として消去されることになる。

１つのブロックは複数のページで構成されている。例えば、図３に示すように、１つのブロックはページＰ１からＰ１２８までの１２８個のページで管理される。フラッシュメモリ２０４へのデータライトはページ単位で行われる。すなわち、１ページ分のデータが一度にライトされる。また、フラッシュメモリ２０４が保持するデータのリードもページ単位で行われる。すなわち、一回のリードで１ページ分のデータがリードされる。

１つのページは複数のセクタで構成されている。例えば、図３に示すように、１つのページはセクタＳＣ０からＳＣ７までの８個のセクタで管理される。また、セクタの記憶領域はメインエリアとスペアエリアから構成される。メインエリアにはフラッシュメモリ２０４へライトしたデータが保持され、スペアエリアにはそのブロックが有効であるかを示す情報や、メインエリアのデータにＥＣＣ処理を行うための訂正用データを保持する。なお、ＥＣＣ処理は一般にセクタ単位で行われる。

ここで、以下の説明では、１セクタのデータ容量はメインエリア、スペアエリアでそれぞれ５１２バイト、１６バイトであるとして説明する。
この場合、１ページのデータ容量は、１ページが８セクタで構成されるため、メインエリア、スペアエリアでそれぞれ４０９６バイト（４Ｋバイト）、１２８バイトとなり、１ブロックのデータ容量は、１ブロックが１２８ページで構成されるため、メインエリア、スペアエリアでそれぞれ５１２Ｋバイト、１６Ｋバイトとなる。

図４は、フラッシュメモリ２０４のリフレッシュによる効果を示す概略図である。
図４では、あるブロックをセクタ単位で表しており、エラービットが存在するセクタを網掛け、存在しないセクタを白で示している。図４（Ａ）はリフレッシュ前のブロックの状態であり、ページＰ１，ページＰ２，ページＰ１２８には２つのセクタ、ページＰ３には４つのセクタでエラービットが発生している。このブロックに対しリフレッシュを行った後のエラービット存在状態を図４（Ｂ）に示す。図４（Ａ）に対し、図４（Ｂ）ではエラービットが存在しない。このようにリフレッシュを行うことで、ブロックにビットエラーがほとんど存在しない状態にすることができる。

図５は、端末装置１からサーバ装置８へ送信されるフラッシュメモリ特性情報の一例を示す図である。
図５に示すフラッシュメモリ特性情報は、端末装置１のフラッシュメモリ２０４のブロックＢ３２０をリフレッシュした時のものであり、ブロックＢ３２０の消去回数（ｃ）は３１２２回、このブロック内のページをリードした回数（ｄ）は４．１Ｍ回（Ｍ（メガ）は１０の６乗を意味する。以下、同じ。）であり、リフレッシュ時のブロックのエラービット数（ｅ）は３２０７ビットであったことを示している。

フラッシュメモリ特性情報は、サーバ装置８がフラッシュメモリ２０４の特性を判断するための情報であり、識別番号（ａ）、リフレッシュ時のブロック番号（ｂ）、リフレッシュ時のブロックの消去回数（ｃ）、ブロックのリード回数（ｄ）およびブロックのエラービット数（ｅ）を総称したものである。

ここで、識別番号（ａ）は端末装置１を識別するために割り当てられた番号、ブロック番号（ｂ）はフラッシュメモリ２０４の記憶領域をブロック単位で識別するための番号である。リフレッシュ時のブロックの消去回数（ｃ）はリフレッシュを行うまでに１つのブロックでデータを消去した回数（ｃ）であり、これは各ブロック内に記録されている。リフレッシュ時のブロックのリード回数（ｄ）はリフレッシュを行うまでに１つのブロックでデータをリードした回数であり、これはリフレッシュを行うまでのページＰ１からページＰ１２８までの各ページに記録されているリード回数の総和に相当する。例えば、リフレッシュ直前にページＰ１を０回、ページＰ２を３回、ページＰ３を０回、ページＰ１２８を５回リードしていた場合、ブロックのリード回数（ｄ）は８回となる。リフレッシュ時のブロックのエラービット数（ｅ）はリフレッシュを行う際のデータリード時に１つのブロックで発生したエラービット数をであり、これはリフレッシュ時、ページＰ１からページＰ１２８までの各ページに記録されているエラービット数の総和に相当する。例えば、ページＰ１で４ビット、ページＰ２で０ビット、ページＰ３で２ビット、ページＰ１２８で１ビットのエラーが発生していた場合、ブロックのエラービット数（ｅ）は７ビットとなる。

図６は、フラッシュメモリ２０４のサンプルについて、所定のブロック消去回数（ｄ）におけるリフレッシュ時のリード回数（ｄ）とエラービット数（ｅ）との関係を示す概略図である。
図６では、あるサンプルのフラッシュメモリ特性情報に基づいて、ブロック消去回数（ｃ）が２ｋ回、３ｋ回、４ｋ回の場合のリード回数（ｄ）とエラービット数（ｅ）をグラフに示している。ブロック消去回数が２ｋ回、３ｋ回、４ｋ回と増加するに従い、リード回数（ｄ）あたりのエラービット数（ｅ）が多くなることが分かる。これは、一般にリフレッシュを行うことでリードディスターブ現象により発生するデータエラー対策はできるが、消去回数（ｃ）が増加するとリードディスターブ特性が悪化するため、リフレッシュ回数が増えるとセクタで最初にエラービット数（ｅ）が訂正閾値に達するリード回数（ｄ）は減少していくということ、すなわち訂正閾値に達するビットエラーの発生が早くなるということに起因している。

次に、本実施形態の動作について説明する。
図７は、端末装置１がフラッシュメモリ２０４からデータリードする時の動作を示すフローチャートである。

図７に示すデータリード処理は、端末装置１のユーザが端末装置１の入力手段からデータの読込みを指示した場合やその他端末装置１の起動時や使用時等にＣＰＵ２０１がデータの読込をした場合に開始される。
まず、図７に示すステップＳ１で、ＣＰＵ２０１はあるブロックのリード対象のデータをフラッシュメモリ２０４からリードする。

ステップＳ２で、ＣＰＵ２０１はリードしたデータのＥＣＣ処理を行う。この処理が行われることにより、セクタ単位でデータのエラーが訂正され、同時に各セクタ内のエラービット数が判明する。
ここで、ＥＣＣ処理は、訂正できるエラービット数が訂正方式とスペアエリアに訂正用データとして保持されている
冗長ビット長によって決まる。すなわち、ＥＣＣ処理を行って訂正できるエラービット数には上限（以下、「訂正閾値」という。）がある。以下の説明では、ＥＣＣ処理を行って１セクタあたり４ビットまでのビットエラーを訂正でき、訂正閾値が４ビットであるとして説明する。

ステップＳ３で、ＣＰＵ２０１はリフレッシュを行うかの判断を行う。
ここで、リフレッシュはＥＣＣ処理を行ってビットエラー訂正をすることができるうちに実施する必要がある。リフレッシュではリードしたデータを再ライトする処理を行うため、正しいデータをリードすることができるうちに実施すべきだからである。したがって、ページリード時にページを構成する８セクタのうち１セクタでも４ビットのエラービットが発生した場合にリフレッシュする。

ステップＳ３では、データリード時にページを構成するセクタごとに、ステップＳ２で判明したエラービット数（ｅ）を訂正閾値（４ビット）と比較し、エラービット数（ｅ）が訂正閾値に達しているか判断する。エラービット数（ｅ）が訂正閾値に達している場合はステップＳ１１へ分岐し、リフレッシュの処理を開始する。エラービット数（ｅ）が訂正閾値よりも小さい場合はステップＳ４へ進み、ＣＰＵ２０１はＲＡＭ２０２に格納してあるそのブロックのリード回数（ｄ）をリードし、そのリード回数（ｄ）の値をインクリメントし、再びそれをＲＡＭ２０２に格納して、データリード処理は終了する。

ステップＳ１１では、ＣＰＵ２０１はリフレッシュ対象ブロックの全データをリードしＲＡＭ２０２へ転送する。次いで、ステップＳ１２で、ＣＰＵ２０１はステップＳ１１でデータリードした時に判明したブロックのエラービット数（ｅ）をＲＡＭ２０２へ転送する。次いで、ステップＳ１３で、リフレッシュ対象ブロックの消去回数（ｃ）をＲＡＭ２０２からリードする。

ステップＳ１４で、端末装置１はフラッシュメモリの特性情報として、識別番号（ａ）ならびにリフレッシュ時のブロック番号（ｂ）、ブロックの消去回数（ｃ）、ブロックのリード回数（ｄ）およびブロックのエラービット数（ｅ）をサーバ装置８へ送信する。
ＣＰＵ２０１は、端末装置１の識別番号（ａ）、ステップＳ１１でリフレッシュを行ったブロック番号（ｂ）、ステップＳ１３でＲＡＭ２０２からリードした消去回数（ｃ）、ＲＡＭ２０２に格納している対象ブロックのリード回数（ｄ）、ステップＳ１０のＥＣＣ処理の時に判明したエラービット数（ｅ）およびリフレッシュを行った旨をバス２０７を介して無線モジュール２０５へ送る。無線モジュール２０５ではデータを変調し、アンテナ２０６を経由して送出、基地局４で受信してネットワーク７を経由しサーバ装置８に到達する。

ステップＳ１５で、ＣＰＵ２０１はリフレッシュを行うブロックが寿命に達したかを判定する。一般にリフレッシュを行うことでリードディスターブ現象により発生するデータエラー対策はできるが、消去回数が増加するとリードディスターブ特性が悪化するため、リフレッシュ回数が増えるとセクタで最初にエラービット数（ｅ）が訂正閾値に達するリード回数は減少していく。すなわち訂正閾値に達するビットエラーの発生が早くなる。よって、このリード回数が一定回数以下になった時にそのブロックが寿命となったと判断し、そのブロックの内容は別のブロックへ転送して寿命に達したブロックは使用禁止として以後使用しないことにする。

ステップＳ１５で、ＲＡＭ２０２に格納している対象ブロックのリード回数（ｄ）をリードし、その値が一定回数以上（例えば１Ｍ回）の場合には寿命に達していないと判断してステップＳ１６へ進む。一定回数よりも小さい場合には寿命に達したと判断してステップＳ２０へ分岐する。

ステップＳ１５でブロックが寿命に達していないと判断した場合には、ステップＳ１６で、ＣＰＵ２０１はステップＳ１３でリードした消去回数（ｃ）を１増加し、再びＲＡＭ２０２へ格納する。次いで、ステップＳ１７で、ＣＰＵ２０１はリフレッシュ対象ブロックの内容を消去する。次いで、ステップＳ１８で、ＣＰＵ２０１はステップＳ１１でＲＡＭ２０２へリードした対象ブロックのデータをリフレッシュ対象ブロックへライトする。また、この時、ステップＳ１５でＲＡＭ２０２へ書き込んだ消去回数（ｃ）もそのリフレッシュ対象ブロックにライトする。次いで、ステップＳ１９で、ＣＰＵ２０１はＲＡＭ２０２に格納している、リフレッシュ対象ブロックのリード回数（ｄ）をクリアする。

ステップＳ１５でブロックが寿命に達したと判断した場合には、ステップＳ２０で、リフレッシュ対象ブロックのスペアエリアに無効ブロックの情報をライトし、そのブロックを以後使用しないようにする。次いで、ステップＳ２１で、ステップＳ１１でリードしたブロックのデータを別の空いているブロックへライトする。このように寿命となったブロックのデータを別のブロックへ移すことでデータを問題なく保持できる。次いで、ステップＳ１９で、ＣＰＵ２０１はＲＡＭ２０２に格納している対象ブロックのリード回数（ｄ）をクリアする。

なお、上記ステップＳ２では、ＥＣＣ処理はソフトウェアで実施しているが、フラッシュメモリ２０４にＥＣＣ機能が内蔵されている場合にはハードウェアで実施しても良い。この場合、ステップＳ２ではＥＣＣ処理の代わりにフラッシュメモリ２０４から各セクタのエラービット数（ｅ）をリードする処理を行う必要がある。

上述の処理によれば、端末装置１は、フラッシュメモリ２０４からデータリードした時にＥＣＣ処理を行うことにより取得可能なエラービット数（ｅ）に基づき、フラッシュメモリ２０４のリフレッシュを行うか判断し、リフレッシュを行う場合には、リフレッシュ時のフラッシュメモリ特性情報をサーバ装置８へ送信し、その後リフレッシュを行う。リフレッシュが行われることで、リフレッシュの対象ブロックにはビットエラーがほとんど存在しない状態にすることができる。

次に、サーバ装置８におけるフラッシュメモリ特性情報の記録について説明する。
サーバ装置８のハードディスクドライブ等に構築された特性情報データベースには、端末装置１のフラッシュメモリ２０４と同じ型式の複数のサンプルのフラッシュメモリ特性情報を予め記録しておく必要がある。
各サンプルの任意のブロックで一定回数消去した後にリードし続け、リード時のセクタ内のエラービット数（ｅ）が最初に訂正閾値に達した時に、識別番号（ａ）、ブロック番号（ｂ）、ブロック消去回数（ｃ）、ブロックリード回数（ｄ）、ブロックエラービット数（ｅ）をフラッシュメモリ特性情報として特性情報データベースに記録していく。

その際にブロックの消去やライトに失敗しブロックが不良となった場合には、不良となったブロックのフラッシュメモリ特性情報は使わず、その代わりに別のブロックのフラッシュメモリ特性情報を記録していく。このように各サンプルのフラッシュメモリ特性情報を記録する時に不良ブロックのフラッシュメモリ特性情報は使用しないため、正確なフラッシュメモリ特性情報を得ることができる。

エラービット数（ｅ）が訂正閾値（４ビット）に達した時のリード回数（ｄ）が一定回数以上に達していなかった時は寿命に達したとしてそのブロックのフラッシュメモリ特性情報の記録を終了する。

なお、上述の説明では、フラッシュメモリ特性情報を特性情報データベースに記録するにあたり、ブロック消去回数（ｃ）を１つ増加した後リードし続け、訂正閾値に達した時のブロックリード回数（ｄ）、ブロックエラービット数（ｅ）を記録しているが、これに代えて予め決めておいた所定のブロック消去回数（ｃ）に達した時のブロックリード回数（ｄ）、ブロックエラービット数（ｅ）を記録しても良い。時間がかかる上、フラッシュメモリ２０４の特性も大きく変化しないからである。
以下では、フラッシュメモリ特性情報として、予め決めておいた所定のブロック消去回数（ｃ）に達した時のブロックリード回数（ｄ）、ブロックエラービット数（ｅ）を記録することとして説明する。その際には、ブロック消去回数（ｃ）が２０００回から５００回刻みでブロックリード回数（ｄ）、ブロックエラービット数（ｅ）を記録し、ブロックリード回数（ｄ）が１Ｍ回に達する前にセクタ内に４ビットエラーが発生した場合は寿命に達したとしてその直前に記録したブロック消去回数（ｃ）までのフラッシュメモリ特性情報を使用することとする。

次に、図８を参照して、サーバ装置８に記録された複数のサンプルのフラッシュメモリ特性情報から一番悪い特性を選別する仕方を説明する。ここで、図８は、サーバ装置８に記録されたフラッシュメモリ特性情報を示す図である。図８では、各サンプルともブロックＢ１００、ブロックＢ２００、ブロックＢ３００の３つのブロックのフラッシュメモリ特性情報が記録されている。
なお、サンプル２ではフラッシュメモリ特性情報の記録時にブロックＢ２００で不良ブロックが発生したためこのブロックの特性は無効ブロックのデータとして使用せず、代わりにブロックＢ４００のフラッシュメモリ特性情報を記録し、それら３つのブロックのフラッシュメモリ特性情報を記録した。なお、サンプルごとに寿命に達した時のブロック消去回数（ｃ）が異なるのはフラッシュメモリの特性にばらつきがあるためである。

まず各サンプルの中でブロック消去回数（ｃ）に着目し、同一サンプルの中で寿命に達した時の消去回数（ｃ）が一番少ないブロックを選ぶ。消去回数（ｃ）が同じ値であるためどちらの特性が悪いか分からない場合はブロックのリード回数（ｄ）に着目し、同一サンプルの中で寿命に達した時のリード回数（ｄ）が一番少ないブロックを選ぶ。なおブロック消去回数（ｃ）、ブロックのリード回数（ｄ）ともに同じ値だった場合にはブロックのエラービット数（ｅ）に着目し、同一サンプルの中で寿命に達した時のエラービット数（ｅ）の多いブロックの方を選ぶ。

図８に示すサンプルＳＰ１では、ブロックＢ１００、ブロックＢ２００およびブロックＢ３００の消去回数（ｃ）はそれぞれ６０００回、５５００回および５５００回である。この中で消去回数（ｃ）が一番少ないブロックに着目すると、ブロックＢ２００とブロックＢ３００の消去回数（ｃ）が同じ値であるためどちらの特性が悪いか分からない。そこで、ブロックのリード回数（ｄ）に着目すると、ブロックＢ２００は１．２Ｍ回、ブロックＢ３００は１．１Ｍ回である。よって、リード回数（ｄ）はブロックＢ３００の方が少ないため、ブロックＢ３００がサンプルＳＰ１で取得したブロックの中で一番特性の悪いブロックである。

図８に示すサンプルＳＰ２では、ブロックＢ１００、ブロックＢ３００およびブロックＢ４００の消去回数（ｃ）は、それぞれ４５００回、４５００回および４０００回である。よって、消去回数（ｃ）の一番少ないブロックＢ４００がサンプルＳＰ２の中で一番特性の悪いブロックである。

図８に示すサンプルＳＰＮでは、ブロック消去回数（ｃ）が一番少ないブロックに着目すると、ブロックＢ２００とブロックＢ３００が同じ値であるので、どちらの特性が悪いか分からない。そこで、ブロックのリード回数（ｄ）に着目すると、これも同じ値であるので、ブロックのエラービット数（ｅ）に着目すると、エラービット数（ｅ）が多いのはブロックＢ２００である。よって、ブロックＢ２００がサンプルＳＰＮの中で一番特性の悪いブロックである。

以上より、各サンプルで一番特性の悪いブロック同士を比べると、サンプルＳＰ１はブロックＢ３００、サンプルＳＰ２はブロックＢ４００、サンプルＳＰＮはブロックＢ２００であるから、一番特性が悪いのはブロック消去回数（ｃ）の値から、サンプルＳＰ２となる。

図９は、サーバ装置８がフラッシュメモリ２０４の寿命となるブロック消去回数（ｃ）を予測する処理を示すフローチャートである。なお、図１０は、あるサンプルのリード回数（ｄ）とエラービット数（ｅ）の傾きと領域分けを示す概略図である。

まず、図９に示すステップＳ３１で、サーバ装置８は端末装置１から送信されてきたリフレッシュ時の所定のフラッシュメモリ特性情報のうち、ブロックの消去回数（ｃ）を取得する。次いで、ステップＳ３２で、サンプルのうち一番特性の悪かったブロック（サンプルＳＰ２のブロックＢ４００）の消去回数（ｃ）のうち、端末装置１のブロックの消去回数（ｃ）に最も近い値をとる時のリード回数（ｄ）とエラービット数（ｅ）を特性情報データベースからリードする。

ステップＳ３３で図１０に示すように、原点と、Ｓ３２でリードしたブロックリード回数（ｄ）とブロックエラービット数（ｅ）が示す点の２点を通る領域境界線ＢＬ１を基準とし、ブロックリード回数（ｄ）とブロックエラービット数（ｅ）からなるグラフ上の領域を以下の２つの領域に分ける。
（Ｘ）領域Ｄ１：縦軸と領域境界線ＢＬ１の間の領域
（Ｙ）領域Ｄ２：領域境界線ＢＬ１と横軸の間の領域

ステップＳ３４で端末装置１から送信されたフラッシュメモリ特性情報のうちブロックリード回数（ｄ）とブロックエラービット数（ｅ）を図１０に示すグラフ上にプロットする。これは上記領域Ｄ１または領域Ｄ２のどちらかに属するので、どちらに属するかを判断することにより、端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を予測する。

ステップＳ３５で端末装置１のフラッシュメモリ特性情報が、図１０に示すグラフ上で２つの領域のうちどちらに属するか判断する。
ここで、その属す領域により、以下のように、端末装置１のフラッシュメモリ２０４の特性がサンプルの特性より良いか悪いか定義する。
（１−１）領域Ｄ１に属す場合：フラッシュメモリの特性がサンプルの特性より悪い
（１−２）領域Ｄ２に属す場合：フラッシュメモリの特性がサンプルの特性より良い

端末装置１のフラッシュメモリ特性情報が領域Ｄ１に属す場合、例えば、図１０の「×１」印に位置した場合は、ステップＳ３５でＹｅｓ（Ｙ）と判別され、ステップＳ３６で端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を「メーカ保障消去回数」と予測する。

他方、端末装置１のフラッシュメモリ特性情報が領域Ｄ２に属す場合、例えば、図１０の「×２」印に位置した場合は、ステップＳ３５でＮｏ（Ｎ）と判別され、ステップＳ３７で端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を「サンプルＳＰ２が寿命に達した時の消去回数」と予測する。

ステップＳ３８で、サーバ装置８は前述の予測された消去回数を基準として、端末装置１から送信されたブロック消去回数（ｃ）を比較し、残りの消去回数が一定回数よりも少ない場合には端末装置１のフラッシュメモリ２０４の寿命が近いと判断し、以下で説明するようにネットワーク７を経由してフラッシュメモリ２０４の消去回数（ｃ）が残り少ないためデータバックアップが必要である旨の通知を直接端末装置１へ送信する。
また、残りの消去回数が一定回数以上ある場合には端末装置１へ送信しないで処理を終了する。

ここで、図１１を参照して、サーバ装置８がネットワーク７を経由してデータバックアップが必要である旨の通知を直接端末装置１へ送信する時の動作を説明する。なお、図１１は、サーバ装置８がネットワーク７を経由してデータバックアップが必要である旨の通知を直接端末装置１へ送信する時の動作を示すフローチャートである。
図１１に示すステップＳ４１で、サーバ装置８は端末装置１から送信されたフラッシュメモリ特性情報のうち識別番号（ａ）から端末装置１を識別する。次いで、ステップＳ４２で、サーバ装置８はユーザに対してフラッシュメモリ２０４の消去回数（ｃ）が残り少ないためデータバックアップが必要である旨のバックアップ要求文を作成する。次いで、ステップＳ４３で、サーバ装置８はステップＳ４２で作成されたバックアップ要求文をネットワーク７を経由して端末装置１へ送信する。

上述した処理によれば、サーバ装置８は予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルのフラッシュメモリ特性情報を基準として、端末装置１から送信されたフラッシュメモリ特性情報を比較し、その結果に基づいてフラッシュメモリ２０４の寿命となる消去回数（ｃ）を予測し、フラッシュメモリ２０４の寿命が近いと判断した場合には、バックアップ要求文を作成し、それを端末装置１へ送信するので、フラッシュメモリ２０４が寿命に達することを確実に端末装置１へ送信することができる。

また、上述した処理では、サーバ装置８は、予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルを用いてフラッシュメモリ２０４の寿命となる消去回数（ｃ）を予測したが、これに代えて複数のサンプルのフラッシュメモリ特性情報を基準として寿命となる消去回数（ｃ）を予測することも可能である。例えば、図１２に示すように、２つのサンプルの場合はブロックリード回数（ｄ）とブロックエラービット数（ｅ）からなるグラフ上の領域を領域境界線ＢＬ１と領域境界線ＢＬ２に基づいて３つの領域に分け、以下のように予測を行うことも可能である。
（２−１）領域Ｄ１に属す場合：フラッシュメモリの特性がサンプルＳＰ２よりも悪い
（２−２）領域Ｄ２に属す場合：特性が悪いサンプルＳＰ２よりは特性は良いがサンプルＳＰ１よりは特性が悪い
（２−３）領域Ｄ３に属す場合：フラッシュメモリの特性がサンプルＳＰ１よりも良い

端末装置１のフラッシュメモリ特性情報が領域Ｄ１に属す場合、例えば、図１２の「×３」印に位置した場合は、端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を「メーカ保障消去回数」と予測する。これは予め調べてある２つのサンプルの特性よりも端末装置１のフラッシュメモリ２０４の方が特性が悪いためである。

領域Ｄ２に属す場合、例えば、図１２の「×４」印に位置した場合は、端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を「サンプルＳＰ２が寿命に達した時の消去回数」と予測する。

領域Ｄ３に属す場合、例えば、図１２の「×５」印に位置した場合は、端末装置１のフラッシュメモリ２０４が寿命に達する消去回数（ｃ）を「サンプルＳＰ１が寿命に達した時の消去回数」と予測する。

また、上述した処理では、２個のサンプルで説明しているが、これを拡張し、Ｎ個（Ｎは整数）のサンプルがあった場合には領域Ｄ１から領域Ｄ（Ｎ＋１）に分割し、端末装置１から送信されたフラッシュメモリ特性情報がどの領域に属すかでフラッシュメモリ２０４の寿命となる消去回数（ｃ）を予測することも可能である。

また、上述した処理では、サーバ装置８は、端末装置１のフラッシュメモリ２０４と同型のサンプルのフラッシュメモリ特性情報を用いていたが、これに代えて端末装置１がフラッシュメモリ２０４のリフレッシュ時に送信するフラッシュメモリ特性情報を、図１３に示すように、サーバ装置８へ記録していき、これを用いて他の端末装置のフラッシュメモリ２０４が寿命となる消去回数（ｃ）を予測しても良い。

また、上述した処理では、サーバ装置８はネットワーク７を経由してバックアップ要求文を直接端末装置１へ送信しているが、これに代えて、以下で説明するように電子メールでデータバックアップが必要である旨のバックアップ要求メールを端末装置１へ送信しても良い。

ここで、図１４を参照して、サーバ装置８が電子メールでバックアップ要求メールを端末装置１へ送信する時の動作を説明する。なお、図１４は、サーバ装置８がバックアップ要求メールを端末装置１へ送信する時の動作を示すフローチャートである。
まず、図１４に示すステップＳ５１で、サーバ装置８は端末装置１から送信されたフラッシュメモリ特性情報のうち識別番号（ａ）から端末装置１を識別する。次いで、ステップＳ５２で、サーバ装置８のデータベースから電子メールアドレスを取得する。次いで、ステップＳ５３で、サーバ装置８はステップＳ５２で取得した端末装置１の電子メールアドレスへデータバックアップを促す電子メールを送信する。

一方、端末装置１は、ネットワーク７を経由してサーバ装置８から送信されたバックアップ要求文を受信し、以下で説明するようにそのバックアップ要求文を表示画面上に表示してユーザにデータバックアップを促す報知をする。

ここで、図１５を参照して、端末装置１がサーバ装置８から送信されたバックアップ要求文を表示画面上に表示する時の動作を説明する。なお、図１５は、端末装置１がサーバ装置８から送信されたバックアップ要求文を表示画面上に表示する時の動作を示すフローチャートである。
まず、図１５に示すステップ６１で、端末装置１の表示画面上にサーバ装置８から送信されたバックアップ要求文を表示し、ユーザに対してバックアップを促す。次いで、ステップＳ６２で、ユーザがデータバックアップを完了しているか否かを判断する。バックアップを完了している場合には、表示画面上への出力を終了する。バックアップをしていない場合には、ステップＳ６３に進み、一定時間経過したか否かを判断する。一定時間経過していない場合にはステップＳ６２に戻り、ユーザがデータバックアップをしているか否かを判断する。一定時間経過した場合にはステップＳ６１に戻り、端末装置１の表示画面上にバックアップ要求文を再表示する。

上述した処理によれば、端末装置１はサーバ装置８から送信されたバックアップ要求文をユーザがデータバックアップを完了するまで表示画面上に表示するので、端末装置１のユーザにフラッシュメモリ２０４が寿命に達することを確実に報知することができる。

なお、上述した処理では、端末装置１は、サーバ装置８から送信されたバックアップ要求文を表示画面上に表示する処理を行っているが、これに代えて電子メールの到着を知らせ、ユーザのメール選択時にバックアップ要求メール本文を表示する処理、端末装置１上のランプを点灯させバックアップ要求を知らせる処理、または端末装置１のスピーカからバックアップ要求を知らせる音（音声、ブザー音等）を出す処理を行うようにしても良い。

上述した実施形態によれば、端末装置１は、フラッシュメモリ２０４からデータリードした時にＥＣＣ処理を行うことにより取得可能なエラービット数（ｅ）に基づき、フラッシュメモリ２０４のリフレッシュを行うか判断し、リフレッシュが行われる場合には、リフレッシュの対象ブロックにはビットエラーがほとんど存在しない状態にすることができる。

また、本実施形態によれば、サーバ装置８は、サンプルのフラッシュメモリ特性情報をハードディスクドライブ等に構築された特性情報データベースに記録する際に、不良ブロックのフラッシュメモリ特性情報は使用しないため、正確なフラッシュメモリ特性情報を使用することができる。

また、本実施形態によれば、サーバ装置８は、予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルのフラッシュメモリ特性情報を基準として、端末装置１から送信された所定のフラッシュメモリ特性情報を比較する際に、一番特性の悪いサンプルのフラッシュメモリ特性情報に係る消去回数（ｃ）のうち、端末装置１から送信されたフラッシュメモリ特性情報に係る消去回数（ｃ）と最も近い値をとる消去回数（ｃ）のときのリード回数（ｄ）およびエラービット数（ｅ）に基づいてフラッシュメモリの使用限界を予測することで、正確な消去回数（ｃ）を得ることができるため、メーカが保証するよりも長く使用できる。

また、本実施形態によれば、サーバ装置８は、予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルのフラッシュメモリ特性情報を基準として、端末装置１から送信された所定のフラッシュメモリ特性情報を比較する際に、一番特性の悪いサンプルのフラッシュメモリ特性情報に係る消去回数（ｃ）のうち、端末装置１から送信されたフラッシュメモリ特性情報に係る消去回数（ｃ）と最も近い値をとる消去回数（ｃ）のときのリード回数（ｄ）およびエラービット数（ｅ）に基づいてフラッシュメモリ特性情報を分析しているため、正確にフラッシュメモリが使用限界に達しているか検出することができる。

また、本実施形態によれば、サーバ装置８は、予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルのフラッシュメモリ特性情報を基準として、端末装置１から送信された所定のフラッシュメモリ特性情報を比較するので、サンプル数が少ない場合でも消去回数（ｃ）を予測することができる。

また、本実施形態によれば、サーバ装置８は、予め記録したサンプルのフラッシュメモリ特性情報のうち一番特性の悪いサンプルのフラッシュメモリ特性情報を基準として、端末装置１から送信された所定のフラッシュメモリ特性情報を比較し、その結果に基づいてフラッシュメモリ２０４の寿命となる消去回数（ｃ）を予測し、フラッシュメモリ２０４の寿命が近いと判断した場合には、データバックアップを促す通知を端末装置１へ送信するので、フラッシュメモリ２０４が寿命に達することを確実に端末装置１へ送信することができる。

また、本実施形態によれば、端末装置１はサーバ装置８から送信されたデータバックアップを促す通知をユーザがデータバックアップを完了するまで一定時間経過ごとに繰り返し行うので、端末装置１のユーザにフラッシュメモリ２０４が寿命に達することを確実に報知することができる。

なお、本発明の実施形態では、端末装置の記憶手段としてフラッシュメモリを使用しているが、本発明は、例えば、ＦｌａｓｈＳＳＤ（フラッシュ型ソリッドステートドライブ）等、その他のデータ保持可能な記憶素子にも適用できる。
また、本実施形態は、端末装置として携帯電話に適用した例であるが、本発明はこれに限定されるものではない。フラッシュメモリを搭載した無線通信可能な携帯型または据置型の端末機器、例えば、通信機能を持つデジタルカメラ、携帯情報端末、パーソナルコンピュータ、通信機、その他の電子機器等にも幅広く適用できる。

以上、本発明の実施の形態について説明したが、本発明は、これらに限定されるものではなく、特許請求の範囲に記載された発明とその均等の範囲を含むものである。
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）
図１６は、付記１の構成図である。この図に示すように、付記１記載の発明は、
ネットワークを介して相互に通信可能な端末装置１とサーバ装置８とを備えるフラッシュメモリ保持データのバックアップ通知システムであって、
前記端末装置１は、
データを保持するフラッシュメモリを有する記憶手段２０４と、
前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置８へ送信するよう指令を出す制御手段２０１、２０３と、
前記指令に基づいてリフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置８へ送信するとともに、前記サーバ装置８から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信手段２０５、２０６と、
を有し、
前記サーバ装置８は、
予め所定のフラッシュメモリ特性情報が設定された記録手段３０１と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置１から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置１のフラッシュメモリの使用限界を予測し、前記端末装置１のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置１へ送信するように指令を出す制御手段３０２と、
前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置１へ送信するとともに、前記端末装置１から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信手段３０３と、
を有することを特徴とするフラッシュメモリ保持データのバックアップ通知システムである。

（付記２）
前記リフレッシュ時の所定のフラッシュメモリ特性情報は、
少なくとも、前記フラッシュメモリがリフレッシュを実施する時のリフレッシュ対象ブロックの消去回数、リード回数およびエラービット数を含むことを特徴とする付記１に記載のフラッシュメモリ保持データのバックアップ通知システムである。

（付記３）
前記サーバ装置の制御手段は、
予め設定された前記端末装置のフラッシュメモリと同型である複数サンプルの所定のフラッシュメモリ特性情報のうち最も特性が悪いものを基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較し、
前記端末装置の所定のフラッシュメモリ特性情報の方が最も特性が悪いサンプルの所定のフラッシュメモリ特性情報よりも良い場合には、そのサンプルの消去回数を用いて前記フラッシュメモリの使用限界を予測し、悪い場合には、メーカの保証する消去回数を用いて前記フラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記のフラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出すことを特徴とする付記１または付記２のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システムである。

（付記４）
前記サーバ装置の制御手段において、
予め設定された前記端末装置のフラッシュメモリと同型である複数サンプルの所定のフラッシュメモリ特性情報のうち最も特性が悪いものを基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較するとは、
サンプルのフラッシュメモリ特性情報に係る消去回数のうち、前記端末装置から送信されたリフレッシュ時のフラッシュメモリ特性情報に係る消去回数に最も近い値をとる消去回数のときのリード回数およびエラービット数を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較することであることを特徴とする付記１ないし付記３のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システムである。

（付記５）
前記フラッシュメモリの寿命が近い旨の通知は、
前記フラッシュメモリの残りの消去回数が少ないためデータバックアップが必要である旨の通知であることを特徴とする付記１ないし付記４のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システムである。

（付記６）
前記端末装置は、更に、
前記サーバ装置から前記端末装置へ送信される前記フラッシュメモリの寿命が近い旨の通知を受信した時に、前記端末装置のユーザにその着信を知らせる報知手段を有することを特徴とする付記１ないし付記５のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システムである。

（付記７）
ネットワークを介して相互に通信可能な、フラッシュメモリを有する端末装置と、サーバ装置とによって実行されるフラッシュメモリ保持データのバックアップ通知方法であって、
前記端末装置のコンピュータが実行する処理として、
フラッシュメモリにデータを保持する記憶工程と、
前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御工程と、
リフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信したり、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信工程と、
を含み、
前記サーバ装置のコンピュータが実行する処理として、
所定のフラッシュメモリ特性情報を予め設定する記録工程と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御工程と、
前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信工程と、
を含むことを特徴とするフラッシュメモリ保持データのバックアップ通知方法である。

（付記８）
前記端末装置のコンピュータに、
フラッシュメモリにデータを保持する記憶処理と、
前記フラッシュメモリのリフレッシュを実施する際に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御処理と、
前記指令に基づいて、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信処理と、
を実行させることを特徴とするプログラムである。

（付記９）
前記サーバ装置のコンピュータに、
所定のフラッシュメモリ特性情報を予め設定する記録処理と、
予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御処理と、
前記指令に基づいて、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信処理と、
を実行させることを特徴とするプログラムである。

１、２、３ 端末装置（記憶手段、制御手段、通信手段、報知手段）
４、５、６ 基地局
７ ネットワーク
８ サーバ装置（記録手段、制御手段、通信手段）
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ フラッシュメモリ
２０５ 無線モジュール
２０６ アンテナ
２０７ バス

Claims (9)

1. ネットワークを介して相互に通信可能な端末装置とサーバ装置とを備えるフラッシュメモリ保持データのバックアップ通知システムであって、
   前記端末装置は、
   データを保持するフラッシュメモリを有する記憶手段と、
   前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御手段と、
   前記指令に基づいてリフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信手段と、
   を有し、
   前記サーバ装置は、
   予め所定のフラッシュメモリ特性情報が設定された記録手段と、
   予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御手段と、
   前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信手段と、
   を有することを特徴とするフラッシュメモリ保持データのバックアップ通知システム。
2. 前記リフレッシュ時の所定のフラッシュメモリ特性情報は、
   少なくとも、前記フラッシュメモリがリフレッシュを実施する時のリフレッシュ対象ブロックの消去回数、リード回数およびエラービット数を含むことを特徴とする請求項１に記載のフラッシュメモリ保持データのバックアップ通知システム。
3. 前記サーバ装置の制御手段は、
   予め設定された前記端末装置のフラッシュメモリと同型である複数サンプルの所定のフラッシュメモリ特性情報のうち最も特性が悪いものを基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較し、
   前記端末装置の所定のフラッシュメモリ特性情報の方が最も特性が悪いサンプルの所定のフラッシュメモリ特性情報よりも良い場合には、そのサンプルの消去回数を用いて前記フラッシュメモリの使用限界を予測し、悪い場合には、メーカの保証する消去回数を用いて前記フラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出すことを特徴とする請求項１または請求項２のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システム。
4. 前記サーバ装置の制御手段において、
   予め設定された前記端末装置のフラッシュメモリと同型である複数サンプルの所定のフラッシュメモリ特性情報のうち最も特性が悪いものを基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較するとは、
   サンプルのフラッシュメモリ特性情報に係る消去回数のうち、前記端末装置から送信されたリフレッシュ時のフラッシュメモリ特性情報に係る消去回数に最も近い値をとる消去回数のときのリード回数およびエラービット数を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較することであることを特徴とする請求項１ないし請求項３のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システム。
5. 前記フラッシュメモリの寿命が近い旨の通知は、
   前記フラッシュメモリの残りの消去回数が少ないためデータバックアップが必要である旨の通知であることを特徴とする請求項１ないし請求項４のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システム。
6. 前記端末装置は、更に、
   前記サーバ装置から前記端末装置へ送信される前記フラッシュメモリの寿命が近い旨の通知を受信した時に、前記端末装置のユーザにその着信を知らせる報知手段を有することを特徴とする請求項１ないし請求項５のいずれかに記載のフラッシュメモリ保持データのバックアップ通知システム。
7. ネットワークを介して相互に通信可能な、フラッシュメモリを有する端末装置と、サーバ装置とによって実行されるフラッシュメモリ保持データのバックアップ通知方法であって、
   前記端末装置のコンピュータが実行する処理として、
   フラッシュメモリにデータを保持する記憶工程と、
   前記フラッシュメモリのリフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御工程と、
   リフレッシュを実施する場合に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信工程と、
   を含み、
   前記サーバ装置のコンピュータが実行する処理として、
   所定のフラッシュメモリ特性情報を予め設定する記録工程と、
   予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御工程と、
   前記指令に基づいて前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信工程と、
   を含むことを特徴とするフラッシュメモリ保持データのバックアップ通知方法。
8. 前記端末装置のコンピュータに、
   フラッシュメモリにデータを保持する記憶処理と、
   前記フラッシュメモリのリフレッシュを実施する際に、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するよう指令を出す制御処理と、
   前記指令に基づいて、リフレッシュ時の所定のフラッシュメモリ特性情報を前記サーバ装置へ送信するとともに、前記サーバ装置から送信される前記フラッシュメモリの寿命が近い旨の通知を受信する通信処理と、
   を実行させることを特徴とするプログラム。
9. 前記サーバ装置のコンピュータに、
   所定のフラッシュメモリ特性情報を予め設定する記録処理と、
   予め設定された所定のフラッシュメモリ特性情報を基準として、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を比較して、前記端末装置のフラッシュメモリの使用限界を予測し、前記端末装置のフラッシュメモリの寿命が近いと判断した場合には、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するように指令を出す制御処理と、
   前記指令に基づいて、前記フラッシュメモリの寿命が近い旨の通知を前記端末装置へ送信するとともに、前記端末装置から送信されたリフレッシュ時の所定のフラッシュメモリ特性情報を受信する通信処理と、
   を実行させることを特徴とするプログラム。
   

Images