【事件の表示】
　平成１１年特許願第　７９１９２号「ソフトウェア自動配布システム及び方法」拒絶査定不服審判事件〔平成１２年１０月　６日出願公開、特開２０００−２７６３３６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯、本願発明
　本願は、平成１１年３月２４日の出願であって、その請求項２に係る発明は、平成１５年７月２２日付け手続補正書で補正された明細書および図面の記載からみて、本願の特許請求の範囲の請求項２に記載された次のとおりのものである。
　   
「【請求項２】少なくともソフトウェアのバージョン情報及び時間に応じたソフトウェア毎のバージョンを管理する配布履歴表を含む配布状況の履歴を蓄積するソフトウェア配布情報蓄積ファイルと、前記蓄積ファイルの情報を検索する管理手段と、ソフトウェアの配布を実行する制御手段とを備えた配布サーバが、ネットワークを介し、ソフトウェアを配布先に配布するソフトウェア自動配布方法において、前記管理手段が、指定された配布先に対する指定された切り戻し時刻における配布指定にもとづき前記配布履歴表を検索して、配布が必要となるバージョンのソフトウェアを特定し、前記制御手段が、前記特定されたソフトウェアの再配布を行うことを特徴とするソフトウェア自動配布方法。」
 
２．引用例
　これに対し、原査定の拒絶の理由に引用された特開平１０−２７０９２号公報（以下、引用例１という。）には、以下の事項が図面と共に記載されている。
　
（Ａ）「　　【０００９】
　　【発明の実施の形態】
　以下、本発明のソフトウェアの管理方法をその実施形態例に基づいて詳しく説明する。
　　（第１実施形態例）
　まず、本発明の第１実施形態例を説明する。
　本発明におけるクライアント／サーバのネットワークシステムは、図５に示したものと同様に、通信回線等からなる通信経路１を介してサーバ２とクライアント３ａ、３ｂ、３ｃ、３ｄとが接続され、さらにソフトウェアの配布を行うためのマネージャ４が接続されて構築されたものである。ここで、サーバ２は、データベース等のアクセスを行う情報処理装置であり、クライアント３ａ、３ｂ、３ｃ、３ｄは、人が実際に業務上の操作を行うための端末である。また、マネージャ４は、ソフトウェアの配布元となる情報処理装置である。ただし、本発明においては、バージョン変更を行う場合、マネージャ４に登録した変更後のソフトウェアを、該マネージャ４からバージョン変更を必要とするサーバ２やクライアント３ａ、３ｂ、３ｃ、３ｄに個別に配布するのでなく、ソフトウェアを使用するファイル全てについて一括してバージョン変更を行うようにしている。」 
 　 
（Ｂ）「　【００１２】
　このようにして種類や用途毎に分類されたソフトウェアの一つについてそのバージョン変更を行う場合には、該ソフトウェアを使用するファイルのグループセット全てについて一括してそのバージョン変更を行うとともに、各バージョンの状態についても前記マネージャ４内のバージョン管理ファイルに記憶しておく。
ここで、各バージョンの状態とは、各バージョンの処理状況に応じた状態とされ、具体的には「予約中」、「運用中」、「切り戻し待機中」、「履歴管理中」、「管理対象外」の五種類に分けられる。そして、そのうちの「予約中」、「運用中」、「切り戻し待機中」、「履歴管理中」のみが前記バージョン管理ファイルに記憶されるようになっている。
　　　【００１３】
　「予約中」とは、将来の変更のためにマネージャ４に登録され保有されている状態を指す。すなわち、本実施形態例では、バージョン変更の際、これに先立って新しいバージョンのソフトウェアをマネージャ４に登録し、バージョン変更の予約を行う。
　「運用中」とは、マネージャ４に予約登録されたバージョンが、このソフトウェアを使用するグループセット内のファイル全てに配布されたことによってバージョン変更がなされ、実際に使用されている状態を指す。なお、この運用中のバージョンそのものは、これを使用するグループセット内のファイル全てに配布された後も、マネージャ４内に保有されている。
　　　【００１４】
　「切り戻し待機中」とは、実際に使用されていた、すなわち「運用中」にあったバージョンが、バージョンアップがなされたことによって新しく運用中になったバージョンに対し一世代前の古いバージョンとなり、運用されなくなった状態を指す。ただし、本実施形態例では、運用中のバージョンに対して一世代前のバージョンのみが「切り戻し待機中」となり、このバージョンそのものはマネージャ４に保有されたままとなっている。そして、運用中のバージョンに問題が生じた場合、後述するようにこのバージョンが再度運用に戻されるようになっているのである。」
　
（Ｃ）「　　【００１６】
　次に、図２に示すグループセット状態遷移図に基づき、本実施形態例のソフトウェア管理方法を具体的に説明する。
　図２に示したグループセット状態遷移図は、図１（ａ）、（ｂ）に示したグループセット「業務Ａ」の状態遷移を説明するためのものである。図２において左欄の（１）、（２）…（７）は時間経過に対応するものであり、これら（１）、（２）…（７）に対応する各欄には、特にバージョン変更に係わるときの各バージョンの状態が示されている。また、各欄中の四角で囲んだ１．００、２．００〜５．００はグループセット「業務Ａ」に使用されるソフトウェアのバージョンを示している。なお、図２中においては、当然１．００が最も古いバージョンであり、以下一世代ずつ新しくなって５．００が最も新しいバージョンであることを示している。」
　
（Ｄ）「【００２３】
　このような状態のもとで、運用中のバージョン４．００にバグの発生など何らかのトラブルが生じた場合、トラブルが生じたファイルのみでなく、グループセット全体を一世代前のバージョンに戻すべく、（７）に示すように「切り戻し待機中」にあったバージョン３．００を再度使用するファイル全てに対応させて配布し、これを運用に供してその状態を「運用中」に戻す。同時に、「運用中」にあったバージョン４．００を、グループセット全体から削除し、これにより該バージョン４．００を「予約中」に戻す。このとき、「管理対象外」にあるバージョン１．００はもちろん、「履歴管理中」にあるバージョン２．００についても、そのバージョンそのものがマネージャ４から削除されているため、その状態遷移は起こらず、同様に、「予約中」にあるバージョン５．００もその状態遷移が起こらない。
　その後、バージョン４．００のトラブルを解消すべく細部を改め、例えばバージョン４．１０を作成してこれを「予約中」、「運用中」へと状態遷移させ、あるいは「予約中」にあるバージョン５．００を「運用中」へと状態遷移させるといったことにより、グループセットのバージョンを逐次変更していく。」
　
（Ｅ）「　【００２５】
　　（第２実施形態例）
　次に、本発明の第２実施形態例を説明する。
　この第２実施形態例が先の第１実施形態例と異なるところは、「切り戻し待機中」の状態となるバージョンの世代数を予め設定できるようにしておき、設定した世代数分、切り戻し待機のためそのバージョンをマネージャ４内に保有しておくようにした点である。
　例えば、「切り戻し待機中」の状態となるバージョンの世代数を２と設定した場合、グループセットの状態遷移は図４に示すようになる。ここで、「切り戻し待機中」の状態には優先順位を付けておき、「運用中」の状態に続いて「切り戻し待機中」に遷移した状態を「第１切り戻し待機中」とし、この「第１切り戻し待機中」に続いて再度「切り戻し待機中」に遷移した状態を「第２切り戻し待機中」とする。
　なお、図４は先に示した図２と同様に、図１（ａ）、（ｂ）に示したグループセット「業務Ａ」の状態遷移を説明するためのものである。」
　
（Ｆ）「【００２８】
　このような状態のもとで、運用中のバージョン４．００にバグの発生など何らかのトラブルが生じた場合、第１実施形態例と同様にトラブルが生じたファイルのみでなく、グループセット全体を一世代前のバージョンに戻すべく、（４）に示すように「第１切り戻し待機中」にあったバージョン３．００を再度使用するファイル全てに対応させて配布し、これを運用に供してその状態を「運用中」に戻す。同時に、「第２切り戻し待機中」にあったバージョン２．００を「第１切り戻し待機中」に戻し、また「運用中」にあったバージョン４．００をグループセット全体から削除し、これにより該バージョン４．００を「予約中」に戻す。
このとき、「履歴管理中」にあるバージョン１．００については、そのバージョンそのものがマネージャ４から削除されているため、その状態遷移は起こらず、同様に、「予約中」にあるバージョン５．００もその状態遷移が起こらない。
　　　【００２９】
　さらに、切り戻して再度運用に供したバージョン３．００に、先の場合と同様にトラブルが生じた場合、再度切り戻しを行い、（５）に示すように「第１切り戻し待機中」にあったバージョン２．００を再度「運用中」に戻す。同時に、「運用中」にあったバージョン３．００を、グループセット全体から削除し、これにより該バージョン３．００を「予約中」に戻す。このとき、「履歴管理中」にあるバージョン１．００については、前述したようにその状態遷移は起こらず、同様に、「予約中」にあるバージョン４．００、バージョン５．００もその状態遷移が起こらない。」
　
上記（Ｃ)の記載によれば、
　図２に示したグループセット状態遷移図は図１（ａ）（ｂ）に示したグループセット「業務Ａ」の状態遷移を説明するものであり、図３がそのバージョン管理ファイルの記憶例を示している。そして、グループセットは「業務Ａ」だけでなく「業務Ｂ」もあるから、バージョン管理ファイルはグループセット毎のバージョンの状態を記憶していることになる。
　
上記（Ｄ）（Ｅ）（Ｆ）の記載によれば、
　マネージャが切り戻し処理を行うときにはバージョン管理ファイルを参照し、また、その状態を書き換えているからバージョン管理ファイルをアクセスする手段を有することは明らかである。
　
上記（Ｅ）（Ｆ）の記載によれば、
　切り戻しの世代数は任意に設定でき、切り戻しを繰り返すことにより任意の時点のバージョンまで切り戻しが可能となる。
　
  以上より、引用例１には以下の発明が記載されている。
　
　少なくともグループセットのバージョン情報及びグループセット毎のバージョンの状態を蓄積するバージョン管理ファイルと、前記バージョン管理ファイルの情報をアクセスするアクセス手段とを備えたマネージャが、通信回線を介し、グループセットを配布先に配布するソフトウェア自動配布方法において、切り戻し指示に基づいて前記バージョン管理ファイルをアクセスして、１世代前のバージョンのグループセットの再配布を繰り返すことにより任意の世代に切り戻しを行うことを特徴とするソフトウェア自動配布方法
　
 ３．対比・判断
 　
 本願の請求項２に係る発明（以下、本願発明という）と引用例１に記載された発明（以下、引用例１発明という）とを比較する。
　
　引用例１発明の「グループセット」は、ソフトウエアをグループ化したものであるから本願発明の「ソフトウエア」に相当する。引用例１発明の「グループ毎のバージョンの状態」とは、例えば、引用例１の図３に示されるようなグループセットのバージョンの配布状態が表形式のバージョン管理ファイルとなっているのであるから、引用例１発明の「グループセット毎のバージョンの状態を蓄積するバージョン管理ファイル」は、本願発明の「ソフトウエア毎のバージョンを管理する配布履歴表を含む配布状況の履歴を蓄積するソフトウエア配布情報蓄積ファイル」に対応するものである。
　そして、引用例１発明の「アクセス手段」は、バージョン管理ファイルから所望の情報を取り出すものであるから、本願発明の「蓄積ファイルの情報を検索する管理手段」と同等のものであり、引用例１発明の「マネージャ」は、ソフトウエアの配布元になる情報処理装置であり、登録されているソフトウエアをクライアントに配布しているから、ソフトウエアの配布を実行する制御手段を有するものであり、本願発明の「ソフトウエアの配布を実行する制御手段を備えた配布サーバ」に相当する。
　また、引用例１発明の「通信回線」は、本願発明の「ネットワーク」に相当するものである。
　また、切り戻しの処理として、引用例１発明において「グループセットの再配布を繰り返すことにより任意の世代に切り戻しを行う」ことは、本願発明における「指定され、特定されたソフトウエアの再配布を行う」ことと実質的に同等のことである。
　
　してみると、両者は次の点で一致している。
　
　少なくともソフトウェアのバージョン情報及びソフトウェア毎のバージョンを管理する配布履歴表を含む配布状況の履歴を蓄積するソフトウェア配布情報蓄積ファイルと、前記蓄積ファイルの情報を検索する管理手段と、ソフトウェアの配布を実行する制御手段とを備えた配布サーバが、ネットワークを介し、ソフトウェアを配布先に配布するソフトウェア自動配布方法において、切り戻し処理として前記配布履歴表を検索して配布が必要となるバージョンのソフトウェアを特定し、前記制御手段が、前記特定されたソフトウェアの再配布を行うことを特徴とするソフトウェア自動配布方法
　
　一方、両者は以下の点で相違している。
　
　本願発明では、配布履歴表が時間に応じたソフトウエア毎の管理を行うものであり、切り戻し処理としては切り戻し時刻を指定して配布が必要となるバージョンのソフトウエアを特定するものであるのに対し、引用例１発明では、配布履歴表は時間に応じておらず、切り戻し処理は１世代前にバージョンへの切り戻しを繰り返すものである点
　
４．相違点についての検討
　引用例１発明のバージョン管理ファイルは図３に示されるように、各バージョンが現在どのような状態にあるかを示すものであるが、バージョンの変更は「予約中」「運用中」「切り戻し待機中」「履歴管理中」「管理対象外」という順に推移するものであり、図２に示されるような状態遷移をとる。そして、図２において左欄の（１）〜（７）は時間経過に対応しているから、図３に示されるバージョン管理ファイルの状態は時間の要素を含むものである。また、バージョン管理において、バージョンを更新した時刻を記録することは通常の形態である（特開平９−７３３９０号公報におけるバージョン管理日付や特開平８−１７９９３５号公報におけるプログラム更新日付）。
　切り戻しは１つ前の世代に戻すのが普通であり、これはバージョン更新処理の時間経過を戻すことになる。引用例１発明ではバージョンを指定せずに現在の１世代前に戻しており、更に、任意の世代に戻すためには１世代前に戻す処理を繰り返しているが、バージョン変更時には変更日付や時刻を記録しておくことが普通のことであるから、１世代前に戻す処理を繰り返すことに変えて、バージョン更新処理の時間経過を戻すために時刻を指定して任意のバージョンに切り戻すようにすることは容易に為し得ることである。
　
５．むすび
　したがって、請求項２に係る発明は、引用例１に記載された発明及び当該分野の周知事項に基いて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。