特表 2024-538041 ホワイトリストの管理方法、機器及び記憶媒体

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-10-18

(54)【発明の名称】ホワイトリストの管理方法、機器及び記憶媒体

(51)【国際特許分類】

   G06F 15/78 20060101AFI20241010BHJP

   G06F 8/70 20180101ALI20241010BHJP

   G06F 1/3203 20190101ALI20241010BHJP

   G06F 1/3246 20190101ALI20241010BHJP

【ＦＩ】

G06F15/78 517

G06F8/70

G06F1/3203

G06F1/3246

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024521361

(86)(22)【出願日】2022-08-02

(85)【翻訳文提出日】2024-04-09

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

(87)【国際公開番号】W WO2023071363

(87)【国際公開日】2023-05-04

(31)【優先権主張番号】202111238364.X

(32)【優先日】2021-10-25

(33)【優先権主張国・地域又は機関】CN

(81)【指定国・地域】

(71)【出願人】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】時宏亮

【テーマコード（参考）】

5B011

5B062

5B376

【Ｆターム（参考）】

5B011DA06

5B011EA05

5B011LL11

5B062AA05

5B062HH06

5B376DA14

(57)【要約】

【課題】本願は、ホワイトリストの管理方法、機器及び記憶媒体を提供する。
【解決手段】本願のホワイトリストの管理方法は、第１のユーザからの、メインアプリに対応するクローンアプリの作成を要求するクローンアプリ作成要求を受信するステップ（Ｓ１００）と、前記第１のユーザに対応する第１のホワイトリストを取得するステップであって、前記第１のホワイトリストは、スタンバイスリープモードへの移行が許可されるアプリリストであるステップ（Ｓ２００）と、前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加するステップ（Ｓ３００）と、を含む。
【選択図】図２

【特許請求の範囲】

【請求項1】

ホワイトリストの管理方法であって、
第１のユーザからの、メインアプリに対応するクローンアプリの作成を要求するクローンアプリ作成要求を受信するステップと、
前記第１のユーザに対応する第１のホワイトリストを取得するステップであって、前記第１のホワイトリストは、スタンバイスリープモードへの移行が許可されるアプリリストであるステップと、
前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加するステップと、
を含む方法。

【請求項2】

前記スタンバイスリープモードは、低電力消費モードとアプリスタンバイモードとのうちの少なくとも１つを含み、
これに対応して、前記第１のホワイトリストは、低電力消費モードへの移行が許可されるアプリリストである低電力消費ホワイトリストと、前記アプリスタンバイモードへの移行が許可されるアプリリストであるアプリスタンバイホワイトリストとのうちの少なくとも１つを含む請求項１に記載の方法。

【請求項3】

前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加する前記ステップは、
前記第１のホワイトリストに対応するアプリ名セットを取得するステップと、
前記アプリ名セットに前記メインアプリのアプリ名と一致するアプリが存在する場合に、前記クローンアプリを前記第１のホワイトリストに追加するステップと、
を含む請求項１に記載の方法。

【請求項4】

前記クローンアプリを前記第１のホワイトリストに追加する前記ステップは、
前記クローンアプリのアプリ識別子を前記第１のホワイトリストに追加するステップを含む請求項３に記載の方法。

【請求項5】

受信したユーザ切替要求に応じて、端末の現在のユーザを前記第１のユーザから第２のユーザに切り替えるステップと、
前記第２のユーザに対応する第１のアプリセットを取得するステップであって、前記第１のアプリセットは、前記スタンバイスリープモードへの移行が許可される前記第２のユーザのアプリリストであるステップと、
前記第１のアプリセットに従って、前記第１のホワイトリストに対して調整処理を行い、前記第２のユーザの第２のホワイトリストを得るステップと、
をさらに含み、
前記調整処理は、
前記第１のホワイトリストから、前記第１のアプリセットに存在しないアプリを削除するステップと、
前記第１のアプリセットに存在し、前記第１のホワイトリストに存在しないアプリを、前記第１のホワイトリストに追加するステップと、
のうちの少なくとも１つを含む請求項１に記載の方法。

【請求項6】

第２のユーザのユーザ作成要求に応じて、前記第２のユーザに対応する第１のアプリセットを取得するステップと、
前記第１のアプリセットに存在し且つアプリ名が前記第１のホワイトリストのアプリと一致する第１のアプリを前記第１のホワイトリストに追加するステップと、
をさらに含む請求項１に記載の方法。

【請求項7】

前記第１のアプリセットに存在し且つアプリ名が前記第１のホワイトリストのアプリと一致する第１のアプリを前記第１のホワイトリストに追加する前記ステップは、
前記第１のホワイトリストに対応するアプリ名セットを取得するステップと、
前記アプリ名セット内の全てのアプリをトラバースして前記第１のホワイトリストのアプリとアプリ名のマッチングを行い、いくつかの第１のアプリを得るステップと、
前記第１のアプリに対応するクローンアプリのアプリ識別子をそれぞれ前記第１のホワイトリストに追加するステップと、
を含む請求項６に記載の方法。

【請求項8】

第１のユーザからの、メインアプリに対応するクローンアプリの作成を要求するクローンアプリ作成要求を受信する受信処理モジュールと、
前記第１のユーザに対応する第１のホワイトリストを取得する取得モジュールであって、前記第１のホワイトリストは、スタンバイスリープモードへの移行が許可されるアプリリストである取得モジュールと、
前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加するリスト処理モジュールと、
を備える電子機器。

【請求項9】

メモリと、プロセッサと、メモリに記憶されて且つプロセッサ上で実行できるコンピュータプログラムとを備える電子機器であって、
前記プロセッサは、前記コンピュータプログラムを実行した場合、請求項１～７の何れか一項に記載のホワイトリストの管理方法を実現する
電子機器。

【請求項10】

コンピュータ実行可能な命令を記憶しているコンピュータ可読記憶媒体であって、
前記コンピュータ実行可能な命令は、少なくとも請求項１～７の何れか一項に記載のホワイトリストの管理方法を実行するように構成された
コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は出願番号が２０２１１１２３８３６４．Ｘで、出願日が２０２１年１０月２５日である中国特許出願に基づいて提出され、その中国特許出願の優先権を主張し、その中国特許出願の全ての内容を参考として本願に援用する。

【0002】

本願の実施例は、通信の技術分野に関するが、これに限定されるものではなく、例えば、ホワイトリストの管理方法、機器及び記憶媒体に関する。

【背景技術】

【0003】

スタンバイスリープモードは、端末に導入される省電力機能であり、端末が電源に接続されていないときのアプリの行動を管理することにより、ユーザが端末の電池寿命を延ばすことを支援する端末のアプリモード、例えば低電力消費（Ｄｏｚｅ）モード、アプリスタンバイ（Ａｐｐ Ｓｔａｎｄｂｙ）モードである。しかしながら、実際の使用中では、通常、あるアプリについてクローンアプリを作成することにより、同じ端末が異なるアカウントのアプリを同時に使用できるようにする。端末がスタンバイスリープモードに入った後、クローンアプリに対応するメインアプリは正常に動作するが、クローンアプリは通常、省電力のために管理される。この場合、ユーザはこのクローンアプリを正常に使用することができず、現在の端末の管理用電力消費が増大する。

【発明の概要】

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

【0004】

以下は、本文で詳細に説明される主題の概要である。本概要は、請求の範囲を制限するためのものではない。

【0005】

本願の実施例は、管理用の消費電力を低減させることができる、ホワイトリストの管理方法、機器及び記憶媒体を提供する。

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

【0006】

第１の態様において、本願の実施例はホワイトリストの管理方法を提供し、前記方法は、第１のユーザからの、メインアプリに対応するクローンアプリの作成を要求するクローンアプリ作成要求を受信するステップと、前記第１のユーザに対応する第１のホワイトリストを取得するステップであって、前記第１のホワイトリストは、スタンバイスリープモードへの移行が許可されるアプリリストであるステップと、前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加するステップと、を含む。

【0007】

第２の態様において、本願の実施例は電子機器をさらに提供し、前記機器は、第１のユーザからの、メインアプリに対応するクローンアプリの作成を要求するクローンアプリ作成要求を受信する受信処理モジュールと、前記第１のユーザに対応する第１のホワイトリストを取得する取得モジュールであって、前記第１のホワイトリストは、スタンバイスリープモードへの移行が許可されるアプリリストである取得モジュールと、前記メインアプリが前記第１のホワイトリスト内にある場合、前記クローンアプリを前記第１のホワイトリストに追加するリスト処理モジュールと、を備える。

【0008】

第３の態様において、本願の実施例は電子機器をさらに提供し、前記電子機器は、メモリと、プロセッサと、メモリに記憶されて且つプロセッサ上で実行できるコンピュータプログラムとを備え、前記プロセッサは、前記コンピュータプログラムを実行した場合、第１の態様の何れか一項に記載のホワイトリストの管理方法を実現する。

【0009】

第４の態様において、本願の実施例はコンピュータ実行可能な命令を記憶しているコンピュータ可読記憶媒体をさらに提供し、前記コンピュータ実行可能な命令は、第１の態様の何れか一項に記載のホワイトリストの管理方法を実行するように構成されている。

【0010】

本願の他の特徴及び利点は、後の明細書において説明され、明細書から部分的に明らかになるか、又は本願を実施することによって理解される。本願の目的及び他の利点は、明細書、特許請求の範囲及び図面において特別に指摘される構成によって達成し、得ることができる。

【0011】

添付図面は、本願の技術案の更なる理解を提供するものであり、明細書の一部を構成し、本願の実施例と共に本願の技術案を解釈するために使用され、本願の技術案に対する制限を構成するものではない。

【図面の簡単な説明】

【0012】

【図1】本願の実施例にかかる電子機器のモジュールブロック図の模式図である。

【図2】本願の実施例にかかる、ホワイトリストの管理方法の模式フローチャートである。

【図3】本願の実施例にかかる、ホワイトリストの管理方法におけるユーザ切替の模式フローチャートである。

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

【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】

１００ 受信処理モジュール
２００ 取得モジュール
３００ リスト処理モジュール
４００ クローンアプリリスニングモジュール
５００ マルチユーザリスニングモジュール

【図1】

【図2】

【図3】

【国際調査報告】