【事件の表示】
　特願２０１２−　９０１７７「処理状態が遷移する複数のプログラムを実行する装置及び方法」拒絶査定不服審判事件〔平成２４年　８月１６日出願公開、特開２０１２−１５５７４１、請求項の数（１６）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，平成１９年７月１０日に出願した特願２００７−１８１３４５号の一部を，平成２０年４月１０日に新たに出願した特願２００８−１０２３２４号の一部を，さらに，平成２４年４月１１日に新たな特許出願としたものであって，その手続の経緯は以下のとおりである。
　　平成２４年　５月　９日　　　：出願審査請求書，手続補正書の提出
　　平成２５年　８月　６日付け　：拒絶理由の通知
　　平成２５年１０月１５日　　　：意見書，手続補正書の提出
　　平成２６年　１月２８日付け　：最後の拒絶理由の通知
　　平成２６年　４月　４日　　　：意見書，手続補正書の提出
　　平成２６年　６月２３日付け　：補正の却下の決定，拒絶査定
　　平成２６年　９月３０日　　　：審判請求書の提出
　　平成２７年　５月　１日付け　：当審の拒絶理由の通知
　　平成２７年　６月１７日　　　：意見書，手続補正書の提出
　また，本件審判請求の趣旨は，「原査定を取り消す，この出願の発明は，これを特許すべきものとする，との審決を求める」ものであり，
　本件審判請求は，その理由の「４．本件発明が特許されるべき理由」において，「平成２６年４月４日付けの手続補正書についての補正却下の決定は不適法」である旨を主張するものである。
第２　平成２６年６月２３日付けの補正の却下の決定の適否
　請求人は，審判請求の理由において，平成２６年４月４日付けの手続補正に対する補正の却下の決定に対して，不服の申し立てを主張しているので，上記補正の却下の決定の適否について検討する。
１．原審における補正の却下の決定の概要
　上記補正の却下の決定の概要は，次のとおりである。
『補正後の請求項１に記載された「前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが
第１の制限の範囲内である場合に
第２の制限の範囲内であるか否かを判定する
　例えば，段落【０１２０】−【０１２２】及び図１７には，アプリＡとアプリＢが各々単独でメモリ消費量の制限値を超えていなくとも，同時に起動された場合には両アプリの合計メモリ消費量が前記制限値を超える場合がある消費パターンが示されており，当該消費パターンを検知可能とするために，段落【０１２３】−【０１２９】，図１８及び図１９には，前記両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定することが記載されているにすぎず，アプリＡの全ての遷移先状態におけるメモリ消費量の最大のものと第１の制限値とを比較する処理を行った上で，さらに，アプリＡの遷移先状態のメモリ消費量とアプリＢのメモリ消費量とを第２の制限値と比較する処理を行うことは記載されていない。』
２．当審の判断
（１）補正の却下の決定の理由
　上記補正の却下の決定の概要では，平成２６年４月４日付けの手続補正で補正された特許請求の範囲の請求項１（以下，「補正後の請求項１」という。）に記載の事項が，当初明細書，特許請求の範囲及び図面（以下，「当初明細書等」という。）に記載された事項の範囲内にあるものではない理由として，
　『アプリＡとアプリＢが各々単独でメモリ消費量の制限値を超えていなくとも，同時に起動された場合には両アプリの合計メモリ消費量が前記制限値を超える』課題を解決するために，
　『前記両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定すること』が記載されているにすぎないことを根拠としており，
　上記構成に対応する「第二の実施の形態」において，判定処理が１種類しか記載されてないことを，上記補正の却下の決定の理由としている。
（２）当初明細書等の記載
　しかるに，当初明細書等（下線は，参考のために当審で附加したものである。）には，
『続いて，仮起動サービス３３３は，メインスクリプト７１（図９）の記述７１３に基づいて，仮起動の成否の判定を行う。記述７１３では，消費メモリが５ＭＢ以下であること，ＨＤＤ２３３への書き込みが無いこと，及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって，
仮起動サービス３３３は，
ヒープメモリの消費量のログの中で最大値を検索し，当該最大値が５ＭＢ以下であるか否かを確認する。
　『第二の実施の形態において，メインスクリプト７１は，次のように定義される。図１８は，第二の実施の形態におけるメインスクリプトの記述例を示す図である。図１８中，図９と同一部分には同一符号を付し，その説明は省略する。なお，
第二の実施の形態において，メインスクリプト７１は，メインスクリプト７１ａとして説明する。
　『
メインスクリプト７１ａは，第一の実施の形態と比較して記述７１６が異なる。
　『第二の実施の形態における，複合機１０の仮起動に関する処理手順は，図７とほぼ同様である。但し，メインスクリプト７１ａにおける
記述７１６に基づいて，
仮起動サービス３３３は，
仮起動ログ８０の内容をＳＡＳマネージャ３１に通知する。
　『
第二の実施の形態では，
ＳＡＳマネージャ３１による，起動中
のアプリケーションの管理に関する処理が異なる。
　『複合機１０において，状態遷移（起動によるｉｎｉｔ状態への遷移も含む）の必要なアプリケーション（以下，「アプリＡ」という。）が発生すると（Ｓ２０１でＹｅｓ），
ＳＡＳマネージャ３１は，アプリＡの遷移先の状態のメモリ消費量の最大値と，現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値（例えば，５ＭＢ）以下であるか否かを判定する
　『なお，
第二の実施の形態では，仮起動時に，全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示した
当該制限を満たしたアプリケーションのみが，本起動の対象とされる前提
　当初明細書等には，
（Ａ）仮起動サービスが，アプリケーションの仮起動時に，「全状態を通したメモリの消費量」の最大値と制限値を比較して判定し，
（Ｂ）ＳＡＳマネージャが，アプリケーションの状態遷移時に，「遷移先の状態のメモリ消費量」の最大値と，現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との「合計」と制限値を比較して判定する，
２種類のメモリ消費量制限の判定処理が記載されているものと認められる。
（３）補正の却下の決定の理由に記載の構成
　特に，当初明細書等に記載の構成では，複数のアプリケーションのメモリ消費量の「合計」が制限値の範囲内であるか否かを判定する際には，「全ての遷移先状態」のメモリ消費量ではなく，これから状態遷移しようとする１つの「遷移先状態」のメモリ消費量と他のアプリケーションのメモリ消費量の合計に基づいて判定している。
　一方，上記補正の却下の決定の理由に記載の「両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定する」処理は，本願の当初明細書等に記載されているか明らかではない。
（４）補正の却下の決定の理由の下線部について
　また，上記補正の却下の決定の理由において，補正後の請求項１の「第１の制限の範囲内である場合」と「第２の制限の範囲内であるか否かを判定する」に下線部を引いているものの，
　それ以降の記載からは，該下線は，当初明細書等に，メモリ判定処理が１種類しかないにも関わらず，補正後の請求項１に係る発明に２種類のメモリ判定処理が含まれることを示そうとしたものとも考えられる。
（５）以上からすると，上記補正の却下の決定は，判断の理由として，本願の当初明細書等の認定についての記載が不十分であったと考えられる。
　したがって，補正後の請求項１に係る発明は，当初明細書等に記載されているといえ，明細書の要旨を変更するものではない。
３．補正の却下の決定についてのむすび
　以上のとおりであるから，平成２６年４月４日付けの手続補正を却下すべきものとした原審の決定は妥当なものではない。
　よって，平成２６年６月２３日付けでなされた平成２６年４月４日付けの手続補正に対する補正の却下の決定を取り消す。
第３　本願発明
　本願の請求項１−１６に係る発明は，平成２７年６月１７日付けの手続補正で補正された特許請求の範囲の請求項１−１６に記載された事項により特定されるものと認められるところ，本願の請求項１に係る発明（以下，「本願発明」という。）は以下のとおりである。
「処理状態が遷移する複数のプログラムを実行する装置であって，
　前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために各処理状態において消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と，
　前記一のプログラムによる状態遷移の発生を検知する検知手段と，
　前記動作情報取得手段により取得された動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量が所定の制限値以下である場合に，前記一のプログラムの状態遷移の発生に応じて，前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づく消費量が，前記所定の制限値以下であるか否かを判定する判定手段と，
　前記判定手段の判定に基づいて，前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」
第４　当審の判断
１．当審拒絶理由の概要
　平成２６年６月２３日付けでした補正の却下が不適法であったので，平成２６年４月４日付けでした手続補正により補正された明細書等に基づいて通知した当審拒絶理由の概要は，次のとおりである。
『１．（新規事項）平成２６年４月４日付けでした手続補正は，下記の点で願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから，特許法第１７条の２第３項に規定する要件を満たしていない。
２．（サポート要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていない。
３．（委任省令要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。
４．（明確性要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
●理由１について
・請求項　１〜１６
　平成２６年４月４日付け手続補正（以下，「本件補正」という。）による補正後の特許請求の範囲の請求項１（以下，「本願請求項１」という。）において，
　「処理状態が遷移する複数のプログラムを実行する装置であって，
　前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と，
　前記一のプログラムによる状態遷移の発生を検知する検知手段と，
　前記動作情報取得手段により取得された動作情報に基づいて，前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第１の制限の範囲内である場合に，前記一のプログラムの状態遷移の発生に応じて，前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づき第２の制限の範囲内であるか否かを判定する判定手段と，
　前記判定手段の判定に基づいて，前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」
について記載している（下線は，参考のために当審で附加したものである。）。
　しかるに，願書に最初に添付した明細書，特許請求の範囲又は図面（以下，「当初明細書等」という。）には，
『続いて，仮起動サービス３３３は，メインスクリプト７１（図９）の記述７１３に基づいて，仮起動の成否の判定を行う。記述７１３では，消費メモリが５ＭＢ以下であること，ＨＤＤ２３３への書き込みが無いこと，及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって，
仮起動サービス３３３は，
ヒープメモリの消費量のログの中で最大値を検索し，当該最大値が５ＭＢ以下であるか否かを確認する。
　『第二の実施の形態において，メインスクリプト７１は，次のように定義される。図１８は，第二の実施の形態におけるメインスクリプトの記述例を示す図である。図１８中，図９と同一部分には同一符号を付し，その説明は省略する。なお，
第二の実施の形態において，メインスクリプト７１は，メインスクリプト７１ａとして説明する。
　『
メインスクリプト７１ａは，第一の実施の形態と比較して記述７１６が異なる。
　『第二の実施の形態における，複合機１０の仮起動に関する処理手順は，図７とほぼ同様である。但し，メインスクリプト７１ａにおける
記述７１６に基づいて，
仮起動サービス３３３は，
仮起動ログ８０の内容をＳＡＳマネージャ３１に通知する。
　『
第二の実施の形態では，
ＳＡＳマネージャ３１による，起動中
のアプリケーションの管理に関する処理が異なる。
　『複合機１０において，状態遷移（起動によるｉｎｉｔ状態への遷移も含む）の必要なアプリケーション（以下，「アプリＡ」という。）が発生すると（Ｓ２０１でＹｅｓ），
ＳＡＳマネージャ３１は，アプリＡの遷移先の状態のメモリ消費量の最大値と，現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値（例えば，５ＭＢ）以下であるか否かを判定する
　『なお，
第二の実施の形態では，仮起動時に，全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示した
当該制限を満たしたアプリケーションのみが，本起動の対象とされる前提
　仮起動サービスが，アプリケーションの仮起動時に，全状態を通したメモリの消費量の最大値と「制限値」を比較して判定し，
　ＳＡＳマネージャが，アプリケーションの状態遷移時に，遷移先の状態のメモリ消費量の最大値と，現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計と「制限値」を比較して判定する構成が記載されるものの，
　段落［０１２９］，［０１４１］に記載されるように，前者の判定処理も後者の判定処理も「制限値」なる用語を用いており，具体的な制限値（５ＭＢ）も１種類しか開示されていない。
　このため本願請求項１に記載の「第１の制限の範囲」及び「第２の制限の範囲」の２種類の制限の範囲を用いて判定する構成は，当初明細書等に記載も示唆もされておらず，また，当初明細書等の記載から自明なものでもない。
　したがって，当業者が当初明細書等の記載から，本願請求項１に係る発明を導き出すことができたとすることはできない。
　このため，本件補正は，当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において，新たな事項を導入するものであるから，当初明細書等に記載した事項の範囲内においてしたものではないため，特許法第１７条の２第３項に規定する要件を満たしていない。
　請求項２〜１６も同様である。
●理由２について
・請求項　１〜１６
　補正後の請求項１は，「前記動作情報取得手段により取得された動作情報に基づいて，前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第１の制限の範囲内である場合に，前記一のプログラムの状態遷移の発生に応じて，前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づき第２の制限の範囲内であるか否かを判定する判定手段」を有することを特徴とする「装置」に関するものである。
　しかしながら，補正後の発明の詳細な説明では，請求項１に記載された「第１の制限の範囲」及び「第２の制限の範囲」の２種類の制限の範囲を用いて判定する構成について，請求項の範囲と共に補正された明細書の段落［０００８］に課題を解決するための手段として請求項１と同様の記載しかなされていない。
　また，補正された明細書には，
「図１７は，複数のアプリケーションを並列して起動した場合のメモリの消費の様子を説明するための図である。」（段落［０１１９］），及び，
「（前略）この場合，全状態を通して，アプリＢのヒープメモリの最大の消費量は３ＭＢであり，第一の実施の形態における制限である５ＭＢを満たしている。したがって，アプリＢについても，仮起動は成功であると判定され，本起動が可能となる。」（段落［０１２１］），及び，
「（前略）すなわち，本起動が許可された二つのアプリケーションが同時に起動され，同じタイミングで状態遷移が行われた場合（中略）ｉｎｉｔ状態において，制限値である５ＭＢを超えてしまい，アプリケーションが正常に動作しない可能性がある。」（段落［０１２３］），及び，
「そこで，第二の実施の形態では，斯かる課題を解決した例について説明する。」（段落［０１２３］）と記載され，
　請求項１に係る発明に対応する第二の実施の形態は，複数のアプリケーションを並列して起動した場合に「第一の実施の形態における制限である５ＭＢ」（請求項１の「第１の制限の範囲」に相当）を超えてしまい，アプリケーションが正常に動作しない可能性があるという課題しか記載されていない。
　このため，補正後の発明の詳細な説明では，「第１の制限の範囲」及び「第２の制限の範囲」の２種類の制限の範囲を用いて判定する構成に係る具体的な課題や構成は記載も示唆もされておらず，
　請求項１に係る発明は，発明の詳細な説明において，発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものである。
　よって，請求項１に係る発明は，発明の詳細な説明に記載したものでない。
　請求項２〜１６も同様である。
●理由３について
・請求項　１〜１６
　請求項１に係る発明は，第二の実施の形態に対応するものであるが，
　前記理由２で検討した請求項１に係る発明の課題と，その解決手段である「第２の制限の範囲」との関係は明らかでなく，本発明の技術上の意義は不明である。
　よって，この出願の発明の詳細な説明は，請求項１に係る発明について，経済産業省令で定めるところにより記載されたものでない。
　請求項２〜１６も同様である。
●理由４について
（１）請求項　１〜１６
　本願請求項１に記載の「第１の制限の範囲」及び「第２の制限の範囲」について，両者の関係が特定されておらず，例えば，両者が同一のものであるのか否か，不明瞭である。
　したがって，請求項１に係る発明は，特許を受けようとする発明の範囲が不明確である。請求項２〜１６も同様である。
（２）請求項　２〜８
　本願請求項２に記載の「予め設定された制限の範囲」，並びに，該請求項２が引用する本願請求項１に記載の「第１の制限の範囲」及び「第２の制限の範囲」について，相互の関係が特定されておらず，不明瞭である。
　したがって，請求項２に係る発明は，特許を受けようとする発明の範囲が不明確である。
　請求項２を引用する請求項３〜８も同様である。
（３）請求項　１０〜１６
　本願請求項１０に記載の「予め設定された制限の範囲」，並びに，該請求項１０が引用する本願請求項９に記載の「第１の制限の範囲」及び「第２の制限の範囲」について，相互の関係が特定されておらず，不明瞭である。
　したがって，請求項１０に係る発明は，特許を受けようとする発明の範囲が不明確である。
　請求項１０を引用する請求項１１〜１６も同様である。
（４）請求項　１〜１６
　本願請求項１に記載の「前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第１の制限の範囲内である場合」について，
　資源の消費量が最大の「遷移」と「第１の制限の範囲」とを比較しているが，
　「遷移」と「第１の制限の範囲」（制限値）との比較処理が何を意味するのかについて不明瞭である。
　本願明細書には『（前略）図示されるように，アプリＡは，ｉｎｉｔ状態，ｐａｕｓｅ状態，ａｃｔｉｖｅ状態の各状態において，それぞれ，最大で３ＭＢ，１ＭＢ，４ＭＢのヒープメモリを消費する。この場合，全状態を通して，アプリＡのヒープメモリの最大の消費量は４ＭＢであり，第一の実施の形態における制限である５ＭＢを満たしている。したがって，アプリＡについては，仮起動は成功であると判定され，本起動が可能となる。』（段落［０１２０］）と記載されており，
　「資源の消費量」は，「遷移」でなく，１つの「状態」に関連付けられる値である点が開示されているが，
　２状態間の「遷移」と「第１の制限の範囲」（制限値）との比較処理が何を意味するのかについては，本願の発明の詳細な説明を参酌しても，不明瞭である。
　したがって，請求項１に係る発明は，特許を受けようとする発明の範囲が不明確である。請求項２〜１６も同様である。』
２．当審拒絶理由の判断
（１）平成２７年６月１７日付け手続補正書によって，本願の請求項１は
「処理状態が遷移する複数のプログラムを実行する装置であって，
　前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために各処理状態において消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と，
　前記一のプログラムによる状態遷移の発生を検知する検知手段と，
　前記動作情報取得手段により取得された動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量が所定の制限値以下である場合に，前記一のプログラムの状態遷移の発生に応じて，前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づく消費量が，前記所定の制限値以下であるか否かを判定する判定手段と，
　前記判定手段の判定に基づいて，前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」
と補正された。
（２）特に，請求項１において，「第１の制限の範囲」及び「第２の制限の範囲」が，「所定の制限の範囲」に補正された。
　このことにより，請求項１に係る発明は明確となり，かつ，技術上の意義が明らかとなり，発明の詳細な説明に記載されたものとなった。
　請求項１の従属項又はカテゴリを変更した請求項である請求項２〜１６についても同様である。
　よって，当審拒絶理由１〜３及び理由４（１）〜（３）は解消した。
（３）また，特に，請求項１において，「動作情報に基づいて，前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のもの」が，「動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量」に補正された。
　このことにより，請求項１に係る発明は明確となった。
　請求項１の従属項又はカテゴリを変更した請求項である請求項２〜１６についても同様である。
　よって，当審拒絶理由４（４）は解消した。
第５　むすび
　以上のとおり，当審拒絶理由によっては本願を拒絶することはできない。そして，原査定は上記補正の却下を前提としたものであり，原査定の拒絶理由を検討しても，その理由によって拒絶すべきものとすることはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。