【事件の表示】
　特願２０１１−２６６２４９「索引キーを使用して検索を絞込む方法および記録媒体」拒絶査定不服審判事件〔平成２４年　４月　５日出願公開、特開２０１２−　６９１５２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯　 
　本願は，平成１７年６月１５日（優先権主張日：２００４年９月２７日、米国）を出願日とする特許出願（特願２００５−１７５１７４号）の一部を平成２３年１２月５日に新たな特許出願（特願２０１１−２６６２４９号）としたものであって，平成２５年９月２日付けの拒絶理由通知に対して平成２５年１１月１４日に意見書の提出とともに手続補正がなされ，平成２６年４月２日付けの拒絶査定に対して平成２６年８月１日に審判請求がなされ、当審の平成２７年８月３１日付けの拒絶理由通知に対して平成２７年１１月２４日に意見書の提出とともに手続補正がなされたものである。 
 　　  
第２　本願発明について
　平成２７年１１月２４日付けの手続補正書による特許請求の範囲の請求項１（以下、「本願発明」という。）は以下のとおりのものである。
「【請求項１】
　クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法であって、
　コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップと、
　コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップと、
　コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップと、
　コンピュータが、前記範囲関連検索キーの少なくも２つの組合せに基づいて、複合範囲関連索引キーを生成するステップと、
　コンピュータが索引を生成するステップであって、前記索引は、
　　前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第１のパーティションと、
　　前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第２のパーティションと、
　　前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第３のパーティションと
を含む、ステップと、
　コンピュータが、最初に前記第３のパーティションに基づいて、前記クエリに対する結果を生成し提供するステップと、
を含むことを特徴とする方法。」
　　
第３　当審の判断
１．引用例
（１）当審の拒絶の理由に引用された、「Christian Gross，これがSite Serverだ　Integrating The Microsoft Index Server with Active Server Pages，マイクロソフト・インタラクティブ・デベロッパー日本語版, 日本，株式会社アスキー，１９９７年７月１８日，１９９７　Ｊｕｌｙ Ｎｏ．２，ｐ．７５−９０」（以下、「引用例１」という。）には、次の事項が記載されている。なお、下線は当審において付加したものである。
ア．「
Index Serverは、システム内の指定されたドキュメントの内容カタログ（インデックス）をディスク上に作成し、管理する
イ．「新しいASPサイトにIndex Serverを導入する前に、Index Serverとはどういうもので、どのような仕組みで動作するのかを説明しておこう。Index Serverは驚くほど強力で、複雑な問い合わせ、検索のほとんどを簡単に実行できる。Index Serverは、基本的に自分で自分のメンテナンスを行う。システムがほとんど、あるいはまったく動いていないときに、
システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新する。カタログに対して検索を実行すると、Index Serverはインデックスの内容に基づいてHTMLページを作成し、クライアントに返す。
　Index Serverは、単にファイル名のリストを管理するだけではなく（やりたいことがこんなことなら、Windowsの“検索”ダイアログを使えばよい。）、ドキュメントの詳細を大量に格納できる。これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれる。
ウ．「Index Serverが、ほんのちょっとした作業でどれだけのことができるのかを示すために、実際の使用例を示すことにしよう。必要なのは、テキストボックスを１つとサブミットボタン（それに、テキストボックスをクリアするための標準リセットボタン）を１つずつ含むFORMセクションを持ったページだけである。テキストボックスは、検索基準を判定し、それを満たすファイルのリストを手に入れるために使う。今、このテキストボックスに
ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始してみよう
　
“Search”ボタンをクリックすると、Index Serverはカタログを見に走り、しばらくすると、基準を満たすドキュメントのリストが表示される
　・・・(途中省略）・・・　
検索したいドキュメントを指定するための方法は、複数ある。私が、ここで選択したデフォルトは、ドキュメントの内部のテキストを検索するものである。
　・・・(途中省略）・・・　
　
検索文字列内の単語は、Figure 10に示す論理演算子で結合できる。Index Serverがカタログに格納するドキュメントの属性やプロパティ（Figure 11)を使って検索することもできる。
　
ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができる。Figure 10の!@size
2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられている。正規表現ベースの検索では#を使う。たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致する
エ．「一般に、
Index Serverは、仮想パス（WWWroot、FTProotとそのサブフォルダ）に格納されたドキュメントのカタログしか作らない。
ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわない
オ．第８１頁右欄の「Figure 11　Index Serverプロパティキーワード」には、プロパティキーワードとその意味について、以下の内容が示されている。
  
属性／プロパティ　−　意味
Contents　　　　　　−ドキュメント内の単語及びフレーズ。ほかの属性／　　　　　　　　　　プロパティが指定されていないときのデフォルト
filename　　　　   −ファイル名
Size     　　　　　−ファイルサイズ（単位バイト）
Path　　　　　　　−ドキュメントのパスとファイル名
VPath　　　　　　 −サーバの仮想パスとドキュメントのファイル名
HitCount　　　　　 −内容検索のヒット数
Rank　　　　　　　−問い合わせの相対ランク。0から1000まで
Create　　　　　　 −ファイルが最初に作成された日時
Write　　　　　　　−ファイルが最後に更新された日時
・・・
　　
　以上、ア〜オの記載によれば引用例１には次の発明（以下、「引用発明」という。）が記載されている。
＜＜引用発明＞＞
「Index Serverは、システム内の指定されたドキュメントの内容カタログ（インデックス）をディスク上に作成し、管理するものであり、
　Index Serverは、仮想パス（WWWroot、FTProotとそのサブフォルダ）に格納されたドキュメントのカタログしか作らないが、ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわないものであり、
　システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し、
　カタログに対して検索を実行すると、インデックスの内容に基づいてHTMLページを作成し、クライアントに返すものであり、
　Index Serverは、単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり、
　ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され、検索文字列内の単語は、論理演算子で結合でき、また、Index Serverがカタログに格納するドキュメントの属性やプロパティを使って検索することもでき、ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができ、!@size2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられ、正規表現ベースの検索では#を使い、たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致するものであり、プロパティキーワードには、Contents（ドキュメント内の単語及びフレーズ。ほかの属性／プロパティが指定されていないときのデフォルト）、filename（ファイル名）、Size（ファイルサイズ（単位バイト））、Path（ドキュメントのパスとファイル名）、VPath（サーバの仮想パスとドキュメントのファイル名）、Create（ファイルが最初に作成された日時）、Write（ファイルが最後に更新された日時）などが使用可能である、Index Server」
　　
（２）当審の拒絶の理由に引用された、特開２００４−１９２６５７号公報（以下、「引用例２」という。）には、次の事項が記載されている。
ア．「【００１４】
　インデックス生成手段22は、検索に先立ち、実データ記憶部30から実データを読み出し、指定された属性あるいはその組合せに対してインデックスを生成して、それをインデックス記憶部31に格納する。」
      　
　上記アの記載から、引用例２には以下の事項が記載されている。
＜＜引用例２記載事項＞＞
「インデックス生成手段が、指定された属性あるいはその組合せに対してインデックスを生成し、それをインデックス記憶部に格納する方法」
　　
（３）当審の拒絶の理由に周知例として引用された、特開２００２−２４０１５号公報（以下、「引用例３」という。）には、次の事項が記載されている。
ア．「【００３１】なお、データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置くものとしても良い。従って、複数のデータベースサーバ３ｂを用いるものとしても良い。また、アプリケーションサーバ３ａがデータベースサーバ３ｂの機能も有する物としても良い。」
　　
　上記アの記載から、引用例３には以下の事項が記載されている。
＜＜引用例３記載事項＞＞
「データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置く方法」
　　
２．対比
（１）引用発明の「Index Server」は、「システム内の指定されたドキュメントの内容カタログ（インデックス）をディスク上に作成し、管理するものであり」、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」、「カタログに対して検索を実行すると、インデックスの内容に基づいてHTMLページを作成し、クライアントに返すものであり」、及び、「ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され」との記載によれば、「ZIP*という検索基準」すなわちクエリに基づいて、システム内に格納される複数のドキュメント、すなわち文書の検索を行うためのコンピュータであることは明らかである。
　また、引用発明の「仮想パス（WWWroot、FTProotとそのサブフォルダ）に格納されたドキュメントのカタログしか作らないが、ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわないものであり」との記載によれば、「Index Server」のカタログの作成対象となるドキュメントは、ネットワーク上のほかのマシンに格納されているものでもかまわないことから、検索の対象となるドキュメントは、ネットワーク内に格納されるドキュメントであるといえる。
　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータ」
である点で共通する。
（２）引用発明の「Index Server」は、「システム内の指定されたドキュメントの内容カタログ（インデックス）をディスク上に作成し、管理する」際に、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」、及び「Index Serverは、単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり」との記載によれば、ドキュメントのカタログ（インデックス）を作成する際に、該ドキュメントに関連するファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティも識別するものであることは明らかである。
　また、引用発明の「Index Server」は、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」との記載によれば、システム内の選択された領域内を“歩き回る”、つまり“クロール”することにより格納されているドキュメントの内容や上記プロパティを識別してカタログ情報を構築、更新する処理ステップを備えるものである。
　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップ」
を備える点で共通する。
（３）本願発明の「コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップ」における「範囲関連索引キー」が、どのようなインデックスを意味するのかについて、明細書の例えば第【００１１】段落には「・・・「索引キー」という用語は、索引の検索クエリまたは作成で１組の文書を標的にするために使用される検索に関連付けられている任意のキーワードまたはキーを指す。「範囲キー」という用語は、検索が開始される前に検索される文書の数が低減されるように、検索の範囲を絞るために使用することができる任意の索引キーを指す。検索の範囲は、ファイルタイプなどの属性、何らかのデータベースまたはＵＲＬなどの場所に従って、または検索される文書の数を低減する他の基準によって絞ることができる。」と記載されており、「ファイルタイプなどの属性」、「データベース」及び「ＵＲＬなどの場所」等が含まれるものである。
　これに対し、引用発明の「Index Server」は、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新」する処理において、各ドキュメントについての索引キーであるカタログ（インデックス）を生成するステップを備えるものである。
　そして、この索引キーであるカタログ（インデックス）の生成においては、引用発明の「単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり」、「また、Index Serverがカタログに格納するドキュメントの属性やプロパティを使って検索することもでき、ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができ、!@size2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられ、正規表現ベースの検索では#を使い、たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致するものであり」との記載、また、プロパティキーワードとして「filename（ファイル名）」、「Size（ファイルサイズ（単位バイト））」、「Create（ファイルが最初に作成された日時）」、「Write（ファイルが最後に更新された日時）」が指定可能であることから、上記（２）で識別したドキュメントに関連するプロパティに従って、本願発明の「範囲関連索引キー」の一つである「ファイルタイプなどの属性」についてカタログ（インデックス）を生成するものであるといえるし、また、さらに「Path（ドキュメントのパスとファイル名）」及び「VPath（サーバの仮想パスとドキュメントのファイル名）」も指定可能であることから、ファイルの存在する「場所」、つまり本願発明の「範囲関連索引キー」の一つである「ＵＲＬなどの場所」についてもカタログ（インデックス）を生成するものであるといえる。
　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップ」
を備える点で共通する。
（４）上記（３）で示したように、引用発明の「Index Server」は、各ドキュメントについての索引キーであるカタログ（インデックス）を生成するステップを備えるものである。
　また、引用発明の「ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され」、及び、プロパティキーワードとして「Contents（ドキュメント内の単語及びフレーズ。ほかの属性／プロパティが指定されていないときのデフォルト）」との記載から、ドキュメント内の単語（キーワード）を識別してカタログ（インデックス）が生成されており、これは本願発明の「内容関連索引キー」を生成することに相当するものであるのは明らかである。
 　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップ」
を備える点で共通する。
（５）本願発明における「コンピュータが索引を生成するステップであって、前記索引は、前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第１のパーティションと、前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第２のパーティションと、前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第３のパーティションとを含む、ステップ」と、引用発明における「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」について検討する。
　引用発明で各ドキュメントについてのカタログ情報が構築されることは、各ドキュメントについてのインデックス、すなわち索引キーが生成されることである。
　また、一般にインデックスは、該インデックスにより識別される内容を含むドキュメントの部分集合（例えばドキュメントを識別するＩＤの集合）と関連付けられてカタログとして構築され格納されるものであることは技術常識である。
　そして、上記（３）及び（４）で検討したように、引用発明においても本願発明の「内容関連索引キー」及び「範囲関連索引キー」に相当するインデックスが生成されている。
　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが索引を生成するステップであって、前記索引は、前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納し、前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納するステップ」
を備える点で共通する。
（６）引用発明の「Index Server」も上記（１）及び（４）で検討したように、構築されたインデックスに基づいて、クエリに対する検索結果を生成し提供するものである。
　そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、索引キーに基づいて、前記クエリに対する結果を生成し提供するステップ」
を備える点で共通する。
（７）引用発明の「Index Server」も上記（２）−（６）のステップを実行するコンピュータであり、引用発明で行われる各処理についてみれば、実質的に「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法」であるといえる。
（８）以上の（１）−（７）によれば、本願発明と引用発明は、
＜＜一致点＞＞
「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法であって、
　コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップと、
　コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップと、
　コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップと、
　コンピュータが索引を生成するステップであって、前記索引は、
　　前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納し、
　　前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納するステップと、
　コンピュータが、索引キーに基づいて、前記クエリに対する結果を生成し提供するステップと、
を含むことを特徴とする方法。」
である点で一致し、以下の点で相違する。
　　
［相違点１］
　本願発明では、「コンピュータが、前記範囲関連検索キーの少なくも２つの組合せに基づいて、複合範囲関連索引キーを生成するステップ」を備えているのに対し、引用発明ではそのようなステップを備えていない点。
　　
［相違点２］
　本願発明では、「前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第１のパーティション」、「前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第２のパーティション」、及び、「前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第３のパーティション」に分けて格納するものであるのに対し、引用発明ではそのようになっていない点。
　　
［相違点３］
　本願発明では、「最初に前記第３のパーティションに基づいて」、つまり最初に「複合範囲関連索引キー」によりクエリに対する結果を生成するものであるのに対し、引用発明ではそのようになっていない点。
　　
３．当審の判断
（１）相違点１について
　本願発明は、明細書の【発明が解決使用とする課題】に「【０００３】こうしたクエリでは、一貫してキーワードまたは索引キーが使用される傾向にある。ユーザが検索クエリを長いテキスト文字列として入力しようと、ブール演算子の連結として入力しようと、検索エンジンは、キーワードに一致する文書に対応して入力されたキーワードについて、すべてのレコードを検査する。次いで、ブール演算子の制約を満たす、または長いテキスト文字列に対応するレコードのサブセットが戻される。これらのレコードの検査は、時間がかかり、費用がかかる操作となる可能性がある。さらに、クライアントは、特定のキーワードを含む文書の全レコード検索を望まない場合がある。」と記載され、また、【課題を解決するための手段】として「【０００５】本発明の別の態様によれば、複合範囲も認識され、格納される。この追加の索引パーティションは、基本的な範囲の組合せである範囲定義を含む。これらの複合範囲に対応する文書はすでに解決されており、これらの複合範囲を参照すると、より迅速な検索が可能となる。」と記載されていることから、検索処理の迅速化が課題である。
　また、一般に検索処理の迅速化は、検索技術分野における共通の課題である。
　これに対して引用例２記載事項の「インデックス生成手段が、指定された属性あるいはその組合せに対してインデックスを生成し、それをインデックス記憶部に格納する方法」によれば、属性の組合せに対してインデックスを生成することは既に知られており、また、属性を組み合わせることは、組み合わせる属性同士でのＡＮＤ条件での絞り込みと同じであるから、それをインデックスとして生成しておけば、絞り込みに要する時間の短縮化に有効であることは当業者であれば自明である。
　してみれば、引用発明においても検索処理の迅速化のために、上記引用例２記載事項の技術を採用し、プロパティキーワードとして示される「filename（ファイル名）」、「Size（ファイルサイズ（単位バイト））」、「Create（ファイルが最初に作成された日時）」、「Write（ファイルが最後に更新された日時）」に対応するドキュメントの各種属性についてのインデックスの少なくとも２つの組合せ、つまり「範囲関連索引キー」の少なくも２つの組合せに基づいて「複合範囲関連索引キー」を生成することは、当業者であれば容易に想到し得たことである。
　　
（２）相違点２について
　上記引用文献３記載事項の「データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置く方法」との記載によれば、一般にデータベースやインデックスをパーティショニングに対応したものとすること、つまりデータベースやインデックスをいくつかに分割し、分割したそれぞれの格納場所も物理的に分割して配置することは周知の技術であって、例えばアクセス頻度の高いデータについては読み出し速度の速い記憶装置に配置することで検索処理の迅速化が可能となり、また、メンテナンスの容易性などが見込まれることはよく知られている。
　してみれば、引用発明においても検索処理の迅速化やメンテナンスの容易性を考慮し、カタログ（インデックス）を複数のパーティションに分割して格納することは、上記周知技術から当業者であれば容易に想到し得たことであるし、また、その際に単にインデックスの種類毎、つまり「内容関連索引キー」、「範囲関連索引キー」、「複合範囲関連索引キー」毎のそれぞれ第１、第２、第３のパーティションに格納することに格別の技術的困難性があるものでないから、この点で進歩性があるものとはいえない。
　　
（３）相違点３について
　属性の組合せに対してインデックスを生成しておけば、絞り込みに要する時間の短縮化が可能であることは上記「（１）相違点１について」で示したとおりであり、クエリ内にこの属性の組合せに関する検索キーが指定されているのであれば、他の検索キーに比べて当該属性の組合せに対するインデックスによって、より対象の絞り込みができる可能性が高いことは明らかであるから、まず最初に当該属性の組合せに対するインデックスを使用して絞り込みを行うこと、つまり「第３のパーティション」に基づいて絞り込みを行うことは当業者であれば容易に想到し得たことである。
　　
（４）そして、上記相違点を総合的に勘案しても、本願発明の奏する作用効果は、引用発明、引用例２記載事項及び引用例３記載事項の作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
    　
４．まとめ
　以上のとおり、本願発明は、引用発明、引用例２記載事項及び引用例３記載事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　　
第４　むすび
　以上のとおり、請求項１に係る発明は、引用発明、引用例２記載事項及び引用例３記載事項に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものであるから、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　
　よって、結論のとおり審決する。