• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1298576
審判番号 不服2012-10477  
総通号数 185 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-05-29 
種別 拒絶査定不服の審決 
審判請求日 2012-06-06 
確定日 2015-03-11 
事件の表示 特願2006-549406「モデルイベントを用いてモデル構成要素の実行をスケジューリングするためのシステム及び方法」拒絶査定不服審判事件〔平成17年 8月 4日国際公開、WO2005/071537、平成19年 7月 5日国内公表、特表2007-518190〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯・先行技術等

1.手続の経緯の概要
本件請求に係る出願(以下「本願」と記す)は
2004年1月15日付けのアメリカ合衆国における出願を基礎としたパリ条約に基づく優先権主張を伴う、
2005年1月6日を国際出願日とする出願であって、
平成18年7月14日付けで特許法第184条の5第1項の規定による書面が提出され、
平成18年9月14日付けで特許法第184条の4第1項の規定による国際出願日における明細書、請求の範囲、図面の翻訳文が提出され、
平成20年1月7日付けで審査請求がなされ、
平成23年5月10日付けで拒絶理由通知(平成23年5月24日発送)がなされ、これに対して
平成23年11月24日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出され、
平成24年1月26日付けで拒絶査定(平成24年2月7日謄本発送、送達)がなされたものである。

本件審判請求は、
「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」との請求の趣旨で、
平成24年6月6日付けでなされたものであって、
同日付けで手続補正書が提出され、
平成24年9月4日付けで特許法第164条第3項に定める報告(前置報告)がなされ、
平成24年11月15日付けで当該報告に対する意見を求める旨の審尋(平成24年11月20日発送)がなされ、これに対して
平成25年3月18日付けで回答書が提出され、
平成26年1月8日付けで上記平成24年6月6日付けの手続補正を却下する旨の補正の却下の決定(平成26年1月21日発送)がなされるとともに、
同日付けで拒絶理由通知(平成26年1月14日発送)がなされ、これに対して、
平成26年7月14日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出されたものである。


2.拒絶理由・補正の内容・意見書の主張等

(1)当審拒絶理由
上記平成26年1月8日付け拒絶理由通知(以下「当審拒絶理由通知」と記す。)で通知された拒絶理由(以下「当審拒絶理由」と記す。)の内容は概略以下のとおりのものである。

『1.この出願は、発明の詳細な説明及び特許請求の範囲の記載が下記の点で、特許法第36条第4項第1号及び第6項第1号、第2号、第3号に規定する要件を満たしていない。


(1)本願請求項1、19、30に「実行可能な」「構成要素」とあるが、その意味・定義(「実行可能な」とは「構成要素」が如何なる構成や性質を有することを意味するのか? なにがこれに該当しなにが該当しないのか? 実行可能なプログラム部品と言う意味なのか? 構成要素が入力を処理して出力を出すと言う意味なのか? 等々)が該請求項の記載からは明確でない。また本願の発明の詳細な説明においても明確に定義がされておらず、本願の発明の詳細な説明を参酌してもこの点は明確でない。
したがって、本願請求項1?32に係る発明は明確でなく、また、本願の発明の詳細な説明に記載されるものではない。
さらに、このため、本願の発明の詳細な説明は、当業者が本願請求項1?32に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項1?32に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものであるとも言える。

・・・中略・・・

(38)本願の発明の詳細な説明中にも意味の不明確な記載等(下記ア.?ニ.に例示する。)が散見される。
このため、本願の発明の詳細な説明は、当業者が本願請求項1?32に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項1?32に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものである。

ア.段落【0001】の「本願は、その内容を引用して本明細書に援用する2004年1月15日に提出された米国特許出願第10/759,346号の利益を主張する。」。(削除されたし。)

イ.段落【0003】の『本発明の例示的な実施形態は、「ブロックダイヤグラム・モデリングで実行コンテキストを使用するためのシステム及び方法」と題した現在係属中の米国特許出願第10/414,644号に関連し、その内容を引用して本明細書に援用する。』。(削除されたし。)

ウ.段落【0007】の「Simulink(商標)のサンプルレートにより、モデルの構成要素を実行する頻度が指定可能となる。」。(誤訳なのでは?)

エ.段落【0013】【0014】の「一方法は、前記モデルの実行を指定イベントの発生に関して監視する。」。(技術的に意味不明の記載である。誤訳なのでは?)

オ.段落【0016】の「サンプルレートはイベントとして指定されるので、モデル構成要素の実行をそのモデルの動態に結びつける。」。(なぜこのような因果関係が成り立つのかが、明確に説明されていない。)

カ.段落【0016】の「非連続モデル構成要素を、モデルイベント発生に基づいて条件付きで実行するように構成できる。」。(「非連続モデル構成要素」とは如何なる構成要素なのかの説明がない。)

キ.段落【0016】の「更に、構成要素実行の範囲は、ある種の従来システムで必要となるように、サブシステム全体には制限されない。」。(「ある種の従来システムで必要となるように」とは如何なるシステムの如何なる性質を意味しているのか不明。)

ク.段落【0021】の「因果関係に関連付けられたファーストクラス・オブジェクト「A」が存在するので、色などの特性を構成し、その関係に割り当てることができる。」。(技術的に意味不明の記載である。誤訳なのでは?)

ケ.段落【0022】の『任意イベントの「範囲」とは、それが存在する作業領域の範囲である。』。(技術的に意味不明の記載である。誤訳なのでは?)

コ.段落【0022】の「作業領域がサブシステム又はモデルに関連付けられている場合、イベントの範囲はそのサブシステム又はモデルである。」。(技術的に意味不明の記載である。誤訳なのでは?)

サ.段落【0022】の「ブロックがそのサンプル時間をイベントとして指定できるのは、そのイベントが該ブロックからの範囲内にある場合である。」。(技術的に意味不明の記載である。誤訳なのでは?)

シ.段落【0024】の「実行時間検査を行ってこれらイベントが20ミリ秒毎に告知されることを表明する。」。(技術的に意味不明の記載である。誤訳なのでは?)

ス.段落【0024】の「イベントのレートを明示的に指定する1つの利点は、そのレートで生成される任意コードが、連続実行の間に経過時間が必要な場合は、通常のようにタイマ使用を必要とするのでなく、この生成コードにおいて対応する定数サンプル時間を使用できることである。」。(技術的に意味不明の記載である。誤訳なのでは?)

セ.段落【0030】の『「ゼロ次保持」ブロック92はそのサンプルレートが「使用禁止」に指定されているため、』。(【図5】にはそのような記載はない。)

ソ.段落各イベントは【0031】の「各イベントは・・・マッピングする」。(技術的に意味不明の記載である。「イベント」は「マッピング」されるのであって、「マッピングする」は誤訳なのでは?))

タ.段落【0031】の「インライン化」。(その意味(コンパイル時にインライン展開すると言う意味か? インラインアセンブラで記述したと言う意味か? 一行で記述したという意味か?)が明確で無い。)

チ.段落【0032】の「Simulink(商標)イベントのプロパティの1つはそのタスクである。」。(技術的に意味不明の記載である。誤訳なのでは?)

ツ.段落【0035】の「タスクを用いて、実時間実装においてイベントを用いる際にデータの完全性を保証する助けとするが、これは、データの完全性のためイベント遷移ブロックがどこで必要とされているかを示すことにより達成される。」。(技術的に意味不明の記載である。誤訳なのでは?)

テ.段落【0044】の「当業者であれば、・・・ので、・・・を備えることは重要なことは理解するはずである。」。(文法的に意味不明。誤訳なのでは?)

ト.段落【0045】の「図7Aのモデルは、アトミック・サブシステムを用いて、例外イベントBを介して条件付きで回避することを意図した積ブロックの前にスローブロックが実行されるソート済みブロック順序の実行を徹底する。」。(技術的に意味不明の記載である。誤訳なのでは?)

ナ.段落【0045】の「このアトミック・サブシステムはソート済みブロックリストで積ブロックより早いので、スローブロックも含むその内容は積ブロックより前に実行される。」。(技術的に意味不明の記載である。誤訳なのでは?)

ニ.段落【0055】の「連続ステップ」。(誤訳なのでは?)


2.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

記 (引用文献等については引用文献等一覧参照)
・請 求 項 1?32
・引用文献等 1?4
・備 考
現代制御理論等に対応した所謂リアルタイムシミュレターにおいてイベントドリブン機能を具備せしめることは、引用文献1?3等に示される如く、当業者にとっては周知慣用技術に過ぎないものである。
本願請求項1に係る発明は上記理由1.で示したように、必ずしも明確なものではないものの、イベントハンドラを用いてイベントドリブン機能を実現していることが限定されている点で、上記引用文献1?3に記載のない特徴を有し、その余の点には該周知慣用技術との間に格別な相違は認められない。
しかしながら、引用文献4等に示される如く、イベントハンドラの採用は、当業者にとってはイベントドリブン機能を実現するための一常套手段に過ぎないものである。
してみると、本願請求項1に係る発明は、引用文献1?4記載の発明に基づいて、当業者が容易に発明し得たものである。
本願請求項2?18も常識的な事項を限定しているに過ぎないものと解することができ、引用文献1?4記載の発明に基づいて、当業者が容易に発明し得たものであると言える。
本願請求項19?29、30?32にかかる発明も、本願請求項1?18に係る発明と同様の理由で、引用文献1?4記載の発明に基づいて、当業者が容易に発明し得たものである。

引 用 文 献 等 一 覧
1.石塚 真一,「高度な制御理論に対応した設計が可能になるMATLABファミリ」,Interface,CQ出版株式会社,平成9年9月1日,第23巻,第9号,p.84-85
2.「MATLAB」,計測と制御,社団法人計測自動制御学会,平成11年1月10日,第38巻, 第1号,p.80-81
3.「動的システムをモデリング/シミュレーションするためのツール Simulinkの基礎」,Interface,CQ出版株式会社,平成13年10月1日,第27巻, 第10号,p.28-52 (特に28頁「はじめに」中の「Stateflow」に関する記載。)
4.米国特許第5497500号明細書(特に第49欄第4-38行。)』

(2)平成26年7月14日付け手続補正
上記平成26年7月14日付けの手続補正書は特許請求の範囲を、
「 【請求項1】
複数の実行可能なブロックを具備した少なくとも1つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって、前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し、
前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
少なくとも1つの実行可能なブロックを前記イベントに関連付ける段階と、
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知する段階と、
前記イベントハンドラが前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階と、
特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する段階とを含む、方法。
【請求項2】
前記少なくとも1つの実行可能なブロックを前記イベントハンドラに登録する段階を更に含む、請求項1に記載の方法。
【請求項3】
前記少なくとも1つの実行可能なブロックのサンプルレートを前記イベントとして指定する段階を更に含む、請求項1に記載の方法。
【請求項4】
前記サンプルレートを前記少なくとも1つの実行可能なブロックから他の実行可能なブロックに伝播させる段階を更に含む、請求項3記載の方法。
【請求項5】
前記グラフィカルモデルにおいてグループ化されていない非連続の複数の実行可能なブロックのサンプルレートを前記イベントとして指定する段階を更に含む、請求項3に記載の方法。
【請求項6】
前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックが該ブロック間のグラフィカル結合を伴わずに表示される、請求項5に記載の方法。
【請求項7】
前記少なくとも1つの実行可能なブロックの前記サンプルレートが前記イベントとして指定されていることを、前記グラフィカルモデルのビューにおいて前記イベントの名前を用いて表示する段階を更に含む、請求項3に記載の方法。
【請求項8】
前記イベントがユーザによって設定される明示イベントである、請求項3に記載の方法。
【請求項9】
前記イベントが前記グラフィカルモデルの前記実行に伴って自動的に告知される暗黙イベントである、請求項3に記載の方法。
【請求項10】
前記暗黙イベントがパワーアップ、パワーダウン、及び初期設定の1つである、請求項9に記載の方法。
【請求項11】
前記暗黙イベントがサブシステムの使用可能及び使用禁止の何れかに対応する、請求項9に記載の方法。
【請求項12】
前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックの論理的関連付けをユーザに色で表示する、請求項5に記載の方法。
【請求項13】
前記告知ブロックは、前記入力信号がゼロを上回る時を条件として前記イベントを告知するよう構成されている、請求項1に記載の方法。
【請求項14】
前記グラフィカルモデルの各イベントがイベントハンドラに1対1でマッピングし、該イベントハンドラが関数である、請求項1に記載の方法。
【請求項15】
前記関数がコード生成時にインライン化されている、請求項14に記載の方法。
【請求項16】
前記通知に応答して、分岐優先順位ブロックが少なくとも2つの実行可能なブロックの実行順序を示す、請求項1に記載の方法。
【請求項17】
前記通知に応答して2つ以上のブロックグループが実行され、該ブロックグループがユーザにより予め選択されたブロックグループであり、該ブロックグループの実行順序がユーザにより予め指定される、請求項1に記載の方法。
【請求項18】
複数の実行可能なブロックを具備した少なくとも1つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって、前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し、
前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知する段階と、
前記イベントの前記告知に応答して別のブロックの実行に割り込む段階と、
特定の時刻に応答させるのではなく、前記イベントの前記告知に応答して、前記グラフィカルモデルにおいて演算を実行する段階とを含む、方法。
【請求項19】
前記指定イベントが通常イベントであり、
前記割り込まれたブロックの実行を再開する段階を更に含む、請求項18に記載の方法。
【請求項20】
前記指定イベントが例外イベントであり、
前記割り込まれたブロックの実行を再開することなく、前記グラフィカルモデルの前記実行の制御を、該割り込まれたブロックを呼び出した呼出プロセスに返す段階を更に含む、請求項18に記載の方法。
【請求項21】
前記イベントが、オブジェクトとして予め定義される、請求項18に記載の方法。
【請求項22】
前記イベントが明示イベントである、請求項21に記載の方法。
【請求項23】
前記イベントが暗黙イベントである、請求項21に記載の方法。
【請求項24】
前記オブジェクトがタスクオブジェクトに関連付けられており、該タスクオブジェクトがオペレーティングシステムのタスクに対応する、請求項21に記載の方法。
【請求項25】
前記タスクオブジェクトが指定レート及び優先順位の少なくとも1つのプロパティを含む、請求項24に記載の方法。
【請求項26】
異なるタスクが少なくとも2つのイベントで実行されるように指定されている場合、
イベント遷移ブロックを用いて前記少なくとも2つのイベントに関連付けられたブロックの実行をスケジューリングする段階を更に含み、該イベント遷移ブロックが、前記少なくとも2つのイベントに関連付けられた前記ブロックの間で機能する、請求項25に記載の方法。
【請求項27】
前記演算が分岐優先順位ブロックに示された実行順序により制御される、請求項18に記載の方法。
【請求項28】
前記演算が2つ以上のブロックグループの実行であり、該ブロックグループがユーザにより予め選択されたブロックグループであり、該ブロックグループの実行順序がユーザにより予め指定される、請求項18に記載の方法。
【請求項29】
グラフィカルモデリング環境における少なくとも1つの実行可能なグラフィカルモデルの実行を制御するためのコンピュータ実行可能な命令を保持した物理的かつ非一時的なコンピュータ可読媒体であって、前記命令が、
前記グラフィカルモデルのビューを複数の実行可能なブロックで表示する1つまたは複数の命令であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する1つまたは複数の命令と、
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する1つまたは複数の命令と、
前記条件が満足された時に、前記告知ブロックに前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知させる1つまたは複数の命令と、
前記イベントの前記発生を、該イベントに関連付けられた前記少なくとも1つの実行可能なブロックに通知する1つまたは複数の命令であって、前記イベントの前記発生が、前記少なくとも1つの実行可能なブロックを実行させる契機となる、通知する1つまたは複数の命令と、
前記グラフィカルモデリング環境において、前記グラフィカルモデルのシミュレーション時に、前記少なくとも1つの実行可能なブロックを、特定の時刻に応答するのではなく、前記通知に応答して実行させる1つまたは複数の命令とを含む、非一時的なコンピュータ可読媒体。
【請求項30】
前記命令が、前記少なくとも1つの実行可能なブロックを前記イベントハンドラに登録する1つまたは複数の命令を更に含む、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項31】
前記少なくとも1つの告知ブロックがラベルである、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項32】
前記命令が、前記少なくとも1つの実行可能なブロックのサンプルレートを前記イベントとして指定する1つまたは複数の命令を更に含む、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項33】
前記命令が、前記サンプルレートを前記少なくとも1つの実行可能なブロックから他の実行可能なブロックに伝播させる1つまたは複数の命令を更に含み、前記他の実行可能なブロックが前記サンプルレートを継承するように構成される、請求項32に記載の非一時的なコンピュータ可読媒体。
【請求項34】
前記命令が、前記グラフィカルモデルにおいてグループ化されていない非連続の複数の実行可能なブロックのサンプルレートを前記イベントとして指定する1つまたは複数の命令を更に含む、請求項32に記載の非一時的なコンピュータ可読媒体。
【請求項35】
前記命令が、前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックを該ブロック間のグラフィカル結合を伴わずに表示させる1つまたは複数の命令を更に含む、請求項34に記載の非一時的なコンピュータ可読媒体。
【請求項36】
前記命令が、前記少なくとも1つの実行可能なブロックの前記サンプルレートが前記イベントとして指定されていることを、前記グラフィカルモデルのビューに前記イベントの名前を用いて表示させる1つまたは複数の命令を更に含む、請求項32に記載の非一時的なコンピュータ可読媒体。
【請求項37】
前記イベントがユーザによって設定される明示イベントである、請求項32に記載の非一時的なコンピュータ可読媒体。
【請求項38】
前記イベントが、前記グラフィカルモデルの前記実行に伴って自動的に告知される暗黙イベントである、請求項32に記載の非一時的なコンピュータ可読媒体。
【請求項39】
前記暗黙イベントがパワーアップ、パワーダウン、及び初期設定の1つである、請求項38に記載の非一時的なコンピュータ可読媒体。
【請求項40】
前記暗黙イベントが、サブシステムの使用可能及び使用禁止の何れかに対応する、請求項38に記載の非一時的なコンピュータ可読媒体。
【請求項41】
前記命令が、前記グラフィカルモデルのビューにおいて、前記非連続の複数の実行可能なブロックの論理的関連付けをユーザに色で表示させる1つまたは複数の命令を更に含む、請求項34に記載の非一時的なコンピュータ可読媒体。
【請求項42】
前記告知ブロックは、前記入力信号がゼロを上回る時を条件として前記イベントを告知するよう構成されている、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項43】
前記グラフィカルモデルの各イベントがイベントハンドラに1対1でマッピングし、該イベントハンドラが関数である、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項44】
前記関数がコード生成時にインライン化されている、請求項43に記載の非一時的なコンピュータ可読媒体。
【請求項45】
前記通知に応答して、分岐優先順位ブロックが、少なくとも2つの実行可能なブロックの実行順序を示す、請求項29に記載の非一時的なコンピュータ可読媒体。
【請求項46】
前記通知に応答して2つ以上のブロックグループが実行され、該ブロックグループがユーザにより予め選択されたブロックグループであり、該ブロックグループの実行順序がユーザにより予め指定される、請求項45に記載の非一時的なコンピュータ可読媒体。」
と補正するとともに、

明細書の発明の詳細な説明の段落【0001】【0003】を削除し、
同段落【0007】を
「 Simulink(商標)サンプルレートは、モデルの構成要素を実行する頻度を指定するための機構を提供している。図1は、モデル構成要素の実行を制御するにあたりサンプルレートを使用する例を示す。例えば、設計者は、プラントブロック4が連続レートで実行し、コントローラブロック10が周期的且つ離散的レートで実行することを指定できる。モデル構成要素の実行は、シミュレーション時にSimulink(商標)インフラストラクチャにより、或いは実時間実装を目的としてオペレーティングシステムによりスケジューリングされる。モデルの動態とこれらレートのスケジューリングとの間には何の因果関係もなく、構成要素が実行される時点は予め定められている。」と、
同段落【0013】を
「 一実施形態では、複数の実行可能な構成要素を具備した少なくとも1つのモデルを備えたモデリング環境において、一方法は、前記モデルの実行中に指定されたイベントの発生を監視する。前記指定イベントの発生が確認されると、該発生はイベントハンドラに告知される。すると、前記イベントハンドラへの通知に応答して構成要素が実行される。」と、
同段落【0014】を、
「 別の実施形態では、複数の実行可能構成要素を具備した少なくとも1つのモデルを備えたモデリング環境において、一方法は、前記モデルの実行中に指定されたイベントの発生を監視する。前記指定イベントの発生が確認されると、前記指定イベントの発生の確認に応答して、別のイベントの実行に割り込みが掛けられる。前記指定イベントの発生の確認に応答して、前記モデルにおける演算が行われる。」
と補正するものである。

(3)平成26年7月14日付け意見
上記平成26年7月14日付けの意見書の意見の内容は概略次のとおりである。
『【意見の内容】
1.補正の説明
この意見書と同日付で手続補正書を提出し、特許請求の範囲および発明の詳細な説明において以下のような補正を行った。この補正により特許請求の範囲および発明の詳細な説明の記載が明確になったので、拒絶理由1は解消したと確信する。
(1)補正後の請求項1において、「複数の実行可能なブロックを具備した少なくとも1つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって」の補正事項は、当初明細書の段落0004、0020の記載に基づく。この補正により、拒絶理由1の(1)、(2)、(3)、(4)で指摘された記載上の不備が解消した。

・・・中略・・・

(22)平成23年11月24日付の手続補正書における請求項30,31,32を削除した。この補正により、拒絶理由1の(33)、(34)、(35)、(36)で指摘された記載上の不備が解消した。
(23)補正後の請求項29-46は、今回、新たに追加された請求項である。
(24)以上に説明した特許請求の範囲の補正、並びに、同日付の手続補正書でした発明の詳細な説明の補正により、拒絶理由1の(37)、(38)で指摘された記載上の不備が解消した。
2.本願発明の説明
本願の請求項1-46に係る発明は、特に請求項1、18,29に係る発明において、グラフィカルモデルのビューに告知ブロックを表示し、該告知ブロックの入力信号に関連付けられた条件が満足された時に、その告知ブロックがイベントの発生をイベントハンドラに告知するよう構成したことを技術的特徴とし、それによって、不特定の時刻に発生したイベントに応答して、グラフィカルモデルの構成要素であるブロックを実行できるという格別な作用効果を奏するものである。
3.引用発明の説明
引用文献1?3には、現代制御理論等に対応した所謂リアルタイムシミュレターにおいてイベントドリブン機能を備えた発明(引用発明1-3)が記載されている。引用文献4には、イベントハンドラを用いてイベントドリブン機能を実現する発明(引用発明4)が記載されている。
4.本願発明と引用発明との対比
本願発明と引用発明1-3とは、シミュレターにおいてイベントドリブン機能を備えている点で類似するが、本願発明は、不特定な時刻に発生するイベントをイベントハンドラに告知するブロックを備えているのに対し、引用発明1-3は、そのようなブロックを備えていない点で相違する。
本願発明と引用発明4とは、イベントハンドラを採用している点で類似するが、そのイベントハンドラが、本願発明では、告知ブロックと連携して、不特定な時刻に発生するイベントを少なくとも1つの実行可能なブロックに通知するのに対し、引用発明1では、そのような通知を行っていない点で相違する。
5.本願発明が特許されるべき理由
以上対比したように、本願発明の技術的特徴点は引用発明1-4の何れにも開示されていない。したがって、本願の請求項1-46に係る発明は、たとえ引用発明1-4を総合したとしても、そこから直ちに導き出すことができない発明であり、当然、すべてが特許されるべきである。よって、拒絶理由2は解消したと確信する。
6.むすび
以上のとおり、拒絶理由1,2は解消したので、この意見書と手続補正書を採用のうえ、本願に対し速やかに特許査定を賜りたい。』


3.引用文献

(1)本願の出願前である上記優先日よりも前に頒布または電気通信回線を通じて公衆に利用可能となり、上記当審拒絶理由の2.において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。)

<引用文献1>
石塚 真一,「高度な制御理論に対応した設計が可能になるMATLABファミリ」,Interface,CQ出版株式会社,平成9年9月1日,第23巻,第9号,p.84-85

<引用文献記載事項1-1>
「このようなシステムはFSM(Finite State Machine:有限状態機械)として知られ,これを効率よく記述するものが状態遷移図と呼ばれるもです.Stateflowは,この状態遷移図を発展させたステートチャートをGUI環境で簡便に記述し,さまざまなFSMを構築するツールです.また,Stateflowで記述したFSMは,Stateflow Coderを用いることによりC言語に変換することができます」(第85頁左欄下から10行目から最下行)


<引用文献2>
「MATLAB」,計測と制御,社団法人計測自動制御学会,平成11年1月10日,第38巻, 第1号,p.80-81

<引用文献記載事項2-1>
「1.はじめに
現代制御理論やロバスト制御理論などの先端的な制御理論は,理論自身の発展とマイコンやDSPなどのハードウェアの進歩,そして設計を支援するソフトウェアの整備が進んだことによって,一部の研究者のものから次第に一般的にも利用可能なものとなってきている.米国Math-Works社が開発するMATLAB製品ファミリーは,こうした制御理論普及の流れの中で広く利用されてきた.本稿ではこのMATLAB製品ファミリーの概要を紹介する.」(第80頁左欄第1行?第9行)

<引用文献記載事項2-2>
「2.製品構成
現在のMATLAB製品ファミリーは,図1に示すようにMATLAB,Simulink,Stateflowを中心として,ToolboxやBlocksetと呼ばれる各種の拡張ライブラリや,Real-Time Workshop,Stateflow Coder等の自動コード生成ツールなどから構成されている.
Toolboxは各種の制御理論に基づく解析・設計ツール,システム同定・信号処理などのデータ解析・モデリング機能を提供する.Simulinkはブロック線図によるシステムのモデリングと非線形シミュレーション機能を備え,Stateflowはステートチャートまたはフローダイアグラムによるイベントドリブンシステムの記述機能をSimulinkに追加する.Real-Time WorkshopとStateflow Coderは,これらで記述したシステムモデル(コントローラやプラントモデルなど)からCのソースコードを自動生成する機能を提供するもので,これにより設計したシステムのプロトタイプ開発やソフトウェア実装を効率よく行うことができる.」(第80頁左欄第10行?同頁右欄第4行)

<引用文献記載事項2-3>
「3.Simulink/Stateflowによる倒立振子の制御系設計例(データフローとコントロールフロー記述の統合化)
制御系の設計は,「フィードバック制御」と「シーケンス制御」に分けて考えることができる.前者の「センサ測定量に基づいて操作量を計算する」といったデータフローの記述にはSimulinkのブロック線図によるモデル化手法が適している.それに対して後者の「起こりうるさまざまな状況(イベント)に応じてシステムの状態を切り替えていく」コントロールフローの記述には,従来から状態遷移図と呼ばれる手法が用いられてきた.Stateflowは,この状態遷移図をさらに発展させたステートチャートを記述してSimulinkモデルに組み込む機能を追加する製品である.実際のシステムでは多くの場合このシーケンス制御とフィードバック制御が混在している.SimulinkとStateflowによるブロック線図記述とステートチャート記述の統合化は,このような実問題に対する使いやすく機能的な設計環境を提供する.」(第80頁右欄第5行?第22行)

<引用文献記載事項2-4>
「図2はアーム型倒立振子(写真1)の制御実験に用いたコントローラのモデルである.ここでは具体的につぎの3つのモードを考えたコントローラを設計している.
○1(当審注:「○数字」は「数字」を「○」で囲った文字を意味する。以下同様。)振子を鉛直下向きに静止させた状態から振り上げる.
○2振子を鉛直上向き状態に保つ(制御状態).
○3制御を切り,振子が鉛直下向きに静止するまで待つ.
この3つのモードを繰り返す.モード○1から○2への切り替えは振子の角度・角速度がある条件を満足したときに,モード○2から○3へと○3から○1への切り替えはおのおのある設定時間経過後に行うことにする.このように設定した論理条件を満足したときに状態を切り替えるような制御モデルは,Stateflowを利用することで容易に記述できる.」(第80頁右欄第23行?第81頁左欄第7行)

<引用文献記載事項2-5>
「図2中でControl Logicという名前を付けられたブロックはStateflowにより記述されたモデルで,ここから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモード(Hold,Swing,Wake-up)の実行を切り替えている.図3にそのControl Logicブロックの内部を示す.これがStateflowで記述されたステートチャートで,モードの切り替えのロジックと(実際には,緊急停止モードを加えた4つのモードがある)タイマーを記述している.
このようにStateflowをSimulinkと併用することで,コントロールフローをわかりやすい形でモデルに組み込むことが可能になる.」(第81頁左欄第8行?同頁右欄第11行)

<引用文献記載事項2-6>


」(第81頁)

<引用文献記載事項2-7>


」(第81頁)

<引用文献3>
「動的システムをモデリング/シミュレーションするためのツール Simulinkの基礎」,Interface,CQ出版株式会社,平成13年10月1日,第27巻, 第10号,p.28-52


<引用文献記載事項3-1>
「ブロックを配置するためには,ライブラリブラウザで希望のブロックを左クリックした状態でドラッグし,モデルウインドウの任意の場所にドロップする.ここでは,SourceライブラリにあるSine Waveブロックを配置する.なお,モデルウィンドウ上のブロックは,左クリックのドラッグ&ドロップ,またはキーボードの矢印キーで移動する.」(第30頁第5行?第8行)


<引用文献4>
米国特許第5497500号明細書

<引用文献記載事項4-1>
「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. Each occurrence function call also includes a respective argument which informs the function as to which Wait on Occurrence node is to be requeued. This argument is provided to the occurrence handler function call at compile time.」(第49欄第4行?第38行)
(当審訳:「事象メモリ機構
ここで図119を参照すると、事象がメモリに実装される方法を説明する図が示されている。ここに示されるように、本発明はブロック図上の事象生成ノードに対応する多数の事象入力を含む事象テーブルを含む。同様に、他の非同期ノードが事象テーブル上に配置されることがわかる。
事象待ち受けノードがランタイム中にエンカウントされるとき、すなわち、その事象待ち受けノードへの入力がランタイム時に到達するとき、実行サブシステムが事象識別子を使って事象テーブル中へ索引付けをする。上述のとおり、事象識別子は事象待ち受けノードに接続している各事象生成ノードの出力である。
そのサブシステムはポインタを構成する適切な入力に索引付けをして、そしてその入力を1あるいはより多くの入力を持っている事象ハンドラポインタテーブルをアクセスするために使う。事象ハンドラポインタテーブルは、各事象が設定されているときに識別されそして呼び出されることを要求するすべてのノードを含む。このとき、新規入力が各事象待ち受けノードのために作成され、そのノードは「装備済み」と言われる。図119に示されるように、事象ハンドラポインタテーブルの各自の入力はそれぞれの事象ハンドラファンクションコールを指し示す。各事象ハンドラファンクションコールは、各自の事象が起こるか、あるいは「トリガーされる」とき、事象待ち受けノードの動作を再開する事象ハンドラファンクションの開始アドレスを含む。そして、事象ハンドラファンクションコールは、その事象がトリガーされるとき、実行キュー上の事象待ち受けノードをリキューすることがその役割である関数をコールする。それぞれの事象ファンクションコールは、同様に、それへの事象待ち受けノードがリキューされるべき関数に通知する各引数を含む。この引数はコンパイル時に事象ハンドラファンクションコールに供給される。」)


第2.当審拒絶理由1(特許法第36条)について

1.拒絶理由
上記当審拒絶理由の理由1.で通知した特許法第36条についての拒絶理由は上記第1.2.(1)の理由の1.に記載のとおりのものであり、これに対して上記第1.2.(2)に示した上記平成26年7月14日付け手続補正(以下単に「上記補正」と記す。)がなされるとともに、上記第1.2.(3)に示した意見書が提出されている。

2.当審判断
(1)理由1.(1)について
当審拒絶理由の理由1.(1)で意味・定義が明確でないと指摘された「実行可能な」「構成要素」との記載は、上記補正後の請求項1、18、29においては「実行可能なブロック」との記載に補正された。
しかしながら、上記補正後の請求項1、18、29における「ブロック」は「ビュー」に「表示」される「グラフィカルモデル」の要素にほかならないものであり、プログラムや電子回路のように「実行可能」なものではないので、特許請求の範囲の記載のみからは「実行可能なブロック」との意味を明確に把握することはできない。
そして、この点について発明の詳細な説明を参酌するに、本願明細書における「ブロック」が制御系の要素であることから、何らかの制御を行う要素を「実行可能なブロック」と表現しているとの解釈や、「ブロック」がシミュレーションの対象となる系の要素であることから、「シミュレーション」を行うことができる要素を「実行可能なブロック」と表現しているとの解釈等、様々な解釈が可能となるものの、その意味を明確に定義する記載等、いずれかの解釈に特定可能とできるような記載は見当たらない。
してみると、当審拒絶理由の理由1.(1)で指摘した不備は依然として解消されておらず、本願請求項1?46に係る発明は明確でない。
さらに、このため、本願の発明の詳細な説明は、当業者が本願請求項1?46に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、本願請求項1?46に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものであるとも言える。

(2)理由1.(38)について
上記当審拒絶理由通知書の理由1.(38)において、意味の不明確な記載等として例示したオ.?ニ.の点に関しては、何ら補正がされていない。
このため、当審拒絶理由通知書の理由1.(38)オ.?ニ.において示した記載の意味は依然として不明確であり、かかる本願の発明の詳細な説明の記載内容から、本願請求項1?46に係る発明の構成を正確に理解しこれを再現することも、本願請求項1?46に係る発明が如何なる課題を解決するためのもので、如何なる効果が奏されるのかといった、本願請求項1?46に係る発明の技術上の意義を正確に理解することは、当業者と言えども不可能である。
また、上記補正と同日付けの意見書においても実質的な反論や釈明はなされていない。

3.小結
よって、本願の発明の詳細な説明及び特許請求の範囲の記載は、特許法第36条第4項第1号及び同条第6項第2号に規定する要件を満たしていない


第3.当審拒絶理由2(特許法第29条第2項)について

1.本願発明の認定
本願請求項1に係る発明(以下「本願発明」と記す。)は、上記平成26年7月14日付けの手続補正書によって補正された特許請求の範囲、明細書および図面の記載からみて、上記第1.1.(2)に【請求項1】として記載したとおりのものと認める。

2.引用文献
上記当審拒絶理由の理由2.で通知した特許法第29条第2項についての拒絶理由は上記第1.2.(1)の理由の2.に記載のとおり、上記第1.3.に挙げた引用文献1?4を引用するものである。

3.引用発明の認定
(1)
ア.引用文献2は引用文献記載事項2-1記載のとおり「MATLAB製品ファミリーの概要を紹介する」ものであるところ、引用文献記載事項2-3などから、当該「MATLAB製品ファミリー」の「Simulink」と「Stateflow」とによって「ブロック線図記述とステートチャート記述の統合化」がなされた「設計環境」が提供されることが読み取れる。
イ.また、引用文献記載事項2-2等から該「Simulink」が「ブロック線図によるシステムのモデリングと非線形シミュレーション機能を備え」たものであることが記載され、引用文献記載事項2-3以降では当該環境での「設計例」が説明されているのであるから、これらの記載からは当該環境における「モデリングとシミュレーションを行う方法」を読み取ることができる。
ウ.してみると、引用文献2には
「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法」
が記載されていると言える。

(2)上記引用文献記載事項2-4から
該「モデリングとシミュレーション」の対象は「アーム型倒立振子の制御実験に用いるコントローラ」であり、該「コントローラ」は「振子を鉛直下向きに静止させた状態から振り上げる」「モード○1」と、「振子を鉛直上向き状態に保つ」「モード○2」と「制御を切り,振子が鉛直下向きに静止するまで待つ」「モード○3」の「3つのモードを繰り返」し「モード○1から○2への切り替えは振子の角度・角速度がある条件を満足したときに,モード○2から○3へと○3から○1への切り替えはおのおのある設定時間経過後に行う」ものであることが読み取れる。
したがって、
「該モデリングとシミュレーションの対象はアーム型倒立振子の制御実験に用いるコントローラであり、
該コントローラは
振子を鉛直下向きに静止させた状態から振り上げる第1のモードと、
振子を鉛直上向き状態に保つ第2のモードと、
制御を切り,振子が鉛直下向きに静止するまで待つ第3のモードを有し、
この3つのモードを繰り返すもので、
前記第1のモードから前記第2のモードへの切り替えは振子の角度・角速度がある条件を満足したときに,前記第2のモードから前記第3のモードへと前記第3のモードから前記第1のモードへの切り替えはおのおのある設定時間経過後に行うもの」
であると言える。

(3)上記引用文献記載事項2-6等から、
『該コントローラのモデルは、
「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」という名前を付けられた信号が出力されるブロック線図で記述され』
るものであると言える。

(4)そして、上記引用文献記載事項2-5の「図3にそのControl Logicブロックの内部を示す.これがStateflowで記述されたステートチャートで,モードの切り替えのロジックと(実際には,緊急停止モードを加えた4つのモードがある)タイマーを記述している.」との記載や上記引用文献記載事項2-7等から、
『前記「Control Logic」という名前を付けられたブロックのモードの切替えロジックは前記「timer」「arm_p」「arm_v」「pend_p」「pend_v」「clock」を用いたステートチャートで記述されるもの』
であると言える。

(5)さらに上記引用文献記載事項2-5の「図2中でControl Logicという名前を付けられたブロックはStateflowにより記述されたモデルで,ここから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモード(Hold,Swing,Wake-up)の実行を切り替えている.」との記載等から、
『該ブロック線図とステートチャートとで、前記「Control Logic」という名前を付けられたブロックから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモードの実行を切り替えることを表している』
と言える。

(6)よって、引用文献2には、下記引用発明が記載されていると認められる。

<引用発明>
「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法であって、
該モデリングとシミュレーションの対象はアーム型倒立振子の制御実験に用いるコントローラであり、
該コントローラは
振子を鉛直下向きに静止させた状態から振り上げる第1のモードと、
振子を鉛直上向き状態に保つ第2のモードと、
制御を切り,振子が鉛直下向きに静止するまで待つ第3のモードを有し、
この3つのモードを繰り返すもので、
前記第1のモードから前記第2のモードへの切り替えは振子の角度・角速度がある条件を満足したときに,前記第2のモードから前記第3のモードへと前記第3のモードから前記第1のモードへの切り替えはおのおのある設定時間経過後に行うものであり、
該コントローラのモデルは、
「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」という名前を付けられたブロックから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモードの実行を切り替えることを表している
方法。」


4.対比
以下に、本願発明と引用発明とを比較する。

(1)
ア.引用発明は「ブロック線図記述とステートチャート記述の統合化がなされた設計環境において、モデリングとシミュレーションを行う方法」であり、該「ブロック線図記述とステートチャート記述」は「グラフィカルモデル」とも言えるものである。

イ.そして、当該「ブロック線図記述」が複数の「ブロック」からなるものであることは明らかである。

ウ.また、引用発明における『「Control Logic」という名前を付けられたブロック』は「イベントドリブンなサブシステムとして記述されている3つのモードの実行を切り替える」と言う制御を実行するものであり、更に該「サブシステム」は「振子を鉛直下向きに静止させた状態から振り上げる第1のモード」「振子を鉛直上向き状態に保つ第2のモード」「制御を切り,振子が鉛直下向きに静止するまで待つ第3のモード」における制御を実行するものであり、引用発明においてはこれらの「シミュレーション」を行うことができることは明らかである。そして、本願発明における「実行可能なブロック」の技術的な意味は必ずしも明確なものではないものの、このような「制御を実行する」ものを表すブロックや「シミュレーション」を行うことができるブロックは「実行可能なブロック」に含まれると解することができる。

エ.したがって、引用発明も本願発明と同様に
「複数の実行可能なブロックを具備した少なくとも1つの実行可能なグラフィカルモデルを備えた環境において実行される方法」
と言えるものである。

(2)
ア.引用発明において「モデリングとシミュレーションの対象」となる「アーム型倒立振子の制御実験に用いるコントローラ」は「動的システム」にほかならない。

イ.引用発明における『「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」という名前を付けられた信号』は「出力」にほかならない

カ.したがって、引用発明においても本願発明と同様に
「前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し」
ていると言える。

(3)
ア.引用発明における「コントローラ」の「モデリング」においてはその「モデル」を表す「ブロック線図」が「表示」されることは明らかであり(必要があれば引用文献記載事項1-1、3-1等参照)、これは「前記グラフィカルモデルのビューを表示する」ものであるとも言える。

イ.また、引用発明における「「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つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階」
を含むと言える。

(4)
ア.引用発明においては『「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つの実行可能なブロックを前記イベントに関連付ける段階」
を含むと言える。

(5)
ア.引用発明において「モデリング」されたモデルを「シミュレーション」することは、「グラフィカルモデルの実行」とも言えるものであり、その際に「ステートチャート」で記述されたとおりの状態遷移の遷移条件を満たすか否か識別することは明らかであり、これは「前記告知ブロックにおいて前記条件が満足された時を識別する」ことにほかならない。

イ.したがって、引用発明も本願発明と同様に
「前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階」
を含むと言える。

(6)
ア.引用発明における「ブロック線図とステートチャート」は『前記「Control Logic」という名前を付けられたブロックから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモードの実行を切り替えることを表している』のであるから、その「シミュレーション」の際には、『「Control Logic」という名前を付けられたブロック』から『「Hold Mode」という名前を付けられたブロック』『「Swing Mode」という名前を付けられたブロック』および『「Wake Up Mode」という名前を付けられたブロック』にイベントの発生が通知されることが模擬されることは明らかであり、引用発明は「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むと言える。

イ.なお、本願発明における「ブロック」は「ビュー」に「表示」される「グラフィカルモデル」の「ブロック」にほかならず、技術常識からみて「通知」の相手となるものではないので、本願発明における「イベントの発生を」「ブロックに通知する」との表現の技術的な意味は必ずしも明確なものではない。しかしながら、本願発明の詳細な説明においても「Simulink」を例示して説明している点などを参酌すれば、この表現は「シミュレーション」の際に「ブロック」が表現する技術的手段に「イベントの発生」が通知されることを模擬することを意味すると解することができる。

ウ.一方、本願発明は「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生をイベントハンドラに告知する段階」と「前記イベントハンドラが前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むのであるから、本願発明も「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」を含むと言える。

エ.したがって、引用発明と本願発明とは
「前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階」
を含む点で共通すると言える。

(7)
ア.引用発明における『「Control Logic」という名前を付けられたブロックから発生させるイベント信号により,それぞれイベントドリブンなサブシステムとして記述されている3つのモードの実行』をすることは、「特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する」ことにほかならない。

イ.したがって、引用発明も本願発明と同様に
「特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する段階」
を含むと言える。

(8)よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。

<一致点>
「複数の実行可能なブロックを具備した少なくとも1つの実行可能なグラフィカルモデルを備えた環境において実行される方法であって、前記ブロックが連続的にまたは特定の時刻に離散的に変化する入力と、状態と、出力とを備えた動的システムを表し、
前記グラフィカルモデルのビューを表示する段階であって、前記ビューに、少なくとも1つの入力信号を受け取るための少なくとも1つの入力ポートを備えた少なくとも1つの告知ブロックが含まれ、該告知ブロックが、前記入力信号に関連付けられた条件が満足された時にイベントを告知するよう構成されている、表示する段階と、
少なくとも1つの実行可能なブロックを前記イベントに関連付ける段階と、
前記グラフィカルモデルの実行中に、前記告知ブロックにおいて前記条件が満足された時を識別する段階と、
前記条件が満足された時に、前記告知ブロックが前記グラフィカルモデルにおける前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知する段階と、
特定の時刻に応答させるのではなく前記通知に応答して、前記少なくとも1つの実行可能なブロックを実行する段階とを含む、方法」。

<相違点>
本願発明においては、前記イベントの発生を「イベントハンドラに告知する段階」を有し、「前記イベントハンドラが」前記イベントの発生を前記少なくとも1つの実行可能なブロックに通知するものである。
(これに対し、引用文献2にはイベントドリブン機能をシミュレーションするための具体的な構成までは開示されていない。)


5.判断
(1) 上記相違点について検討するに、引用発明におけるイベントドリブン機能はシミュレーションの対象となるものであるから、ハードウエアとして実装せずにソフトウエア的に実装すべきものであることは明らかであるところ、このような事象の発生に応動する制御機構を当該事象の発生に対応付けられたハンドリングを行う関数、所謂ハンドラを呼び出すように構成することでソフトウエア的に実装することは、当該技術分野においては常套手段にすぎないものである(必要があれば引用文献記載事項4-1等参照)。
してみると、引用発明においてイベントドリブン機能の実現のために、かかるハンドラを用いた機構を採用することは、当業者の通常の創作力の発揮にすぎないものであり、そしてこの場合には、必然的に該ハンドラは「イベントハンドラ」と称し得るものとなり、告知ブロックは前記イベントの発生を「イベントハンドラに告知する」ものとなり、該「イベントハンドラ」が前記イベントの発生を実行可能なブロックに通知するものとなる。
したがって、引用発明を上記相違点に係る構成を備えたものとすることは当業者であれば容易に想到し得たものである。
そして、これによって格別予測困難な作用効果が奏されるものでもない。

(2)してみると、本願発明の構成は引用文献2に記載された発明に基づいて、当業者が容易に想到し得たものであり、また、本願発明の効果は当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本願発明は、引用文献2に記載された発明に基づいて、当業者が容易に発明をすることができたものである。

6.小結
以上のとおり、本願請求項1に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。


第4.むすび

上記第2.のとおり、本願の発明の詳細な説明及び特許請求の範囲の記載は、特許法第36条第4項第1号及び同条第6項第2号に規定する要件を満たしていないので、本願は拒絶すべきものである。

上記第3.のとおり、本願請求項1に係る発明は特許法第29条第2項の規定により特許を受けることができないものであるから、他の請求項についての検討をするまでもなく、本願は拒絶すべきものである。

よって、上記結論のとおり審決する。
 
審理終結日 2014-10-10 
結審通知日 2014-10-14 
審決日 2014-10-27 
出願番号 特願2006-549406(P2006-549406)
審決分類 P 1 8・ 536- WZ (G06F)
P 1 8・ 121- WZ (G06F)
P 1 8・ 537- WZ (G06F)
最終処分 不成立  
前審関与審査官 新井 寛  
特許庁審判長 辻本 泰隆
特許庁審判官 田中 秀人
山崎 達也
発明の名称 モデルイベントを用いてモデル構成要素の実行をスケジューリングするためのシステム及び方法  
代理人 水野 祐啓  

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