• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1306184
審判番号 不服2012-22871  
総通号数 191 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-11-27 
種別 拒絶査定不服の審決 
審判請求日 2012-11-19 
確定日 2015-09-30 
事件の表示 特願2006-269569「保安方法及びシステム、その方法を記録したコンピュータで読み取り可能な記録媒体」拒絶査定不服審判事件〔平成19年 4月19日出願公開,特開2007-102785〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2006年9月29日(パリ条約による優先権主張外国庁受理2005年9月30日(以下,「優先日」という。),韓国)を出願日とする出願であって,その手続の経緯は以下のとおりである。

平成21年 9月 7日 :出願審査請求書の提出
平成24年 2月14日付け :拒絶理由の通知
平成24年 6月21日 :意見書,手続補正書の提出
平成24年 7月11日付け :拒絶査定
平成24年11月19日 :審判請求書の提出
平成26年 2月27日付け :拒絶理由の通知(当審)
平成26年 6月 4日 :意見書,手続補正書の提出
平成26年10月14日付け :拒絶理由(最後)の通知(当審)
平成27年 1月21日 :意見書,手続補正書の提出


第2 平成26年2月27日付け拒絶理由通知書

上記平成26年2月27日付けで当審より通知した拒絶理由の概要は以下のとおりである。

『 理 由

1)この出願の下記の請求項に係る発明は,その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。

2)この出願は,明細書,特許請求の範囲及び図面の記載が下記の点で,特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしていない。

記

(理由1)
請求項1-13:
引用文献1,2

[引用文献等一覧]
1.特開2003-258788号公報
2.特開2002- 72874号公報

備考:

(1)引用文献に記載されている事項及び引用発明

＜引用文献1＞
引用文献1の特に段落【0013】?【0025】の記載から,引用文献1には,
互いに通信可能に接続された,ユーザ端末102と,ユーザ端末102からのユーザIDをデータベース105で管理する登録局サーバ104と,認証局サーバ107とが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法において,
前記ユーザ端末102は新たな公開鍵の登録要求を行う必要があると判断した時点で,前記ユーザIDを前記登録局サーバ104に送信するステップと,
前記登録局サーバ104は,受信した前記ユーザIDをキーとして前記データベース105を検索して,前記ユーザIDが存在する場合には,新たな公開鍵を前記ユーザIDに対応づけて前記前記データベース105に記憶し,前記ユーザ端末102から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバ107に送信し,前記認証局サーバ107から送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末Aに前記新たな公開鍵に対するデジタル証明書を送信するステップと,
前記新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末102は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップと,を含む公開鍵暗号方式を利用した鍵管理方法。(以下,「引用発明1」という。)が記載されていると解される。

＜引用文献2＞
引用文献2の特に段落【0003】?【0005】の記載から,引用文献2には,
送信元では,送信するデータをメッセージ要約関数を使って圧縮し,この圧縮文を秘密鍵で暗号化することで認証子(電子署名)を生成し,この認証子と送信するデータとからなる署名文を作成して,それを送信先に送信し,一方,送信先は,この送られてきた署名文から認証子を抽出して,それを公開鍵で復号することで復号化圧縮文を取得すると共に,送られてきた前記署名文の本体部分(送信データ部分)をメッセージ要約関数を使って圧縮することで圧縮文を生成し,この圧縮文と復号により得た前記復号化圧縮文とを比較して,両者が一致するときには,送られてきたデータが第三者により改竄されていないと判断し,一致しないときには,送られてきたデータが第三者により改竄されたと判断すること,すなわち,デシタル署名が付加されたデータを送信元から送信先に送信し,送信先では,公開鍵を利用して前記送信されてきたデータを認証すること,が記載されていると解される。

(2)請求項1について
本願の請求項1に係る発明(以下,「本願発明」という。)と,引用発明1とを比較すると,引用発明1の「互いに通信可能に接続された,ユーザ端末102と,ユーザ端末102からのユーザIDをデータベース105で管理する登録局サーバ104と,認証局サーバ107とが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法」は,本願発明の「保安維持のための方法」に相当している。
また,引用発明1の「ユーザ端末102」及び「登録局サーバ104」は,本願発明の「クライアント」及び「サーバ」にそれぞれ相当しており,引用発明1の「ユーザID」と,本願発明の「現在公開キー情報」は,共に「クライアント」を識別するための情報であるといえるから,引用発明1の「前記ユーザ端末102は新たな公開鍵の登録要求を行う必要があると判断した時点で,前記ユーザIDを前記登録局サーバ104に送信するステップ」と,本願発明の「クライアントの現在公開キー情報をサーバへ伝送するステップ」とは,共に「クライアントを識別する識別情報をサーバへ伝送するステップ」である点で共通するといえる。
また,引用発明1の「前記新たな公開鍵に対するデジタル証明書」には,「新たな公開鍵」情報が含まれていることは明らかであるから,引用発明1の「前記登録局サーバ104は,受信した前記ユーザIDをキーとして前記データベース105を検索して,前記ユーザIDが存在する場合には,新たな公開鍵を前記ユーザIDに対応づけて前記前記データベース105に記憶し,前記ユーザ端末102から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバ107に送信し,前記認証局サーバ107から送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末Aに前記新たな公開鍵に対するデジタル証明書を送信するステップ」と,本願発明の「前記サーバは,前記現在公開キー情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し,前記最新の認証情報をクライアントへ伝送するステップ」とは,共に,「前記サーバは,前記クライアントを識別する識別情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報を含む最新の認証情報を生成し,前記最新の認証情報をクライアントへ伝送するステップ」である点で共通するといえる。
また,引用発明1の「前記新たな公開鍵に対する公開鍵のデジタル証明書を受け取った前記ユーザ端末102は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ」と,本願発明の「前記認証が成功する場合,前記最新の認証情報を利用して前記現在公開キー情報をアップデートするステップ」とは,共に,「前記最新の認証情報を利用して前記現在公開キー情報をアップデートするステップ」である点で共通するといえる。

したがって,本願発明と,引用発明1とは,以下の点で相違している。

＜相違点1＞
「クライアントを識別する識別情報」が,本願発明は,「現在公開キー情報」であるのに対して,引用発明1では,「ユーザID」である点。

＜相違点2＞
本願発明は,「最新公開キー情報とデジタル署名を含む最新の認証情報を生成し,前記最新の認証情報をクライアントへ伝送」するように構成しているのに対して,引用発明1は,「前記認証局サーバ107から送られてくる,前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末Aに前記新たな公開鍵に対するデジタル証明書を送信」している点。

＜相違点3＞
「前記最新の認証情報を利用して前記現在公開キー情報をアップデート」する条件として,本願発明は,「前記現在公開キー情報を利用して前記最新の認証情報を認証」できた場合であるのに対して,引用発明1は,この点が明記されていない点。

上記相違点に対する当審の判断は以下のとおりである。

＜相違点1について＞
クライアントを識別する識別情報として,本願発明のように「現在公開キー情報」を用いるか,あるいは,引用発明1のように「ユーザID」を用いるかは当業者がその必要に応じて適宜選択し得るものであるから,引用発明1における「ユーザID」を「現在公開キー情報」に代えて本願発明のように構成すること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点1は格別なものではない。

＜相違点2について＞
引用発明1における「前記認証局サーバ107から送られてくる,前記新たな公開鍵に対するデジタル証明書」には,新たな公開鍵情報とその認証情報が含まれていることは自明であるから,相違点2は実質的な相違点ではないが,仮に相違していたとしても,一般に,最新公開キー情報とデジタル署名を含む最新の認証情報を生成し,前記最新の認証情報として相手側に送信することは,従来周知の技術事項であるから,引用発明1にこのような従来周知の技術思想を適用して,本願発明のように構成すること,すなわち,上記相違点2に係る構成とすることは,当業者が容易に想到し得たことである。
よって,相違点2は格別なものではない。

＜相違点3について＞
引用発明1において,「受け取った前記新たな公開鍵に対するデジタル証明書を上書きする」のは,「前記新たな公開鍵に対するデジタル証明書」の認証が済んだ後であることは自明の技術事項であるから,上記相違点3は実質的な相違点ではない。
また,仮に,相違しているとしてもこの点は当業者が適宜なし得る事項に過ぎない。
よって,相違点3は格別なものではない。

(3)請求項2について
送信元では,送信するデータをメッセージ要約関数を使って圧縮し,この圧縮文を秘密鍵で暗号化することで認証子(電子署名)を生成し,この認証子と送信するデータとからなる署名文を作成して,それを送信先に送信し,一方,送信先は,この送られてきた署名文から認証子を抽出して,それを公開鍵で復号することで復号化圧縮文を取得すると共に,送られてきた前記署名文の本体部分(送信データ部分)をメッセージ要約関数を使って圧縮することで圧縮文を生成し,この圧縮文と復号により得た前記復号化圧縮文とを比較して,両者が一致するときには,送られてきたデータが第三者により改竄されていないと判断し,一致しないときには,送られてきたデータが第三者により改竄されたと判断すること,すなわち,デシタル署名が付加されたデータを送信元から送信先に送信し,送信先では,公開鍵を利用して前記送信されてきたデータを認証することは,上記引用文献2に記載されているように従来周知の技術事項であるから,本願の請求項2に係る発明は,引用発明1及び引用文献2に記載されている従来周知の技術事項から,当業者が容易に想到し得たことである。

…(中略)…

(理由2)

(1)特許法第36条第4項1号について

a.請求項1-13に関して,「現在公開キー情報」および,「現在公開キー情報」から生成される「最新公開キー情報」が発明特定事項に含まれ,これら発明特定事項について,発明の詳細な説明の0021段落には,「認証情報伝送モジュール110は,メモリ151に保存されている認証情報を,通信モジュール140を通じてサーバ200へ伝送し,サーバ200から最新の認証情報を受信する。認証情報150は,公開キーについての情報を含むことが望ましい。また,サーバ200は,既存の公開キーをアップデートするための情報として,最新の公開キー情報と,この公開キー情報についてのデジタル署名とを含む最新の認証情報を伝送する。このとき,サーバ200は,クライアント100から受信した認証情報を利用してクライアントを確認し,クライアントのための認証情報を検索して最新の認証情報を生成した後に送信する。」が記載され,0024段落には,「サーバは,クライアントから受信した認証情報を利用して,クライアントのための最新の認証情報を生成して伝送する(S204)。このステップで,サーバは,クライアントの認証情報を基盤にクライアントの現在状態を把握し,クライアントが認証できる情報を検索して伝送する。このとき,サーバが伝送する最新の認証情報は,クライアントのための最新の公開キー情報と,この公開キー情報についてのデジタル署名とを含むことが望ましい。」が記載されているが,どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか,そのための情報処理が不明である。
すなわち,発明の詳細な説明の0029段落には,「クライアントは,自身の公開キーを利用して受信された情報のデジタル署名を検証し(S506),受信された情報が安全であると判断される場合にのみ,自身の公開キーと最新の公開キーとを比較してアップデートの如何を決定する。アップデートが必要であると判断されれば,自身の公開キーを最新の公開キーに修正する(S508)。受信された情報の認証に失敗するか,または最新の認証情報に新たな内容がないと判断されれば,公開キーをアップデートせずに次のステップを行う。」と記載されており,「最新の公開キー」を含む「最新の認証情報」について「最新の認証情報に新たな内容がないと判断され」る場合が発生すると解されるが,0021段落や0024段落に記載の,現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報の生成をどのような処理で実行すると,このような「最新の認証情報に新たな内容がないと判断され」る状況が発生するのか不明であり,理解することができない。
したがって,出願時の技術常識を考慮しても,発明の詳細な説明は,当業者が請求項1-13に係る発明の実施をすることができる程度に明確かつ十分に記載したものでない。

…(後略)… 』


第3 本願発明の進歩性について

1 本願発明

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

「 保安維持のための方法において,
クライアントの現在公開キー情報を含む認証情報をサーバへ伝送するステップと,
前記サーバは,前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し,前記最新の認証情報をクライアントへ伝送するステップと,
前記現在公開キー情報を利用して前記デジタル署名を解読し,前記最新の認証情報を認証するステップと,
前記認証が成功する場合,前記最新の認証情報を利用して前記現在公開キー情報を含む前記最新の認証情報に前記認証情報をアップデートするステップと,を含むことを特徴とする保安方法。」


2 引用例

(1) 引用例1に記載されている技術的事項および引用発明

ア 本願の優先日前に頒布され,当審からの上記平成26年2月27日付け拒絶理由通知において引用された,特開2003-258788号公報(平成15年9月12日出願公開,以下,「引用例1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【0012】この発明は,このような課題に着目してなされたもので,前記デジタル証明書の余分な発行などにかかる費用や余分な公開鍵などの管理に対する負担を減少させつつ,現用の公開鍵失効後の新規公開鍵への切り替えが迅速に行える仕組みを実現する,登録局サーバ104の運用方法を提供することを目的とする。
【0013】
【課題を解決するための手段】上記目的を達成する本発明の登録局サーバの運用方法は,互いに通信可能に接続された,ユーザ端末と認証局サーバと登録局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法における前記登録局サーバの運用方法であって,前記登録局サーバは,ユーザIDをデータベースで管理し,あるユーザ端末Aから新たな公開鍵の登録要求を受信して,これに付帯して受信したユーザIDをキーとして前記データベースを検索し,ユーザIDが存在する場合には,新たな公開鍵を前記ユーザIDに対応づけて前記データベースに記憶し,ユーザ端末Aあるいは他のユーザ端末から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる,前記新たな公開鍵に対するデジタル証明書を受信して,ユーザ端末Aに前記デジタル証明書を送信することを特徴とする。」

B 「【0014】
【発明の実施の形態】以下,本発明の実施の形態を,図を参照しながら詳細に説明する。
【0015】図1は,ネットワーク101のような通信手段を利用した「公開鍵暗号方式」による鍵管理方法の全体構成を示している。
【0016】ユーザ100が操作するユーザ端末102,103と,登録局106での登録局サーバ104と,認証局108での認証局サーバ107とが,運用されている。登録局サーバ104と認証局サーバ107とは,同一局の異なる部門にあって,LANによって結ばれていても良い。また,各サーバは複数台が協調して,一つのサーバとして機能する構成でもよい。」

C 「【0019】＜第1実施例＞登録局サーバ104では,鍵データベース105が稼働する。このデータベース105には,ユーザIDを含むユーザ情報,「公開鍵暗号方式」に利用される現用の鍵ペア,その現用公開鍵に対するデジタル証明書,予備の鍵ペア,その予備公開鍵に対するデジタル証明書,及び新規鍵に対する審査情報等が,関連づけて記憶されている。
【0020】前述したように,秘密鍵や公開鍵は,使用頻度や時間経過とともに次第に危殆化が進行していく。ユーザ100はその危殆化の進行度を,例えば,使用頻度などから判断し,ある時点で,予備鍵を新たに準備する時期であると判断する。その時点で,ユーザ100は,ユーザ端末102を通じて登録局サーバ104が開設しているホームページ500にアクセスし,それぞれ予備公開鍵と予備秘密鍵として,新たな公開鍵と新たな秘密鍵の準備を行う。これにより,危殆化と関係なく現用公開鍵生成時から予備鍵を準備しておく必要性がなくなり,余分な予備鍵の管理負担を軽減させることができるだけでなく,予備鍵の有効期間は鍵生成時から始まるため,有効期間の無駄な消費を防ぐことができる。また,現用公開鍵は常時一つであり,複数の公開鍵を所有することによる管理負担やデジタル証明書の発行費用などを減少させることができる。」

D 「【0021】図2は,第1実施例の運用方法に関するフローチャートである。図5に,登録局サーバ104のホームページ500の画面の一例を示す。
【0022】図2に示すように,登録局サーバ104のホームページ500において,ユーザ100がユーザ端末102から「予備公開鍵の登録-予備公開鍵はもっていない-今すぐに生成して保管しておく」の各チェック欄501,502,505をクリックし,送信ボタン509をクリックすることによって登録局サーバ104に送信すると(ｓ201),登録局サーバ104は,送信されたユーザIDをキーとして,鍵データベース105を検索し,保管されているユーザ情報や現用公開鍵等の情報を得る。一方で前記ユーザは,郵送などにより前述した審査に必要な登記簿や印鑑証明書等の書類を登録局サーバ104に提出する。登録局106では,それらの情報に基づき,本人確認や申請情報の真正性確認を含む審査が行われる。なお,この審査の過程が,公開鍵のデジタル証明書の発行過程全体の中で,最も時間のかかるステップである。審査が合格になると,登録局サーバ104は,鍵ペアを生成し(ｓ202),鍵データベース105にユーザIDと関連づけて保管する(ｓ203)。この時,新たに生成した秘密鍵をユーザ端末102に送信してもよい。
【0023】ユーザは,現用秘密鍵の危殆化が過度に進行したと判断すると,ユーザ端末102を通じて同じホームページ500にアクセスし,「予備公開鍵の使用開始」のチェック欄507をクリックすることにより,今度は予備公開鍵の使用開始要求を送信する(ｓ204)。この要求を受信した登録局サーバ104は,認証局サーバ107に,ユーザIDと関連づけた公開鍵,現用公開鍵の失効要求とともに,公開鍵のデジタル証明書の発行要求を送信する(ｓ205)。
【0024】つぎに,認証局サーバ107が,現用公開鍵のデジタル証明書を失効させる一方,要求された公開鍵のデジタル証明書を発行し,登録局サーバ104に送信する(ｓ206)と,これを受信した登録局サーバ104は,ユーザ端末102にその公開鍵に対するデジタル証明書を送信し(ｓ207),鍵データベース105にユーザIDと対応づけてユーザ情報及び公開鍵デジタル証明書を記憶する(ｓ208)。また,秘密鍵を登録局サーバ104が生成した場合には,この段階で秘密鍵を一緒に送信してもよい。
【0025】このようにして前記公開鍵のデジタル証明書を受け取ったユーザ端末102は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取ったデジタル証明書を上書きする。」

E 「【0030】＜第3実施例＞登録局サーバ104において,予備公開鍵をあらかじめ用意しておくのではなく,登録局106による審査だけを予め済ませておき,新規公開鍵への切り替えの際に,新たに予備公開鍵を生成するようにしてもよい。鍵生成は時間のかかる処理ではなく,審査は鍵の切り替え時にすでに終了しているため,この場合も新規公開鍵への切り替えは迅速に行われる。以下,図4のフローチャートとともに,第2実施例について詳述する。
【0031】この実施例では,ユーザ100が,予備鍵ペアを準備する時期であると判断した時点で,ユーザ端末102を通じて登録局サーバ104のホームページ500にアクセスし,ユーザ端末102において,「予備公開鍵の登録-予備公開鍵は持っていない-現用鍵からの切り替えの直前に生成する」の各チェック欄501,503,506という組み合わせをクリックし,ユーザ情報と共に入力情報を送信する(ｓ401)。登録局106は,ユーザ端末102から登録局サーバ104に送信されたユーザ情報に基づいて,上記と同様に審査を行う。審査が合格になると,登録局サーバ104は,ユーザIDと関連づけて,送信された登録要求を記録する(ｓ402)。これにより,第1実施例のときと同様,危殆化と関係なく現用公開鍵生成時から予備鍵を準備しなければならない必要性がなくなり,余分な予備鍵の管理負担を減少させることができるだけでなく,予備鍵の有効期間の開始は生成時から始まるため,無駄な有効期限の消費を防ぐことができる。また,現用公開鍵は常時一つであり,複数の公開鍵を所有することによる管理負担やデジタル証明書の発行費用を減少させることができる。」

イ ここで,上記引用例1に記載されている事項を検討する。

(ア) 上記Aの「この発明は,このような課題に着目してなされたもので,前記デジタル証明書の余分な発行などにかかる費用や余分な公開鍵などの管理に対する負担を減少させつつ,現用の公開鍵失効後の新規公開鍵への切り替えが迅速に行える仕組みを実現する,登録局サーバ104の運用方法を提供することを目的とする。」との記載からすると,引用例1には,公開鍵の管理を目的とする発明が読み取れる。
また,上記Aの「上記目的を達成する本発明の登録局サーバの運用方法は,互いに通信可能に接続された,ユーザ端末と認証局サーバと登録局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法における前記登録局サーバの運用方法であって,前記登録局サーバは,ユーザIDをデータベースで管理し」との記載,上記Bの「ユーザ100が操作するユーザ端末102,103と,登録局106での登録局サーバ104と,認証局108での認証局サーバ107とが,運用されている。登録局サーバ104と認証局サーバ107とは,同一局の異なる部門にあって,LANによって結ばれていても良い。」との記載からすると,「ユーザ端末」と「認証局サーバ」と「登録局サーバ」とが行う「公開鍵暗号方式を利用した鍵管理方法」が読み取れることから,引用例1には,
“互いに通信可能に接続された,ユーザ端末と,前記ユーザ端末からのユーザIDをデータベースで管理する登録局サーバと,認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法”
が記載されていると解される。

(イ) 上記Aの「あるユーザ端末Aから新たな公開鍵の登録要求を受信して,これに付帯して受信したユーザIDをキーとして前記データベースを検索し」との記載,上記Cの「前述したように,秘密鍵や公開鍵は,使用頻度や時間経過とともに次第に危殆化が進行していく。ユーザ100はその危殆化の進行度を,例えば,使用頻度などから判断し,ある時点で,予備鍵を新たに準備する時期であると判断する。その時点で,ユーザ100は,ユーザ端末102を通じて登録局サーバ104が開設しているホームページ500にアクセスし,それぞれ予備公開鍵と予備秘密鍵として,新たな公開鍵と新たな秘密鍵の準備を行う。」との記載からすると,ユーザは新たな公開鍵の登録要求を行う必要があると判断した時点で,「登録局サーバ」にアクセスするために,「ユーザ端末」から「ユーザID」を送信することが読み取れるから,引用例1には,
“ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で,ユーザIDを登録局サーバに送信するステップ”
が記載されていると解される。

(ウ) 上記Aの「前記登録局サーバは,ユーザIDをデータベースで管理し,あるユーザ端末Aから新たな公開鍵の登録要求を受信して,これに付帯して受信したユーザIDをキーとして前記データベースを検索し,ユーザIDが存在する場合には,新たな公開鍵を前記ユーザIDに対応づけて前記データベースに記憶し」との記載,上記Dの「登録局サーバ104のホームページ500において,ユーザ100がユーザ端末102から「予備公開鍵の登録-予備公開鍵はもっていない-今すぐに生成して保管しておく」の各チェック欄501,502,505をクリックし,送信ボタン509をクリックすることによって登録局サーバ104に送信すると(ｓ201),登録局サーバ104は,送信されたユーザIDをキーとして,鍵データベース105を検索し,保管されているユーザ情報や現用公開鍵等の情報を得る。 …(中略)… 審査が合格になると,登録局サーバ104は,鍵ペアを生成し(ｓ202),鍵データベース105にユーザIDと関連づけて保管する(ｓ203)。」との記載からすると,登録局サーバは,ユーザ端末から受信したユーザIDをキーとしてデータベースを検索して,前記ユーザIDが存在する場合には新たな公開鍵を生成し,前記ユーザIDに対応づけて前記データベースに記憶することが読み取れる。
また,上記Aの「ユーザ端末Aあるいは他のユーザ端末から送られてくる前記新たな公開鍵の使用開始要求あるいは現在の公開鍵の失効要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる,前記新たな公開鍵に対するデジタル証明書を受信して,ユーザ端末Aに前記デジタル証明書を送信する」との記載,上記Dの「ユーザは,現用秘密鍵の危殆化が過度に進行したと判断すると,ユーザ端末102を通じて同じホームページ500にアクセスし,「予備公開鍵の使用開始」のチェック欄507をクリックすることにより,今度は予備公開鍵の使用開始要求を送信する(ｓ204)。この要求を受信した登録局サーバ104は,認証局サーバ107に,ユーザIDと関連づけた公開鍵,現用公開鍵の失効要求とともに,公開鍵のデジタル証明書の発行要求を送信する(ｓ205)。」,「つぎに,認証局サーバ107が,現用公開鍵のデジタル証明書を失効させる一方,要求された公開鍵のデジタル証明書を発行し,登録局サーバ104に送信する(ｓ206)と,これを受信した登録局サーバ104は,ユーザ端末102にその公開鍵に対するデジタル証明書を送信し(ｓ207),鍵データベース105にユーザIDと対応づけてユーザ情報及び公開鍵デジタル証明書を記憶する(ｓ208)。」との記載からすると,登録局サーバは,ユーザ端末から新たな公開鍵の使用開始要求を受信すると,新たな公開鍵に対するデジタル証明書の発行要求を認証局サーバに送信する態様,登録局サーバは,認証局サーバから送られてくる新たな公開鍵に対するデジタル証明書を受信すると,ユーザ端末に当該デジタル証明書を送信する態様を読み取ることができるから,引用例1には,
“登録局サーバは,受信したユーザIDをキーとしてデータベースを検索して,前記ユーザIDが存在する場合には新たな公開鍵を生成し,前記ユーザIDに対応づけて前記データベースに記憶し,ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を認証局サーバに送信し,前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップ”
が記載されていると解される。

(エ) 上記Dの「このようにして前記公開鍵のデジタル証明書を受け取ったユーザ端末102は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取ったデジタル証明書を上書きする。」との記載からすると,公開鍵のデジタル証明書を受け取り,受け取ったデジタル証明書を上書きするユーザ端末は,新たな公開鍵の使用開始要求を登録局サーバに送信したユーザ端末であることは明らかであるから,引用例1には,
“新たな公開鍵に対するデジタル証明書を受け取ったユーザ端末は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ”
が記載されていると解される。

ウ 以上,(ア)乃至(エ)の検討によれば,引用例1には,次の発明(以下,「引用発明」という。)が記載されているものと認める。

「互いに通信可能に接続された,ユーザ端末と,前記ユーザ端末からのユーザIDをデータベースで管理する登録局サーバと,認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法において,
前記ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で,前記ユーザIDを前記登録局サーバに送信するステップと,
前記登録局サーバは,受信した前記ユーザIDをキーとして前記データベースを検索して,前記ユーザIDが存在する場合には新たな公開鍵を生成し,前記ユーザIDに対応づけて前記データベースに記憶し,前記ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップと,
前記新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップと,
を含む公開鍵暗号方式を利用した鍵管理方法。」


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

本願の優先日前に頒布され,当審からの上記平成26年2月27日付け拒絶理由通知において引用された,特開2002-72874号公報(平成14年3月12日出願公開,以下,「引用例2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

F 「【0003】この電子署名を用いる場合,送信元は,図6の処理フローに示すように,送信するデータをメッセージ要約関数を使って圧縮し,この圧縮文を秘密鍵で暗号化することで認証子(電子署名)を生成する。そして,この認証子と送信するデータとからなる署名文を作成して,それを送信先に送信する。
【0004】この署名文を受けて,送信先は,図7の処理フローに示すように,送られてきた署名文から認証子を抽出して,それを公開鍵で復号することで復号化圧縮文を取得する。
【0005】そして,送られてきた署名文の本体部分(送信データ部分)をメッセージ要約関数を使って圧縮することで圧縮文を生成し,この圧縮文と復号により得た復号化圧縮文とを比較して,両者が一致するときには,送られてきたデータが第三者により改竄されていないと判断し,一致しないときには,送られてきたデータが第三者により改竄されたと判断する。」


3 参考文献

(1) 参考文献1に記載されている技術的事項

本願優先日前に頒布された,特開2005-182317号公報(平成17年7月7日出願公開,以下,「参考文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

G 「【0008】
この電子カルテシステムにおいては,通信端末固有の情報である公開鍵証明書の識別番号によって本人認証がおこなわれる。そして,この公開鍵証明書の識別番号は,通信端末の登録手段によって情報システムにオンラインで登録される。そのため,ユーザは面倒な登録作業をすることなく,本人認証に用いられる情報を容易に情報システムに登録することができる。なお,公開鍵証明書の登録は,単に公開鍵証明書のみを送信するのではなく,公開鍵証明書と併せてこの公開鍵証明書に含まれる公開鍵を用いて暗号化したカルテ識別情報を送信するため,通信端末から情報システムへのカルテ識別情報の送信を安全におこなうことができる。つまり,このカルテ識別情報が通信端末と情報システムとの間の通信経路において盗まれた場合であっても,その情報を不正使用することができない。
…(中略)…
【0019】
端末格納部18には,端末ユーザが医療機関から取得した自己の電子カルテの識別情報であるカルテIDが格納されている。証明書受信部20は,認証局12から移動体通信網28を介して自端末のクライアント証明書を受信して端末格納部18に格納し,また移動体通信網28及びインターネット30を介して情報システム16に対してクライアント証明書を送信する。なお,クライアント証明書は公開鍵証明書であるため,この証明書には公開鍵及び他の証明書との識別が可能な識別情報(以下,証明書IDを称す。)が含まれている。」

(2) 参考文献2に記載されている技術的事項

本願優先日前に頒布された,特開2002-287631号公報(平成14年10月4日出願公開,以下,「参考文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

H 「【0003】また,ネットワーク上での本人認証方法として,利用者ID(識別子)とパスワードによる方法に比べて認証の為の情報を分散管理可能な,上記の公開鍵証明書を利用した本人認証方法が利用されている。
…(中略)…
【0006】この発明は,上述した事情を考慮してなされたもので,属性証明書の発行時に公開鍵証明書で本人認証を行う属性証明書管理サーバ,属性証明書管理方法およびそのプログラムを提供することを目的とする。また,複数の属性証明書の発行や管理を簡便に行う属性証明書管理サーバ,属性証明書管理方法およびそのプログラムを提供することを目的とする。」


4 対比

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

ア 引用発明の「互いに通信可能に接続された,ユーザ端末と,前記ユーザ端末からのユーザIDをデータベースで管理する登録局サーバと,認証局サーバとが存在する環境下で行われる公開鍵暗号方式を利用した鍵管理方法」は,セキュリティ維持のために公開鍵を管理することは明らかであるから,上位概念において本願発明の“保安維持のための方法”に相当すると言える。

イ 引用発明は「ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で,前記ユーザIDを前記登録局サーバに送信する」ところ,「ユーザ端末」から「登録局サーバ」へ新たな公開鍵の登録要求を行うための「ユーザID」を送信することから,引用発明の「ユーザ端末」,「登録局サーバ」は,本願発明の「クライアント」,「サーバ」に相当すると言える。
そして,引用発明の「ユーザID」と,本願発明の「現在公開キー情報を含む認証情報」は,共に「クライアント」を認証するための識別情報であると言えるから,引用発明の「ユーザ端末は新たな公開鍵の登録要求を行う必要があると判断した時点で,前記ユーザIDを前記登録局サーバに送信するステップ」と,本願発明の「クライアントの現在公開キー情報を含む認証情報をサーバへ伝送するステップ」とは後記する点で相違するものの,“クライアントを認証する識別情報をサーバへ伝送するステップ”である点で共通すると言える。

ウ 引用発明は「前記登録局サーバは,受信した前記ユーザIDをキーとして前記データベースを検索して,前記ユーザIDが存在する場合には新たな公開鍵を生成し,前記ユーザIDに対応づけて前記データベースに記憶」するところ,ユーザIDが存在するか否かを判定することから,登録局サーバは,ユーザを識別するユーザIDを基盤に前記ユーザを認証し,前記ユーザのための新たな公開鍵を生成すると言える。さらに,引用発明は「前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信する」ところ,登録局サーバは,ユーザIDにより識別された当該ユーザのための当該新たな公開鍵に対するデジタル証明書の発行を認証局サーバに要求し,認証局サーバから受信した当該新たな公開鍵に対するデジタル証明書をユーザ端末に送信していると言える。
また,引用発明の「前記新たな公開鍵に対するデジタル証明書」には,「新たな公開鍵」情報が含まれていることは明らかであり,本願発明の「最新の認証情報」は,最新公開キー情報を含むクライアントの証明情報とみることができることから,引用発明の「新たな公開鍵に対するデジタル証明書」と,本願発明の「最新公開キー情報とデジタル署名を含む最新の認証情報」とは,共に“最新公開キー情報を含む最新の証明情報”である点で共通する。
そうすると,引用発明の「前記登録局サーバは,受信した前記ユーザIDをキーとして前記データベースを検索して,前記ユーザIDが存在する場合には新たな公開鍵を生成し,前記ユーザIDに対応づけて前記データベースに記憶し,前記ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信して,前記新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書を受信して,前記ユーザ端末に前記新たな公開鍵に対するデジタル証明書を送信するステップ」と,本願発明の「前記サーバは,前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成し,前記最新の認証情報をクライアントへ伝送するステップ」とは後記する点で相違するものの,“サーバは,クライアントの識別情報を基盤に前記クライアントを認証し,前記クライアントのための最新公開キー情報を含む最新の証明情報を生成し,前記最新の証明情報をクライアントへ伝送するステップ”である点で共通すると言える。

エ 引用発明は「新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きする」ところ,ユーザ端末は登録局サーバから受け取った最新の証明情報を利用して最新の証明情報にアップデートしているとみることができ,引用発明の「新たな公開鍵に対するデジタル証明書」と,本願発明の「最新の認証情報」とは,共に“最新の証明情報”である点で共通する。
そうすると,引用発明の「新たな公開鍵に対するデジタル証明書を受け取った前記ユーザ端末は,現用の公開鍵のデジタル証明書が記憶されているメモリ上の領域に,受け取った前記新たな公開鍵に対するデジタル証明書を上書きするステップ」と,本願発明の「前記認証が成功する場合,前記最新の認証情報を利用して前記現在公開キー情報を含む前記最新の認証情報に前記認証情報をアップデートするステップ」とは後記する点で相違するものの,“最新の証明情報を利用して現在公開キー情報を含む前記最新の証明情報に前記証明情報をアップデートするステップ”である点で共通すると言える。

(2) 以上,ア乃至エの検討によれば,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

(一致点)

「 保安維持のための方法において,
クライアントを認証する識別情報をサーバへ伝送するステップと,
前記サーバは,前記クライアントの前記識別情報を基盤に前記クライアントを認証し,前記クライアントのための最新公開キー情報を含む最新の証明情報を生成し,前記最新の証明情報を前記クライアントへ伝送するステップと,
前記最新の証明情報を利用して現在公開キー情報を含む前記最新の証明情報に前記証明情報をアップデートするステップと,を含むことを特徴とする保安方法。」

(相違点1)
クライアントを認証する識別情報に関し,本願発明は,「現在公開キー情報を含む認証情報」により認証しているのに対して,引用発明は「ユーザID」を用いて認証する点。

(相違点2)
クライアントに送信する最新公開キー情報を含む最新の証明情報の生成手順に関し,本願発明では,サーバが,「認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報」を同時に生成するのに対して,引用発明では,登録局サーバが,「受信した前記ユーザIDをキーとして前記データベースを検索して」「新たな公開鍵」を予め生成し,「ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信し」た時点で,「新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信」する点。

(相違点3)
最新の証明情報にアップデートする条件に関し,本願発明は,「前記現在公開キー情報を利用して前記デジタル署名を解読し,前記最新の認証情報を認証」できた場合に,「認証情報をアップデートする」のに対して,引用発明は,「新たな公開鍵に対するデジタル証明書を上書きする」条件について言及されていない点。


5 当審の判断

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

(1) 相違点1について

参考文献1(上記Gを参照)や参考文献2(上記Hを参照)に記載されるように,公開鍵の情報を含む認証情報を,クライアント端末ユーザの本人確認のために利用することは,本願優先日前には当該技術分野の周知技術であった。
また,クライアント端末を利用するユーザの認証を行うために,如何なる認証情報を用いるかということは,通信の安全性等を考慮して適宜に選択すべき事項であると言える。
してみると,引用発明において,上記周知技術を適用し,ユーザIDに代えて,適宜,現用の公開鍵を含む認証情報によりユーザを認証すること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

(2) 相違点2について

引用発明は,登録局サーバが,「受信した前記ユーザIDをキーとして前記データベースを検索して」「新たな公開鍵」を予め生成し,「ユーザ端末から送られてくる前記新たな公開鍵の使用開始要求を受信し」た時点で,「新たな公開鍵に対するデジタル証明書の発行要求を前記認証局サーバに送信し,前記認証局サーバから送られてくる前記新たな公開鍵に対するデジタル証明書」をユーザ端末に送信するところ,ユーザを認証する識別情報を基盤に,新たな公開鍵と最新の証明情報とを順次に生成していると言える。そして,引用例1の上記Eの記載からすると,新たな公開鍵の生成と,新たな公開鍵の最新の証明情報の生成とを同時に行う態様も可能であることが読み取れることから,新たな公開鍵の生成を,証明情報の生成と同時に行うか,証明情報の生成より前に予め行うかは,当業者にとって必要に応じて選択し得た設計的事項であった。
また,上記「(1) 相違点1について」での検討のとおり,公開鍵の情報を含む認証情報を,クライアント端末ユーザの本人確認のために利用することは,本願優先日前には周知技術であり,かつ,公開鍵に対するデジタル証明書にデジタル署名を付けて送信する旨の技術も,本願優先日前には当該技術分野の慣用技術であった。
してみると,引用発明において,上記周知技術を適用し,適宜,登録局サーバが,現用の公開鍵を基盤にユーザを認証し,前記ユーザのための認証情報を検索することによって新たな公開鍵情報とデジタル署名を含む最新の認証情報とを生成すること,すなわち,上記相違点2に係る構成とすることは,当業者が容易に想到し得たことである。

(3) 相違点3について

引用例2(上記Fを参照)に記載されるように,デシタル署名が付加されたデータを送信元から送信先に送信し,送信先では公開鍵を利用して前記送信されてきたデータの真正性を確認することは,本願優先日前に周知技術であり,安全性の高いデータの送受信を行うことを技術的課題としている点で引用発明と共通すると言える。
また,受信データの真正性の確認が済んだ後に当該受信データに基づく登録データの更新処理を実行することは,セキュリティ通信の技術分野における周知慣用技術である。
そうすると,引用発明において,上記の周知技術を適用し,適宜,現用の公開鍵を利用して新たなデジタル証明書に含まれるデジタル署名を解読し,前記新たなデジタル証明書を認証できた場合に,当該デジタル証明書をアップデートすること,すなわち,上記相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

(4) 小括

上記で検討したごとく,相違点1乃至3に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,上記引用発明及び引用例2などに記載の当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。


6 本願発明の進歩性についてのむすび

以上のとおり,本願の請求項1に係る発明は,上記引用発明,引用例2などに記載の当該技術分野の周知技術に基づいて,当業者が容易に発明をすることができたものである。


第4 当審による平成26年2月27日付け拒絶理由通知書の理由2(記載不備)について

1 理由2(1)a.について

(1) 平成27年1月21日付け手続補正書により補正された特許請求の範囲請求項1には,「前記サーバは,前記認証情報に含まれる前記現在公開キー情報を基盤に前記クライアントを認証し,前記クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成」することが特定されており, 「現在公開キー情報」および,「現在公開キー情報」から生成される「最新公開キー情報」が発明特定事項に含まれているところ,これら発明特定事項について,発明の詳細な説明の記載を参酌しても,如何にして現在公開キー情報を基盤にしてクライアントのための認証情報を検索し,如何にして最新公開キー情報とデジタル署名を含む最新の認証情報を生成するのか,そのための情報処理が依然として不明である。
すなわち,発明の詳細な説明の段落【0021】には,「認証情報伝送モジュール110は,メモリ151に保存されている認証情報を,通信モジュール140を通じてサーバ200へ伝送し,サーバ200から最新の認証情報を受信する。認証情報150は,公開キーについての情報を含むことが望ましい。また,サーバ200は,既存の公開キーをアップデートするための情報として,最新の公開キー情報と,この公開キー情報についてのデジタル署名とを含む最新の認証情報を伝送する。このとき,サーバ200は,クライアント100から受信した認証情報を利用してクライアントを確認し,クライアントのための認証情報を検索して最新の認証情報を生成した後に送信する。」が記載され,また,段落【0024】には,「サーバは,クライアントから受信した認証情報を利用して,クライアントのための最新の認証情報を生成して伝送する(S204)。このステップで,サーバは,クライアントの認証情報を基盤にクライアントの現在状態を把握し,クライアントが認証できる情報を検索して伝送する。このとき,サーバが伝送する最新の認証情報は,クライアントのための最新の公開キー情報と,この公開キー情報についてのデジタル署名とを含むことが望ましい。」が記載されており,これらの記載からすると,クライアントから受信した認証情報を基盤に最新の認証情報を検索して生成することは把握できるものの,「クライアントのための認証情報を検索することによって最新公開キー情報とデジタル署名を含む最新の認証情報を生成」するための情報処理や,「現在公開キー情報」,「クライアントのための認証情報」,「最新公開キー情報」が当該「検索」を実行するための情報処理にどのように関与しているかについては,当該技術分野の技術常識を考慮しても,当業者が発明の実施をすることができる程度に明確かつ十分に記載されているとは言えない。

また,上記と同様,本願発明の詳細な説明は,平成27年1月21日付け手続補正書により補正された特許請求の範囲請求項2-12に係る発明の実施をすることができる程度に明確かつ十分に記載されているとは言えない。

(2) したがって,この出願の発明の詳細な説明は,当業者が請求項1-12に係る発明を実施することができる程度に明確かつ十分に記載したものでない。

2 請求人の主張について

(1) なお,請求人は,上記平成26年6月4日付け意見書において,

「4.拒絶理由について
…(中略)…
＜理由2＞
・特許法第36条第4項第1号について
a「どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか」について
まず,段落〔0029〕から「または最新の認証情報に新たな内容がないと判断されれば」という記載を削除しました。これにより,「最新の認証情報に新たな内容がないと判断され」る状況が発生することがなくなりました。
また,認証情報から最新公開キー情報を含む最新の認証情報を生成する情報処理は,例えば,認証情報に所定値を加えたり,認証情報をシードにして乱数を発生させることで新しい認証情報を作成します。
以上により,補正後の請求項1?12に係る発明は,当業者が請求項1-12に係る発明の実施をすることができる程度に明確かつ十分に記載したものになったと思料します。

…(後略)…」

と主張している。

(2) しかしながら,請求人が主張する「認証情報から最新公開キー情報を含む最新の認証情報を生成する情報処理は,例えば,認証情報に所定値を加えたり,認証情報をシードにして乱数を発生させることで新しい認証情報を作成します。」については本願明細書に記載されたものではなく,また,「現在公開キー情報」,「最新公開キー情報」がどのように関与しているかも不明であるから,本願明細書の発明の詳細な説明の段落【0021】,【0024】からは,クライアントから受信した認証情報を基盤に最新の認証情報を検索して生成することが把握されるにとどまる。それ故に,仮に請求人の主張する上記事項が当該技術分野の技術常識だとしても,当業者が発明の実施をすることができる程度に明確かつ十分に記載されているとはいえない。
よって,「どのように現在公開キー情報を含む認証情報から最新公開キー情報を含む最新の認証情報を生成するのか」については,依然として情報処理が不明であり,請求人の当該主張についても,採用することはできない。

3 理由2(記載不備)についてのむすび

したがって,本願明細書の発明の詳細な説明は,平成27年1月21日付け手続補正書により補正された特許請求の範囲請求項1-12に係る発明について,当業者がその実施をすることができる程度に明確かつ十分に記載したものではない。


第5 むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。
また,本願明細書の発明の詳細な説明は,特許法第36条第4項第1号に規定する要件を満たしておらず,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2015-04-27 
結審通知日 2015-04-28 
審決日 2015-05-15 
出願番号 特願2006-269569(P2006-269569)
審決分類 P 1 8・ 121- WZ (G06F)
P 1 8・ 536- WZ (G06F)
最終処分 不成立  
前審関与審査官 石田 信行  
特許庁審判長 石井 茂和
特許庁審判官 木村 貴俊
辻本 泰隆
発明の名称 保安方法及びシステム、その方法を記録したコンピュータで読み取り可能な記録媒体  
代理人 伊東 忠重  
代理人 大貫 進介  
代理人 伊東 忠彦  

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