JP2023505983A - エンドツーエンド電子メールタグ予測 - Google Patents

Abstract

システムは、電子メールメッセージの自動エンドツーエンドタグ付けを提供する。メッセージが送信側電子メールクライアントで作成されている間に、サーバは、予測モデルへの入力として使用される電子メール情報を受信することができる。このモデルは、電子メールメッセージに適用される、特定のユーザグループまたは電子メールリストに使用可能なタグを識別する。これらの予測タグは電子メールクライアントに返送され、タグは、ユーザによって定められた他のタグとともに電子メールに埋め込まれてもよい。メッセージが電子メールサーバを通して送られると、システムは、予測タグに対して行われた任意の変更を用いてモデルを再訓練することができる。メッセージが第２の電子メールクライアントで受信されると、受信側はタグをさらに編集することができ、任意の変更を再び用いてモデルを再訓練することができる。

Description

背景
現代のインターネットおよびネットワーク通信は、過去２０年にわたって指数関数的に増加した。現在、組織のメンバーは、電子メール、インスタントメッセージング、テキストメッセージング、会話チャネル、ソーシャルメディアおよび／またはそれに類似するものを含むいくつかの異なる並列通信チャネルを通して瞬時に通信することができる。この通信は、情報のアクセシビリティの増加、ならびに分散した従業員間での前例のないレベルの協働およびチームワークをもたらした。対面での会議の大部分が、多くの場合より効率的で簡潔で効果的である電子通信に置き換えられた。

さまざまな通信手段が出現し続けているにもかかわらず、ビジネス通信の主な方法は、組織内の電子メール（ｅメール）のままである。インスタント電子メール通信の結果生産性が向上したにもかかわらず、そうでなければなされ得る改善を制限するいくつかの問題が残っている。具体的には、組織内の電子メール量の増加に伴い、ユーザは、毎日発生する大量の電子メール通信を開く、読む、ファイリングする、アドレス指定する、そうでなければ処理することに、ますます多くの時間を費やすことが求められる可能性がある。たとえグループプロジェクトに参加している少数のメンバーのような特定の組織に限定される場合であっても、日々受信される電子メールの膨大な量は、直ちに情報の過負荷につながる可能性がある。

過去、電子メールを受信したユーザは、この殺到した電子メール通信を整理して少なくしようという試みにおいて、いくつかの技術を使用した。たとえば、ある電子メールクライアントは、ユーザが、受信した電子メールをさまざまなフォルダに分類できるようにする。また、ある電子メールクライアントは、特定のトピックに従って電子メールを分類するために手動で割り当てられる静的ラベルまたはタグを使用している。以前のある解決策は、電子メールが受信されるときに電子メールの件名または本文内の単語の連続に基づいて電子メールを自動的に分類する規則を設定するために、論理式を使用した。しかしながら、これらの解決策の各々は、組織全体において一貫した方法で電子メールを自動的に分類しておらず、電子メール送信者から電子メール受信者にエンドツーエンド方式でタグを適用していない。その結果、組織内の受信ボックスの各々に対して異なるカテゴリ割り当てが手動で行われることになる。

概要
システムは、電子メールメッセージの自動エンドツーエンドタグ付けを提供する。メッセージが送信側電子メールクライアントで作成されている間に、サーバは、予測モデルへの入力として使用される電子メール情報を受信することができる。このモデルは、電子メールメッセージに適用される、特定のユーザグループまたは電子メールリストに使用可能なタグを識別する。これらの予測タグは電子メールクライアントに返送され、タグは、ユーザによって定められた他のタグとともに電子メールに埋め込まれてもよい。メッセージが電子メールサーバを通して送られると、システムは、予測タグに対して行われた任意の変更を用いてモデルを再訓練することができる。メッセージが第２の電子メールクライアントで受信されると、受信側はタグをさらに編集することができ、任意の変更を再び用いてモデルを再訓練することができる。

電子メールメッセージが送信側電子メールクライアントで起案されると、予測タグのセットがシステムから要求されてもよい。電子メールメッセージは、メーリングリストまたは他の組織グループ等のユーザグループに関連付けられてもよく、このグループは、時間の経過に伴いグループメッセージとともに発展する、自身の使用可能なタグのセットを有していてもよい。システムは、使用可能なタグの各々に対応する出力を有するモデルへの入力として、電子メール情報（たとえば本文、件名、電子メール受信者など）を使用することができる。モデルは、各タグのスコアを生成してもよく、しきい値を使用して、グループの使用可能なタグから、予測タグのセットを選択してもよい。送信側電子メールクライアントは、予測タグを、標題、受信者リストなどとともにユーザインターフェイスに表示してもよい。次に、ユーザは、予測タグを編集し、予測タグを選択し、予測タグを非選択とし、および／または新規ユーザタグを追加してもよい。新規タグを追加するとき、システムは、タイプされたプレフィックスを、予測タグとして提供されなかった使用可能なタグと適合させるオートコンプリート機能を提供してもよい。

電子メールメッセージが送信されるとき、選択された／非選択の／ユーザタグは、電子メールメッセージとともに送信されてもよい。たとえば、タグは、電子メールメッセージのヘッダに埋め込まれてもよい。メッセージが電子メールサーバによって受信されると、システムは、モデルを使用して電子メールのタグを再び分析してもよい。予測タグが選択／提供されなかった場合、システムは、電子メールサーバにおいて予測タグのセットを生成するために電子メール情報を使用してもよい。次に、これらの予測タグは、受信側電子メールクライアントに転送される前に電子メールに追加されてもよい。新規タグがユーザによって追加された場合、または既存タグがユーザによって編集された場合、モデルは、次に、訓練ペアとして電子メール情報および変更されたタグを使用して再訓練されてもよい。

電子メールが受信側電子メールクライアントによって受信されると、受信側ユーザは、電子メールメッセージとともに受信されたタグを編集、追加、および／または削除するために、ユーザインターフェイスを再び使用してもよい。これらの編集が完了すると、システムは、受信側ユーザによって行われた任意の変更を再び使用して、タグ予測モデルのための新たな訓練セットを生成してもよい。これは、タグを、電子メールメッセージのライフサイクルの開始から終了まで、割り当てる、伝播する、および／または編集することを可能にする。送信者および／または受信者は、電子メールの分類をグループ内で標準化することができるように、タグの共通セットを使用することができる。また、電子メールを送信するために訓練され利用されるタグ予測モデルは、Ｓｌａｃｋ（登録商標）チャネル、ソーシャルメディアフィード、インスタントメッセージングなどのような追加の通信チャネルにおいてメッセージにタグ付けするために使用されてもよい。

タグ予測モデルのいくつかの実装形態は、電子メール情報を使用してポピュレートされる単語埋め込み行列を生成してもよい。異なるウィンドウサイズを有するいくつかの異なる畳み込みフィルタの各々が、単語埋め込み行列の列に対して実行されてもよい。畳み込みフィルタからの結果に対し、結果ベクトルをポピュレートするために最大値プーリング演算が行われてもよい。モデルは、これも単語埋め込み行列を使用する並列演算セットをさらに含んでいてもよい。アテンション行列が単語埋め込み行列から生成されてもよく、別の最大値プーリング演算を使用して、特定のタグを入力テキストの部分に関連付けてもよい。結果として得られたアテンションベクトルを、単語埋め込み行列を転置したもので乗算することにより、第２の結果ベクトルを生成することができる。次に、この２つの結果ベクトルを完全連結層として組み合わせることにより、使用可能なタグの各々の最終スコアを提供することができる。

さまざまな実施形態の性質および利点の一層の理解は、本明細書の残りの部分および図面を参照することによって得られ、いくつかの図面における同様の参照番号は同様の構成要素を示すために使用される。場合によっては、サブラベルが参照番号に関連付けられて複数の同様の構成要素のうちの１つを示す。既存のサブラベルを指定することなく参照番号に言及される場合、そのような複数の同様の構成要素のすべてを示すことが意図されている。

いくつかの実施形態に係る、動的タグ予測を実現するためのシステムアーキテクチャを示す図である。 いくつかの実施形態に係る、送信側クライアントデバイスにおける電子メールクライアントの一部であってもよいユーザインターフェイスを示す。 いくつかの実施形態に係る、新規タグを追加し既存タグを削除するためにユーザインターフェイスが如何にして使用され得るかを示す図である。 いくつかの実施形態に係る、タグ２０２のリスト対してユーザ変更が行われた後のユーザインターフェイスを示す図である。 いくつかの実施形態に係る、タグを特定のテキスト選択に適用するためにユーザインターフェイスが如何にして使用され得るかを示す図である。 いくつかの実施形態に係る、ユーザによる編集のための予測タグのセットを表示するために電子メールクライアントによって実行されるプロセスのフローチャートを示す図である。 いくつかの実施形態に係る、使用可能なタグのセットから予測タグのセットを生成するためにタグ予測サーバによって実行される動作の機能図を示す。 いくつかの実施形態に係る、電子メールメッセージが電子メールサーバを通して送信されるときに電子メールメッセージ内のタグを処理するための方法のフローチャートを示す図である。 いくつかの実施形態に係る、受信側クライアントデバイスを使用してタグとやり取りするための方法のフローチャートを示す図である。 いくつかの実施形態に係る、受信側電子メールクライアントにおいて実現されるユーザインターフェイスを示す図である。 いくつかの実施形態に係る、タグのセットを修正するためにユーザインターフェイスが如何にして使用され得るかを示す図である。 いくつかの実施形態に係る、電子メールメッセージ内の特定のタグに関連する特定のテキストを閲覧するためにユーザインターフェイスが如何にして使用され得るかを示す図である。 いくつかの実施形態に係る、如何にしてタグ予測モデルが入力電子メール情報に基づいて使用可能なタグの信頼度スコアのセットを生成するかを示す図である。 いくつかの実施形態に係る、使用可能なタグの信頼度スコアを生成するためにタグ予測モデルによって実行される第２の演算を示す図である。 いくつかの実施形態に係る、如何にして、タグ予測モデルによって実行された２つの演算から得られたベクトルを組み合わせて最終結果セットにできるかを示す図である。 いくつかの実施形態に係る、追加の通信チャネルを含む拡張されたシステムアーキテクチャを示す図である。 いくつかの実施形態に係る、電子メールシステムを通して電子メールが送受信される際に電子メールにタグ付けする方法を示す図である。 実施形態のうちのいくつかを実現するための分散型システムの簡略化されたブロック図を示す図である。 ある実施形態のシステムの構成要素が提供するサービスをクラウドサービスとして提供し得るシステム環境の構成要素の簡略化されたブロック図を示す図である。 各種実施形態を実現し得る具体例としてのコンピュータシステムを示す図である。

詳細な説明
本明細書では、電子メールおよびその他の通信チャネルのための協調電子メールタグ予測モジュールを実現するための実施形態について説明する。中央サーバは、システムに提供された入力セットに基づいてタグを予測することを学習する機械学習モデルを含み得る。入力セットは、電子メールのテキストまたは本文、電子メールの件名、電子メールの添付物、電子メールの送信者／受信者のアイデンティティ等の電子メール情報を含み得る。この入力テキストは、メーリングリストまたはグループメンバーシップ等の情報とともに分析されてもよい。この情報は、メッセージを既存のグループまたは組織に分類するために使用されてもよい。このグループまたは組織は、組織内で送信されたメッセージを分類するために使用できる組織タグの既存のセットを有していてもよい。メッセージは、その内容によって識別され、特定のグループに分類することができる。たとえば、電子メールで送信されるメッセージは、ＳＬＡＣＫ（登録商標）チャネル、ソーシャルメディアスレッド、インスタントメッセージング会話などを通して送信されるメッセージとグループ化することができる。タグ予測プロセスは、各グループまたはサブグループに固有のモデルを使用してもよく、モデルは、予め定められたタグリストを精緻化し各メッセージに関連するタグを予測するように、連続的に訓練されてもよい。これらのタグは、メッセージが最初に作成されているときにユーザに自動的に提供されてもよい。そうすると、ユーザは、提案されたタグリストを追加、削除、または修正するオプションを有することができる。タグ予測プロセスは、ユーザがそのような編集を行っているときに、組織のためのタグの予め定められたリストからのオートコンプリート予測を提供してもよい。ユーザ編集の完了後、変更を使用することにより、モデルを、組織内で時間の経過に伴いユーザ基本設定とともに継続的に発展するように、さらに訓練することができる。電子メールが送信されると、サーバは、タグを分析し予測されたものとユーザによって実際に使用されたものとの間の何らかの相違を識別することができる。最後に、電子メールメッセージが受信されると、受信側ユーザが、メッセージ内のタグを追加、削除、および／または修正してもよく、これらの変更は、再びモデルをさらに訓練するために使用することができる。

図１は、いくつかの実施形態に係る、動的タグ予測を実現するためのシステムアーキテクチャ１００を示す。本明細書に記載されるシステムは、メッセージが送信者において作成される際、メッセージが送信者と受信者との間で送信されるとき、および、メッセージが受信者によって読み出され受信される際に、タグを予測および／または精緻化することができる、「エンドツーエンド」タグ予測システムとして、分類されてもよい。これは、送信者または受信者において排他的に使用されるタグまたはその他の分類方法を提供する既存のシステムと対比させることができる。たとえば、本開示に先立ち、ある電子メールクライアントは、ユーザが、その電子メールを、受信された際に分類またはタグ付けすることを可能にした。しかしながら、メッセージが送信者において作成されているときにタグが自動的に提案されることを可能にするメカニズム、特定の組織またはユーザグループに固有のタグを予測するメカニズム、および、ある組織全体で送信されるメッセージに対して均一となるようにタグを送信者から受信者に伝搬させるメカニズムは、存在しなかった。

以下でさらに説明されるように、本明細書に記載される方法およびシステムは、任意の通信チャネルに適用されてもよい。より具体的には、本明細書に記載される方法およびシステムは、タグを通信チャネル間で通信互換性の有無に関係なく共有し得るように、複数の種類の通信チャネルに適用され得るものである。本開示全体にわたり、電子メールメッセージは、電子メールサーバを通して送られるメッセージを送信者および受信者の電子メールクライアントが作成する特定の例として、使用されてもよい。タグ予測サーバは、メッセージが作成され、読み出され、および／または電子メールサーバを通して送信されるときに、メッセージを監視して、タグ予測／提案を行い、グループのモデルを継続的に訓練／精緻化することができる。しかしながら、電子メールメッセージ、電子メールクライアント、および電子メールサーバの使用は、例示のために提供されているだけであって、限定することを意図しない。他の実施形態は、任意の種類の通信チャネルを自由に使用してもよい。

システムアーキテクチャ１００は、送信側クライアントデバイス１０２と呼ばれるクライアントデバイスを含み得る。送信側クライアントデバイス１０２は、限定されないが、スマートフォン、デジタルアシスタント、ラップトップコンピュータ、デスクトップコンピュータ、タブレットコンピュータ、スマートホームデバイス、仮想／拡張現実デバイスなどを含む、電子メッセージを送信することが可能な任意のデジタルデバイスを含み得る。送信側クライアントデバイス１０２は、メッセージを送信／受信し、メッセージの作成、読出、編集、格納、分類などをそれを通して行うことができるユーザインターフェイスを提供する、ソフトウェアプロセスを含む電子メールクライアント１０４を含み得る。電子メールクライアント１０４は、スマートフォン上で動作するスタンドアロンアプリケーション（たとえば「ａｐｐ」）、ならびに、デスクトップコンピュータ上で動作するアプリケーション、ブラウザベースのアプリケーション、および／または任意の他のソフトウェアプロセスであってもよい。

システムアーキテクチャ１００は、受信側クライアントデバイス１０８も含み得る。受信側クライアントデバイス１０８も、電子メールクライアント１１０を含み得る。受信側クライアントデバイス１０８および／または電子メールクライアント１１０は、送信側クライアントデバイス１０２および／または電子メールクライアント１０４について先に説明したように構成されてもよい。

また、システムアーキテクチャ１００は、電子メールサーバ１０６を含み得る。電子メールサーバ（または「メールサーバ」）１０６は、ネットワークを介して電子メールメッセージを処理および配信する任意のサーバを含み得る。電子メールサーバ１０６は、送信側クライアントデバイス１０２上の電子メールクライアント１０４から、作成および送信された電子メールメッセージ１１６を受信し得る。電子メールサーバ１０６は、電子メールメッセージ１１６の受信者を識別し、電子メールメッセージ１１６を受信者に送信することができる。たとえば、電子メールサーバ１０６は、電子メールメッセージ１１６を、受信側クライアントデバイス１０８上の電子メールクライアント１１０に転送することができる。いくつかの実施形態において、電子メールサーバ１０６は、通信セッション間で電子メールメッセージが電子メールクライアント１０４、１１０によってダウンロードされてもよいように、各電子メールクライアント１０４、１１０に対する電子メールメッセージを格納してもよい。

システムアーキテクチャ１００はまた、タグ予測サーバ１１２を含み得る。タグ予測サーバ１１２は、タグ予測モデル１１４を含み得る。以下で詳細に説明されるように、タグ予測モデル１１４は、電子メールメッセージ１１６の本文テキスト、電子メールメッセージ１１６の件名、電子メールメッセージ１１６の送信者／受信者、および／または電子メールメッセージ１１６に添付されまたは電子メールメッセージを記述し得る任意の他のメタデータ等の、電子メール情報を受信するように構成されてもよい。タグ予測モデル１１４は、電子メール情報を分析し、その出力において、電子メールメッセージ１１６に適用される提案されたタグのセットを提供することができる。提案されたタグのセットは、電子メールメッセージ１１６が作成される際に、電子メールクライアント１０４に提供されてもよい。以下で説明されるように、提案されたタグは、電子メールメッセージ１１６が送信される前に、ユーザによって選択され／非選択とされ、および／またはそうでなければ修正されてもよい。電子メールメッセージ１１６が送信される場合、複数のタグ１１８が、電子メールメッセージ１１６が送信側クライアントデバイス１０２と電子メールサーバ１０６との間で送信されるときに、電子メールメッセージ１１６の一部として埋め込まれてもよい。

電子メールメッセージ１１６が電子メールサーバ１０６で受信されると、タグ予測サーバ１１２は、送信側クライアントデバイス１０２から送信された複数のタグ１１８を検討することができる。次に、タグ予測サーバ１１２は、タグ予測モデル１１４によって提案されたタグと、ユーザによって選択されたタグとの間の相違を識別してもよい。タグ予測サーバ１１２はまた、ユーザによって追加／削除されたタグを識別してもよい。次に、タグ予測サーバ１１２は、電子メール情報と複数のタグ１１８とで構成された訓練ペアを生成してもよい。電子メール情報は、訓練セッションのために複数のタグ１１８の出力を提供するように構成された入力として使用されてもよい。これに加えてまたはこれに代えて、タグ予測サーバ１１２はまた、送信側クライアントデバイス１０２によって提供されたタグ１１８を修正してもよい。たとえば、タグ予測サーバ１１２は、電子メールサーバ１０６から受信側クライアントデバイス１０８に、電子メールメッセージ１１６とともに送信される、修正された複数のタグ１１９を生成するために、複数のタグ１１８を追加、削除、および／または修正してもよい。

電子メールメッセージ１１６が受信側クライアントデバイス１０８上の電子メールクライアント１１０によって受信されると、電子メールクライアント１１０は、ユーザが、電子メールサーバ１０６から受信された複数のタグ１１９を閲覧および／または修正することを可能にしてもよい。送信側クライアントデバイス１０２上で可能にされたものと同様のプロセスにおいて、受信側クライアントデバイス１０８は、ユーザが、タグを追加すること、タグを削除すること、タグを修正すること、および／または同様のことを可能にしてもよい。タグ１１９に対して行われた任意の変更は、タグ予測モデル１１４を再訓練するために、タグ予測サーバ１１２に返送されてもよい。

図１に示されるシステムアーキテクチャ１００によって説明されるプロセスは、上記技術的課題を解決するエンドツーエンドタグ予測を提供する。具体的には、モデルは、個々のユーザグループごとに訓練されてもよい。これにより、ユーザグループ内で送信される電子メールに適用されるタグを、グループ全体で均一に維持することができる。送信者および受信者は、グループ全体においてよく知られるようになり均一になるタグの共通セットを使用してもよい。さらに、モデルは、グループ内のユーザの言語、電子メールの習慣、用語、および／または通信スタイルに極めて固有のものになるように、時間をかけて訓練されてもよい。加えて、タグは、各電子メールメッセージごとに、送信者において定められ、中央サーバにおいて修正され、受信者においてさらに精緻化されてもよい。タグが送信者側で適用される一方で異なるタグが受信者側で適用される代わりに、このシステムアーキテクチャ１００は、電子メールメッセージのライフサイクル全体にわたってタグが均一に維持されることを可能にする。タグは、電子メールメッセージが作成、送信、処理、および／または受信されるときに電子メールメッセージに埋め込まれるので、訓練機会は、メッセージがシステムを通して送信される各段階で強化される。全体として、これは、必要なユーザの手間を最小レベルにする、均一で予測的で適応的なタグ付けシステムを提供する。

図２Ａは、いくつかの実施形態に係る、送信側クライアントデバイス１０２における電子メールクライアント１０４の一部になり得るユーザインターフェイス２００を示す。インターフェイス２００は、メールボックス構成（たとえば受信箱、送信メール、ドラフトなど）等の現代の電子メールクライアントの典型であるユーザコントロール、検索機能、電子メールヘッダおよび／または第１行を表示するためのエリア、選択された電子メールの本文を表示するためのエリアなどを含み得る。図２Ａの例において、ユーザは、新たな電子メールを作成するための表示を生成する入力を既に提供している。この表示は、電子メール受信者を指定するためのフィールド（たとえば「Ｔｏ」、「ＣＣ」、「ＢＣＣ」など）、件名行を指定するためのフィールド、および／または電子メールの本文を提供するためのフィールドを含み得る。いくつかの実施形態において、ユーザは、電子メール受信者の、メーリングリストまたはグループメンバーシップへのマッピングを提供してもよい。以下で詳細に説明されるように、システムによって適用されるタグは、特定のメーリングリストまたはグループメンバーシップに固有の使用可能なタグのグループから選択されてもよい。電子メール本文は、テキスト、添付物、グラフィックス、マルチメディア、および／または電子メールメッセージに埋め込まれ得るおよび／または添付され得る任意の他のタイプのデジタル情報を含み得る。

電子メールクライアントの一部として提供され得る従来の表示およびユーザコントロールに加えて、インターフェイス２００は、電子メールメッセージのための、予測、選択、および／またはユーザ指定されたタグのセットを表示しユーザが編集することを可能にする、追加のコントロールまたはコントロールのセットを含み得る。これらのタグ２０２は、電子メール受信者および電子メールメッセージの件名とともに表示されてもよい。以下で詳細に説明されるように、初期タグ２０２は、タグ予測サーバから自動的に提供されてもよい。ユーザが電子メールを作成すると、電子メール情報を捕捉し電子メール情報をタグ予測サーバに送信し電子メールメッセージの予測タグのセットを受信するように、あるアクションが電子メールクライアントをトリガしてもよい。

いくつかの異なるアクションが、予測タグを生成するようにシステムをトリガしてもよい。いくつかの実施形態において、タグ予測サーバに送信される電子メール情報は、件名、受信者のセット、電子メール本文、任意の添付物、および／または電子メールメッセージの任意の他のメタデータもしくは記述情報を含み得る。この情報が変更されると、電子メール情報は、電子メール情報をタグ予測モデルによって処理し予測タグのセットを生成できるように、サーバに送信されてもよい。いくつかの実施形態において、タグ２０２は、電子メール情報がクライアントデバイスにおいて変更されるたびに生成されてもよい。いくつかの実施形態において、タグ２０２は、タイマの満了時に（たとえば３０秒ごと、６０秒ごとなど）生成されてもよい。いくつかの実施形態において、タグ２０２は、電子メールメッセージが完了したときに（たとえばユーザが「送信」をクリックしたときに）生成されてもよい。予測タグのセット２０２は、タグ予測サーバから受信されると、図２Ａに示されるようにタグフィールド内に表示されてもよい。

タグ２０２は、電子メールメッセージによって扱われる標題を示し得る。たとえば、インターフェイス２００で作成されているメッセージは、この特定のユーザグループに以前に割り当てられた予め定められたいくつかのタグに関連していてもよい。たとえば、電子メールメッセージは、テレビ会議を要求する際は「Meetings（会議）」に関連し得る。これはまた、電子メール本文でこの特定のプロジェクトに言及する際は「Proj 233（プロジェクト２３３）」に関連し得る。メッセージはまた、特定のウィジェットの調達オプションを要求する際は「Procurement（調達）」に関連し得る。最後に、メッセージは、この場所のディストリビュータに言及する際は「New Mexico」に関連し得る。これらのタグの各々は、このグループに割り当てられたグローバルタグのセットからタグ予測モデルを使用して自動的に予測されたものであってもよい。これらのタグ２０２は、ユーザが最終的にこの電子メールメッセージに適用されるタグを精緻化するための出発点としての役割を果たし得る。

図２Ｂは、いくつかの実施形態に係る、新規タグを追加し既存タグを削除するためにユーザインターフェイス２００が如何にして使用され得るかを示す図である。ユーザは、出発点として予測タグのセット２０２を受信した後に、電子メールメッセージに割り当てられるタグをさらに精緻化することを所望する場合がある。現在の電子メールメッセージに適用される新規タグを表すテキストをユーザが入力できるように、コントロール２０４を提供することができる。いくつかの実施形態において、システムは、特定のユーザグループのための既存タグにユーザを誘導するのに役立つオートコンプリート機能を提供してもよい。

以下で詳細に説明されるように、サーバは、このユーザグループに使用可能なグローバルタグのセットから予測タグのその初期セットを選択することができる。これらの使用可能なタグの各々は、タグ予測モデルの出力に対応し得る。しかしながら、モデルの出力は、使用可能なタグの各々についてスコアを生成してもよく、サーバは、あるしきい値を上回るスコアを有するタグのみを送信してもよい。これにより、最小信頼度スコアにより、予測タグが特定の電子メールメッセージに関連付けられることを保証する。最小信頼度スコアを下回ってスコアが付けられた残りの使用可能なタグは、たとえそれらが最初に適用可能であると予測されていなくても、現在の電子メールメッセージに適用し得るタグとしてなおも使用可能である。

ユーザがコントロール２０４に情報をタイプし始めると、システムは、タグ予測サーバによって予測タグとして選択されなかった使用可能タグリスト内のタグを最初に参照するオートコンプリート機能を実行することができる。この例の場合、ユーザがテキスト「Ｗｉｄ…」をタイプし始めると、システムは、予測タグとして選択されなかった使用可能なタグのリストを検索し、ユーザによってタイプされたプレフィックスと一致する、残っている使用可能なタグのうちのいずれかを、識別することができる。たとえば、コントロール２０４は、使用可能タグリストのうちの「Ｗｉｄｇｅｔｓ」および「Ｗｉｄｔｈｓ」タグ等の、ユーザによってタイプされているテキストを仕上げるまたはオートコンプリートするテキストを提供することができる。次に、ユーザは、タグのテキストの残りを手動でタイプするのではなく、オードコンプリートオプションのうちの１つを選択することができる。

いくつかの実施形態において、システムは、使用可能タグリストの一部ではない新規タグをユーザが追加できるようにしてもよい。コントロール２０４によって示されるオートコンプリート機能は、オートコンプリートオプションを提供することができる。ユーザが引続きタイプしてもタイプされたプレフィックスが使用可能なタグのいずれとも一致しない場合、システムは、ユーザによって追加された新規タグを定めてもよい。以下で説明されるように、この新規タグは、モデルが再訓練されるときに、ユーザグループのための使用可能なタグのリストに追加されてもよい。加えて、ユーザは、タグ予測サーバによって提供された予測タグのうちの１つ以上を削除または「非選択」にすることができる。この例において、ユーザは、「Ｍｅｅｔｉｎｇｓ」タグ２０３をリストから削除することを望むかもしれない。ユーザは、このタグが不要であるか、またはこの特定の電子メールメッセージに誤って割り当てられていると感じるかもしれない。ユーザは、単純にタグ２０３をクリックしてこのタグをリストから削除してもよい。

図２Ｃは、いくつかの実施形態に係る、タグ２０２のリストに対してユーザ変更が行われた後のユーザインターフェイス２００を示す。先に述べたように、図２Ａに示される予測タグの元のリストは、「Ｗｉｄｇｅｔｓ」タグを追加し「Ｍｅｅｔｉｎｇｓ」タグを削除することで、変更されている。タグは、サーバによって提供された予測タグのリストから削除されると、非選択タグ（すなわち当初予測タグリストに提供されていたタグであって、この電子メールメッセージに適用可能なものとしてユーザによって選択されなかったタグ）と呼ぶことができ、予測されたタグのリストに残っているタグは、選択タグ（すなわち当初予測タグリストに提供されていたタグであって、この電子メールメッセージに適用可能なものとしてユーザによって選択されたタグ）と呼ぶことができる。加えて、ユーザによって手動でまたはオートコンプリート機能により追加された任意のタグは、ユーザタグと呼ぶことができる。この用語は、モデルによって最初に予測されなかった、ユーザによって追加されたタグと、モデルによって最初に予測され、リストに保存／リストから削除されたタグとを、区別することができる。

図２Ｄは、いくつかの実施形態に係る、タグを特定のテキスト選択に適用するためにユーザインターフェイス２００が如何にして使用され得るかを示す図である。上記例において、電子メール情報の全体がモデルによって分析されてもよく、モデルによって提供された予測タグは、電子メールメッセージ全体に適用可能であってもよい。しかしながら、いくつかの実施形態は、電子メールメッセージ内のテキストセグメントとタグとの間のより細分化された関連付けを可能にし得る。

この例において、ユーザは、電子メールメッセージの本文内の「ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｅ」テキスト文字列等の、テキストの特定のセグメントを強調表示することができる。このテキスト文字列の強調表示または選択に応じて、インターフェイス２００は、ユーザがこのユーザグループのためのタグ予測サーバから使用可能なタグのうちの１つを選択することを可能にする、ポップアップコントロール２０８を生成することができる。いくつかの実施形態において、選択されたテキストは、タグ予測モデルに送信されてもよく、そのテキスト選択に固有の予測タグの新たなセットが提供されてもよい。この例において、タグ予測モデルは、「Ｖｉｄｅｏ Ｃｏｎｆｅｒｅｎｃｅ」、「ＷｅｂＥｘ」、および／または「Ｗｅｂ Ｃａｍ」等のタグを含む、この特定のテキスト選択に適用可能なタグのセットを提供することができる。オートコンプリート機能について先に述べたように、ユーザは、コントロール２０８から、その特定のテキスト選択に適用されるべき予測タグのうちの１つを選択することができる。加えて、所望のタグがコントロール２０８において利用可能でない場合、ユーザは、このユーザグループまたはメーリングリストのための使用可能なタグのグループに追加し得る新規タグをタイプしてもよい。オートコンプリート機能は、ユーザが新規タグをタイプしたときに起動されてもよく、そうすると、最初にコントロール２０８において提案タグとして表示されない、使用可能なタグを提供することができる。したがって、新規タグは、オートコンプリート機能を使用して、または、図２Ｂに関連して先に説明したように全く新規のタグをタイプすることにより、追加されてもよい。タグが選択された後、タグ２０３のアイコンが、インターフェイス２００のタグリスト内のタグ２０２に追加されてもよい。ユーザがタグ２０３をクリックすると、「Ｖｉｄｅｏ Ｃｏｎｆｅｒｅｎｃｅ」テキストがインターフェイス２００において強調表示され、タグ２０３と特定の選択テキストとの間のつながりが視覚的に明らかになる。

図３は、いくつかの実施形態に係る、ユーザによる編集用に予測タグのセットを表示するために電子メールクライアントによって実行されるプロセスのフローチャート３００を示す。この方法は、電子メール情報を受信すること（３０２）を含み得る。電子メール情報は、自動的にロードされてもよく、または、電子メールが作成される際にユーザによって提供されてもよい。たとえば、ユーザは、件名、一組の受信者、添付物、電子メールの本文などを提供することができる。電子メール情報がユーザによって提供されると、次に、この情報はタグ予測サーバに提供されてもよい（３０４）。

いくつかの実施形態において、タグ予測モデルは、電子メール情報からタグを確実に予測するために使用できるようになる前に、十分に訓練される必要がある場合がある。モデルは、訓練データのセットを使用して手動で訓練されてもよい。モデルはまた、使用中に、電子メールがシステムを通して送信される際に訓練されてもよい。タグ予測モデルが有効にされているか、動作しているか、および／またはタグの信頼できる予測セットを生成するために十分に訓練されているかについて、判断を行うことができる（３０６）。モデルは、予め定められた数の訓練データセットが処理された後、予め定められた期間の終了後などに、訓練されたとみなされてもよい。

モデルがまだ訓練されていない場合、システムは、ユーザのための出発点として予測タグのセットを提供することなく、次に進んでもよい。しかしながら、インターフェイスは、依然として、ユーザが各電子メールメッセージに対して独自のタグを追加することを可能にしてもよい。図３に示されるように、これらのユーザタグは、ユーザによって入力されるタグを指定するために、「ｔ＿ｕｓｅｒ」という省略表現を使用して指定されてもよい。これらのタグは、システムにとって新規であってもよく、またはこれらのタグは、以前に予測されなかった使用可能なタグから選択されてもよい。いくつかの実施形態において、新規ユーザタグがシステムに提供されると、モデルの出力は、新規タグの追加方法に基づいて、使用可能なタグのセットが増加するように更新されてもよい。

モデルが以前に十分に訓練されている場合、モデルは、以下で説明されるように、使用可能なタグのセットから予測タグのセットを提供することができる。ユーザインターフェイスは、予測タグのセットをロードしてもよく（３１０）、その結果、これらのタグは、電子メールがリアルタイムで作成されているときに電子メールとともに表示される。先に述べたように、インターフェイスは、新規タグのリストへの追加、既存タグのリストからの削除（「非選択」）などのために、ユーザがタグリストを更新できるようにしてもよい（３１２）。加えて、上記オートコンプリート機能は、タグ予測サーバとインターフェイスして、特定のユーザグループのための使用可能なタグのグローバルリストから取り出されたオートコンプリートオプションを提供してもよい（３１４）。

ユーザタグが追加され予測タグが選択された／非選択とされた後に、タグの最終リストが、電子メール送信前に電子メール内のタグフィールドをポピュレートするために提示されてもよい（３１６）。送信側クライアントデバイスの電子メールクライアントから送信されるタグのこの最終セットは、ユーザタグ（ｔ＿ｕｓｅｒ）、予測タグリストから選択されたままのタグ（ｔ＿ｓｅｌ）、および／または予測タグリストから削除された／非選択とされたタグ（ｔ＿ｕｎｓｅｌ）を含み得る。任意で、いくつかのタグが、特定のテキスト選択と関連付けられてもよい（３１８）。特定のテキスト選択と関連付けられない任意のタグは、電子メール情報に一般に適用可能とみなされてもよい。

この方法はまた、電子メールを電子メールサーバに送信すること（３２０）を含み得る。いくつかの実施形態は、タグのための追加フィールドを加えるために、本開示に先立って存在していた従来の電子メール構造を修正してもよい。具体的には、ｔ＿ｕｓｅｒ、ｔ＿ｓｅｌ、およびｔ＿ｕｎｓｅｌタグはすべて、それらのすべてをサーバが利用できるように、電子メールのヘッダに含まれてもよい。このタグ構造は、タグ予測モデルからの予測タグの初期セットが如何にしてユーザによって修正されたかを示す。これら２つのタグセット間の相違を利用して、モデルが時間をかけてユーザの好みに適合するようにモデルを訓練してもよい。加えて、特定のテキスト選択と関連付けられるタグは、タグテキスト、およびテキスト選択を定めた電子メール情報内の開始／終了基準を含み得る。

図４は、いくつかの実施形態に係る、使用可能なタグのセットから予測タグのセットを生成するためにタグ予測サーバによって実行される動作の機能図４００を示す。この図４００は、電子メールが作成され送信されているときに送信側クライアントデバイス１０２が如何にしてタグ予測サーバ１１２と対話するかを示す。電子メールクライアント１０４は、上述の電子メール情報４０２をタグ予測サーバ１１２に送信することができる。電子メール情報４０２は、タグ予測モデル１１４への入力として提供されてもよい。タグ予測モデル１１４は、複数の出力を有することができ、その各々は、システム内の単一の使用可能なタグに対応する。電子メール情報４０２の入力セットがタグ予測モデル１１４に提供されるとき、使用可能なタグの各々に対応する出力は、信頼度スコアを生成し得る。たとえば、信頼度スコアは、０．０と１．０との間の小数値を含み得る。信頼度スコアは、関連付けられた使用可能なタグが電子メール情報４０２とより密接に相関するにつれて増加し得る。タグ予測モデル１１４が如何にして動作するかの具体的な詳細は、図８～図１１において以下で詳細に説明される。

この例において、システム内の使用可能タグ４０６の数は、ｍ個のタグを含み得る。システムは、ｍ個の使用可能タグ４０６のすべてを提供する代わりに、タグ予測モデルによって提供される信頼度スコアにしきい値を適用してもよい。信頼度スコアしきい値を超えるｋ個の使用可能タグ４０６が、予測タグ４１２として電子メールクライアント１０４に提供されてもよい。予測タグ４１２の数ｋは、使用可能タグ４０６の数ｍ未満となり得る。予測タグ４１２は、図２Ａに関して先に述べたように、電子メール情報のタグとして最初に表示されてもよい。ユーザは、選択タグ４１４と呼ぶことができる予測タグ４１２のうちのいくつかを保持することを選択してもよい。ユーザはまた、非選択タグ４１６と呼ぶことができる予測タグ４１２のうちのいくつかを削除することを選択してもよい。選択タグ４１４および非選択タグ４１６の両方が、電子メールメッセージが送信されるときに電子メールメッセージに埋め込まれてもよい。

タグ予測モデル１１４は、動作環境内の組織または下位組織のような特定のユーザグループに固有であってもよい。たとえば、異なるタグ予測モデル１１４が異なるプロジェクトグループに対して訓練されてもよい。異なるタグ予測モデル１１４は、異なる組織に対し、組織図に従って訓練されてもよい。異なるタグ予測モデル１１４は、異なるユーザロールまたはセキュリティ認可グループに対して訓練されてもよい。ある一般的な例において、異なるタグ予測モデル１１４は、特定のメーリングリストに対して訓練されてもよい。ユーザ組織がメーリングリストを構築できる場合、特定のタグ予測モデル１１４は、各メーリングリストが、メーリングリストのメンバーのニーズを満たすようにある時間にわたって増大する使用可能タグのそれ自身のセットを構築するように、各メーリングリストごとに訓練されてもよい。要するに、タグ予測モデル４１４は、ユーザの任意のグループ分けに固有になるように訓練されてもよい。

タグ予測モデルはいくつかの要求を同時に出し易くすることができるので、いくつかの実施形態は、各電子メールメッセージのための使用可能タグの状態を保存する、メモリ機構を含み得る。加えて、個々のユーザは、複数の電子メールメッセージを同時に作成することができる。したがって、電子メール情報４０２は、ハッシュプロセス４０４に提供されてもよい。ハッシュプロセスは、電子メール情報４０２の任意の部分に基づいて固有の鍵を作成することができる。同じ送信者からの複数の電子メールに対応するために、ハッシュプロセス４０４は、送信者電子メールＩＤ、電子メールの件名、メーリングリスト、タイムスタンプ、電子メール本文の部分、および／または任意の他の情報を組み合わせて使用して、ハッシュマップ４０８をポピュレートするために各電子メールのための固有のハッシュキーを生成することができる。ハッシュマップ４０８は、特定のタグ予測モデル１１４を使用するオープン電子メールメッセージごとのハッシュキーを含み得る。

ハッシュマップ４０８は、オープン電子メールメッセージごとに、使用可能タグの表現にマッピングすることができる。これらは、残りのｍ－ｋ個の使用可能タグに基づいて生成された個々の重み付けされたトライ（trie）として表されてもよい。トライは、各ノードがプレフィックスの一部分に対応するツリーデータ構造の特殊バージョンであり、タグは、トライ内のパスをトラバースすることによって構築されてもよい。トライは、ある経路が他の経路よりも重く重み付けされるように重み付けされてもよい。これらの重みは、タグ予測モデル１１４から導出された信頼度スコアに基づいて決定されてもよい。

これらのタグは、上記オートコンプリート機能のために使用できるようにされてもよいことを想起されたい。たとえば、ユーザが、電子メールクライアント１０４において、ポップアップウィンドウにおけるタイピングを開始すると、システムは、タグが作成されたときにオートコンプリートエントリを要求することができる。たとえば、電子メール情報４０２は、ハッシュプロセス４０４に提供されてもよく、ハッシュプロセスは、オープン電子メールメッセージに対応する鍵を生成し得る。ハッシュマップ４０８は、ハッシュプロセス４０４によって生成された鍵を受信し、オープン電子メールメッセージに関連付けられた、対応する重み付けされたトライ４１０を取り出すことができる。電子メールメッセージ１１６は、次に、オートコンプリート機能によって生成されたユーザタグ４１８、および、ユーザによって最初から追加された任意のユーザタグ４２０を含み得る。

ユーザが電子メールメッセージ１１６を送信するとき、上記タグタイプ４１４、４１６、４１８、４２０の各々は、電子メールメッセージ１１６のヘッダの一部として埋め込まれてもよい。加えて、電子メール情報４０２は、ハッシュマップ４０８内の対応するキーおよび対応する重み付けされたトライ４１０がメモリシステムからパージされ得るように、ハッシュプロセス４０４に提供されてもよい。

図５は、いくつかの実施形態に係る、電子メールメッセージが電子メールサーバを通して送信されるときに電子メールメッセージ内のタグを処理するための方法のフローチャート５００を示す。図１で説明したように、電子メールが電子メールサーバ１０６によって受信されると、電子メールサーバ１０６は、電子メール情報および／またはタグをタグ予測サーバ１１２に送信することができる。次に、タグ予測サーバは、この方法を実行して、電子メールメッセージ内のタグを更新する、および／またはタグ予測モデルをさらに訓練することができる。

この方法は、最初に、タグ予測モデルが有効にされているか否かを判断すること（５０２）を含み得る。モデルが有効にされていない場合、タグおよび／または電子メール情報に対するさらなる処理は必要でない可能性がある。電子メールメッセージに埋め込まれた任意のタグは、タグ予測モデルがアクティブでなかったため、ユーザによって手動で追加されたユーザタグとみなされてもよい。ユーザタグは、電子メールメッセージの最終タグとして割り当てられてもよく（５０４）、タグ予測サーバ１１２は、電子メールメッセージ１１６が受信側クライアントデバイス１０８に配信されてもよいという指示を電子メールサーバ１０６に送信してもよい（５２６）。いくつかの実施形態において、ユーザタグは、タグ予測モデルを訓練するため、および／またはユーザグループのための使用可能タグのセットを構築するために、電子メール情報とともに訓練データセットとして使用されてもよい。

タグ予測モデルが有効にされている（すなわち十分に訓練されている）場合、電子メールメッセージが作成されているときに予測タグが電子メールクライアントに提供されたか否か判断されてもよい（５０６）。たとえば、非選択タグの数に加算された選択タグの数が０より大きかった場合に、予測タグが電子メールクライアントに提供され、最初に、ユーザのための出発点として提示された。予測タグが提供されなかった場合は、メッセージが構成されていたときにタグ予測モデルが使用可能でなかったと仮定することができる。たとえば、タグ予測モデルは、ネットワーク機能停止、ソフトウェアまたはクライアントの更新、モデル訓練などに起因して利用不可能であった可能性がある。したがって、いくつかの実施形態は、この時点でタグ予測処理を実行してもよい（５０８）。これは、電子メールメッセージとともに提供されるユーザタグのセットに追加されてもよい予測タグのセットを生成し得る。たとえば、ユーザによって追加された任意のタグが、タグ予測モデルによって予測タグと組み合わされてもよく、これらの２つのタグセットの和集合が、電子メールメッセージのための最終タグとして格納されてもよい（５１０）。予測タグのセットは、次に、ユーザタグとともに電子メールヘッダに埋め込まれてもよく、電子メールは、タグの更新されたセットとともに送信されてもよい（５２６）。

より一般的には、電子メールメッセージが作成されていたときに予測タグが電子メールクライアントに提供されたと判断されてもよい（５０６）。次に、タグ予測モデルによって予測された選択／非選択タグのセットに対してユーザが任意の追加タグを加えたか否かが判断されてもよい（５１２）。ユーザタグが提供された場合、これは、ユーザの嗜好／行動により厳密に一致するように、モデルが再訓練される必要があることを示し得る。訓練ペアが、電子メール情報と、ユーザタグおよび予測タグの組み合わせとを使用して構築されてもよい（５１４）。次に、この訓練ペアは、将来の訓練セッション中にタグ予測モデルに提供されてもよい。電子メールのための最終タグセットは、ユーザタグおよび選択されたタグとして設定することができ（５１６）、電子メールは、タグのこの最終セットとともに送信されてもよい（５２６）。

電子メールメッセージが作成されたときにユーザタグが追加されなかった場合（５１２）、ユーザが予測タグのいずれかを維持することを選択したか否か、すなわち、選択されたタグの数が０よりも大きいか否かが判断されてもよい（５１８）。選択されたタグがなく、予測タグのいずれもユーザは維持しなかったことが示される場合、ユーザは予測タグを検討していないと仮定することができる。いくつかの実施形態において、ユーザは、予測タグリストから、タグを、電子メールのためのタグとして使用される前に、積極的に選択することが要求されてもよい。この場合、システムは、非選択タグを破棄することによる利益を得られない。代わりに、最終タグが非選択タグとして設定されてもよい（５２０）。実際、システムは、予測タグのすべてを、そのうちのいずれもユーザによって選択されない場合、電子メールに割り当てることができる。これは、ユーザが予測タグを十分に検討しなかったことを示し得るものであり、したがって、ユーザによって積極的に選択されないことを利用してモデルを訓練する必要はない。

選択されたタグが電子メールメッセージに割り当てられる場合、タグの選択は、モデルをさらに訓練するために使用されてもよい。これは、将来の予測タグセットが、ユーザによって選ばれた選択タグセットと整合する可能性がより高くなるように、モデルが信頼度しきい値を調整する、および／またはモデルによって生成された信頼度スコアを調整するのに役立つ。言い換えると、この訓練セットは、将来ユーザが電子メールメッセージに適用可能な予測タグのすべてを選択する可能性をより高くする。訓練ペアは、電子メール情報および選択されたタグのセットを使用して定められ（５２２）、将来の訓練セッション中にモデルを訓練するために使用されてもよい。電子メールメッセージのためのタグの最終セットは、ユーザのための選択タグとして設定されてもよく（５２４）、電子メールメッセージは、タグのこの最終セットとともに送信されてもよい（５２６）。

このプロセスは、いくつかの実施形態が非選択タグを選択タグとともに電子メールヘッダに埋め込むことができる理由を示す。非選択タグは、ユーザによって示される電子メールメッセージに必ずしも適用されないが、電子メールサーバによって開始されるこのプロセスによってなおも使用される可能性がある。非選択タグを電子メールヘッダに格納しなければ、それらは、モデルをさらに訓練するためのこのプロセスに使用できない場合がある。

図６は、いくつかの実施形態に係る、受信側クライアントデバイス１０８を使用してタグとやり取りするための方法のフローチャート６００を示す。このプロセスは、送信側クライアントデバイスに関して図３で説明したプロセスと非常に似ている可能性がある。この場合、受信側クライアントデバイス１０８は、電子メールをタグのセットとともに受信することができる（６０２）。電子メールクライアントが上記タグ付けシステムと互換性があるか否かが判断されてもよい（６０４）。電子メールクライアントに互換性がない場合はヘッダ内のタグ情報が破棄されてもよく、および／またはユーザインターフェイス内に表示されなくてもよく、電子メールはタグなしで通常通り表示されてもよい（６０８）。これは、タグ互換性のあるシステムから送信される電子メールが、このタグ付けシステムを使用しない他の電子メールクライアント／システムとなおも後方互換性があることを保証し得る。

電子メールクライアントがタグシステムと互換性がある場合（６０４）、タグは、図７Ａ～図７Ｃにおいて下記の通り示されるように、ユーザインターフェイス内に表示されてもよく、ユーザは、現在のタグセットから修正、追加、および／または減算を行ってもよい（６０６）。受信側電子メールクライアントに最初に提示されるタグは、最初にタグ予測モデルによって予測され、送信側ユーザによって選択され／非選択とされ、オートコンプリートおよび／または他のユーザ生成タグで増補され、電子メールサーバを通して送信されてもよいことに、留意されたい。電子メールサーバにおいて、タグ予測サーバは、再びアクセスされてもよく、タグは、上述のように追加の予測タグを含むようにさらに精緻化されてもよい。

タグが受信側電子メールクライアントによって受信されると、受信側ユーザは、タグセットにさらなる修正を行うことができる。たとえば、受信側ユーザは、タグを追加し、タグを削除し、既存タグを修正し、および／またはタグリストを変更してもよい。これは、この特定のユーザグループのための既存の使用可能タグリストから新規タグを選択するために、上述のオートコンプリート機能を使用することを含み得る。タグが受信側ユーザによって変更された後、受信側クライアントデバイス１０８は、変更されたタグとともに受信された電子メールをタグ予測サーバ１１２に返送することができる（６１０）。タグ予測サーバ１１２は、次に、受信側クライアントデバイス１０８によってタグに行われた変更を用いてモデルを再訓練することができる（６１２）。したがって、モデルは、システムを通過する各電子メールメッセージに割り当てられたタグの共通セットのエンドツーエンド管理を提供するために、送信側クライアントデバイス１０２、電子メールサーバ１０６、および／または受信側クライアントデバイス１０８において行われた変更に基づいて再訓練されてもよい。

図７Ａは、いくつかの実施形態に係る、受信側電子メールクライアントにおいて実現されるユーザインターフェイス７００を示す。ユーザインターフェイス７００は、図２Ａに関連して説明した共通する特徴のうちのいずれかを含み得る。ユーザインターフェイス７００は、ユーザが受信箱内の電子メールのリストから電子メールを選択し、電子メールの内容を図７Ａに示す表示エリアに表示することを可能にしてもよい。この表示エリアの一部として、電子メールは、受信者リスト、送信者、件名、および／または他の従来の電子メール情報を表示することができる。加えて、電子メールクライアントがタグシステムとの互換性を有する場合、受信された電子メールも、電子メールが電子メールサーバを通して作成および／または送信されているときに、送信側電子メールクライアントおよび／またはタグ予測サーバによって以前に割り当てられたタグ７０２を伴うフィールドを表示してもよい。これらのタグ７０２は、受信側ユーザが電子メールのタグ７０２を閲覧および／または編集するための出発点として機能し得る。

図７Ｂは、いくつかの実施形態に係る、タグ７０２のセットを修正するためにユーザインターフェイス７００が如何にして使用され得るかを示す。実際、タグのセット７０２からタグを編集、追加、および／または削除するために、送信側電子メールクライアントについて説明したのと同じプロセスが、受信側電子メールクライアントにおいて行われてもよい。たとえば、受信側ユーザは、送信側ユーザが、この電子メールが適用されるべきプロジェクトを誤って識別したこと、すなわち、この電子メールがプロジェクト２３３の代わりにプロジェクト２３５に適用されるべきであることを認識し得る。ユーザは、「Ｐｒｏｊ２３３」のタグを選択し、タグの「３」というサフィックス部分を削除することができる。この時点で、電子メールクライアントは、タグに残されたプレフィックスに基づいてオートコンプリートリストを提供することを求める要求を、タグ予測サーバに送信することができる。たとえば、「２３」で始まる他のプロジェクトは、ユーザに提示されてもよいドロップダウンメニュー７０２に表示されてもよい。加えて、図７Ｂには明確に示されていないが、ユーザは、新規ユーザタグを追加し、および／または受信された電子メールメッセージの一部であった任意の既存タグを削除してもよい。

図７Ｃは、いくつかの実施形態に係る、電子メールメッセージ内の特定のタグに関連する特定のテキストを閲覧するためにユーザインターフェイスが如何にして使用され得るかを示す図である。上記送信者および／またはタグ予測サーバが電子メールメッセージに一般に適用可能であるタグを割り当て得ることを、想起されたい。送信者および／またはタグ予測サーバは、電子メールメッセージ内のテキスト選択に特に適用可能なタグを割り当ててもよい。図２Ｄの例では、「ｖｉｄｅｏ ｃｏｎｆｅｒｅｎｃｅ」というテキスト選択に特に適用可能となるように「ＷｅｂＥｘ」タグが送信側ユーザによって追加された。この関係を見るために、受信側ユーザは、マウス、フィンガータップ、および／またはそれに類似するもの等の入力デバイスを使用して、ＷｅｂＥｘタグ７０４を選択することができる。タグ７０４が選択されると、インターフェイス７０２は、対応するテキスト選択７０６を自動的に強調表示することができる。これは、ユーザが、それらのタグに特に結び付けられる電子メールメッセージ内の任意の選択テキストを視覚的に識別するために、タグ７０２の各々を選択することを可能にする。

先に述べたように、対応するテキスト選択７０６は、ユーザが電子メールメッセージを送信および／または受信することによって手動で割り当てることができる。しかしながら、いくつかの実施形態は、タグ予測モデルを使用して、選択されたテキスト７０６を対応するタグ７０４に自動的に割り当ててもよい。以下でより詳細に説明されるように、タグ予測モデルは、信頼度スコアを使用可能な各タグに割り当てるときに各単語または句の寄与を特徴付けるアテンションベクトルを生成する動作を含み得る。アテンションベクトルは、特定のテキスト選択を各タグに割り当てるために、タグ予測モデルによって予測された各タグごとに分析されてもよい。この例において、ユーザはＷｅｂＥｘタグ７０４を選択することができ、図７Ｃに示す選択テキストは、ユーザによって手動で行われる選択ではなく、タグ予測モデルによって行われる自動選択として強調表示されてもよい。

図８は、いくつかの実施形態に係る、如何にしてタグ予測モデルが入力電子メール情報に基づいて使用可能なタグの信頼度スコアのセットを生成するかを示す図である。タグ予測モデルは、畳み込みニューラルネットワークを使用することができる。このニューラルネットワークは、テキストのブロックを入力として受け、出力ベクトル内の使用可能なタグの各々についてのスコアを生成する機能と考えることができる。この例において、ニューラルネットワークに提供されるテキスト８０１は、「there is a proposal by the dev team for containerizing certain services.」というフレーズを含み得る。これは単純化された例であり、現実世界の例は、電子メールメッセージにおいて典型的に見出されるはるかに長いテキストブロックを使用し得ることに留意されたい。また、この特定のユーザグループのためのシステム内にＴｎ個の使用可能タグがあると仮定する。使用可能タグデータベースは、管理者またはユーザのいずれかによってシステムに提供される任意のタグを認識および記録することによって構築されてもよい。ニューラルネットワークの出力は、長さＴｎのアレイであってもよく、アレイ中の各エントリは、関連するタグがテキストに関連するレベルを示す信頼度スコアを含む。ニューラルネットワークは、このプロセスを、分類問題に対する解を見出すものとして閲覧することができる。

ニューラルネットワークを通してテキストを処理する前に、タグ予測モデルは、テキスト８０１を単語埋め込み行列８０２のような２次元（２Ｄ）ベクトルに変換してもよい。単語埋め込み行列８０２は、テキスト８０１を、ニューラルネットワークが理解できる数値表現に変換する。単語埋め込み行列８０２は、ニューラルネットワークの効率を大幅に改善し、完全接続層のように機能する。各単語は、ｄ次元ベクトル空間にマッピングされてもよい。ベクトル空間は、ベクトル空間内の関連付けられたベクトルの近接度に基づいて、テキスト８０１内の単語がどれだけ密接に関連しているかを数学的に表現する。たとえば、同様の意味を有する単語はベクトル空間において同様の方向に向けられ、反対の意味を有する単語は反対方向に向けられる。入力テキストにｎ個の単語がある場合、単語埋め込み行列８０２の次数はｎ×ｄとなる。

ニューラルネットワークは、複数の畳み込みフィルタ８０４、８０６、８０８で構成されてもよい。畳み込みフィルタ８０４、８０６、８０８の各々は、単語埋め込み行列８０２内のテキストのスライディングウィンドウを考慮することができる。実際、各フィルタは、テキスト８０１内の隣接する単語によって形成された異なる長さｎグラムを考慮することができる。この例において、第１のフィルタ８０４は２単語のウィンドウ長を有してもよく、第２のフィルタ８０６は３単語のウィンドウ長を有してもよく、第３のフィルタ８０８は４単語のウィンドウ長を有してもよい。図８に明示的に示されていない、より長いウィンドウ長を有する追加のフィルタが使用されてもよいことに、留意されたい。畳み込みフィルタ８０４、８０６、８０８内の各セルは、単語埋め込み行列８０２内の対応する行内の各値で乗算される値を含み得る。乗算結果は畳み込み演算で累積される。たとえば、ウィンドウサイズ２は、畳み込みニューラルネットワークの各列にｎ－１個のアイテムをもたらす。畳み込みフィルタ８０４、８０６、８０８について図８に示される列のセットの各々は、各フィルタの畳み込み演算の結果得られた行列とみなされてもよい。

畳み込みフィルタが、結果として得られる行列を演算し生成した後で、フィルタの結果を組み合わせるために最大値プーリング演算が実行されてもよい。いくつかの実施形態において、この演算は、結果として得られる行列の各々における各要素を調べ、各位置において結果として得られる行列から最大値を識別してもよい。この最大値を蓄積して長さ３Ｌであってもよいニューラルネットワークの最終層８１０にしてもよく、Ｌはフィルタ８０４、８０６、８０８のサイズである。

図９は、いくつかの実施形態に係る、使用可能なタグの信頼度スコアを生成するためにタグ予測モデルによって実行される第２の演算を示す図である。この第２の演算は、先に述べたものと同じ単語埋め込み行列８０２を使用する。ウィンドウ長２、３、４などを有する畳み込みフィルタを使用する代わりに、この第２の演算は、長さ１の畳み込みフィルタを使用する。このフィルタは、１グラムトークンとして一度に各単一ワードを処理することができる。長さ１を有するフィルタの使用個数はｍで表すことができる。フィルタリング演算の結果を使用して、ｎ×ｍ次元の「アテンション行列」と呼ばれる行列をポピュレートしてもよい。

次に、アテンションベクトルを生成するためにアテンション行列に対して最大値プーリング演算が実行されてもよい（９０４）。最大値プーリング演算は、アテンション行列内の各行に対して実行され、最大値を識別し、アテンションベクトルに最大値を格納することができる。結果として得られるアテンション行列は、ｎ×１次元を有する。元の単語埋め込み行列８０２は、元のｎ×ｄ行列がｄ×ｎ行列となるように転置されてもよい（９０６）。結果として得られた転置単語埋め込み行列は、ｄ×１次元の埋め込みアテンションベクトル９１０を生成するために、アテンションベクトルで乗算されてもよい（９０８）。

このアテンション機構は、各タグが関連し得る特定のテキストをモデルが予測することを可能にする。アテンションベクトルは、タグ予測モデルのタグ出力の各々に対応するので、各単語の相対的な重要度を表す。実際、アテンションベクトルは、特定の各タグに最も寄与するテキストのあるエリアに対してより大きな値を含み得る。いくつかの実施形態は、さらにアテンションベクトルを使用して、特定の各タグに関連すべきテキストのセグメントを識別することができる。先に述べたように、いくつかの実施形態は、ユーザがタグを選択し、タグに寄与する強調表示されたテキストを視認することを可能にする。このテキストはユーザによって設定されてもよいが、タグ予測モデルによって自動的に予測されてもよい。

図１０は、いくつかの実施形態に係る、如何にして、タグ予測モデルによって実行された２つの演算から得られた結果ベクトルを組み合わせて最終結果セット１０１０にできるかを示す。長さｄの埋め込みアテンションベクトル９１０は、単一のベクトルを形成するために、図８で説明した最終層８１０からのベクトルの終わりに連結することができる。この連結されたベクトルは、長さ３Ｌ＋ｄのニューラルネットワーク内の最後から２番目の層を表し得る。

連結されたベクトルは、次に、ニューラルネットワークの最終層１０１０を形成するために使用されてもよい。最終層１０１０中の各セルは、システム内の単一の使用可能タグに対応し得る。したがって、最終層１０１０は、使用可能タグに対応する長さＴｎを有し得る。最終層１０１０は、最後から２番目の連結層内の各セルが最終層１０１０へのＴｎの接続を有するので、完全接続層とみなされてもよい。連結層を最終層１０１０に変換するための機能は、連結ベクトルを、訓練プロセス中に設定された重み値を含む行列ｗで乗算することを含み得る。いくつかの実施形態は、各乗算結果にバイアス値を加算することもできる。バイアス値は、学習プロセスを通して設定されてもよく、０．０に近いランダムな値に初期化されてもよい。この行列乗算プロセスから得られる最終ベクトルは、結果として得られる最終層１０１０であり、上記信頼度スコアを表す数値を各セルの中に含む。

上記プロセスのいくつかの異なるステップにおいて、ユーザによって選択され定められたタグは、ニューラルネットワークのための訓練ペアとして、電子メールテキストとともに与えられてもよい。ニューラルネットワークを訓練するために、電子メールテキストが入力として与えられてもよい。加えて、ニューラルネットワークの最終層１０１０における値は、選択されたタグに従って設定されてもよい。ユーザによって電子メールに関連するものとして選択されたタグについて、最終層１０１０の対応する場所の値は１．０に設定されてもよい。非選択（たとえば関連しない）タグのすべてが０．０に設定されてもよい。次に、訓練プロセスが、バイアスの値、上記行列における重み、および畳み込みフィルタの値を、設定してもよい。

図１１は、いくつかの実施形態に係る、追加の通信チャネルを含む拡張システムアーキテクチャ１１００を示す。先に述べたように、電子メール通信チャネルは、タグ予測サーバ１１２を利用することができる多くの異なる通信チャネルの一例にすぎない。上述の同じ原理、方法、機能、およびモデルが、限定なく他の通信チャネルと併せて使用されてもよい。したがって、上記説明全体は、ソーシャルメディアチャネル１１０４、インスタントメッセージングチャネル１１０６、ＳＬＡＣＫ（登録商標）チャネル１１０２、および／または任意の他の通信方法に等しく適用可能であってもよい。たとえば、タグ予測サーバ１１２に電子メール情報を提供する代わりに、他の通信チャネルは、インスタントメッセージ、メッセージ会話、スレッド、コメントなどを表すテキスト本文を提供してもよい。これらのテキスト本文の各々は、次に、上記のように電子メールメッセージが予測タグを受信するのと同じ方法でタグを受信してもよい。

加えて、さまざまな通信チャネルの各々が、同一のタグセットおよび／または同一のタグ予測モデルを使用して互いに連携して動作してもよい。たとえば、モデルは、特定のソースに関係なく、電子メールメッセージ、インスタントメッセージ、ソーシャルメディア投稿、およびチャネル会話を使用して訓練されてもよい。ユーザが電子メールを送信し、タグ予測モデルによって予測されたタグを精緻化するとき、モデルは、新たな予測タグが同じタグ予測モデルを使用してインスタントメッセージのために提供され得るように訓練されてもよい。各ユーザグループのタグのデータベースは、これらの複数のチャネルの各々の間で共有されてもよい。

図１２は、いくつかの実施形態に係る、電子メールシステムを通して電子メールが送受信される際に電子メールにタグ付けする方法を示す図である。この方法は、図１で説明したシステムを使用して実行することができる。以下で説明されるステップの各々は、本開示の上記各種図面およびセクションにおいて詳細に説明されている。したがって、以下で説明されるステップの各々は、本明細書の他の場所で説明されるこれらのステップに関連する特徴のうちのいずれかを含み得る。

この方法は、電子メール情報を第１の電子メールクライアントから受信すること（１２０２）を含み得る。いくつかの実施形態において、電子メール情報は、第１の電子メールクライアントから第２の電子メールクライアントに送信される電子メールメッセージに関連付けられてもよい。第１の電子メールクライアントは送信側電子メールクライアントであってもよく、第２の電子メールクライアントは受信側電子メールクライアントであってもよい。電子メール情報は、電子メール本文、件名、ヘッダ、受信者リストなどのような任意のメタデータまたは記述情報を含み得る。電子メールは、第１の電子メールクライアントから、タグ予測モデルを操作するタグ予測サーバに送信されてもよい。電子メール情報は、電子メールメッセージが作成されているときであって第１の電子メールクライアントから送信される前に送信されてもよい。

この方法はまた、電子メール情報をモデルに提供するステップ（１２０４）を含み得る。モデルは、複数のタグのスコアを生成することができる。モデルは、図８～図１１において説明した、変化するウィンドウサイズを有する複数のフィルタを備えた畳み込みニューラルネットワークであってもよい。タグは、特定の組織、ユーザグループ、下位組織、またはユーザおよび／または電子メールメッセージの他のグループ分けに固有の、使用可能タグのセットからロードされてもよい。

この方法はさらに、スコアに少なくとも一部に基づいて、複数のタグのサブセットを識別することを含み得る（１２０６）。サブセットは、上記予測タグのセットを含み得る。使用可能なタグのスコアは、しきい値と比較されてもよく、しきい値を上回るタグが予測タグとして使用されてもよい。予測タグとして使用される使用可能なタグのサブセットは、電子メール情報において表現されるアイデアまたはコンセプトに関連し得る。スコアは、対応するタグと電子メールメッセージとの間の関係における信頼度スコアを表し得る。いくつかの実施形態において、複数のタグのサブセットも、電子メールメッセージ内の特定のテキスト選択に関連付けられる１つ以上のタグを含み得る。特定のテキスト選択は、図１０で説明したアテンションベクトル／行列を使用して識別することができる。

この方法は、予測タグのセットを第１の電子メールクライアントに送信することをさらに含み得る（１２０８）。これらの予測タグは、図２Ａ～図２Ｄにおいて示したユーザのためのユーザインターフェイスに表示されてもよい。ユーザが、予測タグを、編集、修正、追加、削除、および／または変更することを可能にしてもよい。たとえば、ユーザは、予測タグのうちのいくつかを削除することができ、これは、予測タグから選択されたタグのグループおよび選択されていないタグのグループを形成することができる。ユーザはまた、予測タグリストの一部ではない新規タグを追加してもよい。いくつかの実施形態において、サブセットの一部として選択されなかった複数のタグのうちのタグは、オートコンプリート機能を実行するためにサーバにおいて参照されてもよい。最終タグリストがユーザによって設定されると、タグは、電子メールヘッダ内などの、電子メールの一部として、埋め込まれてもよい。次に、タグは、電子メールとともに電子メールサーバに送信されてもよく、電子メールサーバは、電子メールを受信側電子メールクライアントに転送してもよい。先に詳細に説明されたように、サーバは、任意で、電子メールが電子メールサーバを通して送られ受信側電子メールクライアントにおいて受信される際に、モデルを再訓練および／またはタグリストを修正してもよい。

上記タグの各セットは、任意の数のタグを含み得る。したがって、場合によっては、タグのセットは、単一のタグを含む、複数のタグを含む、またはタグを含まない場合がある。タグのサブセットは、親セットからのタグのすべてを含み得る。たとえば、プロセスは、スコアがそれを示すのであれば、使用可能なタグのすべてを予測タグとして識別してもよい。

図１２に示される特定のステップは、各種実施形態に係る電子メールシステムを通して電子メールが送受信されるときに電子メールにタグ付けする特定の方法を提供することを、理解されたい。ステップの他のシーケンスを代替の実施形態に従って実行することもできる。たとえば、本発明の代替実施形態は、概要を説明したステップを異なる順序で実施してもよい。さらに、図１２に示される個々のステップは、個々のステップの必要に応じてさまざまなシーケンスで実行することができる複数のサブステップを含み得る。さらに、特定の用途に応じて追加のステップを加えるまたは削除することができる。当業者は、多数の変形、変更、および代替形を認識するであろう。

本明細書に記載の各方法は、コンピュータシステムによって実現することができる。これらの方法の各ステップは、当該コンピュータシステムが自動的に実行してもよく、および／またはユーザを必要とする入力／出力が与えられてもよい。たとえば、ユーザが方法の各ステップに対して入力を与えてもよく、これらの入力は各々、このような入力を要求する、コンピュータシステムが生成した特定の出力に応じて与えられてもよい。各入力は、対応する要求出力に応じて受けられてもよい。さらに、入力は、ユーザから受けられてもよく、別のデータシステムからデータストリームとして受けられてもよく、メモリロケーションから取り出されてもよく、ネットワークを介して取り出されてもよく、ウェブサービスから要求されてもよく、および／またはその他であってもよい。同様に、出力は、ユーザに与えられてもよく、データストリームとして別のコンピュータシステムに与えられてもよく、メモリロケーションに保存されてもよく、ネットワークを介して送られてもよく、ウェブサービスに与えられてもよく、および／またはその他であってもよい。すなわち、本明細書に記載の方法の各ステップは、コンピュータシステムが実行し得るものであり、かつ、ユーザを必要とするもしくは必要としないかもしれないコンピュータシステムに対する、任意の数の入力、当該コンピュータシステムからの出力、および／または当該コンピュータシステムへの／からの要求を必要とし得るものである。ユーザを必要としないステップは、人の介入なしでコンピュータシステムが自動的に実行し得ると言える。したがって、本開示に照らして、本明細書に記載の各方法の各ステップは、ユーザへのおよびユーザからの入力および出力を含むように変更されてもよく、または、プロセッサが何らかの判断を行う場合は人の介入なしでコンピュータシステムが自動的に行ってもよい。さらに、本明細書に記載の各方法のいくつかの実施形態は、有形の非一時的な記憶媒体に格納されて有形のソフトウェアプロダクトを形成する一組の命令として実現されてもよい。

図１３は、実施形態のうちの１つを実現するための分散型システム１３００の簡略図を示す。示されている実施形態において、分散型システム１３００は１つ以上のクライアントコンピューティングデバイス１３０２、１３０４、１３０６、および１３０８を含み、これらのクライアントコンピューティングデバイスは、１つ以上のネットワーク１３１０を介してウェブブラウザ、専用クライアント（たとえばOracle（登録商標） Forms）などのようなクライアントアプリケーションを実行し操作するように構成されている。サーバ１３１２が、ネットワーク１３１０を介してリモートクライアントコンピューティングデバイス１３０２、１３０４、１３０６、および１３０８に対して通信可能に結合されていてもよい。

各種実施形態において、サーバ１３１２は、このシステムのコンポーネントのうちの１つ以上が提供する１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされてもよい。いくつかの実施形態において、これらのサービスは、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および／または１３０８のユーザに対し、ウェブベースのもしくはクラウドサービスとして、またはサービスとしてのソフトウェア（ＳａａＳ）モデルのもとで、提供されてもよい。そうすると、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および／または１３０８を操作しているユーザは、１つ以上のクライアントアプリケーションを利用してサーバ１３１２とやり取りすることにより、これらのコンポーネントが提供するサービスを利用することができる。

図面に示される構成において、システム１３００のソフトウェアコンポーネント１３１８、１３２０および１３２２は、サーバ１３１２上に実装されたものとして示されている。他の実施形態において、システム１３００のコンポーネントおよび／またはこれらのコンポーネントが提供するサービスのうちの１つ以上が、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および／または１３０８のうちの１つ以上によって実装されてもよい。そうすると、クライアントコンピューティングデバイスを操作しているユーザは、１つ以上のクライアントアプリケーションを利用することにより、これらのコンポーネントが提供するサービスを使用することができる。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはその組み合わせで実装されてもよい。分散型システム１３００とは異なり得るさまざまな異なるシステム構成が可能であることが理解されるはずである。図面に示される実施形態はしたがって、実施形態のシステムを実装するための分散型システムの一例であって、限定を意図したものではない。

クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および／または１３０８は、Microsoft Windows Mobile（登録商標）等のソフトウェア、および／またはiOS、Windows Phone、Android、BlackBerry 10、Palm OSその他等のさまざまなモバイルオペレーティングシステムを実行し、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ）、Blackberry（登録商標）、またはその他の通信プロトコルに接続可能な、ポータブルハンドヘルドデバイス（たとえばiPhone（登録商標）、携帯電話、iPad（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）であってもよい。クライアントコンピューティングデバイスは、例として、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステムを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む汎用パーソナルコンピュータであってもよい。クライアントコンピューティングデバイスは、限定されないがたとえばGoogle Chrome OS等のさまざまなGNU/Linux（登録商標）オペレーティングシステムを含む市場で入手可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステムのうちのいずれかを実行するワークステーションコンピュータであってもよい。これに代えてまたはこれに加えて、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および１３０８は、ネットワーク１３１０を介して通信可能な、シンクライアントコンピュータ、インターネット接続可能なゲームシステム（たとえばKinect（登録商標）ジェスチャー入力デバイスを有するまたは有しないMicrosoft Xboxゲームコンソール）、および／またはパーソナルメッセージングデバイス等の、電子デバイスであってもよい。

具体例としての分散型システム１３００が４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがサーバ１３１２とやり取りしてもよい。

分散型システム１３００のネットワーク１３１０は、限定されないがＴＣＰ／ＩＰ（transmission control protocol/Internet protocol）、ＳＮＡ（systems network architecture）、ＩＰＸ（Internet packet exchange）、AppleTalk（登録商標）などを含む、市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。一例にすぎないが、ネットワーク１３１０は、たとえばイーサネット（登録商標）、トークンリングおよび／または同様のものに基づく、ローカルエリアネットワーク（ＬＡＮ）であってもよい。ネットワーク１３１０は、広域ネットワークおよびインターネットであってもよい。これは、限定されないが仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえばInstitute of Electrical and Electronics（ＩＥＥＥ）８０２．１１プロトコルスイート、Bluetooth（登録商標）、および／または任意の他の無線プロトコルのうちのいずれかの下で動作するネットワーク）、および／または上記および／またはその他のネットワークの任意の組み合わせを含む、仮想ネットワークを含み得る。

サーバ１３１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを含む）、サーバファーム、サーバクラスタ、または、その他任意の適切な構成および／または組み合わせからなるものであってもよい。各種実施形態において、サーバ１３１２は、上の開示で説明した１つ以上のサービスまたはソフトウェアアプリケーションを実行するようにされていてもよい。たとえば、サーバ１３１２は、本開示の実施形態に係る上記処理を実行するためのサーバに対応していてもよい。

サーバ１３１２は、上記オペレーティングシステムのうちのいずれかおよび市場で入手可能なサーバオペレーティングシステムを含むオペレーティングシステムを実行し得る。また、サーバ１３１２は、ＨＴＴＰ（hypertext transport protocol）サーバ、ＦＴＰ（file transfer protocol）サーバ、ＣＧＩ（common gateway interface）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、さまざまな付加的なサーバアプリケーションおよび／またはミッドティアアプリケーションのうちのいずれかを実行し得る。具体例としてのデータベースサーバは、Oracle、Microsoft、Sybase、ＩＢＭ（International Business Machines）などから市販されているものを含むが、これらに限定されない。

いくつかの実装例において、サーバ１３１２は、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および１３０８のユーザから受信したデータフィードおよび／またはイベントアップデートを分析し統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、限定されないが、１つ以上の第三者情報源および連続データストリームから受信したTwitter（登録商標）フィード、Facebook（登録商標）アップデートまたはリアルタイムアップデートを含み得る。これらはセンサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などに関連するリアルタイムイベントを含み得る。また、サーバ１３１２は、クライアントコンピューティングデバイス１３０２、１３０４、１３０６、および１３０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含み得る。

分散型システム１３００は、１つ以上のデータベース１３１４および１３１６も含み得る。データベース１３１４および１３１６はさまざまな場所に存在し得る。一例として、データベース１３１４および１３１６のうちの１つ以上は、サーバ１３１２に対してローカルな場所にある（および／またはサーバ内にある）非一時的な記憶媒体上にあってもよい。これに代えて、データベース１３１４および１３１６は、サーバ１３１２から遠隔の場所に位置してネットワークベースのまたは専用接続を介してサーバ１３１２と通信してもよい。一組の実施形態において、データベース１３１４および１３１６は、ストレージエリアネットワーク（ＳＡＮ）内にあってもよい。同様に、サーバ１３１２に帰する機能を実行するために必要な任意のファイルを、適宜、サーバ１３１２にローカルにおよび／またはサーバ１３１２から遠隔の場所に格納してもよい。一組の実施形態において、データベース１３１４および１３１６は、ＳＱＬフォーマットのコマンドに応答してデータを格納し、アップデートし、取り出すようにされた、Oracleが提供するデータベース等のリレーショナルデータベースを含み得る。

図１４は、本開示の実施形態に係る、実施形態のシステムの１つ以上のコンポーネントがサービスをクラウドサービスとして提供し得るシステム環境１４００の１つ以上のコンポーネントの簡略化されたブロック図である。示されている実施形態において、システム環境１４００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１４０２とやり取りするためにユーザが使用し得る１つ以上のクライアントコンピューティングデバイス１４０４、１４０６、および１４０８を含む。クライアントコンピューティングデバイスは、クライアントコンピューティングデバイスのユーザがクラウドインフラストラクチャシステム１４０２とやり取りすることによってクラウドインフラストラクチャシステム１４０２が提供するサービスを使用するために用いることができる、ウェブブラウザ、専用クライアントアプリケーション（たとえばOracle Forms）、またはその他何らかのアプリケーション等のクライアントアプリケーションを操作するように構成されてもよい。

図面に示されているクラウドインフラストラクチャシステム１４０２は示されているもの以外のコンポーネントを有し得ることが理解されるはずである。さらに、図面に示されている実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例にすぎない。他のいくつかの実施形態において、クラウドインフラストラクチャシステム１４０２は、図示されているものよりも多いまたは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成または配置を有していてもよい。

クライアントコンピューティングデバイス１４０４、１４０６、および１４０８は、１３０２、１３０４、１３０６、および１３０８について先に述べたものと同様のデバイスであってもよい。

具体例としてのシステム環境１４００は３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスをサポートすることができる。センサなどを有するデバイスのようなその他のデバイスがクラウドインフラストラクチャシステム１４０２とやり取りしてもよい。

ネットワーク１４１０は、クライアント１４０４、１４０６、および１４０８とクラウドインフラストラクチャシステム１４０２との間におけるデータの通信および交換を容易にすることができる。各ネットワークは、ネットワーク１３１０について先に述べたものを含む市場で入手可能なさまざまなプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られた任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム１４０２は、１つ以上のコンピュータ、および／またはサーバ１３１２について先に述べたものを含み得るサーバを含み得る。

特定の実施形態において、クラウドインフラストラクチャシステムが提供するサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされているオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理された技術サポートサービスなどのような、クラウドインフラストラクチャシステムのユーザがオンデマンドで利用できるようにされる多数のサービスを含み得る。クラウドインフラストラクチャシステムが提供するサービスは、そのユーザのニーズに合わせて動的にスケーリングすることができる。クラウドインフラストラクチャシステムが提供するサービスを具体的にインスタンス化したものを本明細書では「サービスインスタンス」と呼ぶ。一般的に、クラウドサービスプロバイダのシステムからの、インターネットのような通信ネットワークを介してユーザが利用できるようにされる任意のサービスを、「クラウドサービス」と呼ぶ。典型的に、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストすることができ、ユーザは、インターネットのような通信ネットワークを介して、オンデマンドでこのアプリケーションをオーダーし使用することができる。

いくつかの例において、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、クラウドベンダーによってまたは当該技術において周知の他のやり方でユーザに提供される、ストレージ、ホストされているデータベース、ホストされているウェブサーバ、ソフトウェアアプリケーション、またはその他のサービスに対する保護されたコンピュータネットワークアクセスを含み得る。たとえば、サービスは、インターネットを介した、クラウド上の遠隔ストレージに対するパスワードで保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク化された開発者の私的使用のための、ウェブサービスベースのホストされているリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダーのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。

特定の実施形態において、クラウドインフラストラクチャシステム１４０２は、セルフサービスで、サブスクリプションベースで、弾力的にスケーラブルで、信頼性が高く、可用性が高く、かつ安全なやり方で顧客に与えられる、アプリケーション、ミドルウェア、およびデータベースサービス提供物一式を含み得る。そのようなクラウドインフラストラクチャシステムの一例は、本願の譲受人が提供するOracle Public Cloudである。

各種実施形態において、クラウドインフラストラクチャシステム１４０２は、クラウドインフラストラクチャシステム１４０２が提供するサービスに対する顧客のサブスクリプションを自動的にプロビジョニングし、管理し、追跡するようにされていてもよい。クラウドインフラストラクチャシステム１４０２は、異なるデプロイメントモデルを介してクラウドサービスを提供することができる。たとえば、（例としてOracle所有の）クラウドサービスを販売する組織がクラウドインフラストラクチャシステム１４０２を所有しており一般の人々または異なる産業企業がサービスを利用できるようにされるパブリッククラウドモデルの下で、サービスが提供されてもよい。別の例として、クラウドインフラストラクチャシステム１４０２が１つの組織のためにのみ運営されこの組織内の１つ以上のエンティティのためにサービスを提供し得るプライベートクラウドモデルの下で、サービスが提供されてもよい。また、クラウドインフラストラクチャシステム１４０２およびクラウドインフラストラクチャシステム１４０２が提供するサービスを関連するコミュニティー内のいくつかの組織が共有するコミュニティークラウドモデルの下で、クラウドサービスが提供されてもよい。また、２つ以上の異なるモデルの組み合わせであるハイブリッドクラウドモデルの下で、クラウドサービスが提供されてもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム１４０２が提供するサービスは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリ、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリ、サービスとしてのインフラストラクチャ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含むサービスの他のカテゴリの下で提供される、１つ以上のサービスを含み得る。顧客は、クラウドインフラストラクチャシステム１４０２が提供する１つ以上のサービスを、サブスクリプションオーダーを通じてオーダーすることができる。そうすると、クラウドインフラストラクチャシステム１４０２は、この顧客のサブスクリプションオーダーのサービスを提供するために処理を実行する。

いくつかの実施形態において、クラウドインフラストラクチャシステム１４０２が提供するサービスは、限定されないが、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含み得る。いくつかの例において、アプリケーションサービスは、クラウドインフラストラクチャシステムがＳａａＳプラットフォームを介して提供することができる。ＳａａＳプラットフォームは、ＳａａＳカテゴリに含まれるクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、統合開発およびデプロイメントプラットフォーム上でオンデマンドアプリケーション一式を構築し配信する機能を提供することができる。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。ＳａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用することが可能である。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、アプリケーションサービスを得ることが可能である。さまざまな異なるＳａａＳサービスを提供することができる。例は、限定されないが、大組織向けの販売実績管理、企業統合、およびビジネスフレキシビリティのためのソリューションを提供するサービスを含む。

いくつかの実施形態において、プラットフォームサービスは、クラウドインフラストラクチャシステムがＰａａＳプラットフォームを介して提供することができる。ＰａａＳプラットフォームは、ＰａａＳカテゴリに含まれるクラウドサービスを提供するように構成し得る。プラットフォームサービスの例は、限定されないが、共有されている共通アーキテクチャ上の既存のアプリケーションを組織（Oracle等）が統合することを可能にするサービスと、当該プラットフォームが提供する共有サービスを推進する新たなアプリケーションを構築する機能とを含み得る。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理し制御することができる。顧客は、顧客が別々のライセンスおよびサポートを購入しなくても、クラウドインフラストラクチャシステムが提供するＰａａＳサービスを得ることが可能である。プラットフォームサービスの例は、限定されないが、Oracle Java Cloud Service（ＪＣＳ）、Oracle Database Cloud Service（ＤＢＣＳ）その他を含む。

ＰａａＳプラットフォームが提供するサービスを利用することにより、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばOracle Fusion Middlewareサービス）、およびＪａｖａクラウドサービスを含み得る。一実施形態において、データベースクラウドサービスは、組織がデータベースリソースをプールしデータベースクラウドの形態でサービスとしてのデータベース（Database as a Service）を顧客に提供することを可能にする共有サービスデプロイメントモデルをサポートすることができる。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発しデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、クラウドインフラストラクチャシステムにおいて顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。

さまざまな異なるインフラストラクチャサービスは、クラウドインフラストラクチャシステムにおいてＩａａＳプラットフォームが提供してもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用する顧客のためのストレージ、ネットワーク、および他の基本的なコンピューティングリソース等の、基礎となるコンピューティングリソースの管理および制御を容易にする。

特定の実施形態において、クラウドインフラストラクチャシステム１４０２はまた、クラウドインフラストラクチャシステムの顧客にさまざまなサービスを提供するために用いられるリソースを提供するためのインフラストラクチャリソース１４３０を含み得る。一実施形態において、インフラストラクチャリソース１４３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームが提供するサービスを実行するためのサーバ、ストレージ、およびネットワーキングリソース等のハードウェアの、予め統合し最適化した組み合わせを含み得る。

いくつかの実施形態において、クラウドインフラストラクチャシステム１４０２におけるリソースは、複数のユーザによって共有され要求ごとに動的に再割り当てされてもよい。加えて、リソースは、異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム１４３０は、第１のタイムゾーンの第１組のユーザが指定された時間数だけクラウドインフラストラクチャシステムのリソースを利用することを可能にし、それから、異なるタイムゾーンにいる別の１組のユーザに対して同じリソースを再割り当てすることにより、リソースの利用を最大化することができる。

特定の実施形態において、クラウドインフラストラクチャシステム１４０２の異なるコンポーネントまたはモジュールによって共有され、クラウドインフラストラクチャシステム１４０２が提供するサービスによって共有される、複数の内部共有サービス１４３２を提供することができる。これらの内部共有サービスは、限定されないが、セキュリティおよびアイデンティティサービス、統合サービス、企業リポジトリサービス、企業マネージャーサービス、ウィルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、電子メールサービス、通知サービス、ファイル転送サービスなどを含み得る。

特定の実施形態において、クラウドインフラストラクチャシステム１４０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的管理を提供し得る。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１４０２が受けた顧客のサブスクリプションをプロビジョニング、管理、および追跡する機能を含み得る。

一実施形態において、図面に示されるように、クラウド管理機能は、オーダー管理モジュール１４２０、オーダーオーケストレーションモジュール１４２２、オーダープロビジョニングモジュール１４２４、オーダー管理およびモニタリングモジュール１４２６、ならびにアイデンティティ管理モジュール１４２８等の、１つ以上のモジュールによって提供されてもよい。これらのモジュールは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他任意の適切な構成および／または組み合わせであってもよい、１つ以上のコンピュータおよび／またはサーバを含み得る、または、これらを用いて提供し得る。

具体例としての動作１４３４において、クライアントデバイス１４０４、１４０６または１４０８等のクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム１４０２が提供する１つ以上のサービスを要求すること、および、クラウドインフラストラクチャシステム１４０２が提示する１つ以上のサービスのサブスクリプションをオーダーすることにより、クラウドインフラストラクチャシステム１４０２とやり取りしてもよい。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ １４１２、クラウドＵＩ １４１４および／またはクラウドＵＩ １４１６にアクセスしこれらのＵＩを介してサブスクリプションオーダーを行ってもよい。顧客がオーダーを行ったことに応じてクラウドインフラストラクチャシステム１４０２が受けるオーダー情報は、顧客を特定する情報と、クラウドインフラストラクチャシステム１４０２が提供する、顧客がサブスクライブする予定の１つ以上のサービスとを含み得る。

顧客がオーダーを行った後に、オーダー情報は、クラウドＵＩ １４１２、１４１４および／または１４１６を介して受信される。

動作１４３６において、オーダーはオーダーデータベース１４１８に格納される。オーダーデータベース１４１８は、クラウドインフラストラクチャシステム１４１８によって運営され他のシステム要素とともに運営されるいくつかのデータベースのうちの１つであってもよい。

動作１４３８において、オーダー情報はオーダー管理モジュール１４２０に転送されてもよい。いくつかの例において、オーダー管理モジュール１４２０は、オーダーを確認し確認後にオーダーを記入する等の、オーダーに関連する課金および会計機能を行うように構成されてもよい。

動作１４４０において、オーダーに関する情報は、オーダーオーケストレーションモジュール１４２２に伝えられる。オーダーオーケストレーションモジュール１４２２は、オーダー情報を利用することにより、顧客によって行われたオーダーのためのサービスおよびリソースのプロビジョニングをオーケストレーションするように構成されてもよい。いくつかの例において、オーダーオーケストレーションモジュール１４２２は、リソースのプロビジョニングをオーケストレーションすることにより、オーダープロビジョニングモジュール１４２４のサービスを使用するサブスクライブされたサービスを、サポートしてもよい。

特定の実施形態において、オーダーオーケストレーションモジュール１４２２は、各オーダーに関連付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用することにより、オーダーがプロビジョニングに進むべきか否かを判断する。動作１４４２において、新規サブスクリプションのオーダーを受けると、オーダーオーケストレーションモジュール１４２２は、サブスクリプションオーダーを遂行するのに必要なリソースを割り当てて構成することを求める要求を、オーダープロビジョニングモジュール１４２４に送る。オーダープロビジョニングモジュール１４２４は、顧客がオーダーしたサービスのためのリソースの割り当てを可能にする。オーダープロビジョニングモジュール１４２４は、クラウドインフラストラクチャシステム１４００が提供するクラウドサービスと、要求されたサービスを提供するためのリソースのプロビジョニングに使用される物理実装層との間の抽象化レベルを提供する。このようにして、オーダーオーケストレーションモジュール１４２２を、サービスおよびリソースが実際にオンザフライでプロビジョニングされるか否か、または、予めプロビジョニングされており要求後に割り当て／アサインされるか否か等の、実装の詳細から切り離すことができる。

動作１４４４において、サービスおよびリソースがプロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム１４０２のオーダープロビジョニングモジュール１４２４によってクライアントデバイス１４０４、１４０６および／または１４０８の顧客に送信されてもよい。

動作１４４６において、顧客のサブスクリプションオーダーは、オーダー管理およびモニタリングモジュール１４２６によって管理および追跡されてもよい。いくつかの例において、オーダー管理およびモニタリングモジュール１４２６は、ストレージ使用量、転送データ量、ユーザ数、ならびにシステムアップタイムおよびシステムダウンタイムの量等の、サブスクリプションオーダーにおけるサービスの使用統計を収集するように構成されてもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１４００はアイデンティティ管理モジュール１４２８を含み得る。アイデンティティ管理モジュール１４２８は、クラウドインフラストラクチャシステム１４００におけるアクセス管理および認可サービス等のアイデンティティサービスを提供するように構成されてもよい。いくつかの実施形態において、アイデンティティ管理モジュール１４２８は、クラウドインフラストラクチャシステム１４０２が提供するサービスの利用を所望する顧客に関する情報を管理してもよい。そのような情報は、このような顧客のアイデンティティを認証する情報と、さまざまなシステムリソース（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に関してこれらの顧客が実行を認可されるアクションを記述する情報とを含み得る。アイデンティティ管理モジュール１４２８は、各顧客に関し、かつ、誰が如何にしてこの記述情報にアクセスし修正することができるかに関する記述情報の管理も含み得る。

図１５は、本発明の各種実施形態を実現し得る具体例としてのコンピュータシステム１５００を示す。システム１５００を用いることにより、上記コンピュータシステムのうちのいずれかを実現することができる。図面に示されるように、コンピュータシステム１５００は、バスサブシステム１５０２を介して複数の周辺サブシステムと通信する処理ユニット１５０４を含む。これらの周辺サブシステムは、処理加速ユニット１５０６と、入出力サブシステム１５０８と、ストレージサブシステム１５１８と、通信サブシステム１５２４とを含み得る。ストレージサブシステム１５１８は、有形のコンピュータ読取可能記憶媒体１５２２とシステムメモリ１５１０とを含み得る。

バスサブシステム１５０２は、コンピュータシステム１５００の各種コンポーネントおよびサブシステムを目的に合わせて互いに通信させるためのメカニズムを提供する。バスサブシステム１５０２は１つのバスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを利用し得る。バスサブシステム１５０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、Industry Standard Architecture（ＩＳＡ）バス、Micro Channel Architecture（ＭＣＡ）バス、Enhanced ISA（ＥＩＳＡ）バス、Video Electronics Standards Association（ＶＥＳＡ）ローカルバス、および、ＩＥＥＥ Ｐ１３８６．１規格に準拠して製造されたMezzanineバスとして実装することができるPeripheral Component Interconnect（ＰＣＩ）バスを含み得る。

１つ以上の集積回路（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）として実現することができる処理ユニット１５０４は、コンピュータシステム１５００の動作を制御する。１つ以上のプロセッサが処理ユニット１５０４に含まれていてもよい。これらのプロセッサはシングルコアまたはマルチコアプロセッサを含み得る。特定の実施形態において、処理ユニット１５０４は、１つ以上の独立した処理ユニット１５３２および／または１５３４として、各処理ユニットに含まれるシングルまたはマルチコアプロセッサとともに実現されてもよい。他の実施形態において、処理ユニット１５０４はまた、２つのデュアルコアプロセッサを１つのチップに統合することによって形成されるクアッドコア処理ユニットとして実現されてもよい。

各種実施形態において、処理ユニット１５０４は、プログラムコードに応じてさまざまなプログラムを実行することができ、かつ、同時に実行している複数のプログラムまたはプロセスを管理することができる。ある所定の時点で、実行すべきプログラムコードのうちの一部またはすべてが、プロセッサ１５０４および／またはストレージサブシステム１５１８にあってもよい。適切なプログラミングを通して、プロセッサ１５０４は上記各種機能を提供することができる。コンピュータシステム１５００はさらに、デジタル信号プロセッサ（ＤＳＰ）、専用プロセッサ、および／またはその他同様のものを含むことができる、処理加速ユニット１５０６を含み得る。

入出力サブシステム１５０８は、ユーザインターフェイス入力デバイスと、ユーザインターフェイス出力デバイスとを含み得る。ユーザインターフェイス入力デバイスは、キーボード、マウスまたはトラックボール等のポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声コマンド認識システム付きの音声入力デバイス、マイク、およびその他のタイプの入力デバイスを含み得る。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャーおよび発話コマンドを使用するナチュラルユーザインターフェイスを通してユーザが入力デバイスを制御し入力デバイスとやり取りすることを可能にする、Microsoft Xbox（登録商標）３６０ゲームコントローラ等のMicrosoft Kinect（登録商標）モーションセンサのような、モーション検知および／またはジェスチャー認識デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、ユーザの目の活動（たとえば写真撮影中および／またはメニュー選択中の「まばたき」）を検出し目のジェスチャーを入力デバイス（たとえばGoogle Glass（登録商標）)への入力として変換する、Google Glass（登録商標）まばたき検出器等のアイジェスチャー認識デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通して音声認識システム（たとえばSiri（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含み得る。

ユーザインターフェイス入力デバイスはまた、限定されないが、３次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、およびスピーカ等のオーディオ／ビジュアルデバイス、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレイヤー、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダー３Ｄスキャナ、３Ｄプリンタ、レーザ測距装置、および視線追跡デバイスを含み得る。加えて、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影装置、磁気共鳴撮像装置、ポジトロン断層撮影装置、医療用超音波検査装置等の医療用撮像入力デバイスを含み得る。ユーザインターフェイス入力デバイスはまた、たとえば、ＭＩＤＩキーボード、デジタル楽器などのような音声入力装置を含み得る。

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、表示灯、または音声出力装置等の非視覚的ディスプレイなどを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを用いるもの等のフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般的に、「出力デバイス」という用語を使用する場合は、コンピュータシステム１５００からユーザまたは他のコンピュータに情報を出力するための可能なすべてのタイプのデバイスおよびメカニズムを含むことを意図している。たとえば、ユーザインターフェイス出力デバイスは、限定されないが、モニタ、プリンタ、スピーカ、ヘッドホン、カーナビゲーションシステム、プロッタ、音声出力デバイス、およびモデム等の、テキスト、図形、およびオーディオ／ビデオ情報を視覚的に伝えるさまざまなディスプレイデバイスを含み得る。

コンピュータシステム１５００は、現在はシステムメモリ１５１０内にあるものとして示されているソフトウェア要素を含むストレージサブシステム１５１８を含み得る。システムメモリ１５１０は、処理ユニット１５０４上にローディング可能であり処理ユニット上で実行可能なプログラム命令と、これらのプログラムの実行中に生成されたデータとを格納することができる。

コンピュータシステム１５００の構成および種類に応じて、システムメモリ１５１０は、揮発性（たとえばランダムアクセスメモリ（ＲＡＭ））であってもよく、および／または不揮発性（たとえば読出専用メモリ（ＲＯＭ）、フラッシュメモリなど）であってもよい。典型的に、ＲＡＭは、処理ユニット１５０４が直ちにアクセス可能でありおよび／または現在操作し実行している、データおよび／またはプログラムモジュールを含む。いくつかの実装例において、システムメモリ１５１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）等の複数の異なる種類のメモリを含み得る。いくつかの実装例において、たとえば起動中のコンピュータシステム１５００内の要素間の情報の転送を支援する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、典型的にはＲＯＭに格納することができる。例として、限定されないが、システムメモリ１５１０はまた、クライアントアプリケーション、ウェブブラウザ、ミッドティアアプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含み得るアプリケーションプログラム１５１２と、プログラムデータ１５１４と、オペレーティングシステム１５１６とを示している。例として、オペレーティングシステム１５１６は、さまざまなバージョンのMicrosoft Windows（登録商標）、Apple Macintosh（登録商標）、および／またはLinux（登録商標）オペレーティングシステム、市場で入手可能な多様なUNIX（登録商標）またはUNIX（登録商標）系オペレーティングシステム（限定されないが多様なGNU/Linux（登録商標）オペレーティングシステム、Google Chrome（登録商標）OSなどを含む）、および／またはiOS、Windows（登録商標）Phone、Android（登録商標） OS、BlackBerry（登録商標） 10 OS、およびPalm（登録商標） OSオペレーティングシステム等のモバイルオペレーティングシステムを含み得る。

ストレージサブシステム１５００はまた、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ読取可能記憶媒体を提供することができる。プロセッサによって実行されると上記機能を実行するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム１５１８に格納することができる。これらのソフトウェアモジュールまたは命令は、処理ユニット１５０４によって実行されてもよい。ストレージサブシステムｙ１５１８はまた、本発明に従い使用されるデータを格納するためのリポジトリを提供することができる。

ストレージサブシステム１５１８はまた、コンピュータ読取可能記憶媒体１５２２にさらに接続することが可能なコンピュータ読取可能記憶媒体リーダ１５２０を含み得る。システムメモリ１５１０とともに、また、任意でシステムメモリ１５１０と組み合わされて、コンピュータ読取可能記憶媒体１５２２は、コンピュータ読取可能情報を一時的におよび／またはより恒久的に含む、格納する、送信する、および取り出すための、リモート、ローカル、固定、および／またはリムーバブル記憶装置プラス記憶媒体を包括的に表すことができる。

コードまたはコードの一部を含むコンピュータ読取可能記憶媒体１５２２はまた、限定されないが、情報の記憶および／または送信のための任意の方法または技術で実現される、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体等の、記憶媒体および通信媒体を含む、当該技術において周知のまたは使用されている適切な任意の媒体を含み得る。これは、ＲＡＭ、ＲＯＭ、電子的に消去可能プログラム可能なＲＯＭ（ＥＥＰＲＯＭ）、フラッシュメモリまたはその他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）、もしくはその他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくはその他の磁気記憶装置、または、他の有形のコンピュータ読取可能媒体等の、有形のコンピュータ読取可能記憶媒体を含み得る。これはまた、所望の情報を送信するために使用することができコンピューティングシステム１５００がアクセスすることができる、データ信号、データ送信、またはその他任意の媒体等の、非有形コンピュータ読取可能媒体を含み得る。

例として、コンピュータ読取可能記憶媒体１５２２は、非リムーバブル不揮発性磁気媒体からの読取およびこの媒体への書込を行うハードディスクドライブ、リムーバブル不揮発性磁気ディスクからの読取およびこのディスクへの書込を行う磁気ディスクドライブ、ならびに、ＣＤ ＲＯＭ、ＤＶＤ、Blu-Ray（登録商標）ディスク、またはその他の光学媒体等のリムーバブル不揮発性光ディスクからの読取およびこのディスクへの書込を行う光ディスクドライブを含み得る。コンピュータ読取可能記憶媒体１５２２は、限定されないが、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含み得る。コンピュータ読取可能記憶媒体１５２２はまた、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどのような、不揮発性メモリベースのソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ等の揮発性メモリベースのＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、ならびにＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組み合わせを用いるハイブリッドＳＳＤを、含み得る。ディスクドライブおよびこれらに対応付けられたコンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、およびコンピュータシステム１５００のためのその他のデータの不揮発性ストレージを提供することができる。

通信サブシステム１５２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１５２４は、他のシステムからデータを受信し、コンピュータシステム１５００から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム１５２４は、コンピュータシステム１５００がインターネットを介して１つ以上のデバイスに接続することを可能にする。いくつかの実施形態において、通信サブシステム１５２４は、（たとえば携帯電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（enhanced data rates for global evolution）等の高度データネットワーク技術、ＷｉＦｉ（登録商標）（ＩＥＥＥ ８０２．１１系規格、または他の移動通信技術、またはそれらの任意の組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバーコンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、および／またはその他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム１５２４は、無線インターフェイスに加えてまたはその代わりに、有線ネットワークコネクティビティ（たとえばイーサネット（登録商標））を提供することができる。

いくつかの実施形態において、通信サブシステム１５２４は、コンピュータシステム１５００を使用し得る１人以上のユーザの代わりに、構造化および／または非構造化データフィード１５２６、イベントストリーム１５２８、イベントアップデート１５３０などの形態の入力通信を受けることもできる。

例として、通信サブシステム１５２４は、Twitter（登録商標）フィード、Facebook（登録商標）アップデート、Rich Site Summary（ＲＳＳ）フィード等のウェブフィード、および／または１つ以上の第３者情報源からのリアルタイムアップデート等の、ソーシャルネットワークおよび／または他の通信サービスのユーザからのデータフィード１５２６をリアルタイムで受信するように構成されてもよい。

加えて、通信サブシステム１５２４は、明確な終わりがない本質的に連続しているまたは無限である可能性があるリアルタイムイベントのイベントストリーム１５２８および／またはイベントアップデート１５３０を含み得る、連続データストリームの形態のデータを受信するように構成されてもよい。連続データを生成するアプリケーションの例は、たとえば、センサデータアプリケーション、金融ティッカー、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通監視などを含み得る。

通信サブシステム１５２４はまた、構造化および／または非構造化データフィード１５２６、イベントストリーム１５２８、イベントアップデート１５３０などを、コンピュータシステム１５００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するように構成されてもよい。

コンピュータシステム１５００は、ハンドヘルドポータブルデバイス（たとえばiPhone（登録商標）携帯電話、iPad（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばGoogle Glass（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他任意のデータ処理システムを含む、さまざまなタイプのうちの１つであってもよい。

コンピュータおよびネットワークには常に変化しているという性質があるので、図面に示されるコンピュータシステム１５００の説明は、具体的な一例を意図しているにすぎない。図面に示されるシステムよりも多くのまたは少ないコンポーネントを有するその他多数の構成が可能である。たとえば、カスタマイズされたハードウェアが使用されてもよく、および／または特定の要素がハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組み合わせで実現されてもよい。さらに、ネットワーク入出力デバイスのようなその他のコンピューティングデバイスに対する接続を用いてもよい。本明細書で提供される開示および教示に基づいて、当業者は、各種実施形態を実現するためのその他のやり方および／または方法を理解するであろう。

上述の記載では、説明のために、本発明の各種実施形態の十分な理解が得られるよう、数多くの具体的な詳細を述べている。しかしながら、当業者には、本発明の実施形態はこれらの具体的な詳細のうちの一部がなくても実施し得ることが明らかであろう。その他の例では、周知の構造およびデバイスはブロック図の形態で示されている。

上述の記載は、具体例としての実施形態を提供しているだけであって、本開示の範囲、利用可能性、または構成を限定することを意図しているのではない。むしろ、具体例としての実施形態の上述の記載は、具体例としての実施形態を実現することを可能にする説明を当業者に提供するであろう。以下の請求項に記載の本発明の精神および範囲から逸脱することなく、要素の機能および構成に各種変更を加え得ることが理解されるはずである。

上述の記載において、具体的な詳細は、実施形態の十分な理解を得るために提供されている。しかしながら、当業者は、実施形態はこれらの具体的な詳細がなくても実現し得ることを理解するであろう。たとえば、回路、システム、ネットワーク、プロセス、およびその他のコンポーネントは、実施形態を不必要な詳細で不明瞭にすることがないよう、ブロック図の形態のコンポーネントとして示されている場合がある。その他の例において、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態を不明瞭にすることを避けるために不必要な詳細なしで示されている場合がある。

また、個々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして記載されている場合があることが注目される。フローチャートは動作を逐次プロセスとして説明している場合があるが、動作のうちの多くは並列または同時に実行することができる。加えて、動作の順序は構成し直してもよい。プロセスは、その動作が完了すると終了するが、図面に含まれていない追加のステップを有する可能性がある。プロセスは、方法、関数、手順、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応する場合、その終了は、この関数が呼び出し側関数またはメイン関数に戻ることに相当し得る。

「コンピュータ読取可能媒体」という用語は、携帯型または固定記憶装置、光記憶装置、無線チャネル、ならびに、命令および／またはデータを格納する、含む、または保持することが可能なその他の各種媒体を含むが、これらに限定される訳ではない。コードセグメントまたはマシン実行可能命令は、手順、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または、命令、データ構造、もしくはプログラムステートメントの任意の組み合わせを表し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリコンテンツを送ることおよび／または受けることにより、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む任意の適切な手段を介して、送る、転送する、または送信することができる。

さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはその任意の組み合わせによって実現することができる。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードで実現するとき、必要なタスクを実行するためのプログラムコードまたはコードセグメントは、マシン読取可能媒体に格納されていてもよい。プロセッサ（複数のプロセッサ）が必要なタスクを実行してもよい。

上述の明細書では、本発明の局面を、その具体的な実施形態を参照しながら説明しているが、本発明がこれらの実施形態に限定される訳ではないことを当業者は認識するであろう。上記発明の各種特徴および局面は、個別に使用されてもよく、またはともに使用されてもよい。さらに、実施形態は、本明細書のより広い精神および範囲から逸脱することなく、本明細書に記載の環境およびアプリケーションを超える、任意の数の環境およびアプリケーションで利用することができる。したがって、本明細書および図面は、限定的なものではなく例示的なものであるとみなされねばならない。

加えて、説明のために、方法は特定の順序で記載されている。代替実施形態においてこれらの方法は記載されている順序と異なる順序で実行され得ることが理解されるはずである。上記方法は、ハードウェアコンポーネントによって実行されてもよく、またはマシン実行可能命令のシーケンスで実施されてもよいことも、理解されるはずである。マシン実行可能命令は、当該命令でプログラミングされた汎用もしくは専用プロセッサまたは論理回路のようなマシンに当該方法を実行させるために使用することができる。これらのマシン実行可能命令は、ＣＤ－ＲＯＭもしくはその他のタイプの光ディスク、フロッピー（登録商標）ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気もしくは光カード、フラッシュメモリ、または、電子命令を格納するのに適したその他のタイプのマシン読取可能媒体等の、１つ以上のマシン読取可能媒体に、格納されてもよい。これに代えて、当該方法はハードウェアとソフトウェアとの組み合わせによって実行されてもよい。

Claims (20)

1. １つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む非一時的なコンピュータ読取可能媒体であって、前記動作は、
   電子メール情報を第１の電子メールクライアントから受信するステップを含み、前記電子メール情報は、前記第１の電子メールクライアントから第２の電子メールクライアントに送信される電子メールメッセージに関連付けられ、前記動作はさらに、
   前記電子メール情報をモデルに提供するステップを含み、前記モデルは、使用可能なタグのセットについてのスコアを生成し、前記動作はさらに、
   予測タグのセットを、前記スコアに少なくとも一部に基づいて、前記使用可能なタグのセットのサブセットとして識別するステップと、
   前記予測タグのセットを前記第１の電子メールクライアントに送信するステップとを含み、前記予測タグのセットから選択されたタグのセットが、前記電子メールメッセージが前記第２の電子メールクライアントに送信されるときに前記電子メールメッセージとともに送信される、非一時的なコンピュータ読取可能媒体。
2. 前記選択されたタグのセットは、前記電子メールが前記第２の電子メールクライアントに送信されるときに前記電子メールメッセージのヘッダに埋め込まれている、請求項１に記載の非一時的なコンピュータ読取可能媒体。
3. ユーザから受信された新規タグのプレフィックスを含む要求を前記第１の電子メールクライアントから受信するステップと、
   前記プレフィックスで始まる前記使用可能なタグのセットにおけるオートコンプリートタグのセットを識別するステップと、
   前記オートコンプリートタグのセットを前記第１のクライアントに送信するステップとをさらに含む、請求項１に記載の非一時的なコンピュータ読取可能媒体。
4. 前記予測タグのセットのうちの未選択タグのセットも、前記電子メールメッセージが前記第２の電子メールクライアントに送信されるときに前記電子メールメッセージとともに送信される、請求項１に記載の非一時的なコンピュータ読取可能媒体。
5. 前記予測タグのセットのうちのユーザタグのセットも、前記電子メールメッセージが前記第２のクライアントに送信されるときに前記電子メールメッセージとともに送信され、前記ユーザタグのセットは前記予測タグのセットと異なる、請求項１に記載の非一時的なコンピュータ読取可能媒体。
6. 前記第１の電子メールクライアントは、前記予測タグのセットを含む電子メールヘッダのディスプレイを含むユーザインターフェイスを生成するように構成される、請求項１に記載の非一時的なコンピュータ読取可能媒体。
7. 前記動作は、前記電子メール情報に基づいてハッシュキーを生成するステップをさらに含み、前記ハッシュキーは前記電子メールメッセージを一意に識別する、請求項１に記載の非一時的なコンピュータ読取可能媒体。
8. 前記動作は、前記ハッシュキーをハッシュキーのハッシュマップに格納するステップをさらに含み、前記ハッシュマップ内の前記ハッシュキーの各々は、前記予測タグのセットの一部ではない前記使用可能なタグのセットのサブセットを表すデータ構造を参照する、請求項７に記載の非一時的なコンピュータ読取可能媒体。
9. 前記データ構造は、重み付けされたプレフィックスのトライを含む、請求項８に記載の非一時的なコンピュータ読取可能媒体。
10. 前記動作は、
    前記第１の電子メールクライアントからプレフィックスと前記電子メール情報とを受信するステップと、
    前記電子メール情報を用いて前記ハッシュキーを再生成するステップと、
    前記ハッシュキーを用いて前記電子メールメッセージについてのデータ構造を参照するステップと、
    前記プレフィックスを完成させる前記使用可能なタグのセット内の１つ以上のタグを前記データ構造から取り出すステップとをさらに含む、請求項８に記載の非一時的なコンピュータ読取可能媒体。
11. 前記動作は、前記選択されたタグのセットを電子メールサーバから受信するステップをさらに含み、前記電子メールメッセージは前記電子メールサーバを通して送信される、請求項１に記載の非一時的なコンピュータ読取可能媒体。
12. 前記動作は、前記選択されたタグと異なるユーザタグのセットを前記電子メールサーバから受信するステップをさらに含む、請求項１１に記載の非一時的なコンピュータ読取可能媒体。
13. 前記動作は、前記ユーザタグのセットを用いて前記モデルを再訓練するステップをさらに含む、請求項１２に記載の非一時的なコンピュータ読取可能媒体。
14. 前記モデルは複数のモデルから選択され、前記複数のモデルのうちの各モデルは異なるユーザグループに関連付けられる、請求項１に記載の非一時的なコンピュータ読取可能媒体。
15. 異なる各ユーザグループは予め定められたメーリングリストに対応する、請求項１４に記載の非一時的なコンピュータ読取可能媒体。
16. 前記動作は、
    第２の電子メール情報を電子メールサーバから受信するステップをさらに含み、前記電子メールサーバを通して第２の電子メールメッセージが前記第１の電子メールクライアントから送信され、前記動作はさらに、
    前記第２の電子メール情報を前記モデルに提供することにより、前記使用可能なタグのセットから予測タグの第２のセットを識別するステップと、
    前記予測タグの第２のセットを前記電子メールサーバに送信するステップとを含み、前記予測タグの第２のセットは、前記第２の電子メールメッセージとともに前記第２の電子メールクライアントに送信される、請求項１に記載の非一時的なコンピュータ読取可能媒体。
17. 前記動作は、
    前記第２の電子メールクライアントが前記電子メールメッセージを受信した後に、前記選択されたタグのセットに対する変更または新規ユーザタグを前記第２の電子メールクライアントから受信するステップと、
    前記電子メール情報と、前記第２の電子メールクライアントからの前記選択されたタグのセットに対する前記変更または前記新規タグとを用いて、前記モデルを再訓練するステップとをさらに含む、請求項１に記載の非一時的なコンピュータ読取可能媒体。
18. 前記モデルは、
    前記電子メール情報を用いてポピュレートされた単語埋め込み行列と、
    異なるウィンドウサイズを有する複数の畳み込みフィルタと、
    前記複数の畳み込みフィルタからの結果を使用する最大値プーリング演算とを含む、請求項１に記載の非一時的なコンピュータ読取可能媒体。
19. 電子メールシステムにおいてエンドツーエンド電子メールタグを自動的に生成する方法であって、前記方法は、
    電子メール情報を第１の電子メールクライアントから受信するステップを含み、前記電子メール情報は、前記第１の電子メールクライアントから第２の電子メールクライアントに送信される電子メールメッセージに関連付けられ、前記方法はさらに、
    前記電子メール情報をモデルに提供するステップを含み、前記モデルは、使用可能なタグのセットについてのスコアを生成し、前記方法はさらに、
    予測タグのセットを、前記スコアに少なくとも一部に基づいて、前記使用可能なタグのセットのサブセットとして識別するステップと、
    前記予測タグのセットを前記第１の電子メールクライアントに送信するステップとを含み、前記予測タグのセットから選択されたタグのセットが、前記電子メールメッセージが前記第２の電子メールクライアントに送信されるときに前記電子メールメッセージとともに送信される、方法。
20. システムであって、
    １つ以上のプロセッサと、
    前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに動作を実行させる命令を含む１つ以上のメモリデバイスとを備え、前記動作は、
    電子メール情報を第１の電子メールクライアントから受信するステップを含み、前記電子メール情報は、前記第１の電子メールクライアントから第２の電子メールクライアントに送信される電子メールメッセージに関連付けられ、前記動作はさらに、
    前記電子メール情報をモデルに提供するステップを含み、前記モデルは、使用可能なタグのセットについてのスコアを生成し、前記動作はさらに、
    予測タグのセットを、前記スコアに少なくとも一部に基づいて、前記使用可能なタグのセットのサブセットとして識別するステップと、
    前記予測タグのセットを前記第１の電子メールクライアントに送信するステップとを含み、前記予測タグのセットから選択されたタグのセットが、前記電子メールメッセージが前記第２の電子メールクライアントに送信されるときに前記電子メールメッセージとともに送信される、システム。

Images