CN101124766A - 创建电子签名的文档的方法 - Google Patents

Abstract

电子签名在打印或扫描的形式下是有效的。电子签名被嵌入到文档中，从而即使当文档以纸件形式被扫描、打印或存储时，电子签名也是有效的。文档包括被嵌入到文档中的条形码。条形码包括唯一文档ID和唯一签名ID，用于识别文档和文档的签名者。文档还包括用于指示文档的签名者当包含有效电子签名时授权文档的纸件版本被接受的嵌入到文档中的语言。

Description

创建电子签名的文档的方法

相关申请的交叉引用

本申请要求于2003年12月22日申请的题为“Method And Process ForCreating An Electronically Signed Document”的第60/531,861号美国临时申请和2004年12月21日提交的未知申请号的美国实用专利申请的优先权，在此通过参考援引其内容。

技术领域

本发明总的涉及提供法律上承认的签名。更具体地讲，本发明涉及产生用于电子和纸件文档的签名。

背景技术

签名经常是各种事务的形式需要。如果不以指定的方式由适当的人签字，诸如遗嘱、合同和契约的许多法律文件在法律上不可实施。尽管与签名相关的具体法律要求可根据权限有所不同，但是在文档上具有签名的要求才是基本的目的。例如，签名应该代表对具体文档签名的人，并且签名在没有授权的情况下难以复制。签名还应该识别什么被签名了，从而难以改变签名的事物而不被发现。签名还通过识别对文档签名的每个人来用于鉴别文档，并且对文档签名的步骤旨在使签名者注意对文档签名的法律观点。

对纸件文档签名的过程相对易于建立。然而，在数字领域中，尽管可以证明电子签名的特性(诸如真实性和安全性)地优于纸件签名，但是人们还是由于各种原因不愿意对电子文档进行电子签名。例如，与电子签名相比，人们给予纸件签名更多的信任。

当应用电子签名对文档进行签名时，签名者首先正确识别正在对什么签名。由签名者识别的文档或数据被哈希(hash)处理以产生对所述文档实质上唯一的哈希结果。然后，使用签名者的私钥将所述哈希结果转换成电子签名以对哈希结果加密。以此方式，文档和私钥两者与电子签名相关。

涉及数字签名的文档的事务通常需要发送方和接收方具有数字发送和/或接收文档的能力。这种需求可由双方简单地具有与网络(例如无所不在的互联网)相连的计算机***以及适当的软件来满足。

接收签名的文件的一方常常不配备通过数字连接(例如通过互联网)接收电子签名的工具。例如，法律或本地管理的要求可管理用于签名的文件的纸件副本的使用。一种对签名的文档的通常使用是在地方档案局记录转让和契约。在一实例中，地方记录者可能没有配备用以通过数字连接来接收文档的工具。

但是，电子文件产生和执行是成本和时间节省的操作。作为使用电子签名文件的实例，参照题为“PROCESSING ELECTRONIC DOCUMENTS WITHEMBEDDED DIGITAL SIGNATURES”的第6,796,489号美国专利，在此通过参考援引其全部内容。因此，如果电子签名的文件可被实施，从而可利用有效电子文件产生文件的纸件副本，将是很有用的。

发明内容

本发明的一实施例包括一种对文档电子签名的方法。该电子签名使得该文档处于纸件形式时能够保持电子签名的有效性。该方法包括将条形码嵌入到该文档中。该条形码包括识别该文档的唯一文档ID和与该文档的签名者相关的唯一签名ID。该方法还包括将法律语言嵌入到文档中。该法律语言可包括用于指示签名者当文档的纸件版本包含有效电子签名时授权该文档的纸件版本被接受的文本。

另一实施例包括包含电子签名的文档。即使当该文档被打印或图像处理时，该签名也是有效的。该文档包括条形码。该条形码包括识别该文档的唯一文档ID。该条形码还包括与该文档的签名者相关的唯一签名ID。该文档可包括用于指示文档的签名者在文档的纸件版本包含有效电子签名时授权该文档的纸件版本被接受的语言。

另一实施例包括一种验证包括条形码签名的文档的方法。该方法包括读取该条形码的内容以获得文档ID和签名ID。该方法还包括访问文档的电子副本。将该文档的电子副本与该文档进行比较。该方法还包括验证该文档的电子副本与该文档是否匹配。

一些实施例的优点在于：既考虑到电子文档的产生和处理，同时还考虑到文档的打印和扫描的副本以保持具有法律效力的电子签名。这使得电子文档处理的便捷性和高效性能够适用于仅接受纸件文档的用户。

根据以下描述和所附权利要求，本发明的这些和其它优点和特点将变得更加清楚，或可通过以下说明的本发明的实践而被掌握。

附图说明

为了说明获得本发明的上述和其它优点和特点的方式，将通过参照在附图中示出的本发明具体实施例来更具体地说明以上简要说明的本发明。应该理解的是，这些附图仅描述本发明的典型实施例，因此不应认为是对本发明范围的限制，将通过使用附图来更具体详细地描述和解释本发明，在附图中：

图1示出可实践本发明实施例的典型拓扑结构；

图2示出对电子文档进行签名的方法；

图3示出对电子文档进行验证的方法；

图4示出创建文档的认证的副本的方法；

图5示出检索关于文档数据的方法；

图6示出由文档的记录者来背书的方法；

图7示出公证文档的方法；和

图8示出检索背书数据的方法。

具体实施方式

近来，已经颁布多种对电子签名进行了充分地定义的法规和法律。例如，在美国法典(USC)第15编第7001-7006章所规定的全球及国内电子商务电子签名法案将电子定义为：“术语‘电子’表示涉及具有电、数字、磁、无线、光学、电磁或相似能力的技术。”关于电子签名，美国法典第15编第7001章规定：“(1)签名、合同或与这种事务相关的其它记录不可仅因为其以电子形式而否认其法律效力、有效性或可实施性；和(2)与这种事务相关的合同不可仅因为电子签名或电子记录的使用形式而否认其法律效力、有效性或可实施性。”

因此，在一实施例中，通过将条形码用作数字信号或光学信号来实现电子签名。条形码可包括多条编码的信息，所述信息包括文档ID号和签名ID，其中文档ID号用于识别具有电子签名的具体文档，签名ID为与具体签名相关联的唯一ID号。在另一实施例中，条形码还可包括用于文档的加密哈希码，该哈希码通过使用哈希算法以及来自(PKI)加密方案的私钥(或专用密钥)来计算。

通过将条形码用作文档上的签名，即使当文档被扫描、打印或以纸件形式存储时，也满足了用于有效签名的法律要求。这既能够利用电子文档产生的效率，同时也使得没有配备用以接收和/或处理来自数字网络的文档的个人或单位(实体)能够接收以电子方式产生的文档。

参照图1，图1示出其中可实施各实施例的环境的一个实例。如图1所示，文档服务提供商102维护文档服务器104。尽管文档服务器104被显示为单个服务器，在其他实施例中，可使用多个服务器或其它计算机硬件来执行文档服务器104的功能。文档服务器104可通过网络106将文档发送到接收方108。或者，文档服务器104可控制准备文档110的纸件副本，所述文档110的纸件副本可作为实际的邮件112的一部分被发送到接收方108。接收方108在物理邮箱116中接收邮件112。

如图1所示，文档110包括条形码120。可使用接收方108所拥有的条形码扫描器118来扫描条形码120。条形码120可包括唯一文档ID、唯一签名ID、作为标准PKI公钥认证或者涉及或关于该认证的信息的“参照”认证、加密哈希码以及关于文档服务器104上的文档的统一资源定位符(URL)中的任意一个。

文档服务器104具有帮助文档110的接收方确信文档110可信以及对文档110的所有签名可信的功能。其中的一些功能包括：在文档服务器104上存储具有签名的文档的数字副本，以及使用私钥来计算哈希码，其中，哈希码被嵌入到诸如条形码120中的文档中，并且所述哈希码可以与存储在文档服务器104的值进行比较。

通过在文档服务器104存储文档110的数字副本，用户无论通过网络106或者是通过其它手段(如通过邮件112)接收文档110的副本，均可访问文档110的副本并且可将其与文档110进行比较。在一实施例中，条形码120包括嵌入的URL，所述URL具有与文档服务器104上存储文档110的副本的位置有关的地址。通过用条形码扫描器118对条形码120进行扫描，所述URL可被解密，并且可根据所述URL访问文档110的副本。然后，用户可确信他们自己拥有的文档110与作为由服务器提供商102产生的文档110的副本匹配。

当通过网络106接收到文档110时或者当将文档110扫描成数字图像形式时，本发明的一实施例提供覆盖(overlay)功能。在文档服务器102上的文档的一个视图是透明视图(transparency view)。以这种方法，文档的透明视图可被覆盖在扫描的或以电子方式接收到的文档上以通过同时显示两种图像来进行直接物理比较。

文档110还可包含根据PKI加密方案的私钥计算的加密哈希码。该加密哈希码被用作篡改密封(tamper seal)以帮助确信文档110没有被修改或伪造。在一实施例中，根据由文档服务器104或服务提供商102所使用的专用***密钥来计算加密哈希码。在PKI加密方案中，使用私钥和公钥。将私钥保密，而公钥是公共可用的。私钥所有者使用私钥来产生值，即加密哈希码，它是私钥以及文档110中的信息的函数。使用公钥，加密哈希码可通过进一步的计算来验证。

可理解的是，文档常常包含许多签名。因此，在一实施例中，文档服务器104在签名的各阶段中维护文档110的副本。

现在参照图2，图2示出一实施例的使用案例1。图2中示出将包括条形码的签名嵌入到文档中的使用案例。在202，文档处于可签名状态。在可签名状态下的文档可以是例如XML文档、HTML文档、图像或具有附带XML文档的图像。当文档具有它的最终外观时并且当法律语言和输入信息完成时，所述文档处于可签名状态中。可以以多种方式制作文档并将其形成为可签名状态。例如，可向文档输入任意适当数据来对其进行图像处理。或者，由服务提供商102(图1)提供的电子文档工具可被用于将文档处理成可签名状态。

在204，获得电子公布位置信息。在此阶段，向诸如服务提供商102的公布服务来注册文档。位置可关联于其中文档被电子公布的服务器，诸如文档服务器104(图1)。可由服务提供商提供URL。在206，URL可以诸如以XML或者作为可视超链接的一部分被嵌入到文档中。URL允许文档的接收方验证该文档的真实性。通过根据URL所关联的内容，接收方可验证他们的物理拥有的文档与被电子签名的文档是否匹配。将URL嵌入到文档中可服务于提供功能，即：第一，用篡改密封保护URL，因此将法律约束力状态给予电子公布位置。法律绑定效果使得嵌入位置成为协议的一部分。第二，如上所述，接收方可使用篡改密封功能来验证他们所拥有的文档与被签名的文档的一致性。因此，当单位或实体对具有电子公布位置的文档签名时，所述单位所述实质上进行了法律声明，即正在被签名的文档与在该电子公布位置存储的文档匹配。

在208，所需的法律和信息的签名语言被嵌入到文档中。美国法典第15编和其它规定要求关于电子签名的效力的通知和信息声明。例如，美国法典第15编第7001章讨论了需要提供给对文档进行电子签名的个人的各种通知。因此，在208，任一需要的语言可被嵌入到文档中以符合任一法定通知要求。在此实例中，所述信息的签名语言可包括指示签名者当文档的纸件版本包含有效电子签名时授权该文档的纸件版本被接受的语言。所述语言还可指示文档被电子签名，以及指示将条形码嵌入到文档中的目的在于当文档被打印或图像处理时保持电子签名。因此，签名者授权条形码的任一纸件或图像处理的版本被认为是有效签名。

在210，签名者角色信息被嵌入到文档中。签名者角色信息涉及其中签名者对文档签名的能力。例如，如果签名者是公证人，则签名者角色信息可包括公证者签章和承诺信息。对于地方记录者，签名者角色信息可包括记录者背书块。其它签名者角色信息可被嵌入到文档中。可以以多种方式将签名者角色信息嵌入到文档中。例如，如果文档为XML和/或HTML文档，则签名者角色信息可以作为文本被嵌入。当文档为图像和关联的XML时，具有签名者角色信息的图形可被添加。或者，文本可覆盖在图像上。

在212，创建电子签名。在一实施例中，创建电子签名包括以下三个步骤：(1)将签名者的身份与文档绑定，(2)对文档进行篡改密封，和(3)将条形码嵌入到文档中。由于当签名者在执行签名时授权***执行所述步骤，所以这三个步骤中的每个都处于签名者的控制之下。

在214和218中示出用于将签名者的身份与文档绑定的两个选择。在214，示出数字化签名序列。在此实例中，个人的手写签名的图形被嵌入到文档中。例如，该图形可以是真实签名的扫描。该扫描被存储在***中，以当个人对文档进行电子签名时使用。如216所示，数字化的图像被嵌入到文档中。所述数字化的图像可被放置于由签名者指定的位置、缺省位置、或者由商业规则指定的位置中。当使用商业规定来放置签名时，可实现批处理以使得在短时间内对大量文档进行签名。

作为214中的数字化的签名序列的替代，218中的PKI签名序列(包括PKI签名序列签名块)被嵌入到文档中。在本实施例中，签名者具有他们自己的个人私钥。因此，签名者将PKI签名应用到文档，而不是使用图形。作为PKI签名序列的一部分，文档被哈希处理。用签名者的私钥来对该哈希码进行加密。随后，加密的哈希码被嵌入到文档中。

220示出在使用数字化的签名序列的实施例(如214所示)中所使用的对文档进行篡改密封的步骤。在此实施例中，将***产生的PKI篡改密封签名应用到文档。可使用***专用密钥。在216将数字化图像嵌入到文档之后，文档被哈希处理。使用***的专用密钥对处理后的哈希码进行加密，并随后将加密的哈希码嵌入到文档中。在一实施例中，在嵌入条形码之前，在文档上进行篡改密封。这使得可包括加密的哈希码作为条形码的一部分。因此，当文档接收方试图验证文档时，如以下更详细讨论的，条形码应该在对接收的文档进行哈希处理之前被去除以验证文档上任一加密哈希码的签名。

当使用在218的这种PKI签名序列时，不再需要进行诸如220的篡改密封。签名者的PKI签名同时用作签名步骤和应用篡改密封。

在222，创建并嵌入条形码作为签名的部分。在一实施例中，将条形码置于文档中是在电子签名的应用期间发生的非可视过程。将条形码置于文档中是在签名者的控制下进行的。在一实施例中，条形码是二维条形码，从而增加可存储在条形码中的信息量。如先前讨论的，条形码可包括PKI签名或PKI篡改密封的加密哈希码、对应于文档位置的URL、认证ID、唯一文档ID以及任意其它期望的数据。PKI签名或篡改密封可使用64基编码或其它二进制编码类型。使用认证ID来认证用于对文档进行PKI篡改密封的私钥。

条形码可作为在文档的数字版本表面上的图形显示。另外，条形码可被超链接，从而使得条形码用作与存储文档副本的文档服务器上的位置相对应的活动可点击链接。

文档常常需要由多方签名或背书。因此，在224，进行检验以确定是否需要附加签名。如果需要附加签名，如图2所示重复在204开始的步骤，直到已经添加了所有必要的签名。

当已经获得了所有必要的签名时，如在226所示，公布所完成的文档。用最近的文档版本号来更新文档服务器。现在，文档服务器上的文档为公共可用的。文档服务器上的文档包括所有必要信息，从而副本可被显示并且可将该副本与由接收方接收到的文档进行比较。根据文档中的URL链接，是否从文档中的数字链接进行选择、从文档中的文本链接手动键入到终端、或者从条形码进行读取，其结果将导致显示包括条形码的所有签名的文档。文档服务器还可包括为接收方验证加密哈希码的有效性的功能。

在228和230，将文档传递给接收方。这可通过例如提供纸件文档228或者数字传递的文档230来实现。在一实施例中，纸件副本可被打印并邮寄到接收方(即228)。在可通过电子渠道接收文档的实施例中，文档可被电子传递(即230)。在232，图2所示的处理结束。

现在，参照图3，图3示出使用案例2，使用案例2示出从已被打印出的电子签名文档中获取验证和数据。如302所示，可通过如304所示处理纸件文档或者可通过如306所示处理电子文档来处理文档。

在304示出对电子签名文档的打印出的纸件的验证。为了验证文档，接收方可以：(1)手动键入在文档表面显示的URL，(2)用手工条形码读取器扫描条形码，(3)将文档送入扫描器，或(4)绕开对文档服务器上的文档的验证。

接收方可将在文档表面显示的URL手动键入到终端中。可将URL添加到文档以作为图2所示的签名过程的一部分。URL包含链接到文档服务器上存储文档的电子副本的位置的链接。随后，接收方可将文档服务器上的文档与他们手头有的纸件副本进行比较，以保证他们拥有作为被签名的文档的真实而准确的副本。

接收方可以用手工条形码读取器来扫描条形码。条形码读取器可从条形码中解码数据。如上所述的数据可包括对应于文档服务器的URL，从而可检索文档的电子版。

接收方可将接收的文档送入扫描器。使用盘式送纸扫描器(tray-feederscanner)处理文档以验证文档，以上操作可自动进行。使用光字符识别(OCR)和条形码识别，***将具有来自条形码的数据，该条形码包括对应于文档服务器的URL。这将允许***从文档服务器检索文档的电子副本。

接收方不需要验证与文档的电子副本相对应的文档。例如，接收方可相信从其接收纸件副本的源。在这种情况下，接收方可仅简单地接受包括签名和条形码的文档作为有效可信的文档。

在306显示当文档被电子传递时的处理过程。在这种情况下，条形码签名的文档被数字地传递。没有纸件副本被传递。在本实例中，文档携带条形码上的活动超链接到达，所述条形码上对应于文档服务器上的公布位置。或者，文本URL可以是活动超链接或可通过XML提取的。因此，对文档的处理过程可以以多种方式发生，所述多种方式包括：用户在超链接(或者是条形码或者是文本URL)上点击的人工交互；通过从XML读取URL的自动处理过程。

如在308所示，一旦接收的文档已经被处理，不管以电子形式还是纸件形式，都可将接收到的文档与文档服务器上的文档的副本进行比较。将接收到的文档与在文档服务器的文档进行比较的过程包括：验证接收到的文档中的条形码数据与文档服务器的文档副本上的条形码数据是否匹配。接收方应在文档服务器的站点上执行域验证或SSL检验，以保证公布服务的IP地址没有被创建假文档的人所欺骗。可以针对多个项目将接收的文档与文档服务器的文档进行比较。紧接在接收到的文档被签名之前将其与文档的副本进行比较。可以将处于完成签名状态下的接收到的文档与在文档服务器上的副本进行比较。另外，可以针对与文档相关的HTML和XML、哈希码、签名数据、篡改密封数据等将接收到的文档上的与存储在文档服务器上的文档进行比较。可以将接收到的文档上的图像与存储在文档服务器上的文档上的图像进行比较。可以在接收到的文档和存储在文档服务器上的文档之间比较HTML视图或PDF视图。可以在接收到的文档和存储在文档服务器上的文档之间比较诸如PRIA、明尼苏达州记录XML、PRIA索引格式等的XML解释。可以在接收到的文档和存储在文档服务器上的文档之间比较付款信息。

如上讨论，如在310所示，接收人(即自然人)可以对文档的本地纸件版本与存储在文档服务器上的文档的副本进行视觉比较。在此实例中，自然人执行对两种文档的比较，直到他们确信文档相同为止。存储在文档服务器上的文档可以以多种形式向接收方呈现，直到接收方确信他们的本地纸件文本与存储在文档服务器上的文档相同为止。

或者，如在312所示，当文本被电子存储在接收方的计算机***上时，可由人进行视觉比较。接收方比较两种文档，直到接收方确信文档相同为止。文档可以以多种形式向接收方呈现，直到接收方确信接收到的文本与存储在文档服务器上的文档相同为止。当使用接收方的计算机***比较文档时，在一实例中，可以通过将文档与彼此相邻呈现的图像并行比较来比较文档。

在可选实施例中，图像中的一个(例如，存储在文档服务器上的文档的图像)可以被可视化地着色，从而图像中的一个可以被覆盖在另一图像上。因此，当接收到的文档的图像与存储在文档服务器上的文档图像不匹配时，任意差异对于自然人将是非常明显的。例如，在一实施例中，在文档的扫描版被覆盖在来自文档服务器的文档的图像上的情况下，可调用覆盖函数。然后，可使用对比色或其它指示符来强调任意差异。或者，可将文档的扫描版与允许扫描版被拖拽、旋转、伸展等的处理关联，从而允许在存储在图像服务器上的文档的副本上手动覆盖。通过包括这些处理，扫描位置或分辨率的差异可被补偿。还可使用对比色或其它强调方式。

在314显示的另一可选实施例中，可执行对接收到的文档和存储在文档服务器上的文档的自动比较。自动比较可以使用图像比较算法将接收到的(或者扫描的或者电子接收的)文档与存储在文档服务器的文档进行比较，并经统计而产生人们对于两个文档应该是相同文档的信任程度的可信级。

现在，参照316，其显示对文档签名进行验证。验证包括例如检验篡改密封。在一实施例中，篡改密封可以是加密的哈希码。在一实施例中，可以通过比较存储在文档服务器上的文档中的加密哈希码信息来验证签名。文档服务器执行存储在文档服务器的文档验证，并提供加密的哈希码。对加密的哈希码进行解密，之后将其与接收到的文档的哈希码进行比较。

或者，可以基于存储在条形码中的信息，将存储在文档服务器上的文档与接收到的文档进行比较。在本实例中，从接收到的文档的条形码取得加密的哈希码，并且将加密的哈希码随同对应于存储在文档服务器上的文档副本的参照资料(例如URL)一起发送到服务提供商。服务提供商对加密的哈希码进行解密，并且将其与文档服务器上的文档的新的哈希码进行比较。随后，将验证结果从服务提供商返回到接收方。

如上所述，在验证篡改密封之前需要从文档去除条形码。这是因为，篡改密封常常是在没有条形码情况下的文档的函数，因此为了复制作为篡改密封的部分的新哈希码，应去除条形码。

在318，显示在成功验证文档上的签名之后纸件文档或电子文档的处理过程。文档的处理过程可以利用文档是被正确签名且可信的合理信用而进行。可以使用任意现有的文档处理方法来处理文档的纸件副本。还可使用任意现有的电子文档处理方法来处理电子文档，例如在标题为“PROCESSINGELECTRONIC DOCUMENTS WITH EMBEDDED DIGITAL SIGNATURES”的第6,796,489号美国专利中描述的方法，在此通过参考援引其全部内容。

如果在325验证文档的处理的结果是验证文档失败，则在322处理结束，并且接收到的文档不被处理或者认为不可信。同样，当在320签名验证失败时，可给出适当的通知，在322，处理结束，并且文档不被处理。

现在，参照图4，其显示使用案例3，其中创建公证人签名的证明的电子文档副本。此实例示出公证人如何能够使用基于条形码的签名以制作文档图像的电子证明的副本。在此实例中，签名和公证可以以诸如由接收墨水签名和公证的纸件文档的标准方式发生。

在图4所示的使用案例3中，公证人证明文档的图像是纸件文档的真实正确的副本。实现这种证明，从而如果文档的图像被打印出，则该证明即使在打印的副本上也是有效的并可被验证的。

在402，公证人检查待复制并可被证明的文档。文档被完全且适当地执行。文档还可包括例如公证人签章和签名。由公证人来检查此完全执行的文档。文档的检查可包括检查文档的扫描的副本。扫描的副本将是纸件文档的副本。在证明副本时检查扫描的副本。如果先前进行了扫描，则可以从可信源中检索扫描的副本。因此，在一实例中，可能需要文档的基于图像的显示，所述文档没有附带如电子文本中典型附带的HTML或XML。

或者，待复制并可被证明的文档可包括HTML、XML和/或ERML。在本实例中，文档不可以是纸件文档，而是具有电子签名和公证的电子签名的HTML或XML文档。证明副本的公证人为他们自己验证文档是原始的，从而其可被证明。公证人可执行任意PKI签名的PKI签名验证。如果文档的检查失败，则随后在420，使用案例3结束，并且文档的副本不被证明。

在404，向诸如服务提供商的公布服务注册文档。一旦公证人证明文档的电子版是原始的证明的副本，则公证人会将公证类型的条形码签名应用到电子文档以证明其作为副本。对公证类型的条形码的应用进行与上述结合图2所述的使用案例1所述相似的过程。具体地，如图2中210所述，嵌入包括公证人签章和公证人誓言的公证信息。例如，将向服务提供商注册文档以及从服务提供商返回的关联的URL。设置描述文档服务器的文档位置的地址，并将该地址嵌入到文档中。此过程可包括嵌入可视URL。关于此方面的进一步细节参见图2所描述的使用案例1。

当文档是图像时，可将URL嵌入到文档中作为图像的一部分。例如，可使用覆盖将URL嵌入到原始图像上。当文档是XML或HTML文档时，在文档服务器上的文档的地址可同时作为HTML和XML被嵌入，从而使得地址既可视又“数据可检索”。

现在，参照406，将副本证明和其它法律语言的嵌入添加到副本。根据本地要求，将执行公证人证明的副本或者宣誓。权限的适当记号将嵌入作为图像的覆盖或者作为HTML和XML被嵌入。在将嵌入的副本证明添加到文档的实例中，公证人嵌入指定状态的证明的副本文本。在使用宣誓的实例中，包括宣誓声明，包括签名以及包括签名的公证。在一实施例中，任意种类的电子签名可以和宣誓声明一起被签名者包括。签名的公证可以是基于条形码的电子签名。基于条形码的签名还应该是关于作为电子签名的条形码的特点的声明。这种语言先前在图2中的208已经描述。可将这种语言嵌入，或者作为在图像上的覆盖和/或作为与认证的副本特点相关的HTML和XML。

在408，显示公证人签名的嵌入。在这种情况下，将电子签名以与图2中在使用案例1的210和212所述相似的方式置于图像上。还将嵌入如在210所述的适当的公证人信息。这种信息可包括公证人签章、承诺、承诺截止期等。如先前所述，可使用覆盖来嵌入图像。还可对证明的副本使用PKI签名或篡改密封，并且随后所述PKI签名或篡改密封能够获得来自服务提供商的验证。无论证明的副本是图像还是HTML和XML文档，均可使用PKI签名或篡改密封。

在410，显示条形码图形的嵌入。将使用与图2所示相似的技术将条形码嵌入到图像中。条形码可包括或者针对HTML和XML创建或者针对文档图像创建的加密哈希码。根据是否使用签名或篡改密封，或者使用用户的私钥或者根据***的专用密钥来创建加密的哈希码。如图3所述的使用案例1所述，这种加密的哈希码随后能够验证。可包括条形码作为公证人签名和副本证明的一部分。或者，单独页可被添加到包含证明文本和签名的文档。当被证明的文档副本是图像时，条形码图形可被覆盖在该图像上。当被证明的文档副本是XML和HTML文档时，图形可被嵌入，并且链接到文档服务器的地址的超链接也可被包括。

在412，公布完成的文档。用最近的文档版本来更新文档服务器，从而使得能够公布文档的电子副本，以便基于纸件的验证。

在414和416，文档被传递。在一实施例中，如在414所示，文档被打印并且被邮寄到使用纸件副本的目的地。或者，如在416所示，在将文档电子传递到用于电子处理的目的地的情况下，可使用电子传递。在418，使用案例3结束。

现在，参照图5，使用案例4示出与服务提供商交换包括记录数据的数据。本使用案例论证如何为使用包含条形码的文档的纸件版本，电子签名可被用于与服务提供商交换关于那些文档的数据。例如，在一实施例中，接收方可向服务提供商提供这样的信息，即服务提供商不具有诸如背书或其它对文档的添加之类的信息。服务提供商可向纸件文档的接收方或拥有者提供关于文档的XML数据。

在502，显示用户交互数据交换的实例。这种类型的数据交换允许用户(人)与服务提供商交互。在504，用户例如通过登陆到文档服务器而登陆到服务提供商。随后，如在506所示，用户使用在条形码中编码的唯一ID来识别他们拥有的纸件文档。此过程或者可通过用条形码读取器扫描纸件文档来进行，或者通过手工键入唯一文档ID来进行。在508，用户键入文档服务器可能不具有而他们可能具有的关于文档的信息。例如，如果记录者已经记录并背书文档，则用户可提供编目、书页数据、日期等。在510，服务提供商可将关于此文档的数据发送到用户。例如，如果文档是记录文档，则索引信息、授权者、被授权者等等可立即从基于web的接口被提取并传递给地方记录者。或者，信息可被排队等候以随后作为批处理传递到地方记录者或用户。在512示出批处理传递。可在指定的时间传递批处理信息，从而将用于所有正确请求的文档的数据发送到用户的位置。

在516，使用案例4还示出非交互批处理数据交换。在518，创建用户数据文件。在此阶段，用户运行批处理以创建包含将被传递到服务提供商的数据的数据文件。将被传递的数据可包括用于一个或多个已签名的纸件文档的数据。例如，在批处理中可包括来自已经被记录的一批文档的背书数据。如在520所示的被发送到服务提供商的文件包括可作为条形码的一部分的唯一文档ID。该文件还可包括诸如记录者背书信息的任意期望的信息。XML模式可用来指导用户怎样创建对于将此信息提交给服务提供商的XML文件的批处理。在522，来自用户的数据文件被传送到服务提供商的指定位置。在524，准备批处理的文档数据。例如，诸如索引信息、授权者、被授权者等的文档相关的数据被从服务提供商提取，并且被排队等候以在适当时间作为批处理传递给用户。或者，在数据被排列等候以传递给用户之后，所述数据可被立即传递给用户。如上所述，在512，数据被传递给用户。在514，使用案例4结束。

现在，参照图6，使用案例5示出记录者用条形码对打印的电子文档背书的情况。在602，检查将被背书的文档。可通过诸如题为“PROCESSINGELECTRONIC DOCUMENTS WITH EMBEDDED DIGITAL SIGNATURES”的第6,796,489号美国专利所述的典型的电子记录过程来处理文档，或者通过任意适当的记录过程来处理，直到文档准备好被背书为止。典型的记录过程可包括公证和签名的验证，即这些公证和签名是否为基于条形码的、具有篡改密封的电子签名、具有篡改密封的图像和数据对、PKI签名，或者其它签名。对文档图像和/或XML和HTML进行处理，直到背书步骤。如果在604，处理失败，则文档的处理结束。

否则，在606，向可包括文档服务器的公布服务注册文档。作为注册的结果，URL和/或涉及指示文档服务器位置的其它地址信息被返回，并且被添加到文档。可通过基于图像的处理以将文本覆盖在文档上和/或通过将文本作为可包括超链接的XML和HTML嵌入到文档来添加文本。

随后，如608所示，文档可被处理以将适当的文本添加到与背书关联的文档。背书信息可包括编目流水号、记录簿(book)、页、记录日期、时间、付款的费用、记录者姓名、权限、文件类型等。可通过基于图像的处理以将文本覆盖在文档上和/或通过将文本作为可包括超链接的XML和HTML嵌入到文档来添加文本。

如在610所示，将记录者的签名或背书嵌入到文档中。在一实施例中，图形用户界面向背书者呈现声明，该声明指示背书者同意文档将被电子背书，以及条形码将作为他们签名的一部分被嵌入。该声明还可指示当文档被打印或图像处理时，条形码将被用于保持电子记录和/或电子背书。此操作以与图2所述的208所描述的操作相似的方式进行。将签名以与图2所述的在212所描述的操作相似的方式嵌入到文档中。

现在，如在612所示，条形码可被嵌入到文档中。将条形码嵌入到文档中以图2中在222相似的方式操作。然而，在此实例中，条形码还可包含背书数据，例如先前所述的背书数据。条形码可包含与关于文档的记录者专有数据相对应的URL链接，该记录者专有数据包含先前所述的背书数据。

在614，文档服务器上的文档被公布，在616和618，文档被传递。与前述实例相同，在616，文档可被打印和邮寄，在618，文档可被电子传递。在620，使用案例5结束。

现在，参照图7，显示使用案例6，其中使用条形码来公证文档。在702，由签名者使用公证人能够证明的可接受的电子签名方法来对电子文档签名。在704，进行认可和公证人证明。公证人验证签名者的签名是否为PKI签名，并且公证人从签名者接收关于他们的签名的真实性的认可声明。可由公证人进行其它步骤以保证公证是合法和具有约束力的。

在706，公布和地址信息被获得，并且被嵌入到文档中。这包括例如获得与将存储文档副本的文档服务器位置相对应的URL地址。如图1中在204和206所述，可将URL地址嵌入到文档中，包括作为图像、作为XML和/或作为HTML以及以根据文档的类型而定的适当方式嵌入。

在708，法律和信息的语言可被添加到文档。例如，所述法律和信息的语言可包括用于识别文档的唯一文档ID、指示文档被电子公证以及指示条形码的用途在于当文档被打印或图像处理时保持电子公证的声明等。如上所述，信息可作为XML、HTML和/或图像覆盖中的一个或多个被嵌入。

在710，示出公证。在签名时向公证人呈现的图形用户界面包括指示他们同意文档将被电子公证、以及指示其用途在于当文档被打印或图像处理时保持电子公证的条形码将被嵌入作为他们签名的一部分的声明。例如，可使用图2中在221所述的方法嵌入签名。

在712，条形码被嵌入作为***理的一部分。嵌入条形码可以以与图2中在222所述相似的方式进行。另外，公证承诺信息和/或公证人签章可被嵌入到可被用于验证公证的条形码中。

在714，在文档服务器的文档被公布。在716和718，文档被传递。文档的传递可包括如在716所示的打印和邮寄文档，或者如在718所示的文档的传递可包括对文档进行电子传递。在720，使用案例6结束。

现在，参照图8，示出使用案例7，显示对背书和/或索引数据的查询和付款的情况。在802，显示批处理的数据交换。典型地，批处理的数据交换不是用户交互，而是在两个或多个计算机***之间执行的自动处理。

在804，创建请求者数据文件。请求者运行批处理以创建批处理数据文件，该批处理数据文件包含与受处理的电子文档(期望获取该电子文档的信息)相关的参照资料。在一实施例中，纸件文档的条形码可被扫描以帮助创建批处理数据文件。在806，提出付款承诺(payment commitment)。每一文档包括具体承诺、付款额、付款记录ID和/或“决定付款”文档。或者，整个批处理可包括具体承诺、付款记录ID和/或“决定付款”文档。在808，请求者传送数据。此时，批处理数据文件被传送到在文档服务器上的指定的公布位置。

在810，准备批处理的文档数据。从服务提供商的文档(诸如文档服务器上的文档)提取关于电子文档的数据，例如记录信息、背书信息、索引信息、授权者和被授权者等。随后，信息被排队准备作为批处理传递给请求者。信息可在预先指定的时间内或者紧接在批处理被准备好时被作为批处理传递给请求者。

在812，传递批处理的数据。对于所有正确请求的文档的批处理数据在预先指定的时间内被传送到请求者侧的位置。ACH付款被启动以收集对提供的文档服务的付款。在814，使用案例7结束。

在本发明范围内的实施例还包括用于携带或具有计算机可执行指令或在其上存储的数据结构的计算机可读介质。这种计算机可读介质可以是可被通用或专用计算机访问的任意可用介质。作为实例，而非限制性，这种计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储器、磁盘存储器或其它磁存储装置、或者可被用于以计算机可执行指令或数据结构以及可由通用计算机或专用计算机处理的形式携带或存储期望的程序代码方法的任意其它介质。当信息被传递或通过网络或其它通信连接(或者硬连线、无线、或者硬连线或无线的组合)被提供给计算机时，计算机适当地将连接看作计算机可读介质。因此，任意这种连接被适当地称为计算机可读介质。以上的组合也可被包括在计算机可读介质的范围中。例如，计算机可执行指令包括使得通用计算机、专用计算机或专用处理装置执行某功能或功能组的指令和数据。

在不脱离本发明的精神或实质特点的情况下，本发明可以以其它具体形式来实施。描述的实施例在所有方面仅被考虑作为示例性的而不是限制。因此，本发明的范围由所附权利要求而不是前述说明所指示。落入权利要求的等同方案的含义和范围内的所有变化均应包括在本发明的范围内。

Claims (37)

1.一种用电子签名对文档进行电子签名的方法，该方法使得在文档以纸件形式打印时能够保持电子签名的有效性，该方法包括以下步骤：

将法律签名嵌入到该文档中，其中，该签名包括：

条形码，该条形码包括：

唯一文档ID，用于识别该文档；和

唯一签名ID，与该文档的签名者相关。

2.如权利要求1所述的方法，还包括将用于指示签名者在该文档的纸件版本包含有效电子签名时授权该文档的纸件版本被接受的语言嵌入到该文档中。

3.如权利要求1所述的方法，其中，该条形码是二维条形码。

4.如权利要求1所述的方法，其中，该条形码包括参照认证。

5.如权利要求1所述的方法，其中，该条形码包括存储文档的电子副本的位置地址。

6.如权利要求1所述的方法，其中，该条形码包括篡改密封。

7.如权利要求1所述的方法，还包括将该文档发送到接收方。

8.如权利要求7所述的方法，其中，将该文档发送到接收方的步骤包括打印该文档。

9.如权利要求7所述的方法，其中，将该文档发送到接收方的步骤包括以电子形式发送该文档。

10.如权利要求1所述的方法，还包括将该文档的电子副本存储在文档服务器上。

11.如权利要求1所述的方法，还包括将签名者角色信息嵌入到该文档中。

12.如权利要求1所述的方法，还包括将手写的签名的图形嵌入到该文档中。

13.一种具有用于执行如权利要求1所述的步骤的计算机可执行指令的计算机程序产品。

14.一种包含电子签名的文档，该电子签名在打印或图像处理文档时有效，该文档包括：

具有法律效力的签名，该签名包括条形码，其中，该条形码包括：

唯一文档ID，用于识别该文档；和

唯一签名ID，与该文档的签名者相关。

15.如权利要求14所述的文档，还包括用于指示签名者在该文档的纸件版本包含有效电子签名时利用该条形码授权该文档的纸件版本被接受的语言。

16.如权利要求14所述的文档，其中，该条形码是二维条形码。

17.如权利要求14所述的文档，其中，该条形码包括参照认证。

18.如权利要求14所述的文档，其中，该条形码包括存储文档的电子副本的位置地址。

19.如权利要求14所述的文档，其中，该条形码包括篡改密封。

20.如权利要求19所述的文档，其中，该篡改密封包括在将条形码添加到该文档之前的文档的加密哈希码。

21.如权利要求20所述的文档，其中，使用PKI加密方案中的***专用密钥来计算该加密哈希码。

22.如权利要求20所述的文档，其中，使用PKI加密方案中的专用签名者密钥来计算该加密哈希码。

23.如权利要求14所述的文档，还包括XML和HTML代码，其中，所述XML和HTML代码包括篡改密封。

24.如权利要求14所述的文档，还包括XML和HTML代码，其中，所述XML和HTML代码包括存储文档的电子副本的位置地址。

25.一种验证文档的方法，其中，所述文档包括包含条形码的签名，该方法包括以下步骤：

读取该条形码的内容以获得文档ID和签名ID；

访问该文档的电子副本；

将该文档的电子副本与该文档进行比较；和

验证该文档的电子副本与该文档是否匹配。

26.如权利要求25所述的方法，还包括以下步骤：

从该文档去除该条形码；

使用公钥取回哈希码；和

将所述取回的哈希码与存储在该条形码中的哈希码值进行比较。

27.如权利要求25所述的方法，其中，访问该文档的电子副本的步骤包括手动键入在该文档的表面显示的URL以链接到该文档的电子副本。

28.如权利要求25所述的方法，其中，访问该文档的电子副本的步骤包括用条形码读取器扫描该条形码，以访问嵌入到该条形码中的与该文档的副本相对应的URL。

29.如权利要求25所述的方法，其中，访问该文档的电子副本的步骤包括扫描该文档和使用条形码识别方式和/或光字符识别方式，以获得与该文档的副本相对应的URL。

30.如权利要求25所述的方法，其中，将该文档的电子副本与该文档进行比较的步骤包括将该文档的扫描的电子版本与远程文档的副本进行并列比较。

31.如权利要求25所述的方法，其中，将该文档的电子副本与该文档进行比较的步骤包括将该文档的扫描的电子版本与该文档的副本进行比较，其中，该扫描的电子版本和该文档的副本中的任一个可被覆盖。

32.如权利要求25所述的方法，其中，将该文档的电子副本与该文档进行比较的步骤包括将该文档的哈希码与存储的哈希码进行比较。

33.如权利要求25所述的方法，其中，将该文档的电子副本与该文档进行比较的步骤包括自动进行比较并产生该电子副本和扫描的文档是相同文档的可信级。

34.如权利要求25所述的方法，还包括对该文档上的签名进行验证。

35.如权利要求34所述的方法，其中，验证签名的步骤包括验证篡改密封。

36.如权利要求34所述的方法，其中，验证签名的步骤包括验证在该条形码中的篡改密封。

37.一种具有用于执行如权利要求25所述步骤的计算机可执行指令的计算机程序产品。

Images