• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G06F
審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 G06F
管理番号 1281218
審判番号 不服2012-746  
総通号数 168 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-12-27 
種別 拒絶査定不服の審決 
審判請求日 2012-01-13 
確定日 2013-11-06 
事件の表示 特願2005-214303「組み込み照合情報を備えるデータ型」拒絶査定不服審判事件〔平成18年 3月 9日出願公開、特開2006- 65848〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
1.1 手続の経緯の概略
本件の手続の経緯は概略以下の通りのものである。
出願 平成17年7月25日
(優先権主張日2004年8月25日,米国)
拒絶理由通知 平成23年4月19日
意見書及び手続補正書 平成23年7月22日
拒絶査定 平成23年9月8日
同謄本送達 平成23年9月13日
審判請求 平成24年1月13日
手続補正書 平成24年1月13日
前置報告書 平成24年6月18日
審尋 平成24年8月29日
回答書 平成24年12月4日

2.1 原審拒絶理由の概要
「【理由1】この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。



(1)請求項1の「照合情報」という用語の定義が不明であり、請求項1の記載は明確ではない(明細書段落【0022】には、「一般に、照合情報は、データを正しく比較するために必要とされる任意の情報である」という記載が存在するが、「任意の情報」という記載は曖昧であり、また、「データを正しく比較するために必要とされる」情報という記載も、曖昧である(このような曖昧なことを言っているのであれば、従来から存在するintやcharなどの変数の型も、「データを正しく比較するために必要とされる」情報であると言えるから、そのような従来から存在する変数の型と、請求項1の「照合情報」とでは、何が違うのかも不明である)。また、「一般に」というのは、例外が存在することを示唆する表現であるから、「一般に、照合情報は、データを正しく比較するために必要とされる任意の情報である」という文章は、「照合情報」は、「データを正しく比較するために必要とされる任意の情報である」のが一般的だが、必ずしもそうでなくても限らないという趣旨の文章表現であり、すると、「必ずしもそうでなくても限らない」場合の「照合情報」とは何であるのか皆目不明である。したがって、明細書の記載を参照しても、請求項1の「照合情報」という用語の定義は不明である)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(2)請求項1の「型制限」という用語の定義が不明であり、請求項1の記載は明確ではない(明細書を参照しても、「型制限」という用語の定義を説明する記載は存在していない。また、「型制限」に類似した用語で、「型制約」という用語は明細書の中に記載されているが、この「型制約」という用語の定義も不明である)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(3)請求項1の「照合制限」という用語の定義が不明であり、請求項1の記載は明確ではない(明細書を参照しても、「照合制限」という用語の定義を説明する記載は存在していない。また、「照合制限」に類似した用語で、「照合制約」という用語は明細書の中に記載されているが、この「照合制約」という用語の定義も不明である)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(4)請求項1には「型制限および照合制限を含むデータ制約コンポーネント」という記載が存在するが、この記載における「データ制約コンポーネント」は、「型制限」および「照合制限」を「含む」と記載されているものの、「データ制約コンポーネント」とはそもそも何なのか不明である(何らかのプログラムであるのか、あるいは、制限条件や制約条件を列挙しただけのデータに過ぎないのか、或いは、段落【0015】に「LIST<String<eng>>」と記載されているような単なる文字列に過ぎないのか、いずれであるのか不明であり、また、仮に、「データ制約コンポーネント」が何らかのプログラムであると仮定しても、如何なる処理を行うプログラムであるのかも不明である)。したがって請求項1の記載は明確ではない(用語の定義を明確にされたい)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(5)請求項2には「前記照合制限は、前記データ型に組み込まれる」という記載が存在するが、「照合制限」が「データ型」に「組み込まれる」とは如何なる意味であるのか不明であり、請求項2の記載は明確ではない(なお、請求項2の「照合制限」を「照合制約」と補正しても、それだけでは、ここで指摘されている記載不備は解消されないので、注意されたい)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(6)請求項3には「前記型は、前記照合情報によってパラメータ化される」という記載が存在するが、「型」が「照合情報」によって「パラメータ化」されるとは如何なる意味であるのか不明であり、請求項3の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(7)請求項4には「前記データ制約コンポーネントは、type<collationinformation>の形式である」という記載が存在するが、この記載は、以下の(7-1)?(7-3)の点が不明であり、請求項4の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
(7-1)「type<collationinformation>」という記載の意味するところが不明である。
(7-2)「データ制約コンポーネント」の「形式」とは、何のことであるのか意味するところが不明である。
(7-3)「type<collationinformation>」というのは文字が並んだもの(sequenceofcharacters)に過ぎないが、「コンポーネント」が、そのような「文字が並んだもの」の「形式」であるとは如何なる意味であるのか意味不明である(文章表現を再考されたい)。

(8)請求項5の「汎用型と共に採用されて構造型を作成する」という記載の意味するところが不明であり、請求項5の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(9)請求項6の「照合部分型」という用語の定義が不明であり、請求項6の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(10)請求項10には「前記データ制約コンポーネントは、パラメータ化された型である」という記載が存在するが、この記載の意味するところが不明であり、請求項10の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(11)請求項12の冒頭には「前記データ型」という記載が存在するが、請求項12が引用する請求項1には「型」という記載は存在するが、「データ型」という記載は存在していないので、請求項12の冒頭の「前記データ型」という記載は矛盾しており、請求項12の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

以上(1)?(11)として指摘したとおりであるので、請求項1?13の記載は明確ではない。
(以上、理由1)

【理由2】この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。



(1)請求項1には「型制限」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(2)請求項1には「照合制限」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(3)請求項6には「照合部分型」という記載が存在するが、そのようなものは発明の詳細な説明には記載されていない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

以上(1)?(3)として指摘したように、請求項1?13の記載は、発明の詳細な説明の記載と対応していないので、請求項1?13として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない(なお、請求項の記載が発明の詳細な説明の記載と対応しないという当方からの上述の指摘に反論がある場合には、対応する記載が存在する明細書内の記載箇所(段落番号、段落内の文番号)を具体的に特定して、意見書で対応関係を説明するようにされたい)。

【注意1】
(1)明細書の中には、請求項の中の記載を形式的に反復して記載しているに過ぎない記載箇所が存在するが、そのような明細書中の記載箇所と、請求項の記載との間に形式的な対応関係が存在するだけでは不十分であり、明細書の【発明を実施するための最良の形態】の中に記載されている具体的な構成と対応することが必要であるから、注意して対処されたい(審査基準第I部第1章(明細書及び特許請求の範囲の記載要件)の2.2.1(2)の「表現上の整合性にとらわれることなく、実質的な対応関係について審査する」という記載参照)。
(2)特許請求の範囲の記載様式は、特許法施行規則の「様式29の2」にて規定されており、この「様式29の2」の[備考]の9には、用語は、明細書及び特許請求の範囲全体を通じて統一して使用することが規定されているので、この規定を遵守するようにされたい。
(以上、理由2)

【理由3】この出願は、発明の詳細な説明の記載が下記の点で、特許法第36条第4項第1号に規定する要件を満たしていない。



(1)上記【理由1】及び【理由2】において指摘した請求項1?13の中の記載箇所の記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。

(2)請求項1には「受け取った型および照合情報を使用して、型制限および照合制限を含むデータ制約コンポーネントを生成する」という記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。「受け取った型および照合情報」に対して、具体的にどのようなアルゴリズムに基づく演算を施すと、「型制限および照合制限を含むデータ制約コンポーネント」が生成されるのか不明である(なお、ここで指摘されている記載不備は、請求項1の「型制限」、「照合制限」という用語を、「型制約」、「照合制約」と補正しても、それだけでは解消されないので、注意されたい)。
例えば、「受け取った型」が「STRING型」で、「照合情報」が「スペイン語」であった場合、前記「STRING型」という情報と、前記「スペイン語」という情報とに対し、具体的にどのようなアルゴリズムに基づく演算を施すと、具体的にどのような内容の「型制限および照合制限を含むデータ制約コンポーネント」が生成されるのか、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない(図2や図3のような箱形の記号が並んだ模式図を見せられても、その中身が具体的に何であるのかは不明であり、また、その中身を具体的にどのようなアルゴリズムに基づいて生成するのかも不明である)。したがって、請求項1記載の発明は実施できない。同様の記載を有するその他の請求項に記載されている発明も、同様に実施できない。

よって、この出願の発明の詳細な説明は、当業者が請求項1?13に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。

【注意2】
明細書の中には、請求項の中の記載を形式的に反復して記載しているに過ぎない記載箇所が存在するが、そのような記載箇所の記載は、単なる願望が抽象的に記載されているだけであり、具体的な実現手法を説明する記載であるとは認められない。
(以上、理由3)

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


・請求項1?13
引用文献:
1.米国特許第5696973号明細書
2.BjarneStroustrup著,長尾高弘訳,「プログラミング言語C++ 第3版」,初版,1998年11月30日,アジソン・ウェスレイ・パブリッシャーズ・ジャパン株式会社,第63?64頁,ISBN:4-7561-1895-X
3.米国特許出願公開第2002/0174100号明細書
4.「IBMCloudscape リファレンス・マニュアル バージョン5.2 SC88-9909-00(英文原典SC18-7585-01)」,第1刷,2003年12月,日本アイ・ビー・エム株式会社,第199?200頁
5.「VisualAgeC++forWindows 使用者の手引き バージョン3.5 SB88-7180-00(英文原典S33H-5031-00)」,第1刷,1996年7月,日本アイ・ビー・エム株式会社,第651?660頁
6.浅海智晴,「Javaデザインノート 第12回 Webデータ・タイプ」,JAVAWORLD,2001年6月号(第5巻第6号),2001年6月1日,(株)IDGジャパン,第110?122頁7.社団法人情報処理学会,「新版 情報処理ハンドブック」,第1版,1995年11月25日,株式会社オーム社,第650頁,ISBN:4-274-07832-9
備考:
引用文献1は、第1頁の"ABSTRACT"の記載、第1コラム第9?36行、同コラム第51行?第2コラム第第26行、第3コラム第55行?第4コラム第15行、同コラム第47?53行、第5コラム第第29?33行、第10コラム第19?49行、第12コラム第41?52行の記載(特にsubtypeに関する記載)に、特に注意されたい。
引用文献2は、「ユーザー定義型」に関する記載に、特に注意されたい。
引用文献3は、第1頁の"ABSTRACT"内の"culturallysensitivesorting","localespecificationhavingcollationinfromationofaculture","localetoken"に関する記載に特に注意されたい。
引用文献4は、「ロケール固有の照合シーケンス」という表題の付いた段落の記載に特に注意されたい。
引用文献5は、第651頁中段の「カスタム・データ型の作成」という記載、第653頁の後半の「可変情報ブロック」の「langID」、「charsetID」に関する記載、第656頁の図表(langIDの詳細を説明する図表である)の中の「標準スペイン語」、「メキシコのスペイン語」という記載、第657頁の図表(charsetIDの詳細を説明する図表である)の中の「日本語」、「ギリシャ語」、「トルコ語」、「ヘブライ語」、「アラビア語」という記載に、特に注意されたい。
引用文献6は、第115頁の「表3:SQLのデータ・タイプ」という表の中の「TIME」、「TIMESTAMP」、「TIMEWITHTIMEZONE」、「TIMESTAMPWITHTIMEZONE」という記載と、第120頁の「表9:時間型のマッピング」という記載に、特に注意されたい。
引用文献7は、第650頁左コラムの下から15行目?同頁右コラム第15行の記載(弱く型付けされた言語では、それぞれのデータが自分の属する型の情報を内部に保持している旨の記載)に、特に注意されたい。
・・・(後略)・・・ 」

2.2 原審拒絶理由に対する意見書、補正書の概要
2.2.1意見書の概要
「・・・(中略)・・・
(2)出願人は、かかる拒絶理由に鑑み、別途提出の手続補正書により本願の特許請求の範囲を補正し、本願発明の要旨をより一層明確にするとともに、以下のように意見を申し述べる次第です。
(3)本願発明の要旨とするところは、補正した特許請求の範囲の記載より明らかなように、請求項1に記載の発明は、
「コンピュータを、
データ型を受け取る型受信コンポーネント、
前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信する照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント、および
前記データ型および前記照合情報に基づき、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって、前記パラメータ化は、1以上のデータ型パラメータを前記データ型に追加することを含む、コンストラクタコンポーネント
として機能させるためのプログラムを備えたことを特徴とする型制約システム」
です。
(4)補正の説明
請求項1,11,14は、本願当初明細書の段落[0022]、[0035]、[0037]、[0040]の記載に基づくものです。
請求項2,13は、補正前の請求項5,25と本願当初明細書の段落[0041]の記載に基づくものです。
請求項3?9,12,15?17は、補正前の請求項6?12,23,36,37,39に基づくものです。
請求項2?4,10,14?18,20?22,24,26?33,35,38,40は削除しました。
(5)理由1,2について
・「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」とし、照合情報を明確にしました。
・「前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネント」とし、データ制約コンポーネントを明確にしました。
・請求項3に記載の「部分型」は、本願当初明細書の段落[0027]の記載に基づくものです。
(6)理由3について
本願当初明細書の表3?6に記載されているように、データ型をさらに詳細に表現するためにデータ型の直後の<>内にパラメータ化した照合情報を記述することは当業者にとって明らかであると思料します。また、図7?9のフローチャートで示された手順によってデータ制約が生成できることも当業者が十分理解できるものと思料します。
(8)理由4について
コンピュータによって各機能、ステップが実現されることを明確にしました。
(9)理由5,6について
本願発明は、照合情報をパラメータ化してインスタンスではなくデータ型に組み込むことによってコンパイル時にエラーを発見できる強い型検査が可能にすることを特徴とします。
しかしながら、引用文献1?7には、データ型に組み込むことができるパラメータ化された照合情報、および、インスタンス化してからの照合をしなくても強い型検査が可能であることについては開示していません。
引用文献2,5には、「ユーザ定義型」や「カスタム・データ型」などの固有のデータ型を作成するための構成が開示されていますが、これらを使用して強い型検査を可能する構成については開示されていません。
よって、本願発明は、引用文献1?7に開示されていない固有の技術的特徴を有し、当業者が引用文献1?7から容易に発明できたものではないと思料します。
・・・(後略)・・・」

2.2.2 補正書
(略) 3.1の(本件補正前の特許請求の範囲)参照。

2.3 拒絶査定の概要
「 この出願については、平成23年4月19日付け拒絶理由通知書に記載した理由1?3によって、拒絶をすべきものです。
なお、意見書及び手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。

備考
(1)理由1について
(1-1)理由1の(1)として指摘した記載不備が、依然として解消されていない。補正後の請求項1の中には、「照合情報」という単語を修飾する修飾句として、「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載(以下、便宜的に「記載A」という。)と、「前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み」という記載(以下、便宜的に「記載B」という。)とが存在するが、これら記載A及び記載Bは、以下の(1-1-1)及び(1-1-2)の点が不明であり、このような不明瞭な修飾句であるところの前記記載A及び前記記載Bを伴う補正後の請求項1の「照合情報」という用語は依然として明確ではない。したがって、補正後の請求項1の記載は、依然として明確ではない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。

(1-1-1)前記記載Aは、「データ型」と「データ」を「比較および順序付けする」という趣旨の記載であるが、「データ型」と「データ」を「比較」するとは如何なる意味であるのか不明であり、また、「データ型」と「データ」を「順序付けする」とは如何なる意味であるのかも不明である。
(1-1-2)前記記載Bには、型検査を「容易」にするという趣旨の記載があるが、「容易」か否かの判断基準が何であるのか不明である(審査基準第I部第1章(明細書及び特許請求の範囲の記載要件)の2.2.2.1(5)の3番目の項目参照)。

(1-2)理由1の(3)として指摘した記載不備が、依然として解消されていない。補正後の請求項3?6の「照合制限」という用語の定義が依然として不明である。

(1-3)理由1の(4)として指摘した記載不備が、依然として解消されていない。補正後の請求項1には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載は、「データ制約コンポーネント」は、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」を「含む」という趣旨の記載であるが、そもそも「データ制約コンポーネント」とは何なのか、依然として不明である(何らかのプログラムであるのか、あるいは、制限条件や制約条件を列挙しただけのデータに過ぎないのか、或いは、段落【0015】に「LIST<String<eng>>」と記載されているような単なる文字列に過ぎないのか、いずれであるのか依然として不明であり、また、仮に、「データ制約コンポーネント」が何らかのプログラムであると仮定しても、如何なる処理を行うプログラムであるのかも依然として不明である)。また、補正後の請求項1の上述の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載の中の「前記照合情報によってパラメータ化された前記データ型の変数」という記載も、その意味するところが不明である(「パラメータ化された」は、「データ型」に係るのか、「変数」に係るのか、文章の係り受け構造が不明であり、また、係り受け構造の解釈をどちらに解釈しても、照合情報によって「パラメータ化」されるとは、如何なる意味であるのかも不明である)。
したがって、補正後の請求項1の記載は、依然として明確ではない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。

(1-4)理由1の(6)として指摘した記載不備が、依然として解消されていない。補正後の請求項1には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載には、「データ型」が「照合情報」によって「パラメータ化」されるという趣旨に解釈可能な記載が依然として存在しており、その意味するところが依然として不明である。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。

(1-5)理由1の(8)として指摘した記載不備が、依然として解消されていない。補正後の請求項2には「汎用型と共に採用されて構造型を作成する」という記載が依然として存在しており、その意味するところが依然として不明である。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。

以上(1-1)?(1-5)で指摘した記載不備が依然として解消されていないので、補正後の請求項1?16の記載は、依然として明確ではない。
(以上、理由1について)

(2)理由2について
(2-1)理由2の(2)として指摘した記載不備が、依然として解消されていない。補正後の請求項3?6には依然として「照合制限」という記載が存在するが、そのようなものは、依然として、発明の詳細な説明には記載されていない。同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。
(以上、理由2について)

(3)理由3について
(3-1)理由3の(1)として指摘した記載不備が、依然として解消されていない。上記「(1)理由1について」及び上記「(2)理由2について」で指摘した補正後の請求項1?16の中の記載箇所の記載の具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。

(3-2)理由3の(2)として指摘した記載不備が、依然として解消されていない。指摘を受けていた請求項1の記載は、補正後の請求項1では、

「前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成する」

という記載(以下、便宜的に「記載C」という。)に変わったが、この記載Cの具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
前記記載Cは、「前記データ型および前記照合情報」を「使用」して、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」を「生成」するという趣旨の記載であるが、「前記データ型および前記照合情報」に対して、具体的にどのようなアルゴリズムに基づく演算を施すと、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」が生成されるのか、依然として不明である。
例えば、「データ型」が「STRING型」で、「照合情報」が「スペイン語」であった場合、前記「STRING型」という情報と、前記「スペイン語」という情報とに対し、具体的にどのようなアルゴリズムに基づく演算を施すと、具体的にどのような内容の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」が生成されるのか、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない(図2や図3のような箱形の記号が並んだ模式図を見せられても、その中身が具体的に何であるのかは依然として不明であり、また、その中身を具体的にどのようなアルゴリズムに基づいて生成するのかも依然として不明である)。
なお、意見書において出願人は、

「(6)理由3について
本願当初明細書の表3?6に記載されているように、データ型をさらに詳細に表現するためにデータ型の直後の<>内にパラメータ化した照合情報を記述することは当業者にとって明らかであると思料します。また、図7?9のフローチャートで示された手順によってデータ制約が生成できることも当業者が十分理解できるものと思料します。」

という説明を行っているが、この説明の中で用いられている用語と、前記記載Cの中で用いられている用語とは異なっており、当該説明の中には、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」などという記載は存在していないので、意見書の前記説明は、補正後の請求項1の前記記載Cと何の関係があるのか不明であり、このような説明を参照しても、補正後の請求項1の前記記載Cの、「前記データ型および前記照合情報」を「使用」して、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」を「生成」するという趣旨の記載の具体的な実現手法は不明である(なお、用語は統一して用いるようにされたい)。
したがって、補正後の請求項1記載の発明は依然として実施できない。同様の記載を有するその他の補正後の請求項に記載されている発明も、同様に、依然として実施できない。
(以上、理由3について)
---------------------------------
【附記1】
今回した補正によって、新たに以下の【理由A】乃至【理由D】の拒絶理由が発生している。

【理由A】特許法第36条第6項第2号違反
(1)請求項1には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在し、この記載は、「データ型」が「データ型パラメータ」を「含む」という趣旨の記載であるが、その意味するところが不明であり、請求項1の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(2)請求項1には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在するが、「確実」か否かの判断基準が不明であり、請求項1の記載は明確ではない(審査基準第I部第1章(明細書及び特許請求の範囲の記載要件)の2.2.2.1(5)の3番目の項目参照)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(3)請求項1の「前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって」という記載は文章の係り受け構造が不明であり、

(3-1)「前記データ型パラメータ」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、
(3-2)「前記データ型パラメータを含むデータ制約コンポーネント」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、
(3-3)「前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネント」が、「前記照合情報によってパラメータ化された前記データ型の変数」であるという趣旨、

のいずれの趣旨であるのか不明であり、請求項1の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(4)請求項1の「データ型パラメータ」という用語の定義が不明であり、請求項1の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。

(5)請求項3、4、6には「前記照合制限」という記載が存在するが、請求項3、4、6ににも、請求項3、4、6が引用する請求項1にも「照合制限」などというものは「前記」されていないので、請求項3、4、6の「前記照合制限」という記載は矛盾しており、したがって、請求項3、4、6の記載は明確ではない。

(6)請求項10には「データ制約を生成する」という記載と、「データ制約コンポーネントを生成する」という記載とが存在するが、これら2つの記載の関係が不明である(同じものを指すのであれば用語を統一すべきであるし、別のものを指すのであれば両者の関係や両者の違いが明確になるように請求項10を記載されたい)。同様の記載を有するその他の請求項についても、同様の記載不備がある。

以上(1)?(6)として指摘したとおりであるので、請求項1?16の記載は明確ではない。
(以上、理由A)

【理由B】特許法第17条の2第3項違反
(1)補正後の請求項1には「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載が存在し、この記載は、照合情報とは、「データ型」と「データ」を「比較および順序付けする」ために使用する情報であるという趣旨の記載であるが、そのようなことは願書に最初に添付した明細書、願書に最初に添付した特許請求の範囲、願書に最初に添付した図面(以下、これら三者を便宜的に「当初明細書等」と総称する。)に記載した事項の範囲内のものではない。当初明細書の段落【0040】には、「照合情報は、一般にデータを比較および/または順序付けするために必要なデータを含んでいる」という記載が存在するが、この記載は、「照合情報」とは、「データ」同士を「比較および/または順序付けする」ために用いられるという趣旨の記載に過ぎず、「データ型」と「データ」を比較や順序付けするために用いられるなどということは、記載されておらず自明でもない(また、常識的に考えても、例えば、段落【0024】で、Strings1;と、Strings2;というように変数を宣言する記述がソースコード中にある場合、コンパイラは、という記述同士を比較してコンパイル時に型チェックを行い、また、コンパイラによって生成されたオブジェクトモジュールは、実行時には変数に格納されているデータ同士を比較したり順序付けしたりすると考えるのが当然であり、変数に格納されるデータの内容と、という記述とを比較したり、変数に格納されるデータの内容と、という記述とを順序付けたりするなどというナンセンスな処理を行う筈が無い(英文のクレームを日本語のクレームに翻訳する際に翻訳ミスが発生している可能性もあるので、注意されたい))。
同様の記載を有するその他の補正後の請求項についても、同様に、当初明細書等に記載した事項の範囲内のものではない。

(2)補正後の請求項1には「前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする」という記載が存在し、この記載は、「データ型」が「データ型パラメータ」を「含む」という趣旨の記載であるが、そのようなことは、当初明細書等に記載した事項の範囲内のものではない。
同様の記載を有するその他の補正後の請求項についても、同様に、当初明細書等に記載した事項の範囲内のものではない。

以上(1)、(2)として指摘したとおりであるので、補正後の請求項1?16についてした補正は、当初明細書等に記載した事項の範囲内のものではない。
(以上、理由B)

【理由C】特許法第36条第6項第1号違反
(1)上記【理由B】で指摘した請求項1?16の中の記載は、発明の詳細な説明の記載と対応しないので、請求項1?16に記載の発明は、発明の詳細な説明に記載した発明ではない。
(以上、理由C)

【理由D】特許法第36条第4項第1号違反
(1)上記【理由A】乃至【理由C】で指摘した請求項1?16の中の記載箇所の記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
(以上、理由D)
----------------------------------
【附記2】
先の拒絶理由通知書において【注意1】、【注意2】、【注意4】として説示した注意事項は、現時点においても引き続き有効であるので、審判請求を行うのであれば、その際には、それらの注意事項を遵守するようにされたい。
---------------------------------
【附記3】
上記「(1)理由1について」、 上記「(2)理由2について」、 上記「(3)理由3について」及び上記【理由A】乃至【理由D】で指摘した記載不備の程度の悪さが著しいので、現時点では、請求項1?16については、新規性進歩性等の特許要件についての審査を行っていない(行うことができない)。請求項1?16に新規性進歩性が有ると認めているわけではないので、誤解の無いように注意されたい。
なお、現時点において、以下の【参考文献1】及び【参考文献2】の存在を把握しているので、参考までにお知らせしておく。
上述の如く、記載不備があるために、現時点では進歩性の審査を厳密に行うことができない状態であるが、例えば以下の【参考文献1】の第300頁左コラムの「3.3 文字型のパラメタ化」というセクションには、変数Aを宣言する表記法として、

CHARACTER(KIND=2LEN=6)::A

という表記法(CHARACTERという記述が、変数Aが文字型であることを宣言し、KIND=2という記述が、変数Aには日本語の文字が格納されることを宣言するという表記法)が例示されているが、この記載のうち、「CHARACTER」という文字列をキーボードから受け取る手段が本願請求項1の「型受信コンポーネント」に対応し、「KIND=2」という文字列をキーボードから受け取る手段が本願請求項1の「照合情報受信コンポーネント」に対応し、受け取った前記「CHARACTER」という文字列と、前記「KIND=2」という文字列とをくっつけてFORTRAN90のソースコードの中に書き込む手段が本願請求項1の「コンストラクタコンポーネント」に対応するという対応付けも可能ではないかと審査官は考えていることを、参考までに申し述べておく(なお、コンパイラがソースコード内で宣言された変数の型に基づいてコンパイル時に変数の型チェックを行うのは当然であるから、上述の如く、「CHARACTER(KIND=2LEN=6)::A」という宣言をソースコード内で発見したコンパイラは、「CHARACTER」という変数の型と、「KIND=2」という文字種(日本語)という型との両方のチェックを行うのは当然のことである)。

【参考文献1】
和田英穂,「プログラミング言語最新情報-II4.新しいFortran-Fortran90-」,情報処理,1995年4月号(第36巻,第4号),社団法人情報処理学会,1995年4月15日,第297?303頁,ISSN:0447-8053(特に、第300頁左コラムの「3.3 文字型のパラメタ化」というセクションの中の「文字型に種別パラメタが追加され」という記載に注意)

【参考文献2】
高田正之,「Fortran90の概要」,bit,1993年12月号(通巻第327号),共立出版株式会社,1993年12月1日,第23?30頁,ISSN:0385-6984(特に、第26頁右コラムの「5.その他の新機能」というセクションの中の、「型パラメタという概念ができた」、「種別(kind)パラメタが加わった」、「数値型では精度や範囲の違い、文字型では字種の違いを表すと思ってよい」、「character(5,kanji)::message」という記載に注意)」

2.4 審判請求の理由と審判請求時の補正
2.4.1 審判請求の理由
審判請求の趣旨は「原査定を取り消す。本願の発明は特許すべきものとする、との審決を求める。」というものであり、その理由は、概略、次のとおりのものである。
「 ・・・(中略)・・・
【本願発明が特許されるべき理由】
(a)本願発明の説明
本願発明は、変数の属性としてデータ型を指定する「型制約」に加えて、データ型をより詳細に指定する「照合制約」を備えることを特徴とします。すなわち、本願発明は、請求項1にあるように、
「・・・(中略)・・・」
です。
(b)補正について
補正前後の請求項の関係は下表の通りです。補正前の請求項2、12?16は削除しました。
・・・(中略)・・・
(1)請求項1,9は、補正前の請求項1,10を本願明細書の段落[0012]、[0013]、[0023]?[0025]、[0037]、[0045]の記載に基づき補正したものです。
・「前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受け取る型制約受信コンポーネント」は本願明細書の段落[0022]?[0025]の記載に基づくものです。
・「データ型が同じ前記変数同士を比較および順序付けするために使用される照合制約」は本願明細書の段落[0045]の記載に基づくものです。
・「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネント」は本願明細書の段落[0023]、[0037]の記載に基づくものです。
・「前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする」は本願明細書の段落[0012]、[0013]、[0037]の記載に基づくものです。
(2)請求項3,4は、補正前の請求項4,5を本願明細書の段落[0026]の記載に基づき補正したものです。
(3)請求項5は、補正前の請求項6を本願明細書の段落[0036]の記載に基づき補正したものです。
(4)請求項6?8,10は、補正前の請求項7?9,11を請求項1,9と整合するように補正したものです。

(c)理由1,3について・請求項1,9において、本願明細書の段落[0045]の「型が同じまたは比較できる場合、・・・照合制約が比較できるかどうかに関して判別が行われる」との記載にあるように、比較等の対象は同じ型のコンポーネントであり、かつ[0025]に「s1およびs2を比較すると」との記載から、「前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約」としました。
・請求項1,9において、「前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする」と定義して「前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネント」とし、パラメータ化されるのは「変数」であり、補正前の「データ制約コンポーネント」はデータであることを明確にするために「データ制約」としました。これにより当業者は、
本願明細書の表3?6、図7?9およびこれらに関連する記載から「データ制約」を生成することは十分可能であると思料します。

(d)理由2について
補正前の請求項3?6の「照合制限」との記載は、「照合制約」に補正しました。

【むすび】
以上のとおり、本願発明は、特許法第36条第6項第1号及び第2号、第36条第4項第1号に規定する要件は満たすものと思料します。
よって、原査定を取り消す、本願発明は特許すべきものとする、との審決を求めます。
・・・(後略)・・・」

2.4.2 審判請求時の補正
(略) 3.1(本件補正後の特許請求の範囲)参照。

2.5 前置報告
平成24年6月18日付けでなされた前置報告の概略は次のとおりである。
「審判請求時になされた手続補正は、以下に(A)?(C)として述べるように、特許法第17条の2第3項の規定に適合しないので、特許法第159条第1項において準用する特許法第53条第1項の規定により、前記手続補正は、審判合議体の手によって却下されるべきものである。
そして、審判請求時になされた上述の手続補正が却下されれば、原査定は維持される。

(A)補正後の請求項1には、「前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記照合制約に基づき前記データ型が同じ変数同士でそれらが同じまたは互換性を有することを判定する、照合制約受信コンポーネント」という記載(以下、便宜的に「記載A」という。)が存在する。
前記「記載A」の中の「前記比較および順序付け操作中」と記載されているところの「操作中」という期間は、コンパイラが既に処理を済ませて、コンパイラの出力を用いたリンク処理(技術常識)なども済み、そうして最終的に完成したプログラムを動作させている期間のことである(すなわち、この「操作中」という期間の開始時点においては、コンパイラの処理は、既に終了している)。
一方、前記「記載A」の中の「前記コンパイル時の型検査は・・・判定する」という「判定」処理は、コンパイラがソースコードをコンパイル処理している最中に行われる処理である。
したがって、前記「記載A」は、コンパイラがコンパイル中に行う「判定」処理が、コンパイラの処理完了後に完成したプログラムを実行させている期間中に、行われるという趣旨の、時間的な前後関係が矛盾した出鱈目な記載になっており、そのような矛盾した出鱈目な記載は、当初明細書等には記載されておらず自明でもないので、特許法第17条の2第3項に規定されている要件を満たさない。補正後の請求項9についても同様。補正後の請求項1、9を引用するその他の請求項についても同様。

(B)補正後の請求項1の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、「変数をパラメータ化する」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【0023】、【0037】を挙げているが、それら段落【0023】、【0037】には、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもなく、したがって、このような記載を含む審判請求時の手続補正は、特許法第17条の2第3項の規定に適合しない。補正後の請求項9についても同様。補正後の請求項1、9を引用するその他の請求項についても同様。

(C)補正後の請求項1の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、「前記変数の属性を定義するパラメータ」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【0012】、【0013】、【0037】を挙げているが、それら段落【0012】、【0013】、【0037】には、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく(そもそも、「変数」の「属性」などというもの自体、当初明細書等のどこにも記載されておらず自明でもなく)、したがって、このような記載を含む審判請求時の手続補正は、特許法第17条の2第3項の規定に適合しない。補正後の請求項9についても同様。補正後の請求項1、9を引用するその他の請求項についても同様。
----------------------------------
【附記】(進歩性について)
拒絶査定の【附記3】で述べたように、拒絶査定時の請求項には不明瞭な記載が存在する(また、審判請求時の請求項にも、同様に不明瞭な記載が存在する)ので、新規性進歩性等の特許要件について、審査を行うことができない。
ところで、本願明細書の段落【0024】を参照すると、s1,s2という、文字列型(string型)の変数をソースコードの中で宣言する際に、それら変数s1,s2に格納される文字列が何語の文字列であるのか(英語か、ドイツ語か、など)を示す,などのパラメータを付けて宣言しており、それらs1,s2という変数に対し比較処理やソート(sort)処理を行う記述をソースコード内でコンパイラが発見した場合に、それら変数s1,s2の宣言時にそれらの変数に付けられていた前述の,などのパラメータをチェックするというのが本願明細書記載の発明の要点であると見受けられるが、仮に、本願請求項1などの記載が、そのような要点を、不必要に回りくどい表現で記載しているだけのものに過ぎないならば、そのような請求項の進歩性は、拒絶査定時の【附記3】で挙げた【参考文献1】や【参考文献2】の存在によって否定されるものと思料する。
何故ならば、上記【参考文献1】の第300頁左コラムの「3.3文字型のパラメタ化」を参照すると、Fortran90というプログラミング言語では、CHARACTER型の変数を宣言する際に、その長さ(LEN)と、「日本語」であるか「中国語」であるかなどの文字の種別(KIND)とを指定して宣言するようになっており、

CHARACTER(KIND=2,LEN=6)::A

という記述がソースコードの中に存在する場合、この記述は、変数Aが、長さ(文字数)が6で、格納される文字の種別が日本語であるようなCHARACTER型の変数であるという宣言であることを意味しており、このような変数宣言がFortran90のソースコードの中に記述されていると、その記述を解析したFortran90のコンパイラは、変数Aをソート(sort)する場合には、日本語の文字の並び順(平仮名やカタカナであれば、あいうえお順、漢字であればJIS漢字コード順)で処理するのは当然であるし(この点については、原審で挙げた引用文献4の第199頁の末尾6行の「ロケール固有の照合シーケンス」に関する技術常識も参照されたい)、また、従来から、データ型の不一致を検出するとコンパイラがエラーメッセージを出すことも技術常識である(例えば、整数型変数と文字列型変数の大小比較処理を行うようなソースコード内の記述がエラーメッセージを引き起こすことは、技術常識である)ので、Fortran90のソースコードにおいて、日本語の文字列であると宣言されている上述の変数Aを、中国語や韓国語の文字列と比較するような処理の記述がソースコードの中に存在していれば、Fortran90のコンパイラがそれを発見してエラーメッセージを発生させるようなことは、当然行うべきことに過ぎないからである(以上、【参考文献1】についてコメントしたが、【参考文献2】についても同様である)。
したがって、仮に、原査定の理由(理由1?3)が解消されているものと審判合議体が判断するのであれば、上述の【参考文献1】と【参考文献2】(さらには、先の拒絶理由通知書の【理由6】において挙げた引用文献1?7)に基づく進歩性の是非についても検討する必要があるものと思料する。」

2.6 審尋に対する回答書の意見の概要
平成24年6月18日付けでなされた審尋は、上記前置報告の内容について、審判請求人の意見を求めるものであり、該審尋に対する回答の概略は次のとおりである。
「・・・(中略)・・・
(2)前置報告書において審査官は、平成24年2月20日に提出した手続補正書について「特許法第17条の2第3項の規定に適合しないので、特許法第159条第1項において準用する特許法第53条第1項の規定により、前記手続補正は、審判合議体の手によって却下されるべきものである。」と認定されました。

(3)そこで、審判請求人は、審査官からの指摘を解消すべく、請求項の記載を下記のように補正を行う用意があります。

[請求項1]
コンピュータを、
前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信する型制約受信コンポーネント、
前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信する照合制約受信コンポーネントであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記照合制約に基づき前記データ型が同じ変数同士でそれらが同じまたは互換性を有することを判定する、照合制約受信コンポーネント、および
前記型制約および前記照合制約からなり、前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、前記変数のデータ型をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数のプロパティおよび前記変数のデータ型を定義するパラメータとして利用可能にし、前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能にする、コンストラクタコンポーネント
として機能させるためのプログラムを備えたことを特徴とする型制約システム。
[請求項2]
前記照合制約は、部分型の関係をサポートするために階層的であることを特徴とする請求項1に記載のシステム。
[請求項3]
前記照合制約は、前記データ型に言語を指定する言語制約を含むことを特徴とする請求項1に記載のシステム。
[請求項4]
前記照合制約は、前記言語制約に制約を追加するための文化制約を含むことを特徴とする請求項3に記載のシステム。
[請求項5]
前記照合制約は、前記データ型に時間帯を指定する時間帯制約を含むことを特徴とする請求項1に記載のシステム。
[請求項6]
前記データ型は、ストリングであり、および前記照合制約は、言語に関する制約であることを特徴とする請求項1に記載のシステム。
[請求項7]
前記データ型は、時間に関連し、および前記照合制約は、時間帯に関する制約であることを特徴とする請求項1に記載のシステム。
[請求項8]
前記データ型および照合制約は、弱く型付けされたプログラムから受け取られることを特徴とする請求項1に記載のシステム。
[請求項9]
プログラムされたコンピュータによってデータ制約を生成する方法であって、
前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信するステップであって、前記データ型はストリング、または日時のいずれかである、ステップと、
前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信するステップであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型が同じ前記変数同士について、それら変数同士が同じまたは互換性を有することを前記照合制約に基づき判定する、ステップと、 前記型制約および前記照合制約からなり、前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、前記変数のデータ型をパラメータ化するために使用されるデータ制約を生成するステップであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数のプロパティおよび前記変数のデータ型を定義するパラメータとして利用可能にし、前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能にする、ステップと
を有することを特徴とする方法。
[請求項10]
前記照合制約は、言語部分型を指定する文化データを含むことを特徴とする請求項9に記載の方法。

・「前記照合制約によってパラメータ化された前記受信したデータ型の変数が自動的に前記照合制約を含むように、」は、本願当初明細書の段落[0023]?[0025]の記載に基づくものです。
・「前記データの各インスタンスに関する追加の照合情報なしにコンパイル時に型チェックを可能にする」は、本願当初明細書の段落[0007]?[0009]、[0025]の記載に基づくものです。

(4)前置報告書に対する意見
A.本願明細書の段落[0023]にあるように、「本発明は、従来技術によって生成される実行時または動的エラーではなく、コンパイル時または静的エラーを生成することができる」ことを特徴とします。すなわち、本願発明は、従来コンパイルの処理完了後に完成したプログラムを実行させている期間中にしかできなかった処理を、コンパイル時に行えるようにしたものです。

B.請求項1,9の「前記変数をパラメータ化する」との記載は、本願当初明細書の段落[0037]の記載に基づき「前記変数のデータ型をパラメータ化する」と補正しました。

C.請求項1,9「前記変数の属性を定義するパラメータ」との記載は、は、本願当初明細書の段落[0037]の「本発明では、従来の理解とまったく対照的に、照合をデータ自体の特性として見ている。」との記載に基づき、「前記変数のプロパティおよび前記変数のデータ型を定義するパラメータ」と補正しました。

これらのことから、請求項1?10に係る発明は、本願当初明細書に記載した事項の範囲内にあるものと思料します。

(5)以上の通り、審判請求人は、原査定が取り消され、本願発明は特許されるべきものであると思料致しますので、上記意見を参酌の上、審理頂きたく、お願い申し上げます。
・・・(後略)・・・」

3. 平成24年1月13日付の手続補正についての補正却下の決定
[補正却下の決定の結論]
平成24年1月13日付の手続補正を却下する。
[理由]
3.1 本件補正
平成24年1月13日付の手続補正(以下、「本件補正」という。)により、特許請求の範囲の請求項1ないし請求項10は次のように補正された。
(本件補正後の特許請求の範囲)
「 【請求項1】
コンピュータを、
前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信する型制約受信コンポーネント、
前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信する照合制約受信コンポーネントであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記照合制約に基づき前記データ型が同じ変数同士でそれらが同じまたは互換性を有することを判定する、照合制約受信コンポーネント、および
前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント
として機能させるためのプログラムを備えたことを特徴とする型制約システム。
【請求項2】
前記照合制約は、部分型の関係をサポートするために階層的であることを特徴とする請求項1に記載のシステム。
【請求項3】
前記照合制約は、前記データ型に言語を指定する言語制約を含むことを特徴とする請求項1に記載のシステム。
【請求項4】
前記照合制約は、前記言語制約に制約を追加するための文化制約を含むことを特徴とする請求項3に記載のシステム。
【請求項5】
前記照合制約は、前記データ型に時間帯を指定する時間帯制約を含むことを特徴とする請求項1に記載のシステム。
【請求項6】
前記データ型は、ストリングであり、および前記照合制約は、言語に関する制約であることを特徴とする請求項1に記載のシステム。
【請求項7】
前記データ型は、時間に関連し、および前記照合制約は、時間帯に関する制約であることを特徴とする請求項1に記載のシステム。
【請求項8】
前記データ型および照合制約は、弱く型付けされたプログラムから受け取られることを特徴とする請求項1に記載のシステム。
【請求項9】
プログラムされたコンピュータによってデータ制約を生成する方法であって、
前記コンピュータに入力されたデータに含まれる変数のデータ型を指定する型制約を受信するステップであって、前記データ型はストリング、または日時のいずれかである、ステップと、
前記受信した型制約で指定されたデータ型が同じ前記変数同士を比較および順序付けするために使用される照合制約を受信するステップであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型が同じ前記変数同士について、それら変数同士が同じまたは互換性を有することを前記照合制約に基づき判定する、ステップと、
前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するステップであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、ステップと
を有することを特徴とする方法。
【請求項10】
前記照合制約は、言語部分型を指定する文化データを含むことを特徴とする請求項9に記載の方法。」

(本件補正前の特許請求の範囲)
「【請求項1】
コンピュータを、
データ型を受け取る型受信コンポーネント、
前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信する照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント、および
前記データ型および前記照合情報を使用して、前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネントを生成するコンストラクタコンポーネントであって、前記パラメータ化は、1以上のデータ型パラメータを前記データ型に追加することを含む、コンストラクタコンポーネント
として機能させるためのプログラムを備えたことを特徴とする型制約システム。
【請求項2】
前記データ制約コンポーネントは、インスタンス化されるとデータ型が決まる汎用型と共に採用されて構造型を作成するために用いられることを特徴とする請求項1に記載のシステム。
【請求項3】
前記照合制限は、部分型の関係をサポートするために階層的であることを特徴とする請求項1に記載のシステム。
【請求項4】
前記照合制限は、言語制約コンポーネントを含むことを特徴とする請求項1に記載のシステム。
【請求項5】
前記照合制限は、文化制限コンポーネントを含むことを特徴とする請求項4に記載のシステム。
【請求項6】
前記照合制限は、時間帯を含むことを特徴とする請求項1に記載のシステム。
【請求項7】
前記データ型は、ストリングであり、および前記照合情報は、言語であることを特徴とする請求項1に記載のシステム。
【請求項8】
前記データ型は、時間に関連し、および前記照合情報は、時間帯であることを特徴とする請求項1に記載のシステム。
【請求項9】
前記データ型および照合情報は、弱く型付けされたプログラムから受け取られることを特徴とする請求項1に記載のシステム。
【請求項10】
プログラムされたコンピュータによってデータ制約を生成する方法であって、
データ型を受信するステップであって、前記データ型は照合情報が言語であるストリング、または、前記照合情報がタイムゾーンである日時のいずれかである、ステップと、
前記受信したデータ型とデータを比較および順序付けするために使用される照合情報を受信するステップであって、前記照合情報は前記データ型のコンパイル時の強い型検査を容易にする1以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、ステップと、
前記受信したデータ型のデータを比較するための、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するステップであって、前記パラメータ化は、1以上のデータ型パラメータを前記データ型に追加することを含む、ステップと
を有することを特徴とする方法。
【請求項11】
前記照合情報は、言語部分型を指定する文化データを含むことを特徴とする請求項10に記載の方法。
【請求項12】
前記生成されたデータ制約をインスタンス化されるとデータ型が決まる汎用型のパラメータとして使用する構造型を生成するステップをさらに備えたことを特徴とする請求項10に記載の方法。
【請求項13】
プログラムされたコンピュータによるプログラミング言語又はシステム間のマッピング方法であって、
データ型および前記データ型が関連付けられたデータの照合情報を弱く型付けされた言語またはシステムから受信するステップであって、前記データ型は照合情報が言語であるストリング、又は、前記照合情報がタイムゾーンである日時のいずれかであり、前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、ステップと、
前記受信したデータ型のデータを比較するための、前記照合情報でパラメータ化された前記データ型の前記データ型パラメータを含むデータ制約コンポーネントを生成するステップであって、前記パラメータ化は、1以上のデータ型パラメータを前記データ型に追加することを含む、ステップと
を有することを特徴とする方法。
【請求項14】
前記型および照合情報は、データベースから受け取られ、および前記データ制約コンポーネントを使用して強く型付けされたプログラミング言語にマップされることを特徴とする請求項13に記載の方法。
【請求項15】
前記強く型付けされたプログラミング言語は、C#、Java(登録商標)、およびXqueryの内の1つを含むことを特徴とする請求項14に記載の方法。
【請求項16】
前記マッピングは、システム上の複数の言語を同時にサポートするマルチリンガルシステムを提供することを特徴とする請求項15に記載の方法。」

3.2 本件補正が、特許法第17条の2第3項の規定に適合するものであるかについて検討する。
(1)本件補正により補正された特許請求の範囲の請求項1(以下、「補正後請求項1」などと呼ぶ。)には「型制約を受信する型制約受信コンポーネント」「照合制約受信コンポーネント」という記載が存在するが、そのような型制約を「受信」する「型制約受信コンポーネント」、照合制約を「受信」することを意味する「型制約受信コンポーネント」は願書に最初に添付した明細書又は図面(以下、「当初明細書等」と呼ぶ。)には記載されておらず自明でもない。即ち、「受信」に関し、図1、図7や段落【0022】などに「型受信側コンポーネント」「照合情報受信側コンポーネント(照合受信側コンポーネント)」が記載されているが、これらのコンポーネントは制約コンストラクタコンポーネント130によってデータ制約コンポーネントが生成される前のコンポーネントであるから、生成されたデータ制約コンポーネントが「受信」を構成として備えることを意味しない。前記データ制約コンポーネントは前記型制約や照合制約を「受信」するコンポーネントとみることはできないので、補正後請求項1の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」は、当初明細書等に記載されたデータ型や前記照合情報を受信する「型受信側コンポーネント」「照合情報受信側コンポーネント」と対応するものでない。また、補正後請求項1の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」が図5、図8、図9や段落【0035】?【0037】、段落【0044】【0045】に記載されたデータ制約コンポーネントを含むデータ指定コンポーネントを指すとみても、これらのデータ制約コンポーネントを含むデータ指定コンポーネントは「受信」するものでない。よって、補正後請求項1の前記「型制約受信コンポーネント」「照合制約受信コンポーネント」は、当初明細書等に記載されたものではなく、特許法第17条の2第3項に規定されている要件を満たさない。
(2)請求項1には、「照合制約受信コンポーネントであって、前記照合制約は前記データ型のコンパイル時の型検査に使用する1以上のパラメータを含み、前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記照合制約に基づき前記データ型が同じ変数同士でそれらが同じまたは互換性を有することを判定する、照合制約受信コンポーネント」という記載(以下、便宜的に「記載A」という。下線部は強調の意味で付した。)が存在する。
前記「記載A」の中の「前記比較および順序付け操作中」と記載されているところの「操作中」という期間は、コンパイラが既に処理を済ませて、コンパイラの出力を用いたリンク処理(技術常識)なども済み、そうして最終的に完成したプログラムを動作させている期間とみることができ、そうすると、この「操作中」という期間の開始時点においては、コンパイラの処理は、既に終了している。
一方、前記「記載A」の中の「前記コンパイル時の型検査は・・・判定する」という「判定」処理は、コンパイラがソースコードをコンパイル処理している最中に行われる処理である。
したがって、前記「記載A」は、コンパイラがコンパイル中に行う「判定」処理が、コンパイラの処理完了後に完成したプログラムを実行させている期間中に、行われるという趣旨の、時間的な前後関係が矛盾した記載になっており、そのような矛盾した記載は、当初明細書等には記載されておらず自明でもない。よって、特許法第17条の2第3項に規定されている要件を満たさない。
補正後請求項9は、カテゴリが「方法」の発明に係るが、補正後請求項1の「システム」と実質同じ事項を備えており、前記補正後請求項1と同様のことがいえる。補正後請求項1、9を引用するその他の請求項についても同様のことがいえる。

(3)補正後請求項1の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、特に「変数をパラメータ化する」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【0023】、【0037】を挙げているが、それら段落【0023】、【0037】には、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「変数をパラメータ化する」などということはどこにも記載されておらず自明でもない。
したがって、このような記載を含む審判請求時の手続補正は、特許法第17条の2第3項の規定に適合しない。補正後請求項9についても同様のことがいえる。補正後請求項1、9を引用するその他の請求項についても同様のことがいえる。

(4)補正後請求項1の「前記型制約および前記照合制約からなり、前記変数をパラメータ化するために使用されるデータ制約を生成するコンストラクタコンポーネントであって、前記パラメータ化は、前記型制約および前記照合制約を、前記変数の属性を定義するパラメータとして利用可能にする、コンストラクタコンポーネント」という記載の中には、「前記変数の属性を定義するパラメータ」という記載が存在するが、そのようなことは、当初明細書等には記載されておらず自明でもない。審判請求人は、補正の根拠として、当初明細書の段落【0012】、【0013】、【0037】を挙げているが、それら段落【0012】、【0013】、【0037】には、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく、また、当初明細書等のその他の箇所の記載を参照しても、「前記変数の属性を定義するパラメータ」などということはどこにも記載されておらず自明でもなく(そもそも、「変数」の「属性」などというもの自体、当初明細書等のどこにも記載されておらず自明でもなく)、したがって、このような記載を含む審判請求時の手続補正は、特許法第17条の2第3項の規定に適合しない。
補正後請求項9についても同様のことがいえる。補正後請求項1、9を引用するその他の請求項についても同様のことがいえる。

(なお、回答書の補正案には、例えば、その請求項1に「照合制約によってパラメータ化」「自動的に」「変数のプロパティ」(段落【0037】の「照合をデータ自体の特性として見ている」における特性から「プロパティ」が示唆されるとしても前記照合、特性は「変数のプロパティ」までも示唆するものではない。)といった事項が記載されており、これらの事項は当初明細書等に記載されておらず、自明な事項でもなく、結果的に前記補正案により新たな不明確な事項を導入するものとみることができるので、回答書の補正案は採用することはできない。)

3.3 むすび
したがって、本件補正は、平成18年法律第55号改正附則第3条第1項の規定によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、上記補正却下の決定の結論のとおり決定する。

4.本件審判請求について
(1)平成24年1月13日付の手続補正は前記のとおり却下されたので、本願の請求項1?16は、平成23年7月22日付の手続補正書により補正された特許請求の範囲の請求項1?16に記載されたとおりのものである。(3.1の特許請求の範囲の請求項1?請求項16参照。以下「本願請求項1」「本願請求項2」などという。)

(2)そこで、原査定(拒絶理由通知で示した理由1?3によって拒絶すべきものであるとした点)が妥当なものであるか否かを検討する。あわせて、原査定において、前記平成23年7月22日付の手続補正書による補正により、新たに【理由A】ないし【理由D】の拒絶の理由が発生しているとしているので、この【理由A】ないし【理由D】で指摘した点も検討する。

(2.1)理由1について(特許法第36条第6項第2号)
本願請求項1には、「照合情報」について、「前記受信したデータ型とデータを比較および順序付けするために使用される照合情報」という記載(以下、便宜的に「記載AA」という。)と、「前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み」という記載(以下、便宜的に「記載BB」という。)とが存在するが、これら記載AA及び記載BBは、以下の(2.1.1)の点が不明であり、このような記載AA及び記載BBを伴う本願請求項1の「照合情報」という用語は依然として明確ではない。したがって、本願請求項1の記載は、依然として明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備が、依然として解消されていない。

(2.1.1)記載AAは、「データ型」と「データ」を「比較および順序付けする」という趣旨の記載であるが、「データ型」と「データ」を「比較」するとは如何なる比較を意味するのか技術的意味が不明であり、また、「データ型」と「データ」を「順序付けする」も如何なる技術的意味であるのかも不明である。
また、記載BBには、型検査を「容易」にするという趣旨の記載があるが、「容易」か否かの判断基準が何であるのか不明である。
(2.1.2)理由1の(3)として指摘した「照合制限」という用語の定義が不明であり、明細書にはその定義を説明する記載もなく、この記載不備は解消されていない。本願請求項3?6の「照合制限」という用語の定義は不明である。
(2.1.3)理由1の(4)として指摘した記載不備が、依然として解消されていない。本願請求項1には「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」という記載が存在し、この記載は、「データ制約コンポーネント」は、「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」を「含む」という趣旨の記載である。ここで、「前記照合情報」の「前記」とは本願請求項1に記載された「前記照合情報は・・・1以上のデータ型パラメータを含」む照合情報であるから、これらの記載における「照合情報」と「照合情報によってパラメータ化された変数」と「データ型パラメータ」との関係において、「変数」である「データ型パラメータ」との記載からして「データ型パラメータ」は「変数」のことであり、「データ型パラメータを含」む「照合情報」との記載からして「データ型パラメータ」と「照合情報」とは同じものがあることを意味する。あわせると、「照合情報」「データ型パラメータ」「変数」は同じであることを含むことになり、特に「パラメータ化」「変数」なる記載が特定事項として如何なる技術的意味をもつのか不明にするものであり、前記「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータを含むデータ制約コンポーネント」は明確でないことになる。
請求人は、平成23年7月22日付け意見書の「(4)補正の説明」の項において、請求項1は段落【0022】【0035】【0037】【0040】の記載に基づく旨主張しているが、当該段落には、少なくとも「変数」(データプレースホルダ(つまり変数))(段落【0025】【0026】参照)は記載されていないので、補正の根拠が不明であるが、変数はデータプレースホルダ(つまり変数)であるから「照合情報」「データ型パラメータ」とは種類が異なる情報(例えば、汎用化レベルが異なるカテゴリの情報等)であり、前記本願請求項1の前記同じものであることを意味する内容と矛盾する。また、「データ型パラメータ」は、明示的には当初明細書等の請求項17に「前記照合制約は、データ型パラメータである」ことは記載されているが、前記段落には記載されていない。

以上(2.1.1)ないし(2.1.3)で指摘した記載不備が依然として解消されていないので、本願請求項1?16の記載は、依然として明確ではない。

(2.2)理由2について(特許法第36条第6項第1号)
(2.2.1)理由2の(2)として指摘した記載不備が、依然として解消されていない。補正後の請求項3?6には依然として「照合制限」という記載が存在するが、そのようなものは、発明の詳細な説明には記載されていない。
同様の記載を有するその他の補正後の請求項についても、同様の記載不備が、依然として解消されていない。

(2.3)理由3について(特許法第36条第4項第1号)
(2.3.1)理由3の(1)として指摘した記載不備が、依然として解消されていない。上記「(1)理由1について」及び上記「(2)理由2について」で指摘した本願請求項1?16の中の記載箇所の記載の具体的な実現手法が、下記ア.?エ.の点で、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
ア.本願請求項1の「受信したデータ型とデータを比較および順序付けする」は如何にしてデータ型とデータを比較および順序付けするのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
イ.本願請求項1の「照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータを含み」における当該「容易にする」なる構成は、「照合情報」と「データ型パラメータ」とが如何なる対応関係にあり、「パラメータ化」された「変数」を構成とすることもなく如何なるメカニズムを用いることにより「容易にする」構成なのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。
ウ.本願請求項1の「前記比較および順序付け操作中に、前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント」は、「照合情報受信コンポーネント」に係る構成であるから、図1?図3のブロックないし、図7のフロー、及びこれらに関連する明細書の説明が対応づけられると解されるが、前記「操作中」とはどのブロックないしフローの部分が対応していて発明の詳細な説明のどこに記載されているのか、また、当該「操作中」に、「前記コンパイル時の型検査は、前記データ型パラメータを含む前記データ型が同じまたは互換性があることを確実にする、照合情報受信コンポーネント」とは、操作中に如何なるメカニズムによりどのような手順で「確実にする」ことをすれば成されるのか、具体的な実現手法が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。段落【0035】には「型チェッカコンポーネント530は、データ指定コンポーネント510および520の両方を分析して、そのデータ制約が満たされ、コンポーネントが互換であることを確実にする。」ことが記載されているが、この「確実にする」はデータ指定コンポーネント510および520の両方を分析して、この分析の結果、互換を確実にするものであるから、この段落に記載された事項は、本願請求項1のように、分析する構成を備えずに確実にするものではなく、「前記照合情報受信コンポーネントであって、」「前記比較および順序付け操作中に、」なる構成に於けるものではないから、本願請求項1の前記事項の具体的な実現手法に対応付けることはできないものである。
エ.本願請求項1の「前記照合情報によってパラメータ化された前記データ型の変数である前記データ型パラメータ」は、「照合情報によってパラメータ化された前記データ型の変数」である「前記データ型パラメータ」(「照合情報受信コンポーネントであって、前記照合情報は前記データ型のコンパイル時の型検査を容易にする1以上のデータ型パラメータ」における当該「データ型パラメータ」)を意味するが、このような「パラメータ化された」「変数」である「データ型パラメータ」の、具体的な実現手法(少なくとも「データ型パラメータ」すら発明の詳細な説明に記載も示唆もない。)が、依然として、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。

したがって、本願の発明の詳細な説明の記載は、請求項1?16に係る発明について、当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。
よって、本願は、依然として、特許法第36条第4項第1号に規定する要件を満たしていないものであるとした、原査定は妥当なものである。

4.むすび
以上のとおり、依然として、本願は、発明の詳細な説明及び特許請求の範囲の記載が不備であり、特許法第36条第4項第1号並びに特許法第36条第6項第1号及び第6項第2号に規定する要件を満たしていないとする拒絶理由は解消されていない。
したがって、本願は、前記の拒絶理由によって拒絶すべきものであるとした原査定は妥当なものであり、これを取り消すことはできない。

よって、結論のとおり審決する。
 
審理終結日 2013-06-05 
結審通知日 2013-06-11 
審決日 2013-06-25 
出願番号 特願2005-214303(P2005-214303)
審決分類 P 1 8・ 561- Z (G06F)
P 1 8・ 536- Z (G06F)
P 1 8・ 537- Z (G06F)
最終処分 不成立  
前審関与審査官 久保 光宏  
特許庁審判長 山崎 達也
特許庁審判官 原 秀人
田中 秀人
発明の名称 組み込み照合情報を備えるデータ型  
代理人 特許業務法人 谷・阿部特許事務所  
復代理人 濱中 淳宏  
復代理人 藤原 弘和  

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