Signature method, system, and / or device

Abstract

A signing device and / or method for signing a document, where the signing device is used to place a unique code on the document, which is logically associated with data / information located at a URL associated with the unique code.

Description

[Technical field]

[0001] Embodiments of the present invention relate to a signature method, system and / or device for forming a signature that is logically associated with other data in electronic form.

[0002] An electronic signature is used to sign different types of documents in order to authenticate such documents in a manner that can have the same legal status as a handwritten signature and is a typical example of data in electronic form that is logically linked to other data in electronic form.

[0003] A digital signature is a further example of a scheme for, for example, authenticating a document and providing the recipient of such a document with confidence in the document's authenticity by means of the encryption / decryption techniques on which the electronic signature is based. Digital signatures can be used to perform electronic signing, but not all electronic signatures use digital signatures.

[0004] There are several known methods for fabricating documents and signatures, creating forged documents, altering existing documents, or creating unauthorized signatures. When signing documents, such as paper documents, it is easy to commit fraud by, for example, inserting a fake document over a genuine signature, or simply pasting a copied signature onto a document, such as a legal contract. This type of fraud may result in a fraudulent document being considered genuine if, for example, nothing is written over the signature when the paper is signed, or, for example, another statement was originally written over the signature that has been erased or removed, so that the fraudulent document still has a genuine signature.

[0005] US Patent Application Publication No. 20060265590 describes a hardcopy document as authenticating a physical representation of a digital signature or a public key that is attached to a hardcopy document or object. The method includes attaching a physical representation of a digital signature to a hardcopy document and converting it into an electronic digital signature. The electronic digital signature is compared to the public key to verify the authenticity of the hardcopy document. Overview

[0006] The following embodiments and aspects thereof are described and illustrated in conjunction with exemplary and illustrative systems, tools and methods that are not intended to be limiting in scope.

[0007] At least some aspects of the present invention relate to providing access, e.g., via a Uniform Resource Locator Link (URL), to a server on which data may be stored, the data being logically associated with at least some embodiment of a signing device (SD) of the present invention and / or with a document that has been signed by the signing method of the present invention.

[0008] In an embodiment, the signing of a document may be performed by using a signing device (SD), possibly a portable SD, capable of generating a unique code (UC) in the form of an electronic signature, possibly further secured or enforced by a digital signature. The unique code (UC) according to at least some embodiments of the invention may be imposed on a document, possibly a paper document. Data stored and / or uploaded at the above mentioned URL may be logically associated with the unique code (UC).

[0009] In some cases, such a URL may be formed after analyzing a UC assigned to a document via a signature device (SD). The URL may be provided to a user to view stored data associated with the UC. In one embodiment, the URL may point to a document and / or information located on a cloud-based web page.

[0010] Access to the data / information at the URL may in some cases require login access permissions, but in some cases such data may be considered public, and at least some of the information may be considered public. In one non-binding example, public information may include the signer's name, date, location, signer's email, phone (and the like). In one example, some information may remain private, such as the signer's phone number, personal ID, the signed document itself (and the like). In some cases, some information may be user restricted, such as the work department where the signing action occurred, the authorized signer's position within the company, work location (and the like).

[0011] In some cases, the URL pointing to the restricted document / information may require login / sign in. After the user gains access, at least some information related to the "signed" document may be revealed. The information revealed may be related to the user accessing the data and may be determined by characteristic details such as their email (or similar).

[0012] In one embodiment of the present invention, the application of a unique code (UC) via a signature device (SD) may generally be by a stamping and / or encoding operation applied to a document.

[0013] At least some embodiments of the signature device (SD) may be configured to form a unique code (UC) that is "visible" under normal conditions (e.g., normal "natural light" conditions, including a combination of direct and indirect sunlight during the day). For example, such a visible UC may be formed using a colored liquid and / or a glue (e.g., ink) to impart the unique code (UC) onto the document.

[0014] At least some embodiments of the signature device (SD) may be configured to form a unique code (UC) that is "invisible" under normal conditions (e.g., normal "natural light" conditions). For example, such an "invisible" UC may be formed using luminescence, such as by using a fluorescent material to form the UC.

[0015] In some embodiments, "invisible" markings may be used in combination with "visible" markings to form a unique code (UC) to further avoid tampering with the UC signed by the SD and prevent (or reduce the likelihood of) creating a counterfeit document.

[0016] Such a combination of "invisible" and "visible" markings can be achieved by doping (i.e. the deliberate introduction of "invisible" type substances together with "visible" type substances) or by selective distribution of "invisible" type (e.g. fluorescent type) elements or particles in order to mark signed, e.g. paper documents with "invisible" permanent tags for more complex authentication and tracking.

[0017] In some cases, the combination of an "invisible" marking and a "visible" marking to form a unique code (UC) may be defined as being in the form of a colloid, where the "invisible" marking is considered to be suspended in the "visible" marking. Such a suspension may be defined as a dispersion of solid or liquid particulates (here, the particles that form the "invisible" marking) in a fluid or liquid (here, the material that forms the "visible" marking). In some cases, such a combination may be further defined by the buoyant support of the particles that form the "invisible" marking.

[0018] Granting UC via at least some SD embodiments may require an authentication process, perhaps an initial stage of authentication to determine that the person operating the signing device (SD) is an authorized user (AU) of the SD.

[0019] Such authentication may be performed via biometric authentication, for example via fingerprint authentication of the person operating the SD. This authentication may be performed via a local scanner that may be integrated into an embodiment of the signature device (SD), for example a fingerprint scanner in the case of fingerprint authentication, or via a device in close proximity to the SD, for example a mobile device possibly communicating with the SD via a wired or wireless (such as Bluetooth) connection.

[0020] Conceivably, authentication of a user operating the signing device (SD) may be performed by requiring the authorized user (AU) to enter a password, such as an alphanumeric code. In at least some embodiments, the authorized user (AU) may initially perform a biometric authentication and, if this fails, may be required to perform one or more possible additional biometric authentications. In some cases, if such an initial biometric authentication fails, the user may be prompted to perform additional authentication attempts by other means / methods, such as entering an alphanumeric code. The biometric authentication methods of various embodiments of the present invention may include at least one of voice analysis, vocal cord or iris analysis, face analysis (and the like).

[0021] In some embodiments, various biometric (e.g., fingerprint) sensors may be used within the signature device (SD), such as optical, capacitive, thermal, pressure, ultrasonic, and RF sensors. In some embodiments, biofeedback (galvanic skin resistance, thermometer, heart rate), possibly integrated into a biometric (e.g., fingerprint) detection device, may be used as an authentication method to analyze the physiological or mental state of a user signing a particular document at a given time.

[0022] In some cases, an Authorized User (AU) may be in a location different from where the Signing Device (SD) associated with the AU is actually located. Such a different location may be a different physical location and / or a different possibly remote area, such as a different workplace, city, country, etc. In such cases, a remote authentication process may be performed first and the actual "signing" (i.e. physically granting the UC) may be performed by another person assisting the Authorized User (AU).

[0023] Such a remote "signing" process may include providing a scan or image of the "signed" document (by the UC) to the AU to verify that the remotely granted UC is authentic and / or valid prior to the creation of a URL where data associated with the "signed" document is located / uploaded.

[0024] In some cases, a signing method according to at least some embodiments of the present invention may include in an initial step the collection of information that may be used in a later step to generate a unique code (UC). Such collected information may include user ID, date, location, and various bits of information, perhaps collected from the mobile device of the authorized user (AU) using the signing device (SD).

[0025] Such information that may be collected may be obtained wirelessly (e.g., via a Bluetooth connection) and may include GPS location information, WIFI information, WIFI location information, carrier information, carrier location information, IMEI, email (and the like). In one embodiment, information may be collected by the signature device (SD) and / or stored by means of, for example, a microprocessor and / or memory contained on the SD.

[0026] In one embodiment, the generation of a unique code (UC) (e.g., a digitally signed UC) may include applying a function that "mixes" or "uses" all, most, or at least some of the information collected to generate the UC. Such a unique code (UC) may be an electronic UC, or may be a digital UC if, for example, it is compiled to include an image of the signed document (or part thereof). Such a unique code may also be configured to include a URL link to where the data associated with the UC is located or uploaded. The unique code (UC) may in some cases be linked to a URL that is formed from at least some of the information from which the UC is formed. The URL may also be randomly generated.

[0027] In one non-binding example, the unique code (UC) may be formed by multiplying a number representing a current date (e.g., applying a multiplication function to the number 091017 representing the date October 9, 2017) and then, for example, multiplying the result by a user ID (or the like) to generate a unique code (UC) representing the result. Other techniques for secure information / communication, such as cryptography and / or cryptographic hash functions, may be used to form at least some unique codes (UC) of the present invention. For example, techniques for forming the UC may include at least one of the following: Rabin encryption, SHA-256 algorithm, SHA-512 hash function, and the like. Once the unique code (UC) is formed, the unique code (UC) may be used by an authorized user (AU) to compose a so-called "signing" event (EV) in which the UC is attached to a document by a signing device (SD).

[0028] At least some signing method embodiments of the present invention may involve the performance of a signing event (EV) that may include applying similar unique codes (UC) multiple times (e.g., by stamping / printing / signing) to the same document (e.g., to an area or page of a document) or to multiple documents that are related to each other (e.g., multiple contracts related to similar legal matters).

[0029] Conceivably, such similar UCs used multiple times in an EV may have a single URL where data associated with the UC is stored, and an EV may involve applying (e.g., by stamping) a unique code (UC) only once, e.g., stamping a single page with the UC once.

[0030] In one aspect of the invention, information regarding one or more Signature Events (EV) may be temporarily stored in an embodiment of the Signature Device (SD) used to apply the EV. Each such Signature Event (EV) may therefore include data / information that is collected to generate a Unique Code (UC), which may be used in the EV and a URL where data associated with the UC is stored.

[0031] In at least some embodiments, data / information for one or more signature events (EVs) may be temporarily stored on the signing device (SD) performing the EVs when the SD is in "offline" mode, and such data / information may then be uploaded to a URL associated with said EVs when a secure connection is established between the signing device (SD) and the web.

[0032] Upon establishing the connection (or shortly thereafter), the respective actual links may be generated in the cloud (possibly on a dedicated server). For each EV stored on the SD, a URL link (e.g. https: / / lynx.io / W5h67r) may be created. Upon or after the URL / link is generated, the information of the EV associated with this link may be uploaded to the currently existing URL.

[0033] In one embodiment, a remote "signing" process may include the following steps: A user at the location where the document resides sends an image of the page of the document to be "signed" to an authorized user (AU) at a remote location for remote approval / signature. The authorized user (AU) then verifies the document and, if approving, may authenticate himself / herself via biometric means (e.g., a fingerprint scanner). The process including this authentication may possibly be performed via computational means, such as, for example, a dedicated mobile application running on a mobile device, such as the authorized user's (AU's) mobile device.

[0034] Such computing means may then transmit a confirmation via secure communication to the local user and the local user's own signing device (SD), where a unique code (UC) and URL may be formed for the upcoming stamping operation (e.g., EV).

[0035] In one embodiment, the unique code (UC) may be implemented in various other forms, such as a matrix barcode, e.g., a QR code (notably, the aspects described herein are not limited to QR codes). The content of the message included in such a QR code type UC may be further hashed, for example, by forming a hash result such as e18f415ae8fef102d57e69d6d316d59ef6d30e85. This hashed result may be communicated along with a public key to form a digital signature.

[0036] Encrypting the message content may include applying a Zip image to the message content. In addition to the message hash value and the Zip image of the message, additional information may be collected, such as the signer's ID, date, location, information from a Bluetooth connected phone (GPS location, WIFI information, WIFI location information, carrier information, carrier location information, IMEI, email address, etc.).

[0037] In one embodiment, a unique code (UC) in the form of a QR code may be established taking into account information such as a URL formed on a server (e.g., https: / / lynx.io / W5h67r) and an unencrypted message such as "Follow these steps to read your message...".

[0038] The QR encoding process in at least some embodiments may take into account the message and a hash function, for example, the hash result e18f415ae8fef102d57e69d6d316d59ef6d30e85 may be taken into account along with a private key to generate a digitally signed Unique Code (UC).

[0039] For a hardcopy document that has been authenticated by a unique code (UC), an OCR function may be applied to extract text and numbers from the document (although commas, dots, and other small symbols may be ignored for better OCR results). After the OCR is successful and letters and numbers have been extracted (possibly removing upper or lower commas, dots, and other small symbols), the next step may be followed, such as applying a hash function with a private key to generate a digital UC signature.

[0040] In some embodiments of the invention, a user may perform manual authentication of a message, which may be done when fraud is suspected and other processes, such as automated processes, do not provide the required certainty of the authenticity of the signed document.

[0041] An Authorized User (AU) who wishes to verify that a previously signed document is authentic (e.g., has not been tampered with), for example by using specialized software, may be prompted to select an option to "authenticate" or "suspect." Upon selecting "suspect," the Authorized User (AU) or a person associated with the AU may be provided with content associated with the signed document and / or its UC, such as a zip image or scan of the document to inspect whether any alterations to the document may have been made, such as the addition of "commas," Arabic numerals, etc. Among other things, adding information such as "commas" may result in a different hash value, thus introducing errors into the authentication process.

[0042] In the case of a Unique Code (UC) of type QR Code, if the message in such QR code is zip-imaged in the QR code, the zip image may be extracted and unzipped to display the message.

[0043] In some cases, the soft copy may be stored on the web, for example on a dedicated server that stores data / information about the EV. For example, in case of suspected fraud, the soft copy may be stored at a URL associated with the EV. If the initially signed document has already been uploaded to that URL, either by the user or automatically, it may be possible to switch to a soft copy of the previously signed document.

[0044] Authentication of a signed document (eg, a legal contract) where tampering is suspected on a soft copy of the document stored on the web can be done as follows.

[0045] In a possible first step, an OCR of the suspect document may be performed and a hash function based on the OCR may be obtained. Then, possibly automatically, the hashes of both messages (that of the current suspect document and that of the soft copy stored on the server) may be displayed and matched. The comparison may provide a matching score percentage and possibly indicate mismatches / inconsistencies, for example by highlighting them in red. The user may also be asked to go through the mismatches / inconsistencies one by one and confirm or mark each highlighted difference as invalid. And in a last possible step, a summary of the authentication and the results may be displayed.

[0046] In a further example (possibly combined with the previous example or independent), information may be extracted from the signature to verify its validity. In a first step, the stamped unique code (UC) is scanned and recognized, e.g. a QR code type UC may be scanned by a QR code scanner. In one example, a link may be extracted from the scan pointing to a web server / cloud where information associated with the UC can be accessed under certain restrictions.

[0047] Further references may be extracted if more information is encoded in the UC, such as a QR code type UC, which may contain user information, a URL (e.g., https: / / lynx.io / W5h67r), an unencrypted message (e.g., "Follow these steps to read the message..."), a document hash value, a zip image of the message, a public key, a digital signature (and the like).

[0048] In some cases, more than one method may be applied at once to verify the authenticity of a signed document.

[0049] In addition to the exemplary aspects and embodiments described above, further aspects and embodiments will become apparent by reference to the drawings and by study of the following detailed descriptions. [Brief description of the drawings]

[0050] Exemplary embodiments are shown in the referenced drawings. It is intended that the embodiments and drawings disclosed herein be considered illustrative and not restrictive. However, the invention, both as to organization and method of operation, together with its objects, features, and advantages, may best be understood by reference to the following detailed description taken in conjunction with the accompanying drawings, in which:

[0051] [Figure 1A] FIG. 1A illustrates a schematic diagram of an embodiment of a signature device (SD) of the present invention placed in a stamped / signed state on a surface, such as the cover of a paper document, to be signed according to various methods of the present invention.

[0052] [Figure 1B] FIG. 1B is a schematic diagram of an embodiment of a signing device substantially identical to that of FIG. 1A, but removed from a surface, showing one possible type of unique code (UC) that may be printed / stamped on the surface or that may remain attached to the surface.

[0053] [Figure 2A-2B] 2A and 2B are schematic top and bottom perspective views, respectively, of an embodiment of a signature device (SD) substantially identical to the signature device of FIG.

[0054] [Diagram 3] FIG. 3 illustrates diagrammatically the steps that may be included in an embodiment of the method of the present invention, using a signing device (SD) possibly similar to the signing device of FIGS. 1 and 2, illustrating the formation of a URL associated with a unique code (UC) provided by the SD.

[0055] [Figure 4]FIG. 4 illustrates a schematic of a sequence of actions that may be taken to create a unique code in accordance with at least some embodiments of the present invention.

[0056] [Figure 5A-5E] 5A-5E are schematic diagrams illustrating a unique code (UC) and / or data or information associated with such a UC, in accordance with at least some embodiments of the present invention.

[0057] [Figure 6] FIG. 6 illustrates diagrammatically a step which may be included in an embodiment of the method of the present invention, namely the so-called remote authorization of a signing operation performed by at least some embodiment of the signing device of the present invention.

[0058] [Figure 7A-7D] 7A-7D are schematic flow charts useful for understanding various embodiments of the present invention.

[0059] It will be appreciated that for simplicity of illustration and ease of understanding, elements shown in the figures have not necessarily been drawn to scale. For example, dimensions of some elements may be exaggerated relative to other elements for ease of understanding. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate similar elements. DETAILED DESCRIPTION

[0060] Attention is first directed to Figures 1A and 1B, which illustrate an embodiment of a signature device (SD) 10 of the present invention. In one aspect of the present invention, the signature device (SD) 10 may be used to sign a physical document, such as the illustrated document 12. Here, the signature device (SD), in the form of a "rubber stamp," is illustrated as forming / impressing a unique code (UC) 14 on the document.

[0061] Attention is further directed to Figures 2A and 2B, which show top and bottom perspective views, respectively, of one possible embodiment of a signature device (SD) 10. The SD 10 in this example is equipped with an authentication device 16, here a possible biometric authentication device, configured to detect a biometric characteristic of a user attempting to operate the SD.

[0062] In this example, the authentication device 16 may be a fingerprint authentication device. A user considering signing a document with the illustrated signature device (SD) may be instructed / required, in a first initial step, to place a finger to be used for authentication on the authentication device 16 in order to be recognized as the user. In other embodiments (not shown), the authentication device may be configured to identify other types of biometric features, such as voice, retina, iris (or the like).

[0063] In the illustrated example, the signature device (SD) 10 is shown including a stamping means 140 at its bottom portion, which is configured to form a unique code (UC) 14 on the document being signed. The stamping means 140 in this example includes a number of markers (five markers in this example) 141-145.

[0064] The marker in this example has a downwardly sloping configuration towards a protrusion 170 that is configured to form a marking (in this example a relatively short line marking) when the SD is used to form a unique code (UC). In one example, at least some embodiments of the signature device (SD) may be configured to form a type of marking that is "visible" under normal conditions (e.g., normal "natural light" conditions), such as by dipping the protrusion of the marker in ink and then transferring it to a surface against which the SD is pressed to provide the UC, in this alternative example.

[0065] Some embodiments of the signature device (SD) may be configured to form a unique code (such as UC14 or UC100) that forms an "invisible" type marking under normal conditions (e.g., normal "natural light" conditions) instead of or in addition to a "visible" type marking. Such an "invisible" type marking may be formed, for example, using luminescence by using a fluorescent material, and when combined with a "visible" type marking, may be placed inside the "visible" type marking, for example, by doping or selective distribution (or the like). The combination of an "invisible" marking and a "visible" marking may be defined as a form of colloid, where the "invisible" marking is possibly suspended throughout the "visible" marking.

[0066] Referring again to FIG. 1B, the short markings 17 in the unique code (UC) 14 may be formed by means generally similar to the protrusions of the imprinting means 140.

[0067] In various embodiments of the present invention, at least some SD implementations may include a local camera scanner (not shown). This scanner may be integrated into the SD to make the SD more autonomous, independent of external camera / scanner devices such as smartphones, and more secure. This camera / scanner may be used to scan documents before and / or after signing, for example, for authentication, which may be discussed herein.

[0068] A signing device (SD), such as device 10, may, at least in some embodiments, be configured for operation by one or more authorized users (AUs). Authenticating that a user attempting to operate the SD is an authorized user may include an authentication process 200 shown in FIG. 7A.

[0069] A positive authentication made in an initial step 201 that the user operating the signing device (SD) is a legitimate user may initiate a step 202 of collecting information that may later be used in a next step 203 to generate a unique code (UC) to be imprinted by the SD. The authentication made in step 201 may be performed by the user placing a finger on the authentication device 16.

[0070] Such information may include an ID number associated with the authenticated authorized user (AU), date, location, and additional information that may be collected, for example, from the authenticated authorized user's (AU's) mobile terminal.

[0071] In one embodiment, when generating a unique code (UC) to be stamped by a signature device (SD) while in use by an authorized user, a shape / structure for the UC may be obtained that represents at least a portion of the information collected about the AU. For example, a function may be applied to all, or most, or at least a portion of the collected information that results in some "score" that may be represented by the shape / structure of the UC.

[0072] In the illustrated example, the shape / structure of the resulting unique code (UC) may be formed in a further step 204 by altering the positions of the markers 141-145 to form a so-called "marker combination" that represents the calculated "score." In this example, the signature device (SD) may include one or more internal actuators (not shown) for altering the positions of the markers to form the required structure of the unique code (UC).

[0073] In addition to generating the unique code (UC), step 205 may also form a unique URL where information related to the UC may be stored. This URL may be assigned by a server that communicates and / or cooperates with the signing device (SD) or by the signing device (SD) itself (e.g., by a processor running on the SD).

[0074] Various signature device (SD) embodiments (not shown) may have different mechanical or other forms and may be configured to form a unique code (UC) of a different shape / form than that shown in Figures 1B and 2B in step 204. For example, at least some signature device (SD) embodiments may be configured to form various types of unique codes (UC), such as a QR code.

[0075] For example, a portable signature device (SD) in at least some embodiments of the present invention may comprise a code (which may be a QR code) generating means (e.g. a printing means such as an inkjet printer) for applying / stamping a unique code (UC) onto a document to be signed, such that the UC is applied onto the surface to be signed by first placing the SD on the surface and then dragging the SD laterally along the surface to apply the UC.

[0076] At least some embodiments of the signing device (SD) may be configured for "offline" operation, where there may be no communication with an external environment, such as the Internet. Such an embodiment of the signing device (SD) may be used to perform one or more signing actions during such "offline" periods. Each signing action may be characterized as a separate signing event (EV) if, for example, it involves at least one of a different authorized user (AU), a different time at which the signature is performed, a different document signed (or the like).

[0077] In one embodiment, information relating to different signature events (EV) may be stored on the signature device (SD) and uploaded to a server, possibly a dedicated server configured to cooperate with the signature device (SD), until external communication is possible and / or resumed.

[0078] Attention is now directed to Fig. 3, which illustrates such an upload process from a signing device (SD) 10 to a server 20, possibly a cloud server. Different signing events (EVs) may be stored in dedicated URLs, where dedicated URLs are marked as URLs (1) to (n) for n signing events (EVs) stored on the signing device (SD) after they have been executed during its "offline" period.

[0079] Attention is now directed to Figure 4, which illustrates one possible example of generating a unique code (UC) to be stamped by a signature device (SD) of at least some embodiments. Starting at the top of the figure, a possible first step 101 of collecting information to be considered in forming the unique code (UC) is illustrated.

[0080] In this optional example, the information collected includes the current date (in this example, November 6, 2017), the personal ID of the user attempting to use the SD, a number representing the signature event (EV) that is about to occur, possibly entered by the user operating the SD, and the serial number (or the like) of the SD being used.

[0081] In a next step 102, these pieces of information may be communicated to a "generator" 32 configured to use the input information values ​​to form an "output" 34. The generator 32 may implement various techniques for secure information / communication to form the output 34, such as cryptographic techniques and / or cryptographic hash functions (and the like). For example, techniques that may be implemented by the "generator" 32 may include at least one of the following: Rabin cipher, SHA-256 algorithm, SHA-512 hash function (and the like). A key, such as a private key, may be utilized / used during the process of generating the unique code (UC).

[0082] The output 34 in this example includes a "message" consisting of multiple "tags," here including numbers and letters. The content embedded within the "message" (e.g., groups and / or combinations of "tags" within the "message") can be used, for example, to determine a unique code (UC) to be used by the SD in the signature event (EV) that is about to occur (EV 00013 in this example).

[0083] The illustrated example shows the formation of a number of numerical values ​​(five values ​​in this example) from the "message". In this example, these values ​​are shown as X1 through X5. Each of the values ​​X1 through X5 may be normalized to fall within a predetermined range, in this example between "0" and "315" if desired. The conversion of the "message" of output 34 to values ​​X1 through X5 is indicated to the right of "output" 34 by a double-sided arrow, with each value of X1 through X5 shown in its corresponding position within the predetermined range.

[0084] In at least some embodiments, signing device (SD) 10 may be configured to set the relative position of each of its markers 141-145 according to values ​​of X1-X5. For example, a value of X1 may set the position of marker 141, a value of X2 may set the position of marker 142, a value of X3 may set the position of marker 143, a value of X4 may set the position of marker 144, and a value of X5 may set the position of marker 145. The markers that reach their respective positions may then be used in a signing operation to form a unique code (UC) by the signing device (SD).

[0085] The illustrated optional example of a process for obtaining a UC 14, together with the steps for forming a UC described above, represents a type of UC that may be more suitable for an organization that may require substantial internal control measures for distributing the UC. In one non-binding example, such a type of UC may be considered preferable for an organization such as a government agency (e.g., customs) where internal standards for signature authentication may be enforced.

[0086] More open UC types may include, for example, QR code type UCs. Turning to Figures 5A and 5D, such a QR code type unique code (UC) 100 is described along with a series of possible steps that may be taken to generate such a UC (Figures 5A and 5B) and to read information embedded within the UC (Figures 5C and 5D) in at least some embodiments of the present invention.

[0087] In Fig. 5A, a first step 1001 of forming "encrypted data" is shown, which in this example involves obtaining "OCR data" of the signed document of a portion of the document (e.g., using an application running on the authorized user's mobile device) and then forming the "encrypted data" using a "private key". Step 1001 may be performed at least in part on a dedicated application (APP) running on the authorized user's (AU) mobile terminal (or similar).

[0088] In a second possible step 1002, examples of data to be embedded within a UC, such as UC 100, may be shown. A first set of data 36 embedded within UC 100 may be formed by ZIP imaging the "encrypted data" generated in the previous step. In this example, a "public key" may be embedded within UC 100 as data 38, which may be used to open the ZIP imaged "encrypted message." Further possible information that may be embedded within a UC are a "message" and a "link."

[0089] The "message" may be, for example, instructions on how to access the data in the UC100 (such as go to ... and download the "APP"). The "link" may be to a location on a dedicated server where data associated with the UC may be stored. In one embodiment, steps 1001 and 1002 may be performed automatically by the dedicated APP after imaging at least a portion of the signed document. This results in an output of a UC (e.g., UC100) to be, for example, stamped on the signed document.

[0090] In some embodiments, steps 1001 and 1002 may be performed in a variety of ways, such as in a cloud-based application that may then be communicated to, for example, an SD for signing, or may be performed locally on an SD configured to stamp the UC.

[0091] Attention is now directed to Figures 5C and 5D, which illustrate a possible process for reading data embedded within a UC, such as UC100. In a possible first step 1003, the data embedded within UC100 may be identified to obtain the encoded data. In this example, this data is shown as binary data including 0's and 1's. In this example, the APP used to read UC100 may identify a portion of the data, such as the data within regions 40 and 42 of the UC. This portion of data may be, for example, a message explaining where to download a dedicated APP for reading the UC and a link to where the data associated with the UC may be stored.

[0092] The presence of a public key embedded in field 38 may also be identified, and text contained in field 40, for example, may instruct the user how to decrypt encrypted data embedded in field 36. In one embodiment, access to the public key to assist in reading UC100 may be granted only after "logging in" via a link provided in the data in field 42.

[0093] Thus, the unique code (UC) 100 may include encoded data that may be embedded within different regions. Although, for simplicity, such different regions are shown as being separate adjacent rectangular regions in the illustrated examples of Figures 5B and 5C, embedding of information within a unique code such as UC 100 may occur throughout the UC, such as within interspersed portions / regions of the UC (etc.).

[0094] According to at least one embodiment, links (URLs) to locations where data / information related to UC may be stored may be categorized as "openly accessible" or "restricted access." 5E , such categories are shown, where so-called "freely accessible" links (URLs) may allow the display of the information therein (possibly public information) without requiring a password or the like (as shown on the left side of the figure). So-called "restricted access" links (as shown on the right side of the figure) may require an "entry" action from the user who reaches the link, which may include a login process and creating an account (if there is no existing account for the user who reaches such a link). After "entry", the user may gain full or partial access to the information in the link, or may be denied access.

[0095] With further attention to Figure 7B, a flow chart is shown illustrating possible steps for decoding / obtaining information within UC 100. In a first possible step 301, a known QR code reader or scanner can be used to read UC 100. At least a portion of the information embedded in UC 100 (as shown in connection with Figure 5) may be configured to be at least readable by a known QR code scanner and thus revealable in step 302. Such information may include a field 42 that defines a URL where data associated with UC 100 may be stored.

[0096] The additional information that may be read by known scanners and that may be considered to be revealed in step 303 may thus be embedded, for example, in region 40 and may include an indication (e.g., a message) on where to download a dedicated QR code reader that can read the additional information embedded in the unique code (UC) 100. If not read, this information may remain unrevealed or unintelligible. For example, a message may be something like "Download ... to read the complete code." As mentioned above, the regions of the UC, such as region 40, may not necessarily be rectangular as shown, but may be spread out (or similarly) so as to be scattered around the UC.

[0097] Thus, field 36 may contain a ZIP image of the authentic contents of the document (or a portion thereof) that was originally signed with UC 100. Some fields may also embed a hash of the document or a hash of a portion of the document. In at least some cases, the ZIP and / or hash may be formed by scanning the document to be signed prior to applying the unique code (UC) 100 to the document.

[0098] In embodiments where "invisible" markings (under normal conditions, e.g., "natural light" conditions) were used to form at least part of the unique code (UC) on the "original" signed document, the scan of such "original" document may be adjusted to substantially ignore (e.g., not capture) such "invisible" markings. This may, for example, facilitate avoiding such markings from interfering with and / or causing interference with the content of the "original" document.

[0099] In some cases, scanning of a unique code (UC) that is an "invisible" type of marking (e.g., fluorescent ink) and / or a unique code (UC) that includes such marking may be performed by a scanner configured to capture such "invisible" materials used in the UC.

[0100] In some cases, a user or person wishing to verify the authenticity of a signed document bearing a UC known to have originally contained "invisible" markings may visually inspect such UC under appropriate lighting conditions designed to reveal the "invisible" material. The absence of such "invisible" markings may indicate possible falsification of the UC and / or possible falsification of the content within the document bearing such UC.

[0101] To provide access to this document in step 304, a ZIP image of the original signed document may be unzipped using a dedicated QR code reader and / or a dedicated application, possibly downloaded from the URL revealed in field 42. Such a dedicated application may be a mobile app running on a mobile terminal. A hash of the original signed document may also be revealed by the dedicated application / reader in step 305.

[0102] Viewing or accessing the actual document originally signed by UC100 may provide a means to compare the contents of the current document bearing UC100 with the original document that was originally signed. Such a comparison may provide evidence that the originally signed document has not been altered or tampered with between its original signing and the current inspection.

[0103] In one embodiment, a comparison may be made between the original signed document and the currently verified signed document by initial step 306 scanning the current document and applying OCR to the scan, and then subsequently applying a hash function to the OCR'd scan in step 307, perhaps to make a comparison 308 between the hash of the currently verified document and the hash made to the original signed document.

[0104] If the hashes do not match, doubts may be raised about the authenticity of the current document. For example, the original signed document may be a legal contract that refers to a sum of $1 million. Tampering with the document after it was originally signed may include changing this sum to show $10 million. Thus, a change in this amount underlying the disputed contract may be revealed by comparing the hash value of the current document with the hash value of the original document.

[0105] In some cases, the ZIP image of the signed document embedded in area 36 of the UC 100 may include only a portion of the signed document, although the hash embedded in one of the areas of the UC 100 may be of the entire document. For example, the signed document may include ten pages, and creating a ZIP image containing the information of all ten pages and embedding it in area 36 of a standard size QR code type UC may not be practical due to insufficient space in area 36 to accommodate such a large amount of ZIP compressed information. On the other hand, the hashes of the ten pages are effectively a "line" of information that can easily be placed within one area of ​​a standard size QR code.

[0106] One aspect of at least some embodiments of the present invention is to increase confidence in the authenticity of a verification document signed by a UC due to the dual security provided by the ZIP image and the hash. For example, using only the hash could allow a document to be compromised by altering some information in the document (such as changing $1 million to $10 million) and then altering another portion of the document to obtain a hash that appears similar to the hash of the original, unaltered document (perhaps by trial and error).

[0107] Attention is directed to Figure 7D, which illustrates possible steps that may be taken after attempting to match "original" content stamped with a given UC (e.g., as described above) with "current" content marked with such a given UC. An automated comparison / authentication between the "original" content and the "current" content may, for example, result in a positive match between the contents or may identify a mismatch between the contents, for example, between a hash of the "original" content and a hash of the "current" content.

[0108] If such automatic verification / authentication fails (as indicated by "NO" at the top of FIG. 7D), the user attempting such verification may be instructed to manually inspect the inconsistencies causing such a negative result. The user may have the "original" content and the "current" content to be authenticated, in this optional example, both displayed on a split screen. The user may then be directed to the location of the inconsistency in the content to manually inspect the inconsistency between the two contents.

[0109] If, during such checking, the user determines that an identified discrepancy is incorrect (e.g., due to an error in OCR made on the content) and is a "false alarm," the user may choose to correct / ignore this discrepancy or may be guided to further possible discrepancies (as indicated by the "next" rectangle marked in FIG. 7D) until all discrepancies that caused failures in previous automatic verifications have been checked.

[0110] If all discrepancies turn out to be "false alarms", then such a manual check can result in a positive manual authentication that can override previous negative results made during the automated process. On the other hand, if the manual verification process results in the same negative result as a previous one, then a double verification (first an automated verification and then a manual verification) can more reliably determine that the "current" content under inspection is not authentic. An authentic "original" copy of the content may be stored, for example, at a URL associated with the UC.

[0111]

[0112] Attention is now directed to Fig. 6, which illustrates a schematic representation of the use of at least one embodiment 10 of a signing device (SD) in a remote signing process. Attention is also directed to Fig. 7C, which provides a flow chart illustrating steps that may occur during such a remote signing process, in which an authorized user 30 may be located remotely from where the signing device (SD) is physically located, and a remote authentication and verification process may be performed to authorize the execution of the signature by the SD.

[0113] In a possible first step 401, a photograph or scan of the document or document page 120 to be signed may be sent to an authorized user 30 at a remote location. In a next step 402, the remote user may receive the scanned data of the document and access it on a dedicated application, possibly running on a device such as a mobile phone.

[0114] The remote user can then read the document and verify it for remote signing in step 403, possibly by placing his or her fingerprint on a fingerprint scanner implemented by the application, which may result in a secure verification 404 being sent to the local user at the location where the document to be signed resides. In a next step 405, the document 120 can be signed by the local user who helps the remote authorized user 30 to approve the signature.

[0115] In the specification and claims of this application, the verbs "comprise," "include," and "have," and words of cognate origin, are used to indicate that the object of the verb does not necessarily represent a complete recitation of the members, components, elements, or parts of the subject of the verb.

[0116] Furthermore, although the present invention or technology has been illustrated and described in detail in the drawings and the above description, such illustrations and descriptions should be considered as explanatory or exemplary, and not restrictive. Therefore, the technology is not limited to the disclosed embodiments. Those skilled in the art can understand and realize variations of the disclosed embodiments, and can implement the technology described in the claims from a study of the drawings, the technology, and the appended claims.

[0117] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" and "an" do not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0118] In addition, when a term, feature, numerical value, or numerical range is described in conjunction with terms such as "about," "approximately," "substantially," "generally," or "at least," the term, feature, numerical value, or numerical range is understood to include the term, feature, numerical value, or numerical range itself. In other words, "about 3" includes "3," and "substantially vertical" includes "vertical." Any reference signs in the claims should not be construed as limiting the scope.

[0119] Although the present embodiments have been described in some detail, it should be understood that various modifications and variations can be made without departing from the scope of the invention as defined below.

Claims

1. A portable signature device (SD) for signing physical paper documents, comprising: the SD is configured to collect information about a signing event, generate by the SD a unique code (UC) from the collected information, and apply by the SD the UC on the physical paper document; The provision of the UC is performed by physically stamping the unique code (UC) on the physical paper document; generating the UC includes cryptographic techniques; the UC is logically associated with data / information located at a URL associated with the UC; The data / information is the collected information or information generated from the collected information; The collected information for forming the unique code (UC) is at least a portion of the document to be signed, and includes text extracted from the paper document by an OCR function; The cryptographic technique for generating the UC includes applying a hash function together with a secret key to the text extracted from the paper document to generate encrypted data, and generating the UC using the encrypted data. Signature Device (SD).

2. The signature device (SD) of claim 1, wherein said unique code (UC) is an electronic signature that is further secured or enforced by a digital signature.

3. The signature device (SD) of claim 1 or 2, wherein the URL points to the data / information located on a cloud-based web page.

4. A signature device (SD) according to any one of claims 1 to 3, configured to allow only authorized users (AU) of said SD to generate unique codes (UC).

5. A signature device (SD) according to any one of claims 1 to 4, wherein the placing of at least a part of the unique code (UC) on the document utilises markings that are visible under normal conditions.

6. A signature device (SD) according to any one of claims 1 to 5, wherein applying at least a part of said unique code (UC) on said document utilises markings which are invisible under normal conditions.

7. 1. A method of signing a physical paper document, comprising: providing a portable signature device (SD); providing a physical paper document to be signed; collecting information regarding the signature event; generating a unique code (UC) using the SD and attaching the UC to the paper document by physically stamping the UC; having The generation of the UC includes Including cryptography, forming a URL at which data / information logically associated with said UC is located; The data / information is the collected information or information generated from the collected information; the unique code (UC) consists of and / or includes at least a portion of the collected information, the collected information being at least one of GPS location information, WIFI information, WIFI location information, carrier information, carrier location information, IMEI, an email of an authorized user (AU) of the SD and / or an email of a device associated with the AU; The collected information includes text extracted from the paper document using an OCR function; The cryptographic technique for generating the UC includes applying a hash function together with a secret key to the text extracted from the paper document to generate encrypted data, and generating the UC using the encrypted data; configured to perform remote signature processing by the AU of the SD that is located at a location remote from the location of the SD; The remote signature process includes: authenticating the authorized user (AU) through biometric authentication; The remote signing process includes transmitting at least one image of the paper document to be signed to the AU. Including, method.

8. The method of claim 7, wherein the assigning of the unique code (UC) is performed only by an authorized user (AU) of the SD.

9. 9. The method of claim 7 or 8, wherein the collected information is stored by the signature device (SD) in a microprocessor and / or memory contained in the SD.

10. 10. The method of claim 7, wherein said unique code (UC) comprises information consisting of at least a part of said document to be signed.

11. 11. The method of claim 7, wherein the signing device (SD) is configured to be used in different signing events (EV), and in each signing event (EV), the SD is capable of generating one or more unique codes (UC), and all unique codes (UC) in an EV are identical.

12. The method of claim 11, wherein the unique codes (UC) of different signature events (EV) are different.

13. 13. The method of claim 11 or 12, wherein each signature event (EV) has one said URL.

14. A method according to any one of claims 7 to 13, configured to be used in an offline operating mode in which the data / information is stored locally on the SD card.

15. 15. The method of claim 14, wherein the SD is also configured to be used in an online operating mode in which it communicates with an external device / external means, and at least a portion of the data / information stored on the SD during the offline operating mode is configured to be uploaded to the external device / external means during the online operating mode.

Images