ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04L |
---|---|
管理番号 | 1081140 |
審判番号 | 不服2002-16583 |
総通号数 | 45 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2002-02-08 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2002-08-29 |
確定日 | 2003-08-06 |
事件の表示 | 特願2001-124981「ソフトウェア管理モジュール」拒絶査定に対する審判事件[平成14年 2月 8日出願公開、特開2002- 44070]について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
1.手続の経緯、本願発明 本願は、平成6年9月20日に出願した特願平6-225228号の一部を平成13年4月23日に新たな特許出願としたものであって、その請求項1に係る発明は、平成14年9月27日付け手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項1に記載された次のとおりのものである。 「 通信又は媒体を介して所定のソフトウエア(データおよび/またはプログラム)と、前記ソフトウエアの完全性をチェックするコードであるチェックサムを得て、前記ソフトウエアの処理を行うソフトウエア管理モジュールであって、 前記ソフトウエアから比較用チェックサムを生成するチェックサム生成手段と、 前記ソフトウエアとともに受け取った前記チェックサムと、前記チェックサム生成手段により生成された比較用チェックサムとを比較する比較手段と、 前記ソフトウェア管理モジュールの一端に設けられ、前記比較手段による比較結果および前記チェックサム生成手段が通信又は媒体を介して入力されたソフトウエア(データおよび/またはプログラム)を処理中であることを示す表示手段と、を備え、 前記表示手段は、前記チェックサム生成手段が処理中である事、前記比較手段による比較結果が異常である事、前記比較手段による比較結果が正常終了した事の3種の状態を知らせる表示を行う表示ランプで構成されることを特徴とするソフトウェア管理モジュール。」 2.引用例 これに対し、原査定の拒絶の理由に引用された「関一則 外3名著、暗号を利用した新しいソフトウエア流通形態の提案、情報処理研究会研究報告、1993年7月20日、Vol.93,No64,p.19-28」(以下、引用例1という。)には、以下の記載がある。 (1)「2.2.3 認証アーキテクチャ 認証アーキテクチャは、暗号アーキテクチャと密接な関わりをもち、公開鍵暗号法とそのサポートとしてハッシュ関数を利用する。ここでは、ソフトウエアの著作権者を特定しソフトウエアの不正な改変を検出するためのメッセージ認証・・・(略)・・・ メッセージ認証を行うためには、ソフトウエアのデータ構造は図1のように通常のソフトウエアのヘッダ部分にメッセージ認証子を付加する。認証子は、図1のように、暗号化されたソフトウエアをハッシュ関数にかけて得られたハッシュ・データをソフトウエア著作権者の秘密鍵で暗号化した値・・・(略)・・・によって構成する。」(21頁右欄8行〜23行) (2)「2.4 ユーザ管理プロセス (略) ソフトウエア認証 ソフトウエアの認証とは、通信中にソフトウエアが事故・過失・故意によって改変されていないかを検証することで、ソフトウエア登録プロセスとソフトウエア・サーバの通信におけるソフトウエア認証と同様の認証を行なう。」(24頁左欄22行〜36行) (3)「3 実装 試作システムでは、研究所内の数台のUNIXワークステーションを結ぶイーサネットによるローカル・エリア・ネットワークを用い、ここにソフトウエア・サーバとなるマシンを設置し、それぞれのユーザーがこのサーバから、あるいは他のユーザーから得たソフトウエアを実行するという環境を支援している。」(24頁右欄1行〜7行) (4)「故意・事故・過失などのよって改変されたソフトウエアの流通 このシステムでは、故意・事故・過失などによって改変されたソフトウエアの流通を防ぐ手段として、認証子照合法による認証を行なっている。この認証の安全性は暗号処理ではなく認証子を作成するためのハッシュ関数に依存する。ここで使用されるハッシュ関数は一対一写像ではなく、写像によって得られる値域が縮小しているために逆関数が存在しないので、適当なハッシュ関数を選択することによって高い安全性を保つことができる。」(26頁右欄13行から22行) 以上の記載から、引用例1には、以下の発明が記載されている。 ネットワークを介して所定のソフトウエアと、前記ソフトウエアが事故・過失・故意によって改変されているかを検証するためのハッシュデータから導かれる認証子を得て、前記ソフトウエアを実行する装置であって、 前記ソフトウエアをハッシュ関数にかけて得られたハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した認証子を前記ソフトウエアのヘッダ部分に付加するようにした認証アーキテクチャによって、通信中の前記ソフトウエアの改変を認証子照合法により検出(メッセージ認証)する装置 また、原査定の拒絶の理由に引用された「岡本栄司著、暗号理論入門、共立出版株式会社、1993年2月25日発行、p.129-131,134-135」(以下、引用例2という。)には、以下の事項が図面とともに記載されている。 (5)「7.1 メッセージ認証 メッセージ認証(message authentication)とは、メッセージの正当性を確認する技術であり、認証子法と冗長暗号化法が実用化されている。 7.1.1 認証子法 証明者は認証子(MAC:message authentication code)と呼ばれるコードを作成してメッセージとともに送る。それを受けて検証者は、メッセージから同様に認証子を作成して、それが送られた認証子と一致するか否かで、メッセージの正当性(改ざんの有無)を判定する。図7.1は認証子法を示している。 認証子を作成するには、秘密鍵をパラメータとするハッシュ(hash)関数を使用する。すなわち、秘密の鍵(認証鍵)Kを送信側と受信側で共有し、それを用いて認証子を作成するが、鍵Kを知らなければメッセージMと認証子hK(M)から、異なるM’と対応するhK(M’)を作れないような関数hKである。ハッシュ関数については、7.4節で詳述するが、長いデータをある一定長のビットパターンに変換する関数である。」(129頁13行から130頁6行) (6)「7.3 デイジタル署名 ディジタル署名(digital signature)は、通常のサインと同じく、メッセージや情報の作成者が確かにそれらを作成したことを示すものである。非対称暗号と同時に生まれた概念であり、実際にも非対称暗号を用いることが多いが、対称暗号でも信頼できる機関であれば可能である。(略) 7.3.2 非対称暗号による署名法 (略) 図7.6 RSA署名法(b)ハッシュに署名 」(133頁17行〜135頁) ここで、図7.6には、送り手側で平文Mをハッシュ化し、ハッシュ値を秘密鍵で暗号化し平文Mとともに送り、受け手側では受け取ったハッシュ値を公開鍵で復号化し、平文Mから生成したハッシュ値と照合することによるデジタル署名技術が図示されていると認められる。 また、原査定の拒絶の理由に引用された特公昭61-26111号公報(以下、引用例3という。)には、以下の事項が図面とともに記載されている。 (7)「該処理回路15の出力端に接続された1つの入力端と、入出装置12に接続された他の入力端を有する比較回路16と、上記比較回路16の出力に接続された入力を有する2つの安定した状態をとる例えば点灯回路のような証明(表示出力)回路17とを有する。」(公報5頁9欄39行〜44行) (8)「次いで、処理回路15は受信装置から供給されたメッセージの署名SGを自動的に再計算する。・・・(略)・・・ 第3相において、処理回路15により再算出された署名SGは比較装置16の入力端に供給される。比較回路16の他の入力端は、入力端子24を介して、入出力装置12を介して受信装置から供給される署名SGを受取る。比較装置16はこれら2つの署名を比較して出力端子26を介して証明要素しくは表示装置17を付勢するための信号を発生する。」(公報7頁13欄9行〜26行) 3.対比 本願の請求項1にかかる発明(以下、前者という)と、引用例1に記載された発明(以下、後者という。)とを比較する。 後者の「ネットワーク」「所定のソフトウエア」「前記ソフトウエアが事故・過失・故意によって改変されているかを検証する」は、前者の「通信」「所定のソフトウエア(データおよび/またはプログラム)」「前記ソフトウエアの完全性をチェックする」に相当する。 また、前者では「ソフトウエア管理モジュール」とされているが、モジュールというものは構造/形状を規定するものではなく、ある情報処理を実現する機能実現手段の集まりにすぎないから、後者におけるメッセージ認証の処理が実行される「装置」に相当するものである。 また、後者では、「認証子を前記ソフトウエアのヘッダ部分に付加するようにした認証アーキテクチャによって、通信中の前記ソフトウエアの改変を認証子照合法により検出(メッセージ認証)する」とされており、検証の具体的手法については明示されていないが、当該分野の技術常識を示す上記(5)の記載を参酌すれば、認証子照合法というのは、送り手は認証子(ハッシュデータ)を作成してメッセージとともに送り、受け手側ではメッセージから同様の認証子(ハッシュデータ)を作成してそれが送られてきた認証子(ハッシュデータ)と一致するか否かで改ざんの有無を判定する手法であるから、後者においてもソフトウエアから比較用コードを生成するコード作成手段とソフトウエアとともに受け取ったコードと比較用コードを比較する比較手段を有していると解される。 してみると、両者は次の点で一致する。 通信を介して所定のソフトウエア(データおよび/またはプログラム)と、前記ソフトウエアの完全性をチェックするコードを得て、前記ソフトウエアの処理を行うソフトウエア管理モジュールであって、 ソフトウエアから比較用コードを生成するコード生成手段と、 ソフトウエアとともに受け取った前記コードと、前記コード生成手段により生成された比較用コードとを比較する比較手段と を有するソフトウェア管理モジュール 一方、両者は、次の点で相違する。 (相違点1) 前者では、ソフトウエアとともに受け取られるコードがチェックサムであるのに対し、後者では、ソフトウエアとともに受け取られるコードは、ソフトウエアをハッシュ関数にかけて得られたハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した認証子である点、 (相違点2) 前者が、ソフトウエア管理モジュールの一端に、チェックサム生成手段が処理中である事、比較手段による比較結果が異常である事、比較手段による比較結果が正常終了した事の3種の状態を知らせる表示を行う表示ランプで構成される表示手段が設けられているのに対し、後者のものでは比較手段の比較結果の使用形態が明示されていない点、 4.当審の判断 上記相違点について検討する。 (相違点1について) 情報が伝送途中で改変/改ざんされていないことを検出するために、両者はメッセージの情報を凝縮してメッセージとともに送り、受け手側でチェックする手法によっており、このメッセージを凝縮するために用いられる関数は一般にメッセージ要約関数と呼ばれている。そして、ハッシュやチェックサムは広義の意味でメッセージ要約関数と呼ばれている。後者は、メッセージ要約関数としてハッシュデータによってソフトウエアの完全性をチェックするものであるが、前述の通りハッシュもチェックサムも広義の意味でメッセージ要約関数であるから、メッセージ要約関数としてチェックサムを用いることは当業者が容易に想到し得ることである。 なお、後者では、ハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した値を認証子としているが、これは上記(6)を参照すれば、チェックサムに対して署名を行う、いわゆるデジタル署名を行っているからであり、改ざんの検証はあくまで上記(5)の図7.1に示されるように、ハッシュデータ同士を照合する認証子照合法によっているものである。従って、デジタル署名を行わず、そのための構成、つまり、ハッシュデータをソフトウエア著作権者の秘密鍵で暗号化すること、を後者からはずすようにすることは単なる設計事項にすぎないものである。 従って、相違点1を格別の相違ということはできない。 (相違点2について) 後者のものにおいてはソフトウエアの完全性をチェックする手法までしか開示されていないが、チェック結果を次に何らかの処理に用いることは当然である。引用例3に示されるようなメッセージの署名を認証する装置では、上記(7)(8)に示されるように点灯回路のような表示出力回路で認証結果を報知している。また、その表示の形態として、装置の一面に配置された表示ランプを用いることや処理の結果だけでなく処理結果を得るまでの処理中表示を行い、利用者に知らせることは、例えば、特開平5-231912号公報や特開昭54-70679号公報に見られるように利用者の利便性を考慮したユーザインターフェースとしては周知の技術であるから、モジュールの一端に3種の状態を知らせる表示ランプを表示手段として設けることは必要に応じて為されることであり、単なる設計的事項にすぎないものである。 従って、後者においてソフトウエアの完全性をチェックした結果を表示手段で表示することは当業者が容易に為し得ることであり、相違点2を格別の相違ということはできない。 5.むすび したがって、本願発明は引用例1-3に記載された発明および周知の事項に基いて当業者が容易に発明をすることができたものであるので、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
審理終結日 | 2003-05-27 |
結審通知日 | 2003-06-03 |
審決日 | 2003-06-16 |
出願番号 | 特願2001-124981(P2001-124981) |
審決分類 |
P
1
8・
121-
Z
(H04L)
|
最終処分 | 不成立 |
前審関与審査官 | 中里 裕正 |
特許庁審判長 |
吉岡 浩 |
特許庁審判官 |
川崎 優 吉見 信明 |
発明の名称 | ソフトウェア管理モジュール |
代理人 | 松倉 秀実 |
代理人 | 遠山 勉 |