JP2000172395A - 携帯情報端末向けのコンパクトｇｕｉ - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】小さな携帯情報端末や、スマートフォン向けコ
ンパクトＧＵＩシステムを構築する。 【解決手段】メニューバー（＋ツールバー）及び各メニ
ューを開いたコマンド一覧表や各項目を開いたダイアロ
グボックスの位置を開いたコンテンツ表示部を動かすこ
となく自由に移動でき、かつ、コンテンツ表示部をメニ
ューバー（＋ツールバー）やコマンド一覧表及びダイア
ロッグボックスの上に重ねて表示できる、またこの逆も
可能となる。さらにそれらをそれぞれ縮少、拡大でき
る。同一ソフトで異る二つの画面を開いた場合、それぞ
れに対応する同一のメニューバー（＋ツールバー）は別
々に表示されるのではなく一つに統合して表示される。
対象とする携帯情報端末が二つの独立したディスプレイ
部を持つ場合、メニューバー（＋ツールバー）をコンテ
ンツ表示部画面が開かれているディスプレイとは別のデ
ィスプレイに分割して表示できる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、情報通信端末としての
携帯情報端末（ＰＤＡ）の表示画面上で、ＧＵＩ （グ
ラフィカル ユーザ インターフェイス）をコンパクト
に実現するシステムに関する。

【０００２】

【従来の技術】従来、パソコン等で、何らかの応用ソフ
トを、ディスプレイ上に開いた場合、通常、画面の上部
に“メニューバー（＋ツールバー）”が表示されてい
た。（以後、“ツールバー”が標準で表示されるソフト
と、“ツールバー”が標準で表示されないソフトを、ま
とめて同時に議論するために、“メニューバー（＋ツー
ルバー）”という表現を用いる。議論の力点はあくまで
も、”メニューバー”に置かれている点に注意せよ。ま
た、“メニューバー”の代役として、例えば、“メニュ
ーボックス”や“メニューアイコン”、その他の“メニ
ュー…”表示形式を考えることができる。本発明は、そ
れらの一般的な表示法に適用できる汎用的なものであ
る。ただ、議論の判り易さのため、従来の“メニューバ
ー形式”を基準に話を進める。）

【０００３】例えば、各社のインターネットのブラウザ
ーソフトや各社のワープロソフト、表計算ソフト、その
他のオフィス用ソフトまで、総てこの「画面の上部に
“メニューバー（＋ツールバー）”が表示される」とい
うモデルでＧＵＩが統一されていた。

【０００４】この事実により、この“メニューバー（＋
ツールバー）”＋“（その他の）コンテンツ表示部”と
いうＧＵＩモデルは、かなり便利なものであり、汎用性
があることが見て取れる。

【０００５】実際、パソコンばかりでなく、従来の携帯
情報端末でも、この“メニューバー（＋ツールバー）”
＋“コンテンツ表示部”ＧＵＩモデルが基本的に採用さ
れている。

【０００６】多分、今から流行り出すであろう、スマー
トフォンの世界でも、この基本ＧＵＩモデルは採用され
るに違いない。

【０００７】このような状況のもとで、従来の（携帯
型）パソコンでは、このようなメニューバー中の任意の
メニュー（例えば、“ファイル”メニュー）を開いた時
に出現する、各コマンド（例えば、“新規作成”、“開
く”、“閉じる”、“名前を付けて保存”、“印刷”、
“送信”、“プロパティ”等）の一覧表、及び、各コマ
ンドを開いた時に出現する“ダイアログボックス”は、
ディスプレイ画面中でかなりの面積を占めていた。そし
て、当然のことながら、この一覧表やダイアログボック
スの下になったコンテンツ表示部は、ユーザの目から隠
されて、ユーザからは見えなくなっていた。

【０００８】ここで、大事な点として、従来のＧＵＩで
は、 「このメニューバーや一覧表やダイアログボックスは、（開いた表示画面全体を 動かさない限り、）画面上で移動させることが出来ない」… 且つ、 「この一覧表やダイアログボックスは、（開いた表示画面全体を縮小・拡大した 場合でも、）画面上で縮小や拡大をさせることが出来ない」… という事実がある。

【０００９】

【発明が解決しようとする課題】ところで、従来の携帯
型パソコンと比較して、携帯情報端末のディスプレイ部
分の表示面積はかなり小さい。このような、小さな表示
面積しか持たないディスプレイ上で、同じＧＵＩモデル
に従って、画面の上部にメニューバー（＋ツールバー）
を表示した場合、各メニューを開いた時のコマンド一覧
表や各項目を開いた時のダイアログボックスは、（たと
え、パソコン向けＧＵＩと比べて、簡易化されていると
しても、）ディスプレイ部分の大部分を占め、ほとんど
のコンテンツ部分がユーザからは見えなくなるという事
態が生じる。

【００１０】つまり、パソコンの場合と比較して、携帯
情報端末では、ディスプレイ画面全体に対する、コマン
ド一覧表やダイアログボックスで隠される部分の相対的
な割合が増加する。場合によっては、ディスプレイ画面
一杯に広がる場合もあろう。この結果、ＧＵＩとしての
不便さが増すことになる。

【００１１】このような事態を避けるため、まず、メニ
ューバーやコマンド一覧表やダイアログボックスで使用
する文字やアイコンを相対的に小さくするという手段を
とるのが普通であろう。しかしながら、使用する各文字
やアイコンの大きさに関しては、これを人が見る限り、
ある一定以上のサイズは確保しておかねばならない。つ
まり、ディスプレイのサイズが小さくなったからといっ
て、それに比例して文字サイズを小さくすることは不可
能であるという現実がある。たとえ、無理に縮小して
も、ユーザインターフェイスの観点から、不適切にな
る。一瞥して、読み難くなるのだ。

【００１２】次に、（文字は“ＧＵＩの意味で極小”の
大きさのまま、）画面全体に占めるメニューバーやコマ
ンド一覧表やダイアログボックス部分の割合をできるだ
け小さくすることを試みるのが常套手段であろう。

【００１３】このためには、（もう文字は小さくできな
いのであるから、）例えば、従来の一覧表やダイアログ
ボックスをさらに多重に階層化して、小出しに表示する
という手段が採用できるかもしれない。（具体的に、ど
ういう区分けで階層化するかを考えれば、これは中々の
難問であることが判る。）ただし、（もし出来たとして
も、）この階層化により、ＧＵＩとしての便利さは減少
するという点を注意せねばならない。つまり、目的の項
目がどこにあるのかを探すのが大変になる。

【００１４】また、ソフト自体を簡易化して、メニュー
の数や各一覧表のコマンド数やダイアログボックスの内
容を出来るだけ減らすという戦術もあろう。これは、従
来の携帯情報端末用ＧＵＩで採用されている戦術であ
る。しかし、これにも限度がある。そもそも、この戦術
は、ソフトとしての諸機能の多様性を犠牲にして成り立
つ手段であり、そうそう気安くは使えない。つまり、こ
の場合はＧＵＩの便利さとソフトの諸機能とのバーター
になるわけである。

【００１５】以上の意味で、従来のＧＵＩモデルに基づ
く、コマンド一覧表やダイアログボックス部分の表示面
積の極小化は、便利さと不便さのバーターの意味で、す
でに行き着くところまで行っている。

【００１６】これが、今から流行るであろう、スマート
フォンや小型携帯情報端末のように、ディスプレイ画面
がさらに小さい場合だと、不便さはさらに増すことにな
る。つまり、ＧＵＩとしての“メニューバー（＋ツール
バー）”方式の便利さと、不便さが逆転しかねない事態
になる。

【００１７】さらに言えば、従来の携帯情報端末でも、
同じソフトで、異なる画面を二つ以上同時に開く機能を
装備する場合があろう。この場合、従来のＧＵＩでは、
“メニューバー（＋ツールバー）”がそれぞれの画面に
付属している関係上、その画面の表示場所に、その画面
の数だけ出現した。このような状況で、各々のコマンド
一覧表やダイアログボックスを開けば、デメリットは、
ますます悪化することが目に見えている。

【００１８】つまり、一画面をディスプレイ上で精一杯
大きく開いて、やっとメリットとデメリットの均衡が取
れるような、ギリギリのＧＵＩを何とかして採用できた
としても、同時に二画面の表示では、どうしようもなく
なる。

【００１９】その上、例えば、インターネットのブラウ
ザーソフトで不可欠の機能である、“お気に入り”（良
く使うホームページの登録機能）メニューを、簡易化ソ
フトで省略するわけにはいかないであろう。このメニュ
ーのコマンド一覧表は、御存知のように、登録されたホ
ームページを区分けしたフォルダの数だけ生成され、且
つ、各項目を開くと、そのフォルダに登録されたホーム
ページの名称一覧ダイアログボックスが生成される。つ
まり、 「たとえ簡易ソフトでも、（ある種のメニューに対応した）コマンド一覧表やダ イアログボックスは、いくらでも長く、大きくなる場合がある」… のだ。

【００２０】以上の洞察により、次のことが理解でき
る。つまり、従来のＧＵＩを、従来の基本思想のまま、
画面の小さな携帯情報端末向けに改変して移植すると、
インターフェイスの“感性”、及び、“便利さ”の意味
で、欠点を抱え込むことになる。

【００２１】我々は、ソフトウェア、特にＧＵＩ部分の
改変によって、以上述べたような基本的な欠陥を克服し
たい。

【００２２】ところが、一方において、本モデルがあま
りにも斬新すぎて、従来のＧＵＩモデルとの整合性がま
ったく取れないようでは困る。特に、従来の応用ソフト
ウェアが、まったく再利用できないようでは困る。具体
的に言えば、“メニューバー（＋ツールバー）”、もし
くは、その変形を使用するという原理だけは、踏襲した
い。

【００２３】以上の思想に基づき、本特許では次のよう
な新しいＧＵＩシステムを採用する。

【００２４】

【課題を解決するための手段】上記目的を達成するため
に、本発明のコンパクトＧＵＩモデルでは、各応用ソフ
トを開いた時、通常、画面の上部に表示されている“メ
ニューバー＋（ツールバー）”を、その画面から独立さ
せて表示する。

【００２５】つまり、各応用ソフトを開いた時、“メニ
ューバー（＋ツールバー）”画面と（従来の画面では、
それ以外の部分にあたる）“コンテンツ表示部”画面
が、（比較的小さな液晶）ディスプレイ上で別画面とし
て、同時に開かれることになる。

【００２６】一枚目の画面を開いた時、最初に表示され
る“メニューバー＋（ツールバー）”のディスプレイ上
の位置と“コンテンツ表示部”のディスプレイ上の位置
は、ほぼ従来通りとする。つまり、上下にくっ付いた形
で表示される。

【００２７】それでは、我々の新ＧＵＩと従来のＧＵＩ
とでは、実質的にどこが違うのか？以下の点が本質的に
違うのである。

【００２８】第一に、我々の新ＧＵＩでは、 「開いた“メニューバー（＋ツールバー）”と“コンテンツ表示部”を、ディス プレイ上で、それぞれ独立、且つ、自由に移動させることができる。」 …（ 独立移動性）

【００２９】さらに、各メニューを開いた時の“コマン
ド一覧表”や、各項目を開いた時の“ダイアログボック
ス”の位置も（、同時に開いた“コンテンツ表示部”と
は独立に、）自由に移動できるようにする。（従来のＧ
ＵＩでは、上述の通りである。）

【００３０】第二に、その結果、特に、 「“コンテンツ表示部”やその他の（ソフトを開いた）画面を“メニューバー（ ＋ツールバー）”や“コマンド一覧表”や“ダイアログボックス”の上に重ねて 表示できる。また、その逆も可能になる。」…（相互重合性） 一言で言えば、独立画面相互の重なり具合は、自由にで
きるように設計する。

【００３１】第三に、 「“メニューバー（＋ツールバー）”や“コマンド一覧表”や“ダイアログボッ クス”をそれぞれ、自由に縮小、拡大できるようにする。」…（独立縮小・拡 大性） （従来のＧＵＩでは、上記の通りである。）

【００３２】以上が、“メニューバー（＋ツールバ
ー）”を“コンテンツ表示部”から独立させるという意
味である。さらに、次のような本質的な効果をあげるこ
とが可能になる。

【００３３】第四に、 「同一ソフト（、例えばインターネットのブラウザーソフト、）で異なる二つの 画面を同時に開いた場合、それぞれに対応する同一の“メニューバー（＋ツール バー）”は、それぞれ二つが別々に表示されるのではなく、一つの合体“メニュ ーバー（＋ツールバー）”のみが表示される。」…（統合表示性） 言い換えれば、同じソフトで、別々の画面を二つ（以
上）同時に開いても、同じ一つの“メニューバー（＋ツ
ールバー）”が両者（それら）を共通に制御できるよう
にする。（従来は、開いた画面の数だけ、“メニューバ
ー（＋ツールバー）”が表示された。）

【００３４】第五の機能は、携帯情報端末の装置として
の形状、すなわち、ハードウェアに依存する。上記〜
の４つの新機能は、携帯情報端末のディスプレイ部分
が小さいという前提だけで有用な機能であった。それに
対し、第五の機能は、対象とする携帯情報端末が、二つ
の独立したディスプレイ部を持つ、折畳式のモデルの場
合に実現する。

【００３５】このようなモデルの携帯情報端末では、 「“メニューバー（＋ツールバー）”部分を、“コンテンツ表示部”画面が開か れているディスプレイとは別のディスプレイの方へ分割して表示させる機能を実 現できる。」…（分割表示性） （特願平９−２７９３００“新携帯情報端末：モデル
１”を参照せよ。） これは、同一画面上での自由な移動を保証した、上の第
一機能（独立移動性）とは本質的に異なるという事実
に注意せよ。

【００３６】上記〜の五機能がシステム特許の意味
で新規性・進歩性を有していることは明白である。これ
らの諸機能を実現するための、ソフトウェアの具体的な
内容に関しては、著作権の問題になり、ここでは詳述し
ないし、する必要もない。要は、この道の専門家とし
て、以上５つの新機能が実現可能かどうかを保証すれば
よかろう。

【００３７】というわけで、この場で、プロとしての保
証をしておこう。「上記の（コンパクトＧＵＩ向け、）
新しい５機能は、総て実現可能である事実をここに保証
する。」以上で発明の開示は終わった。

【００３８】

【作用】上記のように構成された新機能を使用する場
合、まず、第一機能に関しては、これ以上追加する注
意事項はない。

【００３９】第二機能に関してであるが、例えば、
“メニューバー（＋ツールバー）”が“コンテンツ表示
部”の背後にあり、“メニューバー（＋ツールバー）”
の一部分だけが画面上に顔を出しているような状況を想
定せよ。この場合、顔を出している“メニューバー（＋
ツールバー）”の一部をタッチすると、“メニューバー
（＋ツールバー）”が自動的に“画面の最上部、且つ、
画面の最前部”に移動し、しかも、タッチされた個別メ
ニューの“コマンド一覧表”が開かれるように設計す
る。つまり、後ろに隠されている“メニューバー（＋ツ
ールバー）”を使用する際、一度、画面の最上部、且
つ、最前部へ（タッチで）移動さす必要はない。

【００４０】これに関連して、次のような気になる事態
が生じる。従来のＧＵＩでは、使いたい画面Ａをタッチ
すれば、その画面の“Ａメニューバー（＋ツールバ
ー）”＋“Ａコンテンツ表示部”がワンセットで最前面
に出てきた。ところが、我々のコンパクトＧＵＩでは、
“メニューバー（＋ツールバー）”と“コンテンツ表示
部”は独立している。この状況のもとで、例えば、別画
面Ｂの背後にある、“Ａコンテンツ表示部”画面を使用
したいとする。この“Ａコンテンツ表示部”をタッチし
て最前部に持ってきた時、これに対応する、残りの“Ａ
メニューバー（＋ツールバー）”部はどうなるのかとい
う基本技術に関する疑問である。

【００４１】具体的には、例えば、最初、“Ａメニュー
バー（＋ツールバー）”部が画面Ｂの背後にある時、
“Ａコンテンツ表示部”を最前部に移した後も、“Ａメ
ニューバー（＋ツールバー）”部はそのまま、元の位置
（画面Ｂの背後）に留まるのか？これでは、少しばか
り、使い勝手が悪くないか？

【００４２】この本質的な疑問に対する解答は次のよう
なものとなる。我々のコンパクトＧＵＩでは、「何らか
のソフトＡを開いた時、独立して表示される“Ａメニュ
ーバー（＋ツールバー）”と“Ａコンテンツ表示部”
は、“理論上”、常に一つのまとまった２要素集合 Ｓ（Ａ）＝｛“Ａメニューバー（＋ツールバー）”、“Ａコンテンツ表示部”｝ として取り扱う。」… （場合によっては、｛“Ａメュューバー”、“Ａツール
バー”、“Ａコンテンツ表示部”｝と３要素に分解して
も良い。しかし、以下の議論は２要素分解を基準に話を
進めていく。それで話の根本が変化することはない。）

【００４３】よって、別のソフトＢを開いて、同じディ
スプレイ上に、集合 Ｓ（Ｂ）＝｛“Ｂメニューバー（＋ツールバー）”、
“Ｂコンテンツ表示部”｝ が追加表示された場合、Ｓ（Ａ）とＳ（Ｂ）の要素が、
“表示画面の重なり”の意味で交じり合うことはない。

【００４４】そして、例えば、Ｓ（Ａ）がＳ（Ｂ）よ
り、“表示画面の重なり”の意味で背後にある時、Ｓ
（Ａ）の任意の要素をタッチして、画面の最前部へ移行
した時、（集合として、まとまって移動するのであるか
ら、）Ｓ（Ａ）の他の要素も同時に前面へ浮上してくる
ことになる。

【００４５】それでは、Ｓ（Ａ）内の２要素の内、どち
らをタッチしても、（画面前部への集団移行の意味
で、）まったく同じ効果を生むのか？幸い（残念）なが
ら、事はそれほど単純ではない。では、どう違うのか。

【００４６】前後の重なり順が違ってくるのである。つ
まり、どちらかをタッチすることにより、Ｓ（Ａ）内の
２要素は同時に最前部に移行してくるが、タッチした要
素の方が、２要素内で、さらに最最前部（画面の一番手
前側）として表示される。

【００４７】つまり、タッチ以前のＳ（Ａ）内の“Ａメ
ニューバー（＋ツールバー）”と“Ａコンテンツ表示
部”の画面上の順序がどのようなものであっても、タッ
チ後は、タッチされた方が最前部に来るのだ。

【００４８】そして、上で述べたように、特に“Ａメニ
ューバー（＋ツールバー）”の特定のメニューをタッチ
した時は、同時にそのメニューが開かれるのである。

【００４９】また、“Ａコンテンツ表示部”をタッチし
た場合は、ディスプレイ画面内でタッチ前の位置のま
ま、最前部へ浮かび上がってくることになる。この時、
“Ａメニューバー（＋ツールバー）”の画面内の位置は
変化せず、開かれもせず、そのまま、“Ａコンテンツ表
示部”の真下へ浮上してくることになる。

【００５０】第三機能に関しては、一つだけ作用上の
注意をしたい。“メニューバー（＋ツールバー）”は
“コンテンツ表示部”やその他の画面の下に隠せるので
あるから、“メニューバー（＋ツールバー）”の縮小機
能は、実用上、役に立たないと思うかもしれない。しか
しながら、現実はそうではない。縮小した“メニューバ
ー（＋ツールバー）”を“コンテンツ表示部”上の任意
の位置に重ねる場面を想定してみよ。ましてや、“コマ
ンド一覧表”や“ダイアログボックス”の場合は、これ
を開いた後で、縮小できることのメリットは、（従来の
ＧＵＩが、一覧表やダイアログボックスを縮小出来なか
ったという事実を思い起こせば、）大きい。

【００５１】さて、第四機能実現のためには、そもそ
も、いかにして“メニューバー（＋ツールバー）”を単
一のものに統合するかという点が重要になってくる。こ
れの解決のために、次のような手段を採用する。

【００５２】（１）あるソフトＥ（例えば、インターネ
ットブラウザー）をディスプレイ上で初めて開く時に
は、集合Ｓ（Ｅ）＝｛“Ｅメニューバー（＋ツールバ
ー）”、“Ｅコンテンツ表示部”｝が、“初期状況”σ
_ｏで同時に表示される。 （２）これらの画面を適宜使用する。その結果、集合Ｓ
（Ｅ）内の各要素の表示形式、及び、それらの表示順序
等の関係は初期状況から変移する。さらに、この間、場
合によっては、別のソフトＦを開くことで、ディスプレ
イ画面上で、集合Ｓ（Ｅ）が集合Ｓ（Ｆ）の下にくるよ
うな事態が生じるかもしれない。このような一般的な状
態を仮に、“現状況”σ_ｎと呼ぼう。 （３）現状況σ_ｎで、同じソフトＥから、さらに第二の
画面を開くとする。この時、 ３−１．集合Ｓ（Ｅ）内の“Ｅメニューバー（＋Ｅツー
ルバー）”がディスプレイ画面上、最前部に（その位置
のまま）浮上してくる。 ３−２．この“Ｅメニューバー（＋Ｅツールバー）”
に、第二画面で生成される、新たな“Ｅコンテンツ表示
部２”が新要素として追加される。 ３−３．その結果、２つの要素｛“Ｅメニューバー（＋
Ｅツールバー）”、“Ｅコンテンツ表示部２”｝からな
る集合Ｓ（Ｅ）（２）が生成される。 ３−４．Ｓ（Ｅ）（２）内の各要素の表示順は、“Ｅコ
ンテンツ表示部２”が最前部になる。 ３−５．この結果、最初“Ｅメニューバー（＋Ｅツール
バー）”と組んでいた“Ｅコンテンツ表示部”は単体で
もとの場所に取り残されることになる。この結果の状況
をσ_ｎ＋１としよう。

【００５３】さらに別の操作を続けて、一般の状況σ_ｍ
になったとする。ここで、依然として、Ｓ（Ｅ）（２）
と先の“Ｅコンテンツ表示部”は（画面の重なりの意味
で）離れているものと想定する。このσ_ｍもとで、“Ｅ
コンテンツ表示部”を使用したい時は、その“Ｅコンテ
ンツ表示部”画面をタッチすればよい。この時、“Ｅコ
ンテンツ表示部”はディスプレイ上、最前部に浮上し、
その真下に“Ｅメニューバー（＋Ｅツールバー）”が浮
上して、もとの集合Ｓ（Ｅ）を再構成する。

【００５４】最後に、画面上の単一の“Ｅメニューバー
（＋ツールバー）”が、残りの（二つ以上ある同一種類
画面のうちの）どの“Ｅコンテンツ表示部Ｘ”画面を制
御しているのかを一意に決定できねばならない。

【００５５】これの決定は簡単である。以上の設計によ
り、“Ｅメニューバー（＋ツールバー）”とペアを組ん
でいる“Ｅコンテンツ表示部Ｘ”画面は常に一意決定さ
れている。（“Ｅメニューバー（＋ツールバー）”の直
前か直後にある。）この画面を制御するように設計すれ
ばよい。

【００５６】第五機能（分割表示性）に関して、別画
面への移動はペン等で操作するのではない点を強調して
おきたい。つまり、第五機能とは、各応用ソフトを開
いた時点で、“メニューバー（＋ツールバー）”が“コ
ンテンツ表示部”を表示しているディスプレイとは別の
ディスプレイ上に表示されるという意味である。

【００５７】また、上ので、集合Ｓ（Ａ）を規定した
際、“理論上”という言葉を用いておいた。これは、第
五機能を使用する場合、本質的に生きてくる。つま
り、により、“Ａメニューバー（＋ツールバー）”と
“Ａコンテンツ表示部”は別々のディスプレイ上に表示
されることになる。そのような場合でも、上述の議論

【００３９】〜

【００５５】は、対応する適当な変形を施せば、そのま
ま成立することは明白である。（例えば、片方のディス
プレイで（タッチにより）“Ａコンテンツ表示部”を最
前部に移行させると、他方のディスプレイで”Ａメニュ
ーバー（＋ツールバー）”が、自動的に最前部に移るの
である。）

【００５８】さて、以上は、何らかのソフト（、例え
ば、インターネットブラウザー）を固定した時の“メニ
ューバー（＋ツールバー）”の表示システムに関する話
であったが、同様の機能は、その他の（“メニューバー
（＋ツールバー）”を有するＯＳ内の、または、応用）
ソフトについても発現できる。例えば、ワープロソフト
に関しても、“メニューバー”と“ツールバー”は存在
するし、ＯＳ内のコントロールパネルにも“メニューバ
ー”は存在する。この場合にも“メニューバー（＋ツー
ルバー）”を独立させるように機能設計をするのであ
る。

【００５９】この時、当然のことながら、一目で、イン
ターネット用の“メニューバー（＋ツールバー）”とワ
ープロ用の“メニューバー（＋ツールバー）”が区別で
きなければ使い物にはならない。この区別付けは簡単で
ある。上述のように、各ソフトを開いた場合、基本的に
はセットになって表示されるという事実を考えれば、混
同の心配はない。

【００６０】但し、原理上の話と、ＧＵＩとしての“見
易さ”の話題は別である。このため、例えば、インター
ネット用の“メニューバー（＋ツールバー）”にはイン
ターネット印を、ワープロ用の“メニューバー（＋ツー
ルバー）”にはワープロ印を押しておけばよい。

【００６１】インターネット用の“メニューバー（＋ツ
ールバー）”とワープロ用の“メニューバー（＋ツール
バー）”をさらに統一して、一つの“メニューバー（＋
ツールバー）”にまとめるようなまねはしない。これ
は、両者の基本機能が異なるからである。なるほど、両
者で重なり合っている機能も幾つかはある。しかし、合
体させることで生じる、全体的な煩わしさ、使用上の不
便さは、スペース節約のメリットを台無しにすると思う
からである。

【００６２】このような、“メニューバー（＋ツールバ
ー）”の独立が、我々が提唱する、コンパクトＧＵＩ向
けの、新ＯＳの改変だけで可能になるのか、それとも各
種応用ソフト自身をいじらねばならないのかに関して
は、従来のＯＳと従来の各種応用ソフトの相互関係に依
存する。（最近は、どこまでがＯＳで、どこから応用ソ
フトなのかを区別することが難しくなっているが。）し
かしながら、我々は従来のＯＳを改変して、携帯情報端
末に特化したコンパクトな新ＯＳを設計するのである。
この新ＯＳに乗るように、従来の応用ソフトを改変する
のが自然な姿であろう。

【００６３】従来のパソコン用の応用ソフトを、そのま
ま携帯情報端末用に使用することは、まずない。これ
は、容量及び使い勝手の問題が絡むからである。（“携
帯”は“簡易性が命”である。ウインドウズＣＥ上の
“ポケットワード”を見よ。）どうせ改変するなら、そ
の際、我々の新機能を盛り込もうという思想である。

【００６４】実は、本特許は、折り畳み式携帯情報端末
向けの分割表示性の機能を申請するのが本来の目的で
あった。しかしながら、のみを独立させて申請するよ
りも、へ至るまでの途中の機能〜も、一般の（デ
ィスプレイ画面の小さな）携帯情報端末向けに、独立さ
せて同時に申請しておくのが、我々の特許戦略上、有利
と判定した。

【００６５】さらに言えば、〜の新機能は、それぞ
れ汎用性のある、“ＧＵＩコンパクト化特許”として申
請できるコンセプトである。つまり、それぞれが、通常
のキーボード使用パソコンのソフトにも、スペース節約
機能として適用できる。

【００６６】これに関連して、コンパクトＧＵＩの視点
から、「“メニューバー（＋ツールバー）”のスマート
で知的な表示法」の問題が生じてくる。いかにして、ス
ペースを小さく、しかも、見やすく、使いやすくするか
という点は、別の特許になろう。以下の実施例で、具体
例を一つだけ挙げておこう。

【００６７】

【実施例】実施例について図面を参照して説明すると、
図１は我々が提唱するコンパクトＧＵＩを携帯情報端末
上で実現した一例である。この図では、何らかの応用ソ
フト（例えば、簡易ワープロ）をキーボード付きの携帯
情報端末で開いた直後の表示画面の状態を表わしてい
る。

【００６８】ここでは、従来のような、“メニューバー
（＋ツールバー）形式”が初期画面に表示されるのでは
なく、 「“メニューショウ”を初期画面上で左上隅に表示する。」…▲１０▼ という、究極の最小化を我々のコンパクトＧＵＩとして
提案する。

【００６９】この“メニューショウ”とは、一メニュー
分の文字数（せいぜい、４〜５文字）を記すに足るだけ
の表示面積を有する電子掲示板のようなものであり、こ
の掲示板の上を、各（区切られて、一ユニットになって
いる）メニューが右から左へと、一定の速度で流れなが
ら表示される仕組みになっている。（町の電子広告を想
起してほしい。）つまり、各メニューは、ある一定の
（短い）時間間隔で、このメニューショウ上に（瞬間的
に入れ替わるのではなく、流れるように）繰り返し登場
する。

【００７０】各メニューを開きたい時は、従来と同様、
目的のメニューがメニューショウ上に登場した時に、そ
のメニューをタッチすればよい。

【００７１】このメニューショウに対して、上記〜
＋の機能が設定されることになる。つまり、メニュー
ショウの自由な移動、拡大・縮小、他の画面との重ね合
わせ、統一化、別画面表示が可能になるように設計す
る。

【００７２】メニューショウを拡大した時、当然、一度
に表示できるメニュー数は増加する。それらの、複数の
メニューが、やはり、その拡大枠の中で、右から左へ一
定速度で流れながら、表示される。当然、左へ消えたメ
ニューは、一定時間後、右から登場する。（丁度、複数
メニューの乗ったベルトコンベヤーのような感じであ
る。）

【００７３】最終的に、総てのメニューが同時にメニュ
ーショウ上に表示できる程、メニューショウの枠が拡大
された時点で、この流れは自動的に停止する。

【００７４】メニューショウ枠の拡大方向は自由にとれ
る。つまり、メニューショウの枠組みが、横一列である
必要はない。複数列に開かれた場合は、各列毎に、右か
ら左への独立した流れが生じるように設計する。（各列
のメニュー配分は自動とする。全メニューを、ほぼ、そ
の列数に分ければ良い。）

【００７５】各メニューを開いた時のコマンド一覧表
や、各コマンドを開いた時のダイアログボックスについ
ても、同様の流れを生じさせる。つまり、一度に全情報
が表示出来ない（程度の枠組みの大きさの）時には、そ
の枠内で流れを作る。

【００７６】なお、この流れの速度は各ユーザが自由に
設定できるようにする。

【００７７】また、場合によっては、（ユーザが）流れ
の方向を、左右ではなく、上下（下から上）に変更でき
るように設計する。

【００７８】このアイデアの新規性・進歩性について一
言。この機能は、従来の、例えば、電子メールの自動ス
クロール機能とは、本質的に異なる点に注意せよ。そも
そも、電子メール画面はコンテンツ表示部の話である。
それに、なによりも、メニューショウでは、流れている
各メニューにタッチすると、その命令が実行される。つ
まり、流れている実体は、単なる情報ではなく、命令な
のだ。

【００７９】図２は、メニューショウの枠組みを、もと
の場所で、最大の大きさ（全メニューが同時に表示され
て、流れが生じない大きさ）に拡大した際の様子であ
る。このためには、先頭のアイコンをタッチすればよ
い。（アイコン部分は流れない。）このアイコン（ペン
模様）は、このメニューショウが、今開かれているワー
プロソフトのメニューショウであることを示す。

【００８０】図３は、新機能（独立移動性）、（相
互重合性）、（独立縮小・拡大性）を用いて、このメ
ニューショウを、ディスプレイ内で自由に移動し、且
つ、縮めた結果を表わす。この図では画面右下部に移動
して、縮小されている。

【００８１】図４は、新機能（相互重合性）により、
メニューショウがコンテンツ表示部の背後に隠された場
合のディスプレイ画面を表わしている。この図では、メ
ニューショウはコンテンツ表示部で完全に隠されておら
ず、その一部が、コンテンツ表示部の背後から顔を出し
ている状態を表わしている。

【００８２】図５は、新機能（統合表示性）により、
一つのメニューショウに対し、二つのコンテンツ表示部
が開かれている状態を示している。二つのコンテンツ表
示部はディスプレイ上で、左右に並んで表示されてい
る。この両者の前面にメニューショウが開かれている。

【００８３】図６は、我々が提唱する“モデルＩ”とい
う両開きのディスプレイを有する新携帯情報端末上で、
機能（分割表示性）を実施した例である。図中、上側
のディスプレイにコンテンツ部が表示され、下側のディ
スプレイにメニューショウが表示されている。

【００８４】この実施例では、メニューショウが表示さ
れたディスプレイ上には、それ以外に、キーボードのシ
ミュレート機能画面と、その他のアイコン（このアイコ
ンの具体的な機能に関しては、ここでは話題にしな
い。）が二つ表示されている。一方、上側のディスプレ
イでは、開いたソフトのコンテンツ部が画面一杯に表示
されている。

【００８５】

【発明の効果】本発明は、以上説明したように構成され
ているので、以下に記載されるような効果を奏する。

【００８６】本システムを採用したコンパクトＧＵＩモ
デルは、携帯情報端末のディスプレイ画面が（、従来の
画面と比較して）小さな時、感性上も実用上も、メリッ
トを有する。具体的には

【００８７】第一に、我々の新ＧＵＩでは、“メニュー
バー（＋ツールバー）”の位置を（、開いたコンテンツ
表示部を動かすことなく、）ディスプレイ上で、独立、
且つ、自由に移動させることができる。（独立移動性）

【００８８】さらに、各メニューを開いた時の“コマン
ド一覧表”や各項目を開いた時の“ダイアログボック
ス”の位置も（、開いたコンテンツ表示部を動かすこと
なく、）自由に移動できる。これにより、コンテンツ部
の内容が観やすくなり、新ＧＵＩとしてのメリットが増
す。

【００８９】第二に、“コンテンツ表示部”やその他の
（ソフトを開いた）画面を“メニューバー（＋ツールバ
ー）”や”コマンド一覧表”や“ダイアログボックス”
の上に重ねて表示できる。また、その逆も可能になる。
（相互重合性）これにより、コンテンツの表示面積とい
う観点から見た場合、メニューバー（＋ツールバー）”
部分のスペースが節約できる。つまり、新ＧＵＩとして
のメリットが増す。

【００９０】第三に、“メニューバー（＋ツールバ
ー）”や“コマンド一覧表”や“ダイアログボックス”
をそれぞれ、自由に縮小、拡大できるようにする。（独
立縮小・拡大性）これにより、コンテンツ部の内容が観
やすくなり、新ＧＵＩとしてのメリットが増す。

【００９１】第四に、同一ソフト（、例えばインターネ
ットのブラウザーソフト、）で異なる二つの画面を開い
た場合、それぞれに対応する同一の“メニューバー（＋
ツールバー）”は、それぞれ二つが別々に表示されるの
ではなく、一つの合体“メニューバー（＋ツールバ
ー）”のみが表示される。（統合表示性）言い換えれ
ば、同じソフトで、別々の画面を二つ（以上）同時に開
いても、同じ一つの“メニューバー（＋ツールバー）”
が両者（それら）を共通に制御できるようにする。これ
により、実質的に何らの不便を被ることなく、コンテン
ツ部の内容がさらに観やすくなり、新ＧＵＩとしてのメ
リットが増す。

【００９２】第五の機能は、対象とする携帯情報端末
が、二つの独立したディスプレイ部を持つ、折畳式のモ
デルの場合に実現する。このようなモデルの携帯情報端
末では、“メニューバー（＋ツールバー）”部分を、
“コンテンツ表示部”画面が開かれているディスプレイ
とは別のディスプレイの方へ分割して表示させる機能を
実現できる。（分割表示性） （特願平９−２７９３００“新携帯情報端末：モデル
１”を参照せよ。）

【００９３】これにより得られるコンパクトＧＵＩとし
てのメリットは大きい。“メニューバー（＋ツールバ
ー）”部分が、別の画面に表示されるという事実は、当
然、それに付随した“コマンド一覧表”や“ダイアログ
ボックス”も別画面のほうに表示されるという事実を包
含する。つまり、“コマンド一覧表”や“ダイアログボ
ックス”が、どんなに長く大きくなっても、それの影響
は、“コンテンツ表示部”には出ない。（上述のを思
い起こしてほしい。）

【００９４】勿論、“メニューバー（＋ツールバー）”
を表示するディスプレイ側に、別のソフト（例えば、キ
ーボードのシミュレーション機能）が開かれている場合
もあろう。このような場合、このディスプレイ側で、必
要に応じて〜を実行する。このように、別ディスプ
レイ側でも、必要に応じて〜を実行するのならば、
実質的に何が有り難いのか？それは次の点である。

【００９５】つまり、一枚パネルのディスプレイの場
合、“メニューバー（＋ツールバー）”や“コマンド一
覧表”や“ダイアログボックス”で隠される部分とし
て、別ソフトの画面のみならず、今、一番見たい、当
の、“コンテンツ表示部”までも影響が及ぶ。一方、２
枚パネルの折り畳み式ディスプレイの場合、“コンテン
ツ表示部”に影響は及ばない。この結果、両者では、
“必要に応じて”の度合い・頻度が本質的に違ってくる
のだ。

【００９６】〜は、ユーザが携帯情報端末を使用
中、たとえ余分な操作をしてでも、隠れた部分を見たい
という場合に実行されるに決まっている。具体的に、ど
のような場面で、そのような必要性を感じるかは、各ユ
ーザの感性と組み込みソフト、及び、携帯情報端末の使
用状況に依存する。要は、「いざ必要となった時に、ち
ゃんと用意が整っている」というのが〜のメリット
である。一方、は“無駄を省こう”という単純性の思
想を実践したものである。また、のメリットは上で述
べた。これ、らこそ、“知的インターフェイス”の真髄
であろう。

【００９７】我々のコンパクトＧＵＩでは、以上のよう
な、従来の常識では考えられないような機能を獲得でき
る。逆に言えば、そのような新機能をコンパクトＧＵＩ
として装備するのである。狭い画面上で、上記〜＋
を統合して得られる融合機能から得られるメリットは
計り知れない。

【図面の簡単な説明】

【図１】何らかの応用ソフト（例えば、簡易ワープロ）
を開いた直後の表示画面の状態。

【図２】メニューショウを拡大表示した一例。

【図３】メニューショウを、ディスプレイ内で自由に移
動し、且つ、縮めた結果を表わす。

【図４】メニューショウがコンテンツ表示部の背後に隠
された場合。

【図５】一つのメニューショウに対し、二つのコンテン
ツ表示部が開かれている状態。

【図６】両開きのディスプレイを有する新携帯情報端末
上で、機能（分割表示性）を実施した例。

【符号の説明】

１ 初期状態のメニューショウ ２ 最大画面のメニューショウ ３ 移動・縮小したメニューショウ ４ 一部顔を出したメニューショウ ５ 二つの画面が共有する統合メニューショウ ６ 別のディスプレイ上に表示されたメニューショウ

フロントページの続き Ｆターム(参考） 5C080 AA10 BB05 DD01 DD13 EE01 EE17 FF09 GG02 GG12 JJ01 JJ06 KK07 5C082 AA01 AA22 BA02 BA12 BB42 CA52 CA59 CB05 DA42 DA87 MM09 MM10 5E501 AA04 AA14 BA03 CA02 CB05 EA05 EA10 EA11 EA15 EB01 EB05 FA05 FA08 FB04 FB22

Claims (8)

【特許請求の範囲】
1. 【請求項１】本発明のコンパクトＧＵＩモデルでは、各
   応用ソフトを開いた時、通常、画面の上部に表示されて
   いる“メニューバー（＋ツールバー）”を、その画面か
   ら独立させて表示する。つまり、各応用ソフトを開いた
   時、“メニューバー（＋ツールバー）”画面と（従来の
   画面では、それ以外の部分にあたる）“コンテンツ表示
   部”画面が、ディスプレイ上で別画面として、同時に開
   かれることになる。（以後、“ツールバー”が標準で表
   示されるソフトと、“ツールバー”が標準で表示されな
   いソフトを、まとめて同時に議論するために、“メニュ
   ーバー（＋ツールバー）”という表現を用いる。議論の
   力点はあくまでも、“メニューバー”に置かれている点
   に注意せよ。また、“メニューバー”の代役として、例
   えば、“メニューボックス”や“メニューアイコン”、
   その他の“メニュー…”表示形式を考えることができ
   る。本発明の各請求項目は、それらの一般的な表示法に
   適用できる汎用的なものである。ただ、議論の判り易さ
   のため、従来の“メニューバー形式”を基準に話を進め
   る。）
2. 【請求項２】さらに、本発明のコンパクトＧＵＩでは、
   “メニューバー（＋ツールバー）”を（、同時に開いた
   “コンテンツ表示部”を動かすことなく、）ディスプレ
   イ上で、独立、且つ、自由に移動させることができる。
   また、各メニューを開いた時の“コマンド一覧表”や、
   各コマンドを開いた時の“ダイアログボックス”の位置
   も（、同時に開いた“コンテンツ表示部”を動かすこと
   なく、）自由に移動できるようにする。（独立移動性）
3. 【請求項３】その結果、特に、“コンテンツ表示部”や
   その他の（ソフトを開いた）画面を“メニューバー（＋
   ツールバー）”や“コマンド一覧表”や“ダイアログボ
   ックス”の上に重ねて表示できる。また、その逆も可能
   になる。（相互重合性）
4. 【請求項４】さらに“メニューバー（＋ツールバー）”
   や“コマンドー覧表”や“ダイアログボックス”をそれ
   ぞれ、自由に縮小、拡大できるようにする。（独立縮小
   ・拡大性）
5. 【請求項５】さらに、同一ソフト（、例えばインターネ
   ットのブラウザーソフト、）で異なる二つ（複数）の画
   面を同時に開いた場合、それぞれに対応する同一の“メ
   ニューバー（＋ツールバー）”は、それぞれ二つ（複
   数）が別々に表示されるのではなく、一つの合体“メニ
   ューバー（＋ツールバー）”として表示される。言い換
   えれば、同じソフトで、別々の画面を二つ（以上）同時
   に開いても、同じ一つの“メニューバー（＋ツールバ
   ー）”が両者（それら）を共通に制御できるようにす
   る。（統合表示性）
6. 【請求項６】この統合表示性の一例として、具体的に
   は、次のようなＧＵＩモデルを考えることができる。 （１）あるソフトＥ（例えば、インターネットブラウザ
   ー）をディスプレイ上で初めて開く時には、集合Ｓ
   （Ｅ）＝｛“Ｅメニューバー（＋ツールバー）”、“Ｅ
   コンテンツ表示部”｝が、“初期状況”σ_ｏで同時に表
   示される。 （２）これらの画面を適宜使用する。その結果、集合Ｓ
   （Ｅ）内の各要素の表示形式、及び、それらの表示順序
   等の関係は初期状況から変移する。さらに、この間、場
   合によっては、別のソフトＦを開くことで、ディスプレ
   イ画面上で、集合Ｓ（Ｅ）が集合Ｓ（Ｆ）の下にくるよ
   うな事態が生じるかもしれない。このような一般的な状
   態を仮に、“現状況”σ_ｎと呼ぼう。 （３）現状況σ_ｎで、同じソフトＥから、さらに第二の
   画面を開くとする。この時、 ３−１．集合Ｓ（Ｅ）内の“Ｅメニューバー（＋Ｅツー
   ルバー）”がディスプレイ画面上、最前部に（その位置
   のまま）浮上してくる。 ３−２．この“Ｅメニューバー（＋Ｅツールバー）”
   に、第二画面で生成される、新たな“Ｅコンテンツ表示
   部２”が新要素として追加される。 ３−３．その結果、２つの要素｛“Ｅメニューバー（＋
   Ｅツールバー）”、“Ｅコンテンツ表示部２”｝からな
   る集合Ｓ（Ｅ）（２）が生成される。 ３−４．Ｓ（Ｅ）（２）内の各要素の表示順は、“Ｅコ
   ンテンツ表示部２”が最前部になる。 ３−５．この結果、最初“Ｅメニューバー（＋Ｅツール
   バー）”と組んでいた“Ｅコンテンツ表示部”は単体で
   もとの場所に取り残されることになる。この結果の状況
   をσｎ_＋１としよう。 （４）さらに別の操作を続けて、一般の状況σ_ｍになっ
   たとする。ここで、依然として、Ｓ（Ｅ）（２）と先の
   “Ｅコンテンツ表示部”は（画面の重なりの意味で）離
   れているものと想定する。このσ_ｍもとで、“Ｅコンテ
   ンツ表示部”を使用したい時は、その“Ｅコンテンツ表
   示部”画面をタッチすればよい。この時、“Ｅコンテン
   ツ表示部”はディスプレイ上、最前部に浮上し、その真
   下に“Ｅメニューバー（＋Ｅツールバー）”が浮上し
   て、もとの集合Ｓ（Ｅ）を再構成する。 （５）最後に、画面上の単一の“Ｅメニューバー（＋ツ
   ールバー）”が、残りの（二つ以上ある同一種類画面の
   うちの）どの“Ｅコンテンツ表示部Ｘ”画面を制御して
   いるのかを一意に決定できねばならない。 （６）これの決定は簡単である。以上の設計により、
   “Ｅメニューバー（＋ツールバー）”とペアを組んでい
   る“Ｅコンテンツ表示部Ｘ”画面は常に一意決定されて
   いる。（“Ｅメニューバー（＋ツールバー）”の直前か
   直後にある。）この画面を制御するように設計すればよ
   い。
7. 【請求項７】特に、対象とする携帯情報端末が、二つの
   独立したディスプレイ部を持つ、折畳式のモデルの場合
   には、“メニューバー（＋ツールバー）”部分を、“コ
   ンテンツ表示部”画面が開かれているディスプレイとは
   別のディスプレイの方へ分割して表示させる機能を実現
   できる。その結果、付随した“コマンド一覧表”や“ダ
   イアログボックス”も別画面のほうに表示される（分割
   表示性）（特願平９−２７９３００“新携帯情報端末：
   モデル１”を参照せよ。）
8. 【請求項８】コンパクトＧＵＩの視点から、“メニュー
   バー（＋ツールバー）”のスマートで知的な表示法の問
   題が生じる。いかにして、スペースを小さく、しかも、
   見やすく、使いやすくするかという点は、別の特許にな
   ろう。ここでは、従来のように、“メニューバー（＋ツ
   ールバー）”を初期画面に表示するのではなく、「“メ
   ニューショウ”を初期画面上で左上隅に表示する。」と
   いう、究極の最小化を我々のコンパクトＧＵＩとして提
   案する。この“メニューショウ”とは、一メニュー分の
   文字数（せいぜい、４〜５文字）を記すに足るだけの表
   示面積を有する電子掲示板のようなものであり、この掲
   示板の上を、各（区切られて、一ユニットになってい
   る）メニューが右から左へと、一定の速度で流れながら
   表示される仕組みになっている。（町の電子広告を想起
   してほしい。）つまり、各メニューは、ある一定の（短
   い）時間間隔で、このメニューショウ上に（瞬間的に入
   れ替わるのではなく、流れるように）繰り返し登場す
   る。各メニューを開きたい時は、従来と同様、目的のメ
   ニューがメニューショウ上に登場した時に、そのメニュ
   ーをタッチすればよい。このメニューショウに請求項１
   〜７が適用される。（メニューショウに関する詳しい説
   明は実施例を参照せよ。）