【事件の表示】
　特願２０１０−５３６０４２「共通メッセージングインタフェースを用いたサービス指向アーキテクチャアプリケーションの統合」拒絶査定不服審判事件〔平成２１年　６月　４日国際公開，ＷＯ２００９／０７０４１２，平成２３年　２月１７日国内公表，特表２０１１−５０５０４８〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２００８年１０月３１日（パリ条約による優先権主張外国庁受理２００７年１１月２７日（以下，「優先日」という。），米国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。
　
　　平成２２年　５月２７日　　　：国内書面の提出
　　平成２２年　７月２６日　　　：翻訳文の提出
　　平成２３年　８月２６日　　　：出願審査請求書の提出
　　平成２４年　７月２７日付け　：拒絶理由の通知
　　平成２５年　１月３１日　　　：意見書，手続補正書の提出
　　平成２５年　４月１５日付け　：拒絶査定　
　　平成２５年　８月２３日　　　：審判請求書，手続補正書の提出
　　平成２５年１０月２２日　　　：前置報告
　　平成２５年１１月２８日付け　：審尋
　　平成２６年　２月２４日　　　：回答書の提出
　
　
第２　平成２５年８月２３日付けの手続補正についての補正却下の決定　 
　
 ［補正却下の決定の結論］ 
　
　平成２５年８月２３日付けの手続補正を却下する。
　
 ［理由］ 
　
 １　補正の内容
　
　平成２５年８月２３日付けの手続補正（以下，「本件補正」という。）の内容は，平成２５年１月３１日付けの手続補正により補正された特許請求の範囲の請求項１乃至４の記載
　
「　【請求項１】
　サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステムであって，
　第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しであって，予め規定された共通ＡＰＩへのミドルウェアＡＰＩ呼出しを受信するようコード化されたインタフェースアダプタ（４３２）と，
　前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）と
を含む共通インタフェースシステム。
　　【請求項２】
　前記インタフェースアダプタ（４３２）および前記ミドルウェアアダプタ（４３４）が，それぞれ実行時ライブラリを含む，請求項１に記載の共通インタフェースシステム。
　　【請求項３】
　前記インタフェースアダプタ（４３２）が，少なくとも１つのＡＰＩ呼出しを受信するようコード化されている，請求項１に記載の共通インタフェースシステム。
　　【請求項４】
　前記ミドルウェアアダプタ（４３４）が，第１ミドルウェアＡＰＩとは異なるミドルウェアＡＰＩと互換性のある実行時ライブラリを呼び出すようコード化されている，請求項１に記載の共通インタフェースシステム。」
（以下，この特許請求の範囲に記載された請求項を「本件補正前の請求項」という。）
　
を，
　
「　【請求項１】
　サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステムであって，
　第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出し
を，
接続
　前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）と
を含
み，
　
前記インタフェースアダプタ（４３２）は，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記ミドルウェアＡＰＩ呼出しと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し，
　
前記ミドルウェアアダプタ（４３４）は，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって，前記第２ミドルウェアＡＰＩと互換性のあるターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する，
共通インタフェースシステム。
　　【請求項２】
　前記インタフェースアダプタ（４３２）および前記ミドルウェアアダプタ（４３４）が，それぞれ実行時ライブラリを含む，請求項１に記載の共通インタフェースシステム。
　　【請求項３】
　前記インタフェースアダプタ（４３２）が，少なくとも１つのＡＰＩ呼出しを受信するようコード化されている，請求項１に記載の共通インタフェースシステム。
　　【請求項４】
　前記ミドルウェアアダプタ（４３４）が，第１ミドルウェアＡＰＩとは異なるミドルウェアＡＰＩと互換性のある実行時ライブラリを呼び出すようコード化されている，請求項１に記載の共通インタフェースシステム。」（当審注：下線は，出願人が付与したものである。以下，この特許請求の範囲に記載された請求項を「本件補正後の請求項」という。）　
　
に補正するものである。
　
　そして，本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてなされており，特許法第１７条の２第３項の規定に適合している。
　また，本件補正は，シフト補正をしようとするものではなく，特許法第１７条の２第４項の規定に適合している。　
　
　
２　目的要件
　
　本件補正は，上記「第２　１　補正の内容」のとおり本件審判の請求と同時にする補正であり，特許請求の範囲について補正をしようとするものであるから，本件補正が，特許法第１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。　
　
（１）本件補正前の請求項と，本件補正後の請求項とを比較すると，本件補正後の請求項１，２，３，４はそれぞれ，本件補正前の請求項１，２，３，４に対応することは明らかである。
　
（２）本件補正は，下記の補正事項１，２よりなるものである。
　
＜補正事項１＞　
　本件補正前の請求項１の
「第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しであって，予め規定された共通ＡＰＩへのミドルウェアＡＰＩ呼出しを受信するようコード化されたインタフェースアダプタ（４３２）」との記載を，
　本件補正後の請求項１の
「第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しを，予め規定された共通ＡＰＩへ接続するようコード化されたインタフェースアダプタ（４３２）」，「前記インタフェースアダプタ（４３２）は，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記ミドルウェアＡＰＩ呼出しと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し」との記載に限定することを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
＜補正事項２＞　
　本件補正前の請求項１の
「前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）」との記載を，
　本件補正後の請求項１の
「前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）」，「前記ミドルウェアアダプタ（４３４）は，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって，前記第２ミドルウェアＡＰＩと互換性のあるターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する」との記載に限定することを目的とするものであり，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
（３）したがって，上記補正事項１，２は限定的減縮を目的とするものであり，本件補正は，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当すると言えることから，特許法第１７条の２第５項の規定に適合するものである。
　
　
３　独立特許要件
　
　以上のように，本件補正は，限定的減縮を目的とする上記補正事項１，２を含むものである。そこで，限定的減縮を目的として補正された本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。
　
（１）本件補正発明
　
　本件補正発明は，上記平成２５年８月２３日付けの手続補正書により補正された特許請求の範囲，明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。　
　
「　サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステムであって，
　第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しを，予め規定された共通ＡＰＩへ接続するようコード化されたインタフェースアダプタ（４３２）と，
　前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）と
を含み，　
　前記インタフェースアダプタ（４３２）は，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記ミドルウェアＡＰＩ呼出しと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し，　
　前記ミドルウェアアダプタ（４３４）は，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって，前記第２ミドルウェアＡＰＩと互換性のあるターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する，　
共通インタフェースシステム。」　
　
　
（２）引用例
　
ア　本願の優先日前に頒布され，原審の拒絶査定の理由である上記平成２４年７月２７日付けの拒絶理由通知において引用された，米国特許第７１５２０９４号明細書（２００６年１２月１９日公開，以下，「引用例」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「FIELD OF THE INVENTION 
　
The invention relates to the field of communication within computer networks containing heterogeneous computer systems and more particularly to communication between systems connected by disparate middleware products.
（当審仮訳；　発明の分野
　
本発明は，異種のコンピュータ・システムを含むコンピュータネットワーク内の通信の分野，特に，異種のミドルウェア製品で接続されたシステム間の通信に関するものである。
　
Ｂ　「SUMMARY OF THE INVENTION 
　
The present invention, hereafter referred to as the Middleware Brokering System Adapter, is a component useful with a Middleware Brokering System. The Middleware Brokering System acts as an intermediary, or meta-middleware, device among different middleware systems. Each middleware service can send messages to and receive messages from the Middleware Brokering System in its native data format and programming syntax.
（当審仮訳；　発明の概要
　
以下，ミドルウェアブローカシステムアダプタと呼ばれる本発明は，ミドルウェアブローカシステムで有用なコンポーネントである。ミドルウェアブローカシステムは，異なるミドルウェアシステム間の仲介者，またはメタミドルウェア，デバイスとして機能する。各ミドルウェアサービスは，そのネイティブのデータフォーマットとプログラミング構文で，ミドルウェアブローカシステムにメッセージを送信し，ミドルウェアブローカシステムからのメッセージを受け取ることができる。
　
Ｃ　「
In the embodiment of FIG.3 , the Middleware Brokering System comprises a mainframe adapter 340 , a JMS adapter 350 , and a message brokering server 360 . The mainframe adapter 340 , the JMS adapter 350 , and the message brokering server 360 are software components that act virtually as a unit and can reside on the same physical device or on different devices.
（当審仮訳；　
図3の実施形態では，ミドルウェアブローカシステムは，メインフレームアダプタ340，JMSアダプタ350，及びメッセージブローカサーバ360を含む。メインフレームアダプタ340，JMSアダプタ350，およびメッセージブローカサーバ360は，ユニットとして実質的に機能し，同じ物理デバイスまたは異なるデバイス上に置くことができるソフトウェアコンポーネントである。
　
Ｄ　「
In a preferred embodiment, the mainframe system 310 uses IBM's MQSeries middleware to interact with the Middleware Brokering System. In alternative embodiments, any middleware product equivalent to MQSeries may be used to transfer data between the mainframe 310 and the Middleware Brokering System. When a Cobol program running on the mainframe 310 needs to send a message to the CORBA network 320 , the JMS network 330 , or both, the data is prepared by placing it in a structure known as a Cobol copybook.
The program running on the mainframe 310 uses a standard programming command to transmit the copybook to MQSeries. MQSeries then sends the data to the mainframe adapter 340 , described in detail below.
The mainframe adapter 340 converts the copybook into a standard format known as a structured event, also described in detail below. The mainframe adapter 340 then sends the message in the structured event format to the message brokering server 360 .
（当審仮訳；　
好ましい実施形態では，メインフレームシステム310は，ミドルウェアブローカシステムと対話するために，IBMのMQSeriesのミドルウェアを使用する。別の実施形態では，メインフレーム310とミドルウェアブローカシステムとの間でデータを転送するために，MQSeriesと同等の任意のミドルウェア製品を使用することができる。メインフレーム310上で動作するCobolプログラムは，CORBAネットワーク320，JMSネットワーク330，または両方にメッセージを送信する必要があると，データは，Cobolコピーブックとして知られている構造に配列することにより準備される。
メインフレーム310上で動作するプログラムは，MQSeriesにコピーブックを送信するための標準的なプログラミングコマンドを使用する。 MQSeriesはそれから，後述するように，メインフレームアダプタ340にデータを送信する。
メインフレームアダプタ340は，これも後述するように，コピーブックを，構造化イベントとして知られる標準的なフォーマットへ変換する。メインフレームアダプタ340はそれから，メッセージブローカサーバ360に構造化イベントフォーマットのメッセージを送信する。
　
Ｅ　「Other types of computing systems or middleware that might be added to the configuration depicted in FIG.3 would publish their data to the message brokering server 360 in a similar manner. Where the middleware operates in a native language other than that of the Middleware Brokering System, the data would be transmitted to an adapter in the application's native format. 
The adapter would then convert the data into the structured event format and send the structured event to the message brokering server 360 . The use of the message brokering server 360 and the structured event allows mainframe systems and disparate middleware products to communicate with each other in a publish/subscribe mode.
（当審仮訳；　図3に示された構成に加えて，他のタイプのコンピューティングシステム，またはミドルウェアが，同様の方法で，メッセージブローカサーバ360に自身のデータを発行するであろう。ミドルウェアブローカシステム以外のネイティブ言語でミドルウェアが動作する場合，データはアプリケーションのネイティブフォーマットでアダプタに送信される。
アダプタは，構造化イベントフォーマットにデータを変換し，メッセージブローカサーバ360にその構造化イベントを送信する。メッセージブローカサーバ360及び構造化イベントを使用することにより，メインフレームシステムと異種ミドルウェア製品をパブリッシュ/サブスクライブモードで相互に通信することを可能にする。
　
Ｆ　「
Messages received by the message brokering server 360 are passed on to an underlying publish/subscribe engine 370 . The message brokering server 360 and the publish/subscribe engine 370 act together as a broker for the messages transferred among the mainframe system 310 , the CORBA network 320 , and the JMS network 330 . The message brokering server 360 maintains a list of subscribers and the types of messages they have registered to receive. The publish/subscribe engine 370 stores the messages in channels that can be configured with various attributes such as the number of messages that can be stored on the channel, the length of time messages are to be stored on the channel, and the priority of the messages on the channel. When the message brokering server 360 finds a match between a message sent to it by one of the publishers and a subscriber that has registered an interest in the message, the message brokering server 360 retrieves the message from the channels of the publish/subscribe engine 370 and sends the message to the appropriate subscriber.
（当審仮訳；　
メッセージブローカサーバ360が受信したメッセージは，潜在するパブリッシュ/サブスクライブエンジン370に渡される。メッセージブローカサーバ360とパブリッシュ/サブスクライブエンジン370は，メインフレームシステム310，CORBAネットワーク320，およびJMSネットワーク330の間で転送されるメッセージの仲介者として一緒に動作する。メッセージブローカサーバ360は，購読者のリストと，彼らが受け取るように登録されたメッセージの種類のリストを保持する。パブリッシュ/サブスクライブエンジン370は，チャネルに格納できるメッセージの数，チャネルに格納できるメッセージの長さ，およびチャネルでのメッセージの優先度などの様々な属性を有して構成されるチャネルにメッセージを格納する。メッセージブローカサーバ360は，発行者の1つによって送られたメッセージと，メッセージへの関心を登録している購読者との間の一致を見つけると，メッセージブローカサーバ360は，パブリッシュ/サブスクライブエンジン370のチャネルからそのメッセージを取得し，そして，適切な購読者にそのメッセージを送信する。
　
Ｇ　「
The message brokering server 360 retrieves data from the publish/subscribe engine 370 and passes it in the form of a structured event to the mainframe adapter 340 , the JMS adapter 350 , and/or directly to the CORBA network 320 . In a conversion process that is the reverse of the process described earlier, the mainframe adapter 340 converts the structured event to a copybook and sends the copybook to the mainframe 310 . Likewise, the JMS adapter 350 converts the structured event into the JMS MapMessage format and sends the MapMessage to the JMS network 330 . In this manner, the mainframe 310 , CORBA 320 , and JMS 330 systems can send data to and receive data from each other in their native formats.
（当審仮訳；　
メッセージブローカサーバ360は，パブリッシュ/サブスクライブエンジン370からデータを取得し，メインフレームアダプタ340，JMSアダプタ350，かつ/あるいは直接CORBAネットワーク320に対して，そのデータを構造化イベントの形式で渡す。先に説明したプロセスの逆の変換処理においては，メインフレームアダプタ340は構造化イベントをコピーブックに変換し，メインフレーム310にそのコピーブックを送信する。同様に，JMSアダプタ350は，構造化イベントをJMS MapMessageフォーマットに変換し，JMSネットワーク330にそのMapMessageを送信する。このように，メインフレーム310，CORBA320，およびJMS330のシステムは，それらのネイティブフォーマットで互いにデータを送信し，受信することができる。
　
　
イ　ここで，上記引用例に記載されている事項を検討する。　
　
（ア）上記Ａの「The invention relates to the field of communication within computer networks containing heterogeneous computer systems and more particularly to communication between systems connected by disparate middleware products. 」（当審仮訳；本発明は，異種のコンピュータ・システムを含むコンピュータネットワーク内の通信の分野，特に，異種のミドルウェア製品で接続されたシステム間の通信に関するものである。）との記載，上記Ｂの「The present invention, hereafter referred to as the Middleware Brokering System Adapter, is a component useful with a Middleware Brokering System. The Middleware Brokering System acts as an intermediary, or meta-middleware, device among different middleware systems. Each middleware service can send messages to and receive messages from the Middleware Brokering System in its native data format and programming syntax.」（当審仮訳；以下，ミドルウェアブローカシステムアダプタと呼ばれる本発明は，ミドルウェアブローカシステムで有用なコンポーネントである。ミドルウェアブローカシステムは，異なるミドルウェアシステム間の仲介者，またはメタミドルウェア，デバイスとして機能する。各ミドルウェアサービスは，そのネイティブのデータフォーマットとプログラミング構文で，ミドルウェアブローカシステムにメッセージを送信し，ミドルウェアブローカシステムからのメッセージを受け取ることができる。）との記載からすると，「異なるミドルウェアシステム」間で「メッセージ」が通信され，当該「メッセージ」を「ミドルウェアブローカシステム」が仲介することが読み取れるから，引用例には，
“異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム”
が記載されていると解される。
　
（イ）上記Ｃの「In the embodiment of FIG.3 , the Middleware Brokering System comprises a mainframe adapter 340 , a JMS adapter 350 , and a message brokering server 360 . The mainframe adapter 340 , the JMS adapter 350 , and the message brokering server 360 are software components that act virtually as a unit and can reside on the same physical device or on different devices.」（当審仮訳；図3の実施形態では，ミドルウェアブローカシステムは，メインフレームアダプタ340，JMSアダプタ350，及びメッセージブローカサーバ360を含む。メインフレームアダプタ340，JMSアダプタ350，およびメッセージブローカサーバ360は，ユニットとして実質的に機能し，同じ物理デバイスまたは異なるデバイス上に置くことができるソフトウェアコンポーネントである。）との記載からすると，「ミドルウェアブローカシステム」は「メインフレームアダプタ」，「JMSアダプタ」，「メッセージブローカサーバ」を含むことが読み取れるから，引用例には，
“メインフレームアダプタと，JMSアダプタと，メッセージブローカサーバとを含”む“ミドルウェアブローカシステム”
が記載されていると解される。
　
（ウ）上記Ｄの「In a preferred embodiment, the mainframe system 310 uses IBM's MQSeries middleware to interact with the Middleware Brokering System. In alternative embodiments, any middleware product equivalent to MQSeries may be used to transfer data between the mainframe 310 and the Middleware Brokering System. When a Cobol program running on the mainframe 310 needs to send a message to the CORBA network 320 , the JMS network 330 , or both, the data is prepared by placing it in a structure known as a Cobol copybook.」（当審仮訳；好ましい実施形態では，メインフレームシステム310は，ミドルウェアブローカシステムと対話するために，IBMのMQSeriesのミドルウェアを使用する。別の実施形態では，メインフレーム310とミドルウェアブローカシステムとの間でデータを転送するために，MQSeriesと同等の任意のミドルウェア製品を使用することができる。メインフレーム310上で動作するCobolプログラムは，CORBAネットワーク320，JMSネットワーク330，または両方にメッセージを送信する必要があると，データは，Cobolコピーブックとして知られている構造に配列することにより準備される。）との記載からすると，「メインフレームシステム」は，「ミドルウェアブローカシステム」との間でデータを転送するために，IBMの「MQSeries」のようなミドルウェアを使用し，「Cobolコピーブック」構造に配列されたデータは，「メインフレームシステム」上で動作する「Cobolプログラム」から送信されるメッセージであることが読み取れ，また，上記Ｄの「The program running on the mainframe 310 uses a standard programming command to transmit the copybook to MQSeries. MQSeries then sends the data to the mainframe adapter 340 , described in detail below.」（当審仮訳；メインフレーム310上で動作するプログラムは，MQSeriesにコピーブックを送信するための標準的なプログラミングコマンドを使用する。MQSeriesはそれから，後述するように，メインフレームアダプタ340にデータを送信する。）との記載からすると，「Cobolコピーブック」は，「MQSeries」が「メインフレームアダプタ」に送信するメッセージデータであるとが読み取れることから，「Cobolコピーブック」は，「メインフレームシステム」の「Cobolプログラム」使用の「MQSeries」が「メインフレームアダプタ」に送信する「メッセージ」であると解される。
　そして，上記Ｄの「The mainframe adapter 340 converts the copybook into a standard format known as a structured event, also described in detail below. The mainframe adapter 340 then sends the message in the structured event format to the message brokering server 360 .」（当審仮訳；メインフレームアダプタ340は，これも後述するように，コピーブックを，構造化イベントとして知られる標準的なフォーマットへ変換する。メインフレームアダプタ340はそれから，メッセージブローカサーバ360に構造化イベントフォーマットのメッセージを送信する。）との記載からすると，「メインフレームアダプタ」は，「Cobolコピーブック」を，「構造化イベントとして知られた標準フォーマット」の「メッセージ」に変換し，そして，変換された「メッセージ」を「メッセージブローカサーバ」に送信することが読み取れるから，引用例には，
“メインフレームアダプタは，メインフレームシステムのCobolプログラム使用のMQSeriesが送信するメッセージであるCobolコピーブックを，構造化イベントフォーマットに変換して，前記構造化イベントフォーマットのメッセージをメッセージブローカサーバに送信”する態様
が記載されていると解される。
　
（エ）上記Ｆの「Messages received by the message brokering server 360 are passed on to an underlying publish/subscribe engine 370 . The message brokering server 360 and the publish/subscribe engine 370 act together as a broker for the messages transferred among the mainframe system 310 , the CORBA network 320 , and the JMS network 330 . The message brokering server 360 maintains a list of subscribers and the types of messages they have registered to receive. The publish/subscribe engine 370 stores the messages in channels that can be configured with various attributes such as the number of messages that can be stored on the channel, the length of time messages are to be stored on the channel, and the priority of the messages on the channel.」（当審仮訳；メッセージブローカサーバ360が受信したメッセージは，潜在するパブリッシュ/サブスクライブエンジン370に渡される。メッセージブローカサーバ360とパブリッシュ/サブスクライブエンジン370は，メインフレームシステム310，CORBAネットワーク320，およびJMSネットワーク330の間で転送されるメッセージの仲介者として一緒に動作する。メッセージブローカサーバ360は，購読者のリストと，彼らが受け取るように登録されたメッセージの種類のリストを保持する。パブリッシュ/サブスクライブエンジン370は，チャネルに格納できるメッセージの数，チャネルに格納できるメッセージの長さ，およびチャネルでのメッセージの優先度などの様々な属性を有して構成されるチャネルにメッセージを格納する。）との記載からすると，「メッセージブローカサーバ」は「メインフレームシステム」，「CORBAネットワーク」，および「JMSネットワーク」の間で転送されるメッセージの仲介者として動作し，受信した「メッセージ」を「パブリッシュ/サブスクライブエンジン」に渡して格納することが読み取れる。
　また，上記Ｆの「When the message brokering server 360 finds a match between a message sent to it by one of the publishers and a subscriber that has registered an interest in the message, the message brokering server 360 retrieves the message from the channels of the publish/subscribe engine 370 and sends the message to the appropriate subscriber.」（当審仮訳；メッセージブローカサーバ360は，発行者の1つによって送られたメッセージと，メッセージへの関心を登録している購読者との間の一致を見つけると，メッセージブローカサーバ360は，パブリッシュ/サブスクライブエンジン370のチャネルからそのメッセージを取得し，そして，適切な購読者にそのメッセージを送信する。）との記載からすると，「メッセージブローカサーバ」は「メッセージ」の購読者，すなわち「転送先」が見つかると，当該「メッセージ」を「パブリッシュ/サブスクライブエンジン」から取得して，「転送先」に送信することが読み取れるから，引用例には，
“メッセージブローカサーバは，受信したメッセージを，パブリッシュ/サブスクライブエンジンに格納し，メッセージ転送先が見つかると，前記パブリッシュ/サブスクライブエンジンから前記メッセージを取得し，転送先に対して前記メッセージを構造化イベントの形式で送信”する態様
が記載されていると解される。
　
（オ）上記（ア）での検討のとおり，引用例には，異なるミドルウェアシステム間でメッセージが通信され，該メッセージを「ミドルウェアブローカシステム」が仲介することが記載されていると解され，また，上記Ｅの「The adapter would then convert the data into the structured event format and send the structured event to the message brokering server 360 . The use of the message brokering server 360 and the structured event allows mainframe systems and disparate middleware products to communicate with each other in a publish/subscribe mode.」（当審仮訳；アダプタは，構造化イベントフォーマットにデータを変換し，メッセージブローカサーバ360にその構造化イベントを送信する。メッセージブローカサーバ360及び構造化イベントを使用することにより，メインフレームシステムと異種ミドルウェア製品をパブリッシュ/サブスクライブモードで相互に通信することを可能にする。）との記載からすると，「メッセージブローカサーバ」により，「構造化イベントフォーマット」の「メッセージ」を使用して，「メインフレームシステム」と異なる「ミドルウェアシステム」間で「メッセージ」が通信されることが読み取れる。
　そして，上記Ｆの「The message brokering server 360 and the publish/subscribe engine 370 act together as a broker for the messages transferred among the mainframe system 310 , the CORBA network 320 , and the JMS network 330 .」（当審仮訳；メッセージブローカサーバ360とパブリッシュ/サブスクライブエンジン370は，メインフレームシステム310，CORBAネットワーク320，およびJMSネットワーク330の間で転送されるメッセージの仲介者として一緒に動作する。）との記載からすると，「メッセージ」が転送される異なる「ミドルウェアシステム」の態様として，「メインフレームシステム」，「CORBAネットワーク」，「JMSネットワーク」が例示されていることから，「メッセージブローカサーバ」が標準の「構造化イベントフォーマット」の「メッセージ」を使用して，「メインフレームシステム」が送信した「メッセージ」を「JMSネットワーク」に転送する態様を読み取ることができる。
　
　さらに，上記Ｇの「The message brokering server 360 retrieves data from the publish/subscribe engine 370 and passes it in the form of a structured event to the mainframe adapter 340 , the JMS adapter 350 , and/or directly to the CORBA network 320 . In a conversion process that is the reverse of the process described earlier, the mainframe adapter 340 converts the structured event to a copybook and sends the copybook to the mainframe 310 . Likewise, the JMS adapter 350 converts the structured event into the JMS MapMessage format and sends the MapMessage to the JMS network 330 . In this manner, the mainframe 310 , CORBA 320 , and JMS 330 systems can send data to and receive data from each other in their native formats.」（当審仮訳；メッセージブローカサーバ360は，パブリッシュ/サブスクライブエンジン370からデータを取得し，メインフレームアダプタ340，JMSアダプタ350，かつ/あるいは直接CORBAネットワーク320に対して，そのデータを構造化イベントの形式で渡す。先に説明したプロセスの逆の変換処理においては，メインフレームアダプタ340は構造化イベントをコピーブックに変換し，メインフレーム310にそのコピーブックを送信する。同様に，JMSアダプタ350は，構造化イベントをJMS MapMessageフォーマットに変換し，JMSネットワーク330にそのMapMessageを送信する。このように，メインフレーム310，CORBA320，およびJMS330のシステムは，それらのネイティブフォーマットで互いにデータを送信し，受信することができる。）との記載からすると，「メッセージブローカサーバ」が構造化イベントの形式で受信した「メッセージ」を転送するものとして，「JMSネットワーク」に「メッセージ」を転送する態様が含まれることが読み取れ，その場合，「JMSアダプタ」が「メッセージブローカサーバ」から受信した「メッセージ」を，「ネイティブフォーマット」である「MapMessage」に変換し，「JMSネットワーク」に「MapMessage」を送信することが読み取れるから，引用例には，
“JMSアダプタは，メッセージブローカサーバから構造化イベントの形式で受信したメッセージを，ネイティブフォーマットであるMapMessageに変換し，JMSネットワークにその変換されたメッセージであるMapMessageを送信する”態様
が記載されていると解される。
　
ウ　以上，（ア）乃至（オ）で示した事項から，引用例には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「メインフレームアダプタと，JMSアダプタと，メッセージブローカサーバとを含み，異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステムであって，
　前記メインフレームアダプタは，メインフレームシステムのCobolプログラム使用のMQSeriesが送信するメッセージであるCobolコピーブックを，構造化イベントフォーマットに変換して，前記構造化イベントフォーマットのメッセージを前記メッセージブローカサーバに送信し，
　前記メッセージブローカサーバは，受信したメッセージを，パブリッシュ/サブスクライブエンジンに格納し，メッセージ転送先が見つかると，前記パブリッシュ/サブスクライブエンジンから前記メッセージを取得し，転送先に対して前記メッセージを構造化イベントの形式で送信し，
　前記JMSアダプタは，前記メッセージブローカサーバから構造化イベントの形式で受信したメッセージを，ネイティブフォーマットであるMapMessageに変換し，JMSネットワークにその変換されたメッセージであるMapMessageを送信する，
ミドルウェアブローカシステム。」　
　
　
（３）参考文献
　
（３−１）参考文献１に記載されている技術的事項
　
　本願の優先日前に頒布された，特開２００３−１７７９３０号公報（平成１５年６月２７日出願公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｈ　「【００４３】
ＵＩＰＣ ＡＰＩ６０
ＵＩＰＣ ＡＰＩ６０は，いずれのタスク(プロセス)でも利用されることができる共有形ライブラリーであり，ＵＩＰＣ３０から提供されるすべての外部機能に対するインタフェースを提供する。要するに，ＵＩＰＣ ＡＰＩ６０は，あるアプリケーションタスクがＵＩＰＣ機能を使用することができるようにインタフェースを提供する。
ＵＩＰＣ ＡＰＩ６０は，内部プロセス通信のためには，ＵＩＰＣプロトコルスタック７０を使用しない。ＵＩＰＣ ＡＰＩ６０は，該当アプリケーションタスク(プロセス)の物理的な位置を示すネットワークアドレスＮ＿ＡＤＤＲを調査して，内部プロセス通信の場合には，図３のＯＩＡ階層５４から提供されるＯＩＡ ＡＰＩライブラリーを通じて直接該当タスク(プロセス)のメッセージキュー(queue)へメッセージを伝達する。
　
（３−２）参考文献２に記載されている技術的事項
　
　本願の優先日前に頒布された，特開平７−３１９８３１号公報（平成７年１２月８日出願公開，以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｊ　「【０００６】
【課題を解決するための手段】上記目的を達成するため，
本発明の同一分散トランザクション処理システムでのＡＰＩの混在方式は，異なるＡＰＩの範囲で作成された複数のプログラムを内蔵するコンピュータがネットワークによって複数結ばれたシステムにおいて，各プログラム間通信を制御するマネージャを備え，当該マネージャの定義形式に，サーバごとに使用するＡＰＩの種類を表わすサーバのタイプを設けて，プログラム間通信を要求する場合，当該サーバのタイプを指定することにより，サーバ起動時に，使用するＡＰＩを選択し，独自ＡＰＩなら従来通りに当該オブジェクト名とデータ資源を処理するプログラム名を指定し，ＸＡＴＭＩインタフェースなら管理するデータ資源を表わす疑似オブジェクト名を登録して通信を行い，クライアント／サーバ型分散処理システムが持つ独自ＡＰＩとＸ／Ｏｐｅｎ準拠の標準ＡＰＩとを一つのシステムで通信可能とすることを特徴とする。また，上記マネジャによるプログラム間通信で，それぞれのＡＰＩの範囲で作成されたアプリケーション・プログラム同士が同一システムで互換性を持ち，通信を行うことを特徴とする。
　
　
（４）対比
　
ア　本件補正発明と引用発明とを対比する。
　
（ア）引用発明の「ミドルウェアブローカシステム」は，「異なるミドルウェアシステム間で通信されるメッセージの仲介をする」ところ，「メインフレームシステム」や「JMSネットワーク」といった「異なるミドルウェアシステム」間で「メッセージ」の交換を可能とする共通インターフェースとして機能するとみることができ，一方，本件補正発明の「共通インタフェースシステム」も「第１ミドルウェアＡＰＩ」から「異なる第２ミドルウェアＡＰＩ」に接続し，「メッセージ」を通信することから，引用発明の「異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム」と本件補正発明の「サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステム」とは，後記する点で相違するものの，“異なるミドルウェアシステム間でメッセージの仲介をする共通インタフェースシステム”である点で共通していると言える。
　
（イ）引用発明は，「メインフレームアダプタは，メインフレームシステムのCobolプログラム使用のMQSeriesが送信するメッセージであるCobolコピーブックを，構造化イベントフォーマットに変換して，前記構造化イベントフォーマットのメッセージを前記メッセージブローカサーバに送信」するところ，引用発明の「メインフレームアダプタ」は，「メインフレームシステム」のミドルウェア「MQSeries」が送信する「メッセージ」について，「ネイティブフォーマット」である「Cobolコピーブック」から，標準の「構造化イベントフォーマット」に変換することから，引用発明の「メインフレームアダプタ」は本件補正発明の「インタフェースアダプタ（４３２）」に対応すると言える。
　ここで，引用発明の「MQSeries」は，上記Ｄの記載からすると，「メインフレームシステム」上で動作するプログラムである「Cobolプログラム」使用のミドルウェアであることから，引用発明の「Cobolプログラム」，「MQSeries」はそれぞれ，本件補正発明の「第１アプリケーション」，「第１ミドルウェアプラットフォームインタフェース」に相当すると言える。
　また，引用発明の「Cobolコピーブック」は「Cobolプログラム」に関連し，「MQSeries」が送信する「メッセージ」であり，本件補正発明の「第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出し」は「第１ミドルウェア」でのメッセージ通信プロトコルであることは明らかであるから，引用発明の「Cobolコピーブック」の「送信」と本件補正発明の「第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出し」とは，“第１ミドルウェアメッセージプロトコル”である点で共通すると言える。
　さらに，引用発明の「構造化イベントフォーマットのメッセージ」の「送信」は，「Cobolコピーブック」の「送信」と等価な標準のメッセージ通信プロトコルであると言えることから，引用発明の「構造化イベントフォーマットのメッセージ」の「送信」は，本件補正発明の「中間メッセージプロトコル」の「実行」に相当すると言える。
　そうすると，引用発明の「メインフレームアダプタは，メインフレームシステムのCobolプログラム使用のミドルウェアが送信するメッセージであるCobolコピーブックを，構造化イベントフォーマットに変換して，前記構造化イベントフォーマットのメッセージを前記メッセージブローカサーバに送信し」と本件補正発明の「第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しを，予め規定された共通ＡＰＩへ接続するようコード化されたインタフェースアダプタ（４３２）」であって，「前記インタフェースアダプタ（４３２）は，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記ミドルウェアＡＰＩ呼出しと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し」とは，後記する点で相違するものの，“第１アプリケーションに関連付けられた第１ミドルウェアメッセージプロトコルを，予め規定された中間メッセージプロトコルへ接続するインタフェースアダプタ”を含む点と，“インタフェースアダプタは，第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，第１ミドルウェアメッセージプロトコルと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行する”点で共通していると言える。
　
（ウ）引用発明においては，「JMSアダプタは，前記メッセージブローカサーバから構造化イベントの形式で受信したメッセージを，ネイティブフォーマットであるMapMessageに変換し，JMSネットワークにその変換されたメッセージであるMapMessageを送信する」ところ，引用発明の「JMSアダプタ」は，標準の「構造化イベントの形式で受信したメッセージ」を，「JMSネットワーク」の「ネイティブフォーマットであるMapMessageに変換」することから，引用発明の「JMSアダプタ」は本件補正発明の「ミドルウェアアダプタ（４３４）」に対応すると言える。
　ここで，引用発明の「JMSネットワーク」では，上記Ｆの「メッセージブローカサーバ360は，発行者の1つによって送られたメッセージと，メッセージへの関心を登録している購読者との間の一致を見つけると，メッセージブローカサーバ360は，パブリッシュ/サブスクライブエンジン370のチャネルからそのメッセージを取得し，そして，適切な購読者にそのメッセージを送信する。」との記載からみて，メッセージ購読者のアプリケーションが動作していることは自明であり，「メッセージ」の宛先とみることができるから，引用発明の「JMSネットワーク」は，本件補正発明の「第２アプリケーションであるメッセージ宛先」に相当すると言える。
　また，引用発明の「MapMessage」の「送信」は，「構造化イベントの形式で受信したメッセージ」の「送信」と等価な，メッセージ宛先に基づくメッセージ通信プロトコルであると言えることから，引用発明の「MapMessage」の「送信」は，本件補正発明の「ターゲットメッセージプロトコル」の「実行」に相当すると言える。
　そうすると，引用発明の「JMSアダプタは，前記メッセージブローカサーバから構造化イベントの形式で受信したメッセージを，ネイティブフォーマットであるMapMessageに変換し，JMSネットワークにその変換されたメッセージであるMapMessageを送信する」と本件補正発明の「ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）」であって，「前記ミドルウェアアダプタ（４３４）は，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって，前記第２ミドルウェアＡＰＩと互換性のあるターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する」とは，後記する点で相違するものの，“第１ミドルウェアメッセージプロトコルと等価の中間メッセージプロトコルから，前記第１ミドルウェアメッセージプロトコルとは異なるターゲットメッセージプロトコルへと接続するミドルウェアアダプタ”を含む点と，“ミドルウェアアダプタは，第２アプリケーションであるメッセージ宛先に基づいて，中間メッセージプロトコルと等価のターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する”点で共通していると言える。
　
イ　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞ 
　
「異なるミドルウェアシステム間でメッセージの仲介をする共通インタフェースシステムであって，
　第１アプリケーションに関連付けられた第１ミドルウェアメッセージプロトコルを，予め規定された中間メッセージプロトコルへ接続するインタフェースアダプタと，
　前記第１ミドルウェアメッセージプロトコルと等価の前記中間メッセージプロトコルから，前記第１ミドルウェアメッセージプロトコルとは異なるターゲットメッセージプロトコルへと接続するミドルウェアアダプタと
を含み，
　前記インタフェースアダプタは，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記第１ミドルウェアメッセージプロトコルと等価の前記中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し，
　前記ミドルウェアアダプタは，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価の前記ターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する，
共通インタフェースシステム。」　
　
＜相違点１＞　
　
　本件補正発明は，「サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステム」であるのに対して，引用発明は，「異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム」である点。
　
＜相違点２＞
　
　第１ミドルウェアメッセージプロトコルの実行に関し，本件補正発明は，「第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出し」により実行しているのに対して，引用発明は，第１ミドルウェアプラットフォームインタフェースである「MQSeries」が「Cobolコピーブック」を「送信」しており，「ＡＰＩ」によりメッセージプロトコルを実行することについて言及されていない点。
　
＜相違点３＞
　
　中間メッセージプロトコルおよびターゲットメッセージプロトコルの実行に関し，本件補正発明は，「共通ＡＰＩ」により「中間メッセージプロトコル」を実行し，「第２ミドルウェアＡＰＩ」により「ターゲットメッセージプロトコル」を実行しているのに対して，引用発明は，「ＡＰＩ」によりメッセージ通信プロトコルを実行することについて言及されていない点。
　
＜相違点４＞
　
　インタフェースアダプタとミドルウェアアダプタとの連携に関し，本件補正発明は，「インタフェースアダプタ」と「ミドルウェアアダプタ」との間に中継する手段を有しないのに対して，引用発明は「メインフレームアダプタ」と「JMSアダプタ」との間の「メッセージブローカサーバ」がメッセージを中継する点。
　
　
（５）当審の判断
　
　上記相違点１乃至４について検討する。
　
ア　相違点１について
　
　引用発明の「ミドルウェアブローカシステム」は，「異なるミドルウェアシステム間で通信されるメッセージの仲介をする」ところ，「メッセージ」は，互いに「異なるミドルウェアシステム」に関連した異なるアプリケーション間で通信されると解される。
　また，サービス指向アーキテクチャー（ＳＯＡ）に基づくシステムにおける異なるアプリケーションの間で，メッセージ通信を可能とすることは，例えば，米国特許出願公開第２００７／０１２４１５６号明細書（段落［0045］〜［0048］を参照）に記載されるように，本願優先日前には当該技術分野の周知技術であった。
　そうすると，引用発明において，上記周知技術を適用し，適宜，異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステムを，サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステムとすること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
イ　相違点２及び相違点３について
　
　引用発明では，「MQSeries」が「Cobolコピーブック」を「送信」し，「メインフレームアダプタ」が「構造化イベントフォーマットのメッセージ」を「送信」し，「JMSアダプタ」が「MapMessage」を「送信」することで，メッセージ通信プロトコルを実行していると解されるが，これらメッセージの送信を如何なるインタフェースを用いて実行しているか特に言及されていない。
　しかしながら，プログラム間のメッセージ通信をＡＰＩ（アプリケーションプログラミングインタフェース）呼び出しにより実現することは，例えば，参考文献１（上記Ｈを参照），参考文献２（上記Ｊを参照）に記載されるように，本願優先日前には当該技術分野の周知慣用の手法であり，プログラム間のメッセージ通信にＡＰＩを利用するか否かは必要に応じて選択し得た設計的事項であった。
　そうすると，引用発明において，上記周知慣用手法を適用し，MQSeriesによるCobolコピーブックの送信，メインフレームアダプタによる構造化イベントフォーマットメッセージの送信，JMSアダプタによるMapMessageの送信に係るメッセージ通信プロトコルを，適宜，対応するＡＰＩを呼び出すことにより実行すること，すなわち，上記相違点２及び相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
ウ　相違点４について
　
　引用発明は「メインフレームアダプタ」と「JMSアダプタ」との間の「メッセージブローカサーバ」がメッセージを中継するところ，「メッセージブローカサーバ」は受信した「構造化イベントフォーマットのメッセージ」を変換することなく，転送先が見つかるまでは「受信したメッセージを，パブリッシュ/サブスクライブエンジンに格納し」，転送先のアダプタへ送信していると言える。
　そして，引用発明が上記「メッセージブローカサーバ」のような構成を備える必要があるのは，「メインフレームアダプタ」と「JMSアダプタ」の組合せ以外の異種ミドルウェア間でメッセージ転送を可能としているからに他ならない。
　そうすると，引用発明において，メッセージを転送するミドルウェアの組合せを固定することにより，メインフレームアダプタが送信する構造化イベントフォーマットのメッセージを，JMSアダプタが中継手段を用いることなく直接受信できるようにすること，すなわち，上記相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　
エ　小括
　
　上記で検討したごとく，相違点１乃至相違点４に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
　
（６）補正却下の決定のむすび
　
　以上のように，本件補正は，上記「３　独立特許要件」で指摘したとおり，本件補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって，上記補正却下の決定の結論のとおり決定する。
　
　
第３　本願発明について
　
１　本願発明の認定 
  
　平成２５年８月２３日付けの手続補正は上記のとおり却下されたので，本件補正後の請求項１に対応する本件補正前の請求項に係る発明（以下，「本願発明」という。）は，平成２５年１月３１日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「　サービス指向アーキテクチャ（ＳＯＡ）にアプリケーションを統合するための共通インタフェースシステムであって，
　第１アプリケーションに関連付けられた第１ミドルウェアＡＰＩに基づくミドルウェアＡＰＩ呼出しであって，予め規定された共通ＡＰＩへのミドルウェアＡＰＩ呼出しを受信するようコード化されたインタフェースアダプタ（４３２）と，
　前記ミドルウェアＡＰＩ呼出しを予め規定された共通ＡＰＩから第１ミドルウェアＡＰＩとは異なる第２ミドルウェアＡＰＩと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ（４３４）と
を含む共通インタフェースシステム。」　
　
２　引用例に記載されている技術的事項及び引用発明の認定 
　
　原査定の拒絶の理由に引用された，引用発明は，前記「第２　平成２５年８月２３日付けの手続補正についての補正却下の決定」の「３　独立特許要件」の「（２）引用例」に記載したとおりである。
　
３　対比・判断  
　
　本願発明は，前記「第２　平成２５年８月２３日付けの手続補正についての補正却下の決定」の「３　独立特許要件」で検討した本件補正発明の発明特定事項から
　「前記インタフェースアダプタ（４３２）は，前記第１アプリケーションに関連付けられた第１ミドルウェアプラットフォームインタフェースに基づいて，前記ミドルウェアＡＰＩ呼出しと等価の中間メッセージプロトコルを特定し，特定した前記中間メッセージプロトコルを実行し」の限定事項を削除し，
　「前記ミドルウェアアダプタ（４３４）は，第２アプリケーションであるメッセージ宛先に基づいて，前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって，前記第２ミドルウェアＡＰＩと互換性のあるターゲットメッセージプロトコルを特定し，特定した前記ターゲットメッセージプロトコルを実行する」の限定事項を削除したものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２５年８月２３日付けの手続補正についての補正却下の決定」の「３　独立特許要件」の「（２）引用例」乃至「（５）当審の判断」に記載したとおり，引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。 
　
　
第４　むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。