• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1307301
審判番号 不服2013-16351  
総通号数 192 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-12-25 
種別 拒絶査定不服の審決 
審判請求日 2013-08-23 
確定日 2015-11-04 
事件の表示 特願2010-536042「共通メッセージングインタフェースを用いたサービス指向アーキテクチャアプリケーションの統合」拒絶査定不服審判事件〔平成21年 6月 4日国際公開,WO2009/070412,平成23年 2月17日国内公表,特表2011-505048〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2008年10月31日(パリ条約による優先権主張外国庁受理2007年11月27日(以下,「優先日」という。),米国)を国際出願日とする出願であって,その手続の経緯は以下のとおりである。

平成22年 5月27日 :国内書面の提出
平成22年 7月26日 :翻訳文の提出
平成23年 8月26日 :出願審査請求書の提出
平成24年 7月27日付け :拒絶理由の通知
平成25年 1月31日 :意見書,手続補正書の提出
平成25年 4月15日付け :拒絶査定
平成25年 8月23日 :審判請求書,手続補正書の提出
平成25年10月22日 :前置報告
平成25年11月28日付け :審尋
平成26年 2月24日 :回答書の提出


第2 平成25年8月23日付けの手続補正についての補正却下の決定

[補正却下の決定の結論]

平成25年8月23日付けの手続補正を却下する。

[理由]

1 補正の内容

平成25年8月23日付けの手続補正(以下,「本件補正」という。)の内容は,平成25年1月31日付けの手続補正により補正された特許請求の範囲の請求項1乃至4の記載

「 【請求項1】
サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステムであって,
第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しであって,予め規定された共通APIへのミドルウェアAPI呼出しを受信するようコード化されたインタフェースアダプタ(432)と,
前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)と
を含む共通インタフェースシステム。
【請求項2】
前記インタフェースアダプタ(432)および前記ミドルウェアアダプタ(434)が,それぞれ実行時ライブラリを含む,請求項1に記載の共通インタフェースシステム。
【請求項3】
前記インタフェースアダプタ(432)が,少なくとも1つのAPI呼出しを受信するようコード化されている,請求項1に記載の共通インタフェースシステム。
【請求項4】
前記ミドルウェアアダプタ(434)が,第1ミドルウェアAPIとは異なるミドルウェアAPIと互換性のある実行時ライブラリを呼び出すようコード化されている,請求項1に記載の共通インタフェースシステム。」
(以下,この特許請求の範囲に記載された請求項を「本件補正前の請求項」という。)

を,

「 【請求項1】
サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステムであって,
第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しを,予め規定された共通APIへ接続するようコード化されたインタフェースアダプタ(432)と,
前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)と
を含み,
前記インタフェースアダプタ(432)は,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記ミドルウェアAPI呼出しと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し,
前記ミドルウェアアダプタ(434)は,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって,前記第2ミドルウェアAPIと互換性のあるターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する,
共通インタフェースシステム。
【請求項2】
前記インタフェースアダプタ(432)および前記ミドルウェアアダプタ(434)が,それぞれ実行時ライブラリを含む,請求項1に記載の共通インタフェースシステム。
【請求項3】
前記インタフェースアダプタ(432)が,少なくとも1つのAPI呼出しを受信するようコード化されている,請求項1に記載の共通インタフェースシステム。
【請求項4】
前記ミドルウェアアダプタ(434)が,第1ミドルウェアAPIとは異なるミドルウェアAPIと互換性のある実行時ライブラリを呼び出すようコード化されている,請求項1に記載の共通インタフェースシステム。」(当審注:下線は,出願人が付与したものである。以下,この特許請求の範囲に記載された請求項を「本件補正後の請求項」という。)

に補正するものである。

そして,本件補正は,願書に最初に添付した明細書,特許請求の範囲又は図面に記載した事項の範囲内においてなされており,特許法第17条の2第3項の規定に適合している。
また,本件補正は,シフト補正をしようとするものではなく,特許法第17条の2第4項の規定に適合している。


2 目的要件

本件補正は,上記「第2 1 補正の内容」のとおり本件審判の請求と同時にする補正であり,特許請求の範囲について補正をしようとするものであるから,本件補正が,特許法第17条の2第5項の規定を満たすものであるか否か,すなわち,本件補正が,特許法第17条の2第5項に規定する請求項の削除,特許請求の範囲の減縮(特許法第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る),誤記の訂正,或いは,明りょうでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る)の何れかを目的としたものであるかについて,以下に検討する。

(1)本件補正前の請求項と,本件補正後の請求項とを比較すると,本件補正後の請求項1,2,3,4はそれぞれ,本件補正前の請求項1,2,3,4に対応することは明らかである。

(2)本件補正は,下記の補正事項1,2よりなるものである。

<補正事項1>
本件補正前の請求項1の
「第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しであって,予め規定された共通APIへのミドルウェアAPI呼出しを受信するようコード化されたインタフェースアダプタ(432)」との記載を,
本件補正後の請求項1の
「第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しを,予め規定された共通APIへ接続するようコード化されたインタフェースアダプタ(432)」,「前記インタフェースアダプタ(432)は,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記ミドルウェアAPI呼出しと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し」との記載に限定することを目的とするものであり,本件補正によっても,補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。

<補正事項2>
本件補正前の請求項1の
「前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)」との記載を,
本件補正後の請求項1の
「前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)」,「前記ミドルウェアアダプタ(434)は,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって,前記第2ミドルウェアAPIと互換性のあるターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する」との記載に限定することを目的とするものであり,本件補正によっても,補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。

(3)したがって,上記補正事項1,2は限定的減縮を目的とするものであり,本件補正は,特許法第17条の2第5項第2号に掲げる特許請求の範囲の減縮を目的とするものに該当すると言えることから,特許法第17条の2第5項の規定に適合するものである。


3 独立特許要件

以上のように,本件補正は,限定的減縮を目的とする上記補正事項1,2を含むものである。そこで,限定的減縮を目的として補正された本件補正後の請求項1に記載された発明(以下,「本件補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)以下に検討する。

(1)本件補正発明

本件補正発明は,上記平成25年8月23日付けの手続補正書により補正された特許請求の範囲,明細書及び図面の記載からみて,その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「 サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステムであって,
第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しを,予め規定された共通APIへ接続するようコード化されたインタフェースアダプタ(432)と,
前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)と
を含み,
前記インタフェースアダプタ(432)は,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記ミドルウェアAPI呼出しと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し,
前記ミドルウェアアダプタ(434)は,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって,前記第2ミドルウェアAPIと互換性のあるターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する,
共通インタフェースシステム。」


(2)引用例

ア 本願の優先日前に頒布され,原審の拒絶査定の理由である上記平成24年7月27日付けの拒絶理由通知において引用された,米国特許第7152094号明細書(2006年12月19日公開,以下,「引用例」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「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. 」(第1欄第18行-23行)
(当審仮訳; 発明の分野
本発明は,異種のコンピュータ・システムを含むコンピュータネットワーク内の通信の分野,特に,異種のミドルウェア製品で接続されたシステム間の通信に関するものである。)

B 「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. The Middleware Brokering System Adapter transforms data messages from the native format of a middleware computing product or a mainframe computing system into a format known as a structured event and from a structured event into the native format of the middleware product or the mainframe system. In an embodiment of the invention, the Middleware Brokering System Adapter maps the fields of a Cobol copybook onto the fields of a structured event and the fields of a structured event onto the fields of a copybook. In an alternative embodiment, the Middleware Brokering System Adapter maps the fields of a Java Messaging Service MapMessage onto the fields of a structured event and the fields of a structured event onto the fields of a MapMessage. 」(第3欄35行-57行)
(当審仮訳; 発明の概要
以下,ミドルウェアブローカシステムアダプタと呼ばれる本発明は,ミドルウェアブローカシステムで有用なコンポーネントである。ミドルウェアブローカシステムは,異なるミドルウェアシステム間の仲介者,またはメタミドルウェア,デバイスとして機能する。各ミドルウェアサービスは,そのネイティブのデータフォーマットとプログラミング構文で,ミドルウェアブローカシステムにメッセージを送信し,ミドルウェアブローカシステムからのメッセージを受け取ることができる。ミドルウェアブローカシステムアダプタは,データメッセージを,ミドルウェア製品またはメインフレーム・システムのネイティブフォーマットから構造化イベントとして知られるフォーマットに変換し,また,構造化イベントからミドルウェア製品またはメインフレーム・システムのネイティブフォーマットに変換する。本発明の実施形態では,ミドルウェアブローカシステムアダプタは,Cobolコピーブックのフィールドを構造化イベントのフィールドに,構造化イベントのフィールドをコピーブックのフィールドにマッピングする。別の実施形態では,ミドルウェアブローカシステムアダプタはJavaのメッセージングサービスMapMessageのフィールドを構造化イベントのフィールドに,構造化イベントのフィールドをMapMessageのフィールドにマッピングする。)

C 「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. Details of the operation of these components are provided below. In alternative embodiments, other adapters could be used instead of or in addition to the mainframe adapter 340 and the JMS adapter 350 if other types of computer systems or middleware products needed to be connected to the Middleware Brokering System. A separate CORBA adapter is not needed since CORBA applications and the Middleware Brokering System can communicate directly with each other using their common data format, the structured event. 」(第4欄42行-57行)
(当審仮訳; 図3の実施形態では,ミドルウェアブローカシステムは,メインフレームアダプタ340,JMSアダプタ350,及びメッセージブローカサーバ360を含む。メインフレームアダプタ340,JMSアダプタ350,およびメッセージブローカサーバ360は,ユニットとして実質的に機能し,同じ物理デバイスまたは異なるデバイス上に置くことができるソフトウェアコンポーネントである。これらコンポーネントの動作の詳細を以下に提示する。別の実施形態では,他のタイプのコンピュータシステムまたはミドルウェア製品が,ミドルウェアブローカシステムに接続する必要がある場合には,メインフレームアダプタ340,JMSアダプタ350の代わりに,あるいは,それらに加えて,他のアダプタを使用することができる。CORBAアプリケーションとミドルウェアブローカシステムは,それらの共通のデータフォーマットである,構造化イベントを使用して互いに直接通信することができるために,別個のCORBAアダプタは必要ではない。)

D 「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. In alternative embodiments, other mainframe programming languages and other equivalent data structures commonly used in those languages could be used to prepare the data. For purposes of this application, the term copybook is used to refer to any such data structure. Information about the subject matter of the message is included in the copybook which, as described below, will be used by the Middleware Brokering System to determine if the subscribers are interested in the message. 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. In alternative embodiments, additional interface layers may exist between the mainframe 310 and MQSeries or between MQSeries and the mainframe adapter 340 . 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 . 」(第4欄58行-第5欄19行)
(当審仮訳; 好ましい実施形態では,メインフレームシステム310は,ミドルウェアブローカシステムと対話するために,IBMのMQSeriesのミドルウェアを使用する。別の実施形態では,メインフレーム310とミドルウェアブローカシステムとの間でデータを転送するために,MQSeriesと同等の任意のミドルウェア製品を使用することができる。メインフレーム310上で動作するCobolプログラムは,CORBAネットワーク320,JMSネットワーク330,または両方にメッセージを送信する必要があると,データは,Cobolコピーブックとして知られている構造に配列することにより準備される。別の実施形態では,他のメインフレームのプログラミング言語や,これら言語で一般的に使用される他の同等なデータ構造が,データを準備するために使用することができる。この用途について,コピーブックという用語が,任意のそのようなデータ構造を指すことに使用される。メッセージの主題の情報が,後述するように,購読者がメッセージに興味を持っているかどうかを決定するためにミドルウェアブローカシステムにより使用されるコピーブックに含まれている。メインフレーム310上で動作するプログラムは,MQSeriesにコピーブックを送信するための標準的なプログラミングコマンドを使用する。 MQSeriesはそれから,後述するように,メインフレームアダプタ340にデータを送信する。別の実施形態では,追加的なインターフェイス層が,メインフレーム310とMQSeriesの間,またはMQSeriesとメインフレームアダプタ340との間に存在してもよい。メインフレームアダプタ340は,これも後述するように,コピーブックを,構造化イベントとして知られる標準的なフォーマットへ変換する。メインフレームアダプタ340はそれから,メッセージブローカサーバ360に構造化イベントフォーマットのメッセージを送信する。)

E 「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. Only one adapter is needed for each disparate type of middleware system to be connected. Without the message brokering server 360 and the structured event, the different types of systems would need to operate in a point-to-point fashion and the number of adapters needed would be greater. 」(第5欄40行-57行)
(当審仮訳; 図3に示された構成に加えて,他のタイプのコンピューティングシステム,またはミドルウェアが,同様の方法で,メッセージブローカサーバ360に自身のデータを発行するであろう。ミドルウェアブローカシステム以外のネイティブ言語でミドルウェアが動作する場合,データはアプリケーションのネイティブフォーマットでアダプタに送信される。アダプタは,構造化イベントフォーマットにデータを変換し,メッセージブローカサーバ360にその構造化イベントを送信する。メッセージブローカサーバ360及び構造化イベントを使用することにより,メインフレームシステムと異種ミドルウェア製品をパブリッシュ/サブスクライブモードで相互に通信することを可能にする。唯一のアダプタが,接続するミドルウェアシステムのそれぞれ異なるタイプに対して必要とされる。メッセージブローカサーバ360及び構造化イベントがないとすれば,さまざまなタイプのシステムがポイントトゥーポイント方式で動作する必要があり,必要なアダプタの数も多くなるであろう。)

F 「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. Messages are stored in the publish/subscribe engine 370 until the message expires or has been delivered to all subscribers successfully. Expiration occurs when the age of the message exceeds a preset limit or the number of messages exceeds the limit of the storage mechanism. In a preferred embodiment, the publish/subscribe engine 370 is a product developed by Vitria Technology known as BusinessWare. In alternative embodiments, any equivalent publish/subscribe engine could be substituted for the Vitria product. 」(第5欄58行-第6欄18行)
(当審仮訳; メッセージブローカサーバ360が受信したメッセージは,潜在するパブリッシュ/サブスクライブエンジン370に渡される。メッセージブローカサーバ360とパブリッシュ/サブスクライブエンジン370は,メインフレームシステム310,CORBAネットワーク320,およびJMSネットワーク330の間で転送されるメッセージの仲介者として一緒に動作する。メッセージブローカサーバ360は,購読者のリストと,彼らが受け取るように登録されたメッセージの種類のリストを保持する。パブリッシュ/サブスクライブエンジン370は,チャネルに格納できるメッセージの数,チャネルに格納できるメッセージの長さ,およびチャネルでのメッセージの優先度などの様々な属性を有して構成されるチャネルにメッセージを格納する。メッセージブローカサーバ360は,発行者の1つによって送られたメッセージと,メッセージへの関心を登録している購読者との間の一致を見つけると,メッセージブローカサーバ360は,パブリッシュ/サブスクライブエンジン370のチャネルからそのメッセージを取得し,そして,適切な購読者にそのメッセージを送信する。メッセージは,メッセージが期限切れになるか,すべての購読者にうまく配信されるまで,パブリッシュ/サブスクライブエンジン370に格納される。メッセージの経過時間が予め設定された限度を超えるか,メッセージの数が記憶機構の制限を超えたときに有効性の満了が発生する。好ましい実施形態では,パブリッシュ/サブスクライブエンジン370は,BusinessWareとして知られているビトリア・テクノロジー社が開発した製品である。別の実施形態では,任意の同等のパブリッシュ/サブスクライブエンジンをビトリア社製品の代わりに用いることができる。)

G 「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. The underlying conversion process carried out by the Middleware Brokering System is transparent to the participating networks. 」(第6欄19行-33行)
(当審仮訳; メッセージブローカサーバ360は,パブリッシュ/サブスクライブエンジン370からデータを取得し,メインフレームアダプタ340,JMSアダプタ350,かつ/あるいは直接CORBAネットワーク320に対して,そのデータを構造化イベントの形式で渡す。先に説明したプロセスの逆の変換処理においては,メインフレームアダプタ340は構造化イベントをコピーブックに変換し,メインフレーム310にそのコピーブックを送信する。同様に,JMSアダプタ350は,構造化イベントをJMS MapMessageフォーマットに変換し,JMSネットワーク330にそのMapMessageを送信する。このように,メインフレーム310,CORBA320,およびJMS330のシステムは,それらのネイティブフォーマットで互いにデータを送信し,受信することができる。ミドルウェアブローカシステムによって実行される潜在的変換処理は,接続するネットワークに透過的である。)


イ ここで,上記引用例に記載されている事項を検討する。

(ア)上記Aの「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. 」(当審仮訳;本発明は,異種のコンピュータ・システムを含むコンピュータネットワーク内の通信の分野,特に,異種のミドルウェア製品で接続されたシステム間の通信に関するものである。)との記載,上記Bの「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.」(当審仮訳;以下,ミドルウェアブローカシステムアダプタと呼ばれる本発明は,ミドルウェアブローカシステムで有用なコンポーネントである。ミドルウェアブローカシステムは,異なるミドルウェアシステム間の仲介者,またはメタミドルウェア,デバイスとして機能する。各ミドルウェアサービスは,そのネイティブのデータフォーマットとプログラミング構文で,ミドルウェアブローカシステムにメッセージを送信し,ミドルウェアブローカシステムからのメッセージを受け取ることができる。)との記載からすると,「異なるミドルウェアシステム」間で「メッセージ」が通信され,当該「メッセージ」を「ミドルウェアブローカシステム」が仲介することが読み取れるから,引用例には,
“異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム”
が記載されていると解される。

(イ)上記Cの「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アダプタと,メッセージブローカサーバとを含”む“ミドルウェアブローカシステム”
が記載されていると解される。

(ウ)上記Dの「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プログラム」から送信されるメッセージであることが読み取れ,また,上記Dの「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」が「メインフレームアダプタ」に送信する「メッセージ」であると解される。
そして,上記Dの「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コピーブックを,構造化イベントフォーマットに変換して,前記構造化イベントフォーマットのメッセージをメッセージブローカサーバに送信”する態様
が記載されていると解される。

(エ)上記Fの「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ネットワーク」の間で転送されるメッセージの仲介者として動作し,受信した「メッセージ」を「パブリッシュ/サブスクライブエンジン」に渡して格納することが読み取れる。
また,上記Fの「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のチャネルからそのメッセージを取得し,そして,適切な購読者にそのメッセージを送信する。)との記載からすると,「メッセージブローカサーバ」は「メッセージ」の購読者,すなわち「転送先」が見つかると,当該「メッセージ」を「パブリッシュ/サブスクライブエンジン」から取得して,「転送先」に送信することが読み取れるから,引用例には,
“メッセージブローカサーバは,受信したメッセージを,パブリッシュ/サブスクライブエンジンに格納し,メッセージ転送先が見つかると,前記パブリッシュ/サブスクライブエンジンから前記メッセージを取得し,転送先に対して前記メッセージを構造化イベントの形式で送信”する態様
が記載されていると解される。

(オ)上記(ア)での検討のとおり,引用例には,異なるミドルウェアシステム間でメッセージが通信され,該メッセージを「ミドルウェアブローカシステム」が仲介することが記載されていると解され,また,上記Eの「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及び構造化イベントを使用することにより,メインフレームシステムと異種ミドルウェア製品をパブリッシュ/サブスクライブモードで相互に通信することを可能にする。)との記載からすると,「メッセージブローカサーバ」により,「構造化イベントフォーマット」の「メッセージ」を使用して,「メインフレームシステム」と異なる「ミドルウェアシステム」間で「メッセージ」が通信されることが読み取れる。
そして,上記Fの「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ネットワーク」に転送する態様を読み取ることができる。

さらに,上記Gの「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を送信する,
ミドルウェアブローカシステム。」


(3)参考文献

(3-1)参考文献1に記載されている技術的事項

本願の優先日前に頒布された,特開2003-177930号公報(平成15年6月27日出願公開,以下,「参考文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

H 「【0043】UIPC API60
UIPC API60は,いずれのタスク(プロセス)でも利用されることができる共有形ライブラリーであり,UIPC30から提供されるすべての外部機能に対するインタフェースを提供する。要するに,UIPC API60は,あるアプリケーションタスクがUIPC機能を使用することができるようにインタフェースを提供する。また,ネットワークアドレスN_ADDR及びアプリケーション識別子APP_IDに基づいて外部及び内部プロセス通信経路を決定する。UIPC API60は,内部プロセス通信のためには,UIPCプロトコルスタック70を使用しない。UIPC API60は,該当アプリケーションタスク(プロセス)の物理的な位置を示すネットワークアドレスN_ADDRを調査して,内部プロセス通信の場合には,図3のOIA階層54から提供されるOIA APIライブラリーを通じて直接該当タスク(プロセス)のメッセージキュー(queue)へメッセージを伝達する。外部プロセス通信の場合には,UIPC API60は,目的地を探すルーチングのためにUIPCプロトコルスタック70のメッセージキューへメッセージを伝達する。」

(3-2)参考文献2に記載されている技術的事項

本願の優先日前に頒布された,特開平7-319831号公報(平成7年12月8日出願公開,以下,「参考文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

J 「【0006】
【課題を解決するための手段】上記目的を達成するため,本発明の同一分散トランザクション処理システムでのAPIの混在方式は,異なるAPIの範囲で作成された複数のプログラムを内蔵するコンピュータがネットワークによって複数結ばれたシステムにおいて,各プログラム間通信を制御するマネージャを備え,当該マネージャの定義形式に,サーバごとに使用するAPIの種類を表わすサーバのタイプを設けて,プログラム間通信を要求する場合,当該サーバのタイプを指定することにより,サーバ起動時に,使用するAPIを選択し,独自APIなら従来通りに当該オブジェクト名とデータ資源を処理するプログラム名を指定し,XATMIインタフェースなら管理するデータ資源を表わす疑似オブジェクト名を登録して通信を行い,クライアント/サーバ型分散処理システムが持つ独自APIとX/Open準拠の標準APIとを一つのシステムで通信可能とすることを特徴とする。また,上記マネジャによるプログラム間通信で,それぞれのAPIの範囲で作成されたアプリケーション・プログラム同士が同一システムで互換性を持ち,通信を行うことを特徴とする。」


(4)対比

ア 本件補正発明と引用発明とを対比する。

(ア)引用発明の「ミドルウェアブローカシステム」は,「異なるミドルウェアシステム間で通信されるメッセージの仲介をする」ところ,「メインフレームシステム」や「JMSネットワーク」といった「異なるミドルウェアシステム」間で「メッセージ」の交換を可能とする共通インターフェースとして機能するとみることができ,一方,本件補正発明の「共通インタフェースシステム」も「第1ミドルウェアAPI」から「異なる第2ミドルウェアAPI」に接続し,「メッセージ」を通信することから,引用発明の「異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム」と本件補正発明の「サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステム」とは,後記する点で相違するものの,“異なるミドルウェアシステム間でメッセージの仲介をする共通インタフェースシステム”である点で共通していると言える。

(イ)引用発明は,「メインフレームアダプタは,メインフレームシステムのCobolプログラム使用のMQSeriesが送信するメッセージであるCobolコピーブックを,構造化イベントフォーマットに変換して,前記構造化イベントフォーマットのメッセージを前記メッセージブローカサーバに送信」するところ,引用発明の「メインフレームアダプタ」は,「メインフレームシステム」のミドルウェア「MQSeries」が送信する「メッセージ」について,「ネイティブフォーマット」である「Cobolコピーブック」から,標準の「構造化イベントフォーマット」に変換することから,引用発明の「メインフレームアダプタ」は本件補正発明の「インタフェースアダプタ(432)」に対応すると言える。
ここで,引用発明の「MQSeries」は,上記Dの記載からすると,「メインフレームシステム」上で動作するプログラムである「Cobolプログラム」使用のミドルウェアであることから,引用発明の「Cobolプログラム」,「MQSeries」はそれぞれ,本件補正発明の「第1アプリケーション」,「第1ミドルウェアプラットフォームインタフェース」に相当すると言える。
また,引用発明の「Cobolコピーブック」は「Cobolプログラム」に関連し,「MQSeries」が送信する「メッセージ」であり,本件補正発明の「第1ミドルウェアAPIに基づくミドルウェアAPI呼出し」は「第1ミドルウェア」でのメッセージ通信プロトコルであることは明らかであるから,引用発明の「Cobolコピーブック」の「送信」と本件補正発明の「第1ミドルウェアAPIに基づくミドルウェアAPI呼出し」とは,“第1ミドルウェアメッセージプロトコル”である点で共通すると言える。
さらに,引用発明の「構造化イベントフォーマットのメッセージ」の「送信」は,「Cobolコピーブック」の「送信」と等価な標準のメッセージ通信プロトコルであると言えることから,引用発明の「構造化イベントフォーマットのメッセージ」の「送信」は,本件補正発明の「中間メッセージプロトコル」の「実行」に相当すると言える。
そうすると,引用発明の「メインフレームアダプタは,メインフレームシステムのCobolプログラム使用のミドルウェアが送信するメッセージであるCobolコピーブックを,構造化イベントフォーマットに変換して,前記構造化イベントフォーマットのメッセージを前記メッセージブローカサーバに送信し」と本件補正発明の「第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しを,予め規定された共通APIへ接続するようコード化されたインタフェースアダプタ(432)」であって,「前記インタフェースアダプタ(432)は,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記ミドルウェアAPI呼出しと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し」とは,後記する点で相違するものの,“第1アプリケーションに関連付けられた第1ミドルウェアメッセージプロトコルを,予め規定された中間メッセージプロトコルへ接続するインタフェースアダプタ”を含む点と,“インタフェースアダプタは,第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,第1ミドルウェアメッセージプロトコルと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行する”点で共通していると言える。

(ウ)引用発明においては,「JMSアダプタは,前記メッセージブローカサーバから構造化イベントの形式で受信したメッセージを,ネイティブフォーマットであるMapMessageに変換し,JMSネットワークにその変換されたメッセージであるMapMessageを送信する」ところ,引用発明の「JMSアダプタ」は,標準の「構造化イベントの形式で受信したメッセージ」を,「JMSネットワーク」の「ネイティブフォーマットであるMapMessageに変換」することから,引用発明の「JMSアダプタ」は本件補正発明の「ミドルウェアアダプタ(434)」に対応すると言える。
ここで,引用発明の「JMSネットワーク」では,上記Fの「メッセージブローカサーバ360は,発行者の1つによって送られたメッセージと,メッセージへの関心を登録している購読者との間の一致を見つけると,メッセージブローカサーバ360は,パブリッシュ/サブスクライブエンジン370のチャネルからそのメッセージを取得し,そして,適切な購読者にそのメッセージを送信する。」との記載からみて,メッセージ購読者のアプリケーションが動作していることは自明であり,「メッセージ」の宛先とみることができるから,引用発明の「JMSネットワーク」は,本件補正発明の「第2アプリケーションであるメッセージ宛先」に相当すると言える。
また,引用発明の「MapMessage」の「送信」は,「構造化イベントの形式で受信したメッセージ」の「送信」と等価な,メッセージ宛先に基づくメッセージ通信プロトコルであると言えることから,引用発明の「MapMessage」の「送信」は,本件補正発明の「ターゲットメッセージプロトコル」の「実行」に相当すると言える。
そうすると,引用発明の「JMSアダプタは,前記メッセージブローカサーバから構造化イベントの形式で受信したメッセージを,ネイティブフォーマットであるMapMessageに変換し,JMSネットワークにその変換されたメッセージであるMapMessageを送信する」と本件補正発明の「ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)」であって,「前記ミドルウェアアダプタ(434)は,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって,前記第2ミドルウェアAPIと互換性のあるターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する」とは,後記する点で相違するものの,“第1ミドルウェアメッセージプロトコルと等価の中間メッセージプロトコルから,前記第1ミドルウェアメッセージプロトコルとは異なるターゲットメッセージプロトコルへと接続するミドルウェアアダプタ”を含む点と,“ミドルウェアアダプタは,第2アプリケーションであるメッセージ宛先に基づいて,中間メッセージプロトコルと等価のターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する”点で共通していると言える。

イ 以上から,本件補正発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

<一致点>

「異なるミドルウェアシステム間でメッセージの仲介をする共通インタフェースシステムであって,
第1アプリケーションに関連付けられた第1ミドルウェアメッセージプロトコルを,予め規定された中間メッセージプロトコルへ接続するインタフェースアダプタと,
前記第1ミドルウェアメッセージプロトコルと等価の前記中間メッセージプロトコルから,前記第1ミドルウェアメッセージプロトコルとは異なるターゲットメッセージプロトコルへと接続するミドルウェアアダプタと
を含み,
前記インタフェースアダプタは,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記第1ミドルウェアメッセージプロトコルと等価の前記中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し,
前記ミドルウェアアダプタは,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価の前記ターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する,
共通インタフェースシステム。」

<相違点1>

本件補正発明は,「サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステム」であるのに対して,引用発明は,「異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステム」である点。

<相違点2>

第1ミドルウェアメッセージプロトコルの実行に関し,本件補正発明は,「第1ミドルウェアAPIに基づくミドルウェアAPI呼出し」により実行しているのに対して,引用発明は,第1ミドルウェアプラットフォームインタフェースである「MQSeries」が「Cobolコピーブック」を「送信」しており,「API」によりメッセージプロトコルを実行することについて言及されていない点。

<相違点3>

中間メッセージプロトコルおよびターゲットメッセージプロトコルの実行に関し,本件補正発明は,「共通API」により「中間メッセージプロトコル」を実行し,「第2ミドルウェアAPI」により「ターゲットメッセージプロトコル」を実行しているのに対して,引用発明は,「API」によりメッセージ通信プロトコルを実行することについて言及されていない点。

<相違点4>

インタフェースアダプタとミドルウェアアダプタとの連携に関し,本件補正発明は,「インタフェースアダプタ」と「ミドルウェアアダプタ」との間に中継する手段を有しないのに対して,引用発明は「メインフレームアダプタ」と「JMSアダプタ」との間の「メッセージブローカサーバ」がメッセージを中継する点。


(5)当審の判断

上記相違点1乃至4について検討する。

ア 相違点1について

引用発明の「ミドルウェアブローカシステム」は,「異なるミドルウェアシステム間で通信されるメッセージの仲介をする」ところ,「メッセージ」は,互いに「異なるミドルウェアシステム」に関連した異なるアプリケーション間で通信されると解される。
また,サービス指向アーキテクチャー(SOA)に基づくシステムにおける異なるアプリケーションの間で,メッセージ通信を可能とすることは,例えば,米国特許出願公開第2007/0124156号明細書(段落[0045]?[0048]を参照)に記載されるように,本願優先日前には当該技術分野の周知技術であった。
そうすると,引用発明において,上記周知技術を適用し,適宜,異なるミドルウェアシステム間で通信されるメッセージの仲介をするミドルウェアブローカシステムを,サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステムとすること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

イ 相違点2及び相違点3について

引用発明では,「MQSeries」が「Cobolコピーブック」を「送信」し,「メインフレームアダプタ」が「構造化イベントフォーマットのメッセージ」を「送信」し,「JMSアダプタ」が「MapMessage」を「送信」することで,メッセージ通信プロトコルを実行していると解されるが,これらメッセージの送信を如何なるインタフェースを用いて実行しているか特に言及されていない。
しかしながら,プログラム間のメッセージ通信をAPI(アプリケーションプログラミングインタフェース)呼び出しにより実現することは,例えば,参考文献1(上記Hを参照),参考文献2(上記Jを参照)に記載されるように,本願優先日前には当該技術分野の周知慣用の手法であり,プログラム間のメッセージ通信にAPIを利用するか否かは必要に応じて選択し得た設計的事項であった。
そうすると,引用発明において,上記周知慣用手法を適用し,MQSeriesによるCobolコピーブックの送信,メインフレームアダプタによる構造化イベントフォーマットメッセージの送信,JMSアダプタによるMapMessageの送信に係るメッセージ通信プロトコルを,適宜,対応するAPIを呼び出すことにより実行すること,すなわち,上記相違点2及び相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

ウ 相違点4について

引用発明は「メインフレームアダプタ」と「JMSアダプタ」との間の「メッセージブローカサーバ」がメッセージを中継するところ,「メッセージブローカサーバ」は受信した「構造化イベントフォーマットのメッセージ」を変換することなく,転送先が見つかるまでは「受信したメッセージを,パブリッシュ/サブスクライブエンジンに格納し」,転送先のアダプタへ送信していると言える。
そして,引用発明が上記「メッセージブローカサーバ」のような構成を備える必要があるのは,「メインフレームアダプタ」と「JMSアダプタ」の組合せ以外の異種ミドルウェア間でメッセージ転送を可能としているからに他ならない。
そうすると,引用発明において,メッセージを転送するミドルウェアの組合せを固定することにより,メインフレームアダプタが送信する構造化イベントフォーマットのメッセージを,JMSアダプタが中継手段を用いることなく直接受信できるようにすること,すなわち,上記相違点4に係る構成とすることは,当業者が容易に想到し得たことである。

エ 小括

上記で検討したごとく,相違点1乃至相違点4に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本件補正発明は,上記引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

(6)補正却下の決定のむすび

以上のように,本件補正は,上記「3 独立特許要件」で指摘したとおり,本件補正後の請求項1に記載された発明は,特許出願の際独立して特許を受けることができるものではないから,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,上記補正却下の決定の結論のとおり決定する。


第3 本願発明について

1 本願発明の認定

平成25年8月23日付けの手続補正は上記のとおり却下されたので,本件補正後の請求項1に対応する本件補正前の請求項に係る発明(以下,「本願発明」という。)は,平成25年1月31日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される,以下のとおりのものである。

「 サービス指向アーキテクチャ(SOA)にアプリケーションを統合するための共通インタフェースシステムであって,
第1アプリケーションに関連付けられた第1ミドルウェアAPIに基づくミドルウェアAPI呼出しであって,予め規定された共通APIへのミドルウェアAPI呼出しを受信するようコード化されたインタフェースアダプタ(432)と,
前記ミドルウェアAPI呼出しを予め規定された共通APIから第1ミドルウェアAPIとは異なる第2ミドルウェアAPIと互換性のあるインタフェースへと接続するようコード化されたミドルウェアアダプタ(434)と
を含む共通インタフェースシステム。」

2 引用例に記載されている技術的事項及び引用発明の認定

原査定の拒絶の理由に引用された,引用発明は,前記「第2 平成25年8月23日付けの手続補正についての補正却下の決定」の「3 独立特許要件」の「(2)引用例」に記載したとおりである。

3 対比・判断

本願発明は,前記「第2 平成25年8月23日付けの手続補正についての補正却下の決定」の「3 独立特許要件」で検討した本件補正発明の発明特定事項から
「前記インタフェースアダプタ(432)は,前記第1アプリケーションに関連付けられた第1ミドルウェアプラットフォームインタフェースに基づいて,前記ミドルウェアAPI呼出しと等価の中間メッセージプロトコルを特定し,特定した前記中間メッセージプロトコルを実行し」の限定事項を削除し,
「前記ミドルウェアアダプタ(434)は,第2アプリケーションであるメッセージ宛先に基づいて,前記中間メッセージプロトコルと等価のターゲットメッセージプロトコルであって,前記第2ミドルウェアAPIと互換性のあるターゲットメッセージプロトコルを特定し,特定した前記ターゲットメッセージプロトコルを実行する」の限定事項を削除したものである。
そうすると,本願発明の発明特定事項を全て含む本件補正発明が,前記「第2 平成25年8月23日付けの手続補正についての補正却下の決定」の「3 独立特許要件」の「(2)引用例」乃至「(5)当審の判断」に記載したとおり,引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから,上記特定の限定を省いた本願発明も同様の理由により,引用発明及び当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものである。


第4 むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-06-03 
結審通知日 2015-06-09 
審決日 2015-06-23 
出願番号 特願2010-536042(P2010-536042)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 杉浦 孝光田中 幸雄  
特許庁審判長 山崎 達也
特許庁審判官 辻本 泰隆
木村 貴俊
発明の名称 共通メッセージングインタフェースを用いたサービス指向アーキテクチャアプリケーションの統合  
代理人 園田 吉隆  
代理人 小林 義教  

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