ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F 審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
|---|---|
| 管理番号 | 1310292 |
| 審判番号 | 不服2014-11703 |
| 総通号数 | 195 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2016-03-25 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2014-06-19 |
| 確定日 | 2016-02-17 |
| 事件の表示 | 特願2010-506501「プロテイン,プール,およびスロークス処理環境」拒絶査定不服審判事件〔平成20年11月 6日国際公開,WO2008/134452,平成22年 7月22日国内公表,特表2010-525494,請求項の数(41)〕について,次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は,特許すべきものとする。 |
| 理由 |
第1 手続の経緯 本願は,平成20年4月24日(パリ優先権主張外国庁受理2007年4月24日(以下「優先日」という),米国)の国際出願であって,平成21年10月23日に国内書面が提出され,平成21年12月22日に翻訳文提出がなされ,平成24年10月24日付けで拒絶理由が通知され,平成25年4月30日付けで意見・手続補正がなされ,平成25年5月24日に拒絶理由(以下「原審拒絶理由」という)が通知され,平成25年11月28日付けで,意見・手続補正がなされ,平成26年2月17日付けで拒絶査定(以下「原査定」という)がなされ,これに対して,平成26年6月19日付けで拒絶査定不服審判が請求され,その後,当審において平成27年5月1日付けで拒絶理由(以下「当審拒絶理由」という)が通知され,平成27年11月9日付けで,意見・手続補正がなされたものである。 第2 本願発明 本願の請求項1乃至41に係る発明は,平成27年11月9日付けの手続補正で補正された特許請求の範囲の請求項1乃至41に記載された事項により特定されるものと認められる。 本願の請求項1に係る発明(以下「本願発明」という)は,以下のとおりである。 「ソース・デバイスによって生成又は出力されるデータ,又は前記ソース・デバイスに対応するプログラムを使用して,前記ソース・デバイスのイベントを検出するステップと, 前記イベントを指定するデバイス・イベント・データであるディスクリプトと,当該イベントの状態情報であるインジェストとを備えている少なくとも1つのデータ・シーケンスを含むプロテインを発生するステップであって,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている,ステップと, 前記少なくとも1つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスを含む前記プロテインを,類別されていない(untyped)データ構造を用いて表現する,ステップと, 前記データ・カプセルを,第1アプリケーション・タイプを有する第1アプリケーションから,少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにプールを介して転送するステップであって,前記第1アプリケーション・タイプは前記第2アプリケーション・タイプとは異なり,前記少なくとも1つのデータ・シーケンスを発生するステップを,前記第1アプリケーションによって実行する,ステップと, 前記転送の間,前記データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持するステップと, を備えている,方法。」 第3 原査定の理由について 1 原査定の理由の概要 原査定の理由である原審拒絶理由に記載された理由3は以下のとおりである。 『3.この出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。 記 (引用文献等については引用文献等一覧参照) ・請求項 1-48 ・引用文献 1 ・備考 引用文献1(特に,段落【0010】-【0016】,【0055】及び図1A-2,4参照。)には コンピュータシステム101(本願の「ソース・デバイス」に相当。)のアプリケーション102(本願の「第1アプリケーション」に相当。)からの,アプリケーションヘッダとアプリケーションデータを有するアプリケーションメッセージ(本願の「データ・シーケンス」に相当。)をコード化し,カプセル化し,当該カプセル(本願の「データ・カプセル」に相当。)をコンピュータシステム111に転送し,当該カプセルから取り出し,復号化し,コンピュータシステム111のアプリケーション112(本願の「第2アプリケーション」に相当。)が前記アプリケーションメッセージを受け取ることが記載されている。 請求項1に係る発明と引用文献1記載の発明とを対比すると,主に以下の点で相違する。 ・相違点1 請求項1に係る発明では,ソース・デバイスのイベントを検出し,前記イベントを指定するデバイス・イベント・データと,当該イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生し,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データであるのに対し,引用文献1記載の発明では,そのような構成の明記がない点。 ・相違点2 請求項1に係る発明では,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有するのに対し,引用文献1記載の発明では,そのような構成の明記がない点。 ・相違点3 請求項1に係る発明では,第1アプリケーション・タイプは第2アプリケーション・タイプとは異なるのに対し,引用文献1記載の発明では,そのような構成の明記がない点。 ・相違点4 請求項1に係る発明では,転送の間,データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持するのに対し,引用文献1記載の発明では,そのような構成の明記がない点。 以下,上記相違点1-4について検討する。 ・相違点1について イベントを検出する技術は,周知技術である。 また,イベントが発生したときに,イベント・データと,イベントの状態を他のアプリケーションに通信することも,周知技術である。 さらに,引用文献1のアプリケーションヘッダにはアプリケーションを識別する情報が付与されていることが通常であるから,引用文献1のアプリケーションヘッダにアプリケーションのタイプを特定するデータを設けることは,当業者が適宜なし得たことである。 よって,引用文献1記載の発明において,上記周知技術を適用し,ソース・デバイスのイベントを検出し,前記イベントを指定するデバイス・イベント・データと,当該イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生し,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データであるようにすることは,当業者が容易に想到し得たことである。 ・相違点2について 引用文献1記載のカプセルは,すべてのプロトコルに対応可能であるから,アプリケーションに独立しているものと推定される。 よって,引用文献1記載の発明において,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスのアプリケーション独立表現を備えているデータ構造を有するようにすることは,当業者が適宜なし得たことである。 ・相違点3について タイプの異なるアプリケーション間での通信(例えば,ワードプロセッサ,表計算やメールというタイプの場合など)は,周知技術である。 よって,引用文献1記載の発明において,上記周知技術を適用し,第1アプリケーション・タイプは第2アプリケーション・タイプとは異なるようにすることは,当業者が容易に想到し得たことである。 ・相違点4について 引用文献1記載の発明において,アプリケーションメッセージは,単に,コード化,復号化されているのみであるから,実質的に不変のまま維持されているといえる。また,そうでないとしても,コード化,復号化するか否かは,当業者が必要に応じて適宜選択し得た設計的事項であるから,引用文献1記載の発明において,コード化,復号化しないようにすることは,当業者が適宜なし得たことである。 よって,引用文献1記載の発明において,転送の間,データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持するようにすることは,当業者が適宜なし得たことである。 また,その余の相違点があるとしても,それらは,周知技術又は当業者が適宜なし得たことである。 よって,請求項1に係る発明は,引用文献1記載の発明及び周知技術に基いて,当業者が容易に想到し得たことである。 さらに,請求項2-48に係る発明において請求項1に係る発明と異なる構成は,引用文献1に記載されている構成,周知技術又は当業者が適宜なし得たことである。 したがって,請求項1-48に係る発明は,引用文献1記載の発明及び周知技術に基いて,当業者が容易に想到し得たことである。』 2 原査定の理由の判断 (1)引用文献1の記載事項 本願の優先日前に既に頒布または電気通信回線を通して公衆に利用可能とされ,原査定の理由である原審拒絶理由で引用された文献である特開2006-172454号公報(以下「引用文献1」という。)には,関連図面とともに,以下の技術的事項が記載されている。 ア 引用文献1の「この本発明の原理は,キューに入れられたアプリケーションメッセージを確実に転送するための方法,システム,およびコンピュータプログラム製品を対象とする。」(段落【0010】)との記載から,引用文献1には「アプリケーションメッセージを確実に転送するための方法」が記載されている。また,引用文献1の「図1Aでは,コンピュータシステム101は,アプリケーション102,キューチャネル103,およびキューマネージャー108を含む。(中略)アプリケーション102は,アプリケーション112へ配信するためのアプリケーションメッセージを有することがある。(後略)」(段落【0030】)との記載,「図1Bでは,コンピュータシステム111は,アプリケーション112,キューリスナー113,およびキューマネージャー118を含む。(中略)アプリケーション112は,アプリケーション102から受信するアプリケーションメッセージを有することがある。(後略)」(段落【0034】)との記載から,引用文献1には「コンピュータシステム101のアプリケーション102からのアプリケーションメッセージをコンピュータシステム111のアプリケーション112に転送する方法」が記載されていると認められる。 イ 引用文献1の「(前略)キューに入れられたアプリケーションメッセージの確実な転送を実施するためのプロトコルは,メッセージのカプセル化を利用することができる。一般に,メッセージのカプセル化は,第1のメッセージ(たとえば,アプリケーションメッセージ)(の少なくとも一部)を,第2のメッセージ(たとえば,転送メッセージ)内にラップすることを含む。いくつかの実施形態では,第1および第2のメッセージは,たとえばシンプルオブジェクトアクセスプロトコル(「SOAP」)などの同一のメッセージングプロトコルに従って構成される。(後略)」(段落【0049】)との記載から,引用文献1には「メッセージのカプセル化を利用し,アプリケーションメッセージを転送し,メッセージのカプセル化は,アプリケーションメッセージを転送メッセージ内にラップすることを含み,SOAPなどの同一メッセージングプロトコルに従って構成され」ることが記載されていると認められる。 ウ 引用文献1の「送信側転送層は,コード化されたアプリケーションメッセージをキューから外す。送信側転送層は,メッセージングプロトコル(たとえばSOAP)に従って,転送メッセージを構成する。送信側転送メッセージは,受信側コンピュータシステムを識別し,適切な場合は,対応するメッセージセッションを識別する。送信側転送層は,コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化する。送信側転送層は,その転送メッセージを受信側コンピュータシステムへの配信用として送信する。」(段落【0011】)との記載から,引用文献1には「送信側転送層は,コード化されたアプリケーションメッセージをキューから外し,受信側コンピュータを識別し,コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し,転送メッセージを受信側コンピュータシステムへ送信する」ことが記載されていると認められる。 エ 引用文献1の「送信側の保存および回送層(store and forward layer)は,転送メッセージにアクセスする。送信側の保存および回送層は,転送メッセージの転送ヘッダをコード化して,対応するコード化された転送ヘッダを作成する。」(段落【0012】)との記載から,引用文献1には「送信側の保存及び回送層は,転送メッセージの転送ヘッダを作成する」ことが記載されていると認められる。 オ 引用文献1の「受信側の保存および回送層は,メッセージングプロトコル(たとえばSOAP)に従って構成された保存および回送メッセージを受信する。受信側の保存および回送層は,コード化された転送ヘッダを,対応する転送ヘッダへと復号する。受信側の保存および回送層は,メッセージングプロトコル(たとえばSOAP)に従って,転送メッセージを構成する。受信側の保存および回送層は,転送メッセージがアプリケーションへどのように転送されるかを示すために,その転送メッセージ内に転送ヘッダを含む。保存および回送層は,コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し,その転送メッセージを受信側転送層へ送信する。」(段落【0014】)との記載から,引用文献1には「受信側の保存及び回送層は,コード化された転送ヘッダを復号し,転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め,アプリケーションメッセージを転送メッセージ内にカプセル化し,転送メッセージを受信側転送層へ送信する。」ことが記載されていると認められる。 カ 引用文献1の「受信側転送層は,そのキューから外されたメッセージを受信し,メッセージプロトコル(たとえばSOAP)に従って,デキュー応答を構成する。受信側転送層は,コード化されたアプリケーションメッセージを,そのキューから外された応答内にカプセル化する。(中略)受信側転送層は,デキュー応答をアプリケーションへ送信する。キューリスナーは,そのデキュー応答を受信する。キューリスナーは,コード化されたアプリケーションメッセージをアプリケーションメッセージへと復号し,そのアプリケーションメッセージをアプリケーションへ送信する。(後略)」(段落【0016】)との記載から,引用文献1には「受信側転送層はメッセージを受信し,コード化されたアプリケーションメッセージを復号化し,アプリケーションへ送信する。」ことが記載されていると認められる。 キ 上記ア乃至カより,引用文献1には次の発明(以下「引用発明」という。)が記載されているものと認められる。 「コンピュータシステム101のアプリケーション102からのアプリケーションメッセージをコンピュータシステム111のアプリケーション112に転送する方法であって, メッセージのカプセル化を利用し,アプリケーションメッセージを転送し,メッセージのカプセル化は,アプリケーションメッセージを転送メッセージ内にラップすることを含み,SOAPなどの同一メッセージングプロトコルに従って構成され, 送信側転送層は,コード化されたアプリケーションメッセージをキューから外し,受信側コンピュータを識別し,コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し,転送メッセージを受信側コンピュータシステムへ送信し, 送信側の保存及び回送層は,転送メッセージの転送ヘッダを作成し, 受信側の保存及び回送層は,コード化された転送ヘッダを復号し,転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め,アプリケーションメッセージを転送メッセージ内にカプセル化し, 受信側転送層はメッセージを受信し,コード化されたアプリケーションメッセージを復号化し,アプリケーションへ送信する, ことを特徴とする方法。」 (2)対比 ア 引用発明の「転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダ」を含めることは,転送の順番又は方法を記述していると解せるので「少なくとも1つのデータ・シーケンス」を含むことといえ,「アプリケーションメッセージを転送メッセージ内にカプセル化」することは,「データ・カプセルを形成」することといえ,引用発明の「メッセージのカプセル化は,アプリケーションメッセージを転送メッセージ内にラップすることを含み,SOAPなどの同一メッセージングプロトコルに従って構成」することは,SOAPなどのアプリケーションのタイプに依存しないデータ構造を用いているので,「類別されていない(untyped)データ構造を用いて表現する」ことと解せるので,引用発明における「メッセージのカプセル化は,アプリケーションメッセージを転送メッセージ内にラップすることを含み,SOAPなどの同一メッセージングプロトコルに従って構成され,送信側転送層は,(中略)コード化されたアプリケーションメッセージを転送メッセージ内にカプセル化し,(中略)受信側の保存及び回送層は,コード化された転送ヘッダを復号し,転送メッセージがアプリケーションへどのように転送されるかを示す転送ヘッダを含め,アプリケーションメッセージを転送メッセージ内にカプセル化」することと,本願発明における「前記少なくとも1つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスを含む前記プロテインを,類別されていない(untyped)データ構造を用いて表現する,ステップ」とは,後記する点で相違するものの,“少なくとも1つのデータ・シーケンスを含むデータ・カプセルを形成するステップであって,前記少なくとも1つのデータ・シーケンスを含む,類別されていない(untyped)データ構造を用いて表現する,ステップ”という点で一致する。 イ 引用発明の「コンピュータシステム101のアプリケーション102からのアプリケーションメッセージをコンピュータシステム111のアプリケーション112に転送する方法」は,本願発明における「前記データ・カプセルを,第1アプリケーション・タイプを有する第1アプリケーションから,少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにプールを介して転送するステップ」とは,後記する点で相違するものの,“前記データ・カプセルを,第1アプリケーションから,第2アプリケーションに転送するステップ”という点で一致する。 本願発明と引用発明とを対比すると以下の点で一致し,相違している。 ＜一致点＞ 少なくとも1つのデータ・シーケンスを含むデータ・カプセルを形成するステップであって,前記少なくとも1つのデータ・シーケンスを含む,類別されていない(untyped)データ構造を用いて表現する,ステップと, 前記データカプセルを第1のアプリケーションから第2のアプリケーションに転送ステップとを, を備える方法。 ＜相違点1＞ 本願発明では「ソース・デバイスによって生成又は出力されるデータ,又は前記ソース・デバイスに対応するプログラムを使用して,前記ソース・デバイスのイベントを検出」しているのに対して,引用発明はそのように特定されていない点。 ＜相違点2＞ 本願発明では「前記イベントを指定するデバイス・イベント・データであるディスクリプトと,当該イベントの状態情報であるインジェストとを備えている少なくとも1つのデータ・シーケンスを含むプロテインを発生するステップであって,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている,ステップ」であり,「プロテイン」というデータ形式であるのに対して,引用発明はそのように特定されていない点。 ＜相違点3＞ 本願発明では「データ・カプセル」を「プールを介して」転送しているノに対して、引用発明はそのように特定されていない点。 ＜相違点4＞ 本願発明では「第1アプリケーション・タイプを有する第1アプリケーション」と「少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーション」について、「前記第1アプリケーション・タイプは前記第2アプリケーション・タイプとは異なり,前記少なくとも1つのデータ・シーケンスを発生するステップを,前記第1アプリケーションによって実行する,ステップ」であるのに対して,引用発明はそのように特定されていない点 ＜相違点5＞ 本願発明では「前記転送の間,前記データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持するステップ」であるのに対して,引用発明はそのように特定されていない点。 (3)判断 (3-1)相違点1 引用発明の「アプリケーションメッセージ」を,キューに入れる契機となるイベントを検出してキューに入れることは周知技術である。また,引用発明の「アプリケーションメッセージ」を「ソース・デバイスによって生成又は出力」されるデータとすることも,「ソース・デバイスに対応するプログラムを使用」することも周知技術である。 そうすると,「ソース・デバイスによって生成又は出力されるデータ,又は前記ソース・デバイスに対応するプログラムを使用して,前記ソース・デバイスのイベントを検出」することに格別の困難性はない。 (3-2)相違点2および3 「イベントを指定するデバイス・イベント・データ」や「イベントの状態情報」をアプリケーションメッセージに含めることは当業者が適宜なし得ることである。 しかしながら,「前記イベントを指定するデバイス・イベント・データであるディスクリプトと,当該イベントの状態情報であるインジェストとを備えている少なくとも1つのデータ・シーケンスを含むプロテインを発生する」ことや,「前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている」ことは周知技術とは言えず,第1アプリケーションから第2アプリケーションへ「プールを介して」転送することも本願の優先日前に周知技術であったとは言えない。 このことにより,「大規模マルチ・プロセス相互動作を可能としかつ促進する新規プログラミング又は処理環境を含む実施形態を教示する」(段落【0007】)という効果を得ることができると解せる。 また,引用発明は「受信側コンピュータを識別し,コード化されたアプリケーションを転送メッセージ内にカプセル化」していることから,宛先を識別していると解される。そのため,本願発明のように,宛先が必ずしも特定されていない「データ・カプセル」を「プールを介して」転送することが周知技術であったとしても,前記周知技術を組み合わせる動機付けがない。 (3-3)相違点4 タイプの異なるアプリケーション間での通信は周知技術であり,第1アプリケーション・タイプを第2アプリケーション・タイプとは異なるようにすることは当業者が適宜なし得ることである。 また,その場合「データ・シーケンス」をタイプの異なるアプリケーションのうちのどのアプリケーションで実行するのかも適宜選択し得た設計的事項である。 (3-4)相違点5 引用発明の「アプリケーションメッセージ」は,第1アプリケーションから第2アプリケーションへ転送の間,コード化及び復号化されるのみであり,実質的に不変のまま維持されると解せる。そうすると,引用発明の「アプリケーションメッセージ」を「前記転送の間,前記データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持する」ことは当業者が適宜なし得ることである。 (4)小括 したがって,本願発明は,当業者が引用発明に基づいて容易に発明することができたとはいえない。 請求項28に係る発明は,データをカプセル化する方法であり,請求項29に係る発明は,実施形態の異なるものであるが,本願発明と同様に,当業者引用発明に基づいて容易に発明することができたとはいえない。 さらに,請求項2-27,30-41に係る発明は,本願発明又は請求項29に係る発明をさらに限定したものであるので,本願発明と同様に,当業者が引用発明に基づいて容易に発明することができたとはいえない。 よって,原査定の理由によっては,本願を拒絶することができない。 第4 当審の拒絶理由について 1 当審拒絶理由の概要 『この出願は,発明の詳細な説明及び特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号又は第2号に規定する要件を満たしていない。 記 請求項1-42に係る発明は,特許請求の範囲とその実質的なコピー箇所以外において,発明の詳細な説明に記載された用語と不統一のため,両者の対応関係が不明瞭であり,特許を受けようとする発明が発明の詳細な説明に記載されたものでなく,明確でない。 1.請求項1-27について (1)請求項1には「ソース・デバイスのイベントを検出する」と記載されているが,発明の詳細な説明との対応が不明である。 発明の詳細な説明の段落【0059】には「(前略)各デバイス(中略)は,それぞれのデバイス上で走っているプログラム(中略)が発生または出力をされた離散生データをプラズマ・プロテインに変換し,プラズマ・プールに貯入する。(後略)」,段落【0062】には「(前略)入力プールからイベント・プロテインを抽出できる。プロテインの抽出に続いて,デバイスCは,ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを,プロテイン・データが対応する処理イベントにおいて用いることができる。(中略)プロテインの抽出に続いて,デバイスBは,プロテイン・データが対応する処理イベントにおいて,プロテインのデータを用いることができる。」と記載されているものの, 請求項1の「ソース・デバイスのイベントを検出する」ことは,発明の詳細な説明の「デバイス上で走っているプログラムが発生または出力した離散生データ」が「発生または出力」することと解するのか,「イベント・プロテインを抽出し,ディスクリップのスローおよびプロテインのインジェストを引き出しまたは読み出す」ことと解するのかが不明である。 (2)請求項1には「前記イベントを指定するデバイス・イベント・データと,当該イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生する」と記載されているが,請求項1の「イベントを指定するデバイス・イベント・データ」「イベントの状態情報」「データ・シーケンスを発生する」ことと発明の詳細な説明との対応が不明である。 発明の詳細な説明の段落【0060】には「各プロテインは,アプリケーションが発生し,プログラム自体についての情報を特定するデータまたは出力を指定するディスクリップ・リストを収容する。(中略)プロテインのデータ・ペイロード(例えば,インジェスト)は,プログラム・イベントについての1組の有用な状態情報全体を搬送する。」と記載されているものの, 請求項1の「イベントを指定するデバイス・イベント・データ」「イベントの状態情報」を発明の詳細な説明の「ディスクリップ・リスト」「データ・ペイロード(例えば,インジェスト)」とそれぞれ解するとするのか,または,それらに含まれる「スロー(スロークス)」と解するのかが不明である。 また,請求項1の「データシーケンス」と発明の詳細な説明の「スロー」と解するのかが不明である。仮に,請求項1の「データ・シーケンス」を発明の詳細な説明の「スロー」と解すると,請求項1の「イベントを指定するデバイス・イベント・データと,当該イベントの状態情報とを備えている少なくとも1つのデータ・シーケンス」の構成が,発明の詳細な説明の「スロー」に「ディスクリップ・リスト」(又は「スロー」)と「データ・ペイロード」(又はスロー)とを備えている構成となり,そのような構成の「スロー」について,発明の詳細な説明に記載も示唆もされていない。 (3)請求項1には「データ・カプセルが,前記少なくとも1つのデータ・シーケンスを,類別されていないデータ構造を用いて表現するステップ」と記載されているが,請求項1の「類別されていないデータ構造」について,発明の詳細な説明との対応が不明である。 発明の詳細な説明の段落【0026】には「非標準プロテイン構造については,(後略)」,段落【0027】には「(前略),プロテインの標準構造では,(後略)」,段落【0034】には「(前略),類型に分けたデータをプロテイン内部に埋め込むために(中略),スローは,類型に分けた(恐らくは,集計)データの一片を表すバイトの線形シーケンスであり,(後略)」と記載されていることから,発明の詳細な説明には,「非標準プロテイン構造」や「プロテインの標準構造」や類型された「スロー」を「プロテイン」の内部に埋め込む実施例が記載されていると解される。しかし,請求項1の「類別されていないデータ構造」に関し,発明の詳細な説明に記載も示唆もされていない。 (4)請求項1には「データ・カプセルを,第1アプリケーション・タイプを有する第1アプリケーションから,少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションに転送するステップ」と記載されているが,請求項1の「データ・カプセル」を「第1アプリケーション」から「第2アプリケション」へ「転送する」ことについて,発明の詳細な説明との対応が不明である。 発明の詳細な説明の段落【0057】には「(前略)プロテインは,他のアプリケーションとプロテイン・データ・コンテンツを共有する方法として,プールに供給される。図7は,一実施形態の下において,スロークス,プロテイン,およびプールを用いたデータ交換を含む処理環境のブロック図である。この環境例は,前述のようにスロークス,プロテイン,およびプールの使用によりデータを共有する3つのデバイス(中略)を含む。これらのデバイスの各々は,3つのプール(中略)に結合されている。プール1は,それぞれのデバイスから当該プールに提供または転送された多数のプロテイン(中略)を含む(中略)。プール2は,それぞれのデバイスから当該プールに提供または転送された多数のプロテイン(中略)を含む(中略)。プール3は,それぞれのデバイスから当該プールに供給または転送された多数のプロテイン(中略)を含む(後略)」,段落【0062】「一例として,デバイスCは1つ又は複数のプロテイン(中略)をプールから抽出することができる。プロテインの抽出に続いて,デバイスCは,ディスクリップのスローおよびプロテインのインジェストから引き出したまたは読み出したプロテインのデータを,プロテイン・データが対応する処理イベントにおいて用いることができる。(後略)」と記載されているものの, 発明の詳細な説明の「プロテイン」は,「デバイス」から「プール」に転送され,「プール」から「プロテイン」を抽出し,プロテイン・データに対応する処理イベントにおいて用いているので,デバイス上のアプリケーションが「プロテイン」を「転送」するのは,「プール(レポジトリ)」のみであると解される。そのため,「プロテイン」を「第1アプリケーション」から「第2アプリケーション」に「転送」させることは記載されていない。即ち,請求項1の「データ・カプセル」を発明の詳細な説明の「プロテイン」と解すると, 請求項1の「データ・カプセル」を「アプリケーション」から他の「アプリケーション」へ「転送する」ことは,発明の詳細な説明に記載も示唆もされていない。 (6)請求項1には「前記転送の間,前記データ・カプセルの少なくとも1つのデータ・シーケンスを不変のまま維持するステップ」と記載されているが,発明の詳細な説明との対応が不明である。 発明の詳細な説明の段落【0018】には「(前略)プロテインは,それらが含むデータを不変のまま維持しつつ,プロセッサ間そしてネットワークを跨いで自然に移動できるように構成されている。」と記載されている。 請求項1の「データ・カプセル」「データ・シーケンス」を発明の詳細な説明の「プロテイン」「スロー」と解すると,「プロテイン」や「スロー」は,コード化されているのみであるから,実質的に不変のまま維持されると解することができるものの,発明の詳細な説明には「プロテイン」や「スロー」を不変のまま「維持する」という動作について,記載も示唆もされていない。更に,「転送の間」が何時から何時までを想定しているのかが不明であり,「転送の間」に「維持する」という動作に関しても,発明の詳細な説明に記載も示唆もされていない。』 2 当審拒絶理由の判断 (1)平成27年11月9日付け手続補正によって,審判請求時の請求項1に係る発明(平成25年11月25日付け手続補正で補正された請求項1に記載された発明)の「ソース・デバイスのイベントを検出するステップ」,「前記イベントを指定するデバイス・イベント・データと,当該イベントの状態情報とを備えている少なくとも1つのデータ・シーケンスを発生するステップであって,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データである,ステップ」,「前記少なくとも1つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスを,類別されていない(untyped)データ構造を用いて表現する,ステップ」,「前記データ・カプセルを,第1アプリケーション・タイプを有する第1アプリケーションから,少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションに転送するステップ」を 「ソース・デバイスによって生成又は出力されるデータ,又は前記ソース・デバイスに対応するプログラムを使用して,前記ソース・デバイスのイベントを検出するステップ」,「前記イベントを指定するデバイス・イベント・データであるディスクリプトと,当該イベントの状態情報であるインジェストとを備えている少なくとも1つのデータ・シーケンスを含むプロテインを発生するステップであって,前記デバイス・イベント・データおよび状態情報は,前記ソース・デバイスのアプリケーションに対応するタイプを有するタイプ特定データを含むスローを備えている,ステップ」,「前記少なくとも1つのデータ・シーケンスを含む前記プロテインを含むようにデータ・カプセルを形成するステップであって,該データ・カプセルが,前記少なくとも1つのデータ・シーケンスを含む前記プロテインを,類別されていない(untyped)データ構造を用いて表現する,ステップ」,「前記データ・カプセルを,第1アプリケーション・タイプを有する第1アプリケーションから,少なくとも1つの第2アプリケーション・タイプを有する少なくとも1つの第2アプリケーションにプールを介して転送するステップ」とそれぞれ補正された。 このことにより,本願発明の「ソース・デバイスのイベントを検出するステップ」と「ソースデバイスによって生成又は出力されるデータ,又は前記ソースデバイスに対応するプログラム」,「イベントを指定するデバイス・イベント・データ」と「ディスクリプト」,「イベントの状態情報」と「インジェスト」,「データシーケンス」と「プロテイン」,「転送するステップ」と「プール」との対応がそれぞれ明確になった。 また,本願発明の「類別されていない(untyped)データ構造」及び「転送の間,(中略)不変のまま維持するステップ」については,「アプリケーションに対応するタイプを有するタイプ特定データを含むスロー」と「プロテイン」の関係,「プールを介して転送するステップ」が明確になったことで,発明の詳細な説明との対応が明確となった。 よって,請求項1に係る拒絶理由は解消した。 また,当審拒絶理由おいて指摘した請求項42は削除され,請求項28及び29に係る発明は,請求項1に係る発明と同様に補正された。これにより,請求項28及び29に係る発明の拒絶理由は解消した。 請求項1に従属している請求項2-27に係る発明,及び請求項29に従属している請求項30-41に係る発明についても,拒絶理由が解消した。 第5 むすび 以上のとおり,原査定の理由によっては,本願を拒絶することはできない。また,他に本願を拒絶すべき理由を発見しない。 よって,結論のとおり審決する。 |
| 審決日 | 2016-02-04 |
| 出願番号 | 特願2010-506501(P2010-506501) |
| 審決分類 |
P
1
8・
121-
WY
(G06F)
P 1 8・ 537- WY (G06F) |
| 最終処分 | 成立 |
| 前審関与審査官 | 中野 裕二、篠塚 隆 |
| 特許庁審判長 |
辻本 泰隆 |
| 特許庁審判官 |
高木 進 戸島 弘詩 |
| 発明の名称 | プロテイン、プール、およびスロークス処理環境 |
| 代理人 | 山本 修 |
| 代理人 | 竹内 茂雄 |
| 代理人 | 小林 泰 |
| 代理人 | 上田 忠 |
| 代理人 | 小野 新次郎 |