特許 5873571 アプリケーション・データを処理するための方法及び計算ノード

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5873571

(24)【登録日】2016年1月22日

(45)【発行日】2016年3月1日

(54)【発明の名称】アプリケーション・データを処理するための方法及び計算ノード

(51)【国際特許分類】

   G06F 9/54 20060101AFI20160216BHJP

【ＦＩ】

   G06F9/46 480Z

【請求項の数】11

【全頁数】16

(21)【出願番号】特願2014-547676(P2014-547676)

(86)(22)【出願日】2012年7月2日

(65)【公表番号】特表2015-507257(P2015-507257A)

(43)【公表日】2015年3月5日

(86)【国際出願番号】CN2012078010

(87)【国際公開番号】WO2013102341

(87)【国際公開日】20130711

【審査請求日】2014年6月18日

(31)【優先権主張番号】201210000757.1

(32)【優先日】2012年1月4日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】512165101

【氏名又は名称】▲華▼▲為▼終端有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩ ＤＥＶＩＣＥ ＣＯ．， ＬＴＤ．

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】王 ▲チン▼

【審査官】 篠塚 隆

(56)【参考文献】

【文献】 特開２００７−１１６５０（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ３／０６

９／４６

９／４８

９／５０−９／５２

９／５４

１２／００

(57)【特許請求の範囲】

【請求項1】

計算ノードであって、オペレーティング・システムと、前記オペレーティング・システム上で実行されるサービス・プロセス、バックアップ・ソフトウェア、及びアプリケーション・ソフトウェアとを含む、計算ノード、に適用されるアプリケーション・データを処理するための方法であって、前記方法は：
前記オペレーティング・システムによる、前記サービス・プロセスを開始するステップ；
前記オペレーティング・システムによる、前記サービス・プロセスと前記バックアップ・ソフトウェアとの間のソケット接続を設定するステップであって、前記サービス・プロセスがルート操作権を有し、かつ前記サービス・プロセスと前記バックアップ・ソフトウェアが同じユーザ識別子（ｕｉｄ）を有する、ステップ；
前記バックアップ・ソフトウェアによる、前記ソケットにより、アプリケーション・データに関する処理要求を送信するステップ；
前記サービス・プロセスによる、前記ソケットにより、アプリケーション・データに関する前記処理要求を受信するステップであって、前記処理要求は、前記バックアップ・ソフトウェアにより送信される、ステップ；
前記サービス・プロセスによる、アプリケーション・データに関する前記処理要求を、対応するアプリケーション・ソフトウェアに対して送信するステップ；
前記サービス・プロセスによる、前記対応するアプリケーション・ソフトウェアにより返されたアプリケーション・データを受信するステップであって、前記アプリケーション・データは、前記処理要求に応答して返されたアプリケーション・データである、ステップ；及び
前記サービス・プロセスによる、前記ソケットにより、前記返されたアプリケーション・データを前記バックアップ・ソフトウェアに送信するステップ；
を備えることを特徴とする、方法。

【請求項2】

前記バックアップ・ソフトウェアによる、前記ソケットにより、アプリケーション・データに関する前記処理要求を送信するステップは、具体的には：
前記バックアップ・ソフトウェアによる、前記ソケットにより、アプリケーション・データに関する前記処理要求の処理を要求するコマンドとしての長さを送信するステップ；及び
前記バックアップ・ソフトウェアによる、前記ソケットにより、アプリケーション・データに関する前記処理要求の前記長さに対応する具体的な内容を送信するステップ；
を含むことを特徴とする、請求項１記載の方法。

【請求項3】

前記サービス・プロセスによる、前記ソケットにより、前記返されたアプリケーション・データを前記バックアップ・ソフトウェアに送信することは、具体的には：
前記サービス・プロセスによる、前記返されたアプリケーション・データの長さを、前記ソケットにより、前記バックアップ・ソフトウェアに送信するステップ；及び
前記サービス・プロセスによる、前記返されたアプリケーション・データの具体的な内容を前記バックアップ・ソフトウェアに送信するステップ；
を含むことを特徴とする、請求項１又は２記載の方法。

【請求項4】

アプリケーション・データに関する前記処理要求がカタログ読み取り要求又はファイル読み取り要求を含み、従って、前記対応するアプリケーション・ソフトウェアによって返された前記アプリケーション・データが、読み取ったカタログ情報又は読み取ったファイル内容
を含むことを特徴とする、請求項１乃至３のいずれか１項記載の方法。

【請求項5】

アプリケーション・データに関する前記処理要求がカタログ書き込み要求又はファイル書き込み要求を含み、従って、前記対応するアプリケーション・ソフトウェアによって返された前記アプリケーション・データが、前記カタログ書き込み要求に対応する結果又は前記ファイル書き込み要求に対応する結果
を含むことを特徴とする、請求項１乃至３のいずれか１項記載の方法。

【請求項6】

前記サービス・プロセスによる、前記対応するアプリケーション・ソフトウェアにアプリケーション・データに関する前記処理要求を送信するステップは、具体的には；
前記サービス・プロセスによる、前記処理要求についてシグネチャ検証を実行するステップ；及び
前記シグネチャ検証に合格した場合に、アプリケーション・データに関する前記処理要求を前記対応するアプリケーション・ソフトウェアに送信するステップ；
を含むことを特徴とする、請求項１乃至５のいずれか１項記載の方法。

【請求項7】

ハードウェア層、前記ハードウェア層上で動作するオペレーティング・システム、及び前記オペレーティング・システム上で実行されるサービス・プロセス、バックアップ・ソフトウェア、及びアプリケーション・ソフトウェアを含む計算ノードであって：
前記オペレーティング・システムが前記サービス・プロセスを開始できるように構成された開始モジュールと、
前記オペレーティング・システムが前記サービス・プロセスと前記バックアップ・ソフトウェアとの間のソケット接続を設定できるように構成された接続設定モジュールであって、前記サービス・プロセスがルート操作権を有し、かつ前記サービス・プロセスと前記バックアップ・ソフトウェアが同じユーザ識別名（ｕｉｄ）を有する、接続設定モジュール；
前記バックアップ・ソフトウェアが、アプリケーション・データに関する処理要求を、前記ソケットにより、送信すること、を可能とするように構成された第１の送信モジュール；
前記サービス・プロセスが、アプリケーション・データに関する前記処理要求を、前記ソケットにより、受信すること、を可能とするように構成された第１の受信モジュールであって、前記処理要求が前記バックアップ・ソフトウェアによって送信される、第１の受信モジュール；
前記サービス・プロセスが、対応するアプリケーション・ソフトウェアに、アプリケーション・データに関する前記処理要求を送信すること、を可能とするように構成された第２の送信モジュール；
前記サービス・プロセスが、前記対応するアプリケーション・ソフトウェアにより返されたアプリケーション・データを受信すること、を可能とするように構成された第２の受信モジュールであって、前記アプリケーション・データは前記処理要求に応答して返されたアプリケーション・データである、第２の受信モジュール；及び
前記サービス・プロセスが、前記返されたアプリケーション・データを、前記バックアップ・ソフトウェアに、前記ソケットにより、送信すること、を可能とするように構成された第３の送信モジュール；
を備えることを特徴とする、計算ノード。

【請求項8】

前記第１の送信モジュールが：
前記バックアップ・ソフトウェアが、アプリケーション・データに関する前記処理要求の処理を要求するコマンドとしての長さを、前記ソケットにより、送信すること、を可能とするように構成された第１の送信ユニット；及び
前記バックアップ・ソフトウェアが、アプリケーション・データに関する前記処理要求の前記長さに対応する具体的な内容を、前記ソケットにより、送信すること、を可能とするように構成された第２の送信ユニット；
を含むことを特徴とする、請求項７記載の計算ノード。

【請求項9】

前記第３の送信モジュールが：
前記サービス・プロセスが、前記返されたアプリケーション・データの長さを、前記バックアップ・ソフトウェアに、前記ソケットにより、送信すること、を可能とするように構成された第３の送信ユニット；及び
前記サービス・プロセスが、前記返されたアプリケーション・データの具体的な内容を、前記バックアップ・ソフトウェアに、前記ソケットにより、送信すること、を可能とするように構成された第４の送信ユニット；
を含むことを特徴とする、請求項７又は８記載の計算ノード。

【請求項10】

前記第２の送信モジュールは、具体的には：
前記サービス・プロセスが、前記処理要求について、シグネチャ検証を実行すること、を可能とするように構成された検証ユニット；及び
前記シグネチャ検証に合格した場合に、アプリケーション・データに関する前記処理要求を前記対応するアプリケーション・ソフトウェアに送信するように構成された第５の送信ユニット；
を含むことを特徴とする、請求項７乃至９のいずれか１項記載の計算ノード。

【請求項11】

前記計算ノードがモバイル端末である、請求項７乃至１０のいずれか１項記載の計算ノード。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動体通信技術の分野に関し、特に、アプリケーション・データを処理するための方法及び計算ノード（ｃｏｍｐｕｔａｔｉｏｎ ｎｏｄｅ）に関する。

【背景技術】

【0002】

現今、新しい携帯電話の開発はますます急速になり、開発の過程で、バージョンのアップグレード又は携帯電話の交換により、アプリケーション・データの喪失が引き起こされる可能性がある。アプリケーション・データの喪失という問題を解決するために、携帯電話上のアプリケーション・データをバックアップするためのバックアップ・ソフトウェアを携帯電話にインストールすることができる。アプリケーション・データはアプリケーション・ソフトウェアのデータ・パケットである。また、アプリケーション・ソフトウェアは、天気時計及びゲーム・ソフトウェアなどのアプリケーションと呼ぶこともできる。Ａｎｄｒｏｉｄ携帯電話上の既存のバックアップ技術は、バックアップ・ソフトウェアがファイル・コピーによりルート（ｒｏｏｔ）操作権（ｒｏｏｔ ｏｐｅｒａｔｉｏｎ ｒｉｇｈｔ）を有するＡｎｄｒｏｉｄ携帯電話内のアプリケーション・データをバックアップするというものであってもよく、携帯電話がルート操作権を有する場合、ソフトウェアは、相互にアクセスすることができ、従って、バックアップ・ソフトウェアはアプリケーション・ソフトウェアにアクセスして、アプリケーション・ソフトウェア内のアプリケーション・データをバックアップしてもよく、或いは、アプリケーション・ソフトウェア自体がバックアップ・ソフトウェアに対するプロバイダ・インターフェース（Ｐｒｏｖｉｄｅｒ ｉｎｔｅｒｆａｃｅ）を提供し、バックアップ・ソフトウェアはプロバイダ・インターフェースを介してアプリケーション・データをバックアップする。

【0003】

しかし、従来技術では、Ａｎｄｒｏｉｄ携帯電話上のアプリケーション・データのバックアップは、携帯電話がルート操作権を有する必要があるか又はアプリケーション・ソフトウェアがプロバイダ・インターフェースを提供する必要がある。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】中国特許出願第２０１２１００００７５７．１号

【発明の概要】

【発明が解決しようとする課題】

【0005】

本発明の諸実施形態は、計算ノードがルート操作権を有しておらず、計算ノード上のアプリケーション・ソフトウェアがプロバイダ・インターフェースを提供しない時に、データ・バックアップ及びリカバリを達成するために、アプリケーション・データを処理するための方法及び計算ノードを提供する。

【課題を解決するための手段】

【0006】

本発明の一実施形態は、計算ノードであって、オペレーティングシステム、オペレーティング・システム上で実行されるサービス・プロセス、バックアップ・ソフトウェア、及びアプリケーション・ソフトウェアとを含む、計算ノードに適用される、アプリケーション・データを処理するための方法を提供し、前記方法は：
オペレーティング・システムによる、サービス・プロセスを開始するステップ；
オペレーティング・システムによる、前記サービス・プロセスと前記バックアップ・ソフトウェアとの間のソケット（ｓｏｃｋｅｔ）接続（ｓｏｃｋｅｔ ｃｏｎｎｅｃｔｉｏｎ）を設定するステップであって、前記サービス・プロセスがルート（ｒｏｏｔ）操作権を有し、かつ前記サービス・プロセスと前記バックアップ・ソフトウェアが同じユーザ識別子（ｕｉｄ）を有する、ステップ；
前記バックアップ・ソフトウェアによる、前記ソケットにより、アプリケーション・データに関する処理要求を送信するステップ；
前記サービス・プロセスによる、前記ソケットにより、アプリケーション・データに関する前記処理要求を受信するステップであって、前記処理要求が前記バックアップ・ソフトウェアによって送信される、ステップ；
前記サービス・プロセスによる、アプリケーション・データに関する前記処理要求を対応するアプリケーション・ソフトウェアに送信するステップ；
前記サービス・プロセスによる、前記対応するアプリケーション・ソフトウェアによって返されたアプリケーション・データを受信するステップであって、前記アプリケーション・データが前記処理要求に応答して返されたアプリケーション・データである、ステップ；及び
前記サービス・プロセスによる、前記返されたアプリケーション・データを、前記ソケットにより、前記バックアップ・ソフトウェアに送信するステップ；
を備える。

【0007】

本発明の一実施形態は、ハードウェア層、ハードウェア層上で動作するオペレーティング・システム、及びオペレーティング・システム上で実行されるサービス・プロセス、バックアップ・ソフトウェア、及びアプリケーション・ソフトウェアを含む計算ノードであって、かつ：
前記オペレーティング・システムが、前記サービス・プロセスを開始すること、を可能とするように構成された開始モジュール；
前記オペレーティング・システムが、前記サービス・プロセスと前記バックアップ・ソフトウェアとの間のソケット（ｓｏｃｋｅｔ）接続を設定すること、を可能とするように構成された接続設定モジュールであって、前記サービス・プロセスがルート（ｒｏｏｔ）操作権を有し、かつ前記サービス・プロセス及び前記バックアップ・ソフトウェアが同じユーザ識別名（ｕｉｄ）を有する、接続設定モジュール；
前記バックアップ・ソフトウェアが、アプリケーション・データに関する処理要求を、前記ソケットにより、送信すること、を可能とするように構成された第１の送信モジュール；
前記サービス・プロセスが、アプリケーション・データに関する前記処理要求を、前記ソケットにより、受信すること、を可能とするように構成された第１の受信モジュールであって、前記処理要求が前記バックアップ・ソフトウェアによって送信される、第１の受信モジュール；
前記サービス・プロセスが、対応するアプリケーション・ソフトウェアに、アプリケーション・データに関する前記処理要求を送信すること、を可能とするように構成された第２の送信モジュール；
前記サービス・プロセスが、前記対応するアプリケーション・ソフトウェアにより返されたアプリケーション・データを受信すること、を可能とするように構成された第２の受信モジュールであって、前記アプリケーション・データは前記処理要求に応答して返されたアプリケーション・データである、第２の受信モジュール；及び
前記サービス・プロセスが、前記返されたアプリケーション・データを、前記バックアップ・ソフトウェアに、前記ソケットにより、送信すること、を可能とするように構成された第３の送信モジュール；
を含む、計算ノードを提供する。

【0008】

本発明の実施形態は、サービスプロセスを開始することにより、サービス・プロセスがルート操作権を有しているため、サービス・プロセスが計算ノード内の様々なアプリケーション・ソフトウェアにアクセスできることを保証することができ、かつサービス・プロセスがバックアップ・ソフトウェアとのソケット接続を設定しし、そしてバックアップ・ソフトウェアと同じｕｉｄを有しているため、サービス・プロセスとバックアップ・ソフトウェアとの間の対話処理を保証することができることは、上記の技術的解決策から理解されてもよい。従って、バックアップ・ソフトウェアはサービス・プロセスを介してアプリケーション・ソフトウェアと対話処理を実行することができ、それにより、バックアップ・ソフトウェアによるアプリケーション・ソフトウェア内のアプリケーション・データのバックアップ又はリカバリを達成することができる。

【0009】

本発明の諸実施形態における技術的解決策をより明瞭に例示するために、諸実施形態を説明するための添付図面について以下に簡単に紹介する。明らかに、以下の説明における添付図面は本発明のいくつかの実施形態を示しており、当業者であれば、創造的努力なしに添付図面からその他の図面を導き出すことができる。

【図面の簡単な説明】

【0010】

【図1】本発明のアプリケーション・データを処理するための方法の一実施形態の概略流れ図である。

【図2】本発明によるシステムの概略構造図である。

【図3】本発明のアプリケーション・データを処理するための方法の他の実施形態の概略流れ図である。

【図4】本発明のアプリケーション・データを処理するための方法の他の実施形態の概略流れ図である。

【図5】本発明の計算ノードの一実施形態の概略構造図である。

【図6】本発明の計算ノードの他の実施形態の概略構造図である。

【図7】本発明の計算ノードの他の実施形態の概略構造図である。

【図8】本発明の計算ノードの他の実施形態の概略構造図である。

【発明を実施するための形態】

【0011】

本発明の目的、技術的解決策、及び利点をより分かり易くするために、本発明の諸実施形態における添付図面を参照することにより、本発明の諸実施形態に従う技術的解決策について以下に明瞭かつ完全に説明する。明らかに、以下の説明における諸実施形態は、本発明の諸実施形態のすべてではなく、一部に過ぎない。創造的努力なしに本発明の諸実施形態に基づいて当業者が取得したその他の実施形態はいずれも本発明の保護範囲に属するものとしなければならない。

【0012】

図１は、本発明のアプリケーション・データを処理するための方法の一実施形態の概略流れ図であり、以下のステップを含む。

【0013】

ステップ１１： オペレーティング・システムがサービス・プロセスを開始する。

【0014】

ステップ１２： オペレーティング・システムが、サービス・プロセスとバックアップ・ソフトウェアとの間のソケット（ｓｏｃｋｅｔ）接続を確立し、サービス・プロセスがルート（ｒｏｏｔ）操作権を有し、サービス・プロセスとバックアップ・ソフトウェアが同じユーザ識別名（Ｕｓｅｒ Ｉｄｅｎｔｉｆｉｅｒ、ｕｉｄ）を有する。

【0015】

本発明のこの実施形態では、計算ノードであるＡｎｄｒｏｉｄ携帯電話が一例として挙げられており、Ａｎｄｒｏｉｄ携帯電話はルート操作権を有していない可能性があり、この場合、携帯電話内のバックアップ・ソフトウェアはアプリケーション・ソフトウェアからデータを取得するためにアプリケーション・ソフトウェアと直接的には対話処理を実行することができない。その上、Ａｎｄｒｏｉｄ携帯電話はプロバイダ・インターフェースを提供するためにアプリケーション・ソフトウェアを必要としない可能性もあり、この場合、携帯電話内のバックアップ・ソフトウェアはアプリケーション・ソフトウェアからデータを直接取得することもできない。

【0016】

Ａｎｄｒｏｉｄ携帯電話がルート操作権を有しておらず、アプリケーション・ソフトウェアがプロバイダ・インターフェースを提供しない場合、アプリケーション・ソフトウェアのアプリケーション・データのバックアップ及びリカバリを達成するために、本発明のこの実施形態では携帯電話の最下層でプロセスを開始してもよく、このプロセスはサービス（Ｓｅｒｖｉｃｅ）プロセスと呼ばれてもよい。

【0017】

サービス・プロセスは、バックアップ・ソフトウェアが開始された場合に同時に開始されてもよく、或いはバックアップ・ソフトウェア内の特定の機能が開始された後に開始されてもよい。サービス・プロセスの具体的なの実行方法は、携帯電話の最下層でＣコードを使用することによりＬｉｎｕｘ（登録商標）プロセスを実行することである。Ｌｉｎｕｘ（登録商標）プロセスはｉｎｉｔ．ｒｃにより起動される。このＬｉｎｕｘ（登録商標）プロセスはサービス・プロセスと呼ばれてもよい。具体的には、サービス・プロセス名をカスタマイズすることができ、アプリケーション・データの読み取り、書き込み、及び削除のための操作権を持たせるためにサービス・プロセスに特定の操作権を割り当てることができ、その間に、バックアップ・ソフトウェアと通信するためにプロセスに特別なＵＩＤが割り当てられる。このプロセスは、特定の操作権が割り当てられ、特別なＵＩＤも割り当てられるという点で、一般的なプロセスとは異なっている。

【0018】

加えて、一般的に言えば、開始されたプロセスに対応する操作権及びそのプロセスのｕｉｄは、プロセスを開始する過程で設定することができる。本発明のこの実施形態では、図２を参照すると、開始されたサービス・プロセスの操作権はルート操作権として設定され、そのプロセスのｕｉｄはバックアップ・ソフトウェアのｕｉｄと同じである。

【0019】

サービス・プロセスの操作権をルート操作権として設定することにより、サービス・プロセスが計算ノード内のすべての種類のアプリケーション・ソフトウェア及びバックアップ・ソフトウェアと対話処理を行えることを保証してもよく、その結果、サービス・プロセスがアプリケーション・ソフトウェアからアプリケーション・データを読み取り、読み取ったアプリケーション・データをバックアップ・ソフトウェアに書き込むことができ、バックアップ・ソフトウェアからアプリケーション・ソフトウェアにアプリケーション・データを書き込むこともできるようになる。サービス・プロセスのｕｉｄがバックアップ・ソフトウェアのｕｉｄと同じになるように設定することにより、ソケットにより接続が確立した後にサービス・プロセスとバックアップ・ソフトウェアが相互に対話処理を行えることを保証してもよく、その結果、サービス・プロセスがバックアップ・ソフトウェアにアプリケーション・データを送信してもよく、また、バックアップ・ソフトウェアによって送信されたアプリケーション・データを受信してもよい。例えば、サービス・プロセスとバックアップ・ソフトウェアとの間の接続はｓｏｃｋｅｔ／ｄｅｖ／ｓｏｃｋｅｔ／ｆｉｌｅｂａｃｋというコマンドにより確立することができる。

【0020】

ステップ１３： バックアップ・ソフトウェアがアプリケーション・データに関する処理要求を、ソケットにより、送信する。

【0021】

ステップ１４： サービス・プロセスがアプリケーション・データに関する処理要求を、ソケットにより、受信する。ここで、当該処理要求は、バックアップ・ソフトウェアにより送信される。

【0022】

ステップ１５： サービス・プロセスが対応するアプリケーション・ソフトウェアにアプリケーション・データに関する処理要求を送信する。

【0023】

ステップ１６： サービス・プロセスが対応するアプリケーション・ソフトウェアによって返されたアプリケーション・データを受信する。

【0024】

ステップ１７： サービス・プロセスが、返されたアプリケーション・データをバックアップ・ソフトウェアに、ソケットにより、送信する。

【0025】

図２を参照すると、バックアップ・ソフトウェアとサービス・プロセスは、ソケット接続により、相互に対話処理を行うことができ、サービス・プロセスはルート操作権を有しているので、アプリケーション・ソフトウェアと対話することができる。

【0026】

バックアップ・ソフトウェア、サービス・プロセス、及びアプリケーション・データの間でやり取りされた具体的なコマンド、データなどは、データをバックアップするか又はデータをリカバリする目的に応じて異なる可能性があり、具体的な対話処理の流れについては、バックアップ及びリカバリに関する以下の流れを参照することができる。

【0027】

更に、セキュリティを保証するために、バックアップ・ソフトウェアとサービス・プロセスとの間のインターフェース及びサービス・プロセスとアプリケーション・ソフトウェアとの間のインターフェースは、シグネチャによって保護されるように設定することができる。この場合、まず受信した情報についてシグネチャ検証を実行する必要があり、次に検証に合格した後に処理が実行される。例えば、サービス・プロセスは、ソケットにより、アプリケーション・データに関する処理要求であって、バックアップ・ソフトにより送信される、処理要求、を受信し；サービス・プロセスは処理要求についてシグネチャ検証を実行し、次にシグネチャ検証に合格した後に対応するアプリケーション・ソフトウェアにアプリケーション・データに関する処理要求を送信する。他の例の場合、サービス・プロセスの処理要求を受信した後に、アプリケーション・ソフトウェアはまずシグネチャ検証を実行し、次にシグネチャ検証に合格した後にそのアプリケーション・データをサービス・プロセスに送信する。他の例に関して、サービス・プロセスによって返されたアプリケーション・データを受信した場合に、バックアップ・ソフトウェアはまずシグネチャ検証を実行し、次にシグネチャ検証に合格した後にアプリケーション・データを保存する。

【0028】

サービス・プロセスを開始することにより、この実施形態は、サービス・プロセスがルート操作権を有しているのでサービス・プロセスが計算ノード内の様々なアプリケーション・ソフトウェアにアクセスできることを保証することができ、サービス・プロセスがバックアップ・ソフトウェアとのソケット接続を確立し、バックアップ・ソフトウェアと同じｕｉｄを有しているのでサービス・プロセスとバックアップ・ソフトウェアとの間の対話処理を保証することができる。従って、バックアップ・ソフトウェアは、サービス・プロセスにより、アプリケーション・ソフトウェアと対話処理を行うことができ、それにより、バックアップ・ソフトウェアによるアプリケーション・ソフトウェア内のアプリケーション・データのバックアップ及びリカバリを達成することができる。

【0029】

図３は、本発明のアプリケーション・データを処理するための方法の他の実施形態の概略流れ図であり、この実施形態はバックアップの流れを一例として挙げている。バックアップ・ソフトウェアとサービス・プロセスは、まず情報のやり取りのために接続を確立する必要があるので、この実施形態によって含まれる以下のステップはサービス・プロセスを開始するためのステップ及びサービス・プロセスとバックアップ・ソフトウェアとの間のソケット接続の設定のためのステップの後であるということを理解すべきである。

【0030】

アプリケーション・データに関する処理要求はカタログ読み取り要求又はファイル読み取り要求を含み、従って、対応するアプリケーション・ソフトウェアによって返されたアプリケーション・データは、読み取ったカタログ情報又は読み取ったファイル内容を含む。アプリケーション・データを読み取るための全体的な流れについては以下に詳細に説明する。

【0031】

図３を参照すると、この流れは以下のステップを含む。

【0032】

ステップ３１： バックアップ・ソフトウェアは、ソケット接続により、カタログ読み取り要求をサービス・プロセスに送信する。

【0033】

バックアップ・ソフトウェアがコマンド・ワード及びパラメータをサービス・プロセスに送信する場合、バックアップ・ソフトウェアはまずコマンド・ワード及びパラメータの長さをサービス・プロセスに送信し、次にコマンド・ワード及びパラメータの具体的な内容を送信することができる。

【0034】

例えば、カタログ読み取り要求が送信される場合、カタログ読み取り要求はｏｐｅｎｄｉｒ＋ｃａｔａｌｏｇｕｅと表すことができ、ここで、「ｏｐｅｎｄｉｒ」はコマンド・ワードであり、「ｃａｔａｌｏｇｕｅ」はカタログ・パス・パラメータである。この場合、まず「ｏｐｅｎｄｉｒ＋ｃａｔａｌｏｇｕｅ」の長さを送信することができ、ここで、その長さは符号なしショート１６ビット（ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ １６ｂｉｔ）の形で表すことができ、次に「ｏｐｅｎｄｉｒ＋ｃａｔａｌｏｇｕｅ」を送信することができる。

【0035】

ステップ３２： サービス・プロセスは、カタログ読み取り要求に従って、対応するアプリケーション・ソフトウェアにカタログ読み取り要求を送信する。

【0036】

サービス・プロセスは、コマンド・ワード及びパラメータの受信した長さに従って、対応する長さの内容を読み取り、その内容をコマンド・ワード及びパラメータの具体的な内容と判断し、即ち、カタログ読み取り要求の具体的な内容と判断することができる。

【0037】

例えば、カタログ読み取り要求は、カタログ・パス・パラメータ「ｃａｔａｌｏｇｕｅ」など、カタログの情報を伝達し、サービス・プロセスは、カタログの情報に応じてカタログのハンドルを取得し、次にハンドルによって示されたアプリケーション・ソフトウェアにカタログ読み取り要求を送信することができる。

【0038】

ステップ３３： アプリケーション・ソフトウェアがサービス・プロセスに結果を返す。

【0039】

返された結果は、カタログに基づくすべてのファイル及び関連属性であってもよい。例えば、バックアップ・ソフトウェアによって送信されたカタログ読み取り要求がアプリケーション・ソフトウェアＡのカタログを読み取るためのものである場合、アプリケーション・ソフトウェアＡは、カタログ１に含まれるファイル情報、カタログ２に含まれるファイル情報、及びカタログ３に含まれるファイル情報など、アプリケーション・ソフトウェアＡに含まれるカタログをサービス・プロセスに返す。カタログ読み取り要求は一般に一度に１つのカタログを読み取るためのものであるので、返された結果は一般に１つのカタログに関する情報であることを理解すべきである。

【0040】

ステップ３４： サービス・プロセスは、読み取った内容を、ソケット接続により、バックアップ・ソフトウェアに送信する。

【0041】

読み取った内容は、カタログ１に含まれるファイル情報、カタログ２に含まれるファイル情報、並びにカタログ３に含まれるファイル情報など、アプリケーションによってサービス・プロセスに返された結果に含まれるカタログの情報であってもよい。

【0042】

更に、サービス・プロセスは、読み取った内容をバッファ（ｂｕｆｆｅｒ）に記憶し、次にバッファ内に記憶されたデータ、即ち読み取った内容をバックアップ・ソフトウェアに送信することができる。バッファは、データを記憶するためのデータ・フィールドと解釈することができる。

【0043】

加えて、サービス・プロセスは、まず読み取った内容の長さであって、符号なしショート１６ビット（ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ １６ｂｉｔ）の形で表すことができる、長さ、を送信することができ、そして次に、読み取った内容をバックアップ・ソフトウェアに送信することができる。バックアップ・ソフトウェアは、読み取った内容の長さに従って、対応する長さのデータを読み取り、次にバックアップ・ソフトウェアは読み取ったデータをバックアップすることができる。

【0044】

ステップ３５： バックアップ・ソフトウェアがサービス・プロセスにファイル読み取り要求を送信する。

【0045】

カタログ読み取り要求と同様に、バックアップ・ソフトウェアは、まずファイル読み取り要求の長さを送信し、次にファイル読み取り要求の具体的な内容を送信することができる。

【0046】

ステップ３６： サービス・プロセスが対応するアプリケーション・ソフトウェアにファイル読み取り要求を送信する。

【0047】

バックアップ・ソフトウェアによって送信されるファイル読み取り要求はファイル情報を伝達し、例えば、ファイル読み取り要求はｏｐｅｎ＋ｆｉｌｅ ｐａｔｈであり、ここで、ｆｉｌｅ ｐａｔｈはオープンすべきファイルのパス情報を示してもよい。次にサービス・プロセスはファイル読み取り要求内のファイル・パスから対応するアプリケーション・ソフトウェアを見つけることができる。

【0048】

ステップ３７： アプリケーション・ソフトウェアがサービス・プロセスに結果を返す。

【0049】

返された結果は、ファイルの内容、ファイルのフォーマット、及びファイルの操作権など、ファイルの内容に関連する情報を含んでもよい。

【0050】

ステップ３８： サービス・プロセスがバックアップ・ソフトウェアにファイルの内容を返す。

【0051】

例えば、返されたファイルの内容は、ファイルの内容、ファイルのフォーマット、ファイルの操作権などを含む。

【0052】

この実施形態においてサービス・プロセスを開始することにより、サービス・プロセスは、アプリケーション・ソフトウェアからデータを読み取り、かつバックアップ・ソフトウェアに当該データを送信してもよく、そしてバックアップ・ソフトウェアは当該データをバックアップしてもよく、これによりデータ・バックアップの処理を実現する。

【0053】

図４は、本発明のアプリケーション・データを処理するための方法の他の実施形態の概略流れ図であり、この実施形態は一例としてリカバリの流れを挙げている。バックアップ・ソフトウェアとサービス・プロセスはまず情報のやり取りのために接続を設定する必要があるので、この実施形態によって含まれる以下のステップはサービス・プロセスを開始するステップ並びにサービス・プロセスとバックアップ・ソフトウェアとの間のソケット接続を設定するステップの後であることを理解すべきである。

【0054】

アプリケーション・データに関する処理要求はカタログ書き込み要求又はファイル書き込み要求を含み、従って、対応するアプリケーション・ソフトウェアによって返されたアプリケーション・データは、カタログ書き込み要求に対応する結果又はファイル書き込み要求に対応する結果を含む。アプリケーション・データをリカバリするための全体的な流れを以下に詳細に説明する。

【0055】

図４を参照すると、この流れは以下のステップを含む。

【0056】

ステップ４１： バックアップ・ソフトウェアは、ソケット接続により、カタログ書き込み要求をサービス・プロセスに送信する。

【0057】

カタログ書き込み要求を送信する場合、カタログ読み取り要求の処理と同様に、バックアップ・ソフトウェアはまずカタログ書き込み要求の長さを送信し、次にカタログ書き込み要求の具体的な内容を送信することができる。

【0058】

加えて、カタログ書き込み要求の具体的な内容は、例えば、カタログ１、カタログ２、カタログ３などを含む複数のカタログなどのファイル情報を含んでもよい。そして、カタログ１はファイル１、ファイル２などを含む。任意選択で、カタログ書き込みは一般に一度に１つのカタログを書き込むので、カタログ書き込み要求は一般に１つのカタログの情報を含む。例えば、カタログ書き込み要求のフォーマットは、ｗｒｉｔｅＤｉｒ＋ｃａｔａｌｏｇｕｅ ｎａｍｅである。加えて、複数のカタログを同じ要求に入れ、特殊文字で分離することができ、例えば、カタログ書き込み要求のフォーマットは、ｗｒｉｔｅＤｉｒ＋ｃａｔａｌｏｇｕｅ ｎａｍｅ １； ｃａｔａｌｏｇｕｅ ｎａｍｅ ２； ｃａｔａｌｏｇｕｅ ｎａｍｅ ３になる。

【0059】

ステップ４２： サービス・プロセスは、カタログ書き込み要求に従って、対応するアプリケーション・ソフトウェアにカタログ書き込み要求を送信する。

【0060】

サービス・プロセスは、カタログ書き込み要求に含まれるカタログ名に応じて対応するハンドルを決定し、次に対応するハンドルによって示されているアプリケーションにカタログ書き込み要求を送信してもよい。、ここで、カタログ書き込み要求はカタログに含まれるファイル情報をんでもよい。

【0061】

例えば、カタログ書き込み要求はアプリケーションＡに送信され、ここで、カタログ書き込み要求はカタログ１、カタログ２、カタログ３などを伝達し、かつ含み、カタログ１はファイル１、ファイル２などを含む。

【0062】

ステップ４３： アプリケーション・ソフトウェアがサービス・プロセスに結果を返す。

【0063】

ステップ４４： サービス・プロセスがバックアップ・ソフトウェアに結果を返す。

【0064】

ステップ４３〜４４における結果は、カタログ書き込みが成功したかどうかを示す情報であってもよい。

【0065】

ステップ４５： バックアップ・ソフトウェアがサービス・プロセスにファイル書き込み要求を送信する。

【0066】

ファイル書き込み要求のフォーマットは、ｗｒｉｔｅ＋ｆｉｌｅ ｎａｍｅ＋ｆｉｌｅ ｃｏｎｔｅｎｔにすることができる。

【0067】

ファイル内容は、図３に示されている方法でバックアップ・ソフトウェアによってすでにバックアップされたデータである可能性がある。

【0068】

ステップ４６： サービス・プロセスが対応するアプリケーション・ソフトウェアにファイル書き込み要求を送信する。

【0069】

サービス・プロセスは、ファイル書き込み要求を受信した後に、ファイル名に従って、対応するカタログを決定してもよい。例えば、それぞれのカタログについて実行される操作は一般に直列であるので、操作はその時点の特定のカタログについてのみ実行され、従って、書き込み操作がその時点でカタログＢについて実行されている場合、サービス・プロセスは、カタログＢに対応するアプリケーションＡにファイル書き込み要求を送信することになる。任意選択で、操作がそれぞれのカタログについて並列に実行されてもよく、かつ複数のカタログに対応する複数のファイル名が同じであってもよい場合、バックアップ・ソフトウェアにより送信されるファイル書き込み要求もまた、対応するファイル内容を正しいカタログに書き込むために、カタログの情報を伝達してもよい。

【0070】

ステップ４７： アプリケーション・ソフトウェアがサービス・プロセスに結果を返す。

【0071】

ステップ４８： サービス・プロセスがバックアップ・ソフトウェアに結果を返す。

【0072】

ステップ４７〜４８における結果は、ファイル書き込みが成功したかどうかを示す情報であってもよい。リカバリが完了した後に、ソケット（ｓｏｃｋｅｔ）接続を除去してもよく、かつサービス・プロセスは、停止されてもよい。

【0073】

リカバリ操作が完了したと判断した後に、バックアップ・ソフトウェアは、例えば、ｃｌｏｓｅ＋ｃｏｎｔｅｎｔ及び／又はｆｉｌｅ ｐａｔｈというコマンドにより、停止させるために、サービス・プロセスに対して指示してもよい。

【0074】

この実施形態においてサービス・プロセスを開始することにより、サービス・プロセスは、バックアップ・ソフトウェアによってバックアップされたデータを受信し、そしてバックアップされたデータをアプリケーション・ソフトウェアに送信してもよく、これによりデータ・リカバリの処理を実現することができる。

【0075】

図５は、開始モジュール５１と、接続設定モジュール５２と、第１の送信モジュール５３と、第１の受信モジュール５４と、第２の送信モジュール５５と、第２の受信モジュール５６と、第３の送信モジュール５７とを含む、本発明の計算ノードの一実施形態の概略構造図である。開始モジュール５１は、サービス・プロセスを開始するように構成される。接続確立モジュール５２は、サービス・プロセスとバックアップ・ソフトウェアとの間のソケット（ｓｏｃｋｅｔ）接続を設定するように構成され、サービス・プロセスはルート（ｒｏｏｔ）操作権を有し、サービス・プロセスとバックアップ・ソフトウェアは同じユーザ識別名（ｕｉｄ）を有する。第１の送信モジュール５３は、バックアップ・ソフトウェアが、ソケットにより、アプリケーション・データに関する処理要求を送信すること、を可能とするように構成される。第１の受信モジュール５４は、サービス・プロセスが、ソケットにより、アプリケーション・データに関する処理要求であって、バックアップ・ソフトウェアにより送信される、処理要求、を受信すること、を可能とするように構成される。第２の送信モジュール５５は、サービス・プロセスがアプリケーション・データに関する処理要求を対応するアプリケーション・ソフトウェアに送信すること、を可能とするように構成される。第２の受信モジュール５６は、サービス・プロセスが対応するアプリケーション・ソフトウェアによって返されたアプリケーション・データを受信すること、を可能とするように構成される。第３の送信モジュール５７は、サービス・プロセスが、返されたアプリケーション・データを、ソケットにより、バックアップ・ソフトウェアに送信すること、を可能とするように構成される。

【0076】

開始モジュール５１及び接続設定モジュール５２はオペレーティング・システムにより実現されてもよく、第１の送信モジュール５３はバックアップ・ソフトウェアにより実現されてもよく、かつ第１の受信モジュール５４、第２の送信モジュール５５、第２の受信モジュール５６、及び第３の送信モジュール５７はサービス・プロセスにより実現されてもよいことに注意すべきである。

【0077】

任意選択で、図６を参照すると、第１の送信モジュールは第１の送信ユニット６１と第２の送信ユニット６２とを含む。第１の送信ユニット６１は、バックアップ・ソフトウェアがアプリケーション・データに関する処理要求の長さをソケットにより送信すること、を可能とするように構成される。第２の送信ユニット６２は、バックアップ・ソフトウェアが、アプリケーション・データに関する処理要求の長さに対応する具体的な内容を、ソケットにより、送信すること、を可能とするように構成される。

【0078】

任意選択で、図７を参照すると、第３の送信モジュールは第３の送信ユニット７１と第４の送信ユニット７２とを含む。第３の送信ユニット７１は、サービス・プロセスが、返されたアプリケーション・データの長さを、ソケットにより、バックアップ・ソフトウェアに送信すること、を可能とするように構成される。第４の送信ユニット７２は、サービス・プロセスが、返されたアプリケーション・データの具体的な内容を、ソケットにより、バックアップ・ソフトウェアに送信すること、を可能とするように構成される。

【0079】

任意選択で、図８を参照すると、第２の送信モジュールは検証ユニット８１と第５の送信ユニット８２とを含む。検証ユニット８１は、サービス・プロセスが、処理要求について、シグネチャ検証を実行すること、を可能とするように構成される。第５の送信ユニット８２は、シグネチャ検証に合格した場合に、アプリケーション・データに関する処理要求を対応するアプリケーション・ソフトウェアに送信するように構成される。

【0080】

サービス・プロセスを開始することにより、この実施形態は、サービス・プロセスがルート操作権を有しているのでサービス・プロセスが計算ノード内の様々なアプリケーション・ソフトウェアにアクセスできることを保証することができ、かつサービス・プロセスがバックアップ・ソフトウェアとのソケット接続を設定し、バックアップ・ソフトウェアと同じｕｉｄを有しているのでサービス・プロセスとバックアップ・ソフトウェアとの間の対話処理を保証することができる。従って、バックアップ・ソフトウェアは、サービス・プロセスにより、アプリケーション・ソフトウェアと対話処理を行うことができ、それにより、バックアップ・ソフトウェアによるアプリケーション・ソフトウェア内のアプリケーション・データのバックアップ又はリカバリを実現することができる。

【0081】

計算ノードはモバイル端末であってもよく、、かつモバイル端末は上記の諸実施形態におけるバックアップ及びリカバリ機能を実現してもよく、これについては本明細書でもう一度詳細に説明しないことに注意すべきである。

【0082】

当業者は、本発明のいずれかの実施形態に指定された方法の諸ステップの全部又は一部が、関連するハードウェアに指示するプログラムによって実現されてもよいことを理解すべきである。このプログラムはコンピュータ可読記憶媒体の中に記憶されてもよい。プログラムが実行されると、このプログラムは上記の実施形態に指定された方法の諸ステップを実行する。記憶媒体は、ＲＯＭ、ＲＡＭ、磁気ディスク、又はＣＤ−ＲＯＭなど、プログラム・コードを記憶できる任意の媒体であってもよい。

【0083】

最後に、上記の諸実施形態は本発明の技術的解決策について説明するために提供されたものに過ぎず、本発明を限定するためのものではないことに注意すべきである。上記の諸実施形態に関連して本発明について詳細に説明してきたが、変更又は置き換えによって対応する技術的解決策の本質が本発明のそれぞれの実施形態の技術的解決策の範囲を逸脱することがない限り、上記の諸実施形態に記載されている技術的解決策に対して変更を行ってもよく、或いは技術的解決策におけるいくつかの技術的特徴に対して均等の置き換えを行ってもよいことを、当業者は理解すべきである。

【0084】

本出願は、「ＭＥＴＨＯＤ ＡＮＤ ＣＯＭＰＵＴＡＴＩＯＮ ＮＯＤＥ ＦＯＲ ＰＲＯＣＥＳＳＩＮＧ ＡＰＰＬＩＣＡＴＩＯＮ ＤＡＴＡ」という名称で２０１２年１月４日に出願された中国特許出願第２０１２１００００７５７．１号に対する優先権を請求するものであり、同出願は参照によりその全体が本明細書に組み込まれている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】