JP2007265458A - 複数の圧縮オプションを生成する方法およびコンピュータ - Google Patents

Abstract

【課題】小さな表示画面にテキストを表示可能にする。
【解決手段】表示すべきテキスト中の各単語を言語解析し、言語解析に応じて、各単語について複数の圧縮オプションを割り当てる（２３０）。複数の圧縮オプションの１つを選択して（２３２）、選択の圧縮オプションに対応の圧縮形（圧縮の単語）を取得する。
【選択図】図４

Description

本発明は、限られた表示空間を有するデバイス上でのメッセージングに関する。より詳細には、本発明は、テキストをより容易に小さな画面上に表示できるように、言語的にインテリジェントな方式でテキストを圧縮することに関する。

メッセージングは、現在のコンピュータシステム上で広く利用可能である。メッセージは、音声メール、電子メール（ｅメール）、ページングを介して、また、その他のソースまたは手段から送信することができる。さらに、様々なソースからのメッセージを統合して、単一のデバイスに転送することもできる。例えば、コンピュータまたはコンピュータネットワークにおいて、目下、音声メールおよび電子メールを介してメッセージを受信しているユーザが、このようなメッセージを受信する能力を備えたセルラーホンにこれらのメッセージを転送することもできる。しかし、セルラーホンの画面は、著しく限られた表示空間である。このことは、メッセージを表示しようとする際に非常に大きな問題を提示する可能性がある。

例えば、ごく短い電子メールメッセージまたは文字化された音声メールメッセージであっても、セルラーホンの単一画面上で見るには大きすぎるテキストを提示する可能性がある。これにより、ユーザはしばしば、メッセージの最初のわずかな単語から（それが表示できるすべてなので）メッセージ全体を解読するか、メッセージ全体を見るためにテキストの多くの行を下にスクロールする必要がある。これらの手法は双方とも煩わしく、エラーを引き起こす可能性がある。

テキスト圧縮は、従来、様々な多くのコンテキストで用いられてきたが、このような圧縮の目的は、主にテキストを効率的にデータ記憶できるようにすることであった。このような圧縮技法は、圧縮テキストを人間が解読しなければならないコンテキストには全く適用不可能である。

このような目的を達成するために、請求項１の発明は、コンピュータにおいて、テキスト本文を処理して複数の圧縮オプションを生成する方法において、前記コンピュータは、
前記テキスト本文について言語解析を実行し、前記テキスト本文の中の、単語および数字の１つを有する複数のトークンを取得する手段と、前記言語解析の実行の後、前記テキスト本文を圧縮するために、前記テキスト本文の中の複数の対応の異なるトークンの各々について複数の正しい圧縮オプションを自動的に生成して前記テキスト本文を圧縮するための手段であって、そこでは、前記正しい複数の圧縮オプションの各々は、異なる、前記テキスト本分の中の対応のトークンの正しい圧縮形を有し、前記対応のトークンの中の文字列または数字列の個数を少なくとも減らし、前記圧縮形には前記対応の複数のトークンの中のいくつかの、すべてではない文字列を含む手段と、前記テキスト本文の中の異なる複数のトークンの各々についての複数の圧縮オプションの１つを選択し、各トークンについて選択の圧縮のオプションに従って前記テキスト本文の圧縮形を出力する手段として動作することを特徴とする。

請求項２の発明は、メッセージを受け取り、メッセージの中のテキスト本文の一部分の異なる形態を示す複数の圧縮オプションを生成するコンピュータにおいて、言語学的に前記テキスト本文を解析して、前記テキスト本文の中の個々のトークンを葉ノードで示す言語学的解析を提供する手段と、少なくとも前記言語学的解析の中の葉ノードで表される複数のトークンについての複数の異なる圧縮形を提供する手段であって、前記複数の異なる圧縮形は、各々が対応の個々のトークンの正しい圧縮形を示す圧縮形生成手段と、前記テキスト本文の中の個々のトークンについての異なる複数の圧縮形の中の選択を示す出力を生成する圧縮手段とを備えたことを特徴とする。

請求項３の発明は、テキスト本文を圧縮するためのコンピュータにおいて、圧縮のタイプとして、単語の消去する、単語を置換するおよび単語そのものを使用するタイプが単語の言語学的特徴に対応して予め定められており、前記テキスト本文中の各単語の特徴を言語学的に解析する解析手段であって、前記言語学的の解析により得られる言語学的特徴は、単語に付加される属性の形態で表される解析手段と、前記属性に従って前記テキスト本文中の各単語を圧縮する圧縮手段とを備えたことを特徴とする。

請求項４の発明は、前記テキスト本文は、複数の単語を複数のノードとして表される１つのツリーの形態で表され、前記解析手段は前記ツリー上の各単語を検索して単語を言語学的に解析することを特徴とする。

図１に、本発明を実施できる、適したコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適したコンピューティング環境の一例でしかなく、本発明の使用または機能の範囲に関していかなる限定も示すものではない。コンピューティング環境１００はまた、例示的な動作環境１００中に示したコンポーネントのいずれか１つまたはそれらの組合せに関してどんな依存も要件も有しないと解釈すべきである。

本発明は、その他の様々な汎用または専用コンピューティングシステム環境または構成でも動作する。本発明と共に使用するのに適した、知られているコンピューティングシステム、環境、および／または構成としては、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが挙げられるが、これらに限定しない。

本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストで述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含めたローカルとリモートの双方のコンピュータ記憶媒体中に位置することができる。

図１を参照すると、本発明を実施するための例示的なシステムが、コンピュータ１１０の形をとる汎用コンピューティングデバイスを含んでいる。コンピュータ１１０のコンポーネントとしては、プロセッシングユニット１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントをプロセッシングユニット１２０に結合するシステムバス１２１とを挙げることができるが、これらに限定しない。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いたメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含めた、いくつかのタイプのバス構造のいずれでもよい。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。

コンピュータ１１は通常、様々なコンピュータ可読媒体を備える。コンピュータ可読媒体は、コンピュータ１１０がアクセスできる任意の利用可能な媒体とすることができ、揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不可能媒体の双方が含まれる。限定ではなく、例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他データを含めた情報を記憶するための任意の方法または技術で実装された揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不可能媒体の双方が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）またはその他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用できコンピュータ１００がアクセスできるその他の媒体が含まれるが、これらに限定しない。通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを、搬送ＷＡＶまたはその他のトランスポートメカニズムなどの変調されたデータ信号中に組み入れており、任意の情報送達媒体が含まれる。「変調されたデータ信号」という用語は、情報を信号にエンコードするようにその１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、ワイヤードネットワークまたは直接ワイヤードネットワーク接続などのワイヤード媒体と、音響、ＦＲ、赤外線などのワイヤレス媒体およびその他のワイヤレス媒体が含まれる。以上のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含めるべきである。

システムメモリ１３０は、読出し専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形をとるコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動時などにコンピュータ１１０内の要素間で情報を転送することを支援するＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）１３３が記憶されている。ＲＡＭ１３２は通常、プロセッシングユニット１２０からすぐにアクセス可能であってプロセッシングユニット１２０が現在作用しているデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７が示されている。

コンピュータ１１０はまた、その他の取外し可能／取外し不可能、かつ揮発性／不揮発性のコンピュータ記憶媒体を備えることもできる。例示にすぎないが、図１には、取外し不可能かつ不揮発性の磁気媒体に対して読取りまたは書込みを行うハードディスクドライブ１４１と、取外し可能かつ不揮発性の磁気ディスク１５２に対して読取りまたは書込みを行う磁気ディスクドライブ１５１と、ＣＤ ＲＯＭやその他の光学媒体など取外し可能かつ不揮発性の光学ディスク１５６に対して読取りまたは書込みを行う光学ディスクドライブ１５５が示されている。この例示的な動作環境で使用できるその他の取外し可能／取外し不可能、かつ揮発性／不揮発性のコンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれるが、これらに限定しない。ハードディスクドライブ１４１は通常、インタフェース１４０などの取外し不可能メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は通常、インタフェース１５０などの取外し可能メモリインタフェースによってシステムバス１２１に接続される。

以上に論じ、図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶域をコンピュータ１１０に提供する。例えば図１では、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶しているものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、およびプログラムデータ１３７と同じものとすることも異なるものとすることもできることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７は、これらが少なくとも異なるコピーであることを示すために、ここでは異なる番号を付けてある。

ユーザは、キーボード１６２、マイクロホン１６３、およびマウスやトラックボールやタッチパッドなどのポインティングデバイス１６１など、入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）には、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナなどを含めることができる。これらおよびその他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース１６０を介してプロセッシングユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造によって接続することもできる。モニタ１９１または他のタイプの表示デバイスもまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７やプリンタ１９６など他の周辺出力デバイスを備えることもでき、これらは出力周辺インタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など1つまたは複数のリモートコンピュータへの論理接続を用いてネットワーク化された環境で動作することもできる。リモートコンピュータ１８０は、パーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常、コンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続はローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーク化環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでよくみられるものである。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２またはその他の手段を備える。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インタフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示すプログラムモジュールまたはその一部をリモートメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がリモートコンピュータ１８０上にあるものとして示してある。図示のネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立するための他の手段を使用することもできることを理解されたい。

図１に関して述べたようなコンピュータシステム上で本発明を実施できることに留意されたい。ただし、本発明は、サーバメッセージ処理専用のコンピュータ、または分散システム上で実施することもでき、分散システムの場合は、本発明の異なる各部分を分散処理システムの異なる各部分で実施する。

図２は、本発明を実施するのに使用できるいくつかのコンポーネントの例示的な一実施形態のブロック図である。図２は、メッセージハンドラ２００、コンプレッサ２０２、およびターゲットデバイス２０５を含む。メッセージハンドラ２００は、例示的にメッセージパーサ２０４、言語アナライザ２０６、およびテキスト圧縮コンポーネント２０８を含む。例示的な一実施形態では、ターゲットデバイス２０５はセルラーホンまたは画面の小さい他のデバイスであり、リンク２１０を介してコンプレッサ２０２に接続される。リンク２１０は、無線伝送部分を含んでも含んでいなくてもよいグローバルコンピュータネットワーク、または、ターゲットデバイス２０５にメッセージを送信するのに適した他の任意のリンクとすることができる。

メッセージハンドラ２００は、例示的にメッセージ２１２を受け取る。メッセージ２１２は、ページングシステム、電子メール、音声メールなどを含めた種々のソースのうちの１つからくるものとすることができる。したがって、メッセージ２１２は例示的に、ヘッダ、テキスト本文、および電子メールの場合は電子メールスレッド中の以前のメッセージを含めた、種々の部分を含む。パーサ２０４は、メッセージ２１２をその種々の部分に解析する。パーサ２０４の動作は本発明に関係しない。関係するのは、圧縮すべきメッセージ本文２１４またはその他のテキスト本文を識別してアナライザ２０６に提供することだけである。これは周知のどんな方法で行ってもよく、本発明の一部を形成しない。したがって、パーサ２０４については詳述しない。パーサ２０４はヘッダ情報および場合によっては以前のメールメッセージを除去し、メッセージ本文２１４を言語アナライザ２０６に提供することができると言えば十分であろう。

当然、パーサ２０４は、メッセージ本文２１４以外にも、他の任意の自然言語テキスト本文をアナライザ２０６に提供することができることに留意されたい。例えば、テキスト本文は、サブジェクトヘッダ、タスク記述ヘッダ、ウェブページなどとすることもできる。ここでは、分析すべきテキストのほんの一例として、メッセージ本文２１４に関して考察を進める。

言語アナライザ２０６は例示的に、語彙アナライザ、形態アナライザ、および構文アナライザを含む。語彙アナライザは、メッセージ本文２１４を受け取り、それを単語（またはその他のトークン）に分割する。これは周知の方式で行う。形態アナライザは、形態データベース（辞書など）にアクセスし、意味や品詞など、各ワード（またはトークン）に関連する様々な情報を得る。構文アナライザは、メッセージ本文２１４の構文分析を行って、メッセージ本文中の各文ごとに構文解析ツリー（または構文分析構造）を獲得し、この構造を言語アナライザ２０６の出力として出力する。これもまた周知の方式で行い、図３に関して簡単に示されている。

テキスト圧縮コンポーネント２０８は、言語アナライザ２０６からの言語分析出力にアクセスし、メッセージ本文２１４の構成要素について異なる複数の任意選択の圧縮を生成する。例示的な一実施形態では、テキスト圧縮コンポーネント２０８は、メッセージ本文２１４中の各単語または句ごとに５つの属性を提供する。一般に、各属性は、分析中の各単語をより大胆に圧縮したものを表す。例示的な一実施形態では、テキスト圧縮コンポーネント２０８から出力されるデータ構造は、以下の属性を含む。

ＳｈｏｒｔＴｙｐｅ 適用される圧縮規則のタイプの１つを示す。
ＬｏｎｇＦｏｒｍ メッセージ本文２１４に書かれている単語の形である。
ＳｈｏｒｔＦｏｒｍ ＳｈｏｒｔＴｙｐｅ属性によって識別される圧縮規則または技法を適用した後の単語の形である。
ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ ＳｈｏｒｔＦｏｒｍの第１文字を大文字にして、残りの文字を小文字にする。
ＣｏｍｐｒｅｓｓｅｄＦｏｒｍ ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍの圧縮形であり、単語をさらに圧縮するためにＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍに追加の圧縮規則を施す。

例示的な一実施形態では、これらの属性を含むデータ構造が、圧縮ＸＭＬ出力２１６として出力され、コンプレッサコンポーネント２０２に提供される。コンプレッサコンポーネント２０２は、例示的に、圧縮出力２１６中の圧縮形のうちの１つを選択し、それをターゲットデバイス２０５に提供する。コンプレッサコンポーネント２０２は、例示的に、ターゲットデバイス２０５上で利用可能な画面空間または他の基準に基づいて圧縮形を選択することができる。コンプレッサコンポーネント２０２は本発明の一部を形成しないことに留意されたい。

図３は、メッセージ本文２１４中に入れることのできる文の例示的な一実施形態である。この文は、「Ｙｏｕ ｈａｖｅ ａ ｍｅｅｔｉｎｇ ｗｉｔｈ Ｄｒ．Ｊｏｈｎ Ｅｐｓｔｅｉｎ ｎｅｘｔ Ｔｕｅｓｄａｙ ａｔ ｔｅｎ ａ．ｍ．（あなたは次の火曜日の午前１０時にＪｏｈｎ Ｅｐｓｔｅｉｎ先生と面会する）」と書いてある。当然、メッセージ本文２１４は語彙アナライザに提供され、語彙アナライザは、メッセージ本文を文および個々の単語（またはトークン）に分割する。次いで形態アナライザが、各単語（またはトークン）のルックアップを行い、分析のために望まれる品詞（会話部分）およびその他の可能な情報を識別する。したがって、以下の品詞によって単語が識別されることがわかる。

ｙｏｕ＝代名詞
ｈａｖｅ＝動詞
ａ＝冠詞
ｍｅｅｔｉｎｇ＝名詞
ｗｉｔｈ＝前置詞
Ｄｒ．Ｊｏｈｎ Ｅｐｓｔｅｉｎ＝固有名詞
ｎｅｘｔ＝形容詞
Ｔｕｅｓｄａｙ＝名詞
ａｔ＝前置詞
ｔｅｎ ａ．ｍ．＝名詞

構文アナライザは、文および品詞を、例示的な一実施形態では図３に示すような構文解析ツリーに分析する。構文解析ツリー中の末端ノード（または葉ノード）は、文中の単語を表し、末端以外のノードは、文の各部分を識別する句またはその他の上位レベルの構文単位を表す。図３に示す構文解析ツリー中では、指標「Ｓ」は文ノードを表し、指標「ＮＰ」は名詞句を表し、「ＶＰ」は動詞句を表し、「ＰＰ」は前置詞句を表す。「ｎｅｘｔ Ｔｕｅｓｄａｙ」および「ａｔ ｔｅｎ ａ．ｍ．」の上にある三角形は、単に、これらの句をさらにノードに分析できるが簡単にするために省略されていることを示す。この構文解析ツリーは、この文が、名詞句およびそれに続く動詞句、およびそれに続く他の２つの構文構成要素（ここでは具体的に分析されていない）で形成されていることを示す。

テキスト圧縮コンポーネント２０８は、例示的に図３に示す文を、人間に解読できるように言語的にインテリジェントな方式で圧縮する。このような圧縮を行う際、いくつかの問題が生じる。例えば、テキスト中のあるタイプの単語をすべて削除することが直感的なこともある。例えば、テキスト中のすべての冠詞を削除することが直感的なこともる。しかしこれは、英語ではうまくいく場合もあるが、他の言語ではうまくいかない。実際、これはすべてのロマンス諸語でさえ機能しない。例えば、「Ｉ ｍａｄｅ ｈｉｍ ｅａｔ ｉｔ（私は彼がそれを食べるようにした）」と翻訳されるフランス語の句Ｊｅ ｌｅ ｌｕｉ ａｉｆａｉｔ ｍａｎｇｅｒを考えてみる。接語代名詞「ｌｅ」は、ちょうど男性不定冠詞「ｌｅ」（「ｔｈｅ」と翻訳される）のように見えることに留意されたい。したがって、すべての「冠詞」または単語「ｔｈｅ」、および異なる言語におけるそれらの等価物が除去された場合、それにより、異なる言語のいくつかの句の意味が劇的に変化することになる。

同様に、テキスト中のすべてのスペースを除去することが直感的に妥当と思われることもある。しかし、メッセージ中に電子メールエイリアスまたはユニフォームリソースロケータ（ＵＲＬ）が設けられている場合、スペースを除去すると、電子メールエイリアスまたはＵＲＬがテキスト中のどこにあるか判別するのが非常に困難になる。今日、記号に影響されやすいこのような多くのテキストフラグメントが、メッセージ中で使用されている。フラグメント中の記号が変更される場合、フラグメント全体の意味は回復できないほどに失われる。例えば、句「Ｖｉｓｉｔ ｈｔｔｐ：／／ｍｉｃｒｏｓｏｆｔ．ｃｏｍ ｆｏｒ ｉｎｆｏｒｍａｔｉｏｎ」を考えてみる。これが「ｖｉｓｉｔｈｔｔｐ：／／ｍｉｃｒｏｓｏｆｔ．ｃｏｍｆｏｒｉｎｆｏ」に短縮されると、テキストフラグメント中のどこでＵＲＬが終わるのかを決定するのが非常に困難である。

したがって本発明は、このようなインテリジェントでない一様な手法をとらない。本発明の圧縮は、そうではなく、アナライザ２０６によって行われる言語分析に基づいている。

図４は、メッセージハンドラ２００の動作をもう少し詳細に示したフローチャートである。最初に、メッセージハンドラ２００はメッセージ２１２を受け取る。これをブロック２１８で示す。パーサ２０４が、メッセージ２１２中のメッセージ本文を突き止め、メッセージ本文２１４をアナライザ２０６に渡す。これをブロック２２０で示す。アナライザ２２６は、メッセージ２１４を文に分割する。これをブロック２２２で示す。次いで、アナライザ２０６の語彙アナライザコンポーネントが、テキスト本文の語彙分析を行い、文を単語、数字、および句読記号などのトークンに分割する。トークンはまた、「ａｌｏｎｇ ｗｉｔｈ」や「ｂｙ ｍｅａｎｓ ｏｆ」のような複数単語の表現など、２つ以上の単語からなるものとすることもできる。これをブロック２２４で示す。次いで、言語アナライザ２０６中の形態アナライザが形態分析を行い、したがって、各トークンに対応する品詞およびその他の関連情報を突き止める。これをブロック２２６で示す。次いで、構文アナライザが構文分析を行い、例示的な一実施形態では構文解析ツリーを提供する。これをブロック２２８で示す。

次いで、テキスト圧縮コンポーネント２０８が、アナライザ２０６から提供された分析の中の各ノードを再帰的に調べ、可能性ある圧縮オプションが利用可能かどうかを判定する。これをブロック２３０で示す。分析の中のノードを調べ終わり、様々な圧縮オプションを識別すると、例えばＸＭＬ出力２１６として圧縮オプションを出力する。これをブロック２３２で示す。次いで、コンプレッサ２０２が、単純に各単語（またはトークン）ごとにオプションのうちの１つを選択し、メッセージを圧縮形でターゲットデバイス２０５に提供する。

図５および図６に、分析されたメッセージ本文２１４の各部分に対して可能性ある圧縮オプションを生成する際のテキスト圧縮オプション２０８の動作をより詳細に示す。図５および図６は、アナライザ２０６からの分析出力の中の末端ノード（または葉ノード）に対する可能性ある圧縮オプションを生成する際のテキスト圧縮コンポーネント２０８の動作を具体的に示している。言い換えれば、図５および図６には、メッセージ本文の句またはより大きなフラグメントを表す場合のある末端以外のノードとは対照的に、可能性ある圧縮のためのテキストメッセージ中の各ワード（またはトークン）の処理が示してある。

最初に、長い形の各トークンを受け取る。長い形は、テキスト本文に書かれたトークンの形であることを想起されたい。これを図５のブロック２３４で示す。この長い形を、圧縮出力２１６として提供されたデータ構造中に出力される属性として保存する。これをブロック２３６で示す。

次に、ＳｈｏｒｔＴｙｐｅ属性を決定して保存する。ＳｈｏｒｔＴｙｐｅ属性は、長い形のトークンに適用される圧縮規則の具体的なタイプを示す属性であることを想起されたい。これをブロック２３８で示す。以下に、本発明の一実施形態による様々なＳｈｏｒｔＴｙｐｅ属性をより広く論じる。

次いで、ＳｈｏｒｔＴｙｐｅ属性によって識別される圧縮規則を用いて分析中のノード全体を削除すべきかどうかを決定する。例えば、いくつかのノードは、あらゆる状況で削除することになる。英語の冠詞（ＳｈｏｒｔＴｙｐｅ属性「Ａｒｔｉｃｌｅｓ」を有する）は、常に省略することができる。このような冠詞には、例えばａ、ｔｈｅ、ｔｈｏｓｅ、およびｔｈｅｓｅが含まれる。挨拶は、ＳｈｏｒｔＴｙｐｅ属性「Ｇｒｅｅｔｉｎｇ」を有し、これらもまたブロック２４０で特別処理する。挨拶（Ｄｅａｒ Ｂｏｂ、Ｈｉ、Ｈｉ Ｂｏｂなど）は、すべて削除することができる。ノードをあらゆる状況で削除すべきかどうか決定することを、ブロック２４０で示す。そうである場合は、ブロック２３８に示すように、ＳｈｏｒｔＴｙｐｅ属性を「Ａｒｔｉｃｌｅｓ」（または適切な属性なら何でも）に設定し、ＳｈｏｒｔＦｏｒｍ、ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ、およびＣｏｍｐｒｅｓｓｅｄＦｏｒｍの属性をすべてヌルの値に設定する。これをブロック２４２に示す。

ブロック２４０で、ノードを完全に削除すべきではないと決定した場合は、その他の特別処理をこのノードに対して行うべきかどうかを決定する。これをブロック２４４で示す。このような特別処理は、様々な形で行われる可能性がある。次に、これらの形のいくつかについて論じる。

形容詞のグループ（ＳｈｏｒｔＴｙｐｅ「Ａｄｊｅｃｔｉｖｅ」を有する）は、特別処理される。これらには、ｗｈｉｃｈ、ｗｈｏ、ｗｈａｔなど、「ｗｈ」で始まる単語が含まれる。これらの形容詞について、以下により詳細に論じる。

英語の冠詞については、ブロック２４０に関して先に論じた。英語の冠詞は、あらゆる状況で省略することができる。しかし、他の言語の冠詞は特別処理が必要な場合がある。例えば、ドイツ語の定冠詞は、あらゆる状況で省略することができる。しかし、不定冠詞は、あいまいなので保留される（同じ形が「ａ」または「ｏｎｅ」の意味になり得るため）。スペイン語およびフランス語の定冠詞は削除されるが、同じ綴りの接語代名詞は削除されない。スペイン語およびフランス語の不定冠詞は、あいまいなので保留される（同じ形が「ａ」または「ｏｎｅ」の意味になり得るため）。

副詞は、ＳｈｏｒｔＴｙｐｅ属性「Ａｄｖｅｒｂｓ」を有し、「ｗｈ」単語として分類されるもの（ｗｈｙ、ｈｏｗ、ｗｈｅｎなど）は、どんな仕方でも圧縮されない。これらについては後で論じる。その他の副詞は、文字削減（母音削除、子音削除、またはその双方）がなされるが、これもまた後でより詳細に論じる。

社名は、ＳｈｏｒｔＴｙｐｅ「Ｃｏｍｐａｎｙ」を有し、これらもまた特別処理される。社名タイプは削除される。例えば、「Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ」は、単に「Ｍｉｃｒｏｓｏｆｔ」に変換することができる。短縮された形は、後で論じるように文字削減および大文字／小文字標準化を受ける。

接続詞は、ＳｈｏｒｔＴｙｐｅ属性「Ｃｏｎｊ」を有し、これらもまた特別処理される。例えば、英語の接続詞「ａｎｄ」、フランス語の「ｅｔ」、およびドイツ語の「ｕｎｄ」には、アンパサンド符号が取って代わる。スペイン語の「ｙ／ｅ」は、すでに１語なので短縮されない。その他の接続詞はすべてそのままであり、後の処理ステップを受ける。

いくつかの様々なタイプの名詞もまた、特別処理される。絶対的な日付および時間は、ＳｈｏｒｔＴｙｐｅ「Ｄａｔｅｓ」で指定され、以下のようにして処理される。あらゆる言語において、単独で月がある場合、長い月名は短い形（ｓｈｏｒｔ ｆｏｒｍ）に変換される。最後にピリオドの付いた短い月名では、ピリオドは除去される。得られる短い形には、母音圧縮や大文字／小文字標準化などは行われない。例えば、「ｌｅｔｓ ｍｅｅｔ ｉｎ Ｎｏｖｅｍｂｅｒ（１１月に会いましょう）」という句では、Ｎｏｖｅｍｂｅｒは「Ｎｏｖ」に短縮される。同様に、「ｌｅｔｓ ｍｅｅｔ ｉｎ Ｎｏｖ．」という句では、Ｎｏｖｅｍｂｅｒの省略形が「Ｎｏｖ」に変換される（すなわち後に付くピリオドが取り去られる）。

あらゆる言語において、日の指定がない月（および年）は、短い月名だけとする。例えば、「２００１」が現在の年である場合に、語「Ｎｏｖｅｍｂｅｒ ２００１」は単に「Ｎｏｖ」に短縮される。

日付が、月と現在の年でない年とである場合は、数字の月および分離符号および数字の年に変換される。例えば、「Ｎｏｖ ２００２」は、「１１／２００２」（英語およびフランス語の場合）、または「１１．２００２」（他のヨーロッパ言語の場合）に変換される。

同様に、アメリカ英語では、単一の絶対的な日付は、月／日／年の数字フォーマットに標準化される。他の言語の日付は、それらのフォーマットに標準化される（例えば日本語では常に、年−月−日のフォーマットが使用される）。英語およびフランス語ではフォワードスラッシュマークが分離符号として使用されるが、スペイン語およびドイツ語ではピリオドが分離符号として使用される。

年は、「今日」の年と等しい場合、または年に２０００を足した数が「今日」の年と等しい場合は省略される。例えば、２３ Ｊｕｌｙ，２００１は７／２３に変換される。さらに、Ｍｏｎｄａｙ ２３ Ｊｕｌｙも７／２３に変換される。

同様に、ｍｉｄｎｉｇｈｔ（真夜中）もまた特別処理を受ける。ｍｉｄｎｉｇｈｔもまた、ＳｈｏｒｔＴｙｐｅ「Ｄａｔｅｓ」で指定され、この短い形は「１２ａｍ」である。よくある連語「１２ ｍｉｄｎｉｇｈｔ」もまた、短い形「１２ａｍ」を有するが、これは出力「１２ １２ａｍ」を回避するための特別な場合である。

英語の日付範囲もまた、特別処理を受ける。例えば、語「Ｄｅｃｅｍｂｅｒ ５ｔｈ−９ｔｈ」は、「１２／５−９」に変換される。また、日付範囲「Ｄｅｃｅｍｂｅｒ ５ｔｈ−９ｔｈ，２００２」は「１２／５−９／２００２」に変換される。

オフセット日付もまた特別処理され、これらにはＳｈｏｒｔＴｙｐｅ「ＯｆｆｓｅｔＤａｔｅ」が与えられる。「ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ」などの語がテキスト中で識別された場合は、そのメッセージが送信された（または書かれた）日付が取得され、オフセット日付「ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ」が変形される。したがって、メッセージが１２月１日の金曜日に送信された場合、「ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ」が言及するのは１２月６日ということになる。したがって、語「ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ」は「１２／６」に変換される。

曜日には、ＳｈｏｒｔＴｙｐｅ「Ｄａｙｓ」が与えられる。あらゆる言語で、絶対的な日付に確実に変換できない独立した曜日は、それらの曜日の短い形に変形される。最後にピリオドの付いた短い曜日名は、ピリオドが取り去られる。得られる短い形には、母音圧縮や大文字／小文字標準化などは行われない。例えば、「ｌｅｔｓ ｍｅｅｔ ｏｎ Ｍｏｎｄａｙ（月曜日に会いましょう）」という句では、語「Ｍｏｎｄａｙ」は「Ｍｏｎ」に変換される。

電子メールエイリアスおよびＵＲＬもまた、特別処理を受ける。電子メールエイリアスおよびＵＲＬは、大文字／小文字標準化も母音除去もされずにそのまま維持される。電子メールには、ＳｈｏｒｔＴｙｐｅ「Ｅｍａｉｌ」が与えられ、ＵＲＬにはＳｈｏｒｔＴｙｐｅ「ＵＲＬ」が与えられる。

電話番号には、ＳｈｏｒｔＴｙｐｅ「Ｐｈｏｎｅ」が与えられ、これらの中から句読点が除去される。例えば、語「ｃａｌｌ ｍｅ ａｔ（４２５）７０３−７３７１（（４２５）７０３−７３７１にかけて私に電話をください）」の中の電話番号は、単に「４２５７０３７３７１」に変換される。

州および国には、ＳｈｏｒｔＴｙｐｅ「Ｇｅｏ」が与えられ、これらには従来の省略形が取って代わる。例えば、「Ｗａｓｈｉｎｇｔｏｎ」には「ＷＡ」が取って代わり、「Ａｌａｂａｍａ」には「ＡＬ」が取って代わり、その他同様となる。

言語でないものには、ＳｈｏｒｔＴｙｐｅ「ＮｏｔＬａｎｇｕａｇｅ」が与えられ、言語圧縮は行われない。このようなものの例には、以下のものが挙げられる。

ｘ＝ｘ＋ｙ；
Ｉｆ（ｘ＝１）｛
＜Ｓｏｍｅ ＸＭＬ＞Ｃｏｎｔｅｎｔ＜／Ｓｏｍｅ ＸＭＬ＞＜Ｆｏｏ／＞．

綴り字の数字もまた特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「Ｎｕｍｂｅｒ」が与えられる。綴り字の数字には、アラビア数字が取って代わる。例えば、英語の句「ｏｎｅ ｔｈｏｕｓａｎｄ ｆｏｕｒ ｈｕｎｄｒｅｄ ｔｗｅｎｔｙ−ｆｉｖｅ」には、「１４２５」が取って代わる。例示的に、千の位の間に分離符号は使用されていない。

貨幣の単位名もまた特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「Ｄｏｌｌａｒｓ」が与えられる。千は語「Ｋ」で置換される。１００万は語「Ｍ」で置換され、１０億は「Ｂ」で置換される。例えば、＄１０００００は＄１００Ｋに、＄１２３００００００は＄１２３Ｍに、＄２０００００００００は＄２Ｂに変換される。また、これらの短い形は、後で述べる大文字／小文字標準化を受けない。

同様に、例示的な一実施形態では少数も示される。例えば、＄２２５０００００００は＄２．２５Ｂに変換される。また、通貨指示詞が後に続く数量は、数と共に、その通貨に対する一般的な記号に標準化される。例えば、「ｏｎｅ ｈｕｎｄｒｅｄ ｄｏｌｌａｒｓ」は「＄１００」に変換される。語「５７ｐｏｕｎｄｓ」は「＃５７」に変換される。「５００Ｆｒａｎｃｓ」は「５００Ｆｒ」に変換され、その他同様となる。

固有名詞は特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「ＰｒｐｒＮ」が与えられる。ドイツ語以外の言語では、複数の部分からなる固有名詞は、可能なら単に第１の姓に凝縮される。例えば、「Ｄｒ．Ｍａｒｙ Ｓｍｉｔｈ」は「Ｓｍｉｔｈ」に変換される。

スペイン語の、句からなる姓の場合は、第１の部分に凝縮されることに留意されたい（例えば「Ｃａｒｄｏｓｏ ｄｅ Ｃａｍｐｏｓ」は「Ｃａｒｄｏｓｏ」に短縮される）。例示的な一実施形態では、固有名詞にも母音除去は行われない。

同様に、固有名詞は、より一般的な名前があるかどうか辞書ルックアップを受ける。例えば、固有名詞「Ｐａｔｒｉｃｋ」には「Ｐａｔ」が取って代わることができる。名前「Ｗｉｌｌｉａｍ」には「Ｗｉｌｌ」が取って代わることができ、その他同様である。さらに、名前および最後の頭文字がある場合は、単に名前だけに短縮される。

ドイツ語では、テキストフラグメント中の多くの単語が大文字になるので、この言語では固有名詞はより厄介である。したがってドイツ語では、固有名詞は、限定詞が前にある場合は圧縮されない。

所有格もまた特別処理され、これらにはＳｈｏｒｔＴｙｐｅ「Ｐｏｓｓｅｓｓｉｖｅ」が与えられる。英語では、「′ｓ」および「ｓ′」の接語が付いた所有格は、アポストロフィなしで書き直すことができる。例えば、語「Ｊｏｈｎ′ｓ ｈｏｕｓｅ」は「Ｊｏｈｎｓ ｈｏｕｓｅ」と書くことができる。同様に、「ｄｏｇ′ｓ ｔａｉｌｓ」は「ｄｏｇｓ ｔａｉｌｓ」と書くことができる。

いくつかの前置詞もまた特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「Ｐｒｅｐｓ」が与えられる。例えば英語では、いくつかの前置詞がルックアップテーブルを通して要約される。例えば、「ｔｈｒｏｕｇｈ」は「ｔｈｒｕ」に要約することができる。単語「ａｔ」は「＠」に要約することができる。ある状況では、語「ｔｏ」および「ｆｏｒ」もまた、「２」および「４」に要約することができる。これらは、略さずに綴られた数詞または数字であって、可能性ある数字置換形を有する数詞または数字に隣接していない場合に限り、このような形で要約される。例えば、「Ｉ ｗａｎｔ ｔｏ ｌｅａｖｅ（私は出発したい）」という句では、語「ｔｏ」に数字「２」が取って代わる。しかし、「Ｉ ｈａｖｅ ｂｅｅｎ ｔｏ ｔｗｏ ｇｏｏｄ ｍｏｖｉｅｓ ｌａｔｅｌｙ（私は最近よい映画を２本観に行った）」という句では、語「ｔｏ」は数字「２」に変化しない。そうすると、話者がよい映画を２２本観たという誤解が生じる可能性があるからである。

いくつかの代名詞もまた特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「Ｐｒｏｎｏｕｎｓ」が与えられる。英語では、代名詞「ｙｏｕ」には「Ｕ」が取って代わる。他のすべての代名詞は同じままであり、母音除去されない。スペイン語では、代名詞「Ｕｓｔｅｄ」には「Ｕｄ」が取って代わり、「Ｕｓｔｅｄｅｓ」には「Ｕｄｓ」が取って代わる。ドイツ語では、「ｅｉｎ」（および屈折）を含む代名詞は、数字「１」を使用して要約される。

句読点は特別処理され、これにはＳｈｏｒｔＴｙｐｅ「Ｐｕｎｃｔｕａｔｉｏｎ」が与えられる。文の分離符号でもなく、電子メールエイリアスまたはＵＲＬの中に現れたのでもない句読点は、削除される。不可欠な句読点には、ＳｈｏｒｔＴｙｐｅ「ＥｓｓｅｎｔｉａｌＰｕｎｃｔ」が与えられる。あらゆる言語で、以下の文字は削除されない。すなわち、

（外１）

である。日本語では、文の分離符号としてのみ使用される特別な小円記号もまた削除されない。セミコロンおよびピリオドは、文の最後の句読点でない場合に限って削除される。他のすべての文字は、ＮｏｎｅｓｓｅｎｔｉａｌＰｕｎｃｔｕａｔｉｏｎ（後述する）とマークされる。

ただし一実施形態では、最後の句読点の連なりは、最初の文字に短縮される。したがって、「Ａｒｅ ｔｈｅｓｅ ｔｈｉｎｇｓ ｒｅｍｏｖｅｄ？！？（除去されたものがあるか？！？）」のような句では、最後の句読点は単に「？」に短縮される。

またあらゆる言語で、他の圧縮規則に従ってディジットになる場合のあるものの間に現れる句読点は維持される。例えば、「Ｉ ｂｏｕｇｈｔ ３ ｉｎ １９７６ ａｎｄ ｉｎ １９７７，１００（私は１９７６年に３個買い、１９７７年に１００個買った）」という句では、１９７７の後のコンマは維持される（または任意選択でスペースが維持される）。これは、１９７７１００に圧縮されるのを避け、そうではなく「１９７７，１００」または「１９７７ １００」に圧縮されるようにするためである。

同様に、英語では、ｉｎｃｈｅｓ（インチ）およびｆｏｏｔ／ｆｅｅｔ（フィート）の測定値の句は、適切なら″または′に変換される。

その他の重要でない句読点マークは特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「ＮｏｎｅｓｓｅｎｔｉａｌＰｕｎｃｔ」が与えられる。類事実（電子メールアドレス、ＵＲＬ、数字範囲など）の中の句読点は、そのまま残る。このような類事実の中にあるのではない句読点は、ＥｓｓｅｎｔｉａｌＰｕｎｃｔと、接続詞として現れた句読点（例えば節を分離するためのセミコロン）とを除いては、削除することができる。

いくつかの動詞もまた特別処理を受け、これらにはＳｈｏｒｔＴｙｐｅ「Ｖｅｒｂｓ」が与えられる。このような動詞は、辞書ルックアップの対象である。例えば、単語「ａｒｅ」には文字「Ｒ」が取って代わり、単語「ｂｅ」には「Ｂ」が取って代わることができる。そうでない場合は、動詞は単に、後で述べる文字削減および大文字／小文字標準化を受ける。

他にあと２つの形の特別処理も行われる。一方は、ＳｈｏｒｔＴｙｐｅ「ＷｏｒｄＳｕｂｓｔｉｔｕｔｉｏｎ」が与えられ、単語置換を含むものであり、他方は、先に論じた「ｗｈ」単語の処理である。これらのタイプの特別処理については、後で説明の中でより詳細に考察する。

次に、再び図５および図６に関して考察を進める。図５のブロック２４４で、これらの特別処理ケースをどれも行わない場合は、分析中の単語に関連するＳｈｏｒｔＦｏｒｍ属性を、単にＬｏｎｇＦｏｒｍ属性（テキスト中に書かれた単語の形）に設定する。これをブロック２４６で示す。

しかし、ブロック２４４で特別処理を行うと判定した場合は、次に、特別処理が単語置換かどうかを判定する。単語置換は、しばしば辞書ルックアップに基づいて単純に行う。単語置換は、例えば別の単語または句にあたる頭字語を得るために行うことができる。例えば英語では、「ａｓ ｓｏｏｎ ａｓ ｐｏｓｓｉｂｌｅ」という句は「ＡＳＡＰ」で置換することができる。

特別処理が単語置換である場合は、必要な単語置換をテキスト中の単語に対して行って、ＳｈｏｒｔＦｏｒｍ属性を得る。これをブロック２５０で示す。単語置換が成功した場合は、ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ（ＣＮＦ）属性とＣｏｍｐｒｅｓｓｅｄＦｏｒｍ（Ｃｏｍｐ）属性の双方を、このときにＳｈｏｒｔＦｏｒｍ属性にみられるのと同じ形に設定する。これにより、文字削減や大文字／小文字標準化などの後続処理からその単語が除かれる。これをブロック２５２で示す。したがって、単語置換プロセスを用いて、他の厄介な状況も回避することができる。例えばドイツ語では、代名詞「ｓｉｃｈ」は、よくある卑猥な言葉の省略形をもたらす後続の母音削除を回避するために、（単語置換により）「ｓｉｃｈ」のままにしておく必要がある可能性がある。特別処理が単語置換であるかどうか判定することを、ブロック２４８に示す。

ブロック２４８で、行う特定のタイプの特別処理が単語置換ではないと判定した場合は、ブロック２５４で、行う特別処理が前述の「ｗｈ」単語に関連する処理かどうか判定する。そうである場合は、「ｗｈ」単語は短縮されないことを想起されたい。この場合、残りのすべての属性（ＳｈｏｒｔＦｏｒｍ、ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ、およびＣｏｍｐｒｅｓｓｅｄＦｏｒｍ）は、ＬｏｎｇＦｏｒｍに設定する。これをブロック２５６で示す。

ブロック２５４で、行われる特別処理が「ｗｈ」単語に関連する処理ではないと判定された場合は、前述の特別処理操作のうちの他の１つでなければならない。この場合、その特定の特別処理ステップを行ってＳｈｏｒｔＦｏｒｍ属性を獲得し、それを保存する。これをブロック２５８で示す。

特別処理を行い、ＳｈｏｒｔＦｏｒｍ属性を得た後で、ＳｈｏｒｔＦｏｒｍ属性をスペース除去にかける。最初に、スペース除去を行うべきかどうかを決定する。これをブロック２６０で示す。行うべきである場合は、短い形を以下のプロシージャ中に述べるようなスペース除去アルゴリズムにかける。

各トークンを以下のとおり分類する
<EssentialPunct>:これらは叙述を必要とせず、すべてのトークンを叙述する働きをすると仮定する
<CaseDelineable>:大文字／小文字を標準化できる場合の、すべての通常の単語／句などを含む
<Number>:数字（これらには「２」に変換された「ｔｗｏ」のようなトークンが含まれることに留意されたい）
<SpaceDelineable>:ＵＲＬや電子メールアドレスのように、周りにスペースがなければならないトークン
アルゴリズムの一実施形態
//前にスペースのない短い形で始める
Result = RemoveLeadingSpaces (<short form>)
//トークンがNULLでない場合にのみこれを行う
if (Result) {
FrontSpaceNeeded = FALSE;
//現在のトークンのタイプをオンにする
switch <curtype> {
case <EssentialPunct>:
//すべて行うべきである。叙述は必要でない
break;
case <CaseDelineable>:
//前のタイプがspace delineableであった場合はスペースを配置する
if (prevtype == <SpaceDelineable>) FrontSpaceNeeded = TRUE;
break;
case <Number>:
//前のタイプがnumberまたはspace delineableであった場合はスペースを配置する
if (prevtype == <SpaceDelineable> || prevtype == <Number> || PreviousTokenがディジットで終わる) FrontSpaceNeeded = True;
break;
case <SpaceDelineable>:
//前のトークンがessential punctuationでない限りスペースを配置する
if (prevtype! = <EssentialPunct> && !lsFirstTokenInSentence) FrontSpaceNeeded = TRUE;
break;
}
//前のタイプを現在のタイプに設定する
prevtype = curtype;
if (FrontSpaceNeeded) Result = AddLeadingSpace (<Result>)
}

この擬似コードは、ＵＲＬや電子メールアドレスなどの前にあるスペースは除去されず、これらの後に続くスペースも除去されないことを示している。しかし、叙述がなされる可能性のあるその他の場合では、スペースはＳｈｏｒｔＦｏｒｍ属性から除去されることになる。これをブロック２６２で示す。

次に、大文字／小文字標準化を行うかどうかを判定する。これをブロック２６４で示す。例えば、ＵＲＬおよび電子メール、ならびに大文字／小文字の影響を受けやすいその他のものの中では、大文字／小文字標準化は望ましくない場合があることを理解されたい。このような場合は、ブロック２６６で示すように、ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ属性をＳｈｏｒｔＦｏｒｍ属性に設定する。しかし、大文字／小文字標準化が行われる場合は、ＳｈｏｒｔＦｏｒｍ属性の各単語の第１文字（トークンは複数の単語からなる可能性があることを想起されたい）を大文字にし、これをＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍ属性として保存する。これをブロック２６８で示す。

次に、さらに圧縮を行うかどうかを判定する。これをブロック２７０で示す。例えば、上述したいくつかの特別処理の場合では、母音除去は行わない（英語の代名詞、「ｗｈ」単語、固有名詞や、Ｍｏｎ、Ｔｕｅｓなどの日付のＳｈｏｒｔＦｏｒｍなど）。同様に、頭文字、電子メールアドレス、ＵＲＬなどからも、母音または子音は除去しない。

これ以上の圧縮を行わない場合は、ブロック２７２で示すように、ＣｏｍｐｒｅｓｓｅｄＦｏｒｍ属性をＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍに設定する。しかし、さらに圧縮を行う場合は、ＣａｓｅＮｏｒｍａｌｉｚｅｄＦｏｒｍに文字削減を施す（母音および子音の除去など）。

この考察では、用語「語中母音」とは、単語の最初にあるのでも最後にあるのでもない単一母音または一連の母音を意味する。英語では、すべての語中母音は除去される。

ドイツ語において文字を除去する場合は、まず子音群の簡略化規則が適用される。例えば、子音群「ｓｃｈ」は、指小接尾辞−ｓｃｈｅｎの中以外では「ｓｈ」に簡略化される。子音群「ｃｋ」もまた、「ｋ」に簡略化される。

次に、語尾に随伴する−ｅｉｎは、同じ発音の−１で置換される。ドイツ語には、−ｅｉｎで終わるが数字の１と同じ発音ではない単語がいくつかある。このような単語のいくつかの例を以下に挙げる。

Ｃｏｄｅｉｎ、Ｃｏｆｆｅｉｎ、Ｃａｓｅｉｎ、Ｆｌｕｏｒｅｓｚｅｉｎ、Ｈｕｓｓｅｉｎ、Ｋａｆｆｅｉｎ、Ｋａｓｅｉｎ、Ｋｌｅｂｅｒｐｒｏｔｅｉｎ、Ｋｏｄｅｉｎ、Ｌｕｔｅｉｎ、Ｍｏｖｅｉｎ、Ｎｕｋｌｅｉｎ、Ｎｕｃｌｅｉｎ、Ｏｌｅｉｎ、Ｐｈｅｎｏｌｐｈｔａｌｅｉｎ、Ｐｈｔａｌｅｉｎ、Ｐｒｏｔｅｉｎ、Ｐｙｇｍａｅｉｎ、Ｔａｌｅｉｎ、Ｔｅｉｎ、Ｔｈｅｉｎ、Ｚｅｉｎ、Ｚｙｇｓｔｅｉｎ
また、後続の単語が数字、日付、時間など（ディジットで始まる場合のある何らかのもの）である場合も、「ｅｉｎ」置換は行われないことに留意されたい。

ドイツ語で、語中母音を１つしか含まない単語の中では、母音は削除されない。２つ以上の語中母音を含む単語の場合は、２番目の語中母音ごとに削除される。子音と語尾「ｎｇ」との間の文字「ｕ」は削除される。まだ残っている「ｉｅ」がある場合は、「ｉ」に変換される。最後に、文字「ｅ」は、子音に続き、かつ語尾「ｌ、ｍ、ｎ、またはｒ」の前にある場合は、削除される。母音は、文字ｓに続き、かつ群ｃｈの前にある場合は、削除されないことに留意されたい。削除されると、ｓｃｈという連続になり、ドイツ語の読み手はこれを１つの子音の始めと解釈する傾向が非常に強いからである。この考察では、母音には通常、ａｅｉｏｕが含まれ、いくつかの言語ではｙも含まれ、またアクセント、ウムラウト、およびその他の発音区別符号が付いたすべての形が含まれる。英語、ドイツ語、フランス語、およびスペイン語に対する十分なリストを以下に挙げる。

（外２）

英語、ドイツ語、フランス語、およびスペイン語では、子音には以下のものが含まれる。

（外３）

他の言語の場合は、追加の子音記号を追加することができる。

ブロック２７４で示すように文字削減（母音除去や子音除去など）が行われると、ＣｏｍｐｒｅｓｓｅｄＦｏｒｍ属性が得られ、保存される。これをブロック２７６で示す。最後に、可能性ある圧縮オプションとして５つの属性すべてを出力することができる。これをブロック２７８で示す。

構文解析ツリーの走査中に、末端以外のノードレベルでも圧縮を行うことができることにも留意されたい。一実施形態では、構文分析に基づいて句全体を削除する。例えば、「Ｗｈｉｌｅ Ｉ ｗａｓ ｓｔｕｃｋ ｏｎ ｔｈｅ ｆｒｅｅｗａｙ，Ｉ ｒｅｍｅｍｂｅｒｅｄ ｔｏ ａｓｋ ｙｏｕ ｔｏ ｓｅｎｄ ｍｅ ｔｈｅ ｃｏｎｔａｃｔ ｉｎｆｏｒｍａｔｉｏｎ ｆｏｒ Ｄｒ．Ｍａｒｙ Ｓｍｉｔｈ．（フリーウェイで立ち往生している間に、Ｍａｒｙ Ｓｍｉｔｈ先生に関するコンタクト情報を送ってくれるようにあなたに頼むことを思い出した。）という文を考えてみる。この例では、文頭の従属節全体を削除することができる。言い換えれば、構文分析によってこれが従属節であることが示され、従属接続詞「ｗｈｉｌｅ」によってこれが時を表す副詞節であることが示される。したがって、このフレーズ全体を単純に削除して、「Ｉ ｒｅｍｅｍｂｅｒｅｄ ｔｏ ａｓｋ ｙｏｕ ｔｏ ｓｅｎｄ ｍｅ ｔｈｅ ｃｏｎｔａｃｔ ｉｎｆｏｒｍａｔｉｏｎ ｆｏｒ Ｄｒ．Ｍａｒｙ Ｓｍｉｔｈ．」という文を得ることができる。１９９８年１２月２４日に出願されたＳＹＳＴＥＭ ＦＯＲ ＩＭＰＲＯＶＩＮＧ ＴＨＥ ＰＥＲＦＯＲＭＡＮＣＥ ＯＦ ＩＮＦＯＲＭＡＴＩＯＮ ＩＤＥＮＴＩＦＹＩＮＧ ＣＬＡＵＳＥＳ ＨＡＶＩＮＧ ＰＲＥＤＥＴＥＲＭＩＮＥＤ ＣＨＡＲＡＣＴＥＲＩＳＴＩＣＳという名称の特許出願第＿０９／２２０８３６号に、従属節の識別、およびそれらの節が比較的重要な題材を含んでいるかどうかの識別に関する追加情報が提供されている。

末端以外のノードレベルでの圧縮に関する別の例は、発話行為動詞に関するものである。発話行為動詞は、言語学で「補語をとる述語」と呼ばれるサブクラスである。英語では、以下の文にあいまいさが示される。

「Ｊｏｈｎ ｓａｉｄ ｔｈａｔ ｈｅ ｗａｓ ａｒｒｉｖｉｎｇ ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ．」
ある読み方では、単語「ｈｅ」は「Ｊｏｈｎ」と同一指示的である。別の読み方では、「ｈｅ」は他の誰かである可能性がある。以下のように、出力を入力よりいくらかでもあいまいにすることなく、この文のいくつかの要素を削除することができる。

母型節の発話行為動詞の主語（この場合は「ｓａｉｄ」の主語である「Ｊｏｈｎ」）が従属節の代名詞主語（ｈｅ）と同一指示的であるかもしれない場合に、形態ルックアップからわかるようにこれらが双方とも男性であることに注意することによって、または同一指示性を決定するためのより複雑な意味論分析を用いることによって、同一指示的であることが決定できる場合は、従属節中の代名詞は削除することができる。従属接続詞「ｔｈａｔ」もまた削除でき、以下のようになることに留意されたい。

「Ｊｏｈｎ ｓａｉｄ ｗａｓ ａｒｒｉｖｉｎｇ ｎｅｘｔ Ｗｅｄｎｅｓｄａｙ」
従属節の主語は、それが代名詞であって、かつ主節の主語と同一指示的であるときだけ削除するように注意しなければならないことに留意されたい。例えば、以下の場合は削除すべきではない。

Ｊｏｈｎ ｓａｉｄ ｔｈａｔ ｓｈｅ ｗａｓ ａｒｒｉｖｉｎｇ．．．
Ｊｏｈｎ ｓａｉｄ ｔｈａｔ Ｂｉｌｌ ｗａｓ ａｒｒｉｖｉｎｇ．．．
Ｊｏｈｎ ｓａｉｎ ｔｈａｔ ｔｈｅｙ ｗｅｒｅ ａｒｒｉｖｉｎｇ．．．

この時点で、図３に示した文を例にして話を続けるのが有用であろう。先に述べたように、分析における各ノードを再帰的に調べて、圧縮が達成できるかどうかを判定する。したがって、最初に文ノード（Ｓ）を調べる。この時点では圧縮を行うことはできず、したがって処理はより深い分析に進み、名詞句ノード３００を調べる。このレベルでは圧縮を行うことはできず、したがって、処理はより深く代名詞ノード３０２に進む。代名詞は「ｙｏｕ」であることがわかる。したがって、特別処理の規定により、これを「Ｕ」に変換することができる。この結果、以下の属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝Ｐｒｏｎｏｕｎｓ
ＬｏｎｇＦｏｒｍ＝Ｙｏｕ
ＳｈｏｒｔＦｏｒｍ＝Ｕ
ＣＮＦ＝Ｕ
Ｃｏｍｐ．＝Ｕ

次の処理は、動詞句ノード３０４に関して継続する。このレベルでは圧縮を行うことはできないことがわかり、したがって動詞ノード３０６を調べる。語「ｈａｖｅ」を、単純に図５および図６に示すフローチャート中を通し、大文字／小文字標準化および母音除去を施して、語「Ｈｖｅ」が得られる。これにより、以下の属性が得られる（下線は前にあるスペースを表す）。

ＳｈｏｒｔＴｙｐｅ＝ＶｅｒｂｓＤｅｆａｕｌｔ
ＬｏｎｇＦｏｒｍ＝＿ｈａｖｅ
ＳｈｏｒｔＦｏｒｍ＝＿ｈａｖｅ
ＣＮＦ＝Ｈａｖｅ
Ｃｏｍｐ．＝Ｈｖｅ

この場合も、ノード３０８を調べ、このレベルでは圧縮を行うことはできないことがわかる。したがって、検査はノード３１０に進み、図５のブロック２４０で冠詞「ａ」を削除する。これにより以下のようになる。

ＳｈｏｒｔＴｙｐｅ＝Ａｒｔｉｃｌｅｓ
ＬｏｎｇＦｏｒｍ＝＿ａ
ＳｈｏｒｔＦｏｒｍ＝Ｎｕｌｌ
ＣＮＦ＝Ｎｕｌｌ
Ｃｏｍｐ．＝Ｎｕｌｌ

次いで、ノード３１２を調べて単語置換を施し、これにより以下の５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝ＷｏｒｄＳｕｂｓｔｉｔｕｔｉｏｎ
ＬｏｎｇＦｏｒｍ＝＿ｍｅｅｔｉｎｇ
ＳｈｏｒｔＦｏｒｍ＝Ｍｔｇ
ＣＮＦ＝Ｍｔｇ
Ｃｏｍｐ．＝Ｍｔｇ

次いで、前置詞句ノード３１４を調べるが、このレベルでは圧縮を行うことはできないと判定される。したがって、前置詞ノード３１６を調べる。処理は図５および図６のフローチャート中を移動し、大文字／小文字標準化および母音除去を行って、以下の５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝ＰｒｅｐｓＤｅｆａｕｌｔ
ＬｏｎｇＦｏｒｍ＝＿ｗｉｔｈ
ＳｈｏｒｔＦｏｒｍ＝＿ｗｉｔｈ
ＣＮＦ＝Ｗｉｔｈ
Ｃｏｍｐ．＝Ｗｔｈ

次いで、固有名詞ノード３１８を調べる。このノードでは、ＰｒｐｒＮのＳｈｏｒｔＴｙｐｅを用いて３つの単語「Ｄｒ．Ｊｏｈｎ Ｅｐｓｔｅｉｎ」を圧縮できることがわかる。これにより、以下の５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝ＰｒｐｒＮ
ＬｏｎｇＦｏｒｍ＝＿Ｄｒ．＿Ｊｏｈｎ＿Ｅｐｓｔｅｉｎ
ＳｈｏｒｔＦｏｒｍ＝＿Ｅｐｓｔｅｉｎ
ＣＮＦ＝Ｅｐｓｔｅｉｎ
Ｃｏｍｐ．＝Ｅｐｓｔｅｉｎ

次に、ノード３２０を調べるが、この句がオフセット日付を表していることがわかる。図５および図６に示すフローチャートを通してこれを分析し、以下の５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝ＯｆｆｓｅｔＤａｔｅ
ＬｏｎｇＦｏｒｍ＝＿ｎｅｘｔ＿Ｔｕｅｓｄａｙ
ＳｈｏｒｔＦｏｒｍ＝＿１２／３
ＣＮＦ＝１２／３
Ｃｏｍｐ．＝１２／３

次に、ノード３２２を調べるが、このノードでは圧縮を行うことはできないと判定される。したがって、前置詞ノード３２４を調べる。図５および図６に示す処理を通して、語「ａｔ」が「＠」に対する単語置換の対象であることに気付く。これにより、以下の５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝ＷｏｒｄＳｕｂｓｔｉｔｕｔｉｏｎ
ＬｏｎｇＦｏｒｍ＝＿ａｔ
ＳｈｏｒｔＦｏｒｍ＝＠
ＣＮＦ＝＠
Ｃｏｍｐ．＝＠

最後にノード３２６を調べるが、見つかる圧縮は、綴り字の語「ｔｅｎ」に数字「１０」が取って代わることだけであり、これにより５つの属性が得られる。

ＳｈｏｒｔＴｙｐｅ＝Ｎｕｍｂｅｒｓ
ＬｏｎｇＦｏｒｍ＝＿ｔｅｎ＿ａｍ
ＳｈｏｒｔＦｏｒｍ＝＿１０ａｍ
ＣＮＦ＝１０ａｍ
Ｃｏｍｐ．＝１０ａｍ

次いでコンプレッサ２０２が、これらのデータ構造中に示した様々な圧縮オプションの中から自由に選りすぐって、最終的な出力であるテキスト圧縮バージョンを提供する。これは、ターゲットデバイス２０５上の表示画面のサイズが著しく限られている場合は非常に大胆に行うことができ、例えば表示空間のより大きいパームトップコンピュータの場合は、より低い大胆さで行うことができる。したがって、最も大胆な圧縮は以下のようになる。

ＵＨＶｅＭｔｇＷｔｈＥｐｓｔｅｉｎ１２／３＠１０ａｍ
非常に大胆な圧縮でも、これは大いに読むことが可能かつ解読可能なテキストメッセージであり、それでもなお、図３に述べた原形に勝って多くの空間を節約する。

したがって、本発明を使用して大きな圧縮をもたらすことができ、それでもなお、圧縮は、人間が容易に解読できるような言語的に非常にインテリジェントな方式で行われることがわかる。本発明はまた、個々の単語および句ごとに異なる複数の圧縮オプションを提供し、これらは多くの場合、大胆さの様々な度合いを反映する。このことは、最終的にターゲットデバイス中で最良の圧縮シーケンスを選択しなければならないダウンストリームコンポーネントにとって非常に有用である。

本発明を特定の実施形態に関して述べたが、本発明の趣旨および範囲を逸脱することなく形式および詳細に変更を加えることができることを当業者なら理解するであろう。

本発明を使用することのできる一実施形態のブロック図である。 本発明の一実施形態により言語分析を行うためのメッセージハンドラのブロック図である。 例示的な文に関する構文解析ツリーの一部の図である。 図２に示したシステムの全体的な動作のフローチャートである。 構文分析の中の末端ノード（または単語および句読点）に対する圧縮オプションを生成する際の、図２に示したシステムの動作を示すより詳細なフローチャートである。 構文分析の中の末端ノード（または単語および句読点）に対する圧縮オプションを生成する際の、図２に示したシステムの動作を示すより詳細なフローチャートである。

符号の説明

１１０ コンピュータ
１２０ プロセッシングユニット
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ ＢＩＯＳ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ その他のプログラムモジュール
１３７ プログラムデータ
１４０ 取外し不可能かつ不揮発性メモリインタフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ その他のプログラムモジュール
１４７ プログラムデータ
１５０ 取外し可能かつ不揮発性メモリインタフェース
１５１ 磁気ディスクドライブ
１５２ 磁気ディスク
１５５ 光学ディスクドライブ
１５６ 光学ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロホン
１７０ ネットワークインタフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
２００ メッセージハンドラ
２０２ コンプレッサ
２０４ メッセージパーサ
２０５ ターゲットデバイス
２０６ 言語アナライザ
２０８ テキスト圧縮コンポーネント
２１０ リンク
２１２ メッセージ
２１４ メッセージ本文
２１６ 圧縮済みＸＭＬ出力
３００、３０２、３０４、３０６、３０８、３１０、３１２、３１４、３１６、３１８、３２０、３２２、３２４、３２６ ノード

Claims (4)

1. コンピュータにおいて、テキスト本文を処理して複数の圧縮オプションを生成する方法において、前記コンピュータは、
   前記テキスト本文について言語解析を実行し、前記テキスト本文の中の、単語および数字の１つを有する複数のトークンを取得する手段と、
   前記言語解析の実行の後、前記テキスト本文を圧縮するために、前記テキスト本文の中の複数の対応の異なるトークンの各々について複数の正しい圧縮オプションを自動的に生成して前記テキスト本文を圧縮するための手段であって、そこでは、前記正しい複数の圧縮オプションの各々は、異なる、前記テキスト本分の中の対応のトークンの正しい圧縮形を有し、前記対応のトークンの中の文字列または数字列の個数を少なくとも減らし、前記圧縮形には前記対応の複数のトークンの中のいくつかの、すべてではない文字列を含む手段と、
   前記テキスト本文の中の異なる複数のトークンの各々についての複数の圧縮オプションの１つを選択し、各トークンについて選択の圧縮のオプションに従って前記テキスト本文の圧縮形を出力する手段
   として動作することを特徴とする方法。
2. メッセージを受け取り、メッセージの中のテキスト本文の一部分の異なる形態を示す複数の圧縮オプションを生成するコンピュータにおいて、
   言語学的に前記テキスト本文を解析して、前記テキスト本文の中の個々のトークンを葉ノードで示す言語学的解析を提供する手段と、
   少なくとも前記言語学的解析の中の葉ノードで表される複数のトークンについての複数の異なる圧縮形を提供する手段であって、前記複数の異なる圧縮形は、各々が対応の個々のトークンの正しい圧縮形を示す圧縮形生成手段と、
   前記テキスト本文の中の個々のトークンについての異なる複数の圧縮形の中の選択を示す出力を生成する圧縮手段と
   を備えたことを特徴とするコンピュータ。
3. テキスト本文を圧縮するためのコンピュータにおいて、
   圧縮のタイプとして、単語の消去する、単語を置換するおよび単語そのものを使用するタイプが単語の言語学的特徴に対応して予め定められており、
   前記テキスト本文中の各単語の特徴を言語学的に解析する解析手段であって、前記言語学的の解析により得られる言語学的特徴は、単語に付加される属性の形態で表される解析手段と、
   前記属性に従って前記テキスト本文中の各単語を圧縮する圧縮手段と
   を備えたことを特徴とするコンピュータ。
4. 前記テキスト本文は、複数の単語を複数のノードとして表される１つのツリーの形態で表され、前記解析手段は前記ツリー上の各単語を検索して単語を言語学的に解析することを特徴とする請求項３に記載のコンピュータ。

Images