【事件の表示】
　特願２００７−５１１６８９「マルチ・ソース型の長期患者レベルのデータ暗号化処理」拒絶査定不服審判事件〔平成１７年１１月１７日国際公開、ＷＯ２００５／１０９２９４、平成１９年１２月１３日国内公表、特表２００７−５３６８３３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　
　本願は，２００５年５月５日（パリ条約による優先権主張外国庁受理　２００４年５月５日米国，他４件）を国際出願日とする出願であって，
　平成１８年１２月２８日付けで特許法第１８４条の４第１項の規定による明細書，図面（図面中の説明に限る），要約書の日本語による翻訳文が提出され，
　平成２０年４月２３日付けで審査請求がなされ，
　平成２３年２月２５日付けで審査官により拒絶理由が通知（同年３月８日発送）され，
　これに対して同年７月８日付けで意見書が提出されると共に手続補正がなされたが，
　同年９月１６日付けで拒絶査定（同年同月２７日謄本送達）がなされ，
　これに対して平成２４年１月２７日付けで審判請求がなされると共に手続補正がなされ，
　同年３月６日付けで審査官により特許法第１６４条第３項の規定に基づく報告（前置報告）がなされ，
　同年８月２９日付けで当審により上記報告を利用した特許法第１３４条第４項の規定に基づく審尋（同年９月４日発送）がなされ，
　これに対して同年１２月２８日付けで回答書が提出され，
　平成２５年９月１１日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年同月１７日発送）がなされ，
　これに対して同年１２月１７日付けで回答書が提出があったものである。
　
　
第２．平成２４年１月２７日付けの手続補正の却下の決定
　
［補正却下の決定の結論］
　
　平成２４年１月２７日付けの手続補正を却下する。
　
 ［理由］ 
　
（１）本件補正 
　 
　平成２４年１月２７日付けの手続補正（以下，「本件補正」という。）は，特許請求の範囲について，本件補正前に， 
　 
「【請求項１】
　個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法であって，
第１のコンポーネントで，
(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップと，
(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップと，
(c) 特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップと，
　前記LDF内に構成される第2のコンポーネントで，
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと，
(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を部分的に解読するステップと，
　前記LDF内に構成される第3のコンポーネントで，
(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップと，
(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップと，
を含む方法。
　　【請求項２】
　前記ステップ（ｅ）が，第3のLDF暗号鍵を用いて，前記属性を暗号化するステップを更に含む請求項1に記載の方法。
　　【請求項３】
　前記暗号化したデータ記録のデータ・フィールドを標準化したコンテンツ形式にするように，前記取得したデータ記録を処理するステップを更に含む請求項1に記載の方法。
　　【請求項４】
　前記データ記録において前記患者識別属性と前記非識別属性とを分離するステップを更に含み，前記ステップ(b)及び(c)が，前記分離した患者識別属性を暗号化するステップを更に含む請求項1に記載の方法。
　　【請求項５】
　前記データ記録において，前記暗号化した患者識別属性を，前記分離した非識別属性とマージするステップを更に含む請求項2に記載の方法。
　　【請求項６】
　前記ステップ(d)が，前記データ記録において，前記暗号化した患者識別属性と前記非識別属性とを分離するように，前記受信したデータ記録を処理するステップを更に含み，前記ステップ(e)が，前記分離した患者識別属性を部分的に解読するステップを更に含む請求項1に記載の方法。
　　【請求項７】
　前記ステップ(e)が，前記データ記録において，前記部分的に解読した患者識別属性を，前記分離した非識別属性とマージするステップを更に含む請求項6に記載の方法。
　　【請求項８】
　前記データ属性のマッチング・アルゴリズムが，データ属性の選択組に基づいて，前記暗号化したデータ記録に長期の患者識別子を割り当てる請求項1に記載の方法。
　　【請求項９】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項8に記載の方法。
　　【請求項１０】
　前記データ属性のマッチング・アルゴリズムが，長期の患者識別子及び対応するデータの属性の組を含む相互参照データベースを参照することにより，前記暗号化したデータ記録に長期の患者識別子を割り当てる請求項８に記載の方法。
　　【請求項１１】
　前記ステップ(d)及びステップ(e)が，前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で実行される請求項1に記載の方法。
　　【請求項１２】
　複数のデータ供給者から得られた個々の患者ヘルスケア・トランザクション・データ記録を，長期にリンクするシステムであって，
　患者識別属性と非識別属性を有するデータ記録を取得するように構成され，中央装置(LDF)に対して特定の第１の暗号鍵，及び，特定の第2の暗号鍵により，前記データ記録の前記患者識別属性を二重暗号化するように構成される第１のコンポーネントと，
　前記第１のコンポーネントから二重暗号化したデータ記録を受信するように構成され，前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による暗号化を保持するように，前記受信したデータ記録を部分的に解読するように構成され，暗号化の追加層を実行するように前記LDF内に構成される第2のコンポーネントと，
　前記暗号化したデータ記録において，属性をマッチングすることにより，前記暗号化したデータ記録に長期の患者識別子を割り当てるように構成され，長期のデータベースを形成するために，前記暗号化したデータ記録を長期の患者識別子毎にリンクするように前記LDF内に構成される前記第3のコンポーネントと，
を備えるシステム。
　　【請求項１３】
　前記第1のコンポーネントが，前記データ記録において，前記患者識別属性と前記非識別属性とを分離し，前記分離した患者識別属性を暗号化するように更に構成される請求項12に記載のシステム。
　　【請求項１４】
　前記第1のコンポーネントが，前記データ記録において，前記暗号化した患者識別属性を，前記非識別属性とマージするように更に構成される請求項13に記載のシステム。
　　【請求項１５】
　前記第1のコンポーネントが，前記暗号化したデータ記録のデータ・フィールドを標準書式にするように，前記取得したデータ記録を処理するように更に構成される請求項12に記載のシステム。
　　【請求項１６】
　前記第2のコンポーネントが，前記受信したデータ記録において，前記暗号化した患者識別属性と前記非識別属性とを分離し，前記分離した患者識別属性を部分的に解読するように更に構成される請求項12に記載のシステム。
　　【請求項１７】
　前記第2のコンポーネントが，前記データ記録において，前記部分的に解読した患者識別属性を，前記非識別属性とマージするように更に構成される請求項12に記載のシステム。
　　【請求項１８】
　前記第3のコンポーネントが，データ属性の選択組に基づいて，前記暗号化したデータ記録に長期の患者識別子を割り当てるように更に構成される請求項12に記載のシステム。
　　【請求項１９】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項18に記載のシステム。
　　【請求項２０】
　前記第3のコンポーネントが，長期の患者識別子，及び対応するデータの属性の組を含む相互参照データベースを参照することにより，前記暗号化したデータ記録に長期の患者識別子を割り当てるように更に構成される請求項18に記載のシステム。
　　【請求項２１】
　前記第2のコンポーネントが，前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で動作するように構成される請求項12に記載のシステム。
　　【請求項２２】
　システムの各機能が，ソフトウェア・アプリケーションを用いて実現される請求項12のシステム。
　　【請求項２３】
　個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースであって，
　マルチ・ソース型のデータ記録を格納し，
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために暗号化されおり，
　各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる長期リンク化データベース。
　　【請求項２４】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項23に記載の長期リンク化データベース。」（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）　　
とあったものを，
　　　
「【請求項１】
　個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法であって，
第１のコンポーネントで，
(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップと，
(b) 中央装置(LDF)に対して
長期用の
(c) 
ベンダー用の
　前記LDF内に構成される第2のコンポーネントで，
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと，
(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を
前記第2の暗号鍵と相補的な公開鍵を用いて
　前記LDF内に構成される第3のコンポーネントで，
(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップと，
(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップと，
を含む方法。
　　【請求項２】
　前記ステップ（ｅ）が，第3のLDF暗号鍵を用いて，前記属性を暗号化するステップを更に含む請求項1に記載の方法。
　　【請求項３】
　前記暗号化したデータ記録のデータ・フィールドを標準化したコンテンツ形式にするように，前記取得したデータ記録を処理するステップを更に含む請求項1に記載の方法。
　　【請求項４】
　前記データ記録において前記患者識別属性と前記非識別属性とを分離するステップを更に含み，前記ステップ(b)及び(c)が，前記分離した患者識別属性を暗号化するステップを更に含む請求項1に記載の方法。
　　【請求項５】
　前記データ記録において，前記暗号化した患者識別属性を，前記分離した非識別属性とマージするステップを更に含む請求項2に記載の方法。
　　【請求項６】
　前記ステップ(d)が，前記データ記録において，前記暗号化した患者識別属性と前記非識別属性とを分離するように，前記受信したデータ記録を処理するステップを更に含み，前記ステップ(e)が，前記分離した患者識別属性を部分的に解読するステップを更に含む請求項1に記載の方法。
　　【請求項７】
　前記ステップ(e)が，前記データ記録において，前記部分的に解読した患者識別属性を，前記分離した非識別属性とマージするステップを更に含む請求項6に記載の方法。
　　【請求項８】
　前記データ属性のマッチング・アルゴリズムが，データ属性の選択組に基づいて，前記暗号化したデータ記録に長期の患者識別子を割り当てる請求項1に記載の方法。
　　【請求項９】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項8に記載の方法。
　　【請求項１０】
　前記データ属性のマッチング・アルゴリズムが，長期の患者識別子及び対応するデータの属性の組を含む相互参照データベースを参照することにより，前記暗号化したデータ記録に長期の患者識別子を割り当てる請求項８に記載の方法。
　　【請求項１１】
　前記ステップ(d)及びステップ(e)が，前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で実行される請求項1に記載の方法。
　　【請求項１２】
　複数のデータ供給者から得られた個々の患者ヘルスケア・トランザクション・データ記録を，長期にリンクするシステムであって，
　患者識別属性と非識別属性を有するデータ記録を取得するように構成され，中央装置(LDF)に対して
長期用の
ベンダー用の
　前記第１のコンポーネントから二重暗号化したデータ記録を受信するように構成され，前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による暗号化を保持するように，前記受信したデータ記録を
前記第2の暗号鍵と相補的な公開鍵を用いて
　前記暗号化したデータ記録において，属性をマッチングすることにより，前記暗号化したデータ記録に長期の患者識別子を割り当てるように構成され，長期のデータベースを形成するために，前記暗号化したデータ記録を長期の患者識別子毎にリンクするように前記LDF内に構成される前記第3のコンポーネントと，
を備えるシステム。
　　【請求項１３】
　前記第1のコンポーネントが，前記データ記録において，前記患者識別属性と前記非識別属性とを分離し，前記分離した患者識別属性を暗号化するように更に構成される請求項12に記載のシステム。
　　【請求項１４】
　前記第1のコンポーネントが，前記データ記録において，前記暗号化した患者識別属性を，前記非識別属性とマージするように更に構成される請求項13に記載のシステム。
　　【請求項１５】
　前記第1のコンポーネントが，前記暗号化したデータ記録のデータ・フィールドを標準書式にするように，前記取得したデータ記録を処理するように更に構成される請求項12に記載のシステム。
　　【請求項１６】
　前記第2のコンポーネントが，前記受信したデータ記録において，前記暗号化した患者識別属性と前記非識別属性とを分離し，前記分離した患者識別属性を部分的に解読するように更に構成される請求項12に記載のシステム。
　　【請求項１７】
　前記第2のコンポーネントが，前記データ記録において，前記部分的に解読した患者識別属性を，前記非識別属性とマージするように更に構成される請求項12に記載のシステム。
　　【請求項１８】
　前記第3のコンポーネントが，データ属性の選択組に基づいて，前記暗号化したデータ記録に長期の患者識別子を割り当てるように更に構成される請求項12に記載のシステム。
　　【請求項１９】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項18に記載のシステム。
　　【請求項２０】
　前記第3のコンポーネントが，長期の患者識別子，及び対応するデータの属性の組を含む相互参照データベースを参照することにより，前記暗号化したデータ記録に長期の患者識別子を割り当てるように更に構成される請求項18に記載のシステム。
　　【請求項２１】
　前記第2のコンポーネントが，前記データ記録の患者識別属性情報に対する不正アクセスを制限する安全な環境で動作するように構成される請求項12に記載のシステム。
　　【請求項２２】
　システムの各機能が，ソフトウェア・アプリケーションを用いて実現される請求項12のシステム。
　　【請求項２３】
　個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベース
を格納する記憶装置
　
前記長期リンク化データベースは，
有
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために
長期用の特定の第１の暗号鍵により
て
　各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる
記憶装置
　　【請求項２４】
　前記データ属性の選択組が，患者の生年月日，カードホルダ識別，記録番号，郵便番号，名，姓，住所，及び業界標準の患者識別子のうち少なくとも1つを含む請求項23に記載の
記憶装置
と補正しようとするものである。 
　　　
（２）本件補正における補正の目的についての判断
　
　以下に，本件補正における特許請求の範囲についてする補正の目的について検討する。　
ア．補正後の請求項１の補正に係る，補正前の請求項１の「(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップ」を，「(b) 中央装置(LDF)に対して長期用の特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップ」とし，補正前の請求項１の「(c) 特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップ」を，「(c) ベンダー用の特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップ」とし，補正前の請求項１の「(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を部分的に解読するステップ」を，「(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な公開鍵を用いて部分的に解読するステップ」とする補正は，
　それぞれ「特定の第１の暗号鍵」，「特定の第2の暗号鍵」，「部分的に解読するステップ」を限定するもので，特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものある。
　
イ．補正後の請求項１２の補正に係る，補正前の請求項１２の「患者識別属性と非識別属性を有するデータ記録を取得するように構成され，中央装置(LDF)に対して特定の第１の暗号鍵，及び，特定の第2の暗号鍵により，前記データ記録の前記患者識別属性を二重暗号化するように構成される第１のコンポーネント」を，「患者識別属性と非識別属性を有するデータ記録を取得するように構成され，中央装置(LDF)に対して長期用の特定の第１の暗号鍵，及び，ベンダー用の特定の第2の暗号鍵により，前記データ記録の前記患者識別属性を二重暗号化するように構成される第１のコンポーネント」とし，補正前の請求項１２の「前記第１のコンポーネントから二重暗号化したデータ記録を受信するように構成され，前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による暗号化を保持するように，前記受信したデータ記録を部分的に解読するように構成され，暗号化の追加層を実行するように前記LDF内に構成される第2のコンポーネント」を，「前記第１のコンポーネントから二重暗号化したデータ記録を受信するように構成され，前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による暗号化を保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な公開鍵を用いて部分的に解読するように構成され，暗号化の追加層を実行するように前記LDF内に構成される第2のコンポーネント」とする補正は，
　それぞれ「特定の第１の暗号鍵」，「特定の第2の暗号鍵」，「部分的に解読する」を限定するもので，特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものある。
　
ウ．補正後の請求項２３の補正に係る，補正前の請求項２３の「個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベース」を，「個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースを格納する記憶装置」とし，補正前の請求項２３の「マルチ・ソース型のデータ記録を格納し」を，「前記長期リンク化データベースは，マルチ・ソース型のデータ記録を有し」とし，補正前の請求項２３の「各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる長期リンク化データベース」を，「各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる記憶装置」とし，
　また，補正後の請求項２４の補正に係る，補正前の請求項２４の「請求項23に記載の長期リンク化データベース」を，「請求項23に記載の記憶装置」とする補正は，
　平成２３年９月１６日付けの拒絶査定における，
「請求項２３，２４における「データベース」は，データを意味するものであって，物の発明であるとは認められず，依然として，請求項２３，２４に係る発明は，「物の発明」か「方法の発明」かが特定できず，発明の内容が不明確です。」
　との指摘を受けて行うもので，特許法第１７条の２第４項第４号の明りょうでない記載の釈明を目的とするものであるとともに，
　補正前の請求項２３の「前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために暗号化されおり」を，「前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために長期用の特定の第１の暗号鍵により暗号化されており」とする補正は，「暗号化され（て）おり」を限定することを含むもので，特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものを含むものである。
　
　よって，本件補正は，特許請求の範囲の減縮及び明りょうでない記載の釈明を目的とするものであり，平成１８年法律第５５号改正附則第３条第１項の規定によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に適合する。
　
　そこで，本件補正後の請求項に記載された発明が，特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）否かを，以下に検討する。
　
（３）請求項１に係る発明の独立特許要件についての検討
　
（３−１）請求項１に係る発明
　まず，本願の請求項１に係る発明の独立特許要件について，以下に検討する。
　本願の請求項１に係る発明は，上記「（１）」において，補正後の請求項１として引用した，次のものである（以下，「本願補正発明１」という。）。
　
「個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法であって，
第１のコンポーネントで，
(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップと，
(b) 中央装置(LDF)に対して長期用の特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップと，
(c) ベンダー用の特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップと，
　前記LDF内に構成される第2のコンポーネントで，
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと，
(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な公開鍵を用いて部分的に解読するステップと，
　前記LDF内に構成される第3のコンポーネントで，
(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップと，
(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップと，
を含む方法。」
　
（３−２）引用文献等
　１）引用文献１に記載されている技術的事項及び引用発明の認定 
　本願の第１国出願前に頒布され，原査定の拒絶の理由に引用された，特開２００３−１７３３７６号公報（平成１５年６月２０日出願公開，以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。） 
　
　Ａ「【０００１】
【発明の属する技術分野】
本発明は，
例えば，端末装置から送信される患者の病症に関するデータを収集・蓄積
する，データ集中収集管理システム
に関するものである。
【０００２】
【従来の技術】現在，例えばアルツハイマー症，パーキンソン病，ＣＯＰＤ（慢性閉塞性肺疾患）など，明確な治療方法や治療薬が研究段階にあって未だ発見されておらず，試験的に薬物投与が試みるか，あるいは生活環境の改善が有効な対策とされている病症が多数存在する。
このような病症について，その進行を阻止する治療方法を確立するためには，まず，現在さしあたって行われている種々の治療と，この治療により得られた患者の症状とから成るサンプルを広く収集し，これらを分析し，それぞれの治療による効果を明らかにしていくことが必要である。そして，その分析結果を医療機関（病院等）や患者（潜在的な患者も含む）等に広く提供し，フィードバックしていくことにより，効果の認められる治療方法を徐々に明らかにしていくことが必要であるとされている
　
　Ｂ「【００１３】２．
データ集中収集管理システムによる処理動作の概要
ＰＣ５０側に対し患者の病症に関する計測データ等の原データが入力されることとなる。このため，ＰＣ５０側のステップＳ１０１においては，この原データが入力されることとなる。そして，ＰＣ５０側は，入力された原データに基づき，ステップＳ１０２において分析用送信データと原データ（分析用送信データ）のプロパティを示すプロパティデータを生成する。続くステップＳ１０３においては，分析用送信データ及びプロパティデータ内のプライバシー保護を要する部分についてのみ独自鍵によって暗号化を施し
そして，ステップＳ１０５においては，分析用送信データ，及びプロパティデータを暗号化鍵，つまりサーバ装置１側と共有している鍵で暗号化し，これらをサーバ装置１に対して送信する。
このステップＳ１０５における暗号化方式としては，秘密鍵方式あるいは暗号鍵管理の容易な公開鍵方式を採用することが可能である。本実施の形態の場合，この暗号化方式を，例えば市販製品であるＳＳＬ（Secure Sockets Layer）を組み込むことで実現する。このＳＳＬによっては，ＰＣ５０側においてはサーバ装置１側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われるようになり，サーバ装置１側においてはこのように暗号化されたデータについて秘密鍵による復号化が行われるようになるものである。
【００１４】
続いて，サーバ装置１側の処理としては，
データの適合性を判断する。そして，適合性があると判断した場合は，ステップＳ２０２に進み，プロパティデータに加えて分析用送信データを受信し，これを暗号化鍵を用いて復号化する。
続くステップＳ２０４においてこれら分析用送信データ（数値化された計測データも含む）とプロパティデータを蓄積する。
　
　Ｃ「【００２２】４．サーバ装置の構成
サーバ装置１内部における要部の構成を図４に示す。図示するように，サーバ装置１には通信部２，エンコード／デコード部３，データベース４，分析部５，課金処理部６，コントローラ１０，ＲＯＭ１１，及びＲＡＭ１２が形成されている。なお，図示はしていないが，この他にも，サーバ装置１側のオペレータの行う各種設定や調整などの必要な操作のためのインターフェース部位としての操作部や表示部等が形成されるのは言うまでもない。
　・・・（中略）・・・
【００２６】
データベース４は，例えばハードディスクドライブ等の記憶装置内に構築され，
プロパティデータ及び分析用送信データを記憶する。そして，このように通信部２で受信された分析用送信データを随時記憶していくことで，このデータベース４にデータが蓄積される
　
　Ｄ「【００２９】５．端末装置による処理動作
図５にＰＣ５０のＣＰＵ５２による処理動作を示す。まず，ＰＣ５０側においては，ステップＳ３０１で，ユーザによる原データの入力がなされる。
この原データは，主に患者のプロフィールに関するプロフィールデータ，及び患者に施した治療に関するデータとしての治療データ，計測により得られた患者の病症レベルを表す計測データとによって構成される。
【００３０】
この原データとして，まず，プロフィールデータついては，
この他にも，
血糖値（糖尿病患者にはアルツハイマー症が少ないといわれる），喫煙経験（喫煙者アルツハイマー症が非喫煙者より相対的に少ないとの報告がある）などのデータが採用されてもよい。
【００３１】
治療データとしては，
食事療法に関するデータ，
運動の両種に関するデータ，睡眠（時間等）に関するデータなどが挙げられる。
【００３２】また，計測データとしては，患者に対する問診により医師が判定した病症レベルの数値が採用される。問診による病症レベルの判定としては，患者の自覚症状を調査することによって判定された病症レベル，及び，例えばアルツハイマー症の病症レベル判定に採用される代表的な方式である「ＭＭＳＥ」（Mini-MentalState Examination：「簡易心理機能検査」30点満点で採点を行い，年齢や教育にも依存するが，24点以上を正常，9点以下を重症と判定する）とよばれる質問方式の認知機能検査の結果，及び，「ＡＤＡＳ−Ｃｏｇ」（Alzheimer's Disease Assesment Scale-Cognitive Subscale：１１部門からなるテストで，ＭＭＳＥよりカバー度が高く，特に言語機能や記憶能力をみるのに適する）等の判定結果が採用される。」
　
　Ｅ「【００３７】説明を図５に戻す。図５のステップＳ３０１において，上述したような原データが入力されると，ＰＣ５０のＣＰＵ５２はステップＳ３０２に進み，入力された原データに基づき，図７に示すように構成される分析用送信データと，図８に示すように構成されるプロパティデータとを生成する。
分析用送信データとは，サーバ装置１へ送信され，図４で説明した分析部５における分析の対象となるデータであり，上記した原データを元として生成されるデータである。
【００３８】また，プロパティデータは，原データのプロパティに関する部分のみを示すデータであり，例えば，ＸＭＬ（Extensible Markup Language）の言語等により表現されるものである。具体的には，図８に示すように病院等のＩＤ（識別子／識別コード），患者氏名，性別，生年月日，患者管理用ＩＤ（以下患者ＩＤ），原データ採取時刻（年月日時分まで），ファイルサイズに関する情報，履歴に関するデータ（新規／修正の履歴を示すデータ）等の内容を有するものが主な項目となる。また，このプロパティデータには，図示するようにプロパティデータのファイルＩＤも書き込まれる。このファイルＩＤは，このステップＳ３０２においてプロパティデータを生成する毎に，カウントアップされていく値であり，これを随時，生成するプロパティデータに書き込んでいくようにすることで，ＣＰＵ５２は生成したプロパティデータを管理することが可能となるようにされている。
【００３９】これらそれぞれの項目のデータは，ステップＳ３０１における原データの入力，及びその内容に応じて書き込まれるようになっている。そして，このようにプロパティデータが原データに応じた内容とされることで，分析用送信データとプロパティデータとが対応づけられることとなり，この結果，分析用送信データとプロパティデータとの間の同一性が確保されることとなる。
【００４０】続く
ステップＳ３０３では，サーバ装置１に送信する分析用送信データのプロフィールデータに相当する部分と，プロパティデータとに含まれる個人情報に関するデータ部分に暗号化を施すための処理を実行する
予めＰＣ５０において設定した独自鍵を用い，プロフィールデータ部分とプロパティデータとに含まれる個人情報データ部分に暗号化を施す
　
　Ｆ「【００５０】６．端末装置における個人情報の秘匿方式
本実施の形態としてのＰＣ５０における，暗号化による個人情報の秘匿方式の例を図９に示す。この図において，秘匿する個人情報として，患者の氏名が例示されている。例えば，患者の所属する病院が「Ａ病院」，患者氏名が「山田花子」であるとすると，図５のステップＳ３０３の処理によって，図示するように分析用送信データ及びプロパティデータに含まれる患者氏名の項目のデータは，例えば「Ｘ７８２ａｌｐ５」と暗号化されることとなる。この際，図示するように分析用送信データ，及びプロパティデータの他の部分についてはそのままの状態とされる。
これら「Ａ病院」の独自鍵によって暗号化された分析用送信データ，及びプロパティデータは，先に説明した図６のステップＳ３１０において，さらにサーバ装置１との暗号化鍵によって暗号化が行われたのち，サーバ装置１に送信される。
【００５１】
サーバ装置１においては，分析用送信データ及びプロパティデータが受信された際，ＰＣ５０との間の暗号化鍵でのみ暗号化された部分については復号化されるのであるが，ステップＳ３０３において独自鍵で暗号化された部分については暗号化されたままの状態でしか認識されないこととなる。
【００５２】一方，例えば「Ａ病院」においてサーバ装置１から分析結果等の提供を受ける際には，「Ａ病院」に関するデータのみについては暗号化の施されたデータを独自鍵によって復号化することが可能となるため，例えば図示するようにｗｅｂ等を介して分析結果を閲覧する際には「山田花子」と患者氏名を復号化することが可能となる。
【００５３】しかしながら，他の病院，例えばこれを「Ｂ病院」とすると，この「Ｂ病院」においても「Ａ病院」と同様，自病院の分析用送信データに関しては独自鍵でのみしか復号化することができないようにされている。このため，例えば「Ａ病院」において，「Ｂ病院」についてのデータを閲覧しようとする際には，「Ｂ病院」の患者氏名の欄は例えば「Ｑ７３３Ｐｄｅｚ」と暗号化されたままの状態での表示となる。」　
　
　以下に，上記引用文献１の記載事項について検討する。
　
　ア．上記Ａの「本発明は，・・・例えば，端末装置から送信される患者の病症に関するデータを収集・蓄積・・・する，データ集中収集管理システム・・・に関するものである。」との記載から，引用文献１は，
“端末装置から送信される患者の病症に関するデータを収集・蓄積するデータ集中収集管理システム”について説明するものである。
　
　イ．上記Ｂの「本実施の形態のデータ集中収集管理システムの処理動作の概要・・・ＰＣ５０側に対し患者の病症に関する計測データ等の原データが入力されることとなる。このため，ＰＣ５０側のステップＳ１０１においては，この原データが入力されることとなる。そして，ＰＣ５０側は，入力された原データに基づき，ステップＳ１０２において分析用送信データと原データ（分析用送信データ）のプロパティを示すプロパティデータを生成する。続くステップＳ１０３においては，分析用送信データ及びプロパティデータ内のプライバシー保護を要する部分についてのみ独自鍵によって暗号化を施し・・・そして，ステップＳ１０５においては，分析用送信データ，及びプロパティデータを暗号化鍵，つまりサーバ装置１側と共有している鍵で暗号化し，これらをサーバ装置１に対して送信する。・・・続いて，サーバ装置１側の処理としては，・・・データの適合性を判断する。そして，適合性があると判断した場合は，ステップＳ２０２に進み，プロパティデータに加えて分析用送信データを受信し，これを暗号化鍵を用いて復号化する。・・・続くステップＳ２０４においてこれら分析用送信データ（数値化された計測データも含む）とプロパティデータを蓄積する。」との記載から，引用文献１には，
“データ集中収集管理システムにおける処理方法であって，
　ＰＣ側で，患者の病症に関する計測データ等の原データが入力され，
　入力された原データに基づき，分析用送信データと原データである分析用送信データのプロパティを示すプロパティデータが生成され，
　分析用送信データ及びプロパティデータ内のプライバシー保護を要する部分についてのみ独自鍵によって暗号化を施し，
　分析用送信データ，及びプロパティデータをサーバ装置側と共有している暗号化鍵で暗号化し，
　これらをサーバ装置に対して送信し，
　サーバ装置側で，データの適合性を判断し，
　適合性があると判断した場合は，プロパティデータに加えて分析用送信データを受信し，
　これを暗号化鍵を用いて復号化し，
　分析用送信データとプロパティデータを蓄積する，方法”が記載されているといえる。
　
　ウ．上記Ｃの「データベース４は，例えばハードディスクドライブ等の記憶装置内に構築され，・・・プロパティデータ及び分析用送信データを記憶する。そして，このように通信部２で受信された分析用送信データを随時記憶していくことで，このデータベース４にデータが蓄積される」との記載から，
　上記“分析用送信データとプロパティデータを蓄積する”のは，“記憶装置内のデータベースに”対して行うものであることが読み取れる。
　
　エ．上記“分析用送信データ”に関し，上記Ｅの「分析用送信データとは，サーバ装置１へ送信され，図４で説明した分析部５における分析の対象となるデータであり，上記した原データを元として生成されるデータである。」との記載，上記Ｄの「この原データは，主に患者のプロフィールに関するプロフィールデータ，及び患者に施した治療に関するデータとしての治療データ，計測により得られた患者の病症レベルを表す計測データとによって構成される。」との記載，及び図面第７図に示された態様から，
　上記“入力された原データに基づき”“生成され”る“分析用送信データ”は，“プロフィールデータ，治療データ，計測データを含む”ものであることが読み取れる。
　
　オ．上記“分析用送信データ及びプロパティデータ内のプライバシー保護を要する部分についてのみ独自鍵によって暗号化を施し”に関し，上記Ｅの「ステップＳ３０３では，サーバ装置１に送信する分析用送信データのプロフィールデータに相当する部分と，プロパティデータとに含まれる個人情報に関するデータ部分に暗号化を施すための処理を実行する」，「予めＰＣ５０において設定した独自鍵を用い，プロフィールデータ部分とプロパティデータとに含まれる個人情報データ部分に暗号化を施す」との記載，及び図面第７図に「プロフィールデータ」として「性別，年齢，住所」等のデータが含まれるように示された態様から，
　上記“分析用送信データ及びプロパティデータ内のプライバシー保護を要する部分についてのみ独自鍵によって暗号化を施”すとは，“分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施”すことであることが読み取れる。
　
　カ．上記“サーバ装置側と共有している暗号化鍵で暗号化し”に関し，上記Ｂの「このステップＳ１０５における暗号化方式としては，秘密鍵方式あるいは暗号鍵管理の容易な公開鍵方式を採用することが可能である。本実施の形態の場合，この暗号化方式を，例えば市販製品であるＳＳＬ（Secure Sockets Layer）を組み込むことで実現する。このＳＳＬによっては，ＰＣ５０側においてはサーバ装置１側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われるようになり，サーバ装置１側においてはこのように暗号化されたデータについて秘密鍵による復号化が行われるようになるものである。」との記載から，
　上記“サーバ装置側と共有している暗号化鍵による暗号化は，サーバ装置側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われ，サーバ装置側における当該暗号化されたデータの復号化は，秘密鍵により行われる，秘密鍵方式であ”ることが読み取れる。
　
　キ．上記“サーバ装置側”での“暗号化鍵を用いて復号化”することに関し，上記Ｆの「これら「Ａ病院」の独自鍵によって暗号化された分析用送信データ，及びプロパティデータは，先に説明した図６のステップＳ３１０において，さらにサーバ装置１との暗号化鍵によって暗号化が行われたのち，サーバ装置１に送信される。」，「サーバ装置１においては，分析用送信データ及びプロパティデータが受信された際，ＰＣ５０との間の暗号化鍵でのみ暗号化された部分については復号化されるのであるが，ステップＳ３０３において独自鍵で暗号化された部分については暗号化されたままの状態でしか認識されないこととなる。」との記載から，
　上記“サーバ装置側での暗号化鍵を用いた復号化は，独自鍵で暗号化された部分については暗号化されたままの状態とするものである”ことが読み取れる。
　
　以上，ア．〜キ．で指摘した事項から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
　端末装置から送信される患者の病症に関するデータを収集・蓄積するデータ集中収集管理システムにおける処理方法であって，
　ＰＣ側で，患者の病症に関する計測データ等の原データが入力され，
　入力された原データに基づき，プロフィールデータ，治療データ，計測データを含む分析用送信データと，原データである分析用送信データのプロパティを示すプロパティデータが生成され，
　分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施し，
　分析用送信データ，及びプロパティデータをサーバ装置側と共有している暗号化鍵で暗号化し，
　これらをサーバ装置に対して送信し，
　サーバ装置側で，データの適合性を判断し，
　適合性があると判断した場合は，プロパティデータに加えて分析用送信データを受信し，
　これを暗号化鍵を用いて復号化し，
　分析用送信データとプロパティデータを記憶装置内のデータベースに蓄積するものであり，
　前記サーバ装置側と共有している暗号化鍵による暗号化は，サーバ装置側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われ，サーバ装置側における当該暗号化されたデータの復号化は，秘密鍵により行われる，秘密鍵方式であり，
　サーバ装置側での暗号化鍵を用いた復号化は，独自鍵で暗号化された部分については暗号化されたままの状態とするものである，方法。
　
２）引用文献２に記載されている事項　
　本願の第１国出願前に頒布され，原査定の拒絶の理由に引用された，特開２０００−３２４０９４号公報（平成１２年１１月２４日出願公開，以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。） 
　
　Ｇ「【０００９】図１は，本発明の原理を利用できる例示的な情報ネットワークのハイレベルデータフロー図１１０である。この例においては，データプロバイダ１１２はデータベース１１４を所有または制御する。データベース１１４は，例えば，複数のデータレコードとして組織されている。各レコードは，１以上のデータフィールドを含む。各人のデータは単一レコードとして保持され，または複数のレコードにわたってリンクされている。各レコードのフィールドまたはフィールドの部分は，
個人を識別するのに利用可能なデータ，すなわち個人識別可能属性
属性は，例えば，「名前」，「住所」および「社会保障番号」を含む
【００１０】情報の識別に加えて，
データベースは個人についての他の情報
医療情報
を含む
・・・・
【００１４】
一意の識別子を取り出しまたは生成すると
もとのデータベースのレコードを含む新たなデータベース１２０を生成する。
　
　Ｈ「【００４５】
一意の識別子の割り当て本プロセス
【００４６】
入力されたファイルからのレコードの各々
評価され，それによりデータにより表されるもの（entity）が決定一致技術および確率一致技術を組み合わせて用いて前に識別されているかを判断する
入力されたレコードには，一致した参照レコードから一意の識別子
が割り当てられる。
【００４７】ＵＩＤ割り当てが起こると，入力されたレコードはその全体において評価され，それによりそのレコードが参照テーブルにいまだ含まれないものを一意に表現するかが判断される。新たなレコードである場合には，将来的な使用のために，そのレコードは参照データベース１１５に挿入される。
【００４８】決定一致技術
例示的な決定一致技術は単にブール論理を利用するものであり，データが標準化された後に適用される。２つのレコードが，ある基準を満たしているかに適合するかがか判断される。例えば，以下のようになる。
【００４９】
ファーストネーム
【００５０】２つのレコードが決定一致法の基準を満足する場合には，確率的処理は行わない。しかし，決定一致が生じない場合には，入力されたレコードは，確率一致法に付される。
【００５１】確率一致技術
確率一致プロセスの第１ステップは，入力されたレコードの固有の要素の特徴に基づいて，参照テーブルから広報（当審注：「候補」の誤記と解される。）レコードセットを構築することである。このプロセスはブロッキングと呼ばれ，候補レコードはブロッキングテーブルと呼ばれる。全てのデータセットに同一の文字を用いることはなく，本プロセスで用いられる要素はデータ解析を経て決定される。しかしながら
ブロッキング変数は
社会保障番号，または誕生日およびラストネームの組み合わせである。
【００５２】ブロッキングテーブルの構築が完成すると，各候補レコードの各要素は，入力されたレコードからの対応する要素と比較される。計算手順についての式（１２）を参照されたい。
【００５３】そして式（１３）に示すように，全ての候補レコードについて複合重みが計算される。
【００５４】その後，最も高い複合重みがかかった候補レコードがあらかじめ定められた閾値に対して評価される。重みが閾値に一致するまたは超えると，候補レコードは入力されたレコードに適合すると判断される。重みが閾値を超えない場合は，入力されたレコードは，いまだ参照セットに含まれていないものを表すと想定される。
【００５５】例示的な一致技術は，不一致の２つのフィールドが同一のデータを表すかを決定しようとする技術ではない。例えば，書き換えエラーのために社会保障番号１２３４５６７８９が１２３４５６７９８と記録されているとすると，上で説明した
アルゴリズム
　
（３−３）本願補正発明１と引用発明との対比 
　本願補正発明１と引用発明とを対比する。
　
　あ．引用発明である「データ集中収集管理システムにおける処理方法」は，「端末装置から送信される患者の病症に関するデータ」を「収集・蓄積」するものであり，その結果「データ」を「データベース」に蓄積するものであるところ，これは「データベース」を生成するものであるといえ，また「患者の病症に関するデータ」を収集・蓄積するための入力データである「患者の病症に関する計測データ等の原データ」は，上記Ｃの段落【００２４】に記載があるように，データ集中収集管理システムにおいてメモリ上に記憶されて処理されるものであるから，データ記録に他ならない。
　してみると，引用発明の「端末装置から送信される患者の病症に関するデータを収集・蓄積するデータ集中収集管理システムにおける処理方法」と，本願補正発明１の「個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法」とは，ともに，“個々の患者のデータ記録からデータベースを生成する方法”である点で共通する。
　
　い．引用発明の「プロフィールデータ，治療データ，計測データを含む分析用送信データ」における「プロフィールデータ」とは，「性別，年齢，住所等」のデータを含むものであるところ，これらのデータは患者を識別しうるデータであるから患者識別属性に対応するといえ，それ以外のデータのうち例えば「治療データ」等は患者を直接識別しうるデータではないから非患者識別属性に対応するといえる。
　してみると，引用発明の「ＰＣ側」で，「患者の病症に関する計測データ等の原データが入力され，入力された原データに基づき，プロフィールデータ，治療データ，計測データを含む分析用送信データと，原データである分析用送信データのプロパティを示すプロパティデータが生成され」ることは，本願補正発明１の「第１のコンポーネント」で，「(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップ」に相当するといえる。
　
　う．引用発明の「独自鍵」による「暗号化」は，「分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分」に対して行われるところ，上記い．の検討結果を踏まえると，前記「性別，年齢，住所等」のデータとは患者を識別しうるデータであり患者識別属性に対応するものである。
　してみると，引用発明の「ＰＣ側」で，「分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施」すことと，本願補正発明１の「第１のコンポーネント」で，「(b) 中央装置(LDF)に対して長期用の特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップ」とは，後記の点（相違点２）で相違するものの，“第１のコンポーネント”で，“(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップ”である点で共通する。
　
　え．引用発明の「サーバ装置側と共有している暗号化鍵」による「暗号化」は，「分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施し」たものに対して行われるものであり，上記う．の検討結果から患者識別属性に対応するデータに対して行われるものである。
　してみると，引用発明の「ＰＣ側」で，「分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施し」た後に「分析用送信データ，及びプロパティデータをサーバ装置側と共有している暗号化鍵で暗号化」することと，本願補正発明１の「第１のコンポーネント」で，「(c) ベンダー用の特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップ」とは，後記の点（相違点２）及び（相違点３）で相違するものの，“第１のコンポーネント”で，“(c) 特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップ”である点で共通する。
　
　お．引用発明の「サーバ装置側」で，「プロパティデータに加えて分析用送信データを受信」することと，本願補正発明１の「LDF内に構成される第2のコンポーネント」で，「(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップ」とは，後記の点（相違点２）及び（相違点３）で相違するものの，“LDF内に構成される第2のコンポーネント”で，“(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップ”である点で共通する。
　
　か．引用発明における「サーバ装置側と共有している暗号化鍵による暗号化は，サーバ装置側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われ，サーバ装置側における当該暗号化されたデータの復号化は，秘密鍵により行われる，秘密鍵方式であ」ることとは，「ＰＣ側」にて「暗号化」するための「公開鍵とこれに基づいて生成する秘密鍵」と，「サーバ装置側」にて「復号化」するための「秘密鍵」とが互いに補うよう対になっていることを指しており，これは相補的な関係であることに他ならない。
　してみると，引用発明の「サーバ装置側」で，「暗号化鍵を用いて復号化」することであり，「前記サーバ装置側と共有している暗号化鍵による暗号化は，サーバ装置側から送信されてくる公開鍵とこれに基づいて生成する秘密鍵とを用いてデータの暗号化が行われ，サーバ装置側における当該暗号化されたデータの復号化は，秘密鍵により行われる，秘密鍵方式であり，サーバ装置側での暗号化鍵を用いた復号化は，独自鍵で暗号化された部分については暗号化されたままの状態とするものである」ことと，本願補正発明１の「LDF内に構成される第2のコンポーネント」で，「(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な公開鍵を用いて部分的に解読するステップ」とは，後記の点（相違点２）及び（相違点３）で相違するものの，“LDF内に構成される第2のコンポーネント”で，“(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な鍵を用いて部分的に解読するステップ”である点で共通する。
　
　き．上記あ．の検討結果から，引用発明の「サーバ装置側」で，「分析用送信データとプロパティデータをデータベースに蓄積する」ことと，本願補正発明１の「LDF内に構成される第3のコンポーネント」で，「(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップ」とは，後記の点（相違点２）及び（相違点４）で相違するものの，“LDF内”で，“(g) データベースを生成するステップ”である点で共通する。
　
　以上から，本願補正発明１と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　個々の患者のデータ記録からデータベースを生成する方法であって，
第１のコンポーネントで，
(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップと，
(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップと，
(c) 特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップと，
　前記LDF内に構成される第2のコンポーネントで，
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと，
(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を前記第2の暗号鍵と相補的な公開鍵を用いて部分的に解読するステップと，
　前記LDF内で，
(g) データベースを生成するステップと，
を含む方法。　
　
（相違点１）　
　個々の患者のデータ記録に関し，本願補正発明１が「ヘルスケア」・「トランザクション」・データ記録であるのに対し，引用発明は，「原データ」が「ヘルスケア」に関する「トランザクション」データであるとは明示されていない点。
　
（相違点２）　
　本願補正発明１が，「長期リンク化データベース」を「形成」することで「アセンブリ」するものであり，また，データ記録の患者識別属性の暗号化のための特定の第１の暗号鍵が「長期用」であるのに対し，引用発明は，データを蓄積することで「データベース」を生成するものであり，また，分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分の暗号化を「独自鍵」によって行っているところ，「データベース」について「長期リンク化」に係るものであることや，「独自鍵」について「長期用」であるとの特定はない点。
　
（相違点３）　
　本願補正発明１が，「(c)」ステップでの暗号化のための特定の第2の暗号鍵として「ベンダー用」のものを用い，「(e)」ステップでの復号化のための前記第2の暗号鍵と相補的な鍵として「公開鍵」を用いているのに対し，引用発明は，暗号化のためのサーバ装置側と共有している暗号化鍵と，復号化のための秘密鍵について，それぞれ「ベンダー用」，「公開鍵」との特定はない点。
　
（相違点４）　
　本願補正発明１が，「(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップ」と「(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップ」とを，「LDF内に構成される第3のコンポーネント」で行っているのに対し，引用発明は，そのような構成になっていない点。
　
（３−４）判断 
　上記相違点１ないし相違点４について検討する。 
　
（３−４−１）相違点１について
　引用文献１には，「原データ」について「ヘルスケア」・「トランザクション」に当たるデータ記録であるとの具体的な記載はない。しかしながら，引用文献１の上記Ｄに「この原データとして，まず，プロフィールデータついては，・・・この他にも，・・・血糖値（糖尿病患者にはアルツハイマー症が少ないといわれる），喫煙経験（喫煙者アルツハイマー症が非喫煙者より相対的に少ないとの報告がある）などのデータが採用されてもよい。治療データとしては，・・・食事療法に関するデータ，・・・運動の両種に関するデータ，睡眠（時間等）に関するデータなどが挙げられる。」（【００３０】〜【００３１】）との記載があるとおり，「原データ」は健康管理に係るデータを含むものであるから「ヘルスケア」データに相当するといえ，また，同「原データ」はデータ集中収集管理システムにおける一連の処理の対象となるものであり，データを一連の処理に係るトランザクションデータとして対象とすることは，情報処理分野における常とう手段であることを鑑みれば，「原データ」をトランザクションデータとして扱うことに格別困難性は認められない。してみると，引用発明の入力データにおいて「ヘルスケア」・「トランザクション」・データ記録とすること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，相違点１は格別なものではない。
　
（３−４−２）相違点２および相違点３について
　相違点２及び相違点３は，データベースの生成及びそのためのデータの鍵による暗号化・復号化に関連することから，まとめて検討する。
　本願明細書には，「長期リンク化データベース」「長期用」という点に関し，例えば次のような記載がある。（当審注：下線は，参考のために当審で付与したものである。）
「患者の健康記録の電子データベース化は，商業利用及び非商業的利用の双方に役立つものである。例えば，
長期（寿命期間）の患者記録データベースは
用いられる
長期のデータベース
長期の研究
長期のデータベース装置
「システム例における第3の（即ち，最後の）コンポーネントは，中央装置，又は，他の適切な
長期のデータベース装置
長期のデータベース
長期患者
長期
長期にリンクする
長期のデータベースをアセンブリする
「本解決例の第1のステップで，各DSは，LDFに対して安全な送信をするためのデータ記録を作成する。DSは，その患者のデータ記録を第1の“匿名型”の形式に変換するように，患者のデータ記録内で選択したデータのフィールド（例えば，患者の特定する属性及び／又は他の標準の属性データについてのフィールド）を標準化し，暗号化する。各DSは，選択したデータ・フィールドを二重に暗号化するために，2つの鍵（即ち，ベンダーの特定鍵と特定のLDFに関連付けされた共通・
長期鍵
長期鍵
長期のデータベース
　上記記載によれば，本願補正発明１は，個々の患者の寿命期間に亘って利用が可能な長期の患者のデータを蓄積していくことでデータベースを形成する方法を含むものであり，「長期リンク化データベース」の「形成」による「アセンブリ」とは，上述のような，個々の患者の寿命期間に亘って利用が可能な長期の患者のデータが蓄積されたデータベースを形成する態様を含むものと解され，また「長期用」の鍵についても，上記「長期リンク化データベース」の形成に資する暗号化のための鍵という態様を含むものと解され，鍵の技術的特性について「長期用」であることによる格別な点は認められない。
　他方，引用発明も，上記Ａに「このような病症について，その進行を阻止する治療方法を確立するためには，まず，現在さしあたって行われている種々の治療と，この治療により得られた患者の症状とから成るサンプルを広く収集し，これらを分析し，それぞれの治療による効果を明らかにしていくことが必要である。そして，その分析結果を医療機関（病院等）や患者（潜在的な患者も含む）等に広く提供し，フィードバックしていくことにより，効果の認められる治療方法を徐々に明らかにしていくことが必要であるとされている。」との記載があるように，患者に関するデータに対し，治療・サンプルの収集・分析・分析結果の提供・フィードバックという長期的な利用を想定しているものであり，その場合に患者に関するデータとして，患者の寿命期間に亘るよう長期のものとすることが有用であることは自明の事項であることから，引用発明におけるデータベースを個々の患者の寿命期間に亘って利用が可能な長期の患者のデータが蓄積されたデータベースとし，また，データベース形成のための患者のデータを暗号化する鍵を「長期用」とすることに，技術上格別な困難性は認められない。
　さらに，暗号化・復号化の方式として，個々に設定した秘密鍵により暗号化し公開鍵により復号化する方式は，周知の技術事項（例えば，特開２００２−２３７８１２号公報の従来技術に関する記載【０００３】〜【０００４】に「データ交換を行う通信二者は，それぞれに秘密鍵を持ち，通信相手を認証するために公開鍵暗号を利用した電子認証を利用する。すなわち，送信者は，第三者である認証局の証明書（ＣＡ）付きの公開鍵及び秘密鍵で暗号化したデータを送る。一方，受信者は認証局証明書（ＣＡ）を確認し，添付されている公開鍵で暗号化データを復号する。」等の記載がある。）と言えるものであるし，特に，復号化のための公開鍵については，平成２５年１２月１７日付けの回答書における「本願発明は，暗号化されたデータを解読するために公開鍵を用いていること自体に格別な技術的意味を有するものではなく」との回答を参酌しても技術的に格別な点は見出せず，また，暗号化のための秘密鍵について，どのような単位毎に設定するかは当事者間の取決めに係る事項であるから，当該秘密鍵をデータ提供者毎に設定することは，暗号鍵によるセキュリティを考慮して，データの提供者及び受信者の当事者間で決定する設計的事項に過ぎない。
　してみると，引用発明におけるデータベースの生成において，周知技術等を採用することで，「長期リンク化データベース」を「形成」することで「アセンブリ」するものとし，また，データ記録の患者識別属性の暗号化のための特定の第１の暗号鍵を「長期用」とするとともに，「(c)」ステップでの暗号化のための特定の第2の暗号鍵として「ベンダー用」のものを用い，「(e)」ステップでの復号化のための前記第2の暗号鍵と相補的な鍵として「公開鍵」を用いるようにすること，すなわち，相違点２及び相違点３に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，相違点２及び相違点３は格別なものではない。　 
　
（３−４−３）相違点４について 
　引用文献２には，入力されたレコードデータを医療情報等を含むデータベースに蓄積するために，入力されたレコードの各々に対して，ファーストネーム等の個人に関係した属性情報による決定一致技術や確率一致技術といったアルゴリズムを用いた評価により，個々に関連付けた一意の識別子を割り当てることが記載されているとおり，上記「ファーストネーム等の個人に関係した属性情報」による上記「決定一致技術や確率一致技術といったアルゴリズム」とは，データ属性におけるマッチングアルゴリズムといえるものである。
　他方，引用発明は，入力データをデータベースに蓄積するものであり，その際には入力データとデータベースとの間で何らかの対応付けがなされていることは明らかであるところ，そのために両者のうちいずれか一方の有する識別子を両者の結び付けすなわちリンクのための情報として用いることは，情報処理分野における常とう手段であり，また，当該蓄積処理を，サーバ装置内におけるいずれの構成によって行うかに技術上格別な点はなく，必要により適宜決める設計的事項である。そして，引用発明及び引用文献２に記載の事項は，いずれも個人に関する医療情報をデータベースで管理する共通の技術分野に関するものであることから，上記（３−４−２）における検討結果も踏まえると，引用発明におけるデータベースへの蓄積において，引用文献２に記載の事項等を採用し，「(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップ」と「(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップ」とを，「LDF内に構成される第3のコンポーネント」で行うようにすること，すなわち相違点４に係る構成とすることは，当業者が容易に想到し得たものである。
　よって，相違点４は格別なものではない。　 
　
 （３−５）小括 
　上記で検討したごとく，相違点１ないし相違点４は格別のものではなく，そして，これらの相違点を総合的に勘案しても，本願補正発明１の奏する作用効果は，上記引用発明，引用文献２の記載事項及び周知技術等の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。 
　したがって，本願補正発明１は，上記引用発明，引用文献２の記載事項及び周知技術等に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条２項の規定により，特許出願の際独立して特許を受けることができない。
　
（４）請求項２３に係る発明の独立特許要件についての検討
　
（４−１）請求項２３に係る発明
　次に，本願の請求項２３に係る発明の独立特許要件について，以下に検討する。
　本願の請求項２３に係る発明は，上記「（１）」において，補正後の請求項２３として引用した，次のものである（以下，「本願補正発明２」という。）。
　
「個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースを格納する記憶装置であって，
　前記長期リンク化データベースは，マルチ・ソース型のデータ記録を有し，
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために長期用の特定の第１の暗号鍵により暗号化されており，
　各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる記憶装置。」
　
（４−２）引用文献等
　原査定の拒絶の理由に引用された，引用文献の記載事項及び引用発明は，前記「第２．」「（３）」の「（３−２）」に記載したとおりである。　
　
（４−３）本願補正発明２と引用発明との対比
　本願補正発明２と引用発明とを対比すると，
　引用発明の「データ集中収集管理システムにおける処理方法」も，データを「サーバ装置」に具える「記憶装置内のデータベース」に蓄積するものであるから，「サーバ装置」が「データベースを格納する記憶装置」を具える態様が含まれているといえ，
　また，引用文献１の図１から，「データベース」のための入力データである「原データ」を送信する「ＰＣ」が複数存在し，それらから「サーバ装置」がデータを集中収集しているのは明らかであるから，「原データ」はマルチソース型に相当するものであるといえる。
　以上の検討結果，及び，上記（３−３）における検討結果を踏まえると，引用発明の「端末装置から送信される患者の病症に関するデータを収集・蓄積するデータ集中収集管理システムにおける処理方法」において，「サーバ装置」内で「データベースを格納する記憶装置」と，本願補正発明２の「個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースを格納する記憶装置」とは，ともに，“個々の患者データ記録から生成されるデータベースを格納する記憶装置”である点で共通する。
　また，引用発明の「入力された原データに基づき，プロフィールデータ，治療データ，計測データを含む分析用送信データと，原データである分析用送信データのプロパティを示すプロパティデータが生成され」，「分析用送信データとプロパティデータを記憶装置内のデータベースに蓄積する」ことと，本願補正発明２の「前記長期リンク化データベースは，マルチ・ソース型のデータ記録を有」することとは，ともに，“前記データベースは，マルチ・ソース型のデータ記録を有”することである点で共通する。
　また，引用発明の「入力された原データに基づき，プロフィールデータ，治療データ，計測データを含む分析用送信データと，原データである分析用送信データのプロパティを示すプロパティデータが生成され，分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分について独自鍵によって暗号化を施」すことと，本願補正発明２の「前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために長期用の特定の第１の暗号鍵により暗号化されて」いることとは，ともに，“前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために特定の第１の暗号鍵により暗号化されて”いることである点で共通する。
　
　以上から，本願補正発明２と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　個々の患者データ記録から生成されるデータベースを格納する記憶装置であって，
　前記データベースは，マルチ・ソース型のデータ記録を有し，
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために特定の第１の暗号鍵により暗号化されている，記憶装置。　
　
（相違点ａ）　
　個々の患者のデータ記録に関し，本願補正発明２が「ヘルスケア」・「トランザクション」・データ記録であるのに対し，引用発明は，「原データ」が「ヘルスケア」に関する「トランザクション」データであるとは明示されていない点。
　
（相違点ｂ）　
　本願補正発明２が，「アセンブリ」した「長期リンク化データベース」を格納するものであり，また，データ記録において患者識別属性の暗号化のための特定の第１の暗号鍵が「長期用」であるのに対し，引用発明は，データを蓄積することで「データベース」を生成し記憶装置に格納するものであり，また，分析用送信データ及びプロパティデータ内の，プロフィールデータに含まれる性別，年齢，住所等のデータ部分の暗号化を「独自鍵」によって行っているところ，「データベース」について「長期リンク化」に係るものであることや，「独自鍵」について「長期用」であるとの特定はない点。
　
（相違点ｃ）　
　本願補正発明２が，「各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされ」ているのに対し，引用発明は，そのような構成になっていない点。
　
（４−４）判断 
　上記（相違点ａ）〜（相違点ｃ）について検討する。 
　
（４−４−１）相違点ａについて
　上記相違点ａは，上記「（３−３）」で検討した（相違点１）と同様の事項であるから，上記「（３−４−１）」で検討したとおり，相違点ａは格別のものではない。　
　
（４−４−２）相違点ｂについて
　上記相違点ｂは，上記「（３−３）」で検討した（相違点２）と，若干の表現の相違はあるものの内容的には同じものであるところ，上記「（３−４−２）」でも同様に述べたとおり，本願補正発明２は，本願明細書の記載から，個々の患者の寿命期間に亘って利用が可能な長期の患者のデータを蓄積していくことでデータベースを形成し格納する態様を含むものであり，「長期リンク化データベース」の「アセンブリ」とは，上述のような，個々の患者の寿命期間に亘って利用が可能な長期の患者のデータが蓄積されたデータベースを形成する態様を含むものと解され，また「長期用」の鍵についても，上記「長期リンク化データベース」の形成に資する暗号化のための鍵という態様を含むものと解され，鍵の技術的特性について「長期用」であることによる格別な点は認められない。
　他方，引用発明も，上記Ａに「このような病症について，その進行を阻止する治療方法を確立するためには，まず，現在さしあたって行われている種々の治療と，この治療により得られた患者の症状とから成るサンプルを広く収集し，これらを分析し，それぞれの治療による効果を明らかにしていくことが必要である。そして，その分析結果を医療機関（病院等）や患者（潜在的な患者も含む）等に広く提供し，フィードバックしていくことにより，効果の認められる治療方法を徐々に明らかにしていくことが必要であるとされている。」との記載があるように，患者に関するデータに対し，治療・サンプルの収集・分析・分析結果の提供・フィードバックという長期的な利用を想定しているものであり，その場合に患者に関するデータとして，患者の寿命期間に亘るよう長期のものとすることが有用であることは自明の事項であることから，引用発明におけるデータベースを個々の患者の寿命期間に亘って利用が可能な長期の患者のデータが蓄積されたデータベースとし，また，データベース形成のための患者のデータを暗号化する鍵を「長期用」とすることに，技術上格別な困難性は認められない。
　してみると，引用発明におけるデータベースの生成において，「長期リンク化データベース」を「アセンブリ」するものとし，また，データ記録の患者識別属性の暗号化のための特定の第１の暗号鍵を「長期用」とすること，すなわち，相違点ｂに係る構成とすることは，当業者が容易に想到し得たものである。
　よって，相違点ｂは格別のものではない。
　
（４−４−３）相違点ｃについて
　引用文献２には，入力されたレコードデータを医療情報等を含むデータベースに蓄積するために，入力されたレコードの各々に対して，ファーストネーム等の個人に関係した属性情報による決定一致技術や確率一致技術といったアルゴリズムを用いた評価により，個々に関連付けた一意の識別子を割り当てること，及び確率一致技術の際に，そのための変数として個人に関係した属性情報の組み合わせを用いることが記載されており，上記「個人に関係した属性情報の組み合わせ」を用いた「一意の識別子を割り当てること」とは，データ属性の選択組に基づく識別子の割り当てといえるものである。
　他方，引用発明は，入力データをデータベースに蓄積するものであり，その際には入力データとデータベースとの間で何らかの対応付けがなされていることは明らかであるところ，そのために両者のうちいずれか一方の有する識別子を両者の結び付けすなわちリンクのための情報として用いることは，情報処理分野における常とう手段である。そして，引用発明及び引用文献２に記載の事項は，いずれも個人に関する医療情報をデータベースで管理する共通の技術分野に関するものであることから，引用発明において，引用文献２に記載の事項等を採用し，「各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされ」るようにすること，すなわち相違点ｃに係る構成とすることは，当業者が容易に想到し得たものである。
　よって，相違点ｃは格別なものではない。
　
（４−５）小括 
　上記で検討したごとく，相違点ａないし相違点ｃは格別のものではなく，そして，これらの相違点を総合的に勘案しても，本願補正発明２の奏する作用効果は，上記引用発明及び引用文献２の記載事項の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。 
　したがって，本願補正発明２は，上記引用発明及び引用文献２の記載事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条２項の規定により，特許出願の際独立して特許を受けることができない。
　
（５）本件補正についての結び
 　 
　上記で検討した通り，本願の補正後の請求項１に係る発明及び請求項２３に係る発明は，第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものであるから，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に違反するので，特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　
第３．本願に係る発明について
１．本願に係る発明
　平成２４年１月２７日付けの手続補正は，上記のとおり却下されたので，本願に係る発明は，上記「第２．」，「（１）」において，補正前の請求項（以下，これを，「本願の請求項」という）として引用した事項により特定されるものである。
　
２．原審の拒絶理由
　原審による，平成２３年２月２５日付けの拒絶理由は，概略，以下のとおりである。
　
『　　　　　　　　　　　　　　　　理　由
　
（理由１）
　この出願の下記の請求項に係る発明は，下記の点で特許法第２９条第１項柱書に規定する要件を満たしていないので，特許を受けることができません。
　
（理由２）
　この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができません。
　
（理由３）
　この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていません。
　
（理由４）
　この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていません。
　
（理由５）
　この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていません。
　
　　　　　　記　　（引用文献等については引用文献等一覧参照）
　
（理由１）・・・＜省略＞・・・
　
（理由２）
・請求項　：１〜２４
・引用文献：１〜５
・備考
　請求項１，４〜９，１２〜１４，１６〜１９，２２〜２４に係る発明について，引用文献１（特に，【００２２】段〜【００２８】段，【００５０】段〜【００５４】段，【図９】）には，病院のＰＣにおいて，患者氏名などの個人情報（請求項１における「患者識別属性」に相当）を独自鍵（請求項１における「第１の暗号鍵」に相当）及びＰＣとサーバ装置間との暗号化鍵（請求項１における「第２の暗号鍵」に相当）で暗号化して，分析用送信データ及びプロパティデータの他の部分のデータとともにサーバ装置へ送信し，サーバ装置において，２重に暗号化された患者氏名などの個人情報は，ＰＣとサーバ装置間との暗号化鍵で復号され，独自鍵で暗号化されたまま利用する旨，また，サーバ装置のデータベースに，プロパティデータ及び分析用送信データを記憶する旨の発明が記載されています。
　また，引用文献２（特に，【００１０】段，【００４５】段〜【００５５】段）には，個人についての医療情報を含む参照データベースにレコードを入力する際，一意の識別子ＵＩＤを確率一致技術により割り当てる旨の発明が記載されています。
　そして，引用文献１に記載された発明に，引用文献２に記載された発明を採用し，引用文献１に記載された発明におけるデータベースにおけるプロパティデータ及び分析用送信データの記憶に対して，引用文献２に記載された発明を採用することに，格別の困難性はありません。
・・・＜省略＞・・・
（理由３）・・・＜省略＞・・・
　
（理由４）・・・＜省略＞・・・
　
（理由５）
・・・＜省略＞・・・
（８）請求項２３，２４は，「長期リンク化データベース」として特許請求されているものと認められます。
　「データベース」とは，一般に情報の集合体を意味するものと認められ，「物の発明」か「方法の発明」かが特定できず，発明の内容が不明確です。
　
　　　　　　　　　　　 引　用　文　献　等　一　覧
１．特開２００３−１７３３７６号公報
２．特開２０００−３２４０９４号公報
３．特開２００２−３２４７３号公報
４．特開２００３−５６４５号公報
５．越塚　登，「ユビキタス・コンピューティングと物流システム」，ロジスティクスシステム，（社）日本ロジスティクスシステム協会発行，２００４年　１月３０日，第１３巻  第２号，ｐ．３２〜３８　』
　
３．当審の判断
　上記，原審の拒絶理由で指摘された点のうち，理由５の（８），及び，理由２について，以下に検討する。
　
（１）理由５の（８）（特許法第３６条第６項第２号）について
　本願の請求項２３における「長期リンク化データベース」との記載は，「データベース」という用語自体は単に情報の集合体を意味するものと解されるところ，「物の発明」を指すのか「方法の発明」を指すのか特定することができず不明確であり，また，請求項中の他の記載や従属する請求項の記載によっても，依然として明確でない。
　また，上記「長期リンク化データベース」との記載に関連する，発明の詳細な説明における記載を参酌しても，依然として明確でない。
　上記の点は，本願の請求項２４についても同様である。
　以上のとおりであるから，本願の上記特許請求の範囲の記載は，特許法第３６条第６項第２号に規定する要件を満たしているとはいえない。
　
（２）理由２（特許法第２９条第２項）について
（２−１）請求項１に係る発明についての検討
（２−１−１）請求項１に係る発明
　本願の請求項１に係る発明（以下，「本願発明１」という。）は，上記「第２．」「（１）」において，補正前の請求項１として記載した次のとおりのものである。 
　
「個々の患者のヘルスケア・トランザクション・データ記録から長期リンク化データベースをアセンブリする方法であって，
第１のコンポーネントで，
(a) 患者識別属性，及び非識別属性を有するデータ記録を取得するステップと，
(b) 中央装置(LDF)に対して特定の第１の暗号鍵を用いて，前記データ記録の前記患者識別属性を暗号化するステップと，
(c) 特定の第2の暗号鍵で，前記ステップ（b）において暗号化した前記データ記録の前記患者識別属性を暗号化するステップと，
　前記LDF内に構成される第2のコンポーネントで，
(d) 前記ステップ(b)及び(c)において暗号化した前記データ記録を受信するステップと，
(e) 前記患者識別属性が，前記LDFに対して特定の前記第1の暗号鍵による前記ステップ(b)の暗号化のみ保持するように，前記受信したデータ記録を部分的に解読するステップと，
　前記LDF内に構成される第3のコンポーネントで，
(f) 前記データ記録に対して長期の患者識別子を割り当てるようにデータ属性のマッチング・アルゴリズムを用いるステップと，
(g) 前記暗号化したデータ記録を長期の患者識別子毎にリンクし，長期リンク化データベースを形成するステップと，
を含む方法。」
　
（２−１−２）引用文献等 
　原査定の拒絶の理由に引用された引用文献である，特開２００３−１７３３７６号公報（引用文献１），特開２０００−３２４０９４号公報（引用文献２）の記載事項及び引用発明は，前記「第２．」「（３）」の「（３−２）」に記載したとおりである。　
 　　
（２−１−３）請求項１に係る発明についての対比・判断
　本願補正発明１は，本願発明１に対し前記「第２．」「（２）」で述べた限定的減縮をしたものであるから，本願発明１は，上記本願補正発明１から当該限定的減縮により限定される要件を無くしたものに相当する。
　そうすると，本願発明１の構成要件を全て含み，さらに特定の構成要件に限定要件を付加したものに相当する本願補正発明１が，前記「第２．」「（３）」の「（３−４）判断」に記載したとおり，引用発明，引用文献２の記載事項及び周知技術等に基づいて，当業者が容易に発明をすることができたものであるから，本願発明１も，同様の理由により，当該引用発明，引用文献２の記載事項及び周知技術等に基づいて，当業者が容易に発明をすることができたものである。
　
（２−２）請求項２３に係る発明についての検討
（２−２−１）請求項２３に係る発明
　本願の請求項２３に係る発明（以下，「本願発明２」という。）は，上記「第２．」「（１）」において，補正前の請求項２３として記載した次のとおりのものである。
　
「個々の患者ヘルスケア・トランザクション・データ記録からアセンブリされる長期リンク化データベースであって，
　マルチ・ソース型のデータ記録を格納し，
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために暗号化されおり，
　各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされる長期リンク化データベース。」
　
（２−２−２）引用文献等 
　原査定の拒絶の理由に引用された引用文献である，特開２００３−１７３３７６号公報（引用文献１），特開２０００−３２４０９４号公報（引用文献２）の記載事項及び引用発明は，前記「第２．」「（３）」の「（３−２）」に記載したとおりである。
　
（２−２−３）請求項２３に係る発明についての対比・判断
　前記「第２．」「（４）」の「（４−３）」における検討結果を踏まえると，本願発明２と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
　個々の患者データ記録から生成されるデータベースであって，
　マルチ・ソース型のデータ記録を格納し，
　前記マルチ・ソース型のデータ記録において，患者識別属性が，患者のプライバシを保護するために暗号化されている，データベース。
　
（相違点あ）　
　個々の患者のデータ記録に関し，本願発明２が「ヘルスケア」・「トランザクション」・データ記録であるのに対し，引用発明は，「原データ」が「ヘルスケア」に関する「トランザクション」データであるとは明示されていない点。
　
（相違点い）　
　本願発明２が，「アセンブリ」した「長期リンク化データベース」であるのに対し，引用発明は，データを蓄積することで「データベース」を生成し記憶装置に格納するものであり，「データベース」について「長期リンク化」に係るものであるとの特定はない点。
　
（相違点う）　
　本願発明２が，「各データ記録は，データ属性の選択組に基づく識別子を割り当てられており，該割り当てられた識別子により各データ記録がリンクされ」ているのに対し，引用発明は，そのような構成になっていない点。
　
　上記（相違点あ）〜（相違点う）について検討する。
　本願発明２と，引用発明との（相違点あ）〜（相違点う）は，本願補正発明２と，引用発明との（相違点ａ）〜（相違点ｃ）に対して，（相違点あ），（相違点い），及び，（相違点う）は，（相違点ａ），（相違点ｂ），及び，（相違点ｃ）と実質的に同じ又は内容として含まれるものであるから，上記「第２．平成２４年１月２７日付けの手続補正の却下の決定」の「（４−４）判断 」において検討したとおり，（相違点あ）〜（相違点う）は，格別のものではない。
　そして，本願発明２の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　したがって，本願発明２は，当該引用発明及び引用文献２の記載事項に基づいて，当業者が容易に発明をすることができたものである。
　
（２−３）理由２についてのむすび
　以上のとおりであるから，本願の請求項１に係る発明及び請求項２３に係る発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項に規定する要件を満たしているとはいえない。
　
４．むすび
　以上のとおり，本願の請求項２３，２４の記載が，特許法第３６条第６項第２号に規定する要件を満たしておらず，また，本願の請求項１に係る発明及び請求項２３に係る発明は，引用刊行物に記載の発明に基づいて当業者が容易になし得たものであるから，他の請求項について検討するまでもなく，本願は特許法第２９条第２項に規定する要件を満たしておらず，したがって，特許を受けることができない。
　よって，結論のとおり審決する。