JP2001154858A - イベント配送制御システム、方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ウインドウを伴うタスクとウインドウを伴わ
ないタスクとを一元的に扱うことができ、さらにユーザ
ーの、目的とするウインドウへのフォーカスの移動負担
を軽減したイベント配送制御システム、方法及び記憶媒
体を提供する。 【解決手段】イベント配送順序管理部にタスクを特定で
きるタスク識別子とウインドウを特定できるウインドウ
識別子を並列に登録しておき、イベントが発生したと
き、イベント配送処理部で、当該イベントが配送される
べき上記識別子の取得要請を実行するとともに、得られ
た識別子に対応するタスクにイベントを配送する。上記
イベント配送処理部の識別子の取得要請はイベント配送
先取得部に配送され、当該イベント配送先取得部はイベ
ント配送順序管理部より順次識別子を取得するととも
に、受け取った識別子を上記イベント配送処理部に転送
する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】イベント配送制御システム、
方法及びこの記録媒体に関し、特に、ウインドウを伴う
タスクにもウインドウを伴わないタスクにも同等のイベ
ント配送処理ができるイベント配送制御システム、方法
及び記録媒体に関するものである。

【０００２】

【従来の技術】近年、ディジタル技術の発達、及び端末
の処理能力の高速化に伴い、端末の表示装置上に複数の
ウインドウを表示させ、該ウインドウがそれぞれ独立し
た情報を表示するといったタスク制御の手法、即ちウイ
ンドウ制御が用いられている。上記ウインドウ制御は、
複数のタスクが一つの表示画面に対して、相互の表示状
態を理解した上描画を行うものであり、従来のように、
システムの表示状態を管理しているタスクが全てのイベ
ントの処理を判断するといった制御とは全く異なる制御
方法である。

【０００３】従来のアナログ式ＴＶでは選局、音量調節
等の指示は通常リモコンを用いてなされるが、この場合
リモコンからの指示をうけてタスクが処理を開始するよ
うになっており、この手法は上述した従来のタスク制御
に該当する。一方、上記したようにパソコン等ではウイ
ンドウが表示された状態で当該ウインドウの所定の位置
にフォーカスを移動させてマウスボタン等を押下するこ
とによって、選択されたタスクが処理を開始するように
なっている。即ち上述したウインドウ制御である。

【０００４】上記ウインドウ制御を採用した場合、ユー
ザーは以下の様な操作を行う。即ち、表示装置上に１つ
以上のウインドウが表示されている状態で、特定のウイ
ンドウに対応するタスクにイベントを配送する場合、該
特定のウインドウをアクティブな（あるいはフォーカス
を当てた）状態とする必要がある。これは、上記ウイン
ドウが互いに独立したタスクより生成（制御）されてい
る場合があるため、ユーザーがどのウインドウ、即ち該
ウインドウを制御しているタスクに対するイベントを配
送するのかを最初に明らかにするためである。パソコン
等でウインドウをアクティブにする場合はマウスでカー
ソル（フォーカス）を当該ウインドウの所定の位置に移
動させ決定を意味するキ−を押下（通常マウスのキ−を
クリック）する方法が採られているが、将来的に実用化
されると見込まれているディジタルＴＶにおいては、リ
モコンに上下左右キーを設けて該上下左右キーを押し、
フォーカスが処理の位置に移動したときにリモコン上の
決定キーを押下する方法が採られる。

【０００５】通常のパソコンでの上記フォーカス操作が
キー操作と別途の操作（マウス操作）となり、キーを主
として使用する操作（例えば経理処理のための操作）で
は面倒となるところから、特開平５−１１９６２には、
複数のウインドウに対応するウインドウ識別子を記憶手
段にリストとして登録しておき、特定のキーを押下する
毎にフォーカスを決められた順番で順次異なるウインド
ウに移動させることができる方法が開示されている。

【０００６】

【発明が解決しようとする課題】ところで、上記ディジ
タルＴＶでは、ウインドウを伴うタスクと、ウインドウ
を伴わないタスクとが併用されるものと考えられる。上
記選局や音量調節はウインドウを伴わないタスクの代表
例であり、さらに音量調節についてはイベントを受けた
ことをトリガーにして画面表示を行うことはあるが、予
め音量調節を行うための画面表示は存在しない。また、
ウインドウを伴うタスクとしては、番組表が例に挙げら
れる。ディジタルＴＶではデータ放送として配信される
番組表を表示することが可能となるが、当該番組表を表
示する前の状態は、リモコンに「番組」ボタンがあるの
みで、画面上に対応するウインドウやアイコンが表示さ
れている訳ではない。ここで、リモコンの「番組」ボタ
ンを押すと番組表タスクが処理を開始して、番組表（ウ
インドウ）を表示することになる（タスク制御）。この
表示に基づいて目的の時間の目的のチャネルの番組を閲
覧したり、あるいは更に、番組予約、チャネル切り換え
等の処理をしようとすると、番組表の特定位置にフォー
カスを合わせることが必要となる（ウインドウ制御）。

【０００７】このような場合、上記従来からの方法を踏
襲すると、上記選局や音量調節といったフォーカスの移
動を伴わないタスクはアナログＴＶで使用されている、
直接リモコン操作によってタスクを制御する従来のタス
ク制御を採用することになり、一方、さらに上記番組表
の所定部にフォーカスを合わせて新たなウインドウを生
成するといったタスクは、上記従来のパソコンで使用さ
れているように、ウインドウを介してタスクを制御する
ウインドウ制御を採用することになる。

【０００８】ところが、上記従来のタスク制御と上記ウ
インドウ制御の両方を採用した場合、２つの制御方法を
管理し整合性を取ることが必要となり、構成が複雑にな
るという欠点がある。さらに、上記したようにある時点
ではウインドウを伴わないタスクであっても別の時点で
はウインドウを伴う場合もあることを考えるとなおさら
である。

【０００９】本発明は、ウインドウを伴うタスクとウイ
ンドウを伴わないタスクとを一元的に扱うことができ、
さらにユーザーの、目的とするウインドウへのフォーカ
スの移動負担を軽減したイベント配送制御システム、方
法及び記録媒体を提供することを目的とするものであ
る。

【００１０】

【課題を解決するための手段】本発明は上記目的を達成
するために以下の手段を採用している。

【００１１】すなわち、イベント配送順序管理部３４に
タスクを特定できるタスク識別子とウインドウを特定で
きるウインドウ識別子（以下単にイベント配送識別子と
いう）を並列に登録しておき、イベントが発生したと
き、イベント配送処理部３２で、当該イベントが配送さ
れるべき上記イベント配送識別子の取得要請を実行する
とともに、得られたイベント配送識別子に対応するタス
クにイベントを配送する。上記イベント配送処理部３２
のイベント配送識別子の取得要請はイベント配送先取得
部３３に配送され、当該イベント配送先取得部３３は上
記イベント配送順序管理部３４より順次イベント配送識
別子を取得するとともに、受け取ったイベント配送識別
子を上記イベント配送処理部３２に転送するようになっ
ている。

【００１２】これによって、ウインドウを介して目的と
するタスクに配送されるイベントも、ウインドウを介さ
ないで直接特定のタスクに配送されるイベントも一元的
に扱うことができ、それぞれの場合について個別の処理
手段を設ける必要がなくなる。

【００１３】上記イベント配送順序管理部３４には、上
記のようにタスクとウインドウに対応する識別子が並列
的に配列される場合の他に、ウインドウ識別子を別途ウ
ンドウ配送順序管理部３４１（３４１ａ、３４１ｂ）に
登録する方法が考えられる。この場合ウンドウ配送順序
管理部３４１に対応する識別子が、上記各タスクに対応
する識別子と並列にイベント配送順序管理部３４に配列
されることになる。

【００１４】上記ウインドウ配送順序管理部３４１はウ
インドウの位置を以てイベント配送順序関係を管理する
ようにしてもよく、また、ウインドウの生成順序を以て
イベント配送順序関係を管理するようにしてもよい。更
に、複数のウインドウに優先順位を設けておき、該優先
順位で以てイベント配送順序関係を管理してもよいし、
更にまた、ウィンドウを生成したタスクの起動順序を以
て管理するようにしてもよい。

【００１５】上記イベント配送順序管理部の識別子の配
列順序は、固定的であってもよいが、動作状況に合わせ
て動的に変更できる構成とすることができる。動的に変
更する場合は、そのときの状況に合わせて、最も使用確
率が高いイベントの識別子がイベント配列順序管理部
（ウンドウ配送順序管理部）の先頭に位置することにな
るので、リモコンのキーを押したときの応答速度が早く
なる効果がある。

【００１６】上記の処理によってタスク側に配送される
各イベントは、タスク側に設けたイベント受信部４１に
受け取られるが、このイベント受信部４１では、当該タ
スクに配信されたイベントが消費された場合であろう
と、未消費の場合であろうと、単に上記各イベントの配
信を受けて返送するだけの構成とすることができる。ま
た、配送されたイベントに消費状態に関する情報を付加
して、イベント配送処理部３２へ送り返す情報返送機能
を備えるとともに、上記イベント配送処理部が当該情報
の内容に従って必要な処理をする構成とすることもでき
る。例えば、「消費」が返送されたときには、次のイベ
ントを待つ。また、「未消費」あるいは「消費・継続」
が返送されたときには次の配送先を取得する処理を実行
する。

【００１７】

【発明の実施の形態】図７はディジタルＴＶを実現した
場合に使用されると予想されるタスクとウインドウ、更
に、リモコンの各ボタンとの関係を例示したものであ
る。

【００１８】データ放送タスクＴ２はリモコンの「デー
タ放送」ボタンを押下すると処理を開始しデータ表示ウ
インドウＷ２を表示するとともに、例えば、特定のデー
タソースから得られる天気予報等のデータを該ウインド
ウ内に表示するようになっている。また、この状態で、
「ページ上」・「ページ下」ボタンで改ページを行うこ
とができるようになっている。

【００１９】上記においては、データ表示ウインドウＷ
２が表示される迄は、直接データ放送タスクＴ２にイベ
ントを配送し所定の処理をしていることになり、データ
表示ウインドウＷ２が表示された後は、該ウインドウ上
でのフォーカス位置等ウインドウとの関連で必要なイベ
ントがデータ表示ウインドウＷ２を介して上記データ放
送タスクＴ２に配送されることになる。

【００２０】また、番組表タスクＴ１はリモコンの「番
組」ボタンで処理を開始し、チャネル列と時間列を表示
した状態の番組表ウインドウＷ１ａを表示する。この状
態で、上下左右ボタンのいずれかを押下してフォーカス
を目的のチャネルの目的の時間に移動させて決定ボタン
を押下すると、番組詳細情報ウインドウＷ１ｂが現れて
該ウインドウの内部に番組詳細情報が表示されるように
なっている。従って、この場合も番組表ウインドウＷ１
ａが現れる迄は直接番組表タスクＴ１に対してイベント
を配送していることになり、該番組表ウインドウＷ１ａ
が現れた後は該ウインドウを介して番組表タスクＴ１に
イベントを配送していることになる。

【００２１】下記表１はタスクまたは、ウインドウが受
け付け可能なイベントをリモコン上のボタンで例示した
ものであり、上記の記述内容をまとめて記述したもので
ある。但し、この内容はあくまで例示であってこれに限
定されるものではない。

【００２２】

【表１】 本発明は、上記のようにウインドウを介してタスクにイ
ベントを配送する処理と、直接タスクにイベントを配送
する処理が併存する場合に両者を一元管理できるように
なっている。

【００２３】

【実施例１】図１は、本発明の１実施形態を示す概念図
であり、図４はその動作手順を示すフロー図である。

【００２４】まず、リモコン１０よりの特定のボタンが
押下されると、該ボタンに対応する指示内容を含むリモ
コン信号が発信される。このリモコン信号はリモコン受
信部２０に受信されて、ここで、イベントに変換され、
このイベントはイベント配送手段３００のイベント解釈
部３１に入力されて、ここでイベントの種類が判別さ
れ、その後イベント配送処理部３２に渡されるようにな
っている（図４、ステップＳ４１〜Ｓ４３）。このイベ
ント配送処理部３２は、上記のようにしてイベントを受
け取ったとき、イベント配送先獲得要請をイベント配送
先取得部３３に対して通知し、この通知を受けたイベン
ト配送先取得部３３は、まず、イベント配送順序管理部
３４に図２、図３に示すように登録されている先頭のウ
インドウ識別子またはタスク識別子を取得する（図４、
ステップＳ４４）。ここに、上記イベント配信順序管理
部３４は具体的にはメモリ、ハードディスク等の記憶装
置である。尚、図２、図３に付いては後に詳しく説明す
る。

【００２５】このようにウインドウ識別子またはタスク
識別子を獲得したイベント配送先取得部３３は当該ウイ
ンドウ識別子またはタスク識別子をイベント配送処理部
３２に通知する。イベント配送処理部３２は受け取った
識別子がタスク識別子かウインドウ識別子かを判定し、
ウインドウ識別子である場合には後述するウインドウ管
理部３９（例えば図８参照）に問い合わせて、当該ウイ
ンドウを制御するタスク識別子を獲得する（図４、ステ
ップＳ４６→Ｓ４７）。このようにして得られたタスク
識別子あるいはウインドウ識別子によってイベント配送
処理部３２は、上記のようにイベント解釈部３１より配
送されたイベントの配送先タスクを確認したことになる
ので、該イベントを対象となるタスクのイベント受信部
４１に配送する（図４、ステップＳ４８）。

【００２６】イベント受信部４１の構成は種々の場合が
考えられ、例えば各タスクに対応するキューをメモリ上
に設定しておき、該キューに対してイベントを配送する
構成が考えられる。

【００２７】各タスクのイベント受信部４１には特定の
識別子を受信可能なマスクが設けられており、特定のタ
スクのイベント受信部４１は自タスクで上記のようにし
て配送されるイベントが受け入れ可能であれば、上記イ
ベントに対応してタスク（ウインドウに対応するタスク
を含む）の処理を開始し、この後、必要であれば描画処
理部４２が必要な描画処理をする。尚、特定のタスクが
どのような場合に特定のイベントを受け入れ可能かにつ
いては、上記表１において若干示したが、この態様につ
いては種々の状況に応じて決定されることになるので、
画一的なものではない。

【００２８】上記のようにイベント配送処理部３２が、
イベント配送順序管理部３４に登録された先頭のタスク
識別子に従って、イベント解釈部３１より配送されてき
たイベントを配送すると、イベント配送順序管理部３４
のカウンタをインクリメントする（図４、ステップＳ４
９）。次いで、上記イベント配送処理部３２は次のイベ
ント配送先取得要請をイベント配送先取得部３３に出
し、上記と同様にして、イベント配送順序管理部３４の
２番目の識別子（上記カウンタ値に対応する順位に位置
する識別子）がイベント配送処理部３２に渡されること
になる。この２番目の識別子に従って、イベント配送処
理部３２が保持している上記イベントを目的のタスクに
配送すると、さらに３番目の識別子についての処理が順
次なされ、終了を示す状態（上記カウンタが最終の順位
までカンウトを終えてＮＵＬＬ状態になったとき）を検
出すると、処理を終了し、次のイベントの発生を待つよ
うになっている（図４、ステップＳ４５：Yes ）。

【００２９】尚、上記においては、イベント配送処理部
３２が受け取った識別子がウインドウ識別子であるか、
タスク識別子であるかを判定し、ウインドウ識別子であ
る場合にウインドウ管理部３９に問い合わせて、対応す
るタスク識別子を得るようにしている（図４、ステップ
Ｓ４６→Ｓ４７）。しかしながらこの手順をイベント配
送先取得部３３に実行させ、イベント配送処理部３２は
イベントの配送のみを実行するようにしてもよい。さら
に、理解に供するため、ウインドウ管理部３９を別途設
けているが、後述する処理も含め、該ウインドウ管理部
３９の処理をイベント配送先取得部３３が行ってもよ
い。また、カウンタをインクリメントする手順（ステッ
プＳ４９）はイベント配送順序管理部３４の内容が正し
い手順で抽出されることを目的としており、イベント配
送先取得部３３による配送先取得の手順の次に位置させ
てもよい。

【００３０】図２はイベント配送順序管理部３４のタス
クあるいはウインドウの登録状態を示す一例である。タ
スク識別子（TaskID01,ID02,ID03) とウインドウ識別子
（WinID01,ID03,ID05)とが１列に登録されている。

【００３１】ここでこの登録状態は後に例示するよう
に、静的な状態と動的な状態が考えられる。静的な状態
は登録順序が固定されている構成をいう。また、動的な
状態はタスクが起動したときあるいはウインドウが生成
されたとき、該起動したタスクあるいは生成されたウイ
ンドウが先頭に登録され、既に登録されているタスクあ
るいはウインドウはその順序が繰り下げられるようにな
る。

【００３２】この場合、ウインドウが生成された順序
や、ウインドウを制御しているタスクの起動順序に従っ
てイベント配送順序管理部３４を構成してもよい。更
に、タスクあるいはウインドウに予め優先順位を付けて
おき、該優先順位に従ってイベント配送順序管理部３４
を構成してもよい。更に、状況に応じてタスク識別子あ
るいはウインドウ識別子の配列順序を入れ替えたり、追
加、挿入、削除ができるようにしてもよい。

【００３３】図３はイベント配送順序管理部３４の別の
態様を示すものである。タスク識別子（TaskID01,ID02,
ID03) は図２に示す場合と同様に登録されているが、ウ
インドウ識別子に代えてウインドウ配送順序管理部３４
１（３４１ａ、３４１ｂ）を特定するウインドウ順序識
別子(Window Order1又はWindow Order2)が格納され、該
ウインドウ配送順序管理部３４１ａ、３４１ｂにはウイ
ンドウ識別子が登録された状態になっている。このよう
に構成することによって、例えば、同一グループ、即ち
同一のタスクに属するウインドウ識別子をまとめて一つ
のウインドウ配送順序管理部３４１ａに登録することが
可能である。また、ウインドウ配送順序管理部３４１ｂ
に示すように上記ウインドウの位置を上記ウインドウ識
別子の代わりに登録しておき、該位置に対応して優先順
位を決定することも可能である。ウインドウの位置と
は、例えば表示装置における表示部の左上端を原点とし
て、下方向にＸ軸、右方向にＹ軸、手前方向にＺ軸（但
しＺ軸は仮想）をそれぞれ設定した場合の、ウインドウ
の左上端等の座標であり。上記Ｚ軸座標の一番大きい
（即ち仮想的に最も手前に表示されている）ウインドウ
をウインドウ配送順序管理部３４１ｂの最上部に配置す
ることで、該ウインドウの優先順位を高くすることがで
きる。いずれの場合であっても、上記したように静的、
動的いずれの方法でも採ることができる。

【００３４】尚、図３では説明の便宜上２つのウインド
ウ配送順序管理部３４１ａ、３４１ｂを示し、一方をウ
インドウ識別子で管理し、他方をウインドウの位置で管
理するようにしているが、ウインドウ配送順序管理部３
４１の数は状況に応じて設定することができる。また、
同一種類の管理方法（例えばウインドウの位置で管理す
る方法）を採るウインドウ配送順序管理部のみを採用す
ること、また、上記のように異なる種類の管理方法を採
るウインドウ配送順序管理部を採用することは、状況に
応じて設定することができる。

【００３５】

【実施例２】図５は上記イベント受信部４１でタスク識
別子を処理をする場合の別の実施形態を示すフロー図で
あり、図６はその概念図である。図６において、タスク
およびウインドウの図面上右から左に向かっての配列順
序がイベント配送順序管理部３４の上から下への配列順
序とする。

【００３６】ここで、各タスク側のイベント受信部４１
は単にイベントを受け取るだけでなく、以下に説明する
ように該イベントの消費状況に関する情報を当該イベン
トとともにイベント配送処理部３２に返送する機能を備
えるようにする。尚、あるイベントをトリガーとして対
応するタスクが意味のある処理を行うことをここではイ
ベントの「消費」という。

【００３７】上記の状態で、最初に取得したタスク識別
子（ウインドウ識別子）に従って、タスク側のイベント
受信部４１にイベントが配送される迄の手順（図５、ス
テップＳ４１〜Ｓ４９迄）は、上記図４に示す手順と同
じであるのでここでは説明を省略する。

【００３８】イベント配送処理部３２は上記のようにイ
ベントを該識別子に対応する特定のタスクのイベント受
信部４１に配送し、イベントが消費されたか否かの返送
を待つことになる（図５、ステップＳ５０）。上記のよ
うにイベントの配送を受けたイベント受信部４１は、配
送されたイベントについて自タスクで受け入れ可能なイ
ベントか否かを判断し、受け入れが可能であればれば該
イベントが消費された旨の情報「消費」とともに当該イ
ベントをイベント配送処理部３２に返送する。当該「消
費」を受けたイベント配送処理部３２は当該イベントを
破棄し次のイベントの発生を待つことになる（図５、ス
テップＳ５１→Ｓ４１）〔図６(a) 参照〕。

【００３９】上記イベントの配送を受けたイベント受信
部４１が自タスクで受け入れできないイベントであると
判断したときは、該イベントとともに該イベントが未消
費である旨の情報「未消費」をイベント配送処理部３２
に返送する。このようにイベントの返送を受けたイベン
ト配送処理部３２はイベント配送先取得部３３に次の配
送先を取得するように指示する（図５、ステップＳ５１
→Ｓ４４）。イベント配送先取得部３３はこの指示に基
づいてイベント配送順序管理部３４の配列順序に従って
次のタスク識別子あるいはウインドウ識別子を取得して
イベント配送処理部３２に渡し、イベント配送処理部３
２は、次のタスクに対してそのイベントを渡す。この手
順を順次繰り返してそのイベントが受け入れ可能なタス
クに配送されたときには、上記と同様に該イベントとと
もに「消費」の情報がイベント配送処理部３２に渡され
次のイベントの発生を待つことになる（図５、ステップ
Ｓ５１→Ｓ４１）〔図６(b) 参照〕。

【００４０】尚、上記においてイベント受信部４１より
返送される情報として「消費」、「未消費」を例に説明
したが、この２つに限られるものではなく、必要に応じ
て他の情報を返送することができる。例えば、消費した
けれども次の配送先にも同じイベントを配送する旨の
「消費・継続」を返送するようにしておくと、上記図５
の消費か未消費かの判断において「Ｎｏ」となって、次
の配送先の取得処理に戻ることになる（図５、ステップ
Ｓ５１→Ｓ４４）〔図６(c) 参照〕。例えば番組詳細情
報ウインドウが生成されている状態で一定時間放置され
ることによって、スクリーンセーバタスクが動作しスク
リーンセーバがかかった場合、上矢印キーが押下された
ときスクリーンセーバタスクが、該上矢印キーのイベン
トを受けてスクリーンセーバを解除し、続けて番組表タ
スクが同じ上矢印キーのイベントで上方へ改ページをす
る場合などである。

【００４１】尚、図６(c) において説明した「消費・継
続」の場合に、次に当該イベントが消費されるウインド
ウあるいはタスクが既に「未消費」を返送したタスク
（ウインドウ）である場合がある（すなわち、イベント
配送順序管理部３４の配列上上位の位置（図６上では
右）に位置することもある）。そこで、イベント配送順
序管理部３４の識別子の配列順序を動的に変更できる場
合には、次に当該イベントが消費されるタスク（ウイン
ドウ）に対応する識別子を「消費・継続」を返送したタ
スク（ウインドウ）に対応する識別子の下位の順序に位
置させるように、イベント配送順序管理部の配列を変更
するようにしてもよい。また、イベント配送順序管理部
の識別子の配列が固定的である場合にはイベント配送順
序管理部３４の配列順序の最後の識別子に対応するタス
クまでイベントを順次配送し、更に、最上位の位置に戻
って、当該イベントが消費される迄イベントの配送を継
続するようにしてもよい。

【００４２】以上のように構成することによって、実施
の形態１に示した例のようにリモコンより配送された特
定のイベントがすでにタスク側で受け入れられているに
も関わらず、イベント配送処理部３２等が可動する無駄
を省くことができる。

【００４３】

【実施例３】図８は図２に示したイベント配送順序管理
部３４を使用した場合の更に具体的な動作状態を示すも
のである。

【００４４】図８において特定のタスクが起動したと
き、該タスクによって描画されるウインドウの生成に必
要な情報（位置・高さ・幅・色等の情報）とともに、ウ
インドウ生成のリクエストを該タスクからウインドウ管
理部３９に通知すると、ウインドウ管理部３９はそれら
の情報に基づいて必要な資源を獲得してウインドウを描
画するようになっている。

【００４５】ここで、上記イベント配送順序管理部３４
のイベント順序テーブル３４ｔには例えば「番組表タス
ク」、「番組表ウインドウ」、「番組詳細情報ウインド
ウ」、「データ放送タスク」、「データ放送ウインド
ウ」、「字幕タスク」・・の順にタスク識別子とウイン
ドウ識別子が固定的に配列されている場合を想定する。

【００４６】ここでユーザがリモコン１０の字幕ボタン
を押すと、イベント配送処理部３２の要求に従って、イ
ベント配送先取得部３３は上記イベント配送順序管理部
３４の上記イベント順序テーブル３４ｔよりまず番組表
タスクＴ１の識別子を取得する。次いでイベント配送先
取得部３３は上記番組表タスクＴ１に対応する識別子を
イベント配送処理部３２に転送し、これによってイベン
ト配送処理部３２は、この番組表タスクＴ１の識別子に
従って、上記字幕ボタンに対応するイベントを番組表タ
スクＴ１のキューに配送する（図４、図５、ステップＳ
４８）。ここで、番組表タスクＴ１は図７において示す
ように、リモコンの番組ボタンに対応するイベントで起
動／終了するので、字幕ボタンに対応するイベントが送
られてきても処理を開始しない。

【００４７】図４に示したフロー図の例では、上記のよ
うに配送されたイベントが特定のタスクに受け入れられ
ようが、受け入れられまいがイベント配送処理部３２は
次の配送先を取得するようにイベント配送先取得部３３
にイベント配送先獲得要請を出すようになっている。ま
た、図５に示したフロー図の例では、上記のように配送
されたイベントが特定のタスクに受け入れられない場合
には、イベント配送処理部３２は次の配送先を取得する
ようにイベント配送先取得部３３にイベント配送先獲得
要請を出すようになっている。

【００４８】従って、図４の場合であっても図５の場合
であっても、イベント配送処理部３２は、次の識別子獲
得要請をイベント配送先取得部３３に渡し、該イベント
配送先取得部３３が、イベント順序テーブル３４ｔ上の
２番目に配列されている番組表ウインドウＷ１ａに対応
する識別子を取得してイベント配送処理部３２に渡すこ
とになる。イベント配送処理部３２は当該識別子がウイ
ンドウに対応する識別子であることを認識して、ウイン
ドウ管理部３９に対して対応のタスクを問い合わせる。
ここでウインドウ管理部３９が、自己の管理下に置いて
いる上記識別子に関する情報を基に、イベント配送処理
部３２に上記番組表ウインドウＷ１ａに対応するタスク
が番組表タスクＴ１であることを通知すると（図４、図
５ステップＳ４６→Ｓ４７）、番組表タスクＴ１のキュ
ーに上記字幕ボタンに対応するイベントを送出する。今
度も番組表タスクＴ１は当該イベントが不要であるので
起動されないことになる。なお、上記”自己の管理下に
置く”とは、例えば上記ウインドウ管理部３９が、ある
タスクの指示により新規ウインドウを生成した時に、当
該新規ウインドウに、対応する識別子を与えるととも
に、上記新規ウインドウの作成指示を出した上記タスク
の識別子、及びその他ウインドウの生成に必要な情報を
合わせて所定の記憶部に記憶し、上記イベント配送処理
部３２からの問い合わせ要求に応じて、問い合わされた
ウインドウを制御しているタスクの情報を送信すること
を言う。ここに上記必要な情報とは、例えばタスク識別
子（ここでは番組表タスクＴ１の識別子）、親ウィンド
ウからの相対位置（ｘ，ｙ）、ウィンドウの幅、高さな
どである。

【００４９】このように、図４あるいは図５の手順に従
って、字幕ボタンに対応するイベントが上記イベント順
序テーブル３４ｔに配列された識別子に対応するタスク
に配送される手順を繰り返して、上記イベント順序テー
ブル３４ｔ上の字幕タスクの識別子がイベント配送取得
部３３に取得されるとイベント配送処理部３２が当該字
幕ボタンに対応するイベントを字幕タスクＴ３に配送す
ることになる。これによって、当該イベントは字幕タス
クＴ３に受け取られて当該字幕タスクＴ３が処理を開始
することになる。

【００５０】ここで上記図４に示す手順では、上記のよ
うにイベントが字幕タスクＴ３に消費されても、上記イ
ベント順序テーブル３４ｔの最後迄順次識別子を取得す
る手順を継続することになる。また、図５に示す手順で
あって、イベント受信部４１より「消費」の情報を受け
たときは字幕タスクＴ３が、上記イベントに消費された
時点で、次のイベントを待つ状態（図５、ステップＳ４
１）に戻ることになるが、一方、イベント受信部４１よ
り「消費・継続」の情報を受けたときは字幕タスクＴ３
が、上記イベントに消費されても、「消費」の情報を受
け取るまで、イベント配送先取得部３３より順次得られ
る次の配送先に同じイベントを配送することになる。

【００５１】このように字幕ボタンに対応するイベント
が字幕タスクＴ３に受け取られると、当該字幕タスクＴ
３が処理を開始して、字幕ウインドウＷ３を生成するた
めに必要な情報をウインドウ管理部３９に通知し、該ウ
インドウ管理部３９が表示手段２００上に必要な字幕ウ
インドウＷ３を生成するようになっている。

【００５２】以上のように、リモコンのボタンに対応し
て動作するタスク（アプリケーション）へのイベント配
送処理と、ウィンドウへのイベント配送処理とを、統一
的に扱うことにより、複数の制御方法を管理し整合性を
とる必要が無くなるため、イベント制御を容易にするこ
とが可能となる。

【００５３】さらに、ユーザーがリモコンを介して入力
したイベントが、所定のウインドウ（タスク）のみに対
応する場合には、イベントが実行されるべきタスクに自
動的に配送されるため、フォーカスを移動するといった
操作が必要なく、ユーザーの負担を軽減することができ
る。

【００５４】次に、図９はイベント順序テーブルが動的
に変動する場合の概念図である。ここでは現在の動作状
態に合わせてイベント順序テーブル３４ｔの各識別子の
配列順序を動的に変更するイベント配送先取得部３３が
置かれる。

【００５５】今、番組表タスクＴ１に対応する識別子が
イベント順序テーブル３４ｔ（図９(a) ）の先頭に位置
している状態で、リモコン１０上で番組表ボタンが押さ
れたとすると、上記したように番組表タスクに対応する
識別子が一番最初にイベント配送先取得部３３に取得さ
れ、イベント配送処理部３２は当該イベントを番組表タ
スクＴ１に配送する。これによって、番組表タスクＴ１
が起動すると、当該番組表タスクＴ１は番組表ウインド
ウＷ１ａを生成するのに必要な情報をウインドウ管理部
３９に渡し、ウインドウ管理部３９は該情報を自己の管
理下に置くとともに表示手段２００に該データに基づい
た番組表ウインドウＷ１ａを表示する（図７参照）。

【００５６】次いで上記ウインドウ管理部３９は番組表
ウインドウＷ１ａが表示されたことをイベント配送先取
得部３３に通知するとともに、上記番組表ウインドウＷ
１ａに対応する識別子を送信する。これに伴い、上記イ
ベント配送先取得部３３は、イベント配送順序管理部３
４内の上記イベント順序テーブル３４ｔ（図９(a) ）
を、上記番組表タスクＴ１の上位の位置に上記番組表ウ
インドウＷ１ａに対応する識別子を配置したイベント順
序テーブル３４ｔ（図９(b) ）に更新することになる。
ここに、上記番組表ウインドウＷ１ａは、新聞のラジオ
テレビ欄のように、各番組毎かつ時間毎といった所定選
択可能範囲で区切られており、ユーザはその区切り単位
で選択することが可能になっている。続いてユーザは、
上下左右キーを使用して、上記所定の選択可能範囲中、
希望する特定のチャネルの特定の時間にフォーカスを移
動し、「決定」キーを押す。該「決定」キーの押下によ
り、上記のように先頭に配列された番組表ウインドウＷ
１ａの識別子が取得され，当該「決定」キーのイベント
を、番組表ウインドウＷ１ａを介して上記番組表タスク
Ｔ１に配送することになる。

【００５７】すなわち、図４、図５におけるタスク識別
子かウインドウ識別子かの判断の手順（図４、図５、ス
テップＳ４６）でウインドウ識別子と判断され、ここで
イベント配送処理部３２が当該ウインドウ識別子に対応
する番組表タスクＴ１の識別子をウインドウ管理部３９
より取得すると、当該番組表タスクＴ１に上記「決定」
キーのイベントが配送される（図４、図５、ステップＳ
４６→Ｓ４７→Ｓ４８）。

【００５８】これによって番組表タスクＴ１は、更に番
組表の詳細ウインドウ情報をウインドウ管理部３９に通
知し、ウインドウ管理部３９は上記番組表ウインドウＷ
１ａ上に、更に、番組詳細情報ウインドウＷ１ｂを表示
する（図７参照）ことになり、上記イベント順序テーブ
ル３４ｔ（図９(c) ）は上記番組詳細情報ウインドウＷ
１ｂを先頭の位置に配列することになる。

【００５９】上記において、イベント配送先取得部３３
が、イベント配送順序管理部３４内のイベント順序テー
ブル３４ｔにウインドウ識別子を配列する場合には、ウ
インドウ管理部３９による情報に基づいているが、例え
ばデータ放送タスクＴ２が起動したときには、上記イベ
ント配送先取得部３３は、タスク管理部４００からの情
報に基づいてデータ放送タスクＴ２に対応する識別子を
イベント順序テーブル３４ｔの先頭位置に配列すること
になる。ここに上記情報とは、例えばタスクの起動状態
やイベントの待ち状態など、イベント順序テーブル３４
ｔへの配列順序を変更させる必要の有無を判断できる内
容である。すなわち、上記タスク管理部４００は、カー
ネル内部の情報等を参照し、タスクが起動状態になれば
イベント配送先取得部３３へその旨を通知し、イベント
配送先取得部３３はそれを受けてイベント順序テーブル
３４ｔの設定を行う。なお，上記タスク管理部４００の
存在は必須ではなく、各タスク（番組表タスクＴ１等）
が起動後、イベント配送先取得部３３に対して、タスク
管理部４００を介することなく直接イベント順序テーブ
ル３４ｔの設定（変更、追加等）を要求することで、イ
ベント順序テーブル３４ｔの各識別子の位置を設定して
もよい。また、タスク管理部４００の行う処理をイベン
ト配送先取得部３３が行ってもよい。

【００６０】以上のように、イベント順序テーブルが動
的に変動することによっても、イベント制御を容易にす
ることが可能となり、さらに、ユーザーがリモコンを介
して入力したイベントが、所定のタスク（ウインドウ）
のみに対応する場合には、イベントが実行されるべきタ
スクに自動的に配送されるため、フォーカスを移動する
といった操作が必要なく、ユーザーの負担を軽減するこ
とができる。

【００６１】なお、ユーザーが入力したイベントを複数
のタスクが実行可能な場合、即ち、例えば複数のウイン
ドウが表示されている場合で、さらに各ウインドウが同
一のイベントを受入れ可能な場合がある。このような場
合には、ユーザーが予め目的とするウインドウにフォー
カスを移動したり、リモコン上のタスクボタン（番組表
タスク、データ放送タスク等）を押下し、イベント配送
順序管理部３４におけるイベント識別子の配置を変更す
ることで、目的とするタスクのみにイベントを配送可能
とすることができる。但し、上述したように、イベント
順序テーブルは動的に変動するため、一連の操作を行う
殆どの場合にはフォーカスを移動する必要がない。

【００６２】次に、図１０はタスク識別子とウインドウ
配送順序管理部３４１を特定するためのウインドウ順序
識別子をイベント順序テーブル３４ｔに登録した図３に
示すイベント配送順序管理部３４を用いた場合の例を示
すものである。

【００６３】初期の状態では、図１１(a) に示すように
表示手段２００に天気情報（データ放送）が表示されて
おり、イベント順序テーブル３４ｔの先頭にウインドウ
順序識別子が配列されているものとする。また、当該ウ
インドウ順序識別子に関連付けられているウインドウ配
送順序管理部３４１では、データ表示ウインドウＷ２に
対応する識別子が先頭に位置したウインドウ順序テーブ
ル３４１ｔが生成されているものとする。

【００６４】上記の状態は、データ放送ボタンが押下さ
れることによって形成される。すなわちデータ放送ボタ
ンが押下されると、そのイベントを受けたデータ放送タ
スクＴ２自身や他のタスク或いは予め設定されたシステ
ム内部からの要求に従って、データ放送タスクＴ２がイ
ベント順序テーブル３４ｔの先頭に位置することにな
る。ついで、データ放送タスクＴ２が処理を開始する
と、該データ放送タスクＴ２の指示に基づいて、ウイン
ドウ管理部３９により上記データ表示ウインドウＷ２が
生成され、該データ表示ウインドウＷ２が生成された旨
の情報は、上記ウインドウ管理部３９よりイベント配送
先取得部３３に通知されるとともに、上記データ表示ウ
インドウＷ２に対応する識別子も送信される。これに基
づいてイベント配送先取得部３３は、イベント配送順序
管理部３４に対して、イベント順序テーブル３４ｔの先
頭に上記ウインドウ順序識別子を位置させることにな
る。また、上記データ表示ウインドウＷ２に対応する識
別子を、イベント配送順序管理部３４を構成するウイン
ドウ配送順序管理部３４１のウインドウ順序テーブル３
４１ｔの先頭に位置させる（１０図(a) ）。また、な
お、上記ウインドウ順序識別子をイベント順序テーブル
３４ｔの先頭に位置することは必須ではなく、イベント
順序テーブル３４ｔの各識別子の位置は移動せずに、ウ
ィンドウ順序テーブル３４１ｔ内のデータ表示ウインド
ウの識別子を先頭に位置させるだけでもよい。

【００６５】この状態で、リモコン１０より番組ボタン
が押下されると上記実施の形態１、実施の形態２で説明
した手順で番組表タスクＴ１が起動し、該番組表タスク
Ｔ１が起動した旨の情報は、タスク管理部４００を介し
てイベント配送先取得部３３に渡され、番組表タスクＴ
１がイベント順序テーブル３４ｔの先頭に配置される
（１０図(b) ）。番組表タスクＴ１が処理を開始する
と、表示手段２００上には図１１(b) に示すように時間
軸とチャネル軸を持つ番組表ウインドウＷ１ａが生成さ
れる。これらの時間軸とチャネル軸は、上述したよう
に、新聞のラジオテレビ欄のように、各番組毎かつ時間
毎といった所定選択可能範囲で区切られており、その区
切り単位でユーザは選択することが可能になっている。
上記番組表ウインドウＷ１ａが生成された旨の情報は、
ウインドウ管理部３９を介してイベント配送先取得部３
３に通知されるとともに、上記番組表ウインドウＷ１ａ
に対応する識別子もイベント配送先取得部３３に送信さ
れる。なお、上記ウインドウ管理部３９は、同時に当該
番組表ウインドウＷ１ａに関する情報（タスク識別子
（ここでは番組表タスクＴ１の識別子）、親ウィンドウ
からの相対位置（ｘ，ｙ，ｚ）、ウィンドウの幅、高さ
等）を自己の管理下に置く。

【００６６】上記番組表ウインドウＷ１ａが生成された
旨の情報に基づいて、ウンドウ配送順序管理部３４１
は、上記データ表示ウインドウＷ１ａに対応する識別子
をウインドウ順序テーブル３４１ｔの先頭に位置させる
ことになる。この状態では上記ウインドウ順序識別子に
関連付けられているウインドウ配送順序管理部３４１の
持つウインドウ順序テーブル３４１ｔは上から、番組表
ウインドウ、データ表示ウインドウ・・のそれぞれに対
応する識別子となり、この順序は表示手段の手前からの
表示順序と一致する。

【００６７】次いで、ウインドウ管理部３９を介して上
記番組表ウインドウＷ１ａが生成されたことを受けて、
イベント配送順序管理部３４では、ウインドウ順序識別
子をイベント順序テーブル３４ｔの先頭に配置されるこ
とになる（１０図(c) ）。

【００６８】この状態で、ユーザが特定のチャネルの番
組を得る目的で、上記図１１(b) に示すように表示され
た番組表ウインドウＷ１ａ上で、リモコンの左右上下キ
ーを用いてフォーカスを目的のチャネルの目的の時間に
まで移動し、決定キーを押下するとウィンドウＷ１a が
イベントを受ける。即ち、ユーザーが行った上下左右キ
ーや決定キーなどの操作のイベントは、まず、イベント
配送処理部３２に送信される。上記イベントを受信した
配送処理部３２は、イベントの送信先をイベント配送先
取得部３３に問い合わせる。上記イベント配送先取得部
３３は、イベント配送順序管理部３４よりイベント配送
先を取得する。即ち、イベント配送先取得部３３は、該
イベント配送順序管理部３４において、１０図(c) のイ
ベント順序テーブル３４ｔの先頭にある、ウインドウ順
序識別子を介してウインドウ順序テーブル３４１ｔの先
頭に配置される番組表ウインドウの識別子を参照し、当
該番組表ウインドウの識別子をイベント配送処理部３２
へ配送先として通知する。

【００６９】これにより、上記イベント配送処理部３２
は、番組表ウインドウの識別子を得ることができる。こ
こで、上記番組表ウインドウの識別子がウインドウ識別
子であるため、上記イベント配送処理部３２は、ウイン
ドウ管理部３９に、該ウインドウ識別子を有するウイン
ドウＷ１ａを制御しているタスクを問い合わせる。問い
合わせを受けた上記ウインドウ管理部３９は、自己の管
理下にある番組表タスクＴ１の識別子をイベント配送処
理部３２に返信する。

【００７０】以上により、上記イベント配送処理部３２
は、番組表タスクＴ１にイベントを送信し、その結果、
番組表タスクＴ１は、番組表ウィンドウＷ１a 上で選択
範囲を示した部分（フォーカス）を移動する。さらに、
同様に決定キーに対するイベント処理も番組表タスクＴ
１で行われ、その結果、番組表タスクＴ１は、新たなウ
ィンドウＷ１b を生成する。その後、イベント配送先取
得部３３に対してウィンドウ順序テーブル３４１ｔのイ
ベント配送順序の変更を要求し、生成したウィンドウＷ
１b を表示状態にする。新たなウィンドウＷ１b を生成
した時の各部の処理も上述したものと同様である。

【００７１】これにより、図１１(c) に示すように、そ
のチャネルの番組詳細情報ウインドウＷ１ｂが表示され
ることになる。このときの上記ウインドウ配送順序管理
部３４１は最前面の特定のチャネルの番組詳細情報ウイ
ンドウＷ１ｂに対応する識別子が先頭に、ついで、上記
番組表ウインドウＷ１ａに対応する識別子が２番目に、
更に、データ表示ウインドウＷ２に対応する識別子が３
番目に配列されたウインドウ順序テーブル３４１ｔを生
成していることになる（１０図(d) ）。

【００７２】上記では表示手段の前面からの配列順序で
ウンドウ配送順序管理部３４１での配列に優先順位を付
けているが、また、別途のルールに従って配列すること
も可能である。

【００７３】すなわち、ウインドウの生成順序を以てイ
ベント配送順序関係を管理すること、あるいは、予めウ
インドウに優先順位を設定しておき、該優先順位に従っ
てイベント配送順序関係を管理すること、更に、ウィン
ドウを生成したタスクの起動順序を以て管理すること等
である。また、図面上ウインドウは重なった状態（例え
ば番組表ウインドウと番組詳細情報ウインドウ）で描か
れているが、必ずしも重ねて表示する表示する必要はな
い。

【００７４】尚、上記各実施の形態において、図１２に
示すようにリモコン受信部２０はＴＶ装置内に回路とし
て内蔵され、イベント配送手段３００（イベント解釈部
３１、イベント配送処理部３２、イベント配送取得部３
３、ウインドウ管理部３９）及びタスク管理部はメモリ
に格納されたプログラムとＣＰＵで構成されることにな
る。但し、イベント配送順序管理部３４（即ちイベント
順序テーブル３４ｔ，ウインドウ順序テーブル３４１
ｔ）はＲＯＭ、あるいはＲＡＭ等のメモリに格納される
ことになる。又、イベント受信部４１である各タスクに
対応するキューはＲＡＭ等のメモリの特定の領域に形成
されることになる。

【００７５】

【発明の効果】以上説明したように、本発明によるとリ
モコンのダイレクトボタンに対応して動作するタスク
（アプリケーション）へのイベント配送処理と、ウィン
ドウへのイベント配送処理とを、統一的に扱うことにな
り、アプリケーションからのイベント制御を容易にする
ことが可能となる。

【００７６】さらに、ユーザーによるリモコンボタンの
押下、即ちイベントの入力が、どのタスクに対応するも
のであるかが自動で判別されることとなり、ユーザーは
フォーカスを所定の場所に合わせる必要がなく、操作性
が良好となる。

【図面の簡単な説明】

【図１】本発明の基本構成を示すブロック図である。

【図２】イベント配送順序管理部の例を示す図である。

【図３】イベント配送順序管理部の別の例を示す図であ
る。

【図４】本発明の処理手順を示すフロー図である。

【図５】本発明の処理手順を示すフロー図である。

【図６】本発明の別の構成を示すブロック図である。

【図７】本発明に使用する表示手段の表示状態を示す図
である。

【図８】本発明の動作状態を示す概念図である。

【図９】本発明の動作状態を示す概念図である。

【図１０】本発明の動作状態を示す概念図である。

【図１１】本発明の場面の表示例を示す概念図である。

【図１２】本発明のシステム図である。

【符号の説明】

３２ イベント配送処理部 ３３ イベント配送先取得部 ３４ イベント配送順序管理部 ３４１ ウンドウ配送順序管理部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｎ 7/03 Ｈ０４Ｑ 9/00 ３３１Ａ 7/035 Ｇ０６Ｆ 3/14 ３５０Ａ Ｈ０４Ｑ 9/00 ３０１ Ｈ０４Ｎ 7/08 Ａ ３３１ // Ｇ０６Ｆ 3/14 ３５０

Claims (13)

【特許請求の範囲】
1. 【請求項１】 タスクを特定できるタスク識別子とウイ
   ンドウを特定できるウインドウ識別子（以下単にイベン
   ト配送識別子という）を並列に登録したイベント配送順
   序管理部と、 特定のイベントが発生したとき、当該イベントが配送さ
   れるべき上記イベント配送識別子の取得要請を実行する
   とともに、得られたイベント配送識別子に対応するタス
   クにイベントを配送するイベント配送処理部と、 上記イベント配送取得要請を受けて、上記イベント配送
   順序管理部より順次イベント配送識別子を取得するとと
   もに、受け取ったイベント配送識別子を上記イベント配
   送処理部に転送するイベント配送先取得部と、 を備えたことを特徴とするイベント配送制御システム。
2. 【請求項２】 さらにウインドウ識別子と、該ウインド
   ウ識別子により特定されるウインドウを生成したタスク
   のタスク識別子とを関連付けて記憶すると共に、上記イ
   ベント配送処理部からの上記ウインドウ識別子を指定し
   た問い合わせに対し、上記関連付けられたタスク識別子
   を返答するウインドウ管理部を具備する請求項１に記載
   のイベント配送制御システム。
3. 【請求項３】 上記イベント配送先取得部が、上記ウイ
   ンドウ管理部の機能を兼ねる請求項２に記載のイベント
   配送制御システム。
4. 【請求項４】 ウインドウ識別子の配列順序でイベント
   の配送順序関係を管理するウインドウ配送順序管理部
   と、 上記ウインドウ識別子にかえてウインドウ配送順序管理
   部に配列されたウインドウ識別子を参照することが可能
   な上記イベント配送先取得部とを備えた請求項３に記載
   のイベント配送制御システム。
5. 【請求項５】 上記ウインドウの位置を以てイベント配
   送順序関係を管理する上記ウインドウ配送順序管理部を
   備えた請求項４に記載のイベント配送制御システム。
6. 【請求項６】 上記ウインドウの生成順序を以てイベン
   ト配送順序関係を管理する上記ウィンドウ配送順序管理
   部を備えた請求項４に記載のイベント配送制御システ
   ム。
7. 【請求項７】 上記ウインドウの優先順位を以てイベン
   ト配送順序関係を管理する上記ウインドウ配送順序管理
   部を備えた請求項４に記載のイベント配送制御システ
   ム。
8. 【請求項８】 上記ウィンドウを生成したタスクの起動
   順序を以てイベント配送順序関係を管理する上記ウイン
   ドウ配送順序管理部を備えた請求項４に記載のイベント
   配送制御システム。
9. 【請求項９】 イベント配送順序管理部に配列される識
   別子の順序を動的に変更できる請求項５〜８のいずれか
   １項に記載のイベント配送制御システム。
10. 【請求項１０】 タスク側に備えたイベント受信部が、
    イベントの消費状態に関連する情報をイベントに付加し
    てイベント配送処理部へ返送するイベント返送機能を備
    えるとともに、イベント配送処理部が上記情報の内容に
    従って必要な処理をする請求項１に記載のイベント配送
    制御システム。
11. 【請求項１１】 上記消費状態に関連した情報がイベン
    トの消費を意味する「消費」、イベントの未消費を意味
    する「未消費」、イベントを消費したが配送を継続する
    を意味する「消費・継続」の少なくともいずれか１つで
    あって、「未消費」または「消費・継続」が返送された
    場合に、上記イベント配送処理部が、次のイベント配送
    識別子の取得要請を実行する請求項１０に記載のイベン
    ト配送制御システム。
12. 【請求項１２】 タスクを特定できるタスク識別子とウ
    インドウを特定できるウインドウ識別子（以下単にイベ
    ント配送識別子という）を並列に登録し、 特定のイベントが発生したとき、当該イベントが配送さ
    れるべき上記イベント配送識別子を、上記並列に登録さ
    れたイベント配送識別子より取得するとともに、 上記取得したイベント配送識別子に対応するタスクにイ
    ベントを配送することを特徴とするイベント配送制御方
    法。
13. 【請求項１３】 タスクを特定できるタスク識別子とウ
    インドウを特定できるウインドウ識別子（以下単にイベ
    ント配送識別子という）を並列に登録する処理と、特定
    のイベントが発生したとき、当該イベントが配送される
    べき上記イベント配送識別子を、上記並列に登録された
    イベント配送識別子より取得する処理と、上記取得した
    イベント配送識別子に対応するタスクにイベントを配送
    する処理と、をプログラムとして記録したコンピュータ
    読み取り可能な記録媒体。