【事件の表示】
　平成１０年特許願第５３７６３５号「ネットワーク・コンピュータに関する汎用のユーザ認証方法」拒絶査定不服審判事件〔平成１０年　９月　３日国際公開、ＷＯ９８／３８７５９、平成１２年　６月２７日国内公表、特表２０００−５０８１５３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、１９９８年１月６日（パリ条約による優先権主張外国庁受理１９９７年２月１４日、米国）を国際出願日とする出願であって、平成１４年６月１０日付けで拒絶の理由が通知され、同年１２月１７日付けで手続補正がなされたものの、平成１５年６月２３日付けで拒絶の査定がなされた。その後、同年９月２９日に拒絶査定不服審判請求がなされたものである。
   
２．本願発明
　本願の特許請求の範囲請求項１に係る発明は、平成１４年１２月１７日付け手続補正書によって補正された明細書又は図面の記載からみて、特許請求の範囲請求項１に記載された次のとおりのものである。
「ユーザ認証システムを有するネットワークにして、
　複数のユーザ・モードの下でプログラムを実行するオペレーティング・システムを有するウェブ・サーバと、
　プログラム実行リクエストと共にユーザ情報を前記ウェブ・サーバに処理依頼する機構を有するウェブ・クライアントと、
　最初はデフォルト・ユーザ・モードの下で実行され、前記ユーザ情報を検査する機能、前記ウェブ・サーバにおける前記オペレーティング・システムに非デフォルト・ユーザ・モードの下で該プログラムを動的に実行させる機能、及び前記ウェブ・クライアントにユーザ情報を戻す機能を前記ウェブ・クライアントに実現させるプログラムと、
　を含むネットワーク。」
　　
３．引用文献
　原査定の拒絶の理由に引用された安東一真，「進化するイントラネットアクセス管理で作るセキュリティ・インフラ　パスワード管理から始める」，日経コミュニケーション，１９９６年９月１６日，第２３０号，ｐ．１００−ｐ．１０３（以下、「引用文献１」という。）には、図面と共に以下の事項が記載されている。
　
Ａ．「手軽なパスワードを使ってＷＷＷサーバーのアクセス制御を行える製品は、３種類に分類できる（表２−１）。
（中略）
ＷＷＷブラウザは任意の製品でよい
　どのタイプの製品も、クライアントとなるＷＷＷブラウザには、フリー・ソフトや異なるベンダーの製品を利用できる。ブラウザ−ＷＷＷサーバー間の通信プロトコルHTTP1.0が備える「ベーシック認証」と呼ぶ標準技術を使って、ユーザーを認証しているからだ。
　ベーシック認証では、アクセス制限のあるWebページにアクセスがあると、ＷＷＷサーバーは、ブラウザに対してユーザーIDとパスワードを要求する（図２−１）。ブラウザは、ユーザーに対してユーザーIDとパスワードの入力を促し（図２−１の(4)）、それをＷＷＷサーバーに送信する。ＷＷＷサーバーはパスワードが正しければ、所望のWebページをブラウザに送信する。
（中略）
ネットワークＯＳ独自の仕組みを使う
　従来のＷＷＷサーバーでは、ユーザーIDとパスワードの管理、アクセス権の設定（読み出し、CGIプログラムの実行など）は、サーバーごとに行う必要があった。」（１００頁中欄１行〜１０１頁左欄３５行）
　
　上記Ａの記載において、ＷＷＷサーバーはオペレーテイング・システムを有し、プログラムがオペレーテイング・システムの制御の下で実行されることは自明のことである。
　また、ＷＷＷブラウザから送信されてくるパスワードが正しければWebページをＷＷＷブラウザに送信しているから、ここではパスワードの検証処理とWebページの送信処理がなされており、この検証機能と送信機能がプログラムによって実現されていることも自明のことである。そして、ここでのパスワードの検証は、ＷＷＷブラウザから送信されてくるユーザーＩＤとパスワードに基づいていることも明らかである。
　
　以上の記載から、引用文献１にはブラウザ−ＷＷＷサーバー間の通信プロトコルが備える「ベーシック認証」を使ってユーザー認証を行うものとして次の発明（以下、「引用発明」という。）が記載されている。
　
　クライアントとなるＷＷＷブラウザと要求されたWebページを送信するWWWサーバーからなるシステムにおけるユーザー認証方式であって、
　プログラムを実行するオペレーテイング・システムを有するＷＷＷサーバーと、
　ＷＷＷサーバーにWebページのアクセスを依頼するＷＷＷブラウザと、
　ＷＷＷブラウザがＷＷＷサーバーに対しアクセス制限のあるWebページにアクセスすると、ＷＷＷサーバーはＷＷＷブラウザに対してユーザーＩＤとパスワードを要求し、WWWブラウザから送信されてくるユーザーＩＤとパスワードに基づく検証機能と、要求されたWebページをＷＷＷブラウザに送信する機能をＷＷＷサーバーに実現させるプログラムと、
　を含むシステムにおけるユーザー認証方式
　
　また、原査定の拒絶の理由に引用された　Ｊｏｎ　Ｕｄｅｌｌ，「ＢＹＴＥ誌のＩｎｔｅｒｎｅｔプロジェクト第１２回　　Ｗｅｂ会議を成功させる方法」，日経バイト，１９９６年７月２２日，第１４５号，ｐ．３３５−ｐ．３３９（以下、「引用文献２」という。）には、図面と共に以下の事項が記載されている。
　
Ｂ．「課題３：ステートレスのＨＴＴＰ
　セッションごとにではなく、メッセージごとにログインを強制するような会議システムにはすぐに我慢できなくなるだろう。しかし、Ｗｅｂ会議のネイテイィブなインプリメンテーションでは、このようにしか動作できないだろう。ＨＴＴＰの大きな成功はコネクションレス（ステートレス）モードの操作に多くを負っている。Internetの大部分で遅延が大きく、忠実さもひどいにもかかわらず、Ｗｅｂトラフィックがかなりうまく流れるのはこのためだ。しかしＨＴＴＰがステートレスであることは、会議のような一貫したユーザ・アイデンテイィティを必要とするアプリケーションを非常に複雑にする。
　この問題の伝統的な解決策は、ＣＧＩを呼び出すごとにユーザの信用証明を再送することだ。Net.ThreadとWebCrossingは、いずれもこの方法で動作する。これらのシステムはユーザが目にする全ＨＴＭＬページを動的に生成するため、信用証明を各ページにある＜form＞タグのaction＝属性に挿入することができる。隠しフィールドを使っても同じ結果を達成することができる（Virtual Press Roomアプリケーションにおいて隠しフィールドでどのように状態を維持しているかは本誌１９９６年２月号ＢＹＴＥ特約「発表資料をＷＷＷサーバで受け取る」参照））。」（３３６ページ右欄３２行〜３３７ページ中欄１１行）
　
Ｃ．「クッキー・ベースの認証を用いるシステムでは、普通は動的にページを生成する。これは、ＣＧＩコマンド・ライン上（または隠しフォーム変数内）で信用証明を送るシステムと同様である。」（３３７ページ右欄２９行〜３３行）
　
Ｄ．「図１　ＢＹＴＥサイトで立ち上げたＷｅｂ会議
　Netscapeの画面におけるLocationの欄の記述（？Ｕｓｅｒ＝・・・・・・・・）及び「HTTPがステートレスであることを補うために、Ｗｅｂ会議アプリケーションはユーザのアイデンテイィティやプリファレンスなどセッション情報を継続的に再送し続ける。」との図面における記載。」（３３７ページ図１）
　
４．対比
　本願発明と引用発明とを対比すると、
　引用発明における「ＷＷＷブラウザ」「ＷＷＷサーバー」「ユーザーＩＤとパスワード」と、本願発明における「ウェブ・クライアント」「ウェブ・サーバ」「ユーザ情報」に相当する。
　引用発明では、「Webページのアクセスを依頼」されたＷＷＷサーバーが「要求されたWebページをＷＷＷブラウザに送信する機能をＷＷＷサーバーに実現させるプログラム」を実行することにより、WebページをＷＷＷブラウザに送信しているから、引用発明の「Webページのアクセスを依頼」は、本願発明の「プログラム実行リクエスト」に相当する。また、プログラムの実行はオペレーテイング・システムの下で動的に行われるものであるから、引用発明において「要求されたWebページをＷＷＷブラウザに送信する機能」は、本願発明における「オペレーティング・システムの下で該プログラムを動的に実行させる機能」と実質的に同等のものである。
　また、引用発明の「ＷＷＷブラウザとＷＷＷサーバーからなるシステムにおけるユーザー認証方式」は、ネットワークを介するシステムの認証方式であるから、本願発明の「ユーザ認証システムを有するネットワーク」と言って良いものである。
　
  よって、本願発明と引用発明とは、
　
　ユーザ認証システムを有するネットワークにして、
　プログラムを実行するオペレーティング・システムを有するウェブ・サーバと、
　プログラム実行リクエストを前記ウェブ・サーバに処理依頼する機構を有するウェブ・クライアントと、
　ユーザ情報を検査する機能、前記ウェブ・サーバにおける前記オペレーティング・システムに該プログラムを動的に実行させる機能を前記ウェブ・クライアントに実現させるプログラムと、
　を含むネットワーク
　
である点で一致し、次の点で相違する。
　
相違点１
　本願発明では、プログラムが複数のユーザ・モードの下で実行されるものであり、最初はデフォルト・ユーザ・モードの下でユーザ情報を検査する機能と非デフォルト・ユーザ・モードの下で該プログラムを動的に実行させる機能を有するものであるのに対し、引用発明ではユーザ情報を検査する機能と該プログラムを動的に実行させる機能がどのようなモードで行われるか不明である点
　
相違点２
　本願発明ではプログラム実行リクエストと共にユーザ情報がウェブ・サーバに送られるものであるのに対し、引用発明ではプログラム実行リクエストがアクセス制限のあるWebページへのアクセスである時にWebサーバの要求に基づいてユーザ情報がウェブ・サーバに送られるものである点
　
相違点３
　本願発明では、プログラムがウェブ・クライアントにユーザ情報を戻す機能を有するものであるに対し、引用発明ではユーザ情報を戻しているかどうか定かでない点
　
５．相違点についての検討
相違点１について
　プログラムの実行モードについて、情報処理学会編、「新版　情報処理ハンドブック」平成７年１１月２５日第１版第１刷、オーム社、ｐ５０７には、次のような記載がある。
「（ａ）特権モード　　このモードで走るプロセスに、システムのすべての対象からなる定義域を与える。スーパバイザモード（supervisor　mode）とかマスタモード（master　mode）ともいう。これに対し、使用できる対象を限定した定義域を与えるモードを使用者モード（user　mode）とかスレーブモード（slave　mode）という。特権モードはほとんどの計算機に実装されている。通常、オペレーテイングシステムの核および核に近いプロセスを特権モードで実行し、そのほかのプロセスを使用者モードで実行する。」
　オペレーテイングシステム（一種のプログラム）の実行においては、核に近いプロセスは特権モードで実行し、そのほかのプロセスは使用者モードで実行しており、実行するプロセスに応じてモードを異ならせている。引用発明においてＷＷＷサーバがＷＷＷブラウザの要求に基づいて実行するアクセス制限のあるWebページへのアクセスでは、ユーザ認証を行う過程と要求されたWebページをアクセスしてWWWブラウザに送信する過程がある。ユーザ認証はシステムの中核に近い処理であり、WebページのＷＷＷブラウザへの送信はアプリケーションの実行と言ってよいものであるから、上述したオペレーテイングシステムの実行の場合と同様に、両者を異なるモードで行わせることは容易に為し得ることである。そしてその場合、引用発明においても最初に行うのはユーザ認証処理であり、ユーザ認証結果に基づいてWebページの送信を行っているから、ユーザ認証の方をデフォルト・ユーザ・モード、Webページの送信の方を非デフォルト・ユーザ・モードと称することも格別のことではない。
　
相違点２について
　引用文献２に、「ＣＧＩを呼び出すごとにユーザの信用証明を再送する」「ＣＧＩコマンド・ライン上（または隠しフォーム変数内）で信用証明を送るシステム」と記載されているように、ユーザ認証を必要とするシステムではサーバに対する要求と共に信用情報を送ることも通常の形態である。
　引用発明では、アクセス制限のあるWebページにアクセスするときだけユーザ認証を行うものであるが、これはアクセス制限のあるWebページとアクセス制限のないWebページが混在するシステムを前提としているからであって、常にユーザ認証を必要とするシステムも引用文献２に示されるようにありふれたものであり、その場合、要求と共に信用情報を送っているからプログラム実行リクエストと共にユーザ情報を送るようにすることは格別のことではない。
　
相違点３について
　引用文献２の図１に示される Netscapeの画面のLocationの欄には、？Ｕｓｅｒ＝・・・・・・・・としてユーザに関する情報が含まれており、また、その説明にも「ユーザのアイデンティティやプリファレンスなどセッション情報を継続的に再送し続ける」と記載されているから、クライアントとサーバの間でユーザに関する情報を双方向で送っている点が見て取れる。従って、引用発明に引用文献２に示されるリクエストと共にユーザ情報を送る技術を適用したときには必然的にユーザ情報は双方向で送られることになるから、この相違点を格別のことということはできない。
　
６．むすび
　したがって、本願発明は、引用文献１，２に記載された発明および当該分野の周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。