【事件の表示】
　特願２０００−１０４２８７「ファイル保全方法」拒絶査定不服審判事件〔平成１３年１０月１９日出願公開、特開２００１−２９０６８５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年４月６日の出願であって、平成１７年１月１１日付（発送日：１月１３日）で拒絶査定がされ、これに対し、平成１７年２月４日に拒絶査定不服審判が請求されるとともに、同日付で手続補正がなされた。
　その後当審において平成１９年１０月２５日付で拒絶の理由が通知されたものである。
　
２．本願発明
　当審の拒絶理由通知と同日付の補正の却下の決定により平成１７年２月４日付け手続補正は却下され、平成１９年１２月５日付けで手続補正がなされたので、本願の請求項に係る発明は、平成１９年１２月５日付の手続補正により補正された特許請求の範囲に記載されたとおりのものと認める。
　そして、本願の請求項１に係る発明（以下、本願発明という。）は、以下のとおりである。
　
「【請求項１】
　第１の情報処理装置からダウンロードされたファイルにより第２の情報処理装置における既存のファイルを更新するファイル保全方法であって、
　前記第１の情報処理装置からダウンロードされるファイルに対して、ファイル名と、日付および論理版番号を含む複数のパラメータと、前記ファイルをダウンロードするか否かの判断基準となるパラメータあるいは強制置換を示すダウンロード判定条件情報とから構成されるダウンロード元管理情報を付加する工程と、
　前記第２の情報処理装置において、前記ダウンロード元管理情報及びダウンロード先管理情報を参照し、前記ダウンロード判定条件情報に基づいてファイル更新の必要性を判断し、更新が必要な場合には前記第１の情報処理装置からダウンロードされたファイルによって既存のファイルを更新するファイル更新工程と、
　前記ファイル更新工程による更新履歴を管理する更新履歴管理工程と、
　前記ファイル更新工程によるファイルの更新時に、更新対象となる既存のファイルを保存するファイル保存工程と、
　前記ダウンロードされたファイルによる更新処理が適正に行われたか否かを判断する判断工程と、
　前記判断工程によって更新処理が適正に行われなかったと判断された場合に、前記更新履歴とファイル保存工程によって保存したファイルとによってダウンロード前の状態に復元する復元工程と、を有することを特徴とするファイル保全方法。」
　
３．当審の拒絶理由
　一方、当審において平成１９年１０月２５日付けで通知した拒絶の理由の概要は、本願請求項１ないし請求項８に係る発明は、その出願前日本国内において頒布された下記の引用文献１ないし引用文献５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないというものである。
　
　引用文献１　特開平１０−１７１６３５号公報
　引用文献２　特開平１０−１７１６３４号公報
　引用文献３　特開平５−３４２０１０号公報
　引用文献４　特開平１１−３１２０８０号公報
　引用文献５　特開平８−８７４１０号公報
　
４．引用文献
　上記拒絶の理由に引用された文献の記載内容を検討する。
　特開平１０−１７１６３５号公報（引用文献１）には、図面と共に次の事項が記載されている。
（ア）「【００１５】
　本発明の第２の側面に従うシステムでは、保守者装置は、被保守装置内の各アプリケーションをバージョンアップするとき、各アプリケーションのアップバージョンのファイルとファイル情報とを被保守装置に送信する送信手段を備える。また、被保守装置は、被保守装置内の各アプリケーションの、現在のバージョンのファイル情報を表した現在の状態を格納するためのアプリケーション管理テーブルと、アップバージョンのファイルとファイル情報とを保守者装置から受信したとき、アプリケーション管理テーブル内の該当する現在の状態と、受信したファイル情報とを比較することにより、受信したファイルの中から新たにインストールすべきファイルを選択するファイル選択手段と、選択されたファイルを被保守者装置にインストールするインストール手段と、選択されたファイルのインストールが終わったとき、アプリケーション管理テーブル内の該当する現在の状態を、インストール終了後のファイル情報に更新するテーブル更新手段とを備える。
　　　【００１６】
　このシステムによれば、保守者装置がアップバージョンのファイルとファイル情報とを被保守者装置に送信すると、各被保守装置が各々のアプリケーション管理テーブルを参照してインストールが必要なファイルを選択して、自動的にインストールする。したがって、バージョンアップの処理が各被保守装置に分散するので、保守者装置の負荷を小さくすることが出来る。」
　
（イ）「【００２４】
　　【発明の実施の形態】
　図１は、本発明の分散環境に於けるソフトウエア資源の管理方式を説明するための、端末のアプリケーション管理構成図である。図１において、ネットワーク１０には、管理者が操作する保守者装置１及び一台または複数台の被保守装置１１等の端末マシンが接続されている。保守者装置１はマネージャプロセス３を実行でき、更に、アプリケーションの「現在の状態」５と「前の状態」７及びアプリケーション変更後の「目的の状態」９を表したアプリケーション管理テーブル２が格納されている。
　　　【００２５】
　また、個々の被保守装置１１はエージェントプロセス１３を実行することができ、保守者装置１と同様に、アプリケーションの「現在の状態」１５と「前の状態」１７及びアプリケーション変更後の「目的の状態」１９を表したアプリケーション管理テーブル１２が格納されている。
　　　【００２６】
　各被保守装置１１は、それにインストールされているアプリケーションの各々毎にアプリケーション管理テーブル１２を有している。一方、保守者装置１は、被保守装置１１の各々毎に、かつ各被保守装置１１にインストールされているアプリケーションの各々毎にアプリケーション管理テーブル２を有している。例えば、被保守装置１１が２台あって、各被保守装置１１に３種類のアプリケーションがインストールされている場合には、各被保守装置１１はその３種類のアプリケーションに対応した３つのアプリケーション管理テーブル１２を有しているが、保守者装置１は、２台の被保守装置１１の各々３種類のアプリケーションに対応した６つのアプリケーション管理テーブル１２を有している。
　　　【００２７】
　各アプリケーション管理テーブル１、１２には、対応するアプリケーションの「現在の状態」１５と「前の状態」１７と「目的の状態」１９とが格納されているが、各状態１５、１７、１９の内容は、図２に例示するように、アプリケーションを構成するファイルの名前、ディレクトリ、サイズ、作成日付等のファイル情報から構成されている。
　　　【００２８】
　このように、各マシン１、１１が各アプリケーション毎に、アプリケーション管理テーブル２、１２を持つことにより、以下に詳述するように、分散環境に於けるソフトウエア資源のアプリケーション管理を容易にすることが出来る。
　　　【００２９】
　管理者は、保守者装置１から被保守装置１１へアプリケーションを配布しインストールすることにより、被保守装置１１のアプリケーションをバージョンアップすることができる。このとき、インストール作業の自動／手動起動を管理者が任意に選択できる。さらに、管理者は、保守者装置１から被保守装置１１のアプリケーションを前のバージョンに戻すこともできる。」
　
（ウ）「【００４４】
　２．　保守者装置１の負荷を小さくする配布・インストール方法
　図５は、保守者装置１の負荷を小さくしてアプリケーションを配布・インストールする場合の情報の流れを示す。また、図６は、この場合の処理の流れを示す。アプリケーションのバージョンアップは次の手順で行われる。
　　　【００４５】
　先ず、管理者は、保守者装置１内の該当するアプリケーション管理テーブル２に「目的の状態」９を登録し、また、インストール作業の自動／手動起動命令をマネージャプロセス３に登録する（Ｓ２１）。また、管理者は、バージョンアップ対象アプリケーションのソースディレクトリをマネージャプロセス３に登録する（Ｓ２２）。マネージャプロセス３は、各被保守装置１１に、インストールするアプリケーションの全ファイルと、アプリケーションの「目的の状態」９と、インストール作業の自動／手動起動命令とを送信する（Ｓ２３）。
　　　【００４６】
　すると、被保守者装置１１で動作しているエージェントプロセス１３が、送信されてきた「目的の状態」９とアプリケーション管理テーブル１２の「現在の状態」１５とを比較し（Ｓ２４）、比較結果に従って、新たにインストールすべきファイル（つまり、状態９、１５が相違するファイル）を選定し、そのファイルをインストールするための、インストールスクリプトを作成する（Ｓ２５）。
　　　【００４７】
　次に、エージェントプロセス１３は、書換えられる現在のファイル（つまり、選定したインストール対象ファイルと同名の現在のファイル）のバックアップを取り、また、アプリケーション管理テーブル１２の「現在の状態」１５を「前の状態」１７にコピーし、選定したインストール対象ファイルの構成（フィル情報）を「目的の状態」１９に登録する（Ｓ２６）。
　　　【００４８】
　次に、エージェントプロセス１３は、インストール作業が自動起動に設定されているかどうか判断し（Ｓ２７）、自動起動に設定されている場合は、インストールスクリプトを起動する（Ｓ２８）。尚、手動起動に設定されている場合はユーザの起動待ちとなる（Ｓ２８’）。
　　　【００４９】
　インストールプロセス２０が起動した後の動作は、既に説明した「ネットワークの負荷を小さくする方法」の動作と同じである。この場合、被保守装置１１が受信した全ファイルのうち、エージェントプロセス１３によって選定されたインストール対象ファイルだけがインストールされることになる。」
　
（エ）「【００５１】
　次に、本実施形態において被保守装置１１のアプリケーションを前のバージョンに戻す動作について説明する。
　　　【００５２】
　図７は、被保守装置１１のアプリケーションを前のバージョンに戻す場合の情報の流れを示す。また、図８はこの場合の処理の流れを示す。次の手順でアプリケーションの前のバージョンへの戻しが行われる。
　　　【００５３】
　管理者は、アプリケーションを前のバージョンに戻す命令と、インストール作業の自動／手動起動の命令とを、保守者装置１のマネージャプロセス３に登録する（Ｓ４１）。マネージャプロセス３は、被保守装置１１に上記の命令を送信する（Ｓ４２）。
　　　【００５４】
　命令を受けた被保守装置１１のエージェントプロセス１３は、アプリケーション管理テーブル１２の「前の状態」１７と「現在の状態」１５とを比較し、状態１７、１５間に相違があるファイルを選定する（Ｓ４３）。
　　　【００５５】
　次に、エージェントプロセス１３は、インストール作業が自動起動に設定されているかどうか判断し（Ｓ４４）、自動起動に設定されている場合、選定したファイルを、以前にバージョンアップしたときにバックアップとして保存しておいた前の状態のファイルを用いて元に戻す（Ｓ４５）。尚、インストール作業が手動起動に設定されている場合は、ユーザの起動待ちとなる（Ｓ４５’）。
　　　【００５６】
　上記の作業が終了したら、エージェントプロセス１３は、現在のファイルの構成をアプリケーション管理テーブル１２の「現在の状態」１５に登録する（Ｓ４６）。次に、エージェントプロセス１３は、アプリケーション管理テーブル１２の「前の状態」１７と「現在の状態」１５を比較し（Ｓ４７）、２つの状態１７、１５が同じであれば（Ｓ４８）、保守者装置１に「インストール成功」の報告を行ない（Ｓ４９）、２つの状態１７、１５が異なっていれば（Ｓ４８）、「インストール失敗」の報告を行う（Ｓ５０）。また、エージェントプロセス１３は、上記報告と共に、アプリケーション管理テーブル１２の「現在の状態」１５も保守者装置１に送信する（Ｓ４９，Ｓ５０）。
　　　【００５７】
　マネージャプロセス３は、エージェントプロセス１３からの報告に従って、インストールが成功したかどうかを画面に出力し、管理者に報告する。また、マネージャプロセス３は、アプリケーション管理テーブル２の「前の状態」７を削除し、被保守装置１１から報告された「現在の状態」１５をアプリケーション管理テーブルの「現在の状態」５に登録する（Ｓ５１）。」
　
　以上、（ア）〜（エ）の記載及び図面を総合すると、引用文献１には、
「保守者装置からダウンロードされたファイルにより被保守者装置における既存のファイルを更新するシステムであって、
　保守者装置からダウンロードされるファイルに対して、ファイル名と、日付を含む複数のファイル情報から構成される保守者装置のアプリケーション管理テーブル中の「目的の状態」を付加し、
　被保守者装置において、前記「目的の状態」および被保守者装置のアプリケーション管理テーブル中の「現在の状態」を参照し、その内容でファイル更新の必要性を判断し、更新が必要な場合には保守者装置からダウンロードされたファイルによって既存のファイルを更新し、
　前記ファイル更新によるアプリケーション管理テーブルの「目的の状態」、「現在の状態」、「前の状態」を管理し、
　ファイル更新によるファイルの更新時に、現在のファイルを前の状態のファイルとしてバックアップし、
　現在のファイルと前の状態のファイルを比較して、現在のファイルを前の状態に戻すことができる、ファイル情報更新システム」
　の発明（以下、「引用文献１発明」という。）が記載されていると認めることができる。
　
５．対比
　まず、引用文献１発明と本願発明とを対比するにあたって、本願発明における「日付および論理版番号を含む複数のパラメータ」、および「ファイルをダウンロードするか否かの判断基準となるパラメータ」という事項の意味を検討しておく。
　本願明細書には「パラメータ」なる用語は記載されていないが、項目【０００８】の、
「本形態において、ダウンロード元コンピュータ１００は、ダウンロードファイル登録手段１１０と、ファイル転送手段１２０とを有する。
　ダウンロードファイル登録手段１１０は、転送元ファイルを登録するためのものであり、このダウンロードファイル登録手段１１０の登録情報には、図２に示すような転送元ファイルのダウンロード元管理情報を含んでいる。 このダウンロード元管理情報は、ダウンロードする転送元ファイルＤ１に付加されるものであり、ファイル名、日付、論理版番号、判定条件情報の各要素から構成されている。
　ここで、判定条件情報は、例えば、強制的にファイルの置換（更新）を行うことを示す強制置換と、論理版を優先してファイルの置換（更新）を行うことを示す論理版番号優先と、日付けを優先してファイルの置換（更新）を行うことを示す日付優先等を含むものである。」
の記載ならびに図２からみれば、「日付および論理版番号を含む複数のパラメータ」とは、「日付および論理版番号を含む複数の要素」を意味し、「ファイルをダウンロードするか否かの判断基準となるパラメータ」とは、「論理版を優先してファイルの置換（更新）を行うことを示す論理版番号優先と、日付けを優先してファイルの置換（更新）を行うことを示す日付優先」を示す情報を意味すると理解できる。
　上記のことを踏まえて、引用文献１発明と、本願発明を対比する。
　引用文献１発明の「保守者装置」、「被保守者装置」は、本願発明の「第１の情報処理装置」、「第２の情報処理装置」に相当する。
　また、引用文献１発明の保守者装置の「アプリケーション管理テーブル」は、ファイルの管理情報という点で、本願発明の「ダウンロード元管理情報」に対応し、また、引用文献１発明の被保守者装置のアプリケーション管理テーブルは、同じく、本願発明の「ダウンロード先管理情報」に対応し、さらに、引用文献１発明の「アプリケーション管理テーブル」における「目的の状態」、「現在の状態」、「前の状態」のファイル情報は、本願発明の「ファイル名、日付等の複数の要素（パラメータ）」に対応する。
　したがって、本願発明と引用文献１発明とは、
＜一致点＞
「第１の情報処理装置からダウンロードされたファイルにより第２の情報処理装置における既存のファイルを更新するファイル保全方法であって、
　前記第１の情報処理装置からダウンロードされるファイルに対して、ファイル名と、日付を含む複数のパラメータから構成されるダウンロード元管理情報を付加する工程と、
　前記第２の情報処理装置において、前記ダウンロード元管理情報及びダウンロード先管理情報を参照し、ファイル更新の必要性を判断し、更新が必要な場合には前記第１の情報処理装置からダウンロードされたファイルによって既存のファイルを更新するファイル更新工程と、
　前記ファイル更新工程による更新履歴を管理する更新履歴管理工程と、
　前記ファイル更新工程によるファイルの更新時に、更新対象となる既存のファイルを保存するファイル保存工程と、
　前記更新履歴とファイル保存工程によって保存したファイルとによってダウンロード前の状態に復元する復元工程と、を有することを特徴とするファイル保全方法。」 
　である点で一致し、以下の点で相違する。
　
＜相違点１＞ 
　本願補正発明は、ダウンロード元管理情報に「論理版番号」及び「前記ファイルをダウンロードするか否かの判断基準となるパラメータあるいは強制置換を示すダウンロード判定条件情報」を含んでおり、そして、ファイル更新の必要性の判断を、ダウンロード判定条件情報に基づいて行っているのに対し、引用文献１発明のアプリケーション管理テーブル情報には、論理版番号や上記のようなダウンロード判定条件情報は含まれておらず、また更新の必要性の判断をダウンロード判定条件情報に基いて行っていない点
 ＜相違点２＞ 
　本願補正発明は、「ファイル更新工程によるファイルの更新時に、更新対象となる既存のファイルを保存するファイル保存工程と、ダウンロードされたファイルによる更新処理が適正に行われたか否かを判断する判断工程と、判断工程によって更新処理が適正に行われなかったと判断された場合に、更新履歴とファイル保存工程によって保存したファイルとによってダウンロード前の状態に復元する復元工程と」を有するのに対し、引用文献１には、現在のファイルのバックアップを取り、管理者の命令に応じてバックアップしておいたファイルを用いて前の状態に戻すことは記載されているものの、上記のような工程が明確には記載されていない点
　
６．判断
＜相違点１＞について
　ファイル更新の必要性を判断するために、バージョン情報（論理版番号）を用いることは、引用文献２（特開平１０−１７１６３４号公報）を示すまでもなく周知な技術である。
　したがって、引用文献１発明において、ダウンロードされたファイルに付加されるアプリケーション管理テーブル情報に、論理版番号を加える程度のことは、適宜なし得るものと認められる。
　次に、ダウンロードされるファイルにダウンロード判定条件情報を付加する点、および、ファイル更新の必要性の判断をダウンロード判定条件情報に基づいて行う点、を検討する。
　一般に、新たに入手したファイルで既存のファイルを更新する際、ファイルのバージョン情報を見て更新の必要性を判断（入手したファイルのバージョンが既存のファイルのバージョンより新しければ更新を行う）したり、ファイルの更新日付を見て更新の必要性を判断したり、あるいは無条件にファイルを更新したりすることは、人が端末でファイルの更新処理を手作業でおこなう場合には普通のことである。
　一方、上記引用文献３（特開平５−３４２０１０号公報、特に【００２５】〜【００３２】参照）には、ダウンロードするファイルにバージョン変更に付随するコマンドを付加し、端末装置で該コマンドを投入してファイルの更新に付随する処理を実行させるものが記載され、そして、上記引用文献４（特開平１１−３１２０８０号公報、【００４３】〜【００６３】）には、ダウンロードするファイルにインストール条件判断プログラムを付加して、クライアント端末装置においてファイル更新の必要性を判断させるものが記載され、さらに、引用文献１にも、インストールするファイルにインストール作業の自動／手動起動命令が付加されることが記載されているように、ダウンロードするファイルに、更新命令や更新に付随する命令、あるいはファイルを更新するときの条件等を付加して、ダウンロード先の装置において人の操作を伴わず自動で、付加された命令を実行させたり、更新条件に基づいてファイルを更新するか否かを判断させたりすることは、従来から知られた技術である。
　してみると、引用文献１に記載されたものにおいて、ダウンロードされるファイルに、日付に基いて更新の必要性を判断するか、バージョン（論理版番号）に基づいて更新の必要性を判断するか、あるいは強制的に更新を行うか、等の更新条件を付加し、その更新条件に基づいて被保守者装置において自動で更新の必要性を判断させ、更新を行うようにすることは、引用文献３，４に記載されたもの、ないし周知技術から当業者が容易に想到できたと認められる。
＜相違点２＞について
　ダウンロードされたファイルによって既存のファイルを更新する際、既存のファイルおよびその管理情報を保存（バックアップ）し、更新処理が適切に行われなかった場合、保存したファイルによってダウンロード前の状態に復元させることは、上記引用文献５（特開平８−８７４１０号公報）にも記載されているが、一般に周知な技術である。
　
　さらに、本願発明の作用効果を勘案しても、本願発明に格別のものを認めることができない。
　
７．むすび
　以上のとおり、本願発明は、引用文献１ないし引用文献５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。