【事件の表示】
　特願２００３−１５９５１９「通信方法、通信システム、コンピュータにて記録できる媒体、クライアント装置、及びサーバ装置」拒絶査定不服審判事件〔平成１６年　１月２９日出願公開、特開２００４−　３０６５０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１５年６月４日（パリ条約による優先権主張２００２年６月７日，韓国）の出願であって，平成１８年６月８日付けの拒絶の理由の通知に対して，同年９月１２日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，同年１０月２日付けで拒絶をすべき旨の査定がされ，これに対し平成１９年１月９日に拒絶査定不服審判の請求がなされるとともに，同月３０日付けで手続補正がなされ，その後，当審において，平成２２年１月２６日付けで平成１９年１月３０日付けの手続補正が却下されるとともに，平成２２年１月２６日付けの拒絶の理由の通知に対して，同年５月６日付けで意見書が提出されるとともに，同日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２２年５月６日付け手続補正書の特許請求の範囲の請求項１（以下単に「請求項１」という。）に記載された事項により特定される，以下のとおりのものであると認める。
　
「スキャニング作業を少なくとも含むＫ（ここで、Ｋ≧１）個の作業を遂行してネットワークを通じてＭ（ここで、Ｍ≧１）個のクライアントによって共有されるＮ（ここで、Ｎ≧１）個のサーバ間の通信のために前記ネットワークを通じて伝送される伝送パケットを用いて前記クライアントと前記サーバ間で、別途の管理プログラム無しで、前記作業を遂行するための通信方法において、
　前記伝送パケットは、前記サーバとクライアント間で多機能の作業を遂行することができるようにする制御内容を含む伝送パケットとして、
　前記伝送パケットのバージョン番号を示すバージョン情報を有するバージョンフィールドと、
　伝送される前記パケットの発生形態を示すパケット形態表示情報を有するパケット形態表示フィールドと、
　前記Ｋ個中の少なくとも１つの作業中、前記パケットを使用する作業の形態を示す作業形態表示情報を有する作業形態表示フィールドと、
　前記作業の属性に関する第１情報と前記作業のデータに関する第２情報中、少なくとも１つを有する属性グループフィールド及びデータグループフィールドの双方または何れか一方と、
　前記伝送パケットの終端を示す終端情報を有する終端フィールドと、を具備し、
　前記伝送パケットの中、前記属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し、前記サーバ自体及び前記作業に関する属性中の所望の属性を有するサーバを発見する探索工程と、
　前記伝送パケットの中、前記属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し、前記発見されたサーバの現在状態をチェックする点検工程と、
　前記チェックされた状態を用いて情報を受信できるサーバを選別して、前記選別されたサーバにイベントを非同期的に通報することを要求する要求工程と、
　前記作業を遂行する遂行工程と、を備えることを特徴とする伝送パケットを利用した通信方法。」
　
　なお，請求項１には，「前記サーバとクライアント間で
多数
多数
多機能
多数
多機能
　
３．当審の拒絶理由
　当審において平成２２年１月２６日付けで通知した拒絶の理由の概要は，本願発明は，特開平１０−２３２９２５号公報（平成１０年９月２日出願公開。以下「引用例１」という。）に記載された発明，特開平８−７０３０５号公報（平成８年３月１２日出願公開。以下「引用例２」という。）に記載された技術及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
　
４．引用例の記載
（ａ）引用例１
　引用例１には，図面とともに次の事項が記載されている。
　
Ａ．「【０００１】
【発明の属する技術分野】本発明は、スキャナからネットワークを介してクライアント・コンピュータに画像を伝送するネットワーク画像走査システムに関し、より詳細には、クライアント・コンピュータがネットワークに接続されたスキャナを制御して、上記スキャナが上記クライアント・コンピュータに直接接続されている場合と同様に、上記スキャナから上記ネットワークを介して画像を受信することができるようにするネットワーク画像走査システムに関する。
【０００２】また、本発明は、ファイル・サーバーに画像ファイルを記憶させるという中間的な工程なしで、スキャナ・サーバーに接続されたスキャナからネットワークを介してクライアント・コンピュータに画像を伝送することに関するものである。」（第５ページ第７欄第１３行目〜同欄第２７行目）
　
Ｂ．「【０００９】本発明は上記に鑑みてなされたものであって、コンピュータ・ネットワークを介してスキャナからクライアント・コンピュータへ画像情報が伝送ができるネットワーク画像走査システムを提供することを目的とする。
【００１０】また、本発明は上記に鑑みてなされたものであって、最初にネットワーク・ファイル・サーバー上に画像を記憶する必要なしに、その画像情報をスキャナからローカル・コンピュータに直接伝送できるネットワーク画像走査システムを提供することを目的とする。
【００１１】また、本発明は上記に鑑みてなされたものであって、スキャナがクライアント・コンピュータに直接接続されている場合と同様に、クライアント・コンピュータ上で実行中のアプリケーション・プログラムがコンピュータ・ネットワークを介して情報を制御したり、画像スキャナからの情報を受け取ったりすることができるネットワーク画像走査システムを提供することを目的とする。
【００１２】また、本発明は上記に鑑みてなされたものであって、それに接続されたスキャナを有するスキャナ・サーバーからクライアント・コンピュータに、その画像ファイルを別個のファイル・サーバー上に保存する必要なく伝送できるネットワーク画像走査システムを提供することを目的とする。
【００１３】また、本発明は上記に鑑みてなされたものであって、画像ファイルを別のファイル・サーバーに記憶させることなく、スキャナと接続しているスキャナ・サーバーからクライアント・コンピュータへ画像ファイルを伝送できるネットワーク画像走査システムを提供することを目的とする。」（第５ページ第８欄第３１行目〜第６ページ第９欄第１０行目）
　
Ｃ．「【００６３】
【発明の実施の形態】以下、本発明に係るスキャナからネットワークを介してクライアント・コンピュータに画像情報を伝送するための画像伝送方法、画像伝送システム、コンピュータにより利用可能な媒体、および、メモリの好適な実施の形態について、添付の図面を参照して詳細に説明する。」（第１０ページ第１７欄第３５行目〜同欄第４１行目）
　
Ｄ．「【００７２】図２は、クライアント・コンピュータ１０２とスキャナ・サーバー・コンピュータ１３０とファイル・サーバー・コンピュータ１２２を示しており、それぞれが本発明で使われるコンピュータ・ネットワーク１２０によって接続されている。スキャナ・サーバー・コンピュータ１３０は、バス（またはケーブル）１４０を介してスキャナ１４４に接続されている。」（第１１ページ第１９欄第１行目〜同欄第７行目）
　
Ｅ．「【０１１５】図３との関連で以前に説明したように、各コマンドと情報はクライアント・コンピュータ１０２とスキャナ・サーバー１３０間をプロトコル・パケットを用いて送信される。本発明によって開発されたプロトコルに従って送信されるパケットには、図６に全体的に示されているヘッダー構造あるいはパケット・ヘッダーとデータ部分が含まれている。ヘッダーは、サーバーのセッション管理と制御のためにクライアントによって使用されるもので、データ部分にはネットワーク・セッション・データが含まれ、またこの部分は、一般的にはマシーン名や、ネットワーク・アドレス、スキャナ・パラメータ、そして画像データを送信するために使用される。
【０１１６】本発明で使用されるコマンドの多くはデータを伝送せず、従って、パケットのヘッダー構造だけがこれらのコマンドのために送信される。本発明で使用されるパケット・ヘッダーは、図６に示されているように、固定長のデータ・ストラクチャであって、伝送パケットのデータ部分における最初の項目である。
【０１１７】ネットワーク１２０上でのパケット・ヘッダーのクライアント・コンピュータ１０２とスキャナ・サーバー１３０間のルート割り当ては、ネットワークのトランスポート層によって、公知の、あるいは従来のネットワーク・トランスポート・プロトコルやその機構に従って実行される。これは、ソースや宛先が図６のパケット・ヘッダーでは必要とされないからである。
【０１１８】図６に示されるパケット・ヘッダー１８０の中で、最初のフィールドは数字記述子であるパケット・タイプ１８２であって、パケットの構成を識別する数字記述子である。本発明においては、各コマンドのパケット・タイプは“ＲＷＰ＿ＰＡＣＫＥＴ＿ＴＹＰＥ”か、あるいはそれに関連する数値である。現在、本発明ではこのタイプのパケットだけを用いて実行しているが、将来は他のパケット・タイプも利用されるようになるに違いない。なお、パケット・タイプ・フィールド１８２の長さは８ビットである。
【０１１９】装置ＩＤフィールド１８４は、パケットを利用するマシーンや機能のタイプを識別する８ビットの数字記述子（識別子）である。本発明の現在のバージョンにおいては、“Ｒｉｃｏｈ  Ｎｅｔｗｏｒｋ  Ｓｃａｎｎｅｒ”（あるいはＲｉｃｏｈ  Ｎｅｔｗｏｒｋ  Ｓｃａｎｎｅｒ  Ｓｏｆｔｗａｒｅ）というただ一つの限定された装置ＩＤがあって、各パケットはその装置ＩＤを持つ。しかしながら、本発明の将来的な展開の中では他の装置の識別子が用いられる可能性があるのは勿論である。
【０１２０】図６のフィールド１８６は８ビット・フィールドで数字フィールドであり、本発明で使用されるプロトコルの現在のバージョンを識別するために用いられる。現在は、一つだけのバージョンが規定されているが、つまり最初のバージョンだけであるが、今後、本発明のバージョンが進展し、追加機能セットをサポートすることになるであろう。
【０１２１】フラグ・フィールド１８８は８ビット・フィールドであって、個々のビットは異なるプロトコルの状態を識別する。ビット０はクライアント・コンピュータからスキャナ・サーバーへパケットを正常に送信する時点でのエラーを表示するために用いられる。
【０１２２】スキャンからアプリケーションへのプロセスにおいてスキャナ・サーバーからクライアント・コンピュータへのファイル転送中に、ビット１は、パケット・ヘッダーに伴う情報がそのファイルの最後であることを表示するために用いられ、ビット２は画像情報ぺージの最後を表示するために用いられる。ビット３はシーケンス・エラーの発生を表示するために用いられ、また正常に受信されなかったパケットの再送信を送信元に要求するために用いられる。
【０１２３】各プロトコル・コマンドはビット０とビット３のフラグを使用し、図７〜図１８と図２８〜図３３では、フラグ・フィールドに何の表示もされていない場合は、この特定のコマンドに、ビット０とビット３フラグが使われている以外は、特別のフラグは存在しない。
【０１２４】シーケンス番号フィールド１９０には３２ビットの数字が入り、現パケットを識別する。通信は双方向性であるので、送信者と受信者の双方ともパケットの流れの方向によって個別のシーケンス番号を保持する。送信される各パケットは、その前のパケットと比べて一つだけ番号を増やしたシーケンス番号を持っている。
【０１２５】確認応答番号フィールド１９２は３２ビットのフィールドであって、受信した最後の誤りなしのパケットを確認したことを表わしている。
【０１２６】エラー番号フィールド１９４には、フラグ・フィールド１８８のビット０がエラーを表わしている時の検査が行われたエラー番号が書き込まれる。このエラー番号フィールド１９４はフラグ・ビット０に関連するエラーの規定のタイプを表わし、８ビット長である。
【０１２７】コマンド・フィールド１９６は８ビットの数字フィールドであって、パケットに伴うコマンドあるいはレスポンスを表わす。各種コマンドとそれに対応する確認応答あるいはレスポンスはそれぞれ図７〜図１８に示され、それらは、セッション開始、セッション開始確認応答、セッション終了、セッション終了確認応答、スキャナ・パラメータ読み込み、スキャナ・パラメータ読み込み確認応答、パラメータ設定、パラメータ設定確認応答、スキャナ・ジョブ停止、スキャナ・ジョブ停止確認応答、ファイル読み込み、そしてファイル読み込み確認応答などである。これらのコマンドは本発明のスキャンからアプリケーションへの側面で使用される。
【０１２８】本発明のスキャンからファイルへの側面では、セッション開始、セッション開始確認応答、セッション終了、セッション終了確認応答、それに、セッション初期設定、セッション初期設定確認応答、セッション停止（ｔｅｒｍｉｎａｔｅｓｅｓｓｉｏｎ）、セッション停止確認応答、保存ファイル入手、そして保存ファイル入手確認応答を含む、図２８〜図３３に示された各コマンドが使用される。
【０１２９】最後に、データ・サイズ・フィールド１９８は１６ビットのフィールドであって、図６に示されたパケット・ヘッダーに続く様々な長さのデータのサイズを含んでいる。
【０１３０】図６に示されたパケット・ヘッダー構造は本発明の好適な実施の形態に従って構成されている。しかしながら、上記各フィールドに含まれる順序や、サイズや、情報は適宜変更が可能である。従って、もし必要とされる機能性を持っているならば、パケット・ヘッダーの各フィールドは消去、追加が可能であることは理解されるであろう。
【０１３１】図６に示されたパケット・ヘッダーは、クライアントおよびスキャナ・サーバー・コンピュータの両サイドでパケット・ヘッダーの送信前と送信後に、例えばＳＲＡＭやＤＲＡＭを使って実行されるバッファ・メモリなどのメモリやその他のメモリに保存される。本発明の一部にはパケット・ヘッダー構造で規定された通信プロトコルが含まれる。
【０１３２】パケット・タイプ、装置ＩＤ、バージョン、シーケンス番号、そしてエラー番号フラグは、図７〜図１８および図２８〜図３３で示された各パケット・ヘッダーにおいて同一のものであり、これらのフィールドは図６に関連して説明されているので、簡略化のためにそれらの説明はここでは行わない。さらには、フラグ・フィールドでは多くのコマンドで、パケットの正常送信におけるエラーを表わすビット０だけが使用され、ビット３は確認応答エラーを表わすために使用される。ファイルの最後とぺージの最後を表わすビット１と２が使用されていない場合は、図７〜図１８および図２８〜図３３においてフラグ・フィールドの説明があるので、その説明は省略される。
【０１３３】図７〜図１８の各パケット・ヘッダーは本発明のプロトコル・コマンドを送信するために使用される。そのため、図７〜図１８のパケット・ヘッダーはまた、プロトコル・コマンドまたはコマンドとも呼ばれる。
【０１３４】図７にはセッション開始コマンドのためのパケット・ヘッダー２００の構造が示されている。セッション開始コマンドのパケット・ヘッダー２００はまずパケットをＲＷＰ＿ＰＡＣＫＥＴ＿ＴＹＰＥで表わすパケット・タイプ・フィールド２０２で始まるので、上記したＲｉｃｏｈ  Ｗｏｒｋｇｒｏｕｐ  Ｐｒｏｔｏｃｏｌの場合を表わしている。
【０１３５】装置ＩＤフィールド２０４は、パケットがＲｉｃｏｈネットワーク・スキャナ・システムとの通信に使用されることを表わしている。バージョン・フィールド２０６は、パケット・プロトコルのバージョンが１であることを表わしている。フィールド２０８にはセッション開始コマンド・パケット・ヘッダーのための所定のフラグがないので、このフィールドで使用することができる各フラグはフラグ０および３であり、それらは上記したとおりである。
【０１３６】シーケンス番号フィールド２１０と確認応答番号フィールド２１２とは以前に発生した通信に従って設定される。エラー番号フィールド２１４はフィールド２０８のフラグ０が設定された時のエラーを表示するために使用される。しかしながら、本例においては、エラーがまだ設定されていないので、エラー番号フィールドはゼロに設定されている。コマンド・フィールド２１６は、そのコマンドがセッション開始のためのものであることを表わしている。
【０１３７】データ・サイズ・フィールド２１８にはクライアント・コンピュータのマシーン名のサイズと、クライアント・コンピュータのネットワーク・アドレスのサイズを示す各データが表示されている。図７に示されたパケット・ヘッダーではクライアント・コンピュータのマシーン名とクライアント・コンピュータのネットワーク・アドレスを表わす各データがつぎに続く。
【０１３８】別の例として、本発明のスキャンからファイルへの側面の一部の例で行われるように、セッション開始コマンドがスキャナ・サーバー１３０から発信されると、そのデータ・サイズには、セッション開始パケット・ヘッダーに続いてスキャナ・サーバーの情報サイズが書き込まれる。
【０１３９】図８にはセッション開始コマンドを受信したコンピュータから送信されるセッション開始確認応答コマンドのためのパケット・ヘッダー２２０の構造が示されている。このパケットのコマンド・フィールド２３６は、このコマンドがセッション開始確認応答コマンドであることを表わしている。
【０１４０】このセッション開始確認応答コマンドはスキャナ・サーバー１３０からクライアント・コンピュータ１０２（またはその逆）へ送信されるが、このコマンドは上記セッション開始コマンドがスキャナ・サーバー・コンピュータ１３０側で正常に受信され、またセッションの開始に向けてすべての必要な操作が順調に行われたことを表わしている。このセッション開始確認応答コマンドに関連する添付データはない。
【０１４１】なお、図において、２２２はパケット・タイプ・フィールド、２２４は装置ＩＤフィールド、２２６はバージョン・フィールド、２２８はフラグ・フィールド、２３０はシーケンス番号フィールド、２３２は確認応答番号フィールド、２３４はエラー番号フィールド、２３８はデータ・サイズ・フィールドを示す。
【０１４２】図９にはセッション終了コマンドのためのパケット・ヘッダー２４０の構造が示されている。このパケット・ヘッダー２４０では、コマンド・フィールド２５６は上記パケット・ヘッダーがセッション終了コマンドのためのものであることを示している。上記セッション終了コマンドに続くデータが何もないことから、セッション終了パケット・ヘッダー２４０のデータ・サイズ・フィールド２５８はゼロとなる。
【０１４３】なお、図において、２４２はパケット・タイプ・フィールド、２４４は装置ＩＤフィールド、２４６はバージョン・フィールド、２４８はフラグ・フィールド、２５０はシーケンス番号フィールド、２５２は確認応答番号フィールド、２５４はエラー番号フィールドを示す。
【０１４４】図１０にはセッション終了確認応答パケット・ヘッダーの構造２６０が示されており、そこにはコマンド・フィールド２７６が設定されており、このパケット・ヘッダー構造がセッション終了確認応答コマンドのためのものであることを表わしている。このパケット・ヘッダーはセッション終了コマンドを受信したコンピュータから送信され、スキャニング操作に関するセッションが正常に終了したことを表わしている。上記セッション終了確認応答パケット・ヘッダーに続くデータが何もないことから、パケット・ヘッダー２６０のデータ・サイズ・フィールド２７８はゼロに設定される。
【０１４５】なお、図において、２６２はパケット・タイプ・フィールド、２６４は装置ＩＤフィールド、２６６はバージョン・フィールド、２６８はフラグ・フィールド、２７０はシーケンス番号フィールド、２７２は確認応答番号フィールド、２７４はエラー番号フィールドを示す。
【０１４６】図１１にはスキャナ・パラメータ読み込みパケット・ヘッダー構造２８０が示されている。このパケット・ヘッダー２８０では、コマンド・フィールド２９６は上記パケット・ヘッダーがスキャナ・パラメータ読み込みコマンドのためのものであることを表わしている。データ・サイズ・フィールド２９８はゼロに設定されるが、それはこのパケット・ヘッダーに続くデータがないことを表わしている。
【０１４７】上記スキャナ・パラメータ読み込みコマンドはクライアント・コンピュータ１０２からスキャナ・サーバー・コンピュータ１３０へ送信され、クライアント・コンピュータ１０２が、ユーザーに提供されるスキャナ・パラメータの内容をクライアント・コンピュータ側で判断したいということを表わしている。このコマンドにはスキャナの選択やスキャナのパラメータを設定する際に許容される範囲が含まれる。
【０１４８】なお、図において、２８２はパケット・タイプ・フィールド、２８４は装置ＩＤフィールド、２８６はバージョン・フィールド、２８８はフラグ・フィールド、２９０はシーケンス番号フィールド、２９２は確認応答番号フィールド、２９４はエラー番号フィールドを示す。
【０１４９】図１２にはスキャナ・パラメータ読み込み確認応答コマンドのためのパケット・ヘッダー構造が示されている。このパケット・ヘッダー３００では、データ・サイズ・フィールド３１８に、スキャナ・サーバー１３０からクライアント・コンピュータ１０２に送信されたスキャナ・パラメータ読み込み確認応答のパケット・ヘッダーに続くスキャナ・パラメータ・テーブルのサイズが書き込まれる。このスキャナ・パラメータ・テーブルはスキャナや画像獲得装置の範囲や可能な設定条件を含むスキャナの現在のパラメータが書き込まれているデータ・ストラクチャである。
【０１５０】このパラメータには、例えば、以下に解説する図２５の各パラメータが含まれる。クライアント・コンピュータがスキャナのパラメータの許容範囲を認識していない場合には、スキャナや画像獲得装置の異なるパラメータの設定やその互換性について当クライアント・コンピュータに通知する必要がある。その通知は、スキャナ・パラメータ読み込み確認応答コマンドといっしょに送信されるスキャナ・パラメータ・テーブルの中に、スキャナ・パラメータの可能な設定や設定範囲を含めることによって可能となる。
【０１５１】あるいは、別個のコマンドとそれに対応するコマンド・プロトコル・ヘッダーを用いて、クライアントからサーバーへ送信されるスキャナ設定の範囲を読み込むことができる。上記の対応する確認応答コマンドにはスキャナや画像獲得装置の範囲や可能な設定を規定するデータが書き込まれる。この選択的な配列では、スキャナ・パラメータ・テーブルには使用される現在のスキャニング・パラメータだけが入っている。要求があれば、スキャナ・サーバーは、ユーザーの望む設定を書き込んだ各ユーザーやクライアント・コンピュータのためのテーブルを引き続き保持する。
【０１５２】このテーブルは、本発明のスキャンからアプリケーションおよびスキャンからファイルへの両側面に利用される。なお、図において、３０２はパケット・タイプ・フィールド、３０４は装置ＩＤフィールド、３０６はバージョン・フィールド、３０８はフラグ・フィールド、３１０はシーケンス番号フィールド、３１２は確認応答番号フィールド、３１４はエラー番号フィールド、３１６はコマンド・フィールドを示す。
【０１５３】クライアント・コンピュータがスキャンからアプリケーションへの手順に用いられるスキャニング・パラメータの設定を希望する場合は、図１３に示されたパラメータ設定のためのパケット・ヘッダー３２０がクライアント・コンピュータからスキャナ・サーバー・コンピュータへ送信される。データ・サイズ・フィールド３３８は送信されているスキャナ・パラメータ・テーブルのサイズに設定される。
【０１５４】スキャナ・パラメータ・テーブルを含むデータはパケット・ヘッダー３２０の後に続く。なお、図において、３２２はパケット・タイプ・フィールド、３２４は装置ＩＤフィールド、３２６はバージョン・フィールド、３２８はフラグ・フィールド、３３０はシーケンス番号フィールド、３３２は確認応答番号フィールド、３３４はエラー番号フィールド、３３６はコマンド・フィールドを示す。
【０１５５】上記スキャナ・サーバーがパラメータ設定に使われるパケット・ヘッダー３２０を受信してから、スキャナ・サーバー・コンピュータは図１４のパラメータ設定確認応答のパケット・ヘッダー３４０をクライアント・コンピュータに送信する。
【０１５６】なお、図において、３４２はパケット・タイプ・フィールド、３４４は装置ＩＤフィールド、３４６はバージョン・フィールド、３４８はフラグ・フィールド、３５０はシーケンス番号フィールド、３５４は確認応答番号フィールド、３５４はエラー番号フィールド、３５６はコマンド・フィールド、３５８はデータ・サイズ・フィールドを示す。
【０１５７】万一、クライアント・コンピュータがスキャンからアプリケーションへの手順を設定したあとで、その手順をクライアント・コンピュータ側で取り消したいと希望する場合は、ユーザーはクライアント・コンピュータ１０２の画像表示上の適切な取消しコマンドをクリックすることによって、図１５のスキャナ・ジョブ停止のパケット・ヘッダー３６０がクライアント・コンピュータ１０２からスキャナ・サーバー・コンピュータ１３０へ送信される。
【０１５８】このパケット・ヘッダー３６０では、データ・サイズ・フィールドにクライアントのマシーン名のサイズが書き込まれている。このスキャナ・ジョブ停止のパケット・ヘッダー３６０に続くデータは上記クライアント・コンピュータ１０２の名前である。なお、図において、３６２はパケット・タイプ・フィールド、３６４は装置ＩＤフィールド、３６６はバージョン・フィールド、３６８はフラグ・フィールド、３７０はシーケンス番号フィールド、３７４は確認応答番号フィールド、３７４はエラー番号フィールド、３７６はコマンド・フィールド、３７８はデータ・サイズ・フィールドを示す。
【０１５９】上記スキャナ・サーバー・コンピュータ１３０は、スキャナ・ジョブ停止のパケット・ヘッダー３６０を受信すると、図１６のスキャナ・ジョブ停止確認応答のパケット３８０をクライアント・コンピュータに送り返す。なお、図において、３８２はパケット・タイプ・フィールド、３８４は装置ＩＤフィールド、３８６はバージョン・フィールド、３８８はフラグ・フィールド、３９０はシーケンス番号フィールド、３９４は確認応答番号フィールド、３９４はエラー番号フィールド、３９６はコマンド・フィールド、３９８はデータ・サイズ・フィールドを示す。
【０１６０】図１７にはファイル読み込みのためのパケット・ヘッダー４００が示されている。クライアント・コンピュータ１０２がスキャニング・パラメータを設定し、ユーザーがスキャニング操作の開始を希望すると、クライアント・コンピュータ１０２はファイル読み込みのためのパケット・ヘッダーをスキャナ・サーバー・コンピュータ１３０に送信する。データ・サイズ・フィールド４１８にはマシーン名やクライアント・コンピュータ名のサイズが書きこまれ、またパケット４００に続くデータは上記マシーン名である。
【０１６１】なお、図において、４０２はパケット・タイプ・フィールド、４０４は装置ＩＤフィールド、４０６はバージョン・フィールド、４０８はフラグ・フィールド、４１０はシーケンス番号フィールド、４１４は確認応答番号フィールド、４１４はエラー番号フィールド、４１６はコマンド・フィールドを示す。
【０１６２】ユーザーがスキャナ・サーバーでスキャニング操作を開始すると、図１８のファイル読み込み確認応答のパケット・ヘッダー４２０を使って画像がスキャナ・サーバー・コンピュータ１３０からクライアント・コンピュータ１０２へ送信される。このパケット・ヘッダー４２０のフラグ・フィールド４２８においては、ビット２はパケット・ヘッダー４２０に続くデータが画像データのぺージの最後を表わし、ビット１は画像ファイルの最後を表わすために用いられる。
【０１６３】データ・サイズ・フィールド４３８は、最大パケット・サイズから（パケット・ヘッダーのサイズ＋送信されるファイル・データのサイズを含む量）を減算したそのサイズに等しいサイズを表わす。画像データはかなり長いものなので、画像あるいはファイル・データは複数のパケットで送信され、それぞれは対応するパケット・ヘッダーを持っている。
【０１６４】なお、図において、４２２はパケット・タイプ・フィールド、４２４は装置ＩＤフィールド、４２６はバージョン・フィールド、４３０はシーケンス番号フィールド、４３４は確認応答番号フィールド、４３４はエラー番号フィールド、４３６はコマンド・フィールドを示す。
【０１６５】図１９〜図２３は本実施の形態のスキャンからアプリケーションへの側面を表わすフローチャートである。本発明のこの側面により、ユーザーはクライアント・コンピュータ１０２上で動作するアプリケーションの中からスキャニング操作の種々の側面を、あたかもスキャナが、例えばＳＣＳＩバスを使って、クライアント・コンピュータ１０２に直接接続されたように制御することができる。しかしながら、実際のスキャニングはスキャナ・サーバー・コンピュータ１３０で行われる。
【０１６６】図１９において、本実施の形態で使用されるソフトウエアは、スタートしてから、ステップ４５０でクライアント・コンピュータ１０２とスキャナ・サーバー・コンピュータ１３０の両方でインストールされる。クライアント・コンピュータではソフトウエアはＴＷＡＩＮとの互換性を持つデバイス・ドライバーがインストールされる。このデバイス・ドライバーで、スキャナのパラメータを設定するという機能がまるでスキャナが直接クライアント・コンピュータに接続されているかのように実行できるので、このデバイス・ドライバーはバーチャルＴＷＡＩＮデバイス・ドライバーと呼ばれている。
【０１６７】また、スキャナ・サーバー・コンピュータにはスキャニング操作を実行するために使われるソフトウエアがインストールされる。図３において、スキャンからアプリケーションへの操作で使われるソフトウエアには、バーチャルＴＷＡＩＮドライバー１０６、クライアント・プロトコル・エンコーダ／デコーダ・ソフトウエア１０８、サーバー・プロトコル・エンコーダ／デコーダ・ソフトウエア１３２、スキャン・タスク・ソフトウエア１３４、それに、ＴＷＡＩＮドライバー１３６などが含まれる。スキャンからアプリケーションへのプロセスのためのソフトウエアを通して使われるアプリケーション・ソフトウエア１０４は、バーチャルＴＷＡＩＮドライバー１０６を使用するＴＷＡＩＮと互換性のあるソフトウエアが好適である。
【０１６８】各ソフトウエアがクライアントとサーバーの両コンピュータにインストールされた後、アプリケーション・ソフトウエアの標準ＴＷＡＩＮインターフェースを使って、ユーザーは図２４のプルダウン・メニューで、画像のソースとしてネットワーク・スキャナをステップ４５２で選択する。
【０１６９】図２４に示されたプルダウン・メニュー５２０には、従来のグラフィカル・ユーザー・インターフェースの各コマンド（５２２〜５３２、５３８〜５４２）と、クライアント・コンピュータ１０２でユーザーが利用するセレクト・ソース・コマンド５３４とが並べられている。
【０１７０】ユーザーが図２４のセレクト・ソース・コマンド５３４を選択すると、つぎのメニューが表示され（図示せず）、ユーザーは一つまたはそれ以上のインストール済デバイス・ドライバーから選ぶことができる。ネットワーク・スキャナでスキャンからアプリケーションへの操作を行う場合は、ユーザーは画像のソースとしてネットワーク・スキャナを選ぶことになる。
【０１７１】画像入手の準備が整うと、ステップ４５４で、ユーザーは図２４の獲得コマンド５３６を使ってスキャニング操作の開始を要求する。この時、クライアント・コンピュータはネットワーク上に利用可能なワークグループ・スキャナがあるかどうかを判断する。クライアント・コンピュータがネットワーク上で利用可能なスキャナ・サーバーがあるかどうかを判断し得る方法は複数あり、また有効なネットワーク・スキャナがあるかどうかを判断する好適な方法が以下で説明される。
【０１７２】本発明で利用されるコンピュータ・ネットワーク１２０のタイプによって、異なるタイプの方法が実行され、ネットワーク１２０上に利用可能なワークグループ・スキャナがあるかどうかを判断する。ネットワーク１２０がＮｏｖｅｌｌ社のＮｅｔＷａｒｅで実現される場合は、スキャナ・サーバーがネットワーク上に存在するかどうかを判断するための二つの方法が実行可能である。
【０１７３】Ｎｏｖｅｌｌ社のＮｅｔＷａｒｅのＳＰＸ／ＩＰＸプロトコルで利用できる第１の方法は、スキャナ・サーバー１３０を含むネットワーク上で利用可能な種々のサーバーによって送信されるＳｅｒｖｉｃｅ  ＡｄｖｅｒｔｉｓｅｍｅｎｔＰｒｏｔｏｃｏｌ（ＳＡＰ）パケットをクライアント・コンピュータに監視させるものである。これらのＳＡＰパケットは、ネットワークの各サーバーの利用可能性を知らせるために、約６０秒毎に各サーバーから送信される。
【０１７４】この方法がクライアント側で利用されると、クライアント・コンピュータはスキャナ・サーバー１３０から送信されるＳＡＰパケットの存在を監視しなければならない。また上記ＳＡＰプロトコルによって、利用可能なネットワーク・サービスに関する問い合わせ要求をクライアントから送信することが可能となり、この問い合わせはサーバーによって対処される。この照会機構とは、本発明の好適な実施の形態で使用されるクライアント・コンピュータがネットワーク・スキャナ・サーバーの利用可能性を判断する方法である。
【０１７５】スキャナ・サーバー・コンピュータ１３０がネットワーク上で利用可能かどうかをＮｏｖｅｌｌネットワーク・システムを使って判断する第２の方法は図２のファイル・サーバー１２２のためのもので、ネットワーク上で利用可能な全サーバーを有するファイル・サーバー１２２でＮｅｔＷａｒｅバインダリやディレクトリを保持する。
【０１７６】ファイル・サーバー１２２が有効な全サーバーのディレクトリを保持しているので、クライアント・コンピュータ１０２は、ネットワーク上で一台または複数のネットワーク・スキャナ・サーバーについて利用可能であることを判断するために、ただ、ファイル・サーバー１２２内に保存されている情報を調べるだけでよい。
【０１７７】本発明は、ＵＮＩＸシステムとインターネットの両方で共通に使われているＴＣＰ／ＩＰネットワーキングを利用しても実施可能である。ＴＣＰ／ＩＰを使用して実行することにより、たとえば、ネットワーク・アドミニストレータといった装置あるいは人は、スキャナ・サーバー１３０を含む利用可能なネットワーク・サービスを規定するテーブルをクライアント・コンピュータ上に登録する。
【０１７８】クライアント・コンピュータ１０２が利用可能なスキャナ・サーバーがあるかどうかの判断を望んだ場合、クライアント・コンピュータ１０２は、その利用可能なスキャナ・サーバーについて判断するためにクライアント・コンピュータで保存しているテーブルをチェックする。スキャナ・サーバーの利用可能性を判断するための上記方法は本発明の好適な実施の形態の一部であるが、必要ならば、スキャナ・サーバーの利用可能性を判断するためのそれ以外の方法も利用できる。
【０１７９】ネットワーク・スキャナが利用可能かどうかの判断がステップ４５６で行われ、ステップ４５８においてステップ４５６の結果が検討される。ステップ４５８で複数のワークグループやネットワーク・スキャナが利用可能であると判断されると、ユーザーは、ステップ４６０で上記複数のワークグループ・スキャナのうちで、スキャンからアプリケーションへの操作に使用されるものを選択する。
【０１８０】ステップ４６０は利用可能なネットワーク・スキャナ・サーバーのリストを表示するグラフィカル・ユーザー・インターフェースで実行することができ、ユーザーはこのリストからスキャナ・サーバーの一つを選ぶ。ステップ４５８で利用可能なワークグループ・スキャナ・サーバーがないと判断されると、エラーが表示され、ユーザーが一台のネットワーク・スキャナを使用すると指示したが利用可能なネットワーク・スキャナがないので、このプロセスは終了する。
【０１８１】ステップ４６０で一台のワークグループ・スキャナの選択が実行され、あるいは、ステップ４５８でネットワーク上で利用可能なワークグループ・スキャナが一台だけあると判断されると、フローはステップ４６２へ進み、そこでセッション開始コマンドがクライアント・コンピュータ１０２からスキャナ・サーバー１３０へ送信される。
【０１８２】セッション開始コマンドのパケット・ヘッダーは図７に示されており、この図示されたパケット・ヘッダーとともにクライアント・コンピュータ１０２のマシーン名とクライアント・コンピュータ１０２のネットワーク・アドレスのデータが送られる。ステップ４６４で、スキャナ・サーバー・コンピュータ１３０は上記セッション開始コマンドを受信し、図４との関連で先に説明したプロセスＩＤテーブルにエントリー情報を作成し、同様に、図５との関連で先に説明したスキャナ画像テーブルにエントリー情報を作成するが、このプロセスについてはクライアント・コンピュータ１０２側で発信される。
【０１８３】図４に示されたプロセスＩＤテーブル１５０はクライアントとサーバー間でのプロセス開始を登録するために使用され、スキャナ画像テーブル１６０は、クライアント・コンピュータの名前とアドレスやスキャニング・プロセスで使われるスキャニング・パラメータとを含むスキャンからアプリケーションへの操作の詳細を登録するために使用される。ステップ４６４が実行されると、スキャナ・サーバー・コンピュータ１３０はステップ４６６で、図８に示されたセッション開始確認応答コマンドをクライアント・コンピュータ１０２へ送信する。
【０１８４】ステップ４６８でスキャナ・パラメータ読み取りコマンドが、そのパケット・ヘッダーは図１１に示されているが、クライアント・コンピュータ１０２からスキャナ・サーバー・コンピュータ１３０へ送信される。つぎにステップ４７０で、スキャナ・パラメータ読み取り確認応答コマンドが、そのパケット・ヘッダーは図１２に示されているが、添付データとしてそのスキャナのパラメータとともにサーバー１３０からクライアント１０２へ送信される。
【０１８５】ステップ４７０についで、ステップ４７２では、バーチャルＴＷＡＩＮデバイスを使ってクライアント・コンピュータ１０２にスキャナのパラメータが表示され、ユーザーはクライアント・コンピュータ１０２でスキャナのパラメータを編集することができる。図２５はコンピュータ画面５４５の画像を表わしており、ここでユーザーはスキャナのパラメータを設定することができる。
【０１８６】例えば、解像度、輝度、そしてコントラストはスライド可能な画像コントロール・ボタンを使って設定される。閾値にはこのスライド可能なマークが表示されていないので、この特定のスキャナでは、閾値を調整することは無理であろう。使用可能な代表的モードにはライン・アート（例えば、白黒）、ハーフトーン、１６階調、そして２５６階調が含まれる。ハーフトーン・リスト・ボックスは、ハーフトーン・モードが選ばれた時にだけ使用される。エラー拡散ハーフトーン・モードでは、拡散ランダム・パターンが作られる。
【０１８７】ステップ４７４ではユーザーがスキャナ・パラメータのどこかを変更したかどうかがチェックされる。スキャナのパラメータが変更されていたら、フローはステップ４７６に進む。なお、ステップ４７６は、必要ならば、プロセスから削除することができるので、上記パラメータが変更されたかどうかは確認されないまま、フローはステップ４７２からステップ４７６へ直接進むことになる。
【０１８８】ステップ４７６では、図１３のスキャナ・パラメータ設定コマンドを、添付のデータとして新たに設定されたスキャナ・パラメータとともに、クライアント・コンピュータ１０２からスキャナ・サーバー１３０へ送信する。
【０１８９】ステップ４７８では、スキャナ・パラメータはサーバーに保存される。つぎに、ステップ４８０で、上記各パラメータが正常に設定されたことを確認応答する図１４のスキャナ・パラメータ設定確認応答コマンドがサーバーからクライアント・コンピュータへ送信される。
【０１９０】ステップ４８０以降で、ステップ４７４での問い合わせに対して否定の回答がなされた場合は、ステップ４８２で、図１７のファイル読み込みコマンドがクライアント・コンピュータの名前を添付され、クライアント・コンピュータ１０２からスキャナ・サーバー・コンピュータ１３０へ送信される。この名前は、スキャナに登録された各種のスキャンからアプリケーションへのジョブを把握するために、スキャナ・サーバー１３０で利用される。
【０１９１】つぎにステップ４８４では、クライアント側のユーザーにスキャナ・サーバー１３０で走査を始めるように指示を出す。ステップ４８４はクライアント・コンピュータでメッセージを表示することによって実行される。上記メッセージがＷｉｎｄｏｗｓベースのグラフィカル・メッセージである場合は、ダイアログ・ボックスが表示され、そこにはキャンセル“ボタン”もまた表示されている。ユーザーがクライアント・コンピュータ１０２でキャンセル・ボタンを“クリック”すると、スキャンからアプリケーションへのプロセスが以下に説明するように中止される。
【０１９２】ステップ４８４で、クライアントにサーバーで走査を開始するよう指示したメッセージを表示すると、そのメッセージは同時に、クライアント・コンピュータが現在スキャナ・サーバー１３０から送信される画像情報を待っていることも示している。必要ならば、クライアント・コンピュータ１０２上で動作するスキャンからアプリケーションへのプロセスを自動的にできるだけ小さくすることができるので、そのプロセスは動作を続けるが、コンピュータ・ディスプレイの前面では動作しない。
【０１９３】また別の場合では、クライアント・コンピュータ１０２上で動作するスキャンからアプリケーションへのプロセスは極小化されず、ユーザーにクライアント・コンピュータからのスキャニング操作の取り消しを許可するメッセージを表示し続け、クライアント・コンピュータがスキャナ・サーバー・コンピュータ１３０からの画像情報の受信を待っていることも同様に示している。
【０１９４】ステップ４８６ではクライアント・コンピュータ１０２でユーザーの動作を監視し、ユーザーがクライアント・コンピュータ１０２でのスキャニング・ジョブの取消しを望んでいるかどうかを判断する。ステップ４８６で行われる判断はステップ４８４以降であればいつでも実行される。例えば、上記ジョブは、ユーザーがスキャナ・サーバー・コンピュータ１３０でスキャニング操作を始めた後での取消しが可能である。
【０１９５】ユーザーがスキャンからアプリケーションへのジョブの取消しを望まない場合は（ステップ４８６、否）、ステップ４８８で、スキャナ・サーバー・コンピュータ１３０でスキャンからアプリケーションへのオプションを選択する。例えば、スキャナ・サーバー１３０は、ユーザーがスキャンからアプリケーションへのプロセス、あるいはスキャンからファイルへのプロセスを実行すること、およびスキャンからアプリケーションへのプロセスを選択することを許可するオプションを表示する。
【０１９６】つぎに、ステップ４９０で図２６の画像６００のように各種マシーン名やジョブのリストがスキャナ・サーバー１３０で表示される。図２６の例におけるマシーン名リスト６０４には、Ｊｏｈｎ、Ｒｏｂｉｎ、Ｈｅｎｒｙという三つのマシーン名が表示されている。図２６ではＪｏｈｎが強調表示されていて、ユーザーが“ＯＫ”ボタン６０６をクリックすると、マシーン名Ｊｏｈｎに対応するスキャナ・ジョブが開始される。
【０１９７】図２６の画像６００ではまた、キャンセル・ボタン６０８をクリックすればユーザーはスキャナ・サーバー１３０におけるスキャニング操作を取り消すことが可能である。なお、図において、６０２は画像６００がワークグループ・スキャナ操作の画面であることを示すジョブ名表示エリアである。
【０１９８】ステップ４９０でユーザーが必要なマシーン名を選択すると、ユーザーにスキャナの上に原稿を置き、用意ができたら“ｓｔａｒｔ”ボタンをクリックするよう要求するメッセージがスキャナ・サーバー・コンピュータ１３０に表示される。そしてステップ４９２において、原稿は図５で示されたスキャナ画像テーブル１６０に保存されている予め設定されたパラメータに従ってスキャンされる。
【０１９９】つぎにステップ４９６では、画像データ・ファイルあるいは画像情報が、図１８との関連で以前に説明されたファイル読み込み確認応答コマンドを使って、スキャナ・サーバー１３０からクライアント・コンピュータ１０２へ送信される。
【０２００】ユーザーが図２２のステップ４８６においてネットワーク・スキャニング操作の取り消し要求をクライアント・コンピュータで表示すると、フローはステップ５１０に進み、そこでクライアント・コンピュータ１０２は、ジョブ停止コマンドと図１５のジョブ停止パケット・ヘッダーにマシーン名を付けて、クライアント・コンピュータ１０２からサーバー・コンピュータ１３０に送信する。ステップ５１２でスキャナ・サーバー・コンピュータ１３０は図１６のジョブ停止確認応答コマンドをクライアント・コンピュータ１０２に送信する。
【０２０１】ステップ４９６で画像データ・ファイルの送信が終わり、ステップ５１２でジョブ停止確認応答コマンドが送信されると、図２３のステップ４９８では、図９のセッション終了コマンドのクライアント・コンピュータ１０２からスキャナ・サーバー・コンピュータ１３０への送信が実行される。
【０２０２】ステップ５００では、このステップ５００で実行されるスキャンからアプリケーションへのプロセスとして、図４のプロセスＩＤテーブルの対応するエントリー情報が消去され、図５のスキャナ画像テーブルの対応するエントリー情報も同様に消去される。ステップ５０２では、図１０のセッション終了確認応答コマンドがスキャナ・サーバー１３０からクライアント・コンピュータ１０２へ送信され、そして上記スキャンからアプリケーションへのプロセスは終了する。
【０２０３】本発明の第２の側面はスキャンからファイルへの動作で、この動作においてはネットワーク・スキャナあるいは他の画像獲得装置に接続されたスキャナ・サーバーがネットワークを通じて獲得された画像ファイルをクライアント・コンピュータのローカル記憶装置に伝送する。このスキャンからファイルでの動作は図２および３に図示されているのと同じハードウエアを用いる。
【０２０４】しかしながら、クライアント・コンピュータ１０２はバーチャルＴＷＡＩＮドライバー１０６を用いる必要はなく、スキャナ・サーバー１３０およびスキャナ１４４から得られた画像ファイルの保存を制御するためにクライアント・コンピュータ１０２のファイル・キャッチャー・ソフトウエア１１２を用いる。スキャン・タスク・ソフトウエア１３４およびスキャナ・サーバー・コンピュータ１３０のサーバー・プロトコル・エンコーダ／デコーダ１３２とクライアント・コンピュータ１０２のクライアント・プロトコル・エンコーダ／デコーダ１０８は本発明のスキャンからアプリケーションへ、およびスキャンからファイルへの両方のための必要な機能性を備えている。もちろん、本発明の異なった側面の異なった機能性を実行するために異なったソフトウエア・プログラムを開発することも可能であろう。
【０２０５】本発明のスキャンからファイルへの側面では、図４に示されているようなプロセスＩＤテーブル、図６に示されているパケット・ヘッダーと同じストラクチャ、および図７〜図１８までに関連して説明したセッション開始、セッション開始確認応答、セッション終了、およびセッション終了確認応答コマンドが用いられる。
【０２０６】本発明のスキャンからファイルへの動作は図２７に示されているようなマシーン名テーブル６２０を用いる。このマシーン名テーブル６２０はスキャナ・サーバー１３０に保存されており、その主な目的はスキャンからファイルへの動作のクライアントを管理することである。
【０２０７】このテーブルは複数のスキャンからファイル動作のクライアントを識別し処理するために必要なすべての情報を含んでおり、個別のエントリー情報（entry)がスキャンからファイル動作で用いられる各クライアント−サーバー接続に関してマシーン名テーブル内に保持されている。
【０２０８】クライアント・コンピュータがスキャナ・サーバー・コンピュータ１３０にスキャンからファイルへのプロセスを登録する度にマシーン名テーブル６２０内にエントリー情報がつくりだされ、このエントリー情報はクライアント・コンピュータによってスキャンからファイル動作が終了すると消去される。
【０２０９】このマシーン名テーブル６２０は一つのクライアント−サーバーのスキャンからファイル動作セッションのための個別のテーブル・エントリー情報を示す整数であるインデックス・フィールド６２２を含んでいる。それらのインデックスは順番に割り当て、保持されたり、ランダムに割り当てられたり、あるいはその他のいずれかの方法で割り当てることができる。
【０２１０】マシーン名フィールド６２４はクライアント・コンピュータ１０２の名前を含む文字列である。この名前はサーバーでのスキャン動作中ユーザーに提示され、したがってユーザーはクライアントの接続を確認して、走査された画像が正しいクライアント・ワークステーションに確実に送られるようにすることができる。クライアント・アドレス・フィールド６２６はそのクライアント・コンピュータ１０２のネットワーク・アドレスを記憶する。
【０２１１】本発明のスキャンからファイル動作において用いられるプロトコル・パケットに関しては、上に述べたように、スキャンからアプリケーション動作に関連して説明したセッション開始、セッション開始確認応答、セッション終了、およびセッション終了確認応答コマンドがスキャンからファイル動作と共に用いられる。
【０２１２】さらに、スキャンからファイル動作を実行するために、図２８〜図３３に示されているセッション初期設定（initialize session) 、セッション初期設定確認応答（initialize session acknowledge) 、セッション停止（terminate session)、セッション停止確認応答（terminate session acknowledge)、保存ファイル入手（get storage file) 、保存ファイル入手確認応答（get storage file acknowledge) コマンドが用いられる。
【０２１３】なお、図２８〜図３３において、６４２、６７２、６９２、７１２、９０２、９２２はパケット・タイプ・フィールド、６４４、６７４、６９４、７１４、９０４、９２４は装置ＩＤフィールド、６４６、６７６、６９６、７１６、９０６、９２６はバージョン・フィールド、６４８、６７８、６９８、７１８、９０８、９２８はフラグ・フィールド、６５０、６８０、７００、７２０、９１０、９３０はシーケンス番号フィールド、６５２、６８２、７０２、７２２、９１２、９３２は確認応答番号フィールド、６５４、６８４、７０４、７２４、９１４、９３４はエラー番号フィールド、６５６、６８６、７０６、７２６、９１６、９３６はコマンド・フィールド、６５８、６８８、７０８、７２８、９１８、９３８はデータ・サイズ・フィールドを示す。
【０２１４】図２８に示すパケット・ヘッダー６４０はセッション初期設定コマンドで用いられる。セッション初期設定コマンドはスキャンからファイル動作を行うためにクライアント・コンピュータ１０２をスキャナ・サーバー・コンピュータ１３０に登録するために用いられ、マシーンのサイズあるいはクライアント名＋ネットワーク・アドレスのサイズを含むデータ・サイズ・フィールド６５８を含んでいる。
【０２１５】セッション初期設定パケット・ヘッダー６４０の後に来るデータはクライアント・コンピュータ１０２のマシーン名およびネットワーク・アドレスを含んでいる。スキャナ・サーバー・コンピュータ１３０がスキャナ・サーバー１３０内にマシーン名テーブル・エントリー情報をつくりださせるセッション初期設定コマンドを受信した後に、スキャナ・サーバー１３０は図２９に示されているようなセッション初期設定コマンドの受領を確認応答するセッション初期設定確認応答パケット・ヘッダー６７０を伝送する。
【０２１６】クライアント・コンピュータ１０２がスキャンからファイル動作のためのそれ自体のスキャナ・サーバー・コンピュータ１３０への登録を解除することを望んだ場合、クライアント・コンピュータ１２０はセッション停止コマンドを図３０に示されているパケット・ヘッダー６９０に従って送る。
【０２１７】このパケット・ヘッダー６９０はクライアント・コンピュータ１０２のマシーン名あるいは名前のサイズと、その後にそのマシーン名を定義しているデータが続くデータ・サイズ・フィールド７０８を含んでいる。スキャナ・サーバー１３０がそのセッション停止コマンドを受領した後、マシーン名テーブル６２０内のそのクライアント・コンピュータ１２０に対応するエントリー情報が消去され、サーバー・コンピュータ１３０がクライアント・コンピュータ１０２に対して図３１に示されているパケット・ヘッダー・ストラクチャ７１０を用いてセッション停止確認応答コマンドを送る。
【０２１８】ネットワーク１２０を介してスキャナ・サーバー１３０からクライアント・コンピュータ１０２に画像情報あるいは画像ファイルを送るためには、図３２に図示されている保存ファイル入手コマンドあるいはプロトコル・ヘッダー９００が本発明のスキャンからファイル・アプリケーション側面で用いられる。
【０２１９】このコマンドは図１８に示されているファイル読み出し確認応答コマンドと同様の形態で作動する。画像ファイルのスキャナ・サーバー１３０からクライアント・コンピュータ１０２への伝送準備が整うと、スキャナ・サーバー１３０が画像情報を付加データとして有している保存ファイル入手コマンドを送ることによってデータの伝送を開始する。
【０２２０】保存ファイル入手コマンド９００のデータ・サイズ・フィールド９１８はその後に来るデータのサイズを示しており、このサイズは最大パケット・サイズからパケット・ヘッダーのサイズを含んだ量を差引いて、さらに送られるファイル・データのサイズを加えたものと等しい。画像データは通常長たらしいので、ファイル・データの画像はそれぞれ対応するパケット・ヘッダーを有する複数のパケットで送られる。
【０２２１】図３３はデータの受領を確認するためにクライアント・コンピュータ１０２からスキャナ・サーバー１３０に送られる保存ファイル入手確認パケット・ヘッダー９２０を示している。この保存ファイル入手確認パケット・ヘッダー９２０は完全な画像ファイルの伝送がうまくいった後、クライアント・コンピュータ１０２からスキャナ・サーバー１３０に送られる。
【０２２２】また、保存ファイル入手確認パケット・ヘッダーはスキャナ・サーバー１３０からの各保存ファイル入手パケット・ヘッダー、一つの画像ファイルの各末尾、あるいは予め決められた数の受信された保存ファイル入手パケット・ヘッダー毎に送られる。保存ファイル入手確認パケット・ヘッダー９２０のデータ・サイズ・フィールド９４０はそのパケット・ヘッダー９２０を送るクライアント・コンピュータのマシーン名のサイズを含んでいる。パケット・ヘッダー９２０に続く、あるいはそれに付加されたデータはそのクライアント・コンピュータの名前を含んでいる。
【０２２３】図３４〜３７のフローチャートにスキャンからファイル動作中に行われるプロセスを示す。適切なソフトウエアを開始し、クライアント・コンピュータ１０２およびファイル・キャッチャー・ソフトウエア１１２、クライアント・プロトコル・エンコーダ／デコーダ・ソフトウエア１０８、サーバー・プロトコル・エンコーダ／デコーダ１３２、スキャン・タスク・ソフトウエア１３４、およびＴＷＡＩＮドライバーを含むスキャナ・サーバー・コンピュータ１３０にロードされた後、ステップ７４０でスキャンからファイル動作のために使うことができるスキャナ１４４などのネットワーク・スキャナについての判定が行われる。
【０２２４】ステップ７４０は図１９のステップ４５６が行われるのと同様の方法で実行することができ、これについての説明は記述を簡潔にするためにここでは省略する。
【０２２５】複数のワークグループあるいはネットワーク・スキャナが使える場合は、ステップ７４０はユーザーが複数のワークグループ・スキャナの一つを指定できるようにする図１９のステップ４５８および４６０と同様のステップを含むこともできる。さらに、クライアント・コンピュータ１０２を複数のスキャナ・サーバー・コンピュータに登録できるように本発明を実施することも可能である。この場合、クライアント・コンピュータをスキャナ・サーバーに登録するステップ７４２〜７５８はそのクライアント・コンピュータが登録されるべき各サーバーで行われる。
【０２２６】スキャンからファイル動作のために用いられるべきサーバーが決まったら、クライアント・コンピュータ１０２はクライアント・マシーン名、クライアント・アドレス、およびステップ７４２のポート番号を含みながら、図７のセッション開始コマンドをスキャナ・サーバー１３０へ伝送する。
【０２２７】ステップ７４４で、このセッション開始コマンドはサーバー１３０で受領され、サーバー１３０は図４に示すプロセスＩＤテーブル１５０内にエントリー情報をつくる。その後、サーバー１３０は図８に示すセッション初期設定確認応答（open session acknowledge) コマンドをステップ７４６でクライアントに送る。ステップ７４８で、クライアント・コンピュータ１０２はスキャンからファイル動作のためにクライアント・コンピュータ１０２をサーバー１３０に登録するために、図２８のセッション初期設定コマンドをスキャナ・サーバー１３０に送る。セッション初期設定コマンドはクライアント・コンピュータの名前あるいはマシーン名、クライアントのアドレス、およびポート番号を含んでいる。
【０２２８】本発明者は同じ情報がセッション開始コマンドとセッション初期設定コマンドで送られるで送られるようにするものであり、したがって、これらの両方のコマンドに同じデータが付加されているか、あるいはパケット・ヘッダーに続いているものを伝送するのは重複であり、あるいは不必要であると考えられるであろう。
【０２２９】しかしながら、これらのコマンドを別のコマンドとして分離しておいて、それぞれのコマンドと共に必要な情報を送るようにした方が、本発明の今後のバージョンをよりインプリメントしやすくするであろう。例えば、もし本発明の今後のバージョンがセッション初期設定コマンドがセッション開始コマンドに付加されるのとは別のデータの付加を必要と必要とするようになれば、そのソフトウエアに対する変更の必要性はあってもほんのわずかであろう。
【０２３０】しかしながら、望ましければ今後のフレキシビリティをなくしてどんなデータもセッション初期設定コマンドとは送らないようにすることも可能であろう。この場合、セッション初期設定コマンドと共に用いられるデータはスキャナ・サーバー１３０の保存情報から読み出される。
【０２３１】ステップ７５０で、サーバー・コンピュータ１３０がクライアント・コンピュータ１０２からセッション初期設定コマンドを受け取り、図２７のマシーン名テーブル内にそのマシーン名テーブル内の各エントリー情報にシーケンシャルに割り当てることができるインデックス、マシーン名であるクライアント・コンピュータの名前、そしてポート番号である場合もあるそのクライアントのネットワーク・アドレスを含むエントリー情報をつくる。つぎに、ステップ７５２で図２９に示してあるようなセッション初期設定確認応答コマンドをサーバー・コンピュータ１３０からクライアント・コンピュータ１０２に送る。
【０２３２】つぎに、ステップ７５４で図９のセッション終了コマンドがクライアント・コンピュータ１０２からスキャナ・サーバー１３０に送られる。ステップ７５６で、スキャナ・サーバー１３０がプロセスＩＤテーブル内の対応するエントリー情報を消去して図１０のセッション終了確認応答コマンドをスキャナ・サーバー１３０からクライアント・コンピュータ１０２に送る。
【０２３３】ステップ７５８で、クライアント・コンピュータはスキャナ・サーバー１３０によっておくられたセッション終了確認応答コマンドを受け取り、クライアント・コンピュータ１０２のファイル・キャッチャー・プログラム１１２をできるだけ小さくする。小さくされたファイル・キャッチャー・プログラム１１２はそのクライアント・コンピュータ１０２に割り当てられたアドレスとスキャンからファイルへの動作に割り当てられたポートを引き続きチェックして、スキャナ・サーバー１３０から画像ファイルが入ってきていないかどうか調べる。
【０２３４】このようにして、クライアント・コンピュータ１０２はスキャナ・サーバー１３０から送られる画像ファイルを待機しながら、他のいかなる動作でも（例えば、ワード・プロセッシング動作などスキャニングには関係ない動作）でも行うことができる。
【０２３５】ステップ７５８の実行後、クライアント・コンピュータ１０２はスキャナ・サーバー１３０に登録され、ユーザーはいつでもスキャンからファイルへの操作を行うことができる。ユーザーがある画像ファイルを入手してその画像ファイルをクライアント・コンピュータ１０２に送りたいと望む場合、ユーザーはそのユーザーが登録されているスキャナ・サーバー１３０に接続されたネットワーク・スキャナ（あるいは他の画像獲得装置）のところに行き、ステップ７６０で表示されるメニューからスキャンからファイルへのオプションを指定する。
【０２３６】クライアント・コンピュータ１０２が複数のスキャナ・サーバーに登録されている場合は、ユーザーは自分が登録されているどのスキャナ・サーバーに行ってもよい。本発明はスキャンからアプリケーションへの動作とスキャンからファイルへの動作の両方をスキャナ・サーバー・コンピュータ１３０で行えるようにしてくれる。
【０２３７】本発明の好ましい実施の形態においては、グラフィック・メニューがスキャナ・サーバー１３０のコンピュータ・モニター上に表示される。このメニューはスキャンからアプリケーション動作とスキャンからファイルへの動作のどちらを実行したいのかをユーザーに選択できるようにしてくれる。ステップ７６２で、ユーザーはスキャンからファイルへの動作を選択する。
【０２３８】スキャンからファイルへのオプションを指定した後、サーバーはスキャンからファイル操作に関してスキャナ・サーバー１３０に登録されている複数のクライアント・コンピュータを表示し、図２７のマシーン名テーブル内にエントリー情報を持つ。
【０２３９】図３８はスキャナ・サーバー１３０の登録マシーン名に対応する名前のリストを含む画像８００を示している。名前のリストは強調表示（図中の８０２）されている“Ｍａｒｙ”という名前を含んでいる。ユーザーがクリックすると、指定ボタン８０４が強調表示された名前を選択する。図３８の画像８００にはまたキャンセル・ボタン８０６とヘルプ・ボタン８０８も示されており、これらを用いることにより指定動作を取り消したり、ユーザーにヘルプ情報が与えられたりする。
【０２４０】ユーザーが図３８の画像表示を用いてステップ７６２で画像ファイルを受け取るためにそのクライアント・コンピュータを指定した後、ユーザーはステップ７６４でＴＷＡＩＮドライバー１３６を用いてスキャナ・サーバー１３０で走査パラメータを指定する。パラメータを指定するこの操作中に、スキャナ・サーバー１３０のスキャン・タスク・ソフトウエア１３４がＴＷＡＩＮとの互換性を有するいずれかの画像獲得ソフトウエアとして作動する。
【０２４１】スキャナ・サーバーのＴＷＡＩＮドライバー１３６は通常のＴＷＡＩＮ標準に従ってインプリメントすることができ、スキャンからアプリケーション・プロセス中にクライアント・コンピュータ１０２によって用いられるバーチャルＴＷＡＩＮドライバー１０６に関して述べたようなバーチャルＴＷＡＩＮドライバーとしては作動しない。ステップ７６４での走査パラメータの設定は好ましくは本発明のスキャンからアプリケーション動作に関連して述べた図２５に示したグラフィック・ユーザー・インターフェースと類似したグラフィック・ユーザー・インターフェースを用いて実行される。
【０２４２】上に述べたような走査パラメータの設定に代わる方法として、本発明のスキャンからファイル側面のための走査パラメータを、この発明のスキャンからパラメータ側面のために用いられたのと同様に方法で設定することも可能である。
【０２４３】画像はステップ７６６でスキャナ１４４か、あるいはＴＷＡＩＮドライバー１３６を用いる他の画像獲得装置を用いて走査される。この走査動作はスキャナ・サーバー１３０、ＴＷＡＩＮドライバー１３６、およびスキャン・タスク・ソフトウエア１３４によって制御される。
【０２４４】ステップ７６８で、スキャナ・サーバー１３０は獲得された画像ファイルを指定されたクライアント・コンピュータ１０２に送信する。なお、ステップ７６８でクライアント・コンピュータ１０２に送られる画像ファイルはそのクライアント・コンピュータ１０２でランしているアプリケーション１０４には送られず、クライアント・コンピュータ１０２の記憶装置１１０内のファイルに保存される。
【０２４５】画像ファイルをスキャナ・サーバー１３０からクライアント・コンピュータ１０２に送るためには、スキャナ・サーバー１３０はセッション開始コマンドあるいはパケット・ヘッダーをクライアント・コンピュータ１０２に送り、クライアント・コンピュータ１０２はスキャナ・サーバー１３０にセッション初期設定確認応答コマンドを送り返す。
【０２４６】この動作に応えて、スキャナ・サーバー１３０はプロセスＩＤテーブル１５０内に対応するエントリー情報をつくる。つぎに、画像ファイルが図３２に示されている保存ファイル入手コマンドかパケット・ヘッダーを用いてスキャナ・サーバー１３０からクライアント・コンピュータ１０２に送られる。その画像情報を送るパケット・ヘッダーを受領すると、クライアント・コンピュータ１０２は図３３に示されているような保存ファイル入手確認応答コマンドかパケット・ヘッダーをスキャナ・サーバー１３０に送る。
【０２４７】クライアント・コンピュータ１０２へのその画像の転送が完了すると、スキャナ・サーバー１３０はクライアント・コンピュータ１０２にセッション終了コマンドを送り、クライアント・コンピュータ側はセッション終了確認応答コマンドで対応する。別の方法として、クライアント・コンピュータ１０２がセッション終了コマンドを送り、スキャナ・サーバー１３０が対応する確認応答を送る。」（第１４ページ第２５欄第３７行目〜第２５ページ第４７欄第２３行目）
　
Ｆ．「【０２７０】
【発明の効果】以上説明したように、本発明に係るスキャナからネットワークを介してクライアント・コンピュータに画像情報を伝送するための画像伝送方法、画像伝送システム、コンピュータにより利用可能な媒体、および、メモリにあっては、コンピュータ・ネットワークを介してスキャナからクライアント・コンピュータへ画像情報を伝送することができる。
【０２７１】また、最初にネットワーク・ファイル・サーバー上に画像を記憶する必要なしに、その画像情報をスキャナからローカル・コンピュータに直接伝送することができる。
【０２７２】また、スキャナがクライアント・コンピュータに直接接続されている場合と同様に、クライアント・コンピュータ上で実行中のアプリケーション・プログラムがコンピュータ・ネットワークを介して情報を制御したり、画像スキャナからの情報を受け取ったりすることができる。
【０２７３】また、それに接続されたスキャナを有するスキャナ・サーバーからクライアント・コンピュータに、その画像ファイルを別個のファイル・サーバー上に保存する必要なく伝送することができる。
【０２７４】また、画像ファイルを別のファイル・サーバーに記憶させることなく、スキャナと接続しているスキャナ・サーバーからクライアント・コンピュータへ画像ファイルを伝送することができる。」（第２６ページ第５０欄第３８行目〜第２７ページ第５１欄第１２行目）
　
　以上の記載によれば，引用例１には，次の発明（以下「引用発明」という。）が記載されている。
　
「クライアント・コンピュータ１０２，スキャナ・サーバー・コンピュータ１３０及びファイル・サーバー１２２がコンピュータ・ネットワーク１２０によって接続され，
　各コマンドと情報はクライアント・コンピュータ１０２とスキャナ・サーバー１３０間をパケットを用いて送信され，
　スキャンからアプリケーションへの側面により，ユーザーはクライアント・コンピュータ１０２上で動作するアプリケーションの中からスキャニング操作の種々の側面を，あたかもスキャナが，クライアント・コンピュータ１０２に直接接続されたように制御することができ，
　スキャンからアプリケーションへの側面で使用されるコマンドは，セッション開始，セッション開始確認応答，セッション終了，セッション終了確認応答，スキャナ・パラメータ読み込み，スキャナ・パラメータ読み込み確認応答，パラメータ設定，パラメータ設定確認応答，スキャナ・ジョブ停止，スキャナ・ジョブ停止確認応答，ファイル読み込み，そしてファイル読み込み確認応答などであり，
　スキャンからファイルへの側面においては，スキャナ・サーバー・コンピュータ１３０が画像ファイルをクライアント・コンピュータ１０２のローカル記憶装置に伝送し，
　スキャンからファイルへの側面では，セッション開始，セッション開始確認応答，セッション終了，セッション終了確認応答，それに，セッション初期設定，セッション初期設定確認応答，セッション停止，セッション停止確認応答，保存ファイル入手，そして保存ファイル入手確認応答を含む各コマンドが使用され，
　パケットは，パケット・ヘッダーとデータ部分を含み，
　パケット・ヘッダーは，スキャナ・サーバー・コンピュータ１３０のセッション管理と制御のためにクライアント・コンピュータ１０２によって使用され，
　データ部分は，ネットワーク・セッション・データを含み，マシーン名や，ネットワーク・アドレス，スキャナ・パラメータ，そして画像データを送信するために使用され，
　パケット・ヘッダーは，
　パケットの構成を識別するパケット・タイプ・フィールドと，
　パケットを利用するマシーンや機能のタイプを識別する装置ＩＤフィールドと，
　プロトコルの現在のバージョンを識別するフィールドと，
　プロトコルの状態を識別するフラグ・フィールドと，
　現パケットを識別するシーケンス番号フィールドと，
　受信した最後の誤りなしのパケットを確認したことを表す確認応答番号フィールドと，
　フラグ・フィールドのビット０に関連するエラーの規定のタイプを表すエラー番号フィールドと，
　パケットに伴うコマンドあるいはレスポンスを表すコマンド・フィールドと，
　パケット・ヘッダーに続く様々な長さのデータのサイズを含んでいるデータ・サイズ・フィールドと，
を有し，
　スキャンからアプリケーションへの側面において，
　ファイル・サーバー１２２は，ネットワーク１２０上で利用可能な全サーバーのディレクトリを保持し，
　クライアント・コンピュータ１０２は，ファイル・サーバー１２２内に保存されている情報を調べ，
　クライアント・コンピュータ１０２は，利用可能なスキャナ・サーバーとして，スキャナ・サーバー・コンピュータ１３０を選び，
　スキャナ・サーバー・コンピュータ１３０において，原稿はスキャンされ，
　その画像データ・ファイルが，ファイル読み込み確認応答コマンドを使って，スキャナ・サーバー１３０からクライアント・コンピュータ１０２へ送信される，
方法。」
　
（ｂ）引用例２
　引用例２には，図面とともに次の事項が記載されている。
　
Ａ．「【０００１】
【産業上の利用分野】本発明は、自己の通信機器と、他の通信機器との間で情報の交換を行う通信機器に関する。」（第４ページ第５欄第３９行目〜同欄第４３行目）
　
Ｂ．「【００１７】(3)   従来のネットワークは、有線通信手段を用いて特定の場所に設置された装置や机の上の装置を接続しており、ネットワークを構成する装置や接続されている装置を利用するユーザは固定されたものである。このネットワークには、特定のサービスを提供する装置（サーバ）が存在し、ユーザの要求に対してサービスの提供を行なう。
【００１８】サーバの例としては、共有データファイルサーバ、かな漢字変換サーバ、辞書サーバ、音声認識サーバ、翻訳サーバ等が挙げられる。いずれの場合もサービス要求時に、要求者（クライアント）とサーバとの間に通信リンクを設定し、サービス終了後に通信リンクを消去する。
【００１９】従来のネットワークでは、どの装置が特定のサービスを行なうかを予め決めておき、ネットワークに接続された各装置に情報を登録することにより、利用者はサービス要求時に、自端末の登録情報を元にサービスを行なう装置と自動的に接続を行なうことができる。また、ネットワーク上に複数のサービス提供が可能な装置が存在する場合には、特定の一台に負荷が集中しないように利用者毎に登録内容を変えることにより負荷を均等にすることが可能である。
【００２０】しかし、各装置に情報を登録しておく方法は、サーバの変更が生じた場合に、各装置のデータを更新する必要が生じ、利用者への負担となる。ネットワークの構成の変化やサービスを行なう装置の変更を柔軟に行なうために、ネットワークに接続された特定の装置に、ネットワークの構成情報とサービスを提供する装置の情報の登録を行ない、その他の装置は、電源投入後の初期化作業の途中でこのような情報を自分の装置にダウンロードを行なう方法が利用されている。管理を行なう装置の情報を更新することにより、各装置は変更に基づきサービス要求を行なうことができ、管理の手間を省くことが可能となる。」（第５ページ第７欄第２８行目〜同ページ第８欄第１１行目）
　
Ｃ．「【００４６】(3)   従来技術の(3) で説明したように、特定の装置においてネットワーク上でのサービスに関する情報を管理する方式では、サービスを行なう装置は常に動作をしている必要があり、そのような装置に障害が生じた場合は、他の装置は構成情報を得ることができなくなってしまい、サービスを受けることができなくなってしまう。
【００４７】また、本出願人が提案した任意の場所で任意の相手と通信を行なう通信機能を有する装置により構成されたネットワークでは、ネットワークを構成する装置を予め特定することができないため、ネットワーク上で提供されるサービスに関する情報を、予め各装置や、あるいは特定の装置を選び出し登録を行なうことはできない。そのため、ネットワークを構成するたびにサービスに関する情報を各装置に登録するか、あるいは特定の装置に登録する必要が生じる。
【００４８】しかし、ネットワークの構成に変更が生じるたびに、各装置の情報を変更する方法は、そのような作業を行なうことは利用者の負担になってしまう。あるいは、特定の装置に情報を登録する方法では、利用者の負担を軽減することが可能ではあるが、その情報を管理する装置が、ネットワークより退出してしまった場合は、サービスに関する情報を失ってしまう。
【００４９】そこで、第３，４の発明は、ネットワークを構成する装置により提供できるサービスを予め各装置やサーバに登録する必要がなく、利用者からのサービス要求時に、目的の装置と自動的に接続しサービスを受けることを可能とする通信機器を提供することである。」（第６ページ第１０欄第３９行目〜第７ページ第１１欄第１６行目）
　
Ｄ．「【００５６】第３の発明の通信機器は、この通信手段を介して他の通信機器と通信を行う通信手段と、前記通信手段を介して他の通信機器にサービス要求を行うサービス要求手段と、他の通信機器からのサービス要求を検知するサービス要求検知手段と、このサービス要求検知手段がサービス要求を検知した場合にサービス要求を行なった通信機器を除く通信機器の中からサービスを提供する通信機器を選定するサーバ選定手段とを有する。」（第７ページ第１２欄第１１行目〜同欄第１９行目）
　
Ｅ．「【００７１】第３の発明の通信機器について説明する。
【００７２】通信手段は、他の通信機器と通信を行う。すなわち、通信手段は、他の情報処理通信機器へのデータ送信、他の通信機器からのデータを受信する。
【００７３】サービス要求手段は、前記通信手段を介して他の通信機器にサービス要求を行う。すなわち、サービス求手段は、利用者からのサービス要求に基づき、決められた手続きに従って他の通信機器に、通信手段を用いてサービス要求を行う。
【００７４】サービス要求検知手段は、前記通信手段を介して他の通信機器からのサービス要求を検知する。すなわち、通信手段がデータを受信した場合に、サービス要求検出手段は、データの解析を行なう。この時決められた信号と一致した場合は、サービス要求信号を出力する。
【００７５】サーバ選定手段は、このサービス要求検知手段がサービス要求を検知した場合にサービス要求を行なった通信機器を除く通信機器の中からサービスを提供する通信機器を選定する。すなわち、サービス要求信号を検出した場合は、サーバ選定手段は、サービス要求を行なった通信機器を除く通信機器の中から決められた手順に従いサービスを行う通信機器を選定する。これにより、サービス要求を受信したときに、ネットワークに接続されている通信機器の中からサーバを選定することにより、ネットワークに属する通信機器の情報を各通信機器や、特定の通信機器に登録する必要がなく、利用者はサービスを行なう通信機器と通信を行なうことが可能となる。」（第８ページ第１４欄第３行目〜同欄第３０行目）
　
Ｆ．「【０２７７】第  ３，４  の  発  明
第１の実施例
図２１は、本実施例に係る通信機器であるサービスを要求する情報処理装置４００の構成を示すブロック図である。図２２にサービス要求装置のフローチャートを、図２３にサービス要求受信装置のフローチャートを示す。
【０２７８】制御部４０２は、ＣＰＵで構成され、サービスを要求するプログラムの実行を行なう。
【０２７９】データ記録部４０４は、メモリーやハードディスクで構成され、サービスを要求するプログラムや提供可能なサービスに関する情報や利用者に関する情報を記録する。
【０２８０】表示部４０６は、使用者にデータの表示を行なう。
【０２８１】データ入力部４０８は、使用者からのキー入力やマウスの入力の管理を行なう。
【０２８２】通信制御部４１０は、外部とのデータのやり取りを行なう物であり、有線、無線、光、赤外線、音を利用した通信方式が利用できる。又、一旦受信したデータを格納する受信バッファを有する。
【０２８３】制御部４０２、データ記録部４０４、表示部４０６、データ入力部４０８、通信制御部４１０は、バス４１２で接続されておりデータや制御命令のやり取りを行なう。また、サービスの提供を行なう情報処理装置の構成も同様のものとする。
【０２８４】本実施例が効果的に利用できる状況として、次のような状況を設定する。
【０２８５】情報処理装置Ａ、Ｂ、Ｃ、Ｄ、Ｅが存在し、それぞれ同一のネットワークに接続している。情報処理装置Ａを有する使用者がサービスの要求を行なったとする。
【０２８６】（情報処理装置Ａの処理）情報処理装置Ａのデータ入力部４０８は使用者からのサービス要求指示を受ける。制御部４０２は、サービス要求を行なうためにサービス要求パケットを作成し（図２２のステップｐ１参照）、通信制御部４１０より送信する（図２２のステップｐ２参照）。
【０２８７】図２４にパケットの構成例、図２５にサービス要求パケット構成例を示す。
【０２８８】パケットを、パケット長部、宛先装置識別情報部、送信装置識別情報部、データ部、ＣＲＣより構成する。
【０２８９】パケット長部のパケット長は、パケットの長さを示す。
【０２９０】宛先装置識別情報部の宛先装置識別情報は、パケットの受信を行なう装置を指定するための情報である。
【０２９１】送信装置識別情報部の送信装置識別情報は、パケットを送信した装置の識別情報を示す。
【０２９２】データ部のデータは、装置間で送受信するデータを示す。
【０２９３】ＣＲＣは、誤り検出を行なうためのものである。
【０２９４】具体的には、サービス要求パケットでは、ネットワーク上の全ての装置に送信するため、予め決められた全装置を示す番号を宛先装置識別情報部に設定する。送信装置識別情報部には、装置Ａの識別番号を設定する。データ部には、予め決められたサービス要求を示す情報を設定する。
【０２９５】（情報処理装置Ｂ、Ｃ、Ｄ、Ｅの処理）情報処理装置Ｂ、Ｃ、Ｄ、Ｅの通信制御部４１０は、データを受信し受信バッファに一旦格納する（図２３のステップｑ１参照）。
【０２９６】通信制御部４１０は、受信したデータの宛先装置識別情報を解析する（図２３のステップｑ２参照）。この場合全ての装置宛てなので、受信バッファから、パケット長で示されたデータを読み出す。
【０２９７】通信制御部４１０は、パケットのデータ部のデータと、予め決められたサービス要求を示す情報との比較を行なう。
【０２９８】一致した場合は、制御部４０２にサービス要求を通知する。制御部４０２は、サービス要求宛先を調べる。全ての装置宛ての場合は、サーバの選定を行なうステップを実行する。
【０２９９】以下に、サービスの提供を行なうサーバの選定方法について説明する。
【０３００】一例として、サービス要求装置上でサーバを選定する方法を説明する。
【０３０１】（情報処理装置Ｂ、Ｃ、Ｄ、Ｅの処理）サービス要求を受信した装置Ｂ、Ｃ、Ｄ、Ｅの制御部４０２は、サーバ選定を行なうためのサーバ選定実行要求パケットを作成し（図２３のステップｑ３参照）、通信制御部４１０より送信する（図２３のステップｑ４参照）。
【０３０２】図２６にサーバ選定実行要求パケット構成例を示す。
【０３０３】宛先装置識別情報にサービス要求装置Ａの識別番号を設定する。
【０３０４】送信装置識別情報には自装置の識別番号を設定する。
【０３０５】データ部には、サーバ選定実行要求を示すデータと、選定用のデータを設定する。選定用のデータとしては、各装置の識別番号、ＣＰＵの負荷情報、使用者識別番号等が利用できる。どのデータを使用するかは予め決めておく。
【０３０６】（情報処理装置Ａの処理）装置Ａは、自分宛てに送信されたパケットの解析を行なう（図２２のステップｐ３，４，５参照）。サーバ選定実行要求を行なった装置の識別番号を管理する。予め決められた一定時間だけサーバ選定実行要求パケットの到着を待つ（図２２のステップｐ６参照）。
【０３０７】一定時間経過後、サーバ選定実行要求を行なった装置から、選定用データをもとにサーバの選定を行なう（図２２のステップｐ７参照）。選定方法は、受信した選定用データの内で最小のデータを送信した装置をサーバとして選定する。あるいは、最大のデータを送信した装置等が考えられる。
【０３０８】サーバ選定後、選定された装置に対してサービス要求を行なう（図２２のステップｐ８，９参照）。この場合は、パケットの宛先情報にサーバに選定された装置の識別番号を設定する。ここでは仮に装置Ｂが選定されたものとする。
【０３０９】（情報処理装置Ｂの処理）装置Ｂの制御部４０２は、受信したパケットを解析することにより自分宛てのサービス要求を検出する。
【０３１０】装置Ｂの制御部４０２は、サービスを提供するプログラムを実行する。
【０３１１】（情報処理装置Ａの処理）サービス要求装置Ａの制御部４０２が、サーバ選定後サーバ選定結果を示すパケットを作成し（図２２のステップｐ１０参照）、通信制御部４１０より送信することにより（図２２のステップｐ１１参照）、ネットワーク上の各装置は、サーバ選定結果を知ることができる。
【０３１２】上述した方法とは異なるサーバの選定方法について説明する。
【０３１３】他のサーバの選定方法は、サービス要求を受けた各装置Ｂ、Ｃ、Ｄ、Ｅが自律的に行う方法が考えられる。
【０３１４】例えば、各装置Ｂ、Ｃ、Ｄ、Ｅの処理の能力情報等の選定用情報をそれぞれ交換し、各装置Ｂ、Ｃ、Ｄ、Ｅの制御部４０２が、処理の能力を評価する。
【０３１５】そして、処理の能力が一番大きい装置をサーバとして選定し（例えば、装置Ｂ）、結果をそれぞれに送りあい確認する方法が考えられる。
【０３１６】サーバ選定結果をサービス要求装置Ａに通知する。
【０３１７】このとき、ある装置がダウンしていたり、通信障害が生じている場合は（例えば、装置Ｃ）、その装置Ｃは、選定用情報を送信することができないため、サーバの候補に含まれない。
【０３１８】以上のように、サービス要求時に、ネットワーク上の各装置にサービス要求を行ない、サーバの選定を行なうことにより、予めサービスを提供する装置の情報を各装置に登録したり、特定の装置に登録を行なわなくても、自動的にサービスを行なう装置と通信することが可能となる。さらに、サービス要求時に装置Ｃがネットワークより退出した場合や、装置Ｃとの間に通信障害が生じている場合は、装置Ｃからサーバ選定実行要求パケットは到着しない。それゆえ、装置Ｃを除いてサーバの選定を行なうので、サービス要求を行なった時に、通信可能な状態の装置の中からサーバを選定することが可能となる。」（第１６ページ第３０欄第１０行目〜第１８ページ第３３欄第１１行目）
　
Ｇ．「【０３９４】第９の実施例
第９の実施例について、第１、第２の実施例と異なる実行ステップについて説明する。
【０３９５】サービス要求装置の制御部４０２は、サービス要求を行なうときに、サーバとして選定する装置の条件及び基準値を付加したサービス要求パケットを作成する。
【０３９６】図３１に条件付きサービス要求パケットの構成例を示す。サーバの選定条件として、ＣＰＵの処理能力や、搭載メモリーサイズ、現在のＣＰＵの負荷等が考えられる。このような条件を、予め数値化して登録しておく。
【０３９７】次に、条件つきサーバの選定方法について説明する。
【０３９８】サービス要求を受けた各装置の制御部４０２は、サービス要求パケットのサーバ条件と基準値を調べ、自分の装置が条件を満たしているかどうか判定する。
【０３９９】条件を満たしている場合は、制御部４０２は、サーバ選定実行要求パケットを作成し、通信制御部４１０よりサービス要求装置に送信する。
【０４００】条件を満たした装置のみが、サーバ選定実行要求パケットをサービス要求装置に送信することにより、条件を満たす装置からサーバを選択することが可能となる。
【０４０１】以上のようにサービスを要求するときに条件を付加し、この条件に適合する装置からサーバを選定することにより、能力の高い装置や負荷の軽い装置をサーバとして選定できるために、効率の良いサービスを提供することが可能となる。」（第２０ページ第３８欄第２５行目〜第２１ページ第３９欄第４行目）
Ｈ．「【０５０７】第３の発明の通信機器によれば、サービス要求を行ったときに、ネットワークに接続されている通信機器からサービスの提供を行なう通信機器を選択するので、サーバに関する情報を各通信機器や特定の通信機器に登録を行なう必要がなく、任意の相手とネットワークを作成した場合でもサービスを受けることが可能となる。」（第２５ページ第４７欄第４行目〜同欄第１０行目）
　
５．対比
　本願発明と引用発明を対比する。
　引用発明の「クライアント・コンピュータ１０２」，「コンピュータ・ネットワーク１２０」，「スキャナ・サーバー・コンピュータ１３０」及び「パケット」は，本願発明の「クライアント」，「ネットワーク」，「サーバ」及び「伝送パケット」に相当する。
　引用発明において，各コマンドと情報がクライアント・コンピュータ１０２とスキャナ・サーバー１３０間をパケットを用いてコンピュータ・ネットワーク１２０を通じて送信されることにより，クライアント・コンピュータ１０２とスキャナ・サーバー１３０間でスキャニング作業を遂行するのは明らかであり，本願発明のＫ，Ｍ及びＮは１を含んでいることから，引用発明は，本願発明の「スキャニング作業を少なくとも含むＫ（ここで、Ｋ≧１）個の作業を遂行してネットワークを通じてＭ（ここで、Ｍ≧１）個のクライアントとＮ（ここで、Ｎ≧１）個のサーバ間の通信のために前記ネットワークを通じて伝送される伝送パケットを用いて前記クライアントと前記サーバ間で、前記作業を遂行するための通信方法」に相当する構成を有している。
　引用発明において，スキャンからアプリケーションへの側面及びスキャンからファイルへの側面における２つの機能の作業があり，パケットに含まれるコマンドは，スキャンからアプリケーションへの側面では，セッション開始，セッション開始確認応答，セッション終了，セッション終了確認応答，スキャナ・パラメータ読み込み，スキャナ・パラメータ読み込み確認応答，パラメータ設定，パラメータ設定確認応答，スキャナ・ジョブ停止，スキャナ・ジョブ停止確認応答，ファイル読み込み，及びファイル読み込み確認応答である一方，スキャンからファイルへの側面では，セッション開始，セッション開始確認応答，セッション終了，セッション終了確認応答，それに，セッション初期設定，セッション初期設定確認応答，セッション停止，セッション停止確認応答，保存ファイル入手及び保存ファイル入手確認応答であることから，引用発明の「パケット」は，本願発明の「前記サーバとクライアント間で多機能の作業を遂行することができるようにする制御内容を含む伝送パケット」に相当する。
　引用発明の「プロトコルの現在のバージョンを識別するフィールド」は，本願発明の「前記伝送パケットのバージョン番号を示すバージョン情報を有するバージョンフィールド」と「バージョン情報を有するバージョンフィールド」である点で一致する。
　引用発明の「パケットに伴うコマンドあるいはレスポンス」は，本願発明の「伝送される前記パケットの発生形態」に相当するから，引用発明の「コマンド・フィールド」は，本願発明の「パケット形態表示フィールド」に相当する。
　引用発明において，「パケット・ヘッダーに続く様々な長さのデータのサイズ」及び「画像データ」は，本願発明の「前記作業のデータに関する第２の情報」に相当するから，引用発明の「データ・サイズ・フィールド」及び「データ部分」は，本願発明の「前記作業の属性に関する第１情報と前記作業のデータに関する第２情報中、少なくとも１つを有する属性グループフィールド及びデータグループフィールドの双方または何れか一方」に相当する。
　引用発明の「スキャナ・サーバー・コンピュータ１３０を選」ぶ構成は，本願発明の「情報を受信できるサーバを選別し」の構成に相当する。
　引用発明の「スキャナ・サーバー・コンピュータ１３０において，原稿はスキャンされ，その画像データ・ファイルが，ファイル読み込み確認応答コマンドを使って，スキャナ・サーバー１３０からクライアント・コンピュータ１０２へ送信される」構成は，本願発明の「前記作業を行う遂行工程」に相当する。
　引用発明は，パケットを利用した通信方法であることは明らかである。
　
　すると，本願発明と引用発明とは，次の点で一致する。
＜一致点＞
「スキャニング作業を少なくとも含むＫ（ここで，Ｋ≧１）個の作業を遂行してネットワークを通じてＭ（ここで，Ｍ≧１）個のクライアントとＮ（ここで，Ｎ≧１）個のサーバ間の通信のために前記ネットワークを通じて伝送される伝送パケットを用いて前記クライアントと前記サーバ間で，前記作業を遂行するための通信方法において，
　前記伝送パケットは，前記サーバとクライアント間で多機能の作業を遂行することができるようにする制御内容を含む伝送パケットとして，
　バージョン情報を有するバージョンフィールドと，
　伝送される前記パケットの発生形態を示すパケット形態表示情報を有するパケット形態表示フィールドと，
　前記作業の属性に関する第１情報と前記作業のデータに関する第２情報中，少なくとも１つを有する属性グループフィールド及びデータグループフィールドの双方または何れか一方と，を具備し，
　前記作業を遂行する遂行工程を備えることを特徴とする伝送パケットを利用した通信方法。」
　
　一方，両者は次の点で相違する。
＜相違点１＞
　本願発明では，Ｍ（ここで，Ｍ≧１）個のクライアントによって共有されるＮ（ここで，Ｎ≧１）個のサーバであるのに対し，引用発明では，共有される点について記載がない点。
＜相違点２＞
　本願発明では，バージョン情報を有するバージョンフィールドの示す情報が伝送パケットのバージョン番号であるのに対し，引用発明では，プロトコルの現在のバージョンである点。
＜相違点３＞
　本願発明では，Ｋ個中の少なくとも１つの作業中，パケットを使用する作業の形態を示す作業形態表示情報を有する作業形態表示フィールドを具備しているのに対し，引用発明では，この点について記載がない点。
＜相違点４＞
　本願発明では，伝送パケットの終端を示す終端情報を有する終端フィールドを具備しているのに対し，引用発明では，この点について記載がない点。
＜相違点５＞
　本願発明では，別途の管理プログラム無しで作業を遂行するものであり，また，伝送パケットの中，属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し，サーバ自体および作業に関する属性のうち所望の属性を有するサーバを見つける探索工程と，伝送パケットの中，属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し，探索工程で見つけられたサーバの現在状態をチェックする点検工程と，点検工程でチェックされた状態を利用して情報を受信できるサーバを選別するのに対し，引用発明では，クライアントは，ファイル・サーバー１２２内に保存されている利用可能な全サーバのディレクトリの情報を調べ，サーバを選別する点。
＜相違点６＞
　本願発明では，選別されたサーバにイベントを非同期的に通報することを要求する要求工程を有するのに対し，引用発明では，この点について記載がない点。
　
６．当審の判断
　上記相違点について検討する。
＜相違点１についての検討＞
　クライアント−サーバシステムにおいて，サーバが複数のクライアントに共有される技術は，文献を示すまでもなく，本願優先日前周知である。
　そうすると，引用発明において，上記周知技術を適用して，Ｍ（ここで，Ｍ≧１）個のクライアントによって共有されるＮ（ここで，Ｎ≧１）個のサーバとすることは，当業者が適宜なし得ることである。
　
＜相違点２についての検討＞
　伝送パケットにどのようなフィールドを設けるかは当業者が適宜なし得る設計的事項であるから，引用発明において，プロトコルの現在のバージョンを示すバージョン情報を有するバージョンフィールドに代えて，伝送パケットのバージョン番号を示すバージョン情報を有するバージョンフィールドとすることは，当業者が適宜なし得ることである。
　
＜相違点３についての検討＞
　伝送パケットにどのようなフィールドを設けるかは当業者が適宜なし得る設計的事項であるから，引用発明において，Ｋ個中の少なくとも１つの作業中，パケットを使用する作業の形態を示す作業形態表示情報を有する作業形態表示フィールドを設けることは，当業者が適宜なし得ることである。
　
＜相違点４についての検討＞
　伝送パケットに伝送パケットの終端を示す終端情報を有する終端フィールドを設ける技術は，文献を示すまでもなく，本願優先日前周知である。そうすると，引用発明において，伝送パケットの終端を示す終端情報を有する終端フィールドを設けることは，当業者が適宜なし得ることである。
　
＜相違点５についての検討＞
　引用例２には，クライアントがサーバを選択する手法として，ネットワークに接続された特定のサーバに，サービスを提供するサーバの情報の登録を行ない，特定のサーバにおいてネットワーク上でのサービスに関する情報を管理する方式（本願発明の「別途の管理プログラム」に相当。）に代えて，サービス要求情報（本願発明の「サーバ自体および作業に関する属性のうち所望の属性」に相当。）及び現在のＣＰＵの負荷（本願発明の「サーバの現在状態」に相当。）などの選定条件を含むフィールド（本願発明の「属性グループフィールド」に相当。）を用いて，サーバを選択する技術が記載されている。
　また，引用例２に記載された技術は，本願発明の探索工程及び点検工程に相当する構成を１つの工程で行っているが，その１つの工程を探索工程及び点検工程という２つの工程に分けることは，当業者が適宜なし得ることである。
　さらに，引用発明及び引用例２に記載された技術の技術分野は，パケットを利用するクライアント−サーバシステムで共通する。
　そして，引用発明において，「特定のサーバにおいてネットワーク上でのサービスに関する情報を管理する方式に代えて，パケットを利用してサーバを選択する」という引用例２に記載された技術を適用した場合，ファイル・サーバー１２２がネットワーク１２０上で利用可能な全サーバーのディレクトリを保持するという管理方式（該管理方式は，本願発明の「別途の管理プログラム」に相当する。）に代えて，引用例２に記載されたパケットを利用してサーバを選択する技術が用いられることは明らかであるから，引用発明に引用例２に記載された技術を適用した発明は，別途の管理プログラム無しで作業を遂行するものになるといえる。
　そうすると，引用発明において，引用例２に記載された技術を適用して，別途の管理プログラム無しで作業を遂行するものとし，また，伝送パケットの中，属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し，サーバ自体および作業に関する属性のうち所望の属性を有するサーバを見つける探索工程と，伝送パケットの中，属性グループフィールド及びデータグループフィールドの双方または何れか一方を使用し，探索工程で見つけられたサーバの現在状態をチェックする点検工程と，点検工程でチェックされた状態を利用して情報を受信できるサーバを選別するようにすることは，当業者が容易に想到し得ることである。
　
＜相違点６についての検討＞
　クライアントがサーバへサービスを依頼した場合に，サーバがサービスを実行する際に起きるイベントをクライアントに非同期に通報する技術は，文献を示すまでもなく，本願優先日前周知である。そうすると，引用発明において，選別されたサーバにイベントを非同期的に通報することを要求する要求工程を設けることは，当業者が容易に想到し得ることである。
　
　また，本願発明の構成によって生じる効果も，当業者が予測できるものである。
　
７．むすび
　以上のとおり，本願発明は，引用発明，引用例２に記載された技術及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，他の請求項について検討するまでもなく，本願は，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。