【事件の表示】
　平成　９年特許願第２５７９１０号「リアルタイムＯＳ上のタスク実行制御方式」拒絶査定に対する審判事件〔平成１１年　３月３０日出願公開、特開平１１−　８５５３９、請求項の数（１）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年９月５日の出願であって、平成１２年３月１４日付けで拒絶の査定がされ、同年４月１３日に拒絶の査定に対する審判請求がされるとともに、同年５月１５日付けで手続補正がされた。 前記補正は、補正前の請求項２の「・・・リアルタイムＯＳ。」を、拒絶の理由に示す事項についてするものにあたる指摘に基づいて、「・・・、リアルタイムＯＳ上のタスク実行制御方式。」と補正するものであり、明りょうでない記載の釈明を目的とするものである。
　したがって、本願の請求項１に係る発明は、平成１２年２月１４日付け及び前記平成１２年５月１５日付けの各手続補正書による手続補正からみて、補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるもの（以下、「本願発明」という。）と認める。
「【請求項１】　リアルタイムＯＳにおいて、
　ソフトウェアの処理単位を構成するタスクに関し、ソフトウェアの設計段階で要求仕様及びシステム分析結果に基づいて作成されたタスクの生成、削除、起動、終了のタイミング、タスクの実行優先度、タスクの起動形態を含むタスク実行状態からなるタスク実行パラメータを、処理の状態毎にひとまとめにしたタスク実行パラメータセットを格納するタスク実行パラメータセット格納手段と、
　前記タスク実行パラメータセット格納手段から処理の状態に応じて必要な前記タスク実行パラメータセットを読み出すタスク実行パラメータセット切り替え手段と、
　前記タスク実行パラメータセット切り替え手段から渡された前記タスク実行パラメータセットを用いて複数のタスクの実行パラメータを一括して切り換えることにより、各タスクの実行を制御するタスク実行制御手段とを備え、
　処理を構成するタスクの実行状態の変化を検出し、タスク実行状態の変化に応じて前記タスク実行パラメータセット切り替え手段に対してタスク実行パラメータセット切り替え指示を行なう切り替え指示発生手段と、
　前記タスク実行パラメータセット切り替え指示に必要なタスクの実行状態の変化を示す事象の定義情報と、タスクの実行状態の変化に対応するタスク実行パラメータセットの情報を格納する切り換え情報格納手段を備えることを特徴とする、リアルタイムＯＳ上のタスク実行制御方式。」
 
２．引用例
［引用例１］　原査定の拒絶の理由に引用された本願出願前頒布された刊行物である特開昭６０−２５３３９７号公報には、第４図に示された制御プログラム（ＯＳ）がサービス（タスク）プログラム群（ＡＰ1〜ＡＰn）を第５図に示された処理フローにより起動して実行する制御方式の発明（以下、引用例１の発明、という。）について次のように記載されている。
（１）「第４図に示す如く、プロセッサ２１のソフトウェア構成は、サービスを制御する制御プログラムＯＳと、サービス（タスク）を記述したサービス（タスク）プログラム群ＡＰより構成され、サービスプログラムＡＰは制御プログラムＯＳより起動される。」（第４頁右上欄３行〜１１行）
（２）「第１図は第２図の高機能端末２において行なわれる呼処理のための一実施例ブロック図であり、・・・２２ａはタスク決定テーブルであり、・・・呼の状態、入力イベント種別及びサービスカウンタの内容により実行すべきタスクを決定するものであり、呼の状態テーブル２２０と、イベント種別テーブル２２１と、サービスカウンタテーブル２２２とを有しており、イベント種別テーブル２２１には各呼の状態に対応するイベント種別が格納され、サービスカウンタテーブル２２２にはイベント種別テーブル２２１の各イベント種別に対応して実行するタスク名が優先度順に格納されており、呼の状態テーブル２２０には各呼の状態に対応するイベント種別が格納されたイベント種別テーブル２２１の先頭アドレスが格納されている。」（第３頁右下欄下３行〜第４頁左上欄１４行）
（３）「呼の状態と入力イベント種別に対応したタスクを実行する呼処理タスク制御方式において、該呼の状態を格納する状態記憶部と、該入力イベント種別を格納するイベント格納部と、該呼の状態と該入力イベント種別とに応じて実行すべきタスクを決定するタスク決定テーブルとを有し、前記タスク決定テーブルに前記実行すべきタスクに関する優先情報および内容を前もって登録しておき、個々の呼の状態、前記入力イベント格納部から読み出されたイベントおよび前記タスクに関する優先情報をもとに前記タスク決定テーブルから決定されたタスクに基づき所望のタスクを逐次実行する呼処理タスク制御方式。」（特許請求の範囲から抜粋）
（４）第５図処理フロー図に従って制御プログラムの動作が説明され「第５図においてＡは制御プログラム、Ｂはサービスプログラムに対応する。・・・このようにして、all状態、idle状態、busy状態、個々の呼の状態で入力イベント種別αに対しサービスが決定できると判定されると、次の様にして個々のサービスプログラムが起動される。
　この例では、逐次起動を可能とするため、サービスカウンタテーブル２２２には当該呼の状態、入力イベント種別に対し複数タスク名が優先順位順に格納されており、これはサービスカウンタ２２ｄのカウント値によって引き出される。即ち、サービスカウンタ２２ｄの初期値は”０”としておき、先ずテーブル２２２の第１順位のタスク名が読み出され、当該タスクに対応するサービスプログラムが選択され、起動処理が行なわれる。起動処理によって第５図Ｂ列のサービスプログラムの実行に移行し、点線によって省略した如く実行される。そして実行の結果が正常終了であるか否かを判断し、正常終了（ＹＥＳ）であれば、一連のサービスが実行されたのであるから、サービスカウンタ、ＧＳＴカウンタを０にリセットし、終了する。正常終了でなければ（ＮＯ）、次の優先順位のサービスを実行すべく、サービスカウンタ２１ｅの内容を+１インクリメントし、Ｂ列のサービスプログラムの起動要因となった入力イベントαを擬似的に発行して、図示点線の如く、Ａ列の制御プログラムの始点に戻して再起動を行なう。この際、サービスカウンタの内容は”０”から”１”・・・順次+１インクリメントしているため、優先順位の高いサービスから処理される。
例えば、busy状態で着信要求の場合に転送サービスと蓄積サービスとが順に登録されているとすると、先ず転送サービスが実行され、転送サービスが正常終了しないと蓄積サービスが実行される。」（第４頁右下欄下２行〜第６頁左上欄下２行）
（４）　第６図、第７図には、発信側、着信側それぞれの基本接続サービス 状態遷移図が示されている。
　
［引用例２］
　同じく原査定の拒絶の理由に引用された本願出願前頒布された刊行物である特開平５−１４３３０１号公報には、ソフトウェア開発支援システムの発明に関して次の記載がされている。
（あ）「【０００３】　しかしながら、要求分析工程ではデータフロー図の他に、状態遷移図、プロセス起動表、コントロールフロー図、データ辞書等の様々な情報を用いてソフトウェアに対する処理要求、制約条件、データと処理との関係等を複数の観点から分析している。したがって、単にデータフロー図の情報だけを設計工程の情報へ変換するだけでは十分かつ効率的な支援がなされているとは言えず、要求分析工程と設計工程との間における溝は完全には埋め尽くせなかった。
【０００４】【発明が解決しようとする課題】
　このように従来にあっては、ソフトウェア要求分析工程で得た情報の多くを人間系でソフトウェア設計情報に反映させて行かねばならなかった。こうした作業は多大な工数を要し、ソフトウェア開発の効率を大幅に劣化させる要因となっていた。
【０００５】　本発明はこのような課題を解決するためのもので、ソフトウェア要求分析工程で得た要求分析情報のほとんどを、ソフトウェア設計工程で直接利用可能な形式の設計情報に効率良く変換することができ、これによってソフトウェア開発を有力に支援することのできるソフトウェア開発支援システムの提供を目的としている。
【０００７】　【作用】
　本発明のソフトウェア開発支援システムでは、まず観点別一覧情報作成手段にて、ソフトウェア要求分析支援ツールで得た要求分析情報を基に、要求されている処理機能を複数の観点から示した要求処理一覧、動作制約一覧、状態制約一覧およびデータ制約一覧をそれぞれ作成する。続いて設計情報生成手段は、観点別一覧情報作成手段にて作成された各一覧情報から所定の変換規則に従って、ソフトウェア設計工程にて解釈可能な設計情報を生成し、この設計情報を設計情報格納手段に格納する。
【０００８】
　したがって、この発明により、ソフトウェア要求分析工程で得た様々な種類の要求分析情報（例えばデータフロー図、コントロールフロー図、状態遷移図、プロセス起動表、データ辞書等）を次のソフトウェア設計工程で直接利用可能な形式の設計情報に効率良く変換することができ、これによってソフトウェア開発を有力に支援することができるようになる。」
　
（い）「【００１８】
　さらに観点別一覧情報作成部４は、状態遷移図およびプロセス起動表等の情報に基づき、システムのある状態において起動される（制約を受ける）処理は何か、さらにそれらの処理がどんな順序で起動されるかを例えば“状態１：処理１、処理２、処理３“の形式でまとめた状態制約一覧（ｈ）を作成する。つまりこれは状態１が処理１、処理２、処理３の順序で起動されることを表す。」
（う）ソフトウェア要求分析支援ツール群で得た要求分析情報の例が図２（ｃ）状態遷移図と（ｄ）プロセス起動表に示され、図３（ｈ）には前記のようにして作成された状態制約一覧が示されている。
　
　前記（あ）〜（う）の記載、及び、特に図２（ｃ）（ｄ）、図３（ｈ）を参照すると、プロセス起動表には、行方向に処理１〜処理３、列方向に状態１、２、３・・・をとり、配列中に数値０〜３が示されていて、この配列中の数値０〜３は、システムのある状態において起動される処理はどれか、そしてそれらの処理がどんな順序で起動されるかを決めるための制御に係るパラメータを示すものであると解すことができ、且つ、プロセス起動表の１つの行についてみると、１つの状態において、処理１、処理２、処理３・・・の起動の順序を表していると解されるので、この点を踏まえると、前記図２（ｄ）プロセス起動表、これと関連する図３（ｈ）状態制約一覧には、状態における複数の処理（タスク）の起動制御のパラメータが記載されているともに、行方向をみれば、１つの状態毎にひとまとめにした複数処理（タスク）の実行パラメータセットとする技術が読み取れる。
　　
３．本願発明と引用例１の発明との対比
（Ａ）引用例１の発明の 制御プログラム（ＯＳ）は、タスク（サービス）がリアルタイムで起動され実行されてサービスが提供されることが要求される呼処理のＯＳであり、リアルタイム処理の実現を重視したＯＳであると言えるので、本願発明の「リアルタイムＯＳにおいて、」に相当する。
（Ｂ）引用例１の発明のタスク決定テーブル２２ａは、
（ｂ１）タスクがソフトウェアの処理単位を構成するものであり、タスク実行パラメータがソフトウェアの設計段階で要求仕様及びシステム分析結果に基づいて作成されるものであることが通常知られた技術的事項であり、
（ｂ２）（４）の記載を参照すると、サービスカウンタテーブル２２２には当該呼の状態、入力イベント種別に対し複数タスク名が優先順位順に格納されており、これはサービスカウンタ２２ｄのカウント値によって引き出されるとあることから、タスク決定テーブル２２ａには、呼の処理の状態に対応して、タスクの実行優先順位（優先度）がタスク実行パラメータとして格納されていると解することができるので、（ａ）（ｂ）からして引用例１の発明は、本願発明の「ソフトウェアの処理単位を構成するタスクに関し、ソフトウェアの設計段階で要求仕様及びシステム分析結果に基づいて作成されたタスクの実行優先度を含むタスク実行状態からなるタスク実行パラメータを、処理の状態毎にタスク実行パラメータを格納するタスク実行パラメータ格納手段と、」の要件を備えている。
（Ｃ）引用例１の発明の制御プログラム（ＯＳ）は、（３）、（４）の記載及び第１図を参照すると、呼処理タスク制御にあたり、個々の呼の状態、前記入力イベント格納部から読み出されたイベント、及びサービスカウンタ２２ｄのカウント値（タスクに関する優先情報）によって当該優先情報のタスクをサービスカウンタテーブル２２２から引き出すことによりタスクを決定して実行し、正常終了でなければ、次の優先順位のサービスを実行すべく、サービスカウンタの内容を+１インクリメントし、Ｂ列のサービスプログラムの起動要因となった入力イベントαを擬似的に発行して、Ａ列の制御プログラムの始点に戻して再起動を行なう。制御プログラム（ＯＳ）がサービスカウンタ２２ｄのカウント値をインクリメントしながら順次に当該優先情報のタスクをサービスカウンタテーブル２２２から引き出してタスクを決定することは、タスク実行パラメータ（タスク優先情報）を切り替えているとみることができるので、本願発明の「前記タスク実行パラメータ格納手段から処理の状態に応じて必要な前記タスク実行パラメータを読み出すタスク実行パラメータ切り替え手段と、」に相当する要件を備えている。
（Ｄ）引用例１の発明の制御プログラム（ＯＳ）は、前記のようにタスク実行パラメータ（タスク優先情報）を切り替えているとみることができ、（３）の記載を参照すると、個々の呼の状態、前記入力イベント格納部から読み出されたイベントおよび前記タスクに関する優先情報をもとに前記タスク決定テーブルから決定されたタスクに基づき所望のタスクを逐次実行する呼処理タスク制御がされるので、本願発明の「前記タスク実行パラメータ切り替え手段から渡された前記タスク実行パラメータを用いてタスクの実行パラメータを切り換えることにより、各タスクの実行を制御するタスク実行制御手段とを備え、」の要件を備えている。
（Ｅ）引用例１の発明は、（４）の記載と第５図を参照すると、先ずサービスカウンタテーブル２２２の第１順位のタスク名が読み出され、当該タスクの起動処理が行なわれ、第５図Ｂ列の呼処理を構成するタスクであるサービスプログラムが実行され、実行の結果が正常終了であるか否かを判断して正常終了であれば終了し、正常終了でなければ、サービスカウンタの内容を+１インクリメントし、Ｂ列のサービスプログラムの起動要因となった入力イベントαを擬似的に発行して、Ａ列の制御プログラムの始点に戻して再起動を行なって次の優先順位のサービスを実行する。サービスプログラムの実行の結果が正常終了であるか否かを判断してサービスカウンタの内容を+１し、当該サブルーチンプログラムの起動要因となった入力イベントαを擬似的に発行することは、呼処理を構成するタスクの実行状態の変化を検出し、タスク実行状態の変化に応じてタスク実行パラメータ切り替え指示を行なうことに相当するので、引用例１の発明は、本願発明の「処理を構成するタスクの実行状態の変化を検出し、タスク実行状態の変化に応じて前記タスク実行パラメータ切り替え手段に対してタスク実行パラメータ切り替え指示を行なう切り替え指示発生手段と、」の要件を備えている。
（Ｆ）引用例１の発明は、（２）の記載及び第１図を参照すると、タスク決定テーブル２２ａには、呼の状態テーブル２２０と、イベント種別テーブル２２１と、サービスカウンタテーブル２２２とを有しており、呼の状態、入力イベント種別、及びサービスカウンタの内容により実行すべきタスクが決定されるものである。
　これらのテーブルのうち、呼の状態テーブル２２０と、イベント種別テーブル２２１に格納された情報は、実行すべきタスクを決定するための事象の定義情報に相当し、サービスカウンタテーブル２２２には複数のタスク名が優先順位順に格納されていてサービスカウンタ２２ｄのカウンタ値によって引き出されることから、タスク名と優先順位情報との情報が対応して格納されていると解され、タスクの実行状態の変化に対応するタスク実行パラメータの情報（優先順位情報）を格納するといえるので、本願発明の「前記タスク実行パラメータ切り替え指示に必要なタスクの実行状態の変化を示す事象の定義情報と、タスクの実行状態の変化に対応するタスク実行パラメータセットの情報を格納する切り換え情報格納手段を備えることを特徴とする」の要件を備えている。
（Ｇ）引用例１の発明は、呼処理タスク（サービス）制御方式であって、（Ａ）の既述を斟酌すれば、本願発明の「、リアルタイムＯＳ上のタスク実行制御方式」の要件を備えている。
　したがって、本願発明は、次の要件を備える点で引用例１の発明とは相違する。
［相違点］
（１）タスク実行パラメータとタスク実行パラメータを格納する手段が、本願発明は、タスクの生成、削除、起動、終了のタイミング、タスクの実行優先度、タスクの起動形態を含むタスク実行パラメータを、処理の状態毎にひとまとめにしたタスク実行パラメータセットであり、タスク実行パラメータセットを格納するパラメータセット格納手段であるのに対し、引用例１の発明は、タスク実行パラメータはタスクの実行優先情報（実行優先度）であり、処理の状態に対応させたタスク実行パラメータ格納手段である点。
（２）タスク実行制御手段が各タスクの実行を制御するのに、本願発明は、タスク実行パラメータセットを用いて複数のタスクの実行パラメータを一括して切り換えることにより、制御するのに対し、引用例１の発明は、そのように制御することは記載されていない点。
　
４．当審判断
（１）引用例１には、タスク実行パラメータとして優先順位を用いたタスクの制御は記載されているといえるが、タスクの生成、削除、起動、終了のタイミング、タスクの実行優先度、タスクの起動形態を含むタスク実行パラメータを、処理の状態毎にひとまとめにしたタスク実行パラメータセットとすることは示されていない。
　引用例２には、前掲引用例２で論じたように、図２（ｄ）プロセス起動表、これと関連する図３（ｈ）状態制約一覧には、状態における複数の処理（タスク）の起動制御のパラメータが記載されているともに、行方向をみれば、１つの状態毎にひとまとめにした複数処理（タスク）の実行パラメータセットとする技術が読み取れるが、複数処理（タスク）のそれぞれについてタスク実行パラメータをひとまとめにすることないしタスク実行パラメータセットを作成することは何ら記載されていない。前記図２（ｄ）プロセス起動表、これと関連する図３（ｈ）状態制約一覧は、ソフトウェア開発工程におけるソフトウェア要求分析工程で得た様々な種類の要求分析情報（例えばデータフロー図、コントロールフロー図、状態遷移図、プロセス起動表、データ辞書等）、次のソフトウェア設計工程で直接利用可能な形式の設計情報に効率良く変換するための情報であり、これを利用して最終的にソフトウェアモジュール（図４）が作成されてソフトウェア開発を有力に支援することができるとしても、タスク実行パラメータについては、具体的にどのようなタスク実行パラメータが作成されるか記載されておらず、ましてや、タスクの生成、削除、起動、終了のタイミング、タスクの実行優先度、タスクの起動形態を含むタスク実行パラメータを、処理の状態毎にひとまとめにしたタスク実行パラメータセットとすることは記載されていない。したがって、引用例１の発明において引用例２の技術を参酌したとしても、本願発明の相違点（１）の構成要件を容易になし得るとすることはできない。
（２）タスク実行制御手段が各タスクの実行を制御するのに、タスク実行パラメータセットを用いて複数のタスクの実行パラメータを一括して切り換えることにより制御することは、引用例１、引用例２には記載がなく容易になし得る理由はない。
　引用例２には、前記相違点（１）に示した点について、具体的にどのようなタスク実行パラメータが作成されるか記載されておらず、ましてや、タスクの生成、削除、起動、終了のタイミング、タスクの実行優先度、タスクの起動形態を含むタスク実行パラメータを、処理の状態毎にひとまとめにしたタスク実行パラメータセットとすることは記載されておらず、一括した切り替えについても記載されておらず、それゆえ、本願発明の相違点（２）の構成要件に係る、タスク実行パラメータセットを用いて複数のタスクの実行パラメータを一括して切り換えることにより制御することは容易になし得るとすることはできない。　
　また、相違点（１）〜（２）について、リアルタイムシステムにおける状態に応じて、タスク実行パラメータ格納手段からタスク制御パラメータを読み出してタスクを切り替えて制御する技術が本願出願前周知（例えば、前記特開平６−２４２９６９号公報には、 タスク動作切替手段７が、状態遷移制御手段４より受け取った状態とアクションテーブル６を比較し、タスクの動作を切り替えることが記載され（第３欄３４行〜３６行）、例えば、特開平８−２７２４０３号公報には、リアルタイムＯＳにける制御において、状態変化に応じて、管理パラメータデータテーブル（タスク実行パラメータを含むと解される。）を選択的に読み出して必要な機能タスクを実行する技術が記載されている（請求項１及び【0051】より抜粋））であるが、この周知技術を参酌したとしても、タスク実行パラメータセットを用いて複数のタスクの実行パラメータを一括して切り換えることを導き出せる合理的な理由はなく、相違点（１）（２）に係る構成要件を備えた本願発明を当業者が容易になし得るものとすることはできない。
　
５．むすび 
　したがって、本願発明は引用例１及び引用例２並びに本願出願前周知の事項に基いて、当業者が容易に発明をすることができたものとは認められず、特許法第２９条第２項の規定により特許を受けることができないとすることはできない。
　また、他に本願発明を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。