JP2021514493A - Signing method, system, and / or device - Google Patents

Abstract

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

Description

Embodiments of the invention relate to signature methods, systems and / or devices for forming signatures that are logically associated with other data in electronic form.

background

Electronic signatures are used to sign such documents to prove that different types of documents are authentic in a way that allows them to have the same legal status as handwritten signatures. It is a typical example of data in electronic form, which is logically associated with other data in electronic form.

Digital signatures, for example, prove that a document is authentic and use the encryption / decryption techniques on which electronic signatures are based to give the recipient of such a document confidence in its authenticity. Is a further example of a scheme for. Digital signatures can be used to make electronic signatures, but not all electronic signatures use digital signatures.

There are several known methods for forging documents and signatures to create counterfeit documents, modify existing documents, or create unauthenticated signatures. When signing a document, such as a paper document, for example, inserting a fake document on top of a real signature, or simply pasting a copied signature on a document, such as a legal contract. It is easy for cheating by doing so. Due to this type of fraud, for example, when signing a piece of paper, nothing is written on the signature, or, for example, another sentence was originally written on the signature. If a fraudulent document has a genuine signature, such as being erased or deleted, the fraudulent document may be considered authentic.

U.S. Patent Application Publication No. 20060265590 describes a physical representation of a digital signature or a hardcopy authentic document as a physical representation of a public key attached to an object. This method involves attaching a physical representation of a digital signature to a hard copy document and converting it into an electronic digital signature. This electronic digital signature is compared to the public key to prove that the hard copy document is authentic.

Overview

The following embodiments and embodiments are described and illustrated in connection with exemplary and descriptive systems, tools and methods and are not intended to be of scope limitation.

At least some aspects of the invention relate to granting access to a server, for example, via a uniform resource locator link (URL). Data may be stored in such a server, and the data is logically associated with at least certain signature device (SD) embodiments of the invention and / or documents signed by the signature method of the invention. ..

In certain embodiments, the signature of a document uses a signing device (SD), perhaps a portable SD, that can generate a unique code (UC) in the form of electronic signatures, perhaps further guaranteed or enforced by digital signatures. Can be composed of. A unique code (UC) according to at least certain embodiments of the present invention may be given on a document, perhaps a paper document. The data stored and / or uploaded at the URL described above can be logically associated with a unique code (UC).

In some cases, such a URL may be formed after the UC assigned to the document is analyzed via the signing device (SD). A URL may be provided to the user to view the 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.

Access to data / information in a URL may in some cases require login permissions, but in some cases such data may be considered public, at least for the information. You may think that a part of it has been made public. In a non-binding example, the published information may include the signer's name, date, location, signer's email, telephone (and similar). In one example, some information, such as the signer's phone number, personal ID, and the signed document itself (and similar) may remain confidential. In some cases, some information, such as the department of the workplace where the act of signing was performed, the title of a legitimate signer in the company, the location of the workplace (and similar) may be user-restricted. Good.

In some cases, URLs pointing to restricted documents / 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 relevant to the user accessing the data, or may be determined by characteristic details such as that person's email (or something similar). Good.

In one embodiment of the invention, assigning a unique code (UC) via a signing device (SD) may generally be due to stamping and / or encoding operations applied to the document.

At least certain signature device (SD) embodiments are "visible" and unique under normal conditions (eg, normal "natural light" conditions including a combination of direct and indirect sunlight during the day). It may be configured to form a code (UC). For example, such a visible UC may be formed with a colored liquid and / or glue (eg, ink) to impart a unique code (UC) on the document.

Even if at least certain signature device (SD) embodiments are configured to form an "invisible" unique code (UC) under normal conditions (eg, normal "natural light" conditions). Good. For example, such "invisible" UCs may be formed, for example, using light emission by using a fluorescent material to form the UC.

In certain embodiments, the "eyes" are used to form a unique code (UC) to further avoid tampering with the SD-signed UC and prevent (or reduce the possibility of) the formation of counterfeit documents. The "invisible" marking may be used in combination with the "visible" marking.

Such a combination of "invisible" and "visible" markings puts "invisible" permanent tags on, for example, paper documents signed for more complex authentication and tracking. Doping (ie, intentionally introducing an "invisible" type substance along with a "visible" type substance) or "invisible" type (eg fluorescent type) to mark with ) Can be realized by selectively distributing the elements and particles.

In some cases, the combination of "invisible" and "visible" markings to form a unique code (UC) is such that "invisible" markings are "visible" markings. It can be defined as being in the form of a colloid that is believed to be suspended in. Such suspended solids have solid or liquid particulates (here, particles that form "invisible" markings) dispersed in a fluid or liquid (here, substances that form "visible" markings). Can be defined as a thing. In some cases, such a combination can be further defined by buoyancy supporting the particles forming the "invisible" marking.

Granting a UC, at least through some SD embodiment, performs the authentication process, perhaps the initial stage of authentication to determine that the person operating the signing device (SD) is a legitimate user (AU) of the SD. May need that.

Such authentication can be done via biometrics, for example, via fingerprint authentication of the person operating the SD. This authentication can be integrated into a signature device (SD) embodiment via a local scanner, such as a fingerprint scanner in the case of fingerprint authentication, or a device close to the SD, such as a wired or wireless connection (such as Bluetooth). It may be done via a mobile device that probably communicates with the SD via.

Perhaps authenticating the user operating the signing device (SD) may be done by requiring the legitimate user (AU) to enter a password, such as an alphanumeric code. At least in certain embodiments, the legitimate user (AU) may be required to perform biometrics first and, if this fails, perform one or more possible additional biometrics. In some cases, if such initial biometric authentication fails, the user may be instructed to attempt additional authentication by other means / methods, such as entering an alphanumeric code. The biometric methods of various embodiments of the present invention may include at least one of voice analysis, vocal cord or iris analysis, face analysis (etc.).

In certain embodiments, various biological (eg, fingerprint) sensors such as optical sensors, capacitive sensors, thermal sensors, pressure sensors, ultrasonic and RF sensors may be used within the signing device (SD). In certain embodiments, biofeedback (skin electrical resistance, thermometer) is probably incorporated into a biometric (eg, fingerprint) detection device to analyze the physiological or mental state of the user signing a particular document at a given time point. , Heart rate) may be used as the authentication method.

In some cases, the legitimate user (AU) may be in a different location than the signature device (SD) associated with the AU is actually located. Such different locations may be physically different locations and / or different possible remote areas, such as different workplaces, cities, countries, and the like. In such cases, the remote authentication process may be performed first, and the actual "signing" (ie, physically granting the UC) may be performed by someone else who assists the legitimate user (AU). Good.

Such a remote "signature" process is authentic with a UC remotely assigned prior to the formation of the URL where the data associated with the "signed" document is located / uploaded. It may include providing the AU with a scan or image of a "signed" document (by a UC) to ensure that it is and / or is legitimate.

In some cases, the signing method according to at least certain embodiments of the present invention may include the collection of information in the first step. This information can be used in a later step to generate a unique code (UC). Such collected information may include the user's ID, date, location, and various bit information probably collected from the mobile device of a legitimate user (AU) using, for example, the signing device (SD). ..

Such information that is believed to be collected may be obtained wirelessly (eg via a Bluetooth connection), GPS location information, WIFI information, WIFI location information, carrier information, carrier location information, IMEI, email. (And similar to these) can be included. In one embodiment, information may be collected by a signing device (SD) and / or stored by means such as a microprocessor and / or memory contained in the SD.

In one embodiment, the generation of a unique code (UC) (eg, an electronically signed UC) is as if all, or at least a portion of, all of the information collected to generate the UC is ". It may include applying features such as "mixing" or "utilizing". Such a unique code (UC) may be an electronic UC, eg, a digital UC if compiled to include an image of a signed document (or part thereof). It is possible that there is. Also, such unique code may be configured to include a URL link to the location where the data associated with the UC is located or uploaded. The unique code (UC) may in some cases be linked to a URL formed from at least a portion of the information from which the UC was formed. Further, the URL may be randomly formed.

In a non-binding example, the unique code (UC) integrates the number representing the current date (eg, apply the integration function to the number 091017 representing the date October 9, 2017), and then For example, it may be formed by multiplying the result by a user ID (etc.) to generate a unique code (UC) representing the obtained result. Other techniques for secure information / communication, such as cryptography and / or cryptographic hash functions, may be used to form at least some unique code (UC) of the present invention. For example, as a method for forming a UC, a method including at least one of Rabin cryptosystem, SHA-256 algorithm, SHA-512 hash function, and the like may be used. Once a unique code (UC) is formed, a legitimate user (AU) uses the unique code (UC) to configure a so-called "signature" event (EV) that grants a UC to a document by a signing device (SD). You may.

At least one embodiment of the signing method of the present invention applies a similar unique code (UC) multiple times (eg, by stamping / printing / signing) to the same document (eg, to some area or page of the document). It may include the execution of a signature event (EV), including doing or granting to multiple documents related to each other (eg, multiple contracts related to similar legal matters).

Perhaps such a similar UC used multiple times in a signature event (EV) may have a single URL where the data associated with the UC is stored. A signature event (EV) may also include assigning a unique code (UC) only once (eg, by stamping), eg, stamping a UC once on a single page.

In certain aspects of the invention, information about one or more signature events (EVs) may be temporarily stored in embodiments of the signature device (SD) used to apply the EV. Therefore, such a signature event (EV) may each contain data / information collected to generate a unique code (UC), where the UC stores the data associated with the EV and UC. It may be used with the URL to be used.

At least in certain embodiments, the data / information of one or more signature events (EVs) may be temporarily stored on the SD when the signing device (SD) performing the EV is in "offline" mode. Then, when a secure connection is established between the signing device (SD) and the web, such data / information may be uploaded to the URL associated with the EV.

Each actual link may be generated in the cloud (perhaps on a dedicated server) when the connection is established (or shortly thereafter). A URL link (eg https://lynx.io/W5h67r) can be formed for each of the EVs stored on the SD. The EV information associated with this link may be uploaded to the currently existing URL during or after the URL / link is generated.

In one embodiment, the remote "signature" process may include the following steps: A user in the location of the document sends an image of the page to "sign" the document to a remote legitimate user (AU) for remote approval / signing. The legitimate user (AU) may then authenticate himself via biometric means (eg, a fingerprint scanner) if the document is verified and approved. The process involving this authentication can probably be performed via computational means such as a dedicated mobile application running on a mobile device, such as a legitimate user (AU) mobile device.

Such computing means may then send confirmations to the local user and the signature device (SD) owned by the local user via secure communication. Here, a unique code (UC) and URL may be formed for the stamping process (eg EV) to be performed.

In one embodiment, the unique code (UC) is a variety of other forms, such as a matrix barcode, eg, a QR code (in particular, the aspects described herein are not limited to QR codes). Can be realized with. The content of the message contained in such a QR code type UC may be further hashed by forming a hash result such as e18f415ae8fef102d57e69d6d316d59ef6d30e85. The hashed result may be communicated with the public key to form a digital signature.

Encryption of the message content may include applying Zip imaging to the message content. In addition to message hash value and Zip image of message, signer ID, date, location, information from Bluetooth connected phone (GPS location information, WIFI information, WIFI information, carrier information, carrier location information, IMEI , Email address) and other additional information may be collected.

In one embodiment, information such as a URL formed on the server (eg https://lynx.io/W5h67r) or encryption such as "follow the following steps to read the message ..." A unique code (UC) of QR code type may be established in consideration of the message that has not been converted.

The QR encoding process, at least in certain embodiments, may be performed in consideration of the message and the hash function. For example, a digitally signed unique code (UC) may be generated, taking into account the hash result e18f415ae8fef102d57e69d6d316d59ef6d30e85 along with the private key.

For hard-copy documents that are identified as authentic by a unique code (UC), the OCR feature may be applied to extract text and numbers from the document (commas, for better OCR results). Dots, and other small symbols can be ignored). After the OCR is successful and the letters and numbers are extracted (upper or lower commas, dots, and other small symbols are probably removed), a hash function is applied along with the private key to generate a digital UC signature. You may continue with the next step, such as.

In certain embodiments of the invention, the user may manually authenticate the message. This can be done when there is a suspicion of fraud and other processing, such as automated processing, does not provide the certainty required for the authenticity of the signed document.

A legitimate user (AU) who wants to verify that the previous signed document is authentic (eg, has not been tampered with) by using dedicated software, for example, should select the "Authentication" or "Suspicious" option. Can be instructed. If you select "Suspicious", a document that checks whether the legitimate user (AU) or anyone associated with the AU may have been tampered with, such as adding "commas" or Arabic numerals. A signed document and / or content associated with its UC, such as a zip image or scan of the UC, may be provided. In particular, adding information such as "commas" will generate different hash values, which can lead to errors in the authentication process.

In the case of a unique QR code (UC), if the message in such a QR code is zipped into a QR code, the zip image may be extracted, decompressed, and the message displayed. ..

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, if there is a suspicion of fraud, the soft copy may be stored in the URL associated with the EV. If the first signed document has already been uploaded to that URL by the user or automatically, it may be possible to switch to a soft copy of the previously signed document.

Authentication of signed documents (for example, legal contracts) that are suspected of being tampered with with respect to soft copies of documents stored on the Web can be performed as follows.

In the first possible step, you may perform OCR on the suspected document to obtain a hash function based on the OCR. It may then automatically display and match the hashes of both messages, one for the currently suspected document and one for the soft copy stored on the server. By comparison, a percentage of matching score can be provided, perhaps displaying inconsistencies / mismatches, for example by highlighting them in red. The user may also be required to check the inconsistencies / inconsistencies one by one and confirm or mark the highlighted differences as invalid. Then, in the final possible step, the authentication summary and results may be displayed.

In a further example (perhaps combined with or independent of the previous example), information may be extracted from the signature to verify its validity. In the first step, a stamped unique code (UC) can be scanned and recognized, for example a QR code type UC can be scanned by a QR code scanner. In one example, a link pointing to a web server / cloud that has access to the information associated with the UC under certain restrictions may be extracted from the scan.

If more information is encoded in the UC, such as a QR coded UC, additional references may be extracted. UCs such as QR codes include user information, URLs (eg https://lynx.io/W5h67r), unencrypted messages (eg "follow the following steps to read the message ..." ), Document hash value, zip imaged message, public key, digital signature (and similar).

In some cases, two or more methods for verifying the authenticity of a signed document may be applied at once.

In addition to the exemplary embodiments and embodiments described above, further embodiments and embodiments will be revealed by reference to the drawings and by reviewing the following detailed description.

An exemplary embodiment is shown in the referenced drawings. The embodiments and drawings disclosed herein are intended to be considered descriptive rather than limiting. However, the present invention can be best understood by referring to the following detailed description, along with the accompanying drawings, with respect to both the organization and the method of operation, along with their purposes, features and effects.

FIG. 1A schematically illustrates an embodiment of a signature device (SD) of the invention placed in a stamped / signed state on a surface such as the cover of a paper document, signed by various methods of the invention. It is a thing.

FIG. 1B is a signature device that is substantially the same as the signature device of FIG. 1A, and schematically shows an embodiment of the signature device that has been removed from the surface, and is printed / stamped on the surface or adhered to the surface. It represents a possible type of unique code (UC) as it is.

2A and 2B schematically show an upward perspective view and a downward perspective view of an embodiment of a signature device (SD) substantially the same as the signature device of FIG. 1.

FIG. 3 schematically illustrates a step considered to be included in an embodiment of the method of the present invention, probably using a signature device (SD) that is substantially the same as the signature device of FIGS. 1 and 2, by SD. It shows the formation of the URL associated with the given unique code (UC).

FIG. 4 schematically illustrates a series of operations believed to be performed to form a unique code according to at least certain embodiments of the present invention.

5A-5E schematically show a unique code (UC) according to at least certain embodiments of the invention and / or data or information associated with such a UC.

FIG. 6 schematically illustrates a step considered to be included in an embodiment of the method of the invention, i.e., a so-called remote approval of a signature operation performed by at least an embodiment of a signing device of the present invention.

7A-7D schematically show flowcharts useful for understanding various embodiments of the present invention.

It is understandable that the elements shown in the figure are not always drawn to scale for the sake of brevity and comprehension. For example, the dimensions of some elements may be exaggerated relative to others for ease of understanding. In addition, reference numbers may be repeated in the figure to indicate similar elements, where appropriate.

Detailed explanation

First, focus on FIGS. 1A and 1B showing embodiments of the signature device (SD) 10 of the present invention. In one aspect of the invention, the signing device (SD) 10 can be used to sign a physical document such as the illustrated document 12. Here, a signature device (SD) in the form of a "rubber stamp" is illustrated as forming / imprinting a unique code (UC) 14 on a document.

Further note are FIGS. 2A and 2B, respectively, showing an upper and lower perspective views of one possible embodiment of the signature device (SD) 10. The SD10 in this example includes an authentication device 16 configured to detect the biometric characteristics of the user attempting to operate the SD, a biometric authentication device considered here.

In this example, the authentication device 16 can be a fingerprint authentication device. A user who is considering signing a document using the illustrated signing device (SD) is used for authentication on the authentication device 16 in order to be recognized as a user in the first initial step. You may be instructed / requested to place your finger. In other embodiments (not shown), the authentication device may be configured to identify other types of biological features such as voice, retina, iris (or similar). ..

In the illustrated example, the signature device (SD) 10 is shown as including the imprinting means 140 at its bottom. The stamping means 140 is configured to form a unique code (UC) 14 on the document to be signed. The imprinting means 140 in this example includes a plurality of markers (five markers in this example) 141-145.

The markers in this example are on protrusions 170 that are configured to form markings (marking of relatively short line segments in this example) when SD is used to form a unique code (UC). It has a form that inclines downward toward it. In one example, at least one signature device (SD) embodiment, for example, in this selective example, soaks the ink and then inks the protrusions of the marker, which is then copied onto the surface on which the SD is pressed. By imparting UC, it may be configured to form a "visible" type of marking under normal conditions (eg, normal "natural light" conditions).

Some signature device (SD) embodiments are "invisible" under normal conditions (eg, normal "natural light" conditions) in place of or in addition to "visible" type markings. It may be configured to form a unique code (such as UC14 or UC100) that forms a type of marking. Such "invisible" type markings can be formed, for example, using light emission by using fluorescent material, and when combined with "visible" type markings, for example, doping or It can be placed inside a "visible" type of marking by a selective distribution (or something similar). The combination of "invisible" and "visible" markings can be defined as a colloidal form in which the "invisible" markings are probably suspended throughout the "visible" markings. ..

Refocusing on FIG. 1B, the short marking 17 in the unique code (UC) 14 can be formed by means that are generally similar to the protrusions of the imprinting means 140.

In various embodiments of the invention, at least certain SD embodiments may include a local camera scanner (not shown). By incorporating this scanner into the SD, the SD becomes more autonomous, independent of external camera / scanner devices such as smartphones, and can be highly secure. This camera / scanner can be used to scan a document before and / or after signature, for example for authentication that can be discussed herein.

A signature device (SD), such as device 10, may be configured for operation by one or more legitimate users (AU), at least in certain embodiments. Authentication that the user attempting to operate the SD is a legitimate user may include the authentication process 200 shown in FIG. 7A.

The next step 203 to generate a unique code (UC) imprinted by the SD by positive authentication that the user operating the signing device (SD) is a legitimate user, as made in initial step 201. Step 202 may be initiated to gather information that may be used later in. The authentication performed in step 201 may be performed by the user placing a finger on the authentication device 16.

Such information includes the ID number, date, location associated with the authentic user (AU) being authenticated, and, for example, additional information that can be collected from the mobile terminal of the authentic user (AU) being authenticated. obtain.

In one embodiment, it represents at least some of the information collected about AU in generating a unique code (UC) stamped by a signing device (SD) while being used by a legitimate user. Shapes / structures for UC may be obtained. For example, a function that produces some "score" that can be represented by the shape / structure of the UC may be applied to all, or most, or at least a portion of the information collected.

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

In addition to generating the unique code (UC), step 205 may form a unique URL in which information related to the UC can be stored. This URL can be assigned by a server that communicates with and / or collaborates with the signing device (SD), or by the signing device (SD) itself (eg, by a processor running on the SD).

The various signature device (SD) embodiments (not shown) may have different mechanical or other forms and are different from those shown in FIGS. 1B and 2B in step 204. It may be configured to form a unique shape / form code (UC). For example, at least certain signature device (SD) embodiments may be configured to form various types of unique codes (UC), such as QR codes.

For example, the portable signing device (SD) in at least certain embodiments of the present invention is, for example, a code (which can be a QR code) generating means for assigning / stamping a unique code (UC) on a signed document. For example, a printing means such as an inkjet printer) may be provided. When assigning a UC on a surface to be signed in this way, the SD may be first placed on the surface and then the SD may be dragged laterally along the surface to assign the UC.

At least certain signature device (SD) embodiments may be configured for "offline" operation where communication with an external environment such as the Internet may not be present. Such signature device (SD) embodiments can be used to perform one or more signature operations during such an "offline" period. Each signing behavior relates to, for example, at least one of different legitimate users (AUs), different times when signatures are made, and different (or similar) signed documents. In some cases, it can be characterized as a separate signature event (EV).

In some embodiments, information related to different signature events (EVs) is stored on the signing device (SD) and stored on the signing device (SD) until external communication is possible and / or resumption of external communication. Can be uploaded to a dedicated server, perhaps configured to work with a signing device (SD).

Note FIG. 3, which shows the process of such an upload process from signing device (SD) 10 to server 20, perhaps a cloud server. Different signature events (EVs) can be stored at a dedicated URL. Here, the dedicated URLs are as URLs (1) to (n) for n signing events (EVs) stored on the signing device (SD) after being executed during that "offline" period. Be marked.

Note FIG. 4, which shows one possible example of generating a unique code (UC) stamped / stamped by at least one embodiment of the signing device (SD). Starting from the top of this figure, a possible first step 101 of collecting information to be considered in the formation of a unique code (UC) is illustrated.

In this optional example, the information collected is probably entered by the current date (November 6, 2017 in this example), the personal ID of the user trying to use the SD, and the user operating the SD. Includes a number representing the signing event (EV) that is about to take place, and the SD serial number (and similar) used.

In the next step 102, this information may be communicated to a "generator" 32 configured to form an "output" 34 using the values of the input information. The generator 32 may implement various techniques for secure information / communication to form output 34, such as cryptographic techniques and / or cryptographic hash functions (and the like). For example, the techniques that can be performed by "Generator" 32 may include at least one of Rabin cryptosystem, SHA-256 algorithm, SHA-512 hash function (and similar). A key such as a private key may be utilized / used during the process of generating a unique code (UC).

The output 34 in this example contains a "message" consisting of a plurality of "tags" including numbers and letters here. The content embedded within the "message" (eg, the group and / or combination of "tags" within the "message") is SD in, for example, the signing event (EV) (EV 00013 in this example) that is about to take place. Can be used to determine the unique code (UC) used by.

The example shown shows that a "message" forms multiple numbers (five values in this example). In this example, these values are shown as X1 through X5. Each of the values X1 to X5 may be normalized to fall within a predetermined range, and in this example, it falls within the range between "0" and "315" as needed. Converting the "message" of output 34 from the value X1 to X5 is indicated on the right side of "output" 34 by double-headed arrows, and each value of X1 to X5 corresponds to each of the above predetermined ranges. It is shown in the position to do.

At least in certain embodiments, the signing device (SD) 10 may be configured to set the relative positions of its markers 141 to 145 depending on the values of X1 to X5. For example, the value of X1 sets the position of marker 141, the value of X2 sets the position of marker 142, the value of X3 sets the position of marker 143, the value of X4 sets the position of marker 144, and so on. The position of the marker 145 may be set according to the value of X5. The markers that reach each position may then be used in the signing operation to form a unique code (UC) by the signing device (SD).

Along with the steps of UC formation described above, the illustrated optional example of the process for obtaining UC14 may be more suitable for organizations where essential internal control techniques for distributing UC may be required. Represents. In a non-binding example, such a type of UC may be considered preferred for organizations such as government agencies (eg customs) where internal standards for signature authentication can be enforced.

More open types of UC may include, for example, QR code type UC. Focusing on FIGS. 5A and 5D, a unique code (UC) 100 of such a QR code type produces such a UC in at least some embodiments of the invention (FIGS. 5A and 5B), UC. Described with a series of possible steps that can be taken to read the information embedded within (Fig. 5C and Fig. 5D).

In FIG. 5A, a first step 1001 of forming "encrypted data" is shown, which in this example (eg, an application running on a legitimate user's mobile device). Includes obtaining the "OCR data" of a portion of the document's signed document (using) and then forming the "encrypted data" using the "private key". Step 1001 may be performed at least partially on a dedicated application (APP) running on a legitimate user (AU) mobile terminal (or something similar).

In a possible second step 1002, an example of data embedded within a UC, such as the UC100, may be shown. The first set of data 36 embedded in the UC100 can be formed by ZIP-imaging the "encrypted data" generated in the previous step. In this example, the "public key" that can be used to open the ZIP imaged "encrypted message" may be embedded in the UC100 as data 38. Further possible information that may be embedded in the UC are "messages" and "links".

The "message" may be, for example, an explanation of how to access the data in the UC100 (such as going to ... and downloading the "APP"). A "link" can be to a location on a dedicated server where the data associated with the UC can be stored. In certain embodiments, steps 1001 and 1002 may be performed automatically by a dedicated APP after imaging at least a portion of the signed document. As a result, the UC (for example, UC100) to be stamped on the signed document is output.

In certain embodiments, steps 1001 and 1002 can be performed in various forms. For example, it may run in a cloud-based application, then communicate with, for example, an SD for signing, or run locally on an SD configured to imprint a UC. Conceivable.

Note Figure 5C and Figure 5D, which show possible processes for reading data embedded within a UC, such as the UC100. In the first possible step 1003, the data embedded in the UC100 to obtain the encoded data can be identified. In this example, this data is shown as binary data containing 0s and 1s. In this example, the APP used to read the UC100 may identify some of the data, such as the data within regions 40 and 42 of the UC. Some of this data is, for example, a message explaining where to download a dedicated APP to read the UC and a link to a location where the data associated with the UC can be stored.

The existence of a public key embedded in region 38 can also be identified. Further, for example, the text included in the area 40 may teach the user how to decrypt the encrypted data embedded in the area 36. In certain embodiments, access to the public key to assist in reading the UC100 may only be granted after "login" with the link provided in the data within region 42.

Thus, the unique code (UC) 100 can contain coded data that can be embedded in different regions within different regions. In the examples illustrated in FIGS. 5B and 5C, for simplicity, such different regions are shown as separate adjacent rectangular regions, but the information is contained within a unique code such as the UC100. The embedding may be done throughout the UC, such as within the interspersed parts / regions of the UC (etc.).

According to at least some embodiments, links (URLs) to locations where UC-related data / information can be stored may be categorized as "freely accessible" or "access restricted". Focusing on Figure 5C, such categories are shown, and so-called "freely accessible" links (URLs) require passwords etc. (as shown on the left side of this figure). Instead, you can allow the display of information (possibly public information) there. A so-called "restricted access" link (as shown on the right side of this figure) may require the user to reach this link for an "entry" action. This "entry" action may include performing a login process and creating an account (if there is no existing account for the user who reached such a link). After an "entry", the user may gain full or partial access to the information in the link, or may be denied access.

Further focusing on FIG. 7B, a flowchart showing a possible step of decoding / acquiring the information in the UC100 is shown. In the first possible step 301, a known QR code reader or scanner can be used to read the UC100. At least a portion of the information embedded in the UC100 (as shown in connection with FIG. 5) can be read at least by a known QR code scanner and is therefore configured to be revealed in step 302. obtain. Such information may include area 42, which defines the URL where the data associated with the UC100 can be stored.

Additional information that can be read by a known scanner and that could be revealed in step 303 may therefore be embedded, for example, within region 40, and embedded within unique code (UC) 100. It may include an indication (eg, a message) about where to download a dedicated QR code reader that can read additional information. If unreadable, this information may remain undisclosed or unintelligible. For example, the message could be something like "Download ... to read the complete code". As mentioned earlier, the region of the UC, such as region 40, does not necessarily have to be the rectangular shape shown, and may spread around the UC (or similar). It may be something like that).

Therefore, area 36 may include a ZIP image of the authentic content of the document (or part thereof) originally signed by UC100. Further, in a certain area, a hash of a document or a hash of a part of a document may be embedded. In at least some cases, the ZIP and / or hash may be formed by scanning the document to be signed before assigning the unique code (UC) 100 to the document.

"Invisible" markings are used (under normal conditions, such as "natural light" conditions) to form at least a portion of the unique code (UC) on an "original" signed document. In certain embodiments, scanning of such "original" documents may be adjusted to substantially ignore (eg, not obtain) such "invisible" markings. This can facilitate, for example, avoiding such markings from interfering with and / or causing interference with the content of the "original" document.

In some cases, scanning of a unique code (UC) that is an "invisible" type of marking (eg, fluorescent ink) and / or a unique code (UC) that includes such a marking is used in the UC. It may be done by a scanner configured to acquire such "invisible" material.

In some cases, a user or person who wants to validate a UC-signed document known to have originally contained "invisible" markings will see "invisible" material. Such a UC may be visually inspected under appropriate lighting conditions designed as such. The absence of such "invisible" markings can imply the possibility of forging UC and / or the content of documents bearing such UC.

The ZIP image of the original signed document to provide access to this document in step 304 is decompressed using a dedicated QR code reader and / or dedicated application, probably downloaded from the URL revealed in area 42. obtain. Such a dedicated application can be a mobile application running on a mobile terminal. The hash of the original signed document may also be revealed by a dedicated application / reader in step 305.

By viewing or accessing the actual document originally signed by the UC100, a means of comparing the contents of the current document with the UC100 with the original document originally signed may be provided. Such a comparison makes it possible to prove that the originally signed document has not been altered or tampered with between its original signature and the current inspection.

In one embodiment, in initial step 306, the current document is scanned and scanned, perhaps to make a comparison 308 between the hash of the currently inspected document and the hash made to the original signed document. A comparison may be made between the original signed document and the currently inspected signed document by applying the OCR to the OCR and then applying the hash function to the OCRed scan in step 307.

If the hashes do not match, the authenticity of the current document can be questioned. For example, the original signed document could be a legal contract referring to a total of $ 1 million. Tampering with a document after it was first signed may involve changing this total to indicate $ 10 million. Therefore, this change in amount, which is the basis of the contract discussed, may be apparent by comparing the hash value of the current document with the hash value of the original document.

In some cases, the hash embedded in one of the UC100 areas may be across the document, but the ZIP image of the signed document embedded in the UC100 area 36 is the signed document. It may contain only a part of. For example, a signed document may contain 10 pages, and forming a ZIP image containing all these 10 pages of information and embedding it in area 36 of a standard size QR code type UC is within area 36. May not be practical due to insufficient space to accommodate such large volumes of ZIP-compressed information. On the other hand, a 10-page hash is essentially a "one line" of information that can be easily placed within one area of a standard size QR code.

At least one embodiment of the present invention enhances the credibility of the inspection document signed by the UC by the dual security provided by the ZIP image and hash. For example, if you use only hashes, on the other hand, some information in the document is tampered with (for example, changing $ 1 million to $ 10 million) and then another part of the document is changed to tamper with the original. Obtaining a hash that looks similar to a hash of a non-document (possibly by trial and error) can lead to document fraud.

It can be considered as a step that can be taken after trying to match the "original" content with a given UC (as described above) with the "current" content with such a given UC. Note Figure 7D, which illustrates the steps. By automatically comparing / authenticating between the "original" content and the "current" content, for example, these contents may be positively matched, or between these contents, for example, the "original" content. This leads to the ability to identify discrepancies between the content hash and the "current" content hash.

If such automatic validation / authentication fails (as indicated by "NO" at the top of Figure 7D), the user attempting such validation will cause such negative results. You may be instructed to manually check for any discrepancies. The user may have an "original" content and an authenticated "current" content, and in this optional example, both contents may be displayed on separate screens. The user may then be directed to a discrepancy in the content to manually check for a discrepancy between the two content.

During such an inspection, if the user determines that the identified discrepancy is incorrect (eg, due to an error in the OCR made to the content) and is a "fake alarm". The user may choose to correct / ignore this discrepancy until all the discrepancies that caused the failure in the previous automatic authentication are checked (the "next" rectangle marked in Figure 7D). It may be induced to further possible discrepancies (as indicated by).

If all discrepancies are found to be "fake alarms", such a manual check can be a positive manual authentication that can ignore the previous negative result made during the automated process. On the other hand, if the manual validation process yields the same negative results as previously performed, double validation (first automatic validation and subsequent manual validation) will result in "current" inspection. Can be more reliably determined that is not authentic. A genuine "original" copy of the content may be stored, for example, at a URL associated with the UC.

Note FIG. 6, which schematically illustrates the use of embodiment 10 of at least one signature device (SD) in remote signature processing. At the same time, FIG. 7C, which is of interest, provides a flowchart showing the steps that can be taken during such remote signing. In such a remote signature process, the legitimate user 30 may be far from where the signing device (SD) is actually located, and remote authentication and remote authentication to authorize the execution of the signature by the SD. Confirmation processing can be performed.

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

A remote user can, in step 403, read the document and verify the document for remote signing, perhaps by imprinting his fingerprint on a fingerprint scanner running by the application. This could result in sending a secure confirmation 404 to the local user where the signed document resides. In the next step 405, the signature of the document 120 may be done by a local user who assists the legitimate user 30 at a remote location to approve the signature.

In the specification of the present application and the claims, the verbs "prepare", "include", and "have" and the words having the same etymology have the object of the verb as a component of the subject of the verb, respectively. It is used to indicate that it is not necessarily a complete list of components, elements, or parts.

Further, although the present invention or the present technology has been illustrated and described in detail in the drawings and the description so far, such illustrations and descriptions are descriptive or exemplary and are non-limiting. You should think that there is. Therefore, the present technology is not limited to the disclosed embodiments. A person skilled in the art can understand and realize a modified example of the disclosed embodiment, and implement the technique described in the claims from the examination of the drawings, the present technology, and the attached claims. can do.

In the claims, the word "preparation" does not exclude other elements or steps, and indefinite articles such as "a" and "an" do not exclude the plural. A single processor or other unit may provide the functionality of multiple items described in the claims. The fact that certain means are described in different dependent claims does not indicate that the combination of these means cannot be used in an advantageous manner.

In addition, the present technology is used when terms, features, numerical values or numerical ranges are described in relation to terms such as "about", "approximately", "substantially", "generally", and "at least". Is understood to include the term, feature, numerical value or numerical range itself. In other words, "about 3" shall also include "3", and "substantially vertical" shall also include "vertical". No reference code in the claims should be construed as limiting its scope.

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 (37)

A signing device (SD) for signing a document, the SD for assigning a unique code (UC) on the document, the UC to a URL associated with the UC. A signing device (SD) that is logically associated with the data / information that is located. The document is the signature device (SD) of claim 1, which is a physical paper document. The signature device (SD) of claim 2, which is a portable device. The unique code (UC) is the signature device (SD) of claim 3, which is an electronic signature that is probably guaranteed or enforced by a digital signature. The signature device (SD) of claim 4, wherein the URL points to a document and / or information located on a cloud-based web page. The signature device (SD) of claim 5, which restricts access to at least a portion of the data / information at the URL. Granting the unique code (UC) is generally the signing device (SD) of claim 6 by the stamping and / or encoding operations applied to the document. The signature device (SD) of claim 1, configured to allow the formation of a unique code (UC) only to the legitimate user (AU) of the SD. The signature device (SD) of claim 8 configured to perform an authentication process that determines that the person handling the SD is the legitimate user (AU) of the SD. The signature device (SD) of claim 9, wherein the authentication process is a biometric authentication process. The signature device (SD) of claim 10, wherein the biometric process is at least one of voice analysis, retina or iris analysis, face analysis, fingerprint. The signature device (SD) of claim 11, wherein the authentication process takes place on a device that communicates with the SD. The signature device (SD) of claim 11 where the authentication process is performed on the SD. The signature device (SD) of claim 11 in which the legitimate user (AU) is located at a location different from the SD. The signature device (SD) of claim 1, which imparts at least a portion of the unique code (UC) on the document utilizes visible markings under normal conditions, such as normal natural light conditions. .. Granting at least a portion of the unique code (UC) on the document makes use of invisible markings under normal conditions, such as normal natural light conditions, the signing device of claim 1 (SD). ). How to sign a document
Steps to prepare a signing device (SD),
A step of assigning a unique code (UC) on the document using the SD,
A method having a step of forming a URL in which data / information logically associated with the UC is located. 17 of claim 17, wherein the unique code (UC) comprises a step of collecting information, comprising at least a portion of the collected information and / or including at least a portion of the collected information. Method. The method of claim 18, wherein assigning the unique code (UC) is performed only by the authorized user (AU) of the SD. The collected information is at least one of GPS location information, WIFI information, WIFI location information, carrier information, carrier location information, IMEI, email of the AU and / or email of a device associated with the AU. The method of claim 19. The method of claim 20, wherein the collected information is stored by the signing device (SD) in a microprocessor and / or memory contained in the SD. The method of claim 21, wherein the unique code (UC) comprises information consisting of at least a portion of the document to be signed. 22. The method of claim 22, wherein the information consisting of at least a portion of the document is a ZIP image of at least a portion of the document and / or a hash of at least a portion of the document. The method of claim 23, wherein the unique code (UC) is formed by a cryptographic technique and / or a cryptographic hash function. The method of claim 17, wherein the URL is randomly formed. The signature device (SD) is configured to be used in different signature events (EVs), and at each signature event (EV) the SD can form one or more unique codes (UC). The method of claim 17, all unique codes (UCs) in an EV are the same. The unique code (UC) of the different signature event (EV) is different, claim 26. The method of claim 27, where each signature event (EV) has one URL. 17. The method of claim 17, wherein information about the operation of the signature device (SD) is configured to be used in an offline operation mode in which information is stored locally on the SD. The SD is configured to be used in an online operating mode in which it communicates with an external device / means, and at least a portion of the information stored in the SD during the offline operating mode is during the online operating mode. 29. The method of claim 29, configured to be uploaded to said external device / said external means. 30. The method of claim 30, wherein the external device / said external means comprises the Internet. 17. The method of claim 17, configured to perform remote signature processing by a legitimate user (AU) of the SD at a location distant from where the SD is located. The method of claim 32, wherein the remote signing process comprises transmitting at least one image of the document to be signed to the legitimate user (AU). 33. The method of claim 33, wherein the remote signature process comprises authenticating the legitimate user (AU), perhaps by biometric authentication. The method of claim 34, wherein the authentication is performed on dedicated software associated with the SD. The method of claim 17, wherein giving at least a portion of the unique code (UC) on the document utilizes visible markings under normal conditions, such as normal natural light conditions. The method of claim 17, wherein assigning at least a portion of the unique code (UC) on the document utilizes invisible markings under normal conditions, such as normal natural light conditions.

Images