【事件の表示】
　特願２００２−５２００７１「非同期メッセージ交換システムで使用される方法および装置」拒絶査定不服審判事件〔平成１４年　２月２１日国際公開、ＷＯ０２／１５００８、平成１６年　７月　８日国内公表、特表２００４−５２０６４０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯  
　本願は、平成１３年７月２６日（パリ条約による優先権主張外国庁受理２０００年８月１５日、米国）を国際出願日とする出願であって、平成１８年２月２日付けで拒絶理由通知がなされ、同年５月８日付けで手続補正がなされたが、同年７月１１日付けで拒絶査定がなされ、これに対し、同年１０月１６日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。そして、平成１９年１月２９日付けで審査官から前置報告がなされ、平成２０年１１月２１日付けで当審より審尋がなされ、平成２１年２月２５日付けで回答書が提出されたものである。
　  
第２．補正却下の決定
［補正却下の決定の結論］
　平成１８年１０月１６日付けの手続補正を却下する。
　
［理由］
１．補正の内容
　平成１８年１０月１６日付けの手続補正（以下、「本件手続補正」という。）の内容は、平成１８年５月８日付けの手続補正により補正された特許請求の範囲の記載
「【請求項１】
　送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
　前記メッセージと前記送達結果状態とを関連付けるステップと、
　前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
　を含む方法。
【請求項２】
　前記評価が、前記メッセージの送達の成功又は失敗のいずれかである、請求項１に記載の方法。
【請求項３】
　前記送達結果状態が、特定のメッセージと独立に定義される、請求項１又は２に記載の方法。
【請求項４】
　前記送達結果状態が、永続オブジェクトとして表現される、請求項１ないし３のいずれか一項に記載の方法。
【請求項５】
　前記送達結果状態が、関連するオブジェクトの組として表現される、請求項４に記載の方法。
【請求項６】
　前記関連付けるステップは、
　前記メッセージと１つまたは複数の永続オブジェクトとしての送達結果状態の表現とを関連付ける、請求項１ないし３のいずれか一項に記載の方法。
【請求項７】
　特定の前記送達結果状態の表現が、異なるメッセージの組と関連付けられる、請求項６に記載の方法。
【請求項８】
　前記監視するステップは、
１つまたは複数の宛先コンピュータ・システムおよび１つまたは複数のメッセージ受信側コンピュータ・システムの少なくとも１つを監視することで実行される、請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
　前記監視するステップは、
前記メッセージの送達をログに記録するステップを含む、請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
　前記評価するステップは、
　前記監視結果としての前記ログに基づいて前記メッセージの送達を評価する請求項９に記載の方法。
【請求項１１】
　前記送信側コンピュータ・システムから照会を受信することに応答して、前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
　を更に含む、請求項１ないし１０のいずれか一項に記載の方法。
【請求項１２】
　前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項１ないし１１のいずれか一項に記載の方法。
【請求項１３】
　前記送信側コンピュータ・システムからオブジェクトを受信するステップと、
　前記評価結果を前記オブジェクトへ送信するステップと
　を更に含む、請求項１ないし１１のいずれか一項に記載の方法。
【請求項１４】
　前記監視結果は監視時間を含む、請求項１ないし１３のいずれか一項に記載の方法。
【請求項１５】
　前記受信するステップの後に、
　前記送達結果状態を修正するステップをさらに含む、請求項１ないし１４のいずれか一項に記載の方法。
【請求項１６】
　前記受信するステップの後に、
前記送達結果状態を置換するステップをさらに含む、請求項１ないし１４のいずれか一項に記載の方法。
【請求項１７】                                                            
　前記送達結果状態は、予め送信側コンピュータ・システムにおいて定義されている、請求項１ないし１６のいずれか一項に記載の方法。
【請求項１８】
　前記送達結果状態は、予め送信側コンピュータ・システムにおいて各メッセージ単位に定義されている、請求項１ないし１７のいずれか一項に記載の方法。
【請求項１９】
　送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、あるコンピュータ・システムを前記非同期メッセージ交換コンピュータ・システムとして機能させるコンピュータ・プログラムであって、
　実行されることで前記コンピュータ・システムに
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する機能と、
　前記メッセージと前記送達結果状態とを関連付ける機能と、
　前記メッセージを前記宛先コンピュータ・システムへ送信する機能と、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する機能と、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する機能と
　を発現させるコンピュータ・プログラム。
【請求項２０】
　通信ネットワークを介して送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと結合されている非同期メッセージ交換コンピュータ・システムであって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する手段と、
　前記メッセージと前記送達結果状態とを関連付ける手段と、
　前記メッセージを前記宛先コンピュータ・システムへ送信する手段と、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する手段と、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する手段と
　を含むコンピュータ・システム。」（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）を、
　
「【請求項１】
　送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
　前記メッセージと前記送達結果状態とを関連付けるステップと、
　前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
　を含む方法。
【請求項２】
　前記評価が、前記メッセージの送達の成功又は失敗のいずれかである、請求項１に記載の方法。
【請求項３】
　前記メッセージが特定の時間内に特定の受信側コンピュータ・システムに到達する場合に前記メッセージの送達の成功と評価する請求項２に記載の方法。
【請求項４】
　前記メッセージが特定の時間内に一定数未満の受信側コンピュータ・システムにしか到達しない場合に前記メッセージの送達の失敗と評価する請求項２に記載の方法。
【請求項５】
　前記送達結果状態が、特定のメッセージと独立に定義される、請求項１乃至４のいずれかに記載の方法。
【請求項６】
　前記送達結果状態が、永続オブジェクトとして表現される、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
　前記送達結果状態が、関連するオブジェクトの組として表現される、請求項６に記載の方法。
【請求項８】
　前記関連付けるステップは、
　前記メッセージと１つまたは複数の永続オブジェクトとしての送達結果状態の表現とを関連付ける、請求項１乃至５のいずれか一項に記載の方法。
【請求項９】
　特定の前記送達結果状態の表現が、異なるメッセージの組と関連付けられる、請求項８に記載の方法。
【請求項１０】
　前記監視するステップは、
１つまたは複数の宛先コンピュータ・システムおよび１つまたは複数のメッセージ受信側コンピュータ・システムの少なくとも１つを監視することで実行される、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
　前記監視するステップは、
前記メッセージの送達をログに記録するステップを含む、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
　前記評価するステップは、
　前記監視結果としての前記ログに基づいて前記メッセージの送達を評価する請求項１１に記載の方法。
【請求項１３】
　前記送信側コンピュータ・システムから照会を受信することに応答して、前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
　を更に含む、請求項１乃至１２のいずれか一項に記載の方法。
【請求項１４】
　前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項１乃至１３のいずれか一項に記載の方法。
【請求項１５】
　前記送信側コンピュータ・システムからオブジェクトを受信するステップと、
　前記評価結果を前記オブジェクトへ送信するステップと
　を更に含む、請求項１乃至１３のいずれか一項に記載の方法。
【請求項１６】
　前記監視結果は監視時間を含む、請求項１乃至１５のいずれか一項に記載の方法。
【請求項１７】
　前記受信するステップの後に、
　前記送達結果状態を修正するステップをさらに含む、請求項１乃至１６のいずれか一項に記載の方法。
【請求項１８】
　前記受信するステップの後に、
前記送達結果状態を置換するステップをさらに含む、請求項１乃至１６のいずれか一項に記載の方法。
【請求項１９】
　前記送達結果状態は、予め送信側コンピュータ・システムにおいて定義されている、請求項１乃至１８のいずれか一項に記載の方法。
【請求項２０】
　前記送達結果状態は、予め送信側コンピュータ・システムにおいて各メッセージ単位に定義されている、請求項１乃至１９のいずれか一項に記載の方法。
【請求項２１】
　送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、あるコンピュータ・システムを前記非同期メッセージ交換コンピュータ・システムとして機能させるコンピュータ・プログラムであって、
　実行されることで前記コンピュータ・システムに
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する機能と、
　前記メッセージと前記送達結果状態とを関連付ける機能と、
　前記メッセージを前記宛先コンピュータ・システムへ送信する機能と、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する機能と、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する機能と
　を発現させるコンピュータ・プログラム。
【請求項２２】
　通信ネットワークを介して送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと結合されている非同期メッセージ交換コンピュータ・システムであって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する手段と、
　前記メッセージと前記送達結果状態とを関連付ける手段と、
　前記メッセージを前記宛先コンピュータ・システムへ送信する手段と、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する手段と、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する手段と
　を含むコンピュータ・システム。」（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
　に補正するものである。
　  
２．補正の適否 
（１）特許法第１７条の２第４項に規定する要件についての検討  
　補正後の請求項１及び補正後の請求項２は、その記載からして、それぞれ補正前の請求項１及び補正前の請求項２に対応したものである。また、補正後の請求項５〜補正後の請求項２２は、その記載からして、それぞれ補正前の請求項３〜補正前の請求項２０に対応したものである。
　そして、補正後の請求項３及び補正後の請求項４は、その記載からして、新たに追加された請求項である。
　本件補正は、補正後の請求項３及び補正後の請求項４を新たに追加する補正を行っており、補正後の請求項３及び補正後の請求項４を新たに追加する補正は、特許法第１７条の２第４項の各号に掲げる「請求項の削除」、「特許請求の範囲の限定的減縮」、「誤記の訂正」、及び「明りょうでない記載の釈明」のいずれの事項を目的とするものでない。
　
（２）小括  
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第１７条の２第４項の規定に違反するものであるから、特許法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．結論  
　本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に適合しないので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１８年１０月１６日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１８年５月８日付けの手続補正により補正された特許請求の範囲の請求項１の記載からして、
　 
　「送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
　前記メッセージと前記送達結果状態とを関連付けるステップと、
　前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
　を含む方法。」
　
にあるものと認める。
　
２．引用発明
　原査定の拒絶の理由に引用された米国特許第５９８３２６５号明細書（以下、「引用文献」という。）には、図面とともに次の事項が記載されている。（備考：下線は当審で便宜上付与したものである。）
　
（ア）「To obviate these difficulties, EMS has undertaken to provide: 
a) message/data queuing and communications services separated from application programs and processes; ・・・（後略）・・・.」（２カラム１３行目〜１６行目。）
（和訳：これらの困難を取り除くために、ＥＭＳは、以下を提供する： 
a) アプリケーションプログラムとプロセスとから分離された、メッセージ／データのキューイングと通信サービス；・・・（後略））
　
（イ）「More specifically, EMS provides a single, consistent programmatic interface to access the queuing, communication and related services for multiple external and internal communication networks, protocols and transport facilities. ・・・（中略）・・・
　As before stated, the invention handles both outgoing and incoming queuing of data or messages on behalf of the application or process. This means that the user does not have to wait for a communications mechanism or facility to become available to send data or messages. Similarly, data/messages can be received in background while this or other applications and processes are running. 」（５カラム２９行目〜５８行目。）
（和訳：より明確に、ＥＭＳは、複数の外部又は内部の通信ネットワーク、プロトコル、およびトランスポート機能のためのキューイング、通信及び関連するサービスにアクセスするための単一の、一貫したプログラムインタフェースを提供する。・・・（中略）・・・
　前に述べたように、本発明は、アプリケーション又はプロセスのために、データ又はメッセージの送信と到達の両方のキューイングを扱う。これは、ユーザが、通信メカニズムや通信機器がデータ又はメッセージを送るために利用可能になるのを待つ必要はないことを意味する。同様に、該アプリケーションやプロセス、又は他のアプリケーションやプロセスの実行中に、バックグラウンドでデータ／メッセージを受け取ることができる。）
　
（ウ）「As previously mentioned, the EMS for each environment consists of a set of toolkit modules tailored specifically for that environment. As more particularly shown in FIG. 2, the basic EMS modules are the following: 
　Application Programming Interface labelled (API)--a set of single-function software modules, or verbs, that together provide a consistent interface through which application programs/processes can access the EMS communications services. 
　Queue Manager/Router (Queues/Router)--stages messages and data flowing to and from the application/process and monitors the delivery status of each. 
　Communication Agents (Comm. Agent or CA)--one for each different network, protocol or communication transport facility. (shown as Communication Network A B  C). 
　Communication Manager (Comm. Manager or CM)--provides common messaging functions for all the communications agent present. 
・・・（中略）・・・
　Any number of nodes may be linked by communications networks and facilities using the EMS of the invention. 」（６カラム９行目〜４１行目。）
（和訳：以前に言及したように、各環境におけるＥＭＳは特にその環境のために合わせた１セットのツールキットモジュールから成る。図２に詳細に示されているように、基本的なＥＭＳモジュールは以下のとおり：
　アプリケーションプログラムインタフェース（ＡＰＩ）−　アプリケーションプログラム／プロセスがＥＭＳ通信サービスにアクセスするための一貫したインタフェースを提供するソフトウェア・モジュールのセット。 
　キューマネージャ／ルータ(”キュー”／”ルータ”)　−　アプリケーション／プロセスにおけるデータ又はメッセージの送信と到達を可能とするとともに、それぞれの送達状態を監視する。 
　コミュニケーションエージェント(”Ｃｏｍｍ．Ａｇｅｎｔ”又は”ＣＡ”）−　それぞれの異なったネットワーク、プロトコルまたはトランスポート機能に対して１つずつ対応する。 (”通信ネットワークＡ”、”Ｂ”、及び”Ｃ”として表す。) 
　コミュニケーションマネージャ(”Ｃｏｍｍ．Ｍａｎａｇｅｒ”又は”ＣＭ”)−　すべてのコミュニケーションエージェントに共通のメッセージング機能を提供する。
・・・（中略）・・・
　いろいろなノードが、本発明のＥＭＳを使用することで、通信網と通信設備によってリンクされる。）
　
（エ）「The details of developing outgoing messasges are presented in the flow chart of FIG. 6 which outlines the main steps in preparing a message for transmission and in sending that message. 
　The application, through its normal processing, creates at 20 the block of data to be transferred. This data block or message MD, as previously explained, may have a simple structure such as text, or it may have a complex internal structure containing binary data, images, text, graphics and other objects that have meaning only to the receiving application. EMS has the job of delivering this message content to a specified destination without loss. 
　The application (or its user) must also decide at 21 how the message MD is to be handled (this defines the class-of-service for the message). Handling options supported by EMS may include acknowledgement level, priority with regard to other traffic, service routing according to logical destination, identifier, recoverability, retry options, and timing and delayed delivery options. 
　The message destination must be specified using IDs (7, FIG. 3) that have been established for the user environments. Both message handling and message destination specifications are loaded into a special EMS data buffer--the Interface Control Block (ICB) 4', FIGS. 4 and 6,--before the EMS API function call is made. 
　After defining both the message data content for EMS (in terms of length and pointer to message data start) and the message handling instructions (via the ICB), the application makes calls to the EMS API to make the transfer. In general, this requires a GETBUF call (3,6 in FIG. 3) to set up the message resources, and a 
SELND
　Upon receipt of a message MD, EMS encapsulates it by prefixing the message handling data as a message header at 22 to the message data to form the complete EMS message ready for transport.」（１１カラム３０行目〜６７行目。）（注：前記
SELND
（和訳：送信メッセージを展開する詳細は、送信メッセージを準備して、該メッセージを送信する主要なステップのアウトラインを記載した図６のフローチャートで提示される。
　アプリケーションは、その正常処理の過程において、送信するためのデータのブロックを作成する（２０）。このデータ・ブロック又はメッセージＭＤは、以前に説明したように、テキストのような単純な構造を有するか、または受信するアプリケーションだけに意味のある、バイナリ・データ、イメージ、テキスト、グラフィックス、および他のオブジェクトを含む複雑な内部構造を有する。ＥＭＳは、該メッセージ内容を損失なしに、指定された送付先に送達する仕事をする。
　アプリケーション(または、ユーザ)は、メッセージＭＤがどのようにハンドリングされるべきか（これはメッセージのサービスクラスを定義する)を決める（２１）。ＥＭＳによってサポートされるハンドリングオプションには、該メッセージ受信確認のレベル、他のトラフィックに対する優先順位、論理宛先によるルーティングサービス、識別子、修復性、再試行オプション、およびタイミング又はディレード送達オプションが含まれる。
　ユーザ環境において確立されているＩＤ（図３の７）を使用して、該メッセージの宛先を指定する。そして、ＥＭＳのＡＰＩファンクションを呼び出す前に、該メッセージのハンドリング仕様とメッセージの宛先をＥＭＳの特定のデータバッファ（図４及び図６記載のインタフェースコントロールブロック（ＩＣＢ）４’）にロードする。
　ＥＭＳに対して該メッセージのデータコンテンツの定義（レングスとメッセージデータの先頭を示すポインタによる)と該メッセージのハンドリングのための指示の定義(ＩＣＢによる)をした後に、アプリケーションは、送信をするためにＥＭＳのＡＰＩを呼び出す。通常、これは該メッセージのリソースを準備するためのＧＥＴＢＵＦコール(図３の３、６)と、送達を開始する(プラットホームに依存)ためのＳＥＮＤコール(図３の４)とを必要とする。ＥＭＳの受信側のプロセスは、プラットフォームに応じて、図６に示すＥＭＳ　Ｒｏｕｔｅｒ又はキューマネジャ”ＱＵＥＵＥＳ”が実行する。
　ＥＭＳの受信側のプロセスがメッセージＭＤを受信すると、ＥＭＳは、該メッセージのハンドリングのための情報を該メッセージのデータの前にメッセージヘッダとして付けてカプセル化することで、転送するための完全なＥＭＳメッセージを形成する。）
　
（オ）「The message data, and Frame format, are received at 31 at each EMS--supported node and are reassembled into packets at 32. The transport layer data and structures are removed and the message header is unpacked to its full EMS format. The message packets are reassembled at 33 (segmentation created by the sending EMS is removed) and protocol data stripped and local header data added at 34. The segments are delivered to the local EMS QUEUE or Router at 35, where the complete messages are reassembled at 36 and acknowledgment messages generated, if needed, at 37. On this queue, messages await either delivery at 38 to a local recipient or transmission over the next transport hop. When the destination application or user requests a message from its assigned EMS Queue, using the RECEIVE verb, the message storage area is delivered to the application. Other data contained in the message ICB is also available to the application, if needed. The application can read the message data and display it or store it for the intended user (or application). If the ICB specifies that application or user acknowledgement is required, the receiving application must initiate an appropriate acknowledgement at 40. Formal return receipts are transmitted to the message sender as separate messages. 」（１２カラム３７行目〜５９行目。）
（和訳：メッセージデータとフレームフォーマットが、ノードでサポートされている各ＥＭＳにおいて受信（３１）され、パケットにリアセンブルされる（３２）。そこで、トランスポートレイヤのデータとその構造は取り除かれ、メッセージヘッダーは完全なＥＭＳ形式にアンパックされる。メッセージパケットは、リアセンブルされ（３３）（送信側のＥＭＳによって作成されたセグメンテーションは取り除かれる)、プロトコルデータを剥ぎ取り、ローカルのヘッダーデータが追加される（３４）。セグメントはローカルのＥＭＳ　ＱＵＥＵＥまたＲｏｕｔｅｒに転送され（３５）、完全なメッセージがリアセンブルされ（３６）、必要であれば、受信確認のメッセージが生成される（３７）。このキューにおいて、メッセージは、該メッセージの受取人による受信か、又は次の転送ホップのための転送を待つ。宛先アプリケーション又はユーザが、割り当てられたＥＭＳ　Ｑｕｅｕｅから、ＲＥＣＥＩＶＥを使用して、メッセージを要求すると、メッセージストレージ領域が該アプリケーションに提供される。そして、必要ならば、メッセージＩＣＢに含まれる他のデータもアプリケーションに利用可能となる。アプリケーションは、対象とするユーザ(または、アプリケーション)のために該メッセージデータを読み込み、表示するか、又は保存することができる。ＩＣＢが、アプリケーションによる受信確認又はユーザによる受信確認を要求している場合、受信側のアプリケーションは、所定の受信確認をイニシエートしなければならない（４０）。そして、正式な受信通知が別のメッセージとして該メッセージの送信側に転送される。）
　
（カ）「Successful receipt of a message (segment) by a final destination or delivery service is signalled by an acknowledgement message being returned to the sender. There are at least four levels at which the ability to generate receipt acknowledgements are valuable; namely, user (i.e., a person), application, device (EMS) and/or communication protocol. EMS handles device and protocol acknowledgements and, through its API, support application-level and user-level acknowledgements 」（１４カラム６６行目〜１５カラム７行目。）
（和訳：最終的な宛先又は送達サービスによって、メッセージ（セグメント）の受信が成功したことは、送信側に返される受信確認メッセージによって知らされる。受信確認を生成するための能力として有益であるレベルとして少なくとも４つのレベルがある；すなわち、ユーザ(すなわち、人)による受信確認レベル、アプリケーションによる受信確認レベル、デバイス（ＥＭＳ）による受信確認レベル、及び／または、通信プロトコルによる受信確認レベルである。そして、ＥＭＳはデバイス及び、通信プロトコルによる受信確認レベルを取り扱い、アプリケーションによる受信確認レベル、およびユーザによる受信確認レベルについては、ＡＰＩを通じてサポートする。）
　
（キ）「A destination application may be given the ability to generate an application acknowledgement to confirm the message receipt by having the application issue a COMMIT call to the destination EMS Router. The EMS Router will generate the required application acknowledgement message and forward it as a separate datagram back to the message originator via the same network path. When the destination application issues a COMMIT verb for a message marked for application acknowledgement in the confirmation field, the Router will generate the required application acknowledgement message and forward it as a separate data-gram back to the message originator via the same processing service path. 」（１５カラム５４行目〜６６行目。）
（和訳：宛先であるアプリケーションは、ＥＭＳ　ＲｏｕｔｅｒにＣＯＭＭＩＴをコールすることにより、該アプリケーションによる受信確認を生成することができる。該ＥＭＳ　Ｒｏｕｔｅｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。宛先であるアプリケーションが、確認欄にアプリケーションによる受信確認が記されたメッセージに対して、ＣＯＭＭＩＴ命令を発行することで、Ｒｏｕｔｅｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じプロセスパスを通して、返送する。）
　
（ク）「A destination application may also be given the ability to generate an acknowledgement confirming message receipt by the receiving user. This requires the application to issue a COMMIT to the destination EMS Router. The EMS Router will generate the required acknowledgement message and again forward it as a separate datagram back to the message originator via the same network path. when the destination application issues a COMMIT verb for a message marked for user acknowledgement in the confirmation mode field, the Router will generate the required user acknowledgement message and forward it as a separate datagram back to the message originator via the same processing service path. 」（１６カラム２７行目〜３９行目。）
（和訳：同様に、宛先であるアプリケーションは、受信側のユーザによる受信確認メッセージを生成することができる。このために、該アプリケーションはＥＭＳ　Ｒｏｕｔｅｒに対してＣＯＭＭＩＴを発行する必要がある。ＥＭＳ　Ｒｏｕｔｅｒは、要求された前記ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。宛先であるアプリケーションが、確認モード欄にユーザによる受信確認が記されたメッセージに対して、ＣＯＭＭＩＴ命令を発行することで、Ｒｏｕｔｅｒは、要求された該ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じプロセスパスを通して、返送する。）
　
　（ア）における記載「ＥＭＳは、以下を提供する：a) アプリケーションプログラムとプロセスとから分離された、メッセージ／データのキューイングと通信サービス」、及び（イ）における記載「本発明は、アプリケーション又はプロセスのために、データ又はメッセージの送信と到達の両方のキューイングを扱う。これは、ユーザが、通信メカニズムや通信機器がデータ又はメッセージを送るために利用可能になるのを待つ必要はないことを意味する。同様に、該アプリケーションやプロセス、又は他のアプリケーションやプロセスの実行中に、バックグラウンドでデータ／メッセージを受け取ることができる。」からすると、
　引用文献には、送信側システムと受信側システムとＥＭＳとが通信ネットワークに結合されており、前記ＥＭＳは、送信側システムと受信側システムに対して、メッセージを非同期に送受信すること（すなわち、非同期メッセージ交換）を可能とする方法であって、前記ＥＭＳに使用される方法が記載されていると解される。
　
　そして、（エ）における記載「アプリケーションは、その正常処理の過程において、送信するためのデータのブロックを作成する（２０）。 ・・・（中略）・・・アプリケーション(または、ユーザ)は、メッセージＭＤがどのようにハンドリングされるべきか（これはメッセージのサービスクラスを定義する)を決める（２１）。ＥＭＳによってサポートされるハンドリングオプションには、該メッセージ受信確認のレベル、・・・（中略）・・・が含まれる。・・・（中略）・・・ＥＭＳのＡＰＩファンクションを呼び出す前に、該メッセージのハンドリング仕様とメッセージの宛先をＥＭＳの特定のデータバッファ（図４及び図６記載のインタフェースコントロールブロック（ＩＣＢ）４’）にロードする。　・・・（中略）・・・　ＥＭＳの受信側のプロセスは、プラットフォームに応じて、図６に示すＥＭＳ　Ｒｏｕｔｅｒ又はキューマネジャ”ＱＵＥＵＥＳ”が実行する。ＥＭＳの受信側のプロセスがメッセージＭＤを受信すると、ＥＭＳは、該メッセージのハンドリングのための情報を該メッセージのデータの前にメッセージヘッダとして付けてカプセル化することで、転送するための完全なＥＭＳメッセージを形成する。」、（カ）における記載「最終的な宛先又は送達サービスによって、メッセージ（セグメント）の受信が成功したことは、送信側に返される受信確認メッセージによって知らされる。受信確認を生成するための能力として有益であるレベルとして少なくとも４つのレベルがある；すなわち、ユーザ(すなわち、人)による受信確認レベル、アプリケーションによる受信確認レベル、デバイス（ＥＭＳ）による受信確認レベル、及び／または、通信プロトコルによる受信確認レベルである。」からすると、ＥＭＳキューマネジャは、前記送信側システムからメッセージと該メッセージに関する受信確認レべル（すなわち、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び／または、通信プロトコルによる受信確認がされた状態）の定義とを受信し、前記メッセージに前記受信確認レべルを付けてカプセル化することで、転送するための完全なＥＭＳメッセージを形成すると解される。
　なお、（カ）における記載からすると、前記メッセージに関する受信確認レべルの定義とは、送信側システムがメッセージ単位で、該メッセージの送達結果状態が、ユーザによる受信確認がなされた状態、又はアプリケーションによる受信確認がなされた状態、又はデバイスによる受信確認がなされた状態等のどの送達結果状態の確認を要求するかを定義するものであって、前記メッセージに関する受信確認レべルを定義することによって、該メッセージの信頼性のある送達を保証するものであると認められる。
　（オ）における記載「メッセージデータとフレームフォーマットが、ノードでサポートされている各ＥＭＳにおいて受信（３１）され、パケットにリアセンブルされる（３２）。そこで、トランスポートレイヤのデータとその構造は取り除かれ、メッセージヘッダーは完全なＥＭＳ形式にアンパックされる。メッセージパケットは、リアセンブルされ（３３）（送信側のＥＭＳによって作成されたセグメンテーションは取り除かれる)、プロトコルデータを剥ぎ取り、ローカルのヘッダーデータが追加される（３４）。 セグメントはローカルのＥＭＳ　ＱＵＥＵＥまたＲｏｕｔｅｒに転送され、・・・（中略）・・・宛先アプリケーション又はユーザが、割り当てられたＥＭＳ　Ｑｕｅｕｅから、ＲＥＣＥＩＶＥを使用して、メッセージを要求すると、・・・（中略）・・・アプリケーションに利用可能となる。」からすると、前記メッセージを受信側システムに関係づけられているＥＭＳ　ＱＵＥＵＥ（すなわち、ＥＭＳキューマネジャ）へ送信すると解される。
　（ウ）における記載「キューマネージャ／ルータ(”キュー”／”ルータ”)　−　アプリケーション／プロセスにおけるデータ又はメッセージの送信と到達を可能とするとともに、それぞれの送達状態を監視する。」及び（オ）における記載「このキューにおいて、メッセージは、該メッセージの受取人による受信か、又は次の転送ホップのための転送を待つ。・・・（中略）・・・アプリケーションは、対象とするユーザ(または、アプリケーション)のために該メッセージデータを読み込み、表示するか、又は保存することができる。」、（カ）における記載「ＥＭＳはデバイス及び、通信プロトコルによる受信確認レベルを取り扱い、アプリケーションによる受信確認レベル、およびユーザによる受信確認レベルについては、ＡＰＩを通じてサポートする。」、（キ）における記載「宛先であるアプリケーションは、ＥＭＳ　ＲｏｕｔｅｒにＣＯＭＭＩＴをコールすることにより、該アプリケーションによる受信確認を生成することができる。該ＥＭＳ　Ｒｏｕｔｅｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。」、及び（ク）における記載「ＥＭＳ　Ｒｏｕｔｅｒは、要求された前記ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。」からすると、前記メッセージの前記受信側システムに関係づけられているＥＭＳキューマネジャから前記受信側システムへの送達を監視するとともに、前記監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送すると解される。
　
　したがって、引用文献には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
　
　 送信側システムと受信側システムと非同期メッセージ交換のためのＥＭＳとが通信ネットワークに結合されており、前記非同期メッセージ交換のためのＥＭＳに使用される方法であって、
　前記送信側システムからメッセージと前記メッセージに関する受信確認レべル（すなわち、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び／または、通信プロトコルによる受信確認がされた状態）の定義とを受信するステップであって、前記メッセージに関する受信確認レべルの定義とは、送信側システムがメッセージ単位で、該メッセージの送達結果状態が、ユーザによる受信確認がなされた状態、又はアプリケーションによる受信確認がなされた状態、又はデバイスによる受信確認がなされた状態等のどの送達結果状態の確認を要求するかを定義するものであって、
　前記メッセージと前記受信確認レべルとをカプセル化したＥＭＳメッセージを形成するステップと、
　前記メッセージを受信側システムに関係づけられているＥＭＳキューマネジャへ送信するステップと、
　前記メッセージの前記受信側システムに関係づけられているＥＭＳキューマネジャから前記受信側システムへの送達を監視するステップと、
　前記監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送するステップと
　を含む方法。
　
３．対比・判断
　ここで、本願発明と引用発明とを対比する。
　引用発明の「送信側システム」、「受信側システム」、及び「非同期メッセージ交換のためのＥＭＳ」は、それぞれ、本願発明の「送信側コンピュータ・システム」、「受信側コンピュータ・システム」及び「非同期メッセージ交換コンピュータ・システム」に相当する。
　引用発明の「メッセージに関する受信確認レべル」は、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び／または、通信プロトコルによる受信確認がされた状態を意味することから、本願発明の「メッセージに関する送達結果状態」に相当する。
　引用発明の「メッセージと前記受信確認レべルとをカプセル化したＥＭＳメッセージを形成する」ことは、メッセージと前記受信確認レべルとを関連づけてカプセル化されたと解されるから、本願発明の「メッセージと前記送達結果状態とを関連付ける」ことに相当する。
　引用発明の「受信側システムに関係づけられているＥＭＳキューマネジャ」は、引用発明の「非同期メッセージ交換のためのＥＭＳに使用される方法」において、メッセージを当該「ＥＭＳキューマネジャ」へ送信するものであって、メッセージの当該「ＥＭＳキューマネジャ」から前記受信側システムへの送達を監視するものであり、他方、本願発明の「宛先コンピュータ・システム」も本願発明の「非同期メッセージ交換コンピュータ・システムに使用される方法」において、メッセージを当該「宛先コンピュータ・システム」へ送信するものであって、メッセージの当該「宛先コンピュータ・システム」から前記受信側コンピュータ・システムへの送達を監視するものであること、さらに、本願明細書の発明の詳細な説明の段落【００２８】に「既存のメッセージ・ミドルウェア１１０は、
メッセージ・キューまたはJMS Topicオブジェクトなどの宛先１１２
　そして、前記「受信側システムに関係づけられているＥＭＳキューマネジャ」が、送信側システムと受信側システムと非同期メッセージ交換のためのＥＭＳと通信ネットワークで結合されていることは、自明の事項である。
　
　そして、引用発明の「監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する」ことと本願発明の「監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する」こととは、ともに監視結果と前記送達結果状態の定義とに基づいて前記メッセージに関する所定の処理を行う点で共通する。
　
　したがって、本願発明と引用発明とは、以下の点で一致し、また、相違している。
　
（一致点）
　送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
　前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
　前記メッセージと前記送達結果状態とを関連付けるステップと、
　前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
　前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
　前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージに関する所定の処理を行うステップと
　を含む方法。
　
（相違点）
　本願発明は、「監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する」のに対し、引用発明は、「監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する」点。
　
　相違点について検討する。
　引用発明において、監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する際に、監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したかどうかを評価するように構成することは、当業者であれば、適宜なし得たことである。
　よって、相違点は格別なものではない。
　
　そして、本願発明の作用効果も、引用発明から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用発明から容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。