【事件の表示】
　平成１０年特許願第５４１８５６号「ネットワークを介して受信されたアプリケーション・プログラムを実行するサーバのセキュリティを確保する方法および装置」拒絶査定不服審判事件〔平成１０年１０月　８日国際公開、ＷＯ９８／４４４０４、平成１４年　１月２９日国内公表、特表２００２−５０３３６４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　１．手続の経緯
　本願は、１９９８年３月２７日（パリ条約による優先権主張１９９７年４月１日、米国）を国際出願日とする出願であって、平成１７年３月１６日付けで拒絶理由通知がなされ、同年６月２１日付けで手続補正がなされたが、同年７月２７日付けで拒絶査定がなされ、これに対し、同年１０月３１日に審判請求がなされるとともに、同日付けで手続補正がなされ、同年１２月２６日付けで前置報告がなされ、平成２０年７月２９日付けで当審より拒絶理由通知がなされ、それに対して同年１２月２２日付けで手続補正がなされたものである。
　
　２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２０年１２月２２日付けで補正された特許請求の範囲の請求項１に記載された以下のとおりのものである。
　
　「サーブレットを実行するサーバのセキュリティを確保する方法において、
　サーブレットを送信元コンピュータから受信するステップであって、サーブレットは、サーブレットのホストを安全に固有に識別する関連付けられた送信元識別子を有する、ステップと、そして
　サーバによってサーブレットに提供される１つ以上の資源へのアクセス特権を、サーバの検証手段によって、許可するステップであって、そのアクセス特権が送信元識別子に基づいて各資源に対してサーバの検証手段によって個別に判定される、ステップと、
を含み、
　１つ以上の資源へのアクセス特権を許可する前にサーブレットのコードおよび関連付けされた送信元識別子を検査してそれらが損なわれていないことを検証手段が確認する、
ことを特徴とする方法。」
　
　３．引用発明
　これに対して、当審における、平成２０年７月２９日付けで通知した拒絶の理由に引用した本願の優先権主張の日前の平成８年８月１日に頒布された「青柳龍也，”インターネット最前線８　Ｊａｖａ−キャッチフレーズの真相”，ｂｉｔ，共立出版株式会社，平成８年８月１日，第２８巻，第８号，ｐ．１５−２４」（以下、「引用文献１」という）には、以下の（イ）〜（ハ）の事項が記載されている。
　
　（イ）「たとえ話で説明しましょう。アプレットをダウンロードして何かをやってもらうということは、お手伝いさんを呼んで掃除や洗濯をやってもらうのに似ています。はるばる海の向こうからお手伝いDuke君がネットワークを通ってやってきたとしましょう。
　Duke君に掃除、洗濯をしてもらうには、Duke君を家の中に入れないといけません。しかし、もしDuke君が悪い奴だったら、お金を盗まれたりするかもしれません。ひょっとするとDuke君はにせ者かもしれません。心配なので、Duke君をまだ家に入れるわけにはいかないのです。
・・・（中略）・・・
　アプレットにできること、できないことがＦＡＱとしてまとめられています。この中に、上の表が載っています。
・・・（中略）・・・
　同じブラウザでもネットワークからアプレットをロードした場合と、ローカルファイルからロードした場合で少し違います。ローカルファイルからロードした場合は、いわば、住み込みのお手伝いさんですね。
・・・（中略）・・・
　Appletviewerでネットワークからロードした場合は、三つだけ○がついています。Appletviewerには、access control list（acl）という設定ができるようになっています。これを設定すればフアイルの読書きができるようになります。」（第１６頁左コラム第７行〜第１７頁左コラム第４行）
　
　（ロ）「・Duke君を家に入れるには
　さて、ここからは将来の話です。あるアプレット（Duke君）を信用するためには、ネットワークからダウンロードされたアプレットが本当にDuke君であり、にせ者ではないことを保証しないといけません。このために「Signed applet」というものが考えられています。デジタル署名の技術を使って本当のDuke君であることを保証しようというものです。Duke君が身分証明書を持ってやってくるという感じです。
　ダウンロードしたアプレットが本当にDuke君であることが保証できれば、後は、Duke君に何を許すかを決めてやればよいことになります。」（第１８頁左コラム第７行〜同第１８行）
　
　（ハ）「JavaOneでは、JeevesというJava Webサーバのアルファリリースを今年の夏に出すと言っています。そのリリースでは「signed servlet」をサポートするそうです。servletとは、アプレットとは逆に、サーバにアップロードされて実行されるプログラム部品です。」（第１８頁左コラム第３０行〜同第３５行）
　
　上記（ロ）に記載されているように、引用文献１には、デジタル署名によりアプレットがにせ者ではないことを保証する「Signed applet」を用い、保証されたアプレットに何を許すかを決めるという趣旨の記載が存在する。ここで、前記「何を許すかを決める」という記述の意義を検討すると、引用文献１の上記（イ）の「アプレットにできること、できないことがＦＡＱとしてまとめられています。この中に、上の表が載っています」という記載において引用されている「表」とは、引用文献１の第１６頁の冒頭に掲げられている表のことであり、その表を参照すると「/home/me下のファイルの読み込み」、「/tmpへのファイルの書き込み」と記載されており、また、上記（イ）の「Appletviewerには、access control list（acl）という設定ができるようになっています。これを設定すればフアイルの読書きができるようになります」という記載が存在し、また、前記「/home/me」や「/tmp」がディレクトリを表す記述であることは当業者にとって自明であることに鑑みれば、引用文献１の前記「何を許すかを決める」という記述によって表現されている技術思想の中には、特定のファイルの読み書きを許すか否かをディレクトリ単位で決定することが包含されることは、当業者にとって自明である。
　また、引用文献１には、上記（ロ）に続く上記（ハ）において、アプレットとは逆にサーバにアップロードされて実行されるプログラムであるservletに関する「signed servlet」について記載されており、上記（ロ）の記載と併せて読めば、「signed servlet」が、デジタル署名によってにせ者ではないことを保証するservletを意味していることは、当業者に明らかであるから、引用文献１には、デジタル署名によりservletがにせ者ではないことを保証する「signed servlet」を用い、保証されたservletに何を許すかを決めることが実質的に記載されている。
　なお、デジタル署名を受け取った場合に、その内容を検証することによって該デジタル署名の正当性を確認することは技術常識であるから、引用文献１において受け取ったデジタル署名の内容を検証し、そのデジタル署名の正当性が確認された場合にservletに何を許すかを決める処理手段がサーバに存在することは、当業者にとって自明である。
　また、上記（ハ）に記載されているように、servletとはサーバにアップロードされて実行されるプログラムであるから、サーバ側において、アップロード元のコンピュータからservletを受信するステップが実行されることは自明である。
　
　よって、引用文献１には次の発明（以下、「引用発明」という。）が記載されているものと認められる。
　
　「servletを実行するサーバのセキュリティを確保する方法において、
　servletをアップロード元のコンピュータから受信するステップであって、servletはにせ者ではないことを保証するデジタル署名を有する、ステップと、そして
　サーバによってservletに特定のファイルの読み書きを許すか否かをディレクトリ単位で決定するステップであって、その決定が前記デジタル署名に基づいてサーバの処理手段によって判定される、ステップと、
を含む方法。」
　
　４．対比
　引用発明の「servlet」が、本願発明の「サーブレット」に相当する。
　引用発明の「サーバ」が、本願発明の「サーバ」に相当する。
　引用発明の「アップロード元のコンピュータ」が、本願発明の「送信元コンピュータ」に相当する。
　引用発明の「servletはにせ者ではないことを保証するデジタル署名を有する」と、本願発明の「サーブレットは、サーブレットのホストを安全に固有に識別する関連付けられた送信元識別子を有する」は、サーブレットが、サーブレットの安全性を識別する関連付けられた識別情報を有するという点において共通する。
　引用発明の「servletに特定のファイルの読み書きを許すか否か」が、本願発明の「サーブレットに提供される１つ以上の資源へのアクセス特権」に相当する。したがって、引用発明の「処理手段」と本願発明の「検証手段」は、サーブレットに提供される１つ以上の資源へのアクセス特権を許可するものであって、そのアクセス特権が前記識別情報に基づいて各資源に対して判定されるものである点において共通している。
　したがって、本願発明と引用発明は以下の点で一致し、また相違している。
　
　（一致点）
　「サーブレットを実行するサーバのセキュリティを確保する方法において、
　サーブレットを送信元コンピュータから受信するステップであって、サーブレットは、サーブレットの安全性を識別する関連付けられた識別情報を有する、ステップと、そして
　サーバによってサーブレットに提供される１つ以上の資源へのアクセス特権を、サーバの検証手段によって、許可するステップであって、そのアクセス特権が前記識別情報に基づいて各資源に対してサーバの検証手段によって判定される、ステップと、
を含む、
ことを特徴とする方法。」
　
　（相違点１）
　前記「識別情報」が、本願発明ではサーブレットのホストを安全に固有に識別する送信元識別子であるのに対し、引用発明では前記「識別情報」が「servletはにせ者ではないことを保証するデジタル署名」である点。
　
　（相違点２）
　アクセス特権を各資源に対して判定するに際し、本願発明では前記判定が個別に判定されるのに対し、引用発明ではファイルの読み書きを許すか否か（すなわち「アクセス特権」）の決定が、ディレクトリ単位で行われる点。
　
　（相違点３）
　本願発明では、１つ以上の資源へのアクセス特権を許可する前にサーブレットのコードおよび関連付けされた前記識別情報を検査してそれらが損なわれていないことを検証手段が確認するのに対し、引用発明ではこれに対応する構成が明記されていない点。
　
　５．当審の判断
　次に、上記相違点の各々について検討する。
　まず、上記相違点１について検討する。
　引用発明の前記デジタル署名が、servletがにせ者ではないことを保証する情報であることは、既に述べたとおりであるが、にせ者でないことを保証する情報として出所を識別する情報を用いることは周知な手法であり、引用発明におけるservletの出所とは、アップロード元のコンピュータであるから、引用発明において前記「デジタル署名」として引用発明のアップロード元のコンピュータを識別する情報を表現するデジタル署名を用いることによって上記相違点１に係る構成とすることは、当業者が容易に想到し得た事項に過ぎない。なお、コンピュータを識別する情報が、該コンピュータを固有に識別可能な情報であることや、デジタル署名がその内容を安全に識別可能なものであることは、当業者にとっての技術常識である。したがって、上記相違点１は格別のものではない。
　
　次に、上記相違点２について検討する。
　引用発明では、上述の如く、ファイルの読み書きを許すか否か（すなわち「アクセス特権」）の決定が、ディレクトリ単位で行われているが、１つのディレクトリの中に格納されている複数のファイル（すなわち「資源」）の各々について、読み書きを許すか否かを個々のファイルごとに個別に決定することは周知技術であり、引用発明において当該周知技術を採用して引用文献のディレクトリ内に存在する個々のファイルごとに個別に読み書きを許すか否かを決定するようにすることは、当業者が容易に想到し得た事項に過ぎない。したがって、上記相違点２も、格別のものではない。
　
　次に、上記相違点３について検討する。
　デジタル署名を受け取った場合に、受け取ったデジタル署名を所定の手順で解析（例えば、署名を行った側が公開している公開鍵を取得して、受け取ったデジタル署名を取得した公開鍵を用いて復号するなど）し、その解析が正しく行えなかった場合にはそのデジタル署名が途中で改ざん等によって損なわれたものであると判断することは周知技術であり、引用発明のデジタル署名においても前記周知技術に基づいた解析を行って、そのデジタル署名が損なわれているか否かを判断することは、正常動作をさせるために当然行わせるべき事項に過ぎない。なお、デジタル署名が損なわれている場合には、そのようなデジタル署名を伴っているservletは信用できないから、そのようなservletを実行させない（したがって、そのようなservletには資源のアクセスも許可されない）ことは、当然のことである。
　また、当審における、平成２０年７月２９日付けで通知した拒絶の理由に引用した本願の優先権主張の日前に頒布された特開平６−１０３０５８号公報の段落［００１２］、［００２７］、［００２８］、［０１０４］、［０１０５］に、
　
「【００１２】この発明は上述のＰＡＩがプログラムそれ自体（またはプログラムのハッシュ）とともに、ユーザが信用するあるエンティティによってディジタル署名され得ることを熟慮する。ディジタル署名がＰＡＩを有効にするために使用された場合、前述のＰＡＩモニタリングはＰＡＩ上のディジタル署名を確証して、それがユーザによって信用されるエンティティに属するものであること、それが適切に権限を付与されていること、およびそれならびにその関連プログラムが手を加えられなかったことを確実にすることを含む。」
　
「【００２７】セグメント２２および２４は「ハッシュ」関連セグメントである。当業者によって理解されるように、「ハッシュ」は「一方向」機能であり、同一の値にハッシュする２つのデータ値を見つけることは計算では実行不可能である。すべての実務的な目的のために、ハッシュ関数をデータのオリジナル集合に適用することから得られた値は、オリジナルデータの偽造不可能な独自の指紋である。もしオリジナルデータが任意の態様で変えられれば、このように変更されたデータのハッシュも同様に異なるであろう。」
　
「【００２８】関連セグメントのハッシングは、この発明に従って適切に権限を付与されたプログラムが後に手を加えられて、変更されたプログラムを結果としてもたらす可能性がないことを確実にする。セグメント２４にプログラムハッシュをストアすることによって、ハッシュは関連プログラムが権限が付与された後に変更されなかったことを保証するために後にチェックされ得る。セグメント２２において、特定のハッシングアルゴリズムを独自に識別する識別子がストアされる。」
　
「【０１０４】他方、それら自身の処置を注意深く確証する呼出されたプログラムでは、呼出されたプログラムにそれを呼出すプログラムより大きい固有の権限を許容することが可能であり得、このように高感度の資源がより広い使用を、信用されたサブプログラムを通してこのような使用を取り次ぐことによって利用可能にされ得る。このような組合わせの可能性は基本的制御システムの設計者によってだけではなく各プログラムへの権限の割当てを行なう者によっても注意深く検討されねばならない。その後、プログラムはロードされ、プログラムのハッシュがプログラムのＰＡＩに特定されるアルゴリズムに基づき計算される。プログラム３１４に戻って、もしシステムが最小の権限省略値を有すると決定されれば、ブロック３２８に示されるように、最小の省略値権限が使用される。このような最小の省略値権限はもしあれば呼出プログラムのＰＡＩと適当に組合わされ、ブロック３２６に関連して上に説明されたように新しいＰＣＢ内に挿入される。ＰＡＩの記憶域はプログラムが一般に変えることができないメモリから割当てられる。その後、記憶域がブロック３２６に関連して上に説明されたようにプログラムについて割当てられ、アドレスがＰＣＢ内に保管される。省略値権限を使用するブロック３２８の処理はプログラムのハッシュの計算を含まず、ルーチンはブロック３３４へ分岐して、プログラム実行に備える。」
　
「【０１０５】ブロック３３０に移って、ブロック３２６の計算されたプログラムハッシュがＰＡＩ内に記憶されるハッシュと一致するか否かを決定するチェックが行なわれる。もしハッシュが一致しなければ、ルーチンはブロック３３２へ分岐し、そこで「プログラムＸが変えられた、または損害を受けた。」というようなエラーメッセージが呼出プログラムへ送られ、ルーチンはブロック４１０へ分岐し、プログラムの実行を抑制する。」
　
と記載されているように、プログラムが改ざん等によって損なわれていないかをハッシュを用いて確認し、改ざん等によって損なわれていることが判明したプログラムを実行しないようにすることは周知技術であり、引用発明のservletに前記周知技術を用いて、改ざん等によってservletが損なわれていないかを確認し、損なわれている場合にはそのservletを実行しないようにすることは、当業者が容易に想到し得た事項に過ぎない（なお、そのように損なわれたservletが実行されないようにした場合には、実行されないservletにはファイル等の資源に対するアクセスが許可されないのは当然のことである）。
　したがって、上記相違点３も格別のものではない。
　
　また、本願発明の構成によって得られる効果も、当業者が予測できる範囲を超えるものではないから、本願発明は引用発明に基づいて当業者が容易に発明できたものである。
　
　６．むすび
　このように、本願発明は引用文献１に記載された引用発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。