【事件の表示】
　平成１１年特許願第１１０５１５号「メッセージ・ブローカ・データ処理装置、方法、及び記録媒体」拒絶査定不服審判事件〔平成１２年　１月２８日出願公開、特開２０００−　２９９０７、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願の発明
　本願は、平成１１年（１９９９年）４月１９日（パリ条約による優先権主張　１９９８年４月２９日、イギリス）の特許出願であって、平成１４年９月２０日付けで拒絶査定がなされ、同年１２月１２日付けで拒絶査定に対する審判請求がなされるとともに、同日付けで手続補正がなされた。
　そして、当審における審理の結果、平成１８年１１月２日付けで当審拒絶理由通知がなされて、同年同月７日付けで手続補正がなされた。
　本願の発明は、上記平成１８年１１月７日付けの手続補正により補正された明細書の特許請求の範囲の請求項１〜１５に記載された次のとおりのものと認める。
　
「【請求項１】
　送信者アプリケーションからメッセージを受信し、受信されたメッセージを処理し、処理されたメッセージの転送先の受信者アプリケーションを決定するメッセージ・ブローカ・データ処理装置であって、
　前記送信者アプリケーションから、複数のフィールドを有するタプルとして編成されるメッセージの入来ストリームを受信する手段と、
　データベースに複数のフィールドを有するタプルとして編成され、記憶されたデータと、前記入来ストリームとを照合する手段と、
　受信した前記メッセージの入来ストリームに対して前記受信者アプリケーションそれぞれに応じた処理を実行し、当該処理が前記照合する手段による照合結果と結合処理を行う場合に、前記照合する手段による照合結果との結合処理を実行する処理手段と、
　前記処理手段による処理結果のメッセージのストリームを、前記受信者アプリケーションが情報を取出す準備が整っているときに少なくとも１つの前記受信者アプリケーションに転送する手段とを含み、
　前記処理手段が、相互接続されてネットワークを形成する複数の処理ノードを利用して処理を実行し、前記処理ノードの各々の処理機能が、標準の関係言語による関係式により定義される、装置。
　
　【請求項２】
　メッセージ・タプルのストリームが前記複数の処理ノード間で転送される、請求項１記載の装置。
　
　【請求項３】
　さらにキュー・マネージャを含み、前記転送する手段が前記処理手段からの処理結果を、前記受信者アプリケーションが取出すため、前記キュー・マネージャの出力キューに配置する、請求項１記載の装置。
　
　【請求項４】
　前記標準の関係言語が構造化照会言語である、請求項１記載の装置。
　
　【請求項５】
　ビジュアル・データベース・ツールが、前記処理ノードの機能を定義する前記関係式を生成するために使用される、請求項１記載の装置。
　
　【請求項６】
　前記装置が１つのデータ処理ユニット上に含まれる、請求項１記載の装置。
　
　【請求項７】
　前記装置が複数の相互接続されるデータ処理ユニット上に含まれる、請求項１記載の装置。
　
　【請求項８】
　前記メッセージ・ブローカ・データ処理装置がインターネット・サーバ上に配置され、前記送信者アプリケーション及び前記受信者アプリケーションの少なくとも１つが、ワールド・ワイド・ウェブ・ブラウザ・アプリケーションを使用する、請求項１に記載の装置。
　
　【請求項９】
　送信者アプリケーションからメッセージを受信し、受信されたメッセージを処理し、処理されたメッセージの転送先の受信者アプリケーションを決定するメッセージ・ブローカ・データ処理方法であって、
　前記送信者アプリケーションから、複数のフィールドを有するタプルとして編成されるメッセージの入来ストリームを受信するステップと、
　データベースに複数のフィールドを有するタプルとして編成され、記憶されたデータと、前記入来ストリームとを照合するステップと、
　受信した前記メッセージの入来ストリームに対して前記受信者アプリケーションそれぞれに応じた処理を実行し、当該処理が前記照合するステップでの照合結果と結合処理を行う場合に前記照合結果と結合処理する処理ステップと、
　前記処理ステップでの処理結果のメッセージのストリームを、前記受信者アプリケーションが情報を取出す準備が整っているときに少なくとも１つの前記受信者アプリケーションに転送するステップとを含み、
　相互接続されてネットワークを形成する複数の処理ノードを利用して、前記処理ステップの処理が実行され、前記処理ノードの各々の処理機能が、標準の関係言語による関係式により定義される、方法
　
　【請求項１０】
　メッセージ・タプルのストリームが前記複数の処理ノード間で転送される、請求項９記載の方法。
　
　【請求項１１】
　前記受信するステップが、キュー・マネージャが前記送信者アプリケーションからの前記メッセージを受信して前記メッセージを前記処理ステップに渡すステップを含み、　前記転送するステップが前記処理ステップからの処理結果を、前記受信者アプリケーションが取出すため、前記キュー・マネージャの出力キューに配置するステップを含む、請求項９記載の方法。
　
　【請求項１２】
　前記標準の関係言語が構造化照会言語である、請求項９記載の方法。
　
　【請求項１３】
　ビジュアル・データベース・ツールが、前記処理ノードの機能を定義する前記関係式を生成するために使用される、請求項９記載の方法。
　
　【請求項１４】
　前記方法がインターネット・サーバ上に実現され、前記送信者アプリケーション及び前記受信者アプリケーションの少なくとも１つが、ワールド・ワイド・ウェブ・ブラウザ・アプリケーションを使用する、請求項９に記載の方法。
　
　【請求項１５】
　請求項９〜１４のいずれか１項に記載の方法を、コンピュータに実行させるプログラムを記録した、コンピュータ読取り可能な記録媒体。」
　
２．原査定の拒絶の理由の概要
　原査定の拒絶の理由は、概要以下のとおりである。
　本願の請求項１〜３９に係る発明は、次の引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　　引用例１：青山円，”イントラネットにＡｃｃｅｓｓを”，
　　　　　　　Ｍｉｃｒｏｓｏｆｔ　Ａｃｃｅｓｓ９７　特別企画，日本，
　　　　　　　エーアイ出版株式会社，１９９７年　６月２０日，
　　　　　　　p.104-p.111
　
　また、前置報告書には周知例として、次のものが挙げられている。
　　周知例１：木村春生，”ソリューション訪問：山一情報システム　営業
　　　　　　　部門の情報武装を促進するモバイル・エージェント技術”，
　　　　　　　ＰＣ　ＷＯＲＫ！，日本，株式会社毎日コミュニケーション
　　　　　　　，１９９７年　４月１８日，第４巻　第４号，p.204-206 
　　周知例２：松崎高典　外３名，”モバイルコンピューティング環境にお
　　　　　　　けるソフトウェア製品の開発”，日立評論，日本，日立評論
　　　　　　　社，１９９６年　９月　１日，第７８巻　第９号，p.11-16 
　　周知例３：小杉正貴　外３名，”電子メールを用いたクライアント／サ
　　　　　　　ーバにおける非同期通信機構の開発”，INTEC TECHNICAL 
　　　　　　　REPORT，日本，株式会社インテック，
　　　　　　　１９９６年６月３０日，第４６号，p.1-6 
　　周知例４：吉田琢也，”メッセージ連携システム”，日経コンピュータ
　　　　　　　，日本，日経ＢＰ社，１９９５年　９月　４日，第３７３号
　　　　　　　，p.126-139 
　
３．平成１８年１１月２日付けで通知した当審の拒絶理由
　当審の拒絶理由の概要は、以下のとおりである。
　平成１４年１２月１２日付けの補正書で補正されたところの、本件の特許請求の範囲の請求項１〜３６においては、特許を受けようとする発明が明確でなく、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
４．引用例及び周知例の記載事項
　上記引用例１及び各周知例に記載又は開示されている事項は、以下のとおりである。
＜引用例１＞
　インターネット上で提供されている表形式のデータをＡｃｃｅｓｓに取り込み、テーブルとして保存し、各種のデータ処理・解析をマクロを用いて自動化すること。
＜周知例１〜４＞
　サーバが、クライアントからのメッセージをキューイングし、ＳＱＬにより、複数のフィールドを持つタプルとして編成されたデータベースを照合し、その照合結果をキューに蓄積し、クライアントが次にサーバにアクセスした際にネットワークに送信すること。
　
５．当審の判断
５−１．原査定の理由（特許法第２９条第２項）について
（１）請求項１に係る発明について
　請求項１に係る発明と引用例１に記載された発明とを対比すると、引用例１に記載された発明における「表形式のデータ」は、請求項１に係る発明における「複数のフィールドを有するタプルとして編成されるメッセージの入来ストリーム」に相当し、引用例１に記載の「Ａｃｃｅｓｓ」は、各種のデータ処理を実行する手段であるから、その意味で、請求項１に係る発明における「処理手段」と共通する。
　そうすると、両者は、
「複数のフィールドを有するタプルとして編成されるメッセージの入来ストリームを受信する手段と、
　受信した前記メッセージの入来ストリームに対して処理を実行する処理手段と
　を含む装置。」
である点で一致し、以下の点で相違する。
（ａ）請求項１に係る発明は、「装置」が、送信者アプリケーションからメッセージを受信し、受信されたメッセージを処理し、処理されたメッセージの転送先の受信者アプリケーションを決定するメッセージ・ブローカ・データ処理装置であるのに対し、引用例１に記載された発明は、そうではない点。
（ｂ）請求項１に係る発明は、データベースに複数のフィールドを有するタプルとして編成され、記憶されたデータと、前記入来ストリームとを照合する手段を含むのに対し、引用例１に記載された発明は、そのような手段を含まない点。
（ｃ）請求項１に係る発明の処理手段は、受信した前記メッセージの入来ストリームに対して前記受信者アプリケーションそれぞれに応じた処理を実行し、当該処理が前記照合するステップでの照合結果と結合処理を行う場合に前記照合結果と結合処理するのに対し、引用例１に記載された発明の処理手段は、そのような処理を行わない点。
（ｄ）請求項１に係る発明は、処理手段による処理結果のメッセージのストリームを、前記受信者アプリケーションが情報を取出す準備が整っているときに少なくとも１つの前記受信者アプリケーションに転送する手段を含むのに対し、引用例１に記載された発明は、そのような手段を含まない点。
（ｅ）請求項１に係る発明の処理手段は、相互接続されてネットワークを形成する複数の処理ノードを利用して処理を実行し、前記処理ノードの各々の処理機能が、標準の関係言語による関係式により定義されるのに対し、引用例１に記載された発明の処理手段はそのようなものではない点。
　
　一方、周知例には、上記（ｂ）に関し、データベースに複数のフィールドを有するタプルとして編成され、記憶されたデータを照合すること、及び、上記（ｄ）の「転送する手段」が記載されているが、周知例では、上記（ｂ）のうち、照合対象を「複数のフィールドを有するタプルとして編成されるメッセージの入来ストリーム」とする点については何ら記載されておらず、また、上記（ａ）、（ｃ）、（ｅ）についての記載は何もない。
　
　請求項１に係る発明は、そもそも、上記（ａ）を前提としているため、入来ストリームを加工処理し、その処理結果を複数の中から決定された受信者アプリケーションへ転送する必要があるので、そうした処理を実現する構成を備えており、処理結果を転送する必要がない引用例１に記載された発明とも、入来ストリーム自体がＳＱＬであり、かつ、その発生源と処理結果の転送先とが常に同一クライアントである周知例１〜４に記載された周知技術とも、根本的に異なる技術思想である。
　それ故、メッセージの流れを効率的でシームレスな構成にするため、照合する手段及び処理手段への入力ストリームを共にタプル編成とすることは、引用例１に記載された発明や周知例１〜４に記載された周知技術からは想到し得ないことである。
　
　結局、引用例１及び周知例の何れにも、上記（ｂ）のうち、データベースのデータとの照合対象を「複数のフィールドを有するタプルとして編成されるメッセージの入来ストリーム」とする点、及び、上記（ａ）、（ｃ）、（ｅ）については、何ら記載もしくは示唆されていない。また、引用例１に記載された発明及び周知例１〜４に記載された周知技術を組み合わせても請求項１に係る発明の上記構成を得ることはできない。
　
　そして、請求項１に係る発明は、データベースのデータとの照合対象を「複数のフィールドを有するタプルとして編成されるメッセージの入来ストリーム」とする点、上記（ａ）、（ｃ）、（ｅ）により、「一旦ブローカ・システムが設計されると、追加の機能を加える変更が非常に容易になる」、「任意のノードの関係式が容易に一様の様式で変更され得る」、「任意のノードのために、異なるタイプのプログラミングに切り替える必要はない」、「顧客要求により結合ノードが変更されなければならない場合、データベース・プログラマは新たなプログラミング技術を習得する必要無しに、これを容易に実行でき、従ってシステム開発費用を多大に低減することができる」という明細書記載の格別の効果を奏するものである。
　
　したがって、請求項１に係る発明は、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることはできない。
　
（２）請求項２〜１５に係る発明について
　請求項２〜８に係る発明は請求項１に係る発明を引用するものであるから、請求項１に係る発明が、上記のように、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることができない以上、請求項２〜８に係る発明も、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることはできない。
　請求項９に係る発明も、請求項１に係る発明と同様の理由によって、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることはできない。
　請求項１０〜１５に係る発明は請求項９に係る発明を引用するものであるから、請求項９に係る発明が、上記のように、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることができない以上、請求項１０〜１５に係る発明も、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものとすることはできない。
　
５−２．平成１８年１１月２日付けで通知した当審の拒絶理由（特許法第３６条第６項第２号）について
　当審で審理した結果、特許請求の範囲の記載に不備があると認められたため、特許法第３６条第６項第２号を満たしていない旨の拒絶理由を通知した。 
　これに対して、審判請求人は、平成１８年１１月７日付けの手続補正書により、特許請求の範囲の記載を上記「１．手続の経緯・本願の発明」の項で摘記したとおりに補正した。 
　これによって、上記の拒絶理由は解消された。 
　
６．むすび
　以上のとおりであるから、本願は、原査定の拒絶の理由によって拒絶すべきものであるとすることはできない。
　
　また、他に本願を拒絶すべき理由を発見しない。
　
　よって、結論のとおり審決する。