ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 判定 審理一般(別表) 属さない(申立て成立) G06F |
|---|---|
| 管理番号 | 1229896 |
| 判定請求番号 | 判定2010-600048 |
| 総通号数 | 134 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許判定公報 |
| 発行日 | 2011-02-25 |
| 種別 | 判定 |
| 判定請求日 | 2010-08-16 |
| 確定日 | 2011-01-08 |
| 事件の表示 | 上記当事者間の特許第4313845号の判定請求事件について、次のとおり判定する。 |
| 結論 | (イ)号図面及びその説明書に示す「マルチインスタンス・インメモリ・データベース」は、特許第4313845号発明の技術的範囲に属しない。 |
| 理由 |
1.請求の趣旨 本件判定請求の趣旨について、本件判定請求書の請求の趣旨の欄には、「イ号図面並びにその説明書に示す「データ分散の方式」は、特許第4313845号の技術的範囲に属する、との判定を求める」と記載されているところ、 (1)本件判定請求書の請求の理由の「本件特許発明の説明」欄では、『本件特許発明の「マルチインスタンス・インメモリ・データベース」は、特許明細書、図面の記載からみて、特許請求の範囲の請求項1及び請求項2に記載された次のとおりのものである。』として、「(7)データ・セット識別記号ロケーション情報変換部内のロケーション情報を書き換えることが可能であり、データ・セットの電子計算機をまたがる再配置が可能である」の構成要素を含んだものと特定され、該特定された構成要素は本件特許発明の請求項2に記載された事項に対応したものと認められ、かつ、本件特許発明の請求項2は請求項1の従属請求項であること、 (2)請求人は、平成22年11月22日付け上申書の「5-1).ソフトウェア特許出願における請求項の書き方の実務に関して」の欄において、「ソフトウェアはハードウェアと一緒でなければその効果を発揮しえないのですから、イ号物件もハードウェア上で稼働する装置であるということになります。」と主張していることから、 本件判定請求の趣旨は、甲第3号証に提示された「Oｒacle Cｏheｒence 3.5」というソフトウェアプログラムをコンピュータ上で動作させて得られるデータベース(以下、「イ号物件」という。)が、特許第4313845号明細書の特許請求の範囲の請求項2に係る発明の技術的範囲に属する、との判定を求めたものと認定する。 2.本件特許発明 (1)発明の構成 本件特許第4313845号の発明は、特許明細書及び図面の記載からみて、その特許請求の範囲の請求項1乃至請求項5に記載されたとおりのものであり、このうち、請求人が上記判定を求めるものは請求項2に係る発明(以下、「本件特許発明」という。)であり、請求項2は請求項1の従属請求項であることから、審理の都合上、その構成要件を符号を付けて分節すると、次のとおりである。 A.ネットワーク上に配置され、 B.外部からのデータを入力するための一個以上のデータ入力装置と、 C.前記入力されたデータの格納先を特定する一個以上のデータ格納部特定装置と、 D.前記入力されたデータを主記憶装置上に格納する一個以上のデータ格納装置と、 E.前記格納されたデータを検索加工する一個以上のデータ検索加工装置と、 F.前記検索加工されたデータを外部へ出力するための一個以上のデータ出力装置と、 G.を備える分散データベースを構成するマルチインスタンス・インメモリ・データベース・システムであって、 H.前記データ格納部特定装置は、 I.前記入力されたデータの一部ないし全部の情報を、前記入力されたデータの格納先であるデータ・セットを特定するためのデータ・セット識別記号に、ハッシング等のアルゴリズムを特定のパラメータで用いて、変換する前記入力されたデータのデータ・セット識別記号変換部と、 J.前記識別記号に対応する前記データ・セットのロケーションを特定するデータ・セット・ロケーション情報と前記データ・セット識別記号とを対応付けする前記データ・セットのデータ・セット識別記号ロケーション情報変換部と、 を有し、 K.前記データ格納装置は、 L.前記データ格納部ロケーション情報によって特定された前記データ格納装置において、当該データ格納装置上の主記憶装置上に存在するデータ・セットに前記入力されたデータを格納するデータ格納部と、 M.当該データ格納装置上の主記憶装置上に存在する前記データ・セットと同一の前記データ・セット・ロケーション情報を有し、前記データ格納装置に接続されている二次記憶装置上ないしネットワーク上の他の電子計算機上の主記憶装置上若しくは二次記憶装置上に一時的に待避させられている別のデータ・セットに挿入ないし抽出等のアクセス要求が発生した場合、前記当該データ格納装置上の主記憶装置上に存在する前記データ・セットを、前記データ格納装置に接続されている二次記憶装置上ないしネットワーク上の他の電子計算機上の主記憶装置上若しくは二次記憶装置上に一時的に待避させ、前記データ格納装置に接続された二次記憶装置上ないしネットワーク上の他の電子計算機上の主記憶装置上若しくは二次記憶装置上に一時的に待避されている前記アクセス要求が発生しているデータ・セットを召還するリソース・マネジメント部と、 を有し、 N.前記データ検索加工装置は、 O.前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定しながら、一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索するデータ検索部と、 P.前記データ検索部によって特定され抽出されたデータを、前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、加工対象となる前記データ・セットを特定しながら、変更ないし削除、若しくは一個以上の前記データ・セットに跨るデータ群のジョインないしプロジェクションないしソートないしマージ等のデータ加工を横断的におこなうデータ加工部と、 Q.前記データ検索部ないし前記データ加工部の処理に供される主記憶空間であるワークスペース部と、 R.前記データ格納部および前記データ検索部および前記データ加工部および前記ワークスペース部に供される主記憶空間のリソースが不足した際、ハードディスク装置等の二次記憶装置やネットワーク上の他の電子計算機上の主記憶装置や二次記憶装置のリソースを利用することによってリソース・マネジメントをおこなうリソース・マネジメント部と、 を有し、 S.前記データ格納部特定装置は、前記データ・セットのデータ・セット識別記号ロケーション情報変換部のロケーション情報を変更する機能を有し、前記データ格納装置の主記憶装置容量と格納データ・セットの大きさの関係を最適化して再配置することが可能な、 マルチインスタンス・インメモリ・データベース・システム。 3.イ号物件の構成 (1)甲第3号証に記載された事項 請求人が判定請求書の添付書類として提出した甲第3号証の各スライドには、下記の点が記載されている。 複数サーバに渡る分散キャッシュを構成したデータグリッド製品である点。(第5番目のスライドの内容参照) キャッシュ全体を論理的なパーティションに分割し、各パーティションをメンバIDによって区別されるキャッシュサーバJVMに割当てられ、KeyとValueからなるデータをキャッシュサーバJVMへ格納するときは、Keyの値から特定の計算ロジックによりパーティションIDを算出し、パーティションIDとメンバIDのマッピングから格納先のキャッシュサーバJVMのメンバIDを取得して、当該KeyとValueからなるデータを取得されたメンバIDに対応するキャッシュサーバJVMに格納され、また、パーティションIDとキャッシュサーバのマッピングは動的に維持される点。(第8番目のスライドの内容参照) 特定条件(ｐ＞=100)となるデータを検索するためのクエリを実行して、キャッシュに格納されているデータの中から、当該特定条件を満たすデータをクエリの結果セットとしてアプリケーションが取得する点。(第18番目のスライドの内容参照) (2)乙第2号証に記載された事項 被請求人が答弁書に代わる上申書の添付書類として提出した乙第2号証には、 Oｒacle Cｏheｒenceインメモリ-・データ・グリッ ドは、複数のサーバ間で共有される点。 Cｏheｒenceにおける分散キャッシュは、任意の数のクラス タ・ノード間で分散(パーティション化)されたデータのコレクショ ンとして定義される点。 分散キャッシュにアクセスするには、一般に、ネットワークを介し て別のクラスタ・ノードに接続する必要がある点。 が認められるので、これらを総合すると、Oｒacle Cｏheｒence 3.5をサーバ上で動作させて得られるデータベースは、インメモリ型のデータベースシステムであり、該データベースを構成する複数のサーバはネットワークを介して接続されているといえる。 (3)イ号物件の認定 上記甲第3号証、乙第2号証に記載された事項は、Oｒacle Cｏheｒence 3.5をサーバ上で動作させて得られるデータベースの構成が記載されているので、イ号物件である、「『Oｒacle Cｏheｒence 3.5』というソフトウェアプログラムをコンピュータ上で動作させて得られるデータベース」の構成は、上記(1)及び(2)の記載から、以下のとおりである。 a.ネットワークで接続された複数サーバに渡る分散キャッシュで構成されたインメモリー型データベースシステムであって、 b.Keyの値から特定の計算ロジックによりパーティションIDを算出する構成、 c.パーティションIDとメンバIDのマッピング、 d.前記マッピングによりメンバIDを取得して、当該KeyとValueからなるデータを取得されたメンバIDに対応するキャッシュサーバJVMに格納する構成、 e.特定条件となるデータを検索するためのクエリを実行して、キャッシュサーバJVMに格納されているデータの中から、当該特定条件を満たすデータをクエリの結果セットとして取得する構成、 f.パーティションIDとキャッシュサーバのマッピングは動的に維持される構成。 4.当審の判断 事案に鑑み、主要な争いとなっている構成要件O,P及びRについての充足を検討する。 (1)構成要件Oについて (1-1)当事者の主張 被請求人は、イ号物件が本件特許発明の構成要件Oを充足しないとし、答弁書に代わる上申書の6-5-3-1において、本件特許発明について、 「特許明細書および請求項の記載、ならびに辞書の『横断的』についての定義によれば、『横断的に検索する』とは、『データ検索部』が『複数のデータ・セットについて、あるデータ・セットから他のデータ・セットに跨ってデータを探すことで、格納データの検索を行うこと』を意味することは明らかであります」 と主張するとともに、イ号物件に対しては、甲第3号証(第9番目のスライドの内容)、乙第2号証(図15-1パーティション・キャッシュ環境でのget操作)等を根拠に、 「イ号物件は、オブジェクト指向システムに基づき、データを『オブジェクト』として格納する」ものであり、「オブジェクト指向データベースは、複数のデータ・セットにわたってデータ・セットのそれぞれで検索を行う必要はなく、効率よく情報のデータ検索を実行することが可能」となるものである。また、「請求人は、このような本件特許発明中の限定を一切無視しております。請求人は、このような「横断的に」との意義について言及しないばかりか、イ号物件が、いかにしてデータ・セットを横断的に検索するとされるのかという点にも言及しておりません。」 と主張している。 これに対して請求人は、イ号物件が本件特許発明の構成要件Oを充足しているとし、上申書において、 「甲第7-3号証には、パーティション・キャッシュについて以下のように記載されています。 すべてのデータをすべてのクラスタ・ノードに単にレプリケートす るだけのレプリケーション(Replicated)・キャッシュとは異なり、パ ーティション(Partitioned)・キャッシュ・サービスは、「分割と侵 出」アプローチ・・・下の図のようにクラスタ内のすべてのノード を横断(across)するデータ・セット(data set)に分割します。 これにより、前記答弁書「6-5-3-1 構成要件e1:イ号物件は、「・・・一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索する検索部」を充足しないにおける「横断的に」に関する議論は不毛であり、前記答弁書の作成者はイ号物件に関する正しい知識を持ち合わせていないということを図らずも露呈しております。」 と主張している。 (1-2)「横断的」な検索について 本件特許発明の構成要件Oでは、「データ検索部」が「横断的に」検索することが規定されているのに対し、イ号物件では、上記3.(3)に記載したように、検索に係る構成は構成eとして、 「e.特定条件となるデータを検索するためのクエリを実行して、キャッシュサーバJVMに格納されているデータの中から、当該特定条件を満たすデータをクエリの結果セットとして取得する構成」 が特定されている。 そして、イ号物件の「横断的」な検索について、被請求人は、(1-1)に記載したように甲第3号証(第9番目のスライドの内容)、乙第2号証(図15-1パーティション・キャッシュ環境でのget操作)等を根拠として、イ号物件は「横断的に」は検索を行わないと主張しているが、当該主張はgetメソッドに基づくデータの抽出についての言及であり、甲第3号証の第18番目のスライドの内容に記載されたクエリによる検索に対しては、答弁書に代わる上申書(33頁25行?26行)に、「単に、クエリが実行されていることを開示しているに過ぎません」とだけ主張しているが、イ号物件の「横断的」な検索について、getメソッドに基づくデータの抽出を根拠とした被請求人の主張、及び、具体的にイ号物件が横断的な検索を行っていることを立証していない請求人の主張は、何れも採用することはできない。 そこで、上記イ号物件の構成eについて検討する。 イ号物件は、KeyとValueからなるデータがキャッシュサーバJVMに格納されているものであるが(構成d)、上記構成eは、キャッシュサーバJVMに格納されている「KeyとValue」からなるデータの中から、特定条件となる値をValue部に含むデータを検索するものである。 また、イ号物件は、Keyの値によりネットワークで接続された複数サーバのうち何れかのキャッシュサーバJVMにデータが格納されるものであり、Value部のデータの値によって格納場所が特定されるものではない。 よって、クエリで特定される条件のデータは、特定の1つのキャッシュサーバJVMに格納されているとは限らないため、イ号物件の構成eは、クエリの実行により複数のキャッシュサーバJVMに対して検索を行うものと解される。 してみると、甲第3号証の第18番目のスライドの内容の記載に基づけば、イ号物件が「横断的」な検索を行うものであることは否定できない。 (1-3)「検索対象となる前記データ・セットを特定しながら」について 甲第3号証の第18番目のスライドの内容に記載されたクエリによる検索では、KeyとValueからなるデータにおけるKeyの値に基づいた特定条件により、クエリを実行してデータの検索を行うことは記載されていない。即ち、イ号物件の構成eでは、検索対象となるキャッシュサーバJVMを特定しながらクエリの実行による検索を行っていないので、本件特許発明の構成要件Oに規定された「検索対象となる前記データ・セットを特定しながら」に対応する構成を有してはいないことは明らかである。 (1-4)構成要件Oの充足性について 本件特許発明の構成要件Oは、「前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定しながら」、「一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索するデータ検索部」である。そして、上記(1-2)及び(1-3)において検討したように、イ号物件の構成eは、クエリの実行により複数のキャッシュサーバJVMに対して「横断的」な検索を行うことは否定できないものの、「検索対象となるキャッシュサーバJVMを特定しながらクエリの実行による検索は行っていない」ことは明らかであるので、イ号物件は構成要件Oを充足しない。 (2)構成要件Pについて (2-1)当事者の主張 被請求人は、答弁書に代わる上申書の6-5-3-1において、 「請求人は判定請求書において、少なくとも、以下の構成要件またはその一部について、言及しておりません」 として、言及していない構成要件の1つに、本件特許発明の構成要件Pの「データ加工部」をあげ、さらに、 「これら重要な構成要件について言及していない以上、請求人は判定請求において、イ号物件が本件特許発明の技術的範囲に属するとの立証を行っていないものであり、本来、かかる判定請求は、却下されてしかるべきものであります。」 と主張している。 これに対して請求人は、上申書において、 「前記答弁書には、『6-5-1 複数の構成要件について全く言及していない』と記載されていますが、本件特許の技術分野の当業者にとって自明である言葉に説明が為されていないだけですので、この主張にも理由がありません。」 と主張している。 (2-2)構成要件Pの構成について 構成要件Pでは、「データ加工を横断的におこなう」ことを規定しているが、本件特許公報(特許第4313845号公報)の発明の詳細な説明及び図面には、「データ加工」を「横断的」におこなうことが明示的に記載されていない。ただし「横断」に関する事項は、図面【図7】及び段落【0047】に、 「【図7】分割後複数データ・セットの横断統合セルフ・ジョイン機構説明図 分割された部品構成表の正展開を例とした横断統合セルフ・ジョイン機構の説明図」 「【0047】 図8は、図7に示された分割された部品構成表のデータ・セットから親部品番号3、16、18の親部品を製品として、BOMの正展開表801を示したものである。図7において、親部品番号3を与えられた製品は、前記データ・セット識別記号変換部701によって3の剰余系として識別番号0を得る。識別番号0は、前記データ・セット識別記号ロケーション情報変換部702によってロケーション情報192.168.1.10を得る。192.168.1.10のロケーション情報を与えられた電子計算機上のデータ格納装置内のデータ格納部703に格納されたデータ・セット内の部品構成表の一部から部品番号8、10、12を子部品としていることを得る。部品番号8を親番号とする部品が前記データ格納部703に格納されたデータ・セット内の部品構成表の一部内には無いため、部品番号8を前記データ・セット識別記号変換部701の入力値として与えることにより識別記号2を得る。識別記号2から前記データ・セット識別記号ロケーション情報変換部702によってロケーション情報192.168.1.30を得る。192.168.1.30のロケーション情報を与えられた電子計算機上のデータ格納装置内のデータ格納部705に格納されたデータ・セット内の部品構成表の一部から部品番号11、13、20を子部品としていることを得る。部品番号11を親番号とする部品構成表のデータはデータ格納部705に格納されたデータ・セット内に存在するため、そのまま検索し、子部品を持たない最末端部品であることを確認する。部品番号13を親番号とする部品はデータ格納部705に格納されたデータ・セット内に存在しないため、再度、部品番号13を前記データ・セット識別記号変換部701の入力値として与えることにより識別記号1を得る。識別記号1から前記データ・セット識別記号ロケーション情報変換部702によってロケーション情報192.168.1.20を得る。192.168.1.20のロケーション情報を与えられた電子計算機上のデータ格納装置内のデータ格納部704に格納されたデータ・セット内の部品構成表の一部から子部品を持たない最末端部品であることを確認する。部品番号20を親番号とする部品構成表のデータはデータ格納部705に格納されたデータ・セット内に存在するため、そのまま検索し、部品番号17を子部品としていることを得る。部品番号17を親番号とする部品構成表のデータはデータ格納部705に格納されたデータ・セット内に存在するため、そのまま検索し、子部品を持たない最末端部品であることを確認する。同様のプロセスを部品番号10、12を持つものについて行い、請求項5で示されているように、図8で示されたBOMの正展開表801の中のレベル0(以下L0)の値が3のもの、すなわち部品番号3をトップ・レベルにもつ製品のBOMの正展開表をえることが可能であることを示している。」 と記載されている。 そこで、図面【図7】及び段落【0047】の記載に基づいて、本件特許発明のデータ加工を「横断的」におこなうことについて検討すると、段落【0047】には、与えられた部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、得られた識別番号に対応するデータ・セットから当該部品番号の部品と親子関係にある子部品の部品番号を検索し、次に、子部品の部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、他のデータ・セットから当該部品番号の部品と親子関係にある子部品の部品番号を求め、求められた部品番号から同様に関係のある部品番号を求めることで、横断統合セルフジョインを行うことが記載されているとといえる。 よって、本件特許発明のデータ加工を「横断的」におこなうとは、データ検索部によって特定され抽出されたデータにより、抽出されたデータが格納されたデータ・セットとは異なるデータ・セットが特定されてデータ加工をおこなうことであると認められる。 以上から、構成要件Pは、構成要件Oのデータ検索部で横断的に抽出されたデータに対して、検索時と同一アルゴリズムを同一のパラメータを用いて、抽出されたデータが格納されたデータセットとは異なるデータセットを特定することで、データ加工を横断的に行うものであると解され、請求人が主張するような「一般的な用語の説明」を特定したものとは言えない。 (2-3)イ号物件のデータ加工部について イ号物件では、検索に係る構成eとして、 「e.特定条件となるデータを検索するためのクエリを実行して、キャッシュサーバJVMに格納されているデータの中から、当該特定条件を満たすデータをクエリの結果セットとして取得する構成」 が特定されており、該構成eでは、クエリの実行により検索されたデータに対して特定の計算ロジックによりパーティションIDを算出する構成を有してはいない。当然、パーティションIDを算出する構成を有していないので、算出されたパーティションIDに基づいて他のキャッシュサーバJVMからデータの検索を行いデータの加工を行う構成も有していない。同様に、請求人が提出した甲第3号証には、クエリの実行により検索されたデータに対して特定の計算ロジックによりパーティションIDを算出する点、該算出されたパーティションIDに基づいて他のキャッシュサーバJVMからデータの検索を行いデータの加工を行う点は、何ら記載されていない。 (2-4)構成要件Pの充足性について 上記(2-3)において検討したように、イ号物件は、「クエリの実行により検索されたデータに対して特定の計算ロジックによりパーティションIDを算出する構成」、「算出されたパーティションIDに基づいて他のキャッシュサーバJVMからデータの検索を行いデータの加工を行う構成」を有していないので、イ号物件は、本件特許発明の構成要件Pである、 「前記データ検索部によって特定され抽出されたデータを、前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、加工対象となる前記データ・セットを特定しながら、変更ないし削除、若しくは一個以上の前記データ・セットに跨るデータ群のジョインないしプロジェクションないしソートないしマージ等のデータ加工を横断的におこなうデータ加工部」を充足しない。 (3)構成要件Rについて (3-1)当事者の主張 被請求人は、イ号物件が本件特許発明の構成要件Rを充足しないとし、答弁書に代わる上申書の6-5-3-3において、概略、 「本件特許の請求項1は、「データ格納装置」の一部の構成要件d2の「リソース・マネッジメント部」と、「データ検索加工装置」の一部の構成要件e4の「リソース・マネッジメント部」の2つの異なった「リソース・マネッジメント部」が記載されている。そして、構成要件e4の「リソース・マネッジメント部」は、4つの異なるユニット(部)である「データ格納部」、「データ検索部」、「データ加工部」及び「ワークスペース部」により使用される主記憶空間が不足した際に、追加のメモリリソースを手当てするものであるから、前記4つの異なるユニット(部)により使用される主記憶空間の量をモニタしなければならない。これに対して、イ号物件は前記4つの異なるユニット(部)により使用される主記憶空間の量をモニタしておらず、データの格納のために使用される主メモリの量は固定値に設定され動的に変化するものではない。また、請求人は、甲第3号証の第18番目のスライドが、構成要件e4を含む構成要件Eのデータ検索・加工装置を開示していると主張しているが、引用されたスライドには、単位クエリが実行されていることが開示されているだけで、リソース・マネッジメント部はなんら開示されていない。」 と主張している。 これに対して請求人は、イ号物件が本件特許発明の構成要件Rを充足しているとし、上申書において、 「さて、『6-5-3-3 構成要素e4: イ号物件は、『データ検索加工装置』におけるリソース・マネジメントをおこなう『リソース・マネジメント部』を充足していない』と言及していますが、およそソフトウェア製品において、特に主記憶装置の利用の多寡が刻々と変化する「データ検索加工装置」について、健全なプロダクト製品であれば、主記憶装置の容量不足によるハングアップは許されるものではないため、何らかの『リソース・マネジメント部』を備えていることは当業者の常識であり、あくまでもイ号物件が、『データ検索加工装置』に何らかの『リソース・マネジメント部』をも充足しないと強弁するのであれば、イ号物件は可用性に欠けた欠陥商品であることを宣伝していることと同じです。もちろん、均等論における、当業者の常識であり、置き換え可能で、本質的でない部分ではないものであるということも書き添えておきます。 『6-5-3-3(1)、6-5-3-3(2)、6-5-3-3(3)に関しても同様に、健全なプロダクト製品であれば、主記憶装置の容量不足によるハングアップは許されるものではないため、何らかの『リソース・マネジメント部』を備えていることは当業者の常識であり、被請求人に、何らかの『リソース・マネジメント部』なしにイ号物件の可用性を保つ方法が存在するならば、それについて被請求人にご教示いただければと考えております。」 と主張している。 (3-2)構成要件Rの充足性について イ号物件では、検索に係る構成として、 「e.特定条件となるデータを検索するためのクエリを実行して、キャッシュサーバJVMに格納されているデータの中から、当該特定条件を満たすデータをクエリの結果セットとして取得する構成」 で特定される構成eを有するが、該構成eは、本件特許発明の構成要件Rである、 「前記データ格納部および前記データ検索部および前記データ加工部および前記ワークスペース部に供される主記憶空間のリソースが不足した際、ハードディスク装置等の二次記憶装置やネットワーク上の他の電子計算機上の主記憶装置や二次記憶装置のリソースを利用することによってリソース・マネジメントをおこなうリソース・マネジメント部」 の構成を有してはいない。 また、請求人が提出した甲第3乃至9号証には、本件特許発明の「データ格納部」、「データ検索部」、「データ加工部」、「ワークスペース部」の4つの構成要件に限定された対応するOｒacle Cｏheｒence 3.5の構成に供される主記憶空間について、リソースが不足した際にリソース・マネジメントをおこなう点は、記載されていない。 さらに、請求人は、本件特許発明の「データ格納部」、「データ検索部」、「データ加工部」、「ワークスペース部」の4つの構成要件に限定された対応するOｒacle Cｏheｒence 3.5の構成に供される主記憶空間について、リソースが不足した際にリソース・マネジメントをおこなう点が、甲第3乃至9号証等の証拠において開示されていることを立証してはいない。 してみると、イ号物件は、本件特許発明の構成要件Rを充足しない。 (4)均等の判断 本件特許発明の目的及び効果について本件特許公報(特許第4313845号公報)には、 「【0015】 そこで、本発明は、本データベース・システムにおいて大規模データ・セットが小規模データ・セットに分割されていても、仮想的に統合して単一の大規模データ・セットとして取扱えるようにし、前記データベース・システムを運用しながら、前記データベース・システムを構成するネットワーク上に配置された一個以上の電子計算機の台数ないし前記電子計算機に搭載されているCPUの性能ないし前記CPUの個数ないし前記電子計算機に搭載されている主記憶装置の容量等のリソースの変化に呼応して、前記分割されたデータ・セットのロケーションをダイナミックに最適配置していくことを目的とする。」 「【発明の効果】 【0021】 これにより、数百テラ・バイト・オーダー・レベルの大規模データ・セットからの抽出ないしソートないしマージないしジョインないしプロジェクションも高速に実行することが可能となる。」 と記載されている。 本件特許発明の構成要件Oの「前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定しながら、一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索するデータ検索部と」は、「本データベース・システムにおいて大規模データ・セットが小規模データ・セットに分割されていても、仮想的に統合して単一の大規模データ・セットとして取扱えるようにし」という本件特許発明の目的を達成するために欠くことができないものであるから、この構成要件Oは発明の本質的部分に相当するものである。 また、本件特許発明の構成要件Pの「前記データ検索部によって特定され抽出されたデータを、前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、加工対象となる前記データ・セットを特定しながら、変更ないし削除、若しくは一個以上の前記データ・セットに跨るデータ群のジョインないしプロジェクションないしソートないしマージ等のデータ加工を横断的におこなうデータ加工部と」は、「数百テラ・バイト・オーダー・レベルの大規模データ・セットからの抽出ないしソートないしマージないしジョインないしプロジェクションも高速に実行することが可能となる。」という本件特許発明の効果を奏するために欠くことができないものであるから、この構成要件Pは発明の本質的部分に相当するものである。 してみると、本件特許発明の構成要件O及びPにおけるイ号物件との相違点は、発明の本質的な部分であるから、均等の判断における「発明の非本質的部分」の要件を満たさない。 (5)まとめ 以上のとおり、イ号物件は、本件特許発明の構成要件O、P及びRを充足しないから、他の構成要件を検討するまでもなく、イ号物件は本件特許発明の技術的範囲に属するということはできない。 また、上記(4)のとおり、イ号物件は、本件特許発明の構成と均等なものであるということはできない。 5.むすび 以上のとおりであるから、イ号物件は、本件特許発明の技術的範囲に属しない。 よって、結論のとおり判定する。 |
| 判定日 | 2010-12-28 |
| 出願番号 | 特願2004-308853(P2004-308853) |
| 審決分類 |
P
1
2・
0-
ZA
(G06F)
|
| 最終処分 | 成立 |
| 前審関与審査官 | 高瀬 勤 |
| 特許庁審判長 |
田口 英雄 |
| 特許庁審判官 |
飯田 清司 池田 聡史 |
| 登録日 | 2009-05-22 |
| 登録番号 | 特許第4313845号(P4313845) |
| 発明の名称 | マルチインスタンス・インメモリ・データベース |
| 代理人 | 酒井 將行 |
| 代理人 | 矢倉 千栄 |
| 代理人 | 三輪 雅彦 |
| 代理人 | 長沢 幸男 |
| 代理人 | 森田 俊雄 |
| 代理人 | 深見 久郎 |