• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 特36条4項詳細な説明の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1336548
審判番号 不服2016-15585  
総通号数 219 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-03-30 
種別 拒絶査定不服の審決 
審判請求日 2016-10-19 
確定日 2018-02-06 
事件の表示 特願2015-527433「記録のための暗号化データ記憶装置」拒絶査定不服審判事件〔平成26年 2月20日国際公開,WO2014/028035,平成27年 9月 7日国内公表,特表2015-526048,請求項の数(14)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1.手続の経緯
本願は,2012年8月30日(パリ条約による優先権主張外国庁受理2012年8月15日 アメリカ合衆国)を国際出願日とする出願であって,
平成27年3月4日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成28年2月15日付けで審査官により拒絶理由が通知され,これに対して平成28年4月26日付けで意見書が提出されると共に手続補正がなされたが,平成28年7月26日付けで審査官により拒絶査定がなされ,これに対して平成28年10月19日付けで審判請求がなされると共に手続補正がなされ,平成28年11月25日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成29年4月13日付けで上申書が提出され,平成29年8月28日付けで当審により審判請求時の手続補正が却下されると共に拒絶理由が通知され,これに対して平成29年11月24日付けで意見書が提出されると共に手続補正がなされたものである。

第2.本願発明について
本願の請求項1?本願の請求項14に係る発明は,平成29年11月24日付けの手続補正(以下,これを「本件手続補正」という)により補正された特許請求の範囲の請求項1?請求項14に記載された,次のとおりのものである。

「【請求項1】
処理システムにより実施される方法であって,
患者のメタデータ・ツリー上の第1の電子健康記録の第1の位置を判定するステップと,
前記第1の位置と,第1のプロバイダーに対応する第1のプロバイダー・キーとに基づいて,前記第1の電子健康記録のための第1のレコード・キーを生成するステップであって,前記第1のプロバイダー・キーは,前記患者に対応する患者キーと,前記第1のプロバイダーに対応する第1のプロバイダー識別子とに基づいて生成される,前記第1の電子健康記録のための第1のレコード・キーを生成するステップと,
前記第1のレコード・キーを使用して前記第1の電子健康記録を暗号化し,第1の暗号化電子健康記録を生成するステップと,
前記第1の暗号化電子健康記録を暗号化データ記憶装置に提供するステップと
を含む方法。
【請求項2】
前記暗号化データ記憶装置上の前記第1の暗号化電子健康記録への第1の参照を含むように,前記メタデータ・ツリー上の前記第1の位置を更新するステップと,
前記メタデータ・ツリーを,第2のプロバイダーによりアクセス可能なメタデータ記憶装置に提供するステップと
をさらに含む,請求項1に記載の方法。
【請求項3】
前記メタデータ・ツリー上の第2の位置が,前記暗号化データ記憶装置上の第2の暗号化電子健康記録への第2の参照を含み,前記第2の暗号化電子健康記録は,前記第2のプロバイダーにより生成され,前記第2のプロバイダーは,前記第1のプロバイダーとは提携していない,請求項2に記載の方法。
【請求項4】
前記第2の暗号化電子健康記録のための第2のレコード・キーを受け取るステップであって,前記第2のレコード・キーが,前記第2の参照を含む前記メタデータ・ツリー上の前記第2の位置と,前記第2のプロバイダーに対応する第2のプロバイダー・キーとに基づいて生成され,前記第2のプロバイダー・キーが,前記患者キーと,前記第2のプロバイダーに対応する第2のプロバイダー識別子とから生成される,前記第2の暗号化電子健康記録のための第2のレコード・キーを受け取るステップと,
前記暗号化データ記憶装置から前記第2の暗号化電子健康記録を取得するステップと,
前記第2のレコード・キーを使用して前記第2の暗号化電子健康記録の暗号化を解除するステップと
をさらに含む,請求項3に記載の方法。
【請求項5】
前記患者の前記メタデータ・ツリー上の第2の電子健康記録の第2の位置を判定するステップと,
前記第2の位置と,前記第1のプロバイダー・キーとに基づいて,前記第2の電子健康記録のための第2のレコード・キーを生成するステップと,
前記第2のレコード・キーを使用して前記第2の電子健康記録を暗号化し,第2の暗号化電子健康記録を生成するステップと,
前記第2の暗号化電子健康記録を前記暗号化データ記憶装置に提供するステップと
をさらに含む,請求項1に記載の方法。
【請求項6】
前記第1のレコード・キーが,前記第2のレコード・キーとは異なり,前記第1のレコード・キーは,前記第2の暗号化電子健康記録の暗号解除には使用できず,前記第2のレコード・キーは,前記第1の暗号化電子健康記録の暗号解除には使用できない,請求項5に記載の方法。
【請求項7】
処理システムであって,
一組の一以上のプロセッサと,
一組の命令を記憶するメモリであって,前記一組の命令が,前記一組のプロセッサにより実行されたときに,前記一組のプロセッサに,
暗号化データ記憶装置上の第1の暗号化電子健康記録に対応する,患者のメタデータ・ツリー上の第1の位置を判定させ,
前記第1の位置と,第1のプロバイダーに対応する第1のプロバイダー・キーとに基づいて,前記第1の暗号化電子健康記録のための第1のレコード・キーを生成させ,前記第1のプロバイダー・キーは,前記患者に対応する患者キーと,前記第1のプロバイダーに対応する第1のプロバイダー識別子とに基づいて生成され,
前記暗号化データ記憶装置上の前記第1の暗号化電子健康記録への第1の参照を使用して,前記暗号化データ記憶装置から前記第1の暗号化電子健康記録を取得させ,前記第1の参照が,前記メタデータ・ツリー上の前記第1の位置に含まれ,
前記第1のレコード・キーを使用して前記第1の暗号化電子健康記録の暗号化を解除させるように構成される,一組の命令を記憶するメモリと
を含む処理システム。
【請求項8】
前記メタデータ・ツリー上の第2の位置は,前記暗号化データ記憶装置上の第2の暗号化電子健康記録への第2の参照を含み,前記第2の暗号化電子健康記録は,第2のプロバイダーにより生成され,前記第2のプロバイダーは,前記第1のプロバイダーとは提携していない,請求項7に記載の処理システム。
【請求項9】
前記第1のレコード・キーは,前記第2の暗号化電子健康記録の暗号解除には使用できず,第2のレコード・キーは,前記第2の暗号化電子健康記録の暗号解除に使用可能であり,前記第2のレコード・キーは,前記第1の暗号化電子健康記録の暗号解除には使用できない,請求項8に記載の処理システム。
【請求項10】
前記一組の命令が,前記一組のプロセッサにより実行されたときに,前記一組のプロセッサに,前記患者,前記第1のプロバイダー,及び,前記第1のプロバイダーとは提携していない第2のプロバイダーによってアクセス可能なメタデータ記憶装置から前記メタデータ・ツリーを取得させるように構成される,請求項7に記載の処理システム。
【請求項11】
命令が記憶された機械読取可能な記憶媒体であって,前記命令が,処理システムにより実行されたときに,前記処理システムに,
第1のプロバイダーにより生成された暗号化データ記憶装置上の第1の暗号化電子健康記録に対応する患者のメタデータ・ツリー上の第1の位置を判定させ,
前記第1の暗号化電子健康記録のための第1のレコード・キーであって,前記第1の位置と,前記第1のプロバイダーに対応する第1のプロバイダー・キーとに基づいて生成された第1のレコード・キーを受信させ,前記第1のプロバイダー・キーは,前記患者に対応する患者キーと,前記第1のプロバイダーに対応する第1のプロバイダー識別子とに基づいて生成され,
前記暗号化データ記憶装置上の前記第1の暗号化電子健康記録への第1の参照を使用して,前記暗号化データ記憶装置から前記第1の暗号化電子健康記録を取得させ,前記第1の参照が,前記メタデータ・ツリー上の前記第1の位置に含まれ,
第2のプロバイダーにより,前記第1のレコード・キーを使用して,前記第1の暗号化電子健康記録の暗号化を解除させるように構成される,機械読取可能な記憶媒体。
【請求項12】
前記メタデータ・ツリー上の第2の位置は,前記暗号化データ記憶装置上の第2の暗号化電子健康記録への第2の参照を含み,前記第2の暗号化電子健康記録は,前記第2のプロバイダーにより生成され,前記第2のプロバイダーは,前記第1のプロバイダーとは提携していない,請求項11に記載の機械読取可能な記憶媒体。
【請求項13】
前記第1のレコード・キーは,前記第2の暗号化電子健康記録の暗号解除には使用できず,第2のレコード・キーは,前記第2の暗号化電子健康記録の暗号解除に使用可能であり,前記第2のレコード・キーは,前記第1の暗号化電子健康記録の暗号解除には使用できない,請求項12に記載の機械読取可能な記憶媒体。
【請求項14】
前記命令が,前記処理システムにより実行されたときに,前記処理システムに,
前記第1のレコード・キーを前記第1のプロバイダーまたは前記患者に要求させ,
前記第1のプロバイダーまたは前記患者から前記第1のレコード・キーを受信させるように構成される,請求項11に記載の機械読取可能な記憶媒体。」

第3.引用刊行物に記載の事項
1.原審における平成28年2月15日付けの拒絶理由(以下,これを「原審拒絶理由」という)に引用された,本願の第1国出願前に既に公知である,特表2005-539423号公報(公表日;2005年12月22日,以下,これを「引用刊行物1」という)には,関連する図面と共に,次の事項が記載されている。

A.「【請求項1】
ツリー構造のメタデータ暗号化方法において,
前記ツリー構造のメタデータの所定ノードでの情報を暗号化するために,上位ノードの暗号化キー及び前記所定ノードを特定する情報を入力値とする関数を使用して前記所定ノードでの暗号化キーを生成する段階と,
前記生成された暗号化キーを使用して前記所定ノードでの情報を暗号化する段階と,を含むことを特徴とする暗号化方法。」

B.「【0042】
図5は,本発明によるメタデータの保護及び管理方法を説明するためのツリー構造で表現されたメタデータを示す。図5のツリー構造で表示されたメタデータは,図3のXｒMLで表現されたメタデータと同一である。」

C.「【0047】
ノードAでの情報は,高級暗号標準(AES)のような暗号化アルゴリズムを使用して暗号化キーKEY_Aによって暗号化される。本実施例では暗号化アルゴリズムとしてAESを使用したが,選択的に任意の暗号化アルゴリズムを使用することもできる。
【0048】
また,ノードAの子ノードであるノードBの情報は,次の式(1)により求められるKeｙ_Bを使用して暗号化される。
【0049】
Keｙ_B=F(Keｙ_A,Infｏ_B) (1)
ここで,Infｏ_BはノードBの位置情報である。また,Fは逆方向に計算が不可能なハッシュ関数のような一方向関数である。すなわち,式(1)を使用してKeｙ_A及びInfｏ_BからKeｙ_Bを計算することは可能であるが,Keｙ_B及びInfｏ_Bを知っているとしてもKeｙ_Aを計算することは不可能である。
【0050】
本実施例では位置情報として該当ノードの絶対位置情報を使用したが,選択的に相対位置情報または該当ノードを特定できるインデックス情報を使用することもできる。例えば,絶対位置情報を使用する場合,Infｏ_Bは1であり,ノードDの絶対位置情報Infｏ_Dは2であり,それ以外の他のノードの絶対位置情報であるInfｏ_C1,Infｏ_C2,Infｏ_E1,Infｏ_E2,Infｏ_F1,及びInfｏ_F2はそれぞれ3,4,5,6,7,及び8の値を持つ。
【0051】
また,ノードBの子ノードのうち一つであるノードC1の情報は次の式(2)により暗号化される。
【0052】
Keｙ_C1=F(Keｙ_B,Infｏ_C1) (2)
ここで,Infｏ_C1はノードC1の相対的な位置または絶対的な位置であり,式(1)と同じく関数Fは一方向関数である。すなわち,式(2)を使用してKeｙ_B及びInfｏ_C1からKeｙ_C1を計算することは可能であるが,Keｙ_C1及びInfｏ_C1を知っているとしてもKeｙ_Bを計算することは不可能である。」

D.「【0061】
このように,本発明によるメタデータ暗号化保護及び管理方法では一方向関数を使用して,親ノードのキー情報及び該当ノードの位置情報から該当ノードのキー情報を生成する。」

E.「【0093】
本発明のさらに他の実施例によれば,メタデータのうち属性値のみを暗号化する。すなわち,位置情報及び属性名称は暗号化しない。このように,位置情報及び属性名称を暗号化しないことによって,XML全体ツリーを復号する必要なくXMLツリーの所定のサブブランチのみを容易に復号化できる。」

F.「【図6】

」

2.原審拒絶理由に引用された,本願の第1国出願前に既に公知である,米国特許出願公開第2003/0200213号明細書(公開日;2003年10月23日,以下,これを「引用刊行物2」という)には,関連する図面と共に,次の事項が記載されている。

G.「[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] 独創的な,適応データ管理(ADM)方法,及び,システムに従って,静的データベース・モデルが,標準的な,フロント-エンド・コンポーネント・インタフェースによって,大容量のデータの操作のために提供され,最適化され,それによって,コストの情報の,時間の情報を削減しつつ,データベースのデザインと,データのアクセスを簡略化する。更に,そのモデルは,全てのデータベースの動作をモニタするために,多数の,資格のある技術職員を要求せず,収集されるデータは,モデルのメタデータとして,書式と関係性の両方おいて記述され,そして,ユーザ・データ(インスタンス・データ)は,次に,メタデータによって定義される書式を用いて,収集され,格納される。試験において,その独創的な方法,及び,システムは,ウェブ・サイトなどのアプリケーションの下で有益な,多数の記録の管理,及び,文書のインデックス化における,成功を示した。ADMデータ・ストレージの本質に起因して,データは,データ・ウェアハウス化されたデータベースへの組み入れ前に,洗浄されないことを,ほとんど要求しない。

[0013] ADMは,識別認証と,多層化されたアクセス制御が要求されるゲートウェイを通じて,アクセス保護と,アクセス追跡,データの安全性と完全性の確保を提供する。ADMは,マルチユーザ・アクセスと,同時並行性を管理する。

[0014] ADMは,そのデザインに加わる,14か,それ以上の数のオブジェクトで,データ・ストレージ・サポートを提供するために,種々のプラットフォーム上で動作している,オラクルデータベースと共に用いられ得る。

[0015] ADMは,バック-エンド情報格納基盤,及び,データ・ストレージための,柔軟な,開発環境の両方を提供する。ADMは,メタデータ・モデルに基づいている。データ自身(メタデータ)の組織は,データの全ての収集に先だって,ADMに説明される。メタデータ・モデルは,これらメタデータ要素の互いの関係性だけでなく,メタデータ要素の定義も含んでいる。データ要素は,それ故に,データ・モデルの全ての可能な表現が許可されるような,例えば,データ要素が,高々,1つの親データ要素を持つような,木として,或いは,データ要素が,例えば,1つ,或いは,複数の親データ要素を持つような,グラフとして組織化される。<当審にて訳出。以下,同じ。>)

H.「[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.」
(メタデータは,どのようにデータが収集されるかが形式的に定義されている構造である。このインターフェースは,完全に,管理である:ADM管理ユーティリティのみが,このインターフェースを使用する。不慣れな,このインターフェースの使用は,存在するデータ要素に,悪影響を及ぼすことに留意されたい。)

I.「[0070] These interfaces allow management of information related to user, security and user access rights.」
(これらのインターフェースは,ユーザに関連した情報,セキュリティ,及び,ユーザ・アクセス権限の管理を許可されている。)

J.「【図3】

」

K.「【図4】

」

第4.引用刊行物に記載の発明
1.上記Aの「ツリー構造のメタデータ暗号化方法において」という記載から,引用刊行物1は,
“ツリー構造のメタデータ暗号化方法”
に関するものであることが読み取れる。

2.上記Aの「ツリー構造のメタデータの所定ノードでの情報を暗号化する」という記載,上記Cの「Infｏ_BはノードBの位置情報である」という記載,及び,同じく,上記Cの「本実施例では位置情報として該当ノードの絶対位置情報を使用した」という記載から,引用刊行物1においては,
“ツリー構造のメタデータの所定ノードでの位置情報が用いられる”
ことが読み取れる。

3.上記Aの「上位ノードの暗号化キー及び前記所定ノードを特定する情報を入力値とする関数を使用して前記所定ノードでの暗号化キーを生成する段階」という記載,上記Cの「Keｙ_B=F(Keｙ_A,Infｏ_B)(1)」という記載,同じく,上記Cの「式(1)を使用してKeｙ_A及びInfｏ_BからKeｙ_Bを計算する」という記載,及び,上記Dの「本発明によるメタデータ暗号化保護及び管理方法では一方向関数を使用して,親ノードのキー情報及び該当ノードの位置情報から該当ノードのキー情報を生成する」という記載と,上記Fに引用した【図6】に開示の事項から,引用刊行物1においては,
“所定ノードにおける,当該所定ノードの情報を暗号化するためのキー情報は,当該所定ノードの位置情報と,当該所定ノードの親ノードの鍵情報とから生成される”
ものであることが読み取れる。

4.上記Aの「生成された暗号化キーを使用して前記所定ノードでの情報を暗号化する段階」という記載,上記Cの「ノードAでの情報は,高級暗号標準(AES)のような暗号化アルゴリズムを使用して暗号化キーKEY_Aによって暗号化される」という記載と,上記2.において検討した事項から,引用刊行物1においては,
“所定のノードの情報は,当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される”
ことが読み取れる。

5.以上1.?4.において検討した事項から,引用刊行物1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

“ツリー構造のメタデータ暗号化方法であって,
ツリー構造のメタデータの所定ノードでの位置情報が用いられ,
前記所定ノードにおける,当該所定ノードの情報を暗号化するためのキー情報は,当該所定ノードの位置情報と,当該所定ノードの親ノードの鍵情報とから生成され,
前記所定のノードの情報は,当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される,方法。”

第5.本願の請求項1に係る発明(以下,これを「本願発明」という)と引用発明との対比
1.引用発明において,「メタデータ」の「暗号化」の処理は,何れかの“システム上”で実施されることは,明らかであるから,
引用発明における「ツリー構造のメタデータ暗号化方法」が,
本願発明における「処理システムにより実施される方法」に相当する。

2.引用発明における「メタデータの所定ノードでの位置情報」が,
本願発明における「第1の位置」に相当し,
引用発明における「所定ノードの情報」と,
本願発明における「第1の電子健康記録」とは,
“被暗号化情報”である点で共通し,
引用発明における「所定のノードの情報を暗号化するためのキー情報」と,
本願発明における「第1のレコードキー」とは,
“データ暗号化キー”である点で共通し,
引用発明における「親ノードの鍵情報」と,
本願発明における「第1のプロバイダーに対応する第1のプロバイダー・キー」とは,“データ暗号化キーを生成するためのキー情報”である点で共通するので,
引用発明における「所定ノードにおける,当該所定ノードの情報を暗号化するためのキー情報は,当該所定ノードの位置情報と,当該所定ノードの親ノードの鍵情報とから生成され」ることと,
本願発明における「第1の位置と,第1のプロバイダーに対応する第1のプロバイダー・キーとに基づいて,前記第1の電子健康記録のための第1のレコード・キーを生成するステップ」とは,
“第1の位置情報と,データ暗号化キーを生成するためのキー情報とに基づいて,被暗号化情報を暗号化するための前記データ暗号化キーを生成するステップ”
である点で共通する。

3.引用発明における「所定のノードの情報は,当該所定のノードの情報を暗号化するためのキー情報を使用して暗号化される」ことと,
本願発明における「第1のレコード・キーを使用して前記第1の電子健康記録を暗号化し,第1の暗号化電子健康記録を生成するステップ」とは,
“データ暗号化キーを使用して,被暗号化情報を暗号化し,第1の暗号化情報を生成するステップ”
である点で共通する。

4.以上,上記1.?3.において検討した事項から,本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
処理システムにより実施される方法であって,
第1の位置情報と,データ暗号化キーを生成するためのキー情報とに基づいて,被暗号化情報を暗号化するための前記データ暗号化キーを生成するステップと,
前記データ暗号化キーを使用して,被暗号化情報を暗号化し,前記第1の暗号化情報を生成するステップと,を含む方法。

[相違点1]
“データ暗号化キーを生成するためのキー情報”に関して,
本願発明においては,「第1のプロバイダーに対応する第1のプロバイダー・キー」であるのに対して,
引用発明においては,「所定ノードの親ノードの鍵情報」である点。

[相違点2]
本願発明においては,「第1のプロバイダー・キーは,前記患者に対応する患者キーと,前記第1のプロバイダーに対応する第1のプロバイダー識別子とに基づいて生成される」ものであるのに対して,
引用発明においては,「患者キー」,「プロバイダー識別子」に関する言及がない点。

[相違点3]
“被暗号化情報”に関して,
本願発明においては,「電子健康記録」であるのに対して,
引用発明においては,“ツリー構造の所定ノードの情報”であって,「電子健康記録」に対する言及がない点。

[相違点4]
本願発明においては,「第1の暗号化電子健康記録を暗号化データ記憶装置に提供するステップ」が存在しているのに対して,
引用発明においては,そのようなステップに関する言及がない点。

第6.相違点についての当審の判断
[相違点1],及び,[相違点2]について検討すると,「プロバイダー・キー」を用いること,及び,当該「プロバイダー・キー」を,「患者キー」と,「プロバイダー識別子」から生成することに関しては,引用刊行物2にも,記載されておらず,当該指摘の構成が,当業者とって自明の事項とも認められない。
したがって,[相違点3],及び,[相違点4]について判断するまでもなく,本願発明は,当業者であっても引用発明,引用刊行物2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第7.本願の請求項2?本願の請求項14に係る発明について
1.本願の請求項2?本願の請求項6に係る発明について
本願の請求項2?本願の請求項6は,本願の請求項1を直接・間接に引用するものであるから,本願の請求項2?本願の請求項6に係る発明は,上記において検討した[相違点1],及び,[相違点2]に係る構成を有するものである。
したがって,本願の請求項2?本願の請求項6に係る発明は,引用発明,引用刊行物2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願の請求項7?本願の請求項10に係る発明について
本願の請求項7に係る発明は,発明のカテゴリが相違するものの,本願発明とほぼ同等の構成を有するものであり,本願の請求項8?本願の請求項10は,本願の請求項7を直接・間接に引用するものであるから,本願の請求項7?本願の請求項10に係る発明は,上記において検討した[相違点1],及び,[相違点2]に係る構成を有するものである。
したがって,本願の請求項7?本願の請求項10に係る発明は,引用発明,引用刊行物2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.本願の請求項11?本願の請求項14に係る発明について
本願の請求項11に係る発明は,発明のカテゴリが相違するものの,本願発明とほぼ同等の構成を有するものであり,本願の請求項12?本願の請求項14は,本願の請求項11を直接・間接に引用するものであるから,本願の請求項11?本願の請求項14に係る発明は,上記において検討した[相違点1],及び,[相違点2]に係る構成を有するものである。
したがって,本願の請求項11?本願の請求項14に係る発明は,引用発明,引用刊行物2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第8.原審拒絶査定の概要及び原審拒絶査定についての判断
原審における平成28年7月26日付けの拒絶査定(以下,これを「原審拒絶査定」という)は,本願の請求項1?本願の請求項17について,引用刊行物1,及び,引用刊行物2に基づいて、当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができないというものである。
しかしながら、本件手続補正により補正された請求項1?請求項14は,それぞれ,上記において検討した,[相違点1],及び,[相違点2]に係る構成を有するものとなっている。
よって,本願の請求項1?本願の請求項14に係る発明は,引用発明,及び,引用刊行物2に記載の技術的事項に基づいて,当業者が容易に発明できたものではない。
したがって,原査定を維持することはできない。

第9.当審拒絶理由について
当審における平成29年8月28日付けの拒絶理由(以下,これを「当審拒絶理由」という)は,次のとおりである。

「1.36条6項2号について
(1)本願の請求項1に,
「前記第1のプロバイダー・キーは,前記患者に対応する患者キーから生成される,前記第1の電子健康記録のための第1のレコード・キーを生成するステップ」,
と記載されているが,上記引用の記載内容は,
“患者キーのみから,第1のプロバイダー・キーを生成する”,
という態様を含むものである。
それでは,どのようにして,“患者キーのみから,第1のプロバイダー・キーを生成する”を実現しているのか,本願の請求項1に記載の内容,及び,本願の他の請求項に記載の内容を検討しても,不明である。

(2)本願の請求項2?本願の請求項7は,本願の請求項1を直接・間接に引用するものであるから,上記(1)において指摘の明確でない構成を内包し,かつ,本願の請求項2?本願の請求項7に記載の内容を検討しても,上記(1)において指摘の明確でない構成が明確になるものではない。
加えて,本願の請求項4に,
「第2のプロバイダー・キーが,前記患者キーから生成される」,
と記載されているが,上記引用の記載内容は,
“患者キーのみから,第2のプロバイダー・キーが生成される”,
という態様を含むものである。
それでは,どのようにして,“患者キーのみから,第2のプロバイダー・キーを生成する”を実現しているのか,願の請求項4に記載の内容,及び,本願の他の請求項に記載の内容を検討しても,不明である。

(3)本願の請求項8は,独立請求項である。
ここで,本願の請求項8に,「第1のプロバイダー・キー」と記載されているが,本願の請求項8に記載の「第1のプロバイダー・キー」と,本願の請求項1に記載の「第1のプロバイダー・キー」との関係が,本願の請求項各項の記載内容を検討しても,不明である。
仮に,本願の請求項8に記載の「第1のプロバイダー・キー」と,本願の請求項1に記載の「第1のプロバイダー・キー」とが,異なるものであるとすると,本願の請求項8に記載の「第1のプロバイダー・キー」が,何処から,或いは,どのようにして,もたらされたものであるか,不明である。

(4)本願の請求項9,及び,本願の請求項10は,本願の請求項8を直接・間接に引用するものであるから,上記(3)において指摘の明確でない構成を内包し,かつ,本願の請求項9,及び,本願の請求項10に記載の内容を検討しても,上記(3)において指摘の明確でない構成が明確になるものではない。

(5)本願の請求項13は,独立請求項である。
本願の請求項13に記載された,「第1のプロバイダー・キー」と,本願の請求項1に記載された,「第1のプロバイダー・キー」と,本願の請求項8に記載された,「プロバイダー・キー」との関係が,本願の請求項各項の記載内容からは,不明である。
仮に,本願の請求項13に記載の「第1のプロバイダー・キー」と,本願の請求項1に記載の「第1のプロバイダー・キー」とが,異なるものであるとすると,本願の請求項13に記載の「第1のプロバイダー・キー」が,何処から,或いは,どのようにして,もたらされたものであるか,不明である。

(6)本願の請求項14?本願の請求項16は,本願の請求項13を直接・間接に引用するものであるから,上記(5)において指摘の明確でない構成を内包し,かつ,本願の請求項14?本願の請求項16に記載の内容を検討しても,上記(5)において指摘の明確でない構成が明確になるものではない。

(7)以上,上記(1)?(6)において検討したとおりであるから,本願の請求項1?本願の請求項10,及び,本願の請求項13?本願の請求項16に係る発明は,明確ではない。

2.36条4項1号について
(1)本願の請求項1に記載の,
「前記第1のプロバイダー・キーは,前記患者に対応する患者キーから生成される,前記第1の電子健康記録のための第1のレコード・キーを生成するステップ」,
は,
“患者キーのみに基づいてプロバイダー・キーを生成する”
という態様を含むものである。
この点に関して,
本願明細書の発明の詳細な説明には,段落【0008】に,
「プロバイダー・キー及びレコード・キーは,患者キーに基づいて生成されることから」,
という記載が存在するのみであり,上記引用の記載以外は,段落【0006】に,
「プロバイダー・キーは,患者の対応する患者キー(本明細書では,Kpatientと呼ばれる)及びプロバイダー識別子(本明細書では,プロバイダーIDと呼ばれる)に基づいて生成される。」
段落【0011】に,
「用語「プロバイダー・キー」は,患者キー及びプロバイダー識別子に基づいて生成された暗号化キーを意味する。」
段落【0016】に,
「各プロバイダーIDは,そのプロバイダーの各患者についてプロバイダー・キー(Kpatient, provider)を生成する際に,患者キーと組み合わせて使用されることがある情報を表す。」
段落【0017】に,
「患者システム20又は他の適当な処理システム(図示せず)は,患者キー22及び対応するプロバイダーID31に基づいて,患者12のための固有のプロバイダー・キー32を生成する。例えば,患者システム20は,患者キー22及びプロバイダーID31(1)に基づいてプロバイダー・キー32(1)を生成し,スマートカード又は通信ネットワーク60のような任意の適当な安全な手段により,プロバイダー・キー32(1)をプロバイダー・システム30(1)に提供する。一実施形態において,患者システム20は,暗号化キーと,プロバイダー・キー32を患者キー22及び対応するプロバイダID31の関数として生成する一方向ハッシュ関数とを使用して,各プロバイダーについてプロバイダー・キー32を生成する。他の実施形態では,他の適当な関数を使用して,患者キー22及びプロバイダーID31に基づいてプロバイダー・キー32を生成する場合がある。」
と記載されていて,本願明細書の発明の詳細な説明には,「プロバイダー・キー」を,「患者キー」,及び,「プロバイダーID」に基づいて生成することは,ある程度開示されているものの,「患者キー」のみで,「プロバイダー・キー」を生成する点については,その態様を含む記載が,上記引用の段落【0008】に存在するのみであり,本願明細書の発明の詳細な説明からは,どのようにして,“患者キーのみに基づいてプロバイダー・キーを生成する”のか,不明である。

(2)本願の請求項4に記載の,
「第2のプロバイダー・キーが,前記患者キーから生成される」,
は,
“第2のプロバイダー・キーが,患者キーのみから生成される”,
という態様を含むものである。
しかしながら,「プロバイダー・キー」の生成に関しては,上記(1)において検討したとおりであるから,本願明細書の発明の詳細な説明からは,どのようにして,“第2のプロバイダー・キーが,患者キーのみから生成される”のか,不明である。

(3)以上,上記(1),及び,(2)において検討したとおりであるから,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。」

上記当審拒絶理由は,本件手続補正における補正によって,全て解消している。

第10.むすび
以上のとおり,本願の請求項1?本願の請求項14に係る発明は,当業者が引用発明,及び,引用刊行物2に記載された技術的事項に基づいて容易に発明をすることができたものではない。
したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2018-01-23 
出願番号 特願2015-527433(P2015-527433)
審決分類 P 1 8・ 536- WY (H04L)
P 1 8・ 537- WY (H04L)
P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 金沢 史明  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
佐久 聖子
発明の名称 記録のための暗号化データ記憶装置  
代理人 古谷 聡  
代理人 細井 玲  
代理人 西山 清春  
代理人 大西 昭広  

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