2018-007056

特願２０１５－５６２６７３「サービス提供方法、サービス要求方法、情報処理装置、及び、クライアント装置」拒絶査定不服審判事件〔平成２７年　８月２０日国際公開、ＷＯ２０１５／１２２００９、請求項の数（９）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，２０１４年２月１７日を国際出願日とする出願であって，平成２９年８月３１日付けで拒絶の理由が通知され，同年１１月１０日に意見書と共に手続補正書が提出され，平成３０年２月１９日付けで拒絶査定（謄本送達日同年２月２７日）がなされ，これに対して同年５月２３日に審判請求がなされると共に手続補正がなされ，同年７月３０日付けで審査官により特許法１６４条３項の規定に基づく報告がなされたものである。 第２　原査定の概要 原査定（平成３０年２月１９日付け拒絶査定）の概要は次のとおりである。 １．（新規性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。 ２．（進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 記　（引用文献等については引用文献等一覧参照） 備考 ●理由１（特許法第２９条第１項第３号：新規性） ・請求項　１、９ ・引用文献等　１ ●理由２（特許法第２９条第２項：進歩性） ・請求項　１～１０ ・引用文献等　１～５ ＜引用文献等一覧＞ １.結城 浩，簡単実装で学ぶWeb技術2006　第8回 Cookie--状態管理とトラッキング，日経ソフトウエア，日本，日経ＢＰ社，２００７年　１月，Vol. 10, No. 3，pp. 104-115 ２.特開２００３－３２３４０９号公報 ３.柳原 秀明ほか，権限管理に対応した認証・アクセス制御技術，FIT2002情報科学技術フォーラム　一般講演論文集，２００２年　９月，第4分冊，pp. 37-38，M-2 ４.特開２００６－２４３９２４号公報（周知技術を示す文献） ５.石田 勝美，Java & Director for Game Making　第5回　ユーザー情報の保存，Java WORLD，１９９９年　２月，Vol. 3, No. 2，pp. 123-128（周知技術を示す文献） 第３　本願発明 本願請求項１乃至９に係る発明（以下「本願発明１」乃至「本願発明９」という。）は，平成３０年５月２３日付け手続補正書によって補正された特許請求の範囲の請求項１乃至９に記載された，次のとおりのものと認める。 「　　【請求項１】 情報処理装置が、クライアント装置から受信したセッションの認証要求に応答して、認証に成功した場合に、前記セッションに関連するデータを生成するとともに当該データを含む前記認証に関するクッキーを生成し、前記クッキーと前記データとを前記クライアント装置に送信する送信工程と、 前記情報処理装置が、前記クライアント装置から、前記データがクエリパラメータとして付与されるＨＴＴＰリクエストと前記クッキーとを受信する受信工程と、 前記情報処理装置が、前記ＨＴＴＰリクエストが前記ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しないコンテンツの送信要求である場合、前記クッキーに含まれる前記データと、前記クエリパラメータとして付与される前記データとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する提供工程とを有し、 前記送信工程は、前記データを暗号化し、前記暗号化したデータを含むクッキーを送信する工程を含み、 前記提供工程は、前記クッキーに含まれる前記データを復号する工程と、前記クエリパラメータとして付与される前記データと前記復号したデータとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する工程と、を有するサービス提供方法。 【請求項２】 請求項１において、 前記送信工程は、前記データに加えて、さらに、前記情報処理装置が提供するサービス上の権限情報を含む認証トークンを含むクッキーを生成し、 前記提供工程は、前記クッキーに含まれる前記データと、前記クエリパラメータとして付与される前記データとが一致する場合に、前記クッキーに含まれる前記認証トークンの権限情報に基づいて、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供するサービス提供方法。 【請求項３】 請求項２において、 前記送信工程は、前記データ及び前記認証トークンを暗号化し、前記暗号化したデータと前記暗号化した認証トークンとを含むクッキーを送信する工程を含み、 前記提供工程は、前記クッキーに含まれる前記データと前記認証トークンとを復号する工程と、前記クエリパラメータとして付与される前記データと、前記復号したデータとが一致する場合に、前記復号した認証トークンの権限情報に基づいて、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する工程と、を有するサービス提供方法。 【請求項４】 請求項１乃至３のいずれかにおいて、 前記送信工程で生成するデータは、数字、文字のいずれかまたは両方をランダムに有するデータであることを特徴とするサービス提供方法。 【請求項５】 請求項１乃至４のいずれかにおいて、さらに、 前記クライアント装置が実行するウェブブラウザが、前記クッキーを当該ウェブブラウザがアクセスする第１のメモリ領域に格納するとともに、前記ウェブブラウザを介して動作し前記認証要求を送信したアプリケーションが、前記受信したデータを当該アプリケーションによって使用され、かつ、前記アプリケーションの終了に応じて解放される第２のメモリ領域に格納する格納工程と、を有するサービス提供方法。 【請求項６】 請求項１において、 前記コンテンツの送信要求は、ＨＴＭＬタグに基づく要求であるサービス提供方法。 【請求項７】 情報処理装置と接続するクライアント装置が実行するウェブブラウザを介して動作するアプリケーションが前記情報処理装置に送信した認証要求に応答して、セッションに関連するデータを含む前記認証要求に関するクッキーと前記データとを前記情報処理装置から受信する受信工程と、 前記ウェブブラウザが、前記受信したクッキーを当該ウェブブラウザがアクセスする第１のメモリ領域に格納するとともに、前記認証要求を送信したアプリケーションが、前記受信したデータを当該アプリケーションによって使用され、かつ、前記アプリケーションの終了に応じて解放される第２のメモリ領域に格納する格納工程と、 前記ウェブブラウザは、前記データをクエリパラメータとして付与した、ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しない形式のコンテンツの送信要求である前記ＨＴＴＰリクエストを、前記クッキーとともに前記情報処理装置に送信する送信工程とを有し、 前記受信工程は、前記データを暗号化し、前記暗号化したデータを含むクッキーを受信する工程を含み、 前記情報処理装置は、クッキーに含まれる前記データを復号し、前記クエリパラメータとして付与される前記データと前記復号したデータとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する サービス要求方法。 【請求項８】 プロセッサと、 サービス要求の対象となる情報を記憶するメモリと、を有し、 前記プロセッサは、クライアント装置から受信したセッションの認証要求に応答して、認証に成功した場合に、前記セッションに関連するデータを生成するとともに当該データを含む前記認証に関するクッキーを生成し、前記クッキーと前記データとを前記クライアント装置に送信し、前記クライアント装置から、前記データがクエリパラメータとして付与されるＨＴＴＰリクエストと前記クッキーとを受信し、前記ＨＴＴＰリクエストが前記ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しないコンテンツの送信要求である場合、前記受信したクッキーに含まれる前記データと、前記クエリパラメータとして付与される前記データとが一致する場合に、前記メモリに記憶される情報を対象とする前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供するとともに、 前記データを暗号化し、前記暗号化したデータを含むクッキーを送信し、前記クッキーに含まれる前記データを復号する工程と、前記クエリパラメータとして付与される前記データと前記復号したデータとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する情報処理装置。 【請求項９】 プロセッサと、 ウェブブラウザがアクセスする第１のメモリ領域と、前記ウェブブラウザを介して動作するアプリケーションによって使用され、かつ、前記アプリケーションの終了に応じて解放される第２のメモリ領域とを備えるメモリと、を有し、 前記プロセッサは、前記アプリケーションが情報処理装置に送信した認証要求に応答して、前記セッションに関連するデータを含む前記認証に関するクッキーと前記データとを前記情報処理装置から受信し、前記受信したクッキーを前記第１のメモリ領域に格納するとともに、前記受信したデータを前記アプリケーションの前記第２のメモリ領域に格納し、前記データをクエリパラメータとして付与した、ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しない形式のコンテンツの送信要求であるＨＴＴＰリクエストを、前記クッキーとともに前記情報処理装置に送信し、前記データを暗号化し、前記暗号化したデータを含むクッキーを受信し、 前記情報処理装置は、前記クッキーに含まれる前記データを復号し、前記クエリパラメータとして付与される前記データと前記復号したデータとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供するクライアント装置。」 第４　引用例 １　引用例１に記載された事項及び引用発明 原査定の拒絶の理由において引用した，本願の出願前に既に公知である，「結城 浩，簡単実装で学ぶWeb技術2006　第8回 Cookie--状態管理とトラッキング，日経ソフトウエア，日本，日経ＢＰ社，２００７年　１月，Vol. 10, No. 3，pp. 104-115」（以下，これを「引用例１」という。）には，関連する図面と共に，次の事項が記載されている。（下線は当審で付加。以下同様。） Ａ　「Ｃｏｏｋｉｅとは Ｃｏｏｋｉｅを一言で説明すると「Ｗｅｂサーバー（ＨＴＴＰサーバー）からＷｅｂブラウザ（ＨＴＴＰクライアント）へ渡され，それ以降のアクセスでＷｅｂブラウザからＷｅｂサーバーに返される情報」です。でも，これではわかりにくいですね。順を追って説明しましょう。」（１０４ページ左欄５乃至１０行） Ｂ　「今月紹介するＣｏｏｋｉｅ（クッキー）は，複数のリクエストが，同じユーザーからのものかどうかをＷｅｂアプリケーション側で判断するための仕組みです。図２にＣｏｏｋｉｅを使って状態を管理している様子を示します。 まず，ＷｅｂブラウザがＷｅｂアプリケーションに対してリクエストＡを送ります。Ｗｅｂアプリケーションは，このリクエストＡに対して，ＷｅｂブラウザにレスポンスＡを返します。その際に，Ｃｏｏｋｉｅと呼ばれる情報をレスポンスＡに含めます。具体的には，以下のような１行がＨＴＴＰレスポンスのヘッダー部に付加されます。 Ｓｅｔ－Ｃｏｏｋｉｅ： ｋｅｙ１＝ｖａｌｕｅ１ この例では，ｋｅｙ１という名前のＣｏｏｋｉｅの値は「ｖａｌｕｅ１」である，ということを表しています。 Ｃｏｏｋｉｅを受け取ったＷｅｂブラウザは，今後，同じサーバーにリクエストを送信する際，このＣｏｏｋｉｅを自動的に付加します。図２ではリクエストＢに相当します。具体的には，以下のような１行がＨＴＴＰリクエストのヘッダー部に付加されます。 Ｃｏｏｋｉｅ： ｋｅｙ１＝ｖａｌｕｅ１ リクエストＢを受け取ったＷｅｂアプリケーションは，ヘッダーを調べ，先ほどレスポンスＡで送ったＣｏｏｋｉｅと同じものがやってきたことがわかります。これによって「レスポンスＡを受け取ったＷｅｂブラウザと，リクエストＢを送ってきたＷｅｂブラウザは同じ」と判断できるのです。」（１０４ページ右欄１３行乃至１０５ページ左欄２０行） Ｃ　「サンプル　ｂｏａｒｄ ログイン状態を管理する掲示板 Ｃｏｏｋｉｅの基本的な使い方は，ユーザーのログイン状態を管理することです。Ｃｏｏｋｉｅを使ってこの機能を実装したメッセージ・ボード（掲示板）を作ってみましょう。 １１１ページの表２にメッセージ・ボードのファイル一覧を示します。また，ｂｏａｒｄ．ｃｇｉでのＣｏｏｋｉｅの使い方を表すシーケンス図を図１３に示します。ログイン後に生成されるユニークなＩＤ（セッションＩＤ）をＣｏｏｋｉｅとしてＷｅｂブラウザに保存します。そして，有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られてきたら「ログインしているユーザーからのアクセス」であると判断します。 コードを紹介する前に，ｂｏａｒｄ．ｃｇｉの実行の様子を見てみましょう。ＣＧＩとして設置したｂｏａｒｄ．ｃｇｉをＷｅｂブラウザで表示すると，図１４のようなログイン画面が表示されます。ここでユーザー名とパスワードを入れると「ログインしました」という画面になります（図１５）。ログインするとメッセージを書き込むことができます（図１６）。「ログアウト」のリンクをたどるとＣｏｏｋｉｅは削除され，ログアウトしたことになります（図１７）。」（１１３ページ左欄１乃至２４行） Ｄ 図１３ ア　上記記載事項Ａ及びＢから，引用例１には，“Ｗｅｂサーバー（ＨＴＴＰサーバー）からＷｅｂブラウザ（ＨＴＴＰクライアント）へ渡され，それ以降のアクセスでＷｅｂブラウザからＷｅｂサーバーに返される情報であるＣｏｏｋｉｅであって，当該Ｃｏｏｋｉｅは，複数のリクエストが，同じユーザーからのものかどうかをＷｅｂアプリケーション側で判断するための仕組みであり， まず，ＷｅｂブラウザがＷｅｂアプリケーションに対してリクエストＡを送り，Ｗｅｂアプリケーションは，このリクエストＡに対して，ＷｅｂブラウザにレスポンスＡを返し，その際に，Ｃｏｏｋｉｅと呼ばれる情報をＨＴＴＰレスポンスのヘッダー部に付加してレスポンスＡに含め， Ｃｏｏｋｉｅを受け取ったＷｅｂブラウザは，今後，同じサーバーにリクエストを送信する際，このＣｏｏｋｉｅを自動的に付加し， リクエストＢを受け取ったＷｅｂアプリケーションは，ヘッダーを調べ，先ほどレスポンスＡで送ったＣｏｏｋｉｅと同じものがやってきたことがわかり，これによって「レスポンスＡを受け取ったＷｅｂブラウザと，リクエストＢを送ってきたＷｅｂブラウザは同じ」と判断でき”ることが記載されているといえる。 イ　上記記載事項Ｃの「Ｃｏｏｋｉｅを使ってこの機能を実装したメッセージ・ボード（掲示板）を作ってみましょう」との記載から，引用例１には，“Ｃｏｏｋｉｅを利用した掲示板などのサービス提供方法”について記載されているといえる。 ウ　上記記載事項Ｃから，引用例１には，“ログイン後に生成されるユニークなＩＤ（セッションＩＤ）をＣｏｏｋｉｅとしてＷｅｂブラウザに保存し，有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られてきたら「ログインしているユーザーからのアクセス」であると判断し， ＣＧＩとして設置したｂｏａｒｄ．ｃｇｉをＷｅｂブラウザで表示すると，ログイン画面が表示され，ここでユーザー名とパスワードを入れると「ログインしました」という画面になり，ログインするとメッセージを書き込むことができ”ることが記載されているといえる。 エ　上記Ｄに示した図１３から，次の事項を読み取ることができる。 まず，図１３は，「ｂｏａｒｄ．ｃｇｉ」という掲示板サービスを提供するＷｅｂアプリケーションにおける，「ユーザー」と当該「ｂｏａｒｄ．ｃｇｉ」間の情報のやりとりを示したものであることを読み取ることができる。そして当該「ユーザー」は，上記アでいう，「Ｗｅｂブラウザ（ＨＴＴＰクライアント）」側にあり，「ｂｏａｒｄ．ｃｇｉ」は，同じく「Ｗｅｂサーバー（ＨＴＴＰサーバー）」側にあるものであることは当業者に明らかである。 図１３中，「（３）ユーザー名＋パスワード」が「ｂｏａｒｄ．ｃｇｉ」に送られていることから，引用例１には，“Ｗｅｂブラウザ（ＨＴＴＰクライアント）から送られたユーザー名＋パスワードをＷｅｂサーバー（ＨＴＴＰサーバー）で受信”することが記載されているといえる。 また，「ｂｏａｒｄ．ｃｇｉ」で，当該「ユーザー名＋パスワード」を受信した後に，「正規のユーザー名とパスワードなら，新しいセッションＩＤを発行し，ユーザーと関連づけする」こと，および「（４）セッションＩＤをＣｏｏｋｉｅとして返す」ことも図１３に記載されていて，このことから，引用例１には，“正規のユーザー名とパスワードなら，新しいセッションＩＤを発行し，ユーザーと関連づけし，セッションＩＤをＣｏｏｋｉｅとしてＷｅｂブラウザ（ＨＴＴＰクライアント）に送信”することが記載されているといえる。 オ　以上上記ア乃至エより，引用例１には，次の発明（以下「引用発明」という。）が記載されているといえる。 「Ｃｏｏｋｉｅは，複数のリクエストが，同じユーザーからのものかどうかをＷｅｂアプリケーション側で判断するための仕組みであり，Ｗｅｂサーバー（ＨＴＴＰサーバー）からＷｅｂブラウザ（ＨＴＴＰクライアント）へ渡され，それ以降のアクセスでＷｅｂブラウザからＷｅｂサーバーに返される情報であり， まず，ＷｅｂブラウザがＷｅｂアプリケーションに対してリクエストＡを送り，Ｗｅｂアプリケーションは，このリクエストＡに対して，ＷｅｂブラウザにレスポンスＡを返し，その際に，Ｃｏｏｋｉｅと呼ばれる情報をＨＴＴＰレスポンスのヘッダー部に付加してレスポンスＡに含め，Ｃｏｏｋｉｅを受け取ったＷｅｂブラウザは，今後，同じサーバーにリクエストを送信する際，このＣｏｏｋｉｅを自動的に付加し， リクエストＢを受け取ったＷｅｂアプリケーションは，ヘッダーを調べ，先ほどレスポンスＡで送ったＣｏｏｋｉｅと同じものがやってきたことがわかり，これによって「レスポンスＡを受け取ったＷｅｂブラウザと，リクエストＢを送ってきたＷｅｂブラウザは同じ」と判断できることを前提とし， Ｃｏｏｋｉｅを利用した掲示板などのサービス提供方法であって， Ｗｅｂブラウザ（ＨＴＴＰクライアント）から送られたユーザー名＋パスワードをＷｅｂサーバー（ＨＴＴＰサーバー）で受信し， 正規のユーザー名とパスワードなら，新しいセッションＩＤを発行し，ユーザーと関連づけし，セッションＩＤをＣｏｏｋｉｅとしてＷｅｂブラウザ（ＨＴＴＰクライアント）に送信し， ログイン後に生成されるユニークなＩＤ（セッションＩＤ）をＣｏｏｋｉｅとしてＷｅｂブラウザに保存し，有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られてきたら「ログインしているユーザーからのアクセス」であると判断し， ＣＧＩとして設置したｂｏａｒｄ．ｃｇｉをＷｅｂブラウザで表示すると，ログイン画面が表示され，ここでユーザー名とパスワードを入れると「ログインしました」という画面になり，ログインするとメッセージを書き込むことができる， Ｃｏｏｋｉｅを利用した掲示板などのサービス提供方法。」 ２　引用例２に記載された事項 原査定の拒絶の理由において引用した，本願の出願前に既に公知である，特開２００３－３２３４０９号公報（平成１５年１１月１４日公開。以下，これを「引用例２」という。）には，関連する図面と共に，次の事項が記載されている。 Ｅ　「【００２６】そして、クッキーが含まれていなかったときには、第１認証用データをユーザコンピュータ４０に要求する（ステップＳ１４０）。即ち、ユーザＩＤの入力欄とパスワードの入力欄が設けられたログイン画面をユーザコンピュータ４０に送信する。その後、第１認証用データをユーザコンピュータ４０から受信する（ステップＳ１５０）。即ち、各入力欄にユーザＩＤ及びパスワードが入力されたログイン画面をユーザコンピュータ４０から受信する。続いて、受信した第１認証用データが記憶装置１６に記憶されている認証用ＤＢに登録されているか否かを判定し（ステップＳ１６０）、登録されていないときにはエラーメッセージ（例えば「入力されたユーザＩＤとパスワードが正しくありません。」など）をユーザコンピュータ４０へ送信し（ステップＳ１７０）、この要求応答処理を終了する。一方、受信した第１認証用データが認証用ＤＢに登録されていたときには、その第１認証用データに対応する個人顧客コードを認証用ＤＢから読み出し（ステップＳ１８０）、読み出した個人顧客コードを有効期限とセッションＩＤを付けて暗号化する（ステップＳ１９０）。ここで、セッションＩＤは、セッションごとに付与される連番である。次いで、暗号化した個人顧客コード、有効期限及びセッションＩＤを含むクッキーを作成し（ステップＳ１９５）、ステップＳ１００で受信したアクセス要求に応じたウェブページと共にこのクッキーをユーザコンピュータ４０へ送信し（ステップＳ２００）、この要求応答処理を終了する。すると、ユーザコンピュータ４０はこのクッキーを受信して所定の保存場所に保存する。なお、セッションＩＤはユーザコンピュータ４０との接続が切断されるごとに第１ウェブサーバ１２において無効化されるＩＤである。 【００２７】さて、ステップＳ１３０において、ユーザコンピュータ４０から受信したデータにクッキーが含まれていたときにはこのクッキーに含まれる暗号化データを復号化して個人顧客コード、有効期限及びセッションＩＤとし（ステップＳ２１０）、復号化した個人顧客コードが有効か否かを判定する（ステップＳ２２０）。この判定は、復号化したデータに含まれる有効期限やセッションＩＤに基づいて行う。具体的には、有効期限内で且つセッションＩＤが無効化されていないときには個人顧客コードが有効、それ以外の時には個人顧客コードが無効と判定する。そして、個人顧客コードが有効でなかったときには、前述したステップＳ１４０以下の処理を行い、一方、個人顧客コードが有効だったときには、第１認証用データをユーザコンピュータ４０に要求することなく、ステップＳ１００で受信したアクセス要求に応じたウェブページをユーザコンピュータ４０へ送信し（ステップＳ２３０）、この要求応答処理を終了する。」 ３　引用例３に記載された事項 原査定の拒絶の理由において引用した，本願の出願前に既に公知である，「柳原 秀明ほか，権限管理に対応した認証・アクセス制御技術，FIT2002情報科学技術フォーラム　一般講演論文集，２００２年　９月，第4分冊，pp. 37-38，M-2」（以下，これを「引用例３」という。）には，関連する図面と共に，次の事項が記載されている。 Ｆ　「１． はじめに ＩＴ化の進展に伴い、インターネットやイントラネットを介して膨大な情報から必要なデータに迅速にアクセスできる環境となってきている反面、不正アクセスによる機密情報の漏洩といった情報セキュリティ上の犯罪が後を絶たないのが現状である。また、既存の業務アプリケーションに加え、電子決裁など新たな業務アプリケーションが増えるに従い、情報システム利用者のログイン操作が煩雑になり、安易な文字列の使用やメモ書き等によるパスワードのずさんな管理によって、成りすましによる不正アクセスの温床が多々存在しているのも非常に問題となっている。 そのため、組織・個人の権限管理、権限に応じたアクセス制御、一回の認証で複数のアプリケーションを利用可能とするシングルサインオンやバイオメトリクスによる個人識別を行える情報システム利用環境が求められる。 本稿では、これら要件に応じたＷｅｂ業務アプリケーションの認証・アクセス制御システムに要する技術の抽出と実現方式について報告する。 …（中略）… ３．２　処理権限チケット 認証完了時に、利用者の権限情報を処理権限チケットとして利用者に発行する。処理権限チケットはＷｅｂのＣｏｏｋｉｅとしてクライアント側に保存され、同一ドメインに属するＷｅｂサーバで参照可能である。」（３７ページ左欄１行乃至３８ページ左欄下から２行） ４　引用例４に記載された事項 原査定の拒絶の理由において引用した，本願の出願前に既に公知である，特開２００６－２４３９２４号公報（平成１８年９月１４日公開。（以下，これを「引用例４」という。）には，関連する図面と共に，次の事項が記載されている。 Ｇ　「【０００４】 クッキーを使用する場合、ウェブブラウザの画面上でユーザ名とパスワードが入力され、ログイン実行ボタンが押されると、サーバは、入力されたユーザ名とパスワード、又はその暗号化されたデータ、或いは登録されたユーザであることが確認された場合のみに乱数により発行されるセッションＩＤを入れたクッキーを応答ヘッダ内に記述されるデータとして発行する。それ以降、ウェブブラウザは、アクセス毎に応答ヘッダ内にそのデータを入れて送出するので、サーバはそのクッキーのデータに基づきユーザを特定し、そのユーザに対し一貫性のあるデータ処理及びサービス提供を行うことができる。」 ５　引用例５に記載された事項 原査定の拒絶の理由において引用した，本願の出願前に既に公知である，「石田 勝美，Java & Director for Game Making　第5回　ユーザー情報の保存，Java WORLD，１９９９年　２月，Vol. 3, No. 2，pp. 123-128」（以下，これを「引用例５」という。）には，関連する図面と共に，次の事項が記載されている。 Ｈ　「Ｃｏｏｋｉｅの仕組み さて、本誌読者の方であれば、Ｃｏｏｋｉｅについてはすでにご存じだろう。だが、その詳しい仕組みまではご存じない方もおられるかもしれない。そこで以下に、Ｃｏｏｋｉｅの仕組みについて少し説明しておこう。 Ｃｏｏｋｉｅは、ユーザーがＷｅｂサイトを閲覧した際の情報を保存し、その情報に基づいたＷｅｂコンテンツをユーザーに提供するためにネットスケープが考案した、リモートからユーザーのローカル・ディスクに情報を書き込むための仕組みである（ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｓｃａｐｅ．ｃｏｍ／ｎｅｗｓｒｅｆ／ｓｔｄ／ｃｏｏｋｉｅ＿ｓｐｅｃ．ｈｔｍｌ）。これにより、ユーザー情報をＣｏｏｋｉｅと呼ばれる小さなデータとしてユーザーのローカル・ディスクに保存することが可能となるのだ。 …（中略）… ただし、ＣｏｏｋｉｅはあくまでＷｅｂブラウザの機能であるため、これをＪａｖａアプレットから直接操作することはできない。ＪａｖａアプレットでＣｏｏｋｉｅを操作するには、「ＬｉｖｅＣｏｎｎｅｃｔ」に対応したＷｅｂブラウザ上でＪａｖａＳｃｒｉｐｔを経由してアクセスしなければならないのだ。現在、このＬｉｖｅＣｏｎｎｅｃｔに対応したＷｅｂブラウザとしては、ＮａｖｉｇａｔｏｒのほかにＩＥ４．０などがある。これらのＷｅｂブラウザでＬｉｖｅＣｏｎｎｅｃｔを使用するには、ブラウザの設定でＪａｖａ、ＪａｖａＳｃｒｉｐｔ、Ｃｏｏｋｉｅの使用を有効にしておけばよい（画面１～４）。 …（中略）… ちなみに、一度に書き込めるＣｏｏｋｉｅの数は１つ。１つのＣｏｏｋｉｅのサイズは約４ＫＢ以下に制限されている。また、オプション・プロパティを設定していないと、多くのＷｅｂブラウザはＣｏｏｋｉｅをローカル・ディスクではなくメモリ上に保持し、セッションが終了した時点で消去してしまう。したがって、ゲーム・ユーザーの成績を残すためには、これらのオプション・プロパティを適切に設定しておく必要がある。」（１２４ページ中欄２５行乃至１２５ページ中欄２５行） 第５　対比・判断 １　本願発明１について （１）対比 本願発明１と引用発明とを対比する。 （あ）引用発明の「Ｗｅｂサーバー（ＨＴＴＰサーバー）」，「Ｗｅｂブラウザ（ＨＴＴＰクライアント）」，及び「Ｃｏｏｋｉｅ」はそれぞれ，本願発明１の「情報処理装置」，「クライアント装置」，及び「クッキー」に相当する。 （い）引用発明において，「ＷｅｂブラウザからＷｅｂサーバーに返される情報である」ところの「Ｃｏｏｋｉｅ」を利用した「掲示板などのサービス提供方法」は，サービスを提供する方法で共通し，本願発明１の「サービス提供方法」に相当する。 （う）引用発明において，「まず，ＷｅｂブラウザがＷｅｂアプリケーションに対してリクエストＡを送り，Ｗｅｂアプリケーションは，このリクエストＡに対して，ＷｅｂブラウザにレスポンスＡを返し，その際に，Ｃｏｏｋｉｅと呼ばれる情報をＨＴＴＰレスポンスのヘッダー部に付加してレスポンスＡに含め，Ｃｏｏｋｉｅを受け取ったＷｅｂブラウザは，今後，同じサーバーにリクエストを送信する際，このＣｏｏｋｉｅを自動的に付加」すること，及び「リクエストＢを受け取ったＷｅｂアプリケーションは，ヘッダーを調べ，先ほどレスポンスＡで送ったＣｏｏｋｉｅと同じものがやってきたことがわかり，これによって「レスポンスＡを受け取ったＷｅｂブラウザと，リクエストＢを送ってきたＷｅｂブラウザは同じ」と判断できることを前提」とし，「Ｗｅｂブラウザ（ＨＴＴＰクライアント）から送られたユーザー名＋パスワードをＷｅｂサーバー（ＨＴＴＰサーバー）で受信し」，「正規のユーザー名とパスワードなら，新しいセッションＩＤを発行し，ユーザーと関連づけし，セッションＩＤをＣｏｏｋｉｅとしてＷｅｂブラウザ（ＨＴＴＰクライアント）に送信」することのうち，「Ｗｅｂブラウザ（ＨＴＴＰクライアント）」から「ユーザー名＋パスワード」を「Ｗｅｂサーバー（ＨＴＴＰサーバー）」に送ることが，「認証要求」にあたり，「正規のユーザー名とパスワード」の時に「発行」される「新しいセッションＩＤ」は，「認証に成功した場合」に「生成」される，「前記セッションに関連するデータ」といい得ることから，引用発明の「Ｗｅｂブラウザ（ＨＴＴＰクライアント）から送られたユーザー名＋パスワードをＷｅｂサーバー（ＨＴＴＰサーバー）で受信し」，「正規のユーザー名とパスワードなら，新しいセッションＩＤを発行し，ユーザーと関連づけし，セッションＩＤをＣｏｏｋｉｅとしてＷｅｂブラウザ（ＨＴＴＰクライアント）に送信」することと本願発明１の「情報処理装置が、クライアント装置から受信したセッションの認証要求に応答して、認証に成功した場合に、前記セッションに関連するデータを生成するとともに当該データを含む前記認証に関するクッキーを生成し、前記クッキーと前記データとを前記クライアント装置に送信する送信工程」とは，上記（あ）での検討を踏まえ，下記の点（相違点１）で異なるものの，“情報処理装置が，クライアント装置から受信したセッションの認証要求に応答して，認証に成功した場合に，前記セッションに関連するデータを生成するとともに当該データを含む前記認証に関するクッキーを生成し，前記クッキーを前記クライアント装置に送信する送信工程”である点で一致するといえる。 （え）引用発明は「Ｃｏｏｋｉｅを受け取ったＷｅｂブラウザは，今後，同じサーバーにリクエストを送信する際，このＣｏｏｋｉｅを自動的に付加」し，「リクエストＢを受け取ったＷｅｂアプリケーションは，ヘッダーを調べ，先ほどレスポンスＡで送ったＣｏｏｋｉｅと同じものがやってきたことがわかり，これによって「レスポンスＡを受け取ったＷｅｂブラウザと，リクエストＢを送ってきたＷｅｂブラウザは同じ」と判断でき」ることを前提としていて，「Ｗｅｂアプリケーション」で受け取る「リクエストＢ」の「ヘッダー」に含まれる「Ｃｏｏｋｉｅ」は，本願発明１の「前記クッキーとを受信する受信工程」において受信する「前記クッキー」といい得ることから，下記の点（相違点２）で相違するものの，引用発明と本願発明１とは，“前記情報処理装置が，前記クライアント装置から，前記クッキーを受信する受信工程”を有する点で一致する。 （お）引用発明において，「ＣＧＩとして設置したｂｏａｒｄ．ｃｇｉをＷｅｂブラウザで表示」した上，「ログイン画面が表示され，ここでユーザー名とパスワードを入れると「ログインしました」という画面になり，ログインするとメッセージを書き込むことができる」ことのうち，「メッセージを書き込むことができる」とは，「Ｃｏｏｋｉｅを利用した掲示板などのサービス」が提供されていることを意味することから，本願発明１の「ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する」ことと対応するといえるから，下記の点（相違点３）で相違するものの，引用発明と本願発明１とは，“ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する提供工程”を有する点で一致するといえる。 （か）以上，（あ）乃至（お）の検討から，引用発明と本願発明１とは，次の一致点及び相違点を有する。 〈一致点〉 情報処理装置が，クライアント装置から受信したセッションの認証要求に応答して，認証に成功した場合に，前記セッションに関連するデータを生成するとともに当該データを含む前記認証に関するクッキーを生成し，前記クッキーを前記クライアント装置に送信する送信工程と， 前記情報処理装置が，前記クライアント装置から，前記クッキーを受信する受信工程と， ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する提供工程とを有するサービス提供方法。 〈相違点１〉 本願発明１が，送信工程において，「認証に関するクッキー」のほかに，「セッションに関連するデータ」も送信するものであるのに対し，引用発明は，「セッションＩＤをＣｏｏｋｉｅとしてＷｅｂブラウザ（ＨＴＴＰクライアント）に送信」するに過ぎない点。 〈相違点２〉 本願発明１が，受信工程において，「クッキー」のほかに，「前記データがクエリパラメータとして付与されるＨＴＴＰリクエスト」も受信するものであるのに対し，引用発明は，「有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られて」くるに過ぎない点。 〈相違点３〉 本願発明１が，「前記情報処理装置が、前記ＨＴＴＰリクエストが前記ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しないコンテンツの送信要求である場合、前記クッキーに含まれる前記データと、前記クエリパラメータとして付与される前記データとが一致する場合に」，サービスをクライアント装置に提供するのに対して，引用発明は，「有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られてきたら「ログインしているユーザーからのアクセス」であると判断」した上，「ログインするとメッセージを書き込むことができる」，すなわちサービスをクライアント装置に提供するものである点。 〈相違点４〉 本願発明１が，送信工程において，「前記データを暗号化し、前記暗号化したデータを含むクッキーを送信する工程を含」み，さらに提供工程が，「前記クッキーに含まれる前記データを復号する工程と、前記クエリパラメータとして付与される前記データと前記復号したデータとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する工程」であるのに対し，引用発明は，データの暗号化及び復号化について特定されていない点。 （２）相違点についての判断 事案に鑑み，先に相違点２及び３について検討する。 引用発明は「有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られ」，「有効なセッションＩＤがＣｏｏｋｉｅとしてｂｏａｒｄ．ｃｇｉに送られてきたら「ログインしているユーザーからのアクセス」であると判断」した上，「ログインするとメッセージを書き込むことができる」，すなわちサービスをクライアント装置に提供するものであることから，「クライアント装置」から，「前記データ」，すなわち「セッションに関連するデータ」たる，実施例でいうところのＣｏｏｋｉｅ＿ｐｅｅｒを「情報処理装置」に送信し，当該「情報処理装置」において受け取るものではなく，これを「クエリパラメータとして付与されるＨＴＴＰリクエスト」に含めるものでもない。 そして，引用発明の「情報処理装置」が「前記ＨＴＴＰリクエストが前記ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しないコンテンツの送信要求」を受け取る態様自体は想定され得たとしても，上記のとおり，そもそも引用発明は，「セッションに関連するデータ」たる，実施例でいうところのＣｏｏｋｉｅ＿ｐｅｅｒをやりとりするものではないことから，これをクライアント装置から送信し，「情報処理装置」が受け取る態様を想起できず，そのような技術的事項は，その他上記引用例２乃至５の中にも見いだせず，当業者にとって自明な事項ともいえない。 したがって，上記その余の相違点について判断するまでもなく，本願発明１は，当業者であっても，引用発明及び引用例２乃至５に記載された技術的事項に基づいて容易に発明できたものとはいえない。 ２　本願発明２乃至６について 本願発明２乃至６は，本願発明１を直接ないし間接的に引用するものであるから，本願発明１と同じ理由により、当業者であっても、引用発明及び引用例２乃至５に記載された技術的事項に基づいて容易に発明できたものとはいえない。 ３　本願発明７について 本願発明７は，本願発明１の「前記情報処理装置が、前記ＨＴＴＰリクエストが前記ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しないコンテンツの送信要求である場合、前記クッキーに含まれる前記データと、前記クエリパラメータとして付与される前記データとが一致する場合に、前記ＨＴＴＰリクエストに対応するサービスを前記クライアント装置に提供する提供工程」に対応する「前記ウェブブラウザは、前記データをクエリパラメータとして付与した、ＨＴＴＰリクエストのＡｕｔｈｏｒｉｚａｔｉｏｎヘッダに認証データを付与しない形式のコンテンツの送信要求である前記ＨＴＴＰリクエストを、前記クッキーとともに前記情報処理装置に送信する送信工程」との構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用例２乃至５に記載された技術的事項に基づいて容易に発明できたものとはいえない。 ４　本願発明８，９について 本願発明８及び９は，それぞれ本願発明１及び本願発明７と単にカテゴリー表現が異なるのみであるから，本願発明１及び本願発明７と同じ理由により、当業者であっても、引用発明及び引用例２乃至５に記載された技術的事項に基づいて容易に発明できたものとはいえない。 第６　原査定について １　理由１（特許法２９条１項３号）について 審判請求時の補正により，本願発明１及び９は上記相違点４に係る構成を有するものとなった。さらに本願発明１及び９は，上記相違点１乃至３の点においても引用文献１に記載された発明とは異なっており，原査定の理由１を維持することはできない。 ２　理由２（特許法２９条２項）について 本願発明１乃至９は，上記のとおり，上記相違点３に係る構成を有するものであって，当該事項は原査定で引用された引用文献１乃至５の何れにも記載が無く，これらの文献に基づいて当業者が容易になし得たとはいえないから，原査定の理由２を維持することはできない。 第７　むすび 以上のとおり，原査定の理由によっては，本願を拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。