【事件の表示】
　特願２００４−　６４５６６「分散コンピューティングシステムのためのアーキテクチャ、ならびに分散アプリケーションの自動化設計、展開、および管理」拒絶査定不服審判事件〔平成１６年　９月３０日出願公開、特開２００４−２７２９１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１６年３月８日（パリ条約による優先権主張２００３年３月６日　アメリカ合衆国）の外国語書面出願であって，
　平成１６年５月１０日付けで特許法第３６条の２第２項の規定による明細書，請求の範囲の日本語による翻訳文が提出され，平成１９年３月８日付けで審査請求がなされ，平成２２年５月２０日付けで審査官により拒絶理由が通知され，これに対して平成２２年８月３０日付けで意見書が提出されると共に手続補正がなされたが，平成２２年９月１０日付けで審査官により拒絶査定がなされ，これに対して平成２３年１月１７日付けで審判請求がなされると共に手続補正がなされたので，特許法第１６２条の規定により前置審査に付され，平成２３年３月１０日付けで審査官により最後の拒絶理由が通知され，これに対して平成２３年７月１３日付けで意見書が提出されると共に手続補正がなされ，平成２３年７月２７日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２３年９月２９日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２３年１２月２８日付けで回答書が提出されたものである。
　
第２．本願発明について
　本願の請求項１乃至請求項２５に係る発明は，平成２３年７月１３日付けの手続補正により補正された特許請求の範囲の請求項１乃至請求項２５（以下，これを「本願の請求項１乃至２５」という）に記載の次の事項により特定されるものである。
　
「　　【請求項１】
　分散アプリケーションの設計，分散アプリケーションの展開，および分散アプリケーションの管理のために分散コンピューティングシステムのリソースおよび分散アプリケーションの機能をモデル化したサービス定義モデル（ＳＤＭ）を使用してアーキテクチャ設計された前記分散アプリケーションの前記分散コンピューティングシステム上での実装をホストするＳＤＭランタイムにおける方法であって，
　前記サービス定義モデルを使用して作成されたＳＤＭタイプを取り扱うための１組のＡＰＩを公開することと，
　分散アプリケーションの展開および管理のために，前記サービス定義モデルを使用して作成されたＳＤＭインスタンスを追跡することと
　を備えることを特徴とする方法。
　　【請求項２】
　設計時検証のために，前記サービス定義モデルを使用して作成されたＳＤＭインスタンスを追跡することをさらに備えることを特徴とする請求項１に記載の方法。
　　【請求項３】
　分散アプリケーションの設計，分散アプリケーションの展開，および分散アプリケーションの管理のために分散コンピューティングシステムのリソースおよび分散アプリケーションの機能をモデル化したサービス定義モデル（ＳＤＭ）を備えた設計ツールであって，前記サービス定義モデルは，アプリケーションレイヤ，ホストレイヤ，および仮想システムレイヤを備えることを特徴とする設計ツール。
　　【請求項４】
　前記サービス定義モデルを使用して前記分散システム上の分散アプリケーションを設計することをさらに備えることを特徴とする請求項１に記載の方法。
　　【請求項５】
　分散アプリケーションを設計することに関連するサービス，分散アプリケーションを展開することに関連するサービス，および分散アプリケーションを管理することに関連するサービスを含む，物理データセンタのリソースおよび分散アプリケーションの機能をモデル化したサービス定義モデルに従って物理データセンタを記述することにより，前記物理データセンタを表わすスケール不変の仮想データセンタの設計を容易にすることを備えることを特徴とする方法。
　　【請求項６】
　前記仮想データセンタは，第１のデータセンタおよび第２のデータセンタによってサポートされ，アプリケーション部分と前記仮想データセンタ部分との間の論理モデルマッピングの変更を要することなく，前記アプリケーションを前記第１のデータセンタ，または前記第２のデータセンタに展開することができるようにすることを特徴とする請求項５に記載の方法。
　　【請求項７】
　前記物理データセンタのある特定の論理コンポーネントに関して作成されるインスタンスの数を決定することと，
　前記物理データセンタを実装する配線トポロジを決定することと
　をさらに備えることを特徴とする請求項５に記載の方法。
　　【請求項８】
　物理リソースおよび分散アプリケーションを自動的に展開することをさらに備えることを特徴とする請求項５に記載の方法。
　　【請求項９】
　モデルベースの管理アプローチを使用して前記物理データセンタ上で分散アプリケーションを管理することをさらに備えることを特徴とする請求項５に記載の方法。
　　【請求項１０】
　前記物理データセンタは，トリガイベントに応答して一続きのオペレーションタスクを統合するためのオペレーションエンジンを含むことを特徴とする請求項５に記載の方法。
　　【請求項１１】
　前記トリガイベントは，前記サービス定義モデルからのアプリケーションコンテキストにより注釈付されることを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　前記一続きのオペレーションタスクは，リソース管理システムを使用して新たなリソースを展開することを含むことを特徴とする請求項１０に記載の方法。
　　【請求項１３】
　物理データセンタのリソースおよび分散アプリケーションの機能をモデル化したサービス定義モデル（ＳＤＭ）を使用する方法であって，
　仮想データセンタおよび分散アプリケーションの設計を容易にすることと，
　前記仮想データセンタ上に前記分散アプリケーションの部分を論理的に配置することと，
　前記仮想データセンタに基づいて物理データセンタを実装することと
　を備えることを特徴とする方法。
　　【請求項１４】
　前記仮想データセンタに前記分散アプリケーションの部分を論理的に配置するとき，前記仮想データセンタの運用者のビューは，前記分散アプリケーションの前記配置に関連する部分だけを収容するように制限されることを特徴とする請求項１３に記載の方法。
　　【請求項１５】
　前記仮想データセンタは，複数のサービス定義モデルレイヤを含み，各レイヤはその下のレイヤの上に論理的に配置されるようにすることを特徴とする請求項１３に記載の方法。
　　【請求項１６】
　前記分散アプリケーションをサポートするように前記仮想データセンタのリソースを割り振ることをさらに備えることを特徴とする請求項１３に記載の方法。
　　【請求項１７】
　物理データセンタのリソースおよび分散アプリケーションの機能をモデル化したサービス定義モデル（ＳＤＭ）を使用する方法であって，
　仮想データセンタおよび分散アプリケーションの設計を容易にすることと，
　前記仮想データセンタ上に前記分散アプリケーションの部分を論理的に配置することと，
　前記分散アプリケーションの前記部分の前記配置が有効であるかどうかを判定することと
　を備えることを特徴とする方法。
　　【請求項１８】
　前記分散アプリケーションの前記部分の前記配置が有効でない場合，警告メッセージを生成することをさらに備えることを特徴とする請求項１７に記載の方法。
　　【請求項１９】
　前記仮想データセンタに基づいて物理データセンタを実装することをさらに備えることを特徴とする請求項１７に記載の方法。
　　【請求項２０】
　前記分散アプリケーションをサポートするように前記仮想データセンタのリソースを割り振ることをさらに備えることを特徴とする請求項１７に記載の方法。
　　【請求項２１】
　分散コンピューティングシステム上で分散アプリケーションを設計し，展開し，管理する際に使用するための，分散コンピューティングシステムのリソースおよび分散アプリケーションの機能をモデル化したソフトウェアアーキテクチャであって，
　マシンを前記分散コンピューティングシステムにて使用されるサーバに変換するために使用するツールのための第１のソフトウェアレイヤと，
　分散アプリケーションのネットワーク管理および仮想トポロジ生成のための第２のソフトウェアレイヤと，
　前記分散コンピューティングシステムの物理モデルを維持管理する第３のソフトウェアレイヤと，
　前記分散アプリケーションによって要求される論理リソースの割り振りを容易にする第４のソフトウェアレイヤと，
　オペレーションプロセスを記述するための名前空間およびコンテキストと，アプリケーションイントロスペクションおよびアプリケーションリソースの制御のためのＡＰＩとを提供するサービス定義モデル（ＳＤＭ）のための第５のソフトウェアレイヤと，
　分散アプリケーションの再使用可能なビルディングブロックを定義し，コンテキスト，名前付け，およびバインド化のために前記ＳＤＭのＡＰＩを使用する第６のソフトウェアレイヤと，
　前記分散アプリケーションのオペレーション上の管理のための第７のソフトレイヤと
　を備えたことを特徴とするソフトウェアアーキテクチャ。
　　【請求項２２】
　分散コンピューティングシステムのリソースおよび分散アプリケーションの機能をモデル化したソフトウェアアーキテクチャによって設計された分散アプリケーションを展開し，管理する際に使用するためのリソースマネージャであって，
　分散コンピューティングシステム内のリソースを割り振るための手段と，
　利用可能なハードウェアを発見するための手段と，
　リソース割り振り要求を処理するための手段と，
　リソースの所有権を追跡するための手段と，
　リソースを制御するための手段と，
　前記分散コンピューティングシステム内のすべてのリソース管理のために共通のＡＰＩを提供するための手段と
　を備えたことを特徴とするリソースマネージャ。
　　【請求項２３】
　リソースを割り振るための前記手段は，前記分散コンピューティングシステム内の論理リソースおよび物理リソースを割り振るように構成されていることを特徴とする請求項２２に記載のリソースマネージャ。
　　【請求項２４】
　前記分散コンピューティングシステム上で分散アプリケーションを管理するための手段をさらに備えたことを特徴とする請求項２２に記載のリソースマネージャ。
　　【請求項２５】
　リソースを制御するための前記手段は，イベントに応答して一続きのオペレーションタスクを統合するように構成されていることを特徴とする請求項２２に記載のリソースマネージャ。」
　
第３．前置審査における拒絶理由
　一方，前置審査における平成２３年３月１０日付けの拒絶理由（以下，「前置拒絶理由」という）は，概略，次のとおりである。
　
「［前置審査］
　　　　　　　　＜＜＜＜　　最　　後　　＞＞＞＞
　
　この出願は，次の理由によって拒絶をすべきものです。これについて意見がありましたら，この通知書の発送の日から３か月以内に意見書を提出してください。
　
　　　　　　　　　　　　　　 理　由
　
１．省略
　
２．省略
　
３．この出願は，明細書及び特許請求の範囲の記載が下記の点で，特許法第３６条第４項第１号並びに第６項第１号及び第２号に規定する要件を満たしていない。
 
　　　　　　　　　　　　　　　　記
 
（１）省略
（２）請求項１の記載において，「分散システムの実装をホストするＳＤＭランタイム」が，日本語としても技術的にも意味が不明である。
　よって，「ＳＤＭランタイム」がいかなるものであるのか不明である。
（３）請求項１の記載「ＳＤＭランタイムにおける方法」は，ａ）「ＳＤＭランタイム」が行う方法という意味であるのか，またはｂ）「ＳＤＭランタイム」を対象とした方法という意味であるのか，不明である。
　ａ）である場合，「ＳＤＭランタイム」は，「公開」及び「追跡」といった処理を実現するためにどのような構成を有しているのか不明である。
　ｂ）である場合，何が処理の主体であるのか不明である。
（４）請求項１の記載において，「公開」及び「追跡」を，何が，どのような手段により行うのか不明である。また，何に対して「公開」を行うのかも不明である。
（５）省略
（６）省略
（７）請求項１の記載において，「ＳＤＭインスタンスを追跡」すると，なぜ，「分散アプリケーションの展開および管理」が実現できるのか，因果関係が不明である。
　請求項２の記載についても同様である。
（８）省略
（９）省略
（１０）前記（１）乃至（９）については，発明の詳細な説明にも，明確かつ十分に記載していない。
　　
　よって，請求項１及び２に係る発明は，明確でなく，かつ，発明の詳細な説明に記載したものではなく，並びに，発明の詳細な説明は，請求項１及び２に係る発明を，当業者が実施できる程度に明確かつ十分に記載していない。」
　
第４．当審の判断
１．理由３の（２）について
　平成２３年７月１３日付けの手続補正によって補正された，本願の請求項１には，
「前記分散アプリケーションの前記コンピュータ上での実装をホストするＳＤＭランタイム」と記載されているが，
　本願の請求項１，及び，本願の他の請求項の記載内容からは，
「前記分散アプリケーションの前記コンピュータ上での実装をホストするＳＤＭランタイム」がどのようなものであるか不明である。
　そこで，本願明細書の発明の詳細な説明を参照すると，発明の詳細な説明には，その段落【０２１９】，及び，段落【０２４７】に，
「ＳＤＭランタイム（または単にランタイム）は、ＳＤＭの実装をホストする」という記載は存在するが，
“分散アプリケーションのコンピュータ上での実装をホストするＳＤＭランタイム”という記載，あるいは，それに類似する記載は存在しない。
　そして，「ＳＤＭ」，すなわち，「サービス定義モデル」と，該「サービス定義モデル」を用いて「アーキテクチャ設計された」，「分散アプリケーション」とは明らかに別のものであるから，「ＳＤＭの実装」と，「分散アプリケーションのコンピュータ上での実装」も別のものである。
　したがって，本願明細書の発明の詳細な説明に記載された内容を参酌しても，
「前記分散アプリケーションの前記コンピュータ上での実装をホストするＳＤＭランタイム」がどのようなものであるか不明であるから，結果として，前置拒絶理由で不明であると指摘された，「分散システムの実装をホストするＳＤＭランタイム」は，依然として不明である。
　
　この点に関して，審判請求人は，平成２３年７月１３日付けの意見書において，
　
「請求項１に記載の「分散システムの実装をホストするＳＤＭランタイム」については、手続補正書において、当該記載を「前記分散アプリケーションの前記分散コンピューティングシステム上での実装をホストするＳＤＭランタイム」としました。
　ここで、「ランタイム」とは、当技術分野において、プログラムを実行するために必要なライブラリないし環境のことをいいます。そして、本願発明における「ＳＤＭランタイム」は、請求項に記載のとおり、「サービス定義モデル（ＳＤＭ）を使用してアーキテクチャ設計された（前記）分散アプリケーションの（前記）分散コンピューティングシステム上での実装をホストする」ものです。
　従いまして、「ＳＤＭランタイムにおける方法」は、「分散コンピューティングシステム」といったハードウエア資源を用いて具体的に実現されたものであり、審査基準第VII部第1章2.2.1(1)の「ソフトウエアによる情報処理が、ハードウエア資源を用いて具体的に実現されている」ものと思料致します。」
　
　との主張を行っているが，該主張中では，前置拒絶理由で指摘した，
「「分散システムの実装をホストするＳＤＭランタイム」が，日本語としても技術的にも意味が不明である。」
　点について，特段反論するものではなく，上記引用の主張を加味しても，前置拒絶理由で指摘の点が解消するものではない。
　
２．理由３の（３），及び，（４）について
　本願の請求項１においては，
「ＳＤＭランタイムにおける方法であって，」
「サービス定義モデルを使用して作成されたＳＤＭタイプを取り扱うための１組のＡＰＩを公開することと」，
「分散アプリケーションの展開および管理のために，前記サービス定義モデルを使用して作成されたＳＤＭインスタンスを追跡することと」，
「を備えることを特徴とする方法」
　と記載されていて，該記載では，「ＳＤＭランタイム」自体が行う事項であるか，「ＳＤＭランタイム」を対象として，何らかの処理主体が処理を実行するものであるか明りょうでない。
　そして，「ＳＤＭタイプを取り扱うための１組のＡＰＩを公開する」こと，及び，「ＳＤＭインスタンスを追跡する」ことを行っているのが，「ＳＤＭランタイム」である場合，本願の請求項１に記載の内容からは，「１組のＡＰＩを公開する」ため，及び，「ＳＤＭインスタンスを追跡するため」に，「ＳＤＭインスタンス」がどのような構成をしているか不明である。この点は，本願の他の請求項の記載内容を加味しても不明のままである。
　そこで，この点に関して，本願明細書の発明の詳細な説明を参照すると，発明の詳細な説明には，
　
「す
べてのインスタンスを作成の時点から，インスタンスが削除されるまで追跡するのは，ＳＤＭランタイムの仕事である
　
「ＳＤＭランタイムはそれ自体，コンポーネント，ポート，およびワイヤのインスタンスを作成せず，代わりに，
ＳＤＭインスタンスの作成と管理を調整するために使用される１組のＡＰＩを提供する
　
「【００４０】
　ＳＤＭランタイムは，「ＳＤＭインスタンス作成」プロセスがいつ開始し，成功または失敗して，いつ終わるかを知っている。また，ＳＤＭランタイムは，ＳＤＭインスタンスの存続期間中に，ＳＤＭインスタンスにどのような変更が行われるかも知っている。ＳＤＭランタイムについての１つの考え方は，ＳＤＭランタイムは，ある所与のアプリケーション／サービスＳＤＭに関連するすべてのトランザクションを記録し，指定されたＳＤＭに関連するインスタンスについての情報を問い合わせることができるアカウンタント（ａｃｃｏｕｎｔａｎｔ）であるということである。ＳＤＭインスタンスを作成する最初のステップは，ＳＤＭランタイムとのアプリケーション／サービスＳＤＭの登録である。ＳＤＭランタイムがある所与のＳＤＭについて知ると，ファクトリおよびリソースマネージャ（以下に説明する）を使用して，インスタンス作成プロセスを呼び出すことができる。
　
ＡＰＩおよびランタイム設計に関するより詳細な情報については，http://big/にあるＳＤＭランタイムアーキテクチャ仕様を閲覧されたい
　
「
ＳＤＭランタイムは，ＳＤＭタイプ空間，メンバ空間，およびインスタンス空間を操作するための所定のＡＰＩを公開する
ランタイムは，一貫性のある形ですべてのＳＤＭインスタンスを追跡する責を担う
　
「●ＳＤＭランタイム−これは，ＳＤＭランタイムの実装である。ＳＤＭランタイムは，１つまたは複数の物理マシン上で稼動する分散された実装である。
ランタイムは，ＳＤＭおびインスタンスを操作するコールのセットであるＳＤＭ　ＡＰＩを通じて自らの機能を公開する
　
「このレイヤは、分散アプリケーションの再使用可能なビルディングブロックの定義を可能にし、コンテキスト、名前付け、およびバインド化のための
ＳＤＭ　ＡＰＩを使用する
　
「ＳＤＭランタイムは、ホスト上で新たなインスタンスを作成し、そのタイプ上の設定値に合致するようにそのインスタンスを構成する責を担う適切なインストーラを（クラスとホストの関係に基づいて）呼び出す。
ＳＤＭランタイムは、すべてのインスタンス、それらの最終設定値、および配置のデータベースを維持管理することになる。ランタイムＡＰＩは、インスタンス空間の照会をサポートする
　
「●
ＳＤＭランタイムは、ＳＤＭのモデルおよびインスタンスを追跡する責を担う
　◆ＩＩＳによってホストされるＷｅｂサービスとして実装される。　
　◆スケーラビリティのために区画化することができる。　
●
ランタイムＡＰＩがＳＯＡＰエンドポイントを公開する
　
　という記載が存在し，上記引用の記載から，「ＡＰＩを公開する」，「インスタンスを追跡する」ものが，「ＳＤＭランタイム」であることは読み取れる。
　しかしながら，上記引用の発明の詳細な説明に記載された内容においては，「ＡＰＩを公開する」こと，及び，「ＳＤＭランタイムのＡＰＩ」が提供する機能といった点については，一応，説明されているが，「ＳＤＭランタイム」が，「ＡＰＩ」を公開するための構成については，何ら述べられておらず，更に，上記引用の段落【００４０】には，
「ＡＰＩおよびランタイム設計に関するより詳細な情報については，http://big/にあるＳＤＭランタイムアーキテクチャ仕様を閲覧されたい」と記載されていて，この記載から，本願明細書中には，「ＳＤＭランタイム」が，「ＡＰＩ」を公開するための構成については記載されていないものと解される。
　また，「ＳＤＭランタイム」が，「ＳＤＭインスタンス」を「追跡する」点については，
　上記引用の段落【００４０】に「追跡する」ことに関連する記載が存在するが，該記載中の，
「「ＳＤＭインスタンス作成」プロセスがいつ開始し，成功または失敗して，いつ終わるかを知っている。また，ＳＤＭランタイムは，ＳＤＭインスタンスの存続期間中に，ＳＤＭインスタンスにどのような変更が行われるかも知っている」ことをどのように実現しているのか，
「ＳＤＭランタイムは，ある所与のアプリケーション／サービスＳＤＭに関連するすべてのトランザクションを記録し，指定されたＳＤＭに関連するインスタンスについての情報を問い合わせることができるアカウンタント（ａｃｃｏｕｎｔａｎｔ）であるということである」とは，「ある所与のアプリケーション／サービスＳＤＭに関連するすべてのトランザクション」を，何処に，どのように記録しているのか，また，「指定されたＳＤＭに関連するインスタンスについての情報を問い合わせることができる」とは，何が，どのようにすることで「ＳＤＭランタイム」への問合せを行っているのか，「ＳＤＭランタイム」が，「アカウント」であるとは，どのような状況を表現し，それをどのように実現しているのか，不明であり，結果として，
“「ＳＤＭランタイム」が，「ＳＤＭインスタンス」を「追跡する」”ことが，どのように実現されているのか，不明である。
　上記指摘の点は，上記で引用した本願明細書の発明の詳細な説明の記載以外の箇所の記載を加味しても，不明のままである。
　よって，本願明細書の発明の詳細な説明に記載された内容を加味しても，
“「ＳＤＭランタイム」が，「ＡＰＩ」を公開するための構成”は不明であり，かつ，“「１組のＡＰＩを公開する」ため，及び，「ＳＤＭインスタンスを追跡するため」に，「ＳＤＭランタイム」がどのような構成をしているか”は不明である。
　
　この点に関して，審判請求人は，平成２３年７月１３日付けの意見書において，
　
「（３）請求項１の記載「ＳＤＭランタイムにおける方法」は，ａ）「ＳＤＭランタイム」が行う方法という意味であるのか，またはｂ）「ＳＤＭランタイム」を対象とした方法という意味であるのか，不明である。
　請求項１には「ＳＤＭランタイムにおける方法」とあるので，「ＳＤＭランタイム」を対象とした方法という意味には解されないように思われます。
（４）請求項１の記載において，「公開」及び「追跡」を，何が，どのような手段により行うのか不明である。また，何に対して「公開」を行うのかも不明である。
　請求項１に記載のとおり，「公開」及び「追跡」は，「ＳＤＭランタイムにおける方法」であり，当業者にとって特許を受けようとする発明は明確であるものと思われます。請求項１の記載において，「公開」及び「追跡」を，何が，どのような手段により行うのか不明であることにより，特許を受けようとする発明が明確でないとする理由，例えば，審査基準のどの類型に該当するのかについてご教示頂きたくお願い致します。」
　
　と述べるにとどまり，上記引用の主張を加味しても，前置拒絶理由で指摘の点が解消するものではない。
　
３．理由３の（７）について
　本願の請求項１には，
「分散アプリケーションの展開および管理のために，前記サービス定義モデルを使用して作成されたＳＤＭインスタンスを追跡すること」，
　と記載されているだけであるから，同請求項１の記載内容から，「ＳＤＭインスタンスを追跡すること」によって，どのようにして「分散アプリケーションの展開および管理」を実現しているか不明である。
　そこで，この点に関して，本願明細書の発明の詳細な説明を参照すると，
　「分散アプリケーションの展開および管理」に関する記述，ならびに，「ＳＤＭインスタンスの追跡」に関する記述については，上記第４の２．で引用した記載のほか，発明の詳細な説明には，段落【０００９】に，
「本開示は，ＳＤＭを使用してコンテキスト上の管理フィードバック，追跡（ｔｒａｃｋｉｎｇ），およびオペレーション（ｏｐｅｒａｔｉｏｎｓ）フィードバックを提供することを含む管理の態様も扱う」，
　段落【００２０】に，
「ＳＤＭは，より高度な機能を構築する基礎となるいくつかの基本プリミティブを定義する必要がある。これらのプリミティブは，次のとおりである。
●コンポーネント−実装，展開，および管理の単位」，
　段落【００２２】に，
「
コンポーネント
　段落【００３８】，及び，段落【００８４】に，
「インスタンスは，物理リソース（サーバ，ネットワークスイッチポート，およびディスク）が割り振られ，ソフトウェアリソース（オペレーティングシステム，ランタイムホスト，アプリケーションコード）がインストールおよび構成されるようにアプリケーション／サービスを展開した結果である」
　段落【００３９】，及び，段落【００８６】に，
「ＳＤＭランタイムはそれ自体，コンポーネント，ポート，およびワイヤのインスタンスを作成せず，代わりに，ＳＤＭインスタンスの作成と管理を調整するために使用される１組のＡＰＩを提供する」，
　段落【００４４】，及び，段落【００９２】に，
「ファクトリはそれ自体，ストレージ，ネットワーク，およびサーバなどの物理リソースを管理しない，」
　段落【００４５】，及び，段落【００９３】に，
「
リソースマネージャ
リソースマネージャは
２）物理環境の何らかの宣言的ＸＭＬベースの記述を通して指定される物理リソースおよび論理リソースを管理する
これらのリソースの所有権を追跡する
　段落【００４８】，及び，【００９６】に，
「
レイヤおよびマッピング
分散アプリケーション／サービスを展開し，管理するために十分ではない
　段落【０１１２】に，
「ＳＤＭは，分散アプリケーションおよびその展開環境の要素的断片を取り込むのによく適したメタモデルである。ＳＤＭには，権限がある（ａｕｔｈｏｒｉａｔｉｖｅ）。すなわち，アプリケーションおよび環境は，それらのＳＤＭから構築され，
アプリケーションおよび環境に対する変更は，ＳＤＭを介して行われる
　段落【０１３４】に，
「展開
　ＳＤＵ，論理配置ファイル，インスタンス要求，および物理配置ファイルが，ＳＤＭランタイムに送り込まれる。すると，ＳＤＭランタイムは，クラスおよびホストの関係に基づいて適切なインストーラを呼び出すことになる。インストーラは，ホスト上で新たなインスタンスを作成し，そのタイプ上の設定値に適合するようにそのインスタンスを構成する責を担う。
ＳＤＭランタイムは，すべてのインスタンス，それらの最終設定値，および配置のデータベースを維持管理することになる
　次に引用の各段落に，
「【０１３８】
　
インスタンス空間は，アプリケーションを展開し，実行するプロセス中に作成されるインスタンスから成る
　【０１３９】
　リソースクラス
　設計時に構成を検査して，
実行時に展開するために，リソースクラスを使用して，知る必要があるアプリケーションの要素を定義する
　段落【０１４１】に，
「ｂ）どのような設定がアプリケーションに適用され，
どのようにアプリケーションが展開されるか
　段落【０１４６】に，
「コンポーネントタイプを使用して，独立に展開することができ，マシン境界を越えて分散させることもできるアプリケーションの部分がモデル化される」
　段落【０１８３】に，
「アプリケーション基本タイプ
　すべてのアプリケーションタイプスキーマは，以下のアプリケーション基本スキーマに基づく。基本スキーマの属性は，タイプが基づくクラス，およびそのタイプの名前を特定する。スキーマ本体において，
そのタイプを展開することができるようにする展開値
　段落【０２１９】に，
「ＳＤＭランタイム
　ＳＤＭランタイム（または単にランタイム）はＳＤＭの実装をホストする・・・
このランタイムは，一貫性のある形ですべてのＳＤＭインスタンスを追跡する責を担う
　段落【０２３３】，及び，段落【０２４７】に，
「ＳＤＭは，すべてのサービスを構築する基盤である。ＳＤＭは，
・・・・・
◆サービス展開，再使用，発見，バージョン管理，および回復のための標準を定義する」，
　段落【０２３５】に，
「ＳＤＭは，サービスのためのコンポーネントモデルを定義している。このモデルは，緩やかに結合された分散型の非同期サービスによく適している。
ＳＤＭは，展開，バージョン管理，回復，およびスコーピング（ｓｃｏｐｉｎｇ）について標準を定義する
　段落【０２４３】に，
「
これらのインスタンスは，ＳＤＭランタイムによって追跡されることになる
　注：ここで使用している構文は，ＳＤＭＬではなく，
ＳＤＭランタイムによって追跡されるインスタンス空間を例示する
　段落【０２５４】に，
「ＳＤＭランタイムは，３つすべての空間，ならびに３つの空間の間の関係を追跡する責を担う」，
　段落【０２９９】に，
「各ＳＤＭランタイムインスタンスは，インスタンス空間の一部分を追跡する責を担う」，
　段落【０３０１】に，
「各ランタイムは，自らが追跡しているインスタンスによって定義されるタイプおよびメンバについてだけ知っているだけでよいことになる・・・・
・・・ある所与のランタイムは，インスタンス空間の一部分を追跡しているだけである」，
　段落【０３０４】に，
「この図では，ボックスは，コンポーネントインスタンスに関して追跡されたインスタンス状態を表す−コンポーネントインスタンス実装コードではない」，
　段落【０３０５】に，
「ランタイムは，自らが追跡しているインスタンスに関するすべてのタイプについて知らなければならない」，
　段落【０３０８】に，
「すべてが単一のルートコンポーネントインスタンスのインスタンスである複合コンポーネントインスタンスを追跡するランタイムは，単一ルートランタイムと呼ばれる」，
　段落【０３０９】に，
「ルート複合コンポーネントインスタンスを有さない複合インスタンスを追跡するランタイムは，マルチルートランタイムと呼ばれる」，
　段落【０３２６】に，
「振る舞い仕様
　
ＳＤＭランタイムは，すべてのＳＤＭクラス，ＳＤＭタイプ，およびＳＤＭインスタンスを追跡する責を担う
ＳＤＭランタイムは，分散アプリケーションを展開する目的で，ＳＤＭドキュメントに対して登録し，操作するための１組のＳＯＡＰインターフェースを公開する
　段落【０３３３】に，
「どの展開動作に関する許可も役割ベースの許可を使用してＳＤＭランタイムによって管理されること」，
　との記載が存在し，更に，段落【０３８６】以降に，
「データセンタおよび分散アプリケーションの展開」に関する記述が，
　そして，段落【０４４０】以降に，
「データセンタおよび分散アプリケーションが展開された後のこれらの管理」についての記述が存在しているが，
　上記引用の何れの記載からも，「展開」，「管理」と，「追跡」との関係は読み取れず，「追跡」に関しては，単に，「インスタンス」を「追跡」するという“処理”が示されているのみで，該“処理”によって，どのような“結果”がもたらされるかは示されていない。
　よって，上記引用の記載からでは，「ＳＤＭランタイム」が，「ＳＤＭインスタンス」を「追跡」することで，どのようにして，「分散アプリケーション」の「展開」と，「管理」を実現するか不明である。
　上記指摘の点は，上記引用以外の，発明の詳細な説明の記載内容を加味しても，同様に不明である。
　
　この点に関して，審判請求人は，平成２３年７月１３日付けの意見書において，
　
「（７）請求項１の記載において、「ＳＤＭインスタンスを追跡」すると、なぜ、「分散アプリケーションの展開および管理」が実現できるのか、因果関係が不明である。
　請求項１の記載において、「ＳＤＭインスタンスを追跡」すると、なぜ、「分散アプリケーションの展開および管理」が実現できるのか、因果関係が不明である点については、審査基準第Ｉ部第1章2.2.2.1(2)「技術的意味・技術的関連が理解できない結果、発明の範囲が不明確となる場合」にあたり、特許を受けようとする発明が明確でないとされているものと思われます。しかしながら、逆に、「ＳＤＭインスタンスを追跡する」しなければ、「分散アプリケーションの展開および管理」は実現できないのではないかと思われます（本願明細書の段落００４０参照）。」
　
　と述べるにとどまり，前置拒絶理由で指摘の点は，上記において当審が検討したとおりであるから，上記引用の審判請求人の主張を加味しても，前置拒絶理由で指摘した不明である点が，解消するものではない。
　
４．理由３の（１０）について
　本願の請求項１に記載の，
「前記分散アプリケーションの前記コンピュータ上での実装をホストするＳＤＭランタイム」，
「サービス定義モデルを使用して作成されたＳＤＭタイプを取り扱うための１組のＡＰＩを公開すること」，
「分散アプリケーションの展開および管理のために，前記サービス定義モデルを使用して作成されたＳＤＭインスタンスを追跡すること」，
　について，本願明細書の発明の詳細な説明には，上記第４の１．〜３．に引用した記載があるに止まるので，上記第４の１．〜３．で検討したとおり，
“分散アプリケーションのコンピュータ上での実装をホストするＳＤＭランタイム”，
「ＳＤＭランタイム」が，どのようにして，“サービス定義モデルを使用して作成されたＳＤＭタイプを取り扱うための１組のＡＰＩを公開する”のか，同じく，
「ＳＤＭランタイム」が，どのようにして，“ＳＤＭインスタンスを追跡する”のか，更に，“ＳＤＭインスタンスを追跡する”ことで，どのようにして，“分散アプリケーションの展開および管理”を実現しているのか，発明の詳細な説明に記載された内容からは不明である。
　
　以上のとおりであるから，本願の請求項１に係る発明は明確でなく，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。
　
第５．むすび
　したがって，本願は，特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。
　
　よって，結論のとおり審決する。