【事件の表示】
　特願２００６−　４０８２８「イベント通知方法、携帯端末機及びサーバ」拒絶査定不服審判事件〔平成１８年　９月　７日出願公開、特開２００６−２３６３４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続きの経緯
　本願は、平成１８年２月１７日（優先権主張２００５年２月２５日、韓国）の出願であって、平成２０年７月２４日付けで拒絶理由が通知され、同年１１月５日付けで手続補正がなされたが、平成２１年８月３日付けで拒絶査定がなされ、これに対し、同年１２月１１日付けで拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　　　
第２　平成２１年１２月１１日付けの手続補正の補正却下の決定
［補正却下の決定の結論］
　平成２１年１２月１１日付けの手続補正（以下、「本件補正」という。）を却下する。
［理由］
（１）補正の内容
　本件補正により、少なくとも特許請求の範囲の請求項１は、
「クライアントが、通知を要求する特定イベント、該特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、
　前記有効時間が経過するまでの間における前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、
　を含み、
　前記通知を要求する特定イベント及び前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれることを特徴とするイベント通知方法。」と補正された。
　　
（２）補正の適否について
　上記補正は、本件補正前の請求項１に記載した発明を特定するために必要な事項である「特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージ」について「通知を要求する特定イベント」「を含む」及び「前記通知を要求する特定イベント及び前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれる」とするものであり、本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　　 
  そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか、すなわち平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するかどうかについて以下に検討する。
　
（３）引用文献
（１）原査定の拒絶の理由に引用された「NIEMI A.，Session Initiation Protocol (SIP) Event Notification Throttle Mechanism，Internet-Draft draft-niemi-sipping-event-throttle-02.txt，２００５年２月２１日，ＵＲＬ，http://tools.ietf.org/id/draft-niemi-sipping-event-throttle-02.txt」（以下、「引用例１」という。）には、図面とともに次の記載がある。
（ア）「1.  Introduction
   
The SIP events framework [1] defines a generic framework for subscriptions to and notifications of events related to SIP systems.  This framework defines the methods SUBSUCRIBE and NOTIFY, and introduces the concept of an event package, which is a concrete application of the SIP events framework to a particular class of events.
  
One of the things the SIP events framework mandates is that each event package specification defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier.   Such a limit is provided in order to reduce network congestion.」（第３／１５頁第１行〜第１２行）
（当審訳：
１．イントロダクション
SIPイベントフレームワーク[1]は、SIPシステムと関係するイベントの通知要請（subscriptions）およびイベントの通知（notifications）の総括的なフレームワークを定義します。このフレームワークはメソッドSUBSUCRIBEおよびNOTIFYを定義し、特別のクラスのイベントに対するSIPイベントフレームワークの具体的なアプリケーションであるイベントパッケージの概念を導入します。
　　
SIPイベントフレームワークが命ずるもののうちの１つは、イベントパッケージ記述が、一つの通知者（notifier）によって発生されることが許可される通知の割合の絶対的最大値を定義するということです。そのような制限はネットワークの混雑を縮小するために提供されます。）
　　　
（イ）「3.1.1  Pre-conditions
   
A presence application in Lisa's mobile device contains a list of buddies or presentities. In order to decrease the processing and network load of watching 100 presentities, Lisa's presence application has included an event throttle to each of the subscriptions, limiting the maximum rate at which notifications are to be generated to once per 20 seconds.
   
Heikki is one of the presentities Lisa is watching.  Heikki's presence agent conforms to the throttling policy requested by Lisa's presence application. The event package includes only full-state notifications.
　
3.1.2  Normal Flow
 　
Heikki publishes a presence status of red, which results in a presence notification to be sent to Lisa.
　
In 10 seconds, Heikki publishes a presence status of blue.  As the throttling policy set by Lisa only allows the presence agent to generate notifications at a maximum of once per 20 seconds, the notifications is put on hold.
   
After another 10 seconds, the notifications is allowed to be sent to Lisa.
   
 Lisa receives a presence update conforming to the set throttling policy.  」（第４／１５頁第６行〜第２７行）
（当審訳：
３．１．１　プリコンディション
　　　
Ｌｉｓａのモバイル装置のプレゼンスアプリケーションは、仲間または出席者のリストを含んでいます。１００人の出席者を見る処理およびネットワーク負荷を減少させるために、Ｌｉｓａのプレゼンスアプリケーションは、各イベント通知要請（subscriptions）にイベントスロットルを含んでいて、それはイベント通知（notifications）が２０秒につき一度生成される最高割合に制限しています。
　　
ＨｅｉｋｋｉはＬｉｓａが見ている出席者のうちの１つです。ＨｅｉｋｋｉのプレゼンスエージェントはＬｉｓａのプレゼンスアプリケーションによって要求された、制限ポリシーに従います。イベントパッケージはフルステートのイベント通知だけを含んでいます。
　　 
３．１．２　ノーマルフロー
　
Ｈｅｉｋｋｉは、Ｌｉｓａに送られるプレゼンス通知となる“赤”のプレゼンスステータスを発行します。
　
１０秒後、Ｈｅｉｋｋｉは、“青”のプレゼンスステータスを発行します。Ｌｉｓａによってセットされたスロットリングポリシーは、プレゼンスエージェントが最大で２０秒毎に通知を発生することのみ可能にするとともに、該通知を保持状態にします。
　　
さらに１０秒後、該通知がＬｉｓａに送られることが許可されます。
　　
Ｌｉｓａは、セットされたスロットリングポリシーに応じる最新のプレゼンスを受け取ります。）
　　　
（ウ）「3.2  Requirements
　　
REQ1: The subscriber must be able to set using a throttle mechanism the minimum time period between two notifications in a specific subscription.
  　
REQ2: The subscriber must be able to indicate that it requires the notifier to comply with the suggested throttling policy in a specific subscription.
   
REQ3: The notifier must be able to indicate that it does not support the use of a throttle mechanism in the subscription.
   
REQ4: It must be possible to use the throttle mechanism in subscriptions to all events.
   
REQ5: It must be possible to use the throttle mechanism together with any event filtering mechanism.
   
REQ6: The notifier must be allowed to use a throttling policy in which the minimum time period between two notifications is longer than the one given by the subscriber.
   
For example, due to congestion reasons, local policy at the notifier could temporarily dictate a throttling policy that effect increases the subscriber-configured minimum time period between two notifications.
　　
REQ7: The throttle mechanism must provide a reasonable resolution for setting the minimum  period between two notifications.　At a minimum, the throttle mechanism must include discussion of the situation resulting from a minimum time period which exceeds the subscription duration, and should provide mechanisms for avoiding this situation.
   
REQ8: The throttle mechanism must allow for the application of authentication and integrity　protection mechanism to subscriptions invoking that mechanism.」
（第６／１５頁第１６行〜第７／１５頁第１０行）
(当審訳：
３．２　必要条件（Requirements）
　　　
REQ１：通知要請者（subscriber）は、スロットルメカニズムで使用する特定の通知要請（subscription）において２つの通知（notifications）間の最小の期間をセットすることができなければなりません。
　
REQ２：通知要請者（subscriber）は、特定の通知要請（subscription）で示されたスロットリングポリシーに応じるように通知者（notifier）に要求することを示さなければなりません。
　　　
REQ３：通知者（notifier）は、通知要請（subscription）のスロットルメカニズムの使用をサポートしないことを示すことができなければならない。
　　　
REQ４：すべてのイベントの通知要請（subscription）においてスロットルメカニズムを使用することが可能でなければなりません。
　　　　
REQ５：任意のイベントフィルタリングメカニズムと一緒にスロットルメカニズムを使用することが可能でなければなりません。
　　　
REQ６：通知者は、２つの通知（notifications）間の最小の期間が通知要請者（subscriber）から与えられたものより長い、スロットリングポリシーを使用することが許されなければなりません。　　　
　
例えば、混雑しているという理由により、通知者（notifier）のローカルポリシーは、通知要請者（subscriber）が形成した２つの通知（notifications）間の最小の期間を増加するようにスロットリングポリシーを一時的に指示することができる。
　　　
REQ７：スロットルメカニズムは、２つの通知（notifications）間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請（subscription）の持続期間（duration）を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならず、そして、この状況を回避するためのメカニズムを提供するべきです。
　　　
REQ８：スロットルメカニズムは、メカニズムを起動する通知要請（subscription）の認証と完全保護メカニズムのアプリケーションを用意しなければなりません。)
   
（エ）「3.3  Event Throttle Model
     
The notifier is responsible for sending out event notifications upon state changes of the subscribed resource.  We can model the notifier as consisting of three components: the event state source S, the packetizer P and the output buffer Bo, as shown in Figure 5.
   
In short, the notifier reads event state changes from the event state source, package them into event notifications, and submits them into the output buffer.  The rate at which this output buffer drains is controlled by the subscriber via event throttle mechanism.」（第７／１５頁第１３行〜第２１行）
（当審訳：
３．３　イベント　スロットル　モデル
   
通知者（notifier）は、通知要請された資源の状態（ステート）の変更によりイベント通知（notifications）を送る能力があります。私たちは３つのコンポーネントから成るとして通知者（notifier）をモデル化することができます：図５に示されるように、イベント状態（ステート）資源S、パケタイザーPおよび出力バッファーBo。
   
要するに、通知者（notifier）はイベント状態（ステート）資源からイベント状態（ステート）変更を読み出し、それらをイベント通知（notifications）にパッケージし、出力バッファーへ提出します。この出力バッファーが出力する割合はイベントスロットルメカニズムによって通知要請者（subscriber）によってコントロールされます。）
　　　
（オ）「3.4  Basic Operation
   
A subscriber that wants to limit the rate of event notification in a specific subscription does by suggesting a throttle as part of the SUBSCRIBE message.  The throttle indicating the minimum time allowed between transmission of two consecutive notifications in a subscription is given as an Event header parameter in the SUBSCRIBE request.」（第８／１５頁第４行〜第１０行）
（当審訳：
３．４　基本オペレーション
　　
特定の通知要請（subscription）においてイベント通知（notifications）の割合を制限したい通知要請者（subscriber）は、SUBSCRIBE（通知要請）メッセージの一部にスロットルを示すことにより行います。通知要請（subscription）における連続した２つの通知（notifications）の送信間で許可された最小の時間を示すスロットルは、SUBSCRIBE（通知要請）リクエスト中のイベントヘッダパラメータとして与えられます。）　　　
    
（カ）「4.2.1  Subscriber Behavior
　　
In general, the way in which a subscriber generates SUBSCRIBE requests and processes NOTIFY requests is according to RFC 3265 [1].
  
A subscriber that wishes to throttle the notifications in a subscription includes a throttle Event header parameter in the SUBSCRIBE request, indicating in seconds the desired throttle value.
The value of this parameter is an integral number of seconds in decimal. 
　　　
In case the notifier dose not support the event-throttle extension, the subscriber SHOULD retry the subscription without that throttle extension present, unless doing so would overly burden the subscriber.
  
In this case the subscriber can resort to other means of limiting the notification rate. For example, instead of a subscription, it can fetch or poll the event state. 
   
There are two main consequencies for the subscriber when applying the throttle mechanism: 
state transitions may be lost, and event notifications may be delayed.  If either of these side effects constitute a problem to the application that is to utilize event throttles, developers are instructed not to use the mechanism.」（第９／１５頁第３行〜第２２行）
（当審訳：
４．２．１　通知要請者（Subscriber）の振る舞い
　　　
一般に、通知要請者（subscriber）がSUBSCRIBE（通知要請）リクエストを生成し、NOTIFY（通知）リクエストを処理する方法は、RFC 3265[1]に従います。
　　
通知要請（subscription）において通知を調節したい通知要請者（subscriber）は、SUBSCRIBE（通知要請）リクエストに希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータを含めます。このパラメータの値は秒で１０進の整数です。
　　
通知者（notifier）が拡張“イベントスロットル”をサポートしない場合、通知要請者（subscriber）は、拡張プレゼントスロットルなしで通知要請（subscription）を再び試みなければなりません、もし、それが通知要請者（subscriber）の過度の負担でなければ。
   
この場合、通知要請者（subscriber）は通知割合を制限する他の手段に頼ることができます。例えば、通知要請（subscription）の代わりに、それはイベント状態（ステート）を取って来るか獲得することができます。
   
スロットルメカニズムを適用する場合、通知要請者（subscriber）には、２つの主な結果があります：状態（ステート）推移が失われること、及びイベント通知が遅れることです。これらの副次的作用のどちらかによってイベントスロットルを利用するアプリケーションに問題が生じる場合、開発者はメカニズムを使用しないように命じられます。 ）
　　
（キ）「4.2.2  Notifier Behavior
　　　　
In general, the way in which a notifier processes SUBSCRIBE requests and generates NOTIFY requests is according to RFC 3265 [1].
　　　
A notifier that supports the event-throttle extension extracts the value of the throttle Event header parameter, and uses it as the minimum time allowed between two notifications.
　　　
A compliant notifier MUST NOT generate notifications more frequent than what the throtlle allows for, except when generating the notification either upon receipt of a SUBSCRIBE request (the first notifications) or upon termination of the subscription (the last notifications).　　Such notifications reset the throttle timer, even though they do not need to abide by it.
　　　　
Retransmissinons of NOTIFY requests are not affected by the throttle, i.e., the throttle only applies to the generation of new transactions.　In other words, the throttle is reset only after the previous transaction has completed.
   
4.3  Selecting the Throttle Interval
  
Special care needs to be taken when selecting the throttle value. Using the throttle syntax it is possible to insist both very short and very long throttles to be applied to the subscription.  For example, a throttle could potentially set a minimum time value between notifications that exceeds the subscription expiration value.  Such a configuration would effectively quench the notifier, resulting in exactly two notifications to be generated.」（第９／１５頁第２３行〜第１０／１５頁第１３行）
（当審訳：
４．２．２　通知者（Notifier）の振る舞い
  
一般に、通知者（notifier）がSUBSCRIBE（通知要請）リクエストを処理し、NOTIFY（通知）リクエストを発生する方法は、RFC 3265[1]によるものです。
　　　
拡張“イベントスロットル”をサポートする通知者（notifier）は、イベントヘッダパラメータ“throtlle”の値を抽出し、２つの通知（notifications）間に許可した最小の時間として、それを使用します。
　　
それに応じる通知者（notifier）は、SUBSCRIBE（通知要請）リクエスト(最初の通知)の受取あるいは通知要請（subscription）終了(通知の終わり)のいずれかの通知を生成するとき以外は、スロットルが許可するより頻繁な通知を生成してはいけません。そのような通知は、たとえそれに従う必要がなくてもスロットル・タイマーをリセットします。
　　　
NOTIFY（通知）リクエストの再伝送はスロットルによって影響されません、つまり、スロットルは、新しい処理の生成にのみ適用されます。言いかえれば、前の処理が終わった後にだけ、スロットルはリセットされます。
　　
４．３　スロットル間隔の選択
　　
スロットル値を選択する場合、特別の注意を払う必要があります。スロットルシンタックスを使用して、非常に短いスロットルと非常に長いスロトッルの両方を通知要請（subscription）に適用することが可能です。例えば、スロットルは、通知要請（subscription）終了（expiration）値を超えるような通知（notifications）間の最小値をセットすることもできます。そのような配置は、正確に生成される２つの通知（notifications）を、通知者（notifier）は実際に失うことになります。）
　　　
　以上の記載によれば、この引用例１には以下のような発明（以下、「引用発明」という。）が開示されていると認められる。
「通知要請者（subscriber）がSUBSCRIBE（通知要請）リクエストを生成し、通知者（notifier）がSUBSCRIBE（通知要請）リクエストを処理し、通知要請された資源の状態（ステート）の変更によりイベント通知（notifications）を発生し、イベント通知（notifications）を通知要請者（subscriber）に送る方法であって、
　通知を調節したい通知要請者（subscriber）は、SUBSCRIBE（通知要請）リクエストに希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータを含め、
　通知者（notifier）は、イベント状態（ステート）資源からイベント状態（ステート）変更を読み出し、それらをイベント通知（notifications）にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知（notifications）を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し、
　通知者（notifier）が通知要請者（subscriber）に送る通知（notifications）間に許可する最小の時間を通知要請者（subscriber）がコントロールすることを特徴とするイベント通知方法。」
　　　
（２）原査定において参考文献として引用された「ROCH A B.，Session Initiation Protocol (SIP) Event Notification，RFC 3265，The Internet Engineering Task Force (IFTF)，２００２年６月，ＵＲＬ，http://www.ietf.org/rfc/rfc3265-02.txt」（以下、「引用例２」という。）には、図面とともに次の記載がある。
（ア）「3.1.1.  Subscription Duration 
   
SUBSCRIBE requests SHOULD contain an Expires header (defined in SIP [1]).  This expires value indicates the duration of subscription.  In order to keep subscriptions effective beyond the duration communicated in the Expires header, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE message on the same dialog as defined in SIP [1].
   
If no Expires header is present in a SUBSCRIBE request, the implied default is defined by the event package being used.
    
200-class responses to SUBSCRIBE requests also MUST contain an Expires header.  The period of time in the response MAY be shorter but MUST NOT be longer than specified in the request.  The period of time in the response is the one which defines the duration of the subscription.
   
An Expires parameter on the Contact header has no semantics for SUBSCRIBE and is explicitly not equivalent to an Expires header in a SUBSCRIBE request or response.
  
A natural consequence of this scheme is that a SUBSCRIBE with an Expires of 0 constitutes a request to unsubscribe from an event.」（第５／３２頁第１１行〜第２９行）
（当審訳：
３．１．１．　通知要請（Subscription）持続期間（Duration）
  
SUBSCRIBE（通知要請）リクエストはExpiresヘッダ(SIP[1]の中で定義された)を含むべきです。この終了（expires）値は、通知要請（Subscription）の持続期間（duration）を示します。Expiresヘッダで伝達された持続期間（duration）を越えてサブスクリプションを有効にしておくために、通知要請者は、SIP[1]に定義されるのと同じダイアログで新しいSUBSCRIBEメッセージを使用して周期的な方式で通知要請（Subscriptions）をリフレッシュする必要があります。
　
SUBSCRIBE（通知要請）リクエスト中にExpiresヘッダが存在しない場合、暗黙的にデフォルトが使用されているイベントパッケージによって定義されます。
　
SUBSCRIBE（通知要請）リクエストに対する200クラスのレスポンスは、さらにExpiresヘッダを含んでなければいけません。レスポンス中の期間は、リクエストで指定されたより短くてもよいが、長くあってはいけません。レスポンス中の期間は通知要請（Subscription）の持続期間（duration）を定義するものです。
　　　Contact ヘッダのExpiresパラメータは、SUBSCRIBE（通知要請）のためのセマンティクス（判断基準）を持っておらず、SUBSCRIBE（通知要請）リクエストやレスポンス中のExpiresヘッダと等価でないことは明らかです。
　　　
ゼロのExpiresのSUBSCRIBE（通知要請）が、あるイベントの通知要請を取り消すリクエストを構成することは、このスキームの自然な結果です。）
　　
（イ）「3.1.2.  Identification of Subscribed Events and Event Classes
    
Identification of events is provided by three pieces of information: Request URI, Event Type, and (optionally) message body. 
   
The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [1].  It also contains enough information to identify the resource for which event notification is desired, but not necessarily enough information to uniquely identify the nature of the event   (e.g., sip:adam@dynamicsoft.com would be an appropriate URI to subscribe to for my presence state; would also be an appropriate URI to subscribe to the state of my voice mailbox).
   
Subscribers MUST include exactly one event header in SUBSCRIBE requests, indicating to which event or class of events they are subscribing.  The event header will contain a token which indicates the type of state for which a subscription is being requested.  This token will be registered with the IANA and will correspond to an event package which further describes the semantics of the event or event class.   The event header MAY also contain an id parameter.  This id parameter, if present, contains an opaque token which identifies the specific subscription within a dialog.  An id parameter is only valid within the scope of single dialog.
   
If the event package to which the event token corresponds defines behavior associated with the body of its SUBSCRIBE requests, those semantics apply.」（第５／３２頁第３０行〜第６／３２頁第２４行）
（当審訳：
３．１．２．　通知要請されたイベントとイベントクラスの識別
　　　
イベントの識別は情報の３つの部分によって提供されます：リクエストURI、イベントタイプおよび(選択的な)メッセージ本体です。
　　
SUBSCRIBE（通知要請）リクエストのリクエストURIは、最も重要なことに、SIP[1]で概説されたリクエストルーティング手続きで適切なエンテティへリクエストを送るために十分な情報を含んでいます。さらに、それは望まれるイベント通知の資源を識別するのに十分な情報を含んでいますが、イベントの性質を唯一に識別するのに必ずしも十分な情報ではありません(例えば、「sip:adam@dynamicsoft.com」は、私のプレゼンスステートを通知要請するのに適切なURIになるでしょう；さらに私のボイスメールボックスのステートを通知要請するのに適切なURIになるでしょう。)。
　　　
通知要請者（subscriber）は、通知要請しているイベントあるいはイベントのクラスを示すために、SUBSCRIBE（通知要請）リクエスト中に“Event”ヘッダを含ませなければならない。“Event”ヘッダは、要求されているサブスクリプションのステートのタイプを示すトークンを含むでしょう。このトークンはIANAで登録され、イベントまたはイベントのクラスのセマンティクス（判断基準）についてさらに記述するイベントパッケージに対応するでしょう。“Event”ヘッダはさらに“id”パラメータを含んでいるかもしれません。
この“id”パラメータが存在する場合、ダイアログ内の特定のサブスクリプションを識別する不透明なトークンを含んでいます。“id”パラメータは、１つのダイアログの範囲内でのみ有効です。
　　
イベントトークンに対応するイベントパッケージがそのSUBSCRIBE（通知要請）リクエストの本体に関連した振る舞いを定義する場合、それらのセマンティクス（判断基準）が適用されます。）
　　
（ウ）「3.1.6.1  Initial SUBSCRIBE Transaction Processing
In no case should a SUBSCRIBE transaction extend for any longer than the time necessary for automated processing.  In particular, notifiers MUST NOT wait for a user response before returning a final response to a SUBSCRIBE request.
   
・・・中略・・・
　　
The notifier SHOULD check that the event package specified on the event header is understood.  If not, the notifier SHOULD return a 489 Bad Event response to indicate that the specified event/event class is not understood.
   
The notifier SHOULD also perform any necessary authentication and authorization per its local policy.  See section 3.1.6.3.
    
The notifier MAY also check that the duration in the Expires header is not too small.  If and only if the expiration interval is greater than zero and smaller than one hour AND less than a notifier configured minimum, the notifier MAY return a 423 Interval too small error which contains a Min-Expires header field.  The Min-Expires header field is described in SIP [1].
   
If the notifier is able to immediately determine that it understands the event package, that the authenticated subscriber is authorized to subscribe, and that there are no other barriers to creating the subscription, it creates the subscription and a dialog (if necessary), and returns a 200 OK response (unless doing so would reveal authorization policy in an undesirable fashion; see section 5.2.).
   
If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a 202 Accepted response.  This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet.
   
When the subscription is created in the notifier, it stores the event package name and Event header id parameter (if present) as part of the subscription information.」（第８／３２頁第２９行〜第９／３２頁第２０行）
（当審訳：
３．１．６．１．　初期通知要請トランザクション処理
 
決して、SUBSCRIBE（通知要請）トランザクションは自動処理に必要な時間を越えて伸ばすべきではありません。特に、通知者は、SUBSCRIBE（通知要請）リクエストに対する最後のレスポンスを返す前にユーザレスポンスを待ってはいけません。
・・・（中略）・・・
　　
通知者（notifier）は、“Event”ヘッダ中に指定されたイベントパッケージが理解されることをチェックするべきです。そうでなければ、通知者（notifier）は、指定されたイベント/イベントクラスが理解されないことを示すために“489 Bad Event”レスポンスを返すべきです。
　　
通知者（notifier）は、さらに自身のローカルポリシー毎に、必要であるどのような認証および認可も行なうべきです。セクション3.1.6.3を参照してください。
　　　
通知者（notifier）はさらに “Expires”ヘッダ中のduration（持続）が小さすぎないことチェックするかもしれません。expiration（終了）間隔がゼロより大きく１時間より小さく、通知者（notifier）が形成した最小値未満の場合のみ、通知者（notifier）は”Min-Expires“ヘッダフィールドを含む”423 Interval too small“エラーを返すかもしれません。”Min-Expires“ヘッダフィールドはSIP[1]に述べられています。
　　　
もし、イベントパッケージを理解すること、認証された通知要請者（subscriber）が通知要請することを認めること、そして、サブスクリプションを作成する他の障害がないことを、通知者（notifier）が直ちに決めることができる場合、通知要請（Subscription）およびダイアログ(必要ならば)を作成し、“200 OK”レスポンス(もし、そうすることが認証ポリシーを露わにすることにならなければ；セクション5.2を参照してください。)を返します。
　
通知者（notifier）が直ちに通知要請（Subscription）を作成することができない場合(例えば、それは認可のためのユーザ入力を待つ必要がある、あるいは現在到達できない別のノードの代理をしている。)、あるいは認証ポリシーを隠したい場合、“202 Accepted”レスポンスを返すでしょう。このレスポンスは、リクエストが受け取られ理解されたことを示しますが、通知要請（Subscription）がすでに認可されたことを必ずしも示しません。
　
サブスクリプションが通知者（notifier）に作成される場合、通知要請（Subscription）情報の一部として、イベントパッケージ名および“Event”ヘッダ“id”パラメータ（もし、あれば）を格納します。）
　　　　
（４）　対　比
　本願補正発明と引用発明とを対比する。
（１）引用発明の「通知要請者（subscriber）」は、本願補正発明の「クライアント」に相当する。
（２）引用発明の「SUBSCRIBE（通知要請）リクエスト」は、本願補正発明の「イベント通知要求メッセージ」に相当する。
（３）引用発明の「SUBSCRIBE（通知要請）リクエストに」含まれる「希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータ」は、本願補正発明の「特定イベントの通知周期に関する周期情報」に相当し、本願補正発明の「前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれる」に対応するといえる。
（４）引用発明の「通知者（notifier）」は、本願補正発明の「サーバ」に対応するといえる。
（５）引用発明の「イベント状態（ステート）資源からイベント状態（ステート）変更を読み出し、それらをイベント通知（notifications）にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知（notifications）を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し」は、本願補正発明の「特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する」に対応するといえる。
　　
　したがって、本願補正発明の用語を用いて表現すると両者は、
「クライアントが、特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、
　前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、
　を含み、
　前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれることを特徴とするイベント通知方法。」
で一致するものであり、次の点で相違している。
　
（相違点）
　本願補正発明は、イベント通知要求メッセージに、「通知を要求する特定イベント、該特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であって、「前記通知を要求する特定イベント」は、「前記イベント通知要求メッセージのヘッダーに含まれる」のに対し、引用発明は、そのような構成は明らかでない点。
　　
（５）判断
　上記相違点について検討する。
　引用例２には、「通知要請者（subscriber）は、通知要請しているイベントあるいはイベントのクラスを示すために、SUBSCRIBE（通知要請）リクエスト中に“Event”ヘッダを含ませなければならない。」及び「SUBSCRIBE（通知要請）リクエストはExpiresヘッダ(SIP[1]の中で定義された)を含むべきです。この終了（expires）値は、通知要請（Subscription）の持続期間（duration）を示します。」と記載されている。
　そして、引用例１には、「一般に、通知要請者（subscriber）がSUBSCRIBE（通知要請）リクエストを生成し、NOTIFY（通知）リクエストを処理する方法は、RFC 3265[1]に従います。」、「REQ７：スロットルメカニズムは、２つの通知（notifications）間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請（subscription）の持続期間（duration）を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならなず、そして、この状況を回避するためのメカニズムを提供するべきです。」及び「例えば、スロットルは、通知要請（subscription）終了（expiration）値を超えるような通知（notifications）間の最小値をセットすることもできる。そのような配置は、正確に生成される２つの通知（notifications）を、通知者（notifier）は実際に失うことになる。」と記載されている。
　したがって、引用発明において、上記引用例２記載の技術を適用し、イベント通知要求メッセージに、「通知を要求する特定イベント、該特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であって、「前記通知を要求する特定イベント」は、「前記イベント通知要求メッセージのヘッダーに含まれる」ようにすることは、当業者が容易になし得ることである。
　
（６）　むすび
　以上のとおり、本願補正発明は、引用発明、引用例２記載の技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、平成２１年１２月１１日付けの本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　　
第３　本願発明
　上記のとおり、上記本件補正は却下されたので、本願請求項１に係る発明（以下、「本願発明」という。）は、平成２０年１１月５日に提出された手続補正書における特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「クライアントが特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、
　前記有効時間が経過するまでの間における前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、
　を含むことを特徴とするイベント通知方法。」
　
第４　引用例
　原査定の拒絶の理由に引用された引用例１、その記載事項及び引用発明は、前記「第２　（３）（１）」に記載したとおりである。
　
第５　対比
　本願発明と引用発明とを対比する。
（１）引用発明の「通知要請者（subscriber）」は、本願発明の「クライアント」に相当する。
（２）引用発明の「SUBSCRIBE（通知要請）リクエスト」は、本願発明の「イベント通知要求メッセージ」に相当する。
（３）引用発明の「SUBSCRIBE（通知要請）リクエストに」含まれる「希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータ」は、本願発明の「特定イベントの通知周期に関する周期情報」に相当するといえる。
（４）引用発明の「通知者（notifier）」は、本願発明の「サーバ」に対応するといえる。
（５）引用発明の「イベント状態（ステート）資源からイベント状態（ステート）変更を読み出し、それらをイベント通知（notifications）にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知（notifications）を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し」は、本願発明の「特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する」に対応するといえる。
　　
　したがって、本願発明の用語を用いて表現すると両者は、
「クライアントが、特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、
　前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、
　を含むことを特徴とするイベント通知方法。」
で一致するものであり、次の点で相違している。
　
（相違点）
　本願発明は、イベント通知要求メッセージに、「特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であるのに対し、引用発明は、そのような構成は明らかでない点。
　　
第６　判断
　引用例１には、「一般に、通知要請者（subscriber）がSUBSCRIBE（通知要請）リクエストを生成し、NOTIFY（通知）リクエストを処理する方法は、RFC 3265[1]に従います。」、「REQ７：スロットルメカニズムは、２つの通知（notifications）間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請（subscription）の持続期間（duration）を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならなず、そして、この状況を回避するためのメカニズムを提供するべきです。」及び「例えば、スロットルは、通知要請（subscription）終了（expiration）値を超えるような通知（notifications）間の最小値をセットすることもできる。そのような配置は、正確に生成される２つの通知（notifications）を、通知者（notifier）は実際に失うことになる。」と記載されている。　
　また、イベント通知要求メッセージに、特定イベントの発生が通知される有効時間を含むようにし、前記有効時間が経過するまでの間に前記特定イベントの発生を通知することは、本出願の優先日前周知の技術である（例えば、特開２００５−２０６５２号公報段落【００３０】の記載、特開２００４−１２６８６４号公報【００４５】〜【００４８】の記載、原査定において参考文献として引用された「ROCH A B.，Session Initiation Protocol (SIP) Event Notification，RFC 3265，The Internet Engineering Task Force (IFTF)，２００２年６月，ＵＲＬ，http://www.ietf.org/rfc/rfc3265-02.txt」（前記「第２　（３）（２）」「引用例２」）の記載参照。）。
　したがって、引用発明に上記周知技術を適用することより、イベント通知要求メッセージに、特定イベントの発生が通知される有効時間を含ませ、前記有効時間が経過するまでの間に前記特定イベントの発生を通知するようにすることは、当業者が容易になし得ることある。
　　　　
　また、本願発明の作用効果も、引用発明及び周知技術から、当業者であれば予想できる範囲内のものである。
　
第７　結論
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　よって、結論のとおり審決する。