2020-017731

第１．手続の経緯

本願は，平成３１年４月１２日の出願であって，

平成３１年４月１５日付けで審査請求がなされ，令和１年１２月２４日付けで審査官により拒絶理由が通知され，これに対して令和２年３月２５日付けで意見書が提出されると共に手続補正がなされたが，令和２年９月１６日付けで審査官により拒絶査定がなされ，これに対して令和２年１２月２５日付けで審判請求がなされると共に手続補正がなされ，令和３年４月２３日付けで審査官により特許法１６４条３項の規定に基づく報告がなされたものである。

第２．本願発明について

本願の請求項１及び本願の請求項２に係る発明は，令和２年１２月２５日付けの手続補正により補正された特許請求の範囲の請求項１及び請求項２に記載された事項により特定されるものである。

第３．原審における拒絶査定の理由

原審における令和１年１２月２４日付けの拒絶理由（以下，これを「原審拒絶理由」という）は，概略，次のとおりである。

「●理由１（明確性）について

省略

●理由２（実施可能要件）について

・請求項 １－６

請求項１には，「前記第１端末，前記第２端末及び前記第３端末の３つは，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵が結合することにより生成する取引公開鍵を取得」が記載されている。

一方で，対応する本願明細書の発明の詳細説明（当審注：正しくは，「発明の詳細な説明」）には，「記憶媒体２５のメモリ２５２に前記第１公開鍵，第２公開鍵及び第３公開鍵が記憶されている場合，記憶媒体２５のマイクロプロセッサ２５１は，前記第１公開鍵，第２公開鍵及び第３公開鍵を結合させてデジタル通貨を有する取引公開鍵を形成し，かつマイクロプロセッサ２５１は，前記取引公開鍵を，秘密鍵に対応する少なくとも２つの電子印鑑がないとデジタル通貨を移動できない取引モードに設定する。」（段落0023；段落0028にも同様の記載あり）が記載されているものの，第１公開鍵，第２公開鍵及び第３公開鍵に対して，どのような演算を行ってそれらを「結合」させるのかについての具体的な記載がない。そして，複数の公開鍵を「結合」させて，公開鍵暗号系の公開鍵として機能する，新たな公開鍵を生成することは，本願優先権主張の優先日（当審注：正しくは，本願の出願前）における技術常識であったとは言えない。

したがって，当業者は，本願明細書の発明の詳細な説明を見ても，請求項１に係る発明の「前記第１端末，前記第２端末及び前記第３端末の３つは，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵が結合することにより生成する取引公開鍵を取得」することを含む方法を使用できない（「特許・実用新案 審査基準」第ＩＩ部第１章第１節 実施可能要件 ３．１．２「方法の発明」についての発明の実施の形態を参照）。

請求項２に記載の「前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵の３つのうち２つと前記第４の公開鍵とを結合させてリセット取引公開鍵を形成し」についても同様である。

請求項１を引用する請求項２－６に係る発明も同様である。

よって，この出願の発明の詳細な説明は，請求項１－６に係る発明を，当業者が実施することができる程度に明確かつ十分に記載されたものでない。

●理由３（進歩性）

省略」

第４．当審の判断

願書に最初に添付された特許請求の範囲の請求項１に記載された，

「前記第１端末，前記第２端末及び前記第３端末の３つは，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵が結合することにより生成する取引公開鍵を取得」，

は，令和２年３月２５日付けの手続補正により，

「前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵に基づいて生成される取引公開鍵が，前記第１端末，前記第２端末及び前記第３端末のそれぞれに取得され」，

と補正され，更に，令和２年１２月２５日付けの手続補正により，

「前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵によって，取引ブロックチェーンに合わせて利用する取引公開鍵を生成し」，

と補正された。

上記引用記載中の「取引公開鍵」について，本願明細書の発明の詳細な説明には，その段落【０００８】に，

「前記第１端末，前記第２端末及び前記第３端末の３つは，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵が結合することにより生成する取引公開鍵を取得し」，

同段落【００１０】に，

「前記取引公開鍵設定ステップにおいて，前記第１端末は，前記第２公開鍵及び前記第３公開鍵を取得することで，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵を有し，前記第１公開鍵前記，第２公開鍵及び前記第３公開鍵を結合させて前記取引公開鍵を生成し」（なお，上記引用記載中の「前記，第２公開鍵」は，原文の表記どおりである），

同段落【００１２】に，

「前記取引公開鍵設定ステップにおいて，前記第１端末，前記第２端末及び前記第３端末のそれぞれは，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵を取得し，前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵を結合させて前記取引公開鍵を形成する」，

同段落【００１３】に，

「前記第１公開鍵，前記第２公開鍵及び前記第３公開鍵の３つのうち２つと前記第４の公開鍵とを結合させて前記取引公開鍵を委託管理するためのリセット取引公開鍵を形成し」，

同段落【００１４】に，

「本発明は，第１端末，第２端末及び第３端末の３つがそれぞれ，１つの秘密鍵と１つの公開鍵を有し，全ての公開鍵が結合して取引公開鍵を形成し」，

同段落【００２３】に，

「次に取引公開鍵設定ステップ１１を行う。記憶媒体２５のメモリ２５２に前記第１公開鍵，第２公開鍵及び第３公開鍵が記憶されている場合，記憶媒体２５のマイクロプロセッサ２５１は，前記第１公開鍵，第２公開鍵及び第３公開鍵を結合させてデジタル通貨を有する取引公開鍵を形成し」，

同段落【００２８】に，

「第１端末２０，第２端末２１，第３端末２２のそれぞれは，前記第１公開鍵，第２公開鍵及び第３公開鍵を互いに結合させて前記取引公開鍵を形成する」，

同段落【００３３】に，

「記憶媒体２５のマイクロプロセッサ２５１は前記第２公開鍵，第３公開鍵及び第４の公開鍵を結合させてリセット取引公開鍵を形成する」，

という記載が存在している。

しかしながら，上記引用記載の何れにも，「取引公開鍵」を形成するために，「第１公開鍵」，「第２公開鍵」，及び，「第３公開鍵」をどのように「互いに結合させ」るのか，或いは，「リセット取引公開鍵」を形成するために，「第１公開鍵」，「第２公開鍵」，及び，「第３公開鍵」の３つのうち２つと，「第４の公開鍵」とを，どのように「結合させ」るのか，何ら説明されておらず，当該技術分野において，複数の「公開鍵」を「結合」するための手法が，周知の技術事項であるとも認められない。

この点について請求人は，令和２年１２月２５日付の審判請求書（以下，これを「請求書」という）において，

『本願補正後の請求項１における取引公開鍵について，まず，本願「第１秘密鍵」，「第２秘密鍵」及び「第３秘密鍵」の３つは，互いに関連性があります。補正後の請求項１に記載のように，「第１秘密鍵」，「第２秘密鍵」及び「第３秘密鍵」の３つは，同一のユーザーＩＤを示す同一のユーザ情報により演算して生成するものであり，したがって，本願「第１秘密鍵」，「第２秘密鍵」及び「第３秘密鍵」の３つに対応している「第１公開鍵」，「第２公開鍵」及び「第３公開鍵」の３つは，楕円曲線デジタル署名アルゴリズム（楕円曲線ＤＳＡ，ＥＣＤＳＡ，Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）によって演算し，取引公開鍵を生成することができます。

なお，楕円曲線デジタル署名アルゴリズムとは，楕円曲線暗号を使った公開鍵暗号であります。

関連コンテンツは，甲第１号証における黄色いハイライトをつけた部分を参照してください。また，甲第１号証は，本願出願日の前に公然知られたものですから，当業者には，本願発明における複数の公開鍵と楕円曲線デジタル署名アルゴリズムによって，取引ブロックチェーンに合わせて利用する取引公開鍵を生成することができます。

かつ，特開２０１９－０５０５９７号公報における，明細書の発明の詳細な説明には，

「（Ｓ１４１０）コントローラは，証明書ＩＤがＣＲＬに記載されていないことを確認すると，機器の公開鍵証明書の署名を認証局の公開鍵を用いて検証する。検証に失敗した場合，コントローラは，機器にエラーを通知して処理を終了する。署名には，ＥＣＤＳＡ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）ＲＳＡ，ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）等の一般的に用いられている方式を利用することが可能である。また，コントローラは，機器の公開鍵証明書の署名の検証に成功すると，接続機器管理テーブル５００に，新たなレコードを作成し，相互認証処理の相手となる機器の機器ＩＤ及び証明書ＩＤを登録する」（段落［０１０１］）と記載されており，

また，特開２０１６－１８４８９２号公報における，明細書の発明の詳細な説明には，

「ステップＳ２６において，証明書認証部２０１は，公開鍵証明書１２２に対する検証が成功した旨を通知する成功通知をコントローラ１に送信する。なお，ステップＳ２１～ステップＳ２６における電子署名方式及び検証方法は，楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）に基づくものとすることができる。」（段落［００４２］）と記載されており，

楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）における技術的な特徴が記載されています。

よって，本願請求項１に係る発明は実施可能要件を満たしていると思料いたします。

また，本願発明の補正した請求項１に記載された技術的な内容「前記第１秘密鍵に対応する第１公開鍵を設定し」，「前記第２秘密鍵に対応する第２公開鍵を設定し」，「前記第３秘密鍵に対応する第３公開鍵を設定し」によって，本願発明の第１，第２及び第３公開鍵のそれぞれは，第１，第２及び第３秘密鍵のそれぞれに対応しているものであります。よって，第１端末が第２電子印鑑を取得した場合，第１端末は，記憶した第２公開鍵によって，取得した第２電子印鑑が第２公開鍵によって生成されたものを確認することができます。したがって，本願発明の第１，第２及び第３公開鍵は，特定の電子印鑑が特定の秘密鍵によって生成されたものを確認するためのものであります。

よって，本願請求項１に係る発明は実施可能要件を満たしていると思料いたします。』

と主張すると共に，甲第１号証として，

「Ｒｏｓａｒｉｏ Ｇｅｎｎａｒｏ ａｎｄ Ｓｔｅｖｅｎ Ｇｏｌｄｆｅｄｅｒ，“Ｆａｓｔ Ｍｕｌｔｉｐａｒｔｙ Ｔｈｒｅｓｈｏｌｄ ＥＣＤＳＡ ｗｉｔｈ Ｆａｓｔ Ｔｒｕｓｔｌｅｓｓ Ｓｅｔｕｐ”，ＣＣＳ’１８： Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１８ ＡＣＭ ＳＩＧＳＡＣ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｅｃｕｒｉｔｙ， Ｏｃｔｏｂｅｒ ２０１８， Ｐａｇｅｓ １１７９－１１９４， ｈｔｔｐｓ：／／ｄｏｉ．ｏｒｇ／１０．１１４５／３２４３７３４．３２４３８５９」

を提示している。

しかしながら，本願明細書中には，「ＥＣＤＳＡ」に関する記載は，一切存在しておらず，「楕円曲線暗号」に関する記載も一切存在しない。

請求人が主張するように，本願の出願前に公開された文献に「ＥＣＤＳＡ」に関する記述が存在し，「ＥＣＤＳＡ」が，本願の出願前に，当業者に広く知られた技術であったとしても，本願明細書の記載内容から，「ＥＣＤＳＡ」との関連が読み取れない以上，請求人の主張は採用できない。

更に，請求人が請求書において主張の根拠として挙げている甲第１号証の当該箇所の記載を参照すると，

ａ．「ABSTRACT

A threshold signature scheme enables distributed signing among n players such that any subgroup of size t+1 can sign, whereas any group with t or fewer players cannot. While there exist previous threshold schemes for the ECDSA signature scheme, we are the first protocol that supports multiparty signatures for any t≦n with an efficient dealerless key generation.」（１１７９頁左欄１行～７行）

（要約

閾値署名スキームにより，サイズｔ＋１のサブグループが署名できるように，プレーヤー間で分散署名が可能になるが，プレーヤーの数が少ないグループは署名ができない。ＥＣＤＳＡ署名スキームには，以前の閾値スキームが存在するが，効率的なディーラレスキー生成を使用して，マルチパーティ署名をサポートする最初のプロトコルである。<当審にて訳出。以下，同じ。>）

ｂ．「With a (t,n) threshold signature scheme, control of a cryptocurrency wallet can be distributed among n servers (or players) such that t+1 of them are required to produce a signature. Crucially, the funds will remain secure even if up to t of these servers are compromised.」（１１７９頁左欄３２行～３７行）

（（ｔ，ｎ）閾値署名スキームを使用すると，それらのｔ＋１が，署名を生成することを要求されるように，暗号通貨ウォレットの制御をｎ台のサーバ（または，ｎ人のプレーヤー）間で分散される。重要なのは，これらのサーバまでが侵害されても資金は，安全なままであるということである。）

ｃ．「we want to generate an additive sharing of c = ab. We note that ab =Σi, j aibj and therefore to get an additive sharing of ab, it is sufficient to obtain an additive sharing of each individual term aibj . To that extent we use a 2-party protocol that allows two parties to transform multiplicative shares of a secret to additive shares of the same secret. The players engage in this protocol in a pairwise fashion to obtain an additive sharing of the product ab.」（１１８０頁左欄２４行～３１行）

（我々は，ｃ＝ａｂの加法的共有を生成することを望む。我々は，ａｂ＝Σi,jａｉｂｉであるため，ａｂの加法的共有を取得するには，それぞれ独立の項ａｉｂｉの加法的共有を得ることで十分であることに言及する。その範囲で，我々は，同じ秘密の加法的共有を，秘密の情報的共有に変換することを，２つのパーティーに許すという，２パーティー・プロトコルを使用する。プレーヤーは，積ａｂの加法的共有を得るために，ペアワイズ方式において，このプロトコルに従事する。

ｄ．「4.2 Signature Generation

We now describe the signature generation protocol, which is run on inputm (the hash of the message M being signed) and the output of the key generation protocol described above. We note that the latter protocol is a t-out-of-n protocol (and thus the secret key x is shared using (t ,n) Shamir secret-sharing).

Let S⊆[1..n] be the set of players participating in the signature protocol. We assume that |S| = t’ where t＜t'≦n. For the signing protocol we can share any ephemeral secrets using a (t’, t’) secret sharing scheme, and do not need to use the general (t,n) structure. We note that using the appropriate Lagrangian coefficients λi,S each player in S can locally map its own (t,n) share xi of x into a (t’, t’) share wi = λi,Sxi of x, i.e. x =Σi ∈S wi . Since Xi = ｇxi and λi,S are public values all the players can compute Wi = ｇwi = Xiλi,S.」（１１８４頁右欄１行～１４行）

（４．２ 署名の生成

ここで，入力ｍ（署名されたメッセージＭのハッシュ）で動作する，署名生成のプロトコルと，上述した鍵生成プロトコルの出力について説明する。後のプロトコルが，ｔ－アウト・オブ－ｎプロトコル（したがって，秘密鍵ｘは，（ｔ，ｎ）シャミア秘密共有を用いることで，共有される。）であることに留意されたい。

Ｓ⊆［１．．ｎ］を署名プロトコルに参加するプレーヤーにセットする。 ｜Ｓ｜ ＝ ｔ’と仮定する。 ここでｔ＜ｔ’≦ｎである。署名プロトコルの場合，（ｔ’，ｔ’）秘密共有スキームを使用して，一時的な秘密を共有でき，一般的な（ｔ，ｎ）構造を使用する必要はない。適切なラグランジェ係数λｉＳを使用することで，Ｓにおけるそれぞれのプレーヤーは，ｘの独自の（ｔ，ｎ）共有ｘｉを，ｘの（ｔ’，ｔ’）共有ｗｉ＝λｉ，Ｓｘｉに，ローカルにマッピングできることに留意されたい。例えば，ｘ＝Σｉ∈Ｓｗｉである。Ｘｉ＝ｇｗｉ及びλｉ，Ｓが公開値なので，全てのプレーヤーは，Ｗｉ＝ｇＷｉ＝Ｘｉλｉ，Ｓが計算できる。）

という内容が記載されていることは読み取れるものの，上記引用の記載内容からは，特に，「取引公開鍵」に関する技術的事項の周知性を読み取ることはできない。

以上に検討したとおりであるから，請求人の審判請求時の主張，及び，甲第１号証の内容を採用したとしても，拒絶理由が解消するとは認められない。

第５．むすび

以上のとおりであるから，本願は，特許法３６条４項１号に規定する要件を満たしていない。

したがって、他の拒絶理由について検討するまでもなく、本願は拒絶すべきものである。

よって，結論のとおり審決する。