• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1285805
審判番号 不服2012-23229  
総通号数 173 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-05-30 
種別 拒絶査定不服の審決 
審判請求日 2012-11-26 
確定日 2014-03-14 
事件の表示 特願2007- 94062「コード変換システム、コード変換方法、コード対応関係情報生成方法、およびコンピュータプログラム」拒絶査定不服審判事件〔平成20年10月16日出願公開、特開2008-250861〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は平成19年3月30日の出願であって,平成23年12月27日付けの拒絶理由通知に対して,平成24年3月6日に意見書の提出とともに手続補正がなされ,平成24年8月24日付けで拒絶査定され,これに対し,平成24年11月26日に審判が請求されたものである。

第2 本願発明
平成24年3月6日に提出された手続補正書により補正された特許請求の範囲の記載によれば,本願の請求項1に係る発明(以下「本願発明」という。)は,次のとおりである。
「複数の項目のデータからなる第一のレコードが複数格納されている第一のマスタを記憶する第一のマスタ記憶手段と,
複数の項目のデータからなる第二のレコードが複数格納されている第二のマスタを記憶する第二のマスタ記憶手段と,
同一の事項に関する,前記第一のレコードの項目および前記第二のレコードの項目を判別する,同一項目判別手段と,
前記第一のマスタおよび前記第二のマスタの中から,同一の事項に関すると判別された項目の内容同士を照合し,重要度に応じて付けられている順位が上位である項目についての照合の結果ほど重みを付け,重みを付けた当該結果に基づいて同一の対象に関する前記第一のレコードおよび前記第二のレコードを判別する,同一対象レコード判別手段と,
同一の対象に関すると判別された前記第一のレコードに示される所定の項目のコードと前記第二のレコードに示される所定の項目のコードとを対応付けて示すコード対応関係情報を記憶する対応コード記憶手段と,
入力された,前記第一のマスタで使用されるコードを,前記コード対応関係情報に基づいて,前記第二のマスタで使用されるコードに変換する,コード変換手段と,
を有することを特徴とするコード変換システム。」

第3 原査定の拒絶の理由について
原査定の拒絶理由の概要は,以下のとおりである。
【拒絶理由】
『この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
記 (引用文献等については引用文献等一覧参照)
・請求項 1-8
・引用文献等 1-3
・備考
(途中略)
引 用 文 献 等 一 覧
1.特開2003-173280号公報
2.特開2005-115644号公報
3.特開2002-109451号公報』
【拒絶査定】
『この出願については,平成23年12月27日付け拒絶理由通知書に記載した理由によって,拒絶をすべきものです。
なお,意見書及び手続補正書の内容を検討しましたが,拒絶理由を覆すに足りる根拠が見いだせません。
備考
(以下略)』

第4 当審の判断
1.引用例について。
(1)引用例1と引用発明について。
原査定の拒絶理由通知で引用文献1として引用した「特開2003-173280号公報」(以下「引用例1」という。)には,図面とともに以下のことが記載されている。
(以下「引用例1摘記事項」という。)
(ア)「【0001】【発明の属する技術分野】本発明は,インターネット等のネットワーク上に分散配置され,店などの案内情報等を独立に管理・運営している複数のサーバ等からデータを収集し,検索・案内するためのデータベースを生成する装置及び方法,並びにそのプログラムに関する。」
(イ)「【0014】図2は,本発明の一実施形態のデータベース生成方法のフローチャートを示す図である。以下,図2のフローチャートに従って,本データベース生成装置10の動作を詳しく説明する。
【0015】データベース生成装置10では,データ収集手段11において,一定期間や特定日時ごと(例えば,1日,1週間,毎月曜日など)に,各情報サーバ20にアクセスし,各情報サーバ20内のデータ(データ集合)を収集する(ステップ111)。ここで,各データは一つのファイルであり,全てのファイルがあるディレクトリ配下にあるものとする。このディレクトリの所在は,データベース生成装置10の管理者と各情報サーバ20の管理者との間であらかじめ取り決めがなされており,データ収集手段11は,各情報サーバ20の該ディレクトリ配下のファイル群をダウンロードし,例えばRAMやハードディスク等に一時的に格納する。ここで,ファイルとともに,データの名称となるファイル名(これが当該データのリンク情報となる)とファイルの更新日時の情報も取得する。
【0016】図3は,情報サーバA及びBからダウンロードしたデータの一例を示したものである。この例では,同一店舗「紅蘭亭」のデータが情報サーバAにもBにも登録されているものとし,そのデータを示したものである。図3に示すように,情報サーバAとBでは,同一店舗「紅蘭亭」でも,名義や住所等が異なる形式,表現で登録されている。
【0017】次に,属性情報抽出手段12において,上記データ収集手段11で収集した各データから名義や住所などの該データを特徴付ける属性の値を抽出する(ステップ112)。各データファイルは典型的にはHTML文書やXML文書であり,ユーザはユーザ端末30を用いてWWWソフトウェア(WWWブラウザ)から該当ファイルのURLにアクセスすることにより,その内容を閲覧することができるものである。各データファイルの内容が,どういった属性からなり,各属性がどのようなフォーマットで記述されているかといったフォーマット情報は,各情報サーバ20ごとに決められている。ここでは,各情報サーバに対応したデータファイルフォーマット解析ルーチンを属性情報抽出手段12が保持しているとする。属性情報抽出手段12は,各情報サーバに対応したデータファイルフォーマット解析ルーチンにより,データファイルから名義や住所などの属性値を抽出する。次に,属性情報抽出手段12では,抽出した名義や住所などの属性値と該データが存在する情報サーバ名及び該データのリンク情報及び更新日時の情報等からなるデータ(レコード)を作成し,このようなデータが集積したデータベースを生成してデータベース格納部16に格納する。この新たに生成されたデータベースを新データベース18とする。また,前回(1日前,1週間前など),同様に各情報サーバ20からデータを収集して生成し,後述の名寄せ,結合,更新情報付与等の処理を施したデータベースを旧データベース17とする。
【0018】図4は,新たに生成されたデータベース(新データベース)18の一例を示したもので,(a)は情報サーバAのデータ,(b)は情報サーバBのデータである。ここでは,抽出する属性として業種,名義,住所をとっている。業種体系は情報サーバ20ごとに一般に異なっている。また,同一店舗のデータでも,情報サーバが異なれば,名義や住所の表記には揺れがある。
【0019】なお,情報サーバ20が,店のデータファイルの他に,各店の名義や住所,電話番号,リンク情報などの基本情報のみが記載されているデータのリストからなるファイルをもっている場合,データ収集手段11において,データファイル群の代わりに,そのようなリストファイルをダウンロードしてもよい。この場合,属性情報抽出手段12においては,リストファイルの各データから名義,住所,リンク情報などを抽出し,抽出したリンク情報をもとに,再び情報サーバ20にアクセスし,データファイルの更新日時情報を取得する。そして,同様に図4のような新データベース18を生成する。
【0020】次に,名寄せ手段13において,新データベース18内の名義や住所などの属性の値が同一とみなせるデータ(レコード)を同一グループに分類する(ステップ113)。即ち,同一店舗として名寄せする。
【0021】例えば,図4に示した新データベース18の任意の2データ間において,名義及び住所の属性の値同士を照合し,マッチしたレコード同士を同一グループに分類する。名義文字列や住所文字列の照合方法には例えば次のようなものが考えられる。一つには完全一致したときマッチするとみなす方法(完全一致と呼ぶ)があり,また,両方に共通して含まれる文字の数の割合がある閾値以上のときマッチするとみなす方法(文字単位一致と呼ぶ)がある。他には,文字列を単語分割して両方に共通して含まれる単語の数の割合がある閾値以上のときマッチするとみなす方法(単語単位一致と呼ぶ)がある。いずれの方法も,漢数字を算用数字に変換したり,英字を大文字に統一化するといった表記の揺れを解消する処理を事前に行うことにより,より照合の精度を高めることが可能である。 照合の結果,図4の例では,1番目と4番目のデータ(レコード)がマッチし,3番目と6番目のデータがマッチする。このマッチしたレコード同士を同一グループに分類する。ここで,各グループを通常のデータと区別して,名寄せデータと呼ぶことにする。
【0022】名寄せ手段13では,各名寄せデータの名義や住所の属性値として,例えば当該名寄せデータに含まれるデータの名義や住所の属性値から一つだけ選んで,その値そのものを用いるか,あるいは正規化した値に変換する。また,各データの業種名は,データベース生成装置10独自の業種体系における対応する業種名に変換する。
【0023】図4について,こうして更新された新データベース18の一例を図5に示す。例えば,データベース生成装置10独自の業種体系では,業種として「和食」,「中華」などがあり,図4におけるデータの業種名はいずれも「中華」に変換される。図5において,同一グループに分類された1番目と4番目のデータの業種名はともに「中華」に変換されるので,名寄せデータとしての業種名も「中華」となる。3番目と6番目のデータに関しても同様である。また,名寄せデータの名義や住所の属性値としては,1番目と4番目のデータでは,名義は「紅蘭亭」を選択し,住所は「新宿区神楽坂1-2-3」を選択している。同様に,3番目と6番目のデータでは,名義は「大竹亭」を選択し,住所は「新宿区神楽坂3-8-6」を選択している。なお,図5中の新データベース18の「更新情報」の欄は後述の更新情報付与手段15で書き替えられるもので,ここでは全て空(NULL)としておく。
【0024】ここで,どの属性値同士をどの照合方法で照合させるかといった照合ルールは,名寄せ手段13を実現するプログラム内に記述してもよいし,データベース生成装置10内の,プログラムが参照する外付けテーブルに記述して,データベース生成装置10の管理者が,この外付けテーブルを自由に変更できるようにしておいてもよい。
【0025】図6は,このような外付けテーブルの内容の一例である。図6(a)では,データが一致する基準を記述する。この例では,照合項目として名義と住所を指定している。名義の照合結果の評価値が90点以上かつ住所の照合結果の評価値が80点以上の場合,あるいは名義の照合結果の評価値が80点以上かつ住所の照合結果の評価値が90点以上の場合,2データが一致すると判定する。図6(b)では,名義の照合方法を記述する。ここでは,照合方法として完全一致,文字単位一致,単語単位一致を指定しており,各方法による照合を行う。完全一致の照合処理で一致したならば評価値100とし,一致しなければ評価値0とする。文字単位一致の照合結果の評価値は一致した文字の数の割合に100を乗じたものとする。単語単位一致の照合結果の評価値も一致した単語の数の割合に100を乗じたものとする。一番高い評価値を返した照合方法の評価値を名義の評価値とする。図6(c)では,住所の照合方法を同様に記述する。ここでは,照合方法として完全一致,単語単位一致を指定している。一番高い評価値を返した照合方法の評価値を住所の評価値とする。
【0026】次に,結合手段14において,データベース格納部16にある,名寄せ後の新データベース18と,前回各情報サーバ20からデータを収集して,生成した旧データベース17との間で,名義や住所などの属性の値が同一とみなせる名寄せデータ同士を同一と判断してリンク付けし,対応付けする(ステップ114)。例えば,新旧データベース17,18内の同一と判断された両データに,同一なデータであることを示す情報を付与するなどしてリンク付けし,対応付けする。
【0027】ここでは,情報サーバ20において,同一データのリンク情報が時の経過とともに変わり得るという前提であるものとする。各データの更新情報を導出するにあたっては,新データと旧データの更新日時などを比較する必要があり,そのためには,新旧データベースにおいて,どのデータが同一かを判断しなけれならない。リンク情報が不変であれば,リンク情報が同一かで判断できるが,リンク情報が変わり得るという前提のもとでは,データがもつ名義や住所の属性値が同一かで判断する必要があるわけである。ここで,同一データであっても時の経過とともに,名義などが微妙に変更される場合もありうるので,照合は,表記の揺れを考慮して行う。具体的には,例えば完全一致以外に文字端単位一致や単語単位一致といった照合方法で行う。基本的には名寄せの場合と同様である。また,照合の対象となる項目を,例えば名義のみにすると,同一店の住所が変更しても,新旧のデータはマッチすることになる。このように,どのような条件で新旧のデータを同一視するかは,照合ルールを変更することにより調節可能である。図7に,外付けテーブルに記述する照合ルールにおけるデータ一致基準の一例を示す。ここでは照合項目として名義のみを指定した例を示している。名義の照合方法の記述は,例えば図6と同様にすればよい。
【0028】図8は,旧データベース17の一例である。便宜上,図8では,各データは前々回から更新がなかったとしている。結合手段14では,図5に示した新データベース18の各名寄せデータと同一な旧データベース17の名寄せデータを,名義のみあるいは名義及び住所の属性値同士を照合することによって特定する。その結果,図5の新データベース18の1番目,2番目,3番目の名寄せデータがそれぞれ,図8の旧データベース17の1番目,2番目,3番目の名寄せデータにリンク付けされる。図5の新データベース18の4番目の名寄せデータにリンク付けされる名寄せデータは,図8の旧データベース17には存在しない。なお,リンク付けされた名寄せデータ内の同一の対応情報サーバをもつデータ同士も,同一のデータとしてリンク付けされる。以後,図5,図8の各データを上から何番目かで表現する。
【0029】次に,更新情報付与手段15において,新データベース18のデータのリンク情報や更新日時の情報と,結合手段14により該データと同一と判断された旧データベース17中のデータのリンク情報や更新日時の情報とを比較することにより,新データベース18中の該当データに更新情報を設定・付与する(ステップ115)。即ち,新データベース18中のデータとリンク付けされた旧データベース17のデータがあり,かつリンク情報または更新日時が変更されているとき,該データは更新されたものと判断し,いずれも変更されていないとき,該データは更新なしと判断し,新データベース18中の該当データの更新情報を「更新」あるいは「更新なし」とする。また,新データベース18中のデータとリンク付けされた旧データベース17のデータがない場合,該データは新規に作成されたものと判断し,新データベース18中の該当データの更新情報を「新規」とする。
【0030】例えば,図5の新データベース18の1番目のデータは,リンク付けされた図8の旧データベース17の1番目のデータと,リンク情報が同じで,更新日時が変わっているので,当該データは更新されたものと判断する。
【0031】図5の新データベース18の2番目のデータは,リンク付けされた図8の旧データベース17の2番目のデータと比べ,リンク情報も更新日時も不変なので,当該データは更新されていないものと判断する。図5の新データベース18の4番目のデータについても同様である。
【0032】図5の新データベース18の3番目のデータは,リンク付けされた図8の旧データベース17の3番目のデータと比べ,更新日時は変わらないが,リンク情報が変わっているので,当該データは更新されたものと判断する。
【0033】図5の新データベース18の5番目のデータは,名寄せデータとしては,図8の旧データベース17の3番目の名寄せデータとリンクしているが,データとしてリンク付けされたデータは図8の旧データベース17にないので,新規に作成されたものと判断する。
【0034】図5の新データベース18の6番目のデータにリンク付けされたデータは,図8の旧データベース17にないので,当該データは新規に作成されたものと判断する。
【0035】このようにして,図5の新データベース18と図8の旧データベース17の場合,図9に示すような更新情報の付与された新データベース18が最終的に生成される。更新情報付与手段15では,この最終的に生成された新データベース18でもって旧データベース17を上書きする。
【0036】以上によりデータベースの生成が終了する。最終的に生成されたデータベースにユーザ端末30からアクセスし,ユーザの要求に合致するデータを検索し表示したときには,名寄せデータの業種,名義,住所の情報と,該データが存在する情報サーバ20内のファイルへのリンク情報及び更新情報が表示される。図10は,図9の生成データベースにより,業種が「中華」で住所が「新宿区神楽坂」である店を検索したときの検索結果の表示例である。ユーザはこのリンク情報を画面上でクリックすることにより,リンク先のファイルの内容である店の詳細情報にアクセスすることができる。」

上記摘記事項(ア)(イ)によれば,引用例1には,以下の発明が開示されている。
(以下「引用発明」という。)
「分散配置され,店の案内情報を独立に管理・運営する複数のサーバからデータを収集し,検索・案内するためのデータベースを生成するものであって,
データベース生成装置10は,一定期間や特定日時ごとに,各情報サーバ20にアクセスし,各情報サーバ20内のデータを収集し,
情報サーバAとBでは,同一店舗「紅蘭亭」でも,名義や住所等が異なる形式,表現で登録され,
属性情報抽出手段12が収集した各データから名義や住所などの該データを特徴付ける属性の値を抽出する際,各データファイルのフォーマット情報は各情報サーバ20ごとに決められていることから,各情報サーバに対応したデータファイルフォーマット解析ルーチンを属性情報抽出手段12が保持し,各情報サーバに対応したデータファイルフォーマット解析ルーチンにより,データファイルから名義や住所などの属性値を抽出し,抽出した名義や住所などの属性値と情報サーバ名,リンク情報,更新日時等のデータレコードを作成し,データが集積したデータベースを生成してデータベース格納部16に格納して新データベース18とし,
ここで,前回の収集,生成,名寄せ,結合,更新情報付与等の処理を施したデータベースは旧データベース17であり,
例えば図4の新データベース18は情報サーバAのデータと情報サーバBのデータであって,同一店舗のデータでも,名義や住所の表記には揺れがあることから,名寄せ手段13で,新データベース18内の名義や住所などの属性の値が同一とみなせるデータレコードを同一グループに分類すること,
ここで,名義及び住所の属性の値同士を照合し,マッチしたレコード同士を同一グループに分類する照合方法には,完全一致や文字単位一致や単語単位一致などがありマッチしたレコード同士を同一グループに分類すること,
名寄せ手段13では,各名寄せデータの名義や住所の属性値として,例えば当該名寄せデータに含まれるデータの名義や住所の属性値から一つだけ選んで,その値そのものを用い,例えば図5の更新された新データベース18では,名寄せデータの名義や住所の属性値としては,1番目と4番目のデータでは,1番目のデータ,つまり名義は「紅蘭亭」を,住所は「新宿区神楽坂1-2-3」を選択し,
結合手段14で,新旧データベース17,18内の同一と判断された両データに,同一なデータであることを示す情報を付与するなどしてリンク付けし,対応付けし,
ここで,リンク情報が変わり得るという前提でデータがもつ名義や住所の属性値が同一かで判断する必要があり,同一データでも時の経過とともに,名義などが微妙に変更される場合もありうるので,照合は,表記の揺れを考慮して行ったり,照合の対象となる項目を,例えば名義のみにすると,同一店の住所が変更しても,新旧のデータはマッチすることになり,
更新情報付与手段15において,リンク情報や更新日時の情報を比較することにより,新データベース18に更新情報を設定・付与して図9の更新情報が付与された新データベース18を最終的に生成し,
このデータベースにユーザ端末30からアクセスし,ユーザの要求に合致するデータを検索し表示したときには,名寄せデータの業種,名義,住所の情報と,該データが存在する情報サーバ20内のファイルへのリンク情報及び更新情報が表示されるもの。」

(2)引用例2と引用例2記載事項について。
原査定の拒絶理由通知で引用文献2として引用した「特開2005-115644号公報」(以下「引用例2」という。)には,図面とともに以下のことが記載されている。
(以下「引用例2摘記事項」という。)
(ア)「【実施例4】
【0069】
図18は実施例4のシステム構成を示すブロック図である。
なお,本実施例の自動取引装置1および取引カード20の構成は,図2および図3に示す実施例1の構成と同様である。また上記実施例1と同様の部分は同一の符号を付してその説明を省略する。
30は金融機関等のセンタに設置された顧客情報管理サーバであり,ホストコンピュータ2と接続しており,金融機関等がその顧客を識別するために付与した顧客識別IDに対応させて顧客の氏名,住所,電話番号,生年月日,職業,家族構成,資産残高等の顧客情報を格納した顧客情報ファイルを保有して金融機関等の顧客の情報を管理する。
【0070】
上記の構成の作用について説明する。
なお,金融機関等と代理店および広告主6との委託および契約,並びに金融機関等から顧客への取引カード20の発行および広告運用サーバ4の広告主データベース7に格納されている顧客マスタ情報とキャンペーン情報は上記実施例1と同様であるのでその説明を省略する。
【0071】
本実施例の金融機関等は,顧客との口座開設契約等の際に取引中に広告表示を行う広告主6の希望を受付け,金融機関等が保有する顧客情報の利用についての可否を問合せを行う。
顧客が顧客情報の利用に同意しない場合は,上記実施例1と同様にして顧客の個人情報を記入した申込書を広告主6へ送付する。
【0072】
顧客が顧客情報の利用に同意した場合は,申込書の記入は省略して広告主6にその旨を伝え,広告主6が付与した会員番号の通知を受けたときに,その会員番号と金融機関等がその顧客に付与した顧客識別IDとの対照表である図19に示す契約顧客変換テーブルを作成する。
この契約顧客変換テーブルは顧客情報管理サーバ30に格納され,顧客情報管理サーバ30は定期的にまたは必要に応じて顧客情報ファイルから顧客の顧客氏名,住所,電話番号,生年月日,職業,家族構成等の顧客の個人情報を抽出してこれを広告主6の会員番号に対応させて記録媒体に出力する。この記録媒体は広告主6へ送付され,広告主6はこれにより顧客マスタ情報を作成する。」
(イ)図19には,実施例4の契約顧客変換テーブルであって,「A商店会員番号」である「000001」という会員のコードが,「金融機関顧客識別ID」である「1234567890」という顧客識別のコードと対応することが記載されている。

上記摘記事項(ア)(イ)によれば,引用例2には以下の事項が記載されている。
(以下「引用例2記載事項」という。)
「金融機関の顧客情報管理サーバが,金融機関の顧客情報ファイルから顧客の氏名,住所,電話番号,生年月日,職業,家族構成等の顧客の個人情報を抽出し,これを広告主のA商店会員番号に対応させて出力して広告主へ送付し,広告主は,受信した金融機関の個人情報により顧客マスタ情報を作成すようにするべく,広告主が付与したA商店会員番号である『000001』などのコードと,金融機関等が顧客に付与した金融機関顧客識別IDである『1234567890』などのコードとの対照である『契約顧客変換テーブル』を設けてコードを変換すること。」

(3)引用例3と引用例3記載事項について。
原査定の拒絶理由通知で引用文献3として引用した「特開2002-109451号公報」(以下「引用例3」という。)には,図面とともに以下のことが記載されている。
(以下「引用例3摘記事項」という。)
(ア)「【0027】例えば,提出先Aに提出するためのA署申請書と,提出先Bに提出するためのB所申請書が必要な場合は,図3に示すように,2枚の電子フォームデータ31,32の入力が必要になる。この2枚の電子フォームデータ31,32を比較すると,同一項目や,項目名が違っていても同じ意味内容を表す同義語と呼ばれる項目が存在する。これら同一又は同義語項目に設けられている入力欄には同じ内容が入力される。そのためエンドユーザは,同一の内容を両方の電子フォームに対して入力しなければならず,手間がかかる。その手間を省き,効率よく入力するための,同一又は同義語項目の検索を行う方法について以下に説明する。この方法は,タグを利用して,同一又は同義語項目の検索及び抽出を行い,抽出された項目にエンドユーザが内容を入力し,その内容を各電子フォームの同一又は同義語項目に反映させる方法である。
【0028】同一項目の検索は,エンドユーザから要求された複数の電子フォームデータ31,32…において同一であるタグを検索する。具体的には,要求があった2枚の電子フォームデータ31,32を比較して,同一であるタグを検索する。A署申請書とB所申請書の場合,図4からわかるように同一であるタグは,「提出者住所」である。
【0029】一方,同義語項目の検索は,図5に示すように,同義語を検索するためのテーブル45を利用して行う。このテーブル45は上記に示したように,データベース12に格納されている。このテーブル45は,例として,A署申請書とB所申請書における電子フォームデータ31,32のタグについて,同義語をまとめたものである。このテーブル45は,左端の文字列45aに,実体的な意味内容を表す「実体名称」46が含まれ,その「実体名称」46と同義語であるタグの項目を右の文字列に列挙している。
【0030】以上のように,このテーブル45は,「提出者氏名」と,「提出者名称」は同義語であることを表し,「実体名称」46として「氏名」46aを用いることを意味している。同様に,下行に示す「項目A」と「項目D」も同義語であることを表し,「実体名称」46として「種類」46bを用いることを意味している。」

上記摘記事項(ア)及び図5の記載を参照すれば,引用例3には以下の事項が記載されている。
(以下「引用例3記載事項」という。)
「A署申請書の『提出者氏名』とB所申請書の『提出者名称』とが同義語であり,実体名称が『氏名』であることを示す同義語をまとめたテーブルにより,実体が同じか判断すること。」

2.対比
本願発明と,引用発明とを比較する。
(ア)引用発明の,データベース生成装置10は,前回の旧データベース17や今回の新データベース18に格納される,情報サーバAの,名義が「紅蘭亭」で住所が「新宿区神楽坂1-2-3」の店舗の「リンク情報」や「更新日時」からなるデータレコードに,表記の揺れがある情報サーバBの,名義が「ラーメンショップ紅蘭亭」で住所が「新宿区神楽坂1丁目2番地3号」の店舗の「リンク情報」や「更新日時」からなるデータレコードを,変換して統合する。
統合された情報をユーザが検索すると,名義が「紅蘭亭」で住所が「新宿区神楽坂1-2-3」の店舗,つまり情報サーバAの名義と住所の店舗の「リンク情報」を生成して表示する。
つまり,表記の揺れがある情報サーバBの各項目のデータは,対応する情報サーバAの各項目のデータに変換されてデータベース格納部に格納される。
してみると,引用発明の,表記の揺れがある情報サーバBの各項目のデータは,本願発明の,第一のマスタのデータに相当し,これが変換されてデータベース格納部に格納される各項目のデータは本願発明の第二のマスタのデータに相当する。
以上,整理したうえで,以下対比する。
(イ)引用発明の,表記の揺れがある情報サーバBのデータレコードである,名義が「ラーメンショップ紅蘭亭」で住所が「新宿区神楽坂1丁目2番地3号」の店舗の「リンク情報」や「更新日時」からなるデータレコードは,本願発明の「複数の項目のデータ」に相当する。
そして,情報サーバBは店などの案内情報等を独立に管理・運営している複数のサーバの一つであるから,「複数の項目のデータ」からなる「レコード」が「複数格納」されている「マスタ記憶手段」を有する。
してみると,引用発明の,表記の揺れがある情報サーバBは,本願発明の,「複数の項目のデータからなる第一のレコードが複数格納されている第一のマスタを記憶する第一のマスタ記憶手段」に相当する。
そして,引用発明の,情報サーバBの表記のゆれを変換して統合したデータベース格納部に格納される各項目のデータは,本願発明の,「複数の項目のデータからなる第二のレコードが複数格納されている第二のマスタを記憶する第二のマスタ記憶手段」に相当する。
(ウ)引用発明は,「属性情報抽出手段12が収集した各データから名義や住所などの該データを特徴付ける属性の値を抽出する際,各データファイルのフォーマット情報は各情報サーバ20ごとに決められていることから,各情報サーバに対応したデータファイルフォーマット解析ルーチンを属性情報抽出手段12が保持し,各情報サーバに対応したデータファイルフォーマット解析ルーチンにより,データファイルから名義や住所などの属性値を抽出し,抽出した名義や住所などの属性値と情報サーバ名,リンク情報,更新日時等のデータレコードを作成」する。
してみると,引用発明と本願発明とは,後記する点で相違するものの,「同一の事項に関する,第一のレコードの項目および第二のレコードの項目を判別し,第一のマスタおよび第二のマスタの中から,同一の事項に関すると判別された項目の内容」を取得する点で共通する。
(エ)引用発明は,例えば「図4の新データベース18は情報サーバAのデータと情報サーバBのデータであって,同一店舗のデータでも,名義や住所の表記には揺れがあることから,名寄せ手段13で,新データベース18内の名義や住所などの属性の値が同一とみなせるデータレコードを同一グループに分類」するものであり,「名義及び住所の属性の値同士を照合し,マッチしたレコード同士を同一グループに分類する照合方法には,完全一致や文字単位一致や単語単位一致などがあり,マッチしたレコード同士を同一グループに分類」するものである。
してみると,引用発明と本願発明とは,後記する点で相違するものの,「第一のマスタおよび第二のマスタの中から,同一の事項に関すると判別された項目の内容同士を照合し,同一の対象に関する第一のレコードおよび第二のレコードを判別する」という点で共通する。
(オ)引用発明は,「同一と判断された両データに,同一なデータであることを示す情報を付与するなどしてリンク付けし,対応付け」をする。
してみると,引用発明と本願発明とは,後記する点で相違するものの,「同一の対象に関すると判別された第一のレコードに示される所定の項目のレコードと第二のレコードに示される所定の項目のレコードとを対応付け」する点で共通する。
(カ)引用発明は,以上(イ)?(オ)により,前記(ア)のとおり,情報サーバAの,名義が「紅蘭亭」で住所が「新宿区神楽坂1-2-3」の店舗の「リンク情報」や「更新日時」からなるデータレコードに,表記の揺れがある情報サーバBの,名義が「ラーメンショップ紅蘭亭」で住所が「新宿区神楽坂1丁目2番地3号」の店舗の「リンク情報」や「更新日時」からなるデータレコードを,変換して統合することから,引用発明と本願発明とは,後記する点で相違するものの,「入力された,第一のマスタで使用されるレコードを,第二のマスタで使用されるレコードに変換するシステム」である点で共通する。

そうすると両者は,以下の点で一致し,また相違する。
[一致点]
「複数の項目のデータからなる第一のレコードが複数格納されている第一のマスタを記憶する第一のマスタ記憶手段と,
複数の項目のデータからなる第二のレコードが複数格納されている第二のマスタを記憶する第二のマスタ記憶手段と,
同一の事項に関する,第一のレコードの項目および第二のレコードの項目を判別し,第一のマスタおよび第二のマスタの中から,同一の事項に関すると判別された項目の内容同士を照合し,同一の対象に関する第一のレコードおよび第二のレコードを判別し,
同一の対象に関すると判別された第一のレコードに示される所定の項目のコードと第二のレコードに示される所定の項目のコードとを対応付け,
入力された,第一のマスタで使用されるレコードを,第二のマスタで使用されるレコードに変換することを特徴とする変換システム。」
[相違点1]
本願発明が,「同一の事項に関する,第一のレコードの項目および第二のレコードの項目を判別」するための「同一項目判別手段」を有するのに対し,引用発明はそのような手段を有するものではない点。
[相違点2]
本願発明が,「同一の対象に関すると判別された第一のレコードに示される所定の項目のコードと第二のレコードに示される所定の項目のコードとを対応付けて示すコード対応関係情報」を記憶する「対応コード記憶手段」と,「入力された,第一のマスタで使用されるコードを,コード対応関係情報に基づいて,第二のマスタで使用されるコードに変換する,コード変換手段」とを有するのに対して,引用発明は,「同一の対象に関すると判別された第一のレコードに示される所定の項目のレコードと第二のレコードに示される所定の項目のレコードとを対応付け,入力された,第一のマスタで使用されるレコードを,第二のマスタで使用されるレコードに変換する」ものの,所定の項目の「コード」により対応付けをすることまでは記載されていない点。
[相違点3]
本願発明が,「重要度に応じて付けられている順位が上位である項目についての照合の結果ほど重みを付け,重みを付けた当該結果に基づいて同一の対象に関する第一のレコードおよび第二のレコードを判別する」のに対して,引用発明は,そのようなものではない点。

3.判断
ア[相違点1]について。
(ア)「同一項目判別手段」に関して,本願の明細書には,「同義語辞書テーブル記憶部1K3には,マスタファイルの種類ごとの同義語辞書テーブルTLDが記憶されている。同義語辞書テーブルTLDには,同一の項目(フィールド)を指していると考えられる様々な項目名を集めてグループ化したシソーラスである。例えば,「得意先マスタ」という種類のマスタファイルのための同義語辞書テーブルTLDとして,図6のような同義語辞書テーブルTLD1が同義語辞書テーブル記憶部1K3に記憶されている。」(段落【0039】)と記載され,図6には同義語辞書テーブルの例であって,「取引先名」のグループでは,取引先,得意先,顧客,お客様,ユーザ等々が同義語の辞書とされている。
つまり,本願発明の「同一項目判別手段」は,同義語辞書テーブルにより項目名が同一であるかを判別するものを含むものである。
(イ)一方,同義語辞書テーブルにより項目名が同一であるかを判断することは,周知の事項である。(以下「周知の事項A」という。)
例えば,引用例3記載事項によれば,引用例3には,「A署申請書の『提出者氏名』とB所申請書の『提出者名称』とが同義語であり,実体名称が『氏名』であることを示す同義語をまとめたテーブルにより,実体が同じか判断すること。」が記載されている。
(ウ)してみると,引用発明が,属性情報抽出手段12が保持する「各情報サーバに対応したデータファイルフォーマット解析ルーチン」により「同一の事項に関する,第一のレコードの項目および第二のレコードの項目を判別」する際,周知の事項Aを適用して同義語辞書テーブルにより項目名が同一であるかを判断するよう構成すること,つまり,「同一の事項に関する,第一のレコードの項目および第二のレコードの項目を判別」するための,「同一項目判別手段」を有するよう構成することは,当業者が容易に想到することができたものである。

イ[相違点2]について。
(ア)引用例2記載事項によれば,引用例2には,再掲すれば,「金融機関の顧客情報管理サーバが,金融機関の顧客情報ファイルから顧客の氏名,住所,電話番号,生年月日,職業,家族構成等の顧客の個人情報を抽出し,これを広告主のA商店会員番号に対応させて出力して広告主へ送付し,広告主は,受信した金融機関の個人情報により顧客マスタ情報を作成すようにするべく,広告主が付与したA商店会員番号である『000001』などのコードと,金融機関等が顧客に付与した金融機関顧客識別IDである『1234567890』などのコードとの対照である『契約顧客変換テーブル』を設けてコードを変換すること。」が記載されている。
(イ)引用例2の,金融機関の金融機関顧客識別IDのレコードの『1234567890』のコードと,A商店の会員番号のレコードの『000001』のコードとは,本願発明の,「第一のレコードに示される所定の項目のコード」と「第二のレコードに示される所定の項目のコード」とに対応し,『契約顧客変換テーブル』は,コード対応関係情報である「対応コード記憶手段」に対応する。
(ウ)ここで,引用発明は,「同一と判断された両データに,同一なデータであることを示す情報を付与するなどしてリンク付け」をするものであるから,引用発明に引用例2記載事項を適用することにより,「同一の対象に関すると判別された第一のレコードに示される所定の項目のコードと第二のレコードに示される所定の項目のコードとを対応付けて示すコード対応関係情報」を記憶する「対応コード記憶手段」を有するよう構成し,「入力された,第一のマスタで使用されるコードを,コード対応関係情報に基づいて,第二のマスタで使用されるコードに変換」する「コード変換手段」を有するよう構成することは,当業者が容易に想到することができたものである。

ウ[相違点3]について。
(ア)相違点3に係る事項に関して,発明の詳細な説明には,以下の記載がある。
(a)「【0043】また,1つの名寄せ条件テーブルTLNには基本条件と対象外文字列との組合せが複数示されることがあるが,上位(上の行)の組合せほど,2つのレコードが同一の対象物に関するか否かを判別する処理(後述する)の際に,重要な判断要件としてまたは優先的に適用される。」
(b)「【0072】または,名寄せ条件テーブルTLN1に定められている順位付けが上位の項目ほど,照合の結果が重要視されるようにしてもよい。この場合は,例えば,順位付けが上位の項目ほど,一致したときに高い点数が与えられるように(つまり,重み付けが大きくなるように),予め規則を決めておく。そして,ステップ#106の照合の実行によって得られた点数の合計が,所定の点数以上であれば,両レコードが同一の対象に関するものであると,判別する。」
(イ)図7の「名寄せテーブルTLN」をみると,「マスタ種別」と「基本条件」とに関して,以下の事例が記載されている。(なお,基本条件の丸数字は(1),(2)等の数字で代用する。)
・得意先仕入先マスタ:(1)「電話番号の後方一致」(2)「住所」の前方一致(3)「取引先名」の部分一致
・社員従業員マスタ:(1)「氏名」の部分一致(2)「ふりがな」の部分一致(3)「内線番号」の後方一致
・製品マスタ:(1)「品番」の全一致(2)「品名」の部分一致(3)「仕様」の部分一致
・部品マスタ:(1)「メーカ品番」の全一致(2)「メーカ名」の部分一致(3)「仕様」の部分一致
・部門組織マスタ:(1)「最下層部門名」の部分一致(2)「中層部門名」の部分一致(3)「最上位部門名」の部分一致
(ウ)上記(ア)(イ)の記載をみると,例えば「製品マスタ」や「部品マスタ」などは,「(1)「品番」の全一致」?「(2)「品名」の部分一致」?「(3)「仕様」の部分一致」の順で表記の揺らぎが少ないから,より上の行の組み合わせを優先することが合理的であると理解できる。
他方,「得意先仕入先マスタ」などは,「(1)「電話番号の後方一致」などの,より上の行の組み合わせを優先する理由は,必ずしも明確ではないものの,例えば電話番号の局番は桁数の変更があり,住所は住居表示の変更があるなどのことから,経時的な揺らぎがあっても名寄せの項目として優先することが合理的であることが理解できる。
(エ)このように,得意先や社員,製品,部品,部門を特定する項目には,時とともに移ろうものや表記の揺れがあることから,より移ろいにくいもの,より表記の揺れが少ないもので,得意先,社員,製品,部品,部門を特定しようすることが普通である(以下「周知の事項B」という。)。
例えば,引用発明によれば,引用例1には,「同一データでも時の経過とともに,名義などが微妙に変更される場合もありうる」ことなどから,「表記の揺れを考慮」すべきこと,「照合の対象となる項目を,例えば名義のみにすると,同一店の住所が変更しても,新旧のデータはマッチする」ことが記載されている。
また,部品であれば,メーカ品番が同じであれば,たとえメーカ名が簡略記載され仕様の表記が異なっていても同じ部品であると判断することなどが普通に行われている。
(オ)してみると,引用発明に,周知の事項Bを適用することにより,「重要度に応じて付けられている順位が上位である項目についての照合の結果ほど重みを付け,重みを付けた当該結果に基づいて同一の対象に関する第一のレコードおよび第二のレコードを判別する」よう構成することは,当業者が容易に想到することができたものである。

以上,ア?ウで判断したとおり,本願発明における上記[相違点1]?[相違点3]に係る発明特定事項は,当業者が容易に想到することができたものであり,想到することが困難な格別の事項は見いだせない。
また,本願発明の作用効果も,引用発明,引用例2記載事項及び周知の事項A,Bから当業者が予測できる範囲のものである。
したがって,本願発明は,引用発明,引用例2記載事項及び周知の事項A,Bに基づいて,当業者が容易に発明をすることができたものである。

4.むすび
以上のとおり,本願発明は引用発明,引用例2記載事項及び周知の事項A,Bに基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により特許を受けることができない。
したがって,本願はその余の請求項について論及するまでもなく,拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2014-01-08 
結審通知日 2014-01-14 
審決日 2014-01-28 
出願番号 特願2007-94062(P2007-94062)
審決分類 P 1 8・ 121- Z (G06Q)
最終処分 不成立  
前審関与審査官 大野 朋也  
特許庁審判長 清田 健一
特許庁審判官 須田 勝巳
石川 正二
発明の名称 コード変換システム、コード変換方法、コード対応関係情報生成方法、およびコンピュータプログラム  
代理人 久保 幸雄  

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