【事件の表示】
　特願２００１−　９８９０８「データ通信プログラム、データ通信プログラムを記録したコンピュータ読み取り可能な記録媒体、データ通信装置およびデータ通信方法」拒絶査定不服審判事件〔平成１４年１０月１１日出願公開、特開２００２−２９７４１０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は、平成１３年３月３０日の出願であって、平成１５年７月２９日付けで拒絶理由通知がなされ、平成１６年２月１２日付けで拒絶査定がなされ、これに対し、同年３月１７日に審判請求がなされるとともに、同日付で手続補正がなされ、平成１８年６月１３日付けで当審より拒絶理由が通知され、同年８月１５日に手続補正がなされたものであり、その請求項６に係る発明（以下、「本願発明」という。）は、特許請求の範囲の請求項６に記載された事項により特定される次のとおりのものと認める。 
　 
「１または複数のファームウェアを分割して複数の分割ファームウェア 
とする分割ステップと、 
　前記複数の分割ファームウェアの中の１の分割ファームウェアを電子メールに添付して、当該分割ファームウェアの書き替え順序に関する情報とともに送信する第１の送信ステップと、 
　前記電子メールに添付された１の分割ファームウェアを取得した相手先から送られてくる当該分割ファームウェアの書き替え結果に関する情報を取得する取得ステップと、 
　前記取得された書き替え結果に関する情報が書き替え成功の情報であることを条件として、前記分割ファームウェアの中の前記第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを電子メールに添付して、当該分割ファームウェアの書き替え順序に関する情報とともに送信する第２の送信ステップとを含む、データ通信方法。」 
　 
２．引用文献 
　 
Ａ．これに対して、当審より通知された拒絶理由に引用された、本願の出願日前である平成１１年１月６日に頒布された刊行物である、特開平１１−３２２３号公報（以下、「引用文献１」という。）には、図面とともに、以下の事項が記載されている。 
　 
（ａ）「【０００２】  
【従来の技術】代表的な情報処理装置であるプリンタにおいては、プリンタの制御を司るＣＰＵや、ＡＳＩＣの動作制御プログラムを格納するメモリに、一般にマスクＲＯＭやＥＰＲＯＭ等が利用されている。  
【０００３】  
【発明が解決しようとする課題】しかしながら、マスクＲＯＭやＥＰＲＯＭは、プログラムを一度書き込むと消去ができないため、プログラムのバージョンアップ、或いはプログラムに不具合が発見された場合等にはＲＯＭ自体を取り替える必要が生じる。特に、プリンタは、印字ヘッド等の可動部分が多く、一般ユーザではＲＯＭの交換が困難なため、交換の際はサービスマン対応となり、コスト、時間がかかるという問題がある。  
【０００４】そこで本発明では、上記のプログラムのような必要な情報を予め自装置内のＲＯＭに格納するのは止め、その必要な情報を外部装置から入手する。特に、その情報の入手の際、外部装置からの入力情報の信頼性の確保が可能な情報処理装置及び情報格納方法の提供を目的とする。 
　・・・（中略）・・・ 
【００１４】また、近年、制御電圧の制御により消去、書き込みが可能な所謂フラッシュＲＯＭが開発されている。そこで、プリンタ内にマスクＲＯＭ等の代わりにフラッシュＲＯＭを備え、前記の双方向通信インタフェースによりホストとの通信を行い、格納されているプログラムのバージョンアップ等を行うべく、そのホストからプリンタ内のフラッシュＲＯＭに対して、新たなプログラムをダウンロードする。これにより、プログラムのバージョンアップの度にＲＯＭを交換する必要は無くなる。 
【００１５】しかしながら、フラッシュＲＯＭを使用する際、プリンタの動作制御プログラムをフラッシュＲＯＭにダウンロード中にＦＡＴＡＬ ＥＲＲＯＲや、電源ダウン等が発生した場合には、フラッシュＲＯＭに格納されているデータが破壊されている可能性が高いため、プリンタを復旧できなくなることが予想される。従って、このような場合、外部装置からダウンロードした動作制御プログラムの受信データとしての信頼性を保証することが重要である。そこで、以下に説明する各実施形態では、動作制御プログラムをフラッシュＲＯＭに格納する場合のデータとしての信頼性を確保する方法を中心に説明する。」 
 
（ｂ）「【００２７】ホストコンピュータ１００から送出されるプリンタ１０００の動作制御プログラムは、予めプリンタ１０００の各動作に合わせてモジュール単位に分割されており、この分割された各モジュールはフラッシュＲＯＭ１０３にブロック単位で格納される。 
　・・・（中略）・・・ 
【００３０】図３は、本発明の第１の実施形態としてのダウンロードのシーケンスを示す図であり（正常終了の場合）、ホストコンピュータ１００とプリンタ１０００との間でＩＥＥＥ１２８４規格のＥＣＰモードにより行われる。
【００３１】ステップ（１）：まず、ホストコンピュータ１００よりプリンタ１０００の動作制御プログラムをダウンロードする場合、ホストコンピュータ１００からプリンタ１０００にダウンロードの問い合わせを行う。 
【００３２】ステップ（２）：ホストコンピュータ１００からの問い合わせに対してプリンタ１０００では、ダウンロードの実行を要求する場合にはホストコンピュータ１００に「応答」を返す。このステータス応答は、前述したフラッシュＲＯＭ１０３のＢｏｏｔ Ｂｌｏｃｋに格納されている通信プログラムにより、インタフェース制御部１０１を介して行われる。 
【００３３】ステップ（３）：次に、プリンタ１０００から「応答」を返されたホストコンピュータ１００は、新たにプリンタ１０００にダウンロードする動作制御プログラムのバージョン番号または記号を送信する。 
【００３４】ステップ（４）：プリンタ１０００は、受信したバージョン番号または記号を、現在フラッシュＲＯＭ１０３に格納されている動作制御プログラムのバージョン番号または記号と比較し、プリンタ１０００内のバージョン番号または記号が古い場合には、ダウンロード要求ステータスを返す。 
【００３５】ステップ（５）：ダウンロードの要求ステータスを受信したホストコンピュータ１００は、プリンタ１０００のフラッシュＲＯＭ１０３内の各セクタに格納すべく、複数のモジュールに区切ってある動作制御プログラムのチェックサムをプリンタ１０００に送信する。 
【００３６】ステップ（６）：チェックサムを受信したプリンタ１０００は、各セクタブロックに現在格納してあるチェックサムを電源投入等のリセットスタート時にＲＡＭ１０４に格納し直してあるため、このＲＡＭ１０４に格納してある各セクタのチェックサムと、今回ホストコンピュータ１００から受信したチェックサムと比較し、異なるチェックサムのモジュールをホストコンピュータ１００に知らせる。 
【００３７】ステップ（７），ステップ（８）：ホストコンピュータ１００は、プリンタ１０００から応答のあったチェックサムの異なる動作制御プログラムのモジュールを、プリンタ１０００にダウンロードする。その際、ホストコンピュータ１００は、送出する動作制御プログラムのモジュールに含まれるデータ数をダウンロードするデータの最初に送信し、次にそのプログラムのモジュール、そしてそのチェックサムを送信する。 
【００３８】ステップ（９）：プリンタ１０００では、順次プログラムデータが送られてくる度にチェックサムの計算が行われ、最後にホストコンピュータ１００から送られてくるチェックサムとプリンタ１０００で計算されたチェックサムとを比較し、同じであれば正常終了のステータスをホストコンピュータ１００に返す。尚、チェックサムは、フラッシュＲＯＭ１０３の各セクタブロックにプログラムモジュールと共に格納する。 
【００３９】これらのステップ（７）〜ステップ（９）の通信は、ステップ（６）で受信した異なるチェックサムのモジュールの分だけ行われ、ダウンロードが終了する。 
　・・・（中略）・・・ 
【００４５】ステップ（１０）：プリンタ１０００のリセットスタートによりホストコンピュータ１００との通信が回復すると、ダウンロードの問い合わせがホストコンピュータ１００からプリンタ１０００になされる。 
【００４６】ステップ（１１），ステップ（１２）：プリンタ１０００では、ホストコンピュータ１００にダウンロードを要請すると共にエラー処理ルーチンから復帰し、ステップ（２）へと移行する。これにより、ホストコンピュータ１００とのバージョン番号または記号及びチェックサムの相違の確認からダウンロードの制御が再開される。即ち、ホストコンピュータ１００は、プリンタ１０００のリセットスタートによりＲＡＭ１０４に格納されたところの、データが破壊されているセクタブロックのチェックサムを認識することができるため、障害の発生によりダウンロードが中断したプログラムモジュールからダウンロードが再開することができる。 
　・・・（中略）・・・ 
【００５７】以上説明したように、ダウンロード中の障害発生を考慮したダウンロードシーケンスを採用し、更に、動作制御プログラムをモジュール単位でフラッシュＲＯＭ１０３の各セクタブロックに格納することにより、ダウンロード中に障害が発生した場合でも、フラッシュＲＯＭ１０３内の最小限のプログラム破壊で済み、再度ダウンロードするときに全領域ダウンロードする必要がない。これにより、ホストコンピュータ１０００から受信する動作制御プログラムの信頼性の確保が可能となる。」 
　  
（ｃ）「【００５９】  
【第２の実施形態】本実施形態は、フラッシュＲＯＭ内の動作制御プログラムの書き換え処理に関する。また、本実施形態も図１のシステムを基にしており、プリンタ１０００の動作制御プログラムに、不具合やバージョンアップ等が必要な場合には、新たな動作制御プログラムをホストコンピュータ１００からプリンタ１０００にダウンロードする。そして、プリンタ１０００は、新たに受信した動作制御プログラムをフラッシュＲＯＭ１０３に書き込むのは同様である。  
【００６０】上述した第１の実施形態の図６（ｂ）の時点でプリンタ１０００のパワーオフ等のトラブルがあった場合、次にプリンタ１０００のパワーオンしたときには、プリンタが暴走する可能性がある。そこで、本実施形態では、その危険性を防止できる書き換えの手順を以下に説明する。尚、本実施形態において、プリンタ１０００は、フラッシュＲＯＭ１０３のアドレスを変換するアドレス変換回路（図８）を備えている。  
【００６１】図７は、本発明の第２の実施形態としてのプリンタの動作制御プログラムの書き換えの手順を説明する図である。  
【００６２】図１３は、本発明の第２の実施形態としてのプリンタの動作制御プログラムの書き換え処理を示すフローチャートである。  
【００６３】図８は、本発明の第２の実施形態としてのプリンタ内のアドレス変換回路のブロック構成図である。同図に示すように、アドレス変換回路は、フラッシュＲＯＭ１０３の各ブロックのアドレス比較回路（ａ）〜（ｃ）、アドレス生成回路（ｅ）から（ｈ）、並びにそれらの回路の接続を選択する選択回路（ｄ）を備える。選択回路の制御は、ＣＰＵ１０２が行うことは言うまでもない。  
【００６４】図９は、本発明の第２の実施形態としてのプリンタ内のアドレス変換回路の内部接続の状態を示す図である。  
【００６５】図７（ａ）において、フラッシュＲＯＭ１０３のＢｏｏｔ Ｂｌｏｃｋ及びＢｌｏｃｋ１からＢｌｏｃｋ３には、第１の実施形態と同様に書き込み禁止のブートプログラムとモジュール化された動作制御プログラムが格納されている。  
【００６６】但し、本実施形態では、Ｂｌｏｃｋ１からＢｌｏｃｋ３のブロックの内、一番大きい記憶容量のブロックと同等以上のサイズを有するバックアップ用の空き領域が設定されている。また、この時のアドレス変換回路（図８）の接続状態は、図９（ｉ）である。  
【００６７】以下、書き換えの手順を図１３を参照して説明する。  
【００６８】ステップＳ１１，ステップＳ１２：ホストコンピュータ１００から、例えば、Ｂｌｏｃｋ２のプログラム書き換えのコマンドを受信した場合には、図７（ｂ）に示すように、まず現在の空き領域に新しいＢｌｏｃｋ２を書き込む。  
【００６９】ステップＳ１３，ステップＳ１４：次に、プリンタ１０００は、新しく書き込んだプログラムのチェックサムを計算し、算出したチェックサムとホストコンピュータ１００から送られたチェックサムとを比較する。 
【００７０】ステップＳ１５：ステップＳ１４でチェックサムが一致しない場合は、ホストコンピュータ１００に再送要求を送り、ステップＳ１１に戻る。  
【００７１】ステップＳ１６，ステップＳ１７：一方、ステップＳ１４でチェックサムが一致した場合は、図８のアドレス変換回路の選択回路（ｄ）を図９（ｊ）のように設定する。これにより、Ｂｌｏｃｋ２をアクセスした場合には、空き領域に書き込まれた新しいＢｌｏｃｋ２のプログラムがＣＰＵ１０２に読み込まれる（図７（ｂ））。  
【００７２】また、図７（ｂ）においてＢｌｏｃｋ２のデータを消去し、その領域を新たな空き領域とする（図７（ｃ））。次に、図７（ｃ）において元の空き領域に保存されている新しいＢｌｏｃｋ２の内容を、現在の空き領域（元のＢｌｏｃｋ２）にコピーする（図７（ｄ））。  
【００７３】ステップＳ１８，ステップＳ１９：そして、新しくＢｌｏｃｋ２に書き込んだプログラムのチェックサムを計算し、そのチェックサムとホストコンピュータ１００から送られたチェックサムとを比較する。  
【００７４】ステップＳ２０：ステップＳ１９でチェックサムが一致しない場合は、ホストコンピュータ１００に当該プログラムの再送要求を行い、ステップＳ１１に戻る。  
【００７５】ステップＳ２１：一方、ステップＳ１９でチェックサムが一致した場合は、図８のアドレス変換回路の選択回路（ｄ）を図９（ｋ）のように設定し、新しいＢｌｏｃｋ２のプログラムが格納されている領域を新たな空き領域とし、ステップＳ１１に戻る。これにより、Ｂｌｏｃｋ２をアクセスした場合には、新しいＢｌｏｃｋ２のプログラムがＣＰＵ１０２に読み込まれる（図７（ｅ））。  
【００７６】ホストコンピュータ１００からダウンロードすべきプログラムが複数有る場合は、上記の手順を繰り返す。尚、本実施形態においても、ホストコンピュータ１００からコマンドの受信、プログラムのダウンロードは、第１の実施形態で説明したダウンロードシーケンスにより行われることは言うまでもない。  
・・・（後略）・・・ 」 
　  
　上記（ｂ）の記載から、引用文献１には、ホストコンピュータからプリンタに動作制御プログラムを分割した分割モジュールをダウンロードするためのデータ通信方法に関する発明が記載されていることは自明である。 
　そして、（ｂ）の段落【００２７】から、ホストコンピュータにおいては、プリンタの動作制御プログラムが、プリンタの動作に合わせてモジュール単位に分割されており、この分割された各モジュールはプリンタのフラッシュＲＯＭにブロック単位で格納されることがわかる。したがって、引用文献１には、プリンタの動作制御プログラムをプリンタの動作に合わせて、分割して複数の分割モジュールとする分割ステップが含まれていると認められる。
　そして、（ａ）の段落【００１５】の記載及び（ｂ）の段落【００４５】、【００４６】、並びに【００５７】の記載によると、引用文献１の発明においては、さらに、プリンタの動作制御プログラムをダウンロード中に電源ダウン等の障害が発生した場合でも、再度ダウンロードするときに全領域ダウンロードする必要がないように、以下のような構成を追加している。
　（ｂ）の段落【００３３】〜【００３６】の記載から、ホストコンピュータは、事前に、プリンタに対して、ホストコンピュータの有する分割された複数のモジュールのチェックサムとプリンタのフラッシュＲＯＭにブロック単位で格納された複数のモジュールのチェックサムとを比較させ、異なるチェックサムのモジュールについて、ホストコンピュータに知らせるようにさせている。
　このようにすることで、ダウンロード中に電源ダウン等の障害が発生した場合、既にダウンロードが正常に行われている分割モジュール以外のモジュールを特定して、これらのモジュールのみをダウンロードするようにしている。
　したがって、引用文献１には、ホストコンピュータからプリンタに問い合わせることで、上記複数の分割モジュールのうち、バージョンアップがなされていない、分割モジュールを特定するステップが追加されていると認められる。
　そして、引用文献１記載の発明の第１の実施形態においては、（ｂ）の段落【００３７】〜【００３９】に記載されているように、ステップ（７）、（８）において、ホストコンピュータは、上記特定された複数のモジュールの１の分割モジュールとそのチェックサムをプリンタに送信する。次に、（ｂ）の段落【００３７】〜【００３９】に記載されているように、ステップ（９）において、プリンタは、送られてきたチェックサムとプリンタで該モジュールから計算したチェックサムとを比較して、同じであれば、正常終了のステータスをホストコンピュータに返す。そして、（ｂ）の段落【００３９】に記載されているように、ホストコンピュータは、プリンタにダウンロードすべき複数のモジュールの数だけ、上記のステップ（７）〜（９）の通信を繰り返す。
　なお、上記第１の実施形態において、プリンタで分割モジュールをフラッシュＲＯＭに書き込むことが必ずしも明記されていないが、引用文献１記載の発明の目的から、モジュールをフラッシュＲＯＭに書き込むことは自明である。
　そして、引用文献１記載の発明の第１の実施形態においては、プリンタで分割モジュールのダウンロードが正常終了した場合には、正常終了のステータスをホストコンピュータに返し、（逆に言えば、ホストコンピュータは、分割モジュールを取得したプリンタから送られてくる当該分割モジュールのダウンロードが成功の場合のダウンロード結果に関する情報をホストコンピュータが取得し）、ホストコンピュータは、プリンタにダウンロードすべき複数のモジュールの数だけ、上記のステップを繰り返すこと、即ち、ダウンロードの成功した分割モジュールとは異なる他の分割モジュールのダウンロードを行うことが記載されている。
　また、引用文献１記載の発明の第２の実施形態においては、（ｃ）の段落【００６８】〜【００６９】に記載されているように、ステップＳ１１〜Ｓ１２において、プリンタは、ホストコンピュータ１００から、例えば、Ｂｌｏｃｋ２のプログラム書き換えのコマンドを受信して、当該分割モジュールとチェックサムとを受信する。（逆にいえば、ホストコンピュータは、特定された複数のモジュールの１の分割モジュールとそのチェックサムをプリンタに送信するものと認められる。）そして、（ｃ）の段落【００７３】〜【００７４】に記載されているように、ステップＳ１８〜Ｓ２０において、プリンタは、Ｂｌｏｃｋ２に書き込んだ分割モジュールのチェックサムを計算し、そのチェックサムとホストコンピュータから送られたチェックサムとを比較して、一致しない場合は、ホストコンピュータに当該分割モジュールの再送要求を行い、ステップＳ１１に戻り、該分割モジュールを受信する。そして、一致した場合には、ステップ２１において、アドレス変換回路の設定をすることで、プリンタのＣＰＵがＢｌｏｃｋ２をアクセスした場合に当該分割モジュールが読み込まれるようにする。そして、その後、（ｃ）の段落【００７６】に記載されているように、ホストコンピュータは、プリンタにダウンロードすべき複数のモジュールの数だけ、上記のステップＳ１１〜Ｓ２１を繰り返す。したがって、一致した場合には、その後、プリンタは書き換え成功した分割モジュールとは異なる他の分割モジュールの１をホストコンピュータから受信することとなる。（逆に言えば、ホストコンピュータは、書き換え成功した分割モジュールとは異なる他の分割モジュールの１をプリンタに送信することとなる。） 
　また、（ｃ）の段落【００７３】に記載されているように、フラッシュメモリのブロックに書き込んだ分割モジュールのチェックサムを計算して、そのチェックサムと送られてきたチェックサムとを比較し、一致しない場合は、ホストコンピュータに再送要求を返す旨の記載がある。なお、チェックサムが一致する場合は、分割モジュールのフラッシュＲＯＭへの書き換えが成功した場合であり、一致しない場合は、成功しなかった場合であることは、引用文献１の記載からして、当業者にとって自明である。 
　したがって、引用文献１記載の発明の第２の実施形態においては、分割モジュールを取得したプリンタから送られてくる当該分割モジュールの書き換えが不成功の場合の書き換え結果に関する情報をホストコンピュータが取得する取得ステップと、ホストコンピュータから当該分割モジュールをプリンタに再送する再送ステップとが含まれている。
　なお、引用文献１記載の発明の第２の実施形態においては、書き換えが成功の場合の書き換え結果に関する情報をホストコンピュータが取得するかどうか、については明記されていないものの、書き換え成功した後に、ホストコンピュータは、プリンタにダウンロードすべき複数のモジュールの数だけ、上記のステップを繰り返すこと、即ち、書き換え成功した分割モジュールとは異なる他の分割モジュールの書き換えに関するステップを行うことが記載されている。 
　また、引用文献１記載の発明の第１及び第２の実施形態のいずれにおいても、当該分割モジュールの送信を第１の送信とみなし、これと異なる他の分割モジュールの送信を第２の送信とみなすことができることは自明である。
　
　以上のように、引用文献１には、
　
　ホストコンピュータにおいて、
　プリンタの動作制御プログラムを分割して複数の分割モジュールとする分割ステップと、
　前記複数の分割モジュールのうち、バージョンアップがなされていない複数の分割モジュールを特定するステップと、
　前記特定された複数の分割モジュールの中の１の分割モジュールを送信する第１の送信ステップと、
　前記１の分割モジュールを取得したプリンタから送られてくる当該分割モジュールの書き換えが不成功である場合の書き換え結果に関する情報を取得する取得ステップと、
　前記１の分割ファームウェアの書き換えが不成功の場合には、当該モジュールをプリンタに再送するステップと、
　前記１の分割ファームウェアの書き換えが成功した後については、前記特定された複数の分割モジュールの中の前記第１の送信ステップにおいて送信した１の分割モジュールとは異なる、他の１の分割モジュールを送信する第２の送信ステップとを含む、
　データ通信方法 
　
　に関する発明（以下、「引用発明」という）が記載されていると認められる。
　 
Ｂ．当審より通知された上記拒絶理由に引用された、本願の出願日前である平成１１年１月２２日に頒布された刊行物である、特開平１１−１７８７２号公報（以下、「引用文献２」という。）には、図面とともに、以下の事項が記載されている。 
　 
（ｄ）「【０００９】すなわち、中央制御装置に、複数のプログラムモジュールの集合体で構成された制御プログラムをそのプログラムモジュール単位で通信回線及びデータ通信装置を介して画像形成装置へ送信する制御プログラム送信手段を備え、画像形成装置に、中央制御装置から通信回線及びデータ通信装置を介して送られてくるプログラムモジュール単位の制御プログラムを受信し、プログラム格納手段に格納されている制御プログラムをプログラムモジュール単位で書き換えるプログラム書換手段を備えたものである。 
【００１０】この場合、上記制御プログラムを、複数のプログラムモジュールを互いに独立させて構成するとよい。また、制御プログラム送信手段を、書き換えるべきプログラムモジュールをそれを特定できるデータと共に通信回線及びデータ通信装置を介して画像形成装置へ送信する手段とするとよい。  
【００１１】この発明の画像形成装置管理システムでは、中央制御装置が、複数のプログラムモジュールの集合体で構成された制御プログラムをそのプログラムモジュール単位で通信回線及びデータ通信装置を介して画像形成装置へ送信し、その画像形成装置が、そのプログラムモジュール単位の制御プログラムを受信し、プログラム格納手段に格納されている制御プログラムをプログラムモジュール単位で書き換える。 
【００１２】この場合、例えば上記制御プログラムを複数のプログラムモジュールを互いに独立させて構成し、さらに制御プログラム送信手段が、書き換えるべきプログラムモジュールをそれを特定できるデータと共に通信回線及びデータ通信装置を介して画像形成装置へ送信する。」 
　  
（ｅ）「【００６４】ここで、画像形成装置の制御プログラムを複数のプログラムモジュールを互いに独立させて構成するために、サブモジュール管理テーブル（サブルーチン管理テーブル）を使用することが考えられる。サブルーチン管理テーブルを使用したシステムとしては、特公平５−１４９３０号公報に記載されたものがある。  
【００６５】本来、サブルーチン管理テーブル方式は、異なる装置間でサブルーチンを共用する目的で考案されたもので、この目的のためにも各々のサブルーチンを互いに独立させる必要があり、この発明の目的とは異なっても結果的に同一構成が要求される。  
【００６６】図１０は画像形成装置の制御プログラムのモジュール構成の一例を示す図、図１１は図１０のサブモジュール管理テーブルの内容の一例を示す図、図１２はそのサブモジュール群の間隔の一例を示す図である。  
【００６７】画像形成装置の制御プログラムは、例えば図１０に示すように、メインモジュール７１，サブモジュール群７２，サブモジュール管理テーブル７３によって構成されている。サブモジュール群７２は、制御プログラムを各々機能分割した互いに独立した構成になっており、全体で画像形成動作を含む各種制御を実行できるようになっている。 
【００６８】サブモジュール管理テーブル７３は、例えば図１１に示すようにサブモジュール群７２の先頭アドレスで構成されている。メインモジュール７１は、サブモジュール管理テーブル７３で定義された先頭アドレスに間接的にジャンプすることにより、順次サブモジュール群７２を実行するようにする。
【００６９】一般的には、メインモジュール７１をＲＯＭ１３に、サブモジュール群７２，サブモジュール管理テーブル７３を不揮発性ＲＡＭ１５に格納する。中央制御装置６から不揮発性ＲＡＭ１５内のサブモジュール群７２（制御プログラム）を書き換える場合、その一部である該当するプログラムモジュールを書き換えるようにすればよいが、これを効果的に達成するためには、プログラムモジュールの書き換えで増加する分を見込んで、例えば図１２に示すようにサブモジュール群７２間に余裕を持ってプログラムモジュールの書き換えを行なう必要がある。
【００７０】このように、この実施形態の画像形成装置管理システムでは、中央制御装置６が、複数のプログラムモジュールの集合体で構成された制御プログラムをそのプログラムモジュール単位で通信回線８及びデータ通信装置７を介して目的とする画像形成装置へ送信し、その画像形成装置が、そのプログラムモジュール単位の制御プログラムを受信し、不揮発性ＲＡＭ１５に格納されている制御プログラムをプログラムモジュール単位で書き換える。 
　・・・（中略）・・・ 
【００７２】この場合、上記制御プログラムを複数のプログラムモジュールを互いに独立させて構成したり、あるいはそれに加えて、書き換えるべきプログラムモジュールをそれを特定できるデータと共に通信回線８及びデータ通信装置７を介して目的とする画像形成装置へ送信することにより、上述の制御プログラムの書き換え制御を効果的に実現することができる。」
　
　上記（ｄ）、(ｅ)の記載から、中央制御装置において、画像形成装置の制御プログラムを機能分割した複数のプログラムモジュール群に分割し、該制御プログラムを書き替える際には、プログラムモジュールを画像形成装置に送信し、画像形成装置は、プログラムモジュール単位で書き替えると認められる。また、（ｅ）の段落【００７２】から、書き換えるべきプログラムモジュールを、特定できるデータとともに、送信することは自明である。
　
　したがって、引用文献２には、
　
　中央制御装置において、
　画像形成装置の画像制御プログラムを複数のプログラムモジュールに分割し、
　前記分割された複数のプログラムモジュールを、該プログラムモジュールを特定できるデータとともに、画像形成装置に送信し、
　画像形成装置は、そのプログラムモジュールを受信し、そのプログラムモジュール単位で書き替えることを
　特徴とする画像形成装置管理システム 
　  
　に関する発明（以下、「引用文献２記載の発明」という）が記載されていると認められる。
　
Ｃ．当審より通知された上記拒絶理由に引用された、本願の出願日前である平成１１年１１月５日に頒布された刊行物である、特開平１１−３０６０２４号公報（以下、「引用文献３」という。）には、図面とともに、以下の事項が記載されている。
　 
（ｆ）「【０００１】  
【発明の属する技術分野】本発明は、ネットワークを介して所定のプログラムの送信および受信を行うホスト装置および情報処理装置に関する。」
  
（ｇ）「【００１９】プリンタ２００は情報処理装置の一例であり、ホスト装置１００またはワークステーション（図示せず）等から送信される印刷データを用紙に印刷する装置である。また、このプリンタ２００は、ホスト装置１００からＬＡＮ３００を介して転送される各種のプログラム（例えば、制御プログラム）を受信、記憶し、これを新規のプログラムとして動作する。  
【００２０】ＬＡＮ３００は、ホスト装置１００とプリンタ２００間のデータの授受を実現するための媒体である。一般には、イーサネット、トークンリング等が挙げられる。  
【００２１】このようなハードウェア構成から成る本実施形態のホスト装置１００では、情報処理装置であるプリンタ２００の有する資源に応じて制御プログラム等を送信する点に特徴がある。 
【００２２】図２に示すように、この動作を実現するソフトウェア構成としては、プリンタ等の情報処理装置の資源を認識する認識手段Ｐ１０１と、この資源と対応して所定のプログラム（制御プログラム等）を記憶する記憶手段Ｐ１０２と、認識手段Ｐ１０１で認識した資源と対応するプログラムを記憶手段Ｐ１０２から読み出してプリンタへ転送する転送手段Ｐ１０３とから構成されている。 
【００２３】認識手段Ｐ１０１は、プリンタの有する資源に関する情報（資源情報）を参照して、そのプリンタにどのような資源が設けられているかを認識する。記憶手段Ｐ１０２は、資源情報と対応してプログラムのプログラム名や長さ等を管理している。、転送手段Ｐ１０３は、認識手段Ｐ１０１で認識された資源に対応するプログラムを記憶手段Ｐ１０２から読み出し、ＬＡＮ３００（図１参照）を介してプリンタへそのプログラムを転送する。 
【００２４】図３は資源情報の形式を説明する図である。すなわち、資源情報は、プリンタ（情報処理装置）の機種識別ＩＤ、機種名長、機種名、資源情報数をヘッダとして、その機種に備わる資源と対応した全ての資源ＩＤが記述されている。 
【００２５】図４は資源情報の具体例を示す図で、図３の形式に対応した所定の１機種の資源情報が記述されている。この例では、機種識別ＩＤ「ＦＸ４３−０１」、機種名長「１２」、機種名「ＬａｓｅｒＰｒｅｓｓＩＩ」、資源情報数「７５」をヘッダとして、資源情報数「７５」個分の資源ＩＤ（例えば、「１０５３０００１」）が記述される。この資源ＩＤは各資源（機能）に対応して付されたものである。」  
　  
（ｈ）「【００３３】ホスト装置１００の認識手段Ｐ１０１は、この取得した資源情報を参照してダウンロード先のプリンタ２００における資源を認識することになる。例えば、図４に示すような資源情報を取得した場合、このプリンタ２００は、少なくとも資源ＩＤ「１０５３００１」、資源ＩＤ「１０５５００１」、資源ＩＤ「２０００００１」、資源ＩＤ「２０００００２」、資源ＩＤ「５０２０００１」に対応する資源を備えていることになる。  
【００３４】すなわち、図６より、この資源ＩＤ「１０５３００１」はハードディスク、資源ＩＤ「１０５５００１」は両面トレイユニット、資源ＩＤ「２０００００１」はＬｐｄソフトウェア、資源ＩＤ「２０００００２」はＮｅｔｗａｒｅソフトウェア、資源ＩＤ「５０２０００１」はＰｏｓｔＳｃｒｉｐｔデコンポーザと対応しており、プリンタ２００がこれらの資源を有することが分かる。  
【００３５】次に、ステップＳ１０２に示すように、転送する制御プログラムの選択を行う。ホスト装置１００の記憶手段Ｐ１０２は、例えば図６に示すような管理形式で各資源ＩＤに対応した制御プログラムを管理している。  
【００３６】ステップＳ１０２では、ホスト装置１００の認識手段Ｐ１０１が資源情報に基づき認識したプリンタ２００の資源ＩＤに対応した制御プログラムを転送手段Ｐ１０３がハードディスク１０４から読み出すようにしている。 
　・・・（中略）・・・ 
【００４０】そして、ステップＳ１０３に示すように、先のステップＳ１０２で選択された制御プログラムをプリンタ２００に転送する。すなわち、ホスト装置１００の転送手段Ｐ１０３によって読み出された制御プログラムは、Ｉ／Ｆ１０８からＬＡＮ３００を介してプリンタ２００に転送される。 
【００４１】これによって、プリンタ２００の有する資源に対応した制御プログラムだけを選択して転送することができるようになる。」  
　 
　上記（ｇ）及び（ｈ）から、プリンタ２００の制御プログラムは、ホスト装置において資源情報単位に分割して管理されており、ホスト装置からプリンタに制御プログラムをダウンロードのために転送する際には、該資源情報単位に対応した制御プログラムを転送すると認められる。
　
　したがって、引用文献３には、
　
　ホスト装置において、
　プリンタの制御プログラムを資源情報単位に分割し、
　前記分割された複数の資源情報単位別にプリンタに送信し、
　プリンタが前記プログラムを受信、記憶し、これを新規の動作プログラムとして動作することを
　特徴とするプリンタの制御プログラムの管理システム 
　
　に関する発明（以下、「引用文献３記載の発明」という）が記載されていると認められる。
　
Ｄ．当審より通知された上記拒絶理由に引用された、本願の出願日前である平成１２年９月２９日に頒布された刊行物である、特開２０００−２６７８５７号公報（以下、「引用文献４」という。）には、図面とともに、以下の事項が記載されている。 
　 
（ｉ）「【要約】  
【解決手段】 リモート機１は、ファクシミリ装置３に対して通信回線２を通じて、受信バッファメモリ１２中にリモートメンテナンス用プログラムデータ１５をローディングする。その後、リモートメンテナンス用プログラムデータ１５に含まれる書換え制御プログラムが動作し、新プログラム１４を旧プログラム１３に上書きしてプログラムの更新をする。  
【効果】 ファクシミリ装置を制御するためのプログラムをファクシミリ装置の持つデータ受信能力を利用してダウンロードし、バージョンアップができるので、サービスマンが現地に出向く必要がなく、作業も短時間で終了する。」  
　  
（ｊ）「【００４２】以後の手順は具体例１と全く同様で、メッセージ終了信号ＥＯＭによりプログラムの送信終了が通知されると、メッセージ確認信号ＭＣＦ送信後、ステップＳ３において、ファクシミリ装置３の側でプログラムが更新される。そして、ステップＳ４において、ファクシミリ装置３は、リモート機１に対しその更新結果をＮＳＦ信号を用いて伝える。即ち、この具体例では、プログラムの更新が成功したかどうかをリモート機１に対し通知する。ここで、ステップＳ５で、リモート機１は、更新結果を判定し、成功していれば、回線切断信号ＤＣＮの送出により処理を終了する。プログラムの更新が成功していなければ、再びステップＳ２に戻り、プログラムデータの再送を行う。」  
　
　以上から、引用文献４には、
　
　ファクシミリ装置の制御プログラムのリモートメンテナンス方法であって、
　リモート機からファクシミリ装置に制御プログラムを送信し、
ファクシミリ装置は、該プログラムの更新を行い、
プログラムの更新が成功したかどうかの更新結果をリモート機に通知し、
それを受けて、リモート機は、
更新が成功の場合は、処理を終了し、更新が不成功の場合は、リモート機はファクシミリ装置に該プログラムを再送する
　ファクシミリメンテナンス方法
　  
　に関する発明（以下、「引用文献４記載の発明」という）が記載されていると認められる。
　
Ｅ．当審より通知された上記拒絶理由に引用された、本願の出願日前である平成９年６月６日に頒布された刊行物である、特開平９−１４６８５９号公報（以下、「引用文献５」という。）には、図面とともに、以下の事項が記載されている。 
　 
（ｋ）「【要約】  
【課題】 本発明は、電子メールを利用して管理端末から被管理端末に対する動作指示を与えることによって、システムとしての柔軟性を確保し、かつ、ユーザにとって使い勝手の良い端末管理機能付ネットワークシステムを提供することを課題とする。」  
　  
（ｌ）「【００２１】つまり、指示作成手段１１では、被管理端末２０に対する動作指示を、上述した記述形態に従って指示書として作成するようになっている。また図１において、指示送信手段１２は、管理端末１０の通信制御部４３及びこの管理端末１０が備えるメールソフトによる処理によって実現されるものであり、指示作成手段１１で作成した指示書を電子メールにより被管理端末２０へ送信するものである。  
【００２２】送信受信判定手段２１は、指示送信手段１２から電子メールによって送信されたメールがあるか否かを一定間隔で検索する・・・（中略）・・・。指示受取手段２２は、送信受信判定手段２１により指示送信手段１２からのメールがあると判断されると、そのメールを受け取るとともに、そのメールから指示書を取り出して指令ファイル２０ｄに格納させるものである。  
【００２３】・・・（中略）・・・  
【００２４】・・・（中略）・・・解読実行手段２３は、指示受取手段２２によって指令ファイル２０ｄに指示書が格納されると、その指示書の内容を上述した記述形態を基に解読するものである。・・・（中略）・・・そして、解読実行手段２３では、その解読結果に従い必要に応じてＯＳ及び通信ソフト２０ａやメールソフト２０ｂに動作指示を与えることにより、指示書によって指示された動作を実行するようになっている。  
【００２５】・・・（中略）・・・結果通知手段２５は、解読実行手段２３が指示書によって指示された動作を実行すると、その実行結果（例えば、動作完了や障害発生等）を電子メールにより管理端末１０へ通知するためのものである。ただし、結果通知手段２５では、管理端末１０の通知を、解読実行手段２３での解読結果、すなわち指示書に記述された結果報告指示５５により指示された内容に従って行うようになっている。」  
　  
（ｍ）「【００３４】・・・（中略）・・・被管理端末２０に登録されているソフトウエアをバージョンアップ（アップデート）するために、管理端末１０から被管理端末２０に対して、Ｂソフト及びこのＢソフトをファイルに上書きするための指示が指示書として送信されると（Ｓ３０１）、被管理端末２０では、その指示書に従ってＢソフトの上書きや動作確認を行い、その結果（ＯＫ／ＮＧ）を管理端末１０へ通知する（Ｓ３０２）。このとき、被管理端末２０からの通知結果がＮＧであれば、管理端末１０のユーザは、被管理端末２０に対して、復旧方法の指示を指示書で与える（Ｓ３０３）。そして、被管理端末２０では、その指示書に従って復旧を行い、その結果（ＯＫ／ＮＧ）を管理端末１０へ通知する（Ｓ３０４）。この被管理端末２０からの通知を管理端末１０のユーザが確認すると、被管理端末２０のソフトウエアをバージョンアップの作業は終了となる（Ｓ３０５）。」  
  
　以上から、引用文献５には、
  
　電子メールを利用した管理端末の被管理端末に対するリモートメンテナンス方法において、
　被管理端末のソフトウエアの更新をするために、ソフトウエアと指示書を電子メールで被管理端末に送信し、
　被管理端末では、その電子メールを受信し、受信した指示書に従い、受信したソフトウエアの更新とその動作確認を行い、
　その結果（ＯＫ／ＮＧ）を管理端末に電子メールで通知し、
　管理端末は通知結果に応じた処理をすることを特徴とする
　電子メールを利用した管理端末の被管理端末に対するリモートメンテナンス方法
　
　に関する発明（以下、「引用文献５記載の発明」という）が記載されていると認められる。
　 
Ｆ．当審より通知された上記拒絶理由に引用された、本願の出願日前である平成１２年１月２８日に頒布された刊行物である、特開２０００−２９６４８号公報（以下、「引用文献６」という。）には、図面とともに、以下の事項が記載されている。 
　 
（ｎ）「【０００１】  
【発明の属する技術分野】本発明は、ネットワーク機器の動作用データ更新装置及びこれを利用した印刷装置に係り、例えば、ネットワーク機器としての印刷装置のファームウェアを更新する動作用データ更新装置及びこれを利用した印刷装置に関する。  
【０００２】・・・（中略）・・・  
【０００３】・・・（中略）・・・  
【０００４】  
【発明の目的】本発明は、・・・（中略）・・・保守担当員が現地まで出向かずにファームウェア等の動作用データを更新できるネットワーク機器の動作用データ更新装置及びこれを利用した印刷装置を提供することを、その目的とする。  
【０００５】  
【課題を解決するための手段】上記目的を達成するため、請求項１記載の発明では、動作用データに従って動作するネットワーク機器に装備され、ネットワークから動作用データの書かれた電子メールを受信して該電子メールに書かれた動作用データを現在の動作用データの記憶部に更新する電子メール処理部を備えた、という構成を採っている。  
【０００６】本発明では、動作用データを記述した電子メールを外部の端末からネットワーク機器宛てに送信すると、その電子メールデータがネットワーク機器に受信され、その電子メールに記述された動作用データが記憶部に更新される。  
【０００７】請求項２記載の発明では、上記動作用データが、印刷処理プログラム（ファームウェアデータ）である、という構成を採っている。  
【０００８】・・・（中略）・・・  
【０００９】請求項４記載の発明では、動作用データに従って動作する印刷装置であって、ネットワークから動作用データの書かれた電子メールを受信して該電子メールに書かれた動作用データを現在の動作用データの記憶部に更新する電子メール処理部を備えた、という構成を採っている。  
【００１０】請求項５記載の発明では、上記動作用データが、印刷処理プログラム（ファームウェアデータ）である、という構成を採っている。」
　
　以上から、引用文献６には、
　
　外部の端末から印刷装置の印刷処理プログラム（ファームウェアデータ）の更新を行うシステムであって、
　外部の端末から電子メールで、印刷処理プログラム（ファームウェアデータ）を印刷装置に送信し、
　印刷装置は、当該電子メールを受信して該電子メールに書かれた印刷処理プログラムによって記憶部に格納された現在の印刷処理プログラムを書替え更新する電子メール処理部を備えた、
　ことを特徴とする印刷装置のファームウエア更新システム 
　
　に関する発明（以下、引用文献６記載の発明という）が記載されていると認められる。
　
３．対比 
　ここで、本願発明と引用発明とを対比する。
　引用発明の「プリンタの動作制御プログラム」、「分割モジュール」、「プリンタ」、及び「書き換え」は、それぞれ本願発明の「１または複数のファームウェア」、「分割ファームウエア」、「相手先」、及び「書き替え」に対応する。 
　引用発明の「特定された複数の分割モジュール」は、「動作制御プログラムを分割」した「複数の分割モジュールのうち、バージョンアップがなされていない複数の分割モジュール」を意味し、本願発明の「複数の分割ファームウェア」は、「１または複数のファームウェアを分割」した「複数の分割ファームウェア」を意味する。したがって、両者は、「１または複数のファームウェアを分割」した「複数の分割ファームウェア」の所定の複数の分割ファームウエアである点で共通する。 
　また、引用発明の「書き替え結果に関する情報」は、書き替えが不成功である場合の情報を含むことから、本願発明の「書き替え結果に関する情報」とは、「所定の書き替え結果に関する情報」である点で共通する。  
　そして、引用発明の「前記１の分割ファームウェアの書き替えが成功した後」に「第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する」ことと、本願発明の「前記取得された書き替え結果に関する情報が書き替え成功の情報であることを条件として」、「第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する」こととは、ともに「書き換えが成功した以降」に第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する点で共通する。 
　  
　よって、本願発明と引用発明とは、 
　  
　１または複数のファームウェアを分割して複数の分割ファームウェアとする分割ステップと、 
前記複数の分割ファームウェアの所定の複数の分割ファームウエアの中の１の分割ファームウェアを送信する第１の送信ステップと、 
　前記１の分割ファームウェアを取得した相手先から送られてくる当該分割ファームウェアの所定の書き替え結果に関する情報を取得する取得ステップと、 
　前記１の分割ファームウェアの書き替えが成功した以降に、前記所定の複数の分割ファームウェアの中の前記第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する第２の送信ステップとを含む、 
　データ通信方法  
　  
　の点で一致し、以下の点で相違している。  
　 
（相違点１） 
　送信する分割ファームウエアが「複数の分割ファームウェアの所定の複数の分割ファームウエア」の中の１の分割ファームウエアである点について、本願発明は「１または複数のファームウェアを分割」した「複数の分割ファームウェア」の中の１の分割ファームウエアであるのに対して、引用発明は、「動作制御プログラムを分割」した「複数の分割モジュールのうち、バージョンアップがなされていない複数の分割モジュール」の中の１の分割モジュールである点。
　 
（相違点２） 
　本願発明は「分割ファームウェアを、当該分割ファームウェアの書き替え順序に関する情報とともに、送信する」のに対して、引用発明はそのような構成を備えていない点。 
　 
（相違点３） 
　「所定の書き替え結果に関する情報」について、本願発明は「書き替え成功の情報」を含むのに対して、引用発明が書き替え成功の情報を含むかどうか、明示されていない点。 
　  
（相違点４） 
　本願発明は、「前記取得された書き替え結果に関する情報が書き替え成功の情報であることを条件として」、第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信するのに対して、引用発明は、「前記取得された書き替え結果に関する情報が書き替え成功の情報であることを条件として」第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する構成であるかどうか、明示されていない点。 
　 
（相違点５） 
　本願発明の第１の送信ステップ及び第２の送信ステップにおいては、分割ファームウェアを電子メールに添付して送信するのに対して、引用発明は、分割ファームウェアを電子メールに添付して送信する構成を備えていない点。
　 
４．判断 
　まず、相違点１について検討する。 
　引用文献２、３記載の発明のように、送信する分割モジュール（分割ファームウエア）を制御プログラム（ファームウエア）を分割して複数の分割モジュールとした前記複数の分割モジュールの中の１の分割モジュール（分割ファームウエア）とすることは、当業者にとって常套手段である。
　また、特開２０００−３２４１９５号公報に
「【００３４】ここで、ファームウエアを分割して作成したデータパケットの一構成例は図１１に示されるように、先頭にデータパケットであることを表す２バイトのオペコードがあり、次にデータパケットの順序を示すブロックナンバーがあり、終端を分割されたファームウエアのデータにより構成される。
【００３５】データパケットを受信したＮＩＣは、ステップＳ４１２でファームウエアの書き換え処理として、受信したデータパケットを翻訳し、順序に沿って組み立てる。」と記載されているように、
　ファームウエアを分割して作成した複数のデータパケットとして、送信するデータパケット（分割ファームウエア）を前記複数のデータパケット（分割ファームウエア）の中の１のデータパケット（分割ファームウエア）とすることも当業者にとって周知の技術である。
　そして、引用発明においては、引用文献１の段落【００５７】に記載されているように、プリンタの動作制御プログラムのダウンロード中に電源ダウン等の障害が発生した場合でも、再度ダウンロードするときに全領域ダウンロードする必要がないように、送信する分割モジュールを「動作制御プログラムを分割」した「複数の分割モジュールのうち、バージョンアップがなされていない複数の分割モジュール」の中の１の分割モジュールとしたことを勘案すれば、引用発明においても、当業者にとって常套手段である、全領域ダウンロードするように構成し、送信する分割モジュール（分割ファームウエア）を「動作制御プログラムを分割」した「複数の分割モジュール」の中の１の分割モジュール（分割ファームウエア）とすることは、当業者であれば、容易に想到しえるものである。
　
　次に、相違点２について検討する。  
　特開平１０−１８７４５７号公報に  
「【０１４６】そして、送信機から受信機へ、分割データ数Ｎを通知する（ステップ３０４）。この分割データ数Ｎの通知は、例えば、図２１のような分割データ数が書き込まれたヘッダ部を先に送出することにより可能となる。なお、特定のプロトコル信号により通知しても良い。  
【０１４７】次に、分割データ番号ｋを１に設定し（ステップ３０６）、送信機から受信機へ、分割データｋ（番号ｋが付与された分割データ；ここではｋ＝１）を送信する（ステップ３０８）。受信機側では、この分割データの受信の良否を判定し、分割データの受信が正常終了しなかった場合（ステップ３１０否定判定）、受信機が送信機に対して分割データｋの再送を要求する（ステップ３１４）。つまり、この再送要求では、これまでの送信機と受信機の送受信の役割が反転される。そして、ステップ３０８に戻り、送信機から受信機へ、受信が失敗した分割データｋの送信処理が再び行われ、ステップ３１０で同様の判定を行う。
　・・・（中略）・・・
【０１５１】・・・（中略）・・・　受信機側では、ファイル名などで識別されている分割データ１、２、．．．．Ｎを順番に結合することにより元のファイルを再現し、　・・・（中略）・・・」と記載されているように
　また、特開２０００−３２４１９５号公報に
「【００３４】ここで、ファームウエアを分割して作成したデータパケットの一構成例は図１１に示されるように、先頭にデータパケットであることを表す２バイトのオペコードがあり、次にデータパケットの順序を示すブロックナンバーがあり、終端を分割されたファームウエアのデータにより構成される。
【００３５】データパケットを受信したＮＩＣは、ステップＳ４１２でファームウエアの書き換え処理として、受信したデータパケットを翻訳し、順序に沿って組み立てる。」と記載されているように、
　また、特開平５−６７００９号公報に
「【００１８】このように、本発明では、第ｉ番目の送信対象のファイルのファイル名が“Ａｉ”であるとするならば、「ｎ，ｉ，Ａｉ」を表示する送信ヘッダ情報を受信側データ処理装置２に送信してから、この第ｉ番目の送信対象のファイルデータを分割しながらレコード転送していくのである。
【００１９】・・・（中略）・・・　
【００２０】このファイル転送を受け取ると、受信側データ処理装置２は、送信されてくる送信ヘッダ情報に従って、　・・・（中略）・・・　その順番に対応付けて用意される受信ファイルに受信するファイルデータを格納していく。」と記載されているように
　通信の技術分野において、送信機側が複数の分割したデータを送信する際に、分割したデータを書き替え順序に関する情報とともに送信することで、受信機側が受信した複数の分割したデータを、書き替え順序に関する情報にしたがって、所定記憶領域に順番に結合、もしくは組み立てる、または格納する（書き込む）ことは、当業者にとって周知の技術である。
　してみれば、引用発明において、動作制御プログラムを分割した複数の分割モジュールを送信する際に、該周知技術を適用することで、受信機側が分割された複数の分割モジュールを書き替え順序に関する情報にしたがって、所定記憶領域に順番に格納する（書き込む）ように、本願発明の「分割モジュール（分割ファームウエア）を、当該分割モジュール（分割ファームウエア）の書き替え順序に関する情報とともに、送信する」ような構成にすることは当業者であれば容易に想到し得たことである。
　
　次に、相違点３及び相違点４について検討する。 
　引用文献１記載の発明の第１の実施形態においては、段落【００３７】〜【００３９】に記載されているように、「正常終了」時には、正常終了のステータスをホストコンピュータに返し、その後、ホストコンピュータは、プリンタにダウンロードすべき複数のモジュールの数だけ、上記のステップを繰り返すこと、即ち、ダウンロードの成功した分割モジュールとは異なる他の分割モジュールのダウンロードに関するステップを行うことが記載されている。 
　そして、通信技術分野において、ホストとクライアント間の通信において、ホストからのコマンドに対して、クライアント側がそのコマンドに対する処理を行い、その処理結果（レスポンス）をホストに返すことで、ホストがクライアントの処理結果（レスポンス）を判定して、その処理結果に基づいて、次の処理を行う（またはコマンドを発行する）ことは、引用文献４、５に記載されているように、当業者にとって周知技術である。
　してみれば、引用発明において、書き替えが不成功の場合に書き替え結果に関する情報をレスポンスとしてホストコンピュータに返し、ホストコンピュータがそのレスポンスに基づいて当該モジュールを再送する構成を有しているのと同様に、書き替えが成功の場合に、書き替え結果に関する情報をレスポンスとしてホストコンピュータに返し、ホストコンピュータがそのレスポンスに基づいて、ホストコンピュータが他の１の分割モジュールを送信するように構成することは、当業者であれば適宜なし得たことである。 
　よって、引用発明において、本願発明のように、「所定の書き替え結果に関する情報」について、「書き替え成功の情報」を含む構成にするとともに、「前記取得された書き替え結果に関する情報が書き替え成功の情報であることを条件として」第１の送信ステップにおいて送信した１の分割ファームウェアとは異なる他の１の分割ファームウェアを送信する構成にすることは、当業者であれば容易に想到し得たことである。
　
　最後に、相違点５について検討する。  
　引用文献５、６記載の発明に記載されているように、ファームウエア等の送信において電子メールを利用することは、当業者にとって周知技術である。したがって、引用発明において、本願発明のように「分割ファームウエアを電子メールに添付して」送信するように構成することは、当業者であれば適宜なし得たことである。
 
　そして、本願発明の作用効果も、引用発明、引用文献２−６に記載された発明、及び周知技術から当業者が予測できる範囲のものである。  
　したがって、本願発明は、引用発明、引用文献２−６に記載された発明、及び周知技術から容易に発明することができたものである。
　
５．むすび
　以上のとおり、本願発明は、引用発明、上記引用文献２−６に記載された発明、及び周知技術に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。  
　  
　よって、結論のとおり審決する。