【事件の表示】
　特願２００４−５１４６３４「ウェブサーバへ情報を供給する方法」拒絶査定不服審判事件〔平成１５年１２月３１日国際公開、ＷＯ２００４／００２１０５、平成１７年１０月１３日国内公表、特表２００５−５３１０５４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　出願の経緯
　本願は、２００３年５月１４日（パリ条約による優先権主張　２００２年６月２２日）を国際出願日とする出願であって、平成２０年１０月３１日付けで拒絶理由が通知され、これに対し、平成２１年２月９日付けで手続補正がなされたが、平成２１年６月５日付けで拒絶理由が通知され、平成２１年９月１８日付けで意見書が提出されたが、平成２１年１０月１３日付けで拒絶査定がなされ、平成２２年２月１６日に拒絶査定不服の審判が請求され、同時に手続補正がなされたものである。
　
第２　平成２２年２月１６日付けの手続補正に付いての補正却下の決定
［補正却下の決定の結論］
　平成２２年２月１６日付けの手続補正を却下する。
［理由］
１．本件補正前及び本件補正後の本願発明
　本件補正は、特許請求の範囲についてするもので、請求項１については、
（１）本件補正前に「クライアントに」とあったところを「クライアント端末に」と語句を統一し、
（２）本件補正前の「第２のウェブサーバに格納される」に続く読点を削除し、
（３）本件補正前の「収容」を「格納」と言い換え、
（４）本件補正前に「前記プロキシサーバが、前記第２のウェブサーバを特定するクッキーを」とあったところを、「前記プロキシサーバが、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを」と限定し、
（５）本件補正前に「前記第１のウェブサーバ宛のメッセージに挿入するステップ」とあったところを「前記受信した第１のウェブサーバ宛のメッセージに挿入するステップ」と記載を明りょうにし、
（６）本件補正前に「前記受信したメッセージを前記第１のウェブサーバに転送するステップ」とあったところを「前記プロキシサーバが、前記クッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送するステップ」と記載を明りょうにし、
（７）本件補正前に「前記第１のウェブサーバは、前記メッセージに挿入された前記クッキーを」とあったところを「前記第１のウェブサーバは、前記転送されたメッセージに挿入された前記クッキーを」と記載を明りょうにし、
（８）本件補正前に「前記第２のウェブサーバへ前記情報を要求するために用いる」とあったところを「前記第２のウェブサーバへ前記クライアント端末に関する情報を要求するために用いる」と記載を明りょうにするものである。
　
　従って、本件補正は、少なくとも（４）の補正を含む点で、特許法第１７条の２第４項第２号（特許請求の範囲の減縮）に掲げる事項を目的とするものである。
　
　そこで、本件補正後における特許請求の範囲に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に記載する要件を満たすか）否かを、請求項１に係る発明（以下、「本願補正発明」という。）について以下に検討する。
　
　本願補正発明は次のとおりのものである。
「【請求項１】
　第１のウェブサーバがプロキシサーバを介してクライアント端末に接続される構成において、第２のウェブサーバに格納される前記クライアント端末に関する情報へのアクセスを、前記第１のウェブサーバに提供するための方法であって、
　前記第２のウェブサーバが、前記クライアント端末に関する情報を格納する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを含むメッセージを、前記プロキシサーバに送信するステップと、
　前記プロキシサーバが、前記クッキーを格納するステップであって、前記クッキーは前記クライアント端末に関連づけられており、
　前記プロキシサーバが、前記クライアント端末から、前記第１のウェブサーバ宛のメッセージを受信するステップと、
　前記プロキシサーバが、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを、前記受信した第１のウェブサーバ宛のメッセージに挿入するステップと、
　前記プロキシサーバが、前記クッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送するステップ、とを有し、
　前記第１のウェブサーバは、前記転送されたメッセージに挿入された前記クッキーを、前記第２のウェブサーバへ前記クライアント端末に関する情報を要求するために用いることを特徴とする方法。」
　
２．引用例
　原査定の拒絶の理由である、平成２１年６月５日付け拒絶理由通知の拒絶の理由で引用された、本願の優先日前に頒布された刊行物である、Ｔｉｖｏｌｉ  ＳｅｃｕｒｅＷａｙ  Ｐｏｌｉｃｙ  Ｄｉｒｅｃｔｏｒ  ＷｅｂＳＥＡＬ、管理ガイド、 バージョン３．８、日本アイ・ビー・エム株式会社、２００１年１１月、第１刷、ｐ．１２９〜１５４」（以下、「引用例」という。）には、図面とともに、次の技術事項が記載されている。
　
（イ）「ＣＤＳＳＯ認証の構成
Ｐｏｌｉｃｙ Ｄｉｒｅｃｔｏｒクロスドメイン・シングル・サインオン（ＣＤＳＳＯ）には、複数のセキュア・ドメイン間でユーザー・クリデンシャルを転送するためのメカニズムがあります。  ＣＤＳＳＯにより、Ｗｅｂユーザーは、シングル・サインオンを実行できるため、２つの個別セキュア・ドメイン間をシームレスに移動することができます。  ＣＤＳＳＯ認証メカニズムは、マスター認証サーバー（ｅ−Ｃｏｍｍｕｎｉｔｙ ＳＳＯを参照）に依存しません。
　
ＣＤＳＳＯは、複数のセキュア・ドメインを統合できるようにして、スケーラブルなネットワーク体系という目標を支援します。たとえば、２つ以上の固有ドメイン（それぞれ独自のユーザーおよびオブジェクト・スペースを持つ）により、大企業のエクストラネットを設定することができます。ＣＤＳＳＯにより、シングル・サインオンを持つドメイン間でのユーザーの移動が可能になります。
　
ユーザーが、他のドメインにあるリソースへの要求を出すと、ＣＤＳＳＯ メカニズムは、  １番目のドメインから２番目のドメインに、暗号化されたユーザーＩＤトークンを転送します。  ２番目のドメインは、ユーザーの識別（１番目のドメインで認証を受けたので）を持つことになり、ユーザーは、さらなるログインを実行するように強制されることはありません。」（第１２９頁第１１行〜第１３０頁第９行）
　
（ロ）「以下の図は、 ドメインＡ （ｄＡ．ｃｏｍ）とドメインＢ （ｄＢ．ｃｏｍ）という２つの参加ドメインを持つサンプルｅ−ｃｏｍｍｕｎｉｔｙを示しています。この例で、 ドメインＡはホームまたはオーナー・ドメインです。 ドメインＢは参加または「リモート」 ドメインです。
　
ホーム・ドメインはユーザーを「所有」する、つまり、ユーザーの認証情報をコントロールします。ユーザーがどこでリソースの要求を行うかに関係なく、ホーム・ドメインは常にユーザーが認証を行う必要のある場所です。
　
認証は、マスター認証サーバー（ＭＡＳ）（ホーム・ドメインにあって、すべてのユーザーを認証するように構成されているサーバー（または一連のレプリカ・サーバ−））に対して行われます。この図ではＭＡＳ がｍａｓ．ｄＡ．ｃｏｍとして表示されています。  ＭＡＳの任務は、認証サービスの提供だけに制限する必要があります。  ＭＡＳに、ユーザーに対して使用可能なリソースが含まれていてはなりません。
　
ユーザーがＭＡＳに対して正常に認証されると、ＭＡＳはトークンとして「保証」を生成します。このトークンは、ユーザーが要求を行っているサーバーに戻されます。サーバーはこの「保証」  トークンを、ユーザーがＭＡＳに対して正常に認証され、ｅ−ｃｏｍｍｕｎｉｔｙに参加できることの証明として扱います。」（第１３７頁第４行〜第１３８頁第９行）
　
（ハ）「続くこのセクションのｅ−ｃｏｍｍｕｎｉｔｙプロセス・フローをお読みになる際は、以下の図を参照してください。このプロセス・フローでは、実行可能な２つの「初回」アクセス・シナリオ（１および２）について説明しています。その次に、２または３のすぐ後に実行できる２つの「次回」アクセス・シナリオ（３および４）について説明します。」（第１４０頁第３０行〜第１４１頁第２行）
　
（ニ）「（２）「初回」ｅ−Ｃｏｍｍｕｎｉｔｙアクセス： ＷｅｂＳＥＡＬ ３（ドメインＢ）
■  ユーザーはＷｅｂＳＥＡＬ ３ （リモート・ドメインＢ）によって保護されたリソースを要求します。ブラウザーには、このドメイン用のｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅは含まれません。 ＷｅｂＳＥＡＬ ３には、このユーザーについてのキャッシュされたクリデンシャルはありません。
■  ＷｅｂＳＥＡＬ ３構成では、ｅ−ｃｏｍｍｕｎｉｔｙ認証が使用可能になり、ＭＡＳの場所が指定されています。  ＷｅｂＳＥＡＬ ３は、ブラウザーをＭＡＳ上の特別な「保証」ＵＲＬに転送します。
■  ＭＡＳは「保証」要求を受け取り、そのユーザー用のクリデンシャルの検索に失敗すると、ユーザーにログインを促すプロンプトを出します。
■  ログインが正常に行われると、  ＭＡＳはユーザー用のクリデンシャルを作成し、これをキャッシュに保管して、ブラウザーを、暗号化された「保証」  トークンと共にＷｅｂＳＥＡＬ ３上の元の要求ＵＲＬに転送して戻します。さらに、ブラウザーには、このドメイン（この例ではＭＡＳ）用の「保証」サーバーを識別するドメインＡ固有のｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅがあります。
ログインの試みが失敗する場合、ＭＡＳは障害状態を示す「保証」トークンを戻します。このトークンは、正常状態の「保証」  トークンと区別できないように構成されています。要求側サーバーは、障害状態に対して、ユーザーがローカル認証に失敗した場合と同様に反応します。
■  ＷｅｂＳＥＡＬ ３はトークンを暗号化解除し、ユーザーについてのその独自のクリデンシャルを作成します。
■  ＷｅｂＳＥＡＬ ３はブラウザー上に２番目のｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）を作成して設定し、  ＷｅｂＳＥＡＬ ３をドメインＢの「保証」サーバーとして識別します。
■  認証サービスが要求を許可または拒否します。」（第１４３頁第６行〜第１４４頁第４行）
　
（ホ）「（４）「次回」ｅ−Ｃｏｍｍｕｎｉｔｙアクセス： ＷｅｂＳＥＡＬ ４（ドメインＢ） 
■  ユーザーはＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求します。シナリオ２が先に実行された場合、ブラウザーには、ＷｅｂＳＥＡＬ ３を「保証」サーバーとして識別するドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅが含まれています。 ＷｅｂＳＥＡＬ ４には、このユーザーについてのキャッシュされたクリデンシャルはありません。
■  ＷｅｂＳＥＡＬ ４構成では、ｅ−ｃｏｍｍｕｎｉｔｙ認証が使用可能になり、ＭＡＳの場所が指定されています。 ドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅの存在により、ＭＡＳの場所に関するＷｅｂＳＥＡＬ ４の構成はオーバーライドされます。  ｃｏｏｋｉｅはＷｅｂＳＥＡＬ ４に「保証」サーバーの識別を提供します。（シナリオ１が先に実行された場合、ブラウザーには、ドメインＢサーバーには送信されないドメインＡ ｃｏｏｋｉｅしか保持されていません。構成されているＭＡＳの場所が代わりに使用されます。そして、ＷｅｂＳＥＡＬ ４がドメインＢの「保証」サーバーになります。）
■  シナリオ２が先に実行された場合は、ＷｅｂＳＥＡＬ ４は、ドメインＢ ｃｏｏｋｉｅによって識別されたドメインＢ「保証」サーバー（この場合はＷｅｂＳＥＡＬ ３）上の特別な「保証」ＵＲＬにブラウザーを転送します。
■  ＷｅｂＳＥＡＬ ３は「保証」要求を受け取り、キャッシュ（これはシナリオ２で発生）の中からそのユーザー用のクリデンシャルを検索します。
■  ＷｅｂＳＥＡＬ ３はブラウザーを、暗号化された「保証」 トークンと共にＷｅｂＳＥＡＬ ４上の元の要求ＵＲＬに転送して戻します。
■   ＷｅｂＳＥＡＬ ４はトークンを暗号化解除し、ユーザーについてのその独自のクリデンシャルを作成します。
■  認証サービスが要求を許可または拒否します。」（第１４４頁第３１行〜第１４５頁第２７行）
　
（ヘ）「ｅ−Ｃｏｍｍｕｎｉｔｙ Ｃｏｏｋｉｅの説明
■  ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅは、１つのＷｅｂＳＥＡＬサーバーによって設定され、ユーザーのブラウザーのメモリーに保管され、後の要求で（同じドメイン内の）他のＷｅｂＳＥＡＬサーバーに伝送されるドメイン固有ｃｏｏｋｉｅです。
■   ドメイン固有ｃｏｏｋｉｅには、「保証」サーバーの名前、ｅ−ｃｏｍｍｕｎｉｔｙ識別、「保証」サーバーの場所（ＵＲＬ）と機能、および存続時間の値が含まれます。 ｃｏｏｋｉｅに、ユーザー情報は含まれません。
■  ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅにより、参加ドメイン内のサーバーは「保証」情報をローカルに要求することができます。  ＭＡＳのドメイン用のｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅには、それほど重要な役割はありません。
■  ｃｏｏｋｉｅには、ｗｅｂｓｅａｌｄ．ｃｏｎｆ構成ファイルで設定されている存続時間（タイムアウト）値が含まれています。存続時間値は、リモート・サーバーがどれくらい長くユーザー用の「保証」情報を提供できるかを指定します。ｃｏｏｋｉｅ存続時間が満了すると、そのユーザーは認証のためにＭＡＳに転送されなけれぱなりません。
■  ｃｏｏｋｉｅは、ブラウザーがクローズされるとメモリーから消去されます。ユーザーが特定のドメインからログアウトとすると、ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅはオーバーライドされて空になります。このアクションにより、これは効果的にブラウザーから除去されます。」（第１４６頁第７〜２９行）
　
　また、第１４１頁図２１．「ｅ−Ｃｏｍｍｕｎｉｔｙ　プロセス・フロー」には、ドメインＡの「ｍａｓ．ｄＡ．ｃｏｍ」サーバーが「ＷｅｂＳＥＡＬ　ＭＡＳ」として記載され、ドメインＢの「ｗｓ３．ｄＢ．ｃｏｍ」サーバーが「ＷｅｂＳＥＡＬ　３」として記載され、ドメインＢの「ｗｓ４．ｄＢ．ｃｏｍ」サーバーが「ＷｅｂＳＥＡＬ　４」として記載されている。
　
　上記引用例記載事項及び図面の記載を総合勘案すると、引用例において、シナリオ２が先に実行され、その後、シナリオ４が実行される場合には、引用例には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
 「リモート・ドメインＢのＷｅｂＳＥＡＬ ３は、ユーザーについてのその独自のクリデンシャルを作成し、ＷｅｂＳＥＡＬ ３はブラウザー上にｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）を作成して設定し、ＷｅｂＳＥＡＬ ３をドメインＢの「保証」サーバーとして識別し、ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求すると、ブラウザーには、ＷｅｂＳＥＡＬ ３を「保証」サーバーとして識別するドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅが含まれており、ｃｏｏｋｉｅはＷｅｂＳＥＡＬ ４に「保証」サーバーの識別を提供し、ＷｅｂＳＥＡＬ ４は、ドメインＢ ｃｏｏｋｉｅによって識別されたドメインＢ「保証」サーバー（この場合はＷｅｂＳＥＡＬ ３）上の特別な「保証」ＵＲＬにブラウザーを転送し、ＷｅｂＳＥＡＬ ３は「保証」要求を受け取り、キャッシュの中からそのユーザー用のクリデンシャルを検索し、ＷｅｂＳＥＡＬ ３はブラウザーを、暗号化された「保証」トークンと共にＷｅｂＳＥＡＬ ４上の元の要求ＵＲＬに転送して戻し、ＷｅｂＳＥＡＬ ４はトークンを暗号化解除し、ユーザーについてのその独自のクリデンシャルを作成し、
　ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅは、１つのＷｅｂＳＥＡＬサーバーによって設定され、ユーザーのブラウザーのメモリーに保管され、後の要求で（同じドメイン内の）他のＷｅｂＳＥＡＬサーバーに伝送されるドメイン固有ｃｏｏｋｉｅであり、ドメイン固有ｃｏｏｋｉｅには、「保証」サーバーの名前、ｅ−ｃｏｍｍｕｎｉｔｙ識別、「保証」サーバーの場所（ＵＲＬ）と機能、および存続時間の値が含まれている、ユーザーの認証情報をＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）に提供する方法。」
　
３．対比
　引用発明の「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」及び「リモート・ドメインＢのＷｅｂＳＥＡＬ ３ 」がそれぞれ本願補正発明の「第１のウェブサーバ」及び「第２のウェブサーバ」に相当する。
　次に、引用発明には「ユーザーのブラウザー」と記載されているから、引用発明の「ユーザー」とは、「ブラウザー」の動作している端末を意味していることは明らかである（なお、審判請求書「３．（１）特許請求の範囲に対する補正と根拠の説明」第３文に記載されているとおり、請求人は本件補正における「クライアント」から「クライアント端末」への言い換えを、「語句の統一」であると説明している。）。よって、引用発明の「ユーザー」が、本願補正発明の「クライアント端末」に相当する。
　次に、引用発明において、「クリデンシャル」に基づいた「ユーザーについて」の「「保証」 トークン」が、本願補正発明の「クライアント端末に関する情報」に相当する。
　次に、引用発明において、「ＷｅｂＳＥＡＬ ３は「保証」要求を受け取り、キャッシュの中からそのユーザー用のクリデンシャルを検索し、ＷｅｂＳＥＡＬ ３はブラウザーを、暗号化された「保証」トークンと共にＷｅｂＳＥＡＬ ４上の元の要求ＵＲＬに転送して戻し、ＷｅｂＳＥＡＬ ４はトークンを暗号化解除し、ユーザーについてのその独自のクリデンシャルを作成」することが、本願補正発明の「第２のウェブサーバに格納される前記クライアント端末に関する情報へのアクセスを、前記第１のウェブサーバに提供する」ことに相当する。
　次に、引用発明において、「ユーザー」が「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」と接続されていることは明らかであるから、引用発明において、「ユーザー」が「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」と接続されていることと、本願補正発明の「第１のウェブサーバがプロキシサーバを介してクライアント端末に接続される」こととは、第１のウェブサーバがクライアント端末に接続される点で共通する。
　次に、引用発明において、「ドメイン固有ｃｏｏｋｉｅ」には、「「保証」サーバーの場所（ＵＲＬ）」が含まれているから、引用発明において、「ＷｅｂＳＥＬ ３を「保証」サーバーとして識別するドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ」が、本願補正発明の「前記クライアント端末に関する情報を格納する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキー」に相当する。
　次に、引用発明において、「ＷｅｂＳＥＡＬ ３はブラウザー上にｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）を作成して設定」することと、本願補正発明の「前記第２のウェブサーバが、前記クライアント端末に関する情報を格納する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを含むメッセージを、前記プロキシサーバに送信するステップ」とは、前記第２のウェブサーバが、前記クライアント端末に関する情報を格納する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを含むメッセージを、クライアント端末側のノードに送信するステップである点で共通する。
　次に、引用発明において、「ブラウザー上にｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）を作成して設定」することと、本願補正発明の「前記プロキシサーバが、前記クッキーを格納するステップであって、前記クッキーは前記クライアント端末に関連づけられて」いることとは、クライアント端末側のノードが、前記クッキーを格納するステップの点で共通する。
　次に、引用発明において、「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」ためのブラウザーからのメッセージが本願補正発明の「前記クライアント端末から」の「前記第１のウェブサーバ宛のメッセージ」に相当する。
　次に、引用発明において、「ブラウザー」に含まれる「ＷｅｂＳＥＡＬ ３を「保証」サーバーとして識別するドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ」は、「ユーザーのブラウザーのメモリーに保管され、後の要求で（同じドメイン内の）他のＷｅｂＳＥＡＬサーバーに伝送されるドメイン固有ｃｏｏｋｉｅ」であるから、「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」と該「要求で（同じドメイン内の）」「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」に「伝送される」ことになる。そして、「ｃｏｏｋｉｅ」はブラウザーからの「要求」メッセージに挿入して伝送されるものであるから、引用発明において、「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求し」、ユーザーが、「ブラウザー」に含まれる「ＷｅｂＳＥＡＬ ３を「保証」サーバーとして識別するドメインＢ ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ」を該「要求で（同じドメイン内の）」「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」に「伝送」することと、本願補正発明の「前記プロキシサーバが、前記クライアント端末から、前記第１のウェブサーバ宛のメッセージを受信するステップと、前記プロキシサーバが、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを、前記受信した第１のウェブサーバ宛のメッセージに挿入するステップと、前記プロキシサーバが、前記クッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送するステップ」とは、前記クライアント端末側から、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送するステップ、の点で共通する。
　次に、引用発明において、「ｃｏｏｋｉｅはＷｅｂＳＥＡＬ ４に「保証」サーバーの識別を提供し、ＷｅｂＳＥＡＬ ４は、ドメインＢ ｃｏｏｋｉｅによって識別されたドメインＢ「保証」サーバー（この場合はＷｅｂＳＥＡＬ ３）上の特別な「保証」ＵＲＬにブラウザーを転送し、ＷｅｂＳＥＡＬ ３は「保証」要求を受け取」ることが、本願補正発明の「前記第１のウェブサーバは、前記転送されたメッセージに挿入された前記クッキーを、前記第２のウェブサーバへ前記クライアント端末に関する情報を要求するために用いる」ことに相当する。
　
　すると、本願補正発明と引用発明とは次の点で一致する。
＜一致点＞
　第１のウェブサーバがクライアント端末に接続される構成において、第２のウェブサーバに格納される前記クライアント端末に関する情報へのアクセスを、前記第１のウェブサーバに提供するための方法であって、
　前記第２のウェブサーバが、前記クライアント端末に関する情報を格納する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを含むメッセージを、クライアント端末側のノードに送信するステップと、
　クライアント端末側のノードが、前記クッキーを格納するステップと、
　前記クライアント端末側から、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送するステップ、とを有し、
　前記第１のウェブサーバは、前記転送されたメッセージに挿入された前記クッキーを、前記第２のウェブサーバへ前記クライアント端末に関する情報を要求するために用いることを特徴とする方法。
　
　また、両者は次の点で相違する。
＜相違点＞
 　本願補正発明では、第１のウェブサーバがクライアント端末と「プロキシサーバを介して」接続され、「第２のウェブサーバ」はクッキーを含むメッセージを、「プロキシサーバ」に送信し、前記クッキーは前記クライアント端末に関連づけられており、前記プロキシサーバが、前記クライアント端末から、前記第１のウェブサーバ宛のメッセージを受信し、前記プロキシサーバが、クッキーを、前記受信した第１のウェブサーバ宛のメッセージに挿入し、前記プロキシサーバが、前記クッキーが挿入された第１のウェブサーバ宛のメッセージを前記第１のウェブサーバに転送しているのに対し、引用発明では、「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」（本願補正発明の「第１のウェブサーバ」に相当する。以下同じ。）が「ユーザー」（クライアント端末）と「プロキシサーバを介して」接続されておらず、「リモート・ドメインＢのＷｅｂＳＥＡＬ ３」（第２のウェブサーバ）はブラウザー上に「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）を作成して設定、つまり、「ユーザー」（クライアント端末）に送信しており、「ユーザー」（クライアント端末）が、「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）が挿入された「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」ためのメッセージを、「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」（第１のウェブサーバ）に送信している点。
　
４．判断
　そこで、上記相違点について検討すると、本願の優先日前において、クッキーを持つことができない携帯電話等の端末とサーバーとの間にＣｏｏｋｉｅを保持するサーバー、つまり本願補正発明でいう「プロキシサーバ」を設置し、Ｃｏｏｋｉｅを携帯電話等の端末に関連づけ、サーバーとの通信を、Ｃｏｏｋｉｅを保持するサーバー（プロキシサーバ）を介して行うことは周知技術である（例えば、特開２００２−１７１２９４号公報、特表２００２−５１７８６１号公報参照。また、引用例に記載されているようなシングル・サインオン（ＳＳＯ）製品への適用についても、例えば、伊藤芳之、セキュアトレンド、シングル・サインオン、拡大する他製品との接続性、キメ細かなユーザー管理を実装、月刊ソリューションＩＴ、第１３巻、第６号、株式会社リックテレコム、２００１年６月１日、ｐ．１９〜２１の「携帯電話やマルチドメインに対しＳＳＯを実現　各社のＳＳＯ製品は、これまでＳＳＯの実現が難しかった領域へも対応し始めている。そのひとつが携帯電話だ。ｉモードやＷＡＰなどのＷｅｂブラウザを搭載した携帯電話は、Ｃｏｏｋｉｅを持つことができない。この場合、特にクライアント側のＣｏｏｋｉｅを介してユーザー情報をやり取りするアクセスチケット方式は成り立たない。そこで、携帯電話とＳＳＯサーバーの間に、Ｃｏｏｋｉｅを保持するサーバーを設置。ここが携帯電話とのセッションを維持した上で、ＳＳＯサーバーとユーザー情報をやり取りすることで解決させている。」（第２１頁中欄第４行〜同頁右欄第１１行）参照。）。
　よって、引用発明に上記周知技術を適用し、引用発明において、「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」（第１のウェブサーバ）が携帯電話等の「ユーザー」（クライアント端末）とプロキシサーバを介して接続するようにし、「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）を携帯電話等の「ユーザー」（クライアント端末）に関連づけ、「リモート・ドメインＢのＷｅｂＳＥＡＬ ３」（第２のウェブサーバ）は、該プロキシサーバに「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）を作成して設定、つまり、送信するようにし、前記プロキシサーバが、前記携帯電話等の「ユーザー」（クライアント端末）から「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」ためのメッセージを受信し、前記プロキシサーバが、「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）を「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」ためのメッセージに挿入し、前記プロキシサーバが、前記「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ （ドメインＢに対して有効）」（クッキー）が挿入された「ユーザーがＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）によって保護されたリソースを要求する」ためのメッセージを前記「ＷｅｂＳＥＡＬ ４ （リモート・ドメインＢ）」（第１のウェブサーバ）に転送することは、当業者が容易になし得たことである。
　
　また、本願補正発明の作用効果も、引用発明及び周知技術に基づいて当業者が予測し得るものである。
　
　従って、本願補正発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
５．請求人の主張について
　請求人の主張（審判請求書、平成２３年１０月２４日付け回答書、及び、該回答書中での面接の希望に基づいて平成２３年１１月２９日に実施された面接においてなされた主張）は、要するに、クッキーとは、これを発行した特定のホストに対してのみ送信されるものであるとの技術的理解に立脚するものであるが、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｍｍｅｒｃｅ  Ｓｅｒｖｅｒ  ２０００  リソースキット、マイクロソフト公式解説書、日経ＢＰソフトプレス、２００１年１０月１５日、初版、第４５９頁第１２〜１７行に「複数ドメインでのシングルログイン機能　Ｃｏｍｍｅｒｃｅ Ｓｅｒｖｅｒは、複数ドメインでのシングルログイン機能を提供しています。このシナリオでは、複数のドメイン間で、それらのドメインのプロパティを持つｃｏｏｋｉｅを共有します。これらのドメインでは、サブドメインの名前が共通していなければなりません。たとえば、ｐｒｅｍｉｅｒ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍとｍｓｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍは、ｍｉｃｒｏｓｏｆｔ．ｃｏｍというドメイン名を持つｃｏｏｋｉｅを共有できます。」と記載されているとおり、あるドメインのプロパティを持つＣｏｏｋｉｅは、そのドメイン内の複数のホストに送信されるものである。
　よって、携帯電話等の端末の代わりにｃｏｏｋｉｅを保持するプロキシサーバーは、引用発明における「ドメインＢに対して有効」なプロパティ（ｄＢ．ｃｏｍのプロパティ）を持つ「ｅ−ｃｏｍｍｕｎｉｔｙ ｃｏｏｋｉｅ 」に対しては、「ドメインＢ」内の複数のホスト（ｗｓ３．ｄＢ．ｃｏｍ、及び、ｗｓ４．ｄＢ．ｃｏｍ）に対し該ｃｏｏｋｉｅを送信するよう動作することになる。
　よって、請求人の主張は採用できない。
　
６．本件補正についてのまとめ
　以上のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１．本願発明
　平成２２年２月１６日付けの手続補正は上記のとおり却下されたので、本願の請求項１〜９に係る発明は、平成２１年２月９日付け手続補正書により補正された特許請求の範囲の請求項１〜９に記載されたとおりのものであるところ、請求項１に係る発明（以下「本願発明」という。）は次のとおりのものである。
「【請求項１】
　第１のウェブサーバがプロキシサーバを介してクライアントに接続される構成において、第２のウェブサーバに格納される、前記クライアントに関する情報へのアクセスを、前記第１のウェブサーバに提供するための方法であって、
　前記第２のウェブサーバが、前記クライアント端末に関する情報を収容する前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを含むメッセージを、前記プロキシサーバに送信するステップと、
　前記プロキシサーバが、前記クッキーを格納するステップであって、前記クッキーは前記クライアント端末に関連づけられており、
　前記プロキシサーバが、前記クライアント端末から、前記第１のウェブサーバ宛のメッセージを受信するステップと、
　前記プロキシサーバが、前記第２のウェブサーバを特定するクッキーを、前記第１のウェブサーバ宛のメッセージに挿入するステップと、
　前記受信したメッセージを前記第１のウェブサーバに転送するステップ、とを有し、
　前記第１のウェブサーバは、前記メッセージに挿入された前記クッキーを、前記第２のウェブサーバへ前記情報を要求するために用いることを特徴とする方法。」
　
２．引用例
　原査定の拒絶の理由である、平成２１年６月５日付け拒絶理由通知書の拒絶の理由で引用された引用例及びその記載事項は、前記「第２　［理由］２．」に記載したとおりである。
　
３．対比・判断
　本願発明は、上記「第２　［理由］」で検討した本願補正発明において「前記プロキシサーバが、前記第２のウェブサーバを特定するネットワークアドレスを含んだクッキーを」とあったところを「前記プロキシサーバが、前記第２のウェブサーバを特定するクッキーを」と限定を解除し、その余の補正を元に戻したものに相当する。
　そうすると、本願発明の発明特定事項に更に他の要件を付加し、さらに明りょうでない記載の釈明及び誤記の訂正を行ったものに相当する本願補正発明が前記「第２［理由］４．」に記載したとおり、引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　従って、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　よって、結論のとおり審決する。