• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1286795
審判番号 不服2012-6463  
総通号数 174 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-06-27 
種別 拒絶査定不服の審決 
審判請求日 2012-04-10 
確定日 2014-04-10 
事件の表示 特願2007- 43963「データ復号処理プログラム」拒絶査定不服審判事件〔平成20年 9月11日出願公開、特開2008-210012〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯

本件審判請求に係る出願(以下、「本願」という。)は、平成19年2月23日の出願であって、平成21年11月10日付けで審査請求がなされ、平成23年9月30日付けで拒絶理由が通知(同年10月11日発送)され、同年12月12日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年12月26日付けで拒絶査定(平成24年1月10日謄本送達)がなされた。
これに対して、本件審判請求は、「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」ことを請求の趣旨として、平成24年4月10日付けで審判請求がなされるとともに、同日付けで手続補正がなされ、同年6月12日付けで審査官により特許法第164条第3項に定める報告(前置報告)がなされ、平成25年1月24日付けで当審により特許法第134条第4項の規定に基づく審尋(同年1月29日発送)がなされ、同年3月29日付けで回答書の提出があったものである。
そして、平成25年10月9日付けで当審により拒絶理由が通知(同年10月15日発送)され、同年12月16日付けで意見書が提出されるとともに、同日付けで手続補正がなされた。


第2 本件審判請求の成否について

1.本願発明

本願の特許請求の範囲の請求項1に係る発明(以下、「本願発明」という。)は、上記平成25年12月16日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「平文データを暗号化した暗号化データと、通信されるデータのデータサイズの情報を備える通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラムにおいて、
コンピュータを、
予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第1の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第2の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する準備手段、
前記第1の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第2の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納するデータ格納手段、
前記第1の格納領域に格納された前記暗号化データから前記平文データを復号する復号手段、
として機能させることを特徴とするデータ復号処理プログラム。」


2.引用文献

(2-1)引用文献1に記載されている技術的事項及び引用発明の認定

本願の出願日前に頒布され、当審の平成25年10月9日付けの拒絶理由通知において引用された、特開2004-364022号公報(平成16年12月24日出願公開、以下、「引用文献1」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

A 「【0005】
本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御方式を提供することを目的とする。
【0006】
【課題を解決するための手段】
本発明の第一の観点によると、アプリケーション層のデータをブロック暗号化し、それをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットに分割して送信する暗号化送信手段と、トランスミッション・コントロール・プロトコルのパケットを受信して暗号化データを組み立て、アプリケーション層のデータに復号化し、メッセージ認証コードを計算して改竄されていないことを検証する受信復号化手段とを備えた暗号化通信制御方式において、前記受信復号化手段は、パケットを受信次第復号を開始し、パケットをすべて受け取った時点において改竄検証以外の可能な処理が完了するように、前記暗号化データの組み立て、データの復号化およびメッセージ認証コードの計算をスケジューリングする手段を備えたことを特徴とする暗号化通信制御方式が提供される。」

B 「【0009】
【発明の実施の形態】
図1は本発明の実施形態を示すブロック構成図である。本発明は、図1に示すような、インターネット4からサーバ5に向かうSSLトラフィックを復号化し、サーバ5からインターネット4へ出て行くトラフィックを暗号化するSSL通信装置1で実施される。このSSL通信装置1は、インターネット4からサーバ5への受信プロセスを担当する復号回路2と、サーバ5からインターネット4への送信プロセスを担当する暗号回路3とからなる。」

C 「【0011】
図3はSSLフォーマットを示す。SSLブロックは、SSLヘッダ、ペイロード、MAC(メッセージ認証コード)、パディングおよびパディング長により構成される。データ部分(ペイロード)は最大18KBまで許容されており、このデータ全体にわたってハッシュ値を計算して、SSL内のMACと比較することで改竄の有無を調べる。このSSLのデータ長に比べてTCPパケットのデータ長は短いので、ひとつのSSLデータが複数のパケットに分割されて転送されることになる。このため、受信側ではそれらのすべてのパケットを受信しないと、そのデータの信頼性を確認できないことになる。」

D 「【0014】
図7は復号回路2の詳細を示すブロック構成図である。この復号回路2は、識別部201、SSL受信バッファ202、復号化スケジューラ203、復号化処理部204、平文メモリ205、ハッシュスケジューラ206、ハッシュ計算処理部207、ハッシュメモリ208、平文送信処理部209およびセッションテーブル210を備える。
【0015】
識別部201は受信したトラフィックがどこからきたものであるかを判別する。この識別されたトラフィックをフローと呼ぶ。識別部201で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはSSL受信バッファ202に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ203でスケジュールされ、復号化処理部204で復号化処理される。ここまではパケットが到着しだい実行されるが、回線状態が悪くパケット順序が入れ替わってしまった場合は、次に来るべきパケットが来るまで復号化は実行されない。復号化処理部204による復号化処理を終えたデータは平文メモリ205に格納される。ハッシュアルゴリズムで決められた長さが復号化されると、平文メモリ205からその長さのデータがハッシュスケジューラ206によってスケジューリングされ、ハッシュ計算処理部207によりハッシュ処理される。ハッシュ計算の結果は、次のハッシュ処理のときに使うためにハッシュメモリ208に保存される。すべての処理が終わったときにハッシュメモリ208に残っている値がハッシュの計算結果である。SSLブロック(図3参照)がすべて復号化され、ハッシュ計算とMAC値が一致すれば改竄されていないことになり、平文送信処理部209によりサーバ5への送信処理が行われる。この際、SSLのために付加されたMACやパディングは取り除かれる。」

E 「【0020】
図7に示した復号回路2の動作についてさらに詳しく説明する。
【0021】
図9はSSL受信バッファ202の処理のフローチャートを示し、図10は復号化スケジューラ203の処理のフローチャートを示す。これらの処理は復号化処理部204の処理に連動する。
【0022】
SSL受信バッファ202では、TCPで運ばれてきた図3に示したようなSSLブロックを格納する。このとき、SSLヘッダから読み取れられSSLブロックの長さをSSL_Length、先頭から入れ替わることなく連続受信できているバイト数をDc、復号化スケジューラ203にすでに要求を完了している復号バイト数をDp、暗号アルゴリズムによって決まる復号化の単位となるバイト数をDdecとする。
【0023】
SSL受信バッファ202は、受信開始後、SSL暗号データをネットワークより受信し(ステップA1)、それがSSLブロックの先頭であれば(ステップA2)そのブロック用の領域を確保し、SSL_Length、Dc、Dp、Ddecの初期値を設定する(ステップA3)。連続受信できているバイト数から既に処理要求を完了しているバイト数を差し引いた値が処理単位のバイト数よりも大きければ(ステップA4)、復号化スケジューラ203に復号化処理要求を行う(ステップA5)。パケットの入れ替えなどで間があいた後でその間のデータを受信すると、連続受信バイト数が急に増えるため処理単位の数倍が一度に復号処理要求される。SSLブロックがちょうど処理単位の整数倍とは限らないため、最後の領域は連続受信バイト数がSSLブロック長と一致したところで(ステップA6)復号処理要求を行う(ステップA7)。以降、この処理を繰り返す。」

ここで、上記引用文献1に記載されている事項を検討する。

(ア)上記Aの「本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御方式を提供することを目的とする。…(中略)…アプリケーション層のデータをブロック暗号化し、それをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットに分割して送信する暗号化送信手段と、トランスミッション・コントロール・プロトコルのパケットを受信して暗号化データを組み立て、アプリケーション層のデータに復号化し、メッセージ認証コードを計算して改竄されていないことを検証する受信復号化手段とを備えた暗号化通信制御方式」との記載、上記Bの「本発明は、図1に示すような、インターネット4からサーバ5に向かうSSLトラフィックを復号化し、サーバ5からインターネット4へ出て行くトラフィックを暗号化するSSL通信装置1で実施される。このSSL通信装置1は、インターネット4からサーバ5への受信プロセスを担当する復号回路2と、サーバ5からインターネット4への送信プロセスを担当する暗号回路3とからなる。」との記載からすると、SSL通信装置の復号回路によりSSLトラフィックを復号化する暗号化通信制御方式が記載されていると解される。また、上記Cの「図3はSSLフォーマットを示す。SSLブロックは、SSLヘッダ、ペイロード、MAC(メッセージ認証コード)、パディングおよびパディング長により構成される。データ部分(ペイロード)は最大18KBまで許容されており、このデータ全体にわたってハッシュ値を計算して、SSL内のMACと比較することで改竄の有無を調べる。」との記載からすると、SSLトラフィックはSSLブロックデータにより送受信され、該SSLブロックは、平文データを暗号化したデータ部分(ペイロード)と、SSLヘッダと、MAC(メッセージ認証コード)と、パディングなどにより構成されることは明らかであるから、引用文献1には、
「平文データを暗号化したデータ部分(ペイロード)と、SSLヘッダと、MAC(メッセージ認証コード)と、パディングとを含むSSLブロックを復号回路で受信して復号化する処理を実行する暗号化通信制御方式」
が記載されていると解される。

(イ)上記Dの「図7は復号回路2の詳細を示すブロック構成図である。この復号回路2は、識別部201、SSL受信バッファ202、復号化スケジューラ203、復号化処理部204、平文メモリ205、ハッシュスケジューラ206、ハッシュ計算処理部207、ハッシュメモリ208、平文送信処理部209およびセッションテーブル210を備える。 …(中略)…。識別部201で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはSSL受信バッファ202に入り」との記載、上記Eの「SSL受信バッファ202では、TCPで運ばれてきた図3に示したようなSSLブロックを格納する。…(中略)…。SSL受信バッファ202は、受信開始後、SSL暗号データをネットワークより受信し(ステップA1)、それがSSLブロックの先頭であれば(ステップA2)そのブロック用の領域を確保し」との記載からすると、復号回路は受信したSSLトラフィックであるSSLブロックを格納するSSL受信バッファを備え、SSLブロックをネットワークより受信し、受信したデータがSSLブロックの先頭であればSSL受信バッファにそのブロック用の領域を確保すると解されるから、引用文献1には、
「復号回路を、ネットワークよりSSLブロックを受信し、それがSSLブロックの先頭であれば、SSL受信バッファにそのブロック用の領域を確保し、受信したSSLブロックを前記SSL受信バッファに格納する手段として機能させること」
が記載されていると解される。

(ウ)上記Dの「識別されたトラフィックはSSL受信バッファ202に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ203でスケジュールされ、復号化処理部204で復号化処理される。…(中略)…。復号化処理部204による復号化処理を終えたデータは平文メモリ205に格納される。」の記載からすると、復号回路の復号化処理部は、SSL受信バッファに格納されたSSLブロックを平文に復号化すると解されるから、引用文献1には、
「復号回路を、SSL受信バッファに格納されたSSLブロックを復号化処理部で平文に復号化する手段として機能させること」
が記載されていると解される。

以上、(ア)乃至(ウ)で指摘した事項から、引用文献1には、次の発明(以下、「引用発明」という。)が記載されているものと認める。

「平文データを暗号化したデータ部分(ペイロード)と、SSLヘッダと、MAC(メッセージ認証コード)と、パディングとを含むSSLブロックを復号回路で受信する処理を実行する暗号化通信制御方式であって、
前記復号回路を、
ネットワークよりSSLブロックを受信し、それがSSLブロックの先頭であれば、SSL受信バッファにそのブロック用の領域を確保し、受信したSSLブロックを前記SSL受信バッファに格納する手段、
前記SSL受信バッファに格納されたSSLブロックを復号化処理部で平文に復号化する手段、
として機能させることを特徴とする暗号化通信制御方式。」

(2-2)引用文献2に記載されている技術的事項

本願の出願日前に頒布され、当審の平成25年10月9日付けの拒絶理由通知において引用された、特開2004-140546号公報(平成16年5月13日出願公開、以下、「引用文献2」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

F 「【0040】
サービス情報管理テーブル600の更新日時の方が新しければ、サービス情報ファイル38から該当するサービス情報(コンテンツデータ)を読出し、コンテンツID、更新日時、データ長等の情報をヘッダ部に含むデータパケットを生成して、情報チャネルf2xに送信する(412)。上記判定と更新されたサービス情報の送信は、更新データ要求メッセージRQ2で指定された全てのコンテンツIDについて繰り返され、送信すべきサービス情報が無くなった時、送信完了通知C3を送信し(413)、移動体システムからの更新完了応答の受信を待つ(414)。」

(2-3)引用文献3に記載されている技術的事項

本願の出願日前に頒布され、当審の平成25年10月9日付けの拒絶理由通知において引用された、特開2006-189937号公報(平成18年7月20日出願公開、以下、「引用文献3」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

G 「【0024】
本実施の形態においては、バッファ制御回路13は、受信バッファ12における各データタイプ毎の領域の割り当てを変更することができるようになっている。図1の斜線部は各データタイプに割り当てられた領域の初期値を示している。領域12a内の無地の領域PHは、データタイプPHに対して初期状態から増大させた領域を示している。また、領域12b内の無地の領域PDは、データタイプPDに対して初期状態から増大させた領域を示している。
【0025】
バッファ制御回路13は、受信したTLPのデータタイプの統計、即ち、トラフィックの統計を求める。バッファ制御回路13は、求めたトラフィック統計に基づいて、受信バッファ12の各領域の容量を増大させるか否かの決定及び増大させる量の決定を行うようになっている。」

H 「【0028】
受信装置11はフロー制御の初期化時において、送信装置1からのデータ伝送に最低限必要な容量を受信バッファ12に設定する。この場合には、バッファ制御回路13は、データタイプ毎の伝送量の予測が可能であれば、その予測に従って特定のデータタイプのクレジット値及び受信バッファの確保領域を他のデータタイプのものよりも大きく設定してもよい。バッファ制御回路13は、設定した初期値のクレジット値をDLLPによって送信装置1に伝送する(ステップS1)。」

(2-4)引用文献4に記載されている技術的事項

本願の出願日前に頒布され、当審の平成25年10月9日付けの拒絶理由通知において引用された、特開2001-306482号公報(平成13年11月2日出願公開、以下、「引用文献4」という。)には、関連する図面とともに、以下の技術的事項が記載されている。
(当審注:下線は、参考のために当審で付与したものである。)

J 「【0018】
【発明の実施の形態】以下、図を用いて本発明の実施の形態について説明する。なお、これにより本発明が限定されるものではない。図1は、本発明の一実施形態に係る入出力制御装置100の構成図である。この入出力制御装置100は、ファブリックFaからのフレームを受信しそのフレームをヘッダ部とデータ部とに分けるデータ入力レジスタ111と、前記ヘッダ部を格納するヘッダ用受信バッファ103と、前記データ部を格納するデータ用受信バッファ102と、Virtual CircuitがDormant状態であるときの前記データ部の書き込みアドレス4を与えるDormant用書き込みアドレスレジスタ107_dと、Virtual CircuitがLive状態であるときの前記データ部の書き込みアドレス4を与えるLive用書き込みアドレスレジスタ107_lと、前記ヘッド部受信バッファ103に格納したヘッダ部を参照してVC_ID1を読み出して該当するVirtual Circuit状態を示すVC状態2を出力するVC管理メモリ105と、…(中略)…、前記データ用受信バッファ102のデータ読み出しアドレスを与える読み出しアドレスレジスタ108と、前記データ用バッファ102の使用状況を管理するためのフラグであるバッファ使用状況管理フラグ106と、…(中略)…、前記バッファ制御回路104と前記下位デバイス間インタフェース制御回路112を制御しデータ転送全体を制御する入出力制御回路101とを具備して構成されている。」


3.対比

本願発明と引用発明とを対比する。

(3-1)引用発明の「平文データを暗号化したデータ部分(ペイロード)」は本願発明の「平文データを暗号化した暗号化データ」に相当し、引用発明の「平文データを暗号化したデータ部分(ペイロード)」を含む「SSLブロック」は、本願発明の「平文データを暗号化した暗号化データ」を有する「通信用暗号化データ」に対応する。そして、引用発明の「SSLヘッダ」は、引用文献1の上記Eの「SSL受信バッファ202では、TCPで運ばれてきた図3に示したようなSSLブロックを格納する。このとき、SSLヘッダから読み取れられSSLブロックの長さをSSL_Length」との記載からすると、「SSLブロック」に関するデータサイズの情報を含んでいることから、本願発明の「通信されるデータのデータサイズの情報を備える通信用データ」に対応し、両者はともに、“データサイズの情報を含む通信用データ”である点で共通するといえる。
また、引用文献1の上記Bの「このSSL通信装置1は、インターネット4からサーバ5への受信プロセスを担当する復号回路2」との記載、上記Dの「図7は復号回路2の詳細を示すブロック構成図である。この復号回路2は、識別部201、SSL受信バッファ202、復号化スケジューラ203、復号化処理部204、平文メモリ205、ハッシュスケジューラ206、ハッシュ計算処理部207、ハッシュメモリ208、平文送信処理部209およびセッションテーブル210を備える。」との記載からすると、引用発明の「暗号化通信制御方式」は、コンピュータを含む「復号回路」が、復号処理プログラムである「受信プロセス」を実行しているといえる。
してみると、引用発明の「平文データを暗号化したデータ部分(ペイロード)と、SSLヘッダと、MAC(メッセージ認証コード)と、パディングとを含むSSLブロックを復号回路で受信する処理を実行する暗号化通信制御方式」と、本願発明の「平文データを暗号化した暗号化データと、通信されるデータのデータサイズの情報を備える通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラム」は、ともに、“平文データを暗号化した暗号化データと、データサイズの情報を含む通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラム”である点で共通するといえる。

(3-2)引用発明の「復号回路」は復号化の処理を実行することから、本願発明の「コンピュータ」に対応する。また、引用発明の「SSL受信バッファ」は、「SSLブロック」を格納するために「復号回路」が備えていることから、本願発明の「コンピュータが備える一時記憶手段」に相当し、両者はともに、暗号化データを受信すると格納領域を準備する点で共通するといえる。
してみると、引用発明の「ネットワークよりSSLブロックを受信し、それがSSLブロックの先頭であれば、SSL受信バッファにそのブロック用の領域を確保し」と、本願発明の「予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第1の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第2の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する準備手段」は、ともに、“コンピュータが備える一時記憶手段に格納領域を準備する”点で共通するといえる。

(3-3)引用発明の「復号回路」は受信した「SSLブロック」を「SSL受信バッファ」の確保した領域に格納することから、引用発明の「受信したSSLブロックを前記SSL受信バッファに格納する」と、本願発明の「前記第1の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第2の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納するデータ格納手段」は、ともに、“受信した通信用暗号化データを格納領域に格納する”点で共通するといえる。

(3-4)引用発明の「復号回路」は、暗号化データを含む「SSLブロック」を平文に復号化することから、引用発明の「前記SSL受信バッファに格納されたSSLブロックを復号化処理部で平文に復号化する」と、本願発明の「前記第1の格納領域に格納された前記暗号化データから前記平文データを復号する復号手段」は、ともに、“格納領域に格納された暗号化データから平文データを復号する”点で共通するといえる。

以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。

(一致点)

「平文データを暗号化した暗号化データと、データサイズの情報を含む通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラムにおいて、
コンピュータを、
前記コンピュータが備える一時記憶手段に格納領域を準備する手段、
受信した前記通信用暗号化データを前記格納領域に格納する手段、
前記格納領域に格納された暗号化データから平文データを復号する手段、
として機能させることを特徴とするデータ復号処理プログラム。」

(相違点1)

通信用暗号化データに含まれる通信用データに関して、本願発明の「通信用データ」は通信されるデータのデータサイズの情報を備えているのに対して、引用発明の「SSLヘッダ」は「SSLブロック」に関するデータサイズの情報を含んでいるが、通信されるデータのデータサイズかどうかは不明である点。

(相違点2)

通信用暗号化データの格納領域の準備に関し、本願発明では、「予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第1の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第2の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する」のに対して、引用発明では、「ネットワークよりSSLブロックを受信し、それがSSLブロックの先頭であれば、SSL受信バッファにそのブロック用の領域を確保」するものの、領域の確保のしかたについて詳細が不明である点。

(相違点3)

通信用暗号化データの格納に関し、本願発明では、「前記第1の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第2の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納」し、「前記第1の格納領域に格納された前記暗号化データから前記平文データを復号する」のに対して、引用発明では、「受信したSSLブロックを前記SSL受信バッファに格納」し、「前記SSL受信バッファに格納されたSSLブロックを復号化処理部で平文に復号化する」ものの、「SSL受信バッファ」への格納のしかた、復号化される「SSLブロック」の「SSL受信バッファ」での格納領域についての詳細が不明である点。


4.当審の判断

上記相違点1乃至相違点3について検討する。

(4-1)相違点1について

データ長をヘッダ部に含むデータパケットを生成して、通信されるデータのデータサイズの情報を含む通信用データを送受信する旨の技術は、例えば、引用文献2(上記F参照)に記載されているように、本願出願前にはデータ通信の技術分野における周知の技術的事項であった。
そして、引用発明においても、「SSLヘッダ」は「SSLブロック」に関するデータサイズの情報を含んでいることから、復号回路で受信するSSLブロックの中に通信されるデータのデータサイズの情報を含むようにすること、すなわち、上記相違点1に係る構成とすることは、当業者が容易に想到し得たことである。

よって、相違点1は格別なものではない。

(4-2)相違点2及び相違点3について

引用発明において、復号回路のSSL受信バッファに格納するSSLブロックは、平文データを暗号化したデータ部分(ペイロード)以外に、SSLヘッダ、MAC(メッセージ認証コード)、パディングなどの暗号化方式により規定されるデータを含んでおり、復号回路はネットワークよりSSLブロックを受信し、それがSSLブロックの先頭であれば、SSL受信バッファにそのブロック用の領域を確保していることから、平文データを暗号化したデータ部分以外の暗号化方式により規定されるデータのサイズも考慮して、格納領域の確保を行っているといえる。
また、引用文献3(上記G,H参照)に記載されているように、データ伝送の受信装置における受信バッファの制御について、受信したデータタイプ毎に初期状態の領域のほか、増大させた領域を割り当て、必要容量を確保する旨の技術は、本願出願前にはデータ通信技術の分野における周知の技術的事項であった。さらに、引用文献4(上記J参照)に記載されているように、入出力制御装置における受信バッファを、ヘッダ部を格納するヘッダ用受信バッファと、データ部を格納するデータ用受信バッファに分けて構成する旨の技術も、本願出願前にはデータ通信技術の分野における周知の技術的事項であった。
してみると、暗号化方式は一種のデータタイプとみることができるから、引用発明においても、SSL受信バッファにそのブロック用の領域を確保するに当たって当該周知技術を適用し、適宜、平文データのサイズに基づいてSSL受信バッファに予め準備される第1の格納領域以外に、暗号化方式により規定されるデータを格納する増大した第2の格納領域を増加し得るサイズに基づいて準備し、前記第1の格納領域に格納した暗号化したデータ部分(ペイロード)は平文に復号化し、前記第2の格納領域には、データサイズの情報を含むSSLヘッダを格納すること、すなわち、上記相違点2及び相違点3に係る構成とすることは、当業者が容易に想到し得たことである。

よって、相違点2及び相違点3は格別なものではない。

上記で検討したごとく、相違点1乃至相違点3は格別のものではなく、そして、この相違点を総合的に勘案しても、本願発明の奏する作用効果は、上記引用発明及び引用文献2乃至4に記載の周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。


5.むすび

以上のとおり、本願の請求項1に係る発明は、特許法第29条第2項の規定により特許を受けることができないものであるから、その余の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。

よって、結論のとおり審決する。
 
審理終結日 2014-01-22 
結審通知日 2014-01-28 
審決日 2014-02-14 
出願番号 特願2007-43963(P2007-43963)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 和田 財太  
特許庁審判長 山崎 達也
特許庁審判官 辻本 泰隆
田中 秀人
発明の名称 データ復号処理プログラム  
代理人 服部 毅巖  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ