• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
審判 査定不服 5項独立特許用件 特許、登録しない。 H04L
管理番号 1334210
審判番号 不服2016-4868  
総通号数 216 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-12-28 
種別 拒絶査定不服の審決 
審判請求日 2016-04-04 
確定日 2017-11-06 
事件の表示 特願2013-525395「属性ベースのデジタル署名」拒絶査定不服審判事件〔平成24年 3月 1日国際公開,WO2012/025866,平成25年 9月19日国内公表,特表2013-536651〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2011年8月22日(パリ条約による優先権主張外国庁受理2010年8月24日 欧州特許庁)を国際出願日とする出願であって,
平成25年2月21日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,平成26年8月19日付けで審査請求がなされると共に手続補正がなされ,平成27年4月8日付けで審査官により拒絶理由が通知され,これに対して平成27年10月8日付けで意見書が提出されると共に手続補正がなされたが,平成27年11月20日付けで審査官により拒絶査定がなされ(謄本送達;平成27年12月8日),これに対して平成28年4月4日付けで審判請求がなされると共に手続補正がなされ,平成28年6月30日付けで審査官により特許法第164条第3項の規定に基づく報告がなされたものである。

第2.平成28年4月4日付けの手続補正の却下の決定

[補正却下の決定の結論]

平成28年4月4日付け手続補正を却下する。

[理由]

1.補正の内容
平成28年4月4日付けの手続補正(以下,「本件手続補正」という)により,平成27年10月8日付けの手続補正により補正された特許請求の範囲,
「 【請求項1】
第1のユーザのための第1の署名鍵及びドキュメントに基づいて,前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと,
第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するための再署名ユニットであって,前記再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される,再署名ユニットとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる,属性ベースのデジタル署名システム。
【請求項2】
前記再署名ユニットは第1の署名を第2の署名へ変換する,請求項1に記載のシステム。
【請求項3】
第2の署名は前記再署名鍵により決定される属性の第2のセットと関連し,属性の第2のセットは,複数の属性を有する,請求項1に記載のシステム。
【請求項4】
第1の署名は属性の第1のセットと関連し,属性の第1のセットは複数の属性を有し,
前記再署名ユニットは,属性の第1のセットが条件のセットを満足する場合だけ,第2の署名を生成する,請求項1又は3に記載のシステム。
【請求項5】
前記再署名鍵は前記属性上の前記条件のセットを暗号によって組み込む,請求項4に記載のシステム。
【請求項6】
属性の第2のセットと関連した第2の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し,前記再署名鍵は,前記再署名ユニットが,第1の署名を属性の第2のセットと関連する第2の署名へ変換可能にし,第2の署名鍵は,第2の署名生成ユニットが前記ドキュメントに基づいて属性の第2のセットと関連する署名を生成可能にする,請求項3に記載のシステム。
【請求項7】
前記再署名鍵生成器は,更に,第2の署名鍵に基づいて第1の署名鍵を生成し,第1の署名鍵及び前記再署名鍵は,鍵のペアとして生成され,第1の署名鍵は第1の署名生成ユニットへ供給され,前記再署名鍵は前記再署名ユニットへ供給される,請求項6に記載のシステム。
【請求項8】
条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し,前記再署名鍵は,前記再署名ユニットが,条件のセットを満足させる属性の任意のセットと関連する第1の署名を第2の署名へ変換可能にさせる,請求項4に記載のシステム。
【請求項9】
前記再署名ユニットは,第1の署名が条件のセットを満足する属性の第1のセットと関連するかどうかを検証するため公開鍵を使用し,第1の署名が条件のセットを満足する属性のセットと関連する場合だけ第2の署名を生成する,請求項4に記載のシステム。
【請求項10】
属性の第2のセットを所有するユーザが,前記再署名ユニットに前記再署名鍵を供給することにより,属性の第2のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する,請求項1に記載のシステム。
【請求項11】
請求項1に記載のシステムを有するワークステーション。
【請求項12】
第1の署名生成ユニットによって,第1のユーザのための第1の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第1の署名を生成するステップと,
再署名ユニットによって,第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するステップであって,前記再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される,ステップとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる,属性ベースのデジタル署名システムの作動方法。
【請求項13】
プロセッサシステムが請求項12に記載の方法を実施させるための命令を有する,コンピュータプログラム。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「 【請求項1】
第1のユーザのための第1の署名鍵及びドキュメントに基づいて,前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと,
第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するための再署名ユニットであって,前記再署名鍵が,ユーザのための署名鍵に基づき生成され,前記ユーザのための署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵を含むが,前記第1の署名鍵を含まない,再署名ユニットとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる,属性ベースのデジタル署名システム。
【請求項2】
前記再署名ユニットは第1の署名を第2の署名へ変換する,請求項1に記載のシステム。
【請求項3】
第2の署名は前記再署名鍵により決定される属性の第2のセットと関連し,属性の第2のセットは,複数の属性を有する,請求項1に記載のシステム。
【請求項4】
第1の署名は属性の第1のセットと関連し,属性の第1のセットは複数の属性を有し,前記再署名ユニットは,属性の第1のセットが条件のセットを満足する場合だけ,第2の署名を生成する,請求項1又は3に記載のシステム。
【請求項5】
前記再署名鍵は前記属性上の前記条件のセットを暗号によって組み込む,請求項4に記載のシステム。
【請求項6】
属性の第2のセットと関連した第2の署名鍵に基づいて前記再署名鍵を生成するための再署名鍵生成器を更に有し,前記再署名鍵は,前記再署名ユニットが,第1の署名を属性の第2のセットと関連する第2の署名へ変換可能にし,第2の署名鍵は,第2の署名生成ユニットが前記ドキュメントに基づいて属性の第2のセットと関連する署名を生成可能にする,請求項3に記載のシステム。
【請求項7】
前記再署名鍵生成器は,更に,第2の署名鍵に基づいて第1の署名鍵を生成し,第1の署名鍵及び前記再署名鍵は,鍵のペアとして生成され,第1の署名鍵は第1の署名生成ユニットへ供給され,前記再署名鍵は前記再署名ユニットへ供給される,請求項6に記載のシステム。
【請求項8】
条件のセットに依存して前記再署名鍵を生成するための再署名鍵生成器を有し,前記再署名鍵は,前記再署名ユニットが,条件のセットを満足させる属性の任意のセットと関連する第1の署名を第2の署名へ変換可能にさせる,請求項4に記載のシステム。
【請求項9】
前記再署名ユニットは,第1の署名が条件のセットを満足する属性の第1のセットと関連するかどうかを検証するため公開鍵を使用し,第1の署名が条件のセットを満足する属性のセットと関連する場合だけ第2の署名を生成する,請求項4に記載のシステム。
【請求項10】
属性の第2のセットを所有するユーザが,前記再署名ユニットに前記再署名鍵を供給することにより,属性の第2のセットと関連する署名でドキュメントを署名するためのユーザの権限を他のユーザへ委任可能にする委任ユニットを更に有する,請求項1に記載のシステム。
【請求項11】
請求項1に記載のシステムを有するワークステーション。
【請求項12】
第1の署名生成ユニットによって,第1のユーザのための第1の署名鍵及びドキュメントに基づいて前記ドキュメントに対する第1の署名を生成するステップと,
再署名ユニットによって,第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するステップであって,前記再署名鍵が,ユーザのための署名鍵に基づき生成され,前記ユーザのための署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵を含むが,前記第1の署名鍵を含まない,ステップとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる,属性ベースのデジタル署名システムの作動方法。
【請求項13】
プロセッサシステムが請求項12に記載の方法を実施させるための命令を有する,コンピュータプログラム。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
(1)新規事項
本件手続補正は,平成25年2月21日付けで提出された,明細書,請求の範囲の日本語による翻訳文,及び,国際出願の願書に添付された図面の範囲内でなされたものであるから,特許法第184条の12第2項により読み替える同法第17条の2第3項の規定を満たすものである。

(2)目的要件
本件手続補正によって,補正前の請求項1に記載の「再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される」が,補正後の請求項1に記載の「再署名鍵が,ユーザのための署名鍵に基づき生成され,前記ユーザのための署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵を含むが,前記第1の署名鍵を含まない」と補正されたが,当該補正内容は,“再署名鍵の生成に用いられる署名鍵を,第2の署名鍵に限定する”ものであって,当該補正内容は,一応,本願明細書の段落【0053】の記載,及び,段落【0061】の記載から読み取れるので,本件手続補正は,特許請求の範囲の限定的減縮であるといえる。
よって,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第5項の規定を満たすものである。
そして,補正前に受けた拒絶理由通知において特許することができないものか否かについて判断が示された発明と,補正後の請求項に記載された事項により特定される発明とが,第37条の発明の単一性の要件を満たす一群の発明に該当するものと,一応,読み取れるので,本件手続補正は,特許法第184条の12第2項により読み替える同法第17条の2第4項の規定を満たすものである。

(3)独立特許要件
そこで,本件手続補正が,特許法第17条の2第6項において準用する同法第126条第7項の規定を満たすものであるか否か,即ち,補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か,以下に検討する。

ア.補正後の請求項1?補正後の請求項13に係る発明
補正後の請求項1?補正後の請求項13に係る発明(以下,これを「補正後の請求項各項に係る発明」という)は,上記「1.補正の内容」において,「補正後の請求項」として引用した記載にあるとおり,“再署名ユニットを有する,属性ベースのデジタル署名システム”に関するものであり,
当該「属性ベースのデジタル署名システム」は,本願明細書の発明の詳細な説明の記載によれば,段落【0022】に記載の,次の機能を実現するものである。
「斯様なシステムに対する望ましい特性の1つは,その人自身(看護士又は代理)以外の誰も,医師に代わって署名を作ることが可能であってはならないということである。加えて,看護士と半信頼されたプロキシ(代理)との間の共謀でさえ,彼らにより医師(委託者)の秘密鍵SK_(ωdelegaｔｏｒ)を回復可能にしてはならない。」
(なお,上記引用の日本語文の英語原文は,
“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. ”
であって,これを日本語訳すると,
“このシステムのための望まれる特性の一つは,何人(看護師,或いは,プロキシ)も,独力では,医師の代理として,署名を生成することはできない。”
となり,原審における平成27年4月8日付けの拒絶理由(以下,これを「原審拒絶理由」という)においても指摘されたとおり,上記において引用した,段落【0022】における日本語訳は,誤訳である。)

イ.本願明細書に開示されている事項
次に,本願明細書に,上記ア.において指摘した,補正後の請求項各項に係る発明の特性を実現するための事項が記載されているかについて検討する。

(ア)第1実施例(第1のスキーム)
本願明細書に記載された実施例の1つである「第1のスキーム」は,本願明細書の段落【0048】,段落【0050】?段落【0057】に記載の,次のとおりのものである。

「【0048】
第1のスキームにおいて,再署名鍵RSKの第1の部分は,エンティティA(受任者)に与えられ,再署名鍵RSKの第2の部分はプロキシに与えられる。エンティティA(受任者)が最初にメッセージに署名する場合だけ,有効な署名が半信頼されたプロキシにより作られる。この場合,受任者は,余分の秘密鍵,すなわち再署名鍵RSKの部分を格納しなければならない。」

「【0050】
図3は,属性ベースの代理再署名スキームの機能的図を提供する。ステップ301において,エンティティ「A」は,再生成アルゴリズムを用いて,再署名鍵RSKを生成する。RSKは,2つのコンポーネント:プロキシに対するコンポーネント及びエンティティ「B」に対するコンポーネントを有する。これは,第1のデザインされたスキームの場合である。上記で紹介された第2のスキームにおいて,これは,プロキシに対する1つのコンポーネントを有する。ステップ302及び303において,再署名鍵,すなわちRSK_(ｐｒｏｘｙ)及びRSK_(delegaｔee)が,プロキシ「P」及びエンティティ「B」それぞれに送られる。ステップ304において,エンティティ「B」は,RSK_(delegaｔee)(第1のスキームで)又はSK_(delegaｔee)(第2のスキームで)を使用して,エンティティ「B」の署名を生成する。ステップ305において,エンティティ「B」は,プロキシ「P」にステップ4の出力を送る。ステップ306において,半信頼されたプロキシは,エンティティ「B」から受信された署名をエンティティ「A」の署名へ変換する。ステップ307において,プロキシ「P」は,エンティティ「A」を代表して作られた署名を検証器「V」(又は,署名されたメッセージの受信器)へ送る。ステップ308において,検証器「V」は,署名がエンティティ「A」からであるかどうか,属性の正しいセットに関係のある秘密鍵により署名されているかどうかを検証する。」

「【0051】
第1のスキームにおいて,ユーザ属性はZ_(ｐ)の要素であり,最大k個の属性があるとみなされている。実際上,属性ストリングをZ_(ｐ)の要素へマップするための対立耐性のあるハッシュ関数を使用できる。当該スキームは,4つのアルゴリズムを有する。

セットアップ
セットアップアルゴリズムは,主要なオーダーｐ並びにランダムジェネレータg及びhの双一次グループG_(0)を選択する。また,双一次マップe:G_(0)ｘG_(0)→G_(1)を選び,ここで,G_(1)はターゲットグループである。加えて,セットアップは,無作為に
t,y,x_(1),x_(2),・・・,x_(k)∈Z_(p)
を取り上げ,属性セット
Ω={a_(1),a_(2),...,a_(k)}
のために,
T_(j)=g^(xj)
及び
T'_(j)=h^(xj)
を(1≦j≦k)に対してセットする。公開鍵PK及びマスター鍵MKは,以下のコンポーネントを有する。
PK=(g,h,{T_(j)}^(k)_(j=1),{T_(j)'}^(k)_(j=1))
MK=({x_(j)}^(k)_(j=1))」

「【0052】
鍵生成(MK,ω)
鍵生成アルゴリズムは,属性セットωと関連するユーザ秘密鍵を出力する。当該アルゴリズムは,ランダムな要素
ｘ∈Z^(*)_(ｐ)
を取り上げる(ここで,ｘは各ユーザに対して固有である)。秘密鍵SK_(ω)は,以下のコンポーネントを有する。
SKω=({S^((1))j=g^(x/xj)}a_(j)∈ω
S^((2))=g^(x)).」

「【0053】
再鍵生成(SK_(ω))”
このアルゴリズムは,委託者により実行される。再鍵生成アルゴリズムは,委託者に代わって署名するためのプロキシ及び受任者により用いられる再署名鍵を出力する。当該アルゴリズムは,ランダムな要素
d∈Zｐ
を取り上げて,これらをd=d1+d2となるような2つの部分d1,d2へ分割する。再署名鍵RSKωは,一方が受任者に対するコンポーネント,他方がプロキシに対するコンポーネントである,以下の2つのコンポーネントを有する。
RSK_(delegatee)=({g^(xd1/xj)}a_(j)∈ω,g^(xd1),g^(d),h^(d))
RSK_(proxy)=({g^(xd2/xj)}a_(j)∈ω,g^(xd))」

「【0054】
署名(RSK_(delegaｔee),m)
このアルゴリズムは,メッセージ
m∈G_(0)
に署名するための受任者により実行される。当該アルゴリズムは,ランダムな要素
ｓ’∈Z^(*)_(ｐ)
を選んで,以下のコンポーネントを有するσ_(delegaｔee)を計算する。

σ_(delegatee)=({σ^((1))j_(dee)=g^(xd1/xj)・h^(ds'm)}a_(j)∈ω
σ^((2))_(dee)=g^(xd1/s')
σ^((3))_(dee)=g^(ds')
σ^((4))_(dee)=g^(s'))」

「【0055】
再署名(RSK_(ｐｒｏｘｙ),σ_(delegaｔee),m)
このアルゴリズムは,プロキシにより実行される。第2のレベル(又は,最終的な署名)を作る前に,プロキシは,以下の態様で受任者により作られた署名を検証する。
I^((1))=e(σ^((1))j_(dee),T_(j))
=e(g,g)^(xd1)・e(g,h)^(ds'mxj):∀a_(j)∈w
I^((2))=e(σ^((2))_(dee),σ^((4))_(dee))・e((σ^((3))_(dee))^(m),T_(j)')
=e(g,g)^(xd1)・e(g,h)^(ds'mxj):∀a_(j)∈w」

「【0056】
ここで,I^((1))=I^((2))の場合,プロキシは第2のレベルの(又は最終的な)署名を作るため受任者により作られる署名を変換する。当該アルゴリズムは,ランダムな要素
ｒ∈Z^(*)_(ｐ)
を選んで,第2のレベルの署名を作る。
σ_(proxy)=({σ^((1))j_(p)=g^(xd2r/xj)・g^(xd1r/xj)・h^(ds'mr)}a_(j)∈ω
={g^(xdr/xj)・h^(ds'mr)}a_(j)∈ω
σ^((2))_(p)=(σ^((3))_(dee))^(r)=g^(ds'r)
σ^((3))_(p)=g^(xdr))」

「【0057】
検証(σｐｒｏｘｙ,PK)
以下の式が成り立つ場合,署名が受け入れられる。
e(σ^((1))j_(p),T_(j))=e(σ^((3))_(p),g)・e(T'_(j),(σ^((2))_(p))m):∀a_(j)∈ω
e(g^(xdr/xj)・h^(ds'mr),T_(j))=e(g^(xdr),g)・e((g^(ds'r))^(m),T'_(j)):∀a_(j)∈ω
e(g,g)^(xdr)・e(g,h)^(drs'mxj)=e(g,g)^(xdr)・e(g,h)^(drs'mxj):∀a_(j)∈ω」(添え字等を,一部変更している。以下,同じ。)

(イ)第2実施例(第2のスキーム)
本願明細書に記載された「第2実施例(第2のスキーム)」は,本願明細書の段落【0059】?段落【0065】に記載の,次のとおりのものである。

「【0059】
セットアップ
セットアップアルゴリズムは,主要なオーダーｐ並びにランダムジェネレータg及びhの双一次グループG_(0)を選択する。当該アルゴリズムは,双一次マップe:G_(0)ｘG_(0)→G_(1)を選ぶ。これ(の選択)に加えて,セットアップは,無作為に
x_(1),x_(2),・・・,x_(k)∈Z_(p)
を取り上げ,属性セット
Ω={a_(1),a_(2),...,a_(k)}
のために,
T_(j)=g^(xj)
及び
T'_(j)=h^(xj)
を(1≦j≦k)に対してセットする。公開鍵PK及びマスター鍵MKは,以下のコンポーネントを有する。
PK=(g,h,{T_(j)}^(k)_(j=1),{T_(j)'}^(k)_(j=1))
MK=({x_(j)}^(k)_(j=1))」

「【0060】
鍵生成(MK,ω)
鍵生成アルゴリズムは,属性セットωと関連するユーザ秘密鍵を出力する。アルゴリズムは,ｘ=ｔｑとなるように,ランダムな要素
ｘ,ｔ,ｑ∈Z^(*)_(ｐ)
を取り上げる(ここで,ｘ,ｔ及びｑは各ユーザに対して固有である)。秘密鍵SK_(ω)は,以下のコンポーネントを有する。
SKω=({S^((1))=g^(x/xj)}a_(j)∈ω
S^((2))=g^(x),{S^((3))=g^(t/xj)}a_(j)∈ω,S^((4))=g^(q))」

「【0061】
再鍵生成(SK_(ωdelegaｔｏｒ))
再鍵生成アルゴリズムは,受任者からの署名を委託者の署名に変換するためにプロキシにより用いられる再署名鍵を出力する。当該アルゴリズムは,ランダムな要素
d∈Z_(ｐ)
を取り上げる。再署名鍵RSK_(ω)は,以下の2つのコンポーネントを有する。
RSK_((proxy))=(RSK^((1))=(S^((1))_(j))^(d)={g^(xd/xj)}a_(j)∈ω
RSK^((2))=(S^((2)))^(d)=g^(xd))」

「【0062】
署名(SK_(ωdelegaｔee),m)
このアルゴリズムは、メッセージ”
m∈G_(0)
に署名するために受任者により実行される。当該アルゴリズムは,ランダムな要素
ｓ’∈Z^(*)_(ｐ)
を選んで,自分自身の秘密鍵を使用して署名σ_(delegaｔee)を計算する。σ_(dee)とも呼ばれる署名σ_(delegaｔee)は,以下のコンポーネントを有する。


」

「【0063】
再署名(RSK,σ_(delegaｔee),m)
このアルゴリズムは,プロキシにより実行される。当該アルゴリズムは,ランダムな要素
ｒ∈Z^(*)_(ｐ)
を選んで,受任者の署名を委託者の署名へ変換する。署名を変換する前に,プロキシは,署名が対応する受任者からの実際有効な署名であるかどうかを検証する。検証は,以下のように進む。


」

「【0064】
ここで,I(1)=I(2)の場合,検証は成功し,プロキシは,第2のレベルの(又は,最終的な)署名を生成する。第2のレベルの署名の生成は,以下のステップを有する。
第1のステップにおいて,プロキシは,以下を計算する。


第2のステップにおいて,プロキシは,以下を計算する。


第3のステップにおいて,プロキシは,以下を計算する。
c=H((Z^((2))),g^(r))=H(e(h,g)^(ms'),g^(r))
ここで,「H」は,ハッシュ関数である。
第4のステップにおいて,プロキシは,以下を計算する。


最終ステップにおいて,プロキシは,署名を出力する。
σ_(proxy)=(σ^((1))j_(p),σ^((2))_(p),σ^((3))_(p),σ^((4))_(p))」

「【0065】
検証(σ_(ｐｒｏｘｙ),PK)
変換された署名を検証するために,検証器は,以下のステップを実施する。
第1ステップにおいて,検証器は,以下を計算する。
c'=H(e(σ^((3))_(p),h^(m)),σ^((2))_(p))=H(e(g^(s'),h^(m)),g^(r))
第2ステップにおいて,以下の式が成り立つ場合,検証器は,署名を受け入れる。

」

ウ.「機能」の実現性についての検討
上記ア.において指摘した,補正後の請求項各項に係る発明が満たすべき「機能」について,上記イ.に引用の本願明細書の発明の詳細な説明に記載の第1実施例,及び,第2実施例が,当該「機能」を実現し得るか,以下に検討する。

(ア)第1実施例について
上記ア.において指摘した,補正後の請求項各項に係る発明が満たすべき「機能」とは,「第1のユーザ」が,「再署名ユニット」になりすます,即ち,「第1のユーザ」が,「再署名ユニット」が行うべき処理を代行しても,代行したことを検出できる。
或いは,「再署名ユニット」が,「第1のユーザ」になりすましたことを検出できることである。
これを,第1実施例に当てはめると,検証ステップにおいて,「受任者」が,「プロキシ」になりすましたこと,及び,「プロキシ」が,「受任者」になりすましたことを検出できれば,当該「機能」を実現していることになる。
今,「受任者」が,「受任者」が署名に用いるランダムな要素
ｓ’∈Z^(*)_(ｐ)
と,「プロキシ」が第2レベルの署名を生成する際に用いるランダムな要素
ｒ∈Z^(*)_(ｐ)
とを選択する。この2つのランダムな要素は,任意の値であるから,選択者が同一であることを妨げない。
次に,「受任者」は,
「メッセージm」,
「受任者」の署名鍵「RSK_(delegaｔee)」の「｛g^(ｘd1/ｘj)｝a_(j)∈ω,」,「g^(ｘd1)」,
「公開鍵PK」の「g」,「h」,
を用いて,署名“σ_(ｐｒｏｘｙ)’”を次のように計算する。
σ_(proxy)'=({σ^((1))j_(p)'=(g^(xd1/xj))^(r)・h^(s'mr)}a_(j)∈ω)
σ^((2))_(p)'=g^(s'r)
σ^((3))_(p)'=(g^(xd1))^(r))
次に,署名“σ_(ｐｒｏｘｙ)’”を,上記引用の第1実施例の検証ステップ(以下,これを「検証ステップ1」という)において検証する。
検証ステップ1の左辺に,上記で求めた,“σ_(ｐｒｏｘｙ)’”の“σ^((1))j_(ｐ)’”を入力して計算すると,
e(σ^((1))j_(p)',Tj)=e((g^(xd1/xj))^(r)・h^(s'mr),T_(j)):∀a_(j)∈ω
=e(g^(xrd1/xj)・h^(s'mr),g^(xj)):∀a_(j)∈ω
=e(g^(xrd1/xj),g^(xj))・e(h^(s'mr),g^(xj)):∀a_(j)∈ω
=e(g,g)^(xrd1)・e(h,e)^(s'mrd1):∀a_(j)∈ω
となる。
次に,検証ステップ1の右辺に,上記で求めた,“σ^((2))_(ｐ)’”,“σ^((3))_(ｐ)’”を入力して計算すると,
e(σ^((3))_(p)',g)・e(T'_(j),(σ^((2))_(p)')^(m)):∀a_(j)∈ω
=e((g^(xd1))^(r),g)・e(T'_(j),(g^(s'r))^(m)):∀a_(j)∈ω
=e(g^(xrd1),g)・e(h^(xj),g^(s'mr)):∀a_(j)∈ω
=e(g,g)^(xrd1)・e(h,g)^(s'mrxj):∀a_(j)∈ω
となり,右辺の計算結果は,先に計算した左辺の計算結果と一致する。
以上の検討結果は,「受信者」,即ち,「第1のユーザ」が,「プロキシ」,即ち,「再署名ユニット」に代わって,「第2レベルの署名」,即ち,「第2の署名」を生成することが可能であることを意味しているので,第1実施例は,なりすましを防止することはできず,上記において指摘した,補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。

(イ)第2実施例について
第2実施例では,「プロキシ」が,「受任者」になりすませることを示す。
「プロキシ」は,「プロキシ」が第2レベルの署名を生成する際に用いるランダムな要素
ｒ∈Z^(*)_(ｐ)
と,「受任者」が署名に用いるランダムな要素
ｓ’’∈Z^(*)_(ｐ)
とを選択する。この2つのランダムな要素は,任意の値であるから,選択者が同一であることを妨げない。
次に,「プロキシ」は,「メッセージm」,
再署名鍵「RSK_(ω)」の「｛g^(ｘd/ｘj)｝a_(j)∈ω,」,「g^(ｘd)」,
「公開鍵PK」の「g」,「h」,
を用いて,第2レベルの署名を次のように計算する。
c''=H(e(h,g)^(ms''),g^(r))
σ^((1))''_(jp)={(g^(xd/xj))^(r)・h^(c''r)}a_(j)∈ω
σ^((2))''_(p)=g^(r)
σ^((3))''_(p)=g^(s'')
σ^((4))''_(p)=(g^(xd))^(r)
σ''_(proxy)=(σ^((1))''_(jp),σ^((2))''_(p),σ^((3))''_(p),σ^((4))''_(p))
上記で求めた,「プロキシ」による署名を,上記に引用した,第2実施例における検証ステップ(以下,これを「検証ステップ2」という)において検証する。
検証ステップ2における第1ステップの式の左辺に,上記で求めた,“σ^((3))’’_(ｐ)”と,“σ^((2))''_(ｐ)”を入力して計算する。
c'''=H(e(σ^((3))''_(p),h^(m)),σ^((2))''_(p))
=H(e(g^(s''),h^(m)),g^(r))
=H(e(g,h)^(s''m),g^(r))=c''
次に,検証ステップ2の第2のステップの式の左辺に,上記で求めた,“σ^((1))''_(jｐ)”を代入して計算すると,
e(σ^((1))''_(jp),T_(j))=e((g^(xd/xj))^(r)・h^(c''r),g^(xj)):∀a_(j)∈ω
=e(g^(xdr/xj)・h^(c''r),g^(xj)):∀a_(j)∈ω
=e(g,g)^(xdr)・e(h,g)^(c''rxj):∀a_(j)∈ω
となる。
次に,第2のステップの右辺に,上記で求めた,“σ^((2))''_(ｐ)”と,“σ^((4))’’_(ｐ)”とを代入して計算すると,
e(σ^((4))''_(p),g)・e((σ^((2))''_(p))^(c'''),T'_(j))
=e((g^(xd))^(r),g)・e((g^(r))^(c'''),h^(xj)):∀a_(j)∈ω
=e(g^(xdr),g)・e(g^(rc'''),h^(xj)):∀a_(j)∈ω
=e(g,g)^(xdr)・e(g,h)^(rc'''xj):∀a_(j)∈ω
ここで,第1のステップの計算結果から,c’’’=c’’であるから,結局,
e(σ^((4))''_(p),g)・e((σ^((2))''_(p))^(c'''),T'_(j))
=e(g,g)^(xdr)・e(g,h)^(rc''xj):∀a_(j)∈ω
となり,右辺の計算結果は,先に計算した左辺の計算結果と一致する。
以上の検討結果は,「プロキシ」,即ち,「再署名ユニット」が,「受任者」,即ち,「第1のユーザ」の結果を用いることなく,「再署名ユニット」単独で取得可能な情報のみにより,「第2レベルの署名」,即ち,「第2の署名」を生成することが可能であることを意味しているので,第2実施例は,上記において指摘した,補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。

(ウ)第1実施例,及び,第2実施例以外の構成について
上記(ア),及び,(イ)において検討したとおり,第1実施例,及び,第2実施例の何れを用いても,補正後の請求項各項に係る発明が満たすべき「機能」を実現することができない。
そこで,本願明細書の発明の詳細な説明,及び,図面に記載された,第1実施例,及び,第2実施例以外の構成によって,本願の請求項各項に係る発明が満たすべき「機能」を実現することができないかについて,検討する。
第1実施例において,「受任者」によるなりすましを不可能にするためには,「第2レベルの署名」の作成において,「プロキシ」固有の秘密情報を用いるか,或いは,「検証器」が,「第2レベルの署名」が,「プロキシ」によって作成されたことが確認できないと,「第2レベルの署名」の検証を行わないといった構成を有することである。
しかしながら,上記指摘の「受任者」によるなりすましに対抗する構成については,本願明細書の発明の詳細な説明,及び,図面には記載されていない。
同様に,第2実施例において,「プロキシ」のみでの,「第2レベルの署名」の生成を不能にするためには,「第2レベルの署名」の作成において,「受任者」固有の秘密情報を用いるか,「検証器」が,「第2レベルの署名」が,「受任者」の署名を再変換したものであることが確認できないと,「第2レベルの署名」の検証を行わないといった構成を有することである。
しかしながら,上記指摘の「プロキシ」単体による,「受任者」の署名を伴わない,「第2レベルの署名」の作成に対抗する構成については,本願明細書の発明の詳細な説明,及び,図面には記載されていない。

なお,請求人は,平成28年4月4日付けの審判請求書(以下,これを「請求書」という)において,
「また,偽造とは,「ほんものに類似のものをつくること。にせものをつくること。」である(広辞苑第5版)。にせものを作る理由が,既存のインフラ/スキームをあざむく,だますためであることは,偽造テレホンカード(公衆電話を現状のまま使う),偽造コイン(自動販売機,ATM等を現状のまま使う),偽造切手,偽造紙幣の例より明らかである。
不正を行うプロキシに対して,スキームのとおり振る舞うことを強制する機構が明細書中に不存在であることを理由に,偽造署名の生成が可能としているが,偽造は上記のように既存スキームに従うことを前提としたものであり,審査官殿の技術認識には重大な誤りが存在する。
審査官殿が偽造可能とする結論に至る行為は,既存インフラ/スキームの破壊,改変,又は乗っ取りに該当するものであり,偽造とは相容れない。そもそも,既存インフラ/スキームの破壊,改変,又は乗っ取りが容易にできるのであれば,偽造など行わない。破壊,改変,又は乗っ取りのリスクが高いからこそ,またこうした行為には費用,労力,手間がかかるからこそ,偽造を選択する(例えば,全国に点在する公衆電話すべてに手を加えるより,入手が容易なテレホンカードをもとに,ほんものに類似するにせもののテレホンカードを作ることを選択する)のであり,審査官殿による誤認が本願の審査に重大な影響を及ぼすことは明らかである。
先の意見書で述べた「前者の受任者B→検証器Vへの直接の経路は,明細書において何ら記載されていない。受任者BはプロキシPに対し出力する存在である。」について,審査官殿は何ら考慮も判断もしていない。同様に「審査官殿は,出力が行われれば左辺=右辺を満たすであろうσproxy”については記載するものの,その前段で,プロキシPがこのσproxy”を出力することがどのように可能にされるのかを何ら明らかにしていない。」についても,審査官殿は何ら考慮も判断もしていない。」
と主張しているが,“なりすまし”(拒絶理由における「偽造」)については,上記「(3)独立特許要件」の「ウ.「機能」の実現性についての検討」において指摘したとおりであるから,請求人の請求書における上記引用の主張を採用することはできない。

(エ)以上(ア)?(ウ)において検討したとおりであるから,本願明細書の発明の詳細な説明,及び,図面には,補正後の請求項各項に係る発明が満たすべき「機能」を実現するための構成が記載されておらず,
よって,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

エ.独立特許要件むすび
以上,(ア)?(エ)において検討したとおりであるから,本件出願は,明細書及び図面の記載が上記の点で不備のため,特許法第36条第4項第1号に規定する要件を満たしていないので,補正後の請求項に記載されている事項により特定される発明は特許出願の際独立して特許を受けることができない。

3.補正却下むすび
したがって,本件手続補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。

第3.本願発明について
平成28年4月4日付けの手続補正は,上記のとおり却下されたので,本願の請求項1?請求項13に係る発明は,平成27年10月8日付けの手続補正により補正された特許請求の範囲の請求項1?請求項13に記載された,上記「第2.平成28年4月4日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1?補正前の請求項13として引用した記載により特定されるものである。

第4.原審の拒絶理由
原審における平成27年4月8日付けの拒絶理由(以下,これを「原審拒絶理由」という)は,概略,次のとおりである。

「 理 由

1.(実施可能要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。

2.＜省略＞
3.＜省略＞

4.(新規性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。

5.(進歩性)この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

記

●理由1(実施可能要件)について

・請求項 1-13
本願明細書に記載の各数式において,定義が明らかでない記号が用いられ,成立しない式が成立するとされており,誤記と思われるものが存在することから,それら各数式の意味を明確に把握することができない。以下に不明な式を挙げる。
1.＜省略＞
2.＜省略＞
3.＜省略＞
4.＜省略＞
5.＜省略＞
6.段落[0064]の Z(2)の計算式は成り立たない。一行目の e(g^(-s't/xj),g^(qs')) が二行目で e(g,g)^(-s'tq/xj) に変形されているが,二行目の指数部分は -s'2tq/xj となるべきであり,三行目の指数部分も -s'2x/xj となるべきである。したがって, Z(2)=e(h,g)^(ms') は成立しない。
7.＜省略＞

・請求項 3-9
請求項3には「第2の署名は前記再署名鍵により決定される属性の第2のセットと関連し」と記載されている。しかしながら,第2の署名と関連する属性の第2のセットを,「前記再署名鍵により決定される」ものとすることを,具体的にどのようにして実現するのか,発明の詳細な説明の記載を参照しても全く不明である。

・請求項 1-13
本願請求項1-13は,属性ベースのデジタル署名システム,署名を生成するステップを有する方法,前記方法を実施させるための命令を有するコンピュータプログラム,を請求するものである。
ところで,デジタル署名スキームは,署名鍵を所有する正当なユーザが,検証鍵で検証可能な署名を生成できるという以外に,署名鍵を所有しない不当なユーザが,正当な署名と同様に検証鍵で検証可能な不正な署名を偽造することができない,という要件をも満たす必要がある。これは,署名が偽造可能なものであるとすると,偽造された署名は正当な署名と同様に検証されることから,正当な署名と偽造された署名とを区別することができず,正当な署名であっても,それが偽造されたものであることを否定できないため,署名としての効力を認めることができないからである。

そこで,本願明細書の発明の詳細な説明に記載された属性ベースの代理再署名スキームについて検討すると,このスキームは,受任者であるエンティティAが,所定の属性に対応するエンティティAの署名鍵を用いて署名を作成し,プロキシPが,作成した署名を,再署名鍵を用いて変換し,変換後の署名は,エンティティBの属性に対応する検証鍵を用いて検証可能である,というものである。そうすると,このスキームにおいて,変換後の署名は,エンティティBの署名に相当するから,前記したことを考慮すれば,エンティティAおよびプロキシPの何れも,独力では,変換後の署名(エンティティBの署名)と同様に検証可能な署名を偽造可能であってはならない。このことは,本願の国際出願の出願当初の明細書にも"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行)として記載されていることである。(なお,翻訳文の段落[0022]の記載「斯様なシステムに対する望ましい特性の1つは,その人自身(看護師又は代理)以外の誰も,医師に代わって署名を作ることが可能であってはならないということである。」は,誤訳である。「その人自身・・・以外」なる日本語に相当する文は,国際出願の出願当初の明細書に存在しない。"by himself"は「一人で」「独力で」の意味であるから,前記の文は「斯様なシステムに対する望ましい特性の一つは,誰も独力で(看護士またはプロキシでも)医師に代わって署名を作ることが可能であってはならないということである。」とでも翻訳すべきものである。)

しかしながら,本願明細書の発明の詳細な説明に第1実施例として記載の発明においては,受任者が,委託者の第2のレベルの署名を,プロキシによる再署名の処理なしで,偽造することができる。第2実施例として記載の発明においては,プロキシが,委託者の第2のレベルの署名を,受任者による署名を用いることなく,偽造することができる。すなわち,明細書に記載の例でいえば,看護師あるいはプロキシが,それぞれ独力で,医師の署名を偽造することができ,偽造された署名は,医師の正規の署名として受理される。以下に説明する。

1.第1実施例

受任者は,ランダムな要素ｒ,ｓ'∈Z_(p)^(*)を生成し,メッセージm,署名鍵RSK_(delegatee)の｛g^(x/xj d1)｝a_(j)∈ω,g^(xd1),公開鍵PKのg,hを用いて,第2のレベルの署名の偽造署名を以下のように計算する。

σ_(proxy)'=(｛σ_(jp)^((1))' =(g^(x/xj d1))^(r)・h^(s'mr)｝a_(j)∈ω
σ_(p)^((2))' = g^(s'r)
σ_(p)^((3))' =(g^(xd1))^(r))

この偽造署名について,段落[0057]の検証式が正規の署名と同様に成立することから,偽造署名は正規の署名として受理される。偽造署名の作成に,プロキシによる再署名の処理は必要としない。

2.第2実施例

プロキシは,ランダムな要素ｒ,ｓ"∈Z_(p)^(*)を生成し,メッセージm,再署名鍵RSK_(ω)の｛g^(x/xj d)｝a_(j)∈ω,g^(xd),公開鍵PKのg,hを用いて,第2のレベルの署名の偽造署名を以下のように計算する。

c" = H(e(h,g)^(ms"),g^(r))

σ_(jp)^((1)") =｛(g^(x/xj d))^(r)・h^(c"r)｝a_(j)∈ω
σ_(p)^((2)") = g^(r)
σ_(p)^((3)") = g^(s")
σ_(p)^((4)") =(g^(xd))^(r)

σ_(proxy")=(σ_(jp)^((1)"),σ_(p)^((2)"),σ_(p)^((3)"),σ_(p)^((4)"))

この偽造署名について,段落[0065]の検証式が正規の署名と同様に成立することから,偽造署名は正規の署名として受理される。偽造署名の作成に,受任者の署名は必要としない。

以上で述べたとおり,本願明細書の発明の詳細な説明に記載の発明は,受任者あるいはプロキシが,独力で委託者の署名を偽造可能なものであるから,請求項1-13に記載のデジタル署名に関して,実施可能なものが実質的に開示されていない。

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

●理由2(明確性)について
＜省略＞
●理由4(当審注;“理由3”の誤記)(発明該当性)について
＜省略＞
●理由4(新規性)について

・請求項 1,2,11-13
・引用文献等 1
・備考
引用文献1には,ユーザAのIDから生成した署名鍵とメッセージとから,前記メッセージに対するユーザAの署名を生成し,前記ユーザAの署名と再署名鍵とから,前記メッセージに対するユーザBの署名を生成し,前記ユーザBの署名の生成は,ユーザAのIDとユーザBのIDとに基づく,IDベースのデジタル署名システム,が記載されている。(特に I. INTRODUCTION, IV. BIDIRECTIONAL CERTIFICATELESS PROXY RE-SIGNATURE)
引用文献1に記載の発明において,署名の生成は,ユーザ及びプロキシが行う(I. INTRODUCTION, A. Proxy re-signature and related work)ところ,技術常識を考慮すれば,その署名生成は,ユーザ及びプロキシがそれぞれ有する,各自のユニットにて行われることは,自明である。
そして,本願明細書段落[0003]の記載「しかしながら,ヘルスケア組織では,属性は,通常,ユーザの役割及び同一性を記述するために用いられ,データへのアクセスはユーザ属性に基づいて付与されている。・・・これらの属性は,また,特定のドメイン(例えば名前又は識別子)の個人に固有である個々の属性を有する。例えば,処方箋が特定の役割を持つ特定のユーザ(例えば医師ジョンスミス)により署名された場合,薬局は,処方箋を受理するだろう。」を参照すれば,本願における「属性」とは,ユーザの同一性を記述するために用いられる「ジョンスミス」の如きものを含むから,ユーザのIDを包含する概念である。
そうすると,引用文献1に記載の発明における,ユーザの「ID」は,本願請求項に係る発明の「属性」に相当するから,本願の請求項1,2,11-13に係る発明は,引用文献1に記載の発明と同一である。

●理由5(進歩性)について

・請求項 1,2,11-13
・引用文献等 1
・備考
これら請求項に係る発明は引用文献1に記載の発明と同一であるから,引用文献1に記載の発明に基づいて当業者が容易に想到し得たものでもある。

・請求項 3-10
・引用文献等 1,2
・備考
引用文献2には,ID情報から検証用の公開鍵を生成し,公開鍵からさらに署名用の秘密鍵を生成する方式であるID型暗号方式において,ID情報とは,ユーザの職業,所属,資格,現在位置等の属性情報を含む情報のことを意味すること,及び,ID情報を携帯電話端末から発行センタへと送信し,携帯電話端末において,一方向性関数Aを用いてID情報から公開鍵を生成し,ID情報を受信した発行センタ1は,一方向性関数Aを用いてID情報から公開鍵を生成し,センタ秘密鍵と公開鍵から一方向性関数Bを用いて秘密鍵を生成し,秘密鍵の生成が終了すると,SSL等を利用して携帯電話端末との間で認証を行い,認証が完了すると,発行センタは生成した秘密鍵を暗号化して携帯電話端末へ送信し,帯電話端末は受信した秘密鍵を復号化し,復号化した秘密鍵と生成した公開鍵とを保存し,ユーザAがユーザBの属性情報を取得する場合には,ユーザAの携帯電話端末からユーザBの携帯電話端末へとチャレンジ情報を送信し,ユーザBの携帯電話端末がチャレンジ情報を受信すると,端末内に保存されているID情報から開示したいID情報を選択し,そのID情報に対応する秘密鍵でチャレンジ情報を署名し,ユーザAの携帯電話端末に対してID情報および署名情報を送信し,ユーザAの 携帯電話端末がID情報および署名情報を受信すると,まずID情報から一方向性関数Aを用いて公開鍵を生成し,生成した公開鍵で署名情報を検証してID情報の正当性を確認し,ID情報の検証に成功すれば,携帯電話端末はID情報に含まれる属性情報をユーザBの属性情報として保存する,ことが記載されている。(特に,段落[0009]-[0018]を参照されたい。)
引用文献1に記載の発明は,IDから署名検証において用いるｕ_(i)を生成し,ｕ_(i)から署名用の秘密鍵であるDを生成するものであるから,引用文献1に記載の発明において,前記の引用文献2に記載の技術を参酌し,ユーザのIDを,ユーザの職業,所属,資格,現在位置等の,複数の属性情報を含むものとして,請求項3-10に係る発明の如く構成することは,当業者にとって容易である。

＜引用文献等一覧＞
1.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
2.特開2006-325072号公報」

第5.当審の判断
1.36条4項1号について
(1)「・請求項 1-13」の6.に関して
平成27年10月8日付けの手続補正においては,原審拒絶理由において,「・請求項 1-13」の6.として指摘された,段落【0064】の記載不備に関する補正はなされていないので,当該拒絶理由は解消していない。

(2)「・請求項 1-13」の項目として,
「本願請求項1-13は,属性ベースのデジタル署名システム,署名を生成するステップを有する方法,前記方法を実施させるための命令を有するコンピュータプログラム,を請求するものである」点に関して,理由を付して,「請求項1-13に記載のデジタル署名に関して,実施可能なものが実質的に開示されていない。」
と指摘した点について
当該指摘事項は,上記「第2.平成28年4月4日付けの手続補正の却下の決定」の「2.補正の適否」における「(2)目的要件」の「ウ.「機能」の実現性についての検討」において,(ア)?(エ)として検討した事項と同等のものであって,当該「ウ.「機能」の実現性についての検討」で検討したとおり,本願明細書の発明の詳細な説明,及び,図面には,補正後の請求項各項に係る発明が満たすべき「機能」を実現するための構成が記載されておらず,
よって,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。

2.29条1項3号,又は,同2項について
(1)本願発明について
本願明細書の発明の詳細な説明は,上記において検討したとおり,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものではないが,
本願の請求項1に係る発明は,以下の検討においては,本願の請求項1に記載された,以下の字句どおりのものする。

「第1のユーザのための第1の署名鍵及びドキュメントに基づいて,前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと,
第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するための再署名ユニットであって,前記再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される,再署名ユニットとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる,属性ベースのデジタル署名システム。」

(2)引用刊行物に記載の事項
ア.原審拒絶理由に引用された,本願の第1国出願前に既に公知である,「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」(以下,これを「引用刊行物1」という)には,次の事項が記載されている。

A.「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.」(157頁左欄30行?右欄11行,なお,下線は,当審にて,説明の都合上,付加したものである。以下,同じ。)
(A.プロキシ再署名と,関連した作業
プロキシ再署名スキームは,半信頼プロキシが,アリスと,ボブとの間の変換装置として動作するものとして,最初,ユーロクリプト’98において,ブレーズ,ブリューマー,及び,シュトラウス[3]によって紹介された。変換するために,プロキシは,同一のメッセージについて,アリスからの署名を,ボブからの署名に変換する。しかしながら,プロキシは,何れの署名する鍵も,覚えておらず,アリス,或いは,ボブの代理として,任意のメッセージに,署名することはできない。プロキシ再署名は,ウェブ証明書の共有,ネットワーク認証,及び,弱いグループ署名の形成に,非常に有用である。
プロキシ再署名は,プロキシ署名とは異なる。プロキシ署名は,プロキシと協力しているのであれば,アリスに,アリスの署名する権利を,ボブに委任することを許可するが,それだけである。しかしながら,プロキシ再署名システムにおいては,あるメッセージσ_(A)(m)について,完璧に正当で,パブリックに検証できる,アリスからの署名を,同じメッセージσ_(B)(m)についてのボブの署名に,変換することができる。その2つの署名は,共存することができ,両者は,同じメッセージについての,2人の異なる人物による2つの署名として,パブリックに証明することが可能である。<当審にて訳出。以下,同じ。>)

B.「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 (sk_(A), sk_(B)) = ((x_(A),D_(A)),(x_(B),D_(B))) , the re-signature key generation algorithm, REKey ,outputs a key rk_(A←→B) for the proxy, where X_(A)(X_(B)) is A's (B's) secret value, D_(A)(D_(B))is A's (B's) partial private key.
・ On input rk_(A←→B) , a public key pk_(A) , a message m ,and a signature σ ,the re-signature algorithm, RESign , outputs a new signature σ' on message m corresponding to pk_(B) if Verify(pk_(A'),m, σ) =1 and⊥otherwise.」(159頁左欄26行?左欄末行)
(IV.双方向認証無しプロキシ再署名
A.定義
双方向認証無しプロキシ再署名スキームは,以下の,6つのランダムなアルゴリズムかからなる:Seｔｕｐ,Keｙgen,ReKeｙ,Sign,ReSign,及び,Veｒifｙは:
・(Seｔｕｐ,Keｙgen,Sign,Veｒifｙ)は,通常の認証無し署名のそれらと同じである。
・入力(sk_(A), sk_(B)) = ((x_(A),D_(A)),(x_(B),D_(B))) に関して,再署名鍵生成アルゴリズム,ReKeｙは,プロキシのための鍵ｒk_(A←→B)を,出力し,ここで,ｘ_(A)(ｘ_(B))は,A(B)の,秘密の値であり,D_(A)(D_(B))は,A(B)の,部分的な個別鍵である。
・入力ｒk_(A←→B),公開鍵ｐk_(A),メッセージm,そして,署名σに関して,再署名アルゴリズム,ReSignは,もし, Verify(pk_(A'), m, σ) =1である時,ｐk_(B)に対応する,メッセージmについての,新しい署名σ’を出力し,かつ,それ以外の時は⊥を出力する。)

C.「B. SchemeI implement
Based on paper [5] and [6], we present a new certificateless bidirectional proxy re-signature scheme, denoted as S_(cl) . The scheme is consisted of six algorithms.
a) Setup: We assume the given length identities and messages are n_(id) and n_(m) (n_(id), n_(m) ∈Z), respectively. We choose two collision-resistant hash functions,
H_(id) : {O,l}^(*) → {O,l}^(nid) and H_(m) : {O,l}^(*) → {O,l}^(nm) .Furthermore, choose a random number α∈Z_(q') compute g_(1) = g^(α), and
then choose g_(2)∈G_(1), u',m'∈ _(R)Z_(q), u_(i )(i = 1, .. ・,n_(id)),m^_(i) (i= 1, .. ,n_(m))∈G_(1), g is a generator of G_(1). The public parameters are
{G_(1), G_(2), e, g, g_(1), g_(2), U', U_(i)}
and the master secret key is g^(α)_(2).
b) Keygen: Input the identity ID_(A'),choose a random number_(id) ∈_( R)Z_(q), KGC computes partial private key:
D_(A) = (d^(1)_(A),d^(2)_(A)) = (g^(α)_(2) (u'Πu_(i))^(rid),g^(rid))
i∈U
where u = H_(id) (ID_(A))',U ⊆ {I,・・・, n_(id)} 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 x_(A) ∈ _(R)Z^(*)_(ｑ); , and computes
pk_(A) = (pk^(1)_(A),pk^(2)_(A)) = (g^(XA) ,g^(XA)_(1))
then he sets sk_(A) = (x_(A) ,D_(A))' The user B sets his key in the same way.」(159頁右欄1行?右欄23行)
(B.スキームIの実装
論文[5],及び,[6]に基づいて,我々は,S_(cl)として示される,新しい,認証無し双方向プロキシ再署名スキームを,提示する。そのスキームは,6つのアルゴリズムから構成される。
a)Seｔｕｐ(設定):与えられた長さ識別子と,メッセージは,それぞれ,n_(id)と,n_(m)(n_(id),n_(m)∈Z)であると定義する。2つの,衝突耐性のある,ハッシュ関数,H_(id):｛O,l｝^(*)→｛O,l｝^(nid)と, H_(m) :｛O,l｝^(*)→｛O,l｝^(nm)を選択する。更に,乱数α∈Z_(ｑ)を選択し,g_(1)=g^(α)を計算し,次に,g_(2)∈G_(1),ｕ’,m’∈_(R)Z_(ｑ),ｕ_(i)(i=1,・・・,n_(id)),m^_(i)(i=1,・・・,n_(m))∈G_(1),を選択する。gは,G_(1)の生成元である。公開パラメータは,
｛G_(1),G_(2),e,g,g_(1),g_(2),ｕ’,ｕ_(i)｝
そして,マスタ秘密鍵は,g^(α)_(2)である。
b)Keｙgen(鍵生成):識別子ID_(A)を入力し,乱数ｒ_(id)∈_(R)Z_(ｑ)を選択し,KGCが,部分個別鍵:
D_(A)=(d^(1)_(A),d^(2)_(A))=(gα_(2)(u'Πu_(i))^(rid),g^(rid))
i∈U
を計算する。ここで,ｕ=H_(id)(ID_(A)),U⊆｛1,・・・n_(id)｝は,ｕ[i]=1であるような,添え字の組であり,ｕ[i]は,ｕのi番目のビットである。
ユーザAが,ｘ_(A)⊆_(R)Z^(*)_(ｑ)を選び,
pk_(A)=(pk^(1)_(A),pk^(2)_(A))=(g^(xA),g^(xA)_(1))
を計算する。次に,ユーザAは,ｓk_(A)=(ｘ_(A),D_(A))を設定する。ユーザBは,自分の鍵を,同じ方法で,設定する。)

D.「c) Rekey: Input two private keys (x_(A),D_(A)),(x_(B),D_(B)) ,
output the re-signature key:
rk_(A→B )= D^(xB)_(B)/D^(xA)_(A )=((d^(1)B)^(xB)/(d^(1)A)^(xA) , (d^(2)B)^(xB)/(d^(2)A)^(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 ID_(A) and the key (x_(A),D_(A)) , choose a random number r_(m)∈_(R)Z_(q). Compute
R_(m) = g^(rm),R_(A) = (d^(2)_(A))^(xA)
m^ = H_(m)(m,R_(A),R_(m),pk_(A))
then, output the sign:
σ_(A) = ((d^(1)_(A))^(xA) (m' Πm^_(i))^(rm) , (d^(2)_(A))^(ｘA) , g^(rm))
i∈M
= (V_(A),R_(A),R_(m))
where M ⊆ {1,・・ ,n_(m)} 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 rk_(A→B) , the public key pk_(A) ,a message m and a signatureσ_(A) = (V_(A),R_(A), R_(m)),
check that Verify(pk_(A), m,σ_(A)) = 1, if σ_(A) does not verify, output ⊥ ; otherwise output
σ_(B) = (V_(A)・(d^(1)_(B))^(xB)/ (d^(1)_(A))^(xA),R_(A)(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA),R_(m))
=((d^(1)_(B))^(ｘB) (m'Π m^_(i))^(rm) ,(d^(2)_(B))^(xB),g^(rm))
i∈M
= (V_(B),R_(B),R_(m))
f) Verify: Input the public key pk , the message m and the signature σ , compute m^ = H_(m)(m,R,R_(m),pk), if
e(g_(1),pk^(1)) = e(g,pk^(2)) ,
e(V, g) = e(pk^(2),g_(2))e(u'Πu_(i),R)e(m'Πm^_(i),R_(m))
i∈U i∈M
output 1 and 0 otherwise」(159頁右欄24行?160頁左欄10行)
c)Rekeｙ(再署名鍵生成):2つの個別鍵,(ｘ_(A),D_(A)),(ｘ_(B),D_(B))を入力し,再署名鍵:
rk_(A)→_(B)=D^(xB)_(B)/D^(xA)_(A)=((d^(1)_(B))^(xB)/(d^(1)_(A))^(xA),(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA))
を出力する。
(注 再署名鍵を得る,この方法は,[3]におけるのと,同じ方法と,仮定である。)
d)Sign(署名):メッセージm∈｛0,1｝^(*),識別子ID_(A),及び,鍵(ｘ_(A),D_(A))を入力し,乱数ｒ_(m)∈_(R)Z_(ｑ)を選び,
R_(m)=g^(rm),R_(A)=(d^(2)_(A))^(xA)
m^=H_(m)(m,R_(A),R_(m),pk_(A))
を計算する。次に,署名:
σ_(A)=((d^(1)_(A))^(xA)(m'Πm^_(i))^(rm),(d^(2)_(A))^(xA),g^(rm))
i∈M
=(V_(A),R_(A),R_(m))
を出力する。ここで,M⊆｛1,・・・,n_(m)｝は,m[i]=1であるような,添え字の組であり,m[i]は,m^のi番目のビットである。
e)Reｓign(再署名):再署名鍵ｒk_(A→B),公開鍵ｐk_(A),メッセージm,及び,署名σ_(A)=(V_(A),R_(A),R_(m))を入力し,Veｒifｙ(ｐk_(A),m,σ_(A))=1であることを,確認する。もし,立証しなければ,⊥を出力し;それ以外は,
σ_(B) = (V_(A)・(d^(1)_(B))^(xB)/ (d^(1)_(A))^(xA),R_(A)(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA),R_(m))

=((d^(1)_(B))^(xB)(m'Πm''_(i))^(rm) ,(d^(2)_(B))^(xB),g^(rm))
i∈M
=(V_(B),R_(B),R_(m))
を出力する。
f)Veｒifｙ(検証):公開鍵ｐk,メッセージm,及び,署名σを入力して,
m^=Hm(m,R,Rm,ｐk)を計算し,もし,
e(g_(1),pk^(1))=e(g,pk^(2)),
e(V,g)=e(pk^(2),g_(2))e(u'Πu_(i),R)e(m'Πm''_(i),R_(m))
i∈U i∈M
であれば,1を出力し,それ以外の場合は,0を出力する。)

イ.原審拒絶理由に引用された,本願の第1国出願前に既に公知である,特開2006-325072号公報(2006年11月30日公開,以下,これを「引用刊行物2」という)には,関連する図面と共に,次の事項が記載されている。

E.「【0009】
以下,図面を参照して本発明の第1の実施形態について説明する。図1は本発明の第1の実施形態にかかる属性情報交換システムを示した外観図である。図1において,発行センタ1は,ユーザの職業,所属,資格,現在位置情報等の属性情報に対して使用する暗号鍵を発行する機関であり,例えば地域コミュニティで運営する組織である。サービスプロバイダ2は,ユーザの携帯電話端末間またはユーザの携帯電話端末3a(3b)と発行センタ1との間のデータ通信の中継を行う機関である。
【0010】
図2は第1の実施形態で用いるID型暗号方式における暗号化方法を示した模式図である。ID型暗号方式とは,ID情報から復号(検証)用の公開鍵(復号鍵)を生成し,公開鍵からさらに暗号化(署名)用の秘密鍵(暗号鍵)を生成する方式である。ID型暗号方式の特徴は,意味のあるID情報から公開鍵を生成するため公開鍵の種類が豊富であり,また公開鍵自体に意味のある情報を持たせることができるという点にある。
【0011】
ここで,ID情報とは,上述の属性情報を含む情報のことを意味する。交換する属性情報を交換相手に譲渡できないよう制限を設ける場合は,個人を識別する情報や携帯電話端末の電話番号等の情報をID情報に含めることで,属性情報の所持者を明確に証明することが可能である。また,一定の期間内のみ有効な資格等を属性情報として交換する場合は,発行時刻をID情報に含めることで,相手から受信した属性情報の有効性を判断することが可能である。」

(3)引用刊行物1に記載の発明
ア.上記Cの「b) Keygen: Input the identity ID_(A'),choose a random number_(id) ∈_( R)Z_(q), KGC computes partial private key:
D_(A) = (d^(1)_(A),d^(2)_(A)) = (g^(α)_(2) (u'Πu_(i))^(rid),g^(rid))
i∈U
where u = H_(id) (ID_(A))',U ⊆ {I,・・・, n_(id)} 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 x_(A) ∈ _(R)Z^(*)_(ｑ); , and computes
pk_(A) = (pk^(1)_(A),pk^(2)_(A)) = (g^(XA) ,g^(XA)_(1))
then he sets sk_(A) = (x_(A) ,D_(A))' The user B sets his key in the same way.」
(b)Keｙgen(鍵生成):識別子ID_(A)を入力し,乱数ｒ_(id)∈_(R)Z_(ｑ)を選択し,KGCが,部分個別鍵:
D_(A)=(d^(1)_(A),d^(2)_(A))=(gα_(2)(u'Πu_(i))^(rid),g^(rid))
i∈U
を計算する。ここで,ｕ=H_(id)(ID_(A)),U⊆｛1,・・・n_(id)｝は,ｕ[i]=1であるような,添え字の組であり,ｕ[i]は,ｕのi番目のビットである。
ユーザAが,ｘ_(A)⊆_(R)Z^(*)_(ｑ)を選び,
pk_(A)=(pk^(1)_(A),pk^(2)_(A))=(g^(xA),g^(xA)_(1))
を計算する。次に,ユーザAは,ｓk_(A)=(ｘ_(A),D_(A))を設定する。ユーザBは,自分の鍵を,同じ方法で,設定する。)という記載,及び,
上記Dの「d) Sign: Input the message m∈{O,l}^(*) , the identity ID_(A) and the key (x_(A),D_(A)) , choose a random number r_(m)∈_(R)Z_(q). Compute
R_(m) = g^(rm),R_(A) = (d^(2)_(A))^(ｘA)
m^= H_(m)(m,R_(A),R_(m),pk_(A))
then, output the sign:
σ_(A) = ((d^(1)_(A))^(ｘA) (m' Πm^_(i))^(ｒm) , (d^(2)_(A))^(ｘA) , g^(rm))
i∈M
= (V_(A),R_(A),R_(m))」
(d)Sign(署名):メッセージm∈｛0,1｝^(*),識別子ID_(A),及び,鍵(ｘ_(A),D_(A))を入力し,乱数ｒm∈RZｑを選び,
R_(m)=g^(rm),R_(A)=(d^(2)_(A))^(xA)
m^=H_(m)(m,R_(A),R_(m),pk_(A))
を計算する。次に,署名:
σ_(A)=((d^(1)_(A))^(xA)(m'Πm^_(i))^(rm),(d^(2)_(A))^(xA),g^(rm))
i∈M
=(V_(A),R_(A),R_(m)))という記載から,引用刊行物1には,“ユーザAの識別子ID_(A)と,ユーザAの署名鍵ｓk_(A)=(ｘ_(A),D_(A))と,メッセージmとに基づいて,ユーザAの署名(V_(A),R_(A),R_(m))を生成する,第1の署名生成部”が存在していることが読み取れる。

イ.上記Bの「・On input rk_(A←→B) , a public key pk_(A) , a message m ,and a signature σ ,the re-signature algorithm, RESign , outputs a new signature σ' on message m corresponding to pk_(B) if Verify(pk_(A') m, σ) =1 and⊥otherwise.」
(・入力ｒk_(A←→B),公開鍵ｐk_(A),メッセージm,そして,署名σに関して,再署名アルゴリズム,ReSignは,もし, Verify(pk_(A') m, σ) =1である時,ｐk_(B)に対応する,メッセージmについての,新しい署名σ’を出力し,かつ,それ以外の時は⊥を出力する。)という記載,及び,上記Dの「e) Resign: Input a re-signature key rk_(A→B) , the public key pk_(A) ,a message m and a signatureσ_(A) = (V_(A),R_(A), R_(m)),
check that Verify(pk_(A), m,σ_(A)) = 1, if σ_(A) does not verify, output ⊥ ; otherwise output
σ_(B) = (V_(A)・(d^(1)_(B))^(xB)/ (d^(1)_(A))^(xA),R_(A)(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA),R_(m))
=((d^(1)_(B))^(xB) (m'Π m^_(i))^(rm) ,(d^(2)_(B))^(xB),g^(rm))
i∈M
= (V_(B),R_(B),R_(m))」
(e)Reｓign(再署名):再署名鍵ｒk_(A→B),公開鍵ｐk_(A),メッセージm,及び,署名σ_(A)=(V_(A),R_(A),R_(m))を入力し,Veｒifｙ(ｐk_(A),m,σ_(A))=1であることを,確認する。もし,立証しなければ,⊥を出力し;それ以外は,
σ_(B) = (V_(A)・(d^(1)_(B))^(xB)/ (d^(1)_(A))^(xA),R_(A)(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA),R_(m))

=((d^(1)_(B))^(xB)(m'Πm''_(i))^(rm) ,(d^(2)_(B))^(xB),g^(rm))
i∈M
=(V_(B),R_(B),R_(m))
を出力する。)という記載から,引用刊行物1には,“再署名鍵ｒk_(A→B),署名σ_(A)=(V_(A),R_(A),R_(m))に基づいて,メッセージmに再署名(V_(B),R_(B),R_(m))を行う,再署名部”が存在していることが読み取れる。

ウ.上記Bの「・ On input (sk_(A), sk_(B)) = ((x_(A),D_(A)),(x_(B),D_(B))) , the re-signature key generation algorithm, REKey ,outputs a key rk_(A?B) for the proxy, where X_(A)(X_(B)) is A's (B's) secret value, D_(A)(D_(B))is A's (B's) partial private key.」
(・入力(sk_(A), sk_(B)) = ((x_(A),D_(A)),(x_(B),D_(B))) に関して,再署名鍵生成アルゴリズム,ReKeｙは,プロキシのための鍵ｒk_(A?B)を,出力し,ここで,ｘ_(A)(ｘ_(B))は,A(B)の,秘密の値であり,D_(A)(D_(B))は,A(B)の,部分的な個別鍵である。)という記載,及び,上記Dの「c) Rekey: Input two private keys (x_(A),D_(A)),(x_(B),D_(B)) ,
output the re-signature key:
rk_(A→B )= D^(xB)_(B)/D^(xA)_(A )=((d^(1)B)^(xB)/(d^(1)A)^(xA) , (d^(2)B)^(xB)/(d^(2)A)^(xA))」
(c)Rekeｙ(再署名鍵生成):2つの個別鍵,(ｘ_(A),D_(A)),(ｘ_(B),D_(B))を入力し,再署名鍵:
rk_(A)→_(B)=D^(xB)_(B)/D^(xA)_(A)=((d^(1)_(B))^(xB)/(d^(1)_(A))^(xA),(d^(2)_(B))^(xB)/(d^(2)_(A))^(xA))
を出力する。)という記載から,引用刊行物1においては,“再署名鍵ｒk_(A→B)の生成には,ユーザAとは異なる,ユーザBの署名鍵(ｘ_(B),D_(B))が用いられる再署名部”が読み取れる。

エ.上記ア.において検討した,ユーザAの署名鍵,及び,ユーザBの署名鍵の生成方法と,上記イ.において検討した事項から,ユーザAの署名には,ユーザAの識別子ID_(A)が関係し,そして,ユーザBの署名鍵は,ユーザBの識別子ID_(B)と関係していて,再署名には,ユーザBの署名鍵が用いられることから,再署名が,少なくとも,ユーザBのユーザBの識別子ID_(B)と関係しているといえるので,引用刊行物1においては,“ユーザAの署名は,ユーザAの識別子ID_(A)が関係し,再署名は,少なくとも,ユーザBのユーザBの識別子ID_(B)と関係している”ことが読み取れる。

オ.上記ア.?エ.において検討した事項,及び,上記Aの「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.」(プロキシ再署名スキームは,半信頼プロキシが,アリスと,ボブとの間の変換装置として動作するものとして,最初,ユーロクリプト’98において,ブレーズ,ブリューマー,及び,シュトラウス[3]によって紹介された。変換するために,プロキシは,同一のメッセージについて,アリスからの署名を,ボブからの署名に変換する。)という記載から,引用刊行物1は,“ユーザAの署名を,ユーザBの署名に変換する,署名変換システム”に関するものであることが,読み取れる。

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

「ユーザAの識別子ID_(A)と,ユーザAの署名鍵ｓk_(A)=(ｘ_(A),D_(A))と,メッセージmとに基づいて,ユーザAの署名(V_(A),R_(A),R_(m))を生成する,第1の署名生成部と,
再署名鍵ｒk_(A→B),署名σ_(A)=(V_(A),R_(A),R_(m))に基づいて,メッセージmに再署名(V_(B),R_(B),R_(m))を行う,再署名部であって,
前記再署名鍵ｒk_(A→B)の生成には,ユーザAとは異なる,ユーザBの署名鍵(ｘ_(B),D_(B))が用いられる,再署名部とを有し,
ユーザAの署名は,ユーザAの識別子ID_(A)が関係し,再署名は,少なくとも,ユーザBの識別子ID_(B)と関係している,
ユーザAの署名を,ユーザBの署名に変換する,署名変換システム。」

(4)本願発明と引用発明との対比
ア.引用発明における「ユーザAの署名鍵ｓk_(A)=(ｘ_(A),D_(A))」,「メッセージm」,及び,「ユーザAの署名(V_(A),R_(A),R_(m))」が,
本願発明における「第1のユーザのための第1の署名鍵」,「ドキュメント」,及び,「ドキュメントに対する第1の署名」に相当するので,
引用発明における「ユーザAの識別子ID_(A)と,ユーザAの署名鍵ｓk_(A)=(ｘ_(A),D_(A))と,メッセージmとに基づいて,ユーザAの署名(V_(A),R_(A),R_(m))を生成する,第1の署名生成部」が,
本願発明における「第1のユーザのための第1の署名鍵及びドキュメントに基づいて,前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニット」に相当する。

イ.引用発明における「再署名鍵ｒk_(A→B)」,「署名σ_(A)=(V_(A),R_(A),R_(m))」,及び,「再署名(V_(B),R_(B),R_(m))」が,
本願発明における「再署名鍵」,「第1の署名」,及び,「ドキュメントに対する第2の署名」に相当するので,
引用発明における「再署名鍵ｒk_(A→B),署名σ_(A)=(V_(A),R_(A),R_(m))に基づいて,メッセージmに再署名(V_(B),R_(B),R_(m))を行う,再署名部」が,
本願発明における「第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するための再署名ユニット」に相当する。

ウ.引用発明における「ユーザB」,「署名鍵(ｘ_(B),D_(B))」が,
本願発明における「第2のユーザ」,「第2の署名鍵」に相当するので,
引用発明における「再署名鍵ｒk_(A→B)の生成には,ユーザAとは異なる,ユーザBの署名鍵(ｘ_(B),D_(B))が用いられる,再署名部」は,
本願発明における「再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される,再署名ユニット」に相当する。

エ.引用発明における「ユーザAの識別子ID_(A)」,及び,「ユーザBの識別子ID_(B)」は,それぞれ,「ユーザAに関連する情報」,及び,「ユーザBに関連する情報」と言い得るものであるから,
本願発明における「第1のユーザが所有する属性」,及び,「第2のユーザが所有する属性」と,
“第1のユーザに関連する情報”,及び,“第2のユーザに関連する情報”である点で共通するので,
引用発明における「ユーザAの署名は,ユーザAの識別子ID_(A)が関係し,再署名は,少なくとも,ユーザBの識別子ID_(B)と関係している」と,
本願発明における「第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザが所有する属性が関連付けられる」とは,
“第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザに関連する情報に関係付けられている”点で共通する。

オ.引用発明においても,「デジタル署名」を行っていることは明らかであるから,
引用発明における「ユーザAの署名を,ユーザBの署名に変換する,署名変換システム」と,
本願発明における「属性ベースのデジタル署名システム」とは,
“デジタル署名システム”である点で共通する。

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

[一致点]
第1のユーザのための第1の署名鍵及びドキュメントに基づいて,前記ドキュメントに対する第1の署名を生成するための第1の署名生成ユニットと,
第1の署名及び再署名鍵に基づいて,前記ドキュメントに対する第2の署名を生成するための再署名ユニットであって,
再署名鍵が,前記第1のユーザと異なる第2のユーザのための第2の署名鍵に基づき生成される,再署名ユニットとを有し,
第1の署名及び/又は第2の署名には,前記第1のユーザ及び/又は前記第2のユーザに関連する情報に関係付けられている,
デジタル署名システム。

[相違点1]
“ユーザに関連する情報”に関して,
本願発明においては,「第1のユーザ及び/又は前記第2のユーザが所有する属性」であるのに対して,
引用発明においては,「ユーザAの識別子ID_(A)」,及び,「ユーザBの識別子ID_(B)」であって,当該「識別子」が,「ユーザ」の「属性」といえるかに関しては,特に言及がない点。

[相違点2]
“デジタル署名システム”に関して,
本願発明においては,「属性ベースのデジタル署名システム」であるのに対して,
引用発明においては,「識別子」に基づくものであることまでは,読み取れるが,当該「識別子」を「属性」に含めることができるかについては,特に,言及がない点。

(5)相違点についての当審の判断
ア.[相違点1]について
本願発明における「属性」に関して,本願明細書の発明の詳細な説明には,その段落【0003】に,
「属性ベースの署名が使われている。よって,ヘルスケアでは,属性は,データ発信元を証明する主要なソースであるとみなされる。これらの属性は,また,特定のドメイン(例えば名前又は識別子)の個人に固有である個々の属性を有する。例えば,処方箋が特定の役割を持つ特定のユーザ(例えば医師ジョンスミス)により署名された場合,薬局は,処方箋を受理するだろう。」
と記載されていて,上記引用の記載においては,“医師の名前”により署名された場合に,当該署名を受理する点が記載され,この記載に従えば,“医師の名前”は,一種の「属性」として扱われていることは,明らかである。そして,当該“医師の名前”は,「識別子」と同じく,「特定のドメイン」を示す情報でもあるから,本願明細書の発明の詳細な説明においては,「名前」と,同じく「識別子」も,「属性」に含まれるものであるといえる。
そうすると,引用発明における「識別子」も,「属性」に含まれるものと言い得るので,[相違点1]は,表現の差こそあれ,実質的な相違には当たらない。

イ.[相違点2]について
上記ア.で検討したとおり,「識別子」が,「属性」の1つと言い得るものであれば,引用発明における「署名変換システム」も,「ユーザの署名」が,「識別子」に関連づけられていることは,明らかであるから,“属性に基づくシステム”と言い得るものである。
よって,[相違点2]は,表現の差こそあれ,実質的な相違には当たらない。

(6)29条1項3号,又は,同2項についてのむすび
以上,ア.,及び,イ.に検討したとおり,本願発明は,引用刊行物1に記載された発明である。
よって,本願発明は,引用刊行物1に記載の発明に基づいて,当業者が容易になし得たものである。

なお,仮に,引用発明における「識別子」が,「属性」に含まれないものであると解釈しても,引用刊行物2の,上記Eに引用した記載内容にもあるとおり,“ユーザの職業,所属,資格,現在位置情報等の属性情報を,ID情報とする”ことは,本願の第1国出願前に,当業者には,広く知られた技術事項であり,該「ID情報」は,「署名鍵」の生成に用いられるものであるから,引用発明において,「識別子」に代えて,引用刊行物2に係る発明における「ID情報」を採用することは,当業者が適宜なし得る事項である。
よって,[相違点1],及び,[相違点2]は,格別のものではなく,そして,本願発明の構成によってもたらされる効果も,当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

第6.むすび
以上「第5.当審の判断」の「1.36条4項1号について」において検討したとおりであるから,
本願は,特許法第36条第4項第1号に規定する要件を満たしていない。
そして,「第5.当審の判断」の「2.29条1項3号,又は,同2項について」において検討したとおりであるから,
本願の発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。
加えて,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
審理終結日 2017-05-26 
結審通知日 2017-06-05 
審決日 2017-06-19 
出願番号 特願2013-525395(P2013-525395)
審決分類 P 1 8・ 121- Z (H04L)
P 1 8・ 536- Z (H04L)
P 1 8・ 575- Z (H04L)
最終処分 不成立  
前審関与審査官 中里 裕正  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
辻本 泰隆
発明の名称 属性ベースのデジタル署名  
代理人 特許業務法人M＆Sパートナーズ  

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