(57)【要約】電子契約文書をデジタルに署名するための方法およびシステム。電子通信は、識別子、その文書を含むメッセージ、および非対称鍵の対（２４７）の秘密鍵を用いて生成されたデジタル署名を含む。この識別子を使用して対応する公開鍵（２８７）およびそのメッセージの送信側に関するアカウント情報を取り出し得る。この公開鍵を使用して送信側およびメッセージを認証し得る。秘密鍵を含むデバイスを使用してデバイスのプライバシーを保護し得る。さらにこのデバイスは、デバイスへの検証データ入力に対応する検証ステータスインジケータを生成し得る。さらにこのインジケータは、契約文書の送信側がデジタルに署名されるべき電子通信を生じる明らかな実施を履行した証拠として使用され得る。安全なデータベースにおける公開鍵にリンクされたセキュリティプロフィールは、このデバイスのセキュリティ特徴を示す。【選択図】図１
2004517381.tif 000002
【特許請求の範囲】
【請求項１】
電子契約を含む取引において使用するための方法であって、
該契約に対する第１のパーティが一組の公開鍵／秘密鍵の秘密鍵を用いてデジタル署名を生成するデバイスを有するステップと、
該第１のパーティに関連付けられた識別子および他の情報に関連してデータベースに該第１のパーティの該一組の公開鍵／秘密鍵の該公開鍵を格納するステップと、
該デバイスに関連付けられたセキュリティプロフィールをデータベースに格納するステップと、
該契約に対する該第１のパーティが該デバイスを用いて該電子契約に関連する所定の情報に関するデジタル署名を生成するステップと、
該第１のパーティが、該契約に対する第２のパーティに電子通信を伝達するステップであって、該電子通信は、該第１のパーティに関連付けられた識別子、デジタル署名、および検証ステータスインジケータを含む、ステップと、
該電子通信の受信に応答して、該第２のパーティが該第１のパーティに関連付けられた該公開鍵を用いて該デジタル署名を認証するステップと、
該デジタル署名の認証に応答して、該第２のパーティが、該セキュリティプロフィールデータベースに、該第１のパーティに関連付けられたセキュリティプロフィールのための要求を通信するステップと、
該安全なエンティティからの、該第１のパーティに関連付けられた該セキュリティプロフィールの受信に応答して、該第２のパーティは、該第２のパーティによって保守された予め格納されたセキュリティプロフィールに関連したビジネス法則に基づいた該電子契約に関わる所定の情報に対する応答を判定するステップと、
該電子通信における該検証ステータスインジケータに応答して、該第２のパーティは、該第２のパーティによって保守された予め格納された検証ステータスに関連したビジネス法則に基づいた該電子契約に関わる所定の情報に対する応答して判定するステップと
を含む方法。
【請求項２】
前記識別子は、前記電子通信を送信しているパーティに関連付けられた前記公開鍵である、請求項１に記載の方法。
【請求項３】
前記契約に対する両方のパーティのそれぞれは、デジタル署名を生成するデバイスを保有する、請求項１に記載の方法。
【請求項４】
前記第１のパーティの前記公開鍵を格納するステップは、前記記載されたステップの前の登録動作において実行される、請求項１に記載の方法。
【請求項５】
前記データベースは、アカウント識別子に関連する前記第１のパーティに関連付けられた情報を格納する前記第２のパーティによって保守された既存のデータベースである、請求項１に記載の方法。
【請求項６】
前記セキュリティプロフィールは、第三者によって保守された安全なデータベースに格納される、請求項１に記載の方法。
【請求項７】
前記セキュリティプロフィールに対する要求は、前記第１のパーティの前記公開鍵に基づく、請求項１に記載の方法。
【請求項８】
前記セキュリティプロフィールに対する要求に応答して、該セキュリティプロフィールデータベースは、前記第１のパーティに関連付けられた該セキュリティプロフィールを取り出し、前記第２のパーティに該第１のパーティに関連付けられた該セキュリティプロフィールを伝達するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記セキュリティプロフィールデータベースは、前記第１のパーティまたは前記第１のパーティから独立した第三者によって保守される、請求項１に記載の方法。
【請求項１０】
前記電子契約に関連している前記所定の情報に対する前記第２のパーティの応答は、
前記契約に対する該第２のパーティが一組の公開鍵／秘密鍵の秘密鍵を用いてデジタル署名を生成するデバイスを有するステップと、
該第２のパーティに関連付けられた識別子および他の情報に関連する前記第１のパーティのデータベースに該第２のパーティの該一組の公開鍵／秘密鍵の該公開鍵を格納するステップと、
該契約に対する該第２のパーティが、該電子契約に関わる所定の情報に関するデジタル署名を生成するために該デバイスを用いるステップと、
該第２のパーティが該第１のパーティに第２の電子通信を伝達するステップであって、該第２の電子通信は、該第２のパーティに関連付けられた識別子、該デジタル署名、および検証ステータスインジケータを含む、ステップと
を含む、請求項１に記載の方法。
【請求項１１】
電子契約を含む取引において使用するための方法であって、
該契約に対する第１のパーティの一組の公開鍵／秘密鍵の該公開鍵に関連付けられたセキュリティプロフィールをデータベースに格納するステップと、
該契約に対する該第１のパーティが該電子契約に関わるデジタル署名を生成するステップと、
該第１のパーティが該契約に対する該第２のパーティに電子通信を伝達するステップであって、該電子通信は、該デジタル署名および検証ステータスインジケータを含む、ステップと、
該電子通信の受信に応答して、該第２のパーティが該第１のパーティに関連付けられた該公開鍵を用いて該デジタル署名を認証するステップと、
該デジタル署名の認証に応答して、該第２のパーティが、該セキュリティプロフィールデータベースに、該第１のパーティに関連付けられたセキュリティプロフィールにための要求を伝達するステップと、
該安全なエンティティから該第１のパーティに関連付けられた該セキュリティプロフィールの受信に応答して、該第２のパーティは、該第２のパーティによって保守された予め格納されたセキュリティプロフィールに関連したビジネス法則に基づいた該電子契約に対する応答を判定するステップと、
該電子通信における該検証ステータスインジケータに応答して、該第２のパーティは、該第２のパーティによって保守された予め格納された検証ステータスに関連したビジネス法則に基づいた該電子契約に対する応答を判定するステップと
を含む方法。
【請求項１２】
前記契約に対する両方のパーティのそれぞれは、デジタル署名を生成するデバイスを保有する、請求項１１に記載の方法。
【請求項１３】
前記第１のパーティの前記公開鍵を格納するステップは、前記記載されたステップの前の登録動作において実行される、請求項１１に記載の方法。
【請求項１４】
前記データベースは、アカウント識別子に関連する前記第１のパーティに関連付けられた情報を格納する前記第２のパーティによって保守された既存のデータベースである、請求項１１に記載の方法。
【請求項１５】
前記セキュリティプロフィールは、第三者によって保守された安全なデータベースに格納される、請求項１１に記載の方法。
【請求項１６】
前記セキュリティプロフィールに対する要求は、前記第１のパーティの前記公開鍵に基づく、請求項１１に記載の方法。
【請求項１７】
前記セキュリティプロフィールに対する要求に応答して、該セキュリティプロフィールデータベースは、前記第１のパーティに関連付けられた該セキュリティプロフィールを取り出し、前記第２のパーティに該第１のパーティに関連付けられた該セキュリティプロフィールを伝達するステップをさらに含む、請求項１１に記載の方法。
【請求項１８】
前記セキュリティプロフィールデータベースは、前記第１のパーティまたは前記第１のパーティから独立した第三者によって保守される、請求項１１に記載の方法。
【請求項１９】
前記電子契約に対する前記第２のパーティの応答は、
該契約に対する第２のパーティが、前記電子契約に関するデジタル署名を生成するステップと、
該第２のパーティが該第１のパーティに該第２の電子通信を伝達するステップであって、該第２の電子通信は、該デジタル署名および検証ステータスインジケータを含む、ステップと
を含む、請求項１１に記載の方法。
【請求項２０】
電子契約に関連している取引における使用のための方法であって、
該取引に対する第１のパーティの検証データを含む入力を受信するステップと、
デジタル署名を生成するデバイスにおいて、該デバイスの複数の所定の検証ステータスからの現在の検証ステータスを、該検証データおよび該デバイス内に予め格納されたデータの関数として識別するステップであって、各検証ステータスは、該デバイスによって実行されたエンティティ認証に関する、ステップと、
該識別された検証ステータスから独立して、該識別された検証ステータスの関数としてメッセージに対するデジタル署名を生成するステップであって、該生成されたデジタル署名は該識別された検証ステータスの表示を含む、ステップと、
該取引に対する該第２のパーティに該電子契約に関わる電子通信を用いて転送するために、該デバイスから該デジタル署名を出力するステップと、
該第２のパーティによる該電子通信の受信によって、該第２のパーティは該デジタル署名を認証するステップと、
該検証ステータスに応答して、該第２のパーティは該電子契約に対する応答を判定するステップと
を含む方法。
【請求項２１】
前記識別された検証ステータスの関数として前記メッセージを表す前記データをデバイス内で改変するステップをさらに含む、請求項２０に記載の方法。
【請求項２２】
前記契約に対する両方のパーティのそれぞれは、デジタル署名を生成するデバイスを保有する、請求項２０に記載の方法。
【請求項２３】
前記第１のパーティのデジタル署名を認証するステップは、該第１のパーティに関連付けられた予め格納された公開鍵を取り出すために前記電子通信を伴うアカウント識別子を用いるステップを含む、請求項２０に記載の方法。
【請求項２４】
前記記載されたステップの前の前記第２のパーティによって保守されたデータベースに前記第１のパーティの前記公開鍵を予め格納するステップをさらに含む、請求項２３に記載の方法。
【請求項２５】
前記データベースは、前記アカウント識別子に関連する前記第１のパーティに関連付けられた情報を格納する前記第２のパーティによって保守された既存のデータベースである、請求項２４に記載の方法。
【請求項２６】
前記電子契約に対する前記第２のパーティの応答は、
該契約に対する第２のパーティが、前記電子契約に関するデジタル署名を生成するステップと、
該第２のパーティが該第１のパーティに該第２の電子通信を伝達するステップであって、該第２の電子通信は、該第２のパーティのデジタル署名を含む、ステップと
を含む、請求項２０に記載の方法。
【請求項２７】
前記第２のパーティの前記デジタル署名は、該第２のパーティの検証データの関数である、請求項２０に記載の方法。
【請求項２８】
電子契約に関連している取引における使用のための方法であって、
該契約に対する第１のパーティが一組の公開鍵／秘密鍵の秘密鍵を用いてデジタル署名を生成するデバイスを有するステップと、
該デバイスに関連付けられたセキュリティプロフィールをデータベースに格納するステップと、
該契約に対する該第１のパーティが該デバイスを用いて該電子契約に関わる所定の情報に関するデジタル署名を生成するステップと、
該第１のパーティが、該契約に対する第２のパーティに電子通信を伝達するステップであって、該電子通信は、少なくともデジタル署名を含む、ステップと、
該電子通信の受信に応答して、該第２のパーティが該第１のパーティに関連付けられた該公開鍵を用いて該デジタル署名を認証するステップと、
該デジタル署名の認証に応答して、該第２のパーティが、該セキュリティプロフィールデータベースに該第１のパーティに関連付けられたセキュリティプロフィールのための要求を伝達するステップと、
該安全なエンティティから該第１のパーティに関連付けられた該セキュリティプロフィールの受信に応答して、該第２のパーティは、該第２のパーティによって保守された予め格納されたセキュリティプロフィールに関連したビジネス法則に基づいた該電子契約に応答して判定するステップと、
を含む方法。
【請求項２９】
前記第１のパーティに関連付けられた識別子および他の情報に関連しているデータベースにおいて該第１のパーティの前記一組の公開鍵／秘密鍵の前記公開鍵を格納するステップをさらに含む、請求項２８に記載の方法。
【請求項３０】
前記データベースは、アカウント識別子に関連する前記第１のパーティに関連付けられた情報を格納する前記第２のパーティによって保守された既存のデータベースでる、請求項２９に記載の方法。
【請求項３１】
前記識別子は、前記第１のパーティに関連付けられた前記公開鍵である、請求項２９に記載の方法。
【請求項３２】
前記契約に対する両方のパーティのそれぞれは、デジタル署名を生成し、互いに受信された電子通信に関する方法のステップを実行するデバイスを保有する、請求項２８に記載の方法。
【請求項３３】
前記第１のパーティの前記公開鍵を格納するステップは、前記記載されたステップの前の登録動作において実行される、請求項２８に記載の方法。
【請求項３４】
前記セキュリティプロフィールは、第三者によって保守された安全なデータベースに格納される、請求項２８に記載の方法。
【請求項３５】
前記セキュリティプロフィールに対する要求は、前記第１のパーティの前記公開鍵に基づく、請求項２８に記載の方法。
【請求項３６】
前記セキュリティプロフィールに対する要求に応答して、該セキュリティプロフィールデータベースは、前記第１のパーティに関連付けられた該セキュリティプロフィールを取り出し、前記第２のパーティに該第１のパーティに関連付けられた該セキュリティプロフィールを伝達するステップをさらに含む、請求項２８に記載の方法
【請求項３７】
前記セキュリティプロフィールデータベースは、前記第１のパーティまたは前記第２のパーティから独立した第三者によって保守される、請求項２８に記載の方法。
【請求項３８】
該取引に対する第１のパーティの検証データを含む入力をデバイスにおいて受信するステップと、
該デバイスの複数の所定の検証ステータスからの現在の検証ステータスを、該検証データおよび該デバイス内に予め格納されたデータの関数としてデバイス内で識別するステップであって、各検証ステータスは、該デバイスによって実行されたエンティティ認証に関する、ステップと、
該識別された検証ステータスから独立して、該識別された検証ステータスの関数としてメッセージに対するデジタル署名を生成するステップであって、該生成されたデジタル署名は該識別された検証ステータスの表示を含む、ステップと、
該取引に対する該第２のパーティに該電子契約に関連する電子通信を用いて転送するために、該デバイスから該デジタル署名を出力するステップと
を含む、請求項２８に記載の方法。
【請求項３９】
前記電子通信の前記検証ステータスインジケータに応答して、前記第２のパーティによって保守された予め格納されたステータスに関連付けれたビジネス規則に基づいて該電子契約に関する前記所定の情報に対する応答を決定するステップをさらに含む、請求項３８に記載の方法。
【請求項４０】
前記電子通信は、前記第１のパーティ、前記デジタル署名、および検証ステータスインジケータに関連付けられた識別子を含む、請求項３８に記載の方法。
【請求項４１】
前記電子契約に対する前記第２のパーティの応答は、
該契約に対する該第２のパーティが一組の公開鍵／秘密鍵の秘密鍵を用いてデジタル署名を生成するデバイスを有するステップと、
該第２のパーティに関連付けられた識別子および他の情報に関連する前記第１のパーティのデータベースに一組の公開鍵／秘密鍵の公開鍵を格納するステップと、
該契約に対する該第２のパーティが該デバイスを用いて該電子契約に対する応答に関するデジタル署名を生成するステップと、
該第２のパーティが、第１のパーティに第２の電子通信を伝達するステップであって、該第２の電子通信は、第２のパーティに関連付けられた識別子および該電子契約に対する応答に関する該デジタル署名を含む、ステップと
を含む、請求項３８に記載の方法。
【請求項４２】
電子契約を含む取引において使用するための方法であって、
該契約に対する少なくとも第１のパーティが、該第１のパーティに関連付けられた各一組の公開鍵／秘密鍵の各秘密鍵を用いてデジタル署名を生成するデバイスを有するステップと、
該第１のパーティに関連付けられた識別子に関連して第三者のデータベースに該第１のパーティの該公開鍵を格納するステップと、
該契約に対する該第１のパーティが該デバイスを用いて該電子契約に関連する所定の情報に関するデジタル署名を生成するステップと、
該第１のパーティが、該契約に対する第２のパーティに第１の電子通信を伝達するステップであって、該電子通信は、該第１のパーティおよび該デジタル署名に関連付けられた少なくとも１つの識別子を含む、ステップと、
該電子通信の受信に応答して、該第２のパーティが第２の電子通信を該第三者に転送するステップであって、該第２の電子通信は、該第１の電子通信からの少なくとも１つの識別子および該デジタル署名を含む、ステップと、
該第三者が、該エンティティ認証を示す第３の電子通信を該第２のパーティに転送するステップと、
該第１のパーティのエンティティ認証を示す該第３の電子通信の受信に応答して、該第２のパーティが該電子契約に対する応答を判定するステップと
を含む方法。
【請求項４３】
セキュリティプロフィールにおける前記第１のパーティのデバイスに関連付けられたセキュリティプロフィールを格納するステップをさらに含む、請求項４２に記載の方法。
【請求項４４】
前記第１のパーティの前記デジタル署名の認証に応答して、前記セキュリティプロフィールデータベースに該第１のパーティに関連付けられたセキュリティプロフィールに対する要求を伝達する、請求項４３に記載の方法。
【請求項４５】
前記セキュリティプロフィールに対する要求は、前記第三者または前記第２のパーティによって実行される、請求項４４に記載の方法。
【請求項４６】
前記第１のパーティに関連付けられた前記セキュリティプロフィールの受信に応答して、前記第２のパーティは、該第２のパーティによって保守された予め格納されたセキュリティプロフィールに関連付けられたビジネス法則に基づいた電子契約に対する応答を判定するステップをさらに含む、請求項４３に記載の方法。
【請求項４７】
前記契約に対する前記第２のパーティは、さらに該第２のパーティに関連付けられた各一組の公開鍵／秘密鍵の各秘密鍵を用いてデジタル署名を生成するデバイスを有して、
該第２のパーティの公開鍵は、該第２のパーティに関連付けられた識別子に関連して該第三者データベースに格納され、
デジタル署名を認証するステップは、該第２のパーティから該第１のパーティへの電子通信に関して該第三者によって実行される、請求項４２に記載の方法。
【請求項４８】
契約を形成する方法であって、該契約に関連する情報が、送信側から受信側に電子契約文書を電子通信として転送される方法は、
（ａ）  該送信側と該受信側との間の情報を交換するステップであって、該送信側は、該送信側に対応する受信側情報を提供し、該受信側は、該受信側に対応する情報を送信者に提供し、該交換された情報は、該各パーティに関連付けられた少なくとも１つの識別子および一組の公開鍵／秘密鍵の公開鍵を含む、ステップと、
（ｂ）  該送信側は、該受信側に対応する該データを送信側データベースに格納するステップおよび該受信側は、該送信側に対応する該データを受信側データベースに格納するステップと、
（ｃ）  該送信側が該各秘密鍵を用いて該電子契約文書をデジタルに署名してデジタル署名を形成するステップと、
（ｄ）  該送信側が、少なくとも該デジタル署名および該識別子を含む電子通信を該受信側に転送するステップと、
（ｅ）  該電子通信の受信に応答して、該受信側は、該電子通信から得られた該送信側の識別子を利用して、該送信側に対応する該公開鍵を取り出すステップと、
（ｆ）  該電子通信におけるデジタル署名を認証して該送信側にエンティティ認証を判定するステップと、
（ｇ）  該エンティティ認証に基づいて電子契約文書に対する応答を判定するステップと
を含む、方法。
【請求項４９】
前記エンティティ認証に基づいて前記電子契約文書に対する応答を判定するステップは、オファーを受理するステップを含む、請求項４８に記載の方法。
【請求項５０】
前記エンティティ認証に基づいて前記電子契約文書に対する応答を判定するステップは、オファーを拒絶するステップを含む、請求項４８に記載の方法。
【請求項５１】
前記デジタル署名は、前記電子契約文書のメッセージダイジェストを含む、請求項４８に記載の方法。
【請求項５２】
前記メッセージダイジェストは、前記電子契約文書のハッシュ値である、請求項５１に記載の方法。
【請求項５３】
前記エンティティ認証に基づいて前記電子契約文書に対する応答を判定するステップは、電子受理が生成されるようにオファーを受理するステップを含み、該受理は該オファーの条件を修正する、請求項４８に記載の方法。
【請求項５４】
前記契約文書の内容は、商品を購買するオファーであり、前記エンティティ認証に基づく該電子契約文書に対する応答を判定するステップが前記送信側の金融資源が前記取引に対して十分であるかどうかの前記受信側による判定を含む、請求項４８に記載の方法。
【請求項５５】
前記送信側の金融資源が前記取引に対して十分であるかどうかの前記受信側による判定は、前記受信側データベースに格納された、該送信側に関連付けられたアカウント情報への参照を含む、請求項５４に記載の方法。
【請求項５６】
前記送信側の前記アカウント情報は、現金、支払可能なアカウント、受信可能なアカウント、支払の適時性に関する支払履歴、および前記オファーを受理するかどうかについてのビジネス判定を行うことに関連する任意の他の情報を含む、請求項５５に記載の方法。
【請求項５７】
契約パーティ間の電子契約のための方法であって、契約文書の内容は、電子通信におけるメッセージとして送信側から受信側に転送され、各パーティは、他のパーティに対するアカウントを保守するような関係を形成し、該アカウントは、該パーティの識別子およびアカウントの特定の情報を含むデータベース記録を含み、該方法は、
該電子契約に関連する内容に関して、デバイス内で、該メッセージ送信側の検証データを含む入力を受信するステップと、
デバイス内で、該検証データの関数として該デバイスの現在の検証ステータスを識別するステップと、
該電子取引の内容に関するデジタル署名を生成するステップと、
該デバイスから該現在の検証ステータスのインジケータを出力するステップと、
少なくとも該デジタル署名および該現在の検証ステータスを組み合わせ電子通信に生成するステップと、
該送信側から該受信側へ該電子通信を送信するステップと、
該受信側が該電子通信を受信するステップと、
該デジタル署名の使用によって、該受信側が該電子通信の該送信側を認証するステップと、
該検証ステータスインジケータの使用によって、該送信側が該電子契約に関連する内容を意図したことを判定するステップと、
該送信側が該電子メッセージの内容を意図した判定に基づいて該電子契約に対する応答を判定するステップと
を含む、方法。
【請求項５８】
第１のパーティと第２のパーティ間の電子契約のための方法であって、
個人化されたデバイスに入力された情報に関するデジタル署名の生成のために該個人化されたデバイスを提供するステップと、
該電子契約の条件に関連する情報を安全に表示し、安全な入力デバイスに入力された情報に関するデジタル情報を生成する安全な入力デバイスを提供するステップと、
該安全な入力デバイスに関連付けられたディスプレイ上の該電子契約の条件に関連する情報を表示するステップと、
該安全な入力デバイスから該個人化されたデバイスへ電子契約に関連するメッセージを通信するステップと、
該安全な入力デバイスによって提供されたメッセージに関するデジタル署名を該個人化されたデバイスを用いて生成するステップと、
該個人化されたデバイスから該安全な入力デバイスに第１の電子通信として少なくとも該デジタル署名を通信するステップと、
該安全な入力デバイスにおいて、該第１の電子通信に関するデジタル署名を生成するステップと、
該第１のパーティから該第２のパーティへ該第１の電子通信に関する少なくとも該デジタル署名を含む第２の電子通信を通信するステップと
を含む、方法。
【請求項５９】
前記第２のパーティが第２の電子通信を受信するステップと、
前記第１の通信の該デジタル署名の使用によって、該第２のパーティが前記第１のパーティを認証するステップと、
前記第２の通信の該デジタル署名の使用によって、該第１のパーティが前記電子契約に関連する内容を意図したことを判定するステップと、
該第２のパーティは、該第１のパーティが該電子メッセージの内容を意図した判定に基づいた該電子契約に対する応答を判定するステップと
をさらに含む、請求項５８に記載の方法。
【請求項６０】
前記安全な入力デバイスは、検証データの安全なエントリを受信するためにさらに動作可能である、請求項５８に記載の方法。
【請求項６１】
前記電子契約メッセージに関連するメッセージは、前記安全な入力デバイスに安全に入力される検証データを含む、請求項６０に記載の方法。
【請求項６２】
前記電子契約に関連するメッセージは、前記電子契約の条件に関連する情報を含む、請求項６１に記載の方法。
【請求項６３】
第１のパーティと第２のパーティ間の電子契約のための方法であって、
個人化されたデバイスに入力された情報に関するデジタル署名の生成のために該個人化されたデバイスを提供するステップと、
検証データの安全なエントリを受信し、安全な入力デバイスに入力される情報に関するデジタル署名を生成する該安全な入力デバイスを提供するステップと、
該電子契約に関連する内容に関して、該第１のパーティの該安全な入力デバイスにおいて検証データを受信するステップと、
該個人化されたデバイスを用いて、該検証データを含む電子契約の内容に関してデジタル署名を生成するステップと、
該個人化されたデバイスから該安全な入力デバイスへ少なくとも該デジタル署名を第１の電子通信として伝達するステップと、
該安全な入力デバイスにおいて、該第１の電子通信に関するデジタル署名を生成するステップと、
該個人化されたデバイス状態の該デジタル署名と該安全な入力デバイスの少なくとも該デジタル署名とを組み合わせて、第２の電子通信を形成するステップと、
該第１のパーティから該第２のパーティへ該第２の電子通信を伝達するステップと
を含む、方法。
【請求項６４】
前記第２のパーティが第２の電子通信を受信するステップと、
前記第１の通信の前記デジタル署名の使用によって、該第２のパーティが前記第１のパーティを認証するステップと、
前記第２の通信の該デジタル署名の使用によって、該第１のパーティが前記電子契約に関連する内容を意図したことを判定するステップと、
該第２のパーティは、該第１のパーティが該電子メッセージの内容を意図した判定に基づいた該電子契約に対する応答を判定するステップと
をさらに含む、請求項６３に記載の方法。
【請求項６５】
前記安全な入力デバイスは、ユーザへの電子契約に関連する情報の安全な表示に対して動作可能である、請求項６３に記載の方法。
【請求項６６】
前記電子契約の条件に関連する情報を前記安全な入力デバイスに表示するステップをさらに含む、請求項６３に記載の方法。
【請求項６７】
前記安全な入力デバイスにおいて電子的に表示された条件が前記個人化されたデバイスによってデジタル署名に対して該電子契約の内容として提供される、請求項６６に記載の方法。
【発明の詳細な説明】
【０００１】
（Ｉ．関連出願の相互参照）
本特許出願は、米国特許法１１９条３５項、および世界的なパリ条約における優先権を主張し、２０００年８月４日に出願されたＷｈｅｅｌｅｒらの米国仮特許出願第６０／２２３，０７６号の出願日の利益を主張し、本明細書中で参考として援用する。また本出願は、４つの国際特許出願および３つの米国特許出願のそれぞれを、本明細書中で参考として援用する。これらの出願は、ＡｎｎｅおよびＬｙｎｎ  Ｗｈｅｅｌｅｒによって同時に米国特許商標庁に出願され、関連する出願番号は、ＰＣＴ／ＵＳ＿／＿（“Ｐｅｒｓｏｎ−Ｃｅｎｔｒｉｃ  Ａｃｃｏｕｎｔ−Ｂａｓｅｄ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅ  Ｓｙｓｔｅｍ”と題された）および出願番号０９／＿，＿（“Ａｃｃｏｕｎｔ−Ｂａｓｅｄ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅ（ＡＢＤＳ）  Ｓｙｓｔｅｍ”と題され、以後これらの出願を「ＡＢＤＳ出願」と呼ぶ）と、ＰＣＴ／ＵＳ＿／＿（“Ｅｎｔｒｙ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｉｎ  Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｂｙ  Ｐｒｏｖｉｄｉｎｇ  Ｖｅｒｉｆｉｃａｔｉｏｎ  Ｓｔａｔｕｓ  ｏｆ  Ｄｅｖｉｃｅ”と題され、以後これらの出願を「ＶＳ出願」と呼ぶ）および出願番号０９／＿，＿（“Ｍｏｄｉｆｙｉｎｇ  Ｍｅｓｓａｇｅ  Ｄａｔａ  ａｎｄ  Ｇｅｎｅｒａｔｉｎｇ  Ｒａｎｄｏｍ  Ｎｕｍｂｅｒ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅ  Ｗｉｔｈｉｎ  Ｃｏｍｐｕｔｅｒ  Ｃｈｉｐ”と題された）と、ＰＣＴ／ＵＳ＿／＿（“Ｌｉｎｋｉｎｇ  Ｐｕｂｌｉｃ  Ｋｅｙ  ｏｆ  Ｄｅｖｉｃｅ  ｔｏ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｄｕｒｉｎｇ  Ｍａｎｕｆａｃｔｕｒｅ”と題された）および出願番号０９／＿，＿（“Ｍａｎｕｆａｃｔｕｒｉｎｇ  Ｕｎｉｑｕｅ  Ｄｅｖｉｃｅｓ  Ｔｈａｔ  Ｇｅｎｅｒａｔｅ  Ｄｉｇｉｔａｌ  Ｓｉｇｎａｔｕｒｅｓ”と題され、以後これらの出願を「ＴＡＤＳ出願」と呼ぶ）とである。
【０００２】
（ＩＩ．発明の分野）
本発明は、契約書の条件を含む電子通信がデジタル署名されるシステムおよび方法に関する。より詳細には、アカウント情報が、検証ステータスインジケータおよびセキュリティプロフィールを用いることによって個人（ｉｎｄｉｖｉｄｕａｌ）またはエンティティの送信にリンクされる。検証ステータスインジケータおよびセキュリティプロフィールは、送信デバイスに対応し、送信側が契約条件によって拘束されるように判断することが受信側にとって容易になるように使用される。
【０００３】
（ＩＩＩ．発明の背景）
現在の商業環境では、効率性および適時性が多くのビジネスの成功を保証する際に重要である。さらに取引は遠距離をはさんで発生し得る。例えば、契約に対する２つのパーティは、条件が交渉される場合、またはその契約が実際に実行される場合であっても同じ時に同じ場所に実際に物理的に存在し得ない。配置される。契約を交渉かつ実行する従来の手段は、電話による通信、メールまたはファクシミリ装置を使用するパーティ間で送信された文書の通信、あるいは代理人または仲介者等の第三者の交渉者でさえも含む。このような行動を容易にする技術がある（すなわち、契約書がメールを介した文書の送信に対して形成される速度を増加させるファックス装置）が、インターネットおよび電子メールの最近の爆発的な増加は、さらなる高速化および契約書形成の効率性の可能性を生じる。
【０００４】
しかし、インターネットおよび電子メールは、単に通信を形成するに過ぎない。契約書、申し込み、受領、および検討の基本要素が依然として存在しなければならない。さらに統一商事法典（Ｕｎｉｆｏｒｍ  ｃｏｍｍｅｒｃｉａｌ  ｃｏｄｅ：ＵＣＣ）２条は、商品の販売にさらに適用する。さらに、世界および米国商業条例（Ｇｌｏｂａｌ  ａｎｄ  Ｎａｔｉｏｎａｌ  Ｃｏｍｍｅｒｃｅ  Ａｃｔ：「Ｅ−ＳＩＧＮ」）の電子署名および統一電子商取引条例（Ｕｎｉｆｏｒｍ  Ｅｌｅｃｔｒｏｎｉｃ  Ｔｒａｎｓａｃｔｉｏｎ  Ａｃｔ：「ＵＥＴＡ」）（１９９９）は、電子契約書（「ｅ−ｃｏｎｔｒａｃｔ」）の促進に関する標準的な法律を対象とする法律制定の最近の例である。
【０００５】
管理および予算管理局による「Ｍｅｍｏｒａｎｄｕｍ  ｆｏｒ  ｔｈｅ  Ｈｅａｄｓ  ｏｆ  Ｄｅｐａｒｔｍｅｎｔｓ  ａｎｄ  Ａｇｅｎｃｉｅｓ」のメモＭ−００−１５によると、「Ｅ−ＳＩＧＮは、電子技術の使用に対する法律の障壁を取り除いて契約書を形成し、これに署名し、文書を収集および蓄積し、そして通知および開示を送信および受信する」。さらに、ＵＥＴＡに対するコメントに説明されているように、署名の主なポイントは、法律的に重要な作用の意図を有する音声、記号、またはプロセスを適用することである。従って、ＵＥＴＡは、電子署名および手書きの署名が同等であることを確立するように試みる。さらに電子署名は、署名される記録または文書と接続されるべきである。
【０００６】
従って、インターネットを介して契約する際、例えば、署名されるべき文書を有する電子署名またはデジタル署名を接続する方法の問題点、および従って有効な契約書が形成されることを判断する方法の問題点が生じる。商品の販売に関する従来の契約法は、ある金額（通常＄５００）を超えて、全ての契約を証明するための契約になるようにパーティによって手書きで署名されることを必要とする。一般的には、５００＄を超える口頭の契約は、契約されるべきパーティが契約を許可しない場合、実際には各州がある様式または別の様式で法律を制定しているＵＣＣの詐欺防止法に基づいて法的拘束力がない。
【０００７】
上述のように、ＵＣＣ、ＵＥＴＡ、およびＥ−ＳＩＧＮは、物理的署名の必要性の抜け道を提供する。従って、電子商取引（「ｅ−コマース」）に関して、拘束されることを意図する種々の方法がある。ＵＣＣセクション１〜２０１は、「署名されたもの」が、書類を検証することに対して現在意図しているパーティによって実行または適応された任意のシンボルを含み、「書面（ｗｒｉｔｔｅｎ）」または「書類」は、印刷、タイプライティング、または明確な形態への意図する変形の任意の他の態様を含むことを規定する。従って、例えばデジタル署名が電子データとして表現されるため、デジタル署名は、それに含まれる条件によって束縛される電子文書と共に意図を表し得る。
【０００８】
従って、競争市場の性質は、電子商取引の領域において多くの技術的利点を推進してきた。電子通信（「ＥＣ」）は、電子形態の通信であることが考慮される。今日ＥＣは、特にインターネットおよび電子商取引の成長に伴って、商取引ビジネスの重要な部分になってきている。近年、デジタル署名はまた、ＥＣの送信側を識別し、そしてＥＣ内に含まれたメッセージを検証するために使用されたデジタル署名と共に、電子商取引の重要な部分になってきている。従って、電子契約を促進するためにデジタル署名およびＥＣの現代の商業への統合は、技術的発展の当然の結果である。
【０００９】
しかし、デジタル署名を用いるための計算システムは、典型的には、メッセージ検証および送信側の検証を実行するために設計される。これらのシステムは、メッセージ発信者による明確な作用なしにデジタル署名を適用し得る。従って、これらのシステムは、発信者の検証を支援するのみであるため、発信者の意図の意味を欠いている。
【００１０】
デジタル署名の開始は、実質的にＥＣにおいて送信されたメッセージ（「Ｍ」）の暗号化を含む。さらに、このメッセージは、ＥＣ内で伝達されるメッセージのハッシュ値を含み得る。このハッシュを生成するために使用されたハッシュアルゴリズムは、例えば、ＳＨＡ−１または公知の他の同様のアルゴリズムである。ハッシュ値を含んでもよいし含まなくてもよいこのメッセージは、公開−秘密鍵暗号法（また非対称暗号法として公知である）において使用された鍵の対の秘密鍵（「ＰｒＫ」）を用いて電子デバイスによって暗号化される。メッセージのダイジェストとして参照され得る生じた暗号文は、デジタル署名（「ＤＳ」）を構成し、デジタル署名は、典型的には、メッセージに添付され、送信側から受信側に送信されるＥＣを形成する。ハッシュ値を生成する際に、いずれかのデバイスは、ハッシュアルゴリズム（ＳＨＡ−１アルゴリズム等）を送信されるべきメッセージの内容に適用するか、または、ハッシュアルゴリズムは、デバイス外部にあるメッセージに適用され、次いで生じたハッシュ値は、暗号化のためにデバイスに通信される。さらに、暗号化がデバイスによって実行される間、デバイスのユーザ（すなわち、ＥＣの送信側）がデジタル署名の「署名者」であると考えられている。送信側は、送信側のアイデンティティを要求するクエリにデジタル署名を用いて自動的に応答する計算システムであり得る。これは、識別のためのトラフィック制御要求に応答して航空機のトランスポンダに分類され得る。
【００１１】
ＥＣの受信は、理解しているか、またはメッセージに適用されたハッシュアルゴリズムとデジタル署名を生成するために使用される秘密鍵に対応する公開鍵（「ＰｒＫ」）の両方を入手することができる。この知識によると、受信側は、適切なハッシュアルゴリズムをメッセージに適用して、ハッシュ値を生成し、次いでデジタル署名を復号する。この受信によって生成されたハッシュ値は、複合化されたデジタル署名のハッシュ値に等しい場合、受信は、メッセージに署名した送信側が受信によって保持された公開鍵に対応する秘密鍵を有していたと判定することができる。従って、受信側は、送信側を「認証する」。さらに、受信側は、ＥＣに含まれたメッセージの内容が変更または改変されたことを判定することができる。なぜなら、メッセージに対する任意の変化がハッシュ値に変更されるためである。従って、受信側は、送信側を「認証する」。さらに、受信側は、ＥＣに含まれるメッセージの内容が変更または改変されない、なぜならメッセージに対する任意の変化がハッシュ値を変化させるためである。従って、受信側はメッセージを「認証する」。
【００１２】
デジタル証明（「デジタルＩＤ」として公知）は、公開鍵の所有者のアイデンティティを証明する第三者（一般的に証明オーソリティと呼ばれる）による証書である。本質的には、デジタル署名は、運転免許書、パスポート、会員書、識別の他の紙ベースの形態である。デジタル証明自体は公開鍵および公開鍵の所有者のアイデンティティを含む電子メッセージを含む。さらにデジタル証明は、典型的には、公開鍵の終了日、証明オーソリティの名前、デジタル証明のシリアルナンバー、および証明オーソリティのデジタル署名を含む。デジタル証明に対して最も広く受け入れられたファーマットは、ＣＣＩＴＴ  Ｘ．５０９国際規格によって定義され、従って、検証は、Ｘ．５０９を用いてコンパイルする任意のアプリケーションによって読み出しまたは書き込まれ得る。ＥＣに含まれたデジタル証明に依存して、受信側は、証明オーソリティの公開鍵を用いてデジタル証明を認証することができ、従って、そこで説明された所有者のアイデンティティを確認する。
【００１３】
デジタル証明がＥＣに含まれるシステムは、「証明オーソリティデジタル署名」（ＣＡＤＳ）と一般的に呼ばれる公開鍵インフラストラクチャー（ＰＫＩ）を含む。不幸にも、ＣＡＤＳシステムは、そうでなければ、互いに予め存在する関係を有し得ない２人のパーティが他のアイデンティティを理解する確信によって互いに通信することを可能にする一方で、ＣＡＤＳシステムは欠点を有する。例えば、典型的には、デジタル証明は満了日で発行され、一般的には、満了したデジタル証明は、産業では理解されない。さらに、秘密鍵が損失または盗難された場合、秘密鍵の所有者は、証明オーソリティに所有者のデジタル証明を無効にするように通知しなければならない。しかし、受信側は、証明オーソリティによって発行された検証無効リスト（ＣＲＬ）に対してデジタル証明のシリアル番号を相互参照する場合、デジタル証明を有するＥＣの受信側は、デジタル証明の無効を知っているのみである。ＣＡＤＳシステムに対する別の欠点は、デジタル証明自体がデジタル証明を発行する特定の機関と同然であることである。受け取られるべきおよび活動されるべき取引または通信に対する送信側と受信側との間の信頼の「チェーン」または「ネットワーク」を作成するために、デジタル証明は、複数のデジタル証明（すなわち、組み込まれたＡＢＤＳ出願の図１に示されたような証明オーソリティ３０６ａ、３０６ｂ〜３０６ｎから）を入手する必要があり得る。さらに、全体のＣＡＤＳシステムは、デジタル証明を発行する証明オーソリティの秘密鍵の秘匿性によって決まり、和解した場合、ＣＡＤＳシステムを崩壊させる。
【００１４】
オンライン購入オーダーの例のようなアカウントに関するＥＣの点において、ＣＡＤＳシステムの別の欠点は、アカウント情報がインターネットのような安全ではない通信媒体を介して送信された場合、アカウント情報は暗号化されるか、またはそうでなければ保護されなければならない。上述の例では、アカウント情報の通信上で盗むハッカーは、不正料金を購入者のアカウントにかける（特に、全ての商取引者が購入オーダーを満たすデジタル署名およびデジタル証明を必要とするとは限らない場合）十分な情報を処理する。さらに金融機関は、購入者のデジタル署名が商取引者により支払要求を認証する前の条件として提示される要求をさらに標準化する必要がある。その代わりとして、購入者が商取引者への支払に影響を与える権限を有するかどうか、およびアカウント情報が損失または盗まれたかどうかを判定する際に、金融機関は、商取引者によって提供された個人アカウント情報に依存する。
【００１５】
従って、デジタル署名を用いて契約書に関連した文書を含むＥＣと通信する改良されたシステムのため、および固有の非効率、制限、およびＣＡＤＳの潜在的な落とし穴なしで、契約しているパーティおよびパーティに関連するアカウント情報のアイデンティティを認証するための必要性が存在する。
【００１６】
ＥＣの一部として送信されるべき秘密の識別情報（すなわち、ＰＩＮまたは母の結婚前の名前）のための必要性なしで個人にアカウント情報をリンクさせ、それによって、このような秘密情報のハッキングを防止し得るこのようなシステムに対する必要性もまた存在する。
【００１７】
さらに、電子通信を送信するパーティのアイデンティティが連続的に確認され得る。
別のパーティが予め存在する関係（例えば、商業の従業員）を有するパーティのアイデンティティである場合、商人の秘密鍵へのアクセスを有し得る。これは、雇用者の秘密鍵を知っている低レベルの従業員が雇用者を大きな取引に拘束することが可能であり得るシナリオを作成するが、従業員は、比較的少ないドル額の取引を除いて会社を束縛するように認証されない。従って、低レベルの従業員は、別のパーティと向かい合っている雇用者を束縛するための明らかな権限を有し得るが、そのための実際の権限を有し得ない。
【００１８】
さらに、送信側が雇用者を拘束する権限を有する場合であっても、送信側は、仕事日の間の種々の時間において複数のパーティと契約する従業員であり得る。例えば、従業員は仕事日の間の所定の時間の間に、複数のパーティとの契約を始めることに関与され、ＰＣを使用する従業員は、契約書の条件を検討することなく、不注意にも契約書に同意し得る。これは、従業員が他のパーティ契約書の条件の交渉に積極的に従事し、各パーティはカウンターオファーを有する他人に応答している場合に起こる。次いで、従業員のコンピュータ上で動作状態にある文書に注意を払わないため、不注意なキーボードストロークは、全体的に異なるパーティから到着するメッセージに応答して送信されるオファーまたは受信を引き起こす。これは、エンティティによる明瞭なアクションに対する必要性なしで、エンティティを認証するように設計されたコンピュータシステムと、特定の文書と共に人の意図またはエンティティの意図を示すように設計されたコンピュータシステムとの間に差異が存在するためである。従って、契約文書を含む電子通信の受信を可能にするための必要性が存在し、送信側が拘束されるべき権限を有し、さらに、送信側が文書の条件に拘束されることを意図するかどうかを判定する。
【００１９】
最後に、秘密情報を含み、秘密情報に合法的に関連付けられた人またはエンティティと見せかけるハッカーの可能性が低くなるかまたは存在しなくなるように、
契約文書を含む電子通信の受信を可能にする必要性が存在し、ＥＣにデジタル署名するために使用されていた秘密情報が物理的に保護されるレベルを判定する。
【００２０】
（ＩＶ．発明の要旨）
本発明は契約を安全に形成および実行するための電子メッセージを用いるための方法およびシステムに関する。本願は、ＡＢＤＳ出願を参照として組み込み、この出願はアカウントオーソリティ（「ＡＡ」）を用いてＥＣを送信するために詳細な方法、システム、およびデバイスを開示し、ＥＣの送信側に関連付けられた受信側アカウント情報を維持および転送する。ＡＡは、リクエスタが自分であると言う者および他者に関連付けられた情報にアクセスする権限を与えられた者であることを識別および認証する。要求の検証および認証に応じて、ＡＡは、要求された情報をリクエスタに放出し得る。
【００２１】
パーティ間の電子契約を促進するために、電子契約に対する各パーティは、他のパーティに対してＡＡとして動作し得る。第三者ＡＡがさらに使用されて、情報を契約パーティに提供することを促進する。組み込まれたＶＳ、ＡＢＤＳ、およびＰＲｉＭＲ出願において説明された種々の特徴および技術を使用して、従来の契約プロセスの種々の局面を実現し、それによって、電子契約を可能にする。組み込まれたＶＳアプリケーションは、秘密鍵を含むデバイスを作製して使用し、とりわけＤＳを生成するためのデバイス、方法、およびシステムを詳細に開示する。このデバイスは、デバイスが製造された安全レベルに基づいて、別の者が、第１の個人として不正に見せかけるようにデバイスの秘密鍵を使用できず、従って第１の個人が拘束されない契約に第１の個人を拘束するような個人用である。さらに、デバイスは、デバイスに保持された秘密鍵を有する安全な環境において製造され、公開鍵がデバイスのセキュリティ特性にリンクされるような安全な環境のデータベースにおいて、公開鍵（補足的には秘密鍵）が保持され得る。このシナリオは、組み込まれたＰＲｉＭＲアプリケーションにおいて開示される。
【００２２】
パーティ間の電子契約を促進する上述のＡＢＤＳ、ＰＲｉＭＲ、およびＶＳ出願において開示された技術に対して、パーティは、典型的には、パーティ間の未来の契約を考慮する関係を形成しているが、そのパーティがまだ関係を形成していないシナリオがさらに支援される。パーティＡが所定のデータをパーティＢに提供し、契約プロセスが開始する前に、パーティＢが所定のデータをパーティＢに提供する。あるいは、パーティが所定のデータを第三者パーティＡＡに提供する。従って、パーティＢがパーティＡからＥＣを受け取る場合、ＡＡ機能は、ＥＣを受け取るパーソナルコンピュータ（「ＰＣ」）または携帯情報端末（「ＰＤＡ」）等のパーティＢのデバイスにおいて、あるいは第三者ＡＡへの要求を送信することのいずれかによって実行される。
【００２３】
予備的な「セットアップ」データは、典型的には、他のパーティのＰｕＫおよび好適なハッシュルーチン（ＳＨＡ−１等）を含む。さらにこのデータは、現金（ｃａｓｈ  ｏｎ  ｈａｎｄ）等の情報、支払可能なアカウント、受け取り可能なアカウント、支払の適時性に関する支払履歴、製造能力、貯蓄商品の品質、商品の出荷の適時性またはサービスの効率、ならびに、オファーするかまたはオファーを受け取るかどうかのビジネス判定を行うかに関する情報を含む。さらに、この情報は、商品および商品の説明自体を製造するために使用された原料および／またはとりわけパーティが提供するサービスのタイプ等のパーティのビジネスに関するパラメータを含み得る。情報のタイプは、特定のタイプの製品を取引する商取引者を探している潜在的な提供者によって使用され得るキーワード検索を容易にする。
【００２４】
例えば、パーティＡが提供者であり、パーティＢが被提供者（ｏｆｆｅｒｅｅ）である場合、Ａは、ＥＣの形態でＢに提案を送信する。このＥＣは、組み込まれたＶＳ出願において開示されたデバイスのタイプのようなＡのデバイスからＡによって送信される。従って、Ａのコンピュータデバイスは、提案された契約を、ＡのＰｒＫおよび恐らくハッシュルーチンを用いてＥＣに符号化して、その契約をＡのＰＣからＢのＰＣに送信する。ＢがメッセージとしてＥＣに符号化された契約オファーを受信する場合、ＢのＰＣは、Ａの名前またはアカウント番号等の識別情報を取り出し、名前またはアカウント番号によってインデックスを付けて、ＢのＰＣに常駐するデータベースを検索する。この検索から、ＢはＰｕＫに関連付けられたＡの情報を取り出し、ＥＣのデジタル署名を認証する。デジタル署名の成功した認証は、ＥＣがＡによって送信された信用を提供する。
【００２５】
Ｂは、受信されたメッセージがＡによって送信された同一のメッセージであることを判定することを望む場合、Ｂは、識別情報を使用して、識別情報に関連付けられたハッシュルーチンを取り出し得る。次いで、メッセージはハッシュルーチンによって検討される。認証されたＥＣのコンポーネントの内の１つは、メッセージ（このメッセージは、メッセージのハッシュ値とは別のＥＣコンポーネントである）のハッシュ値であり得るために、次いでＢは、Ｂによって検討されたようなメッセージの値と識別されたハッシュ値とを比較する。これら２つの値が一致する場合、Ｂは、メッセージがＡによって送信された後に変更されないことを確実にする。これは、Ａが束縛を意図する契約の条件を、Ｂが証明する必要がある場合、重要であり得る。
【００２６】
従って、ハッカーからメッセージの内容を保持することとは対照的に、メッセージの送信側を認証することに焦点が当てられてきた。従って、裸で暗号化されていないメッセージがＥＣのコンポーネントであり、暗号化され選択的にハッシュされたメッセージがＥＣの別のコンポーネントであり得る場合、メッセージ自体が、暗号化され得ない。しかし、ＥＣの転送に対する盗聴者がメッセージの内容を判定することを妨げるために、メッセージは同様に暗号化され得る。
【００２７】
契約書およびその内容への望ましくないアクセスを妨げるためにメッセージを暗号化することが望ましい場合、メッセージは、ハッシュされたメッセージと同様に暗号化され得る。これは、非対称鍵の対を使用するＰｒｅｔｔｙ  Ｇｏｏｄ  Ｐｒｉｖａｃｙ（「ＰＧＰ」）として当業者に公知の暗号化方法の動作と同様である。しかし、それらの鍵が共に使用される態様と従来のＰＧＰにおいて使用される態様との間に差異がある。従来のＰＧＰでは、メッセージの送信側は、受信側の公開鍵を用いてメッセージを暗号化する。この受信側は、秘密鍵を用いて復号化する。従って、受信側（または受信側の秘密鍵へのアクセスを有する者）のみが、そのメッセージに含まれる情報を復号化し、アクセスし得る。
【００２８】
本発明に関して、送信側は、送信側自身の秘密鍵を用いてメッセージを暗号化して、デジタル署名を作成し、次いで、受信側は、送信側の公開鍵を用いてデジタル署名を復号化することによって送信側を認証する。従って、非対称か鍵の対の両方の部分は、実質的に秘密鍵として使用される。なぜなら、各パーティは、パーティのローカルＰＣまたはセキュアＡＡのいずれかにおいて、鍵の以前の交換から受信された他の公開鍵を格納するためである。この送信側は、送信側の公開鍵を受信側に与え、受信側またはＡＡに依存して、その鍵を他人から秘密にする。そのため、送信側の公開鍵は、実質的に半秘密鍵である。なぜなら、この公開鍵を知っている者の世界が制限されるためである。従って、公開鍵は、ある契約書に対してパーティによって使用されて、電子メッセージの内容に対する十分な安全性を提供し得る。特定のパーティが、メッセージの信頼性に関して完全な保証を主張する場合、ＰＧＰを使用して、他の非対称鍵の対の受信側の公開鍵を用いてメッセージを符号化し得る。
【００２９】
（Ａ．第１の局面（各パーティがアカウント期間として他のパーティに作用する）
送信側およびＥＣの内容を認証するための手段を提供することに加えて、ＡＡ機能は、パーティが他のパーティと契約することを望むかどうかに対して適切であり得る情報を提供し得る。アカウント情報は、ＥＣのイニシエータが、他のパーティが契約条件下で他のパーティの債務を実行することを可能にし、従って、他のパーティと契約を開始することか望ましいかどうかを判定することを可能にするアカウント情報が提供され得る。
【００３０】
（Ｂ．第２の局面（同意するかどうかを（自動的に）判定するために使用されたビジネス法則））
しばしば、同一のパーティは、以前の取引と同一または同様の条件を有する契約を開始する。さらに、同様な取引は正確に同一のパーティ間またはパーティの有限なセットまたはグループ間に存在し得る。従って、オファーまたは受信を行うかどうかを判定することは、同一のパーティ間の以前の取引、パーティのグループ間で共有された履歴データ、または最も重要であるのは、予め判定されたビジネス法則に基づき得る。典型的には、ビジネス法則は、コスト、品質、配達または製品要求等のパラメータに関して閾値および限界を確立する。例えば、従来では、ビジネスの経営者は、所定のドル額まで購入を認証する自主性を有するが、この所定のドル額よりも高い購入に対してより高い順位の経営者からの認証を得ることを必要とし得る。このようなシナリオは、売買された商品のタイプ（事務用品または他の低コストなアイテム）が消費可能である場合、発生する可能性があり得る。従って、本発明の第２の局面は、所与のパーティがビジネス法則をコンピュータアルゴリズムに組み込み、オファーを自動的に受け入れ、それにより人間を契約書の条件の交渉に参加させる必要性を取り除く。
【００３１】
（Ｃ．第３の局面（第３者ＡＡが他のパーティのアカウント情報を「保証する」））
本発明の上述の局面は、契約しているパーティが予め存在している関係を有するシナリオに関する。しかし、アカウント情報は、最初のセットアップステージにおいて交換されて、パーティ間の契約を促進し得るが、第三者ＡＡモデルは、所定のシナリオで好適であり得る。例えば、アカウント情報が製品の品質などの主観的なデータを含む場合、第三者ＡＡは好適であり得る。これは、多くのソースからの多くのデータを生じる統計的な経済の大きさのためである。このような第三者ＡＡは、典型的には客観的な情報および主観的な情報、データが正確であり有効性が増大する統計的な確率を提供する多くのユーザを有し得る。
【００３２】
さらに、他のパーティに関する情報のより多くのソースは、特定のパーティに関して自身のデータを維持および更新する単一のパーティまたは他のパーティに依存して他のパーティに関する情報を正確に提供する単一のパーティとは対照的に有益である。これは、同一のパラメータに関連付けられたアカウント情報の種々のソースを有し、このソースがアカウント情報の精度に関してチェックを提供するためである。さらに、アカウント情報を維持するビジネスにおける第三者ＡＡは、アカウント情報がアカウント情報をパーティに提供することに関連するパーティに依存することとは対照的に、アカウント情報の信頼性を規則的に収集し、更新し、および維持するための効率的な手順を有する可能性がある。これは、アカウント情報がそれに関係するパーティに負に反映され得る場合、特に真実である。従って、第三者ＡＡによる識別子および公開鍵と関連して維持されたアカウント情報は、他の別個のパーティの周囲にある別個のパーティによって同様に維持されたアカウント情報よりもより正確で信頼性があり得る。
【００３３】
従って、第三者ＡＡは、パーティが他の契約パーティからの情報を収集および更新することに対して責任があるパーティ間シナリオにおけるパーティよりも、アカウント情報の有効性に対してより正確に高い信頼性で保証する位置にある。さらに、正確な手続きの次にデータの信頼性を維持するためのＡＡがある限り、より多くの商取引者またはエンティティが、単一のＡＡクリーニングハウスを有するデータおよびアカウント情報の共有を生じる他の商取引者またはエンティティの間の集合的な関係に進んで参加する可能性がある。さらに、多くの小さな商取引者は、安全なアカウントオーソリティシステムを購入、動作、維持する適切なリソースを有し得ない。
【００３４】
（Ｄ．第４の局面（検証ステータス局面））
ＥＣの送信側のデジタル署名認証を容易にし、識別子および公開鍵に関連付けられたアカウント情報を提供することに加えて、別の局面は検証ステータスインジケータを使用し、メッセージ送信側の意図に関するメッセージを認証し、特定のメッセージをデジタルに署名する。例えば、その署名がメッセージと共に受け取られる場合、ＰｒＫを含むデバイスを使用して、他のメッセージを同様に符号化し得ることが可能である。デバイスは、そのデバイスの所有者以外の者によって獲得されるが、そのデバイスはデジタル署名を送信するためにさらに活性化された場合、デバイスは、連続的にインクリメントされた検証ステータスインジケータをインクリメントして、デジタル署名が用いられて他のメッセージと同様に送信されることを示し得る。このプロセスは、組み込まれたＶＳ出願に詳細に説明される。従って、デバイスがリセットされたため、デジタル署名が他のＥＣに対して検証ステータスインジケータが生成されたことを示す場合、デジタル署名だけは、他の署名がデバイスをリセットした後にインジケータが生成された場合と同様に強く送信側が拘束されることを意図した証書を提供しない。しかし、検証ステータスインジケータは、デジタル署名が別のメッセージに対して生成されていないことを示す場合、受信側は送信側およびメッセージの条件によって拘束されることを意図した送信側の認証を確実にする。
【００３５】
以前の議論は、契約が実施できるか否かの形成要素に集中していた。しかし、実施可能である契約に対して、さらに契約の実施可能性に対する防御の欠如が存在しなければならない。契約が拘束されるべきパーティによって署名されない場合、同意の所定のタイプは、不正取引法によって実施可能ではない。しかし、取引は、商品の販売に関する場合、ＵＣＣは、署名が拘束されるべきシンボルを証明する意図があり得ることを統括し、提供する。
【００３６】
従って、メッセージの送信側を認証することに加えて、組み込まれたＶＳ出願において詳細に説明されたように、メッセージの検証ステータスインジケータは、さらに予め判定されたビジネス法則に従って契約された文書の自動的認証を促進するように使用され得る。例えば、商取引者と標準化された形態との間の契約が使用された場合、パーティの内いずれかは、オファーあるいはこのオファーの元の条件を改変またはこれに追加される受信側において受信された条件の変化のいずれかの受信側を予め認可し得る。受信されたメッセージにおける商品の数量および／または量が所定の閾値よりも低い場合、このメッセージの受信側は、受信コンピュータを予め認可し、そのメッセージに伴う検証ステータスインジケータを評価することによって、オファーまたは修正された条件を自動的に受け入れる。
【００３７】
例えば、受信側がビジネス法則を使用してオファーを受け入れ、所定の商品を販売し、オファーされた数量が５つの部品であり、各部品の価格は＄１０未満である場合、組み込まれたＶＡアプリケーションにおいて、受信側（被提供者）が、任意の秘密または個人の生物学的データ検証を含まないデジタル署名を要求するだけであり得る。しかし、各部品のコストが＄１００よりも高く、および／またはその数量が１０よりも大きい場合、被提供者は、このオファーを自動的に受け入れる前に、オファーを含むＥＣの検証ステータスコンポーネントが、例えばＰＩＮ認証または網膜スキャン検証を含むことを要求し得る。これは、提供者の代理人が、会社に重要な負担をさせない条件に雇用者を拘束し得る。同様に、オファーを受信するエンティティに対する代理人がオファーの受理を予め認可し得、そのオファーの条件は、所定の閾値よりも低い。
【００３８】
しかし、取引の数量および／またはコストが所定の閾値よりも大きい場合、ＥＣの送信側に関連付けられたビジネス法則は、送信側が、メッセージが送信されたことを意図したさらなる補償を要求し得る。これは、秘匿検証データまたは生物学的検証データを使用してＥＣを送信することを示す検証ステータスマーカーの使用によって実現され得る。さらに、検証ステータス局面は、デジタル署名が自動的に署名されるか、または意図を確立し得る署名に関連するいくつかの明示的な人間の行動および明確な人間の行動が存在したかどうかを判定することを容易にする。これは、日常的な販売オファーおよび購入オーダーの同意が上部の管理を伴うことなく発散を可能にし、それにより、日常的な販売オファーおよび購入オーダーは、それらのエネルギーをほとんど日常的ではないタスクに集中させる。さらに、検証ステータス局面もまた、所定のビジネス法則に従って、その環境の安全性における信頼性を評価することを容易にし、その環境において、ＥＣを同時に見て署名する署名エンティティに関してＥＣが署名される。
【００３９】
（Ｅ．第５の局面（ＡＢＤＳなしでＰｕＫにリンクされたデータベース））
この局面は、ＥＣをデジタルに署名するために使用されたデバイスに関する情報を提供することに関する。このデバイスは、典型的には、組み込まれたＰＲｉＭＲアプリケーションにおいて説明されたように、ＥＣに関連してデジタル署名を作成するために使用されたデバイスである。このデバイスは、非対称暗号鍵の対の埋め込まれた秘密鍵と共に製造される。この鍵の対の公開鍵は、安全な環境において格納された安全なデータベースレコードに、関連付けられたデバイス情報と共に格納される。このデータベースレコードは、公開鍵をデバイス情報にリンクさせる。この情報または「セキュリティ特徴」は、例えば、デバイスのタイプ、デバイスが製造されたセキュリティのレベル、どのタイプの検証データが受信可能であるか、デバイスイが、秘密鍵がデバイスの認可された所有者意外の者によって理解されることを保護する程度に関する。デバイス情報（以後「セキュリティプロフィール」と称する）はまた、デバイスおよび／またはそのセキュリティレベルに関連する情報の他の多くのタイプを含み得る。従って、デバイスの所有者からのＥＣの受信側は、安全な環境で動作するエンティティからのデバイス情報を要求し得る。次いで、この情報の受信の際、ＥＣの受信側は、安全なエンティティから受信された情報に基づいてＥＣのデジタル署名の認証を信頼するかどうか判定し得る。これは、１つ以上のパーティが関連する電子契約を有し得るいくつかの関係を有利に取り除く。契約文書を送信するために使用されるデバイスに関連付けられた情報を有することによって、契約パーティは、ＥＣを署名するために使用されたデバイスが高程度のセキュリティを有し、したがってＥＣの送信側が実際にメッセージの送信側であるかどうかを判定し得る。ＥＣとしてデジタルに署名するために使用されるデバイスのプロフィールが高くない場合、または存在しない場合、受信側パーティは、ＥＣの送信側の認証を信頼しないように通知された判定を行い、したがってＥＣの送信側との契約を形成しないように判定され得る。
【００４０】
（Ｆ．第６の局面（ＡＢＤＳなしのＶＳおよびＰＲｉＭＲ））
本発明のこの局面は、上述のように、組み込まれたＶＳおよびＰＲｉＭＲにおいて、検証ステータスインジケータ局面およびセキュリティプロフィール局面の利益を組み合わせる。検証ステータスインジケータ局面およびセキュリティプロフィール局面の組み合わせは、ＥＣの受信側が、ＥＣの送信側を信頼して認証するばかりではなく、高いレベルの信頼性によって、送信側が文書の条件によって拘束されるように意図されたことを判定する。契約文書を含むＥＣを受信する際に、受信側は、ＥＣのデジタル署名を復号化することによってＥＣの送信側を認証する。しかし、デジタル署名を作成するために使用されたデバイスが他の誰かによって使用されないことを確実にするために、受信側は検証ステータスインジケータ局面およびセキュリティプロフィール局面を使用して、ＥＣの送信側が契約書の条件によって拘束されることが意図されるかどうかを判定する。
【００４１】
検証ステータスインジケータが有効な検証データが入力され、デバイスがリセットされてから、デバイスが一回以上使用されてＥＣをデジタルに署名されるかどうかを示す。さらに、セキュリティプロフィール局面は、ＥＣの受信側が、検証ステータスインジケータに含まれた情報の精度および合法性の信頼のレベルを判定することを可能にする。ＥＣをデジタルに署名するために、デバイスのセキュリティプロフィールを要求し、受信することによって、ＥＣの受信側は、デバイスの適切な所有者がデバイスを使用してＥＣをデジタルに署名したことを信じている危険を判断し得る。さらに検証データ（ＰＩＮまたはＢＩＯ）を入力する物理的動作は、送信側を認証する際のさらなる信頼性のファクタとして解釈され得る。なぜなら、検証データは、合法的な送信側が知っているものまたは送信側のことであるためである。あるいは、検証データを入力するための物理動作が、送信側が特定のＥＣのデジタル署名が実行されることを意図したことを認証する際のさらなる信頼性のファクタとして解釈され得る。検証データを入力する物理的動作が、送信側を認証する際の信頼性ファクタおよびＥＣの意図的な署名を確立する際のさらなる信頼性ファクタの両方として解釈され得ることが理解される。
【００４２】
従って、セキュリティプロフィールは、デバイスが厳密な製造プロトコルにおける安全な環境で製造されたことを示し、その結果認証されていない個人またはエンティティが安全な環境を侵略せず、従って、デバイスが製造された場合、秘密鍵を獲得する場合、受信側は、認証されていない個人によって理解されている秘密鍵の可能性がリモートであることを確実にする。さらに、セキュリティプロフィールは、デバイスの抵抗を示し、デバイスのエンジニアリング仕様書において特定化されたような改ざんに対するデバイスの抵抗を示し得る。従って、セキュリティプロフィールは、デバイスが物理的な試みに対して不透過性であり、デバイスを改ざんしてデバイスから秘密鍵を抽出し、その結果デバイスが不正目的のために使用され得る場合、ＥＣの受信側は、ＥＣにおいて識別された個人またはエンティティがＥＣの送信側であることをさらに保証する。従って、重量者と契約しているパーティは、送信側がＥＣに含まれた契約の条件によって拘束されることが意図されたＥＣにおいて識別された高いレベルの信頼性を提供する。この信頼性は、例えば、ＥＣの受信側は、検証ステータスインジケータによって提供された利点を有することなく、ＥＣのデジタル署名のみに依存し、デバイスのセキュリティプロフィールが使用されて、ＥＣまたはその両方をデジタルに署名するシナリオの信頼性よりもより高い。
【００４３】
（Ｇ．第７の局面（個人デバイスおよび安全な入力デバイスＡＢＤＳ））
この局面は安全な入力デバイスを使用する。このデバイスは、その内部に秘密鍵を有し、送信側の個人のデバイスを用いてメッセージを送信する。この個人のデバイスは、別の秘密鍵を有する。さらにこの局面は、組み込まれたＰＲｉＭＲおよびＴＡＤＳアプリケーションにおいて説明され、これらのアプリケーションはまた、Ｉ／Ｏ支援素子として安全な入力デバイスを示す。さらにこの安全な入力デバイスは、ＥＣにおいてデジタル署名を提供することを可能にし、デジタル署名は安全な入力デバイスから送信される。これは、ＥＣの送信側がＥＣに含まれるメッセージに署名するように意図される強力な証拠を提供する。なぜなら、安全な入力デバイスのセキュリティプロフィールは、受信側に、１）検証情報が安全に入力され、個人用のデバイスを通過したこと、および２）メッセージの条件が実際に表示されたことを示し得る。従って、送信側の秘密鍵が、送信側のように見せかけるハッカーによってコピーされ、不正に使用されない、または合法的な送信側の知識なしで任意の他の態様で使用されない保証を受信側に提供する。従って、受信側は安全な入力デバイス（したがって、高いレベルの信頼性を有するＥＣに含まれる送信側およびメッセージ）から受信されたＥＣを認証し得る。
【００４４】
これは、個人のデバイスがＥＣを送信し、実際に署名される内容を見るか、またはそうでなければ気付いている個人またはエンティティなしでＥＣを合法的に署名することが可能であるためである。これは、ＰＣが使用されて文書を体系化し、デバイスがＰＣに取り付けられたカードリーダに挿入される場合に発生する。例えばウイルス、または例えば個人は、ＥＣの内容がＰＣ上に間違って表示させることが可能な場合、送信側は、ＥＣを合法的に署名し、さらにＥＣの検証ステータスインジケータのための有効な検証データを提供し得る。しかし、ＥＣの署名と共に検証データを入力する際に、送信側が明らかな作用を実行しても、送信側は明らかな作用がリンクされたと考えたことと、ＥＣメッセージの実際の内容との間に矛盾があり得る。従って、検証ステータスインジケータが使用された場合であっても、送信側は契約文書にデジタル署名を添付し得、送信側が署名することを意図しない。実際のＥＣが、＄１，０００，０００の転送に同意する条件を含み得る場合、これらは送信側に害を与えるが、ＰＣ画面に表示された文書の条件が＄１０，０００のみであるように見え得る。さらに、受信側は、受信側のＰＣのディスプレイ条件が＄１，０００に対して１００個の部品を出荷する条件である場合、例えば、＄１，０００の価格に対して１，０００個の部品の出荷に同意する条件を含むＥＣを受け取ることによって害が与えられ得る。
【００４５】
従って、安全な入力デバイスまたはＩ／Ｏサポート素子に関連してＥＣをデジタルに署名する意図を示す明らかな作用の結果として検証ステータスインジケータを署名および提供する個人用デバイスを用いることは、ＥＣの送信側がＥＣの実際の内容を証明することを意図した信頼性の高いレベルを提供することによってこの問題を解決する。さらなる信頼性は、安全な入力デバイス有することによって可能になり、またはＩ／Ｏ支持素子（例えばＥｕｒｏｐｅａｎ  Ｕｎｉｏｎ  ＦＩＮＲＥＡＤ規格等）はまた、例えば、安全な入力デバイスが使用された場合、ＥＣを署名する。
【００４６】
（Ｈ．第８の局面（ＶＳ、ＰＲｉＭＲおよびＡＢＤＳ））
この局面は、上述の検証ステータスインジケータの局面、公開鍵にリンクされたセキュリティプロフィールの局面、およびＥＣの送信側およびＥＣにおいて送信されたメッセージを認証する際のアカウント認可局面の上述で議論された利点を組み合わせる。従って、ＥＣの受信側は、送信デバイスの検証ステータス（送信されたＥＣに含まれた）を使用して、ＥＣの送信側の認証における信頼性を高める。さらにこの検証ステータスインジケータを使用して、ＥＣに含まれたメッセージの認証の信頼性およびＥＣの送信側の意図を高め、ＥＣに含まれたメッセージの特定の内容をデジタルに署名し得る。さらに、ＥＣを送信するために使用されたデバイスのセキュリティプロフィールは、ＥＣに、送信側のデバイスＥＣによってデジタルに署名させる際の送信側、メッセージ、および送信側の意図の認証が利用可能である信頼性を高める。さらに、これらの局面は、アカウント認可データベースと組み合わせて使用されて、ＥＣを署名することを意図するものとして認証されてきた者またはエンティティとアカウント情報をリンクする際の信頼性を提供し得る。従って、ＥＣに含まれたメッセージが契約文書であるＥＣの受信側は、送信側のアカウントに対抗して契約文書の内容で動作する際の信頼性を提供する。より詳細には、アカウントホルダを合法化し（例えば、同意することを意図され、ＥＣメッセージの内容に含まれた考慮との同意に基づいて）、アカウントホルダが受信側に支払うことを意図する信頼性を受信側に提供する。
【００４７】
（Ｖ．図面の簡単な説明）
ここで、好適な実施形態が、添付図面を参照して詳細に説明される。
【００４８】
（ＶＩ．好適な実施形態の詳細な説明）
予備的な事項として、本発明は、本発明の好適な方法の以下の詳細な説明に関して広い有用性および用途に影響を受けやすいことが当業者によって容易に理解される。本明細書に記載された以外の多くの方法、実施形態、および適用、ならびに、多くの変動、改変、および等価な構成は、本発明の内容または範囲をから逸脱することなく、本発明によって合理的に提示された説明および以下の詳細な説明から明らかである。従って、本発明は、好適な方法およびシステムに関連して本明細書中でより詳細に説明される。本開示は、例証的かつ例示的であり、単に、全体を提供する目的のため、および本発明の好適な実施形態の開示を可能にするために為されるに過ぎないことが理解される。本明細書における開示は、本発明を限定することを意図するわけでも本発明を限定するために構成されるわけでもなく、あるいはそうでなければ任意のこのような他の実施形態、適用、変動、改変、修正、および等価な構成を排除するために意図され、そして構成され、本発明は本明細書に添付された特許請求の範囲およびその等価物によってのみ限定される。従って、本発明の多くは、コンピュータ、ネットワーク、デバイス、コンピュータチップ、およびトークンに関して、本明細書中で詳細に開示されるが、特定のソフトウエアまたは論理回路が本発明の実施において使用されることが意図されることも必要とされることもない。実際には、特定のビジネスアプリケーションにおいて本発明を実現する場合、適切なコンピュータ、ネットワーク、デバイス、コンピュータチップ、およびトークンを選択することは、通常の記述の事項である。
【００４９】
（各パーティは他のパーティに対してアカウント機関として機能するパーティ間の契約シナリオ）
ここで図を参照すると、図１は、契約に対して２つのパーティを含むシナリオを促進するための典型的なシステム１４０を示す。ネットワーク（好適にはインターネット１０８）が使用され、契約パーティ間のメッセージを送受信し得る。図示目的のために、パーティＡ  １０２ａを提供者と呼び、パーティＢ  １０２ｂを被提供者と呼ぶ。契約に同意すると、特定の取引のためまたは継続中の未来の取引を促進するためのいずれかのため、パーティは公開鍵を交換する。公開鍵は、公開鍵／秘密鍵の非対称鍵の対の各部分である。従って、提供者１０２ａは提供者の公開鍵２８７ａを被提供者１０２ｂに提供し、被提供者は被提供者の公開鍵２８７ｂを提供者に提供する。図の円で囲まれた１は、交換鍵のステップを示す。
【００５０】
提供者１０２ａおよび被提供者１０２ｂの公開鍵は、それぞれデータベース１１４ｂおよびデータベース１１４ａに格納される。これらのデータベースは識別子によってインデックス化され、いずれかのパーティが他のパーティから通信を受信する場合、この識別子に関連付けられた任意のデータは容易にアクセス可能である。この識別子は、典型的には、ステップ１におけるパーティに対応するために作成されたアカウント番号である。例えば、パーティＡ  １０２ａがパーティＢ  １０２ｂと共にアカウントを確立する場合、パーティＢは、アカウント番号をパーティＡに割り当てる。
【００５１】
さらに、データベースを保守するパーティに特有のアカウント情報は、欠くデータベースに格納され得る。このアカウント情報は、主に金融情報（キャッシュアカウントバランス、融資限度等）を含む。しかし、アカウント情報はまた、材料のタイプ、商品、およびサービス等の関係したパーティに関連する種々のデータを含む。このデータにおいて、エンティティは、通常、利用可能な数量、商品および／またはサービスのコスト、潜在的な取引を実行するための能力の他のインジケータを取引する。従って、パーティＡ  １０２ａは、データベース１１４ａにおいてパーティＢ  １０２ｂの識別子およびパーティＢの公開鍵を保守し、関連付ける。さらにデータベース１１４ａは、パーティＡ  １０２ａに関係し、関連付けられたアカウント情報を含み得る。このアカウント情報は、パーティＡ  １０２ａおよびＡの公開鍵に関連するレコードとしてデータベース１１４ａに格納され得る。明らかに、パーティＡ  １０２ａは、この情報自体の知識を得るために、データベース１１４ａからのこの情報にアクセスする必要がないが、この配置は、必要であれば、格納され、そして別のパーティに提供されおよび／または別のパーティにアクセスされるべきアカウント情報のための便利な方法を提供する。パーティＢ  １０２ｂによって保守されたデータベース１１４ｂは、データベース１１４ａの構造と同様な構成の構造を有する。
【００５２】
ステップ１において公開鍵および識別子が交換され設定された後、提供者１０２ａは、提供者のパーソナルコンピュータ（「ＰＣ」）４２８ａ上にオファー１００を被提供者１０２ｂに作成する。ＰＣ４２８ａは、好適な実施形態において使用された、オファー１００を被提供者１０２ｂに送信するためのデバイスのタイプであるが、ＰＤＡまたはこれに類似のデバイス等の他のデバイスもまたオファーを作成および送信するために使用され得ることが理解される。
【００５３】
提供者パーティＡ  １０２ａは、全てのパーティへの通信を送信することを望み得る。提供者パーティＡ  １０２ａは、任意のパーティがパーティＡの要求を満たすことが可能かどうかを判定するための予め存在する関係を有する。この通信は、ステップ１ａにおいて電子メッセージの形態で送信された要求２２７であり得る。この要求（パーティＡ  １０２ａを識別する識別子を含む）に応答して、この例では受信側のパーティＢ  １０２ｂは、コンピュータ４２８ｂを用いた要求を受信し、データベース１１４ｂからの識別子に基づいてステップ１ｂにおいて要求されたアカウント情報を取り出すＡＡ機能を実行する。パーティは、予め存在する関係を有するため、パーティＡ  １０２ａは、パーティＢ  １０２ｂが利用可能である情報のタイプがどれかを知っている。さらに要求メッセージは、パーティＡ  １０２ａの秘密鍵を用いてデジタルに署名され得、そしてこのパーティが予め存在する関係を有しているため、さらにパーティＢ  １０２ｂは、ステップ１ｃにおいて送信された要求への応答２２９をデジタルに署名し得る。
【００５４】
パーティＢ  １０２ｂは、ステップ１ｃにおいてその能力に関する情報を送信して、パーティ１０２ａの潜在的なオファーを満足するが、この情報は、必ずしもパーティＢからパーティＡまでのオファーを構成する必要はないことが理解される。この情報は、パーティＢ  １０２ｂに対するオファーを作成するかどうかを判定することを促進するために、単にパーティＡ  １０２ａに送信されるだけである。
【００５５】
提供者１０２ａがオファーを被提供者１０２ｂに送信する準備ができている場合、提供者は、公開鍵２８７ａに関連付けられた提供者の秘密鍵を含むデバイス４５０ａを使用して、ステップ３において送信されるオファーを署名する。デバイス４５０ａは、図４ａに示されるように、組み込まれたＡＢＤＳアプリケーションの種々のデバイスの内の１つであり得る。図４ａは、秘密鍵を安全に格納するために使用され得る種々のデバイスを示す。提供者１０２ａは、オファー１００を被提供者１０２ｂ２送信する場合、デバイス４５０ａは、ステップ２において提供者のデバイス４５０ａを用いてオファーメッセージをデジタルに署名され、オファーメッセージを電子メッセージに添付され、その電子メッセージは、オファー１００および識別子の主観的な事項を含み得る。組み合わされたメッセージおよびデジタル署名は、ステップ３において、ネットワーク１０８（好適にはインターネット）を介して提供者のコンピュータによって被提供者１０２ｂに送信されたＥＣ２４７を形成する。ＥＣ２４７ａの内容の信頼性が重要である場合、全体のＥＣは、被提供者の１０２ｂ  ＰｕＫ  ２８７ｂを用いて暗号化され、盗聴者がオファーメッセージの内容を聞き分けることを妨害する。
【００５６】
被提供者１０２ｂが提供者１０２ａからＥＣ２４７ａを受信する場合、被提供者のコンピュータ４２８ｂは、ＥＣにおいて受信されたメッセージの一部である識別子に基づいて、ステップ４においてデータベース１１４ｂにおけるテーブルルックアップ機能を実行して、提供者の公開鍵２８７ａを取り出す。これは、被提供者１０２ｂがデジタル署名を検証することを可能にする。検証プロセスが成功する場合、被提供者１０２ｂは、ＥＣ２４７ａにおいてメッセージの送信側を認証した。
【００５７】
一旦、被提供者１０２ｂは、メッセージの送信側が実際には提供者１０２ａを出会ったことが確実である場合、被提供者は、オファーを解析し、そのオファーを受けるか否かを判定する従来のタスクを実行する。この解析は、識別子および公開鍵２８７ａに対応するデータベース１１４ｂから取り出された提供者１０２ａに関するアカウント情報に基づく。
【００５８】
オファーが受け取られた場合、契約が一般的な法律の原則の下で形成される。上述のステップ１ａ、１ｂ、および１ｃと同様に、被提供者１０２ｂは、ステップ４ａにおいて提供者１０２ａから所定のアカウント情報を要求し得る。要求２３７に応答して、提供者１０２ａはＡＡ機能を実行し、ステップ４ｂにおいてデータベース１１４ａから要求されたアカウント情報を取り出し、ステップ４ｃにおいて要求されたアカウント情報を含む応答２３９を被提供者に提供する。要求された情報は、恐らく提供者１０２ａの能力を含み、提供者１０２ｂが債務を実行する場合、バーゲン終了まで実行する。この情報は、典型的には、オファーが商品を購入するオファーであった場合の提供者１０２ａの支払能力、あるいは、オファーが販売契約であった場合の所定の商品を生産する提供者の能力を含む。要求された情報は、提供者１０２ａがステップ３においてＥＣ２４７ａで送信された元のオファーに対する任意の改変を受け取る能力を有するかどうかを含み得る。
【００５９】
被提供者１０２ｂは、オファーを受け取るように判定される場合、被提供者１０２ｂは、そのようにする意思を提供者１０２ａと通信する。一般的には、受理１１０が提供者１０２ａによって受信される場合、契約が形成される。被提供者１０２ｂは、オファー１００を受け取るように判定される場合、被提供者１０２ｂは、ステップ５において被提供者１０２ｂのデバイス４５０ｂを使用して、被提供者１０２ｂがステップ１で提供した公開鍵に対応する被提供者１０２ｂの秘密鍵からデジタル署名を作成する。次いで、ステップ３における提供者１０２ａのように、被提供者１０２ｂは、ステップ６において、メッセージおよびデジタル署名を含むＥＣ２４７ｂを提供者に送信し、メッセージは受理１１０を含む。さらに、メッセージは、書面の契約オファーの確認を含み得る（例えば、提供者１０２ａによって暗号化され得る）。このようなシナリオでは、メッセージは、典型的には、受理と受け取られたオファーとをリンクさせるために、受け取られた特定のオファーを参照する。
【００６０】
提供者１０２ａは、ＥＣ２８７ｂを受信する場合、提供者１０２ａのコンピュータ４２８ａは、ＥＣにおいて受信されたメッセージの一部である識別子に基づいて、ステップ７においてデータベース１１４ａにおけるテーブルルックアップ機能を実行して、被提供者の公開鍵２８７ｂを取り出す。メッセージが信頼性の目的のために暗号化された場合、被提供者１０２ｂによる復号化を必要とする。提供者１０２ａがデータベース１１４ａから被提供者１０２ｂの公開鍵を取り出した場合、被提供者の公開鍵が使用されて、ＥＣ２４７ｂにおいて見出されたデジタル署名を検証し得る。検証が成功した場合、提供者１０２ａが被提供者１０２ｂのようなメッセージの送信側を認証した。従って、契約が提供者１０２ａと被提供者１０２ｂとの間で形成される。
【００６１】
好適には、ステップ８において、提供者１０２ａは、ハッシュ値Ｈａｓｈ（ＭＢ）を生成するために、ＥＣ２４７ｂにおいて被提供者１０２ｂから受信されたメッセージＭＢに関するハッシュ機能およびハッシュ値（ＭＡ）を作成するために、ステップ３において被提供者に送信された元のオファーに関する同一のハッシュ機能を実行し得る。これらのハッシュ値が比較され、これらが同一である場合、提供者１０２ａは、被提供者１０２ｂがオファーされたような同一の条件を受け入れたことを合理的に保証する。もちろん、この比較は、引き受け１０のコンピュータ４２８ａのモニタ上でのレンダリング、またはコンピュータに取り付けられたコンピュータを用いて受理を印刷し、次いで視覚の比較を行う。しかし、ステップ８においてハッシュ値を比較することは、オファー１００および受理１１０における条件の高速および正確な比較を提供する。さらにハッシュルーチンは、他のパーティからの転送の間、メッセージが改ざんされないことを判定するように実行され得る。
【００６２】
（各パーティがアカウント機関として他のパーティに作用するパーティ間のシナリオのための処理）
ここで図２を参照すると、図２は、各パーティがＡＡとして他のパーティに作用するパーティ間契約シナリオを実行する好適な方法のフローチャートを示す。方法プロセスは、２つのパーティがステップ２１００における関係を確立する場合に開始する。関係２１００を確立することは、パーティが互いに契約することを望むパーティ間の議論を含み得る。さらに関係２１００を確立するステップは、互いに情報を交換することを含む。この交換された情報は、識別子、公開鍵、および識別子公開鍵に関連するアカウント情報を含む。この識別子は、公開鍵を処理するパーティがこの鍵の対の相補的な秘密鍵を用いて署名されたデジタル署名を検証し得るように、データベースにおける任意のパーティを電子的に識別するための任意の手段（会社名またはアカウント番号等）であり得る。公開鍵は、非対称暗号化鍵の対の一部である。さらに、データベースにおいて識別子および公開鍵に関連付けられたアカウント情報は、別のパーティがパーティとの契約を開始することを判定する前にパーティについて知ることを望み得る種々の情報を含む。
【００６３】
ステップ２２００では、別のパーティに送信されるべき通信の内容が定式化される。この内容は、契約のオファーまたは契約の受理を含み得る。
【００６４】
通信の内容が定式化された後、ステップ２２００において、別のパーティに送信されるべきＥＣは、ステップ２３００において生成される。ＥＣは、ＥＣの送信側を識別する識別子、ＥＣに送信されるべき内容、およびＥＣの送信側を識別するデジタル署名を含む。ＥＣがステップ２３００において生成された後、ＥＣは、ステップ２４００において送信側によって受信側に転送される。ＥＣは、通信のための種々の通信手段（ローカルエリアネットワーク、インターネット、または他の手段の中でも無線通信リンク）によって転送され得る。
【００６５】
一旦、ステップ２５００において、受信側がＥＣを受信すると、ステップ２６００において送信側が認証される。ステップ２６００における認証は、ＥＣに含まれた識別子を使用して、デジタル署名を検証する際に使用するためのデータベースから公開鍵を取り出すことを含む。一旦、デジタル署名が連続的に検証されると、受信側がＥＣの送信側を認証し、送信側は送信側が送信したと言っている信頼性を有する。さらに、検証ステップ２６００は、ハッシュ値がデジタル署名の一部として送信された場合、ハッシュアルゴリズムを取り出し、そして内容のハッシュを実行し、生じたハッシュ値をデジタル署名の一部として送信されたハッシュ値とを比較する。ハッシュ値が一致する場合、受信側は、ＥＣの内容が内容であり、その内容は、パーティが転送されたＥＣの識別子に関連付けられたことを確実にする。
【００６６】
送信側および内容がステップ２６００において認証された後、識別子を使用して、ステップ２６００において識別子と関連付けられたアカウント情報を取り出す。典型的には、この情報は、送信側が公衆に漏洩されることを望まないＥＣの送信側に関する敏感な情報である。しかし、この情報は、送信側が契約することを望む受信側が送信側と取引を開始する前に要求する情報であり得る。アカウント情報はステップ２８００において受信側によって解析され、ＥＣの内容に対してどのように作用するかを判定する。例えば、ＥＣが所定の価格で商品の数量を購入するオファーを含む場合、受信側は、送信側が送信側に商品を売却することに同意する前に商品に対して支払う能力を有するかどうかを判定することを望み得る。そうでなければ、受信側は、商品を送信側に売却するように約束し、商品を送信側に出荷し、そしてＥＣの送信側は、キャッシュフロー問題のために、約束したようにその商品に対して支払わない場合、ＥＣの受信側は、出荷された商品の価を損失してしまった。さらに、ＥＣの受信側は、その商品に対して支払うことができた別のパーティにその商品を売却する機会を失ってしまい得る。従って、ステップ２８００において、アカウント情報の解析は、ＥＣの受信側に対するインテリジェンスを提供する。このインテリジェンスが使用されて、ＥＣの受信を可能にすることによってＥＣの内容に含まれたオファーを受け取るリスクを低減し、ＥＣの送信側が送達に応じて商品に対して支払う可能性の教育された判定を行い得る。
【００６７】
識別子に関連付けられたアカウント情報の解析がステップ２８００において実行された後、ステップ２８００において実行された分析の結果として獲得されたインテリジェンスはステップ２９００において適用され、そのオファーを受理するかまたは拒絶するかどうかを判定する。このオファーの拒絶または受理がステップ２９００において為されたかどうかに関する判定は、ステップ２９００において為された後、ＥＣの受信は、ステップ２９５０においてオファーを受理または拒絶するによって行われる。次いで、ステップ２６００において送信側およびメッセージを認証するために使用された識別子および公開鍵に対応する、任意の以前に格納されたアカウント情報がステップ２９６０において更新される。ステップ２９６０におけるこの更新は、販売者が示した商品の数量を低減することは購入者に利用可能であり、販売者が以前に購入者に対して利用可能にした信用限度額を低減することを含み得る。
【００６８】
ＥＣに含まれた内容がオファーであった場合、受信側は、オファーを受信することを望み得る。受理は、被提供者または商品の販売者からの第２のＥＣを提供者または元のＥＣの送信側に送信することを含む種々の態様において為され得る。従って、第１のＥＣの受信側は、別のＥＣを定式化してステップ２９７０において提供者に送信することを判定し得る。被提供者から提供者に送信されたＥＣは、ステップ２２００〜２４００において示されたプロセスに従うことによって定式化され、生成され、および転送される。受理が別のＥＣとして送信された場合、受理ＥＣの受信である提供者は、ステップ２５００および２６００に従い、被提供者が引き受けを送信し、オファーの条件が、上述のように転送されたＥＣの内容に関するハッシュルーチンを実行することによってもとのオファー条件に対して修正されないことを確認する。ステップ２９５０においてＥＣの形態で受理を送信する代わりに、被提供者は、単に受理を構成するために商品を出荷するだけであり得る。ステップ２９５０における判定がオファーを拒絶する場合、被提供者はＥＣを提供者に送信し得、ＥＣの内容は、拒絶を伝達する「Ｉ  ｄｅｃｌｉｎｅ」またはいくつかの同様のテキストを開始するテキストメッセージである。
【００６９】
例示の目的のために、部品を製造し、そして売却するビジネスのベンダーが考慮される。ステップ２５００において、ベンダーがオファーを受け取り、１０，０００の部品を商取引者から購入するオファーを受け取る場合、オファーを受理し、部品を商取引者に出荷することに同意する前に、支払を得る可能性を判定することを望み得る。従って、ステップ２７００において取り出されたアカウント情報は、信用限度額、受信可能なアカウント、支払可能なアカウントおよび支払履歴等のベンダーに対して商取引者に関する情報を含み得る。随意に商取引者は、また商取引者（ベンダーとは無関係の）に関する敏感な情報および秘密の情報（利用可能なキャッシュ、受理可能なアカウント、支払可能なアカウント、および支払履歴の等）を典型的に暴露するように選択し得る。これらの情報は、他のベンダーへの支払および他のベンダーが、商取引者に支払を催促するために収集代理人を雇う必要があるかどうかのタイミングを含む。この商取引者は、例えば、ベンダーが、商取引者との項使用に同意する前にこのような情報を要求する場合、ベンダーの要求においてベンダーにこのような情報を提供することを選択し得る。従って、意味のある解析が実行されて、商取引者がステップ２８００において部品に対してベンダーに支払う可能性を判定する。このような判定を行うためのプロセスは、このような判定が、ビジネスの本質にかかわらず、ビジネスに従事した者によって日常的に為される者として当業者に公知である。
【００７０】
ステップ２８００において、ベンダーが商取引者のアカウント情報を分析した後でベンダーは、ステップ２９００において商取引者から受信されたオファーを受け取るかどうかを判定し得る。ベンダーがオファーを受け取ることを望む場合、ベンダーは、ステップ２９５０においてＥＣを商取引者に送信する。ＥＣは、ベンダーの識別子、上述のように形成されたデジタル署名、およびオファーに含まれた内容を含む。あるいは、提供者に送信されたＥＣは、このオファーの元の内容のテキストではなく、簡単なテキストメッセージ「Ｉ  ａｃｃｅｐｔ」を含み得る。しかし、不正な再生攻撃を防止するために各「Ｉ  ａｃｃｅｐｔ」は、好ましくは特定のオファー（元のオファーのＳＨＡ−１ハッシュを用いることによって）を参照する。
【００７１】
受理を含むＥＣの送信に応じて、ベンダーは、ステップ２９６０において商取引者に関するアカウント情報を更新する。この例では、ベンダーは、利用可能な部品の数量を低減して、１０，０００だけ商取引者に販売する。受理可能なアカウントは、出荷された１０，０００個の部品のコストによって増加される。ベンダーから商取引者に拡張された信用限度額がコスト額によって低減され、ベンダーへの商取引者の支払可能なアカウントは、同じアカウントによって増加される。
【００７２】
ベンダーから商取引者に送信されたＥＣは、オファーの受理を構成し、商取引者は、この受理を受け取るプロセスから始まる。ステップ２５００における受理の受信に応じて、商取引者は、ステップ２６００において受理ＥＣの送信側を認証する。この認証は、受理ＥＣに含まれる内容のハッシュを随意に実行して、オファーの任意の条件が受理によって修正されるかどうかを判定する。あるいは、「Ｉ  ａｃｃｅｐｔ」のような簡単なメッセージが受理の内容として送信された場合、受理ＥＣはまた、オファーＥＣの一部であった元のハッシュ値を含み、上述のように受け取られた条件を確認し得る。
【００７３】
ステップ２５００において受理の受信の際に、商取引者が識別子を使用してベンダーの公開鍵を取り出し、デジタル署名およびベンダーの好適なハッシュルーチンを復号化し、必要であれば、商取引者がステップ２６００において条件が受理によって修正されたかどうかを確認する。次いで、ステップ２７００において、商取引者が識別子を使用して任意の利用可能な関連付けられたアカウント情報を取り出し、ベンダーの能力を解析して実行し得る。この情報は、例えば、ストックにおける部品の数量、月間生産能力、送達されたタイミングおよび数量に関する送達履歴、任意の品質格付けを含み得、ベンダーの商品を購入した他の商取引者によって標準化されたスケールにおいて為されてきた。
【００７４】
最後に、別のＥＣを送信するかどうかの判定がステップ２９７０において為された。ＥＣは、図１に示されるように受理１１０の受信側および提供者１０２ａからの別のオファーを確認し、次いで、ＥＣは、上述のプロセスの関連したステップを繰り返させる。
【００７５】
（購入オーダービジネスシナリオ）
図３を参照すると、図３は、例示によって、商取引者間のシナリオにおいて典型的である場合の、ビジネス法則が商品のオーダーを自動的に受理または拒絶するように使用される契約シナリオを促進するためのシステム１４２を示す。システム１４２は、ネットワーク（好適にはインターネット１０８）を使用して、契約パーティ間にメッセージを転送および受信し得る。例えば、ビジネス２０２に対する購入代理人２０２ａは、目録を獲得し、ペンおよび紙のビジネス２０２の供給が低いことを判定する。さらに、ビジネスは、デスクおよびコンピュータを必要とする新しい従業員を１０人だけ雇う。従って、購入代理人２０２ａは、オフィス供給会社２０３からアイテムを購入することを判定する。ビジネス２０２は、円で囲まれたステップ１において作製された既存のアカウントを有する。
【００７６】
ステップ１において、代理人２０２ａの識別子および公開鍵、代理人のマネージャ２０２ｂ、および供給会社２０３が交換される。この識別子は、名前によって人またはエンティティを識別し得るか、あるいは、好適には、識別子は所与のパーティに関連付けられたアカウント番号であり得る。さらに、アカウント情報は、識別子および公開鍵のそれぞれに関連付けられる。例示的なシナリオでは、典型的には、アカウント情報は商品のタイプを含み、代理人２０２ａまたはマネージャ２０２ｂのいずれかは、ビジネス２０２によって購入することが認可される。さらに、アカウント情報はまた、代理人またはマネージャが購入することが認可される商品のドル額を含む。さらに、アカウント情報は信用限度額を含み得、ビジネス２０２は供給会社２０３を有する。さらに、代理人２０２ａまたはマネージャ２０２ｂのいずれかが消費する認可された額と共にこの信用限度額が付与され得る。その結果、全体の信用限度額が認可された額よりも小さい場合、代理人もマネージャもビジネス２０２に対する利用可能な信用限度額よりも多ク購入し得ない。
【００７７】
パーティ間の初期セットアップおよび情報交換によって、代理人２０２ａは必要な商品を購入するための購入オーダー（「ＰＯ」）２００を作成する。ＰＯ２００は、ＥＣ３４７ａに変換され、これは、識別子、ＰＯ内容、およびＰＯのデジタル署名を含み、これは、ステップ２においてデバイス４５１ａからの代理人の秘密鍵を用いて生成される。ＥＣ３４７ａは、ステップ３において転送される。供給会社２０３がＥＣ３４７ａを受信する場合、ステップ４において、供給会社２０３は、識別子を使用してビジネス２０２の購入代理人２０２ａの公開鍵３８７ａを取り出す、公開鍵３８７ａを使用して、送信側購入代理人２０２ａを任所定する。次に、識別子が使用されて、オフィス供給会社２０３のアカウント情報を取り出し、このアカウント情報がこの会社の購入代理人２０２ａに対応する。
【００７８】
例示的なシナリオの目的のために、購入代理人２０２ａは、＄２５０未満の低コストアイテム（すなわち、紙、ペン、書類クリップ、留め金等の日常的に補給を要する消耗品）を購入するように認証されただけである。さらに、以前の購入により、信用限度額は、ビジネス２０２に関連した者に対して２３７＄のみである。さらに、ビジネス２０２は、購入代理人２０２ａに認証されておらず、比較的高価なアイテム（事務用什器およびコンピュータ装置等）を購入する。これらのパラメータは、図３におけるデータベース２１４ｂの展開図において詳細に示されるように、本例では「ビジネス法則」と呼ばれる。
【００７９】
従って、供給会社２０３のコンピュータ５２８ｂは、アルゴリズム２０５を使用して、購入者の代理人２０２ａの識別子および公開鍵に関連付けられたアカウント情報データに含まれたビジネス法則に従ってアカウント情報を解析する。購入者の代理人の識別子に従ったビジネス法則の解析は、デスクおよびコンピュータの出荷を不可能にする判定を生じる。従って、ペンおよび紙のコストは２３７未満であることを仮定すると、事務用供給会社２０３は、ステップ５におけるＰＯ２００に従って、ビジネスに対する紙およびペンの出荷に同意し、これらの出荷を行う。この部分的な性能はＰＯ２００の受理を構成し、供給会社２０３からビジネス２０２に送信される別のＥＣ３４７ｂの形態で請求書によって添付され得る。
【００８０】
次いで、ビジネス２０２は、ＥＣ３４７ｂにおける識別子を用いることによって送信側を認証し、ステップ１において受信された供給会社２０３の公開鍵を取り出し、ＥＣのデジタル署名を復号化する。次いでステップ７において、この識別子を使用して、データベース２１４ａにおける供給会社の識別子に関連して格納されたアカウント情報から保管アカウント番号を取り出す。次いで、この保管アカウント番号は、ステップ６において受信されたＥＣ３４７ｂにおいて含まれた請求書に対する支払を行うために使用され得る。
【００８１】
この例におけるビジネス法則は、全体のコストが＄１０，０００未満である場合、マネージャ２０２ｂがデスクおよびコンピュータをオーダーすることを可能にすることに留意されたい。しかし、ビジネス２０２と提携した者に対する信用限度額が＄２３７のみであったため、信用限度額の観点からビジネス法則の解析は、事務用什器に対するオーダーの実行を可能にしない。
【００８２】
（購入オーダーのビジネスシナリオのためのプロセス）
ここで、図４を参照すると、図４は、ＥＣにおいて受信されたオファーを自動的に受信するためのビジネス法則を実現するためのステップを示す。このプロセスは、ある関係がオファーの意図された受信によって構築されることによってステップ４０５０において開始する。提供者の従業員は、エンティティまたは商取引者によってインデックス付けされたデータベースにアクセスすることによってこの判定を行い得る。ある関係が構築されない場合、その関係がステップ４１００において構築される。この構築は、アカウント番号、未来の契約を容易にするために使用される識別子およびアカウント情報に関連付けられた公開鍵を含む。
【００８３】
ある関係が構築された後、購入代理人は、ステップ４２００において、オーダーされるべきアイテムを判定し、そこからＰＯを生成する。このＰＯは、ステップ４３００においてＥＣに変換され、そのＥＣは、ＰＯ、代理人識別子、およびＰＯのデジタル署名を含む。ＥＣは、ステップ４４００において受信側に送信され、ステップ４５００において受信側によって受信される。
【００８４】
ＰＯ、ＥＣの受理の際、受信側によって駆動されたコンピュータは、ＥＣから識別子を自動的に抽出し、データベースから関連付けられた公開鍵を取り出して、ステップ４６００においてデジタル署名を検証する。送信側の成功した認証に応じて、受信側のコンピュータは、ステップ４７００において、識別子に関連付けられたアカウント情報を取り出し、ステップ４８００において、アカウント情報に含まれたビジネス法則を使用して、ＰＯの条件を解析する。
【００８５】
ビジネス法則の解析に基づいて、受信側のコンピュータは、ステップ４８２０においてＥＣがＰＯであったことを自動的に判定し、ステップ４８５０において、ＰＯ  ＥＣに含まれた識別子に関連付けられた出荷アドレスに商品を出荷するかどうかを判定する。コンピュータは、商品が出荷されることを自動的に判定する場合、ステップ４９００において商品が自動的に出荷される。商品の性質に依存して、コンピュータは、ステップ４９００において、自動的な倉庫設備を管理して、商品を識別し、その商品を適切な出荷コンテナに配置して、出荷ラベルを用意し、従来の配達サービスによる集荷のために包装された商品を運搬（ｓｔａｇｅ）する。あるいは、その商品がソフトウエアまたは他の電子情報である場合、その商品が集荷されて、ＰＯ  ＥＣに含まれた識別子に関連付けられたアカウント情報を更新する。商品が集荷された場合、ステップ４９００においてコンピュータは、識別子に関連付けられたアカウント情報を更新する。この更新ステップは、ステップ４９００において出荷された商品のコストに等しい量によって、購入者の信用限度を低減することを含む。次いで、コンピュータは、ＥＣにおける請求書を電子的に生成し、ＰＯ  ＥＣに含まれた識別子に関連付けられたアカウント情報において特定されたように電子メールアドレスに送信し得る。さらに、請求書は、ステップ４９５０において調整されたような修正された信用限度に基づいてアカウントの計算書を含み得る。
【００８６】
（第三者ＡＡを使用するシナリオ）
ここで、図５を参照すると、図５は、第三者を使用してその第三者に公開鍵を保守し、この鍵を他の情報に関連させ、この他の情報は、識別子およびアカウント情報を含み、ネットワーク（好適にはインターネット１０８）を使用して、契約パーティ間でメッセージを転送および受信するように使用され得る契約シナリオを促進するためのシステム１４４の実施形態を示す。このプロセスは、図１に示されたパーティ間シナリオにおけるように、ステップ１において各非対称鍵の対から契約パーティの公開鍵を提供する契約パーティから開始する。しかし、このパーティは、交渉プロセスが開始する前に、公開鍵およびアカウント情報を互いに直接的に提供しない。
【００８７】
むしろ、提供者１０２ａは、提供者の公開鍵２８７ａを第三者ＡＡ１５０に提供し、次いで、ＡＡ１５０は、提供者がアカウント機関に提供者１０２ａの公開鍵２８７ａを他のパーティに提供するように命令または許可する場合、提供者１０２ａの公開鍵２８７ａを他のパーティに提供し得る。同様に、このステップにおいて、被提供者１０２ｂは、被提供者の公開鍵２８７ｂをアカウント機関１５０に提供する。従って、提供者１０２ａがオファー１００を作成および送信する場合、被提供者１０２ｂとの契約は要求され得ない。
【００８８】
さらに、各パーティは一般的に、各パーティが通常取引する商品のタイプ、材料またはサービスのような各パーティのビジネス、保管されているアイテムの数量および価格、クレジットの支払履歴、および預金残高等のような契約パーティに関連し得る他の情報に対して、アカウント情報２８９をＡＡ１５０に提供する。従って、ステップ１において、各パーティ（ＡＡによって登録された自然人またはエンティティ）を識別するエンティティがＡＡに登録する場合、ＡＡ１５０によってデータベース１１４において保守された情報がＡＡによって生成された識別子２８５を含む。さらに、データベース１１４は、識別子２８５のそれぞれによって関連付けられた公開鍵２８７および種々のアカウント情報データ２８９を含む。
【００８９】
提供者１０２ａは、提供者がオファー１００を作成し、オファー１００を被提供者１０２ｂに送信することを望むいずれかのエンティティを判定することのみを必要とする。オファー１００は、提供者のＰＣ４２８ａからＥＣ２４７ａとして送信され、ＥＣ２４７ａはインターネット１０８の一部である。ＥＣ２４７ａは、メッセージ、アカウント識別子、およびデジタル署名の形態でオファー１００を含む。ＥＣ２４７ａは、ステップ２においてデバイス４５０ａによって生成される。デバイス４５０ａは、組み込まれたＶＳ出願に開示されおよび図４に示されたようなデバイスである。ＥＣ２４７ａは、ステップ３において被提供者に送信される。
【００９０】
被提供者１０２ｂは、オファー１００を受信して、識別子を用いる代わりに、提供者１０２ａの公開鍵２８７ａを参照する。被提供者は、ステップ４において、アカウント機関１５０に要求を送信する。この要求は、ＥＣ２４７ａにおいて見出された識別子をメッセージとして含む。ＥＣ２４７ａは、ステップ３において提供者１０２ａから受信される。次いでアカウント機関１５０は、ステップ４において受信された識別子に基づいて、ステップ５においてデータベース１１４におけるテーブルルックアップ機能を実行し、識別子２８５に対応する公開鍵２８７ａを受信する。次いで、アカウント機関１５０は、取り出された公開鍵２８７ａおよび関連付けられたアカウント情報を被提供者１０２ｂに提供する。
【００９１】
被提供者１０２ａの公開鍵２８７ａおよびアカウント情報２８９の受信において、被提供者１０２ｂは、次いでオファー１００を解析し、オファー１００を受け取ったかどうかを判定する従来のプロセスを実行する。被提供者１０２ｂは、オファー１００を受け取るように選択する場合、受理１１０は、提供者１０２ａに送信される。受理１１０は、ＥＣ２４７ｂとして被提供者のＰＣ４２８ｂから送信され、被提供者のＰＣ４２８ｂは、インターネット１０８に接続される。ＥＣ２４７ｂは、メッセージおよびデジタル署名の形態で受理１１０を含み、そのデジタル署名は、ステップ６においてデバイス４５０ｂによって署名される。デバイス４５０ｂは、組み込まれたＶＳ出願に開示されおよび図４に示されたようなデバイスである。ＥＣ２４７ｂは、ステップ７において提供者１０２ａに送信される。
【００９２】
被提供者１０２ａは、受理１１０を受信して、識別子を用いる代わりに、図１に示されるように、被提供者１０２ｂの公開鍵を参照する。提供者は、ステップ８において、アカウント機関１５０に要求を送信する。この要求は、ステップ７において被提供者１０２ｂから受信されたＥＣ２４７ｂにおいて見出された識別子を含む。次いでアカウント機関１５０は、ステップ８において受信された識別子に基づいて、ステップ９においてデータベース１１４におけるテーブルルックアップ機能を実行し、関連付けられた公開鍵２８７ｂおよびアカウント情報を取り出す。次いで、アカウント機関１５０は、取り出された公開鍵２８７ｂを、被提供者１０２ｂを認証するために提供者１０２ａに提供する。
【００９３】
図５を続けて参照するが、上述の図１の議論と同様である。提供者１０２ａは、元のオファー１００の条件がステップ７において被提供者１０２ｂから受信された受理１００によって修正されないことを確認することを望み得る。従って、提供者１０２ａは、ステップ８において被提供者１０２ｂからＥＣ２４７ｂにおいて受信されたメッセージＭＢに関するハッシュ機能を実行して、ハッシュ値（ＭＢ）を生成し、ステップ３において被提供者に送信された元のメッセージの同一のハッシュ機能を実行して、ハッシュ値（ＭＡ）を生成し得る。このハッシュ値が一致する場合、提供者１０２ａは、この条件が変更されなかったことがかなり確実になる。
【００９４】
図１と共に説明された実施のように、提供者１０２ａまたは被提供者のいずれかは、他のパーティまたは複数のパーティに関連付けられたアカウント情報を要求し得る。この情報は、契約プロセスの種々の局面において支援するように使用される。例えば、提供者１０２ａは、まずオファーを作成するために考慮する場合、提供者１０２ａは、要求クエリをＡＡ１５０に送信して、ＡＡに登録される全ての他のパーティを見出し得、そのＡＡは、恐らく被提供者１０２ｂであり得る。すなわち、提供者が考慮する商品またはサービスの取引は契約の内容である。これは有用な特徴である。なぜなら、パーティ間に直接的に予め存在する関係が要求されないためである。要求された全ては、パーティがＡＡ１５０に登録されることである。アカウント情報２８９は、データベース１１４に格納されるため、当業者に公知の標準的な検索（キーワード検索等）が恐らく被提供者１０２ｂのリストを生じる。
【００９５】
しかし、データベース１１４におけるアカウント情報は、単にそれに関係する企業の一般的な性質に関連した公正な情報を提供するだけではない。さらにアカウント情報２８９は、所与の企業が、典型的には公知であることを望まない金融データおよび他の敏感な戦略的データを含む。従って、アカウント情報は、ＡＡ１５０に登録されるリクエスタに提供されるのみであり、アカウント情報はデジタル署名と共に要求を送信する。さらに、所与のエンティティは、その敏感な情報が暴露される前に、要求されたセキュリティのレベルに関する制限を設け得る。この機能は、敏感な情報が関係するパーティによって予め判定されたビジネス法則を実現する検証ステータスインジケータおよびアルゴリズムの使用によって達成され得る。
【００９６】
例えば、エンティティは、種々の消費者に販売される、低コストの商品および／またはサービスで取引する場合、そのエンティティは、単に消費者、顧客、またはエンティティ認証を必要するだけである。しかし、エンティティが高価なアイテムまたは長い誘導時間（ｌｅａｄ−ｔｉｍｅ）を要求するアイテムで取引する場合、エンティティは、高いレベルの認証信頼性を必要とし得る。そして、エンティティが高い競争力のあるマーケットで取引され、コンピュータによるエンティティ金融能力または生産能力の知識は、競争者がエンティティへの厳しい損害を引き起こすことを可能にする場合、情報が考慮された契約交渉において公表される前に、エンティティは、情報に対するセキュリティの最も高いレベルを要求し得る。これは、アカウント情報の受信側は、非開示同意（「ＮＤＡ」）の形態として実現され得、そのため情報が機密的であり、契約交渉および取引の目的のために提供されるのみである。リクエスタの認証に関して、最も高いレベルの機密性を要求することによって、ＡＡ１５０は、リクエスタがＮＤＡに同意したレコードを生成し、情報がリクエスタ以外の者に何とか公知になる場合、ＮＤＡは、リクエスタがＮＤＡに違反する証拠として使用され得る。従って、パーティは、情報が契約に関して真剣である別のパーティによって使用され、同時に関連する情報をより多くの潜在的顧客に提供し、ビジネスのパーティの量が増加することを確実にする。
【００９７】
第三者ＡＡモデルは、警告をアカウント情報に関連付け得る。この第三者ＡＡモデルは、アカウント情報をそのアカウント情報が有効であり得ない要求しているパーティに提供する。例えば、第１のパーティは、支払可能な＄５０，０００を有するように主張する場合、商品またはサービスを第１のパーティに販売した他のパーティが、＄５０，０００より大きい第１のパーティから受信可能なアカウントを有する。従って、支払可能な情報が正確ではあり得ない「領収書のない（ｎｏ  ｖｏｕｇｈ）」警告は、特定の識別子およびその対応する公開鍵に関連付けられたアカウント情報に含まれ得る。
【００９８】
さらに図５を参照して、別の例示的な例では、商取引者は、部品を作成するために使用されたレバーの所定のタイプ特定の品質をオーダーすることを望み得、商取引者は、所定の時間だけ部品を必要とし、所定の額を支払う準備ができているのみである。潜在的な購入者は、そのオーダーを十分満たすことが可能であり、または潜在的な購入者の要求を部分的に満たすことが可能であるＡＡに登録された全てのベンダーの識別に対して要求を第三者パーティＡＡに送信し得る。ＡＡに登録された１対上のベンダーは、いくつかまたは全ての購入者の要求を満足する場合、ＡＡは、各識別子に関連付けられた公開鍵およびアカウント情報と共に要求しているパーティにベンダーの識別子を戻す。次いで、購入者／リクエスタは、アカウント情報を解析して、オファーを作成してベンダーから材料を購入するかどうかを判定する。アカウント情報は、購入者の全ての要求が単一のベンダーによって実施され得ることを示す場合、購入者は、１人のみのベンダーへのオファーを作成し得る。一人のベンダーがいくつかの要求を実施し、他人は他の要求を実施し得る場合、購入者は、複数のオファーを作成することを望み得、各オファーは、所定の実現要求に向けられる。さらに、購入者は、他のベンダーに為された他のオファーの成功した受理に応じて偶発的な条件付オファーを作成することを望み得る。
【００９９】
従って、本質的には、第三者ＡＡは、少なくともアカウント情報が正確にＡＡに提供される程度まで、要求しているパーティによって要求された所定の要求を実施するようにパーティの能力を「保証する」。従って、要求しているパーティは、オファーがオーダーを実施することが不可能であり、またはこれを実施することを望まないパーティに作成され、このパーティがもはや不可能になるまで、実施することができるパーティに作成されない。
【０１００】
システム１４４の代替的な実施形態では提供者１０２ａは、ステップ３ａにおいて第三者ＡＡを介して、オファーＥＣ２４７ａを被提供者１０２ｂに送信し得る。これは、送信されたＥＣのみであり得るか、被提供者１０２ｂに直接送信されたＥＣのコピーであり得る。送信されたオファーＥＣのみである場合、第三者パーティＡＡ１５０は、関連付けられたアカウント情報２８９および提供者１０２ａに関連付けられた公開鍵２８７と共に被提供者１０２ｂに送られ得る。この提供の１つの利点は、ＡＡ１５０がオファーＥＣを被提供者１０２ｂに転送する前に、オファーＥＣ２４７ａ上に時間日付スタンプ１０５を添付し得ることである。あるいは、システム１４４は、オファーＥＣ２４７ａが被提供者１０２ｂに送信されたと同時にコピーがＡＡ１５０に送信されるように構成される場合、ＡＡ１５０は、時間日付スタンプをそのコピーに添付し、時間日付スタンプされた添付されたオファーＥＣのコピーを被提供者１０２ｂに送り得る。受理ＥＣをＡＡ１５０に送信する同じプロセスは、ステップ７ａへと続き得る。従って、システム構成にもかかわらず、ＡＡは、オファーおよび受理文書上に時間日付スタンプを配置し、文書が送信される時に文書化の利益を提供する。これは、例えば、ビッドのタイミングが重要なオンラインオークションサービス等の種々のシナリオにおいて有用であり得る。時間日付スタンプを安全に添付することは、また各オーダおよび至るところに発生し得る活動に関する元のイベントの順序またはオーダーを確立するために有用であり得る。
【０１０１】
（第三者ＡＡを用いるシナリオのためのプロセス）
ここで、図６を参照すると、図６は、契約シナリオを促進するための第三者ＡＡを用いるためのプロセスのステップを示す。このプロセスが開始する場合、第１のステップは、ステップ６０５０においてある関係が契約パーティ間の間に存在するかどうかを判定することである。ある関係が存在しない場合、ある関係に対するパーティがステップ６０７５において存在する。このある関係の形成は、パーティ間の契約を形成することに対する情報を提供することによって達成される。パーティは、ある関係を形成することを望むパーティ間で通信する必要がないことが理解される。ＡＡに登録し、ＡＡに関連するアカウント情報を提供することによって、契約の形成を構成する。なぜなら、１つのパーティによって提供された情報のタイプは、別のパーティが２つのパーティ間の以前の通信をすることなく第１のパーティにオファーを作成することを可能にする。
【０１０２】
この関係が情報をＡＡに提供することによって形成された後、次のステップは、オファーがステップ６１００において作成されるべきかどうかを判定することである。オファーが作成されるべきではない場合、次のステップは、以前に送信されたＥＣへの受理がステップ６１１５において作成されるかどうかを判定することである。取るべき作用がステップ６１００においてオファーであるように判定された場合、次のステップは、ステップ６１２５において潜在的な被提供者を検索するかどうかを判定することである。提供者が契約を望むビジネスのタイプに含まれる１人以上の商取引者を検索するステップを含む。従って、パーティのビジネスおよび製品に関する情報は、ＡＡに登録される全てのパーティから潜在的な被提供者の数を少なくすることに役立つ。提供者は、特定のパーティへのオファーを作成する場合、このプロセスは、ステップ６３０に進む。このステップは、提供者が既知のパーティーへのオファーを作成することを判定する。提供者がＡＡに登録された全ての潜在的なパーティを検索することを望む場合、提供者は、ステップ６１５０における提供者の必要性を満たし得る全パーティの検索を開始する。上述したように、この検索要求は、ステップ６１７５において、ＡＡが識別子およびデジタル署名を用いて送信側を認証する受信の際にＥＣの形態でＡＡに送信される。ステップ６２００において、ＡＡは検索を実行し、要求している提供者に対する結果を送信する。ステップ６２２５において、この結果を受信する際に、提供者は、検索結果ＥＣの送信側を認証し、次いでステップ６２５０においてデジタル署名を検証する。
【０１０３】
検索結果の一部として送信された情報が、典型的には、この検索結果において戻されたエンティティの銀行残高として敏感な情報であるために、ＡＡは、ステップ６２５において、その結果の受信側／提供者が電子非開示同意（「ＮＤＡ」）をデジタルに署名することを要求し得る。ＮＤＡが要求されない場合、プロセスはステップ６３５０に進む。ステップ６２７５において、ＮＤＡが要求される場合、ステップ６３００において、デジタル署名を有するＥＣをＡＡに送信し、ステップ６３００と同様に確認することによってＮＤＡの条件に同意しなければならない。ＮＤＡ確認の受信によって、ＡＡは、ステップ６３２５における検索結果を伴う敏感な情報を公表する。
【０１０４】
次いで、提供者は検索結果を解析し、もしあれば、ステップ６３５０においてどのパーティがオファーを作成するかを判定する。一旦、１以上の被提供者パーティが判定されると、提供者がステップ６３７５においてＥＣを生成する。このＥＣは、オファーの内容（すなわち条件）を含み、デジタル署名および識別子を含む。このパーティは、ステップ６４００において１以上のパーティに転送され、ステップ６２４５において受信側によって受信される。ステップ６２４５においてオファーＥＣの受信の後、受信側／被提供者は、ステップ６４５０において提供者の公開鍵およびそれに関連付けられたアカウント情報を要求しているＡＡにＥＣを送信する。次に、ＡＡは、ステップ６４７５において送信側／被提供者を認証する。図５に示されたシステム１４４は、ＡＡを介して被提供者パーティにＥＣを送信するように構成される場合、プロセスは点線によって示された経路を進み、ＡＡは、ステップ６４３５においてＥＣの識別子に基づくＰｕＫを取り出す。従って、受信側／被提供者は、ステップ６４５０において送信側のＰｕＫおよびアカウント情報を要求することを有さない。なぜなら、この情報は、システム１４４がこれに従って構成される場合、ＥＣと共に到着するためである。
【０１０５】
ＡＡがステップ６４７５において受信側／被提供者を認証した後、ステップ６５００において、ＡＡは、提供者の公開鍵および提供者の識別子に関連付けられたアカウント情報を送信する。しかし、図５を参照して説明されるように、システム１４４は、ＡＡを介して提供者から被提供者に送信するように構成される場合、ステップ６５１５において、ＡＡは、提供者の公開鍵、アカウント情報、およびＥＣに転送されたアカウント識別子を被提供者に送信する。従って、システム１４４は、これに従って構成され、提供者の公開鍵、アカウント情報、およびアカウント識別子の別々の転送が必要とされない。従って、システム１４４が構成された場合、ステップ６５００は迂回される。
【０１０６】
次に、ステップ６５２５において、被提供者は提供者に関連付けられた公開鍵およびアカウント情報を受信して、オファーの送信側を認証する。このオファーを受け取るために契約するのは誰かを知るために、被提供者は送信側が誰であるかを知っているだけでなく、オファーの送信側および内容は、さらに提供者が実際にこのオファーを作成することを示すように証明が以後必要とされる場合に被提供者によって保持される。提供者の成功した認証に関して、ステップ６５５０において、被提供者はオファーの条件およびそれに関連付けられたアカウント情報を解析して、オファーを受け取るかどうかを判定する。提供者を認証するために使用されたアカウント情報および公開鍵がＡＡによって被提供者に送信されたため、実質的にはＡＡは、提供者のアカウント情報および公開鍵の正確さを「証明する」。従って、被提供者が提供者に関するＡＡから送信されたアカウント情報のレコードを有するため、ＡＡは、情報の精度に対する責任を受け取り得、それにより、エンティティが進んでＡＡに登録され、そのサービスを使用する可能性を増加させる。
【０１０７】
一旦、被提供者が提供者に関するオファーおよびアカウント情報を改正した場合、被提供者は、ステップ６５７５において、当業者に公知の従来のビジネス原理に基づいて、オファーに関してどのように行動するかを判定し、ステップ６６００においてオファーに関して行動する。その行動がオファーを選択した後、取引に関するアカウント情報がステップ６６２５において更新される。この情報は、非提供者によって保存および格納され得るが、さらに好ましくは、提供者および被提供者の両方の記録の更新のためにＡＡに送信される。更新されたアカウント情報をＡＡに送信することは本明細書中で上述したように、ＥＣにおける送信情報に関連付けられた典型的なステップを含む。この情報は、オファーが商品を販売することである場合、被提供者の貯蓄アカウントに対するアイテム（デビット等）を含み、あるいは、オファーが商品を購入する場合、受信可能なアカウントのエントリおよび被提供者から利用可能な商品の数量の低減を含む。被提供者が拒絶しても、オファーが関連した情報である。なぜなら、将来、２つのパーティのいずれかと契約するかどうかを判定するために、将来の提供者または被提供者がこの情報を使用することが可能であり得る。
【０１０８】
一旦、アカウント情報がステップ６６２５において更新されると、受信側は、ステップ６６５０において別のＥＣを送信するかどうかを判定する。例えば、被提供者がオファーを受け取ることを望まない場合、単にオファーに応答しないことは、拒絶を選択し、プロセスが終了する。しかし、被提供者が受け取りを望む場合、またはさらなる情報を要求する場合、ステップ６６５０において判定が為され、別のＥＣを送信する。従って、ＡＡとの関係が既に存在し、このプロセスはステップ６１００に戻る。被提供者は元のオファーを作成しない場合、プロセスは、ステップ６１１５に進む。オファーに応答する作用がそのオファーを受け取ること、カウンターオファーを受け取ること、または単により多くのオ情報に対する要求を受け取ることである場合、プロセスはステップ６３７５に進み、ここでは、ＥＣを送受信するプロセスは、契約が形成されるまで繰り返される。最終的には、ステップ６６５０において、より多くのＥＣが送信される必要がない判定が為された場合に終了する。
【０１０９】
（好適な用語の説明）
図７は好適な用語の説明７０００を示す。説明７０００において説明された用語は例示目的のために説明されるが、しかしこの説明は、説明７０００において説明された特定の例において示された定義に対して本明細書中で使用されたような用語を限定することを意味しない。説明７０００において示された用語は、一般的には、当業者に公知であり、本明細書中のいたるところで使用された用語のいくつかの構造の視覚的な例を与えるように示される。
【０１１０】
（検証ステータスインジケータを用いる契約シナリオ）
図８は、ＰｒＫを含むデバイスの検証ステータスを用いて、どの信頼性のレベルをデジタルに署名されたＥＣに割り当てるかを判定するためのシステム１４５を示す。この図解的な例では、ネットワーク（好ましくはインターネット１０８）を使用して、契約パーティ間のメッセージを送受信し得る。このシステム１４５は、そこに含まれる契約条件に拘束されるべきＥＣの送信側の認証および意図においてどれくらいの信頼性を有するかを判定することを促進する。例えば、契約オファーが低いドル金額および／または数量である場合、被提供者は、契約オファーが提供者によって所有されたデバイスを用いて送信されたことを知る必要があるのみであり得る。しかし、取引の値がより大きくなる場合、被提供者は、ＥＣのデジタル署名がデバイスを用いて生成されたことを要求し得る。このデジタル署名では、データ（個人識別番号（「ＰＩＮ」））は、デバイスがデジタルにＥＣを署名した場合、正確に入力された。より多くの信頼性を望む場合、被提供者は、バイオメトリック（「ＢＩＯ」）データを使用して、ＥＣの内容に作用する前にデジタル署名およびＥＣを生成する。
【０１１１】
従って、被提供者／受信側は、メッセージが提供者のデバイスから送信されたことを保証するばかりでなく、この提供者は、提供者のデジタル署名を用いて、ＥＣの認可されていない署名および送信から保護され、これは、証明オーソリティの階層が破壊される場合、または誰かのクレジットカードが盗まれた場合、ＣＡＤＳに関連して発生する。これは、さらに被提供者を保護する。なぜなら提供者は、他の誰かがデバイスを使用して、ＥＣをデジタルに署名することを以後主張できないためである。従って、意図がなかった主張する仮定された送信側のみを有する、契約の実行の受信に対するリスクが低減されまたは除去される。従って、商取引者は、電子契約を行うようになる。なぜなら、この局面は、誰がＥＣを送信したかという強い証拠および拘束されるべき送信側の意図を提供することを促進するためである。
【０１１２】
実際、欧州連邦は、公開／秘密鍵を、秘密鍵を公表することなく内部に生成し、その秘密鍵を保護するために非常に高いセキュリティを要求する特別の個人デジタル署名デバイスを有する。欧州連邦は、ＦＩＮＲＥＡＤ規格において、さらに安全な入力デバイスまたはＩ／Ｏ素子を特定し、これらは、１）セキュリティ入力ピンおよび／またはＢＩＯデータ、および２）署名されるべきＥＣの条件を安全に表示し、従って、送信側が条件に署名させ、この条件は、署名時に安全な入力デバイス上で見ることができることを確実にする。
【０１１３】
図８の説明を続けると、典型的な事務所のシナリオ４２５は、種々の雇用者によってアクセス可能なコンピュータ４６０を示す。さらにデバイス４５０は、ＰｒＫ１１６を含むことを示す。デバイス４５０は、ＥＣのメッセージをデジタルに署名するばかりでなく、組み込まれたＶＳ出願において詳細に説明されたように、デバイスの状態を示すインジケータを出力する。
【０１１４】
事務所のシナリオ４５０は、ステップ１において受信されたデバイス４５０を共有し得る３人の個人を示す。ステップ２では、購入代理人３０２Ａは、事務所がより多くのペンおよび紙を必要とすることを判定する。従って、代理人３０２Ａは、デバイス４５０を２：００以降に使用し、事務所のコンピュータ４６０を用いてオーダーする。事務所のコンピュータはデバイス４５０のＰｒＫ１１６を使用して、ステップ２ａにおいてＥＣ４５４Ａの一部として識別子と共にデジタル署名を形成し、送信する。ＥＣ４５４Ａは、ペンおよび紙に対するオファーの内容を含む。さらに、ＥＣ４５４Ａは、組み込まれたＶＳ出願において説明されたように検証ステータスマーカーを含む。
【０１１５】
デジタル署名の成功した復号化によって、ＥＣ４５４Ａの受信側４５ａは、検証ステータスインジケータを解析して、ＥＣが所定のビジネス法則１１５ａを満足するかどうかを判定する。検証ステータスインジケータの解析を実行するために、受信側４５ａは、ビジネス法則１１５ａにアクセスする。これは、受信エンティティ４５ａによって保守されるデータベース４０ａにアクセスすることによって実行され得る。あるいは、ビジネス法則１１５ａは、第三者アカウント機関３２または別のアカウント機関エンティティによって保守され得る。ビジネス法則が格納されたにもかかわらず、上述のように、ビジネス法則は、識別子および公開鍵に関連付けられ、その結果ビジネス法則は、対応する識別子の受信の際、取り出され得る。
【０１１６】
満足されるべきビジネス法則に対して、デバイス４５０は、タイムアウトを有してはいけない。デバイス４５０はタイムアウトを有するかどうかは、タイムアウト変数（「ＴＯ」）によって表される。これは、１１５ａにＴＯ＝Ｆとして示される。デバイスがタイムアウトを有する場合、この変数は、ＴＯ＝Ｔとして示され、ビジネス法則１１５ａは満足されない。なぜなら、ビジネス法則はＴＯ＝Ｆを要求するためである。オーダーされた商品のコストは、＄２５０未満であるため、ビジネス法則は、デバイスの最後のリセットの後からデバイス４５０が別の従業員によって使用されたかどうかを気にかけない。従って、組み込まれたＶＳ出願において詳細に説明されたように、シーケンスマーカーＤＳフラグの状態が利用可能でない（「Ｎ／Ａ」）。デバイスのリセットは、脱付勢化および再付勢デバイス４５０によって達成され得る。あるいは、ビジネス法則は、以下に説明されるように、検証データが入力されることを要求する場合、検証データの入力は、ＤＳフラグをゼロにリセットする。ＰＩＮ検証ステータスは、正確なＰＩＮが入力されるか否かを含む。ＢＩＯ検証ステータスは、入力されたＢＩＯデータの程度の角度（ｄｅｇｒｅｅ）一致またはパーセント一致を含む。
【０１１７】
ビジネス法則１１５ａは、ＤＳフラグが０に設定されないことを要求しないが、ビジネス法則１１５ａは、強調された認証のいくつかの形態が標準的なデジタル署名に追加して使用されることを要求する。例えば、ビジネス法則１１５ａは、正確なＰＩＮが代理人３０２ａによって入力されることを要求し得る。図に示されたように、規則１１５ａは、ＰＩＮ＝Ｔを要求する。従って、誰かが偶然フロアを通り、デバイス４５０に入力し、そして紙およびペンをオーダーする場合、受信側４５ａにおけるビジネス法則１１５ａは、オファー１００の受理を不可能にする。なぜなら、事務所４２５の認証された代理人による意図は、オーダーを配置する際に対抗受信側４５ａを明らかにしない。さらに、ビジネス法則１１５ａは、ＢＩＯ確認を必要としない。なぜなら、オーダーされた商品のコストおよびタイプが２５０＄未満であるためである。従って、正確のＰＩＮが代理人３０２ａによってペンおよび紙に対するオーダーを配置する際に入力された限り、受信側４５ａは、ペンおよび紙を購入するためのオファーが合法的である。ことを保証する。なぜなら、デジタル署名は、送信側をうまく認証し、ビジネス法則１１５ａは、ＥＣ４５４ａにおける検証ステータスインジケータによって満足される。
【０１１８】
しかし、ＤＳフラグ基準がＮ／Ａであるため、正確なＰＩＮのような検証データ最後に入力された後、デバイス４５０がコンピュータ４６０の内側に残っていた場合、ビジネス法則１１５ａは、認可されていないユーザがペンおよび紙（または＄２５０未満のコストである他の商品）をオーダーすることを可能にする。このビジネス法則１１５ａは、ＤＳフラグ状態にもかかわらず、オーダーの実施を可能にする。なぜなら、＄２５０の価格限度は、ステップ２において、商品の認可されていないオーダーから発生し得る任意の損害を低減する。デバイスの以前の使用の後、デバイス４５０がコンピュータ４６０に残され、そしてＤＳフラグが結果的に０〜１にインクリメントしていたとしても、デバイスが属するエンティティがオーダーされた商品をさらに受け取る（デバイスが合法的にオーダーされていないとしても）。従って、本例のエンティティをオーダーすることは、エンティティが要するよりも多くのペンおよび紙を受け取ることになり得るが、認可されていないユーザがペンおよび紙のためにオーダーを行う場合、それによって、ペンおよび紙に対する契約額の支払に拘束され、認可されていないユーザが支払った価格と引き換えに比較的低いドル額のコストを要する受け取られた商品を有することになる。さらに、認可されていないユーザが商品を受け取り、この商品を保持することを望まない場合、ビジネス法則に従って、返金するための供給会社に使用されないそれらの商品を潜在的に返還し得る。従って、ビジネスは、特定のビジネスおよび／または特定の取引の必要性に適合するように調整され得る。
【０１１９】
示された例は、単に所定のビジネス法則と共にデバイスの検証ステータスの使用を示すに過ぎないが、ビジネス法則およびどのようにして検証ステータスがビジネス法則の実現を促進するかに限定されることを意味しない。例えば、オーダーエンティティは、低いドル額の購入が為される度に、検証データが入力されることを要求しないように望まれたビジネス法則を有し得ない。このビジネス判定は、購入代理人３０２Ａに対してかかる時間の低減を行い、ステップ２ａにおいて、オファーの条件を定式化し、オファーＥＣ４５４ａを送信する。しかしこれは、ほんの一例であり、契約パーティが特定の状況に対して望ましいビジネス法則を判定するという事実に関心が集まるべきである。オーダーエンティティは、別のエンティティまたは個人との契約を開始するためのデバイス４５０の任意の使用は、検証データ（正確なＰＩＮ等）が、デバイスがデジタル署名を生成する全ての発生に対して開示されることを要求することを判定する。この重要性は、デバイス４５０の検証ステータスが多くの使用が特定のパーティまたは特定の必要性にカスタマイズすることが可能な多くの使用を有する。検証ステータスの局面の利点の内の１つは、検証ステータスが、ＥＣの送信側がＥＣに含まれるメッセージの条件によって拘束されることを意図したさらなる証拠をＥＣの受信側に提供し得る。送信側が合法的であるか（すなわち、デバイスの合法的で適切な所有者）および拘束されることが意図された送信側（すなわち、ＥＣを送信する前にＥＣの送信側をＰＩＮまたはＢＩＯデータを入力するように促進する）ことを信じる前に、実質的には、このビジネス法則は、信頼性のどのレベルが要求されるかを実質的に判定する。
【０１２０】
この例では、このデバイスは、別の供給者との以前の取引に対して正確なＰＩＮを入力する適切な認証されたユーザによって使用されてきた。従って、検証ステータスインジケータはユーザが適切であったかどうかを示す。すなわち、ユーザが検証され、ＰＩＮが適切に入力される。しかし、ＤＳフラグが０ではない場合、ユーザがオファーＥＣ４５４ａにおけるオファーの特定の条件に拘束されることを意図した証拠が不十分になる。これは、検証ステータスインジケータは、ＰＩＮが、ＥＣが署名される直前に現在のＥＣ４５４ａの送信に関連して正確に入力されることを示さないためである。本例の有効な理由のため、このパーティは、ＤＳが０であることを必要としないことを以前に同意し、それによりビジネス法則は、ＤＳフラグが０に等しくなり得なくとも、ペンおよび紙の出荷を可能にする。
【０１２１】
しかし、正確なＰＩＮまたは有効なＢＩＯ検証データのエントリは、さらに低いコスト取引に対して望ましくあり得る。これは、整合の程度を含む正確なＰＩＮおよび／またはＢＩＯのエントリは、検証ステータスインジケータなしでデジタル署名を行うよりも強い認証を提供するためである。さらに、特定のＥＣのデジタル署名および送信に関連する正確なピンおよび／またはＢＩＯ認証データのエントリは、例えば、契約の内容によって拘束されることが意図された送信側がＥＣに含まれる強い証拠を提供する。図１２を参照して説明されたように、欧州連合は、ＥＣを送信するために、送信側の意図の強い証拠によって支援されるべきであることを特定してきた。従って、安全な入力デバイスは、例えば、安全な入力デバイスは、不正な取引の一部として以後再生され得るＰＣを通過するデータのウイルス盗聴を不可能にするようにＰＩＮまたはＢＩＯの安全な入力を支援する安全な入力デバイスが特定化され得る。さらにこの安全な入力デバイスは、ＥＣを安全に表示しつつ、ＰＩＮまたはＢＩＯデータが入力される。さらに、安全な入力デバイスはまた、ＥＣを署名し、安全な入力デバイスが使用されたことを示す。
【０１２２】
図８の説明を継続すると、図示された例に関する次のステップに対して、１時間未満後に、ペンおよび紙をオーダーするＥＣ４５４ａが送信される。同じ事務所内の秘書３０２ｂが、ステップ３において航空機のチケットに対するオーダを行う必要がある。秘書の上司が会議に出席し、上司がすぐに出発しなければならない。ＴＯ時間が、ビジネス法則１１５ｂにおいて１時間に設定され、ビジネス法則１１５ｂは、データベース４０ｂから取り出されると仮定すると、デバイスに対するＴＯは、さらに「Ｆ」に等しくなる。しかし、デバイス４５０は、代理人３０２ａがステップ２においてペンおよび紙をオーダーした後、コンピュータ４６０に残される場合、ＤＳフラグは、「０」に等しくなくなる。なぜなら、デバイスがリセットされた後、チケットのオーダーは、少なくとも第２の取引において存在し、ＥＣ４５４ｂに対応する公開鍵に関連するビジネス法則は、＄２５０よりも高い価値のある取引が第１の取引でなければならないことを必要とし、ここで、デバイスは、秘密鍵を含むデバイスがリセットされた後に使用される。従って、ＴＯ＝Ｆであっても、このデバイスが除去されそして再挿入され、またはいくつかの他の方法がＤＳフラグをリセットするためにデバイス４５０に対して利用可能である。リセットはまた、ユーザに対するプロンプトを表示するコンピュータ４６０によって達成されて、デバイス４５０に対応する正確なＰＩＮを入力し得る。
【０１２３】
ＤＳフラグをリセットすることは、航空機チケットのためのオーダーを含むＥＣの送信側がそのチケットをオーダーすることを意図することを受信側４５ｂに示す。さらに、ＥＣに含まれた検証ステータスがデータベース４０ｂに、送信側がそのチケットをオーダーするために意図されたデバイス４５０の公開鍵に関連付けられたレコードとして格納され得る。デバイス４５０をリセットする際に、ビジネス法則１１５ｂは、ＰＩＮデータが秘書３０２ｂによって入力されることをさらに必要とする。従って、ＥＣのデジタル署名の成功した復号化によって受信側は、検証ステータスインジケータを評価して、ビジネス法則１１５ｂが満足されるかどうかを判定する。検証ステータスインジケータは、デバイス４５０がタイムアウトされず、検証データ（正確なＰＩＮ等）が入力され、デバイス４５０が取引のために最後に使用された後に入力される場合、ビジネス法則１１５ｂは、ＥＣ４５４ｂの条件に従ってフライトの予約を可能にする。これは、ＥＣ４５４ｂの受信側４５ｂは、成功して認証された秘書３０２ｂが、オーダーを行い、オーダーを行う権限を有することを確実にする。従って、受理が行われた有効なオファーが秘書３０２ｂの雇用者とエンティティ４５ｂとの間の契約を作成する。秘書３０２ｂによってチケットを購入するチケットまたはオファーの販売のための広告がオファーを構成するかどうかおよびＥＣ４５４ｂに含まれた条件を送信するかどうか、あるいは航空会社４５ｂによる航空機のチケット（電子メール確認）の送達は、この議論に対して重要ではない。重要なことは、別個のＥＣにおいて具現化されたオファーおよび受理が検証ステータスインジケータに関連して為され、この検証ステータスインジケータは、送信側がＥＣの内容に含まれた条件によって意図された受信側パーティへの保証を向上させる。
【０１２４】
最後に、図８に示された例の最終ステージは、マネージャ３０２ｃが、ステップ４において部品の２つのボックスのオーダーを出荷する必要がある。ビジネス法則１１５ｃに従って、秘書３０２ｂが航空機チケットをオーダーした後、時間が２時間経過した後に、デバイス４５０ｂがタイムアウトされ、ＴＯ変数は、リセットされなければならない。以前にリセットされていない場合（デバイスＴＯフラグが、デバイスをコンピュータ４６０から除去することによって、またはデバイスアクティブセッションの「ロギングアウト（ｌｏｇｇｉｎｇ  ｏｕｔ）」によって新しいセッションを開始する場合、これは典型的には、自動的に発生する）、さらにＤＳフラグがリセットされる必要がある。出荷の値および別のパラメータに基づいて、ビジネス法則１１５ｃは、マネージャが正確なＰＩＮに加えて有効なＢＩＯデータを入力することを必要とする。従って、指紋、声紋、手のジオメトリ（ｈａｎｄ  ｇｅｏｍｅｔｒｙ）、網膜スキャン、マネージャ３０２ｃに対して個人的である同様の検証データは、受信側４５ｃにおけるビジネス法則が部品を出荷する前に必要とされる。受信側４５ｃは、マネージャ３０２ｃを雇用するエンティティの出荷部門または倉庫であり得、あるいは、受信側４５ｃは、商品の管理を有する受託者であり得、マネージャ３０２ｃからの商品を出荷するための命令を待機する。従って、ＥＣ４５４ｃの成功した認証、データベース４０ｃからのビジネス法則１１５ｃの取り出し、およびデバイス４５０の検証ステータスインジケータを評価することによってビジネス法則の満足に応じて、受信側４５ｃは、送信側がマネージャであり、マネージャがオファーに対して拘束されることを意図することを保証する。この部品が出荷され、オファーが受け取られることによって、マネージャ３０２ｃの雇用者が送達のために出荷エンティティ４５ｃを支払うことを強制する契約を形成する。
【０１２５】
これは、ステップ４ａにおいてマネージャ３０２ｃがＥＣ４５４ｃを送信する前に、契約が入力されたパーティ間で同意することに同意する限り、簡単な契約ではあり得ないが、この例は、簡単で、単純な（ａｒｍｓ−ｌｅｎｇｔｈ）オファーおよび受理以外の検証ステータスインジケータの使用を示す。この出荷エンティティ４５ｃは、マネージャ３０２ｃが雇われる同じエンティティによって所有され、動作された社内の出荷倉庫であり得る。あるいは、商品を目的地まで出荷するまで、出荷エンティティ４５ｃは、商品を格納する受託者、または第三者管理人であり得る。いずれの例においても、出荷エンティティ４５ｃおよびマネージャ３０２ｃは、典型的には、物理的に近接して配置され得ない。そして、マネージャ３０２ｃおよび出荷エンティティ４５ｃは、共通の雇用者に報告する場合、多くのビジネスに対して内部アカウンティング手順は、典型的には、各部門のコストトラッキングアカウントにデビットおよびクレジットを要求する。従って、部品の出荷を認可するＥＣ４５４ｃを送信するように意図されたマネージャ３０２ｃは、やはり有益である。
【０１２６】
（検証ステータスインジケータを用いた契約シナリオのための処理）
図９を参照すると、電子契約のためのプロセス９０００を示すフローチャートを示す。ＥＣが使用されて契約文書を安全に送信する。さらにプロセス９０００は、検証ステータスインジケータの使用を示し、ＥＣの検証において受信側が有する信頼性を増加させる。さらに、プロセス９０００は、送信側がＥＣのメッセージをデジタルに署名する際に明らかな行動を実行する証拠を提供することによって、ＥＣの送信側がＥＣに含まれるメッセージをデジタルに署名することを意図した受信側の信頼性のレベルを上昇させる。
【０１２７】
プロセス９０００は、プロセスを実現するユーザが、ＥＣとして契約文書を送信するかどうかを判定する場合、ステップ９０５０において開始する。ＥＣの送信側は、契約シナリオに含まれ得る提供者、被提供者、または任意の他の契約パーティであり得る。契約パーティがＥＣを送信しない場合、ユーザは、このプロセスを用いて、契約文書を含むＥＣを受信する可能性がある。従って、このプロセスは、「Ｎ」判定経路に進み、ステップ９４００に進む。これを次に手短に説明する。ステップ９０５０から「Ｙ」経路に沿って進むと、ステップ９１００において、ユーザは、典型的には、例えば、ＰＣを用いて契約文書を定式化する（オファーまたはオファーの受理）。この文書が定式化された後で、ＥＣは、ステップ９１５０において生成される。ＥＣは、典型的には、電子メッセージの形態で契約文書の内容を含み得る。
【０１２８】
本例を続けると、典型的にはＥＣは、さらにメッセージのデジタル署名および検証ステータスインジケータを含む。典型的には、このデジタル署名は、送信側の個人用デバイスのＥＣ送信側の秘密鍵を用いて生成される。この検証ステータスインジケータは、典型的には、この個人用デバイスによって受信された最新の検証データに基づいて生成される。次いで、ＥＣが生成された後、送信側は、ステップ９２００においてオプションで示され、個人用デバイスに入力することによって（例えば、ＰＩＮおよび／またはＢＩＯ）検証データを更新する。これは、この人相データが古くなった場合（すなわち、別のＥＣが現在の検証データを用いて、このデバイスによって署名された）望ましくあり得る。あるいは、検証データは、そのデータが送信ＰＣに配置されるためそのデバイスに入力され得ない。さらに、検証データが入力され得、検証データが入力された後、デジタル署名が為されないが、現在の検証データが正しくない（すなわち、間違ったＰＩＮおよび／またはＢＩＯがデバイス内部の正確なＢＩＯに一致しない）。正確に入力されている新鮮な検証データ（すなわち、検証データが入力された後、デジタル署名がデバイスの秘密鍵を用いて生成されない）は、この検証データが使用されて、デバイスによってデジタルに署名されたＥＣを伴って検証ステータスインジケータを生成する。従って、ＥＣに含まれた検証ステータスインジケータを評価することによって、受信側は、ＥＣの認証において配置される信頼性を増加させ得る。
【０１２９】
送信側が検証データを更新しないことを判定する場合（すなわち、送信側がＰＩＮを知らないかまたは個人用デバイスが割り当てられる所有者であり得ない）、送信側は、デバイスを使用してＥＣをデジタルに署名するように所有者の許可を有し得るが、次ぎに手短に説明するようにこのプロセスは、ステップ９３５０に進む。送信側は、デバイスを用いて商品のためのオーダーを行い得る。例えば、オーダーのコストは、例えば送信側の雇用者と受信側／被提供者との間で以前に同意されたビジネス法則に基づいて、所定の額未満である。しかし、送信パーティが検証データを更新することを判定する場合、例えば、上記の場合であるが、送信側が、ビジネス法則によって要求された更新された検証データがＥＣの署名の直前に入力されることを知っていた場合、送信側は、ステップ９２５０において更新されたＰＩＮおよび／またはＢＩＯを入力する。検証データのエントリ（すなわち、デバイスの正確なＰＩＮおよび／または有効なＢＩＯ）に対して、プロセスは、ステップ９１５０においてＥＣの一部として本来生成された検証データを置換する。古い検証データが更新された検証データで置換された後、ＥＣは、ステップ９３５０において受信側に転送される。
【０１３０】
ステップ９３５０においてＥＣが送信された後、受信側は、ステップ９４００においてＥＣを受信する。ＥＣの受信の際、受信側は、ステップ９４５においてＥＣの送信側を検証する。送信側の検証は、ＥＣのデジタル署名を復号化することを含み得る。さらにＥＣの検証ステータスが使用されて、ＥＣの検証において信頼性のレベルを上昇させ得る。例えば、検証ステータスは、ＥＣを署名する前に入力されたことを示す場合、受信側は、送信側の認証においてより高い信頼性を有する。すなわち、送信側は、ＥＣがその送信側が誰であるかを示す者である。これは、検証ステータスインジケータは、ＥＣがデジタルに署名される前に、秘密鍵を含むデバイスの合法的な所有者が、ＥＣに入力された有効な検証データを署名するために使用したことを示し、そして詐欺者が、そのデバイスの合法的な所有者のように見せかけるためにデバイスを使用しないことを示すためである。さらに、これは、合法的な所有者がＥＣの署名者である可能性があったために、合法的な所有者は、ＥＣメッセージの内容に含まれた契約条件によって拘束されることを意図したことを示す。
【０１３１】
しかし、さらに検証ステータスインジケータは、有効な検証データが、デバイスが使用されてＥＣをデジタルに署名した直前に入力されたデータであることを示し得る。従って、受信側はＥＣの内容に関して作用されるかどうかを判定する前に（すなわち、オファーを受け取りまたは受理を評価して、この受理が元のオファーの条件を修正するかどうかを判定する等）、検証ステータスインジケータは、ステップ９５００において判定される。次いで、このプロセスは、ステップ９５５０において検証ステータスインジケータをビジネス法則と比較して、受信されたＥＣの内容に応じてどのように作用するかを判定する。
【０１３２】
例えば、取引額が所定の閾値未満である場合、受信側は、ＥＣがデバイスの秘密鍵によって署名される前に、有効な検証データが送信デバイスに入力されたかどうを気にかけ得ないが、ビジネス法則は、有効な検証データがＥＣの署名の前のある時間においてデバイスに入力されることを要求し得る。しかし、取引のコスト額は、所定の閾値よりも高い場合、ビジネス法則は、受信側によって評価されたＥＣが署名される前に署名された介在するＥＣなしで、検証ステータスインジケータの一部として送信されたＤＳフラグがデバイスを用いてＥＣを署名する前にデバイスに有効検証データが入力されたことを示すことを必要とし得る。さらに、ビジネス法則は、有効な検証データが評価中にＥＣを現在署名する直前に入力され、検証データが、ＥＣが署名される前に所定のタイムアウト時間内に入力されることを要求し得る。この低減は、有効な検証データがデバイスに入力され、検証されていないユーザがデバイスに出会いそしてデバイスをＥＣを署名するために使用しつつ、デバイスを参加したままにさせることだけである。従って、ＥＣをデジタルに署名する直前およびこれに関連して送信側による明らかな行動は、ＥＣに署名する送信側の代わりの意図を確立する。
【０１３３】
ステップ９５５０において為された判定は、ビジネス法則が満足に満たされないことを示す場合、受信側は、ビジネス法則がステップ９５５５において満足されないことを送信側に示すことを判定する。この支持は、署名されていないメッセージの形態で送信側に対して為され得る。送信側は、契約文書内容を含むＥＣが新しいＥＣに署名する直前に送信デバイスに入力された有効検証データを用いて再署名されることを必要とする。従って、プロセスはステップ９２００に戻り、このプロセスは、上述のように再度進む。受信側が検証データを再入力するように元の送信側に命令する簡単なメッセージを送信することを望まない場合、プロセスは、ステップ９５５５〜ステップ９６５０までの「Ｎ」経路に進む。ステップ９６５０において、デジタルに送信されたＥＣの形態でメッセージを送信するかどうかの判定が為される。例えば、受信側は、元の送信側に元の契約文書をデジタルに署名させ、契約の条件が、それが初めに送信された場合と同じままであるように、元の送信側に戻って元のＥＣを送信することを望み得る。ステップ９６５０において、判定が為される場合、このプロセスは、ステップ９０５０に戻り、別のＥＣを送信するかどうか判定する元の送信側によって再び開始する。例えば、元のＥＣを署名するために使用されたデバイスの合法的な所有者がＥＣを送信しない場合、ステップ９０５０において別のＥＣを送信しないように選択し得る。これが判定である場合、プロセスは、ステップ９０５５に進む。ここでは、受信されたＥＣが存在するかどうかについて評価がなされる。このようにプロセスがステップ９４００に進み、ＥＣを受信する場合、このプロセスは既に説明されたように継続する。受信されるべきＥＣが存在しない場合、プロセスは終了する。
【０１３４】
ステップ９５５０において実行された評価の説明に戻ると、ビジネス法則が元のＥＣ内の検証ステータスインジケータによって満たされる場合、ＥＣの内容はステップ９６００において作用される。ビジネス法則の満足は、典型的には、検証ステータスインジケータが受信側に指示（ＥＣの送信側がＥＣに含まれた契約文書の条件に同意する信頼性の所定のレベルを有する）を提供することを暗示する。検証ステータスインジケータはこの信頼性を提供する。なぜなら、この検証ステータスインジケータは、有効な検証データが署名する前の所定の期間内にＥＣを署名するために使用されたデバイスに入力されたことを示すためである。さらに、ビジネス法則は、ＤＳフラグが０に設定されることを要求する場合、検証ステータスインジケータは、有効検証データがビジネス法則によって評価された特定のＥＣの署名に関して入力されたことを示す。従って、デバイスにＥＣをデジタルに署名させるために、ビジネス法則を満足する検証ステータスは、ＥＣを署名するために使用されたデバイスの合法的な所有者が明らかな行動を実行したことを示す。
【０１３５】
ステップ９５５０において、ビジネス法則が満たされる場合、ＥＣ内容に関する作用は、典型的には、ＥＣがオファーを含む場合、オファーを受け取る。ＥＣが受理を含む場合、この作用は、請求書に従ってオーダーされた商品を出荷することであり得る。あるいは、オファーが受理され、履行が契約の条件に従って当然のこととして開始する場合、受理に対するこの作用は不活性であり得る。ステップ９６００にける作用の後、任意の作用が受信されたＥＣの条件に応答して実行された場合、ステップ９６５０において、別のＥＣを送信するかどうかの判定が為される。例えば、受信されたＥＣがオファーであった場合、ＥＣに応答してステップ９６００において選択された作用が、別のＥＣの形態で受理を送信することであり得る。そうである場合、このプロセスはＹ経路に進み、プロセスはステップ９０５０に戻る。プロセスは上述のように継続する。ステップ９６５０における別のＥＣの送信の判定がない場合、このプロセスは「Ｎ」経路に進み、そして終了する。
【０１３６】
（ＡＢＤＳなしのＰｒｉＭＲ）
図１０を参照すると、電子契約取引を実行するために使用された公開鍵にリンクされた情報システム６０３が示される。ネットワーク（好適にはインターネット１０８）を使用して、契約パーティ間のメッセージを転送および受信する。ステップ１において開始して、秘密鍵１１６ａおよび１１６ｂは、安全なエンティティ２３５によって安全な環境１１５におけるデバイス４５２ａおよび４５２ｂに製造される。デバイス４５２ａおよび４５２ｂ、ならびに、これらのデバイスに含まれた非対称鍵の対の各秘密鍵１１６ａおよび１１６ｂは、契約パーティ提供者１０２ａおよび被提供者１０２ｂに分配され、提供者１０２ａおよび被提供者１０２ｂはデバイスを使用して、デジタル署名を生成する。デバイスの製造時に、キーの対の公開鍵１１８ａおよび１１８ｂは、安全な環境１１５において好適に保守された安全なデータベース２３８に格納される。このような安全なエンティティ２３５、安全なデータベース２３８、および安全な環境１１５は、組み込まれたＰＲｉＭＲアプリケーションにおいて詳細に説明される。
【０１３７】
デバイス４５０ａおよび４５０ｂのための秘密鍵１１６ａおよび１１６ｂは、必ずしも同時に製造および送信される必要はないが、デバイスを安全なエンティティ２３５から契約パーティに分配するためプロセスは、図示目的のための単一のステップとして図に示される。従って、複数のパーティが別のデバイスを有し得、各デバイスは、各別のパーティに対して特別であり個人的であり、異なる時間において、格納された公開鍵のそれぞれに対応する秘密鍵を含むデバイスを受信し得る。秘密鍵１１６ａおよび１１６ｂを含む送信デバイスおよび格納されている公開鍵１１８ａおよび１１８ｂに加えて、安全なエンティティ２３５は、デバイスに関連する情報を安全なデータベース２３８に格納する。この情報は、以下に限定されないが、ＥＣをデジタルに署名する際に、デバイスがユーザまたは送信側および彼らの意図を認証することを受け取ることが可能であるＰＣ、ＰＤＡ等のデバイスのタイプ、デバイスの製造の日付、もしあれば製造場所およびデータのタイプを含み得る。データのこのような例は、デバイスのセキュリティ特性と呼ばれ、特定のデバイスに対してまとめてセキュリティプロフィール１２０と呼ばれる。従って、公開鍵を有するデバイスを発行し、対応する公開鍵を格納する際に、安全なエンティティ２３５は、さらにステップ１においてセキュリティプロフィール情報１２０を格納する。従って、各デバイスのセキュリティプロフィール１２０は、安全なデータベース２３８に格納され、各デバイスに関連付けられた対応する公開鍵にリンクされる。
【０１３８】
各パーティがこのパーティに特定であり個人的である別のデバイスを有するこのようなシナリオでは、各パーティは、パーティが互いの契約を形成する場合、安全に保守されたデータベース２３８を利用する。例えば、デバイス４５２ａを用いる提供者のパーティ１０２ａは、被提供者パーティ１０２に対するオファー１００を行うことを判定する場合、オファーは、ＥＣ２４７ａの形態で被提供者に電子的に送信され得る。ステップ２において、提供者は、デバイス４５２ａの秘密鍵を使用して契約オファーの条件を含むＥＣをデジタルに署名する。ステップ３において、ＥＣ２４７ａは、提供者１０２ａから被提供者１０２ｂに送信される。典型的には、被提供者１０２ｂは、ＥＣ２４７ａの送信側の認証において、どれくらいの量の信頼性を有するかを知ることを望むため、被提供者１０２ｂは、ステップ４において、要求２２６を安全なエンティティ２３５に送信することを望み得、ＥＣ２４７ａをデジタルに署名するために使用されたデバイス４５２ａのセキュリティプロフィールを取り出す。
【０１３９】
ＥＣであり得る要求２２６を被提供者１０２ｂから受信する場合、安全なエンティティ２３５は、安全なデータベース２３８にアクセスし、要求共に送信された公開鍵１１８ａにリンクされた情報を取り出し、公開鍵１１８ａに対応するセキュリティプロフィール１２０ａをリクエスタ−被提供者１０２ｂに戻す。あるいは、セキュリティプロフィールは、要求２２６において、アカウント識別子に基づいて取り出され得る。従って、被提供者１０２ｂは、オファーＥＣ２４７ａを送信するために使用されたデバイス４５２ａが、不正に使用されるか、またはＥＣにおいて識別された送信側以外の誰かによって使用され可能性に関して通知した判定を行い得る。これは、被提供者１０２ｂがオファーＥＣ２４７ａの送信側がＥＣにおいて識別されたパーティである保証なしでオファー１００の条件を受け取らないように選択され得る。セキュリティプロフィール１２０ａによって保証が提供される。なぜなら、被提供者１０２ｂは、セキュリティプロフィールを評価して、デバイス４５２ａが十分に安全なタイプであるかどうかを判定し、その結果、妥協することが不可能であり、デバイスに含まれた秘密鍵１１６ａが学習される。デバイス４５２ａが高度に安全である場合、デバイスは電気的にまたは物理的に分解することができず、その結果秘密鍵１１６ａが判定され得、被提供者１０２ｂは、ＥＣ２４７ａがデバイスの所有者を合法化することによってデジタルに署名された保証が提供される。これは、例えば受理がオファー１００の契約条件の履行によって実行され得る場合（すなわちＥＣ２４７ａにおいてオーダーされた商品を提供者１０２ａに出荷する場合）、特に有益である。従って、被提供者１０２ｂは、ＥＣ２４７ａに識別されたパーティは、実際にはＥＣを送信したパーティであり、盗んだ者またはＥＣを送信するためにデバイス４５２ａから秘密鍵１１６ａを不法に使用した者ではないことを後で証明しようとする無益な必要性から保護される。
【０１４０】
オファー１００の受理が履行によって実行されえない場合、被提供者１０２ｂは、別のＥＣの形態で受理１００を送信することによってオファーを受け取り得る。典型的には、ステップ５に示されるように、デバイス４５２ｂを用いてメッセージを形成することおよびメッセージをデジタルに署名することを含む。次いで、ＥＣ２４７ｂは、ステップ６において、元の提供者１０２ａに送信される。同様に、オファーＥＣ２４７ａを受け取る被提供者１０２ｂと同様に、受理ＥＣ２４７ｂを受信する際に、元の提供者１０２ａは、ステップ７において、安全なデータベース２３８からデバイス４５２ｂのセキュリティプロフィールを要求し得る。上述したように、セキュリティプロフィールを使用して、ＥＣ２４７ｂの送信側が実際にＥＣにおいて識別された送信側であることを信用かどうか、およびその結果オファー１００の受理１１０の条件に依存するかどうかを判定し得る。
【０１４１】
（ＡＢＤＳなしのＰｒｉＭＲのための処理）
図１１を参照すると、ＥＣの送信側およびメッセージの認証の受信において信頼性を上昇させるデバイスのセキュリティプロフィールを用いるためのフローチャートを示す。上述のように、特定の個人またはエンティティに対して個人化されたデバイスを使用してメッセージを含むＥＣをデジタルに署名し得る。さらに、上述のように、デバイスが安全な環境において、そして組み込まれたＰＲｉＭＲアプリケーションにおいて製造された場合、デバイスに対するセキュリティプロフィールが製造時において生成され、その後安全な環境で保守される。次いでセキュリティプロフィールは、契約シナリオの合法的な所有者によって署名されてきたＥＣを受信する契約に対するパーティによって使用されて、送信側およびＥＣに含まれたメッセージの認証におけるパーティの信頼性の受信を増加させ得る。
【０１４２】
示されたプロセス１１００は、ステップ１１０５０においてデバイスの製造を開始する。このデバイスは、好ましくは、安全な環境で製造され、このデバイスに含まれた秘密鍵が暴露され、そのデバイスから取り出せない。ＥＣがデジタルに署名された場合、秘密鍵はデバイスから転送されない。むしろ、デバイス内部に含まれた秘密鍵によってデジタルに署名されたＥＣのメッセージは、デバイスに転送され、このデバイスにおいて、このメッセージが署名され、次いでデバイスからデジタル署名として転送される。従って、受信側がデバイスによって署名されたＥＣを受信し、デジタル署名を検証することによって、ＥＣの送信側を連続的に認証する場合、受信側は、ＥＣを署名するために使用されたデバイスの信頼性レベルを有する。
【０１４３】
しかし、ＥＣを認証することは、特定のデバイスが使用されて、ＥＣを署名するが、デバイスの秘密鍵がハッカーに対して安全である程度に関連した情報は、高いレベルの信頼性を受信側に提供する。これは、デバイスがバルクで製造され、暴露された秘密鍵を生じ得る物理的な電気的な侵入からそのデバイスに含まれた秘密鍵を保護しない場合、鍵は、そのデバイスの合法的な所有者であると見せかける詐欺者によって潜在的に使用され得るためである。従って、ＥＣのメッセージのハッシュを復号化および実行することによってＥＣを認証することは、単に受信側が望み得るように送信側の認証において信頼性の高いレベルとして提供し得ない。ＥＣを署名するこのデバイスは、ハッカーから秘密鍵を保護する際に、その秘密鍵の不貫通性に関する高い規格を作成し、秘密鍵がその製造時に発見されおよび／または記録されないことを確実にするように最高のセキュリティを用いて製造されても、このデバイスを用いて署名されたＥＣの受信側は、このデバイスが設計され、製造された規格に気付き得ない。従って、ＥＣを署名するために使用されたデバイスに関する、ＥＣの受信側によって入手可能なセキュリティプロフィールが望ましく、その結果、受信側は、セキュリティプロイファイルを評価して、デバイスの秘密鍵がコピーされておらず、従って、例えばハッカー／詐欺者によって不正に使用されていないことを信じる危険を判定し得る。
【０１４４】
従って、製造後に、組み込まれたＰＲｉＭＲアプリケーションにおいてさらに詳細に上述したように、デバイスのセキュリティプロフィールは、ステップ１１１００における安全な環境において維持された安全なデータベースに格納される。好ましくは、安全な環境は、デバイスが製造された時と同じ安全な環境である。さらに、デバイスの秘密鍵に対応する公開鍵は、データベースにさらに格納され、次いで公開鍵によってインデックス付けされる。セキュリティプロフィールおよび公開鍵は、安全なデータベースに格納された後、デバイスは、ステップ１１１５０における合法的な所有者に分配する。次いで、デバイスを受信した後、この所有者はＥＣを定式化した後、ステップ１１２００において受信側に送信する。この内容は、オファー、受理、または本明細書中の他の場所で説明されたような他の契約文書であり得る。
【０１４５】
ＥＣの課題が定式化された場合、ステップ１１２５０においてデバイスは、デバイスの秘密鍵を用いてＥＣをデジタルに署名するために使用される。デバイスが使用されてＥＣを署名する方法は、任意の１つの方法に限定されないが、好適な方法において、デバイスはカードリーダに挿入されたカードである。このカードリーダは、電気的にＰＣに接続される。従って、ＥＣの内容は、好適にはＰＣを用いることによって定式化され、次いで、そのデバイスがリーダに挿入されつつ、デバイスの秘密鍵によって署名される。このデバイスによりＥＣの署名によって、ＥＣは、典型的にはネットワーク（例えば、インターネット）を介して受信側に転送される。
【０１４６】
ステップ１１３５０においてＥＣの受信によって、受信側は、ステップ１１４００におけるＥＣの送信側を認証する。この認証が実行された場合、ステップ１１４５０において送信側は、単にＥＣにおけるメッセージのハッシュを復号化および実行するに過ぎない結果を生じる秘密鍵のセキュリティの信頼性レベルが、ＥＣの内容に応じて作用する前に受理可能であるかどうかを判定する。「はい」の場合、プロセスは「Ｙ」経路に進み、ステップ１１６５０においてＥＣの内容に応じて作用する。このような作用は、受理、受理されたオファーの契約条件の履行等であり得る。さらに、受信側は、何もしないことを選択し得る。ステップ１１６５０において実行した後、ステップ１１７００において、受信側は、別のＥＣを元の送信側に送信しないように選択する場合、プロセスは終了する。あるいは、ＥＣがオファーである場合、受信側は、ステップ１１７００において選択されて、別のＥＣの形態で受理を送信することによってオファーを受理し得る。
【０１４７】
ステップ１１４５０において、受信側は、ＥＣの内容に作用するように送信側の認証において十分な信頼性がないことを判定する場合、受信側は、ステップ１１５００において、デジタル署名を検証するために使用された公開鍵に基づいて安全なデータベースからデバイスのセキュリティプロフィールを要求し得る。ＥＣを送信するために使用されたデバイスのセキュリティプロフィールの受け取りに基づいて、ステップ１１５００において、受信側は、セキュリティプロフィールを評価して、送信側の認証を信用するかどうかを判定する。例えば、デバイスのセキュリティプロフィールは、デバイスが不透過性であり、その結果、秘密鍵がデバイスからコピーされた高い信頼性のレベルで仮定され得る。従って、評価に基づいて、受信側は、ステップ１１０００においてＥＣの内容に応じてどのように行動するかを判定し得る。例えば、セキュリティプロフィールは、デバイスが秘密鍵の秘匿性を安全に保護することを示し、ＥＣの内容は、商品を購買するオファーであった場合、受信側は送信側に出荷し得る。どのように作用するかという判定の後、ステップ１１６５０において、受信側はＥＣの内容に作用し、プロセスは上述のように継続する。
【０１４８】
（ＡＢＤＳなしでＰＲｉＭＲおよびＶＳを用いる契約シナリオ）
図１２を参照すると、電子契約を促進するセキュリティプロフィールおよび検証ステータスインジケータを使用するシステム６０４が示される。このシステムでは、ネットワーク（好適には、インターネット１０８）を使用して、契約パーティ間でメッセージを送信および受信し得る。例えば、組み込まれたＰＲｉＭＲアプリケーションにおいて説明されたように、ＥＣの受信側のビジネス法則は、ＥＣを生成するために使用されたデバイスが安全な環境１１５において製造されたことを必要とし得る。このビジネス法則は、検証ステータスインジケータの所定のパラメータを使用して、ＥＣが生成される前に、有効な検証データがデバイスに入力されるかどうか、およびＥＣは、検証データが入力された後、特定のデバイスによって生成された第１のＥＣであったかどうかを判定し得る。検証データおよび検証ステータスインジケータが組み込まれたＶＳ出願において詳細に説明される。従って、図１２に示された局面では、検証ステータスインジケータの局面およびセキュリティプロフィール局面のそれぞれは、信頼性のレベルに貢献し、ＥＣの受信側は、ＥＣにおいて識別されたようなＥＣの送信側を検証させ得る。
【０１４９】
円で囲まれた数１で示されたステップ１で開始すると、メッセージをデジタル署名から暗号化するために使用された秘密鍵１１６Ａおよび１１６Ｂの非対称鍵の対はデバイス４５０ａおよび４５０ｂに格納される。デバイスが製造された場合、この秘密鍵１１６ａは、好ましくは、デバイス４５０ａに格納される。組み込まれたＰＲｉＭＲアプリケーションにおいて説明されたように、このデバイス４５０ａは、好ましくは、安全な製造設備２３５において製造される。安全な設備２３５におけるデバイス４５０ａおよび４５０ｂの製造によって、その鍵の対の公開鍵１１８ａおよび１１８ｂは、データベース２３８に格納され、このデータベースは、好ましくは、安全な環境１１５において保守され、安全な環境は、さらに安全な設備を含む。これらのデバイス４５０ａおよび４５０ｂは、必ずしも同時に製造される必要がない。デバイスを製造するプロセスは、図示の目的のために単一のステップ１としてこの図において示される。
【０１５０】
従って、複数のパーティは、別のデバイスを有する。各デバイスは、複数の別のパーティに対して特有であり、個人的である。各パーティは、このパーティに対して特定のでありそして個人的である別のデバイスを有するこのようなシナリオは、安全に保守されたデータベース２３８を利用する。例えば、提供者エンティティ４２５の従業員がオファー１００を被提供者１０２ｂに行うことを判定する場合、そのオファーは、ＥＣ２４７ａの形態で被提供者に電子的に送信され得る。
【０１５１】
デバイスが製造された後、提供者エンティティ４２５は、オファー１００を行うように準備し、そのオファーをＥＣとして被提供者１０２ｂに送信する。提供者１００を作成する実際の個人は、この図に示されおよび図８における説明において詳細に説明されたように、任意の３人の個人（代理人３０２ａ、秘書３０２ｂ、またはマネージャ３０２ｃ）であり得る。従って、オファーを作成する個人に依存するステップ２ａ、２ｂ、または２ｃにおいて、オファー１００は、メッセージに変換され、デバイス４５０ａの秘密鍵１１６ａを用いるデジタル署名を形成する際に暗号化される。この３人の個人パーティは、図８に関連して上述されたように本発明の検証ステータス局面の使用を図示するために使用される。検証ステータスインジケータは、秘密鍵が使用されて、ＥＣ２４７ａのデジタル署名を生成する場合に、デバイス４５０ａによって生成される。検証ステータスは、図８を参照して説明され、組み込まれたＶＳ出願においてより十分に説明されたように、インジケータ４６２ａとして送信される。図８を参照して上述されたように、インジケータ４６２ａは、契約オファー１００に対して拘束されるように意図された保証を提供する。
【０１５２】
ＥＣ２４７ａがステップ２ａ、２ｂ、または２ｃにおいてオファーメッセージ、デジタル署名、識別子、および検証ステータスインジケータ４６２ａを含むように定式化された後、ＥＣは、ステップ３において被提供者１０２ｂに送信される。ＥＣ２４７ａを受信する際、被提供者１０２ｂは、オファー１００を受け取るかまたはオファー１００かどうかを判定する。次いで、被提供者１０２ｂは、ＥＣ４２７ａにおいて含まれた識別子に基づいて提供者の公開鍵１１８ａを取り出すことによって、提供者エンティティ４２５として送信側を検証して、それにより提供者がＥＣを送信した信頼性を提供する。
【０１５３】
しかし、被提供者１０２ｂは、送信側が提供者のエンティティ４２５であるより多くの保証を望み得る。従って被提供者１０２ｂは、ステップ４において安全なエンティティ２３５に要求２２６を送信する。この要求２２６は、オファーＥＣ２４７ａを送信するために使用されたデバイスのセキュリティプロフィール１２０ａを要求するＥＣである。セキュリティプロフィール１２０ａの作成および使用は、組み込まれたＰＲｉＭＲアプリケーションに詳細に説明される。セキュリティプロフィール１２０ａは、レコードとしてデータベース２３８に含まれ、このセキュリティプロフィールは、デバイス４５０ａが安全な製造設備２３５において作成されたと同時に作成された。セキュリティプロフィール１２０ａは、デバイス４５０ａのセキュリティ特性を被提供者１０２ｂに提供する。この情報は、被提供者１０２ｂによって使用され、オファーＥＣ２４７ａのデジタル署名を生成するために使用されたデバイス４５０ａのセキュリティのレベルを判定する。この情報は、安全なエンティティ２３５および安全な環境１１５のセキュリティ属性、ならびに、デバイスを製造するために使用された手順、デバイス自体のタイプ、および製造プロセスの間に秘密鍵１１６ａのセキュリティを保守するために使用された手順を含み得る。さらに、デバイス４５０ａの改ざんに対する抵抗および秘密鍵１１６ａがハッキング（ｈａｃｋｉｎｇ）に対していかにして安全になるかに関連し得る。
【０１５４】
図１２に示される局面の説明を続けると、提供者のエンティティ４２５に関連するビジネス法則は、ＥＣ２４７ａを送信するために使用されたデバイス４５０ａのセキュリティ属性の判定を要求し得る。公開鍵１１８ａに関連するビジネス法則は、ＥＣ２４７ａを生成するために使用されたデバイス４５０ａが、例えば改ざん抵抗があるかどうかを判定するためにセキュリティプロフィール１２０Ａを必要とし得る。要求２２６に応答して送信されたセキュリティプロフィール１２０ａは、デバイスが改ざん抵抗があることを示す場合、被提供者１０２ｂは、デバイスがその中に含まれる秘密鍵１１６ａの秘匿性を保護することが可能であり、ビジネス法則が満足されたことを保証する。例えば、デバイス４５０ａが適切な所有者ではなく誰かの手にわたる場合、他の誰かは、デバイスの分解によって秘密鍵を識別することができない。従って、被提供者１０２ｂは、いくつかの他のデバイス４５０ａから奪われ得た秘密鍵１１６ａを用いるいくつかの他のデバイスではなく、デバイス４５０ａが使用されてＥＣのデジタル署名を生成することを合理的に保証する。
【０１５５】
全体の信頼性に貢献するセキュリティプロフィールに加えて、被提供者１０２ｂがＥＣの起源に配置され、検証ステータスインジケータ４６２ａは、ＥＣ２４７ａを署名する場合、任意の検証データがデバイスに入力されたかどうかを示す。さらに、インジケータ４６２ａは、有効な検証データが入力されたかどうかを示し、ＤＳフラグは、デバイス４５０ａがリセットされた後、正確なデータが入力されたかどうかを示すために使用される。さらに、ＥＣ２４７ａがデバイス４５０ａによってデジタルに署名された場合、検証ステータスインジケータ４６２ａは、無効な検証データが入力されたかどうかを示す。従って、セキュリティプロフィール１２０ａは、秘密鍵１１６ａがデバイス４５０ａから略奪できないことを示し、そしてステップ２ａ、２ｂ、または２ｃにおいてデバイス４５０ａによって送信された検証ステータスインジケータ４６２ａは、有効検証データがＥＣ２４７ａの生成の直前にデバイスに入力されたことを示す場合、被提供者１０２ｂがＥＣ２４７ａを生成した人またはエンティティは、データベース１１４ｂにおいて公開鍵１１８ａに関連付けられた人またはエンティティである。
【０１５６】
検証インジケータに関して、検証データパラメータは、組み込まれたＶＳ出願に説明されたような、ＰＩＮまたはバイオメトリックデータを含む。このセキュリティプロフィールは、さらにデバイス４５０ａが受信を可能にする検証データのタイプに関する情報を含み得る。従って、ステップ４において安全なデータベース２３８から被提供者１０２ｂに送信されたセキュリティプロフィール１２０ａは、デバイス４５０ａがＰＩＮが入力され得る能力を用いて製造されたことを示す場合、被提供者は、そのセキュリティプロフィールがステップ３において送信される前に、正確なＰＩＮに知識を有する誰かがＥＣ２４７ａをデジタルに署名することを合法的にデバイスを使用することを確実にする。さらに、デバイス４５０ａは、バイオメトリックデータが入力され得る能力を用いて製造され得、デバイス４５０ａを用いてＥＣ２４７ａを署名する人がデバイスの正当な所有者であった受信側をさらに保証する。これは、デバイス４５０ａの合法的な所有者がデバイスを使用してＥＣ２４７ａをデジタルに署名する信頼性のさらにより高いレベルを生じる。従って、検証ステータスは、有効な検証データ（ＰＩＮ、ＢＩＯ、または他のタイプの検証データ）が、デバイス４５０ａに入力される場合、被提供者１０２ｂは、ＥＣ２４７ａがデバイスを合法的に所有した誰かによってデバイス４５０ａを用いてデジタルに署名されたことを保証する。さらに、デバイス４５０ａを合法的に用いてＥＣをデジタルに署名する人またはエンティティは、データベース１１４ｂにおける公開鍵１１８Ａに関連付けられた人またはエンティティである。さらに、セキュリティプロフィール１２０ａは、秘密鍵１１６ａがデバイス４５０ａの電気的または機械的な分解または解体によって妥協されることができないことを示す場合、被提供者１０２ｂは、ＥＣ２４７ａの送信側がデータベース１１４ｂの公開鍵１１８ａに関連付けられた人またはエンティティであることをさらに確実にする。
【０１５７】
図１２に示された局面をさらに説明すると、この高い程度の信頼性は、取引の値が所定の額よりも大きいオファーに対して要求され得る。従って、取引額が小さい場合、被提供者１０２ｂは、ＥＣ２４７ａの識別子に関連付けられた公開鍵が使用されてそのユーザを認証することを要求するのみであり得る。さらに、取引額が低い場合、被提供者は、ステップ４において安全な環境１１５からセキュリティプロフィールをさらに要求し得ない。これは、コストを低く維持するために、安全なエンティティ２３５は、典型的には、データベース２３８からのデータの各アクセスに対して課金し得る。
【０１５８】
しかし、オファー１００の取引額が比較的大きい場合、典型的には被提供者１０２ｂは、デジタル署名を生成するために使用されたデバイスのセキュリティプロフィール１２０ａが、ＰＩＮまたはバイオメトリックデータであってもデバイス４５０ａによって支援されることを示すことを要求する。さらに、被提供者１０２ｂは、秘密鍵１１６ａがデバイスから略奪されることができないことをセキュリティプロフィールが示すことを要求し得る。セキュリティプロフィール１２０ａがそのように示す場合、被提供者１０２ｂは、デバイスが盗まれず、デバイスの適切な所有者によって使用されたことを確実にする。これは、被提供者１０２ｂを保護する。なぜなら、ＥＣ２４７ａの送信側がデバイスの所有者であり、従って、この被提供者は、この被提供者がこのオファーを受け取ることを判定する場合、メッセージの送信側が契約１００の条件に拘束されることを証明し得る。
【０１５９】
さらに、デバイス４５０ａの秘密鍵１１６ａのセキュリティに関する信頼性の高い程度に加えて、被提供者１０２ｂはまた、提供者エンティティ４２５が特定の契約１００（ＥＣ２４７ａの内容から構成される）に拘束されることを意図したことを知りたいと望み得る。これは、組み込まれたＶＳ出願に説明された検証ステータス局面によって達成される。検証ステータス局面は、図８を参照して上述されたようなデバイスのタイムアウト状態およびデバイスのシーケンス状態を示す。従って、図８を参照して上述されたようなシナリオでは、デバイス４５０ａは、ＥＣ２４７ａの一部としてインジケータを送信し、このインジケータはデバイスがタイムアウトされるかどうかを示す。さらに、このインジケータは、デバイスのＤＳフラグを示し得、このＤＳフラグは、デバイス４５０ａの秘密鍵１１６ａが使用されて、ＥＣのデジタル署名を生成する度にインクリメントされる。図８を参照して上述したように、タイムアウトおよびＤＳフラグパラメータが使用されて、送信側がＥＣ２４７ａに含まれた実際の契約文書１００を送信することを意図したことを示す。
【０１６０】
オファーの条件を受け取る際に、受理１１０は、このオファーを作成することに関して上記で説明したプロセスと同様であるプロセスによってなされ得る。被提供者１０２ｂは、デバイス４５０ｂからの秘密鍵１１６ｂを用いることによってＥＣ２４７ｂに受理１１０を定式化して、ステップ５においてＥＣをデジタルに署名する。次いで、受理ＥＣ２４７ｂは、ステップ６において元の提供者エンティティ４２５に送信される。ステップ６において受理２４７ｂを受信する際、次いで提供者エンティティ４２５は、ステップ７において、セキュリティ特性プロフィール１２０ｂを安全な環境エンティティ２３５から要求し得る。これは、被提供者１０２ｂが、ＥＣ２４７ａをデジタルに署名するために使用されたデバイス４５０ａのセキュリティ特性プロフィール１２０ａを要求したステップ４のプロセスと同様である。デバイス４５０ｂのセキュリティ特性プロフィールおよび検証ステータスインジケータにアクセスする同様なプロセスは、オファーＥＣ２４７ａに関して被提供者１０２ｂによって実行されたように実行される。
【０１６１】
ＥＣ２４７ｂの送信側に関連付けられたビジネス法則に従って、ＥＣ２４７ｂの送信側の検証およびデバイス４５０ｂのセキュリティ特性および検証ステータスインジケータによって、提供者エンティティ４２５は、有効な契約が形成された信頼性が提供される。従って、元の契約オファー１００の条件の履行は、開始され得る。被提供者１０２ｂが提供者エンティティ４２５がオファー１００を送信することが意図とされ、それにより、オファー１００の条件に拘束されることを容易に判定し得るように、提供者エンティティは、被提供者が受理１１０の条件に同意することを意図したことを信頼して判定し得る。
【０１６２】
デバイスのセキュリティに関連した情報は、安全なデータベース２３８において保守される。セキュリティプロフィール１２０と呼ばれるこの情報は、安全に、好ましくは、デバイス４５０を製造した同じエンティティ２３５によって保守され、情報は、セキュリティプロフィールが正確に使用される信頼性を提供する。データベースが保守される安全な態様は、例えば、低いセキュリティデバイスが非常に高いセキュリティを有するように不正に識別されない信頼性を増加させる。さらに、ＥＣの送信側に対応する特定の公開鍵１１８に関連付けられたビジネス法則は、秘密鍵１１６がデバイスの分解または解体によって検出できないことをセキュリティプロフィールが示すことを要求する。さらに、検証ステータスインジケータは、デバイスが最後にリセットされた後または有効な検証データが入力された後でデバイスが使用されたかどうかを示すＤＳフラグを含む。従って、セキュリティプロフィール、ビジネス法則の満足、および検証ステータスインジケータの組み合わせは、ＥＣの送信側が、自ら存在すると主張した送信側であり、ＥＣに含まれたメッセージを送信することを意図した高い程度の信頼性を受信側に提供する。従って、システム６０４は、提供者エンティティ４２５および被提供者１０２ｂがオファー１００および受理１１０によって表された同意によって形成された契約の条件に相互に同意された信頼性がありそして明らかな証拠を容易に構築するための方法およびシステムを提供する。
【０１６３】
（ＡＢＤＳではなくＰｒｉＭＲおよびＶＳを用いる契約シナリオのためのプロセス）
図１３を参照すると、プロセス１３０００に対するフローチャートが、ＥＣの送信側およびＥＣに含まれるメッセージを認証するために示されている。このプロセスは、図８、図９を参照して、そして組み込まれたＶＳ出願に詳細に説明されるように検証ステータスインジケータを更新かつ評価する。さらにこのプロセスは、図１０、図１１を参照して、そして組み込まれたＰＲｉＭＲアプリケーションに詳細に説明されるようにセキュリティプロフィールを評価する。
【０１６４】
このプロセスは、ステップ１３０５０において開始する。個人用デバイスは、安全な環境で製造される。このデバイスが安全な環境で製造された場合、ステップ１３１００において格納されたデバイスの内部秘密鍵に対応する公開鍵が格納される。さらにステップ１３１００において、デバイスの公開鍵およびデバイスのセキュリティ特性が互いに関連付けられるように、セキュリティ特性が安全な環境で保守された安全なデータベースに格納される。デバイスの公開鍵および対応するセキュリティ特性がデータベースに格納された後、デバイスは、ステップ１３１５０においてユーザに分配される。
【０１６５】
ユーザがデバイスを受け取った後、ステップ１３２００において、ユーザは、例えばデバイスに含まれたメッセージの内容として契約文書を含むＥＣを定式化することを望み得る。このメッセージが定式化された場合、ステップ１３２５０において、デバイスの公開鍵を用いてデジタルに署名される。さらにこのＥＣは、本明細書中で説明されたように検証ステータスインジケータを含み得る。ユーザがデバイスの現在の検証ステータスを更新することを望む場合、ユーザがデバイスの現在の検証ステータスを更新することに対する判定は、ステップ１３３００において実行される。ユーザデバイスがステップ１３３００においてデバイスの検証ステータスを更新することを判定する場合、このプロセスは、ステップ１３４５０に進む。しかし、ユーザは、ステップ１３３００においてデバイスの検証ステータスを更新することを判定する場合、ステップ１３３５０において更新されたデータはデバイスに入力される。次いで、更新された検証ステータスインジケータを含むＥＣは、ステップ１３４００においてデジタルに署名され、そしてステップ１３４５０において受信側に転送される。
【０１６６】
次に、受信側がステップ１３５００においてＥＣを受信し、ステップ１３５５０において送信側を検証する。送信側が検証された後、受信側は、ステップ１３６００において、検証ステータスインジケータを評価する。この評価は、本明細書中の他の箇所で説明されたように所定のビジネス法則の観点から説明され得る。ビジネス法則は、送信側の検証の信頼性のレベルを向上させるためにセキュリティプロフィールを必要とする。デバイスのセキュリティプロフィールは、ステップ１３６５０において安全なエンティティから要求される。次いで、検証における信頼性のレベルは、本明細書中の他の箇所で説明されたように要求されたセキュリティプロフィールの観点から評価された検証ステータスインジケータに基づいてステップ１３７００において判定される。信頼性レベルが判定された場合、ビジネス法則は、セキュリティプロフィールの観点から検証ステータスインジケータをステップ１３７００において実行された評価に基づいてＥＣの内容をどのようにして実行するかを判定する。
【０１６７】
ＥＣの内容をどのようにして実施するかを判定した後、ステップ１３８００におけるビジネス法則によって適用されたように、判定された信頼性のレベルに従ってその内容が実施される。ＥＣの受信側がステップ１３５００において受信されたＥＣ（例えばオファーの受理）に応答してＥＣを送信することを望む場合、別のＥＥＣを送信する判定は、ステップ１３８５０において為される。その判定が別のＥＣを送信するために為される場合、プロセスはステップ１３２００に戻り、上述のようにこのプロセスは、新しいＥＣの送信側である元の受信側およびＥＣの新しい受信側となる元の送信側を継続する。ステップ１３８５０においてこの受信側が別のＥＣを送信しないことを判定する場合、プロセスは終了する。
【０１６８】
（安全な入力デバイスに関連する個人用デバイスを用いるシステム）
図１４を参照すると、システム１４３において、安全な入力デバイス４７２および４７４を使用することが示される。安全な入力デバイス４７２および４７４は、１）安全なＰＩＮおよび／またはＢＩＯ検証データの安全なエントリ（例えば、不正取引の一部としてデータを再生可能にするＰＣのウイルス盗聴を不可能にすること）および２）署名されるべきＥＣメッセージの安全な表示（署名されるべきメッセージとは異なるメッセージを表示するＰＣウイルスを除去すること）を提供する。さらに、安全な入力デバイス４７２または４７４のいずれかがそれぞれ対応する秘密鍵４７３または４７５を用いてＥＣを署名する。受信側は、送信側のデジタル署名環境のセキュリティの証拠を有する。
【０１６９】
デバイスが安全でない環境で使用された場合、ＰＩＮおよび／またはＢＩＯ検証の日付が妥協され、不正な取引において以後使用され得ることに留意されたい。さらに、デバイスが安全でない環境において過去に使用された場合、増加されたリスクが存在する。
【０１７０】
高いセキュリティ状況では、受信側は高いセキュリティ入力デバイスが複数のＢＩＯ検証データの入力に関連して使用されることを知ることを望み得る。さらに、同じバイオメトリックファクタ（親指、左手の人差し指（ｌｅｆｔ  ｉｎｄｅｘ）、虹彩等）の複数の入力は、わずかに異なる整合値を有するのみであるべきである。従って、同一のＢＩＯ検証ステータスの整合値は、不正な取引の指標であり得る。
【０１７１】
従って、図１４に示されたシステム１４３は、検証データを入力するための安全な入力デバイスを提供する。例示の目的のために、提供者１０２ａは、ＰＣ４６６を用いて送信されるべきオファーを定式化する場合、安全な入力デバイス４７２を使用して、被提供者／受信側１０２ｂに送信されるべきオファーＥＣを署名する。署名プロセスを開始するために、提供者１０２ａは、ステップ１においてデバイス４５０ａ（送信側に個人化され、秘密鍵１１６ａを含む）を安全な入力デバイス４７２のスロット４８２に挿入する。デバイス４５０ａがスロット４８２に挿入され、文書の条件がディスプレイ４７６上に表示される間、提供者１０２ａは、ＰＩＮ等の検証データを、例えば、安全な入力デバイスの一部であるキーパッド４８３を用いて入力する。上記および組み込まれたＶＳ出願において説明されたように、次いで検証データが個人用デバイス４５０ａに安全に入力されて、検証ステータスインジケータが生成されて、ＥＣ２４７ａの一部となる。本明細書中の他の箇所で説明されたように、ＥＣ２４７ａは、送信側１０２ａのデバイス４５０ａによって、秘密鍵１１６ａを用いて署名される。ＥＣ２４７ａが安全な入力デバイス４７２の内部で生成された後、次いでＥＣ２４７ａは、契約オファー１００の内容がＥＣ２４７ａを生成する際にメッセージとして処理される態様とほとんど同じように、メッセージとしてＥＣ２４７ａを処理する別のＥＣ２４８ａによって封入される。デバイス４７２は、その秘密鍵４７３を使用して、ＥＣ２４８ａをデジタルに署名する。次いでＥＣ３４８ａは、ステップ２においてＰＣ４６６に送信される。ＥＣ２４８ａを受信する際に、ＰＣ４６６は、ＥＣを送信するように送信側を促進する。送信側がＥＣ２４８ａを送信することを選択する場合、ステップ３においてＥＣ２４８ａは、好適にはインターネット１０８を介して被提供者／受信側１０２ｂに送信される。
【０１７２】
受信側１０２ｂが送信側およびＥＣ２４８ａ、次いでＥＣ２４７ａのメッセージを受信し、認証した場合、ＥＣは、本明細書の他の場所で説明された態様でビジネス法則に従って評価され、いずれかの信頼性のレベルを判定し、ＥＣ２４８ａを割り当て得る。上述のように、個人用デバイス４５０ａのセキュリティプロフィールおよび安全な入力デバイス４７２は、ステップ４において受信側１０２ｂによって安全なエンティティ２３５から要求され得る。安全なエンティティ２３５が安全なデータベース２３８から要求されたセキュリティプロフィールを取り出す際、１つ以上のセキュリティプロフィールは、要求しているパーティ１０２ｂに送信される。個人用デバイス４５０ａおよび安全な入力デバイス４７２の要求されたセキュリティプロフィールを受信する際に、受信側１０２ｂは、ＥＣ２４８ａおよび２４７ａの検証性において配置するために、いずれかの信頼性のレベルを判定する。安全な入力デバイス４７２に対応するセキュリティプロフィールは、安全な入力デバイスが安全な入力デバイスに挿入された個人用デバイスに対応する検証データを受信することを可能にすることを示す場合、そしてその挿入された個人用デバイスに署名されるべきメッセージの内容を表示し、受信側にＥＣとして送信される場合、受信側１０２ｂは、ＥＣ２４７ａの送信側が個人用デバイス４５０ａの使用と関連して明らかな実施を実行し、ＥＣ２４７ａの内容を署名する高い信頼性レベルを有する。
【０１７３】
さらに、個人用デバイス４５０ａに対応するこのセキュリティプロフィールは、ハッカーによる攻撃に対して不透過性であり、例えば、受信側は、デバイス４５０ａの合法的な所有者が安全な入力デバイス４７２に関連したデバイスを使用してＥＣ２４７ａを署名することが高い信頼性レベルまで保証されることを示す。もちろん、これは、この有効な検証ステータスがキーパッド４８３に入力され、契約オファー１００は、ディスプレイ４７６上に表示され、送信側は、例えば正確なＰＩＮの入力の明らかな実施を実行したことを検証ステータスインジケータが示すことを保証する。従って、受信側は、提供者１０２ａがＥＣ２４８ａの送信側（従って２４７ａ）であったことを高い信頼性レベルまで保証する。さらに、受信側は、送信側がＥＣ２４７ａの内容に含まれた条件に拘束されることが意図されたことを高い信頼性レベルまで保証する。
【０１７４】
ＥＣ２４７ａおよびＥＦ２４８ａが、個人用デバイス４５０ａおよび安全な入力デバイス４７２に対するセキュリティプロフィールの観点から検証ステータスインジケータの評価を介して判定されてきたデバイスの送信側による意図の出現によって認証された場合、本例における被提供者１０２ｂは、ＰＣ４６７上のＥＣ２４７ａの内容を解析し得る。判定がオファー１００を受け取るように為された場合、オファーの条件は、ステップ５において受理１１０として安全なデバイス４７４のディスプレイ上に表示される。次いで、被提供者１０２ｂは、ステップ６，７、および８を実行し、これらのステップは、上述したステップ１、２、および３と同様である。元の提供者１０２ａは、ＥＣ２４７ａと同様の構造を有するＥＣ２４８ｂを受信する場合、ＥＣ２４８ｂおよびＥＣ２４７ｂが認証され、安全な入力デバイス４７４は、個人用デバイス４５０ｂおよび安全な入力デバイスにそれぞれ含まれた秘密鍵１１６ｂおよび４７５に対応する公開鍵に基づいた安全なエンティティに関して要求される。これらの安全なプロフィールは、デバイス４５０ｂの合法的な所有者がそのデバイスの秘密鍵１１６ｂにＥＣ２４７ｂを署名させるかどうか、被提供者１０２ｂがＥＣ２４８ｂの内容を署名することを意図する場合の出現のような明らかな実施を実行したかどうか、そして安全な入力デバイスがＥＣ２４８ｂに含まれた内容に被提供者１０２ｂによる意図の出現を安全に関連付けることに確信的に依存し、ＥＣ２４８ｂに含まれた内容に被提供者１０２ｂによる意図の出現を安全に関連付け得るかどうかを判定するために評価される。
【０１７５】
（安全な入力デバイスに関連する個人用デバイスを用いるためのプロセス）
図１５を参照すると、安全な入力デバイスに関連する個人用デバイスを用いるためのプロセス１５０００のフローチャートが示される。示されたプロセスにおける第１のステップは、ＥＣが送信されるべきであるかどうかを判定することである。ＥＣが送信されるべきではない場合、このプロセスは、安全な入力デバイスからのＥＣが受信されるステップ１５４５０に進む。ＥＣが送信されるべきである場合、このプロセスは、ＥＣを送信している個人またはエンティティが送信側に個人化されたデバイスを安全な入力デバイスに挿入するステップ１５１００に進む。デバイスが安全な入力デバイスに入力された後、ＥＣの内容がステップ１５１００において定式化される。この内容（たとえば、契約オファー）は、例えば、安全な入力デバイスに接続されたＰＣに定式化され得る。その内容が定式化された場合、オファーの条件は、安全な入力デバイスの表示部分に表示される。このオファーが安全な入力デバイスに表示された後、ステップ１５２５０において送信側は、検証データをこれらの安全な入力デバイスの入力部に入力する。例えば、入力された検証データがＰＩＮである場合、入力部は数値キーパッドを含み得る。この検証データが入力された場合、ステップ１５３００において、安全な入力デバイスは、第１のＥＣ、例えばこのオファーの内容を含み、挿入された個人用デバイスの秘密鍵を用いてデジタルに署名されたメッセージＥＣを生成する。このメッセージＥＣが生成された後、分離した別のメッセージとしてこのメッセージＥＣを処理する安全な入力デバイスは、この安全な入力デバイスの秘密鍵を用いて第２のＥＣをデジタルに署名する第２のＥＣ、および入力デバイスＥＣを生成し、この第２のＥＣは、このメッセージＥＣを含む。
【０１７６】
第２のＥＣがステップ１５３５０において生成された後、第２のＥＣは、ステップ１５４００において受信側に送信される。この受信側は、ステップ１５４５０において第２のＥＣを受信する。第２のＥＣの受信によって、この受信側は、ステップ１５５００において、第２のＥＣを認証する。ステップ１５５００において第２のＥＣが認証された後、このようなインジケータがステップ１５５５０においてそのように含まれた場合、この受信側は、第２のＥＣに含まれた検証ステータスインジケータを評価し得る。次いで、本明細書中他の箇所で説明されたように、ステップ１５６００において、第２のＥＣが関連付けられたセキュリティプロフィールを有するかどうかについての判定が為される。ステップ１５６００において、第２のＥＣがそれに関連付けられたセキュリティプロフィールを有しないことが判定される場合、プロセスは、第１のメッセージの送信側が認証されるステップ１５６２０に進む。
【０１７７】
しかし、第２のメッセージがセキュリティプロフィールを有する場合、ステップ１５６０５において、プロセスは、安全なエンティティから入力デバイスのセキュリティプロフィールを要求する。安全な入力デバイスに対する要求されたセキュリティプロフィールの受信に対して、受信側は、ステップ１５６１０において安全な入力デバイスのセキュリティプロフィールを評価した後、第１のＥＣの送信側がステップ１５６２０において認証される。次いで、第１のＥＣをデジタルに署名するために使用された個人用デバイスの検証ステータスインジケータがステップ１５６５０において評価される。このステップでは、第１のＥＣをデジタルに署名するために使用された個人用デバイスがセキュリティプロフィールを有するかどうかの判定が為される。個人用デバイスがセキュリティプロフィールを有することが判定された場合、組み込まれたＰＲｉＭＲアプリケーションにおいて詳細に説明されたように、このプロフィールは、ステップ１５７１０において安全なエンティティ／設備から要求される。第１のメッセージをデジタルに署名するために使用された個人用送信デバイスのセキュリティプロフィールが受信された場合、第１のＥＣに送信側の認証における信頼性のレベルは、ステップ１５７２０において、各デバイスのセキュリティプロフィールの観点から個人用送信デバイスおよび安全な入力デバイスの１つ以上の検証ステータスインジケータの１つ以上の評価に基づいて判定される。
【０１７８】
次に、ステップ１５７２０において為された信頼性レベルの判定は、ステップ１５７５０において、この信頼性レベルが受理可能であり、第１のＥＣの内容に関して受信側によって実施されることを可能にする。ステップ１５７５０における判定は、ビジネス法則の観点から為され得るが、ビジネス判定を行う当業者に公知の任意の他の方法が使用され得る。第１のＥＣの送信側の認証の信頼性のレベルおよび第１のＥＣの内容をデジタルに署名する意図の証拠として明らかな実施の送信側の履行の指標における信頼性のレベルが受理可能であることがステップ１５７５０において判定された場合、ＥＣの内容がステップ１５８００において実施される。ステップ１５７５０において判定された信頼性のレベルが受理可能でない場合、このプロセスは、ステップ１５８５０に進み、受信側が第１のメッセージの元の送信側にＥＣを送信することを望むかどうかの判定が為される。このプロセスは、第１のＥＣがステップ１５８００において作用された後、さらにステップ１５８５０に進む。従って、第１のメッセージの内容がオファーであった場合、ステップ１５８００において行われる行動がオファーの条件を受け取ることであり得る。ステップ１５８５０において判定が為され、別のＥＣとして受理を送信する。別のＥＣとして受理を送信する場合、このプロセスは、ステップ１５０５０に戻り、上述のようにここからこのプロセスを継続する。ステップ１５７５０における判定は、信頼性のレベルが受理可能でなく、第１のＥＣの内容に応じて実施する場合、その内容を再度送信する前に、これを元の送信側に報告し、送信側が更新された検証データを入力することを促進する判定が別のＥＣの形態で為され得る。この判定が為される場合、このプロセスはステップ１５０５０に戻る。ステップ１５８５０における判定が別のＥＣを送信することではない場合、プロセスが終了する。
【０１７９】
（ＰｒｉＭＲ、ＶＳ、およびＡＢＤＳを用いるシナリオ）
図１６を参照すると、パーティ間で電子的に契約するためのシステム６０５が示される。このシステムは、組み込まれたＰＲｉＭＲ、ＶＳ、およびＡＢＤＳアプリケーションにおいて示されるように、公開鍵にリンクされたセキュリティプロフィール、検証ステータスインジケータ、およびアカウントベースのデジタル署名システムを使用する。システム６０５は、ネットワーク（好ましくはインターネット１０８）を使用して、契約パーティ間のメッセージを転送および受信し得る。この局面は、別のパーティを他のパーティのアカウント情報に関連付ける１つのパーティによって保守されたデータベースを使用する。このアカウント情報は、例えば、信用限度額、引き出しのための利用可能な現金、他のパーティに関連する位置情報（電話番号、他のパーティの番地（ｓｔｒｅｅｔ  ａｄｄｒｅｓｓ）の任意のタイプであり得る。
【０１８０】
さらに、アカウント情報はまた、どのレベルの信頼性かを判定して、ＥＣに配置させるビジネス法則を含み得る。例えば、組み込まれたＰＲｉＭＲアプリケーションにおいて示されるように、ＥＣの受信側のビジネス法則は、ＥＣを生成させるために使用されたデバイスが安全な環境１１５において製造されことを必要とし得る。この構築タイプの使用およびアカウント情報のアクセスは、組み込まれたＡＢＤＳアプリケーションにおいて詳細に説明される。さらに、ビジネス法則は、検証ステータスインジケータの所定のパラメータを使用して、ＥＣが生成される前に有効な検証データがデバイスに入力されるかどうか、およびＥＣがその検証データが入力であった後で特定のデバイスによって生成された第１のＥＣであったかどうかを判定し得る。検証データおよび検証ステータスインジケータが、組み込まれたＶＳ出願において詳細に説明される。従って、図１６において示された局面において、それぞれの要素、検証ステータスインジケータ局面、アカウントベースのデジタル署名局面、および公開鍵にリンクされたセキュリティプロフィール局面は、信頼性のレベルに貢献し、ＥＣの受信側は、ＥＣにおいて識別されたように、ＥＣの送信側の検証性を認め得る。
【０１８１】
円で囲まれた数１に示されたステップ１で開始すると、デジタル署名を生成させるために使用された秘密鍵１１６ａおよび１１６ｂの非対称鍵の対がデバイス４５０ａおよび４５０ｂに格納される。デバイスが製造された場合、この秘密鍵１１６ａは、好ましくは、デバイス４５０ａに格納される。組み込まれたＰＲｉＭＲアプリケーションにおいて詳細に説明されたように、このデバイス４５０ａは、好ましくは、安全な製造設備２３５において製造される。安全な設備２３５におけるデバイス４５０ａおよび４５０ｂの製造によって、その鍵の対の公開鍵１１８ａおよび１１８ｂは、データベース２３８に格納され、このデータベースは、好ましくは、安全な環境１１５において保守され、安全な環境は、さらに安全な設備を含む。これらのデバイス４５０ａおよび４５０ｂは、必ずしも同時に製造される必要がない。デバイスを製造するプロセスは、図示の目的のために単一のステップ１としてこの図において示される。
【０１８２】
従って、複数のパーティは、別のデバイスを有する。各デバイスは、複数の別のパーティに対して特有であり、個人的である。各パーティがこのパーティに対して特定のでありそして個人的である別のデバイスを有するこのようなシナリオは、安全に保守されたデータベース２３８を利用する。例えば、提供者エンティティ４２５の従業員がオファー１００を被提供者１０２ｂに行うことを判定する場合、そのオファーは、ＥＣ２４７ａの形態で被提供者に電子的に送信され得る。さらに、このパーティはまた、ステップ１ａにおいてある関係を形成し、各パーティは、他のパーティを有するアカウントを有する。従って、各パーティは、他のパーティに対してＡＡとして振舞う。さらに、ステップ１ａにおいて各パーティが他のパーティを有するアカウントを確立した場合、このパーティは、パーティのデバイスの秘密鍵に対応する他のパーティのそれぞれの公開鍵１１８ａを提供した。例示的な例では、この図では事務所のデスクによって示された提供者エンティティ４２５は、秘密鍵１１６ａに対応する公開鍵を提供し、被提供者１０２ｂは、秘密鍵１１６ｂに対応する公開鍵１１８ｂを同様に提供する。
【０１８３】
従って、提供者エンティティ４２５の公開鍵１１８ａは、被提供者１０２ｂによってデータベース１１４ｂにおいて保守される。同様に被提供者１０２ｂの公開鍵１１８ｂは、提供者エンティティ４２５によってデータベース１１４ａにおいて保守される。従って、提供者エンティティ４２５は、データベース１１４ａにおいて被提供者１０２ｂの公開鍵を提供者のアカウント情報に有利に関連付け得る。同様に、被提供者１０２ｂは、データベース１１４ｂにおいて提供者エンティティ４２５の公開鍵１１８ａを被提供者のアカウント情報に有利に関連付け得る。従って、いずれのデバイス４５０ａまたはデバイス４５０ｂの相補的な公開鍵が秘密鍵１１６ａおよび１１６ｂそれぞれに関連付けられるため、各パーティは、他のパーティのアカウント情報を他のパーティのデバイスに関連付け得る。
【０１８４】
デバイスが製造され、その関係が発展し、アカウントがステップ１ａおよび１ｂにおいて確立された後、提供者エンティティ４２５は、オファー１００を作成するように準備し、ＥＣとしてオファー１００を被提供者１０２ｂに送信する。提供者１００を作成する実際の個人は、この図に示されおよび図８における説明において詳細に説明されたように、任意の３人の個人（代理人３０２ａ、秘書３０２ｂ、またはマネージャ３０２ｃ）であり得る。従って、オファーを作成する個人に依存するステップ２ａ、２ｂ、または２ｃにおいて、オファー１００は、メッセージに変換され、デバイス４５０ａの秘密鍵１１６ａを用いてデジタルに署名される。この３人の個人パーティは、図８に関連して上述されたように、本発明の検証ステータス局面の使用を図示するために使用される。検証ステータスインジケータは、秘密鍵が使用されて、ＥＣ２４７ａのデジタル署名を生成する場合に、デバイス４５０ａによって生成される。検証ステータスは、図８を参照して説明され、組み込まれたＶＳ出願においてより十分に説明されたように、インジケータ４６２ａとして送信される。図８を参照して上述されたように、インジケータ４６２ａが使用されて、ＥＣ２４７ａの送信側が契約オファー１００に対して拘束されるように意図した保証を提供する。
【０１８５】
ＥＣ２４７ａがステップ２ａ、２ｂ、または２ｃにおいてオファーメッセージ、デジタル署名、識別子、および検証ステータスインジケータ４６２ａを含むように定式化された後、ＥＣは、ステップ３において被提供者１０２ｂに送信される。ＥＣ２４７ａを受信する際、被提供者１０２ｂは、オファー１００を受け取るかまたはオファー１００を拒絶するかどうかを判定する。この識別子は、典型的にはアカウント番号であり、この識別子は、データベース１１４ｂから公開鍵１１８ａを参照するために使用される。次いで、被提供者１０２ｂは、データベース１１４ｂから取り出された提供者のエンティティ４２５の公開鍵１１８ａを用いてデジタル署名を復号化する。データベース１１４ｂは、好ましくは３つの重要なフィールドを有する。これらのフィールドは、識別子、公開鍵、およびデータベース１１４ｂのアカウントデータベース記録に対して関連付けられたアカウント情報を含む。しかし、データベースは、２つのフィールドのみを含み得る。このフールドでは、公開鍵は、識別子として二重化する。提供者ＥＣ２４７ａが被提供者１０２ｂによって取り出された場合、好適には、提供者の秘密鍵を用いて暗号化されない識別子は、この識別子に対応する公開鍵１１８ａを配置するように使用される。次いで整合している公開鍵は、ＥＣ２４７ａの送信側を認証するために使用される。これは、送信側が提供者エンティティ４２５である信頼性を提供する。なぜなら、ＥＣ２４７ａの送信側を認証した公開鍵は、提供者のエンティティのアカウント番号に関連付けられる。
【０１８６】
しかし、被提供者１０２ｂは、送信側が提供者のエンティティ４２５であるより多くの保証を望み得る。従って、被提供者１０２ｂは、ステップ４において安全なエンティティ２３５に要求２２６を送信する。この要求２２６は、オファーＥＣ２４７ａを送信するために使用されたデバイスのセキュリティプロフィール１２０ａを要求するＥＣである。セキュリティプロフィール１２０ａの作成および使用は、組み込まれたＰＲｉＭＲアプリケーションにおいて詳細に説明される。セキュリティプロフィール１２０ａは、レコードとしてデータベース２３８に含まれ、このセキュリティプロフィールは、デバイス４５０ａが安全な製造設備２３５において作成されたと同時に作成された。セキュリティプロフィール１２０ａは、デバイス４５０ａのセキュリティ特性を被提供者１０２ｂに提供する。この情報は、被提供者１０２ｂによって使用され、オファーＥＣ２４７ａのデジタル署名を生成するために使用されたデバイス４５０ａのセキュリティのレベルを判定する。この情報は、安全なエンティティ２３５および安全な環境１１５のセキュリティ属性、ならびに、デバイスを製造するために使用された手順、デバイス自体のタイプ、および製造プロセスの間に秘密鍵１１６ａのセキュリティを保守するために使用された手順を含み得る。さらに、デバイス４５０ａの改ざんに対する抵抗および秘密鍵１１６ａがハッキングに対していかにして安全になるかに関連する。
【０１８７】
図１６に示される局面の説明を続けると、提供者エンティティ４２５に関連付けられた、データベース１１４ｂにおいて保守されたビジネス法則は、ＥＣ２４７ａを送信するために使用されたデバイス４５０ａのセキュリティ属性の判定を要求し得る。公開鍵１１８ａに関連するビジネス法則は、ＥＣ２４７ａを生成するために使用されたデバイス４５０ａが改ざん抵抗があるかどうかを判定するためにセキュリティプロフィール１２０Ａを要求し得る。要求２２６に応答して送信されたセキュリティプロフィール１２０ａは、デバイスが改ざん抵抗があることを示す場合、被提供者１０２ｂは、デバイスがその中に含まれる秘密鍵１１６ａの秘匿性を保護することが可能であることを保証する。例えば、デバイス４５０ａが適切な所有者ではなく誰かの手にわたる場合、他の誰かは、デバイスの分解によって秘密鍵を識別することができない。従って、被提供者１０２ｂは、いくつかの他のデバイス４５０ａから奪われ得た秘密鍵１１６ａを用いるいくつかの他のデバイスではなく、デバイス４５０ａが使用されてＥＣのデジタル署名を生成することを合理的に保証する。
【０１８８】
全体の信頼性に貢献するセキュリティプロフィールに加えて、被提供者１０２ｂがＥＣの起源に配置され、検証ステータスインジケータ４６２ａは、ＥＣ２４７ａを署名する場合、任意の検証データがデバイスに入力されたかどうかを示す。さらに、インジケータ４６２ａは、有効な検証データが入力されたかどうかを示し、ＤＳフラグは、デバイス４５０ａがリセットされた後、正確なデータが入力されたかどうかを示すために使用される。さらに、ＥＣ２４７ａがデバイス４５０ａによってデジタルに署名された場合、検証ステータスインジケータ４６２ａは、無効な検証データが入力されたかどうかを示す。従って、セキュリティプロフィール１２０ａは、秘密鍵１１６ａがデバイス４５０ａから抽出できないことを示し、そしてステップ２ａ、２ｂ、または２ｃにおいてデバイス４５０ａによって送信された検証ステータスインジケータ４６２ａは、有効検証データがＥＣ２４７ａの生成の直前にデバイスに入力されたことを示す場合、被提供者１０２ｂは、ＥＣ２４７ａを生成した人またはエンティティがデータベース１１４ｂにおいて公開鍵１１８ａに関連付けられた人またはエンティティである。
【０１８９】
検証インジケータに関して、検証データパラメータは、組み込まれたＶＳ出願に説明されたような、ＰＩＮまたはバイオメトリックデータを含む。このセキュリティプロフィールは、さらにデバイス４５０ａが受信を可能にする検証データのタイプに関する情報を含み得る。従って、ステップ４において、データベース２３８から被提供者１０２ｂに送信されたセキュリティプロフィール１２０ａは、デバイス４５０ａがＰＩＮが入力され得る能力を用いて製造されたことを示す場合、被提供者は、そのセキュリティプロフィールがステップ３において送信される前に、正確なＰＩＮに知識を有する誰かがＥＣ２４７ａをデジタルに署名することを合法的にデバイス使用することを確実にする。さらに、デバイス４５０ａは、バイオメトリックデータが入力され得る能力を用いて製造され得、デバイス４５０ａを用いてＥＣ２４７ａを署名する者がデバイスの正当な所有者であった受信側をさらに保証する。これは、デバイス４５０ａの合法的な所有者がデバイスを使用してＥＣ２４７ａをデジタルに署名する信頼性のさらにより高いレベルを生じる。従って、検証ステータスは、正確なＰＩＮ、有効なＢＩＯ、または他のタイプの検証データが、デバイス４５０ａに入力される場合、被提供者１０２ｂは、ＥＣ２４７ａがデバイスを合法的に所有した何者かによってデバイス４５０ａを用いてデジタルに署名されたことを保証する。
【０１９０】
さらに、デバイス４５０ａを合法的に用いてＥＣをデジタルに署名する人またはエンティティは、データベース１１４ｂにおける公開鍵１１８ａに関連付けられた人またはエンティティである。さらに、セキュリティプロフィール１２０ａは、秘密鍵１１６ａがデバイス４５０ａの電気的または機械的な分解または解体によって妥協されることができないことを示す場合、被提供者１０２ｂは、ＥＣ２４７ａの送信側がデータベース１１４ａの公開鍵１１８ａに関連付けられた人またはエンティティであることをさらに確実にする。
【０１９１】
図１６に示されたシステムをさらに説明すると、この高い程度の信頼性は、取引の値が所定の額よりも大きいオファーに対して要求され得る。従って、取引額が小さい場合、被提供者１０２ｂは、ＥＣ２４７ａの識別子に関連付けられた公開鍵が使用されてＥＣの送信側を認証することを要求するのみであり得る。さらに、取引額が低い場合、被提供者は、ステップ４において、安全な環境１１５からセキュリティプロフィールをさらに要求し得ない。これは、コストを低く維持するために、安全なエンティティ２３５は、典型的には、データベース２３８からのデータの各アクセスに対して課金し得る。
【０１９２】
しかし、オファー１００の取引額が比較的大きい場合、典型的には、被提供者１０２ｂは、デジタル署名を生成するために使用されたデバイスのセキュリティプロフィール１２０ａが、ＰＩＮまたはバイオメトリックデータであってもデバイス４５０ａによって支援されることを示すことを要求する。さらに、被提供者１０２ｂは、秘密鍵１１６ａがデバイスから略奪されることができないことをセキュリティプロフィールが示すことを要求し得る。セキュリティプロフィール１２０ａがそのように示す場合、被提供者１０２ｂは、デバイスが盗まれず、デバイスの適切な所有者によって使用されたことを確実にする。これは、被提供者１０２ｂを保護する。なぜなら、ＥＣ２４７ａの送信側がデバイスの所有者であり、従って、この被提供者は、この被提供者がこのオファーを受け取ることを判定する場合、メッセージの送信側が契約１００の条件に拘束されることを証明し得る。
【０１９３】
さらに、デバイス４５０ａの秘密鍵１１６ａのセキュリティに関する信頼性の高い程度に加えて、被提供者１０２ｂはまた、提供者エンティティ４２５が特定の契約１００（ＥＣ２４７ａの内容から構成される）に拘束されることを意図したことを知りたいと望み得る。これは、組み込まれたＶＳ出願に説明された検証ステータス特性によって達成される。検証ステータス特性は、図８を参照して上述されたようなデバイスのタイムアウト状態およびデバイスのシーケンス状態を示す。従って、図８を参照して上述されたようなシナリオでは、デバイス４５０ａは、ＥＣ２４７ａの一部としてインジケータを送信し、このインジケータはデバイスがタイムアウトされるかどうかを示す。
【０１９４】
さらに、このインジケータは、デバイスのＤＳフラグを示し得、このＤＳフラグは、デバイス４５０ａの秘密鍵１１６ａが使用されて、ＥＣのデジタル署名を生成する度にインクリメントされる。図８を参照して上述したように、タイムアウトおよびＤＳフラグパラメータが使用されて、送信側がＥＣ２４７ａに含まれた実際の契約文書１００を送信することを意図したことを示す。
【０１９５】
オファーの条件を受け取る際に、受理１１０は、このオファーを作成することに関して上記で説明したプロセスと同様であるプロセスによってなされ得る。被提供者１０２ｂは、デバイス４５０ｂからの秘密鍵１１６ｂを用いることによってＥＣ２４７ｂに受理１１０を定式化して、ステップ５においてＥＣをデジタルに署名する。次いで、受理ＥＣ２４７ｂは、ステップ６において元の提供者エンティティ４２５に送信される。ステップ６において受理２４７ｂを受信する際、次いで提供者エンティティ４２５は、ステップ７において、セキュリティ特性プロフィール１２０ｂを安全な環境エンティティ２３５から要求し得る。これは、被提供者１０２ｂが、ＥＣ２４７ａをデジタルに署名するために使用されたデバイス４５０ａのセキュリティ特性プロフィール１２０ａを要求したステップ４のプロセスと同様である。デバイス４５０ｂのセキュリティ特性プロフィールおよび検証ステータスインジケータにアクセスする同様なプロセスは、オファーＥＣ２４７ａに関して被提供者１０２ｂによって実行されたように実行される。
【０１９６】
データベース１１４ａに含まれた送信側に関連付けられたビジネス法則に従って、デバイス４５０ｂのセキュリティ特性および検証ステータスインジケータによって、提供者エンティティ４２５は、有効な契約が形成された信頼性が提供される。従って、元の契約オファー１００の条件の履行が開始され得る。被提供者１０２ｂは、提供者エンティティ４２５がオファー１００を送信することが意図とされ、それにより、オファー１００の条件に拘束されることを容易に判定し得るように、提供者エンティティは、被提供者が受理１１０の条件に同意することを意図したことを信頼して判定し得る。
【０１９７】
従って、システム６０５は、ＥＣの送信側そしてさらに送信側が契約１００を送信するように意図された確信的な指標を高い程度の信頼性で認証するための方法およびシステムを提供する。図１６に示された局面は、所定のパラメータが契約文書の条件に同意する前に成功して判定される要求が電子契約を促進するために使用されるビジネス法則を含み得るアカウント情報データを示す。このアカウント情報は公開鍵１１８に関連付けられ、次いでこの情報は識別子に対応し、公開鍵および関連したアカウント情報を含むデータベース１１４ｂがインデックス付けられる。データベース１１４ｂにおける公開鍵１１８は、世界の残りからの秘密鍵１１６の秘匿性を保守するデバイス４５０の秘密鍵に対応する。
【０１９８】
デバイスがそのデバイスのセキュリティを生成し得る程度に関連した情報は、データベース２３８において保守される。セキュリティプロフィール１２０と呼ばれるこの情報は、安全に、好ましくは、デバイス４５０を製造した同じエンティティ２３５によって保守され、この情報は、セキュリティプロフィール関連するデバイスが正確である保証を提供する。さらに、ＥＣにおける識別子に対応する特定の公開鍵１１８に関連付けられた、データベース１１４ｂに含まれたビジネス法則は、秘密鍵１１６がデバイスの分解または解体によって検出できないことをセキュリティプロフィールが示すことを要求し得る。
【０１９９】
さらに、検証ステータスインジケータ４６２は、有効な検証データがデバイス４５０に入力されたかどうかを示し得る。これは、デバイス４５０が割り当てられた適切なユーザがデバイスを使用して、ＥＣをデジタルに署名し、適切なユーザはデータベース１１４ｂにおける識別子アカウント番号に対応する。さらに、検証ステータスインジケータは、デバイスが最後にリセットされた後でデバイスが使用されたかどうか、または有効な検証データが入力された後でデバイスが使用されたかどうかを示すＤＳフラグを含む。従って、セキュリティプロフィールは、デジタル署名を生成するために使用されたデバイスに対応する公開鍵に、データベース１１４ｂにおいて関連付けられたビジネス法則を満足する場合、およびデバイスの検証ステータスインジケータは、同じビジネス法則のパラメータを満足する場合、受信側は、ＥＣをデジタルに署名するためのデバイスを使用したＥＣの送信側がデータベース１１４ｂにおけるアカウント識別子に関連付けられた人またはエンティティである保証の高い程度が受信側に提供される。従って、非常に安全で信頼できる方法は、ポジティブな高い程度の信頼性のリンク、金融情報を含むアカウント情報を有する契約文書を含むＥＣの送信側、またはこの契約文書に含まれた契約条件の履行に関連し得る他の情報によって示される。
【０２００】
（ＰｒｉＭＲ、ＶＳ、およびＡＢＤＳを用いる契約シナリオのためのプロセス）
図１７を参照すると、プロセス１７０００に対するフローチャートが、ＥＣの送信側およびＥＣに含まれるメッセージを認証するために示されている。このプロセスは、図１３を参照して説明されるように、検証ステータスインジケータを更新して評価する。さらにこのプロセスは、例えば２つの契約パーティ間の関係を構築する。この２つの契約パーティは、公開鍵を互いに交換する。公開鍵を交換する場合、１つのパーティは、他の契約パーティの１つまたは全てに対するアカウント機関であるように、このパーティは互いのアカウントを確立する。次いでＡＡは、ＥＣ（このＥＣは、アカウント番号等の識別子を含む）がパーティから受信された場合、この識別子は、公開鍵を取り出すために使用されるように、１つ以上の他のパーティの公開鍵およびアカウント情報を互いに関連付ける。次いでこの公開鍵は、ＥＣの送信側を認証するために使用される。ＡＡがパーティとのアカウントを構築し、次いでパーティの公開鍵に関連付けられたアカウント情報を使用する関係を構築することは、上記図１〜６を参照し、さらに組み込まれたＡＢＤＳアプリケーションにおいてより詳細により十分に説明される。
【０２０１】
このプロセスは、ステップ１７０５０において開始する。個人用デバイスは、安全な環境で製造される。このデバイスが安全な環境で製造された場合、ステップ１７１００において格納されたデバイスの内部秘密鍵に対応する公開鍵が格納される。さらにステップ１７１００において、デバイスの公開鍵およびデバイスのセキュリティ特性が互いに関連付けられるように、セキュリティ特徴が安全な環境で保守された安全なデータベースに格納される。デバイスの公開鍵および対応するセキュリティ特徴がデータベースに格納された後、デバイスは、ステップ１７１５０においてユーザに分配される。
【０２０２】
ユーザがデバイスを受け取った後、ステップ１７２００において、ユーザは、別のパーティに関するアカウントを確立し得る。他のパーティは第１のパーティに対してＡＡ機関として実施され得る。そしてＡＡ機関は第１のパーティに対して他のパーティとして実施され得る。あるいは、第三者ＡＡは、本明細書の他の箇所で説明されたような公開鍵および識別子に全てのアカウントを関連付けるデータベースを保守し得る。デバイスを受け取りそして他のパーティによって確立した後、デバイスのユーザは、ステップ１７２５０において、例えばＥＣに含まれたメッセージの内容として契約文書を含むＥＣを定式化することを望み得る。ＥＣのメッセージが定式化された場合、ＥＣは、ステップ１７３５０において、デバイスの公開鍵を用いてデジタルに署名される。さらにこのＥＣは、本明細書中の他の箇所で説明されたように検証ステータスインジケータを含み得る。ユーザがデバイスの現在の検証ステータスを更新することを望む場合、ユーザがデバイスの現在の検証ステータスを更新するこの判定は、ステップ１７４００において履行される。この判定は、ＥＣが送信されたパーティからの受信されたアカウント情報（例えば、ビジネス法則）に基づき得る。この情報は、パーティ間の関係がステップ１７２００において確立された場合に受信される。ユーザがステップ１７４００においてデバイスの検証ステータスを更新しないことを判定する場合、このプロセスは、ステップ１７４２０に進む。
【０２０３】
しかし、ユーザは、ステップ１７４００においてデバイスの検証ステータスを更新することを判定する場合、ステップ１７４１０において更新されたデータはデバイスに入力される。次いで、更新された検証ステータスインジケータを含むＥＣは、ステップ１７４２００においてデジタルに署名され、そしてステップ１７４５０において受信側に転送される。
【０２０４】
次に、受信側がステップ１７５００においてＥＣを受信し、ステップ１７５５０の受信側に対して、受信側は、受信されたＥＣに含まれたアカウント識別子に基づいてデータベースを検索することによって、受信側によって保守されたデータベースから送信側の公開鍵を取り出す。送信側の公開鍵が取り出された後、本明細書の他の箇所に記載されたように、ステップ１７６００において、送信側の公開鍵は、ＥＣの送信側およびＥＣのメッセージを認証するために使用される。送信側が検証された後、受信側は、ステップ１７６５０において、検証ステータスインジケータを評価する。この評価は、本明細書中の他の箇所で説明されたように所定のビジネス法則の観点から履行され得る。ビジネス法則は、送信側の検証の信頼性のレベルを向上させるためにセキュリティプロフィールを必要とする。デバイスのセキュリティプロフィールは、ステップ１７７００において安全なエンティティから要求される。次いで、検証における信頼性のレベルは、本明細書中の他の箇所で説明されたように、要求されたセキュリティプロフィールの観点から評価された検証ステータスインジケータに基づいてステップ１７７５０において判定される。信頼性レベルが判定された後、受信側は、セキュリティプロフィールの観点から検証ステータスインジケータをステップ１７７５０において実行された評価に基づいてＥＣの内容をどのようにして実行するかをステップ１７８００において判定する。
【０２０５】
ステップ１７８００において、ステップ１７７５０において判定された信頼性のレベルは、受理可能であることが見出されない場合、このプロセス１７０００は、ステップ１７９００に進む。しかし、この信頼性レベルがステップ１７８００において受理可能であることが判定された場合、ステップ１７５００において受信されたＥＣからの公開鍵は、ステップ１７８１０において、受信側によって保守されたデータベースから受信されたＥＣからの識別子および公開鍵に関連付けられた任意のアカウント情報を取り出すために使用される。次いでこのアカウント情報はステップ１７８２０において評価され、ＥＣの主題に関してどのようにして実行するかの判定がステップ１７８３０において為される。
【０２０６】
どのようにして実行するかの判定がステップ１７８３０において判定された後、その内容がビジネス法則に従って適用されるような、判定された信頼性のレベルに従って、またはビジネス判定を作成する当業者に公知の任意の他の方法論に従って、ステップ１７８４０において実施される。内容がステップ１７８４０において実施された後、ＥＣを署名するために使用された公開鍵に関連付けられたアカウント情報は、ステップ１７８５０において更新される。例えば、ＥＣの送信側が受信側に対する信用限度額を有し、受信側からの所定の額に対して商品を購入するためのオファーを含んだ場合、ステップ１７８５０において受信側は信用限度額を低減し得、ＥＣの送信側に関して受信可能なアカウントを反映し得る。
【０２０７】
ＥＣを署名するために使用された公開鍵に関連付けられたアカウント情報を更新した後、ＥＣの受信側がステップ１７５００において受信されたＥＣに応答してＥＣを送信することを望む場合、別のＥＣを送信する判定（例えば受理）がステップ１７９００において為される。別のＥＣを送信する判定が為された場合、このプロセスは、上述のように現在新しいＥＣの送信側である元の受信側、およびＥＣの新しい受信側になる元の送信側によって継続されるステップ１７２５０に戻る。受信側は、ステップ１７９００において別のＥＣを送信しないことを判定する場合、このプロセスは終了する。
【０２０８】
本発明の好適な実施形態の上述の詳細な説明の観点から、本発明は広い利用性および用途に影響を受けやすいことが当業者によって容易に理解される。本明細書中で説明された以外の本発明の多くの実施形態および適用、なたびに、多くの変動、改変および等価な構成は、本発明の実体または範囲から逸脱することなく、本発明および上記の説明から明らかであるかまたはこれにより合理的に提示される。さらに、当業者は、本明細書中で説明されそして主張された種々のプロセスの１つ以上の順序および／または一時的な順序が本発明を実行するためにこれらの順序によって企図されたベストモードであると発明者によって考慮されることを評価し理解する。種々のプロセスが好適な順序または一時的な順序において存在するようないくつかの場合において示され説明されるが、このようなプロセスのステップは、１つ以上のステップが任意の順序または順番で実行されて特定の意図された結果を達成すべきである特定の指示がないような任意の特定の順序またはオーダーで実行されることに限定されない。
【０２０９】
従って、本発明が好適な実施形態に関連して本明細書中で詳細に説明されてきたが、この本発明の開示は、例証的かつ例示的のみであり、本発明の十分な開示および可能な開示を提供する目的のためのみに為される。上述の開示は、本発明を限定することも構成することも意図されず、あるいは任意このような他の実施形態、適用、変動、改変および等価な構成を排除する。本発明は、添付の特許請求の範囲およびその等価物によって限定されるのみである。
【図面の簡単な説明】
【図１】
図１は、各パーティがアカウント機関として他のパーティに作用する、提供者と被提供者との間の基本的な契約シナリオを示す。
【図２】
図２は、各契約パーティが他のパーティに対してアカウント機関として作用する、契約シナリオを実現するためのプロセスを示すフローチャートを示す。
【図３】
図３は、パーティがビジネス法則を使用して契約の条件を自動的に同意し、これを実行する、パーティ間の契約シナリオを示す。
【図４】
図４は、ビジネス法則を使用して、契約に自動的に同意し、実行する契約シナリオを実現するためのプロセスを示すフローチャートである。
【図５】
図５は、契約に対する各パーティがアカウント機関を使用して公開鍵およびアカウント情報を識別子と関連付ける契約シナリオを示す。
【図６】
図６は、契約に対する各パーティがアカウント機関を使用して公開鍵およびアカウント情報を識別子と関連付ける契約シナリオを実現するためのプロセスを示すフローチャートを示す。
【図７】
図７は、電子契約において一般的に使用された好適な用語の定義の説明を示す。
【図８】
図８は、検証ステータスインジケータを実現するためのデバイスを使用する契約シナリオを示す。
【図９】
図９は、契約シナリオにおける検証ステータスインジケータを実現するデバイスを使用するためのプロセスを示すフローチャートを示す。
【図１０】
図１０は、デバイスのセキュリティプロフィールを使用する契約シナリオを示す。
【図１１】
図１１は、契約シナリオにおいてセキュリティプロフィールを有するデバイスを使用するためのプロセスを示すフローチャートを示す。
【図１２】
図１２は、送信側および送信側のメッセージを認証したＥＣを認証するための安全な入力デバイスを使用する契約シナリオを示す。
【図１３】
図１３は、送信側の秘密鍵を使用して送信されたＥＣを認証するために安全な入力デバイスのためのプロセスを示すフローチャートを示す。
【図１４】
図１４は、検証ステータスインジケータおよびセキュリティプロフィールの組み合わせを使用する契約シナリオを示す。
【図１５】
図１５は、契約シナリオにおいて、検証ステータスインジケータおよびセキュリティプロフィールの組み合わせを使用するためのプロセスを示すフローチャートを示す。
【図１６】
図１６は、検証ステータス、セキュリティプロフィール、およびアカウントベースのデジタル署名システムの組み合わせを使用する契約シナリオを示す。
【図１７】
図１７は、契約シナリオにおける検証ステータスインジケータ、セキュリティプロフィール、およびアカウントベースのデジタル署名システムの組み合わせを使用するためのプロセスを示すフローチャートを示す。
【図１】
2004517381.tif 000003
【図２】
2004517381.tif 000004
【図３】
2004517381.tif 000005
【図４】
2004517381.tif 000006
【図５】
2004517381.tif 000007
【図６】
2004517381.tif 000008
【図７】
2004517381.tif 000009
【図８】
2004517381.tif 000010
【図９】
2004517381.tif 000011
【図１０】
2004517381.tif 000012
【図１１】
2004517381.tif 000013
【図１２】
2004517381.tif 000014
【図１３】
2004517381.tif 000015
【図１４】
2004517381.tif 000016
【図１５】
2004517381.tif 000017
【図１６】
2004517381.tif 000018
【図１７】
2004517381.tif 000019
【国際公開パンフレット】
2004517381.tif 000020
2004517381.tif 000021
2004517381.tif 000022
2004517381.tif 000023
2004517381.tif 000024
2004517381.tif 000025
2004517381.tif 000026
2004517381.tif 000027
2004517381.tif 000028
2004517381.tif 000029
2004517381.tif 000030
2004517381.tif 000031
2004517381.tif 000032
2004517381.tif 000033
2004517381.tif 000034
2004517381.tif 000035
2004517381.tif 000036
2004517381.tif 000037
2004517381.tif 000038
2004517381.tif 000039
2004517381.tif 000040
2004517381.tif 000041
2004517381.tif 000042
2004517381.tif 000043
2004517381.tif 000044
2004517381.tif 000045
2004517381.tif 000046
2004517381.tif 000047
2004517381.tif 000048
2004517381.tif 000049
2004517381.tif 000050
2004517381.tif 000051
2004517381.tif 000052
2004517381.tif 000053
2004517381.tif 000054
2004517381.tif 000055
2004517381.tif 000056
2004517381.tif 000057
2004517381.tif 000058
2004517381.tif 000059
2004517381.tif 000060
2004517381.tif 000061
2004517381.tif 000062
2004517381.tif 000063
2004517381.tif 000064
2004517381.tif 000065
2004517381.tif 000066
2004517381.tif 000067
2004517381.tif 000068
2004517381.tif 000069
2004517381.tif 000070
2004517381.tif 000071
2004517381.tif 000072
2004517381.tif 000073
2004517381.tif 000074
2004517381.tif 000075
2004517381.tif 000076
2004517381.tif 000077
2004517381.tif 000078
2004517381.tif 000079
2004517381.tif 000080
2004517381.tif 000081
2004517381.tif 000082
2004517381.tif 000083
2004517381.tif 000084
2004517381.tif 000085
2004517381.tif 000086
2004517381.tif 000087
2004517381.tif 000088
2004517381.tif 000089
2004517381.tif 000090
2004517381.tif 000091
2004517381.tif 000092
2004517381.tif 000093
2004517381.tif 000094
2004517381.tif 000095
2004517381.tif 000096
2004517381.tif 000097
2004517381.tif 000098
2004517381.tif 000099
2004517381.tif 000100
2004517381.tif 000101
2004517381.tif 000102
2004517381.tif 000103
2004517381.tif 000104
2004517381.tif 000105
2004517381.tif 000106
2004517381.tif 000107
2004517381.tif 000108
2004517381.tif 000109
2004517381.tif 000110
2004517381.tif 000111
2004517381.tif 000112
2004517381.tif 000113
2004517381.tif 000114
2004517381.tif 000115
2004517381.tif 000116
2004517381.tif 000117
2004517381.tif 000118
2004517381.tif 000119
2004517381.tif 000120
【国際調査報告】
2004517381.tif 000121