(57)【要約】【課題】柔軟にＷｅｂＵＩにアクセスする。【解決手段】操作者のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第１の判断手段と、第１の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行う問い合わせ手段と、問い合わせ手段による問い合わせに対してコンテンツから返信された操作者のアクセス情報に対応するメニュー項目を受信する受信手段と、受信手段によって受信されたメニュー項目を表示する表示手段と、を含む。【選択図】図３
2013225199.tif 000002
【特許請求の範囲】
【請求項１】
操作者のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第１の判断手段と、
前記第１の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行う問い合わせ手段と、
前記問い合わせ手段による問い合わせに対して前記コンテンツから返信された前記操作者のアクセス情報に対応するメニュー項目を受信する受信手段と、
前記受信手段によって受信されたメニュー項目を表示する表示手段と、
を含むことを特徴とする表示制御装置。
【請求項２】
機器のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第２の判断手段をさらに含み、
前記問い合わせ手段は、前記第２の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行い、
前記受信手段は、前記問い合わせに対して前記コンテンツから返信された前記機器のアクセス情報に対応するメニュー項目を受信し、
前記表示手段は、前記受信手段によって受信されたメニュー項目を表示することを特徴とする請求項１に記載の表示制御装置。
【請求項３】
前記表示されるメニュー項目は、前記コンテンツのメニュー項目と紐付けられていることを特徴とする請求項１又は２に記載の表示制御装置。
【請求項４】
操作者のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第１の判断手段と、
前記第１の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行う問い合わせ手段と、
前記問い合わせ手段による問い合わせに対して前記コンテンツから返信された前記操作者のアクセス情報に対応するメニュー項目を受信する受信手段と、
前記受信手段によって受信されたメニュー項目を表示する表示手段と、を備えた表示制御手段を含むことを特徴とする情報処理装置。
【請求項５】
前記表示制御手段は、機器のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第２の判断手段をさらに含み、
前記問い合わせ手段は、前記第２の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行い、
前記受信手段は、前記問い合わせに対して前記コンテンツから返信された前記機器のアクセス情報に対応するメニュー項目を受信し、
前記表示手段は、前記受信手段によって受信されたメニュー項目を表示することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記表示されるメニュー項目は、前記コンテンツのメニュー項目と紐付けられていることを特徴とする請求項４又は５に記載の情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、表示制御装置及びこれを用いた情報処理装置に関する。
【背景技術】
【０００２】
複写機、ファクシミリ装置、及びプリンタ装置等の情報処理装置においては、入力インタフェースとして予め組み込まれたＧＵＩ（Graphical User Interface）が広く普及し、表示画面中のメニュー上の選択項目やアイコンを選択することにより操作が行われている。これは、選択可能な項目が明示されているため操作が簡単であり、操作体系を記憶しなくても良いので操作のための訓練が不要であるという利点によるものである。
【０００３】
また、アプリケーションソフトのユーザインタフェースとしてＷｅｂブラウザが情報処理装置内に組み込まれたＵＩ（以下、「組込みＷｅｂＵＩ」という。）において、情報処理装置の設定等を行う画面を辿るためのメニューを表示する際、表示不可能なメニューを隠す機能も既に知られている。表示が可能であるか否かを判断する基準は、ユーザの権限、情報処理装置に対するオプションの装着状態、情報処理装置の設定状態等、多種多様な基準があり、メニューにより様々である。
【０００４】
例えば、メニューがユーザ管理画面であれば、ユーザ管理権限を有しないユーザのときには非表示状態となり、メニューが無線ＬＡＮ（Local Area Network）設定画面であれば、無線ＬＡＮ用のオプションが情報処理装置に装着されていないときには、やはり非表示状態となる。また、組込みＷｅｂＵＩ及びメニューは動的に追加されるものであるから、製品出荷時には想定されていない表示条件が必要とされる可能性もある。
【０００５】
特許文献１には、動的に操作メニューを作成する目的で、文書情報に応じて操作メニューを作成するデータ処理装置が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記従来のメニューにおける表示が可能であるか否かに関するデータ処理装置の判断基準は、予め定められた条件に基づいて制御されているので、その後の使用状況の変化に応じて動的に表示条件を追加変更する等の仕組み自体がそもそも存在せず、柔軟に表示条件の変更を行うことができないという問題があった。
【０００７】
また、特許文献１に開示されたデータ処理装置には、表示が可能であるか否かの判断基準を、柔軟に追加変更する等の仕組み自体は構築されていないので、使用状況に応じて表示条件の変更を行うことができないという問題は解決されていない。
【０００８】
そこで、本発明は、上記従来の問題点に鑑みてなされたもので、メニュー上に表示が可能であるか否かの判断基準を、使用状況に応じて動的に変更することにより、組込みＷｅｂＵＩにアクセスすることができる表示制御装置及びこれを用いた情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、請求項１に記載の本発明における表示制御装置は、操作者のアクセス情報に応じて、メニュー項目を表示するか否かを判断する第１の判断手段と、前記第１の判断手段によって表示すると判断されたメニュー項目を構築するため、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合せを行う問い合わせ手段と、前記問い合わせ手段による問い合わせに対して前記コンテンツから返信された前記操作者のアクセス情報に対応するメニュー項目を受信する受信手段と、前記受信手段によって受信されたメニュー項目を表示する表示手段と、を含むことを特徴とする。
【発明の効果】
【００１０】
本発明によれば、メニュー上に表示が可能であるか否かの判断基準を、使用状況に応じて動的に変更することにより、組込みＷｅｂＵＩにアクセスすることが可能な表示制御装置及びこれを用いた情報処理装置を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施の形態における表示制御装置を含む情報処理装置のハードウェア構成例を示す図である。
【図２】本発明の実施形態における表示制御装置の組込みＷｅｂＵＩの静的構造について説明する図である。
【図３】本発明の実施形態における表示制御装置のメニュー表示時の動きについて説明する図である。
【図４】本発明の実施形態における表示制御装置の各メニューにおけるメニュー表示の判断例について説明するシーケンス図である。
【図５】本発明の実施形態における表示制御装置を備えた情報処理装置の組込みＷｅｂＵＩ画面の例について説明する図である。
【発明を実施するための形態】
【００１２】
次に、本発明を実施するための形態について図面を参照して詳細に説明する。なお、各図中、同一又は相当する部分には同一の符号を付しており、その重複説明は適宜に簡略化乃至省略する。本発明は、メニュー項目の表示の可否判断を行い、表示可能であると判断されたときには、表示制御プログラムのユーザインタフェースに関するコンテンツに対して問い合わせを行うことにより、メニュー項目を表示することが特徴になっている。
【００１３】
これにより、如何なるアクセス情報が発生したとしても、メニュー項目に紐付けられた画面のコンテンツにおいて表示の可否判断を論理的に実現することができる。また、動的に組込みＷｅｂＵＩメニュー項目が追加された場合にも、表示の可否判断基準はアクセス情報に依存するので、適切な表示制御が可能となるということが特徴になっている。
【００１４】
まず、最初に、本発明の実施形態における表示制御装置の構成について説明する。図１は、本発明の実施の形態における表示制御装置を含む情報処理装置のハードウェア構成例を示す図である。図１の情報処理装置１は、それぞれバスＢで相互に接続されているドライブ装置１０１と、補助記憶装置１０３と、メモリ装置１０４と、演算処理装置１０５と、表示制御装置１００と、入力装置１０７と等を有するように構成される。
【００１５】
情報処理装置１での処理を実現するプログラムは、ＣＤ−ＲＯＭ（Compact Disk-Read Only Memory）等の記録媒体１０２によって提供される。プログラムを記録した記録媒体１０２がドライブ装置１０１にセットされると、プログラムが記録媒体１０２からドライブ装置１０１を介して補助記憶装置１０３にインストールされる。補助記憶装置１０３は、インストールされたプログラムを格納すると共に、プログラムの処理に必要な各種のデータを格納する。
【００１６】
メモリ装置１０４は、プログラムの起動指示があった場合に、補助記憶装置１０３からプログラムを読み出して格納する。演算処理装置１０５は、メモリ装置１０４に格納されたプログラムにしたがって、情報処理装置１に係る機能を実行する。表示制御装置１００はプログラムによるＧＵＩ等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。
【００１７】
なお、情報処理装置１をネットワークを介して操作する場合、表示制御装置１００及び入力装置１０７は、必ずしも情報処理装置１に接続されている必要はない。また、プログラムのインストールは必ずしも記録媒体１０２より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしても良い。
【００１８】
図２は、本発明の実施形態における表示制御装置の組込みＷｅｂＵＩの静的構造について説明する図である。図１において、表示制御装置１００の静的構造は、Ａｃｔｉｏｎ  １０と、Ａｕｔｈ  Ｈｔｔｐ  Ｃｏｎｔｅｘｔ  １１と、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２と、Ｕｓｅｒ  Ｉｎｆｏ  １３と、Ａｃｔｉｏｎ  Ｂａｓｅ  １４と、Ｓｔａｔｉｃ  Ｃｏｎｔｅｎｔｓ  １５と、Ｍｅｎｕ  Ｉｔｅｍ  １６と、Ａｃｔｉｏｎ  Ｓｅｒｖｌｅｔ  １７と、Ｅｓｄｋ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ  １８と、Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ  １９と、Ｓｅｓｓｉｏｎ  ２０とから構成される。
【００１９】
ここで、Ａｃｔｉｏｎ  １０は、ＷｅｂＵＩコンテンツ（表示制御プログラムのユーザインタフェースに関するコンテンツ）に相当し、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２は、ＵＲＬ（Uniform Resource Locator）アクセス制御に相当し、Ｕｓｅｒ  Ｉｎｆｏ  １３は、認証情報に相当する。これ以外の構成は、ＵＩロジックコントローラに相当する。
【００２０】
次に、各構成部分の役割について説明する。まず、Ａｃｔｉｏｎ  １０は、自分（ＷｅｂＵＩ）へのアクセス権の判断を行い、ＷｅｂＵＩ固有の判断条件を組み込む。Ａｕｔｈ  Ｈｔｔｐ  Ｃｏｎｔｅｘｔ  １１は、リクエスト受付時の入口となるクラスである。
【００２１】
ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２は、メニュー表示可否判定、リクエストの承認共に同一ロジックが用いられる。ＵＲＬへのアクセスが可であればメニュー表示可とし、ＵＲＬへのアクセスが不可であれば、メニュー表示を不可とする。
【００２２】
また、Ｓｔａｔｉｃ  Ｃｏｎｔｅｎｔｓ  １５は、静的情報を保持するクラスであり、メニュー一覧もここに含まれる。Ａｃｔｉｏｎ  Ｓｅｒｖｌｅｔ  １７において、ｇｅｔ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ（）では、初めてコールされた場合にＲｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒのロード、及び初期化が行われる。ｉｎｔ（）内で一度Ｇｅｔ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒがコールされる。
【００２３】
そして、Ｅｓｄｋ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ  １８では、全ての処理において、Ｅｓｄｋ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒが利用される。Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒは、ｓｔｒｕｔｓ−ｃｏｎｆｉｇ．ｘｍｌでどのクラスを利用するかを指定できるため、ここで、Ｅｓｄ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒを使用できるように設定する。
【００２４】
Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ  １９は、Ａｃｔｉｏｎをインスタンス化し、実行するＳｔｒｕｔｓオリジナルクラスであり、生成したＡｃｔｉｏｎインスタンスのキャッシュも行っている。ｐａｔｈ（ＵＲＬではない）からＡｃｔｉｏｎを取得するＩ／Ｆ（Inter/Face）を追加する。
【００２５】
次に、図２のＷｅｂＵＩの静的構造の動作について説明する。Ａｕｔｈ  Ｈｔｔｐ  Ｃｏｎｔｅｘｔ  １１からＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２に対してアクセス権の確認がなされると、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２は、Ａｃｔｉｏｎ  １０に対してＡｃｔｉｏｎ  １０へのアクセス権の確認を行う。Ａｃｔｉｏｎ  １０は、Ｓｅｓｓｉｏｎ２０から送信されるＵｓｅｒ  Ｉｎｆｏ  １３の認証情報に対してＳｅｓｓｉｏｎの取得を行う。
【００２６】
また、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２は、Ａｃｔｉｏｎ  Ｓｅｒｖｌｅｔ  １７によって初期化されたＥｓｄｋ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ  １８に対してＡｃｔｉｏｎの取得を行う。そして、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２によってＡｃｔｉｏｎへのアクセス権の確認を求められたＡｃｔｉｏｎ  １０からＭｅｎｕ  Ｉｔｅｍ  １６に対してメニューが送信される。
【００２７】
このとき、メニューにはＡｃｔｉｏｎ（ビジネスロジック）が関連付けられる。メニューの表示条件は、Ａｃｔｉｏｎのアクセス権と等価である。メニュー表示可否を判断するには、Ａｃｔｉｏｎ  １０のアクセス権が判断される。
【００２８】
そして、Ｍｅｎｕ  Ｉｔｅｍ  １６からＳｔａｔｉｃ  Ｃｏｎｔｅｎｔｓ  １５に対してメニューが送信される。Ｍｅｎｕ  Ｉｔｅｍ  １６からメニューが送信されたＳｔａｔｉｃ  Ｃｏｎｔｅｎｔｓ  １５は、ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  １２に対してメニューアクセスの確認を送信する。
【００２９】
ここで、メニューは、Ａｃｔｉｏｎ  １０のＷｅｂＵＩコンテンツと紐付けられている。ＷｅｂＵＩコンテンツは、自分自身に対するアクセス可否の条件を認識しているが、どのような条件に依存するかは問わないものとする。すなわち、ＷｅｂＵＩコンテンツ自身に対するアクセス可否の条件を、メニューの表示条件と同一化することにより、柔軟なメニューの構築を実現している。
【００３０】
図２は、Ａｐａｃｈｅ  Ｓｏｆｔｗａｒｅ  Ｆｏｕｎｄａｔｉｏｎによって開発されているオープンソースのＷｅｂアプリケーションフレームワークであるＳｔｒｕｔｓをベースとしたＷｅｂＵＩ内部構造図であり、各メニューの処理を行うＡｃｔｉｏｎ  １０の基底クラスとして、抽象クラスのＡｃｔｉｏｎ  Ｂａｓｅ  １４を定義し、そこで表示可否判定処理が定義される。
【００３１】
表示可否判定処理では、各メニューにおいて任意の表示制御が実現される。具体的には、操作者の権限による表示制御、操作者の接続元ＩＰ（Internet Protocol）アドレスによる表示制御、機器オプションによる表示制御等、メニュー毎に独自の制御が実現される。これにより、各メニュー項目において表示条件が定義され、製品出荷後に追加されたメニュー、例えば、仮に新しい表示条件が発生した場合であっても対応することが可能となる。
【００３２】
次に、操作者（オペレータ）が表示制御装置のメニューを操作するときのメニュー表示の動作について説明する。図３は、本発明の実施形態における表示制御装置のメニュー表示時の動きについて説明する図である。
【００３３】
図３において、オペレータ２１がシステム２２に対してリクエストを行うと（１）、システム２２は、そのリクエストをＵＩロジックコントローラ２３に実行させ（１．１）、ＵＩロジックコントローラ２３は、認証２４から認証情報を取得する（１．２）と共に、ＵＲＬアクセス制御２５に対してリクエスト先のアクセス権を確認する（１．３）。
【００３４】
ＵＲＬアクセス制御２５は、ＷｅｂＵＩコンテンツ２６に対してアクセス権の確認を行い（１．４）、ＷｅｂＵＩコンテンツ２６は、認証情報２７からセッション（ユーザの権限情報等）を取得する（１．５）。ＷｅｂＵＩコンテンツ２６は、認証情報等を元にアクセス可否を判断し、アクセス権の確認を行う（１．６）。
【００３５】
ＵＩロジックコントローラ２３は、ＷｅｂＵＩコンテンツ２６に対してＷｅｂＵＩコンテンツを実行し（１．７）、ＷｅｂＵＩコンテンツ２６は、ＷｅｂＵＩコンテンツ２６の独自処理を行う（１．８）。ＵＩロジックコントローラ２３は、静的コンテンツストア２８に対してメニュー情報の取得を要求すると（１．９）、静的コンテンツストア２８は、ＵＲＬアクセス制御２５に対して各メニューのＵＲＬのアクセス権を確認する（１．１０）。ＵＲＬアクセス制御２５は、メニュー：ＷｅｂＵＩコンテンツ２９に対して、アクセス権の確認を要求する（１．１１）。
【００３６】
メニュー：ＷｅｂＵＩコンテンツ２９は、認証情報２７からセッション（ユーザの権限情報等）を取得し（１．１２）、アクセス権の確認を行う（１．１３）。なお、ＵＲＬアクセス制御２５においては、メニュー表示可否判定、リクエストのアクセス権確認共に同一ロジックが用いられ、アクセス権が可であるときにはメニュー表示可となり、アクセス権が不可であるときにはメニュー表示が不可となる。
【００３７】
そして、最後に、システム２２からオペレータ２１に対してレスポンスがなされる（１．１４）。なお、静的コンテンツストア２８が、ＵＲＬアクセス制御２５に対して各メニューＵＲＬのアクセス権を確認するとき、親メニューから子メニューを辿ってアクセス権を確認し、仮に、親メニューにアクセス権がない場合には、子メニューの確認を行わない。
【００３８】
このように、オペレータ２１がメニュー項目の表示をＷｅｂＵＩコンテンツ２６にリクエストすると、システム２２は、認証・承認等一般的な処理を行った後、表示可能なメニュー項目をオペレータ２１に対してレスポンスすることにより、最適なメニュー項目の構築がなされる。
【００３９】
システム２２は、メニュー項目構築の際に、各メニューに紐付けられたＷｅｂＵＩコンテンツ２６に対して、オペレータ２１の権限等の情報を基に表示可否を問い合わせる。ＷｅｂＵＩコンテツ２６は、コンテンツ独自の表示の可否判断を行い、表示の可否の判断結果をシステム２２に返す。
【００４０】
具体的には、フィニッシャー（プリント出力に連携した高速かつ高精度のパンチ（穴あけ）、ステープラー留め、紙折り等の後処理機能を行うオプション品）の装着時にのみ表示するメニュー項目であれば、フィニッシャー装着状態を確認した後に、表示の可否を判断する。システム２２は、表示の可否の判断結果を収集し、最適なメニュー項目を構築し、オペレータ２１に返す。これにより、オペレータ２１や機器の構成等そのときの各種アクセス条件に応じたメニュー項目を表示することが可能となる。
【００４１】
次に、表示制御装置の各メニューにおけるメニュー表示の判断例のシーケンスについて説明する。図４は、本発明の実施形態における表示制御装置の各メニューにおけるメニュー表示の判断例について説明するシーケンス図である。
【００４２】
図４において、オペレータ２１が、Ｗｅｂブラウザを用いてシステム２２に対してメニューが表示される画面へのリクエストを行うと（Ｓ３０１）、システム２２は、これをＵＩロジックコントローラ２３に対して実行させ（Ｓ３０２）、ＵＩロジックコントローラ２３は、認証２４に対して認証を行う（Ｓ３０３）。
【００４３】
ロジックコントローラ２３は、メニュー（１）のＷｅｂＵＩコンテンツ２６１に対してメニュー（１）の表示確認を行う。ここで、メニュー（１）のＷｅｂＵＩコンテンツ２６１は、管理者にのみ表示するメニューである。メニュー（１）のＷｅｂＵＩコンテンツ２６１は、認証２４から認証情報を取得する（Ｓ３０５）。
【００４４】
そして、メニュー（１）のＷｅｂＵＩコンテンツ２６１において、取得された認証状態が管理者である場合には、メニューを表示し（Ｓ３０６）、非管理者である場合には、メニューを表示しない（Ｓ３０７）のである。
【００４５】
次に、ＵＩロジックコントローラ２３は、メニュー（２）のＷｅｂＵＩコンテンツ２６２に対してメニュー（２）の表示確認を行う。ここで、メニュー（２）のＷｅｂＵＩコンテンツ２６２は、ファクシミリオプション装着時にのみ表示するメニューである。
【００４６】
メニュー（２）のＷｅｂＵＩコンテンツ２６２は、機器管理３０から機器オプション情報を取得し、メニュー（２）のＷｅｂＵＩコンテンツ２６２は、ファクシミリオプションが装着されている場合には、メニューを表示し（Ｓ３１０）、未装着である場合には、メニューを表示しない（Ｓ３１１）のである。
【００４７】
さらに、ＵＩロジックコントローラ２３は、メニュー（３）のＷｅｂＵＩコンテンツ２６３に対してメニュー（３）の表示確認を行う。ここで、メニュー（３）のＷｅｂＵＩコンテンツは、特定のＩＰアドレスからの接続時にのみ表示するメニューである。
【００４８】
メニュー（３）のＷｅｂＵＩコンテンツ２６３は、接続元ＩＰアドレスを取得し（Ｓ３１３）、接続元ＩＰアドレスが許可されるアドレスである場合には、メニューを表示し（Ｓ３１４）、許可されないアドレスである場合には、メニューを表示しない（Ｓ３１５）のである。
【００４９】
このように、図４は、アクセス情報の特性毎に表示の可否を判断する実施形態であり、各メニュー項目に紐付けられた画面では、表示可否判断要求があると、アクセス情報の特性に応じた表示可否の判断処理を行い、その結果を返す。
【００５０】
そして、メニュー（１）のＷｅｂＵＩコンテンツ２６１では、ユーザの認証情報を基に、管理者であればメニュー表示、非管理者であればメニュー非表示の判断を行っている。また、メニュー（２）のＷｅｂＵＩコンテンツ２６２では、機器のオプション構成を取得し、ファクシミリが装着されていればメニュー表示、未装着であればメニュー非表示の判断を行っている。さらに、メニュー（３）のＷｅｂＵＩコンテンツ２６３では、接続元ＩＰアドレスにより、許可されるＩＰアドレスであればメニュー表示、許可されないＩＰアドレスであればメニュー非表示の判断を行っている。
【００５１】
このように、表示の可否は、メニュー項目に紐付けられた画面の特性、すなわち、コンテンツのメニュー項目に応じて、任意に判断されているのである。
【００５２】
次に、図１から図４までにおいて説明した本発明の実施形態における表示制御装置を搭載した情報処置装置の組込みＷｅｂＵＩ画面について説明する。図５は、本発明の実施形態における表示制御装置を備えた情報処理端末の組込みＷｅｂＵＩ画面の例について説明する図である。
【００５３】
図５に示す組込みＷｅｂＵＩ画面（Ｗｅｂ  Ｉｍａｇｅ  Ｍｏｎｉｔｏｒ）において、「カスタマイズ」メニューの表示条件は、当該情報処理装置１のハードディスクの装着状態によって決定されている。表示条件は、該当するコンテンツのみによって認識されている。
【００５４】
「設定／管理」メニューは、ユーザのアクセス権限により表示の可否が決定される。表示条件は、該当するコンテンツのみによって認識されている。さらに、新たなコンテンツやメニューが使用条件により増加したとしても、ＷｅｂＵＩコンテンツ自体に表示可否判断を委ねているので、如何なる表示条件が加わったとしても対応することが可能である。
【００５５】
以上説明したように、従来の仕組みでは、多くの場合、ユーザの権限、接続されたオプションによる表示制御等といったように表示制御方法が固定化されており、これ以外の表示制御が必要となった場合、メニュー上に表示はされるが、メニューをクリックした時点でアクセス不可である旨をユーザに通知することとしていた。
【００５６】
これに対して、本発明の実施形態における表示制御装置は、メニューの表示制御をメニュー項目に紐付けられたＷｅｂＵＩコンテンツ（表示制御プログラムのユーザインタフェースに関するコンテンツ）に委譲することにより、表示制御方法を固定化せず、如何なる表示制御が必要となった場合であっても対応することができる。
【００５７】
これにより、ユーザ側からすると、アクセス可能なメニュー項目のみが必ず表示されることになるため、ユーザに対して不要な情報を与えることなく、効率良く操作を行うことが可能な表示制御装置及びこれを用いた情報処理装置を提供することができる。
【００５８】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範囲な趣旨及び範囲から逸脱することなく、これら具体例に様々な修正及び変更が可能である。
【符号の説明】
【００５９】
１    情報処理装置
１０    Ａｃｔｉｏｎ（ＷｅｂＵＩコンテンツ）
１１    Ａｕｔｈ  Ｈｔｔｐ  Ｃｏｎｔｅｘｔ
１２    ＵＲＬ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ
１３    Ｕｓｅｒ  Ｉｎｆｏ
１４    Ａｃｔｉｏｎ  Ｂａｓｅ
１５    Ｓｔａｔｉｃ  Ｃｏｎｔｅｎｔｓ
１６    Ｍｅｎｕ  Ｉｔｅｍ
１７    Ａｃｔｉｏｎ  Ｓｅｒｖｌｅｔ
１８    Ｅｓｄｋ  Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ
１９    Ｒｅｑｕｅｓｔ  Ｐｒｏｃｅｓｓｏｒ
１００    表示制御装置
１０１    ドライブ装置
１０２    記録媒体
１０３    補助記憶装置
１０４    メモリ装置
１０５    演算処理装置
１０７    入力装置
２０    Ｓｅｓｓｉｏｎ
２１    オペレータ
２２    システム
２３    ＵＩロジックコントローラ
２４    認証
２５    ＵＲＬアクセス制御
２６    ＷｅｂＵＩコンテンツ
２６１    メニュー（１）ＷｅｂＵＩコンテンツ
２６２    メニュー（２）ＷｅｂＵＩコンテンツ
２６３    メニュー（３）ＷｅｂＵＩコンテンツ
２７    認証情報
２８    静的コンテンツストア
２９    メニューＷｅｂＵＩコンテンツ
３０    機器管理
Ｂ    バス
【先行技術文献】
【特許文献】
【００６０】
【特許文献１】特開２００１−３５２５２７号公報
【図１】
2013225199.tif 000003
【図２】
2013225199.tif 000004
【図３】
2013225199.tif 000005
【図４】
2013225199.tif 000006
【図５】
2013225199.tif 000007