【事件の表示】
　特願２０１５−５２１５２１「プッシュ管理スキーム」拒絶査定不服審判事件〔平成２６年　１月１６日国際公開、ＷＯ２０１４／０１０７６１、平成２７年１０月　８日国内公表、特表２０１５−５２９９９９、請求項の数（１４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１．手続の経緯　
　本願は、平成２４年（２０１２年）７月１０日を国際出願日とする出願であって、平成２７年６月２日付けで拒絶理由が通知され、平成２７年１２月９日付けで手続補正がされ、平成２８年２月２５日付けで拒絶査定がされ、これに対し、平成２８年６月２４日に拒絶査定不服審判が請求されたものである。
第２．本願発明
　本願の請求項１−１４に係る発明は、平成２７年１２月９日付けの手続補正で補正された特許請求の範囲の請求項１−１４に記載された事項により特定されるとおりのもので、その請求項１の記載は以下のとおりである。
「宛先プッシュサーバに関する情報を含む、１つまたは複数のキープアライブメッセージを生成するための要求をモバイル装置からモバイルオペレー
ティングサーバによって受信することと、
　前記キープアライブメッセージを前記モバイルオペレーティングサーバによって生成することと、
　前記キープアライブメッセージを前記モバイルオペレーティングサーバによって前記宛先プッシュサーバへ送信することと、
　を含み、
　前記送信は前記キープアライブメッセージを定期的に前記宛先プッシュ
サーバに送信し、
　前記モバイルオペレーティングサーバは、前記要求に含まれている、前記モバイル装置の識別子に、少なくとも一部は基づいて、前記キープアライブメッセージの発信元を前記モバイル装置に設定し、
　さらに、前記宛先プッシュサーバは、前記設定に基づいて、プッシュデータの宛先を、前記モバイル装置から前記モバイルオペレーティングサーバに変更する必要がない
　方法。」　
（以下、上記事項により特定される発明を「本願発明」という。）
第３．原査定の理由の概要
　原査定の理由の概要は、本願の請求項１−１４に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないというもので、具体的には、本願の請求項１−５、７−１０、１２、及び１３に係る発明は、下記引用文献１及び３に基づいて、本願の請求項６、１１、及び１４に係る発明は、下記引用文献１及び２に基づいて、当業者が容易に発明をすることができたというものである。
１．米国特許出願公開第２００７／００８８７９０号明細書
２．欧州特許出願公開第２２５４３０９号明細書
３．特表２００８−５３６３６９号公報
第４．当審の判断
１．引用発明
　上記引用文献１には、図面とともに、以下の記載がなされている。（以
下、「引用例」という。）
　
（１）「[0046] Referring to  FIG. 3 , the adapted wireless communication network  100  is shown in greater detail  300 . As mentioned earlier, the Web service proxy (or mobile enabler)  112  is modified to include the task scheduler  118  for synchronously polling the Web service  124  via the Web service client  116 , and the notification module  130  for storing subscriber information and corresponding subscription filters. The notification module  130  accepts an initial subscription request message  138  carrying a subscription filter from the mobile device. The notification module adds this to a table indexed against the appropriate device identification (such as a device PIN). The task scheduler uses the time interval or frequency specified in the subscription filter (or a pre-specified interval or frequency) to generate a timer event. On a timer event the service proxy  112  issues a synchronous SOAP request  140  to the Web service  124  and includes the subscription filter in the body of the request message. The business rules module  132  receives the request  140  and validates the received subscription filter against the available content and generates a response message  142  carrying notification data to be sent to the device  102 . If no new information is required to be passed to the user the response message data  142  is empty. For example the Web service  124  can use the XML Schema definition language (XSD) schema element xsd:choice or xsd:option to send back this information. 
[0047] The user is able to create the subscription filter, which defines the notification rules, at the time of initiating the subscription. The filter may include fields such as polling frequency, percentage change in data etc. The polling frequency may also be coded into the Web service by the application developer. An example of a subscription filter may look like Filter:ticker=MSFT, IBM, RIM; daily change=10%
[0048] The task scheduler  118  in the Web service proxy  112  triggers timer events at the predetermined polling frequency and the Web service client module  116  polls the Web service  124 , by sending a Request message  140 , along with the corresponding subscription filter obtained from a specified requesting device  102  at subscription time. The Web service client  116  then receives the Response data  142  from the Web service  124  at the polling frequency and sends a Response  134  to the device if the Response data  142  received from the Web service  124  is not empty. 」
（当審訳
［００４６］　図３には、適応型無線通信ネットワーク１００の、さらなる詳細３００が示されている。上記のように、ウェブ・サービス・プロキシ
（またはモバイル・イネーブラ）１１２は、ウェブ・サービス・クライアント１１６によるウェブ・サービス１２４の同時ポーリングのため、タスク・スケジューラ１１８、及び加入者情報と通信予約フィルタを記憶する通知モジュール１３０を含むように変更される。通知モジュール１３０は、モバイル装置からの予約フィルタを含む、初期予約要求メッセージ１３８を受信する。通知モジュールは、これを、適切な装置識別子（デバイスＰＩＮのような）に対して索引をつけた表に追加する。タスク・スケジューラは、タイ
マ・イベントの発生に、予約フィルタにより特定される時間間隔または周波数（もしくは、あらかじめ決められた時間間隔または周波数）を使用する。タイマ・イベントにより、サービス・プロキシ１１２は、ウェブ・サービス１２４に、同時ＳＯＡＰ要求１４０を送り、要求メッセージ本体に予約フィルタを含める。ビジネス・ルール・モジュール１３２は、要求１４０を受信し、受信した予約フィルタを、入手可能なコンテンツに対して確認し、装置１０２に送る通知データを含む、応答メッセージ１４２を生成する。ユーザに渡す新しい情報がないときは、応答メッセージ・データ１４２は空であ
る。例えば、ウェブ・サービス１２４は、この情報の返信のために、ＸＬＭスキーマ定義言語（ＸＳＤ）のスキーマ・エレメント ＜ｘｓｄ：ｃｈｏｉｃｅ＞または＜ｘｓｄ：ｏｐｔｉｏｎ＞を使用できる。
［００４７］　ユーザは予約の初期段階で予約フィルタを作ることができ、それは、通知ルールを定義する。フィルタは、「ポーリング周波数」、データのパーセントでの変化等のような領域を含む。ポーリング周波数は、アプリケーション開発者により、ウェブ・サービスの中にコード化することもできる。予約フィルタの例は、Ｆｉｌｔｅｒ：＜ｔｉｃｋｅｒ＝ＭＳＦＴ，　ＩＢＭ，　ＲＩＭ；　ｄａｉｌｙ　ｃｈａｎｇｅ＝１０％＞のようにでき
る。
［００４８］　ウェブ・サービス・プロキシ１１２のタスク・スケジューラ１１８は、あらかじめ決められたポーリング周波数でタイマ・イベントをトリガし、そして、予約時に予約を行う装置１０２から得た通信予約フィルタのほかに、要求メッセージ１４０を送ることで、ウェブ・サービス・クライアント・モジュール１１６はウェブ・サービス１２４にポーリングする。それによって、ウェブ・サービス・クライアント１１６は、ウェブ・サービス１２４からポーリング周波数で応答データ１４２を受信して、ウェブ・サービス１２４から受信した応答データ１４２が「空」でなければ、応答１３４を装置に送る。）
（２）「[0049] Referring to  FIG. 4  there is shown a flowchart of operations in accordance with an embodiment. At step  402  a user defines a subscription filter including notification rules; submits the request (step  404 ) to the web service proxy. At step  406  the proxy stores the subscription filter and device address or identification, at step  408  the proxy initializes the task scheduler for polling the web service and at step  410  the task scheduler issues timer events in accordance with the polling frequency set in step  408 . At step  412  the proxy sends requests on the time events to the web service. At step  414  the proxy receives notification data from the Web service and at step  416  it pushes notification results if not empty to the client. At step  418  the proxy waits for a next timer event at which point it resumes at step  410  to issue a new timer event. 」
（当審訳
［００４９］　図４には、実施例の処理のフローチャートが示されている。ステップ４０２で、ユーザは通知規則を含む予約フィルタを定義し、ウェ
ブ・サービス・プロキシに要求を送る（ステップ４０４）。ステップ４０６で、プロキシは予約フィルタと装置アドレスまたは識別子を記憶し、ステップ４０８で、プロキシは、ウェブ・サービスにポーリングするために、タスク・スケジューラを初期化し、ステップ４１０で、タスク・スケジューラ
は、ステップ４０８でセットされたポーリング周波数で、タイマ・イベントを送る。ステップ４１２で、プロキシは、ウェブ・サービスに、タイマ・イベントで要求を送る。ステップ４１４で、プロキシは、ウェブ・サービスから通知データを受信し、ステップ４１６で、空でなければ、通知結果をクライアントにプッシュする。ステップ４１８で、プロキシは、次のタイマイベントを待って、新しいタイマイベントを送るために、再度ステップ４１０から始める。）
　したがって、上記引用文献１には、次の発明（以下、「引用発明」とい
う。）が記載されているといえる。
　ウェブサーバプロキシが、ブッシュ配信するウェブサーバに関する情報を含む、ポーリングメッセージを生成するための要求をモバイル装置から受信すること、該ポーリングメッセージを生成して該ウェブサーバに定期的に送信すること、並びに、該要求に該モバイル装置の識別情報、ポーリング間隔が含まれていること、を特徴とする方法。
２．対比
　引用発明の「ウェブサーバプロキシ」、「ブッシュ配信するウェブサー
バ」、及び「ポーリングメッセージ」は、それぞれ本願発明の「モバイルオペーティングサーバ」、「宛先プッシュサーバ」、及び「キープアライブ
メッセージ」に対応する。
　引用発明は、「ウェブサーバプロキシ」が「ポーリングメッセージ」を
「ウェブサーバに定期的に送信する」ので、本願発明が「前記送信は前記
キープアライブメッセージを定期的に前記宛先プッシュサーバに送信し」とすることと変わりはない。
　したがって、本願発明と引用発明とを対比すると、以下の点で一致し、また相違する。
一致点
　宛先プッシュサーバに関する情報を含む、１つまたは複数のキープアライブメッセージを生成するための要求をモバイル装置からモバイルオペレー
ティングサーバによって受信することと、
　前記キープアライブメッセージを前記モバイルオペレーティングサーバによって生成することと、
　前記キープアライブメッセージを前記モバイルオペレーティングサーバによって前記宛先プッシュサーバへ送信することと、
　を含み、
　前記送信は前記キープアライブメッセージを定期的に前記宛先プッシュ
サーバに送信する、
　方法。
相違点
　本願発明は、「前記モバイルオペレーティングサーバは、前記要求に含まれている、前記モバイル装置の識別子に、少なくとも一部は基づいて、前記キープアライブメッセージの発信元を前記モバイル装置に設定し」とし、それにより「前記宛先プッシュサーバは、前記設定に基づいて、プッシュデータの宛先を、前記モバイル装置から前記モバイルオペレーティングサーバに変更する必要がない」とするものである。
　それに対して、引用発明は、本願発明の「キープアライブメッセージ」に対応する「ポーリングメッセージ」の発信元については、何らの特定もされていない点。
　なお、上記「１．」の引用発明の認定、及び上記一致点と相違点は、平成２７年１２月９日付けの意見書に、
「３　補正後の発明が特許を受けるべきものであることの理由
（１）拒絶理由１及び２について
イ　補正後の本願発明は、宛先プッシュサーバ……
……
 ロ　本願発明と引用文献記載の発明との対比
　引用文献１（米国特許出願公開第２００７／００８８７９０号明細書）には、「ウェブサーバプロキシ（本願の「モバイルオペーティングサーバ」に相当）が、ブッシュ配信するウェブサーバ（本願の「宛先プッシュサーバ」に相当）に関する情報を含む、ポーリングメッセージ（本願の「キープアライブメッセージ」に相当）を生成するための要求をモバイル装置から受信すること、該ポーリングメッセージを生成して該ウェブサーバに定期的に送信すること、並びに、該要求に該モバイル装置の識別情報、ポーリング間隔が含まれていること、が記載されています（引用文献１の主に〔００４７〕段落〜〔００４９〕段落、ＦＩＧ．１〜ＦＩＧ．３参照）。
　しかしながら、引用文献１には、補正後の本願発明の技術的特徴である、“前記送信は前記キープアライブメッセージを定期的に前記宛先プッシュ
サーバに送信し、前記モバイルオペレーティングサーバは、前記要求に含まれている、前記モバイル装置の識別子に、少なくとも一部は基づいて、前記キープアライブメッセージの発信元を前記モバイル装置に設定し、さらに、前記宛先プッシュサーバは、前記設定に基づいて、プッシュデータの宛先
を、前記モバイル装置から前記モバイルオペレーティングサーバに変更する必要がない”が記載されていません。」
と記載されていることに、対立するものではない。
３．判断
　上記相違点について検討する。
　原査定で引用された引用文献３（特表２００８−５３６３６９号公報）には、サーバとクライアント間の通信について、プロキシが、サーバからクライアントにアドレス指定されたメッセージを受信することが記載されているが、クライアントからの要求により、プロキシが発信元をクライアントにしたメッセージを生成して、それをサーバに送信することは、記載も示唆もされていない。
　また、メッセージの発信元を上記のようにすることが、周知技術とはいえないから、引用発明において、相違点を本願発明のようにすることは、当業者が容易にできることとはいえない。
　請求項７に係る発明は、本願発明に対応するシステムに関する発明であ
り、請求項１２に係る発明は、本願発明に対応する記憶媒体に関する発明であり、請求項２−６及び１４は請求項１を引用するものであり、請求項８−１１は請求項７を引用するものであり、請求項１３は請求項１を引用するものであるから、本願の請求項１−１４に係る発明は、前記引用文献１及び３に記載された発明に基づいて当業者が容易に発明をすることができたものとすることはできない。
　さらに、原査定で引用された前記引用文献２にも、クライアントからの要求により、プロキシが発信元をクライアントにしたメッセージを生成して、それをサーバに送信することは、記載も示唆もされていないから、本願の請求項６、１１、及び１４に係る発明は、前記引用文献１及び２に基づいて、当業者が容易に発明をすることができたものとすることはできない。
第５　むすび
　以上のとおり、本願発明は、前記引用文献１−３に記載された発明に基いて、当業者が容易に発明をすることができたものとすることができないか
ら、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。