• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部無効 特36条6項1、2号及び3号 請求の範囲の記載不備  G06F
審判 全部無効 2項進歩性  G06F
審判 全部無効 特36条4項詳細な説明の記載不備  G06F
審判 全部無効 特120条の4、2項訂正請求(平成8年1月1日以降)  G06F
管理番号 1226791
審判番号 無効2007-800243  
総通号数 133 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2011-01-28 
種別 無効の審決 
審判請求日 2007-11-01 
確定日 2010-09-30 
訂正明細書 有 
事件の表示 上記当事者間の特許第3762882号「インターネットサーバーのアクセス管理およびモニタシステム」の特許無効審判事件についてされた平成20年 6月26日付け審決に対し、知的財産高等裁判所において審決取消の判決(平成20年(行ケ)第10297号平成21年11月 5日判決言渡)があったので、さらに審理のうえ、次のとおり審決する。 
結論 訂正を認める。 本件審判の請求は、成り立たない。 審判費用は、請求人の負担とする。 
理由 第1 手続の経緯
本件特許第3762882号は,平成8年6月3日(優先権主張外国庁受理1995年6月7日,米国)を国際出願日とする特願平9-503084号の一部を平成13年7月9日に新たな特許出願としたものであって,平成18年1月20日に本件特許の設定登録がなされた。
その後,請求人株式会社NETPIAより平成19年11月1日に,本件特許の請求項1ないし7について無効とすることを求める本件無効審判の請求があった。これに対し,被請求人インターネットナンバー株式会社は,平成20年1月23日に訂正請求書及び審判事件答弁書を提出したところ,請求人は平成20年3月4日に審判事件弁駁書を提出した。さらにその後,平成20年5月20日に口頭審理が行われ,口頭審理調書によれば審判請求人は,審判請求書の無効理由のうち,特許法第29条第1項第3号の主張は取下げ,被請求人はこれに同意し,なお,当該主張における甲第1号証及び甲第2号証の記載に係る主張は,特許法第29条第2項の主張に援用するとされた。そして,平成20年6月26日に「訂正を認める。特許第3762882号の請求項1-7に係る発明についての特許を無効とする。」との審決がなされた。
これに対して,訂正後の発明について特許法第29条第2項の規定に違反して無効とすべきであるとした審決の判断の誤りを取消理由として審決取消の訴が被請求人によりなされ,知的財産高等裁判所において平成20年(行ケ)第10297号として審理され,平成21年11月5日に「特許庁が無効2007-800243号事件について平成20年6月26日にした審決を取り消す。」との判決が言い渡された。
請求人は,上記判決を不服として最高裁判所に上告及び上告受理の申立をしたが,最高裁判所により平成22年3月11日に「1 本件上告を棄却する。2 本件を上告審として受理しない。3 上告費用及び申立費用は上告人兼申立人の負担とする。」との決定がなされて,上記判決は確定した。
その後,請求人より平成22年4月19日付けで上申書が提出された。

第2 訂正の適否
被請求人は平成20年1月23日に訂正請求書を提出して特許請求の範囲の減縮及び明りょうでない記載の釈明を目的として請求項1の訂正(以下,「本件訂正」という。)を求めた。

1.訂正の内容
(1)訂正事項a
請求項1において,「前記クライアントにおいて記述子を提供する段階と,」を「前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,」と訂正する。

(2)訂正事項b
請求項1において,「翻訳データベースを用いてURLにマッピングする段階と,」を「翻訳データベースを用いて前記URLにマッピングする段階と,」と訂正する。

(3)訂正事項c
請求項1において,「情報を要求させる段階と,」を「情報を自動的に要求させる段階と,」と訂正する。

2.被請求人の主張する訂正理由の概要
(1)訂正事項aについて
訂正事項aは,記述子に「単一の目標URLに対応する」という事項を追加するものであって,特許請求の範囲を減縮しつつ明りょうでない記載の釈明を目的とするものである。この追加事項は,明細書の段落【0043】,【0045】等の記載に基づくものである。
「目標URL」が「単一」であることについても,特許請求の範囲の記載上,「URL」には何ら「複数のURL」などの文言が付されておらず,用語の通常の用法として「URL」は単独のものであると解され,特許請求の範囲には「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階」,「ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,」,「前記クライアントに前記URLを用いて情報を要求させる段階と,」,「前記URLにより識別されたページを前記クライアント側で表示する段階…」という記載が存在し,「前記URLにより識別されたページ」が「前記クライアント側で表示」されるものであることを考慮すると,当然「前記URL」も単独であると解されるものである(仮に,複数の「URL」がマッピングされているとすれば,「前記URL」の中から特定の一つの「URL」を選択する過程を経なければ,「クライアント側」でページを表示することは不可能となってしまうにも関わらず,特許請求の範囲の記載上,何らURLを選別する過程は示されていない)。
したがって,上記の訂正は,特許法第134条の2第1項第1号の「特許請求の範囲の減縮」及び同項第3号の「明りょうでない記載の釈明」に該当し,同規定を充足する。これにより,上記の訂正は特許法第134条の2第5項で準用する同法第126条第3項,第4項を充足する。

(2)訂正事項bについて
上記の訂正は,請求項1において,「翻訳データベースを用いてURLにマッピングする段階と,」を「翻訳データベースを用いて前記URLにマッピングする段階と,」として,「URL」が上記訂正事項aに基づく「単一の目標URL」を指すものであることを明りようにするものであるから明りょうでない記載の釈明を目的とするものである。したがって,上記の訂正は,特許法第134条の2第1項第3号の「明りょうでない記載の釈明」に該当し,同規定を充足する。

(3)訂正事項cについて
上記の訂正は,請求項1において,「情報を要求させる段階と,」を「情報を自動的に要求させる段階と,」として「自動的に」という事項を追加するものであるから特許請求の範囲を減縮しつつ明りょうでない記載の釈明を目的とするものである。
この追加事項は,明細書の段落【0012】,【0029】,【0032】,【0045】等に基づくものである。したがって,上記の訂正は,特許法第134条の2第5項で準用する同法第126条第3項,第4項を充足する。

3.訂正請求に対する審判請求人の主張の概要
訂正事項aにおける「単一の目標URLに対応する」の構成は,本件明細書全文および図面中に記載のない事項であって直ちにその追加を認められるものではない。
「単一の」の語に関しては少なくとも本件明細書全文において一切記載のない新規な文言であるため,特許法第134条の2第5項で準用する同法第126条第3項を具備せず,本件訂正は認められるべきでない。
もっとも,本件特許発明における「マッピング」や「REDIRECTコマンド」がいずれも甲第1号証や甲第2号証の引用発明から明らかな単一のURLを処理するものであるとの技術常識に照らせば,自ずと本件発明における「URL」も単一のものと把握することができるが,上記訂正事項aが当初明細書の記載の範囲内として認められるとするならば,それは甲第1号証ないし甲第2号証の技術常識を参酌する結果であって,本件発明が甲第1号証記載の発明と同一,または甲第1号証と甲第2号証記載の発明から容易に想到できることを意味するに他ならない。

4.訂正請求に対する当審の判断
(1)訂正事項aについて
訂正事項aは請求項1において,「前記クライアントにおいて記述子を提供する段階と,」とあるのを「前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,」と訂正するものであるが,「記述子」と「目標URL」の関係について発明の詳細な説明には,以下のような記載がある。
(i)「一旦NUMBERがディレクトリサーバー602により受信されると,ディレクトリサーバーはデータベース604を用いて,NUMBERに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標URLにNUMBERを翻訳する。」(段落【0043】)
(ii)「メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。」(段落【0045】)
上記(i)(ii)の記載によれば,記述子に相当する「NUMBER」から目標URLを求めることが記載されている。これら(i),(ii)の記載から,クライアントにおいて提供される記述子は「目標URL」に対応したものであると認められる。
また,「記述子」と「(目標)URL」との対応関係について本件明細書には更に以下の記載がある。
(iii)「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と, 前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と, 前記クライアントに前記URLを用いて情報を要求させる段階と, 前記URLにより識別されたページを前記クライアント側で表示する段階」(請求項1)
(iv)「本発明の一構成では,商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている。これらの商業者サービスはSIDを用いて任意に保護され得る。好ましい実施形態では,図6に示されるように,ウェブブラウザクライアント601がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし,キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでNUMBERがユーザにより指定された電話番号,またはその他の識別子である,書式“http://directory.net/NUMBER”のURLを構成する。ブラウザは次いでこのURLにより指定されたドキュメントのGETを行い,ディレクトリサーバー602に連絡し,メッセージ1で要求されたNUMBERを送信する。」(段落【0041】)
(v)「メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。商業者サーバー603はメッセージ4におけるこの情報を返送する。」(段落【0045】)

これらの記載(iii)?(v)には記述子が複数のURLに対応することが記載されているわけではなく,仮に記述子が複数のURLに対応するとした場合には,「URLにより識別されたページを前記クライアント側で表示する段階」において複数のURLから特定のURLを選択することが必要であるが,そのようなことは記載はされておらず,むしろ,「翻訳データベースを用いてURLにマッピング」することや「ブラウザは次いでこのURLにより指定されたドキュメントのGET」を行うこと,「データベース604から演算されたNUMBERに対する目標URLが記述され」「クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGET」することを通常の意味に解釈すれば,記述子は単一のURLに対応するものと解される。
以上のことから,「前記クライアントにおいて記述子を提供する段階と,」とあるのを「前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,」とする訂正事項aは,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてしたものである。そして,該訂正事項aが特許請求の範囲を減縮するものであり,実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。

(2)訂正事項bについて
請求項1の記載によれば,「クライアントにおいて記述子を提供する段階」,「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階」,「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階」,「前記クライアントに前記URLを用いて情報を要求させる段階」,及び「前記URLにより識別されたページを前記クライアント側で表示する段階」の各段階を経てクライアントは情報ページに対してアクセスをすることができる。ここで,「クライアントにおいて記述子を提供する段階」は訂正事項aにおいて,「クライアントにおいて単一の目標URLに対応する記述子を提供する段階」との訂正がなされた。
訂正事項bは,請求項1において,「翻訳データベースを用いてURLにマッピングする段階と,」を「翻訳データベースを用いて前記URLにマッピングする段階と,」と訂正するものである。
そして,「クライアントにおいて単一の目標URLに対応する記述子を提供する段階」を経て,「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階」が行われるのであるから,「翻訳データベースを用いてURLにマッピングする段階」における「URL」が,「クライアントにおいて単一の目標URLに対応する記述子を提供する段階」の「単一の目標URL」を意味することは当然のことであり,「前記URL」は「URL」が「単一の目標URL」であることを明りょうにするものである。よって,訂正事項bは,明りょうでない記載の釈明を目的としたものであって,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてしたものである。そして,実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。

(3)訂正事項cについて
「情報を要求させる段階」について,発明の詳細な説明には以下の記載がある。
「メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。」(段落【0045】)
この記載から「情報を要求させる段階」について要求は自動的になされることは明らかである。よって,訂正事項cは,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてしたものであり,特許請求の範囲の減縮を目的としたものであって,実質上特許請求の範囲を拡張し又は変更するものではないことは明らかである。

(4)本件訂正についてのまとめ
以上のとおりであるから,本件訂正(訂正事項a?c)は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてしたものであり,特許請求の範囲の減縮,及び明りょうでない記載の釈明を目的とするものである。また,これらの訂正は実質上特許請求の範囲を拡張し又は変更するものではない。
したがって,本件訂正は,特許法第134条の2第1項第1号の「特許請求の範囲の減縮」及び同項第3号の「明りょうでない記載の釈明」に該当し,同条第5項で準用する同法第126条第3項及び第4項の規定に適合するので本件訂正を認める。

第3 本件訂正発明
本件特許の請求項1-7に係る発明は,訂正された特許請求の範囲の請求項1-7に記載された事項により特定される,次のとおりのものである。

【請求項1】
A.インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,
B.前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と,
C.ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と,
D.前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,
E.前記クライアントに前記URLを用いて情報を自動的に要求させる段階と,
F.前記URLにより識別されたページを前記クライアント側で表示する段階と
G.を備えた情報ページに対するアクセス方法。
【請求項2】
請求項1において,前記記述子が電話番号を備えた情報ページに対するアクセス方法。
【請求項3】
請求項1において,前記記述子が記述項目を備えた情報ページに対するアクセス方法。
【請求項4】
請求項3において,前記記述項目が会社名を含む情報ページに対するアクセス方法。
【請求項5】
請求項3において,前記記述項目が製品名を含む情報ページに対するアクセス方法。
【請求項6】
請求項3において,前記記述項目が音声により識別される情報ページに対するアクセス方法。
【請求項7】
請求項1において,前記URLにより識別されたページが管理ページである情報ページに対するアクセス方法。

(請求項1の構成要件を分説し,符号A?Gを当審で付した(以下,「構成要件A」?「構成要件G」という。)。以下,「請求項1」「請求項2」・・・「請求項7」に係る発明を「本件訂正発明1」「本件訂正発明2」・・・「本件訂正発明7」という。)

第4 審判請求人の主張の概要
請求人は,特許第3762882号の特許を無効とする,審判費用は被請求人の負担とする,との審決を求め,平成19年10月31日付け審判請求書と共に甲第1号証?甲第24号証を提出した。さらに,平成20年3月3日付け弁駁書を提出し,訂正が認められたとしても訂正後の特許請求の範囲は訂正前と同様に新規性ないし進歩性を欠き,本件特許の記載には不備があり,訂正にも不備があると主張した。その後,平成20年5月20日口頭審理(平成20年5月20付け口頭審理陳述要領書を提出)にて陳述し,平成22年4月19日付けで上申書と共に資料の提出を行った。なお,口頭審理において特許法第29条第1項第3号の主張は取り下げられ,当該主張における甲第1号証及び甲第2号証の記載に係る主張は,特許法第29条第2項の主張に援用されることとなった。請求人の主張する無効理由は,特許法第36条第6項第2号に規定する要件をみたしておらず,特許法第36条第4項に規定する要件をみたしておらず,特許法第29条第2項の規定により特許を受けることができないとするものであって,これらを整理すると請求人の主張は次のようである。

1.本件特許は,特許請求の範囲の記載が明確でないので,特許法第36条第6項第1号及び第2号に規定する要件を満たしていない。

(1)構成要件A,Gについて
構成要件Aにおける「情報ページに対するアクセスを提供する方法」と構成要件Gの「情報ページに対するアクセス方法」の意味が不明瞭である。
「アクセスを提供する方法」とは「クライアントに対して,別の主体が,目的のウェブページへの接続を提供する(接続してあげる)方法」と解される一方,「アクセス方法」とは「クライアントが,目的のウェブページに接続する方法」と解されるから,二つの「方法」は主体が異なる方法であるが,文頭の構成要件Aにおいて「アクセスを提供する方法」と明確に断定したにもかかわらず,文末の構成要件Gでは「アクセス方法」と,(被請求人も自認するとおり)異なる意味に翻って結ばれておりいずれが当該発明の内容か把握できない。
この点については「発明の詳細な説明」に明確な記載を見出すことができないので,本件特許発明の「特許請求の範囲」の記載は特許を受けようとする発明の記載が不明瞭である。

(2)構成要件Bについて
構成要件Bにおける「前記クライアントにおいて記述子を提供する段階」の記載は,「記述子を提供する」の技術的な意味,並びに「提供」する主体及びその「提供」先が明確でない。
本件発明1の黙示の実施主体としてユーザを念頭に置けば,構成要件Bは「ユーザが,クライアントPCに記述子を入力する段階」と解釈するのが自然であり,つづく構成要件Cの記載に拠れば,前記「記述子」は「提供」の結果として「ディレクトリサーバー」に到った,すなわち「送信」されたと解することも不可能ではない。
ところが,「特許請求の範囲」には「クライアントからディレクトリサーバーへ記述子を送信する段階」(あるいは,「ディレクトリサーバーがクライアントから記述子を受信する段階」)の記載が無いため,構成要件Cにおいて前記記述子が既に「ディレクトリサーバー」に場所を移していることとの整合が取れず,不合理である。
また,被請求人は,本件特許発明は「上記記述子をクライアントが直接的に何処へ『提供』するかなどということは何ら限定していない」と述べているが,限定していないというならば,本件特許は,特許請求の範囲において発明を成立させるに必須の構成要件を欠如しており,発明が不明確である。
被請求人は,答弁書に限らず出願審査中から,クライアントは記述子の提供行為の「行為主体」であると主張していたが,答弁書に至って,被請求人は「クライアント」は記述子を提供する「主体」であり,かつ「場所」であるというのである。要するに被請求人は「提供=ユーザによる記述子の入力行為(クライアントはそれを行う「場所」)」,「提供=記述子の送信行為(クライアントはそれを行う「主体」)」という2つの解釈を被請求人の都合に合わせて混同している。被請求人自身が混乱するほどに,構成要件Bの記載は不明瞭である。

(3)構成要件C,Dについて
構成要件C,Dにいう「ディレクトリサーバー」とは具体的に何であるか不明確である。
「ディレクトリサーバー」の記載は,「ディレクトリサービスを提供するコンピュータ」ほどの意味合いに理解することが自然であるが,ここにいう「ディレクトリサービス」とはイエローページ・サービスのような一般的ディレクトリサービスを想起してよいのか否か,「発明の詳細な説明に一切の説明がないため不明瞭である。
したがって,構成要件C,Dは,動作主体の「ディレクトリサーバー」について具体的でないため,特許を受けようとする発明が明確でなく,かつ明細書においてもその十分な裏付けがなされていない。
もっとも,被請求人の答弁が,ディレクトリサーバーとは何かについては当時の技術常識から明らかであるという趣旨であれば,それは首肯できる。「ディレクトリ」ないし「ディレクトリサービス」とは何かについて,出願当時の公知資料たる甲第6号証によれば,「ディレクトリによって保持されている情報は,ディレクトリ情報ベース(DIB)と総称され」,「DIBは,オブジェクトについての情報で構成されている。DIBは(ディレクトリ)エントリで,各エントリは一つのオブジェクトに関する情報の集合で構成される。各エントリは属性で,各属性は一つのタイプと一つ以上の値で構成される。あるエントリに存在する属性のタイプは,そのエントリが記述するオブジェクトのクラスに依存する。」,「DIBのエントリは,木構造,つまり節点がエントリであるディレクトリ情報木(DIT)にまとめられる。」等と説明される。
このような技術常識からすれば,「ディレクトリサーバー」は,ディレクトリ情報ベースを有するサーバー,あるいはディレクトリサービスに用いられるサーバーを意味すると解釈するほかはない。そして,それは,甲第1号証の引用発明に開示されたイエローページ・サービス(これがディレクトリサービスとして当時知られていた)のイエローページ・サーバーと同じサーバーに他ならない。

(4)請求項2-7の記載について
請求項2-7の記載は,記載に不備を有する請求項1の従属項であるから,各請求項ともにその記載が不明瞭である。

2.本件特許は,明細書及び図面の記載が明確でないので,特許法第36条第4項に規定する構成要件を満たしていない。

(1)本件明細書には,クライアントにおいて提供された記述子をどのような手段で翻訳データベースの存在するディレクトリサーバーに送るか又は受け取るか,「“ダイヤル”コマンド」とは何か,「“ダイヤル”コマンド」以外に記述子を入力し送信する方法はあるのか,標準的なプロトコルは利用できるのか,ウェブクライアントでなくディレクトリクライアントから利用できるのかについて説明されていないから,発明の詳細な説明及び図面の記載は当業者が実施可能な程度に発明の内容が開示されているとはいえない。

3.特許法第29条第2項
本件の請求項1-7に係る発明は,その優先日前日本国内又は外国において頒布された刊行物に記載された発明に基いて,その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができず,本件特許は同法第123条第1項第2号の規定により無効とされるべきである。

(1)請求項1について
本件特許の請求項1の構成要件A「インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって,」について,甲第1号証には,「インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする」旨が記載され,「フラグシップ・ホスト上で動作する転送メカニズムが,実際にそのサービスを提供するサーバーにクライアントを接続させる」旨が記載されており,かつ,甲第1号証において「ローカル・サーバーにアクセス」を「サーバーコンピュータが提供する情報サービスにアクセスする」ようにすることは容易であるから,前記構成要件Aは甲第1号証から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件B「前記クライアントにおいて記述子を提供する段階と,」について,甲第1号証には,「サービスを受けたいクライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる。」旨が記載されているから,前記構成要件Bは甲第1号証から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件C「ディレクトリサーバーが,前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いてURLにマッピングする段階と,」について,甲第1号証には,「各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには,各サービスとそのサービスを提供するサーバーのセットとがバインディングされて格納される。」旨が記載され,「サービス名をサーバーのアドレスにマッピングするイエローページ・サービスを紹介する。」旨が記載されており,かつ,甲第5号証にはイエローページとはディレクトリ情報群であることが記載され,甲第2号証には仮想的なディレクトリを物理的なファイル・システムにおけるパスへと変換するコマンドとしてマッピングが記載され,甲第3号証には「インターネット上の分散したリソースに対して,統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがURLです。」と記載されているから,前記構成要件Cは甲第1号証及び甲第2号証に記載された発明,並びに甲第3号証及び甲第5号証に記載された周知技術から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件D「前記ディレクトリサーバーが,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と,」について,甲第1号証には,「イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する」旨が記載され,「対照的に,プロトコルは,フラッグシップ・ホストがクライアントに対して,そのパケットをリダイレクトする必要があると知らせるように修正できるであろう。」旨が記載されており,かつ,甲第2号証には,「Redirectに指定したパターンにマッチした場合は,指定したURLにリクエストがそのままフォワードされる。」と記載されているから,前記構成要件Dは甲第1号証及び甲第2号証から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件E「前記クライアントに前記URLを用いて情報を要求させる段階と,」について,甲第1号証には「対照的に,プロトコルは,フラッグシップ・ホストがクライアントに対して,そのパケットをリダイレクトする必要があると知らせるように修正できるであろう。」旨が記載され,かつ,甲第3号証には「インターネット上の分散したリソースに対して,統一的な名前の付け方を決めてユーザー・インターフェイスを向上させる試みがあります。それがURLです。」と記載されているように,情報ページの存在を特定するものがURLであることは周知技術であるから,前記構成要件Eは甲第1号証に記載された発明,及び前記周知技術から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件F「前記URLにより識別されたページを前記クライアント側で表示する段階と」について,甲第1号証には「インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにする」旨が記載され,「フラグシップ・ホスト上で動作する転送メカニズムが,実際にそのサービスを提供するサーバーにクライアントを接続させる」旨が記載されており,かつ,甲第4号証にあるようにアクセス先のサーバーにURLで指定される情報ページが備わることは周知技術であるから,前記構成要件Fは甲第1号証に記載された発明,及び前記周知技術から当業者が容易に想到し得るものである。
本件特許の請求項1の構成要件G「を備えた情報ページに対するアクセス方法。」について,甲第1号証には「クライアントは,そのホスト上でサーバーを使用できるかのように,フラグシップ・ホストに接続する。」旨が記載されており,かつ,甲第4号証にあるようにアクセス先のサーバーに情報ページが備わることは周知技術であるから,前記構成要件Gは甲第1号証に記載された発明,及び前記周知技術から当業者が容易に想到し得るものである。
したがって,請求項1に係る発明は,甲第1,2号証に開示された技術事項を適宜選択し或いは寄集めたにすぎず,またこれらの公知技術を組合せることについては動機付けとなり得る記載が多数認められる一方で技術的な阻害要因は一切なく,しかも公知技術と比較しても予想の範囲を超える有利な効果も認められないことから,結局,出願時の技術水準に基づき当業者をして容易に想到できたものである。

(2)請求項2について
本件特許の請求項2の構成要件「前記記述子が電話番号を備えた」について,甲第8号証には,電話番号を翻訳データベースを用いてアクセス先のアドレスにマッピングし,該アドレスをREDIRECTコマンドを用いてクライアントに返送する旨が記載され,甲第9号証には,「FAXをある人に送信するためにはその人の電話番号を知るだけでよい」旨が記載され,甲第5号証には,ディレクトリサービスにおける属性の例示として電話番号が記載されており,記述子として電話番号は周知技術であるから,請求項2に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

(3)請求項3について
本件特許の請求項3の構成要件「前記記述子が記述項目を備えた」について,「記述項目」とは,「記述的又は説明的な言葉ないしは用語」ほどの意味であると理解され,甲第5号証にあるように記述項目を記述してサービスを問い合わせることは周知技術であるから,請求項3に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

(4)請求項4について
本件特許の請求項4の構成要件「前記記述項目が会社名を含む」について,甲第6号証には識別子として組織が記載され,甲第13号証には会社名を記述子として情報検索を行う旨が記載され,甲第5号証には属性の例示の中に組織名=会社名が記載されており,記述項目として会社名は周知技術であるから,請求項4に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

(5)請求項5について
本件特許の請求項5の構成要件「前記記述項目が製品名を含む」について,甲第6号証には識別子として「一般名=レーザプリンタ」や「一般名=ファクス端末」が記載され,甲第13号証には製品カテゴリー名を記述子として情報検索を行う旨が記載されており,記述項目として製品名は周知技術であるから,請求項5に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

(6)請求項6について
本件特許の請求項6の構成要件「前記記述項目が音声により識別される」について,甲第14号証には音声認識機構(soundex and phonix)について記載し,甲第15号証には音声検索機能について記載しており,記述項目が音声により識別されることは周知技術であるから,請求項6に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

(7)請求項7について
本件特許の請求項7の構成要件「前記URLにより識別されたページが管理ページである」について,「管理ページ」とはクライアントからのアクセスが制御されたページであると解釈でき,一方,甲第2号証には,サーバーへのアクセス管理の方法について記載し,甲第6号証には,ユーザ認証を行うことについて記載し,甲第5号証には「認証」「承認」などのアクセス管理について記載しており,URLにより識別されたページが管理ページであることは周知技術であるから,請求項7に係る発明は甲第1号証及び甲第2号証に記載された発明,並びに前記周知技術から当業者が容易に想到し得るものである。

4.証拠方法
甲第一号証の一 COMPUTER COMMUNICATION REVIEW 17巻5号
「A Yellow-Page Service for a Local Area
Network」(1988年出版)
甲第一号証の二 甲第一号証の一の翻訳文
甲第二号証 『UNIX USER』Vol.3 No.12(1994.12.1発行)
甲第三号証 『UNIXMAGAZINE』1994 2月号
甲第四号証 『Internet User』Vol.1 No.2(1995.2.1発行)
甲第五号証 CCITT(BLUE BOOK)第2巻2-6
Fシリーズ勧告「勧告F.500」
甲第六号証 CCITT(BLUE B00K)第VIII巻 VIII-6,8
Xシリーズ勧告「勧告X.500」及び「勧告X.518」
甲第七号証 WIDEプロジェクト1992年度研究報告書
甲第八号証 特表平8-500708号公報
甲第九号証 特開平6-85924号公報
甲第十号証の一 Configuration File of CERN h t t pd
甲第十号証の二 甲第十号証の一の翻訳文
甲第十一号証の一 Rules In The Configuration File
甲第十一号証の二 甲第十一号証の一の翻訳文
甲第十二号証の一 Directory Browsing
甲第十二号証の二 甲第十二号証の一の翻訳文
甲第十三号証の一 Newsbytes Nov 9, 1994 (Menefee)
甲第十三号証の二 甲第十三号証の一の抄訳文
甲第十四号証の一 Digital Systems Journal Sept-Oct 1994 (Buh1e)
甲第十四号証の二 甲第十四号証の一の抄訳文
甲第十五号証の一 X.500 Implementation Description Page
甲第十五号証の二 甲第十五号証の一の翻訳文
甲第十六号証の一 米国特許第5297249号公報(BERNSTEIN)
甲第十六号証の二 甲第十六号証の一の抄訳文
甲第十七号証 WIDEプロジェクト1989年度研究報告書
甲第十八号証 米国特許出願第08/486797号書面
甲第十九号証の一 米国特許出願第08/486797号審査経過
甲第十九号証の二 甲第十九号証の一の翻訳文
甲第二〇号証 米国特許第5812776号公報
甲第二一号証の一 米国特許第5530852号公報(Meske)
甲第二一号証の二 甲第二一号証の一の抄訳文
甲第二二号証の一 max.500ウェブサイト出力
甲第二二号証の二 甲第二二号証の一の翻訳文
甲第二三号証の一 RFC1632
甲第二三号証の二 甲第二三号証の一の翻訳文
甲第二四号証 本件出願に対する拒絶理由通知書

第5 被請求人の主張の概要
被請求人の主張の概要は次のとおりである。

1.本件訂正発明1-7に,特許法第36条第6項第1号及び第2号の規定に違反する不備は存在しない。

(1)構成要件A,Gについて
構成要件Aとして「アクセスを提供する方法」と規定するとともに,構成要件Gとして「アクセス方法」と規定することにより,本件特許発明の特徴が,クライアントがURLとは異なる数字あるいは言葉である記述子を提供した場合(構成要件B)であっても,構成要件CないしEによって具体的に記載される「アクセスを提供する方法」(構成要件A)によって,該クライアントが目的の情報ページ(ウェブページ)にアクセスすることを可能にする方法,すなわち「情報ページに対するアクセス方法」(構成要件G)であることが,特許請求の範囲として明確にされている。両者の規定を区別した理由は,2つの「方法」が性質の異なる段階であることを明確にするためのものである。
すなわち,構成要件Aの「アクセスを提供する方法」とは,本件発明1の実施主体が「アクセスを提供する」ものであり,その具体的構成は以下に続く構成要件BないしGによって実現されるものであり,これに対して,構成要件Gの「アクセス方法」は,構成要件Aの「アクセスを提供」を実現するために,発明の構成要件としてハードウェアであるクライアントがアクセスすることを要することを意味するものである。
換言すると,本件特許の特許請求の範囲の記載は,発明の実施行為自体は究極的に発明実施主体である人によって行われる(構成要件A)ことをクレームのおいて書きで明らかとしつつ,そのための各構成要件は様々なハードウェア(クライアント,サーバー等)によって実現されていくことを明確にした(構成要件BないしG)ものである。

(2)構成要件Bについて
構成要件Bにおける「クライアントにおいて記述子を提供する」とは,「記述子」が,クライアントから送信されることを意味し,上記「記述子」のクライアントへの入力方法それ自体を何ら規定するものではないことが明瞭であるから,何ら記載不明瞭の問題は存しない。請求項1においては,「記述子」について,これを「提供」するハードウェアとしての主体がクライアントであることを明確に規定されている。
特許法においては,物の発明に関する実施行為の定義として,「譲渡等(譲渡及び貸渡しをいい,その物がプログラム等である場合には,電気通信回線を通じた提供を含む。以下同じ。)」(特許法第2条第3項第1号)と規定されているように特許法を始めとする知的財産法自体が,インターネットにおける「提供」という用語が送信行為を意味することを当然の理解としている。
また,上記記述子をクライアントが直接的に何処へ「提供」するかなどということは何ら限定していない。
したがって,本件特許請求の範囲の記載上,構成要件Bが上記のような意義を有することが明確であり,何ら記載不明瞭の問題を生じるものではない。

また,本件特許明細書の発明の詳細な説明の記載においても,「本発明は,クライアントからサーバーへのネットワークを介したサービス要求を処理する方法に関する。」(【0001】【発明の属する技術分野】)として本件特許発明が「クライアントから」の「サービス要求を処理する方法」であることを明記しており,構成要件Bが「クライアント」からの「記述子」送信行為であることを明確としている。
本件特許明細書の実施例では,「本発明の一構成では,商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている。…(中略)…好ましい実施形態では,図6に示されるように,ウェブブラウザクライアント601がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし,キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでNUMBERがユーザにより指定された電話番号,またはその他の識別子である,書式“http://directory.net/NUMBER”のURLを構成する。ブラウザは次いでこのURLにより指定されたドキュメントのGETを行い,ディレクトリサーバー602に連絡し,メッセージ1で要求されたNUMBERを送信する。」(段落【0041】)とされているところ,請求項1の「クライアントにおいて記述子を提供する」との構成要件Bは,「ブラウザは次いでこのURLにより指定されたドキュメントのGETを行い,ディレクトリサーバー602に連絡し,メッセージ1で要求されたNUMBERを送信する。」との記載に基づいて特許請求の範囲に規定されたものである。
このように,実施例中の上記記載も,構成要件Bにおける「記述子を提供する」との用語が,クライアントからの「記述子」送信行為を意味することを明確にしている。
さらに,本件特許出願人は,乙第2号証(平成17年6月20日付け意見書)で「すなわち,記述子を提供する段階はクライアントが行い」との意見を述べて,同日付の手続補正書において,請求項1を現在のとおり「前記クライアントにおいて記述子を提供する段階へ」と補正し,その結果特許が付与されている。

(3)構成要件C,Dについて
審判請求人は,「構成要件C,Dにいう『ディレクトリサーバー』とは具体的に何であるか不明確である。」と主張するが,構成要件Cは,クライアントから送信された「記述子」を受信した「ディレクトリサーバー」がその翻訳データベースを用いて該「記述子」に対応するURLを検出することを意味するに留まるものである。また,「ディレクトリサーバー」は,該URLをREDIRECTコマンドに含めて該クライアントに返送するものである(構成要件D)。このように,本件特許発明において,「ディレクトリサーバー」は,上記「記述子」を「翻訳データベースを用いてURLにマッピング」し,「REDIRECTコマンド中の前記URLを前記クライアントに返送する」サーバーであることを要するとともに,これで足りるものであり,DNSとしての機能を併有してもよく,何ら記載不明瞭の問題は存しない。

2.本件訂正発明1-7に,特許法第36条第4項の規定に違反する不備は存在しない。
(1)本件特許発明の特徴は,「本願発明が適用するようなインターネットの技術分野では,ウェブサイトヘアクセスする際に,長く複雑なURLを入力する必要があるが,本願発明では,このような長く複雑なURLに代えて,このURLに対応して誰でも簡単かつ容易に入力できる電話番号,会社名,製品名などを入力するだけで,目標とするURLのウェブサイトヘアクセスできるようにしたもの」(乙第2号証(平成17年6月20日付け意見書),乙第3号証(同年12月5日付け意見書))である。そして,かかる特徴及び効果を奏するものとして特許されたものである。
したがって,「標準的なプロトコルは利用することができるのか」,「ウェブクライアントでなくディレクトリクライアントからは利用できるのか」,「できるとすれば如何なる態様によるのか」といった事項は,当業者が実際に本件特許発明を実施するにあたって適宜設計すべき事項に過ぎず,本件特許明細書にそれらについての詳細な説明が仮にないとしても何ら実施不能の問題を生じるような事項ではない。発明の実施の形態について,特許出願人が最良と思うものを記載するという点は,特許法第36条第4項により求められている要件ではなく,特許出願人が最良と思うものを記載していないことが明らかであっても,拒絶理由等にはならない。
以上のとおりであるから,本件特許明細書の発明の詳細な説明は,特許法第36条第4項が定める要件を十分満たしている。

3.本件訂正発明1-7は,甲第1号証及び甲第2号証に記載された発明に基づいて,当業者が容易に発明をすることができたものではない。

(1)請求項1について,本件特許は,TCP/IP上で作動するHTTPのURL指定とユーザに馴染みのある会社名等の言葉(ないし数字)である「記述子」とを対応させ,当該「記述子」を与えるだけで,自動的に目標とする情報サイトへアクセスできるようにしたものである。甲第1号証の発明は,クライアントが受けたいサービスの名前や属性条件を指定し,該当サービスを提供可能なサーバーの検索結果を返答させるものである。

本件特許の「記述子」とは,電話番号,会社名,製品名等のユーザーに理解可能なURLとは異なる数字あるいは言葉であり,かつ,当該「記述子」に対応し,目標情報ページを識別する特定かつ唯一の「URL」へとマッピングされる。甲第1号証の発明はクライアントがサーバーに対して求めるサービスの内容やその質といった条件を指定するものであり,特定かつ唯一のサーバーへと対応付けられるものではない。よって,甲第1号証の「サービス名およびサーバーが持つべき任意の属性」は,本件特許の「記述子」に相当しない。

本件特許の「翻訳データベース」は,人間が理解する電話番号,会社名,製品名等の「記述子」をコンピュータネットワーク上の特定の資源(サーバーなど)を指し示す「URL」へと翻訳を行うものである。甲第1号証の「データベース」は,クライアントによって指定された条件をみたすサーバーを検索するものにすぎない。

本件特許の「URL」は「記述子」に対応する特定かつ唯一のものであって目標とする「情報ページ」を識別するものである。甲第1号証は「フラグシップ・ホスト」の「アドレス」が「クライアント」に返されるものである。

本件特許の「REDIRECTコマンド」はREDIRECTコマンド中の特定かつ唯一のURLがクライアントへと返信されることによって自動的に,クライアントをして特定かつ唯一のURLに対応するウエッブへと情報要求させるものである。甲第1号証において「リダイレクト」によりクライアントがどのような動作を要求されるか開示も示唆もない。また「イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する」と,「対照的に,プロトコルは,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる」とを,同時あるいは連続して行うよう結びつけることについて開示も示唆もない。

(2)請求項2-7に係る発明は,特許性を有する請求項1の従属項であるから,同様に特許性を有する。

4.証拠方法
乙第1号証 本件特許明細書(特許第3762882号)
乙第2号証 本件出願の平成17年6月20付意見書
乙第3号証 本件出願の平成17年12月5日付意見書

第6 甲1号証について
甲第1号証(Larry L. Peterson,“A Yellow-Pages Service for a Local-Area Network”,COMPUTER COMMUNICATION REVIEW,Volume 17,Number 5,Special Issue,ACM Press,1988,p.235-242)には,次の事項が記載されている。(以下,甲第1号証の1の翻訳文を併記する。)

(1)第235頁左欄第7-12行「In addition to describing the implementation of the yellow-pages service within a local-area network, we show how the service can be integrated with the available internet communication protocols to enable clients from throughout the internet to access local servers.」(翻訳文「イエローページ・サービスのローカルエリア・ネットワーク内での実施の説明だけでなく,インターネットの至る所からクライアントがローカル・サーバーにアクセスできるようにするために,本サービスが,使用可能なインターネット通信プロトコルとどのように統合できるかを示す。」)

(2)第235頁左欄第14-16行「This paper describes a yellow-pages service that maps the name of a service into the address of a server willing to provide the service.」(翻訳文「この論文では,サービスを提供しようとするサーバーのアドレスにサービス名をマッピングするイエローページ・サービスについて説明する。」)

(3)第235頁左欄第28行-右欄第4行「A client that wishes to engage a service queries the yellow-pages service for the address of a server, specifying the name of the service and any attributes the server should possess. The yellow-pages service returns the address of one or more servers that satisfy the client's requirements.」(翻訳文「サービスを受けたいクライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせる。イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送する。」)

(4)第235頁右欄第10-14行「Clients connect to the flagship host as though the server is available on that host. A forwarding mechanism running on the flagship host then "patches" the client through to an actual server that provides the service.」(翻訳文「クライアントは,そのホスト上でサーバーを使用できるかのように,フラグシップ・ホストに接続する。次に,フラグシップ・ホスト上で動作する転送メカニズムが,実際にそのサービスを提供するサーバーにクライアントを接続させる。」)

(5)第235頁右欄第32-34行「A set of servers implement the yellow-pages service. Each server maintains a database of information about the available services and servers.」(翻訳文「サーバーのセットが,イエローページ・サービスを実施する。各サーバーは,使用可能なサービスおよびサーバーに関する情報のデータベースを維持する。」)

(6)第236頁左欄第2-3行,同欄第11-13行「An attribute is a sytactic object that denotes a property or characteristic of a server.」「Clients submit a set of attributes when querying the yellow-pages for a server that provides a particular service.」(翻訳文「属性は,サーバーのプロパティまたは特徴を示す統語的要素である。」「クライアントは,ある特定のサービスを提供するサーバーについてイエローページに問い合わせる際,属性のセットを送信する。」)

(7)第236頁左欄第53-56行「Associated with each yellow-pages server is a database of information about the services available in the system. The database contains bindings of each service to a set of servers that provide the service.」(翻訳文「各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられる。データベースには,各サービスとそのサービスを提供するサーバーのセットとが結びつけて格納される。」)

(8)第237頁左欄第2-4行「Clients query the yellow-pages service for the address of one or more servers that provide a given service with the operation」(翻訳文「クライアントは,以下のオペレーションによって,イエローページ・サービスに対し,ある所定のサービスを提供する一或いは二以上のサーバーのアドレスを問い合わせる。」)

(9)第238頁右欄第20-26行「As another example, suppose the client wishes to retrieve the address of the printer based on its location: e.g.,"the printer in Rick's office". In the case, the client invokes the lookup() operation with the mandatory attibute loc=rick. Any number of optional attributes are ignored because the mandatory attribute loc=rick selects a single server.」(翻訳文「別の例として,クライアントが場所,例えば「Rickのオフィスのプリンタ」などに基づいてプリンタのアドレスを取得したいとする。この場合,クライアントは,必須属性をloc=rickとしてlookup()オペレーションを要求する。必須属性loc=rickによって唯一のサーバーが選択されるので,オプション属性がいくつあってもすべて無視される。」)

(10)第239頁右欄第24-28行「The system advertizes the flagship as offering a set of services to Internet clients by registering a set of resource records - potentially one for each service - with the domain naming system.」(翻訳文「システムは,ドメイン名システム(domain naming system)によって,一つのセットのリソース・レコード-サービスごとにひとつある可能性がある-を登録することによって,フラグシップがサービスのセットをインターネット・クライアントに提供するものとして広告する。」)

(11)第239頁右欄第30行-第240頁左欄第14行「A client consults the domain name server to learn the address of a host at the system that offers a particular service and the address of the flagship host is returned. The client then contacts the server by sending one or more packets addressed to the well-known port on the flagship host. The flagship host, in turn, forwards the packets to a server within the system. Thus, the forwarding mechanism is analogous to the strategy of accessing a server at well-known port: The flagship serves as the "well-known host" for the system. Consider how the forwarding mechanism is implemented within TCP in more detail. The TCP module running on the flagship host is modified to include the forwarding mechanism. Associated with the forwarding mechanism is a table that binds well-known ports to the address of servers.」(翻訳文「クライアントは,システムにおいて特定のサービスを提供するホストのアドレスを取得するためにドメイン名サーバーに問い合わせ,フラグシップ・ホストのアドレスが返される。その後,クライアントは,フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって,サーバーに接続する。すると,フラグシップ・ホストは,そのパケットをシステム内のサーバーに転送する。このように,転送メカニズムは,ウェルノウンポートにおいてサーバーにアクセスする戦略と類似している。フラグシップは,システムに対して,「ウェルノウンホスト」の役割を果たす。転送メカニズムがTCP内でどのように実施されるかを更に詳細に検討する。フラグシップ・ホスト上で動作するTCPモジュールが,転送メカニズムを含むように変更される。転送メカニズムには,ウェルノウンポートをサーバーのアドレスに結びつけるテーブルが関連付けられる。」)

(12)第240頁左欄第17-24行「When a packet arrives at the TCP module addressed for some port, the forwarding mechanism is consulted to see if forwarding is to take place for that port; i.e., if there is an entry in the table. If the packet is from a new client, the forward server randomly selects one of the available servers and forwards the packet's destination address to the server's address and resends packet.」(翻訳文「あるポート宛のパケットがTCPモジュールに到着すると,そのポートへの転送が行われるべきか,すなわち,テーブルにエントリが存在するかについて,転送メカニズムが問い合わせられる。パケットが新規クライアントからの場合,転送サーバーは,使用可能なサーバーをランダムにひとつ選択し,パケットをそのサーバーに転送する。すなわち,転送メカニズムは,パケットの宛先のアドレスをそのサーバーのアドレスに設定し,パケットを再送信する。」)

(13)第240頁左欄第29-35行「The TCP module runnning on teh server host is aware that forwarding is taking place and sends all reply messages directly to the client. TCP on the server host sets the packet's source address to the client as though it is still communicating with the flagship host.The client,therefore, is never aware that the forwarding is taking place」(翻訳文「サーバー・ホスト上で動作するTCPモジュールは,転送が行われていることを認識し,すべての応答メッセージを直接クライアントに送信する。サーバー・ホスト上のTCPは,パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し,それによって,クライアントには,クライアントがまだフラッグシップ・ホストと通信しているかのように見える。従って,転送が行われていることをクライアントが認識することはない。)

(14)第240頁右欄第12-25行「A load manager executing on the flagship host is responsible for binding each well-known port to a set of servers in the forwarding mechanism's table The load manager's objective is to distribute remote work over the local servers so as to balance their load In the case of generally available services, such as the mail service, the manager becomes a client of the yellow-pages service by periodically querying for all processor serviers with a load under a certain threshold. The manager then updates the forwarding mechanism's table accordingly. Note that becauze the forwarding mechanism is embedded in TCP remote client are not able to request servers that satisfy a particular set of attributea; only the load manager is a client of the yellow-pagea service.」(翻訳文「フラッグシップ・ホスト上で動作するロード・マネージャは,転送メカニズム・テーブル内のウェルノウンポートのそれぞれをサーバーのセットにバインディングする。ロード・マネージャの目的は,ローカル・サーバーの負荷のバランスをとるために,遠隔作業をローカル・サーバーに分配することである。メール・サービスさどの,一般的に使用可能なサービスの場合,負荷がある閾値以下のすべてのプロセッサ・サーバーを定期的に問い合わせることによって,マネージャは,イエローページ・サービスのクライアントとなる。そして,マネージャは,転送メカニズムのテーブルを適宜更新する。ただし,転送メカニズムは,TCPに組み込まれているので,遠隔クライアントは,特定の属性のセットを満足するサーバーを要求することはできず,ロード・マネージャのみが,イエローページ・サービスのクライアントとなる。)

(15)第241頁右欄第45-51行「The forwarding mechanism acts as an intermediary between the client and server. This has the advantage of not requiring any changes to the transport protocol because the client is shielded from indirection. In contrast, the protocol could be modified such that the flagship host informs the client that it should redirect its packets to the server host.」(翻訳文「転送メカニズムはクライアントとサーバー間の仲介人の機能を果たす。これは,クライアントが間接参照から守られているため,トランスポートプロトコルに対するあらゆる変更を要求しないという優位点を有する。対照的に,プロトコルは,フラッグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できるであろう。」)

以上から,甲第1号証には次の発明が記載されている。
「インターネットの至る所からクライアントがローカル・サーバーにアクセスする方法であって,サーバーのセットが,イエローページ・サービスを実施し,各サーバーは,使用可能なサービスおよびサーバーに関する情報のデータベースを維持し,各イエローページ・サーバーには,システム内で使用できるサービスについての情報のデータベースが関連付けられ,データベースには,各サービスとそのサービスを提供するサーバーのセットとが結びつけて格納され,
クライアントは,サービス名およびサーバーが持つべき任意の属性を指定して,イエローページ・サービスにサーバーのアドレスを問い合わせ,
イエローページ・サービスは,サービス名を,サービスを提供しようとするサーバーのアドレスにマッピングし,
イエローページ・サービスは,クライアントの要求を満たす一或いは二以上のサーバーのアドレスを返送し,
転送メカニズムでは,クライアントは,フラグシップ・ホスト上のウェルノウンポート宛に一或いは二以上のパケットを送信することによって,サーバーに接続し,フラグシップ・ホストは,そのパケットをシステム内のサーバーに転送し,
サーバー・ホスト上で動作するTCPモジュールは,転送が行われていることを認識し,サーバー・ホスト上のTCPは,パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し,すべての応答メッセージを直接クライアントに送信し,
転送メカニズムと対照的に,フラグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるように修正できる,
クライアントがローカル・サーバーにアクセスする方法。」

第7 当審の判断

1.特許法第36条第6項第1号及び第2号について
(1)構成要件A,Gについて
審判請求人は,「アクセスを提供する方法」とは「クライアントに対して,別の主体が,目的のウェブページへの接続を提供する(接続してあげる)方法」と解される一方,「アクセス方法」とは「クライアントが,目的のウェブページに接続する方法」と解されるから,二つの「方法」は主体が異なる方法であるが,文頭の構成要件Aにおいて「アクセスを提供する方法」と明確に断定したにもかかわらず,文末の構成要件Gでは「アクセス方法」と,(被請求人も自認するとおり)異なる意味に翻って結ばれておりいずれが当該発明の内容か把握できないと主張している。
しかし,「アクセス」が,構成要件Aの「インターネットよりなるコンピュータネットワークを介したクライアント」による「サーバーシステムヘの情報ページ」に対するものであることは本件訂正発明1の自体の記載から明らかであり,本件訂正発明1がそのような「アクセス」方法を提供する発明であることも明らかである。そして提供されるアクセス方法は構成要件B?Fの各段階を備えており,これら各段階の記載から,各段階の処理はディレクトリサーバー側で行われることが想定されていることは明らかである。
また,本件明細書の段落【0041】?【0045】には次の記載がある。

【0041】
本発明の一構成では,商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている。これらの商業者サービスはSIDを用いて任意に保護され得る。好ましい実施形態では,図6に示されるように,ウェブブラウザクライアント601がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし,キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでNUMBERがユーザにより指定された電話番号,またはその他の識別子である,書式“http://directory.net/NUMBER”のURLを構成する。ブラウザは次いでこのURLにより指定されたドキュメントのGETを行い,ディレクトリサーバー602に連絡し,メッセージ1で要求されたNUMBERを送信する。
【0042】
別の実施形態では,従来のブラウザを備えた形で,クライアント601が“ダイヤル”コマンドの場所に電話番号,またはその他の識別子を入れることを促すディレクトリサーバー602により提供された書式ページを用いる。メッセージ1はこの書式ページにより指定されたURLに対するPOSTメッセージである。
【0043】
一旦NUMBERがディレクトリサーバー602により受信されると,ディレクトリサーバーはデータベース604を用いて,NUMBERに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標URLにNUMBERを翻訳する。この翻訳は番号の句読法を無視する可能性があり,従って埋め込まれた括弧またはダッシュは意味を持たない。
【0044】
別の実施形態では,数字以外の識別子を設けることができる。例えば,ユーザは会社名または製品名を不正確なつづりで記入することがある。このような場合“soundex ”または他の音声マッピングが同じ目標URLに対するマップと類似して響く語を許容するため用いることができる。また,製品名または内線と組み合わせた電話番号のような複数の識別子も使用可能である。
【0045】
メッセージ2では,ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。商業者サーバー603はメッセージ4におけるこの情報を返送する。サーバー602はウェブページをクライアントに返送して,要求されたドキュメントに対して適切なリンクを提供する。しかしながら,サーバー602が最終的なURLに対する翻訳を行い,ページよりはむしろREDIRECTをクライアント601に送信するため,メッセージ4のドキュメントは最初のダイヤル入力以上のユーザの行為なしで入手される。

段落【0041】の「商業者のサービスにアクセスするためにユーザが従来の電話番号,またはその他の識別子を利用できるようにする便が設けられている」こと,段落【0043】の「一旦NUMBERがディレクトリサーバー602により受信されると,ディレクトリサーバーはデータベース604を用いて,NUMBERに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標URLにNUMBERを翻訳する。」こと,段落【0045】の「ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し,このURLのコンテンツをGETする。」ことから,ユーザが商業者のサービスにアクセスするための方法を理解することができる。
したがって,「アクセス」に関する構成要件A,構成要件Gの記載及び相互の関係は明りょうであり,発明の詳細な説明にも記載されている。

(2)構成要件Bについて
審判請求人は,構成要件Bにおける「前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階」の記載は,「記述子を提供する」の技術的な意味,並びに「提供」する主体及びその「提供」先が明確でないと主張している。
審判請求人は更に,構成要件Bは「ユーザがクライアントPCに記述子を入力する段階」と解釈することが文言上は自然であるが,特許請求の範囲には「クライアントからディレクトリサーバーへ記述子を送信する段階」(あるいは,「ディレクトリサーバーがクライアントから記述子を受信する段階」)の記載が無いため,構成要件Cにおいて前記記述子が既に「ディレクトリサーバー」に場所を移していることとの整合が取れず,不合理であると主張している。
しかし,発明の詳細な説明の段落【0041】-【0044】の記載によれば,記述子はユーザがクライアントに入力するものであり,クライアントに入力された記述子はディレクトリサーバーに送信されることが理解できる。
そして,審判請求人が主張するとおり,特許請求の範囲には「クライアントからディレクトリサーバーへ記述子を送信する段階」(あるいは,「ディレクトリサーバーがクライアントから記述子を受信する段階」)の記載はないが,クライアントにおいて記述子が提供され(構成要件B),ディレクトリサーバーにおいて前記記述子がURLにマッピング(構成要件D)されているから,「記述子を送信する段階」や「記述子を受信する段階」が明記されていなくても,請求項1において,構成要件Dにおける記述子が構成要件Bにおいてクライアントにおいて提供された記述子であることは明確に理解することができる。
したがって,構成要件Bの記載は明りょうである。

(3)構成要件C,Dについて
審判請求人は,構成要件C,Dにいう「ディレクトリサーバー」とは具体的に何であるか不明確であると主張している。しかしながら,「ディレクトリサーバー」は,構成要件Cに記載されているように「前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と」を有するサーバであって,それ自体意味は明らかである。
そして,この点に関し,発明の詳細な説明の段落【0043】には,「一旦NUMBERがディレクトリサーバー602により受信されると,ディレクトリサーバーはデータベース604を用いて,NUMBERに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標URLにNUMBERを翻訳する。」と記載され,段落【0045】には,「ディレクトリサーバー602がREDIRECTをクライアント601に送信し,これには,データベース604から演算されたNUMBERに対する目標URLが記述されている。」と記載されており,ディレクトリサーバーは構成要件C,Dに記載されているように「前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と」を有するサーバであって,その意味は明らかであり,発明の詳細な説明にも記載されている。

(4)請求項2-7の記載について
審判請求人は,請求項2-7の記載は,記載に不備を有する請求項1の従属項であるから,各請求項ともにその記載が不明瞭であると主張しているが,請求項1の記載が明確であることは前記のとおりであり,請求項1を引用して記載された請求項2-7にはその他に不明りょうな記載は見当たらないから,請求項2-7の記載は明りょうである。

以上のとおりであるから,本件特許の特許請求の範囲は,特許法第36条第6項第1号及び第2号に規定する要件を満たしている。

2.特許法第36条第4項について
審判請求人が不明確であると主張する特許請求の範囲の記載が,明細書の記載との関係において明確であることは前記のとおりである。
そして,審判請求人の主張する「記述子をどのような手段で翻訳データベースの存在するディレクトリサーバーに送るか又は受取るか」,「「“ダイヤル”コマンド」とは具体的には何なのか」,「「“ダイヤル”コマンド」以外に記述子を入力し送信する具体的な方法はあるのか否か,あるとすればどのような方法か」,「標準的なプロトコルは利用することができるのか」,「ウェブクライアントでなくディレクトリクライアントからは利用できるのか,できるとすれば如何なる態様によるのか」などの点が不明であっても,記述子をクライアントにおいて提供することが実施可能であることは明らかであるし,そのために情報処理の段階を設ける必要が生じても,実施にあたって適宜選択し得る設計的事項にすぎないから,本件特許の明細書は当業者が本件訂正発明1-7を実施できる程度に明確かつ十分に記載されている。

よって,本件特許の明細書及び図面の記載は,特許法第36条第4項に規定する要件を満たしている。

3.特許法第29条第2項について
(1)本件訂正発明1について
本件訂正発明1と上記「第6」の引用発明を対比すると,少なくとも,以下の点において相違(以下,「相違点」という。)するものと認められる。

本件訂正発明1は,「ディレクトリサーバー」が,REDIRECTコマンド中の前記URLを前記クライアントに返送する段階を備えるのに対して,引用発明においては,サーバー・ホスト上で動作するTCPモジュールは,転送が行われていることを認識し,サーバー・ホスト上のTCPは,パケットのソース・アドレスをフラッグシップ・ホストのアドレスに設定し,すべての応答メッセージを直接クライアントに送信し,フラッグシップ・ホストがクライアントに対して,そのパケットをサーバー・ホストにリダイレクトする必要があると知らせるものである点

(2)相違点についての検討
(2-1)引用発明における「リダイレクト」について
上記「第6」に摘記した甲第1号証に記載された事項によると,引用発明の「リダイレクト」に関して,次のようにいうことができる。
甲第1号証には,「イエローページ・サービス」が開示されるとともに,「インターネットの至る所」からのクライアントが「イエローページ・サービス」を含むローカルエリア・ネットワーク内のサーバーが提供するサービスを利用することができるようにするために,フラグシップ・ホストによってクライアントから送信されたパケットを転送して,ローカルエリア・ネットワーク内のサーバーにアクセスする方法が開示されている。
そして,「インターネットの至る所」からのクライアントは,フラグシップ・ホストに対して,特定の属性のセットを満足するサーバーを要求することはできないとされている。
他方,フラグシップ・ホストは,「インターネットの至る所」からのクライアントが求めるサービスを提供するローカルエリア・ネットワーク内の複数のサーバーの中から,負荷が一定レベル以下のものを選択してクライアントのアクセスを確立するために,イエローページ・サーバーに負荷の状況を定期的に問い合わせ,テーブルを更新するという機能を有するものである。
甲第1号証においては,以上のような転送メカニズムによるアクセスの方法を前提として,「フラグシップ・ホストが,クライアントに対して,そのパケットをサーバー・ホストにリダイレクトする」ようにできるとしている。この意味は,「インターネットの至る所」からのクライアントがイエローページ・サービス(メール・サービス)を利用したいと考えて,パケットを送信することによりイエローページ・サーバー(メール・サーバー)へのアクセスを要求した場合,これを受け取ったフラグシップ・ホストが,パケットを,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定して,直接アクセスするように命令するようにするということである。
そうすると,引用発明における「リダイレクト」は,ローカルエリア・ネットワーク内のサーバーが提供するイエローページ・サービスなどのサービスについて,「インターネットの至る所」からのクライアントが利用することができるようにする場合において,同ネットワーク内の負荷を調整するために,同ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものである。

(2-2)本件訂正発明1における「REDIRECTコマンド」について
本件訂正発明1の「REDIRECTコマンド」は,ディレクトリサーバーが,クライアントに対して返送するものであって,クライアントにおいて提供した記述子に対応するURLを含み,同コマンドを受信したクライアントにおいて,同URLを用いて情報を要求させるものであり,その結果同URLによって識別されたページがクライアント側で表示される,というものである。

(2-3)相違点についての判断
上記(2-1)及び(2-2)によると,本件訂正発明1の「REDIRECTコマンド」がクライアントにおいて情報ページを自動的に表示させるためのコマンドであって,ディレクトリサーバーによって行われるものであるのに対して,引用発明の「リダイレクト」は,ローカルエリア・ネットワーク内のサーバーに対する「インターネットの至る所」からのクライアントによるアクセスを確立する方法であって,このようなクライアントに対してローカルエリア・ネットワーク内の唯一のホストであるフラグシップ・ホストによって行われるものであるということができる。
そうすると,インターネットにおけるアクセスが行われたときに,要求のあった記述子に対応するURLへリダイレクトさせる本件訂正発明1と,ローカルエリア・ネットワーク内のサーバーとのアクセスを実現するためのフラグシップ・ホストによる「リダイレクト」を行うことは技術的課題も目的も異なるものであって,通常のインターネットにおいてディレクトリ・サーバーへアクセスする方法において,フラッグシップ・ホストによる「リダイレクト」の構成を採用するような動機付けは発生する余地がないし,甲第1号証にはそのような示唆もない。
また,甲第2号証(平成6年12月1日発行の雑誌「UNIX USER」)には「他のURLに変換?Redirect」との項目において,「Redirectに指定したパターンにマッチした場合は,指定したURLにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。URLは『http://ホスト名/』から書かなければならない。」(135頁左欄19?23行)と記載されており,ここに「Redirect」として紹介されている技術はいわゆる転送の技術であり,上記記載の技術が当業者に周知であったと認められ,フラッグシップホストを必要とする引用発明にこの技術を適用することによっても,フラグシップ・ホストは,パケットを,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定して,直接アクセスするように命令するようにしたにとどまり,本件訂正発明1のような構成とすることができないことは明らかである。
そして,引用発明においてはクライアントは,フラグシップ・ホストに対して,特定の属性のセットを満足するサーバーを要求することはできないとされていること,そもそも引用発明のフラッグシップ・ホストはパケットをサーバーにリダイレクトする必要があると知らせるように修正できるのであるが,クライアントが記述子を提供し,ディレクトリ・サーバが記述子をURLにマッピングして,クライアントに提供するような構成を備えていない。よって,クライアントがURLを用いて情報を提供するサーバーを特定することが周知であったとしても,上記周知技術を引用発明に適用しても本件訂正発明1のような構成を想到できないことは明らかである。
さらに,フラッグシップ・ホストとイエローページ・サーバーを同一サーバー,仮にフラッグシップ・サーバーと成すことを想定するとフラッグシップ・サーバーにアクセスするクライアントはリダイレクトにより所定のサーバーへアクセスできることになるが,そもそも引用発明は,インターネットの至る所からクライアントが,フラッグシップ・ホストによる転送メカニズムによってイエローページ・サーバーを利用することができるものであるから,引用発明において何のためにフラッグシップ・ホストとイエローページ・サーバーを同一のサーバー上に設けるかという動機付けが存在しない。

(2-4)平成22年4月19日付け上申書について
請求人は平成22年4月19日付け上申書において主に次の3点について主張している。
a.本件発明REDIRECTコマンドが意味する技術は優先日当時は公知であったこと。
b.httpリダイレクトは本件優先日当時すでに公知であったこと。
c.LANからインターネットへの容易想到性
そこで,上記a?cについて以下,検討する。

a,bについて
上記(2-3)に記載したとおり,甲第2号証(平成6年12月1日発行の雑誌「UNIX USER」)には「他のURLに変換?Redirect」との項目において,「Redirectに指定したパターンにマッチした場合は,指定したURLにリクエストがそのままフォワードされる。サーバーが引っ越したような場合に用いる。URLは『http://ホスト名/』から書かなければならない。」(135頁左欄19?23行)と記載されており,ここに「Redirect」として紹介されている技術はいわゆる転送の技術であり,上記記載の技術が当業者に周知であったと認められるが,フラッグシップ・ホストを必要とする引用発明にこの技術を適用することによっても,フラグシップ・ホストは,パケットを,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定し,直接アクセスするように命令するようにしたにとどまり,本件訂正発明1のような構成とすることができないことは明らかである。そして同様に,本件訂正発明1のREDIRECTコマンドあるいはhttpリダイレクトが意味する技術が優先日当時は公知であったとしても,フラグシップ・ホストは,パケットを,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定し,直接アクセスするように命令するようにできるだけであって,甲第1号証のリダイレクトに適用して本件訂正発明1のように構成できないことは明らかである。

c.について
LANとインターネットがTCP/IPによって統一的に相互に接続されていることを前提としても,引用発明は,フラグシップ・ホストは,パケットを,負荷の高くないイエローページ・サーバー(メール・サーバー)のアドレスを指定し,直接アクセスするように命令するにとどまり,クライアントが記述子を提供し,ディレクトリ・サーバが記述子をURLにマッピングし,ディレクトリ・サーバがREDIRECTコマンド中のURLをクライアントに返送する,本件訂正発明1の構成とは全く異にするものである。よって,甲第1号証に記載されたLANでのイエローページサービスに関する技術とインターネットからイエローページサービスを受けることに関する技術から構成を適宜抽出しても本件訂正発明1とするような動機はないから,本件訂正発明1を想到できないことは明らかである。
よって,上記上申書による主張も採用できない。

(3)請求項2?7に係る発明について
本件訂正発明2?7は,本件訂正発明1を引用してさらに限定するものであるから,本件訂正発明1が引用発明及び周知技術に基づいて,当業者が容易に発明することができたものではない以上,本件訂正発明2?7もまた当業者が容易に発明することができたものではない。

以上,他の相違点について検討するまでもなく,本件訂正発明1?7は引用発明に基づいて当業者が容易に発明をすることができたものということはできない。

第8 むすび
以上のとおりであるから,請求人が主張する無効理由によっては本件特許の請求項1?7に係る特許を無効とすることはできない。

審判に関する費用については,特許法第169条第2項で準用する民事訴訟法第61条の規定により,審判請求人が負担すべきものとする。

よって,結論のとおり審決する。
 
発明の名称 (54)【発明の名称】
インターネットサーバーのアクセス管理およびモニタシステム
(57)【特許請求の範囲】
【請求項1】
インターネットよりなるコンピュータネットワークを介したクライアントからサーバーシステムへの情報ページに対するアクセスを提供する方法であって、
前記クライアントにおいて単一の目標URLに対応する記述子を提供する段階と、
ディレクトリサーバーが、前記記述子を前記ディレクトリサーバーに存在する翻訳データベースを用いて前記URLにマッピングする段階と、
前記ディレクトリサーバーが、REDIRECTコマンド中の前記URLを前記クライアントに返送する段階と、
前記クライアントに前記URLを用いて情報を自動的に要求させる段階と、
前記URLにより識別されたページを前記クライアント側で表示する段階とを備えた情報ページに対するアクセス方法。
【請求項2】
請求項1において、前記記述子が電話番号を備えた情報ページに対するアクセス方法。
【請求項3】
請求項1において、前記記述子が記述項目を備えた情報ページに対するアクセス方法。
【請求項4】
請求項3において、前記記述項目が会社名を含む情報ページに対するアクセス方法。
【請求項5】
請求項3において、前記記述項目が製品名を含む情報ページに対するアクセス方法。
【請求項6】
請求項3において、前記記述項目が音声により識別される情報ページに対するアクセス方法。
【請求項7】
請求項1において、前記URLにより識別されたページが管理ページである情報ページに対するアクセス方法。
【発明の詳細な説明】
【0001】
【発明の属する技術分野】
本発明は、クライアントからサーバーへのネットワークを介したサービス要求を処理する方法に関する。
【0002】
【従来の技術および発明が解決しようとする課題】
1960年代後半に開始されたインターネットは、地球全体に拡がる多くの小規模ネットワークから成る広大なコンピュータネットワークである。インターネットは指数関数的に成長しており、個人から法人の範囲にわたる数百万のユーザが今や専用線およびダイヤルアップ接続を利用して世界中で日常的にインターネットを使用している。“ホスト”として知られるインターネット内で接続されたコンピュータまたはそのネットワークが、殆どあらゆる専門分野における情報を持つデータベースへの一般のアクセスを可能にしており、大学および政府から多くの民間組織にまでわたる事業により支持されている。
【0003】
インターネット上の情報は“サーバー”を介して一般が利用可能になる。サーバーはインターネットホスト上でそのホスト内に含まれるファイルまたはドキュメントを利用可能にするために作動しているシステムである。このようなファイルは代表的には、ローカルからホストにかけて、テープドライブまたは固定ディスクのような磁気記憶装置上で記憶される。インターネットサーバーは、ホスト上のファイルを要求するあらゆるコンピュータに情報を配布することができる。このような要求をするコンピュータは“クライアント”として知られ、これはインターネットに接続されたワークステーション、掲示板システムまたは家庭用パーソナルコンピュータ(PC)であり得る。TCP/IP(伝送制御プロトコル/インターネットプロトコル)は、インターネットの完全な使用を可能にするネットワークプロトコルの一種である。TCP/IPネットワーク上のすべてのコンピュータが独自のIDコードを必要とする。従って、インターネット上の各コンピュータまたはホストは、IP(インターネットプロトコル)番号またはアドレスとして知られた、ネットワークおよびコンピュータの名称に対応する独自の番号コードにより識別される。過去には、インターネットユーザは要求するファイルを指定するため、ホストコンピュータおよびホストの記憶装置内のディレクトリのパスを識別することによってのみ、そのリソースにアクセスすることができた。様々なナビゲーティングツールが、特定のホストアドレスを知ることなしにイターネット上のリソースを検索するためユーザを支援しているものの、これらのツールはインターネットに関する多分に技術的な知識を要する。
【0004】
ワールドワイドウェブ(ウェブ)は、IPアドレスまたは他の技術的知識なしで直観的にユーザがインターネットリソースをナビゲートすることを可能にするインターネット上の情報をアクセスする一方法である。ウェブは、代表的にはインターネットサーバーと通信するためのコマンドのセットを伝送することをユーザに要求するコマンドラインユーティリティなしで利用できる。代わりに、ウェブはコンピュータモニタに表示可能な数百数千の相互接続された“ページ”、またはドキュメントから構成される。ウェブページは特別なサーバーを動かしているホストにより供給される。これらのウェブサーバーを作動するソフトウェアは比較的簡単で、PCを含めた広範囲のコンピュータプラットフォーム上で利用可能である。同程度に利用可能なものはウェブ“ブラウザ(browser)”として知られ、クライアントシステム上の従来の非ウェブファイルと同様にウェブページを表示するために用いられるクライアントソフトウェアの一形式である。今日、ウェブサーバーを提供するインターネットホストは、月に300を超える割合で増加しており、インターネット通信の好ましい方法となりつつある。
【0005】
1991年に創設されたウェブは、“ハイパーテキスト”および“HTTP”(ハイパーテキスト転送プロトコル)として知られる転送方式の概念に基づいている。HTTPは主としてTCP/IP上で作動するよう設計され、標準的なインターネットセットアップを用い、そこでサーバーがデータを供給し、クライアントがそれを表示または処理する。情報転送のためのフォーマットの1つは、ハイパーテキスト記述言語(HTML)を用いてドキュメントを作成することである。HTMLページは、ページがどのように表示されるべきかを指示するフォーマットコードのほかに、標準的なテキストから構成される。ウェブクライアント、ブラウザはページを表示するためこれらのコードを読み取る。ハイパーテキスト協定およびワールドワイドウェブの関連機能は、本明細書で参考のため引用された、Payneらにより1994年10月24日に出願された米国特許出願第08/328,133号の付属書類に記述されている。
【0006】
各ウェブページはテキストに加えて画像および音声を含むことがある。特定のテキストの背後に隠れて、画像または音声は、“ハイパーテキストリンク”(“リンク”)として知られる、同一のサーバー内、またはインターネット内の他のコンピュータ上の他のページに対して接続されたものである。例えば、リンクは、下線が引かれるか第2の色彩で表示されることがある単語または文節として視覚的に表示することができる。各リンクはURL(Uniform Resource Locator)と呼ばれる特別な名前を用いて、あるウェブページに導かれている。URLは、ウェブブラウザが任意のウェブサーバー上に保持された任意のファイルに直接アクセスすることを可能にする。ユーザはまた、他のウェブページにジャンプするため、既知のURLをウェブページ上のコマンドラインに直接書き込むことにより指定することができる。
【0007】
URLネーミングシステムは3つの部分、すなわち、転送フォーマット、ファイルを保持する機械のホスト名、ファイルへのパスからなる。URLの一例は以下の通りである。
http://www.college.univ.edu/Adir/Bdir/Cdir/page.html
【0008】
ここに“http”は、転送プロトコルを表す。コロンおよび2本のスラッシュ(://)は、転送プロトコルをホスト名から離すために用いられる。“www”は要求されているファイルがウェブページであることを意味し、“www.college.univ.edu”はホスト名である。“/Adir/Bdir/Cdir”はホストマシン上のツリー構造、またはパスにおけるディレクトリ名の一セットである。“page.html”はファイルがHTMLで書き込まれていることを示すファイル名である。
【0009】
インターネットは、情報の交換が制限なしに無料で行われるオープンストラクチャーを維持する。しかしながら、インターネットに特有のフリーアクセス形式は、自己のインターネットサーバーの管理が必要である情報提供者に困難を呈している。例えば、特定の技術情報を自己のインターネットサーバー上で世界中の大規模なグループの仲間たちに利用可能とすることを希望するが、その情報の機密性が保たれなければならない研究組織を考えてみよう。各クライアントを識別する手段なしでは、その組織はネットワーク上で情報を機密的または選択的な形で与えることができないであろう。他の状況では、会社が極めて特殊なサービスの情報を自己のインターネットサーバー上でサービス契約または利用資格を有する顧客に対してのみ提供することを希望する場合がある。
【0010】
インターネットサーバーによるアクセス管理は少なくとも2つの理由で困難である。第1に、クライアントが遠隔のインターネットサーバー上のファイルに要求を送信すると、このメッセージは、宛て先ホストに到達するまで、インターネットを介して接続されたコンピュータのウェブにより通信経路選択または中継される。クライアントはそのメッセージがどのようにサーバーに到達するかを知る必要はない。同時に、サーバーは、クライアントが誰で、IPアドレスが何であるかを正確に知ることさえなく応答を行う。サーバーがそのクライアントを追跡するようにプログラミングされ得るものの、追跡のタスクはそれが不可能とまではいかないが、しばしば困難である。第2に、構内用のローカルエリアネットワーク(LAN)に対する望ましくない侵入を防ぐため、システムアドミニストレータはそのネットワーク内に、インターネット“ファイアウォール”のような様々なデータフロー制御メカニズムを実装する。インターネットファイアウォールは、ユーザがインターネットに匿名で到達することを可能にする一方、外部の侵入者がユーザのLANにアクセスすることを防止する。
【0011】
【発明の概要】
本発明は、ネットワークを介したクライアントからサーバーへのサービス要求を処理する方法に関する。とりわけ本発明は、ワールドワイドウェブ(ウェブ)のようなHTTP(ハイパーテキスト転送プロトコル)環境におけるクライアント要求を処理することに適する。最初に、本発明の基礎をなす基本技術について説明する。本基本技術の一構成は、サービス要求をクライアントからサーバーに送出し、セッション識別子(SID)をその要求、およびその後に続く要求セッション内でのクライアントからサーバーに対するサービス要求に対して付加することを含む。好ましい構成では、クライアントにより作られた最初のサービス要求におけるSIDをサーバーからクライアントに返送することを含む。有効なSIDは、ユーザが管理されたファイルにアクセスすることを可能にする認定(authorization)識別子を含むことがある。
【0012】
好ましい構成では、クライアント要求はUniform Resource Locator(URL)によりウェブブラウザから作られる。クライアント要求が管理されたファイルにSIDなしで送信されると、インターネットサーバーはクライアントをSID発行前に認定ルーチンにかけ、SIDは偽造から保護される。コンテンツサーバーはクライアントの要求を異なるホストに存在し得る認証サーバーに転送することにより認定ルーチンを開始する。転送された要求を受信すると、認証サーバーはクライアントに質問するため応答を返し、次いで資格を付与されたクライアントに対してSIDを発行する。新規のクライアントに対して、認証サーバーは新規の利用資格(アカウント)を開いてから後にSIDを発行することがある。有効なSIDは、代表的には、ユーザ識別子、アクセス可能なドメイン、キー識別子、日付のような満了時刻、ユーザコンピュータのIPアドレス、および秘密キーで暗号化されたSIDにおける他の項目すべての暗号ハッシュのような記憶された電子署名から構成される。認証サーバーは、次いでこのSIDが付加されたオリジナルURLから成る新しい要求を、REDIRECTによってクライアントに送出する。新しいURLにより形成された修正要求は、自動的にクライアントブラウザによりコンテンツサーバーに送出される。
【0013】
コンテンツサーバーがSIDを伴うURL要求を受信すると、コンテンツサーバーはSIDを伴うURLおよびユーザのIPアドレスをトランザクションログ(log)中に記録し、SIDを有効とする段階に進む。SIDがそのように有効になると、コンテンツサーバーは要求されたドキュメントをクライアントのウェブブラウザによる表示のために送信する。
【0014】
好ましい構成では、有効SIDは、クライアントが追加の認定を要求することなく保護ドメイン内にあるすべての管理ファイルにアクセスすることを可能にする。保護ドメインは、サービスプロバイダにより定義され、1つまたは複数のサーバー内における共通保護の管理ファイルの集まりである。
【0015】
クライアントが有効SIDで管理ウェブページをアクセスすると、そのページを見ているユーザが別のウェブページを見るためリンクを横断することを望む場合がある。この時、幾つかの可能性がある。ユーザはリンクを横断して同じパスにある別のページに達することができる。これは“相対リンク”と呼ばれる。相対リンクは同じドメイン内、或いは異なるドメインに対して作られることができる。クライアントコンピュータ上のブラウザは、古い管理ページを新しい管理ページと交換するため、現在のURLを書き直すことにより相対リンクを実行、つまりリンクの横断を行う。新しいURLは新しいページ名を除き、SIDを含む古いURLのすべての部分を保持する。相対リンクが同じ保護ドメインのページを示すものであれば、SIDは有効のままであり、要求は受理される。しかしながら、相対リンクが異なる保護ドメインのページを示すものであれば、SIDはもはや有効ではなく、クライアントは自動的にSIDを更新するため書換URLを認証サーバーに送出するよう転送される。更新された、または新しいSIDは、ユーザの資格が認定されれば、新しいドメインに対するアクセスを与える。
【0016】
ユーザは、リンクを横断して異なるパスにおけるドキュメントに達することも選択できる。これは“絶対リンク”と呼ばれる。絶対リンクを生成する際、SIDはブラウザにより上書きされる。好ましい構成では、コンテンツサーバーがドメイン内の管理ウェブページの各供与に際して、ページをフィルタリングして、現SIDをページ上の各絶対URLに含ませる。従って、ユーザが絶対リンクを横断することを選択すると、ブラウザは異なるパスにおけるページにそのSIDと共に送信される認定されたURLにより支援される。別の構成では、コンテンツサーバーは上記のようなフィルタリング手順なしで作動し、更新のために絶対URLを認証サーバーに転送することができる。
【0017】
絶対リンクはまた、異なるドメインにおける管理ファイルに導かれることがある。さらに、このような要求は新規のSIDを処理するために認証サーバーに転送される。管理されていないファイルに導かれる絶対リンクは、即時アクセスを可能にする。
【0018】
別の構成では、サーバーアクセス管理はクライアントブラウザをプログラミングして、この特定サーバーに対する各URLコールにおける使用のためにSIDまたは類似のタグを記憶することにより維持できる。しかしながら、この構成は、このような通信を取り扱うウェブに共通な標準ブラウザ形式に一般に適さない特殊なブラウザを要する。
【0019】
本基本技術の他の構成は、管理された、または管理されていない双方の様々なページに対するアクセスの頻度およびアクセス継続時間をモニタすることである。コンテンツサーバー内のトランザクションログは、ページをアクセスしたリンクシーケンスを含む、ページに対する各クライアントのアクセス履歴を保持する。さらに、コンテンツサーバーはクライアント要求を、共通のクライアントから繰り返された要求を除いてカウントすることがある。このような記録は、ユーザの要望、アクセスパターン、および顧客の統計的データとアクセスされたページとアクセスパターンとの関係ような重要なマーケティングフィードバックを提供する。
【0020】
本発明にかかるネットワークを介してクライアントからサーバーシステムへの情報ページアクセス提供方法は、前記クライアントに電話番号を提供する段階と、電話番号を翻訳データベースを用いて目標ページ識別子にマッピングする段階と、前記ページ識別子により記述された情報を前記サーバーシステムから要求する段階と、前記ページ識別子により識別されたページを前記クライアント側で表示する段階とを備える。
【0021】
構成の種々の新規な詳細および各部分の組み合わせを含む本発明の上記特徴およびその他の特徴は、添付図面を参照して説明され、請求の範囲に記載されている。本発明を具体化する特定の装置および方法は、例として示されており、本発明はこれに限定されないことが理解されよう。本発明の主要部および特徴は、本発明の範囲を逸脱することなく様々な数多くの実施形態で具体化することができる。
【0022】
【発明の実施の形態】
図を参照すると、図1はインターネットの線図である。インターネット10は、コンピュ-サーブまたはアメリカオンラインのようなインターネットプロバイダ16および情報システム(BBS)20によって所有されるシステムを含む数百万の相互接続されたコンピュ-タ12のネットワークである。個人または法人ユ-ザは、幾つかの方法でインターネットに対する接続を確立することができる。家庭用PC14上のユ-ザは、インターネットプロバイダ16を介してアカウントを購入することができる。モデム22を用い、PCユ-ザはインターネットプロバイダにダイヤルして高速モデム24に接続することができ、そのモデムが次いでインターネットに対する完全なサービス接続を行う。ユ-ザ18は、その顧客に対してインターネットゲートウェイ接続を提供するBBS20を介して、インターネットに対する幾分か制限された接続を行うことができる。
【0023】
図2Aは本発明の基本技術の好ましい処理の詳細を示すフローチャートであり、図4はブラウザによりクライアント側で表示されるサンプルウェブペ-ジの図である。ペ-ジは下線付きリンクテキスト412を含むテキスト404を備える。タイトルバー408およびURLバー402はそれぞれ、現在のウェブペ-ジのタイトルおよびURLを表示する。図4に示されるように、ペ-ジのタイトルは“CONTENT HOME PAGE”であり、それに対応するURLは“http://content.com/homepage”である。カーソル414がリンクテキスト412bの上に置かれた時、マウスをクリックすることで探し出されるペ-ジは、代表的にはそのリンクに対するURLを示すステータスバー406で識別される。この例では、指示リンク412bに対するURLが、“コンテンツ(content)”と呼ばれる商業コンテンツサーバーにおける“広告(advertisement)”と呼ばれるペ-ジに導かれることを、ステータスバー406は示す。リンクテキストをクリックすることで、ユ-ザはブラウザに図2Aの100におけるURL GET要求を生成させる。ブラウザはその要求をコンテンツサーバー120に送出し、コンテンツサーバー120は要求されたペ-ジが管理ドキュメントであるか否かを決定する最初の判断102によって処理する。その要求が未管理ペ-ジに導かれる場合、この例の“広告”ペ-ジにおけるように、コンテンツサーバーはURLおよびIPアドレスを入手できる範囲でトランザクションログ114に記録する。コンテンツサーバーは次いで、要求されたペ-ジをユ-ザコンピュ-タ上に表示するためブラウザに送信する(116)。
【0024】
その要求が管理ペ-ジに導かれる場合、コンテンツサーバーはURLがSIDを備えるか否かを決定する(104)。例えば、URLは、SIDを必要とする“http://content.com/report”のような管理ペ-ジ名“リポート(report)”に導かれる。SIDが存在しない場合、コンテンツサーバーは“REDIRECT”応答122をブラウザ100に送信し、ユ-ザの初期要求を認証サーバー200に転送して有効SIDを入手する。認証処理の詳細は図2Bに説明されており、後に論議されるが、処理結果は認証サーバーからクライアントに提供されるSIDとなる。上記の例では、SIDが付加された修正URLは、“http://content.com/〔SID〕/report”となり得る。好ましいSIDは、1文字当たり6ビットの96ビットSIDデータをコード化する16文字ASCII文字列である。これは32ビット電子署名、1時間単位の16ビット満了日付、キー管理に用いられる2ビットキー識別子、現SIDがアクセスを認定する情報ファイルセットを備える8ビットドメイン、および22ビットユーザ識別子を含む。残りのビットは拡張のため蓄えられる。電子署名は、認証サーバーとコンテンツサーバーにより共有されている秘密キーにより暗号化されているSIDおよび認定IPアドレスにおける残留項目を用いた暗号ハッシュである。
【0025】
初期GET URLがSIDを含む場合、コンテンツサーバーは、要求が現ドメイン内のページに導かれるか否かを決定する(106)。SIDを有する要求が異なるドメインの管理ページへ導かれる場合、SIDはもはや有効ではなく、ユーザは認証サーバーに再度導かれる(122)。
【0026】
要求が現ドメイン内の管理ページに対するものである場合、コンテンツサーバーはSIDを伴う要求URL、およびユーザIPアドレスをトランザクションログ108に記録するように手順を進める。コンテンツサーバーは次いでSIDを有効化する(110)。このような有効化は次の点検リストを含む。(1)SIDの電子署名が、認証サーバーとコンテンツサーバーにより共有されている秘密キーを使用して、SIDおよび認定IPアドレスにおける残留項目から計算された電子署名と比較される。(2)SIDのドメインフィールドが、認定されたドメイン内にあることを確認するため点検される。(3)SIDのEXPフィールドが現在時刻よりも後であることを確認するため点検される。
【0027】
有効性が認められると、コンテンツサーバーは、送出されるページをサーバーに含まれる絶対URLリンク、すなわち、異なるコンテンツサーバーにおける管理ドキュメントに導かれる任意リンクについて探索する(112)。コンテンツサーバーは、各絶対URLを現SIDとともに増加し、多数のコンテンツサーバーにわたる認証されたアクセスを容易にする。要求されたページは、処理されたとおりの形で、次いで表示のためクライアントブラウザに伝送される。要求されたウェブページを見ているユーザは、そのページ上の任意リンクを横断して全シーケンスを再度誘発するように選択することができる(100)。
【0028】
図2Bは認証処理の詳細を説明する。コンテンツサーバーはクライアントを認証サーバーへ再度導くことがある。REDIRECT URLは以下の形をとり得る。
“http://auth.com/authenticate?domain=〔domain〕&URL=http://cotent.com/report”
【0029】
URLは認証を要求し、ドメインおよび初期URLを指定する。REDIRECTに対する応答で、クライアントブラウザは自動的にGET要求を、用意されたURLと共に送信する。
【0030】
コンテンツサーバーがクライアントを認証サーバー200に再度導く時は何時でも、認証サーバーは、それが承認されたコンテンツサーバーに対するものであることを確認し、要求されたアクセスに対して必要な認証のレベルを決定することにより、認定処理を開始する(210)。このレベルに応じて、サーバーはユーザに証明を要求することができる(212)。要求が低レベルドキュメントに対するものである場合、認証サーバーは適切なSIDを直ちに発行し(228)、証明点検手順に移る。ドキュメントが証明を要する場合、認証サーバーは、“CHALLENGE”応答を送信して、クライアントブラウザがユーザに確認を促すよう仕向ける(214)。好ましい確認問合せは、代表的にはユーザ名およびパスワードの要求から成る。ユーザがパスワードを与えることができない場合、そのアクセスは拒否される。ブラウザは与えられた情報から認定ヘッダ300を形成し、認定ヘッダと共に最終URLを用いてGET要求を認証サーバーに再度送信する。例えば、このようなGET要求のURLは次の形をとり得る。
“http://auth.com/authenticate?domain=〔domain〕&URL=http://cotent.com/report”および認定ヘッダは“AUTHORIZE:〔authorization〕”であり得る。
【0031】
GET要求を受信次第、要求ドキュメントにアクセスすることをユーザが認定されているか否かを決定するため(218)、認証サーバーは利用資格データベースに問い合わせる(216)。好ましい利用資格データベースは、ユーザの年齢、住所、趣味、または職業のような、コンテンツサーバーが後に使用するユーザの統計的データ情報のほかに、クライアントのIPアドレスおよびパスワードのような識別目的のための情報を含むユーザのプロファイルを包含することがある。ユーザが認定されると、SIDが前に説明されたように生成される(228)。ユーザが認定されない場合、認証サーバーは、ユーザが新しい利用資格に対する資格を有するか否かを点検する。ユーザが新しい利用資格を開く資格を持たない場合、アクセスを拒否するページがクライアントブラウザ100に伝送される(222)。ユーザが資格を有する場合、新しいユーザには図5に図示されたようなリアルタイムオンライン登録を開始する書式ページが伝送される(224)。この書式は、例えば、ユーザの個人情報およびクレジット照合を要する。ブラウザは認証サーバーに対する“POST”メッセージとして空白502にユーザにより記入されたデータを伝送することができる。POSTメッセージは書式のコンテンツをURLの一部としてではなく、データ部でサーバーに送信されるようにする。新しいユーザにより記入された登録書式が有効になると(226)、適切なSIDが生成される(228)。登録が有効でない場合、アクセスは再度拒否される(222)。
【0032】
認定ユーザに対するSIDが、コンテンツサーバー上の管理ページに導かれたオリジナルURLに付加される(“タグ付け”)(230)。認証サーバーは次いでREDIRECT応答をタグ付きURLに基づき、クライアントブラウザ100に伝送する(232)。“http://auth.com/〔SID〕/report”のような修正されたURLが、自動的にコンテンツサーバー120に送出される。
【0033】
図3は、本発明の基本技術のアクセス管理およびモニタ方法を含む代表的なクライアント対サーバーの取り交わしを図示する。段階1において、ブラウザを作動しているクライアント50は、ネットワークを介して未管理ページ(UCP)に対するGET要求を伝送する。例えば、ユーザは“content.com”がサーバー名および“広告(advertisement)”が未管理ページ名である、URL“http:content.com/advertisement”を伝送することで、広告ページを要求することができる。段階2では、コンテンツサーバー52はGET要求を処理して要求ページ、“広告(advertisement)”を伝送する。コンテンツサーバーはまた、URL、クライアントのIPアドレス、および現在時刻を記録することでGET要求をトランザクションデータベース56に記録する。
【0034】
段階3では、クライアントマシン上のユーザが、管理ページ(CP)に導かれた広告ページ中のリンクを横断するように選択できる。例えば、広告ページは“リポート(report)”と呼ばれる管理ページに対するリンクを含むことがある。このリンクを選択すると、クライアントブラウザ50はGET要求をリポートファイル“http://content.com/report”が関連するURLを介して送出する。コンテンツサーバー52は、要求が管理ページに対するものであること、およびURLがSIDを含んでいないことを決定する。段階4では、コンテンツサーバーはREDIRECT応答をクライアントに伝送し、さらに、段階5では、ブラウザは自動的にREDIRECT URLを認証サーバー54に送信する。認証サーバーに送信されたREDIRECT URLは下記の文字列を含み得る。
“http://auth.com/authenticate?domain=〔domain〕&URL=http://cotent.com/report”
【0035】
認証サーバーはREDIRECTを処理して、認定のためにユーザの確認(CRED)が必要か否かを決定する。段階6では、認証サーバーは“CHALLENGE”応答をクライアントに伝送する。前述のように、代表的な確認はユーザ名とパスワードから成る。確認情報に基づく認定ヘッダは、次いでクライアントブラウザにより認証サーバーへ送信される。例えば、このような認定ヘッダを有するGET URLは“http://auth.com/authenticate?domain=〔domain〕&URL=http://cotent.com/report”であり、認定ヘッダは“AUTHORIZE:〔authorization〕”であり得る。認証サーバーはGET要求を利用資格データベース58を点検することで処理する。有効な利用資格がユーザに対して存在する場合、SIDが発行され、それが管理ページ“リポート(report)”およびドメイン内の他のすべてのページに対するアクセスを認定する。
【0036】
前述のように、好ましいSIDはユーザ識別子、現在のドメイン、キー識別子、満了日時、クライアントのIPアドレス、および記憶された電子署名をコード化するコンパクトなASCII文字列から構成される。段階8では、認証サーバーはクライアントをタグ付きURL、“http://cotent.com/〔SID〕/report”に再度導く。段階9では、タグ付きURLは自動的にブラウザによりコンテンツサーバーにGET要求として送信される。コンテンツサーバーはタグ付きURL、クライアントのIPアドレス、および現在時刻を記録することでGET要求をトランザクションデータベース56に記録する。段階10では、コンテンツサーバーが、SIDの有効性を確認次第、要求された管理ページ“リポート(report)”をクライアントブラウザ上の表示のため伝送する。
【0037】
本基本技術によれば、コンテンツサーバーはトランザクションログ56に記載された記録を定期的に評価して、関連コンテンツサーバーに対するアクセスの頻度とアクセス継続時間を決定する。サーバーは、格付け目的で異なるページ上の情報のメリットを決定するため、共通クライアントからの反復要求を除いて、特定ページに対する要求を計数する。反復要求を除外することで、システムは“投票箱に詰め込む”ことを試みるユーザによるひずみを避ける。一構成において、定まった時間周期内に入る共通クライアントによる反復要求を除外するため、共通クライアントによる反復要求の時間間隔が測定される。
【0038】
これに加え、サーバーは任意の与えられた時間に、クライアント対サーバーのセッション内のアクセス履歴を追跡することができる。このような履歴プロファイルはサービスプロバイダに、リンク横断頻度およびユーザにより辿られるリンク経路について情報を与える。このプロファイルは、特定ユーザID(UID)を含むトランザクションのみを選択するため、1つまたは複数のサーバーからのトランザクションログをフィルタリングすることで作成される。これらのログにおける特定されたユーザからの要求に対応する2つの連続したエントリであるAおよびBは、この特定されたユーザにより行われたドキュメントAからドキュメントBへのリンク横断を表す。この情報は特定ページに対して最も人気があるリンクを識別し、より直接的なアクセスを提供するに何処に新しいリンクを挿入すべきかを示唆するため用いられる。別の構成では、商業ページ内で行われた製品の購入につながる横断リンクを決定するためアクセス履歴が評価される。この情報は、例えば、広告ページから製品ページへのリンク横断数、または広告を含む経路から生ずる購入の計数に基づき、広告料の要求に用いることができる。この構成では、サーバーは特定ページ、リンク、またはリンクの経路から生じた販売件数を測定することで広告の効果を計ることができる。本システムは、広告ページから生じた販売件数に基づき、広告ページに対する料金を商業者に請求するように構成することができる。
【0039】
本発明の別の基本技術によれば、図2Bの認証サーバー200のような第2のサーバーが利用資格データベース216から事前に設定されたユーザプロファイルをアクセスすることができ、このようなプロファイルに基づく情報をSIDのユーザ識別子フィールドに含ませることができる。好ましい構成では、SIDのユーザ識別子フィールドに基づき個人化されたコンテンツを含むように、ユーザ要求ページをカスタマイズするためにコンテンツサーバーはこのようなSIDを用いることができる。
【0040】
本発明の別の基本技術では、ユーザは予約講読を介して雑誌または刊行物を含むサーバーのドメインに対するアクセスを得ることができる。このような状況では、ユーザはインターネットを介するオンラインドキュメントに対してアクセスを得ることで事前に予約講読権を購入することができる。ユーザは認定識別子が好ましくはセッション識別子に埋設されている上述のような認定手順を介して、インターネット上で予約講読ドキュメントに対するアクセスを得る。別の構成では、前払予約講読に頼るのではなく、ユーザがインターネットを介して特定のドキュメントにアクセスする度に料金を請求されることが可能になる。この場合、サービスに対する料金が請求されるためには、ユーザが完全に識別される限り認定は要求されない。ユーザの識別は、最も適切には上記で説明されたセッション識別子に埋設される。
【0041】
本発明の一構成では、商業者のサービスにアクセスするためにユーザが従来の電話番号、またはその他の識別子を利用できるようにする便が設けられている。これらの商業者サービスはSIDを用いて任意に保護され得る。好ましい実施形態では、図6に示されるように、ウェブブラウザクライアント601がユーザからの電話番号を受理するため“ダイヤル”アイコン上をクリックし、キーボードを介して電話番号を入力することのような“ダイヤル”コマンドを提供する。ブラウザは次いでNUMBERがユーザにより指定された電話番号、またはその他の識別子である、書式“http://directory.net/NUMBER”のURLを構成する。ブラウザは次いでこのURLにより指定されたドキュメントのGETを行い、ディレクトリサーバー602に連絡し、メッセージ1で要求されたNUMBERを送信する。
【0042】
別の実施形態では、従来のブラウザを備えた形で、クライアント601が“ダイヤル”コマンドの場所に電話番号、またはその他の識別子を入れることを促すディレクトリサーバー602により提供された書式ページを用いる。メッセージ1はこの書式ページにより指定されたURLに対するPOSTメッセージである。
【0043】
一旦NUMBERがディレクトリサーバー602により受信されると、ディレクトリサーバーはデータベース604を用いて、NUMBERに対応するサービスを実施する商業サーバーおよびドキュメントを記述する目標URLにNUMBERを翻訳する。この翻訳は番号の句読法を無視する可能性があり、従って埋め込まれた括弧またはダッシュは意味を持たない。
【0044】
別の実施形態では、数字以外の識別子を設けることができる。例えば、ユーザは会社名または製品名を不正確なつづりで記入することがある。このような場合“soundex”または他の音声マッピングが同じ目標URLに対するマップと類似して響く語を許容するため用いることができる。また、製品名または内線と組み合わせた電話番号のような複数の識別子も使用可能である。
【0045】
メッセージ2では、ディレクトリサーバー602がREDIRECTをクライアント601に送信し、これには、データベース604から演算されたNUMBERに対する目標URLが記述されている。クライアントブラウザ601は続いて自動的にメッセージ3を送信し、このURLのコンテンツをGETする。商業者サーバー603はメッセージ4におけるこの情報を返送する。サーバー602はウェブページをクライアントに返送して、要求されたドキュメントに対して適切なリンクを提供する。しかしながら、サーバー602が最終的なURLに対する翻訳を行い、ページよりはむしろREDIRECTをクライアント601に送信するため、メッセージ4のドキュメントは最初のダイヤル入力以上のユーザの行為なしで入手される。
【0046】
メッセージ3に含まれる目標URLは未管理ページに対する普通のURLである可能性、または管理ページを記述するURLである可能性がある。目標URLが管理ページを記述する場合、認証は前述のように実行される。また、目標URLは管理ページにアクセスする事前認定された手段を提供するSIDを含むURLを記述できる。
【0047】
“ダイヤル”コマンドおよびその実施の利点の中には、従来の電話番号および他の識別子と互換性を有する、インターネットにアクセスする改善された方法がある。商業者はコンタクト情報のインターネット特定書式を提供するための印刷物またはテレビ広告を変更する必要がなく、ユーザはURLについて知る必要がない。
【0048】
接触時に単独の商業者サーバーが異なる外部の“電話番号”、またはその他の識別子に対応する多数のサービスを提供することができる。例えば、ユーザが“航空便到着”番号にダイヤルした場合、到着ページに対するURLに導かれる可能性があり、一方、ユーザが“予約”番号にダイヤルした場合、予約ページに対するURLに導かれるであろう。“優先ゴールド”番号は最初にユーザをゴールドユーザズグループに属するユーザとして立証するであろう管理ページに導かれ、次いで“優先ゴールド”ページに対するアクセスを提供するであろう管理ページに導かれる可能性がある。未発表の“使節”番号は、ユーザの認証なしに“優先ゴールド”ページに対するアクセスを許すタグ付きURLに導かれる可能性がある。
【0049】
本発明は、この明細書に参照として組み入れられた、1994年10月24日に出願された米国特許出願第08/328,133号に提示されたようなネットワーク販売システムに対する特定の用途を有する。
【0050】
この特許文書の開示の一部は著作権保護の対象である以下の付属部分を構成するプログラムリストを含んでいる。この著作権者は特許開示内容の何者によるファクシミリ複製に対しても、それが特許商標局の特許ファイルまたは記録に現れるため異議を唱えるものではないが、さもない場合はいかなる場合にもすべての著作権を留保する。
【0051】
【数1】

【0052】
【数2】

【0053】
【数3】

【0054】
【数4】

【0055】
【数5】

【0056】
【数6】

【0057】
【数7】

【0058】
【数8】

【0059】
【数9】

【0060】
【数10】

【0061】
【数11】

【0062】
【数12】

【0063】
【数13】

【0064】
【数14】

【0065】
【数15】

【0066】
【数16】

【0067】
【数17】

【0068】
【数18】

【0069】
【数19】

【0070】
【数20】

【0071】
【数21】

【0072】
【数22】

【0073】
【数23】

【0074】
【数24】

【0075】
【数25】

【0076】
【数26】

【0077】
【数27】

【0078】
【数28】

【0079】
【数29】

【0080】
【数30】

【0081】
【数31】

【0082】
【数32】

【0083】
【数33】

【0084】
〔均等物〕
当業者は、必要以上の実験を行わなくとも、ここに記載された本発明の特定の実施形態に対する多くの均等物を相当するであろう。これらすべての均等物は請求の範囲に包含される。
【図面の簡単な説明】
【図1】インターネット運用を示す線図である。
【図2A】インターネットサーバーアクセス管理およびモニタの好ましい方法を説明するフローチャートである。
【図2B】認証プロセスの詳細を説明する関連フローチャートである。
【図3】本発明が基礎とする基本技術によるアクセス管理およびモニタ方法を含むクライアント対サーバーの取り交わしセッションの例を示す線図である。
【図4】ワールドワイドウェブページの例を示す図である。
【図5】認定書式ページを示す図である。
【図6】電話番号のURLに対する翻訳の詳細を示す線図である。
【符号の説明】
601…クライアント、602…ディレクトリサーバー、603…商業者サーバー、604…データベース。
 
訂正の要旨 審決(決定)の【理由】欄参照。
審理終結日 2010-07-27 
結審通知日 2008-06-09 
審決日 2008-06-26 
出願番号 特願2001-208296(P2001-208296)
審決分類 P 1 113・ 832- YA (G06F)
P 1 113・ 536- YA (G06F)
P 1 113・ 121- YA (G06F)
P 1 113・ 537- YA (G06F)
最終処分 不成立  
前審関与審査官 須藤 竜也鈴木 匡明宮司 卓佳  
特許庁審判長 江嶋 清仁
特許庁審判官 中野 裕二
江口 能弘
登録日 2006-01-20 
登録番号 特許第3762882号(P3762882)
発明の名称 インターネットサーバーのアクセス管理およびモニタシステム  
代理人 西島 孝喜  
代理人 西島 孝喜  
代理人 原 慎一郎  
代理人 熊倉 禎男  
代理人 北村 行夫  
代理人 大塚 文昭  
代理人 奥村 直樹  
代理人 中村 佳正  
代理人 飯田 圭  
代理人 須田 洋之  
代理人 須田 洋之  
代理人 熊倉 禎男  
代理人 亀井 弘泰  
代理人 飯田 圭  
代理人 奥村 直樹  
代理人 大塚 文昭  
代理人 中村 佳正  
代理人 樋口 盛之助  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ