【事件の表示】
　特願２００１−１４２６５５「顧客認証システム及び方法」拒絶査定不服審判事件〔平成１４年　２月　８日出願公開、特開２００２−　４２０３２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本願は，平成１３年５月１４日（優先権主張平成１２年５月１５日）の出願であって，平成１７年５月１１日付けで拒絶査定がなされ，これに対し，同年６月１５日に審判請求がされるとともに，同日付けで手続補正がなされた。
　その後，当審において，平成２０年４月１日付け審尋に対する回答はなく，平成２１年２月２３日付け拒絶の理由の通知に対し，平成２１年４月１７日付けで手続補正がなされたものである。
　
　
２．本願発明
　
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２１年４月１７日付け手続補正により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「【請求項１】
　顧客の端末及び店舗のコンピュータと通信を行うコンピュータ・システムであって，
　前記店舗のコンピュータ又は前記顧客の端末から，前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求と共に当該顧客認証要求に係る顧客の端末の情報及び当該店舗の識別情報を受信した場合に，受信した前記店舗の識別情報を用いて，前記店舗の識別情報が正しいかを確認する処理である当該店舗に対する認証処理又は前記店舗の識別情報が予め登録されたものであるかを確認する処理である当該店舗の確認処理を実施する手段と，
　前記店舗に対する認証処理又は前記店舗の確認処理の結果が肯定的である場合に，前記顧客認証要求に係る顧客の端末からの応答であることを確かめるためのキーを生成して当該キーを前記顧客の端末に送信する認証確認手段と，
　前記顧客の端末からキーを受信すると当該キーの正当性確認処理を実施し，前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し，前記キーの正当性確認処理結果及び前記顧客に対する認証処理結果が肯定的である場合に，前記店舗のコンピュータに顧客認証要求に係る前記顧客に対する認証処理結果が肯定的であったことを示す情報を送信する顧客認証手段と，
　を有し，
　前記正当性確認処理が，前記顧客の端末から受信したキーが，前記認証確認手段によって生成されたキーと同一であることを確認する処理を含む
　コンピュータ・システム。」
　
　
３．当審の拒絶の理由について
　
　当審において，平成２１年２月２３日付けで通知した拒絶の理由の概要は以下のとおりである。
　
「［理由Ａ］
　本件出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
（中略）
　
　　　　　記　　　（引用文献等については引用文献等一覧参照） 
　
引用文献等一覧
　
１．大竹剛，アコム　毎月２割が利用する電子決済，１万会員突破の「アコシス」，日経マルチメディア，日経ＢＰ社，1998年9月15日，第39号，p.98〜103
２．アコム／アコシス  バーチャルでクレジット決済を可能にしたアコシス今後２〜３年で採算ベースに，ＣａｒｄＷａｖｅ，株式会社シーメディア，1997年08月10日，第10巻，第9号，p.18〜19
３．特開平１１−３１６７２９号公報
　
（以下略）」
　
　
４．審判請求人の主張の概要
　
　審判請求人は，平成２１年４月１７日付け意見書において，以下の点を主張している。
　
「しかし，周知例記載のセッション識別子は，例えば認証対象者と認証実施者との間において，認証成功後は再度認証を行うことなく通信するために，認証対象者と認証実施者との間で送受信されるものである。これに対し，本請求項における「キー」は，認証実施者（コンピュータ・システム）によって認証対象者（店舗のコンピュータ）の認証が行われた後に，認証実施者から，認証対象者とは異なる第三者（顧客の端末）に送信されるものであり，周知例記載のセッション識別子とは性質が異なる。例えば，認証対象者以外の第三者にセッション識別子を送信するとなると，第三者が他人のユーザＩＤなどを利用して勝手な処理を行うことが可能になってしまい，周知例記載の技術を単に引例１に適用しただけでは，セキュリティ上の問題が生ずる。すなわち，セキュリティ上の問題を生ずるようなセッション識別子の用い方をしなければ，本請求項における「キー」と同じ用い方にならないという着想及び技術上の困難性が存在している。
　また，本請求項に係る発明は，コンピュータ・システム，店舗のコンピュータ及び顧客の端末という三者間での一連の処理の流れに関するものであり，当該コンピュータ・システムは店舗のコンピュータ及び顧客の端末の両方と通信をする必要がある。本請求項においては，店舗のコンピュータに基づく顧客認証要求が，処理を行っても良い顧客認証要求であるか不明であり，またたとえ処理を行っても良い顧客認証要求であったとしても，顧客認証要求を受信した時点では顧客認証要求において指示されている顧客の端末と通信可能であるかも不明である。このような状況においては，処理の連続性を保証しつつ処理の途中からの割り込みを防止しなければ，適正な決済処理を行うことができない。そのため，本請求項では，顧客認証要求に係る店舗に対しては第１段階の処理として認証処理又は確認処理を実行し，さらに顧客認証要求に係る顧客の端末との第１段階の処理として，「前記顧客認証要求に係る顧客の端末からの応答であることを確かめるためのキー」を生成して，指定の顧客の端末に送信する構成を採用している。
　これに対し，いずれの引例においても「処理の割り込みを防止する」という観点は開示も示唆もされていない。すなわち，処理の割り込みを防止し，最初から最後までの処理全体の流れを維持するという本請求項の発明の目的は，処理と処理との間の隙をなくすという観点がない従来技術を寄せ集めても達成されるものではない。
　従って，引例１乃至３並びに周知例から本請求項を容易に想到できたとは言えない。」
　
　
５．引用例
　
（１）当審における拒絶の理由で引用した，大竹剛，アコム　毎月２割が利用する電子決済，１万会員突破の「アコシス」，日経マルチメディア，日経ＢＰ社，1998年9月15日，第39号，p.98〜103（以下，「引用例１」という。）には，図面と共に以下の事項が記載されている。
　
（ア）「アコシスは，ユーザーが電子商店で購入した商品の代金を，クレジット・カードを使わずに郵便局や銀行口座から引き落とせるという会員制のサービスである」（第９８頁第５行〜同頁第９行）
　
（イ）「こうしてアコムは消費者金融で培ったユーザーの信用確認などのノウハウを生かして，電子商店と会員間の決済の代行をする独自の電子決済サービスの開発に着手。現在のアコシスが誕生したというわけである。
　今後アコムは，アコシスの仕組みを他社にも積極的にライセンス提供していく。先行したメリットを生かし，クレジット・カード業界で例えれば，「VISA」や「MasterCard」のような立場をインターネット上の電子決済の世界で確立しようと狙っている。」（第９９頁左欄第１６行〜同欄第２８行）
　
（ウ）「「リボ払い」で利用率が大幅に向上
　会員の利用率を高める起爆剤になったのは，買いたい時にお金がなくても月額一定の支払いで買い物ができる「リボルビング払い」（リボ払い）の導入である。…（中略）…こうした工夫と，ＩＤ／パスワードによる決済手続きの簡便さがあいまって，会員の２割が毎月利用し，平均利用額は月額約１万円という状況を達成した」（第１００頁左欄下から３行〜同頁右欄下から３行）
　
（エ）「注文から発送まで最短２分で処理
　アコシスを使ったショッピングの基本的な流れを見てみると，まず会員は加盟店のホームページにアクセスして商品を注文（図２）。すると注文内容がリンク先のアコシスのホームページに自動的に転送され，そこでは会員がＩＤとパスワードを入力する。…（中略）…加盟店には後日，会員の登録口座から引き落とされた代金から手数料を差し引いた金額が振り込まれる，という流れになる。」（第１０１頁中欄第１行〜同欄第１８行）
　
（オ）「加盟店のシステム環境にも配慮
　ただしアコシスのスタンダード・サービスの場合は，アコムのサーバーとデータを自動的にやりとりするために，電子商店側のＷｅｂサーバーにＣＧＩ(Common Gateway Interface)の仕組みが必要になるなどの条件がある。」（第１０１頁右欄下から５行〜第１０２頁第３行）
　
（ａ）上記摘記事項（エ）及び図２から，会員が加盟店のホームページにアクセスして商品を注文するための「会員の端末」を有すること，加盟店がホームページを運営するための「加盟店のコンピュータ」を有すること，上記摘記事項（ア），（エ），（オ）及び図２から，アコムアコシスセンターがサービスを運営するための「アコシスのサーバー」を備えることは自明である。
　
（ｂ）上記摘記事項（エ）及び図２から，加盟店のホームページから自動転送されてきた注文データをアコシスのサーバーが受信すると，アコシスのサーバーが会員に対して認証処理を行うことから，加盟店のコンピュータからの注文データの自動転送は，会員に対する認証処理の依頼の意味を含むことは自明である。
　
（ｃ）上記摘記事項（エ）及び図２から，ＩＤとパスワードは，アコシスのサーバーが本人確認，すなわち認証処理を行うために用いられることは明らかであり，アコシスのサーバーが，認証処理を実行し，認証が成功した後に，注文確定の情報をアコシスのサーバーから加盟店のコンピュータに送信する手段を備えることは明らかである。
　
　そうすると，引用例１の上記摘記事項及び図面から，引用例１には，次の発明（以下，「引用例１発明」という。）が記載されていると認められる。
　
「会員の端末及び加盟店のコンピュータと通信を行うアコシスのサーバーであって，
　前記会員の端末から，前記加盟店のコンピュータにアクセスした会員に対する認証処理を依頼するための注文データを受信すると，前記会員の端末から当該会員のＩＤとパスワードを受信して前記会員に対する認証処理を実施し，前記会員の注文確定情報を情報を前記加盟店のコンピュータに送信する手段
　を有するアコシスのサーバー」
　
（２）当審における拒絶の理由で引用した，アコム／アコシス  バーチャルでクレジット決済を可能にしたアコシス今後２〜３年で採算ベースに，ＣａｒｄＷａｖｅ，株式会社シーメディア，1997年08月10日，第10巻，第9号，p.18〜19（以下，「引用例２」という。）には，図面とともに，次の事項が記載されている。
　
（カ）「利用者は，アコシス加盟店に商品の注文を行う。注文を受けた加盟店では，アコシスセンターに承認を依頼する。」（第１８頁中欄下から６行〜同欄下から４行）
　
（キ）「一方，加盟店のなりすまし防止に関しては，加盟店に共通鍵を渡してアコシスで認証するといった方法を採っている。」（第１８頁右欄最下行〜第１９頁左欄第３行）
　
（３）当審における拒絶の理由で引用した特開平１１−３１６７２９号公報（以下，「引用例３」という。）には，図面とともに，次の事項が記載されている。
　
（ク）「【０００７】
【発明が解決しようとする課題】しかしながら，上記従来のクレジットカードを利用したものや，特定のサービスを対象とした会員制によるサービスの提供を受けるためには，クレジットカードの会員，または，サービス提供会社の会員になる必要があり，利用者が限定されてしまう。また，会員になる時に私的情報をカード会社やサービス提供会社に教えなければならず，匿名でサービスを利用することができない。また，会員になるための手続きが繁雑で，利用しにくく，さらに，クレジットカード番号がネットワーク上を流れるため，第三者によるカード番号の盗聴・悪用という危険性がある。」
　
（ケ）「【００２４】図１は，本発明の動作の概要を説明するためのシーケンスチャートである。まず，プリペイドカード（ＩＣカード，フロッピーディスク，磁気カード等）に設定されたコンテンツサーバのアドレス情報（例えば，ＨＴＴＰにおけるＵＲＬ）に基づいて，端末からコンテンツサーバに対し有料サービス利用要求が発行される（ステップ１０１）。次に，コンテンツサーバはプリペイドカードの認証及び課金処理を行うことをカード管理サーバに要求し（ステップ１０２），カード管理サーバは端末との間でカードの認証を行い（ステップ１０３），認証・課金処理結果をコンテンツサーバに返却する（ステップ１０４）。コンテンツサーバは認証及び課金処理が成功した場合，有料サービスを端末に提供する（ステップ１０５）。
【００２５】図２は，本発明の一実施例のインターネット課金システムの接続構成の概要を示す図である。端末１００は，インターネット４００を介してコンテンツサーバ２００との間でコネクション１１を設定し，当該コネクション１１を利用して有料サービスの利用を要求する。コンテンツサーバ２００は，端末１００からの有料サービス利用要求を受けると，カード管理サーバ３００との間にコネクション１２を設定し，当該コネクション１２を利用して，端末１００のＩＰアドレスを送信することにより，プリペイドカードの認証要求及び課金処理要求を行う。
【００２６】カード管理サーバ３００は，コンテンツサーバ２００からの認証要求を受けると，端末１００との間にコネクション１３を設定し，端末１００に対してプリペイドカードのパスワードの演算を要求する。端末１００は，コネクション１３を利用して，カード管理サーバ３００にパスワードの演算結果を送信する。カード管理サーバ３００は，各カードのカードＩＤ，パスワード，サービス利用ポイント残度数を記録したカード管理データベース５００を保持している。カード管理データベース５００のデータ構成例を図３に示す。カード管理サーバ３００は，カードＩＤからパスワードを検索し，端末１００と同一の演算を行ない，送られてきた演算結果と一致すれば，認証成立とする。」
　
　
６．対比
　
　引用例１発明の「会員の端末」，「加盟店のコンピュータ」，「アコシスのサーバー」，「前記会員の端末から当該会員のＩＤとパスワードを受信すると前記会員に対する認証処理を実施し」は，それぞれ，本願発明の「顧客の端末」，「店舗のコンピュータ」，「コンピュータ・システム」，「前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し」に相当する。
　
　引用例１発明の「前記会員の端末から，前記加盟店のコンピュータにアクセスした会員に対する認証処理を依頼するための注文データを受信すると」と，本願発明の「前記顧客の端末から，前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求と共に当該顧客認証要求に係る顧客の端末の情報及び当該店舗の識別情報を受信した場合に」は，「前記顧客の端末から，前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求と共に当該顧客認証要求に係る店舗のコンピュータから送信される情報を受信した場合に」で共通する。
　
　引用例１発明の「前記会員の注文確定情報を情報を前記加盟店のコンピュータに送信する手段」と，本願発明の「前記キーの正当性確認処理結果及び前記顧客に対する認証処理結果が肯定的である場合に，前記店舗のコンピュータに顧客認証要求に係る前記顧客に対する認証処理結果が肯定的であったことを示す情報を送信する顧客認証手段」は，「前記顧客に関連する情報を前記店舗のコンピュータに送信する手段」で共通する。
　
　そうすると，本願発明と引用例１発明とは，
　
「顧客の端末及び店舗のコンピュータと通信を行うコンピュータ・システムであって，
前記顧客の端末から，前記店舗のコンピュータにアクセスした顧客に対する認証処理を依頼するための顧客認証要求と共に当該顧客認証要求に係る店舗のコンピュータから送信される情報を受信した場合に，前記顧客の端末から当該顧客の認証用情報を受信すると前記顧客に対する認証処理を実施し，前記顧客に対する認証処理結果が肯定的である場合に，前記顧客に対する認証処理結果が肯定的であったことを示す情報を前記店舗のコンピュータに送信する手段
　を有するコンピュータ・システム。」
　
で一致し，次の点で相違する。
　
［相違点１］
　本願発明では，「店舗のコンピュータから送信される情報」が，「顧客の情報」及び「店舗の識別情報」であり，「顧客に関連する情報」が「顧客に対する認証結果が肯定的であったことを示す情報」であるのに対し，引用例１発明では，「店舗から送信される情報」が「注文データ」であって，「顧客の情報」及び「店舗の識別情報」を含むことは記載されておらず，「顧客に関連する情報」が「注文確定情報」である点。
　
［相違点２］
　本願発明では，コンピュータ・システムが「受信した前記店舗の識別情報を用いて，前記店舗の識別情報が正しいかを確認する処理である当該店舗に対する認証処理又は前記店舗の識別情報が予め登録されたものであるかを確認する処理である当該店舗の確認処理を実施する手段」，「前記店舗に対する認証処理又は前記店舗の確認処理の結果が肯定的である場合に，前記顧客認証要求に係る顧客の端末からの応答であることを確かめるためのキーを生成して当該キーを前記顧客の端末に送信する認証確認手段」を有し，「前記顧客の端末からキーを受信すると当該キーの正当性確認処理を実施し」，「前記正当性確認処理が，前記顧客の端末から受信したキーが，前記認証確認手段によって生成されたキーと同一であることを確認する処理」であるのに対し，引用例１発明は，そのような構成にはなっていない点。
　
　
７．当審の判断
　
［相違点１］及び［相違点２］について。
　引用例２の上記摘記事項（キ）には，アコシスが加盟店のなりすまし防止のために加盟店に共通鍵を渡して，その共通鍵を用いてアコシスで認証することが記載されており，加盟店になりすました注文への対策であるから，引用例１発明に引用例２の当該技術思想を適用して，アコシスのサーバーが共通鍵を用いて加盟店の認証を行うことは当業者が容易になし得た事項にすぎない。
　このとき，加盟店のなりすまし防止のための認証は，加盟店によるアコシスのサーバーへの会員に対する認証処理の依頼時に行うことが効率的であることは当業者が容易に推考できる事項にすぎない。
　さらに，引用例３の上記摘記事項（ク）には，コンテンツサーバが，端末からの有料サービス利用要求を受けると，カード管理サーバと端末との間で認証のためのコネクションの設定を行うために，コンテンツサーバが端末のＩＰアドレスをカード管理サーバに送信することが記載されており，引用例１発明に引用例３の当該技術思想を適用して，端末のＩＰアドレスを注文データに含ませることは，当業者が容易になし得た事項にすぎない。
　そうすると，引用例１発明において，「店舗から送信される情報」を，「顧客の情報」及び「店舗の識別情報」とすること，コンピュータ・システムが，店舗の識別情報を用いて店舗の確認処理を実施する手段を有する構成とすることは，当業者が容易になし得た事項にすぎない。
　また，インターネットを利用したコンピュータ間の通信において，認証済み等のコンテクストを維持するためにセッション識別子を生成し，セッション識別子を送受信することで相手方の正当性を確認することは，特開平２０００−１０６５５２号公報，山崎重一郎，モバイルエージェントによる電子発注と電子決済の統合モデルの提案，情報処理学会研究報告（９７−ＤＰＳ−８５），社団法人情報処理学会，1997年11月07日，第97巻，第104号，p.127〜132（第１３０頁の「４．１同一ｗｅｂサーバーでのコンテクストの維持」等の記載参照）にあるように周知技術にすぎないことから，引用例１発明において，コンピュータ・システムが，店舗に対する認証処理又は店舗の確認処理の結果が肯定的である場合に，顧客認証要求に係る顧客の端末からの応答であることを確かめるためのキーを生成して当該キーを顧客の端末に送信する認証確認手段を有し，顧客の端末からキーを受信すると当該キーの正当性確認処理を実施し，正当性確認処理が，顧客の端末から受信したキーが，認証確認手段によって生成されたキーと同一であることを確認する処理とすることは，当業者が容易になし得た事項にすぎない。
　さらに，引用例１発明の「注文確定情報」は会員の認証後にアコシスのサーバーから加盟店のコンピュータに送られるものであるから，注文確定情報には，会員の認証の成功の意味が含まれていることは，当業者が容易に推考できることであり，引用例３の上記摘記事項（ケ）には，ユーザに対する認証の結果をカード管理サーバからコンテンツサーバに送信することが記載されていることから，引用例１発明において，「顧客に関する情報」を「顧客に対する認証結果が肯定的であったことを示す情報」とすることは，当業者が容易になしえた事項にすぎない。
　
　ここで，請求人の上記主張について検討をする。
　
　本願発明の「キー」（発明の詳細な説明の「ＫＥＹ０１」）について，発明の詳細な説明段落【００２８】〜【００２９】，【００３９】〜【００４０】，【００４７】，【００４９】〜【００５１】，【００５６】には，次の事項が記載されている。
　
「　　【００２８】
　図１に示したシステムにおける処理について簡単に説明しておく。顧客は顧客端末３を操作して店舗サーバ５にネットワーク１を介してアクセスし，購入する商品等を検索する。購入したい商品等が見つかると，顧客は顧客端末３から店舗サーバ５に商品等の注文を送信する。この時顧客は，決済には本実施例に係る決済システムを利用することを指示するものとする。店舗サーバ５は，顧客端末３から受信した注文情報を注文情報ＤＢ５１に登録し，当該注文情報，店舗サーバ５の情報（例えば店舗認証用情報又は店舗識別情報若しくは店舗サーバ５のアドレス等）及び顧客端末３のアドレス等を追加して決済サーバ７に転送する。決済サーバ７は，店舗サーバ５の情報を用いて店舗の確認／認証を行い，注文情報を仮登録する。決済サーバ７は，店舗サーバ５の情報及び注文情報に問題がなければ，動作キーＫＥＹ０１を生成して，顧客端末３に顧客（会員）のＩＤ及びパスワードを入力するように促す画面情報及び隠しパラメータとして動作キーＫＥＹ０１を送信する。
　　　【００２９】
　顧客端末３はＩＤ及びパスワードを入力するように促す画面を顧客に対し表示する。そして，顧客は顧客（会員）のＩＤ及びパスワードを入力し，顧客端末３はＩＤ及びパスワード並びに隠しパラメータの動作キーＫＥＹ０１を決済サーバ７に送信する。決済サーバ７においては，動作キーＫＥＹ０１が正当な動作キーであるか，ＩＤ及びパスワードの対が正しいか，受信した顧客（会員）ＩＤの顧客がＩＳＰにおける正常な会員であるか，本実施例に係る決済システムを使用する資格があるかを検査する。全ての検査が正常に終了すれば，決済サーバ７は，動作キーＫＥＹ０２を生成する。そして，決済サーバ７は，全ての検査が正常に終了していれば，隠しパラメータとして動作キーＫＥＹ０２と，検査結果と，注文情報に含まれる又は注文情報とは別途決済サーバ７に送られてきた，店舗サーバ５における当該注文の識別情報（以下，管理番号と呼ぶ。但し，番号だけでなく記号の場合もある。）とを店舗サーバ５に送信する。もし，いずれかの検査でエラーが生じた場合には，動作キーＫＥＹ０２は生成されず，店舗サーバ５には，いずれかの検査でエラーが生じたことが通知される。ＩＤ及びパスワードの対が正しくない場合には，顧客端末３にも通知される。例えば，ＩＤ及びパスワードの対の入力は２回まで再試行が許される。ここまでで顧客認証処理及びシステム利用資格確認処理が終了する。」
　
「　　【００３９】
　店舗サーバ５は，決済依頼を受信すると，当該決済依頼を決済サーバ７に転送する（ステップＳ１３）。また，転送する際には，顧客端末３のアドレス情報を，決済依頼と共に決済サーバ７に転送する。なお，店舗識別情報とは別に又は店舗識別情報の代わりに店舗の認証用情報（例えば店舗のＩＤ及びパスワード）を併せて転送する場合もある。決済依頼を受信した決済サーバ７は，少なくとも店舗識別情報が実在するコードであるか等の店舗の確認を行う。もし店舗の認証用情報を受信した場合には，店舗のＩＤ及びパスワードの対が正しいか否かを検査する。これらにより店舗の確認が取れると，一旦受信した決済依頼に含まれる注文情報，店舗サーバ５のアドレス情報，店舗識別情報，及び管理番号等を，注文仮受付ファイル等に仮登録しておく。そして，決済サーバ７は動作キーＫＥＹ０１を生成し，顧客端末３に，当該動作キーＫＥＹ０１を隠しパラメータとして，これから決済サーバ７との通信において顧客認証を行うことを顧客に確認させるための認証確認画面情報を送信する（ステップＳ１５）。動作キーＫＥＹ０１を用いるのは，この処理ステップを必ず通過していることを後に確認できるようにするためである。
　　　【００４０】
　顧客端末３は認証確認画面をＷｅｂブラウザ内に表示し，顧客は認証確認画面に含まれる「ＯＫ」ボタンを押す。そうすると，顧客端末３から認証確認が隠しパラメータである動作キーＫＥＹ０１と共に決済サーバ７に送信される（ステップＳ１７）。決済サーバ７は，受信した動作キーＫＥＹ０１の正当性を確認する。正当性が確認された場合には，決済サーバ７は，顧客のＩＤ及びパスワードの入力を促す画面情報を顧客端末３に送信する（ステップＳ１９）。なお，動作キーＫＥＹ０１の正当性が確認されなかった場合には，このまま処理を続けると問題が生じえるので，例えば店舗サーバ５及び顧客端末３にエラーが生じたことを通知する。」
　
「　　【００４７】
　なお，動作キーＫＥＹ０１及びＫＥＹ０２については，有効期限を設けて有効期限内に決済サーバ７に戻ってこないようであれば，動作キーの確認処理でエラーとみなすようにすることも可能である。」
　
「　　【００４９】
　店舗サーバ５は，決済依頼を受信すると，当該決済依頼を決済サーバ７に転送する（ステップＳ４３）。また，転送する際には，顧客端末３のアドレス情報を，決済依頼と共に決済サーバ７に転送する。なお，店舗識別情報とは別に又は店舗識別情報の代わりに店舗の認証用情報（例えば店舗のＩＤ及びパスワード）を併せて転送する場合もある。決済依頼を受信した決済サーバ７は，少なくとも店舗識別情報が実在するコードであるか等の店舗の確認を行う。もし店舗の認証用情報を受信した場合には，店舗のＩＤ及びパスワードの対が正しいか否かを検査する。これらにより店舗の確認が取れると，一旦受信した決済依頼に含まれる注文情報，店舗サーバ５のアドレス情報，店舗識別情報，及び管理番号等を，注文仮受付ファイル等に仮登録しておく。そして，決済サーバ７は，動作キーＫＥＹ０１を生成し，顧客端末３に，当該動作キーＫＥＹ０１を隠しパラメータとして，顧客のＩＤ及びパスワードの入力を促す画面情報を顧客端末３に送信する（ステップＳ４５）。動作キーＫＥＹ０１を用いるのは，この処理ステップを必ず通過していることを後に確認できるようにするためである。
　　　【００５０】
　顧客端末３は，Ｗｅｂブラウザ内に顧客ＩＤ及びパスワードの入力を促す画面を表示する。少なくともこれ以下の通信においては，例えばＳＳＬ（Secure Socket Layer）技術を用いて通信の秘密を守る必要がある。これ以前の通信においてもＳＳＬを用いてもよい。顧客は，要求に応じて，顧客ＩＤ及びパスワードをＷｅｂブラウザ内に入力し，Ｗｅｂブラウザ内の画面に設けられた送信ボタンを押す。そうすると顧客端末３は入力された顧客ＩＤ及びパスワードを決済サーバ７に送信する（ステップＳ４７）。このような形にて顧客ＩＤ及びパスワードを決済サーバ７に出力すれば，店舗サーバ５には顧客ＩＤとパスワードの対は送信されず，悪意ある又は悪意を持つようになった店舗に顧客ＩＤ及びパスワードを悪用されるのを防止することができる。又，顧客端末３は動作キーＫＥＹ０１を決済サーバ７に送信する。
　　　【００５１】
　決済サーバ７は，受信した動作キーＫＥＹ０１の正当性を確認する。もし，正当性が確認されなかった場合には，このまま処理を続けると問題を生じ得るので，例えば店舗サーバ５及び顧客端末３にエラーを生じたことを通知する。さらに，決済サーバ７は，受信した顧客ＩＤ及びパスワードの対が予め登録されている顧客情報と同一か否か判断する。もし，同一でなければ，再度入力を行うようにステップＳ４７に戻る。例えば３回，顧客ＩＤ及びパスワードの確認を行っても同一であると判断できなかった場合には，決済サーバ７は顧客端末３に認証エラー画面情報を送信する。また，決済サーバ７は，店舗サーバ５に認証エラーを通知する場合もある。」
　
「　　【００５６】
　なお，動作キーＫＥＹ０１及びＫＥＹ０２については，有効期限を設けて有効期限内に決済サーバ７に戻ってこないようであれば，動作キーの確認処理でエラーとみなすようにすることも可能である。」
　
　発明の詳細な説明の上記記載から把握できる事項は，ＫＥＹ０１は店舗サーバ５の情報及び注文情報に問題がなければ生成されること，ＫＥＹ０１を隠しパラメータとして認証処理に用いることであり，この点においては，上記周知技術以上の事項を把握することはできない。
　また，上記周知技術におけるセッションの識別子はコンテクスト（状態）を把握するために用いられるものであり，セッションの識別子をみるとセッションの識別子が生成されたときのコンテクスト（状態）を確認することができることも，セッション識別子を用いたセッション管理の分野における技術常識である。
　さらに，引用例１発明も三者間の一連の処理の流れに関するものであり，上記で検討したように，加盟店のなりすまし防止のために加盟店の認証を行うことは当業者が容易になし得た事項にすぎず，加盟店の認証処理が正常に行えたときに，顧客の認証処理に移行するものであることは明らかである。
　そうすると，どの段階でセッション識別子と同様の機能を果たすキーを生成するか，そして，誰と誰の間でキーの授受を行うかは，当業者が適宜決定し得た事項にすぎない。
　よって，審判請求人が意見書で主張する，「キー」は，認証実施者（コンピュータ・システム）によって認証対象者（店舗のコンピュータ）の認証が行われた後に，認証実施者から，認証対象者とは異なる第三者（顧客の端末）に送信されるものであるとする点，本願発明は，コンピュータ・システム，店舗のコンピュータ及び顧客の端末という三者間での一連の処理の流れに関するものであり，当該コンピュータ・システムは店舗のコンピュータ及び顧客の端末の両方と通信をする必要があるので，「前記顧客認証要求に係る顧客の端末からの応答であることを確かめるためのキー」を生成するとする点は，当業者であれば格別の困難性なくなし得たことと認められるから，本願発明が引用例１に記載された発明，引用例２〜３に記載された事項及び周知技術に基づき容易に発明できたものではないとする旨の審判請求人の上記主張は採用できない。
　
　したがって，相違点１及び相違点２に係る本願発明の構成は，引用例１発明，引用例２〜３に記載された事項及び周知技術に基づいて，当業者が容易に想到し得たものである。
　
　以上より，本願発明の構成は，引用例１発明，引用例２〜３に記載された事項及び周知技術に基づき，当業者が容易に想到し得たものである。
　そして，本願発明の作用効果も，引用例１〜３及び周知技術から当業者が予測できる範囲のものである。
　ゆえに，本願発明は，引用例１発明，引用例２〜３に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
　
８．むすび
　
　以上のとおり，本願発明は，引用例１発明，引用例２〜３に記載された事項及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。