• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 G06F
管理番号 1205723
審判番号 不服2006-25672  
総通号数 120 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2009-12-25 
種別 拒絶査定不服の審決 
審判請求日 2006-11-14 
確定日 2009-10-23 
事件の表示 特願2001-505305「部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法」拒絶査定不服審判事件〔平成12年12月28日国際公開、WO00/79408、平成15年 7月 2日国内公表、特表2003-520363〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、2000年5月13日(パリ条約による優先権主張外国庁受理1999年6月18日、ドイツ連邦共和国)を国際出願日とする出願であって、平成18年8月9日付けで拒絶査定がされ、これに対し、同年11月14日に拒絶査定不服審判の請求がされるとともに、同年12月13日付けで手続補正がなされたものである。

2.原査定の理由
一方、原査定の拒絶の理由の概要は、次のとおりである。
「本願は、明細書及び図面の記載が下記の点で不備と認められるから、特許法36条6項2号及び特許法36条4項に規定する要件を満たしていない。

(1)本願の請求項1から24の記載は、具体的にどのような技術的事項を意味するのかが不明確であり、該請求項1から24に係る発明が明確でない(36条6項2号)。
(2)本願の発明の詳細な説明は、当業者が請求項1から24に係る発明を実施することができる程度に明確かつ十分に記載されていない(36条4項)。」

3.当審の判断
(1)上記2.(1)の理由により本願が拒絶されるべきか否かについて
ア.平成18年12月13日付けの手続補正による補正後の特許請求の範囲の請求項1の記載は、以下のとおりである。
「中央データベース(CD)を備えた中央システム(CS)とローカルデータベース(LD)を備えた複数のノードシステム(NS)とを有するオフライン分散型データベースネットワークシステム(DBNS)におけるデータメンテナンス方法において、
各ノードシステム(NS)の各ローカルデータベース(LD)は互いに少なくとも一部異なる中央データベース(CD)からのデータを有しており、
次の各ステップ、すなわち
(a)ローカルデータベース(LD)または中央データベース(CD)に記憶されているデータに対する変更情報が複数のノードシステム(NS)で登録されるステップ、
(b)オンラインコネクションが形成されたときに、変更情報を含むリプリケーションオブジェクトを少なくとも1つのノードシステム(NS)から中央システム(CS)へまたは中央システム(CS)からノードシステム(NS)へ伝送するステップ、
(c)オンラインコネクションの存在しないときに、伝送のために、変更情報を含むリプリケーションオブジェクトを準備するステップ、
(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ
を有し、
ここで前記ルックアップテーブル(LUT)は前記変更情報を含むリプリケーションオブジェクトを宛先としての伝達相手先のノードシステムへ割り当てるものであり、
少なくとも2つのタイプのルックアップテーブルが設けられており、そのうち第1のタイプ(B‐LUT)は前記リプリケーションオブジェクトのインスタンスに依存しないタイプと宛先との対応関係を含み、第2のタイプ(O‐LUT)は前記リプリケーションオブジェクトのインスタンスと宛先との対応関係を含む
ことを特徴とするオフライン分散型データベースネットワークシステムにおけるデータメンテナンス方法。」

イ.上記補正後の請求項1の記載において、当該発明が明確であるかどうかを検討するに、当審は以下の理由で明確ではないと判断する。
すなわち、請求項1に記載されている「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」について、上記「変更情報」は、同じ請求項1の「(a)ローカルデータベース(LD)または中央データベース(CD)に記憶されているデータに対する変更情報が複数のノードシステム(NS)で登録されるステップ」の記載から「ローカルデータベース(LD)または中央データベース(CD)に記憶されているデータに対する変更情報」であると解されるが、該「ローカルデータベース(LD)または中央データベース(CD)に記憶されているデータ」と、上記二つのルックアップテーブルとの関係が請求項1には何ら記載されていないから、上記請求項1の記載のみでは、上記「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」に規定される具体的処理内容が明らかではない。
そして、上記「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」に規定される具体的処理内容が明らかでないという事情は、発明の詳細な説明を参酌しても変わらない。
すなわち、発明の詳細な説明には上記「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」に関連する記載として、「ステップ907?909は処理されたBDocのルックアップテーブルで必要な更新を行うために用いられる。変更情報の宛先が不変のままであるかぎり、LUTの変更は必要ない。したがってまずステップ907で旧い宛先がLUTから読み出され、ステップ908で最新の宛先と旧い宛先との比較が行われ、付加された宛先すなわち新宛先ともはや最新ではない宛先すなわち旧宛先とが求められる。」(【0119】)などの記載は認められるもののそれらの記載によっても上記「ローカルデータベース(LD)または中央データベース(CD)に記憶されているデータ」と二つのルックアップテーブルとの関係は不明なままであり、上記「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」に規定される具体的処理内容は依然として明らかではない。
なお、上記点は平成18年1月17日付け拒絶理由通知書の[ 理由2 ]の(3)、拒絶査定の備考欄の[ 理由2について ]の(2)、及び平成20年12月3日付けの審尋書に引用した前置報告書の[ 理由2について ]の各欄で、それぞれ、「請求項1に記載の『少なくとも1つのルックアップテーブルを変更情報を考慮してリアライメントアルゴリズムにより更新する』の文言について、該文言からは、ルックアップテーブルを更新するために具体的にどのような制御を行うのかについての技術的事項が何ら特定されないから、請求項1?24に係る発明が全体として技術的意義を為さず、不明確である。」、「上記手続補正書による補正後の請求項1に記載の『少なくとも1つのルックアップテーブル(LUT)を前記変更情報に基づいて更新する』の文言について、該文言からは、ルックアップテーブルを更新するために具体的にどのような制御を行うのかについての技術的事項が依然として何ら特定されず、不明確である。」、「補正後の請求項1に記載の『ルックアップテーブル(LUT)を前記変更情報に基づいて更新する』の文言からは、ルックアップテーブルを更新するために具体的にどのような制御を行うのかについての技術的事項が何ら特定されず、依然として不明確である。」、のように具体的に指摘されていたにもかかわらず、審判請求人は「本発明における変更情報の複製は、リプリケーションオブジェクトのタイプごとに、すなわち、図6のバルク型リプリケーション、図7のインテリジェント型リプリケーション、または図8の従属性リプリケーションにしたがって行われます。次いでこれらのリプリケーションオブジェクトのタイプを踏まえ、図9?図12のリアライメントステップが行われます。(中略)出願人は、本明細書において、CRMシステム(Customer Relation Management System)の実施例を挙げ、本発明のコンセプトを説明しております。その詳細な内容は当該分野の技術者が本明細書を注意深く読むことにより理解されるはずであります。」(平成18年7月20日付け意見書)、「ここで中央システムは当該のリプリケーションオブジェクトの変更情報に基づいて、比較により、宛先割り当てを行う2つのルックアップテーブルを更新します。ここで、本願発明では特に、2つのルックアップテーブルを用いています。第1のルックアップテーブルB-LUTはリプリケーションオブジェクトのインスタンスに依存しないタイプ、例えば製品基本データと宛先との対応関係を表しており、第2のルックアップテーブルO-LUTはリプリケーションオブジェクトのインスタンス、例えば顧客住所変更情報と宛先との対応関係を表しております。」(平成18年12月13日付け手続補正書(方式))、「CRMシステムを利用している外勤社員の担当している或る顧客について、顧客側の担当者が変更されるケースを考えてみます。こうした変更は他の全ての外勤社員へ伝達されます。このときにリプリケーションが行われます。リプリケーションにおいては、当該の変更情報を相応の宛先へ転送するだけではふつう充分でなく、宛先割り当てを行うルックアップテーブルも相応に更新する必要がでてきます。このとき、リプリケーションオブジェクト、特にそのタイプIDと更新のIDとによって、インスタンスに依存しないタイプの第1のルックアップテーブルB-LUT、例えば製品基本データと宛先との対応関係を表すルックアップテーブルと、インスタンスに依存する第2のルックアップテーブルO-LUT、例えば顧客住所変更情報と宛先との対応関係を表すルックアップテーブルとが区別されます。第1のルックアップテーブルB-LUTはインスタンスに依存せず迅速に処理可能であるため、区別することに大きな益があるからです。ここで、上述したリプリケーションのフローは当初の図6?図8ならびに当初明細書翻訳文の段落0078?段落0103に示されております。また、上述したリプリケーション動作において、リアライメントモジュールの実行する更新・挿入・消去のプログラムフローが当初の図9?図12ならびに当初明細書翻訳文の段落0104?段落0136に示されております。」(平成21年3月2日付け回答書)、などと漠然とした主張をするのみで、上記点に関する具体的説明を何ら行っていないものである。
以上のとおりであるから、上記補正後の請求項1に係る発明は明確でない。

(2)上記2.(2)の理由によって本願が拒絶されるべきか否かについて
上述したように、本願の発明の詳細な説明の記載を参酌しても上記「(d)中央システム(CS)が変更情報の与えられる前のデータと変更情報の与えられた後のデータとを比較することにより自身に備えられた少なくとも2つのルックアップテーブル(LUT)を前記変更情報に基づいて更新するステップ」に規定される具体的処理内容は明らかでない。したがって、本願発明の詳細な説明は当業者が本願の請求項1に係る発明を実施できる程度に明確かつ十分に記載されているとは言えない。

4.むすび
以上のとおり、本願の請求項1に係る発明は明確でなく、発明の詳細な説明の記載は該請求項1に係る発明を実施することができる程度に明確かつ十分に記載したものではない。
したがって、本願は、他の請求項について検討するまでもなく、特許法第36条6項2号及び特許法第36条4項に規定される要件を満たしていないので拒絶されるべきものである。
よって、結論のとおり審決する。
 
審理終結日 2009-05-20 
結審通知日 2009-05-27 
審決日 2009-06-09 
出願番号 特願2001-505305(P2001-505305)
審決分類 P 1 8・ 536- Z (G06F)
P 1 8・ 537- Z (G06F)
最終処分 不成立  
前審関与審査官 野田 佳邦丹治 彰相崎 裕恒  
特許庁審判長 小曳 満昭
特許庁審判官 田口 英雄
池田 聡史
発明の名称 部分的に複製されるデータベースシステムのネットワークにおけるデータメンテナンス方法  
代理人 矢野 敏雄  
代理人 山崎 利臣  
代理人 久野 琢也  

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