(57)【特許請求の範囲】
【請求項１】
ソースコードをモデル化する方法であって、
ソース位置を有さないコードセグメントを含むソースコードを受け取るステップ（９０１）と、
受け取ったソースコードをインデックス化するステップ（９０３）と、
前記インデックス化ソースコードから、コード要素を表わす複数のノードと要素間の関係についての複数のエッジとを含むデータモデルを作成するステップ（９０５）と、
各ノードと関連付けられるソース位置を判定するステップ（９０７）と、
前記コードセグメントの１つを非表示もしくは黙示コードセグメントとして認識することに応答して、前記コードセグメントについてのフィグメントノードを作成するステップ（９０９）とを備え、前記データモデルは、前記フィグメントノードと前記フィグメントに対する参照を含む前記コード要素を表わすノードとの間のエッジを用いて前記フィグメントの挙動を表わし、前記フィグメントノードの内容は有効なコードシンタックスを表わさず、方法はさらに、
前記作成されたフィグメントを前記コードセグメントのノードと関連付けられた前記ソース位置として割り当てるステップ（９０９）を備える、方法。
【請求項２】
フィグメントノードは、前記データモデルにおいて前記ノードを他のノードから区別するために、特殊な注釈付けがなされる、請求項１に記載の方法。
【請求項３】
前記データモデルをユーザに対して提供するステップをさらに備える、請求項１または２に記載の方法。
【請求項４】
前記データモデルは、ＡＰＩ、ユーザインターフェイス、および／またはコマンドラインコードを介してユーザに対して提供される、請求項３に記載の方法。
【請求項５】
前記データモデルは複数のフィグメントノードを含み、少なくとも１つのフィグメントノードの内容は有効なコードシンタックスである、請求項１から４のいずれか１項に記載の方法。
【請求項６】
ソースコードをモデル化するシステムであって、
１つ以上の処理装置と、
命令を記憶する１つ以上の記憶装置とを備え、前記命令が前記１つ以上の処理装置によって実行されると、前記１つ以上の処理装置は、
ソース位置を有さないコードセグメントを含むソースコードを受け取り（９０１）、
前記受け取ったソースコードをインデックス化し（９０３）、
前記インデックス化ソースコードから、コード要素を表わす複数のノードと要素間の関係についての複数のエッジとを含むデータモデルを作成し（９０５）、
各ノードと関連付けられる前記ソース位置を判定し（９０７）、
前記コードセグメントの１つを非表示もしくは黙示コードセグメントとして認識することに応答して、前記コードセグメントについてのフィグメントノードを作成し（９０９）、前記データモデルは、前記フィグメントノードと前記フィグメントに対する参照を含む前記コード要素を表わすノードとの間のエッジを用いて前記フィグメントの挙動を表わし、前記フィグメントノードの内容は有効なコードシンタックスを表わさず、前記１つ以上の処理装置はさらに、
前記作成されたフィグメントを、前記コードセグメントのノードと関連付けられた前記ソース位置として割り当てる（９０９）、システム。
【請求項７】
フィグメントノードは、前記データモデルにおいて前記ノードを他のノードから区別するために、特殊な注釈付けがなされる、請求項６に記載のシステム。
【請求項８】
前記データモデルをユーザに対して提供することをさらに備える、請求項６または７に記載のシステム。
【請求項９】
前記データモデルは、ＡＰＩ、ユーザインターフェイス、および／またはコマンドラインコードを介してユーザに対して提供される、請求項８に記載のシステム。
【請求項１０】
前記データモデルは複数のフィグメントノードを含み、少なくとも１つのフィグメントノードの内容は有効なコードシンタックスである、請求項６から９のいずれか１項に記載のシステム。
【請求項１１】
請求項１から５のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【背景技術】
【０００１】
背景
ソフトウェア開発者は、いくつかの異なるプログラミング言語でソースコードを書く。各プログラミング言語は、異なるシンタックスおよびセマンティクスを有する。コードブラウザ、統合開発環境（ＩＤＥ）、および履歴分析ツールなどを含むコード化ツールは、これらのツールがソフトウェア開発者にとって有用なものとなるように、ソースコード言語を理解できる必要がある。多くのツールは、１つまたは２つの言語を良好に表わすが、他の言語を支持することが難しい。全てのプログラミング言語を支持する適切なツールを得るためには、全てのツールによって使用され得る単一のコードモデルを設けるべきである。全ての言語のソースコードのセマンティクスおよびシンタックスを表わすには、各言語の微妙な差異を理解する複合データモデルおよびサービスが必要となる。また、データモデルおよびサービスは、任意のプログラミング言語から、または言語間で、要素をインデックス化し、要素間の関係を表示することができる必要がある。
【発明の概要】
【課題を解決するための手段】
【０００２】
概要
この明細書は、概してデータのモデル化に関する技術、具体的にはソース位置を欠くコードセグメントをモデル化する方法およびシステムに関する技術を記載するものである。
【０００３】
概して、この明細書に記載の主題の一局面は、ソースコードをモデル化するシステムおよび方法において具現化され得る。例示的なシステムは、１つ以上の処理装置と、命令を記憶する１つ以上の記憶装置とを含み、命令が１つ以上の処理装置によって実行されると、１つ以上の処理装置は、ソース位置を有さないコードセグメントを含むソースコードを受け取り、受け取ったソースコードをインデックス化し、インデックス化されたソースコードから、コード要素を表わす複数のノードと要素間の関係についての複数のエッジとを含むデータモデルを作成し、各ノードと関連付けられるソース位置を判定し、コードセグメントの１つを非表示もしくは黙示コードセグメントとして認識することに応答して、コードセグメントについてのフィグメント表現（figment representation）を作成し、作成されたフィグメントを、コードセグメントノードと関連付けられたソース位置として割り当てる。例示的な方法は、ソース位置を有さないコードセグメントを含むソースコードを受け取るステップと、受け取ったソースコードをインデックス化するステップと、インデックス化されたソースコードから、コード要素を表わす複数のノードと要素間の関係についての複数のエッジとを含むデータモデルを作成するステップと、各ノードと関連付けられるソース位置を判定するステップと、コードセグメントの１つを非表示もしくは黙示コードセグメントとして認識することに応答して、コードセグメントについてのフィグメント表現を作成するステップと、作成されたフィグメントをコードセグメントのノードと関連付けられたソース位置として割り当てるステップとを含む。ソース位置を有さないコードセグメントを表わすデータモデルを使用する第２の例示的な方法は、ソース位置を有さないコードセグメントを含むコードについてのデータモデルを要求するステップと、ソース位置を有さないコードセグメントのフィグメント表現を含む、要求されたデータモデルを受け取るステップと、任意でコードセグメントのフィグメント表現をエンドユーザに表示するステップとを含む。
【０００４】
これらおよび他の実施形態は、以下の特徴のうち１つ以上を任意で含み得る。フィグメントノードは、データモデルにおいてノードを他のノードから区別するために、特殊な注釈付けがなされ得る。データモデルは、ユーザに対して提供され得る。データモデルは、アプリケーションプログラムインターフェイス（ＡＰＩ）を介して提供され得る。データモデルは、ユーザインターフェイスを介してユーザに対して提供され得る。データモデルは、コマンドラインコードを介してユーザに対して提供され得る。フィグメント表現の内容は有効なコードシンタックスであり得る。フィグメント表現の内容はコード挙動をモデル化するが、有効なコードシンタックスを表わさない。非表示もしくは黙示コードセグメントを使用するソースコードについてのノードと作成されたフィグメントを表わすノードとの間にはエッジがあり得る。データモデルは、フィグメント表現についてのメタデータを含み得る。メタデータは、エンドユーザにフィグメント表現を示すために、またはエンドユーザからフィグメント表現を隠すために使用され得る。メタデータは、コードセグメントがフィグメントであるという情報を表示するために使用され得る。メタデータは、コードセグメントがフィグメントを含むという情報を表示するために使用され得る。データモデルは、アプリケーションプログラムインターフェイスを使用して要求され得る。
【０００５】
本発明の１つ以上の実施形態の詳細は、例示のみによって与えられる添付の図面、および以下の記載において述べられる。本発明の他の特徴、局面、および利点は、明細書、図面、および請求項から明らかとなる。様々な図面における同様の参照番号および名称は、同様の要素を示す。
【図面の簡単な説明】
【０００６】
【図１ａ】例示的なコードセグメントを示すブロック図である。
【図１ｂ】例示的なコードセグメントを示すブロック図である。
【図２】図１ａおよび図１ｂに規定されるコードセグメントについてのデータモデルを示すブロック図である。
【図３】２つのコードセグメントをインデックス化およびグラフ化する例示的な処理を示すブロック図である。
【図４】図３に規定されたコードセグメントについてのデータモデルを示すブロック図である。
【図５】非表示および／もしくは黙示コードについてのコードフィグメントを含む、図３に規定されたコードセグメントについての例示的なモデルを示すブロック図である。
【図６】マクロをインデックス化およびグラフ化する例示的な処理を示すブロック図である。
【図７】図６に規定されるマクロについてのデータモデルを示すブロック図である。
【図８】非表示および／もしくは黙示コードについてのコードフィグメントを含む、図６に規定されるマクロについての例示的なモデルを示すブロック図である。
【図９】非表示および／もしくは黙示コードを表わすコードフィグメントを作成する例示的な方法を示すフロー図である。
【図１０】例示的な演算装置を示すブロック図である。
【図１１】ソース位置を有さないコードセグメントを表わすデータモデルを使用する例示的な方法を示すフロー図である。
【発明を実施するための形態】
【０００７】
詳細な説明
例示的なデータモデルおよびサービスは、言語に依存しない標準的なソースコードおよびコンパイラメタデータの表現を提供する。モデルは、ソースコードをデータグラフとして表わす。データグラフは、データを記憶し、ノードと呼ばれる点およびエッジと呼ばれる線の有限の集合を使用してデータ間の関係を示すデータ構造である。グラフ内の関係は、図２に示されるように、エッジを使用してノードを互いに接続することによって表される。
【０００８】
ソースコードからデータグラフモデルを作成するために、ソースコードは、グラフを形成するノードおよびエッジの集合に変えなければならない。高いレベルの正確性を得る便利な方法は、ソースコードのための既存のコンパイラを再利用することである。コンパイラには、コンパイラからデータを抽出してデータグラフモデルのためのノードおよびエッジを構築するインデクサが設けられ得る。図１ａおよび図１ｂは、「hello world」という単語を印刷するために合わせて使用され得るソースコードファイルの２つの例示的なスニペットを示す。図１ａにおけるファイル「stdio.h」（１０５）は、アーギュメントとしてポインターをストリング「format」に取り込む２行目の関数「printf」の定義を含み、「format」によってポイントされたストリングを標準出力に書き込む。図１ｂにおいて、ファイル「hello.c」（１１）は、２行目の「stdio.h」ファイルを含み、４行目の「stdio.h」からの「printf」の定義を「main」（３行目）と呼ばれる関数において使用し、ストリング「hello world」を標準出力に書き込む。データモデルは、図２に示されるグラフと類似のグラフとしてソースコードスニペットを表わし得る。図２は、グラフにおけるノードとして２つのファイル「hello.c」（２３２）および「stdio.h」（２３４）を示し、２つのノード間の双方向エッジによって表わされる「含む／含まれる（includes/included by）」関係を伴う。ファイル「hello.c」（２３２）を表わすノードは、２つのノード間の「宣言する／宣言される（declares/declared by）」関係を示す双方向エッジによって、関数「main」（２２４）を表わすノードに接続される。ファイル「stdio.h」（２３４）を表わすノードは、「宣言する／宣言される」関係エッジによって「printf」（２２２）のノードに接続される。ソースコードにおいて「printf」は「main」によって呼び出されることから、「main」（２２４）を表わすノードは、「呼び出す／呼び出される（calls/called by）」関係鏡映エッジによって、「printf」（２２２）を表わすノードに接続される。グラフにおいて、「main」（２２４）についてのノードおよび「printf」（２２２）についてのノードの両方は、それらが戻る組み込み型に対して関係を有する。「main」（２２４）は、ボイド戻り（２０４）を有し、「printf」は「int」（２０６）を戻す。
【０００９】
上述のように、ノードは、ソースコードのセグメントを表わすために作成される。ノードは、組み込み型、パラメータ化された型、構成型、ポインタ型、シンボルの宣言、ユーザ定義型、参照、方法、方法呼び出し、フィールド、割り当て、コメント、インラインドキュメンテーション、およびファイルなどのいくつかの異なるタイプの要素を表わし得る。各ノードは、ノードについてのグローバル一意識別子、要素の種類、表示名、ソースコードにおける要素の位置、要素の変更子、次元、およびソースコードにおける要素まわりにあるコードのスニペットを含む、特定の情報を含み得る。ノードは、未解決、コメント、損失、ネームスペース、パッケージ、モジュール、クラス、構造、インターフェイス、列挙、列挙定数、関数、方法、コンストラクタ、フィールド、ローカル、パラメータ、変数、プロパティ、ブーリアン、文字、ストリング、正規表現、整数、フロート、定数、有理数、複素数、大数、オブジェクト、インスタンス、ファイル、ディレクトリ、シンボリックリンク、診断、ポインタ、参照、エイリアス、ヌル、ボイド、ユニット、変動型、パラメータ型、変数型、特殊型、シンボル、名前、値、使用、配列、セット、マップ、リスト、タプル、および結合などのいくつかの種類のうちの１つであり得るが、これらに限定されない。
【００１０】
エッジは、データモデルにおける要素間の関係を表わし得る。これらのエッジは、双方向であり得る。これは、第１のノードから第２のノードへの各エッジが、第２のノードから第１のノードへの鏡映エッジを有することを意味する。拡張する／拡張される、実施する／実施される、オーバーライドする／オーバーライドされる、承継する／承継される、宣言する／宣言される、取り込む／取り込まれる、ベース型／構成型、型を有する／の型である、戻り型／戻される、呼び出す／呼び出される、インスタンス生成する／インスタンス生成される、参照する／参照される、特性を有する／の特性、宣言を有する／の宣言、定義を有する／の定義、入力を有する／消費される、出力を有する／作成される、生成する／生成される、制限される／アクセスを許可される、使用コンテキスト／包含された使用、注釈付される／の注釈、親／子、および投げる／投げられるなどを含む、いくつかの異なるエッジペアがある。 
【００１１】
一部の例において、データグラフは、ソース位置を有さない要素についてのセマンティック情報を記憶する。なぜなら、一部のコード片は、非表示もしくは黙示であり、物理的位置を有さないからである。位置を有さないコードの例としては、デフォルトコンストラクタ、マクロ展開、テンプレートインスタンス化、静的にインデックス化可能なランタイムオブジェクト、陰関数アーギュメント、ラムダ拡張、ドキュメントコメント、定数畳込、および生成コードが含まれる。
【００１２】
非表示もしくは黙示コードセグメントは、参照され得る、使用され得る、またはソースコードの他の部分に結合され得る。これらのコードセグメントが位置を欠いていることは問題である。ユーザが上記のコードセグメントの１つを呼び出すソースコードにおける場所からセグメントへデータグラフを移動したい場合、通常の「ジャンプ」機能は働かない。なぜなら、非表示もしくは黙示コードセグメントについてはソースコードにおける実際の物理的な場所がなく、要素についてのデータグラフにおける位置がないためである。非表示もしくは黙示コードセグメントは、ソース言語における有効なシンタックスである表現を有し得ない。
【００１３】
非表示もしくは黙示コードがある特定の場合において、慣習的なデータモデルでは、利用可能なソース位置がないことをユーザに伝えるメッセージが表示される場合が多い。他の慣習的なモデルでは、ソースコードの関連する断片へポイントされた位置が代替的に合成される。この合成手法は、ソフトウェア開発者がコードを理解するには十分に良いものであるが、この手法は静的解析ツールには使用することができない。たとえば、デフォルトコンストラクタの場合において、ユーザがコンストラクタのインスタンス化をクリックした場合、データグラフモデルは、代わりにクラスの宣言へユーザを導き得る。多くのユーザは、デフォルトコンストラクタをクリックした場合、なぜ黙示的デフォルトコンストラクタを有らしめた宣言にデータグラフモデルがユーザを導くのかを理解し得る。しかしながら、静的解析ツールは、この特殊な知識を有し得ない。このため、非表示もしくは黙示コードが有る時に静的解析ツールがソースコードをリファクタする場合、ツールがコードを無効なコードに書き換える可能性が最も高い。他の慣習的なモデルは、カスタムユーザインターフェイスを構築することを含むが、このモデルでは、各種の非表示／黙示データがそれぞれメタデータおよびカスタムＵＩを記憶する方法を有する必要がある。
【００１４】
例示的なデータグラフモデルは、非表示もしくは黙示コードセグメントに対する代替的な位置をスキップまたは合成しない。代わりに、例示的なモデルは、コードフィグメントを作成することにより、非表示／黙示コードセグメントの表現を露出させる。例示的な方法は、ソースコード内の非表示／黙示コードセグメントを認識する。そして、ソース「フィグメント」が、非表示／黙示コードについて生成される。これらのフィグメントは、実際にコンパイルされたコード、またはソース言語における有効なシンタックスである必要はない。しかしながら、フィグメントは、意味のある方法で非表示もしくは黙示コードを表わすべきである。フィグメントは、エンドユーザがフィグメントを理解することができるように、出来る限り元のソース言語に近いシンタックスを有するのが好ましい。 
【００１５】
ソース位置を有さないコードセグメントをモデル化する例示的な方法は、図９に示されるように、ソースコードを受け取ること（９０１）から始まる。そして、ソースコードはインデックス化されるべきである（９０３）。要素を表わすノードおよびノード間の関係を表わすエッジを使用してインデックス化ソースコードからデータモデルが作成され得る（９０５）。各ノードについて、ソース位置が判定され得る（９０７）。ノードによって表されるコードセグメントが非表示もしくは黙示である場合、コードセグメントのコードフィグメント表現が作成され得る（９０９）。そして、非表示もしくは黙示コードの任意の局面を表わす任意のノードにおける位置をモデル化するためにフィグメント位置が使用され得る（９１１）。また、フィグメントノードは、フィグメントノードを現実のノードから区別するために特殊な注釈付けがなされ得る。そして、データは、ユーザインターフェイス、アプリケーションプログラムインターフェイス、または一部の他の機構を介してエンドユーザに対して提供され得る。 
【００１６】
図３は、例示的なサービスが２つのjava（登録商標）ファイルをインデックス化して例示的なデータグラフモデルを作成する処理を示す。Demo.java()（３０５）は、テスタークラスのデフォルトコンストラクタへの呼び出しを３行目に有する。テスタークラスは、Tester.java （３０３）において定義されるが、Tester.java（３０３）においてデフォルトコンストラクタの明示的な定義はない。このため、このコンストラクタのためのソースコードはなく、コンパイラは、コードのためのプレースホルダとしてデフォルト実施を行ない得る。
【００１７】
図４は、Demo.java()（３０５）とTester.java()（３０３）との間の相互作用についてのデータグラフモデルの部分的な実施である。上述のように、ノードは、ソースコードにおける要素を記載する。この例において、各ノードは、一意識別子（チケット名）とソース位置とを有する。ノードは、ラベル付けされたエッジを介して関係する。Demo.java３行目（４０９）からテスターコンストラクタ（４０４、３行目）へ呼び出しが行われた場合、コンストラクタ（４１２）の使用とコンストラクタノード（４０８）との間にエッジを発することは難しい。なぜなら、コンストラクタノード（４０８）を記載するノードに付されたソース位置がないからである。
【００１８】
図５に示されるような例示的なデータグラフモデルにおいて、フィグメント（５１９）が加えられ、黙示テスターコンストラクタ（５２１）が表わされる。自己コンパイル可能となり得ないjava（登録商標）コードのスニペットであるこのフィグメント（５１９）は、ユーザが黙示コードを理解するのに十分なコンストラクタについての情報を含む。フィグメント（５１９）を記載するノードには、ノードに示されるように「フィグメント：真」などの特殊な注釈がラベル付けされており、ノードがフィグメントであることを示す。そして、テスターコンストラクタ（５０９）を記載するノードは、新たに加えられたフィグメントに対するノードの位置点を有するように変更される。
【００１９】
図６は、マクロ（６０１）を定義および使用するＣ＋＋ファイルをモデル化する例示的な処理を示す。マクロは、規定の手順に従ってどのように特定の入力シーケンスが置換入力シーケンスへマップ化されるべきかを特定する規則またはパターンである。
【００２０】
図７は、図６のソースコードをインデックス化する際に作成され得るデータグラフの部分的な実施である。このグラフにおいて、ソースコードの１０行目の「IntegerContainer」の使用（７０３）をモデル化することは難しい。なぜなら、構造体（７０４、０７行目）は、７行目のマクロに対する呼び出し（７０３）によって導入されたが、構造体の定義についての実際のソースコードが存在しないためである。加えて、１１行目の「IntegerContainer」型のフィールド値（７０３）をモデル化することは難しい。なぜなら、「IntegerContainer」についての実際のソースコードが無いためである。「IntegerContainer」は、位置を欠いた状態でグラフに示される（７１１）。また、「IntegerContainer」の値は、位置の無い状態でグラフに組み込まれる（７１３）。
【００２１】
図８は、IntegerContainer構造体（８０７）の定義を含む新しいファイル「//figments/container.cc/ IntegerContainer」（８０４）を作成する例示的なグラフを示す。この新しいファイル（８０４）は、IntegerContainer構造体（８０５）を表わすノードのためのノードおよびIntegerContainer値フィールド（８１６）のためのノードの両方についての位置情報として使用され得る。さらに、使用ノード（８１７）は、元のソースファイルにおける値フィールドのタイプとtypedefの定義との間に加えられ得る。加えて、フィグメントはユーザアクションによって作成されたセマンティクスを表わすことから、マクロの使用（８０３）とフィグメントファイル（８０４）との間にエッジが作成され得て、これら２つのノード間の「フィグメント／のフィグメント（FIGMENT/FIGMENT_OF）」関係が定義される。
【００２２】
位置情報は、コードセグメントの位置について有用な任意の種類の情報であり得る。図面における位置情報はファイルおよび行番号で示されるが、この情報は単に例示を目的として示される。
【００２３】
例示的な実施形態において、コード化ツールおよびユーザインターフェイスは、フィグメントを用いて向上したデータモデルを使用し、エンドユーザに対してコードを表わす。ソース位置を有さないコードセグメントを表わすデータモデルを使用する例示的な方法は、図１１に示されるようにデータモデルを要求することから始まる（１１０１）。データモデルは、例示的なデータグラフモデルサービスを呼び出すアプリケーションプログラムインターフェイス（ＡＰＩ）を使用して要求され得る。受け取ったデータモデルは、ソース位置を有さない少なくとも１つのコードセグメントを含み得る。受け取ったデータモデルは、ソース位置を有さないコードセグメントのフィグメント表現を含み得る（１１０３）。このデータモデルは、エンドユーザに対して表示され得る（１１０５）。ソース位置を有さないコードセグメントのフィグメント表現に加えて、データモデルはフィグメント表現についてのメタデータを含み得る。このメタデータは、フィグメントであるモデルノードとフィグメントでないノードとの間の区別を含み得る。また、データモデルは、ソース位置の無いコードセグメントを含むノードとソース位置の無いコードセグメントを表わすノードとの間のエッジ関係を提供し得る。エッジ関係は、「のフィグメント／フィグメントを有する（FIGMENT_OF/HAS_FIGMENT）」関係としてモデル化され得る。コードツールおよびユーザインターフェイスは、メタデータ、エッジ関係、および他の提供された情報を使用し、どの情報をユーザに対して表示するかを判定し得る。
【００２４】
図１０は、コードセグメントがソース位置を有さない場合にデータモデルにおいてコードセグメントをモデル化するために配列された例示的なコンピュータ（１０００）を示す高レベルブロック図である。非常に基本的な構成において（１００１）、演算装置（１０００）は、通常、１つ以上のプロセッサ（１０１０）とシステムメモリ（１０２０）とを含む。メモリバス（１０３０）は、プロセッサ（１０１０）とシステムメモリ（１０２０）との間の通信のために使用され得る。
【００２５】
所望の構成に応じて、プロセッサ（１０１０）は、マイクロプロセッサ（μＰ）、マイクロコントローラ（μΘ）、デジタル信号プロセッサ（ＤＳＰ）、またはこれらの任意の組合せを含むタイプであり得るが、これらに限定されない。プロセッサ（１０１０）は、レベル１キャッシュ（１０１１）およびレベル２キャッシュ（１０１２）などの１つ以上のレベルのキャッシュと、プロセッサコア（１０１３）と、レジスタ（１０１４）とを含み得る。プロセッサコア（１０１３）は、算術論理演算ユニット（ＡＬＵ）、浮動小数点ユニット（ＦＰＵ）、デジタル信号処理コア（ＤＳＰコア）またはこれらの任意の組合せを含み得る。また、メモリ制御部（１０１６）は、プロセッサ（１０１０）と共に使用され得る、または、一部の実施において、メモリ制御部（１０１５）は、プロセッサ（１０１０）の内蔵部品であり得る。
【００２６】
所望の構成に応じて、システムメモリ（１０２０）は、揮発性メモリ（ＲＡＭなど）、不揮発性メモリ（ＲＯＭ、フラッシュメモリなど）、またはこれらの任意の組み合わせを含む任意のタイプであり得るが、これらに限定されない。システムメモリ（１０２０）は、通常、オペレーティングシステム（１０２１）と、１つ以上のアプリケーション（１０２２）と、プログラムデータ（１０２４）とを含む。アプリケーション（１０２２）は、ユーザが取る可能性の高いアクションに関連付けられた注釈のみがユーザに対して示されるように電子メール注釈を二重フィルタリングするシステムを含み得る。プログラムデータ（１０２４）は命令を記憶し、この命令が１つ以上の処理装置によって実行されると、電子メールテキストからのアクション可能な項目をパースするとともに、これらのアクション可能な項目を、ユーザがアクションを行う可能性の高いもののみを表示するようにフィルタリングするシステムおよび方法を実施する。（１０２３）。一部の実施形態において、アプリケーション（１０２２）は、オペレーティングシステム（１０２１）上でプログラムデータ（１０２４）と共に動作するように配置され得る。
【００２７】
演算装置（１０００）は、追加の特徴または機能ならびに追加のインターフェイスを有し、基本的な構成（１００１）と任意の必要な装置およびインターフェイスとの間の通信を容易にし得る。
【００２８】
システムメモリ（１０２０）は、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光学記憶部、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶装置、または、所望の情報を記憶するために使用することができ、演算装置１０００によってアクセスすることができる任意の他の媒体を含むが、これらに限定されない。任意のこのようなコンピュータ記憶媒体は、装置（１０００）の一部であり得る。
【００２９】
演算装置（１０００）は、携帯電話、スマートフォン、パーソナルデータアシスタント（ＰＤＡ）、パーソナルメディアプレイヤ装置、タブレットコンピュータ（タブレット）、無線ウェブ視聴装置、パーソナルヘッドセット装置、特定用途向け装置、または上記の機能のいずれかを含むハイブリッド装置など、小さいフォームファクタの持ち運び可能（またはモバイル）電子装置の一部として実施され得る。演算装置（１０００）は、ラップトップコンピュータおよび非ラップトップコンピューター構成の両方を含むパーソナルコンピュータとしても実施され得る。 
【００３０】
上記の詳細な説明では、ブロック図、フローチャート、および／または例を用いて装置および／または処理の様々な実施形態について述べた。このようなブロック図、フローチャート、および／または例が１つ以上の機能および／または動作を含む限りにおいては、当業者は、このようなブロック図、フローチャート、または例における各機能および／または動作が、広い範囲のハードウェア、ソフトウェア、ファームウェア、または実質的にこれらの任意の組み合わせによって、個別および／または集合的に実施され得ることを理解する。一実施形態において、ここに記載される主題のいくつかの部分は、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＰＳ）、または他の統合された形態を用いて実施され得る。しかしながら、当業者は、ここに開示される実施形態の一部の局面が、全体的もしくは部分的に、１つ以上のコンピュータ上で実行される１つ以上のコンピュータプログラムとして（たとえば、１つ以上のコンピュータシステム上で実行される１つ以上のプログラムとして）、１つ以上のプロセッサ上で実行される１つ以上のプログラムとして（たとえば、１つ以上のマイクロプロセッサ上で実行される１つ以上のプログラムとして）、ファームウェアとして、または実質的にこれらの任意の組み合わせとして、集積回路において等しく実施され得ることを理解するとともに、回路を設計すること、ならびに／またはソフトウェアおよび／もしくはファームウェアのためのコードを書くことは、この開示に鑑みて当業者の技術の範囲内となり得ることを理解する。加えて、当業者は、ここに記載の主題の機構が様々な形態のプログラム製品として配布することが可能であること、およびここに記載の主題の例示的な実施形態が配布を実際に行う際に非一時的信号担持媒体の特定のタイプに関係なく適用され得ることを理解する。非一時的信号担持媒体の例としては、フロッピー（登録商標）ディスク、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、デジタルテープ、コンピュータメモリなどの記録可能型媒体、ならびにデジタルおよび／もしくはアナログ通信媒体などの送信型媒体（たとえば、光ファイバケーブル、導波管、有線通信リンク、無線通信リンクなど）が含まれるが、これらに限定されない。
【００３１】
ここでの実質的に複数形および／または単数形の用語の使用に関し、当業者は、文脈および／または用途に適するように、複数形から単数形、および／または単数形から複数形へと解釈を変更し得る。様々な単数形／複数形の置き換えが明瞭化のためにここに明示的に述べられ得る。 
【００３２】
したがって、主題の特定の実施形態が記載された。他の実施形態は、以下の請求項の範囲内にある。一部の場合において、請求項に規定される動作は、異なる順序で行われ得て、それでもなお所望の結果が実現される。加えて、添付の図面に示される処理は、所望の結果を実現するために必ずしも示される特定の順序、または連続的な順序を必要とするものではない。特定の実施において、多重タスク処理および並列処理が有利な場合もある。
【図１ａ】
0005974191.tif 000002
【図１ｂ】
0005974191.tif 000003
【図２】
0005974191.tif 000004
【図３】
0005974191.tif 000005
【図４】
0005974191.tif 000006
【図５】
0005974191.tif 000007
【図６】
0005974191.tif 000008
【図７】
0005974191.tif 000009
【図８】
0005974191.tif 000010
【図９】
0005974191.tif 000011
【図１０】
0005974191.tif 000012
【図１１】
0005974191.tif 000013