JP2009531772A - クライアントカテゴリ構成 - Google Patents

Abstract

クライアントから取得した構成データに基づきクライアントのカテゴリを見つけるために、コンピュータによって実装される方法を使用できるクライアントカテゴリ構成について説明されている。そこで、特定のカテゴリに含まれるクライアントのうちの１つまたは複数のクライアントの構成に基づき、複数のカテゴリのうちの特定の１つのカテゴリについて、構成推奨が作成される。

Description

本発明は、クライアントカテゴリ構成に関する。

ユーザーが利用できる機能性は、高まる一方である。例えば、ユーザーは、デスクトップパーソナルコンピュータ（ＰＣ）、ノートブックコンピュータ、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、ゲーム機などの増大し続けるさまざまなコンピューティングデバイスに曝されている。さらに、これらのデバイス上で実行可能なさまざまなソフトウェアも、通信アプリケーション（例えば、ブラウザ、インスタントメッセージング、および電子メール）、生産性アプリケーション（例えば、文書処理、表計算、プレゼンテーション、メモ取り、グラフィカルデザイン）、ゲームなどから増え続ける一方である。

ユーザーがこのような機能を管理するのを支援するために利用される技術の１つは、メンテナンスサービスの使用によるものである。メンテナンスサービスは、例えば、ユーザーに対しコンピューティングデバイスの構成に関する推奨を行うことができる。しかし、ユーザーが利用できる機能にはさまざまなものがあり、この機能にアクセスするため、またこの機能から選択するために、ユーザーによって多種多様の構成が使用されうる。例えば、ユーザーは、異なるさまざまなコンピューティングデバイスの中から選択し、また先に説明したように利用可能な異なるさまざまなソフトウェアの中から選択することができる。したがって、コンピューティングデバイスにより使用されるソフトウェアおよびハードウェアの構成は、ユーザー毎に大きく異なりうる。しかし、従来のメンテナンスサービス技術では、コンピューティングデバイスの区別を行わず、むしろ、それぞれのデバイスにより使用されるべき一般的推奨を行っていた。しかし、構成が異なると、クライアントの１つまたは複数に対し推奨が適用不可能となる場合がある。さらに、これらの推奨を行った結果、「適用不可能な」コンピューティングデバイスの機能が縮小し、その結果ユーザーの側にフラストレーションが溜まることにすらなりうる。

クライアントカテゴリ構成について説明する。一実装では、クライアントから取得した構成データに基づきクライアントのカテゴリを見つけるために、コンピュータによって実装される方法が使用される。次いで、特定のカテゴリに含まれるクライアントのうちの１つまたは複数のクライアントの構成に基づき、複数のカテゴリのうちの特定の１つのカテゴリについて、構成推奨を作成する。

この欄の記載では、以下の「発明を実施するための最良の形態」欄でさらに説明される概念のいくつかを簡素化された形式で導入する。この欄の記載は、請求された主題の重要な特徴または本質的な特徴を特定することを意図したものではないし、また請求された主題の範囲を決定する際の補助として使用されることを意図したものではない。

類似の構造およびコンポーネントを参照する場合に、説明の中のいくつかの例において同じ参照番号が使用される。

概要
コンピューティングデバイスのユーザーが利用できる機能性は、高まる一方である。ユーザーがこのような機能を管理するのを支援するために利用されうる技術の１つは、メンテナンスサービスを使用によるものである。例えば、メンテナンスサービスは、コンピューティングデバイス上で実行されているアプリケーションに関係するユーザーによって下される決定、バックアップ用に選択されたファイルなど、コンピューティングデバイスの構成に関するデータをコンピューティングデバイスから取得することができる。このデータは、構成に関する推奨を行うことなどにより、サービスのユーザーにより良好なサービスを提供することを目的として分析することができる。

しかし、メンテナンスサービスにより使用された従来の技術は、推奨を行うアプローチとして「多数決（ｍａｊｏｒｉｔｙ ｗｉｎｓ）」方式を採用した。しかし、これらの推奨は、それぞれのコンピューティングデバイス、地理学的および人口統計学的市場などに関係しない場合がある。そこで、カテゴリ内のコンピューティングデバイスと一致する基準に基づいて、収集されたデータを分類し、推奨を作成して、それによりユーザーに対してより意味のある、関連性の高いエクスペリエンスを提供する技術について説明する。

例えば、ユーザーは、「ピア」つまり多くの点で自分たちに似ている人々によってもたらされる推奨を高く評価する傾向が強い。例えば、ゲーマーは、どのようなアプリケーションが、他のゲーマーにより下された決定に基づきネットワークへのアクセスを許されるのかを知りたがる場合があり、これは、「一般の」顧客ベースにより下された決定に反することすらありうる。したがって、これらの技術は、豊かなエクスペリエンスをもたらし、顧客満足度を改善するように推奨を自動的に調整することができる。

以下の説明では、クライアントカテゴリ構成技術を実行するように動作可能な例示的な環境をまず最初に説明する。次いで、この環境に加えて他の環境でも使用できる例示的な手順について説明する。

例示的な環境
図１は、クライアントカテゴリ構成技術を使用するように動作可能な例示的な実装における環境１００を示す図である。示されている環境１００は、ネットワーク１０６を介してクライアントメンテナンスサービス１０４に通信可能に結合されている複数のクライアント１０２（１）、・・・、１０２（Ｎ）を備える。クライアント１０２（１）〜１０２（Ｎ）は、ネットワーク１０６にアクセスするためにさまざまな方法で構成されうる。例えば、クライアント１０２（１）〜１０２（Ｎ）の１つまたは複数は、デスクトップコンピュータ、移動局、エンターテインメントアプライアンス、表示デバイスと通信可能に結合されたセットトップボックス、携帯電話、ゲーム機などの、コンピューティングデバイスとして構成してもよい。したがって、クライアント１０２（１）〜１０２（Ｎ）は、大容量のメモリおよびプロセッサ資源を有するフルリソースのデバイス（例えば、パーソナルコンピュータ、ゲーム機）から、限られたメモリおよび／または処理資源を有するローリソースデバイス（例えば、従来のセットトップボックス、携帯ゲーム機）まで多岐にわたってもよい。クライアント１０２（１）〜１０２（Ｎ）はさらに、クライアントを操作する人間および／または（何らかの）実体に関係してもよい。言い換えると、クライアント１０２（１）〜１０２（Ｎ）の１つまたは複数は、ユーザー、ソフトウェア、および／またはデバイスを含む論理的クライアント（ｌｏｇｉｃａｌ ｃｌｉｅｎｔ）を表すものとすることができる。

ネットワーク１０６はインターネットとして示されているが、ネットワークは多種多様な構成を取りうる。例えば、ネットワーク１０６は、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、公衆電話網、イントラネットなどを含むことができる。さらに、単一のネットワーク１０６が示されているが、ネットワーク１０６は、複数のネットワークを含むように構成されてもよい。

クライアント１０２（１）〜１０２（Ｎ）は、それぞれの監視モジュール１０８（１）〜１０８（Ｎ）を有するものとしてそれぞれ示されている。監視モジュール１０８（１）〜１０８（Ｎ）は、それぞれのクライアント１０２（１）〜１０２（Ｎ）の構成を監視するロジックを表している。この監視から生成されるデータは、それぞれの記憶装置１１４（１）〜１１４（Ｎ）に収められている構成データ１１０（ｄ）およびデータ１１２（ｅ）（「ｄ」および「ｅ」は、それぞれ１（ｏｎｅ）から「Ｄ」および「Ｅ」までのいずれかの整数とすることができる。）として示されている。次いで、この構成データは、ネットワーク１０６を介して定期的間隔でクライアントメンテナンスサービス１０４にアップロードされ、構成データ１１０（ｃ）として記憶装置１１６に格納されてもよい。

クライアントメンテナンスサービス１０４は、図１に示されているように、構成データ１１０（ｃ）を処理する機能を表す構成マネージャモジュール１１８を備える。例えば、構成マネージャモジュール１１８は実行されると、構成データ１１０（ｃ）を調べて、記憶装置１２２内に格納されているものとして示されている複数のクライアントカテゴリ１２０（ｋ）（ここで「ｋ」は、２（ｔｗｏ）から「Ｋ」までのいずれかの整数とすることができる。）に到達することができる。クライアントカテゴリ１２０（ｋ）は、グループ内のクライアントの共通性を参照する。例えば、このようなクライアントカテゴリ１２０（ｋ）の１つは、さまざまなゲームへのインターネットアクセスを許可するクライアント１０２（１）〜１０２（Ｎ）の特定のグループにより定義された「ゲーマー」としてもよい。構成マネージャモジュール１１８は、次いで、グループ内の他のものが実行するアクションに基づきこのグループ全体に推奨を行うことができる。

例えば、ネットワーク１０６へのアクセスを通じて「オンライン」エクスペリエンスを提供する新規ゲームモジュールをクライアント１０２（１）〜１０２（Ｎ）に供給することができる。最初の数人のゲーマーは、新しいゲームモジュールをセットアップするときに、ゲームモジュールが構成設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｅｔｔｉｎｇ）を使用することでネットワーク１０６にアクセスすることを許可することができる。この決定に関する情報は、同じクライアントカテゴリ１２０（ｋ）（例えば、「ゲーマー」）内の他のクライアントに投入することができ、それにより、他のクライアントが最初の数人のゲーマーたちによりなされたような構成を手作業で設定することを強制されなくなる。このようにして、既知のクライアントカテゴリから収集された知識を活用して、それらのカテゴリに分類されている他のクライアントに代わって類似のアクションを実行することができる。クライアントから得られた構成データ１１０（ｃ）に基づくクライアント１０２（１）〜１０２（Ｎ）のカテゴリ分類の詳細は、図３に関して説明されている。また、クライアントから得られた構成データ１１０（ｃ）に基づくモジュールのカテゴリ分類の詳細は、図４に関して説明されている。

クライアントメンテナンスサービス１０４は、さらに、構成マネージャモジュール１１８を使用して、新規クライアントを分類することもできる。例えば、「新規」クライアントが、クライアントメンテナンスサービス１０４に接続することができる。構成マネージャモジュール１１８は、クライアントを調査し、その調査結果に基づき、クライアントをクライアントカテゴリ１２０（ｋ）のうちの１つまたは複数のカテゴリに入れることができる。例えば、クライアントは、さまざまなゲームを備え、「ゲーマー」カテゴリおよびさまざまな財務会計ソフトウェアに入れることができ、したがって、「財務」カテゴリに入れることができる。次いで、それぞれのカテゴリへのクライアントの帰属関係に基づき、クライアントへの推奨を行うことができるが、詳細は、図４に関して説明されている。

一般に、本明細書で説明されている機能のいずれも、ソフトウェア、ファームウェア（例えば、固定論理回路（ｆｉｘｅｄ ｌｏｇｉｃ ｃｉｒｃｕｉｔｒｙ））、手動処理、またはこれらの実装の組み合わせを用いて実装することができる。本明細書で使用される「モジュール」、「機能」、および「ロジック（ｌｏｇｉｃ）」という用語は、一般的に、ソフトウェア、ファームウェア、またはソフトウェアとファームウェアの組み合わせを表す。ソフトウェアによる実装の場合、モジュール、機能、またはロジックは、プロセッサ（例えば、１つまたは複数のＣＰＵ）上で実行された場合に指定されたタスクを実行するプログラムコードを表す。プログラムコードは、１つまたは複数のコンピュータ可読（ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ）メモリデバイス内に格納することができるが、詳細については、図２に関して説明される。後述のクライアントカテゴリ構成技術の特徴は、プラットフォーム独立であること、つまり、これらの技術は、さまざまなプロセッサを有するさまざまな市販のコンピューティングプラットフォーム上で実装できるということを意味している。

図２は、クライアントメンテナンスサービス１０４および図１の複数のクライアントをより詳しく示す例示的実装におけるシステム２００を示す図である。クライアントメンテナンスサービス１０４は、サーバー２０２により実装されているものとして示されており、単一のサーバー２０２が例示されているが、サーバー２０２は、複数のサーバー、例えば、サーバークラスタを表していてもよい。図２においてクライアントデバイスとして示されているクライアント１０２（ｎ）は、クライアント１０２（１）〜１０２（Ｎ）のうちのいずれか１つのクライアントを表すことができる。したがって、サーバー２０２およびクライアント１０２（Ｎ）は、それぞれのプロセッサ２０４、２０６（ｎ）、およびメモリ２０８、２１０（ｎ）を有するものとして例示されている。

プロセッサは、そのプロセッサを構成する材料またはその中で使用される処理メカニズムにより制限されない。例えば、プロセッサは、１つまたは複数の半導体および／またはトランジスタ（例えば、電子集積回路（ＩＣ））を含むことができる。このような状況において、プロセッサ実行可能命令は、電子的実行可能命令であってもよい。あるいは、プロセッサのメカニズムまたはプロセッサのためのメカニズム、したがってコンピューティングデバイスのメカニズムまたはコンピューティングデバイスのためのメカニズムは、これらに限定されないが、（例えば、ナノテクノロジーを使用する）量子コンピューティング、光コンピューティング、機械コンピューティングなどを含むことができる。それに加えて、サーバー２０２およびクライアント１０２（ｎ）について、それぞれ、単一のメモリ２０８、２１０が図示されているが、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクメモリ、リムーバブル可能媒体メモリ、およびその他のタイプのコンピュータ可読媒体などの、さまざまな種類および組み合わせのメモリを使用することができる。例えば、クライアントカテゴリ１２０（ｋ）は、ＲＡＭ内に保持されうるが、構成データ１１０（ｃ）は、ハードディスクドライブ内に保持されうる。さまざまなその他の実施例も考えられる。

クライアント１０２（ｎ）は、プロセッサ２０６（ｎ）上で監視モジュール１０８（ｎ）を実行するものとして例示されているが、このモジュールはメモリ２１０（ｎ）に格納することもできる。監視モジュール１０８（ｎ）は、すでに説明されているように、クライアント１０２（ｎ）の構成を記述する構成データ１１０（ｎ）を生成するために実行可能である。例えば、構成データ１１０（ｎ）は、モジュール２１２（例えば、アプリケーション、サードパーティ製プラグインモジュールなど）、ファイル２１４（例えば、特定のファイル名の拡張子などのファイルの種類）、設定２１６（例えば、モジュール２１２の設定、ハードウェア設定、およびネットワーク設定）、および、モジュールの実行時に実行されるアクションに対する応答、ファイル２１４（例えば、バックアップ記憶装置）に関する特定の挙動などの、クライアント１０２（ｎ）の構成を記述する「その他」２１８の構成データ１１０を記述することができる。

クライアント１０２（ｎ）の構成データ１１０（ｎ）は、ネットワーク１０６を介してクライアントメンテナンスサービス１０４にアップロードされ（定期的間隔、閾値量のデータが生成されたときなどのタイミングで）、メモリ２０８内に構成データ１１０（ｃ）として格納されうる。次いで、構成データ１１０（ｃ）は、構成マネージャモジュール１１８によりさまざまな方法で処理できる。

例えば、構成データ１１０（ｃ）は、複数のクライアントカテゴリ１２０（ｋ）を生成するために使用されうる。例えば、クライアントカテゴリ１２０（ｋ）は、構成マネージャモジュール１１８による構成データ１１０（ｃ）の分析を通じてクライアント１０２（ｎ）の構成中に検出された類似点に基づき自動的に生成することができる。クライアントカテゴリ１２０（ｋ）の類似点は、趣味２２０、職業２２２、共通の関心２２４、およびその他２２６の共通性など多種多様なグループ分けを反映しうる。例えば、これらの共通性は、クライアント１０２（ｎ）のそれぞれに含まれるモジュール２１２、ファイル２１４、設定２１６により反映されうる。

次いで、クライアントカテゴリ１２０（ｋ）を使用して、そのカテゴリに特有の構成推奨を見つけることができる。したがって、これらの推奨は、カテゴリ内のクライアント１０２（ｎ）のそれぞれに関連する傾向が強い。それに加えて、新規クライアントに遭遇すると、クライアントは、新規クライアントのモジュール２１２、ファイル２１４、および設定２１６に基づきクライアントカテゴリ１２０（ｋ）のうちの１つまたは複数のカテゴリに分類されうる。さらに、新規モジュール（例えば、新規ゲーム、生産性アプリケーション、サードパーティ製プラグインモジュールなど）も、どのクライアント１０２（ｎ）がそのモジュールを取得し、かつ／または使用したかに基づき分類されうる。さらに、このクライアントカテゴリ分類プロセスは、クライアントカテゴリ１２０（ｋ）を再調整するために定期的間隔で繰り返すことができる。クライアントカテゴリ構成技術のさらなる説明は、以下の図に関連して行われる。

例示的な手順
以下では、先に説明したシステムおよびデバイスを使用して実装することができるクライアントカテゴリ構成技術について説明する。これらの手順のそれぞれの態様は、ハードウェア、ファームウェア、もしくはソフトウェア、またはそれらの組み合わせで実装することができる。これらの手順は、１つまたは複数のデバイスにより実行されるオペレーションを指定する一組のブロックとして示されており、必ずしも、それぞれのブロックによるオペレーションの実行について示された順序に限定されない。以下の説明の一部において、図１の環境１００および図２のシステム２００を参照する。

図３は、クライアントのカテゴリを見つけ、複数のカテゴリのうちの特定の１つのカテゴリについて構成推奨を作成するために構成データが使用される例示的な一実装における手順３００を示す。クライアントの構成が監視される（ブロック３０２）。例えば、クライアント１０２（ｎ）は、監視モジュール１０８（ｎ）を実行して、クライアント上にどのようなアプリケーションが格納されているか、それらのアプリケーションに関係する設定、クライアント１０２（ｎ）上に格納されているファイルタイプ、どのファイルがクライアント１０２（ｎ）上にバックアップされるか（例えば、２つの異なるメモリデバイス上に格納されるように構成された財務ファイル）など、クライアント１０２（ｎ）の使用を監視することができる。それに加えて、監視は、構成が変更された後の信頼性、性能の変更など、クライアントによる変更の結果として実現される性能の記述を含むように実行されうる。

構成を記述するデータが、クライアント管理サービスにパブリッシュされる（ブロック３０４）。例えば、監視モジュール１０８（ｎ）は、定期的間隔、構成が変更されたとき、閾値量の構成データ１１０（ｎ）が作成されたときなどのタイミングで構成データ１１０（ｎ）をパブリッシュするように構成できる。

クライアントのカテゴリが、クライアントから取得された構成データ内で示されている共通性に基づき見つけられる（ブロック３０６）。例えば、カテゴリは、モジュール（例えば、ゲーム、財務アプリケーション、グラフィカルデザインアプリケーション、サードパーティ製プラグインモジュールなど）、モジュールの設定、ファイル（例えば、購入され、ダウンロードされた楽曲ファイル）などの特定の組み合わせを有するクライアントを指定して形成することができる。

クライアントが属する複数のカテゴリのうちの１つまたは複数を識別する複数のクライアントのうちの１つまたは複数に伝達される指示が形成される（ブロック３０８）。例えば、指示にはクライアントが「ゲーマー」カテゴリや「財務」カテゴリに帰属することを記述することができる。この指示は、ユーザーに公開される場合も、公開されない場合もある。例えば、指示は、カテゴリに関してユーザーに通知することなく監視モジュール１０８（ｎ）による使用のため伝達してもよい。他の例では、ユーザー側で複数のカテゴリのうちの１つまたは複数を受理するか、拒否するか、または変更できるように、ユーザー側で確認できるように指示が出力される。さまざまな他の例も考えられる。

次いで、特定のカテゴリに含まれるクライアントのうちの１つまたは複数のクライアントの構成に基づき、複数のカテゴリのうちの特定の１つのカテゴリについて、構成推奨が作成される（ブロック３１０）。例えば、財務カテゴリのクライアントの部分集合では、ネットワークを介して３０分おきに財務アプリケーションにより金融口座にアクセスすることが可能である。しかし、このようなアクセスを行うことで、クライアントの性能が著しく低下するおそれがある。他方、財務カテゴリのクライアントの他の部分集合では、財務アプリケーションによる１時間おきの金融口座へのアクセスが可能であり、生じる機能性の低下はわずかである。したがって、財務アプリケーションに対するネットワークアクセス設定を１時間おきにアクセスするように設定することを指示する推奨を形成することができる。

他の実施例では、構成マネージャモジュール１１８は、財務カテゴリ内のクライアントが特定の拡張子を持つファイルを典型的にはバックアップすることを決定することができる。したがって、その拡張子を持つファイルのバックアップを提案する財務カテゴリ向けの推奨を形成することができる。さまざまな他の実施例も考えられる。

推奨は、特定のカテゴリ内の複数のクライアントのうちの少なくとも１つのクライアントに伝達される（ブロック３１２）。例えば、グループのそれぞれに対する推奨をパッケージ化して、複数のクライアント１０２（１）〜１０２（Ｎ）のうちのそれぞれに伝達することができる。次いで、クライアントは、それぞれのクライアントが属するカテゴリの指示（ｉｎｄｉｃａｔｉｏｎ）を使って、それらの推奨のうちのどの推奨がそのクライアントに関するものであるかを決定することができる。

クライアントの属しているカテゴリの決定をクライアントが行う他の場合には、どの推奨が関連しているのかをクライアント１０２（ｎ）に決定させることによりカテゴリ帰属関係に関してクライアントのプライバシーを保護するためにこのパッケージ化を使用できる。さまざまな他の事例も考えられる。

図４は、まだ検出されていなかったクライアントおよびモジュールを含む構成データが処理される例示的な一実装における手順４００を示す。複数のクライアント１０２（１）〜１０２（Ｎ）からパブリッシュされた構成データ、データ抽出サービスから得られた構成データなどの構成データが取得される（ブロック４０２）。

クライアント（ブロック４０４）およびモジュール（４０６）は、グローバル一意識別子（ＧＵＩＤ）、表されているデータのハッシュ（例えば、特定のファイルのデータから生成されたハッシュ値）などを使用して、構成データから抽出される。さまざまな他の抽出技術も考えられる。

まだ未検出であったクライアントが検出された場合、クライアントの構成が決定される（ブロック４０８）。例えば、構成マネージャモジュール１１８は、どのモジュールがクライアント上に含まれるか、モジュールの設定、ファイルタイプ、どのファイルがクライアントによってバックアップされたか、などを決定することができる。

クライアントは、カテゴリにより指定された構成とクライアントの構成とを比較することなどによる比較結果に基づき分類される（ブロック４１２）。一実装では、クライアントは、複数のカテゴリへの帰属を許されることに留意されたい。この実装では、矛盾する推奨は、クライアントが他のカテゴリに比べて特定の１つのカテゴリへの帰属に合っている、したがって特定のカテゴリについての推奨が「勝つ」と判定することなど、カテゴリを優先順位付けすることにより解決することができる。他の実装では、帰属は１つのカテゴリに制限され、したがって、矛盾する推奨は生じない。

カテゴリが、クライアントに伝達される（ブロック４１４）。したがって、この例では、処理は、構成マネージャモジュール１１８の実行によりクライアントメンテナンスサービス１０４により実行される。他の実施例では、クライアント１０２（ｎ）は、クライアントメンテナンスサービス１０４により定義された複数のカテゴリのうちのどのカテゴリがクライアント１０２（ｎ）に対応するかをクライアント１０２（ｎ）側で決定することなどにより、処理の全部または一部を実行することができる。さまざまな他の実施例も考えられる。

まだ検出されていないモジュールに対する１つまたは複数のカテゴリを見つけるために、類似の技術を使用できる。例えば、まだ検出されていないモジュールが検出された場合、どのクライアントがモジュールを含んでいるかが判定される（ブロック４１６）。次いで、そのモジュールを含んでいるクライアントが、カテゴリと比較される（ブロック４１８）。次いで、モジュールを含むように複数のカテゴリのうちの１つまたは複数を更新することができる（ブロック４２０）。例えば、モジュールを含む複数のクライアントのうちのかなりの割合が、「ゲーマー」カテゴリにも帰属していると判定されうる。したがって、モジュールを含むように「ゲーマー」カテゴリの定義を更新することができる。次いで、更新された１つまたは複数のカテゴリをそれぞれのカテゴリ内のクライアントに伝達することができる（ブロック４２２）。したがって、この場合、クライアントは、カテゴリの定義に基づきカテゴリ帰属関係を決定することができる。すでに説明されているよう、さまざまな他の実施例も考えられる。

図５は、クライアントがまだ遭遇していないモジュールに関して自動判定が実行され、モジュールがクライアントのカテゴリに含まれているか否かに基づき推奨が提供される例示的な一実装における手順５００を示す。クライアントは、１つのモジュールに遭遇する（ブロック５０２）。例えば、クライアント１０２（ｎ）は、コンテンツプロバイダからネットワーク１０６経由でモジュールをダウンロードすることができる。

モジュールがすでに分類されているか否かに関する決定が下される（決定ブロック５０４）。例えば、監視モジュール１０８（ｎ）は、クライアントメンテナンスサービス１０４から取得されたすでに識別されているモジュールのリストを備え、クライアント１０２（ｎ）が新規モジュールに遭遇したときには必ずこのリストを参照するようにできる。

モジュールが分類されていなかった場合（決定ブロック５０４からの「いいえ」）、クライアント１０２（ｎ）は、特定の特徴の構成に関する入力を求めるプロンプトを出す（ブロック５０６）。例えば、このプロンプトは、モジュールにネットワーク１０６へのアクセスを許可するか否かであってもよい。次いで、クライアント１０２（ｎ）は、アクセスを許可するか否かのプロンプトへの応答として入力を受け取ることができる。この入力は、クライアントメンテナンスサービスにも伝達されうる（ブロック５０８）。このようにして、クライアントメンテナンスサービス１０４は、モジュールの構成に関する入力を集め、集められた入力に基づき他のクライアントに推奨を行うことができる。

モジュールが分類されている場合（決定ブロック５０４からの「はい」）、モジュールがクライアントのカテゴリに含まれているか否かに関する判定が下される（決定ブロック５１０）。モジュールが含まれていない（決定ブロック５１０からの「いいえ」）場合、適切な推奨が行われる（ブロック５１２）。例えば、監視モジュール１０８（ｎ）は、モジュールがクライアントのカテゴリを「外れている」場合、ユーザーに注意する否定的な推奨（例えば、警告）を自動的に送出することができる。

モジュールが含まれている（決定ブロック５１０からの「はい」）場合、クライアントのカテゴリに基づき推奨が行われる（ブロック５１４）。前の例の続きとして、クライアントのカテゴリ内にモジュールが含まれていることに基づきネットワークアクセスを許可する「肯定的」推奨を行うことができる。さまざまな他の例も考えられる。

すでに設定されている構成の変更も、監視することができ、特別に考慮することができる。例えば、クライアント同士のやり取りを監視することにより（ブロック５１６）、構成の変更を検出することができる。次いで、クライアントがこの構成を再び変更したか否かに関する決定が下される（決定ブロック５１８）。変更していなければ（決定ブロック５１８からの「いいえ」）、サービス（例えば、クライアントメンテナンスサービス）は、新規構成を通知される（ブロック５２０）。しかし、変更されていれば（決定ブロック５１８からの「はい」）、このサービスは、クライアントによりすでに設定されていた構成が再び変更されたことを通知される（クロック５２２）。このようにして、監視モジュール１０８（ｎ）は、クライアントメンテナンスサービス１０４が構成データを特別に考慮することができるように構成データ１１０（ｎ）に「フラグ」を立てる。他の例では、構成メンテナンスサービス１０４それ自体が、構成がいつ変更されたかを判定する処理を実行することができることに留意されたい。したがって、前の設定に変更があったということは、前の結果が望ましくないものであったことを示している可能性があるため、将来推奨を行うときに、その変更を特に考慮するとよい。さまざまな他の例も考えられる。

結論
本発明は構造的特徴および／または方法論的動作に固有の言語で説明されているが、添付の特許請求の範囲で定義されている発明は、説明した特定の特徴または動作に必ずしも限定されないことは理解されるであろう。むしろ、特定の特徴および動作は請求されている発明を実施するための複数の実施形態の例として開示されている。

クライアントカテゴリ構成技術を使用するように動作可能な例示的な実装における環境を示す図である。 クライアントメンテナンスサービスおよび図１の複数のクライアントをより詳しく示す例示的な実装におけるシステムを示す図である。 クライアントのカテゴリを見つけ、複数のカテゴリのうちの特定の１つのカテゴリについて構成推奨を作成するために構成データが使用される例示的な一実装における手順を示す流れ図である。 まだ検出されていなかったクライアントおよびモジュールを含む構成データが処理される例示的な一実装における手順を示す流れ図である。 クライアントがまだ遭遇していないモジュールに関して自動判定が実行され、モジュールがクライアントのカテゴリに含まれているか否かに基づき推奨が提供される例示的な一実装における手順を示す流れ図である。

Claims (20)

1. コンピュータにより実装される方法であって、
   クライアントのカテゴリを、前記クライアント（３０６）から得られた構成データに基づいて見つけるステップと、
   前記カテゴリのうちの特定の１つのカテゴリについて、前記特定のカテゴリ（３１０）に含まれる前記クライアントのうちの１つまたは複数のクライアントの構成に基づき構成推奨を作成するステップと
   を含むことを特徴とするコンピュータにより実装される方法。
2. 前記カテゴリは、どのアプリケーション、ファイル、設定、およびプラグインモジュールが、前記カテゴリのそれぞれ内のクライアントに含まれるかということを含む基準により定義されることを特徴とする請求項１に記載のコンピュータにより実装される方法。
3. 前記カテゴリは、前記クライアントのそれぞれの趣味または職業に対応することを特徴とする請求項１に記載のコンピュータにより実装される方法。
4. 前記構成データは、前記クライアントのそれぞれで実行されるモジュールにより実行されるアクションおよび前記クライアントのそれぞれにより実行される前記アクションへの応答を記述することを特徴とする請求項１に記載のコンピュータにより実装される方法。
5. 前記構成データは、前記クライアントのそれぞれによりバックアップされたデータの特定の型を記述し、
   前記構成推奨は、前記特定の型のうちの少なくとも１つの型を識別することを特徴とする請求項１に記載のコンピュータにより実装される方法。
6. 前記特定の型は、ファイル拡張子を介して識別されることを特徴とする請求項５に記載のコンピュータにより実装される方法。
7. 前記構成データは、前記クライアントのそれぞれの上に含まれるモジュールに許可されたネットワークアクセスを記述し、
   前記構成推奨は、前記特定のカテゴリ内に含まれるクライアントに対し、モジュールに関して許可できる、または許可できないネットワークアクセスを識別することを特徴とする請求項１に記載のコンピュータにより実装される方法。
8. 前記構成推奨を、前記特定のカテゴリに含まれる前記クライアントのうちの少なくとも１つのクライアントに伝達するステップと、
   前記構成推奨が、前記クライアントに適用可能か否かを前記クライアントのうちの少なくとも１つのクライアントにより決定するステップと
   をさらに含むことを特徴とする請求項１に記載のコンピュータにより実装される方法。
9. 新規クライアントの分類を行うステップであって、前記新規クライアント上の１つまたは複数のモジュールの構成を複数のカテゴリのそれぞれにおいて記述される構成と比較することにより分類を行うステップをさらに含むことを特徴とする請求項１に記載のコンピュータにより実装される方法。
10. まだ検出されていないモジュールが前記クライアントから得られたその後の構成データにおいて検出された場合に、前記クライアントのうちのどのクライアントが前記モジュールを含むかを決定するステップと、
    前記まだ検出されていないモジュールを含む前記クライアントにどのカテゴリが対応するかを確認するステップと、
    前記まだ検出されていないモジュールを含むように前記確認されたカテゴリのうちの少なくとも１つのカテゴリを更新するステップと
    をさらに含むことを特徴とする請求項１に記載のコンピュータにより実装される方法。
11. コンピュータにより実装される方法であって、
    クライアントの分類を行うステップであって、前記クライアント上の１つまたは複数のモジュールの構成を複数のカテゴリ（３０６）のそれぞれにおいて記述されている構成と比較することにより分類を行うステップと、
    前記カテゴリ分類（３１２）に基づき少なくとも１つの前記モジュールの構成に関する推奨を前記クライアントに伝達するステップと
    を含むことを特徴とするコンピュータにより実装される方法。
12. 前記カテゴリは、どのアプリケーション、ファイル、設定、およびプラグインモジュールが、前記カテゴリのそれぞれの内のクライアントに含まれるかということを含む基準により定義されることを特徴とする請求項１１に記載のコンピュータにより実装される方法。
13. 前記カテゴリは、前記クライアントのそれぞれの趣味または職業に対応することを特徴とする請求項１１に記載のコンピュータにより実装される方法。
14. 前記カテゴリは、前記クライアントのそれぞれで実行されるモジュールにより実行されるアクションおよび前記クライアントのそれぞれにより実行される前記アクションへの応答に対応することを特徴とする請求項１１に記載のコンピュータにより実装される方法。
15. 前記カテゴリの識別を前記クライアントに伝達するステップと、
    前記カテゴリの前記識別に基づき、構成に関するその後の推奨が前記クライアントに関連しているか否かを、前記クライアントにより決定するステップと
    をさらに含むことを特徴とする請求項１１に記載のコンピュータにより実装される方法。
16. 前記複数のクライアントのうちどのクライアントがまだ検出されていないモジュールを含むかを決定するステップと、
    前記まだ検出されていないモジュールを含む前記クライアントにどのカテゴリが対応するかを確認するステップと、
    前記まだ検出されていないモジュールを含むように前記確認されたカテゴリのうちの少なくとも１つのカテゴリを更新するステップと
    をさらに含むことを特徴とする請求項１１に記載のコンピュータにより実装される方法。
17. コンピュータにより実装される方法であって、
    まだ検出されていないモジュールが複数のクライアントから得られた構成データにおいて検出された場合に、前記クライアントのうちのどのクライアントが前記モジュール（４１６）を含むかを決定するステップと、
    どのカテゴリが前記モジュールを含む前記複数のクライアントに対応するかを確認するステップであって、前記カテゴリのそれぞれは、１つまたは複数の他のモジュール（４１８）の構成を記述するものであるステップと、
    前記モジュール（４２０）を含むように前記確認されたカテゴリのうちの少なくとも１つのカテゴリを更新するステップと
    を含むことを特徴とするコンピュータにより実装される方法。
18. 前記カテゴリのそれぞれは、前記クライアントのうちの１つまたは複数のクライアントから得られた前の構成データに基づいて見つけられたことを特徴とする請求項１７に記載のコンピュータにより実装される方法。
19. 前記カテゴリは、どのアプリケーション、ファイル、設定、およびプラグインモジュールが、前記カテゴリのそれぞれの内のクライアントに含まれるかということを含む基準により定義されることを特徴とする請求項１７に記載のコンピュータにより実装される方法。
20. 前記更新されたカテゴリのうちの少なくとも１つのカテゴリを前記複数のクライアントに伝達するステップと、
    前記カテゴリに基づき構成推奨を作成するステップと、
    前記構成推奨を前記複数のクライアントに伝達し、前記更新されたカテゴリに基づき、前記構成推奨のそれぞれが前記クライアントに関連しているか否かを前記クライアントのそれぞれが判定するようにするステップと
    をさらに含むことを特徴とする請求項１７に記載のコンピュータにより実装される方法。

Images