(57)【要約】【課題】  所定の事象の発生を明示することができるＷｅｂページを生成することができるＷｅｂページ生成装置、Ｗｅｂページ生成方法、Ｗｅｂページ生成プログラム及び記録媒体の提供を目的とする。【解決手段】    各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置であって、  前記表示データの表示内容を新たに通知する必要が生じたとき、該新たに通知する必要が生じた表示データに対応する表示領域を、該表示領域以外の表示領域よりも上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手段を有することにより上記課題を解決する。【選択図】  図４
2005189948.tif 000002
【特許請求の範囲】
【請求項１】
各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置であって、
前記表示データの表示内容を新たに通知する必要が生じたとき、該新たに通知する必要が生じた表示データに対応する表示領域を、該表示領域以外の表示領域よりも上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手段を有することを特徴とするＷｅｂページ生成装置。
【請求項２】
前記Ｗｅｂページにおける前記複数の表示領域の配置順序を規定するＷｅｂページ生成情報を有するＷｅｂページ生成情報格納手段と、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手段と、
前記通知要否判断手段によって前記表示データの表示内容を新たに通知する必要があると判断された場合に、前記表示データに対応する表示領域の前記Ｗｅｂページ生成情報における前記配置順序を該表示領域以外の表示領域よりも先にするＷｅｂページ生成情報変更手段とを有し、
前記Ｗｅｂページ生成手段は、前記Ｗｅｂページ生成情報変更手段によって変更された前記Ｗｅｂページ生成情報に基づいて前記Ｗｅｂページを生成することを特徴とする請求項１記載のＷｅｂページ生成装置。
【請求項３】
前記Ｗｅｂページ生成手段は更に、前記表示データの表示内容を新たに通知する必要が生じたとき、該新たに通知する必要が生じた表示データに関する通知情報を表示させる新たな表示領域を該新たな表示領域以外の表示領域の上方に配置して前記Ｗｅｂページを生成することを特徴とする請求項１記載のＷｅｂページ生成装置。
【請求項４】
前記Ｗｅｂページにおける前記複数の表示領域の配置順序を規定するＷｅｂページ生成情報を有するＷｅｂページ生成情報格納手段と、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手段と、
前記通知要否判断手段によって前記表示データの表示内容を新たに通知する必要があると判断された場合に、前記Ｗｅｂページ生成情報に前記新たな表示領域に対応する定義を追加すると共に、該定義と前記表示データに対応する表示領域に対する定義とに共通の識別名を付加するＷｅｂページ生成情報変更手段とを有し、
前記Ｗｅｂページ生成手段は、前記共通の識別名を前記表示データに対応する表示領域を識別するための情報として該表示領域に対するリンクを前記通知情報に組み込むことを特徴とする請求項３記載のＷｅｂページ生成装置。
【請求項５】
前記Ｗｅｂページ生成情報においては、前記複数の表示領域ごとに表示内容の通知の要否の判断対象とするか否かの指定が可能であり、
前記Ｗｅｂページ生成手段は、前記Ｗｅｂページ生成情報に基づいて前記通知の要否の判断対象とされている表示領域を特定し、特定された前記表示領域に対する表示データの表示内容の通知の要否を前記通知要否判断手段に問い合わせることを特徴とする請求項２乃至４いずれか一項記載のＷｅｂページ生成装置。
【請求項６】
各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置におけるＷｅｂページ生成方法であって、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手順と、
前記通知要否判断手順においてその表示内容を新たに通知する必要があると判断された前記表示データに対応する表示領域を該表示領域以外の表示領域よりも上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手順とを有することを特徴とするＷｅｂページ生成方法。
【請求項７】
各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置におけるＷｅｂページ生成方法であって、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手順と、
前記通知要否判断手順においてその表示内容を新たに通知する必要があると判断された前記表示データに関する通知情報を表示させる新たな表示領域を該新たな表示領域以外の表示領域の上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手順とを有することを特徴とするＷｅｂページ生成方法。
【請求項８】
各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置に、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手順と、
前記通知要否判断手順においてその表示内容を新たに通知する必要があると判断された前記表示データに対応する表示領域を該表示領域以外の表示領域よりも上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手順とを実行させるためのＷｅｂページ生成プログラム。
【請求項９】
請求項８記載のＷｅｂページ生成プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１０】
各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置に、
前記表示データの表示内容を新たに通知する必要があるかを判断する通知要否判断手順と、
前記通知要否判断手順においてその表示内容を新たに通知する必要があると判断された前記表示データに関する通知情報を表示させる新たな表示領域を該新たな表示領域以外の表示領域の上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手順とを実行させるためのＷｅｂページ生成プログラム。
【請求項１１】
請求項１０記載のＷｅｂページ生成プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂページ生成装置、Ｗｅｂページ生成方法、Ｗｅｂページ生成プログラム及び記録媒体に関し、特に各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置、Ｗｅｂページ生成方法、Ｗｅｂページ生成プログラム及び記録媒体に関する。
【背景技術】
【０００２】
近年におけるＷｅｂ技術の発達により、インターネットのユーザは汎用的なブラウザによって世界中の様々なサイトで提供されている情報を手軽に閲覧することができる。しかし、入手可能な情報が膨大となった昨今において、目的とする情報を探し出すのは極めて困難な作業である。そのためインターネットの入り口としてのサイト、即ちポータルサイトが普及し、現在においてはインターネットのユーザにとって欠かせないものとなっている。
【０００３】
一方、企業内においてもイントラネットにおける情報の共有化の手段としてＥＩＰ（Enterprise Information Portal）が導入され、必要とする情報を効率よく入手できるようになっている。
【０００４】
インターネットにおけるポータルサイトにしろ、ＥＩＰによるポータルサイトにしろ、そのサイトが提供するＷｅｂページ（ポータルページ）は、複数の領域に分割され、それぞれの分割領域には利用度の高い情報が表示されているのが一般である。従って、ユーザは、一つの画面において有用な情報を一度に閲覧することが可能であり、そのような利便性もポータルサイトの人気の要因になっていると考えられる。
【特許文献１】特開２００３−１０８８６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、一つの画面に掲載される情報が多くなると、情報量の増加に合わせて各分割領域の表示情報の視認性は相対的に悪化するという問題がある。その結果、一の分割領域において何らかの事象の発生をユーザに通知しているにもかかわらず、ユーザが、自らが意識して当該領域を確認しないとその事象の発生に気づかないということがある。
【０００６】
例えば、受信メールの一覧を表示する領域があったとする。新規メールが受信された場合、同じページ上に他の情報が多数表示されていると、当該領域を意識して確認しないと、ユーザは新規メールの受信に気づかないこともあるだろう。更に、当該領域がページの下方に位置していてＷｅｂブラウザの表示領域からはずれている場合、ユーザは、わざわざページをスクロールさせて当該領域を確認しなければならない。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、所定の事象の発生を明示することができるＷｅｂページを生成することができるＷｅｂページ生成装置、Ｗｅｂページ生成方法、Ｗｅｂページ生成プログラム及び記録媒体の提供を目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、本発明は、請求項１に記載されるように、各々が表示データを有する複数の表示領域を統合したＷｅｂページを生成するＷｅｂページ生成装置であって、前記表示データの表示内容を新たに通知する必要が生じたとき、該新たに通知する必要が生じた表示データに対応する表示領域を、該表示領域以外の表示領域よりも上方に配置して前記Ｗｅｂページを生成するＷｅｂページ生成手段を有することを特徴とする。
【０００９】
このようなＷｅｂページ生成装置では、その表示内容を新たに通知する必要のある表示データに対応した表示領域を他の表示領域よりも上方に表示させるＷｅｂページを生成することができるため、ユーザの所定の事象が発生したことを明示することができる。
【００１０】
また、上記課題を解決するため、本発明は、上記Ｗｅｂページ生成装置におけるＷｅｂページ生成方法、前記Ｗｅｂページ生成方法を前記Ｗｅｂページ生成装置に実行させるためのＷｅｂページ生成プログラム、又は前記Ｗｅｂページ生成プログラムを記録した記録媒体としてもよい。
【発明の効果】
【００１１】
本発明によれば、所定の事象の発生を明示することができるＷｅｂページを生成することができるＷｅｂページ生成装置、Ｗｅｂページ生成方法、Ｗｅｂページ生成プログラム及び記録媒体を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、図面に基づいて本発明の実施の形態を説明する。図１は第一の実施の形態におけるＷｅｂシステムの構成例を示す図である。図１のＷｅｂシステム１は、Ｗｅｂサーバ１０と、Ｗｅｂクライアント２０と、プリンタサーバ３０ａと、文書管理サーバ３０ｂと、メールサーバ３０ｃとがＬＡＮ（Local Area Network）又はインターネット等のネットワーク４０を介して接続されている。
【００１３】
Ｗｅｂクライアント２０は、Ｗｅｂブラウザがインストールされている端末であり、例えばＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistants）及び携帯電話等が該当する。
【００１４】
プリンタサーバ３０ａは、接続されるプリンタ５０に関する印刷サービスをＷｅｂサービスとしてネットワーク４０上に公開している。即ち、プリンタサーバ３０ａの機能はＳＯＡＰのＲＰＣにより呼び出すことができる。例えばプリンタサーバ３０ａは、指定された文書データ等を印刷する「印刷要求メソッド」や、プリンタ５０のステータス情報を提供するための「ステータス情報取得メソッド」等を有しており、ネットワーク４０上に公開している。
【００１５】
文書管理サーバ３０ｂは、文書ＤＢ（Data Base）６０に格納されている文書データに関する文書管理サービスをＷｅｂサービスとしてネットワーク４０上に公開している。即ち、文書管理サーバ３０ｂの機能はＳＯＡＰのＲＰＣにより呼び出すことができる。例えば文書管理サーバ３０ｂは、文書ＤＢ６０に格納されている文書データの一覧情報を取得するための「文書一覧取得メソッド」を有しており、ネットワーク４０上に公開している。
【００１６】
メールサーバ３０ｃは、メールサービスをＷｅｂサービスとしてネットワーク４０上に公開している。ＳＯＡＰのＲＰＣによりメールサーバ３０ｃの機能を呼び出すことができる点は、上述したプリンタサーバ３０ａ等と同様である。メールサーバ３０ｃは、例えば受信メールの一覧を取得するための「メール一覧取得メソッド」等を公開している。なお以下において、プリンタサーバ３０ａ、文書管理サーバ３０ｂ及びメールサーバ３０ｃ等のようにＳＯＡＰのＲＰＣによりその機能を呼び出すことができるサーバを、「ＳＯＡＰサーバ」と記述する。
【００１７】
Ｗｅｂサーバ１０は、Ｗｅｂクライアント２０からのＷｅｂページの取得要求に基づいて、プリンタサーバ３０ａ等や図示しないその他のＳＯＡＰサーバの機能をＳＯＡＰのＲＰＣによって呼び出すことにより、Ｗｅｂページの生成に必要な情報を収集する。更にＷｅｂサーバ１０は、収集した情報に基づいてＷｅｂページを生成し、当該ＷｅｂページをＷｅｂクライアント２０に送信する。従って、Ｗｅｂサーバ１０は、なんらかのコンテンツを予め有している必要はなく、ネットワーク４０を介して収集した情報に基づいてＷｅｂページを生成することが主な役割である。但し、Ｗｅｂサーバ１０にもなんらかのサービスを実行する機能を実装してもよい。
【００１８】
次に、Ｗｅｂサーバ１０の詳細について説明する。図２は、本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。Ｗｅｂサーバ１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、補助記憶装置１４、ネットワークインタフェース（Ｉ／Ｆ）１５、ドライブ装置１６等から構成されている。
【００１９】
ＣＰＵ１１は、Ｗｅｂサーバ１０全体を制御する制御部であり、ＲＯＭ１２や補助記憶装置１４に格納された各種制御プログラムやアプリケーションプログラムを実行して装置の制御、通信の制御、データの取得及び編集等の動作を行う。
【００２０】
ＲＯＭ１２は、主に装置の制御プログラムを記憶する記憶手段であり、ＲＡＭ１３はＣＰＵ１１のワークメモリや一時的なデータの記憶に用いる記憶手段である。
【００２１】
補助記憶装置１４は、各種アプリケーションプログラムやデータを記憶する記憶手段であり、後述するテーブル等も必要に応じてここに記憶するようにすることもできる。
【００２２】
ネットワークＩ／Ｆ１５は、Ｗｅｂサーバ１０をネットワーク４０に接続するためのインタフェースである。
【００２３】
ドライブ装置１６は、本発明の機能を実行する後述するプログラムが記録されたＣＤ−ＲＯＭ等の記録媒体１７を読み取るための装置である。
【００２４】
なお、図２には操作部や表示部を示していないが、キーボードやマウス等による操作部や、液晶やブラウン管（ＣＲＴ）による表示部を設け、ユーザからの入力の受付や動作結果の表示を行うことができるようにしてもよい。
【００２５】
次に、Ｗｅｂシステム１の機能構成について説明する。図３は、本発明の実施の形態におけるＷｅｂシステムの機能構成例の概略図である。
【００２６】
図３に示されるように、Ｗｅｂサーバ１０は、Ｗｅｂサーバプログラム１０１、Ｗｅｂアプリケーション１１０、及びサービスプロキシ１２０等より構成されている。
【００２７】
Ｗｅｂサーバプログラム１０１は、一般にＨＴＴＰｄ（HTTP daemon）と呼ばれるプログラムに相当するものであり、Ｗｅｂサーバ１０をＷｅｂサーバとして機能させるためのものである。すなわち、Ｗｅｂサーバプログラム１０１は、Ｗｅｂクライアント２０のＷｅｂブラウザ２１からのＨＴＴＰリクエストを受信し、Ｗｅｂアプリケーション１１０を呼び出す。また、Ｗｅｂサーバプログラム１０１は、呼び出したＷｅｂアプリケーション１１０によって生成されるＷｅｂページをＷｅｂブラウザ２１に対してＨＴＴＰレスポンスとして送信する。
【００２８】
Ｗｅｂアプリケーション１１０は、各種ＳＯＡＰサーバ３０より収集した情報や、Ｗｅｂサーバ１０にローカルに保存されている情報等に基づいて、それらの情報を表示させるＷｅｂページを生成する、いわゆるＷｅｂアプリケーションである。
【００２９】
サービスプロキシ３１は、ＳＯＡＰサーバ３０における機能（サービス３１）に対するメソッドインタフェースを透過的に提供するモジュールである。すなわち、Ｗｅｂアプリケーション１１０は、サービスプロキシ３１のメソッドを呼び出すことにより、ネットワーク境界を意識せずにＳＯＡＰサーバ３０の機能を呼び出すことができる。
【００３０】
Ｗｅｂアプリケーション１１０について更に詳しく説明する。図４は、Ｗｅｂアプリケーションの機能構成を説明するためのクラス図である。
【００３１】
図４に示されるように、Ｗｅｂアプリケーション１１０は、サーブレット（Ｓｅｒｖｌｅｔ）１１１、ページ生成クラス１１２、プロファイル操作クラス１１３、プロファイルＸＭＬ１１４、ユニットデータ取得クラスＡ１１５ａ、ユニットデータ取得クラスＢ１１５ｂ、及びユニットデータ取得クラスＣ１１５ｃ等から構成されている。
【００３２】
サーブレット１１１は、Ｗｅｂサーバプログラム１１０が受信したＷｅｂブラウザ２１からのＨＴＴＰリクエストに指定されているＵＲＬに基づいて、Ｗｅｂブラウザ２１より要求されているＷｅｂページを判断し、当該Ｗｅｂページに対応したページ生成クラス１１２のインスタンスにＷｅｂページを生成させるといった機能が実装されたモジュールである。
【００３３】
ページ生成クラス１１２は、Ｗｅｂページの生成機能を実現するためのクラスである。ページ生成クラス１１２は、プロファイル操作クラス１１３を介してプロファイルＸＭＬ１１４に定義されている情報を取得し、当該情報に基づいてＷｅｂページを生成する。なお、ページ生成クラス１１２は、Ｗｅｂページの種類に応じて定義されている。
【００３４】
本実施の形態においては、ページ生成クラス１１２としてポータルページを生成するクラスが存在する。ここで、ポータルページとは、一つの表示領域に様々な情報を統合して表示させるＷｅｂページをいい、インターネット又はイントラネット等の入り口として利用されるものをいう。
【００３５】
図５は、本発明の実施の形態におけるポータルページの例を示す図である。図５に示されるように、ポータルページ２１０は、サービス一覧ユニット２１１、プリンタ情報ユニット２１２、カレンダーユニット２１３、文書一覧ユニット２１４及び受信トレイユニット２１５等から構成される。なお、本実施の形態においては、ポータルページ２１０上において分割されたそれぞれの領域を「ユニット」と呼ぶ。
【００３６】
サービス一覧ユニット２１１は、各種サービスの一覧（ハイパーリンク）が表示されるユニットである。サービス一覧ユニット２１１におけるそれぞれのリンクがクリックされると、対応するサービスを提供するためのＷｅｂページが新たに表示される。
【００３７】
プリンタ情報ユニット２１２は、プリンタサーバ３０ａより取得されたプリンタ５０のステータス情報が表示されるユニットである。
【００３８】
カレンダーユニット２１３は、ユーザのスケジュール情報が表示されるユニットである。
【００３９】
文書一覧ユニット２１４は、文書管理サーバ３０ｂより取得された文書ＤＢ６０の所定のフォルダ内の文書データの一覧情報が表示されるユニットである。
【００４０】
受信トレイユニット２１５は、メールサーバ３０ｃに管理されている、カレントユーザの受信メールの一覧が表示される領域である。
【００４１】
図４に戻る。プロファイル操作クラス１１３は、プロファイルＸＭＬ１１４へのアクセス手段を提供するクラスである。
【００４２】
プロファイルＸＭＬ１１４は、ポータルページ２１０上における操作環境がユーザごとに定義されているＸＭＬ形式のファイルである。具体的には、ポータルページ２１０をどのように分割するかというレイアウトに関する情報と、それぞれのユニットにどのような情報を表示させるかという表示情報の割り当てに関する情報（これらを総称して以下、「ページ構成情報」という。）とが定義されている。なお、表示用プロファイル１１４ａは、ポータルページ２１０の生成時にプロファイルＸＭＬ１１４のコピーとして一時的に生成されるファイルであるが、その詳細については後述する。
【００４３】
ユニットデータ取得クラスＡ１１５ａ、ユニットデータ取得クラスＢ１１５ｂ、及びユニットデータ取得クラスＣ１１５ｃ等（以下、総称する場合「ユニットデータ取得クラス１１５」という。）は、ポータルページ２１０の各ユニットに表示させる情報（以下、「ユニットデータ」という。）の種別ごとに定義されており、当該ユニットデータを取得するための機能が実装されているクラスである。例えば、ユニットデータ取得クラスＡ１１５ａは、プリンタサーバ３０ａよりプリンタ５０のステータス情報を取得するためのクラス、ユニットデータ取得クラスＢ１１５ｂは、文書管理サーバ３０ｂより文書データの一覧情報を取得するためのクラスといった具合である。したがって、図中に表示されている三つのユニットデータ取得クラス１１５は、単なる例示であり、更に多くのユニットデータ取得クラス１１５が定義され得る。
【００４４】
サービスプロキシ１２０ａ及びサービスプロキシ１２１ｂは、図３におけるサービスプロキシ１２０に相当する（したがって、サービスプロキシ１２０ａ及びサービスプロキシ１２１ｂ等を総称する場合「サービスプロキシ１２０」という。）。すなわち、サービスプロキシ１２０は、各ＳＯＡＰサーバ３０のサービス３１ごとに存在し、そのうちの一つの例示としてサービスプロキシ１２０ａ、他の例示としてサービスプロキシ１２１ｂが表示されているというわけである。したがって、各ユニットデータ取得クラス１１５は、それぞれが取得すべき表示情報に対応したサービスプロキシ１２０のメソッドを呼び出すことにより、それぞれのサービス３１よりユニットデータを取得する。
【００４５】
サービス３１ａ及びサービス３１ｂは、各ＳＯＡＰサーバ３０のサービス３１のそれぞれを区別して例示したものである。例えば、サービス３１ａは、プリンタサーバ３０ａにおけるサービス３１（プリンタサービス）であり、サービス３１ｂは、文書管理サーバ３０ｂにおけるサービス３１（文書管理サービス）であるといった具合である。
【００４６】
ローカルモジュール１２１ｃは、例えば、カレンダーユニット２１３等、そのユニットデータがローカルな環境から取得されるユニットに対するユニットデータ取得クラスＣ１１５ｃが、そのユニットデータを取得するために利用するライブラリの例示である。
【００４７】
以下、図３及び図４のＷｅｂサーバ１０がポータルページ２１０を生成する際の処理手順について説明する。図６は、ポータルページの生成処理を説明するためのシーケンス図である。Ｗｅｂクライアント２０のＷｅｂブラウザ２１からのポータルページ２１０の送信要求（ＨＴＴＰリクエスト）が、Ｗｅｂサーバプログラム１０１によって受信され、Ｗｅｂサーバプログラム１０１によってサーブレット１１１が呼び出されると図６の処理が開始される。
【００４８】
ステップＳ１０１において、サーブレット１１１は、ＨＴＴＰリクエストにおいて指定されているＵＲＬよりポータルページ２１０が要求されていることを判断し、ポータルページ２１０に対応するページ生成クラス１１２（のインスタンス）にポータルページ２１０の生成を要求する。なお、以下において、各クラスのインスタンスを指す場合、単に当該クラスのクラス名のみをもって記述する。
【００４９】
ステップＳ１０１に続いてステップＳ１０２に進み、ページ生成クラス１１２は、プロファイル操作クラス１１３に対してページ構成情報の提供を要求すると、プロファイル操作クラス１１３は、プロファイルＸＭＬ１１４よりページ構成情報を読み込み、その内容をページ生成クラス１１２に対して出力する（Ｓ１０３）。
【００５０】
図７は、プロファイルＸＭＬの定義例を示す図である。図７において、＜ＭｙＬｉｎｋ＞タグで囲まれた定義が一つのポータルページ２１０に対するページ構成情報である。
【００５１】
＜Ｌｅｆｔ＞タグで囲まれたＬｅｆｔ要素１１４１と、＜Ｒｉｇｈｔ＞タグで囲まれたＲｉｇｈｔ要素１１４２の存在によって、ポータルページ２１０が水平方向に２分割される旨が規定されている。なお、本実施の形態においては、ポータルページ２１０は水平方向に２分割されているが、分割数については任意に定義できる。例えば３分割にする場合は、Ｌｅｆｔ要素１１４１及びＲｉｇｈｔ要素１１４２と同じレベルにおいて新たな定義（例えば、Ｃｅｎｔｅｒ要素）を追加すればよい。
【００５２】
Ｌｅｆｔ要素１１４１とＲｉｇｈｔ要素１１４２には、それぞれ一つ以上のＵｎｉｔ要素が属している。Ｕｎｉｔ要素は、ポータルページ２１０上の各ユニットを規定するためのものである。したがって、Ｕｎｉｔ要素の数によって、ポータルページ２１０における左領域及び右領域のそれぞれのユニットの数が規定され、Ｕｎｉｔ要素の定義の順番で各ユニットの配置位置が規定される。
【００５３】
Ｌｅｆｔ要素１１４１には、Ｕｎｉｔ要素１１４１ａ及び１１４１ｂの二つのユニット要素が属している。したがって、左領域は、二つのユニットが配列されることになる。これは、それぞれサービス一覧ユニット２１１、プリンタ情報ユニット２１２に相当する。
【００５４】
Ｒｉｇｈｔ要素１１４２には、Ｕｎｉｔ要素１１４２ａ、１１４２ｂ及び１１４２ｃの三つのユニット要素が属している。したがって、右領域は、垂直方法に三つのユニットが配列されることになる。これは、それぞれカレンダーユニット２１３、文書一覧ユニット２１４、受信トレイユニット２１５に相当する。
【００５５】
各Ｕｎｉｔ要素は、ＩＤ属性及びＣｌａｓｓ属性を有している。ＩＤ属性は、各Ｕｎｉｔ要素を識別するための属性であり、その値は、各Ｕｎｉｔ要素に一意に割り当てられた情報（以下、「ユニットＩＤ」という。）が指定される。Ｃｌａｓｓ属性は、ユニットに関連付けるユニットデータ取得クラス１１５を特定するための属性である。すなわち、Ｃｌａｓｓ属性の値には、ユニットに関連付けるユニットデータ取得クラス１１５を識別するための名前（例えば、クラスファイル名）が指定される。したがって、Ｃｌａｓｓ属性によって、ユニットに表示させるユニットデータが規定される。
【００５６】
Ｕｎｉｔ要素は、更に、Ｎｏｔｉｆｙ属性を付加することができる。Ｎｏｔｉｆｙ属性は、真偽値をとる属性であり、その値が「ｔｒｕｅ」である場合は、当該ユニットは、そのユニットデータが所定の条件を満たした場合にその表示内容をユーザに通知すべきものとして指定されたユニット（以下、「通知ユニット」という。）である旨を示す。図７より、本実施の形態においては、Ｕｎｉｔ要素１１４１ｂとＵｎｉｔ要素１１４２ｃに対応するユニット、すなわち、プリンタ情報ユニット２１２と受信トレイユニット２１５とが通知ユニットであることが分かる。ユニットデータが所定の条件を満たした旨をユーザに対して通知することを以下、単に「通知」という。
【００５７】
なお、ステップＳ１０３において、プロファイル操作クラス１１３は、プロファイルＸＭＬ１１４の内容をそのままページ生成クラス１１２に対して出力してもよいが、本実施の形態においては、各Ｕｎｉｔ要素のＩＤ属性の値とＣｌａｓｓ属性の値、すなわち、各ユニットＩＤと各ユニットデータ取得クラス１１５の識別名（以下、「ユニット名」という。）との一覧が出力されたものとする。
【００５８】
ステップＳ１０３に続いてステップＳ１０４からステップＳ１１６までの処理は、ユニット（Ｕｎｉｔ要素）ごとに実行される。以下、処理対象となっているユニットを「カレントユニット」という。
【００５９】
ステップＳ１０４において、ページ生成クラス１１２は、カレントユニットが通知ユニットユニットであるか否かをそのユニットＩＤに基づいてプロファイル操作クラス１１３に問い合わせる。
【００６０】
ステップＳ１０４に続いてステップＳ１０５に進み、プロファイル操作１１３は、ページ構成情報において、カレントユニットに対するＮｏｔｉｆｙ属性の値がｔｒｕｅであるか否かを確認し、その結果をページ生成クラス１１２に対して出力する。
【００６１】
ステップＳ１０５に続いてステップＳ１０６に進み、ページ生成クラス１１２は、カレントユニットのユニット名に基づいてカレントユニットに対応するユニットデータ取得クラス１１５を特定し、当該ユニットデータ取得クラス１１５に対してユニットデータの取得を要求する。
【００６２】
ステップＳ１０６に続いてステップＳ１０７に進み、ユニットデータ取得クラス１１５は、サービスプロキシ１２１のメソッドを呼び出すことにより、ＳＯＡＰのＲＰＣによって対応するサービス３１に対してユニットデータとして利用される情報の送信を要求する（Ｓ１０８）。
【００６３】
ステップＳ１０８に続いてステップＳ１０９に進み、サービス３１が、ユニットデータをサービスプロキシ１２１に対して送信すると、サービスプロキシ１２１は、ユニットデータ取得クラス１１５に対してユニットデータを出力する（Ｓ１１０）。
【００６４】
例えば、カレントユニットが受信トレイユニット２１５だった場合は、ステップＳ１０７〜Ｓ１１０の処理によって、メールサーバ３０ｃにおける受信メールの一覧情報がユニットデータ取得クラス１１５によって取得される。なお、ユニットデータ取得クラス１１５は、取得したユニットデータを保持しておく。
【００６５】
ステップＳ１１０に続いてステップＳ１１１に進み、ユニットデータ取得クラス１１５は、ユニットデータについて通知の要否を判断し、その判断結果を保持しておく。通知が必要となる基準は、基本的にそれぞれのユニットデータに応じて異なる。例えば、受信メールの一覧情報である場合は、新規メールが受信されている場合に通知されるようにすると便宜である。また、プリンタ５０のステータス情報の場合は、プリンタ５０に異常が発生した場合に通知されるようにすると便宜である。
【００６６】
このような判断は、各ユニットデータ取得クラス１１５内におけるロジックとして実装してもよいし、判断基準を所定のファイルにおいて定義するようにしもよい。後者の場合、ユニットデータ取得クラス１１５は、当該ファイルの定義内容に基づいてユニットデータについての通知の要否を判断することとなる。
【００６７】
ステップＳ１１１に続いてステップＳ１１２に進み、ユニットデータ取得クラス１１５は、ユニットデータの取得が完了した旨をページ生成クラス１１２に対して通知する。
【００６８】
ステップＳ１１２に続いてステップＳ１１３に進み、ステップＳ１０５においてカレントユニットが通知ユニットであることが確認されている場合は、ページ生成クラス１１２は、ユニットデータ取得クラス１１５に対して、カレントユニットについての通知の要否を問い合わせる。
【００６９】
ステップＳ１１３に続いてステップＳ１１４に進み、ユニットデータ取得クラス１１５は、ステップＳ１１１において保持していた情報に基づいて、通知の要否を示す情報（以下、「通知要否情報」という。）をページ生成クラス１１２に対して出力する。
【００７０】
ステップＳ１１４に続いてステップＳ１１５に進み、通知要否情報において通知が必要である旨が示されている場合は、ページ生成クラス１１２は、プロファイル操作クラス１１３に対して、カレントユニットがユーザにとって認識し易いように表示されるようにポータルページ２１０の構成を変更するよう要求する。
【００７１】
ステップＳ１１５に続いてステップＳ１１６に進み、プロファイル操作クラス１１３は、カレントユニットが他のユニットより上方に表示されるように、ページ構成情報を変更する。具体的には、プロファイル操作クラス１１３は、プロファイルＸＭＬ１１４をコピーして表示用プロファイル１１４ａを生成し、表示用プロファイル１１４ａにおいてカレントユニットに対応するＵｎｉｔ要素の位置をＬｅｆｔ要素１１４１又はＲｉｇｈｔ要素１１４２の一番上に変更する。
【００７２】
なお、プロファイル操作クラス１１３が、プロファイルＸＭＬ１１４のコピーである表示用プロファイル１１４ａを生成して表示用プロファイル１１４ａを変更対象とするのは、通知のためのページ構成の変更は一時的なものであるにもかかわらず、プロファイルＸＭＬ１１４を直接変更してしまうと、当初のページ構成情報を維持できなくなってしまうからである。
【００７３】
図８は、変更された表示用プロファイルの定義例を示す図である。図８においては、当初（図７）Ｒｉｇｈｔ要素１１４２において一番下に定義されていたＵｎｉｔ要素１１４２ｃが、一番上に移動された例が示されている。
【００７４】
ステップＳ１１７に続いてステップＳ１１８に進み、上述したステップＳ１０４からステップＳ１１７までの処理が、他のユニットについても実行される。したがって各ユニットに表示させるユニットデータがページ生成手段１１２の元に収集される。
【００７５】
全てのユニットに対する処理が完了するとステップＳ１１９に進み、ページ生成クラス１１２は、プロファイル操作クラス１１３に対して表示用プロファイル１１４ａにおけるページ構成情報の提供を要求する。
【００７６】
ステップＳ１１９に続いてステップＳ１２０に進み、プロファイル操作クラス１１３は、表示用プロファイル１１４ａよりページ構成情報を読み込み、その内容をページ生成クラス１１２に対して出力する。
【００７７】
ステップＳ１２０に続いてステップＳ１２１に進み、ページ生成クラス１１２が、ユニットデータ取得クラス１１５に対してユニットデータの提供を要求すると、ユニットデータ取得クラス１１５は、ステップＳ１１０で保持しておいた全てのユニットに対するユニットデータをページ生成クラス１１２に対して出力する（Ｓ１２２）。
【００７８】
ステップＳ１２２に続いてステップＳ１２３に進み、ページ生成クラス１１２は、表示用プロファイル１１４ａのページ構成情報に基づいて、ポータルページ２１０を生成する。したがって、各ユニットデータは、表示用プロファイル１１４ａに定義されている順番でポータルページ２１０上に配置される。
【００７９】
ステップＳ１２３に続いてステップＳ１２４に進み、ページ生成クラス１１２は、生成したポータルページ２１０をサーブレット１１１に対して出力する。その後、ポータルページ２１０は、Ｗｅｂサーバプログラム１０１によってＷｅｂブラウザ２１に対して送信され、Ｗｅｂブラウザ２１によって表示される。
【００８０】
図９は、変更された表示用プロファイルに基づいて生成されたポータルページの例を示す図である。図９のポータルページ２１０は、図８の表示用プロファイル１１５に基づいて生成された例を示している。したがって、受信トレイユニット２１５がポータルページ２１０上の右側において一番上に表示されている。受信トレイユニット２１５が一番上に表示されることによりその視認性が高まり、ユーザは、容易に新規メールが受信されたことを認識することができる。
【００８１】
上述したように、本実施の形態におけるＷｅｂサーバ１０によれば、複数のユニットが存在するポータルページ２１０の中で、そのユニットデータが所定の条件を満たしたユニットが他のユニットより上方に表示されるようにポータルページ２１０を生成するため、当該ユニットの表示内容をユーザが視認しやすいように示すことができる。
【００８２】
また、プロファイルＸＭＬ１１４は、ユーザ毎に定義されており、各プロファイルＸＭＬ１１４におけるそれぞれのＵｎｉｔ要素のＮｏｔｉｆｙ属性によって通知の要否を指定することが可能なため、ユニットデータが所定の条件を満たした場合に当該ユニットの位置を変更するか否かは各ユーザの任意とすることができる。したがって、ユーザにとって真に重要な情報のみを通知の対象とすることができ、必要以上にユニットの位置関係が変更されてしまうのを防止することができる。
【００８３】
なお、通知の方法は、ユニットの表示位置の変更だけに限られない。例えば、ポータルページ２１０の所定の領域に通知を示すメッセージ（通知メッセージ）を表示させるようにしてもよい。以下、通知メッセージを表示させる領域を「ヘッドラインユニット」という。
【００８４】
図１０は、ヘッドラインユニットを設けたポータルページの例を示す図である。図１０に示されるようにポータルページ２２０の右側の一番上にはヘッドラインユニット２１６が配置されている。ヘッドラインユニット２１６には、「新規メールを受信しました。」等の通知メッセージが表示されているが、この通知メッセージには、対応するユニットへのハイパーリンクが張られている。したがって、ユーザが通知メッセージをクリックすると、対応するユニットの位置までページがスクロールされるというわけである。
【００８５】
ポータルページ２２０を生成するための処理手順は、図６において説明した処理と概ね同じであるが、ステップＳ１１６及びステップＳ１２３において実行される処理が異なる。
【００８６】
すなわち、ステップＳ１１６において、プロファイル操作クラス１１３は、プロファイルＸＭＬ１１４（図７）をコピーして表示用プロファイル１１４ａを生成し、表示用プロファイル１１４ａの定義を図１１に示されるようなものに変更する。
【００８７】
図１１は、ヘッドラインユニットを表示させるための表示用プロファイルの定義例である。まず、プロファイル操作クラス１１３は、ヘッドラインユニット２１６に対応する要素であるＨｅａｄＬｉｎｅ要素１１４３を追加し、そのＨｅａｄＬｉｎｅ要素１１４３に通知メッセージに組み込むハイパーリンクに対応する要素であるＬｉｎｋ要素１１４３ａを追加する。この際、プロファイル操作クラス１１３は、Ｌｉｎｋ要素１１４３ａにＴａｇ属性を付加し、その値としてリンク先を識別するための識別名（以下、「タグ名」という。）を指定する（図１１においては”Ｄｉｓｔ”）。
【００８８】
プロファイル操作クラス１１３は、更に、リンク先となるユニットのＵｎｉｔ要素（図１１においては、Ｕｎｉｔ要素１１４２ｃ）にＴａｇＮａｍｅ属性１１４２ｃ−１を付加し、その値としてＬｉｎｋ要素１１４３ａのＴａｇ属性の値に指定したタグ名（”Ｄｉｓｔ”）と同じ値を指定する。
【００８９】
なお、リンク先となるユニットを識別するためのタグ名は、例えば、予め各ユニットとタグ名との対応表を定義しておき、その対応表（以下、「ユニット・タグ名対応テーブル」という。）に基づいて特定するようにすればよい。
【００９０】
図１２は、ユニット・タグ名対応テーブルの構成例を示す図である。図１２に示されるように、ユニット・タグ名対応テーブルは、ユニットＩＤとタグ名との対応付けを管理しているテーブルである。ユニット・タグ名対応テーブルを参照することにより、プロファイル操作クラス１１３は、リンク先となるユニットのＵｎｉｔ要素のユニットＩＤ（例えば、「００５」）に基づいて、タグ名（例え場、「Ｄｉｓｔ」）を特定することができる。
【００９１】
その後、ステップＳ１２３において、ページ生成クラス１１２は、図１１の表示用プロファイル１１４ａに基づいてポータルページ２１０を生成する。この際、ページ生成クラス１１２は、ＨｅａｄＬｉｎｅ要素１１４３の存在によってヘッドラインユニット２１６を配置する旨を認識し、Ｌｉｎｋ要素１１４３のＴａｇ属性の値（タグ名）に基づいて通知メッセージとして表示する文字列、及び通知メッセージにハイパーリンクとして組み込むＵＲＬを特定する。
【００９２】
通知メッセージとしてヘッドラインユニット２１６に表示させる文字列は、例えば、予めタグ名ごとに対応表に定義しておき、その対応表（以下、「通知メッセージ定義テーブル」という。）に基づいて特定するようにすればよい。
【００９３】
図１３は、通知メッセージ定義テーブルの構成例を示す図である。図１３に示されるように、通知メッセージ定義テーブルは、タグ名とそれに対応する通知メッセージとを管理しているテーブルである。ページ生成クラス１１２は、通知メッセージ定義テーブルを参照することにより、Ｌｉｎｋ要素のＴａｇ属性の値（タグ名）に基づいて、通知メッセージを特定することができる。
【００９４】
また、通知メッセージにハイパーリンクとして組み込むＵＲＬは、ポータルページ２２０のＵＲＬにＴａｇ属性の値（タグ名）をフラグメント名として付加したものとすればよい。したがって、ポータルページ２２０のＵＲＬが「ＭｙＬｉｎｋ．ｈｔｍｌ」である場合は、通知メッセージに組み込むＵＲＬは、「ＭｙＬｉｎｋ．ｈｔｍｌ＃Ｄｉｓｔ」といったようになる。
【００９５】
また、ページ生成クラス１１２は、各ユニットのＨＴＭＬ定義を生成する際に、Ｕｎｉｔ要素にＴａｇＮａｍｅ属性が付加されているユニットについては、当該ＨＴＭＬ定義にアンカー要素（＜ａ＞タグにより囲まれた要素）を追加し、そのアンカー要素のｎａｍｅ属性の値にＴａｇＮａｍｅ属性１１４２ｃ−１の値を指定する。こうすることで、通知メッセージから通知の対象となるユニットへのハイパーリンクが張られたことになる。
【００９６】
このように生成されたポータルページ２２０は、Ｗｅｂクライアント２０のＷｅｂブラウザ２１において図１４に示されるように表示される。
【００９７】
図１４は、ポータルページ２２０のＷｅｂブラウザ上での表示例を示す図である。図１４においては、ポータルページ２２０のサイズが大きく、Ｗｅｂブラウザ２１の表示領域には収まらない様子を示している。しかし、このような場合でもユーザは、ヘッドラインユニット２１６を参照することで、確認すべきユニットを即座に認識することができる。
【００９８】
ここで、ユーザが、通知メッセージ２１６ａをクリックすると、ポータルページ２２０は、リンク先のユニット（ここでは、受信トレイユニット２１５）まで自動的にスクロールされる。
【００９９】
図１５は、リンク先のユニットまで自動的にスクロールされたポータルページの表示例を示す図である。図１５においては、リンク先である受信トレイユニット２１５までスクロールされ、受信トレイユニット２１５が参照可能になっている。
【０１００】
上述したように、ヘッドラインユニット２１６によって通知を行うことにより、各ユニットの相対的な位置関係を維持したまま、ユーザに対して所定の事象を明示することができる。これは、ユニットの位置関係が変更されてしまうと作業がしにくいといったユーザにとって非常に便宜である。
【０１０１】
ところで、近年においては、ある特定の機能に特化した組み込み機器においてもＷｅｂサーバとして機能するもの等、コンピュータと同等の情報処理を実行することができるものが提供されている。例えば、融合機、又は複合機と呼ばれる、プリンタ、コピー、又はファクシミリ等の複合サービスに固有の処理を行う複数のアプリケーションを有する画像処理装置もかかる機器に該当する。最近の画像処理装置には、Ｗｅｂサーバとしての機能を有し、更に、コピーした情報又はＦＡＸ受信した情報等を文書データとして蓄積する文書管理機能等を有しているものもある。
【０１０２】
したがって、このような画像処理装置を用いて、本実施の形態におけるＷｅｂシステム１を構成しても本発明の効果を同様に得ることができる。例えば、図１６は、Ｗｅｂサーバに画像処理装置を用いて構成したＷｅｂシステムの構成例を示す図である。図１６中、図１と同一部分には同一符号を付し、その説明は省略する。図１６と図１とを比較すると、図１６においては、Ｗｅｂサーバ１０の代わりに画像処理装置４１０がＷｅｂシステム１の構成要素となっている。画像処理装置４１０には、Ｗｅｂサーバ１０に実装されていた機能、すなわち、Ｗｅｂサーバプログラム１０１、Ｗｅｂアプリケーション１１０及びサービスプロキシ１２０等が組み込まれている。したがって、画像処理装置４１０は、Ｗｅｂサーバ１０として機能することができる。
【０１０３】
画像処理装置４１０について更に詳しく説明する。図１７は、本発明の実施の形態における画像処理装置の機能構成例を示す図である。図１７において、画像処理装置４１０は、プロッタエンジン１２０３及びスキャナエンジン１２０４等の個別の画像処理を行うためのハードウェア資源と、エンジン制御ボード１２０２と、ＯＳ１２０１と、システム管理サービス１１０６と、ネットワークサービス１１０７と、メモリ管理サービス１１０８と、オペパネ管理サービス１１０９と、エンジン管理サービス１２００と、コピーアプリ１１０１、ファックスアプリ１１０２、プリンタアプリ１１０３、及びＷｅｂアプリ１１０４等の各種アプリケーションとから構成される。
【０１０４】
エンジン制御ボード１２０２は、プロッタエンジン１２０３及びスキャナエンジン１２０４等の画像処理装置４１０の個別機能を制御し、エンジンＩ／Ｆ（インタフェース）を通して、エンジン制御ボード１２０２の機能をＯＳ１２０１等に提供する。
【０１０５】
ＯＳ１２０１は、ＵＮＩＸ（登録商標）等のオペレーティング・システムであり、コピーアプリ１１０１、ファックスアプリ１１０２等、アプリケーションとして実装されている各種ソフトウェアをプロセスとして並列実行する。
【０１０６】
システム管理サービス１１０６、ネットワークサービス１１０７、メモリ管理サービス１１０８、オペパネ管理サービス１１０９、及びエンジン管理サービス１２００は、ＡＰＩ（Application Programming Interface）を通して、コピーアプリ１１０１等の上位アプリケーションにそれぞれの機能を提供するものである。即ち、システム管理サービス１１０６は、システム管理に関する機能を提供し、ネットワークサービス１１０７は、ネットワーク通信に関する機能を提供する。例えば、ネットワークサービス１１０７には、Ｗｅｂサーバプログラム１０１（図３）に相当する機能が実装されている。また、メモリ管理サービス１１０８は、メモリ管理に関する機能を提供し、オペパネ管理サービス１１０９は、画像処理装置４１０に設置された操作パネル（オペパネ）に関する機能を提供する。更に、エンジン管理サービス１２００は、エンジン制御ボード１２０２を介してプロッタエンジン１２０３やスキャナエンジン１２０４を制御するための機能を提供する。
【０１０７】
コピーアプリ１１０１は、コピー用アプリケーションであり、ファックスアプリ１１０２は、ファクシミリ用アプリケーションである。プリンタアプリ１１０３は、ページ記述言語（ＰＤＬ）、ＰＣＬ及びポストスクリプト（ＰＳ）を有するプリンタ用アプリケーションである。Ｗｅｂアプリ１１０４は、本実施の形態におけるＷｅｂサーバ１０のＷｅｂアプリケーション１１０に相当する機能が実装されているアプリケーションである。したがって、Ｗｅｂアプリ１１０４を用いて図６において説明した処理を実行することにより、画像処理装置４１０は、Ｗｅｂサーバ１０と同様の機能を実現する。
【０１０８】
以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１０９】
【図１】本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。
【図２】本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるＷｅｂシステムの機能構成例の概略図である。
【図４】Ｗｅｂアプリケーションの機能構成を説明するためのクラス図である。
【図５】本発明の実施の形態におけるポータルページの例を示す図である。
【図６】ポータルページの生成処理を説明するためのシーケンス図である。
【図７】プロファイルＸＭＬの定義例を示す図である。
【図８】変更された表示用プロファイルの定義例を示す図である。
【図９】変更された表示用プロファイルに基づいて生成されたポータルページの例を示す図である。
【図１０】ヘッドラインユニットを設けたポータルページの例を示す図である。
【図１１】ヘッドラインユニットを表示させるための表示用プロファイルの定義例である。
【図１２】ユニット・タグ名対応テーブルの構成例を示す図である。
【図１３】通知メッセージ定義テーブルの構成例を示す図である。
【図１４】ポータルページ２２０のＷｅｂブラウザ上での表示例を示す図である。
【図１５】リンク先のユニットまで自動的にスクロールされたポータルページの表示例を示す図である。
【図１６】Ｗｅｂサーバに画像処理装置を用いて構成したＷｅｂシステムの構成例を示す図である。
【図１７】本発明の実施の形態における画像処理装置の機能構成例を示す図である。
【符号の説明】
【０１１０】
１            Ｗｅｂシステム
１０          Ｗｅｂサーバ
１１      ＣＰＵ
１２      ＲＯＭ
１３      ＲＡＭ
１４      補助記憶装置
１５      ネットワークＩ／Ｆ
１６      ドライブ装置
１７      記録媒体
２０          Ｗｅｂクライアント
２１          Ｗｅｂブラウザ
３０ａ        プリンタサーバ
３０ｂ        文書管理サーバ
３０ｃ        メールサーバ
３１、３１ａ、３１ｂ          サービス
４０          ネットワーク
５０          プリンタ
６０          文書ＤＢ
１０１        Ｗｅｂサーバプログラム
１１０        Ｗｅｂアプリケーション
１１１        サーブレット
１１２        ページ生成クラス
１１３        プロファイル操作クラス
１１４        プロファイルＸＭＬ
１１４ａ      表示用プロファイル
１１５ａ      ユニットデータ取得クラスＡ
１１５ｂ      ユニットデータ取得クラスＢ
１１５ｃ      ユニットデータ取得クラスＣ
１２０、１２０ａ、１２０ｂ        サービスプロキシ
１２１ｃ      ローカルモジュール
４１０        画像処理装置
１１０１      コピーアプリ
１１０２      ファックスアプリ
１１０３      プリンタアプリ
１１０４      Ｗｅｂアプリ
１１０６      システム管理サービス
１１０７      ネットワークサービス
１１０８      メモリ管理サービス
１１０９      オペパネ管理サービス
１２００      エンジン管理サービス
１２０１      ＯＳ
１２０２      エンジン制御ボード
１２０３      プロッタエンジン
１２０４      スキャナエンジン
【図１】
2005189948.tif 000003
【図２】
2005189948.tif 000004
【図３】
2005189948.tif 000005
【図４】
2005189948.tif 000006
【図５】
2005189948.tif 000007
【図６】
2005189948.tif 000008
【図７】
2005189948.tif 000009
【図８】
2005189948.tif 000010
【図９】
2005189948.tif 000011
【図１０】
2005189948.tif 000012
【図１１】
2005189948.tif 000013
【図１２】
2005189948.tif 000014
【図１３】
2005189948.tif 000015
【図１４】
2005189948.tif 000016
【図１５】
2005189948.tif 000017
【図１６】
2005189948.tif 000018
【図１７】
2005189948.tif 000019