US9614681B2 - Private electronic signature service for electronic documents - Google Patents

Abstract

Techniques are disclosed for providing an electronic signature service where the content of an electronic document to be signed remains unknown to the service. A sender of the electronic document negotiates a specification for encoding the electronic document. In particular, the specification does not include any content of the electronic document. In this manner, the content of the electronic document can be encrypted and securely transmitted between the sender and the signer via the electronic signature service using one or more data packets conforming to the specification without permitting the electronic signature service to read or otherwise decipher the content. The specification enables the electronic signature service to certify that the signer has received the electronic document and assented to its terms. Further, the specification enables the electronic signature service to perform authentication and transaction logging operations associated with obtaining an electronically signed version of the electronic document.

Description

FIELD OF THE DISCLOSURE

This disclosure relates to the field of data processing, and more particularly, to techniques for providing a private electronic signature service for electronic documents.

BACKGROUND

Electronic documents are an alternative to paper documents. An electronic signature functions as an indication that a person adopts the content of the electronic document. Electronic documents are often exchanged between a sender and a signer using different computers that are connected via the Internet or another communication network. Since there is no physical copy of the document, certain measures must be undertaken to ensure that the integrity and confidentiality of each document is maintained when the document is transmitted from one party to another. An intermediate, third party service may be used to obtain electronic signatures. For example, a sender provides an unsigned copy of a document to the third party service, which in turn provides the document to the signer. The signer then applies an electronic signature to the document. The signed document is then returned to the sender via the third party service. With some existing techniques, the third party service reads the document as it is transmitted between the parties, which can potentially compromise the security of sensitive information that is intended to remain confidential. Thus, there is a need for improved techniques for providing an electronic signature service where the content of an electronic document to be signed remains unknown to the electronic signature service.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral.

FIG. 1 shows an example system for providing an electronic signature service, in accordance with an embodiment of the present invention.

FIG. 2 shows an example data flow diagram for providing an electronic signature service, in accordance with an embodiment of the present invention.

FIGS. 3A, 3B and 3C show a flow diagram of several example methodologies for providing an electronic signature service, in accordance with several embodiments of the present invention.

FIG. 4 shows a screenshot of an example electronic document and graphical user interface, in accordance with an embodiment of the present invention.

FIG. 5 is a block diagram representing an example computing device that may be used in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

With some existing techniques, individuals or entities wishing to make use of an electronic signature service must reveal the content of the electronic document to the service. For instance, some existing electronic signature services use the content of the document for authentication and validation purposes, or for identifying a location within the document where the signature is to be applied. However, sometimes the document contains confidential information that the user does not wish to reveal to the electronic signature service under any circumstances.

To this end, and in accordance with an embodiment of the present invention, a technique is disclosed for providing a private electronic signature service where the content of an electronic document to be signed remains unknown to the service. A sender of the electronic document and the private electronic signature service negotiate a data encoding specification for encoding the electronic document. The specification defines a data structure and a file format of the electronic document, including, for example, the number of pages in the document, the size (e.g., in pixels) of images corresponding to pages of the document, a data structure describing any input fields to be filled out by the signer (e.g., field data types, field positions relative to page, or field names), or any other information used by the signer to enter information onto the document (e.g., signature, date, name, title, employer, and so forth). The specification is agreed upon by the sender and the electronic signature service before the document is sent to the signer for signature. As will be described in further detail below with respect toFIG. 2, the data structure defined by the specification includes a data block and byte positions within the data block that correspond to bytes for a given page and bytes corresponding to a representation of the entire document (e.g., where the document is represented in a Portable Document Format, or PDF, format). In some embodiments, the specification defines a format that the fillable fields of the document can be rendered into. In particular, the specification does not include any content of the electronic document. In this manner, using one or more data packets conforming to the specification, the content of the electronic document can be encrypted and privately transmitted between the sender and the signer via the electronic signature service without permitting the electronic signature service to read or otherwise decipher the content. By using data packets conforming to the specification, the electronic signature service can certify that the signer has received the electronic document, or a particular version of the document, and assented to that document by providing an electronic signature. Further, the electronic signature service can perform authentication and transaction logging operations associated with process of obtaining an electronically signed version of the electronic document. Numerous configurations and variations will be apparent in light of this disclosure.

As used in this disclosure, the term “sender” refers to a computing device or computing system that is configured to send an unsigned version of an electronic document, which is encoded as a series of data packets, to one or more other computing devices or computing systems, generally via a data communication network such as the Internet or an intranet. The signer is further configured to receive a signed version of the electronic document, which is also encoded as a series of data packets, from the other computing devices or systems.

As user in this disclosure, the term “signer” refers to a computing device or computing system that is configured to receive, either directly or indirectly, an electronic document from a sender. The signer is also configured to enable one or more people to electronically input their signatures, and to apply those signatures to the electronic document.

As used in this disclosure, the term “electronic signature service” refers to a computing device or computing system that is configured to manage the exchange of an electronic document between a sender and one or more signers. For instance, the electronic signature service may receive an unsigned version of the electronic document from a sender and further provide the unsigned document to a signer for execution of a signature. The electronic signature server may additionally or alternatively return a signed version of the electronic document to the sender, as well as perform other document authentication and management functions. Other examples will be apparent in view of the present disclosure.

As used in this disclosure, the term “electronic signature” refers an indication associated with an electronic document establishing that a person signing the document endorses the contents of the document with the intent to affix his or her signature to the document. An electronic signature may include, for example, an electronically generated symbol or sequence of characters attached to or logically associated with a document and executed or adopted by a person. The electronic signature can be used to assure that the integrity and authenticity of the document, as well as the non-repudiation of the signer, is maintained throughout signing processes, including during electronic transmission of the document between different computing devices. The recipient of an electronically signed document can verify that the signature originated with the signer, that the document has not been altered since the electronic signature was applied, and that the signer has not repudiated or withdrawn his or her signature from the document.

As used in this disclosure, the term “negotiate” refers to a process in which two or more entities (e.g., computers, servers, or other data processing services) agree upon a data encoding specification to be utilized by at least one of the entities, such as described with respect toFIG. 2. For example, a first entity may send a proposed data encoding specification to a second entity. The second entity may, in response, reply to the first entity with a message agreeing to the proposed data encoding specification, thereby completing the negotiation.

Example System

FIG. 1 shows anexample system100 for providing an electronic signature service where the content of an electronic document to be signed remains unknown to the service, in accordance with an embodiment. Thesystem100 includes auser computing system102 for a sender of anelectronic document101, one or moreuser computing systems104 for signers of theelectronic document101, and aserver106 for providing an electronic signature service. The system further includes asender processing module110, one ormore browsers112, asignature processing module114, and anaudit database116. Thesender processing module110, the browser(s)112, thesignature processing module114, and theaudit database116 can each be executed and accessed by thesender102, the signer(s)104, theelectronic signature service106, or any combination of these. In cases where thesystem100 includes more than oneuser computing system102,104, orserver106, such user computing systems and servers can be interconnected to a wired or wireless data communications network108 (e.g., the Internet or an intranet). Thesender processing module102 is configured to generate and provide theelectronic document101 and any related data (e.g., a cryptographic or encryption key118) to the signer(s)104 either directly or via theelectronic signature service106 in one or more data packets that conform to adata encoding specification120, such as described with respect toFIG. 2. An example of a data flow between components of thesystem100 is described in further detail with respect toFIG. 2. In some cases, theelectronic document101, thesender processing module110, thebrowser112, thesignature processing module114, theaudit database116, or any combination of these can reside on a cloud-based computing system. Thebrowser112 may include, for example, a web browser (e.g., Firefox, Internet Explorer, Chrome, Opera, and Safari), which can be used to create, modify, view and retrieve theelectronic document101, such as a contract or other document requiring a signature to indicate assent to or acceptance of the terms set forth in thedocument101.

FIG. 2 shows an example data flow diagram200 for providing an electronic signature service where the content of an electronic document to be signed remains unknown to the service, in accordance with an embodiment. The data flow depicted inFIG. 2 may, for example, be implemented by all or portions of thesystem100 ofFIG. 1. In this example, data flows between thesender102, one ormore signers104, and theelectronic signature service106, are described with respect to thesystem100 ofFIG. 1. A portion of the data flow occurring during a process of obtaining an electronic signature for one signer104 (e.g., Signer1) is generally indicated inFIG. 2 at230. Initially, thesender102 and theelectronic signature service106 negotiate adata encoding specification202 for encoding data associated with theelectronic document101, including any electronic signatures applied to the document. The specification can include a file format for encoding the contents of theelectronic document101, the number of pages in the document, the size (e.g., in pixels) of images corresponding to pages of the document, a data structure describing any input fields to be filled out by the signer (e.g., field data types, field positions relative to page, field names), or any other information used by the signer to enter information onto the document (e.g., signature, date, name, title, employer, and so forth). The specification may be maintained and published a priori by theelectronic signature service106, or may be agreed to by thesender102 on a sender-by-sender basis.

In some embodiments, the agreed upon data structure and file format has sections for field descriptions, and information for the signer to sign. These fields are rendered on something presented to the user, such as an image. Accordingly, the data structure includes sections that refer to binary chunks representing individual pages (e.g., rasterized images such as JPEG or PNG). The data structure also contains a pointer to a binary chunk that corresponds to some total representation of the document (e.g., PDF). Various structures can be used when theelectronic signature service106 andsender102 agree on such structures. In one example, the entire contents of theelectronic document101 may be included in a base64 encoded XML document. In another example, a compact compressed representation of theelectronic document101, or a raw binary stream of theelectronic document101 with specific byte positions known, may be used. It will be understood that other ways of encoding the information in theelectronic document101 can be used in conjunction with various embodiments, as long as the data packet from thesender102 conforms to a specification agreed upon by both thesender102 and theservice106, and that the encoded information includes every field in the specification. For example, in some cases a complete representation of the information may not be required (but instead may be optional) if both thesender102 and theservice106 agree that some information may be omitted.

Prior to sending the electronic document to theelectronic signature service106 for signature by the first or sole signer, thesender102 generates anunsigned data packet206 conforming to the agreed to specification. As used in this disclosure, the term “unsigned data packet” refers to data associated with theelectronic document101 before the document is signed by a given signer (e.g.,Signer1,Signer2, . . . Signer n). Thesender102 encrypts theunsigned data packet206 with anencryption key204 known only to thesender102 and thesigner104 or signers of theelectronic document101. Thesender102 sends theencryption key204 directly to thesigner104 or signers. Theelectronic signature service106 does not have access to theencryption key204. Thesender102 further sends theencrypted data packet206, along with a description of the encryption algorithm (e.g., AES), and a list ofsigners207 to theelectronic signature service106. The list ofsigners207 includes data representing an identity of each individual that will sign theelectronic document101, as designated by the sender102 (e.g., a name, a user identifier, an electronic mail address, an Internet Protocol (IP) address, or another suitable form of identification).

In an embodiment, thedata packet206 can be encrypted using various encryption schemes, such as those conforming to the Advanced Encryption Standard (AES) and the ElGamal encryption system. Two mathematically paired keys, a private key and a public key, may be used in conjunction with a public-key algorithm to encrypt and decrypt thedata packet206. As non-limiting examples, asymmetric-key algorithms may include RSA (Rivest, Shamir, and Adelman's algorithm), DSA (Digital Signature Algorithm), ECDSA (Elliptic Curve Digital Signature Algorithm), as well as other asymmetric-key algorithms. The public-key infrastructure allows the sender of, or a distributor of, theelectronic document101 to ensure that no one other than the signer of the document can read the contents of the document. Likewise, using a private key to encrypt theelectronic document101, thesigner104 can assure both the authenticity and the integrity of signedelectronic document101 while preventing entities other than the sender from reading the contents of the document.

When theelectronic signature service106 receives the encryptedunsigned data packet206, the service generates achecksum208 for thedata packet206. Examples of algorithms that can be used to generate thechecksum208 include SHA-2 (Secure Hash Algorithm Series 2), SHA-3, or any other cryptographic has function that is cryptographically strong at the time theelectronic document101 is sent. Thechecksum208 is sent back to thesender102 for verification. Thesender102 independently generates a checksum for the sameunsigned data packet206 and compares this checksum with thechecksum208 generated by theelectronic signature service106. If the checksums match, thesender102 sends achecksum verification210 to theelectronic signature service106. Once theelectronic signature service106 receives thechecksum verification210, the service records audit information in theaudit database116. The audit information may include, for example, theunsigned data packet206, thechecksum208 and the checksum verification. Other audit information may be recorded, such as the current time and date, or other data that represents the transaction between the sender and the electronic signature service.

Theelectronic signature service106 sends a web page link212 (e.g., an HTTP hyperlink, or a link to a Flash-based or other general purpose document viewing application) or other electronic notification uniquely associated with theelectronic document101 to the first orsole signer104 of thedocument101. For example, if there are n signers in the signer list, theelectronic signature service106 may send the link to signer m, where m is less than or equal to n. Theweb page link212 or notification may, for example, be sent in the form of an e-mail or electronic message (e.g., Simple Messaging Service or SMS message).

When the signer104 (e.g., Signer m) receives theweb page link212, the signer can select the link within thebrowser112 to send a web page request214 (e.g., an HTTP request) to theelectronic signature service106. In response to receiving theweb page request214, theelectronic signature service106 presents a web page to thesigner104, which includes theunsigned data packet206 and associated client-side executable code216 (e.g., Javascript code). The provisioning of the client-sideexecutable code216 by theelectronic signature service106 relaxes constraints on the type of device being used by signer of the electronic document. For example, in some cases thesigner104 can securely read and electronically sign theelectronic document101 using an existing web browser, such as Firefox, Internet Explorer, Chrome, Opera, or Safari, that is configured to execute Javascript code provided by theelectronic signature service106. Furthermore, using the client-sideexecutable code216, thesigner104 can decrypt theelectronic document101 using theencryption key204 that is received directly from thesender102. This is in contrast to some existing electronic signature techniques where the electronic signature service acts as a certificate issuing authority, which manages the trust relationships between the sender and the signer. In such existing cases, the electronic signature service requires the signer's device to register with, and obtain a secure certificate from, the electronic signature service prior to receiving the unsigned electronic document.

The web page, in conjunction with the client-side code, causes thebrowser112 to perform a sequence of operations. First, thebrowser112 receives the data packet206 (as provided by the sender102) from theelectronic signature service106 and thesender verification information210. The client-side code216, when executed by thesigner104, confirms theunsigned data packet206 conforms to theverification information210. Theverification information210 presented to the signer may include, for example, a replay of the verification confirmation message theservice106 received from thesender102 when thesender102 originally sent the message to theservice106. In another example, theverification information210 may represent any form of private information not known to the service106 (i.e., information known only to thesender102 or signer104). This may be in the form of an encrypted digital signature or a piece of private information encrypted with theencryption key204 associated with theelectronic document101. In any case, the verification of these messages must be able to be performed by thesender102 and thesigner104. If, for example, PKI is used, the messages may also be verified by theservice106, and allow theservice106 to reject verification messages not generated by thesender102 or thesigner104. Theverification information210 may be used, for example, to detect if and when theservice106 impermissibly introduces new data into theelectronic document101 or undetectably corrupts the transmitted contents of theelectronic document101. Additionally or alternatively, theverification information210 may be used, for example, to prevent thesender102 or thesigner104 from repudiating the contents of the electronic document101 (e.g., a legal contract), and theservice106 can further prove it acted faithfully during the course of the transaction.

Thesigner104 then prompts the user for the encryption/decryption key204, which is received directly from thesender102. Thesigner104 then decrypts theunsigned data packet206 using the key204. Thesigner104 renders a user interface (e.g., within thebrowser112 or in a separate window) that is configured to receive an input from the user to electronically sign thedocument101 at the location(s) designated by thesender102. Such an input may include keyboard or mouse inputs, for example, where the user types his or her name into an input field rendered in thebrowser112. Thesigner104 converts the signature input into the format specified in theunsigned data packet206. The signature input and any other information associated with the transaction is then encrypted into a new, signeddata packet218 using the encryption/decryption key204. As used in this disclosure, the term “signed data packet” refers to data associated with theelectronic document101 after it is signed by a given signer. The encrypted, signeddata packet218 is then sent to theelectronic signature service106.

When theelectronic signature service106 receives the encrypted, signeddata packet218, the service the service generates achecksum220 for the signeddata packet218. Thechecksum220 is sent back to thesigner104 for verification. Thesigner104 independently generates a checksum for the same signeddata packet218 and compares this checksum with thechecksum220 generated by theelectronic signature service106. If the checksums match, thesigner104 sends achecksum verification222 to theelectronic signature service106. Once theelectronic signature service106 receives thechecksum verification222, the service records audit information in theaudit database116. The audit information may include, for example, the signeddata packet218, thechecksum220 and thechecksum verification222. Other audit information may be recorded, such as the current time and date, or other data that represents the transaction between thesigner104 and theelectronic signature service106.

Theelectronic signature service106 sends the encrypted, signeddata packet218 to thesender102. Thesender102 then decrypts the signeddata packet218, performs any transformations (e.g., impressment of the signature input into the images of PDF representation of the electronic document), and alters any fields for thenext signer104, if there are any other signers in thesigner list207 that have not yet signed theelectronic document101. Thesender102 then repeats the process for thenext signer104, if any, until all signers on thesigner list207 have signed theelectronic document101, such as generally indicated at232. For example, the process generally indicated at230 is repeated for eachsigner104; that is,Signer1 through Signer n.

It will be understood that, according to various embodiments described in this disclosure, any or all of the employed checksum and encryption/decryption algorithms may be specified in the agreed uponspecification202. For example, thespecification202 may specify that the checksums comply with SHA-2 and that the data packets comply with RSA.

Example Methodology

FIGS. 3A, 3B and 3C show a flow diagram ofseveral example methodologies300,310,320 for providing an electronic signature service where the content of an electronic document to be signed remains unknown to the service, in accordance with an embodiment. Themethod300 may be performed, for example, in whole or in part by thesender processing module110 ofFIG. 1. Themethod310 may be performed, for example, in whole or in part by thesignature processing module114 ofFIG. 1. Themethod320 may be performed, for example, in whole or in part by thebrowser112 ofFIG. 1. Theexample methods300,310 and320 are described in relation to each other and referred to generally assender method300,service method310 andsigner method320. It will be understood, however, that all or any portions of themethods300,310 and320 can be performed by any portion of thesystem100 ofFIG. 1, and that the scope of eachexample method300,310 and320 is described in the following manner only for clarity.

Referring first toFIG. 3A,sender method300 begins by generating and encrypting3002 an unsigned data packet m including the electronic document based on a data encoding specification, such as described above with respect toFIG. 2.Sender method300 continues by calculating3004 a checksum for the data packet.Service method310 begins by receiving the encrypted, unsigned data packet m and calculating3102 a checksum for the data packet.Sender method300 continues by receiving and verifying3006 that the checksum calculated by theservice method310 atstep3102 matches the checksum calculated by thesender method300 atstep3004. Upon such verification, theservice method310 continues by recording3104 audit information, such as described above with respect toFIG. 2.Service method310 continues by sending3106 a notification to signer m that the electronic document is ready to be signed. The notification may include, for example, a web page link, such as described with respect toFIG. 2.

Referring next toFIG. 3B,signer method320 begins by receiving the notification sent by the service method atstep3106 and, in response, generating3202 an HTTP request or other suitable instruction to retrieve the web page linked in the notification. The web page may, for example, be hosted by theelectronic signature service106 or another web server.Service method310 continues by receiving the HTTP request and, in response, presenting3108 the unsigned data packet m and associated client-side code to thesigner104, such as described with respect toFIG. 2. For example, the client-side code may include Javascript that, when executed by thebrowser112, causes thebrowser112 to perform one or more of the followingsteps3202 through3212.

In an embodiment,signer method320 continues by decrypting3204 the unsigned data packet m using a decryption key provided by thesender102.Signer method320 continues by rendering a signature user interface (e.g., a text input box for inputting an electronic signature within the browser). An example of such a signature user interface is shown inFIG. 4. The electronic signature is an indication (e.g., symbols or characters) that a person signing the electronic document endorses the contents of the document with an intent to affix his or her signature to the document. Once the signature input is received by thesigner104, thesigner method320 continues by encrypting3208 the signature input into a signed data packet m and calculating3210 a checksum for the signed data packet m. In some embodiments, the signature input in the signed data packet m conforms to the same format in the specification used to generate the unsigned data packet m in step3002 (otherwise thesender102 may not understand the signed data packet). In some alternate embodiments, thesender102 can provide client side code to receive the signature input, which in turn theservice106 provides to thesigner104 for execution by thesigner104. Such client side code can then perform transformations on the signature input according to the format in the specification.Service method310 continues by receiving the encrypted, signed data packet m and calculating3110 a checksum for the data packet.Signer method320 continues by receiving the checksum and verifying3212 that the checksum calculated by theservice method310 atstep3110 matches the checksum calculated by thesigner method320 atstep3210. Upon such verification, theservice method310 continues by recording3112 audit information, such as described above with respect toFIG. 2.Service method310 continues by sending3114 the encrypted, signed data packet m to thesender102.

Referring next toFIG. 3C,sender method300 continues by decrypting3008 the signed data packet m. The signed version of theelectronic document101 can then be obtained from the decrypted signed data packet. If there is only one designated signer of the document, thesender method300, theservice method310 and thesigner method320 end. If there are more signers who have not yet signed thedocument101, then thesender method300 continues by selecting3010 the next signer and repeating all or portions of the various methodologies described in this disclosure.

Example Graphical User Interface

FIG. 4 shows a screenshot of an exampleelectronic document101 and graphical user interface (GUI)404, in accordance with an embodiment. Thedocument101 contains content402 (e.g., text, graphics, images, sounds, or other information), which when encrypted is not decipherable unless and until it is decrypted using a suitable decryption technique. TheGUI404 may, for example, be rendered by thebrowser112 ofFIG. 1. TheGUI404 can include asignature block406 and adate block408 for entering an electronic signature and date, respectively. Alternatively, or in addition to thesignature block406 and thedate block408, the GUI may include any other input elements that are associated with the electronic document, such as a title, company name, address, e-mail address, phone number, identification or registration number, or any other information or inputs that thesender102 wishes to obtain from thesigner104 on theelectronic document101. The size and position of theGUI404 can be determined from the specification used to generate and encode the data packet(s) associated with theelectronic document101, such as the unsigned and signeddata packets206 and218 described with respect toFIG. 2. In some embodiments, the electronic signature and other inputs are encrypted by thesigner104 before the signeddocument101 is transmitted to thesender102.

Example Computing Device

FIG. 5 is a block diagram representing anexample computing device1000 that may be used to perform any of the techniques as variously described in this disclosure. For example, the user computing system, the desktop publishing application, the document conversion module, the document viewer, or any combination of these may be implemented in thecomputing device1000. Thecomputing device1000 may be any computer system, such as a workstation, desktop computer, server, laptop, handheld computer, tablet computer (e.g., the iPad™ tablet computer), mobile computing or communication device (e.g., the iPhone™ mobile communication device, the Android™ mobile communication device, and the like), or other form of computing or telecommunications device that is capable of communication and that has sufficient processor power and memory capacity to perform the operations described in this disclosure. A distributed computational system may be provided comprising a plurality of such computing devices.

Thecomputing device1000 includes one ormore storage devices1010 and/or non-transitory computer-readable media1020 having encoded thereon one or more computer-executable instructions or software for implementing techniques as variously described in this disclosure. Thestorage devices1010 may include a computer system memory or random access memory, such as a durable disk storage (which may include any suitable optical or magnetic durable storage device, e.g., RAM, ROM, Flash, USB drive, or other semiconductor-based storage medium), a hard-drive, CD-ROM, or other computer readable media, for storing data and computer-readable instructions and/or software that implement various embodiments as taught in this disclosure. Thestorage device1010 may include other types of memory as well, or combinations thereof. Thestorage device1010 may be provided on thecomputing device1000 or provided separately or remotely from thecomputing device1000. The non-transitory computer-readable media1020 may include, but are not limited to, one or more types of hardware memory, non-transitory tangible media (for example, one or more magnetic storage disks, one or more optical disks, one or more USB flash drives), and the like. The non-transitory computer-readable media1020 included in thecomputing device1000 may store computer-readable and computer-executable instructions or software for implementing various embodiments. The computer-readable media1020 may be provided on thecomputing device1000 or provided separately or remotely from thecomputing device1000.

Thecomputing device1000 also includes at least oneprocessor1030 for executing computer-readable and computer-executable instructions or software stored in thestorage device1010 and/or non-transitory computer-readable media1020 and other programs for controlling system hardware. Virtualization may be employed in thecomputing device1000 so that infrastructure and resources in thecomputing device1000 may be shared dynamically. For example, a virtual machine may be provided to handle a process running on multiple processors so that the process appears to be using only one computing resource rather than multiple computing resources. Multiple virtual machines may also be used with one processor.

A user may interact with thecomputing device1000 through anoutput device1040, such as a screen or monitor, which may display one or more user interfaces provided in accordance with some embodiments. Theoutput device1040 may also display other aspects, elements and/or information or data associated with some embodiments. Thecomputing device1000 may include other I/O devices1050 for receiving input from a user, for example, a keyboard, a joystick, a game controller, a pointing device (e.g., a mouse, a user's finger interfacing directly with a display device, etc.), or any suitable user interface. Thecomputing device1000 may include other suitable conventional I/O peripherals, such as a camera1052. Thecomputing device1000 can include and/or be operatively coupled to various suitable devices for performing one or more of the functions as variously described in this disclosure.

Thecomputing device1000 may run any operating system, such as any of the versions of Microsoft® Windows® operating systems, the different releases of the Unix and Linux operating systems, any version of the MacOS® for Macintosh computers, any embedded operating system, any real-time operating system, any open source operating system, any proprietary operating system, any operating systems for mobile computing devices, or any other operating system capable of running on thecomputing device1000 and performing the operations described in this disclosure. In an embodiment, the operating system may be run on one or more cloud machine instances.

In other embodiments, the functional components/modules may be implemented with hardware, such as gate level logic (e.g., FPGA) or a purpose-built semiconductor (e.g., ASIC). Still other embodiments may be implemented with a microcontroller having a number of input/output ports for receiving and outputting data, and a number of embedded routines for carrying out the functionality described in this disclosure. In a more general sense, any suitable combination of hardware, software, and firmware can be used, as will be apparent.

As will be appreciated in light of this disclosure, the various modules and components of the system shown inFIG. 1, such as thesender processing module110, thebrowser112, thesignature processing module114, theelectronic document101, theaudit database116, or any combination of these, can be implemented in software, such as a set of instructions (e.g., HMTL, XML, C, C++, object-oriented C, JavaScript, Java, BASIC, etc.) encoded on any computer readable medium or computer program product (e.g., hard drive, server, disc, or other suitable non-transient memory or set of memories), that when executed by one or more processors, cause the various methodologies provided in this disclosure to be carried out. As used in this disclosure, the terms “non-transient” and “non-transitory” exclude transitory forms of signal transmission. It will be appreciated that, in some embodiments, various functions performed by the user computing system, as described in this disclosure, can be performed by similar processors and/or databases in different configurations and arrangements, and that the depicted embodiments are not intended to be limiting. Various components of this example embodiment, including thecomputing device1000, can be integrated into, for example, one or more desktop or laptop computers, workstations, tablets, smart phones, game consoles, set-top boxes, or other such computing devices. Other componentry and modules typical of a computing system, such as processors (e.g., central processing unit and co-processor, graphics processor, etc.), input devices (e.g., keyboard, mouse, touch pad, touch screen, etc.), and operating system, are not shown but will be readily apparent.

Numerous embodiments will be apparent in light of the present disclosure, and features described in this disclosure can be combined in any number of configurations. For example, in some embodiments, theelectronic signature service106 records information pertaining to the content privacy-preserving electronic documents in a distinct manner from other electronic documents (e.g., non-privacy-preserving documents). Theservice106 may be queried regarding these documents without considering every other kind of document in the system. To accomplish this, the service may store these documents with metadata or flags (e.g., database flags or specific file formats) for designating the documents as privacy preserving documents (e.g., legal contracts). In some embodiments, theelectronic signature service106 enables reporting on, and automatic notification of, events relating to the content privacy-preserving electronic document in a manner that is specific to the document. Such events may, for example, include the signature rate (e.g., the percentage of designated signers who actually sign), the amount of time needed to render a page of the electronic document for a signer, and how many times a signature is refused. Other reports may, for example, include user ratings on the usability of the system, and which senders in an organization are or are not using privacy preserving contracts (e.g., it may be a violation of the organization's polices to fail to use a privacy preserving contract). In some embodiments, theelectronic signature service106 makes available all received data packets to all parties, along with all audit information, thereby enabling the parties to independently audit the transactions. In some embodiments, the file to be signed is a PDF that has been encrypted by one of the available PDF encryption methods (such as passwords, where the password is known to the participants but not to the Service). In some embodiments, the electronic signature service sends and receives encrypted data packets in a Forms Data Format (FDF) file. Example data communication techniques that can be implemented in accordance with such embodiments are disclosed in U.S. Pat. Nos. 7,272,628 and 7,620,682, which are hereby incorporated by reference in their entireties.

One example embodiment provides a system including a storage having at least one memory, and one or more processors each operatively coupled to the storage. The one or more processors are configured to carry out a process at a server operating an electronic signature service, the process including negotiating, with a sender device, a specification for encoding an electronic document in a data packet; receiving, from the sender device, a first encrypted data packet conforming to the specification, the first encrypted data packet including data representing an electronic document; presenting the first encrypted data packet to a signer device without decrypting the first encrypted data packet at the server; receiving, from the signer device and at the server, a second encrypted data packet conforming to the specification, the second encrypted data packet including data representing an electronic signature, the electronic signature representing an indication associated with the electronic document establishing that a person signing the electronic document endorses a content of the electronic document with the intent to affix the electronic signature to the electronic document; and presenting the second encrypted data packet to the sender device without decrypting the second encrypted data packet at the server. In some cases, the specification is configured to define a characteristic of the electronic document, the characteristic including at least one of a number of pages in the electronic document, a size of an image of a page of the electronic document, a data structure describing an input field to be filled out by a signer of the electronic document, and a data structure having a data block and byte positions within the data block that correspond to a representation of the electronic document. In some cases, the process includes providing computer-executable instructions to the signer device that when executed by the signer device cause the signer device to perform a process including decrypting the first encrypted data packet; rendering a user interface based on the specification, the user interface being configured to receive a user input representing an electronic signature associated with the electronic document; and encrypting the user input into the second encrypted data packet. In some cases, the process includes calculating a first checksum on the first encrypted data packet and calculating a second checksum on the second encrypted data packet. In some such cases, the first encrypted data packet is presented to the signer device in response to receiving a first checksum verification from the sender device. In some other such cases, the second encrypted data packet is transmitted to the sender device in response to receiving a second checksum verification from the signer device. In some cases, the process includes recording audit information associated with at least one of the first encrypted data packet and the second encrypted data packet. In some cases, the system includes a network interface operatively connected to the processor, where the network interface is configured to receive the first encrypted data packet from the sender device via a communications network and further configured to receive the second encrypted data packet from the signer device via the communications network. Another embodiment provides a non-transient computer-readable medium or computer program product having instructions encoded thereon that when executed by one or more processors cause the processor to perform one or more of the functions defined in the present disclosure, such as the methodologies variously described in this paragraph. In some cases, some or all of the functions variously described in this paragraph can be performed in any order and at any time by one or more different processors.

Yet another embodiment provides a system including a storage having at least one memory, and one or more processors each operatively coupled to the storage. The one or more processors are configured to carry out a process including receiving, from an electronic signature service device, a first encrypted data packet conforming to a specification, the first encrypted data packet including data representing an electronic document; decrypting the first encrypted data packet; rendering a user interface based on the specification, the user interface being configured to receive a user input representing an electronic signature, the electronic signature representing an indication associated with the electronic document establishing that a person signing the electronic document endorses a content of the electronic document with the intent to affix the electronic signature to the electronic document; encrypting the user input into a second encrypted data packet conforming to the specification; and sending the second encrypted data packet to the electronic signature service device. In some cases, the process includes calculating a first checksum on the second encrypted data packet and verifying the first checksum against a second checksum associated with the second encrypted data packet received from the electronic signature service device. In some cases, the process includes generating a request (e.g., a Hypertext Transfer Protocol (HTTP) request) based on a hyperlink received from the electronic signature service device, the hyperlink being associated with the first encrypted data packet. In some cases, the specification is configured to define a characteristic of the electronic document, the characteristic including at least one of a number of pages in the electronic document, a size of an image of a page of the electronic document, a data structure describing an input field to be filled out by a signer of the electronic document, and a data structure having a data block and byte positions within the data block that correspond to a representation of the electronic document. In some such cases, the user interface includes an electronic signature entry field located at a position within the electronic document that is based on the specification. Another embodiment provides a non-transient computer-readable medium or computer program product having instructions encoded thereon that when executed by one or more processors cause the processor to perform one or more of the functions defined in the present disclosure, such as the methodologies variously described in this paragraph. In some cases, some or all of the functions variously described in this paragraph can be performed in any order and at any time by one or more different processors.

The foregoing description and drawings of various embodiments are presented by way of example only. These examples are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Alterations, modifications, and variations will be apparent in light of this disclosure and are intended to be within the scope of the invention as set forth in the claims.

Claims (18)

What is claimed is:

1. A computer-implemented method comprising:

receiving, from a sender device and at a server operating an electronic signature service via a communication network, a first encrypted data packet including data representing an electronic document, the first encrypted data packet conforming to a specification for encoding the electronic document in a data packet;

presenting the first encrypted data packet to a signer device via the communication network without decrypting the first encrypted data packet at the server;

providing computer-executable instructions to the signer device via the communication network, the computer-executable instructions that when executed by the signer device cause the signer device to perform a process comprising:

decrypting the first encrypted data packet;

rendering a user interface based on the specification, the user interface being configured to receive a user input representing the electronic signature associated with the electronic document; and

encrypting the user input into a second encrypted data packet;

receiving, from the signer device and at the server via the communication network, the second encrypted data packet conforming to the specification, the second encrypted data packet including data representing an electronic signature, the electronic signature representing an indication associated with the electronic document establishing that a person signing the electronic document endorses a content of the electronic document with an intent to affix the electronic signature to the electronic document; and

presenting the second encrypted data packet to the sender device via the communication network without decrypting the second encrypted data packet at the server.

2. The method ofclaim 1, wherein the specification defines a characteristic of the electronic document, the characteristic including at least one of a number of pages in the electronic document, a size of an image of a page of the electronic document, a data structure describing an input field to be filled out by a signer of the electronic document, and a data structure having a data block and byte positions within the data block that correspond to a representation of the electronic document.

3. The method ofclaim 1, further comprising calculating a first checksum on the first encrypted data packet and calculating a second checksum on the second encrypted data packet.

4. The method ofclaim 3, wherein the first encrypted data packet is presented to the signer device in response to receiving a first checksum verification from the sender device.

5. The method ofclaim 3, wherein the second encrypted data packet is presented to the sender device in response to receiving a second checksum verification from the signer device.

6. The method ofclaim 1, further comprising recording audit information associated with at least one of the first encrypted data packet and the second encrypted data packet.

7. A computer-implemented method comprising:

receiving, from a server operating an electronic signature service via a communication network, a first encrypted data packet including data representing an electronic document, the first encrypted data packet conforming to a specification for encoding the electronic document in a data packet;

receiving, from a sender device via the server via the communication network, computer-executable instructions that when executed cause a signer device to perform a process comprising:

decrypting the first encrypted data packet;

rendering a user interface based on the specification, the user interface being configured to receive a user input representing an electronic signature, the electronic signature representing an indication associated with the electronic document establishing that a person signing the electronic document endorses a content of the electronic document with an intent to affix the electronic signature to the electronic document;

in response to receiving the user input, encrypting the user input into a second encrypted data packet conforming to the specification; and

sending, via the communication network, the second encrypted data packet to the server operating the electronic signature service.

8. The method ofclaim 7, further comprising calculating a first checksum on the second encrypted data packet and verifying the first checksum against a second checksum associated with the second encrypted data packet received from the electronic signature service device.

9. The method ofclaim 7, further comprising generating a request based on a hyperlink received from the electronic signature service device, the hyperlink being associated with the first encrypted data packet.

10. The method ofclaim 7, wherein the specification is configured to define a characteristic of the electronic document, the characteristic including at least one of a number of pages in the electronic document, a size of an image of a page of the electronic document, a data structure describing an input field to be filled out by a signer of the electronic document, and a data structure having a data block and byte positions within the data block that correspond to a representation of the electronic document.

11. The method ofclaim 10, wherein the user interface includes an electronic signature entry field located at a position within the electronic document that is based on the specification.

12. A system comprising:

a storage; and

a processor operatively coupled to the storage, the processor configured to execute instructions stored in the storage that when executed cause the processor to carry out a process at a server operating an electronic signature service, the process comprising:

negotiating, with a sender device via a communication network, a specification for encoding an electronic document in a data packet;

receiving, from the sender device and at the server via the communication network, a first encrypted data packet conforming to the specification, the first encrypted data packet including data representing the electronic document;

presenting the first encrypted data packet to a signer device without decrypting the first encrypted data packet at the server;

providing computer-executable instructions to the signer device via the communication network, the computer-executable instructions that when executed by the signer device cause the signer device to perform a process comprising:

decrypting the first encrypted data packet;

rendering a user interface based on the specification, the user interface being configured to receive a user input representing the electronic signature associated with the electronic document; and

encrypting the user input into a second encrypted data packet;

receiving, from the signer device and at the server via the communication network, the second encrypted data packet conforming to the specification, the second encrypted data packet including data representing an electronic signature, the electronic signature representing an indication associated with the electronic document establishing that a person signing the electronic document endorses a content of the electronic document with an intent to affix the electronic signature to the electronic document; and

presenting the second encrypted data packet to the sender device via the communication network without decrypting the second encrypted data packet at the server.

13. The system ofclaim 12, wherein the specification is configured to define a characteristic of the electronic document, the characteristic including at least one of a number of pages in the electronic document, a size of an image of a page of the electronic document, a data structure describing an input field to be filled out by a signer of the electronic document, and a data structure having a data block and byte positions within the data block that correspond to a representation of the electronic document.

14. The system ofclaim 12, wherein the process includes calculating a first checksum on the first encrypted data packet and calculating a second checksum on the second encrypted data packet.

15. The system ofclaim 14, wherein the first encrypted data packet is presented to the signer device in response to receiving a first checksum verification from the sender device.

16. The system ofclaim 14, wherein the second encrypted data packet is transmitted to the sender device in response to receiving a second checksum verification from the signer device.

17. The system ofclaim 12, wherein the process includes recording audit information associated with at least one of the first encrypted data packet and the second encrypted data packet.

18. The system ofclaim 12, further comprising a network interface operatively connected to the processor, wherein the network interface is configured to receive the first encrypted data packet from the sender device via the communications network and further configured to receive the second encrypted data packet from the signer device via the communications network.

Images