2016-004868

特願２０１３－５２５３９５「属性ベースのデジタル署名」拒絶査定不服審判事件〔平成２４年　３月　１日国際公開，ＷＯ２０１２／０２５８６６，平成２５年　９月１９日国内公表，特表２０１３－５３６６５１〕について，次のとおり審決する。

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

【理　由】 第１．手続の経緯 本願は，２０１１年８月２２日（パリ条約による優先権主張外国庁受理２０１０年８月２４日　欧州特許庁）を国際出願日とする出願であって， 平成２５年２月２１日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，平成２６年８月１９日付けで審査請求がなされると共に手続補正がなされ，平成２７年４月８日付けで審査官により拒絶理由が通知され，これに対して平成２７年１０月８日付けで意見書が提出されると共に手続補正がなされたが，平成２７年１１月２０日付けで審査官により拒絶査定がなされ（謄本送達；平成２７年１２月８日），これに対して平成２８年４月４日付けで審判請求がなされると共に手続補正がなされ，平成２８年６月３０日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。 第２．平成２８年４月４日付けの手続補正の却下の決定 ［補正却下の決定の結論］ 平成２８年４月４日付け手続補正を却下する。 ［理由］ １．補正の内容 平成２８年４月４日付けの手続補正（以下，「本件手続補正」という）により，平成２７年１０月８日付けの手続補正により補正された特許請求の範囲， 「　【請求項１】 第１のユーザのための第１の署名鍵及びドキュメントに基づいて，前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと， 第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するための再署名ユニットであって，前記再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される，再署名ユニットとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる，属性ベースのデジタル署名システム。 【請求項２】 前記再署名ユニットは第１の署名を第２の署名へ変換する，請求項１に記載のシステム。 【請求項３】 第２の署名は前記再署名鍵により決定される属性の第２のセットと関連し，属性の第２のセットは，複数の属性を有する，請求項１に記載のシステム。 【請求項４】 第１の署名は属性の第１のセットと関連し，属性の第１のセットは複数の属性を有し， 前記再署名ユニットは，属性の第１のセットが条件のセットを満足する場合だけ，第２の署名を生成する，請求項１又は３に記載のシステム。 【請求項５】 前記再署名鍵は前記属性上の前記条件のセットを暗号によって組み込む，請求項４に記載のシステム。 【請求項６】 属性の第２のセットと関連した第２の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し，前記再署名鍵は，前記再署名ユニットが，第１の署名を属性の第２のセットと関連する第２の署名へ変換可能にし，第２の署名鍵は，第２の署名生成ユニットが前記ドキュメントに基づいて属性の第２のセットと関連する署名を生成可能にする，請求項３に記載のシステム。 【請求項７】 前記再署名鍵生成器は，更に，第２の署名鍵に基づいて第１の署名鍵を生成し，第１の署名鍵及び前記再署名鍵は，鍵のペアとして生成され，第１の署名鍵は第１の署名生成ユニットへ供給され，前記再署名鍵は前記再署名ユニットへ供給される，請求項６に記載のシステム。 【請求項８】 条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し，前記再署名鍵は，前記再署名ユニットが，条件のセットを満足させる属性の任意のセットと関連する第１の署名を第２の署名へ変換可能にさせる，請求項４に記載のシステム。 【請求項９】 前記再署名ユニットは，第１の署名が条件のセットを満足する属性の第１のセットと関連するかどうかを検証するため公開鍵を使用し，第１の署名が条件のセットを満足する属性のセットと関連する場合だけ第２の署名を生成する，請求項４に記載のシステム。 【請求項１０】 属性の第２のセットを所有するユーザが，前記再署名ユニットに前記再署名鍵を供給することにより，属性の第２のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する，請求項１に記載のシステム。 【請求項１１】 請求項１に記載のシステムを有するワークステーション。 【請求項１２】 第１の署名生成ユニットによって，第１のユーザのための第１の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第１の署名を生成するステップと， 再署名ユニットによって，第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するステップであって，前記再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される，ステップとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる，属性ベースのデジタル署名システムの作動方法。 【請求項１３】 プロセッサシステムが請求項１２に記載の方法を実施させるための命令を有する，コンピュータプログラム。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は， 「　【請求項１】 第１のユーザのための第１の署名鍵及びドキュメントに基づいて，前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと， 第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するための再署名ユニットであって，前記再署名鍵が，ユーザのための署名鍵に基づき生成され，前記ユーザのための署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵を含むが，前記第１の署名鍵を含まない，再署名ユニットとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる，属性ベースのデジタル署名システム。 【請求項２】 前記再署名ユニットは第１の署名を第２の署名へ変換する，請求項１に記載のシステム。 【請求項３】 第２の署名は前記再署名鍵により決定される属性の第２のセットと関連し，属性の第２のセットは，複数の属性を有する，請求項１に記載のシステム。 【請求項４】 第１の署名は属性の第１のセットと関連し，属性の第１のセットは複数の属性を有し，前記再署名ユニットは，属性の第１のセットが条件のセットを満足する場合だけ，第２の署名を生成する，請求項１又は３に記載のシステム。 【請求項５】 前記再署名鍵は前記属性上の前記条件のセットを暗号によって組み込む，請求項４に記載のシステム。 【請求項６】 属性の第２のセットと関連した第２の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し，前記再署名鍵は，前記再署名ユニットが，第１の署名を属性の第２のセットと関連する第２の署名へ変換可能にし，第２の署名鍵は，第２の署名生成ユニットが前記ドキュメントに基づいて属性の第２のセットと関連する署名を生成可能にする，請求項３に記載のシステム。 【請求項７】 前記再署名鍵生成器は，更に，第２の署名鍵に基づいて第１の署名鍵を生成し，第１の署名鍵及び前記再署名鍵は，鍵のペアとして生成され，第１の署名鍵は第１の署名生成ユニットへ供給され，前記再署名鍵は前記再署名ユニットへ供給される，請求項６に記載のシステム。 【請求項８】 条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し，前記再署名鍵は，前記再署名ユニットが，条件のセットを満足させる属性の任意のセットと関連する第１の署名を第２の署名へ変換可能にさせる，請求項４に記載のシステム。 【請求項９】 前記再署名ユニットは，第１の署名が条件のセットを満足する属性の第１のセットと関連するかどうかを検証するため公開鍵を使用し，第１の署名が条件のセットを満足する属性のセットと関連する場合だけ第２の署名を生成する，請求項４に記載のシステム。 【請求項１０】 属性の第２のセットを所有するユーザが，前記再署名ユニットに前記再署名鍵を供給することにより，属性の第２のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する，請求項１に記載のシステム。 【請求項１１】 請求項１に記載のシステムを有するワークステーション。 【請求項１２】 第１の署名生成ユニットによって，第１のユーザのための第１の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第１の署名を生成するステップと， 再署名ユニットによって，第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するステップであって，前記再署名鍵が，ユーザのための署名鍵に基づき生成され，前記ユーザのための署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵を含むが，前記第１の署名鍵を含まない，ステップとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる，属性ベースのデジタル署名システムの作動方法。 【請求項１３】 プロセッサシステムが請求項１２に記載の方法を実施させるための命令を有する，コンピュータプログラム。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。 ２．補正の適否 （１）新規事項 本件手続補正は，平成２５年２月２１日付けで提出された，明細書，請求の範囲の日本語による翻訳文，及び，国際出願の願書に添付された図面の範囲内でなされたものであるから，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものである。 （２）目的要件 本件手続補正によって，補正前の請求項１に記載の「再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される」が，補正後の請求項１に記載の「再署名鍵が，ユーザのための署名鍵に基づき生成され，前記ユーザのための署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵を含むが，前記第１の署名鍵を含まない」と補正されたが，当該補正内容は，“再署名鍵の生成に用いられる署名鍵を，第２の署名鍵に限定する”ものであって，当該補正内容は，一応，本願明細書の段落【００５３】の記載，及び，段落【００６１】の記載から読み取れるので，本件手続補正は，特許請求の範囲の限定的減縮であるといえる。 よって，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第５項の規定を満たすものである。 そして，補正前に受けた拒絶理由通知において特許することができないものか否かについて判断が示された発明と，補正後の請求項に記載された事項により特定される発明とが，第３７条の発明の単一性の要件を満たす一群の発明に該当するものと，一応，読み取れるので，本件手続補正は，特許法第１８４条の１２第２項により読み替える同法第１７条の２第４項の規定を満たすものである。 （３）独立特許要件 そこで，本件手続補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定を満たすものであるか否か，即ち，補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か，以下に検討する。 ア．補正後の請求項１～補正後の請求項１３に係る発明 補正後の請求項１～補正後の請求項１３に係る発明（以下，これを「補正後の請求項各項に係る発明」という）は，上記「１．補正の内容」において，「補正後の請求項」として引用した記載にあるとおり，“再署名ユニットを有する，属性ベースのデジタル署名システム”に関するものであり， 当該「属性ベースのデジタル署名システム」は，本願明細書の発明の詳細な説明の記載によれば，段落【００２２】に記載の，次の機能を実現するものである。 「斯様なシステムに対する望ましい特性の１つは，その人自身（看護士又は代理）以外の誰も，医師に代わって署名を作ることが可能であってはならないということである。加えて，看護士と半信頼されたプロキシ（代理）との間の共謀でさえ，彼らにより医師（委託者）の秘密鍵ＳＫωｄｅｌｅｇａｔｏｒを回復可能にしてはならない。」 （なお，上記引用の日本語文の英語原文は， “One of the desirable properties for such a system is that no one by himself (nurse or proxy) should be able to produce the signature on behalf of the doctor. ” であって，これを日本語訳すると， “このシステムのための望まれる特性の一つは，何人（看護師，或いは，プロキシ）も，独力では，医師の代理として，署名を生成することはできない。” となり，原審における平成２７年４月８日付けの拒絶理由（以下，これを「原審拒絶理由」という）においても指摘されたとおり，上記において引用した，段落【００２２】における日本語訳は，誤訳である。） イ．本願明細書に開示されている事項 次に，本願明細書に，上記ア．において指摘した，補正後の請求項各項に係る発明の特性を実現するための事項が記載されているかについて検討する。 （ア）第１実施例（第１のスキーム） 本願明細書に記載された実施例の１つである「第１のスキーム」は，本願明細書の段落【００４８】，段落【００５０】～段落【００５７】に記載の，次のとおりのものである。 「【００４８】 第１のスキームにおいて，再署名鍵ＲＳＫの第１の部分は，エンティティＡ（受任者）に与えられ，再署名鍵ＲＳＫの第２の部分はプロキシに与えられる。エンティティＡ（受任者）が最初にメッセージに署名する場合だけ，有効な署名が半信頼されたプロキシにより作られる。この場合，受任者は，余分の秘密鍵，すなわち再署名鍵ＲＳＫの部分を格納しなければならない。」 「【００５０】 図３は，属性ベースの代理再署名スキームの機能的図を提供する。ステップ３０１において，エンティティ「Ａ」は，再生成アルゴリズムを用いて，再署名鍵ＲＳＫを生成する。ＲＳＫは，２つのコンポーネント：プロキシに対するコンポーネント及びエンティティ「Ｂ」に対するコンポーネントを有する。これは，第１のデザインされたスキームの場合である。上記で紹介された第２のスキームにおいて，これは，プロキシに対する１つのコンポーネントを有する。ステップ３０２及び３０３において，再署名鍵，すなわちＲＳＫｐｒｏｘｙ及びＲＳＫｄｅｌｅｇａｔｅｅが，プロキシ「Ｐ」及びエンティティ「Ｂ」それぞれに送られる。ステップ３０４において，エンティティ「Ｂ」は，ＲＳＫｄｅｌｅｇａｔｅｅ（第１のスキームで）又はＳＫｄｅｌｅｇａｔｅｅ（第２のスキームで）を使用して，エンティティ「Ｂ」の署名を生成する。ステップ３０５において，エンティティ「Ｂ」は，プロキシ「Ｐ」にステップ４の出力を送る。ステップ３０６において，半信頼されたプロキシは，エンティティ「Ｂ」から受信された署名をエンティティ「Ａ」の署名へ変換する。ステップ３０７において，プロキシ「Ｐ」は，エンティティ「Ａ」を代表して作られた署名を検証器「Ｖ」（又は，署名されたメッセージの受信器）へ送る。ステップ３０８において，検証器「Ｖ」は，署名がエンティティ「Ａ」からであるかどうか，属性の正しいセットに関係のある秘密鍵により署名されているかどうかを検証する。」 「【００５１】 第１のスキームにおいて，ユーザ属性はＺｐの要素であり，最大ｋ個の属性があるとみなされている。実際上，属性ストリングをＺｐの要素へマップするための対立耐性のあるハッシュ関数を使用できる。当該スキームは，４つのアルゴリズムを有する。 セットアップ セットアップアルゴリズムは，主要なオーダーｐ並びにランダムジェネレータｇ及びｈの双一次グループＧ０を選択する。また，双一次マップｅ：Ｇ０ｘＧ０→Ｇ１を選び，ここで，Ｇ１はターゲットグループである。加えて，セットアップは，無作為に t,y,x1,x2,・・・,xk∈Zp を取り上げ，属性セット Ω={a1,a2,...,ak} のために， Tj=gxj 及び T'j=hxj を（１≦ｊ≦ｋ）に対してセットする。公開鍵ＰＫ及びマスター鍵ＭＫは，以下のコンポーネントを有する。 PK=(g,h,{Tj}kj=1,{Tj'}kj=1) MK=({xj}kj=1)」 「【００５２】 鍵生成（ＭＫ，ω） 鍵生成アルゴリズムは，属性セットωと関連するユーザ秘密鍵を出力する。当該アルゴリズムは，ランダムな要素 ｘ∈Ｚ＊ｐ を取り上げる（ここで，ｘは各ユーザに対して固有である）。秘密鍵ＳＫωは，以下のコンポーネントを有する。 SKω=({S(1)j=gx/xj}aj∈ω S(2)=gx).」 「【００５３】 再鍵生成（ＳＫω）” このアルゴリズムは，委託者により実行される。再鍵生成アルゴリズムは，委託者に代わって署名するためのプロキシ及び受任者により用いられる再署名鍵を出力する。当該アルゴリズムは，ランダムな要素 ｄ∈Ｚｐ を取り上げて，これらをｄ＝ｄ１＋ｄ２となるような２つの部分ｄ１，ｄ２へ分割する。再署名鍵ＲＳＫωは，一方が受任者に対するコンポーネント，他方がプロキシに対するコンポーネントである，以下の２つのコンポーネントを有する。 RSKdelegatee=({gxd1/xj}aj∈ω,gxd1,gd,hd) RSKproxy=({gxd2/xj}aj∈ω,gxd)」 「【００５４】 署名（ＲＳＫｄｅｌｅｇａｔｅｅ，ｍ） このアルゴリズムは，メッセージ ｍ∈Ｇ０ に署名するための受任者により実行される。当該アルゴリズムは，ランダムな要素 ｓ’∈Ｚ＊ｐ を選んで，以下のコンポーネントを有するσｄｅｌｅｇａｔｅｅを計算する。 σdelegatee=({σ(1)jdee=gxd1/xj・hds'm}aj∈ω σ(2)dee=gxd1/s' σ(3)dee=gds' σ(4)dee=gs')」 「【００５５】 再署名（ＲＳＫｐｒｏｘｙ，σｄｅｌｅｇａｔｅｅ，ｍ） このアルゴリズムは，プロキシにより実行される。第２のレベル（又は，最終的な署名）を作る前に，プロキシは，以下の態様で受任者により作られた署名を検証する。 I(1)=e(σ(1)jdee,Tj) =e(g,g)xd1・e(g,h)ds'mxj:∀aj∈w I(2)=e(σ(2)dee,σ(4)dee)・e((σ(3)dee)m,Tj') =e(g,g)xd1・e(g,h)ds'mxj:∀aj∈w」 「【００５６】 ここで，Ｉ（１）＝Ｉ（２）の場合，プロキシは第２のレベルの（又は最終的な）署名を作るため受任者により作られる署名を変換する。当該アルゴリズムは，ランダムな要素 ｒ∈Ｚ＊ｐ を選んで，第２のレベルの署名を作る。 σproxy=({σ(1)jp=gxd2r/xj・gxd1r/xj・hds'mr}aj∈ω ={gxdr/xj・hds'mr}aj∈ω σ(2)p=(σ(3)dee)r=gds'r σ(3)p=gxdr)」 「【００５７】 検証（σｐｒｏｘｙ，ＰＫ） 以下の式が成り立つ場合，署名が受け入れられる。 e(σ(1)jp,Tj)=e(σ(3)p,g)・e(T'j,(σ(2)p)m):∀aj∈ω e(gxdr/xj・hds'mr,Tj)=e(gxdr,g)・e((gds'r)m,T'j):∀aj∈ω e(g,g)xdr・e(g,h)drs'mxj=e(g,g)xdr・e(g,h)drs'mxj:∀aj∈ω」（添え字等を，一部変更している。以下，同じ。） （イ）第２実施例（第２のスキーム） 本願明細書に記載された「第２実施例（第２のスキーム）」は，本願明細書の段落【００５９】～段落【００６５】に記載の，次のとおりのものである。 「【００５９】 セットアップ セットアップアルゴリズムは，主要なオーダーｐ並びにランダムジェネレータｇ及びｈの双一次グループＧ０を選択する。当該アルゴリズムは，双一次マップｅ：Ｇ０ｘＧ０→Ｇ１を選ぶ。これ（の選択）に加えて，セットアップは，無作為に x1,x2,・・・,xk∈Zp を取り上げ，属性セット Ω={a1,a2,...,ak} のために， Tj=gxj 及び T'j=hxj を（１≦ｊ≦ｋ）に対してセットする。公開鍵ＰＫ及びマスター鍵ＭＫは，以下のコンポーネントを有する。 PK=(g,h,{Tj}kj=1,{Tj'}kj=1) MK=({xj}kj=1)」 「【００６０】 鍵生成（ＭＫ，ω） 鍵生成アルゴリズムは，属性セットωと関連するユーザ秘密鍵を出力する。アルゴリズムは，ｘ＝ｔｑとなるように，ランダムな要素 ｘ，ｔ，ｑ∈Ｚ＊ｐ を取り上げる（ここで，ｘ，ｔ及びｑは各ユーザに対して固有である）。秘密鍵ＳＫωは，以下のコンポーネントを有する。 SKω=({S(1)=gx/xj}aj∈ω S(2)=gx,{S(3)=gt/xj}aj∈ω,S(4)=gq)」 「【００６１】 再鍵生成（ＳＫωｄｅｌｅｇａｔｏｒ） 再鍵生成アルゴリズムは，受任者からの署名を委託者の署名に変換するためにプロキシにより用いられる再署名鍵を出力する。当該アルゴリズムは，ランダムな要素 ｄ∈Ｚｐ を取り上げる。再署名鍵ＲＳＫωは，以下の２つのコンポーネントを有する。 RSK(proxy)=(RSK(1)=(S(1)j)d={gxd/xj}aj∈ω RSK(2)=(S(2))d=gxd)」 「【００６２】 署名（ＳＫωｄｅｌｅｇａｔｅｅ，ｍ） このアルゴリズムは、メッセージ” ｍ∈Ｇ０ に署名するために受任者により実行される。当該アルゴリズムは，ランダムな要素 ｓ’∈Ｚ＊ｐ を選んで，自分自身の秘密鍵を使用して署名σｄｅｌｅｇａｔｅｅを計算する。σｄｅｅとも呼ばれる署名σｄｅｌｅｇａｔｅｅは，以下のコンポーネントを有する。 」 「【００６３】 再署名（ＲＳＫ，σｄｅｌｅｇａｔｅｅ，ｍ） このアルゴリズムは，プロキシにより実行される。当該アルゴリズムは，ランダムな要素 ｒ∈Ｚ＊ｐ を選んで，受任者の署名を委託者の署名へ変換する。署名を変換する前に，プロキシは，署名が対応する受任者からの実際有効な署名であるかどうかを検証する。検証は，以下のように進む。 」 「【００６４】 ここで，Ｉ（１）＝Ｉ（２）の場合，検証は成功し，プロキシは，第２のレベルの（又は，最終的な）署名を生成する。第２のレベルの署名の生成は，以下のステップを有する。 第１のステップにおいて，プロキシは，以下を計算する。 第２のステップにおいて，プロキシは，以下を計算する。 第３のステップにおいて，プロキシは，以下を計算する。 c=H((Z(2)),gr)=H(e(h,g)ms',gr) ここで，「Ｈ」は，ハッシュ関数である。 第４のステップにおいて，プロキシは，以下を計算する。 最終ステップにおいて，プロキシは，署名を出力する。 σproxy=(σ(1)jp,σ(2)p,σ(3)p,σ(4)p)」 「【００６５】 検証（σｐｒｏｘｙ，ＰＫ） 変換された署名を検証するために，検証器は，以下のステップを実施する。 第１ステップにおいて，検証器は，以下を計算する。 c'=H(e(σ(3)p,hm),σ(2)p)=H(e(gs',hm),gr) 第２ステップにおいて，以下の式が成り立つ場合，検証器は，署名を受け入れる。 」 ウ．「機能」の実現性についての検討 上記ア．において指摘した，補正後の請求項各項に係る発明が満たすべき「機能」について，上記イ．に引用の本願明細書の発明の詳細な説明に記載の第１実施例，及び，第２実施例が，当該「機能」を実現し得るか，以下に検討する。 （ア）第１実施例について 上記ア．において指摘した，補正後の請求項各項に係る発明が満たすべき「機能」とは，「第１のユーザ」が，「再署名ユニット」になりすます，即ち，「第１のユーザ」が，「再署名ユニット」が行うべき処理を代行しても，代行したことを検出できる。 或いは，「再署名ユニット」が，「第１のユーザ」になりすましたことを検出できることである。 これを，第１実施例に当てはめると，検証ステップにおいて，「受任者」が，「プロキシ」になりすましたこと，及び，「プロキシ」が，「受任者」になりすましたことを検出できれば，当該「機能」を実現していることになる。 今，「受任者」が，「受任者」が署名に用いるランダムな要素 ｓ’∈Ｚ＊ｐ と，「プロキシ」が第２レベルの署名を生成する際に用いるランダムな要素 ｒ∈Ｚ＊ｐ とを選択する。この２つのランダムな要素は，任意の値であるから，選択者が同一であることを妨げない。 次に，「受任者」は， 「メッセージｍ」， 「受任者」の署名鍵「ＲＳＫｄｅｌｅｇａｔｅｅ」の「｛ｇｘｄ１／ｘｊ｝aj∈ω，」，「ｇｘｄ１」， 「公開鍵ＰＫ」の「ｇ」，「ｈ」， を用いて，署名“σｐｒｏｘｙ’”を次のように計算する。 σproxy'=({σ(1)jp'=(gxd1/xj)r・hs'mr}aj∈ω) σ(2)p'=gs'r σ(3)p'=(gxd1)r) 次に，署名“σｐｒｏｘｙ’”を，上記引用の第１実施例の検証ステップ（以下，これを「検証ステップ１」という）において検証する。 検証ステップ１の左辺に，上記で求めた，“σｐｒｏｘｙ’”の“σ（１）jｐ’”を入力して計算すると， e(σ(1)jp',Tj)=e((gxd1/xj)r・hs'mr,Tj):∀aj∈ω =e(gxrd1/xj・hs'mr,gxj):∀aj∈ω =e(gxrd1/xj,gxj)・e(hs'mr,gxj):∀aj∈ω =e(g,g)xrd1・e(h,e)s'mrd1:∀aj∈ω となる。 次に，検証ステップ１の右辺に，上記で求めた，“σ（２）ｐ’”，“σ（３）ｐ’”を入力して計算すると， e(σ(3)p',g)・e(T'j,(σ(2)p')m):∀aj∈ω =e((gxd1)r,g)・e(T'j,(gs'r)m):∀aj∈ω =e(gxrd1,g)・e(hxj,gs'mr):∀aj∈ω =e(g,g)xrd1・e(h,g)s'mrxj:∀aj∈ω となり，右辺の計算結果は，先に計算した左辺の計算結果と一致する。 以上の検討結果は，「受信者」，即ち，「第１のユーザ」が，「プロキシ」，即ち，「再署名ユニット」に代わって，「第２レベルの署名」，即ち，「第２の署名」を生成することが可能であることを意味しているので，第１実施例は，なりすましを防止することはできず，上記において指摘した，補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。 （イ）第２実施例について 第２実施例では，「プロキシ」が，「受任者」になりすませることを示す。 「プロキシ」は，「プロキシ」が第２レベルの署名を生成する際に用いるランダムな要素 ｒ∈Ｚ＊ｐ と，「受任者」が署名に用いるランダムな要素 ｓ’’∈Ｚ＊ｐ とを選択する。この２つのランダムな要素は，任意の値であるから，選択者が同一であることを妨げない。 次に，「プロキシ」は，「メッセージｍ」， 再署名鍵「ＲＳＫω」の「｛ｇｘｄ／ｘｊ｝aj∈ω，」，「ｇｘｄ」， 「公開鍵ＰＫ」の「ｇ」，「ｈ」， を用いて，第２レベルの署名を次のように計算する。 c''=H(e(h,g)ms'',gr) σ(1)''jp={(gxd/xj)r・hc''r}aj∈ω σ(2)''p=gr σ(3)''p=gs'' σ(4)''p=(gxd)r σ''proxy=(σ(1)''jp,σ(2)''p,σ(3)''p,σ(4)''p) 上記で求めた，「プロキシ」による署名を，上記に引用した，第２実施例における検証ステップ（以下，これを「検証ステップ２」という）において検証する。 検証ステップ２における第１ステップの式の左辺に，上記で求めた，“σ（３）’’ｐ”と，“σ（２）''ｐ”を入力して計算する。 c'''=H(e(σ(3)''p,hm),σ(2)''p) =H(e(gs'',hm),gr) =H(e(g,h)s''m,gr)=c'' 次に，検証ステップ２の第２のステップの式の左辺に，上記で求めた，“σ（１）''ｊｐ”を代入して計算すると， e(σ(1)''jp,Tj)=e((gxd/xj)r・hc''r,gxj):∀aj∈ω =e(gxdr/xj・hc''r,gxj):∀aj∈ω =e(g,g)xdr・e(h,g)c''rxj:∀aj∈ω となる。 次に，第２のステップの右辺に，上記で求めた，“σ（２）''ｐ”と，“σ（４）’’ｐ”とを代入して計算すると， e(σ(4)''p,g)・e((σ(2)''p)c''',T'j) =e((gxd)r,g)・e((gr)c''',hxj):∀aj∈ω =e(gxdr,g)・e(grc''',hxj):∀aj∈ω =e(g,g)xdr・e(g,h)rc'''xj:∀aj∈ω ここで，第１のステップの計算結果から，ｃ’’’＝ｃ’’であるから，結局， e(σ(4)''p,g)・e((σ(2)''p)c''',T'j) =e(g,g)xdr・e(g,h)rc''xj:∀aj∈ω となり，右辺の計算結果は，先に計算した左辺の計算結果と一致する。 以上の検討結果は，「プロキシ」，即ち，「再署名ユニット」が，「受任者」，即ち，「第１のユーザ」の結果を用いることなく，「再署名ユニット」単独で取得可能な情報のみにより，「第２レベルの署名」，即ち，「第２の署名」を生成することが可能であることを意味しているので，第２実施例は，上記において指摘した，補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。 （ウ）第１実施例，及び，第２実施例以外の構成について 上記（ア），及び，（イ）において検討したとおり，第１実施例，及び，第２実施例の何れを用いても，補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。 そこで，本願明細書の発明の詳細な説明，及び，図面に記載された，第１実施例，及び，第２実施例以外の構成によって，本願の請求項各項に係る発明が満たすべき「機能」を実現することができないかについて，検討する。 第１実施例において，「受任者」によるなりすましを不可能にするためには，「第２レベルの署名」の作成において，「プロキシ」固有の秘密情報を用いるか，或いは，「検証器」が，「第２レベルの署名」が，「プロキシ」によって作成されたことが確認できないと，「第２レベルの署名」の検証を行わないといった構成を有することである。 しかしながら，上記指摘の「受任者」によるなりすましに対抗する構成については，本願明細書の発明の詳細な説明，及び，図面には記載されていない。 同様に，第２実施例において，「プロキシ」のみでの，「第２レベルの署名」の生成を不能にするためには，「第２レベルの署名」の作成において，「受任者」固有の秘密情報を用いるか，「検証器」が，「第２レベルの署名」が，「受任者」の署名を再変換したものであることが確認できないと，「第２レベルの署名」の検証を行わないといった構成を有することである。 しかしながら，上記指摘の「プロキシ」単体による，「受任者」の署名を伴わない，「第２レベルの署名」の作成に対抗する構成については，本願明細書の発明の詳細な説明，及び，図面には記載されていない。 なお，請求人は，平成２８年４月４日付けの審判請求書（以下，これを「請求書」という）において， 「また，偽造とは，「ほんものに類似のものをつくること。にせものをつくること。」である（広辞苑第５版）。にせものを作る理由が，既存のインフラ／スキームをあざむく，だますためであることは，偽造テレホンカード（公衆電話を現状のまま使う），偽造コイン（自動販売機，ATM等を現状のまま使う），偽造切手，偽造紙幣の例より明らかである。 不正を行うプロキシに対して，スキームのとおり振る舞うことを強制する機構が明細書中に不存在であることを理由に，偽造署名の生成が可能としているが，偽造は上記のように既存スキームに従うことを前提としたものであり，審査官殿の技術認識には重大な誤りが存在する。 審査官殿が偽造可能とする結論に至る行為は，既存インフラ／スキームの破壊，改変，又は乗っ取りに該当するものであり，偽造とは相容れない。そもそも，既存インフラ／スキームの破壊，改変，又は乗っ取りが容易にできるのであれば，偽造など行わない。破壊，改変，又は乗っ取りのリスクが高いからこそ，またこうした行為には費用，労力，手間がかかるからこそ，偽造を選択する（例えば，全国に点在する公衆電話すべてに手を加えるより，入手が容易なテレホンカードをもとに，ほんものに類似するにせもののテレホンカードを作ることを選択する）のであり，審査官殿による誤認が本願の審査に重大な影響を及ぼすことは明らかである。 先の意見書で述べた「前者の受任者Ｂ→検証器Ｖへの直接の経路は，明細書において何ら記載されていない。受任者ＢはプロキシＰに対し出力する存在である。」について，審査官殿は何ら考慮も判断もしていない。同様に「審査官殿は，出力が行われれば左辺＝右辺を満たすであろうσproxy”については記載するものの，その前段で，プロキシＰがこのσproxy”を出力することがどのように可能にされるのかを何ら明らかにしていない。」についても，審査官殿は何ら考慮も判断もしていない。」 と主張しているが，“なりすまし”（拒絶理由における「偽造」）については，上記「（３）独立特許要件」の「ウ．「機能」の実現性についての検討」において指摘したとおりであるから，請求人の請求書における上記引用の主張を採用することはできない。 （エ）以上（ア）～（ウ）において検討したとおりであるから，本願明細書の発明の詳細な説明，及び，図面には，補正後の請求項各項に係る発明が満たすべき「機能」を実現するための構成が記載されておらず， よって，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。 エ．独立特許要件むすび 以上，（ア）～（エ）において検討したとおりであるから，本件出願は，明細書及び図面の記載が上記の点で不備のため，特許法第３６条第４項第１号に規定する要件を満たしていないので，補正後の請求項に記載されている事項により特定される発明は特許出願の際独立して特許を受けることができない。 ３．補正却下むすび したがって，本件手続補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 よって，補正却下の決定の結論のとおり決定する。 第３．本願発明について 平成２８年４月４日付けの手続補正は，上記のとおり却下されたので，本願の請求項１～請求項１３に係る発明は，平成２７年１０月８日付けの手続補正により補正された特許請求の範囲の請求項１～請求項１３に記載された，上記「第２．平成２８年４月４日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１～補正前の請求項１３として引用した記載により特定されるものである。 第４．原審の拒絶理由 原審における平成２７年４月８日付けの拒絶理由（以下，これを「原審拒絶理由」という）は，概略，次のとおりである。 「　　　　　　　　　　　　　　理　由 １．（実施可能要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。 ２．＜省略＞ ３．＜省略＞ ４．（新規性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから，特許法第２９条第１項第３号に該当し，特許を受けることができない。 ５．（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 記 ●理由１（実施可能要件）について ・請求項　１－１３ 本願明細書に記載の各数式において，定義が明らかでない記号が用いられ，成立しない式が成立するとされており，誤記と思われるものが存在することから，それら各数式の意味を明確に把握することができない。以下に不明な式を挙げる。 １．＜省略＞ ２．＜省略＞ ３．＜省略＞ ４．＜省略＞ ５．＜省略＞ ６．段落［００６４］の Ｚ(2)の計算式は成り立たない。一行目の ｅ（ｇ-s't/xj，ｇqs'） が二行目で ｅ（ｇ，ｇ）-s'tq/xj に変形されているが，二行目の指数部分は -s'2tq/xj となるべきであり，三行目の指数部分も -s'2x/xj となるべきである。したがって， Ｚ(2)＝ｅ（ｈ，ｇ）ms' は成立しない。 ７．＜省略＞ ・請求項　３－９ 請求項３には「第２の署名は前記再署名鍵により決定される属性の第２のセットと関連し」と記載されている。しかしながら，第２の署名と関連する属性の第２のセットを，「前記再署名鍵により決定される」ものとすることを，具体的にどのようにして実現するのか，発明の詳細な説明の記載を参照しても全く不明である。 ・請求項　１－１３ 本願請求項１－１３は，属性ベースのデジタル署名システム，署名を生成するステップを有する方法，前記方法を実施させるための命令を有するコンピュータプログラム，を請求するものである。 ところで，デジタル署名スキームは，署名鍵を所有する正当なユーザが，検証鍵で検証可能な署名を生成できるという以外に，署名鍵を所有しない不当なユーザが，正当な署名と同様に検証鍵で検証可能な不正な署名を偽造することができない，という要件をも満たす必要がある。これは，署名が偽造可能なものであるとすると，偽造された署名は正当な署名と同様に検証されることから，正当な署名と偽造された署名とを区別することができず，正当な署名であっても，それが偽造されたものであることを否定できないため，署名としての効力を認めることができないからである。 そこで，本願明細書の発明の詳細な説明に記載された属性ベースの代理再署名スキームについて検討すると，このスキームは，受任者であるエンティティＡが，所定の属性に対応するエンティティＡの署名鍵を用いて署名を作成し，プロキシＰが，作成した署名を，再署名鍵を用いて変換し，変換後の署名は，エンティティＢの属性に対応する検証鍵を用いて検証可能である，というものである。そうすると，このスキームにおいて，変換後の署名は，エンティティＢの署名に相当するから，前記したことを考慮すれば，エンティティＡおよびプロキシＰの何れも，独力では，変換後の署名（エンティティＢの署名）と同様に検証可能な署名を偽造可能であってはならない。このことは，本願の国際出願の出願当初の明細書にも"One of the desirable properties for such a system is that no one by himself (nurse or proxy) should be able to produce the signature on behalf of the doctor."（6頁19-21行）として記載されていることである。（なお，翻訳文の段落［００２２］の記載「斯様なシステムに対する望ましい特性の１つは，その人自身（看護師又は代理）以外の誰も，医師に代わって署名を作ることが可能であってはならないということである。」は，誤訳である。「その人自身・・・以外」なる日本語に相当する文は，国際出願の出願当初の明細書に存在しない。"by himself"は「一人で」「独力で」の意味であるから，前記の文は「斯様なシステムに対する望ましい特性の一つは，誰も独力で（看護士またはプロキシでも）医師に代わって署名を作ることが可能であってはならないということである。」とでも翻訳すべきものである。） しかしながら，本願明細書の発明の詳細な説明に第１実施例として記載の発明においては，受任者が，委託者の第２のレベルの署名を，プロキシによる再署名の処理なしで，偽造することができる。第２実施例として記載の発明においては，プロキシが，委託者の第２のレベルの署名を，受任者による署名を用いることなく，偽造することができる。すなわち，明細書に記載の例でいえば，看護師あるいはプロキシが，それぞれ独力で，医師の署名を偽造することができ，偽造された署名は，医師の正規の署名として受理される。以下に説明する。 １．第１実施例 受任者は，ランダムな要素ｒ，ｓ'∈Ｚp*を生成し，メッセージｍ，署名鍵ＲＳＫdelegateeの｛ｇx/xj d1｝aj∈ω，ｇxd1，公開鍵ＰＫのｇ，ｈを用いて，第２のレベルの署名の偽造署名を以下のように計算する。 σproxy'＝（｛σjp(1)' ＝（ｇx/xj d1）r・ｈs'mr｝aj∈ω σp(2)' ＝ ｇs'r σp(3)' ＝（ｇxd1）r） この偽造署名について，段落［００５７］の検証式が正規の署名と同様に成立することから，偽造署名は正規の署名として受理される。偽造署名の作成に，プロキシによる再署名の処理は必要としない。 ２．第２実施例 プロキシは，ランダムな要素ｒ，ｓ"∈Ｚp*を生成し，メッセージｍ，再署名鍵ＲＳＫωの｛ｇx/xj d｝aj∈ω，ｇxd，公開鍵ＰＫのｇ，ｈを用いて，第２のレベルの署名の偽造署名を以下のように計算する。 ｃ" ＝ Ｈ（ｅ（ｈ，ｇ）ms"，ｇr） σjp(1)" ＝｛（ｇx/xj d）r・ｈc"r｝aj∈ω σp(2)" ＝ ｇr σp(3)" ＝ ｇs" σp(4)" ＝（ｇxd）r σproxy"＝（σjp(1)"，σp(2)"，σp(3)"，σp(4)"） この偽造署名について，段落［００６５］の検証式が正規の署名と同様に成立することから，偽造署名は正規の署名として受理される。偽造署名の作成に，受任者の署名は必要としない。 以上で述べたとおり，本願明細書の発明の詳細な説明に記載の発明は，受任者あるいはプロキシが，独力で委託者の署名を偽造可能なものであるから，請求項１－１３に記載のデジタル署名に関して，実施可能なものが実質的に開示されていない。 よって，この出願の発明の詳細な説明は，当業者が請求項１－１３に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。 ●理由２（明確性）について ＜省略＞ ●理由４（当審注；“理由３”の誤記）（発明該当性）について ＜省略＞ ●理由４（新規性）について ・請求項　１，２，１１－１３ ・引用文献等　１ ・備考 引用文献１には，ユーザＡのＩＤから生成した署名鍵とメッセージとから，前記メッセージに対するユーザＡの署名を生成し，前記ユーザＡの署名と再署名鍵とから，前記メッセージに対するユーザＢの署名を生成し，前記ユーザＢの署名の生成は，ユーザＡのＩＤとユーザＢのＩＤとに基づく，ＩＤベースのデジタル署名システム，が記載されている。（特に I. INTRODUCTION, IV. BIDIRECTIONAL CERTIFICATELESS PROXY RE-SIGNATURE） 引用文献１に記載の発明において，署名の生成は，ユーザ及びプロキシが行う（I. INTRODUCTION, A. Proxy re-signature and related work）ところ，技術常識を考慮すれば，その署名生成は，ユーザ及びプロキシがそれぞれ有する，各自のユニットにて行われることは，自明である。 そして，本願明細書段落［０００３］の記載「しかしながら，ヘルスケア組織では，属性は，通常，ユーザの役割及び同一性を記述するために用いられ，データへのアクセスはユーザ属性に基づいて付与されている。・・・これらの属性は，また，特定のドメイン（例えば名前又は識別子）の個人に固有である個々の属性を有する。例えば，処方箋が特定の役割を持つ特定のユーザ（例えば医師ジョンスミス）により署名された場合，薬局は，処方箋を受理するだろう。」を参照すれば，本願における「属性」とは，ユーザの同一性を記述するために用いられる「ジョンスミス」の如きものを含むから，ユーザのＩＤを包含する概念である。 そうすると，引用文献１に記載の発明における，ユーザの「ＩＤ」は，本願請求項に係る発明の「属性」に相当するから，本願の請求項１，２，１１－１３に係る発明は，引用文献１に記載の発明と同一である。 ●理由５（進歩性）について ・請求項　１，２，１１－１３ ・引用文献等　１ ・備考 これら請求項に係る発明は引用文献１に記載の発明と同一であるから，引用文献１に記載の発明に基づいて当業者が容易に想到し得たものでもある。 ・請求項　３－１０ ・引用文献等　１，２ ・備考 引用文献２には，ＩＤ情報から検証用の公開鍵を生成し，公開鍵からさらに署名用の秘密鍵を生成する方式であるＩＤ型暗号方式において，ＩＤ情報とは，ユーザの職業，所属，資格，現在位置等の属性情報を含む情報のことを意味すること，及び，ＩＤ情報を携帯電話端末から発行センタへと送信し，携帯電話端末において，一方向性関数Ａを用いてＩＤ情報から公開鍵を生成し，ＩＤ情報を受信した発行センタ１は，一方向性関数Ａを用いてＩＤ情報から公開鍵を生成し，センタ秘密鍵と公開鍵から一方向性関数Ｂを用いて秘密鍵を生成し，秘密鍵の生成が終了すると，ＳＳＬ等を利用して携帯電話端末との間で認証を行い，認証が完了すると，発行センタは生成した秘密鍵を暗号化して携帯電話端末へ送信し，帯電話端末は受信した秘密鍵を復号化し，復号化した秘密鍵と生成した公開鍵とを保存し，ユーザＡがユーザＢの属性情報を取得する場合には，ユーザＡの携帯電話端末からユーザＢの携帯電話端末へとチャレンジ情報を送信し，ユーザＢの携帯電話端末がチャレンジ情報を受信すると，端末内に保存されているＩＤ情報から開示したいＩＤ情報を選択し，そのＩＤ情報に対応する秘密鍵でチャレンジ情報を署名し，ユーザＡの携帯電話端末に対してＩＤ情報および署名情報を送信し，ユーザＡの 携帯電話端末がＩＤ情報および署名情報を受信すると，まずＩＤ情報から一方向性関数Ａを用いて公開鍵を生成し，生成した公開鍵で署名情報を検証してＩＤ情報の正当性を確認し，ＩＤ情報の検証に成功すれば，携帯電話端末はＩＤ情報に含まれる属性情報をユーザＢの属性情報として保存する，ことが記載されている。（特に，段落［０００９］－［００１８］を参照されたい。） 引用文献１に記載の発明は，ＩＤから署名検証において用いるｕiを生成し，ｕiから署名用の秘密鍵であるＤを生成するものであるから，引用文献１に記載の発明において，前記の引用文献２に記載の技術を参酌し，ユーザのＩＤを，ユーザの職業，所属，資格，現在位置等の，複数の属性情報を含むものとして，請求項３－１０に係る発明の如く構成することは，当業者にとって容易である。 ＜引用文献等一覧＞ １．Duntao, G. et al., A Certificateless Proxy Re-Singnature Scheme, Proceedings 2010 3rd IEEE International Conference on Computer Science and Information Technology, 2010年7月, Vol.8, p.157-161 ２．特開２００６－３２５０７２号公報」 第５．当審の判断 １．３６条４項１号について （１）「・請求項　１－１３」の６．に関して 平成２７年１０月８日付けの手続補正においては，原審拒絶理由において，「・請求項　１－１３」の６．として指摘された，段落【００６４】の記載不備に関する補正はなされていないので，当該拒絶理由は解消していない。 （２）「・請求項　１－１３」の項目として， 「本願請求項１－１３は，属性ベースのデジタル署名システム，署名を生成するステップを有する方法，前記方法を実施させるための命令を有するコンピュータプログラム，を請求するものである」点に関して，理由を付して，「請求項１－１３に記載のデジタル署名に関して，実施可能なものが実質的に開示されていない。」 と指摘した点について 当該指摘事項は，上記「第２．平成２８年４月４日付けの手続補正の却下の決定」の「２．補正の適否」における「（２）目的要件」の「ウ．「機能」の実現性についての検討」において，（ア）～（エ）として検討した事項と同等のものであって，当該「ウ．「機能」の実現性についての検討」で検討したとおり，本願明細書の発明の詳細な説明，及び，図面には，補正後の請求項各項に係る発明が満たすべき「機能」を実現するための構成が記載されておらず， よって，本願明細書の発明の詳細な説明は，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。 ２．２９条１項３号，又は，同２項について （１）本願発明について 本願明細書の発明の詳細な説明は，上記において検討したとおり，経済産業省令で定めるところにより，その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものではないが， 本願の請求項１に係る発明は，以下の検討においては，本願の請求項１に記載された，以下の字句どおりのものする。 「第１のユーザのための第１の署名鍵及びドキュメントに基づいて，前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと， 第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するための再署名ユニットであって，前記再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される，再署名ユニットとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる，属性ベースのデジタル署名システム。」 （２）引用刊行物に記載の事項 ア．原審拒絶理由に引用された，本願の第１国出願前に既に公知である，「Duntao, G. et al., A Certificateless Proxy Re-Singnature Scheme, Proceedings 2010 3rd IEEE International Conference on Computer Science and Information Technology, 2010年7月, Vol.8, p.157-161」（以下，これを「引用刊行物１」という）には，次の事項が記載されている。 Ａ．「A. Proxy re-signature and related work Proxy re-signature scheme was first introduced by Blaze,Bleumer, and Strauss [3] at Eurocrypt'98, in which a semi-trusted proxy acts as a translator between Alice and Bob. To translate, the proxy converts a signature from Alice into a signature from Bob on the same message. However,the proxy does not learn any signing key and cannot sign arbitrary messages on behalf of either Alice or Bob. Proxy re-signature is very useful in sharing web certificates, authenticating a network path and forming weak group signatures. Proxy re-signature is different from proxy signature. Proxy signature allows Alice to delegate her signing rights to Bob but only if the proxy cooperates. However, in proxy re-signature system, the proxy translates a perfectly valid and publicly-verifiable signature from Alice on a certain message σA (m) , into one from Bob on the same message σB (m) . The two signatures can coexist and both can be publicly verified as being two signatures from two distinct people on the same message.」（１５７頁左欄３０行～右欄１１行，なお，下線は，当審にて，説明の都合上，付加したものである。以下，同じ。） （Ａ．プロキシ再署名と，関連した作業 プロキシ再署名スキームは，半信頼プロキシが，アリスと，ボブとの間の変換装置として動作するものとして，最初，ユーロクリプト’９８において，ブレーズ，ブリューマー，及び，シュトラウス［３］によって紹介された。変換するために，プロキシは，同一のメッセージについて，アリスからの署名を，ボブからの署名に変換する。しかしながら，プロキシは，何れの署名する鍵も，覚えておらず，アリス，或いは，ボブの代理として，任意のメッセージに，署名することはできない。プロキシ再署名は，ウェブ証明書の共有，ネットワーク認証，及び，弱いグループ署名の形成に，非常に有用である。 プロキシ再署名は，プロキシ署名とは異なる。プロキシ署名は，プロキシと協力しているのであれば，アリスに，アリスの署名する権利を，ボブに委任することを許可するが，それだけである。しかしながら，プロキシ再署名システムにおいては，あるメッセージσＡ（ｍ）について，完璧に正当で，パブリックに検証できる，アリスからの署名を，同じメッセージσＢ（ｍ）についてのボブの署名に，変換することができる。その２つの署名は，共存することができ，両者は，同じメッセージについての，２人の異なる人物による２つの署名として，パブリックに証明することが可能である。<当審にて訳出。以下，同じ。>） Ｂ．「IV. BIDIRECTIONAL CERTIFICATELESS PROXY RE-SIGNATURE A. Definition A bidirectional certificateless proxy re-signature scheme consists of the following six random algorithms: Setup, Keygen, ReKey, Sign, ReSign, and Verify where: ・ (Setup, Keygen, Sign, Verify) are the same as those in a standard certificateless signature. ・ On input (skA, skB) = ((xA,DA),(xB,DB)) , the re-signature key generation algorithm, REKey ,outputs a key rkA←→B for the proxy, where XA(XB) is A's (B's) secret value, DA（DB）is A's (B's) partial private key. ・ On input rkA←→B , a public key pkA , a message m ,and a signature σ ,the re-signature algorithm, RESign , outputs a new signature σ' on message m corresponding to pkB if Verify(pkA'，m, σ) =1 and⊥otherwise.」（１５９頁左欄２６行～左欄末行） （ＩＶ．双方向認証無しプロキシ再署名 Ａ．定義 双方向認証無しプロキシ再署名スキームは，以下の，６つのランダムなアルゴリズムかからなる：Ｓｅｔｕｐ，Ｋｅｙｇｅｎ，ＲｅＫｅｙ，Ｓｉｇｎ，ＲｅＳｉｇｎ，及び，Ｖｅｒｉｆｙは： ・（Ｓｅｔｕｐ，Ｋｅｙｇｅｎ，Ｓｉｇｎ，Ｖｅｒｉｆｙ）は，通常の認証無し署名のそれらと同じである。 ・入力(skA, skB) = ((xA,DA),(xB,DB)) に関して，再署名鍵生成アルゴリズム，ＲｅＫｅｙは，プロキシのための鍵ｒｋＡ←→Ｂを，出力し，ここで，ｘＡ（ｘＢ）は，Ａ（Ｂ）の，秘密の値であり，ＤＡ（ＤＢ）は，Ａ（Ｂ）の，部分的な個別鍵である。 ・入力ｒｋＡ←→Ｂ，公開鍵ｐｋＡ，メッセージｍ，そして，署名σに関して，再署名アルゴリズム，ＲｅＳｉｇｎは，もし， Verify(pkA', m, σ) =1である時，ｐｋＢに対応する，メッセージｍについての，新しい署名σ’を出力し，かつ，それ以外の時は⊥を出力する。） Ｃ．「B. SchemeＩ implement Based on paper [5] and [6], we present a new certificateless bidirectional proxy re-signature scheme, denoted as Scl . The scheme is consisted of six algorithms. a) Setup: We assume the given length identities and messages are nid and nm (nid, nm ∈Z), respectively. We choose two collision-resistant hash functions, Hid : {O,l}* → {O,l}nid and Hm : {O,l}* → {O,l}nm .Furthermore,　choose a random number α∈Zq' compute g１ = gα, and then choose g2∈G１, u',m'∈ RZq, ui (i = 1, .. ・,nid),m＾i (i= 1, .. ,nm)∈G1, g is a generator of G1. The public parameters are {G1, G2, e, g, g1, g2, U', Ui} and the master secret key is gα２. b) Keygen: Input the identity IDA'，choose a random numberid ∈ RZq, KGC computes partial private key: DA = (d１A,d２A) = (gα２ (u'Πuｉ)rid,grid) i∈U where u = Hid (IDA)'，U ⊆ {I,・・・, nid} is the set of indices i such that u[i] = 1, and u[i] is the i-th bit of u. The user A picks xA ∈ ＲZ＊ｑ; , and computes pkA = (pk１A,pk２A) = (gXA ，gXA１) then he sets skA = (xA　，DA)' The user B sets his key in the same way.」（１５９頁右欄１行～右欄２３行） （Ｂ．スキームＩの実装 論文［５］，及び，［６］に基づいて，我々は，Ｓｃｌとして示される，新しい，認証無し双方向プロキシ再署名スキームを，提示する。そのスキームは，６つのアルゴリズムから構成される。 ａ）Ｓｅｔｕｐ（設定）：与えられた長さ識別子と，メッセージは，それぞれ，ｎｉｄと，ｎｍ（ｎｉｄ，ｎｍ∈Ｚ）であると定義する。２つの，衝突耐性のある，ハッシュ関数，Ｈｉｄ：｛Ｏ，ｌ｝＊→｛Ｏ，ｌ｝ｎｉｄと， Hm :｛Ｏ，ｌ｝＊→｛Ｏ，ｌ｝ｎｍを選択する。更に，乱数α∈Ｚｑを選択し，ｇ１＝ｇαを計算し，次に，ｇ２∈Ｇ１，ｕ’，ｍ’∈ＲＺｑ，ｕｉ（ｉ＝１，・・・，ｎｉｄ），ｍ＾ｉ（ｉ＝１，・・・，ｎｍ）∈Ｇ１，を選択する。ｇは，Ｇ１の生成元である。公開パラメータは， ｛Ｇ１，Ｇ２，ｅ，ｇ，ｇ１，ｇ２，ｕ’，ｕｉ｝ そして，マスタ秘密鍵は，ｇα２である。 ｂ）Ｋｅｙｇｅｎ（鍵生成）：識別子ＩＤＡを入力し，乱数ｒｉｄ∈ＲＺｑを選択し，ＫＧＣが，部分個別鍵： DA=(d1A,d2A)=(gα2(u'Πui)rid,grid) i∈U を計算する。ここで，ｕ＝Ｈｉｄ（ＩＤＡ），Ｕ⊆｛１，・・・ｎｉｄ｝は，ｕ[ｉ]＝１であるような，添え字の組であり，ｕ[ｉ]は，ｕのｉ番目のビットである。 ユーザＡが，ｘＡ⊆ＲＺ＊ｑを選び， pkA=(pk1A,pk2A)=(gxA,gxA1) を計算する。次に，ユーザＡは，ｓｋＡ＝（ｘＡ，ＤＡ）を設定する。ユーザＢは，自分の鍵を，同じ方法で，設定する。） Ｄ．「c) Rekey: Input two private keys (xA，DA),(xB，DB) , output the re-signature key: rkA→B　= DxBB/DxAA　=（(d1B)xB/(d1A)xA , (d2B)xB/(d2A)xA） (Note that the way we get the re-signature key is the same method and assumptions in [3].) d) Sign: Input the message m∈{O,l}* , the identity IDA and the key (xA，DA) , choose a random number rm∈RZq. Compute Rm = grm，RA = (d２A)xA m＾ = Hm(m，RA，Rm，pkA) then, output the sign: σA = ((d１A)xA (m' Πm＾i)rm , (d２A)ｘA , grm) i∈M = (VA，RA，Rm) where M ⊆ {1，・・ ,nm} is the set of indices i such that m[i] = 1, and m[i] is the i-th bit of m＾. e) Resign: Input a re-signature key rkA→B , the public key pkA ，a message m and a signatureσA = (VA，RA, Rm), check that Verify(pkA， m，σA) = 1, if σA does not verify, output ⊥ ; otherwise output σB = (VA・(d１B)xB/ (d１A)xA，RA（d2B)xB/（d2A)xA，Rｍ) =((d1B)ｘB (m'Π m＾i)rm ,(d２B)xB，grm) i∈M = (VB，RB，Rm) f) Verify: Input the public key pk , the message m and the signature σ , compute m＾ = Hm(m，R，Rm，pk), if e(g1，pk１) = e(g，pk2) , e(V, g) = e(pk2，g2)e(u'Πui，R)e(m'Πm＾i，Rm) i∈U　　　　 i∈M output 1 and 0 otherwise」（１５９頁右欄２４行～１６０頁左欄１０行） ｃ）Ｒｅｋｅｙ（再署名鍵生成）：２つの個別鍵，（ｘＡ，ＤＡ），（ｘＢ，ＤＢ）を入力し，再署名鍵： rkA→B=DxBB/DxAA=((d1B)xB/(d1A)xA,(d2B)xB/(d2A)xA) を出力する。 （注　再署名鍵を得る，この方法は，[３]におけるのと，同じ方法と，仮定である。） ｄ）Ｓｉｇｎ（署名）：メッセージｍ∈｛０，１｝＊，識別子ＩＤＡ，及び，鍵（ｘＡ，ＤＡ）を入力し，乱数ｒｍ∈ＲＺｑを選び， Rm=grm,RA=(d2A)xA m^=Hm(m,RA,Rm,pkA) を計算する。次に，署名： σA=((d1A)xA(m'Πm^i)rm,(d2A)xA,grm) i∈M =(VA,RA,Rm) を出力する。ここで，Ｍ⊆｛１，・・・，ｎｍ｝は，ｍ［ｉ］＝１であるような，添え字の組であり，ｍ［ｉ］は，ｍ＾のｉ番目のビットである。 ｅ）Ｒｅｓｉｇｎ（再署名）：再署名鍵ｒｋＡ→Ｂ，公開鍵ｐｋＡ，メッセージｍ，及び，署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）を入力し，Ｖｅｒｉｆｙ（ｐｋＡ，ｍ，σＡ）＝１であることを，確認する。もし，立証しなければ，⊥を出力し；それ以外は， σB = (VA・(d1B)xB/ (d1A)xA,RA(d2B)xB/(d2A)xA,Rm) =((d1B)xB(m'Πm''i)rm ,(d2B)xB,grm) i∈M =(VB,RB,Rm) を出力する。 ｆ）Ｖｅｒｉｆｙ（検証）：公開鍵ｐｋ，メッセージｍ，及び，署名σを入力して， ｍ＾＝Ｈｍ（ｍ，Ｒ，Ｒｍ，ｐｋ）を計算し，もし， e(g1,pk1)=e(g,pk2)， e(V,g)=e(pk2,g2)e(u'Πui,R)e(m'Πm''i,Rm) i∈U 　　 i∈M であれば，１を出力し，それ以外の場合は，０を出力する。） イ．原審拒絶理由に引用された，本願の第１国出願前に既に公知である，特開２００６－３２５０７２号公報（２００６年１１月３０日公開，以下，これを「引用刊行物２」という）には，関連する図面と共に，次の事項が記載されている。 Ｅ．「【０００９】 以下，図面を参照して本発明の第１の実施形態について説明する。図１は本発明の第１の実施形態にかかる属性情報交換システムを示した外観図である。図１において，発行センタ１は，ユーザの職業，所属，資格，現在位置情報等の属性情報に対して使用する暗号鍵を発行する機関であり，例えば地域コミュニティで運営する組織である。サービスプロバイダ２は，ユーザの携帯電話端末間またはユーザの携帯電話端末３ａ（３ｂ）と発行センタ１との間のデータ通信の中継を行う機関である。 【００１０】 図２は第１の実施形態で用いるＩＤ型暗号方式における暗号化方法を示した模式図である。ＩＤ型暗号方式とは，ＩＤ情報から復号（検証）用の公開鍵（復号鍵）を生成し，公開鍵からさらに暗号化（署名）用の秘密鍵（暗号鍵）を生成する方式である。ＩＤ型暗号方式の特徴は，意味のあるＩＤ情報から公開鍵を生成するため公開鍵の種類が豊富であり，また公開鍵自体に意味のある情報を持たせることができるという点にある。 【００１１】 ここで，ＩＤ情報とは，上述の属性情報を含む情報のことを意味する。交換する属性情報を交換相手に譲渡できないよう制限を設ける場合は，個人を識別する情報や携帯電話端末の電話番号等の情報をＩＤ情報に含めることで，属性情報の所持者を明確に証明することが可能である。また，一定の期間内のみ有効な資格等を属性情報として交換する場合は，発行時刻をＩＤ情報に含めることで，相手から受信した属性情報の有効性を判断することが可能である。」 （３）引用刊行物１に記載の発明 ア．上記Ｃの「b) Keygen: Input the identity IDA'，choose a random numberid ∈ RZq, KGC computes partial private key: DA = (d１A,d２A) = (gα２ (u'Πuｉ)rid,grid) i∈U where u = Hid (IDA)'，U ⊆ {I,・・・, nid} is the set of indices i such that u[i] = 1, and u[i] is the i-th bit of u. The user A picks xA ∈ ＲZ＊ｑ; , and computes pkA = (pk１Ａ,pk２Ａ) = (gXA ，gＸＡ１) then he sets skA = (xA　，DA)' The user B sets his key in the same way.」 （ｂ）Ｋｅｙｇｅｎ（鍵生成）：識別子ＩＤＡを入力し，乱数ｒｉｄ∈ＲＺｑを選択し，ＫＧＣが，部分個別鍵： DA=(d1A,d2A)=(gα2(u'Πui)rid,grid) i∈U を計算する。ここで，ｕ＝Ｈｉｄ（ＩＤＡ），Ｕ⊆｛１，・・・ｎｉｄ｝は，ｕ[ｉ]＝１であるような，添え字の組であり，ｕ[ｉ]は，ｕのｉ番目のビットである。 ユーザＡが，ｘＡ⊆ＲＺ＊ｑを選び， pkA=(pk1A,pk2A)=(gxA,gxA1) を計算する。次に，ユーザＡは，ｓｋＡ＝（ｘＡ，ＤＡ）を設定する。ユーザＢは，自分の鍵を，同じ方法で，設定する。）という記載，及び， 上記Ｄの「d) Sign: Input the message m∈{O,l}* , the identity IDA and the key (xA，DA) , choose a random number rm∈RZq. Compute Rm = grm，RA = (d２Ａ)ｘA m＾= Hm(m，RＡ，Rm，pkA) then, output the sign: σA = ((d１A)ｘＡ (m' Πm＾i)ｒｍ , (d２A)ｘA , grm) i∈M = (VA，RA，Rm)」 （ｄ）Ｓｉｇｎ（署名）：メッセージｍ∈｛０，１｝＊，識別子ＩＤＡ，及び，鍵（ｘＡ，ＤＡ）を入力し，乱数ｒｍ∈ＲＺｑを選び， Rm=grm,RA=(d2A)xA m^=Hm(m,RA,Rm,pkA) を計算する。次に，署名： σA=((d1A)xA(m'Πm^i)rm,(d2A)xA,grm) i∈M =(VA,RA,Rm))という記載から，引用刊行物１には，“ユーザＡの識別子ＩＤＡと，ユーザＡの署名鍵ｓｋＡ＝（ｘＡ，ＤＡ）と，メッセージｍとに基づいて，ユーザＡの署名（ＶＡ，ＲＡ，Ｒｍ）を生成する，第１の署名生成部”が存在していることが読み取れる。 イ．上記Ｂの「・On input rkA←→B , a public key pkA , a message m ,and a signature σ ,the re-signature algorithm, RESign , outputs a new signature σ' on message m corresponding to pkB if Verify(pkA' m, σ) =1 and⊥otherwise.」 （・入力ｒｋＡ←→Ｂ，公開鍵ｐｋＡ，メッセージｍ，そして，署名σに関して，再署名アルゴリズム，ＲｅＳｉｇｎは，もし， Verify(pkA' m, σ) =1である時，ｐｋＢに対応する，メッセージｍについての，新しい署名σ’を出力し，かつ，それ以外の時は⊥を出力する。）という記載，及び，上記Ｄの「e) Resign: Input a re-signature key rkA→B , the public key pkA ，a message m and a signatureσA = (VA，RA, Rm), check that Verify(pkA， m，σA) = 1, if σA does not verify, output ⊥ ; otherwise output σB = (VA・(d1B)xB/ (d1A)xA,RA(d2B)xB/(d2A)xA,Rm) =((d1B)xB (m'Π m^i)rm ,(d2B)xB,grm) i∈M = (VB,RB,Rm)」 （ｅ）Ｒｅｓｉｇｎ（再署名）：再署名鍵ｒｋＡ→Ｂ，公開鍵ｐｋＡ，メッセージｍ，及び，署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）を入力し，Ｖｅｒｉｆｙ（ｐｋＡ，ｍ，σＡ）＝１であることを，確認する。もし，立証しなければ，⊥を出力し；それ以外は， σB = (VA・(d1B)xB/ (d1A)xA,RA(d2B)xB/(d2A)xA,Rm) =((d1B)xB(m'Πm''i)rm ,(d2B)xB,grm) i∈M =(VB,RB,Rm) を出力する。）という記載から，引用刊行物１には，“再署名鍵ｒｋＡ→Ｂ，署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）に基づいて，メッセージｍに再署名（ＶＢ，ＲＢ，Ｒｍ）を行う，再署名部”が存在していることが読み取れる。 ウ．上記Ｂの「・ On input (skA, skB) = ((xA,DA),(xB,DB)) , the re-signature key generation algorithm, REKey ,outputs a key rkA?B for the proxy, where XA(XB) is A's (B's) secret value, DA（DB）is A's (B's) partial private key.」 （・入力(skA, skB) = ((xA,DA),(xB,DB)) に関して，再署名鍵生成アルゴリズム，ＲｅＫｅｙは，プロキシのための鍵ｒｋＡ?Ｂを，出力し，ここで，ｘＡ（ｘＢ）は，Ａ（Ｂ）の，秘密の値であり，ＤＡ（ＤＢ）は，Ａ（Ｂ）の，部分的な個別鍵である。）という記載，及び，上記Ｄの「c) Rekey: Input two private keys (xA，DA),(xB，DB) , output the re-signature key: rkA→B　= DxBB/DxAA　=（(d1B)xB/(d1A)xA , (d2B)xB/(d2A)xA）」 （ｃ）Ｒｅｋｅｙ（再署名鍵生成）：２つの個別鍵，（ｘＡ，ＤＡ），（ｘＢ，ＤＢ）を入力し，再署名鍵： rkA→B=DxBB/DxAA=((d1B)xB/(d1A)xA,(d2B)xB/(d2A)xA) を出力する。）という記載から，引用刊行物１においては，“再署名鍵ｒｋＡ→Ｂの生成には，ユーザＡとは異なる，ユーザＢの署名鍵（ｘＢ，ＤＢ）が用いられる再署名部”が読み取れる。 エ．上記ア．において検討した，ユーザＡの署名鍵，及び，ユーザＢの署名鍵の生成方法と，上記イ．において検討した事項から，ユーザＡの署名には，ユーザＡの識別子ＩＤＡが関係し，そして，ユーザＢの署名鍵は，ユーザＢの識別子ＩＤＢと関係していて，再署名には，ユーザＢの署名鍵が用いられることから，再署名が，少なくとも，ユーザＢのユーザＢの識別子ＩＤＢと関係しているといえるので，引用刊行物１においては，“ユーザＡの署名は，ユーザＡの識別子ＩＤＡが関係し，再署名は，少なくとも，ユーザＢのユーザＢの識別子ＩＤＢと関係している”ことが読み取れる。 オ．上記ア．～エ．において検討した事項，及び，上記Ａの「Proxy re-signature scheme was first introduced by Blaze,Bleumer, and Strauss [3] at Eurocrypt'98, in which a semi-trusted proxy acts as a translator between Alice and Bob. To translate, the proxy converts a signature from Alice into a signature from Bob on the same message.」（プロキシ再署名スキームは，半信頼プロキシが，アリスと，ボブとの間の変換装置として動作するものとして，最初，ユーロクリプト’９８において，ブレーズ，ブリューマー，及び，シュトラウス［３］によって紹介された。変換するために，プロキシは，同一のメッセージについて，アリスからの署名を，ボブからの署名に変換する。）という記載から，引用刊行物１は，“ユーザＡの署名を，ユーザＢの署名に変換する，署名変換システム”に関するものであることが，読み取れる。 カ．以上ア．～オ．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されていると認める。 「ユーザＡの識別子ＩＤＡと，ユーザＡの署名鍵ｓｋＡ＝（ｘＡ，ＤＡ）と，メッセージｍとに基づいて，ユーザＡの署名（ＶＡ，ＲＡ，Ｒｍ）を生成する，第１の署名生成部と， 再署名鍵ｒｋＡ→Ｂ，署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）に基づいて，メッセージｍに再署名（ＶＢ，ＲＢ，Ｒｍ）を行う，再署名部であって， 前記再署名鍵ｒｋＡ→Ｂの生成には，ユーザＡとは異なる，ユーザＢの署名鍵（ｘＢ，ＤＢ）が用いられる，再署名部とを有し， ユーザＡの署名は，ユーザＡの識別子ＩＤＡが関係し，再署名は，少なくとも，ユーザＢの識別子ＩＤＢと関係している， ユーザＡの署名を，ユーザＢの署名に変換する，署名変換システム。」 （４）本願発明と引用発明との対比 ア．引用発明における「ユーザＡの署名鍵ｓｋＡ＝（ｘＡ，ＤＡ）」，「メッセージｍ」，及び，「ユーザＡの署名（ＶＡ，ＲＡ，Ｒｍ）」が， 本願発明における「第１のユーザのための第１の署名鍵」，「ドキュメント」，及び，「ドキュメントに対する第１の署名」に相当するので， 引用発明における「ユーザＡの識別子ＩＤＡと，ユーザＡの署名鍵ｓｋＡ＝（ｘＡ，ＤＡ）と，メッセージｍとに基づいて，ユーザＡの署名（ＶＡ，ＲＡ，Ｒｍ）を生成する，第１の署名生成部」が， 本願発明における「第１のユーザのための第１の署名鍵及びドキュメントに基づいて，前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニット」に相当する。 イ．引用発明における「再署名鍵ｒｋＡ→Ｂ」，「署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）」，及び，「再署名（ＶＢ，ＲＢ，Ｒｍ）」が， 本願発明における「再署名鍵」，「第１の署名」，及び，「ドキュメントに対する第２の署名」に相当するので， 引用発明における「再署名鍵ｒｋＡ→Ｂ，署名σＡ＝（ＶＡ，ＲＡ，Ｒｍ）に基づいて，メッセージｍに再署名（ＶＢ，ＲＢ，Ｒｍ）を行う，再署名部」が， 本願発明における「第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するための再署名ユニット」に相当する。 ウ．引用発明における「ユーザＢ」，「署名鍵（ｘＢ，ＤＢ）」が， 本願発明における「第２のユーザ」，「第２の署名鍵」に相当するので， 引用発明における「再署名鍵ｒｋＡ→Ｂの生成には，ユーザＡとは異なる，ユーザＢの署名鍵（ｘＢ，ＤＢ）が用いられる，再署名部」は， 本願発明における「再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される，再署名ユニット」に相当する。 エ．引用発明における「ユーザＡの識別子ＩＤＡ」，及び，「ユーザＢの識別子ＩＤＢ」は，それぞれ，「ユーザＡに関連する情報」，及び，「ユーザＢに関連する情報」と言い得るものであるから， 本願発明における「第１のユーザが所有する属性」，及び，「第２のユーザが所有する属性」と， “第１のユーザに関連する情報”，及び，“第２のユーザに関連する情報”である点で共通するので， 引用発明における「ユーザＡの署名は，ユーザＡの識別子ＩＤＡが関係し，再署名は，少なくとも，ユーザＢの識別子ＩＤＢと関係している」と， 本願発明における「第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザが所有する属性が関連付けられる」とは， “第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザに関連する情報に関係付けられている”点で共通する。 オ．引用発明においても，「デジタル署名」を行っていることは明らかであるから， 引用発明における「ユーザＡの署名を，ユーザＢの署名に変換する，署名変換システム」と， 本願発明における「属性ベースのデジタル署名システム」とは， “デジタル署名システム”である点で共通する。 カ．以上ア．～オ．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。 ［一致点］ 第１のユーザのための第１の署名鍵及びドキュメントに基づいて，前記ドキュメントに対する第１の署名を生成するための第１の署名生成ユニットと， 第１の署名及び再署名鍵に基づいて，前記ドキュメントに対する第２の署名を生成するための再署名ユニットであって， 再署名鍵が，前記第１のユーザと異なる第２のユーザのための第２の署名鍵に基づき生成される，再署名ユニットとを有し， 第１の署名及び／又は第２の署名には，前記第１のユーザ及び／又は前記第２のユーザに関連する情報に関係付けられている， デジタル署名システム。 ［相違点１］ “ユーザに関連する情報”に関して， 本願発明においては，「第１のユーザ及び／又は前記第２のユーザが所有する属性」であるのに対して， 引用発明においては，「ユーザＡの識別子ＩＤＡ」，及び，「ユーザＢの識別子ＩＤＢ」であって，当該「識別子」が，「ユーザ」の「属性」といえるかに関しては，特に言及がない点。 ［相違点２］ “デジタル署名システム”に関して， 本願発明においては，「属性ベースのデジタル署名システム」であるのに対して， 引用発明においては，「識別子」に基づくものであることまでは，読み取れるが，当該「識別子」を「属性」に含めることができるかについては，特に，言及がない点。 （５）相違点についての当審の判断 ア．［相違点１］について 本願発明における「属性」に関して，本願明細書の発明の詳細な説明には，その段落【０００３】に， 「属性ベースの署名が使われている。よって，ヘルスケアでは，属性は，データ発信元を証明する主要なソースであるとみなされる。これらの属性は，また，特定のドメイン（例えば名前又は識別子）の個人に固有である個々の属性を有する。例えば，処方箋が特定の役割を持つ特定のユーザ（例えば医師ジョンスミス）により署名された場合，薬局は，処方箋を受理するだろう。」 と記載されていて，上記引用の記載においては，“医師の名前”により署名された場合に，当該署名を受理する点が記載され，この記載に従えば，“医師の名前”は，一種の「属性」として扱われていることは，明らかである。そして，当該“医師の名前”は，「識別子」と同じく，「特定のドメイン」を示す情報でもあるから，本願明細書の発明の詳細な説明においては，「名前」と，同じく「識別子」も，「属性」に含まれるものであるといえる。 そうすると，引用発明における「識別子」も，「属性」に含まれるものと言い得るので，［相違点１］は，表現の差こそあれ，実質的な相違には当たらない。 イ．［相違点２］について 上記ア．で検討したとおり，「識別子」が，「属性」の１つと言い得るものであれば，引用発明における「署名変換システム」も，「ユーザの署名」が，「識別子」に関連づけられていることは，明らかであるから，“属性に基づくシステム”と言い得るものである。 よって，［相違点２］は，表現の差こそあれ，実質的な相違には当たらない。 （６）２９条１項３号，又は，同２項についてのむすび 以上，ア．，及び，イ．に検討したとおり，本願発明は，引用刊行物１に記載された発明である。 よって，本願発明は，引用刊行物１に記載の発明に基づいて，当業者が容易になし得たものである。 なお，仮に，引用発明における「識別子」が，「属性」に含まれないものであると解釈しても，引用刊行物２の，上記Ｅに引用した記載内容にもあるとおり，“ユーザの職業，所属，資格，現在位置情報等の属性情報を，ＩＤ情報とする”ことは，本願の第１国出願前に，当業者には，広く知られた技術事項であり，該「ＩＤ情報」は，「署名鍵」の生成に用いられるものであるから，引用発明において，「識別子」に代えて，引用刊行物２に係る発明における「ＩＤ情報」を採用することは，当業者が適宜なし得る事項である。 よって，［相違点１］，及び，［相違点２］は，格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。 第６．むすび 以上「第５．当審の判断」の「１．３６条４項１号について」において検討したとおりであるから， 本願は，特許法第３６条第４項第１号に規定する要件を満たしていない。 そして，「第５．当審の判断」の「２．２９条１項３号，又は，同２項について」において検討したとおりであるから， 本願の発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから，特許法第２９条第１項第３号に該当し，特許を受けることができない。 加えて，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。 よって，結論のとおり審決する。