ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 判定 同一 属さない(申立て不成立) G06F |
|---|---|
| 管理番号 | 1246288 |
| 判定請求番号 | 判定2011-600021 |
| 総通号数 | 144 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許判定公報 |
| 発行日 | 2011-12-22 |
| 種別 | 判定 |
| 判定請求日 | 2011-05-30 |
| 確定日 | 2011-11-04 |
| 事件の表示 | 上記当事者間の特許第4313845号の判定請求事件について、次のとおり判定する。 |
| 結論 | イ号図面及びその説明書に示す「『Oｒacle Cｏheｒence 3.5』というソフトウェアプログラムをコンピュータ上で動作させて得られるデータベース」は、特許第4313845号発明の技術的範囲に属しない。 |
| 理由 |
1.請求の趣旨 本件判定請求の趣旨は、添付書類[5](判定注、表記の都合上、丸数字は[]を用いて表す。以下同じ。)「イ号図面および説明書」に提示された「Oｒacle Cｏheｒence 3.5」というソフトウェアプログラムをコンピュータ上で動作させて得られるデータベース(以下、「イ号物件」という。)が、特許第4313845号明細書の特許請求の範囲の請求項2に係る発明の技術的範囲に属する、との判定を求めるものである。 2.本件特許発明 本件特許第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)「イ号図面および説明書」の記載事項について 請求人は、「イ号図面および説明書」の第6頁において、イ号物件に関する書籍の日本語翻訳本「Oｒacle Cｏheｒence 入門」によって、「イ号物件の詳細を知るに至り新たな事実を認識することができるようになった。」と主張し、第7頁乃至第9頁の「1.イ号における外部データのロードの説明」では、イ号物件におけるデータ格納の構成を説明し、第10頁乃至第16頁の「2.イ号において実装される基本的な検索方法の説明」では、イ号物件におけるデータ検索の構成を説明し、第17頁乃至第24頁の「3.イ号において実装される基本的な加工方法の説明」では、イ号物件におけるデータ加工の構成を説明しているので、各説明の記載内容について確認する。 「2.イ号において実装される基本的な検索方法の説明」では、甲第19号証に基づくとされる図8、甲第3号証の第8番目のスライドに基づくとされる図9を利用してイ号物件の検索方法の説明を行っている。 しかしながら、甲第19号証には、Oｒacle株の株式分割の具体的処理が記載されているのみであり、上記図8に記載された「USA」等のKEY値から各KEYに対応したVALUE値を取得することが記載されておらず、また、「イ号図面および説明書」には、甲第19号証に記載された各処理と上記図8に記載された各構成及び各構成に基づく処理との対応関係が示されていない。 さらに、甲第3号証の第8番目のスライドには、上記図9に記載された各メンバ毎に特定のパーティションが関係付けられた構成は記載されていない。 「3.イ号において実装される基本的な加工方法の説明」では、甲第19号証に基づくとされる図10及び図11、甲第3号証の第8番目のスライドに基づくとされる図12を利用して、イ号物件の加工方法の説明を行っている。 しかしながら、甲第19号証には、Oｒacle株の株式分割の具体的処理が記載されているのみであり、上記図10及び図11に記載された「USA」等のKEY値から各KEYに対応したVALUE値を取得してデータの変更または削除することは記載されておらず、また、「イ号図面および説明書」には、甲第19号証に記載された各処理と上記図10及び図11に記載された各構成及び各構成に基づく処理との対応関係が示されていない。 さらに、甲第3号証の第8番目のスライドには、上記図12に記載された各メンバ毎に特定のパーティションが関係付けられた構成は、記載されていない。 「4.イ号が提供する効果的な検索方法の説明」では、甲第20号証に基づく図13、甲第21号証に基づく図14、甲第22号証に基づく図15及び図16、甲第23号証に基づく図17及び図18を利用して、イ号物件の検索方法の説明を行っている。 しかしながら、甲第20号証には、上記図13に記載されたエクストラクタによる処理結果がメンバに分かれたままフィルタに渡されることは記載されておらず、甲第21号証には、上記図14に記載されたメンバごとに並行フィルタリングがなされることが記載されておらず、甲第22号証には、上記図15に記載されたenｔｒｙSeｔ(FILTER)メソッド内でgeｔ(KEY)メソッドを呼び出すこと、及び上記図16に関する処理は記載されていない。 また、甲第23号証の「5.6 Cｏheｒenceクエリの制限」に、 「これまでの例の中で見てきたフィルタは、すべて1つのキャッシュに対して評価されるものだった点にもしかしたら気づいたかもしれません。これはCｏheｒenceのクエリ機構の制限の1つです。テーブルのjｏin相当の処理を実行し、これに対してクエリを実行するというようなことはできません」 と記載されているので、甲第23号証の「5.5 クエリ・パフォーマンス向上のためのインデックスの使用」欄に記載されたフィルタを用いて作成されたインデックスは、1つ1つのキャッシュメンバ毎に作成されたインデックスであると認められるので、甲第23号証には、図17に記載された他のメンバに属するKEY値までもVALUEに含むようなインデックスを作成することは記載されておらず、また、そのようなインデックスを用いて図18に記載された検索を行うことも記載されていない。 さらに、「イ号図面および説明書」には、甲第20号証乃至甲第23号証に記載された各処理と上記図13乃至図18に記載された各構成及び各構成に基づく処理との対応関係が示されていない。 「5.イ号が提供する効果的な加工方法の説明」では、甲第24号証に基づく図19、及び図20を利用して、イ号物件の加工方法の説明を行っている。 しかしながら、甲第24号証には、Oｒacle株の株式分割の処理が記載されているが、上記図19には記載された「DEU」等のキーについてフィルタ処理することは記載されていない。 また、上記図20には、リポジトリの作成について記載されているものの、リポジトリの根拠とされた甲第25号証には、「イ号図面および説明書」の第36頁?第37頁に記載された、 「データ検索部によって特定されたKey要素の値のリストのそれぞれの値をKeyの値として順に、Keyの値から特定の計算ロジックによりパーティションIDを算出する構成により、該選択されたデータが格納されているパーティションを特定しながら、さらにパーティションIDとメンバIDのマッピングによって該パーティションが配置されているキャッシュサーバJVMを特定しながら、ジョインを、Key要素の値のリスト内のKey要素の値に応じて対象パーティションを変えながら行うため、パーティションを横断的に、ジョインを行うこととなるデータ加工部をその構成要素とすること」 に対応する事項が記載されていない。 さらに、「イ号図面および説明書」には、甲第24号証に記載された各処理と上記図19に記載された各構成及び各構成に基づく処理との対応関係が示されていない。 してみると、「イ号図面および説明書」において、請求人が立証したとしているイ号物件の構成は、提出された各甲号証の記載に基づいたものとはいえないので、「イ号図面および説明書」に記載された請求人のイ号物件の認定を採用することはできない。 (2)甲第3号証に記載された事項 請求人が判定請求書の証拠方法として提出した甲第3号証には、下記の点が記載されている。 (2-1)第5番目のスライドに記載された事項 イ号物件が、複数サーバに渡る分散キャッシュを構成したデータグリッド製品である。 (2-2)第8番目のスライドに記載された事項 イ号物件では、キャッシュ全体を論理的なパーティションに分割し、各パーティションをメンバIDによって区別されるキャッシュサーバJVMに割当て、KEYとVALUEからなるデータをキャッシュサーバJVMへ格納するときは、KEYの値から特定の計算ロジックによりパーティションIDを算出し、パーティションIDとメンバIDのマッピングから格納先のキャッシュサーバJVMのメンバIDを取得して、当該KEYとVALUEからなるデータを取得されたメンバIDに対応するキャッシュサーバJVMに格納する。また、パーティションIDとキャッシュサーバのマッピングは動的に維持される。 (2-3)第9番目のスライドに記載された事項 geｔメソッドによりデータアクセスを行う場合には、KEY値から計算ロジックによりパーティションIDを特定し、特定したパーティションIDからマッピングによりメンバIDを特定してKEY値に対応したデータが取得される。 (3)甲第10号証に記載された事項 請求人が判定請求書の証拠方法として提出した甲第10号証には、 ・Oｒacle Cｏheｒenceインメモリ-・データ・グリ ッドは、複数のサーバ間で共有される点。 ・Cｏheｒenceにおける分散キャッシュは、任意の数のクラ スタ・ノード間で分散(パーティション化)されたデータのコレ クションとして定義される点。 ・分散キャッシュにアクセスするには、一般に、ネットワークを介 して別のクラスタ・ノードに接続する必要がある点。 が記載されているので、Oｒacle Cｏheｒence 3.5をサーバ上で動作させて得られるデータベースは、インメモリ型のデータベースシステムであり、該データベースを構成する複数のサーバはネットワークを介して接続されているといえる。 (4)甲第19号証に記載された事項 本件特許発明では、構成要件Pにおいて構成要件Oのデータ検索の結果に対してデータ加工を行っており、この処理に対応した事項については、請求人が判定請求書の証拠方法として提出した甲第19号証に下記の点が記載されている。 [1]フィルタにより特定の条件に該当するKEY値を取得する。 [2]取得された1つのKEY値について、geｔメソッドにより KEY値に対応するVALUE値を検索する。 [3]検索されたVALUE値を変更する。 [4]取得された残りのKEY値について、上記[2]のデータ検 索と上記[3]のデータ加工を繰り返す。 (5)甲第32号証に記載された事項 スワッピングは、主記憶空間全体のリソースが不足した際に行われるものであること、そして、請求人が判定請求書の証拠方法として提出した甲第32号証には、Oｒacle Cｏheｒence 3.5に関して、 「スワップ領域を介して頻繁に移動が発生していると、Cｏheｒenceのパフォーマンスに大きく影響する可能性があります。」 と記載されている。 (6)イ号物件の認定 上記甲第3号証、上記甲第10号証、上記甲第19号証、上記甲第32号証に記載された事項には、Oｒacle Cｏheｒence 3.5をサーバ上で動作させて得られるデータベースの構成が記載されているので、イ号物件である、「『Oｒacle Cｏheｒence 3.5』というソフトウェアプログラムをコンピュータ上で動作させて得られるデータベース」の構成は、上記(1)乃至(5)の記載に基づけば、以下のとおりであるいえる。 a.ネットワークで接続された複数サーバに渡る分散キャッシュで構成 されたインメモリー型データベースシステムであって、 b.KEYの値から特定の計算ロジックによりパーティションIDを算 出する構成、 c.パーティションIDとメンバIDをマッピングする構成、 d.前記マッピングによりメンバIDを取得して、当該KEYとVAL UEからなるデータを取得されたメンバIDに対応するキャッシュサ ーバJVMに格納する構成、 e.各KEYの値から特定の計算ロジックによりパーティションIDを 算出し、パーティションIDとメンバIDのマッピングにより、各K EYの検索対象となるメンバIDを特定して各KEYの値に対応した VALUEの値を特定されたメンバIDに対応するキャッシュサーバ JVMから検索する構成、 f.検索された各VALUEの値を変更する構成、 g.主記憶空間のリソースが不足した際に、スワッピング機能を使用す る構成、 h.パーティションIDとキャッシュサーバのマッピングは動的に維持 される構成、を有する、インメモリー型データベースシステム。 4.当審の判断 本判定請求は、平成22年8月16日に本件請求人が判定請求した判定2010-600048号において、該判定のイ号物件が本件特許発明の技術的範囲に属さないことの根拠とされた、構成要件O、構成要件P、構成要件Rについて、イ号物件がこれら各構成要件を充足している点を主に主張していることに鑑み、以下、イ号物件が、本件特許発明の構成要件O、構成要件P、構成要件Rをそれぞれ充足しているかについて検討を行う。 (1)構成要件O (1-1)本件特許発明における「横断的に検索する」の意味について 本件特許発明の「データ検索部」は、上記2の構成要件Oに記載されているように、 「前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定しながら、一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索するデータ検索部」 であるところ、「横断的に」の意味について、判定請求書では第9頁に、 「したがって、複数件のデータの集まりから選択条件に該当するデータの集まりを抽出する検索を行うためには、『検索対象となる前記データ・セットを特定しながら、一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索する』ことになる。 ここで『横断的に』は、複数のデータ・セットが横方向に並んでいる様子を観念的に想い浮かべるものとして、そのデータ・セットの並びの端から端までを動的にアクセス対象となるデータ・セットに変えていく様を表している単純な形容詞として使用している。」 と記載されている。 この記載からみて、請求人は、「横断的に検索する」ことの意味を、 「全てのデータ・セットがアクセス対象となり、そのうち一個でもアクセスすれば『横断的に検索する』ことになる」 ことを主張していると認められる。 しかしながら、「横断的に」という一般的な表現から解釈すれば、少なくともデータ・セットを1個だけアクセスすることが、請求人が主張するような「横断的に検索する」ことに該当するとはいえず、かといって、アクセスするデータ・セットが2個以上であれば「横断的に検索する」といえるのか、または、全てのデータ・セットをアクセスして初めて「横断的に検索する」といえるのかまでは、特許請求の範囲に記載された構成要件Oから特定することができない。 そこで、「横断的に検索する」ことについて発明の詳細な説明を参酌すると、本件特許明細書の【発明の詳細な説明】には、「データ検索」を「横断的」におこなうことが明示的に記載されていない。ただし、「横断」に関する事項としては、【図面の簡単な説明】に、 「【図7】分割後複数データ・セットの横断統合セルフ・ジョイン機構説明図 分割された部品構成表の正展開を例とした横断統合セルフ・ジョイン機構の説明図」 と記載され、該【図7】に示される情報処理内容については、段落【0047】に以下のとおりの記載がある。 「【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の正展開表をえることが可能であることを示している。」 そうすると、上記段落【0047】は「横断統合セルフジョイン」即ち本件特許発明の「データ加工」に係わる情報処理に対応したものではあるが、与えられた部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、得られた識別番号に対応するデータ・セットから当該部品番号の部品と親子関係にある子部品の部品番号を検索し、次に、検索された子部品の部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、他のデータ・セットから当該部品番号の部品とさらに親子関係にある子部品の部品番号を検索し、以下同様の処理を繰り返して親子関係にある部品番号を検索することが記載されているから、当該検索に係る情報処理は、まさしく構成要件Oの、 「前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定しながら、一個以上の前記データ格納装置上の一個以上のデータ・セットを横断的に検索するデータ検索部」 に該当するものである。 したがって、以上のことから、本件特許発明における構成要件Oの「横断的に検索する」とは、 「所定のアルゴリズムを適用して特定した検索対象から検索されたデータに対して同一の所定のアルゴリズムを適用することで、次の検索を行う検索対象を特定して検索を行うこと。」 と解釈すべきものである。 (1-2)構成要件Oの充足性について 本件特許発明の構成要件Oは、データを検索するための構成であるところ、イ号物件においてデータを検索するための構成としては、上記3.(6)に記載した構成eに、 「各KEYの値から特定の計算ロジックによりパーティションIDを算出し、パーティションIDとメンバIDのマッピングにより、各KEYの検索対象となるメンバIDを特定して各KEYの値に対応したVALUEの値を特定されたメンバIDに対応するキャッシュサーバJVMから検索する構成」 が特定されている。 そこで、該構成eが構成要件Oの全ての要素を充足しているかについて検討する。 ア.構成eの「特定の計算ロジック」は、構成bの「KEYの値から 特定の計算ロジックによりパーティションIDを算出する構成」に 用いられる「特定の計算ロジック」と同じものである。 イ.構成eの「パーティションIDとメンバIDのマッピング」は、 構成cの「マッピング」と同じものである。 ウ.構成eにおいても、検索するのは1つのKEYだけではなく複数 のKEYであり、それらのKEYの中には既に検索を行ったKEY とは異なるメンバIDに対応するキャッシュサーバJVMから検索 を行うこともあり得る。 上記「ア」?「ウ」によると、構成eの「各KEYの値から特定の計算ロジックによりパーティションIDを算出し、パーティションIDとメンバIDのマッピングにより、各KEYの検索対象となるメンバIDを特定」、及び「特定されたメンバIDに対応するキャッシュサーバJVM」は、構成要件Oの「前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、検索対象となる前記データ・セットを特定」、及び「一個以上の前記データ格納装置上の一個以上のデータ・セット」に相当しているといえる。 しかしながら、上記(1-1)で検討したように、構成要件Oの「横断的に検索する」とは、「所定のアルゴリズムを適用して特定した検索対象から検索されたデータに対して同一の所定のアルゴリズムを適用することで、次の検索を行う検索対象を特定して検索を行うこと。」と解釈されるものである。これに対して、構成eでは、次の検索対象を特定するために利用されるのはKEYの値であり、検索されたデータであるVALUEの値を利用するものではない。 即ち、構成eでは、「所定のアルゴリズムを適用して特定した検索対象から検索されたデータに対して同一の所定のアルゴリズムを適用することで、次の検索を行う検索対象を特定して検索を行うこと。」を行っていないのであるから、構成eで特定されたデータの検索は「横断的に検索する」とはいえない。 したがって、イ号物件は本件特許発明の構成要件Oを充足しない。 (2)構成要件P (2-1)本件特許発明における「データ加工を横断的におこなう」の意味について 上記2.の構成要件Pに記載されているように、本件特許発明の「データ加工部」は、 「前記データ検索部によって特定され抽出されたデータを、前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、加工対象となる前記データ・セットを特定しながら、変更ないし削除、若しくは一個以上の前記データ・セットに跨るデータ群のジョインないしプロジェクションないしソートないしマージ等のデータ加工を横断的におこなうデータ加工部と、」 であるところ、「横断的に」の意味について、「判定請求書」では第12頁に、 「ここで『横断的に』は、複数のデータ・セットが横方向に並んでいる様子を観念的に想い浮かべ、そのデータ・セットの並びの端から端までを対象に動的にアクセス対象を変えていく様を表している単純な形容詞として使用しているに過ぎない。」 と記載されているが、当該「横断的に」の意味を特許請求の範囲に記載された構成要件Pから特定することはできない。 そこで、「データ加工を横断的におこなう」ことについて、発明の詳細な説明を参酌すると、本件特許明細書の【発明の詳細な説明】には、「データ加工」を「横断的」におこなうことが明示的に記載されていない。ただし、「横断」に関する事項については、上記4.(1)(1-1)で摘記したように、図面【図7】及び段落【0047】に関連する記載がある。 そして、上記段落【0047】には、「横断統合セルフジョイン」即ち本件特許発明の「データ加工」について、与えられた部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、得られた識別番号に対応するのデータ・セットから当該部品番号の部品と親子関係にある子部品の部品番号を検索し、次に、検索された子部品の部品番号を入力値としてデータセット識別記号変換部により識別番号を得て、他のデータ・セットから当該部品番号の部品と親子関係にある子部品の部品番号を検索し、以下同様の処理を繰り返して親子関係にある部品番号を検索して、各検索された部品番号をジョインしてデータ加工を行うことが記載されているから、当該データ加工に係る情報処理は、まさしく構成要件Pの、 「前記データ検索部によって特定され抽出されたデータを、前記アルゴリズムと同一のアルゴリズムを同一のパラメータで用いて、加工対象となる前記データ・セットを特定しながら、変更ないし削除、若しくは一個以上の前記データ・セットに跨るデータ群のジョインないしプロジェクションないしソートないしマージ等のデータ加工を横断的におこなうデータ加工部」 に該当するものである。 したがって、以上のことから、本件特許発明における構成要件Pの「データ加工を横断的におこなう」とは、 「所定のアルゴリズムを適用して特定した検索対象から検索されたデータと、当該検索されたデータに対して同一の所定のアルゴリズムを適用して検索を行う検索対象を特定して検索されたデータとをデータ加工すること。」 と解釈すべきものである。 (2-2)構成要件Pの充足性について 本件特許発明の構成要件Pは、データを加工するための構成であるところ、イ号物件においてデータを加工するための構成としては、上記3.(6)に記載した構成fに、 「検索された各VALUEの値を変更する構成、」 が特定されている。 そこで、該構成fが構成要件Pの全ての要素を充足しているかについて検討する。 上記(2-1)で検討したように、構成要件Pの「データ加工を横断的におこなう」とは、「所定のアルゴリズムを適用して特定した検索対象から検索されたデータと、当該検索されたデータに対して同一の所定のアルゴリズムを適用して検索を行う検索対象を特定して検索されたデータとをデータ加工すること。」と解釈されるものである。 これに対して、構成fは、例えば、複数のKEYに対応するVALUEの値を変更する場合、検索部において各KEYに対応したVALUEの値が検索され、次に各VALUEの値が変更されることになるが、当該検索されたVALUEの値に対して所定のアルゴリズムを適用して検索を行う検索対象を特定すること、即ち、検索部において「検索されたデータに対して同一の所定のアルゴリズムを適用して検索を行う検索対象を特定」することは行っていない。 したがって、イ号物件は本件特許発明の構成要件Pを充足しない。 (3)構成要件R (3-1)本件特許発明の「データ格納部」について 構成要件Rの「前記データ格納部」は、構成要件Lの「データ格納部」に対応するものであるから、該「データ格納部」の構成について確認する。 構成要件K乃至Mには、 「K.前記データ格納装置は、 L.前記データ格納部ロケーション情報によって特定された前記データ 格納装置において、当該データ格納装置上の主記憶装置上に存在する データ・セットに前記入力されたデータを格納するデータ格納部と、 M.当該データ格納装置上の主記憶装置上に存在する前記データ・セッ トと同一の前記データ・セット・ロケーション情報を有し、前記デー タ格納装置に接続されている二次記憶装置上ないしネットワーク上の 他の電子計算機上の主記憶装置上若しくは二次記憶装置上に一時的に 待避させられている別のデータ・セットに挿入ないし抽出等のアクセ ス要求が発生した場合、前記当該データ格納装置上の主記憶装置上に 存在する前記データ・セットを、前記データ格納装置に接続されてい る二次記憶装置上ないしネットワーク上の他の電子計算機上の主記憶 装置上若しくは二次記憶装置上に一時的に待避させ、前記データ格納 装置に接続された二次記憶装置上ないしネットワーク上の他の電子計 算機上の主記憶装置上若しくは二次記憶装置上に一時的に待避されて いる前記アクセス要求が発生しているデータ・セットを召還するリソ ース・マネジメント部と、を有し、」 と特定されていることからみて、当該「データ格納部」は、 ・構成要件Rの「リソース・マネジメント部」を有する「データ検 索加工装置」とは別個の装置である「データ格納装置」内に設け られたもの。 ・構成要件Rの「リソース・マネジメント部」とは別個の、「デー タ格納装置」内に設けられた「リソース・マネジメント部」から もリソース・マネジメントを受けるもの。 である構成になっているといえる。 (3-2)構成要件Rについて 上記確認事項に基づけば、「データ検索加工装置」内に設けられた「リソース・マネジメント部」が奏する機能について、次のことがいえる。 ア.「データ検索加工装置」とは別個の装置である「データ格納装置」 内に設けられた「データ格納部」と、「データ検索加工装置」内に設 けられた「データ検索部」および「データ加工部」および「ワークス ペース部」とに供される主記憶空間のリソース・マネジメントをおこ なう。 イ.「データ格納装置」内に設けられた「リソース・マネジメント部」 からリソース・マネジメントを受けている「データ格納部」に対し、 さらに別個のリソース・マネジメントをおこなう。 (3-3)構成要件Rの充足性について イ号物件において、主記憶空間のリソース不足に対処するための構成については、上記3.(6)に記載した構成gに、 「主記憶空間のリソースが不足した際に、スワッピング機能を使用す る構成」 が特定されている。 しかしながら、イ号物件が、スワッピング機能により主記憶空間のリソース不足に対処する構成を有するものであるとしても、上記(3-2)に記載された「ア」及び「イ」の機能を奏する構成を有するものとはいえない。 したがって、イ号物件は、本件特許発明の構成要件Rを充足しない。 (4)まとめ 以上のとおり、イ号物件は、本件特許発明の構成要件O、P及びRを充足しないから、他の構成要件を検討するまでもなく、イ号物件は本件特許発明の技術的範囲に属するということはできない。 5.むすび 以上のとおりであるから、イ号物件は、本件特許発明の技術的範囲に属しない。 よって、結論のとおり判定する。 |
| 判定日 | 2011-10-26 |
| 出願番号 | 特願2004-308853(P2004-308853) |
| 審決分類 |
P
1
2・
1-
ZB
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 高瀬 勤 |
| 特許庁審判長 |
岩崎 伸二 |
| 特許庁審判官 |
飯田 清司 本郷 彰 |
| 登録日 | 2009-05-22 |
| 登録番号 | 特許第4313845号(P4313845) |
| 発明の名称 | マルチインスタンス・インメモリ・データベース |
| 代理人 | 長沢 幸男 |
| 代理人 | 矢倉 千栄 |
| 代理人 | 永井 秀人 |
| 代理人 | 大野 聖二 |
| 代理人 | 佐藤 貴則 |
| 代理人 | 小林 英了 |