【事件の表示】
　特願２００５−２１４３０３「組み込み照合情報を備えるデータ型」拒絶査定不服審判事件〔平成１８年　３月　９日出願公開、特開２００６−　６５８４８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
１．１　手続の経緯の概略
　本件の手続の経緯は概略以下の通りのものである。
　出願　　　　　　　　　　　　　　　平成１７年７月２５日
　　　　　　　　　　　（優先権主張日２００４年８月２５日，米国）
　拒絶理由通知　　　　　　　　　　　平成２３年４月１９日
　意見書及び手続補正書　　　　　　　平成２３年７月２２日
　拒絶査定　　　　　　　　　　　　　平成２３年９月８日
　同謄本送達　　　　　　　　　　　　平成２３年９月１３日
　審判請求　　　　　　　　　　　　　平成２４年１月１３日　
　手続補正書　　　　　　　　　　　　平成２４年１月１３日
　前置報告書　　　　　　　　　　　　平成２４年６月１８日
　審尋　　　　　　　　　　　　　　　平成２４年８月２９日
　回答書　　　　　　　　　　　　　　平成２４年１２月４日
　
２．１　原審拒絶理由の概要
「【理由１】この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　
　（１）請求項１の「照合情報」という用語の定義が不明であり、請求項１の記載は明確ではない（明細書段落【００２２】には、「一般に、照合情報は、データを正しく比較するために必要とされる任意の情報である」という記載が存在するが、「任意の情報」という記載は曖昧であり、また、「データを正しく比較するために必要とされる」情報という記載も、曖昧である（このような曖昧なことを言っているのであれば、従来から存在するintやcharなどの変数の型も、「データを正しく比較するために必要とされる」情報であると言えるから、そのような従来から存在する変数の型と、請求項１の「照合情報」とでは、何が違うのかも不明である）。また、「一般に」というのは、例外が存在することを示唆する表現であるから、「一般に、照合情報は、データを正しく比較するために必要とされる任意の情報である」という文章は、「照合情報」は、「データを正しく比較するために必要とされる任意の情報である」のが一般的だが、必ずしもそうでなくても限らないという趣旨の文章表現であり、すると、「必ずしもそうでなくても限らない」場合の「照合情報」とは何であるのか皆目不明である。したがって、明細書の記載を参照しても、請求項１の「照合情報」という用語の定義は不明である）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（２）請求項１の「型制限」という用語の定義が不明であり、請求項１の記載は明確ではない（明細書を参照しても、「型制限」という用語の定義を説明する記載は存在していない。また、「型制限」に類似した用語で、「型制約」という用語は明細書の中に記載されているが、この「型制約」という用語の定義も不明である）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（３）請求項１の「照合制限」という用語の定義が不明であり、請求項１の記載は明確ではない（明細書を参照しても、「照合制限」という用語の定義を説明する記載は存在していない。また、「照合制限」に類似した用語で、「照合制約」という用語は明細書の中に記載されているが、この「照合制約」という用語の定義も不明である）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（４）請求項１には「型制限および照合制限を含むデータ制約コンポーネント」という記載が存在するが、この記載における「データ制約コンポーネント」は、「型制限」および「照合制限」を「含む」と記載されているものの、「データ制約コンポーネント」とはそもそも何なのか不明である（何らかのプログラムであるのか、あるいは、制限条件や制約条件を列挙しただけのデータに過ぎないのか、或いは、段落【００１５】に「ＬＩＳＴ＜Ｓｔｒｉｎｇ＜ｅｎｇ＞＞」と記載されているような単なる文字列に過ぎないのか、いずれであるのか不明であり、また、仮に、「データ制約コンポーネント」が何らかのプログラムであると仮定しても、如何なる処理を行うプログラムであるのかも不明である）。したがって請求項１の記載は明確ではない（用語の定義を明確にされたい）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（５）請求項２には「前記照合制限は、前記データ型に組み込まれる」という記載が存在するが、「照合制限」が「データ型」に「組み込まれる」とは如何なる意味であるのか不明であり、請求項２の記載は明確ではない（なお、請求項２の「照合制限」を「照合制約」と補正しても、それだけでは、ここで指摘されている記載不備は解消されないので、注意されたい）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（６）請求項３には「前記型は、前記照合情報によってパラメータ化される」という記載が存在するが、「型」が「照合情報」によって「パラメータ化」されるとは如何なる意味であるのか不明であり、請求項３の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（７）請求項４には「前記データ制約コンポーネントは、ｔｙｐｅ＜ｃｏｌｌａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ＞の形式である」という記載が存在するが、この記載は、以下の（7-1）〜（7-3）の点が不明であり、請求項４の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　　（7-1）「ｔｙｐｅ＜ｃｏｌｌａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ＞」という記載の意味するところが不明である。
　　（7-2）「データ制約コンポーネント」の「形式」とは、何のことであるのか意味するところが不明である。
　　（7-3）「ｔｙｐｅ＜ｃｏｌｌａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ＞」というのは文字が並んだもの（sequenceofcharacters）に過ぎないが、「コンポーネント」が、そのような「文字が並んだもの」の「形式」であるとは如何なる意味であるのか意味不明である（文章表現を再考されたい）。
　
　（８）請求項５の「汎用型と共に採用されて構造型を作成する」という記載の意味するところが不明であり、請求項５の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（９）請求項６の「照合部分型」という用語の定義が不明であり、請求項６の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（10）請求項１０には「前記データ制約コンポーネントは、パラメータ化された型である」という記載が存在するが、この記載の意味するところが不明であり、請求項１０の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（11）請求項１２の冒頭には「前記データ型」という記載が存在するが、請求項１２が引用する請求項１には「型」という記載は存在するが、「データ型」という記載は存在していないので、請求項１２の冒頭の「前記データ型」という記載は矛盾しており、請求項１２の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　以上（１）〜（11）として指摘したとおりであるので、請求項１〜１３の記載は明確ではない。
　　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由１）
　
【理由２】この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　
　（１）請求項１には「型制限」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（２）請求項１には「照合制限」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（３）請求項６には「照合部分型」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　以上（１）〜（３）として指摘したように、請求項１〜１３の記載は、発明の詳細な説明の記載と対応していないので、請求項１〜１３として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない（なお、請求項の記載が発明の詳細な説明の記載と対応しないという当方からの上述の指摘に反論がある場合には、対応する記載が存在する明細書内の記載箇所（段落番号、段落内の文番号）を具体的に特定して、意見書で対応関係を説明するようにされたい）。
　
　【注意１】
　（１）明細書の中には、請求項の中の記載を形式的に反復して記載しているに過ぎない記載箇所が存在するが、そのような明細書中の記載箇所と、請求項の記載との間に形式的な対応関係が存在するだけでは不十分であり、明細書の【発明を実施するための最良の形態】の中に記載されている具体的な構成と対応することが必要であるから、注意して対処されたい（審査基準第Ｉ部第１章（明細書及び特許請求の範囲の記載要件）の2.2.1（２）の「表現上の整合性にとらわれることなく、実質的な対応関係について審査する」という記載参照）。
　（２）特許請求の範囲の記載様式は、特許法施行規則の「様式２９の２」にて規定されており、この「様式２９の２」の［備考］の９には、用語は、明細書及び特許請求の範囲全体を通じて統一して使用することが規定されているので、この規定を遵守するようにされたい。
　　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由２）
　
【理由３】この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　記
　
　（１）上記【理由１】及び【理由２】において指摘した請求項１〜１３の中の記載箇所の記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
　
　（２）請求項１には「受け取った型および照合情報を使用して、型制限および照合制限を含むデータ制約コンポーネントを生成する」という記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。「受け取った型および照合情報」に対して、具体的にどのようなアルゴリズムに基づく演算を施すと、「型制限および照合制限を含むデータ制約コンポーネント」が生成されるのか不明である（なお、ここで指摘されている記載不備は、請求項１の「型制限」、「照合制限」という用語を、「型制約」、「照合制約」と補正しても、それだけでは解消されないので、注意されたい）。
　例えば、「受け取った型」が「ＳＴＲＩＮＧ型」で、「照合情報」が「スペイン語」であった場合、前記「ＳＴＲＩＮＧ型」という情報と、前記「スペイン語」という情報とに対し、具体的にどのようなアルゴリズムに基づく演算を施すと、具体的にどのような内容の「型制限および照合制限を含むデータ制約コンポーネント」が生成されるのか、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない（図２や図３のような箱形の記号が並んだ模式図を見せられても、その中身が具体的に何であるのかは不明であり、また、その中身を具体的にどのようなアルゴリズムに基づいて生成するのかも不明である）。したがって、請求項１記載の発明は実施できない。同様の記載を有するその他の請求項に記載されている発明も、同様に実施できない。
　
　よって、この出願の発明の詳細な説明は、当業者が請求項１〜１３に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。
　
　【注意２】
　明細書の中には、請求項の中の記載を形式的に反復して記載しているに過ぎない記載箇所が存在するが、そのような記載箇所の記載は、単なる願望が抽象的に記載されているだけであり、具体的な実現手法を説明する記載であるとは認められない。
　　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由３）
　
【理由４】この出願の下記の請求項に係る発明は、下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないので、特許を受けることができない。
　・・・（中略）・・・
【理由５】この出願は、下記の点で特許法第３７条に規定する要件を満たしていない。
　・・・（中略）・・・
【理由６】この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
・請求項１〜１３
引用文献：
１．米国特許第５６９６９７３号明細書
２．BjarneStroustrup著，長尾高弘訳，「プログラミング言語Ｃ＋＋　第３版」，初版，１９９８年１１月３０日，アジソン・ウェスレイ・パブリッシャーズ・ジャパン株式会社，第６３〜６４頁，ISBN:4-7561-1895-X
３．米国特許出願公開第２００２／０１７４１００号明細書
４．「IBMCloudscape　リファレンス・マニュアル　バージョン5.2　SC88-9909-00（英文原典SC18-7585-01）」，第１刷，２００３年１２月，日本アイ・ビー・エム株式会社，第１９９〜２００頁
５．「VisualAgeC++forWindows　使用者の手引き　バージョン3.5　SB88-7180-00（英文原典S33H-5031-00）」，第１刷，１９９６年７月，日本アイ・ビー・エム株式会社，第６５１〜６６０頁
６．浅海智晴，「Javaデザインノート　第１２回　Webデータ・タイプ」，JAVAWORLD，２００１年６月号（第５巻第６号），２００１年６月１日，（株）IDGジャパン，第１１０〜１２２頁７．社団法人情報処理学会，「新版　情報処理ハンドブック」，第１版，１９９５年１１月２５日，株式会社オーム社，第６５０頁，ISBN:4-274-07832-9
備考：
　引用文献１は、第１頁のABSTRACTの記載、第１コラム第９〜３６行、同コラム第５１行〜第２コラム第第２６行、第３コラム第５５行〜第４コラム第１５行、同コラム第４７〜５３行、第５コラム第第２９〜３３行、第１０コラム第１９〜４９行、第１２コラム第４１〜５２行の記載（特にsubtypeに関する記載）に、特に注意されたい。
　引用文献２は、「ユーザー定義型」に関する記載に、特に注意されたい。
　引用文献３は、第１頁のABSTRACT内のculturallysensitivesorting,localespecificationhavingcollationinfromationofaculture,localetokenに関する記載に特に注意されたい。
　引用文献４は、「ロケール固有の照合シーケンス」という表題の付いた段落の記載に特に注意されたい。
　引用文献５は、第６５１頁中段の「カスタム・データ型の作成」という記載、第６５３頁の後半の「可変情報ブロック」の「langID」、「charsetID」に関する記載、第６５６頁の図表（langIDの詳細を説明する図表である）の中の「標準スペイン語」、「メキシコのスペイン語」という記載、第６５７頁の図表（charsetIDの詳細を説明する図表である）の中の「日本語」、「ギリシャ語」、「トルコ語」、「ヘブライ語」、「アラビア語」という記載に、特に注意されたい。
　引用文献６は、第１１５頁の「表３：ＳＱＬのデータ・タイプ」という表の中の「TIME」、「TIMESTAMP」、「TIMEWITHTIMEZONE」、「TIMESTAMPWITHTIMEZONE」という記載と、第１２０頁の「表９：時間型のマッピング」という記載に、特に注意されたい。
　引用文献７は、第６５０頁左コラムの下から１５行目〜同頁右コラム第１５行の記載（弱く型付けされた言語では、それぞれのデータが自分の属する型の情報を内部に保持している旨の記載）に、特に注意されたい。
・・・（後略）・・・ 」
　
２．２　原審拒絶理由に対する意見書、補正書の概要
２．２．１意見書の概要
「・・・（中略）・・・
（２）出願人は、かかる拒絶理由に鑑み、別途提出の手続補正書により本願の特許請求の範囲を補正し、本願発明の要旨をより一層明確にするとともに、以下のように意見を申し述べる次第です。
（３）本願発明の要旨とするところは、補正した特許請求の範囲の記載より明らかなように、請求項１に記載の発明は、
「
コンピュータを、
　データ型を受け取る型受信コンポーネント、
　前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信する照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント、および
　前記データ型および前記照合情報に基づき、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって、前記パラメータ化は、１以上のデータ型パラメータを前記データ型に追加することを含む、コンストラクタコンポーネント
　として機能させるためのプログラムを備えたことを特徴とする型制約システム
です。
（４）補正の説明
　請求項１，１１，１４は、本願当初明細書の段落［００２２］、［００３５］、［００３７］、［００４０］の記載に基づくものです。
　請求項２，１３は、補正前の請求項５，２５と本願当初明細書の段落［００４１］の記載に基づくものです。
　請求項３〜９，１２，１５〜１７は、補正前の請求項６〜１２，２３，３６，３７，３９に基づくものです。
　請求項２〜４，１０，１４〜１８，２０〜２２，２４，２６〜３３，３５，３８，４０は削除しました。
（５）理由１，２について
・「
前記受信したデータ型とデータを比較および順序付けするために使用される照合情報
・「
前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネント
・請求項３に記載の「部分型」は、本願当初明細書の段落［００２７］の記載に基づくものです。
（６）理由３について
　本願当初明細書の表３〜６に記載されているように、データ型をさらに詳細に表現するためにデータ型の直後の＜＞内にパラメータ化した照合情報を記述することは当業者にとって明らかであると思料します。また、図７〜９のフローチャートで示された手順によってデータ制約が生成できることも当業者が十分理解できるものと思料します。
（８）理由４について
　コンピュータによって各機能、ステップが実現されることを明確にしました。
（９）理由５，６について
　本願発明は、照合情報をパラメータ化してインスタンスではなくデータ型に組み込むことによってコンパイル時にエラーを発見できる強い型検査が可能にすることを特徴とします。
　しかしながら、引用文献１〜７には、データ型に組み込むことができるパラメータ化された照合情報、および、インスタンス化してからの照合をしなくても強い型検査が可能であることについては開示していません。
　引用文献２，５には、「ユーザ定義型」や「カスタム・データ型」などの固有のデータ型を作成するための構成が開示されていますが、これらを使用して強い型検査を可能する構成については開示されていません。
　よって、本願発明は、引用文献１〜７に開示されていない固有の技術的特徴を有し、当業者が引用文献１〜７から容易に発明できたものではないと思料します。
・・・（後略）・・・」
　
２．２．２　補正書
（略）　３．１の（本件補正前の特許請求の範囲）参照。
　
２．３　拒絶査定の概要
「　この出願については、平成２３年４月１９日付け拒絶理由通知書に記載した理由１〜３によって、拒絶をすべきものです。
　なお、意見書及び手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
備考
　（１）理由１について
　（1-1）理由１の（１）として指摘した記載不備が、依然として解消されていない。補正後の請求項１の中には、「照合情報」という単語を修飾する修飾句として、「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載（以下、便宜的に「記載Ａ」という。）と、「前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み」という記載（以下、便宜的に「記載Ｂ」という。）とが存在するが、これら記載Ａ及び記載Ｂは、以下の（1-1-1）及び（1-1-2）の点が不明であり、このような不明瞭な修飾句であるところの前記記載Ａ及び前記記載Ｂを伴う補正後の請求項１の「照合情報」という用語は依然として明確ではない。したがって、補正後の請求項１の記載は、依然として明確ではない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　
　（1-1-1）前記記載Ａは、「データ型」と「データ」を「比較および順序付けする」という趣旨の記載であるが、「データ型」と「データ」を「比較」するとは如何なる意味であるのか不明であり、また、「データ型」と「データ」を「順序付けする」とは如何なる意味であるのかも不明である。
　（1-1-2）前記記載Ｂには、型検査を「容易」にするという趣旨の記載があるが、「容易」か否かの判断基準が何であるのか不明である（審査基準第Ｉ部第１章（明細書及び特許請求の範囲の記載要件）の2.2.2.1（５）の３番目の項目参照）。
　
　（1-2）理由１の（３）として指摘した記載不備が、依然として解消されていない。補正後の請求項３〜６の「照合制限」という用語の定義が依然として不明である。
　
　（1-3）理由１の（４）として指摘した記載不備が、依然として解消されていない。補正後の請求項１には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載は、「データ制約コンポーネント」は、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」を「含む」という趣旨の記載であるが、そもそも「データ制約コンポーネント」とは何なのか、依然として不明である（何らかのプログラムであるのか、あるいは、制限条件や制約条件を列挙しただけのデータに過ぎないのか、或いは、段落【００１５】に「ＬＩＳＴ＜Ｓｔｒｉｎｇ＜ｅｎｇ＞＞」と記載されているような単なる文字列に過ぎないのか、いずれであるのか依然として不明であり、また、仮に、「データ制約コンポーネント」が何らかのプログラムであると仮定しても、如何なる処理を行うプログラムであるのかも依然として不明である）。また、補正後の請求項１の上述の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載の中の「前記照合情報によってパラメータ化された前記データ型の変数」という記載も、その意味するところが不明である（「パラメータ化された」は、「データ型」に係るのか、「変数」に係るのか、文章の係り受け構造が不明であり、また、係り受け構造の解釈をどちらに解釈しても、照合情報によって「パラメータ化」されるとは、如何なる意味であるのかも不明である）。
　したがって、補正後の請求項１の記載は、依然として明確ではない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　
　（1-4）理由１の（６）として指摘した記載不備が、依然として解消されていない。補正後の請求項１には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載には、「データ型」が「照合情報」によって「パラメータ化」されるという趣旨に解釈可能な記載が依然として存在しており、その意味するところが依然として不明である。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　
　（1-5）理由１の（８）として指摘した記載不備が、依然として解消されていない。補正後の請求項２には「汎用型と共に採用されて構造型を作成する」という記載が依然として存在しており、その意味するところが依然として不明である。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　
　以上（1-1）〜（1-5）で指摘した記載不備が依然として解消されていないので、補正後の請求項１〜１６の記載は、依然として明確ではない。
　　　　　　　　　　　　　　　　　　　　　（以上、理由１について）
　
　（２）理由２について
　（2-1）理由２の（２）として指摘した記載不備が、依然として解消されていない。補正後の請求項３〜６には依然として「照合制限」という記載が存在するが、そのようなものは、依然として、発明の詳細な説明には記載されていない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　　　　　　　　　　　　　　　　　　　　　（以上、理由２について）
　
　（３）理由３について
　（3-1）理由３の（１）として指摘した記載不備が、依然として解消されていない。上記「（１）理由１について」及び上記「（２）理由２について」で指摘した補正後の請求項１〜１６の中の記載箇所の記載の具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
　
　（3-2）理由３の（２）として指摘した記載不備が、依然として解消されていない。指摘を受けていた請求項１の記載は、補正後の請求項１では、
　
「前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成する」
　
という記載（以下、便宜的に「記載Ｃ」という。）に変わったが、この記載Ｃの具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
　前記記載Ｃは、「前記データ型および前記照合情報」を「使用」して、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」を「生成」するという趣旨の記載であるが、「前記データ型および前記照合情報」に対して、具体的にどのようなアルゴリズムに基づく演算を施すと、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」が生成されるのか、依然として不明である。
　例えば、「データ型」が「ＳＴＲＩＮＧ型」で、「照合情報」が「スペイン語」であった場合、前記「ＳＴＲＩＮＧ型」という情報と、前記「スペイン語」という情報とに対し、具体的にどのようなアルゴリズムに基づく演算を施すと、具体的にどのような内容の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」が生成されるのか、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない（図２や図３のような箱形の記号が並んだ模式図を見せられても、その中身が具体的に何であるのかは依然として不明であり、また、その中身を具体的にどのようなアルゴリズムに基づいて生成するのかも依然として不明である）。
　なお、意見書において出願人は、
　
「（６）理由３について
　本願当初明細書の表３〜６に記載されているように、データ型をさらに詳細に表現するためにデータ型の直後の＜＞内にパラメータ化した照合情報を記述することは当業者にとって明らかであると思料します。また、図７〜９のフローチャートで示された手順によってデータ制約が生成できることも当業者が十分理解できるものと思料します。」
　
という説明を行っているが、この説明の中で用いられている用語と、前記記載Ｃの中で用いられている用語とは異なっており、当該説明の中には、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」などという記載は存在していないので、意見書の前記説明は、補正後の請求項１の前記記載Ｃと何の関係があるのか不明であり、このような説明を参照しても、補正後の請求項１の前記記載Ｃの、「前記データ型および前記照合情報」を「使用」して、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」を「生成」するという趣旨の記載の具体的な実現手法は不明である（なお、用語は統一して用いるようにされたい）。
　したがって、補正後の請求項１記載の発明は依然として実施できない。同様の記載を有するその他の補正後の請求項に記載されている発明も、同様に、依然として実施できない。
　　　　　　　　　　　　　　　　　　　　　（以上、理由３について）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　【附記１】
　今回した補正によって、新たに以下の【理由Ａ】乃至【理由Ｄ】の拒絶理由が発生している。
　
　【理由Ａ】特許法第３６条第６項第２号違反
　（１）請求項１には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在し、この記載は、「データ型」が「データ型パラメータ」を「含む」という趣旨の記載であるが、その意味するところが不明であり、請求項１の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（２）請求項１には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在するが、「確実」か否かの判断基準が不明であり、請求項１の記載は明確ではない（審査基準第Ｉ部第１章（明細書及び特許請求の範囲の記載要件）の2.2.2.1（５）の３番目の項目参照）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（３）請求項１の「前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって」という記載は文章の係り受け構造が不明であり、
　
　（3-1）「前記データ型パラメータ」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、
　（3-2）「前記データ型パラメータを含むデータ制約コンポーネント」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、
　（3-3）「前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネント」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、
　
のいずれの趣旨であるのか不明であり、請求項１の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（４）請求項１の「データ型パラメータ」という用語の定義が不明であり、請求項１の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　（５）請求項３、４、６には「前記照合制限」という記載が存在するが、請求項３、４、６ににも、請求項３、４、６が引用する請求項１にも「照合制限」などというものは「前記」されていないので、請求項３、４、６の「前記照合制限」という記載は矛盾しており、したがって、請求項３、４、６の記載は明確ではない。
　
　（６）請求項１０には「データ制約を生成する」という記載と、「データ制約コンポーネントを生成する」という記載とが存在するが、これら２つの記載の関係が不明である（同じものを指すのであれば用語を統一すべきであるし、別のものを指すのであれば両者の関係や両者の違いが明確になるように請求項１０を記載されたい）。同様の記載を有するその他の請求項についても、同様の記載不備がある。
　
　以上（１）〜（６）として指摘したとおりであるので、請求項１〜１６の記載は明確ではない。
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ａ）
　
　【理由Ｂ】特許法第１７条の２第３項違反
　（１）補正後の請求項１には「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載が存在し、この記載は、照合情報とは、「データ型」と「データ」を「比較および順序付けする」ために使用する情報であるという趣旨の記載であるが、そのようなことは願書に最初に添付した明細書、願書に最初に添付した特許請求の範囲、願書に最初に添付した図面（以下、これら三者を便宜的に「当初明細書等」と総称する。）に記載した事項の範囲内のものではない。当初明細書の段落【００４０】には、「照合情報は、一般にデータを比較および／または順序付けするために必要なデータを含んでいる」という記載が存在するが、この記載は、「照合情報」とは、「データ」同士を「比較および／または順序付けする」ために用いられるという趣旨の記載に過ぎず、「データ型」と「データ」を比較や順序付けするために用いられるなどということは、記載されておらず自明でもない（また、常識的に考えても、例えば、段落【００２４】で、StringEnglishs1;と、StringGermans2;というように変数を宣言する記述がソースコード中にある場合、コンパイラは、EnglishやGermanという記述同士を比較してコンパイル時に型チェックを行い、また、コンパイラによって生成されたオブジェクトモジュールは、実行時には変数に格納されているデータ同士を比較したり順序付けしたりすると考えるのが当然であり、変数に格納されるデータの内容と、EnglishやGermanという記述とを比較したり、変数に格納されるデータの内容と、EnglishやGermanという記述とを順序付けたりするなどというナンセンスな処理を行う筈が無い（英文のクレームを日本語のクレームに翻訳する際に翻訳ミスが発生している可能性もあるので、注意されたい））。
　同様の記載を有するその他の補正後の請求項についても、同様に、当初明細書等に記載した事項の範囲内のものではない。
　
　（２）補正後の請求項１には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在し、この記載は、「データ型」が「データ型パラメータ」を「含む」という趣旨の記載であるが、そのようなことは、当初明細書等に記載した事項の範囲内のものではない。
　同様の記載を有するその他の補正後の請求項についても、同様に、当初明細書等に記載した事項の範囲内のものではない。
　
　以上（１）、（２）として指摘したとおりであるので、補正後の請求項１〜１６についてした補正は、当初明細書等に記載した事項の範囲内のものではない。
　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｂ）
　
　【理由Ｃ】特許法第３６条第６項第１号違反
　（１）上記【理由Ｂ】で指摘した請求項１〜１６の中の記載は、発明の詳細な説明の記載と対応しないので、請求項１〜１６に記載の発明は、発明の詳細な説明に記載した発明ではない。
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｃ）
　
　【理由Ｄ】特許法第３６条第４項第１号違反
　（１）上記【理由Ａ】乃至【理由Ｃ】で指摘した請求項１〜１６の中の記載箇所の記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｄ）
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　【附記２】
　先の拒絶理由通知書において【注意１】、【注意２】、【注意４】として説示した注意事項は、現時点においても引き続き有効であるので、審判請求を行うのであれば、その際には、それらの注意事項を遵守するようにされたい。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　【附記３】
　上記「（１）理由１について」、　上記「（２）理由２について」、　上記「（３）理由３について」及び上記【理由Ａ】乃至【理由Ｄ】で指摘した記載不備の程度の悪さが著しいので、現時点では、請求項１〜１６については、新規性、進歩性等の特許要件についての審査を行っていない（行うことができない）。請求項１〜１６に新規性や進歩性が有ると認めているわけではないので、誤解の無いように注意されたい。
　なお、現時点において、以下の【参考文献１】及び【参考文献２】の存在を把握しているので、参考までにお知らせしておく。
　上述の如く、記載不備があるために、現時点では進歩性の審査を厳密に行うことができない状態であるが、例えば以下の【参考文献１】の第３００頁左コラムの「3.3　文字型のパラメタ化」というセクションには、変数Ａを宣言する表記法として、
　
CHARACTER(KIND=2LEN=6)::A
　
という表記法（CHARACTERという記述が、変数Ａが文字型であることを宣言し、KIND=2という記述が、変数Ａには日本語の文字が格納されることを宣言するという表記法）が例示されているが、この記載のうち、「CHARACTER」という文字列をキーボードから受け取る手段が本願請求項１の「型受信コンポーネント」に対応し、「KIND=2」という文字列をキーボードから受け取る手段が本願請求項１の「照合情報受信コンポーネント」に対応し、受け取った前記「CHARACTER」という文字列と、前記「KIND=2」という文字列とをくっつけてＦＯＲＴＲＡＮ９０のソースコードの中に書き込む手段が本願請求項１の「コンストラクタコンポーネント」に対応するという対応付けも可能ではないかと審査官は考えていることを、参考までに申し述べておく（なお、コンパイラがソースコード内で宣言された変数の型に基づいてコンパイル時に変数の型チェックを行うのは当然であるから、上述の如く、「CHARACTER(KIND=2LEN=6)::A」という宣言をソースコード内で発見したコンパイラは、「CHARACTER」という変数の型と、「KIND=2」という文字種（日本語）という型との両方のチェックを行うのは当然のことである）。
　
　【参考文献１】
　和田英穂，「プログラミング言語最新情報-II4.新しいFortran-Fortran90-」，情報処理，1995年4月号（第36巻,第4号），社団法人情報処理学会，１９９５年４月１５日，第２９７〜３０３頁,ISSN:0447-8053（特に、第３００頁左コラムの「3.3　文字型のパラメタ化」というセクションの中の「文字型に種別パラメタが追加され」という記載に注意）
　
　【参考文献２】
　高田正之，「Fortran90の概要」，ｂｉｔ，1993年12月号（通巻第327号），共立出版株式会社，１９９３年１２月１日，第２３〜３０頁，ISSN:0385-6984（特に、第２６頁右コラムの「５．その他の新機能」というセクションの中の、「型パラメタという概念ができた」、「種別（kind）パラメタが加わった」、「数値型では精度や範囲の違い、文字型では字種の違いを表すと思ってよい」、「character(5,kanji)::message」という記載に注意）」
　
２．４　審判請求の理由と審判請求時の補正
２．４．１　審判請求の理由
　審判請求の趣旨は「原査定を取り消す。本願の発明は特許すべきものとする、との審決を求める。」というものであり、その理由は、概略、次のとおりのものである。
「　・・・（中略）・・・
　【本願発明が特許されるべき理由】
（ａ）本願発明の説明
　本願発明は、変数の属性としてデータ型を指定する「型制約」に加えて、データ型をより詳細に指定する「照合制約」を備えることを特徴とします。すなわち、本願発明は、請求項１にあるように、
「・・・（中略）・・・」
です。
（ｂ）補正について
　補正前後の請求項の関係は下表の通りです。補正前の請求項２、１２〜１６は削除しました。
・・・（中略）・・・
（１）請求項１，９は、補正前の請求項１，１０を本願明細書の段落［００１２］、［００１３］、［００２３］〜［００２５］、［００３７］、［００４５］の記載に基づき補正したものです。
・「
前記コンピュータに入力されたデータに含まれる変数の
指定する型制約を
制約
・「データ型
が同じ前記変数同士
制約
・「前記
型制約
制約からなり、前記変数を
するために使用されるデータ制約
・「前記パラメータ化は、
前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする
（２）請求項３，４は、補正前の請求項４，５を本願明細書の段落［００２６］の記載に基づき補正したものです。
（３）請求項５は、補正前の請求項６を本願明細書の段落［００３６］の記載に基づき補正したものです。
（４）請求項６〜８，１０は、補正前の請求項７〜９，１１を請求項１，９と整合するように補正したものです。
　
（ｃ）理由１，３について・請求項１，９において、本願明細書の段落［００４５］の「型が同じまたは比較できる場合、・・・照合制約が比較できるかどうかに関して判別が行われる」との記載にあるように、比較等の対象は同じ型のコンポーネントであり、かつ［００２５］に「ｓ１およびｓ２を比較すると」との記載から、「前記受信した
型制約で指定された
が同じ前記変数同士
制約
・請求項１，９において、「前記パラメータ化は、
前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする
前記変数を
するために使用されるデータ制約
本願明細書の表３〜６、図７〜９およびこれらに関連する記載から「データ制約」を生成することは十分可能であると思料します。
　
（ｄ）理由２について
　補正前の請求項３〜６の「照合制限」との記載は、「照合制約」に補正しました。
　
　　【むすび】
　以上のとおり、本願発明は、特許法第３６条第６項第１号及び第２号、第３６条第４項第１号に規定する要件は満たすものと思料します。
　よって、原査定を取り消す、本願発明は特許すべきものとする、との審決を求めます。
・・・（後略）・・・」
　
２．４．２　審判請求時の補正
　（略）　３．１（本件補正後の特許請求の範囲）参照。
　
２．５　前置報告
　平成２４年６月１８日付けでなされた前置報告の概略は次のとおりである。
「審判請求時になされた手続補正は、以下に（Ａ）〜（Ｃ）として述べるように、特許法第１７条の２第３項の規定に適合しないので、特許法第１５９条第１項において準用する特許法第５３条第１項の規定により、前記手続補正は、審判合議体の手によって却下されるべきものである。
　そして、審判請求時になされた上述の手続補正が却下されれば、原査定は維持される。
　
　（Ａ）補正後の請求項１には、「前記照合制約は前記データ型のコンパイル時の型検査に使用する１以上のパラメータを含み、
前記比較および順序付け操作中
前記コンパイル時の型検査は
判定する
　前記「記載Ａ」の中の「前記比較および順序付け操作中」と記載されているところの「操作中」という期間は、コンパイラが既に処理を済ませて、コンパイラの出力を用いたリンク処理（技術常識）なども済み、そうして最終的に完成したプログラムを動作させている期間のことである（すなわち、この「操作中」という期間の開始時点においては、コンパイラの処理は、既に終了している）。
　一方、前記「記載Ａ」の中の「前記コンパイル時の型検査は・・・判定する」という「判定」処理は、コンパイラがソースコードをコンパイル処理している最中に行われる処理である。
　したがって、前記「記載Ａ」は、コンパイラがコンパイル中に行う「判定」処理が、コンパイラの処理完了後に完成したプログラムを実行させている期間中に、行われるという趣旨の、時間的な前後関係が矛盾した出鱈目な記載になっており、そのような矛盾した出鱈目な記載は、当初明細書等には記載されておらず自明でもないので、特許法第１７条の２第３項に規定されている要件を満たさない。補正後の請求項９についても同様。補正後の請求項１、９を引用するその他の請求項についても同様。
　
　（Ｂ）補正後の請求項１の「前記型制約および前記照合制約からなり、前記
変数をパラメータ化する
　
　（Ｃ）補正後の請求項１の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、
前記変数の属性を定義するパラメータ
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
　【附記】（進歩性について）
　拒絶査定の【附記３】で述べたように、拒絶査定時の請求項には不明瞭な記載が存在する（また、審判請求時の請求項にも、同様に不明瞭な記載が存在する）ので、新規性、進歩性等の特許要件について、審査を行うことができない。
　ところで、本願明細書の段落【００２４】を参照すると、s1，s2という、文字列型（string型）の変数をソースコードの中で宣言する際に、それら変数s1,s2に格納される文字列が何語の文字列であるのか（英語か、ドイツ語か、など）を示すEnglish，Germanなどのパラメータを付けて宣言しており、それらs1,s2という変数に対し比較処理やソート（sort）処理を行う記述をソースコード内でコンパイラが発見した場合に、それら変数s1,s2の宣言時にそれらの変数に付けられていた前述のEnglish，Germanなどのパラメータをチェックするというのが本願明細書記載の発明の要点であると見受けられるが、仮に、本願請求項１などの記載が、そのような要点を、不必要に回りくどい表現で記載しているだけのものに過ぎないならば、そのような請求項の進歩性は、拒絶査定時の【附記３】で挙げた【参考文献１】や【参考文献２】の存在によって否定されるものと思料する。
　何故ならば、上記【参考文献１】の第３００頁左コラムの「3.3文字型のパラメタ化」を参照すると、Ｆｏｒｔｒａｎ９０というプログラミング言語では、ＣＨＡＲＡＣＴＥＲ型の変数を宣言する際に、その長さ（ＬＥＮ）と、「日本語」であるか「中国語」であるかなどの文字の種別（ＫＩＮＤ）とを指定して宣言するようになっており、
　
ＣＨＡＲＡＣＴＥＲ（ＫＩＮＤ＝２，ＬＥＮ＝６）：：Ａ
　
という記述がソースコードの中に存在する場合、この記述は、変数Ａが、長さ（文字数）が６で、格納される文字の種別が日本語であるようなＣＨＡＲＡＣＴＥＲ型の変数であるという宣言であることを意味しており、このような変数宣言がＦｏｒｔｒａｎ９０のソースコードの中に記述されていると、その記述を解析したＦｏｒｔｒａｎ９０のコンパイラは、変数Ａをソート（sort）する場合には、日本語の文字の並び順（平仮名やカタカナであれば、あいうえお順、漢字であればＪＩＳ漢字コード順）で処理するのは当然であるし（この点については、原審で挙げた引用文献４の第１９９頁の末尾６行の「ロケール固有の照合シーケンス」に関する技術常識も参照されたい）、また、従来から、データ型の不一致を検出するとコンパイラがエラーメッセージを出すことも技術常識である（例えば、整数型変数と文字列型変数の大小比較処理を行うようなソースコード内の記述がエラーメッセージを引き起こすことは、技術常識である）ので、Ｆｏｒｔｒａｎ９０のソースコードにおいて、日本語の文字列であると宣言されている上述の変数Ａを、中国語や韓国語の文字列と比較するような処理の記述がソースコードの中に存在していれば、Ｆｏｒｔｒａｎ９０のコンパイラがそれを発見してエラーメッセージを発生させるようなことは、当然行うべきことに過ぎないからである（以上、【参考文献１】についてコメントしたが、【参考文献２】についても同様である）。
　したがって、仮に、原査定の理由（理由１〜３）が解消されているものと審判合議体が判断するのであれば、上述の【参考文献１】と【参考文献２】（さらには、先の拒絶理由通知書の【理由６】において挙げた引用文献１〜７）に基づく進歩性の是非についても検討する必要があるものと思料する。」
　
２．６　審尋に対する回答書の意見の概要
　平成２４年６月１８日付けでなされた審尋は、上記前置報告の内容について、審判請求人の意見を求めるものであり、該審尋に対する回答の概略は次のとおりである。
「・・・（中略）・・・
（２）前置報告書において審査官は、平成２４年２月２０日に提出した手続補正書について「特許法第１７条の２第３項の規定に適合しないので、特許法第１５９条第１項において準用する特許法第５３条第１項の規定により、前記手続補正は、審判合議体の手によって却下されるべきものである。」と認定されました。 
  
 （３）そこで、審判請求人は、審査官からの指摘を解消すべく、請求項の記載を下記のように補正を行う用意があります。 
  
［請求項１］ 
　コンピュータを、 
　前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信する型制約受信コンポーネント、 
　前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信する照合制約受信コンポーネントであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する１以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記照合制約に基づき前記データ型が同じ変数同士でそれらが同じまたは互換性を有することを判定する、照合制約受信コンポーネント、および 
　前記型制約および前記照合制約からなり、
前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、
のデータ型
プロパティおよび前記変数のデータ型
にし、前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能
　として機能させるためのプログラムを備えたことを特徴とする型制約システム。 
［請求項２］ 
　前記照合制約は、部分型の関係をサポートするために階層的であることを特徴とする請求項１に記載のシステム。 
［請求項３］ 
　前記照合制約は、前記データ型に言語を指定する言語制約を含むことを特徴とする請求項１に記載のシステム。 
［請求項４］ 
　前記照合制約は、前記言語制約に制約を追加するための文化制約を含むことを特徴とする請求項３に記載のシステム。 
［請求項５］　
　前記照合制約は、前記データ型に時間帯を指定する時間帯制約を含むことを特徴とする請求項１に記載のシステム。　
［請求項６］　
　前記データ型は、ストリングであり、および前記照合制約は、言語に関する制約であることを特徴とする請求項１に記載のシステム。　
［請求項７］　
　前記データ型は、時間に関連し、および前記照合制約は、時間帯に関する制約であることを特徴とする請求項１に記載のシステム。　
［請求項８］　
　前記データ型および照合制約は、弱く型付けされたプログラムから受け取られることを特徴とする請求項１に記載のシステム。　
［請求項９］　
　プログラムされたコンピュータによってデータ制約を生成する方法であって、　
　前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信するステップであって、前記データ型はストリング、または日時のいずれかである、ステップと、　
　前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信するステップであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する１以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型が同じ前記変数同士について、それら変数同士が同じまたは互換性を有することを前記照合制約に基づき判定する、ステップと、　　前記型制約および前記照合制約からなり、
前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、
のデータ型
プロパティおよび前記変数のデータ型
にし、前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能
　を有することを特徴とする方法。　
［請求項１０］ 
　前記照合制約は、言語部分型を指定する文化データを含むことを特徴とする請求項９に記載の方法。 
  
 ・「
前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、
 ・「
前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能
  
 （４）前置報告書に対する意見 
 Ａ．本願明細書の段落［００２３］にあるように、「本発明は、従来技術によって生成される実行時または動的エラーではなく、コンパイル時または静的エラーを生成することができる」ことを特徴とします。すなわち、本願発明は、従来コンパイルの処理完了後に完成したプログラムを実行させている期間中にしかできなかった処理を、コンパイル時に行えるようにしたものです。 
  
 Ｂ．請求項１，９の「前記変数をパラメータ化する」との記載は、本願当初明細書の段落［００３７］の記載に基づき「前記変数
のデータ型
  
 Ｃ．請求項１，９「前記変数の属性を定義するパラメータ」との記載は、は、本願当初明細書の段落［００３７］の「本発明では、従来の理解とまったく対照的に、照合をデータ自体の特性として見ている。」との記載に基づき、「前記変数の
プロパティおよび前記変数のデータ型
  
 　これらのことから、請求項１〜１０に係る発明は、本願当初明細書に記載した事項の範囲内にあるものと思料します。 
  
 （５）以上の通り、審判請求人は、原査定が取り消され、本願発明は特許されるべきものであると思料致しますので、上記意見を参酌の上、審理頂きたく、お願い申し上げます。
・・・（後略）・・・」
　
３．　平成２４年１月１３日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２４年１月１３日付の手続補正を却下する。
［理由］
３．１　本件補正
　平成２４年１月１３日付の手続補正（以下、「本件補正」という。）により、特許請求の範囲の請求項１ないし請求項１０は次のように補正された。
（本件補正後の特許請求の範囲）
　「　【請求項１】
　コンピュータを、
　
前記コンピュータに入力されたデータに含まれる変数の
指定する型制約を受信する
制約
　前記受信した
型制約で指定された
が同じ前記変数同士
制約
制約
制約
に使用する
パラメータ
照合制約に基づき
同じ変数同士でそれらが
を有する
判定
制約
　前記
型制約
制約からなり、前記変数を
するために使用されるデータ制約
前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする
　として機能させるためのプログラムを備えたことを特徴とする型制約システム。
　　【請求項２】
　
前記照合制約は、部分型の関係をサポートするために階層的であることを特徴とする請求項１に記載のシステム
　　【請求項３】
　
前記照合制約は、前記データ型に言語を指定する言語制約を含むことを特徴とする請求項１に記載のシステム
　　【請求項４】
　
前記照合制約は、前記言語制約に制約を追加するための文化制約を含むことを特徴とする請求項３に記載のシステム
　　【請求項５】
　
前記照合制約は、前記データ型に時間帯を指定する時間帯制約を含むことを特徴とする請求項１に記載のシステム
　　【請求項６】
　
前記データ型は、ストリングであり、および前記照合制約は、言語に関する制約であることを特徴とする請求項１に記載のシステム
　　【請求項７】
　
前記データ型は、時間に関連し、および前記照合制約は、時間帯に関する制約であることを特徴とする請求項１に記載のシステム
　　【請求項８】
　
前記データ型および照合制約は、弱く型付けされたプログラムから受け取られることを特徴とする請求項１に記載のシステム
　　【請求項９】
　
プログラムされたコンピュータによってデータ制約を生成する方法であって、
　
前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信するステップであって、前記データ型はストリング、または日時のいずれかである、ステップと、
　
前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信するステップであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する１以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型が同じ前記変数同士について、それら変数同士が同じまたは互換性を有することを前記照合制約に基づき判定する、ステップと、
　
前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するステップであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、ステップと
　
を有することを特徴とする方法
　　【請求項１０】
　前記照合制約は、言語部分型を指定する文化データを含むことを特徴とする請求項９に記載の方法
　
（本件補正前の特許請求の範囲）
「【請求項１】
　コンピュータを、
　データ型を受け取る型受信コンポーネント、
　前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信する照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント、および
　前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって、前記パラメータ化は、１以上のデータ型パラメータを前記データ型に追加することを含む、コンストラクタコンポーネント
　として機能させるためのプログラムを備えたことを特徴とする型制約システム。
　　【請求項２】
　前記データ制約コンポーネントは、インスタンス化されるとデータ型が決まる汎用型と共に採用されて構造型を作成するために用いられることを特徴とする請求項１に記載のシステム。
　　【請求項３】
　前記照合制限は、部分型の関係をサポートするために階層的であることを特徴とする請求項１に記載のシステム。
　　【請求項４】
　前記照合制限は、言語制約コンポーネントを含むことを特徴とする請求項１に記載のシステム。
　　【請求項５】
　前記照合制限は、文化制限コンポーネントを含むことを特徴とする請求項４に記載のシステム。
　　【請求項６】
　前記照合制限は、時間帯を含むことを特徴とする請求項１に記載のシステム。
　　【請求項７】
　前記データ型は、ストリングであり、および前記照合情報は、言語であることを特徴とする請求項１に記載のシステム。
　　【請求項８】
　前記データ型は、時間に関連し、および前記照合情報は、時間帯であることを特徴とする請求項１に記載のシステム。
　　【請求項９】
　前記データ型および照合情報は、弱く型付けされたプログラムから受け取られることを特徴とする請求項１に記載のシステム。
　　【請求項１０】
　プログラムされたコンピュータによってデータ制約を生成する方法であって、
　データ型を受信するステップであって、前記データ型は照合情報が言語であるストリング、または、前記照合情報がタイムゾーンである日時のいずれかである、ステップと、
　前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信するステップであって、前記照合情報は前記データ型のコンパイル時の強い型検査を容易にする１以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、ステップと、
　前記受信したデータ型のデータを比較するための、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するステップであって、前記パラメータ化は、１以上のデータ型パラメータを前記データ型に追加することを含む、ステップと
　を有することを特徴とする方法。
　　【請求項１１】
　前記照合情報は、言語部分型を指定する文化データを含むことを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　前記生成されたデータ制約をインスタンス化されるとデータ型が決まる汎用型のパラメータとして使用する構造型を生成するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
　　【請求項１３】
　プログラムされたコンピュータによるプログラミング言語又はシステム間のマッピング方法であって、
　データ型および前記データ型が関連付けられたデータの照合情報を弱く型付けされた言語またはシステムから受信するステップであって、前記データ型は照合情報が言語であるストリング、又は、前記照合情報がタイムゾーンである日時のいずれかであり、前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、ステップと、
　前記受信したデータ型のデータを比較するための、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するステップであって、前記パラメータ化は、１以上のデータ型パラメータを前記データ型に追加することを含む、ステップと
　を有することを特徴とする方法。
　　【請求項１４】
　前記型および照合情報は、データベースから受け取られ、および前記データ制約コンポーネントを使用して強く型付けされたプログラミング言語にマップされることを特徴とする請求項１３に記載の方法。
　　【請求項１５】
　前記強く型付けされたプログラミング言語は、Ｃ＃、Ｊａｖａ（登録商標）、およびＸｑｕｅｒｙの内の１つを含むことを特徴とする請求項１４に記載の方法。
　　【請求項１６】
　前記マッピングは、システム上の複数の言語を同時にサポートするマルチリンガルシステムを提供することを特徴とする請求項１５に記載の方法。」
　
３．２　本件補正が、特許法第１７条の２第３項の規定に適合するものであるかについて検討する。
（１）本件補正により補正された特許請求の範囲の請求項１（以下、「補正後請求項１」などと呼ぶ。）には「型制約を受信する型制約受信コンポーネント」「照合制約受信コンポーネント」という記載が存在するが、そのような型制約を「受信」する「型制約受信コンポーネント」、照合制約を「受信」することを意味する「型制約受信コンポーネント」は願書に最初に添付した明細書又は図面（以下、「当初明細書等」と呼ぶ。）には記載されておらず自明でもない。即ち、「受信」に関し、図１、図７や段落【００２２】などに「型受信側コンポーネント」「照合情報受信側コンポーネント（照合受信側コンポーネント）」が記載されているが、これらのコンポーネントは制約コンストラクタコンポーネント１３０によってデータ制約コンポーネントが生成される前のコンポーネントであるから、生成されたデータ制約コンポーネントが「受信」を構成として備えることを意味しない。前記データ制約コンポーネントは前記型制約や照合制約を「受信」するコンポーネントとみることはできないので、補正後請求項１の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」は、当初明細書等に記載されたデータ型や前記照合情報を受信する「型受信側コンポーネント」「照合情報受信側コンポーネント」と対応するものでない。また、補正後請求項１の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」が図５、図８、図９や段落【００３５】〜【００３７】、段落【００４４】【００４５】に記載されたデータ制約コンポーネントを含むデータ指定コンポーネントを指すとみても、これらのデータ制約コンポーネントを含むデータ指定コンポーネントは「受信」するものでない。よって、補正後請求項１の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」は、当初明細書等に記載されたものではなく、特許法第１７条の２第３項に規定されている要件を満たさない。
（２）請求項１には、「照合制約受信コンポーネントであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する１以上のパラメータを含み、
前記比較および順序付け操作中
前記コンパイル時の型検査は
判定する
　前記「記載Ａ」の中の「前記比較および順序付け操作中」と記載されているところの「操作中」という期間は、コンパイラが既に処理を済ませて、コンパイラの出力を用いたリンク処理（技術常識）なども済み、そうして最終的に完成したプログラムを動作させている期間とみることができ、そうすると、この「操作中」という期間の開始時点においては、コンパイラの処理は、既に終了している。
　一方、前記「記載Ａ」の中の「前記コンパイル時の型検査は・・・判定する」という「判定」処理は、コンパイラがソースコードをコンパイル処理している最中に行われる処理である。
　したがって、前記「記載Ａ」は、コンパイラがコンパイル中に行う「判定」処理が、コンパイラの処理完了後に完成したプログラムを実行させている期間中に、行われるという趣旨の、時間的な前後関係が矛盾した記載になっており、そのような矛盾した記載は、当初明細書等には記載されておらず自明でもない。よって、特許法第１７条の２第３項に規定されている要件を満たさない。
　補正後請求項９は、カテゴリが「方法」の発明に係るが、補正後請求項１の「システム」と実質同じ事項を備えており、前記補正後請求項１と同様のことがいえる。補正後請求項１、９を引用するその他の請求項についても同様のことがいえる。
　
（３）補正後請求項１の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、特に「変数をパラメータ化する」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【００２３】、【００３７】を挙げているが、それら段落【００２３】、【００３７】には、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもない。
　したがって、このような記載を含む審判請求時の手続補正は、特許法第１７条の２第３項の規定に適合しない。補正後請求項９についても同様のことがいえる。補正後請求項１、９を引用するその他の請求項についても同様のことがいえる。
　
（４）補正後請求項１の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、「前記変数の属性を定義するパラメータ」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【００１２】、【００１３】、【００３７】を挙げているが、それら段落【００１２】、【００１３】、【００３７】には、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく（そもそも、「変数」の「属性」などというもの自体、当初明細書等のどこにも記載されておらず自明でもなく）、したがって、このような記載を含む審判請求時の手続補正は、特許法第１７条の２第３項の規定に適合しない。
　補正後請求項９についても同様のことがいえる。補正後請求項１、９を引用するその他の請求項についても同様のことがいえる。
　
　（なお、回答書の補正案には、例えば、その請求項１に「照合制約によってパラメータ化」「自動的に」「変数のプロパティ」（段落【００３７】の「照合をデータ自体の特性として見ている」における特性から「プロパティ」が示唆されるとしても前記照合、特性は「変数のプロパティ」までも示唆するものではない。）といった事項が記載されており、これらの事項は当初明細書等に記載されておらず、自明な事項でもなく、結果的に前記補正案により新たな不明確な事項を導入するものとみることができるので、回答書の補正案は採用することはできない。）
　
３．３　むすび
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項の規定によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、上記補正却下の決定の結論のとおり決定する。
　
４．本件審判請求について
（１）平成２４年１月１３日付の手続補正は前記のとおり却下されたので、本願の請求項１〜１６は、平成２３年７月２２日付の手続補正書により補正された特許請求の範囲の請求項１〜１６に記載されたとおりのものである。（３．１の特許請求の範囲の請求項１〜請求項１６参照。以下「本願請求項１」「本願請求項２」などという。）
　
（２）そこで、原査定（拒絶理由通知で示した理由１〜３によって拒絶すべきものであるとした点）が妥当なものであるか否かを検討する。あわせて、原査定において、前記平成２３年７月２２日付の手続補正書による補正により、新たに【理由Ａ】ないし【理由Ｄ】の拒絶の理由が発生しているとしているので、この【理由Ａ】ないし【理由Ｄ】で指摘した点も検討する。
　
（２．１）理由１について（特許法第３６条第６項第２号）
　本願請求項１には、「照合情報」について、「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載（以下、便宜的に「記載ＡＡ」という。）と、「前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み」という記載（以下、便宜的に「記載ＢＢ」という。）とが存在するが、これら記載ＡＡ及び記載ＢＢは、以下の（２．１．１）の点が不明であり、このような記載ＡＡ及び記載ＢＢを伴う本願請求項１の「照合情報」という用語は依然として明確ではない。したがって、本願請求項１の記載は、依然として明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備が、依然として解消されていない。
　
（２．１．１）記載ＡＡは、「データ型」と「データ」を「比較および順序付けする」という趣旨の記載であるが、「データ型」と「データ」を「比較」するとは如何なる比較を意味するのか技術的意味が不明であり、また、「データ型」と「データ」を「順序付けする」も如何なる技術的意味であるのかも不明である。
　また、記載ＢＢには、型検査を「容易」にするという趣旨の記載があるが、「容易」か否かの判断基準が何であるのか不明である。
（２．１．２）理由１の（３）として指摘した「照合制限」という用語の定義が不明であり、明細書にはその定義を説明する記載もなく、この記載不備は解消されていない。本願請求項３〜６の「照合制限」という用語の定義は不明である。
（２．１．３）理由１の（４）として指摘した記載不備が、依然として解消されていない。本願請求項１には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載は、「データ制約コンポーネント」は、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」を「含む」という趣旨の記載である。ここで、「前記照合情報」の「前記」とは本願請求項１に記載された「前記照合情報は・・・１以上のデータ型パラメータを含」む照合情報であるから、これらの記載における「照合情報」と「照合情報によってパラメータ化された変数」と「データ型パラメータ」との関係において、「変数」である「データ型パラメータ」との記載からして「データ型パラメータ」は「変数」のことであり、「データ型パラメータを含」む「照合情報」との記載からして「データ型パラメータ」と「照合情報」とは同じものがあることを意味する。あわせると、「照合情報」「データ型パラメータ」「変数」は同じであることを含むことになり、特に「パラメータ化」「変数」なる記載が特定事項として如何なる技術的意味をもつのか不明にするものであり、前記「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」は明確でないことになる。
　請求人は、平成２３年７月２２日付け意見書の「（４）補正の説明」の項において、請求項１は段落【００２２】【００３５】【００３７】【００４０】の記載に基づく旨主張しているが、当該段落には、少なくとも「変数」（データプレースホルダ（つまり変数））（段落【００２５】【００２６】参照）は記載されていないので、補正の根拠が不明であるが、変数はデータプレースホルダ（つまり変数）であるから「照合情報」「データ型パラメータ」とは種類が異なる情報（例えば、汎用化レベルが異なるカテゴリの情報等）であり、前記本願請求項１の前記同じものであることを意味する内容と矛盾する。また、「データ型パラメータ」は、明示的には当初明細書等の請求項１７に「前記照合制約は、データ型パラメータである」ことは記載されているが、前記段落には記載されていない。
　
　以上（２．１．１）ないし（２．１．３）で指摘した記載不備が依然として解消されていないので、本願請求項１〜１６の記載は、依然として明確ではない。
　
（２．２）理由２について（特許法第３６条第６項第１号）
（２．２．１）理由２の（２）として指摘した記載不備が、依然として解消されていない。補正後の請求項３〜６には依然として「照合制限」という記載が存在するが、そのようなものは、発明の詳細な説明には記載されていない。
　同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
　　　　　　　　　　　　　　　　　　　　　
（２．３）理由３について（特許法第３６条第４項第１号）
（２．３．１）理由３の（１）として指摘した記載不備が、依然として解消されていない。上記「（１）理由１について」及び上記「（２）理由２について」で指摘した本願請求項１〜１６の中の記載箇所の記載の具体的な実現手法が、下記ア．〜エ．の点で、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
ア．本願請求項１の「受信したデータ型とデータを比較および順序付けする」は如何にしてデータ型とデータを比較および順序付けするのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
イ．本願請求項１の「照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータを含み」における当該「容易にする」なる構成は、「照合情報」と「データ型パラメータ」とが如何なる対応関係にあり、「パラメータ化」された「変数」を構成とすることもなく如何なるメカニズムを用いることにより「容易にする」構成なのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
ウ．本願請求項１の「前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント」は、「照合情報受信コンポーネント」に係る構成であるから、図１〜図３のブロックないし、図７のフロー、及びこれらに関連する明細書の説明が対応づけられると解されるが、前記「操作中」とはどのブロックないしフローの部分が対応していて発明の詳細な説明のどこに記載されているのか、また、当該「操作中」に、「前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント」とは、操作中に如何なるメカニズムによりどのような手順で「確実にする」ことをすれば成されるのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。段落【００３５】には「型チェッカコンポーネント５３０は、データ指定コンポーネント５１０および５２０の両方を分析して、そのデータ制約が満たされ、コンポーネントが互換であることを確実にする。」ことが記載されているが、この「確実にする」はデータ指定コンポーネント５１０および５２０の両方を分析して、この分析の結果、互換を確実にするものであるから、この段落に記載された事項は、本願請求項１のように、分析する構成を備えずに確実にするものではなく、「前記照合情報受信コンポーネントであって、」「前記比較および順序付け操作中に、」なる構成に於けるものではないから、本願請求項１の前記事項の具体的な実現手法に対応付けることはできないものである。
エ．本願請求項１の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」は、「照合情報によってパラメータ化された前記データ型の変数」である「前記データ型パラメータ」（「照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする１以上のデータ型パラメータ」における当該「データ型パラメータ」）を意味するが、このような「パラメータ化された」「変数」である「データ型パラメータ」の、具体的な実現手法（少なくとも「データ型パラメータ」すら発明の詳細な説明に記載も示唆もない。）が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。　
　
　したがって、本願の発明の詳細な説明の記載は、請求項１〜１６に係る発明について、当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。
　よって、本願は、依然として、特許法第３６条第４項第１号に規定する要件を満たしていないものであるとした、原査定は妥当なものである。
　
４．むすび
　以上のとおり、依然として、本願は、発明の詳細な説明及び特許請求の範囲の記載が不備であり、特許法第３６条第４項第１号並びに特許法第３６条第６項第１号及び第６項第２号に規定する要件を満たしていないとする拒絶理由は解消されていない。
　したがって、本願は、前記の拒絶理由によって拒絶すべきものであるとした原査定は妥当なものであり、これを取り消すことはできない。
 
　よって、結論のとおり審決する。