JP2019102985A - 画像形成装置、プログラム及び情報処理装置 - Google Patents

Abstract

【課題】従来のＭＦＰは、端末に表示される操作画面が遷移する度に生成したＵＩデータを端末に送信するため、端末により操作画面が表示されている間、電源状態を通常状態に維持しなければならなかった。【解決手段】ＭＦＰ１００は、端末２００から要求されたＵＩデータに関連するＵＩデータを事前送信するかの要否を判定し、必要と判定した場合には、端末２００に事前送信する旨を通知する。ＭＦＰ１００は、端末２００に事前送信するＵＩデータを生成及び送信する。そしてＭＦＰ１００は、ＵＩデータを端末２００に事前送信した後、電源状態を省電力状態に移行する。【選択図】図４

Description

本発明は、画像形成装置、プログラム及び情報処理装置に関する。

従来から、印刷（Print）機能、複写（Copy）機能及び読み取り（Scan）機能等を有する複合型の画像形成装置が広く普及している。この画像形成装置は、複合機としてＭＦＰ（Multi Functional Peripherals）とも呼ばれる。

昨今、ユーザによる地球環境問題への関心に後押しされ、ＭＦＰを取り巻く環境規制は年々厳しさを増している。ＭＦＰを取り巻く環境規制は、Energy Star（登録商標）等を基準として定められる。Energy Star（登録商標）は、日本、米国のほか、ＥＵ（European Union）等の国及び地域が協力し、電気機器の省電力化プログラムを実施するための国際的な制度である。

ＭＦＰは、印刷物が出力されるまでの待ち時間を短くするために、用紙に形成したトナー画像を定着させる定着器を一定温度に保持する等の制御を行っており、通常状態での電力消費が大きい。そこで、通常、一定時間使用しない状態が続いた場合に、ＭＦＰを待機状態から待機状態よりも消費電力が少ない省電力状態（スリープ状態とも呼ばれる）に移行させ、消費電力の低下を図っている。

一方、近年、タブレット、スマートフォン等の携帯端末の普及に伴って、ＭＦＰには、有線ネットワークのみならず、無線ネットワークへの対応が進められている。つまり、ＭＦＰは、省電力状態時に、ネットワークを介して印刷要求を常時受け付け可能であることが求められている。

さらに、Ｗｅｂ（World Wide Web）ベースのＵＩ（User Interface）表示、すなわち、ＷｅｂＵＩを採用すると、携帯端末からＭＦＰにＷｅｂアクセスする頻度が増えることが想定される。

また、ＭＦＰに、単一的な業務をクラウド化するための機能（例えば、経費精算システム）を持たせることもできる。ユーザは、プリント、コピー及びスキャンの利用だけでなく、ＭＦＰを介し、会計、給与等の単一的な業務をクラウド化する頻度が増える。このような背景から、ＭＦＰは、印刷物の出力がない間、ＣＰＵ／メモリ及びネットワーク機能等の電源を落とした省電力状態であっても、携帯端末等からの要求を受け付ける必要がある。

特許文献１には、例えば、モバイルデバイスのある場所への到着の検出に応答して、モバイルデバイス上での１つ又は複数のアプリケーション及び/又は機能の実行と関連するコンピュータ可読命令をプリフェッチする技術が開示されている。この技術は、ユーザによって開始される入力又は選択イベントを伴わずにコンピュータ可読命令を実行し、アプリケーション及び/又は機能をアクティブにすることができる。

特許文献２には、通信管理部により検出された、コネクション上でのセッションの開始及び終了の検出結果に応じて、通信デバイスへの給電を制御する電源管理部を備えた通信端末に関する技術が開示されている。

特許文献３には、サブ機の制御部は、親機に代理応答を依頼する際に、自装置の無線ネットワーク及び有線ネットワークのアドレス情報と装置情報とを親機に送信した後、自装置の動作状態を省電力状態に移行させ、親機から復帰要求を受信したら、自装置の動作状態を省電力状態から待機状態に移行させる技術が開示されている。

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

ところで、特許文献１に開示された技術は、モバイルデバイスの状況に応じて、モバイルデバイス側からサーバ等に対して、ユーザが必要とするアプリケーション又は機能を事前に要求、取得する処理である。しかし、モバイルデバイス毎にＭＦＰへＷｅｂアクセスし、その都度、モバイルデバイスがＭＦＰに対してアプリケーション又は機能を要求、取得していたのでは、ＭＦＰの省電力状態を維持することができない。

特許文献２に開示された技術は、携帯端末の通信コネクション状況に応じて、電源の制御を行っている。しかし、ＭＦＰが、携帯端末からの要求に応じる度にデータを転送していたのでは、ＭＦＰの省電力状態を維持することができない。

特許文献３に開示された技術は、省電力状態のＭＦＰに代わり別のＭＦＰが代理応答する処理である。代理応答をするためには、事前に代理応答するためのデータを、別のＭＦＰが保持しておく必要がある。しかし、端末に操作画面を表示するための画面データはデータサイズが大きい。このようなデータサイズが大きい画面データの全パターンを、親機に事前に保持させると、親機のデータ保存領域が圧迫されてしまう。さらに、代理応答を依頼可能な親機となるＭＦＰがない状況においては特許文献３に開示された技術を実現することができない。

本発明はこのような状況に鑑みて成されたものであり、端末からのアクセスが多い状況であっても、画像形成装置をできるだけ省電力状態に保つことを目的とする。

本発明に係る画像形成装置は、自装置の電源状態を制御する電源制御部と、自装置に対する操作が行われる端末に対してネットワーク通信を行うネットワーク部と、端末に表示される操作画面を構成するための画面データを生成する画面データ生成部と、画面データをネットワーク通信で端末へ送信する画面データ送信部と、端末から取得要求された画面データを事前送信するか否かの判定を行い、事前送信が必要と判定した場合には、端末に画面データを事前送信する旨を通知し、事前送信する画面データの生成を画面データ生成部に指示し、画面データ生成部により生成された画面データの事前送信を画面データ送信部に指示すると共に、電源状態を省電力状態に移行可能であることを電源制御部に通知することにより、電源制御部に電源状態を省電力状態に移行させる画面データ送信制御部と、を備える。

本発明によれば、画像形成装置は端末から要求された画面データをまとめて端末に事前送信するため、従来のように端末からのアクセスに備えて通常状態を維持する必要がなくなる。これにより、画像形成装置は、端末に画面データを事前送信した後、直ちに省電力状態に移行することができる。
上記した以外の課題、構成及び効果は、以下の実施の形態の説明により明らかにされる。

本発明の第１の実施の形態に係る通信システムの全体構成例を示すブロック図である。 本発明の第１の実施の形態に係るＭＦＰの内部構成例を示すブロック図である。 従来の通信システムの動作例を示すシーケンス図である。 本発明の第１の実施の形態に係る通信システムの動作例を示すシーケンス図である。 本発明の第１の実施の形態に係るＭＦＰが端末にトップ画面を送信する際の動作例を示すシーケンス図である。 本発明の第１の実施の形態に係るＭＦＰの処理例を示すフローチャートである。 本発明の第１の実施の形態に係る事前送信ＵＩデータ決定テーブルの構成例を示すテーブル図である。 図６のステップＳ３５に示した事前送信ＵＩデータ生成及び送信の処理例を示すフローチャートである。 本発明の第１の実施の形態に係るＵＩデータに設定されるリンク情報の例を示す説明図である。 本発明の第２の実施の形態に係る通信システムの全体構成例を示すブロック図である。 本発明の第２の実施の形態に係る情報処理装置の内部構成例を示すブロック図である。 本発明の第２の実施の形態に係る通信システムの動作例を示すシーケンス図である。

以下、本発明を実施するための形態例について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。

＜通信システムの全体構成例＞
図１は、通信システム１０の全体構成例を示すブロック図である。
通信システム１０は、ＭＦＰ１００、端末２００及びＡＰ（Access Point）３００を備える。

図１では、３台のＭＦＰ１００と、２台の端末２００を設けた構成を示しているが、ＭＦＰ１００と端末２００の数は任意に設定することができるものである。例えば、ＭＦＰ１００を１台又は複数台設けてもよいし、端末２００を１台又は複数台設けてもよい。
ＭＦＰ１００とＡＰ３００は、有線ネットワークに接続されている。端末２００は、ＡＰ３００を通じてＭＦＰ１００にアクセス可能である。

ＭＦＰ１００は、用紙に印刷する印刷機能、複数の原稿を順次搬送するための原稿搬送機能、ＵＩデータ（画面データの一例）を端末２００に送信するための通信機能、搬送された原稿の画像を読取る画像読取機能等の複数の機能を有する、いわゆる複合機として用いられる。このＭＦＰ１００は、通常状態と省電力状態の２つの状態で動作することができる。通常状態とは、各機能への給電が行われ、印刷等の指示が行われると直ちに処理を開始可能な状態をいう。また、省電力状態とは、スリープ状態とも呼ばれ、ＭＦＰ１００の最低限の機能のみに給電した状態をいう。ＭＦＰ１００は、例えば、有線Ｉ／Ｆ（Inter Face）を通して端末２００等から操作画面の取得要求が行われると、各機能に電力を供給して省電力状態から通常状態に移行する。

端末２００は、例えば、タブレット端末やスマートフォン、ノートコンピュータ装置（ノートＰＣ）等の携帯端末である。ただし、端末２００を、デスクトップコンピュータ装置などの据え置き型のＰＣ（Personal Computer）としてもよい。

端末２００には、ＭＦＰ１００に対して各種の設定を行うための複数の階層構造を有する操作画面が表示される。この操作画面は、ＭＦＰ１００から送信されるＵＩデータに基づいて表示される。階層構造とは、複数の操作画面を段階的に含む構造である。ユーザが端末２００に表示される操作画面のボタンを操作することで次画面が表示される場合に、端末２００に最初に表示される操作画面を１階層目、次画面を２階層目と呼ぶ。例えば、Scanメニュー設定画面が１階層目、１階層目にあるボタンを押下し、遷移した画面（スキャンしたデータの格納先を指定する画面等）を２階層目と呼ぶ。また、ＭＦＰ１００にジョブの開始を指示するボタンがある画面を最下層と呼ぶ。ただし、Copyメニュー設定画面のように、１階層だけで構成され、遷移可能な次画面がない場合には、Copyメニュー設定画面自体にコピーの開始を指示するボタンが設けられる。

ＡＰ３００は、無線ＬＡＮ（Local Area Network）等の無線ネットワークにより端末２００に接続される。端末２００は、ＡＰ３００に無線ネットワークで接続されることで、有線ネットワークに接続された各々のＭＦＰ１００とのデータ通信を行うことが可能となる。

＜ＭＦＰの内部構成例を示すブロック図＞
図２は、ＭＦＰ１００の内部構成例を示すブロック図である。
ＭＦＰ１００は、ＵＩ生成部１００ａ、ＵＩ送信部１００ｂ、ＵＩ送信制御部１００ｃ、記憶部１００ｄ、ＭＦＰ制御部１００ｅ、電源制御部１００ｆ及びネットワーク部１００ｇを備える。

ＵＩ生成部１００ａは、画面データ生成部の一例であり、端末２００で表示可能な操作画面等を構成するためのＵＩデータを生成する。また、ＵＩ生成部１００ａは、端末２００に表示される操作画面の操作により遷移する画面を特定するためのリンク情報を、端末２００で参照可能なリンク情報に変更したＵＩデータを生成する。ただし、ＵＩ生成部１００ａは、操作画面の操作により自装置に対して実行指示が行われるリンク情報を変更せず、又は階層構造とした操作画面の下層に含まれるリンク情報を変更しない。

ＵＩ送信部１００ｂは、画面データ送信部の一例であり、ＵＩ生成部１００ａで生成されたＵＩデータを、ネットワーク部１００ｇを経由するネットワーク通信で端末２００へ送信する。

ＵＩ送信制御部１００ｃは、画面データ送信制御部の一例であり、端末２００から取得要求されたＵＩデータを事前送信するか否かの判定を行い、事前送信が必要と判定した場合には、端末２００にＵＩデータを事前送信する旨を通知する。そして、事前送信するＵＩデータの生成をＵＩ生成部１００ａに指示する。

また、ＵＩ送信制御部１００ｃは、ＵＩ生成部１００ａにより生成されたＵＩデータの事前送信をＵＩ送信部１００ｂに指示すると共に、電源状態を省電力状態に移行可能であることを電源制御部１００ｆに通知する。これにより、ＵＩ送信制御部１００ｃは、電源制御部１００ｆを省電力状態に移行させる。
なお、ＵＩ送信制御部１００ｃは、端末２００から要求されたＵＩデータの種別に応じて、ＵＩ送信部１００ｂに事前送信させるか否かを判定することも可能である。

このようにＵＩ送信制御部１００ｃは、従来のように端末２００からのＵＩデータ要求が行われる度に逐次ＵＩデータを送信するのではなく、端末２００からのＵＩデータ要求に対して必要なＵＩデータをまとめて事前送信する機能を有する。また、事前送信する旨の通知を端末２００に送信する。これにより、ユーザが端末２００に事前送信されたＵＩデータを操作している間、ＭＦＰ１００は省電力状態に移行することができる。

また、ＵＩ送信制御部１００ｃは、端末２００に表示される操作画面を通じて要求される機能に関連し、かつ、端末２００により操作される頻度が高いＵＩデータの事前送信をＵＩ送信部１００ｂに指示する。例えば、一般的なユーザが操作画面を操作する際に用いる機能をＭＦＰ１００に実行させるために、端末２００に表示された操作画面から遷移する次画面のＵＩデータが事前送信される。ここで、操作画面を操作する際に、管理者が設定するメニュー画面は、一般的なユーザが使用する操作画面に比べて使用頻度が低い。このため、管理者設定等のメニュー画面のＵＩデータは、事前送信しなくても操作性に影響が生じない。

記憶部１００ｄは、ＨＤＤ（Hard Disk Drive）等で構成され、ＵＩデータ等のプログラムや印刷データ、ネットワークアドレス情報や装置情報、画像形成処理した画像データ等を記憶する。つまり、記憶部１００ｄは、ＵＩ送信部１００ｂにより事前送信されたＵＩデータ、及びＵＩデータの送信先の端末２００、及び端末２００からのアクセス状態を記憶することが可能である。

ＭＦＰ制御部１００ｅは、原稿画像を複写する複写機能（Copy）、画像原稿を読み取る読み取り機能（Scan）、通信回線を介して画像データを送受信するファクシミリ機能（Fax）及び外部Ｉ／Ｆを介して外部装置から供給される画像データに基づいて印刷する印刷機能（Print）を有する。

電源制御部１００ｆは、ＭＦＰ１００（自装置）の電源状態を制御する。電源制御部１００ｆは、ＭＦＰ１００に供給される電源を制御することにより、電源状態を、通常状態又は、通常状態より消費電力の低い省電力状態のいずれかに移行させる。省電力状態には複数の状態があるため、電源制御部１００ｆにより移行される省電力状態は、複数の状態から選択される一つの状態となる。

ネットワーク部１００ｇは、ＮＩＣ（Network Interface Card）やモデムなどで構成され、自装置に対する操作が行われる端末２００に対してネットワーク通信を行う。そして、このネットワーク部１００ｇにより、有線ネットワーク及び無線ネットワークを介して、端末２００にＵＩデータを送信したり、端末２００からの指示を受信したりするデータ通信が可能である。

＜通信システムの動作例＞
次に、従来の通信システムの動作例と、本実施の形態に係る通信システム１０におけるＵＩデータの送信に係る動作例について、図３と図４を参照して説明する。
図３は、従来の通信システムの動作例を示すシーケンス図である。

従来のＭＦＰは、端末に対して無線通信することが可能である。ＭＦＰでPrint等を実行する場合は、無線ネットワークで繋がっている端末からＡＰ経由でＭＦＰにPrint要求を送ってPrintを指示する。このデータのやり取りは、例えば、ＴＣＰ（Transmission Control Protocol）で行われる。

始めに、端末は、省電力状態ＳＴ１であるＭＦＰに対して、データ転送を依頼するための接続要求（ＳＹＮパケット）を送る（Ｓ１）。
端末から接続要求を受信したＭＦＰは起床状態ＳＴ２となる。そして、ＭＦＰは、端末にＡＣＫパケット（確認応答）を送って端末からの接続を許可し（Ｓ２）、接続を許可した端末との間でセッションを確立する。

次に、端末とＭＦＰは、ＵＩデータの送受信を開始する。例えば、端末は、起床状態ＳＴ２であるＭＦＰへScan設定を行うためのScanメニュー画面を表示可能なＵＩデータを要求する（Ｓ３）。ＭＦＰは、要求されたＵＩデータを端末に送信する（Ｓ４）。

端末がＵＩデータを要求する処理（Ｓ３）と、ＭＦＰがＵＩデータを送信する処理（Ｓ４）の１回分のやりとりは、端末に１ページ分のScanメニュー画面を表示するために行われる。ここで、Scanメニュー画面には、他の画面に遷移するためのボタン等が含まれる。例えば、端末を操作するユーザが、そのボタンを押下した場合、端末は、ボタンに設定されるリンク情報に基づいて端末に表示される次画面のＵＩデータをＭＦＰに要求することになる（Ｓ３）。ＭＦＰは、要求された次画面のＵＩデータを端末へ送信する（Ｓ４）。端末がＵＩデータを要求する処理（Ｓ３）と、ＭＦＰがＵＩデータを送信する処理（Ｓ４）は、例えば、最下層を除く階層まで繰り返し行われる。

Scan設定が終わり、端末がＵＩデータを要求する処理（Ｓ３）がなくなると、端末からＭＦＰへセッションの切断要求が行われる（Ｓ５）。ＭＦＰは、切断要求を受けると、端末にＡＣＫパケット（確認応答）を送り（Ｓ６）、セッションを切断する。その後、ＭＦＰは、省電力状態ＳＴ３へ移行する。

このように従来の通信システムでは、端末に表示される画面毎にＵＩデータの要求及び送信が行われていた。このため、端末からＵＩデータの要求が行われるタイミングは不定であるため、ＭＦＰは、すぐにＵＩデータを送信できるように通常状態を維持しなければならなかった。

図４は、本発明の第１の実施の形態である通信システム１０の動作例を示すシーケンス図である。
図３における従来の通信システムの動作例と同様に、本発明の第１の実施の形態の端末２００も、省電力状態ＳＴ１であるＭＦＰ１００に対して、接続要求を行う（Ｓ１１）。そして、ＭＦＰ１００を起床状態ＳＴ２とした後、ＭＦＰ１００からＡＣＫパケット（確認応答）を受信することで、セッションが確立される（Ｓ１２）。

また、端末２００は、起床状態ＳＴ２であるＭＦＰ１００へScan設定を行うためのScanメニュー画面を表示可能なＵＩデータを要求する（Ｓ１３）。ＭＦＰ１００は、要求されたＵＩデータを端末に送信する（Ｓ１４）。端末２００とＭＦＰ１００がセッションを確立した後、ＭＦＰ１００は、端末２００に事前送信するＵＩデータを生成する状態ＳＴ４に変わる。

ＭＦＰ１００が事前送信するＵＩデータには、例えば、Scanメニュー画面から遷移可能な画面を端末２００に表示するためのＵＩデータが含まれる。事前送信するＵＩデータのデータ量は、図３に示した従来の端末に送信されるＵＩデータよりも多い。このため、ＵＩ送信制御部１００ｃは、ＵＩデータを事前送信することを端末２００に通知する（Ｓ１５）。この通知を受けた端末２００は、端末２００内の記憶領域を確保する。

そして、ＭＦＰ１００は、端末２００に通知をした後、ＵＩデータを端末２００に事前送信する（Ｓ１６）。端末２００は、ＭＦＰ１００から事前送信されたＵＩデータを端末２００内の記憶領域に保存する。

ＭＦＰ１００が事前送信するＵＩデータに含まれるリンク情報は、端末２００がネットワーク部１００ｇを通じてＭＦＰ１００と通信することなく次画面に遷移できるように、ＵＩ送信制御部１００ｃにより、端末２００内で参照できるリンク情報に変更されている。このため、端末２００は、端末２００内の記憶領域に保存した、ＭＦＰ１００により事前送信されたＵＩデータを参照するだけで、例えば、Scanメニュー画面から遷移する次画面を表示することができる。ＭＦＰ１００から端末２００にＵＩデータが事前送信された後は、端末２００がＭＦＰ１００に対して動作の実行指示を行うまで、ＭＦＰ１００が通常状態を維持する必要はない。

このため、ステップＳ１６の後、端末２００からＭＦＰ１００へセッションの切断要求が行われる（Ｓ１７）。ＭＦＰ１００は、切断要求を受けると、端末にＡＣＫパケット（確認応答）を送り、セッションを切断する（Ｓ１８）。その後、ＭＦＰは、省電力状態ＳＴ３へ移行する。
このように、図４に示した端末２００とＭＦＰ１００の処理は、ＵＩデータが事前送信されるため、図３に示した従来の端末とＭＦＰの処理に比べて、ＭＦＰ１００が省電力状態ＳＴ３に移行するまでの時間が早くなる。

＜端末とＭＦＰ間の通信システム（トップ画面がある場合）の動作例＞
次に、端末に表示される操作画面にトップ画面がある場合における端末とＭＦＰの動作例を説明する。
トップ画面とは、端末２００を操作するユーザが、ＭＦＰ１００に対してPrint、Copy、Scan等の実行指示を行うための操作画面に遷移する前の画面をいう。トップ画面は、ユーザが所属する組織毎に仕様が異なっていてもよい。例えば、トップ画面には、ユーザが所属する組織のロゴマークが表示されてもよい。ここでは、従来の通信システムの動作例の説明を省略する。

図５は、ＭＦＰ１００が端末２００にトップ画面を送信する際の動作例を示すシーケンス図である。図５に示す動作例では、図４に示したステップＳ１２，Ｓ１３の間に、トップ画面のＵＩデータの要求及び送信の処理を追加している。

図５に示すステップＳ１１，Ｓ１２の処理は、図４にて説明したとおりである。そして、ＭＦＰ１００が起床し、端末２００との間でセッションを確立した後、端末２００はＭＦＰ１００に対して、トップ画面のＵＩデータの送信を要求する（Ｓ１９）。ＭＦＰ１００は、端末２００に表示可能なトップ画面のＵＩデータを生成し、このＵＩデータを端末２００に送信する（Ｓ２０）。これにより、端末２００にはトップ画面が表示される。

トップ画面には、Copy設定、Scan設定及び管理者設定等のメニュー画面に遷移するためのボタンが表示される。端末２００を操作するユーザは、いずれかのボタンを選択することで、ＭＦＰ１００に対して設定を行うことができる。ユーザがボタンを押したタイミングで、端末２００は、起床状態ＳＴ２であるＭＦＰ１００へScan設定を行うためのScanメニュー画面を表示可能なＵＩデータを要求する（Ｓ１３）。ＭＦＰ１００は、要求されたＵＩデータを端末に送信する（Ｓ１４）。これにより、端末２００にScanメニュー画面が表示される。そして、図４と同じようにステップＳ１５以降の処理が行われる。

トップ画面から遷移するメニュー画面には、様々な種類があり、ユーザがどのメニューを選択するかが不明であることが多い。このため、ＭＦＰ１００は、端末２００に対して、メニュー画面のＵＩデータの送信前にトップ画面のＵＩデータを送信するようにしている。しかし、ユーザが選択する可能性のあるメニューに合わせて、トップ画面と共に、全てのメニュー画面に関連するＵＩデータが端末２００に事前送信されると、有線ネットワークの通信帯域が不足するばかりか、端末２００の記憶領域も不足してしまう。
そこで、端末２００がトップ画面のＵＩデータを要求した場合、ＭＦＰ１００は、トップ画面だけのＵＩデータを端末２００に送信する。その後、端末２００に表示されるトップ画面から選択されたボタンに基づいて、ＭＦＰ１００は、メニュー画面のＵＩデータをまとめて事前送信する。これにより、有線ネットワークの通信帯域、及び端末２００の記憶領域の不足を回避することができる。

＜ＭＦＰの処理例＞
図６は、本発明の第１の実施の形態に係るＭＦＰ１００の処理例を示すフローチャートである。
以下、端末２００がＭＦＰ１００にＷｅｂアクセスし、ＭＦＰ１００へＵＩデータの取得を要求した場合に、ＵＩ送信制御部１００ｃが端末２００に事前送信するＵＩデータの処理について説明する。

まず、ＵＩ送信制御部１００ｃは、ＭＦＰ１００が省電力状態であるか否かを判定する（Ｓ３１）。ＭＦＰ１００が省電力状態であると判定すると（Ｓ３１のＹｅｓ）、ＵＩ送信制御部１００ｃは、ＭＦＰ１００の省電力状態を解除する（Ｓ３２）。その後、ＵＩ送信制御部１００ｃは、ＭＦＰ１００の接続元を確認する（Ｓ３３）。

ＵＩ送信制御部１００ｃは、ＭＦＰ１００の接続元がＭＦＰ１００又は端末２００のいずれであるかを判定する（Ｓ３４）。ステップＳ３３、Ｓ３４により、ＵＩ送信制御部１００ｃは、接続元からデバイス種別に関する情報を取得し、接続元のデバイス種別に応じてＵＩデータの接続元に対する事前送信の要否を切替える。

接続元が端末２００であると判定した場合（Ｓ３４の端末）、ＵＩ送信制御部１００ｃは、ＵＩ生成部１００ａに対して、端末２００に事前送信するＵＩデータを生成するよう指示し、生成したＵＩデータを送信するようＵＩ送信部１００ｂに指示する。そして、ＵＩ送信制御部１００ｃは、ＵＩ生成部１００ａにより生成されたＵＩデータが、ＵＩ送信部１００ｂにより、ネットワーク部１００ｇを経て端末２００に送信されたことを確認した後、端末２００とのセッション接続を切断する（Ｓ３５）。ステップＳ３５の詳細な処理は、図８にて後述する。

次に、ＵＩ送信制御部１００ｃは、事前送信したＵＩデータ、及び送信先の端末２００を記憶部１００ｄに記憶する（Ｓ３６）。その後、ＵＩ送信制御部１００ｃは、電源制御部１００ｆに省電力状態に移行するように指示する制御を行い（Ｓ３７）、本処理を終了する。そして、ＭＦＰ１００は、電源制御部１００ｆにより省電力状態に移行する。

一方、ステップＳ３４にて、接続元がＭＦＰ１００であると判定した場合（Ｓ３４のＭＦＰ）、ＵＩ送信制御部１００ｃは、接続元のＭＦＰ１００が操作画面を表示可能か否かを判定する（Ｓ３８）。この判定は、接続元のＭＦＰ１００に対して必ずしもＵＩデータを送信しなくてよい場合を考慮して行われる。例えば、接続元のＭＦＰ１００自体がトップ画面、メニュー画面の画面データを記憶しており、トップ画面、メニュー画面を表示可能であれば、ＵＩ送信部１００ｂが接続元のＭＦＰ１００に対してＵＩデータを送信する必要はない。

ＵＩ送信制御部１００ｃは、接続元のＭＦＰ１００が操作画面を表示できると判定した場合（Ｓ３８のＹｅｓ）、接続元のＭＦＰ１００がＵＩデータの表示を行うように指示し（Ｓ３９）、ステップＳ３７に進む。このため、ＵＩ送信部１００ｂは、接続元のＭＦＰ１００にＵＩデータを送信しない。その後、上述したステップＳ３７以降の処理が行われる。

ＵＩ送信制御部１００ｃは、接続元のＭＦＰ１００が操作画面を表示できないと判定した場合（Ｓ３８のＮｏ）、ステップＳ３５に進む。その後、上述したステップＳ３５以降の処理が行われる。

また、ステップＳ３１にて、省電力状態ではないと判定した場合（Ｓ３１のＮｏ）、ＵＩ送信制御部１００ｃは、記憶部１００ｄを参照し、ＵＩデータを事前送信済みの端末２００があるか否かを判定する（Ｓ４０）。事前送信されたＵＩデータを受信した端末２００がない場合（Ｓ４０のＮｏ）、本処理を終了する。
一方、ＵＩデータを事前送信済みの端末２００がある場合（Ｓ４０のＹｅｓ）、ＵＩ送信制御部１００ｃは、端末２００の操作状態を取得する（Ｓ４１）。

次に、ＵＩ送信制御部１００ｃは、ＭＦＰ１００が省電力状態の期間に、ＵＩ生成部１００ａがＵＩデータを更新したことにより、端末２００に事前送信済みのＵＩデータと差異が生じているか否かの判定をする（Ｓ４２）。

ＵＩ送信制御部１００ｃは、ＵＩ生成部１００ａがＵＩデータを更新したことで、端末２００に記憶されている事前送信済みのＵＩデータと差異が発生したと判定した場合（Ｓ４２のＹｅｓ）、ＵＩ生成部１００ａに事前送信済みのＵＩデータを更新するための更新データを生成させ、この更新データを端末２００に送信する（Ｓ４３）。このとき、ＵＩ送信制御部１００ｃは、端末２００に対して事前送信済みのＵＩデータの破棄要求も送信して、本処理を終了する。

一方、ＵＩ送信制御部１００ｃは、端末２００に記憶されている事前送信済みのＵＩデータと差異が発生していないと判定した場合（Ｓ４２のＮｏ）、端末２００に対して事前送信済みのＵＩデータを更新する必要はないので、このまま本処理を終了する。

＜事前送信ＵＩデータ生成及び送信の処理例＞
次に、ＵＩ送信制御部１００ｃが事前送信するＵＩデータを決定し、ＵＩ送信部１００ｂにＵＩデータを事前送信させる処理の詳細について説明する。
ＭＦＰ１００は、端末２００から要求されるメニュー画面に応じて、ＵＩデータの事前送信の要否を判断することが可能である。

例えば、端末２００からCopyメニュー画面のＵＩデータが要求された場合、端末２００からＭＦＰ１００に対して、すぐにコピー実行を要求される可能性が高い。
このとき、ＭＦＰ１００に設けられる不図示の定着部は、ウォーミングアップに時間がかかる。そこで、ＭＦＰ１００は、端末２００にCopyメニュー画面のＵＩデータを送信した後、すぐに定着部のウォーミングアップを開始する。

これにより、端末２００からコピー実行を要求されると、ＭＦＰ１００は、即座にコピーを実行することができる。このため、端末２００を操作するユーザは、Copyメニュー画面によりコピーの実行開始を指示した後、ＭＦＰ１００が実際にコピーを実行開始するまでの時間を待たなくて良くなる。このようにＵＩ送信制御部１００ｃは、ユーザの利便性を優先してＵＩデータの事前送信を行わない制御が可能である。

一方、端末２００から要求されるメニュー画面が管理者メニュー画面であれば、ＭＦＰ１００に対して設定変更だけを行う可能性が高い。このため、ＵＩ送信制御部１００ｃが端末２００にメニュー画面のＵＩデータを事前送信することにより、ＭＦＰ１００は、端末２００から設定変更が指示されるまで通常状態を維持しなくてよい。
このため、電源制御部１００ｆが速やかに省電力状態に移行することができる。ＭＦＰ１００は、端末２００から設定変更の指示を受けたときに起床し、設定変更を行えばよい。

このようにＵＩ送信制御部１００ｃが、ＵＩデータの事前送信の要否を決定する際に参照する事前送信ＵＩデータ決定テーブル５００の構成例について、図７を参照して説明する。
図７は、事前送信ＵＩデータ決定テーブル５００の構成例を示すテーブルである。

事前送信ＵＩデータ決定テーブル５００は、例えば、記憶部１００ｄに記憶されるテーブルである。事前送信ＵＩデータ決定テーブル５００は、ＵＩデータ要求項目フィールド、事前送信ＵＩデータの有無フィールド、及び事前送信するＵＩデータの階層数フィールドを備える。

ＵＩデータ要求項目フィールドには、端末２００からＭＦＰ１００に対してＵＩデータの取得要求が行われるときのメニュー画面を特定する情報が格納される。メニュー画面を特定する情報は、画面名称、画面識別子等で表されるが、ここでは、Copyメニュー、Scanメニュー、FaXメニュー及び管理者メニューのように画面名称で表される。

事前送信するＵＩデータの有無フィールドには、ＭＦＰ１００が端末２００に事前送信するＵＩデータの有無を示す情報が格納される。
事前送信するＵＩデータの階層数フィールドには、メニュー画面から遷移する次画面以降の階層数を示す情報が格納される。

ＵＩデータ要求項目フィールドのCopyメニューには、コピーの実行指示以外に遷移する次画面がないため、事前送信するＵＩデータの有無フィールドに「なし」と格納され、事前送信するＵＩデータの階層数フィールドに「０」と格納される。
一方、ＵＩデータ要求項目フィールドのScanメニュー、FaXメニュー、管理者メニューは、ボタン操作により次画面以降に遷移する。このため、いずれのメニューに対しても、事前送信するＵＩデータの有無フィールドに「あり」と格納される。また、事前送信するＵＩデータの階層数フィールドには、Scanメニューに対して「３」、FaXメニューに対して「３」、管理者メニューに対して「４」が格納される。

なお、事前送信ＵＩデータの階層数フィールドには、最下層は含まれない。操作画面の最下層は、通常のＵＩデータのリンク情報となるよう事前送信するＵＩデータに設定されている。したがって、ＵＩデータの最下層は、通常のＵＩデータのリンク情報のままとなり、ＵＩデータのリンク情報にアクセスした場合、端末２００はネットワーク部１００ｇと通信する。

次に、事前送信ＵＩデータ決定テーブル５００を参照して行われるＵＩデータの事前送信の要否を判定する処理について、図８を参照して説明する。
図８は、図６のステップＳ３５に示した事前送信するＵＩデータを生成し、送信する処理の詳細な例を示すフローチャートである。
上述したようにＵＩ送信制御部１００ｃは、端末２００から要求されたＵＩデータの種別（例えば、Copy設定、Scan設定、管理者設定等）に応じて、事前送信するＵＩデータの送信の実行要否を切替える。

このため、ＵＩ送信制御部１００ｃは、事前送信ＵＩデータ決定テーブル５００を参照し、事前送信するＵＩデータを決定し（Ｓ５１）、ＵＩ生成部１００ａが事前送信ＵＩデータを生成できたか否かを判定する（Ｓ５２）。

ＵＩ生成部１００ａが事前送信するＵＩデータを生成できたと判定した場合（Ｓ５２のＹｅｓ）、ＵＩ送信制御部１００ｃは、ＵＩデータを端末２００へ事前送信し、端末２００とのセッションを切断して（Ｓ５５）本処理を終了する。

また、ＵＩ生成部１００ａが事前送信ＵＩデータを生成できなかったと判定した場合（Ｓ５２のＮｏ）、ＵＩ送信制御部１００ｃは、事前送信ＵＩデータのメニュー画面のみをＵＩ生成部１００ａに生成させる（Ｓ５３）。そして、ＵＩ送信制御部１００ｃは、最下層を除くリンク情報を端末２００内の記憶領域に保存されたリンク情報を参照するようにＵＩデータを編集する（Ｓ５４）。

その後、ステップＳ５２にて事前送信するＵＩデータを生成できたと判定されると（Ｓ５２のＹｅｓ）、ＵＩ送信制御部１００ｃは、ＵＩデータを端末２００へ事前送信し、端末２００とのセッションを切断して（Ｓ５５）本処理を終了する。

＜リンク情報の変更例＞
図９は、ＵＩデータに設定されるリンク情報の例を示す説明図である。
図９Ａは、端末２００による画面遷移毎に、ＭＦＰ１００にアクセスしてＵＩデータを取得する場合にＵＩデータに設定されるリンク情報の例を示す。
このＵＩデータには、例えば、端末２００がＭＦＰ１００に格納されるｈｔｍファイルにＷｅｂアクセスするためのリンク情報が設定されている。
このリンク情報は、例えば、
「<a href=“http://konicaminolta.com/link.htm”>」と表される。

図９Ｂは、端末２００に事前送信されたＵＩデータに設定されるリンク情報の例を示す。
このＵＩデータには、例えば、端末２００の記憶領域に保存されたｈｔｍファイルを参照するように変更されたリンク情報が設定されている。
このリンク情報は、例えば、
「<a href=“link.htm”>」と表される。

以上説明した第１の実施の形態に係る通信システム１０では、端末２００が、省電力状態であるＭＦＰ１００にＷｅｂアクセスした場合、ＭＦＰ１００は、端末２００が操作するメニュー画面に合わせて、メニュー画面に関連する一まとまりのＵＩデータを生成し、端末２００にＵＩデータを事前送信する。このため、ＭＦＰ１００は、従来のように端末２００からのアクセスに備えて通常状態を維持する必要がなくなる。また、ＭＦＰ１００は、端末２００に画面データを事前送信した後、セッションを切断し、直ちに省電力状態に移行する。このように、端末２００上でＭＦＰ１００への操作又は設定を行っている間、ＭＦＰ１００は省電力状態に戻ることができ、省電力効果を高められる。

端末２００に事前送信されるＵＩデータは、端末２００から要求される機能に関連するものであり、かつ端末２００により操作される頻度が高いものである。このため、端末２００を操作するユーザは、端末２００がＵＩデータを受信したことで表示する操作画面を操作して、目的とする機能を速やかに実行することができる。

＜第１の実施の形態の変形例＞
なお、ＵＩデータの事前送信には様々な方法が考えられる。
例えば、ＵＩ送信制御部１００ｃは、端末２００からＭＦＰ１００（自装置）に対するアクセスが事前にあり、かつ、ＭＦＰ１００が省電力状態から起床した場合には、端末２００に事前送信したＵＩデータに対する追加送信の要否を確認し、端末２００から追加送信が必要と確認されたＵＩデータを追加送信する。これにより、起床状態であるＭＦＰ１００は、事前送信したＵＩデータだけでは不足する場合に、必要なＵＩデータを端末２００に追加送信することができる。

また、ＵＩ送信制御部１００ｃは、他の端末２００からＭＦＰ１００（自装置）に対するアクセスが事前にあり、かつ、ＭＦＰ１００が省電力状態から起床した場合には、端末２００内で参照可能に変更されたリンク情報を、Ｗｅｂアクセス可能なリンク情報に戻す。そして、ＵＩ送信制御部１００ｃは、端末２００内で参照可能に変更されたリンク情報を、Ｗｅｂアクセス可能なリンク情報に戻す旨を端末２００に通知すると共に、Ｗｅｂアクセス可能なリンク情報を端末２００に送信する。これにより、起床状態であるＭＦＰ１００は、従来のように端末２００からのＷｅｂアクセスに応じてＵＩデータを端末２００に送信することができる。

また、ＵＩ送信制御部１００ｃは、ステップＳ３で、端末２００から受信する、事前送信するＵＩデータの制限に関する情報に合わせて変更したＵＩデータをＵＩ送信部１００ｂに事前送信させてもよい。例えば、端末２００の記憶領域が逼迫している場合に、ＵＩ送信制御部１００ｃは、階層数を減らしたＵＩデータを事前送信したり、ＵＩデータの事前送信を中止したりすることができる。

＜第２の実施形態に係る通信システムの全体構成例＞
次に、本発明の第２の実施の形態に係る通信システムについて、図１０〜図１２を参照して説明する。
図１０は、通信システム１０Ａの全体構成例を示すブロック図である。
通信システム１０Ａは、ＭＦＰ１００、端末２００、ＡＰ３００、及び情報処理装置４００を備える。情報処理装置４００は、ＭＦＰ１００及びＡＰ３００が接続される有線ネットワークに接続されている。このため、ＭＦＰ１００は、情報処理装置４００にアクセス可能である。そして、通信システム１０Ａは、情報処理装置４００をサーバとし、ＭＦＰ１００をクライアントとするサーバクライアント構成としている。

情報処理装置４００は、例えば、サーバ装置であり、ＵＩデータを送受信するための通信機能、各種情報を記憶する記憶機能等を有する。情報処理装置４００は、ＭＦＰ１００が画像形成機能のみを有している場合に、ＭＦＰ１００の代わりにＵＩデータを生成し、ＭＦＰ１００にＵＩデータを事前送信することができる。

＜本発明の第２の実施の形態に係る情報処理装置の内部構成例＞
図１１は、情報処理装置４００の内部構成例を示すブロック図である。
この情報処理装置４００は、ＵＩ生成部４００ａ、ＵＩ送信部４００ｂ、ＵＩ送信制御部４００ｃ、記憶部４００ｄ、電源制御部４００ｆ及びネットワーク部４００ｇを備える。情報処理装置４００が備える各部の機能は、上述した図２に示したＭＦＰ１００が備える各部の機能と同様である。以下に、情報処理装置４００が備える各機能ブロックの主要な機能及び動作例について説明する。

ＵＩ生成部４００ａは、情報処理装置４００にアクセスしているＭＦＰ１００が表示可能な操作画面等を構成するためのＵＩデータを生成する。また、ＵＩ生成部４００ａは、ＭＦＰ１００に表示される操作画面の操作により遷移する画面を特定するためのリンク情報を、ＭＦＰ１００で参照可能なリンク情報に変更したＵＩデータを生成する。

ＵＩ送信部４００ｂは、ＵＩ生成部４００ａで生成されたＵＩデータをネットワーク部４００ｇを経由するネットワーク通信でＭＦＰ１００へ送信する。

ＵＩ送信制御部４００ｃは、ＭＦＰ１００から取得要求されたＵＩデータを事前送信するか否かの判定を行う。そして、ＵＩ送信制御部４００ｃは、事前送信が必要と判定した場合には、ＭＦＰ１００にＵＩデータを事前送信する旨を通知し、事前送信するＵＩデータの生成をＵＩ生成部４００ａに指示する。また、ＵＩ送信制御部４００ｃは、ＵＩ生成部４００ａにより生成されたＵＩデータの事前送信をＵＩ送信部４００ｂに指示すると共に、電源状態を省電力状態に移行可能であることを電源制御部４００ｆに通知することにより、電源制御部４００ｆに電源状態を省電力状態に移行させる。

記憶部４００ｄは、ＵＩ送信部４００ｂにより事前送信されたＵＩデータ、及びＵＩデータの送信先のＭＦＰ１００、及びＭＦＰ１００からのアクセス状態を記憶することが可能である。

電源制御部４００ｆは、情報処理装置４００（自装置）の電源状態を制御する。電源制御部１００ｆは、情報処理装置４００に供給される電源を制御することにより、電源状態を、通常状態又は通常状態より消費電力の低い省電力状態のいずれかに移行させる。

ネットワーク部４００ｇは、ＮＩＣやモデムなどで構成され、情報処理装置４００（自装置）に対する操作が行われるＭＦＰ１００に対してネットワーク通信を行う。このネットワーク部４００ｇは、有線ネットワークを介して、ＭＦＰ１００にＵＩデータを送信したり、ＭＦＰ１００からの指示を受信したりするデータ通信が可能である。

＜ＭＦＰと情報処理装置間の通信システムの動作例＞
図１２は、通信システム１０Ａの動作例を示すシーケンス図である。本発明の第２の実施の形態では、情報処理装置４００は、操作画面を表示できるＭＦＰ１００に対してＵＩデータを事前送信する。図１２に示す動作例では、図４に示したステップＳ１２，Ｓ１３の後に、ＭＦＰ１００を識別するための端末情報の要求及び送信の処理と、接続元の種別に応じて事前送信の要否を切替える処理とを追加している。

図１２に示すステップＳ１１〜Ｓ１３までの処理は、図４にて説明したとおりである。情報処理装置４００が起床し、ＭＦＰ１００との間でセッションが確立されると、ＭＦＰ１００は情報処理装置４００に対して、ＵＩデータの事前送信を要求する（Ｓ１３）。

情報処理装置４００は、接続元のＭＦＰ１００に対して、ＭＦＰ１００の種別を特定するために端末情報を要求する（Ｓ２１）。そして、ＭＦＰ１００は、情報処理装置４００に端末情報を送信する（Ｓ２２）。これにより、情報処理装置４００のＵＩ送信制御部１００ｃは、ＭＦＰ１００に事前送信するＵＩデータが必要であるか否かを判定する（ＳＴ５）。

ＭＦＰ１００にＵＩデータが格納されていれば、情報処理装置４００からＭＦＰ１００へのＵＩデータの事前送信は不要となる。このため、情報処理装置４００は、ＭＦＰ１００が保持するＵＩデータを用いて操作画面を表示するよう要求する（Ｓ２３）。一方、ＭＦＰ１００に、ＵＩデータが格納されていなければ、情報処理装置４００は、ＭＦＰ１００にＵＩデータを事前送信し、ＭＦＰ１００に操作画面を表示させる。

その後、情報処理装置４００は、ＭＦＰ１００と確立したセッションを切断する。セッションを切断するためのステップＳ１７以降の処理は、図４にて説明したとおりである。そして、情報処理装置４００が省電力状態ＳＴ３に移行した後、ＭＦＰ１００は、操作画面を表示する状態となる（ＳＴ６）。

以上説明した第２の実施の形態に係る通信システム１０Ａでは、第１の実施の形態においてＭＦＰ１００が端末２００へ送信していた事前送信するＵＩデータを、情報処理装置４００が生成し、ＭＦＰ１００に事前送信する。このため、情報処理装置４００は、ＵＩデータを事前送信した後、省電力状態に直ちに移行することができる。

なお、情報処理装置４００は、端末２００から要求されるＵＩデータを、端末２００に事前送信することも可能である。情報処理装置４００に端末２００がアクセスした場合、図１１に示した情報処理装置４００内の各機能ブロックが端末２００に対して行う動作は、情報処理装置４００がＭＦＰ１００に対して行う動作と同様である。

また、本発明は上述した実施の形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した実施の形態は本発明を分かりやすく説明するために装置及びシステムの構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施の形態の構成の一部を他の実施の形態の構成に置き換えることは可能であり、さらにはある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０…通信システム、１００…ＭＦＰ、２００…端末、１００ａ…ＵＩ生成部、１００ｂ…ＵＩ送信部、１００ｃ…ＵＩ送信制御部、１００ｄ…記憶部、１００ｅ…ＭＦＰ制御部、１００ｆ…電源制御部、１００ｇ…ネットワーク部

Claims (12)

1. 自装置の電源状態を制御する電源制御部と、
   前記自装置に対する操作が行われる端末に対してネットワーク通信を行うネットワーク部と、
   前記端末に表示される操作画面を構成するための画面データを生成する画面データ生成部と、
   前記画面データを前記ネットワーク通信で前記端末へ送信する画面データ送信部と、
   前記端末から取得要求された前記画面データを事前送信するか否かの判定を行い、事前送信が必要と判定した場合には、前記端末に前記画面データを事前送信する旨を通知し、事前送信する前記画面データの生成を前記画面データ生成部に指示し、前記画面データ生成部により生成された前記画面データの事前送信を前記画面データ送信部に指示すると共に、前記電源状態を省電力状態に移行可能であることを前記電源制御部に通知することにより、前記電源制御部に前記電源状態を前記省電力状態に移行させる画面データ送信制御部と、を備える、
   画像形成装置。
2. 前記画面データ送信制御部は、前記端末に表示される前記操作画面を通じて要求される機能に関連し、かつ、前記端末により操作される頻度が高い前記画面データの事前送信を前記画面データ送信部に指示する
   請求項１に記載の画像形成装置。
3. 前記画面データ生成部は、前記端末に表示される前記操作画面の操作により遷移する画面を特定するためのリンク情報を、前記端末で参照可能なリンク情報に変更した前記画面データを生成する
   請求項１又は２に記載の画像形成装置。
4. 前記画面データ生成部は、前記操作画面の操作により前記自装置に対して実行指示が行われるリンク情報を変更せず、又は階層構造とした前記操作画面の下層に含まれる前記リンク情報を変更しない
   請求項３に記載の画像形成装置。
5. 前記画面データ送信制御部は、前記端末から要求された前記画面データの種別に応じて、前記画面データ送信部に事前送信させるか否かを判定する
   請求項１〜４のいずれか一項に記載の画像形成装置。
6. さらに、前記画面データ送信部により事前送信された前記画面データ、及び前記画面データの送信先の前記端末を記憶する記憶部を備え、
   前記画面データ送信制御部は、前記画面データ送信部により事前送信済みの前記画面データと、前記画面データ生成部が更新した画面データとに差異が発生した場合には、前記画面データ送信部に対して、前記画面データの送信先の前記端末に事前送信済みの前記画面データを更新するための更新データを送信させ、かつ、事前送信済みの前記画面データの破棄要求を送信させる
   請求項１〜５のいずれか一項に記載の画像形成装置。
7. 前記記憶部は、前記端末からのアクセス状態を記憶し、
   前記画面データ送信制御部は、前記端末から前記自装置に対するアクセスが事前にあり、かつ、前記自装置が省電力状態から起床した場合に、前記端末に事前送信した前記画面データに対する追加送信の要否を確認し、前記端末から追加送信が必要と確認された前記画面データを追加送信する
   請求項６に記載の画像形成装置。
8. さらに、前記画面データ送信部により事前送信された前記画面データ、前記画面データの送信先の前記端末、及び前記端末からのアクセス状態を記憶する記憶部を備え、
   前記画面データ送信制御部は、前記端末から前記自装置に対するアクセスが事前にあり、かつ、前記自装置が省電力状態から起床した場合に、前記端末に事前送信した前記画面データにより前記端末に表示される前記操作画面が操作されることで遷移する画面を特定するためのリンク情報であって、前記端末で参照可能に変更された前記リンク情報を、Ｗｅｂアクセス可能なリンク情報に戻す旨を前記端末に通知すると共に、Ｗｅｂアクセス可能な前記リンク情報を前記端末に送信する
   請求項１〜５のいずれか一項に記載の画像形成装置。
9. 前記画面データ送信制御部は、前記端末から受信する、事前送信する前記画面データの制限に関する情報に合わせて変更した前記画面データを前記画面データ送信部に事前送信させる
   請求項１〜８のいずれか一項に記載の画像形成装置。
10. 画面データ送信制御部は、前記端末の種別に関する情報を取得し、前記端末の種別に応じて前記画面データの前記端末に対する事前送信の要否を切替える
    請求項１〜９のいずれか一項に記載の画像形成装置。
11. 自装置に対する操作が行われる端末から取得要求された、前記端末に表示される操作画面を構成するための画面データを前記端末に事前送信するか否かの判定を行い、事前送信が必要と判定した場合には、前記端末に前記画面データを事前送信する旨を通知する手順と、
    前記画面データを生成する画面データ生成部に対して、事前送信する前記画面データの生成を指示する手順と、
    生成された前記画面データの事前送信を画面データ送信部に指示して、ネットワーク通紙で前記端末に前記画面データを事前送信する手順と、
    前記自装置の電源状態を省電力状態に移行可能であることを、前記自装置の電源状態を制御する電源制御部に通知することにより、前記電源制御部に前記電源状態を省電力状態に移行させる手順と、を
    コンピュータに実行させるためのプログラム。
12. 自装置の電源状態を管理及び制御する電源制御部と、
    画像形成装置から前記自装置にネットワーク通信を行うネットワーク部と、
    前記画像形成装置に表示される操作画面を構成するための画面データを生成する画面データ生成部と、
    前記画面データを前記ネットワーク通信で前記画像形成装置へ送信する画面データ送信部と、
    前記画像形成装置から取得要求された前記画面データを事前送信するか否かの判定を行い、事前送信が必要と判定した場合には、前記画像形成装置に前記画面データを事前送信する旨を通知し、事前送信する前記画面データの生成を前記画面データ生成部に指示し、前記画面データ生成部により生成された前記画面データの事前送信を前記画面データ送信部に指示すると共に、前記電源状態を省電力状態に移行可能であることを前記電源制御部に通知することにより、前記電源制御部に前記電源状態を前記省電力状態に移行させる画面データ送信制御部と、を備える、
    情報処理装置。

Images