2024-011297

特願２０２３－１５１７４３「データ構造、情報処理装置、情報処理方法、情報処理システム」拒絶査定不服審判事件〔令和 ７年 ３月１４日出願公開、特開２０２５－ ３５９４２〕について、次のとおり審決する。

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

理 由 １ 手続の経緯 本願は、２０２３年（令和５年）９月１日を出願日とする特許出願であって、その手続の経緯は以下のとおりである。 令和 ５年１２月２８日付け：拒絶理由通知書 令和 ６年 ２月 ２日 ：意見書、手続補正書の提出 令和 ６年 ４月２６日付け：拒絶査定（以下、「原査定」という。） 令和 ６年 ６月２１日 ：審判請求書 令和 ７年 ４月２２日付け：拒絶理由通知書 令和 ７年 ７月 ４日 ：意見書の提出 第２ 本願発明 本願の請求項１ないし７に係る発明は、令和６年２月２日に提出された手続補正書により補正された特許請求の範囲の請求項１ないし７に記載された事項により特定されるものであり、そのうち請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。 「 データ証明書は、公開鍵を用いた証明書のデータ構造であって、 ユーザデバイスの特徴を有する情報処理装置と、証明書システムの特徴を有する情報処理システムで用いられ、 データ証明書について一意となる識別子、 ユーザについて一意となる識別子、 デジタル署名の検証鍵、 デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名、 証明書システムの検証鍵、 デジタル署名の対象となるデータについて、データの価値と権利に関する情報、データの利用と履歴に関する情報、瑕疵に関する情報、データに関する認否、賛否、合意形成を表す信用データ、 データ証明書間の関連を示すため、データ証明書について一意となる識別子のリスト、 を有するデータ構造。」 第３ 当審拒絶理由 令和７年４月２２日付けで当審が通知した拒絶理由（以下、「当審拒絶理由」という。）は、概略、次のとおりのものである。 「１．（サポート要件）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。 ２．（明確性）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 記 ●理由１（サポート要件）について （１）請求項１ないし７について ア 本願が解決しようとする課題は、明細書の【０００５】及び【００１０】の記載を参酌すると、「データの信用を形成する」ことであるといえる。 ここで、上記課題を解決するための手段（課題解決手段）に関して、明細書における「対象データは、ユーザが所有または利用している、デジタル署名の対象となるデータである。」（【００１３】）、「信用データは、対象データについての信用を形成する情報である。」（【００２２】）、「ユーザＡがユーザデバイスＡを用いて、デジタル署名の対象となるデータからデータ証明書Ａを生成」（【０００９】）、「データ証明書に信用に関する情報を関連づけるユーザＢ」（【０００６】）、「ユーザＡはユーザデバイスＡを用いて、・・・（中略）・ ・・信用データを利用する。」（【００１９】）という記載を踏まえると（下線は当審で付与した。以下同様である。）、本願の課題解決手段は以下の構成を前提とするものであると認められる。 （ア）（ある特定のユーザである）「ユーザＡ」が所有または利用している「対象データ」に対して、（ユーザＡとは異なる）「ユーザＢ」が「信用データ」を関連づけること。（以下、「構成（ア）」という。） （イ）「ユーザＡ」が「信用データ」を利用すること。（以下、「構成（イ）」という。） さらに、本願の上記課題を解決するためには、構成（ア）において「対象データ」を所有または利用しているのが「ユーザＡ」であることを「ユーザＢ」が確認できること、及び、構成（イ）において「信用データ」を関連づけたのが「ユーザＢ」であることを「ユーザＡ」が確認できることが必要であることは本願出願時の技術常識から明らかである。 そして、上記「ユーザＡ」及び「ユーザＢ」を確認することに関して、明細書及び図面には、次のように記載されている。 「【０００６】 ・・・（中略）・・・ システム構成は、ユーザデバイスと証明書システムからなる。ユーザはデジタル署名の対象となるデータの証明書を用いるユーザＡと、データ証明書に信用に関する情報を関連づけるユーザＢのユースケースがあるため、それぞれのデバイスを、ユーザデバイスＡ、ユーザデバイスＢとする。 デジタル署名の対象となるデータに関する証明書を、データ証明書とする。データ証明書のフィールドの取扱いが異なるため、ユーザデバイスＡとユーザデバイスＢが用いるデータ証明書を、データ証明書Ａとデータ証明書Ｂとする。」 「【００１６】 ユーザデバイスＡは、データ証明書Ａ生成、データ証明書Ａ登録要求、データ証明書取得要求、データ証明書Ｂ検証を備える。 データ証明書Ａ生成は、データ証明書Ａを生成し、フィールドに記録する。 ユーザ識別子は、ユーザＡに対して一意となる値を用いる。外部の情報処理システムから取得したものでも、ＩＣチップなど記録装置のデータを読み取ったものでもよい。 デジタル署名の検証鍵は、検証鍵を用いる。 デジタル署名は、対象データと署名鍵からデジタル署名アルゴリズムで生成した値を用いる。 データ証明書Ａ登録要求は、データ証明書Ａを証明書システムに送信する。証明書システムから処理結果の値、データ証明書識別子を受信する。 データ証明書取得要求は、データ証明書を証明書システムから取得する。データ証明書識別子を送信し、該当するデータ証明書と処理結果、もしくは処理結果のみを受信する。必要に応じて、要求時にユーザデバイスの検証鍵を送信してもよい。 データ証明書Ｂ検証は、データ証明書Ｂの検証と信用データの利用を行う。データ証明書Ａのデジタル署名と、データ証明書Ｂのデジタル署名を、証明書システムの検証鍵で復号し、復号後のデータ証明書Ｂのデジタル署名と、データ証明書Ｂの検証鍵と、復号後のデータ証明書Ａのデジタル署名を用いて、署名検証アルゴリズムを行い判定する。判定後、データ証明書Ｂの信用データを表示するなどして用いる。データ証明書Ａの関連証明書データを用いて、複数のデータ証明書Ｂの信用データの一覧を表示してもよい。」 「【００１７】 証明書システムは、一つの情報処理システムとしてデータ証明書を管理してもよい。または、データ証明書Ａの管理と、データ証明書Ｂの管理を複数の情報処理システムで分散してもよい。証明書システムは、個別のサービスであっても、サービスの一部であってもよい。 証明書システムは、データ証明書Ａ登録応答、データ証明書取得応答、データ証明書Ｂ登録応答からなる。 データ証明書Ａ登録応答は、ユーザデバイスＡから受信したデータ証明書Ａを、データ証明書リストに格納する。格納時に以下のフィールドを記録する。 データ証明書識別子は、データ証明書に対して一意となる値を用いる。 証明書システムの検証鍵は、証明書システムが生成した検証鍵を用いる。 デジタル署名は、データ証明書Ａのデジタル署名の値を、証明書システムの署名鍵で暗号化する。 必要に応じて、データ証明書Ａの受付時刻データに時刻を示す値を記録してもよい。 ユーザデバイスＡに、処理結果、データ証明書識別子を送信する。または、処理結果のみを送信する。 データ証明書取得応答は、ユーザデバイスに、受信したデータ証明書識別子が示すデータ証明書リスト内のデータ証明書と、処理結果を送信する。必要に応じて、ユーザデバイスから受信した検証鍵を用いて、データ証明書を暗号化して送信してもよい。 データ証明書Ｂ登録応答は、ユーザデバイスＢから受信したデータ証明書Ｂをデータ証明書リストに格納する。格納時に、データ証明書Ｂのデジタル署名の値を、証明書システムの署名鍵で復号し、データ証明書Ｂのデジタル署名の検証鍵、データ証明書Ｂの復号後のデジタル署名、関連証明書データが示すデータ証明書Ａのデジタル署名を証明書システムの検証鍵で復号した値を用いて、署名検証アルゴリズムを行う。データ証明書Ｂの以下のフィールドに記録し、データ証明書リストに格納する。 データ証明書Ｂのデータ証明書識別子は、データ証明書に対して一意となる値を用いる。 データ証明書Ｂの証明書システムの検証鍵は、証明書システムの検証鍵を用いる。 デジタル署名は、データ証明書Ｂの復号後のデジタル署名の値を、証明書システムの署名鍵で暗号化する。 データ証明書Ｂの関連証明書データが示すデータ証明書Ａは、データ証明書Ｂのデータ証明書識別子を関連証明書データに追加して記録する。 必要に応じて、データ証明書Ｂの受付時刻データに、時刻を示す値を記録してもよい。 ユーザデバイスＢに、処理結果、データ証明書識別子を送信する。または、処理結果のみを送信する。」 「【００１８】 ユーザデバイスＢは、データ証明書取得要求、データ証明書Ａ検証、データ証明書Ｂ生成、データ証明書Ｂ登録要求を備える。 データ証明書取得要求は、ユーザデバイスＡと同様である。 データ証明書Ａ検証は、データ証明書Ａのデジタル署名を検証する。データ証明書Ａのデジタル署名を証明書システムの検証鍵で復号する。データ証明書Ａの検証鍵、データ証明書Ａの復号後のデジタル署名、対象データを用いて、署名検証アルゴリズムを行い処理結果を取得する。 データ証明書Ｂ生成は、データ証明書Ｂを生成しフィールドに記録する。 ユーザ識別子は、ユーザＢに対して一意となる値を用いる。外部のシステムから取得したものでも、ＩＣチップなど記録装置のデータを読み取ったものでもよい。 デジタル署名の検証鍵は、検証鍵を用いる。 デジタル署名は、復号したデータ証明書Ａのデジタル署名の値と、署名鍵を用いて、デジタル署名アルゴリズムで生成し、証明書システムの検証鍵で暗号化する。 信用データは、ユーザが入力したものなど任意の値を用いる。 関連証明書データは、データ証明書Ａのデータ証明書識別子を用いる。 データ証明書Ｂ登録要求は、データ証明書Ｂを証明書システムに送信する。証明書システムから処理結果、データ証明書Ｂのデータ証明書識別子を受信する。」 上記記載によれば、上記「ユーザＡ」を確認することについては、以下の処理によって実現するものと認められる。 ・「ユーザデバイスＡ」が、「対象データ」と「（ユーザデバイスＡの）署名鍵」から生成した「（ユーザデバイスＡの）デジタル署名」を含む「データ証明書Ａ」を生成する。（以下、「構成（ａ）」という。） ・「証明書システム」が、「データ証明書Ａ」の「（ユーザデバイスＡの）デジタル署名」を「証明書システムの署名鍵」で暗号化する。（以下、「構成（ｂ）」という。） ・「ユーザデバイスＢ」が、「データ証明書Ａ」の「（ユーザデバイスＡの）デジタル署名」を「証明書システムの検証鍵」で復号し、「データ証明書Ａの（ユーザデバイスＡの）検証鍵」、「復号後の（ユーザデバイスＡの）デジタル署名」、「対象データ」を用いて署名検証アルゴリズムを行う。（以下、「構成（ｃ）」という。） また、上記「ユーザＢ」を確認することについては、以下の処理によって実現するものと認められる。 ・「ユーザデバイスＢ」が、「復号後の（ユーザデバイスＡの）デジタル署名」と「（ユーザデバイスＢの）署名鍵」から生成した「（ユーザデバイスＢの）デジタル署名」を含む「データ証明書Ｂ」を生成する。（以下、「構成（ｄ）」という。） ・「証明書システム」が、「データ証明書Ｂ」の「（ユーザデバイスＢの）デジタル署名」を「証明書システムの署名鍵」で暗号化する。（以下、「構成（ｅ）」という。） ・「ユーザデバイスＡ」が、「データ証明書Ｂ」の「（ユーザデバイスＢの）デジタル署名」を、「証明書システムの検証鍵」で復号し、「データ証明書Ｂの（ユーザデバイスＢの）検証鍵」、「復号後の（ユーザデバイスＢの）デジタル署名」、「復号後の（ユーザデバイスＡの）デジタル署名」を用いて署名検証アルゴリズムを行う。（以下、「構成（ｆ）」という。） さらに、「ユーザデバイスＡ」が生成した「データ証明書Ａ」と、「ユーザデバイスＢ」が生成した「データ証明書Ｂ」は、データ証明書について一意となる識別子によって、互いに関連付けられている。（以下、「構成（ｇ）」という。） 以上によれば、本願の課題解決手段は、構成（ア）及び構成（イ）を前提とするものであり、構成（ａ）ないし構成（ｇ）を含むものであると認められる。 ここで、請求項１に係る発明が上記課題解決手段を反映したものであるかについて検討する。 構成（ア）及び構成（イ）に関して、請求項１には「データ証明書」が「ユーザデバイスの特徴を有する情報処理装置・・・で用いられ」ること、「データ構造」が「ユーザについて一意となる識別子」、「デジタル署名の対象となるデータより・・・デジタル署名」、「デジタル署名の対象となるデータについて、・・・（中略）・・・信用データ」を有することが記載されている。しかしながら、請求項１の上記記載は、以下の点が具体的に特定されていない。 ・「ユーザデバイス」はどのユーザが用いるものであるのか。 ・「ユーザについて一意となる識別子」はどのユーザのものであるのか。 ・「デジタル署名の対象となるデータ」（「対象データ」に対応）を所有または利用しているのはどのユーザであるのか。 ・「信用データ」を含む「データ証明書」を生成する（「信用データ」を関連づける）のはどのユーザであるのか。 したがって、請求項１に係る発明は、（ある特定のユーザである）「ユーザＡ」及び（ユーザＡとは異なる）「ユーザＢ」について、並びに、「対象データ」及び「信用データ」それぞれの「ユーザＡ」及び「ユーザＢ」との関係について何ら特定されていないから、構成（ア）及び構成（イ）を反映したものであるということはできない。（請求項１に係る発明は、「対象データ」を所有または利用しているのがどのユーザであるのか、及び、「信用データ」を関連づけるのがどのユーザであるのかが、不明確であるため、例えば、「対象データ」を所有または利用しているのが「ユーザＡ」であり、「信用データ」を関連づけるのが「ユーザＡ」である態様を含むことになるが、そのような態様が、本願の上記課題を解決しないものであることは、明らかである。） 構成（ａ）ないし構成（ｃ）に関して、請求項１には「デジタル署名の検証鍵」、「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化」、「証明書システムの検証鍵」と記載されているが、上述したように、請求項１に係る発明は、構成（Ａ）及び構成（Ｂ）を反映したものではないから、「ユーザＡ（が用いるユーザデバイスＡ）」が「デジタル署名」を生成すること、証明書システムが当該「デジタル署名」を暗号化すること、「ユーザＢ（が用いるユーザデバイスＢ）」が当該「デジタル署名」を検証することが何ら特定されていない。したがって、請求項１に係る発明が、構成（ａ）ないし構成（ｃ）を反映したものであるということはできない。 構成（ｄ）ないし構成（ｆ）に関して、請求項１には「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値」と記載されているが、上述したように、請求項１に係る発明が、構成（Ａ）及び構成（Ｂ）を反映したものではないことに加えて、構成（ｄ）における「復号後の（ユーザデバイスＡの）デジタル署名」から「デジタル署名」が生成されることが何ら特定されていない。したがって、請求項１に係る発明が、構成（ｄ）ないし構成（ｆ）を反映したものであるということはできない。 なお、請求人は、令和６年２月２日付けの意見書において、「なお、「デジタル署名の対象となるデータ」について、・・・（中略）・・・段落［００１８］ではデータ証明書Ａのデジタル署名からデータ証明書Ｂのデジタル署名を生成しているように、データ証明書そのものが含まれ、対象データがデータ証明書Ａである場合をデータ証明書Ｂのユースケースとしています。」と主張しているが、請求項１には「デジタル署名の対象となるデータについて、・・・（中略）・・・信用データ」と記載されていることから、「デジタル署名の対象となるデータ」は明細書に記載の（信用データが関連づけられる）「対象データ」であるとしか解釈することはできず、「データ証明書Ａのデジタル署名」であると解釈することはできない。 構成（ｇ）に関して、請求項１には「データ証明書について一意となる識別子」、「データ証明書間の関連を示すため、データ証明書について一意となる識別子のリスト」と記載されているが、上述したように、請求項１に係る発明は、構成（Ａ）及び構成（Ｂ）を反映したものではないから、「データ証明書について一意となる識別子」及び「データ証明書間の関連を示すため、データ証明書について一意となる識別子のリスト」それぞれが「（ユーザデバイスＡが生成する）データ証明書Ａ」及び「（ユーザデバイスＢが生成する）データ証明書Ｂ」のいずれであるのかが何ら特定されていない。したがって、請求項１に係る発明が、構成（ｇ）を反映したものであるということはできない。 以上のことから、請求項１に係る発明が上記課題解決手段を反映したものであるということはできない。また、請求項１に記載の構成が、本願の上記課題を解決できることが、本願出願時における技術常識とも認められない。 よって、請求項１に係る発明は、当業者が出願時における技術常識に照らし当該発明の課題を解決できると認識できる範囲のものであるとは認められない。 したがって、請求項１に係る発明は、発明の詳細な説明に記載したものではない。 請求項１を直接又は間接的に引用する請求項２ないし７についても同様である。 イ 請求項１に係る発明は「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名」及び「デジタル署名の対象となるデータについて、・・・（中略）・・・信用データ」を有する「データ証明書」の「データ構造」であると認められる。ここで、上記（１）アで述べたとおり、「デジタル署名の対象となるデータ」は明細書に記載の（信用データが関連づけられる）「対象データ」であるとしか解釈することができないところ、「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名」は、上記（１）アで摘記した明細書の【００１６】の記載によれば、「データ証明書Ａ」に含まれるものであるといえ、「デジタル署名の対象となるデータについて、・・・（中略）・・・信用データ」は、【００１８】の記載によれば「データ証明書Ｂ」に含まれるものであるといえる。 しかしながら、摘記した上記記載以外の記載を含め、出願当初の明細書、特許請求の範囲及び図面（以下、「当初明細書等」という。）には、「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名」と「デジタル署名の対象となるデータについて、・・・（中略）・・・信用データ」の両方を含んでいるデータ証明書については、記載も示唆もされていない。また、本願出願時における技術常識から自明ともいえない。 したがって、請求項１に係る発明は、発明の詳細な説明に記載したものではない。 請求項１を直接又は間接的に引用する請求項２ないし７についても同様である。 （２）請求項２、３、６、７について ・・・（中略）・・・ ●理由２（明確性）について ・・・（中略）・・・ （補正の示唆） 請求項１ないし７の記載を例えば以下の補正案のように補正すると、請求項１ないし７についての上記した拒絶の理由は解消する。 なお、上記理由１（１）及び（２）を踏まえて、請求項１に係る「データ構造」の発明については、明細書に記載の「データ証明書Ａ」と「データ証明書Ｂ」のそれぞれを別の請求項とし、請求項２に係る「情報処理装置」の発明については、明細書に記載の「ユーザデバイスＡ」と「ユーザデバイスＢ」のそれぞれを別の請求項とすることを検討されたい。 また、以下の補正案については、元の請求項に含まれていた冗長な記載（「ユーザデバイスの特徴を有する情報処理装置」等）を排除して、簡潔な記載としている。 「 【請求項１】（「データ証明書Ｂ」に対応） 対象データを所有または利用している第１のユーザが用いる第１のユーザデバイス、第２のユーザが用いる第２のユーザデバイス、及び、証明書システムで用いられ、前記第２のユーザデバイスによって生成されるデータ証明書のデータ構造であって、 前記データ構造は、 前記データ証明書について一意となる識別子、 前記第２のユーザについて一意となる識別子、 前記第２のユーザデバイスのデジタル署名の検証鍵、 前記対象データと前記第１のユーザデバイスの署名鍵とから生成された第１のデジタル署名の値と、前記第２のユーザデバイスの署名鍵とから生成された第２のデジタル署名であって、前記証明書システムを経由したことを示すため前記証明書システムの署名鍵で暗号化される第２のデジタル署名、 前記証明書システムの検証鍵 前記対象データの信用に関する情報である信用データであって、前記対象データの価値と権利に関する情報、前記対象データの利用と履歴に関する情報、瑕疵に関する情報、前記対象データに関する認否、賛否、合意形成を表す信用データ、 データ証明書間の関連を示すため、前記対象データと前記第１のユーザデバイスの署名鍵とから生成された第１のデジタル署名であって、前記証明書システムを経由したことを示すため前記証明書システムの署名鍵で暗号化される第１のデジタル署名を含む、前記第１のユーザデバイスが生成したデータ証明書について一意となる識別子のリスト、 を有するデータ構造。 【請求項２】（「データ証明書Ａ」に対応） 対象データを所有または利用している第１のユーザが用いる第１のユーザデバイス、第２のユーザが用いる第２のユーザデバイス、及び、証明書システムで用いられ、前記第１のユーザデバイスによって生成されるデータ証明書のデータ構造であって、 前記データ構造は、 前記データ証明書について一意となる識別子、 前記第１のユーザについて一意となる識別子、 前記第１のユーザデバイスのデジタル署名の検証鍵、 前記対象データと前記第１のユーザデバイスの署名鍵とから生成された第１のデジタル署名であって、前記証明書システムを経由したことを示すため前記証明書システムの署名鍵で暗号化される第１のデジタル署名、 前記証明書システムの検証鍵、 データ証明書間の関連を示すため、前記第２のユーザデバイスが生成した請求項１に記載のデータ構造を有するデータ証明書について一意となる識別子のリスト、 を有するデータ構造。 ・・・（後略）」 第４ 当審の判断 １ 理由１（サポート要件）について 当審拒絶理由で指摘したとおり、本願が解決しようとする課題は、明細書の【０００５】及び【００１０】の記載を参酌すると、「データの信用を形成する」ことであるといえ、明細書の【０００６】、【０００９】、【００１３】、【００１９】及び【００２２】の記載を踏まえると、明細書に記載された課題解決手段は以下の構成（ア）及び（イ）を前提とするものであると認められる。 構成（ア）：（ある特定のユーザである）「ユーザＡ」が所有または利用している「対象データ」に対して、（ユーザＡとは異なる）「ユーザＢ」が「信用データ」を関連づけること。 構成（イ）：「ユーザＢ」が関連づけた「信用データ」を「ユーザＡ」が利用すること。 なお、明細書には、「対象データ」を所有または利用している「ユーザＡ」と、「対象データ」に対して「信用データ」を関連付ける「ユーザＢ」とが同一であることは記載も示唆もされておらず、また、「信用」は他者との間で形成されるものであることが一般常識であることを踏まえると、上記構成（ア）及び（イ）における「ユーザＢ」が「ユーザＡ」とは異なることは明らかである。 そして、明細書の【０００６】、【００１６】ないし【００１８】の記載を参酌すると、本願の課題解決手段は、以下の構成（ａ）ないし（ｃ）の処理によって、「対象データ」を所有または利用しているのが「ユーザＡ」であることを「ユーザＢ」が確認し、以下の構成（ｄ）ないし（ｆ）の処理によって、「信用データ」を関連づけたのが「ユーザＢ」であることを「ユーザＡ」が確認し、構成（ａ）ないし（ｆ）の処理を行うために、以下の構成（ｇ）によって、「データ証明書Ａ」と「データ証明書Ｂ」とを互いに関連付けることであると認められる。 構成（ａ）：「ユーザデバイスＡ」が、「対象データ」と「（ユーザデバイスＡの）署名鍵」から生成した「（ユーザデバイスＡの）デジタル署名」を含む「データ証明書Ａ」を生成する。 構成（ｂ）：「証明書システム」が、「データ証明書Ａ」の「（ユーザデバイスＡの）デジタル署名」を「証明書システムの署名鍵」で暗号化する。 構成（ｃ）：「ユーザデバイスＢ」が、「データ証明書Ａ」の「（ユーザデバイスＡの）デジタル署名」を「証明書システムの検証鍵」で復号し、「データ証明書Ａの（ユーザデバイスＡの）検証鍵」、「復号後の（ユーザデバイスＡの）デジタル署名」、「対象データ」を用いて署名検証アルゴリズムを行う。 構成（ｄ）：「ユーザデバイスＢ」が、「復号後の（ユーザデバイスＡの）デジタル署名」と「（ユーザデバイスＢの）署名鍵」から生成した「（ユーザデバイスＢの）デジタル署名」及び「信用データ」を含む「データ証明書Ｂ」を生成する。 構成（ｅ）：「証明書システム」が、「データ証明書Ｂ」の「（ユーザデバイスＢの）デジタル署名」を「証明書システムの署名鍵」で暗号化する。 構成（ｆ）：「ユーザデバイスＡ」が、「データ証明書Ｂ」の「（ユーザデバイスＢの）デジタル署名」を、「証明書システムの検証鍵」で復号し、「データ証明書Ｂの（ユーザデバイスＢの）検証鍵」、「復号後の（ユーザデバイスＢの）デジタル署名」、「復号後の（ユーザデバイスＡの）デジタル署名」を用いて署名検証アルゴリズムを行う。 構成（ｇ）：データ証明書について一意となる識別子によって、「ユーザデバイスＡ」が生成した「データ証明書Ａ」と、「ユーザデバイスＢ」が生成した「データ証明書Ｂ」とを互いに関連付ける。 ここで、当審拒絶理由で指摘したとおり、本願発明は「デジタル署名の対象となるデータ」（「対象データ」に対応）を所有または利用しているのがどのユーザであるのか、また、「信用データ」を関連付けるのがどのユーザであるのかについて、具体的に特定していない。すなわち、本願発明において、「信用データ」を関連付けるユーザが「デジタル署名の対象となるデータ」を所有または利用しているユーザとは異なる点が、何ら特定されていない。また、本願発明の「信用データ」について、「デジタル署名の対象となるデータ」を所有または利用しているユーザとは異なるユーザが関連づけるものであると限定的に解釈すべき事情もない。 そうすると、本願発明は、「信用データ」を関連付けるユーザと「デジタル署名の対象となるデータ」を所有または利用しているユーザとが同一である態様を含むものであるから、上記構成（ア）及び（イ）を前提とするものであるということはできず、また、当該態様は、ある特定のユーザが、自身が所有または利用している「対象データ」に対して、自身が「信用データ」を関連付けるものであるから、「データの信用を形成する」という本願の上記課題を解決しないものであることは明らかである。 そして、本願発明は、「信用データ」を関連付けるユーザと「デジタル署名の対象となるデータ」を所有または利用しているユーザとが異なる点が何ら特定されていないから、「対象データ」を所有または利用しているのが「ユーザＡ」であることを（ユーザＡとは異なる）「ユーザＢ」が確認するための処理である上記構成（ａ）ないし（ｃ）、「信用データ」を関連づけたのが「ユーザＢ」であることを「ユーザＡ」が確認するための処理である上記構成（ｄ）ないし（ｆ）、並びに、上記構成（ｇ）、すなわち、上記課題解決手段を反映したものであるということはできない。 なお、仮に、本願発明の「信用データ」を関連づけるユーザが、「デジタル署名の対象となるデータ」を所有または利用しているユーザとは異なるユーザが関連づけるものであると限定的に解釈したとしても、本願発明の「データ構造」である「データ証明書」は、上記構成（ａ）ないし（ｃ）における「データ証明書Ａ」であるのか、あるいは、上記構成（ｄ）ないし（ｆ）における「データ証明書Ｂ」であるのかについて、何ら特定されていない。ここで、明細書の【００１６】ないし【００１８】の記載によれば、「データ証明書Ａ」における「デジタル署名」と、「データ証明書Ｂ」における「デジタル署名」は、いずれも「証明書システムの署名鍵」で暗号化され、「証明書システムの検証鍵」で復号されるものであるが、前者は「対象データ」と「（ユーザデバイスＡの）署名鍵」から生成したデジタル署名であり、（「対象データ」を所有または利用している）ユーザＡが署名したことを確認するためのものであるのに対し、後者は「（前者の）デジタル署名」と「（ユーザデバイスＢの）署名鍵」から生成したデジタル署名であり、（「信用データ」を関連付ける）ユーザＢが署名したことを確認するためのものであるから、前者と後者は「デジタル署名」としての役割が異なるものである。（参考として、明細書の【００１６】ないし【００１８】の記載に基づいて、データ証明書Ａとデータ証明書Ｂそれぞれのデータ構造と役割についての参考図を当審で作成した。なお、データ構造中の括弧内は、具体的な値（「デジタル署名の検証鍵」についてはその主体）を示している。） 【参考図】 ［図：0001430692000001.jpg］ しかしながら、本願発明の「デジタル署名」は「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行う」ものとして特定されるのみであるから、本願発明の「データ証明書」は一の「データ構造」であるとしか解釈できず、一の「データ構造」であるとしか解釈できない本願発明の「データ証明書」が、異なる役割の「データ構造」である「データ証明書Ａ」と「データ証明書Ｂ」の両方を含むものでないことは明らかである。したがって、本願発明は、依然として、上記課題解決手段である構成（ａ）ないし（ｇ）を反映したものであるということはできない。 以上のことから、本願発明が上記課題解決手段を反映したものであるということはできない。また、構成（ａ）ないし（ｇ）を含まない本願発明の構成により、本願の上記課題を解決できることが、本願出願時における技術常識から明らかとも認められない。 よって、本願発明は、当業者が出願時における技術常識に照らし当該発明の課題を解決できると認識できる範囲のものであるとは認められない。 したがって、本願発明は、発明の詳細な説明に記載したものではなく、特許法第３６条第６項第１号に規定する要件を満たしていない。 ２ 請求人の主張について 請求人は、令和７年７月４日に提出した意見書において、次のように主張している。（下線は、当審拒絶理由において請求項１について通知した理由１に対する主張、及び、手続違背についての主張を示すため、当審で付与した。） 「本願発明に関する拒絶理由通知書について、審判請求人は意見書を提出する。 ・請求項の記載について 拒絶理由通知書ついて回答する前に、本願発明の請求項を、明細書の段落［課題を解決するための手段］を引用して説明する。 本願発明の請求項は、文言が示す「特徴」を持つ（有する）「データ構造、情報処理装置、情報処理方法、情報処理システム」である。 ・請求項１ データ証明書は、請求項に「公開鍵を用いた証明書のデータ構造であって」と記載し、明細書の段落［０００７］に「データ証明書は、データ証明書Ａに対してデータ証明書Ｂを関連づけて用いる。関連づけた証明書は木構造をとる。」と記載したように、情報技術における「構造化されたデータ」（または、データストラクチャ）のことである。ユーザデバイスおよび証明書システムは、用いる特徴に応じて、「構造化されたデータ」の一部を生成、または取り出して、「データ証明書Ａ」「データ証明書Ｂ」として処理を行い、データを送受信する。 請求項１において、「特許のデータ構造」の要件である「データ要素間の相互関係で表される、データの有する論理的構造をいう。」は、「証明書システムの検証鍵」（証明書システムの非対称鍵）と「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名、」、「デジタル署名の検証鍵」と「デジタル署名」、「データ証明書について一意となる識別子」と「データ証明書について一意となる識別子のリスト」と記載し、名称によって相互関係が明確である。 ・請求項２、３ 請求項の記載と明細書の特徴は、以下の関連付けである。 請求項「デジタル署名の対象となるデータに関する請求項１に記載のデータ証明書を生成する」 明細書「データ証明書Ａ生成」 請求項「データ証明書を証明書システムに登録するため送信する」 明細書「データ証明書Ａ登録要求」「データ証明書Ｂ登録要求」 請求項「データ証明書を用いるため証明書システムから取得する」 明細書「データ証明書取得要求」 請求項「デジタル署名を証明書システムの検証鍵で復号し、デジタル署名と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名の検証鍵を用いて署名検証アルゴリズムで判定し信用データを用いる」 明細書「データ証明書Ｂ検証」 請求項「デジタル署名を証明書システムの検証鍵で復号し、デジタル署名の対象となるデータと、デジタル署名と、デジタル署名の検証鍵を用いて署名検証アルゴリズムで判定する」 明細書「データ証明書Ａ検証」 請求項「データ証明書のデジタル署名と、ユーザデバイスの署名鍵でデジタル署名生成アルゴリズムを行い、データ証明書について一意となる識別子で関連づけたデータ証明書を生成する」 明細書「データ証明書Ｂ生成」 請求項の「ユーザデバイスは、電気通信回線で請求項１に記載の証明書システムと接続し」の記載は、ユーザデバイスと証明書システムの間の電気通信回線（有線ケーブル、無線もしくは空中線、電気回路）において、ユーザデバイスと証明書システムに「付属する装置としての電気通信回線」であり、ユーザデバイスがデータ証明書を送信する際にはユーザデバイスに属する電気通信回線であり、証明書システムがデータ証明書を送信する際には証明書システムに属する電気通信回線である。これは、データ証明書の処理主体が２つある理由でもある。 ・請求項４、５ 請求項の記載と明細書の特徴は、以下の関連付けである。 請求項「ユーザデバイスの要求に応じて、証明書システムを経由したことを示すため、証明書システムの検証鍵を付加し、データ証明書のデジタル署名を証明書システムの署名鍵で暗号化したデータ証明書を記録装置に格納する」 明細書「データ証明書Ａ登録応答」「データ証明書Ｂ登録応答」 請求項「ユーザデバイスの要求に応じて、証明書システムを経由したことを示すため、データ証明書のデジタル署名と、データ証明書のデジタル署名の検証鍵と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名を署名検証アルゴリズムで判定し、データ証明書を記録装置に格納する」 明細書「データ証明書Ｂ登録応答」 請求項「ユーザデバイスの要求に応じてデータ証明書をユーザデバイスに送信する、」 明細書「データ証明書取得応答」 証明書システムが、「データ証明書Ｂ登録応答」を用いる際は、「データ証明書Ａ登録応答」と組み合わせて用いることとしている。すなわち、「データ証明書Ａ登録応答」はデータ証明書を記録装置に格納する場合の特徴、「データ証明書Ｂ登録応答」はデータ証明書のデジタル署名検証を行い記録装置に格納する場合の特徴でもある。 ・請求項６、７ 請求項６、７の前提条件は、ユーザデバイスと証明書システムの公開鍵を事前に共有しているものとしている。明細書の段落［０００９］の各種シーケンスの後に記載したことからも、データ証明書の登録が行われた後などに用いるものである。これには、別の対象データにおいて、同様のシーケンスを行い、公開鍵を共有した場合も含むものである。 ・理由１（サポート要件）について （１）請求項１ないし請求項７について ア ・構成（ア）及び構成（イ）に関して 構成（ア）、構成（イ）について、本願発明の構成要素が「信用データ」しかなく、技術的仕組みとその効果について、十分に説明した文章とはいえない。本願発明は情報技術に関する発明であって、データ証明書とユーザデバイスと証明書システムの技術的仕組みによって、明細書の［発明の効果］に記載した「信用を形成」するものである。 構成（ア）、構成（イ）において、「ユーザＡ」「ユーザＢ」としている箇所は、「ユーザデバイスＡ」「ユーザデバイスＢ」である。本願発明は、データ証明書をユーザデバイスでも扱えるように技術的仕組みを構築するものであって、ユーザとユーザの操作については説明用の記載である。この、ユーザとユーザデバイスの関係性は、背景技術と比較しても、「信用の形成」を行う技術的仕組みと、その効果が生じる箇所について、特段の違いがあるとは言えない。 また、本願発明の技術的仕組みは、「どのようなユーザ」かによって、用途を限定する理由がない。本願発明を用いる際に、本人確認を用いれば、「信用の形成」がより成されるとしているのみである。 ユーザＡとユーザＢが同一の場合もあれば、片方が複数の場合、両方が複数の場合、ユーザに関する処理を自動化している場合も考えられる。業務用の情報処理装置を考えれば、一つのユーザデバイスを複数のユーザが用いることについて、想到が困難とする理由もない。このため、合議体は「そのような態様が、本願の上記課題を解決しないものであることは、明らかである。」ことを指摘するが、発券機や券売機のような情報処理装置を考えればよく、技術常識であることが十分に思料できる。ただし、例示は本願発明の用途を示すものではない。 「信用データ」については、対象データに直接「信用データ」を関連付けるのではなく、対象データに「データ証明書」の関連付けを行うのであり、「データ証明書」を関連付けた結果として、そのフィールドの一つである「信用データ」を用いるというものである。 合議体は、上記論点の他、証明書システムがデータ証明書を中継する際に、経由したことを示すためデジタル署名を暗号化する特徴など、証明書システムが主体の一つであることを見落としている。証明書システムがあることによって、ユーザＡとＢ、ユーザデバイスＡとＢが同一の場合においても、証明書システムがデータ証明書の記録を行い、一定の信用形成を成すものである。なお、証明書システムは、該当箇所の特徴としてデジタル署名アルゴリズムの代わりに暗号化アルゴリズムを用いているが、秘匿を目的とした暗号化ではないため、アルゴリズムとしてはデジタル署名アルゴリズムの一部と同等である。 このように、構成（ア）、構成（イ）は、合議体の解釈によるものであって、本願発明の認識に齟齬があるため、審判請求人は論点として採用しない。 ・「ユーザデバイス」はどのユーザが用いるものであるのか。 ・「ユーザについて一意となる識別子」はどのユーザのものであるのか。 ・「デジタル署名の対象となるデータ」（「対象データ」に対応）を所有または利用しているのははどのユーザであるのか。 ・「信用データ」を含む「データ証明書」を生成する（「信用データ」を関連づける）のはどのユーザであるのか。 「どのユーザ」と、「信用データを関連付けるユーザ」については、前述の通りである。 「ユーザデバイス」については、「（２）請求項２、３、６、７について」にて後述する。 「対象データ」を「所有または利用しているのははどのユーザであるのか」については、本願発明は対象データの所有または利用を、直接は管理していない。本願発明の説明の前提として、ユーザデバイスの記録装置に格納されているものとしている。ユーザデバイスＡとユーザデバイスＢが同一の場合を想定したとしても、記録装置のパーティションや、ファイルのアクセス権限の問題である。一方、本願発明の用い方として、対象データの所有または利用を確認する方法は、証明書システムに登録されたデータ証明書Ａの各種フィールドで判断、もしくはデータ証明書Ｂによるデータ証明書Ａの信用性の評価、などである。 ・構成（ａ）ないし構成（ｃ）に関して 「構成（ア）及び構成（イ）に関して」に記載の通りである。 ・構成（ｄ）ないし構成（ｆ）に関して 「構成（ア）及び構成（イ）に関して」に記載の通りである。また、構成（ｄ）ないし構成（ｆ）の特徴について、「データ証明書Ａのデジタル署名」を用いているが、対象データとしての説明にデジタル署名がないとのことであるが、明細書の段落［００１３］において、「対象データは、ユーザが所有または利用している、デジタル署名の対象となるデータである。識別子、」と記載しており、適切なパラメータを用いていれば、デジタル署名は生成元のデータに対して検証可能な識別子である。また、段落［００１８］において、「デジタル署名は、復号したデータ証明書Ａのデジタル署名の値と、署名鍵を用いて、デジタル署名アルゴリズムで生成し、証明書システムの検証鍵で暗号化する。」と記載し、どのように生成し用いるかも記載している。 上記に関連して、審判請求書の進歩性の説明において、「証明書システムはデータ証明書に含まれる「デジタル署名」を用いるものの、「対象データを扱わない」ため、証明書システムがデータ証明書を中継する際に、デジタル署名を付加する主体となることに阻害要因が生じる。」と記載したが、これは証明書システムが「ユーザデバイスが記録する対象データ」に関する「デジタル署名を付加する主体となること」に阻害要因が生じるという意味であって、証明書システムは「データ証明書」間の関連付けを行うのであるから、経由したことを証明するために「証明書システムが記録するデータ証明書のデジタル署名」を対象データとしてデジタル署名相当の暗号化を行うことは適切である。 ・構成（ｇ）に関して 「構成（ア）及び構成（イ）に関して」に記載の通りである。 請求項１を引用する請求項２ないし請求項７も同様である。 イ 請求項１のデータ証明書について、デジタル署名と信用データの「両方を含んでいるデータ証明書については記載も示唆もされていない。また、本願出願時における技術常識から自明ともいえない。」とのことであるが、明細書の段落［０００６］に「デジタル署名の対象となるデータに関する証明書を、データ証明書とする。データ証明書のフィールドの取扱いが異なるため、ユーザデバイスＡとユーザデバイスＢが用いるデータ証明書を、データ証明書Ａとデータ証明書Ｂとする。」と記載し、「課題を解決するための手段」として記載している。このため、データ証明書Ａとデータ証明書Ｂは、どちらも請求項１の説明をしており、データ証明書という「構造化されたデータ」の一部である。請求項は特徴が揃ったときに成り立つものであり、ユーザデバイスの役割を入れ替えて用いたときにも同様に成り立つ。すなわち、ユーザデバイスＡとして用いた後、別の対象データに対してユーザデバイスＢとして用いた場合である。 他にも、一つのユーザデバイスで、ユーザデバイスＡとＢを同一として、明細書の段落［０００９］のシーケンスを行ってもよい。データ証明書Ｂの一枚目は自己証明書として、証明書システムとの疎通確認を含め、対象データに関するデータ証明書の初期登録として用いる運用方法である。データ証明書Ｂの二枚目以降を、他のユーザデバイスが用いるものとすれば、初期登録の時点で両方を含んでいるデータ証明書である。なお、これは技術常識と本願発明の特徴の範囲内によるデータ証明書の用い方の例示であって、本願発明の用途を限定するものではない。 （２）請求項２、３、６、７について ア 「「データ証明書Ａ検証」と「データ証明書Ｂ検証」の両方の処理を備えるユーザデバイスについて、「摘記した上記記載以外の記載を含め、当初明細書等には、両方の処理を備えるユーザデバイスについては、記載も示唆もされていない。また、本願出願時における技術常識から自明ともいえない。」とのことである。 「ユーザデバイス」についての指摘は、ユーザデバイスＡとユーザデバイスＢが説明用のものであることを、明細書の段落［０００８］に、「請求項では、ユーザデバイスＡとユーザデバイスＢをまとめてユーザデバイスとしている。」と、「課題を解決するための手段」として記載している。このため、ユーザデバイスＡとユーザデバイスＢは、データ証明書と同様にどちらも請求項２および３の説明をしている。 請求項に記載の「ユーザデバイス」と、明細書の「ユーザデバイスＡ」「ユーザデバイスＢ」は、オブジェクト指向の考え方でいえば、ユーザデバイスはクラス、ユーザデバイスＡおよびユーザデバイスＢはインスタンスとすれば、技術常識によらないということもない。このため、「ユーザデバイスＡ」「ユーザデバイスＢ」の役割が入れ替わっても同様に成り立つものである。 このような、ユーザデバイスの考え方が技術常識でないことについても指摘しているが、審査基準には以下の記載がある。 「特許・実用新案 審査基準」 「第１章 発明の詳細な説明の記載要件」 「第１節 実施可能要件（特許法第３６条第４項第１号）」 「２．実施可能要件についての判断に係る基本的な考え方」 「（注）「技術常識」とは、当業者に一般的に知られている技術（周知技術及び慣用技術を含む。）又は経験則から明らかな事項をいう。したがって、技術常識には、当業者に一般的に知られているものである限り、実験、分析、製造の方法、技術上の理論等が含まれる。」 このため、技術上の理論、もしくは当業者の経験則であるオブジェクト指向が含まれるのは明らかである。他にも技術常識でないとしている箇所があるが、「データ証明書」と「ユーザデバイス」の、ＡとＢとして説明しているものが特定できないというものであり、同様の理由により明確である。 上記に関連して、根本的な説明となるが、拒絶理由において、「データ証明書」「ユーザデバイスおよびユーザ」について、それぞれＡとＢとして説明しているものが不明瞭であるとしている。ユーザデバイスＡとＢ、および証明書システムにおいて、それぞれデジタル署名の検証を行い、証明書システムを経由したことの確認は非対称鍵暗号を用いる本願発明において、「どれか特定できない」というのは、不明瞭な指摘である。 仮に、非対称鍵を取り違えたとすれば、デジタル署名を検証しても意図した結果とならないのであるから、それはエラーケースのことである。明細書の段落［００１２］に、「処理結果と記載したものは、正常終了、中止、異常終了を示す値とする。中止と、異常終了を示す値の場合に、中止処理、異常終了処理、例外処理を行ってもよい。」として、エラーケースが発生した場合について記載している。また、複製するなどして同一の秘密鍵が複数ある場合については、意図した運用としているか、または不正な取扱いをしたか、であり、請求項の記載が必要な事柄ではない。 また、審査段階の進歩性の論点に関連して、特許庁がＰＫＩに関する情報処理システムを運用する当事者であることも指摘済みであり、電子証明書を用いる情報処理システムの当業者が、技術常識で理解することができないとして行政処分を行うことに、いかなる妥当性もない。 請求項２を引用する請求項３、６、７も同様である。 以上により、本願発明は特許法第３６条第６項第１号を満たしている。 一方、サポート要件違反の指摘の内容は、審判段階で行うものとはいえない。本願発明の経緯は、審査段階の拒絶理由通知書でサポート要件違反の指摘があった後、論点は解消し、原査定の拒絶理由にサポート要件違反は含まれていない。このため、サポート要件の審査を見送ったということもない。また、原査定以降に補正をしていないので、補正によって生じた新たな指摘ということもない。 合議体の指摘は、審判便覧の「当審の拒絶理由において、出願当初から存在する拒絶理由であって、最初の拒絶理由通知で指摘すべきであったものを含む拒絶理由通知は、原則として（注１）、特§１７の２▲１▼一に規定する最初の拒絶理由通知に相当する。」か、もしくは審査便覧の「６２―０６」によるものと思料するが、審査および審判を行う際に当然に疑問を持ち本願発明の特徴を把握するために必要な技術常識に基づくものであるから、見落として行政処分を行ったのであれば、手続違背である。 ・理由２（明確性）について （１）請求項１ないし請求項７について ア ・（サポート要件と同様の指摘） ・「デジタル署名の検証鍵」がどのユーザデバイスのものであるのか。 ・「データ証明書について一意となる識別子」と、「データ証明書間の関連を示すため、データ証明書について一意となる識別子のリスト」のそれぞれが識別する「データ証明書」を生成するのはどのユーザデバイスであるのか。 以上の論点については、理由１で説明済みである。 サポート要件と同様の指摘に、「「ユーザについて一意となる識別子」はどのユーザのものであるのか」とあるが、論点として、ユニークである。 イ 「請求項１には「データ証明書は、公開鍵を用いた証明書のデータ構造であって、・・ ・データ構造。」と記載されているが、「データ証明書」が「データ構造」であるとはどのような意味であるのか明確とはいえない。」 指摘の文言は、請求項の文言を繰り替えしただけであり、審査基準にそった指摘でないため、指摘の根拠が不明瞭である。 「特許・実用新案 審査基準」 「３．明確性要件についての判断に係る審査の進め方」 「３．１ 拒絶理由通知」 「審査官は、請求項に係る発明が明確でないと判断した場合は、特許請求の範囲の記載が明確性要件を満たしていない旨の拒絶理由通知をする。拒絶理由通知において、例えば、当業者が理解できないと判断した請求項に記載された用語を指摘するとともに、その判断の根拠（例えば、判断の際に特に考慮した発明の詳細な説明の記載箇所、出願時の技術常識の内容等）を示すことなどにより、発明が明確でないと考える理由を具体的に説明する。理由を具体的に説明せず、「請求項に係る発明は明確でない」とだけ記載することは適切ではない。出願人が有効な反論をすることや拒絶理由を回避するための補正の方向を理解することが困難になるからである。」 一方、データ証明書のデータ構造については、情報技術における「構造化されたデータ」であり、かつ、「特許のデータ構造」のことでもある。また、データ構造という文言の使い方が不明瞭であるとすれば、補正案の請求項１の文言も同様であり、補正案は読み取れるのであれば、指摘意図が不明瞭である。 なお、データ構造の説明については、審判請求書の理由５でも行っており、実質的に同一の論点であるなら、拒絶理由が維持できないから拒絶理由通知書があるのであって、論点としては不適格である。 ウ 「請求項１における「・・・非対称鍵で暗号化と復号を行うデジタル署名」という記載から、「暗号化と復号を行う」という動作の主体は「デジタル署名」であると解される。しかしながら、「デジタル署名」は、情報処理装置が演算によって生成する単なるデータであって、処理を行う主体とはなり得ないから、請求項１の上記記載は、技術的に明確な記載であるとはいえない。」 「デジタル署名」の「処理を行う主体」が不明確であるとしているが、請求項１に「ユーザデバイスの特徴を有する情報処理装置と、証明書システムの特徴を有する情報処理システムで用いられ、」と明確に記載している。「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、」とユーザデバイスの特徴によって生成した値であることが明確であり、「証明書システムの非対称鍵で暗号化と復号を行うデジタル署名」は、証明書システムが「証明書システムの非対称鍵で暗号化」した「デジタル署名」であることが明確である。一方、ユーザデバイスが、データ証明書のフィールドに付加された「証明書システムの検証鍵」で復号することによって、証明書システムを経由したデジタル署名およびデータ証明書であることの確認に用いることも明確である。 なお、イの指摘と同様に、審判請求書の理由５に含む論点であれば、不適格である。 請求項１を引用する請求項２ないし請求項７も同様である。 （２）請求項２、３、６、７について ア ・（１）と同様の論点 ・「データ証明書を証明書システムに登録するため送信する」と記載されているが、当該「データ証明書」はどのユーザデバイスが生成したものであるのか。 ・「データ証明書を用いるため証明書システム取得する」と記載されているが、当該「データ証明書」はどのユーザデバイスが生成したものであるのか。 ・「デジタル署名を証明書システムの検証鍵で復号し、デジタル署名と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名の検証鍵を用いて署名検証アルゴリズムで判定し信用データを用いる」と記載されているが、当該「デジタル署名」はどのユーザデバイスが生成したものであり、当該「データ証明書」はどのユーザデバイスが生成したものであるのか ・「デジタル署名を証明書システムの検証鍵で復号し、デジタル署名の対象となるデータと、デジタル署名と、デジタル署名の検証鍵を用いて署名検証アルゴリズムで判定する」と記載されているが、当該「デジタル署名」はどのユーザデバイスが生成したものであるのか。 ・「データ証明書のデジタル署名と、ユーザデバイスの署名鍵でデジタル署名生成アルゴリズムを行い、データ証明書について一意となる識別子で関連づけたデータ証明書を生成する」と記載されているが、当該「データ証明書」はどのユーザデバイスが生成したものであり、当該「ユーザデバイスの署名鍵」はどのユーザデバイスものであるのか。 以上の論点については、理由１で説明済みである。 請求項２を引用する請求項３、６、７も同様である。 （３）請求項４、５、６、７について ア ・（１）と同様の論点 ・「ユーザデバイスの要求」が、どのユーザデバイスからのものであり、具体的にどのような要求であるのか。 どのユーザデバイスかは、理由１で説明済みである。どのような要求かは、「請求項の記載について」に記載した、明細書の名称の箇所で説明済みである。明細書の特徴は、「要求」と「応答」とが名称によっても対応関係にあることが明確である。 ・「ユーザデバイスの要求に応じて、証明書システムを経由したことを示すため、証明書システムの検証鍵を付加し、データ証明書のデジタル署名を証明書システムの署名鍵で暗号化したデータ証明書を記録装置に格納する」と記載されているが、「証明書システムの検証鍵」をどこに付加するのか、当該「データ証明書」はどのユーザデバイスが生成したものであるのか。 どのユーザデバイスが生成したものかについては、理由１で説明済みである。「証明書システムの検証鍵」をどこに付加するのかについては、データ証明書の同名称フィールドに証明書システムが付加するのであり、そのように請求項に記載しており、明細書にも記載している。 ・「ユーザデバイスの要求に応じて、証明書システムを経由したことを示すため、データ証明書のデジタル署名と、データ証明書のデジタル署名の検証鍵と、データ証明書識別子によって関連を示すデータ証明書のデジタル署名を署名検証アルゴリズムで判定し、データ証明書を記録装置に格納する」と記載されているが、当該「データ証明書」及び当該「データ証明書識別子によって関連を示すデータ証明書」のそれぞれがどのユーザデバイスが生成したものであるのか。 ・「ユーザデバイスの要求に応じてデータ証明書をユーザデバイスに送信する」と記載されているが、当該「データ証明書」はどのユーザデバイスが生成したものであり、どのユーザデバイスに送信するのか。 以上の論点については、理由１で説明済みである。 イ 請求項４には「証明書システムを経由したことを示すため、・・・（中略）・・・署名検証アルゴリズムで判定」と記載されているが、「証明書システムを経由したことを示す」ことと、証明書システムにおいてデジタル署名の検証を行うこととの関係が不明である。 「請求項の記載について」に記載の通り、証明書システムの特徴である「データ証明書Ｂ登録応答」は、「データ証明書Ａ登録応答」と組み合わせて用いるものとしている。想定する用い方をした場合に、請求項の説明の文言通りである。 一方、指摘の箇所は、審査請求時の請求項には存在せす、審査段階の拒絶理由通知書の「理由２（実施可能要件）について」「請求項２，３」に関連して補正を行った箇所である。請求項２、３のユーザデバイスと、請求項４、５の証明書システムとがどのように関連するのか明確でないとの指摘を、文言を追加することによって明確にしたものであるから、論点は解消済みである。文言に問題があるのであれば、審査段階における拒絶理由が不備となるものである。 請求項４を引用する請求項５、６、７も同様である。 （４）請求項６、７について ア ・（１）、（２）、（３）と同様の論点 ・「ユーザデバイスは、請求項１に記載のデータ証明書のデジタル署名を証明書システムの公開鍵で暗号化し、信用データはユーザデバイスの公開鍵で暗号化する」と記載されているが、暗号化を行うのはどのユーザデバイスであり、公開鍵はどのユーザデバイスのものであるのか。 ・「証明書システムは、データ証明書のデジタル署名を証明書システムの秘密鍵で復号し、ユーザデバイスの公開鍵でデジタル署名を暗号化する」と記載されているが、当該「データ証明書」はどのユーザデバイスが生成したものであり、公開鍵はどのユーザデバイスのものであるのか。 ・「ユーザデバイスは、データ証明書のデジタル署名と信用データをユーザデバイスの秘密鍵で復号する」と記載されているが、復号するのはどのユーザデバイスであるのか、また、当該「データ証明書」はどのユーザデバイスが生成したものであるのか。 以上の論点については、理由１で説明の通りである。なお、明細書の段落［００２１］は暗号化シーケンスについて説明したものだが、段落に記載の「データ証明書の暗号化シーケンス」とは、段落［００２０］のことである。 説明のために、請求項６にＡとＢを分けたものを記載する。請求項７も同様の説明が成り立つ。データ証明書Ａの信用データとしている箇所は、明細書の段落［０００７］に信用データのフィールドがあることを記載し、段落［００２２］に「合意形成などを表したい場合は、データ証明書Ａに対するデータ証明書Ｂの関連づけを行うかどうかで表してもよい。」と記載したことから、空の文字列で合っても、任意の文字列であってもよい。 ユーザデバイスＡから証明書システムを経由し、ユーザデバイスＢへデータ証明書Ａを送る場合の請求項の説明である。 「ユーザデバイスＡは、請求項１に記載のデータ証明書Ａのデジタル署名を証明書システムの公開鍵で暗号化し、信用データはユーザデバイスＢの公開鍵で暗号化する、 証明書システムは、データ証明書Ａのデジタル署名を証明書システムの秘密鍵で復号し、ユーザデバイスＢの公開鍵でデジタル署名を暗号化する、 ユーザデバイスＢは、データ証明書Ａのデジタル署名と信用データをユーザデバイスＢの秘密鍵で復号する、」 ユーザデバイスＢから証明書システムを経由し、ユーザデバイスＡへデータ証明書Ｂを送る場合の請求項の説明である。 「ユーザデバイスＢは、請求項１に記載のデータ証明書Ｂのデジタル署名を証明書システムの公開鍵で暗号化し、信用データはユーザデバイスＡの公開鍵で暗号化する、 証明書システムは、データ証明書Ｂのデジタル署名を証明書システムの秘密鍵で復号し、ユーザデバイスＡの公開鍵でデジタル署名を暗号化する、 ユーザデバイスＡは、データ証明書Ｂのデジタル署名と信用データをユーザデバイスＡの秘密鍵で復号する、」 これらの説明文は、ＡとＢを取り払うと同一であり、データ証明書のＡとＢのみ取り替える場合や、データ証明書ＡとＢの両方を用いる場合においても、同様である。一方、シーケンスの有する特徴という、一つの請求項に対して一つの発明であることも示している。このように、請求項６、７のシーケンスは、鍵データの更新およびローテーション、データ証明書の更新、対象データの移転などに用いるものである。 請求項６を引用する請求項７も同様である。 以上により、本願発明は特許法第３６条第６項第２号を満たしている。 ・結び 以上により、本願発明には拒絶理由がない。」 上記請求人の主張について検討する。 （１）請求人は、「ユーザデバイスおよび証明書システムは、用いる特徴に応じて、「構造化されたデータ」の一部を生成、または取り出して、「データ証明書Ａ」「データ証明書Ｂ」として処理を行い、データを送受信する。」、「このため、データ証明書Ａとデータ証明書Ｂは、どちらも請求項１の説明をしており、データ証明書という「構造化されたデータ」の一部である。」と主張しており、要するに、本願発明の「データ証明書」は「データ証明書Ａ」と「データ証明書Ｂ」の両方を含むものである旨を主張している。 しかしながら、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願発明の「データ証明書」は一の「データ構造」であるとしか解釈できず、異なる役割の「データ構造」である「データ証明書Ａ」と「データ証明書Ｂ」の両方を含むものではないから、請求人の上記主張は採用しない。 （２）請求人は、「請求項１において、「特許のデータ構造」の要件である「データ要素間の相互関係で表される、データの有する論理的構造をいう。」は、「証明書システムの検証鍵」（証明書システムの非対称鍵）と「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、証明書システムを経由したことを示すため証明書システムの非対称鍵で暗号化と復号を行うデジタル署名、」、「デジタル署名の検証鍵」と「デジタル署名」、「データ証明書について一意となる識別子」と「データ証明書について一意となる識別子のリスト」と記載し、名称によって相互関係が明確である。」と主張している。 しかしながら、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願発明の「データ構造」である「データ証明書」は、「データ証明書Ａ」であるのか、あるいは、「データ証明書Ｂ」であるのかについて、何ら特定されておらず、「データ証明書について一意となる識別子」と「データ証明書について一意となる識別子のリスト」のそれぞれが、「データ証明書Ａ」と「データ証明書Ｂ」のいずれの識別子であるのかが明確でなく、また、「データ証明書について一意となる識別子のリスト」については「データ証明書間の関連を示すため」と特定されているが、「データ証明書間の関連」がどの「データ証明書」とどの「データ証明書」の間の関連であるのかが明確でないから、「データ証明書について一意となる識別子」と「データ証明書について一意となる識別子のリスト」の相互関係が明確であるということはできない。 したがって、請求人の上記主張は採用しない。 （３）請求人は、「構成（ア）、構成（イ）について、本願発明の構成要素が「信用データ」しかなく、技術的仕組みとその効果について、十分に説明した文章とはいえない。」と主張しているが、構成（ア）及び（イ）は、本願の課題解決手段の前提となる構成として示したものであり、本願の課題解決手段については、構成（ａ）ないし構成（ｇ）として示しているから、請求人の「技術的仕組みとその効果について、十分に説明した文章とはいえない。」という主張は採用しない。 （４）請求人は、「構成（ア）、構成（イ）において、「ユーザＡ」「ユーザＢ」としている箇所は、「ユーザデバイスＡ」「ユーザデバイスＢ」である。本願発明は、データ証明書をユーザデバイスでも扱えるように技術的仕組みを構築するものであって、ユーザとユーザの操作については説明用の記載である。この、ユーザとユーザデバイスの関係性は、背景技術と比較しても、「信用の形成」を行う技術的仕組みと、その効果が生じる箇所について、特段の違いがあるとは言えない。」と主張しており、要するに、本願発明は「ユーザ」について特定する必要がない旨を主張している。 しかしながら、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願発明は、「信用データ」を関連付けるユーザが「デジタル署名の対象となるデータ」を所有または利用しているユーザとは異なる点が、何ら特定されておらず、「データの信用を形成する」という本願の課題を解決しないものである。加えて、「信用」は、人（ユーザ）や組織といった主体の間で形成されるものであることが一般常識であること、また、明細書の「対象データは、ユーザが所有または利用している、デジタル署名の対象となるデータである。」（【００１３】）、「データ証明書に信用に関する情報を関連づけるユーザＢ」（【０００６】）という記載を踏まえると、「データの信用を形成する」には、「対象データ」と「信用データ」はそれぞれ「ユーザデバイス」ではなく「ユーザ」に紐付くものである必要があるといえる。以上のことから、本願の課題を解決するための構成として、「デジタル署名の対象となるデータ」を所有または利用しているユーザと「信用データ」を関連付けるユーザのそれぞれについて特定する必要があるといえる。 したがって、出願人の上記主張は採用しない。 （５）請求人は、「また、本願発明の技術的仕組みは、「どのようなユーザ」かによって、用途を限定する理由がない。本願発明を用いる際に、本人確認を用いれば、「信用の形成」がより成されるとしているのみである。」と主張しているが、当審拒絶理由は、「信用データ」を関連付けるユーザが「デジタル署名の対象となるデータ」を所有または利用しているユーザとは異なる点を特定する必要があることを指摘したものであって、「どのようなユーザ」かによって、用途を限定すべきであることを指摘していない。また、「本願発明を用いる際に、本人確認を用いれば、「信用の形成」がより成される」という主張は、請求項の記載に基づくものではない。 したがって、請求人の上記主張は採用しない。 （６）請求人は、「ユーザＡとユーザＢが同一の場合もあれば、片方が複数の場合、両方が複数の場合、ユーザに関する処理を自動化している場合も考えられる。業務用の情報処理装置を考えれば、一つのユーザデバイスを複数のユーザが用いることについて、想到が困難とする理由もない。このため、合議体は「そのような態様が、本願の上記課題を解決しないものであることは、明らかである。」ことを指摘するが、発券機や券売機のような情報処理装置を考えればよく、技術常識であることが十分に思料できる。ただし、例示は本願発明の用途を示すものではない。」と主張している。 しかしながら、「ユーザＡとユーザＢが同一の場合」、「片方が複数の場合」のうち「ユーザＡが複数の場合」及び「両方が複数の場合」、並びに、「一つのユーザデバイスを複数のユーザが用いること」は、明細書に記載も示唆もされていない。なお、「ユーザＡとＢ」が同一の場合については、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願の課題を解決しないものである。 「片方が複数の場合」のうち「ユーザＢが複数の場合」については、明細書の「データ証明書Ａの関連証明書データを用いて、複数のデータ証明書Ｂの信用データの一覧を表示してもよい。」（【００１６】）という記載や、図１の記載から、明細書に示唆されているといえるが、当審拒絶理由で指摘した「そのような態様が、本願の上記課題を解決しないものであることは、明らかである。」という点は、本願発明が「ユーザＡ」と「ユーザＢ」が同一である態様を含む点について指摘したものであるから、「ユーザＢが複数の場合」については、当審拒絶理由における上記指摘と関連するものではない。同様に、不特定多数のユーザが利用する「発券機や券売機のような情報処理装置」についても、当審拒絶理由における上記指摘と関連するものではない。 したがって、請求人の上記主張は採用しない。 （７）請求人は、「「信用データ」については、対象データに直接「信用データ」を関連付けるのではなく、対象データに「データ証明書」の関連付けを行うのであり、「データ証明書」を関連付けた結果として、そのフィールドの一つである「信用データ」を用いるというものである。」と主張しており、要するに、本願発明は「信用データ」の関連付けを「データ証明書」によって行うものである旨を主張しているが、当審拒絶理由において、本願の課題解決手段として、「データ証明書Ａ」及び「データ証明書Ｂ」によって「対象データ」と「信用データ」を関連付けることを示しているから、出願人の上記主張は採用しない。 （８）請求人は、「合議体は、上記論点の他、証明書システムがデータ証明書を中継する際に、経由したことを示すためデジタル署名を暗号化する特徴など、証明書システムが主体の一つであることを見落としている。証明書システムがあることによって、ユーザＡとＢ、ユーザデバイスＡとＢが同一の場合においても、証明書システムがデータ証明書の記録を行い、一定の信用形成を成すものである。」と主張しているが、当審拒絶理由において「証明書システム」が本願の課題解決手段に含まれることを指摘している。また、「ユーザＡとＢ、ユーザデバイスＡとＢが同一」であることは、明細書に記載も示唆もされていない。なお、「ユーザＡとＢ」が同一の場合については、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願の課題を解決しないものである。 したがって、請求人の上記主張は採用しない。 （９）請求人は、「「対象データ」を「所有または利用しているのはは（当審注：原文ママ）どのユーザであるのか」については、本願発明は対象データの所有または利用を、直接は管理していない。本願発明の説明の前提として、ユーザデバイスの記録装置に格納されているものとしている。ユーザデバイスＡとユーザデバイスＢが同一の場合を想定したとしても、記録装置のパーティションや、ファイルのアクセス権限の問題である。一方、本願発明の用い方として、対象データの所有または利用を確認する方法は、証明書システムに登録されたデータ証明書Ａの各種フィールドで判断、もしくはデータ証明書Ｂによるデータ証明書Ａの信用性の評価、などである。」と主張しているが、上記主張は請求項の記載に基づくものではないから採用しない。 （１０）請求人は、「また、構成（ｄ）ないし構成（ｆ）の特徴について、「データ証明書Ａのデジタル署名」を用いているが、対象データとしての説明にデジタル署名がないとのことであるが、明細書の段落［００１３］において、「対象データは、ユーザが所有または利用している、デジタル署名の対象となるデータである。識別子、」と記載しており、適切なパラメータを用いていれば、デジタル署名は生成元のデータに対して検証可能な識別子である。また、段落［００１８］において、「デジタル署名は、復号したデータ証明書Ａのデジタル署名の値と、署名鍵を用いて、デジタル署名アルゴリズムで生成し、証明書システムの検証鍵で暗号化する。」と記載し、どのように生成し用いるかも記載している。」と主張している。 しかしながら、当審拒絶理由で指摘したとおり、本願発明の「デジタル署名の対象となるデータよりデジタル署名生成アルゴリズムで生成した値を、・・・デジタル署名」について、請求項１に「デジタル署名の対象となるデータについて、・・・（中略）・・・を表す信用データ」と記載されていることから、本願発明の「デジタル署名の対象となるデータ」は明細書に記載の（信用データが関連づけられる）「対象データ」、すなわち、明細書に記載の「ユーザＡ」が所有または利用しているデータであって、（ユーザデバイスＡの）署名鍵によってデジタル署名を生成する対象であるデータであるとしか解釈することはできず、「データ証明書Ａのデジタル署名」であると解釈することはできない。そして、上記主張における明細書の【００１３】及び【００１８】の記載については、請求項の記載に基づくものではない。 したがって、請求人の上記主張は採用しない。 （１１）請求人は、「他にも、一つのユーザデバイスで、ユーザデバイスＡとＢを同一として、明細書の段落［０００９］のシーケンスを行ってもよい。データ証明書Ｂの一枚目は自己証明書として、証明書システムとの疎通確認を含め、対象データに関するデータ証明書の初期登録として用いる運用方法である。データ証明書Ｂの二枚目以降を、他のユーザデバイスが用いるものとすれば、初期登録の時点で両方を含んでいるデータ証明書である。なお、これは技術常識と本願発明の特徴の範囲内によるデータ証明書の用い方の例示であって、本願発明の用途を限定するものではない。」と主張しているが、当該事項は明細書に記載も示唆もされておらず、また、本願出願時における技術常識であるともいえないから、請求人の上記主張は採用しない。 （１２）請求人は、「上記に関連して、根本的な説明となるが、拒絶理由において、「データ証明書」「ユーザデバイスおよびユーザ」について、それぞれＡとＢとして説明しているものが不明瞭であるとしている。ユーザデバイスＡとＢ、および証明書システムにおいて、それぞれデジタル署名の検証を行い、証明書システムを経由したことの確認は非対称鍵暗号を用いる本願発明において、「どれか特定できない」というのは、不明瞭な指摘である。」と主張している。 しかしながら、明細書には「データ証明書Ａ」及び「データ証明書Ｂ」、並びに、「ユーザＡ」及び「ユーザＢ」について説明しているものの、上記「１ 理由１（サポート要件）について」で指摘したとおり、本願発明において、「デジタル署名の対象となるデータ」を所有または利用しているのがどのユーザであるのか、また、「信用データ」を関連付けるのがどのユーザであるのかについて何ら特定されておらず、さらに、本願発明の「データ証明書」が「データ証明書Ａ」と「データ証明書Ｂ」のいずれであるのかについて何ら特定されていない。 したがって、請求人の上記主張は採用しない。 （１３）請求人は、「一方、サポート要件違反の指摘の内容は、審判段階で行うものとはいえない。本願発明の経緯は、審査段階の拒絶理由通知書でサポート要件違反の指摘があった後、論点は解消し、原査定の拒絶理由にサポート要件違反は含まれていない。このため、サポート要件の審査を見送ったということもない。また、原査定以降に補正をしていないので、補正によって生じた新たな指摘ということもない。 合議体の指摘は、審判便覧の「当審の拒絶理由において、出願当初から存在する拒絶理由であって、最初の拒絶理由通知で指摘すべきであったものを含む拒絶理由通知は、原則として（注１）、特§１７の２▲１▼一に規定する最初の拒絶理由通知に相当する。」か、もしくは審査便覧の「６２―０６」によるものと思料するが、審査および審判を行う際に当然に疑問を持ち本願発明の特徴を把握するために必要な技術常識に基づくものであるから、見落として行政処分を行ったのであれば、手続違背である。」と主張している。 しかしながら、審判段階において合議体により通知される拒絶理由は、特許法第１５９条第２項において準用する同法第５０条の規定に基づくものであり、当該拒絶理由が原査定の理由に拘束されることについて特許法には規定がなく、またそのような判例もない。よって、本件において、当審拒絶理由として通知したサポート要件違反が原査定の理由に含まれていなかったことにより、当審拒絶理由が手続違背に該当することにはならない。また、原査定がサポート要件違反を見落としていることは、原審（審査段階）における瑕疵に該当するとしても、そのことのみをもって直ちに手続違背とはならない。また、当審において上記瑕疵を改めるべく当審拒絶理由を通知し、請求人に意見書の提出及び補正の機会を与えており、本審決は当審拒絶理由に基づくものであるから、原査定に瑕疵があったとしても、本審決には影響しない。 したがって、請求人の上記主張は採用しない。 上記（１）～（１３）以外にも請求人は縷々主張するが、いずれの主張も、本願の課題解決手段である構成（ａ）ないし構成（ｇ）が具体的に特定されていない本願発明が当審拒絶理由で通知したサポート要件違反とはならない理由として採用することはできない。 第５ むすび 以上のとおり、本願は、特許請求の範囲の請求項１の記載が特許法第３６条第６項第１号に規定する要件を満たしていないから、拒絶すべきものである。 よって、結論のとおり審決する。