ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L |
---|---|
管理番号 | 1302710 |
審判番号 | 不服2012-18491 |
総通号数 | 188 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2015-08-28 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2012-09-21 |
確定日 | 2015-07-01 |
事件の表示 | 特願2009-538471「メッセージデータの非順次到着に対する許容性があるメッセージの完全性のための処理方法」拒絶査定不服審判事件〔平成20年 5月29日国際公開,WO2008/064153,平成22年 4月 2日国内公表、特表2010-510756〕について,次のとおり審決する。 |
結論 | 本件審判の請求は,成り立たない。 |
理由 |
第1.手続の経緯 本願は,2007年11月19日(パリ条約による優先権主張外国庁受理2006年 11月21日,2007年10月22日,2007年11月16日 アメリカ合衆国)を国際出願日とする出願であって, 平成21年5月20日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出されると共に審査請求がなされ,平成23年10月14日付けで審査官により拒絶理由が通知され,これに対して平成24年4月24日付けで意見書が提出されると共に手続補正がなされたが,平成24年5月18日付けで審査官により拒絶査定がなされ,これに対して平成24年9月21日付けで審判請求がなされると共に手続補正がなされ,平成24年12月28日付けで審査官により特許法第164条第3項の規定に基づく報告がなされ,平成25年2月14日付けで当審により特許法第134条第4項の規定に基づく審尋がなされ,平成25年8月19日付けで回答書が提出され,平成26年4月30日付けで当審により拒絶理由が通知され,これに対して平成26年11月6日付けで意見書が提出されると共に手続補正がなされたものである。 第2.本願の特許請求の範囲について 平成26年11月6日付けの手続補正(以下,これを「手続補正」という)によって補正された請求項(以下,これを「補正後の請求項」という)は,以下のとおりである。 「 【請求項1】 送信用アプリケーションパケットを処理するための方法であって, バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって,バイトストリームが複数のブロックを含み,複数のセグメントの各セグメントは,複数のブロックの一部を含む,ステップと, いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと, 複数のスーパーブロックのそれぞれに対するスーバーブロック番号に基づき第1の疑似ランダムビットを複数のスーパーブロックについて生成するステップと, ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップと, ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと, (i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップと, 部分タグを,アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて,累積されたタグを生成するために組み合わせるステップと, 検証タグを累積されたタグおよび第2の疑似ランダムビットに基づいて生成するステップと, 検証タグを記憶するステップと, 複数のセグメントを検証タグを含めて送信するステップとを含む,方法。 【請求項2】 検証タグを生成するステップが,累積されたタグを第2の疑似ランダムビットに対して加えるステップを含む,請求項1に記載の方法。 【請求項3】 複数のセグメントのそれぞれについて部分タグを生成するステップにおいて,部分タグが, 部分タグ=C_(1)(A_(S))^(b)+C_(2)(A_(S))^(b+1)+...+C_(n-b+1)(A_(S))^(n)+C_((S2-S1)n-b+2)(A_(S2))+...+C_((S2-S1)n-b+1+b2)(A_(S2))^(b2) であり,ここでSがスーパーブロック番号,bがスーパーブロック内のブロック番号,nがスーパーブロック内のブロックの数,Cjがセグメント内の暗号化されたブロック,およびA_(S)が第1の疑似ランダムビットである,請求項1に記載の方法。 【請求項4】 複数のセグメントに対して第3の疑似ランダムビットのそれぞれの部分について排他的論理和演算を行って暗号文ブロックを生成することによって,複数のセグメントを暗号化するステップをさらに含む,請求項1に記載の方法。 【請求項5】 複数のセグメントの最終セグメントの再送信のリクエストを受信するステップと, 記憶された検証タグを複数のセグメントの最終セグメントに付加するステップと, 最終セグメントおよび検証タグを再送信するステップとをさらに含む,請求項1に記載の方法。 【請求項6】 最終セグメントを複数のフラグメントに再フラグメント化するステップであって,再送信するステップが複数のフラグメントおよび検証タグを送信する,ステップをさらに含む,請求項5に記載の方法。 【請求項7】 複数のセグメントがブロックサイズの倍数でない場合に, ブロックサイズの倍数であるセグメントを識別するステップと, ブロックサイズの倍数であるセグメントの先頭の前にゼロを付加するステップ,およびブロックサイズの倍数であるセグメントの末尾にゼロを付加するステップの少なくとも1つを実行するステップとをさらに含む,請求項1に記載の方法。 【請求項8】 受信されたアプリケーションパケットセグメントを処理する方法であって, バイトストリーム中のアプリケーションパケットの複数のセグメントを受信するステップであって,バイトストリームが複数のブロックを含み,複数のセグメントの各セグメントは,複数のブロックの一部を含む,ステップと, いくつかの数の複数のブロックをバイトストリーム内でグループ化することにより複数のスーパーブロックをバイトストリーム内で生成するステップと, 複数のスーパーブロックのそれぞれに対するスーバーブロック番号に基づき第1の疑似ランダムビットを複数のスーパーブロックについて生成するステップと, ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップと, ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップと, (i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップと, 部分タグ,受信された複数のセグメント,および受信された検証タグをメモリ中に記憶するステップと, 受信された複数のセグメントをアプリケーションパケットを生成するために組み合わせるステップと, 部分タグを計算されたタグを生成するために組み合わせるステップと, アプリケーションパケットの信頼性を計算されたタグと受信された検証タグとに基づいて検証するステップとを含む,方法。 【請求項9】 複数のセグメントのそれぞれについて部分タグを生成するステップにおいて,部分タグが, 部分タグ=C_(1)(A_(S))^(b)+C_(2)(A_(S))^(b+1)+...+C_(n-b+1)(A_(S))^(n)+C_((S2-S1)n-b+2)(A_(S2))+...+C_((S2-S1)n-b+1+b2)(A_(S2))^(b2) であり,ここでSがスーパーブロック番号,bがスーパーブロック内のブロック番号,nがスーパーブロック内のブロックの数,Cjがセグメント内の暗号化されたブロック,A_(S)が第1の疑似ランダムビットである,請求項8に記載の方法。 【請求項10】 最終部分タグを複数のセグメントの受信された最終セグメントについて生成するステップと, 排他的論理和演算を最終部分タグに対して第2の疑似ランダムビットの最下位ビット(lsb)について行うステップとをさらに含む,請求項8に記載の方法。 【請求項11】 複数のセグメントの最終セグメントの再送信を受信するステップと, 最終部分タグを複数のセグメントの受信された最終セグメントについて生成するステップと, 排他的論理和演算を最終部分タグに対して第2の疑似ランダムビットの最下位ビット(lsb)について行うステップとをさらに含む,請求項8に記載の方法。」 第3.拒絶理由の内容 当審による平成26年4月30日付けの拒絶理由(以下,これを「当審拒絶理由」という)は,概略,以下のとおりである。 「本件出願は,明細書,特許請求の範囲及び図面の記載が下記の点で不備のため,特許法第36条第4項第1号及び第6項第1号,第2号に規定する要件を満たしていない。 記 1.36条6項1号について (1)本願の請求項1,及び,請求項9に, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」, と記載されている。 上記引用の記載に従えば,本願の請求項1,及び,請求項9に記載された発明においては, “部分タグは,第1の疑似ランダムビットと,ブロック番号と,スーパーブロック番号に基づいて生成される” ものであり, “部分タグが,第1の疑似ランダムビットと,ブロック番号と,スーパーブロック番号のみから生成される”, 態様を含むことは明らかである。 ここで,本願発明の課題は,本願明細書の発明の詳細な説明の段落【0002】?段落【0005】に記載されているように, “受信側に順不同に受信されるパケットに含まれるメッセージの完全性の認証の効率改善” である。 即ち,完全性の検証の対象は,“メッセージ”である。 そして,上記引用の本願の請求項1に記載された「部分タグ」は,同じく本願の請求項1に, 「部分タグを,アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて,累積されたタグを生成するために組み合わせるステップと, 検証タグを累積されたタグおよび第2の疑似ランダムビットに基づいて生成するステップ」, と記載されているように,「検証タグ」の生成に用いられ,該「検証タグ」は,本願の請求項9に, 「アプリケーションパケットの信頼性を計算されたタグと受信された検証タグとに基づいて検証する」, と記載されているように,「アプリケーションパケットの信頼性」の検証に用いられてるものであって,ここでいう「アプリケーションパケットの信頼性」とは,上記で指摘した,本願発明の課題を考慮すれば, “「アプリケーションパケット」が改竄されていないこと”, 即ち, “「アプリケーションパケット」内に含まれる「アプリケーション」という“メッセージ”が改竄されていないこと”, を意味するものと解される。 一方,上記引用の「第1の疑似ランダムビット」は,単なる“乱数”であり,「ブロック番号」,「スーパーブロック番号」は,「セグメント」の位置情報を表すものであって,これらの情報は,何れも,完全性を検証されるべき“メッセージの内容”とは,何ら関係の無い情報である。 以上に検討した事項から,本願の請求項1,及び,請求項9に記載された発明は,信頼性の検証対象である「アプリケーションパケット」,即ち,“メッセージ”を,「検証タグ」の生成に用いずに「検証タグ」を生成し,該「検証タグ」を用いて,「アプリケーションパケットの信頼性」の検証を行うという態様を含むものであることは明らかであり,本願の請求項1,及び,請求項9に記載された内容から,むしろ,“メッセージ”を用いずに,「検証タグ」を生成する態様のみ,或いは,該態様が優先するものが表現されていると解される。 そして,本願の請求項1,及び,請求項9に記載された内容は,それ自体,不明確とは言えず,また,「検証タグ」を生成する過程が,当業者に理解不能というものでもないので,本願明細書の発明の詳細な説明を参酌しなければならないというものでもない。 よって,本願の請求項1,及び,請求項9に記載された発明は,本願明細書の発明の詳細な説明に記載されたものではない。 (2)省略 (3)本願の請求項2,及び,本願の請求項4?請求項8は,本願の請求項1を直接・間接に引用し,本願の請求項11,及び,請求項12は,本願の請求項9を引用しているので,上記1.で指摘した構成を内包している。 よって,本願の請求項2,及び,本願の請求項4?請求項8,並びに,本願の請求項11,請求項12に記載された発明は,本願明細書の発明の詳細な説明に記載されたものではない。 ・・・・・(中略)・・・・・ (解説:本願の請求項3,及び,本願の請求項10に記載された発明は,部分タグを求める式の中に,本願明細書の段落【0027】に記載され,【図2】に示されている,「平文ブロックM」を,暗号化した「暗号文ブロックC」を含んでいるので,これが正しく表現されていれば,発明の詳細な説明に記載されたものとなり得る。 しかしながら,本願の請求項1,請求項9に記載された発明は,該請求項を引用する請求項に,「暗号文ブロックC」を含むものがあったとしても,本願の請求項1,及び,請求項9に記載された発明自体は,「暗号文ブロックC」無しで,「部分タグ」が求められるものであるから,発明の詳細な説明に記載されたものでないことは,明らかである。 本願の請求項1,及び,本願の請求項9を引用し,本願の請求項3,及び,請求項10と関連しない,他の請求項も同じく,発明の詳細な説明に記載されたものではない。) 2.36条6項2号について (1)省略 (2)本願の請求項1,本願の請求項9に, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロック及びスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」, と記載されているが,「疑似ランダムビット」と,「ブロック番号」と,「スーパーブロック番号」とに基づいて,どのようにして「部分タグ」を求めているのか,本願の請求項1,及び,請求項9に記載された内容からは,不明である。 ここで,本願の請求項3,及び,請求項10に,「部分タグ」の式が示されているが,上記「1.36条6項1号について」の(2)において指摘したように,本願明細書の発明の詳細な説明の段落【0038】に記載された式と対応しておらず,本願の請求項3,及び,請求項10に記載された内容,及び,発明の詳細な説明に記載された内容を考慮しても,上記指摘の点は不明のままである。 (3)本願の請求項2?請求項8は,本願の請求項1を直接・間接に引用し,本願の請求項10?請求項12は,本願の請求項9を引用するものであるから,上記「2.36条6項2号について」の(1),及び,(2)に指摘した明確でない構成を内包し,かつ,これらの請求項に記載された内容を加味しても,上記(1),及び,(2)において指摘した,明確でない構成が明確になるものではない。(以下,省略) 以上(1)?(3)に検討したとおりであるから,本願の請求項1?請求項12に記載された発明は,明確ではない。 3.36条4項1号について (1)省略 (2)本願の請求項1,及び,請求項9に記載された, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」, に関して,本願明細書の発明の詳細な説明には,上記「1.36条6項1号について」において引用した記載にあるように,「第1の疑似ランダムビット」,「ブロック番号」,及び,「スーパーブロック番号」に基づいて,「セグメント」の「部分タグ」を生成することは記載されていないので,上記引用の本願の請求項1,および,請求項9に記載されたステップを,どのように実現しているか,本願明細書の発明の詳細な説明の記載からは不明である。 (3)省略 (4)省略 (5)省略 (6)本願明細書の発明の詳細な説明の段落【0035】に記載された「完全性タグ」の式は,どのように導出されたか,本願明細書の記載内容からは,不明である。 (本願における特徴的な構成であるから,当業者には,周知でも,自明の事項でもないことは,明らかである。) 以上のとおりであるから,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。」 第4.当審の判断 1.「1.36条6項1号について」の(1)に関して 補正後の請求項1に記載された内容は,上記「第2.本願の特許請求の範囲について」において引用したとおりであり,当該内容は,平成24年4月24日付けの手続補正により補正された請求項(以下,これを「補正前の請求項」という)1の内容と同一である。 また,手続補正によって,補正前の請求項5が削除されているので,補正後の請求項8が,補正前の請求項9であり,その内容は補正前後で同一である。 したがって,手続補正によって,当審拒絶理由の「1.36条6項1号について」の(1)において指摘した事項は解消していない。 即ち,当審拒絶理由において指摘したとおり,補正後の請求項1,及び,請求項8には, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」, と記載され,上記引用の記載に従えば,補正後の請求項1,及び,請求項8に記載された発明においては, “部分タグは,第1の疑似ランダムビットと,ブロック番号と,スーパーブロック番号に基づいて生成される” ものであり, “部分タグが,第1の疑似ランダムビットと,ブロック番号と,スーパーブロック番号のみから生成される”, 態様を含むことは明らかである。 ここで,本願発明の課題は,本願明細書の発明の詳細な説明の段落【0002】?段落【0005】に記載されているように, “受信側に順不同に受信されるパケットに含まれるメッセージの完全性の認証の効率改善” である。 即ち,完全性の検証の対象は,“メッセージ”である。 そして,補正後の請求項1に記載された「部分タグ」は,同じく補正後の請求項1に, 「部分タグを,アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて,累積されたタグを生成するために組み合わせるステップと, 検証タグを累積されたタグおよび第2の疑似ランダムビットに基づいて生成するステップ」, と記載されているように,「検証タグ」の生成に用いられ,該「検証タグ」は,補正後の請求項8に, 「アプリケーションパケットの信頼性を計算されたタグと受信された検証タグとに基づいて検証する」, と記載されているように,「アプリケーションパケットの信頼性」の検証に用いられてるものであって,ここでいう「アプリケーションパケットの信頼性」とは,上記で指摘した,本願発明の課題を考慮すれば, “「アプリケーションパケット」が改竄されていないこと”, 即ち, “「アプリケーションパケット」内に含まれる「アプリケーション」という“メッセージ”が改竄されていないこと”, を意味するものと解される。 そして,本願明細書の発明の詳細な説明,及び,図面においては,「タグ」の生成において,当審拒絶理由において,“解説”として, 「本願の請求項3,及び,本願の請求項10に記載された発明は,部分タグを求める式の中に,本願明細書の段落【0027】に記載され,【図2】に示されている,「平文ブロックM」を,暗号化した「暗号文ブロックC」を含んでいる」, と指摘したとおり,「平文ブロックM」,つまり,“メッセージ”を用いていることは明らかである。 この点について,更に詳細に検討すると,本願明細書の発明の詳細な説明において,「第1の疑似ランダムビット」は,本願明細書の段落【0035】に, 「第1の疑似ランダムビット(OUTPUT)=AES(k,INPUT)」, と記載され,同段落【0026】に, 「AESに対する暗号同期値(INPUT)は,TYPE(例えば8ビット)およびCOUNTER(たとえば64ビット)の2つの部分に分割されてよく」, と記載されていることから,「平文ブロックM」と関連しない,純粋な「疑似ランダムビット」であることが明らかであるが,同段落【0035】に記載された「TAG」を求める式においては,式中に「C_(1)」等が存在し,同段落【0038】に記載された「部分タグ」を求める式においても,式中に「C_(1)」等が存在している。 そして,当該式中の「C_(1)」等は,当審拒絶理由の“解説”において引用した段落【0027】に記載されているとおり, 「平文ブロックM1からM8に対して第1の疑似ランダムビットAESk(0,9001)-AESk(0,9049)との排他的論理和演算を行い(XORが行われ),暗号化された(暗号文)ブロックC1-C8を生成する」ものである。 一方,上記指摘の「TAG」を求める式における,「A_(s)」等,及び,「部分ダグ」を求める式における,「A_(3)」は,同段落【0030】に記載された「第2の疑似ランダムビットAi」に関連するものであり,「第2の疑似ランダムビットAi」は,該同段落【0033】に記載された,「ランダムハッシュキーAi」に関連するものである。 ここで,当審の拒絶理由においても指摘したとおり,補正後の請求項1,及び,請求項8に記載された「第1の疑似ランダムビット」は,その生成に「スーパーブロック番号」をもちいていることから,上記に引用の,同段落【0030】に記載された「第2の疑似ランダムビットAi」,或いは,該同段落【0033】に記載された,「ランダムハッシュキーAi」に対応するものと解される。 そして,当該「Ai」は,同段落,【0033】,及び,段落【0034】に記載された内容から,「スーパーブロック」,及び,「ブロック番号」に関連していることは読み取れる。そして,上記指摘の同段落【0035】に記載された「TAG」を求める式,及び,同段落【0038】に記載された「部分タグ」求める式,並びに,関連する【図4A】に記載された内容から,「TAG」,「部分タグ」の生成には,「スーパーブロック」と,「ブロック番号」に関連する「Ai」を用いていることは読み取れる。 しかしながら,上記において指摘したとおり,本願明細書の発明の詳細な説明においては,「TAG」,及び,「部分タグ」の生成には,「メッセージM」を,「第1の疑似ランダムビット」によって暗号化した,「暗号文ブロックC」が必要不可欠であり,また,上記において指摘したとおり,「TAG」,及び,「部分タグ」の生成に関連している「Ai」は,「第2の疑似ランダムビット」であるから, 以上において検討した事項から,本願明細書の発明の詳細な説明においては,「TAG」,及び,「部分タグ」は,「メッセージM」を,「第1の疑似ランダムビット」によって暗号化した「暗号化ブロックC」と,「第2の疑似ランダムビットAi」とに基づいて生成されるものであって,「スーパーブロック」,及び,「ブロック番号」が関連していることは読み取れるものの,「部分タグ」は,「第1の疑似ランダムビット」(本願明細書における「第2の疑似ランダムビット」)と,「ブロック番号」,「スーパーブロック番号」とに基づいて生成されるものとは言えない。 (当審拒絶理由においても指摘したとおり,「タグ」に,「メッセージ」の情報が含まれていなければ,「メッセージ」の検証はできない。) 一方,補正後の請求項1,及び,請求項8に記載された,「第1の疑似ランダムビット」(本願明細書における「第2の疑似ランダムビット」)は,単なる“乱数”であり,同じく,補正後の請求項1,及び,請求項8に記載された「ブロック番号」,「スーパーブロック番号」は,「セグメント」の位置情報を表すものであって,これらの情報は,何れも,完全性を検証されるべき“メッセージの内容”とは,何ら関係の無い情報である。 以上に検討した事項から,補正後の請求項1,及び,請求項8に記載された発明は,信頼性の検証対象である「アプリケーションパケット」,即ち,“メッセージ”を,「検証タグ」の生成に用いずに「検証タグ」を生成し,該「検証タグ」を用いて,「アプリケーションパケットの信頼性」の検証を行うという態様を含むものであることは明らかであり,補正後の請求項1,及び,請求項8に記載された内容から,むしろ,“メッセージ”を用いずに,「検証タグ」を生成する態様のみ,或いは,該態様が優先するものが表現されていると解される。 そして,補正後の請求項1,及び,請求項8に記載された内容は,それ自体,不明確とは言えず,また,「検証タグ」を生成する過程が,当業者に理解不能というものでもないので,本願明細書の発明の詳細な説明を参酌しなければならないというものでもない。 よって,補正後の請求項1,及び,請求項8に記載された発明は,本願明細書の発明の詳細な説明に記載されたものではない。 なお,審判請求人は,平成26年11月6日付けの意見書(以下,これを「意見書」という)において, 「請求項1に記載の, 「複数のブロック」は,「M1...M8」に対応し, 「スーパーブロック」は,本願の図2の第1スーパーブロック「M1...M4」及び,第2スーパーブロック「M5...M8」に対応し, 「第1の疑似ランダムビット」は,本願の明細書の段落0033に記載の「Ai」であり,iは,スーパーブロック番号であり, 「ブロック番号およびスーパーブロック番号を複数のセグメントのそれぞれの先頭について決定するステップ」及び,「ブロック番号およびスーパーブロック番号をバイトストリーム中の複数のセグメントのそれぞれの末尾について決定するステップ」は,本願の明細書の段落0036に記載されている。 また,請求項1に記載の, 「(i)第1の疑似ランダムビット」は,「Ai」であり, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」は,本願の明細書の段落0038の「部分タグ=C_(1)(A_(3))^(102)+C_(2)(A_(3))^(103)+...+C_(30)(A_(3))^(131)」に記載されている。ここで,「A」の下付き数字「3」は,「i」であり,スーパーブロック番号はSである。また,上付き数字「102」,「103」,...,「131」は,ブロック番号bである。 さらに,請求項1に記載の, 「部分タグを,アプリケーションパケットの最終セグメントに関連付けられた最終部分タグを含めて,累積されたタグを生成するために組み合わせるステップ」は,本願の明細書の段落0035に記載の「TAG」を計算する式及び,本願の明細書の段落0038と0039に記載されている。 さらに,請求項1に記載の, 「検証タグを累積されたタグおよび第2の疑似ランダムビットに基づいて生成するステップ」の「第2の疑似ランダムビット」は,本願の明細書の段落0035の「TAG」に関する式の末尾に記載の「AES(2,LastByteNumber)64ビット」である。 従って,本願の請求項1に記載の発明は,本願の明細書の発明の詳細な説明に記載したものである。」 等の主張を行っているが,上記に検討したとおりであるから,当該意見書における出願人の主張は採用できない。 よって,補正後の請求項1,及び,請求項8(補正前の請求項9)に係る発明は,手続補正,及び,意見書の内容を参酌しても,依然として,本願明細書の発明の詳細な説明に記載されたものではない。 2.「1.36条6項1号について」の(3)に関して 補正後の請求項2,及び,補正後の請求項4?請求項7は,補正後の請求項1を直接・間接に引用し,補正後の請求項10,及び,請求項11は,補正後の請求項8を引用しているので,上記1.において検討した,補正後の請求項1,及び,請求項8に記載の構成を内包している。 よって,補正後の請求項2,及び,本願の請求項4?請求項7,並びに,本願の請求項10,請求項11に記載された発明は,上記1.において指摘した,補正後の請求項1,及び,請求項8に係る発明と同じく,依然として,本願明細書の発明の詳細な説明に記載されたものではない。 3.「2.36条6項2号について」の(2)に関して 補正後の請求項1,及び,請求項8に記載された, 「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」, に関しては,補正後の請求項1,及び,請求項8に記載された内容,及び,他の補正後の請求項に記載された内容を加味しても,「第1の疑似ランダムビット」と,「ブロック番号」と「スーパーブロック番号」とに基づいて,どのようにして「部分タグ」を生成しているか,依然として不明である。 この点について,本願明細書の発明の詳細な説明を参照すると,上記1.においても指摘したように,本願明細書の発明の詳細な説明においては,「部分タグ」は,「メッセージM」を,「第1の疑似ランダムビット」によって暗号化した「暗号化ブロックC」と,「第2の疑似ランダムビットAi」とに基づいて生成されるものであるから,本願明細書の発明の詳細な説明に記載された内容を参酌しても,「第1の疑似ランダムビット」と,「ブロック番号」と「スーパーブロック番号」とに基づいて,どのようにして「部分タグ」を生成しているかは不明である。 審判請求人は,意見書において,「2.36条6項2号について」の(2)に関して, 「(2)不明確と指摘された請求項1に記載の「(i)第1の疑似ランダムビットと,バイトストリーム中の複数のセグメントの各セグメントの決定された先頭と決定された末尾の間に位置するブロックおよびスーパーブロックにそれぞれ関連付けられた(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,バイトストリーム中の複数のセグメントのそれぞれについて部分タグを生成するステップ」については,上述したように,本願の明細書の段落0038の「部分タグ=C_(1)(A_(3))^(102)+C_(2)(A_(3))^(103)+...+C_(30)(A_(3))^(131)」に記載されている。ここで,「A」の下付き数字「3」は,「i」であり,スーパーブロック番号はSである。また,上付き数字「102」,「103」,...,「131」は,ブロック番号bである。 請求項1に記載の上述の内容は,請求項1の現在の記載のままでも,当業者であれば,(i)第1の疑似ランダムビットと,(ii)ブロック番号と(iii)スーパーブロック番号とに基づいて,どのように部分タグを生成するかは,明確であると思料する。 補正前の請求項9(補正後の請求項8)も同様である。」 と主張しているが,上記において指摘したとおり,「部分タグ」は,「メッセージM」を,「第1の疑似ランダムビット」によって暗号化した「暗号化ブロックC」と,「第2の疑似ランダムビットAi」とに基づいて生成されるものであるから,補正後の請求項1,及び,請求項8において,「暗号化ブロックC」に関する記述がない以上,上記において検討したとおり,「第1の疑似ランダムビット」と,「ブロック番号」と「スーパーブロック番号」とに基づいて,どのようにして「部分タグ」を生成しているかは,依然として不明であるから,審判請求人の上記引用の意見書における主張は採用できない。 4.「2.36条6項2号について」の(3)に関して 補正後の請求項2,請求項4?請求項7は,補正後の請求項1を直接・間接に引用し,補正後の請求項10,及び,請求項11は,補正後の請求項8を引用するものであるから,上記において検討した,補正後の請求項1,及び,請求項8における明確でない構成を内包し,かつ,補正後の請求項2,請求項4?請求項7,及び,補正後の請求項10,請求項11に記載された内容を加味しても,上記検討の補正後の請求項1,及び,請求項8における明確でない構成が明確になるものでもない。 以上に検討したとおりであるから,本願の請求項1,請求項2,請求項4?請求項8,請求項10,及び,請求項11に係る発明は,明確ではない。 5.「3.36条4項1号について」の(2)に関して 上記「1.「1.36条6項1号について」の(1)に関して」において指摘したとおり,「部分タグ」は,本願明細書の段落【0038】に記載された式に基づいて計算されるが,この式において重要なのは,「暗号化ブロックC」を用いて「部分タグ」を計算することにあり,本願明細書の発明の詳細な説明には,「暗号化ブロック」の関連しない,「部分タグ」,あるいは,その他の「タグ」を計算する手法は開示されていない。 よって,補正後の請求項1,及び,請求項8に記載された「第1の疑似ランダムビット」(本願明細書における「第2の疑似ランダムビット」),ブロック番号,及び,スーパーブロック番号に基づいて,部分タグを,どのように生成しているか不明である点は,依然として解消していない。 6.「3.36条4項1号について」の(6)に関して 本願明細書段落【0035】に記載の, 「TAG=C_(1)(A_(S))^(b-1)+C_(1)(A_(S))^(b)+...C_(512-b+1)(A_(S))^(512)+C_(512-b+2)(A_(S+1))+C_(512-b+3)(A_(S+1))^(2)+...C_(1024-b+1)(A_(S+1))^(512)+C_((S2-S1)512-b)(A_(S2))+...C_((S2-S1)512-b+b2)(A_(S2))^(b2)+AES(2,LastByteNumber)_(64ビット)」は, その前段に記載された,「アプリケーションパケットが,スーパーブロックS,ブロック番号b中で開始し,スーパーブロックS2,ブロック番号b2中で終了すると仮定する」に基づいて,数値を埋め込んだ式であるから,上記引用のTAGの式では,任意の変数に対するTAGの一般式がどのようなものであるか不明である。 この点に関して,意見書において, 「アプリケーションパケットが,スーパーブロックS,ブロック番号b中で開始し,スーパーブロックS2,ブロック番号b2中で終了すると仮定する。 各スーパーブロックSからS2に対して,本願の補正後の請求項3に記載の式に従って,部分タグが計算される。この式は,本願の明細書の段落0038に例示されている。 完全性タグは,本願の図4Aの「Σ」と記載され,段落0041に「累積器」と記載された,累積器により「部分タグ」を累積し,段落0042に記載のように,本願の図4Bにおいて「Σ」と記載された「累積器」の出力に,「AES(2,LastByteNumber)_(64ビット)」を加えて計算されたものである。 即ち,スーパーブロックSからS2のそれぞれに対する部分タグと「AES(2,LastByteNumber)_(64ビット)」の合計である。 したがって,各スーパーブロックSからS2内のブロック数が512である場合に,スーパーブロックSからS2の全てに対して,本願の明細書の段落0035に記載の式が,完全性タグを計算するために使用されることは明確である。」 と主張しており,確かに,補正後の請求項3,及び,請求項9に「部分タグ」の一般式が記載されているが,補正後の請求項各項,及び,本願明細書の発明の詳細な説明,並びに,図面には,この一般式化された「部分タグ」を求める式と,本願明細書の段落【0035】に記載された,上記引用の「TAG」を求める式とを結びつける説明は存在しておらず,また,同請求項3,及び,請求項9に記載の「部分タグ」の式において用いられているパラメータと,「TAG」の式に用いられている数値等の対応関係も,補正後の請求項各項の記載,及び,本願明細書の発明の詳細な説明,並びに,図面の記載内容からは,明確ではないので,審判請求人の意見書における主張を加味しても,「TAG」が,どのようにして求められているのか,依然として不明確である。 以上に検討したとおりであるから,本願明細書の発明の詳細な説明は,経済産業省令で定めるところにより,その発明の属する技術分野における通常の知識を有する者がその実施をすることができる程度に明確かつ十分に記述したものでない。 第5.むすび したがって,本願は,特許法第36条第4項第1号及び第6項第1号,第2号に規定する要件を満たしていない。 よって,結論のとおり審決する。 |
審理終結日 | 2015-01-30 |
結審通知日 | 2015-02-03 |
審決日 | 2015-02-17 |
出願番号 | 特願2009-538471(P2009-538471) |
審決分類 |
P
1
8・
536-
WZ
(H04L)
P 1 8・ 537- WZ (H04L) |
最終処分 | 不成立 |
前審関与審査官 | 中里 裕正 |
特許庁審判長 |
山崎 達也 |
特許庁審判官 |
小林 大介 石井 茂和 |
発明の名称 | メッセージデータの非順次到着に対する許容性があるメッセージの完全性のための処理方法 |
代理人 | 特許業務法人川口國際特許事務所 |