シリアルバイナリ形式でドキュメントを格納するシステムおよび方法
【課題】ドキュメントデータが他のアプリケーションからアクセス可能なようにシリアル化されたバイナリ形式でドキュメントデータを格納するためのデータ構造を備えるコンピュータ可読媒体を提供すること。
【解決手段】ルートノードデータを含むドキュメント構造が生成される。ドキュメントは、シリアルバイナリデータ形式で格納される。シリアルバイナリ形式は、第１のデータフィールド内のドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式は、さらに、第２のデータフィールドにドキュメント構造ディスクリプタデータを格納することも含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【解決手段】ルートノードデータを含むドキュメント構造が生成される。ドキュメントは、シリアルバイナリデータ形式で格納される。シリアルバイナリ形式は、第１のデータフィールド内のドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式は、さらに、第２のデータフィールドにドキュメント構造ディスクリプタデータを格納することも含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【発明の詳細な説明】
【技術分野】
【０００１】
タブレットＰＣを使用することで、ユーザはふつう、画面に直接描画または書くことができる。この描画または手書きは、一般に「インキング」と呼ばれる。インキングは、一種のユーザ入力であり、タッチスクリーン、およびユーザが従来のペンと紙で書くのと同様にコンピューティングペン（ｃｏｍｐｕｔｉｎｇ ｐｅｎ）を使用し画面上に書くことを含むことができる。インキングは、さまざまなアプリケーションで使用される。例えば、インキングは、ドローイングアプリケーション、ペインティングアプリケーション、ワードプロセッシングアプリケーション、クレジットカード署名アプリケーションなどで使用することができる。
【背景技術】
【０００２】
インキングは、ただ単なるペンストロークの視覚的表現を含むだけではなく、データ型をも含むことができる。データ構造は知られているが、情報を格納するために使用されるデータ構造のサイズはひどく大きくなり、扱いにくいものとなる可能性がある。また、プログラム間にドキュメント構造の互換性があれば、コンピュータの効率および一般的な使い勝手が向上する。しかし、互換性は、ユーザが一方のアプリケーションから他方のインクアプリケーションへインクデータを転送することを望んでいる場合に問題になりうる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
一般に、本発明のいくつかの態様は、ドキュメント構造を生成し、シリアルバイナリ形式でそのドキュメント構造を格納するシステムおよび方法に関係する。本発明はまた、インクドキュメント構造を生成し、他のアプリケーションからアクセス可能なようにインクドキュメント構造を格納するシステムおよび方法にも関係する。本発明は、さらに、インキング全体の再解析を必要とすることなくインキングの一部を修正または変更するシステムおよび方法に関係する。
【課題を解決するための手段】
【０００４】
本発明のいくつかの態様は、ドキュメントデータが他のアプリケーションからアクセス可能なようにシリアル化されたバイナリ形式でドキュメントデータを格納するためのデータ構造を備えるコンピュータ可読媒体に関係する。ルートノードデータを含むドキュメント構造が生成される。ドキュメントは、シリアルバイナリデータ形式で格納される。シリアルバイナリ形式は、第１のデータフィールド内のドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式はまた、第２のデータフィールドにドキュメントディスクリプタデータを格納することを含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【０００５】
本発明の他の態様は、２分木構造をシリアル化形式で格納するコンピュータ実装方法に関係する。コンピュータ実装方法は、第１のデータフィールド内にドキュメント構造のサイズデータを格納することを含む。このコンピュータ実装方法はまた、第２のデータフィールドにドキュメント構造ディスクリプタデータを格納することも含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。このコンピュータ実装方法は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【０００６】
本発明のさらに他の態様は、コンピュータ実行可能命令が格納されているコンピュータ可読媒体に関係する。これらの命令は、インクドキュメント構造を生成することを含み、インクドキュメント構造は、少なくとも１つのルートノードを含む。これらの命令はまた、シリアルバイナリ形式でインクドキュメント構造を格納することも含む。シリアルバイナリ形式は、第１のデータフィールド内のインクドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式はまた、第２のデータフィールドにインクドキュメントディスクリプタデータを格納することも含み、インクドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含むことができ、ルートノードデータは、フラグの少なくとも１つにより示される。
【発明を実施するための最良の形態】
【０００７】
本発明のいくつかの実施形態について、これ以降、本発明の一部をなし、実例として、本発明を実施する特定の例示的な実施形態を示す、添付の図面を参照しつつさらに詳しく説明する。しかし、本発明は、多くの異なる形態で具現化することができ、したがって、本明細書で述べたいくつかの実施形態に限定されるものと解説すべきではなく、むしろ、これらの実施形態は、本開示が網羅的で完全であり、本発明の範囲を完全に当業者に伝えるように実現される。とりわけ、本発明は、方法またはデバイスとして実現することができる。したがって、本発明は、全体としてハードウェア実施形態、全体としてソフトウェア実施形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形を取りうる。したがって、以下の詳細な説明は、限定的な意味で解釈すべきではない。
【０００８】
シリアルバイナリ形式でデータを格納する方法およびシステムの例示的な実施形態
一般に、本発明は、インクドキュメント構造を生成し、他のアプリケーションからアクセス可能なようにインクドキュメント構造を格納するシステムおよび方法に関係する。より具体的には、本発明は、格納効率を高めるためデータをシリアルバイナリ形式で格納するシステムおよび方法に関係する。本発明はまた、インキング全体の再解析を必要とすることなくインクの一部を修正または変更するシステムおよび方法に関係する。本明細書で述べている説明ではインクドキュメントの格納およびロードを参照しているとしても、本明細書で参照されているシリアルバイナリ形式は、他の型のデータを格納するために使用することができる。例えば、本発明は、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、ドローイングアプリケーション、グラフィックスアプリケーション、ノーツアプリケーション、画像アプリケーションなどに関連するデータを含むことができる。簡潔に述べると、シリアルバイナリ形式は、２分木構造に関連付けられた任意の型のデータを格納するために使用することができる。
【０００９】
１．インクアプリケーションの例示的な実施形態
本発明の一態様の一般的な文脈として、インクアプリケーションは、ユーザがペンを使用してデータを入力するときに視覚的フィードバックをリアルタイムで返すことができる。しかし、インキングは、ペンストロークの視覚化よりもさらに多くのものを含み、データ型を含むことができる。ユーザは、ペン、インク、インク解析、およびインク認識のさまざまなレベルの機能をサポートするデジタイザ用のアプリケーションを構築することができる。このようなアプリケーションは、単純なテキスト入力の認識から複雑なインクドキュメントの作成および編集に至るまでさまざまである。
【００１０】
インクアプリケーションはまた、インク−テキスト間変換も含むことができる。状況によっては、直接的インク入力を受け付けないアプリケーションもある。このような状況では、インクアプリケーションは、手書き認識を実装し、インクをテキストに変換することにより、直接的インク入力を受け付けないアプリケーションにカット＆ペーストすることができる。アプリケーションはまた、インクオブジェクトおよび他のドキュメントオブジェクトに関するその文脈も認識することができる。他の実施形態では、ユーザは、インクを操作し、インクを使用して、テキスト、グラフィックス、ベクトル形状、マルチメディアオブジェクトなどを含むリッチドキュメントをオーサリングすることができる。このような実施形態では、インクを、インクオブジェクトをリフローし重ねることができるデータ型として取り扱う。
【００１１】
インク入力は、未処理（ｒａｗ）インクデータの形態でアプリケーションに関連付けることができる。一実施形態では、未処理インクデータをインクアナライザに送り、未処理インクデータを処理し、未処理インクデータと別にすることができるインクドキュメント構造を生成することができる。インクアナライザは、未処理インクデータを管理可能な複数のストローク成分に分割するため解析および認識プロセスを実装することができる。以下でさらに詳しく説明するように、一実施形態では、インクアナライザは、木のそれぞれのノードが未処理インクデータの一部分との関係を定義する２分木を有するインクドキュメント構造を生成することができる。インクドキュメント構造を使用すると、プラットフォームに関連付けられたインクアプリケーションは、未処理インクデータとインクドキュメント構造を関係付けて、オリジナルのインクおよび関連付けられたインクドキュメント構造をロードすることができる。また、インクドキュメント構造を使用することで、ユーザは、インクドキュメント全体を再解析することなくインクをロードし修正することもできる。また、本発明では、１つのプラットフォーム上の複数のアプリケーション間でインクを共有することができる。
【００１２】
図３は、インクドキュメントデータをシリアルバイナリ形式で格納するためのシステムの例示的な一態様の一般的な概要を表す。図に示されているように、システム３００は、デジタイザ３０２、アプリケーション３０４、およびインクアナライザ３０６を含む。デジタイザ３０２は、図１に関して説明されているコンピューティングデバイスを含むことができる。デジタイザ３０２は、図２に関して説明されているモバイルコンピューティングデバイスも含むことができる。一実施形態では、デジタイザは、ワシントン州レドモンドの本件特許出願人のＷＩＮＤＯＷＳ（登録商標）ＸＰ ＴＡＢＬＥＴ ＰＣ ＥＤＩＴＩＯＮ上で稼働するＴＡＢＬＥＴ ＰＣデジタイザを含む。しかし、デジタイザ３０２は、インクアプリケーションの動作をしやすくするデバイスを含むことができる。
【００１３】
デジタイザ３０２は、ユーザ入力ストローク（例えば、手書きおよび／または描画ストローク）を２値化し、一実施形態では、データを未処理データ記憶装置（ｓｔｏｒａｇｅ）３０８に格納する。未処理データ記憶装置３０８は、デジタイザ３０２からのデータを維持することができる種類の記憶装置である。未処理データ記憶装置３０８も、１つまたは複数のアプリケーションおよび／または１つまたは複数のプラットフォームに関連付けることができる。他の実施形態では、デジタイザ３０２は、未処理データ記憶装置３０８をバイパスし、２値化されたデータをアプリケーション３０４に送信する。
【００１４】
アプリケーション３０４は、プラットフォームに関連付けられた任意のアプリケーションを含むことができる。一実施形態では、アプリケーション３０４は、インクを使いやすくするアプリケーションである。アプリケーション３０４は、ワードプロセッシングアプリケーション、ペイントアプリケーション、製図アプリケーション、ドローイングアプリケーション、クレジットカード署名アプリケーションなどを含むことができる。一実施形態では、アプリケーション３０４は、本件特許出願人のＩｎｋＥｄｉｔ、ＩｎｋＰｉｃｔｕｒｅ、および／またはＯｎｅＮｏｔｅを含む。他の実施形態では、アプリケーション３０４は、保存オペレーションおよびロードオペレーションを実行することができる。保存オペレーションは、インクデータおよび非インクデータを保存することを含むことができる。アプリケーション３０４は、未処理インクデータを未処理データ記憶装置３０８に保存し、アプリケーション３０４は、インクドキュメント構造をプラットフォームに関連付けられたインクアナライザに保存することができる。ロードオペレーションでは、アプリケーション３０４は、以下でさらに詳しく説明するようにインクドキュメント構造と未処理インクデータをロードし、統合することができる。
【００１５】
インクアナライザ３０６は、アプリケーション３０４から未処理インクデータを受信するように構成することができる。インクドキュメント構造を生成するため、インクアナライザ３０６は未処理インクデータに対し構造解析を実行するように構成される。構造解析は、未処理データの解析および未処理データの認識を含むことができる。
【００１６】
一実施形態では、構造解析を行うことで、テキスト認識、手書き、および描画分類、およびレイアウト解析を容易にすることができる。インクアナライザ３０６は、連携動作してテキスト認識機能を高める解析コンポーネントおよびレコグナイザコンポーネントを含むことができる。例えば、パーサー（ｐａｒｓｅｒ）は、インクがレコグナイザに送られる前に前処理ステップとしてオペレーションを実行することができる。前処理では、パーサーは、マルチラインインク（ｍｕｌｔｉ−ｌｉｎｅｄ ｉｎｋ）を解析して「きれい（ｃｌｅａｎ）に」し、それを一度に１パーセルずつレコグナイザに送ることができる。パーセルは、インクドキュメントの一部を含むことができる。パーサーは、さらに、不正な入力ストローク順序情報を是正して、入力順序にかかわらずすべてのストロークが確実に認識されるように構成することができる。また、パーサーは、隣接行に関する情報を生成することができる。例えば、２つの隣接行が１つの行頭文字で始まるという事実は、現在行が行頭文字で始まることを示す強い指標となりうる。
【００１７】
他の実施形態では、インクアナライザ３０６の解析オペレーションはまた、インクを描画または手書きとして分類することを含むこともできる。手書きは、単語を認識しやすくするインクストロークを含むことができる。描画ストロークは、手書きストロークでないものを含むことができる。例えば、図４を参照すると、ストローク「Ｈ」は、手書きストロークを含み、「下線」は、描画ストロークを含むことができる。この方法では、一実施形態において、手書きストロークは、レコグナイザに送られる唯一のストロークとすることができる。
【００１８】
インクアナライザ３０６のさらに他の実施形態では、レイアウト解析は、お互いおよび非インクデータに関する手書きおよび描画ストロークの細目（ｂｒｅａｋ ｄｏｗｎ）を含む。インクアナライザ３０６がインキングのストロークを解析した後、これらのストロークの木表現（つまり、インクドキュメント構造）を生成することができる。簡潔にいうと、インクアナライザ３０６は、ドキュメントを２分木で格納し、シリアルバイナリ形式を介してその２分木を他のアプリケーションからアクセスできるようにすることが可能な任意の種類のアナライザを含むことができる。シリアルバイナリ形式がインクドキュメント構造を参照しつつ本明細書で説明されているとしても、シリアルバイナリ形式を使用して、ドキュメント木構造に関連付けられた任意の種類の情報を格納することができる。
【００１９】
インクアナライザ３０６が未処理データに基づいてインクドキュメント構造を生成した後、インクドキュメント構造はアプリケーション３０４から利用することができるようになる。インクドキュメント構造は、ライブインクドキュメント構造を含むことができる。格納オペレーションが引き起こされる（ｉｎｓｔｉｇａｔｅｄ）と、アプリケーション側は、インクアナライザ３０６がインクドキュメント構造を格納することを要求する。インクアナライザ３０６がプラットフォームコンポーネントであるという点において、インクドキュメント構造は他のインクアプリケーションから利用可能である。例えば、ユーザがワードプロセッシングドキュメントでインクを生成する場合、このインクを、再度解析する必要なく、ドローイングアプリケーションにカット＆ペーストすることができる。この実施例では、ドローイングアプリケーションは、インクドキュメント構造からオリジナルのインクを生成する方法を認識する。また、インクは、解析されシリアルバイナリ形式で保存されるため（後述）、インク全体の再解析を必要とすることなく、修正し、効率よく格納することができる。修正された部分は、インクドキュメント構造の単一のパーセル（ｐａｒｃｅｌ）に対応し、したがって、変更されたパーセルの再解析のみをすればよい。
【００２０】
一般に、ロードオペレーションの際に、アプリケーション３０４は、未処理インクデータ、非インクデータ（ｎｏｎ−ｉｎｋ ｄａｔａ）、およびインクドキュメント構造をロードすることができる。未処理インクデータは、未処理データ記憶装置３０８からロードすることができる。非インクデータも、未処理データ記憶装置３０８からロードすることができる。しかし、非インクデータは、アプリケーション３０４に関連付けられた記憶装置からロードされると考えられる。インクドキュメント構造は、プラットフォームコンポーネントであってよい、インクアナライザ３０６からロードすることができる。一実施形態では、アプリケーション３０４は、再解析を行わなくてもインクがロードされるように未処理データおよびインクドキュメント構造を関連付ける。
【００２１】
図４は、本発明の一態様による例示的なインキング４００を表している。インキング４００は、テキスト、図面、テーブル、チャートなどと関連付けることができるか、またはそれらとの関係を持つことができる。また、インキング４００は、さまざまな種類の手書き、描画、形状、言語、記号、および歪みを含むこともできる。以下でさらに詳しく説明するが、インキング４００は、インクドキュメント構造の複数のノードに相関する複数の入力を含むことができる。例えば、参照番号４０２は、手書き領域を示している。
【００２２】
他の実施例として、参照番号４０４は、位置揃え（ａｌｉｇｎｍｅｎｔ）レベルを示している。図４に例示されているインキング４００の最初と最後の行は、同じレベルにインデントされ、したがって、位置揃えレベル４０４を示している。インキング４００の真ん中の行は、内側にインデントされ、したがって、他の位置揃えレベルを示している。
【００２３】
さらに他の実施例では、参照番号４０６は、段落を示し、参照番号４０８は、１行を示す。インキング４００はまた、単語４１０も含み、図には示されていないが、単語４１０はまた、ストロークも含むことができる。ストロークは、単語の一部を含むことができる。
【００２４】
図５は、例示的なインクドキュメント構造５００を表す。例示的なインクドキュメント構造５００は、例示的なインキング４００に関係する。インクドキュメント構造５００は、インクドキュメント構造の一例にすぎない。データ構造の表現を実現しやすくする任意の種類の木構造を実装することができる。インクドキュメント構造５００は、ルートノード５０１、手書き領域ノード５０２、位置揃えレベルノード５０４、段落ノード５０６、行ノード５０８、単語ノード５１０、および／またはストロークノード（図に示されていない）などの複数のノードを含む。インクドキュメント構造５００はまた、描画ノード５１２、ヒントノード５１４、および１つまたは複数のリンクも含むことができる。
【００２５】
図４において、線描画４１２は、「Ｍｒ．Ｂｈａｔｔａｃｈａｒｙａｙ」という名前の下線である。線描画４１２は、図５では描画ノード５１２により表される。線描画４１２は単語「Ｍｒ．」および「Ｂｈａｔｔａｃｈａｒｙａｙ」に関連付けられるという点において、描画ノード５１２および単語ノード５１０および５１１は、図５に示されているようなリンクを通じて関連付けられる。同様に、参照番号４１４は、ある種類のヒントを表す。一実施形態では、ヒント４１４はヒントボックスを含む。ヒント４１４は、入力が数、英字、記号、構造、コード、順序などであることを示す。例えば、図４では、ヒントは、入力が３桁以下の数であることを示唆するヒントを含むことができる。したがって、インクアナライザは、「５」を「Ｓ」と取り違えることがない。ヒント４１４は手書き「３５」に関連付けられているという点において、ヒントノード５１４は、図５に示されているようにリンクを通じて単語ノード５１５に関連付けることができる。上述の実施例は、例示および説明のみを目的としている。
【００２６】
この方法では、インキング４００は、ノードを通じてインクドキュメント構造５００として表すことができる。例えば、ストロークノード（図に示されていない）は、単語ノード５１０の子であってよい。単語ノード５１０は、行ノード５０８の子であってよく、行ノード５０８は、段落ノード５０６の子であってよい。同様に、段落ノード５０６は、位置揃えレベルノード５０４の子であってよく、位置揃えレベル点５０４は、手書き領域ノード５０２の子であってよい。この方法で、ルートノード５０１は、その子ノードのすべての情報含むことができる。一実施形態では、インキング全体４００は、ルートノード５０１を参照して表すことができる。ドキュメント木構造内のドキュメントの表現がしやすくなる限り任意の個数のノードを任意の種類のドキュメントに関連付けることができる。
【００２７】
２．インクドキュメントのシリアル化
図６は、シリアルバイナリ形式６００でドキュメント構造を内部的に格納するための例示的な一実施形態を表す。インクドキュメント構造が本明細書で参照されているとしても、シリアルバイナリ形式６００を使用して任意の種類の木ドキュメント構造を格納することができる。インクドキュメント構造が生成される場合、ドキュメント構造に関係する１つまたは複数の文字列が存在する。一実施形態では、圧縮は、これらの文字列のＬｅｍｐｅｌ−Ｚｉｖ Ｗｅｌｃｈ形式（「ＬＺＷ形式」）を含む。しかし、文字列は、文字列のサイズを縮小する圧縮形式により圧縮することができると考えられる。図６は、データの記憶装置６０４〜６１８の拡大図を含む（一部のデータは状況に応じて格納される）。一実施形態では、記憶装置は、記憶領域を節約するため符号なし整数を格納しやすくする多バイト符号化（「ＭＢＥ」）値を含む。
【００２８】
シリアルバイナリデータブロック６０２は、インクドキュメントのシリアル化されたバイナリデータを含み、データブロック６０４〜６１８により表される。データブロック６０４〜６１８は、シリアルバイナリデータブロック６０２全体の拡大図を表す。サイズデータ６０４は、シリアルバイナリデータブロック６０２に格納される第１の情報とすることができる。サイズデータ６０４は、インクドキュメント構造のサイズに関連付けられたデータを含む。
【００２９】
インクドキュメントディスクリプタデータ６０６は、サイズデータ６０４に従うことができる。インクドキュメントディスクリプタデータ６０６は、シリアルバイナリデータブロック６０２に含まれるベータの型に関して予想を関連付ける任意の型のデータを含むことができる。この予想は、インクドキュメント構造で使用可能な関連付けられたデータを表すフラグの集合により示すことができる。これらのフラグは、シリアルバイナリデータブロック６０２内で使用可能なデータを示すことができる。データブロック６０４〜６１８は、インクドキュメント構造に関連付けることができるデータの少数の例にすぎない。本発明の一実施形態では、ルートノードデータ６１４（以下でさらに説明する）は、常に、インクドキュメントディスクリプタ６０６内のフラグに関連付けられる。
【００３０】
ダーティ領域（Ｄｉｒｔｙ ｒｅｇｉｏｎ）データ６０８は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。ダーティ領域データ６０８は、保存前に完全には解析されていないインクドキュメント構造内のデータを指す。ダーティ領域データ６０８は、ＴｅｘｔＷｏｒｄ、Ｉｍａｇｅなどのインクデータと非インクデータの両方を指すことができる。ダーティ領域データ６０８は、インクドキュメントディスクリプタデータ６０６に関連付けられたフラグにより示すことができる。インクドキュメントディスクリプタデータ６０６がダーティ領域を示すフラグを含む場合、このフラグは、インクドキュメント構造が有限の、空でないダーティ領域を持つことを示す。ダーティ領域データ６０８が存在する場合、このデータは、ダーティ領域の再作成をしやすくするためバイナリ形式で格納される一連の矩形として表すことができる。インクドキュメントが完全に解析される状況では、ダーティ領域データ６０８は、存在しない場合があり、インクドキュメントディスクリプタ６０６内にフラグを必要としない。一実施形態では、ダーティ領域データ６０８（もし存在すれば）は、インクドキュメントディスクリプタ６０６の直後に来る。
【００３１】
一実施形態では、ダーティ領域データ６０８は、領域データとしてシリアルバイナリデータブロック６０２に格納される。領域データ形式は、ダーティ領域データ６０８、非インク葉文脈ノードに対する位置データ、またはヒントノードに対する位置を格納するために使用することができる。領域データは、領域データのエリア全体を定義する個別の矩形の配列を含むことができる。ストリームから領域データオブジェクト（例えば、ダーティ領域データ６０８）を適切に再構築するために、領域データは矩形のカウントを含むことができる。すべての矩形について、領域データは、上データ、左データ、幅データ、および高さデータに関する情報を含むことができる。矩形データを記述する個々の値は、ＭＢＥまたは符号付き多バイト符号化（「ＳＭＢＥ」）を使用して格納することができる。永続的領域データの表現の一例は以下のとおりである。
【００３２】
【表１】
矩形データは、以下のように表すことができる。
【００３３】
【表２】
【００３４】
グローバル一意識別子（「ＧＵＩＤ」）テーブルデータ６１０は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。ＧＵＩＤテーブルデータ６１０は、ＧＵＩＤテーブルおよび／またはＧＵＩＤ値のリストに関連付けられているＭＢＥ ＧＵＩＤの個数のカウントを含むことができる。ＧＵＩＤ値のリストは、それぞれのＧＵＩＤに対する１６バイト符号なしリテラル値（ｕｎｓｉｇｎｅｄ ｌｉｔｅｒａｌ ｖａｌｕｅ）を含むことができる。インクドキュメント構造またはドキュメント木構造内の個々のノードは、ＧＵＩＤにより識別される任意のデータを含むことができる。この任意のデータは、周知のデータ型および特定のアプリケーションに関連付けられているデータ型を含むことができる。特定のアプリケーションに関連付けられているデータ（つまり、カスタムプロパティデータ）では、データは特定のＧＵＩＤと突き合わせて格納される。ＧＵＩＤテーブルデータ６１０は、演繹的に知られることのないインクドキュメント構造に関して使用されるＧＵＩＤの値を指定する。ＧＵＩＤテーブルデータ６１０は、インクドキュメントレベルまたは文脈ノードレベルで任意のカスタムプロパティデータに対応し、その後、ＭＢＥを介して、ＧＵＩＤテーブルデータ６１０に関するゼロを基点とするインデックスと呼ばれる。例えば、事前定義されていないＧＵＩＤは、アプリケーション特有の拡張ノード型およびノードに関するアプリケーション特有の拡張プロパティを含むことができる。ＧＵＩＤテーブルデータ６１０がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、ドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、ＧＵＩＤテーブルデータ６１０が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的ＧＵＩＤテーブルデータの表現の一例は以下のとおりである。
【００３５】
【表３】
【００３６】
文字列テーブルデータ６１２は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。文字列テーブルデータ６１２は、文字列テーブル内のＭＢＥ文字列の個数のカウント、圧縮された文字列データのサイズ、および／または圧縮された文字列データを含むことができる。文字列テーブルデータ６１２は、解析ヒントサフィックスデータ、プレフィックステキストデータ、擬似事実データ、ヒント名データ、単語リストデータ、カスタムノードリンクデータ、および認識された文字列データに関連付けることができる。本発明の一態様に関して、文字列テーブルデータ６１２は、重複を含むことができる。インクドキュメント構造が特定の順序でロードされる限り、文字列テーブルデータ６１２へのインデックスを保持することで、文字列テーブルデータ６１２から適切な文字列データをロードすることができる。
【００３７】
インデックスは、文字列が文字列テーブルデータ６１２に関連付けられるたび毎に書き込まれるわけではない。このような状況では、１インスタンス当たり少なくとも１バイトが節約される。さらに、文字列テーブルデータ６１２内の文字列はＬＺＷ圧縮とすることができる。ＬＺＷ圧縮と組み合わせてすべての文字列についてインデックスを書かないことにより、文字列のサイズを実質的に縮小することができる。文字列テーブルデータ６１２がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、文字列テーブルデータ６１２が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的文字列テーブルデータの表現の一例は以下のとおりである。
【００３８】
【表４】
【００３９】
ルートノードデータ６１４は、ルートノードのサイズに関係するデータおよび／またはルートノードに関連付けられたデータを含む。ルートノードデータ６１４は、図８に関して説明されているように格納することができる（以下でさらに詳しく説明する）。一態様では、ルートノードデータは、ルートノードデータ６１４が空であってもすべてのインクドキュメント構造と関連する必須データである。インクドキュメントディスクリプタデータ６０６に関連付けられたフラグは、ルートノードデータ６１４の存在を示すことができる。
【００４０】
リンクデータ６１６は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。リンクデータ６１６は、インクドキュメント構造のノードが同じインクドキュメント構造内の他のノードにリンクされているかどうかを示すデータを含む。リンクデータ６１６は、インクドキュメント構造に関連して大域的に保持されるようにできる。リンクデータ６１６を格納するときに、リンクデータ６１６は、インクドキュメント構造に関連付けられたリンクの個数のカウントを含むことができる。個別のリンクデータ６１６はまた、データのＭＢＥサイズも含むことができる。一態様では、ＭＢＥサイズデータの後にリンクディスクリプタが続き、これにより、リンクの型およびリンク元情報（ｏｒｉｇｉｎ ｉｎｆｏｒｍａｔｉｏｎ）を識別する。他の態様では、リンクディスクリプタデータの後に、リンク元ノード（ｓｏｕｒｃｅ ｎｏｄｅ）インデックスのＳＭＢＥ値とリンク先ノード（ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ）インデックスのＳＭＢＥ値が続く。リンク元ノードインデックスおよびリンク先ノードインデックスにより、リンク元ノードおよびリンク先ノードをそれぞれ識別する。さらに他の態様では、リンクデータ６１６がカスタムリンクを含むことをリンクディスクリプタデータが示している場合、グローバル文字列テーブル内のインデックスにより示されたグローバル文字列テーブルからカスタムリンクデータが読み込まれる。リンクデータ６１６がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、リンクデータ６１６が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的リンクデータの表現の一例は以下のとおりである。
【００４１】
【表５】
【００４２】
カスタムプロパティデータ６１８は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。カスタムプロパティデータ６１８は、インクドキュメント構造に関連付けることができ、一態様では、ノードに関連付けられたカスタムプロパティデータとして格納される。カスタムプロパティデータは、アプリケーションがノードと関連付ける任意のデータを含むことができる。カスタムプロパティデータはＧＵＩＤにより識別され、既知または未知のＧＵＩＤを含むことができる。ＧＵＩＤが未知の状況では、ＧＵＩＤはＧＵＩＤテーブルデータ６１０として格納することができる。カスタムプロパティデータ６１８を格納する際に、フラグによりカスタムプロパティデータ６１８を既知の値として識別することができる。他の態様では、カスタムプロパティデータ６１８の格納は、ＧＵＩＤテーブルデータ６１０へのインデックスを含む。カスタムプロパティデータ６１８の記憶装置はまた、データのサイズのＭＢＥ値およびそのデータを表すバイトの配列を含むこともできる。カスタムプロパティデータ６１８がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、カスタムプロパティデータ６２０が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的インクドキュメント構造の表現の一例は以下のとおりである。
【００４３】
【表６】
【００４４】
図７は、文脈ノードデータ７００を内部に格納するための例示的な一実施形態を表している。一実施形態では、ルートノードデータ６１４は、文脈ノードであり、文脈ノードデータ７００として格納される。文脈ノードデータ７００は、インクドキュメントのシリアル化されたバイナリデータに含まれることができ、データブロック７０４〜７１６により表される。データブロック７０４〜７１６は、文脈ノードデータ７０２の拡大図を表す。
【００４５】
ノードディスクリプタデータ７０４は、インクドキュメント構造のそれぞれのノードに関連付けられているデータを含むことができる。ノードディスクリプタデータ７０４は、ノードデータの構成とともにインクドキュメント構造に関連付けられたノードの種類をも定義するフラグの集合体により示すことができる。
【００４６】
ノードサイズデータ７０６は、特定のノード上に格納される可能な既知のプロパティを含むことができる（例えば、格子データ、境界ボックスデータ、および／またはピンニングフラグデータ）。ノードサイズデータ７０６はまた、位置データ、子下位ノードデータ、およびストロークデータとともに未知のプロパティ（拡張／カスタムプロパティ）を含むこともできる。一態様では、ノードサイズデータ７０６は、ノードディスクリプタデータ７０４の直後に置くことができる。簡潔に述べると、ノードディスクリプタデータ７０４は、文脈ノード木全体のサイズを示すことができる。
【００４７】
ノード位置データ７０８は、すべてのノード型に関連付けられるわけではないオプションデータである。ノード位置データ７０８が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別される。同様に、ノード位置データ７０８が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。一態様では、ノードディスクリプタデータ７０４が非インク葉ノードを示している場合、ノード位置データ７０８が続くことができる。非インク葉ノードは、子ノードを持たない、またストロークデータを含まないノードを含むことができる。例えば、非インク葉ノードは、イメージノード、テキストノード、またはヒントノードを含むことができる。一実施形態では、ノード位置データ７０８は領域データとして格納される。領域データは、領域データのエリア全体を定義する個別の矩形の配列を含むことができる。ストリームから領域データオブジェクト（例えば、ノード位置データ７０８）を適切に再構築するために、領域データは矩形のカウントを含むことができる。すべての矩形について、領域データは、上データ、左データ、幅データ、および高さデータに関する情報を含むことができる。矩形データを記述するこれら個々の値は、ＭＢＥまたはＳＭＢＥを使用して格納することができる。永続的領域データの表現の一例は以下のとおりである。
【００４８】
【表７】
【００４９】
ストロークデータ７１０は、すべてのノード型に関連付けられるわけではないオプションデータである。ストロークデータ７１０は、ストロークデータを含む任意のノードに関連付けられたデータを含むことができる。例えば、ストロークデータ７１０は、非分類インクノード、単語ノード、または描画ノードに関連付けることができる。ストロークデータ７１０が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ストロークデータ７１０が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。
【００５０】
ストロークデータ７１０が存在する場合、記憶装置には、ノードに関連付けられたストロークの数のＭＢＥ値を入れることができる。一態様では、それぞれのストロークは、ストロークディスクリプタフラグの集合体を含む１バイトのストロークディスクリプタに関連付けられる。これらのフラグは、ＭＢＥストローク識別データを示すストローク識別を示すことができる。一態様では、ストローク識別フラグがセットされていない場合、ストローク識別は、取り出された最後のストローク識別を含むことができる。これらのフラグはまた、手書きに関連付けられているストロークの型を識別する手書きストロークディスクリプタフラグも含むことができる。他の態様では、これらのフラグは、描画に関連付けられているストロークの型を識別する描画ストロークディスクリプタフラグを含むことができる。これらのフラグはまた、ハイライトに関連付けられているストロークの型を識別するハイライターディスクリプタフラグも含むことができる。さらに他の実施形態では、これらのフラグは、ストロークの有効な確認済みの祖先を識別する確認済み祖先ディスクリプタフラグを含むことができる。確認済み祖先シリアル化インデックスのＭＢＥ値をストリーム内に格納することができる。さらに他の実施形態では、これらのフラグは、ストロークに関連付けられた言語を識別するストローク言語の識別フラグを含むことができる。言語に対応する符号付き符号化値（ｓｉｇｎｅｄ ｅｎｃｏｄｅｄ ｖａｌｕｅ）は、ストリーム内に格納できる。さらに他の実施形態では、フラグに関連付けられた値は、ストロークディスクリプタデータに応じて上述の順序で格納される。ストロークの識別を容易にする任意の型のフラグをセットできることもさらに考えられる。
【００５１】
子ノードデータ７１２は、すべてのノード型に関連付けられるわけではないオプションデータである。子ノードデータ７１２が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、子ノードデータ７１２が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。子ノードデータ７１２は、コンテナ型ノードを含むことができる（つまり、段落ノード、行ノード、位置揃えノード、手書き領域ノード、および／またはルートノードなど）。コンテナノードは、子ノードを含む任意のノード型を含むことができる。子ノードデータ７１２の記憶装置は、子ノードの個数およびそれぞれの子ノードからのデータを格納することを含む。それぞれの子からのデータは、文脈ノードデータ７０２と同じようにして格納される。
【００５２】
ノード既知プロパティデータ７１４は、すべてのノード型に関連付けられるわけではないオプションデータである。ノード既知プロパティデータ７１４が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ノード既知プロパティデータ７１４が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。
【００５３】
ノード既知プロパティデータ７１４は、データ型および形式が知られており、データサイズを縮小するために最適化を容易にするプロパティを含む。ノード既知プロパティデータ７１４は、回転された境界ボックスデータ（８個の整数の配列）、認識格子データ（可変長を含むバイトの配列）、注釈データ確認データ（整数型）、および／またはヒントデータ（ヒントノード用）を含むことができる。一実施形態では、このデータは、データのバイナリ表現を最適化するために定義済みの方法により格納される。例えば、整数の配列は、符号付き符号化形式で保存することができる。また、構造体またはクラスデータなどの複合データ型は、効率よくデータを定義するバイナリ形式で格納することができる。永続的既知プロパティデータの表現の一例は以下のとおりである。
【００５４】
【表８】
【００５５】
ノードカスタムプロパティデータ７１６は、すべてのノード型に関連付けられるわけではないオプションデータである。ノードカスタムプロパティデータ７１６が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ノードカスタムプロパティデータ７１６が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。ノードカスタムプロパティデータは、アプリケーションがノードと関連付ける任意のデータを含むことができる。ノードカスタムプロパティデータ７１６はＧＵＩＤにより識別され、既知または未知のＧＵＩＤを含むことができる。ＧＵＩＤが未知の状況では、ＧＵＩＤはＧＵＩＤテーブルデータ６１０として格納することができる。ノードカスタムプロパティデータ７１６を格納する際に、フラグによりノードカスタムプロパティデータ７１６を既知の値として識別することができる。他の態様では、ノードカスタムプロパティデータ７１６を格納することは、ＧＵＩＤテーブルデータ６１０へのインデックスを含む。ノードカスタムプロパティデータ７１６の記憶装置はまた、データのサイズのＭＢＥ値およびそのデータを表すバイトの配列を含むこともできる。永続的文脈ノードデータの表現の一例は以下のとおりである。
【００５６】
【表９】
【００５７】
それぞれのストロークデータブロブ（ｂｌｏｂ）は、以下のようにストリームで表される。
【００５８】
【表１０】
【００５９】
３．シリアル化形式でドキュメント格納するための例示的なプロセス
図８は、インクドキュメントデータをシリアル化バイナリ形式で格納するためのシステムの一般的な実施形態を表している。システム８００は、開始ブロック８０２から始まり、インクドキュメントが生成されるブロック８０４へ流れる。ブロック８０４は、ユーザからのストローク入力を２値化するデジタイザを備えることができる。デジタイザは、コンピューティングデバイス（例えば、図１）、モバイルコンピューティングデバイス（例えば、図２）、本件特許出願人のＷＩＮＤＯＷＳ（登録商標） ＸＰ ＴＡＢＬＥＴ ＥＤＩＴＩＯＮ上で稼働するＴＡＢＬＥＴ ＰＣ、またはインクアプリケーションのオペレーションを容易にする任意のデバイスを含むことができる。さらに、本明細書の説明でインクドキュメントを参照しているとしても、システム８００は、任意の型のデータに関して実装することができる。例えば、本発明は、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、ドローイングアプリケーション、グラフィックスアプリケーション、ノーツアプリケーション、画像アプリケーションなどに関連して使用することもできる。一実施形態では、アプリケーションは、本件特許出願人のＩｎｋＥｄｉｔ、ＩｎｋＰｉｃｔｕｒｅ、および／またはＯｎｅＮｏｔｅを含む。ブロック８０４から、プロセス８００はブロック８０６に流れる。
【００６０】
ブロック８０６は、未処理インクデータを生成するステップを示す。一実施形態では、未処理インクデータを生成することは、デジタイザでストローク入力を未処理インクデータに変換し、未処理インクデータを未処理データ記憶装置に格納することを含む。他の実施形態では、未処理インクデータを生成することは、デジタイザでストローク入力を未処理インクデータに変換し、未処理インクデータをアプリケーションに送信することを含む。次いでプロセス８００は、ブロック８０８に流れる。
【００６１】
ブロック８０８は、インクドキュメント構造を生成するステップを示す。ブロック８０８は、アプリケーションから未処理インクデータを受信するインクアナライザを含むことができる。インクアナライザは、図３に関して上で詳しく説明されているように解析および認識オペレーション用に構成することができる。ブロック８０８は、さらに、図４および５に従って上述のようにインクドキュメント構造を生成することを含むことができる。他の実施形態では、インクドキュメント構造は、インキングに相関する複数のノードを含む。例えば、インクドキュメント構造は、手書き領域ノード、位置揃えノード、段落ノード、行ノード、単語ノード、またはストロークノードを含むことができる。インクドキュメント構造は、さらに、描画ノードおよび／またはヒントノードを含むこともできる。インクドキュメント構造は、インキングの２分木表現を実現しやすくする任意の型のノードを含むことができることが考えられる。他の実施形態では、これらのノードは、関係するノードと相関するリンクに関連付けることができる。
【００６２】
ブロック８１０に流れるときに、インクドキュメント構造は、大域的にアクセス可能なように格納できる。一実施形態では、インクドキュメント構造は、圧縮され、図６および７に関して上で説明されているように格納される。このような場合、インキングは、アプリケーションと連携して生成することができ、その後、他のアプリケーションからアクセス可能なように格納することができる。言い方を変えると、プラットフォームに関連付けられている他のアプリケーションは、インクドキュメント構造および未処理インクを使用して解析されたインクを再生成することができる。このようにアクセス可能であるため、アプリケーション間でカット＆ペーストのオペレーションを容易に実行できる。また、インクは、インクが解析され、認識され、シリアル化形式で保存されている限り、インクドキュメント全体の再解析を行わなくても修正することができる。
【００６３】
４．例示の動作環境
図１を参照すると、本発明を実装する例示的なシステムは、コンピューティングデバイス１００などのコンピューティングデバイスを含む。基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備えるのがふつうである。コンピューティングデバイスの正確な構成と種類に応じて、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のアプリケーション１０６を含み、またプログラムデータ１０７を含むこともある。一実施形態では、アプリケーション１０６は、さらに、インキングオペレーション用のアプリケーション１２０を含む。基本構成は、図１において点線１０８内のコンポーネントにより示されている。
【００６４】
コンピューティングデバイス１００は、さらに特徴または機能を追加することもできる。例えば、コンピューティングデバイス１００は、磁気ディスク、光ディスク、またはテープなどの追加データ記憶装置デバイス（取り外し可能および／または取り外し不可能）を備えることもできる。このような追加記憶装置は、図１では、取り外し可能記憶装置１０９および取り外し不可能記憶装置１１０により例示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことができる。システムメモリ１０４、取り外し可能記憶装置１０９、および取り外し不可能記憶装置１１０は、すべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体としては、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または所望の情報を格納するために使用することができコンピューティングデバイス１００によりアクセスできるその他の媒体がある。このような任意のコンピュータ記憶媒体を装置１００の一部とすることができる。さらにコンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの（複数の）入力デバイス１１２を有することもできる。ディスプレイ、スピーカ、プリンタなどの（複数の）出力デバイス１１４を備えることもできる。これらの装置はすべて、当業に周知であるため、本明細書でさらに詳しい説明をする必要はない。
【００６５】
また、コンピューティング装置１００は、デバイスがネットワークまたはワイヤレスメッシュネットワークなどを経由して他のコンピューティングデバイス１１８と通信するために使用する通信接続（群）１１６も含むことができる。通信接続（群）１１６は、通信媒体の一実施例である。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの被変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。「被変調データ信号」という用語は、信号内に情報を符号化するような方法で特性のうちの１つまたは複数が設定または変更された信号を意味する。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００６６】
図２は、本発明の例示的な一実施形態で使用できるモバイルコンピューティングデバイスを示している。図２を参照すると、本発明を実装する例示的なシステムは、モバイルコンピューティングデバイス２００などのモバイルコンピューティングデバイスを含む。モバイルコンピューティングデバイス２００は、プロセッサ２６０、メモリ２６２、ディスプレイ２２８、およびキーパッド２３２を備える。メモリ２６２は、一般に、揮発性メモリ（例えば、ＲＡＭ）と不揮発性メモリ（例えば、ＲＯＭ、フラッシュメモリなど）の両方を含む。モバイルコンピューティングデバイス２００は、メモリ２６２内に常駐し、プロセッサ２６０上で実行される、オペレーティングシステム２６４を格納する。キーパッド２３２は、プッシュボタン式数値ダイヤリングパッド（典型的な電話機などの）、またはマルチキーキーボード（従来のキーボードなど）としてよい。ディスプレイ２２８は、液晶ディスプレイ、またはモバイルコンピューティングデバイスで一般的に使用される他の種類のディスプレイとすることができる。ディスプレイ２２８は、タッチセンシティブとすることができ、その場合、入力デバイスとしても機能する。
【００６７】
１つまたは複数のアプリケーションプログラム２６６がメモリ２６２内にロードされ、オペレーティングシステム２６４上で実行される。アプリケーションプログラムのいくつかの実施例としては、電話ダイヤラープログラム、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどがある。モバイルコンピューティングデバイス２００はまた、メモリ２６２内に不揮発性記憶装置２６８を含む。不揮発性記憶装置２６８は、モバイルコンピューティングデバイス２００の電源が切れた場合に失われてはならない永続的情報を格納するために使用することができる。アプリケーション２６６では、電子メールまたは電子メールアプリケーションにより使用されるその他のメッセージ、ＰＩＭで使用する連絡先情報、スケジューリングプログラムにより使用されるアポイントメント情報、ワードプロセッシングアプリケーションにより使用されるドキュメントなどの情報を使用し、記憶装置２６８内に格納することができる。一実施形態では、アプリケーション２６６は、さらに、インキングオペレーション用のアプリケーション２８０を含む。
【００６８】
モバイルコンピューティングデバイス２００は、１つまたは複数の電池として実装することができる電源２７０を備える。電源２７０は、さらに、ＡＣアダプタまたは電池を補助または充電する電力供給用ドッキングクレードルなどの外部電源を備えることも可能である。
【００６９】
モバイルコンピューティングデバイス２００は、２種類の外部通知メカニズム、ＬＥＤ ２４０とオーディオインターフェイス２７４とともに示されている。これらのデバイスは、作動させたときに、プロセッサ２６０およびその他のコンポーネントが節電のためシャットダウンする可能性があっても通知メカニズムにより指示される継続期間の間オンのままになるように電源２７０に直接結合することができる。ＬＥＤ ２４０は、ユーザがデバイスの電源投入ステータスを示す処置を講じるまでいつまでもオンのままになるようにプログラムすることができる。オーディオインターフェイス２７４は、可聴信号を供給し、ユーザから可聴信号を受信するために使用される。例えば、オーディオインターフェイス２７４をスピーカに結合することで可聴出力を供給し、マイクに結合することで、電話での会話を容易にするためなど、可聴入力を受け取ることができる。
【００７０】
モバイルコンピューティングデバイス２００はまた、無線周波通信など通信を送受信する機能を実行する無線インターフェイス層２７２も含む。無線インターフェイス層２７２を使用すると、通信事業者またはサービスプロバイダを介して、モバイルコンピューティングデバイス２００と外部世界との無線接続性を容易に実現できる。無線インターフェイス相２７２との間の送信は、オペレーティングシステム２６４の制御の下で実行される。つまり、無線インターフェイス層２７２により受信される通信は、オペレーティングシステム２６４を介してアプリケーションプログラム２６６に、またその逆に広めることができる。
【００７１】
上記の詳説、実施例、およびデータは、本発明の構成の製造および使用に関する完全な説明となっている。本発明の多くの実施形態は、本発明の精神と範囲を逸脱することなく実装できるため、本発明は付属の請求項によって定められる。
【図面の簡単な説明】
【００７２】
【図１】本発明の一態様で使用できる例示的なコンピューティングデバイスを示す図である。
【図２】本発明の一態様で使用できる例示的なモバイルデバイスを示す図である。
【図３】インクドキュメントデータをシリアルバイナリ形式で格納するためのシステムの例示的な一態様を示す図である。
【図４】本発明の一態様による例示的なインキングを示す図である。
【図５】図４に表されているインキングの一部を表す例示的なインクドキュメント構造を示す図である。
【図６】本発明のいくつかの態様によるシリアルバイナリデータブロックを格納するためのデータ構造を示す図である。
【図７】本発明のいくつかの態様による文脈ノードデータを格納するためのデータ構造を示す図である。
【図８】インクドキュメント構造をシリアルバイナリ形式で格納するための一般的な態様を示す流れ図である。
【符号の説明】
【００７３】
１００ コンピューティングデバイス
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ アプリケーション
１２０ インク
１０７ プログラムデータ
１０２ 演算処理装置
１０９ 取り外し可能記憶装置
１１０ 固定記憶装置
１１２ 入力デバイス（群）
１１４ 出力デバイス（群）
１１６ 通信接続（群）
１１８ 他のコンピューティングデバイス
２２８ ディスプレイ
２３０ 周辺デバイスポート
２３２ キーパッド
２４０ ＬＥＤ
２６０ プロセッサ
２６２ メモリ
２６４ ＯＳ
２６６ アプリケーション（群）
２６８ 記憶装置
２７０ 電源
２７２ 無線インターフェイス層
２７４ オーディオインターフェイス
２８０ インク
３０２ デジタイザ
３０４ アプリケーション
３０６ インクアナライザ
３０８ 未処理データ記憶装置
５０１ ルート
５０２ 手書き領域
５１２ 描画
５０４ 位置揃えレベル
５０６ 段落
５０８ 行
５１０ 単語
５１４ ヒント
５１５ 単語
６０２ シリアルバイナリデータブロック
６０４ サイズデータ（インクドキュメント全体のサイズ）
６０６ インクドキュメントディスクリプタデータ
６０８ ダーティ領域データ（オプション）
６１０ ＧＵＩＤテーブルデータ（オプション）
６１２ 文字列テーブルデータ（オプション）
６１４ ルートノードデータ
６１６ リンクデータ（オプション）
６１８ カスタムプロパティデータ（オプション）
７０２ 文脈ノードデータ
７０４ ノードディスクリプタデータ
７０６ ノードサイズデータ
７０８ ノード位置データ（オプション）
７１０ ストロークデータ（オプション）
７１２ 子ノードデータ（オプション）
７１４ ノード既知プロパティデータ（オプション）
７１６ ノードカスタムプロパティデータ（オプション）
【技術分野】
【０００１】
タブレットＰＣを使用することで、ユーザはふつう、画面に直接描画または書くことができる。この描画または手書きは、一般に「インキング」と呼ばれる。インキングは、一種のユーザ入力であり、タッチスクリーン、およびユーザが従来のペンと紙で書くのと同様にコンピューティングペン（ｃｏｍｐｕｔｉｎｇ ｐｅｎ）を使用し画面上に書くことを含むことができる。インキングは、さまざまなアプリケーションで使用される。例えば、インキングは、ドローイングアプリケーション、ペインティングアプリケーション、ワードプロセッシングアプリケーション、クレジットカード署名アプリケーションなどで使用することができる。
【背景技術】
【０００２】
インキングは、ただ単なるペンストロークの視覚的表現を含むだけではなく、データ型をも含むことができる。データ構造は知られているが、情報を格納するために使用されるデータ構造のサイズはひどく大きくなり、扱いにくいものとなる可能性がある。また、プログラム間にドキュメント構造の互換性があれば、コンピュータの効率および一般的な使い勝手が向上する。しかし、互換性は、ユーザが一方のアプリケーションから他方のインクアプリケーションへインクデータを転送することを望んでいる場合に問題になりうる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
一般に、本発明のいくつかの態様は、ドキュメント構造を生成し、シリアルバイナリ形式でそのドキュメント構造を格納するシステムおよび方法に関係する。本発明はまた、インクドキュメント構造を生成し、他のアプリケーションからアクセス可能なようにインクドキュメント構造を格納するシステムおよび方法にも関係する。本発明は、さらに、インキング全体の再解析を必要とすることなくインキングの一部を修正または変更するシステムおよび方法に関係する。
【課題を解決するための手段】
【０００４】
本発明のいくつかの態様は、ドキュメントデータが他のアプリケーションからアクセス可能なようにシリアル化されたバイナリ形式でドキュメントデータを格納するためのデータ構造を備えるコンピュータ可読媒体に関係する。ルートノードデータを含むドキュメント構造が生成される。ドキュメントは、シリアルバイナリデータ形式で格納される。シリアルバイナリ形式は、第１のデータフィールド内のドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式はまた、第２のデータフィールドにドキュメントディスクリプタデータを格納することを含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【０００５】
本発明の他の態様は、２分木構造をシリアル化形式で格納するコンピュータ実装方法に関係する。コンピュータ実装方法は、第１のデータフィールド内にドキュメント構造のサイズデータを格納することを含む。このコンピュータ実装方法はまた、第２のデータフィールドにドキュメント構造ディスクリプタデータを格納することも含み、ドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。このコンピュータ実装方法は、さらに、第３のデータフィールドにルートノードデータを格納することを含み、ルートノードデータは、フラグの少なくとも１つにより示される。
【０００６】
本発明のさらに他の態様は、コンピュータ実行可能命令が格納されているコンピュータ可読媒体に関係する。これらの命令は、インクドキュメント構造を生成することを含み、インクドキュメント構造は、少なくとも１つのルートノードを含む。これらの命令はまた、シリアルバイナリ形式でインクドキュメント構造を格納することも含む。シリアルバイナリ形式は、第１のデータフィールド内のインクドキュメント構造に関連付けられたサイズデータを格納することを含む。シリアルバイナリ形式はまた、第２のデータフィールドにインクドキュメントディスクリプタデータを格納することも含み、インクドキュメント構造ディスクリプタデータは、データ予想を示すための少なくとも１つのフラグを含む。シリアルバイナリ形式は、さらに、第３のデータフィールドにルートノードデータを格納することを含むことができ、ルートノードデータは、フラグの少なくとも１つにより示される。
【発明を実施するための最良の形態】
【０００７】
本発明のいくつかの実施形態について、これ以降、本発明の一部をなし、実例として、本発明を実施する特定の例示的な実施形態を示す、添付の図面を参照しつつさらに詳しく説明する。しかし、本発明は、多くの異なる形態で具現化することができ、したがって、本明細書で述べたいくつかの実施形態に限定されるものと解説すべきではなく、むしろ、これらの実施形態は、本開示が網羅的で完全であり、本発明の範囲を完全に当業者に伝えるように実現される。とりわけ、本発明は、方法またはデバイスとして実現することができる。したがって、本発明は、全体としてハードウェア実施形態、全体としてソフトウェア実施形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形を取りうる。したがって、以下の詳細な説明は、限定的な意味で解釈すべきではない。
【０００８】
シリアルバイナリ形式でデータを格納する方法およびシステムの例示的な実施形態
一般に、本発明は、インクドキュメント構造を生成し、他のアプリケーションからアクセス可能なようにインクドキュメント構造を格納するシステムおよび方法に関係する。より具体的には、本発明は、格納効率を高めるためデータをシリアルバイナリ形式で格納するシステムおよび方法に関係する。本発明はまた、インキング全体の再解析を必要とすることなくインクの一部を修正または変更するシステムおよび方法に関係する。本明細書で述べている説明ではインクドキュメントの格納およびロードを参照しているとしても、本明細書で参照されているシリアルバイナリ形式は、他の型のデータを格納するために使用することができる。例えば、本発明は、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、ドローイングアプリケーション、グラフィックスアプリケーション、ノーツアプリケーション、画像アプリケーションなどに関連するデータを含むことができる。簡潔に述べると、シリアルバイナリ形式は、２分木構造に関連付けられた任意の型のデータを格納するために使用することができる。
【０００９】
１．インクアプリケーションの例示的な実施形態
本発明の一態様の一般的な文脈として、インクアプリケーションは、ユーザがペンを使用してデータを入力するときに視覚的フィードバックをリアルタイムで返すことができる。しかし、インキングは、ペンストロークの視覚化よりもさらに多くのものを含み、データ型を含むことができる。ユーザは、ペン、インク、インク解析、およびインク認識のさまざまなレベルの機能をサポートするデジタイザ用のアプリケーションを構築することができる。このようなアプリケーションは、単純なテキスト入力の認識から複雑なインクドキュメントの作成および編集に至るまでさまざまである。
【００１０】
インクアプリケーションはまた、インク−テキスト間変換も含むことができる。状況によっては、直接的インク入力を受け付けないアプリケーションもある。このような状況では、インクアプリケーションは、手書き認識を実装し、インクをテキストに変換することにより、直接的インク入力を受け付けないアプリケーションにカット＆ペーストすることができる。アプリケーションはまた、インクオブジェクトおよび他のドキュメントオブジェクトに関するその文脈も認識することができる。他の実施形態では、ユーザは、インクを操作し、インクを使用して、テキスト、グラフィックス、ベクトル形状、マルチメディアオブジェクトなどを含むリッチドキュメントをオーサリングすることができる。このような実施形態では、インクを、インクオブジェクトをリフローし重ねることができるデータ型として取り扱う。
【００１１】
インク入力は、未処理（ｒａｗ）インクデータの形態でアプリケーションに関連付けることができる。一実施形態では、未処理インクデータをインクアナライザに送り、未処理インクデータを処理し、未処理インクデータと別にすることができるインクドキュメント構造を生成することができる。インクアナライザは、未処理インクデータを管理可能な複数のストローク成分に分割するため解析および認識プロセスを実装することができる。以下でさらに詳しく説明するように、一実施形態では、インクアナライザは、木のそれぞれのノードが未処理インクデータの一部分との関係を定義する２分木を有するインクドキュメント構造を生成することができる。インクドキュメント構造を使用すると、プラットフォームに関連付けられたインクアプリケーションは、未処理インクデータとインクドキュメント構造を関係付けて、オリジナルのインクおよび関連付けられたインクドキュメント構造をロードすることができる。また、インクドキュメント構造を使用することで、ユーザは、インクドキュメント全体を再解析することなくインクをロードし修正することもできる。また、本発明では、１つのプラットフォーム上の複数のアプリケーション間でインクを共有することができる。
【００１２】
図３は、インクドキュメントデータをシリアルバイナリ形式で格納するためのシステムの例示的な一態様の一般的な概要を表す。図に示されているように、システム３００は、デジタイザ３０２、アプリケーション３０４、およびインクアナライザ３０６を含む。デジタイザ３０２は、図１に関して説明されているコンピューティングデバイスを含むことができる。デジタイザ３０２は、図２に関して説明されているモバイルコンピューティングデバイスも含むことができる。一実施形態では、デジタイザは、ワシントン州レドモンドの本件特許出願人のＷＩＮＤＯＷＳ（登録商標）ＸＰ ＴＡＢＬＥＴ ＰＣ ＥＤＩＴＩＯＮ上で稼働するＴＡＢＬＥＴ ＰＣデジタイザを含む。しかし、デジタイザ３０２は、インクアプリケーションの動作をしやすくするデバイスを含むことができる。
【００１３】
デジタイザ３０２は、ユーザ入力ストローク（例えば、手書きおよび／または描画ストローク）を２値化し、一実施形態では、データを未処理データ記憶装置（ｓｔｏｒａｇｅ）３０８に格納する。未処理データ記憶装置３０８は、デジタイザ３０２からのデータを維持することができる種類の記憶装置である。未処理データ記憶装置３０８も、１つまたは複数のアプリケーションおよび／または１つまたは複数のプラットフォームに関連付けることができる。他の実施形態では、デジタイザ３０２は、未処理データ記憶装置３０８をバイパスし、２値化されたデータをアプリケーション３０４に送信する。
【００１４】
アプリケーション３０４は、プラットフォームに関連付けられた任意のアプリケーションを含むことができる。一実施形態では、アプリケーション３０４は、インクを使いやすくするアプリケーションである。アプリケーション３０４は、ワードプロセッシングアプリケーション、ペイントアプリケーション、製図アプリケーション、ドローイングアプリケーション、クレジットカード署名アプリケーションなどを含むことができる。一実施形態では、アプリケーション３０４は、本件特許出願人のＩｎｋＥｄｉｔ、ＩｎｋＰｉｃｔｕｒｅ、および／またはＯｎｅＮｏｔｅを含む。他の実施形態では、アプリケーション３０４は、保存オペレーションおよびロードオペレーションを実行することができる。保存オペレーションは、インクデータおよび非インクデータを保存することを含むことができる。アプリケーション３０４は、未処理インクデータを未処理データ記憶装置３０８に保存し、アプリケーション３０４は、インクドキュメント構造をプラットフォームに関連付けられたインクアナライザに保存することができる。ロードオペレーションでは、アプリケーション３０４は、以下でさらに詳しく説明するようにインクドキュメント構造と未処理インクデータをロードし、統合することができる。
【００１５】
インクアナライザ３０６は、アプリケーション３０４から未処理インクデータを受信するように構成することができる。インクドキュメント構造を生成するため、インクアナライザ３０６は未処理インクデータに対し構造解析を実行するように構成される。構造解析は、未処理データの解析および未処理データの認識を含むことができる。
【００１６】
一実施形態では、構造解析を行うことで、テキスト認識、手書き、および描画分類、およびレイアウト解析を容易にすることができる。インクアナライザ３０６は、連携動作してテキスト認識機能を高める解析コンポーネントおよびレコグナイザコンポーネントを含むことができる。例えば、パーサー（ｐａｒｓｅｒ）は、インクがレコグナイザに送られる前に前処理ステップとしてオペレーションを実行することができる。前処理では、パーサーは、マルチラインインク（ｍｕｌｔｉ−ｌｉｎｅｄ ｉｎｋ）を解析して「きれい（ｃｌｅａｎ）に」し、それを一度に１パーセルずつレコグナイザに送ることができる。パーセルは、インクドキュメントの一部を含むことができる。パーサーは、さらに、不正な入力ストローク順序情報を是正して、入力順序にかかわらずすべてのストロークが確実に認識されるように構成することができる。また、パーサーは、隣接行に関する情報を生成することができる。例えば、２つの隣接行が１つの行頭文字で始まるという事実は、現在行が行頭文字で始まることを示す強い指標となりうる。
【００１７】
他の実施形態では、インクアナライザ３０６の解析オペレーションはまた、インクを描画または手書きとして分類することを含むこともできる。手書きは、単語を認識しやすくするインクストロークを含むことができる。描画ストロークは、手書きストロークでないものを含むことができる。例えば、図４を参照すると、ストローク「Ｈ」は、手書きストロークを含み、「下線」は、描画ストロークを含むことができる。この方法では、一実施形態において、手書きストロークは、レコグナイザに送られる唯一のストロークとすることができる。
【００１８】
インクアナライザ３０６のさらに他の実施形態では、レイアウト解析は、お互いおよび非インクデータに関する手書きおよび描画ストロークの細目（ｂｒｅａｋ ｄｏｗｎ）を含む。インクアナライザ３０６がインキングのストロークを解析した後、これらのストロークの木表現（つまり、インクドキュメント構造）を生成することができる。簡潔にいうと、インクアナライザ３０６は、ドキュメントを２分木で格納し、シリアルバイナリ形式を介してその２分木を他のアプリケーションからアクセスできるようにすることが可能な任意の種類のアナライザを含むことができる。シリアルバイナリ形式がインクドキュメント構造を参照しつつ本明細書で説明されているとしても、シリアルバイナリ形式を使用して、ドキュメント木構造に関連付けられた任意の種類の情報を格納することができる。
【００１９】
インクアナライザ３０６が未処理データに基づいてインクドキュメント構造を生成した後、インクドキュメント構造はアプリケーション３０４から利用することができるようになる。インクドキュメント構造は、ライブインクドキュメント構造を含むことができる。格納オペレーションが引き起こされる（ｉｎｓｔｉｇａｔｅｄ）と、アプリケーション側は、インクアナライザ３０６がインクドキュメント構造を格納することを要求する。インクアナライザ３０６がプラットフォームコンポーネントであるという点において、インクドキュメント構造は他のインクアプリケーションから利用可能である。例えば、ユーザがワードプロセッシングドキュメントでインクを生成する場合、このインクを、再度解析する必要なく、ドローイングアプリケーションにカット＆ペーストすることができる。この実施例では、ドローイングアプリケーションは、インクドキュメント構造からオリジナルのインクを生成する方法を認識する。また、インクは、解析されシリアルバイナリ形式で保存されるため（後述）、インク全体の再解析を必要とすることなく、修正し、効率よく格納することができる。修正された部分は、インクドキュメント構造の単一のパーセル（ｐａｒｃｅｌ）に対応し、したがって、変更されたパーセルの再解析のみをすればよい。
【００２０】
一般に、ロードオペレーションの際に、アプリケーション３０４は、未処理インクデータ、非インクデータ（ｎｏｎ−ｉｎｋ ｄａｔａ）、およびインクドキュメント構造をロードすることができる。未処理インクデータは、未処理データ記憶装置３０８からロードすることができる。非インクデータも、未処理データ記憶装置３０８からロードすることができる。しかし、非インクデータは、アプリケーション３０４に関連付けられた記憶装置からロードされると考えられる。インクドキュメント構造は、プラットフォームコンポーネントであってよい、インクアナライザ３０６からロードすることができる。一実施形態では、アプリケーション３０４は、再解析を行わなくてもインクがロードされるように未処理データおよびインクドキュメント構造を関連付ける。
【００２１】
図４は、本発明の一態様による例示的なインキング４００を表している。インキング４００は、テキスト、図面、テーブル、チャートなどと関連付けることができるか、またはそれらとの関係を持つことができる。また、インキング４００は、さまざまな種類の手書き、描画、形状、言語、記号、および歪みを含むこともできる。以下でさらに詳しく説明するが、インキング４００は、インクドキュメント構造の複数のノードに相関する複数の入力を含むことができる。例えば、参照番号４０２は、手書き領域を示している。
【００２２】
他の実施例として、参照番号４０４は、位置揃え（ａｌｉｇｎｍｅｎｔ）レベルを示している。図４に例示されているインキング４００の最初と最後の行は、同じレベルにインデントされ、したがって、位置揃えレベル４０４を示している。インキング４００の真ん中の行は、内側にインデントされ、したがって、他の位置揃えレベルを示している。
【００２３】
さらに他の実施例では、参照番号４０６は、段落を示し、参照番号４０８は、１行を示す。インキング４００はまた、単語４１０も含み、図には示されていないが、単語４１０はまた、ストロークも含むことができる。ストロークは、単語の一部を含むことができる。
【００２４】
図５は、例示的なインクドキュメント構造５００を表す。例示的なインクドキュメント構造５００は、例示的なインキング４００に関係する。インクドキュメント構造５００は、インクドキュメント構造の一例にすぎない。データ構造の表現を実現しやすくする任意の種類の木構造を実装することができる。インクドキュメント構造５００は、ルートノード５０１、手書き領域ノード５０２、位置揃えレベルノード５０４、段落ノード５０６、行ノード５０８、単語ノード５１０、および／またはストロークノード（図に示されていない）などの複数のノードを含む。インクドキュメント構造５００はまた、描画ノード５１２、ヒントノード５１４、および１つまたは複数のリンクも含むことができる。
【００２５】
図４において、線描画４１２は、「Ｍｒ．Ｂｈａｔｔａｃｈａｒｙａｙ」という名前の下線である。線描画４１２は、図５では描画ノード５１２により表される。線描画４１２は単語「Ｍｒ．」および「Ｂｈａｔｔａｃｈａｒｙａｙ」に関連付けられるという点において、描画ノード５１２および単語ノード５１０および５１１は、図５に示されているようなリンクを通じて関連付けられる。同様に、参照番号４１４は、ある種類のヒントを表す。一実施形態では、ヒント４１４はヒントボックスを含む。ヒント４１４は、入力が数、英字、記号、構造、コード、順序などであることを示す。例えば、図４では、ヒントは、入力が３桁以下の数であることを示唆するヒントを含むことができる。したがって、インクアナライザは、「５」を「Ｓ」と取り違えることがない。ヒント４１４は手書き「３５」に関連付けられているという点において、ヒントノード５１４は、図５に示されているようにリンクを通じて単語ノード５１５に関連付けることができる。上述の実施例は、例示および説明のみを目的としている。
【００２６】
この方法では、インキング４００は、ノードを通じてインクドキュメント構造５００として表すことができる。例えば、ストロークノード（図に示されていない）は、単語ノード５１０の子であってよい。単語ノード５１０は、行ノード５０８の子であってよく、行ノード５０８は、段落ノード５０６の子であってよい。同様に、段落ノード５０６は、位置揃えレベルノード５０４の子であってよく、位置揃えレベル点５０４は、手書き領域ノード５０２の子であってよい。この方法で、ルートノード５０１は、その子ノードのすべての情報含むことができる。一実施形態では、インキング全体４００は、ルートノード５０１を参照して表すことができる。ドキュメント木構造内のドキュメントの表現がしやすくなる限り任意の個数のノードを任意の種類のドキュメントに関連付けることができる。
【００２７】
２．インクドキュメントのシリアル化
図６は、シリアルバイナリ形式６００でドキュメント構造を内部的に格納するための例示的な一実施形態を表す。インクドキュメント構造が本明細書で参照されているとしても、シリアルバイナリ形式６００を使用して任意の種類の木ドキュメント構造を格納することができる。インクドキュメント構造が生成される場合、ドキュメント構造に関係する１つまたは複数の文字列が存在する。一実施形態では、圧縮は、これらの文字列のＬｅｍｐｅｌ−Ｚｉｖ Ｗｅｌｃｈ形式（「ＬＺＷ形式」）を含む。しかし、文字列は、文字列のサイズを縮小する圧縮形式により圧縮することができると考えられる。図６は、データの記憶装置６０４〜６１８の拡大図を含む（一部のデータは状況に応じて格納される）。一実施形態では、記憶装置は、記憶領域を節約するため符号なし整数を格納しやすくする多バイト符号化（「ＭＢＥ」）値を含む。
【００２８】
シリアルバイナリデータブロック６０２は、インクドキュメントのシリアル化されたバイナリデータを含み、データブロック６０４〜６１８により表される。データブロック６０４〜６１８は、シリアルバイナリデータブロック６０２全体の拡大図を表す。サイズデータ６０４は、シリアルバイナリデータブロック６０２に格納される第１の情報とすることができる。サイズデータ６０４は、インクドキュメント構造のサイズに関連付けられたデータを含む。
【００２９】
インクドキュメントディスクリプタデータ６０６は、サイズデータ６０４に従うことができる。インクドキュメントディスクリプタデータ６０６は、シリアルバイナリデータブロック６０２に含まれるベータの型に関して予想を関連付ける任意の型のデータを含むことができる。この予想は、インクドキュメント構造で使用可能な関連付けられたデータを表すフラグの集合により示すことができる。これらのフラグは、シリアルバイナリデータブロック６０２内で使用可能なデータを示すことができる。データブロック６０４〜６１８は、インクドキュメント構造に関連付けることができるデータの少数の例にすぎない。本発明の一実施形態では、ルートノードデータ６１４（以下でさらに説明する）は、常に、インクドキュメントディスクリプタ６０６内のフラグに関連付けられる。
【００３０】
ダーティ領域（Ｄｉｒｔｙ ｒｅｇｉｏｎ）データ６０８は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。ダーティ領域データ６０８は、保存前に完全には解析されていないインクドキュメント構造内のデータを指す。ダーティ領域データ６０８は、ＴｅｘｔＷｏｒｄ、Ｉｍａｇｅなどのインクデータと非インクデータの両方を指すことができる。ダーティ領域データ６０８は、インクドキュメントディスクリプタデータ６０６に関連付けられたフラグにより示すことができる。インクドキュメントディスクリプタデータ６０６がダーティ領域を示すフラグを含む場合、このフラグは、インクドキュメント構造が有限の、空でないダーティ領域を持つことを示す。ダーティ領域データ６０８が存在する場合、このデータは、ダーティ領域の再作成をしやすくするためバイナリ形式で格納される一連の矩形として表すことができる。インクドキュメントが完全に解析される状況では、ダーティ領域データ６０８は、存在しない場合があり、インクドキュメントディスクリプタ６０６内にフラグを必要としない。一実施形態では、ダーティ領域データ６０８（もし存在すれば）は、インクドキュメントディスクリプタ６０６の直後に来る。
【００３１】
一実施形態では、ダーティ領域データ６０８は、領域データとしてシリアルバイナリデータブロック６０２に格納される。領域データ形式は、ダーティ領域データ６０８、非インク葉文脈ノードに対する位置データ、またはヒントノードに対する位置を格納するために使用することができる。領域データは、領域データのエリア全体を定義する個別の矩形の配列を含むことができる。ストリームから領域データオブジェクト（例えば、ダーティ領域データ６０８）を適切に再構築するために、領域データは矩形のカウントを含むことができる。すべての矩形について、領域データは、上データ、左データ、幅データ、および高さデータに関する情報を含むことができる。矩形データを記述する個々の値は、ＭＢＥまたは符号付き多バイト符号化（「ＳＭＢＥ」）を使用して格納することができる。永続的領域データの表現の一例は以下のとおりである。
【００３２】
【表１】
矩形データは、以下のように表すことができる。
【００３３】
【表２】
【００３４】
グローバル一意識別子（「ＧＵＩＤ」）テーブルデータ６１０は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。ＧＵＩＤテーブルデータ６１０は、ＧＵＩＤテーブルおよび／またはＧＵＩＤ値のリストに関連付けられているＭＢＥ ＧＵＩＤの個数のカウントを含むことができる。ＧＵＩＤ値のリストは、それぞれのＧＵＩＤに対する１６バイト符号なしリテラル値（ｕｎｓｉｇｎｅｄ ｌｉｔｅｒａｌ ｖａｌｕｅ）を含むことができる。インクドキュメント構造またはドキュメント木構造内の個々のノードは、ＧＵＩＤにより識別される任意のデータを含むことができる。この任意のデータは、周知のデータ型および特定のアプリケーションに関連付けられているデータ型を含むことができる。特定のアプリケーションに関連付けられているデータ（つまり、カスタムプロパティデータ）では、データは特定のＧＵＩＤと突き合わせて格納される。ＧＵＩＤテーブルデータ６１０は、演繹的に知られることのないインクドキュメント構造に関して使用されるＧＵＩＤの値を指定する。ＧＵＩＤテーブルデータ６１０は、インクドキュメントレベルまたは文脈ノードレベルで任意のカスタムプロパティデータに対応し、その後、ＭＢＥを介して、ＧＵＩＤテーブルデータ６１０に関するゼロを基点とするインデックスと呼ばれる。例えば、事前定義されていないＧＵＩＤは、アプリケーション特有の拡張ノード型およびノードに関するアプリケーション特有の拡張プロパティを含むことができる。ＧＵＩＤテーブルデータ６１０がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、ドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、ＧＵＩＤテーブルデータ６１０が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的ＧＵＩＤテーブルデータの表現の一例は以下のとおりである。
【００３５】
【表３】
【００３６】
文字列テーブルデータ６１２は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。文字列テーブルデータ６１２は、文字列テーブル内のＭＢＥ文字列の個数のカウント、圧縮された文字列データのサイズ、および／または圧縮された文字列データを含むことができる。文字列テーブルデータ６１２は、解析ヒントサフィックスデータ、プレフィックステキストデータ、擬似事実データ、ヒント名データ、単語リストデータ、カスタムノードリンクデータ、および認識された文字列データに関連付けることができる。本発明の一態様に関して、文字列テーブルデータ６１２は、重複を含むことができる。インクドキュメント構造が特定の順序でロードされる限り、文字列テーブルデータ６１２へのインデックスを保持することで、文字列テーブルデータ６１２から適切な文字列データをロードすることができる。
【００３７】
インデックスは、文字列が文字列テーブルデータ６１２に関連付けられるたび毎に書き込まれるわけではない。このような状況では、１インスタンス当たり少なくとも１バイトが節約される。さらに、文字列テーブルデータ６１２内の文字列はＬＺＷ圧縮とすることができる。ＬＺＷ圧縮と組み合わせてすべての文字列についてインデックスを書かないことにより、文字列のサイズを実質的に縮小することができる。文字列テーブルデータ６１２がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、文字列テーブルデータ６１２が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的文字列テーブルデータの表現の一例は以下のとおりである。
【００３８】
【表４】
【００３９】
ルートノードデータ６１４は、ルートノードのサイズに関係するデータおよび／またはルートノードに関連付けられたデータを含む。ルートノードデータ６１４は、図８に関して説明されているように格納することができる（以下でさらに詳しく説明する）。一態様では、ルートノードデータは、ルートノードデータ６１４が空であってもすべてのインクドキュメント構造と関連する必須データである。インクドキュメントディスクリプタデータ６０６に関連付けられたフラグは、ルートノードデータ６１４の存在を示すことができる。
【００４０】
リンクデータ６１６は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。リンクデータ６１６は、インクドキュメント構造のノードが同じインクドキュメント構造内の他のノードにリンクされているかどうかを示すデータを含む。リンクデータ６１６は、インクドキュメント構造に関連して大域的に保持されるようにできる。リンクデータ６１６を格納するときに、リンクデータ６１６は、インクドキュメント構造に関連付けられたリンクの個数のカウントを含むことができる。個別のリンクデータ６１６はまた、データのＭＢＥサイズも含むことができる。一態様では、ＭＢＥサイズデータの後にリンクディスクリプタが続き、これにより、リンクの型およびリンク元情報（ｏｒｉｇｉｎ ｉｎｆｏｒｍａｔｉｏｎ）を識別する。他の態様では、リンクディスクリプタデータの後に、リンク元ノード（ｓｏｕｒｃｅ ｎｏｄｅ）インデックスのＳＭＢＥ値とリンク先ノード（ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ）インデックスのＳＭＢＥ値が続く。リンク元ノードインデックスおよびリンク先ノードインデックスにより、リンク元ノードおよびリンク先ノードをそれぞれ識別する。さらに他の態様では、リンクデータ６１６がカスタムリンクを含むことをリンクディスクリプタデータが示している場合、グローバル文字列テーブル内のインデックスにより示されたグローバル文字列テーブルからカスタムリンクデータが読み込まれる。リンクデータ６１６がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、リンクデータ６１６が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的リンクデータの表現の一例は以下のとおりである。
【００４１】
【表５】
【００４２】
カスタムプロパティデータ６１８は、すべてのインクドキュメント構造に関連付けられるわけではないオプションデータである。カスタムプロパティデータ６１８は、インクドキュメント構造に関連付けることができ、一態様では、ノードに関連付けられたカスタムプロパティデータとして格納される。カスタムプロパティデータは、アプリケーションがノードと関連付ける任意のデータを含むことができる。カスタムプロパティデータはＧＵＩＤにより識別され、既知または未知のＧＵＩＤを含むことができる。ＧＵＩＤが未知の状況では、ＧＵＩＤはＧＵＩＤテーブルデータ６１０として格納することができる。カスタムプロパティデータ６１８を格納する際に、フラグによりカスタムプロパティデータ６１８を既知の値として識別することができる。他の態様では、カスタムプロパティデータ６１８の格納は、ＧＵＩＤテーブルデータ６１０へのインデックスを含む。カスタムプロパティデータ６１８の記憶装置はまた、データのサイズのＭＢＥ値およびそのデータを表すバイトの配列を含むこともできる。カスタムプロパティデータ６１８がシリアルバイナリデータブロック６０２に関して存在している状況では、その存在は、インクドキュメントディスクリプタデータ６０６に関係するフラグにより識別される。同様に、カスタムプロパティデータ６２０が存在しない場合、インクドキュメントディスクリプタデータ６０６内でフラグはセットされない。永続的インクドキュメント構造の表現の一例は以下のとおりである。
【００４３】
【表６】
【００４４】
図７は、文脈ノードデータ７００を内部に格納するための例示的な一実施形態を表している。一実施形態では、ルートノードデータ６１４は、文脈ノードであり、文脈ノードデータ７００として格納される。文脈ノードデータ７００は、インクドキュメントのシリアル化されたバイナリデータに含まれることができ、データブロック７０４〜７１６により表される。データブロック７０４〜７１６は、文脈ノードデータ７０２の拡大図を表す。
【００４５】
ノードディスクリプタデータ７０４は、インクドキュメント構造のそれぞれのノードに関連付けられているデータを含むことができる。ノードディスクリプタデータ７０４は、ノードデータの構成とともにインクドキュメント構造に関連付けられたノードの種類をも定義するフラグの集合体により示すことができる。
【００４６】
ノードサイズデータ７０６は、特定のノード上に格納される可能な既知のプロパティを含むことができる（例えば、格子データ、境界ボックスデータ、および／またはピンニングフラグデータ）。ノードサイズデータ７０６はまた、位置データ、子下位ノードデータ、およびストロークデータとともに未知のプロパティ（拡張／カスタムプロパティ）を含むこともできる。一態様では、ノードサイズデータ７０６は、ノードディスクリプタデータ７０４の直後に置くことができる。簡潔に述べると、ノードディスクリプタデータ７０４は、文脈ノード木全体のサイズを示すことができる。
【００４７】
ノード位置データ７０８は、すべてのノード型に関連付けられるわけではないオプションデータである。ノード位置データ７０８が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別される。同様に、ノード位置データ７０８が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。一態様では、ノードディスクリプタデータ７０４が非インク葉ノードを示している場合、ノード位置データ７０８が続くことができる。非インク葉ノードは、子ノードを持たない、またストロークデータを含まないノードを含むことができる。例えば、非インク葉ノードは、イメージノード、テキストノード、またはヒントノードを含むことができる。一実施形態では、ノード位置データ７０８は領域データとして格納される。領域データは、領域データのエリア全体を定義する個別の矩形の配列を含むことができる。ストリームから領域データオブジェクト（例えば、ノード位置データ７０８）を適切に再構築するために、領域データは矩形のカウントを含むことができる。すべての矩形について、領域データは、上データ、左データ、幅データ、および高さデータに関する情報を含むことができる。矩形データを記述するこれら個々の値は、ＭＢＥまたはＳＭＢＥを使用して格納することができる。永続的領域データの表現の一例は以下のとおりである。
【００４８】
【表７】
【００４９】
ストロークデータ７１０は、すべてのノード型に関連付けられるわけではないオプションデータである。ストロークデータ７１０は、ストロークデータを含む任意のノードに関連付けられたデータを含むことができる。例えば、ストロークデータ７１０は、非分類インクノード、単語ノード、または描画ノードに関連付けることができる。ストロークデータ７１０が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ストロークデータ７１０が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。
【００５０】
ストロークデータ７１０が存在する場合、記憶装置には、ノードに関連付けられたストロークの数のＭＢＥ値を入れることができる。一態様では、それぞれのストロークは、ストロークディスクリプタフラグの集合体を含む１バイトのストロークディスクリプタに関連付けられる。これらのフラグは、ＭＢＥストローク識別データを示すストローク識別を示すことができる。一態様では、ストローク識別フラグがセットされていない場合、ストローク識別は、取り出された最後のストローク識別を含むことができる。これらのフラグはまた、手書きに関連付けられているストロークの型を識別する手書きストロークディスクリプタフラグも含むことができる。他の態様では、これらのフラグは、描画に関連付けられているストロークの型を識別する描画ストロークディスクリプタフラグを含むことができる。これらのフラグはまた、ハイライトに関連付けられているストロークの型を識別するハイライターディスクリプタフラグも含むことができる。さらに他の実施形態では、これらのフラグは、ストロークの有効な確認済みの祖先を識別する確認済み祖先ディスクリプタフラグを含むことができる。確認済み祖先シリアル化インデックスのＭＢＥ値をストリーム内に格納することができる。さらに他の実施形態では、これらのフラグは、ストロークに関連付けられた言語を識別するストローク言語の識別フラグを含むことができる。言語に対応する符号付き符号化値（ｓｉｇｎｅｄ ｅｎｃｏｄｅｄ ｖａｌｕｅ）は、ストリーム内に格納できる。さらに他の実施形態では、フラグに関連付けられた値は、ストロークディスクリプタデータに応じて上述の順序で格納される。ストロークの識別を容易にする任意の型のフラグをセットできることもさらに考えられる。
【００５１】
子ノードデータ７１２は、すべてのノード型に関連付けられるわけではないオプションデータである。子ノードデータ７１２が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、子ノードデータ７１２が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。子ノードデータ７１２は、コンテナ型ノードを含むことができる（つまり、段落ノード、行ノード、位置揃えノード、手書き領域ノード、および／またはルートノードなど）。コンテナノードは、子ノードを含む任意のノード型を含むことができる。子ノードデータ７１２の記憶装置は、子ノードの個数およびそれぞれの子ノードからのデータを格納することを含む。それぞれの子からのデータは、文脈ノードデータ７０２と同じようにして格納される。
【００５２】
ノード既知プロパティデータ７１４は、すべてのノード型に関連付けられるわけではないオプションデータである。ノード既知プロパティデータ７１４が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ノード既知プロパティデータ７１４が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。
【００５３】
ノード既知プロパティデータ７１４は、データ型および形式が知られており、データサイズを縮小するために最適化を容易にするプロパティを含む。ノード既知プロパティデータ７１４は、回転された境界ボックスデータ（８個の整数の配列）、認識格子データ（可変長を含むバイトの配列）、注釈データ確認データ（整数型）、および／またはヒントデータ（ヒントノード用）を含むことができる。一実施形態では、このデータは、データのバイナリ表現を最適化するために定義済みの方法により格納される。例えば、整数の配列は、符号付き符号化形式で保存することができる。また、構造体またはクラスデータなどの複合データ型は、効率よくデータを定義するバイナリ形式で格納することができる。永続的既知プロパティデータの表現の一例は以下のとおりである。
【００５４】
【表８】
【００５５】
ノードカスタムプロパティデータ７１６は、すべてのノード型に関連付けられるわけではないオプションデータである。ノードカスタムプロパティデータ７１６が存在している状況では、その存在は、ノードディスクリプタデータ７０４に関係するフラグにより識別することができる。同様に、ノードカスタムプロパティデータ７１６が存在しない場合、ノードディスクリプタデータ７０４内でフラグはセットされない。ノードカスタムプロパティデータは、アプリケーションがノードと関連付ける任意のデータを含むことができる。ノードカスタムプロパティデータ７１６はＧＵＩＤにより識別され、既知または未知のＧＵＩＤを含むことができる。ＧＵＩＤが未知の状況では、ＧＵＩＤはＧＵＩＤテーブルデータ６１０として格納することができる。ノードカスタムプロパティデータ７１６を格納する際に、フラグによりノードカスタムプロパティデータ７１６を既知の値として識別することができる。他の態様では、ノードカスタムプロパティデータ７１６を格納することは、ＧＵＩＤテーブルデータ６１０へのインデックスを含む。ノードカスタムプロパティデータ７１６の記憶装置はまた、データのサイズのＭＢＥ値およびそのデータを表すバイトの配列を含むこともできる。永続的文脈ノードデータの表現の一例は以下のとおりである。
【００５６】
【表９】
【００５７】
それぞれのストロークデータブロブ（ｂｌｏｂ）は、以下のようにストリームで表される。
【００５８】
【表１０】
【００５９】
３．シリアル化形式でドキュメント格納するための例示的なプロセス
図８は、インクドキュメントデータをシリアル化バイナリ形式で格納するためのシステムの一般的な実施形態を表している。システム８００は、開始ブロック８０２から始まり、インクドキュメントが生成されるブロック８０４へ流れる。ブロック８０４は、ユーザからのストローク入力を２値化するデジタイザを備えることができる。デジタイザは、コンピューティングデバイス（例えば、図１）、モバイルコンピューティングデバイス（例えば、図２）、本件特許出願人のＷＩＮＤＯＷＳ（登録商標） ＸＰ ＴＡＢＬＥＴ ＥＤＩＴＩＯＮ上で稼働するＴＡＢＬＥＴ ＰＣ、またはインクアプリケーションのオペレーションを容易にする任意のデバイスを含むことができる。さらに、本明細書の説明でインクドキュメントを参照しているとしても、システム８００は、任意の型のデータに関して実装することができる。例えば、本発明は、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、ドローイングアプリケーション、グラフィックスアプリケーション、ノーツアプリケーション、画像アプリケーションなどに関連して使用することもできる。一実施形態では、アプリケーションは、本件特許出願人のＩｎｋＥｄｉｔ、ＩｎｋＰｉｃｔｕｒｅ、および／またはＯｎｅＮｏｔｅを含む。ブロック８０４から、プロセス８００はブロック８０６に流れる。
【００６０】
ブロック８０６は、未処理インクデータを生成するステップを示す。一実施形態では、未処理インクデータを生成することは、デジタイザでストローク入力を未処理インクデータに変換し、未処理インクデータを未処理データ記憶装置に格納することを含む。他の実施形態では、未処理インクデータを生成することは、デジタイザでストローク入力を未処理インクデータに変換し、未処理インクデータをアプリケーションに送信することを含む。次いでプロセス８００は、ブロック８０８に流れる。
【００６１】
ブロック８０８は、インクドキュメント構造を生成するステップを示す。ブロック８０８は、アプリケーションから未処理インクデータを受信するインクアナライザを含むことができる。インクアナライザは、図３に関して上で詳しく説明されているように解析および認識オペレーション用に構成することができる。ブロック８０８は、さらに、図４および５に従って上述のようにインクドキュメント構造を生成することを含むことができる。他の実施形態では、インクドキュメント構造は、インキングに相関する複数のノードを含む。例えば、インクドキュメント構造は、手書き領域ノード、位置揃えノード、段落ノード、行ノード、単語ノード、またはストロークノードを含むことができる。インクドキュメント構造は、さらに、描画ノードおよび／またはヒントノードを含むこともできる。インクドキュメント構造は、インキングの２分木表現を実現しやすくする任意の型のノードを含むことができることが考えられる。他の実施形態では、これらのノードは、関係するノードと相関するリンクに関連付けることができる。
【００６２】
ブロック８１０に流れるときに、インクドキュメント構造は、大域的にアクセス可能なように格納できる。一実施形態では、インクドキュメント構造は、圧縮され、図６および７に関して上で説明されているように格納される。このような場合、インキングは、アプリケーションと連携して生成することができ、その後、他のアプリケーションからアクセス可能なように格納することができる。言い方を変えると、プラットフォームに関連付けられている他のアプリケーションは、インクドキュメント構造および未処理インクを使用して解析されたインクを再生成することができる。このようにアクセス可能であるため、アプリケーション間でカット＆ペーストのオペレーションを容易に実行できる。また、インクは、インクが解析され、認識され、シリアル化形式で保存されている限り、インクドキュメント全体の再解析を行わなくても修正することができる。
【００６３】
４．例示の動作環境
図１を参照すると、本発明を実装する例示的なシステムは、コンピューティングデバイス１００などのコンピューティングデバイスを含む。基本的な構成では、コンピューティングデバイス１００は、少なくとも１つの処理ユニット１０２およびシステムメモリ１０４を備えるのがふつうである。コンピューティングデバイスの正確な構成と種類に応じて、システムメモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこれら２つの何らかの組み合わせとすることができる。システムメモリ１０４は、通常、オペレーティングシステム１０５、１つまたは複数のアプリケーション１０６を含み、またプログラムデータ１０７を含むこともある。一実施形態では、アプリケーション１０６は、さらに、インキングオペレーション用のアプリケーション１２０を含む。基本構成は、図１において点線１０８内のコンポーネントにより示されている。
【００６４】
コンピューティングデバイス１００は、さらに特徴または機能を追加することもできる。例えば、コンピューティングデバイス１００は、磁気ディスク、光ディスク、またはテープなどの追加データ記憶装置デバイス（取り外し可能および／または取り外し不可能）を備えることもできる。このような追加記憶装置は、図１では、取り外し可能記憶装置１０９および取り外し不可能記憶装置１１０により例示されている。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含むことができる。システムメモリ１０４、取り外し可能記憶装置１０９、および取り外し不可能記憶装置１１０は、すべてコンピュータ記憶媒体の例である。コンピュータ記憶媒体としては、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、または所望の情報を格納するために使用することができコンピューティングデバイス１００によりアクセスできるその他の媒体がある。このような任意のコンピュータ記憶媒体を装置１００の一部とすることができる。さらにコンピューティングデバイス１００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの（複数の）入力デバイス１１２を有することもできる。ディスプレイ、スピーカ、プリンタなどの（複数の）出力デバイス１１４を備えることもできる。これらの装置はすべて、当業に周知であるため、本明細書でさらに詳しい説明をする必要はない。
【００６５】
また、コンピューティング装置１００は、デバイスがネットワークまたはワイヤレスメッシュネットワークなどを経由して他のコンピューティングデバイス１１８と通信するために使用する通信接続（群）１１６も含むことができる。通信接続（群）１１６は、通信媒体の一実施例である。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの被変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。「被変調データ信号」という用語は、信号内に情報を符号化するような方法で特性のうちの１つまたは複数が設定または変更された信号を意味する。例えば、限定はしないが、通信媒体としては、有線ネットワークまたは直接配線接続などの有線媒体、および、音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体がある。本明細書で使用されているコンピュータ可読媒体という用語は、記憶媒体と通信媒体の両方を含む。
【００６６】
図２は、本発明の例示的な一実施形態で使用できるモバイルコンピューティングデバイスを示している。図２を参照すると、本発明を実装する例示的なシステムは、モバイルコンピューティングデバイス２００などのモバイルコンピューティングデバイスを含む。モバイルコンピューティングデバイス２００は、プロセッサ２６０、メモリ２６２、ディスプレイ２２８、およびキーパッド２３２を備える。メモリ２６２は、一般に、揮発性メモリ（例えば、ＲＡＭ）と不揮発性メモリ（例えば、ＲＯＭ、フラッシュメモリなど）の両方を含む。モバイルコンピューティングデバイス２００は、メモリ２６２内に常駐し、プロセッサ２６０上で実行される、オペレーティングシステム２６４を格納する。キーパッド２３２は、プッシュボタン式数値ダイヤリングパッド（典型的な電話機などの）、またはマルチキーキーボード（従来のキーボードなど）としてよい。ディスプレイ２２８は、液晶ディスプレイ、またはモバイルコンピューティングデバイスで一般的に使用される他の種類のディスプレイとすることができる。ディスプレイ２２８は、タッチセンシティブとすることができ、その場合、入力デバイスとしても機能する。
【００６７】
１つまたは複数のアプリケーションプログラム２６６がメモリ２６２内にロードされ、オペレーティングシステム２６４上で実行される。アプリケーションプログラムのいくつかの実施例としては、電話ダイヤラープログラム、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどがある。モバイルコンピューティングデバイス２００はまた、メモリ２６２内に不揮発性記憶装置２６８を含む。不揮発性記憶装置２６８は、モバイルコンピューティングデバイス２００の電源が切れた場合に失われてはならない永続的情報を格納するために使用することができる。アプリケーション２６６では、電子メールまたは電子メールアプリケーションにより使用されるその他のメッセージ、ＰＩＭで使用する連絡先情報、スケジューリングプログラムにより使用されるアポイントメント情報、ワードプロセッシングアプリケーションにより使用されるドキュメントなどの情報を使用し、記憶装置２６８内に格納することができる。一実施形態では、アプリケーション２６６は、さらに、インキングオペレーション用のアプリケーション２８０を含む。
【００６８】
モバイルコンピューティングデバイス２００は、１つまたは複数の電池として実装することができる電源２７０を備える。電源２７０は、さらに、ＡＣアダプタまたは電池を補助または充電する電力供給用ドッキングクレードルなどの外部電源を備えることも可能である。
【００６９】
モバイルコンピューティングデバイス２００は、２種類の外部通知メカニズム、ＬＥＤ ２４０とオーディオインターフェイス２７４とともに示されている。これらのデバイスは、作動させたときに、プロセッサ２６０およびその他のコンポーネントが節電のためシャットダウンする可能性があっても通知メカニズムにより指示される継続期間の間オンのままになるように電源２７０に直接結合することができる。ＬＥＤ ２４０は、ユーザがデバイスの電源投入ステータスを示す処置を講じるまでいつまでもオンのままになるようにプログラムすることができる。オーディオインターフェイス２７４は、可聴信号を供給し、ユーザから可聴信号を受信するために使用される。例えば、オーディオインターフェイス２７４をスピーカに結合することで可聴出力を供給し、マイクに結合することで、電話での会話を容易にするためなど、可聴入力を受け取ることができる。
【００７０】
モバイルコンピューティングデバイス２００はまた、無線周波通信など通信を送受信する機能を実行する無線インターフェイス層２７２も含む。無線インターフェイス層２７２を使用すると、通信事業者またはサービスプロバイダを介して、モバイルコンピューティングデバイス２００と外部世界との無線接続性を容易に実現できる。無線インターフェイス相２７２との間の送信は、オペレーティングシステム２６４の制御の下で実行される。つまり、無線インターフェイス層２７２により受信される通信は、オペレーティングシステム２６４を介してアプリケーションプログラム２６６に、またその逆に広めることができる。
【００７１】
上記の詳説、実施例、およびデータは、本発明の構成の製造および使用に関する完全な説明となっている。本発明の多くの実施形態は、本発明の精神と範囲を逸脱することなく実装できるため、本発明は付属の請求項によって定められる。
【図面の簡単な説明】
【００７２】
【図１】本発明の一態様で使用できる例示的なコンピューティングデバイスを示す図である。
【図２】本発明の一態様で使用できる例示的なモバイルデバイスを示す図である。
【図３】インクドキュメントデータをシリアルバイナリ形式で格納するためのシステムの例示的な一態様を示す図である。
【図４】本発明の一態様による例示的なインキングを示す図である。
【図５】図４に表されているインキングの一部を表す例示的なインクドキュメント構造を示す図である。
【図６】本発明のいくつかの態様によるシリアルバイナリデータブロックを格納するためのデータ構造を示す図である。
【図７】本発明のいくつかの態様による文脈ノードデータを格納するためのデータ構造を示す図である。
【図８】インクドキュメント構造をシリアルバイナリ形式で格納するための一般的な態様を示す流れ図である。
【符号の説明】
【００７３】
１００ コンピューティングデバイス
１０４ システムメモリ
１０５ オペレーティングシステム
１０６ アプリケーション
１２０ インク
１０７ プログラムデータ
１０２ 演算処理装置
１０９ 取り外し可能記憶装置
１１０ 固定記憶装置
１１２ 入力デバイス（群）
１１４ 出力デバイス（群）
１１６ 通信接続（群）
１１８ 他のコンピューティングデバイス
２２８ ディスプレイ
２３０ 周辺デバイスポート
２３２ キーパッド
２４０ ＬＥＤ
２６０ プロセッサ
２６２ メモリ
２６４ ＯＳ
２６６ アプリケーション（群）
２６８ 記憶装置
２７０ 電源
２７２ 無線インターフェイス層
２７４ オーディオインターフェイス
２８０ インク
３０２ デジタイザ
３０４ アプリケーション
３０６ インクアナライザ
３０８ 未処理データ記憶装置
５０１ ルート
５０２ 手書き領域
５１２ 描画
５０４ 位置揃えレベル
５０６ 段落
５０８ 行
５１０ 単語
５１４ ヒント
５１５ 単語
６０２ シリアルバイナリデータブロック
６０４ サイズデータ（インクドキュメント全体のサイズ）
６０６ インクドキュメントディスクリプタデータ
６０８ ダーティ領域データ（オプション）
６１０ ＧＵＩＤテーブルデータ（オプション）
６１２ 文字列テーブルデータ（オプション）
６１４ ルートノードデータ
６１６ リンクデータ（オプション）
６１８ カスタムプロパティデータ（オプション）
７０２ 文脈ノードデータ
７０４ ノードディスクリプタデータ
７０６ ノードサイズデータ
７０８ ノード位置データ（オプション）
７１０ ストロークデータ（オプション）
７１２ 子ノードデータ（オプション）
７１４ ノード既知プロパティデータ（オプション）
７１６ ノードカスタムプロパティデータ（オプション）
【特許請求の範囲】
【請求項１】
２分木構造をシリアル化データ形式で格納するためのデータ構造が格納されるコンピュータ可読媒体であって、
ドキュメント構造に関連付けられているサイズデータを格納するための第１のデータフィールドと、
ドキュメントディスクリプタデータを格納する第２のデータフィールドであって、前記ドキュメントディスクリプタデータは、前記ドキュメント構造の関連付けられたデータを示す１つまたは複数のフラグを含む第２のデータフィールドと、
ルートノードデータを格納する第３のデータフィールドであって、前記ルートノードデータは、前記フラグの少なくとも１つにより示される第３のデータフィールドとを備えることを特徴とするコンピュータ可読媒体。
【請求項２】
ダーティ領域データを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記ダーティ領域データの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
前記ダーティ領域データは、インクアナライザにより解析されていないインクデータの位置データおよびインクアナライザにより解析されていない非インクデータの位置データのうちの少なくとも１つを含むことを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項４】
前記ダーティ領域データは、前記ダーティ領域データに関連付けられた矩形のカウント、上データ、左データ、幅データ、および高さデータのうちの少なくとも１つを含むことを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項５】
グローバル一意識別子データを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記グローバル一意識別子データの存在が前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項６】
前記グローバル一意識別子データは、アプリケーション特有のノード型およびアプリケーション特有の拡張プロパティのうちの少なくとも１つを含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
【請求項７】
文字列テーブルデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記文字列テーブルデータの存在が前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項８】
前記文字列テーブルデータは、解析ヒントサフィックスデータ、プレフィックステキストデータ、擬似事実データ、ヒントノードデータ、単語リストデータ、カスタムリンクノードデータ、および認識された文字列データのうちの少なくとも１つに関連付けられることを特徴とする請求項７に記載のコンピュータ可読媒体。
【請求項９】
リンクデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記リンクデータの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１０】
前記リンクデータは、前記ドキュメント構造に関連付けられたリンクのカウント、リンクデータサイズ、リンクディスクリプタ、リンク元ノードインデックスデータ、およびリンク先ノードインデックスデータのうちの少なくとも１つを含むことを特徴とする請求項９に記載のコンピュータ可読媒体。
【請求項１１】
カスタムプロパティデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記カスタムプロパティデータの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１２】
前記カスタムプロパティデータは、サイズデータ、および前記カスタムプロパティデータを表すバイトの配列のうちの少なくとも１つを含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記ルートノードデータは、ディスクリプタデータを含み、前記シリアル化されたデータ内の前記ノードディスクリプタデータの前記存在は、前記ルートノードデータに関連付けられたデータを示す１つまたは複数のフラグを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１４】
前記ルートノードデータは、前記ルートノードデータのサイズを示すサイズデータを示すことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記ルートノードデータは、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１６】
２分木構造をシリアル化データ形式で格納するコンピュータ実装方法であって、
ドキュメント構造サイズデータを第１のデータフィールドに格納すること、
データ予想を示すための少なくとも１つのフラグを含む、ドキュメント構造ディスクリプタデータを第２のデータフィールドに格納すること、および
前記フラグの少なくとも１つにより示されるルートノードデータを第３のデータフィールドに格納することを備えることを特徴とするコンピュータ実装方法。
【請求項１７】
第４のデータフィールドに、ダーティ領域データ、グローバル一意識別子テーブルデータ、文字列テーブルデータ、リンクデータ、およびカスタムプロパティデータのうちの少なくとも１つを格納することをさらに備えることを特徴とする請求項１６に記載のコンピュータ実装方法。
【請求項１８】
ルートノードデータは、予想データ、サイズデータ、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１６に記載のコンピュータ実装方法。
【請求項１９】
コンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記命令は、
少なくとも１つのルートノードを含むインクドキュメント構造を生成すること、
前記インクドキュメント構造をシリアルバイナリデータ形式で格納することであって、前記シリアルバイナリ形式の格納は、
前記インクドキュメント構造に関連付けられたサイズデータを第１のデータフィールドに格納すること、
データ予想を示すため少なくとも１つのフラグを含むインクドキュメント構造ディスクリプタデータを第２のデータフィールドに格納すること、および
前記フラグの少なくとも１つにより示されるルートノードデータを第３のデータフィールドに格納することを含む、シリアルバイナリデータ形式で格納することを備えることを特徴とするコンピュータ可読媒体。
【請求項２０】
ルートノードデータは、予想データ、サイズデータ、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１９に記載のコンピュータ実行可能命令。
【請求項１】
２分木構造をシリアル化データ形式で格納するためのデータ構造が格納されるコンピュータ可読媒体であって、
ドキュメント構造に関連付けられているサイズデータを格納するための第１のデータフィールドと、
ドキュメントディスクリプタデータを格納する第２のデータフィールドであって、前記ドキュメントディスクリプタデータは、前記ドキュメント構造の関連付けられたデータを示す１つまたは複数のフラグを含む第２のデータフィールドと、
ルートノードデータを格納する第３のデータフィールドであって、前記ルートノードデータは、前記フラグの少なくとも１つにより示される第３のデータフィールドとを備えることを特徴とするコンピュータ可読媒体。
【請求項２】
ダーティ領域データを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記ダーティ領域データの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項３】
前記ダーティ領域データは、インクアナライザにより解析されていないインクデータの位置データおよびインクアナライザにより解析されていない非インクデータの位置データのうちの少なくとも１つを含むことを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項４】
前記ダーティ領域データは、前記ダーティ領域データに関連付けられた矩形のカウント、上データ、左データ、幅データ、および高さデータのうちの少なくとも１つを含むことを特徴とする請求項２に記載のコンピュータ可読媒体。
【請求項５】
グローバル一意識別子データを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記グローバル一意識別子データの存在が前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項６】
前記グローバル一意識別子データは、アプリケーション特有のノード型およびアプリケーション特有の拡張プロパティのうちの少なくとも１つを含むことを特徴とする請求項５に記載のコンピュータ可読媒体。
【請求項７】
文字列テーブルデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記文字列テーブルデータの存在が前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項８】
前記文字列テーブルデータは、解析ヒントサフィックスデータ、プレフィックステキストデータ、擬似事実データ、ヒントノードデータ、単語リストデータ、カスタムリンクノードデータ、および認識された文字列データのうちの少なくとも１つに関連付けられることを特徴とする請求項７に記載のコンピュータ可読媒体。
【請求項９】
リンクデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記リンクデータの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１０】
前記リンクデータは、前記ドキュメント構造に関連付けられたリンクのカウント、リンクデータサイズ、リンクディスクリプタ、リンク元ノードインデックスデータ、およびリンク先ノードインデックスデータのうちの少なくとも１つを含むことを特徴とする請求項９に記載のコンピュータ可読媒体。
【請求項１１】
カスタムプロパティデータを格納する第４のデータフィールドをさらに備え、シリアル化されたデータ内の前記カスタムプロパティデータの存在は前記ドキュメントディスクリプタデータに関連付けられた前記フラグのうちの１つにより示されることを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１２】
前記カスタムプロパティデータは、サイズデータ、および前記カスタムプロパティデータを表すバイトの配列のうちの少なくとも１つを含むことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記ルートノードデータは、ディスクリプタデータを含み、前記シリアル化されたデータ内の前記ノードディスクリプタデータの前記存在は、前記ルートノードデータに関連付けられたデータを示す１つまたは複数のフラグを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
【請求項１４】
前記ルートノードデータは、前記ルートノードデータのサイズを示すサイズデータを示すことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記ルートノードデータは、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１６】
２分木構造をシリアル化データ形式で格納するコンピュータ実装方法であって、
ドキュメント構造サイズデータを第１のデータフィールドに格納すること、
データ予想を示すための少なくとも１つのフラグを含む、ドキュメント構造ディスクリプタデータを第２のデータフィールドに格納すること、および
前記フラグの少なくとも１つにより示されるルートノードデータを第３のデータフィールドに格納することを備えることを特徴とするコンピュータ実装方法。
【請求項１７】
第４のデータフィールドに、ダーティ領域データ、グローバル一意識別子テーブルデータ、文字列テーブルデータ、リンクデータ、およびカスタムプロパティデータのうちの少なくとも１つを格納することをさらに備えることを特徴とする請求項１６に記載のコンピュータ実装方法。
【請求項１８】
ルートノードデータは、予想データ、サイズデータ、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１６に記載のコンピュータ実装方法。
【請求項１９】
コンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記命令は、
少なくとも１つのルートノードを含むインクドキュメント構造を生成すること、
前記インクドキュメント構造をシリアルバイナリデータ形式で格納することであって、前記シリアルバイナリ形式の格納は、
前記インクドキュメント構造に関連付けられたサイズデータを第１のデータフィールドに格納すること、
データ予想を示すため少なくとも１つのフラグを含むインクドキュメント構造ディスクリプタデータを第２のデータフィールドに格納すること、および
前記フラグの少なくとも１つにより示されるルートノードデータを第３のデータフィールドに格納することを含む、シリアルバイナリデータ形式で格納することを備えることを特徴とするコンピュータ可読媒体。
【請求項２０】
ルートノードデータは、予想データ、サイズデータ、ノード位置データ、ストロークデータ、子ノードデータ、ノード既知プロパティデータ、およびノードカスタムプロパティデータのうちの少なくとも１つを含むことを特徴とする請求項１９に記載のコンピュータ実行可能命令。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００６−２０２２９７（Ｐ２００６−２０２２９７Ａ）
【公開日】平成１８年８月３日（２００６．８．３）
【国際特許分類】
【出願番号】特願２００６−１４０２９（Ｐ２００６−１４０２９）
【出願日】平成１８年１月２３日（２００６．１．２３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年８月３日（２００６．８．３）
【国際特許分類】
【出願日】平成１８年１月２３日（２００６．１．２３）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]