JP7181958B2 - ファイル処理方法及びモバイル端末 - Google Patents

Description

本願は、「RECYCLE BIN-BASED SELF-RECOVERY METHOD FOR PICTURE MANAGEMENT APPLICATION, AND DEVICE」と題されて２０１７年６月１６日付けで中国特許庁に出願された中国特許出願第２０１７１０４５９５５７．５号の優先権を主張する。なお、先の中国特許出願は、その全文を参照により本願に援用される。

本願は、端末アプリケーションの分野に、特に、ファイル処理方法及びモバイル端末に関係がある。

スマートフォンが一般的になり、スマートフォンの写真撮影機能がますます強力になるにつれて、より多くのユーザが、写真撮影ツール並びに写真及び映像のための記憶媒体としてスマートフォンを使用する。従って、通常、携帯電話機には、大量の写真及び映像が記憶されている。ユーザが写真をクリアするか、又は他の操作を行うときに、いくつかの重要な写真が誤って削除されることがある。普通の携帯電話機の場合には、写真がアルバムから削除された後に、写真は永久削除され、ユーザによって回復され得ない。

ユーザの誤りによる削除のために写真が永久に失われることを防ぐために、いくつかの携帯電話機にはリサイクルビン機能が付加されている。ユーザによって削除された写真又は映像はリサイクルビンへ移動され、そして、写真又は映像がリサイクルビンへ移動された後に、一定期間が経過するまで、写真又は映像はクリアされない。この期間中に、ユーザは、写真又は映像をリサイクルビンからソースアルバムへ回復することができる。

本願の実施形態は、アプリケーションデータがクリアされた後にリサイクルビン画面上でマルチメディアファイルを表示して、ユーザがリサイクルビン画面上でマルチメディアファイルを永久削除又は回復することができるようにし、それによってユーザエクスペリエンスを改善するファイル処理方法及びモバイル端末を提供する。

これを鑑み、本願の第１の態様は、ファイル処理方法を提供し、当該方法は、
ユーザがモバイル端末上で第１操作を入力し、該第１操作に応答して、前記モバイル端末によって、第１アプリケーションの第１画面上で第１ファイルを表示することと、前記ユーザが前記第１画面上で第２操作を入力し、該第２操作に応答して、前記モバイル端末によって、前記第１アプリケーションの前記第１画面上で前記第１ファイルを表示することをスキップし、リサイクルビン画面上で前記第１ファイルを表示することと、
前記モバイル端末によって前記第１アプリケーションの第１データテーブルを削除し、該第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなる、すなわち、前記モバイル端末が前記リサイクルビン画面上で前記第１ファイルを表示することができなくなることと、
前記モバイル端末が前記第１データテーブルを削除した後に、前記ユーザが前記モバイル端末上で第３操作を入力し、該第３操作に応答して、前記モバイル端末によって、第２データテーブルを生成し、該第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見える、すなわち、前記モバイル端末が前記リサイクルビン画面上で前記第１ファイルを表示することができるようになることと
を含む。

第１データテーブル及び第２データテーブルはリサイクルビンデータテーブルであり、リサイクルビンに属するファイルのメタデータを記録するために使用される。第１アプリケーションは、リサイクルビンデータテーブルに基づき、リサイクルビンに属するファイルを表示する。第１データテーブルは、もともとモバイル端末に記憶されており、第２データテーブルは、第１データテーブルが削除された後に生成される。２つのデータテーブルに記録されるメタデータのタイプは、同じであっても又は異なってもよい。

この実施形態では、リサイクルビンデータテーブルが削除された後に、モバイル端末は、新しいリサイクルビンデータテーブルを生成することができ、それにより、モバイル端末は、アプリケーションデータがクリアされた後にリサイクルビン画面上で第１ファイルを依然として表示することができ、そして、ユーザは、リサイクルビン画面上で第１ファイルを永久削除又は回復することができ、それによってユーザエクスペリエンスが改善される。

本願の第１の態様を参照して、本願の第１の態様の第１の実施では、前記モバイル端末が前記第１画面上で前記ユーザによって入力された前記第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記モバイル端末が前記第１画面上で前記ユーザによって入力された前記第２操作を取得した後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属する。

前記モバイル端末が前記リサイクルビン画面上で前記第１ファイルを表示した後に、前記ユーザは、前記第１ファイルを回復するように前記リサイクルビン画面上で第４操作を入力する。該第４操作に応答して、前記モバイル端末は、前記第１ファイルが属するアルバムを前記リサイクルビンアルバムから前記第１アルバムに変更し、そして、前記モバイル端末は、前記第１アルバムに対応する画面上で前記第１ファイルを表示することができる。

この実施形態では、アプリケーションデータがクリアされた後に、ユーザは、リサイクルビン画面上で、第１ファイルを表示のためにソースアルバムに回復することができ、それによって、解決法の柔軟性は改善される。

本願の第１の態様を参照して、本願の第１の態様の第２の実施では、前記モバイル端末が前記第１画面上で前記ユーザによって入力された前記第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記モバイル端末が前記第１画面上で前記ユーザによって入力された前記第２操作を取得した後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属する。

前記モバイル端末が前記リサイクルビン画面上で前記第１ファイルを表示した後に、前記ユーザは、前記第１ファイルを回復するように前記リサイクルビン画面上で第４操作を入力する。該第４操作に応答して、前記モバイル端末は、前記第１ファイルが属するアルバムを前記リサイクルビンアルバムからターゲットアルバムに変更し、そして、前記モバイル端末は、前記ターゲットアルバムに対応する画面上で前記第１ファイルを表示することができる。

ターゲットアルバムは、システム又はユーザに特有のアルバムであり、ユーザによって、リサイクルビン画面上で回復されるマルチメディアファイルを管理するために使用される。

この実施形態では、アプリケーションデータがクリアされた後に、ユーザは、リサイクルビン画面上で、第１ファイルを表示のためにシステム特有のアルバムに回復することができ、それによって、解決法の柔軟性は改善される。

本願の第１の態様を参照して、本願の第１の態様の第３の実施では、前記第２データテーブルを生成した後に、前記モバイル端末が、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示し、前記ユーザが、前記第１ファイルを永久削除するように前記リサイクルビン画面上で第５操作を入力する。該第５操作に応答して、前記モバイル端末は、前記第１ファイルを永久削除する、すなわち、前記第１ファイルを前記モバイル端末から削除する。前記第１ファイルは、永久削除された後にモバイル端末上でもはや記憶されていない。

この実施形態では、アプリケーションデータがクリアされた後に、ユーザは、記憶空間を解放するために第１ファイルを永久削除することができ、それによって、ユーザエクスペリエンスは改善される。

本願の第１の態様を参照して、本願の第１の態様の第４の実施では、前記第２データテーブルを生成した後に、前記モバイル端末が、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示する。前記ユーザは、前記第１ファイルのメタデータを見るために前記リサイクルビン画面上で第６操作を入力する。該第６操作に応答して、前記モバイル端末は、前記第１ファイルの前記メタデータを表示する。前記メタデータは、次のもの：前記第１ファイルのオリジナルのファイル名、前記第１ファイルのオリジナルのファイル識別子、前記第１ファイルの削除時間、前記第１ファイルのソース記憶パス、前記第１ファイルの現在の記憶パス、前記第１ファイルの撮影時間、前記第１ファイルのピクチャ方向、前記第１ファイルのクラウドグローバル一意識別子、前記第１ファイルのハッシュ値、及び前記第１ファイルが属するソースアルバムのクラウド識別子、のうちの少なくとも１つを含んでよい。

オリジナルのファイル名は、モバイル端末が第２操作を取得する前の第１ファイルのファイル名である。オリジナルのファイル識別子は、モバイル端末が第２操作を取得する前の第１ファイルの、対応するデータテーブル内の識別子である。ソース記憶パスは、モバイル端末が第２操作を取得する前の第１ファイルの記憶パスである。現在の記憶パスは、モバイル端末が第６操作を取得するときの第１ファイルの記憶パスである。ソースアルバムは、モバイル端末が第２操作を取得する前に第１ファイルが属するアルバムである。

この実施形態では、アプリケーションデータがクリアされた後に、ユーザは、第１ファイルの詳細を知るためにリサイクルビン画面上で第１ファイルのメタデータを見ることができ、それによって、ユーザエクスペリエンスは改善される。

本願の第１の態様及び第１の態様の第１乃至第４の実施のうちのいずれか１つを参照して、本願の第１の態様の第５の実施では、前記第３操作に応答して、前記モバイル端末は、次のプロシージャ：
前記モバイル端末によって、前記第１アプリケーションの前記リサイクルビン画面上で、前記第１ファイルと同じであって且つクラウドサーバに記憶されているファイルを表示することをスキップすること
を更に実行してよい。

この実施形態では、モバイル端末は、繰り返される表示を回避してユーザエクスペリエンスを改善するために、リサイクルビン画面上で第１ファイルと同じファイルを表示することをスキップする。

本願の第１の態様及び第１の態様の第１乃至第５の実施のうちのいずれか１つを参照して、本願の第１の態様の第６の実施では、前記第２データテーブルを生成した後に、前記モバイル端末は選択画面を表示してよい。前記ユーザは、リサイクルビン画面上で表示される必要があるファイルを選択するように選択画面上で第７操作を入力する。該第７操作に応答して、前記モバイル端末は、前記第１アプリケーションの前記リサイクルビン画面上で、前記ユーザによって選択された前記第１ファイルを表示する。ユーザによって選択されなかったファイルについては、それらのファイルはモバイル端末から永久削除されてよい。

この実施形態では、アプリケーションデータがクリアされた後に、モバイル端末は、ユーザの選択に基づき、リサイクルビンで表示される必要があるファイルを決定してよく、それによって、解決法の柔軟性は改善される。

本願の第１の態様及び第１の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第１の態様の第７の実施では、前記第２操作に応答して、前記モバイル端末は、次のプロシージャ：
前記モバイル端末によって、前記第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、前記第１ファイルのファイル名を第１名称から第２名称へ変更すること
を更に実行してよく、このとき、前記第２ディレクトリは、前記第１アプリケーションの前記リサイクルビン画面上で表示されるファイルを記憶するために使用される。前記モバイル端末が前記第１ファイルの前記記憶場所を前記第１ディレクトリから前記第２ディレクトリへ変更した後に、前記モバイル端末は、前記リサイクルビン画面上で前記第１ファイルを表示することができる。

この実施形態は、解決法の柔軟性を改善するように、モバイル端末によってリサイクルビン画面上で第１ファイルを表示する具体的な方法を提供する。

本願の第１の態様の第７の実施を参照して、本願の第１の態様の第８の実施では、前記第２名称は、前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによって取得されるターゲット文字列である。

この実施形態は、モバイル端末が前もってセットされた符号化方式を使用することによって第２名称で第１ファイルのメタデータを記憶し得る方法を提供して、モバイル端末が削除命令を取得した後にメタデータを記憶する方法を提供するとともに、解決法の柔軟性を改善する。

本願の第１の態様の第８の実施を参照して、本願の第１の態様の第９の実施では、前記モバイル端末は、具体的に、次の方法で前記第２データテーブルを生成してよい：
前記モバイル端末によって、前記前もってセットされた符号化方式を使用して前記第２名称を復号することによって前記第１ファイルの前記メタデータを取得し、復号化を通じて取得された前記メタデータに基づき前記第２データテーブルを生成する。

この実施形態は、解決法の柔軟性を改善するように、第２データテーブルを生成する方法を提供する。

本願の第１の態様の第７の実施を参照して、本願の第１の態様の第１０の実施では、前記第２名称は、前記第１ファイルの前記削除時間であり、
前記モバイル端末によって前記第１ファイルの前記記憶場所を前記第１ディレクトリから前記第２ディレクトリへ変更する過程で、前記モバイル端末は、次のプロシージャ：
前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによってターゲット文字列を取得し、該ターゲット文字列及び前記第１ファイルの前記削除時間を前記第２ディレクトリのバイナリファイルにおいて対応付けて格納すること
を更に実行する。

この実施形態は、解決法の柔軟性を改善するように、モバイル端末が削除命令を取得した後にメタデータを記憶する他の方法を提供する。

本願の第１の態様の第１０の実施を参照して、本願の第１の態様の第１１の実施では、前記モバイル端末は、次の方法で前記第２データテーブルを生成してよい：
前記第２名称に基づき前記第１ファイルの前記削除時間を決定し、前記バイナリファイルにおいて前記削除時間に対応するターゲット文字列を決定し、前記前もってセットされた符号化方式を使用して前記ターゲット文字列を復号することによって前記第１ファイルの前記メタデータを取得し、復号化を通じて取得された前記メタデータに基づき前記第２データテーブルを生成する。

この実施形態は、解決法の柔軟性を改善するように、第２データテーブルを生成する他の方法を提供する。

本願の第１の態様及び第１の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第１の態様の第１２の実施では、前記第１データテーブルを削除する前に、前記モバイル端末は、第３データテーブルを取得するよう前記第１データテーブルをバックアップしてよく、前記第１データテーブルを削除した後に、前記モバイル端末は、前記第３データテーブルに基づき前記第２データテーブルを生成する。

この実施形態は、解決法の柔軟性を改善するように、第２データテーブルを生成する他の方法を提供する。

本願の第２の態様は、モバイル端末を提供する。当該モバイル端末は、タッチ検出面及び表示スクリーンを有するタッチスクリーンと、１以上のプロセッサと、メモリと、複数のアプリケーションプログラムと、１以上のコンピュータプログラムとを含み、前記１以上のコンピュータプログラムは前記メモリに記憶され、前記１以上のコンピュータプログラムは命令を含み、該命令が当該モバイル端末によって実行されるときに、当該モバイル端末は、
ユーザが入力した第１操作を取得し、該第１操作に応答して第１アプリケーションの第１画面上で第１ファイルを表示し、前記第１画面上で前記ユーザが入力した第２操作を取得し、該第２操作に応答して、前記第１アプリケーションの前記第１画面上で前記第１ファイルを表示することをスキップし、リサイクルビン画面上で前記第１ファイルを表示するステップと、
前記第１アプリケーションの第１データテーブルを削除し、該第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなる、すなわち、前記第１ファイルが前記リサイクルビン画面上で表示され得ないステップと、
前記第１データテーブルが削除された後に、前記ユーザが入力した第３操作を取得し、該第３操作に応答して第２データテーブルを生成し、該第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見える、すなわち、前記第１ファイルが前記リサイクルビン画面上で表示され得るステップと
を実行する。

第１データテーブル及び第２データテーブルはリサイクルビンデータテーブルであり、リサイクルビンに属するファイルのメタデータを記録するために使用される。第１アプリケーションは、リサイクルビンデータテーブルに基づき、リサイクルビンに属するファイルを表示する。第１データテーブルは、もともとモバイル端末に記憶されており、第２データテーブルは、第１データテーブルが削除された後に生成される。２つのデータテーブルに記録されるメタデータのタイプは、同じであっても又は異なってもよい。

本願の第２の態様を参照して、本願の第２の態様の第１の実施では、前記第１画面上で前記ユーザによって入力された第２操作が取得される前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記第１画面上で前記ユーザによって入力された第２操作が取得された後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属し、
前記第２データテーブルを生成した後に、当該モバイル端末は、
前記リサイクルビン画面上で前記第１ファイルを表示し、該第１ファイルを回復するために前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得し、該第４操作に応答して、前記第１ファイルが属するアルバムを前記リサイクルビンアルバムからターゲットアルバムに変更し、該ターゲットアルバムに対応する画面上で前記第１ファイルを表示するステップ
を更に実行する。

ターゲットアルバムは、システム又はユーザに特有のアルバムであり、ユーザによって、リサイクルビン画面上で回復されるマルチメディアファイルを管理するために使用される。

本願の第２の態様を参照して、本願の第２の態様の第２の実施では、前記第１画面上で前記ユーザによって入力された第２操作が取得される前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記第１画面上で前記ユーザによって入力された第２操作が取得された後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属し、
前記第２データテーブルを生成した後に、当該モバイル端末は、
前記リサイクルビン画面上で前記第１ファイルを表示するステップと、
前記第１ファイルを回復するために前記リサイクルビン画面上で入力された第４操作を取得し、該第４操作に応答して、前記第１ファイルが属するアルバムを前記リサイクルビンアルバムから第１アルバムに変更し、該第１アルバムに対応する画面上で前記第１ファイルを表示するステップと
を更に実行する。

本願の第２の態様を参照して、本願の第２の態様の第３の実施では、前記第２データテーブルを生成した後に、当該モバイル端末は、
前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するステップと、
前記第１ファイルを永久削除するために前記リサイクルビン画面上で入力された第５操作を取得し、該第５操作に応答して、前記第１ファイルを永久削除する、すなわち、当該モバイル端末から前記第１ファイルを削除するステップと
を更に実行し、このとき、前記第１ファイルは、永久削除された後にもはや当該モバイル端末に記憶されていない。

本願の第２の態様を参照して、本願の第２の態様の第４の実施では、前記第２データテーブルを生成した後に、当該モバイル端末は、次のプロシージャ：
前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示することと、
前記第１ファイルのメタデータを見るために前記リサイクルビン画面上で前記ユーザによって入力された第６操作を取得し、該第６操作に応答して前記第１ファイルの前記メタデータを表示することと
を更に実行し、このとき、前記メタデータは、次のもの：前記第１ファイルのオリジナルのファイル名、前記第１ファイルのオリジナルのファイル識別子、前記第１ファイルの削除時間、前記第１ファイルのソース記憶パス、前記第１ファイルの現在の記憶パス、前記第１ファイルの撮影時間、前記第１ファイルのピクチャ方向、前記第１ファイルのクラウドグローバル一意識別子、前記第１ファイルのハッシュ値、及び前記第１ファイルが属するソースアルバムのクラウド識別子、のうちの少なくとも１つを含む。

オリジナルのファイル名は、プロセッサが第２操作を取得する前の第１ファイルのファイル名である。オリジナルのファイル識別子は、プロセッサが第２操作を取得する前の第１ファイルの、対応するデータテーブル内の識別子である。ソース記憶パスは、プロセッサが第２操作を取得する前の第１ファイルの記憶パスである。現在の記憶パスは、プロセッサが第６操作を取得するときの第１ファイルの記憶パスである。ソースアルバムは、プロセッサが第２操作を取得する前に第１ファイルが属するアルバムである。

本願の第２の態様及び第２の態様の第１乃至第４の実施のうちのいずれか１つを参照して、本願の第２の態様の第５の実施では、当該モバイル端末は、
前記第１アプリケーションの前記リサイクルビン画面上で、前記第１ファイルと同じであって且つクラウドサーバに記憶されているファイルを表示することをスキップするステップ
を更に実行してよい。

本願の第２の態様及び第２の態様の第１乃至第５の実施のうちのいずれか１つを参照して、本願の第２の態様の第６の実施では、前記第２データテーブルを生成した後に、当該モバイル端末は、
選択画面を表示するステップと、
前記選択画面上で前記ユーザが入力した第７操作を取得し、該第７操作に応答して、前記第１アプリケーションの前記リサイクルビン画面上で、前記ユーザによって選択された前記第１ファイルを表示するステップと
を更に実行してよく、このとき、ユーザによって選択されなかったファイルについては、それらのファイルは永久削除されてよい。

本願の第２の態様及び第２の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第２の態様の第７の実施では、前記第２操作に応答して、前記プロセッサは、次のプロシージャ：
前記第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、前記第１ファイルのファイル名を第１名称から第２名称へ変更するステップを実行すること
を更に実行してよく、このとき、前記第２ディレクトリは、前記第１アプリケーションの前記リサイクルビン画面上で表示されるファイルを記憶するために使用される。前記第１ファイルの前記記憶場所を前記第１ディレクトリから前記第２ディレクトリへ変更した後に、当該モバイル端末は、前記リサイクルビン画面上で前記第１ファイルを表示することができる。

本願の第２の態様の第７の実施を参照して、本願の第２の態様の第８の実施では、前記第２名称は、前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによって取得されるターゲット文字列である。

本願の第２の態様の第８の実施を参照して、本願の第２の態様の第９の実施では、当該モバイル端末は、次の方法で前記第２データテーブルを生成してよい：
前記前もってセットされた符号化方式を使用して前記第２名称を復号することによって前記第１ファイルの前記メタデータを取得し、復号化を通じて取得された前記メタデータに基づき前記第２データテーブルを生成する。

本願の第２の態様の第７の実施を参照して、本願の第２の態様の第１０の実施では、前記第２名称は、前記第１ファイルの前記削除時間であり、
当該モバイル端末は、
前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによってターゲット文字列を取得し、該ターゲット文字列及び前記第１ファイルの前記削除時間を前記第２ディレクトリのバイナリファイルにおいて対応付けて格納するステップ
を更に実行する。

本願の第２の態様の第１０の実施を参照して、本願の第２の態様の第１１の実施では、前記プロセッサは、次の方法で前記第２データテーブルを生成してよい：
前記第２名称に基づき前記第１ファイルの前記削除時間を決定し、前記バイナリファイルにおいて前記削除時間に対応するターゲット文字列を決定し、前記前もってセットされた符号化方式を使用して前記ターゲット文字列を復号することによって前記第１ファイルの前記メタデータを取得し、復号化を通じて取得された前記メタデータに基づき前記第２データテーブルを生成する。

本願の第２の態様及び第２の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第２の態様の第１２の実施では、当該モバイル端末は、第３データテーブルを取得するように、前記第１データテーブルを削除する前に該第１データテーブルをバックアップしてよく、前記第１データテーブルを削除した後に、当該モバイル端末は、前記第３データテーブルに基づき前記第２データテーブルを生成する。

本願の第３の態様は、モバイル端末を提供し、このとき、当該モバイル端末は、
第１操作に応答して、第１アプリケーションの第１画面上で第１ファイルを表示するよう構成される表示モジュールと、
前記第１画面上でユーザが入力した第２操作を取得するよう構成される取得モジュールであり、
前記表示モジュールが、前記第２操作に応答して、前記第１アプリケーションのリサイクルビン画面上で前記第１ファイルを表示するよう更に構成される、前記取得モジュールと、
第１データテーブルを削除するよう構成される削除モジュールであり、前記第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなり、
前記取得モジュールが、前記ユーザが入力した第３操作を取得するよう更に構成される、前記削除モジュールと、
前記第３操作に応答して第２データテーブルを生成するよう構成される生成モジュールであり、前記第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見える、前記生成モジュールと
を含む。

本願の第３の態様を参照して、本願の第３の態様の第１の実施では、前記取得モジュールが前記第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記取得モジュールが前記第２操作を取得した後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属し、
前記生成モジュールが前記第２データテーブルを生成した後に、
前記表示モジュールは、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するよう更に構成され、
前記取得モジュールは、前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得するよう更に構成され、
前記表示モジュールは、前記第４操作に応答して、前記第１アプリケーションの第１アルバムに対応する画面上で前記第１ファイルを表示するよう構成され、このとき、
前記取得モジュールが前記第４操作を取得した後に、前記第１ファイルは、前記第１アプリケーションの前記第１アルバムに属する。

本願の第３の態様を参照して、本願の第３の態様の第２の実施では、前記取得モジュールが前記第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、前記取得モジュールが前記第２操作を取得した後に、前記第１ファイルは、前記第１アプリケーションのリサイクルビンアルバムに属し、
前記生成モジュールが前記第２データテーブルを生成した後に、
前記表示モジュールは、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するよう更に構成され、
前記取得モジュールは、前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得するよう更に構成され、
前記表示モジュールは、前記第４操作に応答して、前記第１アプリケーションのターゲットアルバムに対応する画面上で前記第１ファイルを表示するよう更に構成され、このとき、
前記取得モジュールが前記第４操作を取得した後に、前記第１ファイルは、前記第１アプリケーションの前記ターゲットアルバムに属する。

本願の第３の態様を参照して、本願の第３の態様の第３の実施では、前記生成モジュールが前記第２データテーブルを生成した後に、
前記表示モジュールは、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するよう更に構成され、
前記取得モジュールは、前記リサイクルビン画面上で前記ユーザが入力した第５操作を取得するよう更に構成され、
前記削除モジュールは、前記第５操作に応答して、前記第１ファイルを当該モバイル端末から削除するよう更に構成される。

本願の第３の態様を参照して、本願の第３の態様の第４の実施では、前記生成モジュールが前記第２データテーブルを生成した後に、
前記取得モジュールは、前記ユーザが入力した第６操作を取得するよう更に構成され、
前記表示モジュールは、前記第６操作に応答して、前記第１ファイルのメタデータを表示するよう更に構成され、このとき、前記メタデータは、次のもの：前記第１ファイルのオリジナルのファイル名、前記第１ファイルのオリジナルのファイル識別子、前記第１ファイルの削除時間、前記第１ファイルのソース記憶パス、前記第１ファイルの現在の記憶パス、前記第１ファイルの撮影時間、前記第１ファイルのピクチャ方向、前記第１ファイルのクラウドグローバル一意識別子、前記第１ファイルのハッシュ値、及び前記第１ファイルが属するソースアルバムのクラウド識別子、のうちの少なくとも１つを含む。

本願の第３の態様を参照して、本願の第３の態様の第５の実施では、
前記表示モジュールは、前記第３操作に応答して、前記第１アプリケーションの前記リサイクルビン画面上で、前記第１ファイルと同じであって且つクラウドサーバに記憶されているファイルである第２ファイルを表示することをスキップするよう更に構成される。

本願の第３の態様を参照して、本願の第３の態様の第６の実施では、前記生成モジュールが前記第２データテーブルを生成した後に、
前記表示モジュールは、選択画面を表示するよう更に構成され、
前記取得モジュールは、前記選択画面上で前記ユーザが入力した第７操作を取得するよう更に構成され、
前記表示モジュールは、前記第７操作に応答して、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するよう更に構成される。

本願の第３の態様及び本願の第３の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第３の態様の第７の実施では、当該モバイル端末は、
前記第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、前記第１ファイルのファイル名を第１名称から第２名称へ変更するよう構成される処理モジュールを更に含み、
前記第２ディレクトリは、前記第１アプリケーションの前記リサイクルビン画面上で表示されるファイルを記憶するために使用される。

本願の第３の態様の第７の実施を参照して、本願の第３の態様の第８の実施では、前記第２名称は、前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによって取得されるターゲット文字列である。

本願の第３の態様の第８の実施を参照して、本願の第３の態様の第９の実施では、前記生成モジュールは、前記前もってセットされた符号化方式を使用して前記第２名称を復号することによって前記第１ファイルの前記メタデータを取得し、該メタデータに基づき前記第２データテーブルを生成するよう特に構成される。

本願の第３の態様の第７の実施を参照して、本願の第３の態様の第１０の実施では、前記第２名称は、前記第１ファイルの前記削除時間であり、
当該モバイル端末は、
前もってセットされた符号化方式を使用して前記第１ファイルの前記メタデータを符号化することによってターゲット文字列を取得し、該ターゲット文字列及び前記第１ファイルの前記削除時間を前記第２ディレクトリのバイナリファイルにおいて対応付けて格納するよう構成される処理モジュール
を更に含む。

本願の第３の態様の第１０の実施を参照して、本願の第３の態様の第１１の実施では、前記生成モジュールは、前記第２名称に基づき前記第１ファイルの前記削除時間を決定し、前記バイナリファイルにおいて前記第１ファイルの前記削除時間に対応する前記ターゲット文字列を決定し、前記前もってセットされた符号化方式を使用して前記ターゲット文字列を復号することによって前記第１ファイルの前記メタデータを取得し、該メタデータに基づき前記第２データテーブルを生成するよう特に構成される。

本願の第３の態様及び本願の第３の態様の第１乃至第６の実施のうちのいずれか１つを参照して、本願の第３の態様の第１２の実施では、当該モバイル端末は、
第３データテーブルを取得するよう前記第１データテーブルをバックアップするよう構成されるバックアップモジュールを更に含み、
前記生成モジュールは、前記第３データテーブルに基づき前記第２データテーブルを生成するよう特に構成される。

本願の第４の態様は、命令を含むコンピュータ可読記憶媒体を提供する。前記命令がコンピュータで実行されるときに、該コンピュータは、上記の方法を実行する。

本願の第５の態様は、命令を含むコンピュータプログラム製品を提供する。当該コンピュータプログラム製品がコンピュータで実行されるときに、該コンピュータは、上記の方法を実行する。

本願の実施形態では、リサイクルビンデータテーブルが削除された後に、モバイル端末は、新しいリサイクルビンデータテーブルを生成することができ、それにより、モバイル端末は、アプリケーションデータがクリアされた後にリサイクルビン画面上で第１ファイルを依然として表示することができ、そして、ユーザは、リサイクルビン画面上で第１ファイルを永久削除又は回復することができ、それによってユーザエクスペリエンスが改善される。

マルチメディアファイルの管理画面の概略図である。 マルチメディアファイルの管理画面の別の概略図である。 マルチメディアファイルの管理画面上でユーザが削除命令を入力する概略図である。 マルチメディアファイルの管理画面上でユーザが削除命令を入力する別の概略図である。 モバイル端末が第１ファイルをソースディレクトリからリサイクルビンディレクトリへ移動する概略図である。 第１ファイルが削除された後のマルチメディアファイル管理画面の概略図である。 第１ファイルが削除された後のリサイクルビン画面の概略図である。 ユーザがモバイル端末上で第１アプリケーションのデータを削除する命令を入力する概略図である。 マルチメディア管理アプリケーションを起動するためにユーザによって入力される命令の概略図である。 アプリケーションデータが削除された後のリサイクルビンに対応する操作画面の概略図である。 本願の実施形態に従うファイル処理方法の実施形態のフローチャートである。 本願の実施形態に従ってモバイル端末が第１ファイルを第１ディレクトリから第２ディレクトリへ移動する概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルを第１ディレクトリから第２ディレクトリへ移動する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルを第１ディレクトリから第２ディレクトリへ移動する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルを第１ディレクトリから第２ディレクトリへ移動する別の概略図である。 本願の実施形態に従うバイナリファイルの概略図である。 本願の実施形態に従う選択画面の概略図である。 本願の実施形態に従ってモバイル端末がリサイクルビン画面上で第１ファイルを表示する概略図である。 本願の実施形態に従ってモバイル端末がリサイクルビン画面上で第１ファイルを表示する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルのメタデータを表示する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルのメタデータを表示する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルのメタデータを表示する別の概略図である。 本願の実施形態に従ってリサイクルビン画面上でユーザが回復命令を入力する概略図である。 本願の実施形態に従ってリサイクルビン画面上でユーザが回復命令を入力する別の概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルを第２ディレクトリからターゲットディレクトリへ移動する概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルをターゲットアルバムに回復する概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルを第２ディレクトリから第１ディレクトリへ移動する概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルをソースアルバムに回復する概略図である。 本願の実施形態に従ってリサイクルビン画面上でユーザが削除命令を入力する概略図である。 本願の実施形態に従ってリサイクルビン画面上でユーザが削除命令を入力する概略図である。 本願の実施形態に従ってモバイル端末が第１ファイルをモバイル端末から削除する概略図である。 本願の実施形態に従うモバイル端末の実施形態の概略図である。 本願の実施形態に従うモバイル端末の別の実施形態の概略図である。

以下は、本願の実施形態における添付の図面を参照して、本願の実施形態における技術的解決法について記載する。明らかに、記載されている実施形態は一部にすぎず、本願の実施形態の全てではない。

本願の明細書、特許請求の範囲、及び添付の図面において、語「第１」、「第２」、「第３」、「第４」、（もしあれば）などは、類似した対象を区別することを目的としているが、必ずしも具体的な順位又は順序を示すものではない。そのように称されるデータは、適切な状況で互いに交換でき、それにより、ここで記載される実施形態は、ここで図解又は記載されている順序とは別の順序で実施可能であることが理解されるべきである。更に、語「含む」、「包含する」及び任意の他の変形は、非排他的な包含を網羅するものである。例えば、ステップ又はユニットの一覧を含むプロセス、方法、システム、製品、又はデバイスは、明示的にリストアップされているそれらのステップ又はユニットに必ずしも制限されず、明示的にリストアップされていない又はそのようなプロセス、方法、システム、製品、若しくはデバイスに内在する他のステップ又はユニットを含んでもよい。本願の実施形態の理解を助けるために、以下は、本願の実施形態で使用される語について記載する。

メタデータ：中間データ又は中継データとも呼ばれ、メタデータは、データに関するデータ（data about data）、主として、データの性質（property）について記載する情報であり、記憶場所指示、過去のデータ、リソース探索、及びファイル記録のような機能をサポートするために使用される。メタデータは電子ディレクトリである。ディレクトリをコンパイルする目的で、データの内容又は特性は、データ検索を支援するために、記載及び収集される必要がある。

本発明の実施形態では、ピクチャ又はビデオのメタデータは、次のもの：ファイル名拡張子、ファイル名（display name）、削除時間（recycled time）、ファイル識別子（local media identifier）、現在の記憶パス、ソース記憶パス（source path）、撮影時間（date taken）、ピクチャ方向（orientation）、ソースアルバムのクラウド識別子（album identifier）、ファイルのハッシュ値（hash）、ファイルのクラウドグローバル一意識別子（cloud globally unique identifier，Cloud GUID）、及び撮影場所、のうちの１つを含んでよい。

オリジナルのファイル名は、モバイル端末が第２操作を取得する前の第１ファイルのファイル名である。オリジナルのファイル識別子は、モバイル端末が第２操作を取得する前の第１ファイルの、対応するデータテーブル内の識別子である。ソース記憶パスは、モバイル端末が第２操作を取得する前の第１ファイルの記憶パスである。現在の記憶パスは、モバイル端末が第６操作を取得するときの第１ファイルの記憶パスである。ソースアルバムは、モバイル端末が第２操作を取得する前に第１ファイルが属するアルバムである。

アルバム：ピクチャ管理アプリケーションが、モバイル端末でピクチャ及びビデオを管理するために使用される。いくつかのピクチャ管理アプリケーションは、モバイル端末内のピクチャ及びビデオを、如何にしてピクチャ及びビデオが取得されるかに基づき、管理のための複数のグループに分類する。ピクチャ又はビデオが属するアルバムは、ピクチャ又はビデオが属するグループである。例えば、微信アプリケーションからダウンロードされたピクチャ及びビデオは、両方ともが微信アルバムに属するように、１つのグループに分類され、カメラアプリケーションから取得されたピクチャ及びビデオは、両方ともがカメラアルバムに属するように、１つのグループに分類される。

リサイクルビンアルバムは特別なグループである。ピクチャ管理アプリケーションにおいてユーザによって削除されたピクチャ又はビデオは、元のグループからこのグループへ移動される。すなわち、ピクチャ及びビデオが属するアルバムは、ソースアルバムからリサイクルビンアルバムへ変更される。いくつかの実施形態では、リサイクルビンアルバムは、最近削除アルバム、削除アルバム、又は他の名称でも呼ばれることが理解されるべきである。これは、本願において特に制限されない。

その上、本願の以下の実施形態では、「第１ファイルは第１アプリケーションの第１アルバムに属する」のような記述が存在することが留意されるべきである。ここでの「～に属する」は、ユーザが第１アプリケーション（例えば、アルバムアプリケーション）を起動し、アルバムをタップした後に、第１ファイルがそのアルバムにおいて提示されるように理解され得る。ユーザ認知という意味で、ユーザは第１アルバムにおいて第１ファイルを見ると理解され得る。

ピクチャ管理アプリケーションは、アルバム単位でグループにおいてピクチャ及びビデオを表示しても、あるいは、取得場所又は取得時間ごとにピクチャ及びビデオを表示してもよいことが理解されるべきである。

リサイクルビン：本願の実施形態におけるリサイクルビンは、ピクチャ及びビデオのような削除されたマルチメディアファイルが属するグループを指す。リサイクルビンは、ローカルリサイクルビン及びクラウドリサイクルビンに分類され得ることが理解されるべきである。ローカルリサイクルビンは、モバイル端末からローカルで削除されたマルチメディアファイルを管理するためにユーザによって使用され、クラウドリサイクルビンは、クラウドサーバから削除されたマルチメディアファイルを管理するためにユーザによって使用される。モバイル端末がクラウドサーバへ接続される場合に、ユーザは、マルチメディアファイルをローカルリサイクルビンからクラウドリサイクルビンへアップロードすることができ、マルチメディアファイルをクラウドリサイクルビンからローカルリサイクルビンへダウンロードしてもよい。

アプリケーションデータ：本願の実施形態におけるアプリケーションデータは、アプリケーションの実行過程で記録されるデータである。例えば、通信アプリケーションの場合に、通信アプリケーションのアプリケーションデータは、ユーザアカウント情報、チャット履歴、などを含んでよく、ブラウザアプリケーションの場合に、ブラウザアプリケーションのアプリケーションデータは、閲覧履歴、検索履歴、などを含んでよく、メディア管理アプリケーションの場合に、メディア管理アプリケーションのアプリケーションデータは、ユーザによってマルチメディアファイルを管理する過程で生成された記録、例えば、ユーザによるマルチメディアファイルの分類記録、ユーザによるマルチメディアファイルの変更履歴、及び各マルチメディアファイルに対応するメタデータ情報を含んでよい。

ファイル名拡張子：ファイルの拡張子とも呼ばれ、ファイル名拡張子は、オペレーティング・システムがファイルタイプを識別するために使用されるメカニズムである。一般に、拡張子は、メインファイル名の後に続き、セパレータによりメインファイル名から区切られる。例えば、「example.txt」のようなファイル名では、exampleがファイル名であり、txtが拡張子であって、このファイルが純粋なテキストファイルであることを示す。

データテーブル：本願のデータテーブルは、メディア管理アプリケーションにおけるキャリアであって、メディア管理アプリケーションによって管理されるマルチメディアファイルのメタデータを記録するために使用される。メディア管理アプリケーションは、データテーブルに記録されているメタデータに基づきマルチメディアファイルを提示する。

ファイル識別子（local media identifier）：実施形態におけるファイル識別子は、データテーブル内のマルチメディアファイルの識別子である。１つのデータテーブルにおいて、異なるマルチメディアファイルは、異なる識別子に対応している。本願のいくつかの実施形態では、オリジナルのファイル識別子は、ファイル名の一意性を確保するために、命名のために使用される。オリジナルのファイル識別子は、第２操作がユーザによって入力される前のデータテーブル内の識別子である。

ディレクトリ：本願の実施形態におけるディレクトリは、マルチメディアファイルがモバイル端末上で記憶されるフォルダである。第１ディレクトリは、マルチメディアファイルが削除される前に記憶されるディレクトリであり、第２ディレクトリは、ローカルリサイクルビンに対応するマルチメディアファイルを記憶するために使用されるディレクトリである。キー／値ペア（key-value）：データ記憶の形式。キー（key）は、記憶されている値の数を表し、値（value）は、記憶される必要があるデータを表す。一意の対応値がキーに基づき取得され得る。本願では、ターゲット文字列が値として使用され、削除時間がキーとして使用され、一意の対応するターゲット文字列が、削除時間を使用することによって見つけられ得る。

Ｂａｓｅ６４：Ｂａｓｅ６４は、インターネット上で８ビットのバイトコードを送信するために使用される最も一般的な符号化方式の１つである。Ｂａｓｅ６４は、６４個の印刷可能な文字に基づきバイナリデータを表す方法である。Ｂａｓｅ６４の符号化規則は、次の通りである：（１）３つの文字を４つの文字に変換すること、（２）７６文字ごとに改行を加えること、及び（３）最後に終端文字を表示すること。

マルチメディアデータベース：携帯電話機においてマルチメディアファイル（オーディオ、ビデオ、及びピクチャを含む。）を記憶するために使用されるデータベース。携帯電話機が起動されるときに、メディアスキャナサービス（Media Scanner Service）プロセスが起動されて、携帯電話機内でjpg又はmp4の拡張子を持ったマルチメディアファイルを探し、それらのマルチメディアファイルに関する情報をマルチメディアデータベースに加える。携帯電話機上のアプリケーションプログラムは、必要なマルチメディア情報をマルチメディアデータベースからフェッチする。

ユーザによって電話機メモリを管理することの容易さを促すために、多数の携帯電話機は、データ削除機能を与えられており、ユーザは、より多くの記憶空間を解放するために、携帯電話機のシステム設定を通じていくつかのアプリケーションのデータをキャッシュすること及び／又はアプリケーションデータを削除することができる。ユーザが、システム設定を通じて、ピクチャ管理アプリケーション（例えば、ギャラリーアプリケーション又はアルバムアプリケーション）のアプリケーションデータをクリアした後に、ユーザがピクチャ管理アプリケーションを再起動するとき、ピクチャ管理アプリケーションは、マルチメディアデータベースから、携帯電話機に記憶されているピクチャ及びビデオのメタデータを取得し、取得されたメタデータに基づきピクチャ管理アプリケーションにおいて携帯電話機内のピクチャ及びビデオを表示する。

しかし、リサイクルビンアルバムへ移動されるピクチャ及びビデオについては、第三者アプリケーションによる表示を防ぐために、ピクチャ及びビデオがリサイクルビンアルバムへ移動されるとき、ピクチャ管理アプリケーションは、ピクチャ及びビデオのフォーマットに対して特別な処理、例えば、jpg及びmp4のような拡張子を取り外すこと、を実行する。ユーザがピクチャ管理アプリケーションのアプリケーションデータをクリアした後に、ユーザがピクチャ管理アプリケーションを再起動するとき、たとえリサイクルビンアルバム内のピクチャ及びビデオが依然としてシステム内に保持されているとしても、メディアスキャナサービスプロセスは、拡張子がjpg又はmp4でないファイルを見つけることができないので、ピクチャ管理アプリケーションは、メディアデータベースからリサイクルビンアルバム内のピクチャ及びビデオのメタデータを取得することができず、ピクチャ管理アプリケーションにおいてリサイクルビンアルバムに対応するデータテーブルを再構成することができない。従って、ピクチャ管理アプリケーションは、リサイクルビンアルバム内のピクチャ及びビデオを表示することができず、リサイクルビンアルバム内のピクチャ及びビデオを永久削除又は回復することもできない。結果として、ユーザエクスペリエンスは妥協され、システム記憶空間は占有される。

本願の実施形態は、アプリケーションデータがクリアされた後にリサイクルビン画面上でマルチメディアファイルを表示して、ユーザがリサイクルビン画面上でマルチメディアファイルを永久削除又は回復することができるようにし、それによってユーザエクスペリエンスを改善するファイル処理方法及びモバイル端末を開示する。

本願の実施形態の容易な理解のために、以下は、本願のファイル処理方法及びモバイル端末が適用可能であるシナリオについて簡単に記載する。

本願の実施形態におけるモバイル端末は、携帯電話機、タブレットコンピュータ、電子リーダー、携帯型ゲーム機、又は車載用電子機器のような電子機器を含むが限られない。オペレーティング・システムは、例えば、Ａｎｄｒｏｉｄ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ、ＢｌａｃｋＢｅｒｒｙ、又はｉＯＳシステムであってよい。これは、本願の実施形態において特に制限されない。本願の実施形態における端末は、リサイクルビン機能を設けられることが留意されるべきである。

本願の実施形態におけるマルチメディアファイルは、写真、映像、又は音声ファイルのようなファイルを含むが限られない。

本願の実施形態におけるマルチメディア管理アプリケーションは、具体的に、ピクチャ管理アプリケーション（例えば、ギャラリーアプリケーション若しくはアルバムアプリケーション）、又はオーディオファイル管理アプリケーション（レコーダーアプリケーションなど）、あるいは、マルチメディアファイルを管理するために使用される他のアプリケーションであってよい。これは、本願の実施形態において特に制限されない。

いくつかの解決法では、モバイル端末はいくつかのマルチメディアファイルを記憶し、マルチメディア管理アプリケーションは、それらのマルチメディアファイルを管理するために使用されるアプリケーションであり、データテーブルを使用することによってそれらのマルチメディアファイルに対応するメタデータを記録する。具体的に、マルチメディア管理アプリケーションは、リサイクルビン機能をサポートし、マルチメディア管理アプリケーションに対応するデータテーブルは、非リサイクルビンデータテーブル及びリサイクルビンデータテーブルを含む。非リサイクルビンデータテーブルは、非リサイクルビンに対応するマルチメディアファイルのメタデータ（例えば、ファイル名、記憶パス、撮影時間、及びピクチャ方向）を記録するために使用され、リサイクルビンデータテーブルは、リサイクルビンデータテーブル内のマルチメディアファイルのメタデータ（例えば、ソース記憶パス、削除時間、撮影時間、及びピクチャ方向）を記録するために使用される。表１は、非リサイクルビンデータテーブルの例であり、表は、カメラアルバムに対応する8つのマルチメディアファイルのメタデータを記録する。

モバイル端末は、マルチメディア管理アプリケーションを開く命令を受け取り、図１Ａ又は図１Ｂに示されるようなマルチメディアファイル管理画面を提示する。ユーザは、図１Ｃ又は図１Ｄで示されるように、マルチメディアファイル管理画面上で削除命令を入力する。ユーザは、マルチメディアファイル管理画面上で、削除される必要があるマルチメディアファイルを選択し、次いで、選択されたマルチメディアファイルを削除するために削除アイコンをタップする。削除命令を受け取った後、モバイル端末は、削除されるマルチメディアファイルの拡張子を取り外し、削除されるマルチメディアファイルをソースディレクトリからリサイクルビンディレクトリへ移動し（図１Ｅに図示あり。）、削除されるマルチメディアファイルに対応するメタデータを非リサイクルビンデータテーブルから除去する。メタデータを除去された非リサイクルビンデータテーブルが、表２に記載される。その上、リサイクルビンディレクトリへ移動されるマルチメディアファイル（すなわち、削除されるマルチメディアファイル）に対応するメタデータは、リサイクルビンデータテーブルに加えられる。メタデータを加えられたリサイクルビンデータテーブルが、表３に記載される。

ユーザがマルチメディアファイル管理画面上で削除命令を入力した後に、削除されるマルチメディアファイルは、図１Ｆに示されるように、モバイル端末によって提示されるマルチメディアファイル管理画面上に含まれない。モバイル端末が、リサイクルビンを開く命令を受け取るとき、モバイル端末は、図１Ｇに示されるように、リサイクルビンに対応する画面上で、削除されるマルチメディアファイルを提示する。ユーザは、この操作画面上でマルチメディアファイルを回復又は永久削除してよい。

モバイル端末は、図１Ｈに示されるように、メディア管理アプリケーションに対するクリアアプリケーションデータ命令を受け取る。モバイル端末は、メディア管理アプリケーションのアプリケーションデータをクリアする。クリアされるアプリケーションデータは、少なくとも、メディア管理アプリケーションの非リサイクルビンデータテーブル及びリサイクルビンデータテーブルを含む。

モバイル端末がメディア管理アプリケーションのアプリケーションデータをクリアした後に、モバイル端末は、メディア管理アプリケーションを起動する命令を受け取る。命令は、具体的に、図１Ｉに示されるように、ユーザによって、第１アプリケーションのアプリケーションアイコンをタップすることによってトリガされてよく、あるいは、ユーザによって、他のアプリケーションにおいて第１アプリケーションへのインターフェイスをタップすることによってトリガされてよく、あるいは、特定の条件でモバイル端末によって自動的にトリガされてよい。これは、ここで特に制限されない。

モバイル端末がメディア管理アプリケーションを起動した後に、いくつかの解決法では、モバイル端末は、モバイル端末内のマルチメディアファイルのメタデータをメディアデータベースからフェッチし、メタデータに基づきマルチメディア管理アプリケーションのデータテーブルを構築する。リサイクルビンに対応するディレクトリ（例えば、図１ＥのＢＩＮディレクトリ）内のマルチメディアファイルはファイル名拡張子を含まないので、メディアスキャナサービスプロセスは、リサイクルビンに対応するディレクトリ内のマルチメディアファイルを見つけることができない。メディアデータベースは、リサイクルビンに対応するディレクトリ内のマルチメディアファイルを含まず、従って、マルチメディア管理アプリケーションの構築されるデータテーブルは、リサイクルビンデータテーブル内のマルチメディアファイルのメタデータを含まない。この解決法では、メディア管理アプリケーションのアプリケーションデータがクリアされた後に、メディア管理アプリケーションが再起動されるとき、且つ、リサイクルビンを開く命令が受け取られるとき、図１Ｊに示されるように、モバイル端末によって提示されるリサイクルビン画面上には、マルチメディアファイルは表示されない。

本願のこの実施形態では、モバイル端末がマルチメディアファイルに対する削除命令を受け取った後に、削除されるマルチメディアファイルをソースディレクトリからリサイクルビンディレクトリへ移動する過程で、モバイル端末は、削除されるマルチメディアファイルのメタデータを取り出して記憶し、削除されるマルチメディアファイルの名前を付け替える。メディア管理アプリケーションのアプリケーションデータがクリアされた後に、モバイル端末は、非リサイクルビンデータテーブル及びリサイクルビンデータテーブルを再構成し、次いで、非リサイクルビンデータテーブル及びリサイクルビンデータテーブルに基づきメディア管理アプリケーションにおいてリサイクルビンアルバム及び非リサイクルビンアルバム内のマルチメディアファイルを表示することができる。

上記の例となるシナリオに基づき、以下は、本願の実施形態においてモバイル端末によってマルチメディアファイルの名前を付け替え、リサイクルビンデータテーブルを再構成するプロセスについて詳細に記載する。図２を参照すると、本願のこの実施形態におけるファイル処理方法の実施形態は、次のステップを含む。

２０１．モバイル端末は、ユーザが入力した第１操作を取得し、第１操作に応答して、第１アプリケーションの第１画面上で第１ファイルを表示する。具体的に、ユーザは、第１アプリケーションのアイコンをタップし、操作に応答して、モバイル端末は、第１アプリケーションを起動し、第１アプリケーションの第１画面上で第１ファイルを表示する。第１アプリケーションはマルチメディア管理アプリケーションであり、第１画面はマルチメディアファイルの管理画面である。管理画面は、マルチメディアファイルに対する編集、削除、及び分類のような操作のための機能ボタンを提供することができる。第１画面は、図１Ａに示されるような、複数のマルチメディアファイル（第１ファイルを含む。）のための管理画面、又は図１Ｂに示されるような、第１ファイルのための管理画面であってよい。これは、ここで特に制限されない。

２０２．モバイル端末は、第１画面上でユーザが入力した第２操作を取得し、第２操作に応答して、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示する。

具体的に、第２操作は、図１Ｃ又は図１Ｄに示されるような、第１ファイルに対する単一の削除命令、又は複数の第１ファイルに対するバッチ削除命令であってよい。例えば、図１Ｃに示されるシナリオでは、ユーザは、複数のマルチメディアファイルを選択してよく、複数のマルチメディアファイルに対する削除命令を開始するように削除アイコンをタップする。

削除命令を受け取った後に、モバイル端末は、第１ファイルを第１ディレクトリから第２ディレクトリへ移動する、すなわち、第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更する。第１ディレクトリは、ユーザが削除命令を入力する前に第１ファイルが記憶されているディレクトリである。第２ディレクトリは、リサイクルビン画面上で表示されるファイルを記憶するために使用されるディレクトリである。第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、第１ディレクトリの名前を付け替える、すなわち、第１ファイルのファイル名を第１名称から第２名称へ変更し、更には、第１ファイルのメタデータを取り出して記憶する。

モバイル端末が第１ファイルを第２ディレクトリへ移動した後に、モバイル端末は、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示可能であることが留意されるべきである。図１Ｇに示されるように、ユーザは、第１アプリケーションのアルバム選択画面からリサイクルビンアルバムを選択し、モバイル端末は、命令に従ってリサイクルビン画面を表示し、このとき、画面には、第１ファイルに対応するサムネイルが含まれる。リサイクルビン画面を開く命令は、図１Ｇに示される形式に制限されず、リサイクルビン画面上での第１ファイルの表示形式も、図１Ｇに示される形式に制限されないことが理解されるべきである。

具体的に、この実施形態のこの応用では、モバイル端末によって取り出されるメタデータは、第１ファイルのオリジナルのファイル名のファイル名抽出を少なくとも含む必要がある。具体的に、回復の程度に応じて、モバイル端末によって取り出されるメタデータは、次のもの：オリジナルのファイル名（第１名称）のメインファイル名、オリジナルのファイル識別子、削除時間、リサイクルビンファイルパス、第１ファイルのソース記憶パス、撮影時間、ピクチャ方向、第１ファイルが属するソースアルバムのクラウド識別子、第１ファイルのハッシュ値、及び第１ファイルのクラウドグローバル一意識別子、のうちの１つ以上を更に含んでもよい。取り出されたメタデータは、第１ファイルの第２名称で記憶されてよく、第２ディレクトリ内で新たに構築されたバイナリファイルに格納されてよく、あるいは、他の記憶空間に格納されてよい。これは、この実施形態において特に制限されない。

オリジナルのファイル識別子は、第１ファイルが削除される前の非リサイクルビンデータテーブル内の第１ファイルのファイル識別子であることが理解されるべきである。リサイクルビンファイルパスは、リサイクルビン画面上で表示されるマルチメディアファイルに対応する記憶パスである。ソース記憶パスは、第１ファイルが削除される前に第１ファイルが記憶されている場所である。第１ファイルが属するソースアルバムのクラウド識別子は、第１ファイルが削除される前に第１ファイルが属するアルバムの、クラウドサーバ内のアルバム識別子である。第１ファイルのクラウドグローバル一意識別子は、クラウドサーバ内の第１ファイルの識別子である。

以下は、そのいくつかの記憶方法について記載する。

方法１．第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、乱数を生成し、取り出されたメタデータ及び乱数をスプライシングして文字列を取得し、その文字列を第２ディレクトリ内の第１ファイルのファイル名（第２名称）として使用する、すなわち、メタデータと乱数とを組み合わせて記憶する。モバイル端末の取り出されたメタデータは、第１名称のファイル名拡張子である。例えば、モバイル端末によって生成される乱数は「4531265」であり、第１ディレクトリ内の第１ファイルのファイル名（第１名称）は「photo3.jpg」である。モバイル端末は、第１名称のファイル名拡張子「jpg」を取り出し、ファイル名拡張子及び乱数をスプライシングして文字列「jpg4531265」を取得する。モバイル端末は、第１ファイルの名前を「jpg4531265」と付け替える。

方法２．第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、事前設定された符号化方式を使用することによって、取り出されたメタデータを符号化して、ターゲット文字列を取得し、ターゲット文字列を第２ディレクトリ内の第１ファイルのファイル名（第２名称）として設定する、すなわち、符号化を通じて第２名称でメタデータの単片を記憶する。モバイル端末によって取り出されるメタデータは、第１ディレクトリ内の第１ファイルのファイル名、すなわち、オリジナルのファイル名である。図１Ｃ又は図１Ｄに対応するシナリオが、説明のために例として使用される。第１ファイルのオリジナルのファイル名（第１名称）は「photo3.jpg」であり、ターゲット文字列「55u454mHMy5qcGc=」が、Ｂａｓｅ６４符号化を使用することによって取得され、モバイル端末は、第１ファイルの名前を「55u454mHMy5qcGc=」と付け替える。

方法３．第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、取り出されたメタデータの複数片をスプライシングすることによって取得される文字列が、第２ディレクトリ内の第１ファイルのファイル名（第２名称）として使用される、すなわち、スプライシングされたメタデータの複数片が第２名称で記憶される。

任意に、いくつかの実施形態で、方法３においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名及び第１ファイルのオリジナルのファイル識別子である。

任意に、いくつかの実施形態で、方法３においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名及び第１ファイルの削除時間である。

任意に、いくつかの実施形態で、方法３においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名、第１ファイルのオリジナルのファイル識別子、及び第１ファイルの削除時間である。

以下は、図１Ｃ又は図１Ｄに対応するシナリオを説明のための例として使用する。第１ファイルのオリジナルのファイル名（第１名称）は「photo3.jpg」であり、オリジナルのファイル識別子は「0003」であり、削除時間は「20170116」である。モバイル端末によってメタデータのそれらの片をスプライシングすることで取得される文字列は、「0003photo3.jpg20170116」である。モバイル端末は、図３Ａに示されるように、第１ファイルの名前を「0003photo3.jpg20170116」と付け替える。

方法４．第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、最初に、複数の取り出されたメタデータをスプライシングして文字列を取得し、事前設定された符号化方式を使用することによって文字列を符号化してターゲット文字列を取得し、ターゲット文字列を第２ディレクトリ内の第１ファイルのファイル名（第２名称）として使用する、すなわち、符号化を通じて第２名称で複数のスプライシングされたメタデータを記憶する。事前設定された符号化方式は、Ｂａｓｅ６４又は他の方式を含んでよく、これは、ここで特に制限されない。

任意に、この実施形態では、事前設定された符号化方式を使用して、スプライシングを通じて取得された文字列を符号化する前に、モバイル端末は、最初に、文字列を圧縮し、次いで、圧縮された文字列を符号化してターゲット文字列を取得してよい。

任意に、いくつかの実施形態で、方法４においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名及び第１ファイルのオリジナルのファイル識別子である。

任意に、いくつかの実施形態で、方法４においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名及び第１ファイルの削除時間である。

任意に、いくつかの実施形態で、方法４においてモバイル端末によって取り出されるメタデータの複数片は、第１ファイルのオリジナルのファイル名、第１ファイルのオリジナルのファイル識別子、及び第１ファイルの削除時間である。

方法３に対応する例において、モバイル端末が３片のメタデータをスプライシングすることによって文字列「0003photo3.jpg20170116」を取得した後に、モバイル端末は、Ｂａｓｅ６４符号化を使用することによってターゲット文字列「MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==」を取得し、そして、モバイル端末は、図３Ｂに示されるように、第１ファイルの名前を「MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==」と付け替える。

モバイル端末はファイル名の長さを制限することが留意されるべきである。方法４では、取り出されるメタデータが第１ファイルのオリジナルのファイル名（第１名称）を含み、ファイル名がユーザにより編集可能である場合に、オリジナルのファイル名が比較的に長い文字列を有するとき、スプライシングを通じて取得された文字列又は符号化を通じて取得されるターゲット文字列の文字列長さは、モバイル端末の長さ制限を超える可能性がある。この場合に、スプライシングを通じて文字列を取得する過程で、スプライシングを通じて取得される文字列又は符号化を通じて取得されるターゲット文字列の文字列長さが長さ制限を超えないように、モバイル端末は、オリジナルのファイル名に含まれるメインファイル名の末端部を取り除いてよい。例えば、アンドロイド（Android）では、Ｂａｓｅ６４符号化規則から、オリジナルの文字列に対するＢａｓｅ６４符号化された文字列の文字長さ比は４：３であることが分かる。なお、アンドロイドに基づく携帯電話機は、ファイル名の文字列長さにおいて最大２５６バイトをサポートすることができる。Ｂａｓｅ６４符号化された文字列がこの長さ（２５６バイト）を超えないことを確かにするために、符号化される前に、文字列は１９２バイトを超えるべきではない。すなわち、スプライシングを通じて取得される文字列は、１９２バイトを超えるべきではない。第１ファイルのオリジナルのファイル名（第１名称）は、「私は母と一緒に私たちの家の前で写真を撮影しているwozaitianmnenhemamayiqipaizhaowozaitiananmenhemamayiqipaizhaowozaitianammenhemamayiqipaizhaowozaitianmnenhemamayiqipaizhaowozaitianmnenhemamayiqipaizhaoasaaaanjkhkjhkjh.jpg」であり、第１ファイルのオリジナルのファイル識別子は「0003」であり、第１ファイルの削除時間は「20170116 11:11:03」である。３片のデータをスプライシングすることによって取得される文字列の長さは１９２バイトを超え、モバイル端末は、「私は母と一緒に私たちの家の前で写真を撮影している」を取得するようにオリジナルのファイル名の主たる名称の末端部を取り除き、次いで、切り捨てられたファイル名、オリジナルのファイル識別子、及び削除時間をスプライシングして、文字列「0003私は母と一緒に私たちの家の前で写真を撮影している.jpg20170116 11:11:03」を取得し、この文字列の長さが１９２バイトよりも小さくなるようにする。次いで、文字列は、Ｂａｓｅ６４符号化方式を使用することによって符号化されて、２５６バイトに満たない長さのターゲット文字列が取得される。

方法５．第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、最初に、複数の取り出されたメタデータをスプライシングして文字列を取得し、次いで、事前設定された符号化方式を使用することによって文字列を符号化してターゲット文字列を取得してよい。ターゲット文字列の文字長さがシステム長さ制限を超えない場合に、モバイル端末は、ターゲット文字列を第２ディレクトリ内の第１ファイルのファイル名（第２名称）として決定する。ターゲット文字列の文字長さがシステム長さ制限を超える場合に、キー／値（key-value）法において、モバイル端末はターゲット文字列を値（value）として使用し、メタデータに含まれる削除時間をキー（key）として使用し、第２ディレクトリ内で新たに構築されたバイナリファイルに値及びキーを格納し、削除時間を第２ディレクトリ内の第１ファイルのファイル名（第２名称）として決定する。

任意に、この実施形態では、事前設定された符号化方式を使用することによって符号化を通じて取得された文字列を符号化する前に、モバイル端末は、最初に、文字列を圧縮し、次いで、圧縮された文字列を符号化してターゲット文字列を取得してよい。

任意に、この実施形態では、複数のファイルに対応している値（すなわち、ターゲット文字列）及びキー（すなわち、削除時間）は全て、同じバイナリファイルに格納されてよい。バイナリファイルのファイル名は、如何なる方法でも定義されてよく、これは、この実施形態において制限されない。バイナリファイルのファイル名（すなわち、ファイル名拡張子）は、xml、bin、又は他の拡張子であってよく、これも、この実施形態において特に制限されない。

任意に、いくつかの実施形態で、方法５においてモバイル端末によって取り出されるメタデータの複数片は、削除時間、リサイクルビンファイルパス、ソース記憶パス、撮影時間、及びピクチャ方向である。

任意に、いくつかの実施形態で、方法５においてモバイル端末によって取り出されるメタデータの複数片は、削除時間、リサイクルビンファイルパス、ソース記憶パス、撮影時間、ピクチャ方向、及びクラウドグローバル一意識別子である。

任意に、いくつかの実施形態で、方法５においてモバイル端末によって取り出されるメタデータの複数片は、削除時間、リサイクルビンファイルパス、ソース記憶パス、撮影時間、ピクチャ方向、ソースアルバムのクラウド識別子、及びハッシュ値である。

任意に、いくつかの実施形態で、方法５においてモバイル端末によって取り出されるメタデータの複数片は、削除時間、リサイクルビンファイルパス、ソース記憶パス、撮影時間、ピクチャ方向、ソースアルバムのクラウド識別子、ハッシュ値、及びクラウドグローバル一意識別子である。

以下は、図１Ｃ又は図１Ｄに対応するシナリオを説明のための例として使用する。削除されるマルチメディアファイル（第１ファイル）について、削除時間は、「20170116 11:11:03:01」であり、リサイクルビンファイルパスは「Phone storage＼DCIM＼Bin」であり、ソース記憶パスは「Phone storage＼DCIM＼Camera＼photo3.jpg」であり、撮影時間は「20170102 12:20」であり、ピクチャ方向は「90°」である。文字列「Phone storage＼DCIM＼Bin Phone storage＼DCIM＼Camera＼photo3.jpg 20170116 11:11:03:01 20170102 12:20 90°」が、上記のメタデータをスプライシングすることによって取得され、次いで、文字列は、ターゲット文字列「50mL5py65a2Y5YKoX…（続く文字列は省略される。）」を取得するためにＢａｓｅ６４を使用することによって符号化される。ターゲット文字列の文字長さは２５５バイトに満たず、従って、モバイル端末は、図３Ｃで示されるように、ターゲット文字列を第２名称として決定する。

以下は、別のシナリオを説明のための例として使用する。削除されるマルチメディアファイル（第１ファイル）について、削除時間は、「20170116 11:11:03:01」であり、リサイクルビンファイルパスは「Phone storage＼DCIM＼Bin」であり、ソース記憶パスは「Phone storage＼DCIM＼Camera＼photo3.jpg」であり、撮影時間は「20170102 12:20」であり、ピクチャ方向は「90°」であり、ソースアルバムのクラウド識別子は「464135132428731234534」であり、ハッシュ値は、「8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131rD」であり、第１ファイルのクラウドグローバル一意識別子は「6F9619FF-8B86-D011-B42D-00C04FC964FF」である。文字列が、これらのメタデータ片をスプライシングすることによって取得され、ターゲット文字列（この例でのターゲット文字列の文字長さは比較的に長く、従って、ターゲット文字列はここでは提示されない。記載の容易さのために、「A」がターゲット文字列を表現するために使用される。）は、Ｂａｓｅ６４を使用することによって符号化される。ターゲット文字列「A」の長さは２５５バイトを超え、モバイル端末は、図３Ｅで示されるように、ターゲット文字列をバイナリファイルに値として格納し、第２ディレクトリ内に新たに構築されるバイナリファイル内の値に対応するキーとして削除時間「20170116 11:11:03:01」を格納し、図３Ｄで示されるように、第１ファイルの名前を「20170116 11:11:03:01」と付け替える。

方法６．この実施形態では、モバイル端末は、第３データテーブルを取得するためにリサイクルビンデータテーブル（第１データテーブル）をバックアップする。第３データテーブルは、第１アプリケーションに対応するディレクトリとは異なる別のディレクトリに記憶されてよく、モバイル端末が第１アプリケーションのアプリケーションデータをクリアするときに、第３データテーブルは削除されない。

具体的に、削除命令を受け取った後に、モバイル端末は、非リサイクルビンデータテーブルから第１ファイルのメタデータを削除し、第１ファイルに対応するメタデータをリサイクルビンデータテーブルに加え、リサイクルビンデータテーブル内の第１ファイルに対応する全てのメタデータを第２データテーブルにバックアップする。具体的に言えば、第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で、モバイル端末は、リサイクルビンデータテーブル内の第１ファイルに対応する全てのメタデータを第３データテーブルに格納する。

モバイル端末が削除命令を受け取った後に、上記の方法に加えて、モバイル端末は、代替的に、別の方法で第１ファイルのメタデータを記憶してよく、そして、代替的に、別の方法で第１ファイルの名前を付け替えてよいことが理解されるべきである。これは、本願のこの実施形態において特に制限されない。

また、モバイル端末によってメタデータを取り出して記憶し、第１ファイルの名前を付け替えるプロシージャは、第１ファイルを第１ディレクトリから第２ディレクトリへ移動する過程で実行されても、第１ファイルが第１ディレクトリから第２ディレクトリへ移動される前に実行されても、あるいは、第１ファイルが第１ディレクトリから第２ディレクトリへ移動された後に実行されてもよいことも理解されるべきである。

２０３．モバイル端末は第１データテーブルを削除する。

モバイル端末は、第１アプリケーションに対するクリアアプリケーションデータ命令を取得し、第１アプリケーションのアプリケーションデータを削除する。アプリケーションデータはリサイクルビンデータテーブル（第１データテーブル）を含む。具体的に、クリアアプリケーションデータ命令は、図１Ｈで示されるように、モバイル端末の画面上でユーザが入力した操作によってトリガされてよく、あるいは、オペレーティング・システム又は第１アプリケーションでエラーが起こるときに自動的にトリガされてよい。これは、ここで特に制限されない。

２０４．モバイル端末は、ユーザが入力した第３操作を取得し、第３操作に応答して、第２データテーブルを生成する。

モバイル端末が第１アプリケーションのアプリケーションデータを削除した後に、第１アプリケーションを起動する命令を受け取ったとき、モバイル端末は、記憶されているメタデータに基づき第２データテーブルを生成する。第２データテーブルを生成することは、新しいリサイクルビンデータテーブルを構成すること又は削除されたリサイクルビンデータテーブルを回復することであってよい。

メタデータの異なる記憶場所に特異的に、モバイル端末は、異なる方法でリサイクルビンデータテーブルを構成してよい。以下は、それらの方法のうちのいくつかについて記載する。

方法１．モバイル端末は、第１ファイルのメタデータを取得するために、第２ディレクトリにおいて第１ファイルのファイル名（すなわち、第１ファイルの第２名称）を解析し、そして、モバイル端末は、メタデータに基づきリサイクルビンデータテーブルを構成する。

以下は、説明のために例を使用する。第２ディレクトリ内の第１ファイルのファイル名は、図３Ａの右図に示されるように、「0003photo3.jpg20170116」である。モバイル端末は、第１ファイルのファイル名を解析して、オリジナルのファイル名「photo3.jpg」及びリサイクルされた日「20170116」を取得し、このとき、構成されたリサイクルビンデータテーブルは表４で記載される。

方法２．モバイル端末は、第１ファイルのメタデータを取得するために、Ｂａｓｅ６４符号化方式を使用することによって第２ディレクトリ内の第１ファイルのファイル名を復号し、次いで、メタデータに基づきリサイクルビンデータテーブルを構成する。

以下は、図３Ｂの右図に示されるファイル名を説明のための例として使用する。第２ディレクトリ内の第１ファイルのファイル名は「MDAwM+ebuOeJhzMuanBnMjAxN+W5tDHmnIgxNuaXpQ==」である。モバイル端末は、Ｂａｓｅ６４符号化を使用することによってターゲット文字列を復号して文字列「0003photo3.jpg20170116」を取得し、文字列を解析して第１ファイルのオリジナルのファイル名「photo3.jpg」及び第１ファイルのリサイクルされた日「20170116」を取得する。

以下は、図３Ｃの右図に示されるファイル名を説明のための例として使用する。第２ディレクトリ内の第１ファイルのファイル名は「50mL5py65a2Y5YKoX…（文字列は比較的に長く、従って、続く文字列はここでは省略される。）」である。モバイル端末は、Ｂａｓｅ６４符号化を使用することによってターゲット文字列を復号して文字列「Phone storage＼DCIM＼Bin Phone storage＼DCIM＼Camera＼photo3.jpg 20170116 11:11:03:01 20170102 12:20 90°」を取得し、文字列を解析してリサイクルビンパス「Phone storage＼DCIM＼Bin」、第１ファイルのソース記憶パス「Phone storage＼DCIM＼Camera＼photo3.jpg」、第１ファイルの削除時間「20170116 11:11:03:01」、第１ファイルの撮影時間「20170102 12:20」、及び第１ファイルのピクチャ方向「90°」を取得する。構成されたリサイクルビンデータテーブルは表５で記載される。

方法３．モバイル端末は、第２ディレクトリ内の第１ファイルのファイル名がタイムスタンプであるかどうかを判定する、すなわち、ファイル名のフォーマットが時間フォーマットであるかどうかを判定する。ファイル名が時間フォーマットでない場合に、モバイル端末は、Ｂａｓｅ６４符号化方式を使用することによって第２ディレクトリ内の第１ファイルのファイル名を復号して、第１ファイルのメタデータを取得する。ファイル名が時間フォーマットである場合に、モバイル端末は、第２ディレクトリ内で新たに構築されたバイナリファイルからデータを読み出し、第１ファイルのファイル名（削除時間）に一致するターゲット文字列を探し、Ｂａｓｅ６４符号化方式を使用することによってターゲット文字列を復号して第１ファイルのメタデータを取得し、メタデータに基づきリサイクルビンデータテーブルを構成する。

以下は、図３Ｄの右図に示されるファイル名を説明のための例として使用する。第２ディレクトリ内の第１ファイルのファイル名は「20170116 11:11:03:01」である。モバイル端末は、ファイル名がタイムスタンプであると決定し、そして、モバイル端末は、第２ディレクトリ内で新たに構築されたバイナリファイルからデータを読み出し、図３Ｅで示されるように、「20170116 11:11:03:01」に対応しているバイナリファイル内のターゲット文字列が“A”であると決定する。モバイル端末は、Ｂａｓｅ６４符号化方式を使用することによってターゲット文字列“A”を復号して、文字列「Phone storage＼DCIM＼Bin Phone storage＼DCIM＼Camera＼photo3.jpg 20170116 11:11:03:01 20170102 12:20 90°4641351324287312345348a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131rD6F9619FF-8B86-D011-B42D-00C04FC964FF」を取得する。モバイル端末は、文字列を解析して、リサイクルビンファイル「Phone storage＼DCIM＼Bin」、第１ファイルのソース記憶パス「Phone storage＼DCIM＼Camera＼photo3.jpg」、第１ファイルの削除時間「20170116 11:11:03:01」、第１ファイルの撮影時間「20170102 12:20」、第１ファイルのピクチャ方向「90°」、第１ファイルが属するソースアルバムのクラウド識別子「464135132428731234534」、第１ファイルのハッシュ値「8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131r」、及び第１ファイルのクラウドグローバル一意識別子「D6F9619FF-8B86-D011-B42D-00C04FC964FF」を取得する。構成されたリサイクルビンデータテーブルは表６で記載される。

方法４．モバイル端末は、第２ディレクトリ内の第１ファイルのファイル名がタイムスタンプであるかどうかを判定する、すなわち、ファイル名のフォーマットが時間フォーマットであるかどうかを判定する。ファイル名が時間フォーマットでない場合に、モバイル端末は、Ｂａｓｅ６４符号化方式を使用することによって第２ディレクトリ内の第１ファイルのファイル名を復号し、解析を通じて取得されたデータを暗号解読して第１ファイルのメタデータを取得する。ファイル名が時間フォーマットである場合に、モバイル端末は、第２ディレクトリ内で新たに構築されたバイナリファイルからデータを読み出し、第１ファイルのファイル名（削除時間）に一致するターゲット文字列を探し、Ｂａｓｅ６４符号化方式を使用することによってターゲット文字列を復号し、解析を通じて取得されたデータを暗号解読して第１ファイルのメタデータを取得し、メタデータに基づきリサイクルビンデータテーブルを構成する。

方法５．モバイル端末は、第３データテーブルに基づき第２データテーブルを生成する。モバイル端末は、具体的に、第２データテーブルを取得するように第３データテーブルの内容をコピーしてよく、あるいは、第１アプリケーションに対応するディレクトリへ第３データテーブルを移動することによって第３データテーブルを第２データテーブルとして使用してよい。

モバイル端末は、図４で示されるように、リサイクルビンデータテーブルを構成する前に選択画面を提示してもよいことが理解されるべきである。選択画面は、回復される必要があるリサイクルビンファイル及び回復される必要があるメタデータを選択するようにユーザに促すために使用され、その場合に、リサイクルビンデータテーブルは、選択画面上でユーザによって選択されるファイル及びメタデータに基づき構成される。モバイル端末は、リサイクルビンデータテーブルを構成した後に選択画面を提示してもよい。選択画面は、回復される必要があるリサイクルビンファイルを選択するようにユーザに促すために使用され、その場合に、ユーザによって選択されたファイルは、構成されたリサイクルビンデータテーブルに基づきリサイクルビン画面上で表示される。任意に、ユーザによって選択されなかったリサイクルビンファイルについては、モバイル端末は、自動的に、そのリサイクルビンファイルを永久に削除してよい。

モバイル端末がリサイクルビン画面上で第２データテーブルを生成した後に、リサイクルビン画面を開く命令を受け取ったとき、モバイル端末は、第２データテーブルに基づきリサイクルビン画面上で第１ファイルを表示する。

具体的に、リサイクルビン画面は、図５Ａに示されるように、リサイクルビンファイルのサムネイルを表示する画面であってよい。ユーザは、リサイクルビンアルバムに対応するアイコンをタップし、モバイル端末は、第１ファイルのサムネイルを表示する。

リサイクルビン画面は、図５Ｂに示されるように、リサイクルビンファイルの編集画面であってよい。ユーザは、第１ファイルのサムネイルをタップし、モバイル端末は、第１ファイルの編集画面を表示する。

本願のこの実施形態では、リサイクルビンデータテーブルが削除された後に、モバイル端末は、新しいリサイクルビンデータテーブルを生成することができ、それにより、モバイル端末は、アプリケーションデータがクリアされた後にリサイクルビン画面上で第１ファイルを依然として表示可能であり、ユーザは、リサイクルビン画面上で第１ファイルを永久削除又は回復することができ、それによって、ユーザエクスペリエンスは改善される。

本願のこの実施形態は、解決法の柔軟性を改善するように、第２データテーブルを生成する複数の方法を提供する。

図２に対応する実施形態に基づき、いくつかの実施形態で、モバイル端末がリサイクルビン画面上で第１ファイルを表示した後に、ユーザは画面上で第６操作を入力してよく、第６操作に応答して、モバイル端末は第１ファイルのメタデータを表示してよい。図５Ｃで示されるように、ユーザは、第１ファイルの編集画面において詳細機能キーをタップし（第６操作）、モバイル端末は、第２データテーブルに基づき第１ファイルのメタデータを表示する。第２データテーブルに含まれる異なるタイプのメタデータに基づき、モバイル端末は、異なるメタデータを表示することが理解されるべきである。図５Ｃは、単に、第１ファイルの削除時間及びオリジナルのファイル名を示す。更に、いくつかのシナリオでは、図５Ｄに示されるように、モバイル端末は、第１ファイルの現在のパス、第１ファイルのソース記憶パス、第１ファイルの撮影時間、及び第１ファイルのピクチャ方向を更に表示してもよい。また更に、図５Ｅに示されるように、モバイル端末は、第１ファイルが属するアルバムのアルバム識別子、第１ファイルのクラウドグローバル一意識別子、及び第１ファイルのハッシュ値を更に表示してもよい。

この実施形態では、ユーザが第１ファイルの詳細を知ることができるように、モバイル端末は、第２データテーブルに含まれるメタデータを表示してよく、それによって、ユーザエクスペリエンスは改善される。

いくつかの実施形態で、モバイル端末がクラウドサーバへの接続を確立するとき、モバイル端末がアプリケーションデータを削除した後に、モバイル端末は、自動的にクラウドサーバからマルチメディアファイルをダウンロードし、クラウドリサイクルビンからダウンロードされたマルチメディアファイルをリサイクルビン画面上に表示する。それらのマルチメディアファイルの中には、第１ファイルと同じであるファイルが存在する場合があり、従って、複数の同じ写真又は複数の同じ映像がリサイクルビン画面上に表示される。

任意の実施で、この実施形態において、モバイル端末がリサイクルビン画面上で第１ファイルを表示する前に、第２データテーブルに含まれる第１ファイルのクラウドグローバル一意識別子（Cloud GUID）が０でない場合に、モバイル端末は、第１ファイルと、クラウドサーバ内のクラウドグローバル一意識別子に対応する第２ファイルとを関連付け、第２ファイル及び第１ファイルを統合して表示してよい、すなわち、第１ファイルのみ又は第２ファイルのみを表示する。具体的に、モバイル端末は、クラウドサーバからモバイル端末へ第２ファイルをダウンロードしなくてもよく、リサイクルビン画面上で第１ファイルのみを表示する。代替的に、クラウドサーバからモバイル端末へ第２ファイルをダウンロードした後に、モバイル端末は、第１ファイル及び第２ファイルのどちらか一方をリサイクルビン画面上での表示のために選択してよく、それによって、モバイル端末が同じ内容を繰り返し表示することは回避される。

例えば、表６に対応するシナリオでは、第１ファイルに対応するクラウドグローバル一意識別子は「D6F9619FF-8B86-D011-B42D-00C04FC964FF」であり、モバイル端末は、グローバル一意識別子が「D6F9619FF-8B86-D011-B42D-00C04FC964FF」である第２ファイルをクラウドサーバで探し、次いで、第２ファイルを表示せずに、リサイクルビン画面上で第１ファイルのみを表示してよい。

この実施形態は、モバイル端末がリサイクルビン画面上で繰り返し同じファイルを表示することを回避する方法を提供し、それによって、解決法の柔軟性は改善される。

任意の方法で、この実施形態において、モバイル端末がリサイクルビン画面上で第１ファイルを表示する前に、リサイクルビンデータテーブルに、第１ファイルが属するソースアルバムのクラウド識別子と、第１ファイルのハッシュ値とが含まれる場合に、モバイル端末は、第１ファイルと、第１ファイルが属するソースアルバムのクラウド識別子及びハッシュ値に対応するクラウドサーバ内の第２ファイルとを関連付け、第２ファイル及び第１ファイルを統合して表示してよい、すなわち、第１ファイルのみ又は第２ファイルのみを表示する。具体的に、モバイル端末は、クラウドサーバからモバイル端末へ第２ファイルをダウンロードしなくてもよく、リサイクルビン画面上で第１ファイルのみを表示する。代替的に、クラウドサーバからモバイル端末へ第２ファイルをダウンロードした後に、モバイル端末は、第１ファイル及び第２ファイルのどちらか一方をリサイクルビン画面上での表示のために選択してよく、それによって、モバイル端末が同じ内容を繰り返し表示することは回避される。

例えば、表６に対応するシナリオでは、第１ファイルのハッシュ値が「8a21589c6ac2413295d41d8955bbdcc1asdaa3542a1sd21a2sd1asd3sa56hth41464h131r」であり、第１ファイルが属するソースアルバムのクラウド識別子が「464135132428731234534」である場合に、モバイル端末は、クラウドサーバ内で、ハッシュ値が一致するハッシュ値を有し且つソースアルバムのクラウド識別子が一致するソースアルバムのクラウド識別子を有する第２ファイルを見つけることができ、次いで、第２ファイルを表示せずに、リサイクルビン画面上で第１ファイルのみを表示する。

この実施形態は、リサイクルビン画面上で繰り返し同じファイルを表示することを回避する別の方法を提供し、それによって、解決法の柔軟性は改善される。

モバイル端末がリサイクルビン画面上で第１ファイルを表示した後に、第１ファイルは、操作画面上でユーザによって入力された回復命令に従って回復されもよいことが留意されるべきである。第１ファイルは、第２データテーブルに含まれる異なるタイプのメタデータに基づき異なる程度で回復され得る理解されるべきである。

任意の実施で、第１ファイルが属するソースアルバムは第１アルバムである。具体的に言えば、ユーザが第１画面上で第１ファイルを削除する前に（モバイル端末が、第１画面上でユーザによって入力された第２操作を取得する前に）、第１ファイルは第１アルバムに属する。第２データテーブルが第１ファイルのソース記憶パスを含まない場合に、モバイル端末は、第１ファイルをソースアルバムに回復することができない。回復命令を取得した後に、モバイル端末は、第１ファイルをターゲットアルバムに回復する。

ターゲットアルバムは、システム又はユーザに特有のアルバムであり、ユーザによって、リサイクルビン画面上で回復されるマルチメディアファイルを管理するために使用される。第１ファイルをターゲットアルバムに回復することは、第１ファイルが属するアルバムをリサイクルビンアルバムからターゲットアルバムへ変更することを意味する。以下は、表４に対応するシナリオを説明のための例として使用する。第２データテーブルは、第１ファイルの削除時間及び第１ファイルのオリジナルのファイル名を含む。

このシナリオにおいて、モバイル端末は、操作画面上でユーザによって入力された回復命令を受け取る。図６Ａ又は図６Ｂで示されるように、ユーザは、回復される必要がある第１ファイルを選択し、そして、第１ファイルを回復するために回復アイコンをタップする。回復命令を受け取った後に、モバイル端末は、図６Ｃで示されるように、第１ファイルを第２ディレクトリからターゲットディレクトリへ移動し、第１ファイルのファイル名をオリジナルのファイル名（第１名称）に戻す。ターゲットディレクトリは、ターゲットアルバムにマルチメディアファイルを格納するために使用される。ユーザがリサイクルビン画面上で回復命令を入力した後に、回復される第１ファイルは、モバイル端末によって定義されるリサイクルビン画面上に含まれない。モバイル端末がターゲットアルバムを開く命令を受け取るとき、モバイル端末は、図６Ｄで示されるように、回復される第１ファイルを、ターゲットアルバムに対応する画面上で表示する。

この実施形態では、アプリケーションデータが削除された後に、モバイル端末は、システム特有のアルバムに第１ファイルを回復することができ、それによって、解決法の柔軟性は改善される。

任意の実施で、第１ファイルが属するソースアルバムは第１アルバムである。具体的に言えば、ユーザが第１画面上で第１ファイルを削除する前に（モバイル端末が、第１画面上でユーザによって入力された第２操作を取得する前に）、第１ファイルは第１アルバムに属する。第２データテーブルが第１ファイルのソース記憶パスを含む場合には、モバイル端末は、第１ファイルをソースアルバムに回復することができる。回復命令を取得した後に、モバイル端末は、第１ファイルを第１アルバムに回復する、すなわち、第１ファイルが属するアルバムをリサイクルビンアルバムから第１アルバムへ変更する。

以下は、表５に対応するシナリオを説明のための例として使用する。第２データテーブルは、第１ファイルのものであるリサイクルビンパス、ソース記憶パス、削除時間、撮影時間、及びピクチャ方向を含む。

このシナリオにおいて、ユーザによって操作画面上で入力された回復命令を受け取った後に、図７Ａで示されるように、モバイル端末は、ソース記憶パスに基づき、第１ファイルを第２ディレクトリから第１ディレクトリへ移動し且つ第１ファイルのファイル名をオリジナルのファイル名（第１名称）に戻す、すなわち、第１ファイルをリサイクルビンディレクトリからソースディレクトリに回復する。ユーザがリサイクルビン画面上で回復命令を入力した後に、回復される第１ファイルは、モバイル端末によって定義されるリサイクルビン画面上に含まれない。モバイル端末がターゲットアルバムを開く命令を受け取るとき、モバイル端末は、図７Ｂで示されるように、回復される第１ファイルをソースアルバム内で表示する。

この実施形態では、アプリケーションデータが削除された後に、モバイル端末は、ソースアルバムに第１ファイルを回復することができ、それによって、解決法の柔軟性は改善される。

モバイル端末がリサイクルビン画面上で第１ファイルを表示した後に、モバイル端末は、操作画面上でユーザによって入力された削除命令に従って第１ファイルを永久削除してもよい、すなわち、モバイル端末から第１ファイルを削除してもよいことが更に留意されるべきである。

図８Ａ又は図８Ｂで示されるように、ユーザは、リサイクルビン画面上で、削除される必要がある第１ファイルを選択し、そして、第１ファイルを削除するために削除アイコンをタップする。操作を取得した後に、モバイル端末は、第２ディレクトリから第１ファイルを削除する、すなわち、図８Ｃに示されるように、モバイル端末から第１ファイルを永久に削除する。

この実施形態では、モバイル端末は、モバイル端末の利用可能な記憶空間を増やすように、アプリケーションデータが削除された後に第１ファイルを永久に削除することができる。

以上は、本願のファイル処理方法について記載しており、以下は、本願のモバイル端末について記載する。図９を参照すると、本願のモバイル端末の実施形態は、
第１操作に応答して第１アプリケーションの第１画面上で第１ファイルを表示するよう構成される表示モジュール９０１と、
第１画面上でユーザが入力した第２操作を取得するよう構成される取得モジュール９０２であって、
表示モジュール９０１が、第２操作に応答して第１アプリケーションのリサイクルビン画面上で第１ファイルを表示するよう更に構成される、取得モジュール９０２と、
第１データテーブルを削除するよう構成され、第１データテーブルの削除により第１アプリケーションのリサイクルビン画面上で第１ファイルがユーザから見えなくなる削除モジュール９０３であって、
取得モジュール９０２が、ユーザが入力した第３操作を取得するよう更に構成される、削除モジュール９０３と、
第３操作に応答して第２データテーブルを生成するよう構成され、第２データテーブルの存在により第１アプリケーションのリサイクルビン画面上で第１ファイルがユーザから見える生成モジュール９０４と
を含む。

本願のこの実施形態では、リサイクルビンデータテーブルが削除された後に、モバイル端末は、生成モジュール９０４を使用することによって新しいリサイクルビンデータテーブルを生成可能であり、それにより、モバイル端末は、アプリケーションデータがクリアされた後にリサイクルビン画面上で第１ファイルを依然として表示することができ、ユーザは、リサイクルビン画面上で第１ファイルを永久削除又は回復することができ、それによって、ユーザエクスペリエンスは改善される。

任意に、いくつかの実施形態で、取得モジュール９０２が第２操作を取得する前に、第１ファイルは第１アプリケーションの第１アルバムに属し、取得モジュール９０２が第２操作を取得した後に、第１ファイルは第１アプリケーションのリサイクルビンアルバムに属し、
生成モジュール９０４が第２データテーブルを生成した後に、
表示モジュール９０１は、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示するよう更に構成され、
取得モジュール９０２は、リサイクルビン画面上でユーザが入力した第４操作を取得するよう更に構成され、
表示モジュール９０１は、第４操作に応答して、第１アプリケーションの第１アルバムに対応する画面上で第１ファイルを表示するよう構成され、
取得モジュール９０２が第４操作を取得した後に、第１ファイルは第１アプリケーションの第１アルバムに属する。

任意に、いくつかの実施形態で、取得モジュール９０２が第２操作を取得する前に、第１ファイルは第１アプリケーションの第１アルバムに属し、取得モジュール９０２が第２操作を取得した後に、第１ファイルは第１アプリケーションのリサイクルビンアルバムに属し、
生成モジュール９０４が第２データテーブルを生成した後に、
表示モジュール９０１は、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示するよう更に構成され、
取得モジュール９０２は、リサイクルビン画面上でユーザが入力した第４操作を取得するよう更に構成され、
表示モジュール９０１は、第４操作に応答して、第１アプリケーションのターゲットアルバムに対応する画面上で第１ファイルを表示するよう更に構成され、
取得モジュール９０２が第４操作を取得した後に、第１ファイルは第１アプリケーションのターゲットアルバムに属する。

任意に、いくつかの実施形態で、生成モジュール９０４が第２データテーブルを生成した後に、
表示モジュール９０１は、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示するよう更に構成され、
取得モジュール９０２は、リサイクルビン画面上でユーザが入力した第５操作を取得するよう更に構成され、
削除モジュール９０３は、第５操作に応答して第１ファイルをモバイル端末から削除するよう更に構成される。

任意に、いくつかの実施形態で、生成モジュール９０４が第２データテーブルを生成した後に、
取得モジュール９０２は、ユーザが入力した第６操作を取得するよう更に構成され、
表示モジュール９０１は、第６操作に応答して第１ファイルのメタデータを表示するよう更に構成され、このとき、メタデータは、次のもの：第１ファイルのオリジナルのファイル名、第１ファイルのオリジナルのファイル識別子、第１ファイルの削除時間、第１ファイルのソース記憶パス、第１ファイルの現在の記憶パス、第１ファイルの撮影時間、第１ファイルのピクチャ方向、第１ファイルのクラウドグローバル一意識別子、第１ファイルのハッシュ値、及び第１ファイルが属するソースアルバムのクラウド識別子、のうちの少なくとも１つを含む。

任意に、いくつかの実施形態で、表示モジュール９０１は、第３操作に応答して、第１アプリケーションのリサイクルビン画面上で第２ファイルを表示することをスキップするよう更に構成され、このとき、第２ファイルは、第１ファイルと同じであって且つクラウドサーバに記憶されているファイルである。

任意に、いくつかの実施形態で、生成モジュール９０４が第２データテーブルを生成した後に、
表示モジュール９０１は、選択画面を表示するよう更に構成され、
取得モジュール９０２は、選択画面上でユーザが入力した第７操作を取得するよう更に構成され、
表示モジュール９０１は、第７操作に応答して、第１アプリケーションのリサイクルビン画面上で第１ファイルを表示するよう更に構成される。

任意に、いくつかの実施形態で、モバイル端末は、
第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、第１ファイルのファイル名を第１名称から第２名称へ変更するよう構成される処理モジュールを更に含み、このとき、第２ディレクトリは、第１アプリケーションのリサイクルビン画面上で表示されるファイルを記憶するために使用される。

任意に、いくつかの実施形態で、第２名称は、前もってセットされた符号化方式を使用して第１ファイルのメタデータを符号化することによって取得されるターゲット文字列であり、
生成モジュール９０４は、前もってセットされた符号化方式を使用して第２名称を復号することによって第１ファイルのメタデータを取得し、メタデータに基づき第２データテーブルを生成するよう特に構成される。

任意に、いくつかの実施形態で、第２名称は第１ファイルの削除時間であり、
モバイル端末は、
前もってセットされた符号化方式を使用して第１ファイルのメタデータを符号化することによってターゲット文字列を取得し、ターゲット文字列及び第１ファイルの削除時間を第２ディレクトリのバイナリファイルにおいて対応付けて格納するよう構成される処理モジュールを更に含む。

任意に、いくつかの実施形態で、生成モジュール９０４は、第２名称に基づき第１ファイルの削除時間を決定し、バイナリファイルにおいて第１ファイルの削除時間に対応するターゲット文字列を決定し、前もってセットされた符号化方式を使用してターゲット文字列を復号することによって第１ファイルのメタデータを取得し、メタデータに基づき第２データテーブルを生成するよう特に構成される。

任意に、いくつかの実施形態で、モバイル端末は、第３データテーブルを取得するよう第１データテーブルをバックアップするよう構成されるバックアップモジュールを更に含み、
生成モジュール９０４は、第３データテーブルに基づき第２データテーブルを生成するよう特に構成される。

図９に対応するモバイル端末のモジュールによって実行されるプロシージャは、図２に示される実施形態で記載される方法プロシージャと同様であることが理解されるべきである。詳細は、ここで再び記載されない。

以上は、機能モジュールの観点から本願のモバイル端末について記載している。以下は、物理ハードウェアの観点から本願の端末について記載する。図１０に示されるように、記載の容易さのために、本発明のこの実施形態に関係がある部分のみが表されている。開示されない具体的な技術詳細については、本願の方法の実施形態を参照されたい。モバイル端末は、携帯電話機、タブレットコンピュータ、ＰＤＡ（Personal Digital Assistant，パーソナル・デジタル・アシスタント）、ＰＯＳ（Point of Sale，販売時点情報管理）、車載コンピュータ、などを含む如何なる端末デバイスであってもよい。例えば、端末は携帯電話機である。

図１０は、本発明の実施形態によって提供される端末に関係がある携帯電話機ノブ文構造のブロック図である。図１０を参照すると、携帯電話機は、無線周波数（Radio Frequency，RF）回路１０１０、メモリ１０２０、入力ユニット１０３０、表示ユニット１０４０、センサ１０５０、オーディオ回路１０６０、ワイヤレス・フィデリティ（wireless fidelity，Wi-Fi）モジュール１０７０、プロセッサ１０８０、及び電源１０９０のようなコンポーネントを含む。当業者であれば、図１０に示される携帯電話機構造は、携帯電話機に対する如何なる制限も構成せず、携帯電話機は、図示されているよりも多い又は少ないコンポーネント、又はいくつかのコンポーネントの組み合わせ、又はコンポーネントの異なる配置を含んでもよいことを理解し得る。

携帯電話機のコンポーネントは、図１０を参照して以下で詳細に記載される。

ＲＦ回路１０１０は、情報を受信及び送信するか、あるいは、コール中に信号を受信及び送信し、特に、基地局からダウンリンク情報を受信し、それから、ダウンリンク情報を処理のためにプロセッサ１０８０へ送るよう構成されてよい。その上、ＲＦ回路１０１０は、関連するアップリンクデータを基地局へ送る。通常、ＲＦ回路１０１０は、アンテナ、少なくとも１つの増幅器、トランシーバ、カプラ、低雑音増幅器（Low Noise Amplifier，LNA）、デュプレクサ、などを含むが限られない。その上、ＲＦ回路１０１０はまた、無線通信を通じてネットワーク及び他のデバイスと通信してもよい。グローバル・システム・フォー・モバイル・コミュニケーションズ（Global System of Mobil communication，GSM）、汎用パケット無線サービス（General Packet Radio Service，GPRS）、符号分割多重アクセス（Code Division Multiple Access，CDMA）、広帯域符号分割多重アクセス（Wideband Code Division Multiple Access，WCDMA）、ロング・ターム・エボリューション（Long Term Evolution，LTE）、電子メール、ショート・メッセージ・サービス（Short messaging Service，SMS）、などを含むがこれらに限られない如何なる通信標準又はプロトコルも、無線通信のために使用されてよい。

メモリ１０２０は、ソフトウェアプログラム及びモジュールを記憶するよう構成されてよい。プロセッサ１０８０は、メモリ１０２０に記憶されているソフトウェアプログラム及びモジュールを実行することによって、携帯電話機の様々な機能アプリケーションを実行し且つデータを処理する。メモリ１０２０は、プログラム記憶領域及びデータ記憶領域を主として含み得る。プログラム記憶領域は、オペレーティング・システム、少なくとも１つの機能（例えば、音響再生機能及び画像再生機能）のために必要とされるアプリケーションプログラム、などを記憶し得る。データ記憶領域は、携帯電話機の使用に基づき生成されるデータ（例えば、オーディオデータ及び電話帳）、などを記憶し得る。その上、メモリ１０２０は、高速ランダム・アクセス・メモリを含んでよく、あるいは、不揮発性メモリ、例えば、少なくとも１つのディスク記憶デバイス、フラッシュメモリデバイス、又は他の揮発性ソリッドステート記憶デバイスを更に含んでもよい。

入力ユニット１０３０は、入力された数又は文字情報を受け取り、携帯電話機のユーザ設定及び機能制御に関連したキー信号入力を生成するよう構成されてよい。具体的に、入力ユニット１０３０は、タッチパネル１０３１及び他の入力デバイス１０３２を含んでよい。タッチパネル１０３１は、タッチスクリーンとも呼ばれ、タッチパネル１０３１上で又はその近くでユーザによって行われたタッチ操作（例えば、指、スタイラス又は任意の適切な物若しくはアクセサリを使用することによって、タッチパネル１０３１上で又はその近くでユーザによって行われる操作）を収集し、前もってセットされたプログラムに従って、対応する接続デバイスを駆動することができる。任意に、タッチパネル１０３１は２つの部分、すなわち、タッチ検出装置及びタッチコントローラを含んでよい。タッチ検出装置は、ユーザのタッチ方向を検出し、タッチ操作によってもたらされる信号を検出し、信号をタッチコントローラへ送信する。タッチコントローラは、タッチ検出装置からタッチ情報を受信し、タッチ情報をタッチ座標に変換し、次いで、タッチ座標をプロセッサ１０８０へ送信し、そして、プロセッサ１０８０によって送信されたコマンドを受け取り、コマンドを実行することができる。その上、タッチパネル１０３１は、抵抗型、容量型、赤外線型、及び表面弾性波型のような複数のタイプで実装されてよい。タッチパネル１０３１に加えて、入力ユニット１０３０は、他の入力デバイス１０３２を更に含んでもよい。具体的に、他の入力デバイス１０３２は、物理キーボード、ファンクションキー（例えば、音量制御キー又は電源キー）、トラックボール、マウス、ジョイスティックなどを含んでよいが限られない。

表示ユニット１０４０は、ユーザによって入力された情報、又はユーザに提供される情報、及び携帯電話機の様々なメニューを表示するよう構成されてよい。表示ユニット１０４０は表示パネル１０４１を含んでよい。任意に、表示パネル１０４１は、例えば、液晶ディスプレイ(Liquid Crystal Display，LCD)又は有機発光ダイオード（Organic Light-Emitting Diode，OLED）の形で構成されてよい。更に、タッチパネル１０３１が表示パネル１０４１を覆ってもよい。タッチパネル１０３１上で又はその近くでタッチ操作を検出した後、タッチパネル１０３１は、タッチイベントタイプを決定するためにプロセッサ１０８０に対してタッチ操作を転送する。次いで、プロセッサ１０８０は、タッチイベントタイプに基づき、対応する視覚出力を表示パネル１０４１で提供する。図１０では、タッチパネル１０３１及び表示パネル１０４１は、携帯電話機の入力及び出力機能を実装するように２つの分離したコンポーネントとして使用されているが、いくつかの実施形態において、タッチパネル１０３１は、携帯電話機の入力及び出力機能を実装するように表示パネル１０４１と一体化されてもよい。

携帯電話機は、少なくとも１つのセンサ１０５０、例えば、光センサ、動きセンサ、又は他のセンサを更に含んでもよい。具体的に、光センサは、周囲光センサ及び近接センサを含んでよい。周囲光センサは、周囲光の明るさに基づき表示パネル１０４１の輝度を調整してよい。近接センサは、携帯電話機が耳に近づくときに、表示パネル１０４１及び／又はバックライトをオフしてよい。動きセンサの１タイプとして、加速度計センサは、様々な方向（通常は、３つの軸が存在する。）における加速度の値を検出することができ、静止状態では重力の値及び方向を検出することができ、携帯電話機の姿勢を特定する用途（例えば、横向きと縦向きの画面切り替え、関連するゲーム、及び磁力計姿勢較正）、振動認識に関連した機能（例えば、ペドメーター及びタッピング）、などに使用されてよい。ジャイロスコープ、気圧計、湿度計、温度計、及び赤外線センサのような、携帯電話機に構成され得る他のセンサは、ここでは記載されない。

オーディオ回路１０６０、スピーカ１０６１、及びマイクロホン１０６２は、ユーザと携帯電話機との間のオーディオインターフェイスを提供し得る。オーディオ回路１０６０は、受け取られたオーディオデータの変換を通じて取得される電気信号をスピーカ１０６１へ送信し、スピーカ１０６１は、電気信号を音響信号に変換し、音響信号を出力する。その上、マイクロホン１０６２は、収集された音響信号を電気信号に変換し、オーディオ回路１０６０は、電気信号を受信し、電気信号をオーディオデータに変換し、オーディオデータを処理のためにプロセッサ１０８０へ出力し、そして、処理されたオーディオデータは、例えば、ＲＦ回路１０１０を使用することによって他の携帯電話機へ送られ、あるいは、オーディオデータは、更なる処理のためにメモリ１０２０へ出力される。

Ｗｉ－Ｆｉは、短距離無線伝送技術である。Ｗｉ－Ｆｉモジュール１０７０を使用することによって、携帯電話機は、ユーザが、例えば、電子メールを受信／送信すること、ウェブページを閲覧すること、及びストリーミングメディアにアクセスすることを助け得る。Ｗｉ－Ｆｉモジュール１０７０は、無線ブロードバンドインターネットアクセスをユーザに提供する。図１０はＷｉ－Ｆｉモジュール１０７０を示しているが、Ｗｉ－Ｆｉモジュール１０７０は携帯電話機の必須の構成要素ではなく、本発明の本質が変更されないという条件で必要に応じて省略されてもよいことが理解され得る。

プロセッサ１０８０は、携帯電話機の制御センターであり、様々なインターフェイス及びラインを使用することによって携帯電話機の全体の様々な部分を接続する。プロセッサ１０８０は、携帯電話機の全体をモニタするために、メモリ１０２０に記憶されているソフトウェアプログラム及び／又はモジュールを起動又は実行することと、メモリ１０２０に記憶されているデータを呼び出すこととによって、携帯電話機の様々な機能を実行し且つデータを処理する。任意に、プロセッサ１０８０は、１以上の処理ユニットを含んでよい。アプリケーションプロセッサ及びモデムプロセッサがプロセッサ１０８０に組み込まれてよい。アプリケーションプロセッサは、オペレーティング・システム、ユーザインターフェイス、アプリケーションプログラム、などを主に処理する。モデムプロセッサは、無線通信を主に処理する。モデムプロセッサは、代替的に、プロセッサ１０８０に組み込まれなくてもよいことが理解され得る。

携帯電話機は、構成要素へ電力を供給する電源１０９０（例えば、バッテリ）を更に含む。電源は、電力管理システムを使用することによって充電管理、放電管理、及び電力消費管理といった機能を実装するように、電力管理システムを使用することによってプロセッサ１０８０へ論理的に接続されてよい。

図示されていないが、携帯電話機は、カメラ、ブルートゥースモジュール、などを更に含んでもよい。詳細は、ここでは記載されない。

上記の実施形態でモバイル端末によって実行されるステップは、図１０に示されるモバイル端末の構造に基づいてよい。

本願の実施形態は、コンピュータ記憶媒体を更に提供する。コンピュータ記憶媒体は、端末による使用のためにコンピュータソフトウェア命令を記憶するために使用され、コンピュータソフトウェア命令は、モバイル端末の実行のために設計されたプログラムを含む。

本願の実施形態は、コンピュータプログラム製品を更に提供する。コンピュータプログラム製品は、コンピュータソフトウェア命令を含み、コンピュータソフトウェア命令は、図２のファイル処理方法に含まれるプロシージャを実装するためにプロセッサを使用することによってロードされてよい。

上記の実施形態の全て又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせを使用することによって実装されてよい。ソフトウェアが実施形態を実装するために使用されるとき、実施形態は、完全に又は部分的にコンピュータプログラム製品の形で実装されてよい。

コンピュータプログラム製品は、１以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータでロード及び実行されるとき、本発明の実施形態に従うプロシージャ又は機能は全て又は部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は他のプログラム可能な装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてよく、あるいは、コンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体へ送られてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、又はデータセンターから他のウェブサイト、コンピュータ、サーバ、又はデータセンターへ有線（例えば、同軸ケーブル、光ファイバ、若しくはデジタル加入者回線（ＤＳＬ）を通じて）又は無線（例えば、赤外線、電波、マイクロ波、などを通じて）様式で送られてよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能な媒体又は１以上の使用可能な媒体を組み込むサーバ若しくはデータセンターのようなデータ記憶デバイスであってよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、又は磁気テープ）、光学媒体（例えば、ＤＶＤ）、半導体媒体（例えば、ソリッドステートディスクSolid State Disk，（SSD））などであってよい。

当業者によって明らかに理解され得るように、記載の便宜上及び簡潔さのために、上記のシステム、装置、及びユニットの詳細な作動プロセスについては、上記の方法の実施形態における対応するプロセスが参照され得、ここで再度詳細は記載されない。

本願で提供されるいくつかの実施形態で、開示されるシステム、装置、及び方法は他の様態で実装されてもよいことが理解されるべきである。例えば、記載される装置の実施形態は例にすぎない。例えば、ユニット分割は、単に、論理的な機能分割であり、すなわち、実際の実施では他の分割であってよい。例えば、複数のユニット又はコンポーネントは、他のシステムに結合又は一体化されてよく、あるいは、いくつかの特徴は無視されるか又は実行されなくてもよい。その上、表示又は議論される相互結合又は直接的な結合若しくは通信接続は、いくつかのインターフェイス、装置又はユニットを通じた間接的な結合又は通信接続であってもよく、電気的な、機械的な、又は他の形態で実装されてもよい。

分離した部分として記載されるユニットは、物理的に分離していてもしていなくてもよい。ユニットとして表示される部分は、物理的なユニットであってもなくてもよく、一箇所に位置しても、又は複数のネットワークユニット上に分配されてもよい。ユニットの一部又は全ては、実施形態の解決法の目的を達成するために実際のニーズに応じて選択されてよい。

その上、本願の実施形態における機能ユニットは、１つの処理ユニットに一体化されてよく、あるいは、ユニットの夫々が物理的に単独で存在してもよく、あるいは、２以上のユニットが１つのユニットに一体化される。一体化されたユニットは、ハードウェアの形で実装されてよく、あるいは、ソフトウェア機能ユニットの形で実装されてもよい。

一体化されたユニットがソフトウェア機能ユニットの形で実装され、独立した製品として販売又は使用されるとき、一体化されたユニットは、コンピュータ可読記憶媒体に記憶され得る。そのような理解に基づき、本願の技術的解決法は本質的に、あるいは、先行技術を構成する部分、又は技術的解決法の全て若しくは一部は、ソフトウェア製品の形で実装されてよい。コンピュータソフトウェア製品は、記憶媒体に記憶され、本願の実施形態で記載される方法のステップの全て又は一部を実行するようにコンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイス、などであってよい。）に指示するいくつかの命令を含む。上記の記憶媒体は、ＵＳＢフラッシュドライブ、リムーバブル・ハード・ディスク、リード・オンリー・メモリ（英語正式名称：Read-Only Memory，略してROM）、ランダム・アクセス・メモリ（英語正式名称：Random Access Memory，略してRAM）、磁気ディスク、又は光ディスクのような、プログラムコードを記憶することができる如何なる媒体も含む。

上記の実施形態は、本願の技術的解決法について記載することを目的しているにすぎず、本願を制限しない。本願は上記の実施形態を参照して詳細に記載されているが、当業者であれば、彼らが、本願の実施形態の技術的解決法の精神及び適用範囲から外れることなしに、上記の実施形態で記載される技術的解決法を更に変更したり、あるいは、そのいくつかの特徴に対して等価な置換を行ったりし得ることを理解するはずである。

Claims (28)

1. ファイル処理方法であって、
   モバイル端末によって、ユーザが入力した第１操作を取得し、該第１操作に応答して第１アプリケーションの第１画面上で第１ファイルを表示することと、
   前記モバイル端末によって、前記第１画面上で前記ユーザが入力した第２操作を取得し、該第２操作に応答して前記第１アプリケーションのリサイクルビン画面上で前記第１ファイルを表示することと、
   前記モバイル端末によって第１データテーブルを削除し、該第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなることと、
   前記モバイル端末によって、前記ユーザが入力した第３操作を取得し、該第３操作に応答して第２データテーブルを生成し、該第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えることと
   を有し、
   前記モバイル端末によって、前記ユーザが入力した第３操作を取得した後に、当該方法は、
   前記第３操作に応答して、前記モバイル端末によって前記第１アプリケーションの前記リサイクルビン画面上で第２ファイルを表示することをスキップすることを更に有し、
   前記第２ファイルは、前記第１ファイルと同じであって、クラウドサーバに記憶されているファイルである、方法。
2. 前記モバイル端末によって前記第１画面上で前記ユーザが入力した第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、
   前記モバイル端末によって第２データテーブルを生成した後に、当該方法は、
   前記モバイル端末によって、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示することと、
   前記モバイル端末によって、前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得し、該第４操作に応答して、前記第１アプリケーションの前記第１アルバムに対応する画面上で前記第１ファイルを表示することと
   を有し、
   前記モバイル端末が前記リサイクルビン画面上で前記ユーザによって入力された前記第４操作を取得した後に、前記第１ファイルは、前記第１アプリケーションの前記第１アルバムに属する、
   請求項１に記載の方法。
3. 前記モバイル端末によって前記第１画面上で前記ユーザが入力した第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、
   前記モバイル端末によって第２データテーブルを生成した後に、当該方法は、
   前記モバイル端末によって、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示することと、
   前記モバイル端末によって、前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得し、該第４操作に応答して、前記第１アプリケーションのターゲットアルバムに対応する画面上で前記第１ファイルを表示することと
   を有し、
   前記モバイル端末が前記リサイクルビン画面上で前記ユーザによって入力された前記第４操作を取得した後に、前記第１ファイルは、前記第１アプリケーションの前記ターゲットアルバムに属する、
   請求項１に記載の方法。
4. 前記モバイル端末によって第２データテーブルを生成した後に、当該方法は、
   前記モバイル端末によって、前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示することと、
   前記モバイル端末によって、前記リサイクルビン画面上で前記ユーザが入力した第５操作を取得し、該第５操作に応答して前記モバイル端末から前記第１ファイルを削除することと
   を有する、
   請求項１に記載の方法。
5. 前記モバイル端末によって第２データテーブルを生成した後に、当該方法は、
   前記モバイル端末によって、前記ユーザが入力した第６操作を取得し、該第６操作に応答して前記第１ファイルのメタデータを表示することを有し、
   前記メタデータは、
   前記第１ファイルのオリジナルのファイル名、
   前記第１ファイルのオリジナルのファイル識別子、
   前記第１ファイルの削除時間、
   前記第１ファイルのソース記憶パス、
   前記第１ファイルの現在の記憶パス、
   前記第１ファイルの撮影時間、
   前記第１ファイルのピクチャ方向、
   前記第１ファイルのクラウドグローバル一意識別子、
   前記第１ファイルのハッシュ値、及び
   前記第１ファイルが属するソースアルバムのクラウド識別子
   のうちの少なくとも１つを有する、
   請求項１に記載の方法。
6. 前記モバイル端末によって第２データテーブルを生成した後に、当該方法は、
   前記モバイル端末によって選択画面を表示することと、
   前記モバイル端末によって、前記選択画面上で前記ユーザが入力した第７操作を取得し、該第７操作に応答して前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示することと
   を有する、
   請求項１に記載の方法。
7. 前記第２操作に応答して前記第１アプリケーションのリサイクルビン画面上で前記第１ファイルを表示することは、
   前記モバイル端末によって、前記第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、前記第１ファイルのファイル名を第１名称から第２名称へ変更することを有し、
   前記第２ディレクトリは、前記第１アプリケーションの前記リサイクルビン画面上で表示されるファイルを記憶するために使用される、
   請求項１乃至６のうちいずれか一項に記載の方法。
8. 前記第２名称は、前もってセットされた符号化方式を使用して前記第１ファイルのメタデータを符号化することによって取得されるターゲット文字列である、
   請求項７に記載の方法。
9. 前記モバイル端末によって第２データテーブルを生成することは、
   前記モバイル端末によって、前記前もってセットされた符号化方式を使用して前記第２名称を復号することによって前記第１ファイルの前記メタデータを取得することと、
   前記モバイル端末によって前記メタデータに基づき前記第２データテーブルを生成することと
   を有する、
   請求項８に記載の方法。
10. 前記第２名称は、前記第１ファイルの削除時間であり、
    当該方法は、
    前記モバイル端末によって、前もってセットされた符号化方式を使用して前記第１ファイルのメタデータを符号化することによってターゲット文字列を取得し、該ターゲット文字列及び前記第１ファイルの前記削除時間を前記第２ディレクトリのバイナリファイルにおいて対応付けて格納することを更に有する、
    請求項７に記載の方法。
11. 前記モバイル端末によって第２データテーブルを生成することは、
    前記モバイル端末によって前記第２名称に基づき前記第１ファイルの前記削除時間を決定することと、
    前記モバイル端末によって、前記第２ディレクトリの前記バイナリファイルにおいて、前記第１ファイルの前記削除時間に対応するターゲット文字列を決定することと、
    前記モバイル端末によって、前記前もってセットされた符号化方式を使用して前記ターゲット文字列を復号することによって前記第１ファイルの前記メタデータを取得することと、
    前記モバイル端末によって前記第１ファイルの前記メタデータに基づき前記第２データテーブルを生成することと
    を有する、
    請求項１０に記載の方法。
12. 前記モバイル端末によって第１データテーブルを削除する前に、当該方法は、
    前記モバイル端末によって、第３データテーブルを取得するよう前記第１データテーブルをバックアップすることを有し、
    前記モバイル端末によって第２データテーブルを生成することは、
    前記モバイル端末によって前記第３データテーブルに基づき前記第２データテーブルを生成することを有する、
    請求項１乃至６のうちいずれか一項に記載の方法。
13. タッチ検出面及び表示スクリーンを有するタッチスクリーンと、
    １以上のプロセッサと、
    メモリと、
    複数のアプリケーションプログラムと、
    １以上のコンピュータプログラムと
    を有するモバイル端末であって、
    前記１以上のコンピュータプログラムは、前記メモリに記憶され、前記１以上のコンピュータプログラムは、命令を有し、該命令が当該モバイル端末によって実行されるときに、当該モバイル端末は、
    ユーザが入力した第１操作を取得し、該第１操作に応答して第１アプリケーションの第１画面上で第１ファイルを表示するステップと、
    前記第１画面上で前記ユーザが入力した第２操作を取得し、該第２操作に応答して前記第１アプリケーションのリサイクルビン画面上で前記第１ファイルを表示するステップと、
    第１データテーブルを削除し、該第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなるステップと、
    前記ユーザが入力した第３操作を取得し、該第３操作に応答して第２データテーブルを生成し、該第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えるステップと
    を実行する、
    モバイル端末。
14. 前記第１画面上で前記ユーザが入力した第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、
    当該モバイル端末に前記第２データテーブルを生成させるように前記命令を実行した後に、前記プロセッサは、
    前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するステップと、
    前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得し、該第４操作に応答して、前記第１アプリケーションの前記第１アルバムに対応する画面上で前記第１ファイルを表示するステップと
    を更に実行し、
    前記リサイクルビン画面上で前記ユーザによって入力された前記第４操作が取得された後に、前記第１ファイルは、前記第１アプリケーションの前記第１アルバムに属する、
    請求項１３に記載のモバイル端末。
15. 前記第１画面上で前記ユーザが入力した第２操作を取得する前に、前記第１ファイルは、前記第１アプリケーションの第１アルバムに属し、
    当該モバイル端末に前記第２データテーブルを生成させるように前記命令を実行した後に、前記プロセッサは、
    前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するステップと、
    前記リサイクルビン画面上で前記ユーザが入力した第４操作を取得し、該第４操作に応答して、前記第１アプリケーションのターゲットアルバムに対応する画面上で前記第１ファイルを表示するように前記表示スクリーンを制御するステップと
    を更に実行し、
    前記リサイクルビン画面上で前記ユーザによって入力された前記第４操作が取得された後に、前記第１ファイルは、前記第１アプリケーションの前記ターゲットアルバムに属する、
    請求項１３に記載のモバイル端末。
16. 当該モバイル端末に前記第２データテーブルを生成させるように前記命令を実行した後に、前記プロセッサは、
    前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するステップと、
    前記リサイクルビン画面上で前記ユーザが入力した第５操作を取得し、該第５操作に応答して当該モバイル端末から前記第１ファイルを削除するステップと
    を更に実行する、
    請求項１３に記載のモバイル端末。
17. 当該モバイル端末に前記第２データテーブルを生成させるように前記命令を実行した後に、前記プロセッサは、
    前記ユーザが入力した第６操作を取得し、該第６操作に応答して前記第１ファイルのメタデータを表示するステップを更に実行し、
    前記メタデータは、
    前記第１ファイルのオリジナルのファイル名、
    前記第１ファイルのオリジナルのファイル識別子、
    前記第１ファイルの削除時間、
    前記第１ファイルのソース記憶パス、
    前記第１ファイルの現在の記憶パス、
    前記第１ファイルの撮影時間、
    前記第１ファイルのピクチャ方向、
    前記第１ファイルのクラウドグローバル一意識別子、
    前記第１ファイルのハッシュ値、及び
    前記第１ファイルが属するソースアルバムのクラウド識別子
    のうちの少なくとも１つを有する、
    請求項１３に記載のモバイル端末。
18. 前記プロセッサは、前記命令を実行して、当該モバイル端末に、
    前記第３操作に応答して、前記第１アプリケーションの前記リサイクルビン画面上で第２ファイルを表示することをスキップするステップを更に実行させ、
    前記第２ファイルは、前記第１ファイルと同じであって、クラウドサーバに記憶されているファイルである、
    請求項１３に記載のモバイル端末。
19. 当該モバイル端末に前記第２データテーブルを生成させるように前記命令を実行した後に、前記プロセッサは、
    選択画面を表示するステップと、
    前記選択画面上で前記ユーザが入力した第７操作を取得し、該第７操作に応答して前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示するステップと
    を更に実行する、
    請求項１３に記載のモバイル端末。
20. 当該モバイル端末によって前記第２操作に応答して前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルを表示する前記ステップにおいて、前記プロセッサは、前記命令を実行して、当該モバイル端末に、少なくとも、
    前記第１ファイルの記憶場所を第１ディレクトリから第２ディレクトリへ変更し、前記第１ファイルのファイル名を第１名称から第２名称へ変更するステップを実行させ、
    前記第２ディレクトリは、前記第１アプリケーションの前記リサイクルビン画面上で表示されるファイルを記憶するために使用される、
    請求項１３乃至１９のうちいずれか一項に記載のモバイル端末。
21. 前記第２名称は、前もってセットされた符号化方式を使用して前記第１ファイルのメタデータを符号化することによって取得されるターゲット文字列である、
    請求項２０に記載のモバイル端末。
22. 当該モバイル端末によって前記第２データテーブルを生成する前記ステップにおいて、前記プロセッサは、前記命令を実行して、当該モバイル端末に、少なくとも、
    前記前もってセットされた符号化方式を使用して前記第２名称を復号することによって前記第１ファイルの前記メタデータを取得するステップと、
    前記メタデータに基づき前記第２データテーブルを生成するステップと
    を実行させる、
    請求項２１に記載のモバイル端末。
23. 前記第２名称は、前記第１ファイルの削除時間であり、
    前記プロセッサは、前記命令を実行して、前記モバイル端末に、更に、
    前もってセットされた符号化方式を使用して前記第１ファイルのメタデータを符号化することによってターゲット文字列を取得し、該ターゲット文字列及び前記第１ファイルの前記削除時間を前記第２ディレクトリのバイナリファイルにおいて対応付けて格納するステップを実行させる、
    請求項２０に記載のモバイル端末。
24. 当該モバイル端末によって前記第２データテーブルを生成する前記ステップにおいて、前記プロセッサは、前記命令を実行して、当該モバイル端末に、少なくとも、
    前記第２名称に基づき前記第１ファイルの前記削除時間を決定するステップと、
    前記第２ディレクトリの前記バイナリファイルにおいて、前記第１ファイルの前記削除時間に対応するターゲット文字列を決定するステップと、
    前記前もってセットされた符号化方式を使用して前記ターゲット文字列を復号することによって前記第１ファイルの前記メタデータを取得するステップと、
    前記第１ファイルの前記メタデータに基づき前記第２データテーブルを生成するステップと
    を実行させる、
    請求項２３に記載のモバイル端末。
25. 当該モバイル端末によって前記第２データテーブルを生成する前記ステップにおいて、前記プロセッサは、前記命令を実行して、当該モバイル端末に、少なくとも、
    第３データテーブルを取得するよう前記第１データテーブルをバックアップするステップと、
    前記第３データテーブルに基づき前記第２データテーブルを生成するステップと
    実行させる、
    請求項１３乃至１９のうちいずれか一項に記載のモバイル端末。
26. ユーザが入力した第１操作を取得するよう構成される取得モジュールと、
    前記第１操作に応答して第１アプリケーションの第１画面上で第１ファイルを表示するよう構成される表示モジュールであり、
    前記取得モジュールが、前記第１画面上で前記ユーザが入力した第２操作を取得するよう更に構成され、
    前記表示モジュールが、前記第２操作に応答して前記第１アプリケーションのリサイクルビン画面上で前記第１ファイルを表示するよう更に構成される、前記表示モジュールと、
    第１データテーブルを削除するよう構成される削除モジュールであり、前記第１データテーブルの削除により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見えなくなり、
    前記取得モジュールが、前記ユーザが入力した第３操作を取得するよう更に構成される、前記削除モジュールと、
    前記第３操作に応答して第２データテーブルを生成するよう構成される生成モジュールであり、前記第２データテーブルの存在により前記第１アプリケーションの前記リサイクルビン画面上で前記第１ファイルが前記ユーザから見える、前記生成モジュールと
    を有し、
    前記取得モジュールが、前記ユーザが入力した第３操作を取得した後に、前記表示モジュールは、
    前記第３操作に応答して、前記第１アプリケーションの前記リサイクルビン画面上で第２ファイルを表示することをスキップするよう更に構成され、
    前記第２ファイルは、前記第１ファイルと同じであって、クラウドサーバに記憶されているファイルである、モバイル端末。
27. 命令を有し、該命令がコンピュータで実行されるときに、該コンピュータが、請求項１乃至１２のうちいずれか一項に記載の方法を実行する、コンピュータ可読記憶媒体。
28. 命令を有するコンピュータプログラム製品であって、
    当該コンピュータプログラム製品がコンピュータで実行されるときに、該コンピュータが、請求項１乃至１２のうちいずれか一項に記載の方法を実行する、
    コンピュータプログラム製品。

Images