【事件の表示】
　平成１１年特許願第　９９３２６号「障害管理装置および方法、システム、記録媒体」拒絶査定不服審判事件〔平成１２年１０月２０日出願公開、特開２０００−２９３４１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１１年４月６日の出願であって、平成１２年１１月６日付けで拒絶の理由が通知され、平成１３年１月１５日付けで手続補正がなされた後、平成１４年４月３０日付けで拒絶の理由が通知され、同年７月４日付けで手続補正がなされ、更に平成１６年３月３１日付けで拒絶の理由が通知され、同年６月４日付けで手続補正がなされたものの、同年１０月２８日付けで拒絶査定がなされた。
　
　これに対し、平成１６年１２月２日に拒絶査定に対する審判請求がなされるとともに、同年１２月９日付けで手続補正がなされ、当審において、平成１９年７月２６日付けで平成１６年１２月９日付けの手続補正を却下する旨の決定がなされるとともに、同日付けで拒絶理由が通知され、平成１９年１０月１日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１３年１月１５日付け、平成１４年７月４日付け、平成１６年６月４日付け及び平成１９年１０月１日付けの手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
　
「ソフトウェア上に発生した各種障害に関して入力されたレポート情報を蓄積するための記憶手段と、
　上記入力されるレポート情報の障害毎にどのような手順で障害に対する対策処理をとっていくかを定義したワークフロー定義情報に基づいて対策処理の状態情報を遷移させると共に上記記憶手段に遷移状態情報を格納する状態遷移処理手段と、
　上記記憶手段の中から障害に関する情報を収集する情報収集手段と、
　上記収集した情報を基に分析・評価を行う分析・評価手段とを備え、
　上記分析・評価手段は、上記収集した障害に関する情報を経過時間毎に発生件数を累積して出力することを特徴とする障害管理装置。」
　
３．当審における拒絶理由の概要
　当審において、平成１９年７月２６日付けで通知した拒絶理由の概要は以下のとおりである。
　
「本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
 　　　　　　　　　　　　　　　　　　記
 請求項：１−１６
 引用文献：１−３
 　１．特開平７−８４７７７号公報
 　２．特開平９−１７１５２９号公報
 　３．日経コンピュータ別冊「ソフトウェア開発の最新技術」、
 　　　日経ＢＰ社、平成１０年１１月９日発行、Ｐ．２０６−２２６」
　
　
４．引用発明
（１）引用文献１
　当審の拒絶理由に引用された刊行物である特開平７−８４７７７号公報（以下、「引用文献１」という。）には、図面とともに以下の事項が記載されている。
　
Ａ．「【０００１】
【産業上の利用分野】本発明は、ソフトウェアの開発において発生したトラブルの内容をまとめ、分析し、その分析結果をソフトウェア開発現場にフィードバックしてソフトウェアの品質向上を図るためのトラブル分析支援装置に関する。」
　
Ｂ．「【００２０】
【発明が解決しようとする課題】そこで本発明は、ソフトウェアの開発中および開発後に発見されたトラブルの分析を容易化でき、その分析結果の活用に寄与できるトラブル分析支援装置を提供することを目的としている。」
　
Ｃ．「【００２４】
【実施例】以下、図面を参照しながら実施例を説明する。図１には本発明の一実施例に係るトラブル分析支援装置の概略構成が示されている。
【００２５】このトラブル分析支援装置は、大きく別けて、トラブルデータ入力・保存部１と、トラブルデータ検索・表示部２と、トラブル分析・結果表示部３と、チェックリスト更新・保存部４と、データベース５とで構成されている。
【００２６】トラブルデータ入力・保存部１は、ソフトウェアの開発中および開発後に発見されたトラブルを記述してなるトラブルシートＳから必要な情報を抜き出してデータベース５に保存するための部分であり、トラブルデータを入力するためのトラブルデータ入力部１１と、入力されたデータをデータベース５に保存するためのトラブルデータ保存部１２とから構成されている。
【００２７】トラブルデータ検索・表示部２は、あるプロジェクトのトラブルに関して、たとえば特定の原因のものだけ、あるいは特定の人が対応したトラブルだけを抜き出して観察したり、分析したりするために、保存されているトラブルの中から検索キーを使って検索するトラブルデータ検索部２１と、検索されたトラブルデータを表示するトラブルデータ表示部２２とから構成されている。
【００２８】トラブル分析・結果表示部３は、データベース５からトラブル情報を取り出し（必要があれば先に述べたトラブルデータ検索・表示部２の中のトラブルデータ検索部２１を用いて、分析対象とするトラブルデータを一部分に絞り）て、トラブルの分析を行なうトラブル分析部３１と、分析結果をデータベース５に保存する分析結果保存部３２と、分析結果を表示する分析結果表示部３３とから構成されている。
【００２９】トラブル分析部３１は、図２に示すように、トラブル発生件数を開発規模で正規化して分析を行なうトラブル発生密度分析部３１−１と、トラブルの原因によって分類して分析を行なうトラブル原因別分析部３１−２と、トラブルによって影響した品質特性（機能性、信頼性、使用性、効率性、保守性、移植性からなり、ソフトウェアが満たすべき品質の特性）で分類して分析を行なう品質特性別分析部３１−３と、対象とするソフトウェアの処理を幾つかに分類し、その処理内容毎に分析を行なう処理内容別分析部３１−４と、トラブルの影響度に対応させ分類して分析を行なうトラブル影響度別分析部３１−５とを含む各種の分析部から構成されている。」
　
Ｄ．「【００４５】・・・（中略）・・・次に，原因を入力する。ここではトラブル原因を「基本ソフトウェア」，「応用ソフトウェア」，「ハードウェア」の大きく３つに分けている。基本ソフトウェアとはＯＳ（オペレーティングシステム）などを意味する。この実施例が対象としている事務処理プログラムは応用ソフトウェアであり、ほとんどのトラブル原因は「応用ソフトウェア」にある。しかし，ごく稀に、たとえばＯＳの割込み処理がうまく機能しないなどの基本ソフトウェアに原因があったり、機械の性能が十分でないために予定していた性能が得られないなどのハードウェアに原因がある場合もあるので、このような分類としている。」
　
　上記Ａ−Ｄの記載からみて、トラブル分析支援装置が扱う「トラブル」とは、ソフトウェアの開発中及び開発後におけるソフトウェア上に発生したトラブルである。そして、上記Ｃに記載されているように、このトラブルに関して入力されるトラブルデータは、トラブル分析支援装置のデータベースに保存されるものである。
　
　上記Ｃの記載からみて、トラブルデータ検索部は、上記データベースの中から特定の条件に合うトラブルデータを抜き出すものであり、また、トラブル分析・結果表示部は、上記トラブルデータ検索部によって抜き出されたトラブルデータを基に分析を行うものであり、上記抜き出されたトラブルデータに関するトラブル発生密度分析、トラブル原因別分析等の結果を表示するものである。
　
　よって、上記Ａ−Ｄの記載事項及び関連する図面を参照すると、引用文献１には、次の発明（以下、「引用発明１」という。）が記載されていると認められる。
　
「ソフトウェア上に発生したトラブルに関して入力されたトラブルデータを保存するデータベースと、
　上記データベースの中から特定の条件に合うトラブルデータを抜き出すトラブルデータ検索部と、
　上記抜き出されたトラブルデータを基に分析を行うトラブル分析・結果表示部とを備え、
　上記トラブル分析・結果表示部は、上記抜き出されたトラブルデータに関するトラブル発生密度分析、トラブル原因別分析等の結果を表示することを特徴とするトラブル分析支援装置。」
　
（２）引用文献２
　当審の拒絶理由に引用された刊行物である特開平９−１７１５２９号公報（以下、「引用文献２」という。）には、図面とともに以下の事項が記載されている。
　
Ｅ．「【０００１】
【発明の属する技術分野】本発明は、ソフトウェア開発等の作業工程の管理を行うシステムに係り、特に、少なくともその作業者を属性にもつ複数の作業単位間の順序関係によって定義されたワークフローに関する計画の管理を行う動的計画管理装置及び動的計画管理方法に関する。」
　
Ｆ．「【０００６】ここで、「作業単位」とは、各ワークフローを構成する作業の単位であって、少なくとも作業者を属性にもつ。後述する実施の形態の「作業ステップ」に相当する。「属性」とは、前記ワークフロー・データのうち作業単位を特徴付けるデータであって、本発明では、少なくとも、その１つとして作業者を含むものである。「ワークフローの内容を特定するワークフロー・データ」とは、例えば、各作業単位の内容、各作業単位に割り当てられた作業者、各作業単位間の順序関係情報、または、各作業単位の作業状況等がある。「作業状況」とは、各担当者に割り当てられた担当作業単位が現在どのような状況にあるかを示す情報であって、例えば、着手が可能となった状況、作業中の状況、作業完了の状況、修正必要性判断中の状況、修正の状況がある。」
　
Ｇ．「【００２３】
【発明の実施の形態】本発明の実施の形態について説明する。図５には、本発明に係る実施の形態に係る機器構成ブロック図を示す。同図に示すように、本実施の形態に係る動的計画装置は、少なくとも作業者を属性にもつ作業単位間の順序関係によって定義されたワークフローについて、当該ワークフローの内容を特定するワークフロー・データの編集又は蓄積を行うとともに、少なくとも個人作業指示手段２２１〜２２３による作業状況の変更に基づき、各ワークフローの進捗状況を把握するワークフロー管理手段２１と、前記ワークフロー・データに基づいて、割り当てられた作業単位について担当者への指示、及び、当該担当者による作業状況の変更を行う個人作業指示手段２２１〜２２３と、ワークフローの内容を特定するワークフロー・データ等の作業データ、各ワークフロー間の依存関係及び参照関係並びにカテゴリの種類等の１つの作業計画を定めるために必要な計画データの集合からなる計画データ管理単位の複数について表示等の管理を行う計画データ拡張管理手段２３とを有するものである。」
　
Ｈ．「【００３８】続いて、前記入力・表示手段２４を介して、前記計画データ管理単位指定生成手段５９により、計画データ管理単位を指定するとともに、前記ワークフロー情報生成手段４６によって、例えば、帳票の起票等により、指定した前記計画データ管理単位に属するワークフロー情報を生成させる。・・・（中略）・・・
【００３９】図８（ａ）は、起票前の指定された計画データ管理単位に属する帳票管理表７２を示す。図８（ｂ）は、前記入力・表示手段２４の画面上に表示された帳票管理一覧表７３を示す。管理者は、入力・表示手段２４を介して、画面上で、複数の計画データ管理単位である「障害票」、「Ｑ／Ａ票」及び「仕様変更票」の中から、追加したい計画データが属する計画データ管理単位である「障害票」の選択を指示する。
【００４０】その際、管理者は、前記計画データ解釈手段３０のワークフロー情報生成手段４６等の機能を用いて、起票ボタン７４を押すことによって、障害票の起票を個人作業指示手段２２１〜２２３を介して指示する。すると、前記計画データ管理単位最新情報収集手段５８は、指定された計画データ管理単位である「障害票」に、図８（ｃ）に示すように、新たに起票された「障害票０００４」を追加したものを収集して、前記入力・表示手段２４の画面に表示させる。」
　
Ｉ．「【００４６】図１０に示すように、まず、動的計画管理装置を起動する前に、予め、ステップＳＪ１で、環境の設定を行う。・・・（中略）・・・
【００４７】・・・（中略）・・・ここで、「手順設定」とは、各ドキュメント種の編集作業の手順をプロセス・テンプレートから設定又は必要に応じてグラフィカル・プランナにより編集し、また、ドキュメントの編集を行うツール及びドキュメント管理票の設定を行うことをいい、前記作業対象物の種類指定手段４７の機能を介して設定され、前記ワークフロー雛型選択手段４８によって自動的にテンプレートが選択される。
【００４８】・・・（中略）・・・ドキュメント種領域８０ｂは、各ワークフローの内容を表すドキュメントの種類を表し、当該ドキュメント種の名前を表示又は編集を行うものであって、新規にドキュメント種を作成する場合にはここに書き込む。ドキュメント種を大きく分類するものとしてカテゴリがある。
【００４９】ここで、「カテゴリ」とは、ワークフローのもつ性質によって分類されたワークフローの種類をいい、例えば、ファイルが帳票等の作業対象である生産物の種別や、ソフトウェア開発、帳票の回覧、映画開発等に分類されたものがあり、本実施の形態では、大きくは、作業計画と帳票作成に分けられている。」
　
Ｊ．「【００６１】・・・（中略）・・・また、各作業者は、必要に応じて障害票や仕様変更票等の帳票を起票して他の作業者は管理者に回覧することができる。また、管理者は帳票管理表一覧及び帳票管理表により起票された帳票の管理を行うことができる。・・・（中略）・・・
【００６２】・・・（中略）・・・また、起票ボタン８７ｇを押下することによって、ウィンドウ８８が開かれ、帳票管理名８８ｄを設定し、起票される帳票の種類である帳票種８８ｂを設定する。計画日付領域８７ｄは帳票管理表が最初に作成された日付を表す。表示ボタン８７ｆは、指定された帳票管理表の更新又は参照を意味し、指定された帳票管理がない場合はそのユーザの管理権限をチェックした上で新規作成を行う。新規作成の場合には、表示ボタン８７ｆを押下し、図１９（ｂ）のダイアログ・ボックス８８が起動される。ドキュメント種（帳票種）がない場合には警告のメッセージを出すようにしても良い。
【００６３】・・・（中略）・・・起票ボタン８７ｇは指定された帳票管理で管理されている帳票の作成を意味し、前記ワークフロー情報生成手段４６等によって生成され、前記計画データ管理単位最新情報収集手段５８によって、指定された計画データ管理単位として収集される。」
　
　上記Ｅ、Ｇの記載からみて、動的計画管理装置は、ソフトウェア開発等の作業工程について、ワークフロー・データに基づくワークフロー管理を行うものである。
　
　ここで、上記ワークフロー・データは、上記Ｆに記載されているように、各作業単位の内容、各作業単位に割り当てられた作業者、各作業単位間の順序関係情報とともに、各作業単位の作業状況（各担当者に割り当てられた担当作業単位が現在どのような状況にあるかを示す情報）を含んでおり、ワークフロー管理手段は、上記Ｇに記載されているように、この作業状況を含むワークフロー・データを編集・蓄積するとともに、作業状況の変更に基づき、各ワークフローの進捗状況を把握するものであるから、動的計画管理装置は、各作業単位の作業状況を蓄積、変更することによってワークフローの管理を行うものである。
　
　上記Ｉ、Ｊの記載からみて、ワークフローの種類を大きくわけたカテゴリの一つに帳票作成がある。そして、動的計画管理装置の環境の設定時に、予めドキュメント種（帳票種）毎に、作業手順等のワークフローに関する情報が設定され、上記Ｈ、Ｊに記載されているように、帳票が起票されると、上記ドキュメント種（帳票種）毎の設定に基づき、ワークフロー情報（ワークフロー・データ）が生成されて、ワークフロー管理が行われるようになっている。
　
　上記Ｈ、Ｊに記載されているように、これらの帳票種の一つとして障害票が含まれており、障害票の起票により、上記ドキュメント種（帳票種）毎の設定に基づくワークフロー・データの生成と、ワークフロー管理が行われるから、動的計画管理装置は、ソフトウェア開発等の作業工程のワークフロー管理の一つとして、ソフトウェアに生じた障害の対策処理のワークフロー管理を行うものであることがわかる。
　
　よって、上記Ｅ−Ｊの記載事項及び関連する図面を参照すると、引用文献２には、次の発明（以下、「引用発明２」という。）が記載されていると認められる。
　
「ソフトウェア開発等の作業工程について、ワークフロー・データに基づくワークフロー管理を行う動的計画管理装置であって、
　ソフトウェアに生じた障害の対策処理を、ドキュメント種（帳票種）毎に予め設定された作業手順等のワークフローに関する情報に基づき、ワークフロー・データを生成し、各作業単位の作業状況を蓄積、変更することによってワークフロー管理する動的計画管理装置。」
　
（３）引用文献３
　当審の拒絶理由に引用された刊行物である、日経コンピュータ別冊「ソフトウェア開発の最新技術」、日経ＢＰ社、平成１０年１１月９日発行、Ｐ．２０６−２２６（以下、「引用文献３」という。）には、以下の事項が記載されている。
　
Ｋ．「我々はシステムの開発と運用中に収集した、障害に関するデータ（以下、「障害データ」と呼ぶ）を統計的に処理することにより、システムのライフサイクル全体にわたってソフトの信頼性を定量的に評価する手法を開発した。」（２０６頁左欄１２行〜１６行）
　
Ｌ．「信頼性の変動の過程を分析する際に使う指標には、障害発生までの間隔、障害発生の累積回数、単位時間当たりの障害回数（障害強度）の三つの指標を使うことが多い。これらの指標の測定値をプロットしたグラフを見て、試験的に傾向を導くわけである。」（２０７頁右欄１６行〜２０８頁左欄３行）
　
　また、引用文献３の図７（２１４頁）には、「●障害発生の累積回数。観測値と単位時間９から２０の障害データを使って各種モデルで予測した値」として、横軸を単位時間、縦軸を障害発生の累積回数とした障害発生の累積回数のグラフが記載されている。
　
　よって、上記Ｋ、Ｌの記載事項及び上記図７の記載内容を参照すると、引用文献３には、次の発明（以下、「引用発明３」という。）が記載されていると認められる
　
「システムの開発及び運用中に収集した、障害に関するデータを統計的に処理し、ソフトの信頼性の評価を行う方法であって、
　そのための指標の一つとして、障害発生の累積回数を用い、経過時間毎の障害累積回数をグラフ表示する方法。」
　
５．対比・判断
　本願発明と引用発明１とを対比すると、引用発明１の「トラブル」、「トラブルデータ」、「トラブル分析支援装置」は、それぞれ、本願発明の「各種障害」、「レポート情報」、「障害管理装置」に相当する。
　
　引用発明１の「ソフトウェア上に発生したトラブルに関して入力されたトラブルデータを保存するデータベース」は、本願発明のレポート情報に相当するトラブルデータを保存、すなわち、蓄積するものであるから、本願発明の「ソフトウェア上に発生した各種障害に関して入力されたレポート情報を蓄積するための記憶手段」に相当する。
　
　引用発明１の「上記データベースの中から特定の条件に合うトラブルデータを抜き出すトラブルデータ検索部」は、特定の条件に合うトラブルデータを抜き出す、すなわち、トラブルに関する情報の収集を行うものであるから、本願発明の「上記記憶手段の中から障害に関する情報を収集する情報収集手段」に相当する。
　
　引用発明１の「上記抜き出されたトラブルデータ」は、本願発明の情報収集手段に相当するトラブルデータ検索部から得られた情報であり、本願発明の「上記収集した情報」に相当するから、引用発明１の「トラブル分析・結果表示部」は、収集した情報を基に分析を行い、収集した情報に関する情報（分析結果）を出力（表示）する手段（以下、「分析出力手段」という。）である点で、本願発明の「分析・評価手段」と一致する。
　
　したがって、両者は、
「ソフトウェア上に発生した各種障害に関して入力されたレポート情報を蓄積するための記憶手段と、
　上記記憶手段の中から障害に関する情報を収集する情報収集手段と、
　上記収集した情報を基に分析を行う分析出力手段とを備え、
　上記分析出力手段は、上記収集した障害に関する情報を出力することを特徴とする障害管理装置。」
である点で一致し、以下の３点で相違している。
　
［相違点１］
　本願発明の障害管理装置が、入力されるレポート情報の障害毎にどのような手順で障害に対する対策処理をとっていくかを定義したワークフロー定義情報に基づいて対策処理の状態情報を遷移させると共に記憶手段に遷移状態情報を格納する状態遷移処理手段、すなわち、障害に対する対策処理のワークフロー管理を行うための手段を備えているのに対し、引用発明１のトラブル分析支援装置は、上述の状態遷移処理手段のようなトラブルに対する対策処理のワークフロー管理を行うための手段を備えていない点。
　
［相違点２］
　分析出力手段が、本願発明では、「分析・評価手段」であり、障害に関する情報の分析に加えて評価も行うのに対し、引用発明１では、「トラブル分析・結果表示部」であり、トラブルデータの分析のみを行い、評価を行っていない点。
　
［相違点３］
　分析出力手段の出力する情報が、本願発明では、収集した障害に関する情報を経過時間毎に発生件数を累積したものであるのに対し、引用発明１では、トラブル発生密度分析、トラブル原因別分析等の結果である点。
　
　以下、上記各相違点について検討する。
　
［相違点１］について
　引用発明２にあるように、ソフトウェアに生じた障害の対策処理を、ドキュメント種（帳票種）毎に予め設定された作業手順等のワークフローに関する情報（本願発明の「ワークフロー定義情報」に相当。）に基づき、ワークフロー・データを生成し、各作業単位の作業状況（同「遷移状態情報」に相当。）を蓄積（同「格納」に相当。）、変更（同「遷移させ」に相当。）することによってワークフロー管理することは公知である。
　
　また、ワークフロー管理において、作業手順や担当部署の違いに応じて複数のワークフロー定義情報を用意しておくことは、いずれも本願の出願前に頒布された刊行物である、特開平１０−３２０４５６号公報（段落【０００２】〜【０００３】の従来の技術の説明において、業務の種類毎に処理順番や実行者の情報（ワークフロー定義情報）を予め定義して保存しておき、同一の業務が発生した時、該定義情報を再利用することの記載がある。）、戸田、外３名著「ワークフロー　ビジネスプロセスの変革に向けて」、初版、株式会社日科技連出版社、１９９８年５月３日、ｐ．９５−９７（稟議回章業務を３０種類のワークフローに分けてワークフロー管理することの記載がある。）、田路、外１名著「ＯＣＮ問合せ応対業務支援システム　ＯＣＮ−ＭＣＣＳの概要」、ＮＴＴ技術ジャーナル、社団法人電気通信協会、１９９８年１月１日、第１０巻、第１号、ｐ．１１４−１１６（客からの問合せをチケットを用いてワークフロー制御し、送信元のグループと帳票の種類に基づいて、あらかじめ設定された宛先グループに自動的に配信することの記載（１１５頁中欄３行〜２１行参照）がある。）に記載されているように周知である。
　
　そして、引用発明１において扱われるトラブルの原因としては、上記４．（１）Ｄに記載されているように、「基本ソフトウェア」、「応用ソフトウェア」、「ハードウェア」といった大きな分類が想定されており、これらの違いによって、トラブル対策の内容や担当部署が異なることは、当業者であれば明らかであるから、引用発明１において、同じくソフトウェア開発におけるトラブルや障害の対策に関する技術である、上記引用発明２に係る上記公知技術を採用して、トラブルの対策処理をワークフロー管理するとともに、そのワークフローの管理をトラブルの原因毎に行うものとし、入力されるトラブルデータのトラブル毎にどのような手順でトラブルに対する対策処理をとっていくかを定義したワークフロー定義情報に基づいて対策処理の状態情報を遷移させるとともにデータベースに遷移状態情報を格納するための状態遷移処理手段を設けることは、当業者が容易になし得ることである。
　
［相違点２］について
　システムの開発及び運用中に収集した、障害に関するデータをソフトの信頼性の評価に用いることは、引用発明３に見られるように周知であるから、引用発明１におけるトラブル分析・結果表示部において、ソフトウェアの開発中及び開発後に発見されたトラブルに関するデータであるトラブルデータについて、分析だけでなく、評価も行うことは、当業者が容易に想到し得ることである。
　
［相違点３］について
　システムの開発及び運用中に収集した、障害に関するデータの分析結果として、経過時間毎の障害発生の累積回数を出力することは、引用発明３にみられるように周知であるから、引用発明１において、トラブル分析・結果表示部におけるトラブルデータの分析結果として、トラブル発生密度分析、トラブル原因別分析等の結果に代えて、経過時間毎にトラブル発生件数を累積したものを出力することに、格別の困難性はない。
　
　そして、本願発明の構成によってもたらされる効果も、引用文献１及び２に記載された発明及び周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
６．むすび
　以上のとおり、本願発明は、引用文献１及び２に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　
　よって、結論のとおり審決する。