【事件の表示】
　平成１１年特許願第１２０８８５号「複数の文書サーバから文書を取り出す方法，システムおよび記憶媒体」拒絶査定不服審判事件〔平成１２年　１月１４日出願公開，特開２０００−　１１００８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，平成１１年４月２８日（パリ条約による優先権主張　１９９８年（平成１０年）５月１２日，米国）の出願であって，平成１２年３月１４日付けで拒絶査定がなされ，これに対し，同年６月２６日に拒絶査定に対する審判請求がなされるとともに，同日付けで手続補正がなされたものである。
　そして，上記平成１２年６月２６日付け手続補正は，請求項１４〜２５の記載を補正するものであるところ，この補正は，原審の拒絶の理由に示された事項について，明りょうでない記載の釈明を目的としてなされたものである。
　したがって，本願の請求項１に係る発明（以下「本願発明」という。）は，上記平成１２年６月２６日付け手続補正により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された次の事項により特定されるものである。
　「文書サーバのうちの少なくとも２つの文書サーバが異なるアプリケーション・プログラムを含み，各文書サーバがその中に記憶された各文書に関連づけられたそれぞれのレコードを含み，前記文書サーバのうちの少なくとも２つの文書サーバが，関連のないデータ・フィールドを有する異なるレコードを含む，複数の文書サーバから単一のクライアント・セッションに文書を取り出す方法であって，
　検索テンプレート内に表示された検索フィールドが前記文書サーバ内の関連のないそれぞれのデータ・フィールドにマップされた，前記単一のクライアント・セッション中に提示された検索テンプレート内に表示された１つまたは複数の検索フィールド内に検索基準を入力するステップと，
　入力された前記検索基準と一致するデータの各検索フィールドにマップされた関連のない前記データ・フィールドを含む前記文書サーバ内で前記異なるレコードを検索するステップと，
　前記検索テンプレート内で，入力された前記検索基準と一致するデータを含む前記異なるレコードに関連づけられた文書のリストを表示するステップとを含む方法。」
　
２　引用例
　これに対して，原審の拒絶の理由に引用された，本願の出願日前に頒布された，富田，外３名「WWWによるマルチデータベース検索システム：WebSENA」ＮＴＴ技術ジャーナル，Vol.10，No.5，1998，p.55-58（平１０−５−１）（以下「引用例１」という。），大野，外４名「イントラネット対応図面／文書管理システム“FINALFILING Webオプション”」三菱電機技報，Vol.72，No.2，1998，p.150-153（平１０−２−２５）（以下「引用例２」という。）には，それぞれ，図面とともに次の事項が記載されている。
　
２−１　引用例１の記載事項
(ア)「ネットワークの高度化とコンピュータの普及に伴って，個別に構築された複数のデータベースを複合的に利用することが重要になってきています。本稿では，インターネット／イントラネット上で複数の異種データベースから，個々のデータベースの所在・構造・表現形式の違いを意識することなく，WWWを利用して情報検索が行えるシステムの構築技術を紹介します。」（５５頁論文の要約の部分）
(イ)「従来，データベースシステムは各部門や組織において独自に構築・利用されてきました。データベースシステムの普及に伴って，データの２重投入などを避ける目的で，複数のシステムを結合してデータの抽出／変換／集約を行う仕組みが出現しました。最近では，データウェアハウスに蓄積された情報に基づいた経営分析や，市場動向調査のためのデータマイニングも行われています。これらの傾向はインターネット／イントラネットの普及によって一段と強まっています。
　ところが，ネットワーク上にあるそれぞれのデータベースは，構築時期や設計者が異なりますから，当然データベースの間には様々な相違があります。データベース管理システムの相違・項目名の相違・データ構造の相違・データの表現形式の相違といったものがそうです。これらの相違が複数のデータベースから必要な情報を手に入れることを困難にしています（図２）。
　このようなデータベース間の相違を解消し，ネットワーク上の複数の異種データベースにまたがって情報を検索すること（マルチデータベース検索）を可能にするシステムとして，複数データベース検索用ナビゲーションシステムDBSENAがあります（図３）。このDBSENAとイントラネットアプリケーション開発環境WebBASEを連携させることで，インターネット／イントラネット環境でのWWWを利用したマルチデータベース検索システムの容易な構築を可能にしました。」（５５頁中欄１行〜５６頁左欄末行）
(ウ)「マルチデータベース検索連携機能によってWebBASEスクリプトから利用可能なDBSENAの主な機能には，情報の所在位置の特定，情報の構造や表現形式の取得および変換，情報を取得するための検索条件文（SQL）の生成などがあります。
　(1) 情報の所在位置の特定
　欲しい情報の項目名とその条件からなる検索要求を指定することで，ネットワーク上のどのデータベースのどこにそれらの情報が格納されているかを特定することができます。
　(2) 情報の構造や表現形式の取得・変換
　欲しい情報が各データベース中でどのようなデータ構造や形式で定義されているかについての情報を取得し，検索要求を各データベースの構造や表現形式に変換することができます。
　(3) 情報を取得するための検索命令文の生成
　欲しい情報を各データベースから取得するための検索命令文を生成することができます。
　(4) 検索の実行および検索結果の変換
　前項で生成した検索命令文を実行し，得られた検索結果を利用者の指定した形式に変換することができます。
　これらの機能を利用することによって，利用者は，個々のデータベースの所在や構造，データの表現形式などの違いを全く意識することなく，複数のデータベースから一括して欲しい情報を取得できるようになります。」（５７頁右欄９行〜５８頁左欄１６行）
(エ)「WebBASEとDBSENAの連携によるマルチデータベース検索システムを実際に構築しました（図４）。ユーザインタフェースおよびDBSENA制御ルーチンはすべてWebBASEスクリプトで記述してあります。スクリプト内部では，マルチデータベース検索連携機構を通してDBSENAの機能を呼び出しています。
　欲しい情報の項目名と情報に対する条件を入力し検索ボタンを押すと，検索結果が得られます。その際に，DBSENAの機能を利用して，適切なデータベースの選択および項目名や値の表現形式の変換を行います（図５）。」（５８頁左欄１８行〜中欄１０行）
(オ) 図２には，販売管理データベース，書籍データベース及び在庫データベースにおけるレコードの例が記載されており，各レコードは，複数のフィールドからなり，本来は同じ項目名であるフィールドが，データベースによって「書名，題名，書籍名」，「著者，筆者，著作者」，「価格，値段」のように，異なる項目名で構成されていることが開示されている。
(カ) 図５には，検索条件入力画面と検索結果画面が記載されており，検索条件入力画面には，知りたい情報の項目名を入力する欄と，知りたい情報に対する条件を入力する欄が用意されている。
　そして，知りたい情報に対する条件，すなわち，検索条件として，「定価」が「１０００円」を「超えている」こと，及び，「販売日」が「平成１０年１月１日」「以降である」ことが「AND」条件で入力されると，「定価」と「販売日」の項目名に対応する項目名が存在する販売管理データベースと書籍データベースが選択され，販売管理データベースでは，「定価」が「値段」に変換され，書籍データベースでは，「定価」が「価格」に，「販売日」が「発売日」に変換されて，それぞれのデータベースが検索され，検索条件を満たすデータを含むレコードが抽出され，抽出されたレコード中の知りたい情報が検索結果画面にリスト形式で表示されることが開示されている。
　
２−２　引用例２の記載事項
(キ)「近年のオフィスでは文書や図面の電子化が進み，これを管理するための電子書庫や電子図庫が，利用目的別／部門別にシステム化されてきている。
　電子書庫や電子図庫によるマルチメディアデータの電子的な管理は，大量／大容量の情報を確実に保管し，高速な検索及び利用を可能にしたことで，ユーザーの業務効率改善に寄与してきた。」（４５頁左欄２〜８行）
(ク)「FINALFILINGは，大量／大容量のマルチメディアデータを管理するため，データベースによる検索キーの管理とファイルサーバによるマルチメディアデータの管理を行い，サーバ上のデータを操作性の良い画面から登録・検索・編集・印刷することができる。
2.1　サーバ機能
　FINALFILINGでは，データを確実に保管するための機能として，ユーザー認証によるデータへのアクセス権管理とともに，アクセス権ごとに使用できる機能の制限も可能となっている。また，データ保全のために，データベースとファイルサーバの二重化やバックアップ／リカバリ機能も持っている。
2.2　リクエスタ機能
　データを利用する機能として，分類／階層検索，キーワード検索があり，データ取出し機能，簡単な操作での編集／参照機能，参照アプリケーションの定義機能，拡大／縮小が可能な印刷機能がある。
　入力機能としては，検索キーを付与してのマルチメディアデータの登録，オプション追加で，イメージスキャナでの読込みイメージデータからの文字抽出，ＳＧＭＬ（Standard Generalized Markup Language）への自動変換も可能である。
　図１に登録画面，図２に検索条件画面，図３に一覧画面と一覧画面から表示した参照画面を示す。
2.3　Webオプション機能
　Webオプションでは，FINALFILINGのリクエスタ機能のうち，検索機能として，あいまい（曖昧）／範囲指定でのキーワード検索，登録文書の文章全体を検索対象とする全文検索機能，参照機能がCGI（Common Gateway Interface）で提供されている。
2.4　ソフトウェア構成
　FINALFILINGは，図面／文書／画像などのメタデータを属性として管理するデータベース部分，図面／文書の実体をファイルの形で管理するファイルサーバ部分，サーバ上のデータにアクセスするクライアント部分からなる。
　またクライアント部分は，サーバへアクセスするためのライブラリ部分，画面からマルチメディアデータを操作するリクエスタ部分からなる。
　Webオプションでは，FINALFILINGのリクエスタ部分をサーバにアクセスするためのCGIアプリケーション部分とWWW（World Wide Web）ブラウザ操作を行うクライアントに分けて実現している。
　FINALFILING及びWebオプションのソフトウェア構成を図４に示す。」（４５頁右欄１０行〜４６頁左欄２１行）
(ケ) 図１には，図面や文書の実体に対応するメタデータを登録するために，実体のファイル名とメタデータとして名称，作成者，作成日時，サイズ，版名を入力する登録画面が開示されている。
(コ) 図２には，検索条件として，名称，作成者，作成日時，サイズ，版名の入力が可能である検索条件画面が開示されている。
　
２−３　引用例記載発明
　上記２−１の記載事項を総合すると，引用例１には，
「各データベースが複数のフィールドからなるレコードを含み，各データベースのうちの少なくとも２つのデータベースが，相違する項目名のフィールドを有する異なるレコードを含む，複数のデータベースから一括して欲しい情報を取り出す方法であって，
　検索条件入力画面内に表示された１つまたは複数の検索条件入力欄内に欲しい情報の項目名と検索条件を入力するステップと，
　入力された項目名に対応する項目名のフィールドを含む前記各データベースを選択し，入力された前記項目名を前記各データベース内での項目名に変換し，前記各データベース内で前記検索条件と一致するデータのフィールドを含む前記異なるレコードを検索するステップと，
　入力された前記検索条件と一致するデータのフィールドを含む前記異なるレコードのフィールドの情報を検索結果画面に一覧表示するステップとを含む方法。」
の発明（以下「引用例記載発明」という。）が記載されていると認められる。
　
３　対比
(1) そこで，本願発明（以下「前者」という。）と引用例記載発明（以下「後者」という。）とを対比すると，後者の「データベース」と前者の「文書サーバ」とは，管理する情報が相違するが，電子化された情報を管理する手段（以下「情報管理手段」という。）という概念で共通する。
　また，後者の「レコード」は，データベースのレコードそのものであり，文書に関連づけられたものではないが，検索の対象となる情報である点で，前者の「レコード」に対応する。
　また，後者の「フィールド」は，検索の際，ここに入力されているデータが検索条件と一致するか否かということで検索されるのであるから，前者の「データ・フィールド」に相当する。そして，後者の少なくとも２つのデータベースにおいて，項目名が相違する「フィールド」が，相互に関連づけられていないことは明らかである。
　また，後者の「検索条件入力画面」，「検索条件入力欄」，「検索条件」は，前者の「検索テンプレート」，「検索フィールド」，「検索基準」に相当する。
　また，後者の「一括して」「取り出す」ことは，取り出す情報の相違を別にして，前者の「単一のクライアント・セッションに」「取り出す」ことに対応する。
　また，後者の「一覧表示」は，前者の「リストを表示」に相当する。
(2) そうすると，両者は，
　「各情報管理手段がレコードを含み，前記情報管理手段のうちの少なくとも２つの情報管理手段が，関連のないデータ・フィールドを有する異なるレコードを含む，複数の情報管理手段から単一のクライアント・セッションに情報を取り出す方法であって，
　前記単一のクライアント・セッション中に提示された検索テンプレート内に表示された１つまたは複数の検索フィールド内に検索基準を入力するステップと，
　入力された前記検索基準と一致するデータの前記情報管理手段内で前記異なるレコードを検索するステップと，
　入力された前記検索基準と一致するデータを含む前記異なるレコードに係る情報のリストを表示するステップとを含む方法。」
である点で一致し，下記の点で相違する。
　
〔相違点１〕前者の情報管理手段は，「文書サーバ」であり，前者は，「文書」を取り出すのに対し，後者のそれは，データベースであり，後者は，フィールドの情報を取り出す点。
〔相違点２〕前者は，「文書サーバのうちの少なくとも２つの文書サーバが異なるアプリケーション・プログラムを含」むのに対し，後者はそうでない点。
〔相違点３〕前者の「レコード」は，文書サーバの「中に記憶された各文書に関連づけられたそれぞれ」であるのに対し，後者のそれは，データベースのレコードそのものである点。
〔相違点４〕前者のテンプレートは，「検索テンプレート内に表示された検索フィールドが前記文書サーバ内の関連のないそれぞれのデータ・フィールドにマップされ」ているのに対し，後者のそれは，そうでない点。
〔相違点５〕前者は，「各検索フィールドにマップされた関連のない前記データ・フィールドを含む前記文書サーバ内で」検索するのに対し，後者は，変換された項目名のフィールドを含む各データベース内で検索する点。
〔相違点６〕前者は，「前記検索テンプレート内で，」前記異なるレコード「に関連づけられた文書」のリストを表示するのに対し，後者は，検索結果画面に前記異なるレコードのフィールドの情報のリストを表示する点。
　
４　判断
(1) 相違点１，３について
　引用例２には，文書実体をサーバ中のファイルサーバ部分に記憶し，ファイルサーバ部分の中に記憶された各文書について，名称，作成者，作成日時，サイズ等の書誌情報（メタデータ）を属性としてデータベース部分で管理し，検索条件画面で入力された書誌情報を検索条件としてデータベース部分を検索し，検索条件と一致する属性を有する文書を一覧表示して取り出すことが開示されている。
　ここにおいて，名称，作成者，作成日時，サイズ等の書誌情報の各項目がデータベースにおけるフィールドに相当し，これらの書誌情報の項目が集まってデータベースのレコードを構成していること，並びに，各レコードが各文書実体と関連づけられていることは，当業者には自明の事項である。
　そして，文書実体を記憶するファイルサーバ部分及びデータベース部分からなるサーバは，全体として文書を記憶する文書サーバということができる。
　引用例１，２は，データベースという共通の技術分野に属するものであるから，引用例記載発明のデータベース検索において，データベース中のレコードの情報そのものを取り出す構成に代えて，検索の対象とするデータベースを，引用例２に開示された文書実体と関連づけられたレコードを含むデータベースとし，検索条件と一致するレコードに関連づけられた文書を取り出すようにすることは，当業者が容易になし得ることである。
　してみると，引用例記載発明において，情報管理手段を文書サーバとし，レコードを文書サーバの中に記憶された各文書に関連づけられたそれぞれとして，複数の文書サーバから文書を取り出す構成とすることは，当業者が容易に想到し得ることである。
(2) 相違点２について
　特定のアプリケーション・プログラムで作成した文書を，それぞれの文書サーバで維持・管理し，各文書サーバが異なるアプリケーション・プログラムを含むようにすることは，本願明細書に従来技術として記載されているように周知の事項である。
　してみると，引用例記載発明において，文書管理手段を文書サーバとする構成を採用すれば，文書サーバのうちの少なくとも２つの文書サーバが異なるアプリケーション・プログラムを含むようになることは，当業者が容易に想到し得ることである。
(3) 相違点４，５について
　引用例１の検索条件入力画面は，検索フィールドが固定されておらず，検索項目名を検索入力欄に適宜入力するものであるが，入力された各検索項目名は，データベースの対応するフィールドの項目名に変換されて検索されるのであるから，検索条件入力画面で入力された各検索項目名は，データベースのそれぞれのフィールドの項目名にマップされるということができる。
　そして，検索条件入力画面の検索フィールドを固定することは，引用例２に記載されるように周知の事項であるから，引用例記載発明の検索テンプレートの検索フィールドの検索項目名を固定し，各検索フィールドをデータベース内の関連のないそれぞれのデータ・フィールドにマップさせておくことは，当業者が容易になし得ることである。
　そして，引用例記載発明の検索テンプレートの検索フィールドの検索項目名を固定し，各検索フィールドをデータベース内の関連のないそれぞれのデータ・フィールドにマップさせる構成を採用すれば，検索の際，各検索フィールドにマップされた関連のない前記データ・フィールドを含む前記文書サーバ内で検索する構成となることは，当業者が容易に想到し得ることである。
(4) 相違点６について
　検索結果を検索条件入力画面とは別の検索結果画面に表示するか，検索条件入力画面内に表示するかは，表示画面の物理的大きさ，ユーザの好み等に応じて，当業者が適宜選定する事項である。
　そして，異なるレコードに関連づけられた文書のリストを表示することは，引用例記載発明において，文書管理手段を文書サーバとし，文書を取り出す構成を採用することに伴い，直ちに導出される事項である。
(5) 作用効果について
　本願発明の作用効果についてみても，引用例１，２から当業者が予測し得る程度のものであり，格別のものとはいえない。
　
５　むすび
　したがって，本願発明は，引用例記載発明，引用例２に記載された事項及び周知事項に基づいて，当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。