【事件の表示】
　特願２００１−３９６８５７「電子公証システム及び電子公証方法」拒絶査定不服審判事件〔平成１５年　７月１１日出願公開、特開２００３−１９６４１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年１２月２７日の出願であって、平成１７年１０月１２日付で拒絶査定がなされ（発送日同年１０月１８日）、これに対し、同年１１月１７日に拒絶査定不服審判の請求がなされるとともに、同年１２月１９日付で手続補正がなされたものである。
　
２．平成１７年１２月１９日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１７年１２月１９日付の手続補正を却下する。
［理由］
（１）平成１７年１２月１９日付の手続補正書により補正された本願発明
　本件補正により、特許請求の範囲の請求項１は、下記のように補正された。
「電子公証センターと時刻校正センターを含む電子公証システムであって、
　前記電子公証センターは、アプリケーションサーバとタイムスタンプサーバとを有し、
　前記アプリケーションサーバは、
　ユーザの電子データを取得し、前記電子データに係る電子証明書を前記タイムスタンプサーバから取得して前記ユーザに送信する受付手段と、
　前記受付手段で取得した前記電子データを一方向関数値に変換し、前記タイムスタンプサーバに送出する演算手段とを有し、
　前記タイムスタンプサーバは、
　前記時刻校正センターから取得する時刻校正証明書により、前記時刻校正センターによって時刻校正がなされていることが証明されている時刻手段と、
　前記アプリケーションサーバから取得する前記電子データの一方向関数値と、前記時刻手段が出力する時刻情報と、前記タイムスタンプサーバの固有のＩＤとを含むタイムスタンプ情報と、該タイムスタンプ情報の電子署名と、タイムスタンプ用公開鍵証明書と、前記時刻校正証明書とを含む電子証明書を作成し、前記アプリケーションサーバに送出する電子証明書作成手段とを有し、
　前記時刻校正センターは、
　前記電子公証センターからは独立して管理されたセンターであり、
　協定世界時と協調する時計の時刻に基づいて前記電子公証センターの前記タイムスタンプサーバの前記時刻手段の時刻を校正し、時刻校正を行った時に時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段と、
　前記電子公証センターの前記タイムスタンプサーバから、前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を取得して蓄積する手段と、
　前記電子公証センターの前記アプリケーションサーバの前記受付手段がユーザに送信した電子証明書を取得する手段と、
　取得した前記電子証明書と、蓄積している前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を使用して、前記タイムスタンプサーバの前記時刻手段が時刻校正を受けており、前記タイムスタンプサーバが正規のタイムスタンプサーバであること検証する手段とを有する、電子公証システム。」
　
　上記補正は、旧請求項１の発明特定事項である「時刻校正センター」について、「電子公証センターからは独立して管理されたセンターであり」との限定を付加し、同じく旧請求項１の発明特定事項である「時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段」について、「時刻校正を行った時に」（時刻校正証明書を作成する）との限定を付加するものである。
　したがって、本件補正は、特許請求の範囲の減縮を目的とするものに該当する。
　
　そこで、本件補正後の請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるかについて以下に検討する。
　
（２）引用発明の認定
（２−１）引用例１
　原査定の拒絶の理由に引用された、安全な情報流通を支える認証・公証プラットフォーム，NTT RD，日本，社団法人電気通信協会，２０００年１１月１０日，第49巻 第11号，pp.661〜667.（以下、「引用例１」という。）には、図面とともに、以下（ア）〜（ウ）の事項が記載されている。
　　　
（ア）
「欧米においては日本より数年早く認証サービスや事実否認防止サービス（タイムスタンプサービス，セキュア保管サービス，安全な到達サービス）が数多く行われている（７）．
　しかしながらそれらサービスは本人認証のみを行っていたり，事実否認防止サービスといっても存在の証明を行うだけであったり，あるいは安全な到達とデータ保管を行っていても事実の証明を行ってはいなかったりする．また多くの事実否認防止サービスはデータのハッシュ値をサービスの対象としておりデータ自身を証明の対象としていない．
　本論文では著者らが開発した本人認証および事実否認防止を行う認証・公証プラットフォーム（以下，認証・公証ＰＦ）の特徴について述べる（８）〜（１０）．」（第６６２頁左欄第２〜１３行）
　
（イ）
「２．２　応用セキュアサービス基盤
　図２に示すように，情報の流通は事前対処機能である本人認証機能および事後対処機能である事実証明機能を保持することにより安全に保たれる．それに対応して応用セキュアサービス基盤は認証ＰＦおよび公証ＰＦを提供している．認証ＰＦはＰＫＩに基づいた本人認証を行うための認証サービス基盤であり，公開鍵証明書の発行から失効・無効化までの状態を管理する．公証ＰＦは事実否認を防止すると同時に，事実否認が発生したときの事実証明を行うために利用者の情報保管および流通に介在してデータの存在と当事者の行為の証明を行う．それぞれの詳細については３，４章に述べる．」（第６６３頁左欄第１９〜２９行目）
　
（ウ）
「４　公証プラットフォーム
　公証ＰＦは２章で述べたように利用者の情報流通に介在して証拠を保管するが，２種類の関与の形態がある．第１は利用者のデータの存在のみを証明しその証拠を安全に保管するセキュア保管型，第２は利用者のデータの存在のみでなくその配達と相手の受信を証明する到達証明型である．また，到達証明型の類似形態として送信証明サービスも提供している（表２）．これは，送ったが相手に届かなかった場合の，送信者の行為を証明するためのものである．いずれの場合も利用者のデータの作成に責任を持つ人，内容に合意した人（いれば），公証サービスの要求者，配達先利用者の本人認証を行うための情報を必要とする．
　モデル上，公証ＰＦはセキュア基盤上に構築されており，公証システム（ＣＹＮＯＳ：ＣＹｂｅｒ　ＮＯｔａｒｙ　Ｓｙｓｔｅｍ）として実現されている．その構成概要を図４に示す．図中に【２】，【３】，【５】，【７】，【８】，【１０】で示した各コンポーネントはセキュア基盤で提供されるものであり，これらだけでＴＴＰとしての重要な要件を満たしているが，それらに加えＣＹＮＯＳは次の特徴を持つ（１１）．
　（１）高い証明能力
　〔真正性・完全性の保証〕
　ＣＹＮＯＳが証拠を保管するうえでその真正性・完全性を保証するためまずは公証サービスを提供するときの厳密な本人認証が必要となる．そのため，セキュア基盤で提供される機能に加え３章で述べたリアルタイムＣＡ（ＣＡＮＰ：図４中の【４】）を用い，保管する証拠データの作成者，送信者，受領者，合意者についてそれぞれの電子署名を動的に検証している（ＣＡオンライン検証プロトコルの利用）．
　〔ＴＴＰとして証拠の保管〕
　本公証ＰＦは提供する証明サービスに応じて種々の情報を保管し，証拠として提示する（表２）．情報流通当事者のみに証拠の保管を任せるのではなく，ＴＴＰとして証拠を保管することでその客観性・公平性という観点からも証明能力を向上させている．同時にその保管中の無破壊・無改ざん性を保証するために証拠に保管用の電子署名を付与して格納している．
　〔外部機関の採用による公平性確保〕
　ＣＹＮＯＳは証拠として重要情報である基準時間のソースおよび本人登録・承認の主体を外部に求めている．このことはＣＹＮＯＳの公平性を担保し，外部者からのＣＹＮＯＳ自身への信頼性を高めることに役立っている．
　〔ＰＫＩを応用した受領者署名取得に基づく到達の証明〕
　ＣＹＮＯＳは受信者へのデータの到達を証明するために配達対象データに対して受信者の電子署名を取得し保管する．当該電子署名は受信者の持つ秘密鍵でしか作成することはできず，また受信したデータからのみ作成されうる．そのデータと受領者署名両方をあわせて保管することによりその時点で受信者がデータを取得したことを証明することが可能になる（図５）．
　〔紙の証明能力への近似〕
　紙との証明能力の違いを考えると，電子データは複製が容易に作成できるという唯一性の欠落が最も大きな違いといえる．本公証ＰＦではＣＹＮＯＳサーバが保管したデータを原本と見なし，外部に流通する場合にはそのデータを事実証明書（電子証書）として構成している．」（第６６４頁左欄第１３行目から第６６５頁右欄第９行目）（【１】などの【】内に数字は、原文では○内に数字として記載されているが審決ではシステムの制約上表記できないので【】内に数字の表記に置き換えて記載している。）
　
　以上の引用例１の記載によれば、引用例１には以下の事項が開示されていると認められる。
　
（ａ） 引用例１の上記（ア）の「本論文では著者らが開発した本人認証および事実否認防止を行う認証・公証プラットフォーム（以下，認証・公証ＰＦ）の特徴について述べる」という記載、及び、引用例１の上記（イ）の「公証ＰＦは事実否認を防止すると同時に，事実否認が発生したときの事実証明を行うために利用者の情報保管および流通に介在してデータの存在と当事者の行為の証明を行う．」という記載、引用例１の上記（ウ）の「本公証ＰＦは提供する証明サービスに応じて種々の情報を保管し，証拠として提示する（表２）．情報流通当事者のみに証拠の保管を任せるのではなく，ＴＴＰとして証拠を保管することでその客観性・公平性という観点からも証明能力を向上させている．同時にその保管中の無破壊・無改ざん性を保証するために証拠に保管用の電子署名を付与して格納している．（中略）ＣＹＮＯＳは証拠として重要情報である基準時間のソースおよび本人登録・承認の主体を外部に求めている．このことはＣＹＮＯＳの公平性を担保し，外部者からのＣＹＮＯＳ自身への信頼性を高めることに役立っている．（中略）本公証ＰＦではＣＹＮＯＳサーバが保管したデータを原本と見なし，外部に流通する場合にはそのデータを事実証明書（電子証書）として構成している．」という記載、及び、表２並びに図４から、引用例１には、公証システムＣＹＮＯＳと外部時間サーバを含む公証プラットフォームが開示されていると認められる。
　
（ｂ）引用例１の上記（ウ）の「ＣＹＮＯＳが証拠を保管するうえでその真正性・完全性を保証するためまずは公証サービスを提供するときの厳密な本人認証が必要となる．そのため，セキュア基盤で提供される機能に加え３章で述べたリアルタイムＣＡ（ＣＡＮＰ：図４中の【４】）を用い，保管する証拠データの作成者，送信者，受領者，合意者についてそれぞれの電子署名を動的に検証している（中略）本公証ＰＦは提供する証明サービスに応じて種々の情報を保管し，証拠として提示する（表２）．情報流通当事者のみに証拠の保管を任せるのではなく，ＴＴＰとして証拠を保管することでその客観性・公平性という観点からも証明能力を向上させている．同時にその保管中の無破壊・無改ざん性を保証するために証拠に保管用の電子署名を付与して格納している．（中略）本公証ＰＦではＣＹＮＯＳサーバが保管したデータを原本と見なし，外部に流通する場合にはそのデータを事実証明書（電子証書）として構成している．」という記載及び図４から、引用例１に記載の公証システムＣＹＮＯＳは、送信者から証拠データを取得して事実証明書（電子証書）作成手段に渡し、事実証明書（電子証書）作成手段から受け取った証拠データに係る事実証明書（電子証書）を送信者に送信するＷｅｂサーバを備えたサーバ群であるものと認められる。
　
（ｃ）引用例１の上記（ウ）の「本公証ＰＦは提供する証明サービスに応じて種々の情報を保管し，証拠として提示する（表２）．情報流通当事者のみに証拠の保管を任せるのではなく，ＴＴＰとして証拠を保管することでその客観性・公平性という観点からも証明能力を向上させている．同時にその保管中の無破壊・無改ざん性を保証するために証拠に保管用の電子署名を付与して格納している．（中略）本公証ＰＦではＣＹＮＯＳサーバが保管したデータを原本と見なし，外部に流通する場合にはそのデータを事実証明書（電子証書）として構成している．」という記載及び図２並びに表２の「電子証書主要構成要素」の欄内の「原本登録時刻」、「立証データ（データ自身）」、「公証システム識別情報」、「公証システム電子署名」という記載から、引用例１に記載の公証システムＣＹＮＯＳサーバ群は、Ｗｅｂサーバから受け取った証拠データの原本登録時刻、証拠データ自身、公証システム識別情報、及び、公証システム電子署名などを含んだ事実証明書（電子証書）を作成し、Ｗｅｂサーバに渡す、事実証明書（電子証書）作成手段を備えているものと認められる。
　
（ｄ）引用例１の上記（ウ）の「ＣＹＮＯＳは証拠として重要情報である基準時間のソースおよび本人登録・承認の主体を外部に求めている．このことはＣＹＮＯＳの公平性を担保し，外部者からのＣＹＮＯＳ自身への信頼性を高めることに役立っている．」という記載及び図４から、引用例１に記載の外部時間サーバは、公証システムＣＹＮＯＳサーバ群から独立して管理されたサーバであり、基準となる時間のソースとなっていると認められる。
　
　以上の引用例の記載によれば、引用例１には下記の発明（以下、「引用例１発明」という。）が開示されていると認められる。
　
「公証システムＣＹＮＯＳサーバ群と外部時間サーバを含む公証プラットフォームであって、
　公証システムＣＹＮＯＳサーバ群は、
　送信者から証拠データを取得して事実証明書（電子証書）作成手段に渡し、事実証明書（電子証書）作成手段から受け取った証拠データに係る事実証明書（電子証書）を送信者に送信するＷｅｂサーバと、
Ｗｅｂサーバから受け取った証拠データの原本登録時刻、証拠データ自身、公証システム識別情報、及び、公証システム電子署名などを含んだ事実証明書（電子証書）を作成し、Ｗｅｂサーバに渡す、事実証明書（電子証書）作成手段とを有し、
　外部時間サーバは、公証システムＣＹＮＯＳから独立して管理されたサーバであり、基準となる時刻のソースとなっている
公証プラットフォーム。」
　
（２−２）引用例２
　原査定の拒絶の理由に引用された、ベリサインが「電子公証サービス」データに改ざんがないことを証明，日経インターネットテクノロジー，日本，日経ＢＰ社，２００１年７月２２日，第49巻，p.24（以下、「引用例２」という。）には、図面とともに、以下（エ）の事項が記載されている。
　
（エ）
「日本ベリサインは，７月に最大１０Ｍバイトまでのデータ・ファイルにタイム・スタンプを付けてディジタル署名する「電子公証サービス」を開始した。このサービスで証明できるのは（１）ディジタル署名した時点でユーザーのデータ・ファイルが存在したこと，（２）データ・ラァイルが改ざんされていないこと−の２点。同社のアウトソースＣＡ（認証局）サービス「ベリサイン・オンサイト」（約４５０万円）のオプションとして提供する。料金は，１回の署名と１回の検証をそれぞれ１トランザクションと数え，年間５万トランザクションで１２０万円から。
　データに署名するには，まずブラウザでサービス専用サイトにアクセスし，ベリサイン・オンサイトで発行されたディジタル証明書を使いログインする。次に，ディジタル署名したいデータ・ファイルを電子公証サービスにアップロードする。アップロードが完了すそと，タイム・スタンプを付加してディジタル署名する。サービス・サイトのシステムは常時ＵＴＣ（世界協定時）と同期を取っており，タイム・スタンプの誤差は数ミリ秒以内だという。専用サイトでは，ディジタル署名の際に生成されるハッシュ値をデータベースに記録。署名したことを証明する「デジタル・レシート」をユーザーに発行。このレシートは，認証局の証明書でディジタル署名してある。
　ファイルが改ざんされていないかどうかを検証するには，再度サービス専用サイトにファイルをアップロードして，ディジタル署名をする。そのとき生成されたハッシュ値と，デジタル・レシートに記録されたＵＲＬにあるハッシュ値を比較して，一致していれば改ざんされていないことがわかる。」（第２４頁左欄第１行目から同頁右欄第１３行目）
　
　以上の引用例２の記載によれば、引用例２には以下の事項が開示されていると認められる。
　
「電子公証サービス専用サイトであって、
ディジタル署名したいデータ・ファイルのアップロードを受け付ける手段と、
データ・ファイルにタイム・スタンプを付加してディジタル署名する手段と、
ディジタル署名の際に生成されるハッシュ値をデータベースに記録する手段と、
署名したことを証明する「デジタル・レシート」（このレシートは，認証局の証明書でディジタル署名してある。）をユーザーに発行する手段と、
ファイルが改ざんされていないかどうかを検証する際には，再度サービス専用サイトにファイルをアップロードして，ディジタル署名をすると、そのとき生成されたハッシュ値と，デジタル・レシートに記録されたＵＲＬにあるハッシュ値を比較することにより，一致していれば改ざんされていないことが検証でき、
電子公証サービス専用サイトのシステムは、常時ＵＴＣ（世界協定時）と同期を取っており，タイム・スタンプの誤差は数ミリ秒以内であり、
タイムスタンプを付加するサービスサイトがデータの存在を証明するデジタル・レシートを発行する際に、認証局の証明書でデジタル署名してある
電子公証サービス専用サイト。」
　
（２−３）引用例３
　原査定の拒絶の理由に引用された、国際公開第０１／６３９２７号パンフレット（以下、「引用例３」という。）には、図面とともに、以下（オ）〜（キ）の事項が記載されている。
　
（オ）
「
Field of the Invention
　　　　　This invention relates generally to methods and systems for providing and verifying a trusted source of certified time, and, more particularly, the invention relates to digitally time stamping electronic documents wherein the time stamp can be validated and verified as synchronized with an accepted standard.」（第１頁第５〜８行）
　
　上記記載は、以下のような事項が記載されているものと認められる。
　
「
発明の分野
　
（カ）
「
Description of the Related Art
　　　　　Electronic Commerce (e-commerce) is a rapidly expanding aspect of the economic world and demands the use of Electronic Commerce transactions. Such transactions, however, have outgrown the policies and controls that regulate traditional Paper Commerce. For example, a paper document can be typed, signed in ink, and mailed through the post office. The post office can then affix a time stamp and receipt at the destination. There are long standing legal and accounting policies that authenticate this type of transaction. When an electronic document is sent between two computers, however, it does not leave behind the same degree of tangible evidence. Even if the electronic document is stored in a computer's memory, the contents, signature, and time stamp can be manipulated by anyone with access to the computer. 
　　　　　Accounting and legal regulatory bodies are currently developing and mandating Electronic Commerce certification processes to provide reliable authentication for electronic transactions much like those available for paper transactions. Many of the certification processes depend on the creation of a digital signature using public key cryptography that authenticates the Who, What, and When of a document. 
　　　　　Public key cryptography was developed in the 1970s to solve problems involved with symmetric key cryptography. In public key cryptography systems, two corresponding keys are generated. One key, called a private key, is held privately by the keyholder. A second key, called a public key, is published openly for anyone that wants to secretly communicate with the keyholder or verify the authenticity of messages sent by the keyholder. Because the sender and the receiver use different keys, public key cryptography is also known as asymmetric key cryptography. 
　　　　　To send a secret message with public key cryptography, an entity A encrypts a message using the public key of an entity B. A then transmits the encrypted message to B. B decrypts the encrypted message with B's corresponding private key. Since the message encrypted with B's public key can only be decrypted with the corresponding private key, held only by B, the privacy of the communication is ensured. 
　　　　　To authenticate the content and origin of a message, A uses a one-way hash function to create a message digest. A message digest is a fixed length data element that uniquely represents the source message. Since the hash function is one-way, nothing about the content of the source message can be inferred from the message digest. For example, two message digests from two messages that differ by only one character would appear to be a completely random reordering of characters. A then signs the message by encrypting the digest using A's private key. The signature is typically appended to the message itself. A then transmits the signed message to B. In order to authenticate the received message, B uses the same one-way hash function used by A to create a message digest from the received message. B then decrypts the encrypted digest using A's public key. If the decrypted digest matches the digest created from the received message, then the received message must be the identical message from which the decrypted digest was originally derived. Furthermore, that the decrypted digest was decrypted using A's public key ensures that the decrypted digest was originally encrypted with A's private key. The successful matching of digests, therefore, ensures that the message received by B is the identical message signed by A. 
　　　　　Encrypting a message itself establishes secrecy. Signing a message provides for message authentication and establishes the who and what of a message. Encryption and signatures can also be combined by encrypting a message before creating a message digest and signature. By combining encryption and signatures, secret, authenticatable communications can be accomplished. 
　　　　　A very significant attribute of public key cryptography is that there is no need to share a secret key or to transmit a secret key from the keyholder to a proposed communication partner. It is, however, necessary to establish credibility for who owns public and private keys. For instance, C could claim to be A and send a message to B. To prevent being fooled, B needs to be sure that A's public key, is in fact paired with the private key owned by a real A. A Certification Authority (CA) solves this problem. (Note: The use of the word certification in certification authority relates to the association of public keys with particular owners and is distinct from the concept of a Time Calibration Certificate (TCCert), as used herein, which relates to the certification of a clock as synchronized with an accepted standard.) CAs provide digital certificates which contain public keys and are used to transmit the public keys in a secure, authenticated manner to participants in e-commerce transactions. 
　　　　　In addition to the cryptographic techniques and digital certificates provided by CAs, security and authentication of transactions is also supported by an extensive body of protocol standards. It is necessary for A to format messages, signatures, message digests, etc., with protocols that can be recognized by B. Cryptography, digital certificates, protocols, and standards together make up what is termed the Public Key Infrastructure (PKI). With PKI, one can easily guarantee the who and what of a transaction. 
　　　　　When is a measure of the time at which an event occurred and is a concept easily taken for granted. A worldwide system of time standardization is in operation. Each country that is signatory to the Treaty of the Meter maintains a National Timing Laboratory (NTL), which houses the local country's standard time clock. These clocks are kept synchronized to the world standard of time maintained in Paris, France. The world standard for commercial time is Coordinated Universal Time (UTC). In the United States, Congress has mandated that official United States time follow the clock maintained by the National Institute of Standards and Technology (NIST), located in Boulder, Colo. This standard is referred to as UTC-NIST. Any time stamp for a transaction that must survive technical, auditing, or legal scrutiny must be made by a clock that is synchronized to UTC-NIST, and the synchronization process must be traceable. Throughout this document, reference is made to UTC-NIST but the invention described is applicable to operation in any country and with standard time clocks maintained by any country's respective national timing laboratory. 
　　　　　The use of traceable clocks in paper commerce has been sufficient to provide the when of ordinary paper transactions. While there have been numerous cases of falsification of dates on paper documents, the risk to commerce has been relatively small. In the case of e-commerce, however, falsification of dates creates a much greater risk because it is possible to invade computer-directed processes and effect fraud on a very large scale. Such computer crimes frequently involve falsification of electronic time stamps; and for this very reason, protection of the electronic clocks that generate those time stamps from tampering is a high priority in Electronic Commerce. 
　　　　　Current network procedures provide for the synchronization of all workstation clocks in a network. NIST and other agencies provide network time servers that have clocks traceable to UTC-NMST. Client workstations can synchronize their time with the network time servers through a common protocol. The Network Time Protocol (NTP) is commonly used in TCP/IP networks such as the Internet, but other protocols are also used. 
　　　　　Unfortunately, once a local workstation clock is synchronized to the network time server, its time may be subject to manipulation regardless of the reliability of the source network time server. Thus far, little work has been done to ensure that the source of the time used to generate time stamps can be trusted. Today, the majority of applications utilizing time stamps simply use the system clock from their host system. Procedures for setting or offsetting a system clock are commonly known. Thus, there is no inherent trust in a system clock in a conventional system. 
　　　　　Attempts to overcome this problem include time stamp sequencing wherein the time stamp incorporates information regarding the order in which documents are time stamped in relation to other time-stamped documents. (See, for example, U.S. Pat. No. 5,136,647 to Haber et al.) Other attempts to overcome the problem incorporate the use of other time sources such as NTP or Global Positioning System (GPS). While these attempts are significant improvements over using the system clock, the improvements still fall short of fitting into the trust models required for electronic business today. 
　　　　　Still other systems employ the use of certified time that is maintained by a trusted third party's system located outside the local network. The trusted third party system remains synchronized with UTC-NIST through a common protocol. The local network application server then establishes communication with the third party's system whereby a data object (document or message digest) is sent to the third party system where a time stamp is affixed to the data object, either in clear text or in cryptographically embedded text. Such a system may be impractical, however, considering the need for external communication for each instance of time stamping, especially when many time stamps are required by the local network. 
　　　　　Another system introduces a local clock into the local network, thus avoiding the problems associated with obtaining time stamps from an outside source. The local clock must be periodically synchronized with a UTC-NIST traceable clock. In order to avoid frequent certification and calibration between the local clock and the UTC-NIST traceable clock, the local clock is advantageously a cesium atomic clock. Cesium atomic clocks are commercially available and their frequency, and hence time, is derived from an atomic phenomena caused by the energy difference of certain cesium atom electron orbits. Thus, as long as the cesium atomic clock is operating, it will be accurate enough to satisfy most practical applications. Such clocks only lose one second in 30,000 years of normal operation. For this reason, cesium atomic clocks are termed primary reference sources. Unfortunately, when used locally, there is still the possibility that the time value in the clock could, through system malfunction or intentional manipulation, be altered to an incorrect value that would not be apparent to a user. 
　　　　　Trusted time, in the context of the present invention, is time that is certified to be traceable to the legal time source for the application in which it is being used. The legal time source for commercial applications operating in the United States, as legislatively mandated by Congress, is the National Institute of Standards and Technology (NIST). The infrastructure for providing trusted time must provide a strong trust model, including a certification log for auditing and to prevent repudiation at a later date. 
　　　　　The need for trusted time has become recognized over the last two years as marked by the launch of standardization activities in the The Internet Engineering Task Force (IETF). In addition, most Certification Authority (CA) product and service vendors have announced development activities and new products in this area. The present disclosure describes a Trusted Time Infrastructure (TTI) that meets the requirements for providing trusted time. The present disclosure also shows how the TTI fits in with the trust models and cryptographic standards that have been developed to ensure that secure and legally binding electronic transactions can take place today. 」（第１頁第１０行目から第３頁第３６行目）
　
　上記記載は、以下のような事項が記載されているものと認められる。
　
「
関連技術の説明
　　　　　会計上および法律上の規制機関が、現在、書類による取引に関して利用可能であるのとほぼ同じように、電子取引に関して信頼のおける認証を提供する電子商取引認定プロセスを開発し、規定しつつある。認定プロセスの多くは、文書の「誰であるか」、「何であるか」、および「いつであるか」を認証する公開鍵暗号法を使用してデジタル署名を作成することに依存している。
　　　　　公開鍵暗号法は、対称鍵暗号法に関わる問題を解決するため、１９７０年代に開発された。公開鍵暗号法システムでは、２つの対応する鍵が生成される。秘密鍵と呼ばれる１つの鍵が、鍵保持者によって秘密に保持される。公開鍵と呼ばれる第２の鍵が、鍵保持者と秘密に通信することを望む、または鍵保持者によって送信されたメッセージの真正性を確認することを望む人には誰にでも公に発行される。送信側と受信側が、異なる鍵を使用するため、公開鍵暗号法は、非対称鍵暗号法としても知られている。
　　　　　秘密メッセージを公開鍵暗号法を使用して送信するため、エンティティ「Ａ」は、エンティティ「Ｂ」の公開鍵を使用してメッセージを暗号化する。次に「Ａ」は、暗号化したメッセージを「Ｂ」に伝送する。「Ｂ」は、「Ｂ」の対応する秘密鍵を使用して暗号化されたメッセージを暗号化解除する。「Ｂ」の公開鍵で暗号化されたメッセージは、「Ｂ」だけによって保持される対応する秘密鍵でしか暗号化解除することができないので、通信のプライバシーを保証する。
　　　　　メッセージの内容および発信元を認証するため、「Ａ」は、一方向ハッシュ関数を使用してメッセージダイジェストを作成する。メッセージダイジェストは、ソースメッセージを一意的に表す固定長のデータ要素である。ハッシュ関数は一方向であるため、ソースメッセージの内容に関して何もメッセージダイジェストから推定することができない。例えば、１文字だけ異なる２つのメッセージからの２つのメッセージダイジェストが、完全にランダムに文字を並べ替えたように見える。次に、「Ａ」は、「Ａ」の秘密鍵でダイジェストを暗号化することによってメッセージに署名する。署名は、通常、メッセージ自体に付加される。次に「Ａ」は、署名したメッセージを「Ｂ」に伝送する。受信メッセージを認証するため、「Ｂ」は、「Ａ」によって使用されたのと同一の一方向ハッシュ関数を使用して、受信メッセージからメッセージダイジェストを作成する。次に「Ｂ」は、「Ａ」の公開鍵を使用して暗号化されたダイジェストを暗号化解除する。暗号化解除されたダイジェストが、受信メッセージから作成されたダイジェストにマッチする場合には、受信メッセージは、暗号化解除されたダイジェストが元々導出されたメッセージと同一のはずである。さらに、暗号化解除されたダイジェストが、「Ａ」の公開鍵を使用して暗号化解除されたことにより、暗号化解除されたダイジェストが、「Ａ」の秘密鍵で元々暗号化されたことを保証する。したがって、ダイジェストのマッチングがうまくいったことにより、「Ｂ」によって受信されたメッセージが、「Ａ」によって署名されたメッセージと同一であることを保証する。
　　　　　メッセージ自体を暗号化することが、機密性を確立する。メッセージに署名することが、メッセージの認証を可能にし、メッセージの「誰であるか」および「何であるか」を確立する。また、メッセージダイジェストおよび署名を作成する前にメッセージを暗号化することにより、暗号化と署名を組み合わせることも可能である。暗号化と署名を組み合わせることにより、秘密の認証可能な通信を実行することができる。
　　　　　公開鍵暗号法の非常に重要な属性は、秘密鍵を共用する、または鍵保持者から指名された通信パートナに秘密鍵を伝送する必要性が全く存在しないことである。ただし、誰が公開鍵および秘密鍵を所有しているのかに関する信頼性を確立する必要がある。例えば、「Ｃ」が、「Ａ」であると自称して、メッセージを「Ｂ」に送信する可能性がある。騙されるのを防止するため、「Ｂ」は、「Ａ」の公開鍵が、実際、本物の「Ａ」によって所有される秘密鍵と対になっていることの確証を得る必要がある。証明機関（ＣＡ）が、この問題を解決する。（注：証明機関における「証明」という言葉の使用は、特定の所有者に公開鍵が関連していることに関し、認められた標準と同期しているものとしての時計の認定に関する本明細書で使用する時刻較正認定（ＴＣＣｅｒｔ）の概念とは別である。）ＣＡは、公開鍵を含み、ｅコマース取引の参加者に安全で認証された仕方で公開鍵を伝送するのに使用されるデジタル証明を提供する。
　　　　　暗号化技法およびＣＡによって提供されるデジタル証明に加え、取引のセキュリティおよび認証は、広汎なプロトコル標準によってもサポートされる。「Ａ」は、「Ｂ」が認識することができるプロトコルでメッセージ、署名、メッセージダイジェスト等をフォーマットする必要がある。暗号法、デジタル証明、プロトコル、および標準がともに、公開鍵インフラストラクチャ（ＰＫＩ）と呼ばれるものを構成している。ＰＫＩで、取引の「誰であるか」および「何であるか」を容易に保証することができる。
　　　　　「いつであるか」は、イベントが生じた時刻の目安であり、保証されたものと考えやすい概念である。時刻標準の世界共通システムが施行されている。メートル条約に署名する各国は、国の標準時刻時計を収容する国内計時研究機関（Ｎａｔｉｏｎａｌ　Ｔｉｍｉｎｇ　Ｌａｂｏｒａｔｏｒｙ）（ＮＴＬ）を維持する。これらの時計は、フランス国、パリで維持される時刻の世界標準に対する同期が保たれる。商業時刻の世界標準は、協定世界時（Ｃｏｏｒｄｉｎａｔｅｄ　Ｕｎｉｖｅｒｓａｌ　Ｔｉｍｅ）（ＵＴＣ）である。米国では、議会が、公式の米国「時刻」が、コロラド州、ボールダにある国立標準および技術研究所（Ｎａｔｉｏｎａｌ　Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｓｔａｎｄａｒｄｓ　ａｎｄ　Ｔｅｃｈｎｏｌｏｇｙ）（ＮＩＳＴ）によって維持される時計に従うべきことを義務付けている。この標準は、ＵＴＣ−ＮＩＳＴと呼ばれる。技術上、監査上、および法律上の精査を通らなければならない取引に関するどのタイムスタンプも、ＵＴＣ−ＮＩＳＴに同期している時計によって作成されなければならず、また同期プロセスは、「元を辿るのが可能」でなければならない。本明細書の全体にわたり、ＵＴＣ−ＮＩＳＴを引合いに出すが、説明する本発明は、どの国における実施にも、また、どの国のそれぞれの国内計時研究機関によって維持される標準時刻時計を使用する実施にも適用可能である。
　　　　　書類による商取引において、通常の書類による取引の「いつであるか」を提供するには、「元を辿るのが可能な」時計の使用で十分であった。書類の文書上の日付が偽造される多数のケースが存在したが、商取引に対するリスクは、比較的小さかった。しかし、ｅコマースの場合、日付の偽造は、コンピュータ指示プロセスに侵入し、非常に大きな規模で不正行為を行うことが可能であるため、はるかに大きいリスクを生じさせる。そのようなコンピュータ犯罪は、しばしば、電子タイムスタンプの偽造に関わり、正にこの理由で、これらのタイムスタンプを生成する電子時計を不正変更から保護することが、電子商取引における優先事項である。
　　　　　現行のネットワーク手続きは、ネットワーク内のすべてのワークステーション時計の同期を提供する。ＮＩＳＴおよびその他の機関は、ＵＴＣ−ＮＩＳＴに元を辿ることが可能な時計を有するネットワーク時刻サーバを提供する。クライアントワークステーションは、共通のプロトコルを介して自らの時刻をネットワーク時刻サーバと同期できる。ネットワーク時刻プロトコル（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）（ＮＴＰ）が、インターネットなどのＴＣＰ／ＩＰ網で一般的に使用されるが、その他のプロトコルも使用される。
　　　　　残念ながら、ローカルワークステーション時計がネットワーク時刻サーバに同期した後、その時刻は、ソースのネットワーク時刻サーバの信頼性に関係なく、操作を受ける可能性がある。これまで、タイムスタンプを生成するのに使用される時刻のソースを信頼できることを保証する作業は、ほとんどなされていない。今日、タイムスタンプを利用する大多数のアプリケーションは、単に自らのホストシステムからのシステム時計を使用する。システム時計を設定またはオフセットするための手続きが、一般的に知られている。したがって、従来のシステムにおけるシステム時計は、本質的に信頼のおけるものではない。
　　　　　この問題を克服する試みには、他のタイムスタンプが押される文書との関係で文書にタイムスタンプが押される順序に関する情報をタイムスタンプが組み込むタイムスタンプ順序付けが含まれる。（例えば、ハーバー他に発行された米国特許第５１３６６４７号を参照）。問題を克服する他の試みは、ＮＴＰまたは全地球測位システム（ＧＰＳ）などの他の時刻ソースの使用を組み込む。以上の試みは、システム時計を使用することに優る相当な改良であるが、この改良は、それでも、今日の電子ビジネスに必要とされる信頼モデルに適合するには十分でない。
　　　　　さらに別のシステムは、ローカル網の外部にある信頼される第三者のシステムによって維持される認定された時刻の使用を用いる。信頼される第三者システムは、共通のプロトコルを介してＵＴＣ−ＮＩＳＴと同期している状態を保つ。次に、ローカル網アプリケーションサーバが、第三者のシステムと通信を確立し、データオブジェクト（文書またはメッセージダイジェスト）が、第三者システムに送信されて、平文で、または暗号式に埋め込まれた文で、「タイムスタンプ」がデータオブジェクトに付加される。ただし、そのようなシステムは、タイムスタンプを押すたびに毎回、外部通信をする必要があることを考慮すると、特にローカル網によって多数のタイムスタンプが必要とされる場合、実際的でない可能性がある。
　　　　　別のシステムは、ローカル時計をローカル網の中に導入して、外部ソースからタイムスタンプを獲得することに関連する問題を回避する。ローカル時計は、ＵＴＣ−ＮＩＳＴに元を辿るのが可能な時計と定期的に同期させなければならない。ローカル時計とＵＴＣ−ＮＩＳＴに元を辿るのが可能な時計の間における頻繁な認定および較正を回避するため、ローカル時計は、有利には、セシウム原子時計である。セシウム原子時計は、市販されており、その周波数、したがって、時刻は、あるセシウム原子の電子軌道のエネルギー差によって引き起こされる原子現象から導出される。したがって、セシウム原子時計は、動作している限り、ほとんどの実際的な用途を満たすのに十分なだけ正確である。そのような時計は、３００００年の通常の動作で１秒しか損失しない。この理由で、セシウム原子時計は、「１次基準ソース」と呼ばれる。残念ながら、ローカルで使用される場合、システムの動作不良および意図的な操作を介して、時計の中の時間値がユーザには明白でない間違った値に変更される可能性が、それでも存在する。
　　　　　本発明のコンテキストでは、信頼される時刻は、使用される用途に関して法的な時刻ソースに元を辿るのが可能であると認定された時刻である。米国において施行される商業的用途のための、議会によって法的に義務付けられた法的な時刻ソースは、国立標準および技術研究所（ＮＩＳＴ）である。信頼される時刻を提供するためのインフラストラクチャは、監査のため、また後日の否認を防止する認定ログを含む強力な信頼モデルを提供しなければならない。
　　　　　信頼される時刻の必要性は、インターネットエンジニアリングタスクフォース（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）（ＩＥＴＦ）における標準化活動の開始によって画されたこの２年間に認識されるようになった。さらに、ほとんどの証明機関（ＣＡ）の製品およびサービスのベンダが、この分野における開発活動および新製品を発表している。本開示は、信頼される時刻を提供するための要件を満たす信頼される時刻インフラストラクチャ（Ｔｒｕｓｔｅｄ　Ｔｉｍｅ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）（ＴＴＩ）を説明する。また、本開示は、ＴＴＩが、今日、安全で法的拘束力のある電子取引を行うことができるのを保証するように開発された信頼モデルおよび暗号化標準にどのように適合するかも示す。」
　
（キ）
「The Trusted Time Infrastructure (TTI) provides a system for commercial or private timing distribution services to deliver to the application layer a trusted temporal token or trusted time stamp that cryptographically binds the current time of day derived from the NTA to a unique data request submitted by an application. Such a request may be made in response to events, transactions, or document submittals. public key digital signatures are preferably used as the binding mechanism to ensure the identity of the time distribution service and to protect the temporal token from undetected manipulation. 
　　　　　The time delivered by the TTI is preferably Universal Coordinated Time (UTC). The means by which the NTAs synchronize their UTC clocks (e.g., UTC(NIST)) with the International Bureau of Weights and Measures (BIPM) in France is outside of the scope of this disclosure. However, the UTC delivered by most of the major NTAs can be expected to be within nanoseconds of UTC (BIPM), while any of the other NTAs are still within microseconds of UTC (BIPM). Thus, for trusted time applications, where time is typically certified to be accurate to within 100 milliseconds at the application layer, the choice of which NTA to use is a legal issue for a particular country and not one of accuracy. 
2.　　　　Trusted Time Infrastructure (TTI) 
　　　　　Figure 2 illustrates a schematic of the key components of a preferred embodiment of the TTI and also illustrates the key transactions between these components. The embodiment of Figure 2 comprises an NTA Trusted Time Server (NTTS) 202, a Trusted Master Clock or Trusted Third Party Clock (TMC) 204, a Network Operations Center (NOC) 210, a Trusted Local Clock (TLC) 206, and an application 208. Although only one instance of each component is depicted in Figure 2 for instructive purposes, numerous instances of each element may be present in an actual TTI system. 
2.1　　　　Secure Communication Through Public Key Infrastructure (PKI) 
　　　　　The various elements in the TTI system communicate securely using PKI. Although PKI is often used to encrypt confidential communications, PKI can also be used to verify the origin of a communication through digital signatures. In the TTI system, the privacy of the communication between elements is generally not an issue. Instead, it is the authenticity of the communication that is generally of concern. 
　　　　　PKI authentication supports two aspects of the TTI system. First, PKI authentication supports authentication of communications between elements in the TTI system in order to maintain the integrity of the system as a whole. For example, if a Trusted Master Clock (TMC) 204 communicates with a Trusted Local Clock (TLC) 206 in order certify its time calibration, the TMC 204 must know for sure the identity of the TLC 206 that it is certifying. In another example, if a TMC 204 notifies the Network Operations Center (NOC) 210 of a time calibration certification of a TLC 206, the NOC 210 must be able to authenticate the identity of the certifying TMC 204. In an additional example, if a TMC 204 is capable of adjusting the time of a TLC 206, the TLC 206 must be able to verify that it is indeed a valid TMC 204 that is adjusting its time. In accordance with this first aspect, trusted temporal tokens preferably include the signed time calibration certification of the certifying clock. The NOC 210, through its PKI authentication capabilities, provides a system through which trusted time can be traced to the NTA Trusted Time Server (NTTS) 202 from any TLC 206 through authenticated time calibration certifications. In other words, the source of time from which a trusted temporal token has been derived can be traced back through signed time certifications to the NTTS 202. 
　　　　　A second aspect in which PKI authentication supports the TTI system is in authentication of temporal tokens themselves. The trusted temporal token includes a signed concatenation of a digest of the message to be time stamped as well as the time calibration certification of the issuing TLC 206. This signed concatenation allows the authenticity of the temporal token itself to be verified as being unaltered and issued by a particular TLC 206. 
2.2　　　　Key System Elements 
2.2.1　　　Trusted Time Server 
　　　　　The NTA Trusted Time Server (NTTS) 202 is the highest level clock in the TTI and is preferably located in a secure environment under government control. The NTTS 202 is the source of legal time from which the TTI derives its trusted time. The secure environment should be accessible only to trusted agents of the government timing authority (e.g. NIST), in order to ensure the integrity of the NTTS 202. The NTA is responsible for monitoring the accuracy of the NTTS-produced time and the operation of the NTTS 202 itself. 
　　　　　The NTTS 202 is responsible for measuring the clock offsets of the TMC 204 units. The NTTS 202 preferably performs this measurement over the Public Switched Telephone Network (PSTN). To measure the clock offsets of the TMCs, the NTTS 202 preferably supports a variant of Network Time Protocol (NTP) called Secure NTP (SNTP). NTP has been in use as a standard Internet Protocol since the early 1980s. SNTP is currently before the IETF as a draft protocol. It differs from NTP primarily in the establishment of a more robust authentication scheme based on more modern PKI techniques. For redundancy, two NTTS units are preferably located at the NTA, preferably at geographically separate locations. 
2.2.2　　　Trusted Master Clock 
　　　　　The Trusted Master Clock (TMC) 204 is an intermediary clock that serves to pass a trusted source of time from the NTA Trusted Time Server (NTTS) 202 to the Trusted Local Clock (TLC) 206 where the trusted time is actually used. The TMC 204 is preferably a stand-alone server located in a secure environment under the control of a trusted third party. This trusted third party can be the entity or organization implementing the whole TTI system or part of the TTI system. Again, the secure environment is preferably accessible only to trusted agents of the trusted third party to prevent tampering with the TMC 204. 
　　　　　Only one TMC is illustrated in Figure 2 for teaching purposes. Typically, however, the TTI network will contain a minimum of two TMCs. In some configurations, two or more TMCs may be linked in series between the NTTS 202 and the TLC 206. These and other configurations will be shown below. 
　　　　　The TMC 204 preferably comprises a Rubidium oscillator; a GPS receiver for monitoring the oscillator; cryptographic hardware; and a timing engine that generates trusted time. Each TMC 204 has a set of TLCs that it is responsible for time certifying. These sets of TLCs will be assigned by the Network Operations Center (NOC) 210. Preferably, the NOC 210 will ensure that at least two TMCs will be assigned to each TLC. This structure ensures sufficient redundancy so that the failure of a single TMC will not affect the operation and trust of the TLCs. It should be understood that a non-redundant configuration can be advantageously used when redundancy is not a concern. 
　　　　　The TMC 204 preferably uses the NT operating system configured for enhanced security. The TMC housing is designed to meet NIST Federal Information Processing Standard (FIPS) 140-1 Level 3 physical protection and tamper detection requirements (FIPS 140-1 is titled Security Requirements for Cryptographic Modules). Cryptographic calculations, including key generation, are performed by dedicated hardware. In the preferred embodiment, the private signing key of the TMC 204 is never exported from the cryptographic card. The cryptographic device also contains a high quality random number generator that can be used to generate new PKI key pairs. Sensitive cryptographic information is preferably contained in battery-backed memory, which will be erased in the event of a tamper alarm. The TMC 204 is preferably designed to receive a NIST validation rating of FIPS 140-1 Level 1 overall and Level 3 for physical security. 
　　　　　Audit trails are created for all TMC events, including all operator actions (logs include operator IDs), alarms, time certifications, and all remote NOC communications. These logs are digitally signed to prevent (by detection) subsequent forgery or alteration. The TMC 204 will typically include a GPS receiver that can be used to initialize the TMC 204 and to monitor the health of the TMC 204. If any abnormalities are detected in the TMC time source, the TMC 204 goes off line, attempts to isolate the problem, and shuts down. 
　　　　　The TMC 204 uses Secure NTP (SNTP) and User Datagram Protocol (UDP) to access each of its assigned TLCs periodically to measure its time offset. If the time of TLC 206 is within a certain offset (typically 100 ms) from the NTTS 202, the TMC 204 certifies the TLC 206 to be within that offset. The TMC 204 may also send small time corrections to the TLC 206 that can be used to make adjustments to the TLC 206 clock to keep it within specification. If a TMC 204 finds that a TLC 206 has a valid, recent Time Calibration Certificate (TCCert) then it takes no action. 
2.2.3　　　Network Operations Center 
　　　　　The Network Operations Center (NOC) 210 serves as the central control facility for the TTI system. The NOC 210 is preferably located in a secure environment under the control of a trusted third party. 
　　　　　Figure 3 illustrates a functional block diagram of the NOC 210. The NOC 210 communicates with the various elements of the TTI through a communications network 302. The communications network 302 may comprise the Public Switched Telephone Network (PSTN), the Internet, and/or other computer networks. A firewall 304 protects the internal systems of the NOC 210 from external attack through the communications network 302. The NOC 210 comprises an element manager 306, which is a configuration and maintenance system that has the ability to remotely configure and monitor the NTTS 202, TMCs 204, and TLCs 206 using a secure management protocol. In addition, the NOC 210 comprises a central database 308 that is used to store all TMC and TLC time certification logs. 
　　　　　The NOC 210 also comprises a web server 310 that handles temporal token verification requests sent via the World Wide Web. The web server 310 interfaces with the element manager 306 to initiate a verification action and to return the response to the requestor. The web server 310 preferably uses Secure Sockets Layer (SSL) with server authentication in order to encrypt and authenticate the server data exchanged between the client and the server. The NOC 210 further comprises a billing system 312 for trusted time service subscribers. The billing system 312 logs data regarding the number of tokens issued by a TLC 206. 
　　　　　The NOC 210 comprises three additional functional components that implement the PKI authentication capability of the TTI system. The Registration Authority (RA) 312 associates each device in the TTI system with a name. In this manner, TTI devices can be identified, monitored, and controlled. The Certification Authority (CA) 314 associates a public key with each device using the name of the device provided by the RA 312. The Online Certificate Status Protocol (OCSP) responder 316 responds to requests for digital certificates for devices in the TTI system. The OCSP responder 316 serves as a trusted source of digital certificates. Digital certificates provide a data structure associating a public key with a signing device and allow verification/authentication of the signed communications of TTI devices. Since the NOC 210 knows all elements comprising the TTI, the NOC 210 acts as an RA 312 to the CA 314 for the issuance of digital certificates to the TTI elements. The TTI preferably uses ITU-T X.509v3 digital certificates. Each element within the TTI preferably has a distinguished name so that it may be uniquely identified. The name structure is preferably aligned with the International Telecommunications Union--Telecommunication Standardization Sector (ITU-T) X.501/X.520 standards for distinguished names. The use of an RA, a CA, and an OCSP responder is known in the art and information regarding this topic is available from entities such as the IETF (Internet Engineering Task Force). 
　　　　　The NOC 210 preferably also comprises a billing system 318 that interacts with the element manager 306 and the database 308 in order to assemble client billing information. A number of different billing schemes will be discussed in the section on billing below. 2.2.4 Trusted Local Clock 
　　　　　The Trusted Local Clock (TLC) 206 provides trusted time, preferably in the form of a trusted temporal token, to the application 208 on request. The TLC 206 is hosted in a customer-owned server and is preferably a PCIv2.1 compliant card that is tamper-resistant and is assumed to be operating in an insecure host in an insecure environment. 
　　　　　The TLC 206 comprises an oscillator and a timing engine, which generates trusted time. A Time Calibration Certificate (TCCert) typically has a period during which it is valid. The range of accuracy specified by the TCCert during the valid period accounts for the accuracy of the TLC's oscillator and timing engine. The TCCert therefore, serves as assurance of the accuracy, during the valid period, of the certified clock. 
　　　　　The TLC 206 preferably uses a real time operating system to control the on-card functions. The TLC 206 preferably has its own Ethernet TCP/IP connection for communications with the TMC 204 and NOC 210. 
　　　　　Cryptographic calculations in the TLC 206 are preferably performed using a dedicated hardware PCMCIA (Personal Computer Memory Card International Association) cryptography engine. This cryptographic device preferably also contains a high quality pseudorandom number generator. Key generation is performed on the PCMCIA device. The private key for the TLC 206 will preferably never be exported from the PCMCIA cryptography engine. Sensitive cryptographic information is contained in battery-backed memory that is preferably erased in the event of a tamper alarm. The TLC 206 preferably has a NIST validation rating of FIPS 140-1 Level 1 overall and Level 3 for physical security. Audit trails are preferably created for all TLC events, including all operator actions (logs include operator IDs), alarms, time certifications performed, temporal tokens issued, and all remote NOC 210 communications. These logs are digitally signed to prevent (by detection) subsequent forgery or alteration. 
　　　　　Like the TMC 204, the TLC 206 can include a GPS receiver to initialize the TLC 206 and to monitor the health of the TLC 206. If any abnormalities are detected in the TLC time source, the TLC 206 goes off line, attempts to isolate the problem, and shuts down. 
2.2.5　　　Application 
　　　　　The application 208 is any process or device that requests trusted temporal tokens from the TLC 206. The application 208 can run on the same server that hosts the TLC 206 or the application 208 can run on any other machine in communication with the host server. The application 208 can request verification of a time stamp through the NOC 210. Alternatively, a time stamp obtained by an application 208 can be passed to another application. The other application can then perform the verification of the time stamp through the NOC 210. 
　　　　　Client applications 208 access the TLC 206 using a Trusted Time Application Program Interface (TTAPI). The TTAPI will communicate with its associated TLC 206 using the Transport Layer Security/Secure Sockets Layer (TLS/SSL) protocol. Server applications co-located with a TLC 206 access the TLC 206 using a Trusted Local Clock Application Program Interface. 
2.3　　　　TTI System 
　　　　　Figure 4 illustrates one embodiment of a TTI system 400 including a network of clocks and applications. The system 400 comprises two NTTSs 202A-B for redundancy, preferably located in separate locations. Two TMCs 204A-B are directly certified by the NTTSs. The TMC 204A directly certifies a TLC 206A, while the TMC 204B directly certifies a TLC 206D. The TMC 204A also certifies another TMC 204C, which in turn certifies a TLC 206B, and similarly TMC 204B certifies TMC 204D, which in turn certifies TLC 206C. As illustrated, time certification logs are passed from the TLCs 206 up to the highest level TMCs 204 and then on to the NOC 210. 
　　　　　In the case that any clock fails, the device below that clock in the TTI can request service from an alternate clock. If the NTTS 202A fails, for example, the TMC 204A can request certification from the NTTS 202B. Similarly, if the TMC 204A fails, the TLC 206A and the TMC 204C can request certification from the TMC 204B. 
　　　　　Applications 208A, 208B, and 208C request trusted time tokens from their respective TLCs. Upon receiving trusted time tokens, the applications then can route verification requests to the NOC 210. 
2.4　　　　Application Bounded Time Service 
　　　　　Another embodiment of the TTI system or a portion thereof may be configured as an application bounded time service. In application bounded time service, trusted time is provided to a specific application offered by a single third party. For example, if Company X wants to sell certified e-mail gateway servers, each equipped with a TLC, the TLCs will be synchronized by TMCs operated by Company X. Company X's TMCs in turn are certified by TMCs of a trusted third party. Depending on the particular application, application bounded time service may require a separate NOC. 
3.　　　　Calibration and Certification 
　　　　　This section describes how clock calibration and certification is performed in the TTI. Individual timing elements in the TTI are enabled for operation when they possess a Time Calibration Certificate (TCCert). In the preferred embodiment, TLCs cannot issue trusted temporal tokens unless they have been issued a valid TCCert. Also in the preferred embodiment, a TMC cannot certify a lower clock unless the TMC has been issued a valid TCCert. 
　　　　　After measuring the calibration of a lower clock, an upper clock issues a TCCcert to the lower clock to certify that the time of the lower clock is within a certain tolerance with respect to the upper clock. The upper clock signs the TCCerts to assure authenticity. 
3.1　　　　Procedural Overview 
　　　　　Figure 5 illustrates an overview of the process by which a preferred embodiment of the TTI system generates trusted temporal tokens. The steps illustrated in Figure 5 are also depicted by the arrows between elements in Figure 3. 
　　　　　At a first step 502, the NTTS 202 certifies a TMC 204, sends a TCCert to the TMC 204, and records the certification locally. The TMC 204 then sends the TCCert to the NOC 210 for logging at a step 504. At this point, the TMC 204 possesses a valid TCCert and is capable of time certifying other lower clocks. At a step 506, the TMC 204 time certifies a TLC 206, sends a TCCert to the TLC 206, and records the certification. The TMC 204 also retrieves from the TLC 206 the number of trusted temporal tokens that the TLC 206 has issued since the last certification. This number is preferably used for billing purposes. At a step 508, the TMC 204 sends the TCCert and the token count of the TLC 206 to the NOC 210 for logging. 
　　　　　Once the TLC 206 has been certified, the TLC 206 is ready to issue trusted temporal tokens under its new TCCert. At a step 512, an application requests and the TLC 206 issues a new trusted temporal token. At a step 514, the application verifies the authenticity of the temporal token through the NOC, possibly at a future date. 
3.2　　　　TCCERT Generation 
　　　　　Figure 6 illustrates a preferred embodiment of the process by which an upper clock certifies the time of a lower clock, as in steps 502 and 506 of Figure 5. In the context of this illustration, an upper clock is intended to represent the NTTS or a TMC, while a lower clock is intended to represent another TMC or a TLC that is further down the chain of trusted time from the NTTS than the upper clock. When a higher level clock measures the offset of a lower clock and finds it within specification, a TCCert is created to record this determination. At a step 602, the lower clock creates a TCCert Request (TCCertReq) which preferably comprises: 
　　　　　Upper Clock ID; 
　　　　　Lower Clock ID; 
　　　　　Lower Clock Accuracy; 
　　　　　Lower Clock Signature Parameters; and 
　　　　　Lower Clock Signature (across above fields). 
　　　　　The lower clock then sends the TCCertReq to the upper clock. At a step 604 the upper clock receives the TCCertReq from the lower clock. The upper clock validates the signature of the lower clock and verifies that the lower clock ID is correct at a step 606. At a step 608, the upper clock measures the time offset of the lower clock using Secure NTP (SNTP). 
　　　　　The upper clock determines whether the offset of the lower clock is within acceptable limits at a step 610. If the lower clock is within acceptable limits, control passes to a step 614. At the step 614, the upper clock calibrates or adjusts and again measures the offset of the lower clock if necessary. At a step 616, the upper clock creates the TCCert by appending preferably the following fields to the TCCertReq: 
　　　　　TCCert Time; 
　　　　　Class of Service ID; 
　　　　　Lower Clock Offset; 
　　　　　TCCert Accuracy; 
　　　　　TCCert Expire Time; 
　　　　　Delay; 
　　　　　TCCert of Upper Clock (optionally); and 
　　　　　Upper Clock Signature Parameters. 
　　　　　To create the final TCCert, the upper clock appends its digital signature across the TCCertReq and the above-appended fields. By optionally including the TCCert of the upper clock in the TCCert of a lower clock, the complete trace of trusted time from the NTTS down to the lowest level can be encapsulated in each TCCert. At a step 618, the upper clock stores and records the TCCert and sends the TCCert to the lower clock. 
　　　　　If, at step 610, the time of the lower clock is found to be out of acceptable limits, it is possible that the clock has failed or has been tampered with. In this case, control passes to step 612. At step 612, the field TCCert Time is set to an illegal value, and the field Class of Service ID is set to Out of Calibration. If a lower clock has been found to be out of calibration, any TCCerts or trusted temporal tokens issued by the lower clock since its last TCCert issuance should be considered suspect. Accordingly, the NOC 210 should be notified of the out of calibration measurement so that its database can reflect the invalidity of the previous TCCert and any trusted temporal tokens derived from it. If the NOC 210 has been notified of the out of calibration measurement, control is optionally passed back to step 614 for recalibration and recertification of the lower clock. 
3.2.1　　　NTTS to TMC Calibration 
　　　　　The NTTS measures the clock offsets of the TMCs using PSTN connections and the SNTP protocol preferably once per day. The TMC clock offsets are expected to be within 10 milliseconds of UTC as provided by the NTTS. For successful clock offset measurements, the NTTS returns a TCCert indicating the TMC is enabled for time calibration of lower clocks. The NTTS TCCert Expiration Date is preferably seven (7) days from the date of TCCert issuance. In order to keep the NTA implementation simple, an NTA-level CA may not be used. Therefore, the NTTS may not explicitly verify the validity of the TMC certificates that it receives via SNTP with the respective CAs that produced them. Rather, the NTTS simply verifies that the received certificate matches the one that was loaded in its internal database during initialization for that timing service. Should a certificate be received via SNTP that is not in the NTTS database, the NTTS will log an error message with the received certificate and will refuse the connection. 
　　　　　The NTTS preferably logs all clock offset measurement information to paper. The printed records preferably contain the following information: 
　　　　　UTC Time of Calibration; 
　　　　　Trusted Master Clock Name; 
　　　　　Measured Offset; 
　　　　　NTTS Certificate Serial Number; and 
　　　　　Trusted Master Clock Certificate Serial Number. 
3.2.2　　　TMC to TLC Calibration 
　　　　　Each TMC has a set of TLCs that it is responsible for certifying. Using SNTP, each TMC contacts each of the TLCs in its set once per day and requests its TCCert. If the received TCCert is less than 24 hours old, the TMC skips certification of that unit, closes the SNTP session and moves on to query the next TLC on its list. If the received TCCert is equal to or greater than 24 hours old, the TMC measures the TLC's time offset, computes the time correction, and sends this correction to the TLC clock to keep it within specification. The offset is again measured, and if the TLC clock is within specification, the TMC issues a TCCert to the TLC stating that it is within a certain offset from UTC. It is expected that the TMC will certify the TLC to be within 100 ms of UTC. 
3.3　　　　Trusted Time Guarantee 
　　　　　The preferred embodiment of the TTI system combines a number of aspects to guarantee that the time stamp on a trusted temporal token has been derived from a source of time that is synchronized with an accepted standard, or that the TTI system provides trusted time. The first aspect is that the physical devices of which the TTI system is comprised are either located in physically secure, trusted, facilities, or are designed to be physically tamper proof. The second aspect is that communications between elements in the TTI system are authenticated, and, if necessary, encrypted using the PKI system. The third aspect is that the time maintained by a TLC can be linked, through certifications using SNTP calibrations of a chain of trusted clocks, all the way to the NTTS or to another commonly accepted source of time. The fourth aspect is that each clock to be certified is specified to maintain at least a certain accuracy over the duration of a valid TCCert. Accordingly, each TCCert can guarantee that the certified clock's time will be within its specified accuracy during the valid period of its TCCert plus the possible temporal variations introduced by the variations due to the accuracy of the foregoing certifying clocks during the valid periods of their respective TCCerts. 
4.　　　　Trusted Temporal Token Generation and Verification 
　　　　　Once a TLC 206 has a valid TCCert, the TLC 206 is capable of issuing valid trusted temporal tokens. The tokens preferably include a concatenation of the data to be time-stamped and a time stamp supplied by a trusted source of time, in this case, the internal clock of the TLC 206. The signing of the complete message by the TLC 206 functions to bind the data to the time stamp such that the time stamp cannot be altered without detection. 
　　　　　Once a token is generated, it is returned to the requesting application. The requesting application can then verify the authenticity of the token. In addition or in the alternative, the application may pass the token on to another application that may choose to verify the token again in the future. 
　　　　　An application can confirm the authenticity of the token by (1) checking with the NOC 210 that the issuing TLC 206 was in possession of a valid TCCert at the time of token issue, and (2) verifying the signature of the token by obtaining, preferably from the NOC 210, a digital certificate containing the corresponding public key of the TLC 206. 
4.1　　　　Token Generation 
　　　　　Figure 7 illustrates a preferred embodiment of the process by which trusted temporal tokens are generated by a TLC 206. At a first step 702, an application 208 sends a request, including the data to be time stamped, to the issuing TLC 206. The data, in most cases, will comprise a digest, created by a one-way hash function, of the electronic document to be time stamped. At a step 704, the TLC 206 receives the data and concatenates the data, the current time and a TCCert Log Pointer (typically an upper clock ID, a lower clock ID, and the time of the TCCert). The TLC 206 then signs the concatenation to form the trusted temporal token. In an alternative embodiment, the TCCert itself is included rather than the TCCert Log Pointer. At a step 706, the TLC 206 returns the trusted temporal token to the application 208. Thereafter, the TLC 206 increments its internal log of the number of tokens issued for billing purposes. The number is subsequently transmitted, either directly or through a TMC 204, to the NOC 201 for processing and billing. 
4.2　　　　Token Verification 
　　　　　Figure 8 illustrates a preferred embodiment of the process by which an application can verify the authenticity of a trusted temporal token. At a first step 802, the application connects to and authenticates the identity of the NOC 210. Next, the application sends a verification request, including the token to be verified, to the NOC 210 at a step 804. The NOC 210 maintains a database of all of the TCCerts of all of the clocks in the TTI system. In addition, the NOC 210 either includes or has access to the CA for all of the TTI elements. The CA is the source of digital certificates through which the signatures of the TTI elements can be verified. 
　　　　　From step 804, the preferred embodiment of the present process proceeds to a step 806. At the step 806 the NOC 210 determines the authenticity of the submitted token using the TCCerts in its database and the digital certificate associated with the issuing TLC 206. At a subsequent step 808, the NOC 210 supplies a signed verification notification, indicating the status of the submitted token, to the requesting application. 
　　　　　In an alternative embodiment, the process proceeds to a step 810 from the step 804. At the step 810, the NOC 210 determines whether the issuing TLC 206 was in possession of a valid TCCert. If so, the NOC 210 supplies a digital certificate of the issuing TLC 206 to the requesting application at a step 812. At a step 814, the application confirms the authenticity of the token using the digital certificate to verify the token's signature. If, at step 810, the NOC determines, by checking its databases, that the issuing TLC 206 did not possess a valid TCCert or that the TCCert is suspect, the process proceeds to step 816. At step 816, the NOC 210 sends notification to the requesting application that the token cannot be authenticated. 
5.　　　　Security Schemes 
　　　　　A number of different schemes can be used in conjunction with the disclosed TTI to ensure that the time stamp contained in a trusted temporal token is indeed derived from a source of trusted time. The schemes have varying advantages and disadvantages and balance increased security with increased verification, processing, and storage costs. The objective of these schemes is to ensure that a trusted temporal token has been issued by a TLC with a valid TCCert. 
5.1　　　　Basic Scheme A 
　　　　　A first security scheme relies upon the fact that a TLC has been issued a TCCert within a fixed period previous to the token issue in order to guarantee the validity of an issued time stamp. A TCCert is given a valid duration, such as, for example, seven days, during which the certified TLC can issue time stamps. If a TCCert expires or the TLC is issued a new TCCert, the old TCCert is destroyed by the TLC. In order to check the validity of a token, an application or the NOC 210 checks that the time of a time stamp corresponds to a valid period of the TCCert included in or referenced by the trusted temporal token. The NOC 210 must also check that the TCCert itself is valid by tracing the source of trusted time through additional TCCerts of higher clocks up to the NTTS 202. 
5.2　　　　Basic Scheme B 
　　　　　A variation of the previous scheme relies upon the alternative fact that a TLC was issued a valid TCCert within a certain time after issuing a trusted temporal token. In this case, TCCerts are considered valid for a fixed duration, such as seven days, before they are issued. Here, it is assumed if a TLC keeps time to within acceptable limits of NTTS time, the TLC has maintained this time for a reasonable period previous to the certification. In order to implement such a system, the TLCs would have to incorporate a reference to a TCCert that has not yet been issued in each trusted temporal token. The NOC 210 could then associate the references with the later issued TCCerts upon their issuance. The checking of trusted temporal tokens under this scheme could be achieved in a manner similar to the previous scheme. 
5.3　　　　High Trust Scheme 
　　　　　A high trust scheme combines the aspects of Basic Schemes A and B above. In this scheme, the NOC checks that a TCCert has been issued to the issuing TLC within a fixed period before and within a fixed period after the issuance of the trusted temporal token. In this case, the trusted temporal token need only contain a reference to the TCCert issued the TLC before the token issue. The NOC can then determine whether a subsequent TCCert has been issued within the requisite time period following the token issuance. 
5.4　　　　Alternative Scheme 
　　　　　An alternative scheme provides a similar trust guarantee to scheme A, particularly, that a TLC has been issued a TCCert within a fixed period prior to issuing a trusted temporal token. This scheme, however, eliminates the necessity of archiving all of the individual TCCerts for all of the TLCs in the TTI system. Instead, each TCCert contains the complete TCCert of the issuing clock. In this manner, each TCCert will contain a complete, authenticatable chain of certifications from the NTTS all the way down to the issuing TLC. Instead of cataloguing the TCCerts of all of the individual clocks, each trusted temporal token will contain the complete chain of TCCerts linking the trusted time, from which the token was derived, to the NTTS. The public keys of each of the certifying or issuing clocks would then be made available through the CA 314 of the NOC 210, possibly using an Online Certificate Status Protocol (OCSP) responder 316, so that individual applications can independently verify the validity of trusted temporal tokens and the chain of trusted time leading to its creation. 
6.　　　　　Business Model 
　　　　　A billing scheme can also be integrated into the disclosed invention in order to facilitate the operation of the TTI as part of an on-going business concern. A number of different billing schemes providing various benefits can be used in conjunction with the TTI system. 
6.1　　　　Per Stamp Billing 
　　　　　The disclosed system provides mechanisms for TLCs to transmit to the NOC the number of time stamps issued. The NOC can be adapted to log this information and create billing reports for individual clients automatically. In this case clients could be billed for each time stamp issued. 
6.2　　　　Flat Rate Certification 
　　　　　An alternative scheme is based upon billing clients for time certification of each TLC located on the clients' premises. In this case, a client pays for each issued TCCert and receives a flat rate on all of the time stamps issued during the valid TCCert period. In this case, the NOC coordinates and automates billing procedures. 
6.3　　　　Charges for Verification 
　　　　　In one business model, verification services for issued time stamps are provided free of charge to any entity wanting to check the validity of a time stamp. Alternatively, verification services could be provided for a fee through the NOC. 」（第６頁第１９行目から第１５頁第１５行目）
　
　上記記載は、以下のような事項が記載されているものと認められる。
　
「信頼される時刻インフラストラクチャ（ＴＴＩ）が、ＮＴＡから導出された現在時刻をアプリケーションによってサブミットされた固有データ要求に暗号式に結合する「信頼される時間トークン」または「信頼されるタイムスタンプ」をアプリケーションレイヤに配信する商業的、または私的計時配信サービスのためのシステムを提供する。そのような要求が、イベント、取引、または文書のサブミットに応答して行われることが可能である。時刻配信サービスの身元を保証し、検出されない操作から時間トークンを保護するため、公開鍵デジタル署名が、好ましくは、結合機構として使用される。
　　　　　ＴＴＩによって配信される時刻は、好ましくは、協定世界時（ＵＴＣ）である。ＮＴＡが、自体のＵＴＣ時計（例えば、ＵＴＣ（ＮＩＳＴ））をフランス国の国際度量衡局（ＢＩＰＭ）と同期させる手段は、この開示の範囲外である。ただし、主要なＮＴＡのほとんどによって配信されるＵＴＣは、ＵＴＣ（ＢＩＰＭ）から数ナノ秒の範囲内にあると予期することができ、一方、その他のＮＴＡのどれも、やはりＵＴＣ（ＢＩＰＭ）から数マイクロ秒の範囲内にある。したがって、時刻が、通常、アプリケーションレイヤにおいて１００ミリ秒の範囲内で正確であることが認定される信頼される時刻アプリケーションの場合、どのＮＴＡを使用するかの選択は、特定の国に関する法律上の問題であり、精度の問題ではない。
２．　　　信頼される時刻インフラストラクチャ（ＴＴＩ）
　　　　　図２は、ＴＴＩの好ましい実施形態の主要な構成要素の概略を示し、またその構成要素間の主要なトランザクションも示している。図２の実施形態は、ＮＴＡの信頼される時刻サーバ（ＮＴＴＳ）２０２と、信頼されるマスタ時計または信頼される第三者時計（ＴＭＣ）２０４と、ネットワークオペレーションセンタ（ＮＯＣ）２１０と、信頼されるローカル時計（ＴＬＣ）２０６と、アプリケーション２０８とを含む。教示のため、各構成要素の１つの実例だけを図２で描いているが、各要素の多数の実例が実際のＴＴＩシステムの中に存在することが可能である。
２．１　　公開鍵インフラストラクチャ（ＰＫＩ）を介する安全な通信
　　　　　ＴＴＩシステムの中の様々な要素が、ＰＫＩを使用して安全な仕方で通信する。ＰＫＩは、機密の通信を暗号化するのにしばしば使用されるが、デジタル署名を介して通信の発信元を確認するのに使用することも可能である。ＴＴＩシステムにおいて、要素間の通信のプライバシーは、一般に問題ではない。代りに、一般的な問題は、通信の真正性である。
　　　　　ＰＫＩ認証は、ＴＴＩシステムの２つの態様をサポートする。第１に、ＰＫＩ認証は、システム全体の完全性を維持するため、ＴＴＩシステムにおける要素間の通信の認証をサポートする。例えば、信頼されるマスタ時計（ＴＭＣ）２０４が、信頼されるローカル時計（ＴＬＣ）２０６の時刻較正を認定するため、ＴＬＣ２０６と通信する場合、ＴＭＣ２０４は、自らが認定を行うＴＬＣ２０６の身元を確実に知っていなければならない。別の例では、ＴＭＣ２０４が、ＴＬＣ２０６の時刻較正認定をネットワークオペレーションセンタ（ＮＯＣ）２１０に通知する場合、ＮＯＣ２１０は、認定を行うＴＭＣ２０４の身元を認証できなければならない。さらなる例では、ＴＭＣ２０４が、ＴＬＣ２０６の時刻を調整することができる場合、ＴＬＣ２０６は、自らの時刻を調整するのが実際に確かなＴＭＣ２０４であることを確認できなければならない。この第１の態様によれば、信頼される時間トークンは、好ましくは、認定を行う時計の署名された時刻較正認定を含む。ＮＯＣ２１０は、自らのＰＫＩ認証機能を介し、認証された時刻較正認定を介して任意のＴＬＣ２０６からＮＴＡの信頼される時刻サーバ（ＮＴＴＳ）２０２まで信頼される時刻を元に辿ることが可能なシステムを提供する。言い換えれば、信頼される時間トークンが導出された時刻ソースを署名された時刻認定を介して、ＮＴＴＳ２０２まで元に辿ることができる。
　　　　　ＰＫＩ認証がＴＴＩシステムをサポートする第２の態様は、時間トークン自体の認証である。信頼される時間トークンは、タイムスタンプが押されるメッセージのダイジェストと発行を行うＴＬＣ２０６の時刻較正認定の署名された連結を含む。この署名された連結により、時間トークン自体が、変更されておらず、特定のＴＬＣ２０６によって発行されたものとする真正性を確認することができる。
２．２　　主要なシステム要素
２．２．１信頼される時刻サーバ
　　　　　ＮＴＡの信頼される時刻サーバ（ＮＴＴＳ）２０２は、ＴＴＩの中の最高レベルの時計であり、好ましくは、政府の管理下の安全な環境の中に配置される。ＮＴＴＳ２０２は、ＴＴＩが自らの信頼される時刻を導出する法定時刻ソースである。安全な環境は、ＮＴＴＳ２０２の完全性を保証するため、政府計時機関（例えば、ＮＩＳＴ）の信頼されるエージェントにとってだけアクセス可能でなければならない。ＮＴＡは、ＮＴＴＳによって生成された時刻の正確さ、およびＮＴＴＳ２０２の動作自体を監視することを担う。
　　　　　ＮＴＴＳ２０２は、ＴＭＣ２０４ユニットの時計のずれを測定することを担う。ＮＴＴＳ２０２は、好ましくは、公衆交換電話網（ＰＳＴＮ）を介してこの測定を行う。ＴＭＣの時計のずれを測定するため、ＮＴＴＳ２０２は、好ましくは、セキュアＮＴＰ（ＳＮＴＰ）と呼ばれるネットワーク時刻プロトコル（ＮＴＰ）の変形形態をサポートする。ＮＴＰは、１９８０年代初期以来、標準のインターネットプロトコルとして使用されてきた。ＳＮＴＰは、現在、草案段階のプロトコルとしてＩＥＴＦで検討中である。ＳＮＴＰは、主により新しいＰＫＩ技術に基づくより堅固な認証スキームの確立においてＮＴＰと異なる。冗長性のため、２つのＮＴＴＳユニットが、好ましくは、ＮＴＡに、好ましくは、地理的な離れた場所に配置される。
２．２．２信頼されるマスタ時計
　　　　　信頼されるマスタ時計（ＴＭＣ）２０４は、ＮＴＡの信頼される時刻サーバ（ＮＴＴＳ）２０２から、信頼される時刻が実際に使用される信頼されるローカル時計（ＴＬＣ）２０６に時刻の信頼されるソースを中継する作用をする中継時計である。ＴＭＣ２０４は、好ましくは、信頼される第三者の管理下の安全な環境の中に配置された独立型のサーバである。この信頼される第三者は、ＴＴＩシステム全体またはＴＴＩシステムの一部を実装するエンティティまたは機関であることが可能である。この場合も、ＴＭＣ２０４の不正変更を防止するため、安全な環境は、好ましくは、信頼される第三者の信頼されるエージェントだけにアクセス可能である。
　　　　　１つのＴＭＣだけを教示の目的で図２に示す。ただし、通常、ＴＴＩネットワークは、最小限で２つのＴＭＣを含む。いくつかの構成では、２つの以上のＴＭＣをＮＴＴＳ２０２とＴＬＣ２０６の間に直列でリンクすることができる。以上およびその他の構成を以下に示す。
　　　　　ＴＭＣ２０４は、好ましくは、ルビジウム発振器と、発振器を監視するためのＧＰＳ受信器と、暗号化ハードウェアと、信頼される時刻を生成する計時エンジンとを含む。各ＴＭＣ２０４は、自らが時刻認定することを担う１組のＴＬＣを有する。ＴＬＣのこれらのセットは、ネットワークオペレーションセンタ（ＮＯＣ）２１０によって割り当てられる。好ましくは、ＮＯＣ２１０は、少なくとも２つのＴＭＣが各ＴＬＣに割り当てられることを保証する。この構造により、十分な冗長性を保証し、単一のＴＭＣの障害がＴＬＣの動作および信頼性に影響を与えないようにする。冗長性が問題でない場合、冗長性のない構成を有利に使用できることを理解されたい。
　　　　　ＴＭＣ２０４は、好ましくは、より高いセキュリティのために構成されたＮＴオペレーティングシステムを使用する。ＴＭＣハウジングは、ＮＩＳＴ連邦情報処理標準（Ｆｅｄｅｒａｌ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｔａｎｄａｒｄ）（ＦＩＰＳ）１４０−１のレベル３の物理的保護および不正変更検出要件（ＦＩＰＳ１４０−１は、「Ｓｅｃｕｒｉｔｙ　Ｒｅｑｕｉｒｅｍｅｎｔｓ　ｆｏｒ　Ｃｒｙｐｔｏｇｒａｐｈｉｃ　Ｍｏｄｕｌｅｓ：暗号モジュールの安全性要求」という名称である）を満たすように設計される。鍵生成を含む暗号計算は、専用ハードウェアによって行われる。好ましい実施形態では、ＴＭＣ２０４の秘密署名鍵は、暗号化カードから決してエクスポートされない。暗号化装置は、新しいＰＫＩ鍵ペアを生成するのに使用することができる高品質の乱数発生器も含む。センシティブな暗号情報は、好ましくは、バッテリバックアップ付きメモリの中に収められ、不正変更警報が行われたときに消去される。ＴＭＣ２０４は、好ましくは、全体的としてＦＩＰＳ１４０−１のレベル１の、また物理的セキュリティに関してレベル３のＮＩＳＴ認可レーティングを受けるように設計される。
　　　　　すべてのオペレータの処置（ログは、オペレータＩＤを含む）、警報、時刻認定、およびすべての遠隔ＮＯＣ通信を含むすべてのＴＭＣイベントに関して、監査証跡が作成される。これらのログは、デジタル式に署名され、後の偽造または改ざんを（検出により）防止する。ＴＭＣ２０４は、通常、ＴＭＣ２０４を初期設定し、ＴＭＣ２０４の健全性を監視するのに使用することができるＧＰＳ受信器を含む。何らかの異常がＴＭＣ時刻ソースにおいて検出された場合、ＴＭＣ２０４は、オフライン状態になり、問題を分離しようと試み、シャットダウンする。
　　　　　ＴＭＣ２０４は、セキュアＮＴＰ（ＳＮＴＰ）およびユーザデータグラムプロトコル（ＵＤＰ）を使用して自らの割り当てられたＴＬＣのそれぞれに定期的にアクセスして、その時刻のずれを測定する。ＴＬＣ２０６の時刻が、ＮＴＴＳ２０２からのあるずれ（通常、１００ミリ秒）の範囲内にある場合、ＴＭＣ２０４は、ＴＬＣ２０６がそのずれの範囲内にあるものと認定する。また、ＴＭＣ２０４は、ＴＬＣ２０６に調整を行うのに使用して規定の範囲内に保つことができる小さい時刻修正をＴＬＣ２０６に送信することもできる。ＴＬＣ２０６が有効な最近の時刻較正認定（ＴＣＣｅｒｔ）を有することが、ＴＭＣ２０４に分かった場合には、ＴＭＣ２０４は、全く処置を行わない。
２．２．３ネットワークオペレーションセンタ
　　　　　ネットワークオペレーションセンタ（ＮＯＣ）２１０は、ＴＴＩシステムに関する中央制御施設として作用する。ＮＯＣ２１０は、好ましくは、信頼される第三者の管理下の安全な環境の中に配置される。
　　　　　図３は、ＮＯＣ２１０の機能ブロック図を示す。ＮＯＣ２１０は、通信網３０２を介してＴＴＩの様々な要素と通信する。通信網３０２は、公衆交換電話網（ＰＳＴＮ）、インターネット、および／またはその他のコンピュータネットワークを含むことが可能である。ファイアウォール３０４が、通信網３０２を介する外部の攻撃からＮＯＣ２１０の内部システムを保護する。ＮＯＣ２１０は、安全な管理プロトコルを使用してＮＴＴＳ２０２、ＴＭＣ２０４、およびＴＬＣ２０６を遠隔式に構成し、監視する能力を有する構成−保守システムである要素マネージャ３０６を含む。さらに、ＮＯＣ２１０は、すべてのＴＭＣとＴＬＣの時刻認定ログを記憶するのに使用される中央データベース３０８を含む。
　　　　　また、ＮＯＣ２１０は、ワールドワイドウエブ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）を介して送信される時間トークン確認要求を扱うウエブサーバ３１０も含む。ウエブサーバ３１０は、要素マネージャ３０６とインターフェースを取り、確認動作を開始し、応答を要求側に返す。ウエブサーバ３１０は、好ましくは、クライアントとサーバの間で交換されるサーバデータを暗号化し、認証するため、サーバ認証を伴うセキュアソケットレイヤ（ＳＳＬ）を使用する。ＮＯＣ２１０は、信頼される時刻サービスの加入者に対する料金請求システム３１２をさらに含む。料金請求システム３１２は、ＴＬＣ２０６によって発行されたトークンの数に関するデータをログ記録する。
　　　　　ＮＯＣ２１０は、ＴＴＩシステムのＰＫＩ認証能力を実装する３つの追加機能構成要素を含む。登録機関（ＲＡ）３１２が、ＴＴＩシステムの中の各装置を名前に関連付ける。これにより、ＴＴＩ装置の識別、監視、および制御を行うことが可能である。証明機関（ＣＡ）３１４が、ＲＡ３１２によって提供される装置の名前を使用して各装置に公開鍵を関連付ける。オンライン証明ステータスプロトコル（ＯＣＳＰ）レスポンダ３１６が、ＴＴＩシステムの中の装置に関するデジタル証明の要求に応答する。ＯＣＳＰレスポンダ３１６は、デジタル証明の信頼されるソースの作用をする。デジタル証明は、公開鍵を署名を行う装置に関連付けるデータ構造を提供し、ＴＴＩ装置の署名された通信の確認／認証を可能にする。ＮＯＣ２１０は、ＴＴＩを含むすべての要素を知っているので、ＴＴＩ要素に対するデジタル証明の発行に関して、ＣＡ３１４に対するＲＡ３１２として作用する。ＴＴＩは、好ましくは、ＩＴＵ−Ｔ　Ｘ．５０９ｖ３デジタル証明を使用する。ＴＴＩの中の各要素は、好ましくは、区別された名前を有し、一意的に識別することができる。名前構造は、好ましくは、区別された名前に関する国際電気通信連合−電気通信標準化部門（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ　Ｓｅｃｔｏｒ）（ＩＴＵ−Ｔ）Ｘ．５０１／Ｘ．５２０標準に準拠する。ＲＡ、ＣＡ、およびＯＣＳＰレスポンダの使用は、当技術分野で知られており、この主題に関する情報は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）などのエンティティから入手可能である。
　また、ＮＯＣ２１０は、好ましくは、クライアントの料金請求情報を集めるため、要素マネージャ３０６およびデータベース３０８と相互動作する料金請求システム３１８も含む。いくつかの異なる料金請求スキームを以下の料金請求に関するセクションで説明する。
２．２．４信頼されるローカル時計
　　　　　信頼されるローカル時計（ＴＬＣ）２０６は、好ましくは、信頼される時間トークンの形態で信頼される時刻を要求時にアプリケーション２０８に提供する。ＴＬＣ２０６は、顧客が所有するサーバの中でホストされ、好ましくは、不正変更に耐性があり、安全でない環境の中で安全でないホストにおいて動作するものと想定されるＰＣＩｖ２．１準拠のカードである。
　　　　　ＴＬＣ２０６は、発振器、および信頼される時刻を生成する計時エンジンを含む。時刻較正認定（ＴＣＣｅｒｔ）は、通常、有効である期間を有する。有効期間中にＴＣＣｅｒｔによって規定された精度の範囲が、ＴＬＣの発振器および計時エンジンの正確さを請け合う。したがって、ＴＣＣｅｒｔは、有効期間中、認定された時計の正確さの保証として作用する。
　　　　　ＴＬＣ２０６は、好ましくは、リアルタイムのオペレーティングシステムを使用してオンカード機能を制御する。ＴＬＣ２０６は、好ましくは、ＴＭＣ２０４およびＮＯＣ２１０と通信するため、独自のイーサネット（登録商標）ＴＣＰ／ＩＰ接続を有する。
　　　　　ＴＬＣ２０６における暗号計算は、好ましくは、専用ハードウェアＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ　Ｍｅｍｏｒｙ　Ｃａｒｄ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ａｓｓｏｃｉａｔｉｏｎ：パーソナルコンピュータメモリカードに関する国際協会）暗号化エンジンを使用して行われる。この暗号化装置は、好ましくは、高品質の疑似乱数発生器も含む。鍵生成は、ＰＣＭＣＩＡ装置上で行われる。ＴＬＣ２０６に関する秘密鍵は、好ましくは、ＰＣＭＣＩＡ暗号化エンジンから決してエクスポートされない。センシティブな暗号情報は、好ましくは、不正変更警報が行われたときに消去されるバッテリバックアップ付きメモリの中に収められる。ＴＬＣ２０６は、好ましくは、全体的にＦＩＰＳ１４０−１のレベル１の、また物理的セキュリティに関してレベル３のＮＩＳＴ認可レーティングを有する。すべてのオペレータの動作（ログは、オペレータＩＤを含む）、警報、行われた時刻認定、発行された時間トークン、およびすべての遠隔ＮＯＣ２１０通信を含む、すべてのＴＬＣイベントに関して、好ましくは、監査証跡が作成される。これらのログには、デジタル式に署名が行われて（検出によって）後の偽造および改ざんを防止する。
　　　　　ＴＭＣ２０４と同様に、ＴＬＣ２０６は、ＴＬＣ２０６を初期設定し、ＴＬＣ２０６の健全性を監視するＧＰＳ受信器を含むことが可能である。ＴＬＣ時刻ソースにおいて何らかの異常が検出された場合、ＴＬＣ２０６は、オフライン状態になり、問題を分離しようと試み、シャットダウンする。
２．２．５アプリケーション
　　　　　アプリケーション２０８は、ＴＬＣ２０６から信頼される時間トークンを要求する任意のプロセスまたは装置である。アプリケーション２０８は、ＴＬＣ２０６をホストするのと同一のサーバ上で実行されること、またはホストサーバと通信する他の任意のマシン上で実行されることが可能である。アプリケーション２０８は、ＮＯＣ２１０を介してタイムスタンプの確認を要求することができる。別法では、アプリケーション２０８によって獲得されたタイムスタンプが、別のアプリケーションに渡されることが可能である。次に、その別のアプリケーションが、ＮＯＣ２１０を介してタイムスタンプの確認を行うことができる。
　　　　　クライアントアプリケーション２０８は、信頼される時刻アプリケーションプログラムインターフェース（ＴＴＡＰＩ）を使用してＴＬＣ２０６にアクセスする。ＴＴＡＰＩは、トランスポートレイヤセキュリティ／セキュアソケットレイヤ（ＴＬＳ／ＳＳＬ）プロトコルを使用して自らの関連ＴＬＣ２０６と通信する。ＴＬＣ２０６と同じ場所に配置されたサーバアプリケーションが、信頼されるローカル時計アプリケーションプログラムインターフェースを使用してＴＬＣ２０６にアクセスする。
２．３　　ＴＴＩシステム
　　　　　図４は、時計およびアプリケーションのネットワークを含むＴＴＩシステム４００の一実施形態を示している。システム４００は、好ましくは、離れた場所に配置された２つのＮＴＴＳ２０２Ａ、Ｂを冗長性のために含む。２つのＴＭＣ２０４Ａ、Ｂが、ＮＴＴＳによって直接に認定される。ＴＭＣ２０４Ａが、ＴＬＣ２０６Ａを直接に認定し、一方、ＴＭＣ２０４Ｂが、ＴＬＣ２０６Ｄを直接に認定する。また、ＴＭＣ２０４Ａは、別のＴＭＣ２０４Ｃも認定し、ＴＭＣ２０４Ｃは、ＴＬＣ２０６Ｂを認定し、同様に、ＴＭＣ２０４Ｂが、ＴＭＣ２０４Ｄを認定し、ＴＭＣ２０４Ｄが、ＴＬＣ２０６Ｃを認定する。示すとおり、時刻認定ログが、ＴＬＣ２０６から最高レベルのＴＭＣ２０４までに渡され、次に、ＮＯＣ２１０に渡される。
　　　　　どれかの時計に障害が起きた場合、ＴＴＩの中でその時計より下の装置が、代替の時計からのサービスを要求することができる。例えば、ＮＴＴＳ２０２Ａに障害が起きた場合、ＴＭＣ２０４Ａが、ＮＴＴＳ２０２Ｂから認定を要求することができる。同様に、ＴＭＣ２０４Ａに障害が起きた場合、ＴＬＣ２０６ＡおよびＴＭＣ２０４Ｃが、ＴＭＣ２０４Ｂから認定を要求することができる。
　　　　　アプリケーション２０８Ａ、２０８Ｂ、および２０８Ｃが、それぞれのＴＬＣから信頼される時間トークンを要求する。信頼される時間トークンを受け取ると、アプリケーションは、確認要求をＮＯＣ２１０に向けて送ることができる。
２．４　　アプリケーション限定時刻サービス
　　　　　ＴＴＩシステム、またはＴＴＩシステムの一部分の別の実施形態は、アプリケーション限定時刻サービスとして構成することができる。アプリケーション限定時刻サービスでは、信頼される時刻が、単一の第三者によって提供される特定のアプリケーションに提供される。例えば、企業Ｘが、それぞれがＴＬＣを備えている認定された電子メールゲートウェイサーバを販売することを望む場合、ＴＬＣは、企業Ｘによって操作されるＴＭＣによって同期される。企業ＸのＴＭＣは、信頼される第三者のＴＭＣによって認定される。特定のアプリケーションに応じて、アプリケーション限定時刻サービスは、別のＮＯＣを必要とする可能性がある。
３．　　　較正および認定
　　　　　このセクションは、ＴＴＩの中でどのように時計の較正および認定が行われるかを説明する。ＴＴＩの個々の計時要素が、時刻較正認定（ＴＣＣｅｒｔ）を所有するとき、動作がイネーブルにされる。好ましい実施形態では、ＴＬＣは、有効なＴＣＣｅｒｔの発行を受けていない限り、信頼される時間トークンを発行することができない。また、好ましい実施形態では、ＴＭＣは、有効なＴＣＣｅｒｔの発行を受けていない限り、下位の時計を認定することができない。
　　　　　下位の時計の較正を測定した後、上位の時計は、下位の時計にＴＣＣｅｒｔを発行して、下位の時計の時刻が上位の時計との関係である許容範囲内にあると認定する。上位の時計は、ＴＣＣｅｒｔに署名して真正性を保証する。
３．１　　手続きの概要
　　　　　図５は、ＴＴＩシステムの好ましい実施形態が信頼される時間トークンを生成するプロセスの概要を示している。図５に示されるステップは、図３の要素間の矢印によっても描かれている。
　　　　　第１のステップ５０２で、ＮＴＴＳ２０２が、ＴＭＣ２０４を認定し、ＴＣＣｅｒｔをＴＭＣ２０４に送信し、認定をローカルに記録する。次に、ＴＭＣ２０４は、ステップ５０４でログ記録するためにＴＣＣｅｒｔをＮＯＣ２１０に送信する。この時点で、ＴＭＣ２０４は、有効なＴＣＣｅｒｔを所有し、他の下位の時計を時刻認定することができる。ステップ５０６で、ＴＭＣ２０４が、ＴＬＣ２０６を時刻認定し、ＴＣＣｅｒｔをＴＬＣ２０６に送信し、認定を記録する。また、ＴＭＣ２０４は、最後の認定以来、ＴＬＣ２０６が発行した信頼される時間トークンの数をＴＬＣ２０６から取得する。この数は、好ましくは、料金請求の目的で使用される。ステップ５０８で、ＴＭＣ２０４が、ＴＬＣ２０６のＴＣＣｅｒｔおよびトークンカウントをログ記録のためにＮＯＣ２１０に送信する。
　　　　　ＴＬＣ２０６が認定されると、ＴＬＣ２０６は、自らの新しいＴＣＣｅｒｔの下で信頼される時間トークンを発行する準備ができる。ステップ５１２で、アプリケーションが、要求を行い、ＴＬＣ２０６が、新しい信頼される時間トークンを発行する。ステップ５１４で、アプリケーションが、おそらく、後日、ＮＯＣを介して時間トークンの真正性を確認する。
３．２　　ＴＣＣＥＲＴ生成
　　　　　図６は、図５のステップ５０２および５０６におけると同様に、上位の時計が、下位の時計の時刻を認定するプロセスの好ましい実施形態を示している。この例示のコンテキストでは、上位の時計は、ＮＴＴＳまたはＴＭＣを表し、一方、下位の時計は、別のＴＭＣ、つまり、上位の時計より、ＮＴＴＳからの信頼される時刻の連鎖をさらに下るＴＬＣを表すものとされる。より高いレベルの時計が、下位の時計のずれを測定し、ずれが規定の範囲内にあると分かったとき、ＴＣＣｅｒｔが作成されて、この判定が記録される。ステップ６０２で、下位の時計が、好ましくは、以下を含むＴＣＣｅｒｔ要求（ＴＣＣｅｒｔＲｅｑ）を作成する。
　　　　　上位の時計のＩＤ、
　　　　　下位の時計のＩＤ、
　　　　　下位の時計の精度、
　　　　　下位の時計の署名パラメータ、および
　　　　　下位の時計の署名（以上のフィールドにわたる）
　　　　　次に下位の時計が、ＴＣＣｅｒｔＲｅｑを上位の時計に送信する。ステップ６０４で、上位の時計が、下位の時計からＴＣＣｅｒｔＲｅｑを受信する。上位の時計は、ステップ６０６で、下位の時計の署名を検証して下位の時計のＩＤが正しいことを確認する。ステップ６０８で、上位の時計が、セキュアＮＴＰ（ＳＮＴＰ）を使用して下位の時計の時刻のずれを測定する。
　　　　　上位の時計は、ステップ６１０で、下位の時計のずれが許容可能な限度内にあるかどうかを判定する。下位の時計が許容可能な限度内にある場合、制御は、ステップ６１４に進む。ステップ６１４で、上位の時計が、下位の時計のずれを較正または調整し、必要な場合、再び測定する。ステップ６１６で、上位の時計が、好ましくは、以下のフィールドをＴＣＣｅｒｔＲｅｑに付加することによってＴＣＣｅｒｔを作成する。
　　　　　ＴＣＣｅｒｔ時刻、
　　　　　サービスクラスＩＤ、
　　　　　下位の時計のずれ、
　　　　　ＴＣＣｅｒｔ精度、
　　　　　ＴＣＣｅｒｔ失効時刻、
　　　　　遅延、
　　　　　上位の時計のＴＣＣｅｒｔ（オプション）、および
　　　　　上位の時計の署名パラメータ。
　　　　　最終ＴＣＣｅｒｔを作成するため、上位の時計は、ＴＣＣｅｒｔＲｅｑおよび以上の付加されるフィールドの全体にわたって自らのデジタル署名を付加する。オプションとして、下位の時計のＴＣＣｅｒｔの中に上位の時計のＴＣＣｅｒｔを含めることにより、ＮＴＴＳから最低レベルまでの信頼される時刻の完全なトレースを各ＴＣＣｅｒｔの中にカプセル化することができる。ステップ６１８で、上位の時計が、ＴＣＣｅｒｔを記憶し、記録して、そのＴＣＣｅｒｔを下位の時計に送信する。
　　　　　ステップ６１０で、下位の時計の時刻が、許容可能な限度を超えていると判明した場合、その時計に障害があること、または不正変更が行われていることが可能である。この場合、制御はステップ６１２に進む。ステップ６１２で、フィールド、ＴＣＣｅｒｔ時刻が不正な値に設定され、フィールド、サービスクラスＩＤが「較正外」に設定される。下位の時計が較正外であると判明した場合、最後のＴＣＣｅｒｔ以来、その下位の時計によって発行されたどのＴＣＣｅｒｔも、またはどの信頼される時間トークンも、疑わしいと見なさなければならない。したがって、ＮＯＣ２１０に較正外測定の通知が行われ、ＮＯＣ２１０のデータベースが、前のＴＣＣｅｒｔ、および前のＴＣＣｅｒｔから導出されたあらゆる信頼される時間トークンの無効性を反映できるようにしなければならない。ＮＯＣ２１０に較正外測定の通知が行われた場合、制御は、オプションとして、下位の時計の再較正および再認定のため、ステップ６１４に戻る。
３．２．　１ＮＴＴＳ−ＴＭＣ間較正
　　　　　ＮＴＴＳが、好ましくは、日に一回、ＰＳＴＮ接続およびＳＮＴＰプロトコルを使用してＴＭＣの時計のずれを測定する。ＴＭＣの時計のずれは、ＮＴＴＳによって提供されるようにＵＴＣの１０ミリ秒の範囲内にあるものと予期される。時計のずれの測定が成功する場合、ＮＴＴＳは、ＴＭＣが下位の時計の時刻較正に関してイネーブルにされることを示すＴＣＣｅｒｔを戻す。ＮＴＴＳのＴＣＣｅｒｔの失効日は、好ましくは、ＴＣＣｅｒｔ発行の日付から七（７）日間である。ＮＴＡの実施態様を簡単にするため、ＮＴＡレベルのＣＡを使用しないことが可能である。したがって、ＮＴＴＳは、ＴＭＣ証明を生成したＣＡに関して、ＳＮＴＰを介して自らが受信するＴＭＣ証明の有効性を明示的に確認しない可能性がある。代りに、ＮＴＴＳは、計時サービスに関する初期設定中に自らの内部データベースにロードされた証明に受信した証明がマッチすることを単に確認する。ＮＴＴＳデータベースの中にない証明がＳＮＴＰを介して受信された場合、ＮＴＴＳは、受信した証明とともにエラーメッセージをログ記録し、接続を拒否する。
　　　　　ＮＴＴＳは、好ましくは、すべての時計のずれの測定情報を用紙にログ記録する。印刷されたレコードは、好ましくは、以下の情報を含む。
　　　　　較正のＵＴＣ時刻、
　　　　　信頼されるマスタ時計の名前、
　　　　　測定されたずれ、
　　　　　ＮＴＴＳ証明の通し番号、および
　　　　　信頼されるマスタ時計証明の通し番号
３．２．２ＴＭＣ−ＴＬＣ間較正
　　　　　各ＴＭＣは、自らが認定することを担う１組のＴＬＣを有する。各ＴＭＣが、ＳＮＴＰを使用して、日に一回、そのセットのＴＬＣのそれぞれにコンタクトしてＴＣＣｅｒｔを要求する。受信したＴＣＣｅｒｔが、２４時間経過していないものである場合、ＴＭＣは、そのユニットの認定をスキップし、ＳＮＴＰセッションを閉じ、自らのリストの次のＴＬＣにクエリを行うことに移る。受信したＴＣＣｅｒｔが、２４時間以上経過している場合、ＴＭＣは、ＴＬＣの時刻のずれを測定し、時刻修正を計算し、この修正をＴＬＣ時計に送信して、ＴＬＣ時計を規定の範囲内に保つ。ずれが再び測定され、ＴＬＣ時計が規定の範囲内にある場合、ＴＭＣは、ＴＬＣがＵＴＣからあるずれの範囲内にあることを明言するＴＣＣｅｒｔをＴＬＣに発行する。ＴＭＣは、ＴＬＣがＵＴＣの１００ミリ秒の範囲内にあると認定することが予期される。
３．３　　信頼される時刻の保証
　　　　　ＴＴＩシステムの好ましい実施形態は、いくつかの態様を組み合わせて、信頼される時間トークンのタイムスタンプが、認められた標準と同期している時刻のソースから導出されていること、つまりＴＴＩシステムが、「信頼される時刻」を提供することを保証する。第１の態様は、ＴＴＩシステムを構成する物理的装置が、物理的に安全で信頼される施設の中に配置される、または物理的に不正変更に耐性があるように設計されることである。第２の態様は、ＴＴＩシステムの要素間の通信が認証され、また、必要な場合、ＰＫＩシステムを使用して暗号化されることである。第３の態様は、ＴＬＣによって維持される時刻を信頼される時計の連鎖のＳＮＴＰ較正を使用する認定を介して、ＮＴＴＳまで、または別の共通に認められた時刻ソースまでリンクするのが可能なことである。第４の態様は、認定される各時計が、有効なＴＣＣｅｒｔの継続期間にわたって少なくともある精度を維持するように規定されることである。したがって、各ＴＣＣｅｒｔは、認定された時計の時刻が、そのＴＣＣｅｒｔの有効期間中、規定の精度に、前述の認定を行う時計の精度に起因する変動により、それぞれのＴＣＣｅｒｔの有効期間中、導入される可能性がある時間変動を足した範囲内にあるのを保証することができる。
４．　　　信頼される時間トークンの生成および確認
　　　　　ＴＬＣ２０６は、有効なＴＣＣｅｒｔを有すると、有効な信頼される時間トークンを発行することができる。トークンは、好ましくは、タイムスタンプが押されるデータと、時刻の信頼されるソースによって、この場合、ＴＬＣ２０６の内部時計によって供給されるタイムスタンプの連結を含む。ＴＬＣ２０６による完全なメッセージの署名が、検出されることなしにタイムスタンプを変更できないようにデータをタイムスタンプに結合する作用をする。
　　　　　トークンは、生成されると、要求側アプリケーションに戻される。次に、要求側アプリケーションは、トークンの真正性を確認することができる。さらには、または別法では、アプリケーションは、将来、再び確認するのを選択することができる別のアプリケーションにトークンを渡すことができる。
　　　　　アプリケーションは、（１）発行を行ったＴＬＣ２０６がトークン発行時に有効なＴＣＣｅｒｔを所有していたことをＮＯＣ２１０で調べること、および（２）好ましくは、ＮＯＣ２１０から、ＴＬＣ２０６の対応する公開鍵を含むデジタル証明を獲得することによってトークンの署名を確認することによってトークンの真正性を確認することができる。
４．１　　トークン生成
　　　　　図７は、信頼される時間トークンがＴＬＣ２０６によって生成されるプロセスの好ましい実施形態を示している。第１のステップ７０２で、アプリケーション２０８が、タイムスタンプを押されるデータを含む要求を、発行を行うＴＬＣ２０６に送信する。データは、ほとんどの場合、タイムスタンプを押される電子文書の一方向ハッシュ関数によって作成されたダイジェストを含む。ステップ７０４で、ＴＬＣ２０６がデータを受信し、そのデータをＴＣＣｅｒｔログポインタ（通常、上位の時計のＩＤ、下位の時計のＩＤ、およびＴＣＣｅｒｔの時刻）とともに現在時刻に連結する。次に、ＴＬＣ２０６は、連結に署名をして信頼される時間トークンを形成する。代替の実施形態では、ＴＣＣｅｒｔログポインタではなく、ＴＣＣｅｒｔ自体が含められる。ステップ７０６で、ＴＬＣ２０６が、信頼される時間トークンをアプリケーション２０８に戻す。その後、ＴＬＣ２０６が、料金請求の目的で、発行したトークンの数の自らの内部ログを増分する。この数は、後に、処理および料金請求のためにＮＯＣ２０１に直接に、またはＴＭＣ２０４を介して送信される。
４．２　　トークン確認
　　　　　図８は、アプリケーションが信頼される時間トークンの真正性を確認することができるプロセスの好ましい実施形態を示している。第１のステップ８０２で、アプリケーションが、ＮＯＣ２１０に接続し、ＮＯＣ２１０の身元を認証する。次に、アプリケーションは、ステップ８０４で、確認されるべきトークンを含む確認要求をＮＯＣ２１０に送信する。ＮＯＣ２１０は、ＴＴＩシステムのすべての時計のすべてのＴＣＣｅｒｔのデータベースを維持する。さらに、ＮＯＣ２１０は、すべてのＴＴＩ要素に関するＣＡを含むか、またはそのＣＡにアクセスを有する。ＣＡは、ＴＴＩ要素の署名を確認することができるデジタル証明のソースである。
　　　　　ステップ８０４から、本プロセスの好ましい実施形態は、ステップ８０６に進む。ステップ８０６で、ＮＯＣ２１０が、自らのデータベースのＴＣＣｅｒｔ、および発行を行ったＴＬＣ２０６に関連するデジタル証明を使用して、サブミットされたトークンの真正性を判定する。次のステップ８０８で、ＮＯＣ２１０は、サブミットされたトークンのステータスを示す署名された確認通知を要求側アプリケーションに供給する。
　　　　　代替の実施形態では、プロセスは、ステップ８０４からステップ８１０に進む。ステップ８１０で、ＮＯＣ２１０が、発行を行ったＴＬＣ２０６が有効なＴＣＣｅｒｔを所有していたかどうかを判定する。所有していた場合、ＮＯＣ２１０は、ステップ８１２で、発行を行ったＴＬＣ２０６のデジタル証明を要求側アプリケーションに供給する。ステップ８１４で、アプリケーションが、トークンの署名を確認するデジタル証明を使用してトークンの真正性を確認する。ステップ８１０で、ＮＯＣが、自らのデータベースを調べることにより、発行を行ったＴＬＣ２０６が有効なＴＣＣｅｒｔを所有していなかった、またはＴＣＣｅｒｔが疑わしいと判定した場合、プロセスは、ステップ８１６に進む。ステップ８１６で、ＮＯＣ２１０は、トークンを認証できないことの通知を要求側アプリケーションに送信する。
５．　　　セキュリティスキーム
　　　　　いくつかの異なるスキームを開示するＴＴＩと併せて使用して、信頼される時間トークンに含まれるタイムスタンプが、実際に信頼される時刻のソースから導出されたものであることを保証することができる。スキームは、様々な利点および欠点を有し、より高いセキュリティをより高い確認、より高い処理、より高い記憶コストと均衡させる。これらのスキームの目的は、信頼される時間トークンが、有効なＴＣＣｅｒｔを有するＴＬＣによって発行されていることを保証することである。
５．１　　基本スキームＡ
　　　　　第１のセキュリティスキームは、発行されたタイムスタンプの有効性を保証するため、ＴＬＣが、トークン発行に先行する所定期間内にＴＣＣｅｒｔの発行を受けていることを利用する。ＴＣＣｅｒｔには、認定されたＴＬＣがタイムスタンプを発行できる、例えば、７日間といった有効継続期間が与えられる。ＴＣＣｅｒｔが失効した場合、またはＴＬＣが新しいＴＣＣｅｒｔの発行を受けた場合、古いＴＣＣｅｒｔは、ＴＬＣによって破壊される。トークンの有効性を確認するため、アプリケーションまたはＮＯＣ２１０は、タイムスタンプの時刻が、信頼される時間トークンに含まれる、または参照されるＴＣＣｅｒｔの有効期間に対応することを確認する。ＮＯＣ２１０は、ＴＣＣｅｒｔ自体が有効であることを、ＮＴＴＳ２０２に至る上位の時計の追加ＴＣＣｅｒｔを介して信頼される時間のソースをトレースして、調べなければ成らない。
５．２　　基本スキームＢ
　　　　　前述のスキームの変形は、ＴＬＣが、信頼される時間トークンを発行した後のある期間内に有効なＴＣＣｅｒｔの発行を受けていることを利用する。この場合、ＴＣＣｅｒｔは、発行される前の、７日間といった固定継続期間中、有効であると見なされる。このケースでは、ＴＬＣは、ＮＴＴＳ時刻の許容可能な限度内に時刻を保った場合、認定に先立つ妥当な期間にわたってこの時刻を維持したと考えられる。そのようなシステムを実施するため、ＴＬＣは、各信頼される時間トークンの中に、まだ発行されていないＴＣＣｅｒｔに対するリファレンスを含めなければならない。次に、ＴＣＣｅｒｔが発行された際、ＮＯＣ２１０が、そのリファレンスを後に発行されるＴＣＣｅｒｔに、関連付けることが可能である。このスキームの下における信頼される時間トークンの確認は、前述のスキームと同様な仕方で実行することが可能である。
５．３　　高信頼度スキーム
　　　　　高信頼度スキームは、前述した基本スキームＡおよびＢの態様を組み合わせる。このスキームでは、ＴＣＣｅｒｔが信頼される時間トークンの発行前後の所定期間内に発行を行うＴＬＣに発行されていることをＮＯＣが確認する。この場合、信頼される時間トークンは、トークン発行の前にＴＬＣに発行されるＴＣＣｅｒｔに対するリファレンスを含むだけでよい。次に、ＮＯＣが、トークン発行後の要件時間内に後のＴＣＣｅｒｔが発行されたかどうかを判定することができる。
５．４　　代替のスキーム
　　　　　代替のスキームは、スキームＡと同様の信頼保証、詳細には、ＴＬＣが、信頼される時間トークンの発行に先立つ所定期間内にＴＣＣｅｒｔの発行を受けていることの信頼保証を提供する。ただし、このスキームは、ＴＴＩシステムのすべてのＴＬＣのすべての個々のＴＣＣｅｒｔをアーカイブする必要性をなくす。代りに、各ＴＣＣｅｒｔが、発行を行った時計の完全なＴＣＣｅｒｔを含む。このようにして、各ＴＣＣｅｒｔが、ＮＴＴＳから発行を行うＴＬＣにまで至る認定の完全な認証可能な連鎖を含む。すべての個々の時計のＴＣＣｅｒｔをカタログに入れる代りに、各信頼される時間トークンが、そのトークンが導出された信頼される時刻をＮＴＴＳにリンクするＴＣＣｅｒｔの完全な連鎖を含む。次に、おそらくは、オンライン証明ステータスプロトコル（ＯＣＳＰ）レスポンダ３１６を使用して、認定を行う時計または発行を行う時計のそれぞれの公開鍵を、ＮＯＣ２１０のＣＡ３１４を介して提供し、個々のアプリケーションが、信頼される時間トークンの有効性、および信頼される時間トークンの作成に至る信頼される時刻の連鎖を独立に確認できるようにする。
６．　　　ビジネスモデル
　　　　　料金請求スキームは、進行中のビジネス関心事の一環としてＴＴＩの動作を円滑にするため、開示する発明に統合することも可能である。様々な便益を提供するいくつかの異なる料金請求スキームをＴＴＩシステムと併せて使用することが可能である。
６．１　　スタンプごとの料金請求
　　　　　開示するシステムは、発行したタイムスタンプの数をＴＬＣがＮＯＣに送信するための機構を提供する。ＮＯＣは、この情報のログ記録をとり、個々のクライアントに関する料金請求報告書を自動的に作成するように構成することが可能である。この場合、クライアントには、発行された各タイムスタンプごとに料金請求を行うことが可能である。
６．２　　均一料金の認定
　　　　　代替のスキームは、クライアントの敷地に配置された各ＴＬＣの時刻認定に関してクライアントに料金請求することに基づく。この場合、クライアントは、各発行されたＴＣＣｅｒｔごとに代金を支払い、有効なＴＣＣｅｒｔ期間中に発行されたすべてのタイムスタンプに関して均一料金を享受する。この場合、ＮＯＣが、料金請求手続きを調整し、自動化する。
６．３　　確認に対する課金
　　　　　１つのビジネスモデルでは、発行されたタイムスタンプに関する確認サービスが、タイムスタンプの有効性を確認するのを望むどのエンティティにも無料で提供される。別法では、確認サービスは、ＮＯＣを介する料金で提供されることが可能である。」
　
　　以上の引用例３の記載及び図面によれば、引用例３には以下の事項が開示されていると認められる。
　
（ｅ）協定世界時と協調するマスタ時計を有するＴＭＣが、タイムスタンプを押すＴＬＣのローカル時計の時刻較正を行い、ＴＭＣが時刻較正認定（ＴＴＣｅｒｔ）を発行して、ＴＬＣのローカル時計の時刻較正を行ったことを証明していること。
　
（ｆ）タイムスタンプを押すＴＬＣがデータの登録時刻を証明する時間トークンを作成する際に、データ、現在時刻、及び時刻較正認定（ＴＴＣｅｒｔ）を連結し、連結に署名して信頼される時間トークンを形成すること。
　
（ｇ）アプリケーションが時間トークンを含む確認要求をネットワークオペレーションセンタＮＯＣに送信すると、ネットワークオペレーションセンタＮＯＣが時間トークンに含まれた時刻較正認定（ＴＴＣｅｒｔ）を用いて、時間トークンを発行したＴＬＣのローカル時計が時刻較正を受けていることを検査し、時間トークンを発行したＴＬＣのデジタル証明をアプリケーション側に供給することにより、アプリケーションが、時間トークンの署名を確認するデジタル証明を使用して時間トークンの真正性を確認できること。
　
（３）対比
　そこで、本願補正発明と引用例１発明とを対比する。
　
（Ａ）引用例１発明の「公証システムＣＹＮＯＳサーバ群」は、データの公証を行うサーバ群であり、本願補正発明の「電子公証センター」は、アプリケーションサーバとタイムスタンプサーバを含んだデータの公証を行うサーバ群であるから、データの公証を行うサーバ群であるという点で共通している。
　引用例１発明の「外部時間サーバ」は、基準となる時間のソースとなっており、本願補正発明の「時刻校正センター」も電子公証センターの時刻手段の時刻を校正しているから基準となる時刻を電子公証センターに与えているといえ、両者は、基準となる時刻を与えるサーバである点で共通している。
　よって、引用例１発明の「公証プラットフォーム」と本願補正発明の「電子公証システム」とは、公証を行うサーバ群と基準となる時刻を与えるサーバを含むデータ公証システムである点で共通しているといえる。
　
（Ｂ）引用例１発明の「送信者」、「証拠データ」、「証拠データに係る事実証明書（電子証書）」は、本願補正発明の「ユーザ」、「電子データ」、「電子データに係る電子証明書」にそれぞれ相当するから、引用例１発明の公証システムＣＹＮＯＳサーバ群のＷｅｂサーバと、本願補正発明の電子公証センターのアプリケーションサーバとは、ユーザの電子データを取得し、電子データに係る電子証明書を作成する手段に渡し、電子証明書を作成する手段から受け取った電子データに係る電子証明書をユーザに送信する手段を備えたサーバである点で共通しているといえる。
　ただし、本願補正発明の電子公証センターのアプリケーションサーバは、電子データを一方向関数値に変換しているのに対して、引用例１発明の公証システムＣＹＮＯＳサーバ群のＷｅｂサーバでは、電子データを一方向関数値に変換していない点で相違している。
　
（Ｃ）引用例１発明の「証拠データ」、「証拠データに係る事実証明書（電子証書）」「公証システム識別情報」、「公証システム電子署名」は、本願補正発明の「電子データ」、「電子データに係る電子証明書」、「タイムスタンプサーバの固有のＩＤとを含むタイムスタンプ情報」、「タイムスタンプ情報の電子署名」にそれぞれ相当している。
　また、引用例１発明の「原本登録時刻」と、本願補正発明の「時刻情報」とは、データの登録時刻の情報という点で共通している。
　さらに、引用例１発明の「公証システム識別情報」及び「公証システム電子署名」と、本願補正発明の「タイムスタンプサーバの固有のＩＤとを含むタイムスタンプ情報」及び「タイムスタンプ情報の電子署名」とは、それぞれ、公証サーバのＩＤ及び公証サーバの電子署名である点で共通している。
　したがって、引用例１発明の「事実証明書（電子証書）作成手段」と、本願補正発明の「タイムスタンプサーバ」とは、電子データを受け取り、電子データの登録時刻の情報や、公証サーバのＩＤ、公証サーバの電子署名などを含んだ電子証明書を作成し、電子証明書を出力する手段である点で共通している。
　ただし、本願補正発明のタイムスタンプサーバでは、時刻校正センターから取得する時刻校正証明書により、前記時刻校正センターによって時刻校正がなされていることが証明されている時刻手段を備えているのに対して、引用例１発明では、時刻校正センターから取得する時刻校正証明書により、前記時刻校正センターによって時刻校正がなされていることが証明されている時刻手段を備えているのか否か明らかでない点、また、本願補正発明のタイムスタンプサーバでは、電子データの一方向関数値を取得して、電子データの一方向関数値を含んだ電子証明書を作成しているのに対して、引用例１発明では、電子データ自身を受け取り、電子データ自身を含んだ電子証明書を作成している点、さらに、本願補正発明のタイムスタンプサーバでは、電子証明書を作成する際に、タイムスタンプ用公開鍵証明書と、時刻校正証明書とを含んでいるのに対して、引用例１発明では、公証サーバの公開鍵証明書と、時刻校正証明書とを含んでいない点で相違している。
　
（Ｄ）引用例１発明の「外部時間サーバ」と、本願補正発明の「時刻校正センター」とは、公証を行うサーバ群から独立して管理されており、基準となる時刻を与えているサーバである点で共通している。
　ただし、本願補正発明の時刻校正センターは、協定世界時と協調する時計の時刻に基づいて前記電子公証センターの前記タイムスタンプサーバの前記時刻手段の時刻を校正し、時刻校正を行った時に時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段と、前記電子公証センターの前記タイムスタンプサーバから、前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を取得して蓄積する手段と、前記電子公証センターの前記アプリケーションサーバの前記受付手段がユーザに送信した電子証明書を取得する手段と、取得した前記電子証明書と、蓄積している前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を使用して、前記タイムスタンプサーバの前記時刻手段が時刻校正を受けており、前記タイムスタンプサーバが正規のタイムスタンプサーバであること検証する手段とを有しているのに対して、引用例１発明の外部時間サーバは、対応する手段を有しているのか否か不明である点で相違している。
　
　したがって、両者は、
「公証を行うサーバ群と基準となる時刻を与えるサーバを含むデータ公証システムであって、
　公証を行うサーバ群は、
　電子証明書を作成する手段から受け取った電子データに係る電子証明書をユーザに送信する手段を備えたサーバと、
　電子データを受け取り、電子データの登録時刻の情報を含んだ電子証明書を作成し、電子証明書を出力する手段とを有し、
　基準となる時刻を与えるサーバは、公証を行うサーバ群から独立して管理されている
データ公証システム。」
の点で一致し、以下の点で相違している。
　
（相違点１）本願補正発明では、電子データを一方向関数値に変換し、電子データの一方向関数値を含んだ電子証明書を作成しているのに対して、引用例１発明では、電子データを一方向関数値に変換しておらず、電子データ自身を含んだ電子証明書を作成している点。
　
（相違点２）本願補正発明の時刻校正センターは、協定世界時と協調する時計の時刻に基づいて前記電子公証センターの前記タイムスタンプサーバの前記時刻手段の時刻を校正し、時刻校正を行った時に時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段を備えており、タイムスタンプサーバは、時刻校正センターから取得する時刻校正証明書により、時刻校正センターによって時刻校正がなされていることが証明されている時刻手段を備えているのに対して、引用例１発明では、時刻校正手段や時刻手段を備えているのか否か明らかでない点。
　
（相違点３）本願補正発明では、電子証明書を作成する際に、タイムスタンプ用公開鍵証明書と、時刻校正証明書とを含んでいるのに対して、引用例１発明では、公証サーバの公開鍵証明書と、時刻校正証明書とを含んでいない点。
　
（相違点４）本願補正発明の時刻校正センターは、前記電子公証センターの前記タイムスタンプサーバから、前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を取得して蓄積する手段と、前記電子公証センターの前記アプリケーションサーバの前記受付手段がユーザに送信した電子証明書を取得する手段と、取得した前記電子証明書と、蓄積している前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を使用して、前記タイムスタンプサーバの前記時刻手段が時刻校正を受けており、前記タイムスタンプサーバが正規のタイムスタンプサーバであること検証する手段とを有しているのに対して、引用例１発明の外部時間サーバは、対応する手段を有しているのか否か不明である点。
　
（４）判断
　
（相違点１について）
　引用例１の上記（ア）にも「多くの事実否認防止サービスはデータのハッシュ値をサービスの対象としておりデータ自身を証明の対象としていない．」と記載されているように、電子公証システムの技術分野において、電子データの事実防止否認を行う際に、電子データのハッシュ値を対象として電子証明書を作成することは、本願出願前に周知の技術に過ぎない。ここで、電子データのハッシュ値は、一方向関数値に変換したものに他ならない。
　よって、引用例１発明において、受け取った電子データを電子証明書作成手段にそのまま渡し、電子証明書作成手段において、電子データ自身を含んだ電子証明書を作成する構成に代えて、当該周知技術を採用して、受け取った電子データを一方向関数値に変換し、電子データの一方向関数値を含んだ電子証明書を作成する構成を採用することは、当業者が容易に想到し得たものである。
　
（相違点２について）
　電子公証システムの技術分野に属する引用例２には、タイムスタンプを付加するサービスサイトが常時ＵＴＣ（世界協定時）と同期をとっていることが記載されている。
　また、電子データの登録時刻証明システムの技術分野に属する引用例３には、協定世界時と協調するマスタ時計を有するＴＭＣが、タイムスタンプを押すＴＬＣのローカル時計の時刻較正を行い、ＴＭＣが時刻較正認定（ＴＴＣｅｒｔ）を発行して、ＴＬＣのローカル時計の時刻較正を行ったことを証明していることが記載されている。ここで、引用例３の「ＴＭＣ」が本願補正発明の「時刻校正センター」に相当し、引用例３の「ＴＬＣのローカル時計」が本願補正発明の「時刻手段」に相当し、引用例３の「時刻較正」、「時刻較正認定（ＴＴＣｅｒｔ）」が、本願補正発明の「時刻校正」、「時刻校正証明書」にそれぞれ相当する。
　よって、引用例１発明において、外部時間サーバを時刻のソースとする構成に代えて、当該引用例２及び３記載の技術を採用して、時刻校正センターが、協定世界時と協調する時計の時刻に基づいて、電子データの登録時刻を求める（タイムスタンプを押す）ための時刻手段の時刻を校正し、時刻校正を行った時に時刻校正を行ったことを証明する時刻校正証明書を作成して、送出する時刻校正手段を備え、登録時刻を求める手段が、取得する時刻校正証明書により、時刻校正がなされていることが証明されている時刻手段を備える構成を採用することは、当業者が容易に想到し得たものである。
　
（相違点３について）
　電子公証システムの技術分野に属する引用例２には、さらに、タイムスタンプを付加するサービスサイトがデータの存在を証明するデジタル・レシートを発行する際に、認証局の証明書でデジタル署名してあることが記載されている。ここで、引用例２の「デジタル・レシート」は、本願補正発明の「電子証明書」に対応し、引用例２において「認証局の証明書でデジタル署名」することは、本願補正発明でいうところの電子証明書にタイムスタンプ用公開鍵証明書を含んでいることに他ならない。
　電子データの登録時刻証明システムの技術分野に属する引用例３には、さらに、タイムスタンプを押すＴＬＣがデータの登録時刻を証明する時間トークンを作成する際に、データ、現在時刻、及び時刻較正認定（ＴＴＣｅｒｔ）を連結し、連結に署名して信頼される時間トークンを形成することが記載されている。ここで、引用例３の「信頼される時間トークン」は、本願補正発明の「電子証明書」に対応する。
　よって、引用例１発明において、引用例２及び３記載の技術を採用して、電子証明書を作成する際に、タイムスタンプ用公開鍵証明書と、時刻校正証明書とを含む構成を採用することは、当業者が容易に想到し得たものである。
　
（相違点４について）
　電子データの登録時刻証明システムの技術分野に属する引用例３には、さらに、アプリケーションが時間トークンを含む確認要求をネットワークオペレーションセンタＮＯＣに送信すると、ネットワークオペレーションセンタＮＯＣが時間トークンに含まれた時刻較正認定（ＴＴＣｅｒｔ）を用いて、時間トークンを発行したＴＬＣのローカル時計が時刻較正を受けていることを検査し、時間トークンを発行したＴＬＣのデジタル証明をアプリケーション側に供給することにより、アプリケーションが、時間トークンの署名を確認するデジタル証明を使用して時間トークンの真正性を確認できることが記載されている。ここで、引用例３の「時間トークン」、「アプリケーション」は、本願補正発明の「電子証明書」、「ユーザ」に、それぞれ対応し、引用例３の「ＴＭＣ」が本願補正発明の「時刻校正センター」に相当する。
　また、電子認証の技術分野において、データの取り扱い主体の真正性を確認するために、データの取り扱い主体のＩＤとデータの取り扱い主体の公開鍵証明を用いて、データ取り扱い主体の真正性を確認する技術は、本願出願前に周知の技術に過ぎず、データの取り扱い主体の真正性をどこで確認するかは、当業者が必要に応じて適宜選択すべき設計的事項に過ぎないから、データの取り扱い主体であるスタンプサーバの真正性確認をユーザ側で行う構成に代えて、時刻校正センター側で行わせる構成を採用することについても、当業者が容易に想到し得たものである。
　よって、引用例１発明において、引用例３記載の技術及び周知技術を採用して、時刻校正センターが、電子公証センターのタイムスタンプサーバから、タイムスタンプサーバの固有ＩＤとタイムスタンプサーバのタイムスタンプ用公開鍵証明書を取得して蓄積する手段と、電子公証センターのアプリケーションサーバの前記受付手段がユーザに送信した電子証明書を取得する手段と、取得した電子証明書と、蓄積しているタイムスタンプサーバの固有ＩＤとタイムスタンプサーバのタイムスタンプ用公開鍵証明書を使用して、タイムスタンプサーバの時刻手段が時刻校正を受けており、タイムスタンプサーバが正規のタイムスタンプサーバであること検証する手段を備える構成とすることは、当業者が容易に想到し得たものである。
　
　また、本願補正発明の効果についてみても、上記構成の採用に伴って、当然に予測される程度のものに過ぎず、格別顕著なものがあるとは認められない。
　
　したがって、本願補正発明は、引用例１ないし３に記載された発明及び周知の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１７年１２月１９日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１７年７月１３日付の手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「電子公証センターと時刻校正センターを含む電子公証システムであって、
　前記電子公証センターは、アプリケーションサーバとタイムスタンプサーバとを有し、
　前記アプリケーションサーバは、
　ユーザの電子データを取得し、前記電子データに係る電子証明書を前記タイムスタンプサーバから取得して前記ユーザに送信する受付手段と、
　前記受付手段で取得した前記電子データを一方向関数値に変換し、前記タイムスタンプサーバに送出する演算手段とを有し、
　前記タイムスタンプサーバは、
　前記時刻校正センターから取得する時刻校正証明書により、前記時刻校正センターによって時刻校正がなされていることが証明されている時刻手段と、
　前記アプリケーションサーバから取得する前記電子データの一方向関数値と、前記時刻手段が出力する時刻情報と、前記タイムスタンプサーバの固有のＩＤとを含むタイムスタンプ情報と、該タイムスタンプ情報の電子署名と、タイムスタンプ用公開鍵証明書と、前記時刻校正証明書とを含む電子証明書を作成し、前記アプリケーションサーバに送出する電子証明書作成手段とを有し、
　前記時刻校正センターは、
　協定世界時と協調する時計の時刻に基づいて前記電子公証センターの前記タイムスタンプサーバの前記時刻手段の時刻を校正し、時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段と、
　前記電子公証センターの前記タイムスタンプサーバから、前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を取得して蓄積する手段と、
　前記電子公証センターの前記アプリケーションサーバの前記受付手段がユーザに送信した電子証明書を取得する手段と、
　取得した前記電子証明書と、蓄積している前記タイムスタンプサーバの固有ＩＤと前記タイムスタンプサーバのタイムスタンプ用公開鍵証明書を使用して、前記タイムスタンプサーバの前記時刻手段が時刻校正を受けており、前記タイムスタンプサーバが正規のタイムスタンプサーバであること検証する手段とを有する、
電子公証システム。」
　
　（１）引用例
　原査定の拒絶の理由に引用された引用例１ないし３並びにそれらの記載事項は、前記「２．（２）」に記載したとおりである。　
　
　（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、請求項１の発明特定事項である「時刻校正センター」について、「電子公証センターからは独立して管理されたセンターであり」との限定を削除し、同じく請求項１の発明特定事項である「時刻校正を行った時に時刻校正を行ったことを証明する時刻校正証明書を作成して前記タイムスタンプサーバに送出する時刻校正手段」について、「時刻校正を行った時に」（時刻校正証明書を作成する）との限定を削除したものである。
　そうすると、本願発明に限定を付加した本願補正発明が、前記２．（４）に記載したとおり、引用例１ないし３に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願補正発明から限定を取り除いた本願発明も同様の理由により、引用例１ないし３に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。　
　
　（３）むすび
　以上のとおりであるから、本願発明は、引用例１ないし３に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について特に検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。