特許 7383176 ビデオデータの取得方法、装置、電子デバイス及び記憶媒体

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

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

(11)【特許番号】

(24)【登録日】2023-11-09

(45)【発行日】2023-11-17

(54)【発明の名称】ビデオデータの取得方法、装置、電子デバイス及び記憶媒体

(51)【国際特許分類】

   H04N 21/24 20110101AFI20231110BHJP

   H04N 21/437 20110101ALI20231110BHJP

【ＦＩ】

H04N21/24

H04N21/437

【請求項の数】 10

(21)【出願番号】P 2022564689

(86)(22)【出願日】2020-12-29

(65)【公表番号】

(43)【公表日】2023-03-02

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

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

(87)【国際公開日】2021-07-08

【審査請求日】2022-08-18

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

(32)【優先日】2019-12-31

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

(73)【特許権者】

【識別番号】522261237

【氏名又は名称】中移（蘇州） 軟件技術有限公司

【氏名又は名称原語表記】ＣＨＩＮＡ ＭＯＢＩＬＥ （ＳＵＺＨＯＵ） ＳＯＦＴＷＡＲＥ ＴＥＣＨＮＯＬＯＧＹ ＣＯ．， ＬＴＤ．

【住所又は居所原語表記】ＣＭＳｏｆｔ Ｐａｒｋ， Ｂｕｉｌｄｉｎｇ １， Ｎｏ．５８， Ｋｕｎｌｕｎｓｈａｎ Ｒｏａｄ， ＳＮＤ， Ｓｕｚｈｏｕ， Ｊｉａｎｇｓｕ ２１５１６３， Ｃｈｉｎａ

(73)【特許権者】

【識別番号】507142144

【氏名又は名称】中国移動通信集団有限公司

【氏名又は名称原語表記】ＣＨＩＮＡ ＭＯＢＩＬＥ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＧＲＯＵＰ ＣＯ．， ＬＴＤ．

(74)【代理人】

【識別番号】100145403

【弁理士】

【氏名又は名称】山尾 憲人

(74)【代理人】

【識別番号】100135703

【弁理士】

【氏名又は名称】岡部 英隆

(72)【発明者】

【氏名】劉 永超

(72)【発明者】

【氏名】王 軼

(72)【発明者】

【氏名】段 ▲パン▼▲パン▲

【審査官】鈴木 隆夫

(56)【参考文献】

【文献】米国特許出願公開第２０１５／００８１７６４（ＵＳ，Ａ１）

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

Ｈ０４Ｎ ２１／００－２１／８５８

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

【請求項1】

ビデオデータの取得方法であって、
少なくとも２つのシミュレーターを配置するステップであって、前記少なくとも２つのシミュレーターのそれぞれは、モバイル端末の動作をシミュレートするために用いられる、ステップと、
前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信するステップであって、前記サーバーは、ビデオアプリケーションに対応するサーバーである、ステップと、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信するステップと、を含み、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信する場合、前記取得方法は、
前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受し、傍受されたビデオデータを設定されたデータベースに記憶するステップをさらに含む、取得方法。

【請求項2】

前記取得方法は、
設定された時間ごとに、前記設定されたデータベースにおける前記少なくとも２つのシミュレーターのそれぞれに対応するビデオデータの数量を統計するステップと、
前記数量が第１の設定された条件を満たす場合、対応するシミュレーターの前記ビデオアプリケーションを再起動するステップであって、第１の設定された条件は、前記数量が異常であることを示す、ステップと、をさらに含むことを特徴とする請求項１に記載の取得方法。

【請求項3】

前記取得方法は、
前記シミュレーターに対応するパラメータを変更するステップをさらに含み、
前記パラメータは、モバイル端末のシリアル番号、モバイル端末の型番及びメディアアクセス制御層（ＭＡＣ）アドレスのうちの少なくとも１つを含むことを特徴とする請求項１に記載の取得方法。

【請求項4】

前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信する場合、前記取得方法は、
前記ビデオアプリケーションに対応する操作スクリプトを取得するステップと、
前記操作スクリプトを実行し、前記ビデオアプリケーションに対応するサーバーにビデオアクセス要求を送信するステップと、を含むことを特徴とする請求項１に記載の取得方法。

【請求項5】

前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信する場合、前記取得方法は、
前記サーバーが第１の設定されたキーワードに関連する第１のビデオデータを返信するように、前記サーバーに第１の設定されたキーワードを含むビデオアクセス要求を送信するステップ、又は、
前記サーバーが第１のユーザ名に対応するユーザアカウントによってアップロードされた第２のビデオデータを返信するように、前記サーバーに第１のユーザ名を含むビデオアクセス要求を送信するステップ、又は、
前記サーバーが第３のビデオデータを返信するように、前記サーバーに第２のユーザ名を含むビデオアクセス要求を送信するステップであって、前記第３のビデオデータは、前記サーバーが前記第２のユーザ名に対応するユーザアカウントのアクセス履歴データに基づいて、前記第２のユーザ名に対応するユーザアカウントにプッシュしたビデオデータである、ステップを含むことを特徴とする請求項１に記載の取得方法。

【請求項6】

前記サーバーに第１のユーザ名を含むビデオアクセス要求を送信する前に、前記取得方法は、
前記設定されたデータベースにおけるビデオデータに対応する、前記ビデオデータをアップロードしたユーザアカウントを取得するステップと、
前記ユーザアカウントの第１のパラメータ及び対応する重みに基づいて前記ユーザアカウントのスコアを計算するステップであって、前記第１のパラメータは、前記ユーザアカウントによって受信されたインタラクティブ情報の数量及び前記ユーザアカウントをフォローしたユーザの数量のうちの少なくとも１つを含む、ステップと、
前記スコアが第１の設定された値よりも大きいユーザアカウントに対応するユーザ名を第１のユーザ名として決定するステップと、をさらに含むことを特徴とする請求項５に記載の取得方法。

【請求項7】

前記取得方法は、
前記サーバーが第２の設定されたキーワードに関連するユーザ名を返信するように、前記サーバーに前記第２の設定されたキーワードを含むユーザ名アクセス要求を送信するステップと、
前記サーバーによって返信されたユーザ名と前記第２の設定されたキーワードとの関連度を決定するステップと、
前記関連度が第２の設定された値よりも大きいユーザ名を第１のユーザ名として決定するステップと、をさらに含むことを特徴とする請求項５に記載の取得方法。

【請求項8】

ビデオデータの取得装置であって、
少なくとも２つのシミュレーターを配置するように構成される配置モジュールであって、前記少なくとも２つのシミュレーターのそれぞれは、モバイル端末の動作をシミュレートするために用いられる、配置モジュールと、
前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信するように構成される送信モジュールであって、前記サーバーは、ビデオアプリケーションに対応するサーバーである、送信モジュールと、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信するように構成される受信モジュールと、を備え、
前記取得装置は、
前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受し、傍受されたビデオデータを設定されたデータベースに記憶するように構成される傍受モジュールをさらに備える、ビデオデータの取得装置。

【請求項9】

メモリと、プロセッサと、前記メモリに記憶され且つ前記プロセッサで実行可能なコンピュータプログラムを備え、前記プロセッサは、前記コンピュータプログラムを実行するときに請求項１－７のいずれか一項に記載のビデオデータの取得方法を実施する、電子デバイス。

【請求項10】

プロセッサにより実行されるときに、前記プロセッサに請求項１－７のいずれか一項に記載のビデオデータの取得方法を実行させるためのコンピュータプログラムを記憶した、コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、インターネット技術分野に属し、特にビデオデータの取得方法、装置、電子デバイス及び記憶媒体に関する。

【0002】

（関連出願への相互参照）
本出願は、出願番号が２０１９１１４２１４３１．４であり、出願日が２０１９年１２月３１日である中国特許出願に基づいて提出され、上記中国特許出願の優先権を主張し、上記中国特許出願の全内容は、参照により本出願に組み込まれる。

【背景技術】

【0003】

現在、多くの若者は、携帯電話のビデオソフトウェアでビデオをアップロードすることを好むが、アップロードされたビデオの数量が多く、コンテンツが複雑であるため、一部のビデオは、携帯電話のビデオソフトウェアを使用する青少年に悪い影響を与える可能性がある。したがって、携帯電話のビデオソフトウェアにおけるビデオデータをネットワークで監視する必要がある。

【発明の概要】

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

【0004】

しかしながら、携帯電話のビデオソフトウェアがほとんどシェリングされて暗号化されているため、現在、ネットワーク監視プロセスでのビデオデータの収集は、困難である。

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

【0005】

関連する技術的問題を解決するために、本発明の実施例は、ビデオデータの取得方法、装置、電子デバイス及び記憶媒体を提供する。

【0006】

本発明の実施例によるビデオデータの取得方法は、
少なくとも２つのシミュレーターを配置するステップであって、前記少なくとも２つのシミュレーターのそれぞれは、モバイル端末の動作をシミュレートするために用いられる、ステップと、
前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信するステップであって、前記サーバーは、ビデオアプリケーションに対応するサーバーである、ステップと、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信するステップと、を含み、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信する場合、前記取得方法は、
前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受し、傍受されたビデオデータを設定されたデータベースに記憶するステップをさらに含む。

【0007】

上記技術的解決策において、前記取得方法は、
設定された時間ごとに、前記設定されたデータベースにおける前記少なくとも２つのシミュレーターのそれぞれに対応するビデオデータの数量を統計するステップと、
前記数量が第１の設定された条件を満たす場合、対応するシミュレーターの前記ビデオアプリケーションを再起動するステップであって、第１の設定された条件は、前記数量が異常であることを示す、ステップと、をさらに含む。

【0008】

上記技術的解決策において、前記取得方法は、
前記シミュレーターに対応するパラメータを変更するステップをさらに含み、
前記パラメータは、モバイル端末のシリアル番号、モバイル端末の型番及びメディアアクセス制御層（ＭＡＣ）アドレスのうちの少なくとも１つを含む。

【0009】

上記技術的解決策において、前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信する場合、前記取得方法は、
前記ビデオアプリケーションに対応する操作スクリプトを取得するステップと、
前記操作スクリプトを実行し、前記ビデオアプリケーションに対応するサーバーにビデオアクセス要求を送信するステップと、を含む。

【0010】

上記技術的解決策において、前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信する場合、前記取得方法は、
前記サーバーが第１の設定されたキーワードに関連する第１のビデオデータを返信するように、前記サーバーに第１の設定されたキーワードを含むビデオアクセス要求を送信するステップ、又は、
前記サーバーが第１のユーザ名に対応するユーザアカウントによってアップロードされた第２のビデオデータを返信するように、前記サーバーに第１のユーザ名を含むビデオアクセス要求を送信するステップ、又は、
前記サーバーが第３のビデオデータを返信するように、前記サーバーに第２のユーザ名を含むビデオアクセス要求を送信するステップであって、前記第３のビデオデータは、前記サーバーが前記第２のユーザ名に対応するユーザアカウントのアクセス履歴データに基づいて、前記第２のユーザ名に対応するユーザアカウントにプッシュしたビデオデータである、ステップを含む。

【0011】

上記技術的解決策において、前記サーバーに第１のユーザ名を含むビデオアクセス要求を送信する前に、前記取得方法は、
前記設定されたデータベースにおけるビデオデータに対応する、前記ビデオデータをアップロードしたユーザアカウントを取得するステップと、
前記ユーザアカウントの第１のパラメータ及び対応する重みに基づいて前記ユーザアカウントのスコアを計算するステップであって、前記第１のパラメータは、前記ユーザアカウントによって受信されたインタラクティブ情報の数量及び前記ユーザアカウントをフォローしたユーザの数量のうちの少なくとも１つを含む、ステップと、
前記スコアが第１の設定された値よりも大きいユーザアカウントに対応するユーザ名を第１のユーザ名として決定するステップと、をさらに含む。

【0012】

上記技術的解決策において、前記取得方法は、
前記サーバーが前記第２の設定されたキーワードに関連するユーザ名を返信するように、前記サーバーに第２の設定されたキーワードを含むユーザ名アクセス要求を送信するステップと、
前記サーバーによって返信されたユーザ名と前記第２の設定されたキーワードとの関連度を決定するステップと、
前記関連度が第２の設定された値よりも大きいユーザ名を第１のユーザ名として決定するステップと、をさらに含む。

【0013】

本発明の実施例によるビデオデータの取得装置は、
少なくとも２つのシミュレーターを配置するように構成される配置モジュールであって、前記少なくとも２つのシミュレーターのそれぞれは、モバイル端末の動作をシミュレートするために用いられる、配置モジュールと、
前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信するように構成される送信モジュールであって、前記サーバーは、ビデオアプリケーションに対応するサーバーである、送信モジュールと、
前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信するように構成される受信モジュールと、を備え、
前記取得装置は、
前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受し、傍受されたビデオデータを設定されたデータベースに記憶するように構成される傍受モジュールをさらに備える。

【0014】

本出願の実施例による電子デバイスは、プロセッサとメモリとを備え、前記プロセッサと前記メモリは、相互に接続し、前記メモリは、プログラム命令を含むコンピュータプログラムを記憶し、前記プロセッサは、前記プログラム命令を呼び出し、上記ビデオデータの取得方法のステップを実行する。

【0015】

本出願の実施例によるコンピュータ可読記憶媒体は、コンピュータプログラムを記憶し、前記コンピュータプログラムがプロセッサに実行されるときにプロセッサに上記ビデオデータの取得方法のステップを実施させる。

【0016】

本発明の実施例は、少なくとも２つのシミュレーターを配置し、少なくとも２つのシミュレーターを介してビデオアプリケーションのサーバーにビデオアクセス要求をそれぞれ送信することにより、複数のシミュレーターで並列処理を行ってより多くのビデオデータを取得することができ、ビデオデータの収集効率が向上する。また、前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信する場合、前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受することにより、ビデオアプリケーションのシェリングオフ及び復号を回避することができ、かつ取得されたビデオデータをより参照可能にすることができる。

【図面の簡単な説明】

【0017】

【図1】本発明の実施例によるビデオデータの取得方法のためのシステムの構造概略図である。

【図2】本発明の実施例によるシミュレーターの概略図である。

【図3】本発明の実施例によるビデオデータの取得方法の実施プロセスの概略図である。

【図4】本発明の実施例による別のビデオデータの取得方法の実施プロセスの概略図である。

【図5】本発明の実施例による別のビデオデータの取得方法の実施プロセスの概略図である。

【図6】本発明の実施例による別のビデオデータの取得方法の実施プロセスの概略図である。

【図7】本発明の実施例による別のビデオデータの取得方法の実施プロセスの概略図である。

【図8】本発明のアプリケーション実施例による電子デバイスのシステムアーキテクチャの概略図である。

【図9】本発明のアプリケーション実施例によるビデオデータの取得プロセスの概略図である。

【図10】本発明のアプリケーション実施例による別のビデオデータの取得プロセスの概略図である。

【図11】本発明のアプリケーション実施例による別のビデオデータの取得プロセスの概略図である。

【図12】本発明のアプリケーション実施例による第１のユーザ名の取得プロセスの概略図である。

【図13】本発明の実施例によるビデオデータの取得装置の構造概略図である。

【図14】本発明の実施例による電子デバイスのハードウェア構造図である。

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

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

図８のシステムアーキテクチャに基づき、図１０は本発明のアプリケーション実施例による別のビデオデータの取得プロセスを示す概略図である。

【0085】

Ｓ１００１：Ａｐｐｉｕｍコントローラーを起動する。

【0086】

Ｓ１００２：サーバーによって推奨されたビデオデータを受信する。

【0087】

Ａｐｐｉｕｍコントローラーによってシミュレーターのビデオアプリケーションを起動した後、通常、ビデオアプリケーションは、前回ログインしたユーザアカウントに自動的にログインし、シミュレーターのビデオアプリケーションがユーザによってログインされていない場合、Ａｐｐｉｕｍコントローラーによってユーザアカウント情報を入力してログインすることができる。ユーザアカウントにログインした後、前記サーバーが第３のビデオデータを返信するように、Ａｐｐｉｕｍコントローラーを介してサーバーに第２のユーザ名を含むビデオアクセス要求を送信し、前記第３のビデオデータは、前記サーバーが前記第２のユーザ名に対応するユーザアカウントのアクセス履歴データに基づいて、前記第２のユーザ名に対応するユーザアカウントにプッシュしたビデオデータである。

【0088】

Ｓ１００３：サーバーによって推奨されたビデオデータを定期的に更新する。

【0089】

サーバーが一定量のビデオデータをユーザアカウントに毎回推奨するため、推奨されたビデオデータが更新されない場合、ユーザは、サーバーによって推奨されたビデオデータを視聴した後、ビデオデータの視聴を続けることができない。したがって、推奨されたビデオデータをタイムリーに更新する必要がある。実際のアプリケーションでは、設定された時間間隔ごとにサーバーにビデオ更新要求を送信することができ、サーバーは、ビデオ更新要求に応じて一定量の新しいビデオデータをシミュレーターに返信する。

【0090】

Ｓ１００４：パケットキャプチャツールにより、サーバーによって推薦されたビデオデータを傍受する。

【0091】

Ｓ１００５：傍受されたビデオデータをデータベースに記憶する。

【0092】

図８のシステムアーキテクチャに基づいて、図１１は本発明のアプリケーション実施例による別のビデオデータの取得プロセスを示す概略図である。

【0093】

Ｓ１１０１：Ａｐｐｉｕｍコントローラーを起動する。

【0094】

Ｓ１１０２：キーワードを入力してユーザ検索を行う。

【0095】

シミュレーターは、Ａｐｐｉｕｍコントローラーによって制御されて動作し、ビデオアプリケーションの検索ウィンドウにキーワードが入力されると、前記サーバーがキーワードに関連するユーザ名を返信するように、サーバーにキーワードを含むユーザ名アクセス要求を送信する。

【0096】

Ｓ１１０３：第１のユーザ名を決定する。

【0097】

具体的には、前記設定されたデータベースにおけるビデオデータに対応する、前記ビデオデータをアップロードするユーザアカウントを取得することができ、前記ユーザアカウントの第１のパラメータ及び対応する重みに基づいて前記ユーザアカウントのスコアを計算し、前記第１のパラメータは、前記ユーザアカウントによって受信されたインタラクティブ情報の数量及び前記ユーザアカウントをフォローしたユーザの数量のうちの少なくとも１つを含み、前記スコアが第１の設定された値よりも大きいユーザアカウントに対応するユーザ名を第１のユーザ名として決定する。

【0098】

又は、前記サーバーが前記第２の設定されたキーワードに関連するユーザ名を返信するように、前記サーバーに第２の設定されたキーワードを含むユーザ名アクセス要求を送信し、前記サーバーによって返信されたユーザ名と前記第２の設定されたキーワードとの関連度を決定し、前記関連度が第２の設定された値よりも大きいユーザ名を第１のユーザ名として決定する。

【0099】

Ｓ１１０４：第１のユーザ名を入力してビデオ検索を行う。

【0100】

シミュレーターは、Ａｐｐｉｕｍコントローラーによって制御されて動作し、ビデオアプリケーションの検索ウィンドウに第１のユーザ名が入力されると、前記サーバーが第１のユーザ名に関連するビデオデータを返信するように、サーバーに第１のユーザ名を含むビデオアクセス要求を送信する。

【0101】

Ｓ１１０５：第１のユーザ名を定期的に更新する。

【0102】

各ユーザアカウントによってアップロードされるビデオデータが限られるため、当該ユーザアカウントによってアップロードされビデオデータを常時収集すると、当該ユーザアカウントによってアップロードされたビデオデータをすべて収集した後、ビデオデータの収集が停止する。したがって、データ収集が停止することを防止するために、設定された時間ごとに第１のユーザ名を更新することができる。実際のアプリケーションでは、シミュレーターは、Ａｐｐｉｕｍコントローラーによって制御されて動作し、設定された時間ごとにビデオアプリケーションの検索ウィンドウに第１のユーザ名を入力することにより、サーバーに新しい第１のユーザ名を含むビデオアクセス要求を送信する。又は、第１のユーザ名ごとに設定された数量のビデオデータを収集するように設定する。

【0103】

Ｓ１１０６：パケットキャプチャツールにより、サーバーによって返信されたビデオデータを傍受する。

【0104】

Ｓ１１０７：傍受されたビデオデータをデータベースに記憶する。

【0105】

図１２は本発明のアプリケーション実施例による第１のユーザ名の取得プロセスを示す概略図である。

【0106】

本発明の適用実施例では、第１のユーザ名を取得するための方法が２つある。第１の方法では、まず、キーワードデータベースからキーワードを取得し、キーワードデータベースを電子デバイスに記憶し、キーワードデータベースには、ビデオソフトウェアで検索する必要があるキーワードが記憶される。キーワードが取得された後、ビデオソフトウェアのユーザ検索ウィンドウにキーワードを入力し、キーワードに関連するユーザ名を検索する。次に、検索されたユーザ名から、キーワードとの相関度の高い第１のユーザ名を決定し、最後に第１のユーザ名を電子デバイスの第１のユーザ名データベースに記憶する。第２の方法では、設定されたデータベースから第１のユーザ名を決定する。具体的には、まず、設定されたデータベースにおけるビデオデータに対応する、前記ビデオデータをアップロードしたユーザアカウントを取得し、次にユーザアカウントの第１のパラメータ及び対応する重みに基づいて前記ユーザアカウントのスコアを計算し、前記第１のパラメータは、前記ユーザアカウントによって受信されたインタラクティブ情報の数量及びユーザアカウントをフォローしたユーザの数量のうちの少なくとも１つを含み、最後にスコアが第１の設定された値よりも大きいユーザアカウントに対応するユーザ名を第１のユーザ名として決定し、第１のユーザ名を第１のユーザ名データベースに記憶する。

【0107】

上記実施例で詳しく説明されていないステップの具体的な実施プロセスについては、上記方法の実施例を参照することができ、ここでは説明を省略する。

【0108】

本発明の実施例は、ビデオアプリケーションにおけるビデオデータを取得するための３つの方法を提供する。第１の方法は、キーワードに関連するビデオデータを収集することであり、第２の方法は、サーバーによって推奨されたビデオデータを収集することであり、第３の方法は、指定されたユーザによってアップロードされたビデオデータを収集することである。様々な収集ポリシーにより、本発明の実施例は、収集されたビデオデータをより参照可能にすることができる。

【0109】

図１３を参照すると、図１３は本発明の実施例によるビデオデータの取得装置の概略図である。図１３に示すように、当該装置は、電子デバイスに設けられるものであり、配置モジュール、送信モジュール、受信モジュール及び傍受モジュールを備える。

【0110】

配置モジュールは、少なくとも２つのシミュレーターを配置するように構成され、前記少なくとも２つのシミュレーターのそれぞれは、モバイル端末の動作をシミュレートするために用いられる。

【0111】

送信モジュールは、前記少なくとも２つのシミュレーターを介してサーバーにビデオアクセス要求をそれぞれ送信するように構成され、前記サーバーは、ビデオアプリケーションに対応するサーバーである。

【0112】

受信モジュールは、前記少なくとも２つのシミュレーターを介して前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータをそれぞれ受信するように構成される。

【0113】

前記取得装置は、
前記サーバーが対応するビデオアクセス要求に応じて返信したビデオデータを傍受し、傍受されたビデオデータを設定されたデータベースに記憶するように構成される傍受モジュールをさらに備える。

【0114】

前記取得装置は、
設定された時間ごとに、前記設定されたデータベースにおける前記少なくとも２つのシミュレーターのそれぞれに対応するビデオデータの数量を統計するように構成される統計モジュールと、
前記数量が第１の設定された条件を満たす場合、対応するシミュレーターの前記ビデオアプリケーションを再起動するように構成される再起動モジュールであって、第１の設定された条件が、前記数量が異常であることを示す再起動モジュールと、をさらに備える。

【0115】

前記取得装置は、
前記シミュレーターに対応するパラメータを変更するように構成される変更モジュールをさらに備え、
前記パラメータは、モバイル端末のシリアル番号、モバイル端末の型番及びメディアアクセス制御層（ＭＡＣ）アドレスのうちの少なくとも１つを含む。

【0116】

前記送信モジュールは、具体的には、
前記ビデオアプリケーションに対応する操作スクリプトを取得し、
前記操作スクリプトを実行し、前記ビデオアプリケーションに対応するサーバーにビデオアクセス要求を送信するように構成される。

【0117】

前記送信モジュールは、具体的には、
前記サーバーが前記第１の設定されたキーワードに関連する第１のビデオデータを返信するように、前記サーバーに第１の設定されたキーワードを含むビデオアクセス要求を送信するように構成され、又は、
前記サーバーが前記第１のユーザ名に対応するユーザアカウントによってアップロードされた第２のビデオデータを返信するように、前記サーバーに第１のユーザ名を含むビデオアクセス要求を送信するように構成され、又は、
前記サーバーが第３のビデオデータを返信するように、前記サーバーに第２のユーザ名を含むビデオアクセス要求を送信するように構成され、前記第３のビデオデータは、前記サーバーが前記第２のユーザ名に対応するユーザアカウントのアクセス履歴データに基づいて、前記第２のユーザ名に対応するユーザアカウントにプッシュしたビデオデータである。

【0118】

前記取得装置は、
前記設定されたデータベースにおけるビデオデータに対応する、前記ビデオデータをアップロードしたユーザアカウントを取得し、
前記ユーザアカウントの第１のパラメータ及び対応する重みに基づいて前記ユーザアカウントのスコアを計算するように構成され、前記第１のパラメータが前記ユーザアカウントによって受信されたインタラクティブ情報の数量及び前記ユーザアカウントをフォローしたユーザの数量のうちの少なくとも１つを含み、
前記スコアが第１の設定された値よりも大きいユーザアカウントに対応するユーザ名を第１のユーザ名として決定するように構成される第１のユーザ名決定モジュールをさらに備える。

【0119】

前記第１のユーザ名決定モジュールは、
前記サーバーが前記第２の設定されたキーワードに関連するユーザ名を返信するように、前記サーバーに第２の設定されたキーワードを含むユーザ名アクセス要求を送信し、
前記サーバーによって返信されたユーザ名と前記第２の設定されたキーワードとの関連度を決定し、
前記関連度が第２の設定された値よりも大きいユーザ名を第１のユーザ名として決定するように構成される。

【0120】

説明すべきこととして、上記実施例によって提供されるビデオデータの取得装置については、ビデオデータの取得を行う時に、上記の各モジュールの区分のみを例として説明するが、実際の応用において、上記処理割り当ては、ニーズに応じて異なるモジュールによって完了されてもよく、即ち上記の全部又は一部の処理は、装置の内部構造を異なるモジュールに分けることで完了されてもよい。また、上記実施例によって提供されるビデオデータの取得装置及びビデオデータの取得方法の実施例は、同じ概念に属し、具体的な実施プロセスについては、方法の実施例を詳しく参照し、ここでは説明を省略する。

【0121】

図１４は本発明の一実施例による電子デバイスの概略図である。図１４に示すように、当該実施例の電子デバイスは、プロセッサと、メモリと、前記メモリに記憶されて前記プロセッサで実行可能なコンピュータプログラムとを備える。前記プロセッサは、前記コンピュータプログラムを実行すると上記の各方法の実施例におけるステップ、例えば図３に示すステップ１０１から１０４を実施する。又は、前記プロセッサは、前記コンピュータプログラムを実行すると上記の各装置の実施例における各モジュール／ユニットの機能、例えば図１３に示す配置モジュール、送信モジュール、受信モジュール及び傍受モジュールの機能を実施する。

【0122】

例示的に、前記コンピュータプログラムは、１つ又は複数のモジュールに分割されてもよく、前記１つ又は複数のモジュールは、前記メモリに記憶され、本発明を完了するために前記プロセッサによって実行される。前記１つ又は複数のモジュールは、特定の機能を完了することができる一連のコンピュータプログラム命令セグメントであってもよく、当該命令セグメントは、前記サーバーでの前記コンピュータプログラムの実行プロセスを記述するために用いられる。

【0123】

前記電子デバイスは、プロセッサと、メモリとを備えることができるが、これらに限定されない。当業者は、図１４が電子デバイスの例だけであるが、電子デバイスを限定するためのものではなく、図示よりも多く又はより少ない部材を備え、又は幾つかの部材又は異なる部材を組み合わせることができ、例えば、前記電子デバイスが入出力デバイス、ネットワークアクセスデバイス、バスなどをさらに備えることができることを理解できる。

【0124】

前記プロセッサは、中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であってもよく、また、他の汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、専用集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）又は他のプログラマブルロジックデバイス、ディスクリートゲート又はトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであってもよい。汎用プロセッサは、マイクロプロセッサであってもよく、又は当該プロセッサは、いずれかの従来のプロセッサなどであってもよい。

【0125】

前記メモリは、前記電子デバイスの内部記憶ユニット、例えば電子デバイスのハードディスク又はメモリであってもよい。前記メモリは、前記電子デバイスの外部記憶デバイス、例えば前記電子デバイスに配置されたプラグ可能なハードドライブ、スマートメモリーカード（ＳＭＣ：Ｓｍａｒｔ Ｍｅｄｉａ（登録商標） Ｃａｒｄ）、セキュアデジタル（ＳＤ：Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フラッシュカード（Ｆｌａｓｈ Ｃａｒｄ）などであってもよい。さらに、前記メモリは、前記電子デバイスの内部記憶ユニットだけでなく、外部記憶デバイスも含むことができる。前記メモリは、前記コンピュータプログラム及び前記電子デバイスに必要な他のプログラム及びデータを記憶するように構成される。前記メモリは、出力されたデータ又は出力されるデータを一時的に記憶するように構成されてもよい。

【0126】

当業者は、便利及び簡潔に説明するために、上記の各機能ユニット、モジュールの区分のみを例として説明することを明確に理解することができるが、実際のアプリケーションでは、上記機能の割り当ては、ニーズに応じて異なる機能ユニット、モジュールによって完了されてもよく、即ち上述した全て又は一部の機能を完了するために、前記取得装置の内部構造は、異なる機能ユニット又はモジュールに分けられてもよい。実施例における各機能ユニット、モジュールは、１つの処理ユニットに統合されてもよいし、個々のユニットは、単独で存在してもよく、２つ又は２つ以上のユニットは、１つのユニットに統合されてもよく、上記の統合されたユニットは、ハードウェアの形で実現されてもよいし、ソフトウェア機能ユニットの形で実現されてもよい。また、各機能ユニット、モジュールの具体的な名称は、互いに区別するためのものだけであり、本出願の保護範囲を制限するために用いられない。上記システムのユニット、モジュールの具体的な動作プロセスについては、前記取得方法の実施例における対応するプロセスを参照できるため、ここでは説明を省略する。

【0127】

上記実施例では、各実施例の説明について異なる強調を持っているため、ある実施例に詳しく説明又は記載されていない部分に対して、他の実施例の関連説明を参照することができる。

【0128】

当業者であれば、本明細書で開示される実施例と組み合わせて説明された各例のユニット及びアルゴリズムステップが電子ハードウェア、又はコンピュータソフトウェアと電子ハードウェアの組み合わせで実現されてもよいことを理解できる。これらの機能がハードウェア又はソフトウェアで実行されるかは、技術的解決策の特定アプリケーションと設計制約条件に依存する。当業者は、各特定の応用に対して異なる方法を用いて記述される機能を実施することができるが、このような実施は、本発明の範囲を超えると見なしてはならない。

【0129】

本発明が提供する実施例では、開示される装置／電子デバイス及び方法は、他の方式により実現されてもよい。例えば、上記の装置／電子デバイスの実施例は、例示的なものだけであり、例えば、前記モジュール又はユニットの区分は、論理機能的区分だけであり、実際に実施する時に他の区分方式もあり得て、例えば複数のユニット又は構成要素は、組み合わせてもよく又は別のシステムに統合されてもよく、又は幾つかの特徴は、無視されてもよく、又は実行されなくてもよい。また、示されるか、又は議論される相互結合又は直接結合又は通信接続は、幾つかのインターフェース、デバイス又はユニットを介した間接的結合又は通信接続であってもよく、電気的、機械的又は他の形であってもよい。

【0130】

分離部材として説明される前記ユニットは、物理的に分離するものであってもよく又は物理的に分離するものでなくてもよく、ユニットとして表示された部材は、物理ユニットであってもよく又は物理ユニットでなくてもよく、即ち１つの位置に配置されてもよく、又は複数のネットワークユニットに分布してもよい。実際のニーズに応じてその中の一部又は全てのユニットを選択して本実施例の技術的解決策の目的を達成することができる。

【0131】

また、本発明の各実施例における各機能ユニットは、１つの処理ユニットに統合されてもよく、各々のユニットは、単独で物理的に存在してもよく、２つ又は２つ以上のユニットは、１つのユニットに統合されてもよい。上記の統合されたユニットは、ハードウェアの形で実現されてもよく、ソフトウェア機能ブロックの形で実現されてもよい。

【0132】

前記統合されたモジュール／ユニットは、ソフトウェア機能ユニットの形で実現され且つ独立した製品として販売又は使用される時に、１つのコンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づき、本発明の上記実施例の方法の全て又は一部のプロセスの実施は、コンピュータプログラムで関連するハードウェアを指令することで完了されてもよく、前記コンピュータプログラムは、コンピュータ可読記憶媒体に記憶されてもよく、当該コンピュータプログラムがプロセッサに実行される場合、上記の各方法の実施例のステップを実施することができる。ここで、前記コンピュータプログラムは、コンピュータプログラムコードを含み、前記コンピュータプログラムコードは、ソースコード形態、オブジェクトコード形態、実行可能ファイル又は幾つかの中間形態などであってもよい。前記コンピュータ可読媒体は、前記コンピュータプログラムを含むことができる任意のエンティティ又は装置、記録媒体、ＵＳＢフラッシュドライブ、モバイルハードディスク、磁気ディスク、光ディスク、コンピュータメモリ、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、電気搬送波信号、電気信号及びソフトウェア配布メディアなどを含むことができる。前記コンピュータ可読媒体に含まれるコンテンツが司法管轄区域における立法及び特許実務の要求に従って適切に増加又は減少されてもよいことを説明すべきであり、例えば、幾つかの司法管轄区域で、立法と特許実務に従って、コンピュータ可読媒体には、電気搬送波信号と電気信号が含まれない。

【0133】

本明細書及び添付の特許請求の範囲で用いられる場合、「含む」及び「包括」という用語は、記載された特徴、全体、ステップ、操作、要素及び／又は構成要素の存在を示すが、１つ又は複数の他の特徴、全体、ステップ、操作、要素、構成要素及び／又はその集合の存在又は追加を除外しない。

【0134】

本発明の実施例で記載される技術的解決策が衝突することなく任意に組み合わせられてもよいことを説明するべきである。

【0135】

また、本発明の実施例では、「第１」、「第２」などは、類似したオブジェクトを区別するために用いられ、必ずしも特定の順序又は順番を説明するために用いられるわけではない。

【0136】

上記の実施例は、本発明の技術的解決策を説明するためのものだけであり、それを制限しない。本発明は、上記実施例を参照して詳しく説明されたが、当業者であれば、それが依然として上記の各実施例に記載される技術的解決策を変更し、又はその中の一部の技術的特徴に対して同等入れ替えを行うことができることを理解すべきであり、これらの変更又は入れ替えは、対応する技術的解決策の本質を本発明の各実施例の各技術的解決策の精神及び範囲から逸脱させず、いずれも本発明の保護範囲内に含まれるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】