【事件の表示】
　特願２０１１−１８５５８０「データ作成装置、方法及びコンピュータプログラム」拒絶査定不服審判事件〔平成２４年　１月１２日出願公開、特開２０１２−　　９０５９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　
１．出願までの経緯
　平成２２年２月３日に特願２０１０−０２２３９６号が出願され、
これを原出願とする特許法第４４条第１項の規定による新たな特許出願（以下「分割出願」と記す。）として、
平成２２年７月２０日に特願２０１０−１６３４２１号が出願され、
これを原出願とする分割出願として、
平成２３年８月２９日に本件請求に係る出願（以下「本願」と記す）が出願された。
　
２．原審の経緯
　本願は上記のように、
平成２２年２月３日を出願日とみなされる分割出願として、
平成２３年８月２９日に出願されたものであって、
平成２３年１１月１０日付けで手続補正書が提出され、
平成２３年１１月１１日付けで手続補正書が提出され、
平成２４年１月２３日付けで審査請求がなされ、
平成２４年２月２０日付けで拒絶理由通知（平成２４年２月２３日発送）がなされ、
平成２４年４月２３日付けで意見書が提出され、
平成２４年５月１４日付けで拒絶査定（平成２４年５月１６日謄本発送）がなされたものである。
　
３．当審での経緯
　本件審判請求は、
平成２４年８月１５日付けで「原査定を取り消す。この出願の発明は特許をすべきものとする、との審決を求める。」との趣旨でなされたもので、
同日付けで手続補正書が提出され、
平成２４年９月５日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
平成２５年４月１５日付けで当該報告に対する意見を求める旨の審尋（平成２５年４月１６日発送）がなされたが、これに対しての回答は無く、
平成２５年１１月２７日付けで上記平成２４年８月１５日付けの手続補正書による補正の却下の決定（平成２５年１２月１０日発送）がなされるとともに、
同日付けで拒絶理由通知（平成２５年１１月２９日発送）がなされ、
平成２６年１月１７日に面接（平成２６年１月２２日入力）を行い、
平成２６年１月２８日付けで意見書が提出されるとともに、
同日付けで手続補正書が提出されたものである。
　
　
第２．特許法第３６条（明細書の記載要件）について
　
１．当審拒絶理由
　上記平成２５年１１月２７日付けの拒絶理由通知書（以下、「当審拒絶理由通知書」と記す。）によって通知された拒絶理由のうち特許法第３６条についての拒絶理由の概要は下記のとおりのものである。
　
『２．この出願は、明細書及び特許請求の範囲の記載が下記の点で、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　 記
・・・（中略）・・・
　
（５）請求項１、２、３、４、５に「前記格納された原本データのファイル名」とあるが、「格納された原本データのファイル名」は前記されていない。
　したがって、請求項１、２、３、４、５に係る発明は明確でない。
　
・・・（中略）・・・
　
（８）本願発明の詳細な説明の段落【０００２】において「このような現状のもと、特許文献１には電子公証サービスを実現するための技術が開示されている。特許文献１の項目〔００２８〕では、公証サービスを希望する電子データ（１３０）に対して、公証サービス享受者のデジタル署名（１３１）と付加情報（１３２）を加え、これに公証センターの承認者のデジタル署名（１３３）を加え一体となった状態のデータを公証済電子データ（１４１）とする。このように、原本である電子データ（１３０）はデジタル署名（１３１）等が加えられることにより、元の電子データとは同一ではなくなっている。証明が必要とされているのは変更前の元データであるので、証明のために変更せざるを得ないのでは本末転倒である。また、付加情報（１３２）には、日付や承認者、承認内容等が含まれており、電子データ（１３０）の証明書の役割をなすものであるが、本来証明書というものは、それが証明する対象とは相互に独立のはずであり、対象となるデータに付加されるものではない。」と従来技術の問題点の説明がなされているが、当該従来技術の問題点は当業者が理解しうるものではなく、本願請求項１、２、３、４、５に係る発明が解決しようとする課題が明確になされていない。（ここで従来技術として挙げられる文献（引用文献４）の何処にも、「付加情報」や「署名」が加わる際に「電子データ」が変更される旨の説明は見当たらない。また、通常は署名等の付加によって元データが変更されるものではないので、技術常識からみて該従来技術の問題点の記載は理解しがたいものである。）
　したがって、この出願の発明の詳細な説明は、請求項１、２、３、４、５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものである。
　
（９）本願の発明の詳細な説明においては、段落【００２５】に「ファイル本体には原本データＤが添付されており、署名欄には日時保証情報Ｃが書込まれている。ＰＤＦ形式のファイルには、署名欄に書き込んだデータを変更したり削除したりすることはできないという特徴がある。」とある一方、段落【００２６】に「このソフトウェアは、次のような機能を備えている。すなわち、証明済ファイルＦ３から日時証明情報Ｃを削除した後のファイルのハッシュ値を計算する機能」とあり、互いに矛盾する説明がなされている。このため、当業者が本願請求項１、２、３、４、５に係る発明を実施しようとしたときに、本願の発明の詳細な説明の記載から「添付」の処理として如何なる処理を採用すれば良いのかを明確に把握することができない。
　したがって、この出願の発明の詳細な説明は、当業者が請求項１、２、３、４、５に係る発明を実施することができる程度に明確かつ十分に記載されていないものである。
　
（１０）本願発明の詳細な説明においては、段落【０００２】で上記（９）で論じた従来技術の問題点の説明がされ、これに続いて【発明が解決しようとする課題】として段落【０００４】に「証明するために、対象となるデジタルデータを変更するという問題を解決することである。紙媒体への刻印による証明法は、原本データ部分と証明書部分とが独立であり、かつ両者の改変は不可能であり、かつ両者の対応に疑義が生じる余地はない。本発明は、原本がデジタルデータの場合にも、このような証明法を実現することを目的とする。」とあるが、本願請求項１、２、３、４、５に係る発明が何故従来技術の問題点を解消し該課題を解決し得るものであるのかの説明が明確になされていない。
　敷衍するに、本願発明においても「原本データ」は「中間ファイル」に「ファイル名」や「日時」などとともに「格納」され、さらに該「中間ファイル」には「日時保証情報」が「添付」されるところ、発明の詳細な説明を詳細に精査しても、これらの「格納」「添付」等の処理が如何なる処理を意味し、上記従来技術における「付加」する処理や「加え」る処理と何がどう異なるのかを正確に把握することは不可能である。（本願発明の詳細な説明の段落【０００６】に『「中間ファイル」は、原本データを受信した日付やデータ名などの事項が記載された証明書ファイルに任意個数の原本データを追加して記憶させた１個のファイルである。なお、この出願書類では、１つのファイルに１個以上の原本データを追加して記憶させる（含ませる）ことを「添付」と表現している。中間ファイルに添付された原本データには一切変更がない。』、同【０００６】に『なお、「埋め込む」とは、中間ファイルの所定の箇所に書き込むことをいう。例えば、中間ファイルのフォーマットがＰＤＦであれば、日時保証情報はファイルの属性情報の一種であり、かつ書き換え不可能な署名欄に書き込まれる。』、同【００１８】に「次にこの証明書ファイルに受信した原本データを変更することなくそのまま添付して中間ファイルを作成する。」、同【００２４】に「証明済ファイル作成手段１０は、中間ファイルＦ２に日時保証情報Ｃを埋め込み、証明済ファイルＦ３を作成する（ステップＳ６）。日時保証情報Ｃの埋め込み方はＰＤＦなどの公知のファイルフォーマットに従うものとし、詳細な説明は省略する。」等の記載、段落【００２５】及び【００２６】には上記（９）で言及した互いに矛盾する記載があるが、具体的な処理内容についての開示が無く、上記従来技術における「付加」する処理や「加え」る処理とは何がどう異なるのかが何ら説明されていない。）このため、当業者が本願請求項１、２、３、４、５に係る発明を実施しようとしたときに、本願の発明の詳細な説明の記載から「格納」や「添付」の処理として如何なる処理を採用すれば良いのかを把握することはできず、しかも、本願発明が上記従来技術の問題点を解消し上記課題を解決し得るものと認めることもできない。
　したがって、この出願の発明の詳細な説明は、当業者が請求項１、２、３、４、５に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、請求項１、２、３、４、５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものである。
　また、このため、本願請求項１、２、３、４、５の記載は、本願の発明の詳細な説明に記載された、発明の課題を解決するための手段が反映されておらず、発明の詳細な説明に記載した範囲を超えて特許を請求することとなるものであるとも言え、本願請求項１、２、３、４、５に係る発明は本願明細書の発明の詳細な説明に記載したものでないとも言える。
　また、本願請求項１、２、３、４、５で用いられている「格納」「添付」等の用語の意味・定義は、本願の発明の詳細な説明を参酌しても明確でないものであるから、この点からも本願の請求項１、２、３、４、５に係る発明は明確でないと言える。
　
（１１）本願の発明の詳細な説明の段落【００３６】に『ユーザは、原本データについてデータを格納するファイル形式を問わず簡便に内容証明を受けることができる。今後各種書類は、従来の紙媒体からデジタルデータへの移行が進むと予想されるが、本発明はデジタルデータの内容証明を簡便かつ確実に行うシステム・方法として多くの需要が見込まれると期待される。なお「簡便」とは、単にユーザの作業の簡便性だけではなく、「運用のための大がかりな組織を必要としない」という意味も含まれる。』とあるが、本願請求項１、２、３、４、５に係る発明が何故「簡便」「運用のための大がかりな組織を必要としない」発明であるのかが明確に説明されていない。
　敷衍するに、本願請求項１、２、３、４、５に係る発明においても、「タイムスタンプ付与装置」は必須のものであり、さらに「データ作成装置」や「タイムスタンプ付与装置」に接続された「コンピュータ」が必要になるのであるから、決して「簡便」なものとは言えない。また、単に存在証明をするだけであれば、「中間ファイルの作成処理日時」や「原本データのファイル名」を格納した「中間ファイル」と言う形態を採る必要は無く、「データ作成装置」を介さずに「原本データ」あるいはそのハッシュを「ユーザ端末」から直接「タイムスタンプ付与装置」に送って返送された「日時保証情報」を「原本データ」に紐付けるだけで良いのであるから、本願請求項１、２、３、４、５に係る発明は「データ作成装置」と言う通常は必要の無い構成が採用されて、より大がかりな構成となっており、到底「簡便」「運用のための大がかりな組織を必要としない」ものと認め得るものではない。
　したがって、この出願の発明の詳細な説明は、当業者が請求項１、２、３、４、５に係る発明を実施することができる程度に明確かつ十分に記載されていないものであるとともに、請求項１、２、３、４、５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものである。』
　
２．平成２６年１月２８日付け手続補正
　上記平成２６年１月２８日付けの手続補正書は特許請求の範囲を下記本願特許請求の範囲に補正するものである。
　
＜本願特許請求の範囲＞
「　【請求項１】
　ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、
　対象となる原本データを前記ユーザ端末から受信する原本データ受信手段と、
　前記格納された原本データの
データ名
原本データ
記載
ファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する
　前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、
　前記タイムスタンプ付与装置から
、前記日
　受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、
　この証明済ファイルを前記ユーザ端末に送信する証明済ファイル送信手段と、
　を備えることを特徴とするデータ作成装置。
　　【請求項２】
　ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置により行われる方法であって、
　上記データ生成装置が、
　対象となる原本データを前記ユーザ端末から受信する処理と、
　前記格納された原本データの
データ名
原本データ
記載
ファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する
　前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する処理と、
　前記タイムスタンプ付与装置から
、前記日
　受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する処理と、
　この証明済ファイルを前記ユーザ端末に送信する処理と、
　を備えることを特徴とするデータ作成方法。
　　【請求項３】
　ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたコンピュータに対して、
　対象となる原本データを前記ユーザ端末から受信する処理と、
　前記格納された原本データの
データ名
原本データ
記載
ファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する
　前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する処理と、
　前記タイムスタンプ付与装置から
、前記日
　受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する処理と、
　この証明済ファイルを前記ユーザ端末に送信する処理と、
　を実行させるコンピュータプログラム。」
　
　
３．そこで、上記当審拒絶理由書の特許法第３６条についての拒絶理由が上記平成２６年１月２８日付けの手続補正書によって解消されたか否かについて検討する。
　
（１）理由２．（５）について
　当審拒絶理由通知書の理由２．（５）において、指摘した「前記格納された原本データのファイル名」との記載は、依然として請求項１、２、３に存在しており、またその記載の前に「格納」や「格納された原本データ」「格納された原本データのファイル名」との記載は見あたらない。
　なお、この点について、意見書においては【意見の内容】「３．意見の内容」「３−２．理由２について」「（５）」において
『この点補正後の請求項１〜３の記載によれば、「前記格納された原本データのデータ名」として、「原本データを前記ユーザ端末から受信する」の受信した原本データのデータ名を示すことは明らかであるから、指摘の理由は解消したものと考えます。』
との主張がなされている。
　しかしながら、「原本データ」との用語が前記されていたとしても、指摘された「前記」との接頭語は「格納」の前に付されているのであるから、この「前記」がどの記載を指すのかは依然として不明である。
　したがって、当審拒絶理由通知書の理由２．（５）で指摘した不備は解消されていない。
　
（２）理由２．（８）について
　当審拒絶理由通知書の理由２．（８）において、指摘した段落【０００２】の記載は特に補正がなされておらず、依然として、ここに記載の従来技術の問題点は当業者が理解しうるものではない。
　なお、この点について、意見書においては【意見の内容】「３．意見の内容」「３−２．理由２について」「（８）」において
『この点本願明細書段落【０００２】の記載は、従来では、元データとデジタル署名データとが別々のデータないしはファイルとして存在しており、これを紐つけて管理するには別途何らかのデータベースなどの手段が必要であったことを述べています。また、後段は元データとその存在を証明する証明書データ（本願の「中間ファイル」に相当）は別々の独立したデータ（ファイル）として存在していたことを説明しています。
　そして、本願発明では、原本データ受信した日付が記載された中間ファイルとしてＰＤＦ形式を採用することで、この中間ファイルに原本データを格納し、中間ファイルにさら日時保証情報を格納することで、１つのＰＤＦファイルだけで、このＰＤＦに記載された「原本データを受信した日付」を証明すると共に、その受信した「原本データ」と、これらを紐付ける「日時保証情報」をそれぞれまとめて特定できる点に特徴にあります。
　以上のことから、本願明細書段落【０００２】の記載が不明瞭であるとの理由はあたらないものと考えます。』
との主張がなされている。
　しかしながら、
本願明細書の段落【０００２】の記載は
『紙媒体がある時点で存在していたことを客観的に証明するために公証役場の確定日付を利用することが行われる。これは、紙媒体の持ち主が存在を主張しても、本人の主張では信頼性に欠けるので、やはり第三者機関の介在が必要になってくるからである。
ところで、昨今は、各種書類をパソコンなどの情報処理装置で作成することが多くなり、作成されたデジタルデータの作成時期と内容を第三者によって証明してもらおうとする需要は増加の一途である。このような現状のもと、特許文献１には電子公証サービスを実現するための技術が開示されている。
特許文献１の項目〔００２８〕では、公証サービスを希望する電子データ（１３０）に対して、公証サービス享受者のデジタル署名（１３１）と付加情報（１３２）を加え、これに公証センターの承認者のデジタル署名（１３３）を加え一体となった状態のデータを公証済電子データ（１４１）とする。このように、原本である電子データ（１３０）はデジタル署名（１３１）等が加えられることにより、元の電子データとは同一ではなくなっている。証明が必要とされているのは変更前の元データであるので、証明のために変更せざるを得ないのでは本末転倒である。また、付加情報（１３２）には、日付や承認者、承認内容等が含まれており、電子データ（１３０）の証明書の役割をなすものであるが、本来証明書というものは、それが証明する対象とは相互に独立のはずであり、対象となるデータに付加されるものではない。』
というものであるから、到底
「従来では、元データとデジタル署名データとが別々のデータないしはファイルとして存在しており、これを紐つけて管理するには別途何らかのデータベースなどの手段が必要であったこと」
を述べていると解釈することはできないものである。
　したがって、当審拒絶理由通知書の理由２．（８）で指摘した不備は解消されていない。
　
（３）理由２．（９）について
　当審拒絶理由通知書の理由２．（９）において、指摘した段落【００２５】の記載も段落【００２６】の記載も補正されておらず、依然として、互いに矛盾する説明がなされていると言える。
　なお、この点について、意見書においては【意見の内容】「３．意見の内容」「３−２．理由２について」「（９）」において
『この点、ＰＤＦのフォーマットは、本意見書に添付した補足資料１によれば、「ＰＤＦの文章構造は、主に辞書を含むオブジェクトの参照関係で表現します。文書の構造情報、個別ページの描画内容、そこに表示する画像やフォントの情報などをそれぞれ独立したオブジェクトとして定義し、互いに参照させることで、階層構造をもたせています。」とあるようにＰＤＦ内の本文、署名欄、添付欄などの情報はそれぞれ独立したオブジェクトとして定義されています。
これを前提として。ご指摘いただいた段落【００２５】の内容は、ＰＤＦファイルの署名欄自体は書き込みが記載されているオブジェクトであることを説明しています段落【００２６】の「日時保証商標Ｃを削除した後のファイルのハッシュ値を計算する」というのは、日時保証情報が格納されている「署名欄」というオブジェクトは除いて、他のオブジェクト（原本データを受信した日付が記載された本文のオブジェクト、原本データが格納された添付欄のオブジェクトなど）に基づいて、ハッシュ値を再計算することを説明しております。
　つまり、タイムスタンプを押す際にハッシュ値生成の対象となるオブジェクト（証明欄のオブジェクトを除く）と、検証をする際にハッシュ値生成の対象となるオブジェクト（証明欄のオブジェクトを除く）が同じオブジェクトであることを説明しております。
これら同じオブジェクトであれば、その内容が同じであれば生成されるハッシュ値も同じのなるためです。
　このように、上記明細書の記載はＰＤＦの文書構造を斟酌すれば、上記内容を指し示しており、その記載も明確となり、ご指摘的の理由はあたらないものと考えます。』
との主張がなされている。
　しかしながら、情報が独立したオブジェクトとして定義されているからといって、書き込んだデータを変更したり削除したりすることはできないことになるわけではなく、また、日時証明情報が削除可能である旨の記載と矛盾しなくなるわけでもない。
　したがって、当審拒絶理由通知書の理由２．（９）で指摘した不備は解消されていない。
　
（４）理由２．（１０）について
　当審拒絶理由通知書の理由２．（１０）において指摘した、「何故従来技術の問題点を解消し該課題を解決し得るものであるのかの説明」は依然としてなされていない。
　なお、この点について、意見書においては【意見の内容】「３．意見の内容」「３−２．理由２について」「（１０）」において
『この点、ご指摘のように「格納」「添付」の処理自体は、「付加」する処理「加え」る処理と同義です。そして、本願明細書では、その対象となるデータの種類に応じて、これらの表現を変えただけであり、技術的意義については特に異なることはありません。
　本願発明は、ＰＤＦフォーマットを用いることにより、上述の（９）のようにデータを「付加」または「加え」るオブジェクトにより、「格納」「添付」「記載」などの表現を区別したものに過ぎません。
　したがって、上記のご指摘の理由はあたらないものと考えます。』
との主張がなされている。
　しかしながら、「格納」「添付」の処理が「付加」する処理「加え」る処理と同義であるならば、明らかに上記従来技術の問題点を解消し該課題を解決することはできない。
　したがって、当審拒絶理由通知書の理由２．（１０）で指摘した不備は解消されていない。
　
（５）理由２．（１１）について
　当審拒絶理由通知書の理由２．（１１）において指摘した、『何故「簡便」「運用のための大がかりな組織を必要としない」発明であるのか』は依然として明確に説明されていない。
　なお、この点について、意見書においては【意見の内容】「３．意見の内容」「３−２．理由２について」「（１１）」において
『上記明細書の記載は、従来は原本データと、日時保証情報データと、証明書データとは別々に管理され、所定のデータを管理するデータベースによりその紐付けを管理していました。つまり、最初に原本データからハッシュ値を生成した時点で、データベースにその原本データのデータ名とハッシュ値及び日時保証情報を関連付けて管理しておき、証明が必要となった時点で、再度原本データからハッシュ値を作成し、データベースに記憶しておいた日時保証情報のハッシュ値とを比較することで、はじめて証明書が発行されていました。
しかし、これに比べて本願発明によれば、ひとつのＰＤＦ形式の中間ファイに、「原本データを受信した日付」、「日時保証情報」、「原本データ」が一体として格納されていることから、上述の従来技術比べて管理が非常に簡便になります。またその運用において、従来では発行された日時保証情報を管理しておく組織（データベース）が必要とされましたが、本発明では、「原本データを受信した日付」、「日時保証情報」、「原本データ」がひとつのＰＤＦファイルに格納されているため、原本データ改ざんが無いことを証明するためにも、このＰＤＦファイルだけで証明が可能となる点でこの発明の独特な効果を奏するものです。
　したがって、ご指摘の理由は当たらないものと考えます。』
との主張がなされている。
　しかしながら、本願明細書の段落【０００２】記載の従来の技術でも「公証済電子データ」は「一体となった状態のデータ」なのであるから、簡便さや規模では格別相違しないはずである。
　また、本願の明細書記載の発明においても、「日時保証情報」や「原本データ」が格納された「ＰＤＦファイル」は、ユーザーが保存することになるので、従来技術の「組織（データベース）」に相当する手段が不必要になるわけではない。
　また、当審拒絶理由通知書で指摘した『本願請求項１、２、３、４、５に係る発明においても、「タイムスタンプ付与装置」は必須のものであり、さらに「データ作成装置」や「タイムスタンプ付与装置」に接続された「コンピュータ」が必要になるのであるから、決して「簡便」なものとは言えない。』との指摘や『また、単に存在証明をするだけであれば、「中間ファイルの作成処理日時」や「原本データのファイル名」を格納した「中間ファイル」と言う形態を採る必要は無く、「データ作成装置」を介さずに「原本データ」あるいはそのハッシュを「ユーザ端末」から直接「タイムスタンプ付与装置」に送って返送された「日時保証情報」を「原本データ」に紐付けるだけで良いのであるから、本願請求項１、２、３、４、５に係る発明は「データ作成装置」と言う通常は必要の無い構成が採用されて、より大がかりな構成となっており、到底「簡便」「運用のための大がかりな組織を必要としない」ものと認め得るものではない。』との指摘に関しては何ら釈明がなされていない。
　したがって、当審拒絶理由通知書の理由２．（１１）で指摘した不備は解消されていないものである。
　
４．小結
　以上のとおり、本願は、明細書及び特許請求の範囲の記載が、依然として、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていない。
　
　
第３．特許法第２９条第２項（進歩性）について
　
１．本願発明の認定
　本願の請求項１に係る発明は、平成２６年１月２８日付けの手続補正書によって補正された本願特許請求の範囲、明細書および図面の記載からみて下記本願発明のとおりのものと認める。
　
＜本願発明＞
「ユーザ端末及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、
　対象となる原本データを前記ユーザ端末から受信する原本データ受信手段と、
　格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル（ＰＤＦ）形式のファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する中間ファイル作成手段と、
　前記中間ファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、
　前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段と、
　受信した日時保証情報を前記中間ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、
　この証明済ファイルを前記ユーザ端末に送信する証明済ファイル送信手段と、
　を備えることを特徴とするデータ作成装置。」
（なお平成２６年１月２８日付けの手続補正書の【請求項１】記載の「前記格納された原本データのデータ名」との記載は、上記平成２６年１月２８日付けの意見書の【意見の内容】「３．意見の内容」「３−２．理由２について」「（５）」の主張を参酌して「格納された前記原本データのデータ名」と訂正して認定した。）
　
　
２．先行技術
　
（１）引用文献
　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり、上記平成２５年１１月２７日付けの当審拒絶理由通知書の理由３．において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
＜引用文献１＞
　特開２００７−２６６７９７号公報（平成１９年１０月１１日出願公開）
　
　＜引用文献記載事項１−１＞
「【特許請求の範囲】
【請求項１】
　１つまたは複数の端末または他のシステムと通信ネットワークを介して接続された業務システムより、電子文書のデータと当該電子文書の認証情報付与依頼を受信する認証情報付与依頼受付手段と、
　前記電子文書のデータへのタイムスタンプまたは電子署名の何れか一方または両方の付与処理を行う認証情報付与処理手段と、
　を備えることを特徴とする認証システム。
【請求項２】
　前記認証情報付与処理手段は、同時刻のタイムスタンプまたは同時刻に生成された電子署名の何れか一方または両方を、前記認証情報付与依頼受付手段により受付けた複数の電子文書それぞれに対して生成し、当該複数の電子文書への付与処理を行うことを特徴とする請求項１に記載の認証システム。
【請求項３】
　前記タイムスタンプまたは電子署名の何れか一方または両方を付与した前記電子文書のデータを認証情報付与依頼の依頼元へ返信する電子文書データ返信手段と、
　前記タイムスタンプまたは電子署名の何れか一方または両方を付与した電子文書のデータとその電子文書の検証依頼を受信する検証依頼受付手段と、
　前記検証依頼された電子文書のデータに付与される前記タイムスタンプまたは電子署名の何れか一方または両方が正規に生成された情報か否かの検証処理を行う検証手段と、
　前記検証の結果を前記検証依頼の依頼元へ通知する検証結果通知手段と、
　を備えることを特徴とする請求項１に記載の認証システム。
・・・中略・・・
【請求項８】
　１つまたは複数の端末または他のシステムと通信ネットワークを介して接続された業務システムより、電子文書のデータと当該電子文書の認証情報付与依頼を受信する認証情報付与依頼受付処理と、
　前記電子文書のデータへのタイムスタンプまたは電子署名の何れか一方または両方の付与処理を行う認証情報付与処理と、
　を有することを特徴とする認証方法。
【請求項９】
　前記認証情報付与処理において、同時刻のタイムスタンプまたは同時刻に生成された電子署名の何れか一方または両方を、前記認証情報付与依頼受付処理により受付けた複数の電子文書それぞれに対して生成し、当該複数の電子文書への付与処理を行うことを特徴とする請求項８に記載の認証方法。
【請求項１０】
　前記タイムスタンプまたは電子署名の何れか一方または両方を付与した前記電子文書のデータを認証情報付与依頼の依頼元へ返信する電子文書データ返信処理と、
　前記タイムスタンプまたは電子署名の何れか一方または両方を付与した電子文書のデータとその電子文書の検証依頼を受信する検証依頼受付処理と、
　前記検証依頼された電子文書のデータに付与される前記タイムスタンプまたは電子署名の何れか一方または両方が正規に生成された情報か否かを検証する検証処理と、
　前記検証の結果を前記検証依頼の依頼元へ通知する検証結果通知処理と、
　を有することを特徴とする請求項８に記載の認証方法。」
　
　＜引用文献記載事項１−２＞
「【０００１】
　
本発明は、電子文書に対する電子認証や時刻認証を行うことのできる、認証システムおよびその認証方法に関する
　
　＜引用文献記載事項１−３＞
「【発明を実施するための最良の形態】
【００２７】
　以下、本発明の一実施形態による認証システムを図面を参照して説明する。図１は同実施形態による認証システムの構成を示すブロック図である。この図において、符号１は認証システムである。そして
認証システム１は、１つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部１１
電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部１５、
タイムスタンプの生成や発行を行うＴＳＡ（Time Stamping Authority）機能部１７、他のシステム等で計測された正確な時刻の受信処理などを行うＴＡ（Time Authority）機能部１８
認証システム１の各機能部や装置は、それぞれが別々のサーバ装置で処理されてもよいし
【００２８】
　また、認証システム１は業務システムと通信ネットワークを介して接続されている。業務システムは電子文書等を端末や他のシステムとの間で送受信して、各種業務処理を行うシステムである。そして本実施形態において認証システム１は、（ａ）デジタル署名付与依頼、（ｂ）タイムスタンプ付与依頼、（ｃ）デジタル署名やタイムスタンプや電子証明書の検証依頼、（ｄ）電子文書保管の保管依頼、（ｅ）時刻同期依頼、などの通知を業務システムを介して受信し、それらの依頼に応じた処理を上述の各機能部で行う。」
　
　＜引用文献記載事項１−４＞
「【００３２】
（ｂ）タイムスタンプ付与処理
　タイムスタンプ付与機能部１５は、ファイル一体型タイムスタンプ付与処理、独立型タイムスタンプ付与処理、タイムスタンプ一括付与処理などを行う。ここでファイル一体型タイムスタンプ付与処理とは、電子文書にタイムスタンプの情報を格納する処理である。また独立型タイムスタンプ付与処理とは、電子文書とは別に当該電子文書のタイムスタンプを格納したファイルデータを生成する処理である。またタイムスタンプ一括付与処理とは、大量の文書データに対するタイムスタンプの生成と当該タイムスタンプの付与を行う処理である。
【００３３】
　図３はタイムスタンプの付与処理のフローを示す図である。
　次に、本実施形態によるタイムスタンプの付与処理について順を追って説明する。
　タイムスタンプ付与処理を行う際の１例としては、まず
連係処理部１１が業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信する（ステップＳ２０１）。次に連係処理部１１は、当該タイムスタンプ付与依頼と電子文書のデータをタイムスタンプ付与機能部１５へ転送する。タイムスタンプ付与機能部１５は電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求をＴＳＡ機能部１７に通知する（ステップＳ２０２）。そしてＴＳＡ機能部１７においてタイムスタンプが生成され（ステップＳ２０３）、タイムスタンプ付与機能部１５がタイムスタンプを受信する。
そしてタイムスタンプ付与機能部１５は、受信したタイムスタンプを電子文書のデータ内に格納する（ステップＳ２０４）。これにより電子文書へのタイムスタンプ付与の一連の処理が完了する。タイムスタンプ付与機能部１５はタイムスタンプを付与した電子文書のデータを連係処理部１１を介して業務システムへ返信する（ステップＳ２０５）
【００３４】
　なお、
上述のタイムスタンプ付与処理においては、電子文書にタイムスタンプの情報を格納するファイル一体型タイムスタンプ付与処理について説明した
　
　＜引用文献記載事項１−５＞
「【００４６】
　次にＴＳＡ機能部について説明する。
　ＴＳＡ機能部１７はタイムスタンプ要求受信処理、タイムスタンプ生成処理、時刻監視処理、時刻配信・監査受信処理、ＴＳＡ証明書設定処理などを行う。
タイムスタンプ要求受信処理は、タイムスタンプ付与機能部１５からタイムスタンプ要求を受信する処理である。またタイムスタンプ生成処理は、タイムスタンプ付与機能部１５から受信した電子文書のハッシュ値とＴＡ機能部１８から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれをタイムスタンプとして返信する処理である。
　
　
＜引用文献２＞
　金井洋一　ほか二名，「原本性保証電子保存システム（ＴｒｕｓｔｙＣａｂｉｎｅｔ）の開発」，ＲＩＣＯＨ　ＴＥＣＨＮＩＣＡＬ　ＲＥＰＯＲＴ，株式会社リコー，２０００年１１月３０日，Ｎｏ．２６，ｐ．９７−１０３
　
　＜引用文献記載事項２−１＞
「TrustyCabinetによる原本の保存処理についてFig.3を元に簡単に説明する．
（１）業務システムからTrustyCabinetに原本として保存したい電子文書をネットワーク経由で送信する．
（２）TrustyCabinetの主制御プログラム（原本性保証カーネルという）が電子文書を受け取る．
（３）
原本性保証カーネルは受け取った電子文書の属性情報（作成者，日時ファイル構成等）をＸＭＬで記述，作成する
（４）作成した属性情報と電子文書を原本ファイルとしてTrustyCabinetの内部ハードディスクに保存する．
（５）原本性保証カーネルは，原本ファイルと，原本リスト（原本の台帳に相当）に対して公開鍵暗号方式による電子署名を自動的に付与する．」（９９頁右欄第１行〜第１４行）
　
　
＜引用文献３＞
　特開２００７−６０３３６号公報（平成１９年３月８日出願公開）
　
　＜引用文献記載事項３−１＞
「【００１２】
　システム１００を利用するユーザ端末１０１は、電子文書を図６に示すように処理をする。図７には、図６の処理によって作成される電子署名付ＸＭＬ文書５００を示す。
　ユーザ側端末１０１は、ワープロソフト等で作成し蓄積しておいた電子文書をエンコード、すなわち、電子文書を一定の規則に基づいて符号化する（Ｓ４０１）。
エンコードされた電子文書５０１を、１つのブロックとしてタグ５０２で囲み、タグ５０３で囲まれた基本情報を付与してＸＭＬ変換を行う（Ｓ４０２）。なお、基本情報とは、直接契約書とは関係なく、本システム用に付与される情報で、例えば、文書作成に用いたアプリケーションソフト、文書名、作成者、文書の種類、作成日等がある
　次に、ＸＭＬ変換後の文書に電子署名を行い（Ｓ４０３）、電子署名付のＸＭＬ文書を作成する。
　ステップＳ４０３において、電子署名を行う対象は暗号化された１つのブロックである本文５０１であるので、ＸＭＬ文書に対する署名５０４は、各署名部分５０５が１つのブロックである原本部分５０１に直接触れることのないように独立している。そのため、追加して署名したとしても原本の改ざんとはならない。」
　
　
＜引用文献４＞
　特開２００２−４９５９０号公報（平成１４年２月１５日出願公開）
　
　＜引用文献記載事項４−１＞
「【００２８】公証サービスの基本的な流れを図１にて説明する。サービス享受者１１０は公証サービスを希望する電子データ１３０にサービス享受者１１０のデジタル署名１３１を行い、公証依頼電子データ１４０を作成し、公証センター１００に送信する。公証センター１００への送信は、インターネットを介してオンラインで行なう場合と、オフラインで行なう場合がある。公証センター１００はデジタル署名１３１の検証を行ない、問題がなければ公証依頼を受付け、電子データを一意に特定する受付け番号を付番し、電子データを保管する。公証センター１００はサービス享受者１１０に対して受付け番号を送信する。
公証センター１００で保管している電子データの内容を承認者１２０が確認し、当該電子データの公証を行なう場合、承認者１２０がデジタル署名操作を行い、公証依頼電子データ１４０に日付や承認者、承認内容等の付加情報１３２を加え、電子データ１３０、享受者デジタル署名１３１、付加情報１３２に対して、公証センターのデジタル署名１３３を行なう。
　
　
＜引用文献５＞
　特開２００１−２２８４８号公報（平成１３年１月２６日出願公開）
　
　＜引用文献記載事項５−１＞
「【０００７】
【発明の実施の形態】以下、本発明の実施例を、図面により詳細に説明する。図１は、本発明の一実施例を示す電子文書の歴史的有効性証明方法を説明するためシステム構成図である。クライアントコンピュータEE1〜EE3および公証機関NAはインターネット等のネットワークNに接続されている。登録申請者CL1は、電子文書DOCをクライアントコンピュータEE1を用い、電子証明書CRT1を使用して登録申請者の電子署名を付与し、公証機関NAに申請する。
公証機関NAでは、サーバコンピュータ(図示省略)でこれを受信し、受付時刻T1ａを記録するとともに、電子文書が全て揃っているか、不備な箇所はないか否かを検査し、登録直前の時刻を登録時刻T1ｂとして安全な保管装置DBにこの電子文書を登録する。すなわち、公証機関NAは登録要求に登録時の時刻情報（受付時刻T1ａまたは登録直前時刻T1ｂまたはそれらの両方）を付与し、登録時に有効である電子証明書CRTNA1を使用して、公証機関の電子署名を付与し、これを原本ORGとして登録番号NUMと関連付けて保管装置DBに保管する。
【０００８】ここで、本発明におけるサーバコンピュータを含む公証機関の機能を説明する。図６は、公証機関のサーバコンピュータの構成図である。図６に示すように、公証機関NAは電子文書の存在に対し有効期限を越えた歴史的有効性を証明するためのサーバコンピュータを備えており、ネットワークNに接続された各クライアントコンピュータEE1,EE2,EE3を含めて電子文書証明システムを形成している。この公証機関NAのサーバコンピュータには、電子文書に登録時の時刻情報を付与する手段を備えている。すなわち、CPU12は、通信制御部（CCU）19がネットワークを介してクライアントコンピュータから電子文書の登録申請、直接証明申請、間接証明申請等が送られてくると、これを受信してバス14を経由してRAM16に格納する。次に、CPU12は、サーバコンピュータのバス14に接続されたタイマ20あるいはタイマサーバから時刻を取得し、RAM16に格納された最新の申請書に自動的に時刻を付与する。
この場合、電子文書に付与される登録時の時刻情報は、電子文書の登録を受付けた時点の時刻情報T1ａ、あるいは公証機関により電子文書が全部揃ったことが確認された時点の時刻情報T1ｂ、あるいは前記両方がそれぞれ独立した時刻情報T1ａ，T1ｂとして付与されるか、代表的時刻T1を付与することも可能である。
・・・中略・・・
【００１１】図２は、図１に示す電子文書登録時の処理シーケンスチャートであり、また図５は、登録時、直接証明申請時、間接証明申請時の各処理のメッセージデータの構成図である。登録申請者(CL1)は、クライアントコンピュータ(EE1)を用いて電子文書(DOC)に登録申請者署名(S1)を付与し、登録申請要求(M1)を公証機関(NA)に送信する。クライアントコンピュータ(EE1)からサーバコンピュータに送信される登録申請要求M1は、図５（ａ）に示すように、電子文書（DOC）と登録申請者の署名（S1）とから構成される。公証機関(NA)では、登録申請要求(M1)の登録申請者署名(S1)を検証し、登録時の時刻情報(T1)を付与し、電子証明書(CRTNA1)を用いて公証機関署名(SNA１)を付与し、登録番号(NUM)を付与し、これを原本(ORG)として登録番号(NUM)と関連付けて保管装置(DB)に保管する。
なお、登録時の時刻情報(T1)には、前述のように、登録申請要求を受信した時刻(T1a)と、電子文書(DOC)を電子的にチェックして最低条件の不備がないことを確認した後の登録直前の時刻(T1b)とがあり、これらのうち一方を時刻情報(T1)として付与してもよく、また両方を付与してもよい。
【００１２】次に、サーバコンピュータは、原本(ORG)の複製である正本(ORG2)に登録番号(NUM)を付与した登録申請応答(M2)をクライアントコンピュータに返却する。登録申請応答(M2)は、図５（ｂ）に示すように、原本と同じ要素からなる正本（ORG2）と、登録番号（NUM）から構成される。一方、登録申請者CL1は登録申請応答（M2）を受信すると、公証機関署名(SNA1)を検証し、登録申請応答(M2)に含まれる正本(ORG2)および登録番号(NUM)を格納媒体等に保管する。ここで返却された正本(ORG2)は、登録時に有効であった公証機関の電子証明書(CRTNA1)の有効期限の範囲でしかその存在および内容の証明を行うことはできない。」
　
　
＜引用文献６＞
「広告企画　２００６年注目のＰＣ・Ｎｅｔｗｏｒｋ　キーワード　高機能ＰＤＦ」，日経パソコン，日経ＢＰ社，２００５年１２月２６日，Ｎｏ．４９６，ｐ．１０９
　
　＜引用文献記載事項６−１＞
「例えば電子メールをＰＤＦに変換する場合、
添付ファイルやリンクをＰＤＦ内に保持
　
　＜引用文献記載事項６−２＞
「
存在証明や改ざん対策に効果的なタイムスタンプ機能
　
　＜引用文献記載事項６−３＞
「
　　　　　　　　　　　　　　　　　　」（右欄）
　
　＜引用文献記載事項６−４＞
「高機能ＰＤＦの作成・活用に欠かせないのが「Adobe Acrobat 7.0」。各種アプリケーションの文書ファイルだけでなく、Ｗｅｂページや電子メールなど、あらゆる文書を素早くＰＤＦに変換可能だ。また、
複数の文書ファイルを束ねたＰＤＦの作成・管理・活用も簡単にできる
　
　＜引用文献記載事項６−５＞
「さらに、ＩＤやパスワード、
電子印鑑・タイムスタンプ、電子封筒といったセキュリティ対策
　
　
（２）参考文献
　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となった下記参考文献には、それぞれ、下記参考文献記載事項が記載されている。（下線は当審付与。）
　
＜参考文献１＞
　特開２００２−３６９１９０号公報（平成１４年１２月２０日出願公開）
　
　＜参考文献記載事項１−１＞
「【００７９】本実施例では、判定部１０３を設けているが、判定部１０３を設けないことも可能である。
この場合には、デジタル署名部１０４は、たとえば、「本認証局は、３６５９８５０２（下移動、左下移動、左回転、右下移動、左上移動、左回転、右移動、上移動）という情報を送信し、２００１年４月２９日２３時３４分に、添付の画像データを受信したことを証明します。添付の画像データが、上記の情報により変化したものかどうかを、ご確認ください。」という情報にデジタル署名を付して送信する。
　
　＜参考文献記載事項１−２＞
「【０１０２】本実施例では、画像入力装置として、カメラシステム２００を用いているが、任意の画像入力送信装置を用いることができる。
【０１０３】第一に、
画像入力送信装置として、カメラ付携帯電話を用いるものが挙げられる。
・・・中略・・・
【０１１０】カメラシステム２００とカメラ付携帯電話４００の他にも、画像入力装置としては様々なものを用いることができる。例を挙げれば、
カメラ付情報携帯端末
　
　
＜参考文献２＞
　特開２００４−２５８８５０号公報（平成１６年９月１６日出願公開）
　
　＜参考文献記載事項２−１＞
「【０００９】
電子公証サービス代行依頼用システム１１０は、代行依頼用の端末であり
ービス代行依頼用システム１１０から受信した各電子データに対応して電子公証センタ１２０から受信した受付番号を格納する。」
　
　
＜参考文献３＞
　特開２００６−５９２８８号公報（平成１８年３月２日出願公開）
　
　＜参考文献記載事項３−１＞
「【請求項１】
　
公的機関が公文書の電子申請サービスを提供する電子申請処理用のコンピュータと、このコンピュータに対して暗号化通信により電子申請を行う電子申請端末とを通信網を介して接続した電子申請システム
　前記電子申請端末は、
　前記電子申請処理用のコンピュータに対して複数の申請者が連名で電子申請するための申請書を要求する手段と、
　前記要求に応じて前記電子申請処理用のコンピュータより申請書及び連名署名用の添付ファイルを受信する手段と、
　必要事項を記入し代表の申請者が電子書名を行った申請書に、前記連名署名者の氏名毎に電子署名された添付ファイルを添付して前記電子申請処理用のコンピュータへ送信する手段とを備え、
　前記電子申請処理用のコンピュータは、
　電子申請サービスのための各種申請書及び添付ファイルが登録されたドキュメント記憶手段と、
　電子申請された申請情報が登録される申請情報記憶手段と、
　前記電子申請端末より送信された、複数の申請者が連名で電子申請するための申請書の要求を受信する手段と、
　前記受信された要求に応じて、前記ドキュメント記憶手段より該当申請書及び添付ファイルを読み出して送信する手段と、
　前記電子申請端末より送信された電子署名された申請書及び添付ファイルを受信する手段と、
　受信された申請書に対して発行した到達番号及び問い合わせ番号を前記電子申請端末へ通知する手段と、
　前記申請書及び添付ファイルの内容を到達番号及び問い合わせ番号に対応付けて申請情報として前記申請情報記憶手段に登録すると共に、前記申請書及び添付ファイルの署名を検証する手段と、
　前記署名の正当性が検証された場合、前記電子申請端末に対してアクセス先情報を記述した受領通知を行う手段と
を具備したことを特徴とする電子申請システム。」
　
　＜参考文献記載事項３−２＞
「【００２６】
　電子申請端末２では、申請書類一式を受信すると（Ｓ１０５）、ブラウザソフトウェアは、申請書類一式のうちの申請書を、自身の画面で、プラグインされたＰＤＦファイル閲覧用のソフトウェアで開く。
【００２７】
　連絡人（代表申請者）である申請者Ａと共同申請者である連名者Ｂが今回連名で電子申請を行うものとする。
　申請者Ａと連名者Ｂが順に
添付書類（ＰＤＦファイル）
　そして、最後に、申請者Ａは、申請書様式に必要事項を入力し、その申請書様式に添付書類を付与し、代表として、申請書に電子署名を付与する（Ｓ１０７）。
【００２８】
　具体的な例で説明すると、図５に示すように、ブラウザソフトウェアの画面に表示された申請書５０には、申請内容記入欄５１、添付欄５２、連絡欄５３、署名付与欄５４が設けられている。連絡欄５３は、申請者の氏名（申請者名）、住所、メールアドレス、電話番号等を記入する欄である。
　申請者Ａは、申請内容記入欄５１、連絡欄５３へ必要事項、つまり申請内容を記入し、添付欄５２の複数署名用添付ファイル名をクリックすると、複数署名用の添付ファイル６０がＰＤＦファイル閲覧用のソフトウェアによって開かれる。複数署名用の添付ファイル６０には、複数の連名者名欄５５、電子署名欄５６等が設けられている。」
　
　＜参考文献記載事項３−３＞
「【００４２】
　電子署名の検証により正当性が確認されると、オペレータは、所定の文書作成ソフトウェアを起動して、受け付け結果と審査結果とを入力することで（Ｓ１２５）、公文書（例えば
公文書の表紙としてのＰＤＦ文書ファイル
　最後に、オペレータは、電子署名の操作を行うことで、作成された公文書に対して文書作成ソフトウェアが電子署名を行い（Ｓ１２７）、電子申請処理サーバ１の公文書記憶部１７へ登録する（Ｓ１２８）。なお、作成した公文書に対して電子署名を行うことを公印付与という。」
　
３．引用発明の認定
　
（１）
ア．引用文献１は引用文献記載事項１−１や１−２記載のごとき「認証システムおよびその認証方法」を説明する文献であるところ、引用文献記載事項１−３の記載などから、該「認証システム」は「１つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部１１」や「電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部１５」、「タイムスタンプの生成や発行を行うＴＳＡ（Time Stamping Authority）機能部１７」、「他のシステム等で計測された正確な時刻の受信処理などを行うＴＡ（Time Authority）機能部１８」等を有している。
　そして、引用文献記載事項１−３の「認証システム１の各機能部や装置は、それぞれが別々のサーバ装置で処理されてもよい」との記載や引用文献記載事項１−４の記載等から、該「連係処理部１１」と該「タイムスタンプ付与機能部１５」とは、これに接続された「ＴＳＡ機能部１７」や該「ＴＳＡ機能部１７」に接続された「ＴＡ機能部１８」を利用して、「タイムスタンプ付与処理」を行うシステムとして働くものであると見ることができる。
イ．したがって、引用文献１には
「１つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部と
電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部とを備え、
正確な時刻の受信処理などを行うＴＡ機能部に接続されタイムスタンプの生成や発行を行うＴＳＡ機能部に接続された、
タイムスタンプ付与処理システム」
が記載されていると言える。
　
（２）上記引用文献記載事項１−４等から、
「前記タイムスタンプ付与処理は、前記連係処理部が、前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信し、当該タイムスタンプ付与依頼と前記電子文書のデータを前記タイムスタンプ付与機能部へ転送し、
前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記ＴＳＡ機能部に通知し、
前記ＴＳＡ機能部においてタイムスタンプが生成され、
前記タイムスタンプ付与機能部が該タイムスタンプを受信し、受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理を行うことによりなされるもの」であり、また、
「前記タイムスタンプ付与機能部は前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信するもの」
であると言える。
　
（３）上記引用文献記載事項１−５等から、
「前記ＴＳＡ機能部は前記タイムスタンプ付与機能部から前記タイムスタンプ要求を受信する処理と、前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記ＴＡ機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うもの」
であると言える。
　
（４）よって、引用文献１には、下記引用発明が記載されていると認められる。
　
＜引用発明＞
「１つまたは複数のユーザの端末や他のシステムと通信ネットワークを介して接続された業務システムからの各処理依頼の受信とその処理依頼に基づく各機能への処理の振り分け等を行う連係処理部と
電子文書などのデータに対するタイムスタンプの付与処理を行うタイムスタンプ付与機能部とを備え、
正確な時刻の受信処理などを行うＴＡ機能部に接続されタイムスタンプの生成や発行を行うＴＳＡ機能部に接続された、
タイムスタンプ付与処理システムであって、
前記タイムスタンプ付与処理は、
前記連係処理部が、前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信し、当該タイムスタンプ付与依頼と前記電子文書のデータを前記タイムスタンプ付与機能部へ転送し、
前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記ＴＳＡ機能部に通知し、
前記ＴＳＡ機能部においてタイムスタンプが生成され、
前記タイムスタンプ付与機能部が該タイムスタンプを受信し、受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理を行うことによりなされるものであり、
前記タイムスタンプ付与機能部は前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信するものであり、
前記ＴＳＡ機能部は前記タイムスタンプ付与機能部から前記タイムスタンプ要求を受信する処理と、前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記ＴＡ機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うものである
タイムスタンプ付与処理システム」
　
　
４．対比
　以下に、本願発明と引用発明とを比較する。
　
（１）
ア．引用発明の「タイムスタンプ付与機能部」では「受信した該タイムスタンプを前記電子文書のデータ内に格納するファイル一体型タイムスタンプ付与処理」がなされるのであるから、引用発明も「データ作成装置」と言えるものである。
　
イ．引用発明における「業務システム」は、本願発明における「ユーザ端末」に対応付けられるものであるところ、両者は「ユーザ装置」と言えるものである点で共通する。
　
ウ．引用発明における「ハッシュ値」は本願発明における「ハッシュ値」に対応付けられるものであるところ、前者は「タイムスタンプ付与機能部」が「ＴＳＡ機能部に通知」するものであるから、後者と同様に「データ作成装置から送信されたハッシュ値」と言えるものである。
　引用発明における「タイムスタンプ」は本願発明における「日時保証情報」に対応付けられるものであるところ、前者は「前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記ＴＡ機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化」したものなのであるから、後者と同様に「このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報」と言えるものである。
　そして、引用発明における「ＴＳＡ機能部」は本願発明における「タイムスタンプ付与装置」に対応付けられるものであるところ、前者は「前記タイムスタンプ付与機能部から受信した前記電子文書のハッシュ値と前記ＴＡ機能部から受信した現在時刻を並べた文字列を秘密鍵で暗号化しそれを前記タイムスタンプとして返信する処理を行うもの」であるから、両者は「データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置」と言えるものであり、また引用発明も該「タイムスタンプ付与装置と通信可能に接続された」ものであると言える。
　
エ．したがって、引用発明と本願発明とは
「ユーザ装置及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置」
と言えるものである点で共通する。
　
（２）引用発明における「業務システム」から受信される「電子文書のデータ」はタイムスタンプ付与の「対象」となる「原本データ」とも言えるものであり、また、引用発明における「連係処理部」は、本願発明における「原本データ受信手段」に対応付けられるものであるところ、前者は「前記業務システムから電子文書のデータと当該電子文書に対するタイムスタンプ付与依頼を受信」するものであるから、引用発明と本願発明とは
「対象となる原本データを前記ユーザ装置から受信する原本データ受信手段」
を備える点で共通すると言える。
　
（３）
ア．引用発明においてハッシュ値の算出対象となる「電子文書のデータ」は、本願発明における「中間ファイル」にも対応付けられるものであるところ、前者へのタイムスタンプの格納が「ファイル一体型タイムスタンプ付与処理」と言われるように、前者も「ファイル」に格納されているものであることは明らかである。また、前者は「電子文書のデータ」であり、後者は「前記格納された原本データのデータ名及び、上記原本データを受信した日付を記載したポータブルドキュメントフォーマットファイル（ＰＤＦ）形式のファイルに、前記受信した原本データを追加して記憶することで」「作成」された「１つの中間ファイル」であるから、両者は「原本データを持つファイル」と言えるものである点で共通する。
　
イ．引用発明においては「前記タイムスタンプ付与機能部が前記電子文書のハッシュ値を算出し、当該ハッシュ値とともにタイムスタンプ要求を前記ＴＳＡ機能部に通知」するのであるから、引用発明も「該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信する」ものであると言える。
　
ウ．よって、引用発明と本願発明とは
「該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段」
を備える点で共通すると言える。
　
（４）引用発明においては「前記タイムスタンプ付与機能部が該タイムスタンプを受信」することがなされるのであるから、引用発明と本願発明とは
「前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段」
を備えている点で共通すると言える。
　
（５）引用発明においては「受信した該タイムスタンプを前記電子文書のデータ内に格納する」のであるから、引用発明と本願発明とは
「受信した日時保証情報を前記ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段」
を備える点で共通すると言える。
　
（６）引用発明においては「前記タイムスタンプが格納された電子文書のデータを前記連係処理部を介して前記業務システムへ返信する」のであるから、引用発明と本願発明とは
「この証明済ファイルを前記ユーザ装置に送信する証明済ファイル送信手段」
を備える点で共通すると言える。
　
（７）よって、本願発明は、下記一致点で引用発明と一致し、下記相違点を有する点で引用発明と相違する。
　
＜一致点＞
「ユーザ装置及び、データ作成装置から送信されたハッシュ値を受信することで、このハッシュ値とこれを受信した日付を表す日時情報を包含する日時保証情報を生成するタイムスタンプ付与装置と通信可能に接続されたデータ作成装置であって、
　対象となる原本データを前記ユーザ装置から受信する原本データ受信手段と、
　該原本データを持つファイルを所定のハッシュ関数に基づいてハッシュ値を計算し、前記タイムスタンプ付与装置に対して前記計算したハッシュ値を送信するタイムスタンプ要求手段と、
　前記タイムスタンプ付与装置から、前記日時保証情報を受信する日時保証情報取得手段と、
　受信した日時保証情報を前記ファイルに添付することで証明済ファイルを作成する証明済ファイル作成手段と、
　この証明済ファイルを前記ユーザ装置に送信する証明済ファイル送信手段と、
　を備えるデータ作成装置。」
　
＜相違点１＞
　本願発明におけるユーザ装置は「ユーザ端末」である。
（これに対し、引用文献１には、引用発明における「業務システム」が「端末」であるとの記載は無い。）
　
＜相違点２＞
　本願発明においては「格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載した」「ファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する中間ファイル作成手段」を備え、タイムスタンプ要求手段においてはこの「中間ファイル」のハッシュ値を計算し、証明済ファイル作成手段においては日時保証情報をこの「中間ファイル」に添付している。
（これに対し、引用文献１には本願発明の「中間ファイル作成手段」に相当する手段の記載はなく、「業務システム」から受信されるものも、「タイムスタンプ付与機能部」へ転送されるものも、「タイムスタンプ」が格納されるものも、全て「電子文書のデータ」と表現している。）
　
＜相違点３＞
　本願発明における中間ファイルは「ポータブルドキュメントフォーマットファイル（ＰＤＦ）形式の」ファイルである。
（これに対して、引用発明においては、「タイムスタンプを前記電子文書のデータ内に格納すること」ができるファイルフォーマットを採用していることは明らかであるが、これがＰＤＦ形式である旨の明示はない。）
　
５．判断
　以下に、上記相違点について検討する。
　
（１）相違点１について
　タイムスタンプ付与などの証明依頼を個人用ＰＣなどの「端末」と言えるような規模・形態の装置から行うことは、当該分野においては極めて一般的なものであり（必要があれば参考文献記載事項１−２、２−１、３−１等参照）、引用発明の「業務システム」の均等手段としての「ユーザ端末」は、当業者においては何らの創意も要せず自然に想起されるものであり、引用発明における「業務システム」として「ユーザ端末」を採用すること、すなわち、上記相違点１に係る構成を採用することは、当業者であれば適宜になし得た設計変更にすぎないものである。
　
（２）相違点２について
　データに署名等の情報を付加する際に、当該データに関する属性情報などの付加情報を付加することは、一般的に行われていることであり、また、係る付加情報として情報の受信日時やファイル名は適宜に採用されている項目にほかならない。（必要があれば引用文献記載事項２−１、３−１、４−１、５−１、参考文献記載事項１−１参照）
　してみると、引用発明において「格納された前記原本データのデータ名及び、上記原本データを受信した日付を記載した」「ファイルに、前記受信した原本データを追加して記憶することで１つの中間ファイルを作成する中間ファイル作成手段」を設け、この「中間ファイル」のハッシュ値を計算し、この「中間ファイル」にタイムスタンプを添付するように構成すること、すなわち上記相違点２に係る構成を採用することは、当業者であれば容易に想到し得たものである。
　
（３）相違点３について
　ポータブルドキュメントフォーマットファイル（ＰＤＦ）形式は、添付ファイル機能や署名機能を有し存在証明や申請書等に好適なファイルの形式として良く知られているものであり（必要があれば引用文献記載事項６−１〜６−５、参考文献記載事項３−２、３−３等参照）、上記「中間ファイル」の形式として「ポータブルドキュメントフォーマットファイル（ＰＤＦ）形式」を採用すること、すなわち上記相違点３にかかる構成を採用することは、当業者であれば、上記相違点２にかかる構成の採用に際し、適宜に選択・採用し得た設計的事項にすぎない。
　
（４）してみると、本願発明の構成は引用文献に記載された発明に基づいて、当業者が容易に想到し得たものである。
　また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用文献に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
６．小結
　以上のとおり、本願請求項１に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
第４．むすび
　上記第２．のとおり、本願は、明細書及び特許請求の範囲の記載が、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていないものであり、また、上記第３．のとおり、本願請求項１に係る発明は、その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、本願は特許法第２９条第２項の規定により特許を受けることができないものである。
　
　したがって、本願について「原査定を取り消す。この出願の発明は特許をすべきものとする」との審決をすることはできない。
　
　よって、上記結論のとおり審決する。