画像処理装置、編集方法及び編集プログラム
【課題】操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にする。
【解決手段】ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を判断する第１判断手段と、編集後の第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、優先情報から取得した第１ＵＩ部品の種別に対応する優先度と第２ＵＩ部品の種別に対応する優先度とに基づき、第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、第１及び第２判断手段の判断結果に基づき、第１ＵＩ部品の編集を制御する編集制御手段と、を備える。
【解決手段】ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を判断する第１判断手段と、編集後の第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、優先情報から取得した第１ＵＩ部品の種別に対応する優先度と第２ＵＩ部品の種別に対応する優先度とに基づき、第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、第１及び第２判断手段の判断結果に基づき、第１ＵＩ部品の編集を制御する編集制御手段と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＩ部品の編集を行う画像処理装置、編集方法及び編集プログラムに関する。
【背景技術】
【０００２】
近年、画像形成装置（ＭＦＰ：Multifunction Peripheral）の操作画面において、ユーザが使いやすいようにカスタマイズ（編集）したいというニーズが高まっている。ＭＦＰの操作画面（ＵＩ画面ともいう）をカスタマイズする際、画面を構成するＵＩ要素（部品）毎にアクセス権を管理する技術がある。
【０００３】
例えば、特許文献１（特開２００７−３２３２３４号公報）には、ＵＩカスタマイズの権限管理を行うという目的で、ＵＩ部品毎にメタ情報を持たせて、メタ情報の中の権限情報を使って権限管理をさせる構成が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１の技術によれば、ＵＩ部品1つ1つにアクセス権等の情報を記載したメタ情報が必要となる。よって、新しいＵＩ部品を追加した際に、例えそのＵＩ部品が既存のものと同じようなものであっても、そのメタ情報にアクセス権を追加する必要があるという問題があった。さらに、ＵＩ部品のカスタマイズをした際、ＵＩ部品同士が干渉（重なるなど）した場合に、どのＵＩ部品のアクセス権を優先すべきかの判断が難しいという問題があった。
【０００５】
そこで、本発明は上記問題に鑑みてなされたものであり、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる画像形成装置、編集方法及び編集プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一局面の画像処理装置は、ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、前記種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、前記操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を、前記権限情報に基づき判断する第１判断手段と、編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、前記第１及び第２判断手段の判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御手段と、を備える。
【０００７】
また、本発明の他の局面の編集方法は、画像形成装置に実行される編集方法であって、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、を有する。
【０００８】
また、本発明は、本発明の編集方法を実行するためのプログラムを記録した記録媒体をコンピュータに読み取らせて実現することも可能である。
【発明の効果】
【０００９】
本発明によれば、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。
【図面の簡単な説明】
【００１０】
【図１】実施例１におけるＭＦＰのハードウェアの一例を示すブロック図。
【図２】実施例１におけるＭＦＰの機能の一例を示すブロック図。
【図３】判断手段の機能の一例を示すブロック図。
【図４】ＵＩ部品の種別の一例を示す図。
【図５】権限情報の一例を示す図。
【図６】優先情報の一例を示す図。
【図７】ＵＩ部品同士が干渉する例を示す図。
【図８】関連付けがＵＩ部品同士の連動関係である場合の例を示す図。
【図９】関連付けがＵＩ部品同士の排他関係である場合の例を示す図。
【図１０】編集可否判断処理の一例（その１）を示すフローチャート。
【図１１】編集可否判断処理の一例（その２）を示すフローチャート。
【図１２】編集可否判断処理の一例（その３）を示すフローチャート。
【図１３】実施例２におけるＭＦＰの機能の一例を示すブロック図。
【図１４】操作者の権限を変更する例を説明するための図。
【図１５】ＵＩ部品の種別を新規に権限情報に追加する例を説明するための図。
【図１６】種別単位の優先度を変更する例を説明するための図。
【図１７】ＵＩ部品の種別を新規に優先情報に追加する例を説明するための図。
【図１８】権限を変更する処理の一例を示すフローチャート。
【図１９】新規種別を権限情報に追加する処理の一例を示すフローチャート。
【図２０】優先度を変更する処理の一例を示すフローチャート。
【図２１】優先度に種別を追加する処理の一例を示すフローチャート。
【図２２】実施例３におけるＭＦＰの機能の一例を示すブロック図。
【図２３】エラー通知の一例（その１）を示す図。
【図２４】エラー通知の一例（その２）を示す図。
【図２５】エラー通知処理の一例（その１）を示すフローチャート。
【図２６】エラー通知処理の一例（その２）を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、本発明の実施例を図面に基づいて説明する。
［実施例１］
＜ハードウェア＞
図１は、実施例１におけるＭＦＰ１のハードウェアの一例を示すブロック図である。図１に示すように、ＭＦＰ１は、制御部１１、主記憶部１２、補助記憶部１３、外部記録装置Ｉ／Ｆ部１４、ネットワークＩ／Ｆ部１５、操作部１６、表示部１７、エンジン部１８を含む。これら各構成は、バスを介して相互にデータ送受信可能に接続されている。
【００１２】
制御部１１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部１１は、主記憶部１２や補助記憶部１３に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。
【００１３】
主記憶部１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部１１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【００１４】
補助記憶部１３は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。
【００１５】
外部記録装置I／F部１４は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記録媒体１９（例えば、フラッシュメモリ、ＳＤカードなど）とＭＦＰ１とのインタフェースである。
【００１６】
また、記録媒体１９に、所定のプログラムを格納し、この記録媒体１９に格納されたプログラムは外部記録装置Ｉ／Ｆ部１４を介してＭＦＰ１にインストールされ、インストールされた所定のプログラムはＭＦＰ１により実行可能となる。
【００１７】
ネットワークＩ／Ｆ部１５は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器とＭＦＰ１とのインタフェースである。
【００１８】
操作部１６や表示部１７は、キースイッチ（ハードキー）とタッチパネル機能（ＧＵＩのソフトウェアキーを含む：Graphical User Interface）を備えたＬＣＤ（Liquid Crystal Display）とから構成され、ＭＦＰ１が有する機能を利用する際のＵＩ（User Interface）として機能する表示及び／又は入力装置である。
【００１９】
エンジン部１８は、画像データの入出力ユニットとして、紙原稿の読み取り転写紙への印刷を行う。エンジン部１８は、スキャナエンジンなどをさらに備えてもよい。
【００２０】
＜構成＞
次に、実施例１におけるＭＦＰ１の機能について説明する。図２は、実施例１におけるＭＦＰ１の機能の一例を示すブロック図である。
【００２１】
図２に示すＭＦＰ１は、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６を含む。記憶手段１０１は、各操作画面の画面データを記憶したり、操作画面の各ＵＩ部品のデータを記憶したりする。また、記憶手段１０１は、権限情報記憶手段１０２、優先情報記憶手段１０３を含む。
【００２２】
権限情報記憶手段１０２は、ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報を記憶する。ＵＩ部品の種別とは、例えば、ボタン、テキスト、リストボタン、入力エリア、状態表示エリアなどである。ＵＩ部品の種別に対する操作者の権限とは、例えば、テキストのＵＩ部品に対し、Ａさんは編集可又はＢさんは編集不可というような権限である。
【００２３】
優先情報記憶手段１０３は、ＵＩ部品の種別に対する編集の優先度を表す優先情報を記憶する。編集の優先度は、例えば、ＵＩ部品の種別に１，２，３・・・などの優先順を付与したり、テキスト＞ボタン＞リストボタン・・・などの不等号を用いて優先を表したりする。
【００２４】
操作手段１０４は、操作部１６からの各種操作を受け付ける。例えば、操作手段１０４は、記憶部１０１内の画面データに基づく操作画面をカスタマイズ（編集）する編集画面を表示制御し、操作画面内のＵＩ部品の編集指示を受け付ける。ＵＩ部品の編集には、サイズの拡大縮小、位置の変更などがある。操作手段１０４は、編集対象のＵＩ部品と、編集指示内容と、編集を行った操作者（ログインユーザ名）などを判断手段１０５に出力する。
【００２５】
判断手段１０５は、ＵＩ部品の編集指示に対し、操作者の権限と、優先度とに基づいて編集を許可するか否かを判定する。図３は、判断手段１０５の機能の一例を示すブロック図である。
【００２６】
図３に示す判断手段１０５は、権限判断手段２０１、編集可否判断手段２０２を含む。権限判断手段２０１は、権限情報記憶手段１０２に記憶される権限情報を参照して、編集対象のＵＩ部品の種別に対し、操作者に権限があるか否かを判断する。権限判断手段２０１は、判断結果を編集制御手段１０６に出力する。
【００２７】
編集可否判断手段２０２は、編集対象のＵＩ部品を編集することで、他のＵＩ部品に影響を与える（他のＵＩ部品と干渉する又は重なる）場合、この編集を許可するか否かを判断する。他のＵＩ部品に影響を与えるとは、ＵＩ部品同士が重なったりすることである。
【００２８】
編集可否判断手段２０２は、優先情報記憶手段１０３に記憶される優先情報を参照して、編集対象のＵＩ部品の種別と他のＵＩ部品の種別のそれぞれの優先度を取得する。編集可否判断手段２０２は、編集対象のＵＩ部品の優先度の方が高い場合は、この編集を許可し、編集対象のＵＩ部品の優先度の方が低い場合は、この編集を不可とする。編集可否判断手段２０２は、判断結果を編集制御手段１０６に出力する。
【００２９】
なお、判断結果は、編集可否判断手段２０２からの判断結果に一本化してもよい。このとき、権限判断手段２０１は、判断結果を編集可否判断手段２０２に出力する。編集可否判断手段２０２は、操作者に権限がない場合は編集不可を判断結果する。
【００３０】
また、編集可否判断手段２０２は、操作者に権限がある場合でも編集対象のＵＩ部品の優先度が他のＵＩ部品の優先度より低ければ編集不可を判断結果とし、編集対象のＵＩ部品の優先度が他のＵＩ部品の優先度より高ければ編集可を判断結果とする。編集可否判断手段２０２は、操作者に権限がある場合で、編集対象のＵＩ部品が他のＵＩ部品に影響を与えない場合は編集可を判断結果とする。
【００３１】
図２に戻り、編集制御手段１０６は、判断手段１０５から取得した結果に基づき、ＵＩ部品のカスタマイズを制御する。編集制御手段１０６は、権限判断手段２０１からの判断結果が「操作者に権限ある」であり、編集可否判断手段２０２からの判断結果が「編集可」であればＵＩ部品の編集を編集指示に従って実行する。編集制御手段１０６は、ＵＩ部品を編集した画面データを記憶手段１０１に記憶する。記憶手段１０１は、編集後の画面データを、操作者ごとに管理してもよい。
【００３２】
以上の構成を有することで、ＵＩ部品には種別を関連付け、種別毎に権限を確認したりすることができ、既存の権限を流用したりすることができる。編集をすることで、ＵＩ部品間が干渉をする場合は、どのＵＩ部品を優先して編集するかを決定することができる。
【００３３】
＜各種情報＞
図４は、ＵＩ部品の種別の一例を示す図である。図４に示すＵＩ部品の種別は、ＵＩ部品に対し、テキスト、ボタン、リストボタン、入力エリア、状態表示エリアなどが定義されている。例えば、このＵＩ部品の種別情報は、記憶部１０１に記憶されている。
【００３４】
図５は、権限情報の一例を示す図である。図５に示す権限情報は、ＵＩ部品の種別毎に、操作者それぞれの権限が設定されている。図５に示す「○」は例えば権限あり（カスタマイズ可能）を示し、「×」は権限なし（カスタマイズ不可）を示す。
【００３５】
図６は、優先情報の一例を示す図である。図６に示す優先情報は、種別単位の優先度と組み合わせテーブルとの一例を示す図である。図６に示す種別の単位の優先度は、
ボタン＞リストボタン＞入力エリア＞状態表示エリア＝テキスト
となっている。これは、ボタンの優先度が一番高く、状態表示エリア及びテキストの優先度が一番低いことを示す。
【００３６】
図６に示す組み合わせテーブルは、干渉される側とする側のＵＩ部品の種別に対し、どちらを優先するかを示すテーブルである。例えば、干渉する（編集対象のＵＩ部品）側の種別が「ボタン」であり、干渉される（他のＵＩ部品）側の種別が「テキスト」である場合、「ボタン」の優先度が高いため、「ボタン」の編集が許可されることを示す。
【００３７】
また、干渉する側の種別が「テキスト」であり、干渉される側の種別が「ボタン」である場合、「ボタン」の優先度が高いため、「テキスト」の編集は許可されないことを示す。また、「後優先」は、お互いの優先度が同じ（状態表示エリア＝テキスト）であるため、後からカスタマイズした内容が反映されることを示す。なお、種別単位の優先度が決まれば、組み合わせテーブルは自動生成可能である。よって、組み合わせテーブルは、必ずしも記憶される必要はない。
【００３８】
＜編集例＞
次に、図５、６の情報に基づいたカスタマイズの例について説明する。図７は、ＵＩ部品同士が干渉する例を示す図である。図７（Ａ）は、「ボタン」を大きくするカスタマイズにより、「テキスト」の一部が見えなくなる例を示す。ＵＩ部品の種別の「ボタン」と「テキスト」とでは、「ボタン」の方が優先度が高い（図６参照）。
【００３９】
・Ａさんが操作者の場合
権限判断手段２０１は、Ａさんが「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段１０６は、この編集は可能であるため、編集を実行する。
【００４０】
・Ｂさんが操作者の場合
権限判断手段２０１は、Ｂさんが「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限なしと判断する。編集可否判断手段２０２は、権限判断手段２０１の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため編集を実行しない。つまり、Ｂさんによるボタンのサイズ変更はできない。
【００４１】
・管理者が操作者の場合
権限判断手段２０１は、管理者が「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段１０６は、この編集は可能であるため、編集を実行する。
【００４２】
次に、図７（Ｂ）は、「状態表示エリア」を大きくするカスタマイズにより、「リストボタン」の一部が見えなくなる例を示す。ＵＩ部品の種別の「状態表示エリア」と「リストボタン」とでは、「リストボタン」の方が優先度が高い（図６参照）。
【００４３】
・Ａさんが操作者の場合
権限判断手段２０１は、Ａさんが「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため、編集を実行しない。つまり、Ａさんによる「状態表示エリア」の変更はできない。
【００４４】
・Ｂさんが操作者の場合
権限判断手段２０１は、Ｂさんが「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限なしと判断する。編集可否判断手段２０２は、権限判断手段２０１の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため編集を実行しない。つまり、Ｂさんによる「状態表示エリア」の変更はできない。
【００４５】
・管理者が操作者の場合
権限判断手段２０１は、管理者が「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため、編集を実行しない。つまり、管理者による「状態表示エリア」の変更はできない。
【００４６】
次に、ＵＩ部品同士に関連付けが行われている場合、いずれかのＵＩ部品に編集権限があれば、関連付けられたＵＩ部品同士の編集を可能とする例について説明する。図８は、関連付けがＵＩ部品同士の連動関係である場合の例を示す図である。
【００４７】
図８（Ａ）は、片面集約ボタンａ１１が選択されている場合、枚数選択のリストボタンａ２１が連動して表示される例を示す。図８（Ｂ）は、両面集約ボタンａ１２が選択されている場合、枚数選択のリストボタンａ２２が連動して表示される例を示す。図８（Ａ）（Ｂ）は、集約選択ボタンに枚数選択リストボタンが連動している。
【００４８】
例えば、Ａさんがリストボタンを編集する場合を考える。このとき、権限判断手段２０１は、Ａさんが枚数選択リストボタンの種別「リストボタン」を編集可能かどうか（権限があるかどうか）及び枚数選択リストボタンに連動する集約選択ボタンの種別「ボタン」を編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段２０１は、「ボタン」に対して権限ありと判断する。
【００４９】
ここで、連動するＵＩ部品のうち、一つでも権限ありのＵＩ部品があれば、権限判断手段２０１は、連度するＵＩ部品（例えば集約選択ボタン、枚数選択リストボタン）全てを編集可と判断する。よって、編集制御手段１０６は、この枚数選択リストボタンの編集は可能であるため、編集を実行する。
【００５０】
一般的に、カスタマイズ（編集）をする場合は、所定のＵＩ部品に対し、意味のある集合単位で行うことが多い。しかしながら、集合単位でアクセス（カスタマイズ）権限を設定するのは非常に大変である。しかし、煩雑な設定をしなくても、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とする。これにより、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００５１】
次に、関連付けの例が排他関係の場合について説明する。図９は、関連付けがＵＩ部品同士の排他関係である場合の例を示す図である。
【００５２】
図９（Ａ）は、片面集約ボタンが選択されている場合の例を示す。図９（Ｂ）は、両面集約ボタンが選択されている場合の例を示す。図９（Ｂ）には、両面集約に必要な開き方向の選択リストボタンａ３１が表示されている。一方、図９（Ａ）には、片面集約の場合、開き方向は不要であるため、開き方向の選択リストボタンａ３１は表示されない。
【００５３】
つまり、開き方向の選択リストボタンａ３１は、両面集約ボタンａ１２であれば表示され、片面集約ボタンａ１１であれば表示されないという排他的な関係にある。このとき、開き方向の選択リストボタンａ３１は、両面集約ボタンａ１２と関連付けされる。
【００５４】
例えば、Ａさんが開き方向の選択リストボタンａ３１を編集する場合を考える。このとき、権限判断手段２０１は、Ａさんが開き方向の選択リストボタンａ３１の種別「リストボタン」を編集可能かどうか（権限があるかどうか）及び開き方向の選択リストボタンａ３１に連動する両面集約ボタンａ１２の種別「ボタン」を編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段２０１は、「ボタン」に対して権限ありと判断する。
【００５５】
ここで、関連付けられたＵＩ部品のうち、一つでも権限ありのＵＩ部品があれば、権限判断手段２０１は、関連付けられたＵＩ部品（例えば両面選択ボタン、開き方向の選択リストボタン）全てを編集可と判断する。よって、編集制御手段１０６は、この開き方向の選択リストボタンの編集は可能であるため、編集を実行する。なお、関連付けられた関連ＵＩ部品情報は、記憶手段１０１に予め記憶されているとする。判断手段１０５が、記憶手段１０１に記憶されている関連ＵＩ部品情報を参照して、前述した判断を行う。
【００５６】
これにより、開き方向の選択リストボタンのように、排他的な関係を有するＵＩ部品であっても、煩雑な設定をしなくてすむ。また、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００５７】
＜動作＞
次に、ＭＦＰ１の動作について説明する。図１０は、実施例１における編集可否判断処理の一例（その１）を示すフローチャートである。図１０に示すステップＳ１０１で、判断手段１０５は、機器に認証されている操作者の権限を、権限情報を参照することでチェックする。
【００５８】
ステップＳ１０２で、判断手段１０５は、操作者による編集指示が、権限がある種別のＵＩ部品のカスタマイズであるかを判定する。権限がある種別であれば（ステップＳ１０２−ＹＥＳ）ステップＳ１０３に進み、権限がない種別であれば（ステップＳ１０２−ＮＯ）ステップＳ１０６に進む。
【００５９】
ステップＳ１０３で、判断手段１０５は、操作者による編集指示の内容（カスタマイズ内容）が、他のＵＩ部品に干渉するかを判定する。他のＵＩ部品と干渉すれば（ステップＳ１０３−ＹＥＳ）ステップＳ１０４に進み、他のＵＩ部品と干渉しなければ（ステップＳ１０３−ＮＯ）ステップＳ１０６に進む。
【００６０】
ステップＳ１０４で、判断手段１０５は、干渉する（編集対象の）ＵＩ部品と干渉されるＵＩ部品の優先度の関係から、編集をしてもよいかを判定する。干渉するＵＩ部品の優先度の方が高ければ（ステップＳ１０４−ＹＥＳ）ステップＳ１０５に進み、干渉されるＵＩ部品の優先度の方が高ければ（ステップＳ１０４−ＮＯ）ステップＳ１０６に進む。
【００６１】
ステップＳ１０５で、判断手段１０５は、操作者による編集指示を、カスタマイズＯＫ（編集可）と判断する。
【００６２】
ステップＳ１０６で、判断手段１０５は、操作者による編集指示を、カスタマイズＮＧ（編集不可）と判断する。
【００６３】
次に、ＵＩ部品の関連付けを考慮する場合の判断処理について説明する。図１１は、編集可否判断処理の一例（その２）を示すフローチャートである。図１１に示す処理は、図１０に示すステップＳ１０６の後に行われる。
【００６４】
ステップＳ２０１で、判断手段１０５は、ステップＳ１０６でカスタマイズＮＧと判断されたかを判定する。カスタマイズＮＧ（編集不可）と判断されれば（ステップＳ２０１−ＹＥＳ）ステップＳ２０２に進み、カスタマイズＯＫ（編集可）と判断されれば（ステップＳ２０１−ＮＯ）処理を終了する。
【００６５】
ステップＳ２０２で、判断手段１０５は、カスタマイズ対象のＵＩ部品と連動関係にあるＵＩ部品が操作画面上にあるかを判定する（図８参照）。連動関係にあるＵＩ部品があれば（ステップＳ２０２−ＹＥＳ）ステップＳ２０３に進み、連動関係にあるＵＩ部品がなければ（ステップＳ２０２−ＮＯ）処理を終了する。
【００６６】
ステップＳ２０３に進み、判断手段１０５は、連動関係にあるＵＩ部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合（ステップＳ２０３−ＹＥＳ）ステップＳ２０４に進み、カスタマイズ権限がない場合（ステップＳ２０３−ＮＯ）処理を終了する。
【００６７】
ステップＳ２０４で、判断手段１０５は、カスタマイズ対象のＵＩ部品に対し、カスタマイズＯＫ（編集可）と判断する。
【００６８】
図１２は、編集可否判断処理の一例（その３）を示すフローチャートである。図１２に示す処理は、図１０に示すステップＳ１０６の後に行われる。
【００６９】
ステップＳ３０１で、判断手段１０５は、ステップＳ１０６でカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧ（編集不可）と判断されれば（ステップＳ３０１−ＹＥＳ）ステップＳ３０２に進み、カスタマイズＯＫ（編集可）と判断されれば（ステップＳ３０１−ＮＯ）処理を終了する。
【００７０】
ステップＳ３０２で、判断手段１０５は、カスタマイズ対象のＵＩ部品と排他関係にあるＵＩ部品が操作画面上にあるかを判定する（図９参照）。排他関係にあるＵＩ部品があれば（ステップＳ３０２−ＹＥＳ）ステップＳ３０３に進み、排他関係にあるＵＩ部品がなければ（ステップＳ３０２−ＮＯ）処理を終了する。
【００７１】
ステップＳ３０３に進み、判断手段１０５は、排他関係にあるＵＩ部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合（ステップＳ３０３−ＹＥＳ）ステップＳ３０４に進み、カスタマイズ権限がない場合（ステップＳ３０３−ＮＯ）処理を終了する。
【００７２】
ステップＳ３０４で、判断手段１０５は、カスタマイズ対象のＵＩ部品に対し、カスタマイズＯＫ（編集可）と判断する。
【００７３】
以上、実施例１によれば、ＵＩ部品の種別単位で編集権限を管理することで、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。また、実施例１によれば、種別単位で管理を行うことで、新しいＵＩ部品が追加された場合でも、編集権限を流用することができる。
【００７４】
また、実施例１によれば、ＵＩ部品の種別間の優先度から編集の可否を判断するため、ＵＩ部品が干渉した場合に、容易に編集可否を判断することができる。また、実施例１によれば、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００７５】
［実施例２］
次に、実施例２におけるＭＦＰ２について説明する。実施例２では、記憶手段１０１に記憶される権限情報や優先情報を編集する。実施例２におけるＭＦＰ２のハードウェアは実施例１と同様であるため、その説明を省略する。
【００７６】
＜構成＞
図１３は、実施例２におけるＭＦＰ２の機能の一例を示すブロック図である。図１３に示すＭＦＰ２は、権限情報編集手段３０１、優先情報編集手段３０２、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６を含む。図１３に示す機能において、図２に示す機能と同様のものは同じ符号を付し、その説明を省略する。
【００７７】
権限情報編集手段３０１は、図５に示す権限情報にアクセスし、編集を行う。例えば、権限情報の編集画面を表示制御し、操作者からの編集指示を権限情報に反映させる。権限情報編集手段３０１は、例えば、操作者の権限を変更する。
【００７８】
図１４は、操作者の権限を変更する例を説明するための図である。図１４に示す例では、権限情報編集手段３０１は、Ｂさんの「入力エリア」の権限を「×：カスタマイズ不可」から「○：カスタマイズ可」に変更する。また、権限情報編集手段３０１は、管理者の「リストボタン」の権限を「○：カスタマイズ可」から「×：カスタマイズ不可」に変更する。これにより、種別毎の権限を編集することができ、操作者の環境に合うよう最適な権限情報にすることができる。
【００７９】
権限情報編集手段３０１は、ＵＩ部品の種別を新規に追加することもできる。図１５は、ＵＩ部品の種別を新規に権限情報に追加する例を説明するための図である。図１５に示す例では、権限情報編集手段３０１は、種別「アイコン」を新規に権限情報に追加する。この「アイコン」には、Ａさん、Ｂさん、管理者全てに対し、「○：カスタマイズ可」が設定される。これにより、新しいＵＩ部品の種別を追加することができ、新しいＵＩ部品も権限情報に従って編集することができる。
【００８０】
優先情報編集手段３０２は、図６に示す優先情報にアクセスし、編集を行う。例えば、優先情報の編集画面を表示制御し、操作者からの編集指示を優先情報に反映させる。優先情報編集手段３０２は、例えば、種別単位の優先度を変更する。
【００８１】
図１６は、種別単位の優先度を変更する例を説明するための図である。図１６に示す例では、優先情報編集手段３０２は、「状態表示エリア」を「テキスト」よりも優先度を高くする変更を行う。この変更に伴い、組み合わせテーブルも自動で変更される（図１６参照）。干渉する側「状態表示エリア」及び干渉される側「テキスト」、干渉する側「テキスト」及び干渉される側「状態表示エリア」が「後優先」から「状態表示エリア」に変更される。これにより、種別間の優先度を編集することができ、操作者の環境に合うよう最適な優先情報にすることができる。
【００８２】
優先情報編集手段３０２は、ＵＩ部品の種別を新規に追加することもできる。図１７は、ＵＩ部品の種別を新規に優先情報に追加する例を説明するための図である。図１７に示す例では、優先情報編集手段３０２は、種別「アイコン」を、「状態表示エリア」及び「テキスト」と同じ優先度として追加する。
【００８３】
この追加に伴い、組み合わせテーブルも自動で変更される（図１７参照）。干渉するＵＩ部品間の優先度が同じ場合は「後優先」となる。これにより、新しいＵＩ部品の種別を追加することができ、新しいＵＩ部品も種別間の優先情報に従って編集することができる。
【００８４】
以上の構成により、ＭＦＰ２は、権限情報の権限を編集したり、ＵＩ部品の種別の権限を新規に追加したり、容易に編集することができる。また、ＭＦＰ２は、優先情報の権限を編集したり、ＵＩ部品の種別の優先度を追加したり、容易に編集することができる。
【００８５】
＜動作＞
次に、実施例２におけるＭＦＰ２の動作について説明する。図１８は、権限を変更する処理の一例を示すフローチャートである。図１８に示すステップＳ４０１で、権限情報編集手段３０１は、権限情報記憶手段１０２から権限情報を取得する。
【００８６】
ステップＳ４０２で、権限情報編集手段３０１は、ＵＩ部品の種別、操作者の情報から権限情報に設定された権限値を検索し、この権限値を変更する。
【００８７】
ステップＳ４０３で、権限情報編集手段３０１は、ステップＳ４０２の変更内容に基づいて、権限情報記憶手段１０２に記憶される権限情報を更新する（図１４参照）。
【００８８】
図１９は、新規種別を権限情報に追加する処理の一例を示すフローチャートである。図１９に示すステップＳ５０１で、権限情報編集手段３０１は、権限情報記憶手段１０２から権限情報を取得する。
【００８９】
ステップＳ５０２で、権限情報編集手段３０１は、新規ＵＩ部品の種別を権限情報に追加し、適切な権限値を入力する。
【００９０】
ステップＳ５０３で、権限情報編集手段３０１は、ステップＳ５０２の新規種別の追加に基づいて、権限情報記憶手段１０２に記憶される権限情報を更新する（図１５参照）。
【００９１】
図２０は、優先度を変更する処理の一例を示すフローチャートである。図２０に示すステップＳ６０１で、優先情報編集手段３０２は、優先情報記憶手段１０３から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。
【００９２】
ステップＳ６０２で、優先情報編集手段３０２は、種別単位の優先度を変更し、組み合わせテーブルを優先度の変更に従って適切に変更する。
【００９３】
ステップＳ６０３で、優先情報編集手段３０２は、ステップＳ６０２の変更内容に基づいて、優先情報記憶手段１０３に記憶される優先情報を更新する（図１６参照）。
【００９４】
図２１は、優先度に種別を追加する処理の一例を示すフローチャートである。図２１に示すステップＳ７０１で、優先情報編集手段３０２は、優先情報記憶手段１０３から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。
【００９５】
ステップＳ７０２で、優先情報編集手段３０２は、優先度に新規種別を追加して、組み合わせテーブルを新規種別の優先度に従って適切に変更する。
【００９６】
ステップＳ７０３で、優先情報編集手段３０２は、ステップＳ７０２の変更内容に基づいて、優先情報記憶手段１０３に記憶される優先情報を更新する（図１７参照）。
【００９７】
以上、実施例２によれば、権限情報の権限を編集したり、ＵＩ部品の種別の権限を新規に追加したり、容易に編集することができる。また、実施例２によれば、優先情報の権限を編集したり、ＵＩ部品の種別の優先度を追加したり、容易に編集することができる。
【００９８】
［実施例３］
次に、実施例３におけるＭＦＰ３について説明する。実施例３のＭＦＰ３は、編集が不可と判断された場合、その旨を通知する。また、ＭＦＰ３は、カスタマイズが可能な編集内容を合わせて通知する。実施例３におけるＭＦＰ３のハードウェアは実施例１と同様であるため、その説明を省略する。
【００９９】
＜構成＞
図２２は、実施例３におけるＭＦＰ３の機能の一例を示すブロック図である。図２２に示すＭＦＰ３は、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６、通知手段４０１を含む。図２２に示す機能において、図２に示す機能と同様のものは同じ符号を付し、その説明を省略する。
【０１００】
通知手段４０１は、判断手段１０５によりカスタマイズＮＧと判断された旨の通知を受ける。通知手段４０１は、ＵＩ部品の編集がＮＧである（権限がない）ことを表示部１７に表示する（図２３参照）。
【０１０１】
図２３は、エラー通知の一例（その１）を示す図である。図２３に示す例では、エラー通知として「権限がありません」と画面に表示される。
【０１０２】
また、通知手段４０１は、操作者と干渉されるＵＩ部品の種別とから、編集可能なＵＩ部品とその内容とをエラー通知に含める（図２４）。
【０１０３】
図２４は、エラー通知の一例（その２）を示す図である。図２４に示す例では、エラー通知と共に、カスタマイズ可能なＵＩ部品の種別が通知される。例えば、図２４に示す例では、通知手段４０１は、操作者の権限に応じて「テキスト」部品ならカスタマイズできる旨を通知する。また、通知手段４０１は、ＵＩ部品同士が干渉する場合、干渉してもよいＵＩ部品の種別「ボタン」を判断し、「ボタン」なら重ねることができる旨を通知する。
【０１０４】
以上の構成により、編集不可の場合に、その旨を通知することができる。また、編集不可の場合に、編集可能なＵＩ部品の種別や編集内容を通知することもできる。
【０１０５】
＜動作＞
次に、実施例３におけるＭＦＰ３の動作について説明する。図２５は、実施例３におけるエラー通知処理の一例（その１）を示すフローチャートである。図２５に示すステップＳ８０１で、通知手段４０１は、判断手段１０５によりカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧであれば（ステップＳ８０１−ＹＥＳ）ステップＳ８０２に進み、カスタマイズＮＧでなければ（ステップＳ８０１−ＮＯ）処理を終了する。
【０１０６】
ステップＳ８０２で、通知手段４０１は、「権限がありません」というエラー表示を行って、操作者に通知する。
【０１０７】
図２６は、実施例３におけるエラー通知処理の一例（その２）を示すフローチャートである。図２６に示すステップＳ９０１で、通知手段４０１は、判断手段１０５によりカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧであれば（ステップＳ９０１−ＹＥＳ）ステップＳ９０２に進み、カスタマイズＮＧでなければ（ステップＳ９０１−ＮＯ）処理を終了する。
【０１０８】
ステップＳ９０２で、通知手段４０１は、権限情報、優先情報（種別単位の優先度と組み合わせテーブル）に基づき、ＭＦＰ３に認証されている操作者にカスタマイズ可能なＵＩ部品の種別を取得する。
【０１０９】
ステップＳ９０３で、通知手段４０１は、「権限がない旨」と編集可能なカスタマイズ内容を表示部１７に表示して、操作者に通知する。
【０１１０】
以上、実施例３によれば、編集不可の場合に、その旨を通知することができたり、編集可能なＵＩ部品の種別や編集内容を合わせて通知することもできたりする。
【０１１１】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせて画像形成装置を構成することも可能である。
【０１１２】
なお、実施例において説明した処理内容をプログラムとし、このプログラムをコンピュータに実行させて前述した処理を画像形成装置に実行させることも可能である。また、このプログラムを記録媒体に記録し、このプログラムが記録された記録媒体をコンピュータに読み取らせて、前述した処理を画像形成装置に実行させることも可能である。
【符号の説明】
【０１１３】
１ 画像形成装置
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１４ 外部記録装置Ｉ／Ｆ部
１５ ネットワークＩ／Ｆ部
１６ 操作部
１７ 表示部
１８ エンジン部
１０１ 記憶部
１０２ 権限情報記憶手段
１０３ 優先情報記憶手段
１０４ 操作手段
１０５ 判断手段
１０６ 編集制御手段
２０１ 権限判断手段
２０２ 編集可否判断手段
３０１ 権限情報編集手段
３０２ 優先情報編集手段
４０１ 通知手段
【先行技術文献】
【特許文献】
【０１１４】
【特許文献１】特開２００７−３２３２３４号公報
【技術分野】
【０００１】
本発明は、ＵＩ部品の編集を行う画像処理装置、編集方法及び編集プログラムに関する。
【背景技術】
【０００２】
近年、画像形成装置（ＭＦＰ：Multifunction Peripheral）の操作画面において、ユーザが使いやすいようにカスタマイズ（編集）したいというニーズが高まっている。ＭＦＰの操作画面（ＵＩ画面ともいう）をカスタマイズする際、画面を構成するＵＩ要素（部品）毎にアクセス権を管理する技術がある。
【０００３】
例えば、特許文献１（特開２００７−３２３２３４号公報）には、ＵＩカスタマイズの権限管理を行うという目的で、ＵＩ部品毎にメタ情報を持たせて、メタ情報の中の権限情報を使って権限管理をさせる構成が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１の技術によれば、ＵＩ部品1つ1つにアクセス権等の情報を記載したメタ情報が必要となる。よって、新しいＵＩ部品を追加した際に、例えそのＵＩ部品が既存のものと同じようなものであっても、そのメタ情報にアクセス権を追加する必要があるという問題があった。さらに、ＵＩ部品のカスタマイズをした際、ＵＩ部品同士が干渉（重なるなど）した場合に、どのＵＩ部品のアクセス権を優先すべきかの判断が難しいという問題があった。
【０００５】
そこで、本発明は上記問題に鑑みてなされたものであり、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる画像形成装置、編集方法及び編集プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一局面の画像処理装置は、ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、前記種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、前記操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を、前記権限情報に基づき判断する第１判断手段と、編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、前記第１及び第２判断手段の判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御手段と、を備える。
【０００７】
また、本発明の他の局面の編集方法は、画像形成装置に実行される編集方法であって、編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、を有する。
【０００８】
また、本発明は、本発明の編集方法を実行するためのプログラムを記録した記録媒体をコンピュータに読み取らせて実現することも可能である。
【発明の効果】
【０００９】
本発明によれば、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。
【図面の簡単な説明】
【００１０】
【図１】実施例１におけるＭＦＰのハードウェアの一例を示すブロック図。
【図２】実施例１におけるＭＦＰの機能の一例を示すブロック図。
【図３】判断手段の機能の一例を示すブロック図。
【図４】ＵＩ部品の種別の一例を示す図。
【図５】権限情報の一例を示す図。
【図６】優先情報の一例を示す図。
【図７】ＵＩ部品同士が干渉する例を示す図。
【図８】関連付けがＵＩ部品同士の連動関係である場合の例を示す図。
【図９】関連付けがＵＩ部品同士の排他関係である場合の例を示す図。
【図１０】編集可否判断処理の一例（その１）を示すフローチャート。
【図１１】編集可否判断処理の一例（その２）を示すフローチャート。
【図１２】編集可否判断処理の一例（その３）を示すフローチャート。
【図１３】実施例２におけるＭＦＰの機能の一例を示すブロック図。
【図１４】操作者の権限を変更する例を説明するための図。
【図１５】ＵＩ部品の種別を新規に権限情報に追加する例を説明するための図。
【図１６】種別単位の優先度を変更する例を説明するための図。
【図１７】ＵＩ部品の種別を新規に優先情報に追加する例を説明するための図。
【図１８】権限を変更する処理の一例を示すフローチャート。
【図１９】新規種別を権限情報に追加する処理の一例を示すフローチャート。
【図２０】優先度を変更する処理の一例を示すフローチャート。
【図２１】優先度に種別を追加する処理の一例を示すフローチャート。
【図２２】実施例３におけるＭＦＰの機能の一例を示すブロック図。
【図２３】エラー通知の一例（その１）を示す図。
【図２４】エラー通知の一例（その２）を示す図。
【図２５】エラー通知処理の一例（その１）を示すフローチャート。
【図２６】エラー通知処理の一例（その２）を示すフローチャート。
【発明を実施するための形態】
【００１１】
以下、本発明の実施例を図面に基づいて説明する。
［実施例１］
＜ハードウェア＞
図１は、実施例１におけるＭＦＰ１のハードウェアの一例を示すブロック図である。図１に示すように、ＭＦＰ１は、制御部１１、主記憶部１２、補助記憶部１３、外部記録装置Ｉ／Ｆ部１４、ネットワークＩ／Ｆ部１５、操作部１６、表示部１７、エンジン部１８を含む。これら各構成は、バスを介して相互にデータ送受信可能に接続されている。
【００１２】
制御部１１は、コンピュータの中で、各装置の制御やデータの演算、加工を行うＣＰＵである。また、制御部１１は、主記憶部１２や補助記憶部１３に記憶されたプログラムを実行する演算装置であり、入力装置や記憶装置からデータを受け取り、演算、加工した上で、出力装置や記憶装置に出力する。
【００１３】
主記憶部１２は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）などであり、制御部１１が実行する基本ソフトウェアであるＯＳやアプリケーションソフトウェアなどのプログラムやデータを記憶又は一時保存する記憶装置である。
【００１４】
補助記憶部１３は、ＨＤＤ（Hard Disk Drive）などであり、アプリケーションソフトウェアなどに関連するデータを記憶する記憶装置である。
【００１５】
外部記録装置I／F部１４は、ＵＳＢ（Universal Serial Bus）などのデータ伝送路を介して接続された記録媒体１９（例えば、フラッシュメモリ、ＳＤカードなど）とＭＦＰ１とのインタフェースである。
【００１６】
また、記録媒体１９に、所定のプログラムを格納し、この記録媒体１９に格納されたプログラムは外部記録装置Ｉ／Ｆ部１４を介してＭＦＰ１にインストールされ、インストールされた所定のプログラムはＭＦＰ１により実行可能となる。
【００１７】
ネットワークＩ／Ｆ部１５は、有線及び／又は無線回線などのデータ伝送路により構築されたＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などのネットワークを介して接続された通信機能を有する周辺機器とＭＦＰ１とのインタフェースである。
【００１８】
操作部１６や表示部１７は、キースイッチ（ハードキー）とタッチパネル機能（ＧＵＩのソフトウェアキーを含む：Graphical User Interface）を備えたＬＣＤ（Liquid Crystal Display）とから構成され、ＭＦＰ１が有する機能を利用する際のＵＩ（User Interface）として機能する表示及び／又は入力装置である。
【００１９】
エンジン部１８は、画像データの入出力ユニットとして、紙原稿の読み取り転写紙への印刷を行う。エンジン部１８は、スキャナエンジンなどをさらに備えてもよい。
【００２０】
＜構成＞
次に、実施例１におけるＭＦＰ１の機能について説明する。図２は、実施例１におけるＭＦＰ１の機能の一例を示すブロック図である。
【００２１】
図２に示すＭＦＰ１は、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６を含む。記憶手段１０１は、各操作画面の画面データを記憶したり、操作画面の各ＵＩ部品のデータを記憶したりする。また、記憶手段１０１は、権限情報記憶手段１０２、優先情報記憶手段１０３を含む。
【００２２】
権限情報記憶手段１０２は、ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報を記憶する。ＵＩ部品の種別とは、例えば、ボタン、テキスト、リストボタン、入力エリア、状態表示エリアなどである。ＵＩ部品の種別に対する操作者の権限とは、例えば、テキストのＵＩ部品に対し、Ａさんは編集可又はＢさんは編集不可というような権限である。
【００２３】
優先情報記憶手段１０３は、ＵＩ部品の種別に対する編集の優先度を表す優先情報を記憶する。編集の優先度は、例えば、ＵＩ部品の種別に１，２，３・・・などの優先順を付与したり、テキスト＞ボタン＞リストボタン・・・などの不等号を用いて優先を表したりする。
【００２４】
操作手段１０４は、操作部１６からの各種操作を受け付ける。例えば、操作手段１０４は、記憶部１０１内の画面データに基づく操作画面をカスタマイズ（編集）する編集画面を表示制御し、操作画面内のＵＩ部品の編集指示を受け付ける。ＵＩ部品の編集には、サイズの拡大縮小、位置の変更などがある。操作手段１０４は、編集対象のＵＩ部品と、編集指示内容と、編集を行った操作者（ログインユーザ名）などを判断手段１０５に出力する。
【００２５】
判断手段１０５は、ＵＩ部品の編集指示に対し、操作者の権限と、優先度とに基づいて編集を許可するか否かを判定する。図３は、判断手段１０５の機能の一例を示すブロック図である。
【００２６】
図３に示す判断手段１０５は、権限判断手段２０１、編集可否判断手段２０２を含む。権限判断手段２０１は、権限情報記憶手段１０２に記憶される権限情報を参照して、編集対象のＵＩ部品の種別に対し、操作者に権限があるか否かを判断する。権限判断手段２０１は、判断結果を編集制御手段１０６に出力する。
【００２７】
編集可否判断手段２０２は、編集対象のＵＩ部品を編集することで、他のＵＩ部品に影響を与える（他のＵＩ部品と干渉する又は重なる）場合、この編集を許可するか否かを判断する。他のＵＩ部品に影響を与えるとは、ＵＩ部品同士が重なったりすることである。
【００２８】
編集可否判断手段２０２は、優先情報記憶手段１０３に記憶される優先情報を参照して、編集対象のＵＩ部品の種別と他のＵＩ部品の種別のそれぞれの優先度を取得する。編集可否判断手段２０２は、編集対象のＵＩ部品の優先度の方が高い場合は、この編集を許可し、編集対象のＵＩ部品の優先度の方が低い場合は、この編集を不可とする。編集可否判断手段２０２は、判断結果を編集制御手段１０６に出力する。
【００２９】
なお、判断結果は、編集可否判断手段２０２からの判断結果に一本化してもよい。このとき、権限判断手段２０１は、判断結果を編集可否判断手段２０２に出力する。編集可否判断手段２０２は、操作者に権限がない場合は編集不可を判断結果する。
【００３０】
また、編集可否判断手段２０２は、操作者に権限がある場合でも編集対象のＵＩ部品の優先度が他のＵＩ部品の優先度より低ければ編集不可を判断結果とし、編集対象のＵＩ部品の優先度が他のＵＩ部品の優先度より高ければ編集可を判断結果とする。編集可否判断手段２０２は、操作者に権限がある場合で、編集対象のＵＩ部品が他のＵＩ部品に影響を与えない場合は編集可を判断結果とする。
【００３１】
図２に戻り、編集制御手段１０６は、判断手段１０５から取得した結果に基づき、ＵＩ部品のカスタマイズを制御する。編集制御手段１０６は、権限判断手段２０１からの判断結果が「操作者に権限ある」であり、編集可否判断手段２０２からの判断結果が「編集可」であればＵＩ部品の編集を編集指示に従って実行する。編集制御手段１０６は、ＵＩ部品を編集した画面データを記憶手段１０１に記憶する。記憶手段１０１は、編集後の画面データを、操作者ごとに管理してもよい。
【００３２】
以上の構成を有することで、ＵＩ部品には種別を関連付け、種別毎に権限を確認したりすることができ、既存の権限を流用したりすることができる。編集をすることで、ＵＩ部品間が干渉をする場合は、どのＵＩ部品を優先して編集するかを決定することができる。
【００３３】
＜各種情報＞
図４は、ＵＩ部品の種別の一例を示す図である。図４に示すＵＩ部品の種別は、ＵＩ部品に対し、テキスト、ボタン、リストボタン、入力エリア、状態表示エリアなどが定義されている。例えば、このＵＩ部品の種別情報は、記憶部１０１に記憶されている。
【００３４】
図５は、権限情報の一例を示す図である。図５に示す権限情報は、ＵＩ部品の種別毎に、操作者それぞれの権限が設定されている。図５に示す「○」は例えば権限あり（カスタマイズ可能）を示し、「×」は権限なし（カスタマイズ不可）を示す。
【００３５】
図６は、優先情報の一例を示す図である。図６に示す優先情報は、種別単位の優先度と組み合わせテーブルとの一例を示す図である。図６に示す種別の単位の優先度は、
ボタン＞リストボタン＞入力エリア＞状態表示エリア＝テキスト
となっている。これは、ボタンの優先度が一番高く、状態表示エリア及びテキストの優先度が一番低いことを示す。
【００３６】
図６に示す組み合わせテーブルは、干渉される側とする側のＵＩ部品の種別に対し、どちらを優先するかを示すテーブルである。例えば、干渉する（編集対象のＵＩ部品）側の種別が「ボタン」であり、干渉される（他のＵＩ部品）側の種別が「テキスト」である場合、「ボタン」の優先度が高いため、「ボタン」の編集が許可されることを示す。
【００３７】
また、干渉する側の種別が「テキスト」であり、干渉される側の種別が「ボタン」である場合、「ボタン」の優先度が高いため、「テキスト」の編集は許可されないことを示す。また、「後優先」は、お互いの優先度が同じ（状態表示エリア＝テキスト）であるため、後からカスタマイズした内容が反映されることを示す。なお、種別単位の優先度が決まれば、組み合わせテーブルは自動生成可能である。よって、組み合わせテーブルは、必ずしも記憶される必要はない。
【００３８】
＜編集例＞
次に、図５、６の情報に基づいたカスタマイズの例について説明する。図７は、ＵＩ部品同士が干渉する例を示す図である。図７（Ａ）は、「ボタン」を大きくするカスタマイズにより、「テキスト」の一部が見えなくなる例を示す。ＵＩ部品の種別の「ボタン」と「テキスト」とでは、「ボタン」の方が優先度が高い（図６参照）。
【００３９】
・Ａさんが操作者の場合
権限判断手段２０１は、Ａさんが「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段１０６は、この編集は可能であるため、編集を実行する。
【００４０】
・Ｂさんが操作者の場合
権限判断手段２０１は、Ｂさんが「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限なしと判断する。編集可否判断手段２０２は、権限判断手段２０１の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため編集を実行しない。つまり、Ｂさんによるボタンのサイズ変更はできない。
【００４１】
・管理者が操作者の場合
権限判断手段２０１は、管理者が「ボタン」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉する側の優先度が高いため、編集可と判断する。よって、編集制御手段１０６は、この編集は可能であるため、編集を実行する。
【００４２】
次に、図７（Ｂ）は、「状態表示エリア」を大きくするカスタマイズにより、「リストボタン」の一部が見えなくなる例を示す。ＵＩ部品の種別の「状態表示エリア」と「リストボタン」とでは、「リストボタン」の方が優先度が高い（図６参照）。
【００４３】
・Ａさんが操作者の場合
権限判断手段２０１は、Ａさんが「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため、編集を実行しない。つまり、Ａさんによる「状態表示エリア」の変更はできない。
【００４４】
・Ｂさんが操作者の場合
権限判断手段２０１は、Ｂさんが「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限なしと判断する。編集可否判断手段２０２は、権限判断手段２０１の判断結果により優先情報を参照するまでもなく編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため編集を実行しない。つまり、Ｂさんによる「状態表示エリア」の変更はできない。
【００４５】
・管理者が操作者の場合
権限判断手段２０１は、管理者が「状態表示エリア」を編集可能かどうか（権限があるかどうか）を、権限情報を参照して判断する。この場合、権限判断手段２０１は、権限ありと判断する。編集可否判断手段２０２は、干渉される側の優先度が高いため、編集不可と判断する。よって、編集制御手段１０６は、この編集は不可であるため、編集を実行しない。つまり、管理者による「状態表示エリア」の変更はできない。
【００４６】
次に、ＵＩ部品同士に関連付けが行われている場合、いずれかのＵＩ部品に編集権限があれば、関連付けられたＵＩ部品同士の編集を可能とする例について説明する。図８は、関連付けがＵＩ部品同士の連動関係である場合の例を示す図である。
【００４７】
図８（Ａ）は、片面集約ボタンａ１１が選択されている場合、枚数選択のリストボタンａ２１が連動して表示される例を示す。図８（Ｂ）は、両面集約ボタンａ１２が選択されている場合、枚数選択のリストボタンａ２２が連動して表示される例を示す。図８（Ａ）（Ｂ）は、集約選択ボタンに枚数選択リストボタンが連動している。
【００４８】
例えば、Ａさんがリストボタンを編集する場合を考える。このとき、権限判断手段２０１は、Ａさんが枚数選択リストボタンの種別「リストボタン」を編集可能かどうか（権限があるかどうか）及び枚数選択リストボタンに連動する集約選択ボタンの種別「ボタン」を編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段２０１は、「ボタン」に対して権限ありと判断する。
【００４９】
ここで、連動するＵＩ部品のうち、一つでも権限ありのＵＩ部品があれば、権限判断手段２０１は、連度するＵＩ部品（例えば集約選択ボタン、枚数選択リストボタン）全てを編集可と判断する。よって、編集制御手段１０６は、この枚数選択リストボタンの編集は可能であるため、編集を実行する。
【００５０】
一般的に、カスタマイズ（編集）をする場合は、所定のＵＩ部品に対し、意味のある集合単位で行うことが多い。しかしながら、集合単位でアクセス（カスタマイズ）権限を設定するのは非常に大変である。しかし、煩雑な設定をしなくても、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とする。これにより、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００５１】
次に、関連付けの例が排他関係の場合について説明する。図９は、関連付けがＵＩ部品同士の排他関係である場合の例を示す図である。
【００５２】
図９（Ａ）は、片面集約ボタンが選択されている場合の例を示す。図９（Ｂ）は、両面集約ボタンが選択されている場合の例を示す。図９（Ｂ）には、両面集約に必要な開き方向の選択リストボタンａ３１が表示されている。一方、図９（Ａ）には、片面集約の場合、開き方向は不要であるため、開き方向の選択リストボタンａ３１は表示されない。
【００５３】
つまり、開き方向の選択リストボタンａ３１は、両面集約ボタンａ１２であれば表示され、片面集約ボタンａ１１であれば表示されないという排他的な関係にある。このとき、開き方向の選択リストボタンａ３１は、両面集約ボタンａ１２と関連付けされる。
【００５４】
例えば、Ａさんが開き方向の選択リストボタンａ３１を編集する場合を考える。このとき、権限判断手段２０１は、Ａさんが開き方向の選択リストボタンａ３１の種別「リストボタン」を編集可能かどうか（権限があるかどうか）及び開き方向の選択リストボタンａ３１に連動する両面集約ボタンａ１２の種別「ボタン」を編集可能かどうかを、権限情報を参照して判断する。この場合、権限判断手段２０１は、「ボタン」に対して権限ありと判断する。
【００５５】
ここで、関連付けられたＵＩ部品のうち、一つでも権限ありのＵＩ部品があれば、権限判断手段２０１は、関連付けられたＵＩ部品（例えば両面選択ボタン、開き方向の選択リストボタン）全てを編集可と判断する。よって、編集制御手段１０６は、この開き方向の選択リストボタンの編集は可能であるため、編集を実行する。なお、関連付けられた関連ＵＩ部品情報は、記憶手段１０１に予め記憶されているとする。判断手段１０５が、記憶手段１０１に記憶されている関連ＵＩ部品情報を参照して、前述した判断を行う。
【００５６】
これにより、開き方向の選択リストボタンのように、排他的な関係を有するＵＩ部品であっても、煩雑な設定をしなくてすむ。また、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００５７】
＜動作＞
次に、ＭＦＰ１の動作について説明する。図１０は、実施例１における編集可否判断処理の一例（その１）を示すフローチャートである。図１０に示すステップＳ１０１で、判断手段１０５は、機器に認証されている操作者の権限を、権限情報を参照することでチェックする。
【００５８】
ステップＳ１０２で、判断手段１０５は、操作者による編集指示が、権限がある種別のＵＩ部品のカスタマイズであるかを判定する。権限がある種別であれば（ステップＳ１０２−ＹＥＳ）ステップＳ１０３に進み、権限がない種別であれば（ステップＳ１０２−ＮＯ）ステップＳ１０６に進む。
【００５９】
ステップＳ１０３で、判断手段１０５は、操作者による編集指示の内容（カスタマイズ内容）が、他のＵＩ部品に干渉するかを判定する。他のＵＩ部品と干渉すれば（ステップＳ１０３−ＹＥＳ）ステップＳ１０４に進み、他のＵＩ部品と干渉しなければ（ステップＳ１０３−ＮＯ）ステップＳ１０６に進む。
【００６０】
ステップＳ１０４で、判断手段１０５は、干渉する（編集対象の）ＵＩ部品と干渉されるＵＩ部品の優先度の関係から、編集をしてもよいかを判定する。干渉するＵＩ部品の優先度の方が高ければ（ステップＳ１０４−ＹＥＳ）ステップＳ１０５に進み、干渉されるＵＩ部品の優先度の方が高ければ（ステップＳ１０４−ＮＯ）ステップＳ１０６に進む。
【００６１】
ステップＳ１０５で、判断手段１０５は、操作者による編集指示を、カスタマイズＯＫ（編集可）と判断する。
【００６２】
ステップＳ１０６で、判断手段１０５は、操作者による編集指示を、カスタマイズＮＧ（編集不可）と判断する。
【００６３】
次に、ＵＩ部品の関連付けを考慮する場合の判断処理について説明する。図１１は、編集可否判断処理の一例（その２）を示すフローチャートである。図１１に示す処理は、図１０に示すステップＳ１０６の後に行われる。
【００６４】
ステップＳ２０１で、判断手段１０５は、ステップＳ１０６でカスタマイズＮＧと判断されたかを判定する。カスタマイズＮＧ（編集不可）と判断されれば（ステップＳ２０１−ＹＥＳ）ステップＳ２０２に進み、カスタマイズＯＫ（編集可）と判断されれば（ステップＳ２０１−ＮＯ）処理を終了する。
【００６５】
ステップＳ２０２で、判断手段１０５は、カスタマイズ対象のＵＩ部品と連動関係にあるＵＩ部品が操作画面上にあるかを判定する（図８参照）。連動関係にあるＵＩ部品があれば（ステップＳ２０２−ＹＥＳ）ステップＳ２０３に進み、連動関係にあるＵＩ部品がなければ（ステップＳ２０２−ＮＯ）処理を終了する。
【００６６】
ステップＳ２０３に進み、判断手段１０５は、連動関係にあるＵＩ部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合（ステップＳ２０３−ＹＥＳ）ステップＳ２０４に進み、カスタマイズ権限がない場合（ステップＳ２０３−ＮＯ）処理を終了する。
【００６７】
ステップＳ２０４で、判断手段１０５は、カスタマイズ対象のＵＩ部品に対し、カスタマイズＯＫ（編集可）と判断する。
【００６８】
図１２は、編集可否判断処理の一例（その３）を示すフローチャートである。図１２に示す処理は、図１０に示すステップＳ１０６の後に行われる。
【００６９】
ステップＳ３０１で、判断手段１０５は、ステップＳ１０６でカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧ（編集不可）と判断されれば（ステップＳ３０１−ＹＥＳ）ステップＳ３０２に進み、カスタマイズＯＫ（編集可）と判断されれば（ステップＳ３０１−ＮＯ）処理を終了する。
【００７０】
ステップＳ３０２で、判断手段１０５は、カスタマイズ対象のＵＩ部品と排他関係にあるＵＩ部品が操作画面上にあるかを判定する（図９参照）。排他関係にあるＵＩ部品があれば（ステップＳ３０２−ＹＥＳ）ステップＳ３０３に進み、排他関係にあるＵＩ部品がなければ（ステップＳ３０２−ＮＯ）処理を終了する。
【００７１】
ステップＳ３０３に進み、判断手段１０５は、排他関係にあるＵＩ部品に対して、操作者はカスタマイズ権限があるかを判定する。カスタマイズ権限がある場合（ステップＳ３０３−ＹＥＳ）ステップＳ３０４に進み、カスタマイズ権限がない場合（ステップＳ３０３−ＮＯ）処理を終了する。
【００７２】
ステップＳ３０４で、判断手段１０５は、カスタマイズ対象のＵＩ部品に対し、カスタマイズＯＫ（編集可）と判断する。
【００７３】
以上、実施例１によれば、ＵＩ部品の種別単位で編集権限を管理することで、操作画面のＵＩ部品やユーザの権限を効率的に管理することで、カスタマイズを容易にすることができる。また、実施例１によれば、種別単位で管理を行うことで、新しいＵＩ部品が追加された場合でも、編集権限を流用することができる。
【００７４】
また、実施例１によれば、ＵＩ部品の種別間の優先度から編集の可否を判断するため、ＵＩ部品が干渉した場合に、容易に編集可否を判断することができる。また、実施例１によれば、所定の意味のある集合内のＵＩ部品に対し関連付けを行っていれば、その集合内のＵＩ部品の1つに権限がある場合、その集合内のカスタマイズは全て可能とすることで、煩雑な設定をしなくても、適切なカスタマイズが可能になる。
【００７５】
［実施例２］
次に、実施例２におけるＭＦＰ２について説明する。実施例２では、記憶手段１０１に記憶される権限情報や優先情報を編集する。実施例２におけるＭＦＰ２のハードウェアは実施例１と同様であるため、その説明を省略する。
【００７６】
＜構成＞
図１３は、実施例２におけるＭＦＰ２の機能の一例を示すブロック図である。図１３に示すＭＦＰ２は、権限情報編集手段３０１、優先情報編集手段３０２、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６を含む。図１３に示す機能において、図２に示す機能と同様のものは同じ符号を付し、その説明を省略する。
【００７７】
権限情報編集手段３０１は、図５に示す権限情報にアクセスし、編集を行う。例えば、権限情報の編集画面を表示制御し、操作者からの編集指示を権限情報に反映させる。権限情報編集手段３０１は、例えば、操作者の権限を変更する。
【００７８】
図１４は、操作者の権限を変更する例を説明するための図である。図１４に示す例では、権限情報編集手段３０１は、Ｂさんの「入力エリア」の権限を「×：カスタマイズ不可」から「○：カスタマイズ可」に変更する。また、権限情報編集手段３０１は、管理者の「リストボタン」の権限を「○：カスタマイズ可」から「×：カスタマイズ不可」に変更する。これにより、種別毎の権限を編集することができ、操作者の環境に合うよう最適な権限情報にすることができる。
【００７９】
権限情報編集手段３０１は、ＵＩ部品の種別を新規に追加することもできる。図１５は、ＵＩ部品の種別を新規に権限情報に追加する例を説明するための図である。図１５に示す例では、権限情報編集手段３０１は、種別「アイコン」を新規に権限情報に追加する。この「アイコン」には、Ａさん、Ｂさん、管理者全てに対し、「○：カスタマイズ可」が設定される。これにより、新しいＵＩ部品の種別を追加することができ、新しいＵＩ部品も権限情報に従って編集することができる。
【００８０】
優先情報編集手段３０２は、図６に示す優先情報にアクセスし、編集を行う。例えば、優先情報の編集画面を表示制御し、操作者からの編集指示を優先情報に反映させる。優先情報編集手段３０２は、例えば、種別単位の優先度を変更する。
【００８１】
図１６は、種別単位の優先度を変更する例を説明するための図である。図１６に示す例では、優先情報編集手段３０２は、「状態表示エリア」を「テキスト」よりも優先度を高くする変更を行う。この変更に伴い、組み合わせテーブルも自動で変更される（図１６参照）。干渉する側「状態表示エリア」及び干渉される側「テキスト」、干渉する側「テキスト」及び干渉される側「状態表示エリア」が「後優先」から「状態表示エリア」に変更される。これにより、種別間の優先度を編集することができ、操作者の環境に合うよう最適な優先情報にすることができる。
【００８２】
優先情報編集手段３０２は、ＵＩ部品の種別を新規に追加することもできる。図１７は、ＵＩ部品の種別を新規に優先情報に追加する例を説明するための図である。図１７に示す例では、優先情報編集手段３０２は、種別「アイコン」を、「状態表示エリア」及び「テキスト」と同じ優先度として追加する。
【００８３】
この追加に伴い、組み合わせテーブルも自動で変更される（図１７参照）。干渉するＵＩ部品間の優先度が同じ場合は「後優先」となる。これにより、新しいＵＩ部品の種別を追加することができ、新しいＵＩ部品も種別間の優先情報に従って編集することができる。
【００８４】
以上の構成により、ＭＦＰ２は、権限情報の権限を編集したり、ＵＩ部品の種別の権限を新規に追加したり、容易に編集することができる。また、ＭＦＰ２は、優先情報の権限を編集したり、ＵＩ部品の種別の優先度を追加したり、容易に編集することができる。
【００８５】
＜動作＞
次に、実施例２におけるＭＦＰ２の動作について説明する。図１８は、権限を変更する処理の一例を示すフローチャートである。図１８に示すステップＳ４０１で、権限情報編集手段３０１は、権限情報記憶手段１０２から権限情報を取得する。
【００８６】
ステップＳ４０２で、権限情報編集手段３０１は、ＵＩ部品の種別、操作者の情報から権限情報に設定された権限値を検索し、この権限値を変更する。
【００８７】
ステップＳ４０３で、権限情報編集手段３０１は、ステップＳ４０２の変更内容に基づいて、権限情報記憶手段１０２に記憶される権限情報を更新する（図１４参照）。
【００８８】
図１９は、新規種別を権限情報に追加する処理の一例を示すフローチャートである。図１９に示すステップＳ５０１で、権限情報編集手段３０１は、権限情報記憶手段１０２から権限情報を取得する。
【００８９】
ステップＳ５０２で、権限情報編集手段３０１は、新規ＵＩ部品の種別を権限情報に追加し、適切な権限値を入力する。
【００９０】
ステップＳ５０３で、権限情報編集手段３０１は、ステップＳ５０２の新規種別の追加に基づいて、権限情報記憶手段１０２に記憶される権限情報を更新する（図１５参照）。
【００９１】
図２０は、優先度を変更する処理の一例を示すフローチャートである。図２０に示すステップＳ６０１で、優先情報編集手段３０２は、優先情報記憶手段１０３から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。
【００９２】
ステップＳ６０２で、優先情報編集手段３０２は、種別単位の優先度を変更し、組み合わせテーブルを優先度の変更に従って適切に変更する。
【００９３】
ステップＳ６０３で、優先情報編集手段３０２は、ステップＳ６０２の変更内容に基づいて、優先情報記憶手段１０３に記憶される優先情報を更新する（図１６参照）。
【００９４】
図２１は、優先度に種別を追加する処理の一例を示すフローチャートである。図２１に示すステップＳ７０１で、優先情報編集手段３０２は、優先情報記憶手段１０３から優先情報を取得する。ここでは、優先情報は、種別単位の優先度及び組み合わせテーブルをいう。
【００９５】
ステップＳ７０２で、優先情報編集手段３０２は、優先度に新規種別を追加して、組み合わせテーブルを新規種別の優先度に従って適切に変更する。
【００９６】
ステップＳ７０３で、優先情報編集手段３０２は、ステップＳ７０２の変更内容に基づいて、優先情報記憶手段１０３に記憶される優先情報を更新する（図１７参照）。
【００９７】
以上、実施例２によれば、権限情報の権限を編集したり、ＵＩ部品の種別の権限を新規に追加したり、容易に編集することができる。また、実施例２によれば、優先情報の権限を編集したり、ＵＩ部品の種別の優先度を追加したり、容易に編集することができる。
【００９８】
［実施例３］
次に、実施例３におけるＭＦＰ３について説明する。実施例３のＭＦＰ３は、編集が不可と判断された場合、その旨を通知する。また、ＭＦＰ３は、カスタマイズが可能な編集内容を合わせて通知する。実施例３におけるＭＦＰ３のハードウェアは実施例１と同様であるため、その説明を省略する。
【００９９】
＜構成＞
図２２は、実施例３におけるＭＦＰ３の機能の一例を示すブロック図である。図２２に示すＭＦＰ３は、記憶手段１０１、操作手段１０４、判断手段１０５、編集制御手段１０６、通知手段４０１を含む。図２２に示す機能において、図２に示す機能と同様のものは同じ符号を付し、その説明を省略する。
【０１００】
通知手段４０１は、判断手段１０５によりカスタマイズＮＧと判断された旨の通知を受ける。通知手段４０１は、ＵＩ部品の編集がＮＧである（権限がない）ことを表示部１７に表示する（図２３参照）。
【０１０１】
図２３は、エラー通知の一例（その１）を示す図である。図２３に示す例では、エラー通知として「権限がありません」と画面に表示される。
【０１０２】
また、通知手段４０１は、操作者と干渉されるＵＩ部品の種別とから、編集可能なＵＩ部品とその内容とをエラー通知に含める（図２４）。
【０１０３】
図２４は、エラー通知の一例（その２）を示す図である。図２４に示す例では、エラー通知と共に、カスタマイズ可能なＵＩ部品の種別が通知される。例えば、図２４に示す例では、通知手段４０１は、操作者の権限に応じて「テキスト」部品ならカスタマイズできる旨を通知する。また、通知手段４０１は、ＵＩ部品同士が干渉する場合、干渉してもよいＵＩ部品の種別「ボタン」を判断し、「ボタン」なら重ねることができる旨を通知する。
【０１０４】
以上の構成により、編集不可の場合に、その旨を通知することができる。また、編集不可の場合に、編集可能なＵＩ部品の種別や編集内容を通知することもできる。
【０１０５】
＜動作＞
次に、実施例３におけるＭＦＰ３の動作について説明する。図２５は、実施例３におけるエラー通知処理の一例（その１）を示すフローチャートである。図２５に示すステップＳ８０１で、通知手段４０１は、判断手段１０５によりカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧであれば（ステップＳ８０１−ＹＥＳ）ステップＳ８０２に進み、カスタマイズＮＧでなければ（ステップＳ８０１−ＮＯ）処理を終了する。
【０１０６】
ステップＳ８０２で、通知手段４０１は、「権限がありません」というエラー表示を行って、操作者に通知する。
【０１０７】
図２６は、実施例３におけるエラー通知処理の一例（その２）を示すフローチャートである。図２６に示すステップＳ９０１で、通知手段４０１は、判断手段１０５によりカスタマイズＮＧ（編集不可）と判断されたかを判定する。カスタマイズＮＧであれば（ステップＳ９０１−ＹＥＳ）ステップＳ９０２に進み、カスタマイズＮＧでなければ（ステップＳ９０１−ＮＯ）処理を終了する。
【０１０８】
ステップＳ９０２で、通知手段４０１は、権限情報、優先情報（種別単位の優先度と組み合わせテーブル）に基づき、ＭＦＰ３に認証されている操作者にカスタマイズ可能なＵＩ部品の種別を取得する。
【０１０９】
ステップＳ９０３で、通知手段４０１は、「権限がない旨」と編集可能なカスタマイズ内容を表示部１７に表示して、操作者に通知する。
【０１１０】
以上、実施例３によれば、編集不可の場合に、その旨を通知することができたり、編集可能なＵＩ部品の種別や編集内容を合わせて通知することもできたりする。
【０１１１】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施例に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。また、前述した実施例の構成要素を全部又は複数を組み合わせて画像形成装置を構成することも可能である。
【０１１２】
なお、実施例において説明した処理内容をプログラムとし、このプログラムをコンピュータに実行させて前述した処理を画像形成装置に実行させることも可能である。また、このプログラムを記録媒体に記録し、このプログラムが記録された記録媒体をコンピュータに読み取らせて、前述した処理を画像形成装置に実行させることも可能である。
【符号の説明】
【０１１３】
１ 画像形成装置
１１ 制御部
１２ 主記憶部
１３ 補助記憶部
１４ 外部記録装置Ｉ／Ｆ部
１５ ネットワークＩ／Ｆ部
１６ 操作部
１７ 表示部
１８ エンジン部
１０１ 記憶部
１０２ 権限情報記憶手段
１０３ 優先情報記憶手段
１０４ 操作手段
１０５ 判断手段
１０６ 編集制御手段
２０１ 権限判断手段
２０２ 編集可否判断手段
３０１ 権限情報編集手段
３０２ 優先情報編集手段
４０１ 通知手段
【先行技術文献】
【特許文献】
【０１１４】
【特許文献１】特開２００７−３２３２３４号公報
【特許請求の範囲】
【請求項１】
ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、
前記種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、
前記操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を、前記権限情報に基づき判断する第１判断手段と、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、
前記第１及び第２判断手段の判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御手段と、
を備える画像形成装置。
【請求項２】
前記第１判断手段は、
前記第１ＵＩ部品と関連付けられている他の第３ＵＩ部品がある場合、前記第１又は第３ＵＩ部品の権限のいずれかが権限ありを示すとき、前記第１及び第３ＵＩ部品の編集を可能とする請求項１記載の画像形成装置。
【請求項３】
前記権限情報の権限の編集、操作者の権限の追加を行う権限編集手段をさらに備える請求項１又は２記載の画像形成装置。
【請求項４】
前記優先情報の優先度の編集、新規種別の優先度の追加を行う優先度編集手段をさらに備える請求項１乃至３いずれか一項に記載の画像形成装置。
【請求項５】
前記第１判断手段により権限なしと判断された場合、又は第２判断手段により編集不可と判断された場合、編集が不可を示すエラー通知を行う通知手段をさらに備える請求項１乃至４いずれか一項に記載の画像形成装置。
【請求項６】
前記通知手段は、
前記編集指示を行った操作者の権限に基づき、編集可能な編集内容を前記エラー通知とともに通知する請求項５記載の画像形成装置。
【請求項７】
画像形成装置に実行される編集方法であって、
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、
ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、
前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、
を有する編集方法。
【請求項８】
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、
ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、
前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、
をコンピュータに実行させるための編集プログラム。
【請求項１】
ＵＩ部品の各種別に対し、操作者の編集権限が設定された権限情報を記憶する第１記憶手段と、
前記種別に対する編集の優先度を表す優先情報を記憶する第２記憶手段と、
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作手段と、
前記操作手段が編集指示を受け付けた第１ＵＩ部品の種別に対応する権限を、前記権限情報に基づき判断する第１判断手段と、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断手段と、
前記第１及び第２判断手段の判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御手段と、
を備える画像形成装置。
【請求項２】
前記第１判断手段は、
前記第１ＵＩ部品と関連付けられている他の第３ＵＩ部品がある場合、前記第１又は第３ＵＩ部品の権限のいずれかが権限ありを示すとき、前記第１及び第３ＵＩ部品の編集を可能とする請求項１記載の画像形成装置。
【請求項３】
前記権限情報の権限の編集、操作者の権限の追加を行う権限編集手段をさらに備える請求項１又は２記載の画像形成装置。
【請求項４】
前記優先情報の優先度の編集、新規種別の優先度の追加を行う優先度編集手段をさらに備える請求項１乃至３いずれか一項に記載の画像形成装置。
【請求項５】
前記第１判断手段により権限なしと判断された場合、又は第２判断手段により編集不可と判断された場合、編集が不可を示すエラー通知を行う通知手段をさらに備える請求項１乃至４いずれか一項に記載の画像形成装置。
【請求項６】
前記通知手段は、
前記編集指示を行った操作者の権限に基づき、編集可能な編集内容を前記エラー通知とともに通知する請求項５記載の画像形成装置。
【請求項７】
画像形成装置に実行される編集方法であって、
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、
ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、
前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、
を有する編集方法。
【請求項８】
編集画面を表示制御し、操作画面内の各ＵＩ部品の編集指示を受け付ける操作ステップと、
ＵＩ部品の各種別に対し、操作者の権限が設定された権限情報に基づき、前記編集指示がなされた第１ＵＩ部品の種別に対応する権限を判断する第１判断ステップと、
編集後の前記第１ＵＩ部品と他の第２ＵＩ部品とが重なる場合、前記種別に対する編集の優先度を表す優先情報から取得した前記第１ＵＩ部品の種別に対応する優先度と前記第２ＵＩ部品の種別に対応する優先度とに基づき、前記第１ＵＩ部品の編集が可能か否かを判断する第２判断ステップと、
前記第１及び第２判断ステップの判断結果に基づき、前記第１ＵＩ部品の編集を制御する編集制御ステップと、
をコンピュータに実行させるための編集プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図８】
【図９】
【公開番号】特開２０１２−１４６１８５（Ｐ２０１２−１４６１８５Ａ）
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願番号】特願２０１１−４９００（Ｐ２０１１−４９００）
【出願日】平成２３年１月１３日（２０１１．１．１３）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２４年８月２日（２０１２．８．２）
【国際特許分類】
【出願日】平成２３年１月１３日（２０１１．１．１３）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]