JP3105749B2 - 画面表示変換方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ディスプレイに表示さ
れる画面を変換するための画面変換方法に係り、特に、
コンピュータ・システムに接続されたビットマップ形式
ディスプレイ上に表示されるアプリケーション・プログ
ラムの画面を変換するための画面変換方法に関する。更
に詳しくは、本発明は、３２７０端末エミュレータのよ
うに、本来、テキスト・ベースの画面を提供するアプリ
ケーション・プログラムに向けられたものであり、ホス
ト・アプリケーションから送られてくるテキスト・ベー
スの画面情報をＧＵＩ風の画面表示（ＧＵＩ-flavored
host screen）に変換するとともにマウス型入力（Mouse
-oriented operation）を可能にするための画面変換方
法に関する。

【０００２】

【従来の技術】最近の技術革新によって、パーソナル・
コンピュータ（ＰＣ）の利用態様は多様化してきた。

【０００３】ＰＣの利用態様の１つとして、ＥＳ９００
０あるいはＳ／３９０などのホスト・システムとネット
ワークを介して接続されて、ホスト・メインフレーム上
で稼働する適用業務プログラムの入出力端末（例えば３
２７０端末）として用いられる場合が挙げられる（図３
４参照）。この場合、ＰＣは、ハードウェア的には、通
信データ（例えば３２７０データ・ストリーム）を送受
信するための通信用アダプタ・カードを装着することに
よって通信線（例えば同軸ケーブル）でホスト・システ
ムと連絡しているとともに、ソフトウェア的には、３２
７０端末などをエミュレートするためのプログラム（以
下、「エミュレーション・プログラム」又は「エミュレ
ータ」という。）をアプリケーション・プログラムの１
つとしてサポートしていることが前提となる（図２参
照）。３２７０端末エミュレータは、エミュレーション
・プログラムの一例であり、ホスト・システムから送ら
れてくるホスト・アプリケーション（例えばＶＭ／ＣＭ
Ｓなどのホスト・オペレーティング・システムの上で稼
動するアプリケーション・プログラム）の出力を表示す
るとともに、ＰＣ上で入力されたデータをホストに対し
て送るなど、ホスト・メインフレーム用の３２７０端末
となるための機能のほとんど全てを提供するソフトウェ
アである。

【０００４】また、最近のＰＣは、ハードウェア的に
は、ビットマップ表示形式のディスプレイを装備するも
のが増えてきた。また、ソフトウェア的には、ＯＳ／２
（ＩＢＭ Corp.の商標）やＭＳ−Ｗｉｎｄｏｗｓ（Micr
osoft Corp.の商標）のように、ビットマップ表示形式
をサポートし、マルチ・ウィンドウを提供できるオペレ
ーティング・システム（ＯＳ）が主流となってきた。こ
れら最新のＯＳは、一般的に、グラフィカル・ユーザ・
インターフェース（ＧＵＩ）を組み込んでいる。ＧＵＩ
は、マウスやジョイスティックなどによって入力された
座標値をアプリケーション・プログラムに伝えることが
できる。したがって、ユーザは、キーボードだけでな
く、マウスによっても自己の意思を簡易に入力すること
ができるようになっている。

【０００５】また、このような最新鋭のＯＳ上で稼働す
るアプリケーション・プログラムの中には、ビットマッ
プ表示やＧＵＩの流れを受けて、ユーザの目を魅了する
とともに入力操作が容易な表示画面を提供するものもあ
る。図３６は、このようなアプリケーション・プログラ
ムの１例を示している。同図で一目瞭然なように、画面
上でユーザに入力を促す領域(（例えばウィンドウ右上
端の「アイコン化」ボタン，「最大表示」ボタンやダイ
アログ・ポックス内の「ＯＫ」ボタン，「Cancel」ボタ
ンなど）は、枠で囲われているとともに３次元的な陰影
が付されている（以下、画面上で枠で囲われてアイコン
化した領域を「ホット・スポット（HotSpot）」または
「３Ｄボタン」ともいう）。このような画面上では、ユ
ーザは、所望の３Ｄボタン領域内にマウス・ポインタを
移動し、マウス・ボタンをクリック操作するだけで該３
Ｄボタンに対応するキー入力と同じ操作を行えるように
なっている。３Ｄボタン表示は、ユーザに対して、アプ
リケーションが最新（次世代的）であるという印象を与
えるだけでなく、マウス入力のための視覚的な注意を喚
起することにもなるので、有効な表示方法といえよう。

【０００６】ところで、前述の３２７０端末エミュレー
タが提供する表示画面（以下、単に「３２７０画面」と
もいう）は、一般的には、テキスト・ベース（若しくは
キャラクタ・ベース）の旧態依然とした２次元的な形式
で提示されるものである。また、３２７０端末上では、
ユーザはキーボードから入力して操作することしか許さ
れておらず（キャラクタ・ユーザ・インターフェース：
ＣＵＩ）、マウスなどによるＧＵＩ入力はできない。そ
の理由には、３２７０データ・ストリームがテキスト・
データのみで構成される、ということが挙げられよう。
ここで、エミュレータもＰＣのＯＳ上で稼働するアプリ
ケーション・プログラムの１つであるということと、前
述のマルチ・ウインドウ環境とを考え合わせると、３Ｄ
ボタン表示が採用された最新のアプリケーションに係る
ウィンドウと旧態依然としたエミュレータに係るウィン
ドウとが同じディスプレイ・スクリーン上で雑居する、
という様子は容易に想像できるであろう。ＭＳ−Ｗｉｎ
ｄｏｗｓやＯＳ／２のプレゼンテーション・マネージャ
（ＰＭ）、ＡＩＸ（ＩＢＭ Corp.の商標）など、ビット
マップ表示式のＧＵＩ環境をサポートするＯＳ上でも、
３２７０端末エミュレータは既にインプリメントされて
おり、マルチ・ウインドウ環境下での３２７０画面の存
在は実際的な問題である。テキスト・ベースの３２７０
画面の存在は、単にユーザにとって不便なだけでなく、
マルチ・ウィンドウ自体に対する印象をも陳腐化してし
まいかねない。

【０００７】２次元的な３２７０画面を３Ｄボタン表示
に変換するとともにＧＵＩ風のマウス入力を可能にする
ための既存の手法として、画面変換のためのプログラム
を各エミュレータ画面のタイプ毎に開発する、というこ
とが挙げられる。この場合、画面変換プログラムは、エ
ミュレータに対して画面バッファの内容のコピーを要求
して、該画面バッファをスキャンして所望の（ファンク
ション・キーに該当する）文字列を抽出して、これら文
字列を３次元的な陰影付き表示に変換するようになって
いる。

【０００８】このような既存の画面変換プログラムは、
画面のタイプ毎に作成するという、いわばカスタマイズ
されたものであり、ユーザにとって最適なエミュレータ
画面を得ることができよう。しかしながら、画面のタイ
プ毎に変換プログラムを開発するという作業は非常に労
力を要するものであり、例えばホスト・システムが提供
する画面の種類が多ければ、ユーザのプログラム開発意
欲は忽ち失われてしまう。なお、所望の文字列等を自動
的に３Ｄボタン化するアプリケーション・プログラムは
既に存在するが、現行のものは単純に文字列を追うだけ
なので誤変換が多い。

【０００９】

【発明が解決しようとする課題】本発明の目的は、コン
ピュータ・システムに接続されたビットマップ形式ディ
スプレイ上に表示されるアプリケーション・プログラム
に係る画面を自動変換するための画面変換方法を提供す
ることにある。

【００１０】本発明の更なる目的は、３２７０端末エミ
ュレータのようなテキスト・ベース、キャラクタ・ベー
スのアプリケーション・プログラムに係る画面を、ユー
ザがプログラムを何ら修正・変更することなく、自動変
換するための画面変換方法を提供することにある。

【００１１】本発明の更なる目的は、ホスト・アプリケ
ーションから送られてくるテキスト・ベース、キャラク
タ・ベースの画面情報をＧＵＩ風の画面表示（ＧＵＩ-f
lavored host screen）に変換するとともにマウス型入
力（Mouse-oriented operation）を可能にするための画
面変換方法を提供することにある。

【００１２】

【課題を解決するための手段及び作用】本発明は、上記
課題を参酌してなされたものであり、その第１の側面
は、画面情報を変換して表示する画面表示変換方法にお
いて、表示形式を変換したい文字列（以下、被変換文字
列という）を含む集合的な文字列を前記画面情報内で検
索する第１の段階と、第１の段階で抽出された各集合的
な文字列同士の前記画面情報内における配置関係を判定
する第２の段階と、第２の段階における判定結果が肯定
的であれば各集合的な文字列の中の被変換文字列を所定
の表示形式に変換する第３の段階と、を含むことを特徴
とする画面表示変換方法である。

【００１３】また、本発明の第２の側面は、画面情報を
変換して表示する画面表示変換方法において、前記画面
情報内で表示形式を変換したい文字列（以下、Attentio
n IDKeyという。Attention ID KeyにはＰＦｎ，ＦＰ
ｎ，Ｆｎ，ｎ，ＰＡｎ等が挙げられる。但し、ｎは１乃
至２４の整数）を含んで一体として取り扱われる文字列
（以下、aidkeyexpressionという）を所定の条件式に基
づいて検索する第１の段階と、１行中にaidkeyexpressi
onを複数個含む行を水平型配列の行と推定する第２の段
階と、水平型配列と推定された行のうちでAttention ID
keyとしてＰＦｎ，ＦＰｎ，Ｆｎ又はｎを含むaidkeyex
pressionを１行中に２以上含み且つｎが左から右に向か
って正順に配列されていない行については該推定を否定
する第３の段階と、水平型配列の行に含まれる各Attent
ion ID Keyを所定の表示形式に変換する第４の段階と、
を含むことを特徴とする画面表示変換方法である。

【００１４】また、本発明の第３の側面は、画面情報を
変換して表示する画面表示変換方法において、前記画面
情報内で表示形式を変換したい文字列（以下、Attentio
n IDKeyという。Attention ID keyには、ＰＦｎ，ＦＰ
ｎ，Ｆｎ，ｎ，ＰＡｎ等が挙げられる。但し、ｎは１乃
至２４の整数）を含んで一体として取り扱われる文字列
（以下、aidkeyexpressionという）を所定の条件式に基
づいて検索する第１の段階と、aidkeyexpressionを１つ
だけ含む行が複数連続しているか否かを判定して、該連
続している各行を垂直型配列の行と推定する第２の段階
と、垂直型配列と推定された行のうちでＰＦｎ，ＦＰ
ｎ，Ｆｎ又はｎを含む行が２以上ある場合には各行でＰ
Ｆｎ，ＦＰｎ，Ｆｎ又はｎの画面左端若しくは右端から
の位置が一致していなければ該推定を否定する第３の段
階と、垂直型配列と推定された行のうちでＰＦｎ，ＦＰ
ｎ，Ｆｎ又はｎを含む行が２以上ある場合には各行のｎ
が画面上から下に向かって正順に配列していなければ該
推定を否定する第４の段階と、垂直型配列の行に含まれ
る各Attention ID Keyを所定の表示形式に変換する第５
の段階と、を含むことを特徴とする画面表示変換方法で
ある。

【００１５】また、本発明の第４の側面は、テキストと
フィールド・アトリビュート（但し、フィールド・アト
リビュートは画面上にフィールドを設定して各フィール
ドが入力可能フィールドか入力禁止フィールドか等を定
義するための値）とで構成される画面情報を変換して表
示する画面表示変換方法において、予め指定された文字
列の組合せが前記画面情報内で１行中又は連続する２行
中に存在するか否かを判定する第１の段階と、第１の段
階の結果が肯定的であれば、フィールド・アトリビュー
トによって形成されるフィールドの構造が同一の行が複
数連続しているか否かを判定する第２の段階と、第２の
段階の結果が肯定的であれば、該連続している各行の少
なくとも先頭の入力可能フィールドを所定の表示形式に
変換する第３の段階と、を含むことを特徴とする画面表
示変換方法である。

【００１６】また、本発明の第５の側面は、テキストと
フィールド・アトリビュート（但し、フィールド・アト
リビュートは画面上にフィールドを設定して各フィール
ドが入力可能フィールドか入力禁止フィールドか等を定
義するための値）で構成される画面情報を変換して表示
する画面表示変換方法において、前記画面情報内の非空
白行のうち最上段の行が２以上の入力可能フィールドを
含むか否かを判定する第１の段階と、第１の段階の結果
が肯定的であれば、該最上段の行のフィールドの構造が
直近下位の非空白行と一致するか否かを判定する第２の
段階と、第２の段階の結果が否定的であれば、該最上段
の行を所定の表示形式に変換する第３の段階と、を含む
ことを特徴とする画面表示変換方法である。

【００１７】しかして、本発明の第１乃至第３の側面に
よれば、画面上で特に３Ｄボタン化したい文字列である
Attention ID Keyを３２７０画面（プレゼンテーション
・スペース）の中から直接検索して表示変換するのでは
なく、Attention ID Keyを含んで一体として取り扱われ
る文字列を"aidkeyexpression"(Attention ID Key Expr
ession)と定義し、３２７０画面から一旦aidkeyexpress
ionを検索しておき、さらに抽出された各aidkeyexpress
ion間の配置関係を検証することによって、所望のAtten
tion ID Keyだけを確実に３Ｄボタン化するようにして
いる（図２９乃至図３０参照）。例えば図２２に示す画
面上のカレンダ内の各日付はAttentionID Keyの候補で
はあるが、日付を含む一連の文字列はaidkeyexpression
には該当しないので、誤って３Ｄボタン化されることは
ないのである（図２９参照）。

【００１８】また、本発明の第４の側面によれば、図２
４や図２７に示すような３２７０画面内のカーソル位置
指定型の領域を、図３１や図３２に示すように、的確に
３Ｄボタン化できる。

【００１９】また、本発明の第５の側面によれば、図２
８に示すような３２７０画面内のメニュー・バー中の各
入力項目を、図３３に示すように、的確に３Ｄボタン化
できる。

【００２０】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。

【００２１】

【実施例】

【００２２】本発明の実施例を以下のように項分けして
説明する。 Ａ．パーソナル・コンピュータのハードウェア構成 Ｂ．パーソナル・コンピュータのソフトウェア構成 Ｃ．ホスト〜ＰＣ間のデータ・フロー Ｃ−１．３２７０データの画面表示処理 Ｃ−２．ＰＣ側で入力された画面情報の処理 Ｄ．３２７０画面の表示変換処理 Ｄ−１．３Ｄボタン表示に変換したい領域 Ｄ−２．画面変換処理ルーチン Ｄ−３．画面変換の解除キー

【００２３】Ａ．パーソナル・コンピュータのハードウ
ェア構成 図１は、本発明の実施に供されるパーソナル・コンピュ
ータ（ＰＣ）２０のハードウェア構成を概観的に示した
ものである。

【００２４】１はＣＰＵであり、システム２０全体の動
作を統御するためのものである。ＣＰＵ１は、各入出力
装置と連絡すべく、アドレス／データ・バス２と接続し
ているとともに、メモリ・バス３を介してメイン・メモ
リ４と連絡している。メイン・メモリ４は、通常はＤＲ
ＡＭなどの書込み可能メモリである。メイン・メモリ４
は、ＲＯＭ５に格納されたＢＩＯＳ（Basic Input/Outp
ut System）やハード・ディスク装置（ＨＤＤ）６に格
納されたオペレーティング・システム（ＯＳ）などのシ
ステム・ソフトウェアをロードし、また、ユーザの要求
に応じて各種アプリケーションをロードするようになっ
ている。また、メイン・メモリ４中には、ＣＰＵ１がこ
れらソフトウェアを実行するための作業エリアが確保さ
れている。

【００２５】アドレス／データ・バス２に連絡している
入出力装置の１つは、ビデオ・コントローラ（ＶＧＡ）
７である。ビデオ・コントローラ７は、ＣＰＵ１からの
描画命令に従って画面バッファ（ＶＲＡＭ）８に画面情
報を書き込むとともに、画面バッファ８の内容に従って
画像データを表示するように制御するためのものであ
る。システム２０には、表示装置として、ＬＣＤコント
ローラ１０を介して液晶表示装置（ＬＣＤ）１１が、あ
るいはデジタル／アナログ変換回路（ＤＡＣ）１０を介
してＣＲＴディスプレイ１２が装着されている。なお、
本実施例を具現するためには、ビデオ・コントローラ７
や液晶表示装置１１，ディスプレイ１２がビットマップ
表示をサポートすることが前提となっている。

【００２６】また、アドレス／データ・バス２には、１
ビット単位でデータを転送するためのシリアル・ポート
１３，バイト単位でデータを転送するためのパラレル・
ポート１４や，ＥＳ９０００などのホスト・システム
（図示しない）との間で３２７０データの交信を行うた
めの通信用アダプタ・カード（例えば３２７０アダプタ
・カード，トークン・リング・カード，ＳＤＬＣ用のカ
ード）１５が接続されている。

【００２７】なお、実際には、以上のハードウェア要素
の他に多数のＩ／Ｆ（インターフェース）が存在する
が、それらは当業者には周知の事項なので、本実施例の
説明を簡潔にする便宜上省略している。

【００２８】Ｂ．パーソナル・コンピュータのソフトウ
ェア構成 図２は、メイン・メモリ３上にロードされているソフト
ウェアの階層的構成を概略的に示したものである。該ソ
フトウェア層は、上層よりアプリケーション・プログラ
ム３３層、オペレーティング・システム３２層、ハード
ウェア制御層としてのＢＩＯＳ層３１とからなる。

【００２９】アプリケーション・プログラム３３…は、
ユーザの要求に応じてＨＤＤ６，ＦＤＤなどの外部記憶
装置からロードされるものであり、文書処理，データベ
ース管理，スプレッドシートの他、３２７０端末エミュ
レータなどがこれに該当する。各アプリケーション３３
…の画面は、例えば図３６に示すように、ディスプレイ
１１（又は１２）上ではマルチ・ウィンドウとして表示
されてもよい。

【００３０】３２７０端末エミュレータは、アプリケー
ション・プログラム３３…のうちの１つであり、通信ア
ダプタ・カード１５を介して接続されたホスト・システ
ムから送られてくるホスト・プログラム（例えばＶＭ／
ＣＭＳなどのホスト・オペレーティング・システム）の
コマンドを実行するとともに、ＰＣ２０上で入力された
データをホストに対して送るなど、ＰＣ２０が３２７０
端末として動作するための機能を提供するものである。
また、テキスト・ベースの３２７０画面情報を変換する
ための画面変換プログラム（以下、「３Ｄボタン化サブ
ルーチン」という）は、３２７０エミュレータ３３中の
１モジュールとして組み込まれているものと把えられた
い。

【００３１】オペレーティング・システム（ＯＳ）３２
は、各アプリケーション・プログラム３３…の動きを制
御するためのソフトウェアであり、リソース管理，デバ
イス管理，ファイル管理などを行う。本発明を具現する
ためには、ＯＳ３２は、特に、ＶＲＡＭ８の内容を掌握
して（すなわちビットマップ表示をサポート）表示を制
御できるとともに、グラフィカル・ユーザ・インターフ
ェース（ＧＵＩ）をサポートすることが不可欠である。
このようなＯＳには、例えばＭＳ−ＷｉｎｄｏｗｓやＯ
Ｓ／２，ＡＩＸが挙げられる。

【００３２】ＢＩＯＳ３１は、ソフトウェア層３１，３
２とハードウェア層との間のインターフェースであり、
アプリケーション・プログラム３３…やＯＳ３２から送
られてくる一般的な性格のコマンドを解釈して各入出力
装置のハードウェア操作するためのコマンドに変換する
ためのコードで構成されている。

【００３３】Ｃ．ホスト・システム〜ＰＣ間のデータ・
フロー

【００３４】Ｃ−１．３２７０データの画面表示処理 図３は、ホスト・システムから送られてくる３２７０デ
ータ・ストリームを、ＰＣ側の３２７０端末エミュレー
タ３３及びオペレーティング・システム３２が行う処理
フローを概略的に示した図である。

【００３５】(1) ステップ１ ３２７０データ・ストリームは、通信線を介してシーケ
ンシャルに（すなわち１次元的な文字コードの流れとし
て）ＰＣ２０に送られてくる。そして、ホスト−ＰＣ間
のデータ転送速度の差を吸収すべく、データ・ストリー
ムは通信バッファに一旦格納される。この通信バッファ
は、実際には、アダプタ・カード１５が備えているメモ
リか、あるいはメイン・メモリ４内にマッピングされた
エリアである。

【００３６】(2) ステップ２ 次いで、３２７０データ・ストリームは、３２７０端末
エミュレータ３３によって解釈され、テキスト・プレー
ン（text plane）情報とアトリビュート・プレーン（at
tribute plane）情報とからなる２次元的な画面情報と
して再編成されて、プレゼンテーション・スペース（Ｐ
Ｓ）上に書き込まれる。プレゼンテーション・スペース
は、実際には、メイン・メモリ４内にマッピングされた
エリアであり、１つのプレゼンテーション・スペースは
３２７０画面１枚分の情報に相当する。ここで、テキス
ト・プレーンとは、画面上に表示すべき文字列や入力可
能な位置を指定するためのものであり、文字やフィール
ド・アトリビュートが３２７０画面と対応する位置に書
き込まれるようになっている（但し、処理の高速化のた
め、フィールド・アトリビュートも独立した１枚のプレ
ーン上に書き込む場合もある）。フィールド・アトリビ
ュートとは、３２７０画面をフィールドと呼ばれる区域
（フィールドの長さは任意）に分けるとともに、各々の
フィールドがキー入力が可能なフィールド（入力可能フ
ィールド）かキー入力が禁止されているフィールド（入
力禁止フィールド若しくは保護フィールド）かを指定す
るために用いられる。また、アトリビュート・プレーン
とは、主にテキスト・プレーン中の各文字の色などの属
性（キャラクタ・アトリビュート）を定義するためのも
のであり、テキスト・プレーン上の各文字と対応する位
置にキャラクタ・アトリビュートが書き込まれるように
なっている。なお、本実施例では、説明を容易にするた
めにアトリビュート・プレーンは各プレゼンテーション
・スペース毎に１枚としたが、指定したいパラメータが
多数ある場合は、アトリビュート・プレーンを各プレゼ
ンテーション・スペース毎に複数枚設けてもよい。

【００３７】ホスト・システム（ホスト・アプリケーシ
ョン）は、３２７０端末エミュレータによって作成され
たプレゼンテーション・スペースの内容を完全に掌握で
きる。すなわち、ホスト・システムは、ＰＣ２０に対し
てプレゼンテーション・スペースの一部又は全部の書き
込みを指示できるとともに、逆に、ＰＣ２０側でユーザ
のキー入力操作などによってプレゼンテーション・スペ
ースに書き込まれた内容を読みとることができる。但
し、プレゼンテーション・スペース自体は、テキスト・
ベースの旧態依然とした２次元的な画面情報に過ぎな
い、という点に留意されたい。

【００３８】(3) ステップ３ 次いで、プレゼンテーション・スペースの内容をディス
プレイ１１（又は１２）に表示すべく、オペレーティン
グ・システムが画面バッファ（ＶＲＡＭ）８に対して画
面情報の書き込みを行う。

【００３９】従来の３２７０端末エミュレータは、ホス
ト・アプリケーションから受け取った３２７０データ・
ストリームを単に２次元データとして解釈する（すなわ
ちプレゼンテーション・スペースにテキスト・データを
書き込む）のみで、それ以上の処理は行わなかった。し
たがって、オペレーティング・システムはプレゼンテー
ション・スペースの内容をそのままＶＲＡＭ８に書き込
むしかなく、ディスプレイ１２上に表示される３２７０
画面もプレゼンテーション・スペースに書き込まれた内
容（すなわち旧態依然としたテキスト・ベースの２次元
的な画面）と同一であった。

【００４０】これに対し、本実施例に係る３２７０端末
エミュレータ３３は、プレゼンテーション・スペースに
対して所定の前処理をしてから、オペレーティング・シ
ステム３２に画面情報を渡すようになっている。ここで
いう前処理とは、プレゼンテーション・スペースの内容
を順次スキャンして、テキスト・ベースの画面情報の中
から３Ｄボタン表示に変換したい領域（例えばファンク
ション・キーなどの"Attention ID Key"に対応する文字
列）を検索して、各領域毎にその文字列の内容，文字列
の左上のｘｙ座標と高さと幅などの３Ｄボタン化するた
めに必要な情報を構築することをいう（この前処理の詳
細についてはＤ−２項で詳解する）。そして、オペレー
ティング・システム３２は、ＶＲＡＭ８に書き込む際
に、３２７０端末エミュレータ３３が構築した情報に基
づいて画面情報を適宜３Ｄボタン表示に変換処理する。
ＭＳ−ＷｉｎｄｏｗｓやＯＳ／２のようにビットマップ
表示をサポートするオペレーティング・システムは、指
定された領域を陰影付きの３Ｄボタンに変換する機能を
サポートしている。そして、ディスプレイ１１（又は１
２）は、ＶＲＡＭ８の内容に従って３Ｄボタン化処理さ
れた画面を実際に表示する訳である。

【００４１】なお、３２７０端末エミュレータ３３やホ
スト・システムからは、ＶＲＡＭ８の内容が見える必要
はない。何故なら、プレゼンテーション・スペースから
ＶＲＡＭ８への書き込みはオペレーティング・システム
が行うからである（上述）。ホスト・システム自体は、
プレゼンテーション・スペースを介してＰＣ２０のユー
ザとコミュニケーションできるのみであり、ＶＲＡＭ８
（換言すればディスプレイ１１（又は１２）に実際に表
示されている変換処理後の３２７０画面）に対しては、
書き込むことも、逆にユーザが書き込んだ内容を直接読
み取ることもできないのである。

【００４２】Ｃ−２．ＰＣ側で入力された画面情報の処
理 図４は、ＰＣ側で入力された情報を３２７０データ・ス
トリームとしてホスト・システムに送るためのフローを
概略的に示した図である。

【００４３】ＰＣが従来の３２７０端末エミュレーショ
ン・プログラムしかサポートしていない場合、ディスプ
レイ１１，１２に表示される３２７０画面は、３２７０
データ・ストリームをベースとした旧態依然の２次元的
画面である（上述）。また、ユーザの入力操作は、（画
面上で指定された）ファンクション・キーの入力か、フ
ィールド・アトリビュートで定義された入力可能フィー
ルド内でのキー入力という形態しか許されていない。こ
れは、３２７０端末エミュレータやホスト・アプリケー
ションがＶＲＡＭ８の内容を直接読むことができず、プ
レゼンテーション・スペースに入力されたキーの内容し
か３２７０データ・ストリームとしてホスト・アプリケ
ーションに渡すことができないからある。

【００４４】これに対し、本実施例に係る３２７０端末
エミュレータ３３は、ユーザに対してマウス入力も許し
ている。ユーザが任意の３Ｄボタン（例えば陰影付きの
枠で囲まれたＰＦ１キー）上でマウスをクリック操作す
ると（ステップ４）、オペレーティング・システムは、
クリック操作という事象とともにクリックされた座標値
などの必要なパラメータを３２７０端末エミュレータ３
３に通知する（ステップ５）。次いで、３２７０端末エ
ミュレータ３３は、該クリック操作に該当する入力キー
が何であるかを察知して、該入力キーが押されたと同じ
３２７０データ・ストリームを作り出し、通信バッファ
に対して送り出す（ステップ６）。したがって、ホスト
・アプリケーションは、３２７０データ・ストリームを
受け取って、従来と同様の処理をするだけでよい。換言
すれば、ホスト・システムは、３Ｄボタン表示された３
２７０画面の内容を意識しなくともＰＣ側での入力デー
タを処理できる訳である。

【００４５】Ｄ．３２７０画面の表示変換処理 この項では、テキスト・ベースの３２７０画面を３Ｄボ
タンを含む画面に変換するための処理手順について詳解
する。なお、図１５乃至図２８には、テキスト・ベース
（すなわち３Ｄボタン化処理前）の３２７０画面の例を
挙げている。３Ｄボタン化処理前の３２７０画面の内容
はプレゼンテーション・スペースのテキスト・プレーン
の内容と等価であると理解されたい。

【００４６】Ｄ−１．３Ｄボタン表示に変換したい領域 テキスト・ベースの３２７０画面の中で３Ｄボタン表示
に変換したい領域には、以下のものが挙げられる。

【００４７】(1) Attention ID Key: ３Ｄボタン化したい領域の第１は、Attention ID Keyに
係る領域である。ここで、Attention ID Keyとは、ファ
ンクション・キー（"PFn"，"Fn"，"n"，"PAn"など（但
し、nは番号））や"ENTER"，"CLEAR"キーなど、字句通
りのキャラクタ・キーの入力を要しない入力キーのこと
である。

【００４８】画面上でAttention ID Keyを表示する領域
は、ユーザに対して特に注意を喚起したい領域でもあ
る。しかしながら、全てのAttention ID Keyに相当する
文字列を３Ｄボタン化すると、却って画面を見にくいも
のにしてしまう場合がある。何故なら、単なるコメント
文に過ぎず、ユーザに入力動作を喚起しないようなAtte
ntion ID Key表示もあるからである。また、２〜３文字
程度の字句の一致度だけAttention ID Keyを検索したの
では、Attention ID Keyでないものまで抽出して３Ｄボ
タン化してしまうおそれもある。そこで、本実施例で
は、画面上でAttention ID Keyを含んで一体として取り
扱われる文字列を"aidkeyexpression"(Attention ID Ke
y Expression)と定義し、プレゼンテーション・スペー
スから一旦aidkeyexpressionを検索しておき、さらに抽
出された各aidkeyexpression間の配置関係を検証するこ
とによって、所望のAttention ID Keyだけを確実に抽出
できるようにしている。例えば図２２に示す画面上のカ
レンダ内の各日付はAttentionID Keyの候補ではある
が、日付を含む一連の文字列はaidkeyexpressionには該
当しないので、誤って３Ｄボタン化されることはないの
である。

【００４９】以下、式(1)〜(18)を用いてaidkeyexpress
ionの定義しておく。

【００５０】

【数１】

【００５１】式(1)によれば、aidkeyexpressionは、del
im0と、aidkeytermと、delim2と、functionとで構成さ
れる。delim0とdelim2は、ともに文字列間を区切るため
の境界（以下、「デリミッタ」（delimiter）と総称す
る）のことである。delim0は、aidkeyexpressionの先頭
位置を画定するためのものであり、式(2)に示すよう
に、ブランク（'_'）が用いられる。但し、表示画面上
のブランクはSpace，Null，Attribute Characterなどを
含むので、複数種類の文字コードがブランクに該当する
（以下、delimiterとして用いられるブランクについて
同様）。また、delim2は、aidkeytermとこれに関連する
functionとを接続するためのいわば接続詞であり、式
(3)に示すように、ブランクの他に'＝'，'−'，'：'の
うちのいずれかのキャラクタが用いられる。なお、deli
m2の後方に付された戻り矢印は、delim2が繰り返される
場合があることを意味する（例えば'=='や':='など）。

【００５２】

【数２】

【数３】

【００５３】aidkeytermとは、画面上でユーザの注意を
喚起させたい文字列そのものであり、画面表示をテキス
ト・ベースから３Ｄボタンに変換させたい文字列の中で
も中心的存在である。aidkeytermは、その文字列の内容
に応じて、式(4)に示すように、pfkeyitemと、pakeyite
mと、otherkeyitemとに分類される。

【００５４】

【数４】

【００５５】pfkeyitemとは、通常のファンクション
（ＰＦ）・キーに対応するものであり（例えば図１６の
各"PF"キー）、式(5)に示すように、他の文字列との境
界を画定するためのdelim1（行の先頭などでdelim1がな
い場合を含む）と、ＰＦキーの種別などを特定するため
のpfkeyidとで構成される。delim1は、例えば図２０に
示す画面内のＰＦキー"PF8/10"や"PF3/12"のように、単
一のpfkeyitemが２以上のpfnumberを備える場合など
に、各pfnumberの間を仕切るための文字であり、"/"，"
|"，","などのキャラクタが用いられる（式(6)参照）。
また、pfkeyidは、式(7)に示すように、さらに、pfpref
ix（pfprefixを省略する場合を含む）とpfnumberとで構
成される。pfprefixとは、aidkeytermがＰＦキーである
ことを表すためのいわば接頭辞であり、式(8)に示すよ
うに、"PF"，"FP"，"F"のうちのいずれかの文字列が用
いられる。pfnumberとは、ＰＦキーの番号を特定するた
めの変数であり、使用するマシンなどにもよるが、式
(9)に示すように、1…24，01…09，_1…_9のうちのいず
れかのレンジで用いられる。

【００５６】

【数５】

【数６】

【数７】

【数８】

【数９】

【００５７】pakeyitemとは、ファンクション・キーの
中でも"PA"という接頭辞が付されるＰＡキーのことであ
る。ＰＡキーは、従来のホスト・アプリケーションでは
よく用いられたキーである（例えば図２７中に"PA"キー
が存在する）。pakeyitemは、式(10)に示すように、他
の文字列との境界を画定するためのdelim1と、ＰＡキー
であることを特定するためのpakeyidとで構成される（d
elim1が省略される場合を含む）。pakeyidは、式(11)に
示すように、さらに、接頭辞としてのpaprefix（文字
列"PA"。式(12)参照）と、ＰＡキーの番号を特定するた
めのpanumber（式(13)参照）とで構成される。

【００５８】

【数１０】

【数１１】

【数１２】

【数１３】

【００５９】なお、ファンクション・キーの接頭辞やde
limiterファンクション番号等は、言語や使用する機種
によって異なり、通常、ユーザによる変更が許されてい
る。本明細書で書かれているのは英語ベースの画面にお
ける代表的な例を扱っているに過ぎない。

【００６０】otherkeyitemとは、"ENTER"，"CLEAR"，"E
NT"，"CLR"など、ファンクション・キー以外のAttentio
n ID Keyのことであり、式(14)に示すように、otherkey
itemであることを特定するためのotherkeyidで構成され
る。otherkeyidは、式(15)に示すように、さらに、接頭
辞としてのotherprefix（式(16)参照）と、文字列の間
を画定するためのdelim3（式(17)参照）と、接尾辞とし
てのothersuffix（式(18)参照）とからなる（delim3とo
therkeysuffixを省略する場合も含む）。

【００６１】

【数１４】

【数１５】

【数１６】

【数１７】

【数１８】

【００６２】また、functionとは、aidkeytermの機能を
説明するための文字列である。例えば、図１５の場合で
は、"PF1"に連なる"Alternate PFs"や、"PF2"に連なる"
FileNOTE"などが各々のfunctionに該当する。

【００６３】aidkeyexpressionは、通常、３２７０画面
中に複数個存在するが、お互いの配置関係に応じて「水
平型」と「垂直型」に分類される。aidkeyexpressionの
配列が水平型、垂直型のいずれかであるかは、以下の判
定条件に従って決定することができる。なお、上述した
otherkey prefix，othersuffix，delim3などは、使用す
る言語によって異なる、いわばcase insentiveなもので
ある。

【００６４】(a) 水平型判定条件 (a-1) 一行中に複数個のaidkeyexpressionが含まれてい
ること。但し、水平型が複数行にまたがっている場合の
最終行はこの限りではない。 (a-2) 一行中にpfkeyitemを複数個含む場合は、それら
のpfnumberが左から右に向かって正順に配列されている
こと。但し、pfnumberは等差数列的に並んでいなくても
よい。また、pfnumberが行中に１つしか含まれていない
場合も正順とみなす。delim1が存在する場合には、この
条件は適用しない。 (a-3) いずれのaidkeyexpressionもdelim2には同じ文字
コードが使われている。

【００６５】(b) 垂直型判定条件 (b-1) aidkeyexpressionを１つしか含まない行が複数連
続している。但し、他の行が間に入ることは許容する。 (b-2) pfkeyidの左端の桁位置と右端の桁位置の少なく
とも一方が各行とも同一である。 (b-3) 各行のdelim2が一致する。 (b-4) pfnumberは上段の行から下段に向かって正順に配
列されている。但し、pfnumberは必ずしも等差数列的に
並んでいる必要はない。

【００６６】水平型及び垂直型の判定条件において、pf
numberが正順に配列されていない場合を取り除くのは、
かかる場合は３２７０画面中にAttention ID Keyが煩雑
に羅列されているだけでユーザに入力を喚起しない場合
が多い、という経験則に基づくものである。

【００６７】(2) カーソルを置いて指定すべき領域：３
Ｄボタン化したい領域の第２は、カーソルを置いて指定
すべき領域である。例えば、図２６中の"TABLE OF CONT
ENTS"の各エントリの先頭の入力可能フィールドがこれ
に該当する。入力可能フィールドは、テキスト・プレー
ン中の対応位置にキー入力の許可を意味するフィールド
・アトリビュートを書き込むことによって指定される
（Ｃ−１項参照）。本明細書ではこのような領域を「カ
ーソル位置指定型の領域」と呼ぶことにしている。「カ
ーソル位置指定型」の領域は、図２４乃至図２７に示す
ように、１つの３２７０画面内で「水平型」や「垂直
型」と混在していてもよい。

【００６８】カーソル位置指定型は、"cursor"＆"Ente
r"のように、予め指定されているキーワードの組が同一
行又は連続する二行（但し、間に空白行の挿入するのは
許される）の中に存在することが第１の成立条件である
（図２４乃至図２７参照）。さらに、テキスト・プレー
ン中ではフィールドの構造（すなわち、入力可能フィー
ルドと入力禁止フィールドの並び方。各フィールドはフ
ィールド・アトリビュートによって区切られる。Ｃ−１
参照）が一致する行が連続して存在し（但し、空白行の
挿入は許す）、各行が入力可能フィールドを少なくとも
１つ含んでいることが第２の成立条件である。

【００６９】(3) メニュー・バー内の各メニュー項目の
文字列を表示する領域：３Ｄボタン化したい領域の第３
は、メニュー・バー内の各メニュー項目の文字列を表示
する領域である。例えば、図２８に示すように、３２７
０画面の最上段にある水平なバーがこれに該当し、この
メニュー・バー内の"Books"，"GoTo"，"Search"，"Not
e"…などの各メニュー項目に係る文字列が３Ｄボタン化
したい領域である。本明細書ではこのような領域を「メ
ニュー・バー型の領域」と呼ぶことにしている。「メニ
ュー・バー型」は、同じ３２７０画面内で「カーソル位
置指定型」や「水平型」．「垂直型」と混在してもよ
い。

【００７０】メニュー・バー型は、画面の最上部の行が
複数の入力可能フィールドに分かれていることと、該行
の直近下位の行が入力可能フィールドを含まないことが
成立条件である。

【００７１】なお、式(1)〜式(18)によるaidkeyexpress
ionの定義や、「水平型」，「垂直型」，「カーソル位
置指定型」，「メニュー・バー型」という分類は、図１
５乃至図２８などの３２７０画面を始めとする多数のテ
キスト・ベースのアプリケーション画面の内容に基づい
て、ヒューリスティクな手法により構築されたものであ
る。

【００７２】Ｄ−２．画面変換処理ルーチン 図５は、プレゼンテーション・スペース上のテキスト・
ベースの画面情報を変換処理してＶＲＡＭ８に書き込む
ためのフローチャートを概略的に示している。該処理
は、実際には、３２７０端末エミュレータ３３中の３Ｄ
ボタン化サブルーチンと、当プログラムを動作している
オペレーティング・システム３２（例えばＭＳ−Ｗｉｎ
ｄｏｗｓやＯＳ／２，ＡＩＸなど）との協働的作用によ
って実現される。３Ｄボタン化サブルーチンは、引数と
して与えられた情報に基づいて、３２７０画面上の行
数、桁数など３Ｄボタン化に必要な情報を、オペレーテ
ィング・システム３２の定義に合致した形式（すなわ
ち、３Ｄボタンの起点の座標、横幅、高さなどの情報）
に変換して渡すとともに、オペレーティング・システム
に対し３Ｄボタンの表示を要求する。また、３Ｄボタン
の上に表示すべき文字列もオペレーティング・システム
に渡すようになっている。

【００７３】本実施例に係る３２７０端末エミュレータ
３３は、まず、処理対象となるプレゼンテーション・ス
ペースをスキャンして、全てのaidkeyexpressionを抽出
して、３Ｄボタン表示に変換するために必要な情報を、
リスト形式にして構築する（ステップ１００）。

【００７４】次いで、該リストを参照して、プレゼンテ
ーション・スペース中に水平型（前述）に配列されたai
dkeyexpressionが存在するか否かを判別し、存在すれ
ば、該当するAttention ID Keyの３Ｄボタン化処理を行
う（ステップ２００）。但し、水平型に対して画面表示
変換を行うべきか否かを、ユーザが選択できるようにし
てもよい。

【００７５】次いで、該リストを参照して、プレゼンテ
ーション・スペース中に垂直型（前述）に配列されたai
dkeyexpressionが存在するか否かを判別し、存在すれ
ば、該当するAttention ID Keyの３Ｄボタン化処理を行
う（ステップ３００）。但し、垂直型に対して画面表示
変換を行うべきか否か、及びaidkeyexpression中のどの
範囲を３Ｄボタン化するかを、ユーザが選択できるよう
にしてもよい。

【００７６】次いで、プレゼンテーション・スペース中
で既に３Ｄボタンに変換されている部分を除いた残りの
領域で、カーソル位置指定型の領域があれば３Ｄボタン
化し（ステップ４００）、また、メニュー・バー型があ
れば３Ｄボタン化する（ステップ５００）。但し、カー
ソル位置指定型、メニュー・バー型に対して画面表示変
換を行うべきか否かを、ユーザが選択できるようにして
もよい。

【００７７】３Ｄボタン化のためのフローチャートを概
略的に述べてきたが、以下、各ステップの詳細な処理手
順する。

【００７８】(1) プレゼンテーション・スペース中での
aidkeyexpressionの検索 まず、プレゼンテーション・スペース中に存在するaidk
eyexpressionの検索を行うが、これは水平型又は垂直型
に配列されたAttention ID Keyの表示を変換するための
前処理に該当する。本実施例では、プレゼンテーション
・スペースの各行毎に１つのレコード（以下、「aid-ke
yレコード」という）を作成することによって、行単位
でaidkeyexpressionに関する情報を把握するようにして
いる。aid-keyレコードは、図６(a)に示すように、keyt
ypeフィールド，keycountフィールド，deltypeフィール
ド，delcountフィールド，startフィールド，endフィー
ルドという６つのフィールドで構成される。ここで、ke
ytypeフィールドは、対応する行の上にＰＦキーに係るa
idkeyexpressionが存在する場合に、そのＰＦキーのタ
イプ（すなわちpfprefixが"PF"，"FP"，"F"又はデフォ
ルトのいずれであるか）を格納しておくための領域であ
る。また、keycountフィールドは、対応する行の上に存
在するaidkeyexpressionの個数を格納しておくための領
域である。また、deltypeフィールドは、対応する行の
上に存在するaidkeyexpressionの中で用いられるdelim2
のタイプ（すなわち"_"，"="，"-"，":"のいずれである
か）を格納しておくための領域である。また、delcount
フィールドは、対応する行の上に存在するdelim2の個数
を格納しておくための領域である。また、startフィー
ルド，endフィールドは、対応する行の上に存在する最
も行頭に近いpfkeyidの左端の桁位置（start）及び右端
の桁位置（end）を格納しておくための領域である。各a
id-keyレコードはフラグを１つ持っているが、このフラ
グは対応する行が未処理かを示すためのものであり、初
期状態ではセットされており、３Ｄボタン化処理される
とリセットされるようになっている。

【００７９】一般的なＰＣに用いられる表示装置上では
プレゼンテーション・スペースは例えば２４行で構成さ
れるので、図６(b)に示すように、１画面に対して２４
個のaid-keyレコード（以下「aid-keyリスト」という）
が作成されることになる。各行に関するaid-keyレコー
ドの各フィールドの値は、水平型・垂直型それぞれに配
列されたaid-keyを３Ｄボタン化する際に利用される
が、詳細は後述する。

【００８０】図７には、プレゼンテーション・スペース
中のaidkeyexpressionを検索するためのステップ１００
の詳細な処理手順、すなわち各行毎にaid-keyレコード
を作成するための処理手順について図解してある。以
下、このフローについて説明しておく。

【００８１】まずステップ１０２で内部変数等を初期設
定するとともに行ポインタに１を代入することによっ
て、プレゼンテーション・スペースの先頭行からステッ
プ１０４以降の処理を開始する。

【００８２】ステップ１０６乃至１１２で形成される閉
ループでは、処理対象となっている行の左端の桁からタ
ーム（term）毎に文字列を順次取り出して（ステップ１
０６）、前回取り出したタームとの関係に応じて内部状
態を遷移させて処理することによって（ステップ１１
０）、該行のkeytype，keycount，deltype，delcountを
求める。そして、該行からもはや取り出すべきタームが
ない場合（すなわち該行の全ての文字列の処理が終了し
た場合）、判断ブロック１０８の分岐Ｎｏに進んで該閉
ループを抜け出す。次いで、ステップ１１８では、得ら
れたkeytype，keycount，deltype，delcountの各値をai
d-keyレコードの対応フィールドに格納する。次いで、
ステップ１１６では、行中の最も行頭に近いpfkeyidの
左端の桁位置と右端の桁位置をそれぞれstart，endの各
フィールドに格納し、行ポインタを１つだけインクリメ
ントして、判断ブロック１０４の直前に戻る。判断ブロ
ック１０４では行ポインタがプレゼンテーション・スペ
ースの最終行（例えば２４行目）を越えているか否かを
判断する。行ポインタが最終行を越えていなければ、該
ブロック１０４の分岐Ｎｏに進み、次の行に対して上述
の閉ループ処理を繰り返す。一方、行ポインタが最終行
を越えていれば、プレゼンテーション・スペース中の全
ての行の処理が終了したことを意味するので、該ブロッ
ク１０４の分岐Ｙｅｓに進んで、包括的ステップ１００
から抜け出す（経由点Ｐ）。

【００８３】また、ステップ１１０において、新しく取
り出したタームと内部状態との関係により現在処理中の
該行を３Ｄボタン化の対象とする必要がないと判断され
たときには、内部状態を"ａｂｏｒｔ"にして判断ブロッ
ク１１２の分岐Ｙｅｓに進み、次いでステップ１１４で
は該行のaid-keyレコードの各フィールドにはkeytype=n
ull，keycount=0，deltype=null，delcount=0を格納す
る。各フィールドのこのような値は後続のステップ２０
０，３００では無意味なレコードと判断されるようにな
っているので（後述）、結果として該行の処理を失敗
（ａｂｏｒｔ）したことを示せる訳である。このような
失敗処理が必要なのは、３２７０画面上のＰＦキーが必
ずしもユーザが３Ｄボタン化を要求しているとは限らな
いからである。例えば、画面上のテキスト文の中で単に
ＰＦキーに係る文字列が引用されているに過ぎない場合
がａｂｏｒｔに該当する。また、図２２の画面内のカレ
ンダの各日付はpfprefixが省略されたタイプのＰＦキー
の候補ではあるが、３Ｄボタン化の対象とは言えない。
このようなａｂｏｒｔ処理を要する場合、行の上にＰＦ
キーが煩雑に配置されているだけで、ＰＦキーを含む文
字列がaidkeyexpressionを形成していないのが常であ
る。

【００８４】なお、包括的ステップ１００でいう「ター
ム」とは、デリミッタ（delim2やdelim0）で区切られた
文字列のことである。例えば図８(a)に示すようにｒ行
目が"ＰＦ１＝Ｈｅｌｐ＿ＰＦ２＝…"からなる文字列で
構成される場合、ｒ行目から取り出されるタームは、図
８(b)に示すように、"ＰＦ１"，"＝"，"Ｈｅｌｐ"，"Ｐ
Ｆ２"…である。なお、"ＰＦ１"と"Ｈｅｌｐ"の間の"
＝"と、"Ｈｅｌｐ"と"ＰＦ２"の間の"＿"（ブランク）
はともにデリミッタである。但し、ブランクは３Ｄボタ
ン化処理するには無意味な文字であることが経験的に判
っているので、本実施例ではデリミッタがブランクの場
合にはタームとして取り出さないようにしている。

【００８５】図９は、ステップ１０６乃至１１２で形成
される閉ループを状態遷移図の形態表現したものであ
る。同図における各状態間の遷移を以下に説明してお
く。当業者であれば、処理対象となっている行について
の変数keytype，keycount，deltype，delcountの値を得
るための具体的なプログラム構成を、この状態遷移図か
ら充分理解できるであろう。

【００８６】状態０：行の先頭桁（すなわち左端の桁）
では前の内部状態（すなわち前に取り出したターム）を
持たないので、ニュートラル（neutral）の状態（状態
０）で待機する。状態０において、次タームとしてpfke
yid以外の文字列が取り出されると、状態０に戻る（矢
印α）。何故なら、ＰＦキーの配列によって水平型及び
垂直型の判定を行うのであり、その他の文字列には関心
がないからである。また、状態０において、次タームと
して取り出した文字列がaidkeytermの定義（式(4)参
照）に合致するときは、状態１に遷移する（矢印β）。
この場合は、該行で新たにaidkeyexpressionを見つけ出
したのと等価なので、keycountを１つインクリメントす
る。また、該aidkeytermがpfkeyitem（すなわちＰＦキ
ー）であれば、そのタイプ（すなわちpfprefix）をkeyt
ypeとして仮に保持するとともに、そのpfnumberも保持
しておく。

【００８７】状態１：状態１は、前回取り出したターム
がpfkeyidの場合の内部状態である。状態１において、
次タームとして取り出した文字列がdelim1であれば、状
態１'に遷移する（矢印γ）。そして、次々タームがpfn
umberであれば、再び状態１に戻る（矢印δ）。この場
合は、同一ファンクションのＰＦキーが重複（duplicat
e）したに過ぎないので、keytypeの値を変更せず、keyc
ountもインクリメントしない。例えば図２０に示す３２
７０画面において、ＰＦキー"PF8"の次にデリミッタ"/"
を隔ててpfnumber"10"が続き、"PF3"の次に"/"を隔て
て"12"が続く場合がこれに該当する。また、状態１にお
いて、次タームがaidkeytermであれば、状態１に戻る
（矢印ε）。この場合は、新たにaidkeyexpressionを見
つけ出したのと等価なので、keycountを１つインクリメ
ントするとともに、前回のpfnumberを廃棄して今回のも
のを保持する。但し、aidkeytermがpfkeyitemの場合
は、そのＰＦキーのタイプ（すなわちpfprefix）が既に
格納しているkeytypeと同一であることと、そのpfnumbe
rが前回保持したpfnumberよりも大きな値であること
（すなわちpfnumberが正順であること）が条件である。
また、状態１において、次タームがdelim2であれば、該
delim2がdeltypeと一致することを条件に、状態２に遷
移する（矢印ζ）。但し、該行において最初に状態２に
遷移する場合は、deltypeとしてdelim2の値を仮に保持
してから状態２に遷移する。また、遷移の度に、必ずde
lcountを１つインクリメントする。また、状態１におい
て、次タームがaidkeytermやdelim2以外の文字列であれ
ば、該タームはfunction（又はその一部）であると判断
して、状態３に遷移する（矢印η）。また、状態１にお
いて、次タームがpfkeyitemであって、そのpfprefixが
前回までのkeytypeと異なっていたり、そのpfnumberが
前回保持したものよりも小さい値（すなわち逆順）であ
る場合は、矢印θを経て失敗（ａｂｏｒｔ）処理する。
このようなタームの配列を持つ行は、ＰＦキーと同じ文
字列が単に煩雑に配置されているに過ぎず、３Ｄボタン
化処理する上で関心が低いと考えられるからである。ま
た、状態１において、次タームがdelim2であって前回ま
でのdeltypeとは一致しないものである場合、矢印κを
経てａｂｏｒｔ処理する。このようなタームの配列を持
つ行は、aidkeytermやdelim2と同じ文字列が単に煩雑に
配列されているに過ぎず、３Ｄボタン化の対象外と考え
られるからである

【００８８】状態２：状態２は、前回取り出したターム
がdelim2の場合の内部状態である。状態２において、次
タームがaidkeytermであれば、状態１に遷移する（矢印
λ）。但し、aidkeytermがpfkeyitemの場合は、pfprefi
xが前回までのkeytypeと同一であることと、そのpfnumb
erが正順であることが条件である。また、状態１に遷移
する度に、必ずkeycountを１つインクリメントするとと
もに、前回のpfnumberを廃棄して今回のものを保持す
る。また、状態２において、次タームがaidkeyterm以外
の文字列であれば、該タームはfunction（又はその一
部）であると判断して、状態３に遷移する（矢印μ）。
また、状態２において、次タームがpfkeyitemであっ
て、そのpfprefixが前回までのkeytypeと異なっていた
り、そのpfnumberが逆順である場合は、３Ｄボタン化の
関心は低いので、前述同様に失敗（ａｂｏｒｔ）処理す
る（矢印ξ）。

【００８９】状態３：状態３は、前回取り出したターム
がfunctionに係る文字列である場合の内部状態である。
状態３において、次タームがaidkeytermであれば、状態
１に遷移する（矢印π）。但し、aidkeytermがpfkeyite
mの場合は、pfprefixが前回までのkeytypeと同一である
ことと、そのpfnumberが正順であることが条件である。
また、状態１に遷移する度に、必ずkeycountを１つイン
クリメントするとともに、前回のpfnumberを廃棄して今
回のものを保持する。また、状態３において、次ターム
がaidkeyterm以外の文字列であれば、該タームはfuncti
on（又はその一部）であると判断して、状態３に戻る
（矢印σ）。また、状態３において、次タームがpfkeyi
temであって、そのpfprefixが前回までのkeytypeと異な
っていたり、そのpfnumberが逆順である場合は、３Ｄボ
タン化の関心は低いので、前述同様に失敗（ａｂｏｒ
ｔ）処理する状態に遷移する（矢印τ）。

【００９０】ａｂｏｒｔ：ａｂｏｒｔとは、上述したよ
うに、状態１乃至３において処理中の行がもはや３Ｄボ
タン化の対象外であると判断されたときに遷移する内部
状態である。この場合、図７に示すフローチャートで
は、判断ブロック１１２の分岐Ｙｅｓに進んで閉ループ
を抜けて、該行の処理を失敗に終わらせる。次いで、ス
テップ１１４では、該行のaid-keyレコードの各フィー
ルドにはkeytype=null，keycount=0，deltype=null，de
lcount=0を格納することによって、後続の包括的ステッ
プ２００，３００では該行が３Ｄボタン化サブルーチン
にとって関心がないものであることを示すようになって
いる。

【００９１】このようにして作成されたaid-keyionリス
ト（図６(b)参照）は、物理的にはメイン・メモリ４の
中に置かれ、後の処理において３Ｄボタン化サブルーチ
ンは適宜読み出すことができる。

【００９２】(2) 水平型のaid-keyの３Ｄボタン化 次いで、作成されたaid-keyリストを参照して、プレゼ
ンテーション・スペース中に水平型に配列されたaidkey
expressionが存在するか否かを判別して、存在すれば、
該当するAttention ID Keyを３Ｄボタン化表示に変換す
る。図１０は該ステップ２００の詳細な処理手順につい
て図解している。以下、このフローについて説明してお
く。

【００９３】包括的ステップ１００を終了すると、処理
は経由点Ｐを経て包括的ステップ２００に進む。

【００９４】まず、判断ブロック２０２では、水平型の
Attention ID Keyの３Ｄボタン化をユーザが指定してい
るか否かを判断する。結果が肯定的であれば次ステップ
２０４に進む。一方、結果が否定的であれば、分岐Ｎｏ
に進んで後続のステップをスキップして、包括的ステッ
プ１００から抜け出す（経由点Ｑ）。ブロック２０２
は、３Ｄボタン化サブルーチンを利用するユーザの中に
はそもそもAttention IDKeyの３Ｄボタン化を希望しな
い者がいることを考慮して設けられたものである（後述
の判断ブロック３０２，４０４，５０２も同様）。ユー
ザの該指定操作は、例えば３２７０エミュレーション・
プログラムのＰＣへの導入時に対話形式で行われる。

【００９５】ステップ２０４では、aid-keyリストを最
終行から上向きにスキャンして、keycountが最大の行
（すなわちaidkeyexpressionを最も多く含む行）を捜し
出す。最終行から捜し始めるのは、例えば図１５乃至図
２０，図２３乃至図２７から推察されるように、「水平
型の配列をしたaidkeyexpressionは３２７０画面の下方
に多く存在する」ということが経験的に判っているから
である。なお、処理速度を向上させるなどの目的で、ユ
ーザが指定した行数だけしかaid-keyリストをスキャン
しないようにしてもよい。

【００９６】ステップ２０４において該当する行が見つ
け出されれば、ステップ２０６では、該行、及びその上
下でaidkeyexpressionを含む行に対して３Ｄボタン化処
理を行う。このとき、３Ｄボタン化サブルーチンは、プ
レゼンテーション・スペース上の行数や桁数など３Ｄボ
タン化に必要な情報を、オペレーティング・システム３
２の定義に合致した形式（すなわち、３Ｄボタンの起点
の座標、横幅、高さなどの情報）に変換して渡すととも
に、オペレーティング・システム３２に対して３Ｄボタ
ンの表示を要求する。そして、オペレーティング・シス
テムが該要求に応じてプレゼンテーション・スペースの
内容を変換して画面バッファ８に書き込むことによっ
て、３２７０画面上の所望の文字列が３Ｄボタンに切り
換えられる。なお、３Ｄボタン化処理の済んだ行につい
ては、そのaid-keyレコードのフラグをリセットしてお
く。

【００９７】判断ブロック２０８では、前ステップ２０
４において該当する行が実際に見つけられたか否かを判
別する。結果が肯定的であれば、該画面内にはもはや水
平型の処理を行う必要はないものとみなして、分岐Ｙｅ
ｓに進み、包括的ステップ２０４から抜け出す（経由点
Ｑ）。一方、結果が否定的であれば、後続のステップ２
１０に進み、今度は先頭行からユーザが指定した行数だ
けaid-keyリストをスキャンして、その中でkeycountが
最大の行を捜す。次いで、ステップ２１２では、該当す
る行と、その上下でpfkeytitemを含む行に対して３Ｄボ
タン化処理を行ってから、包括的ステップ２００を終了
する（経由点Ｑ）。なお、ステップ２１２における処理
の内容は、ステップ２０６と略同一なので、ここでは説
明を省略する。

【００９８】図３０，図３１及び図３２には、水平型の
配列をしたaidkeyexpressionを３Ｄボタン表示に変換し
た３２７０画面の例を示してある。同図では、aidkeyex
pression全体を３Ｄボタン化しているが、１部の文字列
（例えばaidkeyterm）だけしか表示を変換させないよう
にすることはプログラマブルである。

【００９９】(3) 垂直型のaid-keyの３Ｄボタン化 次いで、作成されたaid-keyリストを参照して、プレゼ
ンテーション・スペース中に垂直型に配列されたaidkey
expressionが存在するか否かを判別して、存在すれば、
該当するAttention ID Keyを３Ｄボタン化表示に変換す
る。図１１は該ステップ３００の詳細な処理手順につい
て図解している。以下、このフローについて説明してお
く。

【０１００】包括的ステップ２００を終了すると、処理
は経由点Ｑを経て包括的ステップ３００に進む。

【０１０１】まず、判断ブロック３０２では、垂直型の
Attention ID Keyの３Ｄボタン化をユーザが指定してい
るか否かを判断する。結果が否定的であれば、分岐Ｎｏ
に進み、包括的ステップ３００から抜け出す（経由点
Ｒ）。一方、結果が肯定的であれば次ステップ３０４に
進む。

【０１０２】ステップ３０４では、既に包括的ステップ
２００で３Ｄボタン化処理された行を除いた残りのaid-
keyレコードについて垂直型の条件に適合するか否かを
順次調べ、適合するaid-keyレコードに係る行番号を垂
直型リスト（図示しない）に記録する。各行が３Ｄボタ
ン化処理済みか否かは各aid-keyレコードのフラグによ
って確認できる。また、垂直型の条件は、上述したよう
に、 (b-1) aidkeyexpressionを１つしか含まない行が複数連
続していること。 (b-2) pfkeyidの左端の桁位置と右端の桁位置の少なく
とも一方が各行とも同一であること。 (b-3) 各行のdelim2が一致すること。 (b-4) pfnumberは上段の行から下段に向かって正順に配
列されていること。 の４つである。条件(b-1)については、keycountが１のa
id-keyレコードが連続しているか否かを調べることによ
り判断できる。条件(b-2)については、各aid-keyレコー
ドのstart，endの各フィールドの値を比較することによ
り判断できる。また、条件(b-3)と(b-4)に反する行は、
aid-keyレコードを作成する段階でａｂｏｒｔ処理され
て、既に条件(b-1)を満たさないように変数keytype…が
設定されている。

【０１０３】次いで、ステップ３０６では、垂直型リス
トに記録された各行を調べ、最も頻出するＰＦキーのタ
イプであり、且つpfkeyitemの開始桁として最も多いも
のと一致する行のみを垂直型リストに残して、他のレコ
ードを廃棄する。

【０１０４】次いで、判断ブロック３０８では、ステッ
プ３０６で余分なレコードを廃棄した結果、未だ垂直型
リストに２行以上残っているか否かを判断する。残った
記録が１行以下であれば、条件(b-1)の「…行が複数連
続している」という点を満たしていないことになるの
で、分岐Ｎｏに進んで、包括的ステップ３００から抜け
出す（経由点Ｒ）。一方、結果が肯定的であれば、次ス
テップ３１０に進む。

【０１０５】ステップ３１０では、垂直型リストに残っ
ている各行毎に、ユーザの指定に基づいて３Ｄボタン化
処理を行う。文字列の３Ｄボタン化は、３Ｄボタン化サ
ブルーチンがオペレーティング・システム３２に対して
必要な情報とともに要求を送るとともに、オペレーティ
ング・システム３２が所定の描画処理を行うことによっ
てなされる（前述）。また、３Ｄボタン化処理の済んだ
行については、そのaid-keyレコードのフラグをリセッ
トしておく。なお、ここでいう「ユーザの指定」とは、
３Ｄボタン化する開始桁や終了桁などのことであり、pf
keyitemだけでなくfunctionに係る文字列をも３Ｄボタ
ン化の対象に指定できる。例えば図３０には、垂直型の
配列をしたaidkeyexpressionを３Ｄボタン表示に変換し
た３２７０画面の例を示しているが、３Ｄボタン化する
領域をaidkeytermに限ったり、あるいは３Ｄボタン化す
る領域の長さを最長のものに統一するこうにすることは
プログラマブルである。

【０１０６】(4) カーソル位置指定型の領域の３Ｄボタ
ン化 次いで、プレゼンテーション・スペース中で既に３Ｄボ
タン化された行を除いた残りの領域で、カーソル位置指
定型が存在すれば、さらに３Ｄボタン化する。図１２は
該ステップ４００の詳細な処理手順について図解してい
る。以下、このフローについて説明しておく。

【０１０７】包括的ステップ３００を終了すると、処理
は経由点Ｒを経て包括的ステップ４００に進む。

【０１０８】まず、ステップ４０２では、プレゼンテー
ション・スペース中の各入力可能フィールド毎に１つの
レコード（以下、「入力可能フィールド・レコード」と
いう）を作成して、入力可能フィールド単位でプレゼン
テーション・スペースを管理できるようにする。入力可
能フィールド・レコードは、図１３(a)に示すように、
対応する入力可能フィールドの開始行（row：ｒ），開
始桁（column：ｃ），長さ（length：ｌ）の各々を格納
しておくために、３つのフィールドで構成される。ま
た、図１３(b)には、１画面分の入力可能フィールド・
レコードの集合（以下、「入力可能フィールド・リス
ト」という）が示してある。１画面分の入力可能フィー
ルド・レコードの個数は、行毎に作成されるaid-keyレ
コードと違って一定でないので、該リストは、プレゼン
テーション・スペース中の入力可能フィールドの個数を
計数し保持しておくためのカウンタを備えている。当業
者であれば、プレゼンテーション・スペースを先頭行の
左端桁からスキャンしていくことによって容易に入力可
能フィールド・リストを作成できる、ということを理解
できるであろう。なお、入力可能フィールド・リスト
は、次の包括的ステップ５００の中でも利用される（後
述）。

【０１０９】次いで、判断ブロック４０４では、カーソ
ル位置指定型に対する３Ｄボタン化処理をユーザが指定
しているか否かを判断する。結果が否定的であれば、分
岐Ｎｏに進み、包括的ステップ４００から抜け出す（経
由点Ｓ）。一方、結果が肯定的であれば次ステップ４０
６に進む。

【０１１０】次いで、ステップ４０６では、プレゼンテ
ーション・スペースの先頭行の左端桁からスキャンして
いくことによって、予め指定されているキーワードの組
を検索する。そして、見つけ出された「キーワードの
組」毎にその位置を格納するためのレコード（キーワー
ド・レコード）を作成する（以下、キーワード・レコー
ドをリスト・アップしたものを「キーワード・リスト」
という）。ここで、「予め指定されているキーワードの
組」とは、図２４乃至図２７に示すように、"cursor"
と"Enter"のような２以上の単語の組合せであり、且
つ、組合せを構成する全ての単語が同一行又は連続する
二行（但し、空白行の挿入は許す）の中に存在するもの
をいう（前述）。

【０１１１】次いで、ステップ４０８では、入力可能フ
ィールド・リストの中から、既に３Ｄボタン化処理を行
った行に関する入力可能フィールド・レコードを廃棄す
る。何故なら、このような行は再度３Ｄボタン化処理す
る必要がなく、余分なレコードと考えられるからであ
る。該処理は、各入力可能フィールドのｒ値に対応する
aid-keyレコードのフラグがリセットされているか否か
を検査することによって行える。

【０１１２】次いで、ステップ４１０では、キーワード
・リストの中から、既に３Ｄボタン化処理を行った行に
関する「キーワードの組」を廃棄する。廃棄する理由は
ステップ４０８と同様である。該処理は、各「キーワー
ドの組」の行位置に対応するaid-keyレコードのフラグ
を検査することによって行える。

【０１１３】次いで、判断ブロック４１２では、ステッ
プ４１０で余分のレコードを廃棄した結果、キーワード
・リスト中に未だ「キーワードの組」が残っているか否
かを判断する。もはや何も残っていなければ、処理中の
３２７０画面中にはカーソル位置指定型の領域は存在し
ないことになるので、分岐Ｎｏに進み、包括的ステップ
４００から抜け出す（経由点Ｓ）。一方、まだ「キーワ
ードの組」が残っていれば、次ステップ４１４に進む。

【０１１４】次いで、ステップ４１４では、ステップ４
０８で余分なレコードを廃棄した結果、未だ入力可能フ
ィールド・リストに残っている入力可能フィールド・レ
コードに対して、カーソル位置指定型の条件を満たすか
否かを順次調べる。該条件とは、フィールドの構造が一
致する行が連続していること（但し、空白行の挿入は許
す）と、各行が入力可能フィールドを少なくとも１つ含
んでいることである。さらに、該条件を満たす行に対し
ては、入力可能フィールドが複数行に跨っていないか否
か、及び該フィールドが文字列を含まない空白フィール
ドであるか否かを検査する。１つの入力可能フィールド
が複数行に跨っていればユーザが３Ｄボタン表示を求め
ない場合が多いし、空白フィールドであればそもそも３
Ｄボタン化すべき対象領域ではないからである。そし
て、全ての条件をクリアした入力可能フィールドについ
て３Ｄボタン化処理を行う。文字列の３Ｄボタン化は、
３Ｄボタン化サブルーチンがオペレーティング・システ
ム３２に対して必要な情報とともに要求を送るととも
に、オペレーティング・システム３２が所定の描画処理
を行うことによってなされる（前述）。また、３Ｄボタ
ン化処理の済んだ行については、そのaid-keyレコード
のフラグをリセットしておく。

【０１１５】なお、図３１及び図３２には、カーソル位
置指定型の領域を３Ｄボタン表示に変換した３２７０画
面の例を示してある。

【０１１６】(5) メニュー・バー型の領域の３Ｄボタン
化 次いで、プレゼンテーション・スペースの先頭行にメニ
ュー・バーが存在すれば、メニュー・バー内の各メニュ
ーを３Ｄボタン化する。図１４は該ステップ５００の詳
細な処理手順について図解している。以下、このフロー
について説明しておく。

【０１１７】包括的ステップ４００を終了すると、処理
は経由点Ｓを経て包括的ステップ５００に進む。

【０１１８】まず、判断ブロック５０２では、メニュー
・バー型の３Ｄボタン化処理をユーザが指定しているか
否かを判断する。結果が否定的であれば、分岐Ｎｏに進
み、３Ｄボタン化サブルーチンを終了する。一方、結果
が肯定的であれば、次ステップ５０４に進む。

【０１１９】判断ブロック５０４では、入力可能フィー
ルド・リストを参照することによって、プレゼンテーシ
ョン・スペースの１行目に入力可能フィールドが２個以
上存在するか否かを検査する。次いで、判断ブロック５
０６では、入力可能フィールド・リストを参照すること
によって、プレゼンテーション・スペースの２行目の入
力可能フィールドは０個か否かを判断する。両ブロック
５０４，５０６の結果がともに肯定的であることがプレ
ゼンテーション・スペース中にメニュー・バー型の領域
が存在するための必要条件である。したがって、ブロッ
ク５０４又は５０６のいずれかで否定的な結果を得る
と、分岐Ｎｏに進み、後続のステップをスキップして、
３Ｄボタン化サブルーチンを終了する。一方、両ブロッ
ク５０４，５０６の結果がともに肯定的であれば、次ス
テップ５０８に進む。

【０１２０】判断ブロック５０８では、１行目のaid-ke
yレコードのフラグを参照して、メニュー・バーの候補
である１行目が既に３Ｄボタン化されているか否かを判
断する。結果が肯定的であれば、もはや１行目を処理す
る必要はないので、分岐Ｙｅｓに進み、次ステップ５１
０をスキップして、３Ｄボタン化サブルーチンを終了す
る。一方、結果が否定的であれば、次ステップ５１０に
進む。

【０１２１】ステップ５１０では、入力可能フィールド
・リストに基づいて、１行目の入力可能フィールドのう
ち最終行^*又は２行目と連続していないフィールドを全
て３Ｄボタン化する。３Ｄボタン化は、３Ｄボタン化サ
ブルーチンがオペレーティング・システム３２に対して
必要な情報とともに要求を送るとともに、オペレーティ
ング・システム３２が所定の描画処理を行うことによっ
てなされる（前述）。このとき、元々表示されるべき文
字列（メニューの内容）を対応する３Ｄボタン上に上書
き表示するようにしてもよい。なお、図３３には、メニ
ュー・バーを３Ｄボタン表示に変換した例を示してあ
る。（＊：３２７０データ・ストリームの定めるところ
によれば、画面左上（第１行目，第１桁目）にフィール
ド・アリトビュートが存在しない場合には、画面右上
（最終行，最右桁）のフィールドの属性を継承すること
になっているためである。）

【０１２２】しかして、ステップ５１０の処理が終わる
と、３Ｄボタン化サブルーチンを抜けて、３２７０エミ
ュレーション・プログラムのメイン・ルーチンに復帰す
る。

【０１２３】以上のようにして、旧態依然とした２次元
的な３２７０画面は、３Ｄボタン表示を含む画面に変換
される。また、オペレーティング・システム３２は、ユ
ーザが任意の３Ｄボタン上でクリック操作などを行う
と、該事象が発生したことを３２７０端末エミュレータ
３３に対して通知することができる（Ｃ−２項参照）。

【０１２４】Ｄ−３．画面変換の解除キー 前項では、旧態依然としたエミュレーション画面を３ボ
タン表示画面に変換するための処理手順について説明し
た。しかしながら、必ずしも変換後の画面は、ユーザに
とっては必ずしも好ましいものとは限らない。例えば、
画面が複雑化して却って見づらくなる場合や、ユーザの
意図とは異なる変換結果となる場合が有りうるからであ
る。このような場合のために、３２７０端末エミュレー
タ３３は、変換画面を解除するための『解除キー』若し
くはこれと同等の手段を持つようにしてもよい。ユーザ
は、このキーを押すことによって、変換前の本来の３２
７０画面（すなわちプレゼンテーション・スペースの内
容と略同一の画面）に戻る。なお、再度このキーを押す
ことによって再び変換後の画面が表示されるようにして
もよい。

【０１２５】以上、特定の実施例を参照しながら、本発
明について詳解してきた。しかしながら、本発明の要旨
を逸脱しない範囲で当業者が該実施例の修正や代用を成
し得ることは自明である。すなわち、例示という形態で
本発明を開示してきたのであり、限定的に解釈されるべ
きではない。本発明の要旨を判断するためには、冒頭に
記載した特許請求の範囲の欄を参酌すべきである。

【０１２６】

【発明の効果】以上詳記したように、本発明によれば、
ホスト・アプリケーションから送られてくるテキスト・
ベース、キャラクタ・ベースの画面情報を、ユーザがプ
ログラムを何ら修正・変更することなく、ＧＵＩ風の画
面表示（ＧＵＩ-flavored hostscreen）に変換するとと
もに、ユーザのマウス型入力（Mouse-oriented operati
on）を可能にするための画面変換方法を提供することが
できる。したがって、本発明を３２７０端末エミュレー
タにインストールすれば、テキスト・ベースの３２７０
画面内に存在するAttention ID Keyなどをを３Ｄボタン
表示に変換することができ、ユーザの使い勝手が頗る向
上する。

【図面の簡単な説明】

【図１】図１は、本発明の実施に供されるパーソナル・
コンピュータ（ＰＣ）２０のハードウェア構成を概観的
に示したものである。

【図２】図２は、メイン・メモリ２上にロードされてい
るソフトウェアの階層的構成を概略的に示したものであ
る。

【図３】図３は、ホスト・システムから送られてくる３
２７０データ・ストリームを３２７０端末エミュレータ
が処理するためのフローを概略的に示した図である。

【図４】図４は、ＰＣ側で入力された情報を３２７０デ
ータ・ストリームとしてホスト・システムに送るための
フローを概略的に示した図である。

【図５】図５は、テキスト・ベースの３２７０画面を３
Ｄボタン表示された画面に変換するための処理手順をフ
ローチャートで示した図である。

【図６】図６は、プレゼンテーション・スペース中のai
dkeyexpressionに関する情報を格納するためのレコード
（aid-keyレコード）のデータ構造を示す図である。よ
り具体的には、図６(a)はaid-keyレコード単体の構造
（すなわち該レコードを構成する各フィールド）を示す
図、図６(b)は１画面分のaid-keyレコードの集合（aid-
keyリスト）を示す図である。

【図７】図７は、プレゼンテーション・スペース中のai
dkeyexpressionを検索するためのステップ１００の詳細
な処理手順、すなわち各行毎にaid-keyレコードを作成
するための処理手順を示した図である。

【図８】図８は、プレゼンテーション・スペース中の１
行からタームを順次取り出していく様子を示す図であ
り、より具体的には図８(a)は"ＰＦ１＝Ｈｅｌｐ＿ＰＦ
２＝…"からなる文字列で構成されるｒ行目を示す図、
図８(b)はターム"ＰＦ１"，"＝"，"Ｈｅｌｐ"，"ＰＦ
２"…がその各々の開始桁の情報とともにｒ行目から取
り出されることを示す図である。

【図９】図９は、図７のフローチャート中のステップ１
０６乃至１１２で形成される閉ループを状態遷移図の形
態で表現した図である。

【図１０】図１０は、３２７０画面の表示を変換するた
めの処理手順を示す図であり、より具体的には、aid-ke
yレコードを参照することによってプレゼンテーション
・スペース上で水平型に配列したAttention ID Keyを見
出だして３Ｄボタン化処理するステップ２００を詳解し
た図である。

【図１１】図１１は、３２７０画面の表示を変換するた
めの処理手順を示す図であり、より具体的には、aid-ke
yレコードを参照することによってプレゼンテーション
・スペース上で垂直型に配列したAttention ID Keyを見
出だして３Ｄボタン化処理するステップ３００を詳解し
た図である。

【図１２】図１２は、３２７０画面の表示を変換するた
めの処理手順を示す図であり、より具体的には、プレゼ
ンテーション・スペース上でカーソル位置指定型に配列
した領域を３Ｄボタン化処理するステップ４００を詳解
した図である。

【図１３】図１３は、ステップ４００で作成され且つ利
用される入力可能フィールド・レコードの構造を示す図
であり、より具体的には図１３(a)は該レコード単体の
構造（すなわちレコードを構成する各フィールド）を示
す図、図１３(b)は１画面分の入力可能フィールド・レ
コードの集合（入力可能フィールド・リスト）を示す図
である。

【図１４】図１４は、プレゼンテーション・スペースの
表示を変換するための処理手順を示す図であり、より具
体的には、プレゼンテーション・スペース上でメニュー
・バー型に配列した領域を３Ｄボタン化処理するステッ
プ５００を詳解した図である。

【図１５】図１５は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixは"PF"、pfnumberは1…12、delim2は"_"（ブラ
ンク）である。

【図１６】図１６は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixは"PF"、pfnumberは1…12、delim2は"_"（ブラ
ンク）である。

【図１７】図１７は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixは"F"、pfnumberは1…12、delim2は"="である。

【図１８】図１８は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixはデフォルト、pfnumberは1…12、delim2は"="
である。

【図１９】図１９は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合のプレゼン
テーション・スペースの例である。同画面において、ai
dkeytermはpfkeyitemタイプ、pfprefixはデフォルト、p
fnumberは1…12、delim2は"-"である。

【図２０】図２０は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixは"PF"、pfnumberは1…12、delim1は"/"、delim
2は"_"（ブランク）である。

【図２１】図２１は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
aidkeyexpressionが水平型に配列された場合の例であ
る。同画面において、aidkeytermはpfkeyitemタイプ、p
fprefixはデフォルト、pfnumberは1…12、delim2は"="
である。

【図２２】図２２は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型及び垂直型のaidkeyexpressionが混在している場
合の例である。同画面において、垂直型に係るaidkeyte
rmはpfkeyitemタイプ、pfprefixは"PF"、pfnumberは1…
12、delim2は"_"（ブランク）である。

【図２３】図２３は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型配列と垂直型配列とが混在した場合の例である。
同画面において、水平型のaidkeytermはpfkeyitemタイ
プ、pfprefixは"PF"、pfnumberは1…12、delim2は"_"
（ブランク）であり、また、垂直型のaidkeytermはpfke
yitemタイプ、pfprefixは"PF"、pfnumberは1…12、deli
m2は"_"（ブランク）である。

【図２４】図２４は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型配列とカーソル位置指定型配列とが混在した場合
の例である。同画面において、水平型のaidkeytermはpf
keyitemタイプ、pfprefixは"PF"、pfnumberは1…12、de
lim2は"="である。

【図２５】図２５は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型配列とカーソル位置指定型配列とが混在した場合
の例である。同画面において、水平型のaidkeytermはpf
keyitemタイプ、pfprefixはデフォルト、pfnumberは1…
12、delim2は"="である。

【図２６】図２６は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型配列とカーソル位置指定型配列とが混在する場合
の例である。同画面において、水平型のaidkeytermはpf
keyitemタイプ、pfprefixはデフォルト、pfnumberは1…
12、delim2は"="である。

【図２７】図２７は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
水平型配列とカーソル位置指定型配列とが混在する場合
の例である。同画面において、水平型のaidkeytermはpf
keyitemタイプ、pfprefixは"PF"、pfnumberは1…12、de
lim2は"="である。

【図２８】図２８は、ホスト・アプリケーションが提供
する３２７０画面の例を示す図である。より詳細には、
メニュー・バー型の例である。

【図２９】図２９は、図２２に示す３２７０画面に対し
て３Ｄボタン化処理を行った例である。

【図３０】図３０は、図２３に示す３２７０画面に対し
て３Ｄボタン化処理を行った例である。

【図３１】図３１は、図２４に示す３２７０画面に対し
て３Ｄボタン化処理を行った例である。

【図３２】図３２は、図２７に示す３２７０画面に対し
て３Ｄボタン化処理を行った例である。

【図３３】図３３は、図２８に示す３２７０画面に対し
て３Ｄボタン化処理を行った例である。

【図３４】図３４は、パーソナル・コンピュータの利用
態様の一例を示した図であり、より具体的には、が、Ｅ
Ｓ９０００やＳ／３９０などのホスト・システムとネッ
トワークを介して接続されて、ホスト・メインフレーム
上で稼働するグラフィック適用業務プログラムの入出力
端末（例えば３２７０端末）として利用される様子を示
した図である。

【図３５】図３５は、パーソナル・コンピュータとホス
ト・システムとが、通信データ（例えば３２７０データ
・ストリーム）を双方向通信可能な通信線（例えば同軸
ケーブル）を介して連絡している様子を示した図であ
る。

【図３６】図３６は、ビットマップ表示及びマルチ・ウ
ィンドウをサポートするオペレーティング・システムが
提供する画面の例を示した図である。

【符号の説明】

１…メインＣＰＵ、２…アドレス／データ・バス、３…
メモリ・バス、４…メイン・メモリ、５…ＲＯＭ、６…
ＨＤＤ、７…ビデオ・コントローラ（ＶＧＡ）、８…画
面バッファ（ＶＲＡＭ）、１０…ＬＣＤコントローラ／
ＤＡ変換回路、１１…ＬＣＤ、１２…ＣＲＴ、１３…シ
リアル・ポート、１４…パラレル・ポート、１５…通信
用アダプタカード。

───────────────────────────────────────────────────── フロントページの続き (56)参考文献 特開 平５−289964（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 3/14 370 G09G 5/00 510

Claims (8)

(57)【特許請求の範囲】
1. 【請求項１】画面情報を変換して表示する画面表示変換
   方法において、前記画面情報内で表示形式を変換したい
   文字列（以下、Attention ID Keyという。Attention ID
   KeyにはＰＦｎ，ＦＰｎ，Ｆｎ，ｎ，ＰＡｎ等が挙げら
   れる。但し、ｎは１乃至２４の整数）を含んで一体とし
   て取り扱われる文字列（以下、aidkeyexpressionとい
   う）を所定の条件式に基づいて検索する第１の段階と、
   １行中にaidkeyexpressionを複数個含む行を水平型配列
   の行と推定する第２の段階と、水平型配列と推定された
   行のうちでAttention ID keyとしてＰＦｎ，ＦＰｎ，Ｆ
   ｎ，ｎ又はＰＡｎを含むaidkeyexpressionを１行中に２
   以上含み且つｎが左から右に向かって正順に配列されて
   いない行については該推定を否定する第３の段階と、水
   平型配列の行に含まれる各Attention ID Keyを所定の表
   示形式に変換する第４の段階と、を含むことを特徴とす
   る画面表示変換方法。
2. 【請求項２】画面情報を変換して表示する画面表示変換
   方法において、前記画面情報内で表示形式を変換したい
   文字列（以下、Attention ID Keyという。Attention ID
   keyには、ＰＦｎ，ＦＰｎ，Ｆｎ，ｎ，ＰＡｎ等が挙げ
   られる。但し、ｎは１乃至２４の整数）を含んで一体と
   して取り扱われる文字列（以下、aidkeyexpressionとい
   う）を所定の条件式に基づいて検索する第１の段階と、
   aidkeyexpressionを１つだけ含む行が複数連続している
   か否かを判定して、該連続している各行を垂直型配列の
   行と推定する第２の段階と、垂直型配列と推定された行
   のうちでＰＦｎ，ＦＰｎ，Ｆｎ又はｎを含む行が２以上
   ある場合には各行でＰＦｎ，ＦＰｎ，Ｆｎ又はｎの画面
   左端若しくは右端からの位置が一致していなければ該推
   定を否定する第３の段階と、垂直型配列と推定された行
   のうちでＰＦｎ，ＦＰｎ，Ｆｎ又はｎを含む行が２以上
   ある場合には各行のｎが画面上から下に向かって正順に
   配列していなければ該推定を否定する第４の段階と、垂
   直型配列の行に含まれる各Attention ID Keyを所定の表
   示形式に変換する第５の段階と、を含むことを特徴とす
   る画面表示変換方法。
3. 【請求項３】前記所定の条件式がdelim0，aidkeyterm，
   delim2，functionの文字列の順で構成される文字列であ
   ることを特徴とする請求項１又は２に記載の画面表示変
   換方法。但し、delim0とは、aidkeyexpression間を画定
   するための文字であり、ブランクが用いられる。また、
   aidkeytermとは、画面表示を変換させたい文字列そのも
   のであり、ＰＦｎ，ＦＰｎ，Ｆｎ，ｎ，ＰＡｎなどのフ
   ァンクション・キー（但し、ｎは正の整数）やClearキ
   ー，EnterキーなどのAttention ID Keyで構成される。
   また、delim2とは、aidkeytermと後続のfunctionとを結
   び付けるための文字であり、ブランクの他、"＝"，"
   −"，"："が用いられ、繰り返し用いられてもよい。ま
   た、functionとは、aidkeytermの機能を説明するための
   文字列のことである。
4. 【請求項４】テキストとフィールド・アトリビュート
   （但し、フィールド・アトリビュートとは画面上にフィ
   ールドを設定して各フィールドが入力可能フィールドか
   入力禁止フィールドか等を定義するための値）とで構成
   される画面情報を変換して表示する画面表示変換方法に
   おいて、予め指定された文字列の組合せが前記画面情報
   内で１行中又は連続する２行中に存在するか否かを判定
   する第１の段階と、第１の段階の結果が肯定的であれ
   ば、フィールド・アトリビュートによって形成されるフ
   ィールドの構造が同一の行が複数連続しているか否かを
   判定する第２の段階と、第２の段階の結果が肯定的であ
   れば、該連続している各行の非空白の入力可能フィール
   ドを所定の表示形式に変換する第３の段階と、を含むこ
   とを特徴とする画面表示変換方法。
5. 【請求項５】前記予め指定された文字列の組合せとは"C
   ursor"と"Enter"（若しくは他の言語でこれらと同義の
   単語の組合せ）であることを特徴とする請求項４に記載
   の画面表示変換方法。
6. 【請求項６】前記所定の表示形式とは、文字列を枠で囲
   むとともに陰影を付けて表示する形式であることを特徴
   とする請求項１、２，４のいずれかに記載の画面表示変
   換方法。
7. 【請求項７】テキストとフィールド・アトリビュート
   （但し、フィールド・アトリビュートとは画面上にフィ
   ールドを設定して各フィールドが入力可能フィールドか
   入力禁止フィールドか等を定義するための値）で構成さ
   れる画面情報を変換して表示する画面表示変換方法にお
   いて、前記画面情報内の非空白行のうち最上段の行が２
   以上の入力可能フィールドを含むか否かを判定する第１
   の段階と、第１の段階の結果が肯定的であれば、該最上
   段の行のフィールドの構造が直近下位の非空白行と一致
   するか否かを判定する第２の段階と、第２の段階の結果
   が否定的であれば、該最上段の行を所定の表示形式に変
   換する第３の段階と、を含むことを特徴とする画面表示
   変換方法。
8. 【請求項８】前記所定の表示形式とは、各入力可能フィ
   ールドを枠で囲んで陰影を付けるとともに、該枠の上に
   は元々入力可能フィールド上にあった文字列を表示する
   形式であることを特徴とする形式であることを特徴とす
   る請求項７に記載の画面表示変換方法。