• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04L
審判 査定不服 特174条1項 特許、登録しない。 H04L
管理番号 1354859
審判番号 不服2018-5240  
総通号数 238 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-10-25 
種別 拒絶査定不服の審決 
審判請求日 2018-04-17 
確定日 2019-09-05 
事件の表示 特願2016-542890「鍵を有するリソースロケーター」拒絶査定不服審判事件〔平成27年 4月 2日国際公開,WO2015/048039,平成28年 9月29日国内公表,特表2016-530850〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1.手続の経緯
本願は,2014年9月23日(パリ条約による優先権主張外国庁受理2013年9月25日 アメリカ合衆国)を国際出願日とする出願であって,
平成28年3月15日付けで特許法第184条の4第1項の規定による明細書,請求の範囲,及び,図面(図面の中の説明に限る)の日本語による翻訳文が提出され,同日付けで審査請求がなされると共に手続補正がなされ,平成29年2月2日付けで審査官により拒絶理由が通知され,これに対して平成29年6月30日付けで意見書が提出されると共に手続補正がなされたが,平成29年11月13日付けで審査官により拒絶査定がなされ(謄本送達;平成29年12月18日),これに対して平成30年4月17日付けで審判請求がなされると共に手続補正がなされ,平成30年6月7日付けで審査官により特許法第164条第3項の規定に基づく報告がなされたものである。

第2.平成30年4月17日付けの手続補正の却下の決定

[補正却下の決定の結論]

平成30年4月17日付け手続補正を却下する。

[理由]

1.補正の内容
平成30年4月17日付けの手続補正(以下,「本件手続補正」という)により,平成29年6月30日付けの手続補正により補正された特許請求の範囲,
「 【請求項1】
システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む,受け取らせることと,
前記認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を使用して1つまたは複数の動作を行わせることと,
前記行った1つまたは複数の動作の結果を提供させることと,を行わせる,
システム。
【請求項2】
前記予め生成された一部分は,ユニフォームリソースロケータとしてフォーマットされる,請求項1に記載の前記システム。
【請求項3】
前記1つまたは複数の動作は,暗号化された形態で前記第1のエンティティによって記憶されるデータにアクセスし,前記暗号化鍵を使用して前記データを解読することを含み,
前記結果を提供することは,前記要求側に前記解読したデータを伝送することを含む,請求項1に記載の前記システム。
【請求項4】
前記要求はさらに,前記予め生成された一部分に加えられたデータを含み,
前記暗号化鍵を使用して前記1つまたは複数の動作を行うことは,前記予め生成された一部分に加えられた前記データに対して1つまたは複数の暗号化動作を行うことを含む,請求項1に記載の前記システム。
【請求項5】
前記認可情報は,前記要求側がアクセスできない秘密情報を使用して生成される電子署名を含む,請求項1に記載の前記システム。
【請求項6】
前記認可情報は,前記要求を提出するためのコンテキストに対して1つまたは複数の条件を指定し,
前記暗号化鍵を使用して1つまたは複数の動作を行うことはさらに,前記1つまたは複数の条件を遵守して前記要求を受け取ることを条件として行われる,請求項1に記載の前記システム。
【請求項7】
前記1つまたは複数の条件は,前記要求を満たすことができる継続時間を定義する,請求項6に記載の前記システム。
【請求項8】
前記認可情報は,前記暗号化鍵に少なくとも部分的に基づいて生成される電子署名を含み,
前記第1のエンティティによる認可を示す前記認可情報は,前記電子署名が有効であることを必要とする,請求項1に記載の前記システム。
【請求項9】
前記システムはさらに,前記要求側と,前記要求側と異なる顧客システムとを備え,
前記顧客システムは,前記要求を提出する際に使用するための前記要求の表現を提供し,それによって,前記要求を前記要求側から受け取ることを可能にする,請求項1に記載の前記システム。
【請求項10】
方法であって,
要求及び暗号化鍵を符号化する情報を生成することと,
前記要求を満たすことができるサービスプロバイダによって検証できる情報の電子署名を生成することと,
前記情報及び電子署名を前記サービスプロバイダに提供することを可能にして,前記サービスプロバイダに前記暗号化鍵を使用させて前記要求を満たすために,前記情報及び前記電子署名を利用できるようにすることと,
を含む,方法。
【請求項11】
前記情報及び前記電子署名を利用できるようにすることは,前記情報及び前記電子署名を含むユニフォームリソースロケータを生成することを含む,請求項10に記載の前記方法。
【請求項12】
前記情報及び前記電子署名を利用できるようにすることは,選択可能な要素で構成されるウェブページを提供することを含み,該選択可能な要素は,選択されたときに,前記情報及び電子署名を含む前記要求を前記サービスプロバイダに伝送させる,請求項10に記載の前記方法。
【請求項13】
前記情報はさらに,前記サービスプロバイダによってホストされるリソースの識別子を符号化し,
前記要求は,前記リソースと関連して行われる1つまたは複数の動作を指定する,請求項10に記載の前記方法。
【請求項14】
前記情報は,前記要求を前記サービスプロバイダによって満たすことができるようにするための,前記要求の提出に対する1つまたは複数の条件を符号化する,請求項10に記載の前記方法。
【請求項15】
前記情報は,前記要求をどのように満たすのかという様式を符号化し,前記様式は,前記要求を満たすことができる複数の様式からのものである,請求項10に記載の前記方法。」(以下,上記引用の請求項各項を,「補正前の請求項」という)は,
「 【請求項1】
システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び前記第1のエンティティによって生成された暗号化鍵を含む予め生成された一部分を含む,受け取らせることと,
前記認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を要求して1つまたは複数の動作を行わせることと,
前記行った1つまたは複数の動作の結果を提供させることと,を行わせる,
システム。
【請求項2】
前記予め生成された一部分は,ユニフォームリソースロケータとしてフォーマットされる,請求項1に記載の前記システム。
【請求項3】
前記1つまたは複数の動作は,暗号化された形態で前記第1のエンティティによって記憶されるデータにアクセスし,前記暗号化鍵を使用して前記データを解読することを含み,
前記結果を提供することは,前記要求側に解読した前記データを伝送することを含む,請求項1に記載の前記システム。
【請求項4】
前記要求はさらに,前記予め生成された一部分に加えられたデータを含み,
前記暗号化鍵を使用して前記1つまたは複数の動作を行うことは,前記予め生成された一部分に加えられた前記データに対して1つまたは複数の暗号化動作を行うことを含む,請求項1に記載の前記システム。
【請求項5】
前記認可情報は,前記要求側がアクセスできない秘密情報を使用して生成される電子署名を含む,請求項1に記載の前記システム。
【請求項6】
前記認可情報は,前記要求を提出するためのコンテキストに対して1つまたは複数の条件を指定し,
前記暗号化鍵を使用して1つまたは複数の動作を行うことはさらに,前記1つまたは複数の条件を遵守して前記要求を受け取ることを条件として行われる,請求項1に記載の前記システム。
【請求項7】
前記1つまたは複数の条件は,前記要求を満たすことができる継続時間を定義する,請求項6に記載の前記システム。
【請求項8】
前記認可情報は,前記暗号化鍵に少なくとも部分的に基づいて生成される電子署名を含み,
前記第1のエンティティによる認可を示す前記認可情報は,前記電子署名が有効であることを必要とする,請求項1に記載の前記システム。
【請求項9】
前記システムはさらに,前記要求側と,前記要求側と異なる顧客システムとを備え,
前記顧客システムは,前記要求を提出する際に使用するための前記要求の表現を提供し,それによって,前記要求を前記要求側から受け取ることを可能にする,請求項1に記載の前記システム。
【請求項10】
方法であって,
要求及び暗号化鍵を符号化する情報を生成することと,
前記要求を満たすことができるサービスプロバイダによって検証できる情報の電子署名を生成することと,
前記情報及び前記電子署名を前記サービスプロバイダに提供することを可能にして,前記サービスプロバイダに前記暗号化鍵を使用させて前記要求を満たすために,前記情報及び前記電子署名を利用できるようにすることと,
を含む,方法。
【請求項11】
前記情報及び前記電子署名を利用できるようにすることは,前記情報及び前記電子署名を含むユニフォームリソースロケータを生成することを含む,請求項10に記載の前記方法。
【請求項12】
前記情報及び前記電子署名を利用できるようにすることは,選択可能な要素で構成されるウェブページを提供することを含み,該選択可能な要素は,選択されたときに,前記情報及び電子署名を含む前記要求を前記サービスプロバイダに伝送させる,請求項10に記載の前記方法。
【請求項13】
前記情報はさらに,前記サービスプロバイダによってホストされるリソースの識別子を符号化し,
前記要求は,前記リソースと関連して行われる1つまたは複数の動作を指定する,請求項10に記載の前記方法。
【請求項14】
前記情報は,前記要求を前記サービスプロバイダによって満たすことができるようにするための,前記要求の提出に対する1つまたは複数の条件を符号化する,請求項10に記載の前記方法。
【請求項15】
前記情報は,前記要求をどのように満たすのかという様式を符号化し,前記様式は,前記要求を満たすことができる複数の様式からのものである,請求項10に記載の前記方法。」(以下,上記引用の請求項各項を,「補正後の請求項」という)に補正された。

2.補正の適否
(1)補正事項
本件手続補正は,補正前の請求項1に記載された,発明特定事項である「暗号化鍵」に対して,「第1のエンティティによって生成された」という限定事項を付加し(以下,これを「補正事項1」という),
補正前の請求項1の,
「前記認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を使用して1つまたは複数の動作を行わせること」,
という記載を,
「前記認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を要求して1つまたは複数の動作を行わせること」,
と補正し(以下,これを「補正事項2」という),
補正前の請求項3の,
「前記要求側に前記解読したデータを伝送する」,
という記載を,
「前記要求側に解読した前記データを伝送する」,
と補正する(以下,これを「補正事項3」という)ものである。

(2)新規事項についての当審の判断
本件手続補正が,特許法第184条の12第2項により読み替える同法第17条の2第3項の規定を満たすものであるか否か,即ち,本件手続補正が,平成28年3月15日付けで提出された明細書,請求の範囲の日本語による翻訳文,及び,国際出願の願書に添付した図面に記載した事項(以下,これを「当初明細書等」という)の範囲内でなされたものであるかについて,以下に検討する。

ア.補正事項1について
当初明細書等には,「第1のエンティティによって生成された暗号化鍵」は記載されていない。
そこで,当初明細書等の記載から,上記指摘の構成が読み取れるかについて検討すると,
当初明細書等には,段落【0020】に,
「図1で例示されるように,URL106はまた,暗号化鍵114も含み得る。暗号化鍵114は,顧客102がアクセスを有する暗号化鍵であり得る」,
同じく,段落【0020】に,
「暗号化鍵114は,URLに含まれ得,別の鍵の下で暗号化される形態で対称鍵がURL106に含まれ得,ここで,他の鍵は,種々の実施形態に従って変化し得るが,全般的に,サードパーティ108からURL106を受け取った時点で,サービスプロバイダ104がそれ自体で,または別のサービス,例えば別のサードパーティのサービスを使用して,暗号化鍵114を使用するために解読することができるような鍵である」,
同じく,段落【0020】に,
「サードパーティ108は,顧客102によって提供される暗号化鍵114を使用して,サービスプロバイダ104のサービスを利用することができる」,
段落【0021】に,
「暗号化鍵114をサードパーティ108へのURL106に含めることによって,サードパーティ108は,サービスプロバイダ104が,暗号化鍵114を使用して,顧客102によってデータ記憶サービスに記憶したデータを解読することを可能にするために,URL106を使用して要求をサービスプロバイダ104に提出することができる」,
段落【0033】に,
「暗号化動作は,URLの署名済部分の中の鍵(顧客によって供給される),及びURLの未署名部分の中の鍵(サードパーティによって供給される)の双方を使用して行われ得る」,
段落【0046】に,
「URLにおいて鍵を供給した顧客」,
段落【0047】に,
「顧客が,プロバイダによってラップ解除できる(利用できる)ように暗号化秘密をラップすることを含む」,
同じく,段落【0047】に,
「全般的に,本開示の変形例は,プロバイダが暗号化秘密自体をラップ解除するのではなく,プロバイダの代わりに暗号化秘密をラップ解除する別のシステム(例えば,サードパーティのシステム)を有する」,
段落【0048】に,
「顧客は,ラップした秘密を有するURLを構築し得る」,
と記載されている。
ここで,段落【0036】に,
「サードパーティは,例えば,上で説明されるようなプロセス500を行うエンティティの顧客であり得る」,
と記載されていることから,請求項1に記載の「第1のエンティティ」とは,当初明細書等の上記引用の段落における「URL106」等を提供する「顧客102」等であることから,上記引用の各段落の記載内容から,「第1のエンティティ」である「顧客102」が,「暗号化鍵」を「URL106」に組み込むために提供することは,読み取れる。
しかしながら,当初明細書等は,「顧客102」が,「暗号化鍵」を生成することは記載されておらず,上記引用の記載を検討しても,「顧客102」が,「暗号鍵」生成すること,即ち,「第1のエンティティによって生成された暗号化鍵」を読み取ることはできない。
このことは,「第1のエンティティ」を,当初明細書等に記載の「サードパーティ」,及び,「顧客102」であると解しても同じである。

イ.補正事項2について
当初明細書等には,補正事項2における,特に,
「暗号化鍵を要求して1つまたは複数の動作を行わせること」,
は記載されていない。
補正事項2における上記指摘の点が,当初明細書等から読み取れるかについて検討すると,上記ア.において引用した記載の他,段落【0004】に,
「要求を満たす際に使用される暗号化鍵を含むために,要求が予め生成される。要求は,ユニフォームリソースロケータの中に符号化され得,また,要求が提出されるサービスプロバイダが,要求が認可されたかどうかを判定することを可能にするために,認証情報を含み得る。要求は,種々のエンティティに渡され得,次いで,エンティティは,該要求をサービスプロバイダに提出することができる。サービスプロバイダは,要求を受け取ると,認証情報を検証し,要求の中に符号化された暗号化鍵を使用して要求を満たすことができる」,
段落【0009】に,
「顧客は,予め署名したURLを利用し得る。予め署名したURLを生成するために,顧客は,URL(または全般的に,要求)及び該URLの一部分の電子(デジタル)署名を生成し得る。電子署名を生成するために使用されるURLの一部分は,要求を処理する際に使用される暗号化鍵を含み得る。暗号化鍵は,種々の形態で提供され得る。例えば,暗号化鍵は,サービスプロバイダが要求を満たすためにその鍵を使用して1つまたは複数の暗号化動作を行って解読することができる,または解読した方法で解読される,プレーンテキスト対称鍵,公開鍵-秘密鍵対のうちのプレーンテキスト公開鍵,または対称鍵であり得る」,
段落【0010】に,
「URLは,要求,暗号化鍵,及び要求を検証するために使用できる認証情報(例えば,電子署名)を含み得る認可情報を符号化するように構成され得る」,
段落【0012】に,
「要求を受け取ると,サービスプロバイダは,要求を満たすかどうかを判定するために,電子署名の有効性を確認し得る。他の動作は,要求を満たすことが,任煮の適用可能なポリシーを遵守するかどうか,及び/または要求に符号化される(例えば,認可情報の一部として符号化される)1つまたは複数のパラメータ(例えば,有効期限)を遵守するかどうかを判定する等の,要求を満たすかどうかを判定する際に行われ得る。サービスプロバイダが満たすことができるとみなされる要求の場合,サービスプロバイダは,該要求から暗号化鍵を抽出し,(該当する場合は)抽出した暗号化鍵を解読し,そして,要求を満たす際に関与する1つまたは複数の動作を行い得る。要求が満たされたという肯定応答,及び/または1つまたは複数の動作を行った結果(例えば,要求の中に提供された鍵を使用して解読したデータ)等の,顧客に対する応答が提供され得る」,
段落【0019】に,
「サービスプロバイダ104が,URL106を使用してサードパーティ108によってサービスプロバイダ104に提出された要求をどのように満たすか,及び/または要求を満たすかどうかを判定することを可能にするために,種々の情報がURLに含まれ得る。例えば,図1で例示されるように,URL106は,電子署名110を含み,該電子署名は,顧客102に対応する署名検証鍵112へのアクセスを有することによって,サービスプロバイダ104によって検証することができる」,
段落【0026】に,
「例えば,データを記憶する要求にURL204が含まれる場合,顧客インターフェースは,URL204に提供される鍵216を利用して,データ記憶システム214のうちの1つまたは複数に記憶するために,データを暗号化し,暗号化したデータ210を要求処理インフラストラクチャ212に伝送し得る」,
段落【0027】に,
「同様に,要求が,データを取り出す要求である場合,顧客インターフェース202は,データ記憶システム214のうちの1つまたは複数からのデータを顧客インターフェース202に提供することを可能にする通信を,要求処理インフラストラクチャ212に伝送し得る。次いで,顧客インターフェース202は,URL204に提供される鍵216を使用して,暗号化されたデータ210を解読し,解読したデータを,要求を提出した顧客に提供し得る」,
段落【0042】に,
「全般的に,要求において提供される暗号化鍵を使用して行われる暗号化動作に応じて,706で取得した結果は,変動し得る」,
段落【0044】に,
「しかしながら,806で,署名が有効であると判定された場合,プロセス800は,810で,802で受け取ったURLから暗号化鍵を抽出することを含み得る。抽出した暗号化鍵は,812で,要求を処理する(すなわち,満たす)ために使用され得る」,
段落【0049】に,
「プロバイダは,要求を検証すると,暗号化鍵を解読するために適切な暗号化アルゴリズムを行うことによって(または別様には,行わせることによって),暗号化秘密をラップ解除し得る。次いで,912で,暗号化鍵を使用して要求を処理し得,914で,プロバイダは,プロバイダが行った1つまたは複数の暗号化動作を行った結果,及び/または該暗号化動作を行ったことの肯定応答を提供する等で,サードパーティの要求に応答し得る」,
と記載されていて,上記において引用した,当初明細書等の記載から,当初明細書等においては,「要求」とは,「顧客」,或いは,「サービスプロバイダ」に対して行うものであり,署名検証用でない,「暗号化鍵」は,「サービスプロバイダ」に対して「要求」を行うために用いられる「URL」に含まれるものであって,同じく,「URL」に含まれる「署名」を,「サービスプロバイダ」において検証し,当該検証が正当である場合に,使用可能になるものである。
したがって,上記引用の当初明細書等の記載を検討しても,補正事項2における,
「暗号化鍵を要求して1つまたは複数の動作を行わせること」,
を読み取ることはできない。

ウ.新規事項むすび
以上,ア.,及び,イ.において検討したとおりであるから,補正事項1,及び,補正事項2は,当初明細書等に記載されたものではなく,
本件手続補正は,当初明細書等の記載の範囲内でなされたものではない。

3.補正却下むすび
したがって,本件手続補正は,特許法184条の12第2項により読み替える同法17条の2第3項の規定に違反するので,同法159条1項において読み替えて準用する同法53条1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。

第3.本願発明について
平成30年4月17日付けの手続補正は,上記のとおり却下されたので,本願の請求項1に係る発明(以下,これを「本願発明」という)は,平成29年6月30日付けの手続補正により補正された特許請求の範囲の請求項1に記載された,上記「第2.平成30年4月17日付けの手続補正の却下の決定」の「1.補正の内容」において,補正前の請求項1として引用した,次のとおりのものである。

「システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む,受け取らせることと,
前記認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を使用して1つまたは複数の動作を行わせることと,
前記行った1つまたは複数の動作の結果を提供させることと,を行わせる,
システム。」

第4.原審拒絶査定
原審における平成29年11月13日付けの拒絶査定は,次のとおりである。
「●理由1(特許法第29条第2項)について
・請求項 1-15
・引用文献等 1-3
拒絶理由のとおりである。引用文献1-3はいずれもURLを用いたアクセスに関する技術なのだから,引用文献1に引用文献2-3の技術を適用することは当業者が容易になしえたことである。
出願人の意見書での主張は,要するに引用文献1には本願と同一の課題が記載されていないから,引用文献1-3を組み合わせることはできないというものであるが,拒絶理由のとおりの理由で,引用文献1-3の組み合わせは容易であるから,意見書の主張は採用しない。(同一の課題が記載されていなければ,進歩性を否定できないというものではなく,上記のとおりの理由で,引用文献1-3を組み合わせる理由は十分に存在している。)
補正後の請求項1-15は,依然として引用文献1-3の記載から当業者が容易に想到することができたものである。

<引用文献等一覧>
1.特開2006-128873号公報
2.米国特許出願公開第2013/0247218号明細書
3.米国特許出願公開第2002/0083178号明細書」

第5.引用文献に記載の事項及び発明
1.引用文献に記載の事項
(1)原審における平成29年2月2日付けの拒絶理由(以下,これを「原審拒絶理由」という)において引用された,本願の第1国出願前に既に公知である,特開2006-128873号公報(2006年5月18日公開,以下,これを「引用文献1」という)には,関連する図面と共に,次の事項が記載されている。

A.「【0047】
ST143では,クライアント102が仲介サーバ101の固定アドレスにアクセスし,サービス提供サーバ103への接続要求を通知し,ST144では,仲介サーバ101がサービスメニュー又はユーザの要望に応じたアクセス制限情報をURLパラメータとして図5に示すA1部分のURLに付加し,共通鍵Kcを用いて認証コードを生成し,認証コードを図5に示すA3部分に付加する。
【0048】
ST145では,仲介サーバ101がパスワード等の所望のクライアント認証を行った後,OTUにてサービス提供サーバ103への接続方法をクライアント102に通知する。このとき,OTUの通知方法は,予め仲介サーバ101が把握するクライアント102のメールアドレス宛に電子メールで通知してもよいし,HTTPプロトコル上でHTMLページ上の情報として通知してもよい。
【0049】
ST146では,仲介サーバ101から通知されたOTUをクライアント102が辿ることにより,サービス提供サーバ103に接続する。通常,この接続はウェブブラウザ又はメーラ上でURLリンク部分をクリックするだけの簡便なユーザインタフェースにより実現される。
【0050】
ST147では,サービス提供サーバ103がクライアント102から提示されたOTUの認証コード部分を共通鍵Kcで検証することにより,OTUの正当性を確認し,ST148では,クライアント102が所望するサービス提供サーバ103へのHTTPアクセスを実現する。」

B.「【0066】
このように実施の形態2によれば,サービス提供サーバとは異なる別の仲介サーバを設け,仲介サーバがサービス提供サーバから定期的に取得したアドレス情報に対して共通鍵でハッシュ演算を行い,公開鍵暗号方式に利用可能な鍵対の一方である秘密鍵を用いてハッシュ演算結果を暗号化処理してOTU用の認証コードを生成し,サービス提供サーバは,仲介サーバと共有する共通鍵を用いてOTUの認証コード以外の部分に対してハッシュ演算を行うと共に,仲介サーバが暗号化処理に用いた秘密鍵と鍵対をなす公開鍵を用いて認証コードを復号化処理し,ハッシュ演算結果と復号化処理結果とを比較して認証コードの正当性を確認することにより,OTUの発行者とOTUの受付者が物理的に異なる場合でも,OTUの偽造又は改竄による不正アクセスを防止することができる。」

(2)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,米国特許出願公開第2013/0247218号明細書(2013年9月19日公開,以下,これを「引用文献2」という)には,関連する図面と共に,次の事項が記載されている。

C.「[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.」
([0052] 別法として,マシン可読コード501内に符号化されたURL620は,コードの有効期限などのような,システム上の調整可能な情報を持つよりも,むしろ,附加的なメタ情報を指定し得る。図6に示すように,ここで示されるURL620は,含むが,限定されない,これらの以下の機能を有する;
[0053] ドキュメントの発行者/生成者のid621,それは,この特別なマシン・コードと共に,そのドキュメントの,このコピーを要求される者を識別する。
[0054] レコードid622,それは,ドキュメント,その有効期限,および,同等のものを検証するために,許可される者を含むが,それに限定されない,この特別なマシン・コードのための,SDVS104上の,メタ情報を指し示す。
[0055] 有効期限623は,暗号化ハッシュ624の一部である,それ故,改変されていないかを検証することができる。
[0056] (システム上のレコードid622によって決定されるような)共有鍵による,上記パラメータの暗号化ハッシュ624。これは,データの完全性だけでなく,URLメッセージの信頼性を確かめることを助ける。URLハッシュのこうした例は,その技術に詳しい者にとってよく知られている。例は,ハッシュに基づくメッセージ認証コード(HMAC),及び,それに類似するものを含むが,それに限定されない。MD-5,及び,SHA-1のような,任意のハッシュ関数が,用いられ得る。
[0057] もし,格納されているファイル,及び/または,ドキュメント情報が,暗号化されるのであれば,組み込まれた暗号鍵と,アルゴリズム625が,任意に指定され得る。これは,格納された符号化されていないドキュメント,符号化されたドキュメント,及び/または,検証のためのドキュメント情報が存在しているときに,システム上の,ファイル,及び/または,情報を,復号するために用いられる,復号鍵と,アルゴリズムを抜き出すために,SDVS104によって,用いられる。この方法は,それによって,システムが,使用される方法と,鍵を知る必要のないような,セキュリティ増強である,システム上に格納された,それぞれのドキュメント,及び/または,ドキュメント情報のための,固有の鍵を提供する。例えば,AES,ブローフィッシュ,及び,その他の有名な方法を含むが,それに限定されない,種々の暗号化方法が用いられ得る。<当審にて訳出。以下,同じ。>)

D.「



(3)原審拒絶理由に引用された,本願の第1国出願前に既に公知である,米国特許出願公開第2002/0083178号明細書(2002年6月27日公開,以下,これを「引用文献3」という)には,関連する図面と共に,次の事項が記載されている。

E.「[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.」
([0142] 鍵情報の検索
[0143] この領域は,RPS14,及び/または,RDS16のウェブ・サーバ24,30の間で転送されるデータを,暗号化,或いは,復号するために用いられる,鍵情報を示している。例えば,その鍵情報は,WADにより生成された,資源要求信号の応答において,RPS14から,RDS16へ送信される資源の復号のために,RDS16のウェブ・サーバ30によって用いられ得る。)

F.「[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」
([150] セキュアURL生成モジュールは,URLから開始して,資源アクセス権データを有するようなURLを生成するために機能する。セキュア資源アクセス権データを備えたURLは,“セキュアURL”と呼ばれ得る。図10Aと,図10Bは,セキュアURLを生成するための,“フォーマットされたパス”技術を表し,図11Aと,図11Bは,セキュアURLを生成するための,“付加変数”方法を表す。URLと共に,資源アクセス権データを符号化する,“フォーマットされたパス”方法において,オリジナルURL:
[0151] http://www.content-server.com/path1/path2/file.ext
は,
[0152] (つぎのように)なる。
[0153] http://www.content-server.com/secure_resource_access_right_data/path1/path2/file.ext
[0154] それ故,資源アクセス権データは,WAD12に要求された資源へつながる,ファイルパスの一部となる。付加変数方法は,異なる形を与える:
[0155] http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data)

G.「



2.引用文献1に記載の発明
(1)上記Aの「仲介サーバ101がサービスメニュー又はユーザの要望に応じたアクセス制限情報をURLパラメータとして図5に示すA1部分のURLに付加し,共通鍵Kcを用いて認証コードを生成し,認証コードを図5に示すA3部分に付加する」という記載,同じく,上記Aの「仲介サーバ101がパスワード等の所望のクライアント認証を行った後,OTUにてサービス提供サーバ103への接続方法をクライアント102に通知する」という記載,及び,同じく,上記Aの「仲介サーバ101から通知されたOTUをクライアント102が辿ることにより,サービス提供サーバ103に接続する」という記載から,引用文献1においては,
“仲介サーバ101がサービスメニュー又はユーザの要望に応じたアクセス制限情報をURLパラメータとしてURLのA1の部分に付加し,共通鍵Kcを用いて認証コードを生成し,認証コードを前記URLのA3の部分に付加して,前記URLにてサービス提供サーバ103への接続方法をクライアント102に通知し,前記クライアント102は,前記URLを辿って,サービス提供サーバ103に接続する”ものであることが読み取れる。

(2)上記Aの「サービス提供サーバ103がクライアント102から提示されたOTUの認証コード部分を共通鍵Kcで検証することにより,OTUの正当性を確認し,ST148では,クライアント102が所望するサービス提供サーバ103へのHTTPアクセスを実現する」という記載,及び,上記Bの「サービス提供サーバとは異なる別の仲介サーバを設け,仲介サーバがサービス提供サーバから定期的に取得したアドレス情報に対して共通鍵でハッシュ演算を行い,公開鍵暗号方式に利用可能な鍵対の一方である秘密鍵を用いてハッシュ演算結果を暗号化処理してOTU用の認証コードを生成し,サービス提供サーバは,仲介サーバと共有する共通鍵を用いてOTUの認証コード以外の部分に対してハッシュ演算を行うと共に,仲介サーバが暗号化処理に用いた秘密鍵と鍵対をなす公開鍵を用いて認証コードを復号化処理し,ハッシュ演算結果と復号化処理結果とを比較して認証コードの正当性を確認することにより,OTUの発行者とOTUの受付者が物理的に異なる場合でも,OTUの偽造又は改竄による不正アクセスを防止することができる」という記載から,引用文献1において,
“サービス提供サーバは103がクライアントから提示されたURLに含まれる認証コード部分を検証することにより,前記URLの正当性を確認し,クライアント102が所望するサービス提供サーバ103へのアクセスを実現する”ことが読み取れる。

(3)以上,上記(1),及び,(2)において検討した事項から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「仲介サーバ101がサービスメニュー又はユーザの要望に応じたアクセス制限情報をURLパラメータとしてURLのA1の部分に付加し,共通鍵Kcを用いて認証コードを生成し,認証コードを前記URLのA3の部分に付加して,前記URLにてサービス提供サーバ103への接続方法をクライアント102に通知し,前記クライアント102は,前記URLを辿って,サービス提供サーバ103にアクセスを要求し,
サービス提供サーバは103がクライアントから提示されたURLに含まれる認証コード部分を検証することにより,前記URLの正当性を確認し,クライアント102が所望するサービス提供サーバ103へのアクセスを実現する,サービス提供サーバ103。」

第6.本願発明と引用発明との対比
1.引用発明における「サービス提供サーバ103」は,「クライアント102」からの要求を受け付けるものであって,「サーバ」が,「プロセッサ」,「メモリ」を有することは,当該技術分野における技術常識であるから,
引用発明における「サービス提供サーバ103」が,
本願発明における「システム」に相当し,
引用発明においても,「サービス提供サーバ103」が,「クライアント102」からの要求を受け取るために,当該「サービス提供サーバ103」が有する「プロセッサ」に,当該要求を受け取るための処理を行われるための「命令」が実行されることも明らかであり,
引用発明においては,「URL」は,「仲介サーバ101」によって生成され,「認証コード」と,「アクセス制限情報」を含むものであって,「クライアント102」から,「サービス提供サーバ103」へのアクセスの「要求」といい得るものであるから,
引用発明における「仲介サーバ」,「URL」,「認証コード」が,
本願発明における「第1のエンティティ」,「要求」,「認可情報」に相当するので,
引用発明における「仲介サーバ101がサービスメニュー又はユーザの要望に応じたアクセス制限情報をURLパラメータとしてURLのA1の部分に付加し,共通鍵Kcを用いて認証コードを生成し,認証コードを前記URLのA3の部分に付加して,前記URLにてサービス提供サーバ103への接続方法をクライアント102に通知し,前記クライアント102は,前記URLを辿って,サービス提供サーバ103にアクセスを要求し,
サービス提供サーバは103がクライアントから提示されたURL」と,
本願発明における「システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び暗号化鍵を含む予め生成された一部分を含む,受け取らせること」とは,
“システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び他の情報を含む予め生成された一部分を含む,受け取らせること”である点で共通する。

2.引用発明においては,「サービス提供サーバ103」が,「クライアント102」が提示する「URL」に含まれる「認証コード」を検証して,URLが正当である場合に,「クライアント102」の要求を受け付けるものであるから,
上記1.において検討した事項と併せると,
引用発明における「サービス提供サーバは103がクライアントから提示されたURLに含まれる認証コード部分を検証することにより,前記URLの正当性を確認し,クライアント102が所望するサービス提供サーバ103へのアクセスを実現する」ことと,
本願発明における「認可情報が,前記要求を満たすために前記第1のエンティティによって認可を示すと判定されることを条件として,前記暗号化鍵を使用して1つまたは複数の動作を行わせること」とは,
“認可情報が,要求を満たすために第1のエンティティによって認可を示すと判定されることを条件として,要求を実行する”点で共通する。

3.以上,上記1.,及び,2.において検討した事項から,本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
システムであって,
1つまたは複数のプロセッサと,
命令を含むメモリと,を備え,該命令は,前記1つまたは複数のプロセッサによって実行された場合には,前記システムに,
要求側からの要求を受け取らせることであって,前記要求は,第1のエンティティによって生成された認可情報及び他の情報を含む予め生成された一部分を含む,受け取らせること,
前記認可情報が,前記要求を満たすために第1のエンティティによって認可を示すと判定されることを条件として,前記要求を実行する,システム。

[相違点1]
“(要求側からの要求に含まれる)他の情報”に関して,
本願発明においては「暗号化鍵」であるのに対して,
引用発明においては,「アクセス制限情報」であって,「暗号化鍵」を含む点については,言及されていない点。

[相違点2]
“要求を実行する”に関して,
本願発明においては,「暗号化鍵を使用して1つまたは複数の動作を行わせること」と,「前記行った1つまたは複数の動作の結果を提供させること」であるのに対して,
引用発明においては,「暗号化鍵」を用いた処理と,その結果の提供については,言及されていない点。

第7.相違点についての当審の判断
1.[相違点1]について
上記Cに引用した,引用文献2の「If the file and/or document information stored is encrypted, an embedded decryption key and algorithm 625 could optionally be specified.(もし,格納されているファイル,及び/または,ドキュメント情報が,暗号化されるのであれば,組み込まれた暗号鍵と,アルゴリズム625が,任意に指定され得る。)」という記載,上記Dに引用した,引用文献2のFIG.6に開示の,特に,項目625に関する事項,上記Eに引用した,引用文献3の「 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. (この領域は,RPS14,及び/または,RDS16のウェブ・サーバ24,30の間で転送されるデータを,暗号化,或いは,復号するために用いられる,鍵情報を示している。)」という記載,上記Fに引用した,引用文献3の「[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([0154] それ故,資源アクセス権データは,WAD12に要求された資源へつながる,ファイルパスの一部となる。付加変数方法は,異なる形を与える:
[0155] http://www.content-server.com/path1/path2/file.ext?secure_resource_access_right_data)」という記載,及び,上記Gに引用した,引用文献3のFIGURE 10Aに開示の,特に,「RETRIEVAL KEY DATA」という項目から,「URL」に,暗号化,復号のための「鍵」を組み込むことは,本願の第1国出願前に,当業者には広く知られた技術事項であり,当該「URL」を送ることは,一種の「要求」と言い得るものであるから,
したがって,引用発明においても,(要求側からの要求としての)「URL」に,「暗号化鍵」を組み込むことは,提供する「サービス」に応じて,当業者が適宜選択し得る事項である。
よって,[相違点1]は,格別のものではない。

2.[相違点2]について
上記1.において言及した,引用文献2,及び,引用文献3に記載の内容から,「URL」に組み込まれた「暗号化鍵」を用いて,情報の「暗号化」,或いは,「復号」を行って提供する「サービス」を実行することは,本願の第1国出願前に,当業者には広く知られた技術事項であった。
そして,当該「サービス」を提供することは,即ち,「動作の結果を提供する」ことであるから,
したがって,引用発明においても,(要求側からの要求としての)「URL」に組み込まれた「暗号化鍵」を用いた「動作の結果を提供する」よう構成することは,当業者が適宜なし得る事項である。
よって,[相違点2]は,格別のものではない。

3.以上,上記1.,及び,2.において検討したとおり,[相違点1],及び,[相違点2]は,格別のものではなく,そして,本願発明の構成によってもたらされる効果も,当業者であれば容易に予測できる程度のものであって,格別なものとは認められない。

なお,本願の請求項1に係る発明における発明特定事項である「暗号化鍵」に,「第1のエンティティによって生成された」と言った限定事項を付加したとしても,「鍵」を「URL」に埋め込む者が,当該「鍵」を生成するよう構成するという態様自体,当業者には周知の技術事項である。
また,審判請求人は,本願発明と,引用発明とでは,課題が異なる旨主張しているが,上記において検討したとおり,本願発明は,引用発明と,引用文献2,及び,引用文献3に記載された技術から,当業者が容易に構築し得るものであるから,審判請求人の上記主張は採用できない。

第8.むすび
したがって,本願発明は,本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであるので,特許法第29条第2項の規定により特許を受けることができない。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2019-03-29 
結審通知日 2019-04-01 
審決日 2019-04-15 
出願番号 特願2016-542890(P2016-542890)
審決分類 P 1 8・ 55- Z (H04L)
P 1 8・ 121- Z (H04L)
最終処分 不成立  
前審関与審査官 平井 誠  
特許庁審判長 辻本 泰隆
特許庁審判官 山崎 慎一
石井 茂和
発明の名称 鍵を有するリソースロケーター  
代理人 伊藤 信和  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ