【事件の表示】
　特願２００２−１２２４２９「データ送信装置」拒絶査定不服審判事件〔平成１５年１１月　７日出願公開、特開２００３−３１６５６１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯 
 　本願は、平成１４年４月２４日の出願であって、平成２０年１月４日付けで拒絶査定がなされ、これに対して平成２０年２月７日に拒絶査定不服審判が請求されるとともに同年３月７日に手続補正がなされ、当審において、平成２２年７月１２日付けで拒絶理由が通知され、これに対し同年９月９日に手続補正がなされたものである。 
 　 
２．本願発明について 
 　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年９月９日付けの手続補正書によって補正された明細書及び図面の記載から見て、本願の特許請求の範囲の請求項１に記載されたとおりの次のものである。
　
 「データ受信装置に対してデータを送信するデータ送信装置であって、
　前記データ送信装置に関連付けられたデバイスに関するデバイス情報を送信すべき旨の要求を、前記データ受信装置から受信する受信手段と、
　前記デバイス情報の表示形式を規定する複数のスタイルデータを格納する格納手段と、
　前記デバイス情報を取得して、前記デバイス情報のデータ内容自体を規定する本体データを生成する生成手段と、
　前記デバイス情報を前記データ受信装置に向けて送信する送信手段と、
を備え、
　前記送信手段は、少なくとも最初の１回の送信時においては前記本体データと前記スタイルデータとを送信する一方で、デバイス情報の更新送信時には前記両データのうち前記本体データのみを送信し、
　前記送信手段は、前記少なくとも最初の１回の送信時において、前記格納手段に格納された前記複数のスタイルデータの中から、前記データ受信装置での操作入力に基づいて選択されたスタイルデータを送信することを特徴とするデータ送信装置。」
 　 
３．引用刊行物 
（１）当審の拒絶理由通知で引用した特開平６−８７５４８号公報（平成６年３月２９日出願公開。以下、「引用例１」という。）には、図面と共に次の記載がある。 
 　 
（ア）「【０００８】 
 【課題を解決するための手段】そのために、本発明のカット紙印刷装置においては、少なくとも一つのワークステーションとカット紙に印刷する複数のプリンタをローカルエリアネットワークを介して接続し、該ローカルエリアネットワーク全体をファイルサーバによって管理するとともに、各プリンタをプリントサーバによって管理し、ローカルエリアネットワークとのインタフェースを行うようにしている。 
 【０００９】各プリンタに残量算出手段が配設され、残存している積層状態のカット紙の厚みと１枚のカット紙の厚みを検出し、両者から用紙残量を算出する。そして、少なくとも用紙残量を含む各プリンタのステータスが前記ファイルサーバに送信され、前記各プリンタごとの用紙残量は前記ファイルサーバ内に配設された用紙残量レジスタに格納されるとともに表示される。」 
 　 
（イ）「【００２１】 
 【実施例】以下、本発明の実施例について図面を参照しながら詳細に説明する。図３は本発明の第１の実施例を示すカット紙印刷装置における用紙残量検出装置の概略図である。図において、２３は用紙トレイ２４内に積層された用紙である。前記用紙トレイ２４には、スプリング２６によって上方に付勢され、上下に可動な底板２５が設けられる。そして、前記用紙２３は底板２５に載置された状態でスプリング２６によってホッピングローラ２８に押し付けられる。 
 【００２２】前記底板２５には基準部材２７が取り付けられ、用紙トレイ２４内のスタック量すなわち残存している積層状態の用紙２３の厚みを求めるための基準面を形成する。前記基準部材２７は、底板２５の上下の移動に合わせて常に基準面を水平に保つように移動する。一方、前記ホッピングローラ２８に隣接する位置に、前記基準部材２７と対向して精密変位センサ２９が設けられる。また、用紙搬送路３１に沿って、一対の用紙厚検出用ローラ３２，３３、１枚の用紙２３の厚み（以下、「用紙厚」という。）を検出するための用紙厚検出用センサ３４、基準面を形成する基準部材３６及び用紙搬送用のレジストローラ３７，２８が設けられる。 
 【００２３】前記用紙厚検出用ローラ３２と用紙厚検出用センサ３４は一つのユニットを構成しており、上下に移動することができるようになっている。そして、前記ユニットは自重、スプリング等によって常に用紙厚検出用ローラ３３に押し付けられる。一方、図示しないプリンタのメモリ４０内には、用紙切れ時における精密変位センサ２９と基準部材２７間の距離情報があらかじめ固定値として格納されている。そして、前記精密変位センサ２９及び用紙厚検出用センサ３４の各センサ出力は、前記メモリ４０内の距離情報と共に残量算出手段４１に入力される。 
 【００２４】前記用紙トレイ２４内に任意の量の用紙２３を積層し、これをプリンタ本体にセットすると、スプリング２６が用紙トレイ２４の底板２５を持ち上げ、ホッピングローラ２８に押し当てる。その際、積層状態の用紙２３の厚みを検出するための基準部材２７も底板２５と共に上昇する。次に、プリンタ内部のファームウェアの制御によって用紙２３が自動的にプリホッピングされ、用紙厚検出用ローラ３２，３３に送られて停止する。この状態で、精密変位センサ２９は積層状態の用紙２３の厚みを基準面までの距離によって検出し、一方、用紙厚検出用センサ３４は用紙厚を検出する。これらの情報とメモリ４０内に格納された用紙切れ時の距離情報に基づいて、残量算出手段４１が次式によって用紙残量ＲRem を算出する。 
 【００２５】〔用紙残量ＲRem 〕＝〔（精密変位センサ２９が検出した距離）−（用紙切れ時の距離情報）〕÷〔用紙厚〕 
 前記プリホッピングは各用紙２３ごとに行われる。また、この時、用紙厚の検出精度を高くするために、プリホッピング直後の検出値をそのまま使用するのではなく、印刷動作中すなわちレジストローラ３７，３８の先に用紙２３が搬送されて、用紙２３の後端が用紙厚検出用ローラ３２，３３に至るまでの間、該用紙厚検出用センサ３４は用紙厚を複数回検出（サンプリング）するようになっている。 
 【００２６】図４は用紙厚の１枚当たりの平均値を算出する動作を示すフローチャートである。 
 ステップＴ１ プリホッピング時において前記用紙厚検出用センサ３４（図３）の検出値すなわち用紙厚をレジスタＲ0 に格納する。 
 ステップＴ２ 印刷動作を開始する。 
 ステップＴ３ ２回目に用紙厚検出用センサ３４が検出した用紙厚をレジスタＲ1 に格納する。 
 ステップＴ４ ３回目に用紙厚検出用センサ３４が検出した用紙厚をレジスタＲ2 に格納する。 
 ステップＴ５ ｎ回目に用紙厚検出用センサ３４が検出した用紙厚をレジスタＲn-1 に格納する。２回目からｎ回目までの用紙厚の検出は、用紙２３が用紙厚検出用ローラ３２，３３に至るまでの間に行う。 
 ステップＴ６ ステップＴ３〜Ｔ５で検出した各用紙厚の平均値を算出する。 
 【００２７】このようにして、用紙厚の１枚当たりの平均値を得ることができるが、更に検出精度を高くするため、用紙トレイ２４のすべての用紙２３について１枚当たりの平均値を算出し、全用紙当たりの平均値を算出するようになっている。図５は用紙厚の全用紙当たりの平均値を算出する平均値算出装置のブロック図である。 
 【００２８】図において、３２，３３は用紙厚検出用ローラ、３４は用紙厚検出用センサ、４２は現在までの用紙厚の平均値を格納するための平均値格納レジスタ、４３は用紙厚を検出した用紙２３が何枚目のものであるかの情報、すなわちページ数の情報を格納するページ数カウントレジスタ、４４は用紙厚の１枚当たりの平均値を算出するページ内平均値算出部である。該ページ内平均値算出部４４内においては、図４に示すような処理が行われる。 
 【００２９】また、４５は用紙厚の全用紙当たりの平均値を算出する全ページ平均値算出部である。該全ページ平均値算出部４５で算出された平均値は、図３の残量算出手段４１に対して出力される。このように、用紙トレイ２４をプリンタ本体にセットしてから次の用紙切れになるまでの間、各用紙２３の用紙厚を現在までの用紙厚の平均値に加え、現在の平均値を算出する。この時、単に現在までの用紙厚の平均値と、新たに検出した用紙厚を加えて２で割っても正確な平均値にはならない。そこで、前記ページ数カウントレジスタ４３を設け、全ページ平均値算出部４５において正確な平均値を算出するようになっている。 
 【００３０】このように、全ページ平均値算出部４５で算出された平均値は、次段の残量算出手段４１に対して出力される。そして、前記ページ数カウントレジスタ４３は各ページの印刷を開始するたびにインクリメントコマンドによってインクリメントされる。次に、このようにして算出した用紙残量ＲRem を、プリンタからプリントサーバに通知する方法について説明する。」 
 　 
（ウ）「【００３１】ローカルエリアネットワークへのプリンタの接続形態にはいくつかの種類がある。この接続形態の差によって、プリントジョブを制御するプリントサーバにプリンタのステータスを送信する手段が異なる。図６はプリンタがネットワークインタフェースを内蔵する場合の接続例を示す図である。 
 【００３２】図において、１１はファイルサーバ、１２はワークステーション、１６はプリンタ、５１は該プリンタ１６に内蔵されたネットワークインタフェースである。この場合、図示しないプリントサーバがプリンタ１６のネットワークインタフェース５１の内部にある場合と、ファイルサーバ１１の内部にあってプリンタ１６をリモートコントロールする場合がある。前記プリンタ１６とネットワークインタフェース５１は、内部のデータ／アドレスバスを介して接続されている。したがって、プリントサーバがネットワークインタフェース５１の内部にある場合は、ネットワークインタフェース５１に対して用紙残量ＲRem を通知するのに特別な手段を必要としない。すなわち、前記用紙残量ＲRem を含むステータスを、ローカルエリアネットワークのプロトコルに合うパケットに組んで一定間隔で定期的にファイルサーバ１１に送信すればよい。 
 【００３３】また、プリントサーバがファイルサーバ１１の内部にある場合は、プリントサーバ１１がステータスの送信を要求するコマンド（以下、「ステータス送信要求コマンド」という。）を一定間隔でプリンタ１６に送信し、これに対しプリンタ１６のネットワークインタフェース５１は用紙残量ＲRem を含むステータスをプロトコルに合うパケットに組んでプリントサーバに送信する。そして、プリントサーバは、受信したステータスをファイルサーバ１１に転送する。この時、ファイルサーバ１１とプリントサーバは同じマシンの中にあるので、ステータスの転送はソフト上で行われる。 
 【００３４】図６の接続例においては、プリンタ１６がネットワークインタフェース５１を内蔵しているため、プリンタ１６をローカルエリアネットワークに直接接続することができる。この接続形態のほか、シリアルポートやパラレルポートを使用してプリンタ１６をローカルエリアネットワークに接続する接続形態もある。この場合、プリンタ１６はローカルエリアネットワークに直接接続することはできず、ワークステーション１２、インタフェースアダプタ、ファイルサーバ１１等のノードのシリアルポートやパラレルポートに接続する。 
 【００３５】図７はプリンタをワークステーションのシリアルポートを介してローカルエリアネットワークに接続した接続例を示す図である。図において、１１はファイルサーバ、１２はワークステーション、１６はプリンタである。該プリンタ１６はシリアルインタフェース（Ｉ／Ｆ）を介してワークステーション１２のシリアルポートに接続され、ワークステーション１２の内部に図示しないプリントサーバが設けられる。 
 【００３６】そして、コマンド、ステータス等の送受信は双方向通信で行う。すなわち、プリントサーバはステータス送信要求コマンドを一定間隔でプリンタ１６に送信する。これを受けてプリンタ１６は、あらかじめ決められたコード体系に基づいて、用紙残量ＲRem を含む各ステータスをシリアルにプリントサーバに対して送信する。そして、該プリントサーバはステータスをローカルエリアネットワークを介してファイルサーバ１１に送信する。 
 【００３７】また、該ファイルサーバ１１の内部にプリントサーバが設けられ、該プリントサーバによってプリンタ１６がリモートコントロールされる場合も同様に、コマンド、ステータス等の送受信は双方向通信で行う。ただし、プリンタ１６が接続されたノード、すなわちワークステーション１２にプリントサーバはないが、ローカルエリアネットワークとのインタフェースを行うための処理はバックグラウンドで実行される。 
 【００３８】そして、ファイルサーバ１１の内部のプリントサーバは、ステータス送信要求コマンドを送信する。該ステータス送信要求コマンドは、プリンタ１６が接続されたノードすなわちワークステーション１２に対して送信される。そして、前記ステータス送信要求コマンドは、前記ワークステーション１２においてあらかじめ決められたコマンドに置き換えられ、シリアルポートからプリンタ１６に送信される。 
 【００３９】これに対して、プリンタ１６はあらかじめ決められたコード体系に基づいて、用紙残量ＲRem を含む各ステータスをシリアルでワークステーション１２に送信する。該ワークステーション１２は、ステータスをローカルエリアネットワークのプロトコルに合うパケットに組んで、ファイルサーバ１１の内部のプリントサーバに送信する。 
 【００４０】そして、該プリントサーバは同じマシンの中のファイルサーバ１１に対してステータスを転送する。図８はプリンタをインタフェースアダプタのシリアルポートを介してローカルエリアネットワークに接続した接続例を示す図である。図において、１１はファイルサーバ、５３はインタフェース（Ｉ／Ｆ）アダプタ、１６はプリンタである。該プリンタ１６はシリアルインタフェースを介してインタフェースアダプタ５３のシリアルポートに接続され、インタフェースアダプタ５３の内部に図示しないプリントサーバが設けられる。 
 【００４１】この場合も、プリントサーバはステータス送信要求コマンドを一定間隔でプリンタ１６に送る。これを受けてプリンタ１６は、あらかじめ決められたコード体系に基づいて、用紙残量ＲRem を含む各ステータスをシリアルにインタフェースアダプタ５３の内部のプリントサーバに対して送信する。そして、該プリントサーバはステータスをローカルエリアネットワークを介してファイルサーバ１１に送信する。 
 【００４２】図９はプリンタをファイルサーバのシリアルポートを介してローカルエリアネットワークに接続した接続例を示す図である。図において、１１はファイルサーバ、１２はワークステーション、１６はプリンタである。該プリンタ１６はシリアルインタフェースを介してファイルサーバ１１のシリアルポートに接続され、ファイルサーバ１１の内部に図示しないプリントサーバが設けられる。 
 【００４３】この場合、図７の接続例と同様に、コマンド、ステータス等の送受信は双方向通信で行う。そして、前記ファイルサーバ１１の内部のプリントサーバは、ステータス送信要求コマンドを一定間隔でプリンタ１６に対し送信する。これに対して、プリンタ１６はあらかじめ決められたコード体系に基づいて、用紙残量ＲRem を含む各ステータスをシリアルでファイルサーバ１１の内部のプリントサーバに送信する。該プリントサーバは同じマシンの中のファイルサーバ１１に対してステータスを転送する。 
 【００４４】図１０はプリンタをワークステーションのパラレルポートを介してローカルエリアネットワークに接続した接続例を示す図、図１１はプリンタをインタフェースアダプタのパラレルポートを介してローカルエリアネットワークに接続した接続例を示す図、図１２はプリンタをファイルサーバのパラレルポートを介してローカルエリアネットワークに接続した接続例を示す図である。 
 【００４５】図において、１１はファイルサーバ、１２はワークステーション、１６はプリンタ、５３はインタフェースアダプタである。パラレルポートによる接続も基本的にはシリアルポートの接続と同じである。ただし、現在多く使用されているパラレルインタフェースであるセントロニクスの仕様では、双方向通信を行うことができない。ところが、プリンタ１６の用紙残量ＲRem を含むステータスをファイルサーバ１１に送信するためには、双方向通信は必要不可欠である。そこで、本実施例においては、「Parallel Port Extended Mode 」（ＩＢＭ社）という双方向パラレルポートの仕様を使用した(IBMPS/2 Model 80 Technical Reference Manual 4-171 参照）。この仕様によって、パラレルインタフェースにおいてもシリアルインタフェースと同様に双方向通信が可能となる。 
 【００４６】以上のように各接続形態ごとに異なる方法でファイルサーバ１１に送信された各ステータスのうち用紙残量ＲRem は、ファイルサーバ１１内に各プリンタ１６ごとに設けられた図示しないプリンタステータスファイル内の用紙残量レジスタに書き込まれる。また、その他のステータス（用紙サイズやプリンタ１６のタイプなど）もこのプリンタステータスファイル内の該当するレジスタに書き込まれる。 
 【００４７】次に、ファイルサーバ１１内の各プリンタステータスファイルに格納された用紙残量ＲRem 等の情報を確認するための手段について説明する。ユーザがプリントジョブの実行前に、あらかじめ各プリンタ１６の用紙サイズ、用紙残量ＲRem を得ようとする場合、ユーザは、ワークステーション１２において用紙残量ＲRem を表示させるコマンドをローカルエリアネットワークのプロトコルに合うパケットに組み、ファイルサーバ１１に対して送信する。これを受けたファイルサーバ１１は、該当するプリンタ１６のプリンタステータスファイル内の用紙残量レジスタから用紙残量ＲRem を読み出し、ローカルエリアネットワークを介して使用中のワークステーション１２に送信して表示させる。これによって、ユーザはいつでもプリンタ１６の状況を確認することができる。」 
 　 
（エ）「【００６６】次に、複数台のワークステーション１２で１台のプリンタを共用する場合のカット紙印刷装置について説明する。図２１は本発明の第４の実施例を示すカット紙印刷装置におけるプリンタのブロック図、図２２は本発明の第４の実施例を示すカット紙印刷装置に使用されるディスプレイの表示例を示す図、図２３は本発明の第４の実施例を示すカット紙印刷装置のブロック図、図２４は本発明の第４の実施例におけるカット紙印刷装置のワークステーション側の動作を示すフローチャート、図２５は本発明の第４の実施例におけるカット紙印刷装置のプリンタ側の動作を示すフローチャートである。 
 【００６７】図において、１２はワークステーション、１２ａはディスプレイ、１６はプリンタ、４１は残量算出手段、６０はＣＰＵ、６１は制御プログラムを格納したＲＯＭ、６２はＲＡＭ、６３は前記ワークステーション１２とのインタフェースを行うインタフェース制御部、６４はＩ／Ｏ制御部、６５は前記プリンタ１６の操作を行う操作部、６６は印刷部、６８は図３で説明した用紙残量検出装置である。 
 【００６８】また、図２２のａはモニタ画面、ｂはアプリケーション表示領域、ｃは印刷制御ウィンド、ｄは該印刷制御ウィンドｃにおけるプリンタ１６のステータス表示領域を示す。この場合、ワークステーション１２がプリンタ１６に用紙残量ＲRem を問い合わせる命令（以下、「用紙残量問合せ命令」という。）を送信すると、プリンタ１６は用紙残量検出装置６８を起動し用紙残量ＲRem を算出する。この動作は、アプリケーションプログラム上で作業をしている間でも、ワークステーション１２の印刷装置制御プログラムを起動させることによって、印刷制御ウィンドｃをオープンさせて実行することができる。 
 【００６９】そして、算出された用紙残量ＲRem はワークステーション１２に送信され、ディスプレイ１２ａに表示される。 
 ステップＳ６１ ワークステーション１２からプリンタ１６に用紙残量問合せ命令を送信する。 
 ステップＳ６２ プリンタ１６からの応答を待機する。 
 ステップＳ６３ ワークステーション１２のディスプレイ１２ａにおいて、更に制御ウィンドｃの中にステータス表示領域ｄを設け、該ステータス表示領域ｄにプリンタ１６から送信された用紙２３（図３）の用紙残量ＲRem を表示する。 
 ステップＳ６４ プリンタ１６が用紙残量問合せ命令を受信する。 
 ステップＳ６５ 用紙残量検出装置６８を起動する。プリンタ１６のＣＰＵ６０はインタフェース制御部６３を介して用紙残量問合せ命令を受けると、Ｉ／Ｏ制御部６４を介して印刷部６６に対して用紙残量検出命令を出力する。 
 ステップＳ６６ 用紙残量ＲRem の検出が終了するまで待機する。 
 ステップＳ６７ 前記印刷部６６の残量算出手段４１は用紙残量検出装置６８を起動させ、印刷部６６の用紙残量ＲRem を算出する。算出された用紙残量ＲRemは、Ｉ／Ｏ制御部６４を介してＣＰＵ６０に通知され、該ＣＰＵ６０はインタフェース制御部６３を介してワークステーション１２に用紙残量ＲRem を送信する。 
 【００７０】このように、ディスプレイ１２ａに用紙残量ＲRem が表示されることによって、ユーザは用紙残量ＲRem を確認するためにプリンタ１６が設置されている場所まで行く必要がなくなる。なお、印刷制御ウィンドｃをクローズすれば、アプリケーション表示領域ｂでの作業を継続して行うことができる。次に、単にワークステーション１２のディスプレイ１２ａに用紙残量ＲRem を表示するだけでなく、用紙不足枚数又は用紙余裕枚数を表示することができるようにした第５の実施例について説明する。」 
　
　以上から引用例１には次の発明（以下、「引用発明」という。）が記載されている。 
　「少なくとも一つのワークステーション１２と複数のプリンタ１６をローカルエリアネットワークを介して接続し、該ローカルエリアネットワーク全体をファイルサーバ１１によって管理するとともに、各プリンタ１６をプリントサーバ１９によって管理し、 
　各プリンタ１６に残量算出手段が配設され、残存している積層状態のカット紙の厚みと１枚のカット紙の厚みを検出し、両者から用紙残量を算出し、
　少なくとも用紙残量を含む各プリンタ１６のステータスが前記ファイルサーバ１１に送信され、前記各プリンタ１６ごとの用紙残量は前記ファイルサーバ１１内に配設された用紙残量レジスタに格納されるものであって、 
　プリントサーバ１９がステータスの送信を要求するコマンドを一定間隔でプリンタ１６に送信し、これに対してプリンタ１６のネットワークインタフェースは用紙残量ＲRem を含むステータスをプロトコルに合うパケットに組んでプリントサーバ１９に送信し、プリントサーバ１９は、受信したステータスをファイルサーバ１１に転送し、 
　ファイルサーバ１１に送信された各ステータスのうち用紙残量ＲRem は、ファイルサーバ１１内に各プリンタ１６ごとに設けられたプリンタステータスファイル内の用紙残量レジスタに書き込まれ、その他のステータス（用紙サイズやプリンタのタイプなど）もこのプリンタステータスファイル内の該当するレジスタに書き込まれ、 
　ユーザがプリントジョブの実行前に、あらかじめ各プリンタ１６の用紙サイズ、用紙残量ＲRem を得ようとする場合、ユーザは、ワークステーション１２において用紙残量ＲRem を表示させるコマンドをローカルエリアネットワークのプロトコルに合うパケットに組み、ファイルサーバ１１に対して送信し、これを受けたファイルサーバ１１は、該当するプリンタ１６のプリンタステータスファイル内の用紙残量レジスタから用紙残量ＲRem を読み出し、ローカルエリアネットワークを介して使用中のワークステーション１２に送信して表示させる、 
システム。」 
 　 
（２）当審の拒絶理由通知で引用した特開２００１−７８４０号公報（平成１３年１月１２日出願公開、以下「引用例２」という。）には図面とともに次の記載がある。 
 　 
（オ）「【００３４】 
 【作用】本発明を具現化した受信システムによれば、コンピュータ言語で記述されたデジタル・データとは分離してスタイル・シートを蓄積し管理することができる。この結果、スタイル・シートを配信データ本体に逐一付加して送信する必要がなくなり、送信データのサイズを削減することができる。特に、スタイル・シートが高機能化し肥大化した場合には、通信負荷軽減の効果が絶大である。スタイル・シートのみの再利用環境を実現することもできる。ここで言うコンピュータ言語は、例えば、任意に定義可能なタグを使用するマークアップ言語を指し、その一例はＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）言語である。」 
 　 
（カ）「【００８２】次に、衛星データ受信システム１０におけるＸＭＬ文書の受信処理手順について説明する。 
 【００８３】デジタル衛星放送システムでは、図５に示すように、まず、放送局１から放送衛星５に対してコンテンツが送信され、衛星５から受信局１０に向かって転送される。 
 【００８４】放送のコンテンツは、ＸＭＬ形式で記述された文書本体（但し、ＤＴＤ文書を含んでもよい）と、ＸＳＬ形式で記述されたスタイル・シートからなる。ＸＭＬ文書本体には、どのように表示されるかを指定するスタイル情報以外の情報が包含されている（例えば、テキストと、これに利用される画像オブジェクトなどのマルチメディア・コンテンツなど）。 
 【００８５】衛星放送のように一方向性の送信環境では、標準的なＸＭＬ言語で記述されたコンテンツは、使用するスタイル・シートを限定しない限り、ＸＭＬ文書とスタイル・シートが同梱された形態で送信される。 
 【００８６】受信システム１０側では、受信データのうち必要なものは、ＨＤＤ２９／６２のような大容量記憶装置に一旦蓄積される。受信データが、ＸＭＬなどのマークアップ言語形式の文書である場合、受信システム１０内で処理され、ＴＶなどの表示装置１８／６８に画面出力される。 
 【００８７】また、本実施例では、放送衛星５を介して送信されるコンテンツは、ＸＭＬ文書とＸＳＬ文書が同梱されたもの以外に、ＸＭＬ文書本体のみ、ＸＳＬ文書のみというケースも想定している。また、ＸＳＬ文書は、放送以外による配信・配布の形態、例えばインターネットのようなネットワーク経由でのファイル・ダウンロードや、ＦＤやＣＤ−ＲＯＭなどの可搬型記憶媒体に担持されて供給を受けることができる。 
 【００８８】本実施例に係る受信システム１０は、供給されたＸＭＬ文書とＸＳＬ文書を分離して蓄積する。すなわち、これら供給された文書・ファイルを蓄積するＨＤＤ２９／６２には、ＸＭＬ文書（但し、ＤＴＤ文書を含んでもよい）のみを保存・管理する文書本体保存部８０と、スタイル・シートとしてのＸＳＬ文書のみを保存・管理するスタイル・シート保存部９０が設けられている。 
 【００８９】前述したように、スタイル・シートの高機能化・高付加価値化が進み、スタイル・シートすなわちＸＳＬ文書自体が、文書本体と同様に著作物性を具備するようになってきている。したがって、スタイル・シートの無断使用や不正利用を排除するためには、スタイル・シート保存部９０はセキュリティ管理された記憶領域であることが好ましい。 
 【００９０】本実施例では、スタイル使用権鍵を導入することで、スタイル・シートすなわちＸＳＬ文書の使用を制限するようにしているが、この点は後に詳解する。 
 【００９１】次に、受信システム１０におけるスタイル・シートの利用手順について、図６を参照しながら説明する。 
 【００９２】上述したように、受信システム１０は、文書本体すなわちＸＭＬ文書と同梱で、あるいは文書本体とは分離して、スタイル・シートを獲得することができる。文書本体は、必ずしもＸＭＬ文書には限定されず、ＳＧＭＬ（ＳｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＨＴＭＬなど他のマークアップ言語形式であってもよい。ＸＭＬ文書が、例えばＴＶ放送などに適用され、他のマルチメディア・コンテンツと共に動作してコンテンツのプレゼンテーションを行う場合には、マルチメディア・コンテンツも文書本体に含むものとする。また、スタイル・シートはＸＳＬ形式で記述された、ＸＭＬ文書本体の表現形式を規定した文書である。 
 【００９３】文書本体は、ＸＭＬ文書の他にＤＴＤ文書を含んでいてもよい。文書本体は、ＸＭＬパーサと呼ばれる構文解析プログラムでパーシング処理される。そして、パーシングされた文書オブジェクトは、スタイル・シートすなわちＸＳＬ文書と一緒にＸＳＬプロセッサに渡される。 
 【００９４】ＸＳＬプロセッサは、ＸＳＬ文書の記述に従って、文書オブジェクトを描画処理可能なデータ形式に変換して、スタイルに応じた文書を生成する。例えば同一の文書本体に適用するスタイル・シートを換えることで、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書、カスタムＡ社文書、カスタムＢ社文書、番組紹介文書、マルチメディア・コンテンツなど、様々な描画可能形式の文書が作成される。 
 【００９５】ＨＴＭＬ文書とは、米Ｎｅｔｓｃａｐｅ社の”Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ”や米Ｍｉｃｒｏｓｏｆｔ社の”Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ”などの、いわゆるＨＴＭＬブラウザを用いて描画可能な文書である。また、カスタムＡ社文書やカスタムＢ社文書は、Ａ社及びＢ社の各々が提供するカスタム・ブラウザで描画可能な形式の文書であると理解されたい。 
 【００９６】また、ＸＳＬプロセッサによる文書変換処理によれば、上記以外に、各番組に対応した番組紹介用の文書に変換して表示することが可能である。 
 【００９７】図７には、元の番組情報が同じであっても、スタイル・シートに応じて表示形態が大きく相違する例を図解している。同図に示す例では、番組Ａ及び番組Ｂの紹介情報はそれぞれ同一な形式であるとする。このような場合、各々についての元の文書に適用するスタイル・シートを変えて、異なる処理を行うことで、各番組における紹介方法を異ならせることができる。 
 【００９８】図７に示した表示は、ＴＶなどの表示装置に対して行われるものである。但し、本発明を実現する上で、表示装置は特に限定されない。すなわち、スタイルの指定において、表示対象をテレビや携帯端末に指定することができる。また、各々の装置が持つ表示機能に合わせてスタイルを選択することで、より効果的な表示を実現することができる。 
 【００９９】放送で実現されている電子番組ガイド（ＥＰＧ）は、各番組毎に専用の番組情報を送信するようになっている。また、その送信方法としては、専用の送信チャンネルを使用する方法や、テレビ放送におけるＶブランクを使用する方法などがある。このため、従来は、番組情報の形式は放送サービスの開始時に決定され、その表示方法も受信機によって固定的であった。 
 【０１００】これに対し、本実施例に従ってスタイル・シートを利用すると、今までは固定的であった番組情報の表示を柔軟に変更することが可能となる。また、スタイル・シートは、放送する番組情報に対応させて随時更新することができるので、番組情報そのものを簡単に変更することができる。また、番組毎、サービス提供者毎に番組ガイドの定義を変更することも可能である。 
 【０１０１】図５を用いて説明したように、本実施例に係る受信システム１０は、スタイル・シート保存部９０を装備している。したがって、受信システム１０は、放送コンテンツを描画可能形式に変換するためのスタイル・シートを、ＸＭＬ文書本体とは分離して利用することができる。 
 【０１０２】さらに、単一のスタイル・シートを複数のＸＭＬ文書間で共用したり、あるいは、複数のスタイル・シートを複数のＸＭＬ文書間で共用することも可能である。 
 【０１０３】本発明によれば、放送コンテンツすなわちＸＭＬ文書本体にスタイル・シートを添付せずに済む。その反面、各ＸＭＬ文書に対して適用すべきスタイル・シートを識別する情報が必要となってくる。 
 【０１０４】そこで、本実施例では、各スタイル・シートに固有の識別子（スタイルＩＤ）を定義してスタイル・シートに付加することとした。このスタイルＩＤによって、スタイル・シート保存部９０に格納されたスタイル・シートを好適に管理することができる（例えば、スタイルＩＤを指定するだけで、所望のスタイル・シートを容易に取り出すことができる）。 
 【０１０５】また、放送コンテンツすなわちＸＭＬ文書本体側でも、コンテンツＩＤを定義する必要がある。スタイルＩＤやコンテンツＩＤは、世界規模で一元管理されていることが好ましい。このような場合、コンテンツＩＤとスタイルＩＤの組み合わせを示すだけで、表示対象となるコンテンツ本体とその表示形態の両方を指定することができる。」 
　
　以上から、引用例２には次の公知技術が記載されている。 
（ａ）データを転送するときに文書本体のみ送り受信側においてスタイル・シートを適用すること。 
（ｂ）スタイル・シートと文書本体を同梱して転送すること。 
（ｃ）スタイル・シートのみを転送すること。 
（ｄ）文書本体とスタイル・シートを分離してスタイル・シートに固有の識別子（スタイルＩＤ）を定義して蓄積管理することにより、スタイル・シートを配信データ本体に逐一付加して送信する必要がなくなり、送信データのサイズを削減できること。 
 　 
（３）当審の拒絶理由通知で引用した特開２００１−４３０６１号公報（平成１３年２月１６日出願公開、以下「引用例３」という。）には図面とともに次の記載がある。 
 　 
（キ）「【要約】 
 【目的】 所望のレイアウトで画像の検索結果を表示する。 
 【構成】 サーバ10には，複数種類のレイアウトを示すスタイル・シートが格納されている。クライアント・コンピュータ１のユーザは，所望のレイアウトをもつスタイル・シートを選択する。その後，クライアント・コンピュータ１のユーザがサーバ10に検索のためにアクセスしたときには，選択されたスタイル・シートで検索結果を表示する。サーバ10にアクセスする度に所望のスタイル・シートを選択する必要がない。」 
 　 
 （ク）「【００３７】さらに，サーバ10にアクセスできるユーザの情報を記憶しているユーザ情報記憶装置26およびユーザ情報記憶装置26に記憶されているユーザ情報を読みだすための，ユーザ情報記憶装置26にユーザ情報を記憶させるためのユーザ情報制御装置25が含まれている。また，サーバ10には，レイアウトを規定するためのスタイル・シートを記憶するスタイル・シート記憶装置28およびスタイル・シート記憶装置28に記憶されているスタイル・シートを読みだすための，スタイル・シート記憶装置28にスタイル・シートを記憶するためのスタイル・シート制御装置27が含まれている。 
 【００３８】図１においては，サーバ10にデータベース22，画像ファイル装置24，ユーザ情報記憶装置26およびスタイル・シート記憶装置28が含まれているが，外部に設けるようにしてもよい。 
 【００３９】図２は，ユーザ情報記憶装置26に記憶されているユーザ情報の一例を示している。 
 【００４０】サーバ10にアクセスできるユーザごとに次に示すユーザ情報がユーザ情報記憶装置26に格納されている。 
 【００４１】ユーザＩＤ；ユーザを識別するためのデータである。 
 【００４２】ユーザ名；ユーザがネットワークで使用する名前である。 
 【００４３】パスワード；ユーザがサーバ10にアクセス権限があるかどうかを確認するためのものである。 
 【００４４】ユーザ・フルネーム；ユーザの本名をフルネームで示すものである。 
 【００４５】ユーザ説明；ユーザが管理者か，副管理者か，一般ユーザかを示すものである。 
 【００４６】システム権限；ユーザ情報（ここではスタイル・シート以外の情報）を書き換える権限があるかどうかを示すものである。 
 【００４７】登録権限；画像ファイル装置24に格納されているデータおよびデータベース22に格納されているデータを書き換える権限があるかどうかを示すものである。 
 【００４８】スタイル・シート後述するようにユーザが選択したスタイル・シートを識別するものである。ユーザが選択していないときには，所定のスタイル・シートを表すデータが格納されている。 
 【００４９】図３は，スタイル・シートを選択する処理手順を示すフローチャートである。 
 【００５０】この図は，ユーザＩＤおよびパスワードにより正当な権限あるユーザによりサーバ10にアクセスされたことが前提とされている。 
 【００５１】クライアント・コンピュータ１の表示装置５には，設定モードの選択画像が表示されている。様々な設定モードがあり，その様々な設定モードの中の一つのモードがスタイル・シート選択モードである。 
 【００５２】クライアント・コンピュータ１のユーザによって設定モードが選択されると（ステップ31でＹＥＳ），設定画像の要求が発生し（ステップ32），その要求を示すデータがクライアント・コンピュータ１からサーバ10に送信される。 
 【００５３】サーバ10において，設定画像の要求を示すデータが受信されると（ステップ51），設定画像に用いられる画像が画像ファイル装置24から読みだされレイアウト制御装置20に与えられる。また，設定画像を示すスタイル・シート28がスタイル・シート記憶装置28から読みだされ，レイアウト制御装置20に与えられる。レイアウト制御装置28においてスタイル・シートに画像が合成され設定画像を表すデータが生成される（ステップ53）。生成された設定画像を表すデータは，サーバ10からクライアント・コンピュータ１に送信される。 
 【００５４】クライアント・コンピュータ１において，サーバ10から送信された設定画像を表すデータが受信され，表示装置５に与えられる。設定画像が表示装置５の表示画面上に表示される（ステップ33）。 
 【００５５】設定画像において様々な設定を選択することができる。スタイル・シートの選択が選ばれると（ステップ34でＹＥＳ），スタイル・シート選択画像の要求が発生する（ステップ35）。発生したスタイル・シートの選択画像の要求は，クライアント・コンピュータ１からサーバ10に送信される。 
 【００５６】サーバ10において，クライアント・コンピュータ１から送信されたスタイル・シートの選択画像の要求が受信されると（ステップ54），スタイル・シート選択画像を生成するための画像データが画像ファイル装置24から読みだされ（ステップ55），レイアウト制御装置20に与えられる。また，スタイル・シート選択画像を生成するためのスタイル・シートがスタイル・シート記憶装置28から読みだされる。読みだされたスタイル・シートは，レイアウト制御装置20に与えられる。レイアウト制御装置20において，スタイル・シート選択画像を表すデータが生成される（ステップ56）。生成されたスタイル・シート選択画像を表すデータは，サーバ10からクライアント・コンピュータ１に送信される。 
 【００５７】クライアント・コンピュータ１において，スタイル・シート選択画像を表すデータが受信されると，そのスタイル・シート選択画像を表すデータは，表示装置５に与えられる。表示装置５の表示画面にスタイル・シート選択画像が表示される（ステップ36）。 
 【００５８】図４は，スタイル・シート選択画像の一例である。 
 【００５９】この実施例においては，スタイル・シートは４種類ある。もちろん，さらに多くのスタイル・シートを規定してもよいし，少ないスタイル・シートを規定してもよい。 
 【００６０】領域61には，タイプＡのスタイル・シートが表されている。領域62は，タイプＡのスタイル・シートを選択するときにクライアント・コンピュータ１のユーザによってチェックされる領域である。 
 【００６１】領域63には，タイプＢのスタイル・シートが表されている。領域64は，タイプＢのスタイル・シートを選択するときにクライアント・コンピュータ１のユーザによってチェックされる領域である。 
 【００６２】領域65には，タイプＣのスタイル・シートが表されている。領域66は，タイプＣのスタイル・シートを選択するときにクライアント・コンピュータ１のユーザによってチェックされる領域である。 
 【００６３】領域67には，タイプＢのスタイル・シートが表されている。領域68は，タイプＤのスタイル・シートを選択するときにクライアント・コンピュータ１のユーザによってチェックされる領域である。 
 【００６４】スタイル・シート選択画像には，さらに，チェックされたスタイル・シートを確定するときにユーザによってクリックされる確認領域71およびキャンセルするときにユーザによってクリックされるキャンセル領域72が含まれている。 
 【００６５】領域62，64，66および68のうちいずれかの領域をチェックすることにより所望のスタイル・シートが選択される（ステップ37）。その後ユーザによつて確認領域71がクリックされると（ステップ38でＹＥＳ），ユーザによって選択されたスタイル・シートを識別するためのデータがクライアント・コンピュータ１からサーバ10に送信される。 
 【００６６】サーバ10においてクライアント・コンピュータ１から送信された選択されたスタイル・シートを示すデータが受信されると（ステップ57），選択されたスタイル・シートを識別するためのデータがユーザに対応してユーザ情報に格納される（ステップ58）。 
 【００６７】その後，クライアント・コンピュータ１のユーザがサーバ10にアクセスし，画像データベース検索を行い得られる検索結果は，選択されたスタイル・シートのレイアウトで表示されることとなる。ユーザの所望のレイアウトで画像検索の結果を表示させることができる。しかも，ユーザが選択されたスタイル・シートは，ユーザ情報として登録されるので，次にアクセスしたときに再びスタイル・シートを選択する必要がない。」 
 　 
　以上から、引用例３には次の公知技術が記載されている。 
（ｅ）サーバにスタイル・シートを複数記憶しておき、ユーザはスタイル・シートを選択でき、ユーザが検索のためにサーバにアクセスしたときに、サーバは検索結果と選択されたスタイル・シートを出力すること。 
 　 
４．対比 
　本願発明と引用発明を対比する。 
（１）引用発明の「ワークステーション１２」は、本願発明の「データ受信装置」に相当する。 
（２）引用発明の「ファイルサーバ１１」は、本願発明の「データ送信装置」に相当する。 
（３）引用発明の「プリンタ１６」は、本願発明の「デバイス」に相当する。 
（４）引用発明の「ステータス」はプリンタの用紙残量や用紙サイズに関する情報であり、これらの情報や「ステータス」は、本願発明の「デバイス情報」に相当する。 
（５）引用発明のファイルサーバ１１は、ワークステーション１２に対してデータを送信するファイルサーバ１１であり、そしてこのファイルサーバ１１は、自装置に関連づけられたプリンタ１６に関するステータスを送信すべき旨の要求を、ワークステーション１２から受信しているから、本願発明と引用発明とは、 
「データ受信装置に対してデータを送信するデータ送信装置であって、 
　前記データ送信装置に関連付けられたデバイスに関するデバイス情報を送信すべき旨の要求を、前記データ受信装置から受信する受信手段」 
 を有する点で一致する。 
（６）引用発明のファイルサーバ１１は、ステータスを取得して、用紙残量をワークステーション１２に向けて送信している。ワークステーションに送信する用紙残量はデバイス情報といえるものであるから、本願発明と引用発明とは、 
　「デバイス情報を取得して、前記デバイス情報のデータを生成する生成手段と、前記デバイス情報を前記データ受信装置に向けて送信する送信手段と」 
を有する点で一致する。 
　 
　以上のことから、本願発明と引用発明との間には次の一致点及び相違点がある。 
 　 
（一致点） 
　「データ受信装置に対してデータを送信するデータ送信装置であって、 
　前記データ送信装置に関連付けられたデバイスに関するデバイス情報を送信すべき旨の要求を、前記データ受信装置から受信する受信手段と、 
　前記デバイス情報を取得して、前記デバイス情報のデータを生成する生成手段と、 
　前記デバイス情報を前記データ受信装置に向けて送信する送信手段と、 
 を備えたデータ送信装置。」 
 　 
（相違点１） 
　本願発明１は、「デバイス情報の表示形式を規定する複数のスタイルデータを格納する格納手段」を備えているのに対して、 
　引用発明には、デバイス情報の表示形式を規定する複数のスタイルデータとその格納手段について明記されていない点。 
 　 
（相違点２） 
　本願発明は、「デバイス情報のデータ内容自体を規定する本体データを生成する生成手段」を備えているのに対して、引用発明は「本体データ」を生成していない点。 
 　 
（相違点３） 
　本願発明の送信手段は、「少なくとも最初の１回の送信時においては前記本体データと前記スタイルデータとを送信する一方で、デバイス情報の更新送信時には前記両データのうち前記本体データのみを送信し」ているのに対し、 
　引用発明には、本願発明のような本体データとスタイルデータの送信の仕方は記載されていない点。 
 　 
（相違点４） 
　本願発明の送信手段は、「前記少なくとも最初の１回の送信時において、前記格納手段に格納された前記複数のスタイルデータの中から、前記データ受信装置での操作入力に基づいて選択されたスタイルデータを送信」しているのに対して、 
　引用発明の送信手段は、本願発明の送信手段のようにスタイルデータを選択して送信するとは記載されていない点。 
 　 
５．相違点１〜４についての判断 
　まず、文書本体と表示を制御するスタイル・シート（本願発明ののスタイル・データに相当する。）からなる構造化文書の形態は一般に知られていた周知技術である。そして、ネットワークを介して機器の管理をするときにＨＴＭＬ等の構造化された文書を使用する点については例えば、当審の拒絶理由通知に記載の引用例４（特開平１１−３４５１０６号公報（段落００２９から段落００４４参照。））や引用例５（特開２０００−１２２９５２号公報（要約の項、段落０００２、０００３、段落００１６から００１９参照。））により周知技術である。よって、引用発明においてファイルサーバからの送信時に上記周知技術を採用することは当業者が適宜に実施し得る程度のことである。 
　さらにその際に、 
　相違点１に係る、スタイルデータを複数格納しておく点は、引用例３により公知であるから、当業者が適宜になし得る事項であり、 
　相違点２に係る、データとして本体データのみ生成することも、引用例２において文書本体とスタイル・シートを分離して管理することが公知技術であるから、当業者が適宜になし得る事項である。 
　また、引用例２には、スタイル・シートをスタイルＩＤにより管理し、文書本体のみを送信することにより送信データのサイズを削減できることが記載されており、さらに、当該文書本体を表示する際には、スタイル・シートが必要なことは明らかであることから、相違点３に係る、少なくとも最初の１回の送信時においては本体データとスタイルデータとを送信する一方で、デバイス情報の更新送信時には両データのうち本体データのみを送信することは容易に想到し得る。 
　さらに、ユーザがスタイル・シートを選択することは引用例３により公知の技術であるから、相違点４に係る、少なくとも最初の１回の送信時において、格納手段に格納された複数のスタイルデータの中から、データ受信装置での操作入力に基づいて選択されたスタイルデータを送信できるようにすることは当業者が容易に想到し得ることである。 
 　 
　そして、本願発明の奏する効果は、引用発明、公知技術及び周知技術から予測される範囲内のものにすぎず、格別顕著なものということはできない。 
　したがって、本願発明は、引用発明、公知技術及び周知技術に基づいて当業者が容易に発明をすることができたものである。 
 　 
 ６．むすび 
　以上のとおり、本願発明は、引用発明、公知技術及び周知技術に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。