2018-016241

特願２０１５－５３１６７２「遠隔計算リソースにより分析される臨床データへのアクセス制御」拒絶査定不服審判事件〔平成２６年　３月２７日国際公開、ＷＯ２０１４／０４５１７３、平成２７年１１月２６日国内公表、特表２０１５－５３４３４３〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本件審判請求に係る出願（以下，「本願」という。）は，２０１３年９月１３日（パリ条約による優先権主張外国庁受理２０１２年９月１８日，アメリカ合衆国）を国際出願日とする出願であって，平成２７年３月１６日に特許法第１８４条の５第１項に規定される書面の提出がなされるとともに，特許法第１８４条の４第１項の規定による国際出願日における明細書，請求の範囲，図面（図面の中の説明に限る。）及び要約の翻訳文の提出がなされ，平成２８年９月７日付けで審査請求がなされるとともに，同日付けで手続補正がなされ，平成２９年９月２８日付けで拒絶理由通知（同年１０月３日発送）がなされ，平成３０年３月１５日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，同年８月１４日付けで拒絶査定（同年８月２１日謄本送達）がなされた。 これに対して，「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」ことを請求の趣旨として，平成３０年１２月６日付けで本件審判請求がなされるとともに，同日付けで手続補正がなされ，平成３１年１月２４日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされた。 そして，令和元年８月２７日付けで当審により拒絶理由通知（以下，「当審拒絶理由通知」という。）（同年８月２９日発送）がなされ，令和２年２月１７日付けで意見書が提出されるとともに，同日付けで手続補正がなされたものである。 第２　本願発明 本願の特許請求の範囲の請求項１に係る発明（以下，「本願発明」という。）は，上記令和２年２月１７日付け手続補正書により補正された特許請求の範囲の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。 「遠隔計算リソースにより処理されるデータへのアクセスを制御する方法において、 前記遠隔計算リソースの外側に位置する第１の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第１の暗号化鍵を作成するステップと、 前記遠隔計算リソースにより、前記データ作成部が前記暗号化鍵を作成するとき用いるデータを所有するデータ所有部との、前記データ作成部のエンカウンタを検出するステップと、 前記エンカウンタを検出することに基づき、前記遠隔計算リソースの第２の認証局により、前記データ作成部に関する第２の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップと、 前記第１の暗号化鍵、前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップと、 前記遠隔計算リソースの外側に位置する検証部による前記第１の暗号化鍵の検証、並びに前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも１つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップと、 前記データ所有部により、前記データ作成部の第１及び第２の暗号化鍵の少なくとも１つのパーミッションを変えることにより、前記データに対する前記データ作成部のアクセスを制御するステップとを有する、方法。」 第３　当審における拒絶の理由 当審における拒絶の理由（以下，「当審拒絶理由」という。）は，次のとおりである。 『本件出願は，発明の詳細な説明の記載が下記の点で不備のため，特許法第３６条第４項第１号に規定する要件を満たしていない。 記 ア　請求項１について 請求項１は，その記載からして，次の事項（ａ），（ｂ），（ｃ），及び（ｄ）を含んでいる。 （ａ）「前記遠隔計算リソースの外側に位置する第１の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第１の暗号化鍵を作成するステップ」 （ｂ）「前記遠隔計算リソースの第２の認証局により、前記データ作成部に関する第２の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップ」 （ｃ）「前記第１の暗号化鍵、前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 （ｄ）「前記遠隔計算リソースの外側に位置する検証部による前記第１の暗号化鍵の検証、並びに前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも１つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップ」 ここで，出願当初の明細書を参照すると， 「【００２４】 図４は、データ作成部からクラウドへとデータを送信する方法のフローチャート図を示す。ステップ１００において、データ作成部は、認証局にパブリック暗号化鍵を要求する。データ作成部が作成されたデータを用いてシステムをサブスクライブするとき、この要求は作成される。ステップ１０２において、認証局は、データ作成部に対してパブリック鍵（ＰｕＫ）を発行する。ステップ１０４において、エンカウンタが、データ所有部に関して作成される。ステップ１０６において、クラウドにおけるローカル認証局は、データ作成部及びデータ所有部に関するプライベート鍵（ＰｒＫ）を作成する。ステップ１０８において、データが作成され、作成認証局パブリック鍵（ＰｕＫ）並びにデータ作成部及びデータ所有部に関する両方のプライベート鍵（ＰｒＫ）でエンコードされる。ステップ１１０において、データは、暗号化されて、クラウドに送信される。ステップ１１２において、クラウドは、パブリック鍵（ＰｕＫ）に関する検証に基づき、並びにデータ作成部及びデータ所有部に関するプライベート鍵（ＰｒＫ）に関する内部検証に基づき、データを復号化する。」， （当審注：下線は，参考のために当審で付与したものである。） と記載されており，請求項１に記載されている「遠隔計算リソース」，「第１の認証局」，「データ作成部」，「第１の暗号化鍵」，「第２の認証局」，「第２の暗号化鍵」，「データ所有部」，「暗号化鍵」は，それぞれ，上記段落【００２４】に記載されている「クラウド」，「認証局」，「データ作成部」，「パブリック鍵（ＰｕＫ）」，「ローカル認証局」，「プライベート鍵（ＰｒＫ）」，「データ所有部」，「プライベート鍵（ＰｒＫ）」に対応しているものと認められる。 そうすると，上記（ａ），上記（ｂ），上記（ｃ），及び上記（ｄ）の具体的な実施例は， （ａ’）「前記クラウドの外側に位置する認証局により，クラウドにより処理されるデータを作成するデータ作成部に関するパブリック鍵（ＰｕＫ）を作成するステップ」 （ｂ’）「前記クラウドのローカル認証局により，前記データ作成部に関するプライベート鍵（ＰｒＫ）及び前記データ所有部に関するプライベート鍵（ＰｒＫ）を作成するステップ」 （ｃ’）「前記パブリック鍵（ＰｕＫ），前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）で，前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 （ｄ’）「前記クラウドの外側に位置する検証部による前記パブリック鍵（ＰｕＫ）の検証，並びに前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）の少なくとも１つの検証に基づき，前記クラウドで，前記データを復号化し，及び格納するステップ」 であると理解されるところ， （１）上記（ｃ’）において，「パブリック鍵（ＰｕＫ）」，「データ作成部のプライベート鍵（ＰｒＫ）」，及び「データ所有部のプライベート鍵（ＰｒＫ）」を用いて，データ作成部がデータをどのように暗号化するのか不明であり， （２）上記（ｃ’）において，「前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）で，前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化する」と記載されているが，「前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）」で暗号化するとはどのようなことを意味しているのか不明，（通常，公開暗号鍵方式では，送信者は公開鍵で暗号化を行い，受信者は当該公開鍵に対応する秘密鍵で復号化を行うものであるところ，送信者がプライベート鍵で暗号化する理由が意味不明）であり， （３）上記（ｄ’）において，「前記クラウドの外側に位置する検証部による前記パブリック鍵（ＰｕＫ）の検証」とは，パブリック鍵（ＰｕＫ）の何を検証するのか不明であり， （４）上記（ｄ’）において，「前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）の少なくとも１つの検証」とは，何をどのように検証するのか不明（上記（２）にも記載したが，公開暗号鍵方式において，送信者がプライベート鍵で暗号化する理由が意味不明であるところ，暗号化されたものを受信者がどのように検証するのかも不明）であり， （５）上記（ｄ’）において，「前記クラウドで，前記データを復号化」する際には，「パブリック鍵（ＰｕＫ）」に対応する「プライベート鍵（ＰｒＫ）」が必要となるところ，クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵（ＰｕＫ）」に対応する「プライベート鍵（ＰｒＫ）」を，クラウドがどのように入手できたのか不明である。 してみると，本願の発明の詳細な説明は，当業者が請求項１に係る発明を実施することができる程度に明確かつ十分に記載されていない。 （中略） キ　請求項８について 請求項８記載の発明は，請求項１記載の発明をシステムの発明として特定したものであることから，上記「ア　請求項１について」の上記（１）ないし上記（５）の検討結果と同様に不明である。 してみると，本願の発明の詳細な説明は，当業者が請求項８に係る発明を実施することができる程度に明確かつ十分に記載されていない。 （以下略）』 第４　当審の判断 １　実施可能要件（特許法第３６条第４項第１号）について ア　特許法第３６条第４項は，「前項第三号の発明の詳細な説明の記載は，次の各号に適合するものでなければならない。」と記載され，その第１号において，「経済産業省令で定めるところにより，その発明の属する技術の分野における通常の知識を有する者が容易にその実施をすることができる程度に，明確かつ十分に記載しなければならない。」と規定している。同号は，明細書のいわゆる実施可能要件を規定したものであって，方法の発明では，その方法を実施するための具体的な記載が発明の詳細な説明にあるか，そのような記載がない場合には，明細書及び図面の記載及び出願時の技術常識に基づき，当業者が過度の試行錯誤や複雑高度な実験等を行う必要なく，その方法を実施することができる程度にその発明が記載されてなければならないと解される。 以下，この観点に立って，判断する。 イ　本願発明は，その記載からして，次の事項（ａ），（ｂ），（ｃ），及び（ｄ）を含んでいる。 （ａ）「前記遠隔計算リソースの外側に位置する第１の認証局により、遠隔計算リソースにより処理されるデータを作成するデータ作成部に関する第１の暗号化鍵を作成するステップ」 （ｂ）「前記遠隔計算リソースの第２の認証局により、前記データ作成部に関する第２の暗号化鍵及び前記データ所有部に関する暗号化鍵を作成するステップ」 （ｃ）「前記第１の暗号化鍵、前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 （ｄ）「前記遠隔計算リソースの外側に位置する検証部による前記第１の暗号化鍵の検証、並びに前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも１つの検証に基づき、前記遠隔計算リソースで、前記データを復号化し、及び格納するステップ」 ウ　そうすると，上記当審拒絶理由の第３アの（１）ないし（５）でも述べたとおり，本願発明は，下記の点で不明であり，発明の詳細な説明の記載は，本願発明の全体について，出願時の技術常識に基づき，当業者がその実施をすることができる程度に明確かつ十分に記載されたものではない。 すなわち， 上記（ｃ）において，「第１の暗号化鍵」，「データ作成部の第２の暗号化鍵」，及び「データ所有部の暗号化鍵」という３つの暗号化鍵を用いてどのように暗号化するのか不明であり，下記エないしカに詳述したとおり，本願の発明の詳細な説明は，当該暗号化について，当業者が実施をすることができる程度に，明確かつ十分に記載されていないものであるところ， 上記（ｄ）において，「遠隔計算リソース」で，上記（ｃ）の３つの暗号化鍵で暗号化されたものをどのようにしてデータを復号化するのか不明であり，下記エないしカに詳述したとおり，本願の発明の詳細な説明は，当該復号化について，当業者が実施をすることができる程度に，明確かつ十分に記載されていない。 エ　ここで，上記ウ記載の不明点について，出願当初の発明の詳細な説明における具体的な実施例と対比して検討する。 本願の発明の詳細な説明の段落【００２４】には， 「【００２４】 図４は、データ作成部からクラウドへとデータを送信する方法のフローチャート図を示す。ステップ１００において、データ作成部は、認証局にパブリック暗号化鍵を要求する。データ作成部が作成されたデータを用いてシステムをサブスクライブするとき、この要求は作成される。ステップ１０２において、認証局は、データ作成部に対してパブリック鍵（ＰｕＫ）を発行する。ステップ１０４において、エンカウンタが、データ所有部に関して作成される。ステップ１０６において、クラウドにおけるローカル認証局は、データ作成部及びデータ所有部に関するプライベート鍵（ＰｒＫ）を作成する。ステップ１０８において、データが作成され、作成認証局パブリック鍵（ＰｕＫ）並びにデータ作成部及びデータ所有部に関する両方のプライベート鍵（ＰｒＫ）でエンコードされる。ステップ１１０において、データは、暗号化されて、クラウドに送信される。ステップ１１２において、クラウドは、パブリック鍵（ＰｕＫ）に関する検証に基づき、並びにデータ作成部及びデータ所有部に関するプライベート鍵（ＰｒＫ）に関する内部検証に基づき、データを復号化する。」 （当審注：下線は，参考のために当審で付与したものである。） と記載されており，本願発明に記載されている「遠隔計算リソース」，「第１の認証局」，「データ作成部」，「第１の暗号化鍵」，「第２の認証局」，「第２の暗号化鍵」，「データ所有部」，「暗号化鍵」は，それぞれ，上記段落【００２４】に記載されている「クラウド」，「認証局」，「データ作成部」，「パブリック鍵（ＰｕＫ）」，「ローカル認証局」，「プライベート鍵（ＰｒＫ）」，「データ所有部」，「プライベート鍵（ＰｒＫ）」に対応しているものと認められる。 オ　したがって，本願発明の，上記（ａ），上記（ｂ），上記（ｃ），及び上記（ｄ）について，発明の詳細な説明における具体的な実施例は， （ａ’）「前記クラウドの外側に位置する認証局により，クラウドにより処理されるデータを作成するデータ作成部に関するパブリック鍵（ＰｕＫ）を作成するステップ」 （ｂ’）「前記クラウドのローカル認証局により，前記データ作成部に関するプライベート鍵（ＰｒＫ）及び前記データ所有部に関するプライベート鍵（ＰｒＫ）を作成するステップ」 （ｃ’）「前記パブリック鍵（ＰｕＫ），前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）で，前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」 （ｄ’）「前記クラウドの外側に位置する検証部による前記パブリック鍵（ＰｕＫ）の検証，並びに前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）の少なくとも１つの検証に基づき，前記クラウドで，前記データを復号化し，及び格納するステップ」 であると認められる。 カ　そうすると，本願発明は，下記の点で不明であり，発明の詳細な説明の記載は，本願発明の全体について，出願時の技術常識に基づき，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 （ア）上記（ｃ’）において，「パブリック鍵（ＰｕＫ）」，「データ作成部のプライベート鍵（ＰｒＫ）」，及び「データ所有部のプライベート鍵（ＰｒＫ）」を用いて，データ作成部がデータを暗号化しているが，データ作成部がデータをどのように暗号化するのか不明である。 すなわち，当該技術分野において，秘密鍵（プライベート鍵）は，公開鍵を用いて暗号化されたものを復号化する際に用いるものであって，暗号化の際に用いるものではないにも関わらず，本願発明における暗号化ステップは，「前記第１の暗号化鍵、前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵で、前記遠隔計算リソースに送られるデータを前記データ作成部が暗号化するステップ」と記載されるように，第１の暗号化鍵（パブリック鍵），データ作成部の第２の暗号化鍵（プライベート鍵）及びデータ所有部の暗号化鍵（プライベート鍵）を用いて暗号化しており，特に，２種類のプライベート鍵を用いて暗号化する点については，当業者にとって周知の事項ではなく，発明の詳細な説明の記載は，本願発明の暗号化がどのような処理で行われるのかについて，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 （イ）上記（ｄ’）において，「前記クラウドの外側に位置する検証部による前記パブリック鍵（ＰｕＫ）の検証」とは，「検証部」がどのようなものであるか不明であり，また該検証部において「パブリック鍵（ＰｕＫ）」の何を検証するのか不明である。 すなわち，本願発明における「前記遠隔計算リソースの外側に位置する検証部による前記第１の暗号化鍵の検証」について，発明の詳細な説明には，段落【００２０】に，「遠隔計算リソース１４は、パブリック暗号化鍵２２、健康プロバイダのプライベート暗号化鍵２６及び／又は患者のプライベート暗号化鍵２８の検証に基づき、臨床データを復号化する・・・特に、臨床及び結果データの復号化は、クラウドインフラストラクチャの外側に位置するパブリック検証部３０（ＰｕＫ Ｖｅｒｉｆｉｃａｔｉｏｎ）によるパブリック暗号化鍵２２の有効性の検証」と記載されているのみであり，遠隔計算リソースの外側に位置する「検証部」（本願の【図２】及び【図３】を参照すると，検証部３０は，第１の認証局（パブリック認証局２０）や第２の認証局（プライベート認証局２４）とは異なる認証部となっている）がどのようなものであるか，またどのような有効性を検証するのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 （ウ）同じく上記（ｄ’）において，「前記データ作成部のプライベート鍵（ＰｒＫ）及び前記データ所有部のプライベート鍵（ＰｒＫ）の少なくとも１つの検証」とは，何をどのように検証するのか不明である。 すなわち，上記（ア）にも述べたとおり，当該技術分野において，秘密鍵（プライベート鍵）は，公開鍵を用いて暗号化されたものを復号化する際に用いるものであって，暗号化の際に用いるものではないにも関わらず，本願発明には，「前記データ作成部の第２の暗号化鍵及び前記データ所有部の暗号化鍵の少なくとも１つの検証に基づき、前記遠隔計算リソースで、前記データを復号化」と記載されるように，データ作成部の第２の暗号化鍵（プライベート鍵）及び前記データ所有部の暗号化鍵（プライベート鍵）を用いて暗号化されたものを遠隔計算リソースが復号化を行っているが，遠隔計算リソースがどのように検証して復号化するのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 （エ）同じく上記（ｄ’）の「前記クラウドで，前記データを復号化」との記載について，上記（ｃ’）の３つの暗号化鍵（「パブリック鍵（ＰｕＫ）」，「データ作成部のプライベート鍵（ＰｒＫ）」，及び「データ所有部のプライベート鍵（ＰｒＫ）」）を用いて暗号化されたものを，クラウドにおいて，どのようにデータを復号化するのか不明である。 すなわち，上記３つの暗号化鍵を用いて暗号化されたものを復号化する際には，上記３つの暗号化鍵に対応する鍵がそれぞれ必要となるところ，クラウドが復号化に必要なこれら３つの鍵をどのように入手して，どのようにデータを復号化するのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 特に，上記３つの暗号化鍵の一つである「パブリック鍵（ＰｕＫ）」について，復号化に際して「プライベート鍵（ＰｒＫ）」が必要となるところ，クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵（ＰｕＫ）」に対応する「プライベート鍵（ＰｒＫ）」を，クラウドがどのように入手できたのか不明である。 すなわち，本願発明における「遠隔計算リソースで、前記データを復号化」との記載について，第１の暗号化鍵（パブリック鍵）を用いて暗号化されたものを復号化する際には，遠隔計算リソース側において当該第１の暗号化鍵に対応する秘密鍵（プライベート鍵）が必要となるところ，発明の詳細な説明には，段落【００１８】に「健康プロバイダは、パブリック認証局２０にパブリック暗号化鍵を要求する」「健康プロバイダ１２が検証された後、パブリック認証局（ＰｕＫ Ａｕｔｈｏｒｉｔｙ）２０は健康プロバイダ１２に対してパブリック暗号化鍵２２を発行する」と記載されていることから，遠隔計算リソースの外側に位置する第１の認証局により作成された第１の暗号化鍵（パブリック鍵）に対応する暗号化鍵（プライベート鍵）をデータ作成部が入手することまでは読み取れるが，当該第１の暗号化鍵に対応する暗号化鍵（プライベート鍵）を遠隔計算リソースがどのように入手できるのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 キ　請求項７について 請求項７記載の発明は，本願発明をシステムの発明として特定したものであることから，上記「１　請求項１について」の上記ウ及び上記カ（ア）ないし（エ）の検討結果と同様に不明である。 したがって，発明の詳細な説明は，当業者が請求項７に係る発明を実施することができる程度に明確かつ十分に記載されたものではない。 第５　請求人の主張について （１）令和２年２月１７日付け意見書における請求人の主張について 請求人は，令和２年２月１７日付け意見書において，下記の点を主張している。（当審注：下線は当審にて付与したものである。） 『（ｉ）審判長殿は「（１）」として、請求項１において、データ作成部がデータをどのように暗号化するのか不明であると指摘された。 しかしながら、本願請求項１に係る発明は、鍵を用いた暗号化自体が具体的にどのような処理で行われるかまでを限定するものではないことは、当業者であれば疑義の生じる余地が全くなく、極めて明らかである。例えば、限定するものではないが、従来技術における鍵による暗号化におけるように、それぞれの鍵が何らかの演算を元データに施す（例えば乱数列と元の文字列とＸＯＲ演算する等）ものであっても良く、その具体的な演算の式などを限定するものではない。』（以下，当該主張を「主張１」という。） 『（ii）また審判長殿は「（２）」として、通常、公開暗号鍵方式では、送信者は公開鍵で暗号化を行い、受信者は当該公開鍵に対応する秘密鍵で復号化を行うものであるところ、送信者がプライベート鍵で暗号化する理由が意味不明であると指摘された。 しかしながら、本願発明は従来の公開暗号鍵方式に対して新規な方式である点に留意されたい。本願発明においては、データ所有部が有するプライベートな鍵（２８）をデータ作成部が受け取って更に暗号化に用いることにより、従来の方式に比べて更に安全性を高めているものである。』（以下，当該主張を「主張２」という。） 『（iii）また審判長殿は「（３）」及び「（４）」として、鍵の検証とは、何をどのように検証するのか不明であると指摘された。 しかしながら、本願発明は、鍵の検証が具体的にどのような処理で行われるかまでを限定するものではない。例えば（限定するものではないが）、クラウドの内外における検証部（３０、３２）が、鍵が表す暗号化演算が所定の規則に合致するものであるか否かを検証するなどして、鍵が正当な方式で作成されたものであるか否かを検証しても良い。』（以下，当該主張を「主張３」という。） 『（iv）また審判長殿は「（５）」として、復号化の際に、クラウドの外側に位置する認証局により作成されたデータ作成部の「パブリック鍵（ＰｕＫ）」に対応する「プライベート鍵（ＰｒＫ）」を、クラウド（１４）がどのように入手できたのか不明であると指摘された。 この点については、当該プライベート鍵は、クラウドの外側に位置する認証局が、クラウド内のデータ作成部に対して発行するものであるから、クラウドがこの際に入手できるものである。これに関しては例えば段落００１８を参照されたい。』（以下，当該主張を「主張４」という。） （２）当審の判断 ア　主張１について 請求人は，「本願請求項１に係る発明は、鍵を用いた暗号化自体が具体的にどのような処理で行われるかまでを限定するものではないことは、当業者であれば疑義の生じる余地が全くなく、極めて明らかである」と主張しているが，上記第４の１カ（ア）に記載したように，当該技術分野において，秘密鍵（プライベート鍵）は，公開鍵を用いて暗号化されたものを復号化する際に用いるものであって，暗号化の際に用いるものではないにも関わらず，パブリック鍵（ＰｕＫ）と２種類のプライベート鍵（データ作成部のプライベート鍵（ＰｒＫ）及びデータ所有部のプライベート鍵（ＰｒＫ））を用いて暗号化すること（特に，２種類のプライベート鍵を用いて暗号化すること）は，当業者にとって周知の事項ではなく，発明の詳細な説明の記載は，本願発明の暗号化が具体的にどのような処理で行われるのかについて，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって，請求人の主張を採用することはできない。 イ　主張２について 請求人は，「本願発明は従来の公開暗号鍵方式に対して新規な方式である点に留意されたい。本願発明においては、データ所有部が有するプライベートな鍵（２８）をデータ作成部が受け取って更に暗号化に用いることにより、従来の方式に比べて更に安全性を高めているものである」と主張している。確かに，パブリック鍵と２種類のプライベート鍵を用いて暗号化することは新規な方式であるが，上記アにも記載したとおり，具体的にどのように暗号化処理を行うのか，発明の詳細な説明には記載されておらず，また当業者にとって自明の事項でもない。 また，請求人の「従来の方式に比べて更に安全性を高めているものである」との主張も抽象的で，どのように安全性を高めているのか具体的に不明である。 したがって，請求人の主張を採用することはできない。 ウ　主張３について 請求人は，「本願発明は、鍵の検証が具体的にどのような処理で行われるかまでを限定するものではない」と主張しているが，当該技術分野において，復号化に際して鍵の検証は重要な事項であると認められるところ，上記第４の１カ（イ）に記載したように，遠隔計算リソースの外側に位置する「検証部」（本願の【図２】及び【図３】を参照すると，検証部３０は，第１の認証局（パブリック認証局２０）や第２の認証局（プライベート認証局２４）とは異なる認証部となっている）がどのようなものであるか，またどのような有効性を検証するのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 また，上記第４の１カ（ウ）に記載したように，当該技術分野において，秘密鍵（プライベート鍵）は，公開鍵を用いて暗号化されたものを復号化する際に用いるものであって，暗号化の際に用いるものではないにも関わらず，データ作成部の第２の暗号化鍵（プライベート鍵）及び前記データ所有部の暗号化鍵（プライベート鍵）を用いて暗号化されたものを遠隔計算リソースがどのように検証して復号化するのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって，請求人の主張を採用することはできない。 エ　主張４について 請求人は，「プライベート鍵は、クラウドの外側に位置する認証局が、クラウド内のデータ作成部に対して発行するものであるから、クラウドがこの際に入手できるものである」と主張しているが，発明の詳細な説明の段落【００２４】における「図４は、データ作成部からクラウドへとデータを送信する方法のフローチャート図」との記載，段落【００２５】における「図５は、クラウドからデータ作成部へとデータを送信する方法のフローチャート図」との記載等からすると，発明の詳細な説明に記載されている「クラウド」は，「遠隔計算リソース」内の環境全体を指していると考えるのが自然であり，「クラウド」が「データ作成部」までを含むものとは認められない。 してみると，上記第４の１カ（エ）に記載したように，発明の詳細な説明から，遠隔計算リソースの外側に位置する第１の認証局により作成された第１の暗号化鍵（パブリック鍵）に対応する暗号化鍵（プライベート鍵）をデータ作成部が入手することまでは読み取れるが，当該第１の暗号化鍵に対応する暗号化鍵（プライベート鍵）を遠隔計算リソースがどのように入手できるのか，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載されたものでない。 したがって，請求人の主張を採用することはできない。 第６　むすび 以上のとおり，本願は，発明の詳細な説明の記載が，特許法第３６条第４項第１号に規定する要件を満たしていないから，拒絶すべきものである。 よって，結論のとおり審決する。