• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特17 条の２ 、４ 項補正目的 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1207242
審判番号 不服2006-23426  
総通号数 121 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-01-29 
種別 拒絶査定不服の審決 
審判請求日 2006-10-16 
確定日 2009-11-11 
事件の表示 特願2002-520071「非同期メッセージ交換システムで使用される方法および装置」拒絶査定不服審判事件〔平成14年 2月21日国際公開、WO02/15008、平成16年 7月 8日国内公表、特表2004-520640〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、平成13年7月26日(パリ条約による優先権主張外国庁受理2000年8月15日、米国)を国際出願日とする出願であって、平成18年2月2日付けで拒絶理由通知がなされ、同年5月8日付けで手続補正がなされたが、同年7月11日付けで拒絶査定がなされ、これに対し、同年10月16日に審判請求がなされるとともに、同日付けで手続補正がなされたものである。そして、平成19年1月29日付けで審査官から前置報告がなされ、平成20年11月21日付けで当審より審尋がなされ、平成21年2月25日付けで回答書が提出されたものである。

第2.補正却下の決定
[補正却下の決定の結論]
平成18年10月16日付けの手続補正を却下する。

[理由]
1.補正の内容
平成18年10月16日付けの手続補正(以下、「本件手続補正」という。)の内容は、平成18年5月8日付けの手続補正により補正された特許請求の範囲の記載
「【請求項1】
送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
前記メッセージと前記送達結果状態とを関連付けるステップと、
前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
を含む方法。
【請求項2】
前記評価が、前記メッセージの送達の成功又は失敗のいずれかである、請求項1に記載の方法。
【請求項3】
前記送達結果状態が、特定のメッセージと独立に定義される、請求項1又は2に記載の方法。
【請求項4】
前記送達結果状態が、永続オブジェクトとして表現される、請求項1ないし3のいずれか一項に記載の方法。
【請求項5】
前記送達結果状態が、関連するオブジェクトの組として表現される、請求項4に記載の方法。
【請求項6】
前記関連付けるステップは、
前記メッセージと1つまたは複数の永続オブジェクトとしての送達結果状態の表現とを関連付ける、請求項1ないし3のいずれか一項に記載の方法。
【請求項7】
特定の前記送達結果状態の表現が、異なるメッセージの組と関連付けられる、請求項6に記載の方法。
【請求項8】
前記監視するステップは、
1つまたは複数の宛先コンピュータ・システムおよび1つまたは複数のメッセージ受信側コンピュータ・システムの少なくとも1つを監視することで実行される、請求項1ないし7のいずれか一項に記載の方法。
【請求項9】
前記監視するステップは、
前記メッセージの送達をログに記録するステップを含む、請求項1ないし8のいずれか一項に記載の方法。
【請求項10】
前記評価するステップは、
前記監視結果としての前記ログに基づいて前記メッセージの送達を評価する請求項9に記載の方法。
【請求項11】
前記送信側コンピュータ・システムから照会を受信することに応答して、前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項1ないし10のいずれか一項に記載の方法。
【請求項12】
前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項1ないし11のいずれか一項に記載の方法。
【請求項13】
前記送信側コンピュータ・システムからオブジェクトを受信するステップと、
前記評価結果を前記オブジェクトへ送信するステップと
を更に含む、請求項1ないし11のいずれか一項に記載の方法。
【請求項14】
前記監視結果は監視時間を含む、請求項1ないし13のいずれか一項に記載の方法。
【請求項15】
前記受信するステップの後に、
前記送達結果状態を修正するステップをさらに含む、請求項1ないし14のいずれか一項に記載の方法。
【請求項16】
前記受信するステップの後に、
前記送達結果状態を置換するステップをさらに含む、請求項1ないし14のいずれか一項に記載の方法。
【請求項17】
前記送達結果状態は、予め送信側コンピュータ・システムにおいて定義されている、請求項1ないし16のいずれか一項に記載の方法。
【請求項18】
前記送達結果状態は、予め送信側コンピュータ・システムにおいて各メッセージ単位に定義されている、請求項1ないし17のいずれか一項に記載の方法。
【請求項19】
送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、あるコンピュータ・システムを前記非同期メッセージ交換コンピュータ・システムとして機能させるコンピュータ・プログラムであって、
実行されることで前記コンピュータ・システムに
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する機能と、
前記メッセージと前記送達結果状態とを関連付ける機能と、
前記メッセージを前記宛先コンピュータ・システムへ送信する機能と、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する機能と、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する機能と
を発現させるコンピュータ・プログラム。
【請求項20】
通信ネットワークを介して送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと結合されている非同期メッセージ交換コンピュータ・システムであって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する手段と、
前記メッセージと前記送達結果状態とを関連付ける手段と、
前記メッセージを前記宛先コンピュータ・システムへ送信する手段と、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する手段と、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する手段と
を含むコンピュータ・システム。」(以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。)を、

「【請求項1】
送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
前記メッセージと前記送達結果状態とを関連付けるステップと、
前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
を含む方法。
【請求項2】
前記評価が、前記メッセージの送達の成功又は失敗のいずれかである、請求項1に記載の方法。
【請求項3】
前記メッセージが特定の時間内に特定の受信側コンピュータ・システムに到達する場合に前記メッセージの送達の成功と評価する請求項2に記載の方法。
【請求項4】
前記メッセージが特定の時間内に一定数未満の受信側コンピュータ・システムにしか到達しない場合に前記メッセージの送達の失敗と評価する請求項2に記載の方法。
【請求項5】
前記送達結果状態が、特定のメッセージと独立に定義される、請求項1乃至4のいずれかに記載の方法。
【請求項6】
前記送達結果状態が、永続オブジェクトとして表現される、請求項1乃至5のいずれか一項に記載の方法。
【請求項7】
前記送達結果状態が、関連するオブジェクトの組として表現される、請求項6に記載の方法。
【請求項8】
前記関連付けるステップは、
前記メッセージと1つまたは複数の永続オブジェクトとしての送達結果状態の表現とを関連付ける、請求項1乃至5のいずれか一項に記載の方法。
【請求項9】
特定の前記送達結果状態の表現が、異なるメッセージの組と関連付けられる、請求項8に記載の方法。
【請求項10】
前記監視するステップは、
1つまたは複数の宛先コンピュータ・システムおよび1つまたは複数のメッセージ受信側コンピュータ・システムの少なくとも1つを監視することで実行される、請求項1乃至9のいずれか一項に記載の方法。
【請求項11】
前記監視するステップは、
前記メッセージの送達をログに記録するステップを含む、請求項1乃至10のいずれか一項に記載の方法。
【請求項12】
前記評価するステップは、
前記監視結果としての前記ログに基づいて前記メッセージの送達を評価する請求項11に記載の方法。
【請求項13】
前記送信側コンピュータ・システムから照会を受信することに応答して、前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項1乃至12のいずれか一項に記載の方法。
【請求項14】
前記評価結果を前記送信側コンピュータ・システムへ送信するステップ
を更に含む、請求項1乃至13のいずれか一項に記載の方法。
【請求項15】
前記送信側コンピュータ・システムからオブジェクトを受信するステップと、
前記評価結果を前記オブジェクトへ送信するステップと
を更に含む、請求項1乃至13のいずれか一項に記載の方法。
【請求項16】
前記監視結果は監視時間を含む、請求項1乃至15のいずれか一項に記載の方法。
【請求項17】
前記受信するステップの後に、
前記送達結果状態を修正するステップをさらに含む、請求項1乃至16のいずれか一項に記載の方法。
【請求項18】
前記受信するステップの後に、
前記送達結果状態を置換するステップをさらに含む、請求項1乃至16のいずれか一項に記載の方法。
【請求項19】
前記送達結果状態は、予め送信側コンピュータ・システムにおいて定義されている、請求項1乃至18のいずれか一項に記載の方法。
【請求項20】
前記送達結果状態は、予め送信側コンピュータ・システムにおいて各メッセージ単位に定義されている、請求項1乃至19のいずれか一項に記載の方法。
【請求項21】
送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、あるコンピュータ・システムを前記非同期メッセージ交換コンピュータ・システムとして機能させるコンピュータ・プログラムであって、
実行されることで前記コンピュータ・システムに
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する機能と、
前記メッセージと前記送達結果状態とを関連付ける機能と、
前記メッセージを前記宛先コンピュータ・システムへ送信する機能と、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する機能と、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する機能と
を発現させるコンピュータ・プログラム。
【請求項22】
通信ネットワークを介して送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと結合されている非同期メッセージ交換コンピュータ・システムであって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信する手段と、
前記メッセージと前記送達結果状態とを関連付ける手段と、
前記メッセージを前記宛先コンピュータ・システムへ送信する手段と、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視する手段と、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する手段と
を含むコンピュータ・システム。」(以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。)
に補正するものである。

2.補正の適否
(1)特許法第17条の2第4項に規定する要件についての検討
補正後の請求項1及び補正後の請求項2は、その記載からして、それぞれ補正前の請求項1及び補正前の請求項2に対応したものである。また、補正後の請求項5?補正後の請求項22は、その記載からして、それぞれ補正前の請求項3?補正前の請求項20に対応したものである。
そして、補正後の請求項3及び補正後の請求項4は、その記載からして、新たに追加された請求項である。
本件補正は、補正後の請求項3及び補正後の請求項4を新たに追加する補正を行っており、補正後の請求項3及び補正後の請求項4を新たに追加する補正は、特許法第17条の2第4項の各号に掲げる「請求項の削除」、「特許請求の範囲の限定的減縮」、「誤記の訂正」、及び「明りょうでない記載の釈明」のいずれの事項を目的とするものでない。

(2)小括
したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第17条の2第4項の規定に違反するものであるから、特許法第159条第1項で読み替えて準用する同法第53条第1項の規定により却下すべきものである。

3.結論
本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に適合しないので、特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

第3.本願発明について
1.本願発明
平成18年10月16日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成18年5月8日付けの手続補正により補正された特許請求の範囲の請求項1の記載からして、

「送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
前記メッセージと前記送達結果状態とを関連付けるステップと、
前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価するステップと
を含む方法。」

にあるものと認める。

2.引用発明
原査定の拒絶の理由に引用された米国特許第5983265号明細書(以下、「引用文献」という。)には、図面とともに次の事項が記載されている。(備考:下線は当審で便宜上付与したものである。)

(ア)「To obviate these difficulties, EMS has undertaken to provide:
a) message/data queuing and communications services separated from application programs and processes; ・・・(後略)・・・.」(2カラム13行目?16行目。)
(和訳:これらの困難を取り除くために、EMSは、以下を提供する:
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. 」(5カラム29行目?58行目。)
(和訳:より明確に、EMSは、複数の外部又は内部の通信ネットワーク、プロトコル、およびトランスポート機能のためのキューイング、通信及び関連するサービスにアクセスするための単一の、一貫したプログラムインタフェースを提供する。・・・(中略)・・・
前に述べたように、本発明は、アプリケーション又はプロセスのために、データ又はメッセージの送信と到達の両方のキューイングを扱う。これは、ユーザが、通信メカニズムや通信機器がデータ又はメッセージを送るために利用可能になるのを待つ必要はないことを意味する。同様に、該アプリケーションやプロセス、又は他のアプリケーションやプロセスの実行中に、バックグラウンドでデータ/メッセージを受け取ることができる。)

(ウ)「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. 」(6カラム9行目?41行目。)
(和訳:以前に言及したように、各環境におけるEMSは特にその環境のために合わせた1セットのツールキットモジュールから成る。図2に詳細に示されているように、基本的なEMSモジュールは以下のとおり:
アプリケーションプログラムインタフェース(API)- アプリケーションプログラム/プロセスがEMS通信サービスにアクセスするための一貫したインタフェースを提供するソフトウェア・モジュールのセット。
キューマネージャ/ルータ(”キュー”/”ルータ”) - アプリケーション/プロセスにおけるデータ又はメッセージの送信と到達を可能とするとともに、それぞれの送達状態を監視する。
コミュニケーションエージェント(”Cｏmm.Agenｔ”又は”CA”)- それぞれの異なったネットワーク、プロトコルまたはトランスポート機能に対して1つずつ対応する。 (”通信ネットワークA”、”B”、及び”C”として表す。)
コミュニケーションマネージャ(”Cｏmm.Manageｒ”又は”CM”)- すべてのコミュニケーションエージェントに共通のメッセージング機能を提供する。
・・・(中略)・・・
いろいろなノードが、本発明のEMSを使用することで、通信網と通信設備によってリンクされる。)

(エ)「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 call (4, FIG. 3) to initiate the transmission (depending on the platform). The receiving EMS process is the EMS Router, FIG. 6, or Queue Manager "QUEUES", depending again on the platform involved.
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.」(11カラム30行目?67行目。)(注:前記SELNDは、SENDの誤記と認められる。)
(和訳:送信メッセージを展開する詳細は、送信メッセージを準備して、該メッセージを送信する主要なステップのアウトラインを記載した図6のフローチャートで提示される。
アプリケーションは、その正常処理の過程において、送信するためのデータのブロックを作成する(20)。このデータ・ブロック又はメッセージMDは、以前に説明したように、テキストのような単純な構造を有するか、または受信するアプリケーションだけに意味のある、バイナリ・データ、イメージ、テキスト、グラフィックス、および他のオブジェクトを含む複雑な内部構造を有する。EMSは、該メッセージ内容を損失なしに、指定された送付先に送達する仕事をする。
アプリケーション(または、ユーザ)は、メッセージMDがどのようにハンドリングされるべきか(これはメッセージのサービスクラスを定義する)を決める(21)。EMSによってサポートされるハンドリングオプションには、該メッセージ受信確認のレベル、他のトラフィックに対する優先順位、論理宛先によるルーティングサービス、識別子、修復性、再試行オプション、およびタイミング又はディレード送達オプションが含まれる。
ユーザ環境において確立されているID(図3の7)を使用して、該メッセージの宛先を指定する。そして、EMSのAPIファンクションを呼び出す前に、該メッセージのハンドリング仕様とメッセージの宛先をEMSの特定のデータバッファ(図4及び図6記載のインタフェースコントロールブロック(ICB)4’)にロードする。
EMSに対して該メッセージのデータコンテンツの定義(レングスとメッセージデータの先頭を示すポインタによる)と該メッセージのハンドリングのための指示の定義(ICBによる)をした後に、アプリケーションは、送信をするためにEMSのAPIを呼び出す。通常、これは該メッセージのリソースを準備するためのGETBUFコール(図3の3、6)と、送達を開始する(プラットホームに依存)ためのSENDコール(図3の4)とを必要とする。EMSの受信側のプロセスは、プラットフォームに応じて、図6に示すEMS Rｏｕｔeｒ又はキューマネジャ”QUEUES”が実行する。
EMSの受信側のプロセスがメッセージMDを受信すると、EMSは、該メッセージのハンドリングのための情報を該メッセージのデータの前にメッセージヘッダとして付けてカプセル化することで、転送するための完全なEMSメッセージを形成する。)

(オ)「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. 」(12カラム37行目?59行目。)
(和訳:メッセージデータとフレームフォーマットが、ノードでサポートされている各EMSにおいて受信(31)され、パケットにリアセンブルされる(32)。そこで、トランスポートレイヤのデータとその構造は取り除かれ、メッセージヘッダーは完全なEMS形式にアンパックされる。メッセージパケットは、リアセンブルされ(33)(送信側のEMSによって作成されたセグメンテーションは取り除かれる)、プロトコルデータを剥ぎ取り、ローカルのヘッダーデータが追加される(34)。セグメントはローカルのEMS QUEUEまたRｏｕｔeｒに転送され(35)、完全なメッセージがリアセンブルされ(36)、必要であれば、受信確認のメッセージが生成される(37)。このキューにおいて、メッセージは、該メッセージの受取人による受信か、又は次の転送ホップのための転送を待つ。宛先アプリケーション又はユーザが、割り当てられたEMS Qｕeｕeから、RECEIVEを使用して、メッセージを要求すると、メッセージストレージ領域が該アプリケーションに提供される。そして、必要ならば、メッセージICBに含まれる他のデータもアプリケーションに利用可能となる。アプリケーションは、対象とするユーザ(または、アプリケーション)のために該メッセージデータを読み込み、表示するか、又は保存することができる。ICBが、アプリケーションによる受信確認又はユーザによる受信確認を要求している場合、受信側のアプリケーションは、所定の受信確認をイニシエートしなければならない(40)。そして、正式な受信通知が別のメッセージとして該メッセージの送信側に転送される。)

(カ)「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 」(14カラム66行目?15カラム7行目。)
(和訳:最終的な宛先又は送達サービスによって、メッセージ(セグメント)の受信が成功したことは、送信側に返される受信確認メッセージによって知らされる。受信確認を生成するための能力として有益であるレベルとして少なくとも4つのレベルがある;すなわち、ユーザ(すなわち、人)による受信確認レベル、アプリケーションによる受信確認レベル、デバイス(EMS)による受信確認レベル、及び/または、通信プロトコルによる受信確認レベルである。そして、EMSはデバイス及び、通信プロトコルによる受信確認レベルを取り扱い、アプリケーションによる受信確認レベル、およびユーザによる受信確認レベルについては、APIを通じてサポートする。)

(キ)「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. 」(15カラム54行目?66行目。)
(和訳:宛先であるアプリケーションは、EMS RｏｕｔeｒにCOMMITをコールすることにより、該アプリケーションによる受信確認を生成することができる。該EMS Rｏｕｔeｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。宛先であるアプリケーションが、確認欄にアプリケーションによる受信確認が記されたメッセージに対して、COMMIT命令を発行することで、Rｏｕｔeｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じプロセスパスを通して、返送する。)

(ク)「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. 」(16カラム27行目?39行目。)
(和訳:同様に、宛先であるアプリケーションは、受信側のユーザによる受信確認メッセージを生成することができる。このために、該アプリケーションはEMS Rｏｕｔeｒに対してCOMMITを発行する必要がある。EMS Rｏｕｔeｒは、要求された前記ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。宛先であるアプリケーションが、確認モード欄にユーザによる受信確認が記されたメッセージに対して、COMMIT命令を発行することで、Rｏｕｔeｒは、要求された該ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じプロセスパスを通して、返送する。)

(ア)における記載「EMSは、以下を提供する:a) アプリケーションプログラムとプロセスとから分離された、メッセージ/データのキューイングと通信サービス」、及び(イ)における記載「本発明は、アプリケーション又はプロセスのために、データ又はメッセージの送信と到達の両方のキューイングを扱う。これは、ユーザが、通信メカニズムや通信機器がデータ又はメッセージを送るために利用可能になるのを待つ必要はないことを意味する。同様に、該アプリケーションやプロセス、又は他のアプリケーションやプロセスの実行中に、バックグラウンドでデータ/メッセージを受け取ることができる。」からすると、
引用文献には、送信側システムと受信側システムとEMSとが通信ネットワークに結合されており、前記EMSは、送信側システムと受信側システムに対して、メッセージを非同期に送受信すること(すなわち、非同期メッセージ交換)を可能とする方法であって、前記EMSに使用される方法が記載されていると解される。

そして、(エ)における記載「アプリケーションは、その正常処理の過程において、送信するためのデータのブロックを作成する(20)。 ・・・(中略)・・・アプリケーション(または、ユーザ)は、メッセージMDがどのようにハンドリングされるべきか(これはメッセージのサービスクラスを定義する)を決める(21)。EMSによってサポートされるハンドリングオプションには、該メッセージ受信確認のレベル、・・・(中略)・・・が含まれる。・・・(中略)・・・EMSのAPIファンクションを呼び出す前に、該メッセージのハンドリング仕様とメッセージの宛先をEMSの特定のデータバッファ(図4及び図6記載のインタフェースコントロールブロック(ICB)4’)にロードする。 ・・・(中略)・・・ EMSの受信側のプロセスは、プラットフォームに応じて、図6に示すEMS Rｏｕｔeｒ又はキューマネジャ”QUEUES”が実行する。EMSの受信側のプロセスがメッセージMDを受信すると、EMSは、該メッセージのハンドリングのための情報を該メッセージのデータの前にメッセージヘッダとして付けてカプセル化することで、転送するための完全なEMSメッセージを形成する。」、(カ)における記載「最終的な宛先又は送達サービスによって、メッセージ(セグメント)の受信が成功したことは、送信側に返される受信確認メッセージによって知らされる。受信確認を生成するための能力として有益であるレベルとして少なくとも4つのレベルがある;すなわち、ユーザ(すなわち、人)による受信確認レベル、アプリケーションによる受信確認レベル、デバイス(EMS)による受信確認レベル、及び/または、通信プロトコルによる受信確認レベルである。」からすると、EMSキューマネジャは、前記送信側システムからメッセージと該メッセージに関する受信確認レべル(すなわち、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び/または、通信プロトコルによる受信確認がされた状態)の定義とを受信し、前記メッセージに前記受信確認レべルを付けてカプセル化することで、転送するための完全なEMSメッセージを形成すると解される。
なお、(カ)における記載からすると、前記メッセージに関する受信確認レべルの定義とは、送信側システムがメッセージ単位で、該メッセージの送達結果状態が、ユーザによる受信確認がなされた状態、又はアプリケーションによる受信確認がなされた状態、又はデバイスによる受信確認がなされた状態等のどの送達結果状態の確認を要求するかを定義するものであって、前記メッセージに関する受信確認レべルを定義することによって、該メッセージの信頼性のある送達を保証するものであると認められる。
(オ)における記載「メッセージデータとフレームフォーマットが、ノードでサポートされている各EMSにおいて受信(31)され、パケットにリアセンブルされる(32)。そこで、トランスポートレイヤのデータとその構造は取り除かれ、メッセージヘッダーは完全なEMS形式にアンパックされる。メッセージパケットは、リアセンブルされ(33)(送信側のEMSによって作成されたセグメンテーションは取り除かれる)、プロトコルデータを剥ぎ取り、ローカルのヘッダーデータが追加される(34)。 セグメントはローカルのEMS QUEUEまたRｏｕｔeｒに転送され、・・・(中略)・・・宛先アプリケーション又はユーザが、割り当てられたEMS Qｕeｕeから、RECEIVEを使用して、メッセージを要求すると、・・・(中略)・・・アプリケーションに利用可能となる。」からすると、前記メッセージを受信側システムに関係づけられているEMS QUEUE(すなわち、EMSキューマネジャ)へ送信すると解される。
(ウ)における記載「キューマネージャ/ルータ(”キュー”/”ルータ”) - アプリケーション/プロセスにおけるデータ又はメッセージの送信と到達を可能とするとともに、それぞれの送達状態を監視する。」及び(オ)における記載「このキューにおいて、メッセージは、該メッセージの受取人による受信か、又は次の転送ホップのための転送を待つ。・・・(中略)・・・アプリケーションは、対象とするユーザ(または、アプリケーション)のために該メッセージデータを読み込み、表示するか、又は保存することができる。」、(カ)における記載「EMSはデバイス及び、通信プロトコルによる受信確認レベルを取り扱い、アプリケーションによる受信確認レベル、およびユーザによる受信確認レベルについては、APIを通じてサポートする。」、(キ)における記載「宛先であるアプリケーションは、EMS RｏｕｔeｒにCOMMITをコールすることにより、該アプリケーションによる受信確認を生成することができる。該EMS Rｏｕｔeｒは、要求された該アプリケーションによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。」、及び(ク)における記載「EMS Rｏｕｔeｒは、要求された前記ユーザによる受信確認メッセージを生成して、それを別のデータグラムとしてメッセージの発信元に対して、同じネットワークパスを通して、返送する。」からすると、前記メッセージの前記受信側システムに関係づけられているEMSキューマネジャから前記受信側システムへの送達を監視するとともに、前記監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送すると解される。

したがって、引用文献には、次の発明(以下、「引用発明」という。)が記載されているものと認められる。

送信側システムと受信側システムと非同期メッセージ交換のためのEMSとが通信ネットワークに結合されており、前記非同期メッセージ交換のためのEMSに使用される方法であって、
前記送信側システムからメッセージと前記メッセージに関する受信確認レべル(すなわち、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び/または、通信プロトコルによる受信確認がされた状態)の定義とを受信するステップであって、前記メッセージに関する受信確認レべルの定義とは、送信側システムがメッセージ単位で、該メッセージの送達結果状態が、ユーザによる受信確認がなされた状態、又はアプリケーションによる受信確認がなされた状態、又はデバイスによる受信確認がなされた状態等のどの送達結果状態の確認を要求するかを定義するものであって、
前記メッセージと前記受信確認レべルとをカプセル化したEMSメッセージを形成するステップと、
前記メッセージを受信側システムに関係づけられているEMSキューマネジャへ送信するステップと、
前記メッセージの前記受信側システムに関係づけられているEMSキューマネジャから前記受信側システムへの送達を監視するステップと、
前記監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送するステップと
を含む方法。

3.対比・判断
ここで、本願発明と引用発明とを対比する。
引用発明の「送信側システム」、「受信側システム」、及び「非同期メッセージ交換のためのEMS」は、それぞれ、本願発明の「送信側コンピュータ・システム」、「受信側コンピュータ・システム」及び「非同期メッセージ交換コンピュータ・システム」に相当する。
引用発明の「メッセージに関する受信確認レべル」は、ユーザによる受信確認がされた状態、アプリケーションによる受信確認がされた状態、デバイスによる受信確認がされた状態、及び/または、通信プロトコルによる受信確認がされた状態を意味することから、本願発明の「メッセージに関する送達結果状態」に相当する。
引用発明の「メッセージと前記受信確認レべルとをカプセル化したEMSメッセージを形成する」ことは、メッセージと前記受信確認レべルとを関連づけてカプセル化されたと解されるから、本願発明の「メッセージと前記送達結果状態とを関連付ける」ことに相当する。
引用発明の「受信側システムに関係づけられているEMSキューマネジャ」は、引用発明の「非同期メッセージ交換のためのEMSに使用される方法」において、メッセージを当該「EMSキューマネジャ」へ送信するものであって、メッセージの当該「EMSキューマネジャ」から前記受信側システムへの送達を監視するものであり、他方、本願発明の「宛先コンピュータ・システム」も本願発明の「非同期メッセージ交換コンピュータ・システムに使用される方法」において、メッセージを当該「宛先コンピュータ・システム」へ送信するものであって、メッセージの当該「宛先コンピュータ・システム」から前記受信側コンピュータ・システムへの送達を監視するものであること、さらに、本願明細書の発明の詳細な説明の段落【0028】に「既存のメッセージ・ミドルウェア110は、メッセージ・キューまたはJMS Topicオブジェクトなどの宛先112への(信頼性のある)メッセージ送達に使用される。」と記載されているように、「宛先コンピュータ・システム」としてメッセージ・キューを例示していることからすると、引用発明の「受信側システムに関係づけられているEMSキューマネジャ」は、本願発明の「宛先コンピュータ・システム」に相当する。
そして、前記「受信側システムに関係づけられているEMSキューマネジャ」が、送信側システムと受信側システムと非同期メッセージ交換のためのEMSと通信ネットワークで結合されていることは、自明の事項である。

そして、引用発明の「監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する」ことと本願発明の「監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する」こととは、ともに監視結果と前記送達結果状態の定義とに基づいて前記メッセージに関する所定の処理を行う点で共通する。

したがって、本願発明と引用発明とは、以下の点で一致し、また、相違している。

(一致点)
送信側コンピュータ・システムと宛先コンピュータ・システムと受信側コンピュータ・システムと非同期メッセージ交換コンピュータ・システムとが通信ネットワークに結合されており、前記非同期メッセージ交換コンピュータ・システムに使用される方法であって、
前記送信側コンピュータ・システムからメッセージと前記メッセージに関する送達結果状態の定義とを受信するステップと、
前記メッセージと前記送達結果状態とを関連付けるステップと、
前記メッセージを前記宛先コンピュータ・システムへ送信するステップと、
前記メッセージの前記宛先コンピュータ・システムから前記受信側コンピュータ・システムへの送達を監視するステップと、
前記監視結果と前記送達結果状態の定義とに基づいて前記メッセージに関する所定の処理を行うステップと
を含む方法。

(相違点)
本願発明は、「監視結果と前記送達結果状態の定義とに基づいて前記メッセージの送達を評価する」のに対し、引用発明は、「監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する」点。

相違点について検討する。
引用発明において、監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したことを示す受信確認メッセージを送信側システムに返送する際に、監視結果と前記受信確認レベルの定義とに基づいて前記メッセージの送達が前記定義された受信確認レベルで受信したかどうかを評価するように構成することは、当業者であれば、適宜なし得たことである。
よって、相違点は格別なものではない。

そして、本願発明の作用効果も、引用発明から当業者が予測できる範囲のものである。
したがって、本願発明は、引用発明から容易に発明できたものであるから、特許法第29条第2項の規定により特許を受けることができない。

4.むすび
以上のとおり、本願の請求項1に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2009-06-10 
結審通知日 2009-06-16 
審決日 2009-06-30 
出願番号 特願2002-520071(P2002-520071)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 57- Z (G06F)
最終処分 不成立  
前審関与審査官 鳥居 稔  
特許庁審判長 赤川 誠一
特許庁審判官 石井 茂和
宮司 卓佳
発明の名称 非同期メッセージ交換システムで使用される方法および装置  
代理人 上野 剛史  
代理人 太佐 種一  
代理人 坂口 博  
代理人 市位 嘉宏  

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