JP6022131B1

JP6022131B1 - ユーザーインターフェイス装置、ユーザーインターフェイス表示方法

Info

Publication number: JP6022131B1
Application number: JP2016540097A
Authority: JP
Inventors: 嘉章北村; 宏平田中; 下谷　光生; 光生下谷; 幸夫後藤; 明豊岡
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2015-01-27
Filing date: 2016-01-21
Publication date: 2016-11-09
Anticipated expiration: 2036-01-21
Also published as: US20180004403A1; US10387019B2; WO2016121620A1; JPWO2016121620A1; CN107209654A; CN107209654B; DE112016000495T5

Abstract

ユーザー入力イベントを受け取るべき画面レイヤー以外に、ユーザー入力イベントを受け取らない画面レイヤーが重なって表示されている場合でも、効率的にユーザー入力イベントを配送すべき画面レイヤーを決定できる技術に関する。ユーザーインターフェイス装置は、取得部（１０２）と、送信部（１０３）と、判断部（１０７）と、決定部（１０４）とを備える。判断部では、送信部からの問い合わせ情報に基づいて、入力情報が各画面レイヤーにおいて受け付けられるか否かが複数の画面レイヤーに対して並行して判断される。決定部は、判断結果に基づいて画面レイヤーを決定する。

Description

本技術は、複数の画面レイヤーからなる画面を表示するユーザーインターフェイス装置に関するものである。

情報機器のユーザーインターフェイスとして、複数の画面レイヤーからなる画面を表示する装置が存在する。各画面レイヤーは、画面レイヤー上の領域に対してアルファ値とよばれる透過率を表す情報を保持している。各画面レイヤーは、アルファ値に基づいて重畳的に表示されることにより、特定の領域のみ下位の画面レイヤーを表示させたり、画面レイヤー同士が重なった場合に半透明の画像が重なっているように表示させたりすることが可能である。

このような装置において、ユーザーは複数の画面レイヤーが表示されている画面に対して、マウスのクリック又はタッチパネルのタップなどを行うことによって、特定のオブジェクトを選択する可能性がある。この時、ユーザーからの入力があったというイベントは、一般的に最前面の画面レイヤーにのみ送られる。しかし、ユーザーが選択しようとしているオブジェクトが最前面の画面レイヤーに表示されているものとは限らないため、ユーザーが選択したいオブジェクトを即座に選択することができないという問題が発生する。

この問題を解決する方法として、例えば、特許文献１においては、各画面レイヤーにしきい値を設定しておき、ユーザーからの入力を受け取る座標のアルファ値がしきい値を超えていた場合にはユーザー入力イベントを受け取り、当該座標のアルファ値がしきい値を下回った場合には、ユーザー入力イベントを下位の画面レイヤーに再配送する方法が開示されている。

また、例えば、特許文献２においては、ユーザー入力イベントの種類に対して各画面レイヤーの優先度があらかじめ設定されており、ユーザー入力イベントの種類と当該優先度とに応じて、ユーザー入力イベントの配送先が決定される方法が開示されている。

特許第４８５６７５６号公報特許第４５２２５３３号公報

しかし、例えば、特許文献１に開示されているユーザー入力イベントの配送先決定方法では、ユーザー入力イベントを受け取るべき画面レイヤーの上位に、ユーザー入力イベントを受け取らない画面レイヤーが多数重なって表示されている場合には、上位の各画面レイヤーを順に探索していく必要がある。各画面レイヤーに表示されている表示内容は異なるプロセスによって描画されている場合が多く、上位の画面レイヤーを順に探索していると、画面レイヤー間の通信が大量に発生してしまう。その結果として、ユーザー入力イベントが実行されるまでに時間がかかってしまうという問題がある。

また、例えば、特許文献２に開示されているユーザー入力イベントの配送先決定方法では、１つの画面レイヤー内にユーザー入力イベントを受け取る領域とユーザー入力イベントを受け取らない領域とが混在する場合には、意図したようには動作できない場合がある。このような場合にも正しく高速に動作させるためには、画面レイヤー内の各領域に対する優先度をテーブルなどにあらかじめ保持しておく必要がある。しかし、このテーブルは、画面レイヤーに表示されているユーザー入力イベントを受け取るオブジェクトの位置又は形状などが変化した場合、さらには画面レイヤー自体の位置又は形状などが変化した場合に、それに合わせて変更する必要がある。したがって、オブジェクトの位置又は形状、さらには画面レイヤーの位置又は形状が頻繁に変化する場合、又はアニメーションのように連続的にそれらが変化する場合には、上記のテーブルの更新に時間がかかり、位置又は形状の変化が滑らかに表示されない可能性がある。また、ユーザー入力イベントの種類に応じて優先度を設定するテーブルを別途有する必要があるため、テーブルを記憶するための記憶領域も大量に必要となる。

本技術は、上記のような問題を解決するものであり、ユーザー入力イベントを受け取るべき画面レイヤー以外に、ユーザー入力イベントを受け取らない画面レイヤーが重なって表示されている場合であっても、効率的にユーザー入力イベントを配送すべき画面レイヤーを決定できるユーザーインターフェイス装置、および、ユーザーインターフェイス表示方法に関するものである。

本技術の一態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示可能なユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する決定部とを備える。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部における処理速度に応じて決定する。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部において用いるＣＰＵの数に応じて決定する。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、あらかじめ定められた切り替え条件を満たした場合、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、各前記画面レイヤーに対して逐次的に判断する。

本技術の一態様に関するユーザーインターフェイス表示方法は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示させるユーザーインターフェイス表示方法であり、外部からの入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信し、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断し、前記判断の結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する。

本技術の一態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示可能なユーザーインターフェイス装置である。ユーザーインターフェイス装置は、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する決定部とを備える。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部における処理速度に応じて決定する。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部において用いるＣＰＵの数に応じて決定する。
また、本技術の他の態様に関するユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、外部からの入力情報を取得する取得部と、前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、前記判断部は、あらかじめ定められた切り替え条件を満たした場合、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、各前記画面レイヤーに対して逐次的に判断する。

このような構成によれば、ユーザー入力イベントを受け取るべき画面レイヤー以外に、ユーザー入力イベントを受け取らない画面レイヤーが重なって表示されている場合であっても、効率的にユーザー入力イベントを配送すべき画面レイヤーを決定できる。

本技術の一態様に関するユーザーインターフェイス表示方法は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示させるユーザーインターフェイス表示方法である。ユーザーインターフェイス表示方法は、外部からの入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信し、前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断し、前記判断の結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する。

本技術の目的、特徴、局面及び利点は、以下の詳細な説明と添付図面とによって、より明白となる。

実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。実施形態に関するユーザーインターフェイス装置を実現するハードウェア構成の一例を示す図である。イベント配送要否並行取得部における、各画面レイヤーに対するイベント配送要否の確認要求の処理の流れを示すフローチャートである。各画面レイヤーに対し実施されるイベント配送要否の確認処理の流れを示すフローチャートである。イベント配送要否統合部への結果送信の可否を判定する送信可否の判定処理の流れを示すフローチャートである。イベント配送要否統合部におけるイベント配送要否の統合処理の流れを示すフローチャートである。複数の画面レイヤーが重畳してなる画面の一例を示す図である。１つ以上の画面レイヤーがイベント配送要否の確認結果を返信していない場合であっても、イベント配送要否の確認結果の送信を行う場合における、処理の流れを示すフローチャートである。１つ以上の画面レイヤーがイベント配送要否の確認結果を返信していない場合であっても、イベント配送要否の確認結果の送信を行う場合における、処理の流れを示すフローチャートである。実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。イベント配送要否並行取得部における、各画面レイヤーに対するイベント配送要否の確認要求の処理の流れを示すフローチャートである。イベント配送要否並行取得部の送信可否の判定処理の流れを示すフローチャートである。処理装置のコア数を取得して並行取得数格納部に格納する処理のフローチャートである。何も処理を実行していない又は使用率が少ない処理装置のコア数を取得して、並行取得数格納部に格納する処理を示すフローチャートである。実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。イベント配送要否並行取得部における、イベント配送要否の確認要求処理の流れを示すフローチャートである。優先度格納部にアプリケーションの種類に応じた優先度が格納されている場合の、イベント配送要否の確認要求処理の流れを示すフローチャートである。優先度格納部にユーザー入力イベントの種類に応じた優先度が格納されている場合の、イベント配送要否の確認要求処理の流れを示すフローチャートである。優先度格納部にユーザーインターフェイス装置の状態に応じた優先度が格納されている場合の、イベント配送要否の確認要求処理の流れを示すフローチャートである。優先度格納部に外部機器との接続状態に応じた優先度が格納されている場合の、イベント配送要否の確認要求処理の流れを示すフローチャートである。実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。イベント配送先決定方法切替部の処理の流れを示すフローチャートである。イベント配送要否の確認が必要な画面レイヤー数によってイベント配送先決定方法を切り替える場合の処理の流れを示すフローチャートである。処理装置のコア数に基づいてイベント配送先決定方法を切り替える場合の処理の流れを示すフローチャートである。ユーザー入力イベントの種類がドラッグである際に、ドラッグイベントが続く限り最初にドラッグイベントを配送した画面レイヤーに対して配送し続ける場合の処理の流れを示すフローチャートである。ドラッグ開始時のイベント配送要否統合部の処理の流れを示すフローチャートである。ユーザー入力イベントの種類がドラッグであった場合の処理の流れを示すフローチャートである。イベント配送要否統合部におけるイベント配送要否統合処理の流れを示すフローチャートである。実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。

以下、添付の図面を参照しながら実施形態について説明する。なお、図面は模式的に示されるものであり、異なる図面にそれぞれ示されている画像のサイズ及び位置の相互関係は、必ずしも正確に記載されるものではなく、適宜変更され得る。また、以下の説明では、同様の構成要素には同じ符号を付して図示し、それらの名称及び機能も同様のものとする。よって、それらについての詳細な説明を省略する場合がある。

また、以下の説明では、「上」又は「下」などの特定の位置及び方向を意味する用語が用いられる場合があるが、これらの用語は、実施形態の内容を理解することを容易にするため便宜上用いられているものであり、実際に実施される際の方向とは関係しない。

＜第１実施形態＞
＜構成＞
図２９は、本実施形態に関するユーザーインターフェイス（以下、ＵＩともいう）装置の構成を概念的に示す図である。

図２９に示されるユーザーインターフェイス装置は、複数の画面レイヤーの少なくとも一部を重畳させて画面に表示可能なユーザーインターフェイス装置である。そして、ユーザーインターフェイス装置は、取得部１００２と、送信部１００３と、判断部１００７と、決定部１００４とを備える。

取得部１００２は、外部からの入力情報を取得する機能部である。送信部１００３は、入力情報が各画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する機能部である。判断部１００７は、問い合わせ情報に基づいて、入力情報が各画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の画面レイヤーのうちの少なくとも２つの画面レイヤーに対して並行して判断する機能部である。決定部１００４は、判断部１００７における判断結果に基づいて、入力情報が受け付けられる少なくとも１つの画面レイヤーを決定する機能部である。

図１は、上記の本実施形態に関するユーザーインターフェイス（以下、ＵＩともいう）装置の構成をさらに具体的に示す図である。

図１に示されるユーザーインターフェイス装置は、入力装置１０１と、ユーザー入力イベント取得部１０２と、イベント配送要否並行取得部１０３と、イベント配送要否統合部１０４と、イベント配送先決定部１０５と、イベント配送部１０６と、画面レイヤー管理部１０７と、画面レイヤー内情報格納部１０８と、イベント処理部１０９と、描画制御部１１０と、表示装置１１１とを備える。

図２９に示される取得部１００２は、図１に示されるユーザー入力イベント取得部１０２に対応する。図２９に示される送信部１００３は、図１に示されるイベント配送要否並行取得部１０３に対応する。図２９に示される判断部１００７は、図１に示される画面レイヤー管理部１０７に対応する。図２９に示される決定部１００４は、図１に示されるイベント配送要否統合部１０４に対応する。

入力装置１０１は、表示装置１１１において表示されているユーザーインターフェイスに対して、ユーザーが操作を行うための装置である。具体的には、マウス、タッチパネル、トラックボール、データグローブ又はスタイラスなどのポインティングデバイス、又は、キーボード又はマイクなどの音声入力装置、又は、カメラなどの画像又は映像入力装置、又は、脳波による入力装置、又は、モーションセンサなどのセンサ類などである。

ユーザー入力イベント取得部１０２では、入力装置１０１において行われた操作に対応するユーザー入力イベントが取得される。ここで、ユーザー入力イベントとは、入力装置１０１におけるあらゆる種類の操作を含む。例えば、マウスによるカーソルの移動、マウスの右ボタン又は左ボタンのクリック開始、マウスの右ボタン又は左ボタンのクリック終了、マウスのダブルクリック、マウスのドラッグ、マウスのホイール操作、マウスの移動による特定表示要素へのポインタの接近、マウスの移動による特定表示要素上へのポインタの移動、マウスの移動による特定表示要素外へのポインタの移動、タッチパネルによるタッチ、タッチパネルによるタップ、タッチパネルによるダブルタップ、タッチパネルによるホールド、タッチパネルによるフリック、タッチパネルによるスワイプ、タッチパネルによるピンチイン、タッチパネルによるピンチアウト、タッチパネルによるローテート、タッチパネル面への指などの接近、１本又は複数本の指を用いたジェスチャ操作、キーボードによるキーの押下、キーボードによるキーのリリース、又は、キーボードによる複数キーの同時操作などがある。また、時間、速度、加速度、複数ユーザーの組合せ又は複数の入力装置の組合せなどにより、独自又は新たなユーザー入力イベントを定義してもよい。なお、これらのユーザー入力イベントは一例であり、その他ユーザーの意図又は意思に起因するすべての操作をユーザー入力イベントとする。

イベント配送要否並行取得部１０３では、ユーザー入力イベント取得部１０２において取得されたユーザー入力イベントを必要としているかどうかについて、各画面レイヤーに対し時間的に並行して行われた判断結果（イベント配送要否）を取得する。具体的には、イベント配送要否並行取得部１０３が、画面レイヤー管理部１０７へユーザー入力イベントに関する情報を送信する。ここで、ユーザー入力イベントに関する情報とは、上記のユーザー入力イベントの種類、入力された位置、入力された時間または入力された速度などに関する情報である。ただし、座標情報を用いずに画面レイヤー全体としてイベント配送要否が定められているような場合も想定されるため、ユーザー入力イベントに関する情報に、座標情報などの数値または文字列が含まれていなくともよい。そして、画面レイヤー管理部１０７は、画面レイヤー管理部１０７において管理している各画面レイヤーに関する情報と受信したユーザー入力イベントに関する情報とを時間的に並行して照合し、当該ユーザー入力イベントが各画面レイヤーに必要とされているか（当該イベントの入力が受け付けられるか）に関する情報をイベント配送要否としてイベント配送要否並行取得部１０３へ送信する。

イベント配送要否統合部１０４では、イベント配送要否並行取得部１０３において取得された各画面レイヤーのイベント配送要否を統合し、ユーザー入力イベントを配送すべき画面レイヤーを決定する。イベント配送要否並行取得部１０３とイベント配送要否統合部１０４とを併せて、イベント配送先決定部１０５が実現されている。

イベント配送部１０６は、イベント配送要否統合部１０４において決定された画面レイヤーに対して、ユーザー入力イベントを配送する。

画面レイヤー管理部１０７は、各画面レイヤーの重畳関係などを管理する。また、画面レイヤー管理部１０７は、各画面レイヤーがユーザー入力イベントを受け付けられるかに関する情報を含む、各画面レイヤーに関する情報を管理する。

画面レイヤー内情報格納部１０８は、画面レイヤーの位置又は形状、表示されているオブジェクト、又は、ユーザー入力イベントを受け取る領域などの情報を格納する。

イベント処理部１０９は、イベント配送部１０６において配送されたユーザー入力イベントを対象の画面レイヤーにおいて処理する。処理結果によっては、画面レイヤー管理部１０７又は画面レイヤー内情報格納部１０８の内容を更新する。

描画制御部１１０では、イベント処理部１０９の処理結果、画面レイヤー管理部１０７の内容及び画面レイヤー内情報格納部１０８の内容に基づいて、表示装置１１１に表示する画面を描画する。表示装置１１１は、ディスプレイ又はタッチパネルといった、描画制御部１１０において描画した画面を出力するための装置である。

図２は、上記のＵＩ装置を実現するハードウェア構成の一例を示す図である。

画面レイヤー内情報格納部１０８は、例えば、コンピューター２０１における、ＲＡＭ又はハードディスクといった記憶装置２０３によって実現されるが、外部の記憶媒体によって実現されていてもよい。

また、ユーザー入力イベント取得部１０２と、イベント配送先決定部１０５に内包されるイベント配送要否並行取得部１０３及びイベント配送要否統合部１０４と、イベント配送部１０６と、画面レイヤー管理部１０７と、イベント処理部１０９と、描画制御部１１０とは、例えば、コンピューター２０１における、処理装置２０２でプログラムを実行することにより実現される。処理装置２０２は、実際に処理を実行するコアが複数内包されている場合であってもよい。入力装置１０１は、マウス２０５又はキーボード２０６などが対応する。表示装置１１１は、ディスプレイ２０４などが対応する。なお、入力装置１０１及び表示装置１１１のハードウェア構成としては、入力及び出力のどちらも行えるタッチパネルなども対応しうる。その場合には、入力装置１０１及び表示装置１１１のハードウェア構成は、同一の装置で実現されてもよい。

＜動作＞
図７は、複数の画面レイヤーが重畳してなる画面の一例である。図７の（ａ）部は、表示装置１１１に表示される画面を示している。また、図７の（ｂ）部は、図７（ａ）部に表示される画面の、画面レイヤーのレイヤー構造を示している。

図７の（ａ）部に示された画面は、図７の（ｂ）部に示されるように、画面レイヤー７０３、画面レイヤー７０２及び画面レイヤー７０１が下から順に重畳されて１つの画面を構成することにより表示されるものである。

図７の（ｂ）部において、画面レイヤー７０１を最上位の画面レイヤーと呼称する。画面レイヤー７０３は最下位の画面レイヤーと呼称する。また、画面レイヤー７０２から見て画面レイヤー７０１のように重なった際に自身（すなわち画面レイヤー７０２）が隠される画面レイヤーを上位の画面レイヤー、画面レイヤー７０３のように重なった際に自身（すなわち画面レイヤー７０２）が表示される画面レイヤーを下位の画面レイヤーと呼称する。

このような画面を表示するユーザーインターフェイス装置における、ユーザーの操作入力からユーザー入力イベントの配送先画面レイヤーの決定までの動作の流れについて、以下に説明する。

まず、ユーザーは入力装置１０１において何らかの操作を実行する。操作された内容は、ユーザー入力イベント取得部１０２においてユーザー入力イベントとして取得される。

次に、現在、表示装置１１１において表示されている各画面レイヤーに対して、ユーザー入力イベント取得部１０２において取得されたユーザー入力イベントの配送要否の判断を時間的に並行して行い、イベント配送要否として取得する。

図３は、イベント配送要否並行取得部１０３における、各画面レイヤーに対するイベント配送要否の確認要求の処理の流れを示すフローチャートである。

イベント配送要否並行取得部１０３は、まず、各画面レイヤーに対してイベント配送要否の確認要求を送信する。

具体的には、まずステップＳＴ３０１に示されるように、イベント配送要否並行取得部１０３は、画面レイヤー管理部１０７から、イベント配送要否の確認要求を未だ受けていない最上位の画面レイヤーに関する情報を取得する。

次に、ステップＳＴ３０２に示されるように、ステップＳＴ３０１において取得された情報に対応する画面レイヤーに対し、イベント配送要否並行取得部１０３からイベント配送要否の確認要求が送信される。具体的には、イベント配送要否並行取得部１０３が画面レイヤー管理部１０７に対しユーザー入力イベントに関する情報を送信し、画面レイヤー管理部１０７における各画面レイヤーに関する情報との照合を各画面レイヤーに関して時間的に並行して行わせる。

次に、ステップＳＴ３０３に示されるように、イベント配送要否並行取得部１０３において、すべての画面レイヤーに対してイベント配送要否の確認要求が送信されたかどうかが確認される。すべての画面レイヤーに対してイベント配送要否の確認要求が送信されていた場合（Ｙｅｓ）には、イベント配送要否の確認要求処理を終了する。すべての画面レイヤーに対してイベント配送要否確認要求が送信されていない場合（Ｎｏ）は、ステップＳＴ３０１に戻る。

図４は、各画面レイヤーに対し実施されるイベント配送要否の確認処理の流れを示すフローチャートである。

画面レイヤー管理部１０７では、各画面レイヤーに対するイベント配送要否の確認要求が受信されると、他の画面レイヤーの処理と並行してイベント配送要否の確認処理が実施される。

具体的には、まずステップＳＴ４０１に示されるように、画面レイヤー管理部１０７において、画面レイヤー内情報格納部１０８から対応する画面レイヤーに関する情報が取得され、各画面レイヤーごとにユーザー入力イベントの配送要否が確認される。この場合、各画面レイヤーのイベント配送要否の確認方法は、特定の場合に限られるものではない。例えば、各画面レイヤーにしきい値を設定しておき、ユーザー入力イベントに対応する画面上の座標のアルファ値がしきい値を超えていた場合には当該ユーザー入力イベントを受け付け、ユーザー入力イベントに対応する画面上の座標のアルファ値がしきい値を超えていない場合には当該ユーザー入力イベントを受け付けないとする方法であってもよいし、画面レイヤーに関する情報自体がユーザー入力イベントに対する配送要否を保持する方法であってもよいし、画面レイヤー内の表示オブジェクトに問い合わせを行う方法であってもよい。

次に、ステップＳＴ４０２に示されるように、ステップＳＴ４０１において確認されたユーザー入力イベントの配送要否が各画面レイヤーからイベント配送要否並行取得部１０３に返信される。

図５は、イベント配送要否統合部１０４への結果送信の可否を判定する送信可否の判定処理の流れを示すフローチャートである。

イベント配送要否並行取得部１０３では、ステップＳＴ４０２において返信されたイベント配送要否の確認結果が受信されると、当該返信されたイベント配送要否の確認結果をイベント配送要否統合部１０４へ送信してよいか否かを判定する送信可否判定処理が実施される。

具体的には、まずステップＳＴ５０１に示されるように、イベント配送要否並行取得部１０３において、すべての画面レイヤーからイベント配送要否の確認処理の結果が返信されているか否かが判断される。すべての画面レイヤーからイベント配送要否確認処理の結果が返信されている場合（Ｙｅｓ）には、イベント配送要否並行取得部１０３は、すべての結果をイベント配送要否統合部１０４へ送信する（ステップＳＴ５０２を参照）。すべての画面レイヤーからイベント配送要否確認処理の結果が返信されていない場合（Ｎｏ）は、イベント配送要否並行取得部１０３は、何もせずに処理を終了する。この送信可否判定処理は、並行して処理されているすべてのイベント配送要否の確認処理の結果の返信に対して実施される。

図６は、イベント配送要否統合部１０４におけるイベント配送要否の統合処理の流れを示すフローチャートである。

イベント配送要否統合部１０４では、イベント配送要否並行取得部１０３において取得されたイベント配送要否が統合され、ユーザー入力イベントの配送先となる画面レイヤーが決定される。

具体的には、まずステップＳＴ６０１に示されるように、イベント配送要否統合部１０４は、画面レイヤー管理部１０７から未だ取得していない画面レイヤーの情報のうちから最上位の画面レイヤーの情報を取得する。

次に、ステップＳＴ６０２に示されるように、イベント配送要否統合部１０４において、イベント配送要否並行取得部１０３から取得されたイベント配送要否確認処理の結果を用いて、ステップＳＴ６０１において取得した情報に対応する画面レイヤーのイベント配送の要否を判断する。イベント配送が必要であった場合（Ｙｅｓ）は、ステップＳＴ６０３へ進む。イベント配送が必要でなかった場合（Ｎｏ）は、ステップＳＴ６０４へ進む。

ステップＳＴ６０３では、イベント配送が必要な画面レイヤーが判明したため、イベント配送要否統合部１０４において、ステップＳＴ６０１において取得した情報に対応する画面レイヤーを、ユーザー入力イベントの配送先画面レイヤーとして決定する。

一方で、ステップＳＴ６０４では、イベント配送要否統合部１０４において、画面レイヤー管理部１０７からすべての画面レイヤーに関する情報を取得したか否かを判断する。すべての画面レイヤーに関する情報を取得していた場合（Ｙｅｓ）は、ステップＳＴ６０５へ進む。すべての画面レイヤーを取得していない場合（Ｎｏ）は、ステップＳＴ６０１へ戻る。

ステップＳＴ６０５では、すべての画面レイヤーについてユーザー入力イベントの配送が必要ないため、イベント配送要否統合部１０４においてユーザー入力イベントの配送先画面レイヤーはなしと判断し、現在処理しているユーザー入力イベントの配送を行わずに処理を終了する。

このように、本実施形態では、ユーザー入力イベントの配送先画面レイヤーの決定する際に、すべての画面レイヤーに対して並行してユーザー入力イベントの配送要否の確認処理を実行することにより、ユーザー入力イベントを受け取るべき画面レイヤーの上位にユーザー入力イベントを受け取らない画面レイヤーが多数重畳されている場合においても、オブジェクト位置又は形状、又は、画面レイヤーの位置又は形状の変化の阻害、又は記憶領域の大量占有を行わずに、高速で配送先画面レイヤーを決定することが可能である。

＜第２実施形態＞
以下では、上記実施形態で説明された構成と同様の構成については同じ符号を付して図示し、その詳細な説明については適宜省略する。

第１実施形態においては、図５に示されるように、イベント配送要否並行取得部１０３における送信可否の判定処理として、すべての画面レイヤーのイベント配送要否の確認結果を取得した後に、イベント配送要否統合部１０４へイベント配送要否の確認結果を送信する動作が記載されている。しかし、可能であればすべての画面レイヤーのイベント配送要否の確認結果を取得する前に、イベント配送要否統合部１０４へイベント配送要否の確認結果を送信してもよい。

本実施形態では、各画面レイヤーのイベント配送要否の確認結果を、各画面レイヤーから並行して取得している際に、より早く取得を完了させるため、すべての画面レイヤーについてイベント配送要否の確認処理が完了していなくとも、条件によってイベント配送要否の確認結果の取得を終了し、その時点で取得したイベント配送要否の確認結果を、イベント配送要否並行取得部１０３がイベント配送要否統合部１０４へ送信する。

図８は、あらかじめ設定された条件が満たされた際に、１つ以上の画面レイヤーがイベント配送要否の確認結果を返信していない場合であっても、イベント配送要否並行取得部１０３がイベント配送要否統合部１０４へイベント配送要否の確認結果の送信を行う場合における、処理の流れを示すフローチャートである。

図８において、図５における場合と同一の符号を付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ８０１に示されるように、イベント配送要否の確認結果が返信された際に、イベント配送要否並行取得部１０３において、当該イベント配送要否の確認結果の受信が、設計者によってあらかじめ設定された条件を満たしているか否かが判断される。条件が満たされた場合（Ｙｅｓ）はステップＳＴ８０２へ進み、満たされていない場合（Ｎｏ）はステップＳＴ５０１へ進む。

ステップＳＴ８０２では、イベント配送要否並行取得部１０３が、現在処理を実行している各画面レイヤーに対して処理の中断を指示する。

また、より具体的には、イベント配送要否の確認結果が返信された際に、イベント配送要否の確認結果を返信した画面レイヤーよりも上位に存在するすべての画面レイヤーがすでにイベント配送要否の確認結果を返信していた場合、イベント配送要否の確認結果を返信した画面レイヤーよりも下位に存在する画面レイヤーがイベント配送要否の確認結果を返信していないとしても、イベント配送要否の統合処理に影響を及ぼさないため、イベント配送要否の確認結果の送信を行ってもよい。

図９は、イベント配送要否の確認結果が返信された際に、イベント配送要否の確認結果を返信した画面レイヤーよりも上位に存在するすべての画面レイヤーがすでにイベント配送要否の確認結果を返信していた場合、イベント配送要否の確認結果を返信した画面レイヤーよりも下位に存在する画面レイヤーがイベント配送要否の確認結果を返信していないとしても、イベント配送要否並行取得部１０３がイベント配送要否統合部１０４へイベント配送要否の確認結果の送信を行う場合における、処理の流れを示すフローチャートである。

図９において、図５における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ９０１に示されるように、イベント配送要否の確認結果が返信された際に、イベント配送要否並行取得部１０３において、当該イベント配送要否の確認結果を返信した画面レイヤーよりも上位の画面レイヤーすべてのイベント配送要否の確認結果がすでに取得されているか否かを判断する。取得済みであった場合（Ｙｅｓ）は、ステップＳＴ９０２へ進む。取得済みでない場合（Ｎｏ）は、即座に処理を終了する。

ステップＳＴ９０２では、イベント配送要否並行取得部１０３が、イベント配送要否の確認結果がユーザー入力イベントの配送を必要とするものか否かを判断する。イベント配送要否の確認結果がユーザー入力イベントの配送を必要とするものであった場合（Ｙｅｓ）は、ステップＳＴ９０３へ進む。イベント配送要否の確認結果がユーザー入力イベントの配送を必要とするものでなかった場合（Ｎｏ）は、ステップＳＴ５０１へ進む。

ステップＳＴ９０３では、イベント配送要否並行取得部１０３が、現在処理を実行している各画面レイヤーに対して処理の中断を指示する。

なお、上記の例では、各画面レイヤーのイベント配送要否の確認処理が終了した際に、あらかじめ設定された条件が満たされた場合にイベント配送要否の確認結果をイベント配送要否並行取得部１０３からイベント配送要否統合部１０４へ送信していたが、この処理を、イベント配送要否並行取得部１０３ではなくイベント配送要否統合部１０４で行うこともできる。すなわち、イベント配送要否並行取得部１０３を経由せずに、イベント配送要否統合部１０４においてあらかじめ設定された条件が満たされた場合に、すぐにユーザー入力イベントの配送先画面レイヤーを決定する処理を行ってもよい。

このように、本実施形態では、すべての画面レイヤーに対してイベント配送要否の確認処理が完了していなくとも、イベント配送要否統合部１０４へイベント配送要否の確認結果を送信し、さらにイベント配送要否統合部１０４において、複数の画面レイヤーのうちの一部の画面レイヤーに関する判断結果に基づいてユーザー入力イベントが受け付けられる画面レイヤーを決定することが可能であるため、より高速にユーザー入力イベントの配送先画面レイヤーを決定することが可能となる。

＜第３実施形態＞
以下では、上記実施形態で説明された構成と同様の構成については同じ符号を付して図示し、その詳細な説明については適宜省略する。

第１実施形態においては、図３に示されるように、イベント配送要否並行取得部１０３におけるイベント配送要否の確認要求処理において、すべての画面レイヤーに対して画面レイヤー管理部１０７においてイベント配送要否の確認処理を実行するように要求していたが、イベント配送要否の確認処理を実行するよう要求する画面レイヤー数を制限してもよい。同時並行的にイベント配送要否の確認処理を実行する場合においても、処理装置２０２の各コアが実行可能な処理には限りがあるため、各コアが実行する処理数を制限することにより各々の処理を高速化することが可能である。

図１０は、本実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。

図１０に示されるユーザーインターフェイス装置の構成のうち、図１に示されたユーザーインターフェイス装置の構成と同様であるものについては同一の符号を付し、ここでの説明は省略する。

本実施形態では、ユーザーインターフェイス装置は、同時並行的にイベント配送要否の確認処理を実行する画面レイヤー数を格納している並行取得数格納部１００１を備える。並行取得数格納部１００１は、例えば、コンピューター２０１における、ＲＡＭ又はハードディスクといった記憶装置２０３によって実現されるが、外部の記憶媒体によって実現されていてもよい。

イベント配送要否並行取得部１０３がイベント配送要否の確認要求処理を実施する際に、並行取得数格納部１００１に格納された値を基にイベント配送要否の確認処理を実行するよう要求する画面レイヤー数を決定する。並行取得数格納部１００１に格納される画面レイヤー数は、例えば、画面レイヤー管理部１０７における処理速度に応じて定められる。

図１１は、本実施形態におけるイベント配送要否並行取得部１０３における、各画面レイヤーに対するイベント配送要否の確認要求の処理の流れを示すフローチャートである。

図１１において、図３における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１１０１に示されるように、イベント配送要否並行取得部１０３が、並行取得数格納部１００１に格納された値を取得する。

ステップＳＴ１１０２では、イベント配送要否並行取得部１０３が、ステップＳＴ１１０１において取得された値に基づいた数の画面レイヤーへ、イベント配送要否の確認要求を送信したか否かを判断する。送信していた場合（Ｙｅｓ）は処理を終了する。送信していない場合（Ｎｏ）は、ステップＳＴ３０１へ戻る。

図１２は、本実施形態に関するイベント配送要否並行取得部１０３の送信可否の判定処理の流れを示すフローチャートである。

図１２において、図５における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１１０１に示されるように、イベント配送要否並行取得部１０３において、並行取得数格納部１００１に格納された値に基づいた数の画面レイヤーが画面レイヤー管理部１０７において並行処理され、そのイベント配送要否の確認結果が返信されたか否かが判断される。並行取得数格納部１００１に格納された値に基づいた数の画面レイヤーからイベント配送要否の確認結果が返信されている場合（Ｙｅｓ）には、ステップＳＴ１２０２へ進む。並行取得数格納部１００１に格納された値に基づいた数の画面レイヤーからイベント配送要否の確認結果が返信されていない場合（Ｎｏ）には、処理を終了する。

なお、並行取得数格納部１００１へ値を格納する方法及び並行取得数格納部１００１に格納された値の利用方法は、どのような方法であってもよい。例えば、設計者があらかじめ並行取得数格納部１００１へ値を格納しておき、本実施形態に関するユーザーインターフェイス装置の動作実行中は、常に同じ値あってもよい。また、並行取得数格納部１００１に格納された値が直接利用されてもよいし、並行取得数格納部１００１に格納された値に基づいて演算された結果が利用されてもよい。

また、格納される情報は値、文字列、リスト又はバイナリなど、利用される際に解釈可能であればどのような形式のデータであってもよいが、本実施形態では、値である場合の例について説明している。以下、並行取得数格納部１００１へ値が格納される方法及び並行取得数格納部１００１に格納された値の利用方法に関する具体例を説明する。

一例として、同時並行的にイベント配送要否の確認処理を実行する場合、その処理速度は処理装置２０２のコア数、すなわち、中央演算処理装置（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ、すなわちＣＰＵ）の数に依存するため、処理装置２０２のコア数を取得し、並行取得数格納部１００１へ格納する方法について説明する。

図１３は、処理装置２０２のコア数を取得して並行取得数格納部１００１に格納する処理のフローチャートである。

まず、ステップＳＴ１３０１に示されるように、処理装置２０２のコア数に関する情報が外部から取得される。次に、ステップＳＴ１３０２に示されるように、取得されたコア数に関する情報が並行取得数格納部１００１に格納される。

この時、並行取得数格納部１００１へ値を格納するタイミングは、イベント配送要否並行取得部１０３の処理が実行されるまでであればよく、一例としては、ユーザーインターフェイス装置の起動時に格納しておく方法がある。この格納処理は、処理装置２０２のコア数が変動しない場合は、いずれかのタイミングで一度だけ実行すればよい。一方で、処理装置２０２のコア数が変動する場合には、イベント配送要否並行取得部１０３の処理の実行前又は処理装置２０２のコア数が変動した際に再度格納処理を実行する必要がある。

一例として、処理装置２０２が他のアプリケーションの処理などイベント配送要否並行取得部１０３の処理以外の処理を実行している場合もあるため、何も処理を実行していない又は使用率が少ない処理装置２０２のコア数を取得し、並行取得数格納部１００１へ格納する方法について説明する。なお、しきい値となる使用率はあらかじめ決めておいてもよいし、実行中に動的に変動させてもよい。

図１４は、何も処理を実行していない又は使用率が少ない処理装置のコア数を取得して、並行取得数格納部１００１に格納する処理を示すフローチャートである。

まず、ステップＳＴ１４０１では、何も処理を実行していない又は使用率が少ない処理装置のコア数に関する情報が取得される。次に、ステップＳＴ１４０２では、取得されたコア数に関する情報が並行取得数格納部１００１に格納される。

この時、並行取得数格納部１００１へ値を格納するタイミングは、イベント配送要否並行取得部１０３の処理が実行される直前が望ましいが、これに限定されない。例えば、処理装置２０２が実行している処理を監視しておき、処理を実行していない処理装置２０２のコア数が変動した際に、並行取得数格納部１００１へ値を格納する方法もある。

このように、本実施形態では、画面レイヤー管理部１０７において同時並行的に実行されるイベント配送要否の確認要求処理の数を制限することによって各々の処理を高速化し、これを逐次的に実行することができるため、特に、イベント配送要否の確認要求を送信する順番が早く回ってくる画面レイヤーがユーザー入力イベントを必要としている場合に、ユーザー入力イベント配送先画面レイヤーを高速に決定することが可能である。

＜第４実施形態＞
以下では、上記実施形態で説明された構成と同様の構成については同じ符号を付して図示し、その詳細な説明については適宜省略する。

第１実施形態においては、図３に示されるように、イベント配送要否並行取得部１０３におけるイベント配送要否の確認要求処理において、最上位の画面レイヤーから順番にイベント配送要否の確認要求を送信していたが、各画面レイヤーに優先順位を設定し、優先順位にしたがってイベント配送要否の確認要求を送信してもよい。

優先順位を設定することにより、処理装置２０２の各コアに割り当てられる処理を平準化すること、又はユーザー入力イベントを受け取る可能性が高い画面レイヤーのイベント配送要否の確認処理を早めに実行することが可能となる。これは第２実施形態及び第３実施形態に示されるように、すべての画面レイヤーに対してイベント配送要否の確認要求を送信しなくとも、ユーザー入力イベントの配送先画面レイヤーを決定可能な場合に特に効果が高い。

図１５は、本実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。

図１５に示されるユーザーインターフェイス装置の構成のうち、図１に示されたユーザーインターフェイス装置の構成と同様であるものについては同一の符号を付し、ここでの説明は省略する。

本実施形態では、ユーザーインターフェイス装置は、イベント配送要否の確認要求を送信する優先順位を決定するための優先度を格納している優先度格納部１５０１を備える。優先度格納部１５０１は、例えば、コンピューター２０１における、ＲＡＭ又はハードディスクといった記憶装置２０３によって実現されるが、外部の記憶媒体によって実現されていてもよい。

イベント配送要否並行取得部１０３がイベント配送要否の確認要求処理を実行する際に、優先度格納部１５０１に格納されている優先度を基に各画面レイヤーに対してイベント配送要否の確認要求を送信する。

図１６は、本実施形態におけるイベント配送要否並行取得部１０３における、イベント配送要否の確認要求処理の流れを示すフローチャートである。

図１６において、図３における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１６０１に示されるように、イベント配送要否並行取得部１０３が、優先度格納部１５０１から各画面レイヤーに対する優先度を取得する。

ステップＳＴ１６０２では、イベント配送要否並行取得部１０３が、イベント配送要否の確認要求を未だ送信していない画面レイヤーの中で最も優先度が高い画面レイヤーを取得する。

なお、優先度格納部１５０１へ優先度を格納する方法及び優先度格納部１５０１に格納された優先度の利用方法は、どのような方法であってもよい。例えば、設計者があらかじめ優先度を格納しておき、本実施形態に関するユーザーインターフェイス装置が動作実行中は、常に同じ値あってもよい。また、優先度格納部１５０１に格納された優先度が直接利用されてもよいし、優先度格納部１５０１に格納された優先度に基づいて演算された結果が利用されてもよい。

また、格納する情報は値、文字列、リスト又はバイナリなど、利用される際に解釈可能であればどのような形式のデータであってもよい。以下、本実施形態に関する優先度格納部１５０１への優先度の格納方法及び優先度格納部１５０１に格納された優先度利用方法に関する具体例を説明する。

一例として、アプリケーションの種類に応じて優先度を設定している場合について説明する。

本実施形態に関するユーザーインターフェイス装置では、地図を表示するアプリケーション又は映像を表示するアプリケーションなど、様々なアプリケーションが同時に動作している場合がある。これらのアプリケーションは、表示すべき内容を画面レイヤー上に表示しており、他の画面レイヤーと同様にユーザー入力イベントを受け取る可能性がある。この例では、表示されているアプリケーションに応じてイベント配送要否の確認要求を送信する順番を決定する。

例えば、映像を表示するアプリケーションの優先度よりも地図を表示するアプリケーションの優先度が高い場合は、地図を表示するアプリケーションを表示している画面レイヤーに対して、先にイベント配送要否の確認要求が送信される。

図１７は、優先度格納部１５０１にアプリケーションの種類に応じた優先度が格納されている場合の、イベント配送要否並行取得部１０３における、イベント配送要否の確認要求処理の流れを示すフローチャートである。

図１７において、図１６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１７０１に示されるように、イベント配送要否並行取得部１０３が、優先度格納部１５０１からアプリケーションの種類に応じた優先度を取得する。

ステップＳＴ１７０２では、イベント配送要否並行取得部１０３が、イベント配送要否の確認要求を送信していない画面レイヤーの中で最も優先度の高いアプリケーションを表示している画面レイヤーを取得する。なお、アプリケーションを表示していない画面レイヤーについては、どのような優先順位であっても構わない。例えば、アプリケーションを表示している画面レイヤーにイベント配送要否の確認要求を送信した後に、アプリケーションを表示していない画面レイヤーにイベント配送要否の確認要求を送信する方法でもよい。また、アプリケーションを複数表示している画面レイヤーが存在する場合には、その画面レイヤーに対しどのように優先順位を決定してもよい。例えば、どちらか一方の優先度を利用してもよいし、複数のアプリケーションを表示しているものを最優先にしてもよい。

一例として、ユーザー入力イベントの種類に応じて優先度を設定している場合について説明する。ユーザー入力イベントの種類は第１実施形態において説明されたように様々な種類が存在している。この例では、ユーザー入力イベントの種類１つ１つに対して優先度が設定されているものとし、各ユーザー入力イベントの種類に応じてイベント配送要否の確認要求を送信する順番を決定する。

図１８は、優先度格納部１５０１にユーザー入力イベントの種類に応じた優先度が格納されている場合の、イベント配送要否並行取得部１０３における、イベント配送要否の確認要求処理の流れを示すフローチャートである。

図１８において、図１６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１８０１に示されるように、イベント配送要否並行取得部１０３が、ユーザー入力イベントの種類を取得する。

ステップＳＴ１８０２では、取得されたユーザー入力イベントの種類に応じて、イベント配送要否並行取得部１０３が、優先度格納部１５０１から優先度を取得する。ここで、優先度格納部１５０１に格納されている優先度は、必ずしもユーザー入力イベントの種類と１対１対応している必要はなく、いくつかの種類を同じ種類とみなして格納する優先度を減らしてもよい。

一例として、ユーザーインターフェイス装置の状態に応じて優先度を設定している場合について説明する。ユーザーインターフェイス装置は、その時々の状態によって様々に振る舞いを変更する場合がある。例えば、車載情報機器においては、走行中の状態と停車中の状態とがあり、走行中は特定の操作又は入力ができない場合がある。ユーザーインターフェイス装置の状態に応じて、イベント配送要否並行取得部１０３に入力されうるユーザー入力イベントの種類が制限されるため、イベント配送要否並行取得部１０３におけるユーザー入力イベントの受け入れ種類を特定することができる。この例では、優先度格納部１５０１にユーザーインターフェイス装置の各状態に応じ優先度が設定されているものとして、ユーザーインターフェイス装置の各状態に応じてイベント配送要否の確認要求を送信する順番を決定する。

図１９は、優先度格納部１５０１にユーザーインターフェイス装置の状態に応じた優先度が格納されている場合の、イベント配送要否並行取得部１０３における、イベント配送要否の確認要求処理の流れを示すフローチャートである。

図１９において、図１６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ１９０１に示されるように、イベント配送要否並行取得部１０３が、ユーザーインターフェイス装置の状態を取得する。

ステップＳＴ１９０２では、イベント配送要否並行取得部１０３が、取得したユーザーインターフェイス装置の状態に応じて優先度格納部１５０１から優先度を取得する。ユーザーインターフェイス装置の状態は、車載情報機器における走行中及び停車中といった状態に限らず、その他どのような状態であってもよい。

一例として、外部機器との接続状態に応じて優先度を設定している場合について説明する。ユーザーインターフェイス装置は、スマートフォン又はタブレットなどの様々な外部機器と接続されて、外部機器のアプリケーション又は表示内容を画面レイヤーに表示する場合が存在する。外部機器との通信は、ユーザーインターフェイス装置内部での通信と比べて遅い傾向にあるため、外部機器との接続状況に応じて外部機器の情報を表示している画面レイヤーの優先度を上げる又は下げるというように優先度を変更させることで、イベント配送要否の確認要求処理を効率的に行える場合がある。

図２０は、優先度格納部１５０１に外部機器との接続状態に応じた優先度が格納されている場合の、イベント配送要否並行取得部１０３における、イベント配送要否の確認要求処理の流れを示すフローチャートである。

図２０において、図１６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ２００１に示されるように、イベント配送要否並行取得部１０３が、外部機器との接続状態を取得する。

ステップＳＴ２００２では、取得した外部機器との接続状態に応じて、イベント配送要否並行取得部１０３が、優先度格納部１５０１から優先度を取得する。この例における外部機器はスマートフォン又はタブレットなどに限らず、いかなる外部機器であってもよい。

このように、本実施形態では、各画面レイヤーに対してイベント配送要否の確認要求を実行する順番を優先順位によって決定することによって、効率的なイベント配送要否の確認要求処理を実行することが可能である。

＜第５実施形態＞
以下では、上記実施形態で説明された構成と同様の構成については同じ符号を付して図示し、その詳細な説明については適宜省略する。

第１実施形態においては、いかなる場合においても、各画面レイヤーにおいてイベント配送要否の確認処理を同時並行的に実行していたが、場合によっては従来の方法を含む別の方法を使用して、イベント配送先を決定した方が高速である場合が存在する。そのため、第１実施形態におけるイベント配送先決定方法とは別のイベント配送先決定方法を切り替えて使用してもよい。

図２１は、本実施形態に関するユーザーインターフェイス装置の構成を概念的に示す図である。

図２１に示されるユーザーインターフェイス装置の構成のうち、図１に示されたユーザーインターフェイス装置の構成と同様であるものについては同一の符号を付し、ここでの説明は省略する。

本実施形態では、ユーザーインターフェイス装置は、どのイベント配送先決定方法を使用するか判断するイベント配送先決定方法切替部２１０１と、第１実施形態に示されたイベント配送先決定方法とは異なるイベント配送先決定方法を実行する第２イベント配送先決定部２１０２とを備える。イベント配送先決定方法切替部２１０１及び第２イベント配送先決定部２１０２は、例えば、コンピューター２０１における、処理装置２０２でプログラムを実行することにより実現される。

イベント配送先決定方法切替部２１０１と、第２イベント配送先決定部２１０２とを備えることにより、イベント配送先決定方法切替部２１０１における判断結果に基づいて、第２イベント配送先決定部２１０２が、イベント配送先決定方法を切り替えることが可能である。

図２１においては、別のイベント配送先決定方法を選択するための構成として第２イベント配送先決定部２１０２のみが備えられているが、別のイベント配送先決定方法として複数のイベント配送先決定方法が想定できる場合には、別のイベント配送先決定方法を選択するための構成として第３のイベント配送先決定部、さらには第４のイベント配送先決定部が備えられていてもよい。また、別のイベント配送先決定方法を選択するための構成の数には上限はない。

図２２は、本実施形態に関する、イベント配送先決定方法切替部２１０１の処理の流れを示すフローチャートである。

まず、ステップＳＴ２２０１に示されるように、イベント配送先決定方法切替部２１０１が、どのイベント配送先決定方法を使用すべきか判断する。イベント配送先決定方法として並行取得を実行する場合（Ｙｅｓ）には、第１実施形態の方法を使用するとしてステップＳＴ２２０２へ進む。イベント配送先決定方法として並行取得を実行しない場合（Ｎｏ）には、別のイベント配送先決定方法を使用するとしてステップＳＴ２２０３へ進む。ステップＳＴ２２０３では、別のイベント配送先決定方法を採用するため、第２イベント配送先決定部２１０２の処理を開始する。

なお、イベント配送先決定方法切替部２１０１におけるイベント配送先決定方法を判断する条件については、どのような条件であってもよい。例えば、時間によって切り替わるという条件であってもよいし、ランダムにどちらかを選択するという条件であってもよい。以下、イベント配送先決定方法切替部２１０１における、イベント配送先決定方法を判断する条件に関する具体例を説明する。

一例として、画面レイヤー数によるイベント配送先決定方法の切り替えについて説明する。イベント配送要否の確認が必要な画面レイヤー数が少ない場合、同時並行的にイベント配送要否の確認処理を実行すると、イベント配送要否の確認結果の受け取り又は統合にかかる時間によって、逐次的にイベント配送要否の確認を実行する場合より時間がかかる可能性がある。そのため、イベント配送要否の確認が必要な画面レイヤー数が少ない場合は、画面レイヤー管理部１０７における処理を従来の逐次的処理など別のイベント配送先決定方法に切り替えることで、より効率的にユーザー入力イベント配送先画面レイヤーを決定できる。

図２３は、イベント配送要否の確認が必要な画面レイヤー数によってイベント配送先決定方法を切り替える場合の、イベント配送先決定方法切替部２１０１の処理の流れを示すフローチャートである。

図２３において、図２２における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ２３０１に示されるように、イベント配送先決定方法切替部２１０１が、イベント配送要否の確認が必要な画面レイヤー数がＮ以上であるか判断する。ここでＮは自然数であるとする。また、Ｎは、設計者があらかじめ設定しておくなどどのような方法で設定してもよい。イベント配送要否の確認が必要な画面レイヤー数がＮ以上であった場合（Ｙｅｓ）は、ステップＳＴ２２０２へ進む。イベント配送要否確認が必要な画面レイヤー数がＮ以上ではなかった場合（Ｎｏ）は、ステップＳＴ２２０３へ進む。なお、図２３におけるイベント配送先決定方法の切り替え条件は一例であり、イベント配送要否の確認が必要な画面レイヤー数がＮ以下であった場合に、ステップＳＴ２２０２へ進むという条件であってもよいし、ＭがＮ以上の自然数であるとして、イベント配送要否の確認が必要な画面レイヤー数がＮ以上Ｍ以下であった場合にステップＳＴ２２０２へ進むという条件であってもよい。

一例として、処理装置２０２のコア数に基づくイベント配送先決定方法の切り替えについて説明する。処理装置のコア数が少ない場合、少ないコアでイベント配送要否の確認をしなければならないため、イベント配送要否の確認結果の受け取り又は統合にかかる時間によって、逐次的にイベント配送要否の確認を実行する場合より時間がかかる可能性がある。処理装置のコア数が少ない場合は、従来の逐次的処理など別のイベント配送先決定方法に切り替えることで、より効率的にユーザー入力イベントの配送先画面レイヤーを決定できる。

図２４は、処理装置２０２のコア数に基づいてイベント配送先決定方法を切り替える場合の、イベント配送先決定方法切替部２１０１の処理の流れを示すフローチャートである。

図２４において、図２２における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ２４０１に示されるように、イベント配送先決定方法切替部２１０１が、処理装置２０２のコア数がＮ以上であるか判断する。ここでＮは自然数であるとする。Ｎは設計者があらかじめ設定しておくなどどのような方法で設定してもよい。処理装置のコア数がＮ以上であった場合（Ｙｅｓ）は、ステップＳＴ２２０２へ進む。処理装置のコア数がＮ以上ではなかった場合（Ｎｏ）は、ステップＳＴ２２０３へ進む。なお、図２４におけるイベント配送先決定方法の切り替え条件は一例であり、処理装置２０２のコア数がＮ以下であった場合にステップＳＴ２２０２へ進むという条件であってもよいし、ＭがＮ以上の自然数であるとして、処理装置２０２のコア数がＮ以上Ｍ以下であった場合にステップＳＴ２２０２へ進むという条件であってもよい。

一例として、ユーザー入力イベントの種類に基づくイベント配送先決定方法の切り替えについて説明する。ユーザー入力イベントの種類によってはイベント配送先決定方法が適さない又はより高速に決定できるイベント配送先決定方法が存在する場合がある。例えば、ユーザー入力イベントの種類がドラッグである場合、ドラッグイベントが続く限り最初にドラッグイベントが配送された画面レイヤーに対して続くユーザー入力イベントを配送し続けたい場合が存在する。又は、マルチタッチ可能な入力装置１０１において、２つの入力が通常では別の画面レイヤーに配送されてしまうが、ピンチインなどの１つのジェスチャイベントとしてどちらか片方の画面レイヤーに配送したい場合も存在する。これらの場合においては、１つ１つのユーザー入力イベントについて各画面レイヤーにイベント要否の確認処理を実行しなくても、配送先画面レイヤーを決定することが可能である。

図２５は、ユーザー入力イベントの種類がドラッグである際に、ドラッグイベントが続く限り最初にドラッグイベントを配送した画面レイヤーに対して配送し続ける場合の、イベント配送先決定方法切替部２１０１の処理の流れを示すフローチャートである。

図２５において、図２２における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

まず、ステップＳＴ２５０１に示されるように、イベント配送先決定方法切替部２１０１が、ユーザー入力イベントの種類がドラッグ以外であるか否かを判断する。ユーザー入力イベントの種類がドラッグ以外であった場合（Ｙｅｓ）は、ステップＳＴ２２０２に進む。ユーザー入力イベントの種類がドラッグであった場合（Ｎｏ）は、ステップＳＴ２２０３に進む。

図２６は、ドラッグ開始時のイベント配送要否統合部１０４の処理の流れを示すフローチャートである。

図２６において、図６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

ドラッグ開始時はプレスなどと判断されるため、まずはイベント配送要否並行取得部１０３及びイベント配送要否統合部１０４における処理が実行される。

そして、ステップＳＴ２６０１では、配送先画面レイヤーとして決定した画面レイヤーを記憶しておく。

図２７は、ユーザー入力イベントの種類がドラッグであった場合の、第２イベント配送先決定部２１０２の処理の流れを示すフローチャートである。

まず、ステップＳＴ２７０１に示されるように、第２イベント配送先決定部２１０２が、図２６のステップＳＴ２６０１において記憶した画面レイヤーを取得する。

ステップＳＴ２７０２では、ステップＳＴ２７０１において取得した画面レイヤーを配送先画面レイヤーとして決定する。

このように、本実施形態では、イベント配送先決定方法を自由に切り替えることによって、第１実施形態において説明したイベント配送先決定方法が効果的に働かない場合においても、別のイベント配送先決定方法を利用することにより高速にユーザー入力イベント配送先画面レイヤーを決定することが可能である。

＜第６実施形態＞
以下では、上記実施形態で説明された構成と同様の構成については同じ符号を付して図示し、その詳細な説明については適宜省略する。

第１実施形態においては、ユーザー入力イベントは１つの画面レイヤーにおいて処理されることを想定していたが、１つのユーザー入力イベントが複数の画面レイヤーに処理されてもよい。

図２８は、本実施形態における、イベント配送要否統合部１０４におけるイベント配送要否統合処理の流れを示すフローチャートである。

図２８において、図６における場合と同一の符号が付された処理は、同一又はこれに相当する機能を有する処理であるので説明を省略する。

ステップＳＴ２８０１では、イベント配送要否統合部１０４が、ユーザー入力イベントの配送を必要としている画面レイヤーを登録しておく。その後は、ステップＳＴ６０１に戻る。

ステップＳＴ２８０２では、イベント配送要否統合部１０４が、すべての画面レイヤーのイベント配送要否の確認結果について判断した後に、ユーザー入力イベント配送先画面レイヤーとして１つ以上の画面レイヤーが登録されているか判断する。１つ以上の画面レイヤーがユーザー入力イベント配送先画面レイヤーとして登録されている場合（Ｙｅｓ）は、処理を終了する。１つ以上の画面レイヤーがユーザー入力イベント配送先画面レイヤーとして登録されていない場合（Ｎｏ）は、ステップＳＴ６０５へ進む。イベント配送部１０６及びイベント処理部１０９では、ユーザー入力イベントの配送先画面レイヤーとして登録されているすべての画面レイヤーに対してユーザー入力イベントを配送及び処理する。

なお、この例ではユーザー入力イベントを必要とするすべての画面レイヤーをユーザー入力イベント配送先画面レイヤーとして登録しているが、ユーザー入力イベントを必要とする一部の画面レイヤーのみをユーザー入力イベント配送先画面レイヤーとして登録してもよい。その際、ユーザー入力イベント配送先画面レイヤーとして登録すべき画面レイヤーの選択についてはどのような方法を用いてもよい。

＜効果＞
以下に、上記の実施形態による効果を例示する。

上記の実施形態によれば、ユーザーインターフェイス装置が、取得部としてのユーザー入力イベント取得部１０２と、送信部としてのイベント配送要否並行取得部１０３と、判断部としての画面レイヤー管理部１０７と、決定部としてのイベント配送要否統合部１０４とを備える。

ユーザー入力イベント取得部１０２は、外部からの入力情報としてのユーザー入力イベントを取得する。イベント配送要否並行取得部１０３は、ユーザー入力イベントが各画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報としてのイベント配送要否の確認要求を送信する。

画面レイヤー管理部１０７では、イベント配送要否の確認要求に基づいて、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の画面レイヤーのうちの少なくとも２つの画面レイヤーに対して並行して判断される。

イベント配送要否統合部１０４は、画面レイヤー管理部１０７における判断結果に基づいて、ユーザー入力イベントが受け付けられる少なくとも１つの画面レイヤーを決定する。

すなわち、上記の構成によれば、ユーザー入力イベントを受け付けるべき画面レイヤーの上にユーザー入力イベントを受け付けるべきでない画面レイヤーが多数重なって表示されている場合においても、オブジェクトの位置又は形状、又は、画面レイヤーの位置又は形状の変化（アニメーション）の阻害、さらには記憶領域の大量占有を行わずに、ユーザー入力イベントを配送すべき画面レイヤーを効率的に決定することが可能となる。よって、ユーザー入力イベントの配送先画面レイヤーの決定に際しての処理時間の低減が可能となり、画面描画速度の向上、さらにはユーザーインターフェイス装置全体の性能向上につながる。

なお、これらの構成以外の構成については適宜省略することができるが、本明細書に示される任意の構成を適宜追加した場合でも、上記の効果を生じさせることができる。

また、上記の実施形態によれば、イベント配送要否統合部１０４は、画面レイヤー管理部１０７における判断結果が複数の画面レイヤーのうちの一部の画面レイヤーに関する判断結果である場合であっても、当該判断結果に基づいて、ユーザー入力イベントが受け付けられる少なくとも１つの画面レイヤーを決定する。

このような構成によれば、必要のないイベント配送要否の確認処理を低減することが可能であり、高速にユーザー入力イベントを配送すべき画面レイヤーを決定することが可能となる。

また、上記の実施形態によれば、イベント配送要否統合部１０４は、画面レイヤー管理部１０７における判断結果が、複数の画面レイヤーのうちの少なくとも１つの画面レイヤーにおいてユーザー入力イベントが受け付けられ、かつ、ユーザー入力イベントが受け付けられる当該画面レイヤーよりも上位の画面レイヤーに関する判断がすべてなされている判断結果である場合に、当該判断結果に基づいて、ユーザー入力イベントが受け付けられる少なくとも１つの画面レイヤーを決定する。

このような構成によれば、必要のないイベント配送要否の確認処理を低減することが可能であり、高速に、ユーザー入力イベントを配送すべき画面レイヤーを決定することが可能となる。

また、上記の実施形態によれば、画面レイヤー管理部１０７は、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の画面レイヤーのうちの一部の画面レイヤーに対して並行して判断する。

このような構成によれば、同時並行的に実行されるイベント配送要否の確認要求処理の数を制限することによって各々の処理を高速化し、これを逐次的に実行することができるため、特に、イベント配送要否の確認要求を送信する順番が早く回ってくる画面レイヤーがユーザー入力イベントを必要としている場合に、ユーザー入力イベント配送先画面レイヤーを高速に決定することが可能である。

また、上記の実施形態によれば、画面レイヤー管理部１０７は、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の画面レイヤーすべてに対して並行して判断する。

このような構成によれば、ユーザー入力イベントを受け付けるべき画面レイヤーの上にユーザー入力イベントを受け付けるべきでない画面レイヤーが多数重なって表示されている場合においても、オブジェクトの位置又は形状、又は、画面レイヤーの位置又は形状の変化（アニメーション）の阻害、さらには記憶領域の大量占有を行わずに、ユーザー入力イベントを配送すべき画面レイヤーを効率的に決定することが可能となる。よって、ユーザー入力イベントの配送先画面レイヤーの決定に際しての処理時間の低減が可能となり、画面描画速度の向上、さらにはユーザーインターフェイス装置全体の性能向上につながる。

また、上記の実施形態によれば、画面レイヤー管理部１０７は、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する画面レイヤーの数を、画面レイヤー管理部１０７における処理速度に応じて決定する。

このような構成によれば、処理装置２０２における処理速度を考慮した上で、処理装置２０２の処理能力を十分に活かしつつ、ユーザー入力イベントの要否の確認処理を実行することができる。

また、上記の実施形態によれば、画面レイヤー管理部１０７は、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する画面レイヤーの数を、画面レイヤー管理部１０７において用いることができるＣＰＵの数に応じて決定する。

このような構成によれば、処理装置２０２が同時並行的に処理可能な最大の画面レイヤーの数を、処理装置２０２におけるＣＰＵの数から自動的に取得することも可能となり、効率的にユーザー入力イベントの配送先画面レイヤーを決定することができる。

また、処理装置２０２の動作状態によって変動する同時並行的に処理可能な画面レイヤーの数を、処理装置２０２における当該判断のために用いることができるＣＰＵ、すなわち、何も処理を実行していない又は使用率が少ないＣＰＵの数から自動的に取得することも可能となり、効率的にユーザー入力イベントの配送先画面レイヤーを決定することができる。

また、上記の実施形態によれば、イベント配送要否並行取得部１０３は、イベント配送要否の確認要求を送信する際、各画面レイヤーについてあらかじめ定められた優先度にしたがう順序で、各画面レイヤーに対応するイベント配送要否の確認要求を送信する。

このような構成によれば、処理装置２０２の各コアに割り当てられる処理の平準化、又は、ユーザー入力イベントを受け取る可能性が高い画面レイヤーのイベント配送要否の確認処理を早めに実行することが可能となる。よって、ユーザー入力イベントの配送先画面レイヤーを高速に決定することが可能である。

また、上記の実施形態によれば、各画面レイヤーについての優先度が、ユーザー入力イベントの種類に応じて定められる。

このような構成によれば、ユーザー入力イベントの種類に依存した優先度を設定することが可能である。

また、上記の実施形態によれば、各画面レイヤーについての優先度が、ユーザー入力イベント取得部１０２におけるユーザー入力イベントの受け入れ制限に応じて定められる。

このような構成によれば、ユーザー入力イベント取得部１０２におけるユーザー入力イベントの受け入れ態勢に依存した優先度を設定することが可能である。

また、上記の実施形態によれば、各画面レイヤーについての優先度が、外部機器との接続状態に応じて定められる。

このような構成によれば、ユーザーインターフェイス装置の、外部機器との接続状態に依存した優先度を設定することが可能である。

また、上記の実施形態によれば、画面レイヤー管理部１０７は、あらかじめ定められた切り替え条件を満たした場合、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて、各画面レイヤーに対して逐次的に判断する。

このような構成によれば、あるイベント配送先の決定方法で効果が見込まれない場合においても、別のイベント配送先の決定方法に切り替えることが可能となり、常にユーザー入力イベントの配送先画面レイヤーを高速に決定することが可能である。

また、上記の実施形態によれば、切り替え条件は、画面レイヤー管理部１０７において判断する必要がある画面レイヤーの数に関する条件である。

このような構成によれば、イベント配送要否の確認が必要な画面レイヤー数に基づいて、イベント配送先の決定方法を切り替えることが可能である。

また、上記の実施形態によれば、切り替え条件は、画面レイヤー管理部１０７における判断のために用いることができるＣＰＵの数に関する条件である。

このような構成によれば、処理装置２０２におけるコア数（ＣＰＵの数）に基づいて、イベント配送先の決定方法を切り替えることが可能である。

また、上記の実施形態によれば、切り替え条件は、ユーザー入力イベントの種類に応じて定められる条件である。

このような構成によれば、取得したユーザー入力イベントの種類によってイベント配送先の決定方法を切り替えることが可能である。

また、上記の実施形態によれば、イベント配送要否統合部１０４は、画面レイヤー管理部１０７における判断結果に基づいて、ユーザー入力イベントが受け付けられる複数の画面レイヤーを決定する。

このような構成によれば、１つのユーザー入力イベントが複数の画面レイヤーにおいて処理される場合においても、ユーザー入力イベントの配送先画面レイヤーを高速に決定することが可能である。

また、上記の実施形態によれば、ユーザーインターフェイス表示方法は、外部からのユーザー入力イベントが各画面レイヤーにおいて受け付けられるか否かについて問い合わせるイベント配送要否の確認要求を送信し、イベント配送要否の確認要求に基づいて、ユーザー入力イベントが各画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の画面レイヤーのうちの少なくとも２つの画面レイヤーに対して並行して判断し、判断の結果に基づいて、ユーザー入力イベントが受け付けられる少なくとも１つの画面レイヤーを決定する方法である。

＜変形例＞
上記実施形態では、各構成要素の寸法、形状、相対的配置関係又は実施の条件などについても記載している場合があるが、これらはすべての局面において例示であって、本明細書に記載されたものに限られることはない。よって、例示されていない無数の変形例が、本技術の範囲内において想定される。例えば、任意の構成要素を変形する場合、追加する場合又は省略する場合、さらには、少なくとも１つの実施形態における少なくとも１つの構成要素を抽出し、他の実施形態の構成要素と組み合わせる場合が含まれる。

また、矛盾が生じない限り、上記実施形態において「１つ」備えられるものとして記載された構成要素は、「１つ以上」備えられていてもよい。さらに、各構成要素は概念的な単位であって、１つの構成要素が複数の構造物から成る場合及び１つの構成要素がある構造物の一部に対応する場合、さらには、複数の構成要素が１つの構造物に備えられる場合を含む。また、各構成要素には、同一の機能を発揮する限り、他の構造又は形状を有する構造物が含まれる。

また、本明細書における説明は、本技術のすべての目的のために参照され、いずれも、従来技術であると認めるものではない。

上記実施形態で記載された各構成要素による作用は、少なくとも１つの、処理回路又は電気回路において実施することができる。処理回路及び電気回路には、プログラムされた演算処理装置を含み、その場合、処理回路又は電気回路があらかじめ設定されたプログラムにしたがって動作することによって、上記実施形態で記載された各構成要素による作用が実現される。また、各構成要素による作用を実現するプログラムは、ハードディスク又はメモリなどの記憶媒体に記憶される。また、処理回路には、集積回路（ａｐｐｌｉｃａｔｉｏｎｓｐｅｃｉｆｉｃｉｎｔｅｇｒａｔｅｄｃｉｒｃｕｉｔ、すなわちＡＳＩＣ）又は上記実施形態で記載された作用を実現するように変更された従来の回路要素などを含む。

本技術は、各構成要素が複数の装置に分散して備えられる場合（すなわち、システムのような態様）であってもよい。例えば、ユーザーインターフェイス装置におけるコンピューターとディスプレイとが分散して備えられており、ディスプレイに対し、コンピューターを用いて外部から表示制御が行われる場合であってもよい。

１０１入力装置、１０２ユーザー入力イベント取得部、１０３イベント配送要否並行取得部、１０４イベント配送要否統合部、１０５イベント配送先決定部、１０６イベント配送部、１０７画面レイヤー管理部、１０８画面レイヤー内情報格納部、１０９イベント処理部、１１０描画制御部、１１１表示装置、２０１コンピューター、２０２処理装置、２０３記憶装置、２０４ディスプレイ、２０５マウス、２０６キーボード、７０１，７０２，７０３画面レイヤー、１００１並行取得数格納部、１００２取得部、１００３送信部、１００４決定部、１００７判断部、１５０１優先度格納部、２１０１イベント配送先決定方法切替部、２１０２第２イベント配送先決定部。

Claims

複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、
外部からの入力情報を取得する取得部と、
前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、
前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、
前記判断部における判断結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する決定部とを備える、
ユーザーインターフェイス装置。
複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、
外部からの入力情報を取得する取得部と、
前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、
前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、
前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、
前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、
前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部における処理速度に応じて決定する、
ユーザーインターフェイス装置。
複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、
外部からの入力情報を取得する取得部と、
前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、
前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、
前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、
前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断し、
前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて並行して判断する前記画面レイヤーの数を、前記判断部において用いるＣＰＵの数に応じて決定する、
ユーザーインターフェイス装置。
複数の画面レイヤーの少なくとも一部を重畳させて画面に表示するユーザーインターフェイス装置であり、
外部からの入力情報を取得する取得部と、
前記入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信する送信部と、
前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断する判断部と、
前記判断部における判断結果に基づいて、前記入力情報が受け付けられる少なくとも１つの前記画面レイヤーを決定する決定部とを備え、
前記判断部は、あらかじめ定められた切り替え条件を満たした場合、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、各前記画面レイヤーに対して逐次的に判断する、
ユーザーインターフェイス装置。
前記決定部は、前記判断部における前記判断結果が複数の前記画面レイヤーのうちの一部の前記画面レイヤーに関する判断結果である場合であっても、当該判断結果に基づいて、前記入力情報が受け付けられる１つの前記画面レイヤーを決定する、
請求項１から請求項４のうちのいずれか１項に記載のユーザーインターフェイス装置。
前記決定部は、前記判断部における前記判断結果が、複数の前記画面レイヤーのうちの少なくとも１つの前記画面レイヤーにおいて前記入力情報が受け付けられ、かつ、前記入力情報が受け付けられる当該画面レイヤーよりも上位の前記画面レイヤーに関する判断がすべてなされている判断結果である場合に、当該判断結果に基づいて、前記入力情報が受け付けられる１つの前記画面レイヤーを決定する、
請求項５に記載のユーザーインターフェイス装置。
前記判断部は、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの一部の前記画面レイヤーに対して並行して判断する、
請求項１、請求項５、および、請求項６のうちのいずれか１項に記載のユーザーインターフェイス装置。
前記送信部は、前記問い合わせ情報を送信する際、各前記画面レイヤーについてあらかじめ定められた優先度にしたがう順序で、各前記画面レイヤーに対応する前記問い合わせ情報を送信する、
請求項１、請求項５、および、請求項６のうちのいずれか１項に記載のユーザーインターフェイス装置。
前記切り替え条件は、前記判断部において判断する必要がある前記画面レイヤーの数に関する条件である、
請求項４に記載のユーザーインターフェイス装置。
前記切り替え条件は、前記判断部における判断のために用いるＣＰＵの数に関する条件である、
請求項４に記載のユーザーインターフェイス装置。
前記切り替え条件は、前記入力情報の種類に応じて定められる条件である、
請求項４に記載のユーザーインターフェイス装置。
複数の画面レイヤーの少なくとも一部を重畳させて画面に表示させるユーザーインターフェイス表示方法であり、
外部からの入力情報が各前記画面レイヤーにおいて受け付けられるか否かについて問い合わせる問い合わせ情報を送信し、
前記問い合わせ情報に基づいて、前記入力情報が各前記画面レイヤーにおいて受け付けられる情報であるか否かについて、複数の前記画面レイヤーのうちの少なくとも２つの前記画面レイヤーに対して並行して判断し、
前記判断の結果に基づいて、複数の前記画面レイヤーのうちの最も上位の前記画面レイヤーから順に前記入力情報が受け付けられる前記画面レイヤーであるか否かを確認し、かつ、前記入力情報が受け付けられる前記画面レイヤーであると確認した時点で、当該画面レイヤーを前記入力情報が受け付けられる１つの前記画面レイヤーとして決定する、
ユーザーインターフェイス表示方法。