【事件の表示】
　特願２００１−１１１０８０「ジョブ・インスタンスの実行依頼及びモニタリングを行うための方法、システム、及びプログラム記憶デバイス」拒絶査定不服審判事件〔平成１３年１２月２１日出願公開、特開２００１−３５０６３６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は平成１３年４月１０日の出願（２０００年４月１２日　パリ条約に基づく優先権主張，米国）であって、その手続の経緯は、概略以下の通りである。
平成１６年　７月　９日　拒絶理由通知
平成１７年　１月１３日　意見書・手続補正書
平成１７年１０月　７日　拒絶査定
平成１８年　１月１６日　拒絶査定不服審判請求
平成１８年　１月３１日　手続補正書
平成１９年１１月１３日　審尋
平成２０年　２月２０日　回答書
平成２０年１１月１４日　補正却下の決定
　　　　　　　　　　（対象：平成１８年１月３１日付け手続補正書）
平成２０年１１月１４日　拒絶理由通知
平成２１年　２月１０日　意見書・手続補正書
平成２１年　２月１８日　意見書・手続補正書
　
　
２．当審の拒絶理由
　上記当審において通知した平成２０年１１月１４日付けの拒絶理由通知の理由の概要は以下の通りである。
　
「　　　　　　　　　　　　　　　　理　由
　
１．平成１７年１月１３日付けでした手続補正は、下記の点で願書に最初に添付した明細書又は図面（以下当初明細書等と記す。）に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
＜・・・中略・・・＞　
　よって、本件補正は、また当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな事項を導入するものであり、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてしたものでない。　
　
　
２．この出願は、発明の詳細な説明及び特許請求の範囲の記載が下記の点で、特許法第３６条第４項及び第６項第１号、第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　
（１）本願特許請求の範囲の請求項１〜１１に、以下の（１−１）〜（１−２６）に示す如き不明確な記載・意味不明の記載等が多数有り、発明の範囲が明確でない（特許法第３６条第６項第１号違反）。
　そして、このため、請求項１〜１１に係る発明と発明の詳細な説明の記載とが整合せず（同条同項第１号違反）、しかも、本願明細書の発明の詳細な説明の記載は、当業者が請求項１〜１１に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり（同条第４項（実施可能要件）違反）、請求項１〜１１に係る発明の技術上の意義を理解するために必要な事項も十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもある（同条第４項（委任省令要件）違反）。
　
（１−１）請求項１〜８の「ジョブ・インスタンスの実行依頼及びモニタリング方法」がコンピュータを利用する方法、コンピュータ内部で実行される方法のいずれの発明であるのかが明確でない。
　
（１−２）請求項１に「フェッチするステップ」「実行依頼するステップ」「格納するステップ」「確定するステップ」「インプリメントするステップ」等種々のステップが記載されているが、その主体（「人間」？「プロセッサ」？「システム」？「デバイス」？「プログラム」？「ＡＰＩ」？「インスタンス」？「アプリケーション」？）が明確でない。また、該主体がいずれであっても所期の課題を解決し所望の作用効果を奏し得ることを裏付ける記載は、本願発明の詳細な説明には見いだせない。
　
（１−３）請求項１〜１１の「プロセッサ」なる用語の技術的意味（チップを意味するのか？装置を意味するのか？）が明確でない。
　
（１−４）請求項１、１０、１１に「状態モデルを用い」て「モニタリングする」旨の記載があるが、その技術的意味（単に「状態モデル」を念頭に設計すると言う程度の意味なのか？「状態モデル」のデータを記憶手段内に保有してこのデータにアクセスして「モニタリング」なる処理をするのか？）が明確でない。またこのため、発明の範囲（単に「モニタリングする」ものとはどう相違し、どう区別（線引き）されるのか？）が明確でない。
　
（１−５）請求項１、１０、１１に「関連付けられたジョブ・インスタンス起動情報」とあるが、何にどう「関連付けられ」ているのかが明確でない。
　
（１−６）請求項１、１０、１１に「ジョブ・インスタンス起動情報」とあるが、その定義（ジョブ・インスタンスとどの様な関係にあるどの様な情報なのか？）が明確でなく、また、具体的な事物の想定も不可能である。（発明の詳細な説明を参酌してもその実例の開示すらない。）
　
（１−７）請求項１、１０、１１に「プロセッサ上で起動しているジョブ待ち行列入れサブシステム」とあるが、その意味（「プロセッサ上で起動している」とはいかなる状態を意味しているのか？「ジョブ待ち行列入れサブシステム」とは如何なるカテゴリのもの（記憶装置なのか？プログラムなのか？装置なのか？）で、如何なる作用・機能のものなのか？）が不明である。
　
（１−８）請求項１、１０、１１の「ＡＰＩ」とは如何なるカテゴリーのもの（インタフェースなのか？プログラムなのか？記憶手段なのか？装置なのか？）が明確でなく、「アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンス起動情報を格納する」、「ＡＰＩのところで」「確定する」、「ＡＰＩによって」「報告」する等の表現からも明確に特定できない。
　
（１−９）請求項１、１０、１１に「ジョブ・インスタンス起動情報を格納する」とは「ＡＰＩ」が如何なる情報処理を行うこと意味するのか（何所にどの様に格納するのか？）が明確でなく、しかも、発明の詳細な説明には係る技術的事項の開示はないため、発明の詳細な説明を参酌しても、その具体的事物を想定することができない。
　
（１−１０）請求項１、１０、１１に「ＡＰＩのところで」「確定する」とあるが、「ＡＰＩ」と「確定」の関連が明確でない。（文言通りに解釈すると「ＡＰＩ」と言う場所で「確定」なる処理がなされると言う意味に解釈されるが、このような解釈は技術的にみて不合理である。）
　また、請求項６の「前記確定するステップは前記ＡＰＩによって実行される」なる事項との関係（同じ事を意味しているのか否か）が明確でない。
　
（１−１１）請求項１、１０、１１に「ジョブ・インスタンスの状態を確定する」とあるが、その技術的意味が明確でない。（文言通りに解釈すると何らかの手段が「ジョブ・インスタンス」に対して働きかけをしてその「ジョブ・インスタンス」を制御して「状態を確定」するものと解されるが、そのような動作に技術的意義は見いだせない。）また、係る事項は発明の詳細な説明にも記載されていない。
　
（１−１２）請求項１、１０、１１に「ＡＰＩによって」「報告し」なる表現があるが、その技術的意味（「ＡＰＩ」を利用して「報告」すると言う意味なのか？「ＡＰＩ」が主体となって「報告」なる処理を行うと言う意味なのか？）が明確でない。
　
（１−１３）請求項１、１０、１１に「前記後続のジョブ・インスタンスにアクションをインプリメントする」とあるが、その技術的意味・定義（「ジョブ・インスタンス」に対してどの様な処理を行うことを意味するのか？）が明確でない。（文言通りに解釈すれば、「後続のジョブ・インスタンス」と言う物に「アクション」という部品を「インプリメント」すると解されるが、係る解釈は技術的にみて不合理である。）
　
（１−１４）請求項１に「前記ジョブ・インスタンスの状態を確定するステップは、前記ジョブ・インスタンスは前記状態をモニタリングし、前記状態が所定の状態値に一致している時は前記ジョブ・インスタンスが前記プロセッサに対して後続のジョブ・インスタンスの実行依頼をし、前記プロセッサ上で起動している前記ＡＰＩによって前記後続のジョブ・インスタンス起動情報を格納する」とあるが、その意味（この文章の主語は何（「確定するステップ」？「ジョブ・インスタンス」？）なのか？「ジョブ・インスタンス」が「ジョブ・インスタンス」自身の状態をモニタしたり「後続のジョブ・インスタンスの実行依頼」をするとはどの様な事を意味するのか？　「確定するステップ」内に「実行依頼」のステップが有るのか？）が明確でない。また、発明の詳細な説明には、係る技術的事項の開示はなく、発明の詳細な説明を参酌してもその具体的事物を想定し得ず、その結果、請求項１〜９に係る発明の実施も、技術上の意義の理解も不可能である。
　
（１−１５）請求項１０に「前記ジョブ・インスタンスは前記状態をモニタし、前記状態が所定の状態値に一致している時は後続のジョブ・インスタンスがプロセッサに対して実行依頼され」とあるが、その技術的意味（「ジョブ・インスタンス」が「ジョブ・インスタンス」自身の状態をモニタするとはどの様な事を意味するのか？「後続のジョブ・インスタンスの実行依頼」は何がするのか？）が明確でない。また、発明の詳細な説明には、「ジョブ・インスタンス」が「ジョブ・インスタンス」自身の状態をモニタする如き事項の開示はなく、発明の詳細な説明を参酌してもその具体的事物を想定し得ず、その結果、請求項１０に係る発明の実施も、その技術上の意義の理解も不可能である。
　
（１−１６）請求項１１に「前記ジョブ・インスタンスの状態を確定することを可能とさせることは、前記ジョブ・インスタンスは前記状態をモニタリングし、前記状態が所定の状態値に一致している時は前記後続のジョブ・インスタンスがプロセッサに対して実行依頼され」とあるが、その意味（この文章の主語は何（「確定することを可能とさせること」？「ジョブ・インスタンス」？）なのか？「ジョブ・インスタンス」が「ジョブ・インスタンス」自身の状態をモニタするとはどの様な事を意味するのか？　「後続のジョブ・インスタンスの実行依頼」は何がするのか？）が明確でない。また、発明の詳細な説明には、「ジョブ・インスタンス」が「ジョブ・インスタンス」自身の状態をモニタする如き事項の開示はなく、発明の詳細な説明を参酌してもその具体的事物を想定し得ず、その結果、請求項１１に係る発明の実施も、その技術上の意義の理解も不可能である。
　
（１−１７）請求項３の限定は不合理である。（「プロセッサ」と「ジョブ待ち行列入れサブシステム」との相互の関係が請求項１と矛盾する。）
　
（１−１８）請求項４、５に「前記レジスタに格納するステップ」とあるが、「レジスタ」も「レジスタに格納するステップ」も前記されていない。
　
（１−１９）請求項４に「前記ジョブ・インスタンスに対するレジスタ・パラメータ」とあるが、その技術的意味・定義（「ジョブ・インスタンス」とどのような関係にあるパラメータで何処で何時どの様にして得られるパラメータなのか？）が、発明の詳細な説明を参酌しても、明確でない。
　
（１−２０）請求項４に「レジスタ・パラメータを確定する」とあるが、その技術的意味（「確定」とは「パラメータ」をどう処理することを意味するのか？）が明確でない。
　
（１−２１）請求項４に「循環プログラム」とあるが、その技術的意味・定義（如何なる構造、如何なる処理を行うプラグラムなのか？）が明確でない。
　
（１−２２）請求項４に「確定するために循環プログラムを用いるステップ」とあるが、その技術的意味・定義（「循環プログラム」と「確定」とはどの様な関係にあるのか？「循環プログラム」内に「確定」のステップがあると言う意味なのか？「確定」のステップから「循環プログラム」がコールされると言う意味なのか？）が明確でない。
　
（１−２３）請求項５に「前記ＡＰＩによって前記ジョブ・インスタンスをレジスタに格納するために」とあるが、その技術的意味・定義（「ジョブ・インスタンスをレジスタに格納する」とは一体どのような処理を意味するのか？請求項１の「ジョブ・インスタンス起動情報を格納するステップ」とどの様な関係の処理なのか？）が明確でない。
　
（１−２４）請求項８に「前記報告するステップは起動プログラムによって実行される」とあるが、その技術的意味・定義（「起動プログラム」とは如何なる処理を行うプログラムなのか？ＡＰＩとは別のプログラムなのか？ＡＰＩの一種なのか？）が明確でない。また、発明の詳細な説明には、段落【００４４】に当該事項と同様の記載があるのみで、これ以上に詳細に当該事項を説明する記載は見あたらない。
　
（１−２５）請求項９に「前記状態は完了状態であり」とあるが、「前記状態」とはどの「状態」を意味するのかが明確でない。
　
（１−２６）請求項９に「前記アクションは前記後続のジョブ・インスタンスに対して前記ステップの全てを実行するステップを含む」とあるが、その技術的意味・定義が明確でない。（「アクション」が「ステップ」を含む、及び、「ジョブ・インスタンスに対して」「実行する」なる表現は技術的に有意な解釈の不可能な表現である。）
　
　
（２）本願明細書の発明の詳細な説明中に、以下の（２−１）〜（２−５０）に示す如き、意味不明・不明確な記載が多数有るため、当業者と言えども、本願明細書の発明の詳細な説明の記載から、請求項１〜１１に係る発明を実施するためにはどのようなプログラムや装置等を作ればよいのかを理解することはできず、また、請求項１〜１１に係る発明の課題や効果等の技術上の意義を正確に理解することも不可能である。
　従って、この出願の発明の詳細な説明は、当業者が請求項１〜１１に係る発明を実施することができる程度に明確かつ十分に記載されていないもの（特許法第３６条第４項（実施可能要件）違反）であり、しかも、この出願の発明の詳細な説明は、請求項１〜１１に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないもの（特許法第３６条第４項（委任省令要件）違反）でもある。
　
（２−１）請求項１における。
「ジョブ・インスタンス起動情報を有するジョブ・インスタンス」
「アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンス起動情報を格納するステップ」
「前記ジョブ・インスタンスの状態を確定するステップは、前記ジョブ・インスタンスは前記状態をモニタリングし、前記状態が所定の状態値に一致している時は前記ジョブ・インスタンスが前記プロセッサに対して後続のジョブ・インスタンスの実行依頼をし、前記プロセッサ上で起動している前記ＡＰＩによって前記後続のジョブ・インスタンス起動情報を格納する」
請求項１０における、
「ジョブ・インスタンス起動情報を有するジョブ・インスタンス」
「アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンス起動情報を格納するデバイス」
「前記ジョブ・インスタンスは前記状態をモニタし、前記状態が所定の状態値に一致している時は後続のジョブ・インスタンスがプロセッサに対して実行依頼され、前記後続のジョブ・インスタンス起動情報が前記プロセッサ上で起動している前記ＡＰＩによって格納されることを特徴とするデバイス」
請求項１１における、
「ジョブ・インスタンス起動情報を有するジョブ・インスタンス」
「アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンス起動情報を格納することを可能とさせること」
「前記ジョブ・インスタンスの状態を確定することを可能とさせることは、前記ジョブ・インスタンスは前記状態をモニタリングし、前記状態が所定の状態値に一致している時は前記後続のジョブ・インスタンスがプロセッサに対して実行依頼され、前記後続のジョブ・インスタンス起動情報が前記プロセッサ上で起動している前記ＡＰＩによって格納される」
なる事は、本願明細書の発明の詳細な説明には記載も示唆もされていない。
　
（２−２）請求項１〜９記載の各「ステップ」、請求項１１記載の各「可能とさせる」ステップを具体的に如何に構成し、これらの間で如何なるデータを如何に受け渡すよう構成して請求項１〜９記載に係る発明を構成すればよいのかが、発明の詳細な説明に十分に開示されていない。（段落【００２８】以降には【図３】【図４】を用いて本願発明の実施例の説明がなされているが、ここには各ステップの漠然とした機能が開示されているだけで、各「ステップ」を実現するプログラムを、具体的に如何なるフローの処理で実現し、如何なるタイミングでどのプログラムを実行し、如何なるパラメータをどのプログラムに引き渡すのか等を明確に説明する記載が無い。）
　
（２−３）請求項１０記載の各「デバイス」を具体的に如何に構成し、これらを如何に接続して請求項１０に係る発明「システム」を構成すればよいのかが、発明の詳細な説明に十分に開示されていない。（段落【００１８】に「本実施形態では、ジョブそれ自身、及び他のファセットがソフトウェア（コンピュータ・プログラム）の使用によってインプリメントされるが、当業者はハードウェア等の任意の技術のいずれかを代わりに利用することも可能である。」とあるだけで、具体的に以下なるハードウエアと如何なるソフトウエアで各「デバイス」を構成し、これらを如何に接続して「システム」を構成すればよいのかが、何ら開示されていない。）
　
（２−４）本願請求項１〜１１記載の事項によって、所期の課題を解決し得る理由が、発明の詳細な説明において十分に説明されていない。（段落【０００７】〜【０００９】、【００２５】〜【００２７】に第１〜第３の問題が記載され、段落【００３６】に「主な利点は、すでに列挙した問題点、すなわち（１）リソースのコンテンション、（２）モニタ・ループの浪費、及び（３）シングル・ポイント障害が本発明のイベント駆動型モデルによって取り除かれる。」とある。
　しかしながら、
（第１の問題について）本願発明においても「ジョブ・インスタンスの状態を確定する」ために「モニタリング」なるものがなされ、当該「モニタリング」がどのような周期でどのようになされるのかは不明なのであるから、当該第１の問題が解決されるものではない。
（第２の問題について）また、本願発明においても「ジョブ・インスタンスの状態を確定する」ために「モニタリング」なるものがなされ、当該「モニタリング」がどのような周期でどのようになされるのかは不明なのであるから、当該第２の問題が解決されるものでもない。
（第３の問題について）また、本願発明においても「ジョブ・インスタンスの状態を確定する」ための「モニタリング」なるものがどのような手順でなされるのかの詳細は開示されておらず、障害発生時にどの様な対処がなされるかも不明なのであるから、当該第３の問題が解決されるものでもない。）
　
（２−５）段落【０００１】の「状態に基づいたシステム」とは如何なるシステムを意味するのか不明であり、この記載を正確に理解できない。
　
（２−６）段落【０００２】に「まず始めに、以下の説明の中で使用される名称、Ｓ／３９０及びＩＢＭは、InternationalBusinessMachinesCorporation（所在：Armonk,NewYork,U.S.A.）の登録商標である。また、Ｌｏｔｕｓは、その系列会社LotusDevelopmentCorporation、InternationalBusinessMachinesCorporation（所在：Armonk,NewYork,U.S.A.）の独立した系列会社の登録商標である。他の名称は、InternationalBusinessMachinesCorporation又は他の会社の登録商標又は製品名である。」とあるが、「Ｓ／３９０」も「ＩＢＭ」も「Ｌｏｔｕｓ」も以下の説明の中で使用されてはいない。
　
（２−７）段落【０００３】の「各ジョブは、各インスタンスが全体的なジョブのサブコンポーネントになっている多くのジョブ・インタンスを含むことができる。」なる記載中の「各ジョブ」、「全体的なジョブ」、「各インスタンス」と「サブコンポーネントになっている多くのジョブ・インタンス」の相互の関係（何が何に含まれているのか？）が明確でなく、この記載を正確に理解できない。
　
（２−８）段落【０００３】の「プロセッサに対して別々に実行依頼される各行列対」の「かけ算」とは、行列中の要素（スカラー）同士のかけ算を意味するのか？部分行列と部分行列のかけ算を意味するのかが明確でなく正確に理解できない。
　
（２−９）段落【０００３】の「ジョブの各インスタンス、及び最終結果の積が完了した後、マスタ・プロセス（オペレーティング・システムの一部でもある）が知らされなければならない。」は、主語と述語、修飾語と被修飾語の関係が錯綜しており理解不可能である。
　
（２−１０）段落【０００３】の「ジョブ全体の終了として、全てのジョブ・インスタンスが完了した後、再度マスタ・プロセスに制御が与えられ、新たなジョブを完了することができる。」なる記載は技術的に意味が不明の記載であり理解不可能である。（「新たなジョブ」とは「ジョブ全体」「全てのジョブ・インスタンス」とどの様な関係のものなのか？）
　
（２−１１）段落【０００３】〜【００１０】【００２１】〜【００２７】において使用される「ループ・モニタリング・デバイス」「モニタ・プログラム」「モニタリング・プログラム」「ループ・モニタリング・システム」等の用語の意味・相互の関連（それぞれが如何なるものを意味するのか？同じものを意味するのか？異なるものを意味するのか？等）が不明であり理解不可能である。
　
（２−１２）段落【０００５】の「このテンションのかかったウェブで、プロセッサは次のジョブ・インスタンスのために繰り返される。」は、技術的に意味不明の記載であり理解不可能である。
　
（２−１３）段落【０００６】の「ジョブ全体は、ジョブ・インスタンスの数に応じて、数マイクロ秒から多くの時間（例えば、７２時間）を費やして実行されなければならない。」、段落【００２４】の「ジョブ全体がジョブ・インスタンスの数に応じて、数マイクロ秒から多くの時間（例えば、７２時間）を費やして実行されなければならない。」は、技術的に意味不明の記載であり理解不可能である。
　
（２−１４）段落【０００７】、【００２５】の「このことの理由は、最初のジョブ・インスタンスの状態にモニタ・プログラムが戻る前に他のジョブ・インスタンス全ての状態がチェックされ、また最初のジョブ・インスタンスが既に完了し、モニタ・プログラムが復帰する前にプログラムがアイドル状態になる可能性さえも多いにあるからである。」は、意味不明の記載であり、理解不可能である。（「最初のジョブ・インスタンスの状態にモニタ・プログラムが戻る」「モニタ・プログラムが復帰する」とはどのような時を意味するのか？「他のジョブ・インスタンス全ての状態がチェックされ、また最初のジョブ・インスタンスが既に完了し」とはどのような状態を意味するのか？等が不明である。）
　
（２−１５）段落【０００８】の「第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス及びモニタ・プログラムが含まれる。」、段落【００２６】第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス１０４及びモニタ・プログラム１１８が含まれる。」は、意味不明の記載であり理解不可能である。（「ループ・モニタリング・デバイス」や「モニタ・プログラム」が何に「含まれる」のか？）
　
（２−１６）段落【０００８】に「プログラムは毎時間連続的に実行されてジョブを処理しなければならないことから、該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である。」と、段落【００２６】に「第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス１０４及びモニタ・プログラム１１８が含まれる。プログラムは毎時間連続的に実行されてジョブを処理しなければならないことから、該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である。」とあるが、その理由（「プログラムは毎時間連続的に実行されてジョブを処理しなければならないこと」と「該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である」ことの因果関係）が不明であり理解不可能である。
　
（２−１７）段落【００１１】に「【発明が解決しようとする課題】本発明は、プロセッサによる実行のためにジョブのジョブ・インスタンスを実行依頼し、状態モデルを用いて該ジョブ・インスタンスをモニタリングする方法、及び該方法を用いるシステムに関する。」とあるが、これは「課題」と認め得るような事項ではなく、この記載からは本願発明の技術上の意義を理解することは到底できない。
　
（２−１８）段落【００１３】の「プロセッサはジョブ待ち行列入れサブシステムとすることができる。」「レジスタに格納するステップは、ジョブ・インスタンスに対するレジスタ・パラメータを確定するために循環プログラムを用いるステップを含むことができる。」「レジスタに格納するステップは、ＡＰＩによってジョブ・インスタンスをレジスタに格納するためにジョブ・インスタンスのレジスタ・パラメータを確定し、さらにレジスタ・パラメータをＡＰＩに実行依頼するステップも含むことができる。」、段落【００１５】の「一実施形態例では、上記した状態は完了状態であり、またアクションは次のジョブ・インスタンスに対してステップ（ａ）から（ｅ）を実行するステップを含むものである。」は意味不明の記載であり理解不可能である。
　
（２−１９）段落【００１９】の「ジョブ全体そのものが実行依頼されるべきジョブの総計を含む。現実に、それはジョブ・インスタンスの総計を含むプログラムである。」は、意味不明の記載であり理解不可能である。
　
（２−２０）段落【００２０】の「ジョブの各インスタンスが完了し、最終結果が得られた後、マスタ・プロセス（同様にオペレーティング・システムの一部である）が伝えられなければならない。」は、意味不明の記載であり理解不可能である。
　
（２−２１）段落【００２０】の「モニタリング・プロセス（又は複数のプロセス）はすべてのジョブ・インスタンスが完了し、新たなジョブ・インスタンスが開始されることを理解しなければならない。」は、意味不明の記載であり理解不可能である。
　
（２−２２）段落【００２１】の「また、本実施形態では、ジョブ待ち行列入りサブシステム１０２、ループ・モニタリング・デバイス１０４，ジョブ・インスタンス１０８、及び実行依頼コマンド１０６はコンピュータ上で実行されるソフトウェアのインスタンス、もしくは代わりに一つのプログラム・モジュールから別のプログラム・モジュールに対する呼出である。」は、意味不明の記載であり理解不可能である。（「ジョブ待ち行列入りサブシステム１０２」、「ループ・モニタリング・デバイス１０４」，「ジョブ・インスタンス１０８、」が「呼出」であるという構成は技術常識からみて理解しうるものではない。）
　
（２−２３）段落【００２２】の「スクリプト１１０は、ジョブ待ち行列入りサブシステム１０２に実行依頼するために、ディスクからジョブ・インスタンス（ファイル）をフェッチするだろう。」なる記載、「実行依頼コマンド１０６は、フェッチ・プログラム１１２を用いてジョブ・インスタンス１０８をフェッチする。」なる記載、「ジョブ・コマンド・ファイル（不図示）があり、そこからフェッチ・コマンド１０６がジョブ・インスタンス１０８をフェッチする。」なる記載は互いにその内容が乖離しており理解不可能である。
　
（２−２４）段落【００２２】の「ジョブ・インスタンス１０８は、次に実行依頼プログラム１１４を介してジョブ待ち行列入りサブシステム１０２に掲示される。」なる記載の「ジョブ待ち行列入りサブシステム１０２に掲示される」とは如何なる処理を意味するのか不明であり理解不可能である。
　
（２−２５）段落【００２８】に「図３は、本発明の自己実行依頼ジョブを説明するためのブロック図である。」とあるが当該「自己実行依頼ジョブ」とは如何なるジョブを意味するの不明であり理解不可能である。
　
（２−２６）段落【００２８】に「イベント駆動型モデルの作成に供するコンポーネントは、（１）アプリケーション・プログラム・インタフェース（ＡＰＩ）、（２）レジスタ手続き３０８、（３）完了手続き３１０、（４）起動プログラム３０４、及び（５）循環プログラム３０６を含む。」とあるが、ここで用いられる「アプリケーション・プログラム・インタフェース（ＡＰＩ）」、「レジスタ手続き３０８」、「完了手続き３１０」、「起動プログラム３０４」、及び「循環プログラム３０６」とは如何なるカテゴリーのものなのか？（「装置」なのか？「プログラム」なのか？「設計思想」なのか？）が不明であり、これを如何に実現すればよいのかを理解することが不可能である。
　
（２−２７）段落【００２９】に「スクリプトは、ジョブ待ち行列入りサブシステム１０２に実行依頼するために、ディスクからジョブ・インスタンス（ファイル）をフェッチするだろう。」とある一方で、「実行依頼コマンド１０６は、フェッチ・プログラム１１２を用いてジョブ・コマンド・ファイルからジョブ・インスタンス１０８をフェッチする」ともあり、「フェッチ」の主体が複数有り、本願発明を如何に実現すればよいのかを理解することが不可能である。
　
（２−２８）段落【００２９】に「次に、ジョブ・インスタンス１０８は、実行依頼プログラム１１４を介してジョブ待ち行列入りサブシステム１０２に掲示される」とある一方で、「ジョブ待ち行列入りサブシステム１０２は、関係した計算を行うオペレーティング・システムの一部（不図示）に対してジョブ・インスタンス１０８を実行依頼する。」ともあり、「ジョブ待ち行列入りサブシステム１０２」はそもそも如何なる種類のもので（掲示手段なのか？プログラムなのか？）、如何なる機能作用のものなのかが不明であり、当該「ジョブ待ち行列入りサブシステム１０２」を如何に実現すればよいのかを理解することが不可能である。
　
（２−２９）段落【００３０】に「実行依頼コマンド１０６の実行と同時に、または実行依頼コマンド１０６の実行とは別々に、循環プログラム３０６が実行される。」とあるが、これをどの様に実現するのか（「実行依頼コマンド１０６」内に「循環プログラム３０６」を実行する機能を設けるのか？「実行依頼コマンド」と「循環プログラム」の「実行」の双方をスクリプトに書くのか？）が不明であり、当該機能を如何に実現すればよいのかを正確に理解することが不可能である。
　
（２−３０）段落【００３０】に「循環プログラム３０６は、実行依頼コマンド１０６と協働し、かつ対話する機能であり、そのため概念的に実行依頼コマンド１０６を「循環（ラップ・アラウンド）する」という。循環プログラムは、ジョブ・インスタンス１０８のレジスタ・パラメータを確定し、このレジスタ・パラメータをＡＰＩプログラム３０２に実行依頼する。」とあるが、「協働し」とはどう動作することを意味するのか？「プログラムが」「機能」であるとはどの様なことを意味するのか？、「そのため概念的に実行依頼コマンド１０６を「循環（ラップ・アラウンド）する」とは如何なることを説明しているのか？「ジョブ・インスタンス１０８のレジスタ・パラメータ」とは如何なるパラメータなのか？これを「確定」するとは如何なる処理を意味するのか？「このレジスタ・パラメータをＡＰＩプログラム３０２に実行依頼する」とは如何なる処理を意味するのか？「パラメータ」を「実行」するとは何を意味しているのか？等々が不明であり、当該「循環プログラム」を如何に実現すればよいのかを理解することが不可能である。
　
（２−３１）段落【００３０】に「循環プログラムは・・・レジスタ・パラメータを確定し、・・・に実行依頼する。」とある一方で「このことはレジスタ手続き３０８の実行によって行われる。」とあり、さらに段落【００３１】では「ＡＰＩプログラム３０２は、ジョブ状態（status又はstate）を確定するために使用される。」ともあり、「確定」や「実行依頼」が「循環プログラム」が行うのか「レジスタ手続き」が行うのか「ＡＰＩプログラム」が行うのか不明であり、「確定」なる機能を如何に実現すればよいのかを理解することが不可能である。
　
（２−３２）段落【００３１】に「プロセッサ上で実行され、かつジョブ待ち行列入れサブシステム１０２と対話するＡＰＩプログラム３０２」とあり、「ジョブ待ち行列入れサブシステム１０２」と「ＡＰＩプログラム３０２」は別個の物として説明されているが、図３においては「ジョブ待ち行列入れサブシステム１０２」内に「ＡＰＩ」が記載されており、矛盾する。このため、これを如何に実現すればよいのかを正確に理解することが不可能である。
　
（２−３３）段落【００３１】に「例えば（１）開始状態（ジョブ・インスタンスが開始された）、（２）実行状態（ジョブ・インスタンスが実行されている）」とあるが「ジョブ・インスタンスが開始された」状態と「ジョブ・インスタンスが実行されている」状態とは何がどう異なる状態なのかが不明である。このため、これを如何に実現すればよいのかを正確に理解することが不可能である。
　
（２−３４）段落【００３１】に「ジョブ・インスタンスに対してプロセッサが不完全」とあるが、これは何を意味しているのかが不明である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　
（２−３５）段落【００３２】に「起動プログラムがプログラム１１６を実行して次のジョブ・インスタンスを起動する。」とあるが、この記載からは「起動プログラム」「プログラム１１６」「ジョブ・インスタンス」が、それぞれ如何なる処理をすることを意味しているのかが不明である。このため、これを如何にして実現すればよいのかを理解することが不可能である。
　
（２−３６）段落【００３２】に「その結果、起動プログラム３０４（及びそれに付随するプログラム・モジュール）は休止状態に入り」とあるが「付随するプログラム・モジュール」とはどのプログラムなのかが不明である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　
（２−３７）段落【００３２】に「ジョブ待ち行列入りサブシステム１０２の状態を続けて実行」とあるが、これは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　
（２−３８）段落【００３３】に「レジストレーション手続き」とあるがこれは何か（別個のプログラム？「レジスタ手続き３０８」のこと？）が不明確である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　
（２−３９）段落【００３３】に「レジストレーション手続きによって、ＡＰＩがジョブ・インスタンスの記録を保持することを許す。」とあるが、これは何が如何なる処理をすることを意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　
（２−４０）段落【００３３】に「付録１（１枚）は模範的な起動プログラムを含む。付録２（３枚）は模範的な循環プログラム１０６を含み、実行依頼コマンド・モジュールに対して呼出する機能が含まれる。ここに示している実施形態では、それらのプログラムはＣ言語によって記述されているが、当業者ならば任意のプラットホームで実行可能である任意の言語を使用することが可能であること、また代わりに別のアプローチの使用（例えばハードウェアの使用）が可能であることを容易に理解することができるだろう。」とあるが「付録１」「付録２」とは何を意味するのかが不明である。
　
（２−４１）段落【００３４】の「出力ファイル」とはどのファイルなのかが不明である。このため、本願発明を如何に実現すればよいのかを理解することが不可能である。
　
（２−４２）段落【００３５】に「一実施形態では、実際のプログラム出力は、チェック・プログラム（不図示）を実行することによって確定することができる。」とあるがこの「実際のプログラム出力」とはどの出力なのかが不明である。このため、本願発明を如何に実現すればよいのかを理解することが不可能である。
　
（２−４３）段落【００３５】の「このチェック・プログラムは、出力結果をどこで見つけるかについての所定の情報である。」は合理的解釈の不可能な記載であり、当該「チェック・プログラム」を如何に実現すればよいのかを理解することが不可能である。
　
（２−４４）段落【００３５】に「起動プログラム３０４はチェック・プログラムを呼出する。」とあるが、従来例の「ポーリング」とどう異なるのかが明確に説明されていない。このため、当該「チェック・プログラム」や「呼出」機能を如何に実現すればよいのかを理解することが不可能である。
　
（２−４５）段落【００３５】に「言い換えると、ジョブ・インスタンス識別子及び結果を見出すための出力の位置を使用する。」とあるが、これは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　
（２−４６）段落【００３５】に「そして、結果が良好かどうかを判断する。もし、結果が良好であるならば、起動プログラム３０４は処理を続けることを許される。」とあるが、「良好」とはどのような状態を意味するのか？「処理を続けることを許される。」とはどのような状態・動作を意味するのか？段落【００３２】の「休止状態」とはどのような関係の動作なのか？等が明確に説明されていない。
　
（２−４７）段落【００３６】に「また、本発明では、循環プログラム３０６が存在することから、実行依頼コマンド１０６がジョブ全体（すべてのジョブ・インスタンスを含む）に対して１度だけ実行される。」とあるが、如何なる因果関係によってこのような作用効果が生じるのかが明確に説明されていない。このため、発明の技術上の意義を正確に理解することができない。
　
（２−４８）段落【００３７】に「起動プログラムは、完了状態を直接受け取り、該完了状態を受け取ると直ちに新たな開始状態をインプリメントする。」とあるがこれは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　
（２−４９）段落【００３８】〜【００４２】にかけて図５を用いて、従来のシステムと本発明のシステムとを比較しているが、この図は何のフローを示しているのかが明確に説明されていない。このため、発明の技術上の意義を正確に理解することができない。
　
（２−５０）段落【００３８】に「図５（ａ）のステップ５０２は、図１の従来のシステムにおいて、実行中にジョブ・コマンド・ファイルを生成する。図５（ｂ）のステップ５１０では、図３の本発明のシステムにおいて、ジョブ・コマンド・ファイルが一度だけ生じ、いかなる時でも任意の数のプロセスによって使用することができる。」と、
段落【００３９】に「図５（ａ）のステップ５０４では、図１の従来のシステムにおいて、一つのジョブの複数のジョブ・インスタンスがループ状になって開始され、かつ実行され、各新たなジョブ・インスタンスを連続して受け取るために続行される。図５（ｂ）のステップ５１２では、図３の本発明のシステムにおいて、しかし、循環プログラム３０６のため、複数のジョブ・インスタンスがジョブの開始時に一度に開始される。」と、
段落【００４０】に「図５（ａ）のステップ５０６では、ジョブ・インスタンスは上記したポーリング方法によってモニタされる。しかし、ステップ５１４ではＡＰＩ３０２と起動プログラム３０４との間の相互作用によってジョブ・インスタンスがイベント駆動される。」と、
段落【００４１】に「図５（ａ）のステップ５０８では、単一モニタ・ループはすべてのジョブ・インスタンスの結果がログに記録されたことを確認しなければならない。しかし、ステップ５１６では、ジョブ・インスタンスが完了した後、新たなジョブ・インスタンスが開示される前に、起動プログラムがジョブ・ログ・プログラムを開始することができる。ここで再び、ジョブ・ログ・プログラムが休止状態にあるイベント駆動型モデルがあり、ジョブ・インスタンスが完了する時、起動プログラムによってのみ実行される。ログ・コレクタはジョブ・インスタンス出力ファイルをクリーン・アップすることができ、あるいはある時間間隔毎に一回ログに記録する。ジョブ・ログ情報はジョブ・コマンド・ファイルに含めることができる。タイムスタンプ・オプションは、ジョブの現在の実行からどれぐらい長くログを隔離するかを明示することに使用することができる。」と、
段落【００４２】に「最後に、図５（ａ）は次のジョブ・インスタンスを検索し、かつ処理するために、ループ・パックを含む。しかし、本発明では、ジョブ情報は一つのジョブ・インスタンスから次のジョブ・インスタンスへラップされて渡されるので、図５（ｂ）ではループ・バックは必要ではない。」
とあるが、なぜ（どのような因果関係から）このようなことが言えるのかが明確に説明されていない。そしてこのため、発明の技術上の意義を正確に理解することができない。
　
　
　なお、上記平成１７年１月１３日付けの手続補正がなされた明細書又は図面における請求項１〜１１に記載した事項は願書に最初に添付した明細書又は図面に記載した事項の範囲内にないことが明らかであり、また、この出願は出願内容が著しく不明確であるから、請求項１〜１１に係る発明については、新規性、進歩性等の特許要件についての審理を行っていない。
　
　
＜補正等の示唆＞
　発明者が如何なる技術的手段を如何に組み合わせたものを発明したのかを正確に確認した上で、明細書の記載内容や出願内容を全体的に再検討されたし。
　なお、平成２０年２月２０日付けの回答書内で提示される補正案も、新規事項を導入するものであり（「ジョブ・インスタンス活動情報」なるものを登録したり比較したりすることも当初明細書等には記載も示唆もない。また、本願発明の１つのジョブが多数のジョブ・インスタンスで構成されることの直接的な記載は当初明細書等には見あたらず、さらに、モニタリングが「自動的かつ継続的」である旨の記載も当初明細書等には見あたらない。）、しかも、その記載内容も依然として不明確なものである。
　また、上記で指摘した不備以外にも奇異な記載（例えば、段落【０００３】の「模範的」、段落【０００９】、【００２７】の「（しばしば漠然として）」、段落【００１９】の「実行依頼（すなわち、行列対）」、段落【００２１】の「高階層の概観」「本質的に概念であり」、段落【００４４】に「まとめ」として記載の当初明細書の特許請求の範囲の記載等）や誤記等（【０００４】の「容易いなこと」、段落【０００５】の「用いて、、」等）が散見されるので、これらに付いても再考されたし。
　
　明細書を補正した場合は、補正により記載を変更した個所に下線を引くこと。
　補正は、この出願の出願当初の明細書又は図面に記載した事項のほか、出願当初の明細書又は図面に記載した事項から自明な事項の範囲内で行わなければならない。
　補正の際には、意見書で、各補正事項について補正が適法なものである理由を、根拠となる出願当初の明細書等の記載箇所を明確に示したうえで主張されたい。
　なお、上記の補正等の示唆は法律的効果を生じさせるものではない。明細書及び図面をどのように補正するかは出願人が決定すべきものである。
＜・・・後略・・・＞」
　
　
３．手続補正・意見書の内容
　これに対して、請求人は、上記平成２１年２月１８日付けの手続補正書（以下「本補正」と記す。）により、
（１）【特許請求の範囲】を
「【請求項１】　
　プロセッサ上で活動するオペレーティング・システムの一部であるジョブ待ち行列入れサブシステム１０２による実行のためのジョブのジョブ・インスタンスを実行依頼し、該ジョブ・インスタンスを状態モデルを用いてモニタリングする方法であって、
　（ａ）ジョブ・インスタンスをフェッチするステップと、
　（ｂ）ジョブ待ち行列入れサブシステムに対して前記ジョブ・インスタンスを実行依頼するステップと、
　（ｃ）アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンスをレジスタに格納するステップと、
　（ｄ）ジョブ・インスタンスの状態を確定するステップと、
　（ｅ）次のジョブ・インスタンスにアクションをインプリメントするためにアプリケーションに対して前記状態を報告するステップとを有し、
前記ジョブ・インスタンスはジョブ・コマンド・ファイルからフェッチされ、
前記レジスタに格納するステップは、前記ジョブ・インスタンスに対するレジスタ・パラメータを確定するために循環プログラムを用いるステップが含まれ、前記ＡＰＩによって前記ジョブ・インスタンスをレジスタに格納するために前記ジョブ・インスタンスのレジスタ・パラメータを確定し、該レジスタ・パラメータを前記ＡＰＩに実行依頼するステップが含まれることを特徴とするジョブ・インスタンスの実行依頼及びモニタリング方法。
　【請求項２】　
　前記確定するステップは、
　開始状態を確定するステップ、
　実行状態を確定するステップ、
　完了状態を確定するステップ、
　中止状態を確定するステップ、及び
　アイドル状態を確定するステップのいずれかを含むことを特徴とする請求項１に記載のジョブ・インスタンスの実行依頼及びモニタリング方法。
　【請求項３】　
　前記報告するステップは起動プログラムによって実行されることを特徴とする請求項１に記載のジョブ・インスタンスの実行依頼及びモニタリング方法。」と補正するとともに、
　
（２）段落【０００３】の
「模範的な」を「典型的な」と、「されなれなければならない」を「されなければならない」と、
　
（３）段落【０００４】の「容易いなこと」を「容易なこと」と、
　
（４）段落【０００５】の「用いて、、」を「用いて、」と、
　
（５）段落【０００９】の「（しばしば漠然として）」を「（しばしば永久に）」と、
　
（６）段落【００１９】の「実行依頼（すなわち、行列対）された後」を「（すなわち、行列対）が、実行依頼された後」と、
　
（７）段落【【００２１】の「本質的に概念であり」を「概念図であり」に、
「制限されている見るべきではない」を「制限されていると見るべきではない」と、
　
（８）段落【００２２】の「ジョブ待ち行列入りサブシステム」を「ジョブ待ち行列入れサブシステム」と、
　
（９）段落【００２７】の「（しばしば永久に）」を「（しばしば永久に）」と、
　
（１０）段落【００４４】を
「まとめとして、本発明の構成に関して以下の事項を開示する。
プロセッサ上で活動するオペレーティング・システムの一部であるジョブ待ち行列入れサブシステム１０２による実行のためのジョブのジョブ・インスタンスを実行依頼し、該ジョブ・インスタンスを状態モデルを用いてモニタリングする方法であって、
　（ａ）ジョブ・インスタンスをフェッチするステップと、
　（ｂ）ジョブ待ち行列入れサブシステムに対して前記ジョブ・インスタンスを実行依頼するステップと、
　（ｃ）アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンスをレジスタに格納するステップと、
　（ｄ）ジョブ・インスタンスの状態を確定するステップと、
　（ｅ）次のジョブ・インスタンスにアクションをインプリメントするためにアプリケーションに対して前記状態を報告するステップとを有し、
前記ジョブ・インスタンスはジョブ・コマンド・ファイルからフェッチされ、
前記レジスタに格納するステップは、前記ジョブ・インスタンスに対するレジスタ・パラメータを確定するために循環プログラムを用いるステップが含まれ、前記ＡＰＩによって前記ジョブ・インスタンスをレジスタに格納するために前記ジョブ・インスタンスのレジスタ・パラメータを確定し、該レジスタ・パラメータを前記ＡＰＩに実行依頼するステップが含まれることを特徴とするジョブ・インスタンスの実行依頼及びモニタリング方法。
（２）　
　前記確定するステップは、
　開始状態を確定するステップ、
　実行状態を確定するステップ、
　完了状態を確定するステップ、
　中止状態を確定するステップ、及び
　アイドル状態を確定するステップのいずれかを含むことを特徴とする（１）に記載のジョブ・インスタンスの実行依頼及びモニタリング方法。
（３）　
　前記報告するステップは起動プログラムによって実行されることを特徴とする（１）に記載のジョブ・インスタンスの実行依頼及びモニタリング方法。」と補正した。
　
　また、請求人は、上記平成２１年２月１８日付けの意見書において、以下の通り意見を述べている。
「【意見の内容】
（１）本願発明は、平成１８年１月３１日付けの手続補正は、願書に最初に添付した明細書又は図面に記載された事項の範囲内に記載されておらず特許法第１７条の２第３項の規定する要件を満たさず（理由１）、発明の詳細な説明及び図面の記載不備により同法第３６条第４項及び第６項第１号及び第２号に規定する要件を満たさず（理由２）、特許を受けることはできないとの拒絶理由通知を受けたが、これらに対して下記の通り意見を述べる
（２）●理由１に対して
審判官殿の指摘に、段落【００３０】には
「循環プログラムは、ジョブ・インスタンス１０８のレジスタ・パラメータを確定し、このレジスタ・パラメータをＡＰＩプログラム３０２に実行依頼する。このことはレジスタ手続き３０８の実行によって行われる。」には、「ジョブ・インスタンス」が「ジョブ・インスタンス起動情報」なるも、これを「ＡＰＩ」によって「格納」する事を示唆するものとは到底認め得るものではないとの指摘、しかも、「ジョブ・インスタンス」が「状態をモニタリング」したり「後続のジョブ・インスタンスの実行依頼をし」たりすることは、当初明細書には微塵も記載されてはいないとの指摘はその通りであると考える。
したがって、出願当初の特許請求の範囲の記載を基礎として、原請求請１の記載に原請求請２〜５に記載の発明特定事項（段落２８〜３０の内容）を追加した新たな請求請１、請求請２（補正前請求請７、段落３１）、請求請３（補正前請求請８、段落３２）とする特許請求の範囲の補正を行った。
◎本願発明の内容の補足説明
この発明特定事項を変更追加することにより、従来の「ジョブ実行依頼システム」（段２１〜２４、図１及び図２）の次の技術課題（段落３６）、
・リソースのコンテンション（段落２５）、
・モニタ・ループの浪費によるプロセッサ・インテンシブ（段落２６）
・シングル・ポイント障害よるインスタンス全ての停止（段落２７）
を解消できるために、
コマンド実行１０６をジョブ全体（ジョブインスタンスの集合）に一度だけ発行する循環プログラム３０６と、ジョブ・インスタンスに次の実行依頼を発行する起動プログラムとを含む構成を有する。この特徴的な発明特定事項は「前記ジョブ・インスタンスが前記ジョブ・インスタンスが実行中の前記状態を自動的かつ継続的にモニタリングして、前記状態が所定の状態値に一致する場合に前記システムに対して後続のジョブ・インスタンスの前記実行依頼ステップ（ｃ）を実行」する点である。かかるモニタ・ループを有する「ジョブ実行依頼システム」の課題を解決するために、本願発明はイベント駆動型の「ジョブ実行依頼システム」は、（１）アプリケーション・プログラム・インタフェース（ＡＰＩ）、（２）レジスタ手続き３０８、（３）完了手続き３１０、（４）起動プログラム３０４、及び（５）循環プログラム３０６を含む（段落２８）。本発明のイベント駆動型モデルの「ジョブ・インスタンスを状態モデルを用いてモニタリングする方法」は、『起動プログラム３０４（及びそれに付随するプログラム・モジュール）は休止状態に入り、ジョブ待ち行列入りサブシステム１０２の状態を続けて実行したり、あるいはポーリングすることはない。』（段落３２）ことより、従来の大規模な行列計算における課題（１．リソースのコンテンション、２．モニタ・ループの浪費によるプロセッサ・インテンシブ、３．シングル・ポイント障害よるインスタンス全ての停止）などを解消できる有利な効果を奏する。
　
●理由２に対して、審査官殿の補正等の示唆に従い以下の通り誤記を正す補正を行った。
１．段落３の語句「模範的」を「典型的」に変更した。
２．「（しばしば漠然として）」を「（しばしば永久に）」（段落９、２７）に変更した。
３．段落１９の「（すなわち、行列対）」を「ジョブの各インスタンス」の直後に挿入する変更を行った。
４．段落２１の「高階層の概観」及び「本質的に概念であり」を単に「概観」及び「概念図」と表現した。
５.段落４４の記載を補正後の特許請求の範囲の記載と整合させる記載とした。
６.段落４、５及び２２の誤記を正した。
（３）以上により、審判長殿の指摘の理由は解消したものと考える。よって、本願発明は、特許法第１７条の２第３項（理由１）、及び、特許法第３６条第６項第１号及び第２号（理由２）に記載された要件を満たさずに特許を受けることができないとの拒絶理由には該当するものではないと確信しますので、審判長殿におかれましては本件を再度ご審理下さり、すみやかに特許審決のほどお願いする次第である。」
　
　
４．判断
　以下に、本補正後の明細書の記載が、上記平成２０年１１月１４日付けの拒絶理由通知書の理由２．において指摘した不備が解消されているものであるか否かについて検討する。
　
＜理由２．（１−１）で指摘した不備について＞
　本補正後の請求項１の記載においても、「ジョブ・インスタンスの実行依頼及びモニタリング方法」なる記載があるところ、これがコンピュータを利用する方法、コンピュータ内部で実行される方法のいずれの発明であるのかは依然として明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−２）で指摘した不備について＞
　本補正後の請求項１の記載においても、「フェッチするステップ」「実行依頼するステップ」「格納するステップ」「確定するステップ」「インプリメントするために」「報告するステップ」等種々のステップが記載されているが、依然としてその主体（「人間」？「プロセッサ」？「システム」？「デバイス」？「プログラム」？「ＡＰＩ」？「インスタンス」？「アプリケーション」？）が明確でない。また、該主体がいずれであっても所期の課題を解決し所望の作用効果を奏し得ることを裏付けるような記載は、本願発明の詳細な説明には見いだせない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−４）で指摘した不備について＞
　本補正後の請求項１の記載においても「状態モデルを用いてモニタリングする」との記載があるが、その技術的意味（単に「状態モデル」を念頭に設計すると言う程度の意味なのか？「状態モデル」のデータを記憶手段内に保有してこのデータにアクセスして「モニタリング」なる処理をするのか？）が、依然として明確でない。またこのため、発明の範囲（単に「モニタリングする」ものとはどう相違し、どう区別（線引き）されるのか？）が明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−８）で指摘した不備について＞
　本補正後の請求項１は「アプリケーション・プログラム・インタフェース（ＡＰＩ）によって前記ジョブ・インスタンス起動情報を格納する」、「ＡＰＩのところで」「確定する」、「ＡＰＩによって」「報告」する等の表現の無いものとなったものの、本補正後の請求項１記載の「前記ジョブ・インスタンスをレジスタに格納する」「該レジスタ・パラメータを前記ＡＰＩに実行依頼する」との記載からは、当該「ＡＰＩ」によって如何なる処理がなされるのかが明確でないため、依然として請求項１の記載は発明として明確なものにはなっていない。
　
＜理由２．（１−９）で指摘した不備について＞
　上記当審拒絶理由通知時における「ジョブ・インスタンス起動情報を格納する」なる記載に対応する記載として、本補正後の請求項１においては「ジョブ・インスタンスをレジスタに格納する」なる記載があるところ、係る記載からは、依然として、「ジョブ・インスタンスをレジスタに格納する」とは「ＡＰＩ」が如何なる情報処理を行うこと意味するのか（何所にどの様に格納するのか？）が明確でない。しかも、発明の詳細な説明には係る技術的事項を詳細に説明する記載はないため、発明の詳細な説明を参酌しても、当業者がその具体的事物を想定することができるものでもない。
　また、この点に関して意見書等での釈明もなされていない。
　なお、該「ジョブ・インスタンスをレジスタに格納する」なる記載は、原審における上記平成１６年７月９日付けの拒絶理由通知の（理由２）Ａ．においてその不備を指摘されていた記載であり、これと同じ記載に戻す本補正は、これが特許法第１７条の２第３項違反の拒絶理由を回避するための補正であったとしても、到底同法第３６条第６項第２号違反の拒絶理由を解消し得るものではない。
　
＜理由２．（１−１１）で指摘した不備について＞
　本補正後の請求項１においても「ジョブ・インスタンスの状態を確定する」との記載があるが、依然としてその技術的意味が明確でない。（文言通りに解釈すると何らかの手段が「ジョブ・インスタンス」に対して働きかけをしてその「ジョブ・インスタンス」を制御して「状態を確定」するものと解されるが、そのような動作に技術的意義は見いだせない。）また、係る事項は発明の詳細な説明にも記載されていない。
　また、この点に関して意見書等での釈明もなされていない。
　なお、この点は原審における上記平成１６年７月９日付けの拒絶理由通知の（理由２）Ｂ．においてもその不備を指摘され、しかも拒絶査定においても依然として解消していない旨を指摘されていた不備である。
　
＜理由２．（１−１３）で指摘した不備について＞
　上記当審拒絶理由通知時における「前記後続のジョブ・インスタンスにアクションをインプリメントする」に対応する記載として、本補正後の請求項１に「次のジョブ・インスタンスにアクションをインプリメントする」あるが、その技術的意味・定義（「ジョブ・インスタンス」に対してどの様な処理を行うことを意味するのか？）が依然として明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　なお、この点も原審における上記平成１６年７月９日付けの拒絶理由通知の（理由２）Ｃ．においてその不備を指摘され、しかも拒絶査定においても依然として解消していない旨を指摘されていた不備である。
　
＜理由２．（１−１９）で指摘した不備について＞
　本補正後の請求項１に「前記ジョブ・インスタンスに対するレジスタ・パラメータ」なる記載があるところ、依然としてその技術的意味・定義（「ジョブ・インスタンス」とどのような関係にあるパラメータで何処で何時どの様にして得られるパラメータなのか？）が、発明の詳細な説明を参酌しても、明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　なお、この点も原審における上記平成１６年７月９日付けの拒絶理由通知の（理由２）Ｅ．においてその不備を指摘され、しかも拒絶査定においても依然として解消していない旨を指摘されていた不備である。
　
＜理由２．（１−２０）で指摘した不備について＞
　本補正後の請求項１においても「レジスタ・パラメータを確定する」なる記載があるところ、依然としてその技術的意味（「確定」とは「パラメータ」をどう処理することを意味するのか？）が明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−２１）で指摘した不備について＞
　本補正後の請求項１においても「循環プログラム」なる記載があるところ、依然としてその技術的意味・定義（如何なる構造、如何なる処理を行うプラグラムなのか？）が明確でない。
　なお、この点も原審における上記平成１６年７月９日付けの拒絶理由通知の（理由２）Ｅ．においてその不備を指摘され、しかも拒絶査定においても依然として解消していない旨を指摘されていた不備である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−２２）で指摘した不備について＞
　本補正後の請求項１においても「確定するために循環プログラムを用いるステップなる記載があるところ、依然としてその技術的意味・定義（「循環プログラム」と「確定」とはどの様な関係にあるのか？「循環プログラム」内に「確定」のステップがあると言う意味なのか？「確定」のステップから「循環プログラム」がコールされると言う意味なのか？）が明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−２３）で指摘した不備について＞
　本補正後の請求項１においても「前記ＡＰＩによって前記ジョブ・インスタンスをレジスタに格納するために」なる記載があるところ、依然としてその技術的意味・定義（「ジョブ・インスタンスをレジスタに格納する」とは一体どのような処理を意味するのか？）が明確でない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（１−２４）で指摘した不備について＞
　本補正後の請求項３においても「前記報告するステップは起動プログラムによって実行される」とあるところ、依然としてその技術的意味・定義（「起動プログラム」とは如何なる処理を行うプログラムなのか？ＡＰＩとは別のプログラムなのか？ＡＰＩの一種なのか？）が明確でない。また、発明の詳細な説明には、段落【００４４】に当該事項と同様の記載があるのみで、これ以上に詳細に当該事項を説明する記載は見あたらない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２）で指摘した不備について＞
　依然として、請求項１〜３記載の各「ステップ」を具体的に如何に構成し、これらの間で如何なるデータを如何に受け渡すよう構成して請求項１〜３記載に係る発明を構成すればよいのかが、発明の詳細な説明に十分に開示されていない。（段落【００２８】以降には【図３】【図４】を用いて本願発明の実施例の説明がなされているが、ここには各ステップの漠然とした機能が開示されているだけで、各「ステップ」を実現するプログラムを、具体的に如何なるフローの処理で実現し、如何なるタイミングでどのプログラムを実行し、如何なるパラメータをどのプログラムに引き渡すのか等を明確に説明する記載が無い。）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４）で指摘した不備について＞
　依然として、本願請求項１〜３記載の事項によって、所期の課題を解決し得る理由が、発明の詳細な説明において十分に説明されていない。（段落【０００７】〜【０００９】、【００２５】〜【００２７】に第１〜第３の問題が記載され、段落【００３６】に「主な利点は、すでに列挙した問題点、すなわち（１）リソースのコンテンション、（２）モニタ・ループの浪費、及び（３）シングル・ポイント障害が本発明のイベント駆動型モデルによって取り除かれる。」とある。
　しかしながら、
（第１の問題について）本願発明における「ジョブ・インスタンスの状態を確定するステップ」がどのような実現手段でなされるのかは不明なのであるから、当該第１の問題が解決されるものではない。
（第２の問題について）また、本願発明における「ジョブ・インスタンスの状態を確定するステップ」がどのような実現手段でなされるのかは不明なのであるから、当該第２の問題が解決されるものでもない。
（第３の問題について）また、本願発明においても「ジョブ・インスタンスの状態を確定するステップ」がどのような手順でなされるのかの詳細は開示されておらず、障害発生時にどの様な対処がなされるかも不明なのであるから、当該第３の問題が解決されるものでもない。）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−５）で指摘した不備について＞
　依然として、段落【０００１】の「状態に基づいたシステム」とは如何なるシステムを意味するのか不明であり、この記載を正確に理解できない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−６）で指摘した不備について＞
　依然として、段落【０００２】に「まず始めに、以下の説明の中で使用される名称、Ｓ／３９０及びＩＢＭは、InternationalBusinessMachinesCorporation（所在：Armonk,NewYork,U.S.A.）の登録商標である。また、Ｌｏｔｕｓは、その系列会社LotusDevelopmentCorporation、InternationalBusinessMachinesCorporation（所在：Armonk,NewYork,U.S.A.）の独立した系列会社の登録商標である。他の名称は、InternationalBusinessMachinesCorporation又は他の会社の登録商標又は製品名である。」とあるが、「Ｓ／３９０」も「ＩＢＭ」も「Ｌｏｔｕｓ」も以下の説明の中で使用されてはいない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−７）で指摘した不備について＞
　依然として、段落【０００３】の「各ジョブは、各インスタンスが全体的なジョブのサブコンポーネントになっている多くのジョブ・インタンスを含むことができる。」なる記載中の「各ジョブ」、「全体的なジョブ」、「各インスタンス」と「サブコンポーネントになっている多くのジョブ・インタンス」の相互の関係（何が何に含まれているのか？）が明確でなく、この記載を正確に理解できない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−８）で指摘した不備について＞
　依然として、段落【０００３】の「プロセッサに対して別々に実行依頼される各行列対」の「かけ算」とは、行列中の要素（スカラー）同士のかけ算を意味するのか？部分行列と部分行列のかけ算を意味するのかが明確でなく正確に理解できない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−９）で指摘した不備について＞
　依然として、段落【０００３】の「ジョブの各インスタンス、及び最終結果の積が完了した後、マスタ・プロセス（オペレーティング・システムの一部でもある）が知らされなければならない。」は、主語と述語、修飾語と被修飾語の関係が錯綜しており理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１０）で指摘した不備について＞
　依然として、段落【０００３】の「ジョブ全体の終了として、全てのジョブ・インスタンスが完了した後、再度マスタ・プロセスに制御が与えられ、新たなジョブを完了することができる。」なる記載は技術的に意味が不明の記載であり理解不可能である。（「新たなジョブ」とは「ジョブ全体」「全てのジョブ・インスタンス」とどの様な関係のものなのか？）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１１）で指摘した不備について＞
　依然として、段落【０００３】〜【００１０】【００２１】〜【００２７】において使用される「ループ・モニタリング・デバイス」「モニタ・プログラム」「モニタリング・プログラム」「ループ・モニタリング・システム」等の用語の意味・相互の関連（それぞれが如何なるものを意味するのか？同じものを意味するのか？異なるものを意味するのか？等）が不明であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１２）で指摘した不備について＞
　依然として、段落【０００５】の「このテンションのかかったウェブで、プロセッサは次のジョブ・インスタンスのために繰り返される。」は、技術的に意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１３）で指摘した不備について＞
　依然として、段落【０００６】の「ジョブ全体は、ジョブ・インスタンスの数に応じて、数マイクロ秒から多くの時間（例えば、７２時間）を費やして実行されなければならない。」、段落【００２４】の「ジョブ全体がジョブ・インスタンスの数に応じて、数マイクロ秒から多くの時間（例えば、７２時間）を費やして実行されなければならない。」は、技術的に意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１４）で指摘した不備について＞
　依然として、段落【０００７】、【００２５】の「このことの理由は、最初のジョブ・インスタンスの状態にモニタ・プログラムが戻る前に他のジョブ・インスタンス全ての状態がチェックされ、また最初のジョブ・インスタンスが既に完了し、モニタ・プログラムが復帰する前にプログラムがアイドル状態になる可能性さえも多いにあるからである。」は、意味不明の記載であり、理解不可能である。（「最初のジョブ・インスタンスの状態にモニタ・プログラムが戻る」「モニタ・プログラムが復帰する」とはどのような時を意味するのか？「他のジョブ・インスタンス全ての状態がチェックされ、また最初のジョブ・インスタンスが既に完了し」とはどのような状態を意味するのか？等が不明である。）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１５）で指摘した不備について＞
　依然として、段落【０００８】の「第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス及びモニタ・プログラムが含まれる。」、段落【００２６】第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス１０４及びモニタ・プログラム１１８が含まれる。」は、意味不明の記載であり理解不可能である。（「ループ・モニタリング・デバイス」や「モニタ・プログラム」が何に「含まれる」のか？）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１６）で指摘した不備について＞
　依然として、段落【０００８】に「プログラムは毎時間連続的に実行されてジョブを処理しなければならないことから、該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である。」と、段落【００２６】に「第２の問題はモニタ・ループに関連したものであり、ループ・モニタリング・デバイス１０４及びモニタ・プログラム１１８が含まれる。プログラムは毎時間連続的に実行されてジョブを処理しなければならないことから、該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である。」とあるが、その理由（「プログラムは毎時間連続的に実行されてジョブを処理しなければならないこと」と「該プログラムはプロセッサ・インテンシブであり、リソースを無駄にし、そして保守が困難である」ことの因果関係）が不明であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１７）で指摘した不備について＞
　依然として、段落【００１１】に「【発明が解決しようとする課題】本発明は、プロセッサによる実行のためにジョブのジョブ・インスタンスを実行依頼し、状態モデルを用いて該ジョブ・インスタンスをモニタリングする方法、及び該方法を用いるシステムに関する。」とあるが、これは「課題」と認め得るような事項ではなく、この記載からは本願発明の技術上の意義を理解することは到底できない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１８）で指摘した不備について＞
　依然として、段落【００１３】の「プロセッサはジョブ待ち行列入れサブシステムとすることができる。」「レジスタに格納するステップは、ジョブ・インスタンスに対するレジスタ・パラメータを確定するために循環プログラムを用いるステップを含むことができる。」「レジスタに格納するステップは、ＡＰＩによってジョブ・インスタンスをレジスタに格納するためにジョブ・インスタンスのレジスタ・パラメータを確定し、さらにレジスタ・パラメータをＡＰＩに実行依頼するステップも含むことができる。」、段落【００１５】の「一実施形態例では、上記した状態は完了状態であり、またアクションは次のジョブ・インスタンスに対してステップ（ａ）から（ｅ）を実行するステップを含むものである。」は意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−１９）で指摘した不備について＞
　依然として、段落【００１９】の「ジョブ全体そのものが実行依頼されるべきジョブの総計を含む。現実に、それはジョブ・インスタンスの総計を含むプログラムである。」は、意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２０）で指摘した不備について＞
　依然として、段落【００２０】の「ジョブの各インスタンスが完了し、最終結果が得られた後、マスタ・プロセス（同様にオペレーティング・システムの一部である）が伝えられなければならない。」は、意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２１）で指摘した不備について＞
　依然として、段落【００２０】の「モニタリング・プロセス（又は複数のプロセス）はすべてのジョブ・インスタンスが完了し、新たなジョブ・インスタンスが開始されることを理解しなければならない。」は、意味不明の記載であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２２）で指摘した不備について＞
　依然として、段落【００２１】の「また、本実施形態では、ジョブ待ち行列入りサブシステム１０２、ループ・モニタリング・デバイス１０４，ジョブ・インスタンス１０８、及び実行依頼コマンド１０６はコンピュータ上で実行されるソフトウェアのインスタンス、もしくは代わりに一つのプログラム・モジュールから別のプログラム・モジュールに対する呼出である。」は、意味不明の記載であり理解不可能である。（「ジョブ待ち行列入りサブシステム１０２」、「ループ・モニタリング・デバイス１０４」，「ジョブ・インスタンス１０８、」が「呼出」であるという構成は技術常識からみて理解しうるものではない。）
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２３）で指摘した不備について＞
　依然として、段落【００２２】の「スクリプト１１０は、ジョブ待ち行列入りサブシステム１０２に実行依頼するために、ディスクからジョブ・インスタンス（ファイル）をフェッチするだろう。」なる記載、「実行依頼コマンド１０６は、フェッチ・プログラム１１２を用いてジョブ・インスタンス１０８をフェッチする。」なる記載、「ジョブ・コマンド・ファイル（不図示）があり、そこからフェッチ・コマンド１０６がジョブ・インスタンス１０８をフェッチする。」なる記載は互いにその内容が乖離しており理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２４）で指摘した不備について＞
　依然として、段落【００２２】の「ジョブ・インスタンス１０８は、次に実行依頼プログラム１１４を介してジョブ待ち行列入れサブシステム１０２に掲示される。」なる記載の「ジョブ待ち行列入れサブシステム１０２に掲示される」とは如何なる処理を意味するのか不明であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２５）で指摘した不備について＞
　依然として、段落【００２８】に「図３は、本発明の自己実行依頼ジョブを説明するためのブロック図である。」とあるが当該「自己実行依頼ジョブ」とは如何なるジョブを意味するの不明であり理解不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２６）で指摘した不備について＞
　依然として、段落【００２８】に「イベント駆動型モデルの作成に供するコンポーネントは、（１）アプリケーション・プログラム・インタフェース（ＡＰＩ）、（２）レジスタ手続き３０８、（３）完了手続き３１０、（４）起動プログラム３０４、及び（５）循環プログラム３０６を含む。」とあるが、ここで用いられる「アプリケーション・プログラム・インタフェース（ＡＰＩ）」、「レジスタ手続き３０８」、「完了手続き３１０」、「起動プログラム３０４」、及び「循環プログラム３０６」とは如何なるカテゴリーのものなのか？（「装置」なのか？「プログラム」なのか？「設計思想」なのか？）が不明であり、これを如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２７）で指摘した不備について＞
　依然として、段落【００２９】に「スクリプトは、ジョブ待ち行列入りサブシステム１０２に実行依頼するために、ディスクからジョブ・インスタンス（ファイル）をフェッチするだろう。」とある一方で、「実行依頼コマンド１０６は、フェッチ・プログラム１１２を用いてジョブ・コマンド・ファイルからジョブ・インスタンス１０８をフェッチする」ともあり、「フェッチ」の主体が複数有り、本願発明を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２８）で指摘した不備について＞
　依然として、段落【００２９】に「次に、ジョブ・インスタンス１０８は、実行依頼プログラム１１４を介してジョブ待ち行列入りサブシステム１０２に掲示される」とある一方で、「ジョブ待ち行列入りサブシステム１０２は、関係した計算を行うオペレーティング・システムの一部（不図示）に対してジョブ・インスタンス１０８を実行依頼する。」ともあり、「ジョブ待ち行列入りサブシステム１０２」はそもそも如何なる種類のもので（掲示手段なのか？プログラムなのか？）、如何なる機能作用のものなのかが不明であり、当該「ジョブ待ち行列入りサブシステム１０２」を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−２９）で指摘した不備について＞
　依然として、段落【００３０】に「実行依頼コマンド１０６の実行と同時に、または実行依頼コマンド１０６の実行とは別々に、循環プログラム３０６が実行される。」とあるが、これをどの様に実現するのか（「実行依頼コマンド１０６」内に「循環プログラム３０６」を実行する機能を設けるのか？「実行依頼コマンド」と「循環プログラム」の「実行」の双方をスクリプトに書くのか？）が不明であり、当該機能を如何に実現すればよいのかを正確に理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３０）で指摘した不備について＞
　依然として、段落【００３０】に「循環プログラム３０６は、実行依頼コマンド１０６と協働し、かつ対話する機能であり、そのため概念的に実行依頼コマンド１０６を「循環（ラップ・アラウンド）する」という。循環プログラムは、ジョブ・インスタンス１０８のレジスタ・パラメータを確定し、このレジスタ・パラメータをＡＰＩプログラム３０２に実行依頼する。」とあるが、「協働し」とはどう動作することを意味するのか？「プログラムが」「機能」であるとはどの様なことを意味するのか？、「そのため概念的に実行依頼コマンド１０６を「循環（ラップ・アラウンド）する」とは如何なることを説明しているのか？「ジョブ・インスタンス１０８のレジスタ・パラメータ」とは如何なるパラメータなのか？これを「確定」するとは如何なる処理を意味するのか？「このレジスタ・パラメータをＡＰＩプログラム３０２に実行依頼する」とは如何なる処理を意味するのか？「パラメータ」を「実行」するとは何を意味しているのか？等々が不明であり、当該「循環プログラム」を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３１）で指摘した不備について＞
　依然として、段落【００３０】に「循環プログラムは・・・レジスタ・パラメータを確定し、・・・に実行依頼する。」とある一方で「このことはレジスタ手続き３０８の実行によって行われる。」とあり、さらに段落【００３１】では「ＡＰＩプログラム３０２は、ジョブ状態（status又はstate）を確定するために使用される。」ともあり、「確定」や「実行依頼」が「循環プログラム」が行うのか「レジスタ手続き」が行うのか「ＡＰＩプログラム」が行うのか不明であり、「確定」なる機能を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３２）で指摘した不備について＞
　依然として、段落【００３１】に「プロセッサ上で実行され、かつジョブ待ち行列入れサブシステム１０２と対話するＡＰＩプログラム３０２」とあり、「ジョブ待ち行列入れサブシステム１０２」と「ＡＰＩプログラム３０２」は別個の物として説明されているが、図３においては「ジョブ待ち行列入れサブシステム１０２」内に「ＡＰＩ」が記載されており、矛盾する。このため、これを如何に実現すればよいのかを正確に理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３３）で指摘した不備について＞
　依然として、段落【００３１】に「例えば（１）開始状態（ジョブ・インスタンスが開始された）、（２）実行状態（ジョブ・インスタンスが実行されている）」とあるが「ジョブ・インスタンスが開始された」状態と「ジョブ・インスタンスが実行されている」状態とは何がどう異なる状態なのかが不明である。このため、これを如何に実現すればよいのかを正確に理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３４）で指摘した不備について＞
　依然として、段落【００３１】に「ジョブ・インスタンスに対してプロセッサが不完全」とあるが、これは何を意味しているのかが不明である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３５）で指摘した不備について＞
　依然として、段落【００３２】に「起動プログラムがプログラム１１６を実行して次のジョブ・インスタンスを起動する。」とあるが、この記載からは「起動プログラム」「プログラム１１６」「ジョブ・インスタンス」が、それぞれ如何なる処理をすることを意味しているのかが不明である。このため、これを如何にして実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３６）で指摘した不備について＞
　依然として、段落【００３２】に「その結果、起動プログラム３０４（及びそれに付随するプログラム・モジュール）は休止状態に入り」とあるが「付随するプログラム・モジュール」とはどのプログラムなのかが不明である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３７）で指摘した不備について＞
　依然として、段落【００３２】に「ジョブ待ち行列入りサブシステム１０２の状態を続けて実行」とあるが、これは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３８）で指摘した不備について＞
　依然として、段落【００３３】に「レジストレーション手続き」とあるがこれは何か（別個のプログラム？「レジスタ手続き３０８」のこと？）が不明確である。このため、これを如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−３９）で指摘した不備について＞
　依然として、段落【００３３】に「レジストレーション手続きによって、ＡＰＩがジョブ・インスタンスの記録を保持することを許す。」とあるが、これは何が如何なる処理をすることを意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４０）で指摘した不備について＞
　依然として、段落【００３３】に「付録１（１枚）は模範的な起動プログラムを含む。付録２（３枚）は模範的な循環プログラム１０６を含み、実行依頼コマンド・モジュールに対して呼出する機能が含まれる。ここに示している実施形態では、それらのプログラムはＣ言語によって記述されているが、当業者ならば任意のプラットホームで実行可能である任意の言語を使用することが可能であること、また代わりに別のアプローチの使用（例えばハードウェアの使用）が可能であることを容易に理解することができるだろう。」とあるが「付録１」「付録２」とは何を意味するのかが不明である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４１）で指摘した不備について＞
　依然として、段落【００３４】の「出力ファイル」とはどのファイルなのかが不明である。このため、本願発明を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４２）で指摘した不備について＞
　依然として、段落【００３５】に「一実施形態では、実際のプログラム出力は、チェック・プログラム（不図示）を実行することによって確定することができる。」とあるがこの「実際のプログラム出力」とはどの出力なのかが不明である。このため、本願発明を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４３）で指摘した不備について＞
　依然として、段落【００３５】の「このチェック・プログラムは、出力結果をどこで見つけるかについての所定の情報である。」は合理的解釈の不可能な記載であり、当該「チェック・プログラム」を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４４）で指摘した不備について＞
　依然として、段落【００３５】に「起動プログラム３０４はチェック・プログラムを呼出する。」とあるが、従来例の「ポーリング」とどう異なるのかが明確に説明されていない。このため、当該「チェック・プログラム」や「呼出」機能を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４５）で指摘した不備について＞
　依然として、段落【００３５】に「言い換えると、ジョブ・インスタンス識別子及び結果を見出すための出力の位置を使用する。」とあるが、これは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４６）で指摘した不備について＞
　依然として、段落【００３５】に「そして、結果が良好かどうかを判断する。もし、結果が良好であるならば、起動プログラム３０４は処理を続けることを許される。」とあるが、「良好」とはどのような状態を意味するのか？「処理を続けることを許される。」とはどのような状態・動作を意味するのか？段落【００３２】の「休止状態」とはどのような関係の動作なのか？等が明確に説明されていない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４７）で指摘した不備について＞
　依然として、段落【００３６】に「また、本発明では、循環プログラム３０６が存在することから、実行依頼コマンド１０６がジョブ全体（すべてのジョブ・インスタンスを含む）に対して１度だけ実行される。」とあるが、如何なる因果関係によってこのような作用効果が生じるのかが明確に説明されていない。このため、発明の技術上の意義を正確に理解することができない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４８）で指摘した不備について＞
　依然として、段落【００３７】に「起動プログラムは、完了状態を直接受け取り、該完了状態を受け取ると直ちに新たな開始状態をインプリメントする。」とあるがこれは如何なる処理を意味するのかが不明である。このため、当該処理を如何に実現すればよいのかを理解することが不可能である。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−４９）で指摘した不備について＞
　依然として、段落【００３８】〜【００４２】にかけて図５を用いて、従来のシステムと本発明のシステムとを比較しているが、この図は何のフローを示しているのかが明確に説明されていない。このため、発明の技術上の意義を正確に理解することができない。
　また、この点に関して意見書等での釈明もなされていない。
　
＜理由２．（２−５０）で指摘した不備について＞
　依然として、段落【００３８】に「図５（ａ）のステップ５０２は、図１の従来のシステムにおいて、実行中にジョブ・コマンド・ファイルを生成する。図５（ｂ）のステップ５１０では、図３の本発明のシステムにおいて、ジョブ・コマンド・ファイルが一度だけ生じ、いかなる時でも任意の数のプロセスによって使用することができる。」と、
段落【００３９】に「図５（ａ）のステップ５０４では、図１の従来のシステムにおいて、一つのジョブの複数のジョブ・インスタンスがループ状になって開始され、かつ実行され、各新たなジョブ・インスタンスを連続して受け取るために続行される。図５（ｂ）のステップ５１２では、図３の本発明のシステムにおいて、しかし、循環プログラム３０６のため、複数のジョブ・インスタンスがジョブの開始時に一度に開始される。」と、
段落【００４０】に「図５（ａ）のステップ５０６では、ジョブ・インスタンスは上記したポーリング方法によってモニタされる。しかし、ステップ５１４ではＡＰＩ３０２と起動プログラム３０４との間の相互作用によってジョブ・インスタンスがイベント駆動される。」と、
段落【００４１】に「図５（ａ）のステップ５０８では、単一モニタ・ループはすべてのジョブ・インスタンスの結果がログに記録されたことを確認しなければならない。しかし、ステップ５１６では、ジョブ・インスタンスが完了した後、新たなジョブ・インスタンスが開示される前に、起動プログラムがジョブ・ログ・プログラムを開始することができる。ここで再び、ジョブ・ログ・プログラムが休止状態にあるイベント駆動型モデルがあり、ジョブ・インスタンスが完了する時、起動プログラムによってのみ実行される。ログ・コレクタはジョブ・インスタンス出力ファイルをクリーン・アップすることができ、あるいはある時間間隔毎に一回ログに記録する。ジョブ・ログ情報はジョブ・コマンド・ファイルに含めることができる。タイムスタンプ・オプションは、ジョブの現在の実行からどれぐらい長くログを隔離するかを明示することに使用することができる。」と、
段落【００４２】に「最後に、図５（ａ）は次のジョブ・インスタンスを検索し、かつ処理するために、ループ・パックを含む。しかし、本発明では、ジョブ情報は一つのジョブ・インスタンスから次のジョブ・インスタンスへラップされて渡されるので、図５（ｂ）ではループ・バックは必要ではない。」
とあるが、なぜ（どのような因果関係から）このようなことが言えるのかが明確に説明されていない。そしてこのため、発明の技術上の意義を正確に理解することができない。
　また、この点に関して意見書等での釈明もなされていない。
　
　なお、意見書には「理由１」に対しての意見において「◎本願発明の内容の補足説明」として「この発明特定事項を変更追加することにより、従来の「ジョブ実行依頼システム」（段２１〜２４、図１及び図２）の次の技術課題（段落３６）、
・リソースのコンテンション（段落２５）、
・モニタ・ループの浪費によるプロセッサ・インテンシブ（段落２６）
・シングル・ポイント障害よるインスタンス全ての停止（段落２７）
を解消できるために、
コマンド実行１０６をジョブ全体（ジョブインスタンスの集合）に一度だけ発行する循環プログラム３０６と、ジョブ・インスタンスに次の実行依頼を発行する起動プログラムとを含む構成を有する。この特徴的な発明特定事項は「前記ジョブ・インスタンスが前記ジョブ・インスタンスが実行中の前記状態を自動的かつ継続的にモニタリングして、前記状態が所定の状態値に一致する場合に前記システムに対して後続のジョブ・インスタンスの前記実行依頼ステップ（ｃ）を実行」する点である。かかるモニタ・ループを有する「ジョブ実行依頼システム」の課題を解決するために、本願発明はイベント駆動型の「ジョブ実行依頼システム」は、（１）アプリケーション・プログラム・インタフェース（ＡＰＩ）、（２）レジスタ手続き３０８、（３）完了手続き３１０、（４）起動プログラム３０４、及び（５）循環プログラム３０６を含む（段落２８）。本発明のイベント駆動型モデルの「ジョブ・インスタンスを状態モデルを用いてモニタリングする方法」は、『起動プログラム３０４（及びそれに付随するプログラム・モジュール）は休止状態に入り、ジョブ待ち行列入りサブシステム１０２の状態を続けて実行したり、あるいはポーリングすることはない。』（段落３２）ことより、従来の大規模な行列計算における課題（１．リソースのコンテンション、２．モニタ・ループの浪費によるプロセッサ・インテンシブ、３．シングル・ポイント障害よるインスタンス全ての停止）などを解消できる有利な効果を奏する。」との説明がなされているが、この説明は明らかに本願特許請求の範囲の記載に基づくものではなく、上記の特許請求の範囲の不備を解消しうるものではない。また、上記の発明の詳細な説明の記載不備を解消し得るものでもない。
　
　以上の通りであるから、請求項１〜３に係る発明は依然として明確でなく、しかも、発明の詳細な説明に記載したものではない。
　また、本願明細書の発明の詳細な説明の記載は、依然として当業者が請求項１〜３に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、請求項１〜３に係る発明の技術上の意義を理解するために必要な事項も十分に記載されておらず、特許法第３６条第４項の経済産業省令で定めるところによる記載がされていないものでもある。
　
　
５．むすび
　よって、この出願は、発明の詳細な説明及び特許請求の範囲の記載が、特許法第３６条第４項及び第６項第１号、第２号に規定する要件を満たしていない。
　従って、新規性・進歩性等の他の特許要件についての検討をするまでもなく、本願は拒絶すべきものである。
　
　よって、結論のとおり審決する。