• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1314808
審判番号 不服2014-15169  
総通号数 199 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-07-29 
種別 拒絶査定不服の審決 
審判請求日 2014-08-01 
確定日 2016-05-16 
事件の表示 特願2011-266249「索引キーを使用して検索を絞込む方法および記録媒体」拒絶査定不服審判事件〔平成24年 4月 5日出願公開、特開2012- 69152〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は,平成17年6月15日(優先権主張日:2004年9月27日、米国)を出願日とする特許出願(特願2005-175174号)の一部を平成23年12月5日に新たな特許出願(特願2011-266249号)としたものであって,平成25年9月2日付けの拒絶理由通知に対して平成25年11月14日に意見書の提出とともに手続補正がなされ,平成26年4月2日付けの拒絶査定に対して平成26年8月1日に審判請求がなされ、当審の平成27年8月31日付けの拒絶理由通知に対して平成27年11月24日に意見書の提出とともに手続補正がなされたものである。

第2 本願発明について
平成27年11月24日付けの手続補正書による特許請求の範囲の請求項1(以下、「本願発明」という。)は以下のとおりのものである。
「【請求項1】
クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法であって、
コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップと、
コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップと、
コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップと、
コンピュータが、前記範囲関連検索キーの少なくも2つの組合せに基づいて、複合範囲関連索引キーを生成するステップと、
コンピュータが索引を生成するステップであって、前記索引は、
前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第1のパーティションと、
前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第2のパーティションと、
前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第3のパーティションと
を含む、ステップと、
コンピュータが、最初に前記第3のパーティションに基づいて、前記クエリに対する結果を生成し提供するステップと、
を含むことを特徴とする方法。」

第3 当審の判断
1.引用例
(1)当審の拒絶の理由に引用された、「Christian Gross,これがSite Serverだ Integrating The Microsoft Index Server with Active Server Pages,マイクロソフト・インタラクティブ・デベロッパー日本語版, 日本,株式会社アスキー,1997年7月18日,1997 Jｕlｙ Nｏ.2,ｐ.75-90」(以下、「引用例1」という。)には、次の事項が記載されている。なお、下線は当審において付加したものである。
ア.「Index Serverは、システム内の指定されたドキュメントの内容カタログ(インデックス)をディスク上に作成し、管理するバックグラウンドアプリケーションを使っている。カタログを検索するためには、簡単なHTMLコードが含まれた問い合わせページを作成すればよい。」(第75頁右欄第7行-第76頁左欄第4行)
イ.「新しいASPサイトにIndex Serverを導入する前に、Index Serverとはどういうもので、どのような仕組みで動作するのかを説明しておこう。Index Serverは驚くほど強力で、複雑な問い合わせ、検索のほとんどを簡単に実行できる。Index Serverは、基本的に自分で自分のメンテナンスを行う。システムがほとんど、あるいはまったく動いていないときに、システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新する。カタログに対して検索を実行すると、Index Serverはインデックスの内容に基づいてHTMLページを作成し、クライアントに返す。カタログ、インデックス作成システム全体は、ユーザーに対して透過的である。検索しなければならないのはインデックスファイルだけなので、スピードも速い。しかし、フルインデックス機能を使うと、システム内のドキュメント全体のサイズの40%ほどがインデックスファイルになってしまう場合があるので注意が必要である。
Index Serverは、単にファイル名のリストを管理するだけではなく(やりたいことがこんなことなら、Windowsの“検索”ダイアログを使えばよい。)、ドキュメントの詳細を大量に格納できる。これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれる。さらに、これがなかなか優れたところなのだが、ドキュメントの要約も管理している。これは、実際のドキュメントのタイプに関わらず、ドキュメントから選ばれたテキストである。Index Serverは、ユーザーの話言葉に合わせた自然言語処理システムを持っており、ファイルの内容を理解できるのである。検索側では、単語、単語のグループ、ファイルのタイプ、著者などのその他のプロパティを指定できる。自然言語エンジンは、文字通りの形での単語の一致(catch*と指定すれば、catcher、catchingなどを検出する)、文法的な意味での一致(catch**と指定すれば、catching、caughtなどを検出する)の両方をサポートする。また、and、or、theなどの単語をインデックスから除外するためのノイズリストファイル(編集可能)も含まれている。これらの機能によって、Index Serverは、どこかに埋もれている情報を検索するための強力な手段となっているのである。」(第79頁左欄第11行-同頁右欄第1行)
ウ.「Index Serverが、ほんのちょっとした作業でどれだけのことができるのかを示すために、実際の使用例を示すことにしよう。必要なのは、テキストボックスを1つとサブミットボタン(それに、テキストボックスをクリアするための標準リセットボタン)を1つずつ含む
セクションを持ったページだけである。テキストボックスは、検索基準を判定し、それを満たすファイルのリストを手に入れるために使う。今、このテキストボックスにZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始してみよう(Figure 7)
“Search”ボタンをクリックすると、Index Serverはカタログを見に走り、しばらくすると、基準を満たすドキュメントのリストが表示される。
・・・(途中省略)・・・
検索したいドキュメントを指定するための方法は、複数ある。私が、ここで選択したデフォルトは、ドキュメントの内部のテキストを検索するものである。
・・・(途中省略)・・・
検索文字列内の単語は、Figure 10に示す論理演算子で結合できる。Index Serverがカタログに格納するドキュメントの属性やプロパティ(Figure 11)を使って検索することもできる。プレフィックスDocを持つプロパティは、これらのプロパティをファイルに格納できるアプリケーションで作成したドキュメントでしか利用できない。たとえば、実行可能ファイルには、DocPageCount、DocKeywordプロパティは使えない。
ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができる。Figure 10の!@size<2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられている。正規表現ベースの検索では#を使う。たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致する。」(第79頁右欄第18行-第80頁右欄第23行)
エ.「一般に、Index Serverは、仮想パス(WWWroot、FTProotとそのサブフォルダ)に格納されたドキュメントのカタログしか作らない。しかし、ほかのディレクトリに仮想パスを作ることもできる。ASPは、自分自身のサンプルディレクトリの1つに仮想パスを作成するので、カタログにはそれらのファイルも組み込まれる。問い合わせファイルを作成するときに、どの仮想パスを使うかを選択したり、My Documentsフォルダなどの既存のファイルリソースに新しい仮想パスを追加したりすることもできる。ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわない。」(第80頁右欄第29行-同頁右欄第38行)
オ.第81頁右欄の「Figure 11 Index Serverプロパティキーワード」には、プロパティキーワードとその意味について、以下の内容が示されている。

属性/プロパティ - 意味
Contents -ドキュメント内の単語及びフレーズ。ほかの属性/ プロパティが指定されていないときのデフォルト
filename -ファイル名
Size -ファイルサイズ(単位バイト)
Path -ドキュメントのパスとファイル名
VPath -サーバの仮想パスとドキュメントのファイル名
HitCount -内容検索のヒット数
Rank -問い合わせの相対ランク。0から1000まで
Create -ファイルが最初に作成された日時
Write -ファイルが最後に更新された日時
・・・

以上、ア?オの記載によれば引用例1には次の発明(以下、「引用発明」という。)が記載されている。
＜＜引用発明＞＞
「Index Serverは、システム内の指定されたドキュメントの内容カタログ(インデックス)をディスク上に作成し、管理するものであり、
Index Serverは、仮想パス(WWWroot、FTProotとそのサブフォルダ)に格納されたドキュメントのカタログしか作らないが、ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわないものであり、
システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し、
カタログに対して検索を実行すると、インデックスの内容に基づいてHTMLページを作成し、クライアントに返すものであり、
Index Serverは、単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり、
ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され、検索文字列内の単語は、論理演算子で結合でき、また、Index Serverがカタログに格納するドキュメントの属性やプロパティを使って検索することもでき、ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができ、!@size<2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられ、正規表現ベースの検索では#を使い、たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致するものであり、プロパティキーワードには、Contents(ドキュメント内の単語及びフレーズ。ほかの属性/プロパティが指定されていないときのデフォルト)、filename(ファイル名)、Size(ファイルサイズ(単位バイト))、Path(ドキュメントのパスとファイル名)、VPath(サーバの仮想パスとドキュメントのファイル名)、Create(ファイルが最初に作成された日時)、Write(ファイルが最後に更新された日時)などが使用可能である、Index Server」

(2)当審の拒絶の理由に引用された、特開2004-192657号公報(以下、「引用例2」という。)には、次の事項が記載されている。
ア.「【0014】
インデックス生成手段22は、検索に先立ち、実データ記憶部30から実データを読み出し、指定された属性あるいはその組合せに対してインデックスを生成して、それをインデックス記憶部31に格納する。」

上記アの記載から、引用例2には以下の事項が記載されている。
＜＜引用例2記載事項＞＞
「インデックス生成手段が、指定された属性あるいはその組合せに対してインデックスを生成し、それをインデックス記憶部に格納する方法」

(3)当審の拒絶の理由に周知例として引用された、特開2002-24015号公報(以下、「引用例3」という。)には、次の事項が記載されている。
ア.「【0031】なお、データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置くものとしても良い。従って、複数のデータベースサーバ3bを用いるものとしても良い。また、アプリケーションサーバ3aがデータベースサーバ3bの機能も有する物としても良い。」

上記アの記載から、引用例3には以下の事項が記載されている。
＜＜引用例3記載事項＞＞
「データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置く方法」

2.対比
(1)引用発明の「Index Server」は、「システム内の指定されたドキュメントの内容カタログ(インデックス)をディスク上に作成し、管理するものであり」、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」、「カタログに対して検索を実行すると、インデックスの内容に基づいてHTMLページを作成し、クライアントに返すものであり」、及び、「ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され」との記載によれば、「ZIP*という検索基準」すなわちクエリに基づいて、システム内に格納される複数のドキュメント、すなわち文書の検索を行うためのコンピュータであることは明らかである。
また、引用発明の「仮想パス(WWWroot、FTProotとそのサブフォルダ)に格納されたドキュメントのカタログしか作らないが、ドメイン、またはコンピュータ名を指定できるなら、これらのフォルダはネットワーク上のほかのマシンにあってもかまわないものであり」との記載によれば、「Index Server」のカタログの作成対象となるドキュメントは、ネットワーク上のほかのマシンに格納されているものでもかまわないことから、検索の対象となるドキュメントは、ネットワーク内に格納されるドキュメントであるといえる。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータ」
である点で共通する。
(2)引用発明の「Index Server」は、「システム内の指定されたドキュメントの内容カタログ(インデックス)をディスク上に作成し、管理する」際に、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」、及び「Index Serverは、単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり」との記載によれば、ドキュメントのカタログ(インデックス)を作成する際に、該ドキュメントに関連するファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティも識別するものであることは明らかである。
また、引用発明の「Index Server」は、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」との記載によれば、システム内の選択された領域内を“歩き回る”、つまり“クロール”することにより格納されているドキュメントの内容や上記プロパティを識別してカタログ情報を構築、更新する処理ステップを備えるものである。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップ」
を備える点で共通する。
(3)本願発明の「コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップ」における「範囲関連索引キー」が、どのようなインデックスを意味するのかについて、明細書の例えば第【0011】段落には「・・・「索引キー」という用語は、索引の検索クエリまたは作成で1組の文書を標的にするために使用される検索に関連付けられている任意のキーワードまたはキーを指す。「範囲キー」という用語は、検索が開始される前に検索される文書の数が低減されるように、検索の範囲を絞るために使用することができる任意の索引キーを指す。検索の範囲は、ファイルタイプなどの属性、何らかのデータベースまたはURLなどの場所に従って、または検索される文書の数を低減する他の基準によって絞ることができる。」と記載されており、「ファイルタイプなどの属性」、「データベース」及び「URLなどの場所」等が含まれるものである。
これに対し、引用発明の「Index Server」は、「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新」する処理において、各ドキュメントについての索引キーであるカタログ(インデックス)を生成するステップを備えるものである。
そして、この索引キーであるカタログ(インデックス)の生成においては、引用発明の「単にファイル名のリストを管理するだけではなく、ドキュメントの詳細を大量に格納でき、これには、ファイルの作成日時、更新日時、サイズ、ファイル属性といったさまざまなプロパティが含まれるものであり」、「また、Index Serverがカタログに格納するドキュメントの属性やプロパティを使って検索することもでき、ファイルのプロパティや属性は、プレフィクスとして@、#を付加することによって検索条件に組み込むことができ、!@size<2049のような関係式では、sizeキーワードの前にプレフィックス@が付けられ、正規表現ベースの検索では#を使い、たとえば、#filename*.xlwを指定すると、Microsoft Excelブックファイルのみが一致するものであり」との記載、また、プロパティキーワードとして「filename(ファイル名)」、「Size(ファイルサイズ(単位バイト))」、「Create(ファイルが最初に作成された日時)」、「Write(ファイルが最後に更新された日時)」が指定可能であることから、上記(2)で識別したドキュメントに関連するプロパティに従って、本願発明の「範囲関連索引キー」の一つである「ファイルタイプなどの属性」についてカタログ(インデックス)を生成するものであるといえるし、また、さらに「Path(ドキュメントのパスとファイル名)」及び「VPath(サーバの仮想パスとドキュメントのファイル名)」も指定可能であることから、ファイルの存在する「場所」、つまり本願発明の「範囲関連索引キー」の一つである「URLなどの場所」についてもカタログ(インデックス)を生成するものであるといえる。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップ」
を備える点で共通する。
(4)上記(3)で示したように、引用発明の「Index Server」は、各ドキュメントについての索引キーであるカタログ(インデックス)を生成するステップを備えるものである。
また、引用発明の「ZIP*という検索基準を入力して、zipで始まる単語を含むドキュメントの検索を開始すると、Index Serverはカタログを見に走り、基準を満たすドキュメントのリストが表示され」、及び、プロパティキーワードとして「Contents(ドキュメント内の単語及びフレーズ。ほかの属性/プロパティが指定されていないときのデフォルト)」との記載から、ドキュメント内の単語(キーワード)を識別してカタログ(インデックス)が生成されており、これは本願発明の「内容関連索引キー」を生成することに相当するものであるのは明らかである。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップ」
を備える点で共通する。
(5)本願発明における「コンピュータが索引を生成するステップであって、前記索引は、前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第1のパーティションと、前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第2のパーティションと、前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第3のパーティションとを含む、ステップ」と、引用発明における「システム内の選択された領域内を歩き回り、そこに格納された各ドキュメントについてのカタログ情報を構築、更新し」について検討する。
引用発明で各ドキュメントについてのカタログ情報が構築されることは、各ドキュメントについてのインデックス、すなわち索引キーが生成されることである。
また、一般にインデックスは、該インデックスにより識別される内容を含むドキュメントの部分集合(例えばドキュメントを識別するIDの集合)と関連付けられてカタログとして構築され格納されるものであることは技術常識である。
そして、上記(3)及び(4)で検討したように、引用発明においても本願発明の「内容関連索引キー」及び「範囲関連索引キー」に相当するインデックスが生成されている。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが索引を生成するステップであって、前記索引は、前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納し、前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納するステップ」
を備える点で共通する。
(6)引用発明の「Index Server」も上記(1)及び(4)で検討したように、構築されたインデックスに基づいて、クエリに対する検索結果を生成し提供するものである。
そうすると、本願発明の「コンピュータ」と引用発明の「Index Server」は、
「コンピュータが、索引キーに基づいて、前記クエリに対する結果を生成し提供するステップ」
を備える点で共通する。
(7)引用発明の「Index Server」も上記(2)-(6)のステップを実行するコンピュータであり、引用発明で行われる各処理についてみれば、実質的に「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法」であるといえる。
(8)以上の(1)-(7)によれば、本願発明と引用発明は、
＜＜一致点＞＞
「クエリに基づいて、ネットワーク内に格納される複数の文書の検索を行うためのコンピュータにより実行される方法であって、
コンピュータが前記文書に関連するプロパティを識別するステップであって、前記文書はクロールの間に識別される、ステップと、
コンピュータが、前記識別されたプロパティに従って、範囲関連索引キーを生成するステップと、
コンピュータが、前記文書の内容に従って、内容関連索引キーを生成するステップであって、前記内容関連索引キーは、前記文書のキーワードを識別する、ステップと、
コンピュータが索引を生成するステップであって、前記索引は、
前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納し、
前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納するステップと、
コンピュータが、索引キーに基づいて、前記クエリに対する結果を生成し提供するステップと、
を含むことを特徴とする方法。」
である点で一致し、以下の点で相違する。

[相違点1]
本願発明では、「コンピュータが、前記範囲関連検索キーの少なくも2つの組合せに基づいて、複合範囲関連索引キーを生成するステップ」を備えているのに対し、引用発明ではそのようなステップを備えていない点。

[相違点2]
本願発明では、「前記内容関連索引キーを、それぞれの前記内容関連索引キーにより識別される内容を含む、前記文書のサブセットに関連付けるデータを格納する第1のパーティション」、「前記範囲関連索引キーを、それぞれの前記範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第2のパーティション」、及び、「前記複合範囲関連索引キーを、それぞれの前記複合範囲関連索引キーにより識別されるプロパティを有する、前記文書のサブセットに関連付けるデータを格納する第3のパーティション」に分けて格納するものであるのに対し、引用発明ではそのようになっていない点。

[相違点3]
本願発明では、「最初に前記第3のパーティションに基づいて」、つまり最初に「複合範囲関連索引キー」によりクエリに対する結果を生成するものであるのに対し、引用発明ではそのようになっていない点。

3.当審の判断
(1)相違点1について
本願発明は、明細書の【発明が解決使用とする課題】に「【0003】こうしたクエリでは、一貫してキーワードまたは索引キーが使用される傾向にある。ユーザが検索クエリを長いテキスト文字列として入力しようと、ブール演算子の連結として入力しようと、検索エンジンは、キーワードに一致する文書に対応して入力されたキーワードについて、すべてのレコードを検査する。次いで、ブール演算子の制約を満たす、または長いテキスト文字列に対応するレコードのサブセットが戻される。これらのレコードの検査は、時間がかかり、費用がかかる操作となる可能性がある。さらに、クライアントは、特定のキーワードを含む文書の全レコード検索を望まない場合がある。」と記載され、また、【課題を解決するための手段】として「【0005】本発明の別の態様によれば、複合範囲も認識され、格納される。この追加の索引パーティションは、基本的な範囲の組合せである範囲定義を含む。これらの複合範囲に対応する文書はすでに解決されており、これらの複合範囲を参照すると、より迅速な検索が可能となる。」と記載されていることから、検索処理の迅速化が課題である。
また、一般に検索処理の迅速化は、検索技術分野における共通の課題である。
これに対して引用例2記載事項の「インデックス生成手段が、指定された属性あるいはその組合せに対してインデックスを生成し、それをインデックス記憶部に格納する方法」によれば、属性の組合せに対してインデックスを生成することは既に知られており、また、属性を組み合わせることは、組み合わせる属性同士でのAND条件での絞り込みと同じであるから、それをインデックスとして生成しておけば、絞り込みに要する時間の短縮化に有効であることは当業者であれば自明である。
してみれば、引用発明においても検索処理の迅速化のために、上記引用例2記載事項の技術を採用し、プロパティキーワードとして示される「filename(ファイル名)」、「Size(ファイルサイズ(単位バイト))」、「Create(ファイルが最初に作成された日時)」、「Write(ファイルが最後に更新された日時)」に対応するドキュメントの各種属性についてのインデックスの少なくとも2つの組合せ、つまり「範囲関連索引キー」の少なくも2つの組合せに基づいて「複合範囲関連索引キー」を生成することは、当業者であれば容易に想到し得たことである。

(2)相違点2について
上記引用文献3記載事項の「データベースは、パーティショニングに対応したものとなっていても良く、データベース・テーブルやインデックスをいくつかに分割してそれに対応する物理的なデータの格納場所も分割して置く方法」との記載によれば、一般にデータベースやインデックスをパーティショニングに対応したものとすること、つまりデータベースやインデックスをいくつかに分割し、分割したそれぞれの格納場所も物理的に分割して配置することは周知の技術であって、例えばアクセス頻度の高いデータについては読み出し速度の速い記憶装置に配置することで検索処理の迅速化が可能となり、また、メンテナンスの容易性などが見込まれることはよく知られている。
してみれば、引用発明においても検索処理の迅速化やメンテナンスの容易性を考慮し、カタログ(インデックス)を複数のパーティションに分割して格納することは、上記周知技術から当業者であれば容易に想到し得たことであるし、また、その際に単にインデックスの種類毎、つまり「内容関連索引キー」、「範囲関連索引キー」、「複合範囲関連索引キー」毎のそれぞれ第1、第2、第3のパーティションに格納することに格別の技術的困難性があるものでないから、この点で進歩性があるものとはいえない。

(3)相違点3について
属性の組合せに対してインデックスを生成しておけば、絞り込みに要する時間の短縮化が可能であることは上記「(1)相違点1について」で示したとおりであり、クエリ内にこの属性の組合せに関する検索キーが指定されているのであれば、他の検索キーに比べて当該属性の組合せに対するインデックスによって、より対象の絞り込みができる可能性が高いことは明らかであるから、まず最初に当該属性の組合せに対するインデックスを使用して絞り込みを行うこと、つまり「第3のパーティション」に基づいて絞り込みを行うことは当業者であれば容易に想到し得たことである。

(4)そして、上記相違点を総合的に勘案しても、本願発明の奏する作用効果は、引用発明、引用例2記載事項及び引用例3記載事項の作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

4.まとめ
以上のとおり、本願発明は、引用発明、引用例2記載事項及び引用例3記載事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものである。

第4 むすび
以上のとおり、請求項1に係る発明は、引用発明、引用例2記載事項及び引用例3記載事項に基づいて当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により特許を受けることができないものであるから、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。

よって、結論のとおり審決する。
 
審理終結日 2015-12-16 
結審通知日 2015-12-17 
審決日 2016-01-04 
出願番号 特願2011-266249(P2011-266249)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 吉田 誠  
特許庁審判長 手島 聖治
特許庁審判官 小田 浩
金子 幸一
発明の名称 索引キーを使用して検索を絞込む方法および記録媒体  
代理人 上田 忠  
代理人 山本 修  
代理人 松尾 淳一  
代理人 末松 亮太  
代理人 鳥居 健一  
代理人 小野 新次郎  
代理人 竹内 茂雄  
代理人 中西 基晴  
代理人 小林 泰  
代理人 大牧 綾子  
代理人 大房 直樹  
代理人 中村 彰吾  

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