ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F 審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1257490 |
| 審判番号 | 不服2009-24502 |
| 総通号数 | 151 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2012-07-27 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2009-12-11 |
| 確定日 | 2012-05-23 |
| 事件の表示 | 特願2006- 40828「イベント通知方法、携帯端末機及びサーバ」拒絶査定不服審判事件〔平成18年 9月 7日出願公開、特開2006-236346〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続きの経緯 本願は、平成18年2月17日(優先権主張2005年2月25日、韓国)の出願であって、平成20年7月24日付けで拒絶理由が通知され、同年11月5日付けで手続補正がなされたが、平成21年8月3日付けで拒絶査定がなされ、これに対し、同年12月11日付けで拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。 第2 平成21年12月11日付けの手続補正の補正却下の決定 [補正却下の決定の結論] 平成21年12月11日付けの手続補正(以下、「本件補正」という。)を却下する。 [理由] (1)補正の内容 本件補正により、少なくとも特許請求の範囲の請求項1は、 「クライアントが、通知を要求する特定イベント、該特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、 前記有効時間が経過するまでの間における前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、 を含み、 前記通知を要求する特定イベント及び前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれることを特徴とするイベント通知方法。」と補正された。 (2)補正の適否について 上記補正は、本件補正前の請求項1に記載した発明を特定するために必要な事項である「特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージ」について「通知を要求する特定イベント」「を含む」及び「前記通知を要求する特定イベント及び前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれる」とするものであり、本件補正は、特許法第17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件補正後の請求項1に記載された発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか、すなわち平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するかどうかについて以下に検討する。 (3)引用文献 (1)原査定の拒絶の理由に引用された「NIEMI A.,Session Initiation Protocol (SIP) Event Notification Throttle Mechanism,Internet-Draft draft-niemi-sipping-event-throttle-02.txt,2005年2月21日,URL,http://tools.ietf.org/id/draft-niemi-sipping-event-throttle-02.txt」(以下、「引用例1」という。)には、図面とともに次の記載がある。 (ア)「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.」(第3/15頁第1行?第12行) (当審訳: 1.イントロダクション SIPイベントフレームワーク[1]は、SIPシステムと関係するイベントの通知要請(subscriptions)およびイベントの通知(notifications)の総括的なフレームワークを定義します。このフレームワークはメソッドSUBSUCRIBEおよびNOTIFYを定義し、特別のクラスのイベントに対するSIPイベントフレームワークの具体的なアプリケーションであるイベントパッケージの概念を導入します。 SIPイベントフレームワークが命ずるもののうちの1つは、イベントパッケージ記述が、一つの通知者(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. 」(第4/15頁第6行?第27行) (当審訳: 3.1.1 プリコンディション Liｓaのモバイル装置のプレゼンスアプリケーションは、仲間または出席者のリストを含んでいます。100人の出席者を見る処理およびネットワーク負荷を減少させるために、Liｓaのプレゼンスアプリケーションは、各イベント通知要請(subscriptions)にイベントスロットルを含んでいて、それはイベント通知(notifications)が20秒につき一度生成される最高割合に制限しています。 HeikkiはLiｓaが見ている出席者のうちの1つです。HeikkiのプレゼンスエージェントはLiｓaのプレゼンスアプリケーションによって要求された、制限ポリシーに従います。イベントパッケージはフルステートのイベント通知だけを含んでいます。 3.1.2 ノーマルフロー Heikkiは、Liｓaに送られるプレゼンス通知となる“赤”のプレゼンスステータスを発行します。 10秒後、Heikkiは、“青”のプレゼンスステータスを発行します。Liｓaによってセットされたスロットリングポリシーは、プレゼンスエージェントが最大で20秒毎に通知を発生することのみ可能にするとともに、該通知を保持状態にします。 さらに10秒後、該通知がLiｓaに送られることが許可されます。 Liｓaは、セットされたスロットリングポリシーに応じる最新のプレゼンスを受け取ります。) (ウ)「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.」 (第6/15頁第16行?第7/15頁第10行) (当審訳: 3.2 必要条件(Requirements) REQ1:通知要請者(subscriber)は、スロットルメカニズムで使用する特定の通知要請(subscription)において2つの通知(notifications)間の最小の期間をセットすることができなければなりません。 REQ2:通知要請者(subscriber)は、特定の通知要請(subscription)で示されたスロットリングポリシーに応じるように通知者(notifier)に要求することを示さなければなりません。 REQ3:通知者(notifier)は、通知要請(subscription)のスロットルメカニズムの使用をサポートしないことを示すことができなければならない。 REQ4:すべてのイベントの通知要請(subscription)においてスロットルメカニズムを使用することが可能でなければなりません。 REQ5:任意のイベントフィルタリングメカニズムと一緒にスロットルメカニズムを使用することが可能でなければなりません。 REQ6:通知者は、2つの通知(notifications)間の最小の期間が通知要請者(subscriber)から与えられたものより長い、スロットリングポリシーを使用することが許されなければなりません。 例えば、混雑しているという理由により、通知者(notifier)のローカルポリシーは、通知要請者(subscriber)が形成した2つの通知(notifications)間の最小の期間を増加するようにスロットリングポリシーを一時的に指示することができる。 REQ7:スロットルメカニズムは、2つの通知(notifications)間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請(subscription)の持続期間(duration)を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならず、そして、この状況を回避するためのメカニズムを提供するべきです。 REQ8:スロットルメカニズムは、メカニズムを起動する通知要請(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.」(第7/15頁第13行?第21行) (当審訳: 3.3 イベント スロットル モデル 通知者(notifier)は、通知要請された資源の状態(ステート)の変更によりイベント通知(notifications)を送る能力があります。私たちは3つのコンポーネントから成るとして通知者(notifier)をモデル化することができます:図5に示されるように、イベント状態(ステート)資源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.」(第8/15頁第4行?第10行) (当審訳: 3.4 基本オペレーション 特定の通知要請(subscription)においてイベント通知(notifications)の割合を制限したい通知要請者(subscriber)は、SUBSCRIBE(通知要請)メッセージの一部にスロットルを示すことにより行います。通知要請(subscription)における連続した2つの通知(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.」(第9/15頁第3行?第22行) (当審訳: 4.2.1 通知要請者(Subscriber)の振る舞い 一般に、通知要請者(subscriber)がSUBSCRIBE(通知要請)リクエストを生成し、NOTIFY(通知)リクエストを処理する方法は、RFC 3265[1]に従います。 通知要請(subscription)において通知を調節したい通知要請者(subscriber)は、SUBSCRIBE(通知要請)リクエストに希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータを含めます。このパラメータの値は秒で10進の整数です。 通知者(notifier)が拡張“イベントスロットル”をサポートしない場合、通知要請者(subscriber)は、拡張プレゼントスロットルなしで通知要請(subscription)を再び試みなければなりません、もし、それが通知要請者(subscriber)の過度の負担でなければ。 この場合、通知要請者(subscriber)は通知割合を制限する他の手段に頼ることができます。例えば、通知要請(subscription)の代わりに、それはイベント状態(ステート)を取って来るか獲得することができます。 スロットルメカニズムを適用する場合、通知要請者(subscriber)には、2つの主な結果があります:状態(ステート)推移が失われること、及びイベント通知が遅れることです。これらの副次的作用のどちらかによってイベントスロットルを利用するアプリケーションに問題が生じる場合、開発者はメカニズムを使用しないように命じられます。 ) (キ)「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.」(第9/15頁第23行?第10/15頁第13行) (当審訳: 4.2.2 通知者(Notifier)の振る舞い 一般に、通知者(notifier)がSUBSCRIBE(通知要請)リクエストを処理し、NOTIFY(通知)リクエストを発生する方法は、RFC 3265[1]によるものです。 拡張“イベントスロットル”をサポートする通知者(notifier)は、イベントヘッダパラメータ“throtlle”の値を抽出し、2つの通知(notifications)間に許可した最小の時間として、それを使用します。 それに応じる通知者(notifier)は、SUBSCRIBE(通知要請)リクエスト(最初の通知)の受取あるいは通知要請(subscription)終了(通知の終わり)のいずれかの通知を生成するとき以外は、スロットルが許可するより頻繁な通知を生成してはいけません。そのような通知は、たとえそれに従う必要がなくてもスロットル・タイマーをリセットします。 NOTIFY(通知)リクエストの再伝送はスロットルによって影響されません、つまり、スロットルは、新しい処理の生成にのみ適用されます。言いかえれば、前の処理が終わった後にだけ、スロットルはリセットされます。 4.3 スロットル間隔の選択 スロットル値を選択する場合、特別の注意を払う必要があります。スロットルシンタックスを使用して、非常に短いスロットルと非常に長いスロトッルの両方を通知要請(subscription)に適用することが可能です。例えば、スロットルは、通知要請(subscription)終了(expiration)値を超えるような通知(notifications)間の最小値をセットすることもできます。そのような配置は、正確に生成される2つの通知(notifications)を、通知者(notifier)は実際に失うことになります。) 以上の記載によれば、この引用例1には以下のような発明(以下、「引用発明」という。)が開示されていると認められる。 「通知要請者(subscriber)がSUBSCRIBE(通知要請)リクエストを生成し、通知者(notifier)がSUBSCRIBE(通知要請)リクエストを処理し、通知要請された資源の状態(ステート)の変更によりイベント通知(notifications)を発生し、イベント通知(notifications)を通知要請者(subscriber)に送る方法であって、 通知を調節したい通知要請者(subscriber)は、SUBSCRIBE(通知要請)リクエストに希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータを含め、 通知者(notifier)は、イベント状態(ステート)資源からイベント状態(ステート)変更を読み出し、それらをイベント通知(notifications)にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知(notifications)を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し、 通知者(notifier)が通知要請者(subscriber)に送る通知(notifications)間に許可する最小の時間を通知要請者(subscriber)がコントロールすることを特徴とするイベント通知方法。」 (2)原査定において参考文献として引用された「ROCH A B.,Session Initiation Protocol (SIP) Event Notification,RFC 3265,The Internet Engineering Task Force (IFTF),2002年6月,URL,http://www.ietf.org/rfc/rfc3265-02.txt」(以下、「引用例2」という。)には、図面とともに次の記載がある。 (ア)「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.」(第5/32頁第11行?第29行) (当審訳: 3.1.1. 通知要請(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.」(第5/32頁第30行?第6/32頁第24行) (当審訳: 3.1.2. 通知要請されたイベントとイベントクラスの識別 イベントの識別は情報の3つの部分によって提供されます:リクエストURI、イベントタイプおよび(選択的な)メッセージ本体です。 SUBSCRIBE(通知要請)リクエストのリクエストURIは、最も重要なことに、SIP[1]で概説されたリクエストルーティング手続きで適切なエンテティへリクエストを送るために十分な情報を含んでいます。さらに、それは望まれるイベント通知の資源を識別するのに十分な情報を含んでいますが、イベントの性質を唯一に識別するのに必ずしも十分な情報ではありません(例えば、「sip:adam@dynamicsoft.com」は、私のプレゼンスステートを通知要請するのに適切なURIになるでしょう;さらに私のボイスメールボックスのステートを通知要請するのに適切なURIになるでしょう。)。 通知要請者(subscriber)は、通知要請しているイベントあるいはイベントのクラスを示すために、SUBSCRIBE(通知要請)リクエスト中に“Event”ヘッダを含ませなければならない。“Event”ヘッダは、要求されているサブスクリプションのステートのタイプを示すトークンを含むでしょう。このトークンはIANAで登録され、イベントまたはイベントのクラスのセマンティクス(判断基準)についてさらに記述するイベントパッケージに対応するでしょう。“Event”ヘッダはさらに“id”パラメータを含んでいるかもしれません。 この“id”パラメータが存在する場合、ダイアログ内の特定のサブスクリプションを識別する不透明なトークンを含んでいます。“id”パラメータは、1つのダイアログの範囲内でのみ有効です。 イベントトークンに対応するイベントパッケージがその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.」(第8/32頁第29行?第9/32頁第20行) (当審訳: 3.1.6.1. 初期通知要請トランザクション処理 決して、SUBSCRIBE(通知要請)トランザクションは自動処理に必要な時間を越えて伸ばすべきではありません。特に、通知者は、SUBSCRIBE(通知要請)リクエストに対する最後のレスポンスを返す前にユーザレスポンスを待ってはいけません。 ・・・(中略)・・・ 通知者(notifier)は、“Event”ヘッダ中に指定されたイベントパッケージが理解されることをチェックするべきです。そうでなければ、通知者(notifier)は、指定されたイベント/イベントクラスが理解されないことを示すために“489 Bad Event”レスポンスを返すべきです。 通知者(notifier)は、さらに自身のローカルポリシー毎に、必要であるどのような認証および認可も行なうべきです。セクション3.1.6.3を参照してください。 通知者(notifier)はさらに “Expires”ヘッダ中のduration(持続)が小さすぎないことチェックするかもしれません。expiration(終了)間隔がゼロより大きく1時間より小さく、通知者(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”パラメータ(もし、あれば)を格納します。) (4) 対 比 本願補正発明と引用発明とを対比する。 (1)引用発明の「通知要請者(subscriber)」は、本願補正発明の「クライアント」に相当する。 (2)引用発明の「SUBSCRIBE(通知要請)リクエスト」は、本願補正発明の「イベント通知要求メッセージ」に相当する。 (3)引用発明の「SUBSCRIBE(通知要請)リクエストに」含まれる「希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータ」は、本願補正発明の「特定イベントの通知周期に関する周期情報」に相当し、本願補正発明の「前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれる」に対応するといえる。 (4)引用発明の「通知者(notifier)」は、本願補正発明の「サーバ」に対応するといえる。 (5)引用発明の「イベント状態(ステート)資源からイベント状態(ステート)変更を読み出し、それらをイベント通知(notifications)にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知(notifications)を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し」は、本願補正発明の「特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する」に対応するといえる。 したがって、本願補正発明の用語を用いて表現すると両者は、 「クライアントが、特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、 前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、 を含み、 前記周期情報は、前記イベント通知要求メッセージのヘッダーに含まれることを特徴とするイベント通知方法。」 で一致するものであり、次の点で相違している。 (相違点) 本願補正発明は、イベント通知要求メッセージに、「通知を要求する特定イベント、該特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であって、「前記通知を要求する特定イベント」は、「前記イベント通知要求メッセージのヘッダーに含まれる」のに対し、引用発明は、そのような構成は明らかでない点。 (5)判断 上記相違点について検討する。 引用例2には、「通知要請者(subscriber)は、通知要請しているイベントあるいはイベントのクラスを示すために、SUBSCRIBE(通知要請)リクエスト中に“Event”ヘッダを含ませなければならない。」及び「SUBSCRIBE(通知要請)リクエストは"Expires"ヘッダ(SIP[1]の中で定義された)を含むべきです。この終了(expires)値は、通知要請(Subscription)の持続期間(duration)を示します。」と記載されている。 そして、引用例1には、「一般に、通知要請者(subscriber)がSUBSCRIBE(通知要請)リクエストを生成し、NOTIFY(通知)リクエストを処理する方法は、RFC 3265[1]に従います。」、「REQ7:スロットルメカニズムは、2つの通知(notifications)間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請(subscription)の持続期間(duration)を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならなず、そして、この状況を回避するためのメカニズムを提供するべきです。」及び「例えば、スロットルは、通知要請(subscription)終了(expiration)値を超えるような通知(notifications)間の最小値をセットすることもできる。そのような配置は、正確に生成される2つの通知(notifications)を、通知者(notifier)は実際に失うことになる。」と記載されている。 したがって、引用発明において、上記引用例2記載の技術を適用し、イベント通知要求メッセージに、「通知を要求する特定イベント、該特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であって、「前記通知を要求する特定イベント」は、「前記イベント通知要求メッセージのヘッダーに含まれる」ようにすることは、当業者が容易になし得ることである。 (6) むすび 以上のとおり、本願補正発明は、引用発明、引用例2記載の技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、平成21年12月11日付けの本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3 本願発明 上記のとおり、上記本件補正は却下されたので、本願請求項1に係る発明(以下、「本願発明」という。)は、平成20年11月5日に提出された手続補正書における特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。 「クライアントが特定イベントの発生が通知される有効時間及び前記特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、 前記有効時間が経過するまでの間における前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、 を含むことを特徴とするイベント通知方法。」 第4 引用例 原査定の拒絶の理由に引用された引用例1、その記載事項及び引用発明は、前記「第2 (3)(1)」に記載したとおりである。 第5 対比 本願発明と引用発明とを対比する。 (1)引用発明の「通知要請者(subscriber)」は、本願発明の「クライアント」に相当する。 (2)引用発明の「SUBSCRIBE(通知要請)リクエスト」は、本願発明の「イベント通知要求メッセージ」に相当する。 (3)引用発明の「SUBSCRIBE(通知要請)リクエストに」含まれる「希望のスロットル値を秒で示している“throttle”イベントヘッダパラメータ」は、本願発明の「特定イベントの通知周期に関する周期情報」に相当するといえる。 (4)引用発明の「通知者(notifier)」は、本願発明の「サーバ」に対応するといえる。 (5)引用発明の「イベント状態(ステート)資源からイベント状態(ステート)変更を読み出し、それらをイベント通知(notifications)にパッケージし、出力バッファーへ提出し、出力バッファーがイベント通知(notifications)を出力する割合として“throtlle”イベントヘッダパラメータの値を抽出して使用し」は、本願発明の「特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する」に対応するといえる。 したがって、本願発明の用語を用いて表現すると両者は、 「クライアントが、特定イベントの通知周期に関する周期情報を含むイベント通知要求メッセージをサーバに転送する過程と、 前記特定イベントの発生時に前記周期情報が満たされていると、前記サーバが前記クライアントに前記特定イベントの発生を通知する過程と、 を含むことを特徴とするイベント通知方法。」 で一致するものであり、次の点で相違している。 (相違点) 本願発明は、イベント通知要求メッセージに、「特定イベントの発生が通知される有効時間」「を含」み、前記特定イベントの発生を通知するのが、「前記有効時間が経過するまでの間」であるのに対し、引用発明は、そのような構成は明らかでない点。 第6 判断 引用例1には、「一般に、通知要請者(subscriber)がSUBSCRIBE(通知要請)リクエストを生成し、NOTIFY(通知)リクエストを処理する方法は、RFC 3265[1]に従います。」、「REQ7:スロットルメカニズムは、2つの通知(notifications)間の最小の期間のセッテイングのために合理的なリゾルーションを提供しなければならない。最低限、スロットルメカニズムは、通知要請(subscription)の持続期間(duration)を超過する最小の期間に起因する状況を確かめる調査を含んでいなければならなず、そして、この状況を回避するためのメカニズムを提供するべきです。」及び「例えば、スロットルは、通知要請(subscription)終了(expiration)値を超えるような通知(notifications)間の最小値をセットすることもできる。そのような配置は、正確に生成される2つの通知(notifications)を、通知者(notifier)は実際に失うことになる。」と記載されている。 また、イベント通知要求メッセージに、特定イベントの発生が通知される有効時間を含むようにし、前記有効時間が経過するまでの間に前記特定イベントの発生を通知することは、本出願の優先日前周知の技術である(例えば、特開2005-20652号公報段落【0030】の記載、特開2004-126864号公報【0045】?【0048】の記載、原査定において参考文献として引用された「ROCH A B.,Session Initiation Protocol (SIP) Event Notification,RFC 3265,The Internet Engineering Task Force (IFTF),2002年6月,URL,http://www.ietf.org/rfc/rfc3265-02.txt」(前記「第2 (3)(2)」「引用例2」)の記載参照。)。 したがって、引用発明に上記周知技術を適用することより、イベント通知要求メッセージに、特定イベントの発生が通知される有効時間を含ませ、前記有効時間が経過するまでの間に前記特定イベントの発生を通知するようにすることは、当業者が容易になし得ることある。 また、本願発明の作用効果も、引用発明及び周知技術から、当業者であれば予想できる範囲内のものである。 第7 結論 以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない。 したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2011-12-21 |
| 結審通知日 | 2011-12-27 |
| 審決日 | 2012-01-10 |
| 出願番号 | 特願2006-40828(P2006-40828) |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
P 1 8・ 575- Z (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 寺谷 大亮 |
| 特許庁審判長 |
和田 志郎 |
| 特許庁審判官 |
安島 智也 安久 司郎 |
| 発明の名称 | イベント通知方法、携帯端末機及びサーバ |
| 代理人 | 笹島 富二雄 |