JP2002117005A

JP2002117005A - 文書サーバ

Info

Publication number: JP2002117005A
Application number: JP2000310233A
Authority: JP
Inventors: Nobuo Iwata; 伸夫岩田
Original assignee: Fuji Xerox Co Ltd
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2000-10-11
Filing date: 2000-10-11
Publication date: 2002-04-19

Abstract

(57)【要約】【課題】要求電文の送信元となるブラウザに対して適
切に文書を送信できるようにする。【解決手段】文書ブラウザからの要求電文を受け付け
かつその受け付けた要求電文に従って文書を送信するＷ
ｅｂサーバ部２１と、このＷｅｂサーバ部２１に要求電
文を送り、その応答文書をディスプレイ５に表示するＷ
ｅｂブラウザ部２４とを備えるプリンタ装置１０におい
て、Ｗｅｂサーバ部２１は、受け付けた要求電文の送信
元となる文書ブラウザとの接続関係を識別する第１の識
別手段と、受け付けた要求電文によって要求された文書
の属性を識別する第２の識別手段と、第１の識別手段及
び第２の識別手段の識別結果を基に、送信する文書を制
御する制御手段とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、文書ブラウザから
の要求に応じて、ＨＴＭＬ(HyperText Markup Languag
e)等によって記述された文書データを送信する文書サー
バに関する。

【０００２】

【従来の技術】現在、ＷＷＷ(World Wide Web)サーバに
よる情報発信やサービス提供が広く普及している。ＷＷ
Ｗサーバによる情報発信等の方法は、一般にインターネ
ットを介し、ＨＴＭＬで記述された文書データを、Ｗｅ
ｂサーバから、Ｗｅｂブラウザを搭載したパーソナルコ
ンピュータ等に供給することにより実現されている。近
年では、そのような情報発信やサービス提供が一層拡大
し、さらに、利用者がＷｅｂブラウザの操作に習熟する
のに伴い、家電製品やＯＡ機器にもＷｅｂブラウザを搭
載した製品が登場している。また、モバイル環境の普及
に伴い、携帯端末や携帯電話などでもＷｅｂブラウザを
搭載した機種が多くなっている。

【０００３】ここで、家電製品、ＯＡ機器、携帯端末、
携帯電話等は、パーソナルコンピュータに比べると、表
示部の能力、ＣＰＵの能力、記憶部の容量、通信速度な
どの点で劣るため、複雑な文書を表示できないといった
課題を抱えている。現状では、通常（パーソナルコンピ
ュータ向け等）の文書の他に、携帯電話等の特別な用途
に、制限されたＨＴＭＬで作成された文書を用意する方
法が用いられている。ここで、制限されたＨＴＭＬと
は、フォーム（入力欄等）、テーブル（表組）、イメー
ジ、オブジェクト（実行可能なプログラム）等の要素を
含まないように構成したものである。ただし、このよう
な方法では、Ｗｅｂブラウザ側の操作者が、表示可能な
ＨＴＭＬ文書のアドレス(URL:Unified Resource Locato
r)を意図的に指定する必要がある。そのため、表示不可
能なＨＴＭＬ文書や容量の大きな文書を誤って指定して
しまった場合は、文書が正しく表示されない、文書を受
信する時間が非常に長くなるなどの問題が生じる。

【０００４】このような問題を解決するため、現在、Ｈ
ＴＭＬを送受信する通信手順であるＨＴＴＰ(HyperText
Transfer Protocol)の規格の中で、Ｗｅｂブラウザ
が、受付可能な文書、イメージ、オブジェクト等の種別
を指定する方法が知られている。即ち、アクセプト(Acc
ept)ヘッダにそれらの種別をＭＩＭＥ(Multipurpose In
ternet Mail Extensions)タイプと呼ばれる種別の表現
方法で通知するものである。例えば、ｔｅｘｔ／ｃｈｔ
ｍｌをアクセプトヘッダの値に指定した場合は、ＣＨＴ
ＭＬ(Compact HyperText Markup Language)で記述され
た文書を受付可能であることを示す。また、ワイルドカ
ード（「＊」文字）を使用してｉｍａｇｅ／＊と指定し
た場合は、あらゆるイメージを受付可能であることを示
す。

【０００５】

【発明が解決しようとする課題】しかしながら、アクセ
プトヘッダで文書の種別を指定する方法では、装置に専
用でない汎用のＷｅｂブラウザソフトウェアを利用する
場合に、アクセプトヘッダが装置に合わせて送信されな
くなる。そのため、表示可能なＨＴＭＬ文書だけが送信
されるように制御することは不可能になる。また、Ｗｅ
ｂブラウザがアクセプトヘッダを送信する場合、アクセ
プトヘッダの分だけ要求電文が長くなり、通信のオーバ
ーヘッドが生じる。さらに、ＭＩＭＥタイプで表現不可
能な機能の差異は制御できないという問題もある。

【０００６】特に、Ｗｅｂブラウザを搭載するＯＡ装置
や家電装置において、装置内にＷｅｂサーバを搭載し、
装置内部に搭載されたＷｅｂサーバで装置の状態を示す
等のＨＴＭＬを供給する場合であって、装置内部に搭載
されたＷｅｂブラウザ及び外部接続されたコンピュータ
等に搭載されたＷｅｂブラウザからの要求に対して、装
置内部に搭載されたＷｅｂサーバがＨＴＭＬを供給する
場合は、次のような問題が生じる。即ち、装置内部に搭
載されたＷｅｂブラウザと、外部接続されたコンピュー
タ等に搭載されたＷｅｂブラウザとでは、実行できる機
能に差異がある。そのため、実行又は表示不可能なＨＴ
ＭＬ文書が送信されてしまったり、適切でないＨＴＭＬ
が送信されるなどの不具合が生じる。例えば、プリンタ
装置に搭載されたＷｅｂサーバであって、プリントデー
タをブラウザからプリントデータをアップロードするＨ
ＴＭＬ文書は、外部接続された装置に送信するのは有効
であるが、プリンタ装置内に搭載されたブラウザ装置に
送信するのは無意味（無効）なものとなる。

【０００７】

【課題を解決するための手段】本発明は、上記課題を解
決するためになされたもので、文書ブラウザからの要求
電文を受け付ける受付手段と、この受付手段で受け付け
た要求電文に従って文書を送信する送信手段とを有する
文書サーバにおいて、受付手段で受け付けた要求電文の
送信元となる文書ブラウザとの接続関係を識別する第１
の識別手段と、受付手段で受け付けた要求電文によって
要求された文書の属性を識別する第２の識別手段と、こ
れら第１の識別手段及び第２の識別手段の識別結果に基
づいて送信手段が送信する文書を制御する制御手段とを
備えた構成となっている。

【０００８】上記構成の文書サーバにおいては、文書ブ
ラウザからの要求電文を受付手段で受け付けると、その
要求電文の送信元となる文書ブラウザとの接続関係が第
１の識別手段によって識別されるとともに、その要求電
文によって要求された文書の属性が第２の識別手段によ
って識別される。そして、これら第１の識別手段及び第
２の識別手段の識別結果を基に、送信手段が送信する文
書が制御手段によって制御される。

【０００９】

【発明の実施の形態】以下、本発明に係る文書サーバを
プリンタ装置に適用した場合の実施の形態につき、図面
を参照しつつ詳細に説明する。なお、本発明に係る文書
サーバは、プリンタ装置への適用に限定されるものでは
なく、他のＯＡ機器や家電製品にも広く適用し得るもの
である。

【００１０】図１は本発明の実施形態に係るプリンタ装
置のハードウェア構成図である。図示したハードウェア
構成においては、装置電源が投入された後、ＣＰＵ１が
ブートＲＯＭ２に格納されたプログラムをＲＡＭ３上に
読み出して実行する。ここで実行されるプログラムはさ
らに、ハードディスク４に格納されているプログラムを
ＲＡＭ３上に読み出して実行する。ここで実行されるプ
ログラムは、ディスプレイ５に表示を行ったり、タッチ
パネル６から入力を受け付けたりし、操作者と対話的に
データ処理を行う。

【００１１】タッチパネル６は、ディスプレイ５の表示
面に貼り付けられた状態で設置される。このタッチパネ
ル６では、操作者がパネル面に触れると、その座標を入
力とみなし、ディスプレイ５に表示されている内容のど
の部分が指示されたのかを判断し処理する。ハードディ
スク４は、文書ファイルや設定情報ファイルなどの各種
の情報、データ、プログラム等を格納するものである。
このハードディスク４に格納されたプログラムは、ＬＡ
Ｎ(Local Area Network)インターフェース７を介して、
ＬＡＮに接続された他のネットワーク通信機器と通信
し、さらにＬＡＮからインターネットを経由して他のネ
ットワーク通信機器とも通信する。

【００１２】図２は本発明の実施形態に係るプリンタ装
置が動作するシステム構成図である。本実施形態のプリ
ンタ装置１０は、ＬＡＮ１１及びインターネット１２を
経由して外部のネットワーク通信機器（パーソナルコン
ピュータ等）１３に搭載されたブラウザからの要求電文
Ｅ１を受信し、この受信した要求電文Ｅ１によって要求
された文書データを応答Ｅ２として、ＬＡＮ１１及びイ
ンターネット１２を経由して要求元（ネットワーク通信
機器１３）のブラウザに送信する。また、プリンタ装置
１０は、自装置内にブラウザ機能を搭載しているため、
ＬＡＮ１１及びインターネット１２を経由してサーバ装
置１４に文書取得の要求電文Ｅ１を送信し、その応答Ｅ
２としてサーバ装置１４から送信された文書データを受
信し、表示する。

【００１３】図３は本発明の実施形態に係るプリンタ装
置のソフトウェア構成図である。図示したソフトウェア
構成において、Ｗｅｂサーバ部２１は、イーサネット
（登録商標）制御部２２、ＴＣＰ／ＩＰプロトコル２３
を介して、ＨＴＴＰの要求電文Ｅ１を受信するととも
に、ハードディスク４に格納されている複数の文書ファ
イルの中から、要求電文で要求のあった文書ファイルを
検索し取得する。さらに、Ｗｅｂサーバ部２１は、ハー
ドディスク４から取得した文書ファイルの文書データ
を、ＴＣＰ／ＩＰプロトコル２３を介してＨＴＴＰの応
答電文Ｅ２として送信する。

【００１４】Ｗｅｂブラウザ部２４は、ハードディスク
４から設定情報ファイルを読み出し、動作を変更する。
例えば、Ｗｅｂブラウザ部２４は、設定情報ファイルか
ら電源投入後最初に表示する文書のＵＲＬを得る。Ｗｅ
ｂブラウザ部２４は、ＴＣＰ／ＩＰプロトコル２３を介
してＷｅｂサーバ部２１に文書取得の要求電文Ｅ１を送
信し、その応答Ｅ２としてＷｅｂサーバ部２１から送信
された文書データを受信してディスプレイ５に表示す
る。また、Ｗｅｂブラウザ部２４は、タッチパネル６か
らの入力を受け付け、表示された文書中のハイパーリン
クが指示された場合に、ハイパーリンクが示す文書を取
得する要求電文Ｅ１を送信する。

【００１５】なお、Ｗｅｂサーバ部２１及びＷｅｂブラ
ウザ部２４は、それぞれイーサネット制御部２２、ＴＣ
Ｐ／ＩＰプロトコル２３を介して、外部のネットワーク
通信機器２５、２６と通信しても良い。

【００１６】図４は本発明の実施形態に係るプリンタ装
置が送受信する通信パケット構造の概念図である。図に
おいて、ＭＡＣ(Media Access Control)ヘッダ３１は、
前述したイーサネット制御部２２によって処理されるも
のである。また、ＴＣＰ／ＩＰヘッダ３２は、前述した
ＴＣＰ／ＩＰプロトコル２３によって処理されるもので
ある。データ３３は、前述したＷｅｂサーバ部２１又は
Ｗｅｂブラウザ部２４によって処理されるものである。

【００１７】データ３３には、アプリケーションプロト
コルのデータが含まれ、本実施形態のプリンタ装置１０
が扱う範囲では、ＨＴＴＰコマンド及びレスポンスが含
まれる。また、ＭＡＣヘッダ３１には、送信元と宛先の
イーサネットアドレスが含まれ、ＴＣＰ／ＩＰヘッダ３
２には送信元と宛先のＩＰアドレスが含まれる。ルータ
を隔てて他の装置と接続される場合、イーサネットアド
レスの相手装置側はルータのイーサネットアドレスとな
る。また、プリンタ装置内部のＷｅｂブラウザ部２４と
Ｗｅｂサーバ部２１とがＴＣＰ／ＩＰプロトコル２３を
介して通信する場合は、ＭＡＣヘッダが付加されない。

【００１８】図５は本発明の第１実施形態に係るＷｅｂ
サーバ部２１の処理手順を示すフローチャートである。
先ず、Ｗｅｂサーバ部２１は、要求電文となるＨＴＴＰ
コマンドを受信すると（ステップＳ１）、要求電文の要
求元のＩＰアドレスを取得する（ステップＳ２）。要求
元のＩＰアドレスは、データ受信時の付加情報としてＴ
ＣＰ／ＩＰプロトコル２３から通知される。ＩＰアドレ
スは、現在一般的に普及しているＩＰバージョン４で
は、４バイトであり、各バイトの間を「．」で区切り、
各バイトを１０進数で表現するドット表記と呼ばれる方
法で表現される。ステップＳ１で受信されるＨＴＴＰコ
マンドには、例えば図６に示すように、要求する文書の
ＵＲＬ（Ｄ１０２）がリクエスト行（Ｄ１０１）に示さ
れる。

【００１９】次に、Ｗｅｂサーバ部２１は、ＨＴＴＰコ
マンドで要求された文書をハードディスク４から読み出
す（ステップＳ３）。これにより、要求された文書がハ
ードディスク４から読み出された場合はステップＳ４で
「Ｙｅｓ」と判断し、要求された文書がハードディスク
４から読み出されなかった場合（要求された文書がハー
ドディスク４に存在しなかった場合）はステップＳ４で
「Ｎｏ」と判断する。

【００２０】続いて、ステップＳ３でハードディスク４
から読み出された文書の属性を取得する（ステップＳ
５）。図７に読み出された文書の例を示す。図例では、
文書中にＭＥＴＡタグ（Ｄ２０１）で記述された情報の
中に文書の属性が示されている。即ち、この例では、
「form-without-text-input」が文書の属性を示してい
ることから、これを基に文書の属性を識別する。

【００２１】次に、先のステップＳ２で取得した要求元
のＩＰアドレスと先のステップＳ６で取得した文書の属
性とに基づいて、要求された文書の送信可否を検査する
（ステップＳ６）。さらに詳述すると、先ず、ステップ
Ｓ２で取得した要求元のＩＰアドレスが自装置内のブラ
ウザのアドレスと一致するか否かによって、要求電文の
要求元の文書ブラウザとの接続関係を識別する。この場
合、自装置内のブラウザのアドレスは、予めループバッ
クのアドレスとして例えば（１２７．０．０．１）と割
り当てられるため、ステップＳ２で取得した要求元のＩ
Ｐアドレスがループバックアドレスと一致するか否かに
より、自装置に属するブラウザであるかどうかを識別す
る。また、ステップＳ５で取得した文書の属性から、要
求された文書がテキスト入力の要素を含むものであるか
どうかを識別する。

【００２２】ここで、要求元の文書ブラウザが自装置
（プリンタ装置）内のブラウザであると判断した場合
は、そのブラウザ（Ｗｅｂブラウザ部２４）によって要
求された文書が、自装置への送信を許可されたものであ
るかどうかをチェックする。自装置への送信を不許可と
する文書としては、例えば、自装置のハードディスク４
に格納されたデータ（プリントデータ等）をアップロー
ドするＨＴＭＬ文書などがある。このＨＴＭＬ文書が自
装置に送信されてディスプレイ５に表示され、タッチパ
ネル６による入力操作によって例えばプリントデータの
ローディングが実行された場合、ローディングされたプ
リントデータが、当該プリントデータを保持する元のハ
ードディスク４に格納される形態となる。そのため、プ
リンタ装置としては全く無効（無意味）な動作となる。
このようにプリンタ装置として無効な動作を招く文書に
ついては、予めそうした文書の属性を特定しておき、ス
テップＳ５で取得した文書の属性がそれに該当する場合
は、自装置に属するブラウザからの取得要求に対して送
信不許可の扱いとするように、文書の送信条件を決定す
る。取得要求のあった文書を送信不許可の扱いに決定し
た場合は、次のステップＳ７で「Ｎｏ」と判断する。

【００２３】また、自装置のブラウザからの取得要求に
対して送信許可の扱いとなった文書であっても、その文
書の属性が自装置に適さないものである場合はステップ
Ｓ７で「Ｎｏ」と判断される。例えば、ステップＳ５で
取得した文書の属性から、当該文書がテキスト入力を含
む文書であると判断した場合は、キー入力が出来ない自
装置において処理不可能と判断する。この場合は、取得
要求のあった文書の送信を禁止するように送信条件を決
定し、ステップＳ７で「Ｎｏ」と判断する。例えば、図
９に示す文書の場合、ＭＥＴＡタグ（Ｄ４０１）の文書
属性に「form-with-text-input」が示されているので、
テキスト入力を含む文書であるとの認識から、自装置の
ブラウザでは処理不可能と判断し、文書の送信を禁止す
るように送信条件を決定する。これに対して、ステップ
Ｓ５で取得した文書の属性が先に記述した「form-witho
ut-text-input」であれば、テキスト入力を含まない文
書であると判断するため、自装置において処理可能と判
断する。この場合は、取得要求のあった文書の送信を実
行するように送信条件を決定し、ステップＳ７で「Ｙｅ
ｓ」と判断する。

【００２４】ちなみに、キー入力が出来るかどうかの判
断は、ＨＴＴＰ要求電文のなかに、その送信元となるブ
ラウザの種別や設定情報、或いは当該ブラウザを搭載し
た装置の構成情報を含ませるようにしてもよい。例え
ば、図６に示した要求電文では、ＨＴＴＰヘッダ（Ｄ１
０３）中にブラウザの種別が示されているので、この部
分を解析することにより送信元のブラウザの種別を識別
することができる。また、ＨＴＴＰヘッダ（Ｄ１０３）
中に、「Pointing:」によりポインティングデバイスの
有無が、「Keyboard」によりキーボードの有無が示され
るので、この部分を解析することにより装置の構成情報
を識別することができる。図６に示した要求電文の例で
は、ブラウザの種別が「micro-browser」であるため、
要求電文の要求元のブラウザの種別は簡易的な機能のも
のであると認識し、その識別結果に応じて、テキスト入
力を含む文書は処理不可能と判断する。また、装置の構
成情報が「Keyboard: No」、即ちキーボードが無い構成
であるため、その構成情報に応じて、テキスト入力を含
む文書は処理不可能と判断する。

【００２５】続いて、ステップＳ７において「Ｙｅｓ」
と判断すると、ステップＳ３でハードディスク４から読
み出した文書を要求元（要求電文の送信元）のブラウザ
に送信する（ステップＳ８）。ステップＳ８で送信され
る電文の概念図を図８に例示する。図８においては、ハ
ードディスク４から読み出された文書が電文の本体部
（Ｄ３０１）に格納される。

【００２６】一方、ステップＳ４において「Ｎｏ」と判
断した場合、又はステップＳ７において「Ｎｏ」と判断
した場合は、それぞれステップＳ９に移行し、そこでエ
ラー通知文書を送信する。図１０にエラー電文の概念図
を例示する。図１０においては、ステータス行（Ｄ５０
１）にエラーコードとして、文書が見つからなかった旨
のコード「４０４」が設定される。また、本体部（Ｄ５
０２）には、ブラウザに表示される文書として、エラー
の内容を表す文書が格納される。このようにエラー通知
文書の中に、エラーの内容を表す文書を含めることによ
り、そのエラー内容をディスプレイ等に表示させること
ができる。ただし、エラー通知文書としては、単にエラ
ーが発生した旨を通知するものであればよく、必ずしも
エラーの内容まで含める必要はない。

【００２７】このように本第１実施形態においては、要
求電文の要求元の文書ブラウザのアドレス情報に基づい
て当該文書ブラウザとの接続関係を識別するとともに、
要求電文によって要求された文書の種別を識別し、それ
らの識別結果を基に、要求された文書が、その要求元装
置に送信許可されたものであるかどうかをチェックし、
送信許可されたものではないと判断した場合は、要求文
書の送信を禁止するようにしている。そのため、自装置
のブラウザからの要求電文に対しては、その要求された
文書が表示されても問題のないもの（例えば、プリント
データの一覧など）だけを選択して送信することが可能
となる。これにより、プリンタ装置１０内に搭載された
Ｗｅｂプラウザ部２４には、プリントデータをアップロ
ードするＨＴＭＬ文書が送信されなくなる。その結果、
自装置内のハードディスク４に格納されたデータのロー
ディングを実行するといった無意味な処理動作を確実に
回避することが可能となる。

【００２８】また、要求された文書が要求元装置に適さ
ないものであると判断した場合（処理不可能と判断した
場合）にも、要求文書の送信を禁止するようにしてい
る。したがって、要求元装置に対しては、その装置で処
理可能な文書だけを選択して送信することが可能とな
る。さらに、要求電文の送信を禁止した場合には、要求
された文書に替えてエラー通知文書を送信するようにし
ている。これにより、取得要求元装置のディスプレイに
はエラー通知文書が表示されるため、当該装置の操作者
は、エラー通知文書を見てエラーの発生やエラー内容を
把握することが可能となる。

【００２９】なお、上記第１実施形態においては、プリ
ンタ装置がイーサネットによってＬＡＮに接続する例を
示したが、Ｔｏｋｅｎ−Ｒｉｎｇや他のネットワークイ
ンターフェースを用いて接続するようにしてもよい。ま
た、プリンタ装置が、ＳＬＩＰ(Serial Line Internet
Protocol)やＰＰＰ(Point to point)によって他の装置
と直接接続しても良い。また、ＰＰＰによってモデム装
置と接続し、さらにインターネットプロバイダと接続す
るようにしてもよい。この場合は、Ｗｅｂサーバ部２１
で受け付けた要求電文の要求元のブラウザが、自装置に
一種類以上の接続手段（有線接続、無線接続等）で接続
されているか否かにより、当該ブラウザとの接続関係を
識別することが可能となる。

【００３０】また、上記第１実施形態においては、プリ
ンタ装置の内部にＷｅｂブラウザ（２４）が搭載されて
いる例を示したが、Ｗｅｂブラウザがプリンタ装置の周
辺装置に搭載されたものであってもよい。例えば、Ｗｅ
ｂブラウザがシリアルポートでプリンタ装置に接続さ
れ、ＳＬＩＰで通信する場合において、ＳＬＩＰのポー
トに特別なＩＰアドレス、例えば「１２７．０．０．
２」を割り当てる。これにより、要求電文の要求元のブ
ラウザのＩＰアドレスが「１２７．０．０．２」に一致
するかどうかにより、プリンタ装置のＷｅｂサーバ（２
１）は、自装置に属するブラウザからの文書取得要求で
あるかどうかを判別することが可能である。

【００３１】図１１は本発明の第２実施形態に係るＷｅ
ｂサーバ部２１の処理手順を示すフローチャートであ
る。先ず、ステップＳ１１〜Ｓ１６では、先のステップ
Ｓ１〜Ｓ６と同様の処理を行う。そして、ステップＳ１
６での文書の送信可否検査において、要求電文により要
求された文書を、その要求元であるブラウザで処理可能
と判断した場合は、ステップＳ１７で「Ｙｅｓ」と判断
してステップＳ１８に進み、要求された文書をそのまま
の形で要求元のブラウザに送信する。なお、ステップＳ
１４で「Ｎｏ」と判断した場合は、先の第１実施形態の
場合と同様にエラー通知文書を送信する（ステップＳ１
９）。

【００３２】これに対して、要求電文により要求された
文書を、その要求元であるブラウザで処理不可能と判断
した場合は、ステップＳ１７で「Ｎｏ」と判断してステ
ップＳ２０に移行する。ステップＳ２０においては、要
求された文書を変更（編集）する。例えば、要求元装置
がディスプレイにキーボードのイメージを表示し、表示
されたキーボードが指示されることによりテキスト入力
する装置である場合は、その装置の構成情報として、Ｈ
ＴＴＰヘッダに「KEYBOAD: Virtual-Keyboard」が示さ
れる。この場合、要求元装置において、短いテキストの
入力は容易であるが、長いテキストの入力は困難と判断
する。そして、要求された文書が例えば図９に示す文書
であるとすると、ＴＥＸＴＡＲＥＡフィールド（Ｄ４０
４）は削除し、ＩＮＰＵＴフィールド（Ｄ４０２，Ｄ４
０３）は残すかたちで文書を変更する。そして、変更後
の文書を要求元のブラウザに送信する（ステップＳ１
８）。

【００３３】このように本第２実施形態においては、要
求された文書が要求元装置に適さないものであると判断
（処理不可能と判断した場合）した場合は、その要求元
装置に適合するように要求文書を変更するものとしてい
る。したがって、要求元装置に対しては、その装置で処
理可能な文書に変換して送信することが可能となる。

【００３４】なお、上記第２実施形態においては、要求
元装置で処理不可能と判断される部分、即ち要求された
文書に含まれる入力要素を削除するようにしたが、これ
以外にも、例えば、要求された文書に含まれる入力要素
を非活性に設定（変更）するようにしてもよい。具体的
には、ＩＮＰＵＴタグ中に「ＤＩＳＡＢＬＥ」の文字列
を挿入して送信することにより、ブラウザ側では該当す
るＩＮＰＵＴフィールドが灰色表示され、入力されない
ように処理される。

【００３５】ここで、先のステップＳ１６において、要
求された文書を要求元装置で処理可能と判断し、これに
従ってステップＳ１７で「Ｙｅｓ」と判断した文書であ
っても、その文書がハイパーリンクを含むものである場
合は、リンクされた文書が要求元装置で処理不可能とな
ることも懸念される。そこで、本発明の第３実施形態に
おいては、要求された文書を変更する他の手法として、
以下のような処理手順を採用することとした。

【００３６】図１２は本発明の第３実施形態に係るＷｅ
ｂサーバ部２１の処理手順を示すフローチャートであ
る。なお、ステップＳ３１〜Ｓ３８については、先のス
テップＳ１１〜Ｓ１７及びＳ１９の処理と同様であるた
め、ここでは説明を省略する。

【００３７】図１２に示す処理フローにおいて、ステッ
プＳ３７で「Ｙｅｓ」と判断すると、先ずは、要求され
た文書に含まれる全てのハイパーリンクについての検査
が終了したか否かを判断し（ステップＳ３９）、終了し
ていない場合は、リンクされている文書を読み出す（ス
テップＳ４０）。次いで、読み出した文書の属性を取得
したのち（ステップＳ４１）、ステップＳ３７と同様に
文書の送信可否を検査する（ステップＳ４２）。さら
に、その検査結果に基づく判断として、ステップＳ４３
で「Ｎｏ」と判断すると、検査対象としたハイパーリン
グを削除し（ステップＳ４４）、ステップＳ４３で「Ｙ
ｅｓ」と判断した場合は、そのハイパーリングを削除せ
ずにステップＳ３９に戻る。

【００３８】例えば、ステップＳ３３で読み出された文
書が、図１３に示される文書である場合、（Ｄ６０１）
と（Ｄ６０２）で示される部分がハイパーリンクであ
る。ハイパーリンクで示される文書がそれぞれ図７及び
図９に示される文書である場合であって、ブラウザがテ
キスト入力不可であれば、テキスト入力を持たない文書
属性（Ｄ２０１）を持つ文書のハイパーリンク（Ｄ６０
１）は削除されないが、テキスト入力を有する文書属性
（Ｄ４０１）を持つ文書のハイパーリンク（Ｄ６０２）
は削除される。その後、要求文書に含まれる全てのハイ
パーリンクについての検査が終了すると、ステップＳ４
５に移行して文書の送信を行う。

【００３９】このように本第３実施形態においては、要
求電文で要求された文書に含まれるハイパーリンクにつ
いても検査し、リンクされた文書の属性が要求元装置に
適さないものであると判断した場合は、その文書を示す
ハイパーリンクを削除するようにしている。したがっ
て、要求元装置に対しては、その装置で処理可能な文書
を示すハイパーリンクのみを残して要求文書を送信する
ことが可能となる。

【００４０】ちなみに、検査対象とするハイパーリンク
は、要求電文を受け付けたサーバ（本実施形態ではプリ
ンタ装置１０のハードディスク４）内に格納された文書
のみに制限してもよい。また、サーバ内の制限された範
囲の文書のみに制限してもよい。また、要求電文を受け
付けたサーバと、制限された幾つかのサーバ内に格納さ
れた文書のみに制限してもよい。

【００４１】さらに、ハイパーリンクの削除に関して
は、タグで囲まれた部分、即ち「＜Ａ」から「＜／Ａ
＞」までを削除してもよいし、タグのみ、即ち「＜
Ａ．．．＞」と「＜／Ａ＞」を削除してもよい。また、
タグ中の関連文書の属性、即ち「ｈｒｅｆ
＝“．．．”」を削除してもよい。

【００４２】図１４は本発明の第４実施形態に係るＷｅ
ｂサーバ部２１の処理手順を示すフローチャートであ
る。先ず、先の図６に示すような要求電文を受信する
（ステップＳ５１）。次に、受信したパケット（図４参
照）のＴＣＰ／ＩＰヘッダ３２に含まれる要求元アドレ
ス（ＩＰアドレス）をＴＣＰ／ＩＰプロトコルプロトコ
ル２３から取得する（ステップＳ５２）。次いで、要求
電文により要求された文書の種別を識別する（ステップ
Ｓ５３）。ここでの文書の種別は、先の図６に示す要求
電文中のＵＲＬ（Ｄ１０２）の一部または全部が、予め
記憶されている文字列と一致するかにより識別する。

【００４３】次に、先のステップＳ５３での識別結果に
基づいて、送信する文書を選択する（ステップＳ５
４）。ここで、例えば、先のステップＳ５２で取得した
アドレスが、同一装置内のアドレス（ループバックアド
レス）であった場合は、要求された文書ファイルの別の
ディレクトリに格納された文書ファイルを選択する。ま
たは、要求された文書ファイルに接頭子や接尾子を付加
した文書ファイルを選択する。さらに、選択された文書
を読み出し（ステップＳ５５）、その読み出した文書を
要求元に送信する（ステップＳ５６）。これにより、予
め用意された複数の種類の文書の中から、要求元装置に
適合した種類の文書を選択して送信することが可能とな
る。

【００４４】なお、上記第１〜第４実施形態において
は、要求電文によって要求された文書を、要求電文の要
求元装置（要求元のブラウザを搭載した装置）で処理可
能かどうかを判断するにあたって、そのブラウザの種別
や設定情報、或いはキーボードの有無といった装置の構
成情報を基にテキスト入力できるか否かを判断基準の例
として示したが、これ以外にも、例えばディスプレイ等
の表示能力（表示枠の制限など）やＣＰＵの処理能力な
どを判断基準として、要求文書を送信元装置で処理可能
かどうかを判断してもよい。

【００４５】

【発明の効果】以上説明したように本発明に係る文書サ
ーバによれば、文書ブラウザからの要求電文を受付手段
で受け付けた場合に、その要求電文の送信元となる文書
ブラウザとの接続関係を第１の識別手段で識別するとと
もに、その要求電文によって要求された文書の属性を第
２の識別手段で識別し、それらの識別結果を基に、送信
手段が送信する文書を制御手段で制御する構成としたの
で、特に、要求電文の送信元となる文書ブラウザが自装
置に属するものである場合に、その文書ブラウザに送信
する文書を適宜制御することで、無効な文書や処理不可
能な文書の送信を禁止したり、処理可能な文書に変更し
て送信したり、ブラウザの処理能力に応じた文書を選択
して送信するなど、要求元の文書ブラウザに対して適切
な文書の送信を行うことが可能となる。また、文書ブラ
ウザ側で処理可能な文書を指定するための情報（アクセ
プトヘッダ等）を伝送する必要がないため、それに伴う
不具合（通信のオーバーヘッド等）を回避することがで
きる。

【図面の簡単な説明】

【図１】本発明の実施形態に係るプリンタ装置のハー
ドウェア構成図である。

【図２】本発明の実施形態に係るプリンタ装置が動作
するシステム構成図である。

【図３】本発明の実施形態に係るプリンタ装置のソフ
トウェア構成図である。

【図４】本発明の実施形態に係るプリンタ装置が送受
信する通信パケット構造の概念図である。

【図５】本発明の第１実施形態に係るＷｅｂサーバ部
の処理手順を示すフローチャートである。

【図６】実施形態におけるＨＴＴＰ要求電文の一例を
示す概念図である。

【図７】実施形態におけるＨＴＭＬ文書の一例を示す
概念図である。

【図８】実施形態におけるＨＴＴＰ肯定応答電文の一
例を示す概念図である。

【図９】実施形態におけるＨＴＭＬ文書の他の例を示
す概念図である。

【図１０】実施形態におけるＨＴＴＰ否定応答電文
（エラー通知文書）の一例を示す概念図である。

【図１１】本発明の第２実施形態に係るＷｅｂサーバ
部の処理手順を示すフローチャート図である。

【図１２】本発明の第３実施形態に係るＷｅｂサーバ
部の処理手順を示すフローチャート図である。

【図１３】ハイパーリンクを含むＨＴＭＬ文書の概念
図である。

【図１４】本発明の第４実施形態に係るＷｅｂサーバ
部の処理手順を示すフローチャート図である。

【符号の説明】

１…ＣＰＵ、２…ブートＲＯＭ、３…ＲＡＭ、４…ハー
ドディスク、５…ディスプレイ、６…タッチパネル、７
…ＬＡＮインターフェース、１０…プリンタ装置、１１
…ＬＡＮ、１２…インターネット、２１…Ｗｅｂサーバ
部、２２…イーサネット制御部、２３…ＴＣＰ／ＩＰプ
ロトコル、２４…Ｗｅｂブラウザ部

Claims

【特許請求の範囲】

【請求項１】文書ブラウザからの要求電文を受け付け
る受付手段と、この受付手段で受け付けた要求電文に従
って文書を送信する送信手段とを有する文書サーバにお
いて、前記受付手段で受け付けた要求電文の要求元の文書ブラ
ウザとの接続関係を識別する第１の識別手段と、前記受付手段で受け付けた要求電文によって要求された
文書の属性を識別する第２の識別手段と、前記第１の識別手段及び前記第２の識別手段の識別結果
に基づいて前記送信手段が送信する文書を制御する制御
手段とを備えることを特徴とする文書サーバ。
【請求項２】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザのア
ドレス情報に基づいて当該文書ブラウザとの接続関係を
識別することを特徴とする文書サーバ。
【請求項３】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザとの
接続関係として、当該文書ブラウザが自装置に属するも
のであるか否かを識別することを特徴とする文書サー
バ。
【請求項４】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザとの
接続関係として、当該文書ブラウザが自装置に一種類以
上の接続手段で接続されているか否かを識別することを
特徴とする文書サーバ。
【請求項５】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザとの
接続関係に加えて、当該文書ブラウザの種別に関する情
報を識別することを特徴とする文書サーバ。
【請求項６】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザとの
接続関係に加えて、当該文書ブラウザの設定情報を識別
することを特徴とする文書サーバ。
【請求項７】請求項１記載の文書サーバにおいて、前記第１の識別手段は、前記要求元の文書ブラウザとの
接続関係に加えて、当該文書ブラウザを搭載する装置の
構成情報を識別することを特徴とする文書サーバ。
【請求項８】請求項１記載の文書サーバにおいて、前記第２の識別手段は、前記要求電文によって要求され
た文書中にタグ表現で記述された情報を基に当該文書の
属性を識別することを特徴とする文書サーバ。
【請求項９】請求項１記載の文書サーバにおいて、前記第２の識別手段は、前記要求電文中の文書の所在を
示す文字列の一部又は全部を基に文書の属性を識別する
ことを特徴とする文書サーバ。
【請求項１０】請求項１記載の文書サーバにおいて、前記制御手段は、前記第１の識別手段及び前記第２の識
別手段の識別結果に基づいて、文書の送信を禁止するこ
とを特徴とする文書サーバ。
【請求項１１】請求項１記載の文書サーバにおいて、前記制御手段は、前記第１の識別手段及び前記第２の識
別手段の識別結果に基づいて、前記送信手段が送信する
文書をエラー通知文書に切り替えることを特徴とする文
書サーバ。
【請求項１２】請求項１記載の文書サーバにおいて、前記制御手段は、前記第１の識別手段及び前記第２の識
別手段の識別結果に基づいて、要求された文書とは異な
る文書を送信することを特徴とする文書サーバ。
【請求項１３】請求項１記載の文書サーバにおいて、前記制御手段は、前記第１の識別手段及び前記第２の識
別手段の識別結果に基づいて、要求された文書を変更す
ることを特徴とする文書サーバ。