【事件の表示】
　特願２００４−１７８８６７「プラグ可能構成要素におけるブレークポイントのデバッグ」拒絶査定不服審判事件〔平成１７年　１月１３日出願公開、特開２００５−　１１３４２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１６年６月１６日（パリ条約による優先権主張２００３年６月２０日、米国）の出願であって、平成１９年６月１８日付けで手続補正がなされ、平成２２年９月１５日付けで拒絶理由通知がなされ、平成２３年１月１７日付けで意見書が提出されるとともに、同日付けで手続補正がなされ、平成２３年２月１日付けで最後の拒絶理由通知がなされ、同年７月１日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年７月１５日付けで拒絶査定がなされ、これに対し、同年１１月２２日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされ、当審において、平成２４年３月８日付けで前置報告書を利用した審尋がなされ、同年６月１１日付けで、それに対する回答書が提出されたものである。
　
　
２．平成２３年１１月２２日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２３年１１月２２日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
（１）新規事項の追加について
　本件補正が、特許法第１７条の２第３項の規定を満たすものであるか否か、すなわち、本件補正が願書に最初に添付された明細書、請求の範囲及び図面（以下、これを「当初明細書等」という。）の範囲内でなされたものであるかについて、以下に検討する。
　
　本件補正は、
補正前の請求項１に記載された
「　プロセッサが通信ネットワークを介してクライアントコンピューティングデバイスと通信することにより、該プロセッサによって複数のタスクからなるプログラムモジュールをデバックする方法であって、
　デバッグインターフェースによって処理するために、タスクを前記通信ネットワークを介して受け取るステップと、
　　　　ここで、前記タスクは、パッケージを実行または配置するための命令を示すものであり、
　ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを前記デバッグインターフェースによって該タスク内に設定するステップと、
　前記設定されたブレークポイントの位置を示す情報を前記ランタイムに送るステップと、
　前記ランタイムによって前記タスクの実行中に、ブレークポイントに遭遇するステップと、
　前記ブレークポイントの遭遇を前記デバッグインターフェースを介して前記クライアントコンピューティングデバイスに通知するステップと、
　　　　　　　　ここで、該ランタイムは、該通知に応答して中断オペレーションを呼び出し、
を具えたことを特徴とする方法。」を、
補正後の請求項１に記載された
「
　通
して、プ
　
前記プログラムモジュールに記憶されたランタイムによって、タスクから構成されるパッケージを、前記通信ネットワークを介して前記クライアントコンピューティングデバイスから受け取るステップと、
　前記ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを、該タスクによって設定するステップと、
　前記ブレイクポイントが設定された位置を示す情報を、前記タスクによって前記ランタイムへ送るステップと、
　前記ランタイムによって前記タスクの実行中に、前記タスクによって前記ブレイクポイントに遭遇するステップと、
　前記ブレークポイントに遭遇したこ
とを、前記ランタイムによって前記
　　ここで、前記通知は、
ランタイムによる
の呼び出し
を具えたことを特徴とする方法。」に補正する
ことを含むものである。
　
　すなわち、補正後の請求項１は、その記載からして、次の発明特定事項（ａ）を含んでいるものと認められる。
　
（ａ）「　通信ネットワークを介してクライアントコンピューティングデバイスと通信して、プログラムモジュールをデバックする方法であって、
　前記プログラムモジュールに記憶されたランタイムによって、タスクから構成されるパッケージを、前記通信ネットワークを介して前記クライアントコンピューティングデバイスから受け取るステップ」
　
　上記発明特定事項（ａ）の「プログラムモジュールをデバックする方法」及び「前記プログラムモジュールに記憶されたランタイム」という記載から、補正後の請求項１は、「デバッグ」対象の「プログラムモジュール」に「ランタイム」が記憶されている態様を含んでいると解される。
　しかしながら、当初明細書には、「プログラムモジュール」と「ランタイム」との関係は記載されておらず、段落【００３６】に
「本発明は、コンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、構成要素、データストラクチャなどが含まれる。」
という記載がある程度である。仮に、上記段落【００３６】の記載の「プログラムモジュールには、特定のタスクを実行する・・・、ルーチン、プログラム・・・が含まれる。」から、「プログラムモジュールには、ランタイムが含まれる」ことが読み取れるとしても、「プログラムモジュール」が「ランタイム」を「記憶」する態様までを読み取ることはできない。
　よって、当初明細書には、「ランタイム」が記憶されている「プログラムモジュール」を「デバッグ」対象にする態様は記載も示唆もなく、また、当業者にとって自明なものでもない。
　
　以上のように、補正後の請求項１に記載された発明特定事項（ａ）は、当初明細書等に記載されておらず、かつ、その記載から自明なものでもないから、上記事項を追加する本件補正は、当初明細書等に記載した範囲内でしたものではない。
　
　
（２）補正の目的について
　
　審判請求時の補正は、補正前の請求項１の記載「複数のタスクからなるプログラムモジュールをデバッグする方法」を、「プログラムモジュールをデバッグする方法であって、前記プログラムモジュールに記憶されたランタイム」と補正することにより、「デバッグ」の対象を実質的に「タスク」から「ランタイム」に変更するものである。実際、補正前の請求項１に記載の「ブレークポイントを…該タスク内に設定する」が補正により削除されたことと相まって、補正後の請求項１に係る発明は、「ランタイム」に対する「ブレークポイント」を「タスク」により設定しているように解される。
　さらに、この補正は、補正前の請求項１に記載されていた「デバッグインターフェース」に関する記述を完全に削除しているため、発明の内容を拡張しており、かつ、削除された記述に代わる、発明を明確にするための記載が付加されているわけでもないから、不明りょうな記載の釈明の限度を超えている。
　上記のような補正はいずれも、不明りょうな記載の釈明、請求項の限定的な減縮、誤記の訂正または請求項の削除の何れをも目的としたものではない。
　
　
（３）むすび
　上記（１）、（２）で検討したとおり、本件補正は、特許法第１７条の２第３項、及び、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
３．補正却下の決定を踏まえた検討
　
（１）本願発明
　平成２３年１１月２２日付けの手続補正は、上記のとおり却下されたので、本願の請求項１ないし１２に係る発明は、平成２３年７月１日付けの特許請求の範囲の請求項１ないし１３に記載された事項により特定されるものである。
　
　
（２）原査定の理由及び請求人の主張
　
（２−１）平成２３年２月１日付けの拒絶理由通知
　平成２３年２月１日付けで審査官が通知した拒絶理由は、次の内容を含むものである。
「４．この出願は、明細書及び特許請求の範囲の記載が下記の点で、特許法第３６条第４項第１号並びに第６項第１号及び第２号に規定する要件を満たしていない
。
　　　　　　　　　　　　　　　　　記
（１）請求項１、２に係る発明は、各ステップの主体が特定されておらず、人間が行う方法であるのか、機械等が自動的に行う方法であるのか、又は、両者が混在したものであるのか不明である。（人間が「プロセッサを介して」、手動で各ステップを操作する態様を含むことに留意されたい。）
　仮に、機械等が自動的に行う方法であるとしても、どのような手段により実現しているのか不明である。（発明を実現するための前提となるシステム構成がそもそも不明である。）
（２）請求項１の記載において、「タスクのインスタンス実行中に」と、「タスクの実行中に」は、同じ意味であるのか否か不明である。同じ意味であれば用語を統一すべきであり、異なる意味であれば、どのように異なるのか不明である。
（３）請求項１の記載において、「タスク」又は「タスクのインスタンス」を実行しているのは、「プロセッサ」であるのか、それ以外の手段であるのか、不明である。
（４）請求項１の記載において、どのような「ブレークポイント」を、何に基づいてどのように「作成」するのか不明である。
　図４のステップ４１５には、「タスクはブレークポイントを作成する」と記載されているが、「タスク」は、自身に関連付けるべき「ブレークポイント」を、どのように「作成」するのか、発明の詳細な説明（特に、明細書の段落【００６１】）には明確かつ十分に記載していない。
（５）請求項１には、「プロセッサを介して」との記載があるが、これ以降には、「プロセッサ」について記載がなく、以降の各「ステップ」において、該「プロセッサ」がどのように関与しているのか不明である。仮に、「プロセッサ」が、以降の各「ステップ」とは無関係であり、「デバッグ」のみにしか関与していない場合は、該「プロセッサ」は、「デバッグ」をどのように実行しているのか不明である。
（６）請求項１の記載において、「ランタイム」は、送られてきた「ブレークポイントの位置を示す情報」をどのように処理するのか不明である。
　なお、「ランタイム」自体が、「ブレークポイントの位置を示す情報」を使用する場合は、「ブレークポイントに遭遇する」のは「ランタイム」となるが、その場合、自身が「遭遇」したことを「ランタイム」自身に「通知する」理由が不明である。
　そうでないとするならば、「ランタイム」以外のものが、「ブレークポイントに遭遇」し、その旨を「ランタイム」に「通知する」ものとなるが、該「ランタイム」以外のものが、何であるのか不明である。（そもそも、このような態様は発明の詳細な説明に記載されているのか？）
　図４の記載によると、ランタイムがタスクを実行し（４３０）、タスクがブレークポイントに遭遇し（４３５）、ブレークポイントがクライアントに通知されており（４４０）、図３の記載によると、ブレークポイントに遭遇したことは、タスクから一旦ランタイムに通知されているようであるが、そもそも、「タスク」の実行主体である「ランタイム」が、実行対象である「タスク」から「ブレークポイント」の「通知」を受けるとは、どのような態様であるのか全く不明である。
（７）請求項１の記載において、「タスクのインスタンス」を実行していると思われる「ランタイム」が、「実行中」の状態で、どのようにして「ブレークポイントの位置を示す情報」を受け取ることができるのか、発明の詳細な説明の記載を参酌しても不明である。
（８）請求項２に記載の「デバッグインターフェース」と、請求項１に記載の「プロセッサ」及び「ランタイム」との関係が不明である。
（９）請求項２の記載において、「入力」が「デバッグインターフェース」によりどのように「処理」されるのか不明である。（「処理するために」は、意味が不明である。）
（１０）請求項２の記載において、「入力」をどこから「受け取る」のか不明である。
（１１）請求項２に記載の「パッケージを実行または配置するための命令を示すもの」が意味するところが全く不明である。
　特に、該「命令」と、請求項１に記載の「ブレークポイント」との関係、及び、該「命令」をどのように用いてどのように「デバッグ」を行うのか不明である。
（１２）請求項１、２を引用する請求項１０及び１１に係る発明も、上記（１）乃至（１１）の点において不明である。
（１３）　（略）」
　
（２−２）平成２３年７月１日付けで提出された意見書における請求人の主張
　上記拒絶理由４．（１）〜（１２）の通知に対し、請求人は、平成２３年７月１日付け手続補正書により、旧請求項１〜１７を新請求項１〜１３に補正するとともに、上記意見書において、次のような主張をしている。
　
「３．理由１−４に対する見解
　請求項１−１７のうち、請求項１に請求項２，３，８を加え，請求項１２に請求項１６を加えて補正しました。これにより、補正後の内容は、別紙手続補正書に示すように、願書に最初に添付した明細書又は図面に記載した事項の範囲内の内容であって明確であり、単一性の要件は満たしております。また、発明の詳細な説明は、本願発明を、当業者が実施できる程度に明確かつ十分に記載しております。従いまして、審査官殿がご指摘の点は解消されたものと思料致します。」
　
（２−３）平成２３年７月１５日付けの拒絶査定
　上記意見書の主張を踏まえた上での審査官の平成２３年７月１５日付けの拒絶査定は、次の内容を含むものである。
　
「（１）理由４．（１）について
　請求項１には、「プロセッサが…することにより、該プロセッサによって…デバッグする方法」と記載されているため、方法を構成する各ステップは、「プロセッサ」が行うものと解される。
　しかしながら、以降には、「デバッグインターフェースによって処理する」、「ランタイムによって前記タスクの実行中に、…前記デバッグインターフェースによって…設定する」、「前記ランタイムによって前記タスクの実行中に」からすると、「通知する」ステップを除くと、「プロセッサ」以外のものが各「ステップ」を実行している。
　また、請求項１の記載においては、「プロセッサ」と、「デバッグインターフェース」及び「ランタイム」との関係が不明である。
　よって、請求項１に係る発明は、依然として処理の主体が不明確である。
　
（２）理由４．（３）、（１２）について
　補正により、請求項１の記載において、「ブレークポイント」は、「デバッグインターフェース」によって「タスク内に設定」されるものとなったが、しかしながら、そのような態様は、発明の詳細な説明には記載されていない。
　そもそも、発明の詳細な説明において、「デバッグインターフェース」が記載されているのは、明細書の段落【００４７】しかなく、その前後の記載を参酌しても、「デバッグインターフェース」がどのようなものでありどのように機能するのかについて全く記載がない。
　
（３）理由４．（８）、（９）及び（１２）について
　請求項１の記載において、「デバッグインターフェース」と、「ランタイム」及び「プロセッサ」との関係が依然として不明である。
　例えば、「デバッグインターフェース」は、「ランタイム」又は「プロセッサ」に含まれるものであるのか、あるいは、それ以外の装置上に存在しているのか、不明である。
　また、「デバッグインターフェースによって処理するために、タスクを…受け取る」という記載からすると、「タスク」は、「デバッグインターフェース」によって「処理」されるものである。ここで、「処理」がどのようなものであるのか不明である。
　一方、「ランタイムによって前記タスクの実行中に」との記載からすると、「タスク」は、「ランタイム」によって「実行」されるものである。
　よって、「ランタイム」と「デバッグインターフェース」との関係が不明確であるとともに、「タスク」が、何により、どのように「処理」又は「実行」されるのか不明である。
（４）理由４．（１１）及び（１２）について
　請求項１の記載「前記タスクは、パッケージを実行または配置するための命令を示すもの」は、発明の詳細な説明の記載を参酌しても、依然として意味が不明確である。特に、
ａ）「タスク」は、「命令」をどのように「示す」のか、不明である。
ｂ）どこに存在する「パッケージ」を「実行」するのか、あるいは、「パッケージ」をどこに「配置」するのか、具体的に想定することができない。
ｃ）発明の詳細な説明には、例えば、明細書の段落【００４８】に「Ｔａｓｋを有するパッケージ」、段落【００４９】に「Ｔａｓｋを備えたパッケージ」、段落【００６０】に「ランタイムは…実行されたパッケージのタスクを実行する」、段落【００６１】に「クライアントは…パッケージを実行し、ランタイムは…タスクを実行する」などと記載されており、請求項１の記載は、発明の詳細な説明の記載と整合しない。
ｄ）「パッケージ」を「配置」することについては、発明の詳細な説明には全く記載がない。」
　
（２−４）平成２３年１１月２２日に提出された審判請求書の「請求の理由」における請求人の主張
　上記拒絶査定に対し、請求人は、平成２３年１１月２２日付け手続補正書により、旧請求項１〜１３のうち、旧請求項４を削除し、旧請求項１〜３，６，７，９〜１１，１３を新請求項１〜７，９〜１１，１３に補正するとともに、上記審判請求書において、次のような主張をしている。
　
「［本願発明が特許されるべき理由］
（・・・中略・・・）
２．特許法第３６条第４項第１号並びに第６項第１号及び第２号の規定に係る理由４に対する見解
　今回の補正では、請求項１−１３のうち、請求項１−３，６，７，９−１１，１３を補正し、請求項４は削除しました。これにより、補正後の内容について、発明の詳細な説明には、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されており、また、発明の詳細な説明に記載したものであって明確であります。」
　
（２−５）平成２４年３月８日付けで行われた前置報告書を利用した審尋
　当審における上記審尋は、次の内容を含むものである。
　
「この審判事件について、下記の点に対する回答書を、この審尋の発送の日から３ヶ月以内に提出して下さい。 
　　　　　　　　　　　　　　　　　記
　この審判事件については、審査官による審査（特許法第１６２条、前置審査）の結果、以下の《前置報告書の内容》のとおり、特許をすべき旨の査定ができない旨の報告（同法第１６４条第３項、前置報告書）が特許庁長官になされました。この審判事件の審理は、今後、この《前置報告書の内容》を踏まえて行うことになります。
　この審尋（同法第１３４条第４項）は、この審判事件の審理を開始するにあたり、《前置報告書の内容》について、審判請求人の意見を事前に求めるものです。意見があれば回答してください。
（・・・中略・・・）
《前置報告書の内容》 
（・・・中略・・・）
１．審判請求時の補正による補正後の請求項１に記載の「プログラムモジュールをデバッグする方法であって、前記プログラムモジュールに記憶されたランタイム」は、出願当初の明細書等に記載したものではない。（補正後の請求項６、８にも同等の記載がある。） 
　
　したがって、この補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでなく、特許法第１７条の２第３項の規定に違反するものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　そして、この出願は原査定の理由に示したとおり拒絶されるべきものである。
　
２．審判請求時の補正は、補正前の請求項１の記載「複数のタスクからなるプログラムモジュールをデバッグする方法」を、「プログラムモジュールをデバッグする方法であって、前記プログラムモジュールに記憶されたランタイム」と補正することにより、「デバッグ」の対象を「タスク」から「ランタイム」に変更するものである。実際、補正前の請求項１に記載の「ブレークポイントを…該タスク内に設定する」が補正により削除されたことと相まって、補正後の請求項１に係る発明は、「ランタイム」に対する「ブレークポイント」を「タスク」により設定しているように解される。 
　さらに、この補正は、補正前の請求項１に記載されていた「デバッグインターフェース」に関する記述を完全に削除しているため、発明の内容を拡張しており、かつ、削除された記述に替わる、発明を明確にするための記載が付加されているわけでもないから、不明りょうな記載の釈明の限度を超えている。 
　上記のような補正はいずれも、不明りょうな記載の釈明、請求項の限定的な減縮、誤記の訂正または請求項の削除の何れをも目的としたものではない。 
　 
　したがって、この補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第１７条の２第４項の規定に違反するものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。 
　そして、この出願は原査定の理由に示したとおり拒絶されるべきものである。」
　
（２−６）平成２４年６月１１日付けで提出された回答書における請求人の主張
　上記審尋に対し、請求人は、上記回答書において、次のような主張をしている。
　
「【回答の内容】 
１．平成２４年３月８日に起案された審尋に記載された前置報告書において、以下の理由（特許法第１７条の２第４項）から、本願発明は、特許することができないと認定されました。 
　・『審判請求時の補正による補正後の請求項１に記載の「プログラムモジュールをデバッグする方法であって、前記プログラムモジュールに記憶されたランタイム」は、出願当初の明細書等に記載したものではない。』点。 
　・『補正前の請求項１に記載の「ブレークポイントを…該タスク内に設定する」が補正により削除されたことと相まって、補正後の請求項１に係る発明は、「ランタイム」に対する「ブレークポイント」を「タスク」により設定しているように解される。』点。 
　・『この補正は、補正前の請求項１に記載されていた「デバッグインターフェース」に関する記述を完全に削除しているため、発明の内容を拡張しており、かつ、削除された記述に替わる、発明を明確にするための記載が付加されているわけでもないから、不明りょうな記載の釈明の限度を超えている。』点。 
　しかしながら、審判請求人は、かかる御認定に関しまして、以下の意見を述べる次第です。 
　
２．特許法第１７条の２第４項に係る拒絶理由に対する回答： 
　審判請求人は、今回の回答書において後述するように、現請求項１〜１２のうち、請求項１，６，８についてそれぞれ補正することを考えております。以下、この点を踏まえて回答します。 
　請求項１において、「受け取るステップ」は、 
　「前記プログラムモジュールに格納
されたタ
ランタイムによって
　さらに、請求項１に以下の構成要素を付加しました。 
　「
前記ランタイムは、前記タスクが正しく実行されていることを知るために、どのブレークポイントをタスクが実現しているかおよび前記クライアントコンピューティング装置が前記ブレークポイントを実行可能であるかどうか、に関する情報を維持できるように、ランタイム時の全てのブレークポイントの状態を維持する
　また、請求項６，８についても、請求項１と同様に補正しました。 
　ここで、請求項１について補正の根拠を括弧書きで説明します。 
　［請求項１］ 
　通信ネットワーク（１４）を介してクライアントコンピューティングデバイス（１５,１７,１１０ａ,１１０ｂ）と通信して、プログラムモジュール（１３６,１４５）をデバックする方法であって、 
　前記プログラムモジュール（１３６,１４５）に格納
されたタ
ランタイムによって
　前記ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを、該タスクによって設定するステップ（４１５）と、 
　前記ブレイクポイントが設定された位置を示す情報を、前記タスクによって前記ランタイムへ送るステップと、 
　前記ランタイムによって前記タスクの実行中に（４３０）、
該
　前記ブレークポイントに遭遇したことを、前記ランタイムによって前記クライアントコンピューティングデバイスに通知するステップ（４４０）と 
を具え、 
　　　　　ここで、前記通知は、前記ランタイムによる
前記タスクの
　　　　　　　　　
前記ランタイムは、前記タスクが正しく実行されていることを知るために、どのブレークポイントをタスクが実現しているかおよび前記クライアントコンピューティング装置が前記ブレークポイントを実行可能であるかどうか、に関する情報を維持できるように、ランタイム時の全てのブレークポイントの状態を維持する（［００５０］）
　これにより、補正後の請求項１，６，８は、出願当初の明細書等に記載したものであり、明確であります。 
　
３．補正案 
　審判請求人は、以下に示す補正案を考えております。この場合、請求項１，６，８について補正します。なお、補正箇所には下線を付しました。 
　従いまして、今一度のご審理をお願いするものでございます。 
［特許請求の範囲］ 
　　［請求項１］ 
　通信ネットワークを介してクライアントコンピューティングデバイスと通信して、プログラムモジュールをデバックする方法であって、 
　前記プログラムモジュールに格納
されたタ
ランタイムによって
　前記ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを、該タスクによって設定するステップと、 
　前記ブレイクポイントが設定された位置を示す情報を、前記タスクによって前記ランタイムへ送るステップと、 
　前記ランタイムによって前記タスクの実行中に、
該
　前記ブレークポイントに遭遇したことを、前記ランタイムによって前記クライアントコンピューティングデバイスに通知するステップと 
を具え、 
　　　　　ここで、前記通知は、前記ランタイムによる
前記タスクの
　　　　　　　　　
前記ランタイムは、前記タスクが正しく実行されていることを知るために、どのブレークポイントをタスクが実現しているかおよび前記クライアントコンピューティング装置が前記ブレークポイントを実行可能であるかどうか、に関する情報を維持できるように、ランタイム時の全てのブレークポイントの状態を維持する
　
（３）当審の判断
　本願の請求項１に記載された発明は、平成２３年７月１日付けの手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次のものである。
「　プロセッサが通信ネットワークを介してクライアントコンピューティングデバイスと通信することにより、該プロセッサによって複数のタスクからなるプログラムモジュールをデバックする方法であって、
　デバッグインターフェースによって処理するために、タスクを前記通信ネットワークを介して受け取るステップと、
　　　　ここで、前記タスクは、パッケージを実行または配置するための命令を示すものであり、
　ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを前記デバッグインターフェースによって該タスク内に設定するステップと、
　前記設定されたブレークポイントの位置を示す情報を前記ランタイムに送るステップと、
　前記ランタイムによって前記タスクの実行中に、ブレークポイントに遭遇するステップと、
　前記ブレークポイントの遭遇を前記デバッグインターフェースを介して前記クライアントコンピューティングデバイスに通知するステップと、
　　　　　　　　ここで、該ランタイムは、該通知に応答して中断オペレーションを呼び出し、
を具えたことを特徴とする方法。」
　
（ア）本願発明の記載のうち、「ブレークポイント」に関する「デバッグインターフェース」との記載について検討する。
　上記記載に関し、発明の詳細な説明には、段落【００４７】に、次の記載がなされている。
「【００４７】
　Ｃ．ブレークポイントのデバッグ
　サーフェス上のＤＴＳ（データ変換サービス）でのデバッグの概念は、他の環境でのそれと同様である。パッケージ作成者は、パッケージの実行を停止し、変数を検査および変更して、実行を続行するための方法を必要とする。プログラマは、ブレークポイントを介して実行を制御し、監視を介して変数の検査および修正を行うことによって、これを実行する。ＤＴＳでの異なる点は、実行の多くがランタイムの制御の外にあるパッケージで発生することである。ＤＴＳはＴａｓｋ上のインターフェースメソッドへの呼出し間を除き、またＴａｓｋのスレッドの中断などの強力な戦術を使用した、Ｔａｓｋへのアクセスまたはその制御を持つことがない。ブレークポイントを設定できる場所にわたる、より詳細な制御が望まれる。したがって、オブジェクトモデルは、好ましくは何の変数、イベント、およびメソッドをブレークポイントターゲットにできるかを記述するための方法をＴａｓｋに提供する。インターフェース定義では、デバッグインターフェースを実施することになるエンティティを記述するために、総称「オブジェクト」が使用される。デバッグおよびブレークポイント機能を実現させることを望むオブジェクトモデルにおけるＴａｓｋとオブジェクトは、どちらもこれらのインターフェースを使用しなければならないため、これは、熟慮の上でのことである。」
　しかしながら、上記段落【００４７】の記載を見ても、「デバッグインターフェース」の具体的な構成や他の構成要素との関係が不明である。
　この点に関し、請求人は、上記「（２−２）」に摘記した意見書において、
「発明の詳細な説明は、本願発明を、当業者が実施できる程度に明確かつ十分に記載しております。」、
上記「（２−４）」に摘記した審判請求書において、
「これにより、補正後の内容について、発明の詳細な説明には、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されており、また、発明の詳細な説明に記載したものであって明確であります。」、
と主張しているのみであり、具体的な根拠については何ら説明をしていない。
　
　また、上記平成２３年７月１日付けの手続補正書により、「ブレークポイント」は、「デバッグインターフェース」によって「タスク内に設定」されるものとなった。
　しかしながら、発明の詳細な説明において、「デバッグインターフェース」が記載されている上記明細書の段落【００４７】には、「ブレークポイント」が、「デバッグインターフェース」によって「タスク内に設定」される態様は記載も示唆もされておらず、発明の詳細な説明及び図面を参酌しても「ブレークポイント」がどのように「デバッグインターフェース」によって「タスク内に設定」されるのか不明である。
　
　よって、本願の明細書は、本願の請求項１に記載されている「ランタイムによって前記タスクの実行中に、該タスクに関連付けられたブレークポイントを前記デバッグインターフェースによって該タスク内に設定するステップ」について、当業者が発明を実施できる程度に記載されているとはいえない。
　
　
（イ）上記請求項１の記載のうち、「デバッグインターフェース」と、「ランタイム」、「タスク」及び「プロセッサ」との関係について検討する。
　上記記載に関し、発明の詳細な説明には、段落【００４７】に、
「【００４７】
  Ｃ．ブレークポイントのデバッグ
  サーフェス上のＤＴＳ（データ変換サービス）でのデバッグの概念は、他の環境でのそれと同様である。パッケージ作成者は、パッケージの実行を停止し、変数を検査および変更して、実行を続行するための方法を必要とする。プログラマは、ブレークポイントを介して実行を制御し、監視を介して変数の検査および修正を行うことによって、これを実行する。ＤＴＳでの異なる点は、実行の多くがランタイムの制御の外にあるパッケージで発生することである。ＤＴＳはＴａｓｋ上のインターフェースメソッドへの呼出し間を除き、またＴａｓｋのスレッドの中断などの強力な戦術を使用した、Ｔａｓｋへのアクセスまたはその制御を持つことがない。ブレークポイントを設定できる場所にわたる、より詳細な制御が望まれる。したがって、オブジェクトモデルは、好ましくは何の変数、イベント、およびメソッドをブレークポイントターゲットにできるかを記述するための方法をＴａｓｋに提供する。インターフェース定義では、デバッグインターフェースを実施することになるエンティティを記述するために、総称「オブジェクト」が使用される。デバッグおよびブレークポイント機能を実現させることを望むオブジェクトモデルにおけるＴａｓｋとオブジェクトは、どちらもこれらのインターフェースを使用しなければならないため、これは、熟慮の上でのことである。」
という記載がある程度にすぎず、
　例えば、「デバッグインターフェース」は、「ランタイム」又は「プロセッサ」に含まれるものであるのか、あるいは、それ以外の装置上に存在しているのか、不明である。
　また、「デバッグインターフェースによって処理するために、タスクを…受け取る」という記載からすると、「タスク」は、「デバッグインターフェース」によって「処理」されるものである。ここで、「処理」がどのようなものであるのか不明である。
　一方、「ランタイムによって前記タスクの実行中に」との記載からすると、「タスク」は、「ランタイム」によって「実行」されるものである。
　よって、「ランタイム」と「デバッグインターフェース」との関係が不明確であるとともに、「タスク」が、何により、どのように「処理」又は「実行」されるのか不明である。
　したがって、上記請求項１は、「デバッグインターフェース」と、「ランタイム」、「タスク」及び「プロセッサ」との関係が明確に記載されているとはいえない。
　
　
（ウ）上記請求項１に記載されている「前記タスクは、パッケージを実行または配置するための命令を示すもの」について検討する。
　上記記載に関して、発明の詳細な説明には、の段落【００４８】に、
「例示的な実施では、ユーザはＴａｓｋを有するパッケージを作成する。・・・」、
段落【００４９】に、
「第２の例示的実施では、プログラマは、１つのループ内で実行される２つのＴａｓｋを備えたパッケージを有する。・・・」、
段落【００６０】に、
「・・・。次にランタイムは、５．２番の矢印によって示されるように、実行されたパッケージのタスクを実行する。・・・」、
段落【００６１】に、
「・・・。クライアントは４２５でパッケージを実行し、ランタイムはブロック４３０でこのタスクを実行する。・・・」
という記載がなされている。
　しかしながら、上記各記載を見ても、「タスク」は、「命令」をどのように「示す」のか、不明である。
　また、どこに存在する「パッケージ」を「実行」するのか、あるいは、「パッケージ」をどこに「配置」するのか、具体的に想定することができない。
　さらに、「パッケージ」を「配置」することについては、発明の詳細な説明には全く記載がなく、「パッケージ」を「配置」するとはどのようなことであるのか不明である。
　よって、上記請求項１は「前記タスクは、パッケージを実行または配置するための命令を示すもの」について、明確に記載されていない。
　
　上記（ア）より、本願の発明の詳細な説明は、上記請求項１に記載された発明について、その発明の属する技術の分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記載したものであるとはいえない。そして、上記請求項１に記載された発明は発明の詳細な説明に記載したものでもない。
　また、上記（イ）〜（ウ）より、上記請求項１に記載された発明は、依然として明確でない。
　
　なお、上記（２−６）で摘記した回答書における補正案をもってしても、依然として、上記明細書及び特許請求の範囲の記載の不備が解消されるものではないため、上記補正案は採用しない。
　
　
４．むすび
　以上のとおり、本願は、明細書及び特許請求の範囲の記載が、特許法第３６条第４項第１号並びに第６項第１号及び第２号に規定する要件を満たしていない。
　よって、結論のとおり審決する。