【事件の表示】
　特願２００３−５２５４５４「完全なエンドツーエンド・ソフトウェア送達プロセス管理のための統合システムおよび方法」拒絶査定不服審判事件〔平成１５年　３月１３日国際公開、ＷＯ０３／２１４３２、平成１７年　１月２０日国内公表、特表２００５−５０２１１８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２００２年８月１３日（パリ条約による優先権主張外国受理２００１年８月３０日、アメリカ合衆国）を国際出願日とする出願であって、平成１６年４月２３日付けで審査請求がなされ、平成１８年６月２２日付けで拒絶理由が通知されたのに対して、平成１８年１２月２７日付けで手続補正がなされたが、平成１９年１月２３日付けで拒絶査定がなされ、これに対して同年５月１日付けで審判請求がなされるとともに同年５月３１日付けで手続補正がなされ、平成２０年１月２８日に前置報告がなされ、平成２１年５月１日付けで当審より審尋がなされたのに対して、同年８月１１日付けで回答書が提出されたものである。
　
第２．補正却下の決定
　
［結論］
　　　　平成１９年５月３１日付けの手続補正を却下する。
　
［理由］
その１．補正の内容
　平成１９年５月３１日付けの手続補正（以下、「本件手続補正」という）により、特許請求の範囲は、
　補正前の特許請求の範囲
「【請求項１】ネットワーク環境で複数のソフトウェア・コンポーネントを含むソフトウェアパッケージをその実行ユニットへの配布するプロセスを管理する統合データ処理システムであって、
前記ソフトウェア・コンポーネントを記憶する中央リポジトリと、
前記中央リポジトリ内で、配布の対象となるソフトウェア・コンポーネントを識別する第１のサブシステムと、
前記第１のサブシステムによって識別された前記ソフトウェア・コンポーネントから前記実行ユニットにおいて実行可能なソフトウェアパッケージを作成する第２のサブシステムと、
前記第２のサブシステムによって作成された前記ソフトウェアパッケージを前記実行ユニットに配布する第３のサブシステムとを含む統合データ処理システム。
【請求項２】前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルである請求項１に記載の統合データ処理システム。
【請求項３】前記第1のサブシステムは、前記ソフトウェア・コンポーネントのバージョンを識別し、
前記第2のサブシステムは、当該バージョンに基づいてソフトウェアパッケージを作成する請求項１に記載の統合データ処理システム。
【請求項４】前記第1のサブシステムは、前記複数のソフトウェア・コンポーネント間の依存性を識別し、
前記第2のサブシステムは、当該依存性に基づいてソフトウェアパッケージを作成する請求項１に記載の統合データ処理システム。
【請求項５】前記第２のサブシステムによって作成された前記ソフトウェアパッケージを記憶するソフトウェア・パッケージ配布リポジトリをさらに含む、請求項１に記載の統合データ処理システム。
【請求項６】前記第1のサブシステムは、前記ソフトウェア・コンポーネントが前記実行ユニットに配布済みソフトウェア・パッケージに含まれるか否かを識別し、
前記第2のサブシステムは、前記ソフトウェア・コンポーネントが配布済みソフトウェア・パッケージに含まれるか否かに基づいてソフトウェアパッケージを作成する請求項１に記載の統合データ処理システム。
【請求項７】前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルであり、
当該ソース・コードから当該バイナリ・ファイルを生成するのに必要なスクリプトを構築する第４のサブシステムをさらに含む請求項１に記載の統合データ処理システム。
【請求項８】前記中央リポジトリは、前記スクリプトの構築結果を記憶する請求項７に記載の統合データ処理システム。
【請求項９】既に前記実行ユニットに配布されたソフトウェアパッケージに変更を適用するプロセスを管理する第５のサブシステムをさらに含む、請求項１に記載の統合データ処理システム。
【請求項１０】前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルであり、
当該ソース・コードから当該バイナリ・ファイルを生成するのに必要なスクリプトを構築する第４のサブシステムと、
既に前記実行ユニットに配布されたソフトウェアパッケージに変更を適用するプロセスを管理する第５のサブシステムと、
統合データ処理システムの前記第１から第５のサブシステムの少なくとも１つによって提供される情報を記録する第６のサブシステムとをさらに含む、請求項１に記載の統合システム。
【請求項１１】ネットワーク環境で複数のソフトウェア・コンポーネントを含むソフトウェアパッケージをその実行ユニットへ配布する方法であって、
前記ソフトウェア・コンポーネントを中央リポジトリに記憶するステップと、
前記中央リポジトリ内で、配布の対象となるソフトウェア・コンポーネントを識別するステップと、
前記第１のサブシステムによって識別された前記ソフトウェア・コンポーネントから前記実行ユニットにおいて実行可能なソフトウェアパッケージを作成するステップと、
前記第２のサブシステムによって作成された前記ソフトウェアパッケージを前記実行ユニットに配布するステップとを含む方法。」（以下、「補正前請求項」という）から、
　
　補正後の特許請求の範囲
「【請求項１】ネットワーク環境で複数のソース・コードであるソフトウェア・コンポーネントを含むソフトウェアパッケージをその実行ユニットへの配布するプロセスを管理する統合データ処理システムであって、
前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルであり、
前記ソフトウェア・コンポーネントを記憶する中央リポジトリと、
前記中央リポジトリ内で、配布の対象となるソフトウェア・コンポーネントを識別する第１のサブシステムと、
前記第１のサブシステムによって識別された前記ソフトウェア・コンポーネントから前記実行ユニットにおいて実行可能なソフトウェアパッケージを作成する第２のサブシステムと、
前記第２のサブシステムによって作成された前記ソフトウェアパッケージを前記実行ユニットに配布する第３のサブシステムと、
当該ソース・コードから当該バイナリ・ファイルを生成するのに必要なスクリプトを構築する第４のサブシステムと
を含み、
前記第１のサブシステムは、前記ソフトウェア・コンポーネントのバージョンおよび前記複数のソフトウェア・コンポーネント間の依存性を識別し、
前記第2のサブシステムは、当該バージョンおよび当該依存性に基づいてソフトウェアパッケージを作成する統合データ処理システム。
【請求項２】前記第２のサブシステムによって作成された前記ソフトウェアパッケージを記憶するソフトウェア・パッケージ配布リポジトリをさらに含む、請求項１に記載の統合データ処理システム。
【請求項３】前記中央リポジトリは、前記スクリプトの構築結果を記憶する請求項１に記載の統合データ処理システム。
【請求項４】既に前記実行ユニットに配布されたソフトウェアパッケージに変更を適用するプロセスを管理する第５のサブシステムをさらに含む、請求項１に記載の統合データ処理システム。
【請求項５】統合データ処理システムの前記第１から第５のサブシステムの少なくとも１つによって提供される情報を記録する第６のサブシステムをさらに含む、請求項４に記載の統合システム。
【請求項６】ネットワーク環境で複数のソフトウェア・コンポーネントを含むソフトウェアパッケージをその実行ユニットへ配布する方法であって、
前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルであり、
前記ソフトウェア・コンポーネントを中央リポジトリに記憶するステップと、
前記中央リポジトリ内で、配布の対象となるソフトウェア・コンポーネントを識別するステップと、
前記第１のサブシステムによって識別された前記ソフトウェア・コンポーネントから前記実行ユニットにおいて実行可能なソフトウェアパッケージを作成するステップと、
前記第２のサブシステムによって作成された前記ソフトウェアパッケージを前記実行ユニットに配布するステップと
当該ソース・コードから当該バイナリ・ファイルを生成するのに必要なスクリプトを構築するステップとを含み、
前記識別するステップは、前記ソフトウェア・コンポーネントのバージョンおよび前記複数のソフトウェア・コンポーネント間の依存性を識別し、
前記作成するステップは、当該バージョンおよび当該依存性に基づいてソフトウェアパッケージを作成する方法。
」（以下、「補正後請求項」という）に補正された。
　
その２．補正の適否
Ａ．新規事項の有無、補正の目的要件について
　本件手続補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、補正前請求項１に記載された発明特定事項である「ソフトウェア・コンポーネント」及び「ソフトウェアパッケージ」を、同請求項２に記載の「前記ソフトウェア・コンポーネントはソース・コードであり、前記ソフトウェアパッケージはバイナリ・ファイルである」ものに限定し、同請求項１に記載された発明特定事項である「第１のサブシステム」及び「第２のサブシステム」を、同請求項３に記載の「前記第１のサブシステムは、前記ソフトウェア・コンポーネントのバージョンを識別し、前記第２のサブシステムは、当該バージョンに基づいてソフトウェアパッケージを作成する」するものに限定し、更に、同請求項１に記載された発明特定事項である「前記実行ユニットにおいて実行可能なソフトウェアパッケージを作成する」構成について、同請求項７に記載の「当該ソース・コードから当該バイナリ・ファイルを生成するのに必要なスクリプトを構築する第４のサブシステム」という事項で限定することで、特許請求の範囲を減縮するものであるから、特許法第１７条の２第３項（新規事項）及び第４項第２号（補正の目的）の規定に適合している。
　
Ｂ．独立特許要件について
　本件手続補正は特許請求の範囲の減縮を目的とするものであるから、補正後請求項１に係る発明（以下、「補正後発明」という）が、特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後発明
　上記「その１．の内容」の項において引用した、「補正後請求項１」に記載されたとおりのものである。
　
（２）引用発明及び周知技術
　原審の拒絶査定時に周知技術文献として引用された特開２０００−３３０７７３号公報（以下、「周知刊行物１」という）には、関連する図面とともに以下の事項が記載されている。
　
ａ．「【０００３】このようなシステム統合を行う際には、システム統合部門の担当者は、各開発グループより納入された
ソースファイルやドキュメントファイル等の納入物件
（なお、上記引用記載中の下線は当審で付したものである。以下同じ。）
　
ｂ．「【００１１】
【課題を解決するための手段】上記目的を達成するべく、この発明の第１の観点に係る
自動統合装置は、システム統合の対象となるプログラムコードを記録したソースファイルを格納するファイル格納手段と、前記ソースファイルのビルドを実行して統合し、リリースファイルを作成する
　
ｃ．「【００１４】また、電子メールを受信してその内容を保存する受信手段を備え、前記統合手段は、前記受信手段が受信した電子メールのうち統合申請書を示すものを読み取り、前記
ソースファイルを一括してビルドするためのメイクファイルを生成するメイクファイル生成手段と、前記メイクファイルを読み取り、前記ソースファイルのビルドを実行して実行形式のバイナリファイルを生成するビルド実行手段と、前記バイナリファイルと前記ソースファイルとに基づいてリリースファイルを作成するリリースファイル作成手段とを備えてもよい
　
ｄ．「【００３１】図２は、
自動統合装置４の構成を示す図
ファイル装置１４
・・・（中略）・・・
【００３３】
ファイル装置１４
ソースファイルＦ１
構成管理情報ファイルＦ８
【００３４】
ソースファイルＦ１は
ソフトウェアのコンポーネントとなるプログラムコードを記載したファイルであり
・・・（中略）・・・
【００３６】
統合用スクリプトファイルＦ３は、コンポーネントどうしの依存関係を示し、納入物件を一括してビルドするためのメイクファイルである
【００３７】
バイナリファイルＦ４は、統合用スクリプトファイルＦ３の記載内容に従ってソースファイルＦ１のコンパイル、リンク等を実行した結果生成される、実行形式のファイルである
・・・（中略）・・・
【００４０】リリースファイルＦ７は、ソースファイルＦ１とドキュメントファイルＦ２及びバイナリファイルＦ４をまとめ、バージョン情報を付加したリリース用のファイルである。」
　
ｅ．「【００４８】次に、上記構成を有する自動統合システムにおける自動統合装置４の論理的構成を図３を参照して説明する。図示するように、
自動統合装置４は、統合処理部１００と、ＷＥＢ処理部２００と、判定監視部３００とから構成される
【００４９】
統合処理部１００は
統合申請書に応じてリリースファイルＦ７を作成する
情報解析部５０と、ビルド処理部５１と、物件作成部５２とを備えている
【００５０】
情報解析部５０は、
納入物件を一括ビルドするためのメイクファイルである統合用スクリプトファイルＦ３を生成するためのものである
　
ｆ．「【００６８】情報解析部５０は、登録処理部６０から受けた統合申請書の記載通りにソースファイルＦ１が揃っているか否かを判別する。すなわち、
情報解析部５０は、統合申請書と納入物件との整合性をチェックし（ステップＳ３）、統合申請書からソースファイルＦ１の依存関係を把握して、統合用スクリプトファイルＦ３を生成する
　
ｇ．「【００７６】一方、情報解析部５０は、統合用スクリプトファイルＦ３を生成する際にエラーが発生しなかったと判別すると（ステップＳ５にてＮＯ）、
生成した統合用スクリプトファイルＦ３をビルド処理部５１に送り、ビルドを実行可能とする
【００７７】
ビルド処理部５１は、情報解析部５０から受けた統合用スクリプトファイルＦ３の記載内容に従って、ソースファイルＦ１のコンパイル、リンクを実行し、実行形式のバイナリファイルＦ４を生成する
・・・（中略）・・・
【００８６】
物件作成部５２は
バイナリファイルＦ４を受けると、これをソースファイルＦ１及びドキュメントファイルＦ２と共にまとめてリリースファイルＦ７を作成
【００８７】物件作成部５２は、リリースファイルＦ７を構成するファイルを構成管理情報ファイルＦ８に記録する。」
　
ｈ．「【００９１】編集処理部６１は、登録処理部６０から受けた電子メールの内容、受取日時等を構成管理情報一覧ファイルＦ１２に書き込み、ＷＥＢサーバ５に送信して構成管理情報一覧ファイルＦ１２を更新する（ステップＳ１０）。これにより、
リリースファイルＦ７を構成するファイルをＷＥＢドキュメントで示してＷＥＢサーバ５に格納し、インターネットやイントラネットを利用して確認することができる
【００９２】また、編集処理部６１は、検証結果一覧ファイルＦ１４に、リリースファイルＦ７が内部リリース中となったことを書き込み、ＷＥＢサーバ５に送信して検証結果一覧ファイルＦ１４を更新する（ステップＳ１１）。
【００９３】このようにして、自動統合装置４は、検証部門にて動作テスト等の検証を行うための内部リリース用のリリースファイルＦ７を作成して、リリース作成処理を終了する。
【００９４】この後、検証部門の担当者は、
検証用コンピュータ２を操作して、ネットワーク６を介して自動統合装置４からリリースファイルＦ７をダウンロードして担当する機能についての検証を実行する
　
ｉ．「【０１１２】このようにして
検証が終了したリリースファイルＦ７は、正式にリリースするための物件となり
　
　同じく、原審の拒絶査定時に周知技術文献として引用された特開２０００−１７２４８９号公報（以下、「周知刊行物２」という）には、対応する図面とともに以下の事項が記載されている。
ｊ．「【００１５】次に、図１を参照して、この第１実施の形態のより詳細な構成について説明する。図１は図２の一つの製品に対する詳細な実施の形態で、分散している開発環境１と、開発物件を統合する統合物件格納場所２と、製品構成やファイルの情報を登録するリポジトリ３と、統合を制御する統合制御手段４と、作成された製品５と、
製品情報ファイルがインストールされるコンピュータ６とを備えている
　
ｋ．「【００１７】
製品５は、コンピュータ６上で動作するために必要な製品ファイル５１と、コンピュータ６にインストールするときに必要な製品情報ファイル５２と、製品ファイル５１の情報と製品情報ファイル５２の情報とをコンピュータ６の製品ファイル６１にインストールするためのインストーラ５３を含む
　
　更に、本願の出願時点において、既に公知の文献である特開平０７−０９３１４２号公報（１９９５年４月７日公開　以下、「周知刊行物３」という）には、対応する図面とともに以下の事項が記載されている。
ｌ．「【００１３】こうして
変更履歴管理環境部２に各ソースコードが登録されると、システム管理者４により第２のツール３が使用されてマスターのソフトウェアがビルドされる
第２のツール３は、フェーズ・ナンバーをバージョン・ナンバーに変換してビルドに用いられるソースコードを変更履歴管理環境部２から抽出する。そして抽出されたソースコードをビルド環境部５に展開する。こうして展開されたソースコードはビルド環境部５で一括してビルドが実施され、マスターのソフトウェアが特定フェーズソフトウェア７として生成される
　
（あ）上記ｂから、周知刊行物１には、“プログラムコードを記憶したソースファイルを格納するファイル格納手段と、ソースファイルのビルドを実行して統合し、リリースファイルを作成する統合手段”を有する「自動統合装置」が記載されていることが読み取れる。
　
（い）上記ｃから、「統合手段」が、ソースファイルを一括してビルドするための「メイクファイル」を生成する「メイクファイル生成手段」、メイクファイルを読み取り、ソースファイルのビルドを実行して実行形式の「バイナリファイル」を生成する「ビルド実行手段」と、「バイナリファイル」と「ソースファイル」とに基づいて「リリースファイル」を作成する「リリースファイル作成手段」とを有することが読み取れる。
　
（う）上記ｄから、「ソースファイルＦ１」は、「ファイル装置１４」に記録され、「ソフトウェアのコンポーネントとなるプログラムコード」を記載したファイルであること、「バイナリファイルＦ４」は「ソースファイルＦ１」をコンパイルした実行形式のファイルであること、「メイクファイル」は「統合用スクリプトファイルＦ３」であること、「リリースファイル」が「ソースファイルＦ１とドキュメントファイルＦ２及びバイナリファイルＦ４をまとめ、バージョン情報を付加したリリース用のファイル」であることが読み取れる。
　
（え）上記ａ、ｃ、ｅ及びｆから、「ソースファイルＦ１」は複数存在し、「自動統合装置」は「統合処理部」を有し、該 「統合処理部」は、統合申請書に応じてリリースファイルＦ７を作成するためのものであり、“「統合申請書」を解析し、「ソースファイルＦ１」を一括ビルドするための「統合用スクリプトファイルＦ３」を生成する”情報解析部を有し、「統合用スクリプトファイルＦ３」は、「ソースファイルＦ１」の依存関係を把握して生成されている点が読み取れる。
　
（お）上記ｇから「ビルド処理部５１」が「統合用スクリプトファイルＦ３」の記載内容に従って、「ソースファイルＦ１」のコンパイル、リンクを実行して「バイナリファイルＦ４」を生成する点が読み取れる。
　
（か）上記ｂ及びｈから、「自動統合装置」では、「リソースファイル」のビルドを実行して「リリースファイル」を作成し、該「リリースファイル」をＷＥＢサーバに登録して「インターネット」や「イントラネット」を利用して確認できるようにする点が読み取れ、「確認」及び「検証」ができる以上は利用可能であることは明らかであるから、
　
　以上の（あ）〜（か）に指摘した点から、周知刊行物１には、以下の発明（以下、「周知発明」という）が記載されているものと認める。
　
　インターネットやイントラネットの環境において複数のソフトウェアのコンポーネントを含み、ソースファイル、ドキュメントファイル及びバイナリファイルをまとめたリリースファイルを利用可能にする過程を管理する自動統合装置であって、
　前記ソフトウェアのコンポーネントを記憶するファイル装置と、
　前記ファイル装置において、ビルドの対象となるソフトウェアのコンポーネントを統合申請書に応じて判別する情報解析部と、
　情報解析部によって判別された前記ソフトウェアのコンポーネントに対して、コンパイル、リンクを実行してバイナリファイルを作成するビルド処理部と、
　前記ソフトウェアのコンポーネントを含み、ソースファイル、ドキュメントファイル及びバイナリファイルをまとめたリリースファイルを作成する物件作成部とを有し、
　前記情報解析部は、ビルド処理部にて、複数のソフトウェアのコンポーネントをビルドするために必要な統合スクリプトファイルを、該ソフトウェアのコンポーネントの依存関係を把握して生成し、
　前記ビルド処理部は、該統合スクリプトファイルに基づいてバイナリファイルを作成する
自動統合装置。
　
（３）補正後発明と周知発明との対比
　次に、補正後発明と周知発明とを対比する。
　周知発明における「インターネットやイントラネットの環境」とは、ネットワーク環境であることは明らかであって、
　周知発明における「ソフトウェアのコンポーネント」が、補正後発明の「ソフトウェア・コンポーネント」に相当し、
　周知発明における「リリースファイル」も、補正後発明における「ソフトウェアパッケージ」も共に、「複数のソフトウェア・コンポーネント」を含む“ファイル”である点で共通し、
　周知発明における「自動統合装置」が、「リリースファイル」を作成する過程を管理していることは明らかであり、また、、補正後発明における「統合データ処理システム」が「パッケージファイルを作成する」までのプロセスを管理していることも明らかであるから、
　周知発明における「自動統合装置」も、補正後発明における「統合データ処理システム」も、共に、「リリースファイル」、あるいは、「ソフトウェアパッケージ」を作成するプロセスを管理する「管理システム」である点で共通し、
　周知発明における「ファイル装置」が、補正後発明における「中央リポジトリ」に相当し、
　周知発明における「情報解析部」は、「ファイル装置において、ビルドの対象となるソフトウェアのコンポーネントを判別」しており、補正後発明における「第１のサブシステム」が、「中央リポジトリ内で、配布の対象となるソフトウェア・コンポーネントを識別」していることから、
　周知発明における「情報解析部」も、補正後発明における「第１のサブシステム」も「対象となるソフトウエア・コンポーネント識別」している「第１のシステム」である点で共通し、
　周知発明における「情報解析部」において、「複数のソフトウェアのコンポーネントの依存関係を把握する」ことは、「複数のソフトウェアのコンポーネント間の依存性を識別する」こととほぼ同義であるから、補正後発明における「第１のサブシステム」において「複数のソフトウェア・コンポーネント間の依存性を識別し」に相当し、
　周知発明においては、「ビルド処理部」において、「情報解析部」にて判別された「ソフトウェアのコンポーネント」から「バイナリファイル」が作成され、補正後発明においては、「第２のサブシステム」において、「前記実行ユニットにおいて実行可能なソフトウェアパッケージ」が作成され、該「ソフトウェアパッケージ」は、「バイナリ・ファイル」でかるから、
　周知発明における「ビルド処理部」と、補正後発明における「第２のサブシステム」とは、「バイナリ・ファイル」を作成する「第２のシステム」である点で共通し、
　周知発明における「統合用スクリプトファイル」は、その記載内容に従って、「ソースファイル」のコンパイル、リンクを実行して「バイナリファイル」を生成するものであるから、該「統合スクリプトファイル」が、補正後発明における「スクリプト」に相当し、
　周知発明も、補正後発明も、該「スクリプト」を生成する「スクリプト生成手段」を有し、該「スクリプト」を用いて「ファイル」を生成している点で共通しているので、
　補正後発明と周知発明との一致点・相違点は以下のとおりである。
　
［一致点］
　ネットワーク環境で複数のソース・コードであるソフトウェア・コンポーネントを含むファイルを作成するプロセスを管理する管理システムであって、
　前記ソフトウェア・コンポーネントはソース・コードであり、前記ファイルはバイナリ・ファイルを含むものであり、
　前記ソフトウェア・コンポーネントを記憶する中央リポジトリと、
　前記中央リポジトリ内で、対象となるソフトウェア・コンポーネントを識別する第１のシステムと、
　前記第１のシステムによって識別された前記ソフトウェア・コンポーネントからバイナリ・ファイルを作成する第２のシステムと、
　当該ソース・コードから当該バイナリ・ファイルを作成するのに必要なスクリプトを構築するスクリプト生成手段とを含み、
　前記第１のシステムは、前記ソフトウェア・コンポーネント間の依存性を識別し、
　前記第２のシステムは、当該依存性に基づいてバイナリ・ファイルを作成する管理システム。
　
［相違点］
（イ）「管理システム」が、
　補正後発明においては、「ソフトウェアパッケージをその実行ユニットに配布する」機能も有する「統合データ処理システム」であり、
　そのため、「第２のサブシステムによって作成されたソフトウェアパッケージを実行ユニットに配布する第３のサブシステム」を有するのに対して、
　周知発明においては、「ソースファイル、ドキュメントファイル及びバイナリファイルをまとめたリリースファイルを利用可能にする過程を管理する」「自動統合装置」であり、該「リリースファイル」を「実行ユニット」に配布する点については言及されていない点
　
（ロ）「スクリプト」を生成する「スクリプト生成手段」について、
　補正後発明においては、「スクリプトを構築する第４のサブシステム」を有しているのに対して、
　周知発明においては、補正後発明における「第１のサブシステム」に相当する「情報解析部」において「統合スクリプトファイル」が生成されている点、
　
（ハ）「第１のシステム」及び「第２のシステム」について、
　補正後発明における「第１のシステム」である、「第１のサブシステム」は、「ソフトウェア・コンポーネントのバージョン」も「識別」し、同「第２のシステム」である「第２のサブシステム」は、「依存性」と「ソフトウェア・コンポーネントのバージョン」に基づいて「ソフトウェアパッケージ」を作成しているのに対して、周知発明における「第１のシステム」及び「第２のシステム」である、「情報解析部」および「ビルド処理部」においては、「バージョン」を識別する点については、特に言及されていない点
　
（ニ）「ソース・コード」である「ソフトウェア・コンポーネント」から生成される「ファイル」が、補正後発明においては、「第２のサブシステム」において作成される「バイナリ・ファイル」である「実行ユニットにおいて実行可能なソフトウェアパッケージ」であるのに対して、周知発明においては、「物件作成部」において、「ソースファイル、ドキュメントファイル及びバイナリファイルとをまとめて」作成される「リリースファイル」である点
　
（４）当審の判断
　以下、上記相違点について検討する。
　
・相違点（イ）について
　周知刊行物２の上記ｊ．ｋとして引用した記載にもあるように、作成した製品ファイルをコンピュータに自動的にインストールすることは、周知の事項である。
　また、該製品ファイルを作成する部分と、該製品ファイルをインストールするコンピュータとをネットワークを介して接続する構成を採用することも、当業者には周知の事項であるから、周知発明における「自動統合装置」において、「リリースファイル」を利用可能にする過程を管理する一環として、ネットワークを介して接続されたコンピュータにインストールすることは、当業者が適宜なし得る事項である。
　よって、相違点（イ）は格別のものではない。
　
・相違点（ロ）について
　周知発明において、「スクリプト」を生成する箇所として「情報解析部」に替えて、専用の「第４のサブシステム」を設けることは、当業者が適宜なし得る事項である。
　よって、相違点（ロ）は格別のものではない。
　
・相違点（ハ）について
　周知刊行物３のｌとして引用した記載にもあるように、ソースコードを用いてビルドを行う場合に、該ソースコードのバージョンを識別してビルドを行うことは、当業者にとって周知の事項である。
　したがって、周知発明において、「情報解析部」で「ソフトウェア・コンポーネントのバージョンを識別」し、該識別した「バージョン」に基づいて、ビルドを行うようにすることは、当業者が適宜なし得る事項である。
　よって、相違点（ハ）は格別のものではない。
　
・相違点（ニ）について
　「ソースファイル」をコンパイルして作成された「バイナリファイル」が、コンピュータにおける「実行ファイル」であることは、当業者にとって周知の事項である。
　したがって、周知発明において、「リリースファイル」を「物件作成部」において作成された「ソースファイル、ドキュメントファイル及びバイナリファイル」からなる「リリースファイル」に替えて、「ビルド処理部」において作成された「バイナリ・ファイル」のみから構成されるものとすることは、当業者が適宜なし得る事項である。
　よって、相違点（ニ）は格別のものではない。
　
　上記で検討したごとく、相違点（イ）乃至（ニ）はいずれも格別のものではなく、そして、補正後発明の構成によってもたらされる効果も、当業者であれば容易に予測できる程度のものであって、格別なものとは認められない。
　以上のとおり、補正後発明は、周知発明及び当該技術分野における周知の技術知識とから、当業者が容易になし得るものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができない。
　
その４．補正却下むすび
　本件手続補正は、以上Ｂで指摘したとおりであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
その１．本願発明
　平成１９年５月３１日付け手続補正は上記のとおり却下されたので、本願の請求項１に係る発明は、平成１８年１２月２７日付け手続補正により補正された明細書及び図面の記載からみて、上記第２のその１．において「補正前の特許請求の範囲」として引用した、補正前請求項１に記載されたとおりのもの（以下、これを「本願発明」という）であると認める。
　
その２．引用刊行物に記載の発明
　原審において拒絶理由に引用された国際公開第００／７３９０１号（２０００年１２月７日公開、以下これを「引用刊行物１」という）には、対応する図面とともに以下の事項が記載されている。
ｍ．「Referring now to  FIG. 3 , wherein one embodiment of a vendor development/code control environment suitable for use to practice the present invention is shown. ・・・・（中略）・・・・ For the illustrated embodiment, development/code control environment  300  includes library  302 , repository  304 , check-in and check out functions  306 - 308 , editor and compiler/linker  310 - 312 , delta generator  314  and distributor  316 . 」
（第３図を参照すると、そこには、本発明を実施するために用いるに適した、ベンダの開発／コード制御環境が示されている。・・・・（中略）・・・・図に示された実施例においては、開発／コード制御環境３００は、ライブラリ３０２、リポジトリ３０４、チェック・イン３０６とチェック・アウト機能３０８、エディタ３１０とコンパイラ／リンカ３１２と、差分生成機３１４と配布装置３１６とを含む。）（第６頁第１３乃至２３行より当審にて訳出、以下同じ。）
　
ｎ．「Library  302  is used to store source files  318  of a program product in either a base or a delta form (depending on whether the source file is the root or a subsequent change), as well as object files  319  of the program product. Each base/delta source file  318  is advantageously identified by an universally unique identifier (UUID), that uniquely identifies the base/delta source file not only among the base/delta source files of the program product, but among the source files of all program products of all vendors. ・・・・（中略）・・・・ Repository  304  is used to store versioning control information  320  of source and object files  318  and  319 .」
（ライブラリ３０２は、（ソースファイルがルートか、その後に変更されたものかに依存した）基本、あるいは、差分形式のプログラム・プロダクトのソースファイル３１８を格納するために用いられ、同様に、プログラム・プロダクトのオブジェクトファイル３１９の格納にも用いられる。基本／差分ソースファイル３１８のそれぞれは、普遍的に唯一の識別子（ＵＵＩＤ）によって、都合良く識別される。これは、その基本／差分ファイルを、そのプログラム・プロダクトの基本／差分ファイルから、一意的に識別するだけでなく、全てのベンダの全てのプログラム・プロダクトのソースファイルから、一意的に識別する。・・・・（中略）・・・・リポジトリ３０４は、ソースファイル３１８とオブジェクトファイル３１９のバージョンを制御する情報３２０を格納する。）（第６頁第２５行乃至第７頁第８行）
　
ｏ．「Check-in and check-out functions  306 - 308  perform their conventional functions of checking in the base/delta source files or selectively checking out different versions of the source and object files, except that check-in and check-out functions  306 - 308  operate with source and object files that are advantageously identified by the above described UUIDs. Editor  310  performs its conventional function of editing the checked out source files, and compiler/linker  312  performs its conventional function of compiling/linking the checked out/edited compilable source files. Similarly, delta generator  314  performs the conventional function of creating delta source files based on the check-out and modified versions of a source file. Last but not least, distributor  316  performs the conventional function of distributing program products to users, ・・・・（中略）・・・・For the purpose of this application, the term distribution includes packaging of the program products onto distribution medium, such as tapes, diskettes, CDROM, and so forth, for distribution, as well as transferring of the program products to the user systems or their proxies (such as a corporate or publisher server) through a wireless or wired medium, such as a public data network (e.g. the Internet). 」
（チェック・イン機能３０６とチェック・アウト機能３０８は、上記のＵＵＩＤによって都合良く識別されるソースファイルとオブジェクトファイルに作用する以外は、基本／差分ソースファイルを取り込むこと、あるいは、ソースファイルファイルとオブジェクトファイルの異なるバージョンを選択的に取り出すことを実行する。エディタ３１０は、取り出されたソースファイルを編集するエディタの通常の機能を実行する。そして、コンパイラ／リンカ３１２は、取り出された／編集され、コンパイル可能なソースファイルを、コンパイルする／リンクするための、コンパイラ／リンカの通常の機能を実行する。同様に、差分生成機３１４は、ソースファイルの取り出され、変更されたバージョンに基づいて、差分ソースファイルを生成するための通常の機能を実行する。最後ではあるが、特に、配布装置３１６は、ユーザにプログラム・プロダクトを配布する。・・・・（中略）・・・・このアプリケーションの目的のために、配布という用語は、テープ、ディスク、ＣＤ−ＲＯＭなどといった、配布メディアに、プログラム・プロダクトをパッケージングすること、同じく、配布のために、プログラム・プロダクトを、ユーザシステム、あるいは、（企業の、あるいは、発行側のサーバといった）ユーザシステムのプロキシへ、（例えば、インターネットのような）公共のデータネットワークといった、無線の、あるいは、有線の媒体を介して送信することを含む。）（第７頁第１６行乃至第８頁７行）
　
ｐ．「The dependency and other control information are determined based on information stored in associated control files generated by compiler/linker  312 . Next, check-in function  306  stores the base/delta source file in library  302 , and the predecessor UUID, dependency and other control information (if any) in repository  304 , step  508 .」
（依存性及び他の制御情報は、コンパイラ／リンカによって生成される、関連した制御ファイルに格納された情報に基づいて決定される。次いで、チェック・イン機能３０６は、ステップ５０８で、基本／差分ソースファイルをライブラリ３０２に格納し、前のＵＵＩＤ、依存性、そして、（もしあるならば）他の制御情報をリポジトリ３０４に格納する。）（第９頁第２１乃至２５行）
　
ｑ．「For the illustrated embodiment, distributor  316  also retrieves the base/delta source files  318  from library  302 , and distributes them for storage for the user system, step  606 . 」
（記載された実施例においては、ステップ６０６において、配布装置３１６は、また、ライブラリ３０２から、基本／差分ソースファイル３１８を検索し、それらをユーザシステムのための記憶装置に配布する。）（第１０頁第１９乃至２１行）
　
ｒ．「 In alternate embodiments, object files  319  may also be retrieved and distributed. 」
（他の実施例において、オブジェクトファイル３１９もまた、検索され、配布される。）（第１１頁第１及び第２行）
　
ｓ．引用刊行物１の第３図を参照すると、ライブラリ３０２とリポジトリ３０４の出力がチェック・アウト機能３０８と配布装置３１６に入力され、チェック・アウト機能３０８の出力が、コンパイラ／リンカ３１２と、差分生成機３１４を経由して、あるいは、エディタ３１０と差分生成機３１４とを経由してチェック・イン機能３０６に入力され、チェック・イン３０６からの出力がライブラリ３０２とリポジトリ３０２に入力される構成が記載されている。
　
（き）上記ｍ、ｓから、引用刊行物１には、ライブラリ３０２、リポジトリ３０４、チェック・イン３０６とチェック・アウト機能３０８、エディタ３１０とコンパイラ／リンカ３１２と、差分生成機３１４と配布装置３１６とを含む開発／コード制御環境３００が記載されていることが読み取れ、該ライブラリ３０２等の構成をすることから、該開発／コード制御環境３００はシステムであり、該ライブラリ３０２等における一連の処理が管理されていることは明らかである。
　
（く）上記ｎ、ｓから、ライブラリ３０２は、ソースファイル３１８とオブジェクトファイル３１９が格納され、リポジトリ３０４には、ソースファイル３１８とオブジェクトファイル３１９のバージョンを制御する情報３２０を格納されていること、また、ソースファイル３１８とオブジェクトファイル３１９（第３図では、「オブジェクトコード」）が複数存在することが読み取れる。
　
（け）上記ｏ、ｓから、 チェック・アウト機能３０８は、ソースファイルファイルとオブジェクトファイルの異なるバージョンを選択的に取り出すことを実行すること、
　コンパイラ／リンカ３１２は、取り出された／編集され、コンパイル可能なソースファイルを、コンパイルする／リンクするための、コンパイラ／リンカの通常の機能を実行すること、配布装置３１６は、ユーザにプログラム・プロダクトを配布することが読み取れ、引用刊行物１においては、プログラム・プロダクトはパッケージメディアを介して、或いは、インターネットといった、ネットワークを介してユーザのシステム、または、プロキシサーバへ、配布、あるいは、送信される点が読み取れ、
　該チェック・アウト機能３０８が、異なるバージョンを選択的に取り出している以上、取り出し対象のファイルを識別していることは明らかである。
　ここで、引用刊行物１の記載からは、該コンパイラ／リンカ３１２の出力先が何処であるか明確ではないが、該コンパイラ／リンカの出力がオブジェクトコードであることは明らかであり、上記ｎと、上記ｓで参照した引用刊行物１の第３図の内容から、オブジェクトファイル、あるいは、オブジェクトコードはライブラリ３０２に格納されていること、
　そして上記ｐの内容から、該コンパイラ／リンカ３１２で生成される情報に基づいて決定された制御情報が、制御情報を格納するリポジトリ３０４に格納されていることから、該コンパイラ／リンカ３１２で生成されたオブジェクトコードは、該ライブラリ３０２に格納されるものと解するのが妥当である。
　また、引用刊行物１おいては、オブジェクトコードとオブジェクトファイルとは同義である。
　
（こ）上記ｑ、ｒ、ｓから、配布装置３１６が、ライブラリ３０２からオブジェクトファイル３１９を検索して、それをユーザシステムに、ネットワークを介して配布する点が読み取れる。
　
　以上（き）乃至（こ）で指摘した事項から、引用刊行物１には、次の発明（以下、「引用発明」という）が記載されているもと認める。
　
　ネットワーク環境でオブジェクトファイルをユーザシステムに配布する過程を管理する開発／コード制御環境であって、
　ソースファイルとオブジェクトファイルを記憶するライブラリと、
　前記ライブラリ内で、ソースファイルを識別するチェック・アウト機能と、
　前記チェック・アウト機能によって識別されたソースファイルをコンパイルしオブジェクトファイルを生成するコンパイラ／リンカと、
　オブジェクトファイルをライブラリから検索して、ユーザシステムに配布する配布装置とを含む開発／コード制御環境
　
その３．対比
　ここで、本願発明と引用発明とを対比すると、
　引用発明においても、該「ソースファイル」を「コンパイラ／リンカ」でコンパイルすることで「オブジェクトファイル」を生成しているので、該「オブジェクトファイル」が「ソースファイル」を含むものであることは明らかであるから、引用発明における「ソースファイル」、「オブジェクトファイル」が、本願発明における「ソフトウェア・コンポーネント」、「パッケージソフトウェア」に相当し、
　引用発明における「ユーザシステム」も配布された「オブジェクトファイル」を実行することは明らかであるから、該「ユーザシステム」は、本願発明における「実行ユニット」に相当し、
　引用発明における「コンパイラ／リンカ」も、「ソースファイル」のコンパイルを行っていることは明らかであって、コンパイルの結果、生成されるのが実行コードであり、該実行コードはコンピュータで実行可能なことは自明の事項であるから、「コンパイラ／リンカ」によって生成される「オブジェクトファイル」が、「ユーザシステム」にて実行可能であることは明らかであり、
　引用発明においても「コンパイラ／リンカ」が作成した「オブジェクトファイル」を、「ライブラリ」に格納し、「配布装置」が、該「オブジェクトファイル」を「ライブラリ」から検索して「ユーザシステム」に配布し、結果として、「コンパイラ／リンカ」が作成した「オブジェクトファイル」を、「配布装置」が「ユーザシステム」に配布していると言えるので、
　引用発明における「ライブラリ」、「チェック・アウト機能」、「コンパイラ／リンカ」、「配布装置」が、それぞれ、本願発明における「中央リポジトリ」、「第１のサブシステム」、「第２のサブシステム」、「第３のサブシステム」に相当し、
　引用発明における「識別されたソースファイルをコンパイルしオブジェクトファイルを生成する」ことは、本願発明における「ソフトウェア・コンポーネントから実行ユニットにおいて実行可能なソフトウェアパッケージを作成する」ことに相当し、
　引用発明における「開発／コード制御環境」も、本願発明における「統合データ処理システム」も、共に、“ソフトウェアの生成、配布の過程、すなわち、プロセスを管理している”システムである点では共通しているので、
　以上の点から、本願発明と引用発明との一致点・相違点は以下のとおりである。
　
［一致点］
　ネットワーク環境でソフトウェア・コンポーネントを含むソフトウェアパッケージを実行ユニットへ配布するプロセスを管理するシステムであって、
　前記ソフトウェア・コンポーネントを記憶する中央リポジトリと、
　前記中央リポジトリ内で、ソフトウェア・コンポーネントを識別する第１のサブシステムと、
　前記第１のサブシステムによって識別された前記ソフトウェア・コンポーネントから、前記実行ユニットで実行可能なソフトウェアパッケージを作成する第２のサブシステムと、
　前記ソフトウェアパッケージを前記実行ユニットに配布する第３のサブシステムとを含むシステム
　
［相違点］
相違点Ａ．本願発明においては、「ソフトウェアパッケージ」は「複数」の「ソフトウェア・コンポーネント」を含むのに対して、
引用発明においては、「オブジェクトファイル」が複数の「ソースファイル」を含む点については言及されていない点。
　
相違点Ｂ．第１サブシステムにおいて、
　本願発明においては、「配布の対象となるソフトウェア・コンポーネントを識別する」のに対して、
　引用発明においては、「異なるバージョンを識別」している点
　
その４．当審の判断
　上記相違点について、以下に検討する。
　
・相違点Ａについて
　上記ｌで引用した周知刊行物３の記載にもあるように、作成されるソフトウェアが、複数のソースコードから構成されるようにすることは、当該技術分野にあっては周知の技術事項であるから、引用発明においても、生成されるオブジェクトファイルを、複数のソースファイルから構成することは、当業者が適宜なし得る事項である。
　よって、相違点Ａは格別なものではない。
　
・相違点Ｂについて
　配布先から要求されるソフトウェアの機能が既知である場合に、該ソフトウェアを作成するために必要となるソースファイルを選択することは自明の事項である。
　引用発明においても、必要となるソースファイルが既知であるならば、ライブラリから識別して読み出すことは、当業者が適宜なし得る事項である。
　よって、相違点Ｂは格別のものではない。
　
上記で検討したごとく、相違点Ａ及びＢはいずれも格別のものではなく、そして、本願発明の構成によってもたらされる効果も、当業者であれば容易に予測できる程度のものであって、格別なものとは認められない。
　
その５．むすび
　したがって、本願発明は、引用発明及び周知技術に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない 。
　
　よって、結論のとおり審決する。