2016-008236

特願２０１４－５３４５８２「課金システムにおいてインテリジェント・ルータを使用するための方法，およびそれに関連する装置」拒絶査定不服審判事件〔平成２５年　４月１１日国際公開，ＷＯ２０１３／０５２２５６，平成２６年１１月２７日国内公表，特表２０１４－５３１８７５〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 第１　出願の経緯と本願発明 本願は，２０１２年９月１４日（パリ条約による優先権主張外国庁受理　２０１１年１０月７日　米国）を国際出願日とする特許出願であって，平成２７年５月２２日付けで拒絶理由通知がされ，これに対して同年１１月２５日付けで手続補正がされたが，平成２８年２月１日付けで拒絶査定（原査定）がされ，これに対し，同年６月３日に拒絶査定不服審判が請求されたものである。 そして，請求項１に係る発明（以下，「本願発明」という。）は，明細書，特許請求の範囲及び図面の記載からみて，平成２７年１１月２５日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。 「　サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムを使用するための方法であって， 課金システムにおけるルータにおいて，サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するステップであって，前記アカウンティング要求は，通信セッションに関連して，前記サービス・プロバイダ・ネットワークにおける前記ネットワーク要素によって提供されるサービスに関連づけられ，前記課金システムは，１つまたは複数の通信セッションに関連して，前記サービス・プロバイダ・ネットワークの１つまたは複数のネットワーク要素からのアカウンティング要求を処理するための，前記ルータに関連する複数の課金収集機能サーバを含む，受信するステップと， 修正されたアカウンティング要求を形成するように，前記ルータにおいて前記受信されたアカウンティング要求を修正するステップと， 前記ルータから，前記複数の課金制御機能サーバから選択される第１の課金収集機能サーバへ前記修正されたアカウンティング要求を送信するステップと， 前記第１の課金収集機能サーバが前記修正されたアカウンティング要求を処理することができなかったことを示すアカウンティング応答を，前記ルータにおいて前記第１の課金収集機能サーバから受信するステップと， 前記ルータから前記第１の課金収集機能サーバへと前記修正されたアカウンティング要求を再送信するステップ，または改訂されたアカウンティング要求を形成するように，前記ルータにおいて前記修正されたアカウンティング要求を変更し，前記ルータから，前記複数の課金制御機能サーバから選択される代替の課金収集機能サーバへと前記改訂されたアカウンティング要求を送信するステップとを含む方法。」 第２　引用例，引用発明等 １　引用例１について 原査定の拒絶の理由に引用された特開２００３－１４３２５０号公報（以下，「引用例１」という。）には，「代理応答方法」（発明の名称）に関して，図面とともに以下の事項が記載されている。 ア　「【０００１】 【発明が属する技術分野】本発明は，パケットを中継するコンピュータにおける代理応答技術に関する。 【０００２】 【従来の技術】ラディウス（RADIUS:Remote Authentication Dial In-User Service）サーバは，例えば公衆回線網及び当該公衆回線網に接続しているアクセス・サーバを介してユーザ端末からユーザ認証情報を受信すると，ユーザ認証処理を実施し，ＤＮＳ（Domain Name Sysyem）サーバ指定やＰＰＰ（Point-to-Point Protocol）接続指定等の接続制御や，課金に必要な情報を取得したりするサーバである。これらの処理が完了すると，ユーザ端末は例えばインターネットへの接続を許可されたり，特別なサービスを受けることができるようになる。ＲＡＤＩＵＳプロトコルについては，ＲＦＣ（Request For Comments）２８６５及びＲＦＣ２８６６に規定がなされている。ＲＡＤＩＵＳプロトコルは，ＵＤＰ（User Datagram Protocol）を用いている。 【０００３】例えば複数のアクセスポイントにアクセス・サーバを設けて，このアクセス・サーバをネットワークで接続し，当該ネットワークを例えばＩＳＰ（Internet Service Provider）等の企業に開放するというサービスがある。このサービスを利用する企業は，自己のシステムに大きな変更を加えることなくユーザに対してアクセス手段を増やすことができる。各企業は，ＲＡＤＩＵＳサーバを用意して，上記ネットワークに接続する。ネットワークには，ユーザからの要求を当該ユーザに対してサービスを行う企業のＲＡＤＩＵＳサーバに振り分けるために中継サーバが設けられる。この中継サーバでは，転送結果を記録してネットワークの使用量を正確に把握して正確な課金を行ったり，パケットの内容を確認して変更したりする。 【０００４】このような環境において，１つの企業のＲＡＤＩＵＳサーバが障害などでダウンしてしまうと，リクエストに対するレスポンスが得られないために，アクセス・サーバは同じリクエストに係るパケットを何度も再送する。そのためネットワークのトラフィックが増加して，正常に動作している他の企業のＲＡＤＩＵＳサーバに対してもレスポンスの低下を招いてしまうという問題がある。また，通常送信したパケットはアクセスサーバ側で管理しているが，再送によるトラフィックの増加によりアクセス・サーバのバッファ・オーバーフローが発生し，パケットが失われてしまう場合もあり，正確に課金できない可能性がある。中継サーバやアクセス・サーバのログを調べて障害中に送信されていたパケットを探し，企業側にその情報を通知しなければならないが，量が多いため不可能な場合も多い。 （…中略…） 【０００８】さらに本発明の他の目的は，課金リクエストに係るパケットの喪失を防止し，正確な課金情報の取得を可能とする技術を提供することである。」（第２ページ） イ　「【００１７】 【発明の実施の形態】図１に本発明の一実施の形態に係るシステム概要図を示す。例えばパーソナル・コンピュータであるユーザ端末７は公衆回線網９を介してアクセス・サーバＡ（３）に接続する。また，例えばノート型コンピュータであるユーザ端末２７も公衆回線網９を介してアクセス・サーバＡ（３）に接続する。例えばパーソナル・コンピュータであるユーザ端末２５は，公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。また，例えばＰＤＡ（Personal Digital Asistance）であるユーザ端末２９も公衆回線網２３を介してアクセス・サーバＢ（２１）に接続する。端末の種類及び数は，これらに限定されるものではなく，携帯電話機が用いられる場合もある。また，アクセス・サーバは，サーバのようなコンピュータであってもよいし，ルータのような接続機器であっても良いが，ここではこれらをコンピュータとして説明する。また，公衆回線網に接続するアクセス・サーバの数は２に限定されるものではなく，より多くのアクセス・サーバを設けることができる。 【００１８】アクセス・サーバＡ（３）及びアクセス・サーバＢ（２１）は，ＩＰ（Internet Protocol）ネットワーク１に接続されている。ＩＰネットワーク１は例えばインターネット１１にも接続されている。また，ＩＰネットワーク１には，中継サーバ５も接続されている。図１では中継サーバは１台しか設けられていないが，複数台設ける場合もある。中継サーバ５は，企業ＡのＲＡＤＩＵＳサーバである課金サーバ１３ａ及び認証サーバ１３ｂに接続されている。また，企業ＢのＲＡＤＩＵＳサーバである課金サーバ１５ａ及び認証サーバ１５ｂに接続されている。中継サーバ５に接続される企業のＲＡＤＩＵＳサーバの数は２に限定されない。また，ここでは説明のため課金サーバ及び認証サーバを分けて説明しているが，これらは１台のサーバにてその機能を実現することも可能である。また，バックアップや処理負荷分散のために多くの課金サーバや認証サーバを一つの企業が用意する場合もある。課金サーバ１３ａは企業Ａのユーザの課金情報を蓄積する課金ＤＢ１８を管理しており，認証サーバ１３ｂは企業Ａのユーザの認証情報を格納する認証ＤＢ１７を管理している。課金サーバ１５ａは企業Ｂのユーザの課金情報を蓄積する課金ＤＢ１９を管理しており，認証サーバ１５ｂは企業Ｂのユーザの認証情報を格納する認証ＤＢ２０を管理している。 【００１９】中継サーバ５には，代理応答処理部５１と代理応答後処理部５３とが設けられている。これらの処理内容については後に図を用いて説明する。また，中継サーバ５は，中継サーバ５が代理応答したリクエストについてのパケット・データを格納する代理応答リスト格納部５５及び中継サーバ５が中継するＲＡＤＩＵＳサーバの稼動状況に関する情報についてのステータス表を格納するステータス表格納部５７を有する。」（第３－４ページ） ウ　「【００２０】次に図２乃至図４を用いて，図１に示したアクセス・サーバ（ここではアクセス・サーバＡ（３）），中継サーバ５，認証サーバ（ここでは認証サーバ１３ｂ），課金サーバ（ここでは課金サーバ１３ａ）の従来における処理を説明する。 【００２１】最初に，例えばユーザ端末７からログイン要求を受信するとアクセス・サーバＡ（３）は，認証リクエスト（Access-Request）のパケットを生成し，中継サーバ５に送信する（ステップ（１））。中継サーバ５は，アクセス・サーバＡ（３）から認証リクエストのパケットを受信すると一旦記憶装置に格納し，パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後，認証リクエストのパケットを認証サーバ１３ｂに転送する（ステップ（２））。 【００２２】認証サーバ１３ｂは，中継サーバ５から認証リクエストのパケットを受信すると一旦記憶装置に格納し，認証ＤＢ１７に格納されたデータを用いて認証処理を実施する（ステップ（３））。認証処理については従来と何ら変わりがないので，これ以上述べない。ここでは認証に成功したものとする。そうすると，認証サーバ１３ｂは，認証レスポンス（Access-Accept）のパケットを生成し，中継サーバ５に送信する（ステップ（４））。中継サーバ５は，認証サーバ１３ｂから認証レスポンスのパケットを受信すると一旦記憶装置に格納し，パケット・データを確認して送信先のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し，パケットの送信先を変更するなどの処理を施した後，認証レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（５））。アクセス・サーバＡ（３）は，中継サーバ５から認証レスポンスのパケットを受信する。ここまでの処理で，認証が完了し，ＰＰＰセッションが確立される（ステップ（６））。 【００２３】次に，アクセス・サーバＡ（３）は，開始（後に述べるが属性Acct-Status-Typeの値が１（Start））を表す課金リクエスト（Accounting-Request）のパケットを生成し，中継サーバ５に送信する（ステップ（７））。中継サーバ５は，アクセス・サーバＡ（３）から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し，パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後，開始を表す課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（８））。 【００２４】課金サーバ１３ａは，中継サーバ５から開始を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し，課金処理を実施する（ステップ（９））。すなわち，課金開始を認識し，課金開始を課金ＤＢ１８に登録する。そして，課金サーバ１３ａは，課金レスポンス（Accounting-Response）のパケットを生成し，中継サーバ５に送信する（ステップ（１０））。中継サーバ５は，課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し，パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し，パケットの送信先を変更するなどの処理を施した後，課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（１１））。アクセス・サーバＡ（３）は，中継サーバ５から課金レスポンスのパケットを受信する。ここまでの処理でユーザ端末７は通信を開始することができるようになる（ステップ（１２））。すなわち，例えばインターネットへのアクセスが可能となる。 【００２５】一方，例えばユーザ端末７からログオフ要求（通信終了通知など）を受信するとアクセス・サーバＡ（３）は，終了（後に述べるが属性Acct-Status-Typeの値が２（Stop））を表す課金リクエスト（Accounting-Request）のパケットを生成し，中継サーバ５に送信する（ステップ（２１））。中継サーバ５は，アクセス・サーバＡ（３）から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し，パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後，終了を表す認証リクエストのパケットを課金サーバ１３ａに転送する（ステップ（２２））。 【００２６】課金サーバ１３ａは，中継サーバ５から終了を表す課金リクエストのパケットを受信すると一旦記憶装置に格納し，課金処理を実施する（ステップ（２３））。すなわち，課金終了を認識し，課金終了を課金ＤＢ１８に登録する。そして，課金サーバ１３ａは，課金レスポンス（Accounting-Response）のパケットを生成し，中継サーバ５に送信する（ステップ（２４））。中継サーバ５は，課金サーバ１３ａから課金レスポンスのパケットを受信すると一旦記憶装置に格納し，パケット・データを確認して送信元のアクセス・サーバ（ここではアクセス・サーバＡ（３））を特定し，パケットの送信先を変更するなどの処理を施した後，課金レスポンスのパケットをアクセス・サーバＡ（３）に転送する（ステップ（２５））。アクセス・サーバＡ（３）は，中継サーバ５から課金レスポンスのパケットを受信する。このような処理によりユーザ端末７との通信は終了する（ステップ（２６））。」（第４－５ページ） エ　「【００３０】本実施の形態では，図５に示すような処理を実施することにより，図４で生じるようなネットワークの輻輳を防止する。すなわち，アクセス・サーバＡ（３）は，課金リクエストのパケットを生成し，中継サーバ５に送信する（ステップ（４１））。中継サーバ５は，アクセス・サーバＡ（３）から課金リクエストのパケットを受信すると一旦記憶装置に格納し，パケット・データに含まれるユーザＩＤ等のユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定すると共にパケットの送信先を変更するなどの処理を施した後，課金リクエストのパケットを課金サーバ１３ａに転送する（ステップ（４２））。ここまでは従来と同じである。 【００３１】しかし，課金サーバ１３ａがダウンしていると課金レスポンスは送られてこないので，中継サーバ５は，所定期間内に課金レスポンスを課金サーバ１３ａから受信しない場合には，課金リクエストのパケット・データを代理応答リスト格納部５５に格納し，当該課金リクエストのパケット・データから課金レスポンスを生成し，代理で課金レスポンスのパケットをアクセス・サーバＡ（３）に返信する（ステップ（４３））。このようにすれば，アクセス・サーバＡ（３）が何度も同じ課金レスポンスを送信するような事態を避けることができる。なお，中継サーバ５は，課金サーバ１３ａのダウンをステータス表格納部５７のステータス表に登録する。 【００３２】中継サーバ５は，所定の周期又は任意のタイミングにて，代理応答リスト格納部５５に格納された課金リクエストのパケット・データを読み出して，課金リクエストのパケットを生成し，課金サーバ１３ａに送信してみる（ステップ（４４））。この際，パケット・データに含まれるユーザＩＤから送信先である課金サーバ１３ａを特定し，またパケット・データに含まれる遅延時間を当該課金リクエストのパケットを受信した時刻からの経過時間分増加させるといった変更処理を実施している。 【００３３】もし，課金サーバ１３ａが既に復帰している場合には，中継サーバ５から課金リクエストのパケットを受信すると，課金処理を実施する（ステップ（４５））。なお，開始を表す課金リクエストの場合には，課金開始を認識し，課金開始に関する情報を課金ＤＢ１８に登録する。終了を表す課金リクエストの場合には，課金終了を認識し，課金終了に関する情報を課金ＤＢ１８に登録する。なお，上でも述べたように遅延時間は中継サーバ５により変更されているが，従来でもこの遅延時間を考慮して課金開始及び課金終了についての情報を登録するようになっているので，課金ＤＢ１８に登録される情報としては問題が生じない。すなわち，本実施の形態を採用してもＲＡＤＩＵＳサーバについて修正・変更は必要ない。 【００３４】なお，課金サーバ１３ａがまだ復帰していない場合には，中継サーバ５は課金リクエストのパケットを再送することはなく，この段階で課金サーバ１３ａへの送信を中止する。」（第５ページ） オ　「【００４４】ステップＳ３では，ステータス表において転送先の課金サーバが稼動中かを確認する。例えばユーザＩＤから課金リクエストの送付先が企業Ａであると特定された場合には，企業Ａに属する課金サーバのうち稼動している課金サーバを特定する。もし，稼動している課金サーバが存在しない場合には，いずれかの課金サーバを選択する。この際，リトライ回数が少ない課金サーバを選択するような構成であってもよい。 【００４５】代理応答処理部５１は，特定された課金サーバへ課金リクエストのパケットを送信する（ステップＳ５）。代理応答処理部５１は，所定期間，課金サーバからの課金レスポンスのパケットを待つ。そして，課金サーバから課金リクエストのパケットを受信したか判断する（ステップＳ７）。なお，１つの課金サーバから課金レスポンスを受信しない場合，上で述べたようにグループ内に複数の課金サーバが存在する場合もあるので，例えば課金レスポンスを受信するまで，当該グループ内の他の課金サーバに課金リクエストのパケットを送信するようにしても良い。また，ステータス表を参照して，グループ内の課金サーバを順番に選択して課金リクエストのパケットを送信するようにしても良い。 【００４６】もし，課金サーバから課金レスポンスのパケットを受信した場合には，一旦記憶装置に格納し，ステータス表格納部５７に格納されたステータス表を更新する（ステップＳ１５）。例えば，課金レスポンスのパケットを送信してきた課金サーバについて，ステータス表のステータスがダウンを表している場合には，稼動（ｕｐ）に変更し，リトライ回数を０にリセットする。なお，課金レスポンスを受信する前に何台かの課金サーバに課金リクエストを送信して応答が得られなかった場合には，当該応答が得られなかった課金サーバについてのステータスを変更する必要がある場合もある。もし，ステータスが稼動（ｕｐ）を表している場合には，ダウン（ｄｏｗｎ）に変更する。もし，ステータスがダウン（ｄｏｗｎ）を表している場合には，リトライ回数を増加させる。そして，パケットの識別子などにより要求元のアクセス・サーバを特定し，課金レスポンスのパケットの送信先を変更するなどの処理を施した後，特定されたアクセス・サーバに課金レスポンスのパケットを送信する（ステップＳ１７）。そして，次の処理に移行する。」（第７ページ） カ　「 」（第１０ページ） キ　「 」（第１１ページ） 以下，前記アないしキの記載及び本願の優先日における技術常識を考慮しつつ，引用例に記載された技術事項について検討する。 ａ．引用例の発明の名称及び前記アの【０００１】より，引用例は，「パケットを中継するコンピュータ」における「代理応答方法」に関するものである。 ここで，「パケットを中継するコンピュータ」とは，前記イの【００１７】及び【００１９】より，「システム」の「中継サーバ」のことであることは明らかである。 また，前記アの【０００８】より，前記「代理応答方法」は，正確な課金情報の取得を目的とするものである。 さらに，前記アの【０００３】より，前記「中継サーバ」は，「アクセス・サーバ」を介して受信したユーザからの要求を，当該ユーザに対してサービスを行う企業，すなわち，ＩＳＰ（インターネット・サービス・プロバイダ）のＲＡＤＩＵＳサーバ（認証，課金，接続制御を行うサーバ）に振り分けるものである。そうすると，前記「正確な課金情報」における「課金」は，ＩＳＰすなわちインターネット・サービス・プロバイダによって提供されるサービスに対するものであり，当該「正確な課金情報」を取得する主体は，「ＲＡＤＩＵＳサーバ」であるといえる。そして，「インターネット・サービス・プロバイダによって提供されるサービス」は，前記ウの【００２４】の記載「アクセス・サーバＡ（３）は，中継サーバ５から課金レスポンスのパケットを受信する。ここまでの処理でユーザ端末７は通信を開始することができるようになる（ステップ（１２））。すなわち，例えばインターネットへのアクセスが可能となる。」及び本願の優先日における技術常識を参酌すれば，「ユーザをインターネットに接続するサービス」であることは明らかである。 よって，引用例には，「インターネット・サービス・プロバイダ（ＩＳＰ）によって提供される，ユーザをインターネットに接続するサービスに対する正確な課金情報をＲＡＤＩＵＳサーバが取得するための，システムの中継サーバにおける代理応答方法」が記載されているといえる。 なお，前記エの【００３１】より，「代理応答」とは，直接的には，「課金サーバ」がダウンし，「課金レスポンス」が送られないときに，当該「課金サーバ」に代わって「代理で課金レスポンスのパケットをアクセス・サーバに返信する」ことであるが，それだけでは，前記「正確な課金情報の取得」という目的を実現し得ないから，それ以降の処理も含まれると解される。 ｂ．前記「システム」の構成に関し，前記イの【００１７】及び【００１８】並びに前記カ（図１）より，前記「システム」は，インターネットに接続する「ＩＰネットワーク」，前記「ＩＰネットワーク」に接続する「アクセス・サーバ」，前記「ＩＰネットワーク」に接続する「中継サーバ」及び前記「中継サーバ」に接続する，各ＩＳＰの「ＲＡＤＩＵＳサーバ」とで構成され，前記「ＲＡＤＩＵＳサーバ」は，「課金サーバ」と「認証サーバ」とで構成され，さらに，対応するＩＳＰのユーザの課金情報を蓄積する「課金ＤＢ」と，対応するＩＳＰのユーザの認証情報を格納する「認証ＤＢ」とを備えている。また，前記イの【００１８】の記載「バックアップや処理負荷分散のために多くの課金サーバや認証サーバを一つの企業が用意する場合もある。」，前記オの【００４４】の記載「企業Ａに属する課金サーバのうち稼動している課金サーバ」及び前記オの【００４５】の記載「上で述べたようにグループ内に複数の課金サーバが存在する場合もある」より，各ＩＳＰの「ＲＡＤＩＵＳサーバ」に「複数の課金サーバ」が存在する場合を含んでいる。 よって，引用例には，「前記システムは，インターネットに接続するＩＰネットワーク，前記ＩＰネットワークに接続するアクセス・サーバ，前記ＩＰネットワークに接続する中継サーバ及び前記中継サーバに接続する，各ＩＳＰのＲＡＤＩＵＳサーバとで構成され，前記ＲＡＤＩＵＳサーバは，複数の課金サーバと認証サーバとで構成され，さらに，対応するＩＳＰのユーザの課金情報を蓄積する課金ＤＢと，対応するＩＳＰのユーザの認証情報を格納する認証ＤＢと」を備えることが記載されているといえる。 ｃ．前記「システム」における「代理応答方法」の処理に関し，前記ウの【００２１】，【００２３】及び前記エの【００３０】並びに前記キ（図５）より，ユーザからのログイン要求に基づいて，「中継サーバ」が「アクセス・サーバ」から「開始」を表す「課金リクエスト」のパケットを受信することが記載され，この処理を「受信するステップ」と称することは任意である。また，前記ウの【００２３】より，「課金リクエスト」に対応する英語は，「Accounting-Request」である。 以上より，引用例には，「前記中継サーバにおいて，ユーザからのログイン要求に基づいて，前記アクセス・サーバから「開始」を表す課金リクエスト（Accounting-Request）のパケットを受信するステップ」が記載されているといえる。 ｄ．前記ウの【００２３】及び前記エの【００３０】より，「中継サーバ」は，「開始」を表す「課金リクエスト」のパケットを受信すると，これを一端記憶装置に格納し，当該パケットに含まれるユーザ識別情報を元に転送先のＲＡＤＩＵＳサーバを特定して，当該パケットの送信先を変更して，当該パケットを，課金サーバに送信している。ここで，パケットの送信先が，「中継サーバ」から「課金サーバ」に変更されることは自明であり、この処理を「変更するステップ」と称することは任意である。また，前記オの【００４４】の記載「いずれかの課金サーバを選択する」及び【００４５】の記載「グループ内の課金サーバを順番に選択して」より，「複数の課金サーバ」のいずれか一つを選択し，選択した課金サーバを変更後の送信先としていることは自明であり、この処理を「送信するステップ」と称することは任意である。 よって，引用例には，「前記中継サーバが，前記課金リクエストのパケットの送信先を，前記中継サーバから，前記複数の課金サーバから選択されたいずれか１つの課金サーバに変更するステップ」と，「前記中継サーバが，送信先を変更した前記課金リクエストのパケットを，前記１つの課金サーバに送信するステップ」が記載されているといえる。 ｅ．前記エの【００３１】には，「中継サーバ」が，「課金サーバ」（課金サーバ１３ａ）がダウンしていることにより「課金サーバ」から所定期間内に「課金レスポンス」のパケットを受信しない場合に，「課金リクエスト」のパケットを格納部に格納し，代理で「課金レスポンス」のパケットを「アクセス・サーバ」に送信することが記載されている。また，前記オの【００４６】には，「課金サーバ」のステータスとして，稼働（ｕｐ）とダウン（ｄｏｗｎ）を記憶装置に管理することが記載され，さらに，「なお，課金レスポンスを受信する前に何台かの課金サーバに課金リクエストを送信して応答が得られなかった場合には，当該応答が得られなかった課金サーバについてのステータスを変更する必要がある場合もある。もし，ステータスが稼動（ｕｐ）を表している場合には，ダウン（ｄｏｗｎ）に変更する。」との記載から，「中継サーバ」は，所定期間内に「課金レスポンス」のパケットを受信しなかった場合には，「課金サーバ」が「ダウン」の状態であると判断していると解される。そして，この処理を「判断するステップ」と称することは任意である。 よって，引用例には，「中継サーバが，前記１つの課金サーバから所定時間内に課金レスポンスのパケットを受信しない場合に，当該１つの課金サーバがダウンしていると判断するステップ」が記載されているといえる。 ｆ．前記エの【００３２】には，「中継サーバ」が，所定の周期又は任意のタイミングで，格納部に格納された「課金リクエスト」のパケットを読み出して，課金サーバ１３ａに送信することが記載されている。すなわち，「中継サーバ」は，「課金リクエスト」のパケットを「課金サーバ」に「再送信」しているといえる。 ｇ．また，前記イの【００１９】には，「中継サーバ」が「代理応答処理部」を備えることが記載され，前記エの【００４５】には，代替的な実施例として，「代理応答処理部」が，１つの「課金サーバ」から所定期間内に「課金レスポンス」を受信しない場合には，他の「課金サーバ」に「課金リクエスト」のパケットを送信してもよいことが記載されている。 そうすると，前記ｅ．及びｆ．を参酌すれば，引用例には，「中継サーバが，代理で課金レスポンスのパケットを前記アクセス・サーバに送信とともに，前記課金リクエストのパケットを，前記１つの課金サーバに再送信するステップ，または，他の課金サーバに課金リクエストのパケットを送信するステップ」が記載されているといえる。 ｈ．前記ウの【００２５】及び【００２６】より，引用例には，ユーザからのログオフ要求に基づいて，「中継サーバ」が，「終了」を表す「課金リクエスト」のパケットを「アクセス・サーバ」から受信し，当該パケットを（送信先を変更するなどして）「課金サーバ」に送信することが記載されており、この処理を「送信するステップ」と称することは任意である。 よって，引用例には，「中継サーバが，ユーザからのログオフ要求に基づいて，「終了」を表す課金リクエストのパケットをアクセス・サーバから受信し，これを前記課金サーバに送信するステップ」が記載されているといえる。 ｉ．前記イの【００２４】，【００２６】，前記ウの【００３３】より，「課金サーバ」は，「開始」を表す「課金リクエスト」のパケットを受信すると，課金開始を認識し，課金開始に関する情報を課金ＤＢに登録し，「終了」を表す「課金リクエスト」のパケットを受信すると，課金終了を認識し，課金終了に関する情報を課金ＤＢに登録するものである。そして，前記ｂ．より，「課金ＤＢ」は，ユーザの課金情報を蓄積するものである。 よって，引用例には，「前記課金サーバは，「開始」を表す課金リクエストのパケットを受信すると，課金開始を認識し，課金開始に関する課金情報を課金ＤＢに登録し，「終了」を表す課金リクエストのパケットを受信すると，課金終了を認識し，課金終了に関する課金情報を課金ＤＢに登録する」ことが記載されているといえる。 上記アないしキ及びａ．ないしｉ．の検討から，引用例には，以下の発明（以下，「引用発明１」という。）が記載されていると認める。 （引用発明１） 「　インターネット・サービス・プロバイダ（ＩＳＰ）によって提供される，ユーザをインターネットに接続するサービスに対する正確な課金情報をＲＡＤＩＵＳサーバが取得するための，システムの中継サーバにおける代理応答方法であって， 前記システムは，インターネットに接続するＩＰネットワーク，前記ＩＰネットワークに接続するアクセス・サーバ，前記ＩＰネットワークに接続する前記中継サーバ及び前記中継サーバに接続する，各ＩＳＰの前記ＲＡＤＩＵＳサーバとで構成され，前記ＲＡＤＩＵＳサーバは，複数の課金サーバと認証サーバとで構成され，さらに，対応するＩＳＰのユーザの課金情報を蓄積する課金ＤＢと，対応するＩＳＰのユーザの認証情報を格納する認証ＤＢとを備え 前記中継サーバにおいて，ユーザからのログイン要求に基づいて，前記アクセス・サーバから「開始」を表す課金リクエスト（Accounting-Request）のパケットを受信するステップと， 前記中継サーバが，前記課金リクエストのパケットの送信先を，前記中継サーバから，前記複数の課金サーバから選択されたいずれか１つの課金サーバに変更するステップと， 前記中継サーバが，送信先を変更した前記課金リクエストのパケットを，前記１つの課金サーバに送信するステップと， 中継サーバが，前記１つの課金サーバから所定時間内に課金レスポンスのパケットを受信しない場合に，当該１つの課金サーバがダウンしていると判断するステップと， 中継サーバが，代理で課金レスポンスのパケットを前記アクセス・サーバに送信するとともに，前記課金リクエストのパケットを，前記１つの課金サーバに再送信するステップ，または，他の課金サーバに課金リクエストのパケットを送信するステップと， 中継サーバが，ユーザからのログオフ要求に基づいて，「終了」を表す課金リクエストのパケットをアクセス・サーバから受信し，これを前記課金サーバに送信するステップと，を含み， 前記課金サーバは，「開始」を表す課金リクエストのパケットを受信すると，課金開始を認識し，課金開始に関する課金情報を課金ＤＢに登録し，「終了」を表す課金リクエストのパケットを受信すると，課金終了を認識し，課金終了に関する課金情報を課金ＤＢに登録する 方法。」 ２　引用例２について 原査定の拒絶の理由に引用された特表２０１１－５２１３３４号公報（以下，「引用例２」という。）には，「ダイアメータアプリケーションに基づいて，エンドツーエンド過負荷を制御するための方法およびネットワーク要素」（発明の名称）に関して，図面とともに以下の事項が記載されている。 ク　「【０００１】 本発明は，通信分野に関し，より詳細には，ダイアメータ（Ｄｉａｍｅｔｅｒ）アプリケーションに関するエンドツーエンド過負荷を制御するための方法，およびその方法を実装するためのネットワーク要素に関する。 【背景技術】 【０００２】 ＲＦＣ３５８８において画定されるダイアメータベースプロトコルは，ネットワークアクセスサービスまたはＩＰモビリティなどのアプリケーションに関する認証，許可および課金（ＡＡＡ）フレームワークを提供することが意図される。現在のダイアメータ標準文書は，すべてのダイアメータアプリケーションによって使用されることになるメッセージフォーマット，トランスポート，誤り報告，課金，およびセキュリティサービスを指定する。プロトコル要素は，いくつかのコマンドおよびＡＶＰ（属性値対）からなり，クライアント，プロキシ，およびサーバの間で認証，許可および課金情報を通信することが可能である。しかし，クライアント，プロキシ，またはサーバのうちのいずれかは，自発的にセッション要求を送信することが可能であり，相手側は応答を提示することになり，したがって，このプロトコルは，ピア間エンティティプロトコル（ｉｎｔｅｒ－ｐｅｅｒ　ｅｎｔｉｔｙ　ｐｒｏｔｏｃｏｌ）とも呼ばれる。コマンドコード，ＡＶＰ値，およびＡＶＰクラスは，アプリケーション要件およびアプリケーション規則に従って拡張されることが可能である。」（第３ページ） ケ　「【０００４】 ダイアメータは比較的新しいプロトコルであるため，エンドツーエンドダイアメータアプリケーションの過負荷制御に関する既存の方法はまだ存在しない。過負荷制御は，容量，パフォーマンス，および信頼性に関する，製品の主な機能性のうちの１つであるため，これはダイアメータプロトコルの大きな弱点である。」（第３ページ） コ　「【００１６】 図１は，ダイアメータ応答メッセージを経由して，ダイアメータ過負荷制御を開始する例を示す。この例では，関与するエンティティは，アプリケーションＡおよびアプリケーションＢであり，アプリケーションＡは，ダイアメータサーバであってよく，アプリケーションＢは，ダイアメータクライアントであってよく，またはアプリケーションＡは，ダイアメータクライアントであってよく，アプリケーションＢは，ダイアメータサーバであってもよい。サーバおよびクライアントのどちらも，自発的に過負荷制御要求を開始する可能性を有する。加えて，「中間ノード」と呼ばれる，１つまたは複数のプロキシ／二次ノードがアプリケーションＡとアプリケーションＢの間に存在し得る。これらの中間ノードは，過負荷制御に参加せずに，過負荷要求メッセージまたは過負荷応答メッセージをトランスペアレントに転送することだけが必要である。図１において，ステップ１０１に示すように，アプリケーションＡはＡＡＲ（認証，許可要求）をアプリケーションＢに送信し，中間ノードはＡＡＲ要求をトランスペアレントに転送すると仮定する。ステップ１０２において，アプリケーションＢは，例えば，重負荷により，自らがＡＡＲメッセージを処理することができないことを見出し，次いで，ステップ１０３において，アプリケーションＢは，アプリケーションＡに返信される状態にある応答ＡＡＡメッセージ内に過負荷ＡＶＰを記入し，結果コードＡＶＰの値を「トゥービジー（ｔｏｏ　ｂｕｓｙ）」に設定する。ステップ１０４において，アプリケーションＢは，応答ＡＡＡメッセージをアプリケーションＡに送信し，同様に，中間ノードは，過負荷制御に参加せずに，このメッセージをアプリケーションＡにトランスペアレントに転送する。最終的に，ステップ１０５に示すように，アプリケーションＡが応答ＡＡＡメッセージを受け取るとき，アプリケーションＡは，そのメッセージ内に過負荷ＡＶＰを発見し，過負荷ＡＶＰの値に従って，対応する処置を取る。」（第５ページ） 以下，前記クないしコの記載及び本願の優先日における技術常識を考慮しつつ，引用例２に記載された技術事項について検討する。 ｊ．前記クの【０００１】及びケより，引用例２は，過負荷制御方法に関するものである。 また，前記クの【０００２】の「…ダイアメータプロトコルは，… 認証，認可および課金（ＡＡＡ）フレームワークを提供することが意図される。現在のダイアメータ標準文書は，すべてのダイアメータアプリケーションによって使用されることになる…，課金，およびセキュリティサービスを指定する。プロトコル要素は，いくつかのコマンドおよびＡＶＰ（属性値対）からなり，クライアント，プロキシ，およびサーバの間で認証，許可および課金情報を通信することが可能である。」より，引用例２は，「課金」に関する処理を対象とする態様を含んでいる。 ｋ．前記コより，クライアント（アプリケーションＡ）が，ＡＡＲ（認証，認可要求）メッセージをサーバ（アプリケーションＢ）に送信し，サーバが，過負荷により前記ＡＡＲメッセージを処理することができない場合には，過負荷（ｔｏｏ　ｂｕｓｙ）を示す応答ＡＡＡメッセージをクライアントに送信し，クライアントは，受信した応答メッセージが過負荷を示している場合には，対応する処置を取ることが記載されている。 そして，前記ＡＡＲメッセージは，処理を要求する「要求メッセージ」といえ，前記応答ＡＡＡメッセージは，前記要求メッセージに対する「応答メッセージ」であるといえる。 前記クないしコ及びｊ．及びｋ．の検討から，引用例２には，以下の発明（以下，「引用発明２」という。）が記載されていると認める。 「　クライントが，サーバに対して，課金に関する処理を要求する要求メッセージを送信し， 前記サーバが，受信した要求メッセージを処理することができない場合に，過負荷を示す応答メッセージを前記クライアントに送信し， 前記クライアントは，受信した応答メッセージが過負荷を示している場合には，対応する処理を取る， 過負荷制御方法。」 ３．周知例について 本願の優先日前に頒布された刊行物である国際公開第２０１１／０４８９３３号（以下，「周知例」という。）には，「ネットワーク通信システム，サーバシステム及び端末」(発明の名称）に関して，図面とともに以下の事項が記載されている。 サ　「【０００１】 本発明は，ネットワークに接続されたサーバと，前記ネットワークに接続され，前記サーバに対して所定の接続権限が付与された端末とを備えたネットワーク通信システム，サーバシステム及び前記端末に関する。」（第１ページ） シ　「【００３１】 図６は，端末１のＣＰＵによって実行される認証要求処理の手順の一例を示すフローチャートである。まず，端末１は，ＵＳＢメモリ４がポートＰに差し込まれると，ＵＳＢメモリ４の装着を検出して認証要求指示の発行を行う（ステップＳ１）。認証要求指示が発せられると，端末１の接続先となるサーバ５０１の設定順を示すパラメータｉが，ｉ＝１に設定される（ステップＳ３）。次いで，認証要求を行うパケットのヘッダ領域に，ＵＳＢメモリ４の接続先リスト記憶部４３に記憶されている，接続先の順番を示すリストの１番目のアドレスが設定される（ステップＳ５）。そして，認証要求信号がアドレス設定されたサーバ５０１に出力される（ステップＳ７）。 【００３２】 次いで，内部タイマにより計時される所所定時間内に応答信号が返信されてきたか否かが判断される（ステップＳ９）。サーバ５０１は，アタック負荷が過大な状態にある場合 ，端末１からの認証要求に対する応答処理を行うことができないと考えられ，すなわち所定期間内に応答信号の作成もできず，返信する処理も不可となる。 【００３３】 応答信号が認証成功を示す信号であれば（ステップＳ１１），この認証成功信号を受けて，サービス提供要求のための特定ＡＰによるファイルの作成が許可され，作成されたファイル（あるいは予め作成されていたファイル）は，サービス提供サーバ８に向けて，すなわち本実施形態では，サービス提供サーバ８を経由させるべく出力される（ステップＳ１３）。他の方法として，ファイルの送信は，サービス提供サーバ８と相手先端末１とにパラレルで行ってもよい。 【００３４】 一方，ステップＳ９で，所定時間内に応答信号が受信できなかった場合，応答なし回数をカウントアップすると共に，同一信号の再送が実行される（ステップＳ１５）。応答信号とは，サーバ５０１が認証要求に応答した場合に返信するであろう，例えば認証成功，認証失敗を示す信号である。この再送に対しても同様に所定時間内に応答信号が返信されてきたか否かが判断され（ステップＳ１７），応答信号が受信できた場合には，ステップＳ１１に移行する。一方，所定期間内に応答信号が受信できなかった場合，再送回数カウンタがカウントアップされると共に再送動作が所定回数に達したか否かがカウント値から判断される（ステップＳ１９）。再送回数を示すカウント値が所定回数未満であれば，ステップＳ１５に戻り，再送動作が繰り返される。一方，再送回数を示すカウント値が所定回数に達すると，ｉ＝ｉ＋１によって接続先の変更処理が実行され（ステップＳ２１），さらに，ｉ＝Ｉか否かが判断される（ステップＳ２３）。この場合，アタックが継続しており，当該サーバ５０１では接続が不可能と判断する。なお，パラメータＩは，接続先リストの個数であって予め設定されており，例えば，サーバ５０１の変更を４台まで許容する態様では，Ｉ＝５となる。あるいは，全てのサーバ５０１が接続先リストに設定される態様でもよい。接続先順は，接続先リスト記憶部４３に登録する際に，図外の登録用処理器（すなわち会員登録時に，各会員に付与されるＵＳＢメモリ４に所要の情報を登録するための機器）のコンピュータが無作為に設定するものでもよい。 【００３５】 そして，ｉ＜Ｉであれば，ステップＳ５に戻って，次のサーバ５０１に切り替わって同様な認証要求処理が繰り返される。一方，ｉ＝Ｉであると，認証要求のための受付自体が不可であったとして，本フローを終了する。 【００３６】 なお，ステップＳ１１で，認証成功を示す信号でない場合，すなわち認証失敗を示す信号である場合，例えば表示部１４に対して，認証要求のための再設定の指示が報知される（ステップＳ２５）。例えば，ＵＳＢメモリ４のポートＰへの差し直し等の指示である。 【００３７】 なお，端末１は，サーバ５０１の変更を行う条件として，アタックによって認証要求に対する応答信号が返信できない程度に過負荷状態となった場合を提示したが，以下のようにしてもよい。すなわち，サーバ５０１が過負荷の状態に，例えばトラフィック，アタック数，アタック頻度等の１つ又は複数の諸情報を計測し，計測結果から，現状では端末１からの認証要求に応えられないと（対象となる要素の所定の閾値と比較するなどして）判断した場合に，応答不可の信号を端末１に発する態様としてもよい。この場合，端末１は，応答不可の信号を受けると，ステップＳ１５のような所定回の再送判断手順を設けることなく，直ちに，次の接続先に切り替えるようにすればよい。」（第１１－１３ページ） 以下，前記サ及びシの記載及び本願の優先日における技術常識を考慮しつつ，周知例に記載された技術事項について検討する。 ｌ．前記サより，周知例は，端末（クライアント）とサーバとの間の通信に関するものである。 ｍ．前記シの【００３１】ないし【００３６】には，端末が，サーバに認証要求を送信し，サーバから所定時間内に応答信号を受信しなかった場合には，前記サーバに対する再送信又は変更したサーバに対して再送信することが記載されている。 ｎ．前記シの【００３７】には，前記【００３１】ないし【００３６】に記載された手法，すなわち，認証要求に対する応答信号を送信できない程度に過負荷となる前に，サーバが過負荷の状態，すなわち，端末からの認証要求に応えられないと判断した場合に，応答不可の信号を端末に送信し，端末が，変更したサーバに対して再送信してもよいことが記載されている。 前記サ及びシ並びに（ク）ないし（セ）の検討から，周知例には，以下の事項（以下，「周知事項」という。）が記載されていると認める。 「　クライアントがサーバに要求を送信し， サーバから，処理時間内に応答を受信しなかった場合に再送信等の処理を行うことに替えて， サーバから，前記要求に応えられないことを示す応答不可の信号を受信した場合に再送信等の処理を行ってもよいこと。」 第３　対比・判断 １　対比 本願発明と引用発明１とを対比する。 （ア）引用発明１において，「課金サーバ」は，「開始」を表す課金リクエストのパケットを受信して，課金開始に関する課金情報を課金ＤＢに登録し，「終了」を表す課金リクエストのパケットを受信して，課金終了に関する課金情報を課金ＤＢに登録しており，また，「開始」を表す課金リクエストのパケットは，「ユーザのログイン要求」に基づいて受信され，「終了」を表す課金リクエストのパケットは，「ユーザのログオフ要求」に基づいて受信されるものである。また，「課金情報」は，「ユーザをインターネットに接続するサービス」に対するものであるから，「ユーザのログオン要求」は，インターネットに接続するサービス提供の開始を要求するものであり，「ユーザのログオフ要求」は，インターネットに接続するサービス提供の終了を要求するものと解される。さらに，本願の優先日において，インターネットに対する接続サービスの提供開始から提供終了までの通信時間，通信に使用したパケット量等に応じて課金を行うことは技術常識であったことを参酌すれば，引用発明１において，「課金サーバ」は，課金ＤＢに登録した，課金開始に関する課金情報と課金終了に関する課金情報とに基づいてユーザに対する課金処理を行うことは自明なことである。そして，その課金処理は，言い替えると、前記「サービス」に対する「明細を明らかにする」といえる。 （イ）引用発明１において，「システム」は，「インターネットに接続するＩＰネットワーク，前記ＩＰネットワークに接続するアクセス・サーバ，前記ＩＰネットワークに接続する前記中継サーバ及び前記中継サーバに接続する，各ＩＳＰの前記ＲＡＤＩＵＳサーバ」とで構成されているから，ユーザが，「インターネットに接続するサービス」の提供を受けるためには，「アクセス・サーバ」及び「ＩＰネットワーク」を介して「インターネット」にアクセスする必要があることは明らかである。そして，「中継サーバ」は，「ユーザからのログイン要求」，すなわち，前記「サービス」の開始要求に応じて，「アクセス・サーバ」から「開始」を表す「課金リクエスト」を受信し，これを「ＩＳＰ」の「ＲＡＤＩＵＳサーバ」（課金サーバ）に送信していることから，「アクセス・サーバ」，「ＩＰネットワーク」「中継サーバ」及び「ＩＳＰ」の「ＲＡＤＩＵＳサーバ」は互いに提携したものといえる。そうすると，「アクセス・サーバ」，「ＩＰネットワーク」，「中継サーバ」及び「ＲＡＤＩＵＳサーバ」は，「ＩＳＰ」側のネットワーク，すなわち，「サービス・プロバイダ・ネットワーク」を構成しているといえ，言い替えると，「アクセス・サーバ」等は，「サービス・プロバイダ・ネットワーク」の「ネットワーク要素」といえる。 そうすると，引用発明１における「インターネット・サービス・プロバイダ（ＩＳＰ）によって提供される，ユーザをインターネットに接続するサービス」は，本願発明における「サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービス」に相当する。 また，前記（ア）を参酌すれば，引用発明１における「課金サーバ」は，前記「サービス」の「明細を明らかにする」ものであり，「課金サーバ」は，「ＲＡＤＩＵＳサーバ」に含まれ，かつ，当該「ＲＡＤＩＵＳサーバ」は，「課金サーバ」と「認証サーバ」とで構成される複合的な「システム」といい得るものである。 そうすると，引用発明１の「ＲＡＤＩＵＳサーバ」は，本願発明の「サービスの明細を明らかにする課金システム」に相当する。 そして，前記（ア）を参酌すれば，引用発明１における「代理応答方法」は，「中継サーバ」が，「課金リクエスト」を「ＲＡＤＩＳＵサーバ」の「課金サーバ」に送信することにより，「ＲＡＤＩＵＳサーバ」による「正確な課金情報」の取得を実現していることは明らかであるから，実質的に，「中継サーバ」が，「ＲＡＤＩＵＳサーバ」を使用するための方法を含むものである。 以上より，引用発明１の「インターネット・サービス・プロバイダ（ＩＳＰ）によって提供される，ユーザをインターネットに接続するサービスに対する正確な課金情報をＲＡＤＩＵＳサーバが取得するための，システムの中継サーバにおける代理応答方法」は，本願発明の「サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムを使用するための方法」を含むものである。 （ウ）引用発明１における「中継サーバ」は，受信した「課金リクエスト」のパケットを，「複数の課金サーバ」のうちの「１つの課金サーバ」に選択的にルーティングしているといえる。また，前記（イ）を参酌すれば，「中継サーバ」と「ＲＡＤＩＵＳサーバ」は連携したものであるから，「中継サーバ」は，「ＲＡＤＩＵＳサーバ」すなわち「課金システム」におけるものといい得るものである。 そうすると，引用発明１における「中継サーバ」と，本願発明における「課金システムにおけるルータ」とは，「課金システムにおけるルータ装置」である点において共通する。 （エ）引用発明１における「課金リクエスト（Accounting-Request）」は，括弧内（英語）を参酌すれば，「アカウンティング要求」といい得るものである。 よって，引用発明１における「「開始」を表す課金リクエスト（Accounting-Request）のパケット」は，本願発明における「アカウンティング要求」に含まれる。 そうすると，前記（ウ）を参酌すれば，引用発明１と本願発明とは，「課金システムにおけるルータ装置において，サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するステップ」を有する点において共通する。 （オ）前記（ア）を参酌すれば，引用発明１においては，「課金サーバ」は，課金ＤＢに登録した，課金開始に関する課金情報と課金終了に関する課金情報とに基づいて，インターネットに対する接続サービスの提供開始（「開始」を表す課金リクエストのパケットの受信）から提供終了（「終了」を表す課金リクエストのパケットの受信）までの通信に対して，課金処理を行うことは明らかである。 そして，インターネットに対する接続の開始から終了までの通信を「通信セッション」と称することは任意であるから，前記「課金リクエスト」は，「通信セッション」に関連して，インターネット接続サービス，すなわち，「前記サービス・プロバイダ・ネットワークの前記ネットワーク要素によって提供されるサービス」に関連付けられていることは自明なことである。 よって，引用発明１は，本願発明における「前記アカウンティング要求は，通信セッションに関連して，前記サービス・プロバイダ・ネットワークにおける前記ネットワーク要素によって提供されるサービスに関連づけられ，」に相当する構成を備えているといえる。 （カ）前記（ア）を参酌すれば，「課金サーバ」は，「課金リクエスト」を処理する機能を有する，いわば「課金処理サーバ」である点において，本願発明における「課金収集機能サーバ」と共通している。 また，前記「課金リクエスト」が，「通信セッション」に関連したものであることは前述したとおりである。また，引用発明１において，前記「課金リクエスト」が，少なくとも１つの「通信セッション」に関連し，少なくとも「アクセス・サーバ」から受信されることは自明である。 よって，前記（ウ）を参酌すれば，引用発明１と本願発明とは，「前記課金システムは，１つの通信セッションに関連して，前記サービス・プロバイダ・ネットワークの１つのネットワーク要素からのアカウンティング要求を処理するための，前記ルータ装置に関連する複数の課金処理サーバを含む」点において共通する。 （キ）前記（ウ）及び（エ）を参酌すれば，引用発明１における「前記課金リクエストのパケットの送信先を…変更するステップ」と，本願発明における「修正されたアカウンティング要求を形成するように，前記ルータにおいて前記受信されたアカウンティング要求を修正するステップ」とは，「修正されたアカウンティング要求を形成するように，前記ルータ装置において前記受信されたアカウンティング要求を修正するステップ」である点において共通する。 （ク）本願発明における「前記複数の課金制御機能サーバ」は，前記されておらず，前後の文脈からして，「前記複数の課金収集機能サーバ」の誤記と解するのが合理的である。 前記（カ）を参酌すれば，引用発明１における「前記複数の課金サーバから選択されたいずれか１つの課金サーバ」の「複数の課金サーバ」及び「１つの課金サーバ」と，本願発明における「複数の課金制御機能サーバ」及び「第１の課金収集機能サーバ」とはそれぞれ，「複数の課金処理サーバ」及び「第１の課金処理サーバ」である点において共通する。 そうすると，前記（ウ）及び（キ）を参酌すれば，引用発明１における「前記中継サーバが，送信先を変更した前記課金リクエストのパケットを，前記１つの課金サーバに送信するステップ」と，本願発明における「前記ルータから，前記複数の課金制御機能サーバから選択される第１の課金収集機能サーバへ前記修正されたアカウンティング要求を送信するステップ」とは，「前記ルータ装置から，前記複数の課金処理サーバから選択される第１の課金処理サーバへ前記修正されたアカウンティング要求を送信するステップ」である点において共通する。 （ケ）引用発明１における「課金レスポンス」は，本願発明における「アカウンティング応答」に相当する。 引用発明１における「前記１つの課金サーバから所定時間内に課金レスポンスのパケットを受信しない場合に，当該１つの課金サーバがダウンしていると判断する」ことは，「課金レスポンス」（アカウンティング応答）の態様（処理時間内に受信しないこと）に応じて１つの課金サーバ（第１の課金処理サーバ）がダウンしていると判断することに他ならない。 また，本願発明における「前記第１の課金収集機能サーバが前記修正されたアカウンティング要求を処理することができなかったことを示すアカウンティング応答を，前記ルータにおいて前記第１の課金収集機能サーバから受信するステップ」において，「アカウンティング応答」の態様（アカウンティング要求を処理することができなかったことを示すものを受信したこと）によって，「第１の課金収集機能サーバ」（第１の課金処理サーバ）が，「修正されたアカウンティング要求を処理することができなかった」ことを判断していることは自明である。 そして，引用発明１における「ダウン」と，本願発明における「修正されたアカウンティング要求を処理することができなかった」こととは，「第１の課金処理サーバ」に「修正されたアカウンティング要求」を処理することができない不具合がある点において共通する。 そうすると，前記（ウ）を参酌すれば，引用発明１における「前記第１の課金収集機能サーバが前記修正されたアカウンティング要求を処理することができなかったことを示すアカウンティング応答を，前記ルータにおいて前記第１の課金収集機能サーバから受信するステップ」と，本願発明における「中継サーバが，前記１つの課金サーバから所定時間内に課金レスポンスのパケットを受信しない場合に，当該１つの課金サーバがダウンしていると判断するステップ」とは，「前記第１の課金処理サーバからのアカウンティング応答の態様に応じて，前記第１の課金処理サーバに，前記修正されたアカウンティング要求を処理することができない不具合があることを前記ルータ装置において判断するステップ」である点において共通するといえる。 （コ）引用発明１において，「他の課金サーバに課金リクエストのパケットを送信するステップ」において，送信先を，「他の課金サーバ」に変更してパケットを送信することは自明である。そして，そのように送信先を変更することを「改訂」と称し，「他の課金サーバ」を，「代替の」ものと称することは任意である。 そうすると，前記（ウ），（カ）及び（キ）を参酌すれば，引用発明１における「中継サーバが，代理で課金レスポンスのパケットを前記アクセス・サーバに送信するとともに，前記課金リクエストのパケットを，前記１つの課金サーバに再送信するステップ，または，他の課金サーバに課金リクエストのパケットを送信するステップ」と，本願発明における「前記ルータから前記第１の課金収集機能サーバへと前記修正されたアカウンティング要求を再送信するステップ，または改訂されたアカウンティング要求を形成するように，前記ルータにおいて前記修正されたアカウンティング要求を変更し，前記ルータから，前記複数の課金制御機能サーバから選択される代替の課金収集機能サーバへと前記改訂されたアカウンティング要求を送信するステップ」とは，「前記ルータ装置から前記第１の課金処理サーバへと前記修正されたアカウンティング要求を再送信するステップ，または改訂されたアカウンティング要求を形成するように，前記ルータ装置において前記修正されたアカウンティング要求を変更し，前記ルータ装置から，前記複数の課金処理サーバから選択される代替の課金処理サーバへと前記改訂されたアカウンティング要求を送信するステップ」である点において共通する。 ２　一致点・相違点 前記１の検討から，本願発明と引用発明１とは，以下の点で一致ないし相違している。 （１）一致点 「　サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムを使用するための方法であって， 課金システムにおけるルータ装置において，サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するステップであって，前記アカウンティング要求は，通信セッションに関連して，前記サービス・プロバイダ・ネットワークにおける前記ネットワーク要素によって提供されるサービスに関連づけられ，前記課金システムは，１つの通信セッションに関連して，前記サービス・プロバイダ・ネットワークの１つのネットワーク要素からのアカウンティング要求を処理するための，前記ルータ装置に関連する複数の課金処理サーバを含む，受信するステップと， 修正されたアカウンティング要求を形成するように，前記ルータ装置において前記受信されたアカウンティング要求を修正するステップと， 前記ルータ装置から，前記複数の課金処理サーバから選択される第１の課金処理サーバへ前記修正されたアカウンティング要求を送信するステップと， 前記第１の課金処理サーバからのアカウンティング応答の態様に応じて，前記第１の課金処理サーバに，前記修正されたアカウンティング要求を処理することができない不具合があることを判断するステップと， 前記ルータ装置から前記第１の課金処理サーバへと前記修正されたアカウンティング要求を再送信するステップ，または改訂されたアカウンティング要求を形成するように，前記ルータ装置において前記修正されたアカウンティング要求を変更し，前記ルータ装置から，前記複数の課金処理サーバから選択される代替の課金処理サーバへと前記改訂されたアカウンティング要求を送信するステップとを含む方法。」 （２）相違点 共通する「ルータ装置」及び「課金処理サーバ」に関し，本願発明においては，「第１の課金収集機能サーバ」は，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」を送信する機能を有し，「ルータ」が，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」を受信したことに基づいて，再送信等の処理をするのに対し，引用発明１においては，「課金サーバ」は，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」に相当するものを送信する機能を有さず，「中継装置」は，「所定時間内」に「課金レスポンス」を受信しない場合に，再送信等の処理をする点。 要するに，本願発明は，不具合を示す明示的な応答に基づいて再送信等を行うのに対し，引用発明１は，応答の不存在に基づいて再送信等を行う点。 ３　判断 上記相違点について検討する。 引用発明２にあるように， 「　クライントが，サーバに対して，課金に関する処理を要求する要求メッセージを送信し， 前記サーバが，受信した要求メッセージを処理することができない場合に，過負荷を示す応答メッセージを前記クライアントに送信し， 前記クライアントは，受信した応答メッセージが過負荷を示している場合には，対応する処理を取る， 過負荷制御方法。」 すなわち，サーバが，要求メッセージに対して，過負荷（不具合）を示す明示的な応答を送信する機能を有し，クライアントが，前記明示的な応答を受信したことに基づいて，対応する処理を取ることは，本願の優先日における公知技術である。 そして，引用発明１における「中継サーバ」は，「課金リクエスト」を「課金サーバ」に送信しているから，「課金サーバ」から見れば「クライアント」であるといえ，逆に，「中継サーバ」から見れば前記「課金サーバ」は「サーバ」であるといえる。また，引用発明１は，「機能サーバ」がダウン（不具合）である場合に，サーバからの応答の態様に応じて再送信等の処理すなわち対応する処理を取るものであるから，引用発明１と引用発明２とは，その前提となる構成及び課題を共通としている。 さらに，周知事項にあるように， 「　クライアントがサーバに要求を送信し， サーバから，処理時間内に応答を受信しなかった場合に再送信等の処理を行うことに替えて， サーバから，前記要求に応えられないことを示す応答不可の信号を受信した場合に再送信等の処理を行ってもよいこと。」 すなわち，応答の不存在に基づいて再送信等を行うことに替えて，不具合を示す明示的な応答に基づいて再送信等を行うことは，本願の優先日における周知技術である。 よって，当該周知技術を勘案すれば，引用発明１に引用発明２に係る公知技術を採用して，引用発明１における，応答の不存在に基づいて再送信等を行うこと，すなわち，「課金サーバ」が，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」に相当するものを送信する機能を有さず，「中継装置」は，「所定時間内」に「課金レスポンス」を受信しない場合に，再送信等の処理をすることに替えて，不具合を示す明示的な応答に基づいて再送信等を行うこと，すなわち，「課金サーバ」を，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」を送信する機能を有する「課金収集機能サーバ」とし，「中継装置」を，「アカウンティング要求を処理することができなかったことを示すアカウンティング応答」を受信したことに基づいて，再送信等の処理をする「ルータ」とすることは，当業者が容易に想到し得たことである。 そして，本願発明の作用効果も，引用発明１及び引用発明２並びに周知事項に基づいて当業者が予測し得る範囲のものであり，格別なものではない。 ４　請求人の主張 請求人は，審判請求書において， 「３．本願発明が特許されるべき理由 引用文献２では，「中継ノード」に関して，以下のように記載されています。 （…中略…） このように，引用文献２は，中間ノードが過負荷状態を判断することを明確に否定しています。中間ノードが過負荷状態を判断する引用文献１の発明に，引用文献２の手法を適用する動機付けはありません。 仮に，引用文献２の手法を引用文献１の発明に適用したとしても，課金サーバが，自らが課金リクエストを処理することができない場合，課金レスポンスに負荷状態を設定してアクセス・サーバに送信し，アクセス・サーバが，負荷状態に従って，課金リクエストの再送信，または他の課金サーバに課金リクエストを送信するような構成になるものと考えられます。 したがって，請求項１及び同様の技術的特徴を有する請求項６並びにこれらの従属項に係る発明は，引用文献１，２に記載された発明に基づいて当業者が容易に想到することができなかったものです。」 と主張している。 しかしながら，引用例２より抽出した技術事項は，クライアントとサーバとの間の通信に関する事項であって，クライアントとサーバとの間の通信をトランスペアレントに仲介する「中間ノード」については抽出していない。 また，引用例１における「中継ノード」は，「課金サーバ」を選択する機能（「前記中継サーバが，前記課金リクエストのパケットの送信先を，前記中継サーバから，前記複数の課金サーバから選択されたいずれか１つの課金サーバに変更するステップ」），「課金サーバ」がダウンしていることを判断する機能（「中継サーバが，前記１つの課金サーバから所定時間内に課金レスポンスのパケットを受信しない場合に，当該１つの課金サーバがダウンしていると判断するステップ」）及び，前記判断に基づいた代理応答機能（「中継サーバが，代理で課金レスポンスのパケットを前記アクセス・サーバに送信する」）等の種々の機能を備えているから，「アクセス・サーバ」と「課金サーバ」との間の通信をトランスペアレントに仲介するものではないから，引用発明１における「中継サーバ」に対応する事項として，引用例２から前記「中間ノード」についての技術事項を抽出しなければならない理由が存在しない。 また，引用発明１における「アクセス・サーバ」は，そもそも課金リクエストの再送信等の処理を行うものではないから，引用発明１に引用発明２を適用した場合に，「アクセス・サーバが，負荷状態に従って，課金リクエストの再送信，または他の課金サーバに課金リクエストを送信するような構成になる」ことはないことが明らかである。 そして，前記「３　判断」の項で述べたように，引用発明１と引用発明２とは，その前提となる構成及び課題を共通とし，さらに，周知事項にあるように，応答の不存在に基づいて再送信等を行うことに替えて，不具合を示す明示的な応答に基づいて再送信等を行うことは本願の優先日における周知技術であるから，引用発明１の構成に替えて，引用発明２の構成を採用することに技術的な阻害要因も認められない。 よって，上記請求人の主張は採用しない。 第４　むすび 以上のとおり，本願発明は，当業者が引用例１及び引用例２に記載された発明に基づいて周知技術を参酌することにより当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 したがって，本願は，その余の請求項に論及するまでもなく拒絶すべきものである。 よって，結論のとおり審決する。