【事件の表示】
　特願２００５−５０８２６７「ルーティングヒント」拒絶査定不服審判事件〔平成１７年　３月　３日国際公開、ＷＯ２００５／０２００８５、平成１９年　８月　２日国内公表、特表２００７−５２１６８４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は，２００３年８月１８日（パリ条約による優先権主張外国庁受理　２００３年８月１３日　米国）を国際出願日とする出願であって，平成２１年１１月３０日付けで拒絶査定がなされ，これに対し，平成２２年４月１日に拒絶査定に対する審判請求がなされるとともに手続補正がなされ，平成２３年１２月１６日付けで当審から拒絶理由が通知され，平成２４年３月２１日付けで手続補正がなされたものである。
　その請求項１５に係る発明は，明細書，特許請求の範囲及び図面の記載からみて，平成２４年３月２１日付け手続補正書により補正された特許請求の範囲の請求項１５に記載されたとおりの次のものと認める（以下，「本願発明」という。）。
「【請求項１５】
　ホストデバイスにおいて実行される方法であって，
　前記ホストデバイスが，クライアントからセッションを開始するための要求を受信する動作と，
　前記ホストデバイスが，ホスト識別子を使用してセッション識別子を作成する動作であって，前記ホスト識別子は，所与のホストクラスタに属する複数のホストにわたって前記ホストデバイスに対して一意であり，かつ別のホストクラスタに属する別のホストに関しては一意ではないものであり，前記セッション識別子の第１のフィールドに前記ホスト識別子を追加し，前記セッション識別子の第２のフィールドに，当該セッション識別子の一意性を高める値を追加することによって，前記第１のフィールドと前記第２のフィールドとを含むセッション識別子を作成する動作と，
　前記ホストデバイスが，前記セッション識別子を用いて，該セッション識別子に対応するセッションについてホストセッション開始メッセージを定式化する動作であって，前記セッション識別子の前記第１のフィールドおよび前記第２のフィールド内のコンテンツが前記セッションに対するクライアントセッション継続メッセージにおいて無変更で返されるように，ホストセッション開始メッセージを定式化する動作と，
　前記ホストデバイスが，前記セッション識別子に対応するセッションを確立する動作であって，前記セッションのタイプは，ＳＳＬセッション，ＴＬＳセッション，セキュアインターネットプロトコル（ＩＰＳｅｃ）セッション，ＨＴＴＰクッキーベースセッション，ＰＰＴＰセッション，ＩＰＳｅｃ／Ｌ２ＴＰセッション，独自セッション，ターミナルサーバセッション，および管理者定義セッションを含む，複数のセッションタイプのうちのいずれかである動作と
　を含むことを特徴とする方法。」
　
　
２．引用発明
　当審の拒絶理由に引用された中国特許出願公開第１３２１９３５号明細書（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。
　
（１）
（説明の１頁３〜４行）
（当審仮訳）
「本発明は概してクライアント／サーバ・ネットワーク・アプリケーションに関し，特に大量のクライアント・トラフィックを扱うためサーバのクラスタを用いるＷＷＷサイトに関する。」
　
（２）
（説明の２頁２行２０文字目〜同頁５行）
（当審仮訳）
「しかしながら，どのＷｅｂサーバが与えられたクライアント要求をルーターから受信するかを予測することは不可能なので，サーバは適切な状態データをキャッシュすることができず，新しいＨＴＴＰリクエストの度に毎回セッションホルダーからそれを検索しなければならない。」
　
（３）
（説明の２頁１３行〜３頁４行２文字目）
（当審仮訳）
「本発明の目的の１つは，サイトが改善されたスピード及び効率でクライアントに供することを可能とする，Ｗｅｂサーバのクラスタに基づく，Ｗｅｂサイトアーキテクチャを提供することである。
　本発明の更なる目的は，あるＨＴＴＰセッションの中でＷｅｂサイトをアクセスしたクライアントと当該サイトのＷｅｂサーバのクラスタの１つとの間のアフィニティを維持するための方法を提供することである。
　本発明の更なる目的は，あるＨＴＴＰセッションの中でＷｅｂサイトをアクセスしたクライアントと当該サイトのＷｅｂサーバのクラスタの１つにおいて実行中のアプリケーションとのアフィニティを維持するための方法を提供することである。
　本発明の好ましい実施例では，Ｗｅｂサイトは，クライアントのＨＴＴＰリクエストを複数のサーバの間で分配する１つのルータ及びセッションデータを蓄積する１つのセッションホルダを伴う，複数のＷｅｂサーバホストで構成される。各ホストはＷｅｂサーバプロセスを実行し，オプションとして，同様に，１つ又は複数の他のアプリケーションプロセスを実行する。クライアントがＷｅｂサイトをアクセスしサーバの１つとＨＴＴＰセッションを実施すると，当該サーバはクライアントにセッション識別子（セッションＩＤ）をダウンロードする。セッションＩＤは，Ｗｅｂサーバホスト，セッションに応じた当該ホスト上のプロセス，バージョン有効性計数値を識別するデータを含む。セッションＩＤは好ましくはクッキー形式でクライアントにより蓄積される。
　Ｗｅｂサイトページはコード化され，クライアントがその後再びそのＷｅｂサイトをアクセスしたときにセッションＩＤはクライアントのＨＴＴＰリクエストに含まれる。ルーターは，クライアントのＨＴＴＰリクエストを以前と同じホストにルーティングするために，セッションＩＤを読み取る。それから，ホストは，リクエストを適切なプロセスにパスするために，そしてバージョン有効性カウンタの値をチェックするために，前記ＩＤを読み取る。」
　
（４）
（説明の３頁２２行〜４頁１７行）
（当審仮訳）
「ここで説明される好ましい実施例では，クライアントのセッションＩＤ情報を読み取り，それに従ってクライアントのＨＴＴＰリクエストをルーティングするルーターを使用するが，本発明の方法はルーター無しでもリクエストを処理してセッションのアフィニティを維持するために使用することができる。このような場合，ＷｅｂサーバはセッションＩＤ情報を読み取り，セッションを適切なアプリケーションプロセスに割当て，キャッシュデータを有効化するためにそれを用いる。更に，これらの好ましい実施例はＷｅｂサーバ上で実行するＨＴＴＰセッションを扱うが，本発明の原理は他のクラスターベースのクライアント／サーバアプリケーション層プロトコルについても同じように適用できる。そのようなプロトコルは，サーバにクライアントに対してセッションＩＤを送信することを可能とし，クライアントにメッセージのはじめにそのセッションＩＤを返すことを可能とする。
　このため本発明の好ましい実施例に従って，以下の構成を含むクライアントとサーバのクラスタ間の通信制御方法が提供される。
　クライアントと選択されたクラスタ内のサーバの１つとの間でネットワークを介して第１の通信セッションを実施する；
　前記クライアントによる蓄積のために前記第１の通信セッションにより生成された識別情報を前記ネットワークを介して送信する；
　第２の通信セッションを実施するために前記クライアントからリクエストを受信する，当該リクエストは前記識別情報を含んでいる；
　前記リクエスト中の前記識別情報に応じて前記リクエストを選択されたサーバにルーティングする。
　好ましくは，第１通信セッションの実施は，アプリケーションプロトコルを用いた通信，最も好ましくはハイパー・テキスト・伝送・プロトコル（ＨＴＴＰ）を含み，そこではリクエストの受信はＨＴＴＰリクエストの受信を含む。更に好ましくは，ネットワークはインターネットを含み，そこではサーバはＷｅｂサーバを含む。
　好ましくは，識別情報は選択されたサーバのネットワークアドレスのための参照を含み，そこでは当該ネットワークアドレスは伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を含む。更に好ましくは，識別情報は選択されたサーバに関連付けられたルーティングポートの識別を含む。」
　
（５）
（説明の８頁１６行〜９頁３行８文字目）
（当審仮訳）
「図２は，本発明の好ましい実施例に従って，セッションＩＤ５０として供されるデータ構造の概略を表すブロック図である。クライアント２４がサイト２０と最初のＨＴＴＰセッションを実施すると，例えばサーバ３２であるＷｅｂサーバがクライアントに割り当てられ，当該ＨＴＴＰセッション中及び／又は当該ＨＴＴＰセッションの終わりでクライアントにセッションＩＤをダウンロードする。セッションＩＤは好ましくは，周知のクッキー形式でクライアント２４にダウンロードされ，クライアントのハードディスクに蓄積される。ＩＤ５０は好ましくは，ＷｅｂサーバホストのＴＣＰ／ＩＰアドレス及びルーターポートを各々識別するＴＣＰ／ＩＰアドレスフィールド５２及びポートフィールド５４と同様に，一意のセッションＩＤ値５１を含む。代替的に，フィールド５２及び５４のアドレス及びポートに代えて，前記ＩＤはサーバホストを識別するためにルータ３０により使用されるルックアップテーブルに対するキーを含むことができる。前記ＩＤはまた，最新のセッションに応じたＷｅｂサーバ又は他のアプリケーションサーバプロセス３８を識別するプロセス識別フィールド５６，及びその機能を後で述べるバージョン有効性計数フィールド５８を含む。
　続くＨＴＴＰセッションでは，クライアントは，蓄積したセッションＩＤ５０を，新しいセッションを開始するためのＨＴＴＰリクエストの一部としてＷｅｂサイトに伝達する。好ましくはセッションＩＤは，クライアントにより蓄積されたクッキーデータが慣例的にＨＴＴＰリクエストの中で伝達されるのと実質的に同じように，ＨＴＴＰリクエストヘッダの中でクライアントからＷｅｂサーバに伝達される。」
　
（６）
（説明の９頁１０〜１７行３文字目）
（当審仮訳）
「図３は，本発明の好ましい実施例に従ってサイト２０で受信したクライアント２４からのＨＴＴＰリクエストをルーティングする方法を概略的に表すフロー図である。ＨＴＴＰインターセプションステップ６０では，ルーター３０は入来するＨＴＴＰリクエストをインターセプトし，第１ＩＤ抽出ステップ６２ではリクエストからセッションＩＤを抽出する。ホスト及びポート抽出ステップ６４では，リクエストがルーティングされるべきＷｅｂサーバホストのアドレス及びルーターポートを決定するために，ルーターはセッションＩＤ５０（図２）のフィールド５２及び５４の情報を用いる。これは，たいていクライアントの先のＨＴＴＰセッションでクライアント２４に供された同じサーバ，例えばサーバ３２となる。」
　
（７）
（説明の１１頁８〜１５行）
（当審仮訳）
「ステップ１００で関連する変更が検出されると，データセービングステップ１０２でサーバ３２は修正されたセッションデータをセッションホルダー４０に送る。このステップはセッション中又はセッションの終わりで発生する。同時に，カウンタ歩進ステップ１０４で，サーバはバージョン有効性カウンタを更新する。更新された計数値はサーバのキャッシュ，及びセッションホルダによりセーブされたセッションデータに記録される。サーバは，他のデータフィールドで起こるいかなる変更と同じように，フィールド５８に新しい計数値を含むようにセッションＩＤ５０を修正し，クライアントにより蓄積されるようＩＤ送信ステップ１０６で修正されたＩＤを送信する。クライアントは次のＨＴＴＰセッションで修正されたセッションＩＤを使用する。」
　
　
　上記記載及び当該技術分野の技術常識を考慮すると，引用例に記載された発明は，上記（１）記載のように，Ｗｅｂサイトを構成する複数のサーバからなる複数のクラスタがクライアントからの大量の通信要求を処理するネットワーク・アプリケーションに関するものであって，
　
ア．上記（３）の「クライアントがＷｅｂサイトをアクセスしサーバの１つとＨＴＴＰセッションを実施すると，・・・」，上記（４）の「クライアントと選択されたクラスタ内のサーバの１つとの間でネットワークを介して第１の通信セッションを実施する；・・・好ましくは，第１通信セッションの実施は，アプリケーションプロトコルを用いた通信，最も好ましくはハイパー・テキスト・伝送・プロトコル（ＨＴＴＰ）を含み，そこではリクエストの受信はＨＴＴＰリクエストの受信を含む。」及び上記（５）の「クライアント２４がサイト２０と最初のＨＴＴＰセッションを実施すると，・・・」の記載によれば，サイトがクライアントから最初のＨＴＴＰセッション（第１の通信セッション）を受信することが記載されているといえる。
　ここで，上記（３）の「本発明の好ましい実施例では，Ｗｅｂサイトは，クライアントのＨＴＴＰリクエストを複数のサーバの間で分配する１つのルータ及びセッションデータを蓄積する１つのセッションホルダを伴う，複数のＷｅｂサーバホストで構成される。」の記載によれば，上記「サイト」は「複数のＷｅｂサーバホストで構成される」ものである。
　したがって，引用例には『複数のＷｅｂサーバホストで構成されるサイトがクライアントから最初のＨＴＴＰセッションを受信する動作』が記載されていると認められる。
　
イ．上記（３）の「クライアントがＷｅｂサイトをアクセスしサーバの１つとＨＴＴＰセッションを実施すると，当該サーバはクライアントにセッション識別子（セッションＩＤ）をダウンロードする。」，上記（４）の「前記クライアントによる蓄積のために前記第１の通信セッションにより生成された識別情報を前記ネットワークを介して送信する；」及び上記（５）の「クライアント２４がサイト２０と最初のＨＴＴＰセッションを実施すると，例えばサーバ３２であるＷｅｂサーバがクライアントに割り当てられ，当該ＨＴＴＰセッション中及び／又は当該ＨＴＴＰセッションの終わりでクライアントにセッションＩＤをダウンロードする。」の記載によれば，第１の通信セッション（最初のＨＴＴＰセッション）によりサイトはセッション識別子を生成するといえる。
　ここで，上記（５）の「ＩＤ５０は好ましくは，ＷｅｂサーバホストのＴＣＰ／ＩＰアドレス及びルーターポートを各々識別するＴＣＰ／ＩＰアドレスフィールド５２及びポートフィールド５４と同様に，一意のセッションＩＤ値５１を含む。代替的に，フィールド５２及び５４のアドレス及びポートに代えて，前記ＩＤはサーバホストを識別するためにルータ３０により使用されるルックアップテーブルに対するキーを含むことができる。前記ＩＤはまた，最新のセッションに応じたＷｅｂサーバ又は他のアプリケーションサーバプロセス３８を識別するプロセス識別フィールド５６，及びその機能を後で述べるバージョン有効性計数フィールド５８を含む。」及び図２の記載によれば，「ＷｅｂサーバホストのＴＣＰ／ＩＰアドレス及びルーターポート」や「前記ＩＤはサーバホストを識別するためにルータ３０により使用されるルックアップテーブルに対するキー」は「ｗｅｂサーバホストを識別するための情報」といえ，少なくともサイトを構成する複数のＷｅｂサーバホストの中では一意であることは当業者に明らかである。また，上記「セッション識別子」は，ｗｅｂサーバホストを識別するための情報の他に，セッションＩＤ値５１及びバージョン有効性計数フィールド５８を含むといえる。
　したがって，引用例には，『前記複数のＷｅｂサーバホストで構成されるサイトが，ｗｅｂサーバホストを識別するための情報を含むセッション識別子を作成する動作であって，前記ｗｅｂサーバホストを識別するための情報は，サイトを構成する複数のＷｅｂサーバホストの中では一意であり，前記セッション識別子のｗｅｂサーバホストを識別するための情報の他にセッションＩＤ値５１及びバージョン有効性計数フィールド５８を含むセッション識別子を作成する動作』が記載されていると認められる。
　
ウ．上記（３）の「クライアントがＷｅｂサイトをアクセスしサーバの１つとＨＴＴＰセッションを実施すると，当該サーバはクライアントにセッション識別子（セッションＩＤ）をダウンロードする。・・・セッションＩＤは好ましくはクッキー形式でクライアントにより蓄積される。」，上記（４）の「前記クライアントによる蓄積のために前記第１の通信セッションにより生成された識別情報を前記ネットワークを介して送信する；第２の通信セッションを実施するために前記クライアントからリクエストを受信する，当該リクエストは前記識別情報を含んでいる；」及び上記（５）の「クライアント２４がサイト２０と最初のＨＴＴＰセッションを実施すると，例えばサーバ３２であるＷｅｂサーバがクライアントに割り当てられ，当該ＨＴＴＰセッション中及び／又は当該ＨＴＴＰセッションの終わりでクライアントにセッションＩＤをダウンロードする。セッションＩＤは好ましくは，周知のクッキー形式でクライアント２４にダウンロードされ，クライアントのハードディスクに蓄積される。」の記載によれば，サイトがクライアントにセッション識別子を含む情報を送信し，クライアントでセッション識別子が蓄積されることは明らかである。
　そして，上記（４）の「第２の通信セッションを実施するために前記クライアントからリクエストを受信する，当該リクエストは前記識別情報を含んでいる；」及び上記（５）の「続くＨＴＴＰセッションでは，クライアントは，蓄積したセッションＩＤ５０を，新しいセッションを開始するためのＨＴＴＰリクエストの一部としてＷｅｂサイトに伝達する。好ましくはセッションＩＤは，クライアントにより蓄積されたクッキーデータが慣例的にＨＴＴＰリクエストの中で伝達されるのと実質的に同じように，ＨＴＴＰリクエストヘッダの中でクライアントからＷｅｂサーバに伝達される。」の記載によれば，第２の通信セッションのリクエストには蓄積されたセッション識別子が含まれているといえる。
　したがって，引用例には『前記クライアントで前記セッション識別子を蓄積し第２の通信セッションのリクエストに前記セッション識別子を含むことができるように，前記複数のＷｅｂサーバホストで構成されるサイトが前記クライアントに前記セッション識別子を含む情報を送信する動作』が記載されていると認められる。
　
エ．上記（４）の「前記リクエスト中の前記識別情報に応じて前記リクエストを選択されたサーバにルーティングする。」及び上記（６）の記載によれば，引用例には『前記第２の通信セッションのリクエストから前記セッションＩＤを抽出し，前記セッションＩＤ５０のフィールドの情報を用いてルーティングされるべきＷｅｂサーバホストを決定する動作』が記載されていると認められる。
　
オ．上記ア．〜エ．のとおり，引用例には『複数のＷｅｂサーバホストで構成されるサイトにおいて実行される方法』が記載されていると認められる。
　
　したがって，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。
「複数のＷｅｂサーバホストで構成されるサイトにおいて実行される方法であって，
　前記複数のＷｅｂサーバホストで構成されるサイトがクライアントから最初のＨＴＴＰセッションを受信する動作と，
　前記複数のＷｅｂサーバホストで構成されるサイトが，ｗｅｂサーバホストを識別するための情報を含むセッション識別子を作成する動作であって，前記ｗｅｂサーバホストを識別するための情報は，サイトを構成する複数のＷｅｂサーバホストの中では一意であり，前記セッション識別子のｗｅｂサーバホストを識別するための情報の他にセッションＩＤ値５１及びバージョン有効性計数フィールド５８を含むセッション識別子を作成する動作と，
　前記クライアントで前記セッション識別子を蓄積し第２の通信セッションのリクエストに前記セッション識別子を含むことができるように，前記複数のＷｅｂサーバホストで構成されるサイトが前記クライアントに前記セッション識別子を含む情報を送信する動作と，
　前記第２の通信セッションのリクエストから前記セッションＩＤを抽出し，前記セッションＩＤ５０のフィールドの情報を用いてルーティングされるべきＷｅｂサーバホストを決定する動作と
　を含むことを特徴とする方法。」
　
　
３．対比・判断
（１）引用発明の「複数のＷｅｂサーバホストで構成されるサイト」，「最初のＨＴＴＰセッション」と本願発明の「ホストデバイス」，「セッションを開始するための要求」とは表現が異なるのみであって，実質的な差異はない。したがって，両者は「ホストデバイスにおいて実行される方法であって，前記ホストデバイスが，クライアントからセッションを開始するための要求を受信する動作」を含む点で差異はない。
　
（２）引用発明の「ｗｅｂサーバホストを識別するための情報」は本願発明の「ホスト識別子」に相当し，ｗｅｂサーバホストを識別するための情報を含むセッション識別子を作成するのだから「ホスト識別子を使用してセッション識別子を作成する」といえる。
　また，引用発明の「サイトを構成する複数のＷｅｂサーバホスト」は，上記２．の（３）の「当該サイトのＷｅｂサーバのクラスタの１つ」，同（４）の「クライアントと選択されたクラスタ内のサーバの１つとの間でネットワークを介して第１の通信セッションを実施する」の記載に照らせば，「所与のホストクラスタに属する複数のホスト」といえるから，「前記ホスト識別子は，所与のホストクラスタに属する複数のホストにわたって前記ホストデバイスに対して一意であ」る点で本願発明と差異はない。
　更に，引用発明のセッション識別子内で「ｗｅｂサーバホストを識別するための情報」が配置される部分（ＴＣＰ／ＩＰアドレスフィールド５２及びポートフィールド５４又はキーが配置される部分）を「第１のフィールド」と称するのは任意である。そして，引用発明の「セッションＩＤ値５１及びバージョン有効性計数フィールド５８」と本願発明の「当該セッション識別子の一意性を高める値」とは「ホスト識別子以外の値」である点で一致しており，セッション識別子内で当該値を配置する部分を「第２のフィールド」と称するのは任意である。
　したがって，引用発明と本願発明とは「前記ホストデバイスが，ホスト識別子を使用してセッション識別子を作成する動作であって，前記ホスト識別子は，所与のホストクラスタに属する複数のホストにわたって前記ホストデバイスに対して一意であり，前記セッション識別子の第１のフィールドに前記ホスト識別子を追加し，前記セッション識別子の第２のフィールドに，ホスト識別子以外の値を追加することによって，前記第１のフィールドと前記第２のフィールドとを含むセッション識別子を作成する動作」を含む点で一致している。
　
（３）引用発明の「前記複数のＷｅｂサーバホストで構成されるサイト」からクライアントに送信される「セッション識別子を含む情報」を「ホストセッション開始メッセージ」と称するのは任意である。また，「セッション識別子を含む情報」を送信する以上，当該情報を生成していることは明らかであり，当該生成する動作を「定式化する動作」と称するのは任意である。
　したがって，引用発明と本願発明とは「前記ホストデバイスが，前記セッション識別子を用いて，該セッション識別子に対応するセッションについてホストセッション開始メッセージを定式化する動作」を含む点で一致している。
　
（４）引用発明の「前記第２の通信セッションのリクエストから前記セッションＩＤを抽出し，前記セッションＩＤ５０のフィールドの情報を用いてルーティングされるべきＷｅｂサーバホストを決定する動作」は，上記２．の（３）の「あるＨＴＴＰセッションの中でＷｅｂサイトをアクセスしたクライアントと当該サイトのＷｅｂサーバのクラスタの１つとの間のアフィニティを維持するための方法を提供する」の記載に照らせば，セッション識別子に対応するセッションを確立するためのものであることは明らかである。したがって，両者は「前記ホストデバイスが，前記セッション識別子に対応するセッションを確立する動作」を含む点で一致している。
　
　したがって，本願発明と引用発明とを対比すると，両者は，以下の点で一致し，また，相違している。
（一致点）
「ホストデバイスにおいて実行される方法であって，
　前記ホストデバイスが，クライアントからセッションを開始するための要求を受信する動作と，
　前記ホストデバイスが，ホスト識別子を使用してセッション識別子を作成する動作であって，前記ホスト識別子は，所与のホストクラスタに属する複数のホストにわたって前記ホストデバイスに対して一意であり，前記セッション識別子の第１のフィールドに前記ホスト識別子を追加し，前記セッション識別子の第２のフィールドに，ホスト識別子以外の値を追加することによって，前記第１のフィールドと前記第２のフィールドとを含むセッション識別子を作成する動作と，
　前記ホストデバイスが，前記セッション識別子を用いて，該セッション識別子に対応するセッションについてホストセッション開始メッセージを定式化する動作と，
　前記ホストデバイスが，前記セッション識別子に対応するセッションを確立する動作と
　を含むことを特徴とする方法。」
　
（相違点１）本願発明のホスト識別子は「別のホストクラスタに属する別のホストに関しては一意ではない」ものであるのに対し，引用発明の「ｗｅｂサーバホストを識別するための情報」は当該事項が明らかでない点。
　
（相違点２）第２のフィールドに追加されるホスト識別子以外の値が，本願発明は「当該セッション識別子の一意性を高める値」であるのに対し，引用発明は「セッションＩＤ値５１及びバージョン有効性計数フィールド５８」であり，セッション識別子の一意性を高めるか否か不明である点。
　
（相違点３）ホストセッション開始メッセージを定式化する動作が，本願発明は「前記セッション識別子の前記第１のフィールドおよび前記第２のフィールド内のコンテンツが前記セッションに対するクライアントセッション継続メッセージにおいて無変更で返されるように，ホストセッション開始メッセージを定式化する動作」であるのに対し，引用発明は当該構成を有していない点。
　
（相違点４）本願発明は「前記セッションのタイプは，ＳＳＬセッション，ＴＬＳセッション，セキュアインターネットプロトコル（ＩＰＳｅｃ）セッション，ＨＴＴＰクッキーベースセッション，ＰＰＴＰセッション，ＩＰＳｅｃ／Ｌ２ＴＰセッション，独自セッション，ターミナルサーバセッション，および管理者定義セッションを含む，複数のセッションタイプのうちのいずれかである」なる構成を有しているのに対し，引用発明は当該構成を有していない点。
　
　以下，上記各相違点について検討する。
（相違点１についての検討）
　引用発明においても本願発明と同様に別のホストクラスタに属する別のホストについてまで一意である必要はないことは当業者に明らかであるから，「ｗｅｂサーバホストを識別するための情報」を「別のホストクラスタに属する別のホストに関しては一意ではない」とすることは適宜採用し得ることに過ぎない。
　
（相違点２についての検討）
　上記２．の（５）の「一意のセッションＩＤ値５１を含む。」及び同（７）の「関連する変更が検出されると，・・・カウンタ歩進ステップ１０４で，サーバはバージョン有効性カウンタを更新する。・・・フィールド５８に新しい計数値を含むようにセッションＩＤ５０を修正し，クライアントにより蓄積されるようＩＤ送信ステップ１０６で修正されたＩＤを送信する。」の記載によれば，引用例には明記していないが，引用発明のセッションＩＤ値５１及びバージョン有効性計数フィールド５８はセッション識別子の一意性を高めていると言い得ることは明らかである。したがって，相違点２な実質的な相違はない。
　
（相違点３についての検討）
　本願明細書には定式化動作と無変更で返されることとの関係については補正の根拠としてあげられている【００６６】に「ホスト識別子２１４を，その代わりに，セッション識別子２１０のフィールドと異なるフィールドに埋め込むことができる。たとえば，クライアント１０２に送られ，そのクライアント１０２が既存セッションの再開を要求している時に無変更で返される特定のフィールドを使用することができる。」と記載されるのみである。しかし，これは，ホスト識別子２１４をセッション識別子２１０のフィールドと異なるフィールドに埋め込むことを前提とするものであるから，「前記セッション識別子の第１のフィールドに前記ホスト識別子を追加し，前記セッション識別子の第２のフィールドに，当該セッション識別子の一意性を高める値を追加することによって，前記第１のフィールドと前記第２のフィールドとを含むセッション識別子を作成する」（すなわち，ホスト識別子２１４をセッション識別子２１０のフィールド内に埋め込んでいる。）本願発明に対応するものではない。また，上記【００６６】の記載をみても，クライアントの間でセッションメッセージの特定のフィールドを無変更で返すという取り決めがあって初めて実現するものと解され，そのような取り決め無しに定式化したところで必ずしもクライアントセッション継続メッセージにおいて無変更で返され得るとは認められない。したがって，相違点３に係る事項は，【０００６】に記載されるようなホスト識別子セッション識別子２１０のフィールドと異なるフィールドに埋め込むような定式化動作をすることを意味するものではなく，定式化されたセッション識別子の第１のフィールドおよび第２のフィールド内のコンテンツがセッションに対するクライアントセッション継続メッセージにおいて無変更で返されるようにクライアントとの間で取り決めがされていると解するのが自然である。
　いっぽう，引用発明は「前記第２の通信セッションのリクエストから前記セッションＩＤを抽出し，前記セッションＩＤ５０のフィールドの情報を用いてルーティングされるべきＷｅｂサーバホストを決定する」ものであり，上記２．の（４）の「クライアントにメッセージのはじめにそのセッションＩＤを返すことを可能とする。」及び同（６）の「第１ＩＤ抽出ステップ６２ではリクエストからセッションＩＤを抽出する。ホスト及びポート抽出ステップ６４では，リクエストがルーティングされるべきＷｅｂサーバホストのアドレス及びルーターポートを決定するために，ルーターはセッションＩＤ５０（図２）のフィールド５２及び５４の情報を用いる。」の記載に照らせば，少なくともセッションＩＤ５０のフィールド５２及び５４の情報は無変更で返されており，継続するセッションにおいてクライアントがセッション識別子の情報を変更して返す必然性も見出せないから，「前記セッション識別子の前記第１のフィールドおよび前記第２のフィールド内のコンテンツが前記セッションに対するクライアントセッション継続メッセージにおいて無変更で返される」ようにすることは当業者が容易になし得ることに過ぎない。
　
（相違点４についての検討）
　ＳＳＬセッション，ＴＬＳセッション，セキュアインターネットプロトコル（ＩＰＳｅｃ）セッション，ＨＴＴＰクッキーベースセッション，ＰＰＴＰセッション，ＩＰＳｅｃ／Ｌ２ＴＰセッション，独自セッション，ターミナルサーバセッション，および管理者定義セッションはいずれも周知のものであり，これらの各セッションの間には本願発明のセッションアフィニティ保存に係る構成と密接に関連する共通の技術的特徴は見出せず，単に採用し得るセッションの例を羅列しているに過ぎないものであるから，当業者が容易に採用し得ることに過ぎない。また，上記２．の（３）の「セッションＩＤは好ましくはクッキー形式でクライアントにより蓄積される。」，同（４）の「セッションＩＤは好ましくは，周知のクッキー形式でクライアント２４にダウンロードされ，クライアントのハードディスクに蓄積される。・・・好ましくはセッションＩＤは，クライアントにより蓄積されたクッキーデータが慣例的にＨＴＴＰリクエストの中で伝達されるのと実質的に同じように・・・」の記載に照らせば，引用発明のセッションは少なくとも「ＨＴＴＰクッキーベースセッション」といえるから，相違点４に実質的な相違はない。
　
　そして，本願発明の作用効果も，引用発明に基づいて当業者が予測し得る範囲のものであり，格別なものではない。
　
　
４．むすび
　以上のとおり，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものと認められるから，特許法第２９条第２項の規定により，特許を受けることができない。
　
　よって，結論のとおり審決する。