(57)【要約】  メッセージ管理サービスにより、入ってくるメッセージに対するフィルタリングルールがユーザの振る舞いのパターンに基づいて動的に生成され得る。メッセージ管理サービスは、ユーザ行動とメッセージの特徴を関連付けたイベント記録を分析して、同一のユーザに属する複数のメッセージングアカウントにわたる相関を含む、メッセージの特徴と結果として生じた行動との間の相関を検出する。相関に基づいて、メッセージ管理サービスは推奨されるルールをユーザのクライアントデバイスに提供し得、ユーザはその推奨を受け入れたり拒否したりし得る。
2017514332.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータで実行される方法であって、
メッセージ管理サービスにおいて、複数のメッセージサービスプロバイダからユーザに対する複数のメッセージを受信することと、
前記メッセージ管理サービスにより、前記ユーザに対する複数のイベント記録であって、各イベント記録が前記複数のメッセージの異なる１つにおけるメッセージの特徴の組と前記メッセージに対して前記ユーザがとった行動を示すイベント情報とを含む、前記複数のイベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づく第１のトリガをかける条件と、前記第１のトリガをかける条件を満たすメッセージの少なくとも最小の断片に対してユーザがとる、結果として生じる第１の行動との間の相関を検出することと、
前記メッセージ管理サービスにより、前記分析に基づき、前記第１のトリガをかける条件を満たす将来のメッセージに対して前記結果として生じる第１の行動を自動的に実行するために、第１の推奨されるルールを生成することと、
前記メッセージ管理サービスにより、前記ユーザに関連付けられたクライアントデバイスから、前記第１の推奨されるルールが受け入れられることのユーザの確認を取得することと、
前記ユーザの確認に応答して、前記メッセージ管理サービスにより、前記第１の推奨されるルールを、前記ユーザのために受信されるメッセージに自動的に適用される成立したルールの組に追加することと、
を含む、コンピュータで実行される方法。
【請求項２】
前記ユーザの確認を取得することは、
前記第１の推奨されるルールを生成した後に、前記複数のメッセージングサービスの１つから、前記第１の推奨されるルールを適用する前記ユーザに対する候補のメッセージを受信することと、
前記候補のメッセージを、前記第１の推奨されるルールを記述する推奨メタデータと共に前記クライアントデバイスへ配信することと、
前記クライアントデバイスから前記ユーザの確認を受信することと、
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項３】
前記ユーザに対する新たなメッセージを、第１の前記複数のメッセージングサービスの１つから受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、前記新たなメッセージに対して、前記適用可能なルールによって定義された結果として生じる行動を自動的に実行することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項４】
前記結果として生じる行動を自動的に実行することは、前記第１の前記メッセージングサービスの１つへ更新命令を送信することを含む、請求項３に記載のコンピュータで実行される方法。
【請求項５】
前記結果として生じる行動は、前記新たなメッセージをフォルダ又はリストに移動すること、前記新たなメッセージを後回しにすること、又は、前記新たなメッセージを削除することを含む、請求項３に記載のコンピュータで実行される方法。
【請求項６】
前記結果として生じる行動は、前記新たなメッセージを送信先に転送することを含む、請求項３に記載のコンピュータで実行される方法。
【請求項７】
新たなメッセージを受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、
前記新たなメッセージに対して、クライアントデバイスが前記適用可能なルールによって定義される結果として生じる行動を実行することを示す、行動メタデータを追加することと、
前記行動メタデータを含む前記新たなメッセージを、前記クライアントデバイスへ配信することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項８】
前記結果として生じる行動は、前記新たなメッセージから転送されるメッセージを生成することと、前記転送されるメッセージを、送信されるべき前記ユーザに提示することと、を含む、請求項８に記載のコンピュータで実行される方法。
【請求項９】
第２のトリガをかける条件を満たす将来のメッセージに対して、第２の結果として生じる行動を自動的に実行するために、第２の推奨されるルールを生成することと、
前記第２の推奨されるルールを拒否するユーザ指示を取得することと、
前記ユーザ指示に応答して、前記第２の推奨されるルールを抑制することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項１０】
システムであって、
ユーザによって操作可能なクライアントデバイスと通信するように構成されたクライアントインタフェースと、
複数のメッセージングサービスから前記ユーザに対するメッセージを受信するように構成されたメッセージングサービスインタフェースと、
前記クライアントインタフェースと前記メッセージングサービスインタフェースとに接続された複数のメッセージ管理モジュールであって、前記複数のメッセージ管理モジュールは、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージに、成立したルールの組を適用するように構成されたフィルタモジュールと、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージと前記クライアントインタフェースを介して受信したイベント情報とに基づいて、イベント記録を生成するように構成されたイベントレコーダであって、各イベント記録がメッセージにおけるメッセージの特徴の組と前記メッセージに対する前記ユーザによってなされた行動を示すイベント情報とを含む、前記イベントレコーダと、
前記イベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づくトリガをかける条件と、前記トリガをかける条件を満たすメッセージの少なくとも最小の断片に対して前記ユーザがとる、結果として生じる行動と、の間の相関を検出し、前記相関に基づいて推奨されるルールを生成するように構成されたパターンディテクタと、を含み、
前記フィルタモジュールは、更に、前記推奨されるルールを、前記クライアントインタフェースを介して前記クライアントデバイスに通信し、前記クライアントインタフェースを介して前記クライアントデバイスから受信した応答に基づいて、前記推奨されるルールを前記成立したルールの組に追加するように構成される、システム。
【請求項１１】
各メッセージに対する前記メッセージの特徴の組は、前記メッセージを受信した前記メッセージングサービスの前記１つを特定するメッセージングサービス識別子を含む、請求項１０に記載のシステム。
【請求項１２】
前記トリガをかける条件は、前記メッセージングサービス識別子に少なくとも部分的に基づく、請求項１１に記載のシステム。
【請求項１３】
前記クライアントインタフェースを介して受信した前記イベント情報は、前記ユーザによってとられた前記行動に関連するクライアントのコンテクスト情報を更に含む、請求項１１に記載のシステム。
【請求項１４】
前記クライアントのコンテクスト情報は、クライアントデバイスの種別、前記行動がとられた時間、又は前記行動がとられた際の前記クライアントデバイスの位置の少なくとも１つを特定する情報を含む、請求項１３に記載のシステム。
【請求項１５】
前記トリガをかける条件は、前記メッセージの特徴と前記クライアントのコンテクスト情報の要素の１つに少なくとも部分的に基づいている、請求項１３に記載のシステム。
【請求項１６】
コンピュータで実行される方法であって、
クライアントデバイスにおいて、新たなメッセージと前記新たなメッセージに対する推奨メタデータとを、メッセージ管理サービスから受信することであって、前記推奨メタデータは、トリガをかける条件と、前記メッセージに適用される推奨されるルールに対する、結果として生じる行動とを含む、前記受信することと、
前記新たなメッセージを、前記クライアントデバイスのユーザインタフェースに提示することと、
前記新たなメッセージとのユーザの相互作用を示すユーザ入力を、前記ユーザインタフェースを介して受け取ることと、
前記ユーザインタフェースにおいて、前記推奨されるルールを受け入れるためのプロンプトを前記ユーザに提示することと、
を含む、コンピュータで実行される方法。
【請求項１７】
前記ユーザインタフェースを介して、前記プロンプトに対する応答を受け取ることと、
前記プロンプトに対する前記応答を含むイベント情報を、前記メッセージ管理サービスへ送信することと、
を更に含む、請求項１６に記載のコンピュータで実行される方法。
【請求項１８】
前記イベント情報は更に、前記示された行動の識別子を含む、請求項１７に記載のコンピュータで実行される方法。
【請求項１９】
前記新たなメッセージを提示することは、前記新たなメッセージの表現と、推奨されるルールが前記メッセージに適用されることの視覚的指標とを表示することを含む、請求項１６に記載のコンピュータで実行される方法。
【請求項２０】
前記視覚的指標は、前記推奨されるルールの前記トリガをかける条件を識別するための視覚的な要素を含む、請求項１９に記載のコンピュータで実行される方法。
【請求項２１】
前記視覚的指標は、前記推奨されるルールの前記結果として生じる行動を識別するための視覚的な要素を含む、請求項１９に記載のコンピュータで実行される方法。
【請求項２２】
前記ユーザ入力は、前記新たなメッセージに対してなされる行動を示し、前記プロンプトは、前記示された行動が前記推奨されるルールの前記結果として生じる行動と一致することが、前記クライアントデバイスによって判定された結果に応じて表示される、請求項１６に記載のコンピュータで実行される方法。
【請求項２３】
システムであって、
ユーザによって操作可能なクライアントデバイスと通信するクライアントインタフェース手段と、
複数のメッセージングサービスから前記ユーザに対するメッセージを受信するサービスインタフェース手段と、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージに、成立したルールの組を適用するフィルタ手段と、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージと前記クライアントインタフェースを介して受信したイベント情報とに基づいて、イベント記録を生成するイベント記録手段であって、各イベント記録がメッセージにおけるメッセージの特徴の組と前記メッセージに対する前記ユーザによってなされた行動を示すイベント情報とを含む、前記イベント記録手段と、
前記イベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づくトリガをかける条件と、前記トリガをかける条件を満たすメッセージの少なくとも最小の断片に対して前記ユーザがとる、結果として生じる行動と、の間の相関を検出し、前記相関に基づいて推奨されるルールを生成する分析手段と、を含み、
前記フィルタ手段は、前記推奨されるルールを、前記クライアントインタフェース手段を介して前記クライアントデバイスに通信し、前記クライアントインタフェース手段を介して前記クライアントデバイスから受信した応答に基づいて、前記推奨されるルールを前記成立したルールの組に追加する、システム。
【請求項２４】
各メッセージに対する前記メッセージの特徴の組は、前記メッセージを受け取った前記メッセージングサービスの前記１つを特定するメッセージングサービス識別子を含む、請求項２３に記載のシステム。
【請求項２５】
前記トリガをかける条件は、前記メッセージングサービス識別子に少なくとも部分的に基づく、請求項２４に記載のシステム。
【請求項２６】
前記クライアントインタフェース手段を介して受信した前記イベント情報は、前記ユーザによってとられた前記行動に関連するクライアントのコンテクスト情報を更に含む、請求項２４に記載のシステム。
【請求項２７】
前記クライアントのコンテクスト情報は、クライアントデバイスの種別、前記行動がとられた時間、又は前記行動がとられた際の前記クライアントデバイスの位置の少なくとも１つを特定する情報を含む、請求項２６に記載のシステム。
【請求項２８】
前記トリガをかける条件は、前記メッセージの特徴と前記クライアントのコンテクスト情報の要素の１つに少なくとも部分的に基づいている、請求項２６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、大まかに電子的なメッセージの管理に関し、特に、ユーザのアクションに基づく、メッセージ管理サービスにおける動的なフィルタ生成に関する。
【背景技術】
【０００２】
個々の人々は、電子メールサービス、インスタントメッセージングサービス、（テキストメッセージングとしても参照される）ＳＭＳ／ＭＭＳサービス等の電子的なメッセージングサービスにますます依存するようになっている。このようなサービスは、ユーザがメッセージを送信し、受信することを可能にする。ある例では、サービスは、メッセージをフォルダに格納したりアーカイブし、メッセージを削除し、格納されたメッセージを検索する等が可能になるような、メッセージングサービスに関する追加的な機能も提供し得る。
【０００３】
電子的なメッセージングサービスに頼る多くのユーザは、様々なネットワークに接続することができ、電子的なメッセージングサービスのクライアントとして動作する、ラップトップコンピュータ又はデスクトップコンピュータ、スマートフォン及びタブレット等のような様々な電子デバイスを使用する。例えば、クライアントは、メッセージングサービスからのメッセージを受信することができ、例えば、メッセージに返信し、メッセージを削除し、メッセージをアーカイブし、送信するメッセージを作成する等によって、ユーザがメッセージと相互作用することができるようにするユーザインタフェースを提供し得る。データネットワークに接続した場合に、クライアントデバイスは、メッセージングサービスからユーザへの更新をやりとりすることができ、ユーザの行動を実行するためにメッセージングサービスへの命令を通信することができる。モバイルデバイスの需要の増大に伴って、ユーザは、ほぼあらゆる時間にほぼあらゆる場所で、メッセージにアクセスすることができる。この利便性は、大量のメッセージが送信され、受信されることにつながり得る。
【０００４】
残念ながら、メッセージサービスの多くのユーザは、今や彼らが受信するこの大量のメッセージに困惑していることに気づいている。従って、ユーザがメッセージをより良く管理することができるようにする技術が望まれる。
【発明の概要】
【０００５】
本発明に係るある実施形態は、入ってくるメッセージを自動的にフィルタするために適用されるフィルタリングルールの動的な生成に関する。ルールは、ユーザの振る舞いのパターンに基づいて自動的に生成され得る。例えば、クライアントデバイスを用いて、ユーザは、メッセージを特定のフォルダ又はリストへ移動したり、メッセージを後の確認や（例えば特定の時間における）行動のために後回しにしたり、メッセージを読まずに削除等するような、受信したメッセージに対する行動を起こし得る。クライアントデバイスは、これらの行動を、クライアントデバイスと１つ以上のメッセージングサービスとの間の仲介人として動作する中間メッセージ管理サービスに、イベント情報としてレポートし得る。メッセージ管理サービスは、イベント情報と、行動のなされたメッセージのメッセージの特徴とを関連付けるイベント記録を生成し得る。メッセージの数に関するイベント記録を分析することによって、メッセージ管理サービスは、（１つ以上のメッセージの特徴に基づき得る）「トリガをかける（triggering）」条件と、結果として生じるユーザの行動との間の相関を検出し得る。ユーザがメッセージ管理サービスにリンクされた複数のメッセージングアカウントを有する場合、相関は、アカウントに跨って検出され得る。十分に強い相関が検出された場合、メッセージ管理サービスは、トリガをかける条件を満たす将来のメッセージに対して自動的に行動をとるために、推奨されるルールを生成し得る。メッセージ管理サービスは、ユーザのクライアントデバイスへ推奨されるルールを提供し得る。クライアントは、推奨されるルールをユーザに提示することができ、ユーザはその推奨を受け入れ又は拒否し得る。推奨が受け入れられる場合、メッセージ管理サービスは、推奨されるルールを、ユーザに向けられる将来のメッセージに自動的に適用するための処理ルールとして成立させ得る。
【０００６】
ある実施形態では、クライアントによって提供されたイベント情報は、ユーザの行動に関連するコンテクスト情報に含まれ得る。例は、クライアントデバイスの種別又は識別、ユーザが行動をとった時間におけるクライアントデバイスの位置、及び、ユーザが行動をとった時間を含む。コンテクスト情報は、イベント記録の分析に取り込まれることができ、トリガをかける条件を更に定義するために用いられ得る。
【０００７】
ある実施形態はルールを推奨する方法に関する。メッセージ管理サービスは、任意の数の異なるメッセージサービスプロバイダからのメッセージを含む、ユーザへのメッセージを受信し得る。メッセージ管理サービスは、イベント記録を構成して分析し得る。ここで、イベント記録のそれぞれは、メッセージの特徴の組と、メッセージに対してユーザがとった行動を示すイベント情報とを含む。イベント記録の分析を通して、メッセージ管理サービスは、（メッセージの特徴の１つに少なくとも部分的に基づく）トリガをかける条件と、第１のトリガをかける条件を満たすメッセージの最小の断片に対してユーザがとる、結果として生じる行動との間の相関を検出し得る。相関が検出された場合、メッセージ管理サービスは、トリガをかける条件を満たす将来のメッセージに対して結果的に生じる行動を自動的に実行するために、第１の推奨されるルールを生成し得る。メッセージ管理サービスは、推奨されるルールの確認をクライアントデバイスから取得し得る。例えば、推奨されるルールを生成した後に、推奨されるルールが適用され得るメッセージを受信した場合、メッセージ管理サービスは、当該メッセージを、推奨されるルールを記述した推奨メタデータと共にクライアントデバイスへ配信し得る。クライアントデバイスは、推奨されるルールをユーザに提示し、当該推奨されるルールを受け入れるかを示すユーザ入力を受け取り得、クライアントは、推奨されるルールが受け入れられる場合、ユーザ確認をメッセージ管理サービスへ送信し得る。ユーザ確認に応答して、メッセージ管理サービスは、推奨されるルールを、ユーザの受信したメッセージに自動的に適用される成立したルールの組に追加し得る。
【０００８】
ある実施形態はメッセージ管理サービス及びシステムに関する。メッセージ管理システムの一例は、ユーザによって操作可能なクライアントデバイスと通信するように構成されたクライアントインタフェース、２つ以上のメッセージングサービスからユーザのメッセージを受信するように構成されたメッセージングサービスインタフェースを含み得る。メッセージは、フィルタモジュール、イベントレコーダ、パターンディテクタを含む、様々なメッセージ管理モジュールによって処理され得る。例えば、フィルタモジュールは、メッセージングサービスインタフェースを介して、成立したルールの組をユーザの受信したメッセージに適用し得る。イベントレコーダは、メッセージングサービスインタフェースを介して受信したユーザのメッセージとクライアントインタフェースを介して受信したイベント情報とに基づいてイベント記録を生成し得る。各イベント記録は、メッセージにおけるメッセージの特徴の組と、メッセージに対してユーザがとる行動を示すイベント情報とを含み得る。パターンディテクタは、イベント記録を分析して、メッセージの特徴の１つに少なくとも部分的に基づくトリガをかける条件と、トリガをかける条件を満たすメッセージの最小の断片に対してユーザがとる、結果として生じる行動との間の相関を検出し得る。この相関に基づいて、パターンディテクタは、推奨されるルールを生成することができる。フィルタモジュールは、クライアントインタフェースを介して、推奨されるルールをクライアントデバイスと通信し得、クライアントインタフェースを介してクライアントデバイスから受信した応答に基づいて、推奨されるルールを成立したルールの組に追加し得る。
【０００９】
ある実施形態は、クライアントデバイスと、推奨されるルールをユーザに提示する方法に関する。例えば、クライアントデバイスは、新しいメッセージと新しいメッセージのための推奨メタデータとを、メッセージ管理サービスから受信し得る。推奨メタデータは、メッセージに適用されるべき推奨されるルールのための、トリガをかける条件と、結果として生じる行動とを含み得る。クライアントデバイスは、ユーザインタフェースに新しいメッセージを提示することができ、新しいメッセージへのユーザ相互作用を示すユーザ入力を受け取り得る。ユーザ入力に基づいて、クライアントデバイスは、推奨されるルールを受け入れるためのプロンプトをユーザに提示し得る。ユーザが応答した場合、クライアントデバイスは、プロンプトに対する応答を含むイベント情報を、メッセージ管理サービスへ送信し得る。
【００１０】
例えば、クライアントは、新しいメッセージの表示を、推奨されるルールがメッセージに適用される視覚的な指標と共に表示し得る。この視覚的な指標は、トリガをかける条件及び／又は結果として生じる行動についての情報を伝達し得る。ある実施形態では、視覚的な指標は、トリガをかける条件に関するメッセージの一部（例えば件名、送信者名、メッセージボディ内の特定の語）に適用された下線又はハイライトを含むことができ、結果として生じる行動（例えば、リスト又はフォルダへの移動、アーカイブ、削除、転送）を示すために色付きになり得る。
【００１１】
他の例として、クライアントデバイスは、（視覚的なインジケータと共に又は表示することなく）新しいメッセージの表示を表示し、とるべき行動を示すユーザ入力を受け取り得る。ユーザ入力が、推奨されるルールによって特定される、結果として生じる行動と一致する場合、クライアントデバイスは、推奨されるルールを受け入れるためにユーザにプロンプトを提示させ得る。
【００１２】
添付の図面と共に以下の詳細な説明は、本発明の本質及び利点に関するより良い理解を提供する。
【図面の簡単な説明】
【００１３】
【図１】図１は、本発明の実施形態に従う通信システムのブロック図を示す。
【図２】図２は、本発明の実施形態に従うメッセージ管理サービスのブロック図を示す。
【図３】図３は、本発明の実施形態に従う、フィルタリングルールの動的な生成の一側面を示す簡略化したメッセージの通過図を示す。
【図４Ａ】、
【図４Ｂ】、
【図４Ｃ】図４Ａ−図４Ｃは、本発明の実施形態に従う、クライアントデバイスのユーザインタフェース画面を示す。
【図５Ａ】、
【図５Ｂ】、
【図５Ｃ】図５Ａ−図５Ｃは、本発明の他の実施形態に従う、クライアントデバイスのユーザインタフェース画面を示す。
【図６】図６は、本発明の実施形態に従う、イベント記録を生成する処理のフローチャートを示す。
【図７】図７は、本発明の実施形態に従う、イベント記録に基づくユーザ行動のパターンを検出する処理のフローチャートを示す。
【図８】図８は、本発明の実施形態に従う、メッセージにフィルタリングルールを適用する処理８００のフローチャートを示す。
【図９】図９は、本発明の実施形態に従う、拒否データを更新する処理のフローチャートを示す。
【図１０】図１０は、本発明の実施形態に従う、推奨されるルールをユーザに提示する処理のフローチャートを示す。
【図１１】図１１は、本発明の実施形態に従う、推奨されるルールをユーザに提示する他の処理のフローチャートを示す。
【図１２】図１２は、本発明のある実施形態を実施するために用いることのできる代表的なサーバシステムとクライアントコンピュータシステムとの簡略化されたブロック図を示す。
【発明を実施するための形態】
【００１４】
本発明に係るある実施形態は、入ってくるメッセージを自動的にフィルタするために適用されるフィルタリングルールの動的な生成に関する。ルールは、ユーザの振る舞いのパターンに基づいて自動的に生成され得る。例えば、クライアントデバイスを用いて、ユーザは、メッセージを特定のフォルダ又はリストへ移動したり、メッセージを後の確認や（例えば特定の時間における）行動のために後回しにしたり、メッセージを読まずに削除等するような、受信したメッセージに対する行動をとり得る。クライアントデバイスは、これらの行動を、クライアントデバイスと１つ以上のメッセージングサービスとの間の仲介人として動作する中間メッセージ管理サービスに、イベント情報としてレポートし得る。メッセージ管理サービスは、イベント情報と、行動のなされたメッセージのメッセージの特徴とを関連づけるイベント記録を生成し得る。メッセージの数に関するイベント記録を分析することによって、メッセージ管理サービスは、（１つ以上のメッセージの特徴に基づき得る）「トリガをかける（triggering）」条件と、結果として生じるユーザの行動との間の相関を検出し得る。ユーザがメッセージ管理サービスにリンクされた複数のメッセージングアカウントを有する場合、相関は、アカウントに跨って検出され得る。十分に強い相関が検出された場合、メッセージ管理サービスは、トリガをかける条件を満たす将来のメッセージに対して自動的に行動をとるために、推奨されるルールを生成し得る。メッセージ管理サービスは、ユーザのクライアントデバイスへ推奨されるルールを提供し得る。クライアントは、推奨されるルールをユーザに提示することができ、ユーザはその推奨を受け入れ又は拒否し得る。推奨が受け入れられる場合、メッセージ管理サービスは、推奨されるルールを、ユーザに向けられる将来のメッセージに自動的に適用するための処理ルールとして成立させ得る。
【００１５】
図１は、本発明の実施形態に従う通信システム１００のブロック図を示す。通信システム１００は、ネットワーク１０６に接続する、メッセージングサービス１０２及びメッセージ管理サービス１０４を含み得る。ネットワーク１０６へ接続されるものはまた、破線矢印１１２、１１４によって示されるように、メッセージ管理サービス１０４を介してメッセージングサービス１０２にアクセスするために用いられる、様々なクライアント１０８、１１０であり得る。メッセージ管理サービス１０４及び／又はメッセージングサービス１０２へのアクセスは、例えばネットワーク１０６を介するなど間接的であり得る。
【００１６】
メッセージングサービス１０２は、ユーザがメッセージを送信、受信、格納及び／又はアクセスすることができるようにする、あらゆるサービスであり得る。ここで、「メッセージ」は、電子メールのメッセージ、インスタントメッセージ（例えば、様々な「チャット」サービスを用いたユーザ間で送信されるメッセージ）、ＳＭＳ／ＭＭＳメッセージ（様々な携帯電話及び他の無線データネットワークによってサポートされる、ショート・メッセージング・サービス及び／又はマルチメディア・メッセージング・サービスのプロトコルに従うメッセージ）、音声メッセージ、写真／画像メッセージ、ソーシャルネットワークメッセージ等のような、送信者によって生成され、1人以上の受信者に向けられた、あらゆる電子的コミュニケーションを含み得る。メッセージングサービス１０２の例は、Ｇメール（トレードマーク）（Ｇｏｏｇｌｅ社のサービス）及びＹａｈｏｏ！（登録商標）メール（Ｙａｈｏｏ！社のサービス）のような電子メールサービスを含み得る。他の例は、Ｇメールのチャット機能又はＦａｃｅｂｏｏｋ（登録商標）チャット機能（Ｆａｃｅｂｏｏｋ社のサービス）、携帯データキャリアによって提供されるＳＭＳ／ＭＭＳサービス、メッセージングコンポーネントを伴ったソーシャルネットワークサービス（例えば、Ｆａｃｅｂｏｏｋ社によって提供されるソーシャルネットワーク）等のような、インスタントメッセージング又はチャットサービスを含み得る。ある実施形態では、ユーザはメッセージングサービス１０２にアカウントを確立し得、メッセージングサービス１０２は、ユーザのメッセージ１２０を格納し、ユーザのメッセージ１２０へのアクセスを提供し得る。メッセージングサービス１０２はまた、ウェブベースのクライアントインタフェース、専用のアプリケーションプログラム、アプリケーションプログラムインタフェース（ＡＰＩ）、及び／又はメッセージ１２０へのユーザアクセスを容易にするためのツールを提供し得る。
【００１７】
メッセージ管理サービス１０４は、破線矢印１１６で示される、メッセージサービス１０２とクライアント１０８、１１０との間の、プロキシや仲介人として動作するサービスであり得る。メッセージ管理サービス１０４は、メッセージングサービス１０２によって格納されるメッセージ１２０に対する、構造化、格納、アクセス、作成、及び／応答のための拡張された機能を提供し得る。メッセージ管理サービス１０４のある例は、ドロップボックス社のメールボックスサービスであり得る。
【００１８】
クライアント１０８及び１１０は、メッセージ管理サービス１０４と相互作用するためのソフトウェアを実行することができるユーザ指向のコンピューティングデバイスであり得る。デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、ウェアラブルコンピューティングデバイス、パーソナルデジタルアシスタント等を含む、様々な種別のコンピューティングデバイスが使用され得る。例によれば、クライアント１０８は、ネットワーク１０６を介してメッセージ管理サービス１０４と通信するためにアプリケーションプログラム（アップとしても参照される）を実行することができるスマートフォンであり得る。アップは、メッセージ管理サービス１０４のプロバイダによって提供され得、メッセージ管理サービス１０４によってサポートされる拡張されたメッセージ管理機能へユーザがアクセスできるようにするためにカスタマイズされ得る。
【００１９】
クライアント１１０は、メッセージ管理サービス１０４と通信するためのアップを実行することができるデスクトップコンピュータであり得る。このアップは、例えば、デスクトップコンピュータのオペレーティングシステムに組み込まれたメールクライアントのアップ、ウェブベースのメッセージングサービスと連動するウェブブラウザ、メッセージ管理サービス１０４によって提供されるサービス固有のアプリケーション、又は他のアップであり得る。ある実施形態において、クライアント１０８と１１０とは、他のアップを実行して、メッセージ管理サービス１０４を用いることなく、メッセージングサービス１０２と通信し得ることを理解すべきである。
【００２０】
所与のユーザは、メッセージングサービス１０２とメッセージ管理サービス１０４の両方にアカウントを有し得る。メッセージ管理サービス１０４にあるユーザのアカウントは、メッセージングサービス１０２にあるユーザのアカウントとリンクされ得、ユーザはメッセージ管理サービス１０４を用いて、メッセージングサービス１０２を介したメッセージ１２０の送信及び受信を管理することができるようになる。ある実施形態では、ユーザは、１つ以上のメッセージングサービス１０２に複数のアカウントを持つことができ、これらのアカウントのいくつか又は全てをメッセージ管理サービス１０４にある１つのアカウントにリンクさせ得る。メッセージ管理サービス１０４は、ユーザのためのメッセージのサブセットをメッセージングサービス１０２から検索することができ、これらのメッセージをクライアント１０８及び／又はクライアント１１０へ配信し得る。
【００２１】
図１に示すように、（メッセージ１２０のサブセットを含むことができる）メッセージ１２２は、ユーザに新たに届くメッセージとしてクライアント１０８（又はクライアント１１０）へ配信され得る。ユーザはメッセージ１２２に対して行動するためにクライアント１０８と相互作用し得る。例えば、クライアント１０８は、送信者、日付、件名、メッセージの内容の一部のプレビュー等のような各メッセージについての情報を含む（ある場合にはインボックスとして参照される）新たなメッセージのリストを提示し得る。ユーザは、メッセージを選択して開き、クライアント１０８がメッセージの全ての内容をユーザに提示し得る。メッセージを読んだ後、ユーザは、メッセージをフォルダ又はリストに移動し、メッセージをアーカイブし、メッセージを削除し、メッセージを後の確認や行動のために後回しにしたり、メッセージに返信又は転送する等のような行動をとり得る。ある実施形態では、ユーザはまた、メッセージを最初に開くことなく、メッセージリストから直接的にメッセージに対する行動をとり得る。ユーザがメッセージに対する行動をとる場合、クライアント１０８は、特定のメッセージに対してとられた行動を示すイベント情報１２４をメッセージ管理サービス１０４へ送信し得る。メッセージ管理サービス１０４は、これに従ってその内部状態を更新し得、及び／又はメッセージングサービス１０２へ適切な更新を送信し得る。
【００２２】
本発明のある実施形態に従って、メッセージ管理サービス１０４は、メッセージにフィルタリングルール１２６を適用し得る。各フィルタリングルール１２６（ここでは単に「ルール」としても参照される）は、「トリガをかける」条件を満たすメッセージに対して自動的にとるべき行動を特定し得る。トリガをかける条件は、件名、送信者、メッセージの内容、いつメッセージが送信又は受信されたか（例えば日付、曜日）、メッセージのフォーマット（例えばプレインテキスト対ＨＴＭＬ）、メッセージの長さ、メッセージが添付を有するか等のような、任意のメッセージの特徴又はメッセージの特徴の組み合わせに基づき得る。行動は、メッセージを特定のフォルダ又はリストに移動し、メッセージを削除又はアーカイブし、メッセージを後の行動のために後回しにしたり、メッセージに返信したり、メッセージを転送する等のような、メッセージに関してユーザが行うかもしれない任意の行動を含み得る。ある例では、フィルタリングルール１２６を適用することは、特定のルールに応じて、結果としてメッセージがクライアント１０８へ後で配信される状態にしたり、クライアント１０８へ全く配信されないようにし得る。ルールの特定の例は以下に説明される。
【００２３】
ある実施形態では、フィルタリングルール１２６は、受信したメッセージに対してとられるユーザの行動のパターンに基づいて、メッセージ管理サービス１０４によって動的に生成されるルールを含み得る。例えば、メッセージ管理サービス１０４は、イベント記録のコレクションを格納し得、各イベント記録はメッセージの特徴についての情報（特定のメッセージの内容及び／又はメタデータ）とメッセージに対するユーザの行動とを含む。メッセージ管理サービス１０４は、振る舞いのパターンを検出するために、特定のユーザのために集められたイベント記録を分析し得る。例えば、ユーザは、特定の送信者からのメッセージ又は特定の受信者のグループへ送信するメッセージを夜又は週末まで一貫して後回しにしてもよい。又は、ユーザは、件名にある語を有するメッセージ又は特定の送信者からのメッセージを、最初に読むことなく一貫してアーカイブ又は削除してもよい。例えば、メッセージの特徴と特定のユーザの行動との間の相関として、パターンが検出され得る。ひとたびパターンが検出されると、メッセージ管理サービス１０４は、推奨されたフィルタリングルールを生成する。このフィルタリングルールは、例えば推奨されるルールが、このルールが適用され得るメッセージ１２２と共にクライアント１０８へ送信されることにより、ユーザに推奨され得る。クライアント１０８は、推奨されるルールをユーザに提示することができ、ユーザはその推奨を受け入れ又は拒否し得る。ユーザが推奨されるルールを受け入れる場合、メッセージ管理サービス１０４は、例えばこのルールをフィルタリングルール１２６の組に追加することによって、ルールを成立させ得る。フィルタリングルールの動的な生成及び推奨に係る特定の例は以下に説明される。
【００２４】
システム１００が具体例であると共に変形例及び修正が可能であることが理解される。本発明の実施形態は、異なるユーザに属し、そうでなければ異なるユーザに関連付けられるクライアントデバイスを含む、任意の数のクライアントデバイスをサポートし得る。更に、ある実施形態では、メッセージ管理サービスは、複数のメッセージングサービスと相互作用し得、全く異なる種別のメッセージ（例えば電子メールとソーシャルネットワークのメッセージ）を管理し得る。以下に説明するように、メッセージ管理サービスが複数のメッセージングサービスと相互作用する場合、メッセージ管理サービスは、どのメッセージングサービスが特定のメッセージの起点であるかにかかわらず、フィルタリングルールを動的に生成し、推奨し得る。
【００２５】
図２は、本発明の実施形態に従うメッセージ管理サービス２００のブロック図を示す。メッセージ管理サービス２００は、図１のメッセージ管理サービス１０４を実施し得る。例えば、メッセージ管理サービス２００は、（例えば図１のクライアント１０８又はクライアント１１０を実施する）クライアント２０２と、図１の（例えばメッセージングサービス１０２を実施する）様々なメッセージングサービス２０４ａ、２０４ｂとの間の仲介人として振る舞い得る。各サービス２０４ａ、２０４ｂは、異なる電子メールサービス、電子メールサービスとソーシャルネットワークサービス等のような異なるメッセージングサービスであり得る。２つのメッセージングサービス２０４が示される一方で、任意の数のメッセージングサービス２０４が１つのメッセージ管理サービス２００によってサポートされ得る。
【００２６】
メッセージ管理サービス２００は、クライアントインタフェース２１０、メッセージ管理モジュール２１２、メッセージングサービスインタフェース２１４、及びメッセージキャッシュ２１６を含み得る。クライアント伝達レイヤ２１８は、メッセージ及び他の命令を伝送するための伝送キューと、クライアントインタフェース２０２及びメッセージ管理モジュール２１２との間の情報を提供し得、サービス転送レイヤ２２０は、メッセージ及び他の命令を伝送するための伝送キューと、メッセージ管理モジュール２１２とメッセージングサービスインタフェース２１４との間の情報を提供し得る。
【００２７】
クライアントインタフェース２１０は、クライアント２０２の複数のインスタンス（例えば、異なるユーザに関連付けられたクライアント、及び／又は、同じユーザに関連付けられた複数のクライアント）と通信し得る。例えば、クライアントインタフェース２１０は、「インバウンド（ｉｎｂｏｕｎｄ）」のメッセージを、メッセージングサービスインタフェース２０４ａ、２０４ｂからクライアント２０２へ配信し得、「アウトバウンド（ｏｕｔｂｏｕｎｄ）」のメッセージをクライアント２０２から受信し得、及び／又は、メッセージを後回しにする、メッセージをリスト又はフォルダへ移動する、メッセージを既読（又は未読）としてマークする、メッセージを削除するための命令等のような、様々なメッセージ処理命令をクライアント２０２から受信し得る。このような命令は、以下に示すようにイベント情報又はユーザの行動を含み得る。
【００２８】
メッセージ管理モジュール２１２は、メッセージングサービス２０４ａ、２０４ｂから受信するインバウンドのメッセージだけでなく、クライアント２０２から受信するアウトバウンドのメッセージを含む、メッセージ管理サービス２００によって受信されるメッセージに対する様々な動作を処理するように構成された機能ブロック又は機能モジュールを含み得る。例えば、メッセージ管理モジュール２１２は、フィルタモジュール２３４、イベントレコーダ２３６、及びパターンディテクタ２３８を含み得る。
【００２９】
フィルタモジュール２３４は、（例えば、図１のフィルタリングルール１２６を実施する）フィルタリングルールを、クライアントに配信する前にインバウンドのメッセージに適用し得る。ある実施形態では、フィルタモジュール２３４は、それぞれが「トリガをかける」条件と結果として生じる行動とを特定する、成立したルール２４０のデータストアを保持し得る。トリガをかける条件は、例えば、インバウンドのメッセージの特徴又は特徴の組み合わせに基づいて、特定され得る。例は、メッセージの件名の特定の語の出現、メッセージが特定の送信者からのものであること、どのメッセージングサービス２０４ａ、２０４ｂがメッセージを受信したか、メッセージが受信者の特定の組に向けられたものであること、受信の時間（例えば、日付、時刻、曜日）が特定のタイムフレーム内にあること、メッセージサイズがある閾値を上回る又は下回ること、メッセージの内容が特定の語又は語の組み合わせを含むこと、等を含む。フィルタモジュール２３４によって検出可能な任意のメッセージの特徴は、個別に、又は他のメッセージの特徴との組み合わせのいずれかで、トリガをかける条件を定義するために用いられ得る。ルールによって特定される、結果として生じる行動は、受信したメッセージに関してユーザがとり得る任意の行動を含み得る。例は、リスト又はフォルダへのメッセージの移動すること、メッセージをアーカイブすること、メッセージを削除すること、後の行動のためにメッセージを後回しにすること、メッセージに返信すること、特定の送信先（例えば、他のユーザ）へメッセージを返信すること、等を含む。ある実施形態では、成立したフィルタリングルール２４０は、特定のユーザに対して、任意のメッセージングサービス２０４ａ、２０４ｂから受信した全ての新たなメッセージに対して適用される。異なるフィルタリングルール２４０の組は、異なるユーザに対して成立し得、カスタマイズされたユーザ体験を提供する。
【００３０】
イベントレコーダ２３６は、フィルタリングルール２４０の動的な生成を容易にするフォーマットで、メッセージに反応するユーザ行動についての情報を収集し得る。例えば、ユーザが受信したメッセージに行動を起こした場合、クライアント２０２はその行動をクライアントインタフェース２１０にレポートし得る。イベントレコーダ２３６は、レポートされた行動に基づいてイベント記録を生成し得る。以下で使用されるように、イベント記録は、メッセージの特徴（又は特性）及びユーザの行動についての情報を含む、あらゆる種別の、構造化されたデータの記録であり得る。ある実施形態では、ユーザの行動についての情報は、なされた行動（例えば、移動、アーカイブ、後回し、返信など）、行動がなされる前にユーザがメッセージを読んだか、及び、クライアント２０２の識別（例えば、モバイル電話、デスクトップコンピュータ）、ユーザが行動を起こした際のクライアント２０２の位置、行動がなされたときの時間等のような、行動に関連するクライアントのコンテクスト情報を含み得る。ある実施形態では、イベントレコーダ２３６は、イベント記録データストア２４２にイベント記録を格納し得る。イベント記録データストア２４２は、あらゆる数のメッセージと対応するユーザの行動とに対する記録を含み得、例えば、格納されるイベント記録の数の上限、及び／又は格納されたイベント記録の寿命に基づく、定期的なパージの影響化にあり得る。
【００３１】
パターンディテクタ２３８は、メッセージの特徴の特定の組と結果として生じるユーザの行動との間の相関のようなパターンを検出するために、イベント記録データストア２４２内の記録を分析し得る。あらゆる種別のパターン検出ロジックが実施され得る。ある例では、パターンディテクタ２３８は、同一のユーザ行動となる特定の条件をメッセージが満たす連続する回数を単にカウントし得る。例えば、ユーザが、特定の送信者の行の５つのメッセージを読まずに削除した場合、このことは、ユーザが当該送信者からのメッセージを受信することに興味がないことを示すかもしれない。パターンディテクタ２３８は、この振る舞いの検出し、当該送信者からのメッセージを自動的に削除するルールを推奨し得る。（ルールの推奨は以下に説明される。）他の例としては、ユーザが特定の件名を有する３つのメッセージを金曜日まで後回しにした場合、このことは、ユーザがそのような全てのメッセージの後回しを望んでいることを示すかもしれない。パターンディテクタ２３８は、この振る舞いの検出し、当該件名を有するメッセージを自動的に後回しにするルールを推奨し得る。
【００３２】
ある実施形態では、パターンディテクタ２３８はまた、同一のユーザ行動に一貫したトリガをかける、より複雑な又は微妙なパターンを検出し得る。例えば、パターンは、件名と送信者、送信者と受信者のリスト、送信者と時刻又は曜日、送信者とメッセージの内容、メッセージの内容と時刻又は曜日、の組み合わせに基づいてよい。ある実施形態では、パターンディテクタ２３８は、いくつかのメッセージの特徴の組と結果として生じるユーザの行動との間の相関を検出することができる機械学習アルゴリズム（例えば、人口ニューラルネットワークなど）を実施し得る。更なるパターン検出の例は以下に説明される。
【００３３】
ある実施形態では、クライアントの（例えば上述したような）コンテクスト情報は、パターン検出分析におけるメッセージの特徴と組み合わせられ得る。従って、例えば、ユーザが、特定の送信者（又は送信者のグループ）からのメッセージを家やデスクトップコンピュータに戻るまで後回しにするというパターンを有することを検出することが可能であり得る。
【００３４】
パターンディテクタ２３８がパターンを検出した場合、推奨されるルールを生成し、その推奨されるルールをフィルタモジュール２３４に提供し得る。ある実施形態では、フィルタモジュール２３４は、パターンディテクタ２３８から受け取った推奨されたルールを自動的に実行しない。代わりに、フィルタモジュール２３４は、まずユーザの確認を取得し得る。例えば、推奨されたルールを受信することによってパターンディテクタ２３６を形成する場合、フィルタモジュール２３４は、当該推奨されるルールを、成立したルール２４０と別々に格納し得る。推奨されるルールが適用されるであろう、インバウンドのメッセージが受信された場合、フィルタモジュール２３４は、推奨されるルールを定義する推奨メタデータをインバウンドのメッセージに追加し、クライアント２０２へ配信するためのクライアントインタフェース２１０に送信する。クライアント２０２は、メタデータを抜き出して推奨されるルールをユーザに提示し、ユーザからの応答を取得して当該応答をメッセージ管理サービス２００へレポートする。ユーザが推奨されるルールを受け入れる場合、フィルタモジュール２３４は、当該推奨されるルールを成立したルール２４０に追加し得る。例を以下に説明する。
【００３５】
メッセージングサービスインタフェース２１４は、様々なサービスモジュール２２６ａ、２２６ｂを含み得、それぞれが、異なる１つのメッセージングサービス２０４ａ、２０４ｂと通信するように構成され得る。例えば、異なるメッセージングサービス２０４は、外部のクライアントによるアクセスのための異なる通信プロトコル（例えば、ＩＭＡＰ、ＰＯＰ、ＭＡＰＩ／Ｅｘｃｈａｎｇｅ、カスタムＡＰＩ等）をサポートしてよく、各サービスモジュール２２６は、特定のメッセージングサービス２０４のために適切なプロトコルを使用するように構成され得る。
【００３６】
ある実施形態では、メッセージングサービスインタフェース２１４は、メッセージ管理サービス２００がメッセージングサービス２０４ａ、２０４ｂに対して透過的になるように、自身をメッセージングサービス２０４ａ、２０４ｂのアクセス機能としてメッセージングサービス２０４ａ、２０４ｂにみえるようにし得る。例えば、メッセージングサービス２０４ａがＩＭＡＰをサポートする場合、サービスモジュール２２６ａは、ユーザのアカウントへの永続的なＩＭＡＰ接続を、メッセージングサービス２０４ａと確立し得、これにより、メッセージングサービス２０４ａが、ユーザのアカウントに対して受信する、任意に入ってくるメッセージ又はメッセージの更新をメッセージ管理サービス２００に配信できるようにし得る。同様に、メッセージ管理サービス２００は、クライアントデバイス２００から受信する任意のアウトバウンドのメッセージ又はメッセージの更新を、メッセージングサービス２０４ａへ配信し得る。ＩＭＡＰ以外のサービスへの永続的な接続もまた維持され得、或いは、メッセージングサービスインタフェース２１４が、様々なメッセージングサービス２０４を定期的にポーリングして新たなメッセージを取得し得る。永続的な接続は、所与のユーザが現在、クライアントインタフェース２１０と接続された任意のクライアント２０２を有するかに関わらず維持され得、メッセージ管理サービス２００はメッセージングサービス２０４との同期を維持し得る。特定のクライアント２０２は、メッセージ管理サービス２００をいつでも切断し得、メッセージ管理サービス２００と再接続したときはいつでも、メッセージ管理サービス２００と再同期し得る。
【００３７】
メッセージキャッシュ２１６は、ストレージ及びメッセージの検索を提供するメッセージ管理サービス２００によって管理されるデータベース又は他のデータストアであり得る。例えば、メッセージは、メッセージ管理サービス２００及び／又はメッセージングサービス２０４により、各メッセージに割り当てられた内部メッセージ識別子への参照を用いて格納されるとともに検索され得る。メッセージ管理サービス２００は、メッセージキャッシュ２１６を用いて、最近受信したメッセージ又はユーザ主導の検索において見つかったメッセージのような、クライアントにとって興味のありそうなメッセージのコピーを格納し得る。
【００３８】
メッセージングサービス２０４は、メッセージ管理サービス２００により、自身のメッセージストア又はリポジトリを任意の行動から独立して維持し得る。ある実施形態では、メッセージングサービス２０４は、（例えば、送信済みメッセージ、受信メッセージ、アーカイブしたメッセージ等の）ユーザのアカウントに現在関連付けられている全てのメッセージを含む、ユーザに対するメッセージのプライマリ（又はマスタ）ストアを維持し得、メッセージキャッシュ２１６は、ユーザのメッセージのサブセット（メッセージの「窓（ｗｉｎｄｏｗ）」としても参照される）だけでなく、メッセージキャッシュ２１６に現在複製されていない、プライマリストア内の追加的なメッセージについての部分的な情報を格納し得る。クライアント２０２がメッセージキャッシュ２１６に現在格納されていないメッセージをリクエストした場合、メッセージ管理サービス２００は、適切なメッセージングサービス２０４からメッセージを検索し、クライアント２０２へ検索したメッセージを配信し得る。
【００３９】
動作において、メッセージ管理サービス２００は、メッセージングサービス２０４からインバウンドのメッセージを取得し、クライアント２０２へ当該メッセージを提供し得る。メッセージ管理サービス２００はまた、クライアント２０２から（例えば送信されるべきメッセージ）アウトバウンドのメッセージを受信し、当該メッセージを、（複数の）受信者への配信のためにメッセージングサービス２０４へ提供する。メッセージ管理サービス２００はまた、（以下で説明するアクションのリクエストとイベント情報とを含む）メッセージの更新リクエストを、クライアント２０２から受信し得、例えば、メッセージを既読又は未読としてマークするため、メッセージをフォルダに移動するため、メッセージタグを適用したり消去するため、メッセージを削除するため等の、対応する命令をメッセージングサービス２０４へ提供し得る。メッセージ管理モジュール２１２は、インバウンド及び／又はアウトバウンドのメッセージに対する様々な動作を実行し得、これらの例は以下で説明される。
【００４０】
メッセージ管理システム２００が具体例であると共に変形例及び修正が可能であることが理解される。例えば、後のレビュー及び／又は応答のために後回しにする、メッセージにタグ付けする、メッセージを検索する等のための能力のような、他のメッセージ管理モジュール及び／又は動作が提供され得る。ある実施形態では、メッセージ管理は、ウインドウニング（５０又は１００、又は、最も最近のメッセージの他のある数のような、関連があり得ると見なされた特定の数のメッセージを選択し、中間的に配信する）、埋め戻し（クライアントリクエストの予想におけるメッセージでメッセージキャッシュ２１６を埋めること）、メッセージのフォーマット変換（例えば、メッセージングサービスによって使用されるメッセージ形式とクライアント上のディスプレイに最適化された形式との間で変換する）、メッセージフォルダ又はストリーム管理、メッセージのソート、添付の管理、メッセージングサービス２０４との同期（メッセージを移動又は変更するための、例えば、クライアント２０２から命令をリレーする）等を含み得る。
【００４１】
本発明のある実施形態に従って、メッセージ管理サービス２００は、メッセージのユーザ処理を容易にするためにフィルタリングルールを自動的に生成し得る。図３は、本発明の実施形態に従う、フィルタリングルールの動的な生成の一側面を示す簡略化したメッセージの通過図を示す。この例では、メッセージングサービス２０４ａは、電子メールサービスであり得る。例えば、メッセージ管理サービス２００は、フィルタモジュール２３４とパターンディテクタ２３８とを含み得る。図示されていないが、メッセージ管理サービス２００は、メッセージに関連する他の動作を実行するために他のモジュールを含み得ることが理解されるべきである。
【００４２】
イベント３０２において、メッセージＭがメッセージ管理サービス２００により受信され得る。メッセージＭは、クライアント２０２のユーザのためにメッセージングサービス２０４ａによって受信される任意のメッセージであり得る。上述したように、メッセージ管理サービス２００は、永続的なＩＭＡＰ接続等を介してメッセージＭを取得し得る。メッセージＭはフィルタモジュール２３４へ配信され得る。フィルタモジュール２３４は、イベント３０４において、成立したルールをメッセージＭに適用し得る。この例では、成立したルールが、結果としてクライアント２０２へメッセージＭを配信しないようにならないことを想定しており、従って、メッセージＭは、イベント３０６において、クライアント２０２へ配信され得る。ある実施形態では、クライアント２０２へ配信されたメッセージＭのバージョンは、メッセージ管理サービス２００によって変更され、例えばクライアント２０２における提示のためにメッセージを再フォーマット又は最適化し得る。
【００４３】
クライアント２０２は、ユーザに受信したメッセージＭを提示し、メッセージＭに対するユーザの行動（イベント３０８）を検出し得る。クライアント２０２は、行動３０８を示すイベント情報をメッセージ管理サービス２００へ送信する（イベント３１０）。特に、イベント情報はパターンディテクタ２３８へ提供され得る。例えば、上述したように、イベントレコーダ２３６（図３において不図示）は、イベント情報を受信して、パターンディテクタ２３８に提供するイベント記録を生成し得る。パターンディテクタ２３８は、他のイベントについての情報と組み合わせ、受信したイベント情報を入力として用いて分析を実行（イベント３１２）し得る。パターンディテクタ２３８がパターンを検出した場合、推奨されるルール３１４がフィルタモジュール２３４に提供され得る。上述したように、推奨されるルール３１４はトリガをかける条件を特定し得、トリガをかける条件が満たされた場合に行動がとられる。
【００４４】
しばらくして、イベント３２０において、他のメッセージ（Ｎ）がメッセージングサービス２０４ａから受信され得る。フィルタモジュール２３４は、推奨されたルールを含むフィルタリングルール３２４を、当該メッセージに適用し得る。この例では、メッセージＮは、推奨されたルール３１４におけるトリガをかける条件を満たすものであると想定する。従って、フィルタモジュール２３４は、メッセージＮを、推奨されるルール３１４を示す推奨メタデータと共にクライアント２０２へ配信し得る。例えば、推奨されるルールがメッセージＮに適用されることを示し、更に推奨されるルールによって定義される、特定のトリガをかける条件と行動とを示すメタデータがメッセージＮに追加され得る。
【００４５】
クライアント２０２は、ユーザにメッセージＮを提示し得ると共に、更にユーザに推奨されるルールを提示し得る。ユーザに推奨されるルールを提示する例を以下に示す。受け入れ３２８によって示されるように、ユーザが推奨を受け入れることを想定すると、クライアント２０２は、受け入れの表示を含むイベント情報３３０を、メッセージ管理サービス２００に送信し得る。例えば、パターンディテクタ２３８は受け入れ３３０を受信して、推奨されるルールを成立させるようにフィルタモジュール２３４に指示する（指示３３２）。或いは、フィルタモジュール２３４は、パターンディテクタ２３８からの指示無しに、受け入れ３３０を受信して推奨されるルールを追加し得る。
【００４６】
その後、イベント３４０において、メッセージＰが受信され得、そしてフィルタモジュール２３４が、指示３３２によって追加されたルールを今まさに含んでいるルール３４２を適用し得る。ルールを適用することは、トリガをかける条件が満たされた場合に、ルールによって示される行動をとることを含み得る。特定のルールに依存するが、この行動は、メッセージＰを削除すること、メッセージＰをフォルダ又はリストに移動すること、クライアント２０２への後の配信のためにメッセージＰを後回しにすること等を含み得る。この例では、ブロックされた配信３４４として示すように、行動をとることによって、結果としてメッセージＰはクライアント２０２へ配信されない。他の例では、メッセージＰは、ルールが適用された後であっても配信され得る。例は以下に説明する。
【００４７】
図３は具体例であると共に変形例及び修正が可能であることが理解される。例えば、メッセージに対するユーザの行動又はフィルタリングルールの適用は、結果として、例えばフォルダへメッセージを移動させ、メッセージを消去する等の、メッセージングサービス２０４ａへの更新命令の通信を生じさせ得る。他のメッセージが受信され得、全てのメッセージが所与のルールのトリガがかける条件を満たすものではないことが想定される。更に、図３は全てのメッセージが同一のメッセージングサービスから受信されることを示す一方で、異なるメッセージが同一のユーザのために異なるメッセージングサービスから受信され得、そのメッセージの送信元がどのメッセージサービスであるかに関わらずメッセージの分析が実行されることが理解されるべきである。
【００４８】
図３への参照と共に示す振る舞いは、メッセージフィルタリングルールを、ユーザの行動に基づいて動的に生成することを可能にする。例えば、イベント３０２−３１０のシーケンスは、パターンが検出され得るイベント記録の組を構築するために、異なるメッセージに対して複数回繰り返され得る。ユーザがクライアント２０２を介してメッセージ管理サービス２００と相互作用を続けるため、同一又は異なるルールの推奨は繰り返され得る。
【００４９】
パターンディテクタ２３８の動作の結果として、フィルタリングルールは、そのようにするための明確なユーザの命令なしに生成され得る。そうは言っても、（例えば図３のイベント３２６−３３０に示すような）新たなルールを成立させる前に、ユーザ設定を取得することは有益であり得る。自動フィルタ生成のユーザ体験は、本発明の実施形態に従う、クライアントデバイスのユーザインタフェース画面を示す図４Ａ−図４Ｃを参照して、より理解され得る。
【００５０】
図４Ａは、本発明の実施形態に従うクライアントデバイス（例えばクライアント２０２）に提示され得るユーザインタフェース画面４００を示す。ユーザインタフェース画面４００は、ユーザのインボックスに対応するメッセージリスト４０２を含み得る。コントロールセクション４０４が提供され、ユーザは、例えば以前に生成されたメッセージのリストを見たり、メッセージを検索する等のような、他の行動をとることができるようになり得る。メッセージリスト４０２はメッセージ４１２、４１４、４１６を含み得る。（この例では、メッセージのスレッド内でメッセージ４１６が最も新しいメッセージであり、バッジ４１８によって示されるように、メッセージ４１６はユーザがスレッド内の他のメッセージにアクセスすることができるようにしている。この例では、ユーザインタフェース画面４００は、ユーザが、メッセージ管理サービス２００とリンクした全てのメッセージングアカウントからのメッセージを含む単一のリスト４０２を見ることができる、統一したインタフェースを提供し得る。ある実施形態では、クライアントデバイスは、ユーザが全てのメッセージングサービスアカウント又は全アカウントより少ないアカウント（例えば同時に１アカウント）のメッセージを見るかどうかを選択可能にし得る。
【００５１】
ユーザインタフェース画面４００は、タッチスクリーンデバイス上に提示され得、ユーザは、タップ又はドラッグのようなタッチジェスチャを用いて、メッセージリスト４０２と相互作用することができる。例えば、図４Ｂに示すように、ユーザはメッセージ４１２をある程度左へドラッグし得、ジェスチャインジケータ４２０は、ドラッグを示す接触ポイントが左に移動することを示す。ある実施形態では、ジェスチャ４２０は、メッセージ４１２が後の行動のために後回しされるべきであることを示すものとして解釈され得、例えば図示される遅延アイコン４２２を提示することにより、この解釈がユーザに伝達され得る。ジェスチャ４２０の実行は、メッセージをどれだけ後回しにするか（例えば、夜まで、翌朝まで、２４時間、１週間、など）についての選択肢のメニュー（不図示）を提示するユーザインタフェース画面４００を結果として生じさせ得る。メッセージをリストに移動する、メッセージをアーカイブ又は削除する等のような、他の行動を示すための他のジェスチャが定義され得る。特定のユーザの行動に関わらず、クライアント２０２はメッセージ管理サービス２００へ（例えば図３のイベント情報３１０として）当該行動をレポートし得る。
【００５２】
ある実施形態では、単一のユーザジェスチャは、行動が複数のメッセージに対して実行されるべきであることを示し得る。例えば、メッセージ４１６は３つのメッセージを含むスレッドを表しており、メッセージ４１６に対する遅延ジェスチャ４２０を実行することが、スレッド内のこれまで受信した全てのメッセージを結果として後回しにし得る。メッセージ管理サービス２００によるパターン検出の目的として、スレッド内の複数のメッセージに対して実行される行動は、複数のイベント記録を生成する、行動の複数のインスタンスとして扱われ得る。これは、ユーザが個々のメッセージよりむしろスレッドに対して行動を起こした場合に、パターンディテクタ２３８が即座にパターンを検出することを可能にし得る。
【００５３】
図４Ａ及び図４Ｂのユーザインタフェースはまた、推奨されるルールをいつユーザに提示するかを決定するために用いられ得る。図示の目的のため、ユーザがメッセージ４１２と同じ送信者からの複数のメッセージを以前に受信し、各メッセージに対して、ユーザは図４Ｂに示すものと同一の遅延行動を実行したものとする。上述したように、パターンディテクタ２３８はこのパターンを検出してルールを推奨する。次に同一の送信者からメッセージが来た場合、メッセージ管理サービス２００は、ユーザに提示するために、例えばメッセージに推奨メタデータを含めることによって、推奨されるルールをクライアント２０２へ提供し得る。クライアント２０２は、提示のための推奨されるルールを受信した場合、クライアント２０２は（例えば図４Ａに示したように）通常通りにメッセージを表示し、ユーザは、図４Ｂに示したような遅延行動を実行し得る。この場合、クライアント２０２は、推奨メタデータに基づき、ユーザの行動が推奨されたルールに対する行動と結果として一致することを認識し得る。これにより、クライアント２０２は、ルールを成立させることをユーザに促すことになり得る。
【００５４】
図４Ｃは、本発明の実施形態に従う、クライアント２００によって表示され得る推奨されるルールに対するプロンプト４４０の例を示す。この例では、プロンプト４４０は、（トリガをかける条件と結果として生じる行動とを含む）推奨されるルールを示す記述４４２を含み、仮想的なボタンの形式でオプションを提供する。「はい」ボタン４４４は、結果として、推奨されるルールが成立し、そのため推奨されたルールが、トリガをかける条件を満たす将来入ってくるメッセージに自動的に適用されるようにし得る。「いいえ」ボタン４４６は、結果として、推奨されるルールが成立しないようにし得る。後述するように、「いいえ」ボタン４４６は、結果として、推奨されるルールが再び成立しないようにもし得る。「後できく」ボタン４４８はまた、結果として、推奨されるルールが成立しないようにし、しかしこの場合には、推奨されるルールが受信されて実行されるようにトリガをかけるメッセージが次回に再び促されるようにし得る。「閉じる」ボタン４５０は、結果として、推奨されるルールが成立しないようにし得、ある実施形態では、ユーザが「閉じる」ボタン４５０を繰り返し選択すると、推奨されるルールの提示は一時的に停止され得る。他のプロンプトと応答のオプションが提供され得、ある実施形態では、ユーザは、特定のボタンをタッチするよりもジェスチャを実行することによって応答を入力し得る。
【００５５】
図５Ａ−５Ｃは、本発明の他の実施形態に従うクライアントデバイスのためのユーザインタフェース画面を示す…図５Ａは、本発明の実施形態に従うクライアントデバイス（例えばクライアント２０２）に提示され得るユーザインタフェース画面５００を示す。ユーザインタフェース画面５００は、ユーザのインボックスに対応するメッセージリスト５０２を含み得る。コントロールセクション５０４が提供され、ユーザは、例えば以前に生成されたメッセージのリストを見たり、メッセージを検索する等のような、他の行動をとることができるようになり得る。メッセージリスト５０２はメッセージ５１２、５１４、５１６を含み得る。（図４Ａと同様に、メッセージ５１６のようないくつかのメッセージはメッセージに関するスレッドを意味し得る。）この例では、ユーザインタフェース画面５００は、ユーザが、メッセージ管理サービス２００とリンクした全てのメッセージングアカウントからのメッセージを含む単一のリスト５０２を見ることができる、統一したインタフェースを提供し得る。ある実施形態では、クライアントデバイスは、ユーザが全てのメッセージングサービスアカウント又は全アカウントより少ないアカウント（例えば同時に１アカウント）のメッセージを見るかどうかを選択可能にし得る。
【００５６】
図５Ａでは、フィルタリングルールを成立させるオプションは、メッセージリスト５０２内の視覚的な兆候を含むことによって示され得る。例えば、メッセージ５１４内の点線下線５２０は、推奨されるルールがメッセージ５１４と共に受信されたことを示し得る。推奨されるルールにおけるトリガをかける条件は、点線下線５２０の位置によって示され得る。この例では、点線下線５２０は、件名５２２に下線を引いており、トリガをかける条件がメッセージの件名に対応することを示している。送信者に対応するトリガをかける条件は、例えば送信者の名前等に下線を引くことによって示され得る。ある実施形態では、推奨されるルールにおいて結果として生じる行動の性質は、線のスタイル及び／又は線の色によって示され得る。例えば、黄色の線は、結果として遅延を生じさせることを示し、緑の線はアーカイブすることを示し、赤の線は削除することを示す等である。
【００５７】
ユーザは、メッセージ５１４上またはより具体的には件名５２２上をタップして、ルールについてのより多くのものを調べることができる。図５Ｂは、本発明の実施形態に従って、メッセージ５１４をユーザがタップした後のユーザインタフェース画面５００を示す。件名５２２（又は、トリガをかける条件に対応するメッセージ５１４の任意の他の部分）はハイライトされた状態になって、トリガをかける条件にユーザの注意を引き付け得る。ある実施形態では、ハイライトされた色は結果として生じる行動に対応し得る。加えて、プロンプト５３０が提示されて、推奨されるルールが受け入れられるべきかを確認するようにユーザを促し得る。図示されるように、プロンプト５３０はテキスト及び／又はアイコンを含んで、結果として生じる行動を示し得る。この例では、結果として生じる行動はメッセージ５１４をアーカイブするものである。他の例では、プロンプト５３０は更なる情報を示しうる。例えば、結果として生じる行動がメッセージを後回しにするものである場合、プロンプト５３０は、遅延期間を示し得、結果として生じる行動がメッセージをフォルダ又はリストに移動するものである場合、プロンプト５３０は、特定のフォルダ又はリストを特定し得る。
【００５８】
ある実施形態では、ユーザは、プロンプト５３０をタップすることにより、推奨されたルールを受け入れることができ、画面５００の他の場所をタップすることにより、推奨されたルールを拒否し得る。他の応答もまた、ジェスチャーにより伝達され得る。例えば、ある実施形態では、プロンプト５３０にわたる右側へのスワイプジェスチャは、ルールを拒否すること（上述した図４Ｃの「いいえ」ボタン４４６と同様）に対応し得え、プロンプト５３０にわたる左側へのスワイプジェスチャは、決定を後回しする（図４Ｃの「後で」ボタン４４８と同様）ことに対応し得る。
【００５９】
図５Ｃは、本発明の実施形態に従う、例えばタッピングプロンプト５３０によって、ユーザが推奨されるルールを受け入れた後のユーザインタフェース画面５００を示す。この例では、クライアントは、ユーザがあたかも手動でその行動をとるためのジェスチャを実行したかのように、行動をとっているアニメーションを行う。この例では、ルールはメッセージを自動的にアーカイブし、メッセージ５１４は右へスライドオフして表示され、アイコン５３２が空間に提示される。この例では、ユーザはスワイプジェスチャを実行する必要がなく、代わりにアニメーションがなされている行動の視覚的な確認を提供する。
【００６０】
図４Ａ−４Ｃ及び図５Ａ−５Ｃのユーザインタフェース画面が具体例であると共に変形例及び修正が可能であることが理解される。ユーザの入力コントロール、レイアウト、アイコン等は、クライアントデバイス、サポートされる機能の組、及び／又はクライアントソフトウェアの美学的思想に応じて、変更され得る。
【００６１】
フィルタリングルールの動的な生成を実施するために用いられ得る特定の処理及びアルゴリズムの例をこれから説明する。
【００６２】
上述したように、フィルタリングルールの生成は、イベント記録の分析に基づいてなされ得る。図６は、本発明の実施形態に従う、イベント記録を生成する処理６００のフローチャートを示す。処理６００は、例えば、図２のメッセージ管理サービス２００のイベントレコーダ２３８内に実装され得る。処理６００は、メッセージ管理サービス２００によって受信される、それぞれの新たなインバウンドのメッセージに対して実行され得る。
【００６３】
ブロック６０２で、インバウンドのメッセージが受信される。ある実施形態では、インバウンドのメッセージは、以前にはクライアント２０２へ配信されておらず、ユーザが以前には読んだり（例えば異なるクライアントを用いて）行動をとっていない、新たなメッセージであり得る。ブロック６０４において、メッセージの特徴の組がインバウンドのメッセージに対して決定され得る。メッセージの特徴は、後にパターンディテクタ２３８へ提供される、メッセージのあらゆる性質、属性、又はメタデータを含み得る。例は、メッセージの件名、送信者の名称又はアドレス、メッセージが受信されたメッセージングサービスの識別子、メッセージの受信者のリスト、メッセージの送信時間、（メッセージングサービス２０４又はメッセージ管理サービス２００における）メッセージの受信時間、メッセージのサイズ、メッセージの内容のいくつか又は全ての提示、メッセージのフォーマット（例えばプレインテキスト、ＨＴＭＬ）、添付の存在及び添付の種別、等を含み得る。
【００６４】
ブロック６０６において、メッセージが、ユーザに当該メッセージを提示し得るクライアント（例えば、図２のクライアント２０２）に配信され得る。ブロック６０８において、ユーザがメッセージに関する行動をとった場合、イベントレコーダ２３６はクライアントからイベント情報を受信し得る。イベント情報は、なされた行動の識別子を含み得る。ある実施形態では、イベント情報はまた、クライアントのコンテクスト情報、すなわち、クライアントデバイスの種別（例えばモバイル電話、ラップトップコンピュータ、デスクトップコンピュータ）、クライアントデバイスの識別（例えば特定のデバイス名又は他のユニークな識別子）、行動のとられた時間、行動がとられた際のクライアントデバイスの位置（例えば「家」又は「オフィス」などの定められた位置）、特定の位置の座標、又は利用可能な無線ネットワークの識別子などの他の位置を示すもの、等のようなコンテクスト情報を含み得る。
【００６５】
ブロック６１０において、イベントレコーダ２３６は、ブロック６０４において決定されたメッセージの特徴と、ブロック６０８において受信したイベント情報とを組み込んだイベント記録を生成し得る。処理６００は、イベント記録の組を生成するために、任意の数のメッセージとユーザ応答に対して繰り返され得る。イベント記録は、例えば、図２のイベント記録データストア２４２内に格納され得る。ある実施形態では、イベント記録は、異なるメッセージングサービスからユーザのために受信した、メッセージに関連する記録を含み得る。
【００６６】
多数のイベント記録が収集された後には、これらのイベント記録はユーザの行動のパターンを検出するために分析され得る。図７は、本発明の実施形態に従う、イベント記録に基づくユーザ行動のパターンを検出する処理７００のフローチャートを示す。処理７００は、例えば、図２のメッセージ管理サービス２００のパターンディテクタ２３８内に実装され得る。
【００６７】
ブロック７０２において、パターンディテクタ２３８は、図２のイベント記録データストア２４２からイベント記録の組を選択し得る。選択された組は、（例えば、同一のユーザアカウントにアクセスする複数のクライアントによってレポートされたイベント、及び／又は、異なるメッセージングサービスから供給される同一のユーザアカウントのためのメッセージに関連するイベントを含む）特定のユーザアカウントのための全てのイベント記録を含み得る。ある実施形態では、ブロック７０２における選択は、メッセージの特徴又は特徴の組み合わせに基づく、プレフィルタリング（ｐｒｅｆｉｌｔｅｒｉｎｇ）を含み得る。例えば、件名又は送信者に関連するパターンを検出するためにパターンディテクタ２３８が用いられる場合、１つ又は２つのイベント記録のみが所定の件名又は送信者を有するときは、その特定の件名又は送信者に対するイベント記録は無視され得る。プレフィルタリングはまた、様々なイベント記録の更新、イベント記録の合計数等のような、他の基準を採用し得る。他の例では、プレフィルタリングは、メッセージに何をすべきかを決定する前にユーザがメッセージを読んだ場合には自動化されたフィルタリングが最適又は望ましいものでないという前提のもと、イベント記録の組を、ユーザが行動を起こす前にメッセージを読んでいない場合のイベントに限定することを含み得る。ユーザがメッセージを読んだかの決定は、クライアントによって提供されたイベント情報に基づき得る。例えば、イベント情報は、行動をとる前にユーザがメッセージリストからメッセージを開いたか（例えば、図４Ａのメッセージリスト４０２内のメッセージに対するタッピングによる）、及び／又は、メッセージを開いた後であって行動する前にユーザがどのくらい長い時間をメッセージを探すことに費やしたかを示しうる。例えば、ユーザが、１秒又はそれ以下の時間で開かれたメッセージを見た場合、このことは、メッセージが、処理の仕方についてただちに認識可能なキューを含むことを示すかもしれず、ユーザが数秒の時間でメッセージを見た場合、キューは検出することを困難にし得る。
【００６８】
ブロック７０４において、パターンディテクタ２３８は、特定のイベントの特徴と結果として生じるユーザの行動との間の相関を検出するために、選択したイベント記録の組を分析し得る。様々な分析技術が使用され得るとともに、分析は、メッセージの１つの特徴、及び／又は、メッセージの特徴及び／又はコンテクスト情報の個別又は組み合わせにおけるコンテクスト情報を考慮し得る。
【００６９】
例えば、ある実施形態では、分析はイベントのカウントに基づいてなされ得る。パターンディテクタ２３８は、イベント記録から、特定の送信者から受信したメッセージの数、又は件名に特定の語を伴って受信したメッセージの数のような、特定のメッセージの特徴（又は特徴の組み合わせ）を有するメッセージの数(ＮＭ)を判定し得る。パターンディテクタ２３８はまた、ユーザが特定の（複数の）特徴を有するメッセージに対して特定の行動をとった回数(ＮＡ)を判定し得る。例えば割合ＮＡ/ＮＭに基づいて相関が検出され得る。特徴がユーザによる特定の行動と相関するインスタンスを特定するために、任意の数の１つの特徴及び／又は特徴の組み合わせがこの方法で分析され得る。メッセージの任意の特徴又は特性がこの分析に組み込まれ得る。
【００７０】
ある実施形態では、ブロック７０４における分析はまた、クライアントによって提供されたコンテクスト情報に部分的に基づき得る。例えば、ユーザは（例えば特定の送信者から、又はユーザの特定のグループに向けられた）特定の特徴を有するメッセージを後回しして、特定の場所（例えば自宅）で又は特定のクライアントデバイス（例えばモバイル電話と対照的なタブレット又はラップトップ）を使用して、後回しを続ける代わりにメッセージを読むまで、後回しを維持してよい。このようなパターンは、入力変数の組（この場合、コンテクスト情報のメッセージの特徴及び／又は要素に対応する）と特定の結果（この場合、一貫してとられる特定の行動）との間の相関についての柔軟かつ一般化された検出を提供する、多変量解析技術を用いて検出され得る。人工ニューラルネットワークのような機械学習アルゴリズムが任意の程度の複雑さの分析をサポートするために実施され得る。ある例では、複雑さは、例えば一度に考慮されるメッセージの特徴及び／又はコンテクスト要素の数を制限することにより、限定され得る。
【００７１】
ブロック７０４における分析は、（メッセージの特徴及び／又はコンテクスト情報の要素を含む）特徴の組と（例えば上で定義されたＮＡ/ＮＭ）特定のユーザの行動との間の相関の程度を示す相関メトリクスを生成し得る。ブロック７０６において、ルールを推奨するための基準として十分に強い相関を識別するために、更なる統計的処理が相関メトリクスに対して実行される。一般に、ブロック７０６における処理は、偶然によって単に発生し得るものから統計的に有意な相関を識別することが可能な任意のアルゴリズムを含み得る。ある実施形態では、相関は、最近のイベント記録のいくつかの組にわたって１００％であることが求められ得る。例えば、ブロック７０６は、ユーザが、関連する特徴の組を有する最も直近の３つ（又はそれ以上）のメッセージの全てに関して同一の行動をとることを必要とし得る。他の例では、ブロック７０６は、より大きなイベント記録の組にわたる、より弱い相関を必要とし得る。例えば、ユーザが関連する特徴の組を有する直近の２０のメッセージに対して少なくとも９５％の機会において同一の行動をとった場合、相関が強いとみなし得る。
【００７２】
ブロック７０８において、パターンディテクタ２３８は、例えば、ブロック７０６における分析を参照して、何等かの強い相関が特定されたかを判定し得る。処理７００は、イベント記録に対する更なる分析を実行するためにブロック７０２に戻り得る。ある実施形態では、更なる分析が追加的なイベント記録が利用可能になるまで停止され得るか、同一の記録の組が、例えば異なる特徴の組又は異なるプレフィルタリングの基準を参照することによって異なる方法で分析され得る。ブロック７０８で強い相関が検出された場合、ブロック７１０においてパターンディテクタ２３８は推奨されるルールを生成し得る。ある実施形態では、推奨されるルールは、「｛条件｝を満たした場合、｛行動｝をする」という一般的な形式を取り得る。｛条件｝、以下、トリガをかける条件としても参照される、は、特定の行動と強く相関させるために、メッセージの特徴の組、及び／又は、発見されたコンテクスト要素を特定し得る。｛行動｝、以下、結果として生じる行動としても参照される、は、メッセージを後回しにすること或いはメッセージをアーカイブすることのような、特定の行動を特定し得る。推奨されるルールは、上述したように、フィルタモジュール２３４とやりとりされ得る。
【００７３】
処理７００は、より多くのイベントの発生により繰り返され得、この分析は、複数の異なるメッセージングサービスからユーザに対して受信したメッセージを含みうる。上述したように、ある実施形態では、イベント記録は寿命又は大量の後続のイベントによって失効し得る。従って、異なる時間においては、処理７００は異なるイベント記録の組を分析することを含み得、更に、推奨されるルールはユーザの振る舞いの変化につれて発達し又はメッセージ管理サービス２００によってより良く理解され得る。様々な時間において、処理７００の実行は、結果として、ゼロ、１つ、又は1つより多くの推奨されるルールを生成し得る。
【００７４】
推奨されるルールを成立させる前に、メッセージ管理サービス２００は、クライアントへそのルールを提供し、ルールを成立させるべきであるとのユーザの確認を得る図８は、本発明の実施形態に従う、メッセージにフィルタリングルールを適用する処理８００のフローチャートを示す。プロセス８００は、例えば、図２に示すメッセージ管理サービス２００のフィルタリングモジュール２３４において実施され得る。
【００７５】
ブロック８０２において、フィルタリングモジュール２３４は、メッセージングサービス（例えば図２のメッセージングサービス２０４ａ）を送信元とするインバウンドのメッセージを受信し得る。これは、クライアントへ以前には配信されておらず、受信ユーザによって行動されておらず、又はメッセージ管理サービス２００によって処理（例えば後回し）されていない新しいメッセージとなり得る。
【００７６】
ブロック８０４において、フィルタリングモジュール２３４は、任意の成立したフィルタリングルール（例えば図２のルール２４０）を適用し得る。ある実施形態では、メッセージ管理サービス２００で新たなユーザアカウントが生成された場合、成立したフィルタリングルールの組は初めに空になり得る。或いは、ルールのセットは、例えばスパムフィルタリングのルール及び／又はユーザの人口統計に基づいて選択されたルールを含みうる開始時のルールの組を予め追加し得る。ブロック８０４において成立したルールを適用することは、メッセージが成立したルールに対してトリガをかける条件を満たしたかを判定し得、もしそうであれば、結果として生じる行動を自動的に実行する。例えば、成立したルールが、メッセージを自動的に後回しにし、フォルダ又はリストへ移動し、又は削除すべきことを示す場合、その示された行動が実行され得る。フィルタリングモジュール２３４又はメッセージ管理サービス２００の他のコンポーネントは、適切な更新命令を生成して、メッセージを受信した送信元のメッセージサービス（例えばメッセージングサービス２０４ａ）へ送信し、及び／又は行動を実行するための自身の内部状態を更新し得る。ある実施形態では、行動がクライアントからの通信に応答してなされるよりむしろ行動がフィルタリングモジュール２３４によって開始されるという唯一の差を有し、クライアントから受信したイベント情報に応答して同一の行動を実行するのと同じように、ルールに応答した行動の実行が実施され得る。
【００７７】
ブロック８０６において、フィルタリングモジュール２３４は、成立したルールを適用した結果に基づいて、インバウンドのメッセージが新たな受信メッセージとしてクライアントへ配信されるべきかを判定し得る。配信されるべきでない場合、ブロック８０８において、配信はブロックされ得る。例えば、成立したルールを適用することによってメッセージを（インボックスの外の）他のフォルダに移動し、後回しにし、又は削除する場合、そのメッセージは、新たな受信メッセージとしてクライアントへ配信されるべきではない。配信がブロックされた場合、処理８００は終了し得る（ブロック８１０）。
【００７８】
ブロック８０６が結果としてこの時点でメッセージを配信しないことを決定したとしても、メッセージはいずれにしろ後のある時間に配信され得ることが理解されるべきである。例えば、既定されたルールが適用されたことによりメッセージが後回しになった場合、その後回しになったメッセージは、クライアントへ後に、すなわち後回しの終了条件を満たした際に配信され得る。他の例として、ルールの適用が結果としてメッセージをリスト又はフォルダへ移動するものであった場合、ユーザが次にリスト又はフォルダにアクセスした際に、メッセージは配信され得る。
【００７９】
ブロック８０６においてメッセージが配信されるべきであると判定された場合、ブロック８１２において、フィルタリングモジュール２３４は、推奨されるルールのいずれかをメッセージに適用すべきかを判定し得る。ある実施形態では、例えば図７の処理７００を実行した結果として、パターンディテクタ２３８によって推奨されるルールが提供され得る。ブロック８１４において推奨されるルールが適用される場合、ブロック８１６において、フィルタリングモジュール２３４はメッセージに推奨メタデータを追加し得る。推奨メタデータは、適用可能な推奨されるルールを記述し得る。例えば、上述したように、ルールは、トリガをかける条件が満たされる場合にとられるべき、結果として生じる行動として表現され得る。従って、推奨メタデータは、結果として生じる行動とトリガをかける条件（例えば、トリガをかける条件がみたされるかを判定するために用いられる、特定のメッセージの特徴及び／又はコンテクスト要素）とを特定し得る。ブロック８１８において、メッセージはクライアントデバイスに配信され得る。図示されるように、メッセージは、推奨されるルールが適用されるかに関わらず配信され得るが、推奨メタデータは推奨されるルールが適用される場合にのみ追加される。
【００８０】
ある実施形態では、複数の推奨されるルールを同じメッセージに適用することができる。この場合、フィルタモジュール２３４は推奨されるルールの１つを選択し、推奨されるルールにのみ対する推奨メタデータを提供する。例えば、処理７００のある実装では、パターンディテクタ２３８が、検出した相関の強さに基づくスコアを各推奨されるルールに割り当て、フィルタモジュール２３４が最も高いスコアを有する推奨されるルールを選択し得る。（２つ以上の推奨されるルールによって最も高いスコアが共有されている場合、これらのルールのなかからランダムな選択がなされ得る。）他の実施形態では、フィルタモジュール２３４は、単一のメッセージについての複数の推奨されるルールに対して推奨メタデータを追加し得る。
【００８１】
ブロック８２０において、処理８００はクライアントからイベント情報を受信し得る。イベント情報は、メッセージに対して実行されたユーザ行動の指標を含み得、また、ユーザが推奨されるルールにどのように対応したかについての指標をも含み得る。例えば、図４Ｃを参照すると、イベント情報は、ユーザが（ルールを受け入れる）「はい」ボタン４４４を選択したか、若しくは、「いいえ」ボタン４４６、「後できく」ボタン４４８、又は「閉じる」ボタン４５０のいずれか（ルールを受け入れない様々な形式に対応するものの全て）を選択したかを示し得る。ユーザがブロック８２２において推奨されるルールを受け入れた場合、ブロック８２４において、推奨されるルールは成立したルールの組に追加され得、処理８００は終了し得る（ブロック８１０）。ユーザがブロック８２２において推奨されるルールを受け入れなかった場合、ブロック８２６において、処理８００は、推奨されるルールに対する拒否データを更新し得、後に処理８００が終了し得る（ブロック８１０）。
【００８２】
ある実施形態では拒否データが使用されて、ユーザが受け入れなかった後に再び推奨されるルールを提示するか、及びいつ提示するかを決定し得る。図９は、本発明の実施形態に従う、拒否データを更新する処理９００のフローチャートを示す。プロセス９００は、例えば、メッセージ管理サービス２００のフィルタモジュール２３４において実施され得、上述した処理８００のブロック８２６において使用され得る。
【００８３】
ブロック９０２において、推奨されるルールに対するユーザの応答が読み出される。この例では、図４のメニュー４４０が提示され、ユーザが選択したことが想定される。「はい」ボタン４４４が選択された場合、ルールが受け入れられ、プロセス９００は起動されない。他の場合は、図９に示す方法で処理される。
【００８４】
例えば、ブロック９０４において、ユーザが（例えば図４Ｃの「いいえ」ボタン４４６を選択することによって）「いいえ」と応答した場合、これは、恐らくユーザが推奨されるルールの実施を少なくとも今は望んでいないことの兆候として解釈され得る。従って、推奨されるルールが再び提示されることを一次的に又は永続的に抑制することが望ましいかもしれない。ある実施形態では、カウンタ「Ｎ（Ｎｏ）」が各推奨されるルールに対して保持され、ユーザが「いいえ」に応答した回数をカウントする。ブロック９０６において、カウンタが最大値（例えば２又は３又はある他の数）に達した場合、そのときはブロック９０８において、推奨されるルールが抑制され得る。例えば、フィルタモジュール２３４は抑制されるルールのリストを保持し得る。パターンディテクタ２３８が推奨されるルールを提供する場合はいつでも、フィルタモジュール２３４は、推奨されるルールを抑制されるルールのリストと比較して、抑制されるルールと一致する場合には当該推奨されるルールを無視し得る。ある実施形態では、フィルタモジュール２３４は抑制されるルールについてのフィードバックをパターンディテクタ２３８に提供し得、パターンディテクタ２３８は以降の処理に当該フィードバックを取り込み得る。
【００８５】
ブロック９０６においてカウンタＮ（Ｎｏ）がその最大値に達していない場合、そのときはブロック９１０においてカウンタＮ（Ｎｏ）がインクリメントされ得る。推奨されるルールがあまりにすぐに再びユーザに提示される（これによりユーザをいらつかせる）ことを防ぐため、ブロック９１２において、推奨されるルールに対する遅延カウンタが初期化され得る。ある実施形態では、遅延カウンタは時間に基づき得、例えば、ユーザが「いいえ」と応答した推奨されるルールは、少なくとも２４時間の間には再び提示されない。ある実施形態では、遅延カウンタは、推奨されるルールが適用されたメッセージの数に基づき得、例えば、ユーザが「いいえ」と応答した推奨されるルールは、ユーザが少なくとも３つ（又はある他の数）かそれ以上のメッセージに対して行動するまで再び提示されない。いずれの場合でも、フィルタモジュール２３４は、遅延カウンタの有効な推奨されるルールがブロック８１４において適用されないものとして扱われる場合を除き、遅延カウンタが制限に達するような時間（例えば遅延時間が満了するか関連するメッセージの数が到達する）まで、上述した処理８００に従って新たなインバウンドのメッセージに対する処理を継続し得る。１つの推奨されるルールに対して遅延カウンタが有効である間に、例えば処理８００の動作を通して他の推奨されるルールが提示され得ることが理解されるべきである。
【００８６】
ブロック９０４においてユーザが「いいえ」と応答しなかった場合、処理９００はブロック９１４に進み得る。ユーザが（例えば図４Ｃの「後できく」ボタン４４８を選択することにより）「後で」と応答した場合、そのときはブロック９１６において、当該推奨されるルールに対する遅延カウンタが初期化され得る。遅延期間が異なるが、これはブロック９１２を参照して説明した遅延カウンタと同様であり得る。例えば、遅延期間は、「いいえ」の応答よりも「後で」の応答に対するものの方が短くなり得る。ある実施形態では、「後で」の応答に対する遅延期間は実際的にゼロであり得る。すなわち、ルールが適用される新たなインバウンドのメッセージをメッセージ管理サービス２００が受信する次の機会には、推奨されるルールが再び提示され得る。ユーザが「後で」と応答した場合、処理９００の目的には、ユーザがなお興味を有するであろうことが想定され、「いいえ」の場合とは異なり、「後で」の応答は結果的に推奨されるルールを抑制しない。
【００８７】
ブロック９１４においてユーザが「後で」と応答しなかった場合、処理９００はブロック９１８に進み得る。これは、（例えば図４Ｃの「閉じる」ボタン４５０を選択することにより）ユーザが特定の応答なしにプロンプトを閉じた場合に対応する。ここで、この応答はユーザが単に今はプロンプトを読みたくないことを示し得、また、この応答はユーザが概して推奨されるフィルタリングルールを受けとることに興味がないことを示し得るため、ユーザの意図は曖昧である。この意図は、興味がないことを示唆する「閉じる」をユーザが繰り返し選択する場合、パターンからより正確に推測され得る。従って、ある実施形態では、フィルタモジュール２３４は「閉じる」応答（「Ｎ（Ｃｌ）」）のグローバルカウンタを保持し得る。ブロック９２０においてこのカウンタＮ（Ｃｌ）が最大値（例えば、３、５又はある他の値）に達した場合、そのときはブロック９２２において、フィルタモジュール２３４が全ての推奨されるルールを抑制し得る。例えば、図８を参照すると、フィルタモジュール２３４は処理８００のブロック８１４と８１６とをスキップし得る。ブロック９２０においてカウンタＮ（Ｃｌ）がその最大値に達していない場合、そのときはブロック９２４においてカウンタＮ（Ｃｌ）がインクリメントされ得る。ある実施形態では、「閉じる」以外の任意のユーザの応答がカウンタＮ（Ｃｌ）をリセットして、「閉じる」以外の何らかではユーザが応答しない場合にのみ、ブロック９２２における、推奨されるルールの全体的な抑制が起こるようにする。他の実施形態では、メッセージ管理サービス２００が「閉じる」応答を無視して、そのような応答が以降のふるまい（例えばルールが推奨されるか）に影響を与えないようにし得る。
【００８８】
（ブロック９０８の結果として）特定の推奨されるルールが抑制される場合、又は、（ブロック９２２の結果として）全ての推奨されるルールが抑制される場合、抑制が必ずしも永続的ではないがなされ得る。例えば、抑制は、メッセージ管理サービス２００がフィルタリングルールの推奨を再び開始する前の、固定期間（例えば１週間又は１か月）において継続し得る。推奨されるルールが一次的に抑制される場合、パターンディテクタ２３８は動作を継続して、推奨されるルールが抑制されない状態になった場合に、ユーザに提示され得る現在の推奨されるルールの組をフィルタモジュール２３４が有するようにし得る。
【００８９】
上述したように、推奨されるルールはクライアントによってユーザに提示され、推奨されるルールが成立したルールになるべきかをユーザが決定できるようにする。推奨されるルールを提示するためにクライアントデバイスによって使用され得る処理の例がこれから説明される。図１０は、本発明の実施形態に従う、推奨されるルールをユーザに提示する処理１０００のフローチャートを示す。処理１０００は、例えばクライアント２０２（又は、図１のクライアント１０８か１１０）において、図４Ａ−４Ｃのユーザインタフェースと似たユーザインタフェースを用いて実施され得る。
【００９０】
処理１０００は、例えばメッセージ管理サービス２００が上述した処理８００のブロック８１８を実行した結果として、クライアント２０２が新たなメッセージを受信した場合に、ブロック１００２において開始され得る。ブロック１００４において、クライアント２０２は、例えば図４Ａのメッセージリスト４０２のようなメッセージリスト内に、ユーザへのメッセージを提示し得る。ブロック１００６において、クライアント２０２は当該メッセージに関連するユーザ入力を受け取り得、そして、ブロック１００８において、クライアント２０２は示された行動を決定するためにユーザの入力を解釈し得る。例えば、図４Ｂに示すように、ユーザ入力はメッセージを後回しにする行動を示し得る。
【００９１】
処理１０１０において、クライアント２００は、（例えばメッセージ管理サービス２００が上述した処理８００のブロック８１６を実行した結果として）行動のなされたメッセージが推奨メタデータを有するかを判定し得る。推奨メタデータを有する場合、ブロック１０１２において、クライアント２０２は、ブロック１００８において示された行動が推奨メタデータで特定される結果として生じる行動と一致するかを判定し得る。一致する場合、ブロック１０１４において、クライアント２０２は、推奨されるルールに関するプロンプトをユーザに提示し得る。このプロンプトは図４Ｃのプロンプトオーバレイ４４０と類似する。ブロック１０１６において、クライアント２００は、（例えば、「はい」、「いいえ」、「後できく」又は「閉じる」を選択する）当該プロンプトに応答するユーザ入力を受け取り得る。ブロック１０１８において、クライアント２０２はメッセージ管理サービス２００にイベントをレポートし得る。レポートは（ブロック１００８において決定されたように）メッセージに対してなされた行動と、（ブロック１０１６において受け取った）プロンプトに対する応答とを含み得る。
【００９２】
推奨メタデータがブロック１０１０において提示されない場合、又は、ブロック１０１２の結果として、ユーザの行動が推奨されるルールにおける結果として生じる行動と一致しないと判定された場合、ブロック１０２０において、クライアント２０２はメッセージ管理サービス２００にイベントをレポートし得る。この場合、推奨されるルールに関連するプロンプトが提示されない場合、レポートはプロンプトに対するユーザの応答を含まない。ある実施形態では、ブロック１０２０におけるレポートは、推奨されるルールと、当該推奨されるルールと一致しない行動とがあったか、又は、推奨されるルールがなかったかを示し得、他の実施形態では、この情報がすでにメッセージ管理サービス２００において利用可能であり、クライアントはレポートする必要がない。ブロック１０２０におけるレポートはまた、行動を選択する前にユーザがメッセージを開いたか、開いた場合にはメッセージがどれだけ長く開かれたか、のような他の情報を含み得る。
【００９３】
ブロック１０１８又は１０２０においてレポートがなされた後に、処理１０００はブロック１０２２において終了し得る。ユーザによってなされた行動はイベント記録に取り込まれるとともに、続いてパターンディテクタ２３８によって用いられて、将来の推奨されるルールが生成され得る。更に、イベント情報が、推奨されるルールをユーザが受け入れたことを示す場合、当該推奨されるルールは、上述したように成立したルールの組に追加され得る。
【００９４】
処理１０００又はその一部は、新たなメッセージを受信したときに繰り返され得る。例えば、新たなメッセージが受信されたとき、ユーザに提示されるメッセージのリストが更新され得る。ユーザは、メッセージを受信する順番に対応する必要はない、任意の順番でメッセージとの相互作用を行い得、そして、ユーザがたまたまメッセージに対して行動した場合はいつでも、ブロック１００６−１０２０が特定のメッセージに関して実行され得る。
【００９５】
図１１は、本発明の実施形態に従う、推奨されるルールをユーザに提示する他の処理１１００のフローチャートを示す。処理１１００は、例えばクライアント２０２（又は、図１のクライアント１０８か１１０）において、図５Ａ−５Ｃのユーザインタフェースと似たユーザインタフェースを用いて実施され得る。
【００９６】
処理１１００は、例えばメッセージ管理サービス２００が上述した処理８００のブロック８１８を実行した結果として、クライアント２０２が新たなメッセージを受信した場合に、ブロック１１０２において開始され得る。ブロック１１０４において、クライアント２０２は、例えば図５Ａのメッセージリスト５０２のようなメッセージリスト内に、ユーザへのメッセージを提示し得る。ブロック１１０６において、メッセージが（例えばメッセージ管理サービス２００が上述した処理８００のブロック８１６を実行した結果としての）推奨メタデータを有する場合、ブロック１１０８において、クライアント２０２は推奨されるルールの表示を含む提示を変更し得る。例えば、図５Ａに示したように、下線が用いられて、トリガをかける条件（例えばトリガをかける条件に対応する部分に下線を引くことによる）、及び／又は、結果として生じる行動（例えば下線の色又は線のスタイルによる）が示され得る。
【００９７】
ブロック１１１０において、クライアント２０２はメッセージに関連するユーザ入力を受け取り得る。例えば、図５Ａを参照すると、ユーザ入力はメッセージ又はメッセージの変更された部分をタップすることを含み得る。
【００９８】
ブロック１１１２において、クライアント２０２は、当該ユーザ入力が、ルールを受け入れるためのプロンプトが表示されるべきであることを示しているかを判定する。例えば、上述したように、メッセージ上のタップは、プロンプトが表示されるべきことを示すかもしれないが、一方で他の行動（例えばメッセージを不ワイプすること）は、プロンプトが表示されるべきでないことを示すかもしれない。プロンプトが表示されるべきである場合、ブロック１１１４において、クライアント２０２は、推奨されるルールに関するプロンプトをユーザに提示し得る。このプロンプトは図５Ｂのプロンプト５３０と類似する。ブロック１１１６において、クライアント２００はプロンプトに応答するユーザ入力（例えば、推奨を受け入れるためにプロンプト５３０上をタップする、又は断るために画面上の他のどこかをタップする）を受け取り得る。ブロック１１１８において、クライアント２００は、ユーザが推奨されるルールを受け入れたかを判定し得る。受け入れた場合、ブロック１１２０において、クライアント２００はユーザインタフェースを介して、例えば図５Ｃに示したように行動をアニメーションさせ、結果として生じる行動を示し得る。これは、推奨されるルールが受け入れられたこと、及び、結果として生じる行動がメッセージに適用されることの確認を提供し得る。推奨されるルールが受け入れられたかに関わらず、ブロック１１２２において、クライアント２０２はメッセージ管理サービス２００にイベントをレポートし得る。レポートは（ブロック１１１６において受け取ったように）プロンプトに対する応答、及び／又は、メッセージに対してなされる行動の指標を含み得る。
【００９９】
ルールのプロンプトが（例えば推奨メタデータがブロック１１０６において表示されないために）ブロック１１１２において表示されない場合、ブロック１１２４において追加的な処理が発生し得る。例えば、ユーザ入力がブロック１１１０においてメッセージに対してとるべき何らかの他の行動を示す場合、クライアント２００は、その行動を含むイベント情報をメッセージ管理サービス２００にレポートし得る。そのレポートは、推奨されるルールと、当該推奨されるルールと一致しない行動とがあったか、又は、推奨されるルールがなかったかを示し得、他の実施形態では、この情報がすでにメッセージ管理サービス２００において利用可能であり、クライアントはレポートする必要がない。ブロック１１２４におけるレポートはまた、行動を選択する前にユーザがメッセージを開いたか、開いた場合にはメッセージがどれだけ長く開かれたか、のような他の情報を含み得る。
【０１００】
ブロック１１２２におけるレポート、又はブロック１１２４における更なる処理の後に、処理１１００はブロック１１２６において終了し得る。ユーザによってなされた行動はイベント記録に取り込まれるとともに、続いてパターンディテクタ２３８によって用いられて、将来の推奨されるルールが生成され得る。更に、イベント情報が、推奨されるルールをユーザが受け入れたことを示す場合、当該推奨されるルールは、上述したように成立したルールの組に追加され得る。
【０１０１】
処理１１００又はその一部は、新たなメッセージを受信したときに繰り返され得る。例えば、新たなメッセージが受信されたとき、ユーザに提示されるメッセージのリストが更新され得る。ユーザは、メッセージを受信する順番に対応する必要はない、任意の順番でメッセージとの相互作用を行い得、そして、ユーザがたまたまメッセージに対して行動した場合はいつでも、ブロック１１１０−１１２２が特定のメッセージに関して実行され得る。
【０１０２】
以下に示される処理が具体例であると共に変形例及び修正が可能であることが理解される。時系列として示したステップは平行に実行されてもよく、ステップの順序は変更されてもよく、そして、ステップは変更され、統合され、追加され、又は省略されてもよい。処理６００、７００、８００、９００、１０００及び１１００（又は同様の処理）は、ユーザの振る舞いと、推奨されるルールが成立したルールになるべきかについてのユーザの最終的な決定とに基づいて自動的に推奨されるルールと共に用いられ、動的なフィルタリングを実施し得る。例えば、処理６００は、新たなメッセージが配信され、クライアントによって（又はユーザがクライアントと相互作用して）行動がなされるまで繰り返され得る。処理７００は一定のインターバルで（例えば、ある最小数の新たな行動がレポートされた後に）繰り返されて、推奨されるルールの組が更新され得る。従って、強い相関が検出された場合に、特定のルールが推奨されるルールになり得る。ユーザがルールを受け入れない場合、ルールは、強い相関が検出され続ける限り、推奨として残り得る。相関が弱くなる場合、推奨されるルールは、処理７００の動作によって推奨されるルールの組から取り消され得る。処理８００は、メッセージ管理サービス２００から受信する各新たなメッセージに対して実行され得、処理９００はユーザが推奨されるルールを受け入れない場合に実行され得る。処理１０００は、クライアントによって新たなメッセージが受信され、ユーザによって行動がなされるまで実行され得る。
【０１０３】
以下に示す処理は、複数のクライアントデバイスにわたって統一的なフィルタリングの振る舞いを提供し得る。例えば、図２のイベント情報データストア２４２は、特定のユーザによって使用される全てのクライアントにわたるイベントを収集し得る。更に、成立したルールは同一のユーザに関連付けられた全てのクライアントにわたって適用され得るため、複数のクライアントを有するユーザは、各クライアントに対する同一のルールを再生成する時間を過ごす必要はない。
【０１０４】
ある実施形態では、ユーザの振る舞いのパターンは、ユーザが操作している特定のクライアントと関連付けられ得る。例えば、ユーザは１日のあらゆる時間にモバイル電話（例えば図１のクライアント１０８）上でメッセージを再確認し、友人からのメッセージを、自宅でデスクトップコンピュータ（図１のクライアント１１０）を用いることができる時間、すなわちメッセージを読んで応答する時間まで後回ししたままにしてもよい。ある実施形態では、図２のパターンディテクタ２３８は、このパターンを検出し、ユーザがクライアント１１０を用いる次の時間まで、これらの送信者からのメッセージを後回しにするルールを提案し得る。
【０１０５】
ある実施形態は、複数のメッセージングサービスのアカウントにわたる統一されたフィルタリングの振る舞いを提供し得る。例えば、上述したように、メッセージ管理サービス２００は、複数のメッセージングサービス２０４ａ、２０４ｂのための仲介人として動作し得る。任意の数のメッセージングサービス２０４におけるユーザアカウントは、メッセージ管理サービス２００における単一のユーザアカウントにリンクされ得る。このような場合、メッセージ管理サービス２００は、複数のメッセージングサービスからのメッセージに関する、ユーザの振る舞いについての情報へのアクセスを有し得る。従って、メッセージ管理サービス２００は、異なるメッセージングサービスから供給されたメッセージにわたるユーザの振る舞いの相関を検出し、フィルタリングルールを適切に推奨し得る。ある例では、ユーザの振る舞いはメッセージの供給元と関連付けられてもよい。例えば、ユーザは、仕事の電子メールアドレスで受信したメッセージを、個人の電子メールアドレスで受信したメッセージとは別に扱ってもよい。ある実施形態では、パターンディテクタ２３８は、メッセージの送信元に依存するパターンを検出し得、そして、他のフィルタリングルールはメッセージの送信元と独立であり得るが、フィルタリングルールのために定義されるトリガをかける条件が送信元を取り込み得る。
【０１０６】
更に、ある実施形態はまた、メッセージの複数の種別にわたる統一されたフィルタリングの振る舞いを提供し得る。例えば、上述したように、メッセージ管理サービス２００は複数のメッセージングサービス２０４ａ、２０４ｂに対する仲介人として動作し得、異なるメッセージングサービス２０４ａ、２０４ｂは同一の種別のメッセージ（例えば２つの異なる電子メールサービスプロバイダ）又は異なる種別のメッセージ（例えば電子メールサービスプロバイダとソーシャルネットワーキングサービスプロバイダ）を提供し得る。（異なる種別のメッセージをサポートするサービスを提供する）任意の数のメッセージングサービス２０４におけるユーザアカウントは、メッセージ管理サービス２００における単一のユーザアカウントにリンクされ得る。このような場合、メッセージ管理サービス２００は、異なる種別のメッセージに関する、ユーザの振る舞いについての情報へのアクセスを有し得る。メッセージ管理サービス２００は、統一されたメッセージモデルを構成して、異なる種別のメッセージの取り扱いを容易にし得る。例えば、各メッセージは、メッセージ種別（例えば、電子メール、ソーシャルネットワークメッセージ、テキストメッセージ等）、送信者識別子（例えば電子メールアドレス、電話番号、名前等）、受信者識別子（例えば、１つ以上の電子メールアドレス、電話番号、名前等）、送信された日付及び時間、メッセージングサービスが受信した日付及び時間、件名（件名の欄を提供しないテキストメッセージのようなメッセージの種別では空欄であり得る）、及びメッセージボディのようなフィールドを有する、構造化されたデータオブジェクトとしてモデル化され得る。従って、個人間及び／又はグループの間の多種多様なコミュニケーションを含む、異なる種別のメッセージは、上述した方法で共に分析されて、現れた場合に結果として一貫したユーザの行動となる特徴の組を特定し得る。従って、メッセージ管理サービス２００は、異なるメッセージの種別にわたるユーザの振る舞いの相関を検出し、フィルタリングルールを適切に推奨し得る。ある例では、ユーザの振る舞いはメッセージの種別と関連付けられてもよい。例えば、ユーザは、電子メールのメッセージを、テキストメッセージやソーシャルネットワークのメッセージとは別に扱ってもよい。ある実施形態では、パターンディテクタ２３８は、メッセージの種別に依存するパターンを検出し得、そして、他のフィルタリングルールはメッセージの種別と独立であり得るが、フィルタリングルールのために定義されるトリガをかける条件がメッセージの種別を取り込み得る。
【０１０７】
上述したような処理は、ユーザの取り組みをほとんど又はまったく要することなく、フィルタリングルールが生成されるようにし得る。例えば、ユーザは、ルール定義用インタフェースにアクセスし、ルールのテンプレートを埋め、又は、ルールを定義することを目的とする明確な他の行動をとる必要はない。代わりに、ユーザが単純に適当だと思うようにメッセージに対する行動をとり、ユーザの行動において検出されたパターンに基づき、メッセージ管理サービスは、ユーザがメッセージに対してより効率的に行動できるようにし得るルールを特定し推奨し得る。推奨されるルールは、その妥当性を理解できるコンテクストにおいて（例えば、上述したように、実際にユーザが丁度メッセージに対してルールを適用したときに）ユーザに提供され得、ユーザは、現れた場合にはその推奨を単純に受け入れることによってルールを成立させることができる。更に、ユーザの承認の後にのみ推奨されるルールが成立したものになる実施形態では、ユーザは、ユーザが望み得ない、メッセージ管理サービスに独自に行動させる不愉快な体験を避けることができる。
【０１０８】
本発明の開示に接する当業者は他の変更が可能であることを認識する。例えば、ある実施形態では、推奨されるルールは、メッセージを最初に読むことなく移動、後回し又はメッセージをアーカイブするような、ユーザの行動の特定の組に基づいて生成され得る。そのような実施形態では、メッセージに対して行動をとる前にユーザがメッセージを読んだ場合の出来事は、例えば、（例えば処理７００のブロック７０２において）パターンディテクタ２３８のためのイベント記録を生成しないことによって、又はそのようなイベント記録を排除するためにプレフィルタリングを行うことによって、無視され得る。ユーザが行動をとる前にメッセージを読んだかどうかは、クライアント２０２によってヒューリスティックに判定され得、メッセージ管理サービスにイベント情報の一部としてレポートされ得る。例えば、ある実施形態では、ユーザが（メッセージを最初に開くことなく）インボックスのメッセージリストから直接的にメッセージに対して行動したか、メッセージに対して行動をとるより前に定められた期間（例えば、１秒又はそれ未満、又は２秒又はそれ未満）より短い間メッセージを開いたか、のいずれかである場合、メッセージは未読であると考えられ得る。クライアントは、ユーザが新たなメッセージを開いたときにタイマを開始し、定められた期間より長い間メッセージを開いたままになっている場合にメッセージが既読であるとみなす。定められた期間は要望通りに選択され得、そして、ユーザが典型的なメッセージを読むためにどれくらい時間を要するかのような、ユーザの振る舞いの観察結果に基づき得る。
【０１０９】
ある実施形態では、推奨されるルールの生成は、トリガをかける条件から起因するユーザの行動の一貫したパターンが検出され得ることによって、メッセージに対するあらゆるユーザの行動に拡張され得る。メッセージの移動、後回し、削除に関するルールについては、ルールを適用することは（例えば上述した例における）結果としてメッセージをクライアントへ配信しないことになるかもしれない。他の種別のルールについては、ルールを適用するメッセージは、ユーザにメッセージを提示することと関連して、クライアントがとるべき行動を示す行動メタデータとともにクライアントへ送信され得る。
【０１１０】
例えば、ユーザが一貫して特定の送信者から受信したメッセージを特定の送信先に転送する場合、ルールは、その送信者からのあらゆるメッセージに対して、当該送信先に転送することをユーザに促すことが定められ得る。メッセージ管理サービス２００は、当該送信先に転送することをユーザに促すことを示し、且つその送信先を特定する行動メタデータとともに、メッセージをクライアント２０２に送信し得る。ユーザがメッセージを開いた場合、クライアント２０２は、例えば、ユーザがそのメッセージを転送することを望むかどうかを尋ねるプロンプトを表示することにより、メッセージを転送するように促し得る。メッセージが転送されるべきであることをユーザが示した場合、クライアント２０２は、転送されるメッセージを準備して、自動的に送信するか、送信する前にユーザが転送されるメッセージを編集することを望む場合にユーザに提示するかのいずれかを行う。ある実施形態では、トリガをかける条件を満たすメッセージを常に転送するための推奨されるルールをユーザが受け入れた場合、その転送はメッセージ管理サービス２００内に実装され得、メッセージとともに送信されるメタデータは、ルールの適用によってメッセージが転送された指標を含み得る。クライアントは、ユーザがメッセージを手動で転送する必要がないことを知るように、（例えばユーザがメッセージを開いた場合に）そのようにユーザに伝え得る。
【０１１１】
他の例として、ユーザは特定の送信者（又は送信者の組）からのメッセージに、特定の特徴を有するメッセージで一貫して返信してもよい。例えば、ユーザは、後の日に実質的な応答が続き得る「確認しました」というショートメッセージで、ボスからのメッセージに即座に返信し得る。又は、ユーザは、箇条書き形式のアイテムのリストを伴う「ストアに向かっています、何か必要ですか？」という配偶者からのメッセージを繰り返し受信し得る。ある実施形態では、メッセージ管理サービス２００は返信を分析して、返信メッセージ内の特定の特徴と返信されるメッセージの特徴との間の相関を検出し得る。受信したメッセージのトリガをかける特徴と、返信メッセージの特定の特徴（例えば、内容及び／又は形式）との間の相関が検出された場合、ルールは、トリガをかける特徴を有するあらゆるメッセージに対して、トリガをかける特徴と関連した特徴を有するメッセージとともに返信をユーザに促すべきということが定義され得る。メッセージ管理サービス２００は、当該送信先に転送することをユーザに促すことを示し且つユーザがメッセージに返信するよう促されることを示す行動メタデータとともに、メッセージをクライアント２０２に送信し得る。ユーザがメッセージを開いた場合、クライアント２０２は、例えば、ユーザがそのメッセージに返信することを望むかどうかを尋ねるプロンプトを表示することにより、メッセージに返信するように促し得る。プロンプトは、ユーザがこのプロンプトを受け入れた場合に返信に自動的に含まれ得る任意の特徴を示しうる。ユーザがプロンプトを受け入れる場合、クライアント２０２は、自動的な特徴を取り入れた返信メッセージを準備して、自動的に送信するか、送信する前にユーザが返信されるメッセージを編集することを望む場合にユーザに提示するかのいずれかを行う。
【０１１２】
トリガをかける条件と結果として生じる行動とは、要望通り豊富に又は要望通り複雑性を少なく定義され得る。ある実施形態では、トリガをかける条件はメッセージ内における１つの特徴の存在又は欠如（例えば、特定の送信者、又は件名における特定の語）に基づき得る。他の実施形態では、トリガをかける条件はメッセージの特徴の組み合わせを取り込み得る。例えば、「クーポンに関する」語の組が特定され得る。このような語は、「クーポン」又は「値引き」のような単一の語、又は、「[パーセント]節約」や「[ドルの量]引き」等を構成する複数の語を含み得る。トリガをかける条件は、特定の送信者と組み合わせた、メッセージ内の１つ以上のクーポンに関連する語の出現に基づき得、又は、特定の形式（例えばＨＴＭＬ）のメッセージと組み合わせた、ある最低限の数のクーポンに関連する語（例えばそのような語の３つ以上）の組み合わせに基づき得る。
【０１１３】
同様に、結果として生じる行動の複雑さは変化し得、メッセージ管理サービス２００によってサポートされる任意の動作は結果として生じる行動になり得る。例えば、あるメッセージ管理サービスは、後回し終了条件が発生するとき、すなわちメッセージがユーザに提示され得る（例えばインボックスに回復する）ときまで、メッセージを後回しにするための機能（ユーザのインボックスからメッセージを一時的に削除し得る）を提供し得る。ルールがメッセージを後回しにするために定義された場合、後回し終了条件は様々な基準に基づいて定義され得る。上述の例は、夜又は週末までメッセージを後回しにするような一時的な基準に言及するものである。メッセージ管理サービス２００は、内部クロック及び／又は外部クロックを参照することによって、そのような基準が満たされたかを検出し得る。他のルールは、特定の時間よりも特定のユーザ（又はクライアント）コンテクストの検出に基づく基準を使用し得る。例えば、ルールは、ユーザ（又はクライアント）が家又はオフィスのような特定の場所に存在するまでメッセージを後回しにし得る。ある実施形態では、メッセージ管理サービスは位置に基づく条件が発生したかを判定するために、クライアントから位置情報を受信してその位置情報を使用し得る。他の例として、ルールは、ユーザが特定のクライアントデバイス（例えばモバイル電話よりもデスクトップコンピュータ）を操作するまでメッセージを後回しにし得、メッセージ管理サービスは、クライアント固有の条件が発生したかを判定するために、特定のクライアント上の活動を検出してクライアント識別情報を使用し得る。他の例として、ユーザが、例えばユーザのカレンダデータに基づいて判定され得る「暇（ｆｒｅｅ）」になるまでメッセージを後回しにし得る。ある実施形態では、クライアントはカレンダデータ又はカレンダデータに基づく「暇／多忙」の指標を、データを使用してユーザが暇であるかを判定するメッセージ管理サービスに提供し得る。ルールは、ユーザが特定の他の人又はデバイスに近接した状態になるまで、メッセージを後回しにし得る。ある実施形態では、クライアントは付近で検出されたデバイス（例えば同一のＷｉ−Ｆｉネットワーク上の他のデバイス）をレポートし、メッセージ管理サービスは、後回し終了条件が発生したかを判定するために、そのようなレポートを使用し得る。或いは、メッセージ管理サービスは複数のクライアントデバイスと通信して各クライアントデバイスから位置のレポートを受信し、２つのクライアントデバイスの近接が、クライアントデバイスが互いに通信し又は互いに認識すること無く、位置のレポートに基づいて判定され得る。
【０１１４】
ある実施形態では、結果として生じる行動は、部分的又は全体的なメッセージの特性に基づいて定義され得、当該結果として生じる行動は、繰り返し行う行動よりもユーザが好む行動であり得る。例えば、ユーザは、配布物や他のコンテンツがメッセージとして受信者のグループに定期的に送信され、ニュースレター又は他のある購読料で運営するサービスを購読してもよく、送信者は、配信停止の方法、例えば配信停止のリクエストのためのアドレスを提供するメッセージの最後の行、を示す指示を各メッセージ（又は配布物）に含めてよい。メッセージ管理サービス２００は、ユーザが特定の購読のニュースレターメッセージを読むこと無く一貫して削除するパターンを検出し得る。パターンは、送信者、件名、受信者のリスト、書式設定、及び／又はメッセージとして送信されるニュースレターの配布物にわたって一貫し得る他の特性に基づいて、検出され得る。ある実施形態では、メッセージ管理サービス２００は将来の配布物を自動的に削除するルールを推奨し得る。他の実施形態では、メッセージ管理サービス２００は、配信停止の指示を提供するルールによって、削除され得るメッセージを検出し得、メッセージを単に削除するよりもニュースレターの配信を停止するようにユーザを促し得る。ユーザがプロンプトを受け入れる場合、メッセージ管理サービス２００は、メッセージ内の指示に基づいて、配信を停止するリクエストを自動的に生成し得る。ある実施形態では、さらに、送信されるべきメッセージを検証したり、ウェブサイトにおいてリクエストを確認したりするなど、ユーザ相互作用が配信停止の処理に取り込まれてもよい。他の例として、ある実施形態では、メッセージ管理サービス２００は、ユーザの配信停止の振る舞い（例えば、特定の特徴を有するニュースレタータイプのメッセージに応答して、ユーザが配信停止のメッセージを一貫して送信する）を検出し得、これらの特徴を有する他のニュースレタータイプのメッセージの配信停止を推奨するルールを生成し得る。ルールが適用される場合、メッセージ管理サービス２００は、ユーザが配信を停止するよう促されることを示す行動メタデータとともに、メッセージをクライアント２０２に送信し得る。
【０１１５】
以下に説明されるユーザインタフェースは変更もされ得る。ある実施形態では、追加的なユーザインタフェースが実施され得る。例えば、クライアントデバイスを操作するユーザは、メッセージ管理サービスからの推奨に独占的に頼る代わりに、ルールを手動で定義できてよい。ある実施形態では、（例えば図４Ｂに示した）メッセージを移動するためのジェスチャを行うユーザは、長期間（例えば１秒、２秒等）にわたって最後の状態でジェスチャを維持して、ジェスチャがルールとして適用されるべきであることを示し得る。ジェスチャを維持することは、結果してクライアントにダイアログボックスを表示させ、（図４Ｃ又は図５Ｃと同様に）ルールを成立させるべきであることを確認をとり得る。ユーザが確認した場合、クライアントは、新たなルールの記述をメッセージ管理サービスに送信して、ルールが全てのユーザのクライアントデバイスとメッセージングアカウントとにわたって適用されるようにし得る。
【０１１６】
ある実施形態では、ユーザインタフェースは、ユーザがルールを提示し、変更し、削除するためにアクセスし得る設定ページ等を含み得る。例えば、ある設定ページは、クライアントが情報をリクエストすることによってメッセージ管理サービスから得られうる、現在成立しているルールのリストを提示し得る。このリストは、ユーザがルールを編集し又は削除し得るオプション（例えばボタン又はジェスチャ）を提供し得る。他の例として、他の設定ページは、（上述したように）メッセージ管理サービスによって生成されたものであるがまだユーザによって受け入れられたり、拒否されていない、推奨されるルールのリストを提示し得、ユーザはリストと相互作用することによってルールを受け入れたり拒否したりし得る。更なる他の例として、設定ページは、ルールの推奨される特徴を有効又は無効にするための、又は、そうでなければ推奨生成の振る舞いをカスタマイズするためのオプションを提供し得る。
【０１１７】
以下に説明される様々な操作が一般的な従来型のデザインであり得るコンピュータシステム上で実施され得、図１２は、本発明のある実施形態を実施するために用いることのできる代表的なサーバシステム１２００とクライアントコンピュータシステム１２１４との簡略化されたブロック図を示す。様々な実施形態において、サーバシステム１２００又は同様のシステムは、メッセージ管理サービス２００、メッセージングサービス２０４、又は他のサービス若しくは以下に記載される又はその一部であるサーバを実施し得る。クライアントコンピュータシステム１２１４又は同様のシステムは、クライアントデバイス２０２又は以下で説明される他のクライアントを実施し得る。
【０１１８】
サーバシステム１２００は、２つのモジュール１２０２が示されるが任意の数が提供され得る、多数のモジュール１２０２（例えばブレードサーバ実装におけるブレード）を組み込んだモジュールデザインを有し得る。各モジュール１２０２は（複数の）処理ユニット１２０４とローカルストレージ１２０６とを含み得る。
【０１１９】
（複数の）処理ユニット１２０４は、１つ以上のコアを有し得る単一のプロセッサ、又は複数のプロセッサを含み得る。ある実施形態では、（複数の）処理ユニット１２０４は、グラフィックスプロセッサ、デジタルシグナルプロセッサ等のような１つ以上の特定用途向けプロセッサだけでなく、汎用１次プロセッサをも含み得る。ある実施形態では、いくつか又は全ての処理ユニット１２０４は、特定用途向け集積回路（ＡＳＩＣｓ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡｓ）などのカスタマイズされた回路を用いて実装され得る。ある実施形態では、そのような集積回路は回路自体に格納された命令を実行する。他の実施形態では、（複数の）処理ユニット１２０４はローカルストレージ１２０６に格納された命令を実行し得る。任意の組み合わせにおける任意の種別のプロセッサは（複数の）処理ユニット１２０４に含まれ得る。
【０１２０】
ローカルストレージ１２０６は、揮発性の記録媒体（例えば従来型のＤＲＡＭ、ＳＲＡＭ、ＳＤＲＭ等）及び／又は不揮発性の記録媒体（例えば磁気又は光ディスク、フラッシュメモリ等）を含み得る。ローカルストレージ１２０６内に組み込まれた記録媒体は、要求通りに固定、取り外し可能、又は更新可能であり得る。ローカルストレージ１２０６は、システムメモリ、リードオンリーメモリ（ＲＯＭ）、永続的なストレージデバイスのような物理的又は論理的に分割された様々なサブユニットであり得る。システムメモリは、動的なランダムアクセスメモリのような、読み書きメモリデバイス、又は、揮発性の読み書きメモリであり得る。システムメモリは、（複数の）処理ユニット１２０４がランタイムにおいて必要とする、いくつかの又は全ての命令とデータとを格納し得る。ＲＯＭは、（複数の）処理ユニット１２０４によって必要とされる、静的なデータ及び命令を格納し得る。永続的なストレージデバイスは、モジュール１２０２が電源を切った状態である場合であっても命令とデータを格納し得る、不揮発性の読み書きメモリデバイスであり得る。ここで用いられる「記録媒体」の語は、データが永久に（上書き、電気的障害、停電等の影響をうける）格納され得る任意のメディアを含み、キャリア波及び、無線や有線で接続されて伝達される一時的な電気信号は含まない。
【０１２１】
ある実施形態では、ローカルストレージ１２０６は、図２のメッセージ管理モジュール２１２、メッセージングサービスインタフェース２１４、及び／又はクライアントインタフェース２１０、又は図１のメッセージングシステム１００に関連付けられた任意の他のサーバの機能などの、様々なサーバ機能を実施するオペレーティングシステム及び／又はプログラムなどの、（複数の）処理ユニット１２０４によって実行される１つ以上のソフトウェアプログラムを格納し得る。「ソフトウェア」は、一般に、（複数の）処理ユニット１２０４によって実行された場合にサーバシステム１２００（又はその一部）に様々な動作を実行させる一連の命令を指し、従って、ソフトウェアプログラムの動作を実行し動作させる１つ以上の特定の機械的な実装を定義する。命令は、読み出し専用メモリに存在するファームウェア、及び／又は、（複数の）処理ユニット１２０４による実行のために揮発性のワーキングメモリに読み出され得る、不揮発性記録媒体に格納されるプログラムコードとして格納され得る。ソフトウェアは、単一のプログラム又は別々のプログラムの集合、又は適切に相互作用するプログラムモジュールとして実装され得る。ローカルストレージ１２０６（又は上述した非ローカルストレージ）から、（複数の）処理ユニット１２０４は、上述した様々な動作を実行するために、実行するプログラム命令と処理するデータとを検索し得る。
【０１２２】
あるサーバシステム１２００では、複数のモジュール１２０２が、バスを介して、又は、モジュール１２０２とサーバシステム１２００の他のコンポーネントとの間の通信をサポートするローカル・エリア・ネットワークを形成する他の内部接続１２０８を介して相互に接続され得る。内部接続１２０８は、サーバラック、ハブ、ルータ等を含む様々な技術を用いて実装され得る。
【０１２３】
ワイド・エリア・ネットワーク（ＷＡＮ）インタフェース１２１０は、ローカル・エリア・ネットワーク（内部接続１２０８）と、インターネットの様なより大きなネットワークとの間のデータ通信能力を提供し得る。有線（例えば、イーサネット、ＩＥＥＥ８０２．３標準）及び／又は無線技術（例えば、Ｗｉ−Ｆｉ、ＩＥＥＥ８０２．１１標準）を含む、従来型の又は他の通信技術が用いられ得る。
【０１２４】
ある実施形態では、ローカルストレージ１２０６は、（複数の）処理ユニット１２０４に対するワーキングメモリを提供することが意図されており、内部接続１２０８のトラフィックを低減する一方で、処理されるべきプログラム及び／又はデータへの高速なアクセスを提供し得る。内部接続１２０８に接続し得る、１つ以上のマスストレージサブシステム１２１２によって、より多くの量のデータのためのストレージがローカル・エリア・ネットワーク上に提供され得る。マスストレージサブシステム１２１２は、磁気、光学、半導体又はその他のデータ記録媒体に基づき得る。ダイレクト・アタッチド・ストレージ、ストレージ・エリア・ネットワーク、ネットワーク・アタッチド・ストレージ等が使用され得る。任意のデータストア、又は、サービスやサーバによって生産され、消費され又は維持されるものとして以下で説明するデータの他のコレクションは、マスストレージサブシステム１２１２内に格納され得る。ある実施形態では、追加的なデータストレージリソースは、（潜在的にレイテンシーが増加する）ＷＡＮインタフェース１２１０を介してアクセス可能であり得る。
【０１２５】
サーバシステム１２００は、ＷＡＮインタフェース１２１０を介して受信したリクエストに応答して動作し得る。例えば、モジュール１２０２の１つは管理機能を実施し、受信したリクエストに応答して他のモジュール１２０２に別々のタスクをアサインし得る。従来型のワーク割り当て技術が使用され得る。リクエストが処理されると、結果はＷＡＮインタフェース１２１０を介してリクエスト元に返信され得る。このような動作は一般的に自動化され得る。更に、ある実施形態では、ＷＡＮインタフェース１２１０は、複数のサーバシステム１２００と互いに接続することができ、大量の動作を扱うことができるスケーラブルなシステムを提供する。サーバシステム及びサーバファーム（協調するサーバシステムの集合）を管理する従来型又は他の技術が使用され得、動的なリソースの割り当て及び再割り当てが組み込まれる。
【０１２６】
サーバシステム１２００は、インターネットなどのワイドエリアネットワークを介して、様々なユーザ所有の又はユーザが操作するデバイスと相互作用し得る。ユーザが操作するデバイスの例は、コンピューティングシステム１２１４として図１２に示されている。クライアントコンピューティングシステム１２１４は、例えば、スマートフォン、他のモバイル電話、タブレットコンピュータ、ウェアラブルコンピューティングデバイス（例えばスマートウォッチ、アイグラス）、デスクトップコンピュータ、ラップトップコンピュータ等のようなコンシューマデバイスとして実施され得る。
【０１２７】
例えば、クライアントコンピューティングシステム１２１４は、ＷＡＮインタフェース１２１０を介して通信し得る。クライアントコンピューティングシステム１２１４は、（複数の）処理ユニット１２１６、ストレージデバイス１２１８、ネットワークインタフェース１２２０、ユーザ入力デバイス１２２２、及びユーザ出力デバイス１２２４のような従来型のコンピュータコンポーネントを含み得る。クライアントコンピューティングシステム１２１４は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、他のモバイルコンピューティングデバイス、ウェアラブルコンピューティングデバイス等のような、様々なフォームファクタで実施されたコンピューティングデバイスであり得る。
【０１２８】
プロセッサ１２１６とストレージデバイス１２１８は、（複数の）処理ユニット１２０４と、上述したローカルストレージデバイス１２０６と同様であり得る。クライアントコンピューティングシステム１２１４に属すために、適切なデバイスが要求に基づいて選択され得、例えば、クライアントコンピューティングシステム１２１４は、処理能力が制限された「シン」クライアントとして、又は高電力のコンピューティングシステムとして実装され得る。クライアントコンピューティングシステム１２１４は、（複数の）処理ユニット１２１６によって実行されるプログラムコードを用いてセットアップされ、メッセージへアクセスすること、メッセージに対する行動を実行すること、及び他の相互作用など、メッセージ管理サービスのサーバシステム１２００との様々な相互作用が可能になり得る。あるクライアントコンピューティングシステム１２１４はまた、メッセージ管理サービスとは独立したメッセージングサービスと相互作用を行い得る。
【０１２９】
ネットワークインタフェース１２２０は、サーバシステム１２００のＷＡＮインタフェース１２１０も接続されているワイド・エリア・ネットワーク（例えばインターネット）との接続を提供し得る。様々な実施形態では、ネットワークインタフェース１２２０は有線インタフェース（例えばイーサネット）及び／又は、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ又は携帯データネットワーク標準（例えば３Ｇ、４Ｇ、ＬＴＥ等）のような様々なＲＦデータ通信標準を実施する無線インタフェースを含み得る。
【０１３０】
ユーザ入力デバイス１２２２は、ユーザがクライアントコンピューティングシステム１２１４へ信号を提供することができる任意のデバイス（複数のデバイス）を含み得、クライアントコンピューティングシステム１２１４は、当該信号を、特定のユーザのリクエスト又は情報を示すものとして解釈し得る。様々な実施形態において、ユーザ入力デバイス１２２２は、キーボード、タッチパッド、タッチスクリーン、マウス又は他のポインティングデバイス、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーバッド、マイクロフォン等の、いくつか又は全てを含み得る。
【０１３１】
ユーザ出力システム１２２４は、クライアントコンピューティングシステム１２１４がユーザに情報を提供することができる任意のデバイスを含み得る。例えば、ユーザ出力デバイス１２２４は、クライアントコンピューティングシステム１２１４によって生成された又はクライアントコンピューティングシステム１２１４に配信された画像を表示するためのディスプレイを含み得る。ディスプレイは様々な画像生成技術、例えば、液晶ディスプレイ（ＬＣＤ）、有機発光ダイオード（ＯＬＥＤ）を含む発光ダイオード（ＬＥＤ）、投影システム、ブラウン管（ＣＲＴ）などを、支援するエレクトロニクス（例えば、デジタル−アナログ又はアナログ−アナログ変換、信号プロセッサなど）と共に組み込み得る。ある実施形態は、入力及び出力デバイスの両方として機能するタッチスクリーンのようなデバイスを含み得る。ある実施形態では、ディスプレイに加えて若しくは代わりに、他のユーザ出力デバイス１２２４が提供され得る。例にはインジケータライト、スピーカ、触覚「ディスプレイ」装置、プリンタ等を含む。
【０１３２】
ある実施形態は、マイクロプロセッサ、ストレージ、及び、コンピュータで読み出し可能な記録媒体内のコンピュータプログラムの命令を格納するメモリのような電子部品を含む。本明細書において説明された多くの特徴は、コンピュータで読み出し可能な記録媒体上にエンコードされたプログラムの命令の組として特定されるプロセスとして実施され得る。これらのプログラムの命令が１つ以上のプロセッシングユニットによって実行される場合、これらのプログラムの命令は、プログラムの命令に示されている様々な動作を（複数の）プロセシングユニットに実行させる。プログラムの命令又はコンピュータコードの例は、コンパイラによって生成されたような機械コードと、コンピュータや電子部品やインタプリタを用いるマイクロプロセッサによって実行される、より高レベルなコードを含んだファイルとを含む。適切なプログラミングを通じて、（複数の）プロセッシングユニット１２０４と１２１６とは、サーバシステム１２００とクライアントコンピューティングシステム１２１４のための様々な機能を提供し得、様々な機能は、サーバ又はクライアントによって実行される機能として、又はメッセージ管理サービスに関連付けられた他の機能として、以下で説明される任意の機能を含む。
【０１３３】
システム１２００及びクライアントコンピューティングシステム１２１４が具体例であると共に変形例及び修正が可能であることが理解される。本発明の実施形態と関連して用いられるコンピューティングシステムは、特にここで説明されないときは他の機能を有し得る。更に、サーバシステム１２００とクライアントコンピューティングシステム１２１４とは特定のブロックを参照して説明されたが、これらのブロックは説明の便宜のために定義されたものであり、コンポーネント部分の特定の物理的な配置を暗示することを意図したものではないことが理解されるべきである。例えば、異なるブロックは、同一のサーバラック内や同一のファシリティ内、又は同一のマザーボード上に配置され得るが必須ではない。更に、ブロックは物理的に別々な部品に対応する必要はない。ブロックは、例えば、プロセッサをプログラムし又は適切な制御回路を提供することによって、様々な動作を実行するように構成され得、そして、様々なブロックは、どのような初期設定が与えられるかに応じて再構成されたり再構成されなかったりし得る。本発明の実施形態は、回路とソフトウェアの任意の組み合わせを用いて実施される電子デバイスを含む、様々な装置で実現され得る。
【０１３４】
本発明が特定の実施形態に関して説明されたが、当業者は多数の変形が可能であることを理解する。例えば、（トリガをかける条件及び／又は結果として生じる行動を含む）ルールと、推奨されるルールを生成する処理の特定の例とが説明されたが、他のルールと処理とが実施され得る。本発明の実施形態は、ここで説明された特定の例に限定されたものだけでなく、様々なコンピュータシステムと通信技術とを用いて実現され得る。
【０１３５】
本発明の実施形態は、専用の部品及び／又はプログラム可能なプロセッサ及び／又は他のプログラム可能なデバイスの任意の組み合わせを用いて実現され得る。ここで説明された様々な処理は、同一のプロセッサ又は任意の組み合わせにおける異なるプロセッサ上で実施され得る。部品がある動作を実行するように構成されているとして説明された場合、このような構成は、例えば、その動作を実行するように電子回路を設計することにより、その動作を実行するようにプログラム可能な（マイクロプロセッサのような）電子回路をプログラムすることにより、又はこれらの任意の組み合わせにより、達成され得る。更に、上述の実施形態が特定のハードウェアとソフトウェアコンポーネントとを参照し得るが、当業者は、ハードウェア及び／又はソフトウェアコンポーネントの異なる組み合わせも用いられること、及び、ハードウェアに実装されるものとして説明された特定の動作もソフトウェアで実施され得る又はその逆もあることを理解する。
【０１３６】
本発明の様々な特徴が組み込まれたコンピュータプログラムは、エンコードされて様々なコンピュータで読み出し可能な記録媒体に格納されてもよく、適切な媒体は磁気ディスク又はテープ、コンパクトディスク（ＣＤ）又はＤＶＤ（デジタル多用途ディスク）のような光学的記録媒体、フラッシュメモリ、及び他の不揮発性の媒体を含む。プログラムコードとともにエンコードされたコンピュータで読み書き可能な媒体は、互換性のある電子デバイスとパッケージ化され得、又は、プログラムコードは、電子デバイスとは別々に（例えば、インターネットのダウンロードを介して、又は、パッケージ化されたコンピュータで読み出し可能な記録媒体とは別なものとして）提供され得る。
【０１３７】
従って、本発明は特定の実施形態に関して説明されたが、本発明は以下の請求項の範囲内にある全ての変形及び均等な構成を包含することが意図されていることが理解される。
【図１】
2017514332.tif 000003
【図２】
2017514332.tif 000004
【図３】
2017514332.tif 000005
【図４Ａ】
2017514332.tif 000006
【図４Ｂ】
2017514332.tif 000007
【図４Ｃ】
2017514332.tif 000008
【図５Ａ】
2017514332.tif 000009
【図５Ｂ】
2017514332.tif 000010
【図５Ｃ】
2017514332.tif 000011
【図６】
2017514332.tif 000012
【図７】
2017514332.tif 000013
【図８】
2017514332.tif 000014
【図９】
2017514332.tif 000015
【図１０】
2017514332.tif 000016
【図１１】
2017514332.tif 000017
【図１２】
2017514332.tif 000018
【手続補正書】
【提出日】平成28年9月30日(2016.9.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータで実行される方法であって、
メッセージ管理サービスにおいて、ユーザに対する複数のメッセージを受信することであって、前記複数のメッセージは、複数のメッセージサービスプロバイダのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージを含む、前記受信することと、
前記メッセージ管理サービスにより、前記ユーザに対する複数のイベント記録であって、各イベント記録が前記複数のメッセージの異なる１つにおけるメッセージの特徴の組と前記メッセージに対して前記ユーザがとった行動を示すイベント情報とを含む、前記複数のイベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づく第１のトリガをかける条件と、前記第１のトリガをかける条件を満たすメッセージの少なくとも最小の断片に対してユーザがとる、結果として生じる第１の行動との間の相関を検出することであって、結果として生じる前記第１の行動は、前記第１のトリガをかける条件を満たすメッセージを、前記ユーザが特定の場所に存在するまで後回しにすることを含む、前記検出することと、
前記メッセージ管理サービスにより、前記分析に基づき、前記第１のトリガをかける条件を満たす将来のメッセージに対して前記結果として生じる第１の行動を自動的に実行するために、第１の推奨されるルールを生成することと、
前記メッセージ管理サービスにより、前記ユーザに関連付けられたクライアントデバイスから、前記第１の推奨されるルールが受け入れられることのユーザの確認を取得することと、
前記ユーザの確認に応答して、前記メッセージ管理サービスにより、前記第１の推奨されるルールを、前記ユーザのために受信されるメッセージに自動的に適用される成立したルールの組に追加することと、
を含む、コンピュータで実行される方法。
【請求項２】
前記ユーザの確認を取得することは、
前記第１の推奨されるルールを生成した後に、前記複数のメッセージングサービスの１つから、前記第１の推奨されるルールを適用する前記ユーザに対する候補のメッセージを受信することと、
前記候補のメッセージを、前記第１の推奨されるルールを記述する推奨メタデータと共に前記クライアントデバイスへ配信することと、
前記クライアントデバイスから前記ユーザの確認を受信することと、
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項３】
前記ユーザに対する新たなメッセージを、第１の前記複数のメッセージングサービスの１つから受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、前記新たなメッセージに対して、前記適用可能なルールによって定義された結果として生じる行動を自動的に実行することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項４】
前記結果として生じる行動を自動的に実行することは、前記第１の前記メッセージングサービスの１つへ更新命令を送信することを含む、請求項３に記載のコンピュータで実行される方法。
【請求項５】
新たなメッセージを受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、
前記新たなメッセージに対して、クライアントデバイスが前記適用可能なルールによって定義される結果として生じる行動を実行することを示す、行動メタデータを追加することと、
前記行動メタデータを含む前記新たなメッセージを、前記クライアントデバイスへ配信することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項６】
前記結果として生じる行動は、前記新たなメッセージから転送されるメッセージを生成することと、前記転送されるメッセージを、送信されるべき前記ユーザに提示することと、を含む、請求項５に記載のコンピュータで実行される方法。
【請求項７】
第２のトリガをかける条件を満たす将来のメッセージに対して、第２の結果として生じる行動を自動的に実行するために、第２の推奨されるルールを生成することと、
前記第２の推奨されるルールを拒否するユーザ指示を取得することと、
前記ユーザ指示に応答して、前記第２の推奨されるルールを抑制することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項８】
システムであって、
ユーザによって操作可能なクライアントデバイスと通信するように構成されたクライアントインタフェースと、
前記ユーザに対するメッセージを受信するように構成されたメッセージングサービスインタフェースであって、前記複数のメッセージは、複数のメッセージサービスのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージを含む、前記メッセージングサービスインタフェースと、
前記クライアントインタフェースと前記メッセージングサービスインタフェースとに接続された複数のメッセージ管理モジュールであって、前記複数のメッセージ管理モジュールは、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージに、成立したルールの組を適用するように構成されたフィルタモジュールと、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージと前記クライアントインタフェースを介して受信したイベント情報とに基づいて、イベント記録を生成するように構成されたイベントレコーダであって、各イベント記録がメッセージにおけるメッセージの特徴の組と前記メッセージに対する前記ユーザによってなされた行動を示すイベント情報とを含む、前記イベントレコーダと、
前記イベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づくトリガをかける条件と、前記トリガをかける条件を満たすメッセージの少なくとも最小の断片に対して前記ユーザがとる、結果として生じる行動と、の間の相関を検出し、前記相関に基づいて、前記トリガをかける条件を満たす将来のメッセージにおいて前記結果として生じる行動を自動的に実行するための推奨されるルールを生成するように構成されたパターンディテクタであって、前記結果として生じる行動は、前記トリガをかける条件を満たすメッセージを、前記ユーザが複数のクライアントデバイスの特定の１つを使用するまで後回しにすることを含む、前記パターンディテクタと、を含み、
前記フィルタモジュールは、更に、前記推奨されるルールを、前記クライアントインタフェースを介して前記クライアントデバイスに通信し、前記クライアントインタフェースを介して前記クライアントデバイスから受信した応答に基づいて、前記推奨されるルールを前記成立したルールの組に追加するように構成される、システム。
【請求項９】
各メッセージに対する前記メッセージの特徴の組は、前記メッセージを受信した前記メッセージングサービスの前記１つを特定するメッセージングサービス識別子を含む、請求項８に記載のシステム。
【請求項１０】
前記トリガをかける条件は、前記メッセージングサービス識別子に少なくとも部分的に基づく、請求項９に記載のシステム。
【請求項１１】
前記クライアントインタフェースを介して受信した前記イベント情報は、前記ユーザによってとられた前記行動に関連するクライアントのコンテクスト情報を更に含む、請求項９に記載のシステム。
【請求項１２】
前記クライアントのコンテクスト情報は、クライアントデバイスの種別、前記行動がとられた時間、又は前記行動がとられた際の前記クライアントデバイスの位置の少なくとも１つを特定する情報を含む、請求項１１に記載のシステム。
【請求項１３】
前記トリガをかける条件は、前記メッセージの特徴と前記クライアントのコンテクスト情報の要素の１つに少なくとも部分的に基づいている、請求項９に記載のシステム。
【請求項１４】
コンピュータで実行される方法であって、
クライアントデバイスにおいて、新たなメッセージと前記新たなメッセージに対する推奨メタデータとを、メッセージ管理サービスから受信することであって、前記推奨メタデータは、トリガをかける条件と、前記メッセージに適用される推奨されるルールに対する、結果として生じる行動とを含み、前記結果として生じる行動は前記トリガをかける条件を満たすメッセージを、前記ユーザが特定の場所に存在するまで後回しにすることを含む、前記受信することと、
前記新たなメッセージを、前記クライアントデバイスのユーザインタフェースに提示することと、
前記新たなメッセージとのユーザの相互作用を示すユーザ入力を、前記ユーザインタフェースを介して受け取ることと、
前記ユーザインタフェースにおいて、前記推奨されるルールを受け入れるためのプロンプトを前記ユーザに提示することと、
前記ユーザインタフェースを介して、前記プロンプトに対する応答を受け取ることと、
前記プロンプトに対する前記応答を含むイベント情報を、前記メッセージ管理サービスへ送信することと、を含み、
前記ユーザが前記推奨されるルールを受け入れたことに応答して、前記メッセージ管理サービスはその後、複数のメッセージングサービスのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージに前記推奨されるルールを適用する、
コンピュータで実行される方法。
【請求項１５】
前記イベント情報は更に、前記示された行動の識別子を含む、請求項１４に記載のコンピュータで実行される方法。
【請求項１６】
前記新たなメッセージを提示することは、前記新たなメッセージの表現と、推奨されるルールが前記メッセージに適用されることの視覚的指標とを表示することを含む、請求項１４に記載のコンピュータで実行される方法。
【請求項１７】
前記視覚的指標は、前記推奨されるルールの前記トリガをかける条件を識別するための視覚的な要素を含む、請求項１６に記載のコンピュータで実行される方法。
【請求項１８】
前記視覚的指標は、前記推奨されるルールの前記結果として生じる行動を識別するための視覚的な要素を含む、請求項１６に記載のコンピュータで実行される方法。
【請求項１９】
前記ユーザ入力は、前記新たなメッセージに対してなされる行動を示し、前記プロンプトは、前記示された行動が前記推奨されるルールの前記結果として生じる行動と一致することが、前記クライアントデバイスによって判定された結果に応じて表示される、請求項１４に記載のコンピュータで実行される方法。
【手続補正書】
【提出日】平成28年10月12日(2016.10.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータで実行される方法であって、
メッセージ管理サービスにおいて、ユーザに対する複数のメッセージを受信することであって、前記複数のメッセージは、複数のメッセージサービスプロバイダのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージを含む、前記受信することと、
前記メッセージ管理サービスにより、前記ユーザに対する複数のイベント記録であって、各イベント記録が前記複数のメッセージの異なる１つにおけるメッセージの特徴の組と前記メッセージに対して前記ユーザがとった行動を示すイベント情報とを含む、前記複数のイベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づく第１のトリガをかける条件と、前記第１のトリガをかける条件を満たすメッセージの少なくとも最小の断片に対してユーザがとる、結果として生じる第１の行動との間の相関を検出することであって、結果として生じる前記第１の行動は、前記第１のトリガをかける条件を満たすメッセージを、前記ユーザが特定の場所に存在するまで後回しにすることを含む、前記検出することと、
前記メッセージ管理サービスにより、前記分析に基づき、前記第１のトリガをかける条件を満たす将来のメッセージに対して前記結果として生じる第１の行動を自動的に実行するために、第１の推奨されるルールを生成することと、
前記メッセージ管理サービスにより、前記ユーザに関連付けられたクライアントデバイスから、前記第１の推奨されるルールが受け入れられることのユーザの確認を取得することと、
前記ユーザの確認に応答して、前記メッセージ管理サービスにより、前記第１の推奨されるルールを、前記ユーザのために受信されるメッセージに自動的に適用される成立したルールの組に追加することと、
を含む、コンピュータで実行される方法。
【請求項２】
前記ユーザの確認を取得することは、
前記第１の推奨されるルールを生成した後に、前記複数のメッセージングサービスの１つから、前記第１の推奨されるルールを適用する前記ユーザに対する候補のメッセージを受信することと、
前記候補のメッセージを、前記第１の推奨されるルールを記述する推奨メタデータと共に前記クライアントデバイスへ配信することと、
前記クライアントデバイスから前記ユーザの確認を受信することと、
を含む、請求項１に記載のコンピュータで実行される方法。
【請求項３】
前記ユーザに対する新たなメッセージを、第１の前記複数のメッセージングサービスの１つから受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、前記新たなメッセージに対して、前記適用可能なルールによって定義された結果として生じる行動を自動的に実行することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項４】
前記結果として生じる行動を自動的に実行することは、前記第１の前記メッセージングサービスの１つへ更新命令を送信することを含む、請求項３に記載のコンピュータで実行される方法。
【請求項５】
新たなメッセージを受信することと、
前記成立したルールの組のうちの、該ルールにおけるそれぞれのトリガをかける条件に基づいて、前記成立したルールの組が、前記新たなメッセージに適用する適用可能なルールを含むかを判定することと、
前記成立したルールの組が適用可能なルールを含む場合、
前記新たなメッセージに対して、クライアントデバイスが前記適用可能なルールによって定義される結果として生じる行動を実行することを示す、行動メタデータを追加することと、
前記行動メタデータを含む前記新たなメッセージを、前記クライアントデバイスへ配信することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項６】
前記結果として生じる行動は、前記新たなメッセージから転送されるメッセージを生成することと、前記転送されるメッセージを、送信されるべき前記ユーザに提示することと、を含む、請求項５に記載のコンピュータで実行される方法。
【請求項７】
第２のトリガをかける条件を満たす将来のメッセージに対して、第２の結果として生じる行動を自動的に実行するために、第２の推奨されるルールを生成することと、
前記第２の推奨されるルールを拒否するユーザ指示を取得することと、
前記ユーザ指示に応答して、前記第２の推奨されるルールを抑制することと、
を更に含む、請求項１に記載のコンピュータで実行される方法。
【請求項８】
システムであって、
ユーザによって操作可能なクライアントデバイスと通信するように構成されたクライアントインタフェースと、
前記ユーザに対するメッセージを受信するように構成されたメッセージングサービスインタフェースであって、前記複数のメッセージは、複数のメッセージングサービスのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージを含む、前記メッセージングサービスインタフェースと、
前記クライアントインタフェースと前記メッセージングサービスインタフェースとに接続された複数のメッセージ管理モジュールであって、前記複数のメッセージ管理モジュールは、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージに、成立したルールの組を適用するように構成されたフィルタモジュールと、
前記メッセージングサービスインタフェースを介して受信した前記ユーザのためのメッセージと前記クライアントインタフェースを介して受信したイベント情報とに基づいて、イベント記録を生成するように構成されたイベントレコーダであって、各イベント記録がメッセージにおけるメッセージの特徴の組と前記メッセージに対する前記ユーザによってなされた行動を示すイベント情報とを含む、前記イベントレコーダと、
前記イベント記録を分析して、前記メッセージの特徴の１つに少なくとも部分的に基づくトリガをかける条件と、前記トリガをかける条件を満たすメッセージの少なくとも最小の断片に対して前記ユーザがとる、結果として生じる行動と、の間の相関を検出し、前記相関に基づいて、前記トリガをかける条件を満たす将来のメッセージにおいて前記結果として生じる行動を自動的に実行するための推奨されるルールを生成するように構成されたパターンディテクタであって、前記結果として生じる行動は、前記トリガをかける条件を満たすメッセージを、前記ユーザが複数のクライアントデバイスの特定の１つを使用するまで後回しにすることを含む、前記パターンディテクタと、を含み、
前記フィルタモジュールは、更に、前記推奨されるルールを、前記クライアントインタフェースを介して前記クライアントデバイスに通信し、前記クライアントインタフェースを介して前記クライアントデバイスから受信した応答に基づいて、前記推奨されるルールを前記成立したルールの組に追加するように構成される、システム。
【請求項９】
各メッセージに対する前記メッセージの特徴の組は、前記メッセージを受信した前記メッセージングサービスの前記１つを特定するメッセージングサービス識別子を含む、請求項８に記載のシステム。
【請求項１０】
前記トリガをかける条件は、前記メッセージングサービス識別子に少なくとも部分的に基づく、請求項９に記載のシステム。
【請求項１１】
前記クライアントインタフェースを介して受信した前記イベント情報は、前記ユーザによってとられた前記行動に関連するクライアントのコンテクスト情報を更に含む、請求項９に記載のシステム。
【請求項１２】
前記クライアントのコンテクスト情報は、クライアントデバイスの種別、前記行動がとられた時間、又は前記行動がとられた際の前記クライアントデバイスの位置の少なくとも１つを特定する情報を含む、請求項１１に記載のシステム。
【請求項１３】
前記トリガをかける条件は、前記メッセージの特徴と前記クライアントのコンテクスト情報の要素の１つに少なくとも部分的に基づいている、請求項１１に記載のシステム。
【請求項１４】
コンピュータで実行される方法であって、
クライアントデバイスにおいて、新たなメッセージと前記新たなメッセージに対する推奨メタデータとを、メッセージ管理サービスから受信することであって、前記推奨メタデータは、トリガをかける条件と、前記メッセージに適用される推奨されるルールに対する、結果として生じる行動とを含み、前記結果として生じる行動は前記トリガをかける条件を満たすメッセージを、前記ユーザが特定の場所に存在するまで後回しにすることを含む、前記受信することと、
前記新たなメッセージを、前記クライアントデバイスのユーザインタフェースに提示することと、
前記新たなメッセージとのユーザの相互作用を示すユーザ入力を、前記ユーザインタフェースを介して受け取ることと、
前記ユーザインタフェースにおいて、前記推奨されるルールを受け入れるためのプロンプトを前記ユーザに提示することと、
前記ユーザインタフェースを介して、前記プロンプトに対する応答を受け取ることと、
前記プロンプトに対する前記応答を含むイベント情報を、前記メッセージ管理サービスへ送信することと、を含み、
前記ユーザが前記推奨されるルールを受け入れたことに応答して、前記メッセージ管理サービスはその後、複数のメッセージングサービスのそれぞれによって維持される個別のユーザアカウントにおいて前記ユーザのために受信されるメッセージに前記推奨されるルールを適用する、
コンピュータで実行される方法。
【請求項１５】
前記イベント情報は更に、前記示された行動の識別子を含む、請求項１４に記載のコンピュータで実行される方法。
【請求項１６】
前記新たなメッセージを提示することは、前記新たなメッセージの表現と、推奨されるルールが前記メッセージに適用されることの視覚的指標とを表示することを含む、請求項１４に記載のコンピュータで実行される方法。
【請求項１７】
前記視覚的指標は、前記推奨されるルールの前記トリガをかける条件を識別するための視覚的な要素を含む、請求項１６に記載のコンピュータで実行される方法。
【請求項１８】
前記視覚的指標は、前記推奨されるルールの前記結果として生じる行動を識別するための視覚的な要素を含む、請求項１６に記載のコンピュータで実行される方法。
【請求項１９】
前記ユーザ入力は、前記新たなメッセージに対してなされる行動を示し、前記プロンプトは、前記示された行動が前記推奨されるルールの前記結果として生じる行動と一致することが、前記クライアントデバイスによって判定された結果に応じて表示される、請求項１４に記載のコンピュータで実行される方法。
【国際調査報告】
2017514332.tif 000019