JP2014519655A - 多段階多ソースバックアップの方法と装置 - Google Patents

Abstract

デバイス内のリソースの第１のバックアップソースへの変更を識別する方法および装置について記述する。第１のバックアップソースから、第２のバックアップソースに対する許可のためのトークンを受信するのに応じて、リソースの変更が、トークンを使って第２のバックアップソースへバックアップされてもよい。第２のバックアップソースへの変更のバックアップが成功すると、リソースの変更が、第１のバックアップソースへコミットされてもよい。

Description

［関連出願の相互参照］
本願は、２０１１年６月３日に出願され、「Ｍｅｔｈｏｄｓ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｍｕｌｔｉ−Ｐｈａｓｅ Ｍｕｌｔｉ−Ｓｏｕｒｃｅ Ｂａｃｋｕｐ ａｎｄ Ｒｅｓｔｏｒｅ」と題された、Ｇｏｒｄｏｎ Ｊ．Ｆｒｅｅｄｍａｎ他の、米国仮特許出願第６１／４９３，３６０号の利益を請求するものであり、それを全体として参照により本願に援用する。

［技術分野］
本発明は、一般に、デバイスのバックアップに関する。より詳細には、本発明は、デバイスのためにファイルを複数の段階で複数のソースを用いてバックアップすることに関する。

移動デバイス、特に、セルラー電話、携帯情報端末（ＰＤＡ）、タブレットデバイス等の移動通信デバイスの急増に伴って、バックアップおよび復元操作は、これらの移動デバイスの日常的な使用においてますます不可欠なものとなってきている。しかし、作業環境、モバイルアプリケーションおよび／またはネットワークストレージ・インフラが進化を続けるにつれて、移動デバイスについての絶えず変化する要件に伴う、そのような能力をサポートするという新たな課題も浮かび上がっている。

例えば、従来のバックアップ／復元操作は、高帯域幅ネットワーク接続を用いたバックアップ／復元ソフトウェアおよびハードウェアとの複雑な対話に基づいて行われることがある。しかし、移動デバイスは、ある場所から別の場所への移動中に、信頼性が低く、帯域幅が限られ、および／または、予測不可能でありうるワイヤレスネットワーク接続を使って使用されることが多い。従って、移動デバイスのバックアック／復元操作を完了するのに、長い時間および／または複数の試行が必要となる可能性がある。また、ほとんどのワイヤレスネットワークはこれらの操作についてはオープンであるため、さらなるセキュリティリスクが存在する可能性もある。

従って、既存のメカニズムでは、信頼性があってセキュアでユーザにやさしい形で移動デバイスをバックアップおよび／または復元できない可能性がある。

一実施形態では、デバイス内のリソースが、クラウドストレージとも呼ばれるネットワークベースのストレージに、複数のレベルの抽象化を介して、増分バックアップおよび再開可能なバックアップ操作が可能になるように、バックアップされてもよい。バックアップソースは、バックアップ／復元性能を向上させると共にデバイスの通常操作への影響を最小化するように、動的に構成されてもよい。一実施形態では、デバイスは、モバイルバックアップサービス（ＭＢＳ）と通信して、リソース（またはファイル）のどの部分をバックアップするのかを、ＭＢＳの中に維持される階層的データに基づいて判定してもよい。階層的データは、デバイスのオーナアカウントと、オーナアカウントに関連する各デバイスに固有のバックアップ階層（または表現）と、および／または、バックアップされている各ファイルを説明するメタデータとを含んでいてもよい。

一実施形態では、ＭＢＳが、（Ｍｏｂｉｌｅ Ｍｅ Ｃｈｕｎｋ ＳｅｒｖｉｃｅすなわちＭＭＣＳのような）コンテンツサービスと通信して、例えばクラウドストレージにおける、データチャンクの重複を回避する目的で、ファイルのうちのどの実際のデータチャンク（すなわちチャンク化データ）がバックアップ用にアップロードされるべきなのかを識別してもよい。ＭＭＣＳは、ファイルとファイルのデータチャンクを識別する一組のチャンク識別子との間のマッピングを把握してもよい。一実施形態では、ＭＭＣＳは、ベンダクラウドストレージを動的に構成または配置して、バックアップ用に識別されたファイルのコンテンツをチャンク化データのコンテナの中に記憶することができる。

別の実施形態では、リソース（またはファイル）がユーザデータ（例えばユーザが作成したデータ）を表すのか、あるいは購入された資産もしくはコンテンツを表すのかを把握するために、デバイス内にメタデータが維持されてもよい。購入資産の実データは、バックアップされることを必要とせず、利用可能な資産ストア（すなわちサイト）からダウンロードまたは復元されうる。例えばＰｏｄｃａｓｔのような、特定の自由に入手可能な資産は、それらの実際のコンテンツが直接バックアップされて復元される代わりに、それらの識別子をバックアップすることによって、再ダウンロードされてもよい。バックアップされるべきリソースを記述するメタデータによって、バックアップ用の多様なソースの自動識別が、これを好機としてユーザに透過的に可能になりうる。例えば、購入資産としてリソースをバックアップすることは、購入資産のコンテンツをプッシュアップする代わりに、メモを取ることを含んでいてもよい。メモされた購入資産を復元するには、購入資産のコンテンツが、資産ストアからプルダウンされるとよい。例えば、資産ストアとは、ネットワークアクセス可能なサイトであって、購入可能な資産をホストし、購入された資産を記憶し、および／または、自由に利用可能な資産（すなわちコンテンツ）をホストしていてもよい。

任意で、リソースが、クラウドストレージ、ローカルコンピュータ、資産ストアおよび／またはその他の適用可能なソースのような複数のソースから、好機をねらってまたデバイスに分割復元されてもよい。メディア資産のタイプを示すメタデータがデバイス内のリソースについて把握されて、リソースを復元（またはバックアップ）するのにどのソースが利用可能なのか、および／またはコスト効率が良いのかが、例えば性能や帯域幅や消費電力および／または適用可能な考慮事項に基づいて、動的に識別されてもよい。

例えば、デバイスが、復元されるべきリソースのコンテンツデータの一部分を記憶している（例えば有線または無線で接続されている）ローカルコンピュータへの接続に気付くことがありうる。そのコンテンツデータの一部分は、すでに接続されているコンピュータから引き出されてもよい。その後、ローカルコンピュータから入手できない残りのリソースが、クラウドストレージおよび／またはストアから分割復元されるように識別されてもよい。結果として、音楽やアプリケーションやその他のメディアファイルのようなコンテンツデータは、クラウド（またはクラウドストレージ）の中にバックアップされてもよいが、そのデバイスにとってのローカルコンピュータから復旧することもやはりできる。

一実施形態では、ファイルまたはリソースが、例えば、関連のアプリケーションやメディアタイプやその他の拡張可能な情報に基づいて、バックアップ用に選択されることがありうる。リソースが、リソースの実際のコンテンツをバックアップすることを必要とせずストアから入手可能な、ストア資産（例えば、資産ストアから入手可能な購入資産）として把握されてもよい。任意で、別のリソースが、ストアから入手可能でなく、例えばクラウドストレージを介して、バックアップおよび復元を必要とするユーザデータとして把握されることがありうる。アプリケーションが、ストア資産としてのアプリケーション自体とユーザデータとしてのアプリケーションデータとを含めて、リソースに関連付けられてもよい。従って、アプリケーションと関連のアプリケーションデータとが、別のソースから復元されてもよい。

例えば、クラウドバックアップ用にデバイス内で選択されたリソースは、対応するアプリケーション自体を含むことなくアプリケーションデータを含んでいてもよい。アプリケーションは、資産ストアからデバイスへ再ダウンロードされてもよく、アプリケーションデータは、クラウドストレージおよび／またはローカルコンピュータから復元されてもよい。あるいは、アプリケーションが、ローカルコンピュータから同期されて、アプリケーションデータをクラウドストレージから復元してもよい。他にも、アプリケーションとアプリケーションデータとを別個に復元するためのバックアップソースの組み合わせは可能でありうる。一部の実施形態では、アプリケーションデータは、その対応するアプリケーションを（例えばユーザが）使用できるようになる前に復元されてもよい。アプリケーションは、適切な順序付けを行うために、（例えばクラウドストレージまたはその他のソースからの）アプリケーションデータの復元を開始する前にダウンロードされるかまたは同期されてもよい。

一実施形態では、バックアップからデバイスへのリソースの復元が複数の段階で行われて、リソースが復元されている間、デバイスを使用可能でユーザに応答できる作業状態に維持してもよい。例えば、デバイスが、デバイスのデュアルフェーズすなわち二段階の復元のために、最初のモーダルな復元セッション（例えば第１のモード）に入り、その後、バックグラウンドの復元セッション（例えば第２のモード）に入ってもよい。一実施形態では、最初のモーダルな復元セッションではデバイスがユーザ入力に応答しないかたちで、デバイスがユーザによって使用されてもよい。一実施形態では、最初のモーダルなセッションは、デバイスをリブートするための中核的なユーザファイルを復元するために、短くて速くてもよい。その後、バックグラウンドセッションでは、個別のアプリケーションがバックグラウンドでまたデバイスへ復元されている間に、ユーザがデバイスを使用できてもよい。バックグラウンドの復元セッションでは、少なくとも一組のユーザ入力に応答するようにデバイスを操作できてもよい。

一実施形態では、２段階復元のうちのモーダルなセッションの間、デバイスをユーザに固有の作業状態にさせるためにデバイスがシステムリソースをダウンロードする間、デバイスが一時的に使用不可能であってもよい。例えば、システムリソースには、すべてのメタデータおよびシステムデータ、アカウントのリスト、壁紙、ＳＭＳ（ショートメッセージサービス）履歴、および／またはその他の適用可能なユーザ固有の、アプリケーション以外のデータが含まれていてもよい。システムデータとメタデータとが、例えば、ユーザの電話として動作するために、デバイスを構成してもよい。デバイスは、モーダルなセッションの後、リブートして復旧してもよい。

一実施形態では、２段階復元のうちのバックグラウンドセッションの間、デバイスが、（例えばＡｐｐｌｅ Ｉｎｃ．製のｉＴｕｎｅｓ（登録商標）を実行中の）ローカルコンピュータおよび／またはクラウドストレージからのデータまたはメディア資産を復元してもよい。デバイスは、バックグラウンドセッションの間、メールを同期させ、および／またはテキストメッセージを受信してもよい。一実施形態では、リソースは、利用パタンによって決められた復元順に従って復元されてもよい。例えば、アプリケーションの利用が把握されて、視聴されたショー／映画や、読まれた書籍やその他の適用可能な利用統計を含めて利用パタンが収集されてもよい。他の実施形態では、復元順は、リソース（またはコンテンツ）のサイズに依存してもよく、その場合、リソースに対応するアイコンが、デバイスのディスプレイ上に位置する（例えばユーザは、使用頻度の高いアイコンを最初のページに置くことがあるだろう）。あるいは、その他の適用可能な因子に依存してもよい。復元順は、ユーザ要求に適合して動的に更新されてもよく、例えば、ユーザがディスプレイ上をタップしてアプリケーションの優先度を示してもよい。

別の実施形態では、デバイスは使用可能であるがすべてのデータがまだ復元されてはいない場合に、デュアルフェーズの（すなわち２つに分けられた）復元におけるある時間帯の間、ＵＩ（ユーザインタフェース）要素が表示され、それによってユーザ体験を向上させて、アプリケーションが不正確に動作したり予期せぬかたちで動作したりするのを防いでよい。例えば、オブジェクトファイルまたはユーザデータがまだ復元されていない（例えば音楽、動画、その他のメディアコンテンツ／資産を再生するための）アプリケーションおよび／またはライブラリを示すアイコンが、灰色で薄く表示されたりプログレスバーを含んでいたりして、アプリケーションはまだ利用可能でないがまもなく利用可能になるであろうということを示してもよい。ユーザが復元を優先させたいアプリケーションや写真や音楽や動画のアイコンをユーザがタップできるようにすることによって、双方向性が付加されてもよい。

別の実施形態では、デバイス内のリソースの第１のバックアップソースへの変更を識別する方法および装置が、本明細書内で記述される。第１のバックアップソースから、第２のバックアップソースに対する許可のためのトークンを受信するのに応じて、リソースの変更が、トークンを使って第２のバックアップソースへバックアップされてもよい。第２のバックアップソースへの変更のバックアップが成功すると、リソースの変更が、第１のバックアップソースへコミットされてもよい。

別の実施形態では、メタデータが、デバイス内に記憶されたファイルの実際のコンテンツを記述するように維持される。メタデータは、ファイルを表現するための第１の抽象化層を表現してもよい。実際のコンテンツの一部分が、第１の抽象化層から識別されてもよい。一実施形態では、実際のコンテンツの一部分が、デバイスからバックアップされてもよい。コンテンツ識別子が、第１の抽象化層とは別の第２の抽象化層を表すため、実際のコンテンツの一部分について動的に生成されてもよい。実際のコンテンツの一部分が、コンテンツ識別子を介して、ネットワークアクセス可能なストレージにアップロードされてもよい。

本発明のその他の特徴は、添付の図面および以下の詳細記述から明らかになるであろう。

本発明を、添付の図面中の各図において、例として、かつ、限定することなく示しており、添付の図面中、類似の参照文字は、類似の要素を示す。

多段階多ソースのバックアップおよび復元のためのネットワークシステムの一実施形態を示すブロック図である。

多段階多ソースのバックアップおよび復元のための例示的なシステムを示すブロック図である。

複数のソースを用いる複数の段階におけるバックアップおよび復元を管理するための例示的なシステムを示すブロック図である。

デバイスのための増分バックアップ操作を行うプロセスの一実施形態を示すフロー図である。

デバイスにおける増分復元操作を行うプロセスの一実施形態を示すフロー図である。

デバイスを復元するためにリソースに動的に優先順序を付けるプロセスの一実施形態を示すフロー図である。

バックアップおよび／または復元操作のためにデバイスの電源を監視する例示的なシステムを示すブロック図である。

電力を節約するためにデバイスのバックアップおよび／または復元操作を中断するプロセスの一実施形態を示すフロー図である。

本明細書で記述する実施形態と共に用いられうるデータ処理システムの一例を示す図である。

本明細書で記述する実施形態と共に用いられうる典型的なコンピュータシステムの一例を示す図である。

デバイス用のファイルを１つ以上のソースを用いて複数の段階でバックアップして復元するための方法および装置を、本明細書に記述する。以下の記述では、本発明の実施形態の十分な説明を提供するために、多数の個別の詳細が述べられている。しかし、当業者には明らかであろうが、本発明の実施形態は、これらの個別の詳細がなくても実施されうる。その他の例では、本記述の理解をあいまいにしないようにするため、周知のコンポーネント、構造、技法は、詳細に示されていない。

明細書の中で「一実施形態」または「実施形態」と呼ぶのは、その実施形態に関連して記述された或る個別の特性、構造、または特徴が、本発明の少なくとも１つの実施形態に含まれうることを意味する。「一実施形態において」という句が本明細書の各所に現れるが、必ずしも、それらがすべて同一の実施形態のことを言っているのではない。

以下の各図に描かれたプロセスは、（例えば、回路機構、専用論理などの）ハードウェア、（例えば汎用コンピュータシステムまたは専用マシン上で実行されるもののような）ソフトウェア、またはそれら両方の組み合わせを含む処理論理によって行われる。各プロセスは、以下では、いくつかの順次的な操作という形で記述されているが、記述された一部の操作は、異なる順序で行われてもよいことは理解されるべきである。また、一部の操作は、順次的ではなく並行して行われてもよい。

一実施形態では、デバイスからのデータまたはリソースをバックアップするために、複数のソースが利用可能でありうる。例えば、一般的なデータバックアップサービスが、クラウド（すなわちクラウドストレージ、クラウドサービス）内で、例えばＡｍａｚｏｎ、Ｓ３、Ｍｉｃｒｏｓｏｆｔなどのようなサードパーティーベンダを介して提供されてもよい。例えば、歌、映画、および／またはアプリケーション等のような購入資産が、クラウド内のｉＴｕｎｅｓ（登録商標）ストアからダウンロードされてもよい。例えばｉＴｕｎｅｓ（登録商標）のようなバックアップサービスソフトウェアを実行するユーザのコンピュータを用いて、例えば、Ａｐｐｌｅ Ｉｎｃ．からのｉＯＳ（登録商標）デバイス、ｉＰｈｏｎｅ（登録商標）デバイス、ｉＰａｄ（登録商標）デバイスのようなデバイスがバックアップされてもよい。

デバイスからのバックアップされるべきリソースは、例えば、設定、アカウントデータ、アプリケーションデータ、写真、メディアファイル、購入資産、および／またはその他のデータファイルを含むバックアップデータでありうる。一実施形態では、バックアップデータは、デバイス内の既存のリソースから動的に識別されてもよい。ユーザコンピュータ（例えば、デスクトップコンピュータまたはノートブックコンピュータ）は、デバイス用のバックアップデータを記憶することができる。任意で、またはその代わりに、デバイス用のバックアップデータの部分集合が、バックアップデータ内の購入資産については、クラウドバックアップを介して、および／または、例えばｉＴｕｎｅｓ（登録商標）ストアのようなストアを介して、クラウド内に記憶されてもよい。

一実施形態では、例えばクラウド内でＭＢＳサーバによって維持されるアカウントを、そのアカウントについての多様なデバイスに個別的に対応する複数のバックアップ（またはバックアップ構造）を含む階層データによって表すことができる。階層データは、複数の異なるデバイスについての一組のバックアップを含むアカウントを含んでいてもよい。バックアップは、デバイス上のファイルの一組のスナップショットを含んでいてもよい。デバイス毎に１つというバックアップがサポートされてもよい。

スナップショットは、単一の時点でのデバイスの状態を表していてもよい。復元は、バックアップ内のいずれのスナップショットからも行うことができ、その時点でのデバイスの状態が再構築される。スナップショットは、或る番号（例えば１）から順次的に番号をつけられてもよく、これらの番号は、サーバによって割り当てられてもよい。第１のスナップショットは、デバイスの完全なバックアップであってもよく、その後のスナップショットは、前のスナップショットからの差分であってもよい。増分スナップショットは、前のスナップショット以来、デバイス上で追加され、修正され、削除されたファイルをすべて含んでいてもよい。

スナップショットは、そのコンテンツがアップロードされた後、明示的にコミットされてもよい。未コミットのスナップショットが一時に１つあってもよく、その未コミットのスナップショットは、最大の数を持つ最後のスナップショットでありうる。スナップショットがコミットされた後、そのコンテンツは、それを完全に削除することによる以外は、修正されないことがある。

スナップショットが削除された場合、そのコンテンツは、それが未コミットでない限り、前のスナップショットにマージされてもよい。結果として、復元は、依然として、いずれかのその後のスナップショットから行うことができる。目標スナップショットの中の追加／修正／削除されたファイルは、保持されうる（例えば、失われないであろう）。未コミットのスナップショットを削除してもマージは行われず、その代わり、コンテンツが単に廃棄されてもよい。一連の記憶されたスナップショットから第２のスナップショットを削除して、その一連のスナップショットのうちの第１のスナップショットにファイルをマージする場合、第１のスナップショットが完全であるため、削除されたファイルは保持されないことがある。第１のスナップショットは、それが一連のスナップショットの中の唯一のスナップショットでない限り、削除されないことがある。

個々のバックアップは、例えば、構成されたスケジュール（例えば、毎時、毎日、毎週など）に従って、対応するデバイスから取られたスナップショットを含んでいてもよい。個々のスナップショットは、ファイルまたはリソースのリストの記述を含んでいてもよい。個々のファイルは、クラウドサービスが記憶するための（例えば所定のビット数の）実データのチャンクに分割（すなわち、ファイルチャンキング）されてもよい。あるいは、ファイルチャンキングは、例えば、全体として参照により本願に援用する、２０１１年１月１４日に出願されたＤｏｍｉｎｉｃ Ｇｉａｍｐａｏｌｏによる「Ｃｏｎｔｅｎｔ Ｂａｓｅｄ Ｆｉｌｅ Ｃｈｕｎｋｉｎｇ」と題された仮特許出願第６１／４３３，１５２号に記述された、データ項目をチャンクに分割する技術に基づいていてもよい。

典型的には、複数のチャンクが、例えばサードパーティーベンダによって提供されるクラウドサービス用のストレージユニットとして、１つのコンテナとして統合されることがある。バックアップは、要求に応じて作成され、更新され、削除され、無効化され、操作されてもよい。例えば、所与の領域のファイルが、バックアップから削除されることがある。クラウドストレージは、クラウドストレージ内に記憶されたデータのチャンクに対応するオリジナルのファイルを再生するのに十分な情報を記憶していない。従って、ファイルは、本質的に、データチャンキングを介して保護される。データのチャンクの暗号化によって、クラウドストレージ内に記憶されたデータについて、さらなるレベルの保護が提供されてもよい。

一実施形態では、例えばｉＯＳデバイスのようなデバイスが、デバイスのリソースからバックアップデータを識別するために、クラウド内の（例えばＭＢＳサーバ内でホストされる）バックアップサービスを使ってバックアップ操作を開始してもよい。デバイスのバックアップステータスを記述するメタデータが、バックアップサービスの中に、例えば、デバイスに対応するバックアップ構造を介して、維持されてもよい。バックアップステータスは、デバイスについてすでにバックアップされているリソースの最新のスナップショットまたは最近の一連のスナップショットを含んでいてもよい。一実施形態では、メタデータは、デバイスのバックアップデータについてサードパーティーベンダを介してクラウドサービス内に記憶されたデータチャンクを参照してもよい。

バックアップ操作のためにデバイス内で識別されたバックアップデータまたはファイルが、クラウドストレージのために準備ができた実際のデータビットのチャンクへと分割されてもよい。一実施形態では、識別されたファイルについてバックアップするためにデータのチャンクを準備するために、デバイスのサービスフレームワークの中のＭＭＣＳコードが、クラウドの中のＭＭＣＳサーバと通信してもよい。例えば、バックアップデータが、一定のチャンク構成（例えば各チャンクについて固有のデータビットサイズ）に従って、複数のデータチャンクに分割されてもよい。

バックアップ用に識別されたファイルから準備された複数のデータチャンクのうちのどれがクラウド内で現在利用可能でなく、アップロードされる必要があるのかを、サービスフレームワークが判定してもよい。一部の実施形態では、サービスフレームワークが（例えばＭＭＣＳコードを介して）、例えばＳＨＡハッシングアルゴリズムまたはその他の適用可能なアルゴリズムを介して、ＭＭＣＳサーバ（またはサービス）用の識別子として各チャンクをハッシングして署名を入れて、識別されたチャンクがすでにクラウド内にバックアップされているのかどうかを判定してもよい。

一実施形態では、ファイルが、ＭＭＣＳへと参照されてもよい。デバイスが、任意の識別子をファイルに割り当ててもよい。デバイスは、識別子を用いて、ファイルに戻って参照してもよい。参照は、ファイルの参照されなかったデータチャンク（すなわちファイルチャンク）のゴミを収集するために、（例えばサーバによって）周期的にＭＭＣＳへとクロールされてもよい。

デバイス用のバックアップ操作は、クラウド内の複数のサービスと協調するために、例えば、セットアップ段階、スキャン段階、バックアップ段階、および／または、その他の適用可能な段階というように、複数の段階で行われてもよい。各段階は、バックアップ操作の効果を高め、および／または、性能を向上させるために、クラウドストレージの動的な構成を好機をねらって可能にするよう、操作の個別の抽象化層に対応していてもよい。

例えば、セットアップ段階の間、ＭＢＳサービスの中にデバイス用のバックアップ（すなわちバックアップ構造）が存在するかどうかが、判定されてもよい。ＭＢＳサービスの中にデバイス用のバックアップが存在しない場合、ＭＢＳサービスは、デバイス用の最初のメタデータを使ってバックアップを作成することを求められてもよい。一実施形態では、デバイスは、ＭＢＳサービスの中のデバイスに対応するバックアップのコピーを反映する、バックアップキャッシュを含んでいてもよい。バックアップキャッシュは、デバイス用に以前取られた１つ以上のスナップショットを含んでいてもよい。

一実施形態では、バックアップキャッシュは、必要に応じて（例えば、ＭＢＳサービスと交わされたメッセージによればバックアップキャッシュの中にキャッシュされているスナップショットが期限切れになった場合）ＭＢＳサービスと同期するように（例えば、ＭＢＳサービスに相談することによって）再構築されてもよい。任意で、またはそれに加えて、未コミットのスナップショットがデバイスの中に存在するかどうかが、セットアップ段階の間に判定されてもよい。未コミットのスナップショットは、ＭＢＳサービスの中に記憶された既存のスナップショットに対応していなくてもよいし、まだバックアップされていないリソースの記述を含んでいてもよい。未コミットのスナップショットが、セットアップ段階の間に作成されてもよい。

一実施形態では、例えばバックアップキャッシュが最新のものであることを確認することの一環として、未コミットのスナップショットが存在するかどうかを判定するために、デバイスが、ＭＢＳサービスにクエリを行ってもよい。デバイスは、バックアップ操作の間にそのファイルシステムをスキャンした後で、未コミットのスナップショットを作成してもよい。バックアップキャッシュは、例えば、ＭＢＳサービスおよびＭＭＣＳサービスへのバックアップが成功したものを反映するために、増分的に更新されてもよい。

スキャン段階の間、デバイスのファイルシステムがスキャンされて、例えば新規ファイル、削除されたファイル、修正されたファイルなどのようなファイルまたはリソース内の変更が見つけられてもよい。一実施形態では、スキャンされたファイルとバックアップキャッシュに記憶されたスナップショットとの間の比較を介して、変更が識別されてもよい。どのファイルがすでにバックアップされており、どのファイルがバックアップされる必要があるのかが、スキャン段階の間に把握されてもよい。

バックアップ段階では、実際のファイルバックアップ操作が行われてもよい。例えば、必要に応じて（例えば、利用可能な未コミットのスナップショットが存在しない場合）スナップショットが作成されてもよい。ＭＢＳサービスにおいて新規ファイル、修正ファイルおよび／または削除ファイルのエントリを作成するための要求が、ＭＢＳサービスへ送信されてもよい。クオータ認証またはクラウドストレージへのアクセス権がＭＢＳサービスから受信されて、ＭＭＣＳサービスにバックアップ要求を送信することが可能になってもよい。バックアップ要求は、バックアップすべきファイルまたはファイルの変更を記述するメタデータを含んでいてもよい。

要求されたバックアップは、デバイスのためにＭＭＣＳによって課されたバックアップストレージサイズの限度内にあることを示すために、認証トークンがＭＢＳサービスから受信されてもよい。認証トークンは、デバイスからストレージベンダへの一組の許可されたＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）要求について、ＭＭＣＳサービスへ送信されてもよい。ＭＭＣＳサービスは、ストレージベンダ（すなわちクラウドサービス）と対話して、デバイス用の許可キーを検索することができる。ファイルの変更（例えば、追加／削除／除去）は、許可キーを用いてクラウドサービスへアップロードされてもよい。アップロード成功の確認がクラウドサービスから受信されると、アップロードに対応するスナップショットが、デバイスとＭＢＳサービスとの間でコミットされてもよい。スナップショットは、それが作成され、そのコンテンツが定義され、次いでＭＭＣＳへアップロードされた後、コミットされてもよい。

一実施形態では、ＭＢＳサービスは、ファイルレベルでファイルを記述するメタデータに基づいていてもよい。ＭＭＣＳサービスは、ファイルの実際のコンテンツまたはデータ（例えばデータのチャンク）に依存してもよい。ファイルの実際のコンテンツから生成されたハッシュ署名が、コンテンツの識別子としてＭＭＣＳサービスで用いられてもよい。ＭＭＣＳサービスは、識別子によって識別されたコンテンツの部分が、例えばクラウドストレージ内で、新規なのか（あるいはまだバックアップされていないのか）どうかを判定してもよい。ＭＢＳサービスは、ファイルが新規であるのかまたは更新されたのかを、そのファイルに関連するメタデータに従って決定してもよい。

実施形態によっては、ＭＢＳサービスのようなバックアップサービスは、デバイス用の１つ以上のバックアップを維持することができる。バックアップは、バックアップされたデータまたはファイルは何なのか、バックアップされたデータをどのように把握するのか、対応するデバイスのＩＤ、（例えば、バックアップの日付、増分バックアップ関係性などに基づいて）異なるバックアップ同士がどのように関係しているのか、および／またはその他の情報を記述しているセマンティクスを含んでいてもよい。一実施形態では、バックアップが、１つのアカウントの下で１つのデバイスに関連付けられてもよい。個々のアカウントは、複数のデバイスを含むことができる。バックアップは、デバイスの複数のスナップショットを含むことができる。例えば、スナップショットは、デバイスのリソースについて毎日取られてもよい。個々のスナップショットは、バックアップの中の前のスナップショットからデバイス内で変更されたファイルを、記述してもよい。

一実施形態では、デバイスのリソースが、複数の方式によるハンドシェイクに基づいてバックアップされて、ＭＢＳサービス、ＭＭＣＳサービス、クラウドベンダ（すなわちストレージ）および／またはその他の適用可能なサービスのようなサービスとデバイスとの間で、ファイルおよび／またはファイルのメタデータが送信されてもよい。ＭＢＳサービスは、ＭＭＣＳサービスの参照を把握してもよい。ＭＭＣＳサービスは、例えば、デバイスがファイルをベンダによって指定された構造化されたデータに動的にマッピングできるようにするため、クラウドベンダの参照を把握してもよい。

例示する一実施形態では、特定のクラウドベンダに従って、ＭＭＣＳサービスは、デバイス内のファイルを項目として識別し、項目をデータのチャンクに分割するようにデバイスに命令し、データの個々のチャンクについて一意の識別子を生成し、識別されたデータのチャンクをバックアップ用にデバイスがクラウドベンダへ転送する必要があるかどうかをデバイスに通知してもよい。デバイスは、ＭＢＳに命令するかまたはＭＢＳと通信して、デバイスのために取られたスナップショットの中に情報を入れ、および／または、スナップショットをデバイスに整合させてもよい。

従って、複数のサービスが、デバイスのリソースをバックアップするための間接化の層を提供して、１つの層の範囲内の操作を他の層に影響しないように分離してもよい。ＭＢＳサービスは、バックアップすべきリソースのメタデータを把握して、どのファイル（すなわち項目）が、バックアップすることを必要とせず、すでに存在していたかを判定してもよい。ＭＭＣＳサービスは、実際のバックアップデータをクラウドストレージのどのベンダに記憶するかを把握し、デバイスがバックアップデータをクラウドストレージへアップロードできるようにするためのチケット（または証明書）を作成するためにクラウドストレージの利用権を管理し、および／または、ゴミ収集（ガベージコレクション）を行ってバックアップ用にもう参照されなくなったデータのチャンクを表す構造を削除することに責任を持ってもよい。ＭＢＳサービスは、ＭＭＣＳサービスによって管理されるクラウドストレージからは孤立して（またはそれに気づかなくて）もよい。

一実施形態では、バックアップ操作用に生成されたスナップショットは、バックアップ操作が成功して完了された後にスナップショットがコミットされるまでは、整合しているとマークされなくてもよい。（例えば、３日間の日常的なスナップショットに相当する）決まった（すなわち構成された）数の最近のスナップショットが、デバイス内にキャッシュされるかまたはＭＢＳサービス内に記憶されてもよい。スナップショットの数は、ストレージスペースを節約するために、制限されてもよい。典型的には、記憶されるスナップショットのうち最初の（すなわち最も古い）ものは、対応するバックアップ操作についてデバイスの各リソースを記述する完全スナップショットであってもよい。残りのスナップショットは、前のスナップショットに対するリソースの追加変更を記述する増分スナップショットであってもよい。

バックアップ操作の最終段階の間、一実施形態では、スナップショットがマージされてもよく、例えば、最も古い２つ以上の既存のスナップショットを１つの完全スナップショットへと折りたたんでもよい。結果として、新規のスナップショットがコミットされる時、記憶されるスナップショットの総数が固定数として維持されてもよい。一部の実施形態では、ＭＢＳサービスは、１つのアトミックなデータベース操作として既存のスナップショットを削除および／またはマージするように通知（または命令）されてもよい。それに応じて、アトミックな操作が成功したか否かを示すために、ＭＢＳサービスから確認応答が受信されてもよい。

実施形態によっては、再ダウンロードできない可能性があるリソース（例えば、アプリケーション、購入資産、またはその他の資産）のリストを識別するために、ｉＴｕｎｅｓ（登録商標）ストアのようなバックアップソースに、クエリが行われてもよい。例えば、（例えばデバイスからの要求に基づいて）デバイスに関連付けられたどの購入資産が再ダウンロードできないのかを、デバイスがコンテンツバックアップ操作を行う前に、バックアップソースが判定してもよい。バックアップソースから再ダウンロードできないリソースのリストにある実際のコンテンツは、ＭＢＳ、ＭＭＣＳ等のバックアップサービスを介してアーカイブまたはバックアップされてもよい。

一実施形態では、デバイスとＭＢＳサービスとの間の通信は、バックアップ（例えば作成／削除）およびスナップショット（例えば作成／削除／マージ／更新）を管理するためのクライアントサーバプロトコルを規定する。スナップショットの更新は、アトミックに行われてもよく、すなわち、スナップショットへのすべての変更が組み込まれる（すなわちコミットされる）かまたはスナップショットがまったく更新されないかのいずれかである。

一部の実施形態では、ＭＢＳサービスを介してスナップショットを管理するプロトコルは、効率的で軽量なネットワーク通信のため、ファイルまたはリソースのメタデータに基づいていてもよい。メタデータは、ファイルの実際のコンテンツを記述することなく、デバイス内のファイルについての情報、例えばファイル名、ファイルへの参照、サイズ、タイムスタンプ、所有権、保護設定、その他のファイルに関連する適用可能なデータ等を記述してもよい。どのファイルまたは資産をバックアップ操作に含める必要があるのかが、メタデータの記述に基づいて判定されてもよい。個別のスナップショット間の差分すなわち相違が、メタデータ記述に関して把握されてもよい。

例えば、デバイスが、最後に修正された時刻値を用いてキャッシュを維持することがありうる。リソースに対してアクセス、削除、更新、修正またはその他の操作を実行するため、要求および応答には最後に修正された時刻値が含まれていてもよい。一実施形態では、リソースに関する要求は、リソースの親リソースの最後に修正された時刻値を更新することをもたらすことがある。例えば、アカウントのバックアップを削除することは、アカウントの最後に修正された時刻値を更新することになりうる。スナップショットにファイルを追加することは、スナップショットの最後に修正された時刻値だけでなくスナップショットの親のバックアップおよびアカウントも更新することになりうる。

スナップショットを管理するための要求によって、新規の空の未コミットのスナップショットを作成することと、前に作成されたスナップショットを更新することと、スナップショットを削除することと、および／または、スナップショットをコミットすることとが可能になりうる。要求されたスナップショットのためにスペースを予約することが、関連のアカウントのクオータを超過することにつながりそうな場合、応答が、ストレージ不足を示してもよい。要求は、デバイス名やバージョン番号のようなスナップショットの属性を含んでいてもよい。

別の実施形態では、属性を持つファイルのリストが、要求を介してスナップショットから検索されてもよい。ＭＭＣＳからファイルのストリームをダウンロードするために、ＭＭＣＳ許可トークンが要求されてもよい。スナップショット用のファイルを管理することへの要求には、例えば、作成すること、削除すること、更新すること、マークすること、またはその他の適用可能な操作が含まれていてもよい。スナップショット内のファイルのサイズが予約されているスペースを超過しそうな場合、応答がコンフリクトを示してもよい。一部の実施形態では、ファイルをスナップショットから削除すると、サーバによって記憶されている元のデータベースレコードが削除されることがあり、削除されたファイルは、スナップショット用のファイルのリストにその後現れないことがある。あるいは、ファイルが削除されたという印を付けることによって、ファイルは以前のスナップショットには存在していたが、もうデバイス内には存在しないことを示してもよい。

デバイス内のファイルのメタデータは、例えばＭＢＳサービスを介してどのファイルをバックアップすべきかを判定するための、および／または、バックアップ操作用のスナップショットを作成するための、抽象化の１つのレベルに対応していてもよい。実際のファイルコンテンツのハッシュ（例えば、ハッシュチャンクが少しずつ）が、別のレベルの抽象化を提供し、バックアップファイルのうちのどのコンテンツがアップロードされる必要があるのかが、例えばＭＭＣＳサービスを介して、識別されてもよい。一実施形態では、同一コンテンツの別個のファイルが、異なるメタデータ記述に関連付けられてもよい。従って、コンテンツのハッシュまたはチャンク署名に基づく比較によって、同一コンテンツであるが異なるメタデータを持つファイルのための、（例えばクラウドからの）バックアップストレージの共有ができてもよい。

バックアップ操作は、再開されるか、および／または、切り換えられてもよい。例えば、ネットワーク接続が失われた場合、バックアップ操作が停止されることがある。バックアップ操作は、ネットワーク接続が再度確立された場合、再開されてもよい。一実施形態では、再開されたバックアップ操作についてどのファイルをバックアップするのかが、ファイルコンテンツから（例えばＭＭＣＳサービスを介して）生成された署名に基づいて判定されてもよい。バックアップ操作が停止される前にファイルシステム内のファイルが変更された場合、ファイルシステムは、バックアップ操作を再開（または開始）する前に再度スキャンされてもよい。一部の実施形態では、最適化のために、ファイルが変更されたかどうかを判定するためにＭＭＣＳサービスに相談する前に、ファイルシステムをスキャンしている間、ファイルの修正タイムスタンプ（または時刻値）が、バックアップキャッシュの中の対応するタイムスタンプと比較されてもよい。

デバイスとソースすなわちホストとの間のバックアップ／復元操作は、デバイス上のデバイスアンカーおよびホスト上のホストアンカーのような同期アンカー技術に基づいて、停止（または終了）されて再開されてもよい。同期アンカー技術の例は、Ｇｏｒｄｏｎ Ｊ．Ｆｒｅｅｄｍａｎによる「Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｍｅｔｈｏｄｓ ａｎｄ Ｓｙｓｔｅｍｓ」と題された発行済の米国特許第７，８０７，４０３号に記述されており、それを全体として参照により本願に援用する。

一実施形態では、リソースが、動的に構成される複数のソースからデバイスへ分割復元されてもよい。例えば、アプリケーション、音楽、動画、ＴＶショー、その他のメディアデータのような購入資産が、要求に応じてクラウド内の１つ以上のストアからデバイスへダウンロードされてもよい。購入資産は、（例えば、デバイスのユーザが所有する）ローカルコンピュータに記憶され、デバイスにも同様に復元される準備が整ってもよい。

一実施形態では、ローカルコンピュータに近い範囲内で移動している時にデバイスが購入資産をクラウド（例えばストア）から復元している間に、デバイスとローカルコンピュータとの間で接続（例えば有線接続または無線接続）が確立されてもよい。接続とローカルコンピュータ内での購入資産の利用可能性とを検出した時点で、デバイスは、購入資産の復元ソースをクラウドからローカルコンピュータへと動的に切り換えて、（例えば、ローカルコンピュータにおいてホストされているｉＴｕｎｅｓ（登録商標）ソフトウェアを介して）購入資産の残りの部分の復元を完了させてもよい。結果として、ネットワーク接続コストを削減して、復元性能を高めることができる。

一部の実施形態では、ストア、ローカルコンピュータ、クラウドストレージといった複数のソースからのデバイスのリソースの利用可能性が、リソースのメタデータに基づいて把握されてもよい。或る個別のリソースがストアまたはローカルコンピュータの中にすでに存在する場合、その個別のリソースは、既存のソースからデバイスへ復元されうるため、その個別のリソースの実際のコンテンツをバックアップする必要はない。例えば、リソースのメタデータが、デバイスに関連するアカウントについて購入資産の所有権を示してもよい。購入資産は、クラウドからのストアおよび／またはローカルコンピュータのような利用可能なソースからすぐに利用可能となりうる。結果として、購入されたリソースは、利用可能なソースから再ロードされうるため、バックアップする必要はない。

一実施形態では、設定、アカウントデータ、アプリケーションデータ、および／または購入資産のようなデバイス内のリソースが、ローカルコンピュータへバックアップされてもよい。また、設定、および／または、アプリケーションデータのようなリソースの部分が、クラウドストレージへバックアップされてもよい。購入資産のような一部のリソースが、クラウド内のストアの中に維持されて利用可能であってもよい。リソースは、利用可能な場合にはローカルコンピュータから復元されてもよいし、ローカルコンピュータがデバイスに接続されていない場合あるいはリソースをローカルコンピュータ内に位置させることができない場合には、クラウドストレージおよび／またはストアから復元されてもよい。電子メール、カレンダ、またはその他の適用可能なリソースのような、中央サービスとの同期操作を介して同期されうる一定の資産は、バックアップ操作によってバックアップされなくてもよい。

実施形態によっては、ＭＢＳサービスのようなメタデータサービスが、バックアップ操作用に許可トークンをデバイスに提供する場合、デバイス内のどのリソースをバックアップすることが可能かを選択してもよい。例えば、サードパーティーアプリケーションおよび／またはデータによっては、フィルタで除去されて、バックアップされることが許可されないことがある。一実施形態では、バックアップからフィルタで除去されるデータには、キャッシュされたデータまたは再生成されうるインデックスのような、サードパーティーアプリケーションによってバックアップされる必要なしと宣言されたディレクトリや文書が含まれることがある。あるいは、デバイスの関連のアカウントについて課される、バックアップデータのトータルなサイズに関するクオータ制限に従って、バックアップすべきリソースが識別されてもよい。

一実施形態では、デバイスについてのすべてのリソースが復元されたかどうか（すなわち、復元操作が完了したのかどうか）が、異なるリソースまたは或る特定のリソースのうちの異なる部分がそれらから復元されうる複数のソース（例えばクラウドストア、ローカルコンピュータ、ストアなど）に対して、把握されてもよい。例えば、デバイスと通信しているローカルコンピュータ内で実行中のｉＴｕｎｅｓ（登録商標）が、クラウド内には記憶されているがローカルコンピュータ内には記憶されていない或る個別のリソースがまだデバイスへ復元されていないと判定してもよい。その個別のリソースは、デバイスが復元操作を完了させるために、ローカルコンピュータを介して検索されてもよい。

例として、ユーザに関連するアカウントについてアクティベートされている新しいデバイス、例えば新しい電話が、アカウントのクラウドバックアップから復元されてもよい。デバイスは、アカウントとデバイスとを識別する識別子を持つＭＢＳサービスのようなバックアップサービスを使って復元操作を開始してもよい。従って、復元すべきリソースの記述が、例えばＭＢＳサービスを使って、判定されてもよい。クラウドストレージは、判定されたリソースを復元するように、（例えば、動的に発見されるかまたは接続されたサービスから得られるなどした構成を介して）位置を突き止められてもよい。あるいは、ｉＴｕｎｅｓ（登録商標）のような対応するバックアップ・サービス・アプリケーションを実行中のローカルコンピュータが利用可能である（例えばデバイスの接続範囲内にある）と分かった場合、リソースは、リモートのクラウドストレージにアクセスすることを必要とせず、ローカルコンピュータから検索されてもよい。

デバイスにおける復元操作は、例えば、モーダルな復元段階に続くバックグラウンドの復元段階を含めて、複数の段階で行われてもよい。設定やメタデータのような不可欠なファイルや情報は、最初にモーダルな復元段階の間にアトミックに（例えば、すべての不可欠なファイルが復元されるか、あるいは何も復元されないかのいずれか）復元されて、デバイスが作業状態へとブートでき、復元操作の残りの完了を待つことを必要とせず、ユーザが迅速に利用できるようにされてもよい。モーダルな復元段階の間、デバイスは、システムファイルを記録中であって、ユーザ入力を受け付けるように操作できないことがある。アトミックな復元によって、リソースが完全に復元される前であっても、整合性のある一組のデータを使ってデバイスが実行されることが保証されてもよい。

続いて、バックグラウンドの復元段階の間、デバイスを復元するのに必要な残りのリソースが、クラウドストレージおよび／またはローカルコンピュータのような利用可能なバックアップソースからバックグラウンドの中にプルされてもよい。例えば、メディア資産の実際のコンテンツ（例えば写真、動画、音声ファイルなど）、サードパーティーアプリケーションデータ、またはその他の適用可能なリソースのようなかなり大きなリソースが、デバイスの操作または少なくとも一部の機能を用いるユーザの能力あるいはデバイスの機能性に影響を及ぼすことなく、バックグラウンドの復元段階の間にプルされてもよい。例えば、バックグラウンドの復元段階においてユーザが、テキストメッセージを送信するかまたはインターネットを閲覧するかまたは音声電話をすることができてもよい。

一実施形態では、デバイスが、ローカルコンピュータ（例えば、ｉＴｕｎｅｓ（登録商標）アプリケーションを実行するｉＴｕｎｅｓ（登録商標）コンピュータ）を使って（例えば同期操作を介して）同期されて、デバイス上の所定のコンテンツまたはリソース（例えば音楽、アプリケーション、ｐｏｄｃａｓｔ、動画、着信音、写真、メモ、電子メールアカウント設定、連絡先、カレンダ、ブックマーク）が、ローカルコンピュータ内の対応するリソースのうちのユーザの選択した部分集合に一致することが保証されてもよい。アプリケーションデータは、同期された場合、デバイスからローカルコンピュータ（例えば、ｉＴｕｎｅｓ（登録商標）バックアップ内）へバックアップされてもよい。アプリケーションやメディアコンテンツのような購入資産は、ローカルコンピュータからデバイスへダウンロードされて（例えばｉＴｕｎｅｓ（登録商標）ライブラリを介して）同期されてもよい。

一実施形態では、デバイスとローカルコンピュータとの間の同期操作が、デバイスのバックグラウンドの復元（段階）の間に（またはその後に）行われてもよい。デバイスとｉＴｕｎｅｓ（登録商標）コンピュータとの間の通信または接続は、デバイスがまだ作業状態へとブートされていないため、バックグラウンドの復元の前には利用可能でないことがある。同期操作は、（例えば、ｉＴｕｎｅｓ（登録商標）ライブラリとして）ローカルコンピュータからデバイスへ資産（例えば購入されたメディアおよび／またはアプリケーション）を復元することができることがある。

任意で、またはそれに加えて、同期操作は、アプリケーションデータまたはユーザデータを（例えばｉＴｕｎｅｓ（登録商標）バックアップとして）ローカルコンピュータからデバイスへ復元してもよい。一実施形態では、同期操作は、デバイスがそれと同期するためのリソースのリストを識別するため、ｉＴｕｎｅｓ（登録商標）コンピュータとデバイスとの間の比較を含んでいてもよい。復元操作および同期操作は、デバイス内で実行中のＡＴＣ（Ａｉｒ Ｔｒａｆｆｉｃ Ｃｏｎｔｒｏｌｌｅｒ）コードのような共通モジュールに依存して、適用可能なソースから実際のコンテンツまたはビットデータをプルしてもよい。同期操作および／または復元操作のためにｉＴｕｎｅｓ（登録商標）デバイスからリソースを転送する目的でデバイスがｉＴｕｎｅｓ（登録商標）デバイスと結合すなわち接続された時、ＡＴＣは、ｉＴｕｎｅｓ（登録商標）同期（またはペアリング）イベントのようなシステムイベントに自動的に気付いてもよい。

一実施形態では、デバイス内の復元操作は、接続されたバックアップサービス（例えばｉＴｕｎｅｓ（登録商標）コンピュータまたはＭＢＳサービス）に問い合わせて、リソースを復元するための最も良いソースを判定してもよい。別個のリソースまたは資産について、クラウド内のバックアップストレージ（すなわちクラウドバックアップ）、ローカルコンピュータ内のバックアップ（例えばｉＴｕｎｅｓ（登録商標）バックアップ）、クラウド内のストア（例えばｉＴｕｎｅｓ（登録商標）ストア）、ローカルコンピュータ内のローカルライブラリ（例えばｉＴｕｎｅｓ（登録商標）ライブラリ）といった多様なソースが識別されることがある。１つのカテゴリのデータが１つのソースから復元されている間に、別のカテゴリのデータが別のソースから復元されてもよい。例えば、写真はクラウドストレージから、音楽コンテンツはストアから、アプリケーションはローカルライブラリから、アプリケーションデータはクラウドストレージからというように復元されてもよい。典型的には、例えば、接続コストがより安価であること、および／または、利用可能なネットワーク帯域幅がより高いことなどの理由で、ローカルコンピュータ内のソースの方が、クラウドからのソースより好適でありうる。

一部の実施形態では、同期操作は、トランザクション段階とその後のベストエフォート段階というように、複数の段階で行われてもよい。トランザクション段階の間に、メタデータが識別されて、デバイスとローカルコンピュータとの間で同期すべきリソースのリストが記述されてもよい。メタデータは、（例えば全か無かの）トランザクションの形でローカルコンピュータから受信されてもよい。ベストエフォート段階の間に、メタデータによって記述された資産が、例えば、利用可能性、性能、コスト、および／またはその他の適用可能な因子を考慮して動的に判定された多様なソースから、デバイスに同期されてもよい。

実施形態によっては、リソースを復元するための多様なソースが、例えば、リソースに関連付けられたメタデータに基づいて、動的に識別されてもよい。同期操作は、デバイスとの同期が必要なリソースのリストの記述を、ローカルに結合または接続されたコンピュータ（例えばｉＴｕｎｅｓ（登録商標）コンピュータ）からプッシュしてもよい。歌、動画、映画、アプリケーションなどのような購入資産は、クラウド内のストアまたはローカルコンピュータから（例えば、ｉＴｕｎｅｓ（登録商標）ライブラリを介して）転送されてもよい。ユーザが撮影した写真または他のデバイスからダウンロードされた動画のような、ストアから購入または取得されていないメディアは、クラウドストレージまたはローカルコンピュータから（例えばｉＴｕｎｅｓ（登録商標）バックアップを介して）復元されてもよい。

復元順序の動的構成が多段階復元の後半で（例えば、第１の段階すなわちモーダルな段階の後で）適用されることは、デバイスの効率および／または有用性を向上させるために有利でありうる。例えば、復元用のリソースまたは資産のリストは、復元の開始（すなわち第１）段階で識別されてもよい。実際のデータ転送のためのバックグラウンド段階のような復元の後半では、動的にすぐさま行われる順序または優先度の判定に続いて、識別されたリソースのうちのどれを次に復元するのかの選択が行われることがある。例えば複数のスレッドまたはプロセスを介して、複数のリソースが、その復元のために同時に転送されることがある。

デバイスの作業ステータス、および／または、まだ復元されていないかまたは復元中のリソースについて構成される各種のヒューリスティックな基準に依存して、次に転送すべきリソースを選択する順序が、ランタイムの間に変更されてもよい。例えば、より小さいサイズのリソース、および／または、転送に必要な時間がより少ない（例えば、関連のソースについてより高い帯域幅が利用可能な）リソースが、（例えば、復元すべき次のリソースとして選択される確率が高い）より高いランクを与えられてもよい。

一実施形態では、デバイスの有用性を高める目的でリソースが復元についてどのように順序付けられるべきかまたは優先されるべきかを判定するために、デバイスの利用が把握されてもよい。例えば、リソースは、関連のアプリケーションに従って順序付けられてもよい。実施形態によっては、直近に用いられたアプリケーションのリソースに、より以前に用いられたアプリケーションのリソースより高い優先度が割り当てられてもよい。アプリケーションに関連するアプリケーションデータがまもなくユーザによってアクセスされうることを予想する際に、現在用いられているアプリケーション（例えば、再生中の映画または動画）が、直近に用いられたアプリケーションとして識別されてもよい。

一部の実施形態では、復元すべきリソースは、リソースに関連するアイコンの表示順に従って優先されてもよい。例えば、リソースに関連するアプリケーションアイコンおよび／またはメディアアイコンが、表示順に従ってデバイスのディスプレイ上に提示されてもよい。表示順は、デバイスのユーザによって暗示的に指定される優先度を反映していてもよい。任意で、またはそれに加えて、リソースがどのように転送されるべきかを動的に制御する（例えば、一時停止、再起動、起動など）ために、ユーザ入力（例えば表示画面をタップすること）が、受信されてもよい。

一実施形態では、復元すべきリソースのリストが、ヒューリスティックに構成された特性、および／または、動的に識別された因子に基づいて割り当てられた順序を使って構築されてもよい。特性は、サイズ、タイプ、位置、および／またはその他のリソースに関連する適用可能なメタデータのような、リソースに関する基準的情報を含んでいてもよい。例えば、購入資産タイプのリソースは、ユーザが作成したコンテンツのタイプである別のリソースより、復元の優先度が高くてもよい。リソースの位置は、リソースがデバイス用にどこで生成または購入されたかを示していてもよい。デバイスの現在位置により近い位置に関連するリソースが、デバイスから離れた別の位置を持つ別のリソースより高い優先度であってもよい。

動的因子は、デバイス内の絶えず変化する作業環境または利用パタンに基づいて、すぐさま判定されてよい。例えば、動的因子には、利用可能な（復元）ソース（例えば、クラウドストレージ、ストア、ローカルコンピュータなど）、アプリケーションの利用履歴、アプリケーションアイコンに関連する表示順序、ユーザ入力、その他の適用可能な因子が含まれうる。典型的には、利用可能なソースから転送されうるリソースは、現在利用可能なソースからは見つからない別のリソースより優先度が高いことがある。リソースの利用履歴には、例えば、頻度、最後にリソースが（例えば、アプリケーションを介して）アクセスされた時刻、利用回数、および／または、その他の利用統計値が含まれてもよい。使用頻度が高いリソースには、より高いランクが付けられてもよい。

一実施形態では、復元すべきリソースの初期リストが、多段階復元の第１の段階（例えばモーダルな段階）の間に構築されてもよい。ヒューリスティックに判定された特性および／または動的因子は、例えば、各リソースについて別個に合成されたヒューリスティックな重みに従って、リソースのリスト間の復元順序を判定するように割り当てられて合成されたヒューリスティックな重みとして表されてもよい。復元の後半の段階の間、最高の重みを持つリソースが、次にダウンロードするために選択されてもよい。

例えば、復元すべきリソースの順序付けられたリストが、少なくとも１つの復元ソース（例えば、クラウドストレージ、ストア、およびｉＴｕｎｅｓ（登録商標）コンピュータ）からリソースを復元することのできる復元プロセスへ転送されてもよい。復元プロセスは、復元のステータスを把握し、環境（例えばネットワーク接続、電源ステータス）の変化を監視し、ユーザ入力を検出するなどして、復元用のリソースの順序を変更してもよい。復元は、（例えば、ユーザ入力および／または環境の変化を介して）中断され、新たな順序を持つリソースの新規リストが再構築されて、新規に構築されたリストを使って再開されてもよい。

一実施形態では、（例えば、ｉＴｕｎｅｓ（登録商標）コンピュータ、またはクラウドストレージなどの）或る個別のソースからの復元すべきリソースの待ち行列が、復元用に識別されたリソースの現在の順序付けられたリストに従って維持されてもよい。異なるソースには、別個の待ち行列が維持されてもよい。一部の実施形態では、リソースのリストは、ランタイムの間に（例えば、ユーザの中断、選択、および／またはその他のシステムイベントなどに起因して）動的に構築されるため、個々の待ち行列が、リソースの新たに構築されたリストに従って（例えば、或る個別のリソースを待ち行列のトップに移動させることによって）更新され、復元が継続されてもよい。

一部の実施形態では、リソースがデバイスを介してどのように用いられているかに従って、リソースの実際のコンテンツが協調的な形で復元されてもよい。例えば、リソースは、デバイスを復元する時にアプリケーションにすぐにアクセスできるようにするため、アプリケーションの周りにサンドボックスされてもよい。アプリケーションプログラムおよび関連のアプリケーションデータ（または設定）は、一緒に復元されるようにサンドボックスされてもよい。

実行可能なプログラム、ライブラリ、アプリケーションの設定、アプリケーションデータ（すなわち、アプリケーションを介してユーザが作成した文書のようなユーザデータ）などのような、アプリケーション用のリソースの依存関係は、これらのリソースをデバイスへ復元する順序を識別するために、サンドボックス内に維持されてもよい。アプリケーションは、たとえすべてのサンドボックスされたリソースが復元される前であっても、デバイスのユーザが利用できるようにされてもよい。例えば、音楽再生アプリケーションを実行するには、音楽コンテンツファイルがデバイスへ転送される前に、プレーヤの設定が復元されることが必要でありうる。

一実施形態では、多段階復元は、ユーザインタフェースと協調して、復元の間に（例えば、デバイスが完全に復元される前に）ユーザがデバイスと対話できるようにしてもよい。復元の個々の段階についてのライブアップデートのステータスまたは進行状況について、プレースホルダが表示されてもよい。リソースの実際の転送は、ユーザインタフェースを介して受信された入力に従って動的に順序付けられてもよい。

例えば、アプリケーション（例えば、写真ビューワ、動画プレーヤ、音楽プレーヤなど）および関連のアプリケーション設定は、対応するアプリケーションアイコンをユーザインタフェース上に表示して、アプリケーションが利用可能であることを示すように復元されてもよい。アプリケーションとユーザとの対話（例えば、写真を見ること）を検出した場合、関連のアプリケーションデータ（例えば写真）に関係するリソースにより高い優先度が割り当てられて、復元順序が動的に変更されてもよい。

一実施形態では、デバイスが復元されている時、アプリケーションの復元状態が、アプリケーションによって把握されてもよい。アプリケーションの復元状態は、例えば、「スピナ」タイプのユーザインタフェース要素か、例えば温度計スタイルの進捗インジケータのような表現か、あるいはその他の適用可能なユーザインタフェース要素を介して、提示されてもよい。アプリケーション用の資産は利用可能か否かが、ユーザインタフェースを介して示されてもよい。

実施形態によっては、復元状態を提示するユーザインタフェース要素は、復元の全体的速度に影響する因子の組み合わせに基づく複合進捗インジケータを含んでいてもよい。各因子は、例えば、アプリケーションのサイズ、アプリケーションのソースからのアプリケーションのダウンロード速度、ユーザデータのサイズ、ユーザデータのソースからのユーザデータのダウンロード速度、インストール時間、メディアコンテンツ（例えば、音楽、暗号化されたデータなど）の解読時間、および／またはその他の適用可能な因子に従って演算されてもよい。複合進捗インジケータは、例えば、メディアタイプおよび／または文脈（例えば、スプリングボードの文脈、ｉＰｏｄ（登録商標）アプリケーションなど）に依存して、直感的な一意の温度計スタイルのインジケータか、円グラフスタイルのインジケータか、またはその他の適用可能なユーザインタフェーススタイルのインジケータとして提示または表示されてもよい。

一部の実施形態では、多様なユーザインタフェースコンポーネント／機能が、復元の状態に依存して提示（またはイネーブル）されてもよい。例えば、（例えば復元の第１の段階で）復元するように識別されたがまだ復元されていない資産は、灰色で表示されて、例えば、その資産のアプリケーションをユーザが起動できないようにされてもよい。しかし、順序付け、名前の変更、および／または削除のような所定のユーザインタフェース操作は、まだ復元されていない資産についても可能であってもよい。一部の実施形態では、復元の状態には、資産の利用可能性や利用不可能性が含まれていてもよい。ソース（例えば、ｉＴｕｎｅｓ（登録商標）ストア、資産ストア、またはその他の適用可能なストレージ）から復元すべき資産が、現時点で利用可能でない、例えばソース内に存在していない、および／または、不正なアクセス認証情報（例えば、資産のメタデータの中に含まれているパスワード）に関連しているのかどうかを、ソースインタフェースモジュールが判定してもよい。

一実施形態では、復元するように識別されたリソースまたは資産のリストが、例えば、同期操作と復元操作との両方のためにＡＴＣモジュールまたは共通モジュールの中に維持されて、復元順序および／または復元の進捗報告を動的に変更してもよい。アプリケーションは、プラグインモジュール（例えばライブラリ）および／またはＡＰＩ（アプリケーションプログラミングインタフェース）を介して復元の進捗にアクセスしてもよい。従って、アプリケーションは、ユーザインタフェース操作を介して、例えばアイコンを灰色で表示し、アイコンを回転させ、進捗バーを動かし、あるいはその他の適用可能なユーザインタフェースを変化させるなどして、復元の進捗のライブアップデートを提供することができる。例えば、ユーザインタフェースが、アプリケーションの復元の進捗を提示して、このアプリケーションについては資産の２０％またはその他のパーセンテージがすでに復元されたことを示してもよい。

アプリケーションが、バックグラウンド段階において作業中の復元操作を中断または変更してもよい。例えば、ユーザが、ストアから購入したメディア資産（例えば歌または動画）用のアプリケーションをタップしてもよい。それに応じて、アプリケーションが、例えばＡＴＣモジュールを介しての資産転送の優先順序の付け直しを、例えばプラグインモジュールまたはＡＰＩを介して要求してもよい。クラウド内の資産ストアのソースインタフェースモジュール（例えばｉｔｕｎｅｓｔｏｒｅｄ）は、ユーザにタップされたメディア資産を、復元または転送を再開するための関連の待ち行列のトップに置くように命令されてもよい。

一実施形態では、バックアップ操作の間、デバイスが電源の状態を監視して、ロバストなユーザ体験を維持してもよい。電源の変化に関係するシステムイベントを検出した時点で、デバイスは、（例えば、バックグラウンド内の）プロセスを終了させるかキャンセルし、ユーザに気付かれずに透過的な形でリソースをバックアップ（または復元）してもよい。システムイベントは、例えば、デバイスへの電源コード、非接触充電パッド、またはその他の給電メカニズムのプラグが抜かれたり、切断されたりすることによって生じることがある。

一部の実施形態では、デバイスが十分な電力を持つ電源にプラグを差し込まれているかどうかを監視することに基づいて（例えば、電源が十分な電力を持たない場合にはバックアップを中止するため）イベントが生成されてもよい。あるいは、または任意で、イベントは、デバイス内の画面がオンかオフか、および／または、デバイスのネットワーク接続のステータスに基づいていてもよい。例えば、画面が（例えばどのような理由であれ）オンにされると、デバイスの自動バックアップがキャンセルされて、ユーザインタフェースの性能に影響を与えることが回避されてもよい。デバイスがもうＷｉＦｉネットワークに接続されていないことをイベントが示す場合、例えば、自動バックアップが中止されて、セルラー電話ネットワークを介してセルラーデータを使用することが回避されてもよい。

一部の実施形態では、バックアップ／復元を続けるか否かをユーザが選択するための選択肢を提供するために、警告が発せられてもよい。デバイスは、作業状態で電源投入されたまま維持され、例えば、ユーザに知られないままバックグラウンドでのバックアップ／復元操作に起因する電力の浪費をすることなく、バッテリ電力を節約してもよい。

一実施形態では、例えば、外部電力線にまたプラグを差し込まれた時にバックアップ／復元操作を再開できるようにするため、バックアップ／復元状態がデバイス内で維持されてもよい。バックアップ操作は再開され、デバイスが再スキャンされて、どのリソースがバックアップされたのかが識別され、例えば外部電力線のプラグが抜かれた時より前にすでにバックアップされていたリソースに関して不要なバックアップ操作が行われないようにされてもよい。

図１は、本明細書で記述される一実施形態による多段階多ソースのバックアップおよび復元のためのネットワークシステムの一実施形態を示すブロック図である。ネットワークシステム１００は、サービス１０１、１０３、１０５、１０７、１１７およびデバイス１１１、１１３を接続する、動的に構成されたネットワーク１０９を含んでいてもよい。例えば、電話デバイスのようなクライアントデバイス１１３が、デバイス１１３がどこに位置しているかに依存して資産ストアサービス１０７に時々接続してもよい。デバイス１１３は、ローカルなバックアップデバイス１１１にローカルに結合されるかまたは（例えば有線で）直接接続されてもよく、バックアップデバイス１１１は、ハードディスク、固体デバイス、フラッシュメモリ、またはその他のストレージサービスのような大容量記憶装置にアクセスすることが可能なデスクトップコンピュータである可能性がある。一実施形態では、クライアントデバイス１１３は、すぐさま識別される複数のソース（例えばサーバ、サービス、またはローカルデバイス）１０１、１０３、１０５、１０７、１１１、１１７を介してバックアップおよび／または復元されてもよい。サービス１０１、１０３、１０５、１０７、１１１、１１７またはその他の適用可能なコンテンツサービスのようなバックアップサービスおよびバックアップソースが、デバイス１１３のようなデバイスへ、デバイスが資産をバックアップすることを必要とせず、要求に応じて資産またはコンテンツを復元することができてもよい。

図２は、本明細書で記述される一実施形態による、多段階多ソースのバックアップおよび復元のための例示的なシステムを示すブロック図である。一実施形態では、システム２００は、図１のクライアントデバイス１１３に基づいていて、操作環境２０１を実行中であってもよく、操作環境２０１は、Ａｐｐｌｅ Ｉｎｃ．製のｉＯＳ（登録商標）オペレーティングシステムまたはその他の適用可能なオペレーティングシステムに基づいていてもよい。

システム２０１は、バックアップ／復元管理モジュール２０７を含んでいて、選択されたソースを使ってネットワークインタフェースモジュール２０３を介してデバイスのリソースをバックアップおよび復元してもよい。リソースは、例えば、ファイルシステム２１７の中のファイルを含んでいてもよい。モジュール２０７は、ユーザが構成可能なスケジュールで、例えば、毎日、毎週、および／または、リモートのデバイスを介して受信された要求および／またはユーザ入力からのオンデマンドで、バックアップ／復元操作を開始してもよい。一部の実施形態では、モジュール２０７は、システムイベントハンドラモジュール２０５を介して監視された、（例えば、外部電源コードのプラグが抜けた場合の）外部電力の喪失のようなシステムイベントに応じて、バックアップ／復元操作を中断または再開してもよい。

ローカルデータベース２０９が、デバイス用にバックアップされた１つ以上のスナップショットをキャッシュに格納するかまたは記憶してもよい。スナップショットは、或る時刻点でバックアップされたデバイスのリソースの状態を表してもよい。バックアップ／復元操作は、システム２０１が、スナップショットに対応する、前の状態に戻ることを可能にしてもよい。

一実施形態では、アプリケーション２１３のような１つ以上のアプリケーションが、例えばステータスインタフェースモジュール２１５を介して、バックアップ／復元管理モジュール２０７と通信してもよい。アプリケーション２１３は、プラグインとしてかまたはＡＰＩインタフェースを介して、ステータスインタフェースモジュール２１５とリンクしていてもよい。一実施形態では、アプリケーション２１３は、関連のリソースのバックアップ／復元ステータスにアクセスして、ユーザインタフェースモジュール２１９を介して進捗を提示してもよい。

あるいは、アプリケーション２１３は、ユーザインタフェースモジュール２１９を介して受信された、例えばユーザのタップ動作のようなユーザ要求をモジュール２０７へ中継して、バックアップ／復元操作をすぐさま順序付けし直すかまたは変更してもよい。ユーザ要求は、タッチスクリーンに基づく、マウスに基づく、ポインタに基づく、音声に基づく、あるいはその他の適用可能なユーザインタフェースの技術を介して受信されてもよい。一実施形態では、利用回数、利用頻度、利用時刻、またはその他の適用可能な利用統計値などのようなアプリケーション２１３の利用履歴が、利用履歴２１１の中に記録されてもよい。モジュール２０７は、利用履歴２１１を介して収集された情報に基づいてバックアップ／復元操作を動的に構成してもよい。

図３は、本明細書で記述される一実施形態による、複数のソースを用いる複数の段階におけるバックアップおよび復元を管理するための例示的なシステムを示すブロック図である。システム３００は、バックアップ／復元管理モジュール２０７を含めて、図２のシステム２００に基づいていてもよい。一実施形態では、システム３００は、バックアップ／復元操作を行うための複数のバックアップ／復元ソースを発見し、および／または、それらとインタフェースを取ることができる、サービスフレームワーク３０９を含んでいてもよい。

例えば、（例えばｉｔｕｎｅｓｔｏｒｅｄプロセスとして実行中の）ストアインタフェースモジュール３０１が、購入されたリソースを転送するために、図１のストア１０７のような利用可能なストアと通信してもよい。クラウド・インタフェース・モジュール３０７が、図１のクラウドバックアップサービス１０１のようなクラウドストレージと通信して、デバイス内のバックアップ／復元リソース用の実際のコンテンツを転送してもよい。（例えばｉｔｕｎｅｓｔｏｒｅｄプロセスとして実行中の）ローカルデバイス・インタフェース・モジュール３０５が、図１のローカルバックアップデバイス１１１の中にホストされるｉＴｕｎｅｓ（登録商標）のような、ローカルコンピュータの中で実行中の対応するサービスとメッセージを交換することによって、リソースをバックアップ、復元、および／または同期させてもよい。一実施形態では、インタフェースモジュール３０１、３０５、３０７が、ＡＴＣエンジンまたはモジュールのような共通インタフェースエンジン３０３を共有してもよく、インタフェースエンジン３０３は、インタフェースモジュール３０１、３０５、３０７よりも低レベルの抽象化でデータ転送を行うことができてもよい。

（例えば、ｂａｃｋｕｐｄプロセスとして実行中の）多段階ハンドラモジュール３１１が、多様な段階のバックアップ／復元操作を管理することができる。例えば、多段階ハンドラモジュール３１１は、（例えば、構成されたスケジュールに従って）バックアップサービス１０５を使ってバックアップ操作を開始して、バックアップすべきリソースのスナップショットの記述を識別してもよい。一実施形態では、多段階ハンドラモジュール３１１は、モーダルな段階（すなわち第１段階）および／または、モーダルでないことがある（例えば、ユーザとの対話が可能な）その後の段階（例えばバックグラウンド段階）においてどのリソースを復元すべきかを識別してもよい。

一部の実施形態では、リソース待ち行列ハンドラモジュール３１３が、復元および／またはバックアップ用のリソースの順序付け直しを、例えば、構成されたヒューリスティックスおよび／またはユーザ要求に従って、動的に行ってもよい。リソースまたは資産は、サービスフレームワーク３０９の別個の待ち行列に従って順序付けされた多様なソースとの間で転送されてもよい。一実施形態では、デバイスの（例えばバックグランドにおける）復元の間にアプリケーションから受信された、ユーザのタップ動作またはその他のユーザインタフェース動作（例えばマウスのクリック、音声コマンド、キーボード選択、手のジェスチャなど）に応じて、リソース待ち行列ハンドラモジュール３１３が、まだ復元されていないリソースの優先順序の付け直しを、アプリケーションに有利になるように行ってもよい。リソース待ち行列ハンドラモジュール３１３は、サービスフレームワーク３０９に命令して、例えば、アプリケーションに関連するリソースをダウンロードする目的で、優先度を上げられるように待ち行列を更新させてもよい。

図４は、本明細書で記述される一実施形態による、デバイスのための増分バックアップ操作を行うプロセスの一実施形態を示すフロー図である。例示的なプロセス４００は、（回路機構、専用論理などの）ハードウェア、（専用マシン上で実行されるような）ソフトウェア、あるいはそれら両方の組み合わせを含みうる処理論理によって行われてもよい。例えば、プロセス４００は、図２のシステム２００の一部のコンポーネントによって行われてもよい。

一実施形態では、プロセス４００の処理論理は、少なくとも２つのステップを含むバックアップ操作を行ってもよい。プロセス４００の処理論理は、メタデータをバックアップサービス（例えばＭＢＳ）へ送信し、コンテンツサービス（例えばＭＭＣＳ）との間で認証するためのトークンをバックアップサービスから受信してもよい。その後、プロセス４００の処理論理は、トークンを用いて実際のコンテンツをコンテンツサービスへアップロードしてもよい。バックアップサービス内のファイルのメタデータは、認証トークンを使って更新されてもよい。

ブロック４０１で、プロセス４００の処理論理は、バックアップ管理サーバ（例えばＭＢＳ）内でデバイスに対応するバックアップを探し出してもよい。デバイスに対応する既存のバックアップが見つからない場合、バックアップが新たに作成されてもよい。ブロック４０３で、プロセス４００の処理論理は、バックアップ管理サーバと同期するために、スナップショットのキャッシュ（またはマニフェストキャッシュ(manifest cache)）を再構築してもよい。ブロック４０５で、プロセス４００の処理論理は、前のバックアップ操作のスナップショットを識別してもよい。識別されたスナップショットは、未コミットのスナップショットまたは新規作成されたスナップショットであってもよい。識別されたスナップショットは、ファイルシステム内のファイルを記述するメタデータを含んでいてもよい。

ブロック４０７で、プロセス４００の処理論理は、例えば、識別されたスナップショットとの比較を介して、ファイルシステムの変更（例えば新規ファイル、削除されたファイル、修正されたファイルなど）についてファイルシステムをスキャンしてもよい。ブロック４０９で、プロセス４００の処理論理は、バックアップ管理サーバ、バックアップサービス管理サーバ（例えばＭＭＣＳ）およびストレージベンダサーバ（例えば、Ａｍａｚｏｎ、Ｓ３、またはクラウドストレージなど）との協調トランザクションを介してバックアップ操作を行ってもよい。ブロック４１１で、プロセス４００の処理論理は、前に作成されたスナップショットをマージしてもよい（例えば、古いスナップショットを削除し、および／または、各々が前のスナップショットからの一組のファイルへの増分変更に対応する、複数の増分スナップショットにより、ファイル一式に対応する１つの全体的スナップショットを維持してもよい）。

図５は、本明細書で記述される一実施形態による、デバイス内で増分復元操作を行うプロセスの一実施形態を示すフロー図である。例示的なプロセス５００は、（回路機構、専用論理などの）ハードウェア、（専用マシン上で実行されるような）ソフトウェア、あるいはそれら両方の組み合わせを含みうる処理論理によって行われてもよい。例えば、プロセス５００は、図２のシステム２００の一部のコンポーネントによって行われてもよい。

ブロック５０１で、プロセス５００の処理論理は、ユーザからの入力に応じることなく、システムファイルをクラウドバックアップからデバイス（例えばｉＯＳ（登録商標）デバイス）へモーダル復元することができる。モーダルな復元の間、デバイスのオペレーティングシステムが利用可能であって実行されてもよい。ブロック５０３で、プロセス５００の処理論理は、復元されたシステムファイルを使ってデバイスをユーザのための作業状態へリブートすることができる。

ブロック５０５で、プロセス５００の処理論理は、バックグラウンドにおいてファイルをデバイスへ復元することができる。（例えば、購入または転送された）資産は、クラウドストア（例えばｉＴｕｎｅｓ（登録商標）ストア）からダウンロードされてもよく、データをクラウドバックアップから復元することもできる。ブロック５０７で、プロセス５００の処理論理は、（例えば、ｉＴｕｎｅｓ（登録商標）バックアップソフトウェアを実行中の）ユーザコンピュータからのファイルを同期／分割復元することができる。ファイルは、購入された資産、および／または、クラウドバックアップから復元されたのではないデータを含んでいてもよい。

図６は、本明細書で記述される一実施形態による、デバイスを復元するためのリソースに動的に優先順位を付けるプロセスの一実施形態を示すフロー図である。例示的なプロセス６００は、（回路機構、専用論理などの）ハードウェア、（専用マシン上で実行されるような）ソフトウェア、あるいはそれら両方の組み合わせを含みうる処理論理によって行われてもよい。例えば、プロセス６００は、図２のシステム２００の一部のコンポーネントによって行われてもよい。

ブロック６０１で、プロセス６００の処理論理は、デバイス（例えば、ｉＯＳ（登録商標）ベースの移動デバイス）内でホストされているアプリケーションおよび／またはコンテンツの利用パタン（例えば、回数、利用時刻、利用位置、利用継続時間など）を把握することができる。ブロック６０３で、プロセス６００の処理論理は、デバイスへ復元すべきアプリケーションおよび／またはコンテンツのリストを作成することができる。ブロック６０５で、プロセス６００の処理論理は、デバイスの現在位置を判定してもよい。ブロック６０７で、プロセス６００の処理論理は、復元すべきアプリケーションおよび／またはコンテンツのリストに、利用パタン、アプリケーションおよび／またはコンテンツに関連する適用可能なメタデータ（例えば、サイズ、タイプなど）、および／または現在位置での利用可能性に基づく順序を使って優先順位を付けてもよい。

ブロック６０９で、プロセス６００の処理論理は、優先順位を付けられたリストを用いて現在位置においてアプリケーションおよび／またはコンテンツをデバイスへ復元することができる。ブロック６１１で、プロセス６００の処理論理は、１つ以上のアプリケーション／コンテンツに関する所望の復元優先度を示す、例えばタップ入力を介したユーザ要求を検出してもよい。ブロック６１３で、プロセス６００の処理論理は、復元すべきアプリケーションおよび／またはコンテンツの優先順位を付けられたリストの順序を、要求された所望の復元優先度に従って動的に変更してもよい。

図７は、本明細書で記述される一実施形態による、バックアップおよび／または復元操作のためにデバイスの電源を監視する例示的なシステムを示すブロック図である。システム７００は、図１のデバイス１１３のようなクライアントデバイスに基づいていてもよい。

システム７００は、外部電源（例えばＡＣ／ＤＣアダプタ、ソーラーパネル、誘導充電パッドなど）７１９からの再充電が停止したのを検出することに応じて、開始されて進行中である、電波による（ワイヤレス）バックアップ操作を終了させるように構成することができる。システム７００は、ＡＣ／ＤＣアダプタまたはその他の外部電源の出力に結合されるプラグのジャックまたはソケットのような外部電源ポート７１３と、再充電制御器の制御の下で再充電されるバッテリ７１７とを含んでいる。

電源検出器７０９が、外部電源ポートに結合され、そして、処理システム７１１に結合されている。処理システム７１１は、チップ上のマイクロプロセッサをベースにしたシステムかまたはその他の処理システムであってよい。電源検出器は、外部電源の利用可能性および再充電プロセスの状態を監視し、その監視に基づいて、再充電プロセスが、外部電源からの切断の結果として終了したかどうかを判定する。電源検出器は、再充電プロセスが切断の結果として終了したことを検出するのに応じて、終了信号（例えば、処理システムに接続されているバス上の中断信号）を生成することができ、それが、処理システムにワイヤレスバックアップ操作を終了させる。

一実施形態では、終了の前にはバックアップ操作が開始されて進行中であり、システム７００のメモリ７１５の中に記憶されうるソフトウェアまたはユーザデータ（例えば、連絡先、カレンダのエントリ、ユーザのテキストファイル、歌や写真などのユーザのメディアファイルなど）またはそれら両方をバックアップしているところである。システム７００内の処理システムは、本明細書内で記述されたバックアップ方法のいずれか１つを行って、ソフトウェアおよび／またはユーザデータを、バックアップ操作を通じて、ネットワーク７０３に接続されたサーバ７０１のようなリモートデバイス上に記憶させることができる。バックアッププロセスは、システム７００内の１つ以上の無線（例えばＷｉＦｉ無線またはセルラー電話無線）７０７を通じてワイヤレスで行われ、これらの無線は、システム７００内の処理システムに接続され、１つ以上のネットワークに接続される。ネットワークは、単一のネットワーク（例えばワイヤレスＬＡＮ）であってもよいし、複数のネットワークまたはインターネットに接続されたセルラー電話ネットワークであってもよい。

終了信号に応じて、処理システムは、進行中の（この時点では不完全である）バックアッププロセスを、すぐに、またはバックアップ操作内で現在処理されているファイルのバックアップ操作を完了した後に、終了させることができる。本明細書で記述される処理システムおよび／または１つ以上のサーバは、署名または同期アンカーまたはその他のメカニズムを用いて、時期尚早に終了されたバックアップ操作において何が完了されたか、および、時期尚早に終了されたバックアップ操作において何が完了されなかったかを把握するために、アトミックなバックアップ操作を把握することができる。バックアップ操作の終了は、システム７００によって、ユーザ要求または対話なしで自動的に行われてもよい。

システム７００が再び外部電源から再充電されている場合、バックアッププロセスは、終了された状態から再開されてもよい。一実施形態では、システム７００は、外部電源を通じて再充電されている場合は本明細書で記述された１つ以上の方法によってバックアップされ、そして、その電源から切断された場合はバックアップを終了させ、再充電が再開された場合は、終了されたバックアップ状態から再開される。従って、バックアッププロセスは、一実施形態では、図８に示すように、外部電源が接続されてシステム７００内のバッテリを充電中であることを検出するのに応じて、開始または再開される。

図８は、本明細書で記述された一実施形態による、電力を節約するためにデバイスのバックアップおよび／または復元操作を中断するプロセスの一実施形態を示すフロー図である。例示的なプロセス８００は、（回路機構、専用論理などの）ハードウェア、（専用マシン上で実行されるような）ソフトウェア、あるいはそれら両方の組み合わせを含みうる処理論理によって行われてもよい。例えば、プロセス８００は、図２のシステム２００または図７のシステム７００の一部のコンポーネントによって行われてもよい。

ブロック８０１で、プロセス８００の処理論理は、内部バッテリが再充電中であることを判定してもよい。ブロック８０３で、プロセス８００の処理論理は、バックグラウンドプロセスとしてリモートのバックアップサーバを使ってバックアップ操作を開始し、そして、内部バッテリの再充電ステータスを監視してもよい。ブロック８０５で、プロセス８００の処理論理は、内部バッテリの再充電が（例えば、ＡＣ／ＤＣアダプタなどから切断されて）終了したと、再充電ステータスに従って判定してもよい。ブロック８０７で、プロセス８００の処理論理は、バッテリの再充電が終了したことを検出するのに応じてバックアップ操作を終了させてもよい。ブロック８０９で、プロセス８００の処理論理は、バッテリが再充電を開始することを検出するのに応じてバックアップ操作を再開してもよい。

図９は、本明細書で記述された実施形態と共に用いられうるデータ処理システムの一例を示す図である。図９に示すデータ処理システム９００は、処理システム９１１を含んでおり、処理システム９１１は、１つ以上のマイクロプロセッサであってもよいし、チップの集積回路上のシステムであってもよい。また、システムは、処理システムによって実行されるデータおよびプログラムを記憶するメモリ９０１も含んでいる。また、システム９００は、音声入力／出力サブシステム９０５を含んでおり、音声入力／出力サブシステム９０５には、例えば、スピーカとマイクとを通して音楽を再生するかまたは電話機能性を提供するためのマイクとスピーカとが含まれていてもよい。システム９００は、少なくとも一部の実施形態では、ネットワークまたはローカルな接続を通して自動的におよび／または手動で、記述された多段階多ソース復元およびバックアップを行うことができる。一実施形態では、システム９００は、図２に示すシステムを含んでいてもよい。

ディスプレイ制御器兼ディスプレイデバイス９０７が、ユーザのための視覚的なユーザインタフェースを提供し、このデジタルインタフェースには、ＯＳ Ｘ（登録商標）オペレーティングシステムソフトウェアを実行中のマッキントッシュコンピュータ上に示されるものに類似したグラフィカルユーザインタフェースが含まれてもよい。また、システム９００は、別のデータ処理システムと通信するための１つ以上のワイヤレストランシーバ９０３を含んでいる。ワイヤレストランシーバは、ＷｉＦｉトランシーバ、赤外線トランシーバ、Ｂｌｕｅｔｏｏｔｈトランシーバ、および／またはワイヤレスセルラー電話トランシーバであってもよい。理解されるであろうが、実施形態によっては、図示しない追加のコンポーネントがシステム９００の一部であってもよいし、実施形態によっては、データ処理システム内で用いられるコンポーネントは、図９に示すものより少なくてもよい。

また、データ処理システム９００は、ユーザがシステムに入力を行えるように設けられている１つ以上の入力デバイス９１３を含んでいる。これらの入力デバイスは、キーパッドまたはキーボードまたはタッチパネルまたはマルチタッチパネルであってもよい。また、データ処理システム９００は、ドック用のコネクタであってもよい任意の入力／出力デバイス９１５を含んでいる。理解されるであろうが、当分野では周知であるように、図示しない１つ以上のバスが用いられて、各種のコンポーネントが相互接続されてもよい。図９に示すデータ処理システムは、手持ち式のコンピュータもしくは携帯情報端末（ＰＤＡ）、または、ＰＤＡに似た機能性を持つセルラー電話、または、セルラー電話を含んでいる手持ち式コンピュータ、または、ｉＰｏｄのようなメディアプレーヤ、あるいは、１つのデバイスの中にＰＤＡとセルラー電話とを組み合わせたメディアプレーヤのような、これらのデバイスの態様または機能を組み合わせたデバイスであってもよい。別の実施形態では、データ処理システム９００は、ネットワークコンピュータ、または別のデバイス内に内蔵された処理デバイス、あるいは図９に示すものよりコンポーネントがより少ないかまたは場合によってはより多い、別のタイプのデータ処理システムであってもよい。

図１０は、本発明における一実施形態と共に用いられうる、コンピュータシステムのようなデータ処理システムの一例を示す図である。例えば、システム１０００は、図１に示すシステムの一部として実装されてもよい。図１０はコンピュータシステムの各種のコンポーネントを示しているが、コンポーネントを相互接続するいずれかの個別のアーキテクチャまたは方式を表すことは意図されておらず、そのような詳細は本発明に密接に結びついてはいないことに留意されたい。また、ネットワークコンピュータ、および、コンポーネントがより少ないかまたは場合によってはより多いその他のデータ処理システムが本発明と共に用いられうることも、理解されるであろう。

図１０に示すように、データ処理システムの一形態であるコンピュータシステム１０００がバス１００３を含んでおり、バス１００３は、マイクロプロセッサ１００５とＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１００７と揮発性ＲＡＭ１００９と不揮発性メモリ１０１１とに接続されている。マイクロプロセッサ１００５は、メモリ１００７、１００９、１０１１から命令を検索して、上記の操作を行うために命令を実行してもよい。バス１００３は、これらの各種のコンポーネントを一緒に相互接続し、また、これらのコンポーネント１００５、１００７、１００９、１０１１をディスプレイ制御器兼ディスプレイデバイス１０１３と、例えばマウス、キーボード、モデム、ネットワークインタフェース、プリンタ、および当分野では周知のその他のデバイスであってもよい入力／出力（Ｉ／Ｏ）デバイスのような周辺デバイスとに相互接続する。典型的には、入力／出力デバイス１０１５は、入力／出力制御器１０１７を通じてシステムに接続される。揮発性ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１００９は、典型的には、メモリ内のデータをリフレッシュまたは維持するために持続的に電力を必要とするダイナミックＲＡＭ（ＤＲＡＭ）として実装される。

マスストレージ１０１１は、典型的には、磁気ハードドライブまたは磁気光学ドライブまたは光学ドライブまたはＤＶＤ ＲＡＭまたはフラッシュメモリまたは、電力がシステムから取り外された後であってもデータ（例えば、大量のデータ）を維持する、その他のタイプのメモリシステムである。また、典型的には、マスストレージ１０１１も、ランダムアクセスメモリであろうが、これは必要とされていない。図１０は、マスストレージ１０１１が、データ処理システム内の残りのコンポーネントに直接接続されるローカルデバイスであることを示しているが、本発明は、モデムやイーサネットインタフェースやワイヤレス・ネットワーキング・インタフェースのようなネットワークインタフェースを通じてデータ処理システムに接続されるネットワークストレージデバイスのような、システムからリモートである不揮発性メモリを利用しうることは、理解されるであろう。バス１００３には、当分野では周知の各種のブリッジ、制御器および／またはアダプタを通じて相互に接続された１つ以上のバスが含まれていてもよい。

上記で説明したものの各部分が、専用の論理回路のような論理回路機構を使って、あるいは、マイクロコントローラまたはその他の形のプログラムコード命令を実行する処理コアを使って、実装されてもよい。従って、上記の議論によって教示されたプロセスが、命令を実行するマシンに所定の機能を行わせるマシン実行可能命令のようなプログラムコードを使って行われてもよい。この文脈では、「マシン」とは、中間形態の（または「抽象的な」）命令をプロセッサ固有の命令へ変換するマシン（例えば、「バーチャルマシン」（例えばＪａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）、インタプリタ、Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ、高レベル言語バーチャルマシンなどのような抽象実行環境）、および／または、汎用プロセッサおよび／または特定用途プロセッサのような、命令を実行するようになっている半導体チップ上に配置された電子回路機構（例えば、トランジスタを実装した「論理回路機構」）であってもよい。また、上記の議論によって教示されたプロセスは、プログラムコードを実行することなくプロセス（またはその一部分）を行うようになっている電子回路機構によって（マシンに代わるものとして、またはマシンと組み合わせて）行われてもよい。

プログラムコードを記憶するため、製品が用いられてもよい。プログラムコードを記憶する製品は、１つ以上のメモリ（例えば、１つ以上のフラッシュメモリ、ランダムアクセスメモリ（スタティック、ダイナミック、またはその他）、光ディスク、ＣＤ−ＲＯＭ、ＤＶＤ ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、あるいはその他のタイプの、電子的命令を記憶するのに適したマシン可読メディア）として実施されてもよいが、それらに限定されない。また、プログラムコードは、リモートのコンピュータ（例えばサーバ）から要求側コンピュータ（例えばクライアント）へ、伝搬メディアの中に具現化されたデータ信号によって（例えば、通信リンク（例えばネットワーク接続）を介して）ダウンロードされてもよい。

本明細書では「メモリ」という用語は、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）やスタティックＲＡＭ（ＳＲＡＭ）のような、すべての揮発性の記憶媒体を包含することが意図されている。コンピュータ実行可能命令は、磁気ハードディスクや光ディスクのような不揮発性記憶デバイス上に記憶されてもよく、典型的には、プロセッサによってソフトウェアの実行中にメモリ内へ、ダイレクトメモリアクセスプロセスによって、書き込まれる。当業者であれば、「マシン可読記憶媒体」という用語は、プロセッサによってアクセス可能ないかなるタイプの揮発性または不揮発性の記憶デバイスをも含むということをすぐに理解するであろう。

上記の詳細記述は、コンピュータメモリの中のデータビットに関する操作のアルゴリズムおよび象徴的な表現に関して提示されている。これらのアルゴリズムに関する記述および表現は、データ処理分野において当業者によって用いられ、自分達の作業の中身を他の当業者に最も効果的に伝達するツールである。本明細書では、また、一般には、アルゴリズムとは、所望の結果をもたらす一連の一貫した操作であると考えられている。これらの操作は、物理量の物理的マニピュレーションを必要とする操作である。必ずというわけではないが、通常は、これらの量は、記憶され、転送され、合成され、比較され、その他の方式でマニピュレートされることができる電気信号または磁気信号という形を取る。主に共通使用という理由から、時には、これらの信号をビット、値、要素、シンボル、文字、用語、数などとして言及することが便利であることが分かっている。

しかし、留意すべきことだが、これらの用語および同様の用語はすべて、適切な物理量に関連付けられることになり、これらの量に適用される単に便利なラベルなのである。理解されることだが、特に別段の指定がない限り、また上記から明らかなとおり、本記述全体を通して、例えば「処理」または「演算」または「計算」または「判定」または「表示」のような用語を用いた議論は、コンピュータシステムまたは同様の電子的演算デバイスの動作およびプロセスのことを言う。コンピュータシステムまたは同様の電子的演算デバイスは、コンピュータシステムのレジスタおよびメモリの中の物理（電子）量として表されるデータをマニピュレートして、コンピュータシステムのメモリまたはレジスタまたはその他のそのような情報のストレージ、送信、または表示デバイスの中の物理量として同様に表される他のデータへと変換する。

また、本発明は、本明細書に記述された操作を行うための装置に関する。この装置は、必要とされる目的に合わせて特別に構築されてもよいし、コンピュータ内に記憶されるコンピュータプログラムによって選択的に起動されるか再構成される汎用コンピュータを備えていてもよい。そのようなコンピュータプログラムは、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭおよび磁気光ディスクを含むいずれかのタイプのディスクと、読取専用メモリ（ＲＯＭ）と、ＲＡＭと、ＥＰＲＯＭと、ＥＥＰＲＯＭと、磁気カードおよび光カードと、あるいは、電子的命令を記憶するのに適していて、それぞれがコンピュータシステムバスに接続されているいずれかのタイプの媒体とのような、コンピュータ可読記憶媒体の中に記憶されていてもよいが、それらに限定されない。

本明細書で提示されたプロセスおよびディスプレイは、いかなる個別のコンピュータまたはその他の装置にも本質的に関係してはいない。各種の汎用システムが、本明細書の教示内容によるプログラムと共に用いられてもよいし、記述された操作を行うためのより特殊な装置を構築することが便利であると分かることもありうる。各種のこれらのシステムに必要な構造は、以下の記述から明らかであろう。加えて、本発明は、いずれかの特定のプログラム言語に関して記述しているのではない。理解されるであろうが、各種のプログラム言語を用いて、本明細書に記述された本発明の教示内容を実装することができる。

前述の明細書において、本発明をその特定の例示的な実施形態に関して記述してきた。下記の請求項の中に記述した本発明の広範な趣旨と範囲とから逸脱することなく、それに対して各種の修正形態が作られうることは明らかであろう。従って、本明細書および図面は、限定的な意味でなく例示的な意味で考えられるべきである。

Claims (23)

1. 命令を有する非一時的なマシン可読記録媒体であって、前記命令は、マシンによって実行されると、前記マシンに方法を実行させ、前記方法は、
   デバイス内のリソースの第１のバックアップソースへの変更を識別するステップと、
   前記第１のバックアップソースから、第２のバックアップソースに対する許可のためのトークンを受信するのに応じて、前記トークンを用いて、前記リソースの変更を前記第２のバックアップソースにバックアップするステップと、
   前記第２のバックアップソースに対する前記変更の前記バックアップが成功した場合、前記リソースの変更を前記第１のバックアップソースに対してコミットするステップと、
   を備えることを特徴とするマシン可読記録媒体。
2. 前記識別するステップは、
   前記デバイスの以前のスナップショットを前記第１のバックアップソースと同期させるステップであって、前記以前のスナップショットは以前の時点に前記デバイスのために既にバックアップされているリソースを示す、ステップと、
   前記変更に関して、前記デバイスのリソースを前記以前のスナップショットと比較するステップと、
   を含む
   ことを特徴とする請求項１に記載のマシン可読記録媒体。
3. 前記デバイスはキャッシュスナップショットを含み、
   前記同期させるステップは、前記第１のバックアップソースを介して、前記キャッシュスナップショットが前記以前のスナップショットに関して期限切れであるか否かを判定するステップを含む
   ことを特徴とする請求項２に記載のマシン可読記録媒体。
4. 前記同期させるステップは、前記デバイスの識別子に基づいており、
   前記以前のスナップショットは、前記第１のバックアップソースの中で前記識別子に対応して維持される
   ことを特徴とする請求項２に記載のマシン可読記録媒体。
5. 前記デバイスはファイルシステムを含み、
   前記リソースは前記ファイルシステム中のファイルを含み、
   前記比較するステップは、どのファイルをバックアップする必要があり、どのファイルが既にバックアップされているかを前記以前のスナップショットに基づいて追跡するために、前記ファイルシステムをスキャンする
   ことを特徴とする請求項２に記載のマシン可読記録媒体。
6. ファイルがネットワークアクセス可能なサイトから入手可能な場合、当該ファイルはバックアップする必要が無い
   ことを特徴とする請求項５に記載のマシン可読記録媒体。
7. 前記リソースの実際のコンテンツを記述することなく前記リソースに関する情報を記述する、前記リソースのメタデータを維持するステップを更に備え、
   前記第１のバックアップソースと前記デバイスとの間の通信は、前記通信に関して軽量のネットワークを可能にするために、前記リソースの１つの抽象化層として前記メタデータに基づいており、
   前記第２のバックアップソースと前記デバイスとの間の通信は、前記第２のバックアップソース内のバックアップストレージを共有することを可能にするために、前記リソースの別個の抽象化層として前記リソースの前記実際のコンテンツに基づいている
   ことを特徴とする請求項１に記載のマシン可読記録媒体。
8. 前記デバイスは、バックアップクオータを有するアカウントに関連付けられており、
   前記許可は、前記バックアップクオータを超過することなく、前記リソースの変更のためのバックアップスペースが前記バックアップストレージの中に予約されたということを示す
   ことを特徴とする請求項７に記載のマシン可読記録媒体。
9. 前記実際のコンテンツの一部分が前記リソースの変更に対応し、
   前記バックアップするステップは、
   前記第１のバックアップソースから参照される第３のバックアップソースを、前記トークンを介して認証するステップと、
   前記第３のバックアップソースから受信した指示に応えて、前記リソースの前記別個の抽象化層に従い、前記実際のコンテンツの前記一部分をデータチャンクに分割するステップと、
   を含む
   ことを特徴とする請求項７に記載のマシン可読記録媒体。
10. 前記第３のバックアップソースを介して、どのデータチャンクが存在しなくてバックアップする必要があるかを識別するステップと、
    前記識別したデータチャンクを前記第２のバックアップソースへアップロードするステップと、
    を更に備えることを特徴とする請求項９に記載のマシン可読記録媒体。
11. どのデータチャンクがということを識別する前記ステップは、各データチャンクを一意に識別するチャンク識別子を生成するステップを含み、前記第３のバックアップソースは、データチャンクのチャンク識別子に従って、当該データチャンクが既にバックアップされているか否かを判定する
    ことを特徴とする請求項１０に記載のマシン可読記録媒体。
12. 前記チャンク識別子は、対応するチャンクデータからハッシュされた署名である
    ことを特徴とする請求項１１に記載のマシン可読記録媒体。
13. 前記リソースは、ファイルから分割されたデータチャンクのうちの少なくとも１つに関連付けられたファイルを含み、
    前記方法は、前記第３のバックアップソースにおける前記関連付けられたデータチャンクに関する参照として、前記ファイルに対して任意の識別子を割り当てることで、前記任意の識別子がもはや参照されていない場合に前記第３のバックアップソースを介したガベージコレクションを可能にするステップを更に備える
    ことを特徴とする請求項１１に記載のマシン可読記録媒体。
14. 前記データチャンクのうちの第１のデータチャンクは、第２のデータチャンクがバックアップソースの中に存在すると共に当該第２のデータチャンクが前記第２のデータチャンクを識別する特定の識別子によって識別される場合には、バックアップする必要が無く、
    前記第１及び第２のデータチャンクは、別個の任意の識別子を割り当てられた別個のファイルに関連づけられている
    ことを特徴とする請求項１３に記載のマシン可読記録媒体。
15. 前記アップロードするステップは、前記デバイスにおいて前記第３のバックアップソースから受信した認証キーによって可能にされる
    ことを特徴とする請求項１０に記載のマシン可読記録媒体。
16. 命令を有する非一時的なマシン可読記録媒体であって、前記命令は、マシンによって実行されると、前記マシンに方法を実行させ、前記方法は、
    デバイス内に格納されたファイルの実際のコンテンツを記述するメタデータであって、前記ファイルを表す第１の抽象化層を表すメタデータを維持するステップと、
    前記第１の抽象化層から、前記デバイスからバックアップすべき前記実際のコンテンツの一部分を識別するステップと、
    バックアップすべき前記実際のコンテンツの前記一部分に関するコンテンツ識別子を動的に生成するステップであって、前記コンテンツ識別子は、前記第１の抽象化層とは別個の、前記ファイルを表す第２の抽象化層を表す、ステップと、
    前記コンテンツ識別子を介して、前記実際のコンテンツの前記一部分をネットワークアクセス可能なストレージへアップロードするステップと、
    を備えることを特徴とするマシン可読記録媒体。
17. 前記実際のコンテンツの前記一部分は、前記ファイルの一部分に属し、
    前記ネットワークアクセス可能なストレージは、前記ファイルの前記一部分を復元するには不十分なデータを格納する
    ことを特徴とする請求項１６に記載のマシン可読記録媒体。
18. 前記識別するステップは、前記第１の抽象化層を用いて前記第１のバックアップソースと通信するネットワークプロトコルに基づく
    ことを特徴とする請求項１７に記載のマシン可読記録媒体。
19. 前記第２の抽象化層を用いるネットワークプロトコルを介して、前記第２のバックアップソースを用いて、前記ファイルの前記一部分について、前記ネットワークアクセス可能なストレージへアップロードすべき前記実際のコンテンツの前記一部分を識別するステップを更に備える
    ことを特徴とする請求項１７に記載のマシン可読記録媒体。
20. 前記ネットワークアクセス可能なストレージは、前記アップロードの効率性を向上させるために、前記第２のバックアップソースを介して動的に構成される
    ことを特徴とする請求項１７に記載のマシン可読記録媒体。
21. コンピュータによって実行される方法であって、
    デバイス内のリソースの第１のバックアップソースへの変更を識別するステップと、
    前記第１のバックアップソースから、第２のバックアップソースに対する許可のためのトークンを受信するのに応じて、前記トークンを用いて、前記リソースの変更を前記第２のバックアップソースにバックアップするステップと、
    前記第２のバックアップソースに対する前記変更の前記バックアップが成功した場合、前記リソースの変更を前記第１のバックアップソースに対してコミットするステップと、
    を備えることを特徴とする方法。
22. コンピュータによって実行される方法であって、
    デバイス内に格納されたファイルの実際のコンテンツを記述するメタデータであって、前記ファイルを表す第１の抽象化層を表すメタデータを維持するステップと、
    前記第１の抽象化層から、前記デバイスからバックアップすべき前記実際のコンテンツの一部分を識別するステップと、
    バックアップすべき前記実際のコンテンツの前記一部分に関するコンテンツ識別子を動的に生成するステップであって、前記コンテンツ識別子は、前記第１の抽象化層とは別個の、前記ファイルを表す第２の抽象化層を表す、ステップと、
    前記コンテンツ識別子を介して、前記実際のコンテンツの前記一部分をネットワークアクセス可能なストレージへアップロードするステップと、
    を備えることを特徴とする方法。
23. コンピュータシステムであって、
    実行可能な命令を格納するメモリと、
    少なくとも第１及び第２のバックアップソースと結合するネットワークインタフェースと、
    前記メモリ及び前記ネットワークインタフェースと結合して前記メモリからの前記命令を実行するプロセッサと、
    を備え、前記プロセッサは、
    前記コンピュータシステム内のリソースの前記第１のバックアップソースへの変更を識別し、
    前記第１のバックアップソースから、前記第２のバックアップソースに対する許可のためのトークンを受信するのに応じて、前記トークンを用いて、前記リソースの変更を前記第２のバックアップソースにバックアップし、
    前記第２のバックアップソースに対する前記変更の前記バックアップが成功した場合、前記リソースの変更を前記第１のバックアップソースに対してコミットする
    ように構成される
    ことを特徴とするコンピュータシステム。

Images