JPH1083274A - ポインタ位置に文字データを受け入れられることを判定する方法およびシステム - Google Patents

Abstract

(57)【要約】 【課題】 非システム・ポインタがシステム・ポインタ
と同等であるかどうかを判定するためのシステムおよび
方法を提供する。 【解決手段】 システム・ポインタと非システム・ポイ
ンタにはそれぞれポインタＩＤが付いている。システム
はまず、非システム・ポインタのポインタＩＤがポイン
タＩＤのテーブルに入っていて、システム・ポインタと
同等であるというフラグがそのテーブル内に付いている
かどうかを判定する。非システム・ポインタのポインタ
ＩＤがポインタＩＤのテーブルに入っていない場合、シ
ステムは、非システム・ポインタの形状に基づいて、非
システム・ポインタがシステム・ポインタと同等である
かどうかを判定する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、広義にはデータ処
理システムに関する。本発明は、単一タスクがキーボー
ド、マウス、またはスタイラス事象などのユーザ入力を
ユーザの制御下で現在実行中の様々なコンピュータ・プ
ログラムに経路指定することに専用化された、マルチタ
スク処理ペンベース・コンピュータ・システムにおいて
具体的に応用されるものである。

【０００２】

【従来の技術】オペレーティング・システム、好ましく
はＩＢＭのＯＳ／２オペレーティング・システムなどの
ペン・ソフトウェア拡張機能により、ユーザは、後で認
識のためにジェスチャ筆跡認識エンジンに送られる文字
をウィンドウに直接書き込むことができる。デフォルト
の場合、そのウィンドウが編集フィールドまたはテキス
ト入力ウィンドウなどテキストを受け入れるものでない
限り、このシステムは、手書き形状をジェスチャとして
扱う。ペンベース・システムについては、アラン・タネ
ンバウム（Alan Tannenbaum）他の「Graphical User In
terface with Gesture Recognition in a Multi-Applic
ation Environment」という名称の米国特許第５２５２
９５１号に全般的に記載されている。

【０００３】規約により、テキストを受け入れるフィー
ルドは、ポインタがそのテキスト・フィールドの上に位
置決めされたときにＩビーム・マウス・ポインタを表示
することにより、その旨を示す。オペレーティング・シ
ステムは、１）すべての入力フィールドの外観が均一に
なり、２）各アプリケーションの開発者がＩビーム・マ
ウス・ポインタのカスタム・バージョンを設計して、そ
れぞれの製品とともにそれを出荷する必要がないように
アプリケーションが使用するための標準的なＩビーム・
マウス・ポインタを提供する。

【０００４】ペンベース・システム・ソフトウェアは、
この標準的なＩビームを利用し、ユーザがテキスト・フ
ィールドに書き込んでいることを把握する。ユーザが表
面付近にスタイラスを移動させ、書込みを始めると、シ
ステムはスタイラスの位置までマウス・ポインタを移動
させる。マウス・ポインタがテキスト・フィールド内に
ある場合、ポインタはＩビームになる。ペンベース・シ
ステムは、ポインタの形状に気付かないが、ポインタの
ＩＤをシステムが供給したＩビーム・ポインタのＩＤと
比較する。両方のＩＤが一致した場合、システムは２通
りのアクションを行う。第１に、システムはマウス・ポ
インタをＩビームからペン形に変更し、ユーザがスタイ
ラスでそのフィールドに直接書き込めることをユーザに
警告する。第２に、システムは手書き文字をジェスチャ
ではなく主にテキストとして扱う。ペンまたはスタイラ
ス入力を解釈するためのアプリケーション、ウィンド
ウ、ポインタの特性の検査については、「Data Interpr
etation Techniques for a Pen-based Computer」と題
するＩＢＭテクニカル・ディスクロージャ・ブリテン、
Vol. 38、No. 09、１９９５年９月に記載されている。

【０００５】しかし、ペンが直面する問題は、多くのア
プリケーション開発者が独自のバージョンのＩビーム・
ポインタを付けてそれぞれのアプリケーションを出荷す
ることである。このような開発者は、美的な理由のため
または単に自分のアプリケーションを競合他社のものと
区別するだけのために、独自のＩビーム・ポインタ形状
を設計している。しかし、いずれの場合も、このような
カスタムＩビームは、良好なヒューマン・ファクタを確
保するために、依然として標準的なＩビーム形状との類
似性をある程度保持している。そうしないと、ユーザが
混乱し、そのフィールドがテキスト入力を受け入れるこ
とに気付かない恐れがある。残念ながら、有力なワード
・プロセッサ・アプリケーションのほとんどは、独自の
Ｉビーム・ポインタを付けて出荷されており、ポインタ
ＩＤ同士を比較するための現存するペンベース・システ
ム技法がいくらか無効になる。

【０００６】ペンベース・システムのもう１つの問題
は、アプリケーションがマウスおよびキーボード入力を
処理できないときを確認することである。通常、アプリ
ケーションは、砂時計ポインタを表示することによっ
て、この「使用中」状態を通知する。これは普通は十分
な表示であり、砂時計ポインタが矢印ポインタに復元さ
れるまで、ユーザは入力を停止する。しかし、多くの場
合、アプリケーションが使用中状態になっている間、デ
スクトップ上の他の活動アプリケーションに向けられた
マウスまたはキーボード入力はすでにシステム待ち行列
に入っている。しかし、ＯＳ／２とWindowsの両方のオ
ペレーティング・システムの設計では、それがマウスお
よびキーボード入力の待ち行列解除を終了したことを使
用中アプリケーションが実際に最初にオペレーティング
・システムに通知するまで、待ち行列に入っている入力
を待ち行列から外してターゲット・アプリケーションに
ディスパッチすることができない。オペレーティング・
システムは、アプリケーションが瞬間的に使用中状態に
なっていることを知ることができないが、ユーザはそれ
を知ることができる。オペレーティング・システムがこ
の使用中状態を検出することができれば、即座に入力待
ち行列を調べ、ユーザ入力を待っている非使用中アプリ
ケーションに向けられたマウスまたはキーボード入力を
待ち行列解除／経路指定することができるはずである。
その結果、処理上のボトルネックが除去されるはずであ
る。

【０００７】

【発明が解決しようとする課題】したがって、本発明の
一目的は、様々なコンピュータ・プログラム・アプリケ
ーションによって表示されるマウス・ポインタを光学的
に認識し、そのアプリケーションの動的状態または環境
を判定することにある。

【０００８】本発明の他の目的は、正確なポインタ形状
認識を実行し、高い確信度でターゲット以外のポインタ
形状を確実に拒否することにある。

【０００９】本発明のさらに他の目的は、認識プロセス
によって追加されるオーバヘッドがコンピュータの応答
性またはパフォーマンスに対して認識できるほどの影響
を及ぼさないように、計算上効率のよいやり方でポイン
タ形状認識を実行することにある。

【００１０】本発明のさらに他の目的は、ディスプレイ
の解像度とカラー能力が変化するコンピュータ上でポイ
ンタ形状認識を実行することにある。

【００１１】

【課題を解決するための手段】簡単に説明すると、上記
およびその他の目的は、本発明の方法およびシステムに
よって達成される。本発明の一態様のシステムは、非シ
ステム・ポインタがシステム・ポインタと同等であるか
どうかを判定する。システム・ポインタと非システム・
ポインタにはそれぞれポインタＩＤが付いている。シス
テムはまず、非システム・ポインタのポインタＩＤがポ
インタＩＤのテーブルに入っていて、システム・ポイン
タと同等であるというフラグがそのテーブル内に付いて
いるかどうかを判定する。非システム・ポインタのポイ
ンタＩＤがポインタＩＤのテーブルに入っていない場
合、システムは、非システム・ポインタの形状に基づい
て、非システム・ポインタがシステム・ポインタと同等
であるかどうかを判定する。

【００１２】システムは、非システム・ポインタを事前
定義マスクと比較することにより、非システム・ポイン
タがシステム・ポインタと同等であるかどうかを形状に
基づいて判定する。非システム・ポインタのすべての画
素がマスク内に入る場合、システムは、非システム・ポ
インタを構成する画素数が所定のしきい値を上回るかど
うかを判定する。非システム・ポインタがシステム・ポ
インタと同等であるとシステムが判定すると、システム
は、ポインタＩＤのテーブルに非システム・ポインタの
ポインタＩＤを追加し、そのポインタＩＤにシステム・
ポインタと同等であるというフラグを付ける。

【００１３】本発明の他の態様のシステムは、まず非シ
ステム・ポインタを事前定義粗大マスクと比較すること
により、非システム・ポインタがシステム・ポインタと
同等であるかどうかを判定することができる。非システ
ム・ポインタのすべての画素が粗大マスク内に入る場
合、システムは非システム・ポインタを事前定義微細マ
スクと比較する。前記非システム・ポインタのすべての
画素が微細マスク内に入る場合、システムは、非システ
ム・ポインタを構成する画素数が所定のしきい値を上回
るかどうかを判定する。次にシステムは、非システム・
ポインタが所定の対称条件を満足するかどうかを判定す
ることができる。

【００１４】

【発明の実施の形態】次に添付図面、特に図１をまず参
照すると、本発明のシステムおよび方法を実施すること
ができるパーソナル・コンピュータ・システムのハード
ウェア・ブロック図の全体が参照番号１０によって示さ
れている。システム１０は、中央演算処理装置（ＣＰ
Ｕ）１５とランダム・アクセス・メモリ１３とを含むプ
ロセッサ１１を含む。システム１０は、ハード・ディス
ク記憶装置１７とフロッピー・ディスク装置１９という
形式の追加メモリも含むことが好ましい。フロッピー・
ディスク装置１９は、本発明のソフトウェア実施態様を
含む、プログラム用のソフトウェアを記録可能なディス
ケット２１を受け入れられるようになっている。また、
システム１０は、ディスプレイ２３、キーボード２５、
マウス２７、ペンまたはスタイラス２９を含む、ユーザ
・インタフェース・ハードウェア装置も含む。システム
１０はプリンタ３１を含むことが好ましい。

【００１５】次に図２を参照すると、同図には、本発明
のペンベース・システムの主要ソフトウェア・システム
構成要素の高レベル図が示されている。図２の下部で
は、ペン２９、マウス２７、キーボード２５からの出力
信号がデバイス・ドライバ３３に接続されているが、こ
のデバイス・ドライバはそれぞれの装置に低レベルの入
出力サポートを提供するモジュールである。デバイス・
ドライバ３３は事象をシステム待ち行列３５に入れる。
システム待ち行列３５内の事象は、その後、プレゼンテ
ーション・マネージャ３７によって処理され、プレゼン
テーション・マネージャ３７は次にペン事象およびマウ
ス事象を処理のためにペン拡張部３９に経路指定する。

【００１６】典型的なシステムは、ペン認識アプリケー
ション４１とペン非認識アプリケーション４３の両方を
含む。ペン認識アプリケーションは、ペン入力を認識し
て処理するための固有の能力を備えている。ペン非認識
アプリケーションは、キーボードまたはマウスあるいは
その両方の入力を認識して処理するための固有の能力だ
けを備えたものである。したがって、ペン拡張部３９
は、ペン事象をペン認識アプリケーション４１に直接経
路指定する。しかし、ペン非認識アプリケーション４３
はペン機能を使用することができないので、システムは
互換モジュール４５を含む。

【００１７】互換モジュール４５は、ペン非認識アプリ
ケーションのためにペン認識アプリケーションとして動
作する。たとえば、ユーザがペン認識アプリケーション
に手書き文字事象を入力した場合、ペン拡張部３９はこ
の事象を互換モジュール４５に経路指定し、次に互換モ
ジュール４５がすべてのペン・ストロークをジェスチャ
筆跡認識エンジン４７に経路指定する。ジェスチャ筆跡
認識エンジン４７は、ペン・ストローク事象を処理し、
認識結果を互換モジュール４５に返す。

【００１８】認識事象がジェスチャである場合、互換モ
ジュール４５はそれを認識事象送達サブシステム４９に
経路指定し、そのサブシステムは、特定のジェスチャに
応答してペン非認識アプリケーションでどのアクション
を実行すべきかをユーザが判定できるようにセットアッ
プしたプロファイル５１にアクセスする。任意で一部の
ツール５３を呼び出して、ペン非認識アプリケーション
４３上で何らかのアクションを実行することもできる。
互換モジュール４５に返された認識結果が筆跡であると
認識された場合、その結果のテキスト・ストリングは適
切なペン非認識アプリケーション４３に直接経路指定さ
れる。

【００１９】次に図３を参照すると、コンピュータのデ
ィスプレイ画面の全体が参照番号６０で示されている。
画面６０は、その上にウィンドウ６１が表示されてお
り、そのウィンドウはノートブック６３を表示してい
る。当業者には当たり前のように、ノートブック６３
は、様々なタブおよびボタンと、テキスト入力フィール
ド６５を含む。ペンベース・システムでは、ユーザがペ
ンまたはスタイラス（図示せず）を画面６０の近くに持
ってくると、システムは、ペンの位置までポインタを移
動させ、ペン位置の特性に応じてペンによるアクション
を処理する。図３では、ポインタはテキスト・フィール
ド６５内にあり、Ｉビーム６７の形状を呈している。こ
のＩビーム・ポインタ形状は、テキスト・フィールド６
５がキーボードからのテキスト入力を受け入れることを
ユーザに示すものである。

【００２０】図４は、図３とほぼ同じであるが、図４の
システムには図３のＩビーム・ポインタの代わりにペン
形ポインタ６９が描かれてる。ペン形ポインタ６９は、
テキスト・フィールド６５が文字またはジェスチャの形
で手書き入力を受け入れることをユーザに示すものであ
る。

【００２１】次に図５を参照すると、同図には、アイコ
ン・エディタ・アプリケーションで表示されるような、
アイコン・ビットマップ８０の絵画表現が示されてお
り、代表的な６通りのＩビーム・ポインタ形状がそこに
描かれている。アイコン・ビットマップ８０は３２×３
２のエレメントからなるグリッドであり、各エレメント
はＶＧＡ解像度の１つの画素（ペル）を表している。図
５に示すＩビーム・ポインタ形状は、ＯＳ／２（ＴＭ）
のＩビーム・ポインタ８１と、Windows（ＴＭ）のＩビ
ーム・ポインタ８３を含んでいる。

【００２２】図５に示すＩビーム・ポインタ形状は、ユ
ーザがただちにＩビームとして認識するような形状を保
持しながら、ペル・レベルでかなり変形したポインタを
示している。また、図５は、設計者がＩビーム・ポイン
タをビットマップのどこにでも配置できることも示して
いる。

【００２３】次に図１３を参照すると、同図には、マウ
ス事象を受け取るたびに呼び出される図２のペン拡張部
３９の機能を示す高レベル流れ図が示されている。この
機能は、通常、マウスまたはペンが動いている間に毎秒
６０〜１００回呼び出される。というのは、これがこの
ような装置の標準的な報告速度であるからである。ポイ
ンティング・デバイスの増分運動ごとに、ポインタ形状
は新しい位置に描き直す必要がある。ポインティング・
デバイスが任意のタイプの入力フィールドの上にある
と、オペレーティング・システムまたはアプリケーショ
ンは、Ｉビームをペイントして、キーボード入力が許さ
れていることをユーザに通知する。ポインタが現在、Ｉ
ビームである場合、図１３の機能により、オペレーティ
ング・システムは図４のペン・ポインタ形状６９をペイ
ントすることになる。

【００２４】ブロック１５００から始まり、現行ポイン
タのＩＤを照会し、現行ポインタがシステムＩビームで
あるか（判断ブロック１５１０）または別のシステム・
ポインタであるか（判断ブロック１５２０）を確認する
ためにテストする。そのポインタがシステムＩビームで
ある場合、システムはブロック１５７０でそのポインタ
形状をペンに変更し、ブロック１５８０で終了する。

【００２５】そのポインタがオペレーティング・システ
ムによって供給された他のポインタの１つである場合、
システムは追加アクションを一切行わず、ブロック１５
８０で終了する。そうではない場合、システムは、ブロ
ック１５３０で図１２によるポインタ・テーブル１４０
０にアクセスし、現行ポインタＩＤ用の項目が存在する
かどうかを判定する。

【００２６】図１２に移行すると、ポインタ・テーブル
１４００は、ポインタＩＤ１４０５、プロセスＩＤ１４
１０、Ｉビーム・フラグ１４１５などの列を有するテー
ブルである。好ましい実施例のポインタ・テーブル１４
００は、行０〜２４９に最高２５０項目まで保持できる
ように構築されている。後で詳述するように、ポインタ
・テーブルは、新しいポインタが認識されたときに項目
を追加し、アプリケーションがシャットダウンされたと
きに項目を削除することによって管理される。

【００２７】図１３に戻ると、判断ブロック１５４０で
ポインタ・テーブル１４００が現行ポインタ用の項目を
含む場合、システムは、判断ブロック１５６０でそのテ
ーブル項目にＩビームとしてのフラグが付いているかど
うかをテストするために分岐する。フラグが付いている
場合、システムはブロック１５７０でペン・ポインタを
ペイントし、付いていない場合、プロセスはブロック１
５８０で終了する。判断ブロック１５４０でのポインタ
・テーブル項目のテストで不合格になった場合、そのポ
インタのＩビーム形状をテストするために別のルーチン
が呼び出されるが、これについては全体をプロセス・ブ
ロック１５５０に示し、詳しくは図１５ないし図２１に
示す。判断ブロック１５６０でそのポインタがＩビーム
であるとルーチンが示す場合、システムはブロック１５
７０でポインタをペンに変更し、そうではない場合、ル
ーチンは１５８０で終了する。

【００２８】図１５を参照すると、図１３のブロック１
５５０でＩビーム形状をテストするルーチンは、アプリ
ケーション供給の各ポインタごとに１回ずつしか呼び出
されないことに留意されたい。これは、ポインタのＩビ
ーム形状のテスト結果が肯定であるかどうかにかかわら
ず、図１５のルーチンがブロック１７５０および１７８
０で各ポインタ・フラグごとにポインタ・テーブル１４
００のＩビーム・フラグ列１４１５に項目を１つずつ作
成するからである。特定のポインタＩＤについてポイン
タ・テーブル１４００の項目が存在すると、図１３の判
断ブロック１５４０のテーブル項目テストの結果が必ず
真になり、Ｉビーム認識プロセスによって発生するオー
バヘッドが防止される。大多数のアプリケーションがシ
ステム供給Ｉビームとその他のシステム・ポインタを使
用し、非システム・ポインタは１回しかテストされない
ということにより、この機能の処理要件が最小限に維持
される。システムにかかる追加の負荷は、洗練され見識
のあるユーザでも認識できないほどである。

【００２９】次に図１４を参照すると、同図には、ポイ
ンタ形状をテストし監視できるようにペン拡張部モジュ
ール３９（図２）を準備するためにブート時にどのよう
な前処理が必要かを示している。ブロック１６００で
は、ポインタ・テーブル１４００内の有効項目の数がゼ
ロになる。好ましい実施例では、Windows（ＴＭ）のＩ
ビーム・ポインタの迅速テストを促進するために、ブロ
ック１６１０でWindowsのＩビーム・ビットマップのコ
ピーがロードされ、ブロック１６２０で照会され、ブロ
ック１６３０でグローバル・メモリ内に移動される。

【００３０】好ましいオペレーティング・システムであ
るＯＳ／２では、独自のＤＯＳ仮想計算機に各Windows
アプリケーションをロードすることにより、固有のWind
owsアプリケーションを実行することができる。この実
施態様の難点は、すべてのアプリケーションが同一のWi
ndows供給Ｉビーム・ポインタを使用していても、活動
状態の各Windowsアプリケーションに固有のＩビーム・
ポインタＩＤが１つずつ与えられることである。認識プ
ロセスの速度を上げるため、現行ポインタとの高速メモ
リ間比較を行えるように、標準のWindowsＩビームのビ
ットマップがメモリに保持される。

【００３１】初期設定の最後のステップでは、システム
供給ＩビームのＩＤがブロック１６４０で照会される。
これは、図１３の判断ブロック１５１０のテストで使用
するＩＤである。

【００３２】図１５は、高レベル認識プロセスを示して
いる。ブロック１７００で概略を示すように、システム
は、現行ポインタのビットマップをメモリにコピーする
ためのルーチンを呼び出すが、そのメモリではビットマ
ップを検査し操作することができる。図１６はこの処理
を示している。ただし、ペン拡張部モジュール３９は、
アプリケーションと同じようにビットマップにアクセス
できるわけではないことに留意されたい。というのは、
このモジュールはオペレーティング・システムの拡張部
として動作しているため、アプリケーションの環境につ
いてはほとんど把握していないからである。このため、
ペン拡張部３７は非常に間接的かつ遠回しのやり方でビ
ットマップ・データにアクセスしなければならない。周
知のＯＳ／２システムＡＰＩを使用して、ブロック１８
００でプレゼンテーション・スペースが割り振られ、ブ
ロック１８１０でポインタ形状ビットマップのハンドル
が照会される。次に、ビットマップがプレゼンテーショ
ン・スペースに設定されるが、これは、ブロック１８３
０でグラフィック・エンジンの制限付きメモリからビッ
トマップ・データを読み取り、ペン拡張部のグローバル
・メモリに読み込むための前処理である。ビットマップ
・データが得られると、ブロック１８４０でそれがプレ
ゼンテーション・スペースから削除され、ブロック１８
５０でプレゼンテーション・スペース資源が割振り解除
される。

【００３３】図１５に戻ると、ブロック１７００でビッ
トマップ・データを照会後、システムは、ブロック１７
１０で最適化メモリ間比較を実行し、ポインタがWindow
sのＩビームであるかどうかを確認する。１７２０で比
較の結果、同じであると判明した場合、ブロック１７８
０でポインタ・テーブル１４００に項目が追加され、ブ
ロック１７８５でその項目にＩビームとしてのフラグが
付けられ、１７９０で有効ポインタ・テーブル項目数が
増分される。ポインタ・テーブル１４００は２５０項目
を含み、ブロック１５３０で費やす探索時間を短縮する
ように構築されており、最後の有効項目が見つかった
後、探索が中断されるので、有効ポインタ項目数は慎重
に管理される。

【００３４】判断ブロック１７２０での比較の結果、偽
であると判明した場合は、ポインタに関する追加テスト
を行うためにブロック１７３０で別のルーチンが呼び出
される。このルーチンが判断ブロック１７４０で否定の
結果を報告した場合、ブロック１７５０でポインタ・テ
ーブルに項目が追加され、ブロック１７６０でその項目
に非Ｉビームとしてのフラグが付けられ、ブロック１７
７０で有効ポインタ・テーブル項目数が増分され、ブロ
ック１７７５でそのルーチンが呼出しルーチンに否定の
結果を返す。判断ブロック１７４０での比較の結果、真
であると判明した場合は、ブロック１７８０でポインタ
・テーブルに項目が追加され、ブロック１７８５でその
項目にＩビームとしてのフラグが付けられ、ブロック１
７９０で有効ポインタ・テーブル項目数が増分され、ブ
ロック１７９５でその結果が返される。

【００３５】図６を参照すると、同図には、任意のＩビ
ーム・ポインタ形状のビットマップ・アレイ５１０が示
されている。ビットマップ・アレイ５１０は、３２×３
２の２進データからなるアレイであり、Ｉビーム形状の
ペルが１で示されている。ただし、ビットマップ・アレ
イ５１０のＩビームは、９列と１４行を占有する２８個
のペルを含むことに留意されたい。さらに、そのＩビー
ムはビットマップ・アレイ５１０内の任意の位置に位置
決めされていることに留意されたい。

【００３６】図１７は、近似Ｉビーム形状、たとえば、
図６のＩビーム形状のテストの流れを示している。図１
８ないし図２１に示すようにこのルーチンおよびその補
助サブルーチンによる処理を合理化するため、ブロック
１９００でビットマップ・アレイが８ビットから３２ビ
ットの位置合せに変換される。データを再フォーマット
することにより発生する不利益は、所与の時点では３２
ビットで動作するＣＰＵ命令の使用により十二分に補正
される。図９は、ビット・アレイ５１０を８ビット６０
０から３２ビット６１０の位置合せに変換する場合を示
している。ブロック１９１０では、テスト中のポインタ
のタイプとディスプレイの解像度に応じてポインタ形状
マスクが選択される。ＶＧＡ解像度用のマスク７１０と
ＸＧＡ解像度用のマスク８１０を図１０と図１１にそれ
ぞれ示す。様々なマスクを使用すると、ポインタ形状認
識の正確さが増す。ブロック１９２０では、ブロック１
９３０でＡＮＤマスクとＯＲマスクを結合するための準
備として、ビットマップのＡＮＤマスクがその１の補数
に変換される。ポインタの形状はＡＮＤマスクまたはＯ
Ｒマスクあるいはその両方にコード化することができる
ので、ポインタ形状全体を確実に考慮に入れるために、
２つのマスクを結合する。また、ＡＮＤマスクは通常、
すべて１であり、ポインタ形状をコード化するためにゼ
ロに変化するので、正反対であるＯＲマスクのフォーマ
ットと一致するようにブロック１９２０で反転される。

【００３７】この時点でビットマップは２つのマスクか
ら１つに削減されているが、マスクと照らし合わせてポ
インタ形状をテストするため、ポインタ形状をさらに分
離しなければならない。これを実施するため、ブロック
１９４０でポインタ形状を左寄せし、ブロック１９５０
でビットマップ・アレイの下部に寄せるためのサブルー
チンが呼び出される。しかし、イメージを下寄せする前
に、システムは判断ブロック１９４５で、ポインタがブ
ランクであるかどうかを確認するためのテストを行う。
ポインタがブランクであることは珍しいことではない。
ブランクである場合、処理は停止し、ブロック１９５５
でルーチンが否定の結果を返す。左寄せおよび下寄せの
処理の結果はそれぞれ図７のビットマップ・アレイ５２
０と図８のビットマップ・アレイ５３０になる。

【００３８】ポインタのイメージは既知の位置にあるの
で、ブロック１９６０でマスク外のビットが１に設定さ
れているかどうかを判定するために別のサブルーチンが
呼び出される。わずか１つのビットでもマスク外で１に
設定されている場合、判断ブロック１９６５のテストで
不合格になり、ブロック１９８５で呼出しサブルーチン
に偽が返される。判断ブロック１９６５でいずれのビッ
トもマスク外で１に設定されていない場合、形状マスク
下に設定されているビットの数をカウントするためにブ
ロック１９７５で別のサブルーチンが呼び出される。判
断ブロック１９７５で十分な数のビットが１に設定され
ている場合、ポインタ形状はほぼＩビームであると見な
され、ブロック１９８０で真が返される。形状がＩビー
ムであるかどうかを判定するために使用するしきい値は
経験に基づいて設定され、現在、そのアルゴリズムはＶ
ＧＡ解像度の場合は１７ビットが１に設定され、ＸＧＡ
の場合は２４ビットが１に設定されていると予想する。

【００３９】次に、図１７のブロック１９４０、１９５
０、１９６０、１９７０で呼び出される４つのサブルー
チンについて詳しく検討する。ビットマップの左寄せに
ついては図１８に示す。ポインタ形状イメージは、右寄
せではなく左寄せされる。というのは、ビットマップの
走査線は必ず３２ビットの倍数でコード化しなければな
らないからである。これは、ビデオ操作を最適化し、メ
モリをビデオ・ハードウェアに直接マッピングできるよ
うにするために行われる。このため、そのイメージが２
番目の３２ビット・ワードのうちのわずか数ビットしか
使用しなくても、解像度が３２×３２ペルから６４×６
４ペルの間のビットマップは、必ず走査線当たり６４ビ
ットのデータを有することになる。このような余分なビ
ットは埋込みと呼ばれ、図１１のビットマップ・アレイ
８１０の列８２０に示されているが、アルゴリズムが右
寄せを使用する場合は、まず、ゼロの埋込みを越えてイ
メージをシフトさせなければならないはずである。これ
は時間のかかることである。３２×３２を上回る解像度
のビットマップを処理する場合、ポインタ・イメージは
通常、ビットマップの左端により接近することになる。

【００４０】図１８のブロック２０００では、走査線の
数がビットマップ・ヘッダからロードされる。次に、サ
ブルーチンはブロック２０１０〜２０５０のループに入
り、そこでブロック２０１０で各走査線の左端のビット
が１であるかどうかがテストされる。各走査線のテスト
後、判断ブロック２０２０で左端のビットがすべて０で
あるかどうかを確認するためにテストが行われる。すべ
て０である場合、ポインタ・イメージの先頭はまだ突き
止められていないので、ブロック２０３０で各走査線が
１ビットずつ左にシフトされ、ブロック２０４０でシフ
ト・カウントが増分される。判断ブロック２０５０で
は、シフトしたビットの数が走査線の数以上であるかを
確認するためにテストが行われる。このテストは、ポイ
ンタ形状がブランクの場合を見つけて、無限ループを防
止するものである。判断ブロック２０５０でシフト・カ
ウントが走査線カウントを上回る場合、サブルーチンは
ブロック２０６０で単に真を返すだけである。判断ブロ
ック２０２０で全走査線のうちの１本の左端のビットが
最終的に１を含むまで、ブロック２０３０のイメージの
左シフトが続行される。このような事態が発生すると、
このイメージは完全に左寄せされ、サブルーチンはブロ
ック２０７０で偽を返す。

【００４１】図１９は、認識アルゴリズムの次のステッ
プの流れを示し、そこで左寄せしたイメージが下寄せさ
れる。入口では、最後または最下部の走査線からテスト
が始まるように、ブロック２１００で走査線ポインタが
ビットマップ・アレイの下部に設定される。ブロック２
１００〜２１３０でループに入り、そのうちの判断ブロ
ック２１１０では各走査線の全体に非ゼロ・ビットがな
いかどうかテストされる。非ゼロ・ビットが一切見つか
らない場合、ブロック２１２０で走査線ポインタが減分
される。判断ブロック２１３０で走査線ポインタがビッ
トマップの最上部の走査線を指し示す場合、ルーチンは
ブロック２１４０で復帰する。そうではない場合、ルー
プが終了し、サブルーチンの残り半分に移行する点にポ
インタ・イメージの最下部が位置していることを意味す
る非ゼロ走査線が見つかるまで、ループが反復する。

【００４２】サブルーチンの残り半分では、イメージの
最下部にある走査線を指し示すようにブロック２１５０
でソース・ポインタが初期設定され、ブロック２１５５
でビットマップ・アレイの最下部を指し示すようにター
ゲット・ポインタが設定される。これらのポインタは、
イメージを有効に下寄せする、ビットマップのメモリ間
転送を実行するために使用する。これは、２１６５から
２１８５までの操作によって制限されるループで実施さ
れる。各走査線はブロック２１６０で１つずつ転送さ
れ、その都度、ブロック２１７５と２１８０でソース・
ポインタとターゲット・ポインタがそれぞれ減分され
る。各走査線の転送後、現行ソース・ポインタがビット
マップの最上部を指し示しているかどうかを確認するた
めに判断ブロック２１６５でテストが行われる。指し示
している場合、ビットマップ全体が転送されるように、
ソース・ポインタはブロック２１７０でビットマップの
最下部に折り返す。最終的には、判断ブロック２１８５
でターゲット・ポインタがビットマップの最上部にヒッ
トして転送の完了を意味し、ループは終了し、サブルー
チンはブロック２１９０で復帰する。

【００４３】図２０は、形状マスク外で１に設定された
ビットがないかどうか、ポインタ・イメージをテストす
る論理の流れを示している。この場合も、走査線ポイン
タは、ブロック２２００でポインタ・イメージの既知の
先頭であるアレイの最下部に設定される。形状マスク・
ポインタも、ビットマップ走査線と固定して調和するよ
うにブロック２２１０でマスク上の最下部に設定され
る。ブロック２２２０〜２２９０のループは、ブロック
２２２０でその１の補数を取り、ブロック２２３０でＡ
ＮＤ演算を使用することにより、マスク線を反転するも
のであり、判断ブロック２２４０でその関連ビットマッ
プ走査線と照らし合わせてそれをテストする。ほぼＩビ
ームである形状は、マスク外に設定されたビットを含ま
なくなる。非ゼロ・ビットが見つかった場合、サブルー
チンは２２５０で真を返し、呼出しルーチンに対して非
Ｉビーム形状を示す。見つからない場合は、判断ブロッ
ク２２６０で、ポインタがビット・アレイの最上部に達
し、テストの完了を通知するかどうかを確認するための
テストが行われる。達していない場合、走査線ポインタ
とマスク線ポインタはブロック２２８０と２２９０でそ
れぞれ減分され、ブロック２２２０に戻ってループが反
復する。判断ブロック２２６０で走査線に達している場
合、マスク外ではいずれのビットも見つかっていないの
で、サブルーチンはブロック２２７０で偽を返す。

【００４４】図２１は、認識アルゴリズムの最終作業ル
ーチンである。すべての非ゼロ・ビットが形状マスク下
にある場合は、２つの形状がぴったり一致していること
を意味することがこれまでに分かっている。最後のタス
クは、マスク下に設定されているビットをカウントし、
それがＩビームとしての資格があるかどうかを確認する
ことである。実際には、このステップでは形状マスクは
不要である。というのは、すべての非ゼロ・ビットがマ
スク内にあるからである。ループ変数を初期設定する
と、シフト・カウント、走査線カウント、ビット・カウ
ントがいずれもブロック２３００、２３０５、２３１０
でそれぞれクリアされる。次に、２つの事前定義定数で
ある非ゼロ・マスク線の数と非ゼロ・マスク列の数は、
ループ内で使用するために、ブロック２３１５と２３２
０でそれぞれロードされる。ブロック２３２５では現行
走査線ポインタがビットマップ・アレイの最下部に設定
され、次にコードは、内部ループ２３３０〜２３５０と
外部ループ２３５５〜２３７０に入る。内部ループ２３
３０〜２３５０は各非ゼロ・ビットを含む各走査線を調
査し、外部ループ２３５５〜２３７０は各走査線全体で
反復する。

【００４５】判断ブロック２３３０では、現行走査線の
左端のビットが１であるかどうかがテストされる。それ
が１である場合、ブロック２３３５でビット・カウント
が増分される。いずれの場合も、シフト・カウントはブ
ロック２３４０で必ず増分され、シフトしたビットの数
が非ゼロ列の数と等しいかどうかを確認するために判断
ブロック２３４５でテストが行われる。１ではない場
合、ブロック２３５０で走査線全体が１ビットずつ左に
シフトされ、判断ブロック２３３０に戻ってループが反
復する。判断ブロック２３４５で、シフトしたビットの
数が非ゼロ・マスク列の数と等しい場合、シフト・カウ
ントはブロック２３５５でクリアされ、次の走査線を検
査するためにブロック２３６０で走査線ポインタが減分
される。判断ブロック２３６５で、検査した走査線の数
が非ゼロ・マスク走査線の数と等しい場合、マスク下の
すべての走査線がテスト済みであり、サブルーチンはブ
ロック２３７５でカウントした非ゼロ・ビットの総数を
返す。そうではない場合、走査線カウントはブロック２
３７０で増分され、判断ブロック２３３０で内部ループ
の最上部に戻って外部ループが反復する。このようにし
て、ポインタ形状内のすべての非ゼロ・ビットがカウン
トされ、呼出しルーチンに返される。

【００４６】前述のように、有効ポインタ・テーブル１
４００の項目のカウントは慎重に管理されている。マウ
ス移動の処理中に新しいアプリケーション供給ポインタ
ＩＤが発見されると、項目がテーブルに追加される。図
２７は、もはや不要になったときに項目が除去されるよ
うにテーブルをさらに管理する方法を示している。図２
７のルーチンは、オペレーティング・システムがアプリ
ケーションを閉じるかまたはシャットダウンするたびに
呼び出される。入口では、項目が存在するかどうかを確
認するために判断ブロック２８００で検査が行われる。
存在しない場合、クリーンアップすべきものは一切ない
ので、ルーチンはブロック２８８０で終了する。判断ブ
ロック２８００でテーブルが空ではない場合、ブロック
２８１０でシャットダウン中のアプリケーションのプロ
セスＩＤが照会される。ブロック２８２０では有効項目
の数がロードされ、ブロック２８３０ではテーブル・ポ
インタがポインタ・テーブル１４００内の最初の項目に
設定される。次に、判断ブロック２８４０でループに入
り、そこで各項目が有効であるかどうかを確認するため
にその項目がテストされる。それが有効である場合、そ
れがシャットダウン中のアプリケーションに属すかどう
かを確認するために、判断ブロックで項目がテストされ
る。属す場合、ブロック２８５５で有効項目のカウント
が減分され、ブロック２８６０でその項目がテーブルか
ら除去される。判断２８５０のテスト結果にかかわら
ず、ブロック２８６５でループ・カウントが減分され、
ブロック２８７０でゼロかどうかがテストされる。ゼロ
ではない場合、ポインタ・テーブル１４００にまだいく
つか有効な項目があるので、テーブル・ポインタはブロ
ック２８７５で増分され、ループは判断ブロック２８４
０に戻って反復する。判断ブロック２８４０で非有効テ
ーブル項目が見つかった場合、その項目は無視され、ブ
ロック２８７５でテーブル・ポインタが増分され、やは
りループが反復する。最終的に、すべての有効項目が見
つかり、ブロック２８７０でループ・カウントがゼロに
なると、ループは終了し、ルーチンはブロック２８８０
で終了する。ポインタ・テーブル１４００は２５０項目
を含むように構築されているが、ほとんどの実際の場合
には最小数の項目しか検査されない。

【００４７】図２８を参照すると、同図には、Windows
（ＴＭ）の砂時計ポインタ用のビットマップ２４１０が
示されている。図２８の砂時計ポインタ形状を検査する
と、その砂時計が「ウェストが細い」形状であり、マス
クを有効にするためにも、それはウェストが細くなけれ
ばならないはずであることが分かる。マスクのウェスト
を太くすればするほど、形状がより四角形に近くなり、
その結果、認識精度が低下するはずである。また、図３
１および図３２に見られるように、マスクとポインタ形
状の位置合せ不良が発生すると、その結果、砂時計ポイ
ンタ形状を認識できなくなる可能性がある。図３１は砂
時計ポインタへの微細形状マスク用のビット・アレイ２
６１０を示し、図３２は砂時計ポインタ２６２０用のビ
ット・アレイを示している。砂時計形状２６２０は依然
として砂時計として認識可能であるが、短いので、走査
線中心点２６３０に示すようにウェスト位置が低くなっ
ている。したがって、砂時計ポインタ２６２０の幅広の
最上部は走査線中心点２６４０に示すマスク２６１０の
ウェストと一致し、それにより、認識アルゴリズムはマ
スク外の非ゼロ・ビットのために不合格になるはずであ
る。

【００４８】形状マスクに関する潜在的な問題は、図３
２の砂時計マスクのようにマスクが大きくなればなるほ
ど、非砂時計形状がマスク下に入る可能性が高くなるこ
とである。１５０程度の高いビット・カウントしきい値
は効果的なフィルタ処理をもたらしうるが、必ずしもす
べての場合に有効なわけではない。砂時計のように珍し
く、しかもビットしきい値が高い場合でも、図３４のビ
ットマップ２８１０のクィーン・ポインタ形状などのそ
の他の形状は両方のテストを通過するはずである。クィ
ーン・ポインタを使用中アプリケーションと誤解する
と、重大な使用可能度の問題が発生する恐れがある。

【００４９】このような問題に対処するため、第２の実
施例は、図２９および図３０にそれぞれ示す粗大マスク
２５１０と微細マスク２５２０を使用する、変更済みで
はあるがわずかに長いアルゴリズムを使用し、図３３に
示すようにポインタ・イメージの対称の考慮に入れるも
のである。

【００５０】図３３を参照すると、砂時計ポインタ・イ
メージ２７１０がその走査線中心点２７１５とその列中
心点２７２０の両方について対称であることが分かるだ
ろう。走査線中心点２７１５と列中心点２７２０は、ポ
インタ・イメージ２７１０を４つの４分割部分に分割す
る。

【００５１】図２２は、本発明の第２の実施例のわずか
に変更した論理を示している。図２２に入ると、ポイン
タ形状はすでに左寄せおよび下寄せされており、ブロッ
ク２４００で粗大マスク外に非ゼロ・ビットがあるかど
うかのテストが行われる。粗大マスクは、砂時計の設計
においては相当な破格を許しながら、大部分の非砂時計
ポインタを除去するように設計されている。判断ブロッ
ク２４１０で粗大マスク外にビットが設定されている場
合、処理は停止され、ブロック２４９５で偽が返され
る。判断ブロック２４１０でビットが一切設定されてい
ない場合、ポインタ形状はブロック２４２０で微細マス
クの上にセンタリングされる。

【００５２】図２３は、図３１および図３２に示す走査
線不一致の問題を解消するためのセンタリング技法の流
れを示している。２つのループに入るが、そこでシステ
ムはブロック２５００で非ゼロ・ポインタ走査線の数を
カウントし、ブロック２５１０で非ゼロ・ポインタ列の
数をカウントする。その結果得られる非ゼロの走査線と
列のカウントをブロック２５２０で２で割り、ポインタ
形状の中心点を計算する。また、微細形状マスクの中心
点も、このような２つの既知の定数を取り、ブロック２
５３０で２で割ることによって計算される。次に、２つ
の被比較数の２つの中心点間の差を求めるため、ブロッ
ク２５４０で微細ブロックの中心点ＸおよびＹからポイ
ンタ形状の中心点ＸおよびＹを引く。ただし、ポインタ
形状は微細マスクより大きくはならないので、計算した
ＸおよびＹの変位はゼロまたは正数になりうるが、けっ
して負数にはならないことに留意されたい。

【００５３】列（Ｘ）と走査線（Ｙ）の変位が分かる
と、微細マスクは、ブロック２５５０で列変位と等しい
量だけ左寄せされ、ブロック２５６０で走査線変位と等
しい量だけ下寄せされる。このような操作の正味の影響
は、ポインタ形状の中心点の上に微細マスクの中心点を
重ねることである。ポインタ形状と微細マスクを重ねる
ことにより、マスクはより小さくよりぴったりの輪郭を
備えたシルエットを有することができ、それにより、認
識精度が高まる。ルーチンは、対称テストで使用すべき
ポインタの中心点を渡す際にブロック２５７０で呼出し
側に戻る。

【００５４】もう一度図２２を参照すると、ブロック２
４５０でシステムは、４分割部分によって微細マスク下
に設定されたビットをカウントするためのサブルーチン
を呼び出す。図３３は、ポインタ・イメージの中心点を
原点として共用する４分割部分の順序を示している。図
２５は、４分割部分によって微細マスク下のビットをカ
ウントするサブルーチンである。図２５のサブルーチン
は、マスク下のビットをカウントする前述の第１の実施
例の図２１のサブルーチンと同じであるが、各４分割部
分ごとに個別のビット・カウンタが管理される。ブロッ
ク２７０５では、４つの４分割ビット・カウンタがすべ
てクリアされる。ビット・カウントは図２１のように内
部ループおよび外部ループによって始まるが、判断ブロ
ック２７３０で非ゼロ・ビットが検出され、ブロック２
７３２で４分割部分カウントを増分するためのサブルー
チンが呼び出される。

【００５５】図２６は、どの４分割部分にビットが配置
されているかを判定するための論理の流れを示してい
る。このサブルーチンへの入口では、列カウントと走査
線カウントが偶数か奇数かを確認するために判断ブロッ
ク２７７１、２７７２、２７７３で３通りのテストが行
われる。対称かどうかをテストするため、イメージは対
称の半分ずつに分割しなければならず、列または走査線
が奇数の場合は、中央の列または走査線が対称軸になる
ので、この列または走査線は無視しなければならない。
列または走査線が偶数の場合、実際の対称線は２つの列
または行同士の間に入り、計算した中心点の列および行
はそれぞれ４分割部分３と４または３と２の一部にな
る。列と走査線のカウントの関係を確立した後、２７０
１〜２７０４、２７０６〜２７０９、２７１６〜２７１
９、２７２１〜２７２４の操作は、新たに見つかったビ
ットがどの４分割部分に入るかを判定するためのふるい
として機能する。列または走査線のカウントが奇数の場
合、対称軸上で見つかったビットはカウントされず、論
理はブロック２７６３で復帰するだけである。操作２７
５１〜２７５４は適切な４分割部分カウントを増分し、
サブルーチンは２７６３で復帰する。

【００５６】図２６のサブルーチンから復帰すると、図
２５のブロック２７３５で非ゼロ・ビットの総数が増分
される。判断ブロック２７６５ですべての走査線が検査
されると、外部ループは終了し、すべてのビット・カウ
ントはブロック２７７５で呼出しルーチンに返される。

【００５７】もう一度図２２に戻ると、判断ブロック２
４６０でのビット・カウントのテストは、経験に基づい
て１５０ビットに設定されている、砂時計形状に適した
しきい値を使用する。テストで不合格になると、ブロッ
ク２４９５で否定の結果が返される。そうではない場
合、ブロック２４７０でポインタ・イメージが対称かど
うか検査される。

【００５８】図２４は、対称検査サブルーチンの論理の
流れを示している。ブロック２６００では、この特定の
ポインタ形状について対称検査が必要かどうかを判定す
るために、図３０の砂時計用の微細形状マスクに照会す
る。判断ブロック２６１０で検査が一切不要である場
合、システムは単にブロック２６８０で対称に関する肯
定表示を呼出し側に返すだけである。砂時計の場合、列
と走査線両方の対称が必要なので、判断ブロック２６２
０の操作の結果、真であると判明し、論理はブロック２
６３０に移行し、そこで列対称線の両側の列ビット・カ
ウントがまとめて加算される。この２通りのカウントが
比較され、判断ブロック２６４０でその差が３ペルを上
回る場合、両側は非対称であると見なされ、ブロック２
６９０でサブルーチンは否定表示を返す。そうではない
場合、判断ブロック２６５０で走査線対称も検査しなけ
ればならないかどうかを確認するために検査が行われ
る。検査する必要がない場合、サブルーチンはブロック
２６８０で肯定を返して終了する。そうではない場合、
操作２６６０が実行され、そこで走査線対称線の両側の
４分割部分ビット・カウントが加算される。判断ブロッ
ク２６７０でこの２つのカウントの差が３ビットを上回
る場合、ポインタは垂直軸に対して非対称であると見な
され、ブロック２６９０で否定の結果が返される。そう
ではない場合、サブルーチンはブロック２６８０で呼出
しルーチンに真を返す。図３４のクィーン・ポインタを
テストした場合、そのポインタは水平軸に対する対称テ
ストで不合格になるはずである。

【００５９】もう一度図２２を参照すると、呼び出され
たサブルーチンの復帰の処理後、判断ブロック２４８０
で必要な対称についてテストが行われ、それに応じてブ
ロック２４９０または２４９５で真または偽の表示がそ
れぞれ返される。

【００６０】この変更により、第２のマスクを処理しな
ければならず、２つのイメージを重ね、対称を検査する
ことから、わずかなパフォーマンス上の不利益が発生す
るが、この不利益は、認識アルゴリズムの信頼性の向上
によって軽減される。また、この不利益は、ポインタ・
タイプによって条件づけられた対称検査を使用すること
により、さらに軽減される。

【００６１】上記の説明により、本発明は、ポインタ形
状の認識を十分実施できるようになっていることが分か
るだろう。テキスト・ポインタ形状がＩビームの形状に
近くなければならないとすると、本発明は、ポインタ形
状がＩビームの視覚的外観を有するかどうかを判定する
ために光学認識を実行するために、ポインタのビットマ
ップを検査する。ポインタ形状は、Ｉビームのサイズ、
形状、特徴の点で相当な変形が可能なＩビームのマスク
と照らし合わせてテストされるが、Ｉビームの妥当な模
写ではない形状は拒否される。

【００６２】本発明では、数多くの変数を考慮してい
る。たとえば、ＶＧＡ、ＳＶＧＡ、ＸＧＡ解像度のディ
スプレイ・ドライバなどの複数のディスプレイ解像度
は、それぞれ異なるポインタ・ビットマップ・サイズ
（たとえば、３２×３２、４０×４０）を備えている可
能性がある。ポインタ解像度の差は、ポインタ・サイズ
に基づいて形状マスクを選択することにより、認識アル
ゴリズムにとって透過なものになる。本発明は、マウス
・ポインタにカラーを使用しても影響を受けない。カラ
ー変動は無視され、ポインタはモノクロの場合と同じよ
うに処理される。

【００６３】ポインタ形状は標準的なビットマップでは
ない。ポインタ・ビットマップは、実際には、所望のポ
インタ形状を除いて透過なポインタ形状イメージを生成
するために結合するカラー・インデックス値のアレイと
ともに、ＸＯＲマスクとＡＮＤマスクという２つのマス
クから構成される。ポインタ形状は、ＸＯＲマスクまた
はＡＮＤマスクあるいはその両方にコード化することが
できる。ＸＯＲマスクは、通常、０であり、その形状
は、０のビットを１のビットに変換することによってコ
ード化される。これに対して、ＡＮＤマスクは、通常、
すべて１であり、形状をコード化するために０に変換さ
れる。

【００６４】３２×３２ペルのポインタ形状は１０２４
ペルを含み、そのうちの１８程度は形状の定義に使用す
ることができる。ポインタの設計者は、ビットマップの
境界内であればどこでも自由にポインタをコード化する
ことができる。この問題を回避するため、本発明では、
ポインタ・イメージをビットマップ内に配置し、次にそ
のイメージをビットマップの左下に再配置する。

【００６５】本発明では、独創的なＩビーム形状のため
に相当な破格を認めるが、Ｉビーム以外の形状は相当な
確実さで拒否する。正確さを高めるため、一部のポイン
タ形状では、テスト中のポインタ形状がより高い解像度
のマスクと正確に位置合せされるような、余分な操作が
認識プロセスで必要な場合もある。さらに、垂直軸また
は水平軸あるいはその両方に対して対称なポインタ形状
についてより厳重なフィルタ処理を行うため、システム
は、テスト中のポインタ形状にこのような対称があるか
どうか探索する場合もある。

【００６６】ビットマップは、デバイス・ドライバ・レ
ベルの高速転送に対応できるように構築されている。し
たがって、左上端のビットは最終的に２進フォーマット
の左下端のビットになる。さらに、ビットマップは、イ
メージ内で連続する２つのビットがバイト境界を横切る
のであれば、１５ビットで分離できることを意味するバ
イト・アレイである。これはいずれも、処理前にビット
マップについて重大なビット操作を行う必要がある。２
つの連続ビットは、ビットマップ・データを８ビット・
データではなく３２ビット・データとして扱うときに不
連続になる可能性がある。したがって、本発明では、ビ
ットマップ・データを８ビットから３２ビットの位置合
せに再フォーマットする。

【００６７】ペンベース・システムには、すべてのアプ
リケーション定義ポインタについてマウス移動またはペ
ンダウン事象を基礎とする光学認識など、計算上の集中
操作を可能にしないような非常に厳重なパフォーマンス
要件がある。アプリケーション定義のポインタをテキス
トまたは非テキスト・ポインタ形状として分類するプロ
セスは、システムの応答性またはパフォーマンスに対し
て識別できるほどの影響を及ぼさない程度まで最適化さ
れる。

【００６８】本発明の好ましい実施例ではテキスト・ウ
ィンドウ域を非テキスト・ウィンドウ域から区別するた
めにＩビーム・ポインタ形状の光学認識を使用するが、
本発明は、ポインティング・デバイスがアプリケーショ
ンを移動するときに、ユーザが行うように、前記アプリ
ケーションの特定の状態を把握することによりオペレー
ティング・システムが利益を得るような、どのようなタ
スクでも実施することができる。アプリケーションが現
在使用中であり、ユーザ入力を処理できない時期を判定
するために、砂時計または時計の認識を使用する、第２
の実施例が記載されている。

【００６９】２通りの特定の実施例について開示してき
たが、本発明の精神および範囲を逸脱せずにこのような
特定の実施例に対して変更を加えることができること
は、当業者であれば分かるだろう。さらに、このような
実施例は、例示のみを目的とするものであり、本発明の
範囲を制限したり、特許請求の範囲を狭めるためのもの
であると解釈してはならない。

【００７０】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００７１】（１）システムＩビーム・ポインタＩＤを
有するシステムＩビーム・ポインタを有するペンベース
・コンピュータ・システムにおいて、ポインタの位置が
文字データを受け入れることができることを判定する方
法であって、前記ポインタがポインタＩＤを有し、前記
方法が、前記ポインタＩＤが前記システムＩビーム・ポ
インタＩＤと等しいかどうかを判定するステップと、前
記ポインタＩＤが前記システムＩビーム・ポインタＩＤ
と等しくない場合に、前記ポインタＩＤがポインタＩＤ
のテーブルに入っていて、Ｉビーム・ポインタであると
いうフラグが前記テーブル内に付いているかどうかを判
定するステップと、前記ポインタＩＤが前記ポインタＩ
Ｄのテーブルに入っていない場合に、前記ポインタがＩ
ビーム形状を有するかどうかを判定するステップとを含
むことを特徴とする方法。 （２）前記ポインタＩＤが前記システムＩビーム・ポイ
ンタＩＤと等しい場合に、前記ポインタをペン形ポイン
タに変更するステップをさらに含むことを特徴とする、
上記（１）に記載の方法。 （３）前記ポインタＩＤが前記ポインタＩＤのテーブル
に入っていて、Ｉビーム・ポインタであるというフラグ
が前記テーブル内に付いている場合に、前記ポインタを
ペン形ポインタに変更するステップをさらに含むことを
特徴とする、上記（１）に記載の方法。 （４）前記ポインタがＩビーム形状を有すると判定され
た場合に、前記ポインタＩＤを前記ポインタＩＤのテー
ブルに追加し、Ｉビーム・ポインタであるというフラグ
を前記ポインタＩＤに付けるステップをさらに含むこと
を特徴とする、上記（１）に記載の方法。 （５）前記ポインタがＩビーム形状を有すると判定され
た場合に、前記ポインタをペン形ポインタに変更するス
テップをさらに含むことを特徴とする、上記（１）に記
載の方法。 （６）前記ポインタがＩビーム形状を有するかどうかを
判定する前記ステップが、前記ポインタを事前定義Ｉビ
ーム・ポインタ形マスクと比較するステップを含むこと
を特徴とする、上記（１）に記載の方法。 （７）前記ポインタがＩビーム形状を有するかどうかを
判定する前記ステップが、前記ポインタのすべての画素
が前記Ｉビーム・ポインタ形マスク内に入っている場合
に、前記ポインタを構成する画素の数をカウントするス
テップをさらに含むことを特徴とする、上記（６）に記
載の方法。 （８）前記ポインタを構成する画素の数が所定のしきい
値を上回る場合に、前記ポインタをペン形ポインタに変
更するステップをさらに含むことを特徴とする、上記
（７）に記載の方法。 （９）前記ポインタがビット・マップ内にあり、前記方
法が、前記ビット・マップを８ビットから３２ビットの
位置合せに変換するステップを含むことを特徴とする、
上記（６）に記載の方法。 （１０）前記ポインタがビット・マップ内にあり、前記
方法が、前記ビット・マップ内で前記ポインタを左寄せ
し、下寄せするステップを含むことを特徴とする、上記
（６）に記載の方法。 （１１）非システム・ポインタがシステム・ポインタと
同等であることを判定する方法において、前記非システ
ム・ポインタがポインタＩＤを有し、前記方法が、前記
ポインタＩＤがポインタＩＤのテーブルに入っていて、
前記システム・ポインタと同等であるというフラグが前
記テーブル内に付いているかどうかを判定するステップ
と、前記ポインタＩＤが前記ポインタＩＤのテーブルに
入っていない場合に、前記非システム・ポインタの形状
に基づいて、前記非システム・ポインタが前記システム
・ポインタと同等であるかどうかを判定するステップと
を含むことを特徴とする方法。 （１２）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であると判定された場合
に、前記ポインタＩＤを前記ポインタＩＤのテーブルに
追加し、前記システム・ポインタと同等であるというフ
ラグを前記ポインタＩＤに付けるステップをさらに含む
ことを特徴とする、上記（１１）に記載の方法。 （１３）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタを事前定
義マスクと比較するステップを含むことを特徴とする、
上記（１１）に記載の方法。 （１４）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタのすべて
の画素が前記マスク内に入る場合に、前記非システム・
ポインタを構成する画素の数をカウントするステップを
さらに含むことを特徴とする、上記（１３）に記載の方
法。 （１５）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタを構成す
る画素の数が所定のしきい値を上回る場合に、前記非シ
ステム・ポインタが所定の対称条件を満足するかどうか
を判定するステップをさらに含むことを特徴とする、上
記（１４）に記載の方法。 （１６）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタを事前定
義粗大マスクと比較するステップを含むことを特徴とす
る、上記（１１）に記載の方法。 （１７）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタのすべて
の画素が前記粗大マスク内に入る場合に、前記非システ
ム・ポインタを事前定義微細マスクと比較するステップ
を含むことを特徴とする、上記（１６）に記載の方法。 （１８）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタのすべて
の画素が前記微細マスク内に入る場合に、前記非システ
ム・ポインタを構成する画素の数をカウントするステッ
プをさらに含むことを特徴とする、上記（１７）に記載
の方法。 （１９）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記ステップが、前記非システム・ポインタを構成す
る画素の数が所定のしきい値を上回る場合に、前記非シ
ステム・ポインタが所定の対称条件を満足するかどうか
を判定するステップをさらに含むことを特徴とする、上
記（１８）に記載の方法。 （２０）前記非システム・ポインタが砂時計ポインタで
あることを特徴とする、上記（１１）に記載の方法。 （２１）前記非システム・ポインタがＩビーム・ポイン
タであることを特徴とする、上記（１１）に記載の方
法。 （２２）ディスプレイと、前記ディスプレイ上に表示可
能なシステムＩビーム・ポインタとを有するペンベース
・コンピュータ・システムにおいて、前記システムＩビ
ーム・ポインタがシステムＩビーム・ポインタＩＤを有
し、ポインタによって示される前記ディスプレイ上の位
置が文字データを受け入れることができることを判定す
るシステムであって、前記ポインタがポインタＩＤを有
し、前記システムが、前記ポインタＩＤが前記システム
Ｉビーム・ポインタＩＤと等しいかどうかを判定する手
段と、前記ポインタＩＤが前記システムＩビーム・ポイ
ンタＩＤと等しくない場合に、前記ポインタＩＤがポイ
ンタＩＤのテーブルに入っていて、Ｉビーム・ポインタ
であるというフラグが前記テーブル内に付いているかど
うかを判定する手段と、前記ポインタＩＤが前記ポイン
タＩＤのテーブルに入っていない場合に、前記ポインタ
がＩビーム形状を有するかどうかを判定する手段とを含
むことを特徴とするシステム。 （２３）前記ポインタがＩビーム形状を有すると判定さ
れた場合に、前記ポインタＩＤを前記ポインタＩＤのテ
ーブルに追加し、Ｉビーム・ポインタであるというフラ
グを前記ポインタＩＤに付ける手段をさらに含むことを
特徴とする、上記（２２）に記載のシステム。 （２４）前記ポインタがＩビーム形状を有するかどうか
を判定する手段が、前記ポインタを事前定義Ｉビーム・
ポインタ形マスクと比較する手段を含むことを特徴とす
る、上記（２２）に記載のシステム。 （２５）前記ポインタがＩビーム形状を有するかどうか
を判定する前記手段が、前記ポインタのすべての画素が
前記Ｉビーム・ポインタ形マスク内に入っている場合
に、前記ポインタを構成する画素の数をカウントする手
段をさらに含むことを特徴とする、上記（２４）に記載
のシステム。 （２６）ディスプレイを有するコンピュータ・システム
において、非システム・ポインタがシステム・ポインタ
と同等であることを判定するシステムであって、前記非
システム・ポインタがポインタＩＤを有し、前記システ
ムが、前記ポインタＩＤがポインタＩＤのテーブルに入
っていて、前記システム・ポインタと同等であるという
フラグが前記テーブル内に付いているかどうかを判定す
る手段と、前記ポインタＩＤが前記ポインタＩＤのテー
ブルに入っていない場合に、前記非システム・ポインタ
の形状に基づいて、前記非システム・ポインタが前記シ
ステム・ポインタと同等であるかどうかを判定する手段
とを含むことを特徴とするシステム。 （２７）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であると判定された場合
に、前記ポインタＩＤを前記ポインタＩＤのテーブルに
追加し、前記システム・ポインタと同等であるというフ
ラグを前記ポインタＩＤに付ける手段を含むことを特徴
とする、上記（２６）に記載のシステム。 （２８）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタを事前定義マ
スクと比較する手段を含むことを特徴とする、上記（２
６）に記載のシステム。 （２９）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタのすべての画
素が前記マスク内に入る場合に、前記非システム・ポイ
ンタを構成する画素の数をカウントする手段を含むこと
を特徴とする、上記（２８）に記載のシステム。 （３０）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタを構成する画
素の数が所定のしきい値を上回る場合に、前記非システ
ム・ポインタが所定の対称条件を満足するかどうかを判
定する手段を含むことを特徴とする、上記（２９）に記
載のシステム。 （３１）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタを事前定義粗
大マスクと比較する手段を含むことを特徴とする、上記
（２６）に記載のシステム。 （３２）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタのすべての画
素が前記粗大マスク内に入る場合に、前記非システム・
ポインタを事前定義微細マスクと比較する手段を含むこ
とを特徴とする、上記（３１）に記載のシステム。 （３３）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタのすべての画
素が前記微細マスク内に入る場合に、前記非システム・
ポインタを構成する画素の数をカウントする手段を含む
ことを特徴とする、上記（３２）に記載のシステム。 （３４）形状に基づいて、前記非システム・ポインタが
前記システム・ポインタと同等であるかどうかを判定す
る前記手段が、前記非システム・ポインタを構成する画
素の数が所定のしきい値を上回る場合に、前記非システ
ム・ポインタが所定の対称条件を満足するかどうかを判
定する手段を含むことを特徴とする、上記（３３）に記
載のシステム。 （３５）前記非システム・ポインタが砂時計ポインタで
あることを特徴とする、上記（２６）に記載のシステ
ム。 （３６）前記非システム・ポインタがＩビーム・ポイン
タであることを特徴とする、上記（２６）に記載のシス
テム。

【図面の簡単な説明】

【図１】本発明によるシステムのハードウェア・ブロッ
ク図である。

【図２】本発明の主要ソフトウェア構成要素のアーキテ
クチャ図である。

【図３】Ｉビーム・ポインタ形状を表示する編集可能テ
キスト・ウィンドウの絵画表現である。

【図４】ペン・ポインタ形状を表示する編集可能テキス
ト・ウィンドウの絵画表現である。

【図５】様々なＩビーム・ポインタを示す絵画表現であ
る。

【図６】ポインタ・イメージに見られるようにＩビーム
・ポインタを示す図である。

【図７】左寄せイメージに見られるようにＩビーム・ポ
インタを示す図である。

【図８】左下寄せイメージに見られるようにＩビーム・
ポインタを示す図である。

【図９】８ビット・データと３２ビット・データの両方
としてフォーマットされたビットマップを示す図であ
る。

【図１０】ＶＧＡ表示解像度用のＩビーム・ポインタ形
状マスクを示す図である。

【図１１】ＸＧＡ表示解像度用のＩビーム・ポインタ形
状マスクを示す図である。

【図１２】本発明によるポインタ・テーブルの図であ
る。

【図１３】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１４】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１５】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１６】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１７】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１８】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図１９】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図２０】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図２１】本発明のＩビーム・ポインタ形状認識方法お
よびシステムの好ましいソフトウェア実施態様の流れ図
である。

【図２２】アプリケーションが使用中または使用不能状
態になっている場合を判定するために砂時計ポインタ形
状認識が実行される、本発明の代替実施例の好ましいソ
フトウェア実施態様の流れ図である。

【図２３】アプリケーションが使用中または使用不能状
態になっている場合を判定するために砂時計ポインタ形
状認識が実行される、本発明の代替実施例の好ましいソ
フトウェア実施態様の流れ図である。

【図２４】アプリケーションが使用中または使用不能状
態になっている場合を判定するために砂時計ポインタ形
状認識が実行される、本発明の代替実施例の好ましいソ
フトウェア実施態様の流れ図である。

【図２５】アプリケーションが使用中または使用不能状
態になっている場合を判定するために砂時計ポインタ形
状認識が実行される、本発明の代替実施例の好ましいソ
フトウェア実施態様の流れ図である。

【図２６】アプリケーションが使用中または使用不能状
態になっている場合を判定するために砂時計ポインタ形
状認識が実行される、本発明の代替実施例の好ましいソ
フトウェア実施態様の流れ図である。

【図２７】アプリケーションがシャットダウンされたと
きにポインタ項目がポインタ・テーブルから除去される
場合の流れ図である。

【図２８】Windows（ＴＭ）の砂時計による「アプリケ
ーション使用中」ポインタ形状の絵画表現である。

【図２９】砂時計ポインタ形状用の粗大マスクを表す図
である。

【図３０】砂時計ポインタ形状用の微細マスクを表す図
である。

【図３１】砂時計ポインタ・イメージと微細マスクとの
位置合せ不良を示す図である。

【図３２】砂時計ポインタ・イメージと微細マスクとの
位置合せ不良を示す図である。

【図３３】砂時計ポインタ形状の対称線および４分割部
分を示す図である。

【図３４】チェス・プログラム・アプリケーションのク
ィーン・ポインタ形状を示す図である。

【符号の説明】

１０ パーソナル・コンピュータ・システム １１ プロセッサ １３ ランダム・アクセス・メモリ １５ 中央演算処理装置（ＣＰＵ） １７ ハード・ディスク記憶装置 １９ フロッピー・ディスク装置 ２１ ディスケット ２３ ディスプレイ ２５ キーボード ２７ マウス ２９ ペンまたはスタイラス ３１ プリンタ

Claims (36)

【特許請求の範囲】
1. 【請求項１】システムＩビーム・ポインタＩＤを有する
   システムＩビーム・ポインタを有するペンベース・コン
   ピュータ・システムにおいて、ポインタの位置が文字デ
   ータを受け入れることができることを判定する方法であ
   って、前記ポインタがポインタＩＤを有し、前記方法
   が、 前記ポインタＩＤが前記システムＩビーム・ポインタＩ
   Ｄと等しいかどうかを判定するステップと、 前記ポインタＩＤが前記システムＩビーム・ポインタＩ
   Ｄと等しくない場合に、前記ポインタＩＤがポインタＩ
   Ｄのテーブルに入っていて、Ｉビーム・ポインタである
   というフラグが前記テーブル内に付いているかどうかを
   判定するステップと、 前記ポインタＩＤが前記ポインタＩＤのテーブルに入っ
   ていない場合に、前記ポインタがＩビーム形状を有する
   かどうかを判定するステップとを含むことを特徴とする
   方法。
2. 【請求項２】前記ポインタＩＤが前記システムＩビーム
   ・ポインタＩＤと等しい場合に、前記ポインタをペン形
   ポインタに変更するステップをさらに含むことを特徴と
   する、請求項１に記載の方法。
3. 【請求項３】前記ポインタＩＤが前記ポインタＩＤのテ
   ーブルに入っていて、Ｉビーム・ポインタであるという
   フラグが前記テーブル内に付いている場合に、前記ポイ
   ンタをペン形ポインタに変更するステップをさらに含む
   ことを特徴とする、請求項１に記載の方法。
4. 【請求項４】前記ポインタがＩビーム形状を有すると判
   定された場合に、前記ポインタＩＤを前記ポインタＩＤ
   のテーブルに追加し、Ｉビーム・ポインタであるという
   フラグを前記ポインタＩＤに付けるステップをさらに含
   むことを特徴とする、請求項１に記載の方法。
5. 【請求項５】前記ポインタがＩビーム形状を有すると判
   定された場合に、前記ポインタをペン形ポインタに変更
   するステップをさらに含むことを特徴とする、請求項１
   に記載の方法。
6. 【請求項６】前記ポインタがＩビーム形状を有するかど
   うかを判定する前記ステップが、 前記ポインタを事前定義Ｉビーム・ポインタ形マスクと
   比較するステップを含むことを特徴とする、請求項１に
   記載の方法。
7. 【請求項７】前記ポインタがＩビーム形状を有するかど
   うかを判定する前記ステップが、 前記ポインタのすべての画素が前記Ｉビーム・ポインタ
   形マスク内に入っている場合に、前記ポインタを構成す
   る画素の数をカウントするステップをさらに含むことを
   特徴とする、請求項６に記載の方法。
8. 【請求項８】前記ポインタを構成する画素の数が所定の
   しきい値を上回る場合に、前記ポインタをペン形ポイン
   タに変更するステップをさらに含むことを特徴とする、
   請求項７に記載の方法。
9. 【請求項９】前記ポインタがビット・マップ内にあり、
   前記方法が、 前記ビット・マップを８ビットから３２ビットの位置合
   せに変換するステップを含むことを特徴とする、請求項
   ６に記載の方法。
10. 【請求項１０】前記ポインタがビット・マップ内にあ
    り、前記方法が、 前記ビット・マップ内で前記ポインタを左寄せし、下寄
    せするステップを含むことを特徴とする、請求項６に記
    載の方法。
11. 【請求項１１】非システム・ポインタがシステム・ポイ
    ンタと同等であることを判定する方法において、前記非
    システム・ポインタがポインタＩＤを有し、前記方法
    が、 前記ポインタＩＤがポインタＩＤのテーブルに入ってい
    て、前記システム・ポインタと同等であるというフラグ
    が前記テーブル内に付いているかどうかを判定するステ
    ップと、 前記ポインタＩＤが前記ポインタＩＤのテーブルに入っ
    ていない場合に、前記非システム・ポインタの形状に基
    づいて、前記非システム・ポインタが前記システム・ポ
    インタと同等であるかどうかを判定するステップとを含
    むことを特徴とする方法。
12. 【請求項１２】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であると判定され
    た場合に、前記ポインタＩＤを前記ポインタＩＤのテー
    ブルに追加し、前記システム・ポインタと同等であると
    いうフラグを前記ポインタＩＤに付けるステップをさら
    に含むことを特徴とする、請求項１１に記載の方法。
13. 【請求項１３】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタを事前定義マスクと比較する
    ステップを含むことを特徴とする、請求項１１に記載の
    方法。
14. 【請求項１４】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタのすべての画素が前記マスク
    内に入る場合に、前記非システム・ポインタを構成する
    画素の数をカウントするステップをさらに含むことを特
    徴とする、請求項１３に記載の方法。
15. 【請求項１５】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタを構成する画素の数が所定の
    しきい値を上回る場合に、前記非システム・ポインタが
    所定の対称条件を満足するかどうかを判定するステップ
    をさらに含むことを特徴とする、請求項１４に記載の方
    法。
16. 【請求項１６】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタを事前定義粗大マスクと比較
    するステップを含むことを特徴とする、請求項１１に記
    載の方法。
17. 【請求項１７】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタのすべての画素が前記粗大マ
    スク内に入る場合に、前記非システム・ポインタを事前
    定義微細マスクと比較するステップを含むことを特徴と
    する、請求項１６に記載の方法。
18. 【請求項１８】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタのすべての画素が前記微細マ
    スク内に入る場合に、前記非システム・ポインタを構成
    する画素の数をカウントするステップをさらに含むこと
    を特徴とする、請求項１７に記載の方法。
19. 【請求項１９】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記ステップが、 前記非システム・ポインタを構成する画素の数が所定の
    しきい値を上回る場合に、前記非システム・ポインタが
    所定の対称条件を満足するかどうかを判定するステップ
    をさらに含むことを特徴とする、請求項１８に記載の方
    法。
20. 【請求項２０】前記非システム・ポインタが砂時計ポイ
    ンタであることを特徴とする、請求項１１に記載の方
    法。
21. 【請求項２１】前記非システム・ポインタがＩビーム・
    ポインタであることを特徴とする、請求項１１に記載の
    方法。
22. 【請求項２２】ディスプレイと、前記ディスプレイ上に
    表示可能なシステムＩビーム・ポインタとを有するペン
    ベース・コンピュータ・システムにおいて、前記システ
    ムＩビーム・ポインタがシステムＩビーム・ポインタＩ
    Ｄを有し、ポインタによって示される前記ディスプレイ
    上の位置が文字データを受け入れることができることを
    判定するシステムであって、前記ポインタがポインタＩ
    Ｄを有し、前記システムが、 前記ポインタＩＤが前記システムＩビーム・ポインタＩ
    Ｄと等しいかどうかを判定する手段と、 前記ポインタＩＤが前記システムＩビーム・ポインタＩ
    Ｄと等しくない場合に、前記ポインタＩＤがポインタＩ
    Ｄのテーブルに入っていて、Ｉビーム・ポインタである
    というフラグが前記テーブル内に付いているかどうかを
    判定する手段と、 前記ポインタＩＤが前記ポインタＩＤのテーブルに入っ
    ていない場合に、前記ポインタがＩビーム形状を有する
    かどうかを判定する手段とを含むことを特徴とするシス
    テム。
23. 【請求項２３】前記ポインタがＩビーム形状を有すると
    判定された場合に、前記ポインタＩＤを前記ポインタＩ
    Ｄのテーブルに追加し、Ｉビーム・ポインタであるとい
    うフラグを前記ポインタＩＤに付ける手段をさらに含む
    ことを特徴とする、請求項２２に記載のシステム。
24. 【請求項２４】前記ポインタがＩビーム形状を有するか
    どうかを判定する手段が、 前記ポインタを事前定義Ｉビーム・ポインタ形マスクと
    比較する手段を含むことを特徴とする、請求項２２に記
    載のシステム。
25. 【請求項２５】前記ポインタがＩビーム形状を有するか
    どうかを判定する前記手段が、 前記ポインタのすべての画素が前記Ｉビーム・ポインタ
    形マスク内に入っている場合に、前記ポインタを構成す
    る画素の数をカウントする手段をさらに含むことを特徴
    とする、請求項２４に記載のシステム。
26. 【請求項２６】ディスプレイを有するコンピュータ・シ
    ステムにおいて、非システム・ポインタがシステム・ポ
    インタと同等であることを判定するシステムであって、
    前記非システム・ポインタがポインタＩＤを有し、前記
    システムが、 前記ポインタＩＤがポインタＩＤのテーブルに入ってい
    て、前記システム・ポインタと同等であるというフラグ
    が前記テーブル内に付いているかどうかを判定する手段
    と、 前記ポインタＩＤが前記ポインタＩＤのテーブルに入っ
    ていない場合に、前記非システム・ポインタの形状に基
    づいて、前記非システム・ポインタが前記システム・ポ
    インタと同等であるかどうかを判定する手段とを含むこ
    とを特徴とするシステム。
27. 【請求項２７】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であると判定され
    た場合に、前記ポインタＩＤを前記ポインタＩＤのテー
    ブルに追加し、前記システム・ポインタと同等であると
    いうフラグを前記ポインタＩＤに付ける手段を含むこと
    を特徴とする、請求項２６に記載のシステム。
28. 【請求項２８】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタを事前定義マスクと比較する
    手段を含むことを特徴とする、請求項２６に記載のシス
    テム。
29. 【請求項２９】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタのすべての画素が前記マスク
    内に入る場合に、前記非システム・ポインタを構成する
    画素の数をカウントする手段を含むことを特徴とする、
    請求項２８に記載のシステム。
30. 【請求項３０】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタを構成する画素の数が所定の
    しきい値を上回る場合に、前記非システム・ポインタが
    所定の対称条件を満足するかどうかを判定する手段を含
    むことを特徴とする、請求項２９に記載のシステム。
31. 【請求項３１】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタを事前定義粗大マスクと比較
    する手段を含むことを特徴とする、請求項２６に記載の
    システム。
32. 【請求項３２】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタのすべての画素が前記粗大マ
    スク内に入る場合に、前記非システム・ポインタを事前
    定義微細マスクと比較する手段を含むことを特徴とす
    る、請求項３１に記載のシステム。
33. 【請求項３３】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタのすべての画素が前記微細マ
    スク内に入る場合に、前記非システム・ポインタを構成
    する画素の数をカウントする手段を含むことを特徴とす
    る、請求項３２に記載のシステム。
34. 【請求項３４】形状に基づいて、前記非システム・ポイ
    ンタが前記システム・ポインタと同等であるかどうかを
    判定する前記手段が、 前記非システム・ポインタを構成する画素の数が所定の
    しきい値を上回る場合に、前記非システム・ポインタが
    所定の対称条件を満足するかどうかを判定する手段を含
    むことを特徴とする、請求項３３に記載のシステム。
35. 【請求項３５】前記非システム・ポインタが砂時計ポイ
    ンタであることを特徴とする、請求項２６に記載のシス
    テム。
36. 【請求項３６】前記非システム・ポインタがＩビーム・
    ポインタであることを特徴とする、請求項２６に記載の
    システム。