以下、本発明の実施の形態を図面に基づいて詳細に説明する。
(第1の実施の形態)
図1は、本発明の第1の実施の形態に係る組み込み装置を適用した画像処理装置を含む画像処理システムの全体構成を示すブロック図である。
本実施の形態の画像処理システムは、アプリケーションサービスプロバイダ(ASP)サイト153、広域ネットワーク152およびユーザサイト151から構成されている。
広域ネットワーク152の一例としては、インターネットである。その他に、インターネット上の仮想プライベートネットワーク(VPN)や、専用のプライベートネットワークでもよい。
ASPサイト153は、広域ネットワーク152を介して、ユーザサイト151に所定のサービスを提供する。ASPサイト153が提供するサービスとしては、たとえば、情報の提供、作成、検索、蓄積、認証、配布、印刷、出版、管理、翻訳、委託などがある。また、官公庁手続や各種の電子商取引などもある。
ASPサイト153は、ローカルエリアネットワーク(LAN)154およびサーバ155を含んでいる。
LAN154は、ASPサイト153内部のネットワークであり、サイト153内のネットワーク機器を接続する。また、LAN154は、図示しないルータなどを介して、広域ネットワーク152と接続されている。
サーバ155上では、ASPが提供するサービスを実現するためのソフトウェアプロセス群が稼動している。このソフトウェアプロセス群を構成するソフトウェアモジュールには、以下がある。すなわち、クライアントからのHTTPプロトコルによる要求に応答してHTMLなどのコンテンツ(Webコンテンツデータ)を伝送するHTTPサーバ、HTTP要求に応じてHTTPサーバにより実行され、所定の処理と動的に変化するHTTP応答を行う、CGIプログラムやServletなどの形態で実装されたWebアプリケーション群、CGIプログラムやServletなどが所定の処理を実行するために用いられる、電子商取引プログラムなどのビジネスロジック群とバックエンドのデータベース管理システムである。
ユーザサイト151は、ホストコンピュータ101と、画像処理装置110,120および130などの複数のネットワーク機器と、ネットワーク機器群が接続されるLAN100とから構成される。ユーザサイト151のLAN100は、図示しないルータなどを介して、広域ネットワーク152に接続されている。ルータは、いわゆる防火壁(firewall)の機能も果たす。すなわち、外部ネットワークからの攻撃からユーザサイト151を守るために、パケットフィルタリングなどを行う。また、アドレス管理上の理由などのために、ネットワークアドレス変換やネットワークポート変換を行う場合もある。ルータのこれらの機能のために、ユーザサイト151と外部ネットワークとの間の通信には制限がつけられている。すなわち、多くの場合、いくつかの特定のプロトコルによる通信だけが可能となっている。たとえば、内部から外部に向かって確立されるHTTP接続は、一般に許可されている通信の例であり、これは、このような一般的なWebベースの技術に基づくアプリケーションサービスの提供が有効である理由のひとつとなっている。
なお、画像処理装置110,120および130はいずれも、本実施の形態の組み込み装置に相当するが、各画像処理装置110,120および130は、それぞれ同様に構成されているため、説明の都合上、画像処理装置110のみを本実施の形態の組み込み装置とする。
画像処理装置110は、画像の入出力と送受信および各種の画像処理を行う複合機(MFP:Multi Function Peripheral)であり、画像入力デバイスであるリーダ部113、画像出力デバイスであるプリンタ部114、制御ユニット(Controller Unit)111およびユーザインターフェースである操作部112から構成される。
リーダ部113、プリンタ部114および操作部112は、それぞれ、制御ユニット111に接続されて、制御ユニット111からの命令によって制御される。制御ユニット111は、LAN100などのネットワーク伝送手段に接続されている。
また、LAN100には、画像処理装置110と同様の機器構成をもつ、他の画像処理装置120および130が接続されている。画像処理装置120は、スキャナ部123、プリンタ部124および操作部122から構成されており、それらが制御ユニット121に接続されて、制御される。また、画像処理装置130は、スキャナ部133、プリンタ部134および操作部132から構成されており、それらが制御ユニット131に接続されて、制御される。
また、ホストコンピュータ101は、LAN100等のネットワーク伝送手段に接続されている。ホストコンピュータ101は、後述するようにWebブラウザを備え、各画像処理装置110,120,130から受信したHTMLファイルに基づいて、各画像処理装置110,120,130のステータスなどを表示する。また、サーバ155にHTTP接続してサービスの提供を受ける。
図2は、画像処理装置110のソフトウェア構成を示すブロック図である。なお、他の画像処理装置120および130のソフトウェア構成も、画像処理装置110と同様である。
ユーザインターフェース(以下、「UI」と略して言う)モジュール201は、ユーザが画像処理装置110に対する各種操作・設定を行う際に、機器とユーザ操作との仲介を行うモジュールである。このモジュール201は、ユーザの操作に従い、後述の各種モジュールに入力情報を転送して処理の依頼、あるいはデータの設定等を行う。
アドレスブック(Address-Book)モジュール202は、データの送付先や通信先等を管理するデータベースモジュールである。アドレスブックモジュール202が管理するデータは、UIモジュール201からの操作により、データの追加、削除、取得が行われる。また、アドレスブックモジュール202は、ユーザの操作により後述の各モジュールにデータの送付・通信先情報を与える。
Webサーバ(Web Server)モジュール203は、Webクライアント(たとえば、ホストコンピュータ101)からの要求により、HTMLなどで記述された情報をHTTPで提供する。
統合送信部(Universal Send)モジュール204は、データの配信を司るモジュールである。このモジュール204は、UIモジュール201を介してユーザによって指示されたデータを、同様にして指示された通信(出力)先に配布する。また、ユーザにより、画像処理装置110のスキャナ機能を使用して配布データの生成が指示された場合は、後述の制御APIモジュール218を介して画像処理装置110を動作させ、データの生成を行う。
P550モジュール205は、統合送信部モジュール204内で、出力先にプリンタが指定された際に実行されるモジュールである。E−mailモジュール206は、統合送信部モジュール204内で、通信先にE−mailアドレスが指定された際に実行されるモジュールである。データベース(DB)モジュール207は、統合送信部モジュール204内で、出力先にデータベースが指定された際に実行されるモジュールである。モジュール208は、統合送信部モジュール204内で、出力先に画像処理装置110と同様の画像処理装置が指定された際に実行されるモジュールである。
リモートコピースキャン(Remote Copy Scan)モジュール209は、画像処理装置110のスキャナ機能を使用して画像情報を読み取り、読み取った画像情報をネットワーク等で接続された他の画像処理装置に出力することにより、画像処理装置110単体で実現しているコピー機能を他の画像処理装置を使って行うモジュールである。
リモートコピープリント(Remote Copy Print)モジュール210は、ネットワーク等で接続された他の画像処理装置で得られた画像情報を、本画像処理装置110のプリンタ機能を使用して出力することにより、画像処理装置110単体で実現しているコピー機能を他の画像処理装置を使って行うモジュールである。
Webブラウザ(Web Browser)モジュール211は、インターネットまたはイントラネット上の各種Webサイト(ホームページ)の情報を読み込んで表示を行うモジュールである。Webブラウザの詳細な構成は、後述する。
HTTPモジュール212は、画像処理装置110がHTTPによる通信を行なう際に使用されるモジュールであり、後述のTCP/IP(Transmission Control Protocol/Internet Protocol)通信モジュール216を使って、Webサーバモジュール203やWebブラウザモジュール211に通信機能を提供する。このモジュール212は、HTTPをはじめとするWebで用いられる各種プロトコルに対応し、特にセキュリティー対応したプロトコルによる通信機能も提供する。
LPRモジュール213は、TCP/IP通信モジュール216を使って、統合送信部モジュール204内のプリンタモジュール205に通信機能を提供するものである。
SMTP(Simple Mail Transfer Protocol)モジュール214は、TCP/IP通信モジュール216を使って、統合送信部モジュール204内のE−mailモジュール206に通信機能を提供する。
SLM(Salutation Manager)モジュール215は、TCP/IP通信モジュール216を使って、統合送信部モジュール204内のデータベースモジュール207およびDPモジュール208と、リモートコピースキャンモジュール209と、リモートコピープリントモジュール210とに通信機能を提供する。
TCP/IP通信モジュール216は、後述のネットワークドライバ217を用いて、前述の各種モジュールにネットワーク通信機能を提供する。
ネットワークドライバ217は、ネットワークに物理的に接続される部分を制御するものである。
制御APIモジュール218は、統合送信部モジュール204等の上流モジュールに、後述のジョブマネージャ(Job Manager)モジュール219等の下流モジュールに対するインターフェースを提供するものである。これによって、上流および下流のモジュール間の依存関係が軽減され、それぞれの流用性を高めることができる。
ジョブマネージャモジュール219は、前述の各種モジュールから制御APIモジュール218を介して指示される様々な処理を解釈し、後述の各モジュール220,224および226に指示を与えるものである。また、ジョブマネージャモジュール219は、画像処理装置110内で実行されるハード的な処理を一元管理する。
コーデックマネージャ(CODEC Manager)モジュール220は、ジョブマネージャモジュール219が指示する処理の中で、データの各種圧縮・伸長を管理・制御するものである。
エンコーダモジュール221は、ジョブマネージャモジュール219や後述のスキャンマネージャ(Scan Manager)モジュール224によって実行されたスキャン処理によって読み込まれたデータを、所定のエンコード手法を用いて圧縮するものである。
JPEGコーデック(JPEG(Joint Photographic Expert Group) CODEC)モジュール222は、ジョブマネージャモジュール219やスキャンマネージャモジュール224によって実行されたスキャン処理、あるいはプリントマネージャ(Print-Manager)モジュール226によって実行された印刷処理において、読み込まれたデータのJPEG圧縮および印刷データのJPEG展開処理を行うものである。
MMR(Modified Modified READ)コーデック(MMR CODEC)モジュール223は、ジョブマネージャモジュール219やスキャンマネージャモジュール224によって実行されたスキャン処理、あるいはプリントマネージャモジュール226によって実行された印刷処理において、読み込まれたデータのMMR圧縮および印刷データのMMR伸長処理を行うものである。
情報埋め込み画像コーデック(IEI CODEC)モジュール229は、ジョブマネージャモジュール219やスキャンマネージャモジュール224によって実行されたスキャン処理、あるいはプリントマネージャモジュール226によって実行された印刷処理において、読み込まれた画像データに埋め込まれた情報のデコード、および印刷画像データへの情報埋め込みを行うものである。画像データへの情報の埋め込みは、バーコードやデジタル透かし(デジタルウォーターマーク)などの符号化技術を用いて行う。また、像域分離とOCR(Optical Character Reader)技術によって画像データの画像中の文字を認識しテキストデータに変換する文字認識も、一種の復号化技術としてサポートする。さらにラスタイメージプロセッサを用いたテキストから画像データへの変換と、変換した画像データとオリジナル画像データとの重ね合わせ(オーバレイ)も、一種の符号化技術(情報埋め込み技術)としてサポートする。
スキャンマネージャ(Scan Manager)モジュール224は、ジョブマネージャモジュール219が指示するスキャン処理を管理・制御するものである。
SCSI(Small Computer System Interface)ドライバ225は、スキャンマネージャモジュール224と、画像処理装置110に内部的に接続しているスキャナ部との間の通信を取り持つものである。
プリントマネージャ(Print Manager)モジュール226は、ジョブマネージャモジュール219が指示する印刷処理を管理・制御するものである。
エンジンインターフェース(Engine I/F)モジュール227は、プリントマネージャモジュール226と印刷部との間のインターフェースを提供する。
パラレルポートドライバ228は、Webサーバモジュール203のリファレンスプリント機能や、Webブラウザモジュール211のWebプルプリント機能などのデータプリント機能がパラレルポートを介して不図示の出力機器にデータを出力する際のI/F(インターフェース)を提供する。
図3は、画像処理装置110の詳細なハードウェア構成を示すブロック図である。
制御ユニット111は、画像入力デバイスであるリーダ部113や、画像出力デバイスであるプリンタ部114と接続し、一方ではLANや公衆回線(WAN)と接続することで、画像情報やデバイス情報の入出力を行うコントローラである。
CPU301は、画像処理装置110の装置全体を制御するコントローラである。
RAM302は、CPU301が動作するために使用するシステムワークメモリである。また、RAM302は、画像データを一時記憶するための画像メモリでもある。
ROM303は、ブートROMであり、システムのブートプログラムが格納されている。
HDD304は、ハードディスクドライブで、システムソフトウェアや画像データを格納する。
操作部I/F306は、操作部(UI)112との間のインターフェースを司り、操作部112のディスプレイ(図示せず)に表示する画像データを操作部112に対して出力する。また、ユーザが操作部112を介して入力した情報を、CPU301に伝える役割も果たす。
ネットワーク(Network)I/F308は、LAN100との接続を司り、LAN100を介して情報の入出力を行う。
モデム(MODEM)309は、公衆回線との接続を司り、公衆回線を介して情報の入出力を行う。
以上のデバイス301〜306,308および309が、システムバス307上に配置されている。
画像バスI/F(Image Bus I/F)305は、システムバス307と、画像データを高速に転送する画像バス310とを接続するとともに、画像データのデータ構造を変換するバスブリッジである。
画像バス310は、PCI(Peripheral Component Interconnect)バスまたはIEEE1394で構成される。
画像バス310には、以下のデバイス311〜316が配置されている。
ラスターイメージプロセッサ(RIP)311は、ネットワークから送信されたPDL(Page Description Language)コードをビットマップイメージに展開する。また、PDL以外にも、たとえばPDF(Portable Document Format)データや各種アプリケーション固有のアプリケーションデータをビットマップイメージに展開するダイレクトプリントのための処理も行う。
デバイスI/F部312は、画像入出力デバイスであるリーダ部113およびプリンタ部114と、制御ユニット111とを接続し、画像データの同期系/非同期系の変換を行う。
スキャナ画像処理部313は、入力画像データに対し補正、加工、編集を行う。
プリンタ画像処理部314は、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。
画像回転部315は、画像データの回転を行う。
画像圧縮部316は、多値画像データに対してはJPEG圧縮伸長処理を行い、二値画像データに対してはJBIG(Joint Bi-level Image experts Group),MMR,MH(Modified Huffman)の圧縮伸長処理を行う。
図4は、画像処理装置110の外観を示す図である。
画像入力デバイスであるリーダ部113は、原稿となる紙上の画像を照明し、CCDラインセンサ(図示せず)を走査することによって、ラスターイメージデータを生成する。
ユーザが、原稿用紙を原稿フィーダ405のトレイ406にセットして、操作部112において原稿画像の読み取りを指示すると、前記図3のCPU301は、リーダ部113に指示を与え、これに応じて、フィーダ405は、原稿用紙を1枚ずつフィードし、リーダ部113は、原稿画像の読み取り動作を行う。
画像出力デバイスであるプリンタ部114は、ラスターイメージデータを用紙上に印刷する。その印刷方式としては、感光体ドラムや感光体ベルトを用いた電子写真方式や、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式を採用しても構わない。なお、プリント動作は、CPU301からの指示に応じてなされる。
プリンタ部114は、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセット401,402および403を備えている。また、排紙トレイ404は、印字し終わった用紙を受けるものである。
図5は、操作部112の詳細な外観を示す図である。
LCD表示部501は、タッチパネルシートが貼られたLCD502を備え、システムの操作画面およびソフトキーを表示するとともに、表示してあるキーが押されると、押された位置を示す位置情報を前記CPU301に伝達する。
スタートキー505は、原稿画像の読み取り動作を開始する場合等に用いられる。スタートキー505の中央部には、緑と赤の2色のLEDからなるLED表示部506が設けられ、その色によってスタートキー505が使える状態にあるかどうかが示される。
ストップキー503は、稼働中の動作を止める働きをする。
IDキー507は、ユーザIDを入力するときに用いられる。
リセットキー504は、操作部112からの設定を初期化するときに用いられる。
図6は、操作部112の詳細な機能構成を示すブロック図である。
上述したように、操作部112は、操作部I/F306を介してシステムバス307に接続され、システムバス307には、CPU301、RAM302、ROM303およびHDD304が接続されている。CPU301は、ROM303とHDD304に記憶された制御プログラム等に基づいてシステムバス307に接続される各種デバイスとのアクセスを総括的に制御する。また、CPU301は、デバイスI/F312を介して接続されるリーダ部113から入力情報を読み込み、デバイスI/F312を介して接続されるプリンタ部114に出力情報としての画像信号を出力する。RAM302は、CPU301の主メモリであり、ワークエリア等として機能する。
タッチパネル502や各種ハードキー503,504,505および507からのユーザ入力は、入力ポート601を介してCPU301に伝達される。CPU301は、ユーザ入力の内容と制御プログラムとに基づいて表示画面データを生成し、画面出力デバイスを制御する出力ポート602を介して、LCD表示部501に表示画面を出力する。また、必要に応じてLED表示部506を制御する。
図7は、画像処理装置110に組み込まれたアプリケーションの動作を説明するためのネットワーク構成の一例を示すブロック図である。
同図において、装置4300は、リモートコピーにおける受信側(プリント側)の複合機器である。装置4350は、統合送信部モジュール204から同報配信される画像データを受信してプリントする、たとえばレーザビームプリンタ(LBP)などのプリンタ機器である。装置4400は、リモートプリントの受信側(プリント側)のデバイスである。装置4450は、同報配信される画像データを受信し格納するグループウェアサーバである。装置4500および4600は、同報配信される二値画像データを受信し格納する画像データベースサーバである。装置4550は、同報配信される電子メールを受信し格納するメールサーバである。装置4650は、情報コンテンツを有するWebサーバである。装置4700は、WebサーバなどにアクセスするWebブラウザである。
(UIアプリケーション)
UIモジュール201の詳細は、前述した通りであるので、ここではアドレスブックモジュール202について説明する。
アドレスブックモジュール202は、画像処理装置110の不揮発性メモリ、たとえばバッテリバックアップされたメモリやハードディスクなどに保存されていて、その中にはネットワーク接続された機器の特徴が記載されている。具体的には、以下に列挙するような情報がアドレスブックモジュール202に含まれている。すなわち、
(1)機器の正式名やエイリアス名
(2)機器のネットワークアドレス
(3)機器が処理可能なネットワークプロトコル
(4)機器が処理可能なドキュメントフォーマット
(5)機器が処理可能な圧縮タイプ
(6)機器が処理可能なイメージ解像度
(7)プリンタ機器の場合は給紙可能な紙サイズおよび給紙段の情報
(8)サーバ機器の場合はドキュメントを格納可能なフォルダ名
などである。
以下に説明する各アプリケーションは、アドレスブックモジュール202に記載された情報に基づいて、配信先の特徴を判別できる。また、アドレスブックモジュール202は、編集可能であるとともに、ネットワーク内のサーバなどに保存されているものがダウンロードされて使用される。または、直接参照することも可能である。
(リモートコピーアプリケーション)
リモートコピースキャンモジュール209で実行されるリモートコピーアプリケーションは、アドレスブックモジュール202によって認識可能な配信先に指定された機器が処理可能な解像度情報に従って、スキャナで読み取った二値画像データをMMR圧縮かつTIFF(Tagged Image File Format)化した後、SLMモジュール215を介してネットワーク上の複合機器4300などに送信する。
(同報配信アプリケーション)
統合送信部モジュール204で実行される同報配信アプリケーションは、リモートコピーアプリケーションと違い、一度の画像スキャンで複数の配信先に画像を送信することが可能である。また、その配信先もプリンタ機器に限らず、サーバなどにも直接配信可能である。以下、配信先毎に説明する。
配信先の機器のネットワークプリンタプロトコルがLPD(Line Printer Daemon)であり、かつ、公知のプリント記述言語(PDL)が処理可能であることがアドレスブックモジュール202から認識される場合は、同様にアドレスブックモジュール202から認識される配信先の機器の画像解像度に従って画像を読み取り、画像自体はエンコーダモジュール221により圧縮し、さらにPDL化して、LPRモジュール213により配信先のプリンタ機器4350などに送信する。
配信先の機器が、SLMにより通信可能であり、かつ、サーバである場合には、アドレスブックモジュール202からサーバアドレスおよびサーバのフォルダ指定を認識して、リモートコピーアプリケーションと同様に、スキャナにより読み取った二値画像データをMMR圧縮し、かつ、TIFF化し、SLMモジュール215を介してネットワーク上のサーバ4550や4500などの特定フォルダに格納することが可能である。また、配信先のサーバが、JPEG圧縮された多値画像を処理可能だと判断される場合には、スキャナにより読み取った画像をJPEG圧縮し、かつ、JFIF(JPEG File Interchange Format)化し、SLMモジュール215を介してネットワーク上のサーバ4600などの特定フォルダに格納することが可能である。
配信先の機器が電子メールサーバの場合には、アドレスブックモジュール202に記載されたメールアドレスを認識して、スキャナにより読み取った二値画像データをMMR圧縮し、かつ、TIFF化し、SMTPモジュール214を介して電子メールサーバ4550などに送信する。その後の配信は、電子メールサーバ4550により実行される。
(Webプルプリントアプリケーション)
Webブラウザモジュール211で実行されるWebプルプリントアプリケーションは、Webサーバ4650などのWebサイトの情報をプリントする。
(Webサーバアプリケーション)
Webサーバモジュール203で実行されるWebサーバアプリケーションは、HTMLなどで記述された情報を、HTTPモジュール212を介してWebブラウザ4700などに提供する。Webサーバアプリケーションは、静的なHTML文書などの情報だけでなく、装置の管理情報を反映した文書を動的に生成して、Webブラウザ4700などに提供する。この管理情報は、統合送信部モジュール204、リモートコピースキャンモジュール209、リモートコピープリントモジュール210および制御APIモジュール218を介して取得され、HTTPモジュール212、TCP/IP通信モジュール216およびネットワークドライバ217を介して、Webクライアントに通知される。さらにまた、Webサーバモジュール203は、Webクライアントにリファレンスプリント機能も提供する。リファレンスプリントでは、WebクライアントがWebサーバモジュール203に対して、HTTPでPOST要求の内容として(またはGET要求のパスの一部に埋め込んで)URL情報を送信する。Webサーバモジュール203は、URL情報を受信し、次に受信したURLの位置からHTTPによってデータを取得し、次に取得したデータをそのまま制御APIモジュール218に渡すことによってプリントを行う。HTTPによって取得可能な位置に、各種PDLなどで記述された、プリンタがプリント可能なデータが置かれている場合には、クライアントは、単にURLをWebサーバに指示するだけで、所望のプリントを行うことできる(データの実体を送信せず、「参照」を送信するだけでよい)。プリンタは、各種PDLで記述されたデータの他に、PDFのデータやアプリケーションデータを直接プリントするダイレクトプリント機能を備えることができるため、ネットワークのWebサーバに散在して配置された各種データを効率良くプリントすることができる。
図8は、Webブラウザモジュール211のソフトウェア構成を示すブロック図である。
プロトコル処理部801は、HTTPモジュール212を介して、他のネットワークノードとの間に接続を確立し通信する。具体的には、URLによって記述されたリソースに対してHTTP要求を発行し、その応答を得る。この過程で、各種符号化形式に則した通信データの符号化・復号化も行う。プロトコル処理部801が、HTMLなどのマークアップ言語で記述された構造を持つテキストデータと、その構造に埋め込まれる画像、スクリプトおよびスタイルなどのデータを取得すると、プロトコル処理部801は、そのデータをコンテンツパーサ802に引き渡す。一方、プロトコル処理部801が、ページ全体がひとつの画像データ形式や構造を持たないテキストデータ形式であるようなコンテンツを取得した場合には、プロトコル処理部801は、そのデータをレンダラ808(ブラウザ手段)に引き渡す。これに応じて、レンダラ808は、レンダリングを行い、そのレンダリング結果をUIモジュール201に表示させる。
さらに、プロトコル処理部801が、Webブラウザモジュール211によって処理できない形式のデータを取得した場合には、プロトコル処理部801は、後述する代替処理に委ねる判断を行い、そのデータを制御APIモジュール218に引き渡す。
コンテンツパーサ802は、プロトコル処理部801からHTML,XML(Extensible Markup Language)およびXHTML(Extensible Hypertext Markup Language)などの表現形式で表現されたコンテンツデータ(Webコンテンツデータ)を受け取り、字句解析および構文解析を行って、解析木を生成する。
DOM構築部803は、コンテンツパーサ802から解析木を受け取り、コンテンツデータの構造に対応したDOMの構築を行う。旧来のHTMLは、文法上さまざまな省略を許し、バリエーションが多岐に亘る。さらに現実世界で運用されているコンテンツは、整形式でも妥当でもない場合が多い。そこで、DOM構築部803は、他の一般的なWebブラウザと同様に、文法的に妥当でないコンテンツデータの正しい論理構造を推論し、妥当なDOMの構築を試みる。
DOM処理部804は、DOM構築部803が構築したDOMを、オブジェクト群の入れ子関係を表現するツリー構造として、メモリ上に保持管理する。Webブラウザモジュール211の各種処理は、このDOMを中心に実現される。
レイアウトエンジン807は、DOM処理部804が保持するオブジェクト群のツリー構造に応じて、各オブジェクトの表示上の表現(プレゼンテーション)を再帰的に決定し、結果的に文書全体のレイアウトを得る。各オブジェクトの表示上の表現は、文書の中に埋め込まれた記述、あるいは、文書からリンクされた別ファイル中の記述によって、CSS(Cascading Style Sheet)などのスタイルシート形式で明示的に指定される場合がある。
スタイルシートパーサ806は、コンテンツの文書に関連付けられたスタイルシートを解析する。
レイアウトエンジン807は、スタイルシートパーサ806によるスタイルシートの解析結果を反映して文書のレイアウトを決定する。
レンダラ808は、レイアウトエンジン807が決定した文書のレイアウトに応じて、LCD表示部501に表示するためのGUI(Graphical User Interface)データ(画面情報)を生成する。生成されたGUIデータは、UIモジュール201によってLCD表示部501に表示される。
イベント処理部809(機能実行手段)は、操作部112上のタッチパネルシート502や各キーなどに対してユーザが行った操作のイベントを受信して、各イベントに対応した処理を行う。イベント処理部809はまた、制御APIモジュール218(機能実行手段)から装置やジョブなどの状態遷移イベントを受信して、各イベントに対応した処理を行う。
DOM処理部804が管理するDOMのツリー構造には、オブジェクトのクラス毎、および、オブジェクトインスタンス毎に、各種イベントに対応するイベントハンドラが登録されている。
イベント処理部809は、生起したイベントに応じて、DOM処理部804が管理するオブジェクト群の中から、そのイベントの処理を担当すべきオブジェクトを決定し、イベントを配信する。イベントの配信されたオブジェクトは、そのイベントに対応するイベントハンドラのアルゴリズムに応じて、各種の処理を実行する。イベントハンドラの処理には、DOM処理部804が保持するDOMの更新、レイアウトエンジン807に対する再描画指示、プロトコル処理部801に対するHTTP要求発行の指示、制御APIモジュール218の呼び出しによる画像処理装置機能の制御などがある。
スクリプトインタプリタ805(スクリプト実行手段)は、Java(登録商標)ScriptやECMA Scriptなどのスクリプトを解釈し、実行するインタプリタである。スクリプトは、文書に埋め込まれたり、あるいは、文書からリンクされた別ファイル中に記述されたりして、DOMに対する操作などを行う。コンテンツの提供者は、スクリプトによって、提供する文書の動的な挙動をプログラムできる。
図9は、LCD表示部501に表示されるWebブラウザの画面構成の一例を示す図である。
同図において、タブ901は、Webブラウザ機能と他の機能(コピー、ボックス、送信および拡張)との画面切り替えを行うためのものである。
URL入力フィールド902は、ユーザが所望のリソースのURLを入力するフィールドである。当該フィールドをユーザが指定すると、文字入力を行うための仮想的なフルキーボード(不図示)が表示される。ユーザは、仮想的なフルキーボード上に配置された、キートップを模したソフトキーによって、所望の文字列を入力することができる。
OKボタン903は、入力したURL文字列を確定するソフトキーである。URLが確定されると、Webブラウザモジュール211は、当該リソースの取得を行うためのHTTP要求を発行する。
プログレスバー904は、HTTP要求応答によるコンテンツ取得処理の進捗状況を示すものである。
コンテンツ表示領域905は、取得したリソースが表示される領域である。
戻るボタン906は、ソフトキーであり、コンテンツ表示の履歴をさかのぼり、現時点で表示しているコンテンツの前に表示したコンテンツを表示し直すためのものである。
進むボタン907は、ソフトキーであり、コンテンツ表示の履歴をさかのぼって表示しているときに、現時点で表示しているコンテンツの後に表示したコンテンツの表示に進ませるためのものである。
リロードボタン908は、ソフトキーであり、現時点で表示しているコンテンツの再取得と再表示を行うためのものである。
中止ボタン909は、ソフトキーであり、実行中のコンテンツ取得処理を中止させるためのものである。
ステータス領域910は、画像処理装置110の各種機能からのメッセージを表示する領域である。Webブラウザ画面を表示中であっても、リーダ部113やプリンタ部114や他の機能などから送信された、ユーザの注意を促すためのメッセージを表示することができる。また、同様にWebブラウザ機能からもメッセージの表示を行う。Webブラウザ機能では、リンク先のURL文字列、コンテンツのタイトル文字列、スクリプトによって指示されたメッセージなどを表示する。
図10は、HTTPによる要求と応答の処理の流れの一例を示すシーケンス図である。
クライアント1001は、HTTP要求を送信し、HTTP応答を受信するソフトウェアであり、画像処理装置110内蔵のWebブラウザや、PC(Personal Computer)、PDA(Personal Digital Assistant)、携帯電話などで稼動する一般的なWebブラウザや、さらにWebブラウザと同様の方法でWebサーバにアクセスしてサービスの利用または中継を行う各種のソフトウェアに相当する。
サーバ1002は、HTTP要求を受信して対応する処理を行い、さらにHTTP応答を返信するソフトウェアであり、サーバ155上で稼動するソフトウェアをはじめとするHTTPサーバに相当する。
HTTP要求1003では、クライアント1001は、所望のリソースに対するGET要求をサーバ1002に送信する。リソースは、一般にURI(Uniform Resorce Identifier)(特にURL)形式によって指定される。サーバ1002は、GET要求に指定されたリソースに対応するデータを取得、または、生成して、HTTP応答1004によって返送する。ここで、指定されたリソースが静的なファイルに対応する場合には、サーバ1002は、サーバ155のファイルシステムから該当するファイルを読み出して、そのデータを取得する。一方、指定されたリソースがCGIプログラムやServletなどの処理に対応する場合には、サーバ1002は、該当する処理を実行する。すなわち、サーバサイド処理が行われる。サーバサイド処理は、要求に対する応答を生成するものであるが、この過程で、所定のサービスを達成するために必要なビジネスロジックの実行や、バックエンドのデータベース管理システムへのアクセスなどの副作用が伴うこともある。そして、サーバサイド処理の結果として生成されたデータを返送する。たとえば、画像処理装置110の消耗品カタログを表示するためのリソースが指定された場合には、電子商取引のためのソフトウェアを実行し、データベースの中から用紙、トナー、部品の最新価格や在庫状況などのレコードを参照し、これらの情報をHTML形式またはXML形式に整形して、カタログ文書データを生成する処理が行われる。
HTTP応答1004で得られたデータが表示可能な形式である場合には、クライアント1001は、そのコンテンツの表示を行う。得られたデータがHTML文書などであり、文書中に他のリソースへの参照情報(画像や埋め込みオブジェクトや他のHTML文書の取得元URIなど)が埋め込まれていれば、Webブラウザは、参照される他のリソースを取得するためのHTTP要求の送信を必要なだけ繰り返す。得られたデータがHTML文書などであれば、Webブラウザ上に表示されたページ中のハイパーテキストなど、リンク情報が埋め込まれたアンカーをユーザが選択するだけで、次々に新たなリソースの取得や表示を繰り返すことができる。
HTTP要求1005は、POST要求である。HTML文書がフォーム(FORM)を含み、そのメソッドにPOSTが指定されている場合には、ユーザがフォームをサブミットすると、指定リソースに対するPOST要求が送信される。POST要求では、クライアント1001からサーバ1002に向けてデータを送信する(応答によってサーバ1002からクライアント1001に向けたデータの返信も行われる)。Webブラウザに表示されたフォームに、ユーザが入力した情報が符号化されて、POST要求によってサーバ1002に送信される。サーバ1002の指定リソースは、クライアント1001から送られたデータを受信して処理を行い、HTTP応答1006を生成して返信する。
HTTP要求としてクライアント1001からサーバ1002に送信されるメッセージ中に含まれるプロトコルヘッダのUser-Agent属性によって、クライアント1001は、サーバ1002に対して、自らがどのような種類のクライアントであるかを示すことができる。User-Agentの値には、組み込みWebブラウザの実装を識別するための固有の文字列が記述される。
HTTP応答としてサーバ1001からクライアント1002に返されるデータは、プロトコルヘッダのContent-Type属性によってそのデータ型が記述される。具体的に、Content-Typeには、データ型の記述子が、以下のように記述される。すなわち、HTTP応答によって、たとえばHTML文書を転送する場合には、
Content-Type: text/html; charset=Shift_JIS
などのように記述される。また、HTTP応答によって、たとえばPDF文書を転送する場合には、
Content-Type: application/pdf
のように記述される。
図11は、サーバサイド処理とクライアントサイド処理の流れの一例を示す図である。
HTTP要求1003では、クライアント1001は、所望のリソースに対するGET要求をサーバ1002に送信する。リソースは、一般にURI(特にURL)形式によって指定される。サーバ1002は、GET要求で指定されたリソースに対応するデータを取得、または、生成して、HTTP応答1004によって返送する。HTTP応答1004で得られたデータが表示可能な形式である場合には、クライアント1001は、そのコンテンツの表示を行う。得られたデータがHTML文書などであれば、Webブラウザは、文書の解釈を行いながら、DOM構築部803によってDOMを構築する。文書にJava(登録商標)Scriptなどのスクリプトが埋め込まれている場合には、埋め込まれたスクリプトを、対応するスクリプトインタプリタにロードし、クライアントサイド処理を実行する。クライアントサイド処理では、スクリプトの内容次第でさまざまな処理を実行することができるが、たとえば、スクリプトが生成したデータを解析中の文書に挿入するなど、動的な文書操作が可能である。文書のonloadイベントに呼応するイベントハンドラがスクリプトインタプリタにロードされ、登録されていた場合、文書を構成するすべてのリソースが取得され、解析されたタイミングで、イベントハンドラのコードが実行される。この実行によって文書を操作することもできる。
さらに、タッチパネルなどのユーザ入力手段を操作することによって、文書や文書の要素にイベントを生起させたり、スクリプトインタプリタが監視するタイマのタイムアップなどのイベントが生起したりした場合に、イベントハンドラとしてロードされ、登録されたスクリプトのコードがあれば、それが実行される。
サーバサイド処理の場合と異なり、クライアントサイド処理の実行は、クライアント1001側のスクリプトインタプリタによって処理されるため、ユーザ入力をサーバ1002側まで伝える必要は必ずしもない。単純なコンピューティングによって達成される処理の場合、クライアントサイド処理で実現すれば、サーバ1002との要求・応答の通信時間が省略できる分だけターンアラウンドタイムを改善できる。また、各クライアント1001が処理を分担するため、サーバ1002側のコンピューティング資源に負荷が集中することを避ける効果もある。特筆すべきは、処理の実現にサーバ1002との対話的な通信が不要となるために、装置のユーザがプライバシーを求める情報をネットワークやサーバ1002に送らずに装置の中にとどめたままで処理することが可能となる。
現実には、クライアントサイド処理とサーバサイド処理の両者を適切に組み合わせてサービスを実装する場合が多い。
図12は、画像処理装置110を利用するユーザのユーザアカウントを管理するデータ構造の一例を示す図であり、ユーザアカウント情報のテーブルにおいて、各行は装置を利用し得る個々のユーザに対応している。
同図において、“system”と“guest”は、画像処理装置110で内部的に用いる仮想的なユーザであり、それ以外は、実際に画像処理装置110を利用する実在のユーザ個人に対応している。
“system”は、装置システムが所有者であるような資源を識別するために利用される。“guest”は、ユーザを認証しなくとも一部の資源が利用可能であるような運用を行う場合に、認証されていないユーザを表現するために利用される。各列は、それぞれ、以下の意味を持つ。
すなわち、ユーザ名の列は、ユーザを識別するための識別子である。同図では、文字列によって表現しているが、内部的には個々のユーザに対応する数値などで表現してもよい。
プライマリグループの列は、各ユーザが所属する既定のグループを表現する識別子である。各ユーザは、既定のグループに加えて他の複数のグループに所属することもできる。グループについては後述する。
パスワードの列は、what-you-know型のユーザ認証によってユーザを認証するときに用いるパスワードである。スマートカードの機能によってユーザ認証を行うときには、この列の情報を用いなくてもよいし、またスマートカードと併用するPIN(Personal Identification Number)を格納するために用いてもよい。
電子メールアドレスの列は、各ユーザの電子メールアドレスを示している。
内線の列は、各ユーザの内線電話番号を示している。
この他、ユーザ毎の情報を登録するためにさまざまな列を追加してもよい。たとえば、ユーザのフルネームや、既定の機能や、既定のボックス内フォルダや、好みの設定などを登録する列を追加すれば、それらをユーザ毎に固有の情報として格納することができる。
図13は、画像処理装置110を利用するユーザのグループを管理するデータ構造の一例を示す図であり、各行はユーザが所属し得る個々のグループに対応している。
グループは、ユーザの集合を表現するオブジェクトであり、組織の部門や役職および担う役割など、さまざまな集合を定義することができる。ユーザは、同時に複数のグループに所属できる。
グループ名の列は、グループを識別するための識別子である。同図では、文字列によって表現しているが、内部的には個々のグループに対応する数値などで表現してもよい。
メンバリストの列は、グループに所属するユーザたちを定義するリストを示している。本実施の形態では、“system”は、ユーザシステムのプライマリグループとして用いるための仮想的なグループである。“guest”は、ユーザ認証を行わずに装置の利用を許す場合のゲストユーザに相当する。“admin”は、装置の管理を行う管理者のグループである。“user”は、装置にユーザアカウントを持つ全ユーザのグループである。“rd”と“sales”は、組織の部門に相当するグループである。“manager”は、組織の役職に相当するグループである。“operator”は、装置内部のデータのバックアップなど専門的な操作を行うための管理者に準ずる役割に相当するグループである。
図14は、画像処理装置110を構成する各種資源を抽象化して表現したリソースクラスのデータ構造を示す模式図である。
リソースクラスは、装置オブジェクトモデルを構成する各種オブジェクトの設計図にあたるクラスの一例である。各装置オブジェクト(およびその設計図としてのクラス)は、内部にいくつかの特性(フィーチャ)を持っている。特性は、データや他のオブジェクトへの参照を保持する属性(またはプロパティ、データメンバ、変数などと呼ばれる)と、操作(またはメソッド、オペレーション、メンバ関数など)とを含んでいる。
装置オブジェクトとそのクラスは、スクリプトインタプリタがサポートする各種のスクリプト言語体系にバインドされ、それぞれの言語の構文と意味論によって利用できる。Java(登録商標)Scriptにおいて、装置オブジェクトモデルのオブジェクトは、Java(登録商標)Scriptのオブジェクト型に対応付けられる。装置オブジェクトモデルのクラスは、Java(登録商標)Script的な意味でのクラスに対応付けられる。なお、他のスクリプト言語の多くと同様に、Java(登録商標)Scriptは、「強い型付け」された言語ではなく、Java(登録商標)やC++のような意味でのクラスという概念は持たない。ただし、クラスに相当するオブジェクトを定義し、そのオブジェクトのコンストラクタとプロトタイプオブジェクトを利用することで、クラスが持つ多くの概念を実質的に実現している。
リソースクラス1901は、画像処理装置110が扱うすべての資源に相当するクラスのスーパークラスである。リソースクラス1901は、複数のインスタンス属性とクラス属性とを保持できる。
オーナIDは、インスタンス属性であり、当該資源を所有するユーザの識別子を保持する。
グループIDは、インスタンス属性であり、当該資源の所有権を持つグループの識別子を保持する。
オーナへの読み出し許可は、インスタンス属性であり、オーナIDが示すユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
オーナへの書き込み許可は、インスタンス属性であり、オーナIDが示すユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
オーナへの実行許可は、インスタンス属性であり、オーナIDが示すユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの読み出し許可は、インスタンス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの書き込み許可は、インスタンス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの実行許可は、インスタンス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への読み出し許可は、インスタンス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への書き込み許可は、インスタンス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への実行許可は、インスタンス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが、当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
既定のオーナIDは、クラス属性であり、当該資源を所有するデフォルトのユーザの識別子を保持する。
既定のグループIDは、クラス属性であり、当該資源の所有権を持つデフォルトのグループの識別子を保持する。
オーナへの既定の読み出し許可は、クラス属性であり、オーナIDが示すユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
オーナへの既定の書き込み許可は、クラス属性であり、オーナIDが示すユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
オーナへの既定の実行許可は、クラス属性であり、オーナIDが示すユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの既定の読み出し許可は、クラス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの既定の書き込み許可は、クラス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
グループへの既定の実行許可は、クラス属性であり、グループIDが示すグループに所属するユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への既定の読み出し許可は、クラス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが当該資源に対して読み出し操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への既定の書き込み許可は、クラス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが当該資源に対して書き込み操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
他者への既定の実行許可は、クラス属性であり、ユーザIDが示すユーザにも、グループIDが示すグループに所属するユーザにも該当しないユーザが当該資源に対して実行操作を行う権限を持つか否かを表現する。本属性は、「可」、「不可」または「未設定」のいずれかの値を採り得る。
装置オブジェクトモデルを構成するオブジェクトを、Java(登録商標)Scriptなどのスクリプトが扱うとき、スクリプトの権限は、Webブラウザを操作している実効ユーザの権限に等しいものとする。スクリプトにそのオブジェクトの読み出し権限がある場合のみ、スクリプトからの属性の読み出しが許可され、スクリプトにそのオブジェクトの書き込み権限がある場合のみ、スクリプトからの属性の変更が許可され、スクリプトにそのオブジェクトの実行権限がある場合のみ、スクリプトからの操作の呼び出しが許可される。さらに、以上説明した許可および既定の許可の属性において、「読み出し」、「書き込み」および「実行」の意味は、本リソースクラスを継承するサブクラスが表現する各種の資源毎に適切にその資源に固有のセマンティクスが追加定義される場合がある。
以上説明した許可のインスタンス属性と既定の許可のクラス属性とは、それぞれが対応している。ある資源のクラスからインスタンスを生成するときに、そのクラスの既定の許可のクラス属性を用いて生成されるインスタンスの、対応する許可のインスタンス属性を初期化する。または、ある資源のインスタンスに許可のインスタンス属性が未設定の場合に、そのインスタンスのクラスが保持している既定の許可のクラス属性を代わりに用いるように構成してもよい。
本実施の形態では、上記許可属性群によって資源のアクセス権限を表現したが、資源に相当するクラス毎に公知のアクセスコントロールリスト(ACL)を保持することによって、資源のアクセス権限を表現するように構成してもよい。
図15は、画像処理装置110を構成する各種資源間の継承関係を表すデータ構造の一例を示すクラス図である。
同図の各クラスは、オブジェクトを生成(インスタンス化)するために用いられる。これらのクラスによって生成されるオブジェクト群は、DOM処理部804内部に保持され、スクリプトインタプリタ805がアクセスする装置オブジェクトモデルを構成する。
画像処理装置110が停止している間も、クラスとクラスとの間の関係は、バイト列にシリアライズされ、HDD304中にファイルとして永続的に記憶されている。画像処理装置110の起動時と稼動中、制御ユニット111のCPU301によってこのファイルが読み込まれ、本クラス図に示すクラス群とそのインスタンスであるオブジェクト群がそれぞれ相互関係を保持したデータ構造としてRAM302内に動的に生成され、維持管理される。
リソース1901は、システム内の各種資源を抽象化したクラスであり、マルチユーザ対応された画像処理装置110のアクセス制御に用いられる。リソースクラスは、少なくとも前記図14で説明した属性を備え、これらは、以下で説明するすべてのサブクラスに継承され、すべてのサブクラスが共通に持つ特性となる。
ユニット1902は、リソース1901のサブクラスであり、画像処理装置110を構成する物理的なユニットを抽象化したクラスである。
操作部ユニット1903、スキャナユニット1904、マーキングユニット1905、原稿給紙ユニット1906,1907および排紙ユニット1908は、それぞれユニット1902のサブクラスである。
外部インターフェースユニット1940は、ユニット1902のサブクラスであり、外部接続のためのインターフェースユニットを抽象化したクラスである。
画像処理システムネットワークユニット1941、USBユニット1942および通信ユニット1943は、外部インターフェースユニット1940のサブクラスである。
リーダ部1971は、ユニット1902のサブクラスであり、リーダ部113に対応する。
プリンタ部1972は、ユニット1902のサブクラスであり、プリンタ部114に対応する。
装置1970は、ユニット1902のサブクラスであり、画像処理装置110に対応する。
外部ユニット1948は、ユニット1902のサブクラスであり、外部インターフェースユニットなどを介して装置に接続される外部ユニットを抽象化したクラスである。
トランスポート1945は、リソース1901のサブクラスであり、画像処理装置110がネットワークや通信回線などを介して他のノードと通信するための各種の通信経路を抽象化したクラスである。
ネットワークポート1946は、トランスポート1945のサブクラスであり、ネットワークインターフェースによって他のノードのプロセスと通信するための通信経路を抽象化したクラスである。ネットワークポート1946のインスタンスは、たとえばTCP(Transmission Control Protocol)やUDP(User Datagram Protocol)などのプロトコルとプロトコル毎のポート番号とによって特徴付けられる。
通信回線1947は、ファクスなどに用いられる通信回線によって他の装置と通信するための通信経路を抽象化したクラスである。通信回線1947のインスタンスは、たとえば電話交換回線網の回線に割り当てられた回線番号などによって特徴付けられる。
機能1909は、リソース1901のサブクラスであり、画像処理システムが提供する機能を抽象化したクラスである。
コピー機能1910は、機能1909のサブクラスであり紙原稿を紙に複写する機能を示す。さらに、白黒コピー1911とカラーコピー1912は、コピー機能1910のサブクラスである。
送信機能1913は、機能1909のサブクラスであり、デジタル文書データを各種のプロトコルによって送信する機能を示す。さらに、ファクス送信1914、電子メール送信1915、ファイル転送送信1916、ファイル共有送信1917およびデータベース入力送信1918は、送信機能1913のサブクラスであり、デジタル文書データをそれぞれに対応するプロトコルによって送信する機能を示す。
ボックス機能1919は、機能1909のサブクラスであり、原稿から読み取った画像データやPDL展開によって得られた文書データなどをシステム内のストレージに蓄積し、さらに蓄積された文書データの閲覧、プリント、送信、管理などを行う機能を示す。
ボックス格納1950は、ボックス機能1919のサブクラスであり、ボックス機能のうち、特に文書データなどをストレージに蓄積する機能を示す。
ボックス出力1951は、ボックス機能1919のサブクラスであり、ボックス機能のうち、特にストレージに蓄積された文書データを読み出して行うプリントや送信などの機能に相当する。
セキュアプリント1952は、ボックス機能1919のサブクラスであり、ボックス機能のうち、特にクライアントPCから受信したプリントデータをそのままプリントせず、一旦ストレージに蓄積し、ユーザが操作部112から明示的なプリント操作を行ったときにプリントする留め置きプリント機能に相当する。
受信機能1922は、機能1909のサブクラスであり、送信機能1913と同様の各種プロトコルによってデジタル文書データを受信し、その蓄積、転送、プリントなどを行う機能を示す。
スキャン機能1953は、機能1909のサブクラスであり、リーダ部113を用いて原稿画像を読み取り電子的な文書データ化する機能を示す。
プリント機能1954は、機能1909のサブクラスであり、クライアントPCなどから受信したプリントデータをプリンタ部114によってプリント出力する機能を示す。
LIPSプリント1955は、プリント機能1954のサブクラスであり、クライアントPCなどから受信した、公知のLIPS言語のPDLデータを解釈展開し、プリント出力する機能を示す。
PostScriptプリント1956は、プリント機能1954のサブクラスであり、クライアントPCなどから受信した、公知のPostScript言語のPDLデータを解釈展開し、プリント出力する機能を示す。
PCLプリント1957は、プリント機能1954のサブクラスであり、クライアントPCなどから受信した、公知のPCL言語のPDLデータを解釈展開し、プリント出力する機能を示す。
ジョブ1921は、リソース1901のサブクラスであり、機能1909の各種サービスに対応する実際のジョブを抽象化したクラスである。
ジョブリスト1958は、ジョブのインスタンスを複数格納可能なコンテナであり、実行中ジョブリストや中断中ジョブリストなど、一定の種類のジョブの集合を抽象化したクラスである。
履歴1922は、リソース1901のサブクラスであり、ジョブ1921のオブジェクトの実行や終了に関する情報や、システムの動作に伴って生起する各種事象に関する情報を含む、履歴情報のレコードを抽象化したクラスである。
履歴リスト1959は、履歴のインスタンスを複数格納可能なコンテナであり、ジョブ履歴やシステム履歴など、一定の種類の履歴の集合を抽象化したクラスである。
ボックス1923は、リソース1901のサブクラスであり、機能1909によって扱われるファイルシステムの管理単位を抽象化したクラスである。
フォルダ1924は、リソース1901のサブクラスであり、機能1909によって扱われるファイルシステムにおいて、複数のファイルをグルーピングするための管理構造を抽象化したクラスである。
文書1925は、リソース1901のサブクラスであり、機能1909によって扱われるファイルシステムにおける個々のファイル、すなわち各種のデジタル文書を抽象化したクラスである。
アドレス帳1926は、リソース1901のサブクラスであり、システムのユーザとユーザのグループを登録し、また、送信機能1913および受信機能1920などの機能において、アドレス情報を扱うために用いられるアドレスのリストを抽象化したクラスである。
受信転送ルール1927は、受信機能1920において受信文書を転送する際の、転送条件や転送宛先指定や挙動記述などのルール群を抽象化したクラスである。
設定1928は、リソース1901のサブクラスであり、システムの各種の動作を制御する動作パラメータの設定を抽象化したクラスである。さらに、ユーザ設定1929と管理者設定1930は、設定1928のサブクラスであり、それぞれエンドユーザ向けの設定と管理者向けの設定を示す。
暗号鍵・電子証明1960は、リソース1901のサブクラスであり、画像処理装置110が保持管理し、暗号処理、ユーザ認証、クライアント認証、サーバ認証などに用いる各種の電子的な鍵や署名や証明書などのデータを示す。暗号鍵・電子署名1960のインスタンスは、一般にセキュリティー上極度に重要であり、また、ユーザ個人毎に所有されるべき情報も含むため、厳格にアクセス制御されなければならない。
図16は、画像処理装置110が扱う各種資源間の集約(aggregation)関係を表すデータ構造の一例を示すクラス図である。
同図の各クラスは、オブジェクトを生成(インスタンス化)するために用いられる。これらのクラスによって生成されるオブジェクト群は、DOM処理部804内部に保持され、スクリプトインタプリタ805がアクセスする装置オブジェクトモデルを構成する。
画像処理装置110が停止している間も、クラスとクラスとの間の関係は、バイト列にシリアライズされ、HDD304中にファイルとして永続的に記憶される。画像処理装置110の起動時と稼動中、制御ユニット111のCPU301によってこのファイルが読み込まれ、本クラス図に示すクラス群とそのインスタンスであるオブジェクト群が、それぞれ相互関係を保持したデータ構造としてRAM302内に動的に生成され、維持管理される。このデータ構造は、各種資源間の全体‐部分の集約関係を表現している。本実施の形態では、画像処理装置110に関連する各種の資源群を管理する負担を軽減するために、資源間の集約関係を定義する。ユニットとサブユニット(部分ユニット)や、コンテナとコンテンツなど、物理的および概念的に何らかの包含関係が認められ、その関係が資源管理に役立つものであれば導入する。
同図中の各クラスは、それぞれ図15中の対応するクラスと同一である。対応するクラスには同一符号を付し、その詳細な説明は省略する。
装置1970は、便宜上、画像処理装置110の全体を表している。リーダ部1971は、装置1970の部分である。原稿給紙ユニット1906とスキャナユニット1904は、リーダ部1971の部分である。
操作部ユニット1903は、装置1970の部分である。
プリンタ部1972は、装置1970の部分である。給紙ユニット1907、マーキングユニット1905および排紙ユニット1908は、装置1970の部分である。
ネットワークユニット1941は、装置1970の部分である。ネットワークポート1946は、ネットワークユニット1941の部分である。
通信ユニット1943は、装置1970の部分である。通信回線1947は、通信ユニット1943の部分である。
USBユニット1942は、装置1970の部分である。外部ユニットは1948の部分である。
ボックス1923は、装置1970の部分である。フォルダ1924は、ボックス1923の部分である。文書1925は、フォルダ1924の部分である。
ジョブリスト1958は、装置1970の部分である。ジョブ1921は、ジョブリスト1958の部分である。
履歴リスト1959は、装置1970の部分である。履歴1922は、履歴リスト1959の部分である。
図17は、装置オブジェクトモデルのインスタンスを構成するオブジェクトの一部を示す図である。
同図において、各四角は、オブジェクト、すなわち各クラスのインスタンスを示す。各オブジェクトの近傍に付した番号は、そのオブジェクトに対応するクラスの符号を表している。
装置オブジェクトモデルを構成するオブジェクトは、そのクラスが備える特性、すなわち属性や操作を持っている。オブジェクトのクラスに定義された特性に加えて、抽象‐具体関係の親クラスの特性も継承によって持っている。たとえば、Deviceクラスのオブジェクトdeviceは、装置クラス1970に定義された特性と、その抽象クラスであるユニットクラス1902と、さらにその抽象クラスであるリソースクラス1901の特性を持っている。また、リソースクラスのさらに抽象クラスである、DOMのElementクラスやNodeクラス(不図示)および、Java(登録商標)Scriptの継承関係の最上位に位置するObjectクラス(不図示)からも特性を継承している。各オブジェクトは、その属性によってその部分オブジェクトを参照している。たとえばdeviceオブジェクトは、属性printerを持ち、この属性はプリンタ部クラス1972のインスタンスを参照する。
deviceオブジェクトは、装置クラス1970のインスタンスであり、以下の特性を持つ。
属性serialは、シリアル番号を表す。属性venderは、ベンダを表す。属性modelは、モデルを表す。以上は、ユニットクラス1902から継承した属性の一部である。
属性firstChildは、全体‐部分関係の子にあたる最初のオブジェクトを参照する。以上は、DOMのNodeクラスから継承した属性の一部である。
属性printerは、このオブジェクトの全体‐部分の子にあたるプリンタ部クラス1972のインスタンスを参照する。属性readerは、このオブジェクトの全体‐部分の子にあたるリーダ部クラス1971のインスタンスを参照する。属性communicationは、このオブジェクトの全体‐部分の子にあたる通信ユニットクラス1943のインスタンスを参照する。属性logは、このオブジェクトの全体‐部分の子にあたるログリストクラス1959のインスタンスを参照する。以上は、装置クラス1970で定義された属性の一部である。
操作diagは、画像処理装置110の自己診断を行う。以上は、ユニットクラス1902から継承した操作の一部である。
操作getNumberOfJobsは、画像処理装置110全体で実行中のジョブ数を返す。操作getCurrentUserは、装置を利用中のユーザを表すオブジェクトを返す。以上は、装置クラス1970で定義された操作の一部である。
操作getElementByIdは、このオブジェクトの全体‐部分関係の子にあたるオブジェクト群の中からidで指定したIDを持つオブジェクトを検索してその参照を返す。操作getElementsByTagNameは、このオブジェクトの全体‐部分関係の子にあたるオブジェクト群の中からnameで指定した名前を持つオブジェクト群を検索してそれらの参照のリストを返す。以上は、DOMのNodeクラスから継承した操作の一例である。
プリンタ部クラス1972のインスタンスであるオブジェクトは、以下の特性を持つ。
属性serial,vender,model,version,firstChildは、deviceオブジェクトと同様である。属性isOnlineは、プリンタ部114がオンラインであるとき真値になる述語である。属性finisherは、このオブジェクトの全体‐部分の子にあたる排紙ユニットクラス1908のインスタンスを参照する。属性paperSupplyは、このユニットの全体‐部分の子にあたる給紙ユニットクラス1907のインスタンスを参照する。属性markingは、このユニットの全体‐部分の子にあたるマーキングクラス1905のインスタンスを参照する。以上の属性は、プリンタ部クラス1972で定義された属性の一部である。
操作diag,getElementById,getElementsByTagNameは、deviceオブジェクトと同様である。操作getNumberOfJobsは、プリンタ部114で実行中のジョブ数を返す。操作getTotalCounterは、プリンタ部114でプリントした積算プリント数を返す。操作getTonerは、プリンタ部114が保持するトナー残量を返す。操作setOnlineは、プリンタ部114をオンライン状態にする。操作setOfflineは、プリンタ部114をオフライン状態にする。
図18は、組み込みWebブラウザに組み込まれたJava(登録商標)Scriptインタプリタがスクリプトの動作環境として提供するクライアントサイドオブジェクトの全体‐部分階層構造の一例を示す図である。
クライアントサイドのJava(登録商標)Scriptオブジェクトの全体‐部分階層において、最上位に位置するのは、Windowオブジェクトである。ブラウザのドキュメントを表示するウィンドウ(フレーム)に対応するオブジェクトが、Windowオブジェクトである。クライアントサイドのオブジェクトは、すべてWindowオブジェクトから参照されている。Windowオブジェクトは、言語処理系のスコープチェーンの先頭につながれているグローバルオブジェクトである。Windowオブジェクトは、属性documentや属性locationを備えている。属性documentは、対応するウィンドウに関連付けられたDocumentオブジェクトを参照する。属性locationは、対応するウィンドウに関連付けられたLocationオブジェクトを参照する。Windowオブジェクトは、他にも、属性frames[ ]も持つ。属性frames[ ]を利用すれば、元のウィンドウを構成する各フレームに対応するWindowオブジェクトを参照できる。たとえば、属性documentは、現在のウィンドウのDocumentオブジェクトを参照し、frames[1].documentは、現在のウィンドウの2番目の子フレームのDocumentオブジェクトを参照する。現在のウィンドウまたはそのほかのWindowオブジェクトから参照されるオブジェクトが自分以外のオブジェクトを参照することもできる。たとえば、Documentオブジェクトのforms[ ]配列を利用すると、文書中に表示する複数のHTMLフォームに対応するFormオブジェクトを参照できる。これらのフォームのうち、どれか1つを参照するためには、self.document.forms[0]のように記述する。
本実施の形態のWebブラウザでは、このオブジェクト階層の中に装置オブジェクトモデルを位置づけている。Windowオブジェクトの属性deviceは、装置オブジェクトのインスタンス(図17のdeviceオブジェクト)を参照している。
以上のように構成された画像処理装置110が実行する制御動作を説明する。
図19および図20は、Webブラウザによってサーバから取得される文書の一例を示す図である。
同図の文書は、Java(登録商標)Scriptのコードが埋め込まれたHTML文書である。この文書をWebブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Webブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。たとえば、図21および図22は、動的に適応した文書のWebブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。
図19の行7では、deviceオブジェクトのgetCurrentUser操作によって現在装置を利用中のユーザオブジェクトを取得し、そのname属性を読み出している。この結果、装置を利用中のユーザの名前(表示例では「山田太郎」)を文書に挿入している。
行9では、deviceオブジェクトのmodel属性によって装置のモデル名を読み出し、それ(表示例では「MFP3200」)を文書に挿入している。
行12〜行33では、装置を構成するサブユニット毎にそれらの実際の装着状況に応じて、その固有の装置にとって有益な情報を選択的に挿入している。
行13では、deviceオブジェクトからreaderオブジェクトをたどり、readerオブジェクトのmodel属性を読み出して、装置を構成するリーダ部のモデルが「S500」と等しいか否かを判定している。もし等しければ、行14でさらにreaderオブジェクトからfeederオブジェクトをたどり、そのmodel属性を読み出して、リーダ部113に装着された原稿給紙ユニットのモデルが「DF03」と等しいか否かを判定している。もし等しければ、行15〜行21で、この特定の原稿給紙ユニットに固有の関連情報を文書に挿入している。また、挿入する情報には、さらに詳細な情報源へのリンクが埋め込まれているが、行19と行20で、このリンクのURLも、device.reader.modelによって読み出した原稿給紙ユニットのモデルに応じて最適なURLを動的に生成し、最適なページへと誘導している。表示例の装置は、このモデルのリーダ部で構成され、かつ原稿給紙ユニットが装着されているため、下取りキャンペーンを紹介する情報が挿入されている。
行24〜行32では、装置を構成するプリンタ部のモデルが「P9900」である場合の処理を記述している。表示例の装置は、このモデルのプリンタ部で構成されないため、表示例ではこの部分の情報は挿入されていない。
図20の行35〜行56では、サーバ側が把握している、リリースされたファームウェアの最新バージョンと、実際の装置に組み込まれているファームウェアのバージョンとを比較し、もし古いバージョンが組み込まれたままであればカスタマーエンジニアによるアップグレード作業の手配を推奨する情報を選択的に文書に挿入している。
行35では、サブユニット毎にリリースされた最新ファームウェアのバージョンを格納するための配列latestsを生成している。
行36〜行41では、操作部ユニット、プリンタ部、リーダ部、ネットワークユニット、通信ユニットおよびUSBユニットのそれぞれのユニットについて、最新バージョンを表すversion属性と表示用のラベルを表すlabel属性を格納したオブジェクトを生成し、配列latestsにオブジェクト名をキーにした連想配列として格納している。
行42〜行55では、配列latestsの全要素のそれぞれに関して繰り返すループを構成している。
行42では、配列latestsのある要素のキーを変数unitで指し示している。
行43では、device[unit]という連想配列表記によってdeviceオブジェクトの属性にアクセスしている。たとえば、unitの値が文字列‘operationPanel’とすると、device[unit]は、device[“operationPanel”]を意味する。Java(登録商標)Scriptでは、これはドット表記したdevice.operationPanelと同じ意味である。したがって、deviceオブジェクトのoperationPanel属性(プロパティ)に対するアクセスを意味する。これはすなわち、装置オブジェクトを構成する操作部ユニットオブジェクトである。この行では、device[unit]、すなわちあるユニットのオブジェクトがそのシステムの実際の装置オブジェクトモデルにおいて、未定義でもnull値でもなく、かつ、device[unit].version、すなわちそのユニットのオブジェクトのバージョンがlatests[unit].version、すなわち行36〜行41で配列に格納したそのユニット用ファームウェアの最新バージョンよりも小さい値であるか否かを判定している。この条件を満たした場合は、そのユニットの稼働中のファームウェアがリリースされている最新版よりも古いことを意味し、この場合は、行44〜行54で、カスタマーエンジニアによるファームウェアのバージョンアップ(ROM交換など)の申請を促す情報を文書に挿入する。挿入する情報の中には、mailto:疑似プロトコルによるURLを参照するアンカーが埋め込まれている。図21の表示において、このアンカーは、「サポートセンターにemailでお申し込み」のハイパーテキストとして表示されている。ユーザがこのハイパーテキストをポイントすると、Webブラウザから電子メールクライアント機能が呼び出される。URLには、宛先アドレスsupport@canon.jpに加えて、subjectとbodyが符号化されているため、電子メールクライアント機能に宛先アドレスと題名と本文の初期値が引き渡される。
図23は、このようにして起動した電子メールクライアントの画面例である。図示例では、コンテンツ提供者が指定した宛先アドレスが設定されている。また、実際の装置オブジェクトから取得したモデル名と装置のシリアル番号を含む題名が設定されている。さらに、より新しいバージョンのファームウェアが存在するサブユニットに関して、実際の装置オブジェクトから取得したサブユニットのモデル名とそのユニットに現在組み込まれているファームウェアのバージョンとが本文に設定されている。
図20に戻り、行59〜行67では、稼働中の組み込み装置のその時点での消耗品残量を確認して、もし残量が少なければ、消耗品の発注を促し、オンライン発注ページへのリンクを表示するためのデータを文書に挿入している。
行59では、操作device.printer.getToner()によって、装置オブジェクトを構成するプリンタ部オブジェクトのgetToner()メソッドを呼び出すことで、トナー残量の割合を得ている。
行60では、トナー残量が10%未満であるか否かを判定し、10%未満であれば文書への挿入を行う。
行61では、文書に挿入するURLを生成しているが、ここで属性device.printer.modelを読み出してURLに埋め込むことによって、ユーザが利用しているモデルに適合したトナーのオンライン販売ページに直接リンクしたURLを生成することができる。
行62および行63では、トナーの残量が少ないことの注意を促し、適合するトナーのオンライン販売ページに誘導するハイパーテキストを含むメッセージを文書に挿入している。
トナー残量が10%以上ある場合は、図21の表示例のようにこのメッセージは文書に含まれず、10%未満の場合は、図22の表示例のようにこのメッセージが文書に挿入される。
行71では、サーバ側が提供する最新マニュアルへのリンクを生成している。device.model属性の値を読み出し、これを埋め込んだURLを生成し参照しているため、ユーザがこのリンクをたどると、利用中の装置に適合したマニュアルに直接到達できる。
図21は、動的に適応した文書のWebブラウザ上での表示例であり、Webブラウザの前記コンテンツ表示領域905上での表示例を示している。
コンテンツの文書に記述されたメッセージ5001の中には、スクリプトによって装置オブジェクトモデルから取得した、画像処理装置110を現在利用中のユーザ名(山田太郎)を挿入している。
コンテンツの文書に記述されたメッセージ5002の中には、スクリプトによって装置オブジェクトモデルから取得した、装置のモデル名(MFP3200)を挿入している。
パラグラフ5003では、スクリプトによって装置オブジェクトモデルから取得した、リーダ部113のモデルと原稿給紙ユニットのモデルとが情報提供の条件に合致しているかどうかを判定した結果、合致していたために、パラグラフ5003が文書に挿入されている。また、このパラグラフ5003に含まれるアンカーのURLは、装置オブジェクトモデルから取得した、原稿給紙ユニットのモデル名を含んでいるため、下線のリンクをユーザが選択すると当該ユニットの下取りキャンペーンページに直接遷移できる。
パラグラフ5004では、スクリプトによって、コンテンツに記述したサブユニット群の最新ファームウェアのバージョンと、装置オブジェクトモデルから取得した実際に稼働中のサブユニット群のファームウェアのバージョンとを比較し、アップブレード可能なサブユニットが存在したために、パラグラフ5004が文書に挿入されている。また、このパラグラフ5004に含まれるリンクは、メール送信を行うためのURLを含んでいる。URL中には、コンテンツに記述された宛先アドレスに加えて、装置オブジェクトモデルから取得した装置のモデル、シリアル番号、アップグレード作業対象のユニット名、現在利用中のファームウェアバージョンの各情報を符号化してあるため、ユーザが下線のリンクを選択すると自動的にサポートセンターに必要な情報を伝える電子メールを生成することができる。
リンク5005は、サーバに置かれた最新マニュアルページへのリンクである。このアンカーのURLには、コンテンツに記述された最新マニュアルのパスとともに装置オブジェクトモデルから取得した装置のモデル名の情報が符号化されているため、下線のリンクをユーザが選択すると、当該組み込み装置専用のマニュアルページに直接遷移できる。
図22は、動的に適応した文書のWebブラウザ上での別の表示例であり、Webブラウザのコンテンツ表示領域905上での表示例を示している。この表示は、図21を表示した同じ組み込み装置において、異なるタイミングで同じコンテンツを取得し表示した例を示している。
パラグラフ5101では、スクリプトが装置オブジェクトモデルのトナー残量取得操作を呼び出して取得した、その時点におけるトナー残量が、コンテンツのスクリプトに定義された規定の値(10%)未満であるか否かを判定し、その結果、規定値未満であったために文書に挿入されている。このパラグラフ5101のメッセージには、スクリプトが装置オブジェクトモデルのトナー残量取得操作を呼び出して得た、その時点におけるトナー残量の値(8%)も、埋め込んで表示している。
図23は、スクリプト処理によって動的に生成したURLに応じて起動した電子メール送信機能の画面例であり、電子メール送信画面は、前記操作部112に表示される。
同図において、宛先アドレス5201には、コンテンツ提供者が指定した宛先アドレスが設定されている。題名5202には、実際の装置オブジェクトから取得したモデル名と装置のシリアル番号を含む題名が設定されている。本文5203には、より新しいバージョンのファームウェアが存在するサブユニットに関して、実際の装置オブジェクトから取得したサブユニットのモデル名とそのユニットに現在組み込まれているファームウェアのバージョンとが設定されている。
カスタマーエンジニアの出動を手配するために必要な情報が自動的に設定されているため、ユーザはこのまま電子メールを送信することもできるし、もし望むならメッセージを書き加えてから送信することもできる。
ボタン5204は、キャンセルボタンであり、送信を行わずに電子メール送信画面を閉じるときに使用する。
ボタン5205は、送信ボタンであり、電子メールの送信を行うときに使用する。
このように、本実施の形態の画像処理装置によれば、以下の効果が得られる。
すなわち、サービスを提供するサーバ側に単一のコンテンツを準備するだけで、システムの構成や状態に応じて適切な情報を選択的に提示する文書を提供することが可能となる。タイムリーな情報は、サーバ側コンテンツを更新し、ユーザが利用している固有の組み込み装置への適合は、Java(登録商標)Scriptのクライアントサイド処理によってHTMLの断片を生成してコンテンツ文書に挿入し、これらの組み合わせによって柔軟にきめの細かいサービスを提供することができる。たとえば、Webページコンテンツのパーソナライズ、装置の構成や動的な状態に応じた最適な提案に利用できる。また、動的に生成するURLに装置の構成や状態を反映することによって、情報提示やオンライン販売などのWebページの中からその装置にとって最適なページに直接遷移するためのリンクを表示するために利用できる(これまでは、必ずしも最適でない選択肢も並んだインデクス的ページへのリンクを表示することしかできず、ユーザにその中から最適な選択肢を選んでもらう手間がかかっていた)。また、URLの生成によってサポートセンターへ送信する電子メールのひな形を提供するためにも利用できる。これらはすべて、たとえばCRM(Customer Relationship Management)のためにも有益である。
(第2の実施の形態)
次に、本実施の第2の形態に係る画像処理装置について説明する。
本実施の形態の画像処理装置は、上記第1の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて上記第1の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。
図24〜図26は、Webブラウザによってサーバから取得される文書の一例を示す図である。
同図の文書は、Java(登録商標)Scriptのコードが埋め込まれたHTML文書である。この文書をWebブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Webブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。図27は、動的に適応した文書のWebブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。
図24の行18〜行26では、オプションユニットである、排紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、排紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。排紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.finisher属性に“null”以外の値がセットされている(つまりFinisherUnitクラスのオブジェクトを参照している)か否かによって判定している。なお、アンカーの内容は、そのユニット当該モデルの画像(HTMLのIMG要素)によって表示している(図27の領域5301)。未装着の場合は、半透明のユニットに「未装着」の文字を重ねた画像によって表示する。
行31〜行38では、同様に、オプションユニットである、原稿給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、原稿給紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。原稿給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.reader.feeder属性に“null”以外の値がセットされている(つまりDocumentFeederUnitクラスのオブジェクトを参照している)か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデルの画像(HTMLのIMG要素)によって表示している(図27の領域5302)。未装着の場合は、半透明のユニットに「未装着」の文字を重ねた画像によって表示する。
図25の行43〜行52では、同様に、オプションユニットである、給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、給紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.paperSupply属性に“null”以外の値がセットされている(つまりPaperSupplyUnitクラスのオブジェクトを参照している)か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデルの画像(HTMLのIMG要素)によって表示している。未装着の場合は半透明のユニットに「未装着」の文字を重ねた画像によって表示する(図27の領域5305)。
行59および行60では、リーダ部113のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデルの画像によって表示している(図27の領域5303)。
行67および行68では、プリンタ部114のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデルの画像によって表示している(図27の領域5304)。
図26の行78および行79では、リーダ部113のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きのテキストによって表示している(図27の文字列5306)。
行83〜行86では、オプションユニットである、原稿給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示している。原稿給紙ユニットの装着状況は、装置オブジェクトモデルのdevice.reader.feeder属性に“null”以外の値がセットされている(つまりDocumentFeederUnitクラスのオブジェクトを参照している)か否かによって判定している。なお、アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示している(図27の文字列5307)。
行90および行91では、プリンタ部114のモデルに応じたマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示している(図27の文字列5308)。
行95〜行99では、オプションユニットである、給紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示している。アンカーの内容は、そのユニットの当該モデル名を含む箇条書きテキストによって表示する。図27の表示例では、給紙ユニットが未装着であるため、このリンクの挿入は行われない。
行102〜行106では、オプションユニットである、排紙ユニットの装着状況を判定し、装着されていれば、そのユニットに関するマニュアルを直接表示するためのリンクを表示し、装着されていなければ、排紙ユニットを発注するためのページへのリンクを表示するための文書を挿入している。排紙ユニットの装着状況は、装置オブジェクトモデルのdevice.printer.finisher属性に“null”以外の値がセットされている(つまりFinisherUnitクラスのオブジェクトを参照している)か否かによって判定している。なお、アンカーの内容は、そのユニット当該モデル名を含む箇条書きテキストによって表示している(図27の文字列5309)。
図27は、動的に適応したマニュアル文書のWebブラウザ上での表示例であり、Webブラウザのコンテンツ表示領域905上での表示例を示している。同図の説明は、図23〜図26の説明の中で併せて行っているので、省略する。
本実施の形態では、スクリプトのアルゴリズムによって、ユニットのモデルとオプションユニットの装着状況に応じて動的に文書の内容を切り替えるように構成したが、さらに動的な状態に応じた切り替えを行い、装置に発生しているエラーに応じて、そのエラーから回復するための手順を解説するマニュアルを表示することもできる。また、スクリプトのアルゴリズムによって、特定の装置のユーザによる利用パターンを、装置に記憶されている統計情報から解析し、その利用パターンにとって最適な「使いこなし」のガイドを表示するように構成することもできる。
本実施の形態の画像処理装置によれば、以下の効果が得られる。
すなわち、サービスを提供するサーバ側に単一のコンテンツを準備するだけで、システムを構成するユニットのモデルやオプションユニットの装着状態に応じて適切な情報を動的に提示する文書を提供することが可能となる。これにより、たとえば、組み込みブラウザによってブラウズしている、まさにその装置の状態にとって最適化した電子マニュアルなどを提供するために利用できる。
(第3の実施の形態)
次に、本実施の第3の形態に係る画像処理装置について説明する。
本実施の形態の画像処理装置は、前記第1の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて前記第1の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。
図28および図29は、Webブラウザによってサーバから取得される文書の一例を示す図である。
同図の文書は、Java(登録商標)Scriptのコードが埋め込まれたHTML文書である。この文書をWebブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Webブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成されて表示される。図30は、動的に適応した文書のWebブラウザ上での表示例である。
また、スクリプトインタプリタにロードされたスクリプトには、Webブラウザ上に表示されている文書の要素に対するユーザの入力操作によって生起するDOMイベントや、タイマーイベントなどに呼応するイベントハンドラスクリプトが含まれており、これらのイベントハンドラは、Webブラウザに文書が表示された後、各種のイベントに応じて実行される。イベントハンドラは、装置オブジェクトモデルに対する操作によって装置制御を行い、また、DOMに対する操作によってHTML文書の取得時に解釈され表示された文書の表示後の変更なども行う。
図31および図32は、文書取得時の表示完了後にあらためて動的に変更された文書のWebブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。
図28の行5〜行29では、関数diagを定義している。関数diagは、引数として各ユニットオブジェクトの参照unitを受け取り、そのユニットの自己診断コードを実行し、さらに、実行結果に基づいて既にWebブラウザに表示されている文書の編集を行う。
行6では、参照を与えられたunitオブジェクトにおいて定義された自己診断メソッドである操作diagを呼び出す(行5で定義しているdiag(unit)とは異なることに注意)。そして、診断結果として返される整数値をdiagResultに得ている。診断結果は“0”であれば正常であり、それ以外の数値はエラーコードを意味する。
行7では、DOMの操作によって、このHTML文書自身が持つ、diagDivというIDがつけられたDIV要素を検索し、その参照diagDivを得ている。
行8では、見つけたdiagDivに含まれる最初のP要素を検索し、その参照oldPを得ている。
行9では、新たにP要素を生成し、その参照pを得ている。
行10では、行6で実行した診断の結果diagResultが正常であるか否かを判定し、正常であれば行11および行12を、異常であれば行15〜行26を実行する。
診断コードが正常に終了した場合、行11では、「診断:正常です。」という文字列からなるDOMのテキストノードを生成している。
行12では、生成したテキストノードを、行9において生成したP要素の最初の子供として追加している。これにより、pのテキストに「診断:正常です。」の文字列が設定される。その後、行28に進む。
一方、診断コードが異常となった場合、行15では、診断結果のエラーコードdiagResultを埋め込んだ、障害サポートサイトのURLを構築する。
行16では、診断エラーコードdiagResultを含み、異常を通告するメッセージの文字列からなるDOMのテキストノードを生成している。もしエラーコードが“199”であれば、文字列は「診断:異常が検出されました。エラーコードは#199です。より詳細な情報は」となる。
行19では、生成したテキストノードを、行9において生成したP要素の最初の子供として追加している。
行20では、新たにA要素を生成してその参照aを得ている。
行21では、生成したA要素であるaにHREF属性を設定している。HREF属性の値は、行15で構築した障害サポートサイトのURLである。
行22では、同じURL文字列からなるDOMのテキストノードを生成している。
行23では、生成したテキストノードを、行20で生成したA要素aの最初の子供として追加している。これによって、Webブラウザに表示されるリンクの、ユーザに見える文字列が、障害サポートサイトのURLとなる。
行24では、HREF属性とテキストノードを設定し終わったA要素aを、pの2番目の子供として追加している。
行25では、「をご参照下さい。」という文字列からなるDOMのテキストノードを生成している。
行26では、生成したテキストノードを、pの3番目の子供として追加している。
行28では、diagDivの最初のP要素を、これまで表示されていたoldPから新たに生成し構築したpに交換している。
関数diagは、図29の行59〜行76のスクリプトから利用されている。
行59では、device.printer.diagが未定義でも“null”でもないことを確認、すなわちプリンタ部の自己診断コードが登録されていることを確認している。登録されていれば、行60では、「プリンタ」とラベルがつけられて、クリックイベントのイベントハンドラとして、プリンタ部オブジェクトを引数とした関数diagの呼び出しを登録したFORMのボタンを、HTML文書に挿入している。こうして、プリンタ部オブジェクトの自己診断コードを呼び出すためのボタンが表示される。
同様にして、行62〜行65で、もし自己診断コードが提供されていれば、排紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。
同様にして、行66〜行69で、もし自己診断コードが提供されていれば、給紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。
同様にして、行70および行71で、もし自己診断コードが提供されていれば、リーダ部オブジェクトの自己診断を呼び出すためのボタンが表示される。
同様にして、行73〜行76で、もし自己診断コードが提供されていれば、原稿給紙ユニットオブジェクトの自己診断を呼び出すためのボタンが表示される。
このスクリプトは、HTML文書の取得直後の解釈時に実行されるため、ボタンは、Webブラウザに最初に表示されるページに表示される。ある特定の組み込み装置においてプリンタ部とリーダ部の診断コードが提供されている場合、図30の表示例のように、プリンタとリーダのための各ボタン5401および5402が表示される。
診断コードの実行は、表示されたボタンをユーザがクリック(タッチパネルなのでタッチ)したタイミングで、イベントハンドラとして登録された関数diagによって実行される。たとえば、ユーザが「プリンタ」と書かれたボタン5401をタッチし、診断が終わり、異常が検出された場合、図31の表示例の文5501のように、表示中の文書の一部を変更して(別の文書を再読み込みしているわけではないことに注意)、ユーザに異常を伝えるメッセージが標示される。
図28の行32〜行41では、関数showPrinterStatusを定義している。
行33および行34では、この文書内のstatusDivというIDをつけられたDIV要素を検索し、その要素に含まれる最初のP要素の参照pを得ている。
行35では、プリンタ部オブジェクトの要素isOnlineを読み出し、isOnlineの値が「真」の場合には、行36でpの最初の子供(つまりテキストノード)のdata属性に「オンラインです。」の文字列を設定し、isOnlineの値が「偽」の場合には、行39で「オフラインです。」の文字列を設定している。
関数showPrinterStatus()は、図29の行52のHTMLから利用されている。
行52では、BODY要素のonLoadイベントに対するイベントハンドラとしてスクリプトを登録している。onLoadイベントハンドラは、文書を構成するすべてのデータのロード(展開、表示)が完了したタイミングで呼び出される。ハンドラでは、setIntervalによって、一定間隔で繰り返し生起するタイマーイベントハンドラの登録を行っている。この登録が行われると、10,000ミリ秒間隔で関数showPrinterStatusが呼び出されることになる。
Webブラウザが文書を表示した直後の状態では、図30の表示例に示すように、statusDivには当初のHTML文書として記述されたまま(行81)の文字列「状態取得中…」5403が表示されている。
約10秒ほど経過すると、図32の表示例の文字列5601のように、装置オブジェクトモデルから取得した装置の状態をユーザに提示し、その後この文書がブラウザに表示されている間は、10秒間隔でその時点での状態表示を更新しつづける。
図28の行44〜行48では、関数errorHandlerを定義している。関数errorHandlerは、引数eventを受け取る。
行45および行46では、この文書内のstatusDivというIDをつけられたDIV要素を検索し、その要素に含まれる最初のP要素の参照pを得ている。
行47では、pの最初の子供(つまりテキストノード)のdata属性に、引数として受け取ったeventオブジェクトの属性unitと「:」とeventオブジェクトの属性messageをつないだ文字列を設定している。
関数errorHandlerは、行49から利用されている。装置オブジェクトのエラーイベントを処理するためには、deviceオブジェクトのonerror属性にイベントハンドラ関数を登録すればよい。装置オブジェクトモデルは、装置制御とインターフェースして、装置制御に何らかのエラーが生じると、device.onerrorに登録された関数を呼び出す。その際、引数に渡すオブジェクトeventは、エラーに関連するユニットオブジェクトの参照unitやエラーを説明する文字列messageなどの属性を持つ。
図30は、動的に適応した装置管理文書のWebブラウザ上での表示例であり、Webブラウザのコンテンツ表示領域905上での表示例を示している。
図31は、文書取得時の表示完了後にあらためて動的に変更した装置管理文書のWebブラウザ上での表示例であり、Webブラウザのコンテンツ表示領域905上での表示例を示している。
図32は、文書取得時の表示完了後にあらためて動的に変更した装置管理文書のWebブラウザ上での他の表示例であり、Webブラウザのコンテンツ表示領域905上での表示例を示している。
本実施の形態の画像処理装置によれば、以下の効果が得られる。
すなわち、スクリプトがDOMを操作することで、文書解析時の挿入だけでなく、さらに動的な文書の編集ができる。
装置オブジェクトモデルのインターフェースを介して、スクリプトから装置やジョブを制御できる。
DOMイベントに呼応して装置オブジェクトモデルを操作するイベントハンドラを登録できる。ユーザからの入力やタイマーなどのイベントに応じて装置制御にアクセスすることができる。
装置オブジェクトモデルからのイベントを、DOMイベントを処理するのと同様にハンドリングできる。
HTML文書に組み込まれたスクリプトによってDOMと装置オブジェクトモデルに対する操作を組み合わせることで、装置制御を行うユーザインターフェースをHTMLとスクリプトにより記述することができる。HTMLのユーザインターフェース記述言語としての側面をサーバ側で動作するWebアプリケーションのユーザインターフェースだけでなく、クライアントサイドの装置サービスのユーザインターフェースを提供するためにも利用できる。ユーザインターフェース記述は、サーバ側のコンテンツとして準備し、装置のブラウザからの取得要求に応えて取得されるため、サービス提供者側で最新のコンテンツを提供できる。
これにより、たとえば、カスタマーエンジニアやユーザによる組み込み装置のメンテナンスを助けるために有効である。
(第4の実施の形態)
次に、本実施の第4の形態に係る画像処理装置について説明する。
本実施の形態の画像処理装置は、前記第1の実施の形態の画像処理装置に対して、サーバから取得する文書の内容が異なるのみであるので、本実施の形態の画像処理装置を含むシステムのハードウェア構成およびソフトウェア構成は、すべて前記第1の実施の形態の画像処理装置を含むシステムのそれをそのまま使うことにする。
図33および図34は、Webブラウザによってサーバから取得される文書の一例を示す図である。
同図の文書は、Java(登録商標)Scriptのコードが埋め込まれたHTML文書である。この文書をWebブラウザが解釈する際に、埋め込まれたスクリプトがスクリプトインタプリタにロードされて実行され、その結果として、当該Webブラウザが組み込まれた特定の組み込み装置に動的に適応した文書が、クライアントサイド処理で生成され表示される。
また、スクリプトインタプリタにロードされたスクリプトには、Webブラウザ上に表示されている文書の要素に対するユーザの入力操作によって生起するDOMイベントやタイマーイベントなどに呼応するイベントハンドラスクリプトが含まれており、これらのイベントハンドラは、Webブラウザに文書が表示された後で、各種のイベントに応じて実行される。イベントハンドラは装置オブジェクトモデルに対する操作によって装置制御を行い、また、DOMに対する操作によってHTML文書の取得時に解釈されて表示された文書の表示後の変更なども行う。
図35は、本文書のWebブラウザ上での表示例である。表示例と対応させながら、文書に埋め込まれたスクリプト部分を中心に文書の内容を説明する。
図33の行5〜行7では、関数createCounterReport()を定義している。
行6では、プリンタ部114が積算するプリントトータルカウンタの現在値を取得するために、device.printer.getTotalCounter()を呼び出し、それを、この文書に含まれるFORMのテキスト入力要素counterに書き込む。テキスト入力要素counterは、図34の行31に記述されている。
図33の行8〜行10では、関数reportLog()を定義している。この関数は、引数messageを受け取る。
行9では、引数に渡されたmessageを、この文書に含まれるFORMのテキスト領域要素logに追記して改行する。テキスト領域要素logは、図34の行36に記述されている。
図33の行11〜行19では、関数createLogReport()を定義している。
行12では、テキスト領域要素logの内容をクリアする。
行13では、DOMと同様のAPIを用いて装置オブジェクトモデルにアクセスすることで、ログリストクラス1959のオブジェクトを検索する。ログリストオブジェクトは複数存在し得るが、ここでは1番目のログリストオブジェクトへの参照をlogとして得る。
行14では、DOMと同様のAPIを用いて装置オブジェクトモデルにアクセスすることで、ログリストオブジェクトlogの全体‐部分関係の子にあたるノードの中からタグ名が“record” であるオブジェクト群を検索してそのリストへの参照をrecordsとして得る。
行15〜行21では、ループを構成し、recordsに含まれる各オブジェクトに対して、以下の処理を繰り返す。すなわち、行16では、recordsに含まれる1つのオブジェクトを選択してrecordとして参照し、行17と行18では、DOMのAPIであるrecord.getAttribute()によって、このレコードオブジェクトが持つDOM属性を調べる。もし属性facilityの値が “system” であり、かつ、属性levelの値が “notice” であれば、行19で、このオブジェクトレコードの属性dateの値と、「:」と、このオブジェクトレコードの最初の子のdata属性とを結合した文字列を構築する。そして引数に構築した文字列を渡して関数reportLog()を呼び出す。
関数createCounterReport()とcreateLogReport()は、図34の行25と行42のHTMLから利用されている。
行25では、BODY要素のonLoadイベントに対するイベントハンドラとしてスクリプトを登録している。onLoadイベントハンドラは、文書を構成するすべてのデータのロード(展開、表示)が完了したタイミングで呼び出される。ハンドラでは、まずcreateCounterReport()の呼び出しを行い、ついでcreateLogReport()を呼び出している。また、行42では、「更新」とラベル付けされたボタン入力要素updateButtonのonClickイベントに呼応するイベントハンドラとしてスクリプトを登録している。こちらのハンドラもまったく同様に、まずcreateCounterReport()の呼び出しを行い、ついでcreateLogReport()を呼び出している。
Webブラウザが文書を表示した直後の状態では、onLoadイベントハンドラスクリプトの処理よって、プリンタ部114のトータルカウント値がテキスト入力要素counter(「カウンタ」)に入力され、system関連でかつnoticeレベルのログレコードオブジェクトのタイムスタンプとメッセージがテキスト領域要素log(「ログ」)に入力されている。したがって、図36のような表示が得られる。その後、ユーザが「更新」ボタンを押すたびに、そのボタンのonClickイベントハンドラによってカウンタとログの各フィールドの内容表示が更新される。
この文書例では、さらに行43において、HTMLのFORMを送信するためのsubmit型の入力要素を記述している。この入力要素は、図35の表示例において「送信」とラベル付けされたボタンに対応する。ユーザが「送信」ボタンを押すと、「カウンタ」ならびに「ログ」の内容がサーバ側にサブミットされる。すなわち、スクリプトが装置オブジェクトモデルにアクセスして得た結果を、FORMを介してサーバ側に引き渡すことができる。これにより、サーバサイド処理とクライアントサイド処理を連携させることが可能となり、DOMと装置オブジェクトモデルを組み合わせたスクリプトによる課題解決の機会が広がる。
ただし、その一方で、ユーザは組み込み装置内部に保持されている情報がやみくもに外部ネットワークに流出することを恐れる場合がある。さらに、ユーザがサブミットボタンを押さなかったとしても、スクリプトからボタンが押されたのと同じ状態を作り出す方法も存在する。したがって、組み込み装置のユーザ環境や運用形態によってはプライバシーの問題が一段と危惧される可能性がある。
そこで、スクリプトが装置オブジェクトモデルのいずれかに一度でもアクセスした場合、そのスクリプトが埋め込まれた文書に含まれるFORMからのサブミットが指示されたときに、本当に送信処理を実行してもよいかユーザに確認する。図36は、この確認ダイアログを示す。FORMのサブミット指示は、HTML文書のDOMイベントであり、DOM管理部によって捕捉できる。また、スクリプトがアクセスする装置オブジェクトモデルも、DOM管理部に組み込まれて管理されるので、DOM管理部が、文書に含まれるスクリプトから装置オブジェクトモデルへのアクセスを監視できる。何らかのアクセスがなされると、DOM管理部は、その文書がダーティであるものとマークする。DOM管理部は、FORMのサブミット指示を捕捉すると、そのFORMを含む文書がダーティであるものとマークされているか否かを判定し、ダーティであればサブミット指示の処理を中止させたり、ユーザに許可の確認を求めたりする。
図35は、動的な装置レポート文書のWebブラウザ上での表示例であり、Webブラウザのコンテンツ表示領域905上に、図33および図34の文書を表示したものである。この文書の表示は、装置オブジェクトモデルのアクセスを反映して動的に適応され、また装置オブジェクトモデルに対する操作を起動するユーザインターフェース(「更新」ボタン)と、その結果をフィードバックするユーザインターフェース(「カウンタ」および「ログ」フィールド)を持ち、さらに、装置オブジェクトモデルのアクセス結果をFORMのサブミット(「送信」ボタン)により送信する。
図36は、装置オブジェクトモデルへのアクセスを行った文書からFORMのサブミットを試みた場合に、ユーザにその許可を確認するために表示された確認ポップアップウィンドウの一例を示す図である。
本実施の形態では、スクリプトが装置オブジェクトモデルのいずれかに一度でもアクセスした場合、そのスクリプトが埋め込まれた文書に含まれるFORMからのサブミットの許可をユーザに確認するように構成したが、この制限がきつすぎる場合、装置オブジェクトモデルのいくつかだけを選択的に監視の対象とするように構成することもできる。また、装置オブジェクトモデルを構成するオブジェクトたちが備える特性のうち、特定のメソッドの呼び出しや特定のプロパティのアクセスを監視して、これらが行われなかった文書からのFORMのサブミットを許可する(つまり、ユーザに確認を求めない)ように構成してもよい。
また、許可の確認は、本実施の形態では、サブミットの度に行うように構成したが、あらかじめ許可または禁止を固定的に設定できるように構成してもよい。また、文書の獲得元URLやFORMの送信先URLなどに基づくルールをあらかじめ設定しておき、その制約に基づいて許可または禁止を自動的に判断するように構成してもよい。
本実施の形態の画像処理装置によれば、以下の効果が得られる。
すなわち、DOMを扱うのと同様に、装置オブジェクトモデルを扱うことができる。どちらもテキストベースであり、また、一般のWebデザインを行う制作者は、スクリプトによるDOMの操作には慣れ親しんでいるため、組み込み装置と連携するコンテンツを手軽に制作できる。
装置オブジェクトモデルの動的なノード、特に、たとえばログのレコードや複数装着可能な同一種類のオプションユニットなど、構造的な柔軟性も要するオブジェクトの集合をDOMと同様の動的な木構造として探索・操作できる。
(第5の実施の形態)
次に、本実施の第5の形態に係る組み込み装置を適用した画像処理装置について説明する。
本実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成は、前記第1の実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成と一部異なるのみであるので、前記第1の実施の形態の画像処理装置を含む画像処理システムのハードウェア構成およびソフトウェア構成を一部変更および追加して用いることにする。そして、以下では、その差異についてのみ説明する。
図37は、HDD304の論理的な使用方法を示した図である。
本実施の形態においては、使用用途に応じて、ハードディスクの記憶領域をテンポラリ領域701とボックス領域702に論理的に分ける。テンポラリ領域701は、画像データの出力順序を変えたり、複数部出力においても一回のスキャンで出力したりできるようにするために、PDLの展開データやスキャナからの画像データを一時的に記憶する記憶領域である。ボックス領域702はボックス機能を使用するための記憶領域であり、領域703〜707のように、登録された数の小さな記憶領域に分割されている。各ボックスにはボックス名を付けることができる。ユーザはボックスを指定することで、PDLジョブやスキャンジョブを各ボックス内の文書として格納することができる。また、複数の文書をまとめて管理するためのフォルダを作ることもできる。さらに、ボックスに格納されている文書やフォルダを閲覧したり、プリントや送信したりすることもできる。
ボックス703〜707は、他の装置内資源と同様に、所有権を持つユーザやグループが割り当てられている。また、オーナであるユーザ(以下、「ユーザu」と言う)、所有するグループに所属するユーザ(以下、「ユーザg」と言う)、および、それらに属さない他のユーザ(以下、「ユーザo」と言う)の、三種類のユーザの各々に対して、それぞれ読み出し、書き込み、および実行の許可として、アクセス権が設定できる。フォルダおよび文書にも同様に、オーナとグループが割り当てられ、アクセス権を設定することができる。
図38は、資源の一例として、文書資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。
ユーザが資源情報の参照または設定を指示すると、LCD表示部501に同図のグラフィカルユーザインターフェース(GUI)が表示される。
同図において、インスタンスフィールドは、現在選択している資源のインスタンスを示している。「技術調査報告書0110」は、当該文書資源のインスタンスにつけられた識別子、すなわち文書名である。
クラスフィールドは、現在選択している資源のクラスを示している。「文書」は当該資源が文書クラスのインスタンスであることを示している。
階層表示ボタンは、現在選択している資源のインスタンスとクラスの関係を階層表示するためのボタンである。詳細は後述する。
所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。
アクセス権設定領域は、現在選択している資源のアクセス権の設定を参照または設定するための領域である。本領域は、テーブルを表現しており、各行は、それぞれ、当該資源のインスタンスのオーナへの許可、グループへの許可、および、他者への許可の各状態を示している。各列は、それぞれ、読み出し、書き込み、および、実行の各許可状態を示している。行と列の交わった各フィールドが、当該資源のそれぞれ対応する属性の値を示している。
この例に限らず、装置オブジェクトモデルを構成するすべてのオブジェクトに関して、読み出し権限がある場合のみスクリプトからの属性の読み出しが許可され、書き込み権限がある場合のみスクリプトへの属性の変更が許可され、実行権限がある場合のみスクリプトからの操作の呼び出しが許可される。
さらに、各属性は資源毎にそれぞれ定義された意味を持つ。文書資源の読み出し許可は、当該文書を閲覧、プリント、送信することが可能であることを示す。文書資源の書き込み許可は、当該文書を編集して、書き換えたり、削除したりすることが可能であることを示す。文書資源の実行許可は、その文書を対象とするプリントや送信などの処理がジョブ記述形式のジョブスクリプトとして記憶され、その文書に対応づけられている場合に、ジョブスクリプトを実行することが可能であることを示す。
キャンセルボタンは、変更可能な値を変更していたとしても、その変更を無効にして、本GUIを閉じるためのボタンである。OKボタンは、変更可能な値を変更していた場合に、その変更を有効にして、本GUIを閉じるためのボタンである。
当該文書を所有するユーザは、本GUIを用いることで、当該文書を所有するグループを自らが所属するグループの中から設定でき、また、オーナ、グループ、および、他者のそれぞれに対して適切な許可を設定できる。また、管理者設定に対する書き込み権限を持つユーザ(不図示の管理者設定資源クラスの属性には、adminグループのメンバに対する書き込み権限が与えられている)は、すべての属性を変更可能であるので、当該文書を所有するオーナの設定も変更できる。したがって、所望のアクセス制御を行うことができる。本実施の形態では、オーナは、当該文書に対するすべての操作が可能であり、オーナが所属するグループrd(組織の研究開発部門)のメンバに対しては、読み出し操作のみを許可し、それ以外のユーザに対しては、読み出しも含むすべての操作を禁じている。
なお、文書資源と関連する資源に、フォルダクラスとボックスクラスがある。フォルダは、複数の文書および複数の他のフォルダをコンテンツとして内包可能なコンテナであり、ボックスは、トップレベルのフォルダである。フォルダおよびボックスにおける許可は、読み出しがコンテナに内包されるコンテンツのリスト表示の許可を表し、書き込みがコンテナへのコンテンツの追加および削除の許可を表し、実行はコンテナ毎に登録可能なコンテンツに対するバッチ処理の実行の許可を表す。
図39は、資源の他の一例として、カラーコピー機能資源インスタンスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。同図中、図38と同様の構成については、説明を省略する。
図39において、インスタンスフィールドは、現在選択している資源のインスタンスを示している。「<無名インスタンス>」は、当該カラーコピー機能資源のインスタンスにつけられた識別子、すなわち機能名である。本実施の形態では、カラーコピー機能クラスのインスタンスには、装置が自動的に生成した単一のインスタンスしか存在しないため、特定のインスタンス名を持たない、無名のインスタンスとなっている。
クラスフィールドは、現在選択している資源のクラスを示している。「カラーコピー」は、当該資源がカラーコピークラスのインスタンスであることを示している。
階層表示ボタンは、現在選択している資源のインスタンスとクラスの関係を階層表示するためのボタンである。詳細は後述する。
所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。
アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。カラーコピー機能資源におけるセマンティクスは、スーパークラスである機能資源によって定義されている。機能資源の読み出し許可は、当該機能の状態をモニタリングすることが可能であることを示す。機能資源の書き込み許可は、当該機能の動作モードをシステムレベルで制御するための特殊設定を変更可能であることを示す。機能資源の実行許可は、その機能のジョブを起動可能であることを示す。
本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本GUIを用いることで、当該機能に対する許可を変更可能である。グループはsales(組織の販売部門)であり、このグループに所属するメンバだけにカラーコピー機能の利用が許可され、それ以外のユーザに対しては禁止されている。
図40は、資源間の継承関係を表示し、カラーコピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。
ユーザが図39の階層表示ボタンを押下すると、LCD表示部501に図40のGUIが表示される。図40中、図39と同様の構成については、説明を省略する。
図40において、最上段の領域は階層表示領域である。本階層表示領域には、抽象‐具体関係に基づく継承関係が、図15と同様な階層表示によって表示されている。継承関係の表示において、それぞれの箱は資源のクラスまたはインスタンスを表現している。ユーザが操作部112上でいずれかの箱の領域を押下すると、そのクラスまたはインスタンスを選択することができる。背景が斜線の施された矩形で囲まれたクラスまたはインスタンスが、現在選択されている資源のクラスまたはインスタンスを示している。選択を変更すると、本GUIの以下の領域は、選択されたクラスまたはインスタンスに関する表示に切り替わる。図示例では、カラーコピークラスが選択されている。
所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。
アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。カラーコピー機能資源におけるセマンティクスは、スーパークラスである機能資源によって定義されている。機能資源の読み出し許可は当該機能の状態をモニタリングすることが可能であることを示す。機能資源の書き込み許可は当該機能の動作モードをシステムレベルで制御するための特殊設定を変更可能であることを示す。機能資源の実行許可は、その機能のジョブを起動可能であることを示す。
本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本GUIを用いることで、当該機能に対する許可を変更可能である。グループはsales(組織の販売部門)であり、このグループに所属するメンバだけにカラーコピー機能の利用が許可され、それ以外のユーザに対しては禁止されている。
図41は、資源間の継承関係を表示し、コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。
ユーザが図40の階層表示領域中でコピー機能クラスを表現する箱を押下すると、LCD表示部501に図41のGUIが表示される。図41中、図40と同様の構成については説明を省略する。
図41において、最上段の領域は階層表示領域である。図示例では、コピー機能クラスが選択されている。コピー機能クラスは、カラーコピー機能と白黒コピー機能を抽象化したスーパークラスであり、サブクラスたちに共通するデフォルトの属性値を継承するために用いられる。
本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本GUIを用いることで、当該機能に対する許可を変更可能である。グループはuser(すべてのユーザ)であり、装置にユーザアカウントを持つすべてのユーザに対してコピー機能の利用が許可され、それ以外のユーザ、すなわちguestユーザに対しては禁止されている。
図42は、資源間の継承関係を表示し、白黒コピー機能資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。
ユーザが図41の階層表示領域中で白黒コピー機能クラスを表現する箱を押下すると、LCD表示部501に図42のグラフィカルユーザインターフェース(GUI)が表示される。図42中、図41と同様の構成については説明を省略する。
図42において、最上段の領域は階層表示領域である。図示例では、白黒コピー機能クラスが選択されている。白黒コピー機能クラスは、コピー機能クラスを特殊化したサブクラスであり、スーパークラスであるコピー機能クラスからデフォルトの属性値を継承する。
本実施の形態では、当該機能を所有するユーザはsystemであり、実際の利用者には存在しない仮想的なユーザである。したがって、管理者設定に対する書き込み権限を持つユーザだけが、本GUIを用いることで、当該機能に対する許可を変更可能である。グループは未設定であり、スーパークラスのコピー機能クラスからuser(すべてのユーザ)を継承する。
本アクセス権設定領域において、すべての許可属性は未設定である。したがって、スーパークラスのコピー機能クラスから各々に対応する許可属性値を継承する。
図43は、資源間の集約関係を表示し、プリンタ部資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。
LCD表示部501に同図のGUIが表示される。同図中、図40などと同様の構成については、説明を省略する。
図43において、最上段の領域は、階層表示領域である。本階層表示領域には、全体‐部分関係に基づく集約関係が、図16と同様な階層表示によって表示されている。集約関係の表示において、それぞれの箱は、資源のクラスまたはインスタンスを表現している。ユーザが操作部上でいずれかの箱の領域を押下すると、そのクラスまたはインスタンスを選択することができる。背景が斜線の施された矩形で囲まれたクラスまたはインスタンスが、現在選択されている資源のクラスまたはインスタンスを示している。選択を変更すると、本GUIの以下の領域は、選択されたクラスまたはインスタンスに関する表示に切り替わる。図示例では、プリンタ部が選択されている。
所有者情報領域は、現在選択している資源の所有者に関する情報を参照または設定するための領域である。オーナフィールドは、現在選択している資源を所有するユーザの識別子を示す。グループフィールドは、現在選択している資源を所有するグループの識別子を示す。
アクセス権設定領域が示す各属性は、資源毎にそれぞれ定義された意味を持つ。本実施の形態におけるプリンタ部1972は、その部分ユニットである、排紙ユニット1907、マーキングユニット1905および排紙ユニット1908をひとまとめに扱うためのユニットにすぎず、実際には、読み出し、書き込みまたは実行のいずれのアクセスも受けない。しかし、プリンタ部資源は、アクセス権設定属性を保持し、これを参照および設定可能である。本実施の形態では、プリンタ部の属性値を、その部分ユニットたちの既定の属性値として用いる。したがって、全体‐部分関係の子にあたる複数の部分ユニットの属性値を未設定にしておけば、それらの部分ユニットの未設定属性が、全体ユニットの対応する属性に連動する。
図44は、資源間の集約関係を表示し、排紙ユニット資源クラスのアクセス権を参照および設定するユーザインターフェースの一例を示す図である。同図中、図43と同様の構成については、説明は省略する。
図44では、排紙ユニットが選択されている。排紙ユニット1908は、プリンタ部1972の部分ユニットである。
同図において、グループおよびアクセス権の各属性は、未設定であるため、プリンタ部資源の対応する属性が設定されているものとして扱っている。
図45は、アクセス権違反エラー表示の一例を示す図である。
ユーザが行った処理がアクセス権の不足によって失敗したとき、LCD表示部501に同図のGUIが表示される。GUIのメッセージは、処理に必要な権限が不足していることをユーザに伝えるためのものである。また、メッセージは、失敗の原因となった資源とその資源に対して必要だった許可を表示している。ユーザが詳細ボタンを押下すると、エラーに関する情報をさらに詳しく表示する。詳細表示として、失敗との原因となった資源の情報(たとえば、図39)を表示することもできる。ユーザがOKボタンを押下すると、本GUIが閉じる。
本実施の形態では、全体クラスとその部分クラス間の集約関係を表現する階層構造を保持し、各資源のアクセス権を示す属性に関して、全体クラスが部分クラスの属性の既定値を提供するように構成した。このため、部分クラスにおいて未設定の属性値を全体クラスから供給できるので、複数の部分的なクラスを持つ資源群に関して、それらを内包するクラスで一度属性値を設定するだけで各々の部分的な資源に対して共通のデフォルトのアクセス権を簡易に設定できる。また、必要に応じ、より部分的な資源(および、もしあればその部分クラス)に対して、共通のデフォルトとは異なる、特定のアクセス権を設定することもできる。
各資源のクラス間の全体‐部分の集約関係を階層的に表示するGUIを備え、さらに、クラスの集約関係を参照しながら、各クラスおよびインスタンスのアクセス権情報を参照および設定するためのGUIを備えた。このため、ユーザは各種資源間の集約関係をわかりやすく把握でき、把握した集約関係に基づき適切なアクセス権の設定を行うことが容易にできる。
なお、上記各実施の形態では、DOMは、HTML文書のDOMだけを取り上げて説明したが、XHTMLなど他のマークアップ言語によって記述された文書一般に対して本発明を適用可能である。たとえば、スクリプトからSVGのDOMを操作することによって、HTMLだけから構成される文書よりもよりグラフィカルにリッチなユーザインターフェースと装置オブジェクトモデルの操作とを組み合わせることもできる。
また、ブラウザとサーバ間のプロトコルは、本実施の形態では、HTTPを用いて説明したが、HTTPS(Hypertext Transfer Protocol Security)はもちろんのこと、今後も含めてWeb技術において一般に用いられるプロトコルであればどのプロトコルを利用してもよい。
さらに、本実施の形態では、スクリプトの実行に伴う処理の権限を、Webブラウザを利用中のユーザに基づいて決定したが、ユーザによらず、スクリプト用のアクセス権を一意的に決定したり、スクリプトに付加された署名などにより識別されるスクリプト提供者に基づいてアクセス権を決定したりするように構成してもよい。
また、本実施の形態では、オブジェクト毎にアクセス権限を設定したが、クラスに含まれる個々の操作毎に権限を設定するように構成してもよい。
なお、上述した各実施の形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムまたは装置に供給し、そのシステムまたは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記憶媒体から読出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
プログラムコードを供給するための記憶媒体としては、たとえば、フレキシブルディスク、ハードディスク、光磁気ディスク、CD−ROM、CD−R、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、DVD+RW、磁気テープ、不揮発性のメモリカード、ROMなどを用いることができる。また、通信ネットワークを介してサーバコンピュータからプログラムコードが供給されるようにしてもよい。
また、コンピュータが読出したプログラムコードを実行することにより、上述した各実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOSなどが実際の処理の一部または全部を行い、その処理によって上述した各実施の形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって上述した各実施の形態の機能が実現される場合も含まれることは言うまでもない。