【事件の表示】
　特願２０１０−５０６５０１「プロテイン，プール，およびスロークス処理環境」拒絶査定不服審判事件〔平成２０年１１月　６日国際公開，ＷＯ２００８／１３４４５２，平成２２年　７月２２日国内公表，特表２０１０−５２５４９４，請求項の数（４１）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は，平成２０年４月２４日（パリ優先権主張外国庁受理２００７年４月２４日（以下「優先日」という），米国）の国際出願であって，平成２１年１０月２３日に国内書面が提出され，平成２１年１２月２２日に翻訳文提出がなされ，平成２４年１０月２４日付けで拒絶理由が通知され，平成２５年４月３０日付けで意見・手続補正がなされ，平成２５年５月２４日に拒絶理由（以下「原審拒絶理由」という）が通知され，平成２５年１１月２８日付けで，意見・手続補正がなされ，平成２６年２月１７日付けで拒絶査定（以下「原査定」という）がなされ，これに対して，平成２６年６月１９日付けで拒絶査定不服審判が請求され，その後，当審において平成２７年５月１日付けで拒絶理由（以下「当審拒絶理由」という）が通知され，平成２７年１１月９日付けで，意見・手続補正がなされたものである。
第２　本願発明
　本願の請求項１乃至４１に係る発明は，平成２７年１１月９日付けの手続補正で補正された特許請求の範囲の請求項１乃至４１に記載された事項により特定されるものと認められる。
　本願の請求項１に係る発明（以下「本願発明」という）は，以下のとおりである。
「ソース・デバイスによって生成又は出力されるデータ，又は前記ソース・デバイスに対応するプログラムを使用して，前記ソース・デバイスのイベントを検出するステップと，
　前記イベントを指定するデバイス・イベント・データであるディスクリプトと，当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生するステップであって，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている，ステップと，
　前記少なくとも１つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスを含む前記プロテインを，類別されていない（untyped）データ構造を用いて表現する，ステップと，
　前記データ・カプセルを，第１アプリケーション・タイプを有する第１アプリケーションから，少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにプールを介して転送するステップであって，前記第１アプリケーション・タイプは前記第２アプリケーション・タイプとは異なり，前記少なくとも１つのデータ・シーケンスを発生するステップを，前記第１アプリケーションによって実行する，ステップと，
　前記転送の間，前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップと，
を備えている，方法。」
第３　原査定の理由について
１　原査定の理由の概要
　原査定の理由である原審拒絶理由に記載された理由３は以下のとおりである。
『３．この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
・請求項　　１−４８
・引用文献　１
・備考
　引用文献１（特に，段落【００１０】−【００１６】，【００５５】及び図１Ａ−２，４参照。）には　コンピュータシステム１０１（本願の「ソース・デバイス」に相当。）のアプリケーション１０２（本願の「第１アプリケーション」に相当。）からの，アプリケーションヘッダとアプリケーションデータを有するアプリケーションメッセージ（本願の「データ・シーケンス」に相当。）をコード化し，カプセル化し，当該カプセル（本願の「データ・カプセル」に相当。）をコンピュータシステム１１１に転送し，当該カプセルから取り出し，復号化し，コンピュータシステム１１１のアプリケーション１１２（本願の「第２アプリケーション」に相当。）が前記アプリケーションメッセージを受け取ることが記載されている。
　請求項１に係る発明と引用文献１記載の発明とを対比すると，主に以下の点で相違する。
・相違点１
　請求項１に係る発明では，ソース・デバイスのイベントを検出し，前記イベントを指定するデバイス・イベント・データと，当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生し，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データであるのに対し，引用文献１記載の発明では，そのような構成の明記がない点。
・相違点２
　請求項１に係る発明では，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有するのに対し，引用文献１記載の発明では，そのような構成の明記がない点。
・相違点３
　請求項１に係る発明では，第１アプリケーション・タイプは第２アプリケーション・タイプとは異なるのに対し，引用文献１記載の発明では，そのような構成の明記がない点。
・相違点４
　請求項１に係る発明では，転送の間，データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するのに対し，引用文献１記載の発明では，そのような構成の明記がない点。
　以下，上記相違点１−４について検討する。
・相違点１について
　イベントを検出する技術は，周知技術である。
　また，イベントが発生したときに，イベント・データと，イベントの状態を他のアプリケーションに通信することも，周知技術である。
　さらに，引用文献１のアプリケーションヘッダにはアプリケーションを識別する情報が付与されていることが通常であるから，引用文献１のアプリケーションヘッダにアプリケーションのタイプを特定するデータを設けることは，当業者が適宜なし得たことである。
　よって，引用文献１記載の発明において，上記周知技術を適用し，ソース・デバイスのイベントを検出し，前記イベントを指定するデバイス・イベント・データと，当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生し，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データであるようにすることは，当業者が容易に想到し得たことである。
・相違点２について
　引用文献１記載のカプセルは，すべてのプロトコルに対応可能であるから，アプリケーションに独立しているものと推定される。
　よって，引用文献１記載の発明において，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有するようにすることは，当業者が適宜なし得たことである。
・相違点３について
　タイプの異なるアプリケーション間での通信（例えば，ワードプロセッサ，表計算やメールというタイプの場合など）は，周知技術である。
　よって，引用文献１記載の発明において，上記周知技術を適用し，第１アプリケーション・タイプは第２アプリケーション・タイプとは異なるようにすることは，当業者が容易に想到し得たことである。
・相違点４について
　引用文献１記載の発明において，アプリケーションメッセージは，単に，コード化，復号化されているのみであるから，実質的に不変のまま維持されているといえる。また，そうでないとしても，コード化，復号化するか否かは，当業者が必要に応じて適宜選択し得た設計的事項であるから，引用文献１記載の発明において，コード化，復号化しないようにすることは，当業者が適宜なし得たことである。
　よって，引用文献１記載の発明において，転送の間，データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するようにすることは，当業者が適宜なし得たことである。
　また，その余の相違点があるとしても，それらは，周知技術又は当業者が適宜なし得たことである。
　よって，請求項１に係る発明は，引用文献１記載の発明及び周知技術に基いて，当業者が容易に想到し得たことである。
　さらに，請求項２−４８に係る発明において請求項１に係る発明と異なる構成は，引用文献１に記載されている構成，周知技術又は当業者が適宜なし得たことである。
　したがって，請求項１−４８に係る発明は，引用文献１記載の発明及び周知技術に基いて，当業者が容易に想到し得たことである。』
２　原査定の理由の判断
（１）引用文献１の記載事項
　本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能とされ，原査定の理由である原審拒絶理由で引用された文献である特開２００６−１７２４５４号公報（以下「引用文献１」という。）には，関連図面とともに，以下の技術的事項が記載されている。
ア　引用文献１の「この本発明の原理は，キューに入れられたアプリケーションメッセージを確実に転送するための方法，システム，およびコンピュータプログラム製品を対象とする。」（段落【００１０】）との記載から，引用文献１には「アプリケーションメッセージを確実に転送するための方法」が記載されている。また，引用文献１の「図１Ａでは，コンピュータシステム１０１は，アプリケーション１０２，キューチャネル１０３，およびキューマネージャー１０８を含む。（中略）アプリケーション１０２は，アプリケーション１１２へ配信するためのアプリケーションメッセージを有することがある。（後略）」（段落【００３０】）との記載，「図１Ｂでは，コンピュータシステム１１１は，アプリケーション１１２，キューリスナー１１３，およびキューマネージャー１１８を含む。（中略）アプリケーション１１２は，アプリケーション１０２から受信するアプリケーションメッセージを有することがある。（後略）」（段落【００３４】）との記載から，引用文献１には「コンピュータシステム１０１のアプリケーション１０２からのアプリケーションメッセージをコンピュータシステム１１１のアプリケーション１１２に転送する方法」が記載されていると認められる。
イ　引用文献１の「（前略）キューに入れられたアプリケーションメッセージの確実な転送を実施するためのプロトコルは，メッセージのカプセル化を利用することができる。一般に，メッセージのカプセル化は，第１のメッセージ（たとえば，アプリケーションメッセージ）（の少なくとも一部）を，第２のメッセージ（たとえば，転送メッセージ）内にラップすることを含む。いくつかの実施形態では，第１および第２のメッセージは，たとえばシンプルオブジェクトアクセスプロトコル（「ＳＯＡＰ」）などの同一のメッセージングプロトコルに従って構成される。（後略）」（段落【００４９】）との記載から，引用文献１には「メッセージのカプセル化を利用し，アプリケーションメッセージを転送し，メッセージのカプセル化は，アプリケーションメッセージを転送メッセージ内にラップすることを含み，ＳＯＡＰなどの同一メッセージングプロトコルに従って構成され」ることが記載されていると認められる。
ウ　引用文献１の「送信側転送層は，コード化されたアプリケーションメッセージをキューから外す。送信側転送層は，メッセージングプロトコル（たとえばＳＯＡＰ）に従って，転送メッセージを構成する。送信側転送メッセージは，受信側コンピュータシステムを識別し，適切な場合は，対応するメッセージセッションを識別する。送信側転送層は，コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化する。送信側転送層は，その転送メッセージを受信側コンピュータシステムへの配信用として送信する。」（段落【００１１】）との記載から，引用文献１には「送信側転送層は，コード化されたアプリケーションメッセージをキューから外し，受信側コンピュータを識別し，コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し，転送メッセージを受信側コンピュータシステムへ送信する」ことが記載されていると認められる。
エ　引用文献１の「送信側の保存および回送層（store and forward layer）は，転送メッセージにアクセスする。送信側の保存および回送層は，転送メッセージの転送ヘッダをコード化して，対応するコード化された転送ヘッダを作成する。」（段落【００１２】）との記載から，引用文献１には「送信側の保存及び回送層は，転送メッセージの転送ヘッダを作成する」ことが記載されていると認められる。
オ　引用文献１の「受信側の保存および回送層は，メッセージングプロトコル（たとえばＳＯＡＰ）に従って構成された保存および回送メッセージを受信する。受信側の保存および回送層は，コード化された転送ヘッダを，対応する転送ヘッダへと復号する。受信側の保存および回送層は，メッセージングプロトコル（たとえばＳＯＡＰ）に従って，転送メッセージを構成する。受信側の保存および回送層は，転送メッセージがアプリケーションへどのように転送されるかを示すために，その転送メッセージ内に転送ヘッダを含む。保存および回送層は，コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し，その転送メッセージを受信側転送層へ送信する。」（段落【００１４】）との記載から，引用文献１には「受信側の保存及び回送層は，コード化された転送ヘッダを復号し，転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め，アプリケーションメッセージを転送メッセージ内にカプセル化し，転送メッセージを受信側転送層へ送信する。」ことが記載されていると認められる。
カ　引用文献１の「受信側転送層は，そのキューから外されたメッセージを受信し，メッセージプロトコル（たとえばＳＯＡＰ）に従って，デキュー応答を構成する。受信側転送層は，コード化されたアプリケーションメッセージを，そのキューから外された応答内にカプセル化する。（中略）受信側転送層は，デキュー応答をアプリケーションへ送信する。キューリスナーは，そのデキュー応答を受信する。キューリスナーは，コード化されたアプリケーションメッセージをアプリケーションメッセージへと復号し，そのアプリケーションメッセージをアプリケーションへ送信する。（後略）」（段落【００１６】）との記載から，引用文献１には「受信側転送層はメッセージを受信し，コード化されたアプリケーションメッセージを復号化し，アプリケーションへ送信する。」ことが記載されていると認められる。
キ　上記ア乃至カより，引用文献１には次の発明（以下「引用発明」という。）が記載されているものと認められる。
「コンピュータシステム１０１のアプリケーション１０２からのアプリケーションメッセージをコンピュータシステム１１１のアプリケーション１１２に転送する方法であって，
メッセージのカプセル化を利用し，アプリケーションメッセージを転送し，メッセージのカプセル化は，アプリケーションメッセージを転送メッセージ内にラップすることを含み，ＳＯＡＰなどの同一メッセージングプロトコルに従って構成され，
送信側転送層は，コード化されたアプリケーションメッセージをキューから外し，受信側コンピュータを識別し，コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し，転送メッセージを受信側コンピュータシステムへ送信し，
送信側の保存及び回送層は，転送メッセージの転送ヘッダを作成し，
受信側の保存及び回送層は，コード化された転送ヘッダを復号し，転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め，アプリケーションメッセージを転送メッセージ内にカプセル化し，
受信側転送層はメッセージを受信し，コード化されたアプリケーションメッセージを復号化し，アプリケーションへ送信する，
ことを特徴とする方法。」
（２）対比
ア　引用発明の「転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダ」を含めることは，転送の順番又は方法を記述していると解せるので「少なくとも１つのデータ・シーケンス」を含むことといえ，「アプリケーションメッセージを転送メッセージ内にカプセル化」することは，「データ・カプセルを形成」することといえ，引用発明の「メッセージのカプセル化は，アプリケーションメッセージを転送メッセージ内にラップすることを含み，ＳＯＡＰなどの同一メッセージングプロトコルに従って構成」することは，ＳＯＡＰなどのアプリケーションのタイプに依存しないデータ構造を用いているので，「類別されていない（untyped）データ構造を用いて表現する」ことと解せるので，引用発明における「メッセージのカプセル化は，アプリケーションメッセージを転送メッセージ内にラップすることを含み，ＳＯＡＰなどの同一メッセージングプロトコルに従って構成され，送信側転送層は，（中略）コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し，（中略）受信側の保存及び回送層は，コード化された転送ヘッダを復号し，転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め，アプリケーションメッセージを転送メッセージ内にカプセル化」することと，本願発明における「前記少なくとも１つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスを含む前記プロテインを，類別されていない（untyped）データ構造を用いて表現する，ステップ」とは，後記する点で相違するものの，“少なくとも１つのデータ・シーケンスを含むデータ・カプセルを形成するステップであって，前記少なくとも１つのデータ・シーケンスを含む，類別されていない（untyped）データ構造を用いて表現する，ステップ”という点で一致する。
イ　引用発明の「コンピュータシステム１０１のアプリケーション１０２からのアプリケーションメッセージをコンピュータシステム１１１のアプリケーション１１２に転送する方法」は，本願発明における「前記データ・カプセルを，第１アプリケーション・タイプを有する第１アプリケーションから，少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにプールを介して転送するステップ」とは，後記する点で相違するものの，“前記データ・カプセルを，第１アプリケーションから，第２アプリケーションに転送するステップ”という点で一致する。
　本願発明と引用発明とを対比すると以下の点で一致し，相違している。
＜一致点＞
　少なくとも１つのデータ・シーケンスを含むデータ・カプセルを形成するステップであって，前記少なくとも１つのデータ・シーケンスを含む，類別されていない（untyped）データ構造を用いて表現する，ステップと，
　前記データカプセルを第１のアプリケーションから第２のアプリケーションに転送ステップとを，
を備える方法。
＜相違点１＞
　本願発明では「ソース・デバイスによって生成又は出力されるデータ，又は前記ソース・デバイスに対応するプログラムを使用して，前記ソース・デバイスのイベントを検出」しているのに対して，引用発明はそのように特定されていない点。
＜相違点２＞
　本願発明では「前記イベントを指定するデバイス・イベント・データであるディスクリプトと，当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生するステップであって，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている，ステップ」であり，「プロテイン」というデータ形式であるのに対して，引用発明はそのように特定されていない点。
＜相違点３＞
　本願発明では「データ・カプセル」を「プールを介して」転送しているノに対して、引用発明はそのように特定されていない点。
＜相違点４＞
　本願発明では「第１アプリケーション・タイプを有する第１アプリケーション」と「少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーション」について、「前記第１アプリケーション・タイプは前記第２アプリケーション・タイプとは異なり，前記少なくとも１つのデータ・シーケンスを発生するステップを，前記第１アプリケーションによって実行する，ステップ」であるのに対して，引用発明はそのように特定されていない点
＜相違点５＞
　本願発明では「前記転送の間，前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップ」であるのに対して，引用発明はそのように特定されていない点。
（３）判断
（３−１）相違点１
　引用発明の「アプリケーションメッセージ」を，キューに入れる契機となるイベントを検出してキューに入れることは周知技術である。また，引用発明の「アプリケーションメッセージ」を「ソース・デバイスによって生成又は出力」されるデータとすることも，「ソース・デバイスに対応するプログラムを使用」することも周知技術である。
　そうすると，「ソース・デバイスによって生成又は出力されるデータ，又は前記ソース・デバイスに対応するプログラムを使用して，前記ソース・デバイスのイベントを検出」することに格別の困難性はない。
（３−２）相違点２および３
　「イベントを指定するデバイス・イベント・データ」や「イベントの状態情報」をアプリケーションメッセージに含めることは当業者が適宜なし得ることである。
　しかしながら，「前記イベントを指定するデバイス・イベント・データであるディスクリプトと，当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生する」ことや，「前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている」ことは周知技術とは言えず，第１アプリケーションから第２アプリケーションへ「プールを介して」転送することも本願の優先日前に周知技術であったとは言えない。
　このことにより，「大規模マルチ・プロセス相互動作を可能としかつ促進する新規プログラミング又は処理環境を含む実施形態を教示する」（段落【０００７】）という効果を得ることができると解せる。
　また，引用発明は「受信側コンピュータを識別し，コード化されたアプリケーションを転送メッセージ内にカプセル化」していることから，宛先を識別していると解される。そのため，本願発明のように，宛先が必ずしも特定されていない「データ・カプセル」を「プールを介して」転送することが周知技術であったとしても，前記周知技術を組み合わせる動機付けがない。
（３−３）相違点４
　タイプの異なるアプリケーション間での通信は周知技術であり，第１アプリケーション・タイプを第２アプリケーション・タイプとは異なるようにすることは当業者が適宜なし得ることである。
　また，その場合「データ・シーケンス」をタイプの異なるアプリケーションのうちのどのアプリケーションで実行するのかも適宜選択し得た設計的事項である。
（３−４）相違点５
　引用発明の「アプリケーションメッセージ」は，第１アプリケーションから第２アプリケーションへ転送の間，コード化及び復号化されるのみであり，実質的に不変のまま維持されると解せる。そうすると，引用発明の「アプリケーションメッセージ」を「前記転送の間，前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持する」ことは当業者が適宜なし得ることである。
（４）小括
　したがって，本願発明は，当業者が引用発明に基づいて容易に発明することができたとはいえない。
　請求項２８に係る発明は，データをカプセル化する方法であり，請求項２９に係る発明は，実施形態の異なるものであるが，本願発明と同様に，当業者引用発明に基づいて容易に発明することができたとはいえない。
　さらに，請求項２−２７，３０−４１に係る発明は，本願発明又は請求項２９に係る発明をさらに限定したものであるので，本願発明と同様に，当業者が引用発明に基づいて容易に発明することができたとはいえない。
　よって，原査定の理由によっては，本願を拒絶することができない。
第４　当審の拒絶理由について
１　当審拒絶理由の概要
『この出願は，発明の詳細な説明及び特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号又は第２号に規定する要件を満たしていない。 
  
 　　　　　　　　　　　　　　　　　記 
  
 　請求項１−４２に係る発明は，特許請求の範囲とその実質的なコピー箇所以外において，発明の詳細な説明に記載された用語と不統一のため，両者の対応関係が不明瞭であり，特許を受けようとする発明が発明の詳細な説明に記載されたものでなく，明確でない。 
  
 １．請求項１−２７について 
  
 （１）請求項１には「ソース・デバイスのイベントを検出する」と記載されているが，発明の詳細な説明との対応が不明である。 
 　発明の詳細な説明の段落【００５９】には「（前略）各デバイス（中略）は，それぞれのデバイス上で走っているプログラム（中略）が発生または出力をされた離散生データをプラズマ・プロテインに変換し，プラズマ・プールに貯入する。（後略）」，段落【００６２】には「（前略）入力プールからイベント・プロテインを抽出できる。プロテインの抽出に続いて，デバイスＣは，ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを，プロテイン・データが対応する処理イベントにおいて用いることができる。（中略）プロテインの抽出に続いて，デバイスＢは，プロテイン・データが対応する処理イベントにおいて，プロテインのデータを用いることができる。」と記載されているものの， 
 　請求項１の「ソース・デバイスのイベントを検出する」ことは，発明の詳細な説明の「デバイス上で走っているプログラムが発生または出力した離散生データ」が「発生または出力」することと解するのか，「イベント・プロテインを抽出し，ディスクリップのスローおよびプロテインのインジェストを引き出しまたは読み出す」ことと解するのかが不明である。 
  
 （２）請求項１には「前記イベントを指定するデバイス・イベント・データと，当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生する」と記載されているが，請求項１の「イベントを指定するデバイス・イベント・データ」「イベントの状態情報」「データ・シーケンスを発生する」ことと発明の詳細な説明との対応が不明である。 
 　発明の詳細な説明の段落【００６０】には「各プロテインは，アプリケーションが発生し，プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。（中略）プロテインのデータ・ペイロード（例えば，インジェスト）は，プログラム・イベントについての１組の有用な状態情報全体を搬送する。」と記載されているものの， 
 　請求項１の「イベントを指定するデバイス・イベント・データ」「イベントの状態情報」を発明の詳細な説明の「ディスクリップ・リスト」「データ・ペイロード（例えば，インジェスト）」とそれぞれ解するとするのか，または，それらに含まれる「スロー（スロークス）」と解するのかが不明である。 
 　また，請求項１の「データシーケンス」と発明の詳細な説明の「スロー」と解するのかが不明である。仮に，請求項１の「データ・シーケンス」を発明の詳細な説明の「スロー」と解すると，請求項１の「イベントを指定するデバイス・イベント・データと，当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンス」の構成が，発明の詳細な説明の「スロー」に「ディスクリップ・リスト」（又は「スロー」）と「データ・ペイロード」（又はスロー）とを備えている構成となり，そのような構成の「スロー」について，発明の詳細な説明に記載も示唆もされていない。 
  
 （３）請求項１には「データ・カプセルが，前記少なくとも１つのデータ・シーケンスを，類別されていないデータ構造を用いて表現するステップ」と記載されているが，請求項１の「類別されていないデータ構造」について，発明の詳細な説明との対応が不明である。 
 発明の詳細な説明の段落【００２６】には「非標準プロテイン構造については，（後略）」，段落【００２７】には「（前略），プロテインの標準構造では，（後略）」，段落【００３４】には「（前略），類型に分けたデータをプロテイン内部に埋め込むために（中略），スローは，類型に分けた（恐らくは，集計）データの一片を表すバイトの線形シーケンスであり，（後略）」と記載されていることから，発明の詳細な説明には，「非標準プロテイン構造」や「プロテインの標準構造」や類型された「スロー」を「プロテイン」の内部に埋め込む実施例が記載されていると解される。しかし，請求項１の「類別されていないデータ構造」に関し，発明の詳細な説明に記載も示唆もされていない。 
  
 （４）請求項１には「データ・カプセルを，第１アプリケーション・タイプを有する第１アプリケーションから，少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに転送するステップ」と記載されているが，請求項１の「データ・カプセル」を「第1アプリケーション」から「第２アプリケション」へ「転送する」ことについて，発明の詳細な説明との対応が不明である。 
 　発明の詳細な説明の段落【００５７】には「（前略）プロテインは，他のアプリケーションとプロテイン・データ・コンテンツを共有する方法として，プールに供給される。図７は，一実施形態の下において，スロークス，プロテイン，およびプールを用いたデータ交換を含む処理環境のブロック図である。この環境例は，前述のようにスロークス，プロテイン，およびプールの使用によりデータを共有する３つのデバイス（中略）を含む。これらのデバイスの各々は，３つのプール（中略）に結合されている。プール１は，それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（中略）を含む（中略）。プール２は，それぞれのデバイスから当該プールに提供または転送された多数のプロテイン（中略）を含む（中略）。プール３は，それぞれのデバイスから当該プールに供給または転送された多数のプロテイン（中略）を含む（後略）」，段落【００６２】「一例として，デバイスＣは１つ又は複数のプロテイン（中略）をプールから抽出することができる。プロテインの抽出に続いて，デバイスＣは，ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを，プロテイン・データが対応する処理イベントにおいて用いることができる。（後略）」と記載されているものの， 
 　発明の詳細な説明の「プロテイン」は，「デバイス」から「プール」に転送され，「プール」から「プロテイン」を抽出し，プロテイン・データに対応する処理イベントにおいて用いているので，デバイス上のアプリケーションが「プロテイン」を「転送」するのは，「プール（レポジトリ）」のみであると解される。そのため，「プロテイン」を「第１アプリケーション」から「第２アプリケーション」に「転送」させることは記載されていない。即ち，請求項１の「データ・カプセル」を発明の詳細な説明の「プロテイン」と解すると， 
 請求項１の「データ・カプセル」を「アプリケーション」から他の「アプリケーション」へ「転送する」ことは，発明の詳細な説明に記載も示唆もされていない。 
  
 （６）請求項１には「前記転送の間，前記データ・カプセルの少なくとも１つのデータ・シーケンスを不変のまま維持するステップ」と記載されているが，発明の詳細な説明との対応が不明である。 
 　発明の詳細な説明の段落【００１８】には「（前略）プロテインは，それらが含むデータを不変のまま維持しつつ，プロセッサ間そしてネットワークを跨いで自然に移動できるように構成されている。」と記載されている。 
 　請求項１の「データ・カプセル」「データ・シーケンス」を発明の詳細な説明の「プロテイン」「スロー」と解すると，「プロテイン」や「スロー」は，コード化されているのみであるから，実質的に不変のまま維持されると解することができるものの，発明の詳細な説明には「プロテイン」や「スロー」を不変のまま「維持する」という動作について，記載も示唆もされていない。更に，「転送の間」が何時から何時までを想定しているのかが不明であり，「転送の間」に「維持する」という動作に関しても，発明の詳細な説明に記載も示唆もされていない。』
２　当審拒絶理由の判断
（１）平成２７年１１月９日付け手続補正によって，審判請求時の請求項１に係る発明（平成２５年１１月２５日付け手続補正で補正された請求項１に記載された発明）の「ソース・デバイスのイベントを検出するステップ」，「前記イベントを指定するデバイス・イベント・データと，当該イベントの状態情報とを備えている少なくとも１つのデータ・シーケンスを発生するステップであって，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである，ステップ」，「前記少なくとも１つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスを，類別されていない（untyped）データ構造を用いて表現する，ステップ」，「前記データ・カプセルを，第１アプリケーション・タイプを有する第１アプリケーションから，少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションに転送するステップ」を
「ソース・デバイスによって生成又は出力されるデータ，又は前記ソース・デバイスに対応するプログラムを使用して，前記ソース・デバイスのイベントを検出するステップ」，「前記イベントを指定するデバイス・イベント・データであるディスクリプトと，当該イベントの状態情報であるインジェストとを備えている少なくとも１つのデータ・シーケンスを含むプロテインを発生するステップであって，前記デバイス・イベント・データおよび状態情報は，前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている，ステップ」，「前記少なくとも１つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって，該データ・カプセルが，前記少なくとも１つのデータ・シーケンスを含む前記プロテインを，類別されていない（untyped）データ構造を用いて表現する，ステップ」，「前記データ・カプセルを，第１アプリケーション・タイプを有する第１アプリケーションから，少なくとも１つの第２アプリケーション・タイプを有する少なくとも１つの第２アプリケーションにプールを介して転送するステップ」とそれぞれ補正された。
　このことにより，本願発明の「ソース・デバイスのイベントを検出するステップ」と「ソースデバイスによって生成又は出力されるデータ，又は前記ソースデバイスに対応するプログラム」，「イベントを指定するデバイス・イベント・データ」と「ディスクリプト」，「イベントの状態情報」と「インジェスト」，「データシーケンス」と「プロテイン」，「転送するステップ」と「プール」との対応がそれぞれ明確になった。
　また，本願発明の「類別されていない（untyped）データ構造」及び「転送の間，（中略）不変のまま維持するステップ」については，「アプリケーションに対応するタイプを有するタイプ特定データを含むスロー」と「プロテイン」の関係，「プールを介して転送するステップ」が明確になったことで，発明の詳細な説明との対応が明確となった。
よって，請求項１に係る拒絶理由は解消した。
　また，当審拒絶理由おいて指摘した請求項４２は削除され，請求項２８及び２９に係る発明は，請求項１に係る発明と同様に補正された。これにより，請求項２８及び２９に係る発明の拒絶理由は解消した。
　請求項１に従属している請求項２−２７に係る発明，及び請求項２９に従属している請求項３０−４１に係る発明についても，拒絶理由が解消した。
第５　むすび
　以上のとおり，原査定の理由によっては，本願を拒絶することはできない。また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。