JP2015069475A - 操作支援プログラム、通信端末、および処理装置 - Google Patents

Abstract

【課題】携帯端末４０のタッチパネル４６に対する入力に基づきＭＦＰ１０を操作する機能に汎用性を持たせること。
【解決手段】ＭＦＰ１０のＬＣＤ２０には、タッチパネル２２に対する入力操作を案内する画像が表示される。この画像を表現する画像データは、携帯端末４０から要求されることで、携帯端末４０に送信され、携帯端末４０のＬＣＤ４４の表示領域に表示される。携帯端末４０では、ＬＣＤ４４の表示領域に画像が表示された状態で、タッチパネル４６に対してなされる入力操作に応じて、その入力イベントの種類と、入力操作によって指示される画像上の指示点の座標情報とを、ＭＦＰ１０に送信する。ＭＦＰ１０では、送信された入力イベントの種類と座標情報とに応じて処理を実行する。
【選択図】 図１

Description

本発明は、操作支援プログラム、通信端末、および処理装置に関する。

例えば下記特許文献１には、ＬＣＤに重ねられたタッチパネルを備える携帯端末を用いて複合機を遠隔操作する技術が提案されている。詳しくは、複合機の操作部を撮影することで得られる画像をＬＣＤに表示させ、タッチパネルの操作に応じて、複合機に処理を実行させる。すなわち、ＬＣＤに表示された画像のうち、例えばコピー処理が割り当てられたキーの画像が指定された場合、携帯端末は複合機にコピー処理の実行を指示する。

特開２０１３−８１８３号公報

上記技術の場合、携帯端末のタッチパネルへの入力操作に応じて複合機に対して処理を指示するための機能を、複合機毎に作成する必要や、複合機がバージョンアップした際には機能の追加変更をする必要が生じるという問題点があった。

本発明は、上記問題点を解決するためになされたものであり、その目的は、表示領域を有する表示部と、該表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する入力部と、処理装置と通信する通信部と、制御部とを備える通信端末によって実行されて且つ、前記入力部に対する入力に基づき前記処理装置を操作する機能に汎用性を持たせることのできる操作支援プログラム、通信端末、および処理装置を提供することにある。

この目的を達成するために、この発明は、表示領域を有する表示部と、該表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する入力部と、処理装置と通信する通信部と、制御部とを備える通信端末によって実行されて且つ、前記入力部に対する入力に基づき前記処理装置を操作するための操作支援プログラムにおいて、前記処理装置により実行される処理を指示するための前記入力媒体による入力操作を案内する画像について、該画像を表現する画像データの送信を前記処理装置に要求する送信要求手段と、該送信要求手段による要求に応じて送信される前記画像データを受信する画像受信手段と、前記受信された画像データにより表現される画像を前記表示領域に表示する表示制御手段と、前記表示制御手段により前記画像が表示されている状態において前記入力部によって検出された前記表示領域上の指示点の座標情報、および該入力部に対する入力イベントの種類を前記処理装置に送信する入力情報送信手段と、を前記制御部に実行させる。

請求項１記載の操作支援プログラムでは、画像受信手段により、画像データを処理装置から受信し、表示制御手段により、画像データにより表現される画像が表示領域に表示される。この画像によれば、通信端末の入力部に対する入力操作を案内することができる。そして、入力部によって検出された指示点の座標情報が、入力イベントの種類とともに、入力情報送信手段により、処理装置に送信される。ここで、画像データは、処理装置から送信されたものであるため、処理装置に、画像における指示点の位置と、実行すべき処理との対応関係を予め把握させておくことができる。そしてこの場合、処理装置では、受信した座標情報から画像における指示点の位置を把握することで、いかなる処理を実行すべきかを把握することができる。このため、通信端末側では、入力部に対する入力操作が処理装置のいかなる処理の実行を指示するものであるのかを把握している必要がない。したがって、入力部に対する入力に基づき処理装置を操作する機能に汎用性を持たせることができる。また、送信要求手段により画像データの送信が要求されるのに応じて、送信される画像データが画像受信手段により受信されるため、通信端末側で画像データが必要となるときに画像データを受信することができる。

請求項２記載の操作支援プログラムでは、入力部に対する入力操作に伴って、表示部の表示領域に表示すべき画像が遷移することに着目し、入力情報送信手段による送信処理が実行されることを条件に、画像データの送信を要求する。これにより、請求項１記載の操作支援プログラムの効果に加えて、表示部の表示領域に表示すべき画像が遷移する際に画像データの送信を要求することができるという効果を奏する。

請求項３記載の操作支援プログラムでは、入力イベントとして画面上の位置の確定操作が送信されることを条件に、画像データの送信を要求する。ここで、入力イベントとして画面上の位置の確定操作がなされる場合、表示部の表示領域に表示される画像を遷移させることが適切である傾向にある。このため、請求項２記載の操作支援プログラムの効果に加えて、画像データの送信を適切なタイミングで要求することができるという効果を奏する。

請求項４記載の操作支援プログラムでは、装置側表示部の表示領域に表示される画像が徐々に入れ替えられるときにおいて、画像データの送信要求を所定期間待機する。これにより、請求項３記載の操作支援プログラムの効果に加えて、処理装置側において画像の入れ替えが完了する前において画像データの送信要求に応じて画像データが通信端末に送信される事態を回避することができるという効果を奏する。

請求項５記載の操作支援プログラムでは、装置側表示部の表示領域に表示される画像が徐々に入れ替えられるために画像データの送信要求を待機している所定期間について、その間に生じた入力イベントの種類を送信しない。このため、請求項３記載の操作支援プログラムの効果に加えて、装置側表示部の表示領域に表示されている画像と、端末側表示部の表示領域に表示されている画像とが不一致となる状態における入力イベントに基づき処理装置が操作される事態を回避することができる。

請求項６記載の操作支援プログラムでは、変位通知受信手段によって画像内のオブジェクトが変位する旨が受信されることを条件に、画像データの送信を要求する。画像内のオブジェクトが変位する旨が受信されるときに画像データの送信を要求する場合、オブジェクトが変位している途中の画像を表現する画像データを受信し、これを端末側表示部の表示領域に表示することができる。したがって、請求項１または２記載の操作支援プログラムの効果に加えて、装置側表示部の表示領域にアニメーション表示がなされる場合に、端末側表示部の表示領域にもアニメーション表示を行うことができるという効果を奏する。

請求項７記載の操作支援プログラムでは、装置側表示部の表示領域に表示される画像内のオブジェクトが変位するときには、装置側表示部の表示領域に表示される画像と、端末側表示部の表示領域に表示される画像とが一致しないことに着目する。画像が一致しないときに、端末側入力部に対する入力操作に基づき送信処理を実行すると、ユーザの意図とは相違する処理装置の操作がなされるおそれがある。この点に鑑み、変位通知受信手段が変位を含む旨を受信することを条件に、処理装置への送信処理を実行しないことで、請求項６記載の操作支援プログラムの効果に加えて、ユーザの意図とは相違する処理装置の操作がなされる事態を好適に回避することができるという効果を奏する。

請求項８記載の操作支援プログラムでは、処理装置により実行される処理を指示するうえで指示点のあるべき箇所を示すオブジェクトが装置側表示部の表示領域において変位する場合には、装置側表示部の表示領域と端末側表示部の表示領域とで、オブジェクトの位置が相違することに着目する。オブジェクトの位置が相違するときに端末側入力部に対する操作によってオブジェクトが指示される場合、その座標情報に基づき処理装置側では、ユーザが意図したオブジェクトが指示されたと判断されず、別の箇所が指示されたと誤認識されるおそれがある。この点、オブジェクトが変位しているときに送信処理を実行しないため、請求項７記載の操作支援プログラムの効果に加えて、ユーザの意図とは相違する処理装置の操作がなされる事態を好適に回避することができるという効果を奏する。

請求項９記載の操作支援プログラムでは、装置側表示部の表示領域に処理装置によって実行される処理の進行度合いがアニメーション表示される場合、この表示自体は、処理装置により実行される処理を指示する上で指示点のあるべき箇所を案内するものではないことに着目する。そしてこの場合には、送信処理を実行可能とすることで、請求項７または８記載の操作支援プログラムの効果に加えて、進行度合いのアニメーション表示がなされているときにおいて、処理装置を操作することが可能となるという効果を奏する。

請求項１０記載の操作支援プログラムでは、変位通知手段が変位を含む旨を受信することを条件に、その旨を端末側表示部の表示領域に表示する。このため、請求項６から９のいずれか１項に記載の操作支援プログラムの効果に加えて、装置側表示部の表示領域に表示されている画像内のオブジェクトが変位している旨や、変位していることに起因した処理を通信端末において実行している旨をユーザに知らせることができるという効果を奏する。

請求項１１記載の通信端末によれば、請求項１から１０のいずれか１項に記載の操作支援プログラムによる効果に準じた効果を奏することができる。

請求項１２記載の処理装置では、要求受信手段が通信端末から画像データの送信要求を受信することを条件に、画像送信手段が通信端末に画像データを送信する。その後、通信端末の入力部に対する入力操作に応じた指示点の座標情報とイベントの種類とを入力情報受信手段によって受信する。ここで、画像データは、処理装置から送信されたものであるため、処理装置に、画像における指示点の位置および入力イベントの種類と、実行すべき処理との対応関係を予め把握させておくことができる。そしてこの場合、受信した座標情報から画像における指示点の位置を把握することで、いかなる処理を実行すべきかを特定することができる。このため、実行手段では、座標情報および入力イベントの種類によって特定される処理を実行することができる。このように、実行手段によって処理を実行させるうえで、通信端末側では、座標情報と入力イベントとを送信するのみでよいため、実行手段によって実行させる処理を特定する必要が生じない。このため、入力部に対する入力に基づき処理装置を操作する機能に汎用性を持たせることができる。また、画像データが要求されることを条件に画像データを送信するため、通信端末が画像データを必要とするときに、画像データを送信することができる。

請求項１３記載の処理装置では、装置側表示部の表示領域に表示されている画像内のオブジェクトが変位していることを条件に、画像データの送信要求を受信した場合であっても、待機手段により画像データの送信を、上記変位が完了するまで待機する。これにより、請求項１２記載の処理装置の効果に加えて、装置側表示部の表示領域に表示される画像と、端末側表示部の表示領域に表示される画像とが不一致となる状態の継続時間を極力短くすることができるという効果を奏する。

請求項１４記載の処理装置では、装置側表示部の表示領域に表示中の画像がアニメーションを含むことを条件に、変位通知手段により通信端末にその旨を通知する。これにより、請求項１２記載の処理装置の効果に加えて、通信端末では、装置側表示部の表示領域に表示中の画像がアニメーションを含むことを把握することができ、それに応じた対処をすることが可能となる。

第１の実施形態にかかるシステム構成図。 画面の変更処理を例示する図。 画像データマップを示す図。 携帯端末側の処理の手順を示すフローチャート。 携帯端末においてアプリケーションを起動した際の処理を示す図。 画像拡縮処理の手順を示すフローチャート。 座標情報の生成処理を示す図。 イベント反応処理の手順を示すフローチャート。 ＭＦＰ側の処理の手順を示すフローチャート。 第２の実施形態にかかるＭＦＰ側の処理の手順を示すフローチャート。 携帯端末側の処理の手順を示すフローチャート。 第３の実施形態にかかるＭＦＰ側の処理の手順を示すフローチャート。 携帯端末側の処理の手順を示すフローチャート。 第４の実施形態にかかるＭＦＰ側に表示される画像を例示する図。

＜第１の実施形態＞
以下、本発明にかかる第１の実施形態について、図面を参照しつつ説明する。

図１に、本実施形態にかかるシステム構成を示す。図示される多機能周辺装置（ＭＦＰ１０）は、印刷機能やスキャナ機能、ファクシミリ機能等を備えている。ＭＦＰ１０は、ＣＰＵ１２、フラッシュメモリ１４、ＲＡＭ１６、通信部１８、ＬＣＤ２０、タッチパネル２２、スキャナ２４、プリンタ２６、およびモデム２８を備え、これらが入出力ポート３０を介して互いに接続されている。ＣＰＵ１２は、フラッシュメモリ１４に記憶される固定値やプログラム、ＲＡＭ１６に記憶されているデータに従って、ＭＦＰ１０が有している各機能の制御や、入出力ポート３０と接続された各部を制御する。

フラッシュメモリ１４は、書換可能な不揮発性のメモリであり、ＲＡＭ１６は書換可能な揮発性のメモリである。ＬＣＤ２０は、液晶表示装置であり、各種画面を表示する。ＬＣＤ２０の画面には、タッチパネル２２が重ねて設けられている。タッチパネル２２は、指や棒などの入力媒体が接触または接近されたタッチパネル２２上の位置を示す指示点情報を出力するユーザインターフェースである。

以下、入力媒体によるタッチパネル２２への接触または接近を、入力媒体によるタッチパネル２２の押下と称し、押下後に、入力媒体とタッチパネル２２との距離が拡大することを離上と称する。また、押下後、離上することなく入力媒体を変位させることで、接触または接近されたタッチパネル２２上の点である指示点を変位させることをドラッグ操作と称する。なお、本実施形態におけるタッチパネル２２上の点は、入力媒体の接触または接近が検出された、タッチパネル２２上の領域の中心点とするが、それに限らず、入力媒体の接触または接近が検出された、タッチパネル２２上の領域内の任意の点としてもよいし、その領域自体を本実施形態の点と読み替えてもよい。また、これらの定義は、携帯端末４０のタッチパネル４６についても同様である。

スキャナ２４は、原稿を読み取って画像データに変換する。プリンタ２６は、画像データに基づく画像を記録用紙に印刷する。モデム２８は、ＦＡＸ送信時には送信すべき画像データを、電話回線網（図示せず）に伝送可能な信号に変調して送信し、または、図示しない電話回線網から入力された信号を画像データに復調する。通信部１８は、無線通信を行うためのインタフェースである。本実施形態において、通信部１８が行う無線通信は、ＩＥＥＥ８０２．１１ｂ/ｇの規格に準拠したＷｉ−Ｆｉ通信（Ｗｉ−Ｆｉは登録商標）である。

携帯端末４０は、例えば、スマートフォンや携帯電話などである。携帯端末４０は、通信部４２、ＬＣＤ４４、タッチパネル４６、音声入出力部４８、電話網通信部５０、ＣＰＵ５２、フラッシュメモリ５４、ＲＡＭ５６を備え、それらが入出力ポート５８を介して互いに接続されている。ＣＰＵ５２は、フラッシュメモリ５４等に記憶される固定値やプログラム等に従って、入出力ポート５８と接続された各部を制御する。

フラッシュメモリ５４は、書換可能な不揮発性のメモリであり、ＲＡＭ５６は、書換可能な揮発性のメモリである。ＬＣＤ４４は、液晶表示装置であり、各種画面を表示する。タッチパネル４６は、ＬＣＤ４４に重ねて設けられ、指や棒などの入力媒体が接触または接近されたタッチパネル４６上の位置を示す指示点情報を出力するユーザインターフェースである。

音声入出力部４８は、マイクやスピーカなどで構成された音声入出力用デバイスである。電話網通信部５０は、携帯電話網（図示せず）を介した通話を行うための回路である。通信部４２は、無線通信を行うためのインタフェースである。本実施形態において、通信部４２が行う無線通信は、ＩＥＥＥ８０２．１１ｂ/ｇの規格に準拠したＷｉ−Ｆｉ通信（Ｗｉ−Ｆｉは登録商標）である。携帯端末４０は、通信部４２および中継装置であるアクセスポイント（図示せず）を介したインフラストラクチャモードにより、通信部１８を有するＭＦＰ１０との間でＷｉ−Ｆｉ接続される。

上記ＭＦＰ１０は、ＬＣＤ２０の表示領域２０ａに入力媒体による入力操作を案内する画像を表示し、タッチパネル２２に対する入力操作である押下、ドラッグ、離上等の操作がなされることに応じて、ファクシミリ送信処理や、印刷処理、スキャン処理等の各種処理を実行する。これら各処理の実行を指示するための入力操作を案内するオブジェクトを含む画像の全てを、ＬＣＤ２０の表示領域２０ａに一度に表示することは、表示領域２０ａの大きさの都合上困難である。このため、本実施形態では、ＬＣＤ２０の表示領域２０ａに表示される画像を切り替えることが可能となっている。図２（ａ）は、ＬＣＤ２０の表示領域２０ａに表示される画像の一例であり、図２（ｃ）はＬＣＤ２０の表示領域２０ａに表示される画像の別の例である。図２（ａ）では、ファクシミリ機能を指定するオブジェクト（ＦＡＸと記載されたボタン）や、コピー機能を指定するオブジェクト（Ｃｏｐｙと記載されたボタン）、スキャン機能を指定するオブジェクト（Ｓｃａｎと記載されたボタン）が表示された例を示している。一方、図２（ｃ）には、ファクシミリ機能の実行を指示するオブジェクト（ＦＡＸ Ｓｔａｒｔと記載されたボタン）等、ファクシミリ機能に関する各種処理の実行を指示するオブジェクトが記載された例を示している。

本実施形態は、ＭＦＰ１０において、ＬＣＤ２０の表示領域２０ａに表示される画像が変更される場合、表示領域２０ａに表示される画像内の少なくともオブジェクトの位置をユーザに感知可能なスピードで変位させる表示（アニメーション表示）を用いて画像を変更する。すなわち、図２（ａ）に示す変更前の画像から、図２（ｃ）に示す変更後の画像に変更する場合、画像の変更に伴い、変更前の画像（画面全体）の右側から変更後の画像（画面全体）を徐々にスライドさせる。図２（ｂ）は、スライドさせている途中の段階を示している。この途中の期間においては、ＭＦＰ１０のタッチパネル２２において入力操作を受け付けないようになっている。

ＬＣＤ２０の表示領域２０ａにおける画像の変更は、基本的には、ユーザによる入力操作に応じてなされる。具体的には、タッチパネル２２に対して画面遷移をさせるオブジェクトが押下された後、離上されることでなされる。これは、本実施形態において、タッチパネル２２に対する押下操作が指示点の位置の選択操作を意味しており、離上操作が指示点の位置の確定操作を意味していることによる。なお、押下操作された指示点の位置はＲＡＭ１６に記憶される。

ただし、本実施形態では、タッチパネル２２に対する離上操作に限らず、ＭＦＰ１０の内部において、ユーザに通知すべき情報が発生したときに、画面遷移をさせるオブジェクトが押下された後、離上されなくても、ＬＣＤ２０の表示領域２０ａの画面が遷移されることもある。ここで、ユーザに通知すべき情報としては、例えばプリンタ２６のインク残量が低下した場合等がある。この画面の遷移は、基本的にはポップアップ表示となる。なお、ポップアップ表示は、所定時間なされることで、表示領域２０ａから消去されるものもある。

本実施形態では、これらＬＣＤ２０の表示領域２０ａに表示される各画面には、画面を特定する情報（画面ＩＤ）が付与されている。画面ＩＤは、図３に示されるように、ＭＦＰ１０のフラッシュメモリ１４内に記憶される画像データマップによって画像と対応づけられている。画像データマップは、画像データ毎に、画面ＩＤと、記憶の要否の情報とが関連づけられているデータである。ここで、記憶の要否の情報については、図９の処理（Ｓ１２０）の説明において詳述する。

ＭＦＰ１０は、タッチパネル２２に対する入力操作とは別に、携帯端末４０からの指示に応じて、各種機能を実行することもできる。これを可能とすべく、本実施形態では、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される、入力媒体による入力操作を案内する画像を、携帯端末４０のＬＣＤ４４においても表示可能とする。すなわち、ＭＦＰ１０がこの画像を表現する画像データを、携帯端末４０に送信することで、携帯端末４０では、受信した画像データが表現する画像をＬＣＤ４４の表示領域４４ａに表示する。これにより、ユーザは、ＬＣＤ４４の表示領域４４ａに表示された画像に従って、タッチパネル４６に対する入力媒体による入力操作を行うことができる。そして、携帯端末４０は、タッチパネル４６に対する入力操作に伴うＬＣＤ４４の表示領域４４ａ上の指示点の座標情報をＭＦＰ１０に出力する。この座標情報により、図７を用いて後に詳述するように、ＭＦＰ１０では、ＬＣＤ２０の表示領域２０ａに表示された画像のうちいかなる位置が指示されたかを把握することができる。これにより、例えばＬＣＤ４４の表示領域４４ａのうち、印刷処理の実行を指示するためのオブジェクトに指示点が位置する場合、ＭＦＰ１０では、座標情報に基づき、印刷処理の実行が指示されたことを認識し、印刷処理を実行する。このように、携帯端末４０のタッチパネル４６に対する入力操作によってＭＦＰ１０を操作することができる。この際、携帯端末４０では、指示点の座標情報と、タッチパネル４６への入力イベントの種類（押下、ドラッグ、離上）をＭＦＰ１０に通知するのみであり、携帯端末４０では、タッチパネル４６への入力操作が、ＭＦＰ１０に対するいかなる処理の実行指令であるかを把握する必要がない。

以下では、図面を参照しつつ、携帯端末４０によるＭＦＰ１０の操作に関する処理について詳述する。

図４に、携帯端末４０によって実行される処理の手順を示す。この処理は、ＣＰＵ５２によって、フラッシュメモリ５４に記憶された操作支援プログラムが実行されることで実現される。なお、Ｓ１４からＳ５４の各処理は、Ｓ１４の処理において、タッチパネル４６に対する入力操作を受け付ける毎に、それぞれ実行される。即ち、Ｓ１４からＳ５４の各処理は、複数並行して実行され得る処理となっている。

ＣＰＵ５２は、操作支援プログラム（アプリケーション）が起動されることで、ＬＣＤデータ取得処理を実行する（Ｓ１０）。すなわち、ＣＰＵ５２は、図５に示すように、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像を表現する画像データ（ＬＣＤデータ）を要求する信号をＭＦＰ１０に出力する。そしてＣＰＵ５２は、ＭＦＰ１０からＬＣＤデータが送信されることで、これを受信して、その表現する画像をＬＣＤ４４の表示領域４４ａに表示する。

次にＣＰＵ５２は、ＭＦＰ１０から送信される付加情報を受信する（Ｓ１２）。ここで、付加情報には、Ｓ１０において要求した画像を特定する画面ＩＤが含まれる。ＭＦＰ１０は、図３に示した画像データマップを用いて、携帯端末４０に送信した画像データに対応する画面ＩＤを付加情報に含める。

続いて、ＣＰＵ５２は、タッチパネル４６に対する入力操作を待ち受ける（Ｓ１４）。そして、ＣＰＵ５２は、入力操作を受け付けた場合、その入力操作に関する入力イベントが、押下イベントであるか否かを判断する（Ｓ１６）。ＣＰＵ５２は、押下イベントであると判断する場合（Ｓ１６：Ｙｅｓ）、押下操作された指示点の位置をＲＡＭ５６に記憶し、タッチパネル４６に対する入力イベントの受付が可能となっているか否かを判断する（Ｓ１８）。この処理は、後述するＳ４６の処理がなされているときか否かを判断するためのものである。そしてＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていないと判断する場合（Ｓ１８：Ｎｏ）、タッチパネル４６に対する入力を受け付け可能となる場合に入力イベントを受け付けるべく、処理をＳ１４に移行する。これに対しＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていると判断する場合（Ｓ１８：Ｙｅｓ）、画像拡縮処理を実行する（Ｓ２０）。

図６に、画像拡縮処理の手順を示す。この処理は、Ｓ１４で受け付けた押下イベントが、ＭＦＰ１０に処理の実行を指示する押下イベントであるか、入力媒体によりピンチイン、ピンチアウト操作が行われることにより受け付ける連続的な押下イベントのうちの１つの押下イベントであるのかを識別するためのものである。ここで、ピンチイン操作とは、タッチパネル上に例えば親指と人差し指の二本の指を乗せ、その二本の指でつまむような動作をすることであり、画像を縮小する際などに行うものである。またピンチアウト操作とは、タッチパネル上に例えば親指と人差し指の二本の指を乗せ、その二本の指で押し広げるような動作をすることであり、画像を拡大する際などに行うものである。よって、ピンチイン、ピンチアウト操作である場合、それは携帯端末４０のＬＣＤ４４の表示領域４４ａに表示される画像の縮小、拡大を指示するものであるため、ＭＦＰ１０には無関係な入力操作である。

ＣＰＵ５２は、ステップＳ６１において説明する待ち処理を実行したか否かを判断する（Ｓ６０）。そしてＣＰＵ５２は、待ち処理を実行していないと判断する場合（Ｓ６０：Ｎｏ）、所定時間待機する待ち処理を開始する（Ｓ６１）。ここで所定時間は、ユーザがピンチイン操作やピンチアウト操作をすべく、タッチパネル４６に入力媒体としての２本の指が押下される場合における、それら一対の押下タイミングの時間差に応じて設定される。詳しくは、上記時間差として通常取り得る値に設定される。例えば本実施形態では、０．５秒に設定される。ＣＰＵ５２は、待ち処理中に他の押下イベントが生じたか否かを判断する（Ｓ６２）。この処理は、ピンチインやピンチアウトがなされるか否かを判断するためのものである。そして、ＣＰＵ５２は、待ち処理中に他の押下イベントが生じたと判断する場合（Ｓ６２：Ｙｅｓ）、一対の押下イベントに対応した一対の指示点の移動状態に応じて、ＬＣＤ４４の表示領域４４ａに表示される画像を拡大または縮小する処理を実行する（Ｓ６４）。なお、Ｓ６２の処理は、実際には、所定時間待機した後に実行するのではなく、所定時間の経過以前において、肯定判断されるまで繰り返し実行されるものとすることが望ましい。これにより、Ｓ６２において肯定判断される場合、Ｓ６４の処理に迅速に移行することができる。

一方、ＣＰＵ５２は、待ち処理中に他の押下イベントが生じないと判断する場合（Ｓ６２：Ｎｏ）、図４のＳ２２の処理へ移行する。

その後、ＣＰＵ５２は、離上イベントの発生前において、他の入力媒体がタッチパネル２２に接近または接触されることで、図４のＳ１６の処理において再度肯定判断されて画像拡縮処理に移行する場合には、Ｓ６１の待ち処理が実行されていると判断し（Ｓ６０：Ｙｅｓ）、Ｓ７２の処理に移行する。この時点では、指示点が２点となっているため、ユーザがピンチイン、ピンチアウト操作をしようとしている可能性があるものの、待ち処理時間の間には指示点が２点とならなかったために、Ｓ７２の処理においては、ピンチイン、ピンチアウト操作であるのか、ドラッグ中にたまたま他の指がタッチパネル４６を押下してしまったのかを区別する。

具体的には、ＣＰＵ５２は、後述するＳ３６の処理によってインクリメントされるドラッグ記憶回数が一定数以下であるか否かを判断する（Ｓ７２）。ドラッグ記憶回数は、ドラッグ操作がなされている場合のサンプリング回数を示すものであり、ドラッグ記憶回数が多いほど、ドラッグ時間が長いことを示す。ここで、一定数は、ピンチイン、ピンチアウトの場合に想定し難い程度の値に設定される。そしてＣＰＵ５２は、一定数を超えると判断する場合（Ｓ７２：Ｎｏ）、ピンチイン、ピンチアウト操作がなされるにしてはドラッグ操作の時間が長すぎるとして、図４のＳ２２の処理に移行する。これに対し、ＣＰＵ５２は、一定数以下であると判断する場合（Ｓ７２：Ｙｅｓ）、ピンチイン、ピンチアウト操作がなされると考えられることから、ＭＦＰ１０に押下イベントの送信を取り消す旨を通知する（Ｓ７４）。これは、ＣＰＵ５２がＳ７２において肯定判断する場合、ユーザが、ピンチイン操作やピンチアウト操作を行うことを意図しつつも、タッチパネル４６において１つの指示点が検出されてから別の１つの指示点が検出されるまでの間に時間がかかったため、Ｓ６２の処理において否定判断され、後述するＳ２２の処理を経てＳ２４の処理によってＭＦＰ１０に押下イベントが送信されているためになされるものである。この取り消し処理は、後述する図９のＳ１６０の処理の前提となる。ＣＰＵ５２は、Ｓ７４の処理を完了すると、一対の指示点の移動状態に応じて拡縮処理を実行する（Ｓ６４）。

ＣＰＵ５２は、Ｓ６４の処理の実行後、全ての指示点が検出されなくなったかを判断する。換言すれば、全ての入力媒体がタッチパネル２２から離上したかを判断する（Ｓ６６）。そして全ての指示点が検出されなくなったと判断する場合（Ｓ６６：Ｎｏ）、ドラッグ記憶回数を初期化する処理を実行し（Ｓ６８）、タッチパネル４６に対する新たな入力を待ち受けるべく、図４のＳ１４の処理に戻る。なお、Ｓ６８の処理によってドラッグ記憶回数が初期化後の値に変化するは、実際には、後述するＳ７４の処理が実行される場合であり、Ｓ６２において肯定判断された場合、Ｓ６８の処理は実際には不要である。

ＣＰＵ５２は、図４のＳ２０の処理が完了する場合、すなわち、Ｓ６２，Ｓ７２において否定判断される場合、押下位置を変換する処理を実行する（Ｓ２２）。これは、例えば図７（ａ）に示すように、ＬＣＤ４４の表示領域４４ａのうち、画像を表示する基準となる座標（描画開始座標：Ｘ，Ｙ）と押下点の座標（Ａ，Ｂ）との差（Ａ−Ｘ，Ｂ−Ｙ）を、表示されている画像の拡大率ｋで除算した値｛（Ａ−Ｘ）／ｋ，（Ｂ−Ｙ）／ｋ｝を算出する処理とすればよい。差（Ａ−Ｘ，Ｂ−Ｙ）は、描画開始座標（Ｘ，Ｙ）を原点に取り直した際の押下点の座標である。ここで、拡大率ｋは、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示された画像のサイズに対する、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示された画像のサイズの比である。なお、ここでサイズとは、実際の長さに限らず、例えば表示画素数等としてもよい。この場合、例えば１画素あたりの面積がＭＦＰ１０のＬＣＤ２０のものと比較して携帯端末４０のＬＣＤ４４のものの方が小さい場合、拡大率が１であっても、表示される画像の実際の大きさは、ＬＣＤ２０に表示されるものよりもＬＣＤ４４に表示されるものの方が小さくなる。

上記変換処理は、携帯端末４０のＬＣＤ４４の表示領域４４ａにおいて画像が拡大表示されている場合や縮小表示されている場合であっても、ＭＦＰ１０において、ＬＣＤ２０の表示領域２０ａに表示された画像のいずれの点が押下点となっているかを把握可能とすることを狙ったものである。なお、こうした狙いは、図７（ｂ）に示すように、２次元座標の各成分における画像の長さに対する基準点から押下点までの長さの比によっても実現することができる。すなわち、画像の対角線上の一対の端部を、描画開始座標（Ｘ，Ｙ）および描画終了座標（Ｘｅ，Ｙｅ）とし、２次元座標成分のそれぞれについての、表示される画像の長さと、描画開始座標に対する押下点の長さの比｛（Ａ−Ｘ）／（Ｘｅ−Ｘ），（Ｂ−Ｙ）／（Ｙｅ−Ｙ）｝としてもよい。

続いてＣＰＵ５２は、図４のＳ２４の処理において、上記処理によって得られた押下位置情報（押下によって指示された指示点の座標情報）と、入力イベントの種類が押下イベントである旨と、ＬＣＤ４４の表示領域４４ａに表示している画像の画面ＩＤとをＭＦＰ１０に送信する（Ｓ２４）。続いてＣＰＵ５２は、イベント反応処理を実行する（Ｓ２６）。図８にこの処理を示す。

この一連の処理では、ＣＰＵ５２は、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示された画像の画面ＩＤと、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像の画面ＩＤとが異なる旨の通知をＭＦＰ１０から受信したか否かを判断する（Ｓ８０）。この通知は、図４のＳ２４の処理に応じてＭＦＰ１０において実行される後述する図９のＳ１４０の処理によってなされるものである。ここで、携帯端末４０のタッチパネル４６に対して押下操作がなされ、ＭＦＰ１０に押下イベントが送信されることによっては、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａの画像は変化しない。これは、上述したように、本実施形態では、指示点の確定操作（離上操作）がなされることで、画面が変更されるためである。それにもかかわらず、画面ＩＤが異なりうるのは、上述したように、ＭＦＰ１０において、ユーザに通知すべき情報が生じた場合に、ユーザによる入力操作とは無関係にＬＣＤ２０の表示領域２０ａに表示される画像が変更されるからである。

そしてＣＰＵ５２は、異なる旨の通知を所定時間受信しない場合（Ｓ８０：Ｎｏ）、イベント反応処理を終了する。これに対しＣＰＵ５２は、異なる旨の通知を受信する場合（Ｓ８０：Ｙｅｓ）、ＭＦＰ１０から取得すべきＬＣＤデータがあるとして、ＬＣＤデータ取得処理を実行する（Ｓ８２）。この処理は、図４のＳ１０の処理と同様である。続いてＣＰＵ５２は、付加情報取得処理を実行する（Ｓ８４）。この処理は、図４のＳ１２の処理と同様であるが、Ｓ８４の処理では画面ＩＤに加え、次画面有無情報も取得している。続いてＣＰＵ５２は、ＬＣＤ４４の表示領域４４ａに、画面ＩＤが異なるために画面を更新する旨を通知する画像を表示する（Ｓ８６）。これは、たとえばポップアップ表示等によって実現すればよい。この処理は、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像と携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像とが一致しないために画面が変更される旨をユーザに通知するためになされるものである。

ＣＰＵ５２は、次に、後述するドラッグ記憶回数を初期化する（Ｓ８８）。そして、ＣＰＵ５２は、Ｓ８４の処理によって受信された付加情報に基づき、ＭＦＰ１０から取得すべき次の画像（次画像）があるか否かを判断する（Ｓ９０）。この処理は、携帯端末４０とは独立に、ＭＦＰ１０側において、ＬＣＤ２０の表示領域２０ａに表示する画像を変更する事態が生じたことに起因して、携帯端末４０が複数の画像のそれぞれを表現する画像データを順に受信し、これをＬＣＤ４４の表示領域４４ａに表示すべき場合に、付加情報に次画像ありとの情報を含める設定を前提としている。なお、この設定については、後述する図９のＳ１１４〜Ｓ１２２の処理において詳述する。そしてＣＰＵ５２は、次画像がないと判断する場合（Ｓ９０：Ｎｏ）、イベント反応処理を終了する。これに対しＣＰＵ５２は、次画像があると判断する場合（Ｓ９０：Ｙｅｓ）、待ち処理を実行し（Ｓ９２）、Ｓ８２の処理に戻る。ここで、待ち処理の待ち時間は、現在、ＬＣＤ４４の表示領域４４ａに表示中の画像をユーザが十分に確認できる長さに設定されている。

なお、ＣＰＵ５２は、イベント反応処理が終了する場合、タッチパネル４６に対する新たな入力操作を待ち受けるべく、図４のＳ１４の処理に戻る。

ＣＰＵ５２は、新たに生じたイベントが押下イベントではないと判断する場合（Ｓ１６：Ｎｏ）、新たに生じたイベントがドラッグイベントであるか否かを判断する（Ｓ２８）。そしてＣＰＵ５２は、タッチパネル４６上の指示点の変位の検知により、ドラッグイベントであると判断する場合（Ｓ２８：Ｙｅｓ）、上記Ｓ１８の処理と同様、タッチパネル４６に対する入力イベントの受付が可能となっているか否かを判断する（Ｓ３０）。そしてＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていないと判断する場合（Ｓ３０：Ｎｏ）、タッチパネル４６に対する入力が可能となった場合にこれを受け付けるべく、Ｓ１４の処理に戻る。これに対しＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていると判断する場合（Ｓ３０：Ｙｅｓ）、ドラッグ位置変換処理を実行する（Ｓ３２）。この処理は、現在の指示点の位置を、図７（ａ）または図７（ｂ）に示した処理の要領で、ＬＣＤ４４の表示領域４４ａに表示された画像のサイズにかかわらず、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示された画像上の位置として特定可能な値（座標情報）に変換する処理である。

続いてＣＰＵ５２は、新たに生じたイベントの種類がドラッグである旨（ドラッグイベント）と、Ｓ３２の処理によって算出されたドラッグに伴う指示点の座標情報とをＭＦＰ１０に送信する（Ｓ３４）。続いてＣＰＵ５２は、Ｓ３２によるドラッグ位置のサンプリング回数を示すドラッグイベント回数をＲＡＭ５６に記憶する処理を実行する（Ｓ３６）。この処理は、図６のＳ７２の処理の前提となる。そしてＣＰＵ５２は、Ｓ３６の処理を完了する場合、タッチパネル４６に対する新たな入力を待ち受けるべく、Ｓ１４の処理に戻る。

一方、ＣＰＵ５２は、新たに生じたイベントがドラッグイベントでもないと判断する場合（Ｓ２８：Ｎｏ）、新たに生じたイベントが離上イベントであるか否かを判断する（Ｓ３８）。そしてＣＰＵ５２は、離上イベントではないと判断する場合（Ｓ３８：Ｎｏ）、タッチパネル４６に対する新たな入力を待ち受けるべく、Ｓ１４の処理に戻る。これに対し、ＣＰＵ５２は、離上イベントであると判断する場合（Ｓ３８：Ｙｅｓ）、上記Ｓ１８の処理と同様、タッチパネル４６に対する入力イベントの受付が可能となっているか否かを判断する（Ｓ４０）。そしてＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていないと判断する場合（Ｓ４０：Ｎｏ）、タッチパネル４６に対する入力の受付が可能となった場合にこれを受け付けるべく、Ｓ１４の処理に戻る。これに対しＣＰＵ５２は、タッチパネル４６に対する入力イベントの受付が可能となっていると判断する場合（Ｓ４０：Ｙｅｓ）、離上位置変換処理を実行する（Ｓ４２）。この処理は、指示点が消失した位置、換言すれば、最後に検出した指示点の位置（押下位置またはドラッグ位置）を、図７（ａ）または図７（ｂ）に示した処理の要領で、ＬＣＤ４４の表示領域４４ａに表示された画像のサイズにかかわらず、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示された画像上の位置として特定可能な値に変換する処理である。

続いてＣＰＵ５２は、新たに生じたイベントの種類が離上である旨と、ＬＣＤ４４に表示されている画像の画面ＩＤと、Ｓ４２の処理において算出された離上位置情報（離上に伴って消失した指示点の座標情報）とを、ＭＦＰ１０に送信する（Ｓ４４）。続いてＣＰＵ５２は、イベント受付を禁止する処理を開始し（Ｓ４６）、待ち処理を実行する（Ｓ４８）。そしてＣＰＵ５２は、待ち処理が終了することで、Ｓ１０の処理と同様の処理であるＬＣＤデータ取得処理を実行（Ｓ５０）し、Ｓ１２の処理と同様の処理である付加情報取得処理を実行する（Ｓ５２）。なお、Ｓ５２の処理では画面ＩＤに加え、次画面有無情報も取得している。上記待ち処理は、離上イベントに起因してＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像が変更されるのに要する時間だけＬＣＤデータの要求信号の送信を待機するためのものである。これは、図２を用いて上述したように、本実施形態では、ＬＣＤ２０の表示領域２０ａに表示される画像が変更される場合、アニメーション表示がなされることを前提としている。

アニメーション表示がなされる期間において、携帯端末４０からＭＦＰ１０に対してＬＣＤデータが要求されてしまう場合、ＭＦＰ１０に表示されている画像と携帯端末４０に表示されている画像とが不一致となることがあり、かかる場合に入力操作を受け付けると、ＭＦＰ１０に誤動作をさせるおそれがある。すなわち、アニメーション中のＬＣＤデータが携帯端末４０に送信され、そのデータが表現する画像がＬＣＤ４４の表示領域４４ａに表示されている期間において、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像の変更が完了すると、ＭＦＰ１０においては既にタッチパネル２２への入力操作が可能となる。この時点において、携帯端末４０側で、ＬＣＤ４４の表示領域４４ａに表示された図２（ｂ）に示す画像に基づき、タッチパネル４６に対する入力操作がなされ、その指示点の座標情報がＭＦＰ１０に送信されると、ＭＦＰ１０は、ＬＣＤ２０の表示領域２０ａに表示された画像のうちのユーザの意図する箇所とは相違する箇所に対して入力操作がなされたと誤認識するおそれがある。そして、誤認識された指示点が、ＬＣＤ２０の表示領域２０ａのうち、ＭＦＰ１０により実行される処理を指示する上で指示点のあるべき箇所を示すオブジェクトに位置する場合、ＭＦＰ１０が誤動作するおそれがある。よって、図４のＳ４６，Ｓ５４の処理により、ＭＦＰ１０側でのアニメーション表示期間において、携帯端末４０のタッチパネル４６に対する入力操作を受け付けないようにしている。

ＣＰＵ５２は、Ｓ５２の処理を完了すると、イベントの受付禁止処理を解除し（Ｓ５４）、タッチパネル４６に対する新たな入力を待ち受けるべく、Ｓ１４の処理に戻る。ちなみに、この処理を、Ｓ４８の処理の終了時に実行しないのは、ＬＣＤ４４の表示領域４４ａに表示される画像が、ＬＣＤ２０の表示領域２０ａに表示されている画像に変更されることを条件に、禁止処理を解除するためである。

図９に、ＭＦＰ１０側の処理の手順を示す。この処理は、ＭＦＰ１０のＣＰＵ１２によって実行される。

ＣＰＵ１２は、携帯端末４０から送信されるイベントの種類や座標情報等の待ち受け処理を実行する（Ｓ１００）。そして、ＣＰＵ１２は、イベントが生じる場合、そのイベントが、ＬＣＤデータを要求するものであるか否かを判断する（Ｓ１０２）。そしてＣＰＵ１２は、ＬＣＤデータを要求するイベントが生じたと判断する場合（Ｓ１０２：Ｙｅｓ）、保存されたＬＣＤデータが存在するか否かを判断する（Ｓ１０４）。この処理は、上述したように、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像が、携帯端末４０のタッチパネル４６に対する入力操作とは無関係に、ＭＦＰ１０内において、ユーザに通知すべき情報が生じることで変更されることがあることに鑑みて設けられたものである。すなわち、この場合、後述するＳ１２２の処理によって、未だ携帯端末４０に送信されていない画像データがＲＡＭ１６に記憶されるため、Ｓ１０４の処理では、ＬＣＤ２０の表示領域２０ａに表示中の画像を表現する画像データとは別に、ＲＡＭ１６に記憶された画像データがあるか否かを判断する。ＣＰＵ１２は、保存されたＬＣＤデータが存在しないと判断する場合（Ｓ１０４：Ｎｏ）、ＬＣＤ２０の表示領域２０ａに表示されている画像データのＩＤである画面ＩＤを取得する（Ｓ１０６）。この処理は、図３に示した画像データマップに基づき実行することができる。続いてＣＰＵ１２は、取得された画面ＩＤを、携帯端末４０に転送する転送画面ＩＤとして、ＲＡＭ１６に記憶する（Ｓ１０８）。そしてＣＰＵ１２は、ＬＣＤデータと、付加情報としての転送画面ＩＤとを携帯端末４０に転送する（Ｓ１１０）。なお、付加情報の転送処理は、実際には、図４のＳ１２，Ｓ５２，Ｓ８４の処理によって、携帯端末４０から、ＬＣＤデータの要求とは別に、付加情報が要求されることに応じて実行される。

これに対しＣＰＵ１２は、ＬＣＤデータ取得指示イベントでないと判断する場合（Ｓ１０２：Ｎｏ）、ＬＣＤ２０の画面が遷移するイベントが生じたか否かを判断する（Ｓ１１６）。この処理は、携帯端末４０からの指示が生じないにもかかわらず、ＬＣＤ２０の画面が遷移するイベントが生じたか否かを判断するためのものである。この場合の画面遷移は、上述したようにＭＦＰ１０においてユーザに通知すべき情報が生じた場合になされるポップアップ表示等である。ここで、図３の画像データマップにおいては、ポップアップ表示がなされる場合と、ポップアップ表示がなされない場合とは互いに異なる画面ＩＤが付与されている。

ＣＰＵ１２は、画面遷移イベントが生じたと判断する場合（Ｓ１１６：Ｙｅｓ）、遷移元の画面ＩＤと、Ｓ１０８において記憶した転送画面ＩＤとが一致するか否かを判断する（Ｓ１１８）。この処理は、遷移前の画像が未だ携帯端末４０に転送されていないか否かを判断するためのものである。そしてＣＰＵ１２は、一致しないと判断する場合（Ｓ１１８：Ｎｏ）、記憶が必要な画面であるか否かを判断する（Ｓ１２０）。この処理は、図３に示した画像データマップを参照することで実行される。すなわち、記憶が必要であるか否かは、画像データマップに予め定められているため、これに基づき記憶が必要か否かを判断する。そしてＣＰＵ１２は、記憶が必要な場合（Ｓ１２０：Ｙｅｓ）、ＬＣＤデータをＲＡＭ１６に保存する（Ｓ１２２）。そしてＣＰＵ１２は、ＬＣＤデータを保存した後や、Ｓ１１８において一致すると判断する場合（Ｓ１１８：Ｙｅｓ）、さらには記憶が必要な画面ではないと判断する場合（Ｓ１２０：Ｎｏ）、画面を遷移させる処理を実行（Ｓ１２４）し、新たに生じるイベントを待ち受けるべく、Ｓ１００に処理を移行する。

ＣＰＵ１２は、上記Ｓ１０４の処理において保存されたＬＣＤデータが存在すると判断する場合（Ｓ１０４：Ｙｅｓ）、保存されたＬＣＤデータを取得する（Ｓ１１２）。次にＣＰＵ１２は、ＬＣＤデータと、付加情報とを転送し（Ｓ１１４）、新たなイベントを待ち受けるべくＳ１００の処理に戻る。ここで、付加情報には、次画像がある旨の情報が含まれる。これは、携帯端末４０に、再度、ＬＣＤデータを要求する信号を送信させるための設定である。すなわち、本実施形態では、携帯端末４０からＬＣＤデータの要求が出されることで、ＭＦＰ１０からＬＣＤデータが携帯端末４０に転送される設定となっており、要求を受信することなくＭＦＰ１０から携帯端末４０に自発的にＬＣＤデータを送信することはない。ここで、保存されたＬＣＤデータがある状況とは、Ｓ１１８において否定判断され、かつ、Ｓ１２０において肯定判断される状況であり、これは、携帯端末４０側で把握できない状況である。このため、付加情報として、次画像がある旨の情報を追加する。これにより、図８のＳ９０において、ＣＰＵ５２が肯定判断することで、Ｓ８２の処理によって、ＣＰＵ５２が再度ＬＣＤデータを要求することとなる。なお、Ｓ１１０の処理における付加情報の転送処理は、実際には、図４のＳ１２，Ｓ５２，Ｓ８４の処理によって、携帯端末４０から、ＬＣＤデータの要求とは別に、付加情報が要求されることに応じて実行される。

ＣＰＵ１２は、新たに生じたイベントが、ＬＣＤデータの要求でも本体画面の遷移でもないと判断する場合（Ｓ１１６：Ｎｏ）、押下イベントであるか否かを判断する（Ｓ１２６）。そしてＣＰＵ１２は、押下イベントであると判断する場合（Ｓ１２６：Ｙｅｓ）、イベントに付加された画面ＩＤを取得（受信）する処理を実行する（Ｓ１２８）。この処理は、図４のＳ２４の処理を前提とする。続いてＣＰＵ１２は、取得された画面ＩＤが、ＬＣＤ２０の表示領域２０ａに表示されている画像の画面ＩＤと一致するか否かを判断する（Ｓ１３２）。この処理は、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像と、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像とが一致するか否かを判断するためのものである。そしてＣＰＵ１２は、一致すると判断する場合（Ｓ１３２：Ｙｅｓ）、携帯端末４０から通知された押下イベントがＭＦＰ１０に処理を指示するものとして有効であるとして、Ｓ１３４〜Ｓ１３８の処理を実行する。すなわち、ＣＰＵ１２は、まず、必要があれば、押下位置データを変換する処理を行う（Ｓ１３４）。

続いてＣＰＵ１２は、押下位置をＲＡＭ１６に記憶する（Ｓ１３６）。この処理は、後述するＳ１６４の処理の前提となる。そしてＣＰＵ１２は、押下に伴う処理（押下処理）を実行し（Ｓ１３８）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。この処理は、たとえば押下された位置にオブジェクトがある場合、これが選択された旨の視覚表示をする処理などとなる。ただし、ＬＣＤ２０の表示領域２０ａにおいては何ら変化を生じさせず、ＭＦＰ１０の内部のみの処理であることもある。

これに対し、ＣＰＵ１２は、Ｓ１３２の処理において一致しないと判断する場合（Ｓ１３２：Ｎｏ）、画面ＩＤが一致しない旨を、携帯端末４０に通知し（Ｓ１４０）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。Ｓ１４０の処理は、図８のＳ８０の処理の前提となるものである。この場合には、押下処理（Ｓ１３８）を実行しない。これは、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像と、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像とが一致しない場合、携帯端末４０から通知された押下イベントがＭＦＰ１０に処理を指示するものとして有効ではないと考えられるからである。

ＣＰＵ１２は、新たに生じたイベントが押下イベントでもないと判断する場合（Ｓ１２６：Ｎｏ）、ドラッグ指示イベントであるか否かを判断する（Ｓ１４２）。そしてＣＰＵ１２は、ドラッグ指示イベントであると判断する場合（Ｓ１４２：Ｙｅｓ）、Ｓ１３４の処理の要領で、必要に応じて、ドラッグ位置データを変換する処理を実行する（Ｓ１４４）。続いてＣＰＵ１２は、携帯端末４０のタッチパネル４６に対するドラッグ操作に伴ってＭＦＰ１０のＬＣＤ２０にドラッグに応じた表示、例えばドラッグされた画像を移動する表示をする必要があるか否かを判断する（Ｓ１４６）。この処理は、ＭＦＰ１０のフラッシュメモリ５４等に予め必要であるか否かを定めた値を記憶しておくことで実行することができる。なお、ドラッグに応じた表示を必要とするか否かは、ＭＦＰ１０の出荷時に定められたものとしてもよいが、ユーザによって選択可能としてもよい。そしてＣＰＵ１２は、ドラッグ中の画像が必要と判断する場合（Ｓ１４６：Ｙｅｓ）、携帯端末４０のタッチパネル４６に対するドラッグ操作に伴ってＭＦＰ１０のＬＣＤ２０にドラッグに応じた表示をする（Ｓ１４８）。これに対しＣＰＵ１２は、ドラッグ中の画像が必要ではないと判断する場合（Ｓ１４６：Ｎｏ）、ドラッグに伴う現在の指示点をＲＡＭ１６に保存する処理を実行し（Ｓ１５０）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。

ＣＰＵ１２は、新たに生じたイベントがドラッグ指示イベントでもないと判断する場合（Ｓ１４２：Ｎｏ）、離上指示イベントであるか否かを判断する（Ｓ１５２）。そしてＣＰＵ１２は、離上指示イベントであると判断する場合（Ｓ１５２：Ｙｅｓ）、Ｓ１５０の処理によってドラッグに伴って押下時から変化した指示点の位置が保存されているか否かを判断する（Ｓ１５４）。ＣＰＵ１２は、上記変化する指示点の位置が保存されていると判断する場合（Ｓ１５４：Ｙｅｓ）、ＬＣＤ２０の表示領域２０ａにおける指示点の表示を、保存されている位置まで変位させる処理を実行する（Ｓ１５６）。そしてＣＰＵ１２は、この処理が完了する場合や、上記変化する指示点の位置が保存されていないと判断する場合（Ｓ１５４：Ｎｏ）、離上処理を実行し（Ｓ１５８）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。なお、離上処理は、携帯端末４０のタッチパネル４６に対する離上操作に伴ってＭＦＰ１０において実行される処理である。たとえば、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されたオブジェクト上で離上操作がなされることで、そのオブジェクトの選択が確定される場合、これに応じた視覚表示をＭＦＰ１０のＬＣＤ２０の表示領域２０ａ上で実行すればよい。

ＣＰＵ１２は、新たに生じたイベントが離上指示イベントでもないと判断する場合（Ｓ１５２：Ｎｏ）、図６のＳ７４の処理による押下取り消しイベントであるか否かを判断する（Ｓ１６０）。そしてＣＰＵ１２は、押下取り消しイベントではないと判断する場合（Ｓ１６０：Ｎｏ）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。これに対し、ＣＰＵ１２は、押下取り消しイベントであると判断する場合（Ｓ１６０：Ｙｅｓ）、押下操作後にドラッグイベントが生じたか否かを判断する（Ｓ１６２）。そしてドラッグイベントが生じたと判断する場合（Ｓ１６２：Ｙｅｓ）、ＬＣＤ２０における指示点の表示位置とこれに伴って変位しているオブジェクトの位置とを、押下位置に戻す処理を実行する（Ｓ１６４）。これは、押下操作後にドラッグ操作が続くことで押下によって選択されたオブジェクトの表示位置が変化した後、押下イベントが取り消される場合、まず表示位置を押下位置に戻すためのものである。そしてこの処理が完了する場合や、ドラッグイベントがないと判断する場合（Ｓ１６２：Ｎｏ）には、押下取り消し処理を実行し（Ｓ１６６）、新たに生じるイベントを待ち受けるべく、Ｓ１００の処理に戻る。ここで、例えば押下処理が押下されたオブジェクトが選択された旨の表示である場合、押下取り消し処理は、その視覚表示の停止を意味する。

以上説明した本実施形態によれば、以下の効果が得られるようになる。

（１）携帯端末４０のＬＣＤ４４の表示領域４４ａに、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像を表示した。これにより、ＭＦＰ１０のタッチパネル２２に対する入力操作に準じた感覚で、携帯端末４０のタッチパネル４６に対する入力操作を行うことができる。

（２）携帯端末４０のタッチパネル４６に対する入力操作に応じて定まる指示点の座標情報（図７（ａ）の（ｘ，ｙ）、または図７（ｂ）の（ｍ，ｎ））を、ＭＦＰ１０に送信した（図４のＳ２４，Ｓ３４，Ｓ４４）。これにより、携帯端末４０側では、タッチパネル４６に対する入力操作がＭＦＰ１０のいかなる処理の実行を指示するものであるのかを把握している必要がないため、タッチパネル４６に対する入力に基づきＭＦＰ１０を操作する機能に汎用性を持たせることができる。

（３）画像データに画面ＩＤを対応付け（図３）、携帯端末４０によるＬＣＤデータの受信に伴って画面ＩＤを受信するようにし、座標情報等をＭＦＰ１０に送信する際に画面ＩＤを送信した。これにより、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像と、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像とが一致しているか否かをＭＦＰ１０において把握することができる。したがって、ＭＦＰ１０では、不一致が生じた場合にこれに対処することができる。

（４）携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像と、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像とが不一致であると判断される場合（Ｓ１３２：Ｎｏ）、携帯端末４０側において、ＬＣＤデータを要求した（Ｓ８２）。これにより、不一致となっている事態を解消することができる。

（５）携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像と、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像とが不一致であると判断される場合（Ｓ１３２：Ｎｏ）、ＭＦＰ１０からＬＣＤデータを受信して表示を更新するとともに、不一致に伴って画像を更新している旨を表示した（Ｓ８６）。これにより、ユーザに、事態を把握させることができる。

（６）画面ＩＤを含む付加情報と、ＬＣＤデータとを各別に要求し、受信するようにした。これにより、ＭＦＰ１０から送信されるＬＣＤデータ（例えばＰＤＦデータ）に他のデータが付与されていない状態でこれを変換する処理（例えばＪＰＥＧに変換する処理）を行うことができることから、付加情報とＬＣＤデータとが合成されている場合と比較して、変換する処理を容易に行うことができる。

（７）ＬＣＤデータを要求してからこれを受信し、その表現する画像をＬＣＤ４４の表示領域４４ａに表示するまでは、タッチパネル４６に対する入力操作を受け付けないようにした（図４のＳ１０の処理の後にＳ１４を設けた点、Ｓ４６〜Ｓ５４、Ｓ２６の処理の終了に伴ってＳ１４の処理に移行する点）。このため、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示されている画像と、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像とが不一致である期間において、タッチパネル４６の入力操作を受け付けないこととなり、ＭＦＰ１０がユーザの意図する指示とは相違する指示を誤って認識する事態が生じることを好適に回避することができる。

（８）付加情報に、次画像の有無の情報を含めた。これにより、携帯端末４０側からの要求があることを条件にＭＦＰ１０側から携帯端末４０側にＬＣＤデータを送信する設定において、携帯端末４０側からＬＣＤデータを適切に要求することができる。

（９）携帯端末４０からＬＣＤデータの送信が要求されることを、ＭＦＰ１０がＬＣＤデータを携帯端末４０に送信する条件にした。これにより、ＭＦＰ１０から携帯端末４０へＬＣＤデータを送信するタイミングを、携帯端末４０がＬＣＤデータを必要とするタイミングとすることができる。また、ＭＦＰ１０と通信する携帯端末４０が複数ある場合であっても、ＬＣＤデータを必要とする携帯端末４０に適切にＬＣＤデータを送信することが可能となる。

（１０）ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示されている画像の画像データが未だ携帯端末４０に送信されていない状態で、画面が遷移することを条件に、遷移する前の画像を表現する画像データをＲＡＭ１６に記憶した（Ｓ１２２）。これにより、遷移する前の画像の画像データを携帯端末４０に送信することが可能となる。

（１１）携帯端末４０のタッチパネル４６に対する離上操作がなされ、入力イベントの種類として離上操作がＭＦＰ１０に送信されるに際し、ＬＣＤデータの送信を要求した（図４のＳ５０）。ここで、離上操作は、画像上の位置の選択を確定させる操作であり、これによりＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像は変化する傾向にある。このため、ＬＣＤデータを適切なタイミングで要求することができる。

（１２）携帯端末４０のタッチパネル４６に対する離上操作がなされることに応じてＬＣＤデータの送信を要求するに先立って、所定期間待機した（図４のＳ４８）。これにより、ＭＦＰ１０側において画像の入れ替えが完了する前に、携帯端末４０からのＬＣＤデータの送信要求に応じてＬＣＤデータが携帯端末４０に送信される事態を回避することができる。

（１３）携帯端末４０からＭＦＰ１０に送信する座標情報（図７（ａ）の（ｘ，ｙ）、図７（ｂ）の（ｍ，ｎ））に、ＬＣＤ４４の表示領域４４ａに表示されている画像が拡大または縮小されているか否かにかかわらず、画像が規定のサイズである場合における指示点の位置を特定するための規格化情報を含めた。このため、ＬＣＤ４４の表示領域４４ａに表示されている画像が拡大または縮小されているか否かにかかわらず、ＭＦＰ１０では、携帯端末４０のタッチパネル４６に対する入力操作がいかなる処理の実行を指示するものであるのかを把握することができる。

（１４）携帯端末４０からＭＦＰ１０に送信する座標情報を、規格化情報と一体化された情報とした。これにより、携帯端末４０からＭＦＰ１０に送信する座標情報をシンプルな情報とすることができる。

（１５）携帯端末４０のＬＣＤ４４の表示領域４４ａに対する指示点の数が複数となる場合、ＭＦＰ１０に入力イベントの種類や座標情報の送信を行わないこととした（図６のＳ６２のＹｅｓの場合の設定）。これにより、ＭＦＰ１０に不要な情報が送信される事態を回避することができる。

（１６）押下イベントの検出後、その離上イベントの発生前に再度他の押下イベントが生じる場合、ＭＦＰ１０に押下イベントの取り消しイベントを転送した（図６のＳ７４）。これにより、携帯端末４０のタッチパネル４６に対する入力操作が拡大または縮小処理を指示するものである場合、入力イベントについての誤った情報がＭＦＰ１０に反映される事態を回避することができる。

（１７）押下イベントの取り消しイベントを転送した（図６のＳ７４）後の離上イベントを、ＭＦＰ１０に転送しないようにした（図６のＳ６６，Ｓ６８の設定）。これにより、ＭＦＰ１０に不要な入力イベント情報が送信される事態を回避することができる。

（１８）押下取り消しイベントを受信する場合、取り消し処理を実行した（図９のＳ１６６）。これにより、ＭＦＰ１０から送信された入力イベントの種類等が後に不適切であると判明した場合であっても、これに対処することができる。

（１９）押下取り消しイベントを受信する場合であって、且つ取り消し対象の押下イベントの後にドラッグイベントが生じている場合、指示点を押下イベントがなされた際の位置に戻す処理を行った（図９のＳ１６４）。これにより、ＭＦＰ１０のＬＣＤ２０において、ドラッグにより移動したオブジェクトを元の位置に戻すことができる。このため、押下取り消し処理（Ｓ１６６）がなされた時点において、オブジェクトを押下イベント前の位置に表示することができる。

＜第２の実施形態＞
以下、第２の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

上記第１の実施形態では、ＭＦＰ１０のＬＣＤ２０に表示される画像が変更されるに際しアニメーション表示がなされることに鑑み、携帯端末４０側での離上イベントに伴って待ち処理（図４のＳ４８）を設けた。これに対し、本実施形態では、携帯端末４０からＭＦＰ１０にＬＣＤデータが要求された際に、ＭＦＰ１０側においてアニメーション表示を行う場合、アニメーション表示が完了するまで、ＭＦＰ１０から携帯端末４０へのＬＣＤデータの転送処理を実行しない。

図１０に、本実施形態にかかるＭＦＰ１０側の処理の手順のうち、図９に示した処理に対する変更点を示す。この処理は、ＭＦＰ１０のＣＰＵ１２によって実行される。

ＣＰＵ１２は、Ｓ１０４の処理において、保存されたＬＣＤデータが存在しないと判断する場合（Ｓ１０４：Ｎｏ）、ＬＣＤ２０の表示領域２０ａに表示される画像を変更するに際してのアニメーション表示中であるか否かを判断する（Ｓ１７０）。そしてＣＰＵ１２は、アニメーション表示中ではないと判断する場合（Ｓ１７０：Ｎｏ）、Ｓ１０６の処理に移行する。これに対し、ＣＰＵ１２は、アニメーション表示中であると判断する場合（Ｓ１７０：Ｙｅｓ）、アニメーション表示中である旨を示すアニメーション通知を携帯端末４０に送信する（Ｓ１７２）。続いてＣＰＵ１２は、アニメーション表示が終了するまで待機する（Ｓ１７６）。そして、ＣＰＵ１２は、アニメーション表示が終了したと判断する場合（Ｓ１７６：Ｙｅｓ）、携帯端末４０にその旨を通知し（Ｓ１７８）、Ｓ１０６の処理に移行する。

図１１に、携帯端末４０側の処理の手順を示す。この処理は、ＣＰＵ５２によって、フラッシュメモリ５４に記憶された遠隔操作プログラムが実行されることで実現される。なお、図１１において、図４に示した処理に対応するものについては、便宜上同一のステップ番号を付している。

本実施形態では、ＣＰＵ５２は、Ｓ１２の処理が完了する場合、ＭＦＰ１０からアニメーション通知がなされているときであるか否かを判断する（Ｓ１８０）。この処理は、図１０のＳ１７２，Ｓ１７８の処理を前提とする。そしてＣＰＵ５２は、アニメーション通知がなされていないと判断する場合（Ｓ１８０：Ｎｏ）、Ｓ１４の処理に移行する。これに対しＣＰＵ５２は、アニメーション通知がなされていると判断する場合（Ｓ１８０：Ｙｅｓ）、タッチパネル４６に対する入力操作の受付（イベント受付）を禁止し、その旨をＬＣＤ４４の表示領域４４ａに表示して（Ｓ１８２）、処理をＳ１８４に移行する。なお、Ｓ１８２では、タッチパネル４６に対する入力操作の受付を禁止しなくても、入力操作は受け付け、受け付けた入力操作に対応した処理を実行しないように構成されてもよい。Ｓ１８４において、ＣＰＵ５２は、ＭＦＰ１０からアニメーション終了通知を受信するまで待機し（Ｓ１８４：Ｎｏ）、アニメーション終了通知を受信すると（Ｓ１８４：Ｙｅｓ）、処理をＳ１０に移行する。

なお、本実施形態では、Ｓ１８，Ｓ３０，４０において否定判断される場合や、Ｓ２６，Ｓ３６，Ｓ５２の処理が完了する場合にも、Ｓ１８０の処理に移行する。

以上説明した本実施形態によれば、上記第１の実施形態の上記（１）〜（４），（７）〜（１９）の効果に加えて、さらに以下の効果が得られるようになる。

（２０）ＭＦＰ１０からＬＣＤデータが要求される場合、アニメーション表示が終了するまで、ＬＣＤデータの送信を待機した（図１０のＳ１７４）。これにより、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像と、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示される画像とが不一致となる状態の継続時間を極力短くすることができる。

（２１）ＭＦＰ１０からアニメーション中であるとの通知を受信すると、携帯端末４０では、タッチパネル４６に対する入力操作を受け付けないようにした。これにより、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像と、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示される画像とが不一致となる状態において、タッチパネル４６に対する入力操作が受け付けられなくなることから、ＭＦＰ１０にユーザの意図に反した指示がなされる事態を回避することができる。

＜第３の実施形態＞
以下、第３の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

上記第１の実施形態では、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａにおいて画像の変更に伴うアニメーション表示がなされる場合であっても、携帯端末４０のＬＣＤ４４の表示領域４４ａにおいてはアニメーション表示を行わなかった。これに対し、本実施形態では、携帯端末４０のＬＣＤ４４の表示領域４４ａにおいても、上記アニメーション表示を実行する。

図１２に、本実施形態にかかるＭＦＰ１０側の処理の手順を示す。この処理は、ＭＦＰ１０のＣＰＵ１２によって実行される。なお、図１２において、図９に示した処理に対応するものについては、便宜上同一のステップ番号を付している。

図示されるように、本実施形態では、ＣＰＵ１２は、Ｓ１０４の処理において、保存されたＬＣＤデータが存在しないと判断する場合（Ｓ１０４：Ｎｏ）、ＬＣＤ２０の表示領域２０ａに表示される画像の変更に伴うアニメーション表示中かを判断する（Ｓ１７０）。そしてＣＰＵ１２は、アニメーション表示中ではないと判断する場合（Ｓ１７０：Ｎｏ）、Ｓ１０６の処理に移行する。これに対し、ＣＰＵ１２は、アニメーション表示中であると判断する場合（１７０：Ｙｅｓ）、アニメーション表示中である旨を示すアニメーション通知を携帯端末４０に送信する（Ｓ１９０）。

図１３に、携帯端末４０側の処理の手順を示す。この処理は、ＣＰＵ５２によって、フラッシュメモリ５４に記憶された遠隔操作プログラムが実行されることで実現される。なお、図１３において、図４に示した処理に対応するものについては、便宜上同一のステップ番号を付している。

本実施形態では、ＣＰＵ５２は、Ｓ５２の処理が完了する場合、アニメーション通知がなされたか否かを判断する（Ｓ２００）。この処理は、図１２のＳ１９０の処理を前提とする。そしてＣＰＵ５２は、アニメーション通知がなされていないと判断する場合（Ｓ２００：Ｎｏ）、Ｓ５４の処理に移行する。これに対しＣＰＵ５２は、アニメーション通知がなされたと判断する場合（Ｓ２００：Ｙｅｓ）、Ｓ５０の処理に戻ることで、再度ＬＣＤデータの取得処理を実行する。

以上説明した本実施形態によれば、上記第１の実施形態の上記（１）〜（４），（７）〜（１９）の効果に加えて、さらに以下の効果が得られるようになる。

（２２）ＭＦＰ１０のＬＣＤ２０の表示領域２０ａにアニメーション表示がなされている場合、携帯端末４０側からＬＣＤデータを再度要求するようにした。これにより、携帯端末４０のＬＣＤ４４の表示領域４４ａにおいてもアニメーション表示を行うことができる。

＜第４の実施形態＞
以下、第４の実施形態について、先の第１の実施形態との相違点を中心に図面を参照しつつ説明する。

本実施形態では、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａにおけるアニメーション表示として、処理の進行度合いを表示するプログレスバー表示を実行する。図１４は、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに、印刷処理の進行度合いを示すプログレスバー７０が表示された例を示している。プログレスバー７０は、印刷処理の進行度合いを表示すべく、印刷処理の進行度合いに応じて、その表示を変化させるものであり、図１４においては、図１４（ｂ）の方が図１４（ａ）よりも印刷処理が進行している状態であることを表示する例が示されている。なお、携帯端末４０のＬＣＤ４４の表示領域４４ａ上でも、印刷処理の進行度合いに応じてプログレスバー７０の表示を変更するためには、付加情報にプログレスバー７０を表示する旨の情報が含まれる場合、図４のＳ５４の処理の後、携帯端末４０からＭＦＰ１０に周期的にＬＣＤデータを要求するようにすればよい。

ＭＦＰ１０のＬＣＤ２０の表示領域２０ａには、印刷処理が完了する前において、印刷処理をキャンセルするキャンセルボタン７２が表示される。このため、ＬＣＤデータの取得処理によって、携帯端末４０のＬＣＤ４４の表示領域４４ａにおいても、キャンセルボタン７２が表示される。そして、携帯端末４０のタッチパネル４６に対する入力操作によって、キャンセルボタン７２が押下、離上されることで、ＭＦＰ１０において、印刷処理を中止する。これにより、携帯端末４０から印刷処理をキャンセルするように指示することができる。

＜第５の実施形態＞
以下、第５の実施形態について、先の第２の実施形態との相違点を中心に説明する。

第２の実施形態では、ＭＦＰ１０側においてアニメーション表示を行う場合、アニメーション表示が完了するまで、携帯端末４０は、ＭＦＰ１０に対しタッチパネルイベントを送信しない構成とされていたが、第５の実施形態では、特定のアニメーションの場合に限り、タッチパネルイベントを送信する構成とする。

具体的には、第２実施形態を示す図１１のＳ１８０において、ＣＰＵ５２は、アニメーション通知がなされていると判断された場合（Ｓ１８０：Ｙｅｓ）、Ｓ１２で取得した付加情報に基づき、ＭＦＰ側で表示されているアニメーションの種類が上述した図１４に示すプログレスバーであると判断する場合には、処理をＳ１４に移行し、アニメーションがプログレスバーではないと判断される場合には、処理をＳ１８２に移行する。なお、ＭＦＰ１０は、携帯端末４０に送信する付加情報に、ＭＦＰ１０側で表示しているアニメーションの種類を特定する情報を含める。

＜各手段等と実施形態との対応＞
表示部（端末側表示部）…ＬＣＤ４４、装置側表示部…ＬＣＤ２０，入力部（端末側入力部）…タッチパネル４６、装置側入力部…タッチパネル２２，通信部…通信部４２、制御部…ＣＰＵ５２、処理装置…ＭＦＰ１０、記憶部…ＲＡＭ１６、送信要求手段…Ｓ１０，Ｓ５０，Ｓ８２、画像受信手段…Ｓ１０，Ｓ５０，Ｓ８２、表示制御手段…Ｓ１０，Ｓ５０，Ｓ８２、入力情報送信手段…Ｓ２４，Ｓ３４，Ｓ４４、変位通知受信手段…Ｓ２００、変位通知手段…Ｓ１８２、Ｓ１９０、要求受信手段…Ｓ１０２、画像送信手段…Ｓ１１０、入力情報受信手段…Ｓ１００、実行手段…Ｓ１３８，Ｓ１４８，Ｓ１５８、待機手段…Ｓ１７４、
入力イベントとしての画像上の位置の選択…押下操作
入力イベントとしての画像上の位置の確定…離上操作
変更後の画像に徐々に入れ替える機能…図２
進行度合いのアニメーション表示…図１４。

＜その他の実施形態＞
以上、上記実施形態に基づき本発明を説明したが、本発明は上記形態に何ら限定されるものではなく、本発明の趣旨を逸脱しない範囲内で種々の変形改良が可能であることは容易に推察できるものである。各実施形態は、それぞれ、他の実施形態が有する構成の一部または複数部分を、その実施形態に追加し或いはその実施形態の構成の一部または複数部分と交換等することにより、その実施形態を変形して構成するようにしてもよい。以下、上記実施形態の変形例としての実施形態を記載する。

携帯端末４０からＭＦＰ１０に画面ＩＤを送信するタイミングとしては、押下イベントに伴って、座標情報等が送信されるとき（Ｓ２４）に限らない。例えば、所定の周期で定期的に携帯端末４０からＭＦＰ１０に画面ＩＤを送信するようにしてもよい。

図２においては、画面自体が変更される際に、ＭＦＰ１０により実行される処理を指示する上で指示点のあるべき箇所を示すオブジェクトが表示領域において変位することに鑑み、画面自体が変更される際に、携帯端末４０のタッチパネル４６に対する入力操作を受け付けないようにしたが、これに限らない。例えば、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示される画像全体が変更されるのではなく、ＭＦＰ１０により実行される処理を指示する上で指示点のあるべき箇所を示すオブジェクトのみが変位する場合に、携帯端末４０のタッチパネル４６に対する入力操作を受け付けないようにしてもよい。

ＬＣＤデータの要求と、付加情報の要求とを携帯端末４０からＭＦＰ１０に各別に出すものに限らず、例えばＬＣＤデータを要求することで、ＭＦＰ１０からＬＣＤデータと対応する付加情報とが送信される設定であってもよい。

図４のＳ４６，Ｓ５４の処理では、ＭＦＰ１０側でのアニメーション表示期間において、携帯端末４０のタッチパネル４６に対する入力操作を受け付けないようにしたが、これに限らない。例えば、入力操作に応じてＬＣＤ４４の表示領域４４ａの表示を変更し、且つ、入力操作を無効とする旨をＬＣＤ４４の表示領域４４ａにさらに表示し、入力操作に関する入力イベントおよび座標情報のＭＦＰ１０への送信を行わないようにしてもよい。

図４の処理では、Ｓ４８の待ち処理がなされている期間等において、タッチパネル４６に対する入力操作を受け付けないこととしたが、この期間であっても、画面の拡大を指示するためのピンチアウト操作のように、ＭＦＰ１０に対する指示に無関係な入力操作については受け付けるようにしてもよい。

図７（ｂ）の手法においては、基準点を描画開始座標（Ｘ，Ｙ）とし、所定点を描画終了座標（Ｘｅ，Ｙｅ）として、基準点から所定点までの各座標成分の長さを画像が規定のサイズである場合における指示点の位置を特定するための規格化情報として用いるものに限らない。例えば、画像のＸ軸方向における中点の座標成分とＹ軸方向における中点の座標成分とによって、所定点を設定してもよい。この場合であっても、基準点から所定点までの各座標成分の長さを画像が規定のサイズである場合における指示点の位置を特定するための規格化情報として用いることができる。

携帯端末４０からＭＦＰ１０に送信する座標情報としては、画像が拡大または縮小されているか否かにかかわらず、画像が規定のサイズである場合における指示点の位置を特定するための規格化情報（図７（ａ）の拡大率ｋ、図７（ｂ）の（Ｘｅ−Ｙ，Ｙｅ−Ｙ））と一体となったものに限らない。例えば、図７（ａ）に代えて、描画開始座標を原点とする座標成分（Ａ−Ｘ，Ｂ−Ｙ）と、規格化情報としての拡大率ｋとを、ＭＦＰ１０に各別に送信してもよい。この場合であっても、ＭＦＰ１０では、画像が規定のサイズである場合における指示点の位置を特定することができる。また、携帯端末４０からＭＦＰ１０に送信される情報としては、規格化情報を含むものに限らない。すなわち、携帯端末４０上において拡大、縮小処理を行わないなら、これを含まなくても、ＭＦＰ１０において、画像が規定のサイズである場合における指示点の位置を特定することができる。

ＭＦＰ１０にＬＣＤデータを要求する手段としては、タッチパネル４６に対する離上操作をトリガとするものに限らない。例えば、タッチパネル４６に対する押下操作をトリガとしてもよい。

ＭＦＰ１０にＬＣＤデータを要求する手法としては、タッチパネル４６に対する入力イベントをトリガとするものに限らない。例えば、所定の時間周期でＬＣＤデータを要求するものであってもよい。この際、携帯端末４０からＭＦＰ１０に画面ＩＤをさらに送信し、ＭＦＰ１０は、携帯端末４０のＬＣＤ４４の表示領域４４ａに表示された画像の画面ＩＤと、ＭＦＰ１０のＬＣＤ２０の表示領域２０ａに表示された画像の画面ＩＤとが不一致であることを条件にＬＣＤデータを携帯端末４０に転送してもよい。

ＭＦＰ１０としては、ＬＣＤ２０およびタッチパネル２２を備えるものに限らない。これらを備えないものであっても、携帯端末４０に、タッチパネル４６に対する入力操作を案内する画像を表現する画像データを送信するなら、携帯端末４０のタッチパネル４６に対する入力操作に応じてＭＦＰ１０を操作することができる。なお、この場合、ＭＦＰ１０は、ＬＣＤ２０の表示領域２０ａに表示される画像を設定することはできないものの、ＭＦＰ１０内で受付可能な操作を案内する画像を設定するようにするなら、画面ＩＤの照合を行う図９のＳ１２８〜Ｓ１４０の処理等を実行することもできる。なお、この場合、画面ＩＤの照合によって不一致と判断される事態として、例えば、携帯端末４０や、ＭＦＰ１０、または携帯端末４０およびＭＦＰ１０間の通信に、ノイズが混入する場合や、携帯端末４０が一時的な電力不足に陥って誤動作が生じる場合等が考えられる。

入力部（端末側入力部、装置側入力部）としては、タッチパネル２２，４６に限らない。例えば、ＬＣＤ２０，４４に対する押下、離上、ドラッグ操作等を画像認識により検出する装置であってもよい。

携帯端末４０によってＭＦＰ１０を操作する際における携帯端末４０とＭＦＰ１０との通信手法としては、Ｗｉ−Ｆｉ通信に限らない。例えば、電話網通信部５０を用いた通信であってもよい。

携帯端末４０を用いた操作対象（処理装置）としては、ＭＦＰ１０に限らない。例えば、住宅に備えられた住宅のエネルギ管理装置を操作してもよい。この場合、電話網通信部５０を用いるなら、住宅から遠く離れた土地からユーザが帰宅に先立って空調装置等を起動させたり、太陽光パネルの発電エネルギを湯を沸かすことに優先して使用する指示を出したりすることも可能となる。そしてこの際、エネルギ管理装置自体がタッチパネルを備える場合、出先から、住宅内におけるタッチパネル操作に準じた操作によって、指示を出すことが可能となる。

通信端末としては、スマートフォンのように、電話網を介した通話の機能等、ＭＦＰ１０などの処理装置の操作に関する機能以外の機能を有するものに限らず、処理装置の操作に特化した端末であってもよい。

上記実施形態において、ＣＰＵ５２が操作支援プログラムを実行することで実現される処理（ソフトウェア処理）の一部または全てを、ＡＳＩＣ等によるハードウェア処理に変更してもよい。

請求項１の「処理装置により実行される処理」としては、コピー機能を実行する処理や、ファクシミリ機能を実行する処理、スキャナ機能を実行する処理など、各機能を実行する処理のほか、画面の入れ替え処理なども該当する。例えば、図２（ａ）の画面において、Ｆａｘアイコンが選択された場合に、図２（ｃ）の画面（画像）に切り替える処理も該当する。

１０…ＭＦＰ，４０…携帯端末。

Claims (14)

1. 表示領域を有する表示部と、該表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する入力部と、処理装置と通信する通信部と、制御部とを備える通信端末によって実行されて且つ、前記入力部に対する入力に基づき前記処理装置を操作するための操作支援プログラムにおいて、
   前記処理装置により実行される処理を指示するための前記入力媒体による入力操作を案内する画像について、該画像を表現する画像データの送信を前記処理装置に要求する送信要求手段と、
   該送信要求手段による要求に応じて送信される前記画像データを受信する画像受信手段と、
   前記受信された画像データにより表現される画像を前記表示領域に表示する表示制御手段と、
   前記表示制御手段により前記画像が表示されている状態において前記入力部によって検出された前記表示領域上の指示点の座標情報、および該入力部に対する入力イベントの種類を前記処理装置に送信する入力情報送信手段と、を前記制御部に実行させることを特徴とする操作支援プログラム。
2. 前記送信要求手段は、前記入力情報送信手段の送信処理が実行されることを条件に、前記画像データの送信を要求することを特徴とする請求項１記載の操作支援プログラム。
3. 前記入力情報送信手段が送信する入力イベントの種類には、前記表示領域に表示される画像上の位置の選択、および該選択の確定が含まれ、
   前記送信要求手段は、前記入力情報送信手段によって前記選択が確定される旨の入力イベントが送信されることを条件に、前記画像データの送信を要求することを特徴とする請求項２記載の操作支援プログラム。
4. 前記表示部は、端末側表示部であり、
   前記入力部は、端末側入力部であり、
   前記処理装置は、表示領域を有する装置側表示部と、該装置側表示部の表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する装置側入力部とを備え、
   前記画像データにより表現される画像は、前記装置側表示部の表示領域に表示されるものであり、
   前記処理装置は、前記装置側表示部の表示領域に表示される画像を変更する場合、変更前の画像から変更後の画像に徐々に入れ替える機能を有し、
   前記送信要求手段は、前記入力情報送信手段によって前記選択が確定される旨の入力イベントが送信される場合、前記画像データの送信を要求するに先立ち、所定期間待機することを特徴とする請求項３記載の操作支援プログラム。
5. 前記入力情報送信手段は、前記所定期間内に生じた入力イベントについて、その種類を送信しないことを特徴とする請求項４記載の操作支援プログラム。
6. 前記表示部は、端末側表示部であり、
   前記入力部は、端末側入力部であり、
   前記処理装置は、表示領域を有する装置側表示部と、該装置側表示部の表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する装置側入力部とを備え、
   前記画像データにより表現される画像は、前記装置側表示部の表示領域に表示されるものであり、
   前記処理装置から、前記装置側表示部の表示領域に表示される画像内のオブジェクトが変位する旨を受信する変位通知受信手段を前記制御部に実行させ、
   前記送信要求手段は、前記画像受信手段が前記画像データを受信する際に前記変位通知受信手段が前記変位を含む旨を受信することを条件に、前記画像データの送信を要求することを特徴とする請求項１または２記載の操作支援プログラム。
7. 前記入力情報送信手段は、前記入力部に対する入力操作をトリガとして、前記送信処理を実行するものであって且つ、前記変位通知受信手段が前記変位を含む旨を受信することを条件に、前記処理装置への送信処理を実行しないことを特徴とする請求項６記載の操作支援プログラム。
8. 前記入力情報送信手段は、前記端末側表示部の表示領域に表示される画像内のオブジェクトであって且つ、前記処理装置により実行される処理を指示するうえで前記指示点のあるべき箇所を示すオブジェクトが変位する場合、前記送信処理を実行しないことを特徴とする請求項７記載の操作支援プログラム。
9. 前記入力情報送信手段は、前記装置側表示部の表示領域に表示される画像内の変位するオブジェクトとして、前記処理装置が実行する処理の進行度合いを示すアニメーションが当該表示領域に表示される場合、前記処理装置への送信処理を実行しうることを特徴とする請求項７または８記載の操作支援プログラム。
10. 前記変位通知受信手段が前記変位を含む旨を受信することを条件に、その旨を前記端末側表示部の表示領域に表示する変位通知手段を前記制御部に実行させることを特徴とする請求項６から９のいずれか１項に記載の操作支援プログラム。
11. 表示領域を有する表示部と、該表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する入力部と、処理装置と通信する通信部と、制御部とを備える通信端末であって、
    請求項１から１０のいずれか１項に記載の操作支援プログラムによって前記制御部が実行する対象となる各手段を、ソフトウェア処理およびハードウェア処理の少なくとも一方によって実現される手段として備えていることを特徴とする通信端末。
12. 表示領域を有する表示部と、該表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する入力部と、通信部と、制御部とを備える通信端末の前記入力部に対する入力に基づき操作される処理装置において、
    前記処理装置により実行される処理を指示するための前記入力媒体による入力操作を案内する画像について、該画像を表現する画像データの送信要求を前記通信端末から受信する要求受信手段と、
    前記要求受信手段によって前記送信要求を受信することを条件に、前記画像データを前記通信端末に送信する画像送信手段と、
    前記入力部によって検出された前記表示領域上の指示点の座標情報、および該入力部に対する入力イベントの種類を前記通信端末から受信する入力情報受信手段と、
    前記入力情報受信手段によって受信された座標情報と前記入力イベントの種類とを入力とし、前記座標情報および前記入力イベントに応じた処理を実行する実行手段とを備えることを特徴とする処理装置。
13. 前記表示部は、端末側表示部であり、
    前記入力部は、端末側入力部であり、
    表示領域を有する装置側表示部と、
    前記装置側表示部の表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する装置側入力部とを備え、
    前記装置側表示部の表示領域に表示される画像には、該画像内のオブジェクトの変位を含むものが含まれ、
    前記画像送信手段は、前記要求受信手段によって前記送信要求を受信することを条件に、前記装置側表示部の表示領域に表示中の画像を表現する画像データを前記通信端末に送信するものであって且つ、前記装置側表示部の表示領域に表示される画像内のオブジェクトが変位していることを条件に、前記要求受信手段によって前記送信要求を受信した場合であっても、前記変位が完了するまで待機する待機手段を備え、変位が完了することで、完了時の画像を表現する画像データを前記通信端末に送信することを特徴とする請求項１２記載の処理装置。
14. 前記表示部は、端末側表示部であり、
    前記入力部は、端末側入力部であり、
    表示領域を有する装置側表示部と、
    前記装置側表示部の表示領域上の点であって且つ、入力媒体によって指示された点である指示点を検出する装置側入力部とを備え、
    前記装置側表示部の表示領域に表示される画像には、該画像内のオブジェクトの変位を含むものが含まれ、
    前記画像送信手段は、前記要求受信手段によって前記送信要求を受信することを条件に、前記装置側表示部の表示領域に表示中の画像を表現する画像データを前記通信端末に送信するものであり、
    前記装置側表示部の表示領域に表示中の画像がアニメーションを含むことを条件に、前記通信端末にその旨を通知する変位通知手段を備えることを特徴とする請求項１２記載の処理装置。
    
    

Images