【事件の表示】
　特願２００４−　５２３５１「送信システムにおけるデバイスタイプ認証」拒絶査定不服審判事件〔平成１６年１２月　２日出願公開、特開２００４−３４２０８０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１６年２月２６日（パリ条約による優先権主張２００３年２月２８日　欧州特許庁）の出願であって，
　平成１９年２月５日付けで審査請求がなされ，平成２２年５月２７日付けで審査官により拒絶理由が通知され，これに対して平成２２年１０月２１日付けで意見書が提出されると共に手続補正がなされたが，平成２２年１１月４日付けで審査官により拒絶査定がなされ，これに対して平成２３年３月２９日付けで審判請求がなされると共に手続補正がなされ，平成２３年７月１日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２３年９月２９日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２４年２月２４日付けで回答書の提出があったものである。
　
第２．平成２３年３月２９日付けの手続補正の却下の決定
　
　補正却下の決定の結論
　
　平成２３年　３月２９日付け手続補正を却下する。
　
　理由
　
１．補正の内容
　平成２３年３月２９日付けの手続補正（以下，「本件手続補正」という）により，平成２２年１０月２１日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　通信システム（１）に接続された第１のデバイス（２０）において、通信メッセージの第１のヘッダ情報を提供するステップと、
　前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップとを含む、通信システム（１）におけるデバイスタイプの認証方法であって、
　前記第１のヘッダ情報は、前記第１のデバイス（２０）のデバイスタイプ関連コミットメントと関連付けられており、
さらに、
　前記第１のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第１のデバイス（２０）で不正使用防止可能なように第１の署名を作成するステップと、
　前記第１のデバイス（２０）において、前記署名を含む前記通信メッセージの第２のヘッダ情報を提供するステップと、
　前記通信ステップの後に前記第１の署名を検証することにより前記第１のヘッダ情報を認証するステップとを有することを特徴とする方法。
　　【請求項２】
　前記通信システム（１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルに基づくことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記デバイスタイプ関連コミットメントが、デジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記第１のデバイスがユーザ端末（２０）であることを特徴とする請求項１から３のいずれか１項に記載の方法。
　　【請求項５】
　前記第２のデバイスがサーバ（１０）であることを特徴とする請求項１から４のいずれか１項に記載の方法。
　　【請求項６】
　前記デバイスタイプに固有の情報が、前記署名を作成する際に従うアルゴリズムの定義を含むことを特徴とする請求項１または５に記載の方法。
　　【請求項７】
　前記デバイスタイプに固有の情報が、それぞれの特定のデバイスタイプに対し一意であるデータ列を含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
　　【請求項８】
　署名を作成する前記ステップが、時刻、日付、およびヘッダ情報から構成されるグループの内の少なくとも１つの項目にさらに基づくことを特徴とする請求項１から７のいずれか一項に記載の方法。
　　【請求項９】
　認証する前記ステップがさらに、
　前記第２のデバイス（１０）で、前記第１のヘッダ情報に基づく前記第１のデバイスのデバイスタイプを決定するステップと、
　少なくとも前記決定されたデバイスタイプと関連する不正使用防止情報に基づいて前記第２のデバイス（１０）で第２の署名を作成するステップと、前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプを本物であると認めるステップとを含むことを特徴とする請求項１から８のいずれか一項に記載の方法。
　　【請求項１０】
　認証する前記ステップがさらに、
　前記第１のヘッダ情報および前記第１の署名に関する情報を前記第２のデバイス（１０）から前記通信システム（１）に接続された第３のデバイス（５０〜５３）に転送するステップと、
　前記第３のデバイス（５０〜５３）により前記第１のヘッダ情報の真偽の検証を要求するステップと、
　前記第３のデバイス（５０〜５３）の検証で本物と確認されたら前記第１のヘッダ情報を本物として認めるステップとを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
　　【請求項１１】
　前記第３のデバイス（５０〜５３）は、前記第１のデバイス（２０）のメーカーと関連していることを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　通信システム（１）に接続可能な通信デバイス（２０）であって、
通信メッセージの第１のヘッダ情報を供給する手段（２５）と、
　前記通信メッセージを前記通信システム（１）に接続された他のデバイス（１０）に伝送する通信手段（２１）とを備え、
　前記第１のヘッダ情報は前記通信デバイス（２０）のデバイスタイプ関連コミットメントと関連付けられており、
　前記通信デバイスのデバイスタイプに固有の情報（２４）の不正使用防止対策済み記憶装置（２３）と、
　少なくとも前記デバイスタイプに固有の情報（２４）に基づいて第１の署名を作成するように構成された不正使用防止署名作成器（２６）と、前記署名を含む前記通信メッセージの第２のヘッダ情報を供給するための手段（２５）とを特徴とする通信デバイス。
　　【請求項１３】
　前記通信手段（２１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１２に記載の通信デバイス。
　　【請求項１４】
　さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１３に記載の通信デバイス。
　　【請求項１５】
　前記通信デバイスがユーザ端末であることを特徴とする請求項１２から１４のいずれか１項に記載の通信デバイス。
　　【請求項１６】
　通信システム（１）に接続可能な通信デバイス（１０）であって、
前記通信システム（１）に接続された送信デバイスから通信メッセージを受信する通信手段（１１）を備え、
　前記通信メッセージは、前記送信デバイスのデバイスタイプ関連コミットメントに関連付けられた第１のヘッダ情報を含み、
　前記通信メッセージがさらに第１の署名を含む第２のヘッダ情報を含み、
　前記第１の署名を検証するように構成された認証手段（１５）を備えることを特徴とする通信デバイス（１０）。
　　【請求項１７】
　前記認証手段（１５）がさらに、
　前記第１のヘッダ情報に基づいて前記送信デバイスのデバイスタイプを決定する手段と、
　通信デバイスのデバイスタイプに固有な情報の記憶装置（１３）と、
　前記決定されたデバイスタイプに対応するデバイスタイプに固有の情報を取り出すように構成され、前記取り出されたデバイスタイプに固有の情報に基づき第２の署名を作成するようにさらに構成された署名作成器（１６）と、
　前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプは本物であると認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
　　【請求項１８】
　前記認証手段（１５）がさらに、
　前記第１のヘッダ情報および前記第１の署名に関する情報を前記通信システム（１）に接続された他のデバイスに転送する手段と、
　前記他のデバイスにより前記第１のヘッダ情報の真偽の検証を要求する手段と、
　前記他のデバイスの検証で本物と確認されたら前記第１のヘッダ情報を本物として認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
　　【請求項１９】
　前記通信手段（１１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１６から１８のいずれか一項に記載の通信デバイス。
　　【請求項２０】
　さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１９に記載の通信デバイス。
　　【請求項２１】
　前記通信デバイスがサーバ（１０）であることを特徴とする請求項１６から２０のいずれか１項に記載の通信デバイス。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
　
「　【請求項１】
　通信システム（１）に接続された第１のデバイス（２０）において、通信メッセージの第１のヘッダ情報を提供するステップと、
　前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップとを含む、通信システム（１）における特定のデバイスタイプの認証方法であって、
　前記第１のヘッダ情報は、前記第１のデバイス（２０）のデバイスタイプ関連コミットメントと関連付けられており、
　前記デバイスタイプ関連コミットメントは、前記特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントであり、
さらに、
　前記第１のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第１のデバイス（２０）で不正使用防止可能なように第１の署名を作成するステップと、
　前記第１のデバイス（２０）において、前記署名を含む前記通信メッセージの第２のヘッダ情報を提供するステップと、
　前記通信ステップの後に前記第１の署名を検証することにより前記第１のヘッダ情報を認証するステップとを有することを特徴とする方法。
　　【請求項２】
　前記通信システム（１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルに基づくことを特徴とする請求項１に記載の方法。
　　【請求項３】
　前記デバイスタイプ関連コミットメントが、デジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項２に記載の方法。
　　【請求項４】
　前記第１のデバイスがユーザ端末（２０）であることを特徴とする請求項１から３のいずれか１項に記載の方法。
　　【請求項５】
　前記第２のデバイスがサーバ（１０）であることを特徴とする請求項１から４のいずれか１項に記載の方法。
　　【請求項６】
　前記デバイスタイプに固有の情報が、前記署名を作成する際に従うアルゴリズムの定義を含むことを特徴とする請求項１または５に記載の方法。
　　【請求項７】
　前記デバイスタイプに固有の情報が、それぞれの特定のデバイスタイプに対し一意であるデータ列を含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
　　【請求項８】
　署名を作成する前記ステップが、時刻、日付、およびヘッダ情報から構成されるグループの内の少なくとも１つの項目にさらに基づくことを特徴とする請求項１から７のいずれか一項に記載の方法。
　　【請求項９】
　認証する前記ステップがさらに、
　前記第２のデバイス（１０）で、前記第１のヘッダ情報に基づく前記第１のデバイスのデバイスタイプを決定するステップと、
　少なくとも前記決定されたデバイスタイプと関連する不正使用防止情報に基づいて前記第２のデバイス（１０）で第２の署名を作成するステップと、前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプを本物であると認めるステップとを含むことを特徴とする請求項１から８のいずれか一項に記載の方法。
　　【請求項１０】
　認証する前記ステップがさらに、
　前記第１のヘッダ情報および前記第１の署名に関する情報を前記第２のデバイス（１０）から前記通信システム（１）に接続された第３のデバイス（５０〜５３）に転送するステップと、
　前記第３のデバイス（５０〜５３）により前記第１のヘッダ情報の真偽の検証を要求するステップと、
　前記第３のデバイス（５０〜５３）の検証で本物と確認されたら前記第１のヘッダ情報を本物として認めるステップとを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
　　【請求項１１】
　前記第３のデバイス（５０〜５３）は、前記第１のデバイス（２０）のメーカーと関連していることを特徴とする請求項１０に記載の方法。
　　【請求項１２】
　通信システム（１）に接続可能な通信デバイス（２０）であって、
通信メッセージの第１のヘッダ情報を供給する手段（２５）と、
　前記通信メッセージを前記通信システム（１）に接続された他のデバイス（１０）に伝送する通信手段（２１）とを備え、
　前記第１のヘッダ情報は前記通信デバイス（２０）のデバイスタイプ関連コミットメントと関連付けられており、
　前記デバイスタイプ関連コミットメントは、特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントであり、
　前記通信デバイスの前記特定のデバイスタイプに固有の情報（２４）の不正使用防止対策済み記憶装置（２３）と、
　少なくとも前記特定のデバイスタイプに固有の情報（２４）に基づいて第１の署名を作成するように構成された不正使用防止署名作成器（２６）と、前記署名を含む前記通信メッセージの第２のヘッダ情報を供給するための手段（２５）とを特徴とする通信デバイス。
　　【請求項１３】
　前記通信手段（２１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１２に記載の通信デバイス。
　　【請求項１４】
　さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１３に記載の通信デバイス。
　　【請求項１５】
　前記通信デバイスがユーザ端末であることを特徴とする請求項１２から１４のいずれか１項に記載の通信デバイス。
　　【請求項１６】
　通信システム（１）に接続可能な通信デバイス（１０）であって、
前記通信システム（１）に接続された送信デバイスから通信メッセージを受信する通信手段（１１）を備え、
　前記通信メッセージは、前記送信デバイスのデバイスタイプ関連コミットメントに関連付けられた第１のヘッダ情報を含み、
　前記デバイスタイプ関連コミットメントは、特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントであり、
　前記通信メッセージがさらに第１の署名を含む第２のヘッダ情報を含み、
　前記第１の署名を検証するように構成された認証手段（１５）を備えることを特徴とする通信デバイス（１０）。
　　【請求項１７】
　前記認証手段（１５）がさらに、
　前記第１のヘッダ情報に基づいて前記送信デバイスのデバイスタイプを決定する手段と、
　通信デバイスのデバイスタイプに固有な情報の記憶装置（１３）と、
　前記決定されたデバイスタイプに対応するデバイスタイプに固有の情報を取り出すように構成され、前記取り出されたデバイスタイプに固有の情報に基づき第２の署名を作成するようにさらに構成された署名作成器（１６）と、
　前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプは本物であると認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
　　【請求項１８】
　前記認証手段（１５）がさらに、
　前記第１のヘッダ情報および前記第１の署名に関する情報を前記通信システム（１）に接続された他のデバイスに転送する手段と、
　前記他のデバイスにより前記第１のヘッダ情報の真偽の検証を要求する手段と、
　前記他のデバイスの検証で本物と確認されたら前記第１のヘッダ情報を本物として認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
　　【請求項１９】
　前記通信手段（１１）が、ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ　Ｍａｉｌ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１６から１８のいずれか一項に記載の通信デバイス。
　　【請求項２０】
　さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１９に記載の通信デバイス。
　　【請求項２１】
　前記通信デバイスがサーバ（１０）であることを特徴とする請求項１６から２０のいずれか１項に記載の通信デバイス。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
２−１．新規事項
　本件手続補正が，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件手続補正が，願書に最初添付された明細書，特許請求の範囲，及び，図面（以下，これを「当初明細書等」という）に記載した事項の範囲内でなされたものであるかについて，以下に検討する。
　
（１）補正後の請求項１，請求項１１，及び，請求項１６に，
「前記デバイスタイプ関連コミットメントは、前記特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントであり」という記載があるが，
　当初明細書等には，
「前記デバイスタイプ関連コミットメントは、前記特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントであ」るという記載は存在しない。
　そこで，当初明細書等に記載の内容から，
“デバイスタイプ関連コミットメントは、特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントである”ということが，読み取れるか否かについて検討すると，
　当初明細書等には，その段落【００１１】に，
「好ましくは，デバイスタイプ関連コミットメントに関係するヘッダに，更にその署名を付与する」，
　同段落【００２３】に，
「この概念は，さまざまなアプリケーションで使用することも可能であるが，特に，デバイスタイプ関連コミットメントに関連するヘッダ情報の認証に特に適している」，
　同段落【００２４】，及び，【００２５】に，
「【００２４】
　端末が「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｏｍａ．ｄｒｍ．ｍｅｓｓａｇｅ」という部分を含むＨＴＴＰヘッダを送信すると，暗黙のうちに，受信サーバに，端末がＯＭＡ　ＤＲＭ規制に従うことを認めたと通知することになる。同様に，ＨＴＴＰヘッダ情報に「Ｕｓｅｒ-Ａｇｅｎｔ：ＳＥＭ４．６」が含まれていると，端末がＳｏｎｙ-Ｅｒｉｃｓｓｏｎ-Ｍｏｂｉｌｅ　４．６ソフトウェアをベースとしていることを主張することになる。受信サーバはそのようなソフトウェアがＤＲＭをサポートしていることを容易に知ることができ，したがってＵｓｅｒＡｇｅｎｔヘッダは暗黙のうちにＤＲＭに従うというコミットメントになる。さらに，ＨＴＴＰヘッダ「ＵＡＰｒｏｆ：ｗｗｗ．ｓｅｍ．ｃｏｍ／ｐｈｏｎｅｓ／ｔ６８」は暗黙のコミットメントである，というのも，Ｔ６８携帯電話の主張するサポート内容を結論できるからである。
　【００２５】
　本発明によれば，デバイスのサポートする能力を通知するヘッダには端末による署名が入る。その後，サーバは，署名の妥当性を確認し，送信者側が信頼できるデバイスであることを確認することができる。署名を作成する実際のプロセスは，従来技術の原理に従って実行することができる。しかし，ヘッダ情報の署名はまだ使用されたことがない」，
　同段落【００２７】に，
「第１のヘッダ情報を使って，例えば，デバイスタイプ関連コミットメントを定義する。第２のヘッダ情報にその署名を入れる」，
　同段落【００４７】に，
「第１のヘッダ情報は，デバイスタイプ関連コミットメントと関連付けけられている情報を含むのが好ましい」，
　といった，「デバイスタイプ関連コミットメント」，及び，「ヘッダ情報」に関連する記載内容は存在するが，これらの記載には，「デバイスタイプ関連コミットメント」が
，「特定のデバイスタイプのデバイスがサポートする機能についてのコミットメント」であることを示唆するものはなく，これら記載内容を参酌しても，
“デバイスタイプ関連コミットメントは、特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントである”ということが，当初明細書等に記載されていることは読み取れない。
　そして，“デバイスタイプ関連コミットメントは、特定のデバイスタイプのデバイスがサポートする機能についてのコミットメントである”ことが，当初明細書等の記載内容を踏まえることで，当業者にとって自明の事項であるとも認められない。
　よって，本件手続補正は，本願の願書に最初に添付した明細書，特許請求の範囲，及び，図面に記載された事項の範囲内でなされたものではない。
　
３．補正却下むすび
　したがって，本件手続補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成２３年３月２９日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２２年１０月２１日付けの手続補正により補正された，上記「１．補正の内容」において，補正前の請求項１として引用した，次のとおりのものである。
　
「　通信システム（１）に接続された第１のデバイス（２０）において、通信メッセージの第１のヘッダ情報を提供するステップと、
　前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップとを含む、通信システム（１）におけるデバイスタイプの認証方法であって、
　前記第１のヘッダ情報は、前記第１のデバイス（２０）のデバイスタイプ関連コミットメントと関連付けられており、
さらに、
　前記第１のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第１のデバイス（２０）で不正使用防止可能なように第１の署名を作成するステップと、
　前記第１のデバイス（２０）において、前記署名を含む前記通信メッセージの第２のヘッダ情報を提供するステップと、
　前記通信ステップの後に前記第１の署名を検証することにより前記第１のヘッダ情報を認証するステップとを有することを特徴とする方法。」
　
第４．引用刊行物に記載の発明
　原審の拒絶理由に引用された，本願の第１国出願前に既に公知である，国際公開第２００２／０５７８６５号（２００２年７月２５日公開，以下，これを「引用刊行物１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「[0021] An object of the invention is to facilitate the distribution of documents over networks, such as the Internet. One aspect of the invention is a system for distributing digital documents having usage rights associated therewith. The system comprises a server having at least one digital document stored thereon, a client computer having a standard application program including a rendering engine capable of being accessed to render content, a communications network coupled to the client and the server, and a security module adapted to be attached to the standard application program for enforcing security conditions for accessing the rendering engine.」
（［００２１］本発明の目的は，インターネットなどの，ネットワークを介しての，ドキュメントの配布を容易にすることである。本発明の一側面は，ディジタル・ドキュメントと，それに付随する使用権を配布するためのシステムである。システムは，その上に，少なくとも１つのディジタル・ドキュメントを格納するサーバと，コンテンツを表示するためにアクセスすることができるレンダリング・エンジンを含む，通常のアプリケーション・プログラムを有するクライアント・コンピュータと，クライアントとサーバを繋ぐ，通信ネットワークと，レンダリング・エンジンにアクセスするための，セキュリティ状態を実行するために，通常のアプリケーション・プログラムに附加されるよう構成された，セキュリティ・モジュールとを含む。当審にて訳出。以下，同じ。）
　
Ｂ．「[0049] Server 220 has a plurality of documents 222 stored thereon, in the form of Web pages, for distribution. Documents 222 can be stored in an encrypted format. The term encrypted, as used herein, refers to any mechanism by which accessibility of content is partially or completely prohibited, such as by use of asymmetric or symmetric encryption algorithms, scrambling algorithms, or the like. Server 220 also includes digital rights management module 224, in the form of software, for storing and managing usage rights associated with particular ones of documents 222, users, and/or payment amounts or other conditions. Other functions of rights management module 224 are described in greater detail below. Distributor server 220 can be part of a server farm or other group of computers, which can also include distributor server 220' as illustrated in Fig. 2.
 
[0050] Client 230 also has user interface (Ul) module 234 and connection module 236 each in the form of software and each adapted to attach to browser 232 without the need for modification of browser 232. For example, Ul module 234 and connection module 236 can be in the form of plug-ins, ActiveX controls, or in any form that allows attachment to the rendering engine of browser 232 without the need for modifying the code of browser 232. Such attachment is described in greater detail below. In combination, Ul module 234 and connection module 236 constitute a security module which is described in detail below. While security module 237 is illustrated as residing in client computer 230, it will become clear that security module 237 can include client side components and server side components. For example, DRM module 224 described below can be a server side component of security module 237.」
（［００４９］サーバ２２０は，配布するために，ウェブ・ページの形態で，その上に格納された，複数のドキュメント２２２を有している。ドキュメント２２２は，暗号化された形式で格納され得る。“暗号化された”という用語は，ここでは，非対称，あるいは，対称暗号アルゴリズム，スクランブル・アルゴリズム，或いは，それらと同様のものを用いるといったことで，コンテンツのアクセス性を，部分的に，あるいは，完全に禁止するための任意のメカニズムを持ち込むことを意味する。サーバ２２０は，また，ソフトウェアの形態で，ドキュメント２２２，ユーザ，及び／または，支払金額，あるいは，他の条件の，特定の１つに関連する，使用権を格納すること，あるいは，管理することのための，ディジタル権利管理（ＤＲＭ）モジュール２２４を含む。権利管理モジュール２２４の他の機能は，以下に詳細に説明される。配布サーバ２２０は，図２に示されているような，配布サーバ２２０’を同様に含むような，サーバ・ファーム，あるいは，他のコンピュータグループの一部であり得る。
　
［００５０］クライアント２３０は，また，それぞれ，ソフトウェア形態で，それぞれ，ブラウザ２３２の変更を要することなく，ブラウザ２３２に接続されるよう構成された，ユーザ・インタフェース（ＵＩ）モジュール２３４と，結合モジュール２３６を持つ。例えば，ＵＩモジュール２３４と，結合モジュール２３６は，プラグ・イン，アクティブＸ・コントロールの形式，或いは，ブラウザ２３２のコードを変更することを要することなく，ブラウザ２３２のレンダリング・エンジンへの接続を許可する，任意の形式であり得る。このような接続は，以下に詳細に説明される。組み合わせて，ＵＩモジュール２３４と，結合モジュール２３６は，以下に詳細に説明される，セキュリティ・モジュールを構成する。セキュリティ・モジュール２３７は，クライアント・コンピュータ２３０に属するものとして，示されているものの，セキュリティ・モジュール２３７は，クライアント側のコンポーネントと，サーバ側のコンポーネントとを含み得ることは明らかであろう。例えば，以下で説明されているＤＲＭモジュール２２４は，セキュリティ・モジュール２３７の，サーバ側コンポーネントであり得る。）
　
Ｃ．「[0055] Alternatively, connection module 236 can generate a signature and send the signature to server 220 with any URL request to server 220. Access to the Web site on server 220 will only be granted if the signature is present and valid. In this alternative, rights management module 224 can include code to validate the signature.」
（［００５５］代わりに，結合モジュール２３６は，署名を生成し，その署名を，サーバ２２０への，任意のＵＲＬ要求と共に，サーバ２２０へ送信することができる。サーバ２２０上のウェブ・サイトへのアクセスは，署名が，存在し，且つ，承認された場合のみに，許可される。この代替案においては，権利管理モジュール２２４は，署名を認証するためのコードを含むことができる。）
　
Ｄ．「[0063] In the first example, client computer 230 initially does not have all required components of security module 237 installed therein. As illustrated in Fig. 5, client computer 230, makes a request of distributor server 220 for one or more documents 222 in step 502. Distributor server 220 analyzes the request and based on a lack of signature information within the request (indicating that components of security module 237 are not loaded in client computer 230), sends a response to client computer 230 to load the requisite components of security module 237 in step 504. As noted above, security module 237 functions to enforce usage rights in client computer 230. The response sent in step 504 is specific to the type of client requesting the content. If the client software on client computer 230 is a Web browser, for example, distributor server 220 will send a response that is a Web page including an executable software component. For example, the software component can be in a standard form such as Java Script or Active Server Pages. In addition the response, a Web page in the preferred embodiment, can include a copy of the unsigned request for content sent in step 502.」
（［００６３］第１の例においては，クライアント・コンピュータ２３０は，最初は，その中にインストールされている，セキュリティ・モジュール２３７の，全ての要求されたコンポーネントを有していない。図５に示されているように，ステップ５０２において，１つ以上のドキュメント２２２のために，配布サーバ２２０の要求を生成する。ステップ５０４において，配布サーバ２２０は，（セキュリティ・モジュール２３７が，クライアント・コンピュータ２３０にロードされていないことを示す）要求における証明情報の欠落に基づいて，要求を分析し，セキュリティ・モジュール２３７の必要なコンポーネントをロードするための応答を，クライアント・コンピュータ２３０に送る。上で述べたように，セキュリティ・モジュール２３７は，クライアント・コンピュータ２３０において，使用権を実施するために機能する。ステップ５０４において，送られた応答は，そのコンテンツを要求しているクライアントのタイプに特有である。例えば，もし，クライアント・コンピュータ２３０上のクライアント・ソフトウェアが，ウェブ・ブラウザであれば，配布サーバ２２０は，実行可能なソフトウェア・コンポーネントが埋め込まれているウェブ・ページである，応答を送るであろう。例えば，ソフトウェア・コンポーネントは，ジャバ・スクリプト，或いは，アクティブ・サーバ・ページといった，標準的な形式を採る場合がある。その応答に加えて，本発明の好適な実施例においては，ウェブ・ページは，ステップ５０２において送られた，コンテンツための使用要求のコピーが含まれ得る。）
　
Ｅ．「[0096] It is known to embed signatures and other security information in the body of an HTTP document. However, such a practice requires special security tags and is difficult to manage since the security information must be parsed out of the document. However, the method of operation of the preferred embodiment illustrated in Fig. 16 simplifies this operation by using only the header of an HTML document for conveying security information.
 
[0097] In step 1602, browser 232 that is regulated by security module 237 requests document 222 from distributor server 220 and security module 237 opens up a standard HTTP or HTTPS connection to distributor server 220. In step 1604, distributor server 220, functioning as a standard HTTP server, retrieves or builds document 222 for downloading. In particular, digital rights management module 224 or another security module component of distributor server 220 authenticates the requesting client by analyzing security information embedded in the headers of the HTTP request and builds a standard HTTP reply.
 
[0098] In step 1606, distributor server 220 inserts security information into the headers of the HTTP reply. For example, the security information, such as a signature can be an attribute of the Header tag in an HTML document as set forth below:
 Header signatured 3490680486724869 MY BOOK Header/」
（［００９６］ＨＴＴＰドキュメントのボディには，署名と，他のセキュリティ情報が埋め込まれていることが知られている。しかしながら，そのような実行は，特別なセキュリティ・タグを要求し，セキュリティ情報が，ドキュメントから解析されなければならないので，使うことが困難である。一方，図１６において示した，本発明の好適な実施例における，処理の方法は，セキュリティ情報を運ぶために，ＨＴＭＬドキュメントのヘッダのみを用いることで，この処理を簡単にしている。
　
［００９７］ステップ１６０２において，セキュリティ・モジュール２３７によって管理されている，ブラウザ２３２は，配布サーバ２２０から，ドキュメント２２０を要求し，セキュリティ・モジュール２３７は，配布サーバ２２０との，標準ＨＴＴＰによる，あるいは，ＨＴＴＰＳによる接続を開く。ステップ１６０４において，標準ＨＴＴＰサーバとして機能する，配布サーバ２２０は，ダウンロードするためのドキュメント２２２を，捜す，あるいは，構築する。特に，ディジタル権利管理（ＤＲＭ）モジュール２２４，あるいは，配布サーバ２２０の，他のセキュリティ・モジュールは，ＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，要求しているクライアントを認証し，標準ＨＴＴＰリプライを構築する。
　
［００９８］ステップ１６０６において，配布サーバ２２０は，ＨＴＴＰリプライのヘッダに，セキュリティ情報を挿入する。例えば，セキュリティ情報は,下に説明するように，例えば署名などの，ＨＴＭＬドキュメントにおけるヘッダタグの特性であり得る。
　　Header signatured 3490680486724869 MY BOOK Header/）
　
１．上記Ａの「システムは，その上に，少なくとも１つのディジタル・ドキュメントを格納するサーバと，コンテンツを表示するために，アクセスすることができる，レンダリング・エンジンを含む，通常のアプリケーション・プログラムを有するクライアント・コンピュータと，クライアントとサーバを繋ぐ，通信ネットワークと，レンダリング・エンジンにアクセスするための，セキュリティ状態を実行するために，通常のアプリケーション・プログラムに附加されるよう構成された，セキュリティ・モジュールとを含む」という記載から，引用刊行物１には，
“ドキュメントを格納したサーバと，コンテンツにアクセスできるレンダリング・エンジンを含む，アプリケーションを有するクライアント・コンピュータとが，ネットワークを介して接続されたシステム”
　が記載されていることが読み取れる。
　
２．上記Ｂの「サーバ２２０は，配布するために，ウェブ・ページの形態で，その上に格納された，複数のドキュメント２２２を有している」という記載，及び，上記Ｂの「サーバ２２０は，また，ソフトウェアの形態で，ドキュメント２２２，ユーザ，及び／または，支払金額，あるいは，他の条件の，特定の１つに関連する，使用権を格納すること，あるいは，管理することのための，ディジタル権利管理（ＤＲＭ）モジュール２２４を含む」という記載から，引用刊行物１に記載の「サーバ」は，
“複数のドキュメントとＤＲＭモジュールを有する”ことが読み取れ，
　同じく上記Ｂの「クライアント２３０は，また，それぞれ，ソフトウェア形態で，それぞれ，ブラウザ２３２の変更を要することなく，ブラウザ２３２に接続されるよう構成された，ユーザ・インタフェース（ＵＩ）モジュール２３４と，結合モジュール２３６を持つ」という記載，及び，上記Ｂの「ＵＩモジュール２３４と，結合モジュール２３６は，以下に詳細に説明される，セキュリティ・モジュールを構成する。セキュリティ・モジュール２３７は，クライアント・コンピュータ２３０に属するものとして，示されているものの，セキュリティ・モジュール２３７は，クライアント側のコンポーネントと，サーバ側のコンポーネントとを含み得ることは明らかであろう」という記載から，
　引用刊行物１に記載の「クライアント・コンピュータ」は，
“ＵＩモジュールと結合モジュールから構成される，セキュリティ・モジュールを有する”ことが読み取れる。
　
３．上記Ｃの「結合モジュール２３６は，署名を生成し，その署名を，サーバ２２０への，任意のＵＲＬ要求と共に，サーバ２２０へ送信することができる」という記載から，
　引用刊行物１には，
“結合モジュールが，署名を生成し，前記署名を，ＵＲＬ要求と共にサーバに送信する”
　ことが記載されていると読み取れ，
　同じく上記Ｃの「サーバ２２０上のウェブ・サイトへのアクセスは，署名が，存在し，且つ，承認された場合のみに，許可される。この代替案においては，権利管理モジュール２２４は，署名を認証するためのコードを含むことができる」という記載と，上記第４の２．で検討した，“複数のドキュメントとＤＲＭモジュールを有する”ことが読み取れることから，
　引用刊行物１には，
“サーバは，ＤＲＭモジュールに含まれる署名を認証するためのコードを用いて，クライアントから送られてきた要求に，証明が存在し，且つ，認証し得るかを検証する”
　ことが記載されていると読み取れ，
　更に，上記引用の「〜承認された場合のみに，許可される」という記載から，
　上記で検討した，引用刊行物１における“検証する”ことは，
“クライアントから，サーバへのアクセスの可否を判定する”ためのものであることは明らかである。
　
４．上記Ｅの「本発明の好適な実施例における，処理の方法は，セキュリティ情報を運ぶために，ＨＴＭＬドキュメントのヘッダのみを用いることで，この処理を簡単にしている」という記載から，
　引用刊行物１には，
“セキュリティ情報を運ぶためにＨＴＭＬヘッダを用いる”
　ことが記載されていると読み取れる。
　
５．同じく上記Ｅの「ディジタル権利管理（ＤＲＭ）モジュール２２４，あるいは，配布サーバ２２０の，他のセキュリティ・モジュールは，ＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，要求しているクライアントを認証」するという記載から，
　引用刊行物１には，
“サーバのＤＲＭモジュール，あるいは，他のセキュリティ・モジュールが，クライアントから送信されたＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，クライアントを認証する”
　ことが記載されていると読み取れる。
　
６．同じく上記Ｅの「セキュリティ情報は,下に説明するように，例えば署名などの，ＨＴＭＬドキュメントにおけるヘッダタグの特性であり得る。
　　Header signatured 3490680486724869 MY BOOK Header/」という記載，及び，上記第４の３．で検討した，“結合モジュールが，署名を生成し，前記署名を，ＵＲＬ要求と共にサーバに送信する”という事項から，
　引用刊行物１には，
“ヘッダ情報に含まれるセキュリティ情報として，署名を組み入れる”
　ことが記載されていると読み取れる。
　
　以上，第４の１．〜６．において検討した事項から，引用刊行物１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「ドキュメントを格納し，ＤＲＭモジュールを有するサーバと，コンテンツにアクセスできるレンダリング・エンジンを含む，アプリケーションを有し，ＵＩモジュールと結合モジュールから構成される，セキュリティ・モジュールを有するクライアント・コンピュータとが，ネットワークを介して接続されたシステムにおいて，
　前記クライアント・コンピュータが有する前記結合モジュールが，署名を生成し，前記署名を，ヘッダ情報に含まれるセキュリティ情報として組み入れ，ＨＴＴＰリクエストのヘッダに埋め込み，ＵＲＬ要求と共にサーバに送信し，
　サーバのＤＲＭモジュール，あるいは，他のセキュリティ・モジュールが，クライアントから送信されたＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，クライアントを認証し，クライアントからサーバへのアクセスの可否を判定する，認証方法。」
　
第５．本願発明と引用発明との対比
１．引用発明における「サーバ」は，「クライアント・コンピュータ」から，「ＨＴＴＰリクエスト」を受信する側であり，前記「サーバ」，「クライアント・コンピュータ」は，「ネットワーク」を介して接続されていることから，
　引用発明における「サーバ」，「クライアント・コンピュータ」，及び，「ネットワーク」は，“通信システム”を構築しており，前記「クライアント・コンピュータ」から，前記「サーバ」へ「ＨＴＴＰリクエスト」が送信されていることから，前記「サーバ」と，「クライアント・コンピュータ」は，“ＨＴＴＰプロトコルに準拠した通信システム”に接続されるものであることは明らかであるから，
　引用発明における「クライアント・コンピュータ」，「サーバ」，及び，「ＨＴＴＰリクエスト」が，
　本願発明における「通信システムに接続された第１のデバイス」，「通信システムに接続された第２のデバイス」，及び，「通信メッセージ」に相当する。
　
２．引用発明においては，前記「クライアント・コンピュータ」が有する「結合モジュール」が，「署名を生成」し，前記「署名」を，「ＨＴＴＰリクエスト」の「ヘッダ」を埋め込むことによって，“署名の埋め込まれたヘッダ”を有する「ＨＴＴＰリクエスト」を生成することに他ならないから，このとき，引用発明における「結合モジュール」に，「ＨＴＴＰリクエスト」の「ヘッダ」が，上記作業のために提供されていることは明らかであるから，このことと，
　本願発明における「通信システム（１）に接続された第１のデバイスにおいて，通信メッセージの第１のヘッダを提供するステップ」とは，
“通信システムに接続された第１のデバイスにおいて，通信メッセージのヘッダを提供するステップ”である点で共通する。
　
３．引用発明においても，「結合モジュールが，署名を生成し」，該「署名」は，「クライアントからサーバへのアクセスの可否を判定する」ために用いられているから，結果として，「クライアント」における“不正使用を防止する”ことになっていることは，明らかであるので，
　引用発明における「結合モジュールが，署名を生成し」と
　本願発明における「前記第１のデバイスの少なくとも不正使用防止デバイスタイプの固有の情報に基づいて、前記第１のデバイス（２０）での不正使用防止可能なように第１の署名を作成するステップ」とは，
“第１のデバイスで署名を，前記第１のデバイスでの不正使用防止可能なように作成するステップ”である点で共通し,
　引用発明においても，「前記署名を，ヘッダ情報に含まれるセキュリティ情報として組み入れ，ＨＴＴＰリクエストのヘッダに埋め込」んでいるから，
　引用発明における「前記署名を，ヘッダ情報に含まれるセキュリティ情報として組み入れ，ＨＴＴＰリクエストのヘッダに埋め込」むことと，
　本願発明における「前記第１のデバイス（２０）において，前記署名を含む前記通信メッセージの第２のヘッダを提供するステップ」とは，
“通信メッセージに，署名の入ったヘッダを附加するステップ”である点で共通し，
　引用発明における「ＵＲＬ要求と共にサーバに送信し」は，「ＨＴＴＰリクエスト」として送られることは明らかであるから,このことが，
　本願発明における「前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップ」に相当する。
　
４．引用発明において，「サーバのＤＲＭモジュール，あるいは，他のセキュリティ・モジュールが，クライアントから送信されたＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，クライアントを認証」することは，“ヘッダに埋め込まれた署名の検証を行うことで，クライアント・コンピュータから受信したＨＴＴＰリクエストが正当であることを認証する”ことに他ならないから，
　引用発明における「サーバのＤＲＭモジュール，あるいは，他のセキュリティ・モジュールが，クライアントから送信されたＨＴＴＰリクエストのヘッダに埋め込まれたセキュリティ情報を解析することで，クライアントを認証」することと，
　本願発明における「前記通信ステップの後に前記第１の署名を検証することにより第１のヘッダ情報を認証するステップ」とは，
“通信メッセージ受信後に，署名を検証することで，通信メッセージを認証するステップ”である点で共通する。
　そして，引用発明における「認証方法」は，「サーバ」，「クライアント・コンピュータ」，及び，「ネットワーク」から構成される，“通信システム”内での認証であることは明らかであるから,
　引用発明における「認証方法」と，
　本願発明における「通信システム（１）におけるデバイスタイプの認証方法」とは，
“通信システムにおける認証方法”である点で共通する。
　
　以上，第５の１．〜４．で検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　通信システムに接続された第１のデバイスにおいて，通信メッセージのヘッダを提供するステップと，
　前記通信メッセージを前記通信システムに接続された第２のデバイスに伝送するステップとを含む，通信システムにおける認証方法であって，
　前記第１のデバイスで署名を，前記第１のデバイスでの不正使用防止可能なように作成するステップと，
　前記通信メッセージに，前記署名の入ったヘッダを附加するステップと，
　前記通信メッセージ受信後に，署名を検証することで，通信メッセージを認証するステップとを有する，認証方法。
　
［相違点１］
　“提供される通信メッセージのヘッダ”に関して，
　本願発明においては，該ヘッダは，「第１のヘッダ情報」であって，“第１のデバイス（２０）のデバイスタイプ関連コミットメントと関連付けされている”ものであるのに対して，
　引用発明においては，“ＨＴＴＰヘッダ”であって，どのような情報であるか，それ以上は，明確に示されてはいない点。
　
［相違点２］
“通信システムの認証方法”に関して，
　本願発明においては，「通信システム（１）におけるデバイスタイプの認証方法」であるのに対して，
　引用発明においては，「クライアントを認証し，クライアントからサーバへのアクセスの可否を判定する」ものである点。
　
［相違点３］
“第１のデバイスで署名を作成するステップ”に関して，
　本願発明においては，「第１のデバイスの少なくとも不正使用防止デバイスタイプの固有の情報に基づいて，前記第１のデバイスでの不正使用防止可能なように第１の署名を作成する」ものであるのに対して，
　引用発明においては，“クライアントを認証し得るような，署名”を生成することは分かるが，「デバイスタイプの固有の情報に基づいて」，「署名」を生成する点が明確でない点。
　
［相違点４］
“通信メッセージを認証するステップ”に関して，
　本願発明においては，「第１のヘッダ情報を認証するステップ」であるのに対して，
　引用発明においては，“クライアントを認証する”ものである点。
　
第６．当審の判断
１．［相違点１］〜［相違点３］について
　引用発明においても，上記Ｄに引用した記載中に，
「送られた応答は，そのコンテンツを要求しているクライアントのタイプに特有である。例えば，もし，クライアント・コンピュータ２３０上のクライアント・ソフトウェアが，ウェブ・ブラウザであれば，配布サーバ２２０は，実行可能なソフトウェア・コンポーネントが埋め込まれているウェブ・ページである，応答を送るであろう」とあるように，“クライアント・コンピュータからの要求に含まれる情報から，サーバ側は，要求側のタイプを特定する”ことが行われていることは明らかであり，
　また，原審が拒絶査定時に，その備考において，周知技術であることを説明するために引用した，本願の第１国出願前に既に公知である，特表２００３−５０１７１５号公報（２００３年１月１４日公開，以下，「周知文献１」という）に，
　
Ｆ．「  【００１４】
  本発明の他の特徴、目的及び利点については、本文の記述及び図面から、及び請求の範囲から明らかになるであろう。
                            詳細な記述
  ウェブ・サーバのような情報サーバにおける情報要求の処理は、要求を処理するのに必要なデータがプロキシ・サーバに格納され情報サーバへ自動的に転送されるデータ転送機構により容易化され得る。このようなデータ転送機構は、例えば、情報サービス・プロバイダ（ＩＳＰ）或いはオンライン・サービス・プロバイダ（ＯＳＰ）により、提携したウェブ・サイトへユーザについての情報（ユーザ・プロファイル）を自動的に転送するのに用いることができる。図２を参照すると、ユーザ・プロファイルをウェブ・サーバ２０３へ自動的に転送するために、ユーザ・プロファイル情報が最初にプロキシ・サーバ２０２のデータベース２２０に格納される。ＨＴＴＰデータ要求２１１がウェブ・ブラウザ２０１からプロキシ・サーバ２０２により受取られると、データベース２２０からのユーザ・プロファイル情報が、プロキシ・サーバによりウェブ・サーバ２０３へ送られる要求２１２の中に封じ込められる。
プロキシ・サーバ２０２は、要求２１１において受取られるヘッダをユーザ・プロファイル情報を含むＨＴＴＰヘッダに追加することによって、要求２１２にユーザ・プロファイル情報を封じ込める
      【００１５】
  図３Ａ及び図３Ｂは、ＨＴＴＰ要求におけるフィールドを示している。フィールド３００は、クライアント・コンピュータ２０１からの要求２１１におけるフィールドであり、フィールド３５０は、プロキシ・サーバ２０２によりウェブ・サイト２０３へ送られる要求２１２におけるフィールドである。図３Ａ及び図３Ｂにおいて、フィールド３０１−３０３の各々は、ＨＴＴＰフィールド名とこのフィールドと関連する値とを含んでいる。ＨＴＴＰフィールド名は、関連するフィールド値を識別する。例えば、フィールド３０２におけるフィールド名「Ｕｓｅｒ−Ａｇｅｎｔ：」は、要求３００が「Ｍｏｚｉｌｌａ／３．０ｃｏｍｐａｔｉｂｌｅ」ブラウザにおいて生じたことを表わし、フィールド３０３におけるフィールド名「Ｃｏｏｋｉｅ：」は値「ｂｅｅｎ＿ｈｅｒｅ＿ｂｅｆｏｒｅ」がウェブ・クッキーであることを含む。フィールド３００を持つＨＴＴＰ要求２１１がプロキシ・サーバ２０２で受取られると、プロキシ・サーバ２０２は、プロファイル情報を含む別のＨＴＴＰフィールド３０４−３０５を追加することにより、ユーザ・プロファイル情報を要求２１１へ追加することができ、こ
れによりフィールド３０４−３０５に封じ込められたユーザ・プロファイル情報を持つ新たな要求２１２を生成する
　
　と記載されているように，“クライアント側のユーザ・プロファイル情報を要求のヘッダ情報に格納する”こと，即ち，“送信側の個別情報を，送信情報のヘッダに格納する”ことは，当業者にとって，周知の技術事項である。
　また，クライアントからの要求メッセージに，該要求メッセージに含まれる情報に基づいた署名を添付して，サーバに送信することも，例えば，本願の第１国出願前に既に公知である，特開２０００−２３５５２８号公報（２０００年８月２９日公開，以下，「周知文献２」という）に，
　
Ｇ．「【００７１】要求署名生成部２１０は，（シリアル番号，発行日時，有効期限，要求パラメータ）からなる第１の４項組を生成する。この場合の４項組は［数２］の通りとなる。
・・・・・
【００７３】［数２］で示した４項組は，シリアル番号が１，要求の発行日時が世界時で１９９９年１月８日１０時１０分，要求の有効期限が１９９９年１月８日１０時１５分，要求パラメータが”ｈｔｔｐ：／／ｓｅｒｖｅｒ３００／ｏｂｊｅｃｔ３１０｜？ａ＝１”であることを示している。
【００７４】
要求署名生成部２１０は，さらに，この第１の４項組に対してメッセージ・ダイジェスト関数を適用し，クライアント中継部２００が持つ公開鍵暗号系の秘密鍵ｓｅｃｒｅｔｋｅｙ１を用いて，第１の電子署名を生成する
【００７５】次いで，
要求署名生成部２１０は，要求パラメータと第１の４項組と署名”ｓｉｇｎａｔｕｒｅ１”を送受信部２３０に出力する
【００７６】送受信部２３０は，
第１の４項組と要求パラメータを元に，［数３］に示すような第２の要求メッセージを，ネットワーク１０上に送信する
　と記載されてもいるように，当業者には周知の技術事項であり，
　端末において，端末固有の情報（本願発明における「デバイスタイプの固有の情報」に相当）と，該端末固有の情報から生成した認証情報とを，送信先に送信することも，例えば，本願の第１国出願前に既に公知である，特開２００２−０６３１３９号公報（２００２年２月２８日公開，以下，「周知文献３」という）に，
　
Ｈ．「【０００８】
【課題を解決するための手段】上記目的を達成するために，本発明に係る端末装置は，サーバからサービスを受ける際，サーバから正規の端末装置であることを認証される端末装置であって，個々の端末に固有の端末固有情報を保持する端末固有情報保持手段と，全ての端末に共通の共通秘密情報を用いて前記端末固有情報を暗号化した，暗号化端末固有情報を保持する暗号化端末固有情報保持手段と，前記暗号化端末情報をさらに暗号化し，端末認証情報を出力する暗号化手段と，
端末の認証のために，前記端末固有情報と端末認証情報を組にしてサーバに送信する認証情報送信手段とを備える
　
　と記載されてもいるように，当業者には周知の技術事項であって，このとき，端末固有の情報に代えて，デバイスタイプといった他の情報を用いることは，システムの使用者の選択事項に過ぎないので，
　引用発明において，要求メッセージのヘッダに附加する情報として，アプリケーションのタイプ情報に代えて，クライアント・コンピュータの情報を用い，該クライアント・コンピュータから署名を生成し，該署名を前記ヘッダに加えて，サーバに送信するよう構成することは，引用発明，及び，上記で指摘の周知技術から，当業者が容易になし得るものである。よって，相違点１〜相違点３は，格別のものではない。
　
２．［相違点４］について
　引用発明においても，クライアントを認証するということは，要求メッセージに付与された署名が正しいかを検証していることは明らかであり，
　また，サーバ側で送られてきた要求メッセージに含まれる情報から署名を生成し，サーバの生成した署名と，該要求メッセージに添付された署名とを比較することで署名検証を行うようなことは，上記Ｇで引用した周知文献２の記載内容，及び，周知文献２の，
　
Ｉ．「【００８６】（７）
要求メッセージ解析部３５０は，第１の電子署名ｓｉｇｎａｔｕｒｅ１が第１のケイパビリティの正しい署名であるか否かを検査する
　
　という記載から，当業者においては周知の技術事項であり，
　また，該サーバ側において，受信した端末固有の情報から認証情報を生成し，サーバ側において生成した認証情報と，サーバ側が受信した認証情報とを比較することで，端末の認証を行うことも，周知文献３に，
　
Ｊ．「【００１３】また，上記目的を達成するために，本発明に係るサーバ装置は，サービスを提供する際，提供先端末の認証を行うサーバ装置であって，端末の認証のために端末から送信されてくる端末固有情報と端末認証情報の組を受信する認証情報受信手段と，端末において保持する暗号化端末固有情報を生成するために使用される共通秘密情報に対応した共通検証鍵情報を保持する共通検証鍵情報保持手段と，前記端末認証情報に対して，
端末装置で前記端末認証情報を生成した暗号処理に対応する復号処理を行い第１の比較値を生成する復号手段と，前記共通検証鍵情報を用い前記端末固有情報と前記第１の比較値を処理することによって，前記認証情報受信手段で受信した各情報の組が正しい組み合わせかどうかを判定する端末認証手段
　と記載されてもいるように，当業者にとって周知の技術事項であるから，結果として，サーバ側において，送信されてきた情報を，該情報に附加された署名によって認証することは，当業者に周知の技術事項である。
　よって，引用発明においても，サーバにおいて，受信したメッセージのヘッダに含まれる情報を，該ヘッダに含まれる署名によって検証することは，当業者が適宜なし得る事項である。
　よって，相違点４は，格別のものではない。
　
　上記で検討したごとく，相違点１〜４はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
第７．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。