ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L |
---|---|
管理番号 | 1365860 |
審判番号 | 不服2018-16241 |
総通号数 | 250 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2020-10-30 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2018-12-06 |
確定日 | 2020-09-09 |
事件の表示 | 特願2015-531672「遠隔計算リソースにより分析される臨床データへのアクセス制御」拒絶査定不服審判事件〔平成26年 3月27日国際公開、WO2014/045173、平成27年11月26日国内公表、特表2015-534343〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1 手続の経緯 本件審判請求に係る出願(以下,「本願」という。)は,2013年9月13日(パリ条約による優先権主張外国庁受理2012年9月18日,アメリカ合衆国)を国際出願日とする出願であって,平成27年3月16日に特許法第184条の5第1項に規定される書面の提出がなされるとともに,特許法第184条の4第1項の規定による国際出願日における明細書,請求の範囲,図面(図面の中の説明に限る。)及び要約の翻訳文の提出がなされ,平成28年9月7日付けで審査請求がなされるとともに,同日付けで手続補正がなされ,平成29年9月28日付けで拒絶理由通知(同年10月3日発送)がなされ,平成30年3月15日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが,同年8月14日付けで拒絶査定(同年8月21日謄本送達)がなされた。 これに対して,「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」ことを請求の趣旨として,平成30年12月6日付けで本件審判請求がなされるとともに,同日付けで手続補正がなされ,平成31年1月24日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされた。 そして,令和元年8月27日付けで当審により拒絶理由通知(以下,「当審拒絶理由通知」という。)(同年8月29日発送)がなされ,令和2年2月17日付けで意見書が提出されるとともに,同日付けで手続補正がなされたものである。 第2 本願発明 本願の特許請求の範囲の請求項1に係る発明(以下,「本願発明」という。)は,上記令和2年2月17日付け手続補正書により補正された特許請求の範囲の記載からみて,その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。 「遠隔計算リソースにより処理されるデータへのアクセスを制御する方法において、 前記遠隔計算リソースの外側に位置する第1の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第1の暗号化鍵を作成するステップと、 前記遠隔計算リソースにより、前記データ作成部が前記暗号化鍵を作成するとき用いるデータを所有するデータ所有部との、前記データ作成部のエンカウンタを検出するステップと、 前記エンカウンタを検出することに基づき、前記遠隔計算リソースの第2の認証局により、前記データ作成部に関する第2の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップと、 前記第1の暗号化鍵、前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップと、 前記遠隔計算リソースの外側に位置する検証部による前記第1の暗号化鍵の検証、並びに前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも1つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップと、 前記データ所有部により、前記データ作成部の第1及び第2の暗号化鍵の少なくとも1つのパーミッションを変えることにより、前記データに対する前記データ作成部のアクセスを制御するステップとを有する、方法。」 第3 当審における拒絶の理由 当審における拒絶の理由(以下,「当審拒絶理由」という。)は,次のとおりである。 『本件出願は,発明の詳細な説明の記載が下記の点で不備のため,特許法第36条第4項第1号に規定する要件を満たしていない。 記 ア 請求項1について 請求項1は,その記載からして,次の事項(a),(b),(c),及び(d)を含んでいる。 (a)「前記遠隔計算リソースの外側に位置する第1の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第1の暗号化鍵を作成するステップ」 (b)「前記遠隔計算リソースの第2の認証局により、前記データ作成部に関する第2の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップ」 (c)「前記第1の暗号化鍵、前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 (d)「前記遠隔計算リソースの外側に位置する検証部による前記第1の暗号化鍵の検証、並びに前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも1つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップ」 ここで,出願当初の明細書を参照すると, 「【0024】 図4は、データ作成部からクラウドへとデータを送信する方法のフローチャート図を示す。ステップ100において、データ作成部は、認証局にパブリック暗号化鍵を要求する。データ作成部が作成されたデータを用いてシステムをサブスクライブするとき、この要求は作成される。ステップ102において、認証局は、データ作成部に対してパブリック鍵(PuK)を発行する。ステップ104において、エンカウンタが、データ所有部に関して作成される。ステップ106において、クラウドにおけるローカル認証局は、データ作成部及びデータ所有部に関するプライベート鍵(PrK)を作成する。ステップ108において、データが作成され、作成認証局パブリック鍵(PuK)並びにデータ作成部及びデータ所有部に関する両方のプライベート鍵(PrK)でエンコードされる。ステップ110において、データは、暗号化されて、クラウドに送信される。ステップ112において、クラウドは、パブリック鍵(PuK)に関する検証に基づき、並びにデータ作成部及びデータ所有部に関するプライベート鍵(PrK)に関する内部検証に基づき、データを復号化する。」, (当審注:下線は,参考のために当審で付与したものである。) と記載されており,請求項1に記載されている「遠隔計算リソース」,「第1の認証局」,「データ作成部」,「第1の暗号化鍵」,「第2の認証局」,「第2の暗号化鍵」,「データ所有部」,「暗号化鍵」は,それぞれ,上記段落【0024】に記載されている「クラウド」,「認証局」,「データ作成部」,「パブリック鍵(PuK)」,「ローカル認証局」,「プライベート鍵(PrK)」,「データ所有部」,「プライベート鍵(PrK)」に対応しているものと認められる。 そうすると,上記(a),上記(b),上記(c),及び上記(d)の具体的な実施例は, (a’)「前記クラウドの外側に位置する認証局により,クラウドにより処理されるデータを作成するデータ作成部に関するパブリック鍵(PuK)を作成するステップ」 (b’)「前記クラウドのローカル認証局により,前記データ作成部に関するプライベート鍵(PrK)及び前記データ所有部に関するプライベート鍵(PrK)を作成するステップ」 (c’)「前記パブリック鍵(PuK),前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)で,前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 (d’)「前記クラウドの外側に位置する検証部による前記パブリック鍵(PuK)の検証,並びに前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)の少なくとも1つの検証に基づき,前記クラウドで,前記データを復号化し,及び格納するステップ」 であると理解されるところ, (1)上記(c’)において,「パブリック鍵(PuK)」,「データ作成部のプライベート鍵(PrK)」,及び「データ所有部のプライベート鍵(PrK)」を用いて,データ作成部がデータをどのように暗号化するのか不明であり, (2)上記(c’)において,「前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)で,前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化する」と記載されているが,「前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)」で暗号化するとはどのようなことを意味しているのか不明,(通常,公開暗号鍵方式では,送信者は公開鍵で暗号化を行い,受信者は当該公開鍵に対応する秘密鍵で復号化を行うものであるところ,送信者がプライベート鍵で暗号化する理由が意味不明)であり, (3)上記(d’)において,「前記クラウドの外側に位置する検証部による前記パブリック鍵(PuK)の検証」とは,パブリック鍵(PuK)の何を検証するのか不明であり, (4)上記(d’)において,「前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)の少なくとも1つの検証」とは,何をどのように検証するのか不明(上記(2)にも記載したが,公開暗号鍵方式において,送信者がプライベート鍵で暗号化する理由が意味不明であるところ,暗号化されたものを受信者がどのように検証するのかも不明)であり, (5)上記(d’)において,「前記クラウドで,前記データを復号化」する際には,「パブリック鍵(PuK)」に対応する「プライベート鍵(PrK)」が必要となるところ,クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵(PuK)」に対応する「プライベート鍵(PrK)」を,クラウドがどのように入手できたのか不明である。 してみると,本願の発明の詳細な説明は,当業者が請求項1に係る発明を実施することができる程度に明確かつ十分に記載されていない。 (中略) キ 請求項8について 請求項8記載の発明は,請求項1記載の発明をシステムの発明として特定したものであることから,上記「ア 請求項1について」の上記(1)ないし上記(5)の検討結果と同様に不明である。 してみると,本願の発明の詳細な説明は,当業者が請求項8に係る発明を実施することができる程度に明確かつ十分に記載されていない。 (以下略)』 第4 当審の判断 1 実施可能要件(特許法第36条第4項第1号)について ア 特許法第36条第4項は,「前項第三号の発明の詳細な説明の記載は,次の各号に適合するものでなければならない。」と記載され,その第1号において,「経済産業省令で定めるところにより,その発明の属する技術の分野における通常の知識を有する者が容易にその実施をすることができる程度に,明確かつ十分に記載しなければならない。」と規定している。同号は,明細書のいわゆる実施可能要件を規定したものであって,方法の発明では,その方法を実施するための具体的な記載が発明の詳細な説明にあるか,そのような記載がない場合には,明細書及び図面の記載及び出願時の技術常識に基づき,当業者が過度の試行錯誤や複雑高度な実験等を行う必要なく,その方法を実施することができる程度にその発明が記載されてなければならないと解される。 以下,この観点に立って,判断する。 イ 本願発明は,その記載からして,次の事項(a),(b),(c),及び(d)を含んでいる。 (a)「前記遠隔計算リソースの外側に位置する第1の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第1の暗号化鍵を作成するステップ」 (b)「前記遠隔計算リソースの第2の認証局により、前記データ作成部に関する第2の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップ」 (c)「前記第1の暗号化鍵、前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 (d)「前記遠隔計算リソースの外側に位置する検証部による前記第1の暗号化鍵の検証、並びに前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも1つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップ」 ウ そうすると,上記当審拒絶理由の第3アの(1)ないし(5)でも述べたとおり,本願発明は,下記の点で不明であり,発明の詳細な説明の記載は,本願発明の全体について,出願時の技術常識に基づき,当業者がその実施をすることができる程度に明確かつ十分に記載されたものではない。 すなわち, 上記(c)において,「第1の暗号化鍵」,「データ作成部の第2の暗号化鍵」,及び「データ所有部の暗号化鍵」という3つの暗号化鍵を用いてどのように暗号化するのか不明であり,下記エないしカに詳述したとおり,本願の発明の詳細な説明は,当該暗号化について,当業者が実施をすることができる程度に,明確かつ十分に記載されていないものであるところ, 上記(d)において,「遠隔計算リソース」で,上記(c)の3つの暗号化鍵で暗号化されたものをどのようにしてデータを復号化するのか不明であり,下記エないしカに詳述したとおり,本願の発明の詳細な説明は,当該復号化について,当業者が実施をすることができる程度に,明確かつ十分に記載されていない。 エ ここで,上記ウ記載の不明点について,出願当初の発明の詳細な説明における具体的な実施例と対比して検討する。 本願の発明の詳細な説明の段落【0024】には, 「【0024】 図4は、データ作成部からクラウドへとデータを送信する方法のフローチャート図を示す。ステップ100において、データ作成部は、認証局にパブリック暗号化鍵を要求する。データ作成部が作成されたデータを用いてシステムをサブスクライブするとき、この要求は作成される。ステップ102において、認証局は、データ作成部に対してパブリック鍵(PuK)を発行する。ステップ104において、エンカウンタが、データ所有部に関して作成される。ステップ106において、クラウドにおけるローカル認証局は、データ作成部及びデータ所有部に関するプライベート鍵(PrK)を作成する。ステップ108において、データが作成され、作成認証局パブリック鍵(PuK)並びにデータ作成部及びデータ所有部に関する両方のプライベート鍵(PrK)でエンコードされる。ステップ110において、データは、暗号化されて、クラウドに送信される。ステップ112において、クラウドは、パブリック鍵(PuK)に関する検証に基づき、並びにデータ作成部及びデータ所有部に関するプライベート鍵(PrK)に関する内部検証に基づき、データを復号化する。」 (当審注:下線は,参考のために当審で付与したものである。) と記載されており,本願発明に記載されている「遠隔計算リソース」,「第1の認証局」,「データ作成部」,「第1の暗号化鍵」,「第2の認証局」,「第2の暗号化鍵」,「データ所有部」,「暗号化鍵」は,それぞれ,上記段落【0024】に記載されている「クラウド」,「認証局」,「データ作成部」,「パブリック鍵(PuK)」,「ローカル認証局」,「プライベート鍵(PrK)」,「データ所有部」,「プライベート鍵(PrK)」に対応しているものと認められる。 オ したがって,本願発明の,上記(a),上記(b),上記(c),及び上記(d)について,発明の詳細な説明における具体的な実施例は, (a’)「前記クラウドの外側に位置する認証局により,クラウドにより処理されるデータを作成するデータ作成部に関するパブリック鍵(PuK)を作成するステップ」 (b’)「前記クラウドのローカル認証局により,前記データ作成部に関するプライベート鍵(PrK)及び前記データ所有部に関するプライベート鍵(PrK)を作成するステップ」 (c’)「前記パブリック鍵(PuK),前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)で,前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 (d’)「前記クラウドの外側に位置する検証部による前記パブリック鍵(PuK)の検証,並びに前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)の少なくとも1つの検証に基づき,前記クラウドで,前記データを復号化し,及び格納するステップ」 であると認められる。 カ そうすると,本願発明は,下記の点で不明であり,発明の詳細な説明の記載は,本願発明の全体について,出願時の技術常識に基づき,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 (ア)上記(c’)において,「パブリック鍵(PuK)」,「データ作成部のプライベート鍵(PrK)」,及び「データ所有部のプライベート鍵(PrK)」を用いて,データ作成部がデータを暗号化しているが,データ作成部がデータをどのように暗号化するのか不明である。 すなわち,当該技術分野において,秘密鍵(プライベート鍵)は,公開鍵を用いて暗号化されたものを復号化する際に用いるものであって,暗号化の際に用いるものではないにも関わらず,本願発明における暗号化ステップは,「前記第1の暗号化鍵、前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」と記載されるように,第1の暗号化鍵(パブリック鍵),データ作成部の第2の暗号化鍵(プライベート鍵)及びデータ所有部の暗号化鍵(プライベート鍵)を用いて暗号化しており,特に,2種類のプライベート鍵を用いて暗号化する点については,当業者にとって周知の事項ではなく,発明の詳細な説明の記載は,本願発明の暗号化がどのような処理で行われるのかについて,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 (イ)上記(d’)において,「前記クラウドの外側に位置する検証部による前記パブリック鍵(PuK)の検証」とは,「検証部」がどのようなものであるか不明であり,また該検証部において「パブリック鍵(PuK)」の何を検証するのか不明である。 すなわち,本願発明における「前記遠隔計算リソースの外側に位置する検証部による前記第1の暗号化鍵の検証」について,発明の詳細な説明には,段落【0020】に,「遠隔計算リソース14は、パブリック暗号化鍵22、健康プロバイダのプライベート暗号化鍵26及び/又は患者のプライベート暗号化鍵28の検証に基づき、臨床データを復号化する・・・特に、臨床及び結果データの復号化は、クラウドインフラストラクチャの外側に位置するパブリック検証部30(PuK Verification)によるパブリック暗号化鍵22の有効性の検証」と記載されているのみであり,遠隔計算リソースの外側に位置する「検証部」(本願の【図2】及び【図3】を参照すると,検証部30は,第1の認証局(パブリック認証局20)や第2の認証局(プライベート認証局24)とは異なる認証部となっている)がどのようなものであるか,またどのような有効性を検証するのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 (ウ)同じく上記(d’)において,「前記データ作成部のプライベート鍵(PrK)及び前記データ所有部のプライベート鍵(PrK)の少なくとも1つの検証」とは,何をどのように検証するのか不明である。 すなわち,上記(ア)にも述べたとおり,当該技術分野において,秘密鍵(プライベート鍵)は,公開鍵を用いて暗号化されたものを復号化する際に用いるものであって,暗号化の際に用いるものではないにも関わらず,本願発明には,「前記データ作成部の第2の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも1つの検証に基づき、前記遠隔計算リソースで、前記データを復号化」と記載されるように,データ作成部の第2の暗号化鍵(プライベート鍵)及び前記データ所有部の暗号化鍵(プライベート鍵)を用いて暗号化されたものを遠隔計算リソースが復号化を行っているが,遠隔計算リソースがどのように検証して復号化するのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 (エ)同じく上記(d’)の「前記クラウドで,前記データを復号化」との記載について,上記(c’)の3つの暗号化鍵(「パブリック鍵(PuK)」,「データ作成部のプライベート鍵(PrK)」,及び「データ所有部のプライベート鍵(PrK)」)を用いて暗号化されたものを,クラウドにおいて,どのようにデータを復号化するのか不明である。 すなわち,上記3つの暗号化鍵を用いて暗号化されたものを復号化する際には,上記3つの暗号化鍵に対応する鍵がそれぞれ必要となるところ,クラウドが復号化に必要なこれら3つの鍵をどのように入手して,どのようにデータを復号化するのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 特に,上記3つの暗号化鍵の一つである「パブリック鍵(PuK)」について,復号化に際して「プライベート鍵(PrK)」が必要となるところ,クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵(PuK)」に対応する「プライベート鍵(PrK)」を,クラウドがどのように入手できたのか不明である。 すなわち,本願発明における「遠隔計算リソースで、前記データを復号化」との記載について,第1の暗号化鍵(パブリック鍵)を用いて暗号化されたものを復号化する際には,遠隔計算リソース側において当該第1の暗号化鍵に対応する秘密鍵(プライベート鍵)が必要となるところ,発明の詳細な説明には,段落【0018】に「健康プロバイダは、パブリック認証局20にパブリック暗号化鍵を要求する」「健康プロバイダ12が検証された後、パブリック認証局(PuK Authority)20は健康プロバイダ12に対してパブリック暗号化鍵22を発行する」と記載されていることから,遠隔計算リソースの外側に位置する第1の認証局により作成された第1の暗号化鍵(パブリック鍵)に対応する暗号化鍵(プライベート鍵)をデータ作成部が入手することまでは読み取れるが,当該第1の暗号化鍵に対応する暗号化鍵(プライベート鍵)を遠隔計算リソースがどのように入手できるのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 キ 請求項7について 請求項7記載の発明は,本願発明をシステムの発明として特定したものであることから,上記「1 請求項1について」の上記ウ及び上記カ(ア)ないし(エ)の検討結果と同様に不明である。 したがって,発明の詳細な説明は,当業者が請求項7に係る発明を実施することができる程度に明確かつ十分に記載されたものではない。 第5 請求人の主張について (1)令和2年2月17日付け意見書における請求人の主張について 請求人は,令和2年2月17日付け意見書において,下記の点を主張している。(当審注:下線は当審にて付与したものである。) 『(i)審判長殿は「(1)」として、請求項1において、データ作成部がデータをどのように暗号化するのか不明であると指摘された。 しかしながら、本願請求項1に係る発明は、鍵を用いた暗号化自体が具体的にどのような処理で行われるかまでを限定するものではないことは、当業者であれば疑義の生じる余地が全くなく、極めて明らかである。例えば、限定するものではないが、従来技術における鍵による暗号化におけるように、それぞれの鍵が何らかの演算を元データに施す(例えば乱数列と元の文字列とXOR演算する等)ものであっても良く、その具体的な演算の式などを限定するものではない。』(以下,当該主張を「主張1」という。) 『(ii)また審判長殿は「(2)」として、通常、公開暗号鍵方式では、送信者は公開鍵で暗号化を行い、受信者は当該公開鍵に対応する秘密鍵で復号化を行うものであるところ、送信者がプライベート鍵で暗号化する理由が意味不明であると指摘された。 しかしながら、本願発明は従来の公開暗号鍵方式に対して新規な方式である点に留意されたい。本願発明においては、データ所有部が有するプライベートな鍵(28)をデータ作成部が受け取って更に暗号化に用いることにより、従来の方式に比べて更に安全性を高めているものである。』(以下,当該主張を「主張2」という。) 『(iii)また審判長殿は「(3)」及び「(4)」として、鍵の検証とは、何をどのように検証するのか不明であると指摘された。 しかしながら、本願発明は、鍵の検証が具体的にどのような処理で行われるかまでを限定するものではない。例えば(限定するものではないが)、クラウドの内外における検証部(30、32)が、鍵が表す暗号化演算が所定の規則に合致するものであるか否かを検証するなどして、鍵が正当な方式で作成されたものであるか否かを検証しても良い。』(以下,当該主張を「主張3」という。) 『(iv)また審判長殿は「(5)」として、復号化の際に、クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵(PuK)」に対応する「プライベート鍵(PrK)」を、クラウド(14)がどのように入手できたのか不明であると指摘された。 この点については、当該プライベート鍵は、クラウドの外側に位置する認証局が、クラウド内のデータ作成部に対して発行するものであるから、クラウドがこの際に入手できるものである。これに関しては例えば段落0018を参照されたい。』(以下,当該主張を「主張4」という。) (2)当審の判断 ア 主張1について 請求人は,「本願請求項1に係る発明は、鍵を用いた暗号化自体が具体的にどのような処理で行われるかまでを限定するものではないことは、当業者であれば疑義の生じる余地が全くなく、極めて明らかである」と主張しているが,上記第4の1カ(ア)に記載したように,当該技術分野において,秘密鍵(プライベート鍵)は,公開鍵を用いて暗号化されたものを復号化する際に用いるものであって,暗号化の際に用いるものではないにも関わらず,パブリック鍵(PuK)と2種類のプライベート鍵(データ作成部のプライベート鍵(PrK)及びデータ所有部のプライベート鍵(PrK))を用いて暗号化すること(特に,2種類のプライベート鍵を用いて暗号化すること)は,当業者にとって周知の事項ではなく,発明の詳細な説明の記載は,本願発明の暗号化が具体的にどのような処理で行われるのかについて,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって,請求人の主張を採用することはできない。 イ 主張2について 請求人は,「本願発明は従来の公開暗号鍵方式に対して新規な方式である点に留意されたい。本願発明においては、データ所有部が有するプライベートな鍵(28)をデータ作成部が受け取って更に暗号化に用いることにより、従来の方式に比べて更に安全性を高めているものである」と主張している。確かに,パブリック鍵と2種類のプライベート鍵を用いて暗号化することは新規な方式であるが,上記アにも記載したとおり,具体的にどのように暗号化処理を行うのか,発明の詳細な説明には記載されておらず,また当業者にとって自明の事項でもない。 また,請求人の「従来の方式に比べて更に安全性を高めているものである」との主張も抽象的で,どのように安全性を高めているのか具体的に不明である。 したがって,請求人の主張を採用することはできない。 ウ 主張3について 請求人は,「本願発明は、鍵の検証が具体的にどのような処理で行われるかまでを限定するものではない」と主張しているが,当該技術分野において,復号化に際して鍵の検証は重要な事項であると認められるところ,上記第4の1カ(イ)に記載したように,遠隔計算リソースの外側に位置する「検証部」(本願の【図2】及び【図3】を参照すると,検証部30は,第1の認証局(パブリック認証局20)や第2の認証局(プライベート認証局24)とは異なる認証部となっている)がどのようなものであるか,またどのような有効性を検証するのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 また,上記第4の1カ(ウ)に記載したように,当該技術分野において,秘密鍵(プライベート鍵)は,公開鍵を用いて暗号化されたものを復号化する際に用いるものであって,暗号化の際に用いるものではないにも関わらず,データ作成部の第2の暗号化鍵(プライベート鍵)及び前記データ所有部の暗号化鍵(プライベート鍵)を用いて暗号化されたものを遠隔計算リソースがどのように検証して復号化するのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって,請求人の主張を採用することはできない。 エ 主張4について 請求人は,「プライベート鍵は、クラウドの外側に位置する認証局が、クラウド内のデータ作成部に対して発行するものであるから、クラウドがこの際に入手できるものである」と主張しているが,発明の詳細な説明の段落【0024】における「図4は、データ作成部からクラウドへとデータを送信する方法のフローチャート図」との記載,段落【0025】における「図5は、クラウドからデータ作成部へとデータを送信する方法のフローチャート図」との記載等からすると,発明の詳細な説明に記載されている「クラウド」は,「遠隔計算リソース」内の環境全体を指していると考えるのが自然であり,「クラウド」が「データ作成部」までを含むものとは認められない。 してみると,上記第4の1カ(エ)に記載したように,発明の詳細な説明から,遠隔計算リソースの外側に位置する第1の認証局により作成された第1の暗号化鍵(パブリック鍵)に対応する暗号化鍵(プライベート鍵)をデータ作成部が入手することまでは読み取れるが,当該第1の暗号化鍵に対応する暗号化鍵(プライベート鍵)を遠隔計算リソースがどのように入手できるのか,発明の詳細な説明の記載は,当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって,請求人の主張を採用することはできない。 第6 むすび 以上のとおり,本願は,発明の詳細な説明の記載が,特許法第36条第4項第1号に規定する要件を満たしていないから,拒絶すべきものである。 よって,結論のとおり審決する。 |
別掲 |
|
審理終結日 | 2020-03-31 |
結審通知日 | 2020-04-02 |
審決日 | 2020-04-22 |
出願番号 | 特願2015-531672(P2015-531672) |
審決分類 |
P
1
8・
536-
WZ
(H04L)
|
最終処分 | 不成立 |
前審関与審査官 | 金木 陽一、和平 悠希 |
特許庁審判長 |
石井 茂和 |
特許庁審判官 |
松平 英 田中 秀人 |
発明の名称 | 遠隔計算リソースにより分析される臨床データへのアクセス制御 |
代理人 | 笛田 秀仙 |
代理人 | 五十嵐 貴裕 |
代理人 | 矢ヶ部 喜行 |