【事件の表示】
　平成　９年特許願第３４６４０１号「コンピュータシステム及び方法」拒絶査定不服審判事件〔平成１０年　９月１４日出願公開、特開平１０−２４７１８３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年１２月１６日（パリ条約による優先権主張１９９６年１２月２３日、米国）の出願であって、平成１５年６月５日に手続補正がなされ、平成１６年３月２３日付けで拒絶査定がなされ、これに対し、同年６月１８日に審判請求及び手続補正がなされたものである。
　
２．平成１６年６月１８日付け手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成１８年６月１８日付け手続補正（以下「本件補正」という。）を却下する。
　
［理由］
（１）本願補正発明
　本件補正後の請求項１乃至２７に係る発明のそれぞれは、本件補正前の請求項１乃至２７に係る発明のそれぞれに対応したものであって、その記載からして、本件補正は、補正前の請求項１乃至６、８乃至１０に係る発明を特定するために必要な事項である「識別子機構」を「複数のウェブ・ブラウザのそれぞれのための識別子を生成し、ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する識別子機構」に限定するものであるから、本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的としたものに該当する。
　
　そして、補正後の請求項１に係る発明（以下、「本願補正発明」という。）は、本件補正後の特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
　
「少ないとも１つの中央処理装置（ＣＰＵ）と、
　ＣＰＵに結合されたメモリと、
　メモリ内に常駐し、少なくとも１つのＣＰＵによって実行され、共通ユーザ・インターフェースを介して複数のウェブ・ブラウザへまたはこれらからデータを送受する能力を有し、データの識別及び追跡のために、複数のウェブ・ブラウザのそれぞれのための識別子を生成し、ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する識別子機構を使用する、トランザクション・サポート機構とを含む、ワールド・ワイド・ウェブ上で複数のウェブ・ブラウザと複数のソフトウェア・アプリケーションとの間で通信するための共通ユーザ・インターフェースを提供するコンピュータ・システム。」
　
　ここで、「少ないとも」は、「少なくとも」の誤記であると認められる。
　
　そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下検討する。
　
（２）引用発明
　原査定の拒絶の理由に引用され、本願の優先権主張の日前である平成８年５月１５日に頒布された刊行物である、日川著、”業務システム構築　ＷＷＷとＤＢ連携製品は急増，Ｊａｖａなど新技術も射程に”、日経オープンシステム、日経ＢＰ社、第３８号、第２５８−２６７頁（以下「引用文献」という。）には、次の事項が記載されている。
　
（ア）「ＷＷＷ（World-Wide Web）とデータベース（ＤＢ）を連携させる形態の企業内システムは、今や現実的な選択肢となった。ＷＷＷ−ＤＢ連携製品の品数は急増し、出荷ラッシュの様相を示している。（表１）
　ＷＷＷベースのシステム構築は、一般に従来型のシステム開発と比べればラクである。ＷＷＷとＤＢＭＳ（データベース管理システム）を連携させる大枠は、図１に示したようになる。例えば画面設計は「ＨＴＭＬテンプレートの記述」という作業に置き換わる。専用の開発ツールによる作業や、プログラミング言語のコーディングに比べれば単純な技術である。管理も楽だ。クライアント側にはＷＷＷブラウザだけがあれば良い。」
（第２５８頁左段第１行〜右段第６行）
　
（イ）第２５８頁の図１の記載からは、ＷＷＷブラウザとＷＷＷサーバー、ＷＷＷサーバーと連携アプリケーション、連携アプリケーションとＤＭＳとがそれぞれ双方向に通信できるように接続され、特に、ＷＷＷブラウザとＷＷＷサーバーとの間には、ＵＲＬ変数として、「セッションＩＤ」が含まれることが見て取れる。
　
（ウ）「ＷＷＷとＤＢＭＳとの連携システムを構築するために必要な道具立ては、以下のようになる。＜１＞ＤＢＭＳ、＜２＞ＷＷＷサーバー・ソフト（外部アプリケーションとの連係機能を備えたもの）、＜３＞ＤＢアクセス機能を含んだ外部アプリケーション群、＜４＞外部アプリケーションとの間を取り持つゲートウェイ・ソフト、以上である。個別に売っている製品、各機能がセットになったパッケージ製品、自作しなければならない部分、に分けられる。
　＜２＞の外部アプリケーションとの連携機能では、ＣＧＩ（Common Gateway Interface）が標準的な技術である。現時点で入手できるほとんどのＷＷＷサーバーがＣＧＩを備える。
　…（中略）…
　＜３＞、＜４＞のＤＢアクセス機能を含んだ外部アプリケーション群は、主にＤＢアクセス・クライアント部分、ＨＴＭＬ生成部分、その他雑多な処理で構成する。ＷＷＷとＤＢを結ぶ役割をするＣＧＩスタブは、自作もしくはＤＢ連携アプリに付属するサンプルをカスタマイズして使う。ＣＧＩスタブを自動生成する製品もある。」（注：＜＞付き数字は、実際は、丸囲み数字である。以降においても同じ。）
（第２５８頁右段下から４行目〜最下行、第２６０頁中段第７行）
　
（エ）「ＤＢ連携アプリケーションの一番の問題点は、セッションを管理する仕組みである。ＨＴＴＰだけの世界で行わせるために、送出するＨＴＭＬに擬似セッション情報をＵＲＬの形で埋め込む（図２）。これは標準的なＨＴＴＰの制約の中でセッション管理を実現するためには必ず必要となる技法である。
　理由は、ＨＴＴＰがステートレスであり、ファイル転送１回１回ごとにセッションを切るためだ。これでは、同時に複数のユーザーがＤＢアクセスする場合や、検索結果からさらに絞り込み検索する場合などで都合が悪い。」
（第２６０頁右段第７−２１行）
　
［補足１］
　上記（イ）の「連携アプリケーション」は、上記（ウ）からして、＜２＞のＷＷＷサーバー・ソフトが備える連携機能（ＣＧＩ）と、＜４＞のゲートウエイ・ソフトとから構成されていることが分かる。また、「連携アプリケーション」は、ソフトウェアであることからコンピュータ上で実行されるものであり、かつ、技術常識からして、当該コンピュータが、少なくとも１つの中央処理装置（ＣＰＵ）とＣＰＵに結合されたメモリを有し、ＣＰＵが当該メモリに常駐する「連携アプリケーション」を実行することにより当該「連携アプリケーション」が有する機能が実現されることは自明である。
［補足２］
　上記（イ）において、ＷＷＷブラウザとＷＷＷサーバー、ＷＷＷサーバーと連携アプリケーションがＨＴＭＬファイルを介してデータのやり取りを行い、及び、ＷＷＷブラウザが、ＷＷＷサーバーから受信したＨＴＭＬファイルを実行することによりユーザ・インターフェースを提供し、該ユーザ・インターフェースを介して入力されたデータを、ＨＴＭＬファイルとしてＷＷＷサーバー及び連携アプリケーションへ送信していることは、ＷＷＷに関する技術常識からして自明である。
　つまり、連携アプリケーションは、ＨＴＭＬファイルによるユーザ・インターフェースを介して複数のＷＷＷブラウザへまたはこれらからデータを送受する能力を有し、図１のＷＷＷベースのシステムは、ＷＷＷ上で複数のウェブ・ブラウザと複数のソフトウェア・アプリケーションとの間で通信するためのＨＴＭＬファイルによるユーザ・インターフェースを提供しているといえる。
［補足３］
　上記（エ）からして、「連携アプリケーション」が、セッション管理のために擬似セッション情報をＵＲＬに埋め込む埋め込み機構を有し、該連携アプリケーションが当該埋め込み機構を使用してＤＢアクセス（トランザクション）をサポートしていることは自明である。
　
　よって、上記（ア）乃至（エ）及び［補足１］乃至［補足３］からして、引用文献には次の発明（以下「引用発明」という。）が記載されている。
　
　少なくとも１つの中央処理装置（ＣＰＵ）と、
　ＣＰＵに結合されたメモリと、
　メモリ内に常駐し、少なくとも１つのＣＰＵによって実行され、ＨＴＭＬファイルによるユーザ・インターフェースを介して複数のＷＷＷブラウザへまたはこれらからデータを送受する能力を有し、セッション管理のために、複数のウェブ・ブラウザのそれぞれのための擬似セッション情報を生成してＵＲＬの形で埋め込む埋め込み機構を使用する、トランザクションをサポートする連携アプリケーションとを含む、ＷＷＷ上で複数のウェブ・ブラウザと複数のソフトウェア・アプリケーションとの間で通信するためのＨＴＭＬファイルによるユーザ・インターフェースを提供するＷＷＷベースのシステム。
　
（３）対比
　本願補正発明と引用発明とを対比すると、引用発明の「ＷＷＷブラウザ」、「セッション管理」、「擬似セッション情報」、「トランザクションをサポートする連携アプリケーション」、「外部アプリケーション」及び「ＷＷＷベースのシステム」は、それぞれ本願補正発明の「ウェブ・ブラウザ」、「データの識別及び追跡」、「識別子」、「トランザクション・サポート機構」、「ソフトウェア・アプリケーション」及び「コンピュータ・システム」に対応している。
　また、引用発明の「ＨＴＭＬファイルによるユーザ・インターフェース」は、ＨＴＭＬの言語仕様がＷＷＷブラウザに共通のものであることを考慮すれば、共通のユーザ・インターフェースであるといえるから、本願補正発明の「共通ユーザ・インターフェース」に対応しているといえる。
　さらに、引用発明の「埋め込み機構」は、複数のウェブ・ブラウザのそれぞれのための識別子を生成する機能を有した機構である点で、本願補正発明の「識別子機構」と共通している。
　
　よって、両者は、
　
　少なくとも１つの中央処理装置（ＣＰＵ）と、
　ＣＰＵに結合されたメモリと、
　メモリ内に常駐し、少なくとも１つのＣＰＵによって実行され、共通ユーザ・インターフェースを介して複数のウェブ・ブラウザへまたはこれらからデータを送受する能力を有し、データの識別及び追跡のために、複数のウェブ・ブラウザのそれぞれのための識別子を生成する機構を使用する、トランザクション・サポート機構とを含む、ワールド・ワイド・ウェブ上で複数のウェブ・ブラウザと複数のソフトウェア・アプリケーションとの間で通信するための共通ユーザ・インターフェースを提供するコンピュータ・システム。
　
　の点で一致し、以下の点で相違している。
　
［相違点］
　本願補正発明は、「識別子機構」が、「ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する」という機能を有しているのに対し、引用発明では、当該「経路指定」に係る機能について言及していない点。
　
（４）判断
　以下、上記相違点について検討する。
　
　本願補正発明において、「識別子機構」が行う「経路指定」がいかなる処理であるのか具体的に特定されておらず、発明の詳細な説明の記載を参酌しても、「識別子機構」が行うどのような処理をもって「経路指定」としているのか具体的な定義がなされていないが、語句の構成からして、「経路」を「指定」する処理であると解釈することが合理的である。
　すると、本願補正発明の「ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する」は、「ソフトウェア・アプリケーション」からのデータを、「複数のウェブ・ブラウザ」のそれぞれのための「識別子」に対応する選択された１つに「経路」を「指定」するということになるから、結局は、「ソフトウェア・アプリケーション」からのデータを、「識別子」に対応する１つの「ウェブ・ブラウザ」を指定して選択的に送信するものと解釈するのが妥当である。
　ここで、引用文献１における上記（エ）は、引用発明が、複数のユーザーが同時にＤＢアクセスを使用すること、または、絞り込み検索を行うことを前提とし、「擬似セッション情報」及びこれを用いたセッション管理により、ＤＢアクセスの結果又は検索結果を、ＤＢアクセス又は検索を要求した一のＷＷＷブラウザ（「擬似セッション情報」に対応するもの）を指定して選択的に返されるものであることを示唆しているから、引用発明において、「連携アプリケーション」は、実質的には、セッション管理機能により、「擬似セッション情報」に対応するＷＷＷブラウザの１つに選択的に経路指定する機能を有しているといえる。
　実際、セッションや会話といった一連の通信の流れ（トランザクション）を識別子により管理し、当該識別子を用いて選択的に経路指定をすることは、例えば、特開平８−３１４８３５号公報（特に、段落【０１２９】の記載「尚、上記セッションＩＤは、サービス装置接続部１２５がＴＣＰプロトコル層で管理しているもので、発信ＩＰアドレス、受信ＩＰアドレス、発信ポート番号、受信ポート番号などの情報により区別される各個別のセッション（コネクション）を識別するためのＩＤである。」、及び図１５参照。）、北川・宮下著、”３階層分散システムにおける協調分散トランザクション処理”、UNISYS TECHNOLOGY REVIEW、日本ユニシス株式会社、１９９４年８月３１日、第１４巻、第２号、第１００−１１８頁（特に、第１０９頁「４．１．２　会話制御プロセス」の欄に記載の「会話制御プロセスは、会話制御プロセス用の構成ファイルに指定された、会話セッションごとの自ノード、宛先ノードのセッション端点のネットワーク内での識別名（ＩＳまたはＤＤＰの構成ファイルに登録されているもの）などの情報により、会話セッションの単位で常駐し、ＡＣＬＥＳ／ＤＴＰとの全二重の会話セッションを確立し、データの送受信を行う（図１４）」参照。）に記載されているように、本願の優先権主張日における周知技術である。
　よって、引用発明において、「ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する」という機能を「識別子機能」に付加することは、当業者が容易になし得たものである。
　
　そして、本願補正発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲内のものである。
　
　したがって、本願補正発明は、引用発明及び周知技術に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１５年改正前特許法第１７条の２第５項で準用する特許法第１２６条第５項の規定に違反するものであり、特許法第１５９条第１項で読み替えて準用する特許法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について、
（１）本願発明
　平成１８年６月１８日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１５年６月５日付け手続補正書の特許請求の範囲の請求項１に記載された次のとおりのものである。
　
「少なくとも１つの中央処理装置（ＣＰＵ）と、
　ＣＰＵに結合されたメモリと、
　メモリ内に常駐し、少なくとも１つのＣＰＵによって実行され、共通ユーザ・インターフェースを介して複数のウェブ・ブラウザへまたはこれらからデータを送受する能力を有し、データの識別及び追跡のために識別子機構を使用する、トランザクション・サポート機構とを含む、ワールド・ワイド・ウェブ上で複数のウェブ・ブラウザと複数のソフトウェア・アプリケーションとの間で通信するための共通ユーザ・インターフェースを提供するコンピュータ・システム。」
　
（２）引用例
　原査定の拒絶の理由に引用した引用文献、及びその記載事項は、前記「２．（２）」に記載したとおりである。
　
（３）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、「識別子機構」の限定事項である「複数のウェブ・ブラウザのそれぞれのための識別子を生成し、ソフトウェア・アプリケーションからのデータを、複数のウェブ・ブラウザのうちの識別子に対応する選択された１つに経路指定する」の構成を省いたものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「２．（４）」に記載したとおり、引用発明及び周知技術に基いて、当業者が容易に発明することができたものであるから、本願発明も、同様の理由により、引用発明及び周知技術に基いて、当業者が容易に発明することができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。