【事件の表示】
　特願２０１１−１３３１８５「トリガー・イベント処理」拒絶査定不服審判事件〔平成２３年１２月　８日出願公開、特開２０１１−２５０４２１、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願発明
　
　本願は、２００３年１２月１９日（パリ条約による優先権主張外国庁受理　２００２年１２月１９日　米国，２００３年１２月１８日　米国）を国際出願日とする出願である特願２００４−５６２３６３号の一部を、平成２３年６月１５日に新たな特許出願としたものであって、平成２５年３月２２日付けで拒絶査定がなされ、これに対して同年７月２６日に拒絶査定に対する審判請求がなされたものである。
　本願の請求項１〜１５に係る発明（以下、「本願発明１」乃至「本願発明１５」という。）は、平成２３年７月１５日付け手続補正書の特許請求の範囲の請求項１〜１５に記載された、次のとおりのものと認める。
　
　「【請求項１】
　情報と関連したトリガー・イベントを処理する方法であって、
　前記情報と関連したトリガー・イベント・パラメータを受信する手段によって受信すること、
　前記情報と関連したエクストラ・データを受信する手段によって受信すること、
　前記トリガー・イベント・パラメータを監視する手段によって監視すること、
　前記トリガー・イベントが起こるかどうかを決定するために前記トリガー・イベント・パラメータを評価する手段によって評価すること、
　前記トリガー・イベント・パラメータが監視されかつ評価されることに基づいて前記トリガー・イベントが起こる場合に、前記エクストラ・データを処理する手段によって処理すること、
　前記エクストラ・データを処理した後で、前記トリガー・イベントを処理する手段によって処理すること
を含み、
　前記トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されかつチェックされる、方法。
【請求項２】
　前記トリガー・イベントと関連した前記エクストラ・データを記憶するステップをさらに含む請求項1の方法。
【請求項３】
　前記エクストラ・データがユニフォームリソースロケータ(ＵＲＬ)である請求項１の方法。
【請求項４】
　前記トリガー・イベント・パラメータは前記情報の有効期限であり、前記トリガー・イベントは前記情報の期限切れである請求項1の方法。
【請求項５】
　前記エクストラ・データが変更され、前記エクストラ・データを処理するステップが前記変更されたエクストラ・データを処理することを含む請求項1の方法。
【請求項６】
　前記トリガー・イベントが無線装置内で起こり、前記エクストラ・データを処理するステップが無線ネットワークに接続することを含む請求項1の方法。
【請求項７】
　前記トリガー・イベントの処理を実行するステップをさらに含む請求項1の方法。
【請求項８】
　前記トリガー・イベント処理が前記トリガー・イベントと関連した前記情報とは独立の処理を含む請求項7の方法。
【請求項９】
　アプリケーションのための期限切れ処理の方法であって、
　前記期限切れパラメータ、スクリプトを含むＵＲＬ、および無線装置におけるアプリケーションを受信する手段によって受信すること、
　前記アプリケーションが期限切れになったかどうかを前記期限切れパラメータに基づいて決定するために前記無線装置を監視する手段によって監視すること、
　前記ＵＲＬを処理する手段によって処理すること、
　前記ＵＲＬを処理した後で、前記アプリケーションの期限切れを処理する手段によって処理すること
を含み、
　前記アプリケーションの期限切れを処理する前に、前記ＵＲＬが待ち行列に置かれ、前記ＵＲＬが特定のハンドラを持つかどうかを見るために、前記ＵＲＬが前記待ち行列から検索されチェックされる、方法。
【請求項１０】
　前記ＵＲＬを処理することが前記無線装置と局所的に関連した機能を実行することを含む請求項９の方法。
【請求項１１】
　前記ＵＲＬを処理することが前記無線装置に遠隔システムと関連した機能を実行することを含む請求項9の方法。
【請求項１２】
　情報およびエクストラ・データと関連したトリガー・イベントを処理する無線装置であって、
　前記無線装置は、トリガー・イベント・パラメータを監視するための監視論理回路と、前記トリガー・イベント・パラメータを評価するための評価論理回路を含み、トリガー・イベントが起こるとエクストラ・データを処理し、そして、前記エクストラ・データを処理した後で、前記トリガー・イベントを処理するようになされており、
　前記トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列内に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために、前記エクストラ・データが前記待ち行列から検索されチェックされる、無線装置。
【請求項１３】
　前記エクストラ・データを処理するとき、前記無線装置が無線ネットワークへの接続を開始する請求項１２の無線装置。
【請求項１４】
　実行されるとき情報と関連したトリガー・イベントを処理するための方法を実行するコンピュータ命令を含むコンピュータ読み出し可能な媒体であって、前記方法は、
　前記情報と関連した前記トリガー・イベント・パラメータを受信するステップと、
　前記情報と関連したエクストラ・データを受信するステップと、
　前記トリガー・イベント・パラメータを監視するステップと、
　前記トリガー・イベントが起こるかどうかを決定するために前記トリガー・イベント・パラメータを評価するステップと、
　前記トリガー・イベント・パラメータが監視され評価されることに基づいて前記トリガー・イベントが起こる場合に、前記エクストラ・データを処理するステップと、
　前記エクストラ・イベントを処理した後で前記トリガー・イベントを処理するステップと
を含み、
　前記トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが検索されチェックされる、コンピュータ読み出し可能な媒体。
【請求項１５】
　情報と関連したトリガー・イベントを処理するために使用される装置であって、
　前記情報と関連したトリガー・イベント・パラメータを受信する手段と、
　前記情報と関連したエクストラ・データを受信する手段と、
　前記トリガー・イベント・パラメータを監視する手段と、
　前記トリガー・イベントが起こるかどうかを決定するために前記トリガー・イベント・パラメータを評価する手段と、
　前記トリガー・イベント・パラメータが監視され評価されることに基づいて前記トリガー・イベントが起こる場合に、前記エクストラ・データを処理する手段と、
　前記エクストラ・データを処理した後で前記トリガー・イベントを処理する手段と
を含み、
　前記トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されチェックされる、装置。」
　
　
２．原査定の理由の概要
　
「この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
請求項１〜１５について／引用文献１〜４
備考：
　引用文献１には、アプリケーション・プログラムのライセンス期間（本願発明の「トリガー・イベント・パラメータ」に対応。）を現在日時と比較して、期限切れ（本願発明の「トリガー・イベント」に対応。）と判断した場合に、認証サーバのＵＲＬ（本願発明の「エクストラ・データ」に対応。）を受信し、受信したＵＲＬを用いて認証サーバにアクセスした後（本願発明の「エクストラ・データを処理した後」に対応。）に、プログラム使用許諾期間を更新する（本願発明の「トリガー・イベントを処理する」に対応。）、プログラム使用許諾期間の更新方法に係る発明が開示されている。（段落００３８〜００５１を参照。）
　引用文献１に開示された発明と本願発明とを対比すると、本願発明では、エクストラ・データの特定のハンドラの構成を備えているのに対して、引用文献１に開示された発明では、そのような構成を備えていない点で相違し（以下、「相違点１」という。）、本願発明では、エクストラ・データが待ち行列に置かれる構成を備えているのに対して、引用文献１に開示された発明では、そのような構成を備えていない点で相違する（以下、「相違点２」という。）。
　相違点１について検討すると、引用文献２の段落００２５には、ＵＲＬが特定のハンドラを持つことが開示されており、エクストラ・データの特定のハンドラは、本願出願前に公知の事項と認められる。してみると、引用文献１に開示された発明において、エクストラ・データの特定のハンドラを備える構成とすることは、当業者であれば容易に想到し得たことである。
　相違点２について検討すると、処理すべきデータを待ち行列に置く技術は、例えば、引用文献３の段落０００３、０００４や、引用文献４の第２頁左下欄第１９行〜右下欄第１２行に開示されているように、本願出願前において周知慣用技術であると認められる。してみると、引用文献１に開示された発明において、当該周知慣用技術を適用して、ＵＲＬを待ち行列に置く構成とすることは、当業者であれば容易に想到し得たことである。
拒絶の理由が新たに発見された場合には拒絶の理由が通知される。
　　　　　　　　　　　引　用　文　献　等　一　覧
１.特開２００２−２５９６０６号公報
２.特開平９−２６５４０８号公報
３.特開平１０−１８７４６６号公報
４.特開平３−０８５６４１号公報」
　
　
３．当審の判断
　　
（１）引用例
　
１）第１引用例　
　
　原査定の拒絶理由で引用された特開２００２−２５９６０６号公報（以下「第１引用例」という。）には、以下の事項が記載されている。　
　　
（ａ）
「【０００１】
【発明の属する技術分野】本発明は、プログラムの使用許諾期間（ライセンス期間）の更新方法、情報処理システムおよびプログラムに関する。特に、ライセンス期間が満了した場合のライセンス更新を簡略化し、ユーザに煩雑な手続を強いることのないライセンス更新に適用して有効な技術に関する。」（３頁３欄２０−２６行）
　
（ｂ）
「【００２２】図２は、本実施の形態のライセンス期間更新の概要について時系列に示した図である。時刻ｔ０でユーザがアプリケーション・プログラムをダウンロードする場合を考える（ステップ１０）。なお、ユーザはこの時点でプログラム提供者の管理するグループ（会）の会員であるとする。ダウンロードの時からアプリケーション・プログラムのライセンス期間が開始し、ライセンスは時刻ｔ０〜ｔ２の間で有効であるとする。この期間（ｔ０〜ｔ２）は、プログラムをインストールする際に同意したライセンス期間となる。時刻ｔ１でユーザがアプリケーション・プログラムを起動した時、ライセンスは有効であるためアプリケーション・プログラムが実行できる（ステップ１１）。」（５頁７欄１７−２９行）
　
（ｃ）
「【００３７】図４は、本実施の形態のライセンス期間の更新方法の一例を示したフローチャートである。ステップ５０のアプリケーション・プログラムの起動から説明を開始する。
【００３８】アプリケーション・プログラムが起動されると、プログラムはライセンス期間と現在日時を取得し（ステップ５１）、現在日時がライセンス期間内であるかを判断する（ステップ５２）。ライセンス期間である場合は、ステップ７２に進んでアプリケーション・プログラムを実行する（ステップ７２）。この場合、ライセンスは有効なので本実施の形態の会員認証は行われず、速やかにアプリケーション・プログラムが実行される。」（６頁１０欄１０〜２１行）
　
（ｄ）
「【００３９】ライセンス期間外である場合、ライセンスは現在無効であるため、会員認証モジュール２２を起動する（ステップ５３）。会員認証モジュールが起動されると、モジュールはインデックス・ファイル取得要求をインデックス・サーバ３に対して発する（ステップ５４）。
【００４０】インデックス・サーバ３は、ユーザからのこの要求を受取り（ステップ５５）、この要求受信を契機としてインデックス・ファイルの選択または生成を行う（ステップ５６）。インデックス・ファイルの選択または生成にはインデックス３２を参照する。インデックス・サーバはこの段階でインデックス・ファイルを暗号化しても良い。暗号化は予め行い、インデックス３２に暗号化インデックス・ファイルを記録しておくことが好ましい。その後、インデックス・サーバ３は暗号化されたインデックス・ファイルをクライアント２に送信する（ステップ５７）。
【００４１】インデックス・ファイルには前記したように認証サーバ４のＵＲＬを含む。このようにユーザはインデックス・サーバ３を参照して認証サーバ４のＵＲＬを取得するので、認証サーバ４のＵＲＬを認証サーバ４によって公開する必要がない。また、クライアント２は本実施の形態の会員認証モジュールを用いる限りインデックス・サーバ３にアクセスすれば、常に最新の認証サーバ４のＵＲＬが取得できる。このため、認証サーバ４のＵＲＬに変更があってもユーザは無関心でよい。また、認証サーバ側ではＵＲＬを変更してもインデックス・サーバ３のインデックス・ファイルを変更するだけでよく、各ユーザへの周知あるいは連絡の必要がない。」（６頁１０欄２２〜５０行）
　
（ｅ）
「【００４３】図５はインデックス・サーバ３が送信するインデックス・ファイルの一例を示す図である。本ファイルはＸＭＬ（extensible markup language）で記述されている。ここでは「url」タグで囲まれた部分に認証サーバ４のＵＲＬが暗号化されて記述されている。また、「information」タグで囲まれた部分には、「frequency」タグで囲まれているライセンス期間、「requirement」タグで囲まれたプログラム使用条件に関するテキストが記述されている。
【００４４】次に、クライアント２が暗号化されたインデックス・ファイルを受信すると（ステップ５８）、この暗号を復号化し平文のインデックス・ファイルを得る（ステップ５９）。図６は復号化した後のインデックス・ファイルの一例を示す。図５と比較して「url」タグで囲まれた部分が意味のある平文になっている。」（７頁１１欄７〜２１行）
　
（ｆ）　
「【００４９】次に、クライアント２は、認証サーバ４に認証の取得要求を発する（ステップ６２）。取得要求には前記ステップで取得したＵＩＤ／ＰＷＤ等の認証データを含める。」（７頁１１欄４７〜５０行）
　
（ｇ）
「【００５０】次に、認証サーバ４がクライアント２からの認証要求を受取り、同時に認証データを受取る（ステップ６３）。認証サーバ４は、クライアントからの要求を契機として、会員データベース４４を検索し（ステップ６４）、認証要求の会員の資格が有効であるかを判断する（ステップ６５）。会員資格が有効である時には、認証成功の「ReturnValue」を生成し（ステップ６６）、会員資格が無効の場合には認証失敗の「ReturnValue」を生成する（ステップ６７）。そしてこの「ReturnValue」を認証結果としてクライアント２に送信する。
【００５１】クライアント２は、「ReturnValue」を受信し（ステップ６９）、「ReturnValue」が認証成功であるかを判断する（ステップ７０）。認証成功の場合、ライセンス期間を新たなライセンス期間に更新し（ステップ７１）、アプリケーション・プログラムを実行する（ステップ７２）。その後処理を終了する（ステップ７３）。認証失敗の場合はライセンス期間を更新することなく、また、アプリケーション・プログラムを実行することなく終了する（ステップ７３）。」（７頁１２欄１−１９行）
　
　
　上記第１引用例の記載及び図面並びにこの分野の技術常識を考慮すると、
　
　上記（ａ）によれば、第１引用例はアプリケーション・プログラムと関連したライセンス期間の更新方法に関するものである。
　
　上記（ｂ）によれば、アプリケーション・プログラムがダウンロードされインストールする際にライセンス期間の同意を行っており、「ライセンス期間」もアプリケーション・プログラムと同時にダウンロードされるものといえる。
　
　上記（ｃ）によれば、アプリケーション・プログラムは「現在日時」と「ライセンス期間」を取得し、「ライセンス期間」が満了しているか判断している。
　
　上記（ｄ）、（ｅ）によれば、ライセンス期間が満了すると「インデックス・サーバ３」に対して「インデックス・ファイル取得要求」を発せられ、「認証サーバ４のＵＲＬ」を含む「インデックス・ファイル」がクライアント側に送信されおり、クライアントはアプリケーション・プログラムと関連した認証サーバのＵＲＬを含むインデックス・ファイルを受信している。
　
　上記（ｆ）、図４によれば、ライセンス期間が満了した際に認証サーバに認証要求を行っており、前記「インデックス・ファイル」の認証サーバのＵＲＬを基に認証サーバに接続されるものであるから、ライセンス期間の満了の際に、認証サーバのＵＲＬを基に認証サーバに接続されるものである。
　
　上記（ｇ）によれば、アプリケーション・プログラムは認証サーバからの「ReturnValue」を基にライセンス期間の更新を行っており、認証サーバに接続した後に、ライセンス期間の更新の処理をするものである。
　　
　上記第１引用例の記載事項及び図面を総合勘案すると、第１引用例には、結局、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
　
「アプリケーション・プログラムと関連したライセンス期間の更新方法であって、
　前記アプリケーション・プログラムと関連したライセンス期間をダウンロードし、
　前記アプリケーション・プログラムと関連した認証サーバのＵＲＬを含むインデックス・ファイルを受信し、
　前記ライセンス期間と現在日時を取得し、
　前記ライセンス期間と前記現在日時を基にライセンス期間の満了を判断し、
　前記ライセンス期間の満了の際に、前記インデックス・ファイルの前記認証サーバのＵＲＬを基に前記認証サーバに接続し、
　前記認証サーバに接続した後に、ライセンス期間の更新の処理をする、
　方法。」
　　
２）第２引用例
　
　同じく原査定の拒絶理由で引用された特開平９−２６５４０８号公報（以下「第２引用例」という。）には、以下の事項が記載されている。
　
（ｈ）
「【００２３】ワークフロー・クーリエ
図４を参照すると、本発明のワークフロー・クーリエ書類１１８のデータ構造を示すことを目的とした図が示されている。図２および図３を参照して先に述べたように、ワークフロー・クーリエ書類１１８は、クライアント１１２のユーザによって当該クライアント１１２から発行されたワークフロー要求１１６に応答して、サーバ１１０によってその主メモリまたは二次的メモリ１１２において組み立てられる。ワークフロー・クーリエ１１８のコピーが、ワークフローの第１段階を完了すべき第１クライアント（例えば、クライアント１１２−１（図１））のメモリ１６２にダウンロードされる。次に、ワークフローの段階が完了すると、ワークフロー・クーリエ１１８のコピーを更新し、クライアント１１２（それぞれ、１１２−１および１１２−３（図１））のメモリに記憶する（更新済みワークフロー・クーリエ１１８’および１１８”として（図１））。図４に示すように、各ワークフロー・クーリエ１１８は、様式１２８を含む複数のデータ構造、プログラム１３０、蓄積状態情報１３２、およびレジストリ１３４を含む。尚、図４は、ワークフロー・クーリエ１１８が、クライアント１１２−１のメモリ１６２−１にダウンロードされた後で、第１実行者によって何等かのアクションがなされる前の状態を示すことを注記しておく。図４のデータ構造における情報は、先に論じた要求ワークフロー１４０−１（即ち、出張申請ワークフロー）から引き出した仮説的値を表わす。
【００２４】様式データ構造１２８は、要求ワークフロー１４０−１の間に記入しなければならない様式または複数の様式を表わす。好適実施例では、様式データ構造１２８における各様式１２８−ｉは、ヘッダ情報３１０−ｉと、完了すべきワークフローのために埋めなければならない記入欄に対応する、記入欄３１２−ｉｊ（ｉおよびｊは異なる指標を表わす）とを含む。図４において、様式データ構造１２８は、２種類の様式１２８−１および１２８−２を含み、これらは各々、多数の記入欄３１２−１ａ，３１２−１ｂ，３１２−１ｃおよび３１２−２ａ，３１２−２ｂ，３１２−２ｃ，３１２−２ｄをそれぞれ有する。
【００２５】ヘッダ３１０−ｉは、様式１２８−ｉが表わされるフォーマット全体を規定し（例えば、当該様式がＨＴＭＬ書類、デルリーナ・フォーム(Delrina Forms)のような所有権のあるフォーマット(propretary format)、またはポストスクリプト・ファイルとして表わされているのかを規定する。他にもいくつか例をあげることはできる）、更に任意に、クライアント１１２上で様式を表示するために用いられるハンドラのＵＲＬ（ユニバーサル・リソース・ロケータ）を規定する。例えば、図４において、様式１２８−２（様式１）は、ポストスクリプト（「Ｐｏｓｔ」）フォーマットであり、ＵＲＬがレジストリ１３４のＣＦ３＿ｒｅｆエントリによって与えられる、ポストスクリプト・ハンドラを必要とする。ハンドラ情報は、特定の様式１２８−ｉに対応するフォーマットに含まれている可能性があるので、これはときとして任意となる。これは、ジャバでイネーブルされるブラウザ１６６−１は、特定の様式または書類を処理すべきクライアント上に互換性のあるハンドラが常駐していない場合は、当該様式または書類のフォーマットに基づくハンドラをネットワークから取り込こむように構成することができるからである。尚、ファイル・フォーマットは、ファイル・ハンドラが、当該様式を構成する記入欄３１２−ｉ全てを表示できることを必ずしも意味するものではない。これは、個々の記入欄３１２−ｉはフォーマットが異なる可能性があるためである。例えば、項目の中には、それらが埋め込まれている様式とは異なるグラフィック・フォーマットを有する場合がある。これはジャバ書類の設計と一貫している。即ち、ＨＴＭＬ複合書類は、埋め込まれたフラット・ファイルを有することができ、かかるフラット・ファイルは属性を有し、当該フラット・ファイルによって参照される、または当該フラット・ファイルの属性に含まれている、ハンドラによってのみ表示可能である。」（８頁１４欄６行〜９頁１５欄２７行）
　
　上記第２引用例の記載及び図面並びにこの分野の技術常識を考慮すると、
　
　上記（ｈ）の記載によれば、クライアントのメモリに記憶される「ワークフロー・クーリエ書類１１８」の中に様式を表示するための「ハンドラのＵＲＬ」が規定されており、データがハンドラ情報を有するといえる。
　
　また、第２引用例に記載された「ハンドラ」の情報は上記（ｈ）によれば、様式を表示するために必要なものであり、様式を表示する際にはチェックされるものである。
　
　上記第２引用例には、以下の技術事項が記載されていると認められる。
　
「データがハンドラ情報を有し、ハンドラ情報はデータの実行の際にはチェックされる。」
　　
（２）対比
　
　本願発明１と引用発明とを対比する。
　　
　引用発明の「アプリケーション・プログラム」は情報の一形態であるから、本願発明１の「情報」に含まれる。
　
　引用発明における「ライセンス期間の更新」は、「ライセンス期間の満了」という出来事を契機として「更新」の処理を行うものでるから、引用発明における「ライセンス期間の満了」、「ライセンス期間の更新」が，本願発明１における「トリガー・イベントが起こる」及び「トリガー・イベントを処理」に相当する。
　
　引用発明における「ライセンス期間」は、「現在日時」を基に「ライセンス期間の満了」が判断されるものであり、本願発明１における「トリガー・イベント・パラメータ」に相当する。また、「ライセンス期間の満了」の判断は「ライセンス期間」を監視し「現在日時」を基に評価するものであるから、引用発明における「ライセンス期間と現在日時を取得し、前記ライセンス期間と前記現在日時を基にライセンス期間の満了を判断し」が、本願発明１の「トリガー・イベント・パラメータを監視する手段によって監視すること、前記トリガー・イベントが起こるかどうかを決定するために前記トリガー・イベント・パラメータを評価する手段によって評価すること」に含まれる。
　
　更に、引用発明においても「ライセンス期間」がダウンロードされるためにはクライアント側に何らかの受信手段を備えているものと認められ、引用発明における「アプリケーション・プログラムと関連したライセンス期間をダウンロードし」が、本願発明１における「情報と関連したトリガー・イベント・パラメータを受信する手段によって受信すること」に含まれる。
　
　引用発明における「認証サーバのＵＲＬ」は「アプリケーション・プログラム」に関連したデータであることは明らかであり、本願発明１の「情報と関連したエクストラ・データ」に相当し、また、引用発明において「認証サーバのＵＲＬを含むインデックス・ファイルを受信」するために何らかの受信手段が備えられているものと認められ、引用発明における「アプリケーション・プログラムと関連した認証サーバのＵＲＬを含むインデックス・ファイルを受信し」は、本願発明１における「情報と関連したエクストラ・データを受信する手段によって受信すること」に含まれる。
　
　そして、 引用発明においてもライセンス期間の満了の際に認証サーバのＵＲＬを基に認証サーバに接続しており、引用発明における「認証サーバのＵＲＬを基に前記認証サーバに接続し」が、本願発明１の「エクストラ・データを処理する」に相当し、また、引用発明の「ライセンス期間の満了の際に、前記インデックス・ファイルの前記認証サーバのＵＲＬを基に前記認証サーバに接続し」が、本願発明１の「トリガー・イベント・パラメータが監視されかつ評価されることに基づいて前記トリガー・イベントが起こる場合に、前記エクストラ・データを処理する手段によって処理すること」に相当する。
　
　また、引用発明においても認証サーバに接続後にライセンス期間の更新の処理を行っているので、引用発明における「認証サーバに接続した後に、ライセンス期間の更新の処理をする」が、本願発明１における「エクストラ・データを処理した後で、前記トリガー・イベントを処理する手段によって処理する」に相当する。
　
　したがって、本願発明１と引用発明は、以下の点で一致し、また、相違する。
　
（一致点）
　
「【請求項１】
　情報と関連したトリガー・イベントを処理する方法であって、
　前記情報と関連したトリガー・イベント・パラメータを受信する手段によって受信すること、
　前記情報と関連したエクストラ・データを受信する手段によって受信すること、
　前記トリガー・イベント・パラメータを監視する手段によって監視すること、
　前記トリガー・イベントが起こるかどうかを決定するために前記トリガー・イベント・パラメータを評価する手段によって評価すること、
　前記トリガー・イベント・パラメータが監視されかつ評価されることに基づいて前記トリガー・イベントが起こる場合に、前記エクストラ・データを処理する手段によって処理すること、
　前記エクストラ・データを処理した後で、前記トリガー・イベントを処理する手段によって処理することを含む、
　方法。」
　
（相違点）
　本願発明１では、トリガー・イベントを処理する前に、エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されかつチェックされるのに対して、引用発明では、そのような構成を備えていない点。
　
　
（３）検討
　
　そこで、上記相違点について検討する。
　
　第２引用例にはデータがハンドラ情報を有し、ハンドラ情報はデータの実行の際にはチェックされるという技術事項が記載されている。しかしながら第１引用例において「認証サーバのＵＲＬ」に関して段落【００４３】（上記（ｅ）参照。）に「図５はインデックス・サーバ３が送信するインデックス・ファイルの一例を示す図である。本ファイルはＸＭＬ（extensible markup language）で記述されている。ここでは「url」タグで囲まれた部分に認証サーバ４のＵＲＬが暗号化されて記述されている」、段落【００４４】（上記（ｅ）参照。）に「次に、クライアント２が暗号化されたインデックス・ファイルを受信すると（ステップ５８）、この暗号を復号化し平文のインデックス・ファイルを得る（ステップ５９）。図６は復号化した後のインデックス・ファイルの一例を示す。図５と比較して「url」タグで囲まれた部分が意味のある平文になっている。」と記載されており、インデックスファイルの認証サーバのＵＲＬ部分が暗号化されてインデックス・サーバから送られ、クライアント側で複合化されるものであるが、第１引用例において「ハンドラ」に関して、また、何らかの手段によって「認証サーバのＵＲＬ」が解析することも記載されておらず、引用発明の「認証サーバのＵＲＬ」はハンドラを持つものではない。仮に「認証サーバのＵＲＬ」がハンドラを持つとして引用例２の技術事項を適用したとしても、「認証サーバのＵＲＬ」の処理の際にハンドラ情報のチェックが行われるものであり、ハンドラを持つかどうかを見るために「認証サーバのＵＲＬ」が待ち行列から検索されかつチェックされるものではない。
　また、第２引用例はワークフローをネットワークの分散ノード上で実行する方法に関するものであって、トリガー・イベントの処理に関するものでなく引用発明に第２引用例を組み合わせる動機付けも見当たらない。
　更に、原査定の拒絶理由で引用した特開平１０−１８７４６６号公報（以下、「第３引用例」という。特に、段落【０００３】−【０００４】）、及び特開平３ー０８５６４１号公報（以下、「第４引用例」という。特に、２頁左下欄１９行−右下欄１２行）には、処理すべきデータを待ち行列に置くことは記載されているが、ハンドラ情報のチェックに関しては記載されていない。
　　
　したがって、「エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されかつチェックされる」ことを容易になし得たとすることはできないから、その余の点は判断するまでもなく、本願発明１は、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
　
（４）本願発明２乃至１３について
　
１）本願発明２乃至８について
　本願発明１に従属する本願発明２乃至８は、本願発明１の発明特定事項を全て含みさらに発明特定事項で限定したものであるから、上記（３）と同様の理由により、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
２）本願発明９について
　独立形式で記載された本願発明９は、「アプリケーションのための期限切れ処理の方法」に係る発明であるが、本願発明１の発明特定事項である「トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されかつチェックされる」にける「トリガー・イベント」および「エクストラデータ」を、「アプリケーションのための期限切れ」および「ＵＲＬ」として限定し、「アプリケ
ーションのための期限切れ処理する前に、前記ＵＲＬが待ち行列に置かれ、前記ＵＲＬが特定のハンドラを持つかどうかを見るために前記ＵＲＬが前記待ち行列から検索されかつチェックされる」として含むものである。
　
　したがって、本願発明９は、上記（３）と同じ理由により、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
３）本願発明１０及び１１について
　本願発明９に従属する本願発明１０および１１は、本願発明９の発明特定事項を全て含みさらに発明特定事項で限定したものであるから、上記（３）と同様の理由により、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
４）本願発明１２，１４，及び１５について
　それぞれ独立形式で記載された本願発明１２、本願発明１４及び本願発明１５は、それぞれ「情報およびエクストラ・データと関連したトリガー・イベントを処理する無線装置」、「実行されるとき情報と関連したトリガー・イベントを処理するための方法を実行するコンピュータ命令を含むコンピュータ読み出し可能な媒体」、および「情報と関連したトリガー・イベントを処理するために使用される装置」に係る発明であるが、本願発明１の発明特定事項である「トリガー・イベントを処理する前に、前記エクストラ・データが待ち行列に置かれ、前記エクストラ・データが特定のハンドラを持つかどうかを見るために前記エクストラ・データが前記待ち行列から検索されかつチェックされる」を含むものである。
　
　したがって、本願発明１２、本願発明１４及び本願発明１５は、上記（３）と同じ理由により、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
５）本願発明１３について
　本願発明１２に従属する本願発明１３は、本願発明１２の発明特定事項を全て含みさらに発明特定事項で限定したものであるから、上記（３）と同様の理由により、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明することができたとはいえない。
　
　　
４．むすび
　
　以上のとおり、本願発明１乃至本願発明１５は、引用発明及び第２引用例乃至第４引用例に記載された技術事項に基づいて、当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。　
　よって、結論のとおり審決する。