拒絶査定不服の審決｜不服2012-15892 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服特36条4項詳細な説明の記載不備特許、登録しない(前置又は当審拒絶理由) G06F 審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない(前置又は当審拒絶理由) G06F 審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) G06F
管理番号	1288929
審判番号	不服2012-15892
総通号数	176
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2014-08-29
種別	拒絶査定不服の審決
審判請求日	2012-08-15
確定日	2014-06-19
事件の表示	特願2011-185580「データ作成装置、方法及びコンピュータプログラム」拒絶査定不服審判事件〔平成24年 1月12日出願公開、特開2012- 9059〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1.手続の経緯 1.出願までの経緯平成22年2月3日に特願2010-022396号が出願され、これを原出願とする特許法第44条第1項の規定による新たな特許出願(以下「分割出願」と記す。)として、平成22年7月20日に特願2010-163421号が出願され、これを原出願とする分割出願として、平成23年8月29日に本件請求に係る出願(以下「本願」と記す)が出願された。 2.原審の経緯本願は上記のように、平成22年2月3日を出願日とみなされる分割出願として、平成23年8月29日に出願されたものであって、平成23年11月10日付けで手続補正書が提出され、平成23年11月11日付けで手続補正書が提出され、平成24年1月23日付けで審査請求がなされ、平成24年2月20日付けで拒絶理由通知(平成24年2月23日発送)がなされ、平成24年4月23日付けで意見書が提出され、平成24年5月14日付けで拒絶査定(平成24年5月16日謄本発送)がなされたものである。 3.当審での経緯本件審判請求は、平成24年8月15日付けで「原査定を取り消す。この出願の発明は特許をすべきものとする、との審決を求める。」との趣旨でなされたもので、同日付けで手続補正書が提出され、平成24年9月5日付けで特許法第164条第3項に定める報告(前置報告)がなされ、平成25年4月15日付けで当該報告に対する意見を求める旨の審尋(平成25年4月16日発送)がなされたが、これに対しての回答は無く、平成25年11月27日付けで上記平成24年8月15日付けの手続補正書による補正の却下の決定(平成25年12月10日発送)がなされるとともに、同日付けで拒絶理由通知(平成25年11月29日発送)がなされ、平成26年1月17日に面接(平成26年1月22日入力)を行い、平成26年1月28日付けで意見書が提出されるとともに、同日付けで手続補正書が提出されたものである。第2.特許法第36条(明細書の記載要件)について 1.当審拒絶理由上記平成25年11月27日付けの拒絶理由通知書(以下、「当審拒絶理由通知書」と記す。)によって通知された拒絶理由のうち特許法第36条についての拒絶理由の概要は下記のとおりのものである。『2.この出願は、明細書及び特許請求の範囲の記載が下記の点で、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていない。記・・・(中略)・・・ (5)請求項1、2、3、4、5に「前記格納された原本データのファイル名」とあるが、「格納された原本データのファイル名」は前記されていない。したがって、請求項1、2、3、4、5に係る発明は明確でない。・・・(中略)・・・ (8)本願発明の詳細な説明の段落【0002】において「このような現状のもと、特許文献1には電子公証サービスを実現するための技術が開示されている。特許文献1の項目〔0028〕では、公証サービスを希望する電子データ(130)に対して、公証サービス享受者のデジタル署名(131)と付加情報(132)を加え、これに公証センターの承認者のデジタル署名(133)を加え一体となった状態のデータを公証済電子データ(141)とする。このように、原本である電子データ(130)はデジタル署名(131)等が加えられることにより、元の電子データとは同一ではなくなっている。証明が必要とされているのは変更前の元データであるので、証明のために変更せざるを得ないのでは本末転倒である。また、付加情報(132)には、日付や承認者、承認内容等が含まれており、電子データ(130)の証明書の役割をなすものであるが、本来証明書というものは、それが証明する対象とは相互に独立のはずであり、対象となるデータに付加されるものではない。」と従来技術の問題点の説明がなされているが、当該従来技術の問題点は当業者が理解しうるものではなく、本願請求項1、2、3、4、5に係る発明が解決しようとする課題が明確になされていない。(ここで従来技術として挙げられる文献(引用文献4)の何処にも、「付加情報」や「署名」が加わる際に「電子データ」が変更される旨の説明は見当たらない。また、通常は署名等の付加によって元データが変更されるものではないので、技術常識からみて該従来技術の問題点の記載は理解しがたいものである。) したがって、この出願の発明の詳細な説明は、請求項1、2、3、4、5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものである。 (9)本願の発明の詳細な説明においては、段落【0025】に「ファイル本体には原本データDが添付されており、署名欄には日時保証情報Cが書込まれている。PDF形式のファイルには、署名欄に書き込んだデータを変更したり削除したりすることはできないという特徴がある。」とある一方、段落【0026】に「このソフトウェアは、次のような機能を備えている。すなわち、証明済ファイルF3から日時証明情報Cを削除した後のファイルのハッシュ値を計算する機能」とあり、互いに矛盾する説明がなされている。このため、当業者が本願請求項1、2、3、4、5に係る発明を実施しようとしたときに、本願の発明の詳細な説明の記載から「添付」の処理として如何なる処理を採用すれば良いのかを明確に把握することができない。したがって、この出願の発明の詳細な説明は、当業者が請求項1、2、3、4、5に係る発明を実施することができる程度に明確かつ十分に記載されていないものである。 (10)本願発明の詳細な説明においては、段落【0002】で上記(9)で論じた従来技術の問題点の説明がされ、これに続いて【発明が解決しようとする課題】として段落【0004】に「証明するために、対象となるデジタルデータを変更するという問題を解決することである。紙媒体への刻印による証明法は、原本データ部分と証明書部分とが独立であり、かつ両者の改変は不可能であり、かつ両者の対応に疑義が生じる余地はない。本発明は、原本がデジタルデータの場合にも、このような証明法を実現することを目的とする。」とあるが、本願請求項1、2、3、4、5に係る発明が何故従来技術の問題点を解消し該課題を解決し得るものであるのかの説明が明確になされていない。敷衍するに、本願発明においても「原本データ」は「中間ファイル」に「ファイル名」や「日時」などとともに「格納」され、さらに該「中間ファイル」には「日時保証情報」が「添付」されるところ、発明の詳細な説明を詳細に精査しても、これらの「格納」「添付」等の処理が如何なる処理を意味し、上記従来技術における「付加」する処理や「加え」る処理と何がどう異なるのかを正確に把握することは不可能である。(本願発明の詳細な説明の段落【0006】に『「中間ファイル」は、原本データを受信した日付やデータ名などの事項が記載された証明書ファイルに任意個数の原本データを追加して記憶させた1個のファイルである。なお、この出願書類では、1つのファイルに1個以上の原本データを追加して記憶させる(含ませる)ことを「添付」と表現している。中間ファイルに添付された原本データには一切変更がない。』、同【0006】に『なお、「埋め込む」とは、中間ファイルの所定の箇所に書き込むことをいう。例えば、中間ファイルのフォーマットがPDFであれば、日時保証情報はファイルの属性情報の一種であり、かつ書き換え不可能な署名欄に書き込まれる。』、同【0018】に「次にこの証明書ファイルに受信した原本データを変更することなくそのまま添付して中間ファイルを作成する。」、同【0024】に「証明済ファイル作成手段10は、中間ファイルF2に日時保証情報Cを埋め込み、証明済ファイルF3を作成する(ステップS6)。日時保証情報Cの埋め込み方はPDFなどの公知のファイルフォーマットに従うものとし、詳細な説明は省略する。」等の記載、段落【0025】及び【0026】には上記(9)で言及した互いに矛盾する記載があるが、具体的な処理内容についての開示が無く、上記従来技術における「付加」する処理や「加え」る処理とは何がどう異なるのかが何ら説明されていない。)このため、当業者が本願請求項1、2、3、4、5に係る発明を実施しようとしたときに、本願の発明の詳細な説明の記載から「格納」や「添付」の処理として如何なる処理を採用すれば良いのかを把握することはできず、しかも、本願発明が上記従来技術の問題点を解消し上記課題を解決し得るものと認めることもできない。したがって、この出願の発明の詳細な説明は、当業者が請求項1、2、3、4、5に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、請求項1、2、3、4、5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものである。また、このため、本願請求項1、2、3、4、5の記載は、本願の発明の詳細な説明に記載された、発明の課題を解決するための手段が反映されておらず、発明の詳細な説明に記載した範囲を超えて特許を請求することとなるものであるとも言え、本願請求項1、2、3、4、5に係る発明は本願明細書の発明の詳細な説明に記載したものでないとも言える。また、本願請求項1、2、3、4、5で用いられている「格納」「添付」等の用語の意味・定義は、本願の発明の詳細な説明を参酌しても明確でないものであるから、この点からも本願の請求項1、2、3、4、5に係る発明は明確でないと言える。 (11)本願の発明の詳細な説明の段落【0036】に『ユーザは、原本データについてデータを格納するファイル形式を問わず簡便に内容証明を受けることができる。今後各種書類は、従来の紙媒体からデジタルデータへの移行が進むと予想されるが、本発明はデジタルデータの内容証明を簡便かつ確実に行うシステム・方法として多くの需要が見込まれると期待される。なお「簡便」とは、単にユーザの作業の簡便性だけではなく、「運用のための大がかりな組織を必要としない」という意味も含まれる。』とあるが、本願請求項1、2、3、4、5に係る発明が何故「簡便」「運用のための大がかりな組織を必要としない」発明であるのかが明確に説明されていない。敷衍するに、本願請求項1、2、3、4、5に係る発明においても、「タイムスタンプ付与装置」は必須のものであり、さらに「データ作成装置」や「タイムスタンプ付与装置」に接続された「コンピュータ」が必要になるのであるから、決して「簡便」なものとは言えない。また、単に存在証明をするだけであれば、「中間ファイルの作成処理日時」や「原本データのファイル名」を格納した「中間ファイル」と言う形態を採る必要は無く、「データ作成装置」を介さずに「原本データ」あるいはそのハッシュを「ユーザ端末」から直接「タイムスタンプ付与装置」に送って返送された「日時保証情報」を「原本データ」に紐付けるだけで良いのであるから、本願請求項1、2、3、4、5に係る発明は「データ作成装置」と言う通常は必要の無い構成が採用されて、より大がかりな構成となっており、到底「簡便」「運用のための大がかりな組織を必要としない」ものと認め得るものではない。したがって、この出願の発明の詳細な説明は、当業者が請求項1、2、3、4、5に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、請求項1、2、3、4、5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものである。』 2.平成26年1月28日付け手続補正上記平成26年1月28日付けの手続補正書は特許請求の範囲を下記本願特許請求の範囲に補正するものである。＜本願特許請求の範囲＞「【請求項1】ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、対象となる原本データを前記ユーザ端末から受信する原本データ受信手段と、前記格納された原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル(PDF)形式のファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する中間ファイル作成手段と、前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段と、受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、この証明済ファイルを前記ユーザ端末に送信する証明済ファイル送信手段と、を備えることを特徴とするデータ作成装置。【請求項2】ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置により行われる方法であって、上記データ生成装置が、対象となる原本データを前記ユーザ端末から受信する処理と、前記格納された原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル(PDF)形式のファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する処理と、前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する処理と、前記タイムスタンプ付与装置から、前記日時保証情報を受信する処理と、受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する処理と、この証明済ファイルを前記ユーザ端末に送信する処理と、を備えることを特徴とするデータ作成方法。【請求項3】ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたコンピュータに対して、対象となる原本データを前記ユーザ端末から受信する処理と、前記格納された原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル(PDF)形式のファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する処理と、前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する処理と、前記タイムスタンプ付与装置から、前記日時保証情報を受信する処理と、受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する処理と、この証明済ファイルを前記ユーザ端末に送信する処理と、を実行させるコンピュータプログラム。」 3.そこで、上記当審拒絶理由書の特許法第36条についての拒絶理由が上記平成26年1月28日付けの手続補正書によって解消されたか否かについて検討する。 (1)理由2.(5)について当審拒絶理由通知書の理由2.(5)において、指摘した「前記格納された原本データのファイル名」との記載は、依然として請求項1、2、3に存在しており、またその記載の前に「格納」や「格納された原本データ」「格納された原本データのファイル名」との記載は見あたらない。なお、この点について、意見書においては【意見の内容】「3.意見の内容」「3-2.理由2について」「(5)」において『この点補正後の請求項1?3の記載によれば、「前記格納された原本データのデータ名」として、「原本データを前記ユーザ端末から受信する」の受信した原本データのデータ名を示すことは明らかであるから、指摘の理由は解消したものと考えます。』との主張がなされている。しかしながら、「原本データ」との用語が前記されていたとしても、指摘された「前記」との接頭語は「格納」の前に付されているのであるから、この「前記」がどの記載を指すのかは依然として不明である。したがって、当審拒絶理由通知書の理由2.(5)で指摘した不備は解消されていない。 (2)理由2.(8)について当審拒絶理由通知書の理由2.(8)において、指摘した段落【0002】の記載は特に補正がなされておらず、依然として、ここに記載の従来技術の問題点は当業者が理解しうるものではない。なお、この点について、意見書においては【意見の内容】「3.意見の内容」「3-2.理由2について」「(8)」において『この点本願明細書段落【0002】の記載は、従来では、元データとデジタル署名データとが別々のデータないしはファイルとして存在しており、これを紐つけて管理するには別途何らかのデータベースなどの手段が必要であったことを述べています。また、後段は元データとその存在を証明する証明書データ(本願の「中間ファイル」に相当)は別々の独立したデータ(ファイル)として存在していたことを説明しています。そして、本願発明では、原本データ受信した日付が記載された中間ファイルとしてPDF形式を採用することで、この中間ファイルに原本データを格納し、中間ファイルにさら日時保証情報を格納することで、1つのPDFファイルだけで、このPDFに記載された「原本データを受信した日付」を証明すると共に、その受信した「原本データ」と、これらを紐付ける「日時保証情報」をそれぞれまとめて特定できる点に特徴にあります。以上のことから、本願明細書段落【0002】の記載が不明瞭であるとの理由はあたらないものと考えます。』との主張がなされている。しかしながら、本願明細書の段落【0002】の記載は『紙媒体がある時点で存在していたことを客観的に証明するために公証役場の確定日付を利用することが行われる。これは、紙媒体の持ち主が存在を主張しても、本人の主張では信頼性に欠けるので、やはり第三者機関の介在が必要になってくるからである。ところで、昨今は、各種書類をパソコンなどの情報処理装置で作成することが多くなり、作成されたデジタルデータの作成時期と内容を第三者によって証明してもらおうとする需要は増加の一途である。このような現状のもと、特許文献1には電子公証サービスを実現するための技術が開示されている。特許文献1の項目〔0028〕では、公証サービスを希望する電子データ(130)に対して、公証サービス享受者のデジタル署名(131)と付加情報(132)を加え、これに公証センターの承認者のデジタル署名(133)を加え一体となった状態のデータを公証済電子データ(141)とする。このように、原本である電子データ(130)はデジタル署名(131)等が加えられることにより、元の電子データとは同一ではなくなっている。証明が必要とされているのは変更前の元データであるので、証明のために変更せざるを得ないのでは本末転倒である。また、付加情報(132)には、日付や承認者、承認内容等が含まれており、電子データ(130)の証明書の役割をなすものであるが、本来証明書というものは、それが証明する対象とは相互に独立のはずであり、対象となるデータに付加されるものではない。』というものであるから、到底「従来では、元データとデジタル署名データとが別々のデータないしはファイルとして存在しており、これを紐つけて管理するには別途何らかのデータベースなどの手段が必要であったこと」を述べていると解釈することはできないものである。したがって、当審拒絶理由通知書の理由2.(8)で指摘した不備は解消されていない。 (3)理由2.(9)について当審拒絶理由通知書の理由2.(9)において、指摘した段落【0025】の記載も段落【0026】の記載も補正されておらず、依然として、互いに矛盾する説明がなされていると言える。なお、この点について、意見書においては【意見の内容】「3.意見の内容」「3-2.理由2について」「(9)」において『この点、PDFのフォーマットは、本意見書に添付した補足資料1によれば、「PDFの文章構造は、主に辞書を含むオブジェクトの参照関係で表現します。文書の構造情報、個別ページの描画内容、そこに表示する画像やフォントの情報などをそれぞれ独立したオブジェクトとして定義し、互いに参照させることで、階層構造をもたせています。」とあるようにPDF内の本文、署名欄、添付欄などの情報はそれぞれ独立したオブジェクトとして定義されています。これを前提として。ご指摘いただいた段落【0025】の内容は、PDFファイルの署名欄自体は書き込みが記載されているオブジェクトであることを説明しています段落【0026】の「日時保証商標Cを削除した後のファイルのハッシュ値を計算する」というのは、日時保証情報が格納されている「署名欄」というオブジェクトは除いて、他のオブジェクト(原本データを受信した日付が記載された本文のオブジェクト、原本データが格納された添付欄のオブジェクトなど)に基づいて、ハッシュ値を再計算することを説明しております。つまり、タイムスタンプを押す際にハッシュ値生成の対象となるオブジェクト(証明欄のオブジェクトを除く)と、検証をする際にハッシュ値生成の対象となるオブジェクト(証明欄のオブジェクトを除く)が同じオブジェクトであることを説明しております。これら同じオブジェクトであれば、その内容が同じであれば生成されるハッシュ値も同じのなるためです。このように、上記明細書の記載はPDFの文書構造を斟酌すれば、上記内容を指し示しており、その記載も明確となり、ご指摘的の理由はあたらないものと考えます。』との主張がなされている。しかしながら、情報が独立したオブジェクトとして定義されているからといって、書き込んだデータを変更したり削除したりすることはできないことになるわけではなく、また、日時証明情報が削除可能である旨の記載と矛盾しなくなるわけでもない。したがって、当審拒絶理由通知書の理由2.(9)で指摘した不備は解消されていない。 (4)理由2.(10)について当審拒絶理由通知書の理由2.(10)において指摘した、「何故従来技術の問題点を解消し該課題を解決し得るものであるのかの説明」は依然としてなされていない。なお、この点について、意見書においては【意見の内容】「3.意見の内容」「3-2.理由2について」「(10)」において『この点、ご指摘のように「格納」「添付」の処理自体は、「付加」する処理「加え」る処理と同義です。そして、本願明細書では、その対象となるデータの種類に応じて、これらの表現を変えただけであり、技術的意義については特に異なることはありません。本願発明は、PDFフォーマットを用いることにより、上述の(9)のようにデータを「付加」または「加え」るオブジェクトにより、「格納」「添付」「記載」などの表現を区別したものに過ぎません。したがって、上記のご指摘の理由はあたらないものと考えます。』との主張がなされている。しかしながら、「格納」「添付」の処理が「付加」する処理「加え」る処理と同義であるならば、明らかに上記従来技術の問題点を解消し該課題を解決することはできない。したがって、当審拒絶理由通知書の理由2.(10)で指摘した不備は解消されていない。 (5)理由2.(11)について当審拒絶理由通知書の理由2.(11)において指摘した、『何故「簡便」「運用のための大がかりな組織を必要としない」発明であるのか』は依然として明確に説明されていない。なお、この点について、意見書においては【意見の内容】「3.意見の内容」「3-2.理由2について」「(11)」において『上記明細書の記載は、従来は原本データと、日時保証情報データと、証明書データとは別々に管理され、所定のデータを管理するデータベースによりその紐付けを管理していました。つまり、最初に原本データからハッシュ値を生成した時点で、データベースにその原本データのデータ名とハッシュ値及び日時保証情報を関連付けて管理しておき、証明が必要となった時点で、再度原本データからハッシュ値を作成し、データベースに記憶しておいた日時保証情報のハッシュ値とを比較することで、はじめて証明書が発行されていました。しかし、これに比べて本願発明によれば、ひとつのPDF形式の中間ファイに、「原本データを受信した日付」、「日時保証情報」、「原本データ」が一体として格納されていることから、上述の従来技術比べて管理が非常に簡便になります。またその運用において、従来では発行された日時保証情報を管理しておく組織(データベース)が必要とされましたが、本発明では、「原本データを受信した日付」、「日時保証情報」、「原本データ」がひとつのPDFファイルに格納されているため、原本データ改ざんが無いことを証明するためにも、このPDFファイルだけで証明が可能となる点でこの発明の独特な効果を奏するものです。したがって、ご指摘の理由は当たらないものと考えます。』との主張がなされている。しかしながら、本願明細書の段落【0002】記載の従来の技術でも「公証済電子データ」は「一体となった状態のデータ」なのであるから、簡便さや規模では格別相違しないはずである。また、本願の明細書記載の発明においても、「日時保証情報」や「原本データ」が格納された「PDFファイル」は、ユーザーが保存することになるので、従来技術の「組織(データベース)」に相当する手段が不必要になるわけではない。また、当審拒絶理由通知書で指摘した『本願請求項1、2、3、4、5に係る発明においても、「タイムスタンプ付与装置」は必須のものであり、さらに「データ作成装置」や「タイムスタンプ付与装置」に接続された「コンピュータ」が必要になるのであるから、決して「簡便」なものとは言えない。』との指摘や『また、単に存在証明をするだけであれば、「中間ファイルの作成処理日時」や「原本データのファイル名」を格納した「中間ファイル」と言う形態を採る必要は無く、「データ作成装置」を介さずに「原本データ」あるいはそのハッシュを「ユーザ端末」から直接「タイムスタンプ付与装置」に送って返送された「日時保証情報」を「原本データ」に紐付けるだけで良いのであるから、本願請求項1、2、3、4、5に係る発明は「データ作成装置」と言う通常は必要の無い構成が採用されて、より大がかりな構成となっており、到底「簡便」「運用のための大がかりな組織を必要としない」ものと認め得るものではない。』との指摘に関しては何ら釈明がなされていない。したがって、当審拒絶理由通知書の理由2.(11)で指摘した不備は解消されていないものである。 4.小結以上のとおり、本願は、明細書及び特許請求の範囲の記載が、依然として、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていない。第3.特許法第29条第2項(進歩性)について 1.本願発明の認定本願の請求項1に係る発明は、平成26年1月28日付けの手続補正書によって補正された本願特許請求の範囲、明細書および図面の記載からみて下記本願発明のとおりのものと認める。＜本願発明＞「ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、対象となる原本データを前記ユーザ端末から受信する原本データ受信手段と、格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル(PDF)形式のファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する中間ファイル作成手段と、前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段と、受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、この証明済ファイルを前記ユーザ端末に送信する証明済ファイル送信手段と、を備えることを特徴とするデータ作成装置。」 (なお平成26年1月28日付けの手続補正書の【請求項1】記載の「前記格納された原本データのデータ名」との記載は、上記平成26年1月28日付けの意見書の【意見の内容】「3.意見の内容」「3-2.理由2について」「(5)」の主張を参酌して「格納された前記原本データのデータ名」と訂正して認定した。) 2.先行技術 (1)引用文献本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり、上記平成25年11月27日付けの当審拒絶理由通知書の理由3.において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。) ＜引用文献1＞特開2007-266797号公報(平成19年10月11日出願公開) ＜引用文献記載事項1-1＞「【特許請求の範囲】【請求項1】 1つまたは複数の端末または他のシステムと通信ネットワークを介して接続された業務システムより、電子文書のデータと当該電子文書の認証情報付与依頼を受信する認証情報付与依頼受付手段と、前記電子文書のデータへのタイムスタンプまたは電子署名の何れか一方または両方の付与処理を行う認証情報付与処理手段と、を備えることを特徴とする認証システム。【請求項2】前記認証情報付与処理手段は、同時刻のタイムスタンプまたは同時刻に生成された電子署名の何れか一方または両方を、前記認証情報付与依頼受付手段により受付けた複数の電子文書それぞれに対して生成し、当該複数の電子文書への付与処理を行うことを特徴とする請求項1に記載の認証システム。【請求項3】前記タイムスタンプまたは電子署名の何れか一方または両方を付与した前記電子文書のデータを認証情報付与依頼の依頼元へ返信する電子文書データ返信手段と、前記タイムスタンプまたは電子署名の何れか一方または両方を付与した電子文書のデータとその電子文書の検証依頼を受信する検証依頼受付手段と、前記検証依頼された電子文書のデータに付与される前記タイムスタンプまたは電子署名の何れか一方または両方が正規に生成された情報か否かの検証処理を行う検証手段と、前記検証の結果を前記検証依頼の依頼元へ通知する検証結果通知手段と、を備えることを特徴とする請求項1に記載の認証システム。・・・中略・・・【請求項8】 1つまたは複数の端末または他のシステムと通信ネットワークを介して接続された業務システムより、電子文書のデータと当該電子文書の認証情報付与依頼を受信する認証情報付与依頼受付処理と、前記電子文書のデータへのタイムスタンプまたは電子署名の何れか一方または両方の付与処理を行う認証情報付与処理と、を有することを特徴とする認証方法。【請求項9】前記認証情報付与処理において、同時刻のタイムスタンプまたは同時刻に生成された電子署名の何れか一方または両方を、前記認証情報付与依頼受付処理により受付けた複数の電子文書それぞれに対して生成し、当該複数の電子文書への付与処理を行うことを特徴とする請求項8に記載の認証方法。【請求項10】前記タイムスタンプまたは電子署名の何れか一方または両方を付与した前記電子文書のデータを認証情報付与依頼の依頼元へ返信する電子文書データ返信処理と、前記タイムスタンプまたは電子署名の何れか一方または両方を付与した電子文書のデータとその電子文書の検証依頼を受信する検証依頼受付処理と、前記検証依頼された電子文書のデータに付与される前記タイムスタンプまたは電子署名の何れか一方または両方が正規に生成された情報か否かを検証する検証処理と、前記検証の結果を前記検証依頼の依頼元へ通知する検証結果通知処理と、を有することを特徴とする請求項8に記載の認証方法。」＜引用文献記載事項1-2＞「【0001】本発明は、電子文書に対する電子認証や時刻認証を行うことのできる、認証システムおよびその認証方法に関する。」＜引用文献記載事項1-3＞「【発明を実施するための最良の形態】【0027】以下、本発明の一実施形態による認証システムを図面を参照して説明する。図1は同実施形態による認証システムの構成を示すブロック図である。この図において、符号1は認証システムである。そして認証システム1は、1つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部11、電子文書のデータをデータベースに登録する電子文書保管機能部12、長期的に保管される電子文書の有効性の延長処理を行う長期保証機能部13、電子文書などのデータに対するデジタル署名(電子署名)の付与処理を行う署名付与機能部14、電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部15、電子文書などに付与されているデジタル署名、タイムスタンプ、電子証明書などの有効性の検証を行う検証代行機能部16を備えている。また認証システム1は、タイムスタンプの生成や発行を行うTSA(Time Stamping Authority)機能部17、他のシステム等で計測された正確な時刻の受信処理などを行うTA(Time Authority)機能部18、電子証明書の発行や登録および失効情報の提供などの処理を行う電子認証局装置19、時刻配信を行う時刻配信部20を備えている。なお、認証システム1の各機能部や装置は、それぞれが別々のサーバ装置で処理されてもよいし、それら機能や装置の処理のうちの複数が同一のサーバ装置で処理されてもよい。また本実施形態においてタイムスタンプとは、電子文書を基に所定のアルゴリズムにより生成した情報と時刻情報との組合せの情報をTSA機能部17の秘密鍵で暗号化したものである。また本実施形態において電子署名とは、少なくとも電子文書を基に所定のアルゴリズムにより生成した情報を署名付与機能部14の秘密鍵で暗号化したものである。【0028】また、認証システム1は業務システムと通信ネットワークを介して接続されている。業務システムは電子文書等を端末や他のシステムとの間で送受信して、各種業務処理を行うシステムである。そして本実施形態において認証システム1は、(a)デジタル署名付与依頼、(b)タイムスタンプ付与依頼、(c)デジタル署名やタイムスタンプや電子証明書の検証依頼、(d)電子文書保管の保管依頼、(e)時刻同期依頼、などの通知を業務システムを介して受信し、それらの依頼に応じた処理を上述の各機能部で行う。」＜引用文献記載事項1-4＞「【0032】 (b)タイムスタンプ付与処理タイムスタンプ付与機能部15は、ファイル一体型タイムスタンプ付与処理、独立型タイムスタンプ付与処理、タイムスタンプ一括付与処理などを行う。ここでファイル一体型タイムスタンプ付与処理とは、電子文書にタイムスタンプの情報を格納する処理である。また独立型タイムスタンプ付与処理とは、電子文書とは別に当該電子文書のタイムスタンプを格納したファイルデータを生成する処理である。またタイムスタンプ一括付与処理とは、大量の文書データに対するタイムスタンプの生成と当該タイムスタンプの付与を行う処理である。【0033】図3はタイムスタンプの付与処理のフローを示す図である。次に、本実施形態によるタイムスタンプの付与処理について順を追って説明する。タイムスタンプ付与処理を行う際の1例としては、まず連係処理部11が業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信する(ステップS201)。次に連係処理部11は、当該タイムスタンプ付与依頼と電子文書のデータをタイムスタンプ付与機能部15へ転送する。タイムスタンプ付与機能部15は電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求をTSA機能部17に通知する(ステップS202)。そしてTSA機能部17においてタイムスタンプが生成され(ステップS203)、タイムスタンプ付与機能部15がタイムスタンプを受信する。なおタイムスタンプの生成処理の詳細については後述する。そしてタイムスタンプ付与機能部15は、受信したタイムスタンプを電子文書のデータ内に格納する(ステップS204)。これにより電子文書へのタイムスタンプ付与の一連の処理が完了する。タイムスタンプ付与機能部15はタイムスタンプを付与した電子文書のデータを連係処理部11を介して業務システムへ返信する(ステップS205)。【0034】なお、上述のタイムスタンプ付与処理においては、電子文書にタイムスタンプの情報を格納するファイル一体型タイムスタンプ付与処理について説明したが、独立型タイムスタンプ付与処理を行うようにしても良い。この場合、タイムスタンプ付与機能部15はTSA機能部17から受信したタイムスタンプを別ファイルに格納し、例えばその別ファイルのファイル名の一部に電子文書のファイル名を用い、電子文書と別ファイルとの関連性を持たせる処理などを行う。そして電子文書とタイムスタンプを格納したファイルを業務システムへ返信する。」＜引用文献記載事項1-5＞「【0046】次にTSA機能部について説明する。 TSA機能部17はタイムスタンプ要求受信処理、タイムスタンプ生成処理、時刻監視処理、時刻配信・監査受信処理、TSA証明書設定処理などを行う。タイムスタンプ要求受信処理は、タイムスタンプ付与機能部15からタイムスタンプ要求を受信する処理である。またタイムスタンプ生成処理は、タイムスタンプ付与機能部15から受信した電子文書のハッシュ値とTA機能部18から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれをタイムスタンプとして返信する処理である。また時刻監査処理はTA機能部18から受信した時刻にずれがないか否かなどを監査する処理である。また時刻配信・監査受信処理は、TA機能部18からの時刻受信と、時刻を受信しているTA機能部18が信頼できるTAか否かの情報を第三者期間のシステムなどから受信する処理などを行う。またTSA証明書設定処理においては、タイムスタンプの生成に用いる秘密鍵に対する公開鍵証明書を電子認証局装置19から受け取り、TSA機能部17において管理する処理である。」＜引用文献2＞金井洋一ほか二名,「原本性保証電子保存システム(TｒｕｓｔｙCabineｔ)の開発」,RICOH TECHNICAL REPORT,株式会社リコー,2000年11月30日,Nｏ.26,ｐ.97-103 ＜引用文献記載事項2-1＞「TrustyCabinetによる原本の保存処理についてFig.3を元に簡単に説明する. (1)業務システムからTrustyCabinetに原本として保存したい電子文書をネットワーク経由で送信する. (2)TrustyCabinetの主制御プログラム(原本性保証カーネルという)が電子文書を受け取る. (3)原本性保証カーネルは受け取った電子文書の属性情報(作成者,日時ファイル構成等)をXMLで記述,作成する. (4)作成した属性情報と電子文書を原本ファイルとしてTrustyCabinetの内部ハードディスクに保存する. (5)原本性保証カーネルは,原本ファイルと,原本リスト(原本の台帳に相当)に対して公開鍵暗号方式による電子署名を自動的に付与する.」(99頁右欄第1行?第14行) ＜引用文献3＞特開2007-60336号公報(平成19年3月8日出願公開) ＜引用文献記載事項3-1＞「【0012】システム100を利用するユーザ端末101は、電子文書を図6に示すように処理をする。図7には、図6の処理によって作成される電子署名付XML文書500を示す。ユーザ側端末101は、ワープロソフト等で作成し蓄積しておいた電子文書をエンコード、すなわち、電子文書を一定の規則に基づいて符号化する(S401)。エンコードされた電子文書501を、1つのブロックとしてタグ502で囲み、タグ503で囲まれた基本情報を付与してXML変換を行う(S402)。なお、基本情報とは、直接契約書とは関係なく、本システム用に付与される情報で、例えば、文書作成に用いたアプリケーションソフト、文書名、作成者、文書の種類、作成日等がある。次に、XML変換後の文書に電子署名を行い(S403)、電子署名付のXML文書を作成する。ステップS403において、電子署名を行う対象は暗号化された1つのブロックである本文501であるので、XML文書に対する署名504は、各署名部分505が1つのブロックである原本部分501に直接触れることのないように独立している。そのため、追加して署名したとしても原本の改ざんとはならない。」＜引用文献4＞特開2002-49590号公報(平成14年2月15日出願公開) ＜引用文献記載事項4-1＞「【0028】公証サービスの基本的な流れを図1にて説明する。サービス享受者110は公証サービスを希望する電子データ130にサービス享受者110のデジタル署名131を行い、公証依頼電子データ140を作成し、公証センター100に送信する。公証センター100への送信は、インターネットを介してオンラインで行なう場合と、オフラインで行なう場合がある。公証センター100はデジタル署名131の検証を行ない、問題がなければ公証依頼を受付け、電子データを一意に特定する受付け番号を付番し、電子データを保管する。公証センター100はサービス享受者110に対して受付け番号を送信する。公証センター100で保管している電子データの内容を承認者120が確認し、当該電子データの公証を行なう場合、承認者120がデジタル署名操作を行い、公証依頼電子データ140に日付や承認者、承認内容等の付加情報132を加え、電子データ130、享受者デジタル署名131、付加情報132に対して、公証センターのデジタル署名133を行なう。公証サービスの方法として、公証センターのデジタル署名の代わりに、承認者のデジタル署名を行なうことにより公証サービスを行なう形態がある。公証センターの承認者のデジタル署名を加え一体となった状態のデータを公証済電子データ141とする。公証済電子データ作成時点で、公証サービスに関する手数料を享受者に対して加算する。この公証済電子データ141は公証センター100にて一時保管される。承認者が当該電子データ130の内容に不備があるとして公証を行なわない場合は、公証を行なえない旨の付加情報132を加え、公証センターのデジタル署名133を行い、公証済電子データ141を作成し、公証センターで保管する。この場合、公証サービスに関する手数料の加算は行なわない。サービス享受者110は受付け番号にサービス享受者のデジタル署名を行い取得要求を作成して、公証センター100に送信する。公証センター100はサービス享受者のデジタル署名を検証して、問題が無ければ、公証済電子データ141を送信する。以上の手続きにより、サービス享受者110は、電子データ130に対して、公証センター100からの公証サービスを享受することができる。」＜引用文献5＞特開2001-22848号公報(平成13年1月26日出願公開) ＜引用文献記載事項5-1＞「【0007】【発明の実施の形態】以下、本発明の実施例を、図面により詳細に説明する。図1は、本発明の一実施例を示す電子文書の歴史的有効性証明方法を説明するためシステム構成図である。クライアントコンピュータEE1?EE3および公証機関NAはインターネット等のネットワークNに接続されている。登録申請者CL1は、電子文書DOCをクライアントコンピュータEE1を用い、電子証明書CRT1を使用して登録申請者の電子署名を付与し、公証機関NAに申請する。公証機関NAでは、サーバコンピュータ(図示省略)でこれを受信し、受付時刻T1aを記録するとともに、電子文書が全て揃っているか、不備な箇所はないか否かを検査し、登録直前の時刻を登録時刻T1bとして安全な保管装置DBにこの電子文書を登録する。すなわち、公証機関NAは登録要求に登録時の時刻情報(受付時刻T1aまたは登録直前時刻T1bまたはそれらの両方)を付与し、登録時に有効である電子証明書CRTNA1を使用して、公証機関の電子署名を付与し、これを原本ORGとして登録番号NUMと関連付けて保管装置DBに保管する。また、原本ORGの複製である正本ORG2に登録番号NUMを付与した登録申請応答を返却する。登録申請応答を受信した登録申請者CL1は、登録申請応答の含まれる正本ORG2および登録番号NUMを格納媒体に格納する。ここで返却された正本ORG2は、登録時に有効であった公証機関の電子証明書CRTNA1の有効期限の範囲でしか、その存在および内容の証明を行うことはできない。なお、電子文書が登録される安全な保管装置DBとしては、例えば半永久的年数で電子文書を保管することができる磁気ディスク、光磁気ディスク、CD-ROM等の電子記憶装置が使用される。【0008】ここで、本発明におけるサーバコンピュータを含む公証機関の機能を説明する。図6は、公証機関のサーバコンピュータの構成図である。図6に示すように、公証機関NAは電子文書の存在に対し有効期限を越えた歴史的有効性を証明するためのサーバコンピュータを備えており、ネットワークNに接続された各クライアントコンピュータEE1,EE2,EE3を含めて電子文書証明システムを形成している。この公証機関NAのサーバコンピュータには、電子文書に登録時の時刻情報を付与する手段を備えている。すなわち、CPU12は、通信制御部(CCU)19がネットワークを介してクライアントコンピュータから電子文書の登録申請、直接証明申請、間接証明申請等が送られてくると、これを受信してバス14を経由してRAM16に格納する。次に、CPU12は、サーバコンピュータのバス14に接続されたタイマ20あるいはタイマサーバから時刻を取得し、RAM16に格納された最新の申請書に自動的に時刻を付与する。この場合、電子文書に付与される登録時の時刻情報は、電子文書の登録を受付けた時点の時刻情報T1a、あるいは公証機関により電子文書が全部揃ったことが確認された時点の時刻情報T1b、あるいは前記両方がそれぞれ独立した時刻情報T1a,T1bとして付与されるか、代表的時刻T1を付与することも可能である。なお、電子文書が揃ったことをチェックする方法は、HDD17に格納されているチェックソフトをCPU12が取り出し、実行することにより行うことができる。また、サーバコンピュータには、登録時に有効である電子証明書を使用して電子署名を付与する手段も含まれている。例えば、CPU12が受領した正本または登録番号と磁気ディスク17の保管装置DBに記憶されている原本または登録番号と照合し一致した場合には、HDD17に格納された証明文を申請応答中に書込むとともに、公証機関の署名も書込み、かつプリンタにも出力することができる。さらに、サーバコンピュータでは、時刻情報付与手段(タイマ20,CPU12)により付与された時刻情報と電子署名付与手段(ROM15,CPU12)により付与された電子署名物を、ディスク17の保管装置DBに安全に保管する。すなわち、CPU12は、RAM16に格納された登録申請、直接または間接証明申請に時刻情報と電子署名を書込んだ後、これを読み出しバス14を経由させてディスク17の保管装置DBの所定場所に登録する。・・・中略・・・【0011】図2は、図1に示す電子文書登録時の処理シーケンスチャートであり、また図5は、登録時、直接証明申請時、間接証明申請時の各処理のメッセージデータの構成図である。登録申請者(CL1)は、クライアントコンピュータ(EE1)を用いて電子文書(DOC)に登録申請者署名(S1)を付与し、登録申請要求(M1)を公証機関(NA)に送信する。クライアントコンピュータ(EE1)からサーバコンピュータに送信される登録申請要求M1は、図5(a)に示すように、電子文書(DOC)と登録申請者の署名(S1)とから構成される。公証機関(NA)では、登録申請要求(M1)の登録申請者署名(S1)を検証し、登録時の時刻情報(T1)を付与し、電子証明書(CRTNA1)を用いて公証機関署名(SNA1)を付与し、登録番号(NUM)を付与し、これを原本(ORG)として登録番号(NUM)と関連付けて保管装置(DB)に保管する。なお、登録時の時刻情報(T1)には、前述のように、登録申請要求を受信した時刻(T1a)と、電子文書(DOC)を電子的にチェックして最低条件の不備がないことを確認した後の登録直前の時刻(T1b)とがあり、これらのうち一方を時刻情報(T1)として付与してもよく、また両方を付与してもよい。保管装置(DB)に保管される原本は、図5(c)に示すように、電子文書(DOC)、登録申請者署名(S1)、時刻情報(T1)、公証機関署名(SNA1)から構成される。【0012】次に、サーバコンピュータは、原本(ORG)の複製である正本(ORG2)に登録番号(NUM)を付与した登録申請応答(M2)をクライアントコンピュータに返却する。登録申請応答(M2)は、図5(b)に示すように、原本と同じ要素からなる正本(ORG2)と、登録番号(NUM)から構成される。一方、登録申請者CL1は登録申請応答(M2)を受信すると、公証機関署名(SNA1)を検証し、登録申請応答(M2)に含まれる正本(ORG2)および登録番号(NUM)を格納媒体等に保管する。ここで返却された正本(ORG2)は、登録時に有効であった公証機関の電子証明書(CRTNA1)の有効期限の範囲でしかその存在および内容の証明を行うことはできない。」＜引用文献6＞「広告企画 2006年注目のPC・Neｔｗｏｒk キーワード高機能PDF」,日経パソコン,日経BP社,2005年12月26日,Nｏ.496,ｐ.109 ＜引用文献記載事項6-1＞「例えば電子メールをPDFに変換する場合、添付ファイルやリンクをPDF内に保持し、さらに送信者、日付、タイトルなどは自動的にしおりにすることができる。」(左欄第23行?26行) ＜引用文献記載事項6-2＞「存在証明や改ざん対策に効果的なタイムスタンプ機能によって証拠力を高めれば、e-文書法などへの対応も可能になる。」(右欄第13行?第15行) ＜引用文献記載事項6-3＞「」(右欄) ＜引用文献記載事項6-4＞「高機能PDFの作成・活用に欠かせないのが「Adobe Acrobat 7.0」。各種アプリケーションの文書ファイルだけでなく、Webページや電子メールなど、あらゆる文書を素早くPDFに変換可能だ。また、複数の文書ファイルを束ねたPDFの作成・管理・活用も簡単にできる。」(下欄外左欄第5行?第6行) ＜引用文献記載事項6-5＞「さらに、IDやパスワード、電子印鑑・タイムスタンプ、電子封筒といったセキュリティ対策も充実。」(下欄外右欄第1行?第3行) (2)参考文献本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となった下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。(下線は当審付与。) ＜参考文献1＞特開2002-369190号公報(平成14年12月20日出願公開) ＜参考文献記載事項1-1＞「【0079】本実施例では、判定部103を設けているが、判定部103を設けないことも可能である。この場合には、デジタル署名部104は、たとえば、「本認証局は、36598502(下移動、左下移動、左回転、右下移動、左上移動、左回転、右移動、上移動)という情報を送信し、2001年4月29日23時34分に、添付の画像データを受信したことを証明します。添付の画像データが、上記の情報により変化したものかどうかを、ご確認ください。」という情報にデジタル署名を付して送信する。認証局の利用者は、受け取った添付の画像データを、実際に目で見て確かめるか、別途判定プログラムを起動して判定することができる。」＜参考文献記載事項1-2＞「【0102】本実施例では、画像入力装置として、カメラシステム200を用いているが、任意の画像入力送信装置を用いることができる。【0103】第一に、画像入力送信装置として、カメラ付携帯電話を用いるものが挙げられる。図4は、本発明の画像入力送信装置の一例であるカメラ付携帯電話の装置構成例を示す外観図である。図4を参照して、カメラ付携帯電話の装置構成例について以下に説明する。・・・中略・・・【0110】カメラシステム200とカメラ付携帯電話400の他にも、画像入力装置としては様々なものを用いることができる。例を挙げれば、カメラ付情報携帯端末、ネットワーク接続機能を有するカメラ付コンピュータ、ネットワーク接続機能を有するカメラ付ロボット、ネットワーク接続機能を有する監視カメラ、ネットワーク接続機能を有するデジタルビデオカメラ、ネットワーク接続機能を有するデジタルカメラなどがあるが、これらに限定されない。」＜参考文献2＞特開2004-258850号公報(平成16年9月16日出願公開) ＜参考文献記載事項2-1＞「【0009】電子公証サービス代行依頼用システム110は、代行依頼用の端末であり、電子公証サービスの利用希望者側の計算機である。電子公証サービス代行システム100は、ネットワークを介して電子公証サービス代行依頼用システム110に接続される代行申請用の端末であり、電子公証サービスの代行者側の計算機である。電子公証センタ120は、ネットワークを介して電子公証サービス代行システム100に接続され、電子公証業務を行う電子公証人側の計算機を含む。電子公証サービス代行依頼用システム110は、その外部記憶装置上にデータベース111を有する。データベース111は、電子公証サービス代行システム100を介して電子公証センタ120へ送信する電子データおよび電子公証センタ120から受信する電子データを格納する。電子公証サービス代行システム100は、その外部記憶装置上にデータベース101を有する。データベース101は、電子公証サービス代行依頼用システム110から受信した各電子データに対応して電子公証センタ120から受信した受付番号を格納する。」＜参考文献3＞特開2006-59288号公報(平成18年3月2日出願公開) ＜参考文献記載事項3-1＞「【請求項1】公的機関が公文書の電子申請サービスを提供する電子申請処理用のコンピュータと、このコンピュータに対して暗号化通信により電子申請を行う電子申請端末とを通信網を介して接続した電子申請システムにおいて、前記電子申請端末は、前記電子申請処理用のコンピュータに対して複数の申請者が連名で電子申請するための申請書を要求する手段と、前記要求に応じて前記電子申請処理用のコンピュータより申請書及び連名署名用の添付ファイルを受信する手段と、必要事項を記入し代表の申請者が電子書名を行った申請書に、前記連名署名者の氏名毎に電子署名された添付ファイルを添付して前記電子申請処理用のコンピュータへ送信する手段とを備え、前記電子申請処理用のコンピュータは、電子申請サービスのための各種申請書及び添付ファイルが登録されたドキュメント記憶手段と、電子申請された申請情報が登録される申請情報記憶手段と、前記電子申請端末より送信された、複数の申請者が連名で電子申請するための申請書の要求を受信する手段と、前記受信された要求に応じて、前記ドキュメント記憶手段より該当申請書及び添付ファイルを読み出して送信する手段と、前記電子申請端末より送信された電子署名された申請書及び添付ファイルを受信する手段と、受信された申請書に対して発行した到達番号及び問い合わせ番号を前記電子申請端末へ通知する手段と、前記申請書及び添付ファイルの内容を到達番号及び問い合わせ番号に対応付けて申請情報として前記申請情報記憶手段に登録すると共に、前記申請書及び添付ファイルの署名を検証する手段と、前記署名の正当性が検証された場合、前記電子申請端末に対してアクセス先情報を記述した受領通知を行う手段とを具備したことを特徴とする電子申請システム。」＜参考文献記載事項3-2＞「【0026】電子申請端末2では、申請書類一式を受信すると(S105)、ブラウザソフトウェアは、申請書類一式のうちの申請書を、自身の画面で、プラグインされたPDFファイル閲覧用のソフトウェアで開く。【0027】連絡人(代表申請者)である申請者Aと共同申請者である連名者Bが今回連名で電子申請を行うものとする。申請者Aと連名者Bが順に添付書類(PDFファイル)の必要項目に情報を入力した後、複数署名を付与する(S106)。電子署名自体の機能についてはPDFファイル閲覧用のソフトウェアの機能である。そして、最後に、申請者Aは、申請書様式に必要事項を入力し、その申請書様式に添付書類を付与し、代表として、申請書に電子署名を付与する(S107)。【0028】具体的な例で説明すると、図5に示すように、ブラウザソフトウェアの画面に表示された申請書50には、申請内容記入欄51、添付欄52、連絡欄53、署名付与欄54が設けられている。連絡欄53は、申請者の氏名(申請者名)、住所、メールアドレス、電話番号等を記入する欄である。申請者Aは、申請内容記入欄51、連絡欄53へ必要事項、つまり申請内容を記入し、添付欄52の複数署名用添付ファイル名をクリックすると、複数署名用の添付ファイル60がPDFファイル閲覧用のソフトウェアによって開かれる。複数署名用の添付ファイル60には、複数の連名者名欄55、電子署名欄56等が設けられている。」＜参考文献記載事項3-3＞「【0042】電子署名の検証により正当性が確認されると、オペレータは、所定の文書作成ソフトウェアを起動して、受け付け結果と審査結果とを入力することで(S125)、公文書(例えば公文書の表紙としてのPDF文書ファイルと、各申請者A,B用の公文書(添付ファイル)2通等を作成する(S126)。最後に、オペレータは、電子署名の操作を行うことで、作成された公文書に対して文書作成ソフトウェアが電子署名を行い(S127)、電子申請処理サーバ1の公文書記憶部17へ登録する(S128)。なお、作成した公文書に対して電子署名を行うことを公印付与という。」 3.引用発明の認定 (1) ア.引用文献1は引用文献記載事項1-1や1-2記載のごとき「認証システムおよびその認証方法」を説明する文献であるところ、引用文献記載事項1-3の記載などから、該「認証システム」は「1つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部11」や「電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部15」、「タイムスタンプの生成や発行を行うTSA(Time Stamping Authority)機能部17」、「他のシステム等で計測された正確な時刻の受信処理などを行うTA(Time Authority)機能部18」等を有している。そして、引用文献記載事項1-3の「認証システム1の各機能部や装置は、それぞれが別々のサーバ装置で処理されてもよい」との記載や引用文献記載事項1-4の記載等から、該「連係処理部11」と該「タイムスタンプ付与機能部15」とは、これに接続された「TSA機能部17」や該「TSA機能部17」に接続された「TA機能部18」を利用して、「タイムスタンプ付与処理」を行うシステムとして働くものであると見ることができる。イ.したがって、引用文献1には「1つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部と電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部とを備え、正確な時刻の受信処理などを行うTA機能部に接続されタイムスタンプの生成や発行を行うTSA機能部に接続された、タイムスタンプ付与処理システム」が記載されていると言える。 (2)上記引用文献記載事項1-4等から、「前記タイムスタンプ付与処理は、前記連係処理部が、前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信し、当該タイムスタンプ付与依頼と前記電子文書のデータを前記タイムスタンプ付与機能部へ転送し、前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記TSA機能部に通知し、前記TSA機能部においてタイムスタンプが生成され、前記タイムスタンプ付与機能部が該タイムスタンプを受信し、受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理を行うことによりなされるもの」であり、また、「前記タイムスタンプ付与機能部は前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信するもの」であると言える。 (3)上記引用文献記載事項1-5等から、「前記TSA機能部は前記タイムスタンプ付与機能部から前記タイムスタンプ要求を受信する処理と、前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記TA機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うもの」であると言える。 (4)よって、引用文献1には、下記引用発明が記載されていると認められる。＜引用発明＞「1つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部と電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部とを備え、正確な時刻の受信処理などを行うTA機能部に接続されタイムスタンプの生成や発行を行うTSA機能部に接続された、タイムスタンプ付与処理システムであって、前記タイムスタンプ付与処理は、前記連係処理部が、前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信し、当該タイムスタンプ付与依頼と前記電子文書のデータを前記タイムスタンプ付与機能部へ転送し、前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記TSA機能部に通知し、前記TSA機能部においてタイムスタンプが生成され、前記タイムスタンプ付与機能部が該タイムスタンプを受信し、受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理を行うことによりなされるものであり、前記タイムスタンプ付与機能部は前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信するものであり、前記TSA機能部は前記タイムスタンプ付与機能部から前記タイムスタンプ要求を受信する処理と、前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記TA機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うものであるタイムスタンプ付与処理システム」 4.対比以下に、本願発明と引用発明とを比較する。 (1) ア.引用発明の「タイムスタンプ付与機能部」では「受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理」がなされるのであるから、引用発明も「データ作成装置」と言えるものである。イ.引用発明における「業務システム」は、本願発明における「ユーザ端末」に対応付けられるものであるところ、両者は「ユーザ装置」と言えるものである点で共通する。ウ.引用発明における「ハッシュ値」は本願発明における「ハッシュ値」に対応付けられるものであるところ、前者は「タイムスタンプ付与機能部」が「TSA機能部に通知」するものであるから、後者と同様に「データ作成装置から送信されたハッシュ値」と言えるものである。引用発明における「タイムスタンプ」は本願発明における「日時保証情報」に対応付けられるものであるところ、前者は「前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記TA機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化」したものなのであるから、後者と同様に「このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報」と言えるものである。そして、引用発明における「TSA機能部」は本願発明における「タイムスタンプ付与装置」に対応付けられるものであるところ、前者は「前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記TA機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うもの」であるから、両者は「データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置」と言えるものであり、また引用発明も該「タイムスタンプ付与装置と通信可能に接続された」ものであると言える。エ.したがって、引用発明と本願発明とは「ユーザ装置及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置」と言えるものである点で共通する。 (2)引用発明における「業務システム」から受信される「電子文書のデータ」はタイムスタンプ付与の「対象」となる「原本データ」とも言えるものであり、また、引用発明における「連係処理部」は、本願発明における「原本データ受信手段」に対応付けられるものであるところ、前者は「前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信」するものであるから、引用発明と本願発明とは「対象となる原本データを前記ユーザ装置から受信する原本データ受信手段」を備える点で共通すると言える。 (3) ア.引用発明においてハッシュ値の算出対象となる「電子文書のデータ」は、本願発明における「中間ファイル」にも対応付けられるものであるところ、前者へのタイムスタンプの格納が「ファイル一体型タイムスタンプ付与処理」と言われるように、前者も「ファイル」に格納されているものであることは明らかである。また、前者は「電子文書のデータ」であり、後者は「前記格納された原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル(PDF)形式のファイルに、前記受信した原本データを追加して記憶することで」「作成」された「1つの中間ファイル」であるから、両者は「原本データを持つファイル」と言えるものである点で共通する。イ.引用発明においては「前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記TSA機能部に通知」するのであるから、引用発明も「該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する」ものであると言える。ウ.よって、引用発明と本願発明とは「該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段」を備える点で共通すると言える。 (4)引用発明においては「前記タイムスタンプ付与機能部が該タイムスタンプを受信」することがなされるのであるから、引用発明と本願発明とは「前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段」を備えている点で共通すると言える。 (5)引用発明においては「受信した該タイムスタンプを前記電子文書のデータ内に格納する」のであるから、引用発明と本願発明とは「受信した日時保証情報を前記ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段」を備える点で共通すると言える。 (6)引用発明においては「前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信する」のであるから、引用発明と本願発明とは「この証明済ファイルを前記ユーザ装置に送信する証明済ファイル送信手段」を備える点で共通すると言える。 (7)よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。＜一致点＞「ユーザ装置及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、対象となる原本データを前記ユーザ装置から受信する原本データ受信手段と、該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段と、受信した日時保証情報を前記ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、この証明済ファイルを前記ユーザ装置に送信する証明済ファイル送信手段と、を備えるデータ作成装置。」＜相違点1＞本願発明におけるユーザ装置は「ユーザ端末」である。 (これに対し、引用文献1には、引用発明における「業務システム」が「端末」であるとの記載は無い。) ＜相違点2＞本願発明においては「格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載した」「ファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する中間ファイル作成手段」を備え、タイムスタンプ要求手段においてはこの「中間ファイル」のハッシュ値を計算し、証明済ファイル作成手段においては日時保証情報をこの「中間ファイル」に添付している。 (これに対し、引用文献1には本願発明の「中間ファイル作成手段」に相当する手段の記載はなく、「業務システム」から受信されるものも、「タイムスタンプ付与機能部」へ転送されるものも、「タイムスタンプ」が格納されるものも、全て「電子文書のデータ」と表現している。) ＜相違点3＞本願発明における中間ファイルは「ポータブルドキュメントフォーマットファイル(PDF)形式の」ファイルである。 (これに対して、引用発明においては、「タイムスタンプを前記電子文書のデータ内に格納すること」ができるファイルフォーマットを採用していることは明らかであるが、これがPDF形式である旨の明示はない。) 5.判断以下に、上記相違点について検討する。 (1)相違点1についてタイムスタンプ付与などの証明依頼を個人用PCなどの「端末」と言えるような規模・形態の装置から行うことは、当該分野においては極めて一般的なものであり(必要があれば参考文献記載事項1-2、2-1、3-1等参照)、引用発明の「業務システム」の均等手段としての「ユーザ端末」は、当業者においては何らの創意も要せず自然に想起されるものであり、引用発明における「業務システム」として「ユーザ端末」を採用すること、すなわち、上記相違点1に係る構成を採用することは、当業者であれば適宜になし得た設計変更にすぎないものである。 (2)相違点2についてデータに署名等の情報を付加する際に、当該データに関する属性情報などの付加情報を付加することは、一般的に行われていることであり、また、係る付加情報として情報の受信日時やファイル名は適宜に採用されている項目にほかならない。(必要があれば引用文献記載事項2-1、3-1、4-1、5-1、参考文献記載事項1-1参照) してみると、引用発明において「格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載した」「ファイルに、前記受信した原本データを追加して記憶することで1つの中間ファイルを作成する中間ファイル作成手段」を設け、この「中間ファイル」のハッシュ値を計算し、この「中間ファイル」にタイムスタンプを添付するように構成すること、すなわち上記相違点2に係る構成を採用することは、当業者であれば容易に想到し得たものである。 (3)相違点3についてポータブルドキュメントフォーマットファイル(PDF)形式は、添付ファイル機能や署名機能を有し存在証明や申請書等に好適なファイルの形式として良く知られているものであり(必要があれば引用文献記載事項6-1?6-5、参考文献記載事項3-2、3-3等参照)、上記「中間ファイル」の形式として「ポータブルドキュメントフォーマットファイル(PDF)形式」を採用すること、すなわち上記相違点3にかかる構成を採用することは、当業者であれば、上記相違点2にかかる構成の採用に際し、適宜に選択・採用し得た設計的事項にすぎない。 (4)してみると、本願発明の構成は引用文献に記載された発明に基づいて、当業者が容易に想到し得たものである。また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。よって、本願発明は、引用文献に記載された発明に基づいて、当業者が容易に発明をすることができたものである。 6.小結以上のとおり、本願請求項1に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。第4.むすび上記第2.のとおり、本願は、明細書及び特許請求の範囲の記載が、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていないものであり、また、上記第3.のとおり、本願請求項1に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、本願は特許法第29条第2項の規定により特許を受けることができないものである。したがって、本願について「原査定を取り消す。この出願の発明は特許をすべきものとする」との審決をすることはできない。よって、上記結論のとおり審決する。
審理終結日	2014-04-24
結審通知日	2014-04-25
審決日	2014-05-08
出願番号	特願2011-185580(P2011-185580)
審決分類	P 1 8・ 121- WZ (G06F) P 1 8・ 537- WZ (G06F) P 1 8・ 536- WZ (G06F)
最終処分	不成立
前審関与審査官	青木重徳
特許庁審判長	仲間晃
特許庁審判官	石井茂和山崎達也
発明の名称	データ作成装置、方法及びコンピュータプログラム
代理人	粕川敏夫

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