• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 補正却下を取り消す 原査定を取り消し、特許すべきものとする  G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 補正却下を取り消す 原査定を取り消し、特許すべきものとする  G06F
審判 査定不服 特174条1項 補正却下を取り消す 原査定を取り消し、特許すべきものとする  G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 補正却下を取り消す 原査定を取り消し、特許すべきものとする  G06F
管理番号 1303624
審判番号 不服2014-19515  
総通号数 189 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-09-25 
種別 拒絶査定不服の審決 
審判請求日 2014-09-30 
確定日 2015-08-18 
事件の表示 特願2012- 90177「処理状態が遷移する複数のプログラムを実行する装置及び方法」拒絶査定不服審判事件〔平成24年 8月16日出願公開、特開2012-155741、請求項の数(16)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,平成19年7月10日に出願した特願2007-181345号の一部を,平成20年4月10日に新たに出願した特願2008-102324号の一部を,さらに,平成24年4月11日に新たな特許出願としたものであって,その手続の経緯は以下のとおりである。

平成24年 5月 9日 :出願審査請求書,手続補正書の提出
平成25年 8月 6日付け :拒絶理由の通知
平成25年10月15日 :意見書,手続補正書の提出
平成26年 1月28日付け :最後の拒絶理由の通知
平成26年 4月 4日 :意見書,手続補正書の提出
平成26年 6月23日付け :補正の却下の決定,拒絶査定
平成26年 9月30日 :審判請求書の提出
平成27年 5月 1日付け :当審の拒絶理由の通知
平成27年 6月17日 :意見書,手続補正書の提出

また,本件審判請求の趣旨は,「原査定を取り消す,この出願の発明は,これを特許すべきものとする,との審決を求める」ものであり,
本件審判請求は,その理由の「4.本件発明が特許されるべき理由」において,「平成26年4月4日付けの手続補正書についての補正却下の決定は不適法」である旨を主張するものである。

第2 平成26年6月23日付けの補正の却下の決定の適否

請求人は,審判請求の理由において,平成26年4月4日付けの手続補正に対する補正の却下の決定に対して,不服の申し立てを主張しているので,上記補正の却下の決定の適否について検討する。

1.原審における補正の却下の決定の概要

上記補正の却下の決定の概要は,次のとおりである。

『補正後の請求項1に記載された「前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第1の制限の範囲内である場合に,前記一のプログラムの状態遷移の発生に応じて,前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づき第2の制限の範囲内であるか否かを判定する」は,当初明細書,特許請求の範囲及び図面に記載された事項の範囲内にあるものではない。
例えば,段落【0120】-【0122】及び図17には,アプリAとアプリBが各々単独でメモリ消費量の制限値を超えていなくとも,同時に起動された場合には両アプリの合計メモリ消費量が前記制限値を超える場合がある消費パターンが示されており,当該消費パターンを検知可能とするために,段落【0123】-【0129】,図18及び図19には,前記両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定することが記載されているにすぎず,アプリAの全ての遷移先状態におけるメモリ消費量の最大のものと第1の制限値とを比較する処理を行った上で,さらに,アプリAの遷移先状態のメモリ消費量とアプリBのメモリ消費量とを第2の制限値と比較する処理を行うことは記載されていない。』

2.当審の判断

(1)補正の却下の決定の理由
上記補正の却下の決定の概要では,平成26年4月4日付けの手続補正で補正された特許請求の範囲の請求項1(以下,「補正後の請求項1」という。)に記載の事項が,当初明細書,特許請求の範囲及び図面(以下,「当初明細書等」という。)に記載された事項の範囲内にあるものではない理由として,
『アプリAとアプリBが各々単独でメモリ消費量の制限値を超えていなくとも,同時に起動された場合には両アプリの合計メモリ消費量が前記制限値を超える』課題を解決するために,
『前記両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定すること』が記載されているにすぎないことを根拠としており,
上記構成に対応する「第二の実施の形態」において,判定処理が1種類しか記載されてないことを,上記補正の却下の決定の理由としている。

(2)当初明細書等の記載
しかるに,当初明細書等(下線は,参考のために当審で附加したものである。)には,
『続いて,仮起動サービス333は,メインスクリプト71(図9)の記述713に基づいて,仮起動の成否の判定を行う。記述713では,消費メモリが5MB以下であること,HDD233への書き込みが無いこと,及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって,仮起動サービス333は,仮起動ログ80内おいて,「Memｏｒｙ,Heaｐ=×××MB」という形式で記録されているヒープメモリの消費量のログの中で最大値を検索し,当該最大値が5MB以下であるか否かを確認する。(後略)』(段落[0099]),及び,

『第二の実施の形態において,メインスクリプト71は,次のように定義される。図18は,第二の実施の形態におけるメインスクリプトの記述例を示す図である。図18中,図9と同一部分には同一符号を付し,その説明は省略する。なお,第二の実施の形態において,メインスクリプト71は,メインスクリプト71aとして説明する。』(段落[0124]),及び,
『メインスクリプト71aは,第一の実施の形態と比較して記述716が異なる。(後略)』(段落[0125]),及び,
『第二の実施の形態における,複合機10の仮起動に関する処理手順は,図7とほぼ同様である。但し,メインスクリプト71aにおける記述716に基づいて,ステップS160において,仮起動サービス333は,仮起動の成否を示す情報と共に,仮起動ログ80の内容をSASマネージャ31に通知する。(後略)』(段落[0126]),及び,
『第二の実施の形態では,また,ステップS167においてアプリケーションの起動要求を受けた際におけるSASマネージャ31による,起動中(起動開始時も含む)のアプリケーションの管理に関する処理が異なる。』(段落[0127]),及び,

『複合機10において,状態遷移(起動によるiniｔ状態への遷移も含む)の必要なアプリケーション(以下,「アプリA」という。)が発生すると(S201でYeｓ),SASマネージャ31は,アプリAの遷移先の状態のメモリ消費量の最大値と,現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値(例えば,5MB)以下であるか否かを判定する(S202)。』(段落[0129]),及び,

『なお,第二の実施の形態では,仮起動時に,全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示した(メインスクリプト71a(図18)の記述713参照)。したがって,当該制限を満たしたアプリケーションのみが,本起動の対象とされる前提で,図19の処理手順を説明した。(後略)』(段落[0141])と記載されていることから,
当初明細書等には,
(A)仮起動サービスが,アプリケーションの仮起動時に,「全状態を通したメモリの消費量」の最大値と制限値を比較して判定し,
(B)SASマネージャが,アプリケーションの状態遷移時に,「遷移先の状態のメモリ消費量」の最大値と,現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との「合計」と制限値を比較して判定する,
2種類のメモリ消費量制限の判定処理が記載されているものと認められる。

(3)補正の却下の決定の理由に記載の構成
特に,当初明細書等に記載の構成では,複数のアプリケーションのメモリ消費量の「合計」が制限値の範囲内であるか否かを判定する際には,「全ての遷移先状態」のメモリ消費量ではなく,これから状態遷移しようとする1つの「遷移先状態」のメモリ消費量と他のアプリケーションのメモリ消費量の合計に基づいて判定している。

一方,上記補正の却下の決定の理由に記載の「両アプリの全ての遷移先状態におけるメモリ消費量の合計が前記制限値の範囲内であるか否かを判定する」処理は,本願の当初明細書等に記載されているか明らかではない。

(4)補正の却下の決定の理由の下線部について
また,上記補正の却下の決定の理由において,補正後の請求項1の「第1の制限の範囲内である場合」と「第2の制限の範囲内であるか否かを判定する」に下線部を引いているものの,
それ以降の記載からは,該下線は,当初明細書等に,メモリ判定処理が1種類しかないにも関わらず,補正後の請求項1に係る発明に2種類のメモリ判定処理が含まれることを示そうとしたものとも考えられる。

(5)以上からすると,上記補正の却下の決定は,判断の理由として,本願の当初明細書等の認定についての記載が不十分であったと考えられる。
したがって,補正後の請求項1に係る発明は,当初明細書等に記載されているといえ,明細書の要旨を変更するものではない。

3.補正の却下の決定についてのむすび
以上のとおりであるから,平成26年4月4日付けの手続補正を却下すべきものとした原審の決定は妥当なものではない。
よって,平成26年6月23日付けでなされた平成26年4月4日付けの手続補正に対する補正の却下の決定を取り消す。

第3 本願発明

本願の請求項1-16に係る発明は,平成27年6月17日付けの手続補正で補正された特許請求の範囲の請求項1-16に記載された事項により特定されるものと認められるところ,本願の請求項1に係る発明(以下,「本願発明」という。)は以下のとおりである。

「処理状態が遷移する複数のプログラムを実行する装置であって,
前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために各処理状態において消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と,
前記一のプログラムによる状態遷移の発生を検知する検知手段と,
前記動作情報取得手段により取得された動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量が所定の制限値以下である場合に,前記一のプログラムの状態遷移の発生に応じて,前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づく消費量が,前記所定の制限値以下であるか否かを判定する判定手段と,
前記判定手段の判定に基づいて,前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」

第4 当審の判断

1.当審拒絶理由の概要

平成26年6月23日付けでした補正の却下が不適法であったので,平成26年4月4日付けでした手続補正により補正された明細書等に基づいて通知した当審拒絶理由の概要は,次のとおりである。

『1.(新規事項)平成26年4月4日付けでした手続補正は,下記の点で願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから,特許法第17条の2第3項に規定する要件を満たしていない。

2.(サポート要件)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号に規定する要件を満たしていない。

3.(委任省令要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。

4.(明確性要件)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。

記

●理由1について

・請求項 1?16
平成26年4月4日付け手続補正(以下,「本件補正」という。)による補正後の特許請求の範囲の請求項1(以下,「本願請求項1」という。)において,
「処理状態が遷移する複数のプログラムを実行する装置であって,
前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と,
前記一のプログラムによる状態遷移の発生を検知する検知手段と,
前記動作情報取得手段により取得された動作情報に基づいて,前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第1の制限の範囲内である場合に,前記一のプログラムの状態遷移の発生に応じて,前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づき第2の制限の範囲内であるか否かを判定する判定手段と,
前記判定手段の判定に基づいて,前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」
について記載している(下線は,参考のために当審で附加したものである。)。

しかるに,願書に最初に添付した明細書,特許請求の範囲又は図面(以下,「当初明細書等」という。)には,

『続いて,仮起動サービス333は,メインスクリプト71(図9)の記述713に基づいて,仮起動の成否の判定を行う。記述713では,消費メモリが5MB以下であること,HDD233への書き込みが無いこと,及びスキャンモードはモノクロであることが仮起動の成功の条件とされている。したがって,仮起動サービス333は,仮起動ログ80内おいて,「Memｏｒｙ,Heaｐ=×××MB」という形式で記録されているヒープメモリの消費量のログの中で最大値を検索し,当該最大値が5MB以下であるか否かを確認する。(後略)』(段落[0099]),及び,

『第二の実施の形態において,メインスクリプト71は,次のように定義される。図18は,第二の実施の形態におけるメインスクリプトの記述例を示す図である。図18中,図9と同一部分には同一符号を付し,その説明は省略する。なお,第二の実施の形態において,メインスクリプト71は,メインスクリプト71aとして説明する。(後略)』(段落[0124]),及び,
『メインスクリプト71aは,第一の実施の形態と比較して記述716が異なる。(後略)』(段落[0125]),及び,
『第二の実施の形態における,複合機10の仮起動に関する処理手順は,図7とほぼ同様である。但し,メインスクリプト71aにおける記述716に基づいて,ステップS160において,仮起動サービス333は,仮起動の成否を示す情報と共に,仮起動ログ80の内容をSASマネージャ31に通知する。(後略)』(段落[0126]),及び,
『第二の実施の形態では,また,ステップS167においてアプリケーションの起動要求を受けた際におけるSASマネージャ31による,起動中(起動開始時も含む)のアプリケーションの管理に関する処理が異なる。』(段落[0127]),及び,

『複合機10において,状態遷移(起動によるiniｔ状態への遷移も含む)の必要なアプリケーション(以下,「アプリA」という。)が発生すると(S201でYeｓ),SASマネージャ31は,アプリAの遷移先の状態のメモリ消費量の最大値と,現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計が予め設定されている制限値(例えば,5MB)以下であるか否かを判定する(S202)。』(段落[0129]),及び,

『なお,第二の実施の形態では,仮起動時に,全状態を通したメモリの消費量の最大値が制限値以下であるか否かが判断された例を示した(メインスクリプト71a(図18)の記述713参照)。したがって,当該制限を満たしたアプリケーションのみが,本起動の対象とされる前提で,図19の処理手順を説明した。(後略)』(段落[0141])と記載されており,

仮起動サービスが,アプリケーションの仮起動時に,全状態を通したメモリの消費量の最大値と「制限値」を比較して判定し,
SASマネージャが,アプリケーションの状態遷移時に,遷移先の状態のメモリ消費量の最大値と,現在本起動中の他のアプリケーションのそれぞれの状態におけるメモリ消費量の最大値との合計と「制限値」を比較して判定する構成が記載されるものの,
段落[0129],[0141]に記載されるように,前者の判定処理も後者の判定処理も「制限値」なる用語を用いており,具体的な制限値(5MB)も1種類しか開示されていない。
このため本願請求項1に記載の「第1の制限の範囲」及び「第2の制限の範囲」の2種類の制限の範囲を用いて判定する構成は,当初明細書等に記載も示唆もされておらず,また,当初明細書等の記載から自明なものでもない。

したがって,当業者が当初明細書等の記載から,本願請求項1に係る発明を導き出すことができたとすることはできない。
このため,本件補正は,当初明細書等の全ての記載を総合することにより導かれる技術的事項との関係において,新たな事項を導入するものであるから,当初明細書等に記載した事項の範囲内においてしたものではないため,特許法第17条の2第3項に規定する要件を満たしていない。
請求項2?16も同様である。

●理由2について

・請求項 1?16
補正後の請求項1は,「前記動作情報取得手段により取得された動作情報に基づいて,前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第1の制限の範囲内である場合に,前記一のプログラムの状態遷移の発生に応じて,前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づき第2の制限の範囲内であるか否かを判定する判定手段」を有することを特徴とする「装置」に関するものである。

しかしながら,補正後の発明の詳細な説明では,請求項1に記載された「第1の制限の範囲」及び「第2の制限の範囲」の2種類の制限の範囲を用いて判定する構成について,請求項の範囲と共に補正された明細書の段落[0008]に課題を解決するための手段として請求項1と同様の記載しかなされていない。

また,補正された明細書には,
「図17は,複数のアプリケーションを並列して起動した場合のメモリの消費の様子を説明するための図である。」(段落[0119]),及び,
「(前略)この場合,全状態を通して,アプリBのヒープメモリの最大の消費量は3MBであり,第一の実施の形態における制限である5MBを満たしている。したがって,アプリBについても,仮起動は成功であると判定され,本起動が可能となる。」(段落[0121]),及び,
「(前略)すなわち,本起動が許可された二つのアプリケーションが同時に起動され,同じタイミングで状態遷移が行われた場合(中略)iniｔ状態において,制限値である5MBを超えてしまい,アプリケーションが正常に動作しない可能性がある。」(段落[0123]),及び,
「そこで,第二の実施の形態では,斯かる課題を解決した例について説明する。」(段落[0123])と記載され,
請求項1に係る発明に対応する第二の実施の形態は,複数のアプリケーションを並列して起動した場合に「第一の実施の形態における制限である5MB」(請求項1の「第1の制限の範囲」に相当)を超えてしまい,アプリケーションが正常に動作しない可能性があるという課題しか記載されていない。

このため,補正後の発明の詳細な説明では,「第1の制限の範囲」及び「第2の制限の範囲」の2種類の制限の範囲を用いて判定する構成に係る具体的な課題や構成は記載も示唆もされておらず,
請求項1に係る発明は,発明の詳細な説明において,発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものである。
よって,請求項1に係る発明は,発明の詳細な説明に記載したものでない。
請求項2?16も同様である。

●理由3について

・請求項 1?16
請求項1に係る発明は,第二の実施の形態に対応するものであるが,
前記理由2で検討した請求項1に係る発明の課題と,その解決手段である「第2の制限の範囲」との関係は明らかでなく,本発明の技術上の意義は不明である。
よって,この出願の発明の詳細な説明は,請求項1に係る発明について,経済産業省令で定めるところにより記載されたものでない。
請求項2?16も同様である。

●理由4について

(1)請求項 1?16
本願請求項1に記載の「第1の制限の範囲」及び「第2の制限の範囲」について,両者の関係が特定されておらず,例えば,両者が同一のものであるのか否か,不明瞭である。
したがって,請求項1に係る発明は,特許を受けようとする発明の範囲が不明確である。請求項2?16も同様である。

(2)請求項 2?8
本願請求項2に記載の「予め設定された制限の範囲」,並びに,該請求項2が引用する本願請求項1に記載の「第1の制限の範囲」及び「第2の制限の範囲」について,相互の関係が特定されておらず,不明瞭である。
したがって,請求項2に係る発明は,特許を受けようとする発明の範囲が不明確である。
請求項2を引用する請求項3?8も同様である。

(3)請求項 10?16
本願請求項10に記載の「予め設定された制限の範囲」,並びに,該請求項10が引用する本願請求項9に記載の「第1の制限の範囲」及び「第2の制限の範囲」について,相互の関係が特定されておらず,不明瞭である。
したがって,請求項10に係る発明は,特許を受けようとする発明の範囲が不明確である。
請求項10を引用する請求項11?16も同様である。

(4)請求項 1?16
本願請求項1に記載の「前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のものが第1の制限の範囲内である場合」について,
資源の消費量が最大の「遷移」と「第1の制限の範囲」とを比較しているが,
「遷移」と「第1の制限の範囲」(制限値)との比較処理が何を意味するのかについて不明瞭である。

本願明細書には『(前略)図示されるように,アプリAは,iniｔ状態,ｐaｕｓe状態,acｔiｖe状態の各状態において,それぞれ,最大で3MB,1MB,4MBのヒープメモリを消費する。この場合,全状態を通して,アプリAのヒープメモリの最大の消費量は4MBであり,第一の実施の形態における制限である5MBを満たしている。したがって,アプリAについては,仮起動は成功であると判定され,本起動が可能となる。』(段落[0120])と記載されており,
「資源の消費量」は,「遷移」でなく,1つの「状態」に関連付けられる値である点が開示されているが,
2状態間の「遷移」と「第1の制限の範囲」(制限値)との比較処理が何を意味するのかについては,本願の発明の詳細な説明を参酌しても,不明瞭である。
したがって,請求項1に係る発明は,特許を受けようとする発明の範囲が不明確である。請求項2?16も同様である。』

2.当審拒絶理由の判断
(1)平成27年6月17日付け手続補正書によって,本願の請求項1は
「処理状態が遷移する複数のプログラムを実行する装置であって,
前記複数のプログラムの内の一のプログラムによる当該装置の機能を実行するために各処理状態において消費される所定の資源の消費量を含むプログラムの動作情報を取得する動作情報取得手段と,
前記一のプログラムによる状態遷移の発生を検知する検知手段と,
前記動作情報取得手段により取得された動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量が所定の制限値以下である場合に,前記一のプログラムの状態遷移の発生に応じて,前記一のプログラムの遷移先の状態における所定の資源の消費量と既に起動されている他のプログラムそれぞれの状態における前記所定の資源の消費量とに基づく消費量が,前記所定の制限値以下であるか否かを判定する判定手段と,
前記判定手段の判定に基づいて,前記一のプログラムの遷移先への移行を制御する制御手段とを有することを特徴とする装置。」
と補正された。

(2)特に,請求項1において,「第1の制限の範囲」及び「第2の制限の範囲」が,「所定の制限の範囲」に補正された。
このことにより,請求項1に係る発明は明確となり,かつ,技術上の意義が明らかとなり,発明の詳細な説明に記載されたものとなった。
請求項1の従属項又はカテゴリを変更した請求項である請求項2?16についても同様である。

よって,当審拒絶理由1?3及び理由4(1)?(3)は解消した。

(3)また,特に,請求項1において,「動作情報に基づいて,前記一のプログラムの全ての遷移のうち前記動作情報に含まれる資源の消費量の最大のもの」が,「動作情報に含まれる前記一のプログラムの全ての前記処理状態における前記消費量のうちの最大の消費量」に補正された。
このことにより,請求項1に係る発明は明確となった。
請求項1の従属項又はカテゴリを変更した請求項である請求項2?16についても同様である。

よって,当審拒絶理由4(4)は解消した。

第5 むすび
以上のとおり,当審拒絶理由によっては本願を拒絶することはできない。そして,原査定は上記補正の却下を前提としたものであり,原査定の拒絶理由を検討しても,その理由によって拒絶すべきものとすることはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2015-08-06 
出願番号 特願2012-90177(P2012-90177)
審決分類 P 1 8・ 561- WYA (G06F)
P 1 8・ 537- WYA (G06F)
P 1 8・ 536- WYA (G06F)
P 1 8・ 55- WYA (G06F)
最終処分 成立  
前審関与審査官 多胡 滋  
特許庁審判長 高木 進
特許庁審判官 戸島 弘詩
田中 秀人
発明の名称 処理状態が遷移する複数のプログラムを実行する装置及び方法  
代理人 伊東 忠重  
代理人 伊東 忠彦  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ