JP6436752B2 - 情報処理装置、情報処理装置における情報処理方法、並びにプログラム - Google Patents

Description

マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置、情報処理装置における情報処理方法、並びにプログラムに関する。

近年、ユーザによる直感的な操作を可能にするために、マルチタッチ操作を検出可能なタッチパネルを備えた情報処理装置が一般的になりつつある。このタッチパネル上で行うマルチタッチ操作としては、ピンチインやピンチアウトなどがある。

マルチタッチ操作を検出可能なタッチパネルとしては、静電タッチパネルが広く知られている。従来の抵抗膜（感圧）方式のタッチパネルではユーザが同時に何点タッチしても１点（シングルタッチ）しか検出できなかったのに対し、静電タッチパネルでは、ユーザが同時にタッチした複数の点を検出することができる。

一方、マルチタッチ操作を実現するためには、マルチタッチ操作を検出可能なタッチパネル（以下、新規タッチパネル）を採用するだけではなく、情報処理装置上で動作するアプリケーション（以下、アプリ）もマルチタッチイベントに対応した実装にする必要がある。つまり、シングルタッチのみ検出可能なタッチパネル（以下、従来タッチパネル）用に開発されたアプリ（以下、従来アプリ）を、新規タッチパネルを備える情報処理装置にインストールしても、アプリの実装を変更しない限りマルチタッチ操作に対応できない。新規タッチパネルにて検出したマルチタッチイベントをマルチタッチ非対応の従来アプリに送信したとしても、従来アプリが当該イベントを認識できないためである。また、マルチタッチ非対応の従来アプリへのマルチタッチイベントの送信は、無駄なイベントの送信となるため、情報処理装置全体のパフォーマンスに影響しうる。

特許文献１には、マルチタッチイベントを送信するか否かのフラグを持ち、このフラグがオフの場合は、タッチパネルでマルチタッチイベントを検出しても、当該イベントをアプリに送信しないことが開示されている。

特開２０１４−６３５１５号公報

上記特許文献１では、マルチタッチを検出可能な新規タッチパネル上でユーザがマルチタッチ操作を行ったとしても、マルチタッチに対応していない従来アプリにはイベントが送信されない。よって、従来アプリが認識できないイベントが送信されることによる情報処理装置のパフォーマンス低下を防ぐことはできる。その一方で、従来アプリを新規タッチパネル上で動作させることにより以下のような問題が生じる可能性がある。

具体例について説明する。通常、タッチパネル上に表示された仮想的なボタン（以下、ボタン）を選択する操作を行う場合、ユーザは１本指で当該ボタンをタッチする。タッチパネルではこれをシングルタッチイベントとして検出し、従来アプリに通知する。従来アプリでは当該シングルタッチイベントに基づいて所定の動作を行う。

一方、年配者などの中には、１本指でタッチせずに、２本指でボタンをタッチする人も存在する。例えば、人差し指と中指をくっつけて２本指でボタンをタッチする場合等である。上述したとおり抵抗膜方式のタッチパネルでは、ユーザが同時に複数の指でタッチした場合であっても、１点のみがシングルタッチイベントとして検出される。抵抗膜方式のタッチパネルでは、その２点の中点を座標とするシングルタッチイベントが検出される。その結果、当該シングルタッチイベントが従来アプリに通知され、従来アプリは当該シングルタッチイベントに基づいて所定の動作を行うことができる。

これに対し、新規タッチパネル上で同じ操作（二本指でボタンを選択する操作）が行われた場合、新規タッチパネルではマルチタッチイベントとして検出し、シングルタッチイベントとしては検出しない。よって、従来アプリは当該ユーザ操作に基づく動作を行わないことになる。

つまり、新規タッチパネルを備える情報処理装置に従来アプリをインストールすると、ユーザが従来と同じ操作を行っても従来アプリが動作しないという状況が発生する。これは、従来タッチパネルを備える情報処理装置から新規タッチパネルを備える情報処理装置に買い替えた場合等に起こりうる。スキャナ機能、プリント機能等を有する画像形成装置においては、どのようなハードウェアでもアプリを変更することなく動作可能にすることが重要視されているため、これは大きな問題となりうる。

本発明は、マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置上で、マルチタッチ非対応のアプリケーションを動作させた場合であっても、従来の操作性を維持できるようにすることを目的とする。

上記課題を解決するため、本発明は、マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置であって、
前記タッチパネルへのユーザによる操作に基づくタッチイベントを検出する検出手段と、
前記検出手段により検出されたマルチタッチイベントに基づいてシングルタッチイベントを生成する生成手段と、
マルチタッチイベントに対応していないアプリケーションに対して、前記生成手段により生成されたシングルタッチイベントを送信する送信手段と、
を有し、前記送信手段は、マルチタッチイベントに対応しているアプリケーションに対して、前記検出手段により検出されたマルチタッチイベントと、前記生成手段により生成されたシングルタッチイベントと、を送信することを特徴とする。

本発明によれば、マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置上で、マルチタッチ非対応のアプリケーションを動作させた場合であっても、従来の操作性を維持することができる。

本発明の各実施形態に係る画像形成装置１００のコントローラユニット１２０の構成を示すブロック図である。 本発明の各実施形態に係る画像形成装置１００の操作部１０６およびその付近の構成を示すブロック図である。 本発明の各実施形態に係るソフトウェアのモジュール構成を表す図である。 画像形成装置１００の操作部１０６でユーザがシングルタッチ操作を行ったときに発生するシングルタッチイベントの一例である。 画像形成装置１００の操作部１０６でユーザがマルチタッチ操作を行ったときに発生するマルチタッチイベントの一具体例である。 本発明の第１の実施形態におけるソフトウエアモジュールの処理を示すフローチャート図である。 画像形成装置１００の操作部１０６に表示される一画面例である。 画像形成装置１００の操作部１０６に表示される一画面例である。 本発明の各実施形態に係るＨＤＤ１０４に記憶されたマルチタッチ管理テーブルを表すイメージ図である。 画像形成装置１００の操作部１０６に表示される一画面例である。 本発明の第２の実施形態におけるソフトウエアモジュールの処理を示すフローチャート図である。 本発明の第３の実施形態におけるソフトウエアモジュールの処理を示フローチャート図である。

以下、本発明を実施するための形態について、図面を用いて説明する。

（第１の実施形態）
図１は、本発明の各実施形態に係る画像形成装置１００のコントローラユニットの構成を示すブロック図である。

コントローラユニット１２０は、各種制御プログラムを実行するＣＰＵ１０１を有する。

ＣＰＵ１０１は、ＲＯＭ１０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上でＨＤＤ（ハードディスク装置）１０４に格納されている制御プログラムを読み出してＲＡＭ１０２をワークエリアとして所定の処理を実行する。この制御プログラムにより、Ｊａｖａ（登録商標）プログラムなどの所定の制御を実行することが可能である。ＨＤＤ１０４には、上記各種制御プログラムが格納されるとともに、画像データや後述するネットワーク部１０７が有するすべての通信手段に関する情報を格納する。

ＣＰＵ１０１には、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４がシステムバス１１１を介して接続されている。さらに操作部Ｉ／Ｆ１０５、ネットワーク部１０７、イメージバスＩ／Ｆ１０９、電源管理部１１０がシステムバス１１１を介して接続されている。

操作部Ｉ／Ｆ１０５は、操作部１０６との間のインターフェイス部であり、操作部１０６に表示する画像データをＲＡＭ１０２から取得して転送する処理や、操作部１０６で発生した信号をＣＰＵ１０１へ転送する処理などを行う。

操作部１０６は、ユーザが操作可能な画像などの対象物を表示するための表示処理と、ユーザの操作に基づく信号（入力信号）を検知する入力処理を行う。

電源管理部１１０は、画像形成装置１００の電源ＯＦＦと電源ＯＮの管理を行う。なお電源ＯＮを検知した場合、上述のように、ＣＰＵ１０１は、ＲＯＭ１０３のブートプログラムに基づきシステムを起動し、このシステム上でＨＤＤ１０４に格納されている制御プログラムを実行する。

ネットワーク部１０７は、ＬＡＮ１０８に接続され、ＬＡＮ１０８を介した情報の入出力を行う。ＬＡＮ回線にＷＥＢサーバや外部装置４００が接続されている場合は、そのサーバからＬＡＮ１０８を介して情報を取得することが可能である。また、ＬＡＮ回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のＷＥＢサーバからＷＥＢコンテンツを取得することも可能である。

イメージバスＩ／Ｆ１０９は、システムバス１１１と、画像バス１１２とを接続し、データ構造を変換するバスブリッジである。画像バス１１２は、画像データを高速で転送可能なＰＣＩバスまたはＩＥＥＥ１３９４規定に従うバスから構成される。画像バス１１２には、ＲＩＰ（ラスタイメージプロセッサ）１１３、デバイスＩ／Ｆ１１４および画像処理部１１９が接続されている。

ＲＩＰ１１３は、ＰＤＬコードをビットマップイメージに展開する。

デバイスＩ／Ｆ１１４は、画像入出力デバイスであるスキャナ１１６やプリンタ１１８とコントローラユニット１２０とを接続し、画像データの同期系／非同期系の変換を行う。ここでは、デバイスＩ／Ｆ１１４とスキャナ１１６とがケーブル１１５を介して接続され、デバイスＩ／Ｆ１１４とプリンタ１１８とがケーブル１１７を介して接続されている。

画像処理部１１９は、多値画像データに対してＪＰＥＧ、二値画像データに対して、ＪＰＥＧ、ＭＭＲ、ＭＨなどの圧縮伸張処理を行う。また、入力画像データや出力画面に対して、プリンタの補正や解像度変換などの補正、加工、編集を行う。

このように、コントローラユニット１２０のＣＰＵ１０１は、各制御プログラムに基づき、システムバス１１１に接続される各種デバイスとのアクセスを総括的に制御するととともに、デバイスＩ／Ｆ１１４を介してスキャナ１１６から画像情報を読み込む。また、読み込んだ画像情報に対して所定の処理を施した後に該画像情報をデバイスＩ／Ｆ１１４を介してプリンタ１１８に出力するなどの制御を行う。さらに、ネットワーク部１０７を通じて取得した文字データや画像データの解析・変換処理を行い、ＨＤＤ１０４へ保存あるいは操作部１０６での表示制御を行う。

図２は、図１の操作部１０６およびその付近の構成を示すブロック図である。

操作部１０６のタッチパネル２０３および各ハードキーのキー群２０２は、操作部Ｉ／Ｆ１０５の入力ポート２０１を介してＣＰＵ１０１に接続される。また、このタッチパネル２０３の押下位置を示す位置情報（座標）、およびキー群２０２の押下に対応するキー情報は、入力ポート２０１を介してＣＰＵ１０１に入力される。

操作部１０６のＬＥＤ２０５およびＬＣＤ２０６は、操作部Ｉ／Ｆ１０５の出力ポート２０４を介してＣＰＵ１０１に接続され、ＬＥＤ２０５の点灯およびＬＣＤ２０６の表示はＣＰＵ１０１により制御される。このタッチパネル２０３には微量な電気が流れており、ユーザがタッチすることで発生する電気量の変化からタッチ位置を検出する静電方式が用いられており、マルチタッチ操作を検出可能である。タッチパネル２０３は、ＬＣＤ２０６の上に重なるように配置されている。ユーザがＬＣＤ２０６上に表示された仮想的なボタン（以下、ボタン）などの操作対象物を触れることで、タッチパネル２０３がその位置情報（座標）を検知する。ＣＰＵ１０１は、位置情報を検知すると、現在ＬＣＤ２０６上に表示している対象物とその座標に基づいて、ユーザが選択した操作対象が何であるかを検知する。そしてＣＰＵ１０１は、ＲＯＭ１０３もしくはＨＤＤ１０４にあらかじめ記憶されている命令の中から、検知した操作対象物が選択されときに実行すべき命令を検出し、この命令を実行する。これにより、ＬＣＤ２０６に表示する画面データが生成される。ＣＰＵ１０１は出力ポート２０４を経由してこの画面データをＬＣＤ２０６に送信することで、操作部１０６の表示を変更できる。なお、このようなＬＣＤ２０６でのユーザ操作時の内部処理は、これ以降の全ての説明で共通であり、以降では記載を省略する。

次に、画像形成装置１００のＣＰＵ１０１やＨＤＤ１０４などの各ハードウェア上で動作するソフトウェアのモジュール構成について、図３を用いて説明する。なお、これらの各モジュールにおける処理は、ＣＰＵ１０１の命令により、ＲＯＭ１０３やＨＤＤ１０４に格納されているプログラムを読み出し、ＲＡＭ１０２をワークエリアとして所定の処理を実行することで実現している。また、所定の処理を実行することで生成される全ての情報は、ＲＡＭ１０２もしくはＨＤＤ１０４に格納される。このような各モジュールにおける処理は、特に明記しない限り同様であるため、以降ではこのようなハードウェアの記載は省略する。

ドライバ部３０１は、タッチパネル２０３へのユーザによるタッチ操作に基づいて発生するタッチイベント（プレスやリリース、ムーブ等）の検知を行うモジュールである。ここで、プレスとは、タッチパネル２０３へ指がタッチされた際に発生するイベントである。リリースとは、タッチパネル２０３へ接触していた指が離された際に発生するイベントである。ムーブとは、タッチパネル２０３へ指がタッチされたまま移動している際に発生するイベントである。

ドライバ部３０１は、検知したタッチイベントをイベント管理部３０２へ送信する。このときに送信されるタッチイベントには、タッチ数、イベント種別、タッチ座標が含まれる。例えば、ユーザがタッチパネル２０３の座標（２００、２００）の地点を指一本でタッチし、座標（２００、３００）の地点まで指を移動した後に、タッチパネル２０３から指を離したとする（指を下に座標１００の距離分移動したとする）。このときにドライバ部３０１により検出され、イベント管理部３０２へ送信されるイベントを、図４に示す。図４では、ユーザが指をタッチパネル２０３にタッチしてから離すまでに、イベントＩＤ１からイベントＩＤ５までの５つのイベントが発生したことを示している。ドライバ部３０１は、これらのイベントを順次、イベント管理部３０２へ送信する。

また別の例として、ユーザがタッチパネル２０３の座標（２００、２００）と座標（２１０、２００）の地点を異なる指でタッチし、それぞれの指を座標（２００、３００）と座標（２１０、３００）の地点まで移動した後にタッチパネル２０３を離したとする。このときにドライバ部３０１により検出され、イベント管理部３０２へ送信されるイベントを図５に示す。なお、図４と図５のイベントＩＤは、イベントを一意に識別するためのものであり、実際には送信されないものとする。また、イベント種別がシングルプレス、シングルムーブ、シングルリリースであるイベントを総称してシングルタッチイベントと呼ぶこととする。また、イベント種別がマルチプレス、マルチムーブ、マルチリリースのイベントを総称してマルチタッチイベントと呼ぶこととする。

イベント管理部３０２は、ドライバ部３０１もしくは後述のイベント生成部３０３から送信されるイベントを受信し、イベント種別に応じて異なる処理を行うモジュールである。イベント管理部３０２は、ドライバ部３０１もしくイベント生成部３０３から受信したイベントのイベント種別がシングルタッチイベントの場合、受信したシングルタッチイベントをシングルイベント通知部３０４に送信する。一方、イベント管理部３０２は、受信したイベントのイベント種別がマルチタッチイベントの場合、受信したマルチタッチイベントをマルチイベント通知部３０５に送信する。さらにイベント管理部３０２は、ドライバ部３０１から送信されたイベントの種別がマルチタッチイベントの場合、当該イベントをイベント生成部３０３へ送信する。

イベント生成部３０３は、イベント管理部３０２から送信されたイベントを受信し、受信したイベント種別とは異なるイベント種別のダミーイベントを生成するモジュールである。例えば、図５のイベントＩＤ１のマルチタッチイベントを受信した場合、イベント生成部３０３は１点目の座標のみからなるシングルタッチイベントを生成する。具体的には、図４のイベントＩＤ１と同じイベント（タッチ数：１、イベント種別：シングルプレス、座標：（２００、２００））が生成される。なお、以降では、ドライバ部３０１からイベント管理部３０２へ送信されたイベントをオリジナルイベントと呼び、イベント生成部３０３が生成したイベントをダミーイベントと呼ぶこととする。そしてイベント生成部３０３は、生成したダミーイベントをイベント管理部３０２に送信する。なお、ダミーイベントを受信したイベント管理部３０２は、当該ダミーイベントをシングルイベント通知部３０４に送信する。

シングルイベント通知部３０４は、シングルタッチイベントのみを扱うことができるモジュールであり、イベント管理部３０２からのシングルタッチイベントを受信し、この受信したシングルタッチイベントをイベント配信部３０６に送信するモジュールである。

マルチイベント通知部３０５は、マルチタッチイベントのみを扱うことができるモジュールであり、イベント管理部３０２からのマルチタッチイベントを受信し、この受信したマルチタッチイベントをイベント配信部３０６に送信するモジュールである。なお、本発明の各実施形態では、シングルイベント通知部３０４とマルチイベント通知部３０５で別々のモジュールがイベント配信部３０６にイベントを送信する構成になっている。これは、従来はシングルイベント通知部３０４しか存在していなかったモジュール構成において、シングルイベント通知部３０４を変更せずに新たにマルチイベント通知部３０５が追加されたためである。

イベント配信部３０６は、シングルイベント通知部３０４もしくはマルチイベント通知部３０５から送信されるイベントを受信する。そしてイベント配信部３０６は、受信したイベントのイベント種別とＬＣＤ２０６に表示されているアプリケーション（以下、アプリ）に応じて、受信したイベントをアプリに送信するモジュールである。なお本実施形態において、ＬＣＤ２０６には１つのアプリのみ表示されることとする。すなわち、複数のアプリが起動していたとしても、ユーザによる操作対象のアプリは１つのみであり、イベント配信部３０６は当該アプリに対してイベントを送信するものとする。イベント配信部３０６は、受信したイベントのイベント種別がシングルタッチイベントの場合、受信したイベントをＬＣＤ２０６に表示されているアプリ（従来アプリ３０７もしくは新規アプリ３０８）に送信する。一方、イベント配信部３０６は、受信したイベントのイベント種別がマルチタッチイベントの場合、ＬＣＤ２０６に表示されているアプリを確認する。そしてイベント配信部３０６は、ＬＣＤ２０６に表示されているアプリが従来アプリ３０７の場合は、受信したマルチタッチイベントを送信しない。一方、ＬＣＤ２０６に表示されているアプリが新規アプリ３０８の場合は、イベント配信部３０６は受信したマルチタッチイベントを新規アプリ３０８に送信する。

従来アプリ３０７は、シングルタッチイベントのみを扱うことができるアプリであり、イベント配信部３０６からのイベントを受信し、このイベントに応じた処理を行う。

新規アプリ３０８は、シングルタッチイベントとマルチタッチイベントの両方のイベントを扱うことができるアプリであり、イベント配信部３０６からのイベントを受信し、イベントに応じた処理を行う。

続いて、各ソフトウエアモジュールの処理について、図６のフローチャートを用いて説明する。

ユーザがタッチパネル２０３に対するタッチ操作を行うと、ドライバ部３０１は、タッチイベントとして、タッチ数、イベント種別、タッチ座標を検出する（Ｓ６０１）。このタッチイベントの検出方法は、一般的な静電方式のタッチパネルでの検出方法と同じであるため、詳細は省略する。そしてドライバ部３０１は、検出したタッチイベントをイベント管理部３０２へ送信する。このイベントを受信したイベント管理部３０２は、タッチイベントに含まれるタッチ数が１であるか否かにより、受信したイベントがシングルタッチイベントであるか否かを判定する（Ｓ６０２）。

まず、イベント管理部３０２が受信したイベントがシングルタッチイベントの場合の処理を説明する。イベント管理部３０２は、受信したイベントがシングルタッチイベントであると判定すると（Ｓ６０２でＹｅｓ）、受信したイベントをシングルイベント通知部３０４へ送信する。シングルイベント通知部３０４は、イベント管理部３０２から受信したイベントをイベント配信部３０６へ送信する。そして、イベント配信部３０６は、ＬＣＤ２０６で表示しているアプリにこのイベントを送信する（Ｓ６０３）。これにより、イベントを受信したアプリは、受信したイベントに対応する所定の動作を行う。以上の通り、イベント管理部３０２が受信したイベントがシングルタッチイベントの場合、現在操作対象となっているアプリが従来アプリ３０７、新規アプリ３０８のいずれであってもシングルタッチイベントが送信される。

続いて、イベント管理部３０２が受信したイベントがマルチタッチイベントの場合の処理を説明する。イベント管理部３０２は、受信したイベントがマルチタッチイベントであると判定すると（Ｓ６０２でＮｏ）、受信したイベントをイベント生成部３０３へ送信する。イベント生成部３０３は、受信したイベントを基に、１点からなるシングルタッチイベントを生成する（Ｓ６０４）。この生成したシングルタッチイベントはダミーイベントである。そしてイベント生成部３０３は、生成したダミーイベントをイベント管理部３０２へ送信する。

イベント管理部３０２は、イベント生成部３０３から送信されたダミーイベントをシングルイベント通知部３０４へ送信し、ドライバ部３０１から送信されたマルチタッチイベント（オリジナルイベント）をマルチイベント通知部３０５へ送信する。

イベント管理部３０２からダミーイベントを受信したシングルイベント通知部３０４は、受信したイベントをイベント配信部３０６へ通知する。イベント管理部３０２からオリジナルイベントを受信したマルチイベント通知部３０５は、受信したイベントをイベント配信部３０６へ通知する。

シングルイベント通知部３０４もしくはマルチイベント通知部３０５からのイベントを受信したイベント配信部３０６は、ＬＣＤ２０６に表示されているアプリがマルチタッチ操作に対応している新規アプリ３０８か否かを判定する（Ｓ６０５）。

ここで、ＬＣＤ２０６に表示されているアプリがマルチタッチ対応のアプリか否かをイベント配信部３０６が判定する方法について説明する。イベント配信部３０６は、アプリ毎にマルチタッチ可能か否かの情報をマルチタッチ管理テーブル（図９、詳細は後述する）で管理している。なお、このマルチタッチ可能か否かの情報は、各アプリがイベント配信部３０６にマルチタッチ要求を行うことで変更できることとする。変更の具体例としては、各アプリがユーザによる操作を受け付ける前の初期化処理として、マルチタッチ要求をイベント配信部３０６に行うことで変更できる。イベント配信部３０６は、ＬＣＤ２０６に表示されているアプリを特定し、マルチタッチ管理テーブルで管理している情報を用いることで、この特定したアプリがマルチタッチ対応のアプリか否かを判定することができる。

イベント配信部３０６は、マルチタッチ対応の新規アプリ３０８がＬＣＤ２０６に表示されていると判定した場合、受信したダミーイベントとオリジナルイベントを新規アプリ３０８へ送信する（Ｓ６０６）。一方、マルチタッチに対応していない従来アプリ３０７が表示されていると判定した場合、イベント配信部３０６は、受信したダミーイベントのみを従来アプリ３０７へ送信する（Ｓ６０７）。

以上の通り、イベント管理部３０２が受信したイベントがマルチタッチイベントの場合、現在操作対象となっているアプリが従来アプリ３０７であれば、マルチタッチイベントに基づいて生成されたシングルタッチイベント（ダミーイベント）が送信される。これにより、従来アプリ３０７は、受信したシングルタッチイベントに基づいて動作を行うことが可能となるため、従来アプリ３０７に変更を加えずとも従来と同様の操作性を維持することができる。よって、アプリの互換性（どのようなタッチパネルでも、アプリの変更なしに動作する互換性）を保つことができる。

続いて、図６の処理の詳細について、具体例を用いて説明する。

図７は、画像形成装置１００の操作部１０６（ＬＣＤ２０６）の一表示例であり、画像形成装置１００の電源をＯＮにすることで最初に表示される画面である。なお以降の説明では、画像形成装置１００の電源をＯＮしてから、操作部１０６に最初に表示される画面を、初期画面と呼ぶこととする。この初期画面は、画像形成装置１００で実行可能なアプリの中からユーザが所望のアプリを選択するためのメニュー画面である。

図７の初期画面には、コピーアプリにアクセスするためのコピーボタン７０１、センドアプリにアクセスするためのセンドボタン７０２、ボックスアプリにアクセスするためのボックスボタン７０３が表示されている。なお、これらとは別のアプリも画像形成装置１００に追加でインストールすることが可能であり、インストールすると初期画面にこのアプリを呼び出して実行するためのボタンが表示される。初期画面に表示されているボタンをタッチ（押下）すると、各ボタンに対応づけられているアプリの処理が実行される。なお本実施形態では、初期画面にはコピーボタン７０１、センドボタン７０２、ボックスボタン７０３のみが表示されているものとする。また、コピーボタン７０１に対応づけられているコピーアプリ、及びセンドボタン７０２に対応づけられているセンドアプリは、シングルタッチイベントのみ処理可能な従来アプリ３０７であるものとする。また、ボックスボタン７０３に対応づけられているボックスアプリは、シングルタッチイベントとマルチタッチイベントの両方が処理可能な新規アプリであるものとする。

このような初期画面において、最初にボックスアプリ（新規アプリ３０８）でシングルタッチとマルチタッチを行った場合の具体例を説明し、続いて、コピーアプリ（従来アプリ３０７）でシングルタッチとマルチタッチを行った場合の具体例も説明する。

初期画面において、ユーザがボックスボタン７０３をタッチ（押下）すると、このボタンに対応するボックスアプリが呼び出され、ボックスアプリの初期化処理が行われる。そして、初期化処理の完了後にボックスアプリの画面（図８）が表示される。まずこの初期化処理の具体例を説明し、その後に図８の画面の説明を行う。

ボックスアプリはマルチタッチイベントに対応可能な新規アプリ３０８であり、初期化処理において、ボックスアプリはマルチタッチ要求をイベント配信部３０６に送信する。イベント配信部３０６は、マルチタッチ要求を受信すると、ボックスアプリはマルチタッチ対応のアプリであると記憶する。具体的には、イベント配信部３０６は、初期画面に表示されている各アプリとマルチタッチ要求有無を紐付けて管理するために、図９のようなマルチタッチ管理テーブルをアプリからのマルチタッチ要求に応じて更新する。

ここで図９のマルチタッチ管理テーブルの説明を行う。このテーブル内のマルチタッチフラグは、アプリがマルチタッチに対応しているか否かを示すフラグであり、アプリからマルチタッチ要求を受信すると値が１に更新される。つまり、マルチタッチフラグが１のアプリは、マルチタッチ対応の新規アプリ３０８であることを示す。なお、アプリからイベント配信部３０６にマルチタッチ解除要求を行うことで、マルチタッチフラグを０に変更することも可能である。マルチタッチフラグのデフォルトは０であり、イベント配信部３０６にマルチタッチ要求を行っていないアプリは、マルチタッチフラグは０になっている。図９では、ボックスアプリの初期化処理においてマルチタッチ要求がイベント配信部３０６に送信されたため、ボックスアプリのマルチタッチフラグのみ１になっている。

初期化処理が完了すると、ボックスアプリは操作部１０６に図８で示す画面を表示する。図８には、ボックスに関する設定やボックスに保存されている画像を確認するための画像ボタンが表示されている。ここで図８の説明を行う。タイトル領域８０１は、アプリのタイトル名を表示する領域である。画像ボタン８０２〜画像ボタン８０４は、ボックスに保存されているそれぞれの画像を選択するためのボタンであり、このボタンをタッチすると選択したボタンに対応する画像のプレビュー画面がプレビュー表示領域８０５に表示される。なお、選択された画像ボタンは色が変わり、選択中であることが識別可能になっている。図８では画像ボタン８０２が選択された状態であり、画像Ａがプレビュー表示領域８０５に表示されている。

図８のボックス画面において、ユーザが画像ボタン８０３を一本の指でタッチ（シングルタッチ）した場合の処理について説明する。ユーザがシングルタッチを行うと、ドライバ部３０１は、タッチ数：１、イベント種別：シングルプレス、タッチ座標：（３００、１００）のタッチイベントを検出する（Ｓ６０１）。そしてドライバ部３０１は、このタッチイベントをイベント管理部３０２へ送信する。イベント管理部３０２は、受信したタッチイベントのタッチ数が１であるため、シングルタッチイベントであると判定し（Ｓ６０２でＹｅｓ）、受信したタッチイベントをシングルイベント通知部３０４へ送信する。そしてシングルイベント通知部３０４は、イベント管理部３０２から受信したイベントをイベント配信部３０６へ送信する。イベント配信部３０６は、操作部１０６に表示されているボックスアプリにこのイベントを送信する（Ｓ６０３）。これにより、ボックスアプリは受信したタッチイベントに対応する動作、すなわち、画像ボタン８０３に対応する画像Ｂのプレビュー画像をプレビュー表示領域８０５に表示する動作を行う。

続いて、図８のボックス画面において、ユーザがプレビュー表示領域８０５に表示されている画像を拡大するために二本の指でピンチアウト操作を行った場合の処理について説明する。なお、ピンチアウトとは、タッチパネル上に表示した対象物を二本の指で広げるようにする操作であり、この操作により対象物の拡大を直感的に実行することができる。

ユーザがマルチタッチを行うと、ドライバ部３０１は、タッチ数：２、イベント種別：マルチプレス、タッチ座標：（１００、３００）、（２００、１００）のタッチイベントを検出する（Ｓ６０１）。そしてドライバ部３０１は、このタッチイベントをイベント管理部３０２へ送信する。イベント管理部３０２は、受信したタッチイベントのタッチ数が２であるため、マルチタッチイベントであると判定する（Ｓ６０２でＮｏ）。

そして、イベント管理部３０２は、受信したイベントをイベント生成部３０３に送信し、イベント生成部３０３はシングルタッチイベントであるダミーイベントを生成する（Ｓ６０４）。この場合、タッチ数：１、イベント種別：シングルプレス、タッチ座標：（１００、３００）のダミーイベントが生成される。そしてイベント管理部３０２は、イベント生成部３０３からダミーイベントを受信し、ダミーイベントをシングルイベント通知部３０４に送信すると共に、イベント管理部３０２から受信したオリジナルイベントをマルチイベント通知部３０５に送信する。

シングルイベント通知部３０４とマルチイベント通知部３０５は、それぞれ受信したイベントをイベント配信部３０６へ送信する。これらのイベントを受信したイベント配信部３０６は、操作部１０６に表示されているアプリがマルチタッチ対応のアプリか否かを判定する（Ｓ６０５）。この判定には、図９のマルチタッチ管理テーブルが用いられる。ここでは、操作部１０６ではボックスアプリが動作しており、マルチタッチ管理テーブルにおけるボックスアプリのマルチタッチフラグが１になっているため、マルチタッチ対応の新規アプリ３０８が表示されていると判断される。そのため、イベント配信部３０６は、受信したダミーイベントとオリジナルイベントをボックスアプリへ送信する（Ｓ６０６）。ボックスアプリは、オリジナルイベントとダミーイベントの両方を受信した場合、ダミーイベントは利用せずにオリジナルイベントに対応する動作を行うものとする。すなわち、オリジナルイベントを解釈し、プレビュー領域の画像の拡大を行う。

以上が、マルチタッチ対応の新規アプリでユーザがシングルタッチとマルチタッチを行ったときの具体例である。

次に、コピーアプリ（従来アプリ３０７）が操作部１０６に表示された状態で、シングルタッチとマルチタッチを行った場合の具体例を説明する。

初期画面において、ユーザがコピーボタン７０１をタッチすると、このボタンに対応するコピーアプリが呼び出され、コピーアプリの初期化処理が行われる。そして、初期化処理の完了後に図１０のコピー画面が表示される。上述した通り、初期化処理において、マルチタッチ対応のアプリはマルチタッチ要求をイベント配信部３０６に送信する。しかしながら、コピーアプリはマルチタッチに対応していない従来アプリ３０７であるため、初期化処理においてマルチタッチ要求をイベント配信部３０６に送信しない。このため、図９のマルチタッチ管理テーブルにおけるコピーアプリのマルチタッチフラグは０のままとなる。

図１０の説明を行う。図１０には、コピーに関する設定を行うためのボタン、現在の設定内容を表示する領域等が表示されている。タイトル領域１００１は、アプリのタイトル名を表示する領域であり、メッセージ領域１００２はユーザに対するメッセージを表示する領域である。設定確認領域１００３は現在設定されている印刷倍率と用紙サイズを表す領域であり、部数領域１００４は現在設定されているコピー部数を表す領域である。倍率設定ボタン１００５は印刷倍率を設定するためのボタンであり、タッチすると印刷倍率を設定する画面が操作部１０６に表示される。用紙選択ボタン１００６はコピーする用紙サイズを設定するためのボタンであり、タッチすると用紙サイズを選択するための画面が操作部１０６に表示される。応用モードボタン１００７は倍率や用紙サイズ以外のコピー設定を行うためのボタンであり、タッチすると各種設定を行うための画面が操作部１０６に表示される。

図１０のコピー画面において、ユーザが用紙選択ボタン１００６を一本の指でタッチした場合の処理について説明する。ユーザがシングルタッチを行うと、ドライバ部３０１は、タッチ数：１、イベント種別：シングルプレス、タッチ座標：（２００、２００）のタッチイベントを検出する（Ｓ６０１）。そしてドライバ部３０１は、検出したタッチイベントをイベント管理部３０２へ送信する。イベント管理部３０２は、受信したタッチイベントのタッチ数が１であるため、シングルタッチイベントであると判定する（Ｓ６０２でＹｅｓ）。そのため、イベント管理部３０２は当該タッチイベントをシングルイベント通知部３０４へ送信し、シングルイベント通知部３０４はこのイベントをイベント配信部３０６へ送信する。イベント配信部３０６は、操作部１０６に表示されているコピーアプリにこのイベントを送信する（Ｓ６０３）。これにより、コピーアプリは受信したタッチイベントに対応する動作、すなわち、用紙選択ボタン１００６に対応づけられている用紙選択を行う画面の表示を行う。

次に、コピー画面において、ユーザが用紙選択ボタン１００６を二本の指でタッチした場合の処理について説明する。ユーザがマルチタッチを行うと、ドライバ部３０１は、タッチ数：２、イベント種別：マルチプレス、タッチ座標：（２００、２００）、（２１０、２００）のタッチイベントを検出する（Ｓ６０１）。そしてドライバ部３０１は、このタッチイベントをイベント管理部３０２へ送信する。イベント管理部３０２は、受信したタッチイベントのタッチ数が２であるため、マルチタッチイベントであると判定する（Ｓ６０２でＮｏ）。そして、イベント管理部３０２は、受信したイベントをイベント生成部３０３に送信し、イベント生成部３０３は当該イベントに基づいてダミーイベントを生成する（Ｓ６０４）。この場合、タッチ数：１、イベント種別：シングルプレス、タッチ座標：（２００、２００）のシングルイベントが生成される。

そしてイベント管理部３０２は、生成されたダミーイベントをシングルイベント通知部３０４に送信すると共に、イベント管理部３０２から受信したオリジナルイベントをマルチイベント通知部３０５に送信する。シングルイベント通知部３０４とマルチイベント通知部３０５は、それぞれ受信したイベントをイベント配信部３０６へ送信する。

これらのイベントを受信したイベント配信部３０６は、操作部１０６に表示されているアプリがマルチタッチ対応のアプリか否かを判定する（Ｓ６０５）。この判定には、図９のマルチタッチ管理テーブルが用いられる。ここでは、操作部１０６ではコピーアプリが動作しており、マルチタッチ管理テーブルにおけるコピーアプリのマルチタッチフラグが０になっているため、マルチタッチに対応していない従来アプリ３０７が表示されていると判断される。そのため、イベント配信部３０６は、受信したダミーイベントのみをコピーアプリへ送信する（Ｓ６０６）。これを受信したコピーアプリは、受信したイベントに対応する動作、すなわち、用紙選択ボタン１００６に対応づけられている用紙選択を行う画面の表示を行う。

以上が、マルチタッチに対応していない従来アプリ３０７でユーザがシングルタッチとマルチタッチを行ったときの具体例である。

以上の通り、タッチパネル２０３へのユーザのタッチ操作に基づいて発生したイベントがマルチタッチイベントの場合、当該マルチタッチイベントに基づいて生成されたシングルタッチイベントがマルチタッチ非対応の従来アプリ３０７に送信される。これにより、従来アプリ３０７を変更することなく、マルチタッチ操作を検出不可能な従来のタッチパネルでの操作性を維持することが可能となる。

なお、図６のＳ６０４で生成するシングルタッチイベントのタッチ座標は、マルチタッチイベントの１点目のタッチ座標をそのまま用いるものとして説明した。しかし、マルチタッチイベントの２点の中点の座標をタッチ座標としてもよい。例えば、図５のイベントＩＤ１のマルチタッチイベントに基づいてシングルタッチイベントを生成する場合、生成されるシングルタッチイベントのタッチ座標を（２０５、２００）としてもよい。これにより、従来の抵抗膜方式（感圧式）のタッチパネルで検出される座標と同じ座標をもつシングルタッチイベントをアプリに送信することが可能となり、より互換性の高い環境を提供できる。

また、図６のＳ６０６において、イベント配信部３０６は新規アプリ３０８に対してマルチタッチイベントとシングルタッチイベントの両方を送信するものとして説明した。つまり、イベント配信部３０６は、シングルイベント通知部３０４から受信したシングルタッチイベントがオリジナルイベントであってもダミーイベントであっても新規アプリ３０８に対して送信していた。これは、受信したシングルタッチイベントがオリジナルイベントであるかダミーイベントであるかをイベント配信部３０６が識別できないためであり、識別できるのであればダミーイベントを新規アプリ３０８に送信する必要はない。そこでイベント管理部３０２は、ダミーイベントをシングルイベント通知部３０４に送信する際に、イベント配信部３０６がダミーイベントであることを識別可能にするための情報を含めて送信するようにしてもよい。イベント配信部３０６は当該情報に基づいて、受信したシングルタッチイベントがダミーイベントであるか否かを判定し、ダミーイベントであると判定された場合には新規アプリ３０８には送信せず、従来アプリ３０７にのみ送信するよう制御する。これにより、アプリの容易な実装が可能になるだけではなく、イベントの通信量を削減することでシステム全体の負荷を削減できる。

（第２の実施形態）
第１の実施形態では、ドライバ部３０１にてマルチタッチイベントが検出された場合には、操作部１０６に従来アプリ３０７と新規アプリ３０８のどちらが表示されているかに拘わらずダミーイベントを生成するものとして説明した。これは、操作部１０６に表示されているアプリがマルチタッチ対応か否かの情報をイベント配信部３０６が管理しており、イベント管理部３０２では判断できないためである。しかしながら、どちらのアプリが表示されているかの情報をイベント配信部３０６からイベント管理部３０２に通知することで、操作部１０６に表示されているアプリがマルチタッチ対応か否かをイベント管理部３０２が判断するようにしてもよい。これにより、新規アプリ３０８が表示されている場合には、マルチタッチイベントが検出されてもダミーイベントの生成、及び送信を行わないようにすることも可能である。このときの処理について図１１のフローチャートを用いて説明する。なお、図６と同じ処理については同一の参照番号を付すことにより詳細な説明は省略するものとする。

Ｓ６０２において、受信したイベントがマルチタッチイベントであると判定された場合、イベント管理部３０２は現在ＬＣＤ２０６に表示されているアプリがマルチタッチ対応のアプリか否かを判定する（Ｓ６０５）。具体的には、イベント管理部３０２からシングルイベント通知部３０４経由でイベント配信部３０６に対して問い合わせることにより操作対象のアプリがマルチタッチ対応のアプリか否かを判定する。また、イベント配信部３０６がアプリの情報を定期的にイベント管理部３０２に通知するようにし、イベント管理部３０２では当該通知される情報に基づいて判定するようにしても良い。

ＬＣＤ２０６に表示されているアプリがマルチタッチ対応の新規アプリ３０８であると判定された場合（Ｓ６０５でＹｅｓ）、イベント管理部３０２はドライバ部３０１から受信したマルチタッチイベントをマルチイベント通知部３０５へ送信する。そして、マルチイベント通知部３０５は当該マルチタッチイベントをイベント配信部３０６に送信し、イベント配信部３０６が当該マルチタッチイベントを新規アプリ３０８に送信する（Ｓ１１０１）。

一方、ＬＣＤ２０６に表示されているアプリがマルチタッチ非対応の従来アプリ３０７であると判定された場合（Ｓ６０５でＮｏ）、イベント管理部３０２は受信したマルチタッチイベントをイベント生成部３０３へ送信する。イベント生成部３０３は、受信したマルチタッチイベントを基に、ダミーイベントとしてのシングルタッチイベントを生成する（Ｓ６０４）。そしてイベント生成部３０３は、生成したシングルタッチイベントをイベント管理部３０２へ送信し、イベント管理部３０２は、当該シングルタッチイベントをシングルイベント通知部３０４へ送信する。シングルイベント通知部３０４は当該シングルタッチイベントをイベント配信部３０６に送信し、イベント配信部３０６は受信したシングルタッチイベントを従来アプリ３０７に送信する（Ｓ６０７）。

以上のように、本実施形態によれば、現在操作対象のアプリがマルチタッチ対応のアプリか否かをイベント管理部３０２が判断し、マルチタッチ非対応のアプリである場合にのみダミーイベントの生成を行う。これにより、不要なダミーイベントの生成処理を行わなくてよく、シングルイベント通知部３０４経由でイベント配信部３０６に送信されるイベントが減少するため、システム全体の負荷も削減される。

（第３の実施形態）
第１、第２の実施形態では、ユーザがタッチパネル２０３上でシングルタッチ操作を行った場合、新規アプリ３０８にシングルタッチイベントのみを送信していた（図６、図１１のＳ６０３）。ここで、シングルタッチイベントとマルチタッチイベントとでは、イベントの送信経路が異なる（シングルイベント通知部３０４経由とマルチイベント通知部３０５経由）。そのため、ユーザがマルチタッチ操作とシングルタッチ操作を順番に行ったとしても、その順番通りにアプリにイベントが到達しない可能性がある。

例えば、図８で示すボックス画面において、ユーザが画像ボタン８０３を選択するタッチ操作（シングルタッチ）を行い、この後に画像Ｂのプレビュー画像を拡大するためのピンチアウト操作（マルチタッチ）を行ったとする。このとき、シングルイベント通知部３０４が他の処理によりすぐに動作できない場合、マルチイベント通知部３０５経由で送信されるマルチタッチイベントが先に新規アプリ３０８に到達する場合がある。その結果、ボックスアプリは、マルチタッチイベントに対応する処理を先に行ってからシングルタッチイベントに対応する処理を行うことになる。具体的には、表示されている画像Ａのプレビュー画像を拡大した後、画像Ｂのプレビュー表示を行うこととなり、ユーザの意図した操作結果とならない。

そこで、本実施形態では、ユーザが行ったタッチ操作の順番通りに新規アプリ３０８にイベントを送信するための方法について、図１２のフローチャートを用いて説明する。なお、基本的な処理や制御は第１、第２の実施形態と同じであるため、異なる点を中心に説明する。図１２において、Ｓ６０１〜Ｓ６０７の各処理は、図６と同じ処理である。図６と比較すると、Ｓ６０２において、ドライバ部３０１から受信したイベントがシングルタッチイベントであると判定された場合（Ｓ６０２でＹｅｓ）の処理が異なる。

イベント管理部３０２は、ドライバ部３０１から受信したイベントがシングルタッチイベントであると判断した場合、ＬＣＤ２０６に表示されているアプリがマルチタッチに対応している新規アプリ３０８であるか否かの判定を行う（Ｓ１２０１）。この判定方法について説明する。まず、ドライバ部３０１からのイベントを受信したイベント管理部３０２は、シングルイベント通知部３０４経由でイベント配信部３０６に対し、操作部１０６で表示しているアプリの情報を問い合わせる。そしてイベント管理部３０２は、イベント配信部３０６から返信された情報に基づいて、ＬＣＤ２０６に表示されているアプリがマルチタッチに対応しているアプリか否かを判定する。

判定の結果、ＬＣＤ２０６に表示されているアプリが従来アプリ３０７である場合（Ｓ１２０１でＮｏ）、第１の実施形態と同じく、イベント管理部３０２は受信したイベントをシングルイベント通知部３０４に送信する。そしてこのイベントは、シングルイベント通知部３０４からイベント配信部３０６経由で従来アプリ３０７に送信される（Ｓ６０３）。

一方、ＬＣＤ２０６に表示されているアプリが新規アプリ３０８であると判定された場合（Ｓ１２０１でＹｅｓ）、イベント管理部３０２は、ドライバ部３０１から受信したシングルタッチイベントをイベント生成部３０３に送信する。そして、イベント生成部３０３は、受信したシングルタッチイベントを基にしてマルチタッチイベントを生成する（Ｓ１２０２）。ここで生成するマルチタッチイベントの１点目のタッチ座標は、シングルタッチイベントに含まれる座標と同じものとし、２点目のタッチ座標は、座標（０、０）に固定するものとする。例えば、図４のイベントＩＤ１のシングルタッチイベントを受信した場合、イベント生成部３０３は、タッチ数：２、イベント種別：マルチプレス、タッチ座標：（２００、２００）、（０、０）のマルチタッチイベントを生成する。なお以降では、このイベント生成部３０３で生成したマルチタッチイベントをダミーイベントと呼び、ドライバ部３０１から受信したシングルタッチイベントをオリジナルイベントと呼ぶ。そしてイベント生成部３０３は、生成したダミーイベントをイベント管理部３０２へ送信する。

イベント管理部３０２は、イベント生成部３０３から送信されたダミーイベント（マルチタッチイベント）をマルチイベント通知部３０５へ送信する。また、イベント管理部３０２は、ドライバ部３０１から受信したオリジナルイベント（シングルタッチイベント）をシングルイベント通知部３０４へ送信する。

シングルイベント通知部３０４とマルチイベント通知部３０５は、それぞれ受信したイベントをイベント配信部３０６へ送信する。イベント配信部は受信したダミーイベントとオリジナルイベントを新規アプリ３０８へ送信する（Ｓ１２０３）。

以上の通り、ＬＣＤ２０６に新規アプリ３０８が表示されているときにユーザがシングルタッチ操作を行った場合、ダミーイベントとして生成されたマルチタッチイベントがシングルタッチイベントと共に新規アプリ３０８に送信される。これにより新規アプリ３０８には、ユーザがタッチパネル２０３上でシングルタッチとマルチタッチのどちらの操作を行った場合でも、常にマルチタッチイベントが送信されることとなる。そして、新規アプリ３０８は、受信したマルチタッチイベントの２点目の座標を確認し、座標（０、０）の場合はシングルタッチイベントと解釈し、座標（０、０）でなければマルチタッチイベントと解釈する。新規アプリ３０８は、シングルイベントであると解釈した場合には、１点目の座標に基づいて、当該シングルイベントに対応する動作を行う。

このように、本実施形態によれば、現在操作対象となっているアプリが新規アプリ３０８の場合、ユーザによりシングルタッチとマルチタッチのいずれが行われても、マルチタッチイベントが送信される。そして、新規アプリ３０８は、シングルタッチイベントを無視し、受信したマルチタッチイベントに基づいて動作を行うことにより、ユーザ操作の順番どおりの正しい動作を行うことが可能となる。

なお、Ｓ６０２でＮｏの場合、ＬＣＤ２０６に表示されているアプリがマルチタッチに対応している新規アプリ３０８であるか否かをイベント管理部３０２が判定し、新規アプリ３０８であると判定された場合にダミーイベントを生成するものとして説明した。これに対し、Ｓ６０２でＮｏと判定された場合、イベント生成部３０３が必ずダミーイベントを生成するようにしても良い。その場合、イベント生成部３０３により生成されたダミーイベントはマルチイベント通知部３０５経由でイベント配信部３０６に送信される。そして、イベント配信部３０６は、ＬＣＤ２０６に表示されているアプリがマルチイベントに対応しているか否かを判定し、対応している場合はダミーイベント、及びオリジナルイベントをアプリに送信し、非対応の場合はオリジナルイベントのみ送信する。このようにすることにより、現在操作対象となっているイベントがマルチイベントに対応しているか否かの判定をイベント管理部３０２が行わなくても同様の効果を得ることができる。

（その他の実施形態）
なお上記各実施形態では、ドライバ部３０１で検出するタッチイベントとして、タッチ数、イベント種別、タッチ座標が含まれるものとして説明した。しかし、タッチイベントはこれに限定されるわけではない。例えば、タッチイベントに含まれる情報としてタッチ省略するようにしてもよい。また、タッチ数に基づいてシングルタッチイベントであるかマルチタッチイベントであるかは判定可能であるため、イベント種別にはシングルやマルチの情報を含まず、「プレス」、「ムーブ」、「リリース」のみのイベント種別としてもよい。また、１つのタッチイベントに複数のタッチ座標を含むのではなく、１つのイベントに１つのタッチ座標しか含まないようにして、複数のタッチイベントを送信してもよい。このように、タッチイベントをシステム構成に合った形に変更することで、アプリの容易な実装が可能になるだけではなく、イベントの通信量を削減することでシステム全体の負荷を削減することも可能となる。

また、上記実施形態ではコピー機能、スキャナ機能、プリント機能等の複数の機能を有する画像形成装置１００を例として説明したが、このうち一部の機能のみを有する画像処理装置にも本発明は適用可能である。また、パーソナルコンピュータやＰＤＡ、携帯電話、ＦＡＸ、カメラ、ビデオカメラ、その他の画像ビューワ等、他の情報処理装置に適用しても構わない。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのコンピュータプログラム、及び該コンピュータプログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (13)

1. マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置であって、
   前記タッチパネルへのユーザによる操作に基づくタッチイベントを検出する検出手段と、
   前記検出手段により検出されたマルチタッチイベントに基づいてシングルタッチイベントを生成する生成手段と、
   マルチタッチイベントに対応していないアプリケーションに対して、前記生成手段により生成されたシングルタッチイベントを送信する送信手段と、
   を有し、前記送信手段は、マルチタッチイベントに対応しているアプリケーションに対して、前記検出手段により検出されたマルチタッチイベントと、前記生成手段により生成されたシングルタッチイベントと、を送信することを特徴とする情報処理装置。
2. 前記送信手段は、マルチタッチイベントに対応していないアプリケーションに対して、前記検出手段により検出されたマルチタッチイベントを送信せずに、前記生成手段により生成されたシングルタッチイベントを送信することを特徴とする請求項１記載の情報処理装置。
3. 前記生成手段は、前記検出手段により検出されたタッチイベントがマルチタッチイベントの場合、操作対象のアプリケーションがマルチタッチイベントに対応しているか否かに拘わらず、当該検出されたマルチタッチイベントに基づいてシングルタッチイベントを生成することを特徴とする請求項１または２に記載の情報処理装置。
4. 前記生成手段は、前記検出手段により検出されたシングルタッチイベントに基づいてマルチタッチイベントを生成し、
   前記送信手段は、マルチタッチイベントに対応しているアプリケーションに対して、前記検出手段により検出されたシングルタッチイベントと、前記生成手段により生成されたマルチタッチイベントと、を送信することを特徴とする請求項１から３のいずれか１項に記載の情報処理装置。
5. 複数のアプリケーションそれぞれについて、マルチタッチイベントに対応しているか否かの情報を管理する管理手段と、
   前記管理手段により管理する情報に基づいて、操作対象のアプリケーションがマルチタッチイベントに対応しているか否かを判定する判定手段と、
   を有することを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記管理手段は、前記複数のアプリケーションそれぞれの初期化処理において各アプリケーションから通知される情報に基づいて、管理する情報を更新することを特徴とする請求項５記載の情報処理装置。
7. 前記検出手段により検出されるタッチイベントには、タッチ数、イベント種別が含まれることを特徴とする請求項１から６のいずれか１項に記載の情報処理装置。
8. 前記生成手段は、前記検出手段により検出されたマルチタッチイベントに含まれる２点タッチ位置のうち、一方のタッチ位置を含むシングルタッチイベントを生成することを特徴とする請求項７記載の情報処理装置。
9. 画像を読み取る読み取り手段を有することを特徴とする請求項１から８のいずれか１項に記載の情報処理装置。
10. 画像を印刷する印刷手段を有することを特徴とする請求項１から９のいずれか１項に記載の情報処理装置。
11. 前記生成手段は、前記検出手段により検出されたマルチタッチイベントに含まれる２点のタッチ位置両方に基づいて１点のタッチ位置を決定し、決定された１点のタッチ位置を含むシングルタッチイベントを生成することを特徴とする請求項１から１０のいずれか１項に記載の情報処理装置。
12. マルチタッチ操作を検出可能なタッチパネルを備える情報処理装置における情報処理方法であって、
    前記タッチパネルへのユーザによる操作に基づくタッチイベントを検出する検出工程と、
    前記検出工程において検出されたマルチタッチイベントに基づいてシングルタッチイベントを生成する生成工程と、
    マルチタッチイベントに対応していないアプリケーションに対して、前記生成工程において生成されたシングルタッチイベントを送信する送信工程と、
    を有し、前記送信工程では、マルチタッチイベントに対応しているアプリケーションに対して、前記検出工程において検出されたマルチタッチイベントと、前記生成工程において生成されたシングルタッチイベントと、を送信することを特徴とする情報処理方法。
13. 請求項１２記載の情報処理方法をコンピュータに実行させるためのプログラム。

Images