【事件の表示】
　平成　７年特許願第１４４５０７号「ソフトウェアの提供方法」拒絶査定不服審判事件〔平成　８年　６月２５日出願公開、特開平　８−１６６８７９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本件審判請求に係る特許出願は、平成７年６月１２日（優先権主張外国庁受理１９９４年６月１０日、米国）の出願であって、平成１３年７月１０日付けで手続補正がなされ、平成１６年９月２９日付けで拒絶の理由が通知され、それに対して平成１７年４月５日付けで手続補正がなされたものの、同年７月２１日付けで拒絶査定がなされ、これに対し同年１０月２４日に審判請求がなされるとともに、同日付け及び同年１１月２４日付けで手続補正がなされたものである。
　
２．平成１７年１１月２４日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成１７年１１月２４日付けの手続補正を却下する。
　
［理由］
（１）平成１７年１１月２４日付けの手続補正（以下、「本件補正」という。）
　本件補正により、特許請求の範囲の請求項１は、
　
「　第１のコンピュータから第２のコンピュータに安全にソフトウェアを提供する方法であって、第２のコンピュータにより、
（ａ） (i)ソフトウェアと、
(ii)前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名、前記アプリケーション作成者のＩＤ、および前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含むソフトウェアパスポートと
を受信するステップと、
（ｂ）前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認するステップと、
（ｃ）前記確認された第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップとを実行するソフトウェアの提供方法。」
　
と補正された。
　
（２）補正内容の検討
　本件補正は、特許請求の範囲の請求項１に記載した発明を特定するために必要な事項であるアプリケーション作成者の第１の暗号解読用キーであることを確認するステップについて「前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認する」旨の限定を付加するものであって、平成６年法律第１１６号による改正前の特許法第１７条の２第３項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（平成１５年法律第４７号による改正後の特許法第１７条の２第５項において準用する同法第１２６条第５項に規定された要件を満たすか）について以下に検討する。
　
（３）引用例
　本件審判請求に係る特許出願前に日本国内において頒布された刊行物であって、原査定の拒絶の理由に引用された、関一則他，「暗号を利用したソフトウェア流通形態の提案」，情報処理学会研究報告，１９９３年７月２０日，第９３巻，第６４号（９３−ＩＳ−４５），ｐ．１９−２８（以下、「引用例」という。）には、図面と共に次の事項が記載されている。
　
（Ａ）「２  次世代ソフトウェア流通システム
２．１  コンセプト
　暗号による不正防止と積極的なネットワークの利用を行なう本システムの基本的コンセプトは次のようなものである。
・流通経路の簡略化
・所有ではなく利用に対する課金の実現
・複製されたソフトウェアの流通に伴うソフトウェアの価値の混乱の防止
・ネットワークを利用した有効なサービスの実現
・・・（中略）・・・
　本システムでは、このようなコンセプトを実現するために、ソフトウェアは暗号化されて流通されるためにそのままの形では利用できないこととし、実行に際しては、その都度これを復号化することにより行う。ここで、復号に必要となる鍵をネットワークを介して提供者から得ることにより、ソフトウェアを利用する権利を与えられる。したがって、ユーザはネットワークを通して容易にソフトウエアを入手でき、復号鍵をレンタルすることにより利用に対する課金が実現される。暗号化されたソフトウェアに対しては、自由な複製を認め、複製による価値の混乱を防ぐ。
　
２．２   アーキテクチャ
　本システムの構築にあたって必要となるアーキテクチャについて述べる。
・・・（中略）・・・
２．２．３  認証アーキテクチャ
　認証アーキテクチャは、暗号アーキテクチヤと密接な関わりをもち、公開鍵暗号法とそのサポートとしてハッシュ関数を利用する。ここでは、ソフトウェアの著作権者を特定しソフトウェアの不正な改変を検出するためのメッセージ認証技術とソフトウェアを利用するユーザを特定するためのエンティティ認証技術が必要となる［１１，１２］。
　メッセ−ジ認証を行うためには、ソフトウェアのデータ構造は図１のように通常のソフトウェアのヘッダ部分にメッセージ認証に使用する認証子を付加する。認証子は、図１のように、暗号化されたソフトウェアをハッシュ関数にかけて得られたハッシュ・データをソフトウェア著作権者の秘密鍵で暗号化した値とソフトウェア著作権者のアドレス・名前や公開鍵といった個人情報によって構成する。
　ユーザを特定するためのエンティティ認証には、公開鍵暗号法による認証子照合法を利用している。
・・・（中略）・・・
２．２．７　ソフトウェア管理アーキテクチャ
　ソフトウェア管理アーキテクチャは、多くのソフトウェア著作権者から提供されたソフトウェアを管理するために必要となる。ソフトウェア管理アーキテクチャによって管理される情報は、暗号化された流通状態のソフトウェア、・・・（中略）・・・ソフトウェア著作権者の個人情報である。」（２０頁右欄２行〜２２頁右欄７行）
　
（Ｂ）「２．３　システムモデル
　本システムは、ソフトウェア登録プロセス、ソフトウェア・サーバ、ユーザ管理プロセスから成り、それぞれを先に述べた各アーキテクチャより構成される。すなわち、ソフトウェアはソフトウェア登録プロセスによってソフトウェア・サーバに登録され（図２参照）、ソフトウェアの実行はユーザ管理プロセスのもとでしか実行できないものとする。それぞれの実行に伴うソフトウェアの通信・認証・鍵の通信・利用状況の通信はユーザ管理プロセスとソフトウェア・サーバの間で行われる（図３参照）。
　
２．３．１　ソフトウェア登録プロセス
　ソフトウェア登録プロセスでは、ソフトウェア提供者によるソフトウェアの登録を受け付けている。ここでの機能は、流通されるソフトウェアの暗号化とそれに伴うソフトウェア暗号鍵の生成、ソフトウェアに付加される認証子の生成、通信に際してソフトウェア暗号鍵の暗号化である。
・・・（中略）・・・
認証子の生成　流通状態のソフトウェアが暗号化によって完成すると、このソフトウエアの認証子が認証アーキテクチャで生成される。認証子は流通されるソフトウェアの改変を検出し、ソフトウェア著作権者の認証を行なうために利用される。
・・・（中略）・・・
　これらの情報が通信アーキテクチャに渡され、ソフトウェアサーバに送られる。」（２２頁右欄２５行〜２３頁右欄２０行）
　
（Ｃ）「２．３．２   ソフトウェア・サーバ
　ソフトウェア・サーバは、ソフトウェア提供者とユーザの間でソフトウェアの流通・鍵の管理と送信・各ユーザの利用状況の管理などの仲介を行う。
・・・（中略）・・・
　ソフトウェア・サーバにはソフトウェア著作件者側にあるソフトウェア登録プロセスとの通信に関する動作と、ユーザ側で立ち上がるユーザ管理プロセスとの通信に関する動作の２種類の動作がある。
　まず、ソフトウェア登録プロセスとの通信に関する動作を述べる（図２参照）。
　
認証　ソフトウェアがソフトウェア登録プロセスから送信されてくると認証アーキテクチャによって通信中の改変などの検出（メッセージ認証）と提供者の認証（エンティティ認証）が行なわれる。
　
ソフトウェアの登録　認証が成功すると、ソフトウェア暗号鍵、ソフトウェア著作権者の個人情報をソフトウェア管理プロセスに渡す。
　
　次に、ユーザ管理プロセスとの通信に関する動作について述べる（図３参照）。
　
ソフトウェアの送信　ユーザ側にソフトウェアが存在せず、そのソフトウェアの送信要求を受け取ると、該当するソフトウェアを選びだし、ユーザにこのソフトウェアを送信する。ここで、送信されるソフトウェアは流通状態のソフトウェアである。」（２３頁右欄２１行〜２４頁左欄７行）
　
（Ｄ）「２．４  ユーザ管理プロセス
　ユーザ管理プロセスでは、ユーザーの認証とソフトウェアの実行、実行状況の制御・管理、これらに伴うソフトウエア・サーバとの通信をを行う。
　
ソフトウェアの実行　ソフトウエアが存在しなければソフトウェア・サーバに対してこのソフトウェアの送信要求を出し、ソフトウェアを受けとる。この際、ソフトウェア認証が行われる。・・・（中略）・・・
　
ソフトウエア認証　ソフトウェアの認証とは、通信中にソフトウェアが事故・過失・故意によって改変されていないかを検証することで、ソフトウェア登録プロセスとソフトウェア・サーバの通信におけるソフトウェアの認証と同様の認証を行なう。」（２４頁左欄２２行〜同欄３６行）
　
（Ｅ）「３   実装
　試作システムでは、研究室内の数台のＵＮＩＸワークステーションを結ぶイーサーネットによる口ーカル・エリア・ネットワークを用い、ここにソフトウェア・サーバとなるマシンを設置し、それぞれのユーザーがこのサーバから、あるいは他のユーザーから得たソフトウェアを実行するという環境を支援している。」（２４頁右欄１行〜同欄７行）
　
（Ｆ）「４．１   本システムのもたらす効果
　ここでは我々の提案したシステムが実現することにより得られる効果について従来の流通形態と比較しながら考察する。
　
ソフトウェア著作権の保護　・・・（中略）・・・
　
流通経路の簡略化　本システムではネットワークを通してソフトウェアを入手することによって流通経路の簡略化が実現できる。その効果は大きく、流通段階でのコスト・ダウンやソフトウェア提供者とユーザの距離の短縮という効果が挙げられる。
　短縮される提供者とユーザ間の距離として、時間的距離、社会的距離、地理的距離が考えられる。・・・（中略）・・・社会的距離とは、ソフトウェア著作権者とユーザの社会的立場の違いのことで、このシステムでは後述するように個人による有料ソフトウェアの流通を可能にするので、ソフトウェア提供者がユーザになることはもちろんのこととして、ユーザが提供者になることも可能となる。・・・（中略）・・・
　
個人による有料ソフトウェアの流通  本システムでは任意のユーザが、ソフトウェア登録プロセスを通してソフトウェア提供者となり得る。」（２５頁左欄３６行〜同頁右欄３１行）
　
（Ｇ）「４．２  システムの安全性
　ここでは、システムにおける様々な不正行為や危険に対する防止機構とその安全性について述べる。
　
・・・（中略）・・・
故意・事故・過失などによって改変されたソフトウェアの流通  このシステムでは、故意・事故・過失などによって改変されたソフトウェアの流通を防ぐ手段として、認証子照合法による認証を行なっている。」（２６頁左欄１１行〜同頁右欄１６行）
　
（Ｈ）「４．３  問題点と今後の課題
　ここではこのシステムが抱える問題点と今後の課題について述べる。           
・・・（中略）・・・
ウィルスを含むソフトウェアの流通  本システムでは、ネットワークによってソフトウェアを流通することによってソフトウェア著作権者とユーザの距離が短縮されるためにソフトウエアの流通範囲が大きい。したがって、もし悪意を持ったユーザが故意にウィルスを含むソフトウェアを流通させた場合、そのソフトウェアによってもたらされる被害が及ぶ範囲が非常に大きくなってしまう危険性がある。ウィルスを含むソフトウェアによる披害は現在の流通形態でも問題になっているが、このシステムではより深刻な問題となる。」（２６頁右欄２８行〜２７頁左欄２８行）
　
　（Ａ）に記載された「ソフトウェアは暗号化されて流通される」システムである「次世代ソフトウェア流通システム」についての、（Ｂ）の「ソフトウェアはソフトウェア登録プロセスによってソフトウェア・サーバに登録され・・・、ソフトウェアの実行はユーザ管理プロセスのもとでしか実行できないものとする」及び「流通状態のソフトウェアが暗号化によって完成する」の記載、（Ｃ）のソフトウェア・サーバについての「ソフトウェアの送信要求を受け取ると、該当するソフトウェアを選びだし、ユーザにこのソフトウェアを送信する。」の記載、及び（Ｄ）のユーザ管理プロセスについての「ソフトウェアの実行・・・ソフトウェア・サーバに対してこのソフトウェアの送信要求を出し、ソフトウェアを受けとる。」の記載、並びに、次世代ソフトウェア流通システムの実装についての（Ｅ）の「試作システムでは、・・・ここにソフトウェア・サーバとなるマシンを設置し、それぞれのユーザーがこのサーバから・・・得たソフトウェアを実行するという環境を支援している。」の記載からみて、
　引用例には、実装されたソフトウェア・サーバとユーザ管理プロセスを含む次世代ソフトウェア流通システムにおける、ソフトウェア・サーバとなるマシンからユーザ管理プロセスの下でソフトウェアを実行するワークステーションへ暗号化されたソフトウェアを送信して流通する方法が記載されている。
　
　そして、（Ａ）の「２．２．７　ソフトウェア管理アーキテクチャ」の記載からみて、送信されるソフトウェアは、ソフトウェア著作権者から提供されており、（Ｃ）のソフトウェア登録プロセスとの通信に関するソフトウェア・サーバでの認証の動作についての「ソフトウェアがソフトウェア登録プロセスから送信されてくると認証アーキテクチャによって通信中の改変などの検出（メッセージ認証）と提供者の認証（エンティティ認証）が行なわれる。」の記載、（Ａ）の「ソフトウェアのデータ構造は図１のように通常のソフトウェアのヘッダ部分にメッセージ認証に使用する認証子を付加する・・・認証子は、図１のように、暗号化されたソフトウェアをハッシュ関数にかけて得られたハッシュ・データをソフトウェア著作権者の秘密鍵で暗号化した値とソフトウェア著作権者のアドレス・名前や公開鍵といった個人情報によって構成する」の記載、「図１：ソフトウェアのデータ構造」の図示、及び（Ｂ）の「流通状態のソフトウェアが暗号化によって完成すると、このソフトウエアの認証子が認証アーキテクチャで生成される。認証子は流通されるソフトウェアの改変を検出し、ソフトウェア著作権者の認証を行なうために利用される。」の記載からみて、
　ソフトウェア登録プロセスとの通信の際ソフトウェア・サーバにおいて通信中の改変などの検出であるメッセージ認証と提供者の認証であるエンティティ認証が行われ、そのメッセージ認証のための処理は、暗号化されたソフトウェアに付加され、暗号化されたソフトウェアをハッシュ関数をかけて得られたハッシュ・データをそのソフトウェアを提供したソフトウェア著作権者の秘密鍵で暗号化した値及びそのソフトウェア著作権者のアドレス・名前や公開鍵といった個人情報によって構成された、認証子を使用して行われる。
　ここで、改変などが検出されるべきメッセージを秘密鍵で暗号化した値によるメッセージ認証ではその値とともにその秘密鍵と対になる公開鍵を使用するから、暗号化されたソフトウェアのハッシュ・データをそのソフトウェアを提供したソフトウェア著作権者の秘密鍵で暗号化した値を使用したメッセージ認証のための処理においては、その値とともにそのソフトウェア著作権者の秘密鍵と対になる公開鍵であるそのソフトウェア著作権者の公開鍵が使用される。
　
　さらに、（Ａ）「ソフトウェアの著作権者を特定しソフトウェアの不正な改変を検出するためのメッセージ認証技術」の記載、（Ｄ）の「ソフトウェアを受けとる。この際、ソフトウェア認証が行われる。・・・ソフトウェアの認証とは、通信中にソフトウェアが事故・過失・故意によって改変されていないかを検証することで、ソフトウェア登録プロセスとソフトウェア・サーバの通信におけるソフトウェアの認証と同様の認証を行なう。」の記載からみて、
　送信されたソフトウェアを受け取ったユーザ管理プロセスの下でソフトウェアを実行するワークステーションでは、ソフトウェアが事故・過失・故意によって改変されていないかを検証すべく、ソフトウェア登録プロセスとソフトウェア・サーバの通信における、上述した認証子を使用して行われる通信中の改変などの検出であるメッセージ認証と同様の認証を行ってソフトウェアの著作権者を特定しソフトウェアの不正な改変を検出している。
　
　してみると、引用例には、
　
　ソフトウェア・サーバとなるマシンからユーザ管理プロセスの下でソフトウェアを実行するワークステーションへ改変されたソフトウェアの流通を防いで暗号化されたソフトウェアを流通する方法であって、
　該ワークステーションで、
　暗号化されたソフトウェアをハッシュ関数をかけて得られたハッシュ・データをそのソフトウェアを提供したソフトウェア著作権者の秘密鍵で暗号化した値、そのソフトウェア著作権者のアドレス・名前や公開鍵といった個人情報、によって構成された認証子が付加された暗号化されたソフトウェアを、受け取り、
　そのソフトウェア著作権者の公開鍵により通信中の改変などの検出であるメッセージ認証を行う、
暗号化されたソフトウェアを流通する方法
　
の発明（以下「引用発明」という。）が記載されているものと認められる。
　
（４）本願補正発明と引用発明との対比
　本願補正発明と引用発明とを対比する。
　
　引用発明の「ソフトウェア・サーバとなるマシン」、「ユーザ管理プロセスの下でソフトウェアを実行するワークステーション」、「暗号化されたソフトウェア」、「流通する」、「ソフトウェア著作権者」は、それぞれ、本願発明の「第１のコンピュータ」、「第２のコンピュータ」、「ソフトウェア」、「提供する」、「アプリケーション作成者」に相当する。
　
　公開鍵による復号化によってメッセージの改変の検出やメッセージの提供者の認証を行うべく、メッセージの提供者の秘密鍵でメッセージそのものやメッセージのハッシュデータを暗号化して得られるものをデジタル署名と称する一般的な用語法に従えば、引用発明の「ソフトウェア著作権者の秘密鍵」及びそれと対になる「ソフトウェア著作権者の公開鍵」は、それぞれ提供されるソフトウェアをメッセージとするデジタル署名を得る際の暗号化に用いる鍵とそれと対になるデジタル署名の復号化に用いる鍵であって、それぞれ本願補正発明の「第１の暗号用キー」及びそれと対になる「第１の暗号解読用キー」に相当する。そして、引用発明の「暗号化されたソフトウェアをハッシュ関数をかけて得られたハッシュ・データをソフトウェア著作権者の秘密鍵で暗号化した値」、つまり、メッセージとなる上記ソフトウェアのハッシュデータを第１の暗号用キーで暗号化して得られるデジタル署名は、本願発明の「前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名」に相当する。
　さらに、引用発明の「そのソフトウェア著作権者のアドレス・名前や公開鍵といった個人情報」は、ソフトウェアを提供したアプリケーション作成者を識別する情報であり、本願補正発明の「前記アプリケーション作成者のＩＤ」に相当する。
　そうすると、引用発明の「認証子」は、前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含んでおらずソフトウェアパスポートでないものの、ソフトウェアと共に受信される、前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名とソフトウェアを提供したアプリケーション作成者のＩＤとを含む情報である点で、本願補正発明の「ソフトウェアパスポート」に対応しており、さらに、引用発明ではこの情報が付加されたソフトウエアを「受け取」っているので、引用発明の「受け取」ることは、本願補正発明の「受信するステップ」を実行することに対応している。
　
　さらに、引用発明では、公開鍵により通信中の改変などの検出であるメッセージ認証を行うことによって、ソフトウェアが、公開鍵である第１の暗号解読用キーに対応する秘密鍵である第１の暗号キーが属するアプリケーション作成者により提供されたものであることを確認しているので、引用発明の「そのソフトウェア著作権者の公開鍵により通信中の改変などの検出であるメッセージ認証を行う」ことは、第１の暗号解読用キーが「前記確認された」ものでない点を除き、本願補正発明の「前記確認された第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップ」を実行することに対応している。
　
　してみると、本願補正発明と引用発明とは、
　
（一致点）
　第１のコンピュータから第２のコンピュータにソフトウェアを提供する方法であって、
　第２のコンピュータにより、
　ソフトウェアと、
　前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名、及び、前記アプリケーション作成者のＩＤ、を含む情報とを受信するステップと、
　第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップ
とを実行するソフトウェアの提供方法
　
　である点で一致しており、次の（あ）〜（え）の点で相違している。
　
（相違点）
（あ）ソフトウェアを提供する際、本願補正発明では「安全に」提供するのに対して、引用発明では、改変されたソフトウェアの流通を防ぐものの安全に提供していることを明示していない点。
　
（い）ソフトウェアと共に受信される、前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名及びソフトウェアを提供したアプリケーション作成者のＩＤを含む情報が、本願補正発明では、「前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含むソフトウェアパスポート」であるのに対して、引用発明では、前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含まない、認証子であって、前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含むソフトウェアパスポートでない点。
　
（う）本願補正発明では、第２のコンピュータにより、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認するステップを実行しているのに対して、引用発明では、第２のコンピュータにより、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認するステップを実行していない点。
　
（え）第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップを実行するにあたって、本願補正発明の第１の暗号解読用キーが「前記確認された」ものであるのに対して、引用発明の第１の暗号解読用キーが「前記確認された」ものでない点。
　
（５）相違点の判断
　上記相違点について検討する。
　
（ｉ）相違点（あ）（い）について
　所定機関のデジタル署名を含み公開鍵が所定の者の公開鍵であることを証明すべく作成される公開鍵証明書を所定機関が発行して、発行された公開鍵証明書の証明事項を確認する、つまり公開鍵証明書により公開鍵がその所定の者やその者の秘密鍵と対応することを確認する技術は、公開鍵証明書で公開鍵と対応するものとされた秘密鍵でデジタル署名を作成する権限が所定機関から設定されるという意味で所定機関が公開鍵証明書を能力や資格や身分に応じた権限や制限であるライセンスに対する証明（以下、「ライセンス証」という。）として発行し、発行された公開鍵証明書の証明事項を確認する技術を含むと解されるものであって、
　
・特開平２−２９１０４３号公報（以下「周知例１」という。）の「信頼しうる公共機関が・・・ディジタルメッセージを作成し、当該機関の代表者が当該機関自身の署名でディジタルメッセージに署名する。証明書と呼ばれることも多いこのディジタルメッセージが権利主張者自身のディジタル署名と共に送付される。権利主張者のメッセージを受け取った人は、機関のパブリックキー（機関署名の検証を可能にする）を認知することを条件に、またその受け手の当該機関に対する信用の度合いに応じて署名を使用することができる。証明書は、信頼のおける機関が署名した短いメッセージであり、その中で証明されているパブリックキー及び該パブリックキーの所有者（作成者）の身分に関する説明を明瞭にあるいは暗黙に含んでいるものであると考えることができる。このように解釈した場合、”Ｃ”が”Ａ”のための証明書を与えたとすると、受け手である”Ｂ”は、”Ｂ”が”Ｃ”を信用することを条件に、また”Ｂ”が”Ａ”のパブリックキーに関する”Ｃ”の証明を保有していることを条件として、”Ａ”のパブリックキーの使用を信用することができる。」（８頁左下欄４行〜同頁右下欄９行）の記載
　
にあるごとく、周知である。
　さらに、デジタル署名をする者の能力や資格や身分に応じた権限や制限に関連付けて公開鍵証明書を所定機関がライセンス証として発行して、発行された公開鍵証明書の証明事項を確認する技術も
　
・周知例１の「例えば、本発明によると下位者が特定のパブリックキーを特定の従業員が使用していることを証明できるようになるだけでなく、その雇用関係において当該個人に対して会社が与えている権限を明確にすると共に会社を代表してパブリックキーを使用していることを明示することも可能になる。・・・証明者は証明書を作成する際に、証明を受けるパブリックキーを固定する欄、および被証明者の名前、身分等を含む特別メッセージを作成する。証明者の作成する証明書にはさらに付与されている権限および課せられている制限や保証条項も含まれる。この中には、例えば・・・被証明者に対して与えられている信用の程度のように証明者に関係する問題を反映した情報が含まれる。」（９頁左下欄９行〜同頁右下欄９行）の記載、及び、
　
・特開平５−２１６４１１号公報（以下「周知例２」という。）の「【００３１】・・・本発明では、認定センターによって指示されたネットワーク安全保証ポリシーの施行を達成するためには、装置Ａが公開キーＰＵＭａの認定を要求した時点で、認定センターが、装置Ａは認証された現構成ベクトルで構成することが有効かどうかを検証することが必要である。装置Ａは、検査（audit ）レコードで、装置Ａの現構成ベクトルのコピーを認定センターに送るよう要求される。次に、認定センターは、装置Ａの構成ベクトルのコピーを認定センターに格納されている装置Ａの認証された構成ベクトルと比較する。その比較が満足であるなられば、認定センターは、要求されていた認定を付与し、認定センターの非公開の認定キーＰＲＣを使用して、装置Ａの公開キーＰＵＭａを表すデジタル署名ｄＳｉｇＰＲＣを作成する。」の記載
　
にあるごとく、周知である。つまり、公開鍵証明書を所定機関がライセンス証として発行して、発行された公開鍵証明書の証明事項を確認する技術は、上記のいずれの意味においても周知技術である。
　
　そして、上記２．（３）の（Ｆ）（Ｇ）（Ｈ）の記載からみて、引用発明は、ウィルスを含むソフトウェアによる被害のない安全な流通を実現するために故意にウィルスを含むソフトウェアを流通させるような悪意を持ったソフトウェア提供者であるユーザに必要な対処を行なって、そのような悪意を持たず安全な流通の実現を妨げないソフトウェア提供者であるユーザだけにソフトウェアを流通させるという課題を内在するものである。
　してみると、引用発明において悪意を持たないソフトウェア提供者であるユーザだけにソフトウェアを流通させるべく上記した周知技術を採用して、所定機関のデジタル署名を含み公開鍵が所定の者の公開鍵であることを証明すべく作成される公開鍵証明書をライセンス証として発行して発行された公開鍵証明書の証明事項を確認するように構成し、
　引用発明において、その認証子を、前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含むソフトウェアパスポートとすることは、当業者が容易になし得たことであって、相違点（い）は、いずれも格別なものでない。
　さらに、このように引用発明において上記の周知技術を採用することによって、ソフトウェアを提供する際、ウィルスによる被害が少なくなることが期待されるという意味で安全に提供されることになるから、相違点（い）と同様に、相違点（あ）も格別なものでない。
　
（ｉｉ）相違点（う）（え）について
　公開鍵証明書を所定機関がライセンス証として発行して、発行された公開鍵証明書の証明事項を確認する技術が周知技術であることは、上記（ｉ）に示したとおりであり、公開鍵証明書の証明事項を確認するために公開鍵証明書のデジタル署名の公開鍵による復号化を行う装置がその復号化を行なうための公開鍵を取得する仕組みは上記（ｉ）に示した周知技術にとって不可欠なものである。
　また、デジタル署名の公開鍵による復号化を行う装置にその公開鍵を予め含めておく仕組みによって、ソフトウェアを提供する装置と無関係に、所定機関の問い合わせ先のような所定機関に関する特定の知識を持つ必要なく、検証に先立ってあらかじめ既存のものとして、デジタル署名の公開鍵による復号化を行う装置がその公開鍵を取得するようにすることは、
　
・特開昭６３−８７８６号公報の「・・・キー分配センター（審決注：ＫＤＣ）の公開キー（ＰＫｋｄｃ）が、端末のＣＦ（審決注：暗号機構）内に導入されているものと仮定される。公開キーは、たとえば、端末の製造工程の一部としてマイクロコード内に導入することができる。」（５頁左下欄１５行〜同頁右下欄３行）の記載、及び「ＰＫ証明」についての６頁右上欄１１行〜１７行の記載
　
にあるように周知である。
　
　そして、引用発明が、ウィルスを含むソフトウェアを流通させない、悪意を持たず安全な流通の実現を妨げないソフトウェア提供者であるユーザだけにソフトウェアを流通させるという課題を内在するものであることは、上記（ｉ）に示したとおりである。
　
　してみると、引用発明において悪意を持たないソフトウェア提供者であるユーザだけにソフトウェアを流通させるべく、上記周知技術を上記した周知の仕組みとともに採用して、所定機関のデジタル署名を含み公開鍵が所定の者の公開鍵であることを証明すべく作成される公開鍵証明書をライセンス証として発行して発行された公開鍵証明書の証明事項を確認するとともに公開鍵証明書の証明事項を確認する際のデジタル署名の公開鍵による復号化を行う装置に含めて所定機関の公開鍵を取得させるように構成し、
　引用発明において、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認するステップを第２のコンピュータにより実行するとともに、第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップを実行するにあたって用いられる第１の暗号解読用キーを「前記確認された」ものとすることは、当業者が容易になし得たことであって、相違点（う）（え）は、格別なものでない。
　
　そして、本願補正発明の構成によってもたらされる効果も、引用発明及び周知技術から当業者ならば予測することができる程度のものであって、格別なものとはいえない。
　
（６）むすび
　したがって、本願補正発明は、日本国内において頒布された刊行物である引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものであるので、本件補正は、特許法第１７条の２第５項で準用する同法第１２６条第５項の規定に違反するものであり、特許法第１５９条第１項の規定において読み替えて準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
（１）本願発明の認定
　平成１７年１１月２４日付けの手続補正は上記２．のとおり却下されたので、本件審判請求に係る特許出願の請求項１に係る発明（以下「本願発明」という。）は、平成１７年１０月２４日付けの手続補正（この補正は、平成６年法律第１１６号による改正前の特許法第１７条の２第３項第１号の請求項の削除を目的とするものである。）による補正後の請求項１に記載された事項による特定される、以下のとおりのものである。
　
「　第１のコンピュータから第２のコンピュータに安全にソフトウェアを提供する方法であって、第２のコンピュータにより、
（ａ） (i)ソフトウェアと、
(ii)前記ソフトウェアを第１の暗号用キーにより暗号化して得られるアプリケーション作成者のデジタル署名、前記アプリケーション作成者のＩＤ、および前記第１の暗号用キーに対応する第１の暗号解読用キーと前記アプリケーション作成者とを対応付ける所定機関のデジタル署名を含むソフトウェアパスポートと
を受信するステップと、
（ｂ）前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを確認するステップと、
（ｃ）前記確認された第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップとを実行するソフトウェアの提供方法。」
　
（２）引用発明
　原査定の拒絶の理由に引用された引用例、及び引用例に記載された発明（上記「引用発明」）その他の記載事項は、上記２．（３）に記載したとおりである。
　
（３）本願発明と引用発明との対比
　本願発明は、上記２．で検討した本願補正発明からアプリケーション作成者の第１の暗号解読用キーであることを確認するステップについての限定事項である「前記第１のコンピュータと無関係で且つ前記第２のコンピュータが前記所定機関に関する特定の知識を持つことなく取得した既存の第２の暗号解読用キーを使って確認する」旨を省いたものである。
　そして、本願発明と引用発明とを対比すると、両者は、上記２．（４）で認定した一致点において一致し、以下の（あ’）〜（え’）の４点において相違している。
　
（相違点）
（あ’）、（い’）　上記２．（４）の（あ）、（い）に同じ。
　
（う’）本願発明では、第２のコンピュータにより、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを確認するステップを実行するのに対して、引用発明では、第２のコンピュータにより、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを確認するステップを実行していない点。
　
（え’）第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップを実行するにあたって、本願補正発明の第１の暗号解読用キーが「前記確認された」ものであるのに対して、引用発明の第１の暗号解読用キーが「前記確認された」ものでない点。　
　
（４）相違点の判断
　相違点（あ’）、（い’）については、上記２．（５）（ｉ）で示したとおり、いずれも格別なものでない。
　
（相違点（う’）、（え’）について）
　公開鍵証明書を所定機関がライセンス証として発行して、発行された公開鍵証明書の証明事項を確認する技術が周知技術であること、及び、引用発明が、ウィルスを含むソフトウェアを流通させない、悪意を持たず安全な流通の実現を妨げないソフトウェア提供者であるユーザだけにソフトウェアを流通させるという課題を内在するものであることは、上記２．（５）の（ｉ）に示したとおりである。
　してみると、引用発明において悪意を持たないソフトウェア提供者であるユーザだけにソフトウェアを流通させるべく上記した周知技術を採用して、所定機関のデジタル署名を含み公開鍵が所定の者の公開鍵であることを証明すべく作成される公開鍵証明書をライセンス証として発行して発行された公開鍵証明書の証明事項を確認するように構成し、
　引用発明において、前記ソフトウェアパスポートの前記所定機関のデジタル署名により特定される第１の暗号解読用キーが、前記所定機関により証明されたアプリケーション作成者の第１の暗号解読用キーであることを確認するステップを第２のコンピュータにより実行するとともに、第１の暗号解読用キーを用いて前記ソフトウェアが前記アプリケーション作成者により提供されたソフトウェアであることを確認するステップを実行するにあたって用いられる第１の暗号解読用キーを「前記確認された」ものとすることは、当業者が容易になし得たことであって、相違点（う’）（え’）は、いずれも格別なものでない。
　
　そして、本願発明の構成によってもたらされる効果も、引用発明及び周知技術から当業者ならば予測することができる程度のものであって、格別なものとはいえない。
　
　してみると、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
（５）むすび
　以上のとおり、本願発明は、本願の出願前に日本国内において頒布された刊行物である引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。