【事件の表示】
　特願２０１６−５４２８９０「鍵を有するリソースロケーター」拒絶査定不服審判事件〔平成２７年　４月　２日国際公開，ＷＯ２０１５／０４８０３９，平成２８年　９月２９日国内公表，特表２０１６−５３０８５０〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１．手続の経緯
　本願は，２０１４年９月２３日（パリ条約による優先権主張外国庁受理２０１３年９月２５日　アメリカ合衆国）を国際出願日とする出願であって，
　平成２８年３月１５日付けで特許法第１８４条の４第１項の規定による明細書，請求の範囲，及び，図面（図面の中の説明に限る）の日本語による翻訳文が提出され，同日付けで審査請求がなされると共に手続補正がなされ，平成２９年２月２日付けで審査官により拒絶理由が通知され，これに対して平成２９年６月３０日付けで意見書が提出されると共に手続補正がなされたが，平成２９年１１月１３日付けで審査官により拒絶査定がなされ（謄本送達；平成２９年１２月１８日），これに対して平成３０年４月１７日付けで審判請求がなされると共に手続補正がなされ，平成３０年６月７日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされたものである。
　
第２．平成３０年４月１７日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成３０年４月１７日付け手続補正を却下する。
　
　［理由］
　
１．補正の内容
　平成３０年４月１７日付けの手続補正（以下，「本件手続補正」という）により，平成２９年６月３０日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む，受け取らせることと，
　前記認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を使用して１つまたは複数の動作を行わせることと，
　前記行った１つまたは複数の動作の結果を提供させることと，を行わせる，
　システム。
　　【請求項２】
　前記予め生成された一部分は，ユニフォームリソースロケータとしてフォーマットされる，請求項１に記載の前記システム。
　　【請求項３】
　前記１つまたは複数の動作は，暗号化された形態で前記第１のエンティティによって記憶されるデータにアクセスし，前記暗号化鍵を使用して前記データを解読することを含み，
　前記結果を提供することは，前記要求側に前記解読したデータを伝送することを含む，請求項１に記載の前記システム。
　　【請求項４】
　前記要求はさらに，前記予め生成された一部分に加えられたデータを含み，
　前記暗号化鍵を使用して前記１つまたは複数の動作を行うことは，前記予め生成された一部分に加えられた前記データに対して１つまたは複数の暗号化動作を行うことを含む，請求項１に記載の前記システム。
　　【請求項５】
　前記認可情報は，前記要求側がアクセスできない秘密情報を使用して生成される電子署名を含む，請求項１に記載の前記システム。
　　【請求項６】
　前記認可情報は，前記要求を提出するためのコンテキストに対して１つまたは複数の条件を指定し，
前記暗号化鍵を使用して１つまたは複数の動作を行うことはさらに，前記１つまたは複数の条件を遵守して前記要求を受け取ることを条件として行われる，請求項１に記載の前記システム。
　　【請求項７】
　前記１つまたは複数の条件は，前記要求を満たすことができる継続時間を定義する，請求項６に記載の前記システム。
　　【請求項８】
　前記認可情報は，前記暗号化鍵に少なくとも部分的に基づいて生成される電子署名を含み，
　前記第１のエンティティによる認可を示す前記認可情報は，前記電子署名が有効であることを必要とする，請求項１に記載の前記システム。
　　【請求項９】
　前記システムはさらに，前記要求側と，前記要求側と異なる顧客システムとを備え，
　前記顧客システムは，前記要求を提出する際に使用するための前記要求の表現を提供し，それによって，前記要求を前記要求側から受け取ることを可能にする，請求項１に記載の前記システム。
　　【請求項１０】
　方法であって，
　要求及び暗号化鍵を符号化する情報を生成することと，
　前記要求を満たすことができるサービスプロバイダによって検証できる情報の電子署名を生成することと，
　前記情報及び電子署名を前記サービスプロバイダに提供することを可能にして，前記サービスプロバイダに前記暗号化鍵を使用させて前記要求を満たすために，前記情報及び前記電子署名を利用できるようにすることと，
　を含む，方法。
　　【請求項１１】
　前記情報及び前記電子署名を利用できるようにすることは，前記情報及び前記電子署名を含むユニフォームリソースロケータを生成することを含む，請求項１０に記載の前記方法。
　　【請求項１２】
　前記情報及び前記電子署名を利用できるようにすることは，選択可能な要素で構成されるウェブページを提供することを含み，該選択可能な要素は，選択されたときに，前記情報及び電子署名を含む前記要求を前記サービスプロバイダに伝送させる，請求項１０に記載の前記方法。
　　【請求項１３】
　前記情報はさらに，前記サービスプロバイダによってホストされるリソースの識別子を符号化し，
　前記要求は，前記リソースと関連して行われる１つまたは複数の動作を指定する，請求項１０に記載の前記方法。
　　【請求項１４】
　前記情報は，前記要求を前記サービスプロバイダによって満たすことができるようにするための，前記要求の提出に対する１つまたは複数の条件を符号化する，請求項１０に記載の前記方法。
　　【請求項１５】
　前記情報は，前記要求をどのように満たすのかという様式を符号化し，前記様式は，前記要求を満たすことができる複数の様式からのものである，請求項１０に記載の前記方法。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び前記第１のエンティティによって生成された暗号化鍵を含む予め生成された一部分を含む，受け取らせることと，
　前記認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を要求して１つまたは複数の動作を行わせることと，
　前記行った１つまたは複数の動作の結果を提供させることと，を行わせる，
　システム。
　　【請求項２】
　前記予め生成された一部分は，ユニフォームリソースロケータとしてフォーマットされる，請求項１に記載の前記システム。
　　【請求項３】
　前記１つまたは複数の動作は，暗号化された形態で前記第１のエンティティによって記憶されるデータにアクセスし，前記暗号化鍵を使用して前記データを解読することを含み，
　前記結果を提供することは，前記要求側に解読した前記データを伝送することを含む，請求項１に記載の前記システム。
　　【請求項４】
　前記要求はさらに，前記予め生成された一部分に加えられたデータを含み，
　前記暗号化鍵を使用して前記１つまたは複数の動作を行うことは，前記予め生成された一部分に加えられた前記データに対して１つまたは複数の暗号化動作を行うことを含む，請求項１に記載の前記システム。
　　【請求項５】
　前記認可情報は，前記要求側がアクセスできない秘密情報を使用して生成される電子署名を含む，請求項１に記載の前記システム。
　　【請求項６】
　前記認可情報は，前記要求を提出するためのコンテキストに対して１つまたは複数の条件を指定し，
前記暗号化鍵を使用して１つまたは複数の動作を行うことはさらに，前記１つまたは複数の条件を遵守して前記要求を受け取ることを条件として行われる，請求項１に記載の前記システム。
　　【請求項７】
　前記１つまたは複数の条件は，前記要求を満たすことができる継続時間を定義する，請求項６に記載の前記システム。
　　【請求項８】
　前記認可情報は，前記暗号化鍵に少なくとも部分的に基づいて生成される電子署名を含み，
　前記第１のエンティティによる認可を示す前記認可情報は，前記電子署名が有効であることを必要とする，請求項１に記載の前記システム。
　　【請求項９】
　前記システムはさらに，前記要求側と，前記要求側と異なる顧客システムとを備え，
　前記顧客システムは，前記要求を提出する際に使用するための前記要求の表現を提供し，それによって，前記要求を前記要求側から受け取ることを可能にする，請求項１に記載の前記システム。
　　【請求項１０】
　方法であって，
　要求及び暗号化鍵を符号化する情報を生成することと，
　前記要求を満たすことができるサービスプロバイダによって検証できる情報の電子署名を生成することと，
　前記情報及び前記電子署名を前記サービスプロバイダに提供することを可能にして，前記サービスプロバイダに前記暗号化鍵を使用させて前記要求を満たすために，前記情報及び前記電子署名を利用できるようにすることと，
　を含む，方法。
　　【請求項１１】
　前記情報及び前記電子署名を利用できるようにすることは，前記情報及び前記電子署名を含むユニフォームリソースロケータを生成することを含む，請求項１０に記載の前記方法。
　　【請求項１２】
　前記情報及び前記電子署名を利用できるようにすることは，選択可能な要素で構成されるウェブページを提供することを含み，該選択可能な要素は，選択されたときに，前記情報及び電子署名を含む前記要求を前記サービスプロバイダに伝送させる，請求項１０に記載の前記方法。
　　【請求項１３】
　前記情報はさらに，前記サービスプロバイダによってホストされるリソースの識別子を符号化し，
　前記要求は，前記リソースと関連して行われる１つまたは複数の動作を指定する，請求項１０に記載の前記方法。
　　【請求項１４】
　前記情報は，前記要求を前記サービスプロバイダによって満たすことができるようにするための，前記要求の提出に対する１つまたは複数の条件を符号化する，請求項１０に記載の前記方法。
　　【請求項１５】
　前記情報は，前記要求をどのように満たすのかという様式を符号化し，前記様式は，前記要求を満たすことができる複数の様式からのものである，請求項１０に記載の前記方法。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
（１）補正事項
　本件手続補正は，補正前の請求項１に記載された，発明特定事項である「暗号化鍵」に対して，「第１のエンティティによって生成された」という限定事項を付加し（以下，これを「補正事項１」という），
　補正前の請求項１の，
「前記認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を使用して１つまたは複数の動作を行わせること」，
　という記載を，
「前記認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を要求して１つまたは複数の動作を行わせること」，
　と補正し（以下，これを「補正事項２」という），
　補正前の請求項３の，
「前記要求側に前記解読したデータを伝送する」，
　という記載を，
「前記要求側に解読した前記データを伝送する」，
　と補正する（以下，これを「補正事項３」という）ものである。
　
（２）新規事項についての当審の判断
　本件手続補正が，特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものであるか否か，即ち，本件手続補正が，平成２８年３月１５日付けで提出された明細書，請求の範囲の日本語による翻訳文，及び，国際出願の願書に添付した図面に記載した事項（以下，これを「当初明細書等」という）の範囲内でなされたものであるかについて，以下に検討する。
　
ア．補正事項１について
　当初明細書等には，「第１のエンティティによって生成された暗号化鍵」は記載されていない。
　そこで，当初明細書等の記載から，上記指摘の構成が読み取れるかについて検討すると，
　当初明細書等には，段落【００２０】に，
「図１で例示されるように，ＵＲＬ１０６はまた，暗号化鍵１１４も含み得る。暗号化鍵１１４は，顧客１０２がアクセスを有する暗号化鍵であり得る」，
　同じく，段落【００２０】に，
「暗号化鍵１１４は，ＵＲＬに含まれ得，別の鍵の下で暗号化される形態で対称鍵がＵＲＬ１０６に含まれ得，ここで，他の鍵は，種々の実施形態に従って変化し得るが，全般的に，サードパーティ１０８からＵＲＬ１０６を受け取った時点で，サービスプロバイダ１０４がそれ自体で，または別のサービス，例えば別のサードパーティのサービスを使用して，暗号化鍵１１４を使用するために解読することができるような鍵である」，
　同じく，段落【００２０】に，
「サードパーティ１０８は，顧客１０２によって提供される暗号化鍵１１４を使用して，サービスプロバイダ１０４のサービスを利用することができる」，
　段落【００２１】に，
「暗号化鍵１１４をサードパーティ１０８へのＵＲＬ１０６に含めることによって，サードパーティ１０８は，サービスプロバイダ１０４が，暗号化鍵１１４を使用して，顧客１０２によってデータ記憶サービスに記憶したデータを解読することを可能にするために，ＵＲＬ１０６を使用して要求をサービスプロバイダ１０４に提出することができる」，
　段落【００３３】に，
「暗号化動作は，ＵＲＬの署名済部分の中の鍵（顧客によって供給される），及びＵＲＬの未署名部分の中の鍵（サードパーティによって供給される）の双方を使用して行われ得る」，
　段落【００４６】に，
「ＵＲＬにおいて鍵を供給した顧客」，
　段落【００４７】に，
「顧客が，プロバイダによってラップ解除できる（利用できる）ように暗号化秘密をラップすることを含む」，
　同じく，段落【００４７】に，
「全般的に，本開示の変形例は，プロバイダが暗号化秘密自体をラップ解除するのではなく，プロバイダの代わりに暗号化秘密をラップ解除する別のシステム（例えば，サードパーティのシステム）を有する」，
　段落【００４８】に，
「顧客は，ラップした秘密を有するＵＲＬを構築し得る」，
　と記載されている。
　ここで，段落【００３６】に，
「サードパーティは，例えば，上で説明されるようなプロセス５００を行うエンティティの顧客であり得る」，
　と記載されていることから，請求項１に記載の「第１のエンティティ」とは，当初明細書等の上記引用の段落における「ＵＲＬ１０６」等を提供する「顧客１０２」等であることから，上記引用の各段落の記載内容から，「第１のエンティティ」である「顧客１０２」が，「暗号化鍵」を「ＵＲＬ１０６」に組み込むために提供することは，読み取れる。
　しかしながら，当初明細書等は，「顧客１０２」が，「暗号化鍵」を生成することは記載されておらず，上記引用の記載を検討しても，「顧客１０２」が，「暗号鍵」生成すること，即ち，「第１のエンティティによって生成された暗号化鍵」を読み取ることはできない。
　このことは，「第１のエンティティ」を，当初明細書等に記載の「サードパーティ」，及び，「顧客１０２」であると解しても同じである。
　
イ．補正事項２について
　当初明細書等には，補正事項２における，特に，
「暗号化鍵を要求して１つまたは複数の動作を行わせること」，
　は記載されていない。
　補正事項２における上記指摘の点が，当初明細書等から読み取れるかについて検討すると，上記ア．において引用した記載の他，段落【０００４】に，
「要求を満たす際に使用される暗号化鍵を含むために，要求が予め生成される。要求は，ユニフォームリソースロケータの中に符号化され得，また，要求が提出されるサービスプロバイダが，要求が認可されたかどうかを判定することを可能にするために，認証情報を含み得る。要求は，種々のエンティティに渡され得，次いで，エンティティは，該要求をサービスプロバイダに提出することができる。サービスプロバイダは，要求を受け取ると，認証情報を検証し，要求の中に符号化された暗号化鍵を使用して要求を満たすことができる」，
　段落【０００９】に，
「顧客は，予め署名したＵＲＬを利用し得る。予め署名したＵＲＬを生成するために，顧客は，ＵＲＬ（または全般的に，要求）及び該ＵＲＬの一部分の電子（デジタル）署名を生成し得る。電子署名を生成するために使用されるＵＲＬの一部分は，要求を処理する際に使用される暗号化鍵を含み得る。暗号化鍵は，種々の形態で提供され得る。例えば，暗号化鍵は，サービスプロバイダが要求を満たすためにその鍵を使用して１つまたは複数の暗号化動作を行って解読することができる，または解読した方法で解読される，プレーンテキスト対称鍵，公開鍵−秘密鍵対のうちのプレーンテキスト公開鍵，または対称鍵であり得る」，
　段落【００１０】に，
「ＵＲＬは，要求，暗号化鍵，及び要求を検証するために使用できる認証情報（例えば，電子署名）を含み得る認可情報を符号化するように構成され得る」，
　段落【００１２】に，
「要求を受け取ると，サービスプロバイダは，要求を満たすかどうかを判定するために，電子署名の有効性を確認し得る。他の動作は，要求を満たすことが，任煮の適用可能なポリシーを遵守するかどうか，及び／または要求に符号化される（例えば，認可情報の一部として符号化される）１つまたは複数のパラメータ（例えば，有効期限）を遵守するかどうかを判定する等の，要求を満たすかどうかを判定する際に行われ得る。サービスプロバイダが満たすことができるとみなされる要求の場合，サービスプロバイダは，該要求から暗号化鍵を抽出し，（該当する場合は）抽出した暗号化鍵を解読し，そして，要求を満たす際に関与する１つまたは複数の動作を行い得る。要求が満たされたという肯定応答，及び／または１つまたは複数の動作を行った結果（例えば，要求の中に提供された鍵を使用して解読したデータ）等の，顧客に対する応答が提供され得る」，
　段落【００１９】に，
「サービスプロバイダ１０４が，ＵＲＬ１０６を使用してサードパーティ１０８によってサービスプロバイダ１０４に提出された要求をどのように満たすか，及び／または要求を満たすかどうかを判定することを可能にするために，種々の情報がＵＲＬに含まれ得る。例えば，図１で例示されるように，ＵＲＬ１０６は，電子署名１１０を含み，該電子署名は，顧客１０２に対応する署名検証鍵１１２へのアクセスを有することによって，サービスプロバイダ１０４によって検証することができる」，
　段落【００２６】に，
「例えば，データを記憶する要求にＵＲＬ２０４が含まれる場合，顧客インターフェースは，ＵＲＬ２０４に提供される鍵２１６を利用して，データ記憶システム２１４のうちの１つまたは複数に記憶するために，データを暗号化し，暗号化したデータ２１０を要求処理インフラストラクチャ２１２に伝送し得る」，
　段落【００２７】に，
「同様に，要求が，データを取り出す要求である場合，顧客インターフェース２０２は，データ記憶システム２１４のうちの１つまたは複数からのデータを顧客インターフェース２０２に提供することを可能にする通信を，要求処理インフラストラクチャ２１２に伝送し得る。次いで，顧客インターフェース２０２は，ＵＲＬ２０４に提供される鍵２１６を使用して，暗号化されたデータ２１０を解読し，解読したデータを，要求を提出した顧客に提供し得る」，
　段落【００４２】に，
「全般的に，要求において提供される暗号化鍵を使用して行われる暗号化動作に応じて，７０６で取得した結果は，変動し得る」，
　段落【００４４】に，
「しかしながら，８０６で，署名が有効であると判定された場合，プロセス８００は，８１０で，８０２で受け取ったＵＲＬから暗号化鍵を抽出することを含み得る。抽出した暗号化鍵は，８１２で，要求を処理する（すなわち，満たす）ために使用され得る」，
　段落【００４９】に，
「プロバイダは，要求を検証すると，暗号化鍵を解読するために適切な暗号化アルゴリズムを行うことによって（または別様には，行わせることによって），暗号化秘密をラップ解除し得る。次いで，９１２で，暗号化鍵を使用して要求を処理し得，９１４で，プロバイダは，プロバイダが行った１つまたは複数の暗号化動作を行った結果，及び／または該暗号化動作を行ったことの肯定応答を提供する等で，サードパーティの要求に応答し得る」，
　と記載されていて，上記において引用した，当初明細書等の記載から，当初明細書等においては，「要求」とは，「顧客」，或いは，「サービスプロバイダ」に対して行うものであり，署名検証用でない，「暗号化鍵」は，「サービスプロバイダ」に対して「要求」を行うために用いられる「ＵＲＬ」に含まれるものであって，同じく，「ＵＲＬ」に含まれる「署名」を，「サービスプロバイダ」において検証し，当該検証が正当である場合に，使用可能になるものである。
　したがって，上記引用の当初明細書等の記載を検討しても，補正事項２における，
「暗号化鍵を要求して１つまたは複数の動作を行わせること」，
　を読み取ることはできない。
　
ウ．新規事項むすび
　以上，ア．，及び，イ．において検討したとおりであるから，補正事項１，及び，補正事項２は，当初明細書等に記載されたものではなく，
　本件手続補正は，当初明細書等の記載の範囲内でなされたものではない。
　
３．補正却下むすび
　したがって，本件手続補正は，特許法１８４条の１２第２項により読み替える同法１７条の２第３項の規定に違反するので，同法１５９条１項において読み替えて準用する同法５３条１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成３０年４月１７日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２９年６月３０日付けの手続補正により補正された特許請求の範囲の請求項１に記載された，上記「第２．平成３０年４月１７日付けの手続補正の却下の決定」の「１．補正の内容」において，補正前の請求項１として引用した，次のとおりのものである。
　
「システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む，受け取らせることと，
　前記認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を使用して１つまたは複数の動作を行わせることと，
　前記行った１つまたは複数の動作の結果を提供させることと，を行わせる，
　システム。」
　
第４．原審拒絶査定
　原審における平成２９年１１月１３日付けの拒絶査定は，次のとおりである。
「●理由１（特許法第２９条第２項）について
・請求項　１−１５
・引用文献等　１−３
　拒絶理由のとおりである。引用文献１−３はいずれもＵＲＬを用いたアクセスに関する技術なのだから，引用文献１に引用文献２−３の技術を適用することは当業者が容易になしえたことである。
　出願人の意見書での主張は，要するに引用文献１には本願と同一の課題が記載されていないから，引用文献１−３を組み合わせることはできないというものであるが，拒絶理由のとおりの理由で，引用文献１−３の組み合わせは容易であるから，意見書の主張は採用しない。（同一の課題が記載されていなければ，進歩性を否定できないというものではなく，上記のとおりの理由で，引用文献１−３を組み合わせる理由は十分に存在している。）
　補正後の請求項１−１５は，依然として引用文献１−３の記載から当業者が容易に想到することができたものである。
　　　　　　　　　　　＜引用文献等一覧＞
１．特開２００６−１２８８７３号公報
２．米国特許出願公開第２０１３／０２４７２１８号明細書
３．米国特許出願公開第２００２／００８３１７８号明細書」
　
第５．引用文献に記載の事項及び発明
１．引用文献に記載の事項
（１）原審における平成２９年２月２日付けの拒絶理由（以下，これを「原審拒絶理由」という）において引用された，本願の第１国出願前に既に公知である，特開２００６−１２８８７３号公報（２００６年５月１８日公開，以下，これを「引用文献１」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【００４７】
　ＳＴ１４３では，クライアント１０２が仲介サーバ１０１の固定アドレスにアクセスし，サービス提供サーバ１０３への接続要求を通知し，ＳＴ１４４では，仲介サーバ１０１がサービスメニュー又はユーザの要望に応じたアクセス制限情報をＵＲＬパラメータとして図５に示すＡ１部分のＵＲＬに付加し，共通鍵Ｋｃを用いて認証コードを生成し，認証コードを図５に示すＡ３部分に付加する。
【００４８】
　ＳＴ１４５では，仲介サーバ１０１がパスワード等の所望のクライアント認証を行った後，ＯＴＵにてサービス提供サーバ１０３への接続方法をクライアント１０２に通知する。このとき，ＯＴＵの通知方法は，予め仲介サーバ１０１が把握するクライアント１０２のメールアドレス宛に電子メールで通知してもよいし，ＨＴＴＰプロトコル上でＨＴＭＬページ上の情報として通知してもよい。
【００４９】
　ＳＴ１４６では，仲介サーバ１０１から通知されたＯＴＵをクライアント１０２が辿ることにより，サービス提供サーバ１０３に接続する。通常，この接続はウェブブラウザ又はメーラ上でＵＲＬリンク部分をクリックするだけの簡便なユーザインタフェースにより実現される。
【００５０】
　ＳＴ１４７では，サービス提供サーバ１０３がクライアント１０２から提示されたＯＴＵの認証コード部分を共通鍵Ｋｃで検証することにより，ＯＴＵの正当性を確認し，ＳＴ１４８では，クライアント１０２が所望するサービス提供サーバ１０３へのＨＴＴＰアクセスを実現する。」
　
Ｂ．「【００６６】
　このように実施の形態２によれば，サービス提供サーバとは異なる別の仲介サーバを設け，仲介サーバがサービス提供サーバから定期的に取得したアドレス情報に対して共通鍵でハッシュ演算を行い，公開鍵暗号方式に利用可能な鍵対の一方である秘密鍵を用いてハッシュ演算結果を暗号化処理してＯＴＵ用の認証コードを生成し，サービス提供サーバは，仲介サーバと共有する共通鍵を用いてＯＴＵの認証コード以外の部分に対してハッシュ演算を行うと共に，仲介サーバが暗号化処理に用いた秘密鍵と鍵対をなす公開鍵を用いて認証コードを復号化処理し，ハッシュ演算結果と復号化処理結果とを比較して認証コードの正当性を確認することにより，ＯＴＵの発行者とＯＴＵの受付者が物理的に異なる場合でも，ＯＴＵの偽造又は改竄による不正アクセスを防止することができる。」
　
（２）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，米国特許出願公開第２０１３／０２４７２１８号明細書（２０１３年９月１９日公開，以下，これを「引用文献２」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｃ．「[0052]　Alternatively the URL 620 encoded in the machine readable code 501 may specify additional meta information rather than have it tunable on the system such as code expiry etc. As shown in  FIG.6, the URL 620 presented here has these following features, including but not limited to:
　[0053]　Document issuer/creator id 621, which identifies who has requested this copy of the document with this particular machine code.
　[0054]　A Record id 622, which points to meta information on the SDVS 104 for this particular machine code, which includes, but not limited to, the who is authorized to verify this document, its expiry and the like.
　[0055]　An expiry date 623 which is part of the cryptographic hash 624 so that it can be verified that it has not been tampered with.
　[0056]　A cryptographic hash 624 of the parameters above with the shared secret key (as determined by the record id 622 on the system). This helps to ascertain the data integrity as well as the authenticity of the URL message. Such examples of URL hashes are well known to those familiar with the art. Examples include, but not limited to Hash-based Message Authentication Code (HMAC) and the like. Any cryptographic hash function could be used such as MD-5 and SHA-1.
　[0057]　If the file and/or document information stored is encrypted, an embedded decryption key and algorithm 625 could optionally be specified. This is used by the SDVS 104 to extract the decryption key and the algorithm to be used to decrypt the file and/or information on the system when presenting the stored unencoded document, encoded document and/or document information for verification. This method provides a unique encryption key for each document and/or document information stored on the system thereby enhancing security as the system need not be aware of the method and key used. Various encryption methods could be used, including but not limited to for example AES, Blowfish and the other popular methods.
　[0058]　The document file name 626.」
（［００５２］　別法として，マシン可読コード５０１内に符号化されたＵＲＬ６２０は，コードの有効期限などのような，システム上の調整可能な情報を持つよりも，むしろ，附加的なメタ情報を指定し得る。図６に示すように，ここで示されるＵＲＬ６２０は，含むが，限定されない，これらの以下の機能を有する；
　［００５３］　ドキュメントの発行者／生成者のｉｄ６２１，それは，この特別なマシン・コードと共に，そのドキュメントの，このコピーを要求される者を識別する。
　［００５４］　レコードｉｄ６２２，それは，ドキュメント，その有効期限，および，同等のものを検証するために，許可される者を含むが，それに限定されない，この特別なマシン・コードのための，ＳＤＶＳ１０４上の，メタ情報を指し示す。
　［００５５］　有効期限６２３は，暗号化ハッシュ６２４の一部である，それ故，改変されていないかを検証することができる。
　［００５６］　（システム上のレコードｉｄ６２２によって決定されるような）共有鍵による，上記パラメータの暗号化ハッシュ６２４。これは，データの完全性だけでなく，ＵＲＬメッセージの信頼性を確かめることを助ける。ＵＲＬハッシュのこうした例は，その技術に詳しい者にとってよく知られている。例は，ハッシュに基づくメッセージ認証コード（ＨＭＡＣ），及び，それに類似するものを含むが，それに限定されない。ＭＤ−５，及び，ＳＨＡ−１のような，任意のハッシュ関数が，用いられ得る。
　［００５７］　もし，格納されているファイル，及び／または，ドキュメント情報が，暗号化されるのであれば，組み込まれた暗号鍵と，アルゴリズム６２５が，任意に指定され得る。これは，格納された符号化されていないドキュメント，符号化されたドキュメント，及び／または，検証のためのドキュメント情報が存在しているときに，システム上の，ファイル，及び／または，情報を，復号するために用いられる，復号鍵と，アルゴリズムを抜き出すために，ＳＤＶＳ１０４によって，用いられる。この方法は，それによって，システムが，使用される方法と，鍵を知る必要のないような，セキュリティ増強である，システム上に格納された，それぞれのドキュメント，及び／または，ドキュメント情報のための，固有の鍵を提供する。例えば，ＡＥＳ，ブローフィッシュ，及び，その他の有名な方法を含むが，それに限定されない，種々の暗号化方法が用いられ得る。当審にて訳出。以下，同じ。）
　
Ｄ．「
」
　
（３）原審拒絶理由に引用された，本願の第１国出願前に既に公知である，米国特許出願公開第２００２／００８３１７８号明細書（２００２年６月２７日公開，以下，これを「引用文献３」という）には，関連する図面と共に，次の事項が記載されている。
　
Ｅ．「[0142]　Retrieval Key Data
 [0143]　This field indicates the key data used to encrypt or decrypt data transmitted between the web servers 24, 30 of the RPS 14 and/or RDS 16. For example, the key data can be used by the web server 30 of the RDS 16 to decrypt the resource transmitted from the RPS 14 to the RDS 16 in response to a request-for-resource signal generated by a WAD.」
（［０１４２］　鍵情報の検索
［０１４３］　この領域は，ＲＰＳ１４，及び／または，ＲＤＳ１６のウェブ・サーバ２４，３０の間で転送されるデータを，暗号化，或いは，復号するために用いられる，鍵情報を示している。例えば，その鍵情報は，ＷＡＤにより生成された，資源要求信号の応答において，ＲＰＳ１４から，ＲＤＳ１６へ送信される資源の復号のために，ＲＤＳ１６のウェブ・サーバ３０によって用いられ得る。）
　
Ｆ．「[0150]　The secure URL generator module functions to generate a URL having resource access right data starting from a URL. The URL with secure resource access right data can be referred to as a “secure URL”. FIGS.10A and 10B represent a “formatted path” technique for generating a secure URL, and FIGS.11A and 11B represent a “appended argument” approach to generating a secure URL. In the formatted path approach to encoding resource access right data with the URL, an original URL: 
[0151]  http://www.content-server.com/path1/path2/file.ext
[0152]  becomes 
[0153]  http://www.content-server.com/secure_resource_access_right_data/path1/path2/file.ext 
[0154]  Thus, the resource access right data becomes a part of the file path leading to the resource requested by the WAD 12. The appended argument approach takes a different form: 
[0155]  http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data」
（［１５０］　セキュアＵＲＬ生成モジュールは，ＵＲＬから開始して，資源アクセス権データを有するようなＵＲＬを生成するために機能する。セキュア資源アクセス権データを備えたＵＲＬは，“セキュアＵＲＬ”と呼ばれ得る。図１０Ａと，図１０Ｂは，セキュアＵＲＬを生成するための，“フォーマットされたパス”技術を表し，図１１Ａと，図１１Ｂは，セキュアＵＲＬを生成するための，“付加変数”方法を表す。ＵＲＬと共に，資源アクセス権データを符号化する，“フォーマットされたパス”方法において，オリジナルＵＲＬ：
［０１５１］　http://www.content-server.com/path1/path2/file.ext
　は，
［０１５２］　（つぎのように）なる。
［０１５３］　 http://www.content-server.com/secure_resource_access_right_data/path1/path2/file.ext 
［０１５４］　それ故，資源アクセス権データは，ＷＡＤ１２に要求された資源へつながる，ファイルパスの一部となる。付加変数方法は，異なる形を与える：
［０１５５］　http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data）
　
Ｇ．「
」
　
２．引用文献１に記載の発明
（１）上記Ａの「仲介サーバ１０１がサービスメニュー又はユーザの要望に応じたアクセス制限情報をＵＲＬパラメータとして図５に示すＡ１部分のＵＲＬに付加し，共通鍵Ｋｃを用いて認証コードを生成し，認証コードを図５に示すＡ３部分に付加する」という記載，同じく，上記Ａの「仲介サーバ１０１がパスワード等の所望のクライアント認証を行った後，ＯＴＵにてサービス提供サーバ１０３への接続方法をクライアント１０２に通知する」という記載，及び，同じく，上記Ａの「仲介サーバ１０１から通知されたＯＴＵをクライアント１０２が辿ることにより，サービス提供サーバ１０３に接続する」という記載から，引用文献１においては，
“仲介サーバ１０１がサービスメニュー又はユーザの要望に応じたアクセス制限情報をＵＲＬパラメータとしてＵＲＬのＡ１の部分に付加し，共通鍵Ｋｃを用いて認証コードを生成し，認証コードを前記ＵＲＬのＡ３の部分に付加して，前記ＵＲＬにてサービス提供サーバ１０３への接続方法をクライアント１０２に通知し，前記クライアント１０２は，前記ＵＲＬを辿って，サービス提供サーバ１０３に接続する”ものであることが読み取れる。
　
（２）上記Ａの「サービス提供サーバ１０３がクライアント１０２から提示されたＯＴＵの認証コード部分を共通鍵Ｋｃで検証することにより，ＯＴＵの正当性を確認し，ＳＴ１４８では，クライアント１０２が所望するサービス提供サーバ１０３へのＨＴＴＰアクセスを実現する」という記載，及び，上記Ｂの「サービス提供サーバとは異なる別の仲介サーバを設け，仲介サーバがサービス提供サーバから定期的に取得したアドレス情報に対して共通鍵でハッシュ演算を行い，公開鍵暗号方式に利用可能な鍵対の一方である秘密鍵を用いてハッシュ演算結果を暗号化処理してＯＴＵ用の認証コードを生成し，サービス提供サーバは，仲介サーバと共有する共通鍵を用いてＯＴＵの認証コード以外の部分に対してハッシュ演算を行うと共に，仲介サーバが暗号化処理に用いた秘密鍵と鍵対をなす公開鍵を用いて認証コードを復号化処理し，ハッシュ演算結果と復号化処理結果とを比較して認証コードの正当性を確認することにより，ＯＴＵの発行者とＯＴＵの受付者が物理的に異なる場合でも，ＯＴＵの偽造又は改竄による不正アクセスを防止することができる」という記載から，引用文献１において，
“サービス提供サーバは１０３がクライアントから提示されたＵＲＬに含まれる認証コード部分を検証することにより，前記ＵＲＬの正当性を確認し，クライアント１０２が所望するサービス提供サーバ１０３へのアクセスを実現する”ことが読み取れる。
　
（３）以上，上記（１），及び，（２）において検討した事項から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「仲介サーバ１０１がサービスメニュー又はユーザの要望に応じたアクセス制限情報をＵＲＬパラメータとしてＵＲＬのＡ１の部分に付加し，共通鍵Ｋｃを用いて認証コードを生成し，認証コードを前記ＵＲＬのＡ３の部分に付加して，前記ＵＲＬにてサービス提供サーバ１０３への接続方法をクライアント１０２に通知し，前記クライアント１０２は，前記ＵＲＬを辿って，サービス提供サーバ１０３にアクセスを要求し，
　サービス提供サーバは１０３がクライアントから提示されたＵＲＬに含まれる認証コード部分を検証することにより，前記ＵＲＬの正当性を確認し，クライアント１０２が所望するサービス提供サーバ１０３へのアクセスを実現する，サービス提供サーバ１０３。」
　
第６．本願発明と引用発明との対比
１．引用発明における「サービス提供サーバ１０３」は，「クライアント１０２」からの要求を受け付けるものであって，「サーバ」が，「プロセッサ」，「メモリ」を有することは，当該技術分野における技術常識であるから，
　引用発明における「サービス提供サーバ１０３」が，
　本願発明における「システム」に相当し，
　引用発明においても，「サービス提供サーバ１０３」が，「クライアント１０２」からの要求を受け取るために，当該「サービス提供サーバ１０３」が有する「プロセッサ」に，当該要求を受け取るための処理を行われるための「命令」が実行されることも明らかであり，
　引用発明においては，「ＵＲＬ」は，「仲介サーバ１０１」によって生成され，「認証コード」と，「アクセス制限情報」を含むものであって，「クライアント１０２」から，「サービス提供サーバ１０３」へのアクセスの「要求」といい得るものであるから，
　引用発明における「仲介サーバ」，「ＵＲＬ」，「認証コード」が，
　本願発明における「第１のエンティティ」，「要求」，「認可情報」に相当するので，
　引用発明における「仲介サーバ１０１がサービスメニュー又はユーザの要望に応じたアクセス制限情報をＵＲＬパラメータとしてＵＲＬのＡ１の部分に付加し，共通鍵Ｋｃを用いて認証コードを生成し，認証コードを前記ＵＲＬのＡ３の部分に付加して，前記ＵＲＬにてサービス提供サーバ１０３への接続方法をクライアント１０２に通知し，前記クライアント１０２は，前記ＵＲＬを辿って，サービス提供サーバ１０３にアクセスを要求し，
　サービス提供サーバは１０３がクライアントから提示されたＵＲＬ」と，
　本願発明における「システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む，受け取らせること」とは，
“システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び他の情報を含む予め生成された一部分を含む，受け取らせること”である点で共通する。
　
２．引用発明においては，「サービス提供サーバ１０３」が，「クライアント１０２」が提示する「ＵＲＬ」に含まれる「認証コード」を検証して，ＵＲＬが正当である場合に，「クライアント１０２」の要求を受け付けるものであるから，
　上記１．において検討した事項と併せると，
　引用発明における「サービス提供サーバは１０３がクライアントから提示されたＵＲＬに含まれる認証コード部分を検証することにより，前記ＵＲＬの正当性を確認し，クライアント１０２が所望するサービス提供サーバ１０３へのアクセスを実現する」ことと，
　本願発明における「認可情報が，前記要求を満たすために前記第１のエンティティによって認可を示すと判定されることを条件として，前記暗号化鍵を使用して１つまたは複数の動作を行わせること」とは，
“認可情報が，要求を満たすために第１のエンティティによって認可を示すと判定されることを条件として，要求を実行する”点で共通する。
　
３．以上，上記１．，及び，２．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　システムであって，
　１つまたは複数のプロセッサと，
　命令を含むメモリと，を備え，該命令は，前記１つまたは複数のプロセッサによって実行された場合には，前記システムに，
　要求側からの要求を受け取らせることであって，前記要求は，第１のエンティティによって生成された認可情報及び他の情報を含む予め生成された一部分を含む，受け取らせること，
　前記認可情報が，前記要求を満たすために第１のエンティティによって認可を示すと判定されることを条件として，前記要求を実行する，システム。
　
［相違点１］
“（要求側からの要求に含まれる）他の情報”に関して，
　本願発明においては「暗号化鍵」であるのに対して，
　引用発明においては，「アクセス制限情報」であって，「暗号化鍵」を含む点については，言及されていない点。
　
［相違点２］
“要求を実行する”に関して，
　本願発明においては，「暗号化鍵を使用して１つまたは複数の動作を行わせること」と，「前記行った１つまたは複数の動作の結果を提供させること」であるのに対して，
　引用発明においては，「暗号化鍵」を用いた処理と，その結果の提供については，言及されていない点。
　
第７．相違点についての当審の判断
１．［相違点１］について
　上記Ｃに引用した，引用文献２の「If the file and/or document information stored is encrypted, an embedded decryption key and algorithm 625 could optionally be specified.（もし，格納されているファイル，及び／または，ドキュメント情報が，暗号化されるのであれば，組み込まれた暗号鍵と，アルゴリズム６２５が，任意に指定され得る。）」という記載，上記Ｄに引用した，引用文献２のＦＩＧ．６に開示の，特に，項目６２５に関する事項，上記Ｅに引用した，引用文献３の「　This field indicates the key data used to encrypt or decrypt data transmitted between the web servers 24, 30 of the RPS 14 and/or RDS 16. （この領域は，ＲＰＳ１４，及び／または，ＲＤＳ１６のウェブ・サーバ２４，３０の間で転送されるデータを，暗号化，或いは，復号するために用いられる，鍵情報を示している。）」という記載，上記Ｆに引用した，引用文献３の「[0154]  Thus, the resource access right data becomes a part of the file path leading to the resource requested by the WAD 12. The appended argument approach takes a different form: 
[0155]  http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data（［０１５４］　それ故，資源アクセス権データは，ＷＡＤ１２に要求された資源へつながる，ファイルパスの一部となる。付加変数方法は，異なる形を与える：
［０１５５］　http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data）」という記載，及び，上記Ｇに引用した，引用文献３のＦＩＧＵＲＥ　１０Ａに開示の，特に，「RETRIEVAL　KEY　DATA」という項目から，「ＵＲＬ」に，暗号化，復号のための「鍵」を組み込むことは，本願の第１国出願前に，当業者には広く知られた技術事項であり，当該「ＵＲＬ」を送ることは，一種の「要求」と言い得るものであるから，
　したがって，引用発明においても，（要求側からの要求としての）「ＵＲＬ」に，「暗号化鍵」を組み込むことは，提供する「サービス」に応じて，当業者が適宜選択し得る事項である。
　よって，［相違点１］は，格別のものではない。
　
２．［相違点２］について
　上記１．において言及した，引用文献２，及び，引用文献３に記載の内容から，「ＵＲＬ」に組み込まれた「暗号化鍵」を用いて，情報の「暗号化」，或いは，「復号」を行って提供する「サービス」を実行することは，本願の第１国出願前に，当業者には広く知られた技術事項であった。
　そして，当該「サービス」を提供することは，即ち，「動作の結果を提供する」ことであるから，
　したがって，引用発明においても，（要求側からの要求としての）「ＵＲＬ」に組み込まれた「暗号化鍵」を用いた「動作の結果を提供する」よう構成することは，当業者が適宜なし得る事項である。
　よって，［相違点２］は，格別のものではない。
　
３．以上，上記１．，及び，２．において検討したとおり，［相違点１］，及び，［相違点２］は，格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　
　なお，本願の請求項１に係る発明における発明特定事項である「暗号化鍵」に，「第１のエンティティによって生成された」と言った限定事項を付加したとしても，「鍵」を「ＵＲＬ」に埋め込む者が，当該「鍵」を生成するよう構成するという態様自体，当業者には周知の技術事項である。
　また，審判請求人は，本願発明と，引用発明とでは，課題が異なる旨主張しているが，上記において検討したとおり，本願発明は，引用発明と，引用文献２，及び，引用文献３に記載された技術から，当業者が容易に構築し得るものであるから，審判請求人の上記主張は採用できない。
　
第８．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。