特表 2023-523191 アカウントの識別方法、装置、電子機器及びコンピュータ読み取り可能な媒体

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

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

(11)【公表番号】

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

(54)【発明の名称】アカウントの識別方法、装置、電子機器及びコンピュータ読み取り可能な媒体

(51)【国際特許分類】

   G06Q 30/0601 20230101AFI20230526BHJP

【ＦＩ】

G06Q30/0601

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022563061

(86)(22)【出願日】2021-03-15

(85)【翻訳文提出日】2022-10-17

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

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

(87)【国際公開日】2021-10-28

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

(32)【優先日】2020-04-23

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】521456922

【氏名又は名称】北京京東振世信息技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｊｉｎｇｄｏｎｇ Ｚｈｅｎｓｈｉ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】６ｔｈ Ｆｌｏｏｒ， Ｎｏ．７６ Ｚｈｉｃｈｕｎ Ｒｏａｄ， Ｈａｉｄｉａｎ Ｄｉｓｔｒｉｃｔ， Ｂｅｉｊｉｎｇ １０００８６， Ｃｈｉｎａ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】趙 可

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

5L049

【Ｆターム（参考）】

5L049BB22

(57)【要約】

本発明は、アカウントの識別方法、装置、電子機器及びコンピュータ読み取り可能な媒体を提供し、インターネット技術分野に属する。前記方法は、リソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、リソース移転記録に基づいてアカウント関係データテーブルを生成するステップと、アカウント関係データテーブルに基づいて、リソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップと、接続アカウント集合内の各アカウント間の接続関係に基づいて各接続アカウント集合内の識別対象アカウントを確定するステップと、識別対象アカウントからサンプルアカウントを抽出するとともに、サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップと、目標アカウント識別モデルにより識別対象アカウントが目標アカウントであるか否かを判断するステップと、を含む。アカウント間の接続関係を介して目標アカウントとして確定される可能性が最も高い識別対象アカウントを選択し、それにより目標アカウント識別モデルをトレーニングすることにより、目標アカウントに対する識別効率を向上させる。

【特許請求の範囲】

【請求項1】

アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップと、
前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップと、
前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するとともに、前記識別対象アカウントをモデルトレーニングサーバに送信するステップと、
前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップと、
前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップと、を含む
アカウントの識別方法。

【請求項2】

前記アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップは、
アカウント処理サーバにより全てのリソース移転記録におけるアカウントデータを取得するとともに、前記リソース移転記録において前記アカウントデータにおけるリソース事前取得アカウントとリソース受信アカウントとが同一であるか否かを判断するステップと、
前記リソース移転記録におけるリソース事前取得アカウントとリソース受信アカウントとが同一である場合、前記リソース移転記録のアカウントデータをフィルタリングするステップと、
前記リソース移転記録におけるリソース事前取得アカウントとリソース受信アカウントとが異なる場合、前記リソース移転記録のアカウントデータをアカウント関係データテーブルに追加するステップと、を含む
請求項１に記載のアカウントの識別方法。

【請求項3】

前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップは、
前記アカウント関係データテーブルから前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを取得するとともに、各リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントをアカウントノードとして複数組のアカウントノード関係ペアを生成するステップと、
それぞれ各組のアカウントノード関係ペアにおける一方のアカウントノードを頂点とし、他方のアカウントノードを前記頂点に対応する接続点として、アカウントノードテーブルを得るステップと、
前記アカウントノードテーブルにおける同じ頂点に対応する接続点を前記頂点に対応する隣接集合として同じ集合に追加するとともに、前記隣接集合に基づいてノード隣接テーブルを生成するステップと、
前記ノード隣接テーブルにおける各隣接集合に基づいて候補ノード隣接テーブルを得るとともに、前記候補ノード隣接テーブルと前記ノード隣接テーブルとが同一であるか否かを判断するステップと、
前記候補ノード隣接テーブルと前記ノード隣接テーブルとが異なる場合、前記候補ノード隣接テーブルを前記ノード隣接テーブルとするとともに、前記候補ノード隣接テーブルを更新するステップと、
前記候補ノード隣接テーブルと前記ノード隣接テーブルとが同一である場合、前記ノード隣接テーブルに基づいて複数の接続アカウント集合を得るステップと、を含む
請求項１に記載のアカウントの識別方法。

【請求項4】

前記ノード隣接テーブルにおける各隣接集合に基づいて候補ノード隣接テーブルを得るステップは、
それぞれ前記隣接集合内の各アカウントノードを頂点とするとともに、前記アカウントノードが位置する隣接集合を前記頂点に対応する隣接集合とするステップと、
同じ頂点に対応する各隣接集合の和集合を取って候補隣接集合を得るとともに、前記候補隣接集合に基づいて候補ノード隣接テーブルを生成するステップと、を含む
請求項３に記載のアカウントの識別方法。

【請求項5】

前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するステップは、
前記アカウント関係データテーブルにより前記接続アカウント集合内の各組のリソース事前取得アカウントとリソース受信アカウントとの間のリソース移転回数を取得するステップと、
前記接続アカウント集合内のアカウントの総数及び前記接続アカウント集合において前記リソース事前取得アカウントとのリソース取得関係を持つ接続アカウントの数を取得するステップと、
前記リソース移転回数、前記接続アカウント集合内の接続アカウントの数及びアカウントの総数に基づいて、前記リソース事前取得アカウントの親切度を得るステップと、
前記接続アカウント集合内の全てのリソース事前取得アカウントの親切度に基づいて、各前記接続アカウント集合において識別対象アカウントを確定するステップと、を含む
請求項１に記載のアカウントの識別方法。

【請求項6】

前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップは、
前記モデルトレーニングサーバにより前記識別対象アカウントを前記親切度に従って順序付けるとともに、順序付けの結果に基づいて全ての識別対象アカウントを複数の識別対象アカウント集合に分けるステップと、
各識別対象アカウント集合から予め設定されたサンプル数の識別対象アカウントを抽出してサンプルアカウントとするとともに、前記サンプルアカウントが目標アカウントであるか否かを判断するステップと、
前記サンプルアカウントにおける目標アカウントに第１タグを追加するとともに、前記サンプルアカウントにおける残りのサンプルアカウントに第２タグを追加するステップと、
前記アカウント関係データテーブルにより前記サンプルアカウントのアカウントデータ指標を取得するとともに、前記サンプルアカウントのアカウントデータ指標を入力とし、前記サンプルアカウントに対応するタグを出力とし、目標アカウント識別モデルをトレーニングするステップと、を含む
請求項５に記載のアカウントの識別方法。

【請求項7】

前記サンプルアカウントのアカウントデータ指標を入力とし、前記サンプルアカウントに対応するタグを出力とし、目標アカウント識別モデルをトレーニングするステップは、
前記サンプルアカウントのアカウントデータ指標に基づいて複数のモデルトレーニングデータセットを得るとともに、ランダムフォレストのアルゴリズムにより目標アカウント識別モデルを構築するステップと、
前記複数のモデルトレーニングデータセットを入力とし、前記サンプルアカウントに対応するタグを出力とし、前記ランダムフォレストのアルゴリズムにより構築される前記目標アカウント識別モデルをトレーニングするステップと、を含む
請求項６に記載のアカウントの識別方法。

【請求項8】

前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップは、
前記アカウント関係データテーブルにより前記識別対象アカウントのアカウントデータ指標を取得するとともに、前記識別対象アカウントのアカウントデータ指標を前記目標アカウント識別モデルに入力するステップと、
前記目標アカウント識別モデルの出力が前記第１タグである場合、前記識別対象アカウントが目標アカウントであると判定するステップと、を含む
請求項６に記載のアカウントの識別方法。

【請求項9】

アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップを実行するように構成されるアカウント関係データテーブル生成モジュールと、
前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップを実行するように構成される接続アカウント集合分割モジュールと、
前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するとともに、前記識別対象アカウントをモデルトレーニングサーバに送信するステップを実行するように構成される識別対象アカウント確定モジュールと、
前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップを実行するように構成されるアカウント識別モデルトレーニングモジュールと、
前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップを実行するように構成される目標アカウント判断モジュールと、を含む
アカウントの識別装置。

【請求項10】

プロセッサと、
１つ又は複数のプログラムを記憶するためのメモリと、を含み、前記１つ又は複数のプログラムが１つ又は複数のプロセッサにより実行される場合、１つ又は複数のプロセッサは、請求項１～請求項８のいずれか１項に記載のアカウントの識別方法を実現する
電子機器。

【請求項11】

コンピュータプログラムが記憶されたコンピュータ読み取り可能な媒体であって、前記プログラムがプロセッサにより実行される場合、請求項１～請求項８のいずれか１項に記載のアカウントの識別方法を実現するコンピュータ読み取り可能な媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、出願番号が２０２０１０３２８２０２．４であって、出願日が２０２０年０４月２３日であって、発明の名称が「アカウントの識別方法、装置、電子機器及びコンピュータ読み取り可能な媒体」である中国特許出願に基づいて優先権を主張し、当該中国特許出願の内容の全てを本願に援用する。

【0002】

本発明は、インターネット技術分野に関し、特に、アカウントの識別方法、アカウントの識別装置、電子機器及びコンピュータ読み取り可能な媒体に関する。

【背景技術】

【0003】

ネットショッピングの普及に伴って、ショッピングの過程において、例えば、あるネットショッピングプラットフォームでの店舗で他のネットショッピングプラットフォームの発注業務を提供する代理発注現象が常に発生している。これらのネットショッピングプラットフォームでの店舗は、いくつかの非正常手段によりクーポンを入手して他のプラットフォームのユーザーを惹き付けて代理発注サービスを提供したり、他のプラットフォームの使用に慣れているユーザーに代理発注サービスを提供したり、ネットショッピングができない消費者団体に顧客の代わりに代理発注するサービスを提供したりする可能性がある。

【0004】

現在、代理発注サービスを提供するユーザー団体は、識別するための専用のリスク制御システムを有しないので、一連の販売後の問題を引き起こして、ネットショッピングプラットフォームのユーザー体験に影響を及ぼす可能性があるが、人手で代理発注アカウントに対する識別の効率が低い。このため、上記の問題を解決するために、代理発注アカウントに対する識別の効率を向上させるアカウントの識別方法が求められている。

【0005】

なお、上記の背景技術の部分に開示されている情報は、本発明の背景に対する理解を深めるためのものに過ぎないため、当業者に知られている従来技術を構成しない情報を含むことができる。

【発明の概要】

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

【0006】

本発明は、少なくともある程度で目標アカウントに対する識別の効率を向上させるために、アカウントの識別方法、アカウントの識別装置、電子機器及びコンピュータ読み取り可能な媒体を提供することを目的とする。

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

【0007】

本発明の第１態様によれば、アカウントの識別方法を提供し、前記アカウントの識別方法は、
アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップと、
前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップと、
前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するとともに、前記識別対象アカウントをモデルトレーニングサーバに送信するステップと、
前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップと、
前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップと、を含む。

【0008】

本発明の一例示的な実施例において、前記アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップは、
アカウント処理サーバにより全てのリソース移転記録におけるアカウントデータを取得するとともに、前記リソース移転記録において前記アカウントデータにおけるリソース事前取得アカウントとリソース受信アカウントとが同一であるか否かを判断するステップと、
前記リソース移転記録におけるリソース事前取得アカウントとリソース受信アカウントとが同一である場合、前記リソース移転記録のアカウントデータをフィルタリングするステップと、
前記リソース移転記録におけるリソース事前取得アカウントとリソース受信アカウントとが異なる場合、前記リソース移転記録のアカウントデータをアカウント関係データテーブルに追加するステップと、を含む。

【0009】

本発明の一例示的な実施例において、前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップは、
前記アカウント関係データテーブルから前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを取得するとともに、各リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントをアカウントノードとして複数組のアカウントノード関係ペアを生成するステップと、
それぞれ各組のアカウントノード関係ペアにおける一方のアカウントノードを頂点とし、他方のアカウントノードを前記頂点に対応する接続点として、アカウントノードテーブルを得るステップと、
前記アカウントノードテーブルにおける同じ頂点に対応する接続点を前記頂点に対応する隣接集合として同じ集合に追加するとともに、前記隣接集合に基づいてノード隣接テーブルを生成するステップと、
前記ノード隣接テーブルにおける各隣接集合に基づいて候補ノード隣接テーブルを得るとともに、前記候補ノード隣接テーブルと前記ノード隣接テーブルとが同一であるか否かを判断するステップと、
前記候補ノード隣接テーブルと前記ノード隣接テーブルとが異なる場合、前記候補ノード隣接テーブルを前記ノード隣接テーブルとするとともに、前記候補ノード隣接テーブルを更新するステップと、
前記候補ノード隣接テーブルと前記ノード隣接テーブルとが同一である場合、前記ノード隣接テーブルに基づいて複数の接続アカウント集合を得るステップと、を含む。

【0010】

本発明の一例示的な実施例において、前記ノード隣接テーブルにおける各隣接集合に基づいて候補ノード隣接テーブルを得るステップは、
それぞれ前記隣接集合内の各アカウントノードを頂点とするとともに、前記アカウントノードが位置する隣接集合を前記頂点に対応する隣接集合とするステップと、
同じ頂点に対応する各隣接集合の和集合を取って候補隣接集合を得るとともに、前記候補隣接集合に基づいて候補ノード隣接テーブルを生成するステップと、を含む。

【0011】

本発明の一例示的な実施例において、前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するステップは、
前記アカウント関係データテーブルにより前記接続アカウント集合内の各組のリソース事前取得アカウントとリソース受信アカウントとの間のリソース移転回数を取得するステップと、
前記接続アカウント集合内のアカウントの総数及び前記接続アカウント集合において前記リソース事前取得アカウントとのリソース取得関係を持つ接続アカウントの数を取得するステップと、
前記リソース移転回数、前記接続アカウント集合内の接続アカウントの数及びアカウントの総数に基づいて、前記リソース事前取得アカウントの親切度を得るステップと、
前記接続アカウント集合内の全てのリソース事前取得アカウントの親切度に基づいて、各前記接続アカウント集合において識別対象アカウントを確定するステップと、を含む。

【0012】

本発明の一例示的な実施例において、前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップは、
前記モデルトレーニングサーバにより前記識別対象アカウントを前記親切度に従って順序付けるとともに、順序付けの結果に基づいて全ての識別対象アカウントを複数の識別対象アカウント集合に分けるステップと、
各識別対象アカウント集合から予め設定されたサンプル数の識別対象アカウントを抽出してサンプルアカウントとするとともに、前記サンプルアカウントが目標アカウントであるか否かを判断するステップと、
前記サンプルアカウントにおける目標アカウントに第１タグを追加するとともに、前記サンプルアカウントにおける残りのサンプルアカウントに第２タグを追加するステップと、
前記アカウント関係データテーブルにより前記サンプルアカウントのアカウントデータ指標を取得するとともに、前記サンプルアカウントのアカウントデータ指標を入力とし、前記サンプルアカウントに対応するタグを出力とし、目標アカウント識別モデルをトレーニングするステップと、を含む。

【0013】

本発明の一例示的な実施例において、前記サンプルアカウントのアカウントデータ指標を入力とし、前記サンプルアカウントに対応するタグを出力とし、目標アカウント識別モデルをトレーニングするステップは、
前記サンプルアカウントのアカウントデータ指標に基づいて複数のモデルトレーニングデータセットを得るとともに、ランダムフォレストのアルゴリズムにより目標アカウント識別モデルを構築するステップと、
前記複数のモデルトレーニングデータセットを入力とし、前記サンプルアカウントに対応するタグを出力とし、前記ランダムフォレストのアルゴリズムにより構築される前記目標アカウント識別モデルをトレーニングするステップと、を含む。

【0014】

本発明の一例示的な実施例において、前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップは、
前記アカウント関係データテーブルにより前記識別対象アカウントのアカウントデータ指標を取得するとともに、前記識別対象アカウントのアカウントデータ指標を前記目標アカウント識別モデルに入力するステップと、
前記目標アカウント識別モデルの出力が前記第１タグである場合、前記識別対象アカウントが目標アカウントであると判定するステップと、を含む。

【0015】

本発明の第２態様によれば、アカウントの識別装置を提供し、前記アカウントの識別装置は、
アカウント処理サーバによりリソース事前取得アカウントとリソース受信アカウントとが異なるリソース移転記録を取得するとともに、前記リソース移転記録に基づいてアカウント関係データテーブルを生成するステップを実行するように構成されるアカウント関係データテーブル生成モジュールと、
前記アカウント関係データテーブルに基づいて、前記リソース移転記録におけるリソース事前取得アカウント及びリソース受信アカウントを複数の接続アカウント集合に分割するステップを実行するように構成される接続アカウント集合分割モジュールと、
前記接続アカウント集合内の各アカウント間の接続関係に基づいて各前記接続アカウント集合内の識別対象アカウントを確定するとともに、前記識別対象アカウントをモデルトレーニングサーバに送信するステップを実行するように構成される識別対象アカウント確定モジュールと、
前記モデルトレーニングサーバにより前記識別対象アカウントからサンプルアカウントを抽出するとともに、前記サンプルアカウントによりトレーニングして目標アカウント識別モデルを得るステップを実行するように構成されるアカウント識別モデルトレーニングモジュールと、
前記目標アカウント識別モデルにより前記識別対象アカウントが目標アカウントであるか否かを判断するステップを実行するように構成される目標アカウント判断モジュールと、を含む。

【0016】

本発明の第３態様によれば、電子機器を提供し、前記電子機器は、プロセッサと、前記プロセッサの実行可能な命令を記憶するためのメモリと、を含み、ここで、前記プロセッサは、前記実行可能な命令を実行することにより、第１態様に記載の方法を実行するように構成される。

【0017】

本発明の第４態様によれば、コンピュータプログラムが記憶されたコンピュータ読み取り可能な媒体を提供し、前記コンピュータプログラムがプロセッサにより実行される場合、第１態様に記載の方法を実現する。

【0018】

なお、前記一般的な記載及び後述の詳細な記載は、単なる例示的で解釈的な記載であり、本発明を限定するものではない。

【0019】

以下の図面は、明細書に組み入れて本明細書の一部分を構成し、本発明に該当する実施例を例示するとともに、明細書とともに本発明の原理を解釈するように構成される。なお、以下の記載における図面はただ本発明の一部の実施例に過ぎず、当業者の場合、創造的な労働を付与しない前提で、これらの図面によって他の図面を得ることができる。

【図面の簡単な説明】

【0020】

【図1】図１は、本発明の例示的な実施形態に係るアカウントの識別方法のフローを示す模式図である。

【図2】図２は、本発明の例示的な実施形態に係るアカウント関係データテーブルを生成するフローを示す模式図である。

【図3】図３は、本発明の例示的な実施形態に係る接続アカウント集合を確定するフローを示す模式図である。

【図4】図４は、本発明の１つの具体的な実施形態に係るユーザー関係辺の取得を模式的に示す模式図である。

【図5】図５は、本発明の１つの具体的な実施形態に係るノード隣接テーブルの取得を模式的に示す模式図である。

【図6】図６は、本発明の例示的な実施形態に係る候補ノード隣接テーブルを確定するフローを示す模式図である。

【図7】図７は、本発明の１つの具体的な実施形態に係るノードクラスタグの取得を模式的に示す模式図である。

【図8】図８は、本発明の１つの具体的な実施形態に係るノードクラスタグの分散型ユニオン検索集合（Ｕｎｉｏｎ－Ｆｉｎｄ Ｓｅｔｓ）の併合を模式的に示す模式図である。

【図9】図９は、本発明の例示的な実施形態に係る識別対象アカウントを確定するフローを示す模式図である。

【図10】図１０は、本発明の例示的な実施形態に係る目標アカウント識別モデルをトレーニングするフローを示す模式図である。

【図11】図１１は、本発明の例示的な実施形態に係るランダムフォレストのアルゴリズムにより構築される目標アカウント識別モデルをトレーニングするフローを示す模式図である。

【図12】図１２は、本発明の例示的な実施形態に係る目標アカウントを識別するフローを示す模式図である。

【図13】図１３は、本発明の１つの具体的な実施例におけるアカウントの識別方法の完全なブロック図である。

【図14】図１４は、本発明の例示的な実施形態に係るアカウントの識別装置を示すブロック図である。

【図15】図１５は、本発明の実施例に係る電子機器を実現するのに適したコンピュータシステムの構造を示す模式図である。

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

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

【数1】

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

本発明のいくつかの例示的な実施例において、識別モデルトレーニングユニットは、識別モデル構築ユニット及びマルチモデルトレーニングユニットを含むことができる。ここで、
識別モデル構築ユニットは、サンプルアカウントのアカウントデータ指標に基づいて複数のモデルトレーニングデータセットを得るとともに、ランダムフォレストのアルゴリズムにより目標アカウント識別モデルを構築するステップを実行するように構成される。

【0137】

マルチモデルトレーニングユニットは、複数のモデルトレーニングデータセットを入力とし、サンプルアカウントに対応するタグを出力とし、ランダムフォレストのアルゴリズムにより構築される目標アカウント識別モデルをトレーニングするステップを実行するように構成される。

【0138】

本発明のいくつかの例示的な実施例において、目標アカウント判断モジュール１４５０は、アカウントデータ入力ユニット及び目標アカウント識別ユニットを含むことができる。ここで、
アカウントデータ入力ユニットは、アカウント関係データテーブルにより識別対象アカウントのアカウントデータ指標を取得するとともに、識別対象アカウントのアカウントデータ指標を目標アカウント識別モデルに入力するステップを実行するように構成される。

【0139】

目標アカウント識別ユニットは、目標アカウント識別モデルの出力が第１タグである場合、識別対象アカウントが目標アカウントであると判定するステップを実行するように構成される。

【0140】

上記のアカウントの識別装置における各モジュール／ユニットの具体的な詳細は、対応する方法の実施例の部分で詳細に説明されたので、ここで詳細な説明を省略する。

【0141】

図１５は、本発明の実施例に係る電子機器を実現するのに適したコンピュータシステムの構造を示す模式図である。

【0142】

なお、図１５に示される電子機器のコンピュータシステム１５００は、単なる一例であり、本発明の実施例の機能及び使用範囲に何ら制限を課すものではない。

【0143】

図１５に示すように、コンピュータシステム１５００は、中央処理装置（ＣＰＵ）１５０１を含み、読み取り専用メモリ（ＲＯＭ）１５０２に記憶されているプログラム又は記憶部１５０８からランダムアクセスメモリ（ＲＡＭ）１５０３にロードされたプログラムに基づいて、適切な各種動作と処理を実行することができる。ＲＡＭ １５０３には、システムの操作に必要な各種プログラム及びデータがさらに記憶される。ＣＰＵ１５０１、ＲＯＭ １５０２及びＲＡＭ １５０３は、バス１５０４を介して相互に接続されている。入力／出力（Ｉ／Ｏ）インタフェース１５０５もバス１５０４に接続される。

【0144】

Ｉ／Ｏインタフェース１５０５には、キーボード、マウスなどを含む入力部１５０６、例えば陰極線管（ＣＲＴ、Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、液晶ディスプレイ（ＬＣＤ、Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）など及びスピーカなどを含む出力部１５０７、ハードディスクなどを含む記憶部１５０８及び例えばＬＡＮカード、モデムなどのネットワークインタフェースカードを含む通信部１５０９が接続される。通信部１５０９は、例えばインターネットのようなネットワークを介して通信処理を実行する。ドライバ１５１０も必要に応じてＩ／Ｏインタフェース１５０５に接続される。例えば磁気ディスク、光ディスク、磁光ディスク、半導体メモリなどのような取り外し可能な媒体１５１１は、必要に応じてドライバ１５１０にインストールされることにより、それから読み出されたコンピュータプログラムは、必要に応じて記憶部１５０８にインストールされる。

【0145】

特に、本発明の実施例によれば、以下、フローチャートを参照して説明する過程は、コンピュータソフトウェアプログラムとして実現されることができる。例えば、本発明の実施例は、コンピュータ読み取り可能な媒体に担持されるコンピュータプログラムを含むコンピュータプログラム製品を含み、前記コンピュータプログラムは、フローチャートに示される方法を実行するためのプログラムコードを含む。このような実施例において、当該コンピュータプログラムは、通信部１５０９を介してネットワークからダウンロードされてインストールされ、及び／又は取り外し可能な媒体１５１１からインストールされることができる。前記コンピュータプログラムが中央処理装置（ＣＰＵ）１５０１により実行される場合、本発明のシステムに限定される各種機能を実行する。

【0146】

なお、本発明に係るコンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な信号媒体又はコンピュータ読み取り可能な記録媒体又はそれらの任意の組み合せであってもよい。コンピュータ読み取り可能な記録媒体は、例えば電気、磁気、光、電磁、赤外線、もしくは半導体のシステム、装置、もしくはデバイス、またはそれらの任意の組合せであってもよいが、これらに限定されない。コンピュータ読み取り可能な記録媒体のより具体的な例は、１つ以上のワイヤを有する電気接続、携帯型コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）またはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、光学記憶デバイス、磁気記憶デバイス、または上記の任意の適切な組み合わせを含むことができるが、これらに限定されない。本発明において、コンピュータ読み取り可能な記録媒体は、命令実行システム、装置、又はデバイスによって、又はそれらと共に使用され得るプログラムを包含又は記憶する任意の有形媒体であってもよい。本発明において、コンピュータ読み取り可能な信号媒体は、ベースバンドで、または搬送波の一部として伝搬されるデータ信号を含むことができ、その中にコンピュータ読み取り可能なプログラムコードが担持される。そのような伝播されるデータ信号は、電磁信号、光信号、又は上記の任意の適切な組み合わせを含むがこれらに限定されない、様々な形態をとり得る。コンピュータ読み取り可能な信号媒体は、また、命令実行システム、装置、またはデバイスによって、またはそれらと関連して使用するためのプログラムを送信、伝播、または伝送し得る、コンピュータ読み取り可能な記録媒体以外の任意のコンピュータ読み取り可能な媒体であってもよい。コンピュータ読み取り可能な媒体に含まれるプログラムコードは、無線、電線、光ケーブル、ＲＦ等、またはこれらの任意の適切な組み合わせを含むがこれらに限定されない、任意の適切な媒体で伝送され得る。

【0147】

図面におけるフローチャート及びブロック図は、本発明の様々な実施例によるシステム、方法及びコンピュータプログラム製品の実現可能なアーキテクチャ、機能及び操作を示す。この点で、フローチャート又はブロック図における各ブロックは、１つのモジュール、プログラムセグメント又はコードの一部を代表することができ、上記のモジュール、プログラムセグメント又はコードの一部は、１つ又は複数の所定の論理機能を実現するための実行可能な命令を含む。また、いくつかの代替的な実施形態において、ブロックに記載された機能は、図面に記載された順序と異なる順序で実行されてもよいことに留意されたい。例えば、連続して示されるブロックは、実際に略並列に実行されてもよく、関連する機能によっては逆の順序で実行されることもある。なお、ブロック図又はフローチャートにおける各ブロック、及びブロック図又はフローチャートにおけるブロックの組み合わせは、所定の機能又は操作を実行するための専用のハードウェアベースのシステムで実現され、又は専用のハードウェアとコンピュータ命令との組み合わせで実現されてもよいことに留意されたい。

【0148】

他の態様によれば、本発明は、コンピュータ読み取り可能な媒体をさらに提供する。前記コンピュータ読み取り可能な媒体は、上記の実施例に係る電子機器に含まれるものであってもよく、単独で存在するが前記電子機器に組み込まれていないものであってもよい。上記のコンピュータ読み取り可能な媒体には、１つ又は複数のプログラムが配置され、上記の１つ又は複数のプログラムが前記電子機器により実行される場合、前記電子機器は、以下の実施例に記載の方法を実現する。

【0149】

上記の詳細な説明では、動作実行のための機器のいくつかのモジュールが言及されているが、このような分割は強制的ではないことに留意されたい。実際には、本発明の実施形態によれば、上記に説明した二つ以上のモジュールの特徴と機能について、一つのモジュールに具体化されてもよい。これに対して、上記に説明した一つのモジュールの特徴と機能について、複数のモジュールにさらに分割され、具体化されてもよい。

【0150】

当業者は明細書を考慮し、ここに開示された発明を実践した後、本発明の他の実施案を容易に想到する。本発明は、本発明に対する任意の変形、用途、又は適応的な変化を含み、このような変形、用途、又は適応的な変化は、本発明の一般的な原理に従い、本発明では開表していない本技術分野の公知知識、又は通常の技術手段を含む。

【0151】

本発明は、上記で記述され、図面で図示した特定の構成に限定するものではなく、その範囲を逸脱しない範囲で、様々な修正や変更を実施してもよい。本発明の範囲は、添付する特許請求の範囲のみによって限定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【国際調査報告】