• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1220482
審判番号 不服2006-27903  
総通号数 129 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-09-24 
種別 拒絶査定不服の審決 
審判請求日 2006-12-11 
確定日 2010-07-21 
事件の表示 特願2001-511604「事前計算されるビューを保守するシステム」拒絶査定不服審判事件〔平成13年 1月25日国際公開、WO01/06419、平成15年 2月12日国内公表、特表2003-505767〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
1.手続の経緯

本願は、平成12年7月19日(優先権主張平成11年7月19日、米国)を国際出願日とする出願であって、
平成18年9月1日付けで拒絶査定がなされ、これに対し、平成18年12月11日に拒絶査定不服審判の請求がなされるとともに、平成19年1月10日付けで手続補正がなされ、
更に、平成21年10月22日付けで拒絶理由が通知され、これに対し、平成22年1月26日付けで手続補正がなされたものである。



2.平成21年10月22日付けの拒絶理由通知書

平成21年10月22日付けの拒絶理由通知書で通知された特許法第36条第6項第2号違反に関する拒絶理由(以下、単に「拒絶理由」という。)は以下のとおりのものである。

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



(1)
請求項1には、「前記詳細データが更新される時に、前記事前計算されるビューをリフレッシュするための保守プランを、前記データベース・サーバ・システム内の照会処理部が決定するステップ」と記載されている。
しかしながら、当該記載では、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で保守プランを決定するのか不明である。
したがって、当該記載では、「発明」(自然法則を利用した『技術的思想』の創作)が明確でない。


(2)請求項1には、「前記照会処理部が、前記保守プランを前記データベース・サーバ・システム内の照会実行プランと統合するステップ」と記載されている。
しかしながら、当該記載では、「保守プラン」及び「照会実行プラン」という名称の実体不明の情報を規定しているのに留まり、当該情報が如何なる類の情報なのか、如何なる構造を有した情報なのか不明である。
そのために、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で各種プランを「統合」するのかも不明になっている。
したがって、当該記載では、「発明」(自然法則を利用した『技術的思想』の創作)が明確でない。


(3)
請求項1に記載された「デルタ表」は、生成され、データ・ストア部に送られ、削除されるだけの存在であって、請求項にデルタ表を活用する事項が存在しない。
そのために、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で、「デルタ表」を用いたビューの更新を行うのか不明である。
したがって、当該記載では、「発明」(自然法則を利用した『技術的思想』の創作)が明確でない。


(4)
請求項2の「前記ビューが、増分式に保守される」という記載は、日本語として意味が不明である。


(5)
昭和31年(行ナ)第18号判決(昭和32年5月21日判決言渡)において、
「原告代理人は、本件出願の発明に引用特許発明とが、技術的内容について同一性を有することを認めつつも、一方は方法として表現し、他方は物として表現したものであるから、異別のニ発明として双方とも特許せられるべきものであると主張するが、方法とは一定の目的に向けられた系列的に関連のある数個の行為又は現象によって成立するものと解すべきであるが(方法の逐次性)、・・・」
と判示されているように、方法の発明」は、「一定の目的に向けられた系列的に関連のある数個の行為又は現象によって成立するもの」である。
したがって、請求項1の各種ステップのどの間で行われるのか特定できない請求項4乃至9の記載では、「(方法の)発明」が明確であるとはいえない。


(6)
請求項4には「依存性情報が、保守ストラテジの決定に使用される」と記載されている。
しかしながら、当該記載では、「依存性情報」及び「保守ストラテジ」という名称の実体不明の情報を規定しているのに留まり、当該情報が如何なる類の情報なのか、如何なる構造を有した情報なのか不明である。
そのために、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で依存性情報から保守ストラテジが決定されるのかも不明になっている。
したがって、当該記載では、「発明」(自然法則を利用した『技術的思想』の創作)が明確でない。


(7)
請求項1と同様の記載がある請求項10乃至11については、上記(1)乃至(3)で指摘した記載不備と同様の記載不備がある。」



3.平成22年1月26日付けの手続補正書

審判請求人は、平成21年10月22日付けの拒絶理由通知書に対し、平成22年1月26日付けで手続補正書を提出し、以下のように、特許請求の範囲を補正した。

「 【請求項1】
データベース・サーバ・システム内の詳細データに対応する事前計算されるビューを保守する方法であって、
前記詳細データが更新される時に、前記事前計算されるビューをリフレッシュするための保守プランを、予め定義されたサブ・プランから前記データベース・サーバ・システム内の照会処理部が選択するステップと、
前記照会処理部が、前記保守プランを前記データベース・サーバ・システム内の照会実行プランと統合するステップと、
前記照会処理部が、前記保守プランが統合された前記照会実行プランを実行するステップと、
前記照会処理部が、前記更新の操作の各々について、更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表、2つの表(デルタ表)を生成するステップと、
前記照会処理部が、前記デルタ表に係る情報を前記データベース・サーバ・システム内のデータ・ストア部に送るステップと、
前記照会処理部が、前記データ・ストア部に送信された前記情報に基づき、前記更新の操作に関連するロックおよびトランザクション・ハンドルを獲得するステップと、
前記照会処理部が、前記データ・ストア部に送信された前記情報に基づき、前記事前計算されるビューを更新するステップと、
前記照会処理部が、前記デルタ表を除去するステップと、
を含む方法。
【請求項2】
前記ビューが、1つまたは複数の詳細表を再計算することによって保守される、請求項1に記載の方法。
【請求項3】
詳細データと照会実行プランとデータ・ストア部とを有し、前記詳細データに対応する事前計算されるビューを保守する、データベース・サーバ・システムであって、
前記詳細データが更新される時に、前記事前計算されるビューをリフレッシュするための保守プランを、予め定義されたサブ・プランから前記データベース・サーバ・システム内の照会処理部が選択する手段と、
前記保守プランを前記データベース・サーバ・システム内の照会実行プランと統合する手段と、
前記保守プランが統合された前記照会実行プランを実行する手段と、
前記更新の操作の各々について、更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表、2つの表(デルタ表)を生成する手段と、
前記デルタ表に係る情報を前記データベース・サーバ・システム内のデータ・ストア部に送る手段と、
前記データ・ストア部に送信された前記情報に基づき、前記更新の操作に関連するロックおよびトランザクション・ハンドルを獲得する手段と、
前記データ・ストア部に送信された前記情報に基づき、前記事前計算されるビューを更新する手段と、
前記デルタ表を除去する手段と、
を含むシステム。
【請求項4】
データベース・サーバ・システム内の詳細データに対応する事前計算されるビューを保守するためのコンピュータ・プログラムを記録した、コンピュータ・プログラム記録媒体であって、前記データベース・サーバ・システム内の照会処理部に、
前記詳細データが更新される時に、前記事前計算されるビューをリフレッシュするための保守プランを、予め定義されたサブ・プランから前記データベース・サーバ・システム内の照会処理部が選択するステップと、
前記保守プランを前記データベース・サーバ・システム内の照会実行プランと統合するステップと、
前記保守プランが統合された前記照会実行プランを実行するステップと、
前記更新の操作の各々について、更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表、2つの表(デルタ表)を生成するステップと、
前記デルタ表に係る情報を前記データベース・サーバ・システム内のデータ・ストア部に送るステップと、
前記データ・ストア部に送信された前記情報に基づき、前記更新の操作に関連するロックおよびトランザクション・ハンドルを獲得するステップと、
前記データ・ストア部に送信された前記情報に基づき、前記事前計算されるビューを更新するステップと、
前記デルタ表を除去するステップと、
を実行させるためのコンピュータ・プログラムを記録した、コンピュータ・プログラム記録媒体。」



4.上記平成22年1月26日付けの手続補正書による補正を踏まえた当審の判断

(1)特許法第36条第6項第2号の「発明が明確であること」について

(1-a)
特許法第36条第6項第2号には、

「6 第三項第四号の特許請求の範囲の記載は、次の各号に適合するものでなければならない。
一 ・・・(中略)・・・
二 特許を受けようとする発明が明確であること。
三 ・・・(中略)・・・
四 ・・・(後略)・・・」

と規定されている。


(1-b)
また、当該規定中の「発明」に関して、特許法第2条第1項には、

「この法律で「発明」とは、自然法則を利用した技術的思想の創作のうち高度のものをいう。」

と定義されている。


(1-c)
更に、当該規定中の「技術」に関しては、特許法には定義されていないものの、我が国の最高裁判所による、

・昭和39年(行ツ)第92号審決取消請求事件
(http://www.courts.go.jp/hanrei/pdf/7FD8AED5EEA613C249256A85003122E3.pdf)
「発明は、自然法則の利用に基礎付けられた一定の技術に関する創作的な思想であるが、特許制度の趣旨にかんがみれば、その創作された技術内容は、その技術分野における通常の知識・経験を持つ者であれば何人でもこれを反復実施してその目的とする技術効果をあげることができる程度にまで具体化され、客観化されたものでなければならない。」

・昭和49年(行ツ)第107号審決取消請求事件
(http://www.courts.go.jp/hanrei/pdf/5EAC05562AD2622749256A850031207F.pdf)
「「発明」は技術的思想、すなわち技術に関する思想でなければならないとしているが、特許制度の趣旨に照らして考えれば、その技術内容は、当該の技術分野における通常の知識を有する者が反復実施して目的とする技術効果を挙げることができる程度にまで具体的・客観的なものとして構成されていなければならないものと解するのが相当であり、技術内容が右の程度にまで構成されていないものは、発明として未完成なものであって、法2条1項にいう「発明」とはいえないものといわなければならない(当裁判所昭和三九年(行ツ)第九二号同四四年一月二八日第三小法廷判決民集二三巻一号五四頁参照。)」

・平成10年(行ツ)第19号審決取消請求事件
「発明は、自然法則の利用に基礎付けられた一定の技術に関する創作的な思想であるが、その創作された技術内容は、その技術分野における通常の知識経験を持つ者であれば何人でもこれを反復実施してその目的とする技術効果を挙げることができる程度にまで具体化され、客観化されたものでなければならない」

という判示事項(なお、下線は当審において付加)から、特許法上の「技術」であるためには、具体的、客観的、反復実施可能の三要件を満たすことが必要であるといえる。

なお、上記判示事項は、それぞれ、エネルギー発生装置、薬物製品、黄桃に関するものであって、本出願が属するコンピュータ・ソフトウエア技術に関するものではないが、
特許法第49条及び第51条の規定から明らかなように、特許法第32条に規定された「公の秩序、善良の風俗又は公衆の衛生を害するおそれがある発明」を除き、特許法においては、特許にするべきか否かの判断をする際に、技術分野による差別を行うことは予定されていないのであるから、
上記判決の「技術」に関する判示事項は、コンピュータ・ソフトウエア関連発明にも適用されることは明らかである。


(1-d)
以上のことから、上記(1-a)(1-b)(1-c)、すなわち、

・特許法第36条第6項第2号には、特許請求の範囲の記載において「特許を受けようとする発明が明確であること。」と規定されていること、

・特許法が「明確であること」を要求している「(特許を受けようとする)発明」は、「自然法則を利用した技術的思想の創作のうち高度のもの」と定義されていること、

・「発明」の定義にある「技術」とは、具体的、客観的、反復実施可能の三要件を満たすものであると最高裁判所が判示しているといえること、

を纏めると、特許法第36条第6項第2号の要件を満たすためには、特許請求の範囲の記載において、少なくとも、具体的、客観的、反復実施可能という観点から明確でなければならないといえる。


(1-e)
なお、特許法第36条第6項第2号について判断する場合、「発明の詳細な説明」の記載に基づいて解釈することが許されないことは、旧特許法36条5項及び6項に関する判決ではあるものの、

昭和62年(行ツ)第3号審決取消請求事件(http://www.courts.go.jp/hanrei/pdf/75CB63A39AC99F3449256A8500311EAF.pdf)を引用した、
平成13年(行ケ)第346号審決取消請求事件
(http://www.courts.go.jp/hanrei/pdf/2462A9ACD430027949256D4400110B02.pdf)
「 原告は,特許請求の範囲の記載が,それ自体で不明確であったとしても,発明の詳細な説明の記載を参酌してそれが明確になる場合は,出願に係る発明の要旨の確定には何ら支障がないのであるから,このような特許請求の範囲の記載も,旧特許法36条5項及び6項に規定する要件を満たしているというべきである,このことは,最高裁平成3年3月8日判決(民集45巻3号123頁)からも明らかである,と主張する。
しかし,上記判例は,特許出願に係る発明の新規性あるいは進歩性を判断する場合における,特許出願に係る発明の請求項の要旨の認定について述べた判例であり,旧特許法36条5項について判断をしたものではないから,本件については,その適用はない,と解すべきである。このことは,上記判例が,「特許法第29条1項及び2項所定の特許要件,すなわち,特許出願に係る発明の新規性及び進歩性について審理するに当たっては,この発明を同条1項各号所定の発明と対比する前提として,特許出願に係る発明の要旨が認定されなければならないところ,この要旨認定は,特段の事情のない限り,願書に添付した明細書の特許請求の範囲の記載に基づいてされるべきである。特許請求の範囲の記載の技術的意義が一義的に明確に理解することができないとか,あるいは,一見してその記載が誤記であることが明細書の発明の詳細な説明の記載に照らして明らかであるなどの特段の事情がある場合に限って,明細書の発明の詳細な説明の記載を参酌することが許されるに過ぎない。」(下線付加)と判示しているところから,明らかである。特許出願に係る発明の新規性あるいは進歩性を判断する場合における,当該発明の要旨を認定する場合において,特許請求の範囲の記載を前提として,当該発明の要旨を認定し,あるいは,上記判例がいうような例外的な場合に明細書における発明の詳細な説明を参酌して要旨を認定した上で,その発明の新規性あるいは進歩性の判断をする,ということには十分合理性がある。しかし,新規性あるいは進歩性の判断の前提としての発明の要旨の認定をいかにして行うか,ということと,特許出願の願書に添付された明細書の特許請求の範囲の記載が,旧特許法36条5項が規定する要件に合致しているかどうかとは,問題を全く異にするものである。特許請求の範囲の記載は,できる限り,それ自体で,特許出願に係る発明の技術的範囲が明確になるように記載されるべきであり,旧特許法36条5項2号の「特許を受けようとする発明の構成に欠くことができない事項のみを記載」すべきであるとした規定は,この考え方を具体化した規定であると解すべきである。原告の上記主張は,旧特許法36条5項の規定の解釈としては採用することができない。」

という判示事項から明らかである。


(2)拒絶理由(3)で指摘した事項についての判断

以上の「発明が明確であること」の意義を踏まえた上で、拒絶理由(3)で指摘した事項について検討する。

(2-a)
請求項1は、「データベース・サーバ・システム内の詳細データに対応する事前計算されるビューを保守する方法」であって、「照会処理部」が各種ステップを行う方法というように記載されていることから明らかなように、コンピュータのような『情報処理装置上で実行可能な情報処理技術』を前提とする発明である。

したがって、請求項1のデルタ表に関する記載、すなわち、
「前記照会処理部が、前記更新の操作の各々について、更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表、2つの表(デルタ表)を生成するステップと、
前記照会処理部が、前記デルタ表に係る情報を前記データベース・サーバ・システム内のデータ・ストア部に送るステップと、
前記照会処理部が、前記データ・ストア部に送信された前記情報に基づき、前記更新の操作に関連するロックおよびトランザクション・ハンドルを獲得するステップと、
前記照会処理部が、前記データ・ストア部に送信された前記情報に基づき、前記事前計算されるビューを更新するステップと、
前記照会処理部が、前記デルタ表を除去するステップ」
という記載は、コンピュータのような『情報処理装置上で実行可能な情報処理技術』として、具体的、客観的、反復実施可能という観点から「明確」でなければならない。


(2-b)
一方、コンピュータのような『情報処理装置上で実行可能な情報処理技術』においては、コンピュータのハードウエア資源と協働することを前提とする「アルゴリズム」に基づいて作成されたプログラムに従ってコンピュータが動作することになるから、
コンピュータのような『情報処理装置上で実行可能な情報処理技術』とは、コンピュータのような『情報処理装置上で実行可能であることが把握できるアルゴリズム』の如きものであるといえる。

そうすると、『如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で、「デルタ表」を用いたビューの更新を行うのか』(拒絶理由(3)を抜粋)が、特許請求の範囲の記載において、少なくとも、具体的、客観的、反復実施可能という観点から「明確」でなければならないことになる。


(2-c)
それにも関わらず、上記した請求項1のデルタ表に関する記載は、
(「更新される行の内容を保存した表」と「該表の行番号と詳細データの行番号の対応を保存した表」とは異なる)『2つの表(デルタ表)』という、具体的構成を何ら特定していない実体不明の表を『何らかの方法』で生成し、前記デルタ表に係る情報に基づき『何らかの方法』でビューを更新するといった事項を規定するに留まっており、
『2つの表(デルタ表)』という実体不明の2つの表に基づいて、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)を用いてビューを更新するのかを、『具体的、客観的、反復実施可能』と把握できる程度にまで「明確」に記載しているとはいえない。

以上のことから、上記した請求項1のデルタ表に関する記載では、具体的、客観的、反復実施可能という観点から、発明が「明確」であるとはいえない。

なお、上記判断は、審査基準「第I部第1章 明細書及び特許請求の範囲の記載要件 2.2.2.1 第36条第6項第2号違反の類型」、及び当該事項を引用している審査基準「第VII部第1章 コンピュータ・ソフトウエア関連発明 1.1.3 発明が明確でない例」の(6)の場合に通ずるものである。


(2-d)
なお、仮に、上記した請求項1のデルタ表に関する記載中の「更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表、2つの表(デルタ表)」が、「更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表という、2つの表(デルタ表)」を意図したものであるとしても、
請求項1は、依然として、前記デルタ表に係る情報に基づき『何らかの方法』でビューを更新するといった事項を規定するに留まる。
その上、そのようなものを意図したものである場合には、請求項1の記載は、「2つの表(デルタ表)」の他に「更新される行の内容を保存した表と、該表の行番号と詳細データの行番号の対応を保存した表」が2つ(合計4つの表)があるとも読める不明確な記載であるということにもなる。

したがって、上記意図の如く解釈したとしても、発明が「明確」であるとはいえない、ということに変わりはない。


(3)拒絶理由(1)で指摘した事項についての判断

請求項1の「前記詳細データが更新される時に、前記事前計算されるビューをリフレッシュするための保守プランを、予め定義されたサブ・プランから前記データベース・サーバ・システム内の照会処理部が選択するステップ」という記載では、
「保守プラン」及び「予め定義されたサブ・プラン」という具体的構成を何ら特定していない実体不明のプラン相互の関係が規定されているに過ぎず、
如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で、サブ・プランに基づき保守プランを選択するのかは、依然として不明である。

なお、上記(1-e)で提示した判決から理解できるように、発明の詳細な説明の欄に説明があることを根拠として、特許請求の範囲の記載を漠然としたものに留めておくことは許されない。


(4)拒絶理由(2)で指摘した事項についての判断

請求項1の「前記照会処理部が、前記保守プランを前記データベース・サーバ・システム内の照会実行プランと統合するステップ」という記載では、
「保守プラン」及び「照会実行プラン」という名称の実体不明の情報が相互に結合されることが規定されているに留まり、当該情報が如何なる類の情報なのか、如何なる構造を有した情報なのかは、依然として不明である。
そのために、如何なる『技術的思想』(例:情報処理装置上で実行可能であることが把握できるアルゴリズム)で各種プランを「統合」するのかも、依然として不明になっている。

なお、上記(1-e)で提示した判決から理解できるように、発明の詳細な説明の欄に説明があることを根拠として、特許請求の範囲の記載を漠然としたものに留めておくことは許されない。



5.まとめ

以上のことから、本出願は、特許法第36条第6項第2号に規定する要件を満たしていない。

したがって、その余の拒絶理由について検討するまでもなく、本出願は拒絶すべきものである。

よって、結論のとおり審決する。
 
審理終結日 2010-02-19 
結審通知日 2010-02-23 
審決日 2010-03-10 
出願番号 特願2001-511604(P2001-511604)
審決分類 P 1 8・ 537- WZ (G06F)
最終処分 不成立  
前審関与審査官 深津 始  
特許庁審判長 田口 英雄
特許庁審判官 和田 財太
小曳 満昭
発明の名称 事前計算されるビューを保守するシステム  
代理人 坂口 博  
代理人 上野 剛史  
代理人 市位 嘉宏  
代理人 太佐 種一  

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