【事件の表示】
　特願２００６−５４９４０６「モデルイベントを用いてモデル構成要素の実行をスケジューリングするためのシステム及び方法」拒絶査定不服審判事件〔平成１７年　８月　４日国際公開、ＷＯ２００５／０７１５３７、平成１９年　７月　５日国内公表、特表２００７−５１８１９０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯・先行技術等
　
１．手続の経緯の概要
　本件請求に係る出願（以下「本願」と記す）は
２００４年１月１５日付けのアメリカ合衆国における出願を基礎としたパリ条約に基づく優先権主張を伴う、
２００５年１月６日を国際出願日とする出願であって、
平成１８年７月１４日付けで特許法第１８４条の５第１項の規定による書面が提出され、
平成１８年９月１４日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文が提出され、
平成２０年１月７日付けで審査請求がなされ、
平成２３年５月１０日付けで拒絶理由通知（平成２３年５月２４日発送）がなされ、これに対して
平成２３年１１月２４日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成２４年１月２６日付けで拒絶査定（平成２４年２月７日謄本発送、送達）がなされたものである。
　
　本件審判請求は、
「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」との請求の趣旨で、
平成２４年６月６日付けでなされたものであって、
同日付けで手続補正書が提出され、
平成２４年９月４日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２４年１１月１５日付けで当該報告に対する意見を求める旨の審尋（平成２４年１１月２０日発送）がなされ、これに対して
平成２５年３月１８日付けで回答書が提出され、
平成２６年１月８日付けで上記平成２４年６月６日付けの手続補正を却下する旨の補正の却下の決定（平成２６年１月２１日発送）がなされるとともに、
同日付けで拒絶理由通知（平成２６年１月１４日発送）がなされ、これに対して、
平成２６年７月１４日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出されたものである。
　
　
２．拒絶理由・補正の内容・意見書の主張等
　
（１）当審拒絶理由
　上記平成２６年１月８日付け拒絶理由通知（以下「当審拒絶理由通知」と記す。）で通知された拒絶理由（以下「当審拒絶理由」と記す。）の内容は概略以下のとおりのものである。
　
『１．この出願は、発明の詳細な説明及び特許請求の範囲の記載が下記の点で、特許法第３６条第４項第１号及び第６項第１号、第２号、第３号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　 記
（１）本願請求項１、１９、３０に「実行可能な」「構成要素」とあるが、その意味・定義（「実行可能な」とは「構成要素」が如何なる構成や性質を有することを意味するのか？　なにがこれに該当しなにが該当しないのか？　実行可能なプログラム部品と言う意味なのか？　構成要素が入力を処理して出力を出すと言う意味なのか？　等々）が該請求項の記載からは明確でない。また本願の発明の詳細な説明においても明確に定義がされておらず、本願の発明の詳細な説明を参酌してもこの点は明確でない。
　したがって、本願請求項１〜３２に係る発明は明確でなく、また、本願の発明の詳細な説明に記載されるものではない。
　さらに、このため、本願の発明の詳細な説明は、当業者が本願請求項１〜３２に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項１〜３２に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものであるとも言える。
　
・・・中略・・・
　
（３８）本願の発明の詳細な説明中にも意味の不明確な記載等（下記ア．〜ニ．に例示する。）が散見される。
　このため、本願の発明の詳細な説明は、当業者が本願請求項１〜３２に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項１〜３２に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものである。
　
ア．段落【０００１】の「本願は、その内容を引用して本明細書に援用する２００４年１月１５日に提出された米国特許出願第１０／７５９，３４６号の利益を主張する。」。（削除されたし。）
　
イ．段落【０００３】の『本発明の例示的な実施形態は、「ブロックダイヤグラム・モデリングで実行コンテキストを使用するためのシステム及び方法」と題した現在係属中の米国特許出願第１０／４１４，６４４号に関連し、その内容を引用して本明細書に援用する。』。（削除されたし。）
　
ウ．段落【０００７】の「Simulink（商標）のサンプルレートにより、モデルの構成要素を実行する頻度が指定可能となる。」。（誤訳なのでは？）
　
エ．段落【００１３】【００１４】の「一方法は、前記モデルの実行を指定イベントの発生に関して監視する。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
オ．段落【００１６】の「サンプルレートはイベントとして指定されるので、モデル構成要素の実行をそのモデルの動態に結びつける。」。（なぜこのような因果関係が成り立つのかが、明確に説明されていない。）
　
カ．段落【００１６】の「非連続モデル構成要素を、モデルイベント発生に基づいて条件付きで実行するように構成できる。」。（「非連続モデル構成要素」とは如何なる構成要素なのかの説明がない。）
　
キ．段落【００１６】の「更に、構成要素実行の範囲は、ある種の従来システムで必要となるように、サブシステム全体には制限されない。」。（「ある種の従来システムで必要となるように」とは如何なるシステムの如何なる性質を意味しているのか不明。）
　
ク．段落【００２１】の「因果関係に関連付けられたファーストクラス・オブジェクト「Ａ」が存在するので、色などの特性を構成し、その関係に割り当てることができる。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
ケ．段落【００２２】の『任意イベントの「範囲」とは、それが存在する作業領域の範囲である。』。（技術的に意味不明の記載である。誤訳なのでは？）
　
コ．段落【００２２】の「作業領域がサブシステム又はモデルに関連付けられている場合、イベントの範囲はそのサブシステム又はモデルである。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
サ．段落【００２２】の「ブロックがそのサンプル時間をイベントとして指定できるのは、そのイベントが該ブロックからの範囲内にある場合である。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
シ．段落【００２４】の「実行時間検査を行ってこれらイベントが２０ミリ秒毎に告知されることを表明する。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
ス．段落【００２４】の「イベントのレートを明示的に指定する１つの利点は、そのレートで生成される任意コードが、連続実行の間に経過時間が必要な場合は、通常のようにタイマ使用を必要とするのでなく、この生成コードにおいて対応する定数サンプル時間を使用できることである。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
セ．段落【００３０】の『「ゼロ次保持」ブロック９２はそのサンプルレートが「使用禁止」に指定されているため、』。（【図５】にはそのような記載はない。）
　
ソ．段落各イベントは【００３１】の「各イベントは・・・マッピングする」。（技術的に意味不明の記載である。「イベント」は「マッピング」されるのであって、「マッピングする」は誤訳なのでは？））
　
タ．段落【００３１】の「インライン化」。（その意味（コンパイル時にインライン展開すると言う意味か？　インラインアセンブラで記述したと言う意味か？　一行で記述したという意味か？）が明確で無い。）
　
チ．段落【００３２】の「Simulink（商標）イベントのプロパティの１つはそのタスクである。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
ツ．段落【００３５】の「タスクを用いて、実時間実装においてイベントを用いる際にデータの完全性を保証する助けとするが、これは、データの完全性のためイベント遷移ブロックがどこで必要とされているかを示すことにより達成される。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
テ．段落【００４４】の「当業者であれば、・・・ので、・・・を備えることは重要なことは理解するはずである。」。（文法的に意味不明。誤訳なのでは？）
　
ト．段落【００４５】の「図７Ａのモデルは、アトミック・サブシステムを用いて、例外イベントＢを介して条件付きで回避することを意図した積ブロックの前にスローブロックが実行されるソート済みブロック順序の実行を徹底する。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
ナ．段落【００４５】の「このアトミック・サブシステムはソート済みブロックリストで積ブロックより早いので、スローブロックも含むその内容は積ブロックより前に実行される。」。（技術的に意味不明の記載である。誤訳なのでは？）
　
ニ．段落【００５５】の「連続ステップ」。（誤訳なのでは？）
　
　
２．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　 記　　　（引用文献等については引用文献等一覧参照）
・請　求　項　１〜３２
・引用文献等　１〜４
・備　　　考
　現代制御理論等に対応した所謂リアルタイムシミュレターにおいてイベントドリブン機能を具備せしめることは、引用文献１〜３等に示される如く、当業者にとっては周知慣用技術に過ぎないものである。
　本願請求項１に係る発明は上記理由１．で示したように、必ずしも明確なものではないものの、イベントハンドラを用いてイベントドリブン機能を実現していることが限定されている点で、上記引用文献１〜３に記載のない特徴を有し、その余の点には該周知慣用技術との間に格別な相違は認められない。
　しかしながら、引用文献４等に示される如く、イベントハンドラの採用は、当業者にとってはイベントドリブン機能を実現するための一常套手段に過ぎないものである。
　してみると、本願請求項１に係る発明は、引用文献１〜４記載の発明に基づいて、当業者が容易に発明し得たものである。
　本願請求項２〜１８も常識的な事項を限定しているに過ぎないものと解することができ、引用文献１〜４記載の発明に基づいて、当業者が容易に発明し得たものであると言える。
　本願請求項１９〜２９、３０〜３２にかかる発明も、本願請求項１〜１８に係る発明と同様の理由で、引用文献１〜４記載の発明に基づいて、当業者が容易に発明し得たものである。
　
　　　　　　　　引　用　文　献　等　一　覧
１．石塚 真一，「高度な制御理論に対応した設計が可能になるＭＡＴＬＡＢファミリ」，Ｉｎｔｅｒｆａｃｅ，ＣＱ出版株式会社，平成９年９月１日，第２３巻，第９号，ｐ．８４−８５
２．「ＭＡＴＬＡＢ」，計測と制御，社団法人計測自動制御学会，平成１１年１月１０日，第３８巻, 第１号，ｐ．８０−８１
３．「動的システムをモデリング／シミュレーションするためのツール　Ｓｉｍｕｌｉｎｋの基礎」，Ｉｎｔｅｒｆａｃｅ，ＣＱ出版株式会社，平成１３年１０月１日，第２７巻, 第１０号，ｐ．２８−５２　（特に２８頁「はじめに」中の「Ｓｔａｔｅｆｌｏｗ」に関する記載。）
４．米国特許第５４９７５００号明細書（特に第４９欄第４−３８行。）』
　
（２）平成２６年７月１４日付け手続補正
　上記平成２６年７月１４日付けの手続補正書は特許請求の範囲を、
「　【請求項１】
　複数の実行可能な
ブロック
実行可能なグラフィカルモデルを備えた環境において実行される
ブロックが
　
前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
　
少なくとも1つの実行可能なブロックを前記イベントに関連付ける段階と、
　
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
　
前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデル
　
前記イベントハンドラが前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階と、
　
特定の時刻に応答させるのではなく前記通知
前記少なくとも1つの実行可能なブロック
　　【請求項２】
　前記
少なくとも1つの実行可能なブロック
　　【請求項３】
　
前記少なくとも1つの実行可能なブロックのサンプルレートを前記イベントとして指定する
　　【請求項４】
　前記サンプル
レート
前記少なくとも1つの実行可能なブロックから他の実行可能なブロックに伝播させる
含む
請求項３
　　【請求項５】
　
前記グラフィカルモデルにおいてグループ化されていない非連続の複数の実行可能なブロックのサンプルレートを前記イベントとして指定する段階
請求項３
　　【請求項６】
　
前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックが該ブロック間のグラフィカル結合を伴わずに表示される
請求項５
　　【請求項７】
　前記少なくとも１つの
実行可能なブロック
として指定
前記グラフィカルモデルのビューにおいて前記イベントの名前を
請求項３
　　【請求項８】
　前記イベントがユーザによって設定される明示イベントである、
請求項３
　　【請求項９】
　前記イベントが前記
グラフィカル
伴って自動的に告知される
請求項３
　　【請求項１０】
　前記暗黙イベントがパワーアップ、パワーダウン、及び初期設定の１つである、
請求項９
　　【請求項１１】
　前記暗黙イベントがサブシステムの使用可能及び使用禁止の何れかに対応する、
請求項９
　　【請求項１２】
　
前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックの論理的関連付けをユーザに色で表示する、請求項５
　　【請求項１３】
　
前記告知ブロックは、前記入力信号がゼロを上回る時を条件として前記イベントを告知するよう構成されている
　　【請求項１４】
　前記
グラフィカル
　　【請求項１５】
　前記関数が
コード生成時に
請求項１４
　　【請求項１６】
　前記通知に応答して、分岐優先順位ブロックが少なくとも２つの
実行可能なブロックの
　　【請求項１７】
　前記通知に応答して２つ以上のブロックグループが実行され、該ブロックグループがユーザにより
予め
予め
　　【請求項１８】
　複数の実行可能な
ブロック
実行可能なグラフィカルモデルを備えた環境において実行される
ブロックが
　
前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
　
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
　
前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデル
　
前記イベントの前記告知
別のブロック
　
特定の時刻に応答させるのではなく、前記イベントの前記告知
グラフィカル
　　【請求項１９】
　前記指定イベントが通常イベント
であり
　前記割り込まれた
ブロック
請求項１８
　　【請求項２０】
　前記指定イベントが例外イベント
であり
　前記割り込まれた
ブロック
グラフィカル
ブロック
請求項１８
　　【請求項２１】
　前記イベントが、オブジェクトとして
予め
請求項１８
　　【請求項２２】
　前記イベントが明示イベントである、
請求項２１
　　【請求項２３】
　前記イベントが暗黙イベントである、
請求項２１
　　【請求項２４】
　
前記オブジェクト
のタスク
請求項２１
　　【請求項２５】
　前記タスクオブジェクトが
指定レート
のプロパティを含む
請求項２４
　　【請求項２６】
　
異なるタスクが少なくとも２つのイベントで実行されるように指定されている場合
　イベント遷移
ブロック
ブロック
ブロック
ブロックの間で機能
請求項２５
　　【請求項２７】
　前記演算が分岐優先順位ブロックに示された実行順序により制御される、
請求項１８
　　【請求項２８】
　前記演算が２つ以上のブロックグループの実行であり、該ブロックグループがユーザにより予め選択されたブロックグループであり、該ブロックグループの実行順序がユーザにより予め指定される、
請求項１８
　　【請求項２９】
　
グラフィカルモデリング環境における少なくとも１つの実行可能なグラフィカルモデルの実行を制御するためのコンピュータ実行可能な命令を保持した物理的かつ非一時的なコンピュータ可読媒体であって、前記命令が、
　
前記グラフィカルモデルのビューを複数の実行可能なブロックで表示する１つまたは複数の命令であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する１つまたは複数の命令と、
　
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する１つまたは複数の命令と、
　
前記条件が満足された時に、前記告知ブロックに前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知させる１つまたは複数の命令と、
　
前記イベントの前記発生を、該イベントに関連付けられた前記少なくとも１つの実行可能なブロックに通知する１つまたは複数の命令であって、前記イベントの前記発生が、前記少なくとも１つの実行可能なブロックを実行させる契機となる、通知する１つまたは複数の命令と、
　
前記グラフィカルモデリング環境において、前記グラフィカルモデルのシミュレーション時に、前記少なくとも１つの実行可能なブロックを、特定の時刻に応答するのではなく、前記通知に応答して実行させる１つまたは複数の命令とを含む、非一時的なコンピュータ可読媒体。
　　【請求項３０】
　
前記命令が、前記少なくとも１つの実行可能なブロックを前記イベントハンドラに登録する１つまたは複数の命令を更に含む、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項３１】
　
前記少なくとも1つの告知ブロックがラベルである、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項３２】
　
前記命令が、前記少なくとも1つの実行可能なブロックのサンプルレートを前記イベントとして指定する１つまたは複数の命令を更に含む、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項３３】
　
前記命令が、前記サンプルレートを前記少なくとも1つの実行可能なブロックから他の実行可能なブロックに伝播させる１つまたは複数の命令を更に含み、前記他の実行可能なブロックが前記サンプルレートを継承するように構成される、請求項３２に記載の非一時的なコンピュータ可読媒体。
　　【請求項３４】
　
前記命令が、前記グラフィカルモデルにおいてグループ化されていない非連続の複数の実行可能なブロックのサンプルレートを前記イベントとして指定する１つまたは複数の命令を更に含む、請求項３２に記載の非一時的なコンピュータ可読媒体。
　　【請求項３５】
　
前記命令が、前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックを該ブロック間のグラフィカル結合を伴わずに表示させる１つまたは複数の命令を更に含む、請求項３４に記載の非一時的なコンピュータ可読媒体。
　　【請求項３６】
　
前記命令が、前記少なくとも１つの実行可能なブロックの前記サンプルレートが前記イベントとして指定されていることを、前記グラフィカルモデルのビューに前記イベントの名前を用いて表示させる１つまたは複数の命令を更に含む、請求項３２に記載の非一時的なコンピュータ可読媒体。
　　【請求項３７】
　
前記イベントがユーザによって設定される明示イベントである、請求項３２に記載の非一時的なコンピュータ可読媒体。
　　【請求項３８】
　
前記イベントが、前記グラフィカルモデルの前記実行に伴って自動的に告知される暗黙イベントである、請求項３２に記載の非一時的なコンピュータ可読媒体。
　　【請求項３９】
　
前記暗黙イベントがパワーアップ、パワーダウン、及び初期設定の１つである、請求項３８に記載の非一時的なコンピュータ可読媒体。
　　【請求項４０】
　
前記暗黙イベントが、サブシステムの使用可能及び使用禁止の何れかに対応する、請求項３８に記載の非一時的なコンピュータ可読媒体。
　　【請求項４１】
　
前記命令が、前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックの論理的関連付けをユーザに色で表示させる１つまたは複数の命令を更に含む、請求項３４に記載の非一時的なコンピュータ可読媒体。
　　【請求項４２】
　
前記告知ブロックは、前記入力信号がゼロを上回る時を条件として前記イベントを告知するよう構成されている、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項４３】
　
前記グラフィカルモデルの各イベントがイベントハンドラに１対１でマッピングし、該イベントハンドラが関数である、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項４４】
　
前記関数がコード生成時にインライン化されている、請求項４３に記載の非一時的なコンピュータ可読媒体。
　　【請求項４５】
　
前記通知に応答して、分岐優先順位ブロックが、少なくとも２つの実行可能なブロックの実行順序を示す、請求項２９に記載の非一時的なコンピュータ可読媒体。
　　【請求項４６】
　
前記通知に応答して２つ以上のブロックグループが実行され、該ブロックグループがユーザにより予め選択されたブロックグループであり、該ブロックグループの実行順序がユーザにより予め指定される、請求項４５に記載の非一時的なコンピュータ可読媒体。
と補正するとともに、
　
明細書の発明の詳細な説明の段落【０００１】【０００３】を削除し、
同段落【０００７】を
「　
Simulink（商標）サンプルレートは、モデルの構成要素を実行する頻度を指定するための機構を提供している。
同段落【００１３】を
「　一実施形態では、複数の実行可能な構成要素を具備した少なくとも１つのモデルを備えたモデリング環境において、一方法は、
前記モデルの実行中に指定されたイベントの発生を監視する。
同段落【００１４】を、
「　別の実施形態では、複数の実行可能構成要素を具備した少なくとも１つのモデルを備えたモデリング環境において、一方法は、
前記モデルの実行中に指定されたイベントの発生を監視する。
と補正するものである。
　
（３）平成２６年７月１４日付け意見
　上記平成２６年７月１４日付けの意見書の意見の内容は概略次のとおりである。
『【意見の内容】
１．補正の説明
　この意見書と同日付で手続補正書を提出し、特許請求の範囲および発明の詳細な説明において以下のような補正を行った。この補正により特許請求の範囲および発明の詳細な説明の記載が明確になったので、拒絶理由１は解消したと確信する。
（１）補正後の請求項１において、「複数の実行可能なブロックを具備した少なくとも１つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって」の補正事項は、当初明細書の段落０００４、００２０の記載に基づく。この補正により、拒絶理由１の（１）、（２）、（３）、（４）で指摘された記載上の不備が解消した。
　
・・・中略・・・
　
（２２）平成２３年１１月２４日付の手続補正書における請求項３０，３１，３２を削除した。この補正により、拒絶理由１の（３３）、（３４）、（３５）、（３６）で指摘された記載上の不備が解消した。
（２３）補正後の請求項２９−４６は、今回、新たに追加された請求項である。
（２４）以上に説明した特許請求の範囲の補正、並びに、同日付の手続補正書でした発明の詳細な説明の補正により、拒絶理由１の（３７）、（３８）で指摘された記載上の不備が解消した。
２．本願発明の説明
　本願の請求項１−４６に係る発明は、特に請求項１、１８，２９に係る発明において、グラフィカルモデルのビューに告知ブロックを表示し、該告知ブロックの入力信号に関連付けられた条件が満足された時に、その告知ブロックがイベントの発生をイベントハンドラに告知するよう構成したことを技術的特徴とし、それによって、不特定の時刻に発生したイベントに応答して、グラフィカルモデルの構成要素であるブロックを実行できるという格別な作用効果を奏するものである。
３．引用発明の説明
　引用文献１〜３には、現代制御理論等に対応した所謂リアルタイムシミュレターにおいてイベントドリブン機能を備えた発明（引用発明１-３）が記載されている。引用文献４には、イベントハンドラを用いてイベントドリブン機能を実現する発明（引用発明４）が記載されている。
４．本願発明と引用発明との対比
　本願発明と引用発明１−３とは、シミュレターにおいてイベントドリブン機能を備えている点で類似するが、本願発明は、不特定な時刻に発生するイベントをイベントハンドラに告知するブロックを備えているのに対し、引用発明１-３は、そのようなブロックを備えていない点で相違する。
　本願発明と引用発明４とは、イベントハンドラを採用している点で類似するが、そのイベントハンドラが、本願発明では、告知ブロックと連携して、不特定な時刻に発生するイベントを少なくとも1つの実行可能なブロックに通知するのに対し、引用発明１では、そのような通知を行っていない点で相違する。
５．本願発明が特許されるべき理由
　以上対比したように、本願発明の技術的特徴点は引用発明１-４の何れにも開示されていない。したがって、本願の請求項１−４６に係る発明は、たとえ引用発明１−４を総合したとしても、そこから直ちに導き出すことができない発明であり、当然、すべてが特許されるべきである。よって、拒絶理由２は解消したと確信する。
６．むすび
　以上のとおり、拒絶理由１，２は解消したので、この意見書と手続補正書を採用のうえ、本願に対し速やかに特許査定を賜りたい。』
　
　
３．引用文献
　
（１）本願の出願前である上記優先日よりも前に頒布または電気通信回線を通じて公衆に利用可能となり、上記当審拒絶理由の２．において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
＜引用文献１＞
石塚 真一，「高度な制御理論に対応した設計が可能になるＭＡＴＬＡＢファミリ」，Ｉｎｔｅｒｆａｃｅ，ＣＱ出版株式会社，平成９年９月１日，第２３巻，第９号，ｐ．８４−８５
　
　＜引用文献記載事項１−１＞
「このようなシステムはFSM(Finite State Machine：有限状態機械)として知られ，これを効率よく記述するものが状態遷移図と呼ばれるもです．Stateflowは，この状態遷移図を発展させた
ステートチャートをGUI環境で簡便に記述し
　
　
＜引用文献２＞
「ＭＡＴＬＡＢ」，計測と制御，社団法人計測自動制御学会，平成１１年１月１０日，第３８巻, 第１号，ｐ．８０−８１
　
　＜引用文献記載事項２−１＞
「１．はじめに
　現代制御理論やロバスト制御理論などの先端的な制御理論は，理論自身の発展とマイコンやＤＳＰなどのハードウェアの進歩，そして設計を支援するソフトウェアの整備が進んだことによって，一部の研究者のものから次第に一般的にも利用可能なものとなってきている．米国Math-Works社が開発するＭＡＴＬＡＢ製品ファミリーは，こうした制御理論普及の流れの中で広く利用されてきた．
本稿ではこのＭＡＴＬＡＢ製品ファミリーの概要を紹介する
　
　＜引用文献記載事項２−２＞
「２．製品構成
　現在のＭＡＴＬＡＢ製品ファミリーは，図１に示すようにＭＡＴＬＡＢ，Simulink，Stateflowを中心として，ToolboxやBlocksetと呼ばれる各種の拡張ライブラリや，Real-Time Workshop，Stateflow Coder等の自動コード生成ツールなどから構成されている．
　Toolboxは各種の制御理論に基づく解析・設計ツール，システム同定・信号処理などのデータ解析・モデリング機能を提供する．Simulink
はブロック線図によるシステムのモデリングと非線形シミュレーション機能を備え，
　
　＜引用文献記載事項２−３＞
「３．Simulink/Stateflowによる倒立振子の制御系
設計例
　制御系の設計は，「フィードバック制御」と「シーケンス制御」に分けて考えることができる．前者の「センサ測定量に基づいて操作量を計算する」といったデータフローの記述にはSimulinkのブロック線図によるモデル化手法が適している．それに対して後者の「起こりうるさまざまな状況（イベント）に応じてシステムの状態を切り替えていく」コントロールフローの記述には，従来から状態遷移図と呼ばれる手法が用いられてきた．Stateflowは，この状態遷移図をさらに発展させた
ステートチャートを記述してSimulinkモデルに組み込む機能を追加する製品である
SimulinkとStateflowによるブロック線図記述とステートチャート記述の統合化
設計環境を
　
　＜引用文献記載事項２−４＞
「図２は
アーム型倒立振子
の制御実験に用いたコントローラのモデルである
○１（当審注：「○数字」は「数字」を「○」で囲った文字を意味する。以下同様。）
振子を鉛直下向きに静止させた状態から振り上げる
○２
振子を鉛直上向き状態に保つ
○３
制御を切り，振子が鉛直下向きに静止するまで待つ
この３つのモードを繰り返す．モード○１から○２への切り替えは振子の角度・角速度がある条件を満足したときに，モード○２から○３へと○３から○１への切り替えはおのおのある設定時間経過後に行うことにする．
　
　＜引用文献記載事項２−５＞
「
図２中でControl Logicという名前を付けられたブロックはStateflowにより記述されたモデルで，ここから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモード（Hold，Swing，Wake-up）の実行を切り替えている
図３にそのControl Logicブロックの内部を示す．これがStateflowで記述されたステートチャートで，モードの切り替えのロジックと（実際には，緊急停止モードを加えた４つのモードがある）タイマーを記述している
　このようにStateflowをSimulinkと併用することで，コントロールフローをわかりやすい形でモデルに組み込むことが可能になる．」（第８１頁左欄第８行〜同頁右欄第１１行）
　
　＜引用文献記載事項２−６＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　」（第８１頁）
　
　＜引用文献記載事項２−７＞
「
　　　　　　　　　　　　　　　　　　　　　　　　　　　」（第８１頁）
　
＜引用文献３＞
「動的システムをモデリング／シミュレーションするためのツール　Ｓｉｍｕｌｉｎｋの基礎」，Ｉｎｔｅｒｆａｃｅ，ＣＱ出版株式会社，平成１３年１０月１日，第２７巻, 第１０号，ｐ．２８−５２
　
　
　＜引用文献記載事項３−１＞
「
ブロックを配置するためには，ライブラリブラウザで希望のブロックを左クリックした状態でドラッグし，モデルウインドウの任意の場所にドロップする
　
　
＜引用文献４＞
米国特許第５４９７５００号明細書
　
　＜引用文献記載事項４−１＞
「Occurrence Memory Organization
　Referring now to FIG. 119, a diagram illustrating the manner in which occurrences are implemented in memory is shown. As shown, the present invention includes an occurrence table which includes a number of occurrence entries corresponding to Generate Occurrence nodes on the block diagram. It is also noted that other asynchronous nodes are placed on the occurrence table.
　When a Wait on Occurrence node is encountered during run time, i.e., when the inputs to the Wait on Occurrence node arrive at run time, the execution subsystem indexes into the occurrence table using the occurrence identifier. As previously noted, the occurrence identifier is the output of the respective Generate Occurrence node that is connected to the Wait on Occurrence node.
　The subsystem indexes to the proper entry, which comprises a pointer, and uses that entry to access an occurrence handler pointer table having one or more entries. The occurrence handler pointer table comprises all the nodes that desire to be identified and called when the respective occurrence is set. At this time, a new entry is created for the respective Wait on Occurrence node, and the node is said to be armed. 
As shown in FIG. 119, each entry in the occurrence handler pointer table points to a respective occurrence handler function call. Each occurrence handler function call includes the beginning address of an occurrence handler function which restarts operation of the Wait on Occurrence node when the respective occurrence occurs or is triggered. Thus, the occurrence handler function call calls a function whose job it is to requeue the Wait on Occurrence node on the run queue when the occurrence is triggered. 
（当審訳：「事象メモリ機構
　ここで図１１９を参照すると、事象がメモリに実装される方法を説明する図が示されている。ここに示されるように、本発明はブロック図上の事象生成ノードに対応する多数の事象入力を含む事象テーブルを含む。同様に、他の非同期ノードが事象テーブル上に配置されることがわかる。
　事象待ち受けノードがランタイム中にエンカウントされるとき、すなわち、その事象待ち受けノードへの入力がランタイム時に到達するとき、実行サブシステムが事象識別子を使って事象テーブル中へ索引付けをする。上述のとおり、事象識別子は事象待ち受けノードに接続している各事象生成ノードの出力である。
　そのサブシステムはポインタを構成する適切な入力に索引付けをして、そしてその入力を１あるいはより多くの入力を持っている事象ハンドラポインタテーブルをアクセスするために使う。事象ハンドラポインタテーブルは、各事象が設定されているときに識別されそして呼び出されることを要求するすべてのノードを含む。このとき、新規入力が各事象待ち受けノードのために作成され、そのノードは「装備済み」と言われる。
図１１９に示されるように、事象ハンドラポインタテーブルの各自の入力はそれぞれの事象ハンドラファンクションコールを指し示す。各事象ハンドラファンクションコールは、各自の事象が起こるか、あるいは「トリガーされる」とき、事象待ち受けノードの動作を再開する事象ハンドラファンクションの開始アドレスを含む。そして、事象ハンドラファンクションコールは、その事象がトリガーされるとき、実行キュー上の事象待ち受けノードをリキューすることがその役割である関数をコールする。
　
　
第２．当審拒絶理由１（特許法第３６条）について
　
１．拒絶理由
　上記当審拒絶理由の理由１．で通知した特許法第３６条についての拒絶理由は上記第１．２．（１）の理由の１．に記載のとおりのものであり、これに対して上記第１．２．（２）に示した上記平成２６年７月１４日付け手続補正（以下単に「上記補正」と記す。）がなされるとともに、上記第１．２．（３）に示した意見書が提出されている。
　
２．当審判断
（１）理由１．（１）について
　当審拒絶理由の理由１．（１）で意味・定義が明確でないと指摘された「実行可能な」「構成要素」との記載は、上記補正後の請求項１、１８、２９においては「実行可能なブロック」との記載に補正された。
　しかしながら、上記補正後の請求項１、１８、２９における「ブロック」は「ビュー」に「表示」される「グラフィカルモデル」の要素にほかならないものであり、プログラムや電子回路のように「実行可能」なものではないので、特許請求の範囲の記載のみからは「実行可能なブロック」との意味を明確に把握することはできない。
　そして、この点について発明の詳細な説明を参酌するに、本願明細書における「ブロック」が制御系の要素であることから、何らかの制御を行う要素を「実行可能なブロック」と表現しているとの解釈や、「ブロック」がシミュレーションの対象となる系の要素であることから、「シミュレーション」を行うことができる要素を「実行可能なブロック」と表現しているとの解釈等、様々な解釈が可能となるものの、その意味を明確に定義する記載等、いずれかの解釈に特定可能とできるような記載は見当たらない。
　してみると、当審拒絶理由の理由１．（１）で指摘した不備は依然として解消されておらず、本願請求項１〜４６に係る発明は明確でない。
　さらに、このため、本願の発明の詳細な説明は、当業者が本願請求項１〜４６に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項１〜４６に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものであるとも言える。
　
（２）理由１．（３８）について
　上記当審拒絶理由通知書の理由１．（３８）において、意味の不明確な記載等として例示したオ．〜ニ．の点に関しては、何ら補正がされていない。
　このため、当審拒絶理由通知書の理由１．（３８）オ．〜ニ．において示した記載の意味は依然として不明確であり、かかる本願の発明の詳細な説明の記載内容から、本願請求項１〜４６に係る発明の構成を正確に理解しこれを再現することも、本願請求項１〜４６に係る発明が如何なる課題を解決するためのもので、如何なる効果が奏されるのかといった、本願請求項１〜４６に係る発明の技術上の意義を正確に理解することは、当業者と言えども不可能である。
　また、上記補正と同日付けの意見書においても実質的な反論や釈明はなされていない。
　
３．小結
　よって、本願の発明の詳細な説明及び特許請求の範囲の記載は、特許法第３６条第４項第１号及び同条第６項第２号に規定する要件を満たしていない
　
　
第３．当審拒絶理由２（特許法第２９条第２項）について
　
１．本願発明の認定
　本願請求項１に係る発明（以下「本願発明」と記す。）は、上記平成２６年７月１４日付けの手続補正書によって補正された特許請求の範囲、明細書および図面の記載からみて、上記第１．１．（２）に【請求項１】として記載したとおりのものと認める。
　
２．引用文献
　上記当審拒絶理由の理由２．で通知した特許法第２９条第２項についての拒絶理由は上記第１．２．（１）の理由の２．に記載のとおり、上記第１．３．に挙げた引用文献１〜４を引用するものである。
　
３．引用発明の認定
（１）
ア．引用文献２は引用文献記載事項２−１記載のとおり「ＭＡＴＬＡＢ製品ファミリーの概要を紹介する」ものであるところ、引用文献記載事項２−３などから、当該「ＭＡＴＬＡＢ製品ファミリー」の「Simulink」と「Stateflow」とによって「ブロック線図記述とステートチャート記述の統合化」がなされた「設計環境」が提供されることが読み取れる。
イ．また、引用文献記載事項２−２等から該「Simulink」が「ブロック線図によるシステムのモデリングと非線形シミュレーション機能を備え」たものであることが記載され、引用文献記載事項２−３以降では当該環境での「設計例」が説明されているのであるから、これらの記載からは当該環境における「モデリングとシミュレーションを行う方法」を読み取ることができる。
ウ．してみると、引用文献２には
「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法」
が記載されていると言える。
　
（２）上記引用文献記載事項２−４から
該「モデリングとシミュレーション」の対象は「アーム型倒立振子の制御実験に用いるコントローラ」であり、該「コントローラ」は「振子を鉛直下向きに静止させた状態から振り上げる」「モード○１」と、「振子を鉛直上向き状態に保つ」「モード○２」と「制御を切り，振子が鉛直下向きに静止するまで待つ」「モード○３」の「３つのモードを繰り返」し「モード○１から○２への切り替えは振子の角度・角速度がある条件を満足したときに，モード○２から○３へと○３から○１への切り替えはおのおのある設定時間経過後に行う」ものであることが読み取れる。
　したがって、
「該モデリングとシミュレーションの対象はアーム型倒立振子の制御実験に用いるコントローラであり、
　該コントローラは
振子を鉛直下向きに静止させた状態から振り上げる第１のモードと、
振子を鉛直上向き状態に保つ第２のモードと、
制御を切り，振子が鉛直下向きに静止するまで待つ第３のモードを有し、
この３つのモードを繰り返すもので、
前記第１のモードから前記第２のモードへの切り替えは振子の角度・角速度がある条件を満足したときに，前記第２のモードから前記第３のモードへと前記第３のモードから前記第１のモードへの切り替えはおのおのある設定時間経過後に行うもの」
であると言える。
　
（３）上記引用文献記載事項２−６等から、
『該コントローラのモデルは、
「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」という名前を付けられた信号が「Control Logic」という名前を付けられたブロックに入力され、該「Control Logic」という名前を付けられたブロックから「hold」「swing」「control」「emergency」という名前を付けられた信号が出力され、
　「Angle of Arm」という名前を付けられた信号と前記「hold」という名前を付けられた信号が「Hold Mode」という名前を付けられたブロックに入力され、該「Hold Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力され、
　前記「Angle of Arm」という名前を付けられた信号と「Angle of Pend」という名前を付けられた信号と前記「swing」という名前を付けられた信号が「Swing Mode」という名前を付けられたブロックに入力され、該「Swing Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力され、
　前記「Angle of Arm」という名前を付けられた信号と前記「Angle of Pend」という名前を付けられた信号と前記「control」という名前を付けられた信号が「Wake Up Mode」という名前を付けられたブロックに入力され、該「Wake Up Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力されるブロック線図で記述され』
るものであると言える。
　
（４）そして、上記引用文献記載事項２−５の「図３にそのControl Logicブロックの内部を示す．これがStateflowで記述されたステートチャートで，モードの切り替えのロジックと（実際には，緊急停止モードを加えた４つのモードがある）タイマーを記述している．」との記載や上記引用文献記載事項２−７等から、
『前記「Control Logic」という名前を付けられたブロックのモードの切替えロジックは前記「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」を用いたステートチャートで記述されるもの』
であると言える。
　
（５）さらに上記引用文献記載事項２−５の「図２中でControl Logicという名前を付けられたブロックはStateflowにより記述されたモデルで，ここから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモード（Hold，Swing，Wake-up）の実行を切り替えている．」との記載等から、
『該ブロック線図とステートチャートとで、前記「Control Logic」という名前を付けられたブロックから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモードの実行を切り替えることを表している』
と言える。
　
（６）よって、引用文献２には、下記引用発明が記載されていると認められる。
　
＜引用発明＞
「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法であって、
　該モデリングとシミュレーションの対象はアーム型倒立振子の制御実験に用いるコントローラであり、
　該コントローラは
振子を鉛直下向きに静止させた状態から振り上げる第１のモードと、
振子を鉛直上向き状態に保つ第２のモードと、
制御を切り，振子が鉛直下向きに静止するまで待つ第３のモードを有し、
この３つのモードを繰り返すもので、
前記第１のモードから前記第２のモードへの切り替えは振子の角度・角速度がある条件を満足したときに，前記第２のモードから前記第３のモードへと前記第３のモードから前記第１のモードへの切り替えはおのおのある設定時間経過後に行うものであり、
　該コントローラのモデルは、
「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」という名前を付けられた信号が「Control Logic」という名前を付けられたブロックに入力され、該「Control Logic」という名前を付けられたブロックから「hold」「swing」「control」「emergency」という名前を付けられた信号が出力され、
　「Angle of Arm」という名前を付けられた信号と前記「hold」という名前を付けられた信号が「Hold Mode」という名前を付けられたブロックに入力され、該「Hold Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力され、
　前記「Angle of Arm」という名前を付けられた信号と「Angle of Pend」という名前を付けられた信号と前記「swing」という名前を付けられた信号が「Swing Mode」という名前を付けられたブロックに入力され、該「Swing Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力され、
　前記「Angle of Arm」という名前を付けられた信号と前記「Angle of Pend」という名前を付けられた信号と前記「control」という名前を付けられた信号が「Wake Up Mode」という名前を付けられたブロックに入力され、該「Wake Up Mode」という名前を付けられたブロックから「Vel.of Moter」という名前を付けられた信号が出力されるブロック線図で記述され、
　前記「Control Logic」という名前を付けられたブロックのモードの切替えロジックは前記「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」を用いたステートチャートで記述されるものであり、
　該ブロック線図とステートチャートとで、前記「Control Logic」という名前を付けられたブロックから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモードの実行を切り替えることを表している
方法。」
　
　
４．対比
　以下に、本願発明と引用発明とを比較する。
　
（１）
ア．引用発明は「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法」であり、該「ブロック線図記述とステートチャート記述」は「グラフィカルモデル」とも言えるものである。
　
イ．そして、当該「ブロック線図記述」が複数の「ブロック」からなるものであることは明らかである。
　
ウ．また、引用発明における『「Control Logic」という名前を付けられたブロック』は「イベントドリブンなサブシステムとして記述されている３つのモードの実行を切り替える」と言う制御を実行するものであり、更に該「サブシステム」は「振子を鉛直下向きに静止させた状態から振り上げる第１のモード」「振子を鉛直上向き状態に保つ第２のモード」「制御を切り，振子が鉛直下向きに静止するまで待つ第３のモード」における制御を実行するものであり、引用発明においてはこれらの「シミュレーション」を行うことができることは明らかである。そして、本願発明における「実行可能なブロック」の技術的な意味は必ずしも明確なものではないものの、このような「制御を実行する」ものを表すブロックや「シミュレーション」を行うことができるブロックは「実行可能なブロック」に含まれると解することができる。
　
エ．したがって、引用発明も本願発明と同様に
「複数の実行可能なブロックを具備した少なくとも１つの実行可能なグラフィカルモデルを備えた環境において実行される方法」
と言えるものである。
　
（２）
ア．引用発明において「モデリングとシミュレーションの対象」となる「アーム型倒立振子の制御実験に用いるコントローラ」は「動的システム」にほかならない。
　
イ．引用発明における『「Control Logic」という名前を付けられたブロック』の入力である『「arm_p」「arm_v」「pend_p」「pend_v」』『という名前を付けられた信号』や『「Hold Mode」という名前を付けられたブロック』『「Swing Mode」という名前を付けられたブロック』および『「Wake Up Mode」という名前を付けられたブロック』の入力である『「Angle of Arm」という名前を付けられた信号』『「Angle of Pend」という名前を付けられた信号』等は「連続的に」「変化する入力」にほかならない。
　
ウ．引用発明における『「Hold Mode」という名前を付けられたブロック』『「Swing Mode」という名前を付けられたブロック』および『「Wake Up Mode」という名前を付けられたブロック』の入力である『「hold」という名前を付けられた信号』『「swing」という名前を付けられた信号』『「control」という名前を付けられた信号』は『特定の時刻に離散的に変化する入力』にほかならない。
　
エ．引用発明における『「Wake Up Mode」という名前を付けられたブロック』は「ステートチャート」によってロジックが記述されるのであるから「状態」を備えたものであることは明らかである。また、他の引用発明におけるブロックも当然何らかの「状態」を備えているはずである。
　
オ．『「Control Logic」という名前を付けられたブロック』から出力される『「hold」「swing」「control」「emergency」という名前を付けられた信号』や、『「Hold Mode」という名前を付けられたブロック』から出力される『「Vel.of Moter」という名前を付けられた信号』、『「Swing Mode」という名前を付けられたブロック』から出力される『「Vel.of Moter」という名前を付けられた信号』および『「Wake Up Mode」という名前を付けられたブロック』から出力される『「Vel.of Moter」という名前を付けられた信号』は「出力」にほかならない
　
カ．したがって、引用発明においても本願発明と同様に
「前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し」
ていると言える。
　
（３）
ア．引用発明における「コントローラ」の「モデリング」においてはその「モデル」を表す「ブロック線図」が「表示」されることは明らかであり（必要があれば引用文献記載事項１−１、３−１等参照）、これは「前記グラフィカルモデルのビューを表示する」ものであるとも言える。
　
イ．また、引用発明における「「Control Logic」という名前を付けられたブロック」は本願発明における「告知ブロック」に対応付けられるものであるところ、前者には『「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」という名前を付けられた信号』が「入力」されるのであるから、前者も後者と同様に「少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロック」と言えるものであり、「前記ビュー」には係る「告知ブロック」が「含まれ」ていると言える。
　
ウ．また、引用発明における『「hold」「swing」「control」「emergency」という名前を付けられた信号』は「イベント信号」とも言えるものであり、これらは「イベントを告知する」ものであると言える。そして、該「「Control Logic」という名前を付けられたブロック」は、その「モードの切替えロジック」が『前記「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」を用いたステートチャートで記述されるもの』であるから、「該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている」とも言える。
　
エ．よって、引用発明も本願発明と同様に、
「前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階」
を含むと言える。
　
（４）
ア．引用発明においては『「Control Logic」という名前を付けられたブロックから「hold」「swing」「control」』『という名前を付けられた信号が出力され』『前記「hold」という名前を付けられた信号が「Hold Mode」という名前を付けられたブロックに入力され』『前記「swing」という名前を付けられた信号が「Swing Mode」という名前を付けられたブロックに入力され』『前記「control」という名前を付けられた信号が「Wake Up Mode」という名前を付けられたブロックに入力され』るものであるところ、そのためには『「Control Logic」という名前を付けられたブロック』と『「Hold Mode」という名前を付けられたブロック』を『「hold」という名前を付けられた信号』で関連付け、『「Control Logic」という名前を付けられたブロック』と『「Swing Mode」という名前を付けられたブロック』を『「swing」という名前を付けられた信号』で関連付け、『「Control Logic」という名前を付けられたブロック』と『「Wake Up Mode」という名前を付けられたブロック』を『「control」という名前を付けられた信号』で関連付ける操作がなされることは明らかであり、これは「実行可能なブロックを前記イベントに関連付ける」ことにほかならない。
　
イ．したがって、引用発明も本願発明と同様に
「少なくとも1つの実行可能なブロックを前記イベントに関連付ける段階」
を含むと言える。
　
（５）
ア．引用発明において「モデリング」されたモデルを「シミュレーション」することは、「グラフィカルモデルの実行」とも言えるものであり、その際に「ステートチャート」で記述されたとおりの状態遷移の遷移条件を満たすか否か識別することは明らかであり、これは「前記告知ブロックにおいて前記条件が満足された時を識別する」ことにほかならない。
　
イ．したがって、引用発明も本願発明と同様に
　「前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階」
を含むと言える。
　
（６）
ア．引用発明における「ブロック線図とステートチャート」は『前記「Control Logic」という名前を付けられたブロックから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモードの実行を切り替えることを表している』のであるから、その「シミュレーション」の際には、『「Control Logic」という名前を付けられたブロック』から『「Hold Mode」という名前を付けられたブロック』『「Swing Mode」という名前を付けられたブロック』および『「Wake Up Mode」という名前を付けられたブロック』にイベントの発生が通知されることが模擬されることは明らかであり、引用発明は「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むと言える。
　
イ．なお、本願発明における「ブロック」は「ビュー」に「表示」される「グラフィカルモデル」の「ブロック」にほかならず、技術常識からみて「通知」の相手となるものではないので、本願発明における「イベントの発生を」「ブロックに通知する」との表現の技術的な意味は必ずしも明確なものではない。しかしながら、本願発明の詳細な説明においても「Simulink」を例示して説明している点などを参酌すれば、この表現は「シミュレーション」の際に「ブロック」が表現する技術的手段に「イベントの発生」が通知されることを模擬することを意味すると解することができる。
　
ウ．一方、本願発明は「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知する段階」と「前記イベントハンドラが前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むのであるから、本願発明も「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むと言える。
　
エ．したがって、引用発明と本願発明とは
「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」
を含む点で共通すると言える。
　
（７）
ア．引用発明における『「Control Logic」という名前を付けられたブロックから発生させるイベント信号により，それぞれイベントドリブンなサブシステムとして記述されている３つのモードの実行』をすることは、「特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する」ことにほかならない。
　
イ．したがって、引用発明も本願発明と同様に
「特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する段階」
を含むと言える。
　
（８）よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。
　
＜一致点＞
「複数の実行可能なブロックを具備した少なくとも１つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって、前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し、
　前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
　少なくとも1つの実行可能なブロックを前記イベントに関連付ける段階と、
　前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
　前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階と、
　特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する段階とを含む、方法」。
　
＜相違点＞
　本願発明においては、前記イベントの発生を「イベントハンドラに告知する段階」を有し、「前記イベントハンドラが」前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知するものである。
（これに対し、引用文献２にはイベントドリブン機能をシミュレーションするための具体的な構成までは開示されていない。）
　
　
５．判断
（１）　上記相違点について検討するに、引用発明におけるイベントドリブン機能はシミュレーションの対象となるものであるから、ハードウエアとして実装せずにソフトウエア的に実装すべきものであることは明らかであるところ、このような事象の発生に応動する制御機構を当該事象の発生に対応付けられたハンドリングを行う関数、所謂ハンドラを呼び出すように構成することでソフトウエア的に実装することは、当該技術分野においては常套手段にすぎないものである（必要があれば引用文献記載事項４−１等参照）。
　してみると、引用発明においてイベントドリブン機能の実現のために、かかるハンドラを用いた機構を採用することは、当業者の通常の創作力の発揮にすぎないものであり、そしてこの場合には、必然的に該ハンドラは「イベントハンドラ」と称し得るものとなり、告知ブロックは前記イベントの発生を「イベントハンドラに告知する」ものとなり、該「イベントハンドラ」が前記イベントの発生を実行可能なブロックに通知するものとなる。
　したがって、引用発明を上記相違点に係る構成を備えたものとすることは当業者であれば容易に想到し得たものである。
　そして、これによって格別予測困難な作用効果が奏されるものでもない。
　
（２）してみると、本願発明の構成は引用文献２に記載された発明に基づいて、当業者が容易に想到し得たものであり、また、本願発明の効果は当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用文献２に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
６．小結
　以上のとおり、本願請求項１に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　
第４．むすび
　
　上記第２．のとおり、本願の発明の詳細な説明及び特許請求の範囲の記載は、特許法第３６条第４項第１号及び同条第６項第２号に規定する要件を満たしていないので、本願は拒絶すべきものである。
　
　上記第３．のとおり、本願請求項１に係る発明は特許法第２９条第２項の規定により特許を受けることができないものであるから、他の請求項についての検討をするまでもなく、本願は拒絶すべきものである。
　
　よって、上記結論のとおり審決する。