【事件の表示】
　特願２００９−５０１１００「アプリケーション連携制御プログラム、アプリケーション連携制御方法およびアプリケーション連携制御装置」拒絶査定不服審判事件〔平成２０年　９月　４日国際公開、ＷＯ２００８／１０５０９９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１９年２月２８日を国際出願日とする出願であって、平成２１年５月２７日付けで手続補正がなされ、平成２２年１２月１７日付けで拒絶理由通知がなされ、平成２３年３月７日付けで意見書が提出されるとともに同日付けで手続補正がなされ、同年６月３０日付けで最後の拒絶理由通知がなされ、同年９月５日付けで意見書が提出されたが、同年９月２２日付けで拒絶査定がなされ、これに対し、平成２４年１月４日付けで拒絶査定不服審判の請求がなされたものである。
　
２．本願発明
　本願の請求項３に係る発明は、平成２３年３月７日付けの手続補正書により補正された特許請求の範囲の請求項３に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
　
「コンピュータが第１のアプリケーションと第２のアプリケーションとの間の連携動作の制御を実行するアプリケーション連携制御方法であって、
　前記第１のアプリケーションからメッセージを受信すると、該メッセージをメッセージ格納手段に格納し、
　前記第１のアプリケーションから格納した前記メッセージについてのコミットの通知を受信した際に、前記コミットの通知の受信より前に前記第２のアプリケーションからメッセージの読み出し依頼を既に受信していれば、該依頼への応答として、格納した前記メッセージを前記第２のアプリケーションに送信する
　ことを特徴とするアプリケーション連携制御方法。」
　
３．引用文献
（引用文献１）
　原査定の拒絶の理由に引用され、本願の国際出願日前に頒布された特開２００６−３１４９１号公報（以下、「引用文献１」という。）には、図面とともに次の事項が記載されている。（下線は、当審において付与したものである。）
　
Ａ１．「【０００８】
　本発明の
アプリケーション間連携システム
送信側と受信側のアプリケーションプログラム間で、ＤＢキューを介して非同期に通信することが可能となる
　
Ａ２．「【００１３】
　まず、本実施の形態における処理実行制御の仕組みの概念図を図1に示す。
300は通信プログラム、100/200は特定の通信基盤、110/210はそれぞれの通信基盤上で実行される業務である。通信基盤100/200、業務110/210は１つ、または複数存在する。通信プログラムの中には、ＤＢキュー（メッセージ格納領域）310、ｎａｍｅ制御部320、ＤＢキューアクセス部330、イベント制御部360が存在する。通信基盤上には通信プログラムが提供するメッセージ送信部130/230、メッセージ受信部140/240、業務の中にはメッセージ処理を行うコンポーネント120/220が存在する。
【００１４】
　
ｎａｍｅ制御部320は、送受信されるメッセージを処理するコンポーネント120/220に対し、それぞれのコンポーネントが送信先として送信可能状態にあるかどうか、および送信可能なコンポーネントについてはコンポーネントが存在するノードの負荷状態をコンポーネントのステータスとして保持する（340/350）。メッセージ送信プロセスからの送信先情報の検索要求に対し送信先情報を応答する(420)。
【００１５】
　
ＤＢキューアクセス部330は、メッセージ送信部130/230、メッセージ受信部140/240からの書き込み要求、読み出し要求にしたがって、ＤＢキュー（メッセージ格納領域）310に対して操作を行う。（440/490）
　
コンポーネント120は通信プログラムが提供する送信インタフェースをプログラム中に記述することによって、メッセージ送信部130に対し、送信要求を発行する（410）。さらに送信要求を含むトランザクション処理が正常終了したこと（トランザクションのコミット指示）を、メッセージ送信部通知する（450）。
メッセージ送信部130は、コンポーネント120からの送信要求を受け、ｎａｍｅ制御部に対し、送信先情報の検索要求を行った後(420)、コンポーネント120からの通知を待つ。コンポーネント120からの処理正常終了通知を受け（450）、ＤＢキューアクセス部330に対し、メッセージの書き込み指示を行うとともに（430）、イベント制御部に送信先のコンポーネント220起動のためのトリガを通知する（460）。　
【００１６】
　
メッセージ受信部240は、
読み出したメッセージをコンポーネント220に受け渡す（510）。
【００１７】
　コンポーネント220はメッセージ受信部からの起動指示により起動され、受信したメッセージを含む処理を行った後、トランザクションが終了したことをメッセージ受信部に通知する（520）。」　
　
（ア）Ａ１．の「アプリケーション間連携システム」との記載から、引用文献１には、アプリケーション間の制御方法に係る記載がなされているといえる。
　そして、Ａ１．には、「アプリケーション間連携」について、「送信側と受信側のアプリケーションプログラム間で、ＤＢキューを介して通信することが可能となる」との記載がなされている。
　ここで、上記連携の制御は、コンピュータによって行われることは明らかであるから、引用文献１には、「コンピュータが送信側のアプリケーションプログラムと受信側のアプリケーションプログラムとの間の連携動作の制御を実行するアプリケーション間連携の制御方法」が記載されているといえる。
　
（イ）Ａ２．における「業務110」は、Ａ１．における「送信側のアプリケーションプログラム」に対応することから、引用文献１には、「送信側のアプリケーションプログラムからメッセージを受信すると、該メッセージをＤＢキュー（メッセージ格納領域）に格納」することが記載されているといえる。
　
（ウ）Ａ２．には、「コンポーネント120は・・・、メッセージ送信部130に対し、送信要求を発行する（410）。さらに送信要求を含むトランザクション処理が正常終了したこと（トランザクションのコミット指示）を、メッセージ送信部通知する（450）。」と記載されている。
　ここで、「コンポーネント120」は、「業務110」すなわち「送信側のアプリケーションプログラム」に存在するものであり、「トランザクションのコミット指示」とは、送信側のアプリケーションプログラムからのメッセージについてのコミット指示であることから、引用文献１には、「前記送信側のアプリケーションプログラムから格納した前記メッセージについてのコミット指示を受信」することが記載されているといえる。
　
（エ）Ａ２．には、「メッセージ受信部240は、・・・、ＤＢキューアクセス部にメッセージの読み出しを要求する（480）。さらにコンポーネント220を起動し（500）、読み出したメッセージをコンポーネント220に受け渡す（510）。」と記載されている。
　ここで、「コンポーネント220」は、「業務210」すなわち「受信側のアプリケーションプログラム」に存在するものであることから、引用文献１には、「格納した前記メッセージを前記受信側のアプリケーションプログラムに受け渡す」ことが記載されているといえる。
　
　上記（ア）〜（エ）から、引用文献１には以下の発明が記載されているといえる。（以下、「引用発明」という。）
　
「コンピュータが送信側のアプリケーションプログラムと受信側のアプリケーションプログラムとの間の連携動作の制御を実行するアプリケーション間連携の制御方法であって、
　前記送信側のアプリケーションプログラムからメッセージを受信すると、該メッセージをＤＢキュー（メッセージ格納領域）に格納し、
　前記送信側のアプリケーションプログラムから格納した前記メッセージについてのコミット指示を受信し、
　格納した前記メッセージを前記受信側のアプリケーションプログラムに受け渡す
　アプリケーション間連携の制御方法。」
　
（引用文献２）
　原査定の拒絶の理由に引用され、本願の国際出願日前に頒布された文献“齊藤正勝，「ＭＳＭＱで実現するＷｅｂ系基幹業務システム（２）　ＮＴで作る低コストＷｅｂ（第６回）　トランザクション処理を伴うメッセージ連携システムを開発」，日経インターネットテクノロジー，第２１号，第１８８−１９３頁，日経ＢＰ社，１９９９年３月２２日”（以下、「引用文献２」という。）には、図とともに次の事項が記載されている。（下線は、当審において付与したものである。）
　
Ｂ１．「ＭＳＭＱによる開発の実際
　基幹業務処理では，データの整合性を常に保つことが非常に重要です。非同期処理においても，同期処理と同様のきっちりとしたトランザクション機能が要求されます。前々回までに３回に渡って紹介したＭＴＳ（Microsoft　Transaction　Server）を使えば，こうした要求を簡単に実現できます。ＭＴＳもＭＳＭＱと同様に，ＩＩＳ４．０に完全に統合されています。したがって，ＭＳＭＱメッセージ・キューをＭＴＳトランザクションに結合させるのは容易です（図１）。
　トランザクション処理を行うＭＴＳコンポーネントがトランザクション・キューにメッセージを送信した場合，その送信処理が自動的に現在のＭＴＳトランザクションに結合されます。例えば，
データベース操作を実行し，メッセージ・キューにメッセージを送信するトランザクションがある場合，トランザクションが成功すればメッセージがそのキューに置かれることが保証されます。
　注意してほしいのは，
トランザクションがコミットされるまでＭＳＭＱは送信操作を実施しないことです。
　
４．対比
（ア）引用発明における「送信側のアプリケーションプログラム」と「受信側のアプリケーションプログラム」は、各々本願発明における「第１のアプリケーション」及び「第２のアプリケーション」に相当する。
　
（イ）引用発明における「アプリケーション間連携の制御方法」は、本願発明における「アプリケーション連携制御方法」に相当する。
　
（ウ）引用発明における「ＤＢキュー（メッセージ格納領域）」は、本願発明における「メッセージ格納手段」に相当する。
　
（エ）引用発明における「コミット指示」は、本願発明における「コミットの通知」に相当する。
　
（オ）引用発明における「メッセージを・・・受け渡す」ことは、本願発明における「メッセージを・・・送信する」ことに相当する。
　
　上記（ア）〜（オ）より、本願発明と引用発明とは、以下の点で一致し、また、相違する。
　
［一致点］
「コンピュータが第１のアプリケーションと第２のアプリケーションとの間の連携動作の制御を実行するアプリケーション連携制御方法であって、
　前記第１のアプリケーションからメッセージを受信すると、該メッセージをメッセージ格納手段に格納し、
　前記送第１のアプリケーションから格納した前記メッセージについてのコミットの通知を受信し、
　格納した前記メッセージを前記第２のアプリケーションに送信する
　アプリケーション連携制御方法。」
　
［相違点］
［相違点１］本願発明では、「第１のアプリケーションから格納した前記メッセージについてのコミットの通知を受信した際に、」「格納した前記メッセージを前記第２のアプリケーションに送信する」のに対して、引用発明では、そのような限定は特になされていない点。
　
［相違点２］本願発明では「コミットの通知の受信より前に前記第２のアプリケーションからメッセージの読み出し依頼を既に受信していれば、該依頼への応答として、格納した前記メッセージを前記第２のアプリケーションに送信する」のに対して、引用発明では、そのような限定は特にされてされていない点。
　
５．判断
　そこで、上記相違点１，２について検討する。
　
ア．相違点１について
　キューにおけるトランザクション処理において、コミットされるまで送信しない、すなわち、コミットされていないメッセージは受信側からは見えないようにすることは、引用文献２に記載されているように周知の技術であり、引用発明において、コミットの通知が受信されるまで、メッセージを送信しないよう構成することは、当業者が容易に想到し得ることである。
　よって、相違点１は格別のものではない。
　
イ．相違点２について
　一般にキューのような先入れ先出しの仕組みを用いたデータの送受信においては、受信の要求のタイミングは任意である。してみると、引用発明においても、読み出し依頼を既に受信することは、発明を実施する際に当業者が適宜になし得ることである。
　そして、上記「相違点１について」で検討したような、コミットの通知が受信されるまで、メッセージを送信しないような構成をとった場合、送信側がコミットを依頼するまで、受信側にデータは送られないことから、引用発明において、受信側が、送信側のコミットを待つ、すなわち、メッセージの読み出し依頼を既に受信していれば、該依頼への応答として、格納した前記メッセージを前記第２のアプリケーションに送信するようにすることは、当業者が容易に想到し得ることである。
　よって、相違点２は格別のものではない。
　
（本願の作用効果について）
　そして、本願発明の構成によってもたらされる効果も、引用発明及び引用文献２記載の技術から当業者が容易に予測することができる程度のものであって、格別のものとはいえない。
　
６．むすび
　以上のとおり、本願発明は、引用発明及び引用文献２記載の技術に基づいて、当業者が容易に発明をすることができたものであることから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。