【事件の表示】
　特願２００７−５３０３１９「エンタープライズ・データ統合システムのためのアーキテクチャ」拒絶査定不服審判事件〔平成１８年　３月　９日国際公開、ＷＯ２００６／０２６６７３、平成２０年　４月１７日国内公表、特表２００８−５１１９３４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００５年８月３１日（パリ条約による優先権主張外国庁受理２００４年８月３１日，米国）を国際出願日とする出願であって，平成２０年５月３０日付けで手続補正がなされ，平成２２年１１月２２日付けの拒絶理由通知に対して平成２３年２月１５日付けで手続補正がなされ，平成２３年９月１３日付けの最後の拒絶理由通知に対して平成２４年２月２９日付けで手続補正がなされたが，同年９月６日付けで補正却下の決定がなされるとともに同日付けで拒絶査定がなされ，これに対して平成２４年１２月２６日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ，さらに平成２５年５月２４日付けの審尋に対して同年７月２９日付けで回答書が提出されたものである。
　
第２　平成２４年１２月２６日付けの手続補正についての補正却下の決定 
　
　［補正却下の決定の結論］
  
　平成２４年１２月２６日付けの手続補正を却下する。 
　
［理由］
１．補正の内容 
（１）本件補正後の特許請求の範囲の記載
　本件補正により補正された特許請求の範囲の記載は次のとおりである。（下線は，補正の個所を示すものとして審判請求人が付したものである。） 
　
「　【請求項１】
　サービス指向アーキテクチャに基づくサービスを提供するためのシステムであって，
　ツールに構成された複数の個別の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス，を含むサービスを動的に配置しインスタンス化するためのサービス・ディレクトリと，
　
前記サービス・ディレクトリに動的に配置された前記サービス
を含み，
　前記システムに含まれるサーバが，
前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づけ前記インスタンス化されたサービス含むデータ統合ジョブを作成する，
　　【請求項２】
　前記サービスが，監査，ロギング，監視，管理及びアドミニストレーション，セキュリティ，ユーザ・プロファイル，セッション管理，並びに，報告，トランザクション，オーケストレーション，ユーザ・ディレクトリ，コンポーネント・サービス，構成，システム管理，ソース制御，ソース及びターゲット・メタデータのインポート／エクスポート，メタデータクエリ，アクセス，分析，報告，並びに，サブスクリプション，サンプル・データ，データ・プロファイリング，プロセス編集，プロセス・コンパイル，データ検証，設計デプロイ，設計実行，インストール及び更新，デモ・セットアップ，デプロイ，リリース管理，同期，データ・プロファイリング，データ・クレンジング，検査及び調整，テンプレートの適用，テスト，並びに，問題報告のうちの１つ又は複数を制御する複数の機能を含む，請求項１に記載のシステム。
　　【請求項３】
　データ統合システムに含まれるサーバが実行するサービスを提供する方法であって，前記サーバが，
　ツールに構成された複数の別個の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするための１つ又は複数のリポジトリ・サービスを含む複数のサービスを，サービス・ディレクトリに登録するステップと，
　前記複数のサービスのうちの１つをレジストリ内に動的に配置するステップと，
　前記複数のサービスのうちの配置された１つをインスタンス化するステップと，
　前記複数のサービスのうちの配置された１つを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースを提供するステップと，
を含み，
前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づけ，前記インスタンス化されたサービス含むデータ統合ジョブを作成する，
　　【請求項４】
　前記サーバが，
　データ統合システムをサービス指向アーキテクチャにおける複数のサービスとしてデプロイするステップと，
　各々が外部リソースに接続されるように構成され
，データ統合プロセスの設計の間，使用可能な
　前記コネクタ・コンポーネントの１つをサービスとして用いて，データ統合システム内から外部リソースへの接続を確立するステップと，
を含む，
請求項３に記載の
　　【請求項５】
　前記コネクタ・コンポーネントが，外部リソース・ファイルへの全てのアクセスを提供する，
請求項４
　　【請求項６】
　少なくとも１つの前記コネクタ・コンポーネントが翻訳プロセスを含む，
請求項４
　　【請求項７】
　前記コネクタ・コンポーネントが，ランタイムの間，使用可能となる，
請求項４
　　【請求項８】
　前記コネクタ・コンポーネントが，特定の外部リソースへのインターフェースを含む，
請求項４
　　【請求項９】
　前記外部リソースへの接続が，イベント・リスニング及びリソース・アクセスを含む，
請求項４
　　【請求項１０】
　前記外部リソースへの接続が永続的である，
請求項４
　　【請求項１１】
　前記外部リソースが，少なくとも１つのデータ・ソース又は少なくとも１つのデータ・ターゲットを含む，
請求項４
　　【請求項１２】
　前記コネクタ・コンポーネントが，外部リソースのためのメタデータ
または外部リソースのためのデータ
請求項１１
  
（２）本件補正前の特許請求の範囲の記載（平成２３年２月１５日付け手続補正）
　本件補正前の特許請求の範囲の記載は次のとおりである。 
「　【請求項１】
　サービス指向アーキテクチャに基づくサービスを提供するためのシステムであって，
　ツールに構成された複数の個別の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス，を含むサービスを動的に配置しインスタンス化するためのサービス・ディレクトリと，
　前記サービスを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースと，
を含み，
　前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスをインスタンス化し，前記インスタンス化されたサービスを前記ユーザ・インターフェースに提供する，システム。
　　【請求項２】
　前記サービスが内部サービスである，請求項１に記載のシステム。
　　【請求項３】
　前記サービスが外部サービスである，請求項１に記載のシステム。
　　【請求項４】
　前記サービスが異なる技術を使用する，請求項１に記載のシステム。
　　【請求項５】
　１つ又は複数の前記サービスが同期である，請求項１に記載のシステム。
　　【請求項６】
　１つ又は複数の前記サービスが非同期である，請求項１に記載のシステム。
　　【請求項７】
　前記サービスが，監査，ロギング，監視，管理及びアドミニストレーション，セキュリティ，ユーザ・プロファイル，セッション管理，並びに，報告，トランザクション，オーケストレーション，ユーザ・ディレクトリ，コンポーネント・サービス，構成，システム管理，ソース制御，ソース及びターゲット・メタデータのインポート／エクスポート，メタデータクエリ，アクセス，分析，報告，並びに，サブスクリプション，サンプル・データ，データ・プロファイリング，プロセス編集，プロセス・コンパイル，データ検証，設計デプロイ，設計実行，インストール及び更新，デモ・セットアップ，デプロイ，リリース管理，同期，データ・プロファイリング，データ・クレンジング，検査及び調整，テンプレートの適用，テスト，並びに，問題報告のうちの１つ又は複数を制御する複数の機能を含む，請求項１に記載のシステム。
　　【請求項８】
　データ統合システムに含まれるサーバが実行するサービスを提供する方法であって，前記サーバが，
　ツールに構成された複数の別個の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするための１つ又は複数のリポジトリ・サービスを含む複数のサービスを，サービス・ディレクトリに登録するステップと，
　前記複数のサービスのうちの１つをレジストリ内に動的に配置するステップと，
　前記複数のサービスのうちの配置された１つをインスタンス化するステップと，
　前記複数のサービスのうちの配置された１つを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースを提供するステップと，
を含む方法。
　　【請求項９】
　データ統合システムに含まれるサーバが実行する方法であって，前記サーバが，
　データ統合システムをサービス指向アーキテクチャにおける複数のサービスとしてデプロイするステップと，
　各々が外部リソースに接続されるように構成された１つ又は複数のコネクタ・コンポーネントを，データ統合システムのサービス・ディレクトリ内のサービスとして登録するステップと，
　前記コネクタ・コンポーネントの１つをサービスとして用いて，データ統合システム内から外部リソースへの接続を確立するステップと，
を含む方法。
　　【請求項１０】
　前記コネクタ・コンポーネントが，外部リソース・ファイルへの全てのアクセスを提供する，請求項９に記載の方法。
　　【請求項１１】
　少なくとも１つの前記コネクタ・コンポーネントが翻訳プロセスを含む，請求項９に記載の方法。
　　【請求項１２】
　前記コネクタ・コンポーネントが，データ統合プロセスの設計の間，使用可能となる，請求項９に記載の方法。
　　【請求項１３】
　前記コネクタ・コンポーネントが，ランタイムの間，使用可能となる，請求項９に記載の方法。
　　【請求項１４】
　前記コネクタ・コンポーネントが，特定の外部リソースへのインターフェースを含む，請求項９に記載の方法。
　　【請求項１５】
　前記外部リソースへの接続が，イベント・リスニング及びリソース・アクセスを含む，請求項９に記載の方法。
　　【請求項１６】
　前記外部リソースへの接続が永続的である，請求項９に記載の方法。
　　【請求項１７】
　前記外部リソースが，少なくとも１つのデータ・ソース又は少なくとも１つのデータ・ターゲットを含む，請求項９に記載の方法。
　　【請求項１８】
　前記コネクタ・コンポーネントが，外部リソースのためのメタデータへのアクセスを提供する，請求項１７に記載の方法。
　　【請求項１９】
　前記コネクタ・コンポーネントが，外部リソースのためのデータへのアクセスを提供する，請求項１７に記載の方法。
　　【請求項２０】
　関連するコンピュータ・プログラム製品スイートの複数の機能が，各々サービスとして登録されるサービス・ディレクトリと，
　関連するコンピュータ・プログラム製品スイートをデプロイするために，前記サービスのうちの１つ又は複数のインスタンスを呼び出すインターフェースと，
を含む，システム。
　　【請求項２１】
　前記関連する製品スイートがデータ統合スイートを含む，請求項２０に記載のシステム。
　　【請求項２２】
　前記機能が，監査，ロギング，監視，管理及びアドミニストレーション，セキュリティ，ユーザ・プロファイル，セッション管理，並びに，報告，トランザクション，オーケストレーション，ユーザ・ディレクトリ，コンポーネント・サービス，構成，システム管理，ソース制御，ソース及びターゲット・メタデータのインポート／エクスポート，メタデータクエリ，アクセス，分析，報告，並びに，サブスクリプション，サンプル・データ，データ・プロファイリング，プロセス編集，プロセス・コンパイル，データ検証，設計デプロイ，設計実行，インストール及び更新，デモ・セットアップ，デプロイ，リリース管理，同期，データ・プロファイリング，データ・クレンジング，検査及び調整，テンプレートの適用，テスト，並びに，問題報告のうちの１つ又は複数を含む，請求項２１に記載のシステム。
　　【請求項２３】
　１つ又はそれ以上のパラメータが，１つ又はそれ以上の前記サービスの１つ又はそれ以上のインスタンスに渡される，請求項２０に記載のシステム。
　　【請求項２４】
　１つ又はそれ以上の前記サービスが，前記関連するコンピュータ・プログラムの全てに共通の少なくとも１つの共通サービスを含む，請求項２０に記載のシステム。」 
　
（３）本件補正は，補正前の請求項１を一部補正して補正後の請求項１とし，補正前の請求項２〜６を削除し，補正前の請求項７を補正後の請求項２とし，補正前の請求項８を一部補正して補正後の請求項３とし，補正前の請求項９を一部補正し補正後の請求項３に従属させて補正後の請求項４とし，補正前の請求項１０，１１を補正後の請求項５，６とし，補正前の請求項１２を削除し，補正前の請求項１３〜１７を補正後の請求項７〜１１とし，補正前の請求項１８，１９をまとめて補正後の請求項１２とし，補正前の請求項２０〜２４を削除するものである。
　
２．補正の適否について
（１）補正前の請求項１を一部補正して補正後の請求項１とする補正（以下，「請求項１に係る補正」という。）について検討する。
　請求項１に係る補正は，補正前の「前記サービス」を補正後の「前記サービス・ディレクトリに動的に配置された前記サービス」とする補正事項（以下，「補正事項１」という。）と，補正前の「前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスをインスタンス化し，前記インスタンス化されたサービスを前記ユーザ・インターフェースに提供する」を補正後の「前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づけ前記インスタンス化されたサービス含むデータ統合ジョブを作成する」とする補正事項（以下，「補正事項２」という。）を含むものである。
　
（補正事項１について）
　補正後の請求項１の「前記サービス・ディレクトリに動的に配置された前記サービス」は，補正前の請求項１の「サービス」を「前記サービス・ディレクトリに動的に配置された」ものに限定するものであるから，補正事項１は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法（以下，「改正前特許法」という。）第１７条の２第４項第２号に規定される「特許請求の範囲の減縮」を目的とするものである。
　
（補正事項２について）
　補正後の請求項１の「前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づけ前記インスタンス化されたサービス含むデータ統合ジョブを作成する」ことは，補正前の請求項１における「前記システムに含まれるサーバ」の処理内容を明確にするものであるから，補正事項２は，改正前特許法第１７条の２第４項第２号に規定される「明りょうでない記載の釈明」を目的とするものである。
　
　したがって，請求項１に係る補正は，改正前特許法第１７条の２第４項第２号に規定される「特許請求の範囲の減縮」及び同項第４号に規定される「明りょうでない記載の釈明」を目的とする補正に該当する。
　
（２）補正前の請求項９を一部補正し補正後の請求項３に従属させて補正後の請求項４とする補正（以下，「補正事項３」という。）について検討する。
　補正後の請求項４は，補正後の請求項３を引用しているので，次の（ア）〜（キ）のステップを含む方法の発明である。
（ア）ツールに構成された複数の別個の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするための１つ又は複数のリポジトリ・サービスを含む複数のサービスを，サービス・ディレクトリに登録するステップ
（イ）前記複数のサービスのうちの１つをレジストリ内に動的に配置するステップ
（ウ）前記複数のサービスのうちの配置された１つをインスタンス化するステップ
（エ）前記複数のサービスのうちの配置された１つを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースを提供するステップ
（オ）データ統合システムをサービス指向アーキテクチャにおける複数のサービスとしてデプロイするステップ
（カ）各々が外部リソースに接続されるように構成され，データ統合プロセスの設計の間，使用可能な１つ又は複数のコネクタ・コンポーネントを，データ統合システムのサービス・ディレクトリ内のサービスとして登録するステップ
（キ）前記コネクタ・コンポーネントの１つをサービスとして用いて，データ統合システム内から外部リソースへの接続を確立するステップ
　
　このうち，（ア）〜（エ）のステップは，補正前の請求項８に記載されたステップであるところ，補正前の請求項９は補正前の請求項８を引用していないから，補正前の請求項９を補正後の請求項４とする補正は，補正前の請求項９に上記（ア）〜（エ）のステップを新たに追加する補正である。そして，この（ア）〜（エ）のステップは，補正前の請求項９に記載されたいずれの発明特定事項の下位概念とも認められないから，補正前の請求項９に上記（ア）〜（エ）のステップを追加して補正後の請求項４とする補正（補正事項３）は，特許請求の範囲の限定的減縮を目的としたものとはいえない。
　また，補正後の請求項４を，補正前の請求項８に上記（オ）〜（キ）のステップを追加したものとみた場合でも，上記（オ）〜（キ）のステップは，補正前の請求項８に記載されたいずれの発明特定事項の下位概念とも認められないから，補正前の請求項８に上記（オ）〜（キ）のステップを追加して補正後の請求項４とする補正も，特許請求の範囲の限定的減縮を目的としたものとはいえない。
　したがって，補正事項３は改正前特許法第１７条の２第４項第２号に規定される「特許請求の範囲の減縮」を目的とするものとは認められない。
　また，上記補正事項３は，改正前特許法第１７条の２第４項第１号に規定される「請求項の削除」，同項第３号に規定される「誤記の訂正」，及び同項第４号に規定される「明りょうでない記載の釈明」のいずれを目的とするものとも認められない。
　以上のことから，補正事項３を含む本件補正は，改正前特許法第１７条の２第４項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．独立特許要件について
　上記「２．（２）」に記載したとおり，本件補正は不適法なものであり，却下すべきものであるが，仮に本件補正が適法なものであるとして，以下さらに検討する。
　
　上記「２．（１）」に記載したとおり，請求項１に係る補正は，改正前特許法第１７条の２第４項第２号に規定される「特許請求の範囲の減縮」及び同項第４号に規定される「明りょうでない記載の釈明」を目的とする補正に該当する。
　
　そこで，本件補正後の請求項１に係る発明（以下，「本件補正発明」という。）が，特許出願の際独立して特許を受けることができるものであるか（改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
３−１．本件補正発明を再掲すると以下のとおりである。
　
「　【請求項１】
　サービス指向アーキテクチャに基づくサービスを提供するためのシステムであって，
　ツールに構成された複数の個別の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス，を含むサービスを動的に配置しインスタンス化するためのサービス・ディレクトリと，
　前記サービス・ディレクトリに動的に配置された前記サービスを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースと，
を含み，
　前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づけ前記インスタンス化されたサービス含むデータ統合ジョブを作成する，システム。」
　
３−２．引用例 
　
（１）引用例
　原査定の拒絶の理由に引用された国際公開第２００３／０３４２８５号（以下，「引用例」という。）には，図面とともに，次の（ア）〜（ケ）の事項が記載されている。
　
（ア）「BRIEF SUMMARY 
　
Systems and methods in accordance with the present invention can provide for application integration by taking advantage of an application view, application view component, and/or application view object
（当審仮訳：概要
　
本発明によるシステム及び方法は，アプリケーションビュー，アプリケーションビューコンポーネント，及び／又は，アプリケーションビューオブジェクトを利用することによって，アプリケーション統合を提供することができる
　
（イ）「DETAILED DESCRIPTION
　
Application integration components can be used to integrate a variety of applications and systems, such as Enterprise Information Systems (EISs)
（当審仮訳：詳細な説明
　
アプリケーション統合コンポーネントは，「企業情報システム（ＥＩＳ）」のような様々なアプリケーション及びシステムを統合するのに使用することができる
　
（ウ）「Integration Architecture
　
Application integration can build on this standardized approach in an application integration framework by providing a standards-based architecture for hosting J2EE Connector architecture-based adapters. Developers can build J2EE Connector architecture-compliant adapters and deploy these adapters, in the integration framework, to connect enterprise applications to an application server
　
These adapters can be used to define business-focused interfaces to an EIS, the interfaces referred to herein as 
application views
 of the respective adapters
Application views can make use of an adapter for an EIS, making it possible to expose existing information systems as business services
（当審仮訳：統合方式
　
アプリケーション統合は，「Ｊ２ＥＥコネクター」方式ベースのアダプタのホストとなる基準ベースの方式を提供することにより，アプリケーション統合フレームワーク内のこの基準化された手法の上に構築することができる。開発者は，「Ｊ２ＥＥコネクター」方式準拠アダプタを構築し，これらのアダプタを統合フレームワーク内にデプロイ（配置）して企業アプリケーションをアプリケーションサーバに接続することができる
　
これらのアダプタを用いて，本明細書でそれぞれのアダプタの「アプリケーションビュー」と呼ぶビジネス集中化インタフェースを「ＥＩＳ」に対して形成することができる
アプリケーションビューは，「ＥＩＳ」のためのアダプタを利用することができ，既存の情報システムをビジネスサービスとして公開することを可能にする
　
（エ）「
An application view is an object, which can be implemented in one embodiment as a stateless session JavaBean
　
A web services interface can also be used with an application view. A protocol such as SOAP can be used to invoke a web service. Another protocol that may be used includes UDDI, a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. A WSDL protocol can also be used, which is an XML format for describing network services . A web services layer can be provided on top of the application view so that any application view can be invoked as a web service
（当審仮訳：
アプリケーションビューは，一実施形態においては，ステートレスセッション「ＪａｖａＢｅａｎ」として実行されるオブジェクトである
　
ウェブサービスインタフェースはまた，アプリケーションビューと共に使用することができる。ウェブサービスを呼び出すために，「ＳＯＡＰ」のようなプロトコルを使用することができる。使用することができる別のプロトコルは，プラットフォームに依存せず，サービスを記述するためのオープンフレームワークであり，ビジネスを見つけ出し，「インターネット」を利用してビジネスサービスを統合する「ＵＤＤＩ」を含む。ネットワークサービスを記述するための「ＸＭＬ」フォーマットである「ＷＳＤＬ」プロトコルも使用することができる。ウェブサービスとして任意のアプリケーションビューを呼び出すことができるように，アプリケーションビューの上にウェブサービス層を設けることができる
　
（オ）「
An integration framework can be based on an existing standard infrastructure, such as an application server that supports J2EE, JMS, and the J2EE Connector architecture. Using such a standard infrastructure also provides for high availability and scalability, such as by clustering and resource pooling
　
An integration framework can also utilize a business-process engine to allow non-programmers to graphically construct and maintain business processes. An integration framework can implement a common model on top of the J2EE Connector architecture that is focused on business-level concepts. This model, which can consist of XML-encoded events and services, allows the management of a consistent integration environment, regardless of the interface required between adapters and their target applications
（当審仮訳：
統合フレームワークは，「Ｊ２ＥＥ」，「ＪＭＳ」，及び「Ｊ２ＥＥコネクター」方式をサポートするアプリケーションサーバのような既存の標準的インフラストラクチャーに基づくことができる。そのような標準的インフラストラクチャーの使用はまた，クラスタリング及びリソースプーリングによるなどして高い利用可能性と拡張性を提供する
　
統合フレームワークはまた，ビジネスプロセスエンジンを利用して，プログラマーでない人がビジネスプロセスをグラフィカルに構築して維持することを可能にすることができる。統合フレームワークは，ビジネスレベルの概念に着目した「Ｊ２ＥＥコネクター」方式の上に共通のモデルを実施することができる。このモデルは，「ＸＭＬ」で符号化されたイベント及びサービスから成り，アダプタとその目標とするアプリケーションとの間に要求されるインタフェースに関係なく，整合性のある統合環境の管理を可能にする
　
（カ）「
Business Process Management (BPM)
One way to use an application view in an enterprise's business processes is to design a workflow in BPM. BPM can provide a GUI-based environment for designing business process workflows
（途中省略）
　
After creating the necessary application view services and events for an enterprise, a user can use those application views to execute business processes. BPM can be used to design business process workflows that use the application view services and events. BPM can provide a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration
（当審仮訳：
ビジネスプロセス管理（ＢＰＭ）
企業のビジネスプロセス内のアプリケーションビューを使用する１つの方法は，「ＢＰＭ」内でワークフローを設計することである。「ＢＰＭ」は，ビジネスプロセスワークフローを設計するための「ＧＵＩ」ベースの環境を提供することができる
（途中省略）
　
企業に必要なアプリケーションビューサービス及びイベントを作成した後で，ユーザは，ビジネスプロセスを実行するためにそれらのアプリケーションビューを使用することができる。「ＢＰＭ」は，アプリケーションビューサービス及びイベントを使用するビジネスプロセスワークフローを設計するために使用することができる。「ＢＰＭ」は，ビジネスプロセスワークフローを設計するために「ＧＵＩ」ベースの環境を提供することができる。これらのワークフローは，アプリケーション統合を使用して形成されたアプリケーションビューサービス及びイベントを含むことができる
　
（キ）「
An application view can be available for use by runtime clients. The application view can have a container with allocated resources for the application view that can service requests for the application view. Runtime clients can obtain instances of this application view from the application view container, and invoke its services and listen for its events
（当審仮訳：
アプリケーションビューは，実行時クライアントの使用に対して利用可能にすることができる。アプリケーションビューは，アプリケーションビューに対する要求にサービスを提供することができるアプリケーションビュー用に割り当てられたリソースを備えたコンテナーを有することができる。実行時クライアントは，アプリケーションビュー（の）コンテナーからこのアプリケーションビューのインスタンスを取得し，そのサービスを呼び出してそのイベントを聴取することができる
　
（ク）「
After defining an application view, it can be deployed on an application server. Deployed application views can be used to implement an enterprise's business processes in a business process workflow
（当審仮訳：
アプリケーションビューを形成した後で，それは，アプリケーションサーバ上にデプロイすることができる。デプロイされたアプリケーションビューは，ビジネスプロセスワークフロー内で企業のビジネスプロセスを実施するために使用することができる。
　
（ケ）「System Example
　The simple example of Figure 6 shows the interrelation of some of the features described above. This figure shows an example situation that could arise which would involve adding customers to an SAP instance 616 that were created originally created in a Siebel system or instance 600. In this example, a new customer 602 is created in Siebel 600. Through SiebelCode, the Siebel-specific event adapter 604 is notified and is passed the customer information. The event adapter creates an XML-based object containing the customer information and notifies the Siebel application view 608 of the event. The Siebel application view 608 then passes the event to the business process 612. The business process 612 can determine that the customer information needs to be replicated to an SAP system 616. The business process 612 transforms the Siebel XML representation of a customer to an SAP XML representation. The business process then invokes a service provided by the SAP application view 610, which can be part ofthe same integration framework 606 as the Siebel application view 608. The SAP application view 610, in turn, calls the SAP service adapter 614 and passes the XML message, which is now in a format that the SAP adapter 614 can understand. The SAP adapter 614 can convert the XML message to a specific BAPI (business application programming interface) and can call the SAP instance 616. SAP 616 can process the request, insert the customer 618, and return the customer number assigned by SAP 616.」（第３４頁第２４行〜第３５頁第１８行）
（当審仮訳：システム例
　図６の簡単な例は，上述のいくつかの特徴の相互関係を示す。この図は，本来「Ｓｉｅｂｅｌ」システム又はインスタンス６００で本来作成された顧客を「ＳＡＰ」インスタンス６１６に追加する段階を含むと考えられる起こり得る例示的状況を示す。この例においては，新しい顧客６０２が，「Ｓｉｅｂｅｌ」６００で作成される。「ＳｉｅｂｅｌＣｏｄｅ」を通して「Ｓｉｅｂｅｌ」特有イベントアダプタ６０４に通知され，顧客情報が通される。イベントアダプタは，顧客情報を含む「ＸＭＬ」ベースのオブジェクトを作成し，イベントを「Ｓｉｅｂｅｌ」アプリケーションビュー６０８に通知する。「Ｓｉｅｂｅｌ」アプリケーションビュー６０８は，次に，イベントをビジネスプロセス６１２に通す。ビジネスプロセス６１２は，顧客情報を「ＳＡＰ」システム６１６に複製する必要があると判断することができる。ビジネスプロセス６１２は，顧客の「Ｓｉｅｂｅｌ」の「ＸＭＬ」表示を「ＳＡＰ」の「ＸＭＬ」表示に変換する。ビジネスプロセスは，次に，「Ｓｉｅｂｅｌ」アプリケーションビュー６０８と同じ統合フレームワーク６０６の一部とすることができる「ＳＡＰ」アプリケーションビュー６１０によって提供されるサービスを呼び出す。「ＳＡＰ」アプリケーションビュー６１０は，次に，「ＳＡＰ」サービスアダプタ６１４を呼び出し，今や「ＳＡＰ」アダプタ６１４が理解することができるフォーマットの「ＸＭＬ」メッセージを通す。「ＳＡＰ」アダプタ６１４は，「ＸＭＬ」メッセージを特定の「ＢＡＰＩ」（ビジネスアプリケーションプログラミングインタフェース）に変換することができ，「ＳＡＰ」インタフェース６１６を呼び出すことができる。「ＳＡＰ」６１６は，要求を処理し，顧客６１８を挿入し，「ＳＡＰ」６１６によって割り当てられた顧客番号を返すことができる。）
　
　上記摘記事項（ア）〜（ケ）の記載及び図面の記載を総合すると，引用例には，次のとおりの発明（以下，「引用例発明」という。）が記載されていると認められる。
　
「アプリケーションビュー，アプリケーションビューコンポーネント，及び／又は，アプリケーションビューオブジェクトを利用することによって，アプリケーション統合を提供することができるシステムであって，
　アプリケーション統合コンポーネントは，企業情報システム（ＥＩＳ）のような様々なアプリケーション及びシステムを統合するのに使用することができ，
　アプリケーション統合は，Ｊ２ＥＥコネクター方式ベースのアダプタのホストとなる基準ベースの方式を提供することにより，アプリケーション統合フレームワーク内のこの基準化された手法の上に構築することができ，開発者は，Ｊ２ＥＥコネクター方式準拠アダプタを構築し，これらのアダプタを統合フレームワーク内にデプロイ（配置）して企業アプリケーションをアプリケーションサーバに接続することができ，
　これらのアダプタを用いて，それぞれのアダプタのアプリケーションビューと呼ぶビジネス集中化インタフェースをＥＩＳに対して形成することができ，
　アプリケーションビューは，ＥＩＳのためのアダプタを利用して，既存の情報システムをビジネスサービスとして公開することを可能にし，
　アプリケーションビューは，ステートレスセッションＪａｖａＢｅａｎとして実行されるオブジェクトであり，
　ウェブサービスインタフェースは，アプリケーションビューと共に使用することができ，ウェブサービスを呼び出すために，ＳＯＡＰのようなプロトコルを使用することができ，使用することができる別のプロトコルは，ビジネスを見つけ出し，インターネットを利用してビジネスサービスを統合するＵＤＤＩを含み，ネットワークサービスを記述するためのＸＭＬフォーマットであるＷＳＤＬプロトコルも使用することができ，ウェブサービスとして任意のアプリケーションビューを呼び出すことができるように，アプリケーションビューの上にウェブサービス層を設けることができ，
　統合フレームワークは，Ｊ２ＥＥ，ＪＭＳ，及びＪ２ＥＥコネクター方式をサポートするアプリケーションサーバのような既存の標準的インフラストラクチャーに基づくことができ，そのような標準的インフラストラクチャーの使用はまた，クラスタリング及びリソースプーリングによるなどして高い利用可能性と拡張性を提供するものであり，
　統合フレームワークはまた，ビジネスプロセスエンジンを利用して，プログラマーでない人がビジネスプロセスをグラフィカルに構築して維持することを可能にすることができ，統合フレームワークは，ビジネスレベルの概念に着目したＪ２ＥＥコネクター方式の上に共通のモデルを実施することができ，このモデルは，ＸＭＬで符号化されたイベント及びサービスから成り，アダプタとその目標とするアプリケーションとの間に要求されるインタフェースに関係なく，整合性のある統合環境の管理を可能にし，
　企業に必要なアプリケーションビューサービス及びイベントを作成した後で，ユーザは，ビジネスプロセスを実行するためにそれらのアプリケーションビューを使用することができ，ビジネスプロセス管理（ＢＰＭ）は，アプリケーションビューサービス及びイベントを使用するビジネスプロセスワークフローを設計するために使用することができ，ＢＰＭは，ビジネスプロセスワークフローを設計するためにＧＵＩベースの環境を提供することができ，これらのワークフローは，アプリケーション統合を使用して形成されたアプリケーションビューサービス及びイベントを含むことができ，
　アプリケーションビューは，実行時クライアントの使用に対して利用可能にすることができ，アプリケーションビューは，アプリケーションビューに対する要求にサービスを提供することができるアプリケーションビュー用に割り当てられたリソースを備えたコンテナーを有することができ，実行時クライアントは，アプリケーションビュー（の）コンテナーからこのアプリケーションビューのインスタンスを取得し，そのサービスを呼び出してそのイベントを聴取することができ，
　アプリケーションビューを形成した後で，それは，アプリケーションサーバ上にデプロイすることができ，デプロイされたアプリケーションビューは，ビジネスプロセスワークフロー内で企業のビジネスプロセスを実施するために使用することができる，
システム。」
　
３−３．対比
　本件補正発明と引用例発明とを対比する。
　
（ａ）引用例発明において，アプリケーションビューは，ＥＩＳのためのアダプタを利用して，既存の情報システムをビジネスサービスとして公開することを可能にするものであり，ユーザは，ビジネスプロセス管理（ＢＰＭ）が提供するＧＵＩベースの環境で，アプリケーションビューを使用してビジネスプロセスワークフローを設計することができるものであるから，引用例発明の「システム」は，ユーザに「ビジネスサービス」を「提供」するものである。
　ここで，引用例発明のこの「ビジネスサービス」が本件補正発明の「サービス」に相当するから，引用例発明の「システム」と本件補正発明の「システム」とは，後記する点で相違するものの，「サービスを提供するためのシステム」である点で共通している。
　
（ｂ）引用例発明のＥＩＳ（企業情報システム）は，「様々なアプリケーション及びシステム」であるから本件補正発明の「リソース」に相当し，また，引用例発明のＥＩＳは，「アプリケーション統合を提供することができるシステム」の「外部」に設けられているから，引用例発明の「ＥＩＳ（企業情報システム）」が本件補正発明の「外部リソース」に相当する。
　引用例発明において，開発者は，Ｊ２ＥＥコネクター方式準拠アダプタを構築し，これらのアダプタを統合フレームワーク内にデプロイ（配置）して企業アプリケーションをアプリケーションサーバに接続しており，引用例発明の「アダプタ」は，企業アプリケーション（外部リソース）をアプリケーションサーバに接続するための「コネクタ」であるということができるから，引用例発明の「アダプタ」が本件補正発明の「外部リソース・コネクタ」に相当する。
　そして，引用例発明の「アプリケーションビュー」は，ＥＩＳのための「アダプタ（外部リソース・コネクタ）」を利用して，既存の情報システムのサービスを「ビジネスサービス（サービス）」として「公開」することを可能にするものであるから，「アダプタ（外部リソース・コネクタ）」を「ビジネスサービス（サービス）」として「公開」する「コンポーネント・サービス」であるということができる。
　してみれば，引用例発明の「アプリケーションビュー」が本件補正発明の「外部リソース・コネクタをサービスとして公開するコンポーネント・サービス」に相当する。
　
（ｃ）引用例発明において，アプリケーションビューは，実行時クライアントの使用に対して利用可能にすることができ，アプリケーションビューは，アプリケーションビューに対する要求にサービスを提供することができるアプリケーションビュー用に割り当てられたリソースを備えたコンテナーを有することができ，実行時クライアントは，アプリケーションビュー（の）コンテナーからこのアプリケーションビューのインスタンスを取得し，そのサービスを呼び出してそのイベントを聴取することができるものであるから，引用例発明の「アプリケーションビュー（の）コンテナー」は，「アプリケーションビュー」という「サービス」を「インスタンス化」するための「サービスインスタンス化手段」であるということができる。
　してみれば，引用例発明の「アプリケーションビュー（の）コンテナー」と本件補正発明の「サービスを動的に配置しインスタンス化するためのサービス・ディレクトリ」とは，後記する点で相違するものの，「サービスをインスタンス化するためのサービスインスタンス化手段」である点で共通している。
　
（ｄ）引用例発明において，ユーザは，ビジネスプロセスを実行するためにアプリケーションビューを使用することができ，ビジネスプロセス管理（ＢＰＭ）は，アプリケーションビューサービス及びイベントを使用するビジネスプロセスワークフローを設計するために使用することができ，ＢＰＭは，ビジネスプロセスワークフローを設計するためにＧＵＩベースの環境を提供することができ，これらのワークフローは，アプリケーション統合を使用して形成されたアプリケーションビューサービス及びイベントを含むことができるものである。
　つまり，引用例発明は，「アプリケーションビューを使用してビジネスプロセスワークフローをユーザが設計するためのＧＵＩ」を含むものであるということができる。
　そして，引用例発明の「アプリケーションビュー」「使用して」「ビジネスプロセスワークフロー」「ＧＵＩ」が本件補正発明の「サービス」「用いて」「データ統合プロセス」「ユーザ・インターフェース」に相当する。
　してみれば，引用例発明の「システム」と本件補正発明の「システム」とは，後記する点で相違するものの，「サービスを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェース」を含む点で共通している。
　
（ｅ）引用例発明では，アプリケーションビューを形成した後で，それは，アプリケーションサーバ上にデプロイすることができ，デプロイされたアプリケーションビューは，ビジネスプロセスワークフロー内で企業のビジネスプロセスを実施するために使用することができるものである。
　ここで，引用例発明の「アプリケーションサーバ」が本件補正発明の「システムに含まれるサーバ」に相当し，ビジネスプロセスワークフローにおいて使用される「アプリケーションビュー（サービス）」は，ビジネスプロセスワークフローの設計時に「ＧＵＩ（ユーザ・インターフェース）」を「介して」「指定」されたものであることは明らかであるから，本件補正発明の「ユーザ・インターフェースを介して指定されたサービス」に相当する。
　そして，引用例発明において，「設計」されたビジネスプロセスワークフロー内で企業のビジネスプロセスを実施するために，「アプリケーションビュー（ユーザ・インターフェースを介して指定されたサービス）」を，「ビジネスプロセスワークフロー（データ統合プロセス）」の「インスタンス」として「関連づける」ことは自明のことである。
　してみれば，引用例発明と本件補正発明とは，後記する点で相違するものの，「システムに含まれるサーバが，ユーザ・インターフェースを介して指定されたサービスをデータ統合プロセスのインスタンスとして関連づける」点で共通している。
　
　そうすると，本件補正発明と引用例発明とは，
　
「サービスを提供するためのシステムであって，
　外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，を含むサービスをインスタンス化するためのサービスインスタンス化手段と，
　前記サービスを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースと，
を含み，
　前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスを前記データ統合プロセスのインスタンスとして関連づける，システム。」
　
の点で一致し，次の点で相違する。
　
［相違点１］
　本件補正発明のシステムは，「サービス指向アーキテクチャに基づく」サービスを提供するためのシステムであるのに対して，引用例発明のシステムは，サービスを提供するためのシステムではあるものの，提供するサービスが，「サービス指向アーキテクチャに基づく」ものであるか否かは不明である点。
　
［相違点２］
　本件補正発明では，サービスが，「ツールに構成された複数の個別の再使用可能かつ共有可能なサービス」を含むのに対して，引用例発明では，そのようなサービスを含むことは特定されていない点。
　
［相違点３］
　本件補正発明では，サービスが，「リポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス」を含むのに対して，引用例発明では，そのようなサービスを含むことは特定されていない点。
　
［相違点４］
　本件補正発明では，「サービスを動的に配置しインスタンス化するためのサービス・ディレクトリ」を含むのに対して，引用例発明は，「サービスをインスタンス化するためのサービスインスタンス化手段」を含むものの，インスタンス化されるサービスが，サービス・ディレクトリに「動的に配置」されることは特定されていない点。
　
［相違点５］
　ユーザがデータ統合プロセスを設計する際に，本件補正発明では，「サービス・ディレクトリに動的に配置された」サービスを用いているのに対して，引用例発明では，そのようになっていない点。
　
［相違点６］
　本件補正発明では，「インスタンス化されたサービス（を）含むデータ統合ジョブを作成する」のに対して，引用例発明は，そのようになっていない点。
　
３−４．当審の判断
　上記相違点について検討する。
　
［相違点１］について
　「ＵＤＤＩを使用してＷｅｂサービスを利用可能とするサービス指向アーキテクチャ」は周知である。
　例えば，「小池隆，Ｗｅｂサービス入門−注目度ナンバーワン！実例で学ぶ「Ｗｅｂサービス」−，ＯＰＥＮ　ＤＥＳＩＧＮ，ＣＱ出版株式会社，２００２年４月１日，第９巻，第４号，ｐ１２２〜１３９」の第１２７頁左欄第１５行〜右欄第２行に，「サービス指向アーキテクチャ　Ｗｅｂサービスを利用したｅ−ｂｕｓｉｎｅｓｓの世界は，サービス指向アーキテクチャ（ＳＯＡ ： Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）として表されることがあります（図５）．　ＳＯＡは，サービスプロバイダ，サービスブローカ，サービスリクエスタの３者によって構成されます．　サービスプロバイダは，サービスを提供し，利用者を求めています．サービスブローカはサービスプロバイダについての情報を提供します．そしてサービスリクエスタは，サービスブローカを利用してサービスプロバイダが提供するサービスを検索して，利用します．　ＵＤＤＩはこれら３者間のインターフェースを整理し，ＵＤＤＩレジストリはサービスブローカの役割を果たします．」と記載されている。
　してみると，「ＵＤＤＩを使用してウェブサービスを利用可能とするもの」である引用例発明のシステムに，上記周知の技術を採用して，「サービス指向アーキテクチャに基づく」サービスを提供するためのシステムとすることは当業者が容易に想到し得たことである。
　
［相違点２］について
　本件補正発明における「ツールに構成された複数の個別の再使用可能かつ共有可能なサービス」に関連して，本願の発明の詳細な説明の【０２０４】及び【０２０６】段落には，次のように記載されている。
「ＳＯＡ５２０１は，例えば，共通コア・サービス５２１０，製品機能サービス５２１２及びメタデータ・サービス５２２２の使用によってＧＵＩ５２０２をデータ統合設計及びデプロイの全てのアスペクトに公開することができ，インテリジェント・オートメーション層５２０３を介して動作することができる。（途中省略）ＳＯＡ５２０１は，共通コア・サービス５２１０及び製品機能サービス５２１２へのアクセスを提供し，並びに，データ統合設計内の機能及びサービスにＡＰＩ５２０８へのバックエンド・サポートを提供することができる。サービスは，複数のクライアント５２０４及び他のサービスによって共有し，再使用することができる。」（【０２０４】段落）
「共通コア・サービス５２１０は，１つ又は複数の共通レジストリのためのディレクトリ・サービス，ロギング及び監査サービス，監視，イベント管理，トランザクション・サービス，セキュリティ，ライセンス交付（ライセンス交付ポリシィの作成及び強化，並びに，外部リスニング・サービスとの通信等）及びプロビジョニング等の，データ統合ソリューションの設計及びデプロイの全てのアスペクトにわたって通常使用できる共通機能サービス，並びに，ＳＯＡの管理サービスを提供することができる。」（【０２０６】段落）
　これらの記載からみて，本件補正発明の「ツールに構成された複数の個別の再使用可能かつ共有可能なサービス」は，少なくともトランザクション・サービスやセキュリティ等の共通コア・サービス５２１０を含むものと認められる。
　
　引用例発明の統合フレームワークは，Ｊ２ＥＥなどの標準的インフラストラクチャーに基づくものである。
　そして，トランザクション・サービスやセキュリティ等のサービスをＪ２ＥＥなどの標準的インフラストラクチャーの「コンテナ」で提供することは周知技術である。
　例えば，「ジョン・ウデル　外１名，エンタープライズＪａｖａ最新事情−ＥＡＩに最適なＷｅｂサービスの実現に向けた　ＪａｖａのＸＭＬ対応強化策−，ＳｕｎＷｏｒｌｄ，（株）ＩＤＧジャパン，２００２年９月１日，第１２巻，第９号，ｐ７１〜７７」の第７２頁右欄第９〜１９行には，「本格化するＪａｖａのＸＭＬ対応　Ｊ２ＥＥプラットフォームが，エンタープライズ市場で強固な支持を獲得したのは，同プラットフォームがエンタープライズ市楊に適した多様な統合コンポーネントと強力なインフラを備えていたからである。例えば，Ｊ２ＥＥ１．３のアーキテクチャの要であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ）コンテナは，セキュリティや持続性，セッション管理やトランザクションの整合性などの重要な機能をサポートするとともに，アプリケーションの展開と管理を簡素化することで，サーバ・サイドで真価を発揮している。」と記載され，また，「毛利　豊，Ｗｅｂアプリケーションサーバー徹底解剖（６）　Ｊａｖａ／ＣＯＲＢＡに対応したＮＥＣのミッションクリティカルソリューション基盤　ＡｃｔｉｖｅＧｌｏｂｅ　ＷｅｂＯＴＸ−Ｐａｒｔ１　ＮＥＣのオープンミッションクリティカルソリューション基盤　ＡｃｔｉｖｅＧｌｏｂｅ  ＷｅｂＯＴＸ　Ｖ５−，ＪＡＶＡ　Ｄｅｖｅｌｏｐｅｒ　Ｎｏ．７　ＵＮＩＸ　ＵＳＥＲ　２００３年２月号増刊，ソフトバンクパブリッシング株式会社，２００３年２月１日，ｐ８２〜８９」の第８３頁左欄第３〜１０行には，「ＥＪＢコンテナ　ＥＪＢコンテナは，ＥＪＢ（ＥｎｔｅｒｐｒｉｓｅＪａｖａＢｅａｎｓ）のコンポーネントフレームワークで開発されたビジネスロジックを動作させるための実行基盤である。ＥＪＢのコンポーネントは，ＥＪＢコンテナの提供するセッション制御やトランザクション制御，セキュリティ制御下で動作するため，アプリケーション開発者はビジネスロジックの実装に注力することができる。」と記載されている。
　してみれば，引用例発明の「コンテナー」において，Ｊ２ＥＥの「コンテナ」が提供するトランザクション・サービスやセキュリティ等のサービスを提供するように構成すること，すなわち，引用例発明のサービスが，「ツールに構成された複数の個別の再使用可能かつ共有可能なサービス」を含むように構成することは，当業者が容易に想到し得たことである。
　
［相違点３］について
　企業内でアプリケーション統合を行う際に，「メタデータ・モデル」を構築し，これを「リポジトリ」に格納して，「リポジトリに格納されたメタデータ・モデル」を用いるようにすることは周知技術である。
　例えば「デイビッド・リンティカム，ＥＡＩ−エンタープライズアプリケーション統合，株式会社ピアソン・エデュケーション，２０００年１１月２５日，第１版」の第９４頁第１〜１８行には，「エンタープライズメタデータモデルの構築　企業内ですべてのデータに関するすべての情報が，データカタロダに含まれると，エンタープライズメタデータモデルに集中するときです。この２つの違いはほんのわずかです。ＥＡＩの問題に対する潜在的なソリューションのリストであるとデータカタロダ作成を考えること，および，データレベルＥＡＩソリューションとしてメタデータモデルを考えることは最善の方法です。メタデータモデルは，企業にある既存のデータ構造体ばかりでなく，またどのように，データ構造体がＥＡＩソリューション領域の内部に相互作用し合うのかも，定義します。　構築されたエンタープライズメタデータモデルは，企業のデータベースリポジトリの種類で，ＥＡＩソリューション用のマスターディレクトリです。多くの場合，リポジトリは，メッセージシステム（たとえば，メッセージブローカ）で使用され，データやデータに適用されるルールの位置を示す参照ポイントとして使用されます。しかし，リポジトリは，単にメタデータ情報の格納場所です。それは，究極のＥＡＩソリューションの中心部で，データとビジネスモデル情報の両方を含みます。　この章で概略を述べたプロセスで構築されたメタデータリポジトリは，データレベルＥＡＩの問題を解決するだけではなく，他のタイプのＥＡＩの基礎ともなります。クライアント／サーバおよびデータウェアハウジングの世界において，プロセスは，必要ならば，データからアプリケーションへおよびアプリケーションからインタフェースへと構築します。この「階層的な」の流れは，データレベルＥＡＩを大きなＥＡＩソリューションの基礎として認識しています。」と記載されている。
　そして，引用例発明は，アプリケーション統合を提供するためのシステムであるから，引用例発明において，アプリケーション統合を行う際に上記周知技術を採用し，「リポジトリに格納されたメタデータ・モデル」を用いるようにすることには何ら困難性がない。
　また，リポジトリに格納されたメタデータ・モデルにアクセスするために，そのための「リポジトリ・サービス」を用いるようにすることは，当業者が適宜なし得る設計的事項である。
　してみれば，引用例発明において，「リポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス」を用いるようにするために，サービスが，「リポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス」を含むように構成することは，当業者が容易に想到し得たことである。
　
［相違点４］，［相違点５］について
　Servletコンテナ（コンテナー）の起動時や，Servletコンテナ（コンテナー）にロードされていないServlet（サービス）に対してリクエストがあった時に，Servlet（サービス）をServletコンテナ（コンテナー）にロードして，すなわち「動的に配置」して，利用できるようにすることは周知技術である。
　例えば「梅田　弘之　外１名，Ｗｅｂ−ＤＢシステムなんて恐くない！　ＶＢスキルも活かせる．ＮＥＴ＆Ｊａｖａ速習講座　−ＰＡＲＴ３　ＶＢプログラマもこれで納得　ＪＳＰとＪａｖａＳｃｒｉｐｔの組み合わせでＷｅｂアプリにＶＳ．ＮＥＴ並の表現力を−，ＤＢ　Ｍａｇａｚｉｎｅ，株式会社翔泳社，２００４年８月１日，第１４巻，第５号，ｐ１０６〜１２２」の第１１３頁右欄第１３行〜第１１４頁左欄第６行には，「Ｓｅｒｖｌｅｔコンテナは，起動時にＳｅｒｖｌｅｔをインスタンス化した後，ｉｎｉｔメソッドを１回だけ呼び出して初期化します。初期化されたＳｅｒｖｌｅｔは，コンテナに常駐してクライアントからのリクエストを待ちます。常駐したＳｅｒｖｌｅｔは，クライアントからのリクエストが来ると，リクエスト単位でスレッド（プログラムの処理単位）を割り当てます。つまりスレッドはリクエストと同じ数だけ生成され，ｓｅｒｖｉｃｅメソッドを起動してリクエストに応じます。　インスタンスは，すべてのスレッドが終了し，一定期間経ったときにｄｅｓｔｒｏｙメソッドが発行されてコンテナから切り離されます。ｄｅｓｔｒｏｙメソッドには，メモリなどのリソースの解放やスレッド，ファイルハンドラなどの状態保持のリリースを記載しておきます。　切り離されたＳｅｒｖｌｅｔに対してリクエストのあった場合は，自動的にコンテナにロードされて再びインスタンスが作成されます。一定時間リクエストがない場合は，ガベージコレクションの対象となりメモリ上から削除されます。ガベージコレクションは，ＪａｖａＶＭが持つメモリを自動管理するプロセスです。ＶＭが利用できるメモリ空間（ヒープ）の中から不要なオブジェクトを破棄します。」と記載され，また，「橋本　吉治，Ｊ２ＥＥも．ＮＥＴフレームワークもイチから教えます　基礎からのＷｅｂ−ＤＢアプリケーション開発　−ＰＡＲＴ２　超入門Ｗｅｂ−ＤＢアプリ開発（１）：Ｊａｖａ編　Ｔｏｍｃａｔ＋ＭｙＳＱＬ＋ＥｃｌｉｐｓｅによるゼロからのＪＳＰ／Ｓｅｒｖｌｅｔ開発−，ＤＢ　Ｍａｇａｚｉｎｅ，株式会社翔泳社，２００４年６月１日，第１４巻， 第３号，ｐ５１〜６４」の第５４頁右欄第９行〜第５５頁中欄第１４行には，「Ｓｅｒｖｌｅｔの一生　ここまで，ＳｅｒｖｌｅｔはＳｅｒｖｌｅｔコンテナ上で動作すると説明した。では，どのようにコンテナ上で動作するのだろうか。これは，Ｓｅｒｖｌｅｔが生まれてから，消滅するまでのＳｅｒｖｌｅｔの一生（ライフサイクル）を見ると分かってくる。　Ｓｅｒｖｌｅｔの一生は，(1)生成期，(2)初期化期，(3)実行期，(4)消滅期の４段階に分けられる。
（途中省略）
(1)生成期：Ｓｅｒｖｌｅｔのインスタンス化
「Ｓｅｒｖｌｅｔコンテナの起動時」ならびに「ＳｅｒｖｌｅｔコンテナにロードされていないＳｅｒｖｌｅｔに対してリクエストがあったとき」に，Ｓｅｒｖｌｅｔコンテナによって，Ｓｅｒｖｌｅｔのインスタンスが生成される。これにより，ＳｅｒｖｌｅｔはＳｅｒｖｌｅｔコンテナ上で動作できる状態に入る。
(2)初期化期：Ｓｅｒｖｌｅｔを初期化する
（途中省略）
(3)実行期：クライアントからリクエストを受け，応答する
（途中省略）
(4)消滅期：後始末する
（途中省略）
　以上で，Ｓｅｒｖｌｅｔの一生は終わるわけだが，またクライアントからリクエストがあり，ＳｅｒｖｌｅｔコンテナがＳｅｒｖｌｅｔインスタンス生成をすれば，このライフサイクルが再び繰り返されることになる。」（なお，原文の丸付き数字は，カッコ()で囲んだ数字で表記した。）と記載されている。
　してみれば，引用例発明に上記周知技術を適用して，「コンテナー」にサービスを「動的に配置」して利用できるように構成すること，すなわち，引用例発明の「コンテナー」を「サービスを動的に配置しインスタンス化するためのサービス・ディレクトリ」とすることは，当業者が容易に想到し得たことである。
　また，その結果，「サービス・ディレクトリに動的に配置された」サービスを用いて，データ統合プロセスを設計するように構成することも，当業者が適宜なし得たことである。
　
［相違点６］について
　処理をコンピュータに実行させるための「ジョブ」を作成することは，周知技術であるから，引用例発明において，データ統合プロセスをコンピュータに実行させる際に，当該データ統合プロセスに用いられるサービスをインスタンス化して，「インスタンス化されたサービス（を）含むデータ統合ジョブを作成する」ように構成することは当業者が容易に想到し得たことである。
　
　以上のとおりであるから，［相違点１］〜［相違点６］に係る事項は，引用例発明及び周知技術から当業者が容易に想到し得たものである。
　
　そして，本件補正発明の作用効果も，引用例発明及び周知技術から当業者が予測できる範囲のものである。
　
　よって，本件補正発明は，引用例発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
３−５．むすび
　したがって，本件補正は，改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
４．補正却下についてのむすび
　上記「２．（２）」で記載したとおり，本件補正は，改正前特許法第１７条の２第４項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また，上記「３−５．」で記載したとおり，本件補正は，改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，上記の補正却下の決定の結論のとおり決定する。
　
第３　本願発明について
１．本願発明
　平成２４年１２月２６日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明は，平成２３年２月１５日付けの手続補正書によって補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。（以下，「本願発明」という。）
　
「　【請求項１】
　サービス指向アーキテクチャに基づくサービスを提供するためのシステムであって，
　ツールに構成された複数の個別の再使用可能かつ共有可能なサービス，外部リソース・コネクタをサービスとして公開するコンポーネント・サービス，及びリポジトリに格納されたメタデータ・モデルにアクセスするためのリポジトリ・サービス，を含むサービスを動的に配置しインスタンス化するためのサービス・ディレクトリと，
　前記サービスを用いてデータ統合プロセスをユーザが設計するためのユーザ・インターフェースと，
を含み，
　前記システムに含まれるサーバが，前記ユーザ・インターフェースを介して指定されたサービスをインスタンス化し，前記インスタンス化されたサービスを前記ユーザ・インターフェースに提供する，システム。」
　
２．原査定の拒絶の理由について
　原査定の拒絶の理由の概要は以下のとおりである。  
　
「【拒絶理由】
　　　　　　　　　　＜＜＜＜　　最　　後　　＞＞＞＞
　
　この出願は，次の理由によって拒絶をすべきものです。これについて意見がありましたら，この通知書の発送の日から３か月以内に意見書を提出してください。
　
　　　　　　　　　　　　　　　　理　由
（途中省略）
理由Ｃ．この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
・請求項：１−２４
・引用文献等：１，２
・備考
　引用文献１には，ユーザインターフェースにより，ウェブサービスを組み合わせてタスクを定義し，当該タスクを実行することが記載されている。
　また，引用文献２には，アプリケーションビューにより，引用文献１と同様の機能を実現することが記載されている。
　
　拒絶の理由が新たに発見された場合には拒絶の理由が通知される。
　
　　　　　　　　　　　最後の拒絶理由通知とする理由
　
　この拒絶理由通知は，発明の単一性の要件が満たされないために特許要件等の審査をしなかった請求項について発見した拒絶理由のみを通知するものである。
　
　　　　　　　　　　　引　用　文　献　等　一　覧
１．特開２００４−１９９７００号公報
２．国際公開第２００３／０３４２８５号（特表２００５−５０６６１８号）
　
【補正の却下の決定】
　平成２４年　２月２９日付け手続補正書でした明細書，特許請求の範囲又は図面についての補正は，次の理由によって却下します。
　
　　　　　　　　　　　　　　　　理　由
　
　請求項１−８についての平成２４年２月２９日付けの手続補正書による補正は限定的減縮を目的としている。この場合，補正後の請求項１−８に係る発明は特許出願の際独立して特許を受けることができるものでなければならない。
　しかしながら，データベースを照会することで，利用可能なサービスを選択することは当業者が普通になし得たことであり，引用文献２には，サービスを統合することが記載されている。
　したがって，当該補正後の請求項１−８に係る発明は，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
　よって，この補正は同法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するものであるから，同法第５３条第１項の規定により上記結論のとおり決定する。
　
引用文献等一覧
１．特開２００４−１９９７００号公報
２．国際公開第２００３／０３４２８５号（特表２００５−５０６６１８号）
　
【拒絶査定】 
　この出願については，平成２３年　９月１３日付けの拒絶理由通知書に記載した理由Ａ，Ｃによって，拒絶をすべきものである。
　なお，意見書の内容を検討したが，拒絶理由を覆すに足りる根拠が見いだせない。
　
備考
　平成２４年　２月２９日付け手続補正書による補正は，本拒絶査定と同日付けで補正却下となった。」
　
３．引用例
　原査定の拒絶の理由に引用文献２として引用された引用例（国際公開第２００３／０３４２８５号）には，上記「第２［理由］３−２．」に記載したとおりの事項及び引用例発明が記載されている。
　
４．対比・判断
　本願発明と引用例発明とを対比すると，上記「第２［理由］３−３．」で記載した［相違点１］〜［相違点４］の点，及び次の［相違点７］の点で相違する。
　
［相違点７］
　本願発明では，インスタンス化されたサービスを「ユーザ・インターフェースに提供する」のに対して，引用例発明では，そのような特定はなされていない点。
　
　上記相違点について検討する。
　
［相違点１］〜［相違点４］について
　上記「第２［理由］３−４．」に記載したとおりである。
　
［相違点７］について
　引用例発明では，「アプリケーションビューは，実行時クライアントの使用に対して利用可能にすることができ，アプリケーションビューは，アプリケーションビューに対する要求にサービスを提供することができるアプリケーションビュー用に割り当てられたリソースを備えたコンテナーを有することができ，実行時クライアントは，アプリケーションビュー（の）コンテナーからこのアプリケーションビューのインスタンスを取得し，そのサービスを呼び出してそのイベントを聴取することができ」るものである。
　つまり，引用例発明は，アプリケーションビューの実行時に，アプリケーションビューのインスタンス，すなわち，「インスタンス化されたアプリケーションビュー」を，「実行時クライアント」に「提供する」ものである。
　ここで，引用例発明の「実行時クライアント」を，ビジネスプロセスワークフローを設計するための「ユーザ・インターフェース」としても使用すること，つまり，ビジネスプロセスワークフローの「設計」とアプリケーションビューの「実行」とを同じ「ユーザ・インターフェース」で行えるようにすることは当業者が適宜なし得る設計的事項である。
　してみれば，引用例発明において，インスタンス化されたアプリケーションビュー（サービス）をビジネスプロセスワークフローを設計するための「ユーザ・インターフェース」に「提供する」ように構成し，もって，相違点７に係る発明の構成とすることは当業者が容易に想到し得たことである。
　
　したがって，本願発明は，引用例発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
　そして，本願発明の作用効果も，引用例発明及び周知技術から当業者が予測できる範囲のものである。 
　
５．むすび 
　以上のとおり，本願発明は，引用例発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は他の請求項について検討するまでもなく拒絶されるべきものである。
　よって，結論のとおり審決する。