【事件の表示】
　特願２０１５−５２７４３３「記録のための暗号化データ記憶装置」拒絶査定不服審判事件〔平成２６年　２月２０日国際公開，ＷＯ２０１４／０２８０３５，平成２７年　９月　７日国内公表，特表２０１５−５２６０４８，請求項の数（１４）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　本願は，２０１２年８月３０日（パリ条約による優先権主張外国庁受理２０１２年８月１５日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２７年３月４日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出されると共に審査請求がなされ，平成２８年２月１５日付けで審査官により拒絶理由が通知され，これに対して平成２８年４月２６日付けで意見書が提出されると共に手続補正がなされたが，平成２８年７月２６日付けで審査官により拒絶査定がなされ，これに対して平成２８年１０月１９日付けで審判請求がなされると共に手続補正がなされ，平成２８年１１月２５日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２９年４月１３日付けで上申書が提出され，平成２９年８月２８日付けで当審により審判請求時の手続補正が却下されると共に拒絶理由が通知され，これに対して平成２９年１１月２４日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２．本願発明について
　本願の請求項１〜本願の請求項１４に係る発明は，平成２９年１１月２４日付けの手続補正（以下，これを「本件手続補正」という）により補正された特許請求の範囲の請求項１〜請求項１４に記載された，次のとおりのものである。
　
「【請求項１】
　処理システムにより実施される方法であって，
　　患者のメタデータ・ツリー上の第１の電子健康記録の第１の位置を判定するステップと，
　　前記第１の位置と，第１のプロバイダーに対応する第１のプロバイダー・キーとに基づいて，前記第１の電子健康記録のための第１のレコード・キーを生成するステップであって，前記第１のプロバイダー・キーは，前記患者に対応する患者キーと，前記第１のプロバイダーに対応する第１のプロバイダー識別子とに基づいて生成される，前記第１の電子健康記録のための第１のレコード・キーを生成するステップと，
　　前記第１のレコード・キーを使用して前記第１の電子健康記録を暗号化し，第１の暗号化電子健康記録を生成するステップと，
　　前記第１の暗号化電子健康記録を暗号化データ記憶装置に提供するステップと
　を含む方法。
　　【請求項２】
　前記暗号化データ記憶装置上の前記第１の暗号化電子健康記録への第１の参照を含むように，前記メタデータ・ツリー上の前記第１の位置を更新するステップと，
　前記メタデータ・ツリーを，第２のプロバイダーによりアクセス可能なメタデータ記憶装置に提供するステップと
　をさらに含む，請求項１に記載の方法。
　　【請求項３】
　前記メタデータ・ツリー上の第２の位置が，前記暗号化データ記憶装置上の第２の暗号化電子健康記録への第２の参照を含み，前記第２の暗号化電子健康記録は，前記第２のプロバイダーにより生成され，前記第２のプロバイダーは，前記第１のプロバイダーとは提携していない，請求項２に記載の方法。
　　【請求項４】
　前記第２の暗号化電子健康記録のための第２のレコード・キーを受け取るステップであって，前記第２のレコード・キーが，前記第２の参照を含む前記メタデータ・ツリー上の前記第２の位置と，前記第２のプロバイダーに対応する第２のプロバイダー・キーとに基づいて生成され，前記第２のプロバイダー・キーが，前記患者キーと，前記第２のプロバイダーに対応する第２のプロバイダー識別子とから生成される，前記第２の暗号化電子健康記録のための第２のレコード・キーを受け取るステップと，
　前記暗号化データ記憶装置から前記第２の暗号化電子健康記録を取得するステップと，
　前記第２のレコード・キーを使用して前記第２の暗号化電子健康記録の暗号化を解除するステップと
　をさらに含む，請求項３に記載の方法。
　　【請求項５】
　前記患者の前記メタデータ・ツリー上の第２の電子健康記録の第２の位置を判定するステップと，
　前記第２の位置と，前記第１のプロバイダー・キーとに基づいて，前記第２の電子健康記録のための第２のレコード・キーを生成するステップと，
　前記第２のレコード・キーを使用して前記第２の電子健康記録を暗号化し，第２の暗号化電子健康記録を生成するステップと，
　前記第２の暗号化電子健康記録を前記暗号化データ記憶装置に提供するステップと
　をさらに含む，請求項１に記載の方法。
　　【請求項６】
　前記第１のレコード・キーが，前記第２のレコード・キーとは異なり，前記第１のレコード・キーは，前記第２の暗号化電子健康記録の暗号解除には使用できず，前記第２のレコード・キーは，前記第１の暗号化電子健康記録の暗号解除には使用できない，請求項５に記載の方法。
　　【請求項７】
　処理システムであって，
　　一組の一以上のプロセッサと，
　　一組の命令を記憶するメモリであって，前記一組の命令が，前記一組のプロセッサにより実行されたときに，前記一組のプロセッサに，
　　　暗号化データ記憶装置上の第１の暗号化電子健康記録に対応する，患者のメタデータ・ツリー上の第１の位置を判定させ，
　　　前記第１の位置と，第１のプロバイダーに対応する第１のプロバイダー・キーとに基づいて，前記第１の暗号化電子健康記録のための第１のレコード・キーを生成させ，前記第１のプロバイダー・キーは，前記患者に対応する患者キーと，前記第１のプロバイダーに対応する第１のプロバイダー識別子とに基づいて生成され，
　　　前記暗号化データ記憶装置上の前記第１の暗号化電子健康記録への第１の参照を使用して，前記暗号化データ記憶装置から前記第１の暗号化電子健康記録を取得させ，前記第１の参照が，前記メタデータ・ツリー上の前記第１の位置に含まれ，
　　　前記第１のレコード・キーを使用して前記第１の暗号化電子健康記録の暗号化を解除させるように構成される，一組の命令を記憶するメモリと
　を含む処理システム。
　　【請求項８】
　前記メタデータ・ツリー上の第２の位置は，前記暗号化データ記憶装置上の第２の暗号化電子健康記録への第２の参照を含み，前記第２の暗号化電子健康記録は，第２のプロバイダーにより生成され，前記第２のプロバイダーは，前記第１のプロバイダーとは提携していない，請求項７に記載の処理システム。
　　【請求項９】
　前記第１のレコード・キーは，前記第２の暗号化電子健康記録の暗号解除には使用できず，第２のレコード・キーは，前記第２の暗号化電子健康記録の暗号解除に使用可能であり，前記第２のレコード・キーは，前記第１の暗号化電子健康記録の暗号解除には使用できない，請求項８に記載の処理システム。
　　【請求項１０】
　前記一組の命令が，前記一組のプロセッサにより実行されたときに，前記一組のプロセッサに，前記患者，前記第１のプロバイダー，及び，前記第１のプロバイダーとは提携していない第２のプロバイダーによってアクセス可能なメタデータ記憶装置から前記メタデータ・ツリーを取得させるように構成される，請求項７に記載の処理システム。
　　【請求項１１】
　命令が記憶された機械読取可能な記憶媒体であって，前記命令が，処理システムにより実行されたときに，前記処理システムに，
　　第１のプロバイダーにより生成された暗号化データ記憶装置上の第１の暗号化電子健康記録に対応する患者のメタデータ・ツリー上の第１の位置を判定させ，
　　前記第１の暗号化電子健康記録のための第１のレコード・キーであって，前記第１の位置と，前記第１のプロバイダーに対応する第１のプロバイダー・キーとに基づいて生成された第１のレコード・キーを受信させ，前記第１のプロバイダー・キーは，前記患者に対応する患者キーと，前記第１のプロバイダーに対応する第１のプロバイダー識別子とに基づいて生成され，
　　前記暗号化データ記憶装置上の前記第１の暗号化電子健康記録への第１の参照を使用して，前記暗号化データ記憶装置から前記第１の暗号化電子健康記録を取得させ，前記第１の参照が，前記メタデータ・ツリー上の前記第１の位置に含まれ，
　　第２のプロバイダーにより，前記第１のレコード・キーを使用して，前記第１の暗号化電子健康記録の暗号化を解除させるように構成される，機械読取可能な記憶媒体。
　　【請求項１２】
　前記メタデータ・ツリー上の第２の位置は，前記暗号化データ記憶装置上の第２の暗号化電子健康記録への第２の参照を含み，前記第２の暗号化電子健康記録は，前記第２のプロバイダーにより生成され，前記第２のプロバイダーは，前記第１のプロバイダーとは提携していない，請求項１１に記載の機械読取可能な記憶媒体。
　　【請求項１３】
　前記第１のレコード・キーは，前記第２の暗号化電子健康記録の暗号解除には使用できず，第２のレコード・キーは，前記第２の暗号化電子健康記録の暗号解除に使用可能であり，前記第２のレコード・キーは，前記第１の暗号化電子健康記録の暗号解除には使用できない，請求項１２に記載の機械読取可能な記憶媒体。
　　【請求項１４】
　前記命令が，前記処理システムにより実行されたときに，前記処理システムに，
　　前記第１のレコード・キーを前記第１のプロバイダーまたは前記患者に要求させ，
　　前記第１のプロバイダーまたは前記患者から前記第１のレコード・キーを受信させるように構成される，請求項１１に記載の機械読取可能な記憶媒体。」
　
第３．引用刊行物に記載の事項
１．原審における平成２８年２月１５日付けの拒絶理由（以下，これを「原審拒絶理由」という）に引用された，本願の第１国出願前に既に公知である，特表２００５−５３９４２３号公報（公表日；２００５年１２月２２日，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【請求項１】
　
ツリー構造のメタデータ暗号化方法において
　
前記ツリー構造のメタデータの所定ノードでの情報を暗号化する
暗号化キー及び前記所定ノードを特定する情報を入力値とする関数を使用して前記所定ノードでの暗号化キーを生成する段階
　前記
生成された暗号化キーを使用して前記所定ノードでの情報を暗号化する段階
　
Ｂ．「【００４２】
　図５は，本発明によるメタデータの保護及び管理方法を説明するためのツリー構造で表現されたメタデータを示す。図５のツリー構造で表示されたメタデータは，図３のＸｒＭＬで表現されたメタデータと同一である。」
　
Ｃ．「【００４７】
　
ノードＡでの情報は，高級暗号標準（ＡＥＳ）のような暗号化アルゴリズムを使用して暗号化キーＫＥＹ＿Ａによって暗号化される
【００４８】
　また，ノードＡの子ノードであるノードＢの情報は，次の式（１）により求められるＫｅｙ＿Ｂを使用して暗号化される。
【００４９】
　　　
Ｋｅｙ＿Ｂ＝Ｆ（Ｋｅｙ＿Ａ，Ｉｎｆｏ＿Ｂ）    （１）
　ここで，
Ｉｎｆｏ＿ＢはノードＢの位置情報である
式（１）を使用してＫｅｙ＿Ａ及びＩｎｆｏ＿ＢからＫｅｙ＿Ｂを計算する
【００５０】
　
本実施例では位置情報として該当ノードの絶対位置情報を使用した
【００５１】
　また，ノードＢの子ノードのうち一つであるノードＣ１の情報は次の式（２）により暗号化される。
【００５２】
 　　Ｋｅｙ＿Ｃ１＝Ｆ（Ｋｅｙ＿Ｂ，Ｉｎｆｏ＿Ｃ１）    （２）
　ここで，Ｉｎｆｏ＿Ｃ１はノードＣ１の相対的な位置または絶対的な位置であり，式（１）と同じく関数Ｆは一方向関数である。すなわち，式（２）を使用してＫｅｙ＿Ｂ及びＩｎｆｏ＿Ｃ１からＫｅｙ＿Ｃ１を計算することは可能であるが，Ｋｅｙ＿Ｃ１及びＩｎｆｏ＿Ｃ１を知っているとしてもＫｅｙ＿Ｂを計算することは不可能である。」
　
Ｄ．「【００６１】
　このように，
本発明によるメタデータ暗号化保護及び管理方法では一方向関数を使用して，親ノードのキー情報及び該当ノードの位置情報から該当ノードのキー情報を生成する
　
Ｅ．「【００９３】
　本発明のさらに他の実施例によれば，メタデータのうち属性値のみを暗号化する。すなわち，位置情報及び属性名称は暗号化しない。このように，位置情報及び属性名称を暗号化しないことによって，ＸＭＬ全体ツリーを復号する必要なくＸＭＬツリーの所定のサブブランチのみを容易に復号化できる。」
　
Ｆ．「【図６】
」
　
２．原審拒絶理由に引用された，本願の第１国出願前に既に公知である，米国特許出願公開第２００３／０２００２１３号明細書（公開日；２００３年１０月２３日，以下，これを「引用刊行物２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｇ．「[0011]　It is an object of the invention to provide a method and system for developing software and managing data, such as for managing patient medical records and other data, while avoiding or minimizing lengthy and costly development cycles for database design, implementation, tuning and maintenance, data cleansing, building of snowflake or other models, and difficulties in harvesting data and generating reports and user screens.
　
[0012]　In accordance with the inventive adaptive data management (ADM) method and system, a static database model is provided and is optimized for manipulation of large volumes of data with a standard front-end component interface, thereby simplifying database design and data access, while reducing development cost and development time. Furthermore, the model does not require numerous qualified technical personnel to monitor all database activity, the data to be collected is described, both in format and in relationships, as meta data to the model, and user data (instance data) is then collected and stored using the format defined by the meta data. In tests, the inventive method and system have shown success in managing large numbers of records and in document indexing as useful in such applications as web sites. Due to the nature of ADM data storage, the data requires little of no cleansing before inclusion into a data warehousing database.
　
 [0013]　ADM provides access protection and tracking, ensuring data security and integrity, through a gateway requiring identity authentication and multi-layered access control. ADM manages multiuser access and concurrency.
　
 [0014]　The ADM may be used with an Oracle database running on any of several platforms to provide the data storage support, with as many as about 14 or more objects participating to the design. A set of components, developed as Microsoft COM objects, provide access to user front-end applications.
　
 [0015]　ADM provides both a back-end information storage infrastructure and a flexible development environment for data storage. ADM is based on a meta data model. The organization of the data itself (the meta data) is described to ADM prior to any collection of data. The meta data model encloses definitions of meta data elements as well as the relationships among these meta data elements. Data elements may be organized as trees, i.e., a meta data element has at most one parent data element, or as graphs, i.e., a meta data element may have one or more parent data elements, thus allowing representations of most possible data models.」
（[0011]　本発明の目的は，データベース・デザイン，実装，チューニングと管理，データ・クリーニング，スノーフレーク，或いは，他のモデルの構築の長く，費用のかかる開発，そして，データを収集すること，報告とユーザ画面を生成することの困難性を，回避，或いは，最小化しつつ，例えば，患者の医療記録，或いは，他のデータの管理のために，データを管理すること，及び，ソフトウェアを開発することのための，システムと方法を提供することである。
　
[0012]　独創的な，適応データ管理（ＡＤＭ）方法，及び，システムに従って，静的データベース・モデルが，標準的な，フロント−エンド・コンポーネント・インタフェースによって，大容量のデータの操作のために提供され，最適化され，それによって，コストの情報の，時間の情報を削減しつつ，データベースのデザインと，データのアクセスを簡略化する。更に，そのモデルは，全てのデータベースの動作をモニタするために，多数の，資格のある技術職員を要求せず，収集されるデータは，モデルのメタデータとして，書式と関係性の両方おいて記述され，そして，ユーザ・データ（インスタンス・データ）は，次に，メタデータによって定義される書式を用いて，収集され，格納される。試験において，その独創的な方法，及び，システムは，ウェブ・サイトなどのアプリケーションの下で有益な，多数の記録の管理，及び，文書のインデックス化における，成功を示した。ＡＤＭデータ・ストレージの本質に起因して，データは，データ・ウェアハウス化されたデータベースへの組み入れ前に，洗浄されないことを，ほとんど要求しない。
　
[0013]　ＡＤＭは，識別認証と，多層化されたアクセス制御が要求されるゲートウェイを通じて，アクセス保護と，アクセス追跡，データの安全性と完全性の確保を提供する。ＡＤＭは，マルチユーザ・アクセスと，同時並行性を管理する。
　
[0014]　ＡＤＭは，そのデザインに加わる，１４か，それ以上の数のオブジェクトで，データ・ストレージ・サポートを提供するために，種々のプラットフォーム上で動作している，オラクルデータベースと共に用いられ得る。
　
[0015]　ＡＤＭは，バック−エンド情報格納基盤，及び，データ・ストレージための，柔軟な，開発環境の両方を提供する。ＡＤＭは，メタデータ・モデルに基づいている。データ自身（メタデータ）の組織は，データの全ての収集に先だって，ＡＤＭに説明される。メタデータ・モデルは，これらメタデータ要素の互いの関係性だけでなく，メタデータ要素の定義も含んでいる。データ要素は，それ故に，データ・モデルの全ての可能な表現が許可されるような，例えば，データ要素が，高々，１つの親データ要素を持つような，木として，或いは，データ要素が，例えば，１つ，或いは，複数の親データ要素を持つような，グラフとして組織化される。当審にて訳出。以下，同じ。）
　
Ｈ．「[0063]　 The Meta data is the structure formally defining how data is collected. This interface is purely administrative: only the ADM Administrative Utility will make use of this interface. Note that inexperienced use of this interface may be detrimental to existing data elements.」
（メタデータは，どのようにデータが収集されるかが形式的に定義されている構造である。このインターフェースは，完全に，管理である：ＡＤＭ管理ユーティリティのみが，このインターフェースを使用する。不慣れな，このインターフェースの使用は，存在するデータ要素に，悪影響を及ぼすことに留意されたい。）
　
Ｉ．「[0070]　These interfaces allow management of information related to user, security and user access rights.」
（これらのインターフェースは，ユーザに関連した情報，セキュリティ，及び，ユーザ・アクセス権限の管理を許可されている。）
　
Ｊ．「【図３】
」
　
Ｋ．「【図４】
」
　
第４．引用刊行物に記載の発明
１．上記Ａの「ツリー構造のメタデータ暗号化方法において」という記載から，引用刊行物１は，
“ツリー構造のメタデータ暗号化方法”
　に関するものであることが読み取れる。
　
２．上記Ａの「ツリー構造のメタデータの所定ノードでの情報を暗号化する」という記載，上記Ｃの「Ｉｎｆｏ＿ＢはノードＢの位置情報である」という記載，及び，同じく，上記Ｃの「本実施例では位置情報として該当ノードの絶対位置情報を使用した」という記載から，引用刊行物１においては，
“ツリー構造のメタデータの所定ノードでの位置情報が用いられる”
　ことが読み取れる。
　
３．上記Ａの「上位ノードの暗号化キー及び前記所定ノードを特定する情報を入力値とする関数を使用して前記所定ノードでの暗号化キーを生成する段階」という記載，上記Ｃの「Ｋｅｙ＿Ｂ＝Ｆ（Ｋｅｙ＿Ａ，Ｉｎｆｏ＿Ｂ）（１）」という記載，同じく，上記Ｃの「式（１）を使用してＫｅｙ＿Ａ及びＩｎｆｏ＿ＢからＫｅｙ＿Ｂを計算する」という記載，及び，上記Ｄの「本発明によるメタデータ暗号化保護及び管理方法では一方向関数を使用して，親ノードのキー情報及び該当ノードの位置情報から該当ノードのキー情報を生成する」という記載と，上記Ｆに引用した【図６】に開示の事項から，引用刊行物１においては，
“所定ノードにおける，当該所定ノードの情報を暗号化するためのキー情報は，当該所定ノードの位置情報と，当該所定ノードの親ノードの鍵情報とから生成される”
　ものであることが読み取れる。
　
４．上記Ａの「生成された暗号化キーを使用して前記所定ノードでの情報を暗号化する段階」という記載，上記Ｃの「ノードＡでの情報は，高級暗号標準（ＡＥＳ）のような暗号化アルゴリズムを使用して暗号化キーＫＥＹ＿Ａによって暗号化される」という記載と，上記２．において検討した事項から，引用刊行物１においては，
“所定のノードの情報は，当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される”
　ことが読み取れる。
　
５．以上１．〜４．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
“ツリー構造のメタデータ暗号化方法であって，
　ツリー構造のメタデータの所定ノードでの位置情報が用いられ，
　前記所定ノードにおける，当該所定ノードの情報を暗号化するためのキー情報は，当該所定ノードの位置情報と，当該所定ノードの親ノードの鍵情報とから生成され，
　前記所定のノードの情報は，当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される，方法。”
　
第５．本願の請求項１に係る発明（以下，これを「本願発明」という）と引用発明との対比
１．引用発明において，「メタデータ」の「暗号化」の処理は，何れかの“システム上”で実施されることは，明らかであるから，
　引用発明における「ツリー構造のメタデータ暗号化方法」が，
　本願発明における「処理システムにより実施される方法」に相当する。
　
２．引用発明における「メタデータの所定ノードでの位置情報」が，
　本願発明における「第１の位置」に相当し，
　引用発明における「所定ノードの情報」と，
　本願発明における「第１の電子健康記録」とは，
　“被暗号化情報”である点で共通し，
　引用発明における「所定のノードの情報を暗号化するためのキー情報」と，
　本願発明における「第１のレコードキー」とは，
“データ暗号化キー”である点で共通し，
　引用発明における「親ノードの鍵情報」と，
　本願発明における「第１のプロバイダーに対応する第１のプロバイダー・キー」とは，“データ暗号化キーを生成するためのキー情報”である点で共通するので，
　引用発明における「所定ノードにおける，当該所定ノードの情報を暗号化するためのキー情報は，当該所定ノードの位置情報と，当該所定ノードの親ノードの鍵情報とから生成され」ることと，
　本願発明における「第１の位置と，第１のプロバイダーに対応する第１のプロバイダー・キーとに基づいて，前記第１の電子健康記録のための第１のレコード・キーを生成するステップ」とは，
“第１の位置情報と，データ暗号化キーを生成するためのキー情報とに基づいて，被暗号化情報を暗号化するための前記データ暗号化キーを生成するステップ”
　である点で共通する。
　
３．引用発明における「所定のノードの情報は，当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される」ことと，
　本願発明における「第１のレコード・キーを使用して前記第１の電子健康記録を暗号化し，第１の暗号化電子健康記録を生成するステップ」とは，
“データ暗号化キーを使用して，被暗号化情報を暗号化し，第１の暗号化情報を生成するステップ”
　である点で共通する。
　
４．以上，上記１．〜３．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　処理システムにより実施される方法であって，
　第１の位置情報と，データ暗号化キーを生成するためのキー情報とに基づいて，被暗号化情報を暗号化するための前記データ暗号化キーを生成するステップと，
　前記データ暗号化キーを使用して，被暗号化情報を暗号化し，前記第１の暗号化情報を生成するステップと，を含む方法。
　
［相違点１］
“データ暗号化キーを生成するためのキー情報”に関して，
　本願発明においては，「第１のプロバイダーに対応する第１のプロバイダー・キー」であるのに対して，
　引用発明においては，「所定ノードの親ノードの鍵情報」である点。
　
［相違点２］
　本願発明においては，「第１のプロバイダー・キーは，前記患者に対応する患者キーと，前記第１のプロバイダーに対応する第１のプロバイダー識別子とに基づいて生成される」ものであるのに対して，
　引用発明においては，「患者キー」，「プロバイダー識別子」に関する言及がない点。
　
［相違点３］
“被暗号化情報”に関して，
　本願発明においては，「電子健康記録」であるのに対して，
　引用発明においては，“ツリー構造の所定ノードの情報”であって，「電子健康記録」に対する言及がない点。
　
［相違点４］
　本願発明においては，「第１の暗号化電子健康記録を暗号化データ記憶装置に提供するステップ」が存在しているのに対して，
　引用発明においては，そのようなステップに関する言及がない点。
　
第６．相違点についての当審の判断
［相違点１］，及び，［相違点２］について検討すると，「プロバイダー・キー」を用いること，及び，当該「プロバイダー・キー」を，「患者キー」と，「プロバイダー識別子」から生成することに関しては，引用刊行物２にも，記載されておらず，当該指摘の構成が，当業者とって自明の事項とも認められない。
　したがって，［相違点３］，及び，［相違点４］について判断するまでもなく，本願発明は，当業者であっても引用発明，引用刊行物２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
第７．本願の請求項２〜本願の請求項１４に係る発明について
１．本願の請求項２〜本願の請求項６に係る発明について
　本願の請求項２〜本願の請求項６は，本願の請求項１を直接・間接に引用するものであるから，本願の請求項２〜本願の請求項６に係る発明は，上記において検討した［相違点１］，及び，［相違点２］に係る構成を有するものである。
　したがって，本願の請求項２〜本願の請求項６に係る発明は，引用発明，引用刊行物２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
２．本願の請求項７〜本願の請求項１０に係る発明について
　本願の請求項７に係る発明は，発明のカテゴリが相違するものの，本願発明とほぼ同等の構成を有するものであり，本願の請求項８〜本願の請求項１０は，本願の請求項７を直接・間接に引用するものであるから，本願の請求項７〜本願の請求項１０に係る発明は，上記において検討した［相違点１］，及び，［相違点２］に係る構成を有するものである。
　したがって，本願の請求項７〜本願の請求項１０に係る発明は，引用発明，引用刊行物２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
３．本願の請求項１１〜本願の請求項１４に係る発明について
　本願の請求項１１に係る発明は，発明のカテゴリが相違するものの，本願発明とほぼ同等の構成を有するものであり，本願の請求項１２〜本願の請求項１４は，本願の請求項１１を直接・間接に引用するものであるから，本願の請求項１１〜本願の請求項１４に係る発明は，上記において検討した［相違点１］，及び，［相違点２］に係る構成を有するものである。
　したがって，本願の請求項１１〜本願の請求項１４に係る発明は，引用発明，引用刊行物２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
第８．原審拒絶査定の概要及び原審拒絶査定についての判断
　原審における平成２８年７月２６日付けの拒絶査定（以下，これを「原審拒絶査定」という）は，本願の請求項１〜本願の請求項１７について，引用刊行物１，及び，引用刊行物２に基づいて、当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができないというものである。
　しかしながら、本件手続補正により補正された請求項１〜請求項１４は，それぞれ，上記において検討した，［相違点１］，及び，［相違点２］に係る構成を有するものとなっている。
　よって，本願の請求項１〜本願の請求項１４に係る発明は，引用発明，及び，引用刊行物２に記載の技術的事項に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持することはできない。
　
第９．当審拒絶理由について
　当審における平成２９年８月２８日付けの拒絶理由（以下，これを「当審拒絶理由」という）は，次のとおりである。
　
「１．３６条６項２号について 
 （１）本願の請求項１に， 
 「前記第１のプロバイダー・キーは，前記患者に対応する患者キーから生成される，前記第１の電子健康記録のための第１のレコード・キーを生成するステップ」， 
 　と記載されているが，上記引用の記載内容は， 
 “患者キーのみから，第１のプロバイダー・キーを生成する”， 
 　という態様を含むものである。 
 　それでは，どのようにして，“患者キーのみから，第１のプロバイダー・キーを生成する”を実現しているのか，本願の請求項１に記載の内容，及び，本願の他の請求項に記載の内容を検討しても，不明である。 
 　 
 （２）本願の請求項２〜本願の請求項７は，本願の請求項１を直接・間接に引用するものであるから，上記（１）において指摘の明確でない構成を内包し，かつ，本願の請求項２〜本願の請求項７に記載の内容を検討しても，上記（１）において指摘の明確でない構成が明確になるものではない。 
 　加えて，本願の請求項４に， 
 「第２のプロバイダー・キーが，前記患者キーから生成される」， 
 　と記載されているが，上記引用の記載内容は， 
 “患者キーのみから，第２のプロバイダー・キーが生成される”， 
 　という態様を含むものである。 
 　それでは，どのようにして，“患者キーのみから，第２のプロバイダー・キーを生成する”を実現しているのか，願の請求項４に記載の内容，及び，本願の他の請求項に記載の内容を検討しても，不明である。 
 　 
 （３）本願の請求項８は，独立請求項である。 
 　ここで，本願の請求項８に，「第１のプロバイダー・キー」と記載されているが，本願の請求項８に記載の「第１のプロバイダー・キー」と，本願の請求項１に記載の「第１のプロバイダー・キー」との関係が，本願の請求項各項の記載内容を検討しても，不明である。 
 　仮に，本願の請求項８に記載の「第１のプロバイダー・キー」と，本願の請求項１に記載の「第１のプロバイダー・キー」とが，異なるものであるとすると，本願の請求項８に記載の「第１のプロバイダー・キー」が，何処から，或いは，どのようにして，もたらされたものであるか，不明である。 
 　 
 （４）本願の請求項９，及び，本願の請求項１０は，本願の請求項８を直接・間接に引用するものであるから，上記（３）において指摘の明確でない構成を内包し，かつ，本願の請求項９，及び，本願の請求項１０に記載の内容を検討しても，上記（３）において指摘の明確でない構成が明確になるものではない。 
 　 
 （５）本願の請求項１３は，独立請求項である。 
 　本願の請求項１３に記載された，「第１のプロバイダー・キー」と，本願の請求項１に記載された，「第１のプロバイダー・キー」と，本願の請求項８に記載された，「プロバイダー・キー」との関係が，本願の請求項各項の記載内容からは，不明である。 
 　仮に，本願の請求項１３に記載の「第１のプロバイダー・キー」と，本願の請求項１に記載の「第１のプロバイダー・キー」とが，異なるものであるとすると，本願の請求項１３に記載の「第１のプロバイダー・キー」が，何処から，或いは，どのようにして，もたらされたものであるか，不明である。 
 　 
 （６）本願の請求項１４〜本願の請求項１６は，本願の請求項１３を直接・間接に引用するものであるから，上記（５）において指摘の明確でない構成を内包し，かつ，本願の請求項１４〜本願の請求項１６に記載の内容を検討しても，上記（５）において指摘の明確でない構成が明確になるものではない。 
 　 
 （７）以上，上記（１）〜（６）において検討したとおりであるから，本願の請求項１〜本願の請求項１０，及び，本願の請求項１３〜本願の請求項１６に係る発明は，明確ではない。 
 　 
 ２．３６条４項１号について 
 （１）本願の請求項１に記載の， 
 「前記第１のプロバイダー・キーは，前記患者に対応する患者キーから生成される，前記第１の電子健康記録のための第１のレコード・キーを生成するステップ」， 
 　は， 
 “患者キーのみに基づいてプロバイダー・キーを生成する” 
 　という態様を含むものである。 
 　この点に関して， 
 　本願明細書の発明の詳細な説明には，段落【０００８】に， 
 「プロバイダー・キー及びレコード・キーは，患者キーに基づいて生成されることから」， 
 　という記載が存在するのみであり，上記引用の記載以外は，段落【０００６】に， 
 「プロバイダー・キーは，患者の対応する患者キー（本明細書では，Ｋpatientと呼ばれる）及びプロバイダー識別子（本明細書では，プロバイダーＩＤと呼ばれる）に基づいて生成される。」 
 　段落【００１１】に， 
 「用語「プロバイダー・キー」は，患者キー及びプロバイダー識別子に基づいて生成された暗号化キーを意味する。」 
 　段落【００１６】に， 
 「各プロバイダーＩＤは，そのプロバイダーの各患者についてプロバイダー・キー（Ｋpatient, provider）を生成する際に，患者キーと組み合わせて使用されることがある情報を表す。」 
 　段落【００１７】に， 
 「患者システム２０又は他の適当な処理システム（図示せず）は，患者キー２２及び対応するプロバイダーＩＤ３１に基づいて，患者１２のための固有のプロバイダー・キー３２を生成する。例えば，患者システム２０は，患者キー２２及びプロバイダーＩＤ３１（１）に基づいてプロバイダー・キー３２（１）を生成し，スマートカード又は通信ネットワーク６０のような任意の適当な安全な手段により，プロバイダー・キー３２（１）をプロバイダー・システム３０（１）に提供する。一実施形態において，患者システム２０は，暗号化キーと，プロバイダー・キー３２を患者キー２２及び対応するプロバイダＩＤ３１の関数として生成する一方向ハッシュ関数とを使用して，各プロバイダーについてプロバイダー・キー３２を生成する。他の実施形態では，他の適当な関数を使用して，患者キー２２及びプロバイダーＩＤ３１に基づいてプロバイダー・キー３２を生成する場合がある。」 
 　と記載されていて，本願明細書の発明の詳細な説明には，「プロバイダー・キー」を，「患者キー」，及び，「プロバイダーＩＤ」に基づいて生成することは，ある程度開示されているものの，「患者キー」のみで，「プロバイダー・キー」を生成する点については，その態様を含む記載が，上記引用の段落【０００８】に存在するのみであり，本願明細書の発明の詳細な説明からは，どのようにして，“患者キーのみに基づいてプロバイダー・キーを生成する”のか，不明である。 
 　 
 （２）本願の請求項４に記載の， 
 「第２のプロバイダー・キーが，前記患者キーから生成される」， 
 　は， 
 “第２のプロバイダー・キーが，患者キーのみから生成される”， 
 　という態様を含むものである。 
 　しかしながら，「プロバイダー・キー」の生成に関しては，上記（１）において検討したとおりであるから，本願明細書の発明の詳細な説明からは，どのようにして，“第２のプロバイダー・キーが，患者キーのみから生成される”のか，不明である。 
 　 
 （３）以上，上記（１），及び，（２）において検討したとおりであるから，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。」
　
　上記当審拒絶理由は，本件手続補正における補正によって，全て解消している。
　
第10．むすび
　以上のとおり，本願の請求項１〜本願の請求項１４に係る発明は，当業者が引用発明，及び，引用刊行物２に記載された技術的事項に基づいて容易に発明をすることができたものではない。
　したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。