【事件の表示】
　特願２００３−１５３４０９「異なる端末器間のセッション保持方法」拒絶査定不服審判事件〔平成１６年　６月　３日出願公開、特開２００４−１５７９７３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本件出願は、平成１５年５月２９日（パリ条約に基づく優先権主張２００２年１１月７日、大韓民国）の出願であって、平成１７年１２月１５日付けで拒絶理由通知がなされ、平成１８年３月２０日付けで手続補正がなされたが、同年４月２８日付けで拒絶査定され、これに対し、同年７月３１日に審判請求がなされるとともに同年８月２５日付けで手続補正がなされたものである。そして、同年１０月１３日付けで審査官から前置報告がなされ、平成２０年１１月１２日付けで当審より審尋がなされ、平成２１年２月１６日付けで回答書が提出されたものである。
　
第２．平成１８年８月２５日付け手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１８年８月２５日付けの手続補正を却下する。
　
［理由］
１．本件補正
　平成１８年３月２０日付け手続補正書により補正された請求項７（以下「補正前の請求項７」という。）の
　
「マルチセッション管理部を含む応用サーバに、
　端末器からのウェブサーバを介したサービス要請により、前記端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する第１機能と、
　前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する第２機能と、
　前記第２機能における判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供して異なる端末器間セッションを保持する第３機能と、
　前記第２機能における判断の結果、セッションが存在しないと、セッション鍵とセッションを新規に生成した後、前記セッションを前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする第４機能と、
　前記応用コンポーネントを呼び出し、要請ページを生成する第５機能と、
　前記要請メッセージを送信した端末器に合うように、生成した前記要請ページを変形する第６機能と
　を実現させるためのプログラムを記録したコンピュータで読み出すことのできる記録媒体。」
　
は、平成１８年８月２５日付け手続補正（以下、「本件補正」という。）により、請求項５（以下、「補正後の請求項５」という。）の
　
「マルチセッション管理部を含む応用サーバに、
　端末器からのウェブサーバを介したサービス要請により、前記端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する第１機能と、
　前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する第２機能と、
　前記第２機能における判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供して異なる端末器間セッションを保持する第３機能と、
　前記第２機能における判断の結果、セッションが存在しないと、セッション鍵とセッションを新規に生成した後、前記セッションを前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする第４機能と、
　前記応用コンポーネントを呼び出し、要請ページを生成する第５機能と、
　前記要請メッセージを送信した端末器に合うように、生成した前記要請ページを変形する第６機能と
を実現させ、前記第２機能は、
　前記ヘッダ情報を解析した結果、クッキーが存在すると、クッキーからセッション鍵を抽出する第７機能と、
　前記ヘッダ情報を解析した結果、クッキーが存在しないと、前記マルチセッション管理部からセッション鍵を抽出する第８機能と、
　前記第７機能、または前記第８機能で抽出されたセッション鍵に基づいてセッションを検索して、セッションが存在するか否かを判断する第９機能と
　を実現させ、前記第８機能は、
　前記マルチセッション管理部の仮想クッキーからユーザＩＤに基づいてセッション鍵を抽出して、セッション鍵が存在するか否かを判断する第１０機能と、
　前記第１０機能における判断の結果、セッション鍵が存在すると、前記第９ステップに移行し、セッション鍵が存在しないと、前記マルチセッション管理部のマルチセッションからユーザＩＤに基づいてセッション鍵を抽出する第１１機能と
　を実現させるためのプログラムを記録したコンピュータで読み出すことのできる記録媒体。」
　
へと補正された。
　
２．補正の適否
　上記補正は、請求項の削除、誤記の訂正あるいは明りようでない記載の釈明を目的としたものとはいえない一方、補正前の請求項７に記載した発明を特定するために必要な事項である「第２機能」について限定するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものであると解される。
　そこで，補正後の前記請求項５に記載された発明が特許出願の際独立して特許を受けることができるものであるか（同法１７条の２第５項において準用する同法１２６条５項の規定に適合するか）について検討すると、下記の通り、補正後の明細書又は図面の記載は特許法第３６条第４項第１号、同第６項第１号又は同第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　記
（１）補正後の請求項５の記載において、「端末器からのウェブサーバを介した・・・第６機能とを実現させ」の部分と、「実現させるためのプログラムを記録したコンピュータで読み出すことのできる記録媒体」とが、どのような関係にあるのかが日本語として明確でないために、同請求項５に記載の第１機能乃至第６機能各々は、何が実現させるものであるのかが記載上明確でない。
　加えて、同請求項５は、「第８機能」がどのようなものであるのかが記載上明確でない。（「前記第８機能は」には述語（例えば「実現させる」）に相当するものがないため、該「第８機能」は「第１０機能」や「第１１機能」とどのような関係があるのかを把握できない。なお、「実現させるためのプログラムを記録した」の部分の「実現させる」を「第８機能」の述語として見た場合、今度は「プログラム」及び「記録媒体」がどのようなものかが不明となる。）
　したがって、同請求項５に係る発明を明確に把握することができない。
　
（２）同請求項５に記載の「マルチセッション管理部からセッション鍵を抽出する第８機能」、「マルチセッション管理部の仮想クッキーからユーザＩＤに基づいてセッション鍵を抽出して、セッション鍵が存在するか否かを判断する第１０機能」、「マルチセッション管理部のマルチセッションからユーザＩＤに基づいてセッション鍵を抽出する第１１機能」各々と、同請求項５に記載の「前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果に応じてセッションが存在するか否かを判断する第２機能」における「要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し」との関係が技術的に明確でない。
　すなわち、本件補正により追加された第７機能乃至同第１１機能は、補正前の請求項７に記載の「第２機能」について限定したものであるから、「第１０機能」及び「第１１機能」の「ユーザＩＤに基づいて」セッション鍵を抽出することは、「第２機能」におけるセッション鍵の抽出である「要請メッセージのヘッダ情報の解析結果によって」セッション鍵を抽出することを下位概念化するものであると記載上は把握される。
　しかし、本件の明細書第【００１７】段落の「そうすると、要請管理部112は、インターネットサービス要請メッセージのHTTPヘッダ情報を解析するプロファイル管理部121に伝送し、プロファイル管理部121は、電話番号、端末器がクッキーを支援するか否か、クッキーなどのHTTPヘッダ情報を解析して(201)、電話番号が存在するか否かを判断する(202)。前記判断の結果(202)、電話番号が存在すると移動通信ネットワークに接続した場合であり、前記電話番号に基づいて、ユーザＩＤを検索してユーザを認証し(203)、電話番号が存在しないと有線ネットワークを利用した端末器に接続した場合であり、ユーザのログイン過程を通しユーザＩＤを入力されてユーザを認証する(204)。」との記載によれば、本件における「ヘッダ情報」には、「ユーザＩＤ」は含んでいないと解される上に、端末器が有線ネットワークを利用して接続している場合には、「ユーザＩＤ」はユーザのログイン過程を通じて入力される情報であって「ヘッダ情報の解析結果」とは格別関係を有しない情報であると解されることから、セッション鍵の抽出を「ユーザＩＤに基づいて」行うことが、なぜ「要請メッセージのヘッダ情報の解析結果によって」行うことの下位概念化に当たるのかが技術的に明確でない。
（なお、ユーザＩＤに基づいてセッション鍵を検索することが、要請メッセージのヘッダ情報の解析結果によってセッション鍵を検索することの下位概念化に当たるものでないならば、ユーザＩＤに基づいてセッション鍵を検索することを特定した本件補正は、補正前の請求項７に記載した発明を特定するために必要な事項を限定するものとはいえず、同特許法第１７条の２第４項第２号でいう特許請求の範囲の減縮を目的とするものともいえないから、同１７条の２第４項各号のいずれを目的とするものともいえず適法な補正ではない。）
　
（３）同請求項５に記載の
「前記第１０機能における判断の結果、セッション鍵が存在すると、前記第９ステップに移行し」における「前記第９ステップ」とは何を指すのかが記載上明確でない。
（「ステップ」は”機能”の誤記であるとも考えられるが、「前記第９ステップに移行し」を、”前記第９機能に移行し”としてみても日本語として明確でない。）
　
（４）同請求項５には、マルチセッション管理部に情報を格納することに関して、
「第２機能における判断の結果、セッションが存在しないと、セッション鍵とセッションを新規に生成した後、前記セッションを前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする第４機能」と、マルチセッション管理部に格納する情報として「セッション」のみが記載されていることからすれば、同請求項５に係る発明は、マルチセッション管理部に
　・新規に生成した「セッション」を格納する一方、
　・「ユーザＩＤ」と「セッション鍵」のいずれも格納しないもの
を含むと認められる。
　しかし、本件の明細書の第【００２１】段落には「ユーザが初めて接続した要請である場合には、マルチセッション管理部122でのマルチセッションの検索の結果セッション鍵が存在せず、したがって、セッション管理部123にセッションとセッション鍵の生成を要請し、セッション管理部123はセッションを生成した後、以後にユーザの異なる端末器間のセッションを保持させるためにマルチセッション管理部122に前記ユーザＩＤとともにセッション鍵を格納するように(216)要請する。」及び「端末器がクッキーを支援しないと、ユーザＩＤとセッション鍵とをマルチセッション管理部122の仮想クッキーに格納(219)するよう要請する。」と記載され、同第【００２２】段落には「セッション管理部123はセッションを生成した後、以後にユーザの異なる端末器間のセッションを保持させるためにマルチセッション管理部122に前記ユーザＩＤとともにセッション鍵を格納するように(216)要請する。」と記載されている通り、本件の明細書の発明の詳細な説明の記載からは、マルチセッション管理部に「ユーザＩＤ」と「セッション鍵」とを格納させる例は読み取れるが、マルチセッション格納部に「セッション」のみを格納させることの記載はない（なお、本件の明細書の発明の詳細な説明中には、「セッション」を格納すること自体の明示がない）。
　したがって、同請求項５に係る発明は、発明の詳細な説明に記載されたものとはいえない。
　加えて、マルチセッション管理部に「セッション鍵」あるいはユーザＩＤを格納しない場合に、「マルチセッション管理部からセッション鍵を抽出する第８機能」、「マルチセッション管理部の仮想クッキーからユーザＩＤに基づいてセッション鍵を抽出して、セッション鍵が存在するか否かを判断する第１０機能」、あるいは、「マルチセッション管理部のマルチセッションからユーザＩＤに基づいてセッション鍵を抽出する第１１機能」を各々どのように実現すればよいのかが技術的に不明であるから、本件の明細書の発明の詳細な説明は、当業者が本件補正後の請求項５に係る発明の実施をすることができる程度に明確かつ十分に記載されていない。
　
　以上の通りであるから、本件補正後の特許請求の範囲の記載は、請求項５の記載に関し特許法第３６条第６項第１号又は同第２号に規定する要件を満たしておらず、また、本件の明細書の発明の詳細な説明の記載は、当業者が補正後の請求項５に係る発明の実施をすることができる程度に明確かつ十分に記載されていないために特許法第３６条第４項第１号の規定を満たしていないから、補正後の請求項５に係る発明は、特許出願の際独立して特許を受けることができるものではない。
　
３．本件補正についてのむすび
  したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
第３．本願発明について
　平成１８年８月２５日付け手続補正は上記のとおり却下されたので、本件の請求項７に係る発明（以下、「本願発明」という。）は、平成１８年３月２０日付け手続補正により補正された明細書及び図面の記載に基づき、
　
「マルチセッション管理部を含む応用サーバに、
　端末器からのウェブサーバを介したサービス要請により、前記端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する第１機能と、
　前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する第２機能と、
　前記第２機能における判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供して異なる端末器間セッションを保持する第３機能と、
　前記第２機能における判断の結果、セッションが存在しないと、セッション鍵とセッションを新規に生成した後、前記セッション鍵を前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする第４機能と、
　前記応用コンポーネントを呼び出し、要請ページを生成する第５機能と、
　前記要請メッセージを送信した端末器に合うように、生成した前記要請ページを変形する第６機能と
　を実現させるためのプログラムを記録したコンピュータで読み出すことのできる記録媒体。」
　
にあるものと認める。
　なお、平成１８年３月２０日付け手続補正の請求項７には「セッション鍵とセッションを新規に生成した後、前記セッションを前記マルチセッション管理部に格納して」と記載されているが、本件の属する技術分野において、端末器とサーバ間に仮想的な接続が維持されている”状態”を指す用語である「セッション」（用語の使用例：特開２００２−１８９６４６号公報の請求項１の「ログイン要求に対して前記端末と中継装置間に仮想的な接続が維持されている状態をセッションとし」との記載）は、通常は管理部に格納される対象となるものではなく、また、本件の明細書第【００２１】段落、同第【００２２】段落の記載からは、セッションが存在しない場合に生成され、マルチセッション管理部に格納されるものは「セッション」ではなく「セッション鍵」であると認められるから、上記記載における「前記セッションを」は、「前記セッション鍵を」の誤記と認め、本願発明を上記のように認定した。
　
第４．引用発明及び周知技術
　引用文献１．特開２００２−９１８５１号公報
　引用文献２．特開２００１−３５０６７７号公報
　引用文献３．特開平１１−３２８０６４号公報
　引用文献４．特開２００２−１８９６４６号公報
　引用文献５．特開２００１−２２２４８７号公報
　
　引用文献１は、原査定の拒絶理由に引用された文献であり、引用文献２乃至５は、当業者に周知の技術事項を示すため当審において新たに引用した文献である。
　
１．引用発明の認定
　引用文献１には、図面とともに次の事項が記載されている。
　
（ア）「【請求項７】 端末からのＷＷＷサーバへの情報読み出し要求を中継して、前記端末から要求のあった情報を要求元の端末に提供する中継サーバとしてコンピュータを機能させるためのプログラム製品であって、各ユーザ毎の第１のユーザＩＤに前記複数のＷＷＷサーバのそれぞれが前記端末を識別するために各端末に対し発行した第２のユーザＩＤを対応付ける機能と、前記端末から前記ＷＷＷサーバへの情報読み出し要求を前記第１のユーザＩＤにて受け付けたとき、情報提供元のＷＷＷサーバから情報を読み出す際には、前記第１のユーザＩＤに対応付けられた前記情報提供元のＷＷＷサーバ対応の前記第２のユーザＩＤを前記情報提供元のＷＷＷサーバへ通知する機能と、前記第１のユーザＩＤを持つユーザが前記複数のＷＷＷサーバのそれぞれへ読み出し要求を行った履歴は当該履歴を参照して再び前記ＷＷＷサーバへ情報読み出し要求を可能にするよう前記第１のユーザＩＤに対応付ける機能と、前記履歴を前記第１のユーザＩＤを持つユーザからの要求に応じて要求元の端末へ提供する機能と、前記履歴を提供する際、当該履歴を参照して履歴要求元の端末がその属性に適した情報の読み出し要求が可能なように前記履歴を書き換える機能と、をコンピュータに実現させるためのプログラム製品。」
　
（イ）「【０００５】さらに、本来、ＷＷＷサーバは通信相手のユーザを特定することができない。ＷＷＷサーバへのアクセスは、１回毎に切断されるため、ＷＷＷサーバ側では、複数のアクセスを連続したものとして把握することができない。そこで、何もしない状態では、ばらばらになる複数の要求を関連付けるための技術が必要となる。例えば、クッキー（ｃｏｏｋｉｅ）のように、端末側にユーザのＩＤなどを記憶することによって、端末が再接続してきたときに、当該端末からクッキーを戻してもらうことで、ＷＷＷサーバは通信相手のユーザを特定して、当該端末とセッションを継続させることができる。しかし、当該ユーザが端末を変更すると、ＷＷＷサーバ側では、そのクッキーによってはユーザを認識できなくなりセッションが継続できないといった問題があった。」
　
（ウ）「【０００７】一方、ＷＷＷでは、端末とＷＷＷサーバとの間にサーバを置いて、通信の中継を行なわせることがある。中継を行なうサーバにはプロキシ（ｐｒｏｘｙ）サーバとサロゲートサーバとがある。これらについて以下で説明する。
【０００８】プロキシサーバは、端末とＷＷＷサーバとの間でネットワーク上で端末に比較的近い位置に置かれ、通信の仲介を行なう。これによってアクセス制御を行なってセキュリティを向上させたり、データのキャッシングなどを行なってネットワークの負荷を低減することができる。なお、プロキシサーバを用いる場合には、区別のためにもともとのＷＷＷサーバをオリジンサーバと呼ぶ。
【０００９】サロゲートサーバ（Ｉｎｔｅｒｎｅｔ Ｗｅｂ Ｒｅｐｌｉｃａｔｉｏｎ ａｎｄ Ｃａｃｈｉｎｇ Ｔａｘｏｎｏｍｙ， Ｉ Ｃｏｏｐｅｒ， Ｉ Ｍｅｌｖｅ， ａｎｄ Ｇ． Ｔｏｍｌｉｎｓｏｎ， Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ， Ｊｕｎｅ ２３，２０００ ｄｒａｆｔ−ｉｅｔｆ−ｗｒｅｃ−ｔａｘｏｎｏｍｙ−０４．ｔｘｔ）は端末からはＷＷＷサーバに見えるが、実際にはその後ろにオリジンサーバがあり、オリジンサーバの代理として端末からの要求に応じて情報を送出する。複製サーバやｒｅｖｅｒｓｅ ｐｒｏｘｙサーバと呼ばれるサーバがサロゲートサーバの一種である。
【００１０】サロゲートサーバを実現するには、プロキシサーバと同じ機構を用い、端末からの要求があった際に、プロキシサーバからオリジンサーバへデータの要求を中継することもできるが、端末からの要求をまたずにあらかじめオリジンサーバからサロゲートサーバへデータを能動的に送出することもできる。
【００１１】また、プロキシサーバが一般に端末に近い場所に置かれてユーザあるいはユーザが利用するサービスプロパイダ側で管理されるのに対して、サロゲートサーバは通常オリジンサーバを運営するコンテンツプロバイダ側で管理されるという違いもある。
【００１２】以上のようにプロキシサーバとサロゲートサーバとでは技術的・管理的に異なる側面があるが、端末とオリジンサーバであるＷＷＷサーバの中間で中継を行なうという点では共通しているので、以下では中継サーバと総称する。」
　
（エ）「【００１８】
【課題を解決するための手段】本発明の情報提供方法および中継サーバ装置は、端末からのＷＷＷサーバ装置への情報読み出し要求を中継して、前記端末から要求のあった情報を要求元の端末に提供するものであって、各ユーザ毎の第１のユーザＩＤに前記複数のＷＷＷサーバ装置のそれぞれが前記端末を識別するために各端末に対し発行した第２のユーザＩＤを対応付けて記憶し、前記端末から前記ＷＷＷサーバ装置への情報読み出し要求を前記第１のユーザＩＤにて受け付けたとき、情報提供元のＷＷＷサーバ装置から情報を読み出す際には、前記第１のユーザＩＤに対応付けて記憶されている前記情報提供元のＷＷＷサーバ装置対応の前記第２のユーザＩＤを前記情報提供元のＷＷＷサーバ装置へ通知することにより、１人のユーザが異なる複数の端末からＷＷＷサーバへアクセスする場合でもＷＷＷサーバ側は（従来同様）対サーバユーザＩＤにて通信相手のユーザを識別することができる。ＷＷＷサーバでは、対サーバＩＤにより通信相手のユーザを識別できるので、例えば、対サーバユーザＩＤにセッションを対応付けたり、当該対サーバユーザＩＤにて識別されるユーザへの個別サービスを提供したりする。従って、ユーザは、異なる端末からＷＷＷサーバにアクセスしてもセッションを継続できたり、その他の個別のサービスの提供を継続して受けることができる。」
　
（オ）「【００２２】
【発明の実施の形態】以下、本発明の実施形態について、図面を参照して説明する。
【００２３】（第１の実施形態）図１は本実施形態に係るＷＷＷシステムの構成を概略的に示したものである。図１において、ＷＷＷシステムは、オリジンサーバとしての複数の（ここでは、例えば３つの）ＷＷＷサーバ３ａ、３ｂ、３ｃと、例えば１人のユーザがＷＷＷサーバへのアクセスに用いる複数の（ここでは、例えば２つの）端末１ａ、１ｂと、ＷＷＷサーバ３ａ、３ｂ、３ｃに対するプロキシサーバあるいはサロゲートサーバである中継サーバ２とから構成されている。以下、ＷＷＷサーバ３ａ、３ｂ、３ｃをオリジンサーバ３ａ、３ｂ、３ｃと呼ぶ。
【００２４】なお、図１には共通の中継サーバ２を持つ端末が２つ（端末１ａ、１ｂ）示されているが、この端末の数は任意である。また、共通の中継サーバ２を持つオリジンサーバが３つ（オリジンサーバ３ａ、３ｂ、３ｃ）示されているが、このオリジンサーバの数も任意であり、例えば、中継サーバがプロキシサーバの場合は、一般に２つ以上である。
【００２５】図２は、本実施形態に係る中継サーバ２の概略構成を示すブロック図である。
【００２６】図２において、中継サーバ２は、制御部１１、履歴記憶部１２、セッション情報記憶部１３、情報対応関係記憶部１４、複製記憶部１５、通信部１６から構成されている。」
　
（カ）「【００２７】中継サーバ２では、各ユーザに、中継サーバ２自身が各ユーザを識別するための対端末ユーザＩＤを割当てており、この対端末ユーザＩＤと、オリジンサーバ３ａ、３ｂ、３ｃがそのユーザにより使用された各端末に対し発行した対サーバユーザＩＤとを対応付けて管理している。」
　
（キ）「【００３３】次に、図７〜図８に示すフローチャートを参照して、ユーザがその所持する複数の端末のうちの１つを用いて、所望のＵＲＬを指定して、ＷＷＷサーバにアクセスした（情報の読み出し要求を行う）ときの、中継サーバ２の処理動作について説明する。
【００３４】ユーザが、例えば、自宅に設置された端末１ａを用いて所望のＷＷＷサーバにアクセスして、Ｗｅｂページを閲覧した後、外出先にて携帯端末１ｂを用いて再び所望のＷＷＷサーバにアクセスする場合を想定する。
【００３５】ユーザは、携帯端末１ｂをインターネットに接続して、ＵＲＬを指定して情報の読み出し要求を送出する。
【００３６】中継サーバ２の制御部１１は、通信部１６を介して端末１ｂからの指定ＵＲＬの情報読み出し要求を受信する（ステップＳ１）。この情報読み出し要求には、図６に示すように、所望する情報を提供するＷＷＷサーバを指定するＵＲＬ、要求元の端末１ｂの端末属性、端末１ｂに既にクッキー（ユーザＩＤ（対端末ユーザＩＤ）を含む）が記憶されていれば、そのクッキー等が含まれている（端末１ｂにクッキーが記憶されていなければ、クッキーが含まれていないこともある）。端末属性には、端末１ｂの種類（例えば、機種（ＣＰＵの種類等）、ブラウザの種類、バージョン等の端末属性）が記述されている。
【００３７】制御部１１は、要求の中にクッキーの形式でユーザＩＤが含まれていた場合は（ステップＳ２）、それをステップＳ８以下の処理で対端末ユーザＩＤとして利用する。含まれていなかった場合は（ステップＳ２）、当該ユーザに対し、ユーザＩＤの入力を要求する（ステップＳ３）。この要求に応じて、当該ユーザが自宅の端末１ａで用いたのと同じユーザＩＤを端末１ｂから入力して、そのユーザＩＤが当該端末１ｂから当該中継サーバ２に送られてきたときは（ステップＳ４）、制御部１１は、そのユーザＩＤを対端末ユーザＩＤとする。この取得した対端末ユーザＩＤが既にセッション情報記憶部１３に記憶されているときは（ステップＳ９）、ステップＳ７へ進み、記憶されていないときは（ステップＳ９）、ステップＳ６へ進む。ステップＳ４でユーザＩＤの入力がないときは、当該ユーザに対し新たにユーザＩＤ（対端末ユーザＩＤ）を生成し（ステップＳ５）、ステップＳ６へ進む。」
　
（ク）「【００４３】ＵＲＬにて指定された情報が複製記憶部９になかった場合は、制御部１１は、まず、セッション情報記憶部１３に、当該ユーザの対端末ユーザＩＤに対応した、情報読み出し要求に含まれるＵＲＬに記述されたサーバ名、およびそれに対応した対サーバユーザＩＤが記憶されているか否か調べる。サーバ名およびそれに対応した対サーバユーザＩＤが記憶されている場合は、端末１ｂから受信した情報読み出し要求にクッキーとして含まれていた対端末ユーザＩＤを対サーバユーザＩＤに置き換えて、あるいは、端末１ｂから受信した情報読み出し要求にクッキーとして対端末ユーザＩＤが含まれていないときは当該要求に対サーバユーザＩＤをクッキーとして含めて、対応のオリジンサーバへ転送する（図８のステップＳ２１）。セッション情報記憶部１３に記憶されていない場合は、端末１ｂからの（対サーバユーザＩＤをクッキーとして含まない）情報読み出し要求を、対応のオリジンサーバへ転送する（ステップＳ２３）。
【００４４】例えば、上記の例の場合、対端末ユーザＩＤが「ＡＡＡ」で要求中に含まれる指定ＵＲＬが「ＵＲＬｃ」のとき、セッション情報記憶部１３には、この「ＵＲＬｃ」に記述されたサーバ名（「ｃｃ」）、およびそれに対応した対サーバユーザＩＤが記憶されていないので（ステップＳ２１）、端末１ｂからの情報読み出し要求をそのまま対応のオリジンサーバ、すなわち、この場合、オリジンサーバ３ｃへ転送する。」
　
（ケ）「【００４５】情報読み出し要求を受け取った、例えば、サーバ名「ｃｃ」のオリジンサーバ３ｃでは、要求された情報を読み出して、中継サーバ２へ送信する。また、要求中にクッキーとして、当該オリジンサーバ３ｃにて発行されたユーザＩＤ（対サーバユーザＩＤ）が含まれていたときは、以後、従来と同様にして当該クッキーを用いた処理を実行する。要求中にクッキーとして、当該オリジンサーバ３ｃにて発行されたユーザＩＤ（対サーバユーザＩＤ）が含まれていないときも、従来同様、新たにユーザＩＤ（対サーバユーザＩＤ）を発行して（例えば、ここでは、「ｃｃ２」）、それも中継サーバ２へ送信する。また、要求された情報に、他の属性の端末用のＵＲＬが存在する場合は、それも中継サーバ２へ送信する。」
　
（コ）「【００４６】中継サーバ２は、例えば、オリジンサーバ３ｃから送られてきた情報を複製記憶部１５へ格納する（ステップＳ２４）。
【００４７】また、当該情報と共に、当該情報の他の属性の端末用のＵＲＬが存在するときは（ステップＳ２５）、それを情報対応関係記憶部１４に格納する（ステップＳ２６）。例えば、オリジンサーバ３ｃから送られてきた情報には、端末属性が「属性ａ」の端末には「ＵＲＬｃａ」、端末属性が「属性ｂ」の端末には「ＵＲＬｃｂ」という、それぞれ別個のＵＲＬが存在するというリンク情報が付加されていたので、図１１に示すように、「ＵＲＬｃ」に対応付けて、これら端末属性毎のリンク情報を記憶する。
【００４８】さらに、当該読み出された情報とともに、クッキーとしてユーザＩＤが存在するときは、それを対サーバユーザＩＤとして、セッション情報記憶部１３に、当該ユーザの対端末ユーザＩＤに対応させて、対応のサーバ名とともに記憶する（ステップＳ２８）。例えば、対端末ユーザＩＤ「ＡＡＡ」を持つユーザが、「ＵＲＬｃ」を指定して情報読み出し要求を行ったような、上記の例に当てはめて説明すると、図９に示すように、セッション情報記憶部１３の対端末ユーザＩＤ「ＡＡＡ」に対応付けて、サーバ名「ｃｃ」と、そのサーバから発行されたユーザＩＤ「ｃｃ２」を記憶する。」
　
（サ）【図７】
　中継サーバ装置の情報提供処理動作を説明するためのフローチャートとして、ステップＳ１として端末から指定ＵＲＬの情報読み出し要求受信を行った後、ステップＳ２として要求中にユーザＩＤがあるか否かを判断することが図示されている。
　
（ａ）上記（オ）の
「【００２３】（第１の実施形態）図１は本実施形態に係るＷＷＷシステムの構成を概略的に示したものである。図１において、ＷＷＷシステムは、オリジンサーバとしての複数の（ここでは、例えば３つの）ＷＷＷサーバ３ａ、３ｂ、３ｃと、例えば１人のユーザがＷＷＷサーバへのアクセスに用いる複数の（ここでは、例えば２つの）端末１ａ、１ｂと、ＷＷＷサーバ３ａ、３ｂ、３ｃに対するプロキシサーバあるいはサロゲートサーバである中継サーバ２とから構成されている。以下、ＷＷＷサーバ３ａ、３ｂ、３ｃをオリジンサーバ３ａ、３ｂ、３ｃと呼ぶ。
【００２４】なお、図１には共通の中継サーバ２を持つ端末が２つ（端末１ａ、１ｂ）示されているが、この端末の数は任意である。また、共通の中継サーバ２を持つオリジンサーバが３つ（オリジンサーバ３ａ、３ｂ、３ｃ）示されているが、このオリジンサーバの数も任意であり、例えば、中継サーバがプロキシサーバの場合は、一般に２つ以上である。
【００２５】図２は、本実施形態に係る中継サーバ２の概略構成を示すブロック図である。
【００２６】図２において、中継サーバ２は、制御部１１、履歴記憶部１２、セッション情報記憶部１３、情報対応関係記憶部１４、複製記憶部１５、通信部１６から構成されている。」の記載からみて、引用文献１には、セッション情報記憶部を含み、サロゲートサーバである中継サーバと、オリジンサーバとを有するシステムの記載が認められる。
　また、上記（ウ）の
「【００１１】また、プロキシサーバが一般に端末に近い場所に置かれてユーザあるいはユーザが利用するサービスプロパイダ側で管理されるのに対して、サロゲートサーバは通常オリジンサーバを運営するコンテンツプロバイダ側で管理されるという違いもある。」との記載からみれば、引用文献１には、サロゲートサーバである中継サーバがオリジンサーバを運営するコンテンツプロバイダ側で管理されること、すなわち、中継サーバとオリジンサーバとは同一のコンテンツプロバイダによって管理されるシステムの記載が読み取れる。
　したがって、引用文献１には、
　セッション情報記憶部を含む中継サーバとオリジンサーバとを有し、同一のコンテンツプロバイダによって管理されるシステム
が記載されたものと認められる。
　
（ｂ）上記（キ）の
「【００３６】中継サーバ２の制御部１１は、通信部１６を介して端末１ｂからの指定ＵＲＬの情報読み出し要求を受信する（ステップＳ１）。この情報読み出し要求には、図６に示すように、所望する情報を提供するＷＷＷサーバを指定するＵＲＬ、要求元の端末１ｂの端末属性、端末１ｂに既にクッキー（ユーザＩＤ（対端末ユーザＩＤ）を含む）が記憶されていれば、そのクッキー等が含まれている（端末１ｂにクッキーが記憶されていなければ、クッキーが含まれていないこともある）。端末属性には、端末１ｂの種類（例えば、機種（ＣＰＵの種類等）、ブラウザの種類、バージョン等の端末属性）が記述されている。
【００３７】制御部１１は、要求の中にクッキーの形式でユーザＩＤが含まれていた場合は（ステップＳ２）、それをステップＳ８以下の処理で対端末ユーザＩＤとして利用する。」との記載、及び、上記（サ）の【図７】の記載を併せると、引用文献１に記載の中継サーバは、端末から受け取った情報読み出し要求中にクッキーの形式でユーザＩＤが含まれるか否かを判断し、含まれていたユーザＩＤを、対端末ユーザＩＤとして利用するものであることが読み取れる。
　また、上記（カ）の
「【００２７】中継サーバ２では、各ユーザに、中継サーバ２自身が各ユーザを識別するための対端末ユーザＩＤを割当てており」との記載から、引用文献１に記載の対端末ユーザＩＤは、中継サーバ自身が各ユーザを識別するために割当てているものであることが読み取れる。
　したがって、引用文献１に記載の中継サーバは、
　端末から受け取った情報読み出し要求中にクッキーの形式でユーザＩＤが含まれるか否かを判断し、含まれていたユーザＩＤを、中継サーバ自身が各ユーザを識別するために割当てている対端末ユーザＩＤとして利用する機能
　を有するものと認められる。
　
（ｃ）上記（ク）の
「【００４３】ＵＲＬにて指定された情報が複製記憶部９になかった場合は、制御部１１は、まず、セッション情報記憶部１３に、当該ユーザの対端末ユーザＩＤに対応した、情報読み出し要求に含まれるＵＲＬに記述されたサーバ名、およびそれに対応した対サーバユーザＩＤが記憶されているか否か調べる。サーバ名およびそれに対応した対サーバユーザＩＤが記憶されている場合は、端末１ｂから受信した情報読み出し要求にクッキーとして含まれていた対端末ユーザＩＤを対サーバユーザＩＤに置き換えて、あるいは、端末１ｂから受信した情報読み出し要求にクッキーとして対端末ユーザＩＤが含まれていないときは当該要求に対サーバユーザＩＤをクッキーとして含めて、対応のオリジンサーバへ転送する（図８のステップＳ２１）。」との記載からみて、引用文献１に記載の中継サーバは、
　前記機能により得られた該対端末ユーザＩＤによってセッション情報記憶部から対応する対サーバユーザＩＤを抽出する機能と、
　抽出された対サーバユーザＩＤをオリジンサーバに通知する機能
を有するものと認められる。
　
（ｄ）上記（ケ）の
「【００４５】情報読み出し要求を受け取った、例えば、サーバ名「ｃｃ」のオリジンサーバ３ｃでは、要求された情報を読み出して、中継サーバ２へ送信する。また、要求中にクッキーとして、当該オリジンサーバ３ｃにて発行されたユーザＩＤ（対サーバユーザＩＤ）が含まれていたときは、以後、従来と同様にして当該クッキーを用いた処理を実行する。要求中にクッキーとして、当該オリジンサーバ３ｃにて発行されたユーザＩＤ（対サーバユーザＩＤ）が含まれていないときも、従来同様、新たにユーザＩＤ（対サーバユーザＩＤ）を発行して（例えば、ここでは、「ｃｃ２」）、それも中継サーバ２へ送信する。」との記載からみて、引用文献１に記載のオリジンサーバは、
　中継サーバから通知された対サーバユーザＩＤであるクッキーを用いた処理を実行する機能を有すること、及び、
　対サーバユーザＩＤが通知されなかったときは、対サーバユーザＩＤを発行して、中継サーバに送信する機能とを有すること
が読み取れる。
　また、上記（イ）の
「【０００５】さらに、本来、ＷＷＷサーバは通信相手のユーザを特定することができない。ＷＷＷサーバへのアクセスは、１回毎に切断されるため、ＷＷＷサーバ側では、複数のアクセスを連続したものとして把握することができない。そこで、何もしない状態では、ばらばらになる複数の要求を関連付けるための技術が必要となる。例えば、クッキー（ｃｏｏｋｉｅ）のように、端末側にユーザのＩＤなどを記憶することによって、端末が再接続してきたときに、当該端末からクッキーを戻してもらうことで、ＷＷＷサーバは通信相手のユーザを特定して、当該端末とセッションを継続させることができる。」との記載、及び、上記（エ）の
「【００１８】
【課題を解決するための手段】本発明の情報提供方法および中継サーバ装置は、・・・（中略）・・・ことにより、１人のユーザが異なる複数の端末からＷＷＷサーバへアクセスする場合でもＷＷＷサーバ側は（従来同様）対サーバユーザＩＤにて通信相手のユーザを識別することができる。ＷＷＷサーバでは、対サーバＩＤにより通信相手のユーザを識別できるので、例えば、対サーバユーザＩＤにセッションを対応付けたり、当該対サーバユーザＩＤにて識別されるユーザへの個別サービスを提供したりする。従って、ユーザは、異なる端末からＷＷＷサーバにアクセスしてもセッションを継続できたり、その他の個別のサービスの提供を継続して受けることができる。」
との記載を併せると、引用文献１に記載のクッキーを用いた処理とは、対サーバユーザＩＤに応じてユーザを識別し、対サーバユーザＩＤにセッションを対応付けることにより、ユーザが異なる端末からオリジンサーバにアクセスしてもセッションを継続できる処理であると把握される。
　よって、引用文献１には
　オリジンサーバが、
　中継サーバから通知された対サーバユーザＩＤに応じてユーザを識別し、対サーバユーザＩＤにセッションを対応付けることにより、ユーザが異なる端末からオリジンサーバにアクセスしてもセッションを継続できる処理を実行する機能と、
　対サーバユーザＩＤが通知されなかったときは、対サーバユーザＩＤを発行して、中継サーバに送信する機能と
を有することが記載されたものと認められる。
　
（ｅ）上記（コ）の
「【００４６】中継サーバ２は、例えば、オリジンサーバ３ｃから送られてきた情報を複製記憶部１５へ格納する（ステップＳ２４）。
【００４７】また、当該情報と共に、当該情報の他の属性の端末用のＵＲＬが存在するときは（ステップＳ２５）、それを情報対応関係記憶部１４に格納する（ステップＳ２６）。例えば、オリジンサーバ３ｃから送られてきた情報には、端末属性が「属性ａ」の端末には「ＵＲＬｃａ」、端末属性が「属性ｂ」の端末には「ＵＲＬｃｂ」という、それぞれ別個のＵＲＬが存在するというリンク情報が付加されていたので、図１１に示すように、「ＵＲＬｃ」に対応付けて、これら端末属性毎のリンク情報を記憶する。
【００４８】さらに、当該読み出された情報とともに、クッキーとしてユーザＩＤが存在するときは、それを対サーバユーザＩＤとして、セッション情報記憶部１３に、当該ユーザの対端末ユーザＩＤに対応させて、対応のサーバ名とともに記憶する（ステップＳ２８）。例えば、対端末ユーザＩＤ「ＡＡＡ」を持つユーザが、「ＵＲＬｃ」を指定して情報読み出し要求を行ったような、上記の例に当てはめて説明すると、図９に示すように、セッション情報記憶部１３の対端末ユーザＩＤ「ＡＡＡ」に対応付けて、サーバ名「ｃｃ」と、そのサーバから発行されたユーザＩＤ「ｃｃ２」を記憶する。」との記載において、「当該読み出された情報とともに、クッキーとしてユーザＩＤが存在する」とは、オリジンサーバから送られてきた情報である「当該読み出された情報」に、オリジンサーバが発行したサーバＩＤである「対サーバユーザＩＤ」が存在するとき、を意味することからみて、引用文献１には、中継サーバが
　オリジンサーバが発行した対サーバユーザＩＤをセッション情報記憶部に格納する機能を有することが記載されたものと認められる。
　
（ｆ）上記（ア）の
「【請求項７】 端末からのＷＷＷサーバへの情報読み出し要求を中継して、前記端末から要求のあった情報を要求元の端末に提供する中継サーバとしてコンピュータを機能させるためのプログラム製品であって、各ユーザ毎の第１のユーザＩＤに前記複数のＷＷＷサーバのそれぞれが前記端末を識別するために各端末に対し発行した第２のユーザＩＤを対応付ける機能と、前記端末から前記ＷＷＷサーバへの情報読み出し要求を前記第１のユーザＩＤにて受け付けたとき、情報提供元のＷＷＷサーバから情報を読み出す際には、前記第１のユーザＩＤに対応付けられた前記情報提供元のＷＷＷサーバ対応の前記第２のユーザＩＤを前記情報提供元のＷＷＷサーバへ通知する機能と、前記第１のユーザＩＤを持つユーザが前記複数のＷＷＷサーバのそれぞれへ読み出し要求を行った履歴は当該履歴を参照して再び前記ＷＷＷサーバへ情報読み出し要求を可能にするよう前記第１のユーザＩＤに対応付ける機能と、前記履歴を前記第１のユーザＩＤを持つユーザからの要求に応じて要求元の端末へ提供する機能と、前記履歴を提供する際、当該履歴を参照して履歴要求元の端末がその属性に適した情報の読み出し要求が可能なように前記履歴を書き換える機能と、をコンピュータに実現させるためのプログラム製品。」との記載からみて、引用文献１に記載の中継サーバは、各機能がプログラムによって実現されるものであると認められる。
　
　したがって、引用文献１には、以下の発明（以下、「引用発明」という。）が記載されている。
　
　セッション情報記憶部を含む中継サーバとオリジンサーバとを有し、同一のコンテンツプロバイダによって管理されるシステムであって、
　中継サーバは、
　端末から受け取った情報読み出し要求中にクッキーの形式でユーザＩＤが含まれるか否かを判断し、含まれていたユーザＩＤを、中継サーバ自身が各ユーザを識別するために割当てている対端末ユーザＩＤとして利用する機能と、
　前記機能により得られた該対端末ユーザＩＤによってセッション情報記憶部から対応する対サーバユーザＩＤを抽出する機能と、
　抽出された対サーバユーザＩＤをオリジンサーバに通知する機能とを有し、
　オリジンサーバは、
　中継サーバから通知された対サーバユーザＩＤに応じてユーザを識別し、対サーバユーザＩＤにセッションを対応付けることにより、ユーザが異なる端末からオリジンサーバにアクセスしてもセッションを継続できる処理を実行する機能と、
　対サーバユーザＩＤが通知されなかったときは、対サーバユーザＩＤを発行して、中継サーバに送信する機能とを有し、
　中継サーバは、さらに
　オリジンサーバが発行した対サーバユーザＩＤをセッション情報記憶部に格納する機能と
　を有し、
　中継サーバは、各機能がプログラムによって実現されるものである
システム
　
第５．対比
　本願発明と引用発明とを対比する。
　
（１）引用発明の「セッション情報記憶部」、「端末」、「情報読み出し要求」、「対サーバユーザＩＤ」は、それぞれ本願発明の「マルチセッション管理部」、「端末器」、「要請メッセージ」、「セッション鍵」に相当する。
　また、引用発明の「中継サーバとオリジンサーバとを有し、同一のコンテンツプロバイダによって管理されるシステム」と、本願発明の「応用サーバ」とは、”マルチセッション管理部を含むサーバシステム”という上位概念では一致する。
　そして、サーバの各機能は通常プログラムによって実現されるものであることから、引用発明のオリジンサーバも、中継サーバと同様に各機能がプログラムによって実現されるものと把握されることからすれば、引用発明が、中継サーバとオリジンサーバとを有する「システム」であることと、本願発明が、機能をサーバに実現させるための「プログラムを記録したコンピュータで読み出すことのできる記録媒体」であることとは、単なる発明のカテゴリー表現上の差異であって実質的な相違ではない。
　
（２）本願発明の「要請メッセージのヘッダ情報を解析し」とは、明細書の記載を参酌すると、明細書の第【００１７】段落の「プロファイル管理部１２１は、電話番号、端末器がクッキーを支援するか否か、クッキーなどのＨＴＴＰヘッダ情報を解析して（２０１）」との記載からみて、クッキーを解析することを意味するものと解される。してみれば、引用発明の「情報読み出し要求中にクッキーの形式でユーザＩＤが含まれているかを判断し」と実質的に同等のものである。
　また、引用発明の「含まれていたユーザＩＤを、中継サーバ自身が各ユーザを識別するために割当てている対端末ユーザＩＤとして利用する」ことは、中継サーバが、ユーザを識別して以降の処理を行うことを意味するから、当該「含まれていたユーザＩＤを、中継サーバ自身が各ユーザを識別するために割当てている対端末ユーザＩＤとして利用する」ことは、実質的にはユーザの認証を行うことであって本願発明の「ユーザを認証する」ことと同等のものである。
　よって、引用発明の「端末から受け取った情報読み出し要求中にクッキーの形式でユーザＩＤが含まれていた場合に、当該ユーザＩＤを、中継サーバ自身が各ユーザを識別するために割当てている対端末ユーザＩＤとして利用する機能」と、本願発明の「端末器からのウェブサーバを介したサービス要請により、前記端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する第１機能」とは、
”端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する機能”である点では一致する。
　
（３）本願発明の「要請メッセージのヘッダ情報の解析結果によって」とは、明細書の記載を参酌すると、明細書の第【００１８】段落の「プロファイル管理部１２１は、端末器がクッキーを支援するか否か、セッション鍵及びユーザＩＤをＨＴＴＰヘッダ解析結果として要請管理部１１２に返す。」との記載からみて、ユーザＩＤを含む情報によるものであると解される。してみれば、引用発明の「対端末ユーザＩＤとして利用する」ことと実質的に同等のものである。
　よって、引用発明の「前記機能により得られた該対端末ユーザＩＤによってセッション情報記憶部から対応する対サーバユーザＩＤを抽出する機能」は、本願発明の「前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し」と実質的に同等のものである。
　また、引用発明の「抽出された対サーバユーザＩＤをオリジンサーバに通知する」こと、及び「中継サーバから通知された対サーバユーザＩＤに応じてユーザを識別し、対サーバユーザＩＤにセッションを対応付けることにより、ユーザが異なる端末からオリジンサーバにアクセスしてもセッションを継続できる処理を実行する」ことと、本願発明の「セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する」こと、及び、「判断の結果、セッションが存在すると、応用コンポーネント呼び出しの際に情報として提供して、異なる端末器間のセッションを保持する」こととは、”セッション鍵の抽出結果により、異なる端末器間のセッションを継続させる処理を実行する”、という上位概念では一致する。
　したがって、引用発明の「前記機能により得られた該対端末ユーザＩＤによってセッション情報記憶部から対応する対サーバユーザＩＤを抽出する機能」、「抽出された対サーバユーザＩＤをオリジンサーバに通知する機能」及び「中継サーバから通知された対サーバユーザＩＤに応じてユーザを識別し、対サーバユーザＩＤにセッションを対応付けることにより、ユーザが異なる端末からオリジンサーバにアクセスしてもセッションを継続できる処理を実行する機能」と、本願発明の「前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する第２機能」及び「第２機能における判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供して異なる端末器間セッションを保持する第３機能」とは、
”前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果により、異なる端末器間のセッションを継続させる処理を実行する機能”である点では一致する。
　
（４）引用発明の「対サーバユーザＩＤが通知されなかったとき」とは、セッション情報記憶部に対端末ユーザＩＤに対応する対サーバユーザＩＤが記憶されておらず、端末とオリジンサーバとの間に”セッション”すなわち”端末とオリジンサーバとの間に仮想的な接続が維持されている状態”が存在しない場合を意味するから、引用発明の「対サーバユーザＩＤが通知されなかったときは」と、本願発明の「第２機能における判断の結果、セッションが存在しないと」とは、”セッションが存在しない場合には”という上位概念では一致する。
　また、引用発明の「対サーバユーザＩＤを発行して、中継サーバに送信する」に関し、「対サーバユーザＩＤを発行」することは、対サーバユーザＩＤと共にセッションを新たに生成することを意味する。
　そして、引用発明は「オリジンサーバが生成した対サーバユーザＩＤをセッション情報記憶部に記憶する」ことによって、以後に対端末ユーザＩＤにより識別されるユーザが異なる端末でアクセスした場合でも、端末とオリジンサーバとの間のセッションが維持される効果が生じるものである
　したがって、引用発明の「対サーバユーザＩＤが通知されなかったときは、対サーバユーザＩＤを生成して、中継サーバに送信する機能」及び「オリジンサーバが生成した対サーバユーザＩＤをセッション情報記憶部に記憶する機能」と、本願発明の「前記第２機能における判断の結果、セッションが存在しないと、セッション鍵とセッションを新規に生成した後、前記セッションを前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする第４機能」とは、
”セッションが存在しない場合には、セッション鍵とセッションを新規に生成した後、前記セッション鍵を前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする機能”である点では一致する。
　
　したがって，本願発明と引用発明の一致点及び相違点は，次のとおりである。
　
＜一致点＞
　マルチセッション管理部を含むサーバシステムに、
　端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する機能と、
　前記要請メッセージのヘッダ情報の解析結果によってセッション鍵を抽出し、前記セッション鍵の抽出結果により、異なる端末器間のセッションを継続させる処理を実行する機能と、
　セッションが存在しない場合には、セッション鍵とセッションを新規に生成した後、前記セッション鍵を前記マルチセッション管理部に格納して、以後に前記認証したユーザの異なる端末器間のセッションが保持されるようにする機能と、
　を実現させるためのプログラムを記録したコンピュータで読み出すことのできる記録媒体。
　
＜相違点＞
（相違点１）
　マルチセッション管理部を含むサーバシステムに関し、本願発明は、サーバシステムのすべての機能が応用サーバという単独のサーバに実現されているのに対し、引用発明は、サーバシステムの機能が中継サーバとオリジンサーバとに分かれて実現されている点。
　
（相違点２）
　端末器から受け取った要請メッセージのヘッダ情報を解析してユーザを認証する機能に関し、本願発明は、応用サーバが端末器から要請メッセージを、ウェブサーバを介したサービス要請によって受け取るのに対し、引用発明は、中継サーバが端末から情報読み出し要求を直接に受け取るものであって、ウェブサーバを介したサービス要請として受け取るものではない点。
　
（相違点３）
　セッション鍵の抽出結果により実行される、異なる端末器間のセッションを継続させる処理に関して、本願発明は、セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断する処理を行い、当該判断の結果、セッションが存在すると応用コンポーネントの呼び出し時に情報として提供することにより異なる端末器間のセッションを継続させるものであり、また、セッションが存在しない場合であることが、セッション鍵の抽出結果に応じてセッションを検索して判断されるものであるのに対して、引用発明は、異なる端末器間のセッションを継続させる処理が具体的にどのようなものであるのかが明らかではなく、また、セッションが存在しない場合であることが、対サーバユーザＩＤに応じてセッションを検索することで判断されているとはいえない点。
　
（相違点４）
　本願発明は、応用コンポーネントを呼び出し、要請ページを生成する第５機能を有するのに対し、引用発明はその点明らかではない点。
　
（相違点５）
　本願発明は、要請メッセージを送信した端末器に合うように、生成した要請ページを変形するものであるのに対し、引用発明はその点明らかではない点。
　
第６．判断
　上記相違点について判断する。
　
（相違点１）について；
　情報処理技術において、複数のサーバを一つの装置上に実現することは、当業者に周知の技術事項（例、引用文献２の第【００８７】段落に記載の、ＷＷＷサーバとメタ情報管理ゲートウェイとを同一の情報処理装置上に構築する例、引用文献３の第【０００６】段落の、ゲートウェイサーバとアプリケーションサーバが同一ハードウェア上に存在してもよいとの記載）であるから、引用発明に当該周知の技術事項を適用することにより、同一のコンテンツプロバイダによって管理されるサーバである中継サーバとオリジンサーバとを、同一の装置上に実現することで、すべての機能が単独のサーバ装置上で実現されるものとすることは当業者が容易に想到し得た事項である。
　よって、相違点１は格別のものでない。
　
（相違点２）について；
　情報処理技術の分野において、端末とサーバ装置との間にウェブサーバを介在させることで、サーバ装置が端末からの要請メッセージを、ウェブサーバを介したサービス要求によって受け取る構成とすることは周知の技術事項であるから、引用発明において、端末と中継サーバとの間にウェブサーバを介在させることで、中継サーバが端末からの情報読み出し要求を、ウェブサーバを介したサービスによって受け取る構成とすることは当業者が容易に想到し得た事項である。
　よって、相違点２は格別のものではない。
　
（相違点３）について；
　セッションを保持するセッション管理の技術分野において、セッション鍵の抽出結果に応じてセッションを検索してセッションが存在するか否かを判断し、判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供することは、引用文献４の第【００６３】段落及び同第【００６４】段落に、ＨＴＴＰヘッダ内のＣｏｏｋｉｅ属性によって指定されるセッションＩＤ（本願発明の「セッション鍵」に相当）がセッション情報格納手段に格納されているかどうかを調べ、データが有効（本願発明の「セッションが存在する」に相当）ならば該セッションＩＤに対応するＤＢアクセス手段を取得してＤＢ（本願発明の「応用コンポーネント」に相当）へのアクセスに利用することが記載されるように周知である。
　一方、セッションが存在しない場合であることがセッション鍵の抽出結果に応じてセッションを検索して判断されることも、引用文献４の第【００１５】段落、第【０１１３】段落及び同第【０１１７】段落に、データ取得要求内のセッションＩＤに該当のデータがセッション情報格納手段内にないことが判断された場合に、セッション鍵とセッションを新規に生成する処理であるログインを行わせることが記載されているように周知である。
　したがって、引用発明においてこれら周知の技術事項を適用し、異なる端末器間のセッションを継続させる処理を、対サーバユーザＩＤに応じてセッションを検索してセッションが存在するか否かを判断し、判断の結果、セッションが存在すると、応用コンポーネントの呼び出し時に情報として提供する処理として実現すると共に、セッションが存在しない場合であることが対サーバユーザＩＤに応じてセッションを検索して判断されるよう構成することは当業者が容易に想到し得たものである。
　よって、相違点３は格別のものではない。
　
（相違点４）について；
　端末から要求のあった情報を要求元の端末に提供する技術において、応用コンポーネントを呼び出して要請ページを生成することは、引用文献４の第【００２１】段落に、ＤＢ（本願発明の「応用コンポーネント」に相当）へアクセスを行いデータを取得し、次にこのデータから第２データ取得要求に対する応答ページ（本願発明の「要請ページ」に相当）の生成を行い、端末に出力することが記載されているように周知であり、引用発明に当該周知の技術事項を適用し、応用コンポーネントを呼び出して要請ページを生成する機能を実現することは、当業者が容易に想到し得たものである。
　よって、相違点４は格別のものではない。
　
（相違点５）について；
　端末から要求のあった情報を要求元の端末に提供する技術において、当該端末に合うように要請ページを変形させることは周知の技術事項（例、引用文献５の第１頁要約の、ＷｅｂプロキシがＷＷＷコンテンツ３１（「要請ページ」に相当）をリクエスト（「要請メッセージ」に相当）のヘッダ情報に付加された端末装置の画像の制約情報に基づいてデータ変換することの記載）であるから、引用発明に該周知の技術事項を用いることで、情報読み出し要求を送信した端末器に合うように、要請ページを変形する機能を実現することは、当業者が容易に想到し得たものである。
　よって、相違点５は格別のものではない。
　
　そして、本願発明の奏する効果も、上記引用発明及び周知技術から当業者が容易に予測し得た程度のものである。
　
第７．むすび
　以上のとおり，本願発明は，本願の特許出願前に日本国内又は外国において，頒布された刊行物に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。  
 　よって，上記結論のとおり，審決する。