JP2014063217A - バックアップ制御プログラム、バックアップ制御方法および情報処理装置 - Google Patents

バックアップ制御プログラム、バックアップ制御方法および情報処理装置 Download PDF

Info

Publication number
JP2014063217A
JP2014063217A JP2012206319A JP2012206319A JP2014063217A JP 2014063217 A JP2014063217 A JP 2014063217A JP 2012206319 A JP2012206319 A JP 2012206319A JP 2012206319 A JP2012206319 A JP 2012206319A JP 2014063217 A JP2014063217 A JP 2014063217A
Authority
JP
Japan
Prior art keywords
file
terminal
files
priority
terminals
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012206319A
Other languages
English (en)
Other versions
JP5924209B2 (ja
Inventor
Hikaru Itazaki
輝 板▲崎▼
Tatsuro Matsumoto
達郎 松本
Isamu Yamada
勇 山田
Hiroyasu Sugano
博靖 菅野
Koichi Yazaki
孝一 矢崎
Hideki Tanaka
秀樹 田中
Koichi Yokota
耕一 横田
Yoshiisa Kaku
兆功 郭
Daisuke Yamashita
大輔 山下
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2012206319A priority Critical patent/JP5924209B2/ja
Priority to US14/025,411 priority patent/US9292387B2/en
Publication of JP2014063217A publication Critical patent/JP2014063217A/ja
Application granted granted Critical
Publication of JP5924209B2 publication Critical patent/JP5924209B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】複数の端末に分散して記憶されている多数のファイルのバックアップを効率化する。
【解決手段】下記の処理を行う情報処理装置は、複数の端末のうちの１台か、１台以上の端末と通信を行うコンピュータである。情報処理装置は、各ファイルに対して行われた各操作について、操作の種類を示す履歴情報を取得する。情報処理装置は、端末内、端末間、または端末と上記コンピュータの間で行われた各複製操作について、複製元のファイルと複製操作により作成されたファイルを関連づける追跡情報も取得する。情報処理装置は、操作の種類と、追跡情報により当該ファイルと関連づけられている他のファイルの有無（ある場合は、両ファイルのデータが等しいか否か）に基づく優先度を、履歴情報と追跡情報を用いて各ファイルについて算出する。情報処理装置は、ファイルの量に関して指定される条件を満たす範囲内で、優先度の降順に１つ以上のファイルを選択する。
【選択図】図１

Description

本発明はファイルのバックアップに関する。
電子ファイルを管理するための技術は、様々な観点から研究されている。１つの観点は、ユーザがファイルを操作した履歴の活用である。
例えば、注目する情報を含んだ電子文書が特定できなくても、当該情報に関与の強い操作を行ったユーザを絞り込むことを目的として、以下のような文書利用追跡システムが提案されている。
当該文書利用追跡システムにおいて、利用履歴保管部には、文書保管部が提供した各文書内の各ページに対して各ユーザが行った操作を示す利用履歴レコードが蓄積される。また、分析部は、ユーザが入力した検索条件に対する各ページの適合度を示すページスコアを計算する。
分析部はさらに、各ページに対する各ユーザの閲覧時間を利用履歴レコードから求める。そして、分析部は、ページスコアと閲覧時間に基づき、利用履歴レコードについての閲覧スコアを計算する。利用履歴レコードは、閲覧スコアが高い順にソートされて表示される。
また、ファイルの管理に関する別の観点は、ファイルのバックアップである。バックアップの技法についても、様々な観点から様々な研究が行われている。
例えば、バックアップ対象のリストアにかかる時間長をなるべく短くすることができるように、テープ記録媒体にバックアップ対象を記録することを目的として、以下のような方法が提案されている。当該方法では、複数の要素グループにそれぞれ対応した複数のグループリストア優先度の記録された優先度別テーブルが使われる。
具体的には、優先度別テーブルに基づき、第１要素グループに属するすべてのバックアップ対象要素が、テープ記録媒体における連続した記録領域である第１連続領域に、バックアップされる。そして、第１要素グループよりもグループリストア優先度が低い第２要素グループに属するすべてのバックアップ対象要素は、第１連続領域のテープ最後尾側に存在する第２連続領域に、バックアップされる。
また、バックアップに関しては、バックアップしたデータのリストアにかかる時間という観点以外にも、記憶容量という観点から、様々な提案がなされている。
例えば、複数コンテンツが蓄積されたＨＤＤ（Hard Disk Drive）から、複数コンテンツの総容量よりも小さな容量の蓄積媒体へ、すべてのコンテンツをバックアップすることは難しい。そのため、ＨＤＤに蓄積された大量のコンテンツに対して、手動によるコンテンツの選別が行われることがある。
一方、近年ではＨＤＤの記録容量が増加し、選別対象となるデータ数が膨大である。そのため、手動によるコンテンツの取捨選択は非常に煩雑である。
以上のような状況に鑑みて、以下のような情報処理装置が提案されている。具体的には、当該情報処理装置は、ＨＤＤに保存するコンテンツに対して属性情報を付与し、属性情報を管理する。そして、ＨＤＤの故障が予測された場合には、情報処理装置は、優先順位の高いコンテンツを優先的にバックアップする。優先順位は、付与された属性情報に応じて決定することができる。
また、ユーザからの煩雑な操作がなくとも消去可能なデータを判別して、判別した消去可能なデータを消去の対象とすることができる情報処理装置も提案されている。当該情報処理装置は、バックアップ処理の際に、画像ファイルごとに所定の条件が満たされているか判断する。そして、所定の条件が満たされていれば、情報処理装置は、画像ファイルをバックアップし、ユーザにより設定された条件に基づいて、当該画像ファイルの保持優先度を減らす。
保持優先度は、当該画像ファイルを記憶部に保持しておく優先度を示す指標である。保持優先度が高い画像ファイルほど消去されにくい。保持優先度の値は、主にバックアップの有無および回数に応じて変化する。
なお、記憶容量の制限に対しては、ファイルのバックアップのみならず、様々な分野で対策が提案されている。例えば、画像読取形成装置の分野では、未使用機能の管理下にあるファイルを外部記憶装置に退避させることにより、メモリの空き領域を一時的に拡大するような方法も提案されている。しかし、このようなメモリの空き領域に関する技法を、ファイルのバックアップのために応用することは難しい。
特開２００７−３０４７１９号公報 特開２００５−１９０１３９号公報 特開２０１０−４９７２９号公報 特開２００９−１５９０８１号公報 特開平７−１７５９１６号公報
かつてと比べて近年では、１人のユーザが使うファイルの量が増大している。しかも、近年では、複数台の端末を使用するユーザも多い。
一方で、複数台の端末に記憶されている多数のファイルの中には、重要性の低いファイルもあり得るし、複数台の端末間でいくつかのファイルが重複することもあり得る。したがって、複数台の端末に記憶されている多数のファイルのすべてをバックアップすることは、時間と記憶容量の無駄につながり得る。
本発明は、１つの側面では、複数台の端末に分散して記憶されている多数のファイルのバックアップを効率化することを目的とする。
一態様によるバックアップ制御プログラムは、情報処理装置にバックアップ制御処理を実行させる。前記情報処理装置は、ユーザが使う複数台の端末のうちの１台であるか、または、前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータである。
前記バックアップ制御処理は、複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得することを含む。前記複数個のファイルは、前記複数台の端末上に分散して記憶されているか、または前記複数台の端末と前記コンピュータに分散して記憶されている。
前記バックアップ制御処理は、各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を取得することも含む。各複製操作は、前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた複製操作である。
前記バックアップ制御処理は、前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、優先度を算出することも含む。前記優先度は、当該個々のファイルに対して行われた操作の種類と、前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否かに基づく。また、前記別のファイルがある場合は、前記優先度は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否かにも基づく。
前記バックアップ制御処理は、バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択することをさらに含む。
上記のバックアップ制御プログラムによれば、複数台の端末に分散して記憶されている多数のファイルのバックアップが効率化される。
第１実施形態におけるバックアップ制御方法のフローチャートである。 システム構成例を示す図である。 情報処理装置のハードウェア構成図である。 第２実施形態のシステム構成図である。 第２実施形態の動作シーケンスの例を示す図である。 第２実施形態において、ある端末に記憶されるＤＢの例を示す図である。 第２実施形態において、別の端末に記憶されるＤＢの例を示す図である。 第２実施形態において、サーバに記憶される情報の概要を例示する図である。 第２実施形態において、サーバに記憶されるＤＢの例の詳細を示す図である。 第２実施形態で、ある端末が行う処理のフローチャートである。 第２実施形態で、別の端末が行う処理のフローチャートである。 第２実施形態で、サーバが行う処理のフローチャートである。 ファイル間の親子関係と優先度について説明する図である。 第２実施形態のバックアップ制御処理のフローチャート（その１）である。 第２実施形態のバックアップ制御処理のフローチャート（その２）である。 第３実施形態のシステム構成図である。 第３実施形態の動作シーケンスの例を示す図である。 第３実施形態で端末が行う処理の一部を示すフローチャートである。 第３実施形態でサーバが行う処理のフローチャートである。 第３実施形態でサーバが行うＤＢの更新と通知のフローチャートである。
以下、実施形態について、図面を参照しながら詳細に説明する。まず、図１〜３を参照して第１実施形態について説明する。図１〜３は、後述の第２および第３実施形態にも当てはまる図である。続いて、図４〜１５を参照して第２実施形態について説明し、図１６〜２０を参照して第３実施形態について説明する。最後にその他の変形例についても説明する。
さて、図１は、第１実施形態におけるバックアップ制御方法のフローチャートである。図１の処理を実行する情報処理装置は、具体的には、ユーザが使う複数台の端末のうちの１台であってもよい。図１の処理を実行する情報処理装置は、複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータ（例えばサーバ）であってもよい。
利用可能な端末の種類は様々である。例えば、各端末は、以下に例示する様々な種類の端末のうちのいずれかであってもよい。
・デスクトップ型のＰＣ（Personal Computer）
・ラップトップ型のＰＣ
・タブレット型端末
・スマートフォン
・携帯電話
・ＰＤＡ（Personal Digital Assistant）
・携帯型メディアプレーヤ
・ディジタルカメラ
情報処理装置は、図１の処理を実行することにより、複数台の端末上に（または、複数台の端末と上記のコンピュータ上に）分散して記憶されている複数個のファイルの中から、バックアップ対象の１つ以上のファイルを選択する。詳しくは後述するとおり、情報処理装置は、バックアップすることが好ましいファイルに高い優先度を割り当て、優先度にしたがってファイルを選択する。情報処理装置による自動選択により、ファイルのバックアップが効率化される。具体的には以下のとおりである。
ユーザが複数台の端末を使う場合、複数台の端末（または、複数台の端末と上記のコンピュータ）に記憶されている全ファイルをバックアップすることは、時間と記憶容量の無駄につながり得る。
例えば、複数台の端末上には、大量のファイルが分散して記憶されている場合があり、大量のファイルの中には、重要性の低いファイルもあり得るし、複数台の端末間でいくつかのファイルが重複することもあり得る。ユーザは、重要性の低いファイルのバックアップのために記憶領域を使いたくないかもしれない。また、複数台の端末間で重複しているファイルは、事実上バックアップされているので、当該ファイルをさらにバックアップする必要性は低い。よって、全ファイルをバックアップすることは、時間と記憶容量の無駄につながり得る。
一方で、ユーザが大量のファイルの中からバックアップ対象のファイルを手動で適切に選択することは、非常に手間がかかるので、現実的には困難である。
第１実施形態では、複数台の端末上に（または、複数台の端末と上記のコンピュータ上に）記憶されている複数個のファイルの中から、一部のファイルが情報処理装置により自動的に選択され、選択されたファイルがバックアップされる。よって、第１実施形態では、バックアップにかかる時間と記憶領域を節約する効果が得られる。さらに、情報処理装置による自動選択により、ユーザがバックアップ対象のファイルを手動で選択する手間もなくせる。
また、情報処理装置が各ファイルについて計算する優先度は、バックアップすることが好ましいファイルほど高くなるように、定義される。情報処理装置が優先度を計算するための式の定義は、可変であってもよい。例えば、優先度を計算するための式の定義（例えば式の中のパラメタの値）は、「どういうファイルをバックアップすることが好ましいとユーザが考えているのか」ということに応じて、適宜決められてもよい。つまり、情報処理装置は、ユーザの考えに応じてカスタマイズされた式にしたがって優先度を計算してもよい。もちろん、情報処理装置は、デフォルトの式にしたがって優先度を計算してもよい。
いずれにしろ、第１実施形態によれば、バックアップすることが好ましいファイルほど、優先度が高いので、優先的に選択され、バックアップされる。その結果、時間と記憶領域の無駄が減る。また、ユーザは、大量のファイルの中からバックアップ対象の一部のファイルを選び出す手間をかけなくてよいので、ユーザの負担も少ない。
以上のようなバックアップの効率化は、具体的には、図１の処理により実現される。以下、図１の処理について詳しく説明する。
ステップＳ１で、情報処理装置は、複数台の端末上に（または、複数台の端末と上記のコンピュータ上に）分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得する。操作の種類は、例えば、作成、編集、閲覧、コピー、変名（rename）、ディレクトリ間での移動（move）、送信、受信などである。編集操作は、換言すれば変更操作である。履歴情報は、当該操作が行われた時点や当該操作にかかった時間の長さをさらに示していてもよい。
次にステップＳ２で、情報処理装置は、追跡情報を取得する。追跡情報は、複製操作によって生じる親ファイルと子ファイルの関係を示す。なお、「複製操作」は、より具体的には、以下のいずれの操作であってもよい。
・複数台の端末のうちの１台の端末内で行われる複製操作。例えば、端末内でファイルをコピーする操作。
・複数台の端末のうちの２台の端末間で行われる複製操作。例えば、第１の端末に記憶されているファイルを、第１の端末が第２の端末に送信し、第２の端末が、受信したファイルを第２の端末内に記憶する場合がある。この場合、結果として、端末間でファイルが複製（duplicate）される。
・複数台の端末のうちの１台と、複数台の端末とネットワークを介して通信を行うコンピュータ（例えばサーバ）との間で行われ複製操作。例えば、第１の端末に記憶されているファイルを、第１の端末がサーバに送信（つまりアップロード）し、サーバが、受信したファイルをサーバ内に記憶する場合がある。この場合、結果として、端末・サーバ間でファイルが複製される。また、サーバ上のファイルを第２の端末が受信（つまりダウンロード）する場合も、端末・サーバ間でファイルが複製される。
以下では説明の便宜上、第１のファイルを複製することで第２のファイルが得られた場合、第１のファイルを「親ファイル」ともいい、第２のファイルを「子ファイル」ともいう。親ファイルは、換言すれば複製元のファイルであり、子ファイルは、親ファイルに対する複製操作により新たに作成されたファイルである。また、以下の説明では、木構造に関する「根」・「葉」・「先祖」・「子孫」などの用語を用いて「根ファイル」や「子孫ファイル」などの言い方をすることもある。追跡情報により、ファイル間の親子関係を追跡する（track）ことが可能となる。
なお、ステップＳ１とＳ２の実行順序は逆でもよいし、ステップＳ１とＳ２が並行して実行されてもよい。また、ステップＳ１における履歴情報の取得は、時間的に分散していてもよく、ステップＳ２における追跡情報の取得も、時間的に分散していてもよい。
例えば、１つのファイルに対して１つの操作が行われるたびに、当該操作についての履歴情報を情報処理装置が取得してもよい。または、いくつかのファイルに対してそれぞれ１回以上行われた操作の各々についての履歴情報を、情報処理装置が一度に取得してもよい。
同様に、１回の複製操作のたびに、当該複製操作によって生じた親子関係を示す追跡情報を情報処理装置が取得してもよい。または、いくつかの複製操作についての追跡情報を、情報処理装置が一度に取得してもよい。
また、あるファイルに対するある操作についての履歴情報は、情報処理装置自体により生成される場合もあり得る。つまり、情報処理装置は、操作の検出に応じて自ら履歴情報を生成することで、履歴情報を取得する場合がある。他方、情報処理装置は、他のファイルに対する操作についての履歴情報を、他の装置から受信する場合もあり得る。つまり、情報処理装置は、受信により履歴情報を取得する場合があり得る。情報処理装置は、一部の履歴情報を生成することにより取得し、残りの履歴情報を他の装置から受信することにより取得してもよい。
同様に、ある複製操作に関する追跡情報は、情報処理装置自体により生成される場合もあり得る。つまり、情報処理装置は、複製操作の検出に応じて自ら追跡情報を生成することで、追跡情報を取得する場合がある。他方、情報処理装置は、他の複製操作に関する追跡情報を、他の装置から受信する場合もあり得る。つまり、情報処理装置は、受信により追跡情報を取得する場合があり得る。情報処理装置は、一部の追跡情報を生成することにより取得し、残りの追跡情報を他の装置から受信することにより取得してもよい。
例えば、図１の処理を実行する情報処理装置が複数台の端末のうちの第１の端末である場合があり得る。この場合、情報処理装置は、複数個のファイルのうちで、第１の端末に記憶されているいずれかのファイルに対して、第１の端末上で行われる操作を検出してもよい。そして、情報処理装置は、検出した操作の種類を示す履歴情報を生成してもよい。
また、図１の処理を実行する情報処理装置が上記第１の端末の場合、情報処理装置は、複数個のファイルのうちで、複数台の端末のうちのある特定の端末に記憶されているいずれかのファイルの、特定の端末から第１の端末への送信を検出してもよい。そして、情報処理装置は、特定の端末から第１の端末へ送信されたファイルに関する情報を推定してもよい。例えば、情報処理装置は、ファイルの作成日時を推定してもよい。
また、特定の端末は、具体的には、履歴情報を生成する機能を持たない端末であってもよいし、ネットワーク通信機能を持たない端末であってもよい。情報処理装置は、上記ファイルに関して、「作成」（具体的には、特定の端末における作成）という種類を示す履歴情報を、特定の端末の代わりに生成してもよい。
また、図１の処理を実行する情報処理装置が上記第１の端末の場合、情報処理装置は、第１の端末に記憶されている第１のファイルを第１の端末内で第２のファイルに複製する複製操作を検出してもよい。そして、情報処理装置は、第１のファイルと第２のファイルを関連づける追跡情報を生成してもよい。
逆に、図１の処理を実行する情報処理装置が、複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータ（例えばサーバ）である場合もあり得る。この場合、情報処理装置は、複数台の端末のうちの第１の端末に記憶されているいずれかのファイルに対して第１の端末上で行われる操作の種類を示す履歴情報を、第１の端末から受信してもよい。また、この場合、情報処理装置は、一部の追跡情報を受信することにより取得し、他の追跡情報を生成することにより取得してもよい。
例えば、複数個のファイルのうちで、第１の端末に記憶されている第３のファイルを、第１の端末が第１の端末内で第４のファイルに複製した場合に、情報処理装置は、第１の端末から、第３のファイルと第４のファイルを関連づける追跡情報を受信してもよい。また、複数個のファイルのうちで、第１の端末に記憶されている第５のファイルを、第１の端末が第２の端末に送信し、送信された第５のファイルを第２の端末が第６のファイルとして第２の端末内に記憶した場合に、情報処理装置は、追跡情報を生成してもよい。具体的には、情報処理装置は、第１の端末からの第５のファイルに関する通知と、第２の端末からの第６のファイルに関する通知に基づいて、第５のファイルと第６のファイルを関連づける追跡情報を生成してもよい。
第１の端末からの第５のファイルに関する上記通知は、具体的には、第１の端末における第５のファイルに対する「送信」という操作の種類を示す履歴情報であってもよい。同様に、第２の端末からの第６のファイルに関する上記通知は、具体的には、第２の端末における第６にファイルに対する「受信」という操作の種類を示す履歴情報であってもよい。つまり、情報処理装置は、２台の端末からそれぞれ送信される履歴情報を受信し、履歴情報に基づいて追跡情報を生成することで、追跡情報を取得する場合もあり得る。
また、図１の処理を実行する情報処理装置が、複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータ（例えばサーバ）である場合、端末と情報処理装置の間の複製操作に関して、情報処理装置は以下のように動作してもよい。複数個のファイルのうちで、第１の端末に記憶されている第７のファイルを、第１の端末が情報処理装置に送信し、送信された第７のファイルを情報処理装置が第８のファイルとして情報処理装置内に記憶することがある。この場合、情報処理装置は、第７のファイルと第８のファイルを関連づける追跡情報を生成することで、追跡情報を取得することができる。
以上説明したように、ステップＳ１〜Ｓ２における情報の取得の具体的手順は、実施形態に応じて様々であってよい。
さて、続くステップＳ３〜Ｓ５で情報処理装置は、履歴情報と追跡情報を用いて、上記複数個のファイルに含まれる個々のファイルについて、優先度を算出する。優先度は、具体的には、以下の事柄に基づく。
・当該個々のファイルに対して行われた操作の種類。
・追跡情報により当該個々のファイルと関連づけられている別のファイルが上記複数個のファイルの中にあるか否か。
・上記別のファイルがある場合は、当該個々のファイルのデータと上記別のファイルのデータが等しいか否か。
具体的には、ステップＳ３で、情報処理装置は、複数台の端末上（または、複数台の端末と上記のコンピュータ上）の上記複数個のファイルのうち、優先度を算出していないファイルがあるか否かを判断する。もし、優先度を算出していないファイルがまだ残っていれば、図１の処理はステップＳ４に移行する。逆に、すべてのファイルについて優先度が算出済みなら、図１の処理はステップＳ６に移行する。
ステップＳ４で情報処理装置は、優先度を算出していないファイルを１つ選ぶ。説明の便宜上、以下では、ステップＳ４で選ばれたファイルを「選択ファイル」という。
次に、ステップＳ５で情報処理装置は、履歴情報と追跡情報を用いて、選択ファイルの優先度を算出する。優先度が何に基づくかは上述のとおりであるが、より詳しく説明すると、以下のとおりである。
・選択ファイルに対して行われた操作の種類（例えば、選択ファイルに関して何らかの操作が今までに５回行われた場合には、５回の操作それぞれの種類）。選択ファイルに対して行われた操作の種類は、履歴情報により示される。
・追跡情報により選択ファイルと関連づけられている別のファイル（つまり、選択ファイルの親ファイルまたは選択ファイルの子ファイル）が存在するか否か。
・追跡情報により選択ファイルと関連づけられている別のファイルが存在する場合、選択ファイルのデータと、追跡情報により選択ファイルと関連づけられている別のファイルのデータとが等しいか否か。
ステップＳ５での優先度の算出後、図１の処理はステップＳ３に戻る。そして、情報処理装置は、ステップＳ３〜Ｓ５の繰り返しによりすべてのファイルについて優先度を算出すると、次に、ステップＳ６〜Ｓ７で、ある条件を満たす範囲内で、優先度の降順に、上記複数個のファイルの中から１つ以上のファイルを選択する。
なお、上記「ある条件」とは、バックアップする対象のファイルの量に関して指定される条件である。例えば、「合計で１５ＧＢ（ギガバイト）まで」のように、ファイルの合計サイズによって条件が指定されてもよい。または、「１０００個のファイルまで」のように、ファイルの個数によって条件が指定されてもよい。
具体的には、ステップＳ６で、情報処理装置は、「バックアップ対象としては未選択のファイルのうちで優先度が最高のファイルを選択しても、指定された条件が満たされるか否か」を判断する。もし、バックアップ対象としては未選択のファイルのうちで優先度が最高のファイルを選択しても、指定された条件がまだ満たされるならば、図１の処理はステップＳ７に移行する。
例えば、上記のように「合計で１５ＧＢまで」という条件が指定されているとする。この場合、もし、バックアップ対象としては未選択のファイルのうちで優先度が最高のファイルを選択しても、バックアップ対象として選択済みのファイルの合計サイズが１５ＧＢ以下ならば、図１の処理はステップＳ７へと移行する。
そして、ステップＳ７で、情報処理装置は、バックアップ対象としては未選択のファイルのうちで優先度が最高のファイルを、バックアップ対象として選択する。ステップＳ７での選択後、図１の処理はステップＳ６に戻る。
以上のようにしてステップＳ６〜Ｓ７が繰り返されると、優先度の高いファイルから順にバックアップ対象のファイルとして選ばれる。そして、ある個数のファイルが選ばれた後のステップＳ６において、「バックアップ対象としては未選択のファイルのうちで優先度が最高のファイルを選択すると、指定された条件が満たされなくなる」と判断される。ステップＳ６でこのように判断されると、図１の処理は終了する。なお、もし情報処理装置がすべてのファイルを選択し終わってもなお、指定された条件が満たされる場合（例えば、全ファイルの合計サイズよりも大きな容量が条件として指定された場合など）も、図１の処理は終了する。
以上のようにして図１の処理によりバックアップ対象のファイルを選択した後、情報処理装置は、選択結果にしたがって適宜の処理を行う。例えば、情報処理装置自体がファイルのバックアップを実行する場合、情報処理装置は、選択したファイルをバックアップする。
また、情報処理装置自体はファイルのバックアップを実行しない場合もあり得る。この場合、情報処理装置は、ファイルのバックアップを実行する装置（例えば、複数台の端末のうち、バックアップソフトウェアがインストールされた端末）に対して、選択結果を通知する。すると、図１の選択結果に応じてバックアップが行われる。選択結果の通知は、具体的には、バックアップ対象として情報処理装置が選択した各ファイルを識別するファイル識別情報を含む。ファイル識別情報は、例えば、ファイルが記憶されている端末を識別する情報と、端末内でファイルを識別する情報（例えばファイルの絶対パス）を含む。
ところで、上記のとおり、情報処理装置が優先度を計算するための式は、バックアップすることが好ましいファイルほど、優先度が高くなるように決められる。以下に、優先度に関する具体例をいくつか示す。
例えば、ステップＳ４で情報処理装置が、ある根ファイル（すなわち複数個のファイルのうち、他のファイルに対する複製操作により得られたのではないファイル）を選択したとする。この場合、情報処理装置がステップＳ５で根ファイルの優先度を算出する処理は、１回以上の複製操作により根ファイルから直接または間接に得られた１個以上の子孫ファイルの各々に対して行われた各操作に応じて、根ファイルの優先度を上げる処理を含んでもよい。
例えば、ユーザは、カメラを有する端末を使って写真を撮影する場合がある。撮影の結果として、画像ファイルが端末に記憶される。ユーザは、オリジナルの画像ファイルをそのまま残す一方で、オリジナルの画像ファイルをコピーし、コピーにより得られた新たな画像ファイルをレタッチすることがある。ユーザは、レタッチした画像ファイルをさらにコピーし、コピーにより得られた新たな画像ファイルをさらにレタッチすることもある。このようにして、ユーザは、異なるバージョンの画像ファイルをいくつか作成することがある。
この場合、オリジナルの画像ファイルが根ファイルである。根ファイルから以上のようにして直接または間接に派生した画像ファイルは、子孫ファイルである。
一方、「ユーザは、ユーザが不要と考えるファイルに対してわざわざ多くの操作を行うことはあまりない」と想定される。換言すれば、根ファイルから子孫ファイルがいくつも作成される場合、ユーザが根ファイルを重要視している蓋然性が高い。
また、仮に子孫ファイルが消えた場合であっても、ユーザが過去と同じ操作を繰り返すことで、削除されたのと同じファイルを再作成することは決して不可能ではない。しかし、根ファイルが消えた場合に、根ファイルを再現することは困難である。
そのため、根ファイルの優先度を高めること（すなわち、根ファイルが優先的にバックアップされるようにし、根ファイルの消失を防ぐこと）は、好ましい。そこで、上記のように情報処理装置は、根ファイルの優先度を算出する際に、各子孫ファイルに対して行われた各操作に応じて、根ファイルの優先度を上げてもよい。もちろん、情報処理装置は、根ファイル自体に対して行われた各操作にも応じて、根ファイルの優先度を上げることが好ましい。
また、根ファイルだけでなく、葉ファイル（つまり、根ファイルから派生した１個以上の子孫ファイルのうちで、どの複製操作における複製元ファイルでもないファイル）も、比較的重要性が高いと考えられる。なぜなら、根ファイルでも葉ファイルでもない中間ファイルは、編集過程の途中の状態を示すものであるのに対し、葉ファイルは最新の編集結果を反映した最新バージョンのファイルだからである。よって、情報処理装置は、ステップＳ４で葉ファイルを選んだ場合には、選んだ葉ファイルの優先度を、ステップＳ５において根ファイルの優先度に応じて上げてもよい。
ところで、ステップＳ５に関して説明したように、選択ファイルの優先度は、選択ファイルのデータと、追跡情報により選択ファイルと関連づけられている別のファイルのデータとが等しいか否かにも基づく。具体的には、両ファイルのデータが等しい場合よりも、両ファイルのデータが等しくない場合の方が、選択ファイルの優先度がより高い。
例えば、複数個のファイルのうちの第１のファイルに対する複製操作により第２のファイルが得られたとする。複製操作が行われた後、第１のファイルが編集されることもあるし、第１のファイルが編集されないこともある。同様に、複製操作が行われた後、第２のファイルが編集されることもあるし、第２のファイルが編集されないこともある。よって、第１のファイルのデータと第２のファイルのデータが等しいとは限らない。
第１のファイルのデータと第２のファイルのデータが等しい場合は、第２のファイルを第１のファイルのバックアップコピーと見なすことができ、第１のファイルを第２のファイルのバックアップコピーと見なすこともできる。つまり、第１のファイルのデータと第２のファイルのデータが等しい場合は、第１のファイルをバックアップする必要性はそれほど高くないし、第２のファイルをバックアップする必要性もそれほど高くない。
したがって、第１のファイルのデータと第２のファイルのデータが異なる場合は、第１のファイルのデータと第２のファイルのデータが等しい場合よりも、第１のファイルと第２のファイルをバックアップする必要性が高い。そこで、優先度は、以下のように定義されていてもよい。
・第１のファイルのデータと第２のファイルのデータが等しい場合よりも、第１のファイルのデータと第２のファイルのデータが等しくない場合の方が、第１のファイルの優先度がより高い。
・第１のファイルのデータと第２のファイルのデータが等しい場合よりも、第１のファイルのデータと第２のファイルのデータが等しくない場合の方が、第２のファイルの優先度もより高い。
ところで、ファイルは、ユーザの指示に応じて変更される場合もあり得るし、自動的に変更される場合もあり得る。例えば、ある種のファイルには、デーモンにより所定の時間間隔でデータが追加されることがある。ユーザにとっての重要性は、ユーザ自身が変更したファイルの方が、ユーザの意思と関係なく自動的に更新されるファイルよりも、高いと想定される。
ここで、説明の便宜上、ファイルに対する操作のうち、ユーザからの指示に基づく操作を、「ユーザ主導（user-driven）操作」という。逆に、複数台の端末のうち当該ファイルを記憶する端末が所定のプログラムを実行することにより、自動的に行われる操作を、「自動操作」という。
ユーザ主導操作は、自動操作よりも、優先度をより高めるように、優先度に影響してもよい。つまり、情報処理装置は、ユーザ手動操作が行われた場合には、自動操作が行われた場合よりも、より高い優先度を算出してもよい。
ところで、第１の端末が第２の端末またはサーバから受信したファイルと、第１の端末にしか存在しないファイルを比較すると、前者のファイルをバックアップする必要性は、後者のファイルをバックアップする必要性よりも低い。なぜなら、「前者のファイルのバックアップコピーが、第２の端末またはサーバにある」と見なせるからである。
そこで、新規ファイルを作成する作成操作は、他の操作（より具体的には、例えば受信操作）よりも、優先度をより高めるように、優先度に影響してもよい。つまり、情報処理装置は、作成操作が行われた場合には、他の操作が行われた場合よりも、より高い優先度を算出してもよい。すると、大まかな傾向としては、例えば、第１の端末により作成されて第１の端末にしか存在しないファイルの優先度を、第１の端末が第２の端末から受信したファイルの優先度よりも高くすることが可能となる。
ところで、履歴情報は、操作が行われた時点をさらに示してもよい。この場合、複数個のファイルの各々に対して行われた各操作について、当該操作が行われた時点が新しいほど、当該ファイルの優先度が高くてもよい。なぜなら、ユーザが長期間にわたって操作を行っていないファイルよりも、ユーザが最近何らかの操作（例えば、閲覧、編集、変名、コピー、送信など、何の操作であってもよい）を行ったファイルの方が、ユーザにとっての重要度が高いと考えられるからである。
また、履歴情報は、操作にかかった時間をさらに示してもよい。この場合、複数個のファイルの各々に対して行われた各操作について、当該操作にかかった時間が長いほど、当該ファイルの優先度が高くてもよい。例えば、ユーザが長時間かけて編集したファイルの重要性は高いと考えられるので、操作にかかった時間に応じて優先度が決められてもよい。
続いて、図２を参照して、第１実施形態が適用可能なシステムの構成例について説明する。図１に関する上記の説明は、様々な構成のシステムに適用可能である。図２には、システム構成の一例が示されている。
図２のシステム１００は、ネットワーク１０１に接続された様々な装置を含む。ネットワーク１０１は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、それらの組み合わせのいずれであってもよい。
例えば、あるユーザは、スマートフォン１０２とタブレット端末１０４とＰＣ１０６とカメラ１０９という、４台の端末を使う。スマートフォン１０２は、ＳＳＤ（Solid-State Drive）１０３を有しており、ネットワーク１０１に接続可能である。タブレット端末１０４も、ＳＳＤ１０５を有しており、ネットワーク１０１に接続可能である。
また、ＰＣ１０６はＨＤＤ１０７を有し、ネットワーク１０１に接続可能である。さらに、外付けのＨＤＤ１０８がＰＣ１０６に接続されてもよい。また、カメラ１０９は、ネットワーク１０１に接続可能なもの（例えば無線通信機能を備えたディジタルカメラ）であってもよいが、通信機能を持っていなくても構わない。例えば、カメラ１０９は、ＵＳＢ（Universal Serial Bus）ケーブルを介してＰＣ１０６に接続可能であってもよい。
ネットワーク１０１には、他のユーザが使う端末１１０と端末１１１がさらに接続されていてもよい。
また、ネットワーク１０１には、管理サーバ１１２が接続されている。ネットワーク１０１にはさらに、コンテンツサーバ（content server）１１３が接続されていてもよいし、ＮＡＳ（Network-Attached Storage）１１４またはファイルサーバが接続されていてもよい。
図１に関して説明した「複数台の端末」は、具体的には、スマートフォン１０２とタブレット端末１０４とＰＣ１０６とカメラ１０９であってもよい。また、図１に関して説明した「複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータ」は、具体的には管理サーバ１１２であってもよい。管理サーバ１１２は、スマートフォン１０２、タブレット端末１０４、およびＰＣ１０６と、ネットワーク１０１を介して通信を行うことができる。
図１の処理を実行する上記の「情報処理装置」は、具体的には、例えば、ＰＣ１０６であってもよいし、管理サーバ１１２であってもよい。例えば、ＰＣ１０６にはバックアップソフトウェアがインストールされていてもよく、ＰＣ１０６は、図１の処理により選んだファイルをバックアップしてもよい。バックアップする対象の個々のファイルは、例えば、以下のいずれかの場所に記憶されている。
・スマートフォン１０２内のＳＳＤ１０３。
・タブレット端末１０４内のＳＳＤ１０５。
・ＰＣ１０６内のＨＤＤ１０７。
・カメラ１０９内の不図示の不揮発性記憶領域（例えばフラッシュメモリカード）。
選んだファイルをＰＣ１０６がどこにバックアップするかは、例えばユーザからの指示にしたがって、適宜決められてよい。例えば、ＰＣ１０６は、図１の処理により選んだファイルを、以下のいずれかの領域にバックアップしてもよい。
・ＰＣ１０６内のＨＤＤ１０７上の領域。
・ＨＤＤ１０８上の領域。
・ＮＡＳ１１４上の領域。
・ＳＳＤ１０３上の領域とＳＳＤ１０５上の領域とＨＤＤ１０７上の領域の組み合わせ。
図１の処理を実行する上記の「情報処理装置」が管理サーバ１１２である場合、管理サーバ１１２は、選択結果をＰＣ１０６に通知してもよい。すると、ＰＣ１０６は、管理サーバ１１２からの通知にしたがって、選択されたファイルを上記のいずれかの領域に適宜バックアップする。
コンテンツサーバ１１３は、ネットワーク１０１を介してユーザ端末からのファイルのアップロードを受け付ける。アップロードされたファイルは、ファイルの所有者（owner）のユーザ自身にのみ公開されてもよいし、特定の何人かのユーザのグループにのみ公開されてもよいし、制限なく一般に公開されてもよい。
管理サーバ１１２とコンテンツサーバ１１３が同じ１台のコンピュータであってもよい。つまり、管理サーバ１１２がコンテンツサーバ１１３を兼ねていてもよい。管理サーバ１１２がコンテンツサーバ１１３を兼ねている場合、コンテンツサーバ１１３と端末との間での複製操作を、管理サーバ１１２が検出することができる。
例えば、タブレット端末１０４上のファイルがアップロードされた場合、タブレット端末１０４上のファイルが親ファイルであり、コンテンツサーバ１１３上に保存（save）されたファイルが子ファイルである。管理サーバ１１２は、タブレット端末１０４からのファイルの受信に応じて、親ファイルと子ファイルを関連づける追跡情報を生成してもよい。
図１のステップＳ１〜Ｓ２に関する説明から明らかなように、一部の履歴情報または一部の追跡情報が、スマートフォン１０２から管理サーバ１１２に送信される場合もある。また、一部の履歴情報または一部の追跡情報が、タブレット端末１０４から管理サーバ１１２に送信される場合もある。同様に、一部の履歴情報または一部の追跡情報が、ＰＣ１０６から管理サーバ１１２に送信される場合もある。
逆に、管理サーバ１１２から、一部の履歴情報または一部の追跡情報が、ＰＣ１０６に送信される場合もある。さらに、一部の履歴情報または一部の追跡情報が、管理サーバ１１２からスマートフォン１０２へ送信されてもよいし、タブレット端末１０４へ送信されてもよい。履歴情報と追跡情報の取得に関する、より具体的な手順の例については、後述の第２実施形態と第３実施形態に示す。
ところで、図１の処理を実行する情報処理装置は、具体的には図３のように構成されていてもよい。図３の情報処理装置２００は、ＣＰＵ（Central Processing Unit）２０１と、ＲＡＭ（Random Access Memory）２０２と、ネットワーク通信装置２０３と、シリアル接続インタフェイス回路２０４を有する。以下、「インタフェイス」を「Ｉ／Ｆ」と略すことがある。情報処理装置２００はさらに、入力装置２０５と、出力装置２０６と、不揮発性記憶装置２０７と、記憶媒体２１０のリーダ／ライタ２０８を有する。「リーダ／ライタ」は「リーダおよびライタ」の意味である。
情報処理装置２００内の各コンポーネントは、バス２０９で互いに接続されている。また、情報処理装置２００はネットワーク通信装置２０３を介してネットワーク２２０に接続されている。ネットワーク２２０は、ＬＡＮ、ＷＡＮ、インターネット、その組み合わせのいずれであってもよい。また、ネットワーク２２０は、有線ネットワークでもよく、無線ネットワークでもよく、両者の組み合わせであってもよい。
ＣＰＵ２０１は、シングルコアまたはマルチコアのプロセッサである。情報処理装置２００は、複数のプロセッサを有していてもよい。例えば、情報処理装置２００は、２台以上のＣＰＵ２０１を有していてもよい。ＣＰＵ２０１は、プログラムをＲＡＭ２０２にロードし、ＲＡＭ２０２をワーキングエリアとしても利用しながら、プログラムを実行する。
ネットワーク通信装置２０３は、例えば、有線ＬＡＮインタフェイス、無線ＬＡＮインタフェイス、またはその組み合わせである。ネットワーク通信装置２０３は、具体的には、外付けのＮＩＣ（Network Interface Card）でもよいし、オンボード型のネットワークインタフェイスコントローラでもよい。例えば、ネットワーク通信装置２０３は、物理層の処理を行う「ＰＨＹチップ」と呼ばれる回路と、ＭＡＣ（Media Access Control）副層の処理を行う「ＭＡＣチップ」と呼ばれる回路を含んでいてもよい。
シリアル接続Ｉ／Ｆ回路２０４は、例えば、ＵＳＢ接続のための、ＵＳＢコントローラとＵＳＢポートを含んでいてもよい。あるいは、シリアル接続Ｉ／Ｆ回路２０４は、ＵＳＢ以外の種類のシリアル接続用の回路であってもよい。情報処理装置２００は、シリアル接続Ｉ／Ｆ回路２０４の代わりに（またはシリアル接続Ｉ／Ｆ回路２０４に加えて）、パラレル接続Ｉ／Ｆ回路を有していてもよい。
例えば、ＰＣ１０６が情報処理装置２００である場合、シリアル接続Ｉ／Ｆ回路２０４は２個以上のＵＳＢポートを含んでいてもよい。この場合、１つのＵＳＢポートを介して情報処理装置２００とＨＤＤ１０８が接続されてもよく、もう１つのＵＳＢポートを介して情報処理装置２００とカメラ１０９が接続されてもよい。
入力装置２０５は、例えば、キーボード、ポインティングデバイス、マイク、カメラまたはその組み合わせである。ポインティングデバイスは、例えば、マウスでもよいしタッチパッドでもよいしタッチスクリーンでもよい。出力装置２０６は、ディスプレイ、スピーカ、またはその組み合わせである。ディスプレイはタッチスクリーンであってもよい。
不揮発性記憶装置２０７は、例えば、ＨＤＤ、ＳＳＤ、またはその組み合わせである。さらにＲＯＭ（Read-Only Memory）が不揮発性記憶装置２０７として使われてもよい。
記憶媒体２１０の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリなどの半導体メモリカードなどである。リーダ／ライタ２０８は、具体的には、光ディスク駆動装置、光磁気ディスク駆動装置、または磁気ディスク駆動装置であってもよいし、メモリカード用のリーダ／ライタであってもよい。
ＣＰＵ２０１が実行するプログラムは、予め不揮発性記憶装置２０７にインストールされていてもよい。あるいは、プログラムは、記憶媒体２１０に格納されて提供され、記憶媒体２１０からリーダ／ライタ２０８により読み取られて不揮発性記憶装置２０７にコピーされ、その後、ＲＡＭ２０２にロードされてもよい。
または、プログラムは、ネットワーク２２０上のプログラム提供者２２１から、ネットワーク２２０とネットワーク通信装置２０３を介して、プログラムが情報処理装置２００にダウンロードされ、インストールされてもよい。プログラム提供者２２１は、具体的には、情報処理装置２００とは別の情報処理装置である。
なお、ＲＡＭ２０２、不揮発性記憶装置２０７、および記憶媒体２１０は、いずれも、有形の（tangible）記憶媒体の例である。これらの有形の記憶媒体は、信号搬送波のような一時的な（transitory）媒体ではない。
上記のとおり、図１の処理を実行する情報処理装置は、例えば図２のＰＣ１０６であってもよいし、管理サーバ１１２であってもよい。つまり、ＰＣ１０６が図３の情報処理装置２００であってもよいし、管理サーバ１１２が情報処理装置２００であってもよい。
また、図１の処理を実行する情報処理装置は、具体的には、取得した履歴情報を記憶する第１の記憶部と、取得した追跡情報を記憶する第２の記憶部と、優先度を算出する優先度算出部と、優先度にしたがって１つ以上のファイルを選択する選択部を有してもよい。第１の記憶部と第２の記憶部は、図２の不揮発性記憶装置２０７により実現されてもよい。また、優先度算出部と選択部は、プログラムを実行するＣＰＵ２０１によって実現されてもよい。
ところで、図２の中のその他の装置も、図３のように構成されていてもよい。例えば、スマートフォン１０２が情報処理装置２００である場合、ネットワーク通信装置２０３は、具体的には、ＬＴＥ（Long Term Evolution）規格にしたがった通信回路と、無線ＬＡＮインタフェイス回路とを含んでいてもよい。同様に、タブレット端末１０４が情報処理装置２００である場合も、ネットワーク通信装置２０３は、ＬＴＥ規格にしたがった通信回路と、無線ＬＡＮインタフェイス回路とを含んでいてもよい。
カメラ１０９が情報処理装置２００である場合、ネットワーク通信装置２０３は省略されてもよい。また、入力装置２０５は、レンズや光電変換回路などを含む撮像部であってもよい。
端末１１０、端末１１１、管理サーバ１１２、およびコンテンツサーバ１１３の各々も、情報処理装置２００のように構成されていてもよい。
続いて、図４〜１５を参照して第２実施形態について説明する。図４は、第２実施形態のシステム構成図である。図４のシステム３００は、あるユーザが使う２台の端末３１０と３３０を含み、さらにサーバ３５０を含む。端末３１０、端末３３０、およびサーバ３５０は、それぞれネットワーク３７０に接続可能である。ネットワーク３７０の種類は任意である。
例えば、端末３１０は、図２のスマートフォン１０２またはタブレット端末１０４であってもよい。端末３３０は、図２のＰＣ１０６であってもよい。サーバ３５０は、図２の管理サーバ１１２であってもよい。そして、ネットワーク３７０は、図２のネットワーク１０１であってもよい。
より詳しくは、端末３１０は、通信部３１１と、ファイル記憶部３１２と、監視部３１３と、デバイスＩＤ（identification）記憶部３１４と、ＤＢ（database）管理部３１５と、ＤＢ記憶部３１６を有する。
通信部３１１は、ネットワーク３７０を介して端末３３０およびサーバ３５０と通信する。ファイル記憶部３１２は、種々のファイルを記憶する。
監視部３１３は、ファイル記憶部３１２に記憶されているファイルに対する操作を監視する。そして、何らかの操作を検出すると、監視部３１３は、監視結果をＤＢ管理部３１５に出力する。
例えば、監視部３１３は、ユーザから端末３１０の入力装置２０５を介して与えられる入力に応じたユーザ主導操作を監視する。さらに、監視部３１３は、例えばデーモンなどの所定のプログラムを端末３１０が実行することによって自動的に行われる自動操作を監視してもよい。
監視部３１３は、例えば、ファイル操作に関するＡＰＩ（Application Programming Interface）関数の呼び出しをフックしてもよいし、ファイル操作に関するシステムコールをフックしてもよい。また、監視部３１３を実現するために、アプリケーション上でのメニュー選択をフックするアドオンが付加的に使われてもよい。
ＡＰＩ関数の呼び出し、システムコール、アプリケーション上でのメニュー選択などをフックすることで、監視部３１３は、ファイルに対する操作を検出することができる。さらに、監視部３１３は、監視部３１３がフックしたシステムコールの呼び出し元（caller）のプロセスを認識してもよい。そして、監視部３１３は、認識した呼び出し元のプロセスに応じて、「ファイルに対してユーザ主導操作が行われたのか、それとも自動操作が行われたのか」ということを判断してもよい。
監視部３１３を実現するのにアドオンも使われる場合は、アプリケーション固有の種別の操作（例えば「コメントの追加」などの操作）も検出可能となる。また、ファイルの送信と受信を監視するために、監視部３１３は、さらに通信部３１１を監視してもよい。例えば、監視部３１３は、ファイルの送信と受信を監視するために、パケットキャプチャを行ってもよい。
また、端末３１０と３３０の双方に、端末間での同期をサポートする特定のアプリケーション（例えば、ある種の写真管理アプリケーションや、メディアプレーヤ・アプリケーションなど）がインストールされている場合がある。その場合、監視部３１３を実現するために、当該特定のアプリケーションのアドオンが使われてもよい。すると、監視部３１３は、同期機能によるファイルの送信と受信を検出することができる。
監視部３１３は、メーラの動作を監視してもよい。具体的には、監視部３１３は、端末３１０が受信した電子メールに添付されているファイルの、ファイル記憶部３１２への保存を、監視してもよい。
デバイスＩＤ記憶部３１４は、端末３１０を識別するデバイスＩＤを記憶する。ＤＢ管理部３１５は、デバイスＩＤ記憶部３１４に記憶されているデバイスＩＤと、監視部３１３による監視結果から、ＤＢ記憶部３１６に追加する情報を作成し、作成した情報をＤＢ記憶部３１６に書き込む。ＤＢ記憶部３１６は、図１に関して説明した履歴情報と追跡情報を含むＤＢを記憶する。
ＤＢの具体例は図６とともに後述するが、ＤＢに含まれる情報は、ファイル記憶部３１２に記憶されているファイルに関するメタデータの一種である。よって、以下では、ＤＢに含まれる情報をメタデータということもある。明らかに、追跡情報はメタデータの一例であり、履歴情報もメタデータの一例である。
なお、通信部３１１は、メタデータを受信して、受信したメタデータをＤＢ記憶部３１６に出力することもあるし、ＤＢ記憶部３１６内のメタデータを送信することもある。また、通信部３１１は、ファイルを受信して、受信したファイルをファイル記憶部３１２に記憶することもあるし、ファイル記憶部３１２に記憶されているファイルを送信することもある。
さて、端末３３０も端末３１０と同様に、通信部３３１と、ファイル記憶部３３２と、監視部３３３と、デバイスＩＤ記憶部３３４と、ＤＢ管理部３３５と、ＤＢ記憶部３３６を有する。通信部３３１、ファイル記憶部３３２、監視部３３３、デバイスＩＤ記憶部３３４、ＤＢ管理部３３５、およびＤＢ記憶部３３６の詳細は、端末３１０と同様なので説明を省略する。なお、ＤＢ記憶部３３６が記憶するＤＢの具体例は、図７とともに後述する。
また、第２実施形態では、端末３３０がバックアップを制御するので、端末３３０はさらに、優先度算出部３３７と、バックアップ記憶部３３８と、バックアップ制御部３３９を有する。
優先度算出部３３７は、ＤＢ記憶部３３６に記憶されているＤＢ（具体的には、取得済みの履歴情報と追跡情報を含むＤＢ）を使って、図１のステップＳ３〜Ｓ５と同様の方法により、各ファイルの優先度を算出する。ユーザが端末３１０と端末３３０の２台の端末を使う場合、優先度算出部３３７が優先度を算出する対象のファイルは、具体的には以下のファイルを含む。
・端末３１０のファイル記憶部３１２に記憶されている複数個のファイル。
・端末３３０のファイル記憶部３３２に記憶されている複数個のファイル。
バックアップ制御部３３９は、優先度算出部３３７の算出した優先度を使って、図１のステップＳ６〜Ｓ７と同様にして、バックアップ対象のファイルを選ぶ。そして、バックアップ制御部３３９は、選んだ各ファイルをバックアップ記憶部３３８にバックアップする。バックアップ制御部３３９は、優先度に応じてバックアップ対象の１個以上のファイルを選ぶ選択部の一例である。
例えば、説明の便宜上、バックアップ制御部３３９が、ファイル記憶部３１２に記憶されているファイルのうちの５００個と、ファイル記憶部３３２に記憶されているファイルのうちの１０００個をバックアップすることに決めたとする。この場合、バックアップ制御部３３９は、上記５００個のファイルを送信するよう、通信部３３１とネットワーク３７０を介して端末３１０に要求し、上記５００個のファイルを、ネットワーク３７０と通信部３３１を介して受信する。そして、バックアップ制御部３３９は、受信した上記５００個のファイルを、バックアップ記憶部３３８にバックアップする。さらに、バックアップ制御部３３９は、上記１０００個のファイルをファイル記憶部３３２からバックアップ記憶部３３８へとバックアップする。もちろん、バックアップ制御部３３９がどういう順序で上記の合計１５００個のファイルをバックアップするのかは、実施形態に応じて任意に変更可能である。
さて、サーバ３５０は、通信部３５１と、ＤＢ記憶部３５２と、デバイス管理部３５３と、ＤＢ管理部３５４を有する。
通信部３５１は、ネットワーク３７０を介して端末３１０および３３０と通信する。具体的には、通信部３５１は、端末３１０からメタデータを受信する場合もあるし、端末３１０にメタデータを送信する場合もあるし、端末３３０からメタデータを受信する場合もあるし、端末３３０にメタデータを送信する場合もある。
ＤＢ記憶部３５２は、メタデータを含むＤＢ（つまり履歴情報と追跡情報を含むＤＢ）を記憶する。ＤＢの具体例は図８〜９とともに後述するが、第２実施形態では、ＤＢ記憶部３５２が、ユーザ別のＤＢを記憶する。
デバイス管理部３５３は、ユーザとデバイスとの対応関係を管理する。つまり、デバイス管理部３５３は、ユーザＩＤと、端末のデバイスＩＤとの対応関係を管理する。よって、デバイス管理部３５３は、デバイスＩＤから、当該デバイスＩＤに対応するユーザＩＤを得ることができる。ＤＢ管理部３５４は、デバイス管理部３５３が得たユーザＩＤに応じて、ＤＢ記憶部３５２上のどのユーザ用のＤＢを操作するのかを決定する。
ところで、端末３１０、端末３３０、サーバ３５０の各々は、図３の情報処理装置２００のように構成されてもよい。
例えば、通信部３１１は、ネットワーク通信装置２０３により実現されてもよい。ファイル記憶部３１２とデバイスＩＤ記憶部３１４とＤＢ記憶部３１６は、不揮発性記憶装置２０７により実現されてもよい。監視部３１３とＤＢ管理部３１５は、プログラムを実行するＣＰＵ２０１により実現されてもよい。
また、通信部３３１は、ネットワーク通信装置２０３により実現されてもよい。ファイル記憶部３３２とデバイスＩＤ記憶部３３４とＤＢ記憶部３３６は、不揮発性記憶装置２０７により実現されてもよい。監視部３３３とＤＢ管理部３３５と優先度算出部３３７とバックアップ制御部３３９は、プログラムを実行するＣＰＵ２０１により実現されてもよい。
バックアップ記憶部３３８は、不揮発性記憶装置２０７により実現されてもよい（例えば、端末３３０が図２のＰＣ１０６である場合、バックアップ記憶部３３８はＨＤＤ１０７であってもよい）。あるいは、バックアップ記憶部３３８は、図３のシリアル接続Ｉ／Ｆ回路２０４を介して接続された外部の記憶装置（例えば、図２のＨＤＤ１０８）により実現されてもよい。
また、通信部３５１はネットワーク通信装置２０３により実現されてもよく、ＤＢ記憶部３５２は不揮発性記憶装置２０７により実現されてもよい。デバイス管理部３５３は、後述のデバイス管理テーブル５２０を記憶する不揮発性記憶装置２０７と、デバイス管理テーブル５２０を用いた処理を実行するＣＰＵ２０１によって、実現されてもよい。ＤＢ管理部３５４は、プログラムを実行するＣＰＵ２０１により実現されてもよい。
続いて、第２実施形態における端末３１０、端末３３０、およびサーバ３５０の動作の概要について、図１と図５を参照して説明する。図１に関して説明したように、図１の処理を実行する情報処理装置は、複数台の端末のうちの１台でもよいし、複数台の端末のうちの少なくとも１台以上とネットワークを介して通信を行うコンピュータ（例えばサーバ３５０）であってもよい。第２実施形態では、図１の処理を実行する情報処理装置は、具体的には端末３３０である。
また、図１のステップＳ１とＳ２に関して説明したように、履歴情報と追跡情報を取得するための具体的手順は、実施形態に応じて様々である。
第２実施形態では、端末３３０が、履歴情報を生成することで履歴情報を取得することもあるし、追跡情報を生成することで追跡情報を取得することもある。また、端末３３０は、履歴情報をサーバ３５０から受信することで履歴情報を取得することもあるし、追跡情報をサーバ３５０から受信することで追跡情報を取得することもある。
また、サーバ３５０が端末３３０に送信する履歴情報は、具体的には、サーバ３５０が端末３１０から受信することにより取得した履歴情報であってもよい。また、サーバ３５０は、端末３１０からの履歴情報の通知と、端末３３０からの履歴情報の通知に基づいて追跡情報を生成することもある。サーバ３５０は、こうして生成した追跡情報を端末３３０に送信することがあり、その結果として、端末３３０が追跡情報を取得することもある。
以下、履歴情報と追跡情報を含むメタデータのやりとりの具体的な例について、図５を参照して説明する。図５は、第２実施形態の動作シーケンスの例を示す図である。
ステップＳ１０１で端末３１０がファイル４０１を作成する。例えば、端末３１０が入力装置２０５としてカメラを有する場合、ユーザが端末３１０を用いて写真を撮影することで、画像ファイルが新規に作成される。ファイル４０１はそのようにして作成される画像ファイルであってもよい。もちろん、ファイル４０１は、テキストファイルやスプレッドシートファイルなど、その他の種類のファイルであってもよい。作成されたファイル４０１は、ファイル記憶部３１２に記憶される。
また、監視部３１３は、ファイル４０１の作成を検出する。検出に応じて、ステップＳ１０２では、ＤＢ管理部３１５が、ファイル４０１の作成に関する履歴情報を含むメタデータ４０２を生成する。ＤＢ管理部３１５は、生成したメタデータ４０２を、ＤＢ記憶部３１６に記憶する。
さらに、ステップＳ１０３では、通信部３１１がメタデータ４０２をサーバ３５０に送信する。メタデータ４０２は、サーバ３５０の通信部３５１において受信される。
すると、ステップＳ１０４でデバイス管理部３５３が、メタデータ４０２の送信元の端末３１０のデバイスＩＤから、端末３１０のユーザを識別するユーザＩＤを求める。
そして、ステップＳ１０５では、得られたユーザＩＤにしたがって、ＤＢ記憶部３５２中の適宜のＤＢに、受信されたメタデータ４０２が書き込まれる。ステップＳ１０５でのＤＢの更新は、ＤＢ管理部３５４により制御される。
さらに、ステップＳ１０６では、メタデータ４０３が、通信部３５１から端末３３０へと送信され、端末３３０の通信部３３１で受信され、ＤＢ記憶部３３６に追加される。ファイル４０１は作成操作により新たに作成されたファイルなので、他のファイルとの間に親子関係はない。よって、メタデータ４０３は追跡情報を含んでおらず、実質的にはメタデータ４０２とメタデータ４０３は同じである。
以上のようにして、端末３３０は、ファイル４０１の作成に関する履歴情報を含むメタデータ４０３を取得することができる。また、端末３１０上でファイル４０１に対して編集、移動、変名などの操作が行われる可能性もある。端末３１０でファイル４０１に対して何らかの操作が行われると、ステップＳ１０２〜Ｓ１０６のシーケンスと類似のシーケンスにより、端末３３０は、行われた操作に関する履歴情報を含むメタデータを取得することができる。
なお、端末３１０内でファイル４０１がコピーされることもあり得る。コピー操作は複製操作の一種である。この場合、端末３３０は、コピー操作に関する履歴情報と、ファイル４０１（つまり親ファイル）と子ファイルの関係を示す追跡情報とを含むメタデータを、ステップＳ１０２〜Ｓ１０６のシーケンスと類似のシーケンスにより、取得する。
ところで、端末３１０と３３０のユーザは、端末間でファイルを複製することもあり得る。例えば、端末３１０のファイル記憶部３１２に記憶されている既存のファイル４０４が、ステップＳ１０７で、通信部３１１から送信される。ファイル４０４は、端末３３０の通信部３３１で受信され、ファイル記憶部３３２に保存される。
すると、監視部３３３は、ファイル４０４の受信と保存を検出する。検出に応じて、ステップＳ１０８では、ＤＢ管理部３３５が、ファイル４０４の受信と保存に関する履歴情報を含むメタデータ４０５を生成する。ＤＢ管理部３３５は、生成したメタデータ４０５を、ＤＢ記憶部３３６に記憶する。
さらに、ステップＳ１０９では、通信部３３１がメタデータ４０５をサーバ３５０に送信する。メタデータ４０５は、サーバ３５０の通信部３５１において受信される。
すると、ステップＳ１１０でデバイス管理部３５３が、メタデータ４０５の送信元の端末３１０のデバイスＩＤから、端末３１０のユーザを識別するユーザＩＤを求める。また、得られたユーザＩＤにしたがって、ＤＢ記憶部３５２中の適宜のＤＢに、受信されたメタデータ４０５が書き込まれる。
他方、端末３１０は、ステップＳ１０１の作成操作の後にステップＳ１０２とＳ１０３を実行したのと同様に、ステップＳ１０７の送信操作の後にはステップＳ１１１とＳ１１２を実行する。具体的には以下のとおりである。
監視部３１３が、ステップＳ１０７でのファイル４０４の送信を検出する。すると、検出に応じて、ステップＳ１１１でＤＢ管理部３１５が、ファイル４０４の送信に関する履歴情報を含むメタデータ４０６を生成する。ＤＢ管理部３１５は、生成したメタデータ４０６をＤＢ記憶部３１６に記憶する。
さらに、ステップＳ１１２では、通信部３１１がメタデータ４０６をサーバ３５０に送信する。メタデータ４０６は、サーバ３５０の通信部３５１において受信される。
すると、ステップＳ１１３でデバイス管理部３５３が、メタデータ４０６の送信元の端末３１０のデバイスＩＤから、端末３１０のユーザを識別するユーザＩＤを求める。そして、得られたユーザＩＤにしたがって、ＤＢ記憶部３５２中の適宜のＤＢに、受信されたメタデータ４０６が書き込まれる。このときのＤＢの更新も、ＤＢ管理部３５４により制御される。
さらに、ＤＢ管理部３５４は、ファイル４０４の端末３３０における受信を示すメタデータ４０５と、ファイル４０４の端末３１０からの送信を示すメタデータ４０６に基づいて、「ファイル４０４が端末３１０から端末３３０に複製された」と認識する。よって、ＤＢ管理部３５４は、端末３１０と３３０の間での複製操作に対応する追跡情報を含むメタデータ４０７を、ステップＳ１１３でさらに生成する。ＤＢ管理部３５４は、生成したメタデータ４０７をＤＢ記憶部３５２に追加する。
そして、ステップＳ１１４では、上記のような追跡情報を含むメタデータ４０７が、通信部３５１から、端末３１０と３３０の双方へ送信される。メタデータ４０７は、通信部３１１で受信されてＤＢ記憶部３１６に記憶されるとともに、通信部３３１で受信されてＤＢ記憶部３３６に記憶される。
なお、図５では図示の便宜上、ステップＳ１０８〜Ｓ１１０がステップＳ１１１〜Ｓ１１３よりも先に描かれている。しかし、場合によっては、サーバ３５０は、メタデータ４０６をメタデータ４０５よりも先に受信することもあり得る。
いずれにしろ、サーバ３５０は、メタデータ４０５とメタデータ４０６の双方を受信した後に、追跡情報を含むメタデータ４０７を生成する。そして、メタデータ４０７は端末３１０と３３０に送信される。図１の処理を実行する端末３３０は、以上のようにして、端末３１０と３３０の間で行われる複製操作についての追跡情報を取得することができる。
なお、ファイル記憶部３３２に記憶されているファイルが、端末３３０から端末３１０に送信される場合もあり得る。つまり、端末３３０から端末３１０にファイルが複製されることもあり得る。この場合も、サーバ３５０は、端末３３０からの通知（具体的には送信に関する履歴情報を含むメタデータ）と、端末３１０からの通知（具体的には受信に関する履歴情報を含むメタデータ）に基づいて、追跡情報を含むメタデータを生成することができる。よって、端末３３０は、追跡情報を含むメタデータをサーバ３５０から取得することができる。
さて、ステップＳ１１５では、ファイルをバックアップするためのトリガイベントが生じる。例えば、端末３３０の入力装置２０５を介して、ユーザから明示的にバックアップ開始が指示されることもある。また、バックアップスケジュールが予め決められている場合には、トリガイベントは、具体的には、「バックアップスケジュールにより決められた日時になった」というイベントである。
トリガイベントの発生に応じて、優先度算出部３３７は、端末３１０のファイル記憶部３１２に記憶されている各ファイルと、端末３３０のファイル記憶部３３２に記憶されている各ファイルについて、優先度４０８を算出する。つまり、優先度算出部３３７は、図１のステップＳ３〜Ｓ５と同様の処理を実行する。
そして、バックアップ制御部３３９は、算出された優先度４０８に応じて、バックアップ対象のファイルを選び、選んだ各ファイルをバックアップ記憶部３３８にバックアップする。
続いて、第２実施形態で使われる何種類かの情報の具体例について、図６〜９を参照して説明する。
図６は、第２実施形態において端末３１０のＤＢ記憶部３１６に記憶されるＤＢの例を示す図である。図６のＤＢ５００は、ＩＤテーブル５０１と、ＩＤテーブル５０１中の各エントリに対応する履歴テーブルと、追跡テーブル５０３を含む。図６には、履歴テーブルのうち、履歴テーブル５０２ａと５０２ｂのみが例示されている。
ＩＤテーブル５０１の各エントリは、１台の端末内の１個のファイルに対応する。ＩＤテーブル５０１の各エントリは、デバイスＩＤ、ファイルＩＤ、ファイル名、およびパスを含む。
例えば、図６の例では、端末３１０のデバイスＩＤは「ｍｏｂｉｌｅ−００１」である。ファイル記憶部３１２内のファイルに関するファイルＩＤは、具体的には、ファイル記憶部３１２上に新たなファイルが記憶されたことを監視部３１３が検出するたびに、ＤＢ管理部３１５が発行するシーケンス番号であってもよい。図６のＩＤテーブル５０１は、以下のことを示している。
・ファイル記憶部３１２において「／ｍｎｔ／ｄｏｃ／」というパスで識別されるディレクトリにある、「ｔｅｓｔ．ｔｘｔ」というファイル名のファイルには、「１５０」というファイルＩＤが割り当てられている。
・ファイル記憶部３１２において「／ｍｎｔ／ｐｉｃｔ／２０１２０３０６／」というパスで識別されるディレクトリにある、「２０１３．ｊｐｇ」というファイル名のファイルには、「１３」というファイルＩＤが割り当てられている。
・ファイル記憶部３１２において「／ｍｎｔ／ｐｉｃｔ／ｆａｖｏｒｉｔｅ／」というパスで識別されるディレクトリにある、「２０１３．ｊｐｇ」というファイル名のファイルには、「２１０」というファイルＩＤが割り当てられている。
さて、履歴テーブル５０２ａは、「１３」というファイルＩＤのファイルに対応する。つまり、履歴テーブル５０２ａの各エントリは、「１３」というファイルＩＤのファイルに対して行われた１つの操作に対応する履歴情報である。履歴テーブル５０２ａの各エントリは、日時、利用時間、ログ種別、およびユニーク値を含む。
ユニーク値は、ファイルに対して一意に決まる値（つまりファイルに固有の値）であり、ファイルの内容を要約する（digest）値である。このように、履歴情報は、単に操作の種類（つまりログ種別）を示すだけでなく、操作が行われた時点、操作にかかった時間、操作対象のファイルに対して一意に決まる値をさらに含んでもよい。なお、ログ種別によっては、利用時間の値は省略されてもよい。
なお、ユニーク値は、具体的には、ファイルのハッシュ値であってもよい。例えば、ユニーク値は、ＭＤ５（Message Digest Algorithm 5）などのハッシュ関数により算出される値であってもよい。また、ユニーク値の算出に、ファイル自体のデータのみが使われてもよいし、ファイル名、パス、またはその双方がさらに使われてもよい。以下では説明の簡単化のため、ユニーク値同士の衝突（collision）は無視しても差し支えないものとする。
履歴テーブル５０２ａは、具体的には以下のことを示す。
・「１３」というファイルＩＤのファイルは、２０１２年３月６日８時２０分に端末３１０上で作成された。
・このファイルから算出されたユニーク値は「６５６１５１６３」である。
・このファイルは、２０１２年３月６日８時２１分にＰＣ（具体的には端末３３０）に送信された。
・このファイルは、２０１２年３月６日８時２３分から３０分間、端末３１０上で閲覧された。
・このファイルは、閲覧されている最中の２０１２年３月６日８時２５分に、端末３１０上でコピーされた。具体的には、このファイルは、「．．／ｆａｖｏｒｉｔｅ／」という相対パスで識別されるディレクトリにコピーされた。
・送信・閲覧・コピーによってファイルが変化することはないので、ユニーク値は「６５６１５１６３」のままである。
なお、図６では便宜上、相対パスが例示されているが、絶対パスが使われてもよい。
さて、「１３」というファイルＩＤのファイルに対する上記コピー操作により得られたファイルは、「２１０」というファイルＩＤのファイルである。図６には、「２１０」というファイルＩＤのファイルに対応する履歴テーブル５０２ｂも示されている。履歴テーブル５０２ｂの形式は、履歴テーブル５０２ａと同様である。履歴テーブル５０２ｂは、具体的には以下のことを示す。
・「２１０」というファイルＩＤのファイルは、２０１２年３月６日８時２５分に、他のファイルをコピーすることにより得られた。具体的には、「２１０」というファイルＩＤのファイルは、「．．／２０１２０３０６」という相対パスで識別されるディレクトリのファイルをコピーすることで得られた。
・「２１０」というファイルＩＤのファイルのユニーク値は、複製元のファイルと同じく、「６５６１５１６３」である。
・「２１０」というファイルＩＤのファイルは、２０１２年３月６日８時３０分から４５分間かけて、端末３１０上で編集された。
・編集によりファイルのデータが変化したので、ユニーク値も「１６１５３３２１」に変化した。
・２０１２年３月７日９時３１分から１時間かけて、端末３１０上でこのファイルにコメントが付加された。例えば、ユーザは、コメントを付加する機能を持つアプリケーションを使って、このファイルにコメントを付加してもよい。
・コメントの付加によりファイルのデータが変化したので、ユニーク値も「９７４８８４７５」に変化した。
・このファイルは、２０１２年３月７日１０時４５分にウェブサービスに投稿（submit）された。つまり、このファイルは、ブログサービス、ソーシャルネットワーキングサービス、ファイル共有サービスなど、何らかの種類のウェブサービスのサーバにアップロードされた。
・ウェブサービスへの投稿によってファイルが変化することはないので、ユニーク値は「９７４８８４７５」のままである。
さて、追跡テーブル５０３の各エントリは、１つの親ファイルと１つの子ファイルとの関係を示す追跡情報に相当する。図６には追跡テーブル５０３中の２つのエントリが例示されている。追跡テーブル５０３の各エントリは、親デバイスＩＤと、親ファイルＩＤと、子デバイスＩＤと、子ファイルＩＤを含む。
親デバイスＩＤは、親ファイルを記憶している端末のデバイスＩＤである。親ファイルＩＤは、親ファイルを記憶している端末が親ファイルに対して割り当てたファイルＩＤである。親デバイスＩＤと親ファイルＩＤの組み合わせにより、親ファイルが識別される。
他方、子デバイスＩＤは、子ファイルを記憶している端末のデバイスＩＤである。子ファイルＩＤは、子ファイルを記憶している端末が子ファイルに対して割り当てたファイルＩＤである。子デバイスＩＤと子ファイルＩＤの組み合わせにより、子ファイルが識別される。
したがって、１台の端末内での複製操作により生じた親子関係を示すエントリにおいては、親デバイスＩＤと子デバイスＩＤが等しい。逆に、端末間または端末・サーバ間での複製操作により生じた親子関係を示すエントリにおいては、親デバイスＩＤと子デバイスＩＤが異なる。ただし、説明の簡単化のため、第２実施形態では、端末・サーバ間での複製操作は行われないものとする。端末・サーバ間での複製操作の具体例については、第３実施形態とともに後述する。
具体的には、追跡テーブル５０３は、以下のことを示す。
・「ｍｏｂｉｌｅ−００１」というデバイスＩＤの端末（具体的には端末３１０）において「１３」というファイルＩＤを持つファイルが、「ＰＣ−００２」というデバイスＩＤの端末（具体的には端末３３０）に複製された。そして、複製操作（具体的には、端末３１０からの送信と、端末３３０での受信および保存による複製）によって、端末３３０上に作られたファイルには、「８３」というファイルＩＤが割り当てられた。
・つまり、「ｍｏｂｉｌｅ−００１」というデバイスＩＤと「１３」というファイルＩＤのペアにより識別されるファイルは、「ＰＣ−００２」というデバイスＩＤと「８３」というファイルＩＤのペアにより識別されるファイルの親ファイルである。
・「ｍｏｂｉｌｅ−００１」というデバイスＩＤの端末（具体的には端末３１０）内で、「１３」というファイルＩＤを持つファイルが複製された（具体的には、端末３１０内でコピーされた）。そして、コピー操作の結果として端末３１０上に作られた新たなファイルには、「２１０」というＩＤが割り当てられた。
・つまり、「ｍｏｂｉｌｅ−００１」というデバイスＩＤと「１３」というファイルＩＤのペアにより識別されるファイルは、「ｍｏｂｉｌｅ−００１」というデバイスＩＤと「２１０」というファイルＩＤのペアにより識別されるファイルの親ファイルでもある。
さて、図７は、第２実施形態において端末３３０のＤＢ記憶部３３６に記憶されるＤＢの例を示す図である。図７のＤＢ５１０は、ＩＤテーブル５１１と、ＩＤテーブル５１１中の各エントリに対応する履歴テーブルと、追跡テーブル５１３を含む。図７には、履歴テーブルのうち、履歴テーブル５１２ａと５１２ｂのみが例示されている。
ＩＤテーブル５１１の形式は、図６のＩＤテーブル５０１と同様である。図７には、端末３３０のファイル記憶部３３２内に記憶されている２つのファイルに関する２つのエントリと、端末３１０のファイル記憶部３１２内に記憶されている１つのファイルに関する１つのエントリ（図６にも例示されているもの）が例示されている。図７では省略されているが、図６のＩＤテーブル５０１に例示されている残りの２つのエントリと同じエントリも、ＩＤテーブル５１１には含まれる。
上記のとおり、「ｍｏｂｉｌｅ−００１」は端末３１０のデバイスＩＤであり、「ＰＣ−００２」は端末３３０のデバイスＩＤである。よって、ＩＤテーブル５１１は以下のことを示す。
・端末３３０のファイル記憶部３３２において「Ｄ：＼ｄｏｃ＼」というパスで識別されるディレクトリにある、「ｔｅｓｔ．ｔｘｔ」というファイル名のファイルには、「３５１」というファイルＩＤが割り当てられている。
・端末３３０のファイル記憶部３３２において「Ｄ：＼ｔｅｍｐ＼」というパスで識別されるディレクトリにある、「ｓｎｏｗ＿０３０６．ｊｐｇ」というファイル名のファイルには、「８３」というファイルＩＤが割り当てられている。
・端末３１０のファイル記憶部３１２において「／ｍｎｔ／ｐｉｃｔ／ｆａｖｏｒｉｔｅ／」というパスで識別されるディレクトリにある、「２０１３．ｊｐｇ」というファイル名のファイルには、「２１０」というファイルＩＤが割り当てられている。
さて、履歴テーブル５１２ａは、端末３３０内で「８３」というファイルＩＤにより識別されるファイルに対応する。履歴テーブル５１２ａの各エントリは、当該ファイルに対して行われた１つの操作に対応する履歴情報である。履歴テーブル５１２ａは、具体的には以下のことを示す。
・２０１２年３月６日８時２１分にスマートフォン（具体的には端末３１０）からファイルが受信され、受信されたファイルがファイル記憶部３３２に記憶され、記憶されたファイルに対して、「８３」というファイルＩＤが割り当てられた。
・このファイルのユニーク値は、図６の履歴テーブル５０２ａからも分かるとおり、「６５６１５１６３」である。
・以上のようにしてファイル記憶部３３２に記憶されたこのファイルは、２０１２年３月６日２０時１５分から１時間２０分かけて、端末３３０上で編集された。
・編集によりファイルのデータが変化したので、ユニーク値も「１２３４５６７８」に変化した。
・編集後、２０１２年３月６日２１時３７分に、このファイルは、「ｓｎｏｗ＿０３０６．ｊｐｇ」というファイル名へとリネームされた。リネーム後の新たなファイル名がＩＤテーブル５１１には記録されている。
・図７の例では、ユニーク値がファイル名にも依存するものとする。したがって、ファイルをリネームするとユニーク値も変化する。具体的には、２０１２年３月６日２１時３７分のリネームの結果、ユニーク値は「８７６５４３２１」に変化した。
さて、図７には履歴テーブル５１２ｂと追跡テーブル５１３も例示されている。履歴テーブル５１２ｂは図６の履歴テーブル５０２ｂと同じであり、追跡テーブル５１３は図６の追跡テーブル５０３と同じなので、詳しい説明は省略する。
なお、図６では省略されているが、図７で例示されているＩＤテーブル５１１中の１番目と２番目のエントリは、図６のＩＤテーブル５０１にも含まれる。よって、端末３１０も、図７の履歴テーブル５１２ａと同じテーブルを有する。同様に、端末３３０も、図６の履歴テーブル５０２ａと同じテーブルを有する。
図８は、第２実施形態においてサーバ３５０に記憶されている情報の概要を例示する図である。図８には、デバイス管理部３５３が管理するデバイス管理テーブル５２０と、ＤＢ記憶部３５２に記憶されるユーザ別のＤＢ５３０−１〜５３０−Ｕが例示されている。なお、Ｕは１以上の整数である。
デバイス管理テーブル５２０の各エントリは、１台の端末に対応する。デバイス管理テーブル５２０の各エントリは、ユーザＩＤとデバイスＩＤを含む。デバイス管理テーブル５２０は、以下のことを示す。
・「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザは、「ｍｏｂｉｌｅ−００１」というデバイスＩＤの端末を使う。
・このユーザは、「ＰＣ−００２」というデバイスＩＤの端末も使う。
・つまり、このユーザは、端末３１０と３３０を使う。
・「ｓａｔｏ＿ｊｉｒｏ」というユーザＩＤのユーザは、「ｐａｄ−１２３」というデバイスＩＤの端末を使う。
例えば、バックアップ対象のファイルの自動選別を望むユーザは、自分が使う各端末をサーバ３５０に登録する操作をまず行ってもよい。そして、デバイス管理部３５３は、登録の際に、システム３００内で一意のデバイスＩＤを新たに生成して、生成したデバイスＩＤを端末に割り当ててもよい。あるいは、既存の情報（例えば、端末の製造ベンダ・機種名・製造シリアル番号の組み合わせにより示される識別子など）が、デバイスＩＤとして使われてもよい。いずれにせよ、端末３１０のデバイスＩＤは、デバイスＩＤ記憶部３１４に記憶され、端末３３０のデバイスＩＤはデバイスＩＤ記憶部３３４に記憶される。
デバイス管理テーブル５２０は、ユーザＩＤとデバイスＩＤに加えて、さらに他のフィールドを含んでいてもよい。例えば、端末３１０に対応する１番目のエントリには、以下のようなフィールドが含まれていてもよい。他のエントリについても同様である。
・端末３１０で使われる電子メールアドレスを表すフィールド。
・端末３１０と３３０の間での同期をサポートする特定のアプリケーションが端末３１０にインストールされている場合、当該アプリケーションにおいて端末３１０を識別するために用いられるＩＤを表すフィールド。
ＤＢ５３０−１は、１番目のユーザ（具体的には「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザ）用のＤＢである。ＤＢ５３０−１の詳細は、図９に例示する。ＤＢ５３０−２は、２番目のユーザ（具体的には「ｓａｔｏ＿ｊｉｒｏ」というユーザＩＤのユーザ）用のＤＢである。ＤＢ５３０−Ｕは、Ｕ番目のユーザ用のＤＢである。
図９は、第２実施形態においてサーバ３５０に記憶されるＤＢ５３０−１の例の詳細を示す図である。図９に示すとおり、ＤＢ５３０−１は、ＩＤテーブル５３１と、ＩＤテーブル５３１中の各エントリに対応する履歴テーブルと、追跡テーブル５３３を含む。図９には、履歴テーブルのうち、履歴テーブル５３２ａと５３２ｂのみが例示されている。
ＩＤテーブル５３１の形式は、図６のＩＤテーブル５０１と同様である。図９では、図７でＩＤテーブル５１１中に例示した３つのエントリと同じ３つのエントリのみが、ＩＤテーブル５３１に関して例示されている。図９では省略されているが、図６のＩＤテーブル５０１中に例示した１番目と２番目のエントリと同じエントリも、ＩＤテーブル５３１には含まれる。
履歴テーブル５３２ａは、「ＰＣ−００２」というデバイスＩＤを持つ端末３３０内において「８３」というファイルＩＤにより識別されるファイルに対応する。履歴テーブル５３２ａは、図７の履歴テーブル５１２ａと同じである。
履歴テーブル５３２ｂは、「ｍｏｂｉｌｅ−００１」というデバイスＩＤを持つ端末３１０において「２１０」というファイルＩＤにより識別されるファイルに対応する。履歴テーブル５３２ｂは、図６の履歴テーブル５０２ｂと同じである。
また、追跡テーブル５３３は、図６の追跡テーブル５０３と同じである。
以上、図６〜９を参照して説明したように、第２実施形態では、ＤＢ記憶部３１６とＤＢ記憶部３３６とＤＢ記憶部３５２が重複して同様のＤＢを保持する。しかし、実施形態によっては、ＤＢは必ずしも冗長化されていなくてもよい。ＤＢを冗長化しない変形例については後述する。
続いて、図１０〜１５を参照して、第２実施形態において端末３１０と端末３３０とサーバ３５０が行う処理について詳しく説明する。
図１０は、第２実施形態で端末３１０が行う処理のフローチャートである。ある観点から言えば、図１０の処理は、端末３３０（すなわち優先度の算出を行う情報処理装置）が履歴情報と追跡情報を取得することができるようにするための処理である。端末３１０の電源がオンにされると、端末３１０は図１０の処理を開始する。
ステップＳ２０１でＤＢ管理部３１５は、「ファイル記憶部３１２に記憶されているファイルが、通信部３１１から送信された」というイベントが監視部３１３により検出されたか否かを判断する。そのようなイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部３１３からＤＢ管理部３１５に出力された場合）、図１０の処理はステップＳ２０２に移行する。逆に、そのようなイベントが検出されていなければ、図１０の処理はステップＳ２０５に移行する。
ステップＳ２０２でＤＢ管理部３１５は、監視部３１３からＤＢ管理部３１５へ出力される監視結果から、ファイルの送信先などの情報を抽出する。例えば、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが送信されたことを示す情報（例えば「送信」を示すコードなど）。
・送信操作が行われた日時。
・送信されたファイルが置かれている（located）ディレクトリのパスと、当該ファイルのファイル名。
・送信先の端末を示す送信先情報（例えば、端末の名前、デバイスＩＤ、送信先の端末で使われる電子メールアドレスなど）。
ＤＢ管理部３１５は、監視結果から日時と送信先情報を抽出する。また、ＤＢ管理部３１５は、デバイスＩＤ記憶部３１４に記憶されているデバイスＩＤと、ディレクトリのパスと、ファイル名とを検索キーとして使って、ＩＤテーブル５０１を参照し、ファイルＩＤを取得する。また、ＤＢ管理部３１５は、上記のパスとファイル名により識別されるファイルから、当該ファイルのユニーク値を算出する。
そして、次のステップＳ２０３でＤＢ管理部３１５は、抽出済みの情報を使ってＤＢ５００を更新する。さらに、次のステップＳ２０４では、ステップＳ２０３での更新に応じて、１つ以上のテーブルそれぞれの一部または全部が、通信部３１１からネットワーク３７０を介してサーバ３５０へと送信される。なお、図１０に示すとおり、ステップＳ２０３は、ステップＳ２０２、Ｓ２０６、Ｓ２０８またはＳ２１１の後に実行される。よって、「ステップＳ２０３でどのテーブルが更新され、ステップＳ２０４でどのテーブル（の一部または全部）が送信されるのか」ということは、場合による。
例えば、ステップＳ２０２の後にステップＳ２０３が実行される場合、ＤＢ管理部３１５は、送信されたファイルに対応する履歴テーブルに、ステップＳ２０３で新規エントリを追加する。例えば、図６の履歴テーブル５０２ａの２番目のエントリは、ステップＳ２０２で抽出された情報に基づいて、ＤＢ管理部３１５によってステップＳ２０３で追加されるエントリの一例である。
また、ステップＳ２０２の後にステップＳ２０３が実行される場合、ステップＳ２０４では、ステップＳ２０３で履歴テーブルに追加されたエントリと、当該履歴テーブルに対応するファイルＩＤが送信されてもよい。あるいは、ステップＳ２０４では、当該履歴テーブルの全体が、当該履歴テーブルに対応するファイルＩＤとともに送信されてもよい。図５のステップＳ１１２は、ステップＳ２０２の後に実行されるステップＳ２０４の例である。
ステップＳ２０４での送信の後、図１０の処理はステップＳ２０１に戻る。
さて、ステップＳ２０５でＤＢ管理部３１５は、「ファイル記憶部３１２に記憶されているファイルが、変更、移動、変名、または削除された」というイベントが監視部３１３により検出されたか否かを判断する。そのようなイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部３１３からＤＢ管理部３１５に出力された場合）、図１０の処理はステップＳ２０６に移行する。逆に、そのようなイベントが検出されていなければ、図１０の処理はステップＳ２０７に移行する。
ステップＳ２０６でＤＢ管理部３１５は、監視部３１３からＤＢ管理部３１５へ出力される監視結果から、操作が行われたファイルに関するパスなどの情報を抽出する。
例えば、あるファイルが変更された場合（例えば、ユーザがアプリケーションを利用してファイルを編集したりファイルにコメントを付加したりした場合）、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが変更されたことを示す情報（例えば「変更」を示すコードなどでもよいし、より細分化された「編集」や「コメント付加」などの種別を示すコードなどでもよい）。
・変更されたファイルが置かれているディレクトリのパス。
・変更されたファイルのファイル名。
・監視部３１３が、ファイルの変更にかかった時間も検出可能な場合は、ファイルの変更が開始された日時と、ファイルの変更にかかった時間。
・監視部３１３が、ファイルの変更にかかった時間を検出しない場合は、変更されたファイルが保存された日時。
また、あるファイルが、あるディレクトリから別のディレクトリへと移動された場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが移動されたことを示す情報（例えば「移動」を示すコードなど）。
・移動される前にファイルが置かれていたディレクトリのパス。
・ファイルが移動された先のディレクトリのパス。
・移動されたファイルのファイル名。
・移動操作が行われた日時。
また、あるファイルが変名された場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが変名されたことを示す情報（例えば「変名」を示すコードなど）。
・変名される前のファイル名。
・変名後のファイル名。
・変名操作が行われた日時。
なお、ある種のコマンドの実行によって、ファイルの移動と変名が同時に行われることもある。その場合も、監視部３１３は適宜の監視結果を出力する。
また、あるファイルが削除された場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが削除されたことを示す情報（例えば「削除」を示すコードなど）。
・削除されたファイルが今まで置かれていたディレクトリのパス。
・削除されたファイルのファイル名。
以上例示したように、監視部３１３は、変更、移動、変名、削除といった操作の種類に応じて、適宜の監視結果を出力する。よって、ステップＳ２０６でＤＢ管理部３１５は、出力された監視結果から、パスなどの適宜の情報を抽出することができる。
また、ＤＢ管理部３１５は、デバイスＩＤ記憶部３１４に記憶されているデバイスＩＤと、監視結果から得られるパスおよびファイル名を検索キーとして用いて、ＩＤテーブル５０１を参照することで、ファイルＩＤを抽出することができる。さらに、ＤＢ管理部３１５は、変更、移動、または変名されたファイルから、ユニーク値を算出する。その後、図１０の処理はステップＳ２０３に移行する。
以上のようにしてステップＳ２０６の後にステップＳ２０３が実行される場合、ステップＳ２０３とＳ２０４では、具体的には以下のような処理が行われる。
例えば、あるファイルが変更された場合、ＤＢ管理部３１５は、変更されたファイルに対応する履歴テーブルに、ステップＳ２０３で新規エントリを追加する。例えば、図６の履歴テーブル５０２ｂの２番目と３番目のエントリは、ステップＳ２０６の後のステップＳ２０３で追加されるエントリの例である。そして、ステップＳ２０４では、ステップＳ２０３で履歴テーブルに追加されたエントリ（または当該履歴テーブルの全体）と、当該履歴テーブルに対応するファイルＩＤが送信される。
また、あるファイルが移動された場合、ＤＢ管理部３１５は、ＩＤテーブル５０１において、移動された当該ファイルに対応するエントリをステップＳ２０３で更新する。具体的には、ＤＢ管理部３１５は、当該エントリのパスを書き換える。さらに、ＤＢ管理部３１５は、移動されたファイルに対応する履歴テーブルに、ステップＳ２０３で新規エントリを追加する。そして、ステップＳ２０４では、ＩＤテーブル５０１中の書き換えられたエントリと、当該エントリに対応する履歴テーブルに追加されたエントリ（または当該履歴テーブルの全体）が送信される。
また、あるファイルが変名された場合、ＤＢ管理部３１５は、ＩＤテーブル５０１において、変名された当該ファイルに対応するエントリをステップＳ２０３で更新する。具体的には、ＤＢ管理部３１５は、当該エントリのファイル名を書き換える。さらに、ＤＢ管理部３１５は、変名されたファイルに対応する履歴テーブルに、ステップＳ２０３で新規エントリを追加する。そして、ステップＳ２０４では、ＩＤテーブル５０１中の書き換えられたエントリと、当該エントリに対応する履歴テーブルに追加されたエントリ（または当該履歴テーブルの全体）が送信される。
また、あるファイルが削除された場合、ＤＢ管理部３１５は、削除されたファイルに対応する履歴テーブルを、ステップＳ２０３でＤＢ５００から削除する。そして、ステップＳ２０４では、削除されたファイルに対応する、ＩＤテーブル５０１中のエントリが、ファイルの削除を示す情報とともに送信される。
さて、ステップＳ２０７でＤＢ管理部３１５は、「ファイル記憶部３１２に記憶されている既存のファイルに対して、変更、移動、変名、削除、コピー以外の他の操作が行われた」というイベントが監視部３１３により検出されたか否かを判断する。そのようなイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部３１３からＤＢ管理部３１５に出力された場合）、図１０の処理はステップＳ２０８に移行する。逆に、そのようなイベントが検出されていなければ、図１０の処理はステップＳ２０９に移行する。具体的には、例えば、ファイルの閲覧操作が検出されると、図１０の処理はステップＳ２０７からＳ２０８へと移行する。
例えば、監視部３１３は、ファイルを開くためのシステムコールと、ファイルにデータを書き込むためのシステムコールと、ファイルを閉じるためのシステムコールを監視してもよい。そして、ファイルが開かれた後、何もファイルに書き込まれずにファイルが閉じられた場合、監視部３１３は、閲覧操作を検出してもよい。逆に、ファイルが開かれた後、何らかのデータがファイルに書き込まれ、その後にファイルが閉じられた場合、監視部３１３は変更操作（例えば編集操作）を検出してもよい。
さて、ステップＳ２０８でＤＢ管理部３１５は、監視部３１３からＤＢ管理部３１５へ出力される監視結果から、操作種別などの情報を抽出する。
例えば、あるファイルが閲覧されたことを監視部３１３が上記のようにして検出した場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが閲覧されたことを示す情報（例えば「閲覧」を示すコードなど）。
・閲覧されたファイルが置かれているディレクトリのパス。
・閲覧されたファイルのファイル名。
・ファイルの閲覧にかかった時間（つまりファイルが開かれてから閉じられるまでの時間）。
・閲覧操作が開始された日時（つまりファイルが開かれた日時）。
すると、ＤＢ管理部３１５は、「閲覧」という種別と、閲覧にかかった時間と、閲覧操作が開始された日時を監視結果から抽出することができる。また、ＤＢ管理部３１５は、デバイスＩＤ記憶部３１４に記憶されているデバイスＩＤと、監視結果から得られるパスおよびファイル名を、検索キーとして用いてＩＤテーブル５０１を参照することで、ファイルＩＤを抽出することができる。また、ＤＢ管理部３１５は、閲覧されたファイルから、ユニーク値を算出する。その後、図１０の処理はステップＳ２０３に移行する。
以上のようにしてステップＳ２０８の後にステップＳ２０３が実行される場合、ステップＳ２０３とＳ２０４では、具体的には以下のような処理が行われる。
例えば、あるファイルが閲覧された場合、ＤＢ管理部３１５は、閲覧されたファイルに対応する履歴テーブルに、ステップＳ２０３で新規エントリを追加する。例えば、図６の履歴テーブル５０２ａの３番目のエントリは、ステップＳ２０８の後のステップＳ２０３で追加されるエントリの例である。そして、ステップＳ２０４では、ステップＳ２０３で履歴テーブルに追加されたエントリ（または当該履歴テーブルの全体）と、当該履歴テーブルに対応するファイルＩＤが送信される。
さて、テップＳ２０９でＤＢ管理部３１５は、「ファイル記憶部３１２に新たなファイルが１つ増えた」というイベントが監視部３１３により検出されたか否かを判断する。より具体的には、ＤＢ管理部３１５は、以下の３種類のイベントのいずれかが検出されたか否かを判断する。
・「端末３１０内でファイルが新規作成された」というイベント。
・「ファイル記憶部３１２内の既存のファイルがコピーされた」というイベント。
・「ファイルが、通信部３１１を介して受信されて、ファイル記憶部３１２に記憶された」というイベント。
上記３種類のイベントのうちのいずれかが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部３１３からＤＢ管理部３１５に出力された場合）、図１０の処理はステップＳ２１０に移行する。逆に、上記３種類のイベントがいずれも検出されていなければ、図１０の処理はステップＳ２１２に移行する。
ステップＳ２１０でＤＢ管理部３１５は、新たなファイルＩＤを発行する。例えば、シーケンス番号がファイルＩＤとして使われる場合、ＤＢ管理部３１５は、カウンタをインクリメントすることで、新たなファイルＩＤを取得してもよい。そして、ＤＢ管理部３１５は、取得した新たなファイルＩＤを、新たなファイルに割り当ててもよい。
次に、ステップＳ２１１でＤＢ管理部３１５は、監視部３１３からＤＢ管理部３１５へ出力される監視結果から、新たなファイルに関するパスなどの情報を抽出する。
例えば、端末３１０内でファイルが新規作成された場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが作成されたことを示す情報（例えば「作成」を示すコードなど）。
・作成された新たなファイルが保存されたディレクトリのパス。
・作成された新たなファイルのファイル名。
・ファイルがファイル記憶部３１２上に作成された日時。
また、ファイル記憶部３１２内の既存のファイルがコピーされた場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルがコピーされたことを示す情報（例えば「コピー」を示すコードなど）。
・コピー操作が行われた既存ファイルが置かれているディレクトリのパス。
・当該既存ファイルのファイル名。
・コピー操作により新たに作られたファイルが保存されたディレクトリのパス。
・当該新たなファイルのファイル名。
・コピー操作が行われた日時。
また、ファイルが、通信部３１１を介して受信されて、ファイル記憶部３１２に記憶された場合、監視部３１３は、以下のような項目を含む監視結果を出力してもよい。
・ファイルが受信されたことを示す情報（例えば「受信」を示すコードなど）。
・受信されたファイルが保存されたディレクトリのパス。
・受信されて新たに保存されたファイルのファイル名。
・受信されたファイルがファイル記憶部３１２上に保存された日時。
・ファイルの送信元を示す送信元情報（例えば、端末の名前、デバイスＩＤ、送信元の端末で使われる電子メールアドレスなど）。
以上例示したように、監視部３１３は、操作の種類に応じて適宜の監視結果を出力する。よって、ステップＳ２１１でＤＢ管理部３１５は、出力された監視結果から、パスなどの適宜の情報を抽出することができる。さらに、ＤＢ管理部３１５は、新たなファイルからユニーク値を算出する。その後、図１０の処理はステップＳ２０３に移行する。
以上のようにしてステップＳ２１１の後にステップＳ２０３が実行される場合、ステップＳ２０３とＳ２０４では、具体的には以下のような処理が行われる。
作成操作、コピー操作、受信操作のいずれが検出された場合においても、ＤＢ管理部３１５は、ステップＳ２０３でＩＤテーブル５０１に新規エントリを追加する。具体的には、新規エントリの各フィールドには以下の値が設定される。
・デバイスＩＤ記憶部３１４から読み取った、端末３１０のデバイスＩＤ。
・ステップＳ２１０で発行した新たなファイルＩＤ。
・ステップＳ２１１で抽出したパス。
・ステップＳ２１１で抽出したファイル名。
さらに、ステップＳ２０３でＤＢ管理部３１５は、ＩＤテーブル５０１に追加した新規エントリに対応する新たな履歴テーブルを作成する。そして、ＤＢ管理部３１５は、作成した新たな履歴テーブルに新規エントリを追加する。新規エントリには、ステップＳ２１１で抽出された情報が設定される。
例えば、図６の履歴テーブル５０２ａは、ファイルが端末３１０内で新規作成されて、当該ファイルに対してステップＳ２１０で「１３」というファイルＩＤが割り当てられた後に、ステップＳ２０３で作成されたテーブルである。履歴テーブル５０２ａの１番目のエントリは、履歴テーブル５０２ａが作成されたときにステップＳ２０３で追加されたエントリである。
また、履歴テーブル５０２ｂは、「１３」というファイルＩＤのファイルがコピーされて、コピー操作により作られた新たなファイルに対してステップＳ２１０で「２１０」というファイルＩＤが割り当てられた後、ステップＳ２０３で作成されたテーブルである。履歴テーブル５０２ｂの１番目のエントリは、履歴テーブル５０２ｂが作成されたときにステップＳ２０３で追加されたエントリである。
さらに、検出された操作がコピー操作である場合、ステップＳ２０３でＤＢ管理部３１５は、コピー元のファイルに対応する履歴テーブルにも新規エントリを追加する。新規エントリには、ステップＳ２１１で抽出された情報が設定される。この場合、ステップＳ２０３でＤＢ管理部３１５は、さらに、コピー操作によって生じたファイル間の親子関係を示すエントリを追跡テーブル５０３に追加する
例えば、図６の履歴テーブル５０２ａの４番目のエントリは、履歴テーブル５０２ｂが作成されたのと同じステップＳ２０３において、追加されたエントリである。また、図６の追跡テーブル５０３の２番目のエントリも、履歴テーブル５０２ｂが作成されたのと同じステップＳ２０３において、追加されたエントリである。
そして、ステップＳ２１１の後にステップＳ２０３が実行される場合、ステップＳ２０４では、少なくとも、ＩＤテーブル５０１に追加されたエントリと、新たに作成された履歴テーブルが送信される。コピー操作が行われた場合には、ステップＳ２０４でさらに、コピー元のファイルに対応するＩＤテーブル５０１中のエントリと、コピー元のファイルに対応する履歴テーブルに追加されたエントリと、追跡テーブル５０３に追加された新たなエントリも送信される。
さて、ステップＳ２１２でＤＢ管理部３１５は、「ＤＢ５００に追加するためのテーブルの一部または全部を、サーバ３５０から通信部３１１が受信した」というイベントが監視部３１３により検出されたか否かを判断する。そのようなイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部３１３からＤＢ管理部３１５に出力された場合）、図１０の処理はステップＳ２１３に移行する。逆に、そのようなイベントが検出されていなければ、図１０の処理はステップＳ２１４に移行する。
例えば、ＤＢ５００に追加するためのテーブルの一部または全部が特定のＴＣＰ（Transmission Control Protocol）ポートで受信される場合、監視部３１３は、特定のＴＣＰポートにおける受信を監視してもよい。それにより、監視部３１３は、上記のようなイベントを検出することができる。
なお、上記の「ＤＢ５００に追加するためのテーブルの一部または全部」とは、具体的には以下のうちの１つ以上の組み合わせである。
・ＩＤテーブル５０１の全体を置き換えるための、丸ごとのＩＤテーブル。
・ＩＤテーブル５０１に追加するための、新たな１つ以上のエントリ。
・ＩＤテーブル５０１中の既存の１つ以上のエントリをそれぞれ置き換えるための、更新された１つ以上のエントリ。
・ＤＢ５００に追加するための、新たな履歴テーブル。
・ＤＢ５００中の既存のいずれかの履歴テーブルの全体を置き換えるための、丸ごとの履歴テーブル。
・ＤＢ５００中の既存のいずれかの履歴テーブルに追加するための、新たな１つ以上のエントリ。
・追跡テーブル５０３の全体を置き換えるための、丸ごとの追跡テーブル。
・追跡テーブル５０３に追加するための、新たな１つ以上のエントリ。
例えば、図５のステップＳ１１４での端末３１０におけるメタデータ４０７の受信は、ステップＳ２１２における受信の一例である。例えば、メタデータ４０７は、追跡テーブル５０３に追加するための、新たな１つのエントリを含む。
さて、ステップＳ２１３では、ステップＳ２１２で受信された内容に応じて、ＤＢ５００が更新される。ステップＳ２１３でのＤＢ５００の更新は、ＤＢ管理部３１５により制御される。
例えば、丸ごとのＩＤテーブルが受信された場合、ＤＢ管理部３１５は、受信されたＩＤテーブルで既存のＩＤテーブル５０１を置き換えてもよい。あるいは、丸ごとのＩＤテーブルが受信された場合、ＤＢ管理部３１５は、更新されたエントリと追加された新規エントリを探してもよい。そして、ＤＢ管理部３１５は、更新されたエントリでＩＤテーブル５０１中の既存のエントリを置き換え、受信したＩＤテーブルに含まれている新規エントリをＤＢ５００中のＩＤテーブル５０１に追加してもよい。
履歴テーブルや追跡テーブルに関しても、ＤＢ管理部３１５は、類似の方法により、テーブル全体の置き換え、エントリの更新、および／またはエントリの追加を行う。なお、新たな履歴テーブルが受信された場合、ＤＢ管理部３１５は、受信された新たな履歴テーブルをＤＢ５００に追加する。
例えば以上のようなＤＢ５００の更新の後、図１０の処理はステップＳ２０１に戻る。
さて、ステップＳ２１４でＤＢ管理部３１５は、サーバ３５０への問い合わせをするか否かを判断する。ここで、「サーバ３５０への問い合わせ」とは、「端末３１０中のＤＢ５００には含まれていない新たなデータがサーバ３５０のＤＢ５３０−１（つまり端末３１０と３３０を使うユーザ用のＤＢ）内に蓄積されているか否か」についての問い合わせである。
例えば、端末３１０の入力装置２０５を介して、ユーザが明示的に、サーバ３５０への問い合わせをするよう端末３１０に指示する場合があり得る。この場合、ＤＢ管理部３１５は、ユーザからの入力を検出してもよい。ＤＢ管理部３１５は、ユーザからの入力を検出した場合には、「サーバ３５０への問い合わせをする」と判断する。
あるいは、端末３１０が最後にサーバ３５０からメタデータ（つまりテーブルの一部または全部）を受信してから、決められた時間以上の時間が既に経過している場合に、ＤＢ管理部３１５は、「サーバ３５０への問い合わせをする」と判断してもよい。ステップＳ２１４の判断は、例えばフラグやタイマを用いて実装されてもよい。
ＤＢ管理部３１５が「サーバ３５０への問い合わせをする」と判断すると、図１０の処理はステップＳ２１５に移行する。逆に、ＤＢ管理部３１５が「サーバ３５０への問い合わせをしない」と判断すると、図１０の処理はステップＳ２０１に戻る。
ステップＳ２１５では、通信部３１１がサーバ３５０に問い合わせを送る。問い合わせは、ＤＢ管理部３１５により生成される。問い合わせは、端末３１０が最後にサーバ３５０からメタデータを受信した日時を含んでいてもよい。また、問い合わせは、ＩＤテーブル５０１のエントリ数や追跡テーブル５０３のエントリ数などを含んでいてもよい。
問い合わせに対して、サーバ３５０から応答が返される。サーバ３５０から返される応答は、具体的には、適宜のメタデータ（つまりテーブルの一部または全部）を含む応答であるか、または、「新たなデータは蓄積されていない」旨を示す応答である。通信部３１１は、サーバ３５０からの応答をステップＳ２１５で受信する。
次に、ステップＳ２１６でＤＢ管理部３１５は、受信された応答に基づいて（あるいは、受信された応答に含まれるメタデータと端末３１０中のＤＢ５００との比較に基づいて）、追加データがあるか否かを判断する。つまり、ＤＢ管理部３１５は、端末３１０中のＤＢ５００には含まれていない新たなデータがあるか否かを判断する。
追加データがある場合、図１０の処理はステップＳ２１３に移行し、ステップＳ２１３で追加データがＤＢ５００に追加される。逆に、追加データがない場合、図１０の処理はステップＳ２０１に戻る。
さて、図１１は、第２実施形態で端末３３０が行う処理のフローチャートである。端末３３０の電源がオンにされると、端末３３０は図１１の処理を開始する。
図１１と図１０の違いは、図１１ではステップＳ３０１とＳ３０２が追加されている点である。ステップＳ２０１〜Ｓ２１６は、図１０と図１１で共通なので、詳しい説明は省略する。なお、図１０では、ステップＳ２０４、Ｓ２１３、Ｓ２１４、およびＳ２１６からステップＳ２０１へと処理が戻る場合があるが、図１１では、ステップＳ２０１ではなくステップＳ３０１に処理が戻る。
具体的には、端末３３０が図１１の処理を開始すると、まずステップＳ３０１で、バックアップ制御部３３９が「ファイルのバックアップを行うか否か」を判断する。
例えば、端末３３０の入力装置２０５を介して、ユーザから明示的にバックアップ開始が指示される場合もある。バックアップ制御部３３９は、ユーザから入力を検出してもよい。バックアップ制御部３３９は、ユーザからの入力を検出した場合には、「ファイルのバックアップを行う」と判断する。
また、バックアップスケジュールが予め決められていてもよい。バックアップスケジュールにより決められた日時になった場合、バックアップ制御部３３９は、「ファイルのバックアップを行う」と判断してもよい。
そして、バックアップ制御部３３９が「ファイルのバックアップを行う」と判断すると、図１１の処理はステップＳ３０２に移行する。ステップＳ３０２では、図１４〜１５とともに後述するバックアップ制御処理が行われる。バックアップ制御処理の実行後、図１１の処理はステップＳ３０１に戻る。
逆に、ステップＳ３０１でバックアップ制御部３３９が「ファイルのバックアップを行わない」と判断した場合、図１１の処理はステップＳ２０１に移行する。ステップＳ２０１〜Ｓ２１６では、端末３３０内の通信部３３１、監視部３３３、およびＤＢ管理部３３５が、端末３１０内の通信部３１１、監視部３１３、およびＤＢ管理部３１５とそれぞれ同様に動作する。
また、図１０に関して説明したように、端末３１０では、ファイル記憶部３１２内のファイルに対する操作が監視され、デバイスＩＤ記憶部３１４に記憶されたデバイスＩＤが使われ、ＤＢ記憶部３１６上のＤＢ５００が管理される。同様に、図１１の処理においては、端末３３０では、ファイル記憶部３３２内のファイルに対する操作が監視され、デバイスＩＤ記憶部３３４に記憶されたデバイスＩＤが使われ、ＤＢ記憶部３３６上のＤＢ５１０が管理される。
ある観点から言えば、図１１のステップＳ２０１〜Ｓ２１６の処理は、端末３３０（すなわち優先度の算出を行う情報処理装置）が履歴情報と追跡情報を取得する処理であり、図１のステップＳ１〜Ｓ２に対応する。他方、図１１のステップＳ３０２でのバックアップ制御処理は、図１のステップＳ３〜Ｓ７に対応するいくつかのステップを含む。
また、図５のステップＳ１０６でのメタデータ４０３の受信は、図１１のステップＳ２１２での受信に対応する。同様に、ステップＳ１１４でのメタデータ４０７の受信も、ステップＳ２１２での受信に対応する。
図５のステップＳ１０７でのファイル４０４の受信は、図１１のステップＳ２０９で検出される受信に対応する。そして、図５のステップＳ１０８でのメタデータ４０５の生成と記録は、図１１のステップＳ２１０、Ｓ２１１およびＳ２０３に対応し、図５のステップＳ１０９でのメタデータ４０５の送信は図１１のステップＳ２０４での送信に対応する。
図５のステップＳ１１５での優先度４０８の算出は、図１１のステップＳ３０２のバックアップ制御処理に含まれる。
ところで、ステップＳ２１４の問い合わせは、主に、端末３３０に利点をもたらす。なぜなら、優先度の算出を行う端末３３０にとって、優先度の算出に使うＤＢ５１０を適切に管理することが望ましいからであり、問い合わせはＤＢ５１０の適切な管理に役立つからである。
例えば、端末３３０には常に電源が入れられているとは限らない。また、仮に端末３３０に電源が入れられているとしても、端末３３０が常にネットワーク３７０に接続されているとは限らない。例えば、端末３３０が電池で駆動される場合などに、省電力のために通信機能がオフにされることがあり得る。また、通信機能がオンになっていても、無線通信環境などによっては、端末３３０が通信不能な場合もあり得る。
すると、端末３３０がネットワーク３７０を介してサーバ３５０と通信を行うことができない期間が存在し得る。一方、そのような期間中に、端末３１０においてファイルに対して何らかの操作が行われることもあり得るし、その結果、新たなメタデータが生成されることもあり得る。
ステップＳ２１４の問い合わせは、端末３３０が通信不能な期間中に新たに生成されたメタデータを、後から端末３３０が取得することを可能にする。つまり、ステップＳ２１４の問い合わせは、端末３３０のＤＢ記憶部３３６上のＤＢ５１０を適切な状態に維持するうえで、有益である。
また、「端末３１０や３３０は、常にネットワーク３７０を介した通信が可能な状態にあるわけではない」という点を考慮して、図１０と１１の処理は、以下のように変形されてもよい。説明の便宜上、図１０の処理の変形について以下に例示するが、図１１の処理も同様に変形されてよい。
端末３１０は、電池残量や通信環境によっては、ステップＳ２０３の実行後、ステップＳ２０４を実行せずにステップＳ２０１に戻ってもよい。端末３１０は、このようにステップＳ２０３の直後のステップＳ２０４の送信を省略する場合は、代わりに、「ステップＳ２０３でどのテーブルのどのエントリを更新または追加したのか」ということを記録する。例えば、ＤＢ５００中の各テーブルの各エントリに、「当該エントリを後でサーバ３５０に送信するか否か」を示すフラグ用のフィールドが設けられてもよい。
端末３１０は、ステップＳ２０４を省略する場合は、ステップＳ２０３で更新または追加した各エントリのフラグをオンにする。そして、端末３１０は、通信が可能な状況になった後の適宜の時点において、フラグがオンのエントリをサーバ３５０に送信してもよい。送信後、端末３１０は、送信した各エントリのフラグをオフにする。
以上のような図１０の処理の変形と同様の変形は、上述のとおり、端末３３０が実行する図１１の処理にも適用可能である。
さて、ここで説明の都合上、上記のステップＳ３０２のバックアップ制御処理の詳細について説明する前に、サーバ３５０が行う処理について先に説明することにする。サーバ３５０は、上記のステップＳ２１４の問い合わせに応答するだけでなく、さらに、図１２の処理も実行する。ある観点から言えば、ステップＳ２１４の問い合わせに対して応答する処理も、図１２の処理も、端末３３０（すなわち優先度の算出を行う情報処理装置）が履歴情報と追跡情報を取得することができるようにするための処理である。
サーバ３５０に電源が入れられると、サーバ３５０は図１２の処理を開始する。そして、通信部３５１が、いずれかの端末から、いずれかのテーブルの一部または全部（つまり何らかのメタデータ）を受信するまで、サーバ３５０はステップＳ４０１で待つ。通信部３５１が何らかのメタデータを受信すると、図１２の処理はステップＳ４０２に移行する。
ステップＳ４０２でデバイス管理部３５３は、メタデータの送信元の端末のデバイスＩＤを抽出する。また、ステップＳ４０３でデバイス管理部３５３は、メタデータの送信元の端末を使うユーザのユーザＩＤを抽出する。
ステップＳ４０２とＳ４０３の抽出のための具体的手法は、実施形態に応じて適宜決められていてよい。
例えば、端末３１０と３３０の各々は、ステップＳ２０４において、ステップＳ２０３で更新または追加したテーブルおよび／またはエントリとともに、デバイスＩＤをサーバ３５０に送信してもよい。すると、デバイス管理部３５３は、通信部３５１が受信した情報の中から、ステップＳ４０２でデバイスＩＤを抽出することができる。また、ステップＳ４０３でデバイス管理部３５３は、抽出したデバイスＩＤを検索キーとして用いて、デバイス管理テーブル５２０を参照することで、ユーザＩＤを抽出することもできる。
あるいは、ステップＳ２０４の送信が、端末とサーバ３５０の間でコネクションを確立するための認証フェーズと、確立されたコネクション上での情報送信フェーズを含んでいてもよい。端末３１０と３３０の各々は、認証フェーズにおいてデバイスＩＤをサーバ３５０に送信してもよい。この場合、デバイス管理部３５３は、認証フェーズで送信されたデバイスＩＤを取得することができる。
もちろん、端末３１０と３３０の各々は、デバイスＩＤだけでなく、ユーザＩＤをさらに記憶していてもよい。この場合、端末３１０と３３０の各々は、デバイスＩＤだけでなく、ユーザＩＤをさらにサーバ３５０に送信してもよい。
具体的な方法が何であれ、デバイス管理部３５３は、デバイスＩＤとユーザＩＤを抽出すると、デバイスＩＤとユーザＩＤをＤＢ管理部３５４に出力する。そして、図１２の処理はステップＳ４０４に移行する。
なお、図１２に関しては、説明の簡単化のため、端末から一度に送られるメタデータは、１つの操作に対応するものと仮定する。２つ以上の操作に対応するメタデータが一度にまとめて送られる場合は、図１２の処理が、ステップＳ４０４〜Ｓ４０８・Ｓ４１１〜Ｓ４１３を適宜の回数繰り返すように変形される。
さて、ステップＳ４０４でＤＢ管理部３５４は、通信部３５１が受信したメタデータのログ種別が、「受信」なのか、「送信」なのか、それ以外なのかを判断する。そして、ログ種別が「受信」の場合、図１２の処理はステップＳ４０５に移行する。ログ種別が「送信」の場合、図１２の処理はステップＳ４１１に移行する。ログ種別が「受信」でも「送信」でもない場合、図１２の処理はステップＳ４１３に移行する。
例えば、あるファイルが１台の端末から他の端末に送信された場合、送信されたファイルに対応する当該ファイルのファイルＩＤと、当該ファイルＩＤに対応する履歴テーブル中の１個のエントリがステップＳ４０１で受信される。この場合、ログ種別は「送信」である。もちろん、単なるファイルＩＤの代わりに、ＩＤテーブル中の１つのエントリが使われてもよい。
例えば、図６の履歴テーブル５０２ａの２番目のエントリがステップＳ４０１で受信された場合、ログ種別は「送信」である。よって、この場合、図１２の処理はステップＳ４１１に移行する。
あるファイルが端末内で変更された場合は、変更された当該ファイルのファイルＩＤと、当該ファイルＩＤに対応する履歴テーブル中の１個のエントリがステップＳ４０１で受信される。この場合、ログ種別は「受信」でも「送信」でもない。もちろん、単なるファイルＩＤの代わりに、ＩＤテーブル中の１つのエントリが使われてもよい。
例えば、図６の履歴テーブル５０２ｂの２番目または３番目のエントリがステップＳ４０１で受信された場合、図１２の処理はステップＳ４１３に移行する。同様に、図７の履歴テーブル５１２ａの２番目のエントリがステップＳ４０１で受信された場合も、図１２の処理はステップＳ４１３に移行する。
あるファイルが端末内で移動または変名された場合は、ＩＤテーブルの１個のエントリ（つまり移動または変名された当該ファイルに対応するエントリ）と、当該ファイルに対応する履歴テーブル中の１個のエントリがステップＳ４０１で受信される。この場合、ログ種別は「受信」でも「送信」でもない。
例えば、図７のＩＤテーブル５１１の２番目のエントリと履歴テーブル５１２ａの３番目のエントリがステップＳ４０１で受信された場合、図１２の処理はステップＳ４１３に移行する。
あるファイルが削除された場合は、ＩＤテーブルの１個のエントリ（つまり削除された当該ファイルに対応するエントリ）が、削除を示す情報とともにステップＳ４０１で受信される。この場合、ログ種別は「受信」でも「送信」でもない。よって、図１２の処理はステップＳ４１３に移行する。
あるファイルが端末内で新規作成された場合は、ＩＤテーブルの１個のエントリ（つまり作成された当該ファイルに対応するエントリ）と、当該ファイルに対応する新たな履歴テーブルに最初に作られたエントリが、ステップＳ４０１で受信される。この場合、ログ種別は「受信」でも「送信」でもない。
例えば、図６のＩＤテーブル５０１の２番目のエントリと、履歴テーブル５０２ａの１番目のエントリがステップＳ４０１で受信された場合、図１２の処理はステップＳ４１３に移行する。
あるファイルが端末内でコピーされた場合は、ＩＤテーブルの２個のエントリ（つまりコピー元のファイルとコピー操作により新たに作られたファイル）と、両ファイルにそれぞれ対応する履歴テーブルのそれぞれ１個のエントリが、ステップＳ４０１で受信される。さらに、この場合には、追跡テーブルの１個のエントリもステップＳ４０１で受信される。
例えば、ステップＳ４０１で以下のエントリが受信された場合、図１２の処理はステップＳ４１３に移行する。
・図６のＩＤテーブル５０１において、履歴テーブル５０２ａに対応するエントリ。
・ＩＤテーブル５０１において、履歴テーブル５０２ｂに対応するエントリ。
・履歴テーブル５０２ａの４番目のエントリ。
・履歴テーブル５０２ｂの１番目のエントリ。
・追跡テーブル５０３の２番目のエントリ。
あるファイルが、ある端末で受信されて新たに保存された場合は、ＩＤテーブルの１個のエントリ（つまり受信され保存されたエントリ）と、当該ファイルに対応する新たな履歴テーブルに最初に作られたエントリが、ステップＳ４０１で受信される。この場合、ログ種別は「受信」である。
例えば、図７のＩＤテーブル５１１の２番目のエントリ（ただしファイルがリネームされる前の状態のもの）と、履歴テーブル５１２ａの１番目のエントリがステップＳ４０１で受信された場合、図１２の処理はステップＳ４０５に移行する。
あるファイルが閲覧された場合は、閲覧された当該ファイルのファイルＩＤと、当該ファイルＩＤに対応する履歴テーブル中の１個のエントリがステップＳ４０１で受信される。この場合、ログ種別は「受信」でも「送信」でもない。もちろん、単なるファイルＩＤの代わりに、ＩＤテーブル中の１つのエントリが使われてもよい。
例えば、図６の履歴テーブル５０２ａの３番目のエントリがステップＳ４０１で受信された場合、図１２の処理はステップＳ４１３に移行する。
さて、ログ種別が「受信」の場合、ステップＳ４０５でＤＢ管理部３５４は、送信元に関する情報を抽出する。
例えば、図７の履歴テーブル５１２ａの１番目のエントリでは「スマートフォンから受信」と例示されている。よって、履歴テーブル５１２ａの１番目のエントリが受信された場合、ＤＢ管理部３５４は、スマートフォンが送信元であることをステップＳ４０５で認識する。
例えば、図８のデバイス管理テーブル５２０には、ユーザＩＤとデバイスＩＤのフィールドのみが例示されているが、さらに、端末の種類（例えば、「ＰＣ」や「スマートフォン」など）を示すフィールドがあってもよい。すると、デバイス管理部３５３は、デバイス管理テーブル５２０を参照することで、スマートフォンのデバイスＩＤを認識することも可能である。したがって、ＤＢ管理部３５４は、デバイス管理部３５３への問い合わせを介して、スマートフォンのデバイスＩＤを取得することができる。
場合によっては、履歴テーブルにおいて、「ｍｏｂｉｌｅ−００１から受信」のように、デバイスＩＤを使ってログ種別が表現されていてもよい。この場合、ＤＢ管理部３５４は、送信元に関する情報として、「ｍｏｂｉｌｅ−００１」というデバイスＩＤを、理的テーブルから直接抽出することができる。
なお、履歴テーブルにおけるログ種別の表現形式は、実施形態に応じて適宜決められていてよい。例えば、「『スマートフォンから受信』というサブ種別が『受信』という種別に含まれる」と予め定義されていてもよい。あるいは、図６では「ログ種別」という１つのフィールドの中に「スマートフォンから受信」と例示されているが、「受信」のような大まかな種別を示すフィールドと、種別に応じたパラメタを示すフィールドが履歴テーブルに含まれていてもよい。例えば、「受信」という種別の場合、後者のフィールドには、「スマートフォン」または「ｍｏｂｉｌｅ−００１」などのパラメタが含まれていてもよい。
さて、次のステップＳ４０６において、ＤＢ管理部３５４は、受信に対応する送信ログがあるか否かを判断する。ここで、今回のステップＳ４０１において受信された履歴情報が示す「受信」は、ファイルが送られる送信先の端末にとっての「受信」であることに注意されたい。よって、ステップＳ４０６でＤＢ管理部３５４は、具体的には、送信元の端末にとっての「送信」を示す履歴情報がＤＢ記憶部３５２内にあるか否かを判断する。
例えば、端末３３０から図７の履歴テーブル５１２ａの１番目のエントリがステップＳ４０１で受信されたとする。この場合、ステップＳ４０２で抽出されるデバイスＩＤは「ＰＣ−００２」であり、ステップＳ４０３で抽出されるユーザＩＤは「ｓｕｚｕｋｉ＿ｔａｒｏ」である。ステップＳ４０５では、送信元を示す情報として、「スマートフォン」という種別のみが抽出される場合もあり得るし、「ｍｏｂｉｌｅ−００１」というデバイスＩＤが抽出される場合もあり得る。
このように「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤが抽出された場合、ＤＢ管理部３５４は、「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザ用のＤＢ（すなわち図８と９のＤＢ５３０−１）を参照し、受信に対応する送信ログを探す。例えば、送信元を示す情報として「ｍｏｂｉｌｅ−００１」というデバイスＩＤが抽出されたとする。この場合、ＤＢ管理部３５４は、ＩＤテーブル５３１で「ｍｏｂｉｌｅ−００１」というデバイスＩＤを持つ各エントリに対応するすべての履歴テーブルの中から、以下の３つの条件を満たすエントリを探す。
・ログ種別が、「送信」である。
・ユニーク値が、「受信」を示す履歴情報におけるユニーク値（この例では、履歴テーブル５１２ａの１番目のエントリにおける「６５６１５１６３」）と等しい。
・日時が、「受信」を示す履歴情報における日時（この例では、履歴テーブル５１２ａの１番目のエントリにおける「２０１２年３月６日８時２１分）と、ある誤差範囲内で等しい。
上記の３つの条件を満たすエントリが、上記の「受信に対応する送信ログ」である。例えば、上記の例では、図６の履歴テーブル５０２ａの２番目のエントリをサーバ３５０が既に受信していた場合には、「受信に対応する送信ログ」がＤＢ５３０−１内に存在する。
以上の説明から明らかなとおり、ステップＳ４０５では、送信元を示す情報が抽出されなくても問題ない。つまりステップＳ４０５は省略可能である。なぜなら、ＤＢ管理部３５４は、ＤＢ５３０−１中の全履歴テーブルの中から上記の３つの条件を満たすエントリを探せばよいからである。ただ、送信元を示す情報が抽出可能であれば、検索が効率化されるので、図１２にはステップＳ４０５が例示されている。
そして、受信に対応する送信ログが見つかった場合、図１２の処理はステップＳ４０７に移行する。逆に、受信に対応する送信ログが見つからなければ、図１２の処理はステップＳ４１３に移行する。例えば、図５のステップＳ１１０では、受信に対応する送信ログが見つからない。
さて、ステップＳ４０７でＤＢ管理部３５４は、送信を示す履歴情報と、受信を示す履歴情報に基づいて、端末間の複製操作によるファイル間の親子関係を認識する。そして、ＤＢ管理部３５４は、親子関係を示す追跡情報を生成する。
例えば、送信を示す履歴情報として、図６の履歴テーブル５０２ａの２番目のエントリが既にサーバ３５０に受信されており、かつ、受信を示す履歴情報として、図７の履歴テーブル５１２ａの１番目のエントリが既にサーバ３５０に受信されているとする。この場合、ＤＢ記憶部３５２内のＤＢ５３０−１には、送信を示す履歴情報と受信を示す履歴情報が含まれている。つまり、ＤＢ５３０−１には、以下の２つの履歴テーブルが含まれている。
・「ｍｏｂｉｌｅ−００１」というデバイスＩＤと「１３」というファイルＩＤとのペアに対応する履歴テーブル。
・「ＰＣ−００２」というデバイスＩＤと「８３」というファイルＩＤとのペアに対応する履歴テーブル。
そして、ステップＳ４０７に至るまでのステップにおいて、ＤＢ管理部３５４は既に上記の２つのデバイスＩＤと上記の２つのファイルＩＤを認識している。
例えば、ファイルの受信を示す履歴情報は、ＩＤテーブルのエントリとともにサーバ３５０に受信されるから、ＤＢ管理部３５４は、ファイルの送信先の端末（つまりファイルを受信した端末）におけるファイルＩＤを認識することができる。また、ファイルの受信を示す履歴情報がステップＳ４０１で受信された場合には、ファイルの送信先の端末（つまり履歴情報の送信元の端末）のデバイスＩＤは、ステップＳ４０２で抽出されている。
そして、ファイルを送信した端末のデバイスＩＤは、ステップＳ４０５で抽出されるか、または、ステップＳ４０６での検索の結果として、ＤＢ管理部３５４に認識される。また、ファイルを送信した送信元の端末におけるファイルＩＤは、ステップＳ４０６での検索の結果として、ＤＢ管理部３５４に認識されている。
よって、ステップＳ４０７でＤＢ管理部３５４は、送信を示す履歴情報と、受信を示す履歴情報に基づいて、親デバイスＩＤ、親ファイルＩＤ、子デバイスＩＤ、および子ファイルＩＤを認識することができる。ＤＢ管理部３５４は、これら４つのＩＤにより表される追跡情報を生成する。
続いて、ステップＳ４０８でＤＢ管理部３５４は、テーブルの送信先を決定する。より具体的には、ＤＢ管理部３５４は、ステップＳ４０１で受信されたメタデータの送信元の端末と同じユーザにより使われているすべての端末に、以下のエントリを送信することを決定する。
・追跡テーブルのエントリ（ステップＳ４０７で生成された追跡情報であり、次のステップＳ４０９でＤＢ５３０−１内の追跡テーブル５３３に追加するエントリとも同じ追跡情報である）。
・履歴テーブルのエントリ（ステップＳ４０１で受信されたエントリと同じ履歴情報であり、次のステップＳ４０９でＤＢ５３０−１内のいずれかの履歴テーブルに追加するエントリとも同じ履歴情報である）。
・ステップＳ４０１でＩＤテーブルのエントリが受信された場合は、当該ＩＤテーブルのエントリ（次のステップＳ４０９でＤＢ５３０−１内のＩＤテーブル５１１に追加するエントリと同じである）。
上記の説明から明らかなように、あるユーザがＭ台の端末を使う場合、Ｍ台の端末すべてが、ステップＳ４０８で送信先として決定される。そして、図１２の処理はステップＳ４０９に移行する。
ステップＳ４０９でＤＢ管理部３５４は、ＤＢ記憶部３５２上のＤＢを更新する。つまり、ＤＢ管理部３５４は、ステップＳ４０１で受信したメタデータに基づいて、適宜、テーブルの追加、エントリの追加、および／またはエントリの更新を行う。また、ステップＳ４０７の後にステップＳ４０９が実行される場合は、ＤＢ管理部３５４はさらに、ステップＳ４０７で生成した追跡情報もＤＢに追加する。
そして、次のステップＳ４１０では、ステップＳ４０９で更新または追加された各エントリが、通信部３５１から送信される。送信先は、ステップＳ４０８で決定された上記Ｍ台の端末か、または、後述するようにステップＳ４１３で決定された（Ｍ−１）台の端末である。送信後、図１２の処理はステップＳ４０１に戻る。
さて、ログ種別が「送信」の場合、ステップＳ４１１でＤＢ管理部３５４は、送信先に関する情報を抽出する。そして、次のステップＳ４１２でＤＢ管理部３５４は、送信に対応する受信ログがあるか否かを判断する。ステップＳ４１１およびＳ４１２の詳細は、「受信」と「送信」が入れ替わっている点を除けば、ステップＳ４０５およびＳ４０６と類似である。よって、詳細な説明は省略する。ステップＳ４０５が省略可能なのと同様に、ステップＳ４１１も省略可能である。
ステップＳ４１２において、送信に対応する受信ログが見つかった場合、図１２の処理はステップＳ４０７に移行する。逆に、送信に対応する受信ログが見つからなかった場合、図１２の処理はステップＳ４１３に移行する。
例えば、図５のステップＳ１１２でのメタデータ４０６が、図１２のステップＳ４０１で受信されると、ステップＳ４１２で、送信に対応する受信ログが見つかる。なぜなら、図５のステップＳ１０９で既にメタデータ４０５が受信されているからである。よって、この場合は、図１２の処理はステップＳ４０７に移行する。その結果、ステップＳ４０７で認識された親子関係を示す追跡情報を含むメタデータ４０７が、ステップＳ４１０で送信される。このステップＳ４１０での送信が、図５のステップＳ１１４に対応する。
さて、ステップＳ４１３では、ＤＢ管理部３５４は、以下のようにテーブルの送信先を決定する。具体的には、ＤＢ管理部３５４は、ステップＳ４０１で受信されたメタデータの送信元の端末以外のすべての端末（ただし、送信元の端末と同じユーザにより使われている端末に限る）に、以下のエントリを送信することを決定する。
・履歴テーブルのエントリ（ステップＳ４０１で受信されたエントリと同じ履歴情報であり、次のステップＳ４０９でＤＢ５３０−１内のいずれかの履歴テーブルに追加するエントリとも同じ履歴情報である）。
・ステップＳ４０１でＩＤテーブルのエントリが受信された場合は、当該ＩＤテーブルのエントリ（次のステップＳ４０９でＤＢ５３０−１内のＩＤテーブル５１１に追加するエントリと同じである）。
上記の説明から明らかなように、あるユーザがＭ台の端末を使う場合、（Ｍ−１）台の端末が、ステップＳ４１３で送信先として決定される。そして、図１２の処理はステップＳ４０９に移行する。
例えば、図４と図５に示す例ではＭ＝２であり、図５のステップＳ１０６は、１（＝Ｍ−１）台の端末３３０にステップＳ４１０でメタデータ４０３が送信されることを示している。
以上、図１２を参照して説明したように、第２実施形態では、端末間の複製操作によって発生する親子関係についての追跡情報は、サーバ３５０により生成される。そして、サーバ３５０が追跡情報を送信することで、端末３３０（つまり優先度を算出する情報処理装置）は、追跡情報を取得することが可能となる。
続いて、図１１のステップＳ３０２におけるバックアップ制御処理の詳細について、図１３〜１５を参照して説明する。バックアップ制御処理は優先度の算出を含み、優先度の算出においてはファイル間の親子関係が考慮される。
図１３は、ファイル間の親子関係と優先度について説明する図である。ファイルは、端末内でのコピー操作により複製されることもあり得るし、ある端末から他の端末への送信により端末間で複製されることもあり得る。また、後述の第３実施形態では、ファイルが端末からサーバへの送信により複製されることもあり得るし、サーバから端末への送信によりファイルが複製されることもあり得る。そして、複製は１回だけ行われるとは限らない。また、複製の後に、親ファイルが変更される可能性もあるし、子ファイルが変更される可能性もある。つまり、親ファイルと子ファイルのデータは、互いに等しい場合もあり得るし、互いに異なる場合もあり得る。
図１３では、ファイル間の親子関係を木構造で図示している。以下では説明の便宜上、１つ以上のファイルを含む木を「ファイルツリー」という。また、１つのファイルツリーに含まれるファイルのうち、データが同じ１つ以上のファイル同士のグループを「同一データグループ」という。さらに、根ファイルでも葉ファイルでもないファイルを「中間ファイル」という。
ファイルツリー６００は、１つのファイル６０１のみを含む。ファイル６０１は根ファイルであり、かつ、葉ファイルである。つまり、ファイル６０１に対する複製操作は、まだ行われたことがない。ファイル６０１の優先度は、ファイル６０１に対して今までに行われた各操作に応じて算出される。
例えば、ファイル６０１に対して今までに３回、何らかの操作が行われたとする。この場合、優先度算出部３３７は、３つの操作それぞれの種別に応じた値の和を、ファイル６０１の優先度として算出してもよい。例えば、優先度算出部３３７は、定義７０１のようにログ種別に応じて決められた式にしたがって、３つの操作それぞれに対応する値を算出し、算出した３つの値を足すことで、ファイル６０１の優先度を算出してもよい。
定義７０１に例示されているそれぞれの式において、「Ｎｏｗ」は現在時刻（つまり優先度算出部３３７が優先度を算出する時点）を示し、「ｔ」は操作が行われた日時を示し、「Δｔ」は操作にかかった時間の長さを示す。定義７０１に例示するとおり、操作の種別に応じた値を算出するための式は、（Ｎｏｗ−ｔ）の関数であってもよいし、（Ｎｏｗ−ｔ）とΔｔの関数であってもよい。
各関数ｆａ（１≦ａ）は、（Ｎｏｗ−ｔ）に対して単調減少することが望ましい。つまり、優先度算出部３３７は、そのように定義された関数を用いることで、操作が行われた時点が新しいほど、ファイルの優先度を高めてもよい。
また、関数ｆａが引数としてΔｔをもとる場合、関数ｆａは、Δｔに対して単調増加することが望ましい。つまり、優先度算出部３３７は、そのように定義された関数を用いることで、操作にかかった時間が長いほど、ファイルの優先度を高めてもよい。
各関数ｆａの詳細は、実施形態に応じて適宜決められてよい。例えば、以下の式（１）と（２）のような定義が採用されてもよい（ただし、式（１）と（２）では、（Ｎｏｗ−ｔ）とΔｔの単位が秒であるものとする）。
Figure 2014063217
Figure 2014063217
例えば、式（１）と（２）における「１００」などの具体的な値は、いずれも説明の便宜上の例に過ぎないが、これらの値を調整することで、操作の種別に応じた重要度を優先度に反映させることができる。
例えば、作成操作は、他の操作（例えば受信操作）よりも優先度をより高めるように、優先度に影響することが好ましい。そこで、「受信」という種別に対応する関数は、式（１）の「１００」という値を「２０」という値に置き換えた関数であってもよい。すると、このような値の違いにしたがって、優先度算出部３３７は、優先度の算出において、受信よりも作成を重要視することが可能となる。
同様に、ユーザ主導操作と自動操作の違いを優先度に反映するために、関数ｆ５とｆ６におけるパラメタの値が異なるように定義されていてもよい。
また、スマートフォン１０２のＳＳＤ１０３の容量は、ＰＣ１０６のＨＤＤ１０７の容量よりも小さい場合が多い。このことから、以下のような考察が得られる。
ユーザは、それほど重要と考えていないファイルでも、しばしばスマートフォン１０２からＰＣ１０６に送信すると考えられる。なぜなら、ＰＣ１０６のＨＤＤ１０７の容量は大きいからである。
しかし、ユーザがわざわざＰＣ１０６からスマートフォン１０２に送信するファイルは、ユーザにとってある程度重要性の高いものだと考えられる。なぜなら、スマートフォン１０２のＳＳＤ１０３の容量は小さいからである。
以上のような考察に基づいて、「送信」という種別は、「ＰＣへの送信」という種別と、「スマートフォンへの送信」という種別にサブカテゴリ化されてもよい。そして、「ＰＣへの送信」という種別と、「スマートフォンへの送信」という種別に応じて、互いに異なる式が使われてもよい。同様に、「ＰＣからの受信」と「スマートフォンからの受信」という種別に応じて、互いに異なる式が使われてもよい。つまり、優先度算出部３３７は、そのように端末の種類に応じてサブカテゴリ化された「受信」・「送信」などのログ種別に応じた式を使ってもよい。
それにより、スマートフォン１０２への送信操作（換言すればＰＣ１０６からの受信操作）は、ＰＣ１０６への送信操作（換言すればスマートフォン１０２からの受信操作）よりも、一層、優先度を高めるように、優先度に影響することになる。
さて、ファイルツリー６１０は、３つのファイル６１１〜６１３を含む。ファイル６１１は根ファイルであり、ファイル６１２はファイル６１１の子ファイルである。ファイル６１３は、ファイル６１２の子ファイルであり、かつ、葉ファイルである。また、ファイル６１１〜６１３のデータは互いに異なる。
例えば、ユーザは、ファイル６１１を作成し、ファイル６１１をコピーしてファイル６１２を作成し、ファイル６１２を編集し、編集後のファイル６１２をコピーしてファイル６１３を作成し、ファイル６１３を編集する場合がある。ファイルツリー６１０は、例えばこのような場合に対応する。
優先度算出部３３７は、１回以上の複製操作により根ファイルから直接または間接に得られた１個以上の子孫ファイルの各々に対して行われた各操作に応じて、根ファイルの優先度を上げてもよい。つまり、優先度算出部３３７は、ファイル６１１の優先度を算出する際に、ファイル６１１に対する操作履歴のほかに、さらに、ファイル６１２と６１３に対する操作履歴を考慮してもよい。具体的には、優先度算出部３３７は、ファイル６１２と６１３に対する操作履歴に応じて、ファイル６１１の優先度を上げてもよい。
なぜなら、「もしファイル６１２や６１３に対して多くの操作が行われているならば、ファイル６１２と６１３の元になった根ファイルであるファイル６１１の重要性が高い」と想定されるからである。
また、ファイル６１２と６１３を比べると、ファイル６１３は最新版である蓋然性が高く、ファイル６１２は編集過程の途中の状態が保存されたものである蓋然性が高い。よって、優先度算出部３３７は、１つのファイルツリーに属するファイルのうち、葉ファイルの優先度を中間ファイルの優先度よりも高く評価することが好ましい。
例えば、優先度算出部３３７は、ファイル６１３の優先度を、ファイル６１１の優先度（例えば、上記のようにして各子孫ファイルに対する各操作に応じて上げた優先度）に応じて上げてもよい。優先度算出部３３７は、このようにして、中間ファイル６１２の優先度よりも、葉ファイル６１３の優先度の方を高く評価してもよい。
あるいは、優先度算出部３３７は、根ファイル以外の各ファイルについては、根ファイルから当該ファイルまでのパス上の各ファイルに対する各操作に応じて優先度を算出してもよい。例えば、優先度算出部３３７は、ファイル６１１と６１２に対する各操作に応じてファイル６１２の優先度を算出してもよく、ファイル６１１と６１２と６１３に対する各操作に応じてファイル６１３の優先度を算出してもよい。
それにより、優先度算出部３３７は、ある先祖ファイル（ただし根ファイル以外）の優先度よりも、その子孫ファイルの優先度の方を高く評価することができる。その結果、優先度算出部３３７は、葉ファイルの優先度を中間ファイルの優先度よりも高く評価することが可能となる。
以上説明したように、根ファイルと葉ファイルの優先度を中間ファイルの優先度よりも高く評価するために、優先度算出部３３７は、例えば、定義７０２に例示されるような式を用いて各ファイルの優先度を算出してもよい。なお、定義７０２中のそれぞれの式の詳細については後述する。
さて、ファイルツリー６２０は、３つのファイル６２１〜６２３を含む。ファイル６２１は根ファイルであり、ファイル６２２はファイル６２１の子ファイルである。ファイル６２３は、ファイル６２２の子ファイルであり、かつ、葉ファイルである。また、ファイル６２１〜６２３のデータは互いに等しい。よって、ファイル６２１〜６２３は、同一データグループ６２４に属する。
ファイルツリー６１０と６２０を比較すると明らかなように、もしファイル６１１と６２１の重要性が同じであれば、ファイル６１１が失われると生じる損害の方が、ファイル６２１が失われると生じる損害よりも大きい。なぜなら、ファイル６２１が仮に失われたとしても、ファイル６２２と６２３がファイル６２１のバックアップコピーとして利用可能だからである。
よって、同一データグループに２つ以上のファイルが含まれる場合、優先度算出部３３７は、同一データグループ内の各ファイルの優先度を下げることが好ましい。例えば、優先度算出部３３７は、同一データグループに含まれるファイルの個数に対して単調減少するような関数を使ってもよい。優先度算出部３３７は、優先度を下げるために、１未満の適宜の整数を掛ける乗算を行ってもよい。
ところで、１つの同一データグループに属する複数のファイルは、すべて１台の端末内に記憶されている場合もあり得るし、２台以上の端末に分散している場合もあり得る。明らかに、１つの同一データグループに属する複数のファイルが多くの端末に分散しているほど、ファイルをバックアップする必要性が低い。
そこで、優先度算出部３３７は、「１つの同一データグループに属する複数のファイルが何台の端末に分散しているか」ということに応じて、優先度を調整することが好ましい。例えば、優先度算出部３３７は、１つの同一データグループに属するファイルを１個以上記憶している端末の台数に対して単調減少するような関数を使ってもよい。
以上のような、同一データグループを考慮に入れた優先度の算出のために、優先度算出部３３７は、例えば定義７０３に例示されるような式を用いて各ファイルの優先度を算出してもよい。なお、定義７０３中のそれぞれの式の詳細については後述する。
さて、ファイルツリーの中には、ファイルツリー６３０のような複雑なものも存在し得る。ファイルツリー６３０は、図１２に示すようにファイル６３１〜６３９を含む。ファイルツリー６３０に示すように、１つの親ファイルから複数の子ファイルが派生する場合もあり得る（例えば、ファイル６３２の子ファイルの数は３つである）。また、ファイルツリー６３０内において、ファイル６３１、６３３、および６３７は１つの同一データグループ６４０に属し、ファイル６３２と６３４も１つの同一データグループ６４１に属する。しかし、他のファイルは、互いにデータが異なる。
例えば、優先度算出部３３７が根ファイル６３１の優先度を算出する処理は、次の２つの処理を含むことが好ましい。
・子孫ファイル６３２〜６３９に対して行われた各操作を考慮に入れて優先度を上げる処理。
・同一データグループ６４０に３つのファイルが含まれることを考慮に入れて優先度を下げる処理。
さて、図１４〜図１５は、図１１のステップＳ３０２に示したバックアップ制御処理のフローチャートである。このバックアップ制御処理は、図１３に関して説明したような優先度の調整を含む。
まずステップＳ５０１で、優先度算出部３３７は、ＩＤテーブル５１１を参照し、デバイスＩＤとファイルＩＤの全ペアを抽出する。より正確には、優先度算出部３３７は、ＩＤテーブル５１１に記録されているデバイスＩＤとファイルＩＤのペアのうち、当該ペアに対応する履歴テーブルが存在するすべてのペアを抽出する。すなわち、優先度算出部３３７は、まだ削除されていない各ファイルを識別するデバイスＩＤとファイルＩＤを抽出する。
また、ステップＳ５０２で優先度算出部３３７は、ＤＢ５１０中のすべての履歴テーブルを参照し、全ユニーク値を抽出する。具体的には、優先度算出部３３７は、各履歴テーブル内において日時が最新のエントリにおけるユニーク値を抽出する。こうして得られる複数のユニーク値の中には、互いに等しいものもあり得る。例えば、ファイル６２１〜６２３のユニーク値は等しい。
よって、優先度算出部３３７は、重複したユニーク値を除く。なお、上述のとおり、説明の簡単化のため、ユニーク値の衝突は無視して差し支えないものとする。
続くステップＳ５０３〜Ｓ５０８は、各ユニーク値に対する繰り返しループを形成している。
ステップＳ５０３で優先度算出部３３７は、ステップＳ５０２で抽出したユニーク値の中に未選択のものがあるか否かを判断する。未選択のユニーク値がある場合、優先度算出部３３７は、次のステップＳ５０４で、未選択のユニーク値を１つ選択する。逆に、抽出した全ユニーク値が選択済みの場合、バックアップ制御処理はステップＳ５０９へ移行する。
さて、ステップＳ５０４で選択されたユニーク値を、以下では「選択ユニーク値」という。ステップＳ５０４での選択に続いて、ステップＳ５０５で優先度算出部３３７は、選択ユニーク値に複数のファイルが対応するか否かを判断する。
選択ユニーク値に複数のファイルが対応する場合とは、同一データグループに複数のファイルが含まれる場合である。具体的には、日時が最新のエントリの「ユニーク値」のフィールドに選択ユニーク値が記録されている履歴テーブルがＤＢ５１０中に２つ以上存在する場合、選択ユニーク値には複数のファイルが対応する。
選択ユニーク値には１つのファイルのみが対応する場合、バックアップ制御処理はステップＳ５０６に移行する。逆に、選択ユニーク値に複数のファイルが対応する場合、バックアップ制御処理はステップＳ５０７に移行する。
ステップＳ５０６で優先度算出部３３７は、選択ユニーク値に対応する１つのファイルに対して行われた操作に基づいて、選択ユニーク値に対応する「個別優先度」を算出する。以下では、あるユニーク値「ｕ」に対応する個別優先度を「ｐ（ｕ）」と示す。
個別優先度ｐ（ｕ）は、ユニーク値ｕに対応する１つ以上のファイルの各々に対する各操作に基づく値である。ステップＳ５０６では、選択ユニーク値に対応するファイルの個数は１個なので、ステップＳ５０６で算出される個別優先度ｐ（ｕ）は、ユニーク値ｕに対応する１つファイルに対する各操作に基づく値である。
個別優先度ｐ（ｕ）は、例えば、式（３）により定義されてもよい。
Figure 2014063217
式（３）における「Ｈ（ｕ）」は、ユニーク値ｕに関する履歴情報のエントリの数である。例えば、ユニーク値ｕに対応するファイルが１個あって、当該ファイルに対応する履歴テーブルが４個のエントリを有する場合、Ｈ（ｕ）＝４である。
式（３）における「ｆ（ｈ）」は、図１３の定義７０１中の関数ｆａのいずれかである（ただし１≦ａ）。例えば、Ｈ（ｕ）個のエントリのうちのｈ番目のエントリのログ種別が「作成」の場合、ｆ（ｈ）＝ｆ１（Ｎｏｗ−ｔ）である。なお、前述のとおり「Ｎｏｗ」は現在時刻を示す。また、「ｔ」は、Ｈ（ｕ）個のエントリのうちのｈ番目のエントリにおける日時を示し、「Δｔ」は、Ｈ（ｕ）個のエントリのうちのｈ番目のエントリにおける利用時間を示す。
ステップＳ５０６で優先度算出部３３７は、例えば上記の式（３）にしたがって、選択ユニーク値に対応する個別優先度を算出する。なお、ステップＳ５０６は、選択ユニーク値には１つのファイルのみが対応する場合に実行される。よって、優先度算出部３３７は、具体的には、当該１つのファイルに対して行われた操作に基づいて（すなわち、当該１つのファイルに対応する履歴テーブルに基づいて）、個別優先度を算出する。
優先度算出部３３７は、算出した個別優先度を、選択ユニーク値に対応づけて記憶する。例えば、優先度算出部３３７は、選択ユニーク値と個別優先度のペアをＲＡＭ２０２上に記憶する。そして、バックアップ制御処理はステップＳ５０３に戻る。
さて、選択ユニーク値に複数のファイルが対応する場合、優先度算出部３３７は、ステップＳ５０７で、それら複数のファイルに対して行われた操作に基づいて、選択ユニーク値に対応する個別優先度を算出する。ステップＳ５０７でも、優先度算出部３３７は、例えば上記の式（３）を用いる。
例えば、選択ユニーク値に対応するファイルが３個あって、各ファイルに対応する履歴テーブル中のエントリ数がそれぞれ２個、５個、１個の場合には、式（３）においてＨ（ｕ）＝８である。この場合、ステップＳ５０７で優先度算出部３３７は、３つの履歴テーブル中の合計８個のエントリに基づいて、式（３）を使って個別優先度を算出する。
そして、次のステップＳ５０８で優先度算出部３３７は、ステップＳ５０７で算出した個別優先度から、選択ユニーク値に対応する「コピー優先度」を算出する。以下では、あるユニーク値「ｕ」に対応するコピー優先度を「ｑ（ｕ）」と示す。
コピー優先度ｑ（ｕ）は、ユニーク値ｕに対応するファイルがどのように分散して記憶されているかに応じて、個別優先度ｐ（ｕ）を調整した値を示す。例えば、コピー優先度は式（４）により定義されてもよく、式（４）中の関数ｇは式（５）のように定義されてもよい。
Figure 2014063217
Figure 2014063217
式（４）における「Ｍ」は、ユーザが使う端末の数である（１≦Ｍ）。式（４）と（５）における「ｃｍ」は、ｍ番目（１≦ｍ≦Ｍ）の端末内における、ユニーク値ｕのファイルの個数を示す（０≦ｃｍ）。
そして、式（４）における「ｎ（ｕ）」は、Ｍ台の端末のうちで、ユニーク値ｕのファイルを少なくとも１つ記憶している端末の台数である。なお、ステップＳ５０２で抽出されるユニーク値は、どれも、Ｍ台の端末のいずれかに現在、実際に記憶されているファイルのユニーク値である。よって、０＜ｎ（ｕ）が成り立つ。
例えば、図１３の同一データグループ６４０に属するファイル６３１と６３３と６３７に共通のユニーク値がｕであり、ユーザが２台の端末３１０と３３０を使っているとする。
例えば、もし、ファイル６３１が端末３１０に記憶されており、ファイル６３３と６３７が端末３３０に記憶されていれば、ｃ１＝１かつｃ２＝２かつｎ（ｕ）＝２である。別の例として、もし、ファイル６３１と６３３と６３７がすべて端末３３０に記憶されていれば、ｃ１＝０かつｃ２＝３かつｎ（ｕ）＝１である。
式（４）と（５）から明らかなように、ユニーク値ｕを持つ複数のファイルが多くの端末に分散して記憶されていれば、コピー優先度は低い。また、１台の端末内にユニーク値ｕを持つファイルが沢山ある場合も、コピー優先度は低い。
以上のようにしてコピー優先度を算出すると、優先度算出部３３７は、算出したコピー優先度を選択ユニーク値に対応づけて記憶する。例えば、優先度算出部３３７は、選択ユニーク値とコピー優先度のペアをＲＡＭ２０２上に記憶する。そして、バックアップ制御処理はステップＳ５０３に戻る。
ところで、ユニーク値ｕに対応するファイルがＭ台の端末の中に１つしかない場合、式（４）と（５）によればｑ（ｕ）＝ｐ（ｕ）である。なぜなら、この場合、式（４）と（５）の定義より、ｎ（ｕ）＝１が成り立ち、ｃｍ＞０を満たすｍが１つだけ存在し、そのようなｍに関して具体的にはｃｍ＝１が成り立ち、したがって、ｑ（ｕ）＝ｇ（ｐ（ｕ），１）＝ｐ（ｕ）が成り立つからである。
つまり、式（４）と（５）は、ユニーク値ｕに対応するファイルが１つしかない場合にｑ（ｕ）＝ｐ（ｕ）が成り立つように定義されている。実施形態によっては、ユニーク値ｕに対応するファイルが１つしかない場合にｑ（ｕ）＝ｐ（ｕ）が成り立つように定義された他の式が、式（４）と（５）の代わりに使われてもよい。
例えば、式（４）における（ｎ（ｕ））２による除算は、（ｎ（ｕ））αによる除算に置き換えられてもよい（αは１より大きい定数）。式（４）では、Ｍのオーダとｎ（ｕ）のオーダが同程度であることを考慮に入れて、ｎ（ｕ）に応じて優先度を下げる効果を得るために、単なるｎ（ｕ）による除算ではなく、（ｎ（ｕ））２による除算が採用されている。同様の考慮に基づいて、αは１より大きいことが望ましい。また、式（５）におけるｃｍによる除算は、ｃｍ βによる除算に置き換えられてもよい（βは１より大きい定数）。
さて、以上のステップＳ５０３〜Ｓ５０８によれば、ステップＳ５０９の実行時点においては、ステップＳ５０２で抽出された各ユニーク値に対応する個別優先度またはコピー優先度が、例えばＲＡＭ２０２に記憶されている。また、ユニーク値ｕに対応するファイルが１つしかない場合、上記のとおりｑ（ｕ）＝ｐ（ｕ）なので、この場合は個別優先度をコピー優先度と見なすことができる。したがって、ステップＳ５０９の実行時点においては、ステップＳ５０２で抽出された各ユニーク値に対応するコピー優先度ｑ（ｕ）が、例えばＲＡＭ２０２に記憶されている。
続くステップＳ５０９〜Ｓ５１８は、各ファイル（つまり、ステップＳ５０１で抽出された各ペアにより識別される各ファイル）に対する繰り返しループを形成している。ステップＳ５０９〜Ｓ５１８において、優先度算出部３３７は、各ファイルの優先度を式（６）にしたがって算出する。
Figure 2014063217
式（６）において、「ｘ」と「ｙ」はファイルを示し、「ｒ（ｘ）」はファイルｘの優先度を示す。また、「ｄ（ｘ）」はファイルｘのユニーク値を示し、「Ａ」は正の定数である。根ファイルと葉ファイルの優先度のバランスを良くするためには、定数Ａは１未満であることが好ましい。
また、「ｔｒｅｅ（ｘ）」は、ファイルｘを含むファイルツリーに含まれるファイルの集合を示す。例えば、ファイルｘが図１３のファイル６３１の場合、集合ｔｒｅｅ（ｘ）は、ファイルツリー６３０内の９個のファイル６３１〜６３９を含む。そして、「ｒｏｏｔ（ｘ）」は、ファイルｘを含むファイルツリーの根ファイルを示す。例えば、ファイルｘが図１３のファイル６３６の場合、ｒｏｏｔ（ｘ）はファイル６３１である。
なお、説明の簡単化のため、式（６）と図１３には明示していないが、ときには、「あるファイルツリー中の一部のファイルが既に削除されている」という状況も生じ得る。例えば、図１３のファイルツリー６３０において、ファイル６３２と６３６が既に削除されており、残りの７個のファイルのみが現存している場合があり得る。
仮にファイル６３２が削除されたとしても、ファイル６３２の子ファイル６３４がファイルツリー６３０に属することには変わりない。よって、第２実施形態では、ファイル６３２が削除されても、ＩＤテーブル５１１中のファイル６３２に対応するエントリは削除されないし、追跡テーブル５１３中のファイル６３２に関わるエントリは削除されない。他方、ファイル６３２に対応する履歴テーブルは不要なので削除される。
ファイルｙが既に削除されている場合、式（６）では、ｑ（ｄ（ｙ））＝０と見なされる。つまり、後述のステップＳ５１４またはＳ５１６での総和の算出においては、ファイルツリー中の削除済みのファイルに関しては、優先度としてゼロが使われる。
なお、ＤＢ管理部３３５は、適宜のタイミングで、「当該ファイルツリーに属するすべてのファイルが削除済みであるようなファイルツリー」を探してもよい。そして、もしそのようなファイルツリーが見つかれば、ＤＢ管理部３３５は、見つかったファイルツリーに関連する全エントリを、ＩＤテーブル５１１と追跡テーブル５１３から削除してもよい。
さて、以下にステップＳ５０９〜Ｓ５１８の詳細を説明する。
ステップＳ５０９で優先度算出部３３７は、未選択のファイル（つまり、ステップＳ５０１で抽出されたデバイスＩＤとファイルＩＤのペアのうち、未選択のペアにより識別されるファイル）が残っているか否かを判断する。未選択のファイルがある場合、バックアップ制御処理はステップＳ５１０に移行する。逆に、すべてのファイルが選択済みの場合（つまりすべてのファイルについて優先度が算出済みの場合）、バックアップ制御処理は、図１５のステップＳ５１９に移行する。
ステップＳ５１０で優先度算出部３３７は、未選択のファイルを１つ選択する。以下では、ステップＳ５１０で選択されたファイルを「選択ファイル」という。
そして、次のステップＳ５１１で優先度算出部３３７は、選択ファイルの親ファイルが存在するか否かを判断する。具体的には、優先度算出部３３７は、選択ファイルを識別するデバイスＩＤとファイルＩＤが、子デバイスＩＤと子ファイルＩＤとして記憶されているエントリを、追跡テーブル５１３内において検索する。
そのようなエントリが見つからない場合、選択ファイルは親ファイルを持たない。つまり、選択ファイルは根ファイルである。この場合、バックアップ制御処理はステップＳ５１２に移行する。
逆に、上記のようなエントリが見つかった場合、選択ファイルの親ファイルが存在する。つまり、選択ファイルは中間ファイルまたは葉ファイルである。この場合、バックアップ制御処理はステップＳ５１５に移行する。
ステップＳ５１２で優先度算出部３３７は、選択ファイルの子ファイルが存在するか否かを判断する。具体的には、優先度算出部３３７は、選択ファイルを識別するデバイスＩＤとファイルＩＤが、親デバイスＩＤと親ファイルＩＤとして記憶されているエントリを、追跡テーブル５１３内において検索する。
そのようなエントリが見つからない場合、選択ファイルは子ファイルを持たない。つまり、選択ファイルの属するファイルツリーには、選択ファイルのみが含まれる。この場合、バックアップ制御処理はステップＳ５１３に移行する。
逆に、上記のようなエントリが見つかった場合、選択ファイルの子ファイルが存在する。つまり、選択ファイルを根ファイルとして含むファイルツリーは、１つ以上の子孫ファイルをさらに含む。この場合、バックアップ制御処理はステップＳ５１４に移行する。
ステップＳ５１３で優先度算出部３３７は、選択ファイルのユニーク値に対応する優先度（すなわち、選択ファイルのユニーク値に対応づけられて記憶されているｑ（ｕ）の値）を、選択ファイルの優先度ｒ（ｘ）として決定する。ステップＳ５１３は式（６）の右辺の３番目のケースに該当する。
そして、優先度算出部３３７は、決定した優先度ｒ（ｘ）を、選択ファイルに対応づけて（具体的には、選択ファイルを識別するデバイスＩＤとファイルＩＤのペアに対応づけて）、例えばＲＡＭ２０２に記憶する。その後、バックアップ制御処理はステップＳ５０９に戻る。
さて、ステップＳ５１４で優先度算出部３３７は、選択ファイルを根とするファイルツリー内の各ファイルのユニーク値に対応する優先度の総和を算出する。
なお、優先度算出部３３７は、追跡テーブル５１３を参照することで、選択ファイルを根とするファイルツリー内に含まれるすべてのファイルを認識することができる。具体的には、ステップＳ５１２と同様の方法により子ファイルを探す処理を繰り返すことで、優先度算出部３３７は、選択ファイルを根とするファイルツリー内に含まれるすべてのファイルを認識することができる。
また、各ファイルのユニーク値は、当該ファイルに対応する履歴テーブルの中で日時が最新のエントリに記録されている。そして、上記のとおり、ステップＳ５０３〜Ｓ５０８の結果として、各ユニーク値に対応してｑ（ｕ）が記憶されている。
よって、優先度算出部３３７は、上記のごとき総和を算出することができる。優先度算出部３３７は、算出した総和を、選択ファイルの優先度ｒ（ｘ）として決定する。ステップＳ５１４は式（６）の右辺の１番目のケースに該当する。
そして、優先度算出部３３７は、決定した優先度ｒ（ｘ）を、選択ファイルに対応づけて、例えばＲＡＭ２０２に記憶する。その後、バックアップ制御処理はステップＳ５０９に戻る。
さて、ステップＳ５１５で優先度算出部３３７は、選択ファイルの子ファイルが存在するか否かを判断する。ステップＳ５１５における判断は、ステップＳ５１２と同様に、追跡テーブル５１３を検索する処理により実現される。
選択ファイルが子ファイルを持たない場合（つまり、選択ファイルが葉ファイルである場合）、バックアップ制御処理はステップＳ５１６に移行する。逆に、選択ファイルが子ファイルを持つ場合（つまり、選択ファイルが中間ファイルである場合）、バックアップ制御処理はステップＳ５１８に移行する。
ステップＳ５１６で優先度算出部３３７は、選択ファイルを含むファイルツリー内の各ファイルのユニーク値に対応する優先度の総和を算出する。
具体的には、まず、優先度算出部３３７は、追跡テーブル５１３を参照することにより、葉ファイルからパスをたどって根ファイルを特定する。例えば、選択ファイルが図１３のファイル６３８である場合、優先度算出部３３７は、追跡テーブル５１３を参照することで、ファイル６３８の親ファイルがファイル６３３であることを認識する。そして、優先度算出部３３７は、追跡テーブル５１３を参照することで、ファイル６３３の親ファイルがファイル６３１であることを認識する。さらに優先度算出部３３７は、追跡テーブル５１３を参照することで、ファイル６３１が親ファイルを持たないことを認識する。以上のようにして、優先度算出部３３７は、選択ファイル６３８に基づいて、根ファイル６３１を特定する。
そして、優先度算出部３３７は、上記のようにして特定したファイルを根とするファイルツリー内の、各ファイルのユニーク値に対応する優先度の総和を、ステップＳ５１４と同様の方法により算出する。以上のようにしてステップＳ５１６で算出される総和は、式（６）におけるｒ（ｒｏｏｔ（ｘ））である。
次に、ステップＳ５１７で優先度算出部３３７は、選択ファイルのユニーク値に対応する優先度と、ステップＳ５１６で算出した総和から、選択ファイルの優先度を算出する。つまり、優先度算出部３３７は、式（６）の定数Ａを上記の算出した総和に掛けて積を求め、求めた積と、選択ファイルのユニーク値に対応づけられて記憶されているｑ（ｕ）の値との和を、選択ファイルの優先度ｒ（ｘ）として算出する。
そして、優先度算出部３３７は、算出した優先度ｒ（ｘ）を、選択ファイルに対応づけて、例えばＲＡＭ２０２に記憶する。その後、バックアップ制御処理はステップＳ５０９に戻る。
さて、ステップＳ５１８で優先度算出部３３７は、ステップＳ５１３と同様に、選択ファイルのユニーク値に対応する優先度（すなわち、選択ファイルのユニーク値に対応づけられて記憶されているｑ（ｕ）の値）を、選択ファイルの優先度ｒ（ｘ）として決定する。ステップＳ５１８も、式（６）の右辺の３番目のケースに該当する。
そして、優先度算出部３３７は、決定した優先度ｒ（ｘ）を、選択ファイルに対応づけて、例えばＲＡＭ２０２に記憶する。その後、バックアップ制御処理はステップＳ５０９に戻る。
さて、以上のステップＳ５０９〜Ｓ５１８によれば、現存する全ファイルに対して優先度ｒ（ｘ）が算出される。そして、全ファイルに対して優先度ｒ（ｘ）が算出されると、バックアップ制御部３３９によりステップＳ５１９〜Ｓ５２１が実行される。
ステップＳ５１９でバックアップ制御部３３９は、バックアップ容量を決める。例えば、バックアップ制御部３３９は、バックアップ容量に関するユーザからの入力を、ステップＳ５１９で入力装置２０５から受け付けてもよい。あるいは、バックアップ制御部３３９は、予め設定ファイルなどに設定されたバックアップ容量の値を、ステップＳ５１９で読み込んでもよい。
そして、ステップＳ５２０でバックアップ制御部３３９は、優先度算出部３３７により算出されて記憶された優先度の降順に、バックアップ容量の範囲内で、バックアップ対象のファイルを選ぶ。ステップＳ５２０は図１のステップＳ６〜Ｓ７と同様である。
最後に、ステップＳ５２１でバックアップ制御部３３９は、選んだファイルをバックアップ記憶部３３８にバックアップする。そして、バックアップ制御処理は終了する。
なお、バックアップ対象のファイルは、多くの場合、２台以上の端末に分散している。よって、ステップＳ５２１では、バックアップ制御部３３９は、ユーザが使う全端末をネットワーク３７０に接続するようにユーザに促すプロンプトを出力装置２０６に表示してもよい。
例えば、バックアップ制御処理が開始される時点で端末３１０の電源はオフになっているかもしれない。しかし、プロンプトに応じてユーザが端末３１０の電源をオンにすると、端末３３０は、端末３１０内のファイルをネットワーク３７０を介して受信し、受信したファイルをバックアップ記憶部３３８にバックアップすることが可能となる。
また、ファイルのバックアップにはある程度の時間がかかる。よって、ＶＳＳ（Volume Shadow Copy Service）などのスナップショット技術が利用されてもよい。つまり、バックアップ制御部３３９は、ステップＳ５２１でスナップショットを作成してもよく、スナップショットの作成後、直ちに図１１の処理はステップＳ３０２からステップＳ３０１に戻ってもよい。
例えば、より具体的には、バックアップ制御部３３９は、端末３３０のファイル記憶部３３２のスナップショットを作成するとともに、ファイル記憶部３１２のスナップショットを作成するように端末３１０に命令してもよい。こうしてスナップショット技術を利用することで、端末３３０は、実際にいくつものファイルをファイル記憶部３３２および３１２からバックアップ記憶部３３８へとバックアップするのと並行して、図１１のステップＳ２０１〜２１６を実行することも可能である。
以上説明したように、第２実施形態によれば、第１実施形態と同様に、バックアップが効率化される。また、第１実施形態と第２実施形態のいずれにおいても、バックアップスケジュールとバックアップ容量を適宜に設定することにより、優先度の高いファイルをより高い頻度でバックアップすることが可能となる。
例えば、「毎週月曜日にファイルをバックアップする」というスケジュールが決められているとする。この場合、さらに、例えば、「第１月曜日におけるバックアップ容量は５０ＧＢであり、その他の月曜日におけるバックアップ容量は１５ＧＢである」と決められていてもよい。すると、大まかには、以下のような傾向に沿ってファイルのバックアップが行われることになる。
・優先度が高いファイルは、毎週月曜日にバックアップされる。
・優先度が中程度のファイルは、第１月曜日にのみバックアップされる。
・優先度が低いファイルは、バックアップされない。
もちろん、各ファイルに対して行われる操作に応じて、優先度は、日々動的に変動し得るが、大まかには以上のごとき傾向が見られるであろう。このように、第１実施形態と第２実施形態のいずれにおいても、優先度の高いファイルをより高い頻度でバックアップすることが可能である。
なお、上記の例は「高・中・低」の３段階の優先度に応じてバックアップ頻度を３段階に分ける例である。しかし、バックアップスケジュールとバックアップ容量を適宜に設定することにより、バックアップ頻度を４段階以上に分けることも可能である。
続いて、図１６〜２０を参照して第３実施形態について説明する。なお、第２実施形態との共通点については、適宜説明を省略する。
図１６は、第３実施形態のシステム構成図である。図１６のシステム８００は、端末８１０、８３０、８５０とサーバ８７０を含む。端末８１０は、図１６の例ではネットワーク８９０に接続可能であるが、ネットワーク通信機能がなくても問題ない。端末８３０と８５０はネットワーク８９０に接続可能な端末であるものとする。また、サーバ８７０もネットワーク８９０に接続される。ネットワーク８９０の種類は任意である。
例えば、端末８１０は、図２のカメラ１０９でもよい。カメラ１０９は、例えば無線ＬＡＮによる通信機能を有していてもよく、無線ＬＡＮを介してＰＣ１０６と通信を行ってもよい。もちろん、カメラ１０９の無線ＬＡＮ通信機能は省略可能である。カメラ１０９は、例えばＵＳＢケーブルにより直接ＰＣ１０６に接続されてもよい。もちろん、端末８１０は、図２のスマートフォン１０２またはタブレット端末１０４であってもよい。
端末８３０は、図４の端末３３０と類似の端末である。端末８３０は、例えば図２のＰＣ１０６であってもよい。
端末８５０は、例えば図２のスマートフォン１０２でもよいし、タブレット端末１０４でもよい。端末８５０は、端末８３０とは別のＰＣであってもよい。
サーバ８７０は、図２の管理サーバ１１２とコンテンツサーバ１１３を兼ねるコンピュータであってもよい。ネットワーク８９０は、図２のネットワーク１０１であってもよい。
以下、システム８００内の各装置の詳細について説明する。
端末８１０は、通信部８１１と、作成部８１２と、ファイル記憶部８１３と、デバイスＩＤ記憶部８１４を有する。通信部８１１は、ネットワーク８９０を介して端末８３０と通信を行ってもよいし、端末８３０に接続されたＵＳＢケーブルなどの接続を介して端末８３０と通信を行ってもよい。通信部８１１はさらに、ネットワーク８９０を介してサーバ８７０と通信を行ってもよい。
作成部８１２はファイルを作成し、作成されたファイルはファイル記憶部８１３に記憶される。また、デバイスＩＤ記憶部８１４は、端末８１０を識別するデバイスＩＤを記憶する。
例えば、端末８１０は、カメラ１０９であってもよい。カメラ１０９も図３の情報処理装置２００の一種である。
例えば、通信部８１１は、無線ＬＡＮ通信用のネットワーク通信装置２０３により実現されてもよいし、ＵＳＢケーブルなどのシリアル接続用のシリアル接続Ｉ／Ｆ回路２０４により実現されてもよい。カメラ１０９ではネットワーク通信装置２０３は省略可能である。
端末８１０がカメラ１０９である場合、作成部８１２は、写真の画像ファイルを作成する。つまり、作成部８１２は、レンズ、光電変換回路、およびＣＰＵ２０１などのハードウェア要素により実現されてもよい。ファイル記憶部８１３は、カメラ１０９のリーダ／ライタ２０８にセットされた記憶媒体２１０（より具体的には半導体メモリカード）により実現されてもよい。デバイスＩＤ記憶部８１４は、不揮発性記憶装置２０７（例えばＲＯＭまたはフラッシュメモリ）により実現されてもよい。例えば、製造シリアル番号が、デバイスＩＤとしてデバイスＩＤ記憶部８１４に記憶されていてもよい。
もちろん、端末８１０は、スマートフォン１０２、タブレット端末１０４、またはＰＣ１０６であってもよい。
端末８３０は、上記のとおり図４の端末３３０と類似の端末である。端末８３０は、通信部８３１、ファイル記憶部８３２、監視部８３３、デバイスＩＤ記憶部８３４、ＤＢ管理部８３５、ＤＢ記憶部８３６、優先度算出部８３７、バックアップ記憶部８３８、およびバックアップ制御部８３９を有する。また、端末３３０と同様に、端末８３０も、情報処理装置２００によって実現されてもよい。
通信部８３１は、ネットワーク８９０またはＵＳＢケーブルなどの有線接続を介して、端末８１０と通信を行う。また、通信部８３１は、ネットワーク８９０を介して、サーバ８７０および端末８５０と通信を行う。例えば、通信部８３１は、ネットワーク通信装置２０３により実現されてもよい。通信部８３１は、ネットワーク通信装置２０３とシリアル接続Ｉ／Ｆ回路２０４の双方により実現されてもよい。
ファイル記憶部８３２、監視部８３３、およびデバイスＩＤ記憶部８３４は、端末３３０のファイル記憶部３３２、監視部３３３、およびデバイスＩＤ記憶部３３４と同様である。よって、詳細な説明は省略する。ファイル記憶部８３２には、図７のＤＢ５１０と同様のＤＢが記憶される。
ＤＢ管理部８３５は、端末３３０のＤＢ管理部３３５と同様の処理を行い、さらに、他の端末により作成されたファイルに関する情報を推定する処理も行う。ＤＢ管理部８３５が行う推定の詳細については、図１７〜１８とともに後述する。ＤＢ管理部８３５は、プログラムを実行するＣＰＵ２０１により実現されてもよい。
ＤＢ記憶部８３６、優先度算出部８３７、バックアップ記憶部８３８、およびバックアップ制御部８３９は、端末３３０のＤＢ記憶部３３６、優先度算出部３３７、バックアップ記憶部３３８、およびバックアップ制御部３３９と同様である。よって、詳細な説明は省略する。
さて、端末８５０は、通信部８５１と、ファイル記憶部８５２と、デバイスＩＤ記憶部８５３を有する。
通信部８５１は、ネットワーク８９０を介して端末８３０およびサーバ８７０と通信を行う。通信部８５１は、ネットワーク８９０を介してさらに端末８１０と通信を行ってもよい。通信部８５１は、例えばネットワーク通信装置２０３により実現されてもよい。
ファイル記憶部８５２は、種々のファイルを記憶する。デバイスＩＤ記憶部８５３は、端末８５０を識別するデバイスＩＤを記憶する。ファイル記憶部８５２とデバイスＩＤ記憶部８５３は、例えば不揮発性記憶装置２０７により実現されてもよい。
なお、図１６では省略されているが、端末８１０、８３０、および８５０は、それぞれ入力装置２０５と出力装置２０６を有する。
ところで、サーバ８７０は、通信部８７１、ＤＢ記憶部８７２、デバイス管理部８７３、ＤＢ管理部８７４、およびファイル記憶部８７５を有する。
通信部８７１は、ネットワーク８９０を介して、端末８３０および８５０と通信を行う。通信部８７１は、例えばネットワーク通信装置２０３により実現されてもよい。
ＤＢ記憶部８７２は、サーバ３５０のＤＢ記憶部３５２と同様である。ＤＢ記憶部８７２は、不揮発性記憶装置２０７により実現されてもよい。
デバイス管理部８７３は、サーバ３５０のデバイス管理部３５３と似ている。ただし、デバイス管理部８７３が保持するデバイス管理テーブル（不図示）の形式は、デバイス管理部３５３が保持する図８のデバイス管理テーブル５２０とは異なる。具体的には、デバイス管理部８７３が保持するデバイス管理テーブル中の各エントリは、ユーザＩＤおよびデバイスＩＤだけでなく、デバイスがメタデータを生成する機能を持つか否かを示すフラグを含む。デバイス管理部８７３は、例えば、デバイス管理テーブルを記憶する不揮発性記憶装置２０７と、デバイス管理テーブルを用いた処理を実行するＣＰＵ２０１によって、実現されてもよい。
ＤＢ管理部８７４は、第２実施形態でサーバ３５０のＤＢ管理部３５４が行う処理と似た処理を実行するだけでなく、端末３３０の監視部３３３およびＤＢ管理部３３５が行う処理と似た処理も実行する。
具体的には、第３実施形態のサーバ８７０は、ネットワーク８９０を介して種々の端末からそれぞれファイルのアップロードを受け付け、アップロードされたファイルをファイル記憶部８７５に記憶する。また、サーバ８７０は、ファイル記憶部８７５に記憶されたファイルに対するダウンロード要求も受け付ける。
つまり、第３実施形態のサーバ８７０は、図２の管理サーバ１１２とコンテンツサーバ１１３を兼ねている。そして、サーバ８７０は、ファイルの送受信を行うという点において、第２実施形態の端末３３０と似ている。そのため、ＤＢ管理部８７４は、端末３３０の監視部３３３とＤＢ管理部３３５が行う処理と似た処理も実行する。
なお、サーバ８７０はさらに、ファイル記憶部８７５に記憶されたファイルに対するその他の要求も、ネットワーク８９０を介して、種々の端末から受け付ける。例えば、サーバ８７０は、編集、移動、変名、削除、コメント追加などの操作をファイルに対して行うための要求を受け付けてもよい。
ＤＢ管理部８７４が実行する処理の詳細については、図１９〜２０とともに後述する。ＤＢ管理部８７４は、例えば、プログラムを実行するＣＰＵ２０１により実現されてもよい。ファイル記憶部８７５は、不揮発性記憶装置２０７により実現されてもよい。
ところで、上記の第２実施形態に関しては、ある１人のユーザが使う複数の端末（例えば、端末３１０と３３０）に分散している複数のファイルそれぞれの優先度の算出について詳しく説明した。上記のとおり、第２実施形態における優先度は、当該ユーザが各ファイルに対して行った各操作に基づいて算出される。しかし、上記の第２実施形態では、他のユーザは優先度とは無関係である。
しかし、第３実施形態では、あるユーザの所有する（own）ファイルに対する、他のユーザの行為も、当該ファイルの優先度に反映される。例えば、あるユーザの所有するファイルは、サーバ８７０にアップロードされてファイル記憶部８７５に記憶されてもよく、他の１人以上の特定または不特定のユーザに対して公開されてもよい。サーバ８７０にアップロードされて公開されたファイルに対して、他のユーザたちは、例えば以下のような行為（action）を行う可能性がある。
・ファイルを閲覧またはダウンロードする行為。
・ファイルにコメントやタグなどの付加的情報を加える行為。
・ファイルへの参照リンクを生じさせる行為（例えばトラックバック）。
また、ファイルに対する評価や参照などを、ＳＮＳ（Social Networking Service）を介してユーザ間で共有するために、サーバ８７０上のウェブページには、ファイルに対応づけられたユーザインタフェイス要素（例えばボタン）が設けられることがある。このようなユーザインタフェイス要素には、ファイルに対する評価や参照などを、ＳＮＳを介してユーザ間で共有するための、ＳＮＳ固有の機能が割り当てられている。
例えば、このようなボタン（より具体的には、例えば「いいね！（Like）ボタン」など）をクリックする行為も、あるユーザの所有するファイルに対して他のユーザが行う可能性のある行為のうちの一つである。つまり、ユーザインタフェイス要素に割り当てられた上記の機能を呼び出す行為が、他のユーザにより行われる可能性がある。
第３実施形態では、例えば以上例示したような、他のユーザによる行為も、優先度の算出において考慮される。
例えば、サーバ８７０がコメント機能をサポートしている場合、第１のユーザの端末からサーバ８７０にアップロードされたファイルに対して、第２のユーザがサーバ８７０上でコメントを付加する場合があり得る。第１のユーザは、多くの他のユーザから多くのコメントが寄せられたファイルを重要と考え、他のユーザからほとんど何の反応も得られなかったファイルはさして重要でないと考えるかもしれない。
また、第１のユーザは、あるファイルを編集し、編集後のファイルをサーバ８７０にアップロードすることがある。アップロードされたファイルに対して多くの他のユーザからコメントが寄せられたりダウンロードが要求されたりした場合、第１のユーザは、編集前のオリジナルのファイルを重要と考えるかもしれない。つまり、この場合、第１のユーザは、アップロードされたファイルが属するファイルツリーの根ファイルを、重要と考えるかもしれない。
第３実施形態は、例えば上記のような考えを持つ第１のユーザにとって、特に有益である。以下では説明の便宜上、次のように仮定する。
・端末８１０と８３０は、「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザにより使われる端末である。
・端末８５０は、「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザにより使われる端末であってもよいし、「ｓａｔｏ＿ｊｉｒｏ」というユーザＩＤのユーザにより使われる端末であってもよい。
さて、上記のような仮定のもとで、第３実施形態における端末８１０、８３０、８５０とサーバ８７０の動作の概要について、図１と図１７を参照して以下に説明する。
図１に関して説明したように、図１の処理を実行する情報処理装置は、複数台の端末のうちの１台でもよいし、複数台の端末のうちの少なくとも１台以上とネットワークを介して通信を行うコンピュータ（例えばサーバ８７０）であってもよい。第３実施形態では、図１の処理を実行する情報処理装置は、具体的には端末８３０である。
図１のステップＳ１とＳ２に関して説明したように、履歴情報と追跡情報を取得するための具体的手順は、実施形態に応じて様々である。第３実施形態では、端末８３０が、履歴情報を生成することで履歴情報を取得することもあるし、追跡情報を生成することで追跡情報を取得することもある。また、端末８３０は、履歴情報をサーバ８７０から受信することで履歴情報を取得することもあるし、追跡情報をサーバ８７０から受信することで追跡情報を取得することもある。
以下、履歴情報と追跡情報を含むメタデータのやりとりの具体的な例について、図１７を参照して説明する。図１７は、第３実施形態の動作シーケンスの例を示す図である。
ステップＳ６０１で端末８１０の作成部８１２がファイル９０１を作成する。ファイル９０１はファイル記憶部８１３に記憶される。
その後、ステップＳ６０２で端末８１０と８３０が、ネットワーク８９０を介して接続されるか、または、ＵＳＢケーブルなどにより直接接続される。そして、ファイル９０１が端末８１０から端末８３０に送られる。つまり、ファイル９０１は、ファイル記憶部８１３から読み出され、通信部８１１から送信され、通信部８３１で受信されて、ファイル記憶部８３２に記憶される。
すると、ファイル記憶部８３２を監視している監視部８３３は、ファイル９０１の受信と保存を検出する。検出に応じて、ステップＳ６０３では、ＤＢ管理部８３５が、ファイル９０１の受信と保存に関する履歴情報を含むメタデータ９０２を生成する。
また、ＤＢ管理部８３５は、ファイル９０１から、ファイル９０１の送信元の端末８１０に関する情報や、端末８１０におけるファイル９０１の作成日時に関する情報を推定する。推定により何らかの情報が得られた場合、ＤＢ管理部８３５は、推定により得られた情報をメタデータ９０２に含めてもよい。
例えば、ある種のフォーマットのファイルは、プロパティを含む。プロパティには、ファイルの作成日時が含まれている場合がある。
よって、端末８３０のＤＢ管理部８３５は、端末８１０におけるファイル９０１の作成日時のフィールドを、ファイル９０１のプロパティにおいて、探してもよい。作成日時のフィールドがプロパティ内に見つかったら、ＤＢ管理部８３５は、プロパティから作成日時を読み取る。
また、ファイル９０１が画像ファイルである場合、ファイル９０１がＥｘｉｆ（Exchangeable image file format）データを含む可能性がある。Ｅｘｉｆデータは様々なフィールドを含み得る。
例えば、ファイル９０１の作成日時がファイル９０１のＥｘｉｆデータに含まれている場合がある。また、ファイル９０１を作成した端末８１０の製造シリアル番号が、ファイル９０１のＥｘｉｆデータに含まれている場合がある。
そこで、ファイル９０１がＥｘｉｆデータを含む場合には、ＤＢ管理部８３５は、作成日時と製造シリアル番号のフィールドを、Ｅｘｉｆデータの中から探してもよい。作成日時と製造シリアル番号のフィールドがＥｘｉｆデータ内に見つかったら、ＤＢ管理部８３５は、作成日時と製造シリアル番号をＥｘｉｆデータから読み取る。ＤＢ管理部８３５は、製造シリアル番号に加えて（あるいは製造シリアル番号の代わりに）、端末８１０の機種（モデル）など、端末８１０に関するその他の情報を、Ｅｘｉｆデータの中から探してもよい。
例えば以上のような処理を行うことにより、ＤＢ管理部８３５は、ファイル９０１の送信元の端末８１０に関する情報や、端末８１０におけるファイル９０１の作成日時に関する情報を推定してもよい。推定の結果、何らかの情報の取得に成功したら、ＤＢ管理部８３５は、取得した情報をメタデータ９０２に含めてもよい。
なお、上記のとおりメタデータ９０２は、端末８１０に関する推定により得られた情報だけでなく、端末８３０自体における受信と保存に関する履歴情報も含む。例えば、ＤＢ管理部８３５は、以下のようにして履歴情報を生成してメタデータ９０２に含めてもよい。
ＤＢ管理部８３５は、ファイル９０１がファイル記憶部８３２に保存された日時を、監視部８３３からの通知に基づいて認識する。また、ＤＢ管理部８３５は、ファイル９０１に対して新たなファイルＩＤを発行し、ファイル９０１が保存されたディレクトリのパスとファイル９０１の名前を取得する。さらに、ＤＢ管理部８３５は、ファイル９０１のユニーク値を算出する。
また、ＤＢ管理部８３５は、監視部８３３からの通知に基づいて、ログ種別を「受信」と判断する。なお、ＤＢ管理部８３５は、もし端末８１０の製造シリアル番号を上記のようにして取得することができた場合は、ファイル９０１の送信元を示す製造シリアル番号を含む形式で、ログ種別を表してもよい。
ＤＢ管理部８３５は、以上のようにして、ＤＢ記憶部８３６上のＤＢ中の履歴テーブルの１つのエントリに対応する新たな履歴情報を生成してもよい。そして、ＤＢ管理部８３５は、図７のＩＤテーブル５１１と同様の形式のＩＤテーブルに、ファイル９０１に対応するエントリを追加し、ファイル９０１に対応する新たな履歴テーブルを作成する。ＤＢ管理部８３５はさらに、作成した履歴テーブルに、１つのエントリ（つまり、上記のようにして生成した履歴情報を示すエントリ）を追加する。
また、次のステップＳ６０４で端末８３０は、メタデータ９０２をサーバ８７０に送信する。メタデータ９０２はサーバ８７０の通信部８７１において受信される。
すると、ステップＳ６０５では、デバイス管理部８７３が、メタデータ９０２の送信元の端末８３０のデバイスＩＤから、端末８３０のユーザを識別するユーザＩＤを求める。また、得られたユーザＩＤにしたがって、ＤＢ記憶部８７２中の適宜のＤＢに、受信されたメタデータ９０２が書き込まれる。
ところで、端末８３０からサーバ８７０に送られたメタデータ９０２は、端末８３０が端末８１０からファイル９０１を受信したことを示す。しかし、サーバ８７０は、メタデータ９０２が示す受信と対になる送信を示すメタデータ（つまり端末８１０が端末８３０にファイル９０１を送信したことを示す履歴情報）を受信することはない。なぜなら、端末８１０は、メタデータを生成する機能を持たないからである。また、端末８１０がメタデータを生成する機能を持たないことを、サーバ８７０は認識している。なぜなら、サーバ８７０のデバイス管理部８７３（より具体的にはデバイス管理テーブル）には、端末８１０が、メタデータを生成しない端末として登録されているからである。
したがって、サーバ８７０のＤＢ管理部８７４は、メタデータ９０２が示す受信と対になる送信を示すメタデータを端末８１０から受信するのを待たずに、ステップＳ６０５で追跡情報も生成してしまう。つまり、ＤＢ管理部８７４は、端末８１０に記憶されている親ファイルと、端末８１０から受信されて端末８３０に記憶された子ファイルとを対応づける追跡情報を生成する。
なお、ここで親ファイルと子ファイルのデータは互いに等しい。そのため、図１７に関する説明では、便宜上、親ファイルと子ファイルの両方を、「９０１」という参照符号を用いて参照している。
ＤＢ管理部８７４は、生成した追跡情報をＤＢ記憶部８７２に書き込む。つまり、ＤＢ管理部８７４は、ＤＢ記憶部８７２中の追跡テーブルにエントリを１つ追加する。
そして、以上のようにして生成された追跡情報を含むメタデータ９０３が、ステップＳ６０６で、サーバ８７０から端末８３０へと送られる。通信部８３１がメタデータ９０３を受信すると、ＤＢ管理部８３５は、メタデータ９０３をＤＢ記憶部８３６に記憶する。
ところで、ファイルが端末８３０とサーバ８７０の間で複製されることもあり得る。つまり、端末８３０からサーバ８７０へのアップロードによりファイルが複製される場合もあり得るし、サーバ８７０から端末８３０または８５０へのダウンロードによりファイルが複製される場合もあり得る。ステップＳ６０７は、前者の場合の一例である。
具体的には、ステップＳ６０７では、ファイル記憶部８３２に記憶されている既存のファイル９０４が、通信部８３１から送信される。ファイル９０４は、サーバ８７０の通信部８７１で受信され、ファイル記憶部８７５に保存される。
すると、ステップＳ６０８でサーバ８７０のＤＢ管理部８７４は、ファイル９０４の受信と保存に応じて、履歴情報を生成し、ＤＢ記憶部８７２のＤＢを更新する。図１７では省略されているが、生成された履歴情報は、さらにサーバ８７０から端末８３０に送信されてもよい。
また、図１７では省略されているが、ファイル９０４を送信した端末８３０は、ファイル９０４の送信を示す履歴情報を含むメタデータをさらにサーバ８７０に送信する。このように端末８３０がメタデータをサーバ８７０に送信することは、図５でファイル４０４を送信した端末３１０が、ファイル４０４の送信を示す履歴情報を含むメタデータ４０６をサーバ３５０に送信することと同様である。
すると、ＤＢ管理部８７４は、サーバ８７０における受信に関して生成した履歴情報と、端末８３０における送信に関して端末８３０から取得した履歴情報から、端末８３０・サーバ８７０間でのファイル９０４の複製操作に関する追跡情報をさらに生成する。ＤＢ管理部８７４は、生成した追跡情報をＤＢ記憶部８７２の追跡テーブルに追加する。
図１７では省略されているが、以上のようにして生成された追跡情報も、サーバ８７０から端末８３０に送信される。
具体的には、ステップＳ６０８でＤＢ管理部８７４は、サーバ８７０でファイル９０４を識別するためのファイルＩＤを発行し、ファイル記憶部８７５に記憶されたファイル９０４に関する新たな履歴テーブルを作成する。また、ＤＢ管理部８７４は、端末８３０に記憶されている親ファイルと、端末８３０から受信されてサーバ８７０に記憶された子ファイルとを対応づける追跡情報を生成する。こうして生成された追跡情報を示す新たなエントリが、ＤＢ記憶部８７２内の追跡テーブルに追加される。
なお、ここで親ファイルと子ファイルのデータは互いに等しい。そのため、図１７に関する説明では、便宜上、親ファイルと子ファイルの両方を、「９０４」という参照符号を用いて参照している。
ところで、以上のようにしてサーバ８７０にアップロードされたファイル９０４は、端末８１０と８３０を使うユーザ自身に対してのみアクセス権が与えられていてもよい。または、特定の他の１人以上のユーザに対しても、サーバ８７０上のファイル９０４に対するアクセスが許可されていてもよい。場合によっては、不特定の任意の他のユーザに対しても、サーバ８７０上のファイル９０４に対するアクセスが許可されていてもよい。
なお、アクセス権の種類は、実施形態に応じて適宜決められていてよい。例えば、特定または不特定の他の１人以上のユーザに対して、読み取りアクセス、書き込みアクセス、またはその双方が許可されていてもよい。
また、実施形態によっては、ユーザに読み取りアクセス権さえあれば以下のような行為が許されてもよい。あるいは、以下のような行為に対して、読み取りアクセス権とは別種のアクセス権が定義される実施形態も可能である。
・ファイルにコメントやタグなどの付加的情報を加える行為。
・ファイルへの参照リンクを生じさせる行為（例えばトラックバック）。
・ファイルに対する評価や参照などをＳＮＳを介してユーザ間で共有するための、ＳＮＳ固有の機能を呼び出す行為（例えば所定のボタンをクリックすることで上記機能を呼び出す行為）。
説明の簡単化のため、図１７の例では、サーバ８７０上のファイル９０４を閲覧する行為およびファイル９０４にコメントを加える行為は、任意のユーザに許可されているものとする。また、端末８５０は、端末８１０と８３０を使うユーザ自身の端末であってもよいし、他のユーザの端末であってもよい。
すると、ステップＳ６０９に示すように、サーバ８７０にアップロードされたファイル９０４に対するコメント９０５が、端末８５０からサーバ８７０に送られることがある。
すると、ファイル９０４に対して「コメント９０５の付加」という操作が行われたことを示す履歴情報を含むメタデータ９０６を、ステップＳ６１０でサーバ８７０のＤＢ管理部８７４が生成する。ＤＢ管理部８７４は、メタデータ９０６をＤＢ記憶部８７２に記憶する。
さらに、メタデータ９０６は、ステップＳ６１１で通信部８７１から送信され、端末８３０の通信部８３１で受信され、ＤＢ記憶部８３６に記憶される。
すると、後のステップＳ６１２において、ファイルをバックアップするためのトリガイベントが生じると、優先度９０７の算出において、コメント９０５の付加のような操作に関する履歴情報も考慮される。トリガイベントの発生に応じて、優先度算出部８３７は、端末８３０を使うユーザが所有する各ファイルについて、優先度９０７を算出する。具体的には、以下の各ファイルについて優先度９０７が算出される。
・端末８１０のファイル記憶部８１３に記憶されているファイル。
・端末８３０のファイル記憶部８３２に記憶されているファイル。
・端末８５０のファイル記憶部８５２に記憶されているファイル（ただし端末８５０が当該ユーザの端末である場合に限る）。
・サーバ８７０のファイル記憶部８７５に記憶されているファイルのうち、当該ユーザが所有するファイル。
そして、バックアップ制御部８３９は、バックアップする対象のファイルを優先度９０７にしたがって選択し、選択したファイルをバックアップ記憶部８３８にバックアップする。
続いて、図１７に例示したような動作シーケンスを実現するために第３実施形態で行われる種々の処理について、図１８〜２０のフローチャートを参照して説明する。
図１８は、第３実施形態で端末８３０が行う処理の一部を示すフローチャートである。端末８３０は、端末３３０が実行する図１１の処理と類似の処理を実行する。具体的には、端末８３０は、図１１の一部が図１８に示すように変更された処理を実行する。図１１と１８を比較すると分かるとおり、図１１におけるステップＳ２０９〜Ｓ２１１の処理のうち、ステップＳ２０９が、図１８ではステップＳ７０１〜Ｓ７０５に置き換えられている。
さらに、第３実施形態では、ステップＳ２０１における「送信」は、端末８３０から別の端末（例えば端末８１０または８５０）への送信であってもよいし、端末８３０からサーバ８７０への送信であってもよい。このようなステップＳ２０１の変形に応じて、第３実施形態のＳ２０２では、送信先の情報として、サーバ８７０を識別する情報が抽出される場合もある。
さて、図１１から理解されるように、ステップＳ２０７でＤＢ管理部８３５は、以下のような判断を行う。すなわち、ＤＢ管理部８３５は、「ファイル記憶部８３２に記憶されている既存のファイルに対して、変更、移動、変名、削除、コピー以外の他の操作が行われた」というイベントが監視部８３３により検出されたか否かを判断する。そして、そのようなイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部８３３からＤＢ管理部８３５に出力された場合）に、図１８のステップＳ７０１が実行される。
ステップＳ７０１でＤＢ管理部８３５は、以下のいずれかのイベントが検出されたか否かを判断する。
・「端末８３０内でファイルが新規作成された」というイベント。
・「ファイル記憶部８３２内の既存のファイルがコピーされた」というイベント。
上記のいずれかのイベントが検出された場合（すなわち、そのようなイベントの検出を示す監視結果が監視部８３３からＤＢ管理部８３５に出力された場合）、図１８の処理はステップＳ２１０に移行する。ステップＳ２１０と、それに続くステップＳ２１１は、図１１と同様である。ステップＳ２１１の実行後は、ステップＳ２０３が実行される。
逆に、上記のいずれのイベントも検出されていなければ、図１８の処理はステップＳ７０２に移行する。そして、ステップＳ７０２でＤＢ管理部８３５は、「ファイルが、通信部８３１を介して受信されて、ファイル記憶部８３２に記憶された」というイベントが検出されたか否かを判断する。
そのようなイベントが検出された場合、図１８の処理はステップＳ７０３に移行する。逆に、そのようなイベントが検出されていなければ、図１１と同様に、次はステップＳ２１２が実行される。
なお、ステップＳ７０２で検出される「受信」は、別の端末（例えば端末８１０または８５０）から送られたファイルの端末８３０における受信の場合もあり得るし、サーバ８７０から送られたファイルの端末８３０における受信の場合もあり得る。
さて、ステップＳ７０３でＤＢ管理部８３５は、受信されてファイル記憶部８３２に記憶されたファイルから、ユニーク値を算出する。そして、次のステップＳ７０４でＤＢ管理部８３５は、算出したユニーク値がＤＢに登録されているか否かを判断する。具体的には、ＤＢ管理部８３５は、算出したユニーク値を含むエントリを含む履歴テーブルを探す。
なお、端末８３０のＤＢ記憶部８３６上のＤＢと、サーバ８７０のＤＢ記憶部８７２における、端末８３０のユーザ用のＤＢとは、通信環境などによっては、完全には同期していない場合があり得る。よって、ステップＳ７０４では、具体的には、図１１のステップＳ２１４、Ｓ２１５、Ｓ２１６およびＳ２１３に示すような、同期のための処理が行われることが好ましい。すると、ＤＢ記憶部８３６上のＤＢは、サーバ８７０上のＤＢに同期されて最新の状態となる。ＤＢ管理部８３５は、こうして同期されたＤＢ記憶部８３６上のＤＢにおいて、ステップＳ７０３で算出したユニーク値を含むエントリを含む履歴テーブルを探す。
もし、算出したユニーク値を含むエントリを含む履歴テーブルが見つかれば、図１８の処理はステップＳ２１０に移行する。なぜなら、この場合、端末８３０が受信したファイルの送信元（つまり他の端末またはサーバ８７０）における当該ファイルに関するメタデータは、既にＤＢに登録されているからである。したがって、ＤＢ管理部８３５は、そのようなメタデータを新たに生成する必要もないし、メタデータを推定する必要もない。この場合、ＤＢ管理部８３５は、端末８３０のファイル記憶部８３２に新たに記憶されたファイルについてのメタデータさえ生成すれば十分である。よって、図１８の処理はステップＳ２１０に移行する。
例えば、図１６では省略されているが、端末８３０のユーザは、図４の端末３１０のようにメタデータを生成する端末をさらに使っていてもよい。端末８３０が端末３１０からファイルを受信した場合、送信元の端末３１０で生成済みのメタデータがＤＢ内に存在する。よって、この場合、算出したユニーク値を含むエントリを含む履歴テーブルが、ステップＳ７０４で見つかる。
また、端末８１０のようにメタデータを生成しない端末から、端末８３０がファイルを受信した場合でも、ステップＳ７０４で履歴テーブルが見つかる場合があり得る。例えば、かつて端末８３０が端末８１０から受信したことのあるファイルを、再度、端末８３０が端末８１０から受信した場合などは、履歴テーブルが見つかる。
しかし、逆に、ステップＳ７０３で算出したユニーク値を含むエントリを含む履歴テーブルが見つからなければ、図１８の処理はステップＳ７０５に移行する。そして、ステップＳ７０５でＤＢ管理部８３５は、受信したファイルに関するメタデータを推定する。
具体的には、図１７のステップＳ９０３に関して説明したように、ＤＢ管理部８３５は、Ｅｘｉｆデータまたはプロパティから、受信したファイルの作成日時や、ファイルの送信元の端末を識別する識別情報（例えば製造シリアル番号など）の抽出を試みる。端末８３０が受信したファイルによって、作成日時や識別情報の抽出が成功する場合もあるし、何の情報も抽出されない場合もあり得る。いずれにしろ、図１８の処理は、ステップＳ２１０に移行する。
なお、ステップＳ７０５で情報の抽出に成功した場合、ステップＳ２１０とＳ２１１の後に実行されるステップＳ２０４において、抽出された情報が端末８３０からサーバ８７０へと送信される。
さて、図１９は、第３実施形態でサーバ８７０が行う処理のフローチャートである。上記のとおり、第３実施形態のサーバ８７０のＤＢ管理部８７４は、以下の処理を行う。
・第２実施形態の端末３３０の監視部３３３およびＤＢ管理部３３５が行う処理と似た処理。
・第２実施形態のサーバ３５０のＤＢ管理部３５４が行う処理と似た処理。
図１９には、前者の処理が具体的に示されている。図１９中のステップＳ８０３に相当する図２０には、後者の処理が具体的に示されている。
さて、ステップＳ８０１でＤＢ管理部８７４は、「ファイル記憶部８７５に記憶されているファイルが、いずれかの端末からのダウンロード要求に応じて、通信部８７１から送信された」というイベントが発生したか否かを判断する。そのようなイベントが発生した場合、図１９の処理はステップＳ８０２に移行する。逆に、そのようなイベントが検出されなければ、図１９の処理はステップＳ８０４に移行する。
ステップＳ８０２でＤＢ管理部８７４は、ファイルの送信先などの情報を抽出する。上記のとおり、第３実施形態のＤＢ管理部８７４は、第２実施形態の監視部３３３と類似の処理も行う。例えば、ＤＢ管理部８７４は、ダウンロード要求の受信や、ダウンロード要求に応じたファイルの送信を監視する。
よって、ステップＳ８０２でＤＢ管理部８７４は、監視結果として、例えば以下のような情報を取得する。
・「送信」というログ種別を示す情報。
・ファイルが送信された日時。
・送信されたファイルが置かれている、ファイル記憶部８７５におけるディレクトリのパスと、当該ファイルのファイル名。
・送信先の端末を識別するデバイスＩＤ（例えば、端末８５０からのダウンロード要求に応じてファイルが端末８５０に送信された場合、端末８５０のデバイスＩＤ）。
ところで、サーバ８７０のファイル記憶部８７５に記憶されているファイルを表す、ＩＤテーブル中のエントリにおいて、デバイスＩＤの値は、サーバ８７０を識別する値である。よって、ＤＢ管理部８７４は、サーバ８７０自身のデバイスＩＤと、取得した上記のパスおよびファイル名を検索キーとして用いて、ＤＢ記憶部８７２内のＩＤテーブルを参照し、送信されたファイルのファイルＩＤを取得する。
なお、ＤＢ管理部８７４は、ファイル記憶部８７５上に記憶された各ファイルの所有者がどのユーザなのかを認識している。例えば、サーバ８７０のＯＳ（Operating System）が提供するファイルシステムにより、各ファイルの所有者が記録されてもよい。ＤＢ管理部８７４は、ファイルシステムを介して、各ファイルの所有者を認識してもよい。ＤＢ管理部８７４は、「ファイルが送信されたことを示すエントリを、どのユーザのＤＢ中の履歴テーブルに追加するのか」ということを決めるために、ステップＳ８０２で、ファイルの所有者のユーザを識別するユーザＩＤも、取得する。
また、ＤＢ管理部８７４は、送信先の端末のデバイスＩＤを使って、デバイス管理部８７３に対して、送信先の端末のユーザのユーザＩＤを問い合わせる。ファイルの所有者のユーザ自身がファイルをダウンロードすることもあるし、他のユーザがファイルをダウンロードすることもある。そのため、上記のようにして得られる２つのユーザＩＤ同士は、等しい場合もあるし、異なる場合もある。
さらに、ＤＢ管理部８７４は、送信されたファイルのユニーク値を取得する。具体的には、ＤＢ管理部８７４は、上記のパスとファイル名により識別されるファイルから、ユニーク値を算出してもよい。または、ＤＢ管理部８７４は、当該ファイルに対応する履歴テーブルの最新のエントリから、ユニーク値を読み出してもよい。
以上のようにして、履歴テーブルに追加するエントリに含めるための情報をＤＢ管理部８７４が取得し終えると、図１９の処理はステップＳ８０３に移行する。ステップＳ８０３の詳細は、図２０とともに後述する。概要だけ説明すると、ステップＳ８０３では、ＤＢ管理部８７４が、取得済みの情報を用いて適宜ＤＢを更新し、更新または追加されたエントリ（つまり、履歴情報、追跡情報、またはその双方を含むメタデータ）を、適宜の１台以上の端末に通知する。ステップＳ８０３の実行後、図１９の処理はステップＳ８０１に戻る。
さて、ステップＳ８０４でＤＢ管理部８７４は、「いずれかの端末から送信されたファイルが、通信部８７１で受信されて、ファイル記憶部８７５に記憶された」というイベントが発生したか否かを判断する。つまり、ＤＢ管理部８７４は、端末からサーバ８７０へのファイルのアップロードも監視し、監視結果に応じてステップＳ８０４の判断を行う。
上記イベントが発生した場合（つまりファイルがアップロードされた場合）、図１９の処理はステップＳ８０５に移行する。例えば、図１７のステップＳ６０７でファイル９０４が端末８３０からアップロードされると、図１９の処理はステップＳ８０５に移行する。逆に、上記イベントが検出されなければ、図１９の処理は、ステップＳ８０７に移行する。
ステップＳ８０５でＤＢ管理部８７４は、新たなファイルＩＤを発行する。例えば、シーケンス番号がサーバ８７０内でのファイルＩＤとして使われる場合、ＤＢ管理部８７４は、カウンタをインクリメントすることで、新たなファイルＩＤを取得してもよい。
次に、ステップＳ８０６でＤＢ管理部８７４は、監視結果として、例えば以下のような情報を取得する。
・「受信」というログ種別を示す情報。
・アップロードされたファイルが保存された、ファイル記憶部８７５上のディレクトリのパス。
・アップロードされたファイルの、ファイル記憶部８７５でのファイル名。
・当該ファイルがファイル記憶部８７５に保存された日時。
・当該ファイルの送信元の端末のデバイスＩＤ。
また、ＤＢ管理部８７４は、アップロードされたファイルのユニーク値も算出する。
さらに、ＤＢ管理部８７４は、どのユーザ用のＤＢを更新するのかを決めるために、ユーザＩＤを取得する。つまり、ＤＢ管理部８７４は、アップロードされたファイルの所有者のユーザＩＤを取得する。
具体的には、ＤＢ管理部８７４は、上記パスとファイル名に基づいて、ファイルシステムを介してユーザＩＤを取得してもよい。あるいは、ＤＢ管理部８７４は、取得したデバイスＩＤを使って、デバイス管理部８７３に対する問い合わせを介して、デバイスＩＤからユーザＩＤを取得してもよい。
以上のようにして、ＩＤテーブルに追加するエントリに含めるための情報と、新たに追加する履歴テーブルに含めるための情報をＤＢ管理部８７４が取得し終えると、図１９の処理はステップＳ８０３に移行する。
さて、ステップＳ８０７でＤＢ管理部８７４は、「ファイル記憶部８７５に記憶されているファイルが、変更、移動、変名、または削除された」というイベントが生じたか否かを判断する。つまり、ＤＢ管理部８７４は、「ファイル記憶部８７５に記憶されているファイルに対する、変更、移動、変名、または削除のための要求が、いずれかの端末からネットワーク８９０を介して通信部８７１により受信されたか否か」を監視する。そして、ＤＢ管理部８７４は、監視結果にしたがって、ステップＳ８０７の判断を行う。なお、ファイルに設定されたアクセス権によっては、あるユーザが所有するファイルが、他のユーザによって変更、移動、変名、または削除される可能性もある。
上記のようなイベントが検出された場合、図１９の処理はステップＳ８０８に移行する。逆に、上記のようなイベントが検出されなければ、図１０の処理はステップＳ８０９に移行する。
ステップＳ８０８でＤＢ管理部８７４は、パスなどの情報を取得する。具体的には以下のとおりである。
例えば、ファイル記憶部８７５上のあるファイルが変更された場合、ＤＢ管理部８７４は、監視結果として、以下のような情報を取得する。
・「変更」というログ種別を示す情報。
・変更されたファイルが置かれているディレクトリのパス。
・変更されたファイルのファイル名。
・ＤＢ管理部８７４が、ファイルの変更にかかった時間も検出可能な場合は、ファイルの変更が開始された日時と、ファイルの変更にかかった時間。
・ＤＢ管理部８７４が、ファイルの変更にかかった時間を検出しない場合は、変更されたファイルが保存された日時。
・ファイルを変更するための要求をサーバ８７０に送信してきた、要求元（requestor）端末のデバイスＩＤ。
さらに、ＤＢ管理部８７４は、変更操作についての履歴情報をどのユーザ用のＤＢに追加するのかを決めるために、変更されたファイルの所有者のユーザのユーザＩＤも取得する。ＤＢ管理部８７４は、変更されたファイルの新たなユニーク値も算出する。また、ＤＢ管理部８７４は、デバイス管理部８７３への問い合わせを介して、要求元端末のデバイスＩＤから、当該端末のユーザのユーザＩＤを取得する。ＤＢ管理部８７４は、ＩＤテーブルを参照することにより、パスとファイル名から、ファイルＩＤも取得する。
また、ファイル記憶部８７５上のあるファイルが、あるディレクトリから別のディレクトリへと移動された場合、ＤＢ管理部８７４は、監視結果として、以下のような情報を取得する。
・「移動」というログ種別を示す情報。
・移動される前にファイルが置かれていたディレクトリのパス。
・ファイルが移動された先のディレクトリのパス。
・移動されたファイルのファイル名。
・移動操作が行われた日時。
・ファイルを移動するための要求をサーバ８７０に送信してきた、要求元端末のデバイスＩＤ。
さらに、ＤＢ管理部８７４は、ファイルが変更された場合と同様にして、２つのユーザＩＤも取得し、ファイルＩＤも取得する。
また、ファイル記憶部８７５上のあるファイルが変名された場合、ＤＢ管理部８７４は、監視結果として、以下のような情報を取得する。
・「変名」というログ種別を示す情報。
・変名される前のファイル名。
・変名後のファイル名。
・変名操作が行われた日時。
・ファイルを変名するための要求をサーバ８７０に送信してきた、要求元端末のデバイスＩＤ。
さらに、ＤＢ管理部８７４は、ファイルが変更された場合と同様にして、２つのユーザＩＤも取得し、ファイルＩＤも取得する。また、ＤＢ管理部８７４は、変名されたファイルのユニーク値を算出する。
なお、ある種のコマンドの実行によって、ファイルの移動と変名が同時に行われることもある。その場合も、ＤＢ管理部８７４は適宜の監視結果を取得することができる。
また、ファイル記憶部８７５上のあるファイルが削除された場合、ＤＢ管理部８７４は、監視結果として、以下のような情報を取得する。
・「削除」というログ種別を示す情報。
・削除されたファイルが今まで置かれていたディレクトリのパス。
・削除されたファイルのファイル名。
・ファイルを削除するための要求をサーバ８７０に送信してきた、要求元端末のデバイスＩＤ。
さらに、ＤＢ管理部８７４は、ファイルが変更された場合と同様にして、２つのユーザＩＤも取得し、ファイルＩＤも取得する。
以上、例示したように、ＤＢ管理部８７４は、変更、移動、変名、削除といった操作の種類に応じて、適宜の情報を取得する。そして、ＤＢの更新に使う情報（例えば、ＩＤテーブルのエントリを書き換えるための情報と、履歴テーブルに追加するエントリに含めるための情報、など）をＤＢ管理部８７４が取得し終えると、図１９の処理はステップＳ８０３に移行する。
さて、ステップＳ８０９でＤＢ管理部８７４は、「ファイル記憶部８７５に記憶されている既存のファイルに対して、変更、移動、変名、削除以外の他の操作が行われた」というイベントが生じたか否かを判断する。上記イベントが発生した場合、図１９の処理はステップＳ８１０に移行する。逆に、上記イベントが検出されなければ、図１９の処理はステップＳ８１１に移行する。
より詳しく説明すると、ＤＢ管理部８７４は、上記のダウンロード要求などを監視するだけでなく、端末からサーバ８７０に対して送られるその他の種々の要求も監視し、監視結果に応じてステップＳ８０９の判断を行う。ステップＳ８０９での検出対象の操作の種類と数は実施形態に応じて任意である。例えば、以下のような操作がステップＳ８０９で検出されてもよい。
・ファイルにコメントやタグなどの付加的情報を加える操作。
・ファイルへの参照リンクを生じさせる操作（例えばトラックバック）。
・ファイルに対する評価や参照などをＳＮＳを介してユーザ間で共有するための、ＳＮＳ固有の機能を呼び出す操作（例えば所定のボタンをクリックする操作）。
さて、ステップＳ８１０でＤＢ管理部８７４は、監視結果として、例えば以下のような情報を取得する。
・行われた操作の種別を示す情報。
・操作が行われたファイルが置かれているディレクトリのパス。
・操作が行われたファイルのファイル名。
・操作が行われた日時。
・操作のための要求をサーバ８７０に送信してきた、要求元端末のデバイスＩＤ（例えば、図１７のステップＳ６０９のように端末８５０によりコメント９０５が加えられた場合は、端末８５０のデバイスＩＤ）。
さらに、ＤＢ管理部８７４は、検出した操作に関する履歴情報をどのユーザ用のＤＢに追加するのかを決めるために、操作が行われたファイルの所有者のユーザのユーザＩＤも取得する。なお、ステップＳ８０９で検出される操作は、ファイル自体のデータを変更する操作ではないので、ファイルのユニーク値は変化しない。また、ＤＢ管理部８７４は、ステップＳ８０８と同様に、２つのユーザＩＤも取得し、ファイルＩＤも取得する。
以上のようにして、履歴テーブルに追加するエントリに含めるための情報をＤＢ管理部８７４が取得し終えると、図１９の処理はステップＳ８０３に移行する。
さて、ステップＳ８１１でＤＢ管理部８７４は、「いずれかのユーザ用のＤＢに追加するためのテーブルの一部または全部を、いずれかの端末から通信部８７１が受信した」というイベントが発生したか否かを判断する。そして、そのようなイベントが発生すると（つまりいずれかの端末からサーバ８７０が何らかのメタデータを受信すると）、図１９の処理はステップＳ８０３に移行する。
より具体的には、ＤＢ管理部８７４は、通信部８７１がメタデータを受信するか否かも監視する。そして、通信部８７１がメタデータを受信すると、ＤＢ管理部８７４は、メタデータの送信元の端末のデバイスＩＤを取得する。ＤＢ管理部８７４は、取得したデバイスＩＤを使って、デバイス管理部８７３に対する問い合わせを介して、メタデータの送信元の端末を使うユーザのユーザＩＤも取得する。ＤＢ管理部８７４は、以上のようにユーザＩＤを取得することにより、受信したメタデータをどのＤＢに反映させるかを決定する。その後、上記のとおり図１９の処理はステップＳ８１１からステップＳ８０３へと移行する。
逆に、「通信部８７１がメタデータを受信した」というイベントが検出されなければ、図１９の処理はステップＳ８０１に戻る。
さて、図２０は、図１９のステップＳ８０３におけるＤＢの更新と通知のフローチャートである。
ステップＳ９０１でＤＢ管理部８７４は、どのＤＢを更新するかを、取得済みのユーザＩＤにしたがって決める。上記のとおり、図１９のステップＳ８０２、Ｓ８０６、Ｓ８０８、Ｓ８１０またはＳ８１１において、どのＤＢを更新するかを決めるためにユーザＩＤが既に取得されている。
例えば、ＤＢ記憶部８７２は、図８と同様にＵ人のユーザ用のＤＢ５３０−１〜５３０−Ｕを記憶していてもよい。そして、「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤのユーザが所有するファイルに対して、当該ユーザ自身の端末または他のユーザの端末から、何らかの操作（例えば、変更、コメント付加など）のための要求がサーバ８７０に送られてもよい。この場合、「ｓｕｚｕｋｉ＿ｔａｒｏ」というユーザＩＤが取得済みである。よって、この場合、ステップＳ９０１でＤＢ管理部８７４は、ＤＢ５３０−１〜５３０−ＵのうちのＤＢ５３０−１を更新することを決める。
便宜上、図２０に関する以下の説明においては、ＤＢ管理部８７４が、ＤＢ５３０−１を更新することに決めたものとする。
さて、次にステップＳ９０２でＤＢ管理部８７４は、ＤＢ５３０−１の更新に関わるログ種別が、「受信」なのか、「送信」なのか、それ以外なのかを判断する。そして、ログ種別が「受信」の場合、図２０の処理はステップＳ９０３に移行する。ログ種別が「送信」の場合、図２０の処理はステップＳ９１０に移行する。ログ種別が「受信」でも「送信」でもない場合、図２０の処理はステップＳ９１５に移行する。より具体的には、以下のとおりである。
図１９のステップＳ８０４でファイルの受信が検出された場合、ログ種別は「受信」である。つまり、いずれかの端末から送信されたファイルの、サーバ８７０における受信が検出された場合、ログ種別は「受信」である。
また、図１９のステップＳ８１１でメタデータの受信が検出され、かつ、当該メタデータが「受信」というログ種別の履歴情報を含む場合も、ログ種別は「受信」である。つまり、端末間でのファイル転送（transfer）またはサーバ８７０から端末へのファイルのダウンロードが、受信側の端末で検出され、履歴情報が受信側の端末で生成され、生成された履歴情報がサーバ８７０に送られた場合も、ログ種別は「受信」である。
他方、図１９のステップＳ８０１でファイルの送信が検出された場合、ログ種別は「送信」である。つまり、サーバ８７０からいずれかの端末への送信が検出された場合、ログ種別は「送信」である。
また、図１９のステップＳ８１１でメタデータの受信が検出され、かつ、当該メタデータが「送信」というログ種別の履歴情報を含む場合も、ログ種別は「送信」である。つまり、端末間でのファイル転送または端末からサーバ８７０へのファイルのアップロードが、送信側の端末で検出され、その結果として履歴情報が送信側の端末で生成され、生成された履歴情報がサーバ８７０に送られた場合も、ログ種別は「送信」である。
さて、ステップＳ９０３でＤＢ管理部８７４は、ファイルの送信元を認識する。具体的には、以下のとおりである。
「受信」というログ種別の履歴情報をいずれかの端末（例えば端末８３０）からサーバ８７０が受信した場合、ＤＢ管理部８７４は、ステップＳ９０３において、図１２のステップＳ４０５と同様にして、送信元に関する情報を抽出する。それにより、ＤＢ管理部８７４は、ファイルの送信元を認識する。
また、図１９のステップＳ８０４でファイルの受信が検出された場合には、上記のとおり、ステップＳ８０６で既に送信元の端末のデバイスＩＤが得られている。よって、この場合も、ＤＢ管理部８７４は送信元を認識することができる。
次に、ステップＳ９０４でＤＢ管理部８７４は、ステップＳ９０３で認識した送信元が、メタデータを生成することが可能であるか否かを判断する。
例えば、送信元が端末８１０である場合、端末８１０はメタデータの生成機能を持たない。そして、上記のとおり、デバイス管理部８７３が保持するデバイス管理テーブルには、各デバイスがメタデータを生成する機能を持つか否かを示すフラグが含まれる。よって、送信元が端末８１０の場合、ＤＢ管理部８７４は、デバイス管理部８７３への問い合わせを介して、「送信元はメタデータを生成する機能を持たない」と判断する。
逆に、送信元が例えば端末８３０である場合、ＤＢ管理部８７４は、デバイス管理部８７３への問い合わせを介して、「送信元はメタデータを生成する機能を持つ」と判断する。また、送信元がサーバ８７０である場合も、ＤＢ管理部８７４は、「送信元はメタデータを生成する機能を持つ」と判断する。
そして、「送信元はメタデータを生成する機能を持たない」と判断された場合、図２０の処理はステップＳ９０５に移行する。逆に、「送信元はメタデータを生成する機能を持つ」と判断された場合、図２０の処理はステップＳ９０８に移行する。
ステップＳ９０５でＤＢ管理部８７４は、ファイルの送信元の端末（つまりメタデータの生成機能を持たない端末）においてファイルを識別するためのファイルＩＤを生成する。ＤＢ管理部８７４は、例えば、端末別のカウンタを使って、シリアル番号をファイルＩＤとして生成してもよい。
また、送信元の端末におけるファイルに対応する新規エントリを、後のステップＳ９０７でＩＤテーブル中に追加するために、ＤＢ管理部８７４は、新規エントリ用の適当なパスもステップＳ９０５で生成する。ステップＳ９０５で生成されるパスは、送信元の端末において実際にファイルが置かれているパスではなく、単なる便宜上の値である。よって、ＤＢ管理部８７４は、どのようなパスを生成してもよい。
ファイルＩＤとパスの生成後、図２０の処理はステップＳ９０６に移行する。なお、ステップＳ９０３で認識される送信元を示すデバイスＩＤと、ステップＳ９０５で生成されるファイルＩＤとのペアは、デバイス間での複製操作における親ファイルを識別する。つまり、メタデータを生成しない端末（例えば端末８１０）から他の端末（例えば端末８３０）またはサーバ８７０へのファイルの複製操作における親ファイルを識別する情報が、ステップＳ９０３とＳ９０５で取得される。
さて、ステップＳ９０６でＤＢ管理部８７４は、端末間または端末・サーバ８７０間での複製操作によって生じる、ファイル間の親子関係を認識し、追跡情報を生成する。
例えば、ステップＳ９０５の次にステップＳ９０６が実行される場合の追跡情報の詳細は、以下のとおりである。
・親デバイスＩＤは、ステップＳ９０３で認識されたデバイスＩＤである。
・親ファイルＩＤは、ステップＳ９０５で生成されたファイルＩＤである。
・図１９のステップＳ８１１で、あるファイルＩＤに対応する履歴テーブルのエントリがある端末から受信された場合、子デバイスＩＤは、履歴テーブルのエントリの送信元の当該端末のデバイスＩＤであり、子ファイルＩＤは、当該ファイルＩＤである。
・図１９のステップＳ８０４で受信が検出された場合、子デバイスＩＤは、サーバ８７０のデバイスＩＤであり、子ファイルＩＤは、ステップＳ８０５で発行されたＩＤである。
また、ステップＳ９０６でＤＢ管理部８７４は、テーブルの送信先を決定する。より具体的には、ＤＢ管理部８７４は、ステップＳ９０１で決めたＤＢ５３０−１に対応するユーザが使う端末のうち、メタデータの生成機能を持つすべての端末に、後述のステップＳ９０７で追加または更新する各エントリを送信することを決定する。そして、図２０の処理はステップＳ９０７に移行する。
ステップＳ９０７でＤＢ管理部８７４は、ＤＢ（つまり、更新対象としてステップＳ９０１で選んだＤＢ）を更新する。具体的には、ＤＢ管理部８７４は、サーバ８７０上の操作を検出した場合は、ステップＳ８０２、Ｓ８０５、Ｓ８０６、Ｓ８０８、またはＳ８１０で取得した情報に基づいて、適宜、テーブルの追加、エントリの追加、および／またはエントリの更新を行う。また、サーバ８７０がいずれかの端末からメタデータを受信した場合は、ＤＢ管理部８７４は、受信したメタデータに基づいて、適宜、テーブルの追加、エントリの追加、および／またはエントリの更新を行う。ステップＳ９０５または後述のステップＳ９１２でファイルＩＤを生成した場合は、ＤＢ管理部８７４は、ＩＤテーブルにエントリを追加する。なお、ステップＳ９０６の後にステップＳ９０７が実行される場合は、ＤＢ管理部８７４はさらに、ステップＳ９０６で生成した追跡情報もＤＢに追加する。
ステップＳ９０７で追加または更新された各エントリは、ステップＳ９０６で送信先として決められた各端末か、または、後述のステップＳ９１５で送信先として決められる各端末に、通信部８７１から送信される。送信後、図２０の処理は終了する。
さて、「ファイルの送信元の端末はメタデータの生成機能を持つ」とステップＳ９０４で判断した場合、ステップＳ９０８でＤＢ管理部８７４は、「現在注目している受信は、１人のユーザに閉じたファイル転送における受信か否か」を判断する。
例えば、現在注目している受信が、端末８３０からサーバ８７０へのファイル転送における、サーバ８７０での受信の場合がある。この場合、当該受信は、１人のユーザに閉じている。なぜなら、サーバ８７０にアップロードされるファイルの所有者は、アップロード元の端末を使うユーザ自身だからである。
逆に、現在注目している受信が、ステップＳ８１１で得られた履歴情報により示される受信の場合もある。この場合、当該履歴情報からステップＳ９０３で抽出された送信元のデバイスＩＤと、当該履歴情報をサーバ８７０に送ってきた端末のデバイスＩＤは、同じユーザＩＤに対応づけられている可能性もあるし、違うユーザＩＤに対応づけられている可能性もある。
２つのデバイスＩＤが同じユーザＩＤに対応づけられていれば、当該受信は、１人のユーザに閉じたファイル転送における受信である。逆に、２つのデバイスＩＤが異なるユーザＩＤに対応づけられていれば、当該受信は、１人のユーザに閉じたファイル転送における受信ではなく、ユーザ間でのファイル転送における受信である。
ＤＢ管理部８７４は、具体的には、ステップＳ９０３で抽出したデバイスＩＤから、デバイス管理部８７３への問い合わせを介して、ユーザＩＤを取得してもよい。ＤＢ管理部８７４は、こうして取得したユーザＩＤ（つまり、ファイルの送信元に対応するユーザＩＤ）を、ステップＳ８１１で取得したユーザＩＤ（つまり、ファイルの送信先に対応するユーザＩＤ）と比較してもよい。そして、ＤＢ管理部８７４は、比較結果に応じて、ステップＳ９０８の判断を行ってもよい。
そして、「現在注目している受信は、１人のユーザに閉じたファイル転送における受信である」とＤＢ管理部８７４が判断すると、図２０の処理はステップＳ９０９に移行する。
逆に、「現在注目している受信は、１人のユーザに閉じたファイル転送における受信ではない」とＤＢ管理部８７４が判断すると、図２０の処理はステップＳ９１５に移行する。なぜなら、ユーザ間でのファイル転送による複製では、ファイル間に親子関係は生じないからである。
さて、ステップＳ９０９でＤＢ管理部８７４は、現在注目している受信に対応する送信ログがあるか否かを判断する。
例えば、現在注目している受信が、端末８３０からサーバ８７０に送られたファイルのサーバ８７０における受信の場合がある。この場合、「現在注目している受信に対応する送信ログ」とは、端末８３０により生成されて端末８３０からサーバ８７０に送られる履歴情報であり、より具体的には、ログ種別として「送信」が指定されている履歴情報である。
逆に、現在注目している受信が、ステップＳ８１１で得られた履歴情報により示される受信の場合もある。この場合、「現在注目している受信に対応する送信ログ」とは、当該履歴情報をサーバ８７０に送ってきた端末にファイルを送信した他の端末（またはサーバ８７０）により生成され、ログ種別として「送信」が指定されているような、履歴情報である。
いずれの場合も、ＤＢ管理部８７４は、図１２のステップＳ４０６と類似の方法でＤＢ５３０−１内の履歴テーブルを検索することにより、現在注目している受信に対応する送信ログがあるか否かを判断することができる。
そして、現在注目している受信に対応する送信ログが見つかった場合、図２０の処理はステップＳ９０６に移行する。この場合、ステップＳ９０６でＤＢ管理部８７４は、見つかった送信ログに基づいて親デバイスＩＤと親ファイルＩＤを決定し、現在注目している受信に関して取得済みの情報から、子デバイスＩＤと子ファイルＩＤを決定する。それにより、ＤＢ管理部８７４は、ステップＳ９０６で適切な追跡情報を生成することができる。
逆に、現在注目している受信に対応する送信ログが見つからなければ、図２０の処理は、ステップＳ９１５に移行する。つまり、現在注目している受信に対応する送信ログが見つからない場合、サーバ８７０は、今回は追跡情報を生成せず、対応する送信ログ（つまり履歴情報）の受信を待ってから追跡情報を生成する。
さて、ログ種別が「送信」の場合、ステップＳ９１０でＤＢ管理部８７４は、ファイルの送信先を認識する。具体的には、以下のとおりである。
「送信」というログ種別の履歴情報をいずれかの端末（例えば端末８３０）からサーバ８７０が受信した場合、ＤＢ管理部８７４は、ステップＳ９１０において、図１２のステップＳ４１１と同様にして、送信先に関する情報を抽出する。それにより、ＤＢ管理部８７４は、ファイルの送信先を認識する。
また、図１９のステップＳ８０１でファイルの送信が検出された場合には、上記のとおり、ステップＳ８０２で既に送信先の端末のデバイスＩＤが得られている。よって、この場合も、ＤＢ管理部８７４は送信先を認識することができる。
次に、ステップＳ９１１でＤＢ管理部８７４は、ステップＳ９１０で認識した送信先が、メタデータを生成することが可能であるか否かを判断する。ステップＳ９１１の判断の詳細は、送信元と送信先の違い以外は、ステップＳ９０４と同様である。よって、ステップＳ９１１の詳細な説明は省略する。
なお、「ファイルの送信先はメタデータを生成する機能を持たない」と判断された場合は、図２０の処理はステップＳ９１２に移行する。逆に、「ファイルの送信先はメタデータを生成する機能を持つ」と判断された場合は、図２０の処理はステップＳ９１３に移行する。
さて、ステップＳ９１２でＤＢ管理部８７４は、ファイルの送信先の端末（つまりメタデータの生成機能を持たない端末）においてファイルを識別するためのファイルＩＤを生成する。
例えば、端末８３０から端末８１０に、ＵＳＢケーブルまたはネットワーク８９０を介して、ファイルが送信された場合、端末８３０は、送信に関する履歴情報を生成し、当該履歴情報をサーバ８７０に送信する。そして、サーバ８７０は、「送信先の端末８１０がメタデータを生成しない」と判断し、ステップＳ９１２でファイルＩＤを生成する。
ステップＳ９１２でＤＢ管理部８７４はさらに、送信先の端末におけるファイルに対応する新規エントリを、後のステップＳ９０７でＩＤテーブル中に追加するために、新規エントリ用の適当なパスも生成する。ステップＳ９１２の詳細はステップＳ９０５と類似である。ファイルＩＤとパスの生成後、図２０の処理はステップＳ９０６に移行する。
なお、ステップＳ９１０で認識される送信先を示すデバイスＩＤと、ステップＳ９１２で生成されるファイルＩＤとのペアは、デバイス間での複製操作における子ファイルを識別する。つまり、サーバ８７０または端末８３０から、メタデータを生成しない端末（例えば端末８５０）へのファイルの複製操作における、子ファイルを識別する情報が、ステップＳ９１０とＳ９１２で取得される。
一方、当該複製操作における親ファイルを識別する情報は、サーバ８７０が端末８３０から受信した履歴情報（つまり送信を示す履歴情報）に含まれているか、または、サーバ８７０自身がステップＳ８０２で既に抽出している。よって、ステップＳ９１２の後にステップＳ９０６が実行される場合も、適切な追跡情報が生成される。
さて、「ファイルの送信先はメタデータの生成機能を持つ」とステップＳ９１１で判断した場合、ステップＳ９１３でＤＢ管理部８７４は、「現在注目している送信は、１人のユーザに閉じたファイル転送における送信か否か」を判断する。
例えば、現在注目している送信が、サーバ８７０からいずれかの端末へのファイルの送信（つまりステップＳ８０１で検出された送信）の場合がある。この場合、ステップＳ８０２で取得された２つのユーザＩＤが等しければ、現在注目している送信は、１人のユーザに閉じたファイル転送における送信である。逆に、ステップＳ８０２で取得された２つのユーザＩＤが異なれば、現在注目している送信は、１人のユーザに閉じたファイル転送における送信ではない。例えば、ファイルの所有者とは別のユーザの端末からのダウンロード要求に応じてサーバ８７０がファイルを送信した場合、２つのユーザＩＤは異なる。
また、現在注目している送信が、ステップＳ８１１で得られた履歴情報により示される送信の場合もある。この場合、当該履歴情報からステップＳ９１０で抽出された送信先のデバイスＩＤと、当該履歴情報をサーバ８７０に送ってきた端末のデバイスＩＤは、同じユーザＩＤに対応づけられている可能性もあるし、違うユーザＩＤに対応づけられている可能性もある。
２つのデバイスＩＤが同じユーザＩＤに対応づけられていれば、当該送信は、１人のユーザに閉じたファイル転送における送信である。逆に、２つのデバイスＩＤが異なるユーザＩＤに対応づけられていれば、当該送信は、１人のユーザに閉じたファイル転送における送信ではなく、ユーザ間でのファイル転送における送信である。
ＤＢ管理部８７４は、具体的には、ステップＳ９１０で抽出したデバイスＩＤから、デバイス管理部８７３への問い合わせを介して、ユーザＩＤを取得してもよい。ＤＢ管理部８７４は、こうして取得したユーザＩＤ（つまり、ファイルの送信先に対応するユーザＩＤ）を、ステップＳ８１１で取得したユーザＩＤ（つまり、ファイルの送信元に対応するユーザＩＤ）と比較してもよい。そして、ＤＢ管理部８７４は、比較結果に応じて、ステップＳ９１３の判断を行ってもよい。
そして、「現在注目している送信は、１人のユーザに閉じたファイル転送における送信である」とＤＢ管理部８７４が判断すると、図２０の処理はステップＳ９１４に移行する。
逆に、「現在注目している送信は、１人のユーザに閉じたファイル転送における送信ではない」とＤＢ管理部８７４が判断すると、図２０の処理はステップＳ９１５に移行する。なぜなら、ユーザ間でのファイル転送による複製では、ファイル間に親子関係は生じないからである。
さて、ステップＳ９１４でＤＢ管理部８７４は、現在注目している送信に対応する受信ログがあるか否かを判断する。
例えば、現在注目している送信が、サーバ８７０から端末８３０へのファイルの送信の場合がある。この場合、「現在注目している送信に対応する受信ログ」とは、端末８３０により生成されて端末８３０からサーバ８７０に送られる履歴情報であり、より具体的には、ログ種別として「受信」が指定されている履歴情報である。
逆に、現在注目している送信が、ステップＳ８１１で得られた履歴情報により示される送信の場合もある。この場合、「現在注目している送信に対応する受信ログ」とは、当該履歴情報をサーバ８７０に送ってきた端末からファイルを受信する他の端末（またはサーバ８７０）により生成され、ログ種別として「受信」が指定されているような、履歴情報である。
いずれの場合も、ＤＢ管理部８７４は、図１２のステップＳ４１２と類似の方法でＤＢ５３０−１内の履歴テーブルを検索することにより、現在注目している送信に対応する受信ログがあるか否かを判断することができる。
そして、現在注目している送信に対応する受信ログが見つかった場合、図２０の処理はステップＳ９０６に移行する。この場合、ステップＳ９０６でＤＢ管理部８７４は、見つかった受信ログに基づいて子デバイスＩＤと子ファイルＩＤを決定し、現在注目している送信に関して取得済みの情報から、親デバイスＩＤと親ファイルＩＤを決定する。それにより、ＤＢ管理部８７４は、ステップＳ９０６で適切な追跡情報を生成することができる。
逆に、現在注目している送信に対応する受信ログが見つからなければ、図２０の処理はステップＳ９１５に移行する。つまり、現在注目している送信に対応する受信ログが見つからない場合、サーバ８７０は、今回は追跡情報を生成せず、対応する受信ログ（つまり履歴情報）の受信を待ってから追跡情報を生成する。
さて、ステップＳ９１５でＤＢ管理部８７４は、テーブル（具体的には、履歴テーブルのエントリか、履歴テーブルとＩＤテーブルそれぞれのエントリか、履歴テーブルとＩＤテーブルと追跡テーブルそれぞれのエントリ）の送信先を決定する。例えば、ＤＢ管理部８７４は、以下のように送信先の端末を選んでもよい。
ステップＳ８１１で端末から履歴情報が受信され、ログ種別が「受信」でも「送信」でもなかった場合、ＤＢ管理部８７４は、履歴情報の送信元の端末のユーザが使う端末のうち、当該履歴情報の送信元以外で、メタデータの生成機能を持つ端末をすべて選んでもよい。例えば、端末８３０内でのファイルのコピーや変更などの操作を示す履歴情報が受信された場合は、ＤＢ管理部８７４は、端末８３０のユーザが使う他の端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。
ステップＳ８１１で端末から履歴情報が受信され、ログ種別が「受信」だった場合、ＤＢ管理部８７４は、履歴情報の送信元の端末のユーザが使う端末のうち、当該履歴情報の送信元以外で、メタデータの生成機能を持つ端末をすべて選んでもよい。また、ステップＳ９０８の後にステップＳ９１５が実行される場合（つまりユーザ間でのファイル転送が行われる場合）は、ＤＢ管理部８７４は、さらに、ファイルの送信先の端末のユーザが使う端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。
ステップＳ８１１で端末から履歴情報が受信され、ログ種別が「送信」だった場合、ＤＢ管理部８７４は、履歴情報の送信元の端末のユーザが使う端末のうち、当該履歴情報の送信元以外で、メタデータの生成機能を持つ端末をすべて選んでもよい。また、ステップＳ９１３の後にステップＳ９１５が実行される場合（つまりユーザ間でのファイル転送が行われる場合）は、ＤＢ管理部８７４は、さらに、ファイルの送信元の端末のユーザが使う端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。
ステップＳ８０１でサーバ８７０からのファイルの送信が検出された場合、ＤＢ管理部８７４は、ファイルの所有者が使う端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。また、ファイルの所有者と、ファイルをダウンロードした端末のユーザが異なる場合、ＤＢ管理部８７４は、さらに、ファイルをダウンロードした端末のユーザが使う端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。
ステップＳ８０４でサーバ８７０でのファイルの受信が検出された場合、ＤＢ管理部８７４は、ファイルの送信元の端末のユーザが使う端末のうち、当該送信元の端末以外で、メタデータの生成機能を持つ端末をすべて選んでもよい。
ステップＳ８０７またはＳ８０９で、ファイル記憶部８７５に記憶されている既存のファイルに対する何らかの操作が検出された場合、ＤＢ管理部８７４は、当該ファイルの所有者が使う端末のうち、メタデータの生成機能を持つ端末をすべて選んでもよい。つまり、操作がどのユーザの端末からの要求に基づいてなされたかには関係なく、ＤＢ管理部８７４は、ファイルの所有者に基づいて、メタデータの送信先を選ぶ。
ステップＳ９１５では、例えば以上のようにして、メタデータの送信先の１台以上の端末が選ばれる。その後、図２０の処理はステップＳ９０７に移行する。すると、ステップＳ９０７でＤＢ管理部８７４は、サーバ８７０が端末から受信したメタデータをＤＢに追加するか、または、ＤＢ管理部８７４自身が検出および取得した情報に基づいてＤＢ管理部８７４が生成したメタデータをＤＢに記録する。そして、図２０の処理は終了する。
以上説明した第３実施形態には、第１〜第２実施形態と同様の効果がある。さらに、第３実施形態によれば、あるユーザの所有するファイルに対する他のユーザによる操作を、当該ファイルの優先度に反映させることが可能となる。
ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。上記の各実施形態（変形例を含む）および下記の各種変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
図６〜９にはテーブル形式でデータを例示したが、ＸＭＬ（Extensible Markup Language）形式など、その他のデータ形式も利用可能である。また、追跡テーブルの１つのエントリは、１つのファイルツリー中の１つのエッジを表す。つまり、追跡テーブルは、木構造を示すためのデータ形式の一例である。実施形態によっては、追跡テーブルのようなテーブル形式のデータの代わりに、木構造を表すための別の形式のデータが、追跡情報を示すために利用されてもよい。
また、矛盾が生じない限り、フローチャート中のステップの実行順序は入れ替えられてもよい。また、入れ替え可能なステップ同士は、並列に実行されてもよい。
例えば、図１４〜１５では、ファイルを選択する順序について特に決められていない。しかし、実施形態によっては、優先度算出部３３７は、根ファイルを葉ファイルよりも先に選択してもよい。すると、優先度算出部３３７は、ステップＳ５１６での総和の算出の代わりに、算出済みの根ファイルの優先度を参照するだけでよい。
実施形態によっては、式（６）以外の式で表される優先度が算出されてもよい。式（１）〜（５）の定義も、実施形態に応じて適宜変更されてよい。例えば、式（４）の代わりに式（７）が使われてもよい。
Figure 2014063217
式（７）は以下のことを示す。
・同じユニーク値ｕのファイルを有する端末の台数ｎ（ｕ）が多いほど、コピー優先度ｑ（ｕ）は低い。
・同じユニーク値ｕのファイルの数が多いほど、コピー優先度ｑ（ｕ）は低い。
・同じユニーク値ｕのファイルの数が１のとき、ｑ（ｕ）＝ｐ（ｕ）が成り立つ。
実施形態によっては、同じユニーク値ｕのファイルを有する端末が２台以上ある場合に、優先度算出部は、ユニーク値ｕを持つ全ファイルの優先度ｒ（ｘ）の値を非常に低い値（例えばゼロ）に決めてもよい。
ところで、端末間での複製操作は、例えば、写真管理ソフトウェアなどの特定のアプリケーションを介して端末間で行われるファイル転送であってもよいし、添付ファイルつきの電子メールの送受信であってもよい。場合によっては、リムーバブルメディアを介して、ファイルが端末間で複製されてもよい。いずれにせよ、監視部が適宜の操作（例えば、特定のアプリケーションにおける操作、メーラからの添付ファイルの保存操作、リムーバブルメディアに対する読み書きの操作など）を検出することにより、適切な追跡情報の生成が可能となる。
なお、上記の第３実施形態は、サーバ８７０上でのファイルのコピー操作が許可されていない場合の例である。しかし、もちろん、サーバ８７０上でのファイルのコピー操作が許可されていてもよい。つまり、サーバ８７０上のファイルが、サーバ８７０上で複製されてもよい。その場合、ＤＢ管理部８７４は、サーバ８７０上でのコピー操作に応じて、適宜のメタデータを生成し、ＤＢを更新する。
具体的には、ファイル記憶部８７５に記憶されているファイルの所有者自身が、当該ファイルをサーバ８７０上でコピーした場合は、ＤＢ管理部８７４は、履歴情報と追跡情報の双方を生成する。
しかし、他のユーザが当該ファイルをサーバ８７０でコピーした場合は、ＤＢ管理部８７４は、履歴情報を生成するが、追跡情報は生成しない。なぜなら、コピー操作により新たに作成されたファイルの所有者は、元のファイルの所有者とは異なるからである。つまり、複数のユーザ間での複製操作では、ファイル間に親子関係は生じない。換言すれば、追跡情報により表されるファイルツリーは、１人のユーザにとってのファイルの優先度を算出するために参照されるのであり、あるユーザにとっての優先度は、他のユーザにとっての優先度に影響しない。
ところで、第２実施形態では、ＤＢ記憶部３１６とＤＢ記憶部３３６とＤＢ記憶部３５２が同様のＤＢを保持し、第３実施形態では、ＤＢ記憶部８３６とＤＢ記憶部８７２が同様のＤＢを保持する。つまり、第２実施形態と第３実施形態は、ＤＢが冗長化される例を示す。
しかし、実施形態によっては、ＤＢが完全に冗長化されていなくてもよい。ただし、図１０のステップＳ２１４の問い合わせに関して説明したように、端末がオフラインの場合もある。よって、各端末は、当該端末がオフラインの間に当該端末上で行われる操作に関するエントリだけは、少なくとも保持する。つまり、各端末は、当該端末がサーバとの通信を行わない期間中に当該端末上で行われる操作に関して、ＩＤテーブル、履歴テーブル、追跡テーブルのうち少なくとも１つのテーブルの、少なくとも１つのエントリを保持する。
各端末は、オフライン状態からオンライン状態に変化したら、オフライン状態の間にＤＢ記憶部に蓄積したエントリをサーバに送信する。実施形態によっては、このような送信の後、端末は、送信済みのエントリを削除してもよい。
ところで、実施形態によっては、ユニーク値が使われなくてもよい。代わりに、ファイル同士のデータが等しいか否かをチェックするためのコマンド等が利用されてもよい。
また、ユニーク値同士の衝突を無視することができない場合は、図１４〜１５のバックアップ制御処理が変形されてもよい。具体的には、優先度算出部３３７または８３７は、ユニーク値だけに注目してユニーク値ごとにステップＳ５０５〜Ｓ５０８を実行する代わりに、各ファイルツリー別に、当該ファイルツリー内でのユニーク値ごとにステップＳ５０５〜Ｓ５０８を実行してもよい。
ところで、第２実施形態と第３実施形態では、端末が優先度を算出する。しかし、第１実施形態に関して説明したように、サーバが優先度を算出してもよい。つまり、図１の処理を実行する情報処理装置は、ユーザの使う複数の端末のうちの１台以上と通信を行う他のコンピュータ（例えば、管理サーバ１１２、サーバ３５０、またはサーバ８７０）であってもよい。
優先度を算出する情報処理装置としてのサーバは、複数台の端末のうちの第１の端末に記憶されているいずれかのファイルに対して第１の端末上で行われる操作の種類を示す履歴情報を、第１の端末から受信してもよい。こうした履歴情報の受信の例は、図１２のステップＳ４０１や図１９のステップＳ８１１に例示されている。
また、第１の端末に記憶されているファイルｘ１を、第１の端末が第１の端末内でファイルｘ２に複製する（つまりコピーする）こともある。優先度を算出する情報処理装置としてのサーバは、第１の端末から、ファイルｘ１とｘ２を関連づける追跡情報を受信してもよい。こうした追跡情報の受信も、図１２のステップＳ４０１や図１９のステップＳ８１１に例示されている。サーバは、このように受信により取得した追跡情報を、優先度の算出において使う場合もある。
また、第１の端末に記憶されているファイルｘ３を、第１の端末が第２の端末に送信し、送信されたファイルｘ３を第２の端末がファイルｘ４として第２の端末に記憶する場合があり得る。例えば、第１と第２の端末がそれぞれ端末３１０と３３０であってもよく、ファイルｘ３は図５のファイル４０４であってもよい。
この場合、優先度を算出する情報処理装置としてのサーバは、第１の端末からのファイルｘ３に関する通知と、第２の端末からのファイルｘ４に関する通知に基づいて、ファイルｘ３とｘ４を関連づける追跡情報を生成してもよい。例えば、サーバは、図５のステップＳ１１２の通知とステップＳ１０９の通知に基づいて、ステップＳ１１３で、追跡情報を生成してもよい。サーバは、このようにして自ら生成した追跡情報を、優先度の算出において使う場合もある。
また、第１の端末に記憶されているファイルｘ５を、第１の端末がサーバに送信し、送信されたファイルｘ５をサーバがファイルｘ６としてサーバ内に記憶する場合もあり得る。例えば、第１の端末が端末８３０であってもよく、サーバはサーバ８７０であってもよく、ファイルｘ５はファイル９０４であってもよい。
この場合、優先度を算出する情報処理装置としてのサーバは、ファイルｘ５とｘ６を関連づける追跡情報を、ファイルｘ６の保存に応じて生成してもよい。このような追跡情報の生成は、例えば図１７のステップＳ６０８に例示されている。サーバは、このようにして自ら生成した追跡情報を、優先度の算出において使う場合もある。
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
ユーザが使う複数台の端末のうちの１台であるか、または、前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータである情報処理装置に、
前記複数台の端末上に分散して記憶されているか、または前記複数台の端末と前記コンピュータに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得し、
前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を取得し、
前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
当該個々のファイルに対して行われた操作の種類、
前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
に基づく優先度を算出し、
バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する
ことを含むバックアップ制御処理を実行させるためのバックアップ制御プログラム。
（付記２）
前記複数個のファイルのうち、他のファイルに対する複製操作により得られたのではない根ファイルの前記優先度を算出する処理は、１回以上の複製操作により根ファイルから直接または間接に得られた１個以上の子孫ファイルの各々に対して行われた各操作に応じて、前記根ファイルの前記優先度を上げる処理を含む
ことを特徴とする付記１に記載のバックアップ制御プログラム。
（付記３）
前記１個以上の子孫ファイルのうちで、どの複製操作における複製元ファイルでもない葉ファイルの前記優先度を算出する処理は、前記根ファイルの前記優先度に応じて前記葉ファイルの前記優先度を上げる処理を含む
ことを特徴とする付記２に記載のバックアップ制御プログラム。
（付記４）
前記複数個のファイルのうちの第１のファイルに対する複製操作により第２のファイルが得られた場合において、
前記第１のファイルのデータと前記第２のファイルのデータが等しい場合よりも、前記第１のファイルの前記データと前記第２のファイルの前記データが等しくない場合の方が、前記第１のファイルの前記優先度がより高く、
前記第１のファイルの前記データと前記第２のファイルの前記データが等しい場合よりも、前記第１のファイルの前記データと前記第２のファイルの前記データが等しくない場合の方が、前記第２のファイルの前記優先度もより高い
ことを特徴とする付記１から３のいずれか１項に記載のバックアップ制御プログラム。
（付記５）
各ファイルに対する各操作は、
前記ユーザからの指示に基づくユーザ主導操作であるか、または、
前記複数台の端末のうち当該ファイルを記憶する端末が、所定のプログラムを実行することにより自動的に行われる自動操作であり、
前記ユーザ主導操作は、前記自動操作よりも、前記優先度をより高めるように、前記優先度に影響する
ことを特徴とする付記１から４のいずれか１項に記載のバックアップ制御プログラム。
（付記６）
新規ファイルを作成する作成操作は、他の操作よりも、前記優先度をより高めるように、前記優先度に影響することを特徴とする付記１から５のいずれか１項に記載のバックアップ制御プログラム。
（付記７）
前記複数個のファイルの各々に対して行われた各操作について、当該操作が行われた時点が新しいほど、当該ファイルの前記優先度が高い
ことを特徴とする付記１から６のいずれか１項に記載のバックアップ制御プログラム。
（付記８）
前記複数個のファイルの各々に対して行われた各操作について、当該操作にかかった時間が長いほど、当該ファイルの前記優先度が高い
ことを特徴とする付記１から７のいずれか１項に記載のバックアップ制御プログラム。
（付記９）
前記複数個のファイルのうち、あるファイルが前記コンピュータに記憶されている場合、前記あるファイルに対して前記ユーザ以外の他のユーザが行った操作についての前記履歴情報が取得される
ことを特徴とする付記１から８のいずれか１項に記載のバックアップ制御プログラム。
（付記１０）
前記情報処理装置が、前記複数台の端末のうちの第１の端末であり、
前記履歴情報を取得する処理が、
前記複数個のファイルのうちで、前記第１の端末に記憶されているいずれかのファイルに対して、前記第１の端末上で行われる操作を検出し、
前記検出した操作の種類を示す前記履歴情報を生成する
ことを含む
ことを特徴とする付記１から９のいずれか１項に記載のバックアップ制御プログラム。
（付記１１）
前記履歴情報を取得する処理が、さらに、
前記複数個のファイルのうちで、前記複数台の端末のうちのある特定の端末に記憶されているいずれかのファイルの、前記特定の端末から前記第１の端末への送信を検出し、
前記特定の端末から前記第１の端末へ送信された前記ファイルに関する情報を推定する
ことを含む
ことを特徴とする付記１０に記載のバックアップ制御プログラム。
（付記１２）
前記追跡情報を取得する処理が、
前記複数個のファイルのうちで、前記第１の端末に記憶されている第１のファイルを前記第１の端末内で第２のファイルに複製する複製操作を検出し、
前記第１のファイルと前記第２のファイルを関連づける前記追跡情報を生成する
ことを含む
ことを特徴とする付記１０または１１に記載のバックアップ制御プログラム。
（付記１３）
前記情報処理装置が、前記コンピュータであり、
前記履歴情報を取得する処理が、前記複数個のファイルのうちで、前記複数台の端末のうちの第１の端末に記憶されているいずれかのファイルに対して前記第１の端末上で行われる操作の種類を示す前記履歴情報を、前記第１の端末から受信することを含む
ことを特徴とする付記１から９のいずれか１項に記載のバックアップ制御プログラム。
（付記１４）
前記追跡情報を取得する処理が、
前記複数個のファイルのうちで、前記第１の端末に記憶されている第３のファイルを、前記第１の端末が前記第１の端末内で第４のファイルに複製した場合に、前記第１の端末から、前記第３のファイルと前記第４のファイルを関連づける前記追跡情報を受信し、
前記複数個のファイルのうちで、前記第１の端末に記憶されている第５のファイルを、前記第１の端末が第２の端末に送信し、送信された前記第５のファイルを前記第２の端末が第６のファイルとして前記第２の端末内に記憶した場合に、前記第１の端末からの前記第５のファイルに関する通知と、前記第２の端末からの前記第６のファイルに関する通知に基づいて、前記第５のファイルと前記第６のファイルを関連づける前記追跡情報を生成し、
前記複数個のファイルのうちで、前記第１の端末に記憶されている第７のファイルを、前記第１の端末が前記コンピュータに送信し、送信された前記第７のファイルを前記コンピュータが第８のファイルとして前記コンピュータ内に記憶した場合に、前記第７のファイルと前記第８のファイルを関連づける前記追跡情報を生成する
ことを含む
ことを特徴とする付記１３に記載のバックアップ制御プログラム。
（付記１５）
ユーザが使う複数台の端末のうちの１台であるか、または、前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータである情報処理装置が、
前記複数台の端末上に分散して記憶されているか、または前記複数台の端末と前記コンピュータに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得し、
前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を取得し、
前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
当該個々のファイルに対して行われた操作の種類、
前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
に基づく優先度を算出し、
バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する
ことを特徴とするバックアップ制御方法。
（付記１６）
ユーザが使う複数台の端末上に分散して記憶されているか、または前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータと前記複数台の端末とに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を記憶する第１の記憶部と、
前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を記憶する第２の記憶部と、
前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
当該個々のファイルに対して行われた操作の種類、
前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
に基づく優先度を算出する優先度算出部と、
バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する選択部
を備えることを特徴とする情報処理装置。
（付記１７）
前記複数台の端末のうちの１台であることを特徴とする付記１６に記載の情報処理装置。
（付記１８）
前記コンピュータであることを特徴とする付記１６に記載の情報処理装置。
１００、３００、８００ システム
１０１、２２０、３７０、８９０ ネットワーク
１０２ スマートフォン
１０３、１０５ ＳＳＤ
１０４ タブレット端末
１０６ ＰＣ
１０７、１０８ ＨＤＤ
１０９ カメラ
１１０、１１１、３１０、３３０、８１０、８３０、８５０ 端末
１１２ 管理サーバ
１１３ コンテンツサーバ
１１４ ＮＡＳ
２００ 情報処理装置
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ネットワーク通信装置
２０４ シリアル接続Ｉ／Ｆ回路
２０５ 入力装置
２０６ 出力装置
２０７ 不揮発性記憶装置
２０８ リーダ／ライタ
２０９ バス
２１０ 記憶媒体
２２１ プログラム提供者
３１１、３３１、３５１、８１１、８３１、８５１、８７１ 通信部
３１２、３３２、８１３、８３２、８５２、８７５ ファイル記憶部
３１３、３３３、８３３ 監視部
３１４、３３４、８１４、８３４、８５３ デバイスＩＤ記憶部
３１５、３３５、３５４、８３５、８７４ ＤＢ管理部
３１６、３３６、３５２、８３６、８７２ ＤＢ記憶部
３３７、８３７ 優先度算出部
３３８、８３８ バックアップ記憶部
３３９、８３９ バックアップ制御部
３５０、８７０ サーバ
３５３、８７３ デバイス管理部
４０１、４０４、６０１、６１１〜６１３、６２１〜６２３、６３１〜６３９、９０１、９０４ ファイル
４０２、４０３、４０５、４０６、４０７、９０２、９０３、９０６ メタデータ
４０８、９０７ 優先度
５００、５１０、５３０−１〜５３０−Ｕ ＤＢ
５０１、５１１、５３１ ＩＤテーブル
５０２ａ、５０２ｂ、５１２ａ、５１２ｂ、５３２ａ、５３２ｂ 履歴テーブル
５０３、５１３、５３３ 追跡テーブル
５２０ デバイス管理テーブル
６００、６１０、６２０、６３０ ファイルツリー
６２４、６４０、６４１ 同一データグループ
７０１〜７０３ 定義
８１２ 作成部
９０５ コメント

Claims (10)

  1. ユーザが使う複数台の端末のうちの１台であるか、または、前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータである情報処理装置に、
    前記複数台の端末上に分散して記憶されているか、または前記複数台の端末と前記コンピュータに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得し、
    前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を取得し、
    前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
    当該個々のファイルに対して行われた操作の種類、
    前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
    前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
    に基づく優先度を算出し、
    バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する
    ことを含むバックアップ制御処理を実行させるためのバックアップ制御プログラム。
  2. 前記複数個のファイルのうち、他のファイルに対する複製操作により得られたのではない根ファイルの前記優先度を算出する処理は、１回以上の複製操作により根ファイルから直接または間接に得られた１個以上の子孫ファイルの各々に対して行われた各操作に応じて、前記根ファイルの前記優先度を上げる処理を含む
    ことを特徴とする請求項１に記載のバックアップ制御プログラム。
  3. 前記１個以上の子孫ファイルのうちで、どの複製操作における複製元ファイルでもない葉ファイルの前記優先度を算出する処理は、前記根ファイルの前記優先度に応じて前記葉ファイルの前記優先度を上げる処理を含む
    ことを特徴とする請求項２に記載のバックアップ制御プログラム。
  4. 前記複数個のファイルのうちの第１のファイルに対する複製操作により第２のファイルが得られた場合において、
    前記第１のファイルのデータと前記第２のファイルのデータが等しい場合よりも、前記第１のファイルの前記データと前記第２のファイルの前記データが等しくない場合の方が、前記第１のファイルの前記優先度がより高く、
    前記第１のファイルの前記データと前記第２のファイルの前記データが等しい場合よりも、前記第１のファイルの前記データと前記第２のファイルの前記データが等しくない場合の方が、前記第２のファイルの前記優先度もより高い
    ことを特徴とする請求項１から３のいずれか１項に記載のバックアップ制御プログラム。
  5. 前記情報処理装置が、前記複数台の端末のうちの第１の端末であり、
    前記履歴情報を取得する処理が、
    前記複数個のファイルのうちで、前記第１の端末に記憶されているいずれかのファイルに対して、前記第１の端末上で行われる操作を検出し、
    前記検出した操作の種類を示す前記履歴情報を生成する
    ことを含む
    ことを特徴とする請求項１から４のいずれか１項に記載のバックアップ制御プログラム。
  6. 前記追跡情報を取得する処理が、
    前記複数個のファイルのうちで、前記第１の端末に記憶されている第１のファイルを前記第１の端末内で第２のファイルに複製する複製操作を検出し、
    前記第１のファイルと前記第２のファイルを関連づける前記追跡情報を生成する
    ことを含む
    ことを特徴とする請求項５に記載のバックアップ制御プログラム。
  7. 前記情報処理装置が、前記コンピュータであり、
    前記履歴情報を取得する処理が、前記複数個のファイルのうちで、前記複数台の端末のうちの第１の端末に記憶されているいずれかのファイルに対して前記第１の端末上で行われる操作の種類を示す前記履歴情報を、前記第１の端末から受信することを含む
    ことを特徴とする請求項１から４のいずれか１項に記載のバックアップ制御プログラム。
  8. 前記追跡情報を取得する処理が、
    前記複数個のファイルのうちで、前記第１の端末に記憶されている第３のファイルを、前記第１の端末が前記第１の端末内で第４のファイルに複製した場合に、前記第１の端末から、前記第３のファイルと前記第４のファイルを関連づける前記追跡情報を受信し、
    前記複数個のファイルのうちで、前記第１の端末に記憶されている第５のファイルを、前記第１の端末が第２の端末に送信し、送信された前記第５のファイルを前記第２の端末が第６のファイルとして前記第２の端末内に記憶した場合に、前記第１の端末からの前記第５のファイルに関する通知と、前記第２の端末からの前記第６のファイルに関する通知に基づいて、前記第５のファイルと前記第６のファイルを関連づける前記追跡情報を生成し、
    前記複数個のファイルのうちで、前記第１の端末に記憶されている第７のファイルを、前記第１の端末が前記コンピュータに送信し、送信された前記第７のファイルを前記コンピュータが第８のファイルとして前記コンピュータ内に記憶した場合に、前記第７のファイルと前記第８のファイルを関連づける前記追跡情報を生成する
    ことを含む
    ことを特徴とする請求項７に記載のバックアップ制御プログラム。
  9. ユーザが使う複数台の端末のうちの１台であるか、または、前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータである情報処理装置が、
    前記複数台の端末上に分散して記憶されているか、または前記複数台の端末と前記コンピュータに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を取得し、
    前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を取得し、
    前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
    当該個々のファイルに対して行われた操作の種類、
    前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
    前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
    に基づく優先度を算出し、
    バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する
    ことを特徴とするバックアップ制御方法。
  10. ユーザが使う複数台の端末上に分散して記憶されているか、または前記複数台の端末のうち少なくとも１台以上とネットワークを介して通信を行うコンピュータと前記複数台の端末とに分散して記憶されている複数個のファイルの各々に対して行われた各操作について、当該操作の種類を示す履歴情報を記憶する第１の記憶部と、
    前記複数台の端末のうちの１台の端末内で行われたか、前記複数台の端末のうちの２台の端末間で行われたか、または、前記複数台の端末のうちの１台と前記コンピュータとの間で行われた各複製操作について、複製元のファイルと、当該複製操作により作成されたファイルとを関連づける追跡情報を記憶する第２の記憶部と、
    前記履歴情報と前記追跡情報を用いて、前記複数個のファイルに含まれる個々のファイルについて、
    当該個々のファイルに対して行われた操作の種類、
    前記追跡情報により当該個々のファイルと関連づけられている別のファイルが前記複数個のファイルの中にあるか否か、および
    前記別のファイルがある場合は、当該個々のファイルのデータと前記別のファイルのデータが等しいか否か
    に基づく優先度を算出する優先度算出部と、
    バックアップする対象のファイルの量に関して指定される条件を満たす範囲内で、前記優先度の降順に、前記複数個のファイルの中から１つ以上のファイルを選択する選択部
    を備えることを特徴とする情報処理装置。
JP2012206319A 2012-09-19 2012-09-19 バックアップ制御プログラム、バックアップ制御方法および情報処理装置 Expired - Fee Related JP5924209B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2012206319A JP5924209B2 (ja) 2012-09-19 2012-09-19 バックアップ制御プログラム、バックアップ制御方法および情報処理装置
US14/025,411 US9292387B2 (en) 2012-09-19 2013-09-12 Medium, control method, and information processing apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012206319A JP5924209B2 (ja) 2012-09-19 2012-09-19 バックアップ制御プログラム、バックアップ制御方法および情報処理装置

Publications (2)

Publication Number Publication Date
JP2014063217A true JP2014063217A (ja) 2014-04-10
JP5924209B2 JP5924209B2 (ja) 2016-05-25

Family

ID=50275519

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012206319A Expired - Fee Related JP5924209B2 (ja) 2012-09-19 2012-09-19 バックアップ制御プログラム、バックアップ制御方法および情報処理装置

Country Status (2)

Country Link
US (1) US9292387B2 (ja)
JP (1) JP5924209B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019079281A (ja) * 2017-10-25 2019-05-23 富士ゼロックス株式会社 同期処理装置、ファイル同期システムおよびプログラム
JP2021103494A (ja) * 2019-12-25 2021-07-15 富士通株式会社 実行方法、情報処理装置及び実行プログラム

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012102717A1 (en) * 2011-01-27 2012-08-02 Hewlett-Packard Development Company, L. P. Importance class based data management
US9230001B2 (en) 2013-11-14 2016-01-05 Vmware, Inc. Intelligent data propagation using performance monitoring
US9268836B2 (en) * 2013-11-14 2016-02-23 Vmware, Inc. Intelligent data propagation in a highly distributed environment
US10198445B2 (en) * 2014-06-30 2019-02-05 Google Llc Automated archiving of user generated media files
US10872099B1 (en) * 2017-01-24 2020-12-22 Tintri By Ddn, Inc. Automatic data protection for virtual machines using virtual machine attributes
US11860819B1 (en) * 2017-06-29 2024-01-02 Amazon Technologies, Inc. Auto-generation of partition key
US11010470B2 (en) * 2017-12-15 2021-05-18 Microsoft Technology Licensing, Llc Anti-virus file system cache for operating system remediation
US11055261B2 (en) * 2018-02-28 2021-07-06 Microsoft Technology Licensing, Llc In-application support for topological changes to files during remote synchronization
US10942816B1 (en) * 2018-09-06 2021-03-09 NortonLifeLock Inc. Systems and methods for dynamically adjusting a backup policy
CN112612775B (zh) * 2020-12-17 2023-06-27 平安消费金融有限公司 一种数据存储方法、装置、计算机设备及存储介质
US12093138B2 (en) * 2022-12-16 2024-09-17 Dell Products, L.P. Prioritize slices for faster file backup and restore
CN116107815B (zh) * 2023-04-07 2023-06-13 微网优联科技(成都)有限公司 互联网数据备份方法、装置及服务器

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06250902A (ja) * 1993-02-24 1994-09-09 Hitachi Ltd 分散システムのファイルバックアップ方法
JPH1011344A (ja) * 1996-06-24 1998-01-16 Mitsubishi Electric Corp データ・バックアップ方法
JP2008084327A (ja) * 2007-10-01 2008-04-10 Hitachi Ltd データのバックアップのための方法、装置、システム、プログラム及び記憶媒体
US8352429B1 (en) * 2009-08-31 2013-01-08 Symantec Corporation Systems and methods for managing portions of files in multi-tier storage systems

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07175916A (ja) 1993-12-20 1995-07-14 Ricoh Co Ltd 画像読取形成装置
US5829023A (en) * 1995-07-17 1998-10-27 Cirrus Logic, Inc. Method and apparatus for encoding history of file access to support automatic file caching on portable and desktop computers
JP2861908B2 (ja) * 1996-01-16 1999-02-24 日本電気株式会社 ブラウジング装置
JP4232283B2 (ja) * 1999-08-10 2009-03-04 ソニー株式会社 アクセス履歴提示方法及びアクセス履歴提示装置、資源提供方法及び資源提供装置、並びに、プログラムを記録したコンピュータ読み取り可能な記録媒体
US7865157B2 (en) * 2003-11-03 2011-01-04 Thomson Licensing Controllable mixer
JP4426280B2 (ja) 2003-12-25 2010-03-03 株式会社日立製作所 バックアップ／リストアシステム及び方法
US20070100908A1 (en) * 2005-11-01 2007-05-03 Neeraj Jain Method and apparatus for tracking history information of a group session
JP4826331B2 (ja) 2006-05-09 2011-11-30 富士ゼロックス株式会社 文書利用追跡システム
JP5020799B2 (ja) 2007-12-25 2012-09-05 キヤノン株式会社 情報処理装置及び情報処理方法
US8473956B2 (en) * 2008-01-15 2013-06-25 Microsoft Corporation Priority based scheduling system for server
JP2010049729A (ja) 2008-08-20 2010-03-04 Canon Inc 情報処理装置
US9002801B2 (en) * 2010-03-29 2015-04-07 Software Ag Systems and/or methods for distributed data archiving amongst a plurality of networked computing devices
US20140032833A1 (en) * 2012-07-25 2014-01-30 International Business Machines Corporation Dynamic Disk Space Management In A File System

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06250902A (ja) * 1993-02-24 1994-09-09 Hitachi Ltd 分散システムのファイルバックアップ方法
JPH1011344A (ja) * 1996-06-24 1998-01-16 Mitsubishi Electric Corp データ・バックアップ方法
JP2008084327A (ja) * 2007-10-01 2008-04-10 Hitachi Ltd データのバックアップのための方法、装置、システム、プログラム及び記憶媒体
US8352429B1 (en) * 2009-08-31 2013-01-08 Symantec Corporation Systems and methods for managing portions of files in multi-tier storage systems

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019079281A (ja) * 2017-10-25 2019-05-23 富士ゼロックス株式会社 同期処理装置、ファイル同期システムおよびプログラム
JP7114877B2 (ja) 2017-10-25 2022-08-09 富士フイルムビジネスイノベーション株式会社 同期処理装置、ファイル同期システムおよびプログラム
JP2021103494A (ja) * 2019-12-25 2021-07-15 富士通株式会社 実行方法、情報処理装置及び実行プログラム

Also Published As

Publication number Publication date
US20140081920A1 (en) 2014-03-20
US9292387B2 (en) 2016-03-22
JP5924209B2 (ja) 2016-05-25

Similar Documents

Publication Publication Date Title
JP5924209B2 (ja) バックアップ制御プログラム、バックアップ制御方法および情報処理装置
US11615059B2 (en) Smart archiving and data previewing for mobile devices
US20220138148A1 (en) Data previewing before recalling large data files
CN101404567B (zh) 用于访问备份数据的方法和计算机系统
US10747719B2 (en) File system point-in-time restore using recycle bin and version history
US8135677B2 (en) File management system and method
US9864736B2 (en) Information processing apparatus, control method, and recording medium
US9565232B2 (en) Importing content items
CN103620549B (zh) 用于统一数据存储的存储介质抽象
US9183205B1 (en) User-based backup
WO2014083591A1 (en) Storage system and file management method
US10241870B1 (en) Discovery operations using backup data
US20160019234A1 (en) Application recommendation using stored files
WO2011108021A1 (en) File level hierarchical storage management system, method, and apparatus
AU2010232791B2 (en) Employing user-context in connection with backup or restore of data
US8108359B1 (en) Methods and systems for tag-based object management
US11531658B2 (en) Criterion-based retention of data object versions
JP2014526748A (ja) 効率的なデータ回復
JP2012098934A (ja) 文書管理システム、文書管理システムの制御方法、プログラム
US20130325932A1 (en) Electronic device and method for storing distributed documents
US11223528B2 (en) Management of cloud-based shared content using predictive cost modeling
CN107220248A (zh) 一种用于存储数据的方法和装置
US11809381B2 (en) Accessing network based content items by a mobile device while offline
JP6610189B2 (ja) 協働文書のオンライン文書管理システムとの同期
US10853316B1 (en) File versioning for content stored in a cloud computing environment

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150604

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160212

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160322

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160404

R150 Certificate of patent or registration of utility model

Ref document number: 5924209

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees