【事件の表示】
　特願２００１−１２４９８１「ソフトウェア管理モジュール」拒絶査定に対する審判事件［平成１４年　２月　８日出願公開、特開２００２−　４４０７０］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯、本願発明
　本願は、平成６年９月２０日に出願した特願平６−２２５２２８号の一部を平成１３年４月２３日に新たな特許出願としたものであって、その請求項１に係る発明は、平成１４年９月２７日付け手続補正書によって補正された明細書及び図面の記載からみて、本願の特許請求の範囲の請求項１に記載された次のとおりのものである。
    
「 通信又は媒体を介して所定のソフトウエア（データおよび／またはプログラム）と、前記ソフトウエアの完全性をチェックするコードであるチェックサムを得て、前記ソフトウエアの処理を行うソフトウエア管理モジュールであって、
　前記ソフトウエアから比較用チェックサムを生成するチェックサム生成手段と、
　前記ソフトウエアとともに受け取った前記チェックサムと、前記チェックサム生成手段により生成された比較用チェックサムとを比較する比較手段と、
　前記ソフトウェア管理モジュールの一端に設けられ、前記比較手段による比較結果および前記チェックサム生成手段が通信又は媒体を介して入力されたソフトウエア（データおよび／またはプログラム）を処理中であることを示す表示手段と、を備え、
　前記表示手段は、前記チェックサム生成手段が処理中である事、前記比較手段による比較結果が異常である事、前記比較手段による比較結果が正常終了した事の３種の状態を知らせる表示を行う表示ランプで構成されることを特徴とするソフトウェア管理モジュール。」
　
２．引用例
　これに対し、原査定の拒絶の理由に引用された「関一則　外３名著、暗号を利用した新しいソフトウエア流通形態の提案、情報処理研究会研究報告、1993年7月20日、Vol.93,No64,p.19-28」（以下、引用例１という。）には、以下の記載がある。
　
（１）「2.2.3 認証アーキテクチャ
　
　認証アーキテクチャは、暗号アーキテクチャと密接な関わりをもち、公開鍵暗号法とそのサポートとしてハッシュ関数を利用する。ここでは、ソフトウエアの著作権者を特定しソフトウエアの不正な改変を検出するためのメッセージ認証・・・（略）・・・
メッセージ認証を行うためには、ソフトウエアのデータ構造は図１のように通常のソフトウエアのヘッダ部分にメッセージ認証子を付加する。認証子は、図１のように、暗号化されたソフトウエアをハッシュ関数にかけて得られたハッシュ・データをソフトウエア著作権者の秘密鍵で暗号化した値・・・（略）・・・によって構成する。」（２１頁右欄８行〜２３行）
　
（２）「2.4　ユーザ管理プロセス
　（略）
　ソフトウエア認証　ソフトウエアの認証とは、通信中にソフトウエアが事故・過失・故意によって改変されていないかを検証することで、ソフトウエア登録プロセスとソフトウエア・サーバの通信におけるソフトウエア認証と同様の認証を行なう。」（２４頁左欄２２行〜３６行）
　
（３）「３　実装
試作システムでは、研究所内の数台のＵＮＩＸワークステーションを結ぶイーサネットによるローカル・エリア・ネットワークを用い、ここにソフトウエア・サーバとなるマシンを設置し、それぞれのユーザーがこのサーバから、あるいは他のユーザーから得たソフトウエアを実行するという環境を支援している。」（２４頁右欄１行〜７行）
　
（４）「故意・事故・過失などのよって改変されたソフトウエアの流通
　このシステムでは、故意・事故・過失などによって改変されたソフトウエアの流通を防ぐ手段として、認証子照合法による認証を行なっている。この認証の安全性は暗号処理ではなく認証子を作成するためのハッシュ関数に依存する。ここで使用されるハッシュ関数は一対一写像ではなく、写像によって得られる値域が縮小しているために逆関数が存在しないので、適当なハッシュ関数を選択することによって高い安全性を保つことができる。」（２６頁右欄１３行から２２行）
　
　以上の記載から、引用例１には、以下の発明が記載されている。
　
　ネットワークを介して所定のソフトウエアと、前記ソフトウエアが事故・過失・故意によって改変されているかを検証するためのハッシュデータから導かれる認証子を得て、前記ソフトウエアを実行する装置であって、
　前記ソフトウエアをハッシュ関数にかけて得られたハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した認証子を前記ソフトウエアのヘッダ部分に付加するようにした認証アーキテクチャによって、通信中の前記ソフトウエアの改変を認証子照合法により検出（メッセージ認証）する装置
　
　また、原査定の拒絶の理由に引用された「岡本栄司著、暗号理論入門、共立出版株式会社、1993年2月25日発行、ｐ.129-131，134-135」（以下、引用例２という。）には、以下の事項が図面とともに記載されている。
　
（５）「７．１　メッセージ認証
　メッセージ認証（message　authentication）とは、メッセージの正当性を確認する技術であり、認証子法と冗長暗号化法が実用化されている。
　７．１．１　認証子法
　証明者は認証子（ＭＡＣ：message　authentication　code）と呼ばれるコードを作成してメッセージとともに送る。それを受けて検証者は、メッセージから同様に認証子を作成して、それが送られた認証子と一致するか否かで、メッセージの正当性（改ざんの有無）を判定する。図７．１は認証子法を示している。
　認証子を作成するには、秘密鍵をパラメータとするハッシュ（hash）関数を使用する。すなわち、秘密の鍵（認証鍵）Ｋを送信側と受信側で共有し、それを用いて認証子を作成するが、鍵Ｋを知らなければメッセージＭと認証子ｈＫ（Ｍ）から、異なるＭ’と対応するｈＫ（Ｍ’）を作れないような関数ｈＫである。ハッシュ関数については、７．４節で詳述するが、長いデータをある一定長のビットパターンに変換する関数である。」（１２９頁１３行から１３０頁６行）
　
　（６）「７．３　デイジタル署名
　ディジタル署名（digital　signature）は、通常のサインと同じく、メッセージや情報の作成者が確かにそれらを作成したことを示すものである。非対称暗号と同時に生まれた概念であり、実際にも非対称暗号を用いることが多いが、対称暗号でも信頼できる機関であれば可能である。（略）
　７．３．２　非対称暗号による署名法
（略）
図７．６　ＲＳＡ署名法（ｂ）ハッシュに署名  」（１３３頁１７行〜１３５頁）
　
　ここで、図７．６には、送り手側で平文Ｍをハッシュ化し、ハッシュ値を秘密鍵で暗号化し平文Ｍとともに送り、受け手側では受け取ったハッシュ値を公開鍵で復号化し、平文Ｍから生成したハッシュ値と照合することによるデジタル署名技術が図示されていると認められる。
　
　また、原査定の拒絶の理由に引用された特公昭６１−２６１１１号公報（以下、引用例３という。）には、以下の事項が図面とともに記載されている。
　
（７）「該処理回路１５の出力端に接続された１つの入力端と、入出装置１２に接続された他の入力端を有する比較回路１６と、上記比較回路１６の出力に接続された入力を有する２つの安定した状態をとる例えば点灯回路のような証明（表示出力）回路１７とを有する。」（公報５頁９欄３９行〜４４行）
　
（８）「次いで、処理回路１５は受信装置から供給されたメッセージの署名ＳＧを自動的に再計算する。・・・（略）・・・
第３相において、処理回路１５により再算出された署名ＳＧは比較装置１６の入力端に供給される。比較回路１６の他の入力端は、入力端子２４を介して、入出力装置１２を介して受信装置から供給される署名ＳＧを受取る。比較装置１６はこれら２つの署名を比較して出力端子２６を介して証明要素しくは表示装置１７を付勢するための信号を発生する。」（公報７頁１３欄９行〜２６行）
　
３．対比
　本願の請求項１にかかる発明（以下、前者という）と、引用例１に記載された発明（以下、後者という。）とを比較する。
　後者の「ネットワーク」「所定のソフトウエア」「前記ソフトウエアが事故・過失・故意によって改変されているかを検証する」は、前者の「通信」「所定のソフトウエア（データおよび／またはプログラム）」「前記ソフトウエアの完全性をチェックする」に相当する。
　また、前者では「ソフトウエア管理モジュール」とされているが、モジュールというものは構造／形状を規定するものではなく、ある情報処理を実現する機能実現手段の集まりにすぎないから、後者におけるメッセージ認証の処理が実行される「装置」に相当するものである。
　また、後者では、「認証子を前記ソフトウエアのヘッダ部分に付加するようにした認証アーキテクチャによって、通信中の前記ソフトウエアの改変を認証子照合法により検出（メッセージ認証）する」とされており、検証の具体的手法については明示されていないが、当該分野の技術常識を示す上記（５）の記載を参酌すれば、認証子照合法というのは、送り手は認証子（ハッシュデータ）を作成してメッセージとともに送り、受け手側ではメッセージから同様の認証子（ハッシュデータ）を作成してそれが送られてきた認証子（ハッシュデータ）と一致するか否かで改ざんの有無を判定する手法であるから、後者においてもソフトウエアから比較用コードを生成するコード作成手段とソフトウエアとともに受け取ったコードと比較用コードを比較する比較手段を有していると解される。
　
してみると、両者は次の点で一致する。
　
　通信を介して所定のソフトウエア（データおよび／またはプログラム）と、前記ソフトウエアの完全性をチェックするコードを得て、前記ソフトウエアの処理を行うソフトウエア管理モジュールであって、
　ソフトウエアから比較用コードを生成するコード生成手段と、
　ソフトウエアとともに受け取った前記コードと、前記コード生成手段により生成された比較用コードとを比較する比較手段と
を有するソフトウェア管理モジュール
　
　一方、両者は、次の点で相違する。
　
（相違点１）
　前者では、ソフトウエアとともに受け取られるコードがチェックサムであるのに対し、後者では、ソフトウエアとともに受け取られるコードは、ソフトウエアをハッシュ関数にかけて得られたハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した認証子である点、
（相違点２）
　前者が、ソフトウエア管理モジュールの一端に、チェックサム生成手段が処理中である事、比較手段による比較結果が異常である事、比較手段による比較結果が正常終了した事の３種の状態を知らせる表示を行う表示ランプで構成される表示手段が設けられているのに対し、後者のものでは比較手段の比較結果の使用形態が明示されていない点、
　
 ４．当審の判断
  上記相違点について検討する。
（相違点１について）
　情報が伝送途中で改変／改ざんされていないことを検出するために、両者はメッセージの情報を凝縮してメッセージとともに送り、受け手側でチェックする手法によっており、このメッセージを凝縮するために用いられる関数は一般にメッセージ要約関数と呼ばれている。そして、ハッシュやチェックサムは広義の意味でメッセージ要約関数と呼ばれている。後者は、メッセージ要約関数としてハッシュデータによってソフトウエアの完全性をチェックするものであるが、前述の通りハッシュもチェックサムも広義の意味でメッセージ要約関数であるから、メッセージ要約関数としてチェックサムを用いることは当業者が容易に想到し得ることである。
　なお、後者では、ハッシュデータをソフトウエア著作権者の秘密鍵で暗号化した値を認証子としているが、これは上記（６）を参照すれば、チェックサムに対して署名を行う、いわゆるデジタル署名を行っているからであり、改ざんの検証はあくまで上記（５）の図７．１に示されるように、ハッシュデータ同士を照合する認証子照合法によっているものである。従って、デジタル署名を行わず、そのための構成、つまり、ハッシュデータをソフトウエア著作権者の秘密鍵で暗号化すること、を後者からはずすようにすることは単なる設計事項にすぎないものである。
　従って、相違点１を格別の相違ということはできない。
（相違点２について）
　後者のものにおいてはソフトウエアの完全性をチェックする手法までしか開示されていないが、チェック結果を次に何らかの処理に用いることは当然である。引用例３に示されるようなメッセージの署名を認証する装置では、上記（７）（８）に示されるように点灯回路のような表示出力回路で認証結果を報知している。また、その表示の形態として、装置の一面に配置された表示ランプを用いることや処理の結果だけでなく処理結果を得るまでの処理中表示を行い、利用者に知らせることは、例えば、特開平５−２３１９１２号公報や特開昭５４−７０６７９号公報に見られるように利用者の利便性を考慮したユーザインターフェースとしては周知の技術であるから、モジュールの一端に３種の状態を知らせる表示ランプを表示手段として設けることは必要に応じて為されることであり、単なる設計的事項にすぎないものである。
　従って、後者においてソフトウエアの完全性をチェックした結果を表示手段で表示することは当業者が容易に為し得ることであり、相違点２を格別の相違ということはできない。
　
 ５．むすび
　したがって、本願発明は引用例１−３に記載された発明および周知の事項に基いて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。