• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04L
管理番号 1236069
審判番号 不服2008-24343  
総通号数 138 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2011-06-24 
種別 拒絶査定不服の審決 
審判請求日 2008-09-22 
確定日 2011-04-14 
事件の表示 特願2004-247490「電子転送システムの通信方法」拒絶査定不服審判事件〔平成16年11月18日出願公開、特開2004-328802〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、平成8年12月14日に出願した特願平08-353097号(パリ条約による優先権主張1995年12月14日、アメリカ合衆国)の一部を平成16年8月26日に新たな特許出願としたものであって、出願と同日に審査請求がなされ、平成19年10月3日付けで審査官により拒絶理由が通知され、平成20年3月10日付けで意見書が提出されるとともに手続補正がなされたが、同年6月20日付けで拒絶査定がなされ、同年9月22日付けで審判請求がなされるとともに手続補正がなされ、平成21年3月30日付けで前置報告がなされ、平成21年5月19日付けで当審により審尋がなされ、それに対して同年9月18日付けで回答書が提出され、平成22年3月31日付けで当審により拒絶理由が通知され、平成22年10月2日付けで意見書が提出されるとともに手続補正がなされたものである。

2.本願発明について
本願の請求項に係る発明(以下、「本願発明」という)は、明細書及び図面の記載からみて、平成22年10月2日付けの手続補正によって補正された、本願の特許請求の範囲の請求項1乃至請求項9に記載の次のとおりのものである。
「【請求項1】通信システムにおいて安全に通信を行う方法であって、この通信システムはユーザ側の第一の装置とこの装置と通信を行うサーバとを有し、
(a)第一の装置から前記サーバへリクエストを転送して組込まれる使用パラメータを含むセッションを創作し、
(b)サーバによって第一キーと第二キーを暗号化し、
(c)暗号化された第一キーと前記セッションに組込んだ前記使用パラメータとをサーバから使用第一装置へ転送し、
(d)暗号化された第一キーを第一の装置によって受信し、暗号化された第一キーを解読して、前記解読された第一キーを使用して、第一の装置が前記通信システム中で安全に通信を行うことを特徴とする通信システムにおいて安全に通信を行う方法。
【請求項2】第一キーがDESキーである請求項1に記載の方法。
【請求項3】第二キーがDESキーである請求項2に記載の方法。
【請求項4】安全な通信システムがDESより安全レベルが高いことからなる請求項1に記載の方法。
【請求項5】通信システムは更に、第二ユーザ側に第二装置を備え、この第二装置も第一の装置とサーバに接続され、組込まれる第二使用パラメータを含む第二セッションを創作し、第二リクエストを第二装置からサーバへ転送することによりサーバにより第四キーを用いて第三キーを暗号化し、暗号化された第三キーと第二使用パラメータとをサーバから前記第二装置へ転送し、暗号化された第三キーと前記第二使用パラメータとを前記第二装置で受信し、前記第三キーを解読して解読された第三キーを使用して、前記第二装置を通信システムにおいて安全に通信させることを特徴とする請求項1に記載の方法。
【請求項6】第三キーがDESキーである請求項5記載の方法。
【請求項7】第四キーがDESキーである請求項5記載の方法。
【請求項8】安全な通信がDESより高い安全レベルにある請求項5記載の方法。
【請求項9】(a)第一データセットを第一の装置から第二装置へ転送し、前記第一データセットは暗号化された部分と暗号化されていない部分とを含み、前記暗号化された部分は解読された第一キーと、少なくとも前記第一データセットの暗号化されていない部分とを使って暗号化され、
(b)第二装置により前記第一データセットを受信し、前記第一データセットの暗号化された部分と共に第二データセットを前記第二装置からサーバへ転送し、第二データセットは暗号化された部分と暗号化されていない部分とを含み、前記第二データセットの暗号化された部分は第一データセットの暗号化されていない部分の少なくとも一部を含み、第二データセットの前記暗号化された部分は前記解読された第三キーを使用して解読されるとともに第二データセットの前記暗号化されていない部分の少なくとも一部を含み、
(c)サーバによって前記第二装置から前記第二データセットを受信して、第二データセットの暗号化された部分を第三キー及び第二データセットの暗号化されていない部分の一部を使用して解読することにより、第二データセットの暗号化された部分に含まれる前記第一データセットの部分が解読され、第一キーと前記第一データセットの解読された部分とを使用して前記第一データセットの前記暗号化された部分を解読し、これにより、前記ユーザは前記第一キーを使用して前記サーバによって確認されると共に前記第二のユーザは前記第三キーを使用して、前記サーバによって認識されることからなる請求項5記載の方法。」

3.原査定の理由
一方、原査定の拒絶の理由の概要は、次のとおりである。

「 理 由
(1)この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。
(2)この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。
(3) この出願は、発明の詳細な説明の記載が下記の点で、特許法第36条第4項に規定する要件を満たしていない。

記

理由(1)にいて
(ア)?(セ)省略
理由(2)について
(ソ)省略
(タ)本願特許請求の範囲の請求項1には、「(b)前記サーバによって第一のキーと第二のキーを暗号化する;」と記載されているが、これはサーバによって第一のキーと第二のキーとをそれぞれ暗号化することを開示するものであるが、本願明細書の発明の詳細な説明では、第一のキーと第二のキーとをそれぞれ暗号化する態様は記載されていないことから、本願請求項1に係る発明は特許法第36条第6項第1号に規定する要件を満たしていない。
(チ)?(ヌ)省略
理由(3)について
(ネ)省略

4.当審の判断
(あ)拒絶理由の前記(タ)について
特許請求の範囲の請求項1に記載の、
「(b)サーバによって第1のキーと第2のキーとを暗号化し」に関して、
本願明細書の発明の詳細な説明には、
A.「【0564】ステップ909A、912、914、915及び916のテストでステップ905で設定されるエラーフラッグが生じないのであれば、ステップ1507で処理が続けられる。そこで、サーバコンピュータ100がセッションの認識番号(“セッションID”)、セッションの暗号化/復号化キー(“セッションキー”)及びセッションソルトを計算(演算)し、メッセージOS1に反映される顧客ユーザー203に要求されるセッションの限界を有効なものとする。」(下線は当審で附したものである。以下同じ。)

B.「【0566】セッションキーは、56ビットのDESキー(8ビットバイト毎に無視される最も少ない有効ビット)及び64ビットの初期化ベクトルを含む128ビット数である。」

C.「【0570】
ステップ1508で、サーバセッションデータ構造130(図12)が更新される。セッションIDはセッションID領域130Aに蓄積される。セッションキーはセッションキー領域130Bに蓄積される。セッションソルトはセッションソルト領域130CAに蓄積される。セッションの間顧客ユーザ203に入手可能な電子キャッシュの金額は、オープンニング金額領域130Eに蓄積され、領域130Eに蓄積されている値に関連する通貨指定者は領域130Dに蓄積される。最初は、領域130Fはオープンニング金額の値を反映している。電子キャッシュが使われると、領域130Fの値は、オープンニング金額と使用した金額との差を示す。実際にサーバコンピュータ100で許可されるキー寿命が、キー寿命領域130Jに蓄積される。実際にサーバコンピュータ100で許可されるキー使用制限がキー使用制限領域130Iに蓄積される。ラベル値ペア4613Aの値は個人ID領域130Kに蓄積される。セッションが作られる日付はサーバアプリケーションソフトウエア110から得られ、開設日付領域130Gに蓄積される。ラベル値ペア4617Dは記録ノート領域130Mに蓄積される。サーバセッションデータ構造130の残りの領域は下記にCAタイプのメッセージの内容のところで述べる。
【0571】ステップ1509の後、メッセージOS2が組み込まれ、サーバコンピュータ100から顧客コンピュータ200へ転送され、クレジットセッション処理407を完成させる。図71及び72を参照してメッセージOS2について述べる。」

D.「【0576】ラベル値ペア4717は“不透明”ラベルを有する。ラベル値ペア4717の値は、メッセージOS2の不透明部の内容(暗号化されたフォームで)を含む。ここに、図72に示すメッセージOS2の不透明部の内容を述べる。」

E.「【0592】ラベル値ペア4717Pは“セッションキー”ラベルを有する。ラベル値ペア4717Pの値は、領域130Bのセッションキーから得る。」

F.「【0594】図68に示すステップ1509では、サーバソフトウエア100が、図2に示すフロー図に基づいてメッセージOS2を組立てる。サーバメッセージ組立処理1000は、メッセージR2の組立てのところですでに述べた。
【0595】ステップ1509Aでは、メッセージOS2がサーバコンピュータ100から顧客コンピュータ200へ送信(伝送)される。」
と記載されていて、
上記Aで引用した内容から、発明の詳細な説明には、
“サーバにおいてセッションキーを生成する”点が記載されていることが読み取れ、
上記Bに引用した内容から、発明の詳細な説明には、
“セッションキーがDESキー”であることが記載されていることが読み取れ、
上記C?Fに引用した内容から、
“サーバから顧客ユーザ203に送信されるメッセージOS2の不透明部に、サーバのセッションキー領域に蓄積されたセッションキーが組み込まれる”点が読み取れる。
そして、該「不透明部」とは、上記Dに引用した内容から、“暗号化されたフォーム”を有するものであることが読み取れる。
したがって、上記A?Fで引用した内容から、本願明細書の発明の詳細な説明には、
“サーバにおいて、セッションキーが生成され、該セッションキーが、メッセージOS2の暗号化されたフォームである不透明部に組み込まれて、顧客ユーザ203に送信される”点、すなわち、
“サーバにおいて、セッションキーが、何らかの暗号アルゴリズムを用いて暗号化され、ユーザに送信される”点、そして、“該暗号アルゴリズムは、何らかの暗号化キーを必要とする”点までは読み取れる。
しかしながら、本願明細書の発明の詳細な説明に記載された内容においては、上記で指摘したように、1つの「セッションキー」を何らかの暗号アルゴリズムを用いて暗号化する点までは読み取れるが、更にもう一つの「キー」を暗号化する点、
すなわち、特許請求の範囲の請求項1に記載の「(b)サーバによって第1のキーと第2のキーとを暗号化し」ついては、記載されておらず、また、当業者にとって自明の事項でもない。
よって、特許請求の範囲の請求項1に係る発明は、発明の詳細な説明に記載したものではない。

5.小括
したがって、本願は、特許法第36条第6項第1号に規定する要件を満たしていない。

6.平成22年10月2日付け手続補正による請求項1が誤記を含む場合の検討
同手続補正によって、平成20年9月22日付け手続補正により補正された請求項1が、「通信システムにおいて安全に通信を行う方法であって、この通信システムはユーザ側の装置とこの装置と通信を行うサーバとを有し、
(a)ユーザ側装置から前記サーバへリクエストを転送して組込まれる使用パラメータを含むセッションを創作し、
(b)サーバによって第二キーを用いて第一キーを暗号化し、
(c)暗号化された第一キーと前記セッションに組込んだ前記使用パラメータとをサーバから使用装置へ転送し、
(d)暗号化された第一キーと前記使用パラメータとをユーザ側装置によって受信し、暗号化された第一キーを解読して、前記使用パラメータにより前記解読された第一キーを使用して、ユーザ側装置を前記通信システム中で安全に通信させたことを特徴とする通信システムにおいて安全に通信を行う方法。」(以下、「補正前の請求項1」という)から、
上記項目2で引用した請求項1(以下、「補正後の請求項1」という)に補正された。
しかしながら、該補正後の請求項1における、
「(b)サーバによって第1のキーと第2のキーとを暗号化」という記載内容は、本願の出願当初明細書の請求項1、あるいは、平成20年3月10日付けの手続補正によって補正された本願明細書の請求項1に記載の項目(b)の内容と同一のものであって、
補正前の請求項1における
「(b)サーバによって第二キーを用いて第一キーを暗号化し」は、審査官による拒絶理由・拒絶査定での指摘を受けて補正されたものであり、当該記載内容の方が、発明の詳細な説明の内容と対応している点、および、平成22年10月2日付けの手続補正における請求項1の補正において、他の補正箇所には、下線が附されているが、上記指摘の請求項1の項目(b)については、補正箇所であることを示す下線が附されていないことから、当該請求項1の項目(b)に関する、平成22年10月2日付け手続補正における補正は、手違いによる誤記の可能性が存する。
よって、当該請求項1の項目(b)の記載内容が誤記である場合についても検討する。

6-1.当審の拒絶理由
平成22年3月31日付けの当審による拒絶理由の概略は、次のとおりである。
「【理由1】本件出願は、特許請求の範囲の記載が以下の点で、特許法第36条第6項第2号に規定する要件を満たしていない。

(1)請求項1に記載された発明特定事項「(a)ユーザ側装置から前記サーバへリクエストを転送して組込まれる使用パラメータを含むセッションを創作し、」において、
1)「ユーザ側装置から前記サーバへリクエストを転送して組込まれる使用パラメータ」とあるが、「転送して組み込まれる」とは、どの様なことを意味しているのか不明であり、発明が明確ではない。
2)「セッションを創作し、」とは、どの様なことを意味しているのか不明であり、発明が明確ではない。
3)「セッション」は、どの装置が創作しているのか不明であり、発明が明確ではない。
4)省略
(2)請求項1に記載された発明特定事項「(b)サーバによって第二キーを用いて第一キーを暗号化し、」において、
1)「第二キー」は、サーバとユーザ側装置との間で、どの様にして共有されるのか不明であり、発明が明確ではない。
2)「第二キー」は、どの装置で生成されているのか不明であり、発明が明確ではない。
3)省略
4)「第一キー」は、どの装置で生成されているのか不明であり、発明が明確ではない。
(3)省略
(4)請求項1に記載された発明特定事項「(d)暗号化された第一キーと前記使用パラメータとをユーザ側装置によって受信し、暗号化された第一キーを解読して、前記使用パラメータにより前記解読された第一キーを使用して、ユーザ側装置を前記通信システム中で安全に通信させたことを特徴とする」において、
1)「暗号化された第一キーを解読して、」とあるが、ユーザ側装置で暗号化された第一キーを解読するためには、第二キーが必要であると解されるが、ユーザ側装置はどの様にして第二キーを得ているのか不明であり、発明が明確ではない。
2)及び3)省略
4)「第一キー」は、どの装置で生成されているのか不明であり、発明が明確ではない。
(5)及び(6)省略
(7)請求項5に記載された発明特定事項「第二リクエストを第二装置からサーバへ転送することによりサーバにより第四キーを用いて第三キーを暗号化し、」において
1)「第四キー」は、サーバと第二装置との間で、どの様にして共有されるのか不明であり、発明が明確ではない。
2)「第四キー」は、どの装置で生成されているのか不明であり、発明が明確ではない。
3)省略
4)「第三キー」は、どの装置で生成されているのか不明であり、発明が明確ではない。
(8)請求項5に記載された発明特定事項「暗号化された第三キーと前記第二使用パラメータとを前記第二装置で受信し、前記第三キーを解読して前記第二使用パラメータに従って解読された第三キーを使用して、前記第二装置を通信システムにおいて安全に通信させる」において、
1)「前記第三キーを解読して、」とあるが、第二装置で暗号化された第三キーを解読するためには、第四キーが必要であると解されるが、第二装置はどの様にして第四キーを得ているのか不明であり、発明が明確ではない。
2)?4)省略
(9)?(14)省略

【理由2】本件出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

[引用文献]
1.特開平5-304523号公報 (以下、略)」

6-2.当審の判断
(い)【理由1】について
(1)に関して
本願の請求項1に記載の
「(a)第一の装置から前記サーバへリクエストを転送して組込まれる使用パラメータを含むセッションを創作し」、及び
「c)暗号化された第一キーと前記セッションに組込んだ前記使用パラメータとをサーバから使用第一装置へ転送し」
における「セッション」とは、上記引用の(a)及び(c)に記載の内容から、
“仕様パラメータを含んで第一の装置から、リクエストとして転送されるために創作されるもの”
或いは、
“使用パラメータを組み込んで、第一キーと共にサーバから仕様第一装置に転送されるもの”と解することができる。
しかしながら、該「セッション」に関して、本願明細書の発明の詳細な説明においては、
段落【0011】に、
「この方法は、第1のパーティーと関連する第1のセッションを行なう工程を備え、この第1のセッションは、この第1のセッションが使用可能な期間を制限する第1の使用パラメータと、第1のデータセットとを有している。」
と記載され、この記載に従えば、該「セッション」は「工程」であって、「創作」されるものでないことは明らかである。
また、同発明の詳細な説明に、
「【0022】
オープンセッション処理はステップ2で行われる。一般的に、セッションは、顧客ユーザ203がインターネット50を通して販売者から製品を購入することができる、または、販売者ユーザ303がインターネット50を通して顧客ユーザ203に対して製品を提供することができる、機会(またはウィンドウ)である。顧客ユーザ203及び販売者ユーザ303は、各自が独立したセッションを有している。セッションは限られた期間となる。この期間はパラメータによって管理される。これらのパラメータは、好ましくは、顧客ユーザ203及び販売者ユーザ303によってセットされる。あるいは、サーバコンピュータ100もそのようなパラメータをセットできる。」
とも記載されていて、該記載に従えば、「セッション」とは、「機会」或いは「限られた期間」となる。
以上のように、本願の特許請求の範囲及び明細書において、「セッション」の定義が一様でなく、
よって、本願の請求項1に記載の「セッション」及び「セッションを創作し」がどのようなものを表現しようとしたものであるか、本願明細書の発明の詳細な説明に記載の内容を加味しても、依然として不明である。
(2)に関して
本願の請求項1に記載の項目(b)が、
「(b)サーバによって第二キーを用いて第一キーを暗号化」 であるとすると、同請求項1に記載の内容から、
a.“サーバは、第一のキーと第二のキーを有している”
b.“第一キーは、サーバにおいて、第二キーで暗号化されて第一の装置に転送される”
c.“第一の装置は、暗号化された第一キーを解読できる”点が読み取れる。
しかしながら、同請求項1の記載内容からは、
d.“サーバが、どのようにして、第一キー及び第二キーを取得したのか”
e.“第一の装置が、どのようにして、暗号化された第一キーを復号したのか”については何ら言及されていない。
そして、本願の請求項2及び請求項3を参酌すると、「第一キー」及び「第二キー」は、共に、「DESキー」であると記載されている。
「DESキー」は、共通鍵暗号系である「DES」の暗号化・復号鍵であるから、暗号化に用いた鍵と同一の鍵を復号処理側が有さなければならないが、
本願の請求項1に記載の内容からは、「第一の装置」が「サーバ」が「第一キー」を暗号化するのに用いた鍵と同一の「第二キー」をどのように得ているのか何ら記載されていない。
同様に、本願の請求項5において、
「サーバにより第四のキーを用いて第三キーを暗号化し、暗号化された第三キーと前記第二使用パラメータとをサーバから第二装置へ転送し、暗号化された第三キーと前記第二使用パラメータとを前記第二装置で受信し、前記第三キーを解読し」と記載されているが、
f.“サーバがどのようにして、第三キー及び第四キーを取得したのか”
g.“第二装置が、どのようにして、暗号化された第三キーを復号したのか”については、請求項5には何ら言及されていない。
上記a?gで指摘したように、本願の請求項1に記載の内容からは、
“第一の装置は、どのようにして、暗号化された第一キーを復号したのか”
本願の請求項5に記載の内容からは、
“第二装置は、どのようにして、暗号化された第三キーを復号したのか”
不明であり、本願の請求項1及び請求項5に記載の発明は、明確でない。

(う)【理由2】について
以下の検討においては、上記(い)で指摘したように、項目(b)が誤記であったものとして、検討する。

(う)-1.本願発明
本願の請求項1に係る発明は、平成22年10月2日付けの手続補正が誤記である可能性を踏まえて、次のとおりのものであると認める。
「通信システムにおいて安全に通信を行う方法であって、この通信システムはユーザ側の第一の装置とこの装置と通信を行うサーバとを有し、
(a)第一の装置から前記サーバへリクエストを転送して組込まれる使用パラメータを含むセッションを創作し、
(b)サーバによって第二キーを用いて第一キーを暗号化し、
(c)暗号化された第一キーと前記セッションに組込んだ前記使用パラメータとをサーバから使用第一装置へ転送し、
(d)暗号化された第一キーを第一の装置によって受信し、暗号化された第一キーを解読して、前記解読された第一キーを使用して、第一の装置が前記通信システム中で安全に通信を行うことを特徴とする通信システムにおいて安全に通信を行う方法。」

(う)-2.引用刊行物に記載の発明
一方、当審が、平成22年3月31日付けの拒絶理由で引用した、本願の原出願の第一国出願時点で既に公知である、特開平05-304523号(1993年11月16日公開、以下、「引用刊行物」という)には、関連する図面と共に次の事項が記載されている。「【0026】送信端末装置#iは着信端末装置#jと暗号化通信を行う場合、まず鍵配送センタ2を呼び出して、セッション鍵の配送を要請する。
【0027】[鍵配送センタとのセッション鍵配送手順]送信端末装置#iが鍵配送センタ2に呼接続要求する場合、発番号情報要素の表示識別子を表示可:“00”に設定し、内容長“18”とセッション鍵要求コマンド(1バイト)、タイムスタンプｔi (1バイト)、及び相手端末装置番号#j(15バイト)を含むユーザ・ユーザ情報要素を付加して、SETUPメッセージをISDN3のDチャネルを介して鍵配送センタ2に転送する。発信端末装置#iは、ISDNの発信者番号通知サービスの契約条件を予め“呼毎指定”にしておく必要がある。この時に、表示識別子が“表示可”の場合には、もし発番号が正しく設定されていなくとも、網が正しい番号を設定し、着信ユーザに転送する。発信者番号通知サービスと発番号情報要素の規定の詳細は、「日本電信電話(株)、技術参考資料、ISNネットーサービスのインタフェース 第3分冊、電気通信協会、1990年発行」の頁78?頁79を参照されたい。
【0028】このように、鍵配送センタ2は、ISDN3が保証する発番号を確認することによって発信端末装置#iを一意に認証でき、発信端末装置#iを装って呼接続要求をしてくる敵となる端末装置との誤接続を防止することができる。
【0029】鍵配送センタ2がSETUPメッセージを受信すると、センタ制御部21がSETUPメッセージを解析し、セッション鍵要求コマンドを検知すると、発信端末装置番号#i及び着信端末装置番号#jから鍵管理記憶部23の暗号鍵管理テーブル(図5)を検索し、対応する加入者の暗号鍵Ki とKj が登録されているかどうか検査する。暗号鍵が登録されていれば、ランダムデータ発生部25を起動して16バイトのランダムデータMを発生させ、セッション鍵記憶部24にランダムデータMを格納する。
【0030】次に暗号機構22を起動し、暗号鍵Kj と初期値all “0”を与えて、ランダムデータMを暗号化し、暗号文E_(Kj)(M)を作成する。再び、鍵配送センタ2の暗号機構22に暗号鍵Ki と初期値All “0”を与えて発信端末装置#iから送信されたタイムスタンプｔi とランダムデータM及び、先に作成された暗号文E_(Kj)(M)を暗号化し、暗号文E_(Ki)｛ｔi ,M,E_(Kj)(M)｝を作成する。
【0031】次いで、鍵配送センタ2のセンタ制御部21は、DISCメッセージに内容長“35”、セッション鍵配送コマンド(1バイト)及び暗号文:E_(Ki)｛ｔi ,M,E_(Kj)(M)｝(33バイト)を含むユーザ・ユーザ情報要素を付加して、Dチャネルを介して発信端末装置#iに応答する。この間に鍵配送センタ2からALERTメッセージが応答されることは、通常の呼設定手順と同じである。
【0032】発信端末装置#iはDISCメッセージを受信し、端末制御部11において、セッション鍵配送コマンドを検知すると、鍵記憶部13から自端末装置の暗号鍵Ki を読み出し、暗号機構12に暗号鍵Ki と初期値All “0”を与えて、ユーザ・ユーザ情報要素の暗号文E_(Ki)｛ｔi ,M,E_(Kj)(M)｝を復号し、タイムスタンプｔi 及びランダムデータM、暗号文E_(Ki)(M)を得る。
【0033】発信端末装置#iは、復号したタイムスタンプｔi が自分が着信端末装置#jに送ったものでかどうかを照合し、鍵配送センタ2が確かに応答したか否かを検証する。また、復号したランダムデータMの上位8バイトをセッション鍵KS 、下位8バイトを初期値IVとしてセッション鍵記憶部14に記憶する。発信端末装置#iと鍵配送センタ2はRELメッセージとREL COMPメッージを相互にやりとりしてBチャネルを接続することなく、呼接続シーケンスを完了する。」

(i)上記で引用した引用刊行物の段落【0026】には、
「発信端末装置#i」が、「鍵配送センタ2」に対して、「セッション鍵の配送を要請する」点が記載されている。
(ii)同じく段落【0027】には、
「発信端末装置#i」が、「鍵配送センタ2」に対して、「タイムスタンプｔi」を含む「SETUPメッセージ」を送信する点が記載されている。
(iii)同じく段落【0029】には、
「鍵配送センタ2」が、「発信端末装置#i」の「暗号鍵Ki」が登録されている場合に、「16バイトのランダムデータMを発生させ、セッション鍵記憶部24にランダムデータMを格納する」点が記載されている。
(iｖ)同じく段落【0030】?【0031】には、
「鍵配送センタ2」において、「暗号鍵Ki」を用いて、「ランダムデータM」と、「発信端末装置#i」から受信した「タイムスタンプｔi」と、「鍵配送センタ2」で作成される「EKj(M)」とを暗号化し、暗号文「EKi｛ｔi,M,Ekj(m)｝」を作成し、該作成した情報を、「鍵配送センタ2」から「発信端末装置#i」に送信する点が記載されている。
(ｖ)同じく段落【0032】?【0033】には、
「鍵配送センタ2」から送信されてきた「暗号文「EKi｛ｔi,M,Ekj(m)｝」を、「発信端末装置#i」において復号し、該復号した「タイムスタンプｔi」が、自らが送信したものと一致するか検証し、復号した「ランダムデータM」 の上位8ビットをセッション鍵Kｓ、下位8ビットを初期値IVとする点が記載されている。
以上(i)?(ｖ)指摘した事項と、引用刊行物に記載されているものが、「秘話通信システム」であることから、引用刊行物には、次の発明(以下、「引用発明」という)が記載されているものと認める。

発信端末装置と鍵配送センタとを有する秘話通信システムにおいて
発信端末装置において、鍵配送センタへのタイムスタンプｔiを含むSETPUPメッセージを作成して、送信し、
鍵配送センタにおいて、受信したSETUPメッセージに基づいて、セッション鍵Kｓを含むランダムデータMを生成し、該ランダムデータMと、発信端末装置から受信したタイムスタンプｔiとを、暗号鍵Kiを用いて暗号化し、暗号化されたデータを、発信端末装置に送信し、
前記暗号化されたデータを発信端末装置にて受信し、暗号化されたデータを復号し、復号して得られたランダムデータMから、セッション鍵Kｓを生成する方法

(う)-3.本願発明と引用発明との対比
引用発明における、「発信端末装置」が、本願発明における「第一の装置」に相当し、
引用発明における、「鍵配送センタ」も、本願発明における「サーバ」も、“暗号鍵”を暗号化して、「発信端末装置」或いは「第一の装置」に送信する「暗号鍵暗号化送信手段」である点で共通し、
引用発明における、「タイムスタンプｔi」も、リクエストに組み込まれて送信されていることは明らかであるから、本願発明における、「使用パラメータ」に相当し、
引用発明における、「SETUPメッセージ」も、本願発明における、「セッション」も、「第一の装置」から「サーバ」に送信される「データ」を含み、「第一の装置」から「サーバ」への“リクエスト”である点で一致し、
引用発明における、「セッション鍵Kｓ」と「暗号鍵Ki」が、本願発明における、「第一キー」と「第二キー」に相当し、
引用発明の「秘話通信システム」を用いた通信方法も、安全に通信を行うためのものであり、引用発明においても、「セッション鍵Kｓ」が、「秘話通信システム」内で、安全に通信を行うために用いられることは明らかであり、
引用発明における「復号」が、本願発明における「解読」と同一の意味であることは、暗号の技術分野においては、自明の事項であるから、
本願発明と、引用発明との一致点及び相違点は、次のとおりである。

(一致点)
通信システムのおいて安全に通信を行うための方法であって、この通信システムはユーザ側の第一の装置とこの装置と通信を行う暗号鍵暗号化送信手段とを有し、
(1)第一の装置からサーバへ、第一の装置からサーバへ送信されるデータを含むリクエストを送信し、
(2)サーバにおいて第一キーを第二キーで暗号化し、
(3)暗号化された第一キーと前記データとをサーバから第一の装置に送信し、
(4)暗号化された第一キーを第一の装置で受信し、前記第一キーを解読して、解読した第一のキーを使用して、第一の装置が前記通信システム中で安全に通信を行うことを特徴とする方法

(相違点1)暗号鍵暗号化送信手段が、
本願発明においては、サーバであるのに対して、
引用発明においては、鍵配送センタである点、

(相違点2)
本願発明においては、「使用パラメータを含むセッションを創作」しているのに対して、 引用発明においては、「セッション」に関しては特に言及されていない点、

(相違点3)
本願発明においては、「使用パラメータ」が、「暗号化された第一キー」と共に「使用第一装置へ転送」されるのに対して、
引用発明においては、「タイムスタンプｔi」が、「ランダムデータM」とともに、「暗号鍵Ki」で暗号化されて、「発信端末装置」に返送される点、

(う)-4.当審の判断
(相違点1)について
サーバで暗号化に用いるキーを管理したり、暗号化してクライアントに送信することは、例えば、本願の原出願の第一国出願時点で既に公知である特開平07-066803号公報(1995年3月10日公開、以下、「周知文献1」という)等にも記載されているように、当業者にとっては周知の技術事項であり(例えば、周知文献1の【要約】等参照、以下、これを「周知技術1」という)、引用発明において、「鍵管理センタ」の機能を「サーバ」に持たせることは、当業者が適宜なし得る事項である。
よって、相違点1は、格別のものでない。

(相違点2)について
上記項目6-2.(い)(1)で指摘したように、「セッション」及び「セッションを創作」がどのようなものか明確でないものの、
本願発明における「セッション」の意味として、本願明細書の発明の詳細な説明に記載されたものが正しいとすれば、当該発明の詳細な説明に記載されたような「セッション」は、一般的なネットワークを介したコンピュータ間の“セッション確立要求メッセージ”に相当するものと解されるが、引用発明においても、一般的なネットワークを介した場合に、同様のメッセージを用いて「セッション」を作成することは、当業者が適宜なし得る事項である。
また、該「セッション」が、上記項目6-2.(い)(1)で指摘したように、同請求項1に記載の内容から解釈される構成であったとしても、
その場合、本願発明における「セッション」とは、「第一の装置」から「サーバ」に「転送」される「リクエスト」あるいは、「サーバ」から「使用第一装置」に送信される“データ”と同義であるから、引用発明の構成と格別の相違はない。
よって、相違点2は、格別のものでない。

(相違点3)について
ネットワークで接続されたノード間でメッセージを送信する際に、暗号化されたメッセージに暗号化されていない情報を付加して送信することも、例えば、本願の原出願の第一国出願時点で既に公知である特開平07-250059号公報(1995年9月26日公開、以下、「周知文献2」という)等にも記載されているように、当業者にとっては周知の技術事項である(例えば、周知文献3の請求項1等参照、以下、これを「周知技術2」という)。
したがって、引用発明において、「タイムスタンプｔi」が、返送時に暗号化の必要がないのであれば、該「タイムスタンプｔi」を、暗号化せずに「発信端末装置」側に返送するよう構成することは、当業者が適宜なし得る事項である。
よって、相違点3は、格別のものでない。

上記で検討したごとく、相違点1?3はいずれも格別のものではなく、そして、本願発明の構成によってもたらされる効果も、当業者であれば容易に予測できる程度のものであって、格別なものとは認められない。

よって、本願発明は、引用発明及び周知技術1並びに2により、当業者が容易になし得たものである。

ここで、上記の検討は、平成22年10月2日付けの手続補正によって補正された請求項1に記載の項目(b)が誤記であったことを前提としているが、
該項目(b)が誤記ではない。すなわち、
「(b)サーバによって第1のキーと第2のキーとを暗号化し、」
であったとしても、鍵配送センタ側で2つのキーを暗号化することは、例えば、本願の原出願の第一国出願時点で既に公知である特開平06-318939号公報(1994年11月15日公開、以下、「周知文献3」という)等にも記載されているように、当業者にとっては周知の技術事項であるから、
引用発明の「鍵配送センタ」において、暗号化の必要な2つの鍵を暗号化するよう構成することは、当業者が適宜なし得た事項である。
よって、項目(b)が誤記でないとしても、
本願発明は、引用発明及び周知文献1?3に記載の周知技術から、当業者が容易になし得たものである。

6-3.項目6のまとめ
したがって、平成22年10月2日付けの手続補正により補正された請求項1の項目(b)が誤記を含むとしても、
本願は、当審の拒絶理由で指摘したとおり、特許法第36条第6項第2号に規定する要件を満たしていない。
また、たとえ、同手続補正が、上記要件を満たしていたとしても、
本願発明は、引用刊行物に記載の発明に基づいて当業者が容易に発明がてきたものであるので、特許法第29条第2項の規定により特許受けることができない。

7.まとめ
以上のとおりであるから、本願は、上記項目3?5で検討したように、原査定の拒絶理由で指摘したとおり、特許法第36条第6項第1号に規定する要件を満たしていない。
また、上記項目6で検討したように、たとえ、平成22年10月2日付けの手続補正によって補正された請求項1に誤記が存在し、該誤記を訂正したとしても、
本願は、当審の拒絶理由で指摘したとおり、特許法第36条第6項第2号に規定する要件を満たしていない。
また、仮に、誤記を正しく訂正し、本願の請求項に記載の内容が明確であるとしても、
本願発明は、当審の拒絶理由で指摘したとおり、引用刊行物に記載の発明に基づいて当業者が容易に発明ができたものであるので、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2010-11-08 
結審通知日 2010-11-10 
審決日 2010-12-01 
出願番号 特願2004-247490(P2004-247490)
審決分類 P 1 8・ 121- WZ (H04L)
P 1 8・ 536- WZ (H04L)
P 1 8・ 537- WZ (H04L)
最終処分 不成立  
前審関与審査官 青木 重徳  
特許庁審判長 吉岡 浩
特許庁審判官 宮司 卓佳
石井 茂和
発明の名称 電子転送システムの通信方法  
代理人 浜田 治雄  
代理人 浜田 治雄  

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