【事件の表示】
　特願２０１１−２６４７１６「将来の損失に関連する頻度を予測し、損失決定ユニットの関連する自動処理のためのシステム及び方法」拒絶査定不服審判事件〔平成２４年　８月　９日出願公開、特開２０１２−１５０７８８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２３年１２月２日（パリ条約による優先権主張２０１０年１２月３日：世界知的所有権機関）の出願であって，平成２６年８月１２日付けの拒絶理由通知に対して，平成２７年２月１９日に意見書の提出とともに手続補正がなされたが，平成２７年４月３日付けで拒絶査定がなされ，これに対し平成２７年８月６日に審判請求がなされ，平成２８年５月１２日付けの当審による拒絶理由通知に対して，平成２８年８月１７日に意見書の提出とともに手続補正がなされたものである。
　　
第２　平成２８年５月１２日付け拒絶理由通知の概要
　平成２８年５月１２日付けで，当審より通知した拒絶理由（以下「当審拒絶理由」という。）の内容は，以下のとおりである。
「　　　　　　　　　　　　　　　　理　由 
   　
Ａ　この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていない。 
 　 
　　　　　　　　　　　　　　　　　　記 
・・・（省略）・・・
　　 
Ｂ　この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。 
　 
　　　　　　　　　　　　　　　　　　記 
〔請求項１について〕 
　請求項１は「複数の動作ユニットに関する個別のリスクについて将来の損失に関する頻度及び損失分布の予想に利用される制御装置によって実行される方法」であって，この「制御装置」は明細書の第【００１８】段落に「コントロールユニットであるコントローラ１０は，１以上のデータ処理ユニット，ディスプレイ，及びキーボード及び／又はコンピュータマウス又は他のポインティング装置などの他の動作要素を有することが可能である。」と記載されているように実質的にコンピュータであることから，特定される各ステップについて，コンピュータによる情報処理として実施することができる程度に明確かつ十分に記載されているかについても検討する。 
（１）請求項１の「動作ユニット」について，明細書の第【００１７】段落には「動作ユニット３０は，例えば，デバイスコントローラ，バルブ，ポジショナー，スイッチ，送信機（温度，圧力及びフローレートセンサなど）又は他の何れかの技術的装置など，すべてのタイプの動作又はフィールド装置から構成可能である。・・・通常，動作ユニット３０は，ユーザ又は企業に割り当てられるか，又は少なくともユーザ又は企業を表す。」と記載されており，なんらかの装置であってユーザ又は企業に割り当てられるものとは一体どのような装置を意味するものであるのか，また，ユーザ又は企業を表す装置とは一体どのような装置を意味するものであるのか全く不明である。 
（２）請求項１の「複数の動作ユニットのそれぞれは少なくとも１つの測定可能な責任負担を有し」について，例えば明細書の第【００１７】段落には「独立して実行される責任リスク要因３１１〜３１３を用いた少なくとも１つの測定可能な責任エクスポージャ３１を有する複数の動作ユニット３０」と記載されているが，そもそも測定可能な「責任負担」や「責任エクスポージャ３１」が，コンピュータにより処理可能な情報として具体的にどのようなデータ構造を有する情報であるのか等が全く記載されておらず不明であり実施できない。 
（３）請求項１の「損失単位に割り当てられた測定装置によって送信された測定パラメータを動的に選択するステップ」について，この「損失単位」は，明細書の第【０００８】段落には「損失ユニットは，動作ユニットによるアクション又はインタラクションに晒される，すなわち，動作ユニットによる責任問題を受けるリスクに晒される何れかのタイプのデバイス，システム又は人間とすることができる。」と記載されており，上記（１）で示したように「動作ユニット」自体が不明であり，該「動作ユニット」によりリスクに晒されるデバイスやシステムが具体的にどのようなものであるのかも不明である。 
　また，上記「測定装置」は，明細書の第【００１７】段落に「測定装置２０１，．．．，２６１は，特にすべてのタイプのセンサ及びデータキャプチャリング又はフィルタリング装置である，すべてのタイプの物理的又は解析的測定装置から構成可能である。」と記載されており，当該「測定装置」は「損失単位に割り当てられた」ものとしているが，具体的にデバイス，システム又は人間にどのように割り当てるというものであるのかが記載がなく実施できない。 
　また，「測定装置によって送信された測定パラメータを動的に選択する」との処理については，上記Ａ（２）で示したように具体的にどのような処理であるのかはそもそも明細書に記載されておらず，コンピュータによる情報処理として測定パラメータをどのような選択基準に基づいて動的に選択するというのかが全く不明であり実施できない。 
（４）請求項１の「前記選択された測定パラメータを複数の責任リスクドライバの少なくとも１つに動的に割り当てるステップ」について，明細書の第【０００８】段落には「損失ユニットにおいて損失が発生した場合，測定パラメータが測定され，前記コントロールユニットであるコントローラに送信され，前記責任リスクドライバに動的に割り当てられ」と記載され，また，第【００１７】段落にも「損失ユニット２０〜２６において損失が発生した場合，測定パラメータが測定され，制御ユニットであるコントローラ１０に送信され，責任リスク要因３１１〜３１３に動的に割り当てられる。」との記載があるものの，コンピュータによる情報処理として，具体的にどのような処理により割り当てる責任リスクドライバを選択し，動的に割り当てるのか，また，そもそも測定パラメータを割り当てるとはコンピュータによる情報処理として具体的にどのような処理を意味するものであるのかも不明であり実施できない。 
　また，上記「責任リスクドライバ」について，明細書の第【００２０】段落に「少なくとも１つの測定可能な責任エクスポージャ３１が，複数の動作ユニット３０のそれぞれに割り当てられる。各責任エクスポージャ３１は，責任リスクドライバ３１１〜３１３を用いて表すことが可能である。・・・責任リスクドライバ３１１〜３１３は，コントロールユニットであるコントローラ１０の信号生成と電子的にやりとりするハードウェア及び／又はソフトウェアベースの機能モジュールである。」との記載はあるものの，具体的に該「責任リスクドライバ」がどのような動作を行うのか，インプット及びアウトプットされる情報は具体的にどのような情報であるのか，また，そもそも「責任エクスポージャ３１」とどのような関係があるのかが不明であり実施できない。 
（５）請求項１の「前記複数の動作ユニットの少なくとも１つについて前記測定可能な責任負担をパラメータ化した前記複数の責任リスクドライバのサブセットを選択し，前記選択された測定パラメータに基づき前記複数の動作ユニットの少なくとも１つのための責任負担を決定するステップ」について，明細書の第【０００８】段落には「責任リスクドライバのセットが，動作ユニットの責任エクスポージャをパラメータ化するコントロールユニットであるコントローラのドライバ選択手段により選択され，動作ユニットの責任エクスポージャ信号が，測定デバイスにより選択された測定パラメータの測定に基づきコントロールユニットであるコントローラにより生成され」との記載があるものの，ここでは単にコントローラの「ドライバ選択手段」により選択されることが特定されているだけであって，コンピュータによる情報処理として，具体的にどのような情報処理により，また，選択基準により，複数の責任リスクドライバのサブセットを選択するものであるのかが全く記載がなく実施することができない。 
　また，上記「前記選択された測定パラメータに基づき前記複数の動作ユニットの少なくとも１つのための責任負担を決定する」について，上記Ａ（３）で示したように明細書には責任負担を決定することは記載がなく実施不能であるが，上記第【０００８】段落の「動作ユニットの責任エクスポージャ信号が，測定デバイスにより選択された測定パラメータの測定に基づきコントロールユニットであるコントローラにより生成され」や，第【０１４３】段落の「動作ユニット３０の責任エクスポージャ信号は，測定デバイス２０１，．．．，２６１を用いて選択された測定パラメータの測定に基づき生成される」ことであるとしても，そもそもこの「責任エクスポージャ信号」とはどのような信号を意味するのか全く不明であるし，また，当該信号をコンピュータによる情報処理として，選択された測定パラメータの測定に基づき具体的にどのような情報処理により生成するのかについては全く記載がなく実施できない。 
（６）請求項１の「前記決定された責任負担の変化に基づき前記責任リスクドライバを変更するステップ」について，上記Ａ（４）で示したように明細書には責任負担の変化に基づき前記責任リスクドライバを変更することは記載がなく実施不能であるが，明細書の第【０００８】段落の「前記ドライバ選択手段が，定期的な時間レスポンスにより前記測定された責任エクスポージャ信号に関して前記責任リスクドライバを変更する前記責任リスクドライバのセットを動的に適応化し」や第【０１４３】段落の「ドライバ選択手段１５は，定期的な時間レスポンスによって測定された責任エクスポージャ信号に関する責任リスクドライバ３１１〜３１３を変更する責任リスクドライバ３１１〜３１３のセット１６を動的に適応化し」のことであるとしても，ここでいう「責任リスクドライバのセットを動的に適応化し」の技術的な意味が不明であるし，また，コンピュータによる情報処理として，動的に適応化する処理を具体的にどのように実現するものであるのかが全く記載がなく不明であり実施できない。 
　また，そもそも「責任負担の変化」がなぜ発生するのか，また，該「責任負担」，「測定パラメータ」と「責任リスクドライバ」の関係が不明である。 
（７）請求項１の「前記変更された責任リスクドライバに基づき，前記複数の動作ユニットの少なくとも１つと損失決定ユニットとの間のインタラクションを調整するステップ」について，上記Ａ（５）で示したように明細書には変更された責任リスクドライバに基づきインタラクションを調整することは記載がなく実施不能であるが，明細書の第【０００８】段落の「定期的な時間レスポンスにより前記測定された責任エクスポージャ信号に関して前記責任リスクドライバを変更する前記責任リスクドライバのセットを動的に適応化し，前記損失決定ユニットと前記動作ユニットとの間の責任リスクにより駆動されるやりとりが，前記適応化された責任エクスポージャ信号に基づき調整される」，また，第【０１４３】段落の「適応化された責任エクスポージャ信号に基づき，損失決定ユニット４０と動作ユニット３０との間の責任リスクにより駆動されるやりとりを調整する手段を有する」ことであるとしても，そもそも損失決定ユニット４０と動作ユニット３０との間の責任リスクにより駆動されるやりとり自体がどのようなものであるのかが全く不明であるし，また，コンピュータによる情報処理として，責任エクスポージャ信号に基づき具体的にどのような処理により調整を行うものであるのかが全く記載がなく不明であり実施できない。 
　また，上記「損失決定ユニット」について，明細書の第【００１７】段落には「損失決定ユニット４０は，何れかのタイプの損害リカバリモジュール及び／又は自動修復ノードを有し，特に損失を補償するための電子会計，課金及び他の取引のための適切な手段を有する自動保険ユニットとして実現可能である。損害リカバリモジュールはまた，動作ユニット３０により引き起こされた損失を有する損失ユニット２０〜２６に電子的に割り当てられる金銭ベースの損害補償を有することが可能である。損失決定ユニット４０はまた，損失のケースにおいて損失ユニット２０，．．．，２６の動作を維持し，損失をリカバリするための自動的又は半自動的システムを有する専用の修復ノードを有することが可能である。」と記載されているものの，「損失ユニット」は上記（３）で示したようにデバイス，システム又は人間であり，リカバリや金銭ベースの損害補償を行うユニットであると思われるが，「動作ユニット」との関係が不明であり，これらの間のインタラクションとはどのような情報のやり取りを意味するのかが不明であり，また，調整も不明であり実施できない。 
　　
・・・（省略）・・・ 　 
　　
 　よって，この出願の発明の詳細な説明は，当業者が請求項１−１２に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。 
 　　
Ｃ　この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。 
　 
 　　　　　　　　　　　　　　　　　記 
・・・（省略）・・・
　　 
 　よって，請求項１−１２に係る発明は明確でない。 
　　
Ｄ　この出願の請求項１−１２に係る発明は，下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないので，特許を受けることができない。 
 　 
 　　　　　　　　　　　　　　　　　記
・・・（省略）・・・」
   　
第３　請求人の対応
１．平成２８年８月１７日付け手続補正書の概要
　上記当審拒絶理由に対し，請求人は，平成２８年８月１７日付けで，以下の手続補正を行う手続補正書を提出した。
　なお，当該手続補正は特許請求の範囲のみを対象としたものである。
「【請求項１】
　複数の動作ユニットに関する個別のリスクについて将来の損失に関する頻度及び損失分布を予想する方法であって，前記複数の動作ユニットのそれぞれは少なくとも１つの測定可能な責任負担を有し，
当該方法は，
　ハードウェア制御ユニットコントローラが，損失単位に割り当てられた測定装置によって送信された測定パラメータ及び測定可能パラメータの一部を動的に選択し，前記損失単位の少なくとも１つに損失が生じると，前記測定装置が，複数の責任リスクドライバの少なくとも１つの動的処理及び静的特性の少なくとも１つをキャプチャする前記測定パラメータ及び前記測定可能パラメータを動的にスキャンするステップと
　前記ハードウェア制御ユニットコントローラが，前記測定パラメータ及び前記測定可能パラメータの一部を複数の責任リスクドライバの少なくとも１つに動的に割り当てるステップと，
　前記ハードウェア制御ユニットコントローラのドライバセレクタが，前記複数の動作ユニットの少なくとも１つについて前記測定可能な責任負担をパラメータ化した前記複数の責任リスクドライバのセットを選択し，前記ハードウェア制御ユニットコントローラが，前記選択された測定パラメータ及び測定可能パラメータのサブセットに基づき前記複数の動作ユニットの少なくとも１つのための責任負担信号を生成するステップと，
　前記ドライバセレクタが，前記生成された責任負担信号の定期的な変化に基づき前記責任リスクドライバを変更することによって，前記責任リスクドライバのセットを動的に適応化するステップと，
　前記ハードウェア制御ユニットコントローラが，前記適応化された責任リスクドライバのセットに基づき，前記複数の動作ユニットの少なくとも１つと損失決定ユニットとの間の責任リスクにより起動されるインタラクションを自動調整するステップと，
を有する方法。
   　
【請求項２】〜【請求項１２】（略）」
　　
２．平成２８年８月１７日付け意見書の概要
　上記当審拒絶理由に対し，請求人は，平成２８年７月１７日付けで，以下の意見書（以下「意見書」という。）を提出した。その概要は以下のとおりである。
「４．理由Ａ（第３６条第６項第１号），理由Ｂ（第３６条第４項第１号）及び理由Ｃ（第３６条第６項第２号）に対して
（１）補正後の請求項１〜１２に係る発明は，当初明細書（例えば，［００１７］，［００２０］，［００２３］など）に記載され，これに基づき実施可能であり，また明確であると考えます。
（２）「責任負担」について，損失は損失単位において発生し，測定パラメータをキャプチャすることによって物理的に測定されます。各測定パラメータはコントロールユニットによって正しい責任リスクドライバに割り当てられます。従って，「責任負担」の負担の種類は，測定結果に基づきシステムが自らの動作を自己適応化する測定可能な物理的パラメータが存在することを意味します。
（３）「割り当てる」と「選択する」との相違は当業者に明らかであります。「割り当てる」は，あるアイテムを選択し，選択したアイテムを互いにリンク付けすることを含み，すなわち，新たな測定パラメータを選択し，それをリスクドライバにリンク付けることを意味します。
（４）補正後の請求項１の「前記ハードウェア制御ユニットコントローラのドライバセレクタが，前記複数の動作ユニットの少なくとも１つについて前記測定可能な責任負担をパラメータ化した前記複数の責任リスクドライバのセットを選択し，前記ハードウェア制御ユニットコントローラが，前記選択された測定パラメータ及び測定可能パラメータのサブセットに基づき前記複数の動作ユニットの少なくとも１つのための責任負担信号を生成する」特徴は明確であると考えます。
（５）その他のご指摘を受けた各記載についても，補正後の請求項１〜１２に係る発明は，当初明細書に記載され，これに基づき実施可能であり，また明確であると考えます。」
　　
第４　当審の判断
　そこで，上記当審拒絶理由で示した拒絶の理由が妥当であるか，特に上記手続補正により補正された請求項１について，本願の発明の詳細な説明に，当業者が請求項１に係る発明を実施することができる程度に明確かつ十分に記載されているかについて以下に検討する。
　　
１．請求項１は「複数の動作ユニットに関する個別のリスクについて将来の損失に関する頻度及び損失分布を予想する方法」であって，ここで特定される各ステップは「ハードウェア制御ユニットコントローラ」の動作により実現されるものである。
　そして，この「ハードウェア制御ユニットコントローラ」は，明細書の第【００１８】段落に「コントロールユニットであるコントローラ１０は，１以上のデータ処理ユニット，ディスプレイ，及びキーボード及び／又はコンピュータマウス又は他のポインティング装置などの他の動作要素を有することが可能である。」と記載されているように実質的にコンピュータであることから，ここで特定される各ステップについて，コンピュータによる情報処理として実施することができる程度に明確かつ十分に記載されているかについて検討する。
２．請求項１における「複数の動作ユニットに関する個別のリスクについて将来の損失に関する頻度及び損失分布を予想する方法であって，前記複数の動作ユニットのそれぞれは少なくとも１つの測定可能な責任負担を有し」との事項について検討する。
　ここで特定される「動作ユニット」は，明細書の第【００１７】段落に「動作ユニット３０は，例えば，デバイスコントローラ，バルブ，ポジショナー，スイッチ，送信機（温度，圧力及びフローレートセンサなど）又は他の何れかの技術的装置など，すべてのタイプの動作又はフィールド装置から構成可能である。・・・通常，動作ユニット３０は，ユーザ又は企業に割り当てられるか，又は少なくともユーザ又は企業を表す。」と記載されており，なんらかの装置であることは理解できる。
　しかしながら，「複数の動作ユニットのそれぞれは少なくとも１つの測定可能な責任負担を有し」について，例えば明細書の第【００１７】段落には「独立して実行される責任リスク要因３１１〜３１３を用いた少なくとも１つの測定可能な責任エクスポージャ３１を有する複数の動作ユニット３０」と記載されているが，そもそも測定可能な「責任負担」や「責任エクスポージャ３１」が，コンピュータにより処理可能な情報として具体的にどのようなデータ構造を有する情報であるのか等が全く記載されておらず，依然として不明であり実施できない。 
３．請求項１における「ハードウェア制御ユニットコントローラが，損失単位に割り当てられた測定装置によって送信された測定パラメータ及び測定可能パラメータの一部を動的に選択し，前記損失単位の少なくとも１つに損失が生じると，前記測定装置が，複数の責任リスクドライバの少なくとも１つの動的処理及び静的特性の少なくとも１つをキャプチャする前記測定パラメータ及び前記測定可能パラメータを動的にスキャンするステップ」との事項について検討する。
（１）「損失単位に割り当てられた測定装置によって送信された測定パラメータ及び測定可能パラメータの一部を動的に選択し」との事項について，この「損失単位」は，明細書の第【０００８】段落に「損失ユニットは，動作ユニットによるアクション又はインタラクションに晒される，すなわち，動作ユニットによる責任問題を受けるリスクに晒される何れかのタイプのデバイス，システム又は人間とすることができる。」と記載されており，リスクに晒される「デバイス，システム又は人間」であるとは理解できる。
　また，「測定装置」は，明細書の第【００１７】段落に「測定装置２０１，．．．，２６１は，特にすべてのタイプのセンサ及びデータキャプチャリング又はフィルタリング装置である，すべてのタイプの物理的又は解析的測定装置から構成可能である。」と記載されており，当該「測定装置」は「損失単位に割り当てられた」ものとしているが，具体的に「デバイス，システム又は人間」にどのように割り当てるというものであるのかが記載がなく実施できない。
（２）また，明細書の第【０００８】段落には「損失ユニットにおいて損失が発生した場合，測定パラメータが測定され，前記コントロールユニットであるコントローラに送信され，前記責任リスクドライバに動的に割り当てられ」と記載され，また，第【００１７】段落にも「損失ユニット２０〜２６において損失が発生した場合，測定パラメータが測定され，制御ユニットであるコントローラ１０に送信され，責任リスク要因３１１〜３１３に動的に割り当てられる。」と記載されており，ここでは測定パラメータが測定装置によって送信されることの記載はあるものの，「ハードウェア制御ユニットコントローラ」による処理として，具体的に「測定パラメータ及び測定可能パラメータの一部を動的に選択し」をどのように実現するものであるのかが全く記載されておらず，実施できない。
（３）「前記損失単位の少なくとも１つに損失が生じると，前記測定装置が，複数の責任リスクドライバの少なくとも１つの動的処理及び静的特性の少なくとも１つをキャプチャする前記測定パラメータ及び前記測定可能パラメータを動的にスキャンする」との事項について，この「責任リスクドライバ」は，例えば明細書の第【００２０】段落に「少なくとも１つの測定可能な責任エクスポージャ３１が，複数の動作ユニット３０のそれぞれに割り当てられる。各責任エクスポージャ３１は，責任リスクドライバ３１１〜３１３を用いて表すことが可能である。・・・責任リスクドライバ３１１〜３１３は，コントロールユニットであるコントローラ１０の信号生成と電子的にやりとりするハードウェア及び／又はソフトウェアベースの機能モジュールである。」との記載があり，また，第【００４７】段落には，
「　　　【表４】
・・・」と、また，第【００８０】段落には，
「　【数２５】
との式に基づく。・・・」との記載があるものの，具体的に該「責任リスクドライバ」がどのような動作を行うのか，インプット及びアウトプットされる情報は具体的にどのような情報であるのか，「測定装置」とどのような関係であるのか等が不明である。
　そして，「測定装置」が「複数の責任リスクドライバの少なくとも１つの動的処理及び静的特性の少なくとも１つをキャプチャする前記測定パラメータ及び前記測定可能パラメータ」を「動的にスキャンする」とは具体的にどのような処理を動的に行うことであるのかが不明であり実施できない。
４．請求項１における「前記ハードウェア制御ユニットコントローラが，前記測定パラメータ及び前記測定可能パラメータの一部を複数の責任リスクドライバの少なくとも１つに動的に割り当てるステップ」との事項について検討する。
　明細書の第【０００８】段落には「損失ユニットにおいて損失が発生した場合，測定パラメータが測定され，前記コントロールユニットであるコントローラに送信され，前記責任リスクドライバに動的に割り当てられ」と記載され，また，第【００１７】段落にも「損失ユニット２０〜２６において損失が発生した場合，測定パラメータが測定され，制御ユニットであるコントローラ１０に送信され，責任リスク要因３１１〜３１３に動的に割り当てられる。」との記載があるものの，「ハードウェア制御ユニットコントローラ」による情報処理として，具体的に「測定パラメータ」と「責任リスクドライバ」とのどのような関係に基づいて，どのような処理により動的に割り当てるのかが不明であり実施できない。
５．請求項１における「前記ハードウェア制御ユニットコントローラのドライバセレクタが，前記複数の動作ユニットの少なくとも１つについて前記測定可能な責任負担をパラメータ化した前記複数の責任リスクドライバのセットを選択し，前記ハードウェア制御ユニットコントローラが，前記選択された測定パラメータ及び測定可能パラメータのサブセットに基づき前記複数の動作ユニットの少なくとも１つのための責任負担信号を生成するステップ」との事項について検討する。
（１）「ドライバセレクタ」について，明細書の第【０００８】段落には「責任リスクドライバのセットが，動作ユニットの責任エクスポージャをパラメータ化するコントロールユニットであるコントローラのドライバ選択手段により選択され，動作ユニットの責任エクスポージャ信号が，測定デバイスにより選択された測定パラメータの測定に基づきコントロールユニットであるコントローラにより生成され」との記載があるものの，ここでは単にコントローラの「ドライバ選択手段」により選択されることが特定されているだけであって，コンピュータによる情報処理として，具体的にどのような情報処理により，また，どのような選択基準により，複数の責任リスクドライバのセットを選択するものであるのかが全く記載がなく実施することができない。 
（２）また，「前記ハードウェア制御ユニットコントローラが，前記選択された測定パラメータ及び測定可能パラメータのサブセットに基づき前記複数の動作ユニットの少なくとも１つのための責任負担信号を生成する」との事項について，明細書の第【０００８】段落には「動作ユニットの責任エクスポージャ信号が，測定デバイスにより選択された測定パラメータの測定に基づきコントロールユニットであるコントローラにより生成され」と，また，第【０１４３】段落には「動作ユニット３０の責任エクスポージャ信号は，測定デバイス２０１，．．．，２６１を用いて選択された測定パラメータの測定に基づき生成される」と記載されているものの，そもそもこの「責任負担信号」とはどのような意味を持つ「信号」であるのか全く不明であるし，また，ここでは単に生成するとしか記載されておらず，当該信号をコンピュータによる情報処理として，選択された測定パラメータ及び測定可能パラメータのサブセットに基づき具体的にどのような情報処理により生成するのかについては全く記載がなく実施できない。 
６．請求項１における「前記ドライバセレクタが，前記生成された責任負担信号の定期的な変化に基づき前記責任リスクドライバを変更することによって，前記責任リスクドライバのセットを動的に適応化するステップ」との事項について検討する。
　上記５．で検討したように，そもそも「責任負担信号」自体がどのような意味を持つ信号であるのか，具体的にどのように生成されるものであるのかが全く記載されておらず不明であり，ここでいう「定期的な変化」が持つ意味も全く不明である。
　また，「責任リスクドライバを変更する」ことについては，明細書の第【０００８】段落に「前記ドライバ選択手段が，定期的な時間レスポンスにより前記測定された責任エクスポージャ信号に関して前記責任リスクドライバを変更する前記責任リスクドライバのセットを動的に適応化し」と，また，第【０１４３】段落に「ドライバ選択手段１５は，定期的な時間レスポンスによって測定された責任エクスポージャ信号に関する責任リスクドライバ３１１〜３１３を変更する責任リスクドライバ３１１〜３１３のセット１６を動的に適応化し」との記載があるものの，上記したように「責任負担信号の定期的な変化」がどのような意味を持つのかすら不明であり，また，コンピュータによる情報処理として，当該「責任負担信号の定期的な変化」に基づいて，具体的にどのような処理により「責任リスクドライバを変更することによって，前記責任リスクドライバのセットを動的に適応化する」という処理を実現しているのかが全く記載がなく不明であり実施できない。
７．請求項１における「前記ハードウェア制御ユニットコントローラが，前記適応化された責任リスクドライバのセットに基づき，前記複数の動作ユニットの少なくとも１つと損失決定ユニットとの間の責任リスクにより起動されるインタラクションを自動調整するステップ」との事項について検討する。
　この「損失決定ユニット」について，明細書の第【００１７】段落には「損失決定ユニット４０は，何れかのタイプの損害リカバリモジュール及び／又は自動修復ノードを有し，特に損失を補償するための電子会計，課金及び他の取引のための適切な手段を有する自動保険ユニットとして実現可能である。損害リカバリモジュールはまた，動作ユニット３０により引き起こされた損失を有する損失ユニット２０〜２６に電子的に割り当てられる金銭ベースの損害補償を有することが可能である。損失決定ユニット４０はまた，損失のケースにおいて損失ユニット２０，．．．，２６の動作を維持し，損失をリカバリするための自動的又は半自動的システムを有する専用の修復ノードを有することが可能である。」と記載されており，なんらかのコンピュータシステムと考えられる。
　そして，明細書の第【０００８】段落には「定期的な時間レスポンスにより前記測定された責任エクスポージャ信号に関して前記責任リスクドライバを変更する前記責任リスクドライバのセットを動的に適応化し，前記損失決定ユニットと前記動作ユニットとの間の責任リスクにより駆動されるやりとりが，前記適応化された責任エクスポージャ信号に基づき調整される」，また，第【０１４３】段落には「適応化された責任エクスポージャ信号に基づき，損失決定ユニット４０と動作ユニット３０との間の責任リスクにより駆動されるやりとりを調整する手段を有する」と記載されているものの，そもそも「動作ユニットの少なくとも１つ」と「損失決定ユニット」との間の「責任リスクにより起動されるインタラクション」自体が具体的にどのような情報のやり取りを意味するものであるのか，その具体的な内容や情報自体がが全く記載されておらず不明であり，さらに「ハードウェア制御ユニットコントローラ」が具体的にどのような処理により「インタラクションを自動調整する」ものであるのかも全く記載がなく不明であり実施できない。
８．以上の１．〜７．で検討したとおり，本願の発明の詳細な説明は，当業者が請求項１に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえないものである。
　　
第５　請求人の主張について
　請求人は，上記意見書において，「（１）補正後の請求項１〜１２に係る発明は，当初明細書（例えば，［００１７］，［００２０］，［００２３］など）に記載され，これに基づき実施可能であり，また明確であると考えます。」と主張している。
　しかしながら，上記「第４　当審の判断」において，請求項１に係る発明の各発明特定事項について，明細書の第【００１７】段落及び第【００２０】段落等の記載を摘記した上で，実施することができる程度に明確かつ十分に記載されているとはいえないことを示した。
　また，請求人が主張する第【００２３】段落には「本発明のシステムでは，責任リスクドライバ構成はシナリオに基づく。損失シナリオは，機能構成を形成するため，責任リスクドライバ３１１〜３１３を接続するコントロールユニットであるコントローラ１０のシステム変数である。以下において，上述された実施例の変形のコントロールユニットであるコントローラ１０のコンポーネント間の関係と損失シナリオとが確立される。シナリオは，特定のセットアップであり，イベント又は発生系列内で流れる。従って，シナリオ又はシナリオの記述データ及び機能は，“何が損失を生じさせるか”及び“何が潜在的な損失の効果となるか”という質問に対する回答を，“それはどこで生じうるか”及び“誰が影響を受けうるか”という質問に対する回答と共に有する。時間の大きさは，コントロールユニットであるコントローラ１０において明示的に構成される。シナリオは，災害，リスク対象／活動，損失機構，影響を受ける主体のタイプ，及び位置のカテゴリによって特定されるエンティティとしてみなすことができる。これらのシナリオは潜在的な損失のクラスであり，個別の損失はそれらのインスタンスである。シナリオを生成する技術的な目的は，少なくとも３つある。すなわち，（１）シナリオが，リスク展望の直感的な解析を可能にする，（２）シナリオがリスクをリスクドライバが独立して動作するコンポーネントに分解することを可能にする，及び（３）シナリオがリスクの累積値の推定を可能にするイベントセットに基づく単一の損失セットのシミュレーションを可能にする。シナリオは，以下のカテゴリにより特定可能である。（ｉ）災害：潜在的な損失の原因の一部，（ｉｉ）リスク活動又はリスク対象：潜在的な損失の原因の一部，（ｉｉｉ）シナリオクラス（損失機構）：潜在的な損失の効果である。さらに，以下のカテゴリが，リスクをリスクドライバ３１１〜３１３が独立して動作するコントロールユニットのコントローラ１０のシステムコンポーネントに分解するのに妥当である。すなわち，（ｉｖ）第三者の責任：損失決定ユニット４０により規定される（製品責任又は企業総合責任），（ｖ）潜在的な損失の場所：製品責任のケースでは国，企業総合責任のケースでは製品が販売された市場，製造場所である。本実施例の変形では，“未知”又は“汎用的”というパラメータ値は，コントロールユニットであるコントローラ１０の上述されたコンポーネントによって受け入れ可能であるだけでなく，各カテゴリの重要な価値となりうる。例えば，影響を受けた損失ユニット２０〜２６又は動作ユニット３０の各タイプについて関連性のないすべての高頻度／低重大性の損の原因となる背景シナリオが存在する。背景シナリオは，未知の災害，未知のリスク活動又は対象，未知の機構であるが，既知のタイプの影響を受けた主体によって特定される。本実施例の変形では，損失シナリオは正規化されず，シナリオ生成手段１３１の正規化された表現から生成される。以降の金銭的な損失は，暗黙的には，例えば，身体の傷害に従う金銭的な損失など，コントロールユニットであるコントローラ１０の各コンポーネントの一部である。潜在的な損失の場所は保険対象の損失決定ユニット４０の位置と異なってもよいことは明らかであり，第三者の永続的な位置は，特定の実施例の変形に基づく。一例として，特定の実施例の変形について，製品責任について輸出市場の各場所と，企業総合責任についての製造場所が想定できる。さらに，損失の頻度は，イベントの頻度とイベント毎の損失数の分布とから生成される必要がある可能性がある。コントロールユニットであるコントローラ１０の構成は，システムの動作においてこのような仮定を容易に組み込むことを可能にする。」と記載されているものの，ここには請求項１に係る発明の各発明特定事項について，つまり上記「第４　当審の判断」において検討した「ハードウェア制御ユニットコントローラ」による具体的な情報処理が，実施することができる程度に明確かつ十分に記載されているわけではない。
　したがって，請求人の主張は失当である。
　　
第６　むすび
　以上のとおり，本願の明細書の発明の詳細な説明は，当業者が請求項１に係る発明を実施することができる程度に明確かつ十分に記載されているとはいえないものであり，特許法第３６条第４項第１号に規定する要件を満たしておらず，特許を受けることが出来ないものであるから，その余の請求項について検討するまでもなく，本願は拒絶すべきものである。
　　
　よって，結論のとおり審決する。