阅读说明：本技术 签名方法、系统和/或装置 (Signature method, system and/or device ) 是由 E·沙可德 N·波利斯特斯基 于 2019-01-20 设计创作，主要内容包括：用于对文件进行签名的签名装置和/或方法。该签名装置用于在文件上应用唯一代码,并且该唯一代码在逻辑上关联到位于关联到唯一代码的URL中的数据/信息。(A signing device and/or method for signing a file. The signing device is used to apply a unique code on the file and the unique code is logically linked to the data/information located in the URL associated to the unique code.)

1. A Signing Device (SD) for signing a file, said SD being adapted to apply a Unique Code (UC) on said file, and said UC being logically linked to data/information located in a URL, said URL being linked to said UC.

2. The Signing Device (SD) of claim 1, wherein said document is a physical paper document.

3. The Signing Device (SD) of claim 2, being a hand-held device.

4. Signing Device (SD) according to claim 3, wherein said Unique Code (UC) is an electronic signature that can be further protected or implemented by a digital signature.

5. Signature Device (SD) according to claim 4, wherein said URL points to a file and/or information located on a cloud-based web page.

6. The Signing Device (SD) of claim 5, wherein access to at least some of the data/information in the URL is restricted.

7. Signature Device (SD) according to claim 6, wherein the application of said Unique Code (UC) is generally carried out by an embossing and/or coding action applied to said document.

8. The Signing Device (SD) according to claim 1, configured to allow the formation of a Unique Code (UC) only to Authorized Users (AU) of the SD.

9. The Signing Device (SD) of claim 8, configured to perform an identification process to determine that the person handling the SD is the Authorized User (AU) of the SD.

10. The Signing Device (SD) of claim 9, wherein said identification process is a biometric identification process.

11. The Signing Device (SD) of claim 10, wherein said biometric identification process is at least one of: voice analysis, retinal or iris analysis, facial analysis, fingerprints.

12. The Signing Device (SD) of claim 11, wherein said identification process is performed on a device in communication with said SD.

13. The Signing Device (SD) of claim 11, wherein said identification process is performed on said SD.

14. Signature Device (SD) according to claim 11, wherein said Authorized User (AU) is located in a different location than said SD.

15. Signing Device (SD) according to claim 1, wherein said application of at least part of said Unique Code (UC) on said file makes use of visible markings under normal conditions, for example normal daylight conditions.

16. Signing Device (SD) according to claim 1, wherein said application of at least part of said Unique Code (UC) on said file makes use of invisible markings under normal conditions, such as normal daylight conditions.

17. A method of signing a document, the method comprising the steps of:

providing a Signature Device (SD);

applying a Unique Code (UC) on the file using the SD; and

forming a URL where data/information logically associated to said UC is located.

18. The method according to claim 17, comprising a step of collecting information, and said Unique Code (UC) is constituted by and/or comprises at least some of the collected information.

19. The method of claim 18, wherein the Unique Code (UC) is applied only by Authorized Users (AU) of the SD.

20. The method of claim 19, wherein the collected information is at least one of: GPS position, WIFI position, carrier position, IMEI, email of the AU and/or of a device associated to the AU.

21. The method according to claim 20, wherein the collected information is stored by the Signing Device (SD) on a microprocessor and/or a memory comprised in the SD.

22. The method of claim 21, wherein the Unique Code (UC) comprises information of at least a portion of the file being signed.

23. The method of claim 22, wherein the information of the at least a portion of the file is a compressed image of the at least a portion of the file and/or a hash of the at least a portion of the file.

24. The method according to claim 23, wherein said Unique Code (UC) is formed by cryptographic techniques and/or cryptographic hash functions.

25. The method of claim 17, wherein the URL is randomly formed.

26. Method according to claim 17, wherein the Signing Device (SD) is configured for different signing Events (EV) and in each signing Event (EV) the SD can form one or more Unique Codes (UC) and all Unique Codes (UC) of a certain EV are identical.

27. The method of claim 26, wherein the Unique Codes (UC) of different signed Events (EV) are different.

28. The method of claim 27, wherein each signed Event (EV) has one URL.

29. The method according to claim 17, said method being configured for use in an offline mode of operation, in which information relating to the operation of said Signing Device (SD) is stored locally on said SD.

30. The method of claim 29, configured for use also in a line mode of operation in which the SD includes communications with external devices/appliances, and at least some of the information stored on the SD during its off-line mode of operation is configured to be uploaded to the external devices/appliances during the line mode of operation.

31. The method of claim 30, wherein the external device/appliance comprises the internet.

32. The method of claim 17, configured for use in a remote signature process by an Authorized User (AU) of the SD located remotely from where the SD is located.

33. The method of claim 32, wherein the remote signing process comprises sending at least one image of the file to be signed to the Authorised User (AU).

34. The method of claim 33, wherein the remote signature process comprises enabling identification of the Authorized User (AU) by biometric identification.

35. The method of claim 34, wherein the identifying is performed on dedicated software associated with the SD.

36. The method according to claim 17, wherein the application of at least a portion of said Unique Code (UC) on said file makes use of visible markings under normal conditions, such as normal daylight conditions.

37. The method according to claim 17, wherein the application of at least a portion of said Unique Code (UC) on said file makes use of invisible marks under normal conditions, such as normal daylight conditions.

Technical Field

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

Background

Electronic signatures are used to sign different types of files and are a typical example of data in electronic form that is logically associated with other data in electronic form; to authenticate such documents in a manner that may have the same legal status as a handwritten signature.

Digital signatures are another example of a scheme for authenticating, for example, documents, using encryption/decryption techniques on which electronic signatures are built to give a recipient of such documents certainty of their authenticity. Digital signatures may be used to perform electronic signatures, but not all electronic signatures use digital signatures.

There are several common methods of forging documents and signatures, resulting in the production of fake documents, alteration of existing documents, or the unauthorized production of signatures. Signing documents such as paper documents may be vulnerable to fraud, for example by filling out fake documents on top of a real signature, or simply pasting a copied signature on a document such as a legal contract. Fraud of this nature may result in a fraudulent document being considered authentic when it has an authentic signature, whereas for example the paper above the signature may be blank at the time of signature, or may for example initially include other text that may have been erased or removed.

US20060265590 describes a hard copy authentication file as a physical representation of a digital signature or of a public key attached to a hard copy file or physical object. The method comprises the following steps: the physical manifestation of the digital signature is attached to the hardcopy document and converted to an electronic digital signature that is compared to the public key to authenticate the hardcopy document.

Disclosure of Invention

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools, and methods, which are meant to be exemplary and illustrative, not limiting in scope.

At least some aspects of the present invention relate to providing access to a server, for example, via a uniform resource locator link (URL); wherein data may be stored in such a server that is logically associated with a file signed by at least some Signing Device (SD) embodiments and/or signing methods of the present invention.

In some embodiments, the signature of the file may be formed by using a Signing Device (SD), possibly a handheld SD, which may create a Unique Code (UC) in the form of an electronic signature, which may further be protected or enforced by a digital signature. A Unique Code (UC) according to at least some embodiments of the present invention may be applied on a document (possibly a paper document); and the data stored and/or uploaded to the URL in question may be logically associated to a Unique Code (UC).

In some cases, such a URL may be formed after the UC assigned to the file via the Signing Device (SD) has been analyzed, and the URL may be provided to the user for browsing stored data associated with the UC. In an embodiment, the URL may point to a file and/or information located on a cloud-based web page.

Access to the data/information in the URL may in some cases require login access permissions, and in some cases such data may be considered public or have at least some information public. In one non-limiting example, the public information may include: name, date, location of signer, e-mail, phone call of signer (etc.). In an example, some information may remain private, such as the phone number of the signer, the personal ID, the signed file itself (and so on). In some cases, some information may be user-limited, such as the workplace division where the signing activity takes place, the role of the authorized signer in the company, the office location (and so forth).

In some cases, a URL pointing to restricted files/information may require a login/check-in; and at least some information relating to the "signed" file may be revealed after the user gains access. The presented information may be relevant to the user accessing the data and may e.g. be determined from his unique details such as his e-mail (etc.).

In embodiments of the invention, the application of the Unique Code (UC) via the Signing Device (SD) may generally be achieved by performing an embossing and/or encoding action applied to the signed document.

At least some Signing Device (SD) embodiments may be arranged to form a Unique Code (UC) that is "visible" under normal conditions (e.g. normal "daylight" conditions including a combination of direct and indirect sunlight during the day). For example, such visible UC may be formed by applying a Unique Code (UC) on a document using a pigmented liquid and/or slurry (e.g., ink).

At least some Signing Device (SD) embodiments may be arranged to form a Unique Code (UC) that is "invisible" under normal conditions (e.g. normal "daylight" conditions). Such "invisible" UC may be formed, for example, by luminescence, for example, by using a fluorescent substance.

In some embodiments, the "invisible" mark may be used in conjunction with the "visible" mark to form a Unique Code (UC) that is used to assist in further avoiding counterfeiting of the UC performed by the SD, thereby preventing the formation of counterfeit files (or reducing the likelihood).

This combination of "invisible" and "visible" indicia may be achieved by at least one of the following: doping (i.e. deliberately introducing "invisible" type substances as well as "visible" type substances) or selective distribution of "invisible" type elements or particles (e.g. of the fluorescent type) in order to mark a signed, e.g. paper-based document with "invisible" and permanent labels for more sophisticated identification and tracking.

In some cases, the combination of "invisible" and "visible" marks used to form the Unique Code (UC) may be defined in the form of a colloid, wherein the "invisible" marks may be suspended throughout the "visible" marks, wherein such suspension may be defined as the dispersion of fine solid or liquid particles (here, particles forming the "invisible" marks) in a fluid or liquid (here, substances forming the "visible" marks). In some cases, such a combination may also be defined by particles that form "invisible" marks from buoyant supports.

Applying UC via at least some SD implementations may require performing an identification process (possibly a preliminary identification phase) to determine that the person manipulating the Signature Device (SD) is an Authorized User (AU) of the SD.

Such identification may be performed via biometric identification, such as via fingerprint identification of the person manipulating the SD. The identification may be performed via a local scanner (e.g., a fingerprint scanner in the case of fingerprint identification), which may be integrated into an implementation of the Signing Device (SD), or the identification may be performed via a device in proximity to the SD (e.g., a mobile device that communicates with the SD, possibly via a wired or wireless connection, such as bluetooth, etc.).

Possibly, the identification of the user manipulating the Signature Device (SD) can be performed by requiring an Authorized User (AU) to enter a password, such as an alphanumeric code. In at least some embodiments, an Authorized User (AU) may initially be required to undergo biometric identification with one or more possible additional biometric identification attempts if a previous attempt fails; and in some cases, if such initial biometric attempts fail, the user may be guided through additional identification attempts by other means/methods, such as entering an alphanumeric code. The biometric identification method of various embodiments of the present invention may include at least one of: voice analysis, retinal or iris analysis, facial analysis (etc.).

In some embodiments, various biometric (e.g., fingerprint) sensors may be used in a Signature Device (SD), such as: optical sensors, capacitive sensors, thermal sensors, pressure sensors, ultrasonic and RF sensors, and the like. In some embodiments, biofeedback (skin resistance, thermometer, heart rate), possibly integrated with biometric (e.g., fingerprint) detection means, may also be used as a method of identification in order to analyze the physiological or psychological state of the user signing a particular document at a given time.

In some cases, an Authorized User (AU) may be located at a location different from where a Signature Device (SD) associated with the AU is actually located. Such different locations may be physically different locations and/or different areas that may be remote, e.g., different offices, cities, countries (etc.). In this case, the remote identification process may be performed initially, while the actual "signature" (i.e. physically applying UC) may be performed by another person assisting the Authorized User (AU).

Such a remote "signature" process may include providing a scan or image of the performed "signed" file (signed by the UC) to the AU in order to provide confirmation of the authenticity and/or validity of the UC of the remote application before forming the URL at/to which data associated with the "signed" file may be located/uploaded.

In some cases, a signing method according to at least some embodiments of the present invention may include, in an initial step, gathering information that may be used in a later step to create a Unique Code (UC). Such collected information may include: the ID of the user, the date, the location and possibly various bits of information collected using the Signature Device (SD) from the mobile device, e.g. the Authorized User (AU).

Such possible collected information may be obtained wirelessly (e.g., via a bluetooth connection) and may include: GPS location, WIFI location, carrier location, IMEI, email (etc.). In an embodiment, the information may be collected and/or stored by a Signature Device (SD), for example, via a device such as a microprocessor and/or memory included in the SD.

In an embodiment, generation of a Unique Code (UC) (e.g., electronically signed UC) may include applying a function as if all, most, or at least some of the collected information were "mixed" or "utilized" in order to create the UC. Such a Unique Code (UC) may be of the electronic type UC and, if compiled for example as an image comprising for example a signature file (or a part thereof), also of the digital type UC. Such unique code may also be configured to include a URL link to which data associated with UC may be located/uploaded. The Unique Code (UC) may be linked to a URL that is in some cases formed from at least some of the information that forms the UC. The URL may also be formed randomly.

In a non-limiting example, the Unique Code (UC) may be formed by: the number representing the current date is squared (e.g., a squaring function is applied to the number 091017 representing the date 2017, 10, 9, etc.), and the result is then multiplied by the user's ID (etc.), for example, to create a Unique Code (UC) representing the result reached. Other techniques for securing information/communications, such as cryptographic techniques and/or cryptographic hash functions, may be used to form at least some of the Unique Code (UC) of the present invention. For example, techniques may be used to form UC that includes at least one of: rabin cryptosystem, SHA-256 algorithm, SHA-512 hash function, etc. Once formed, the Unique Code (UC) can be used by the Authorized User (AU) to form a so-called "signature" Event (EV) for the application of UC on the document by the Signing Device (SD).

At least some signature method embodiments of the present invention may include the steps of: a signature Event (EV) is performed that includes multiple applications (e.g., by imprinting/printing/signing) of a similar specific Unique Code (UC) on the same document (e.g., in certain areas or pages of the document) or to several documents related to each other (e.g., several contracts related to similar legal events), and so on.

Possibly, such a similar UC, used multiple times in a signed Event (EV), may be provided with a single URL in which the data associated to the UC is stored. Signing an Event (EV) may also include applying (e.g. by stamping) a specific Unique Code (UC) only once, e.g. stamping UC once on a single page.

In one aspect of the invention, in an embodiment of a Signing Device (SD) for applying one or more signing Events (EVs), information relating to the one or more signing events EV may be temporarily stored. Thus, each such signature Event (EV) may include data/information collected to create a Unique Code (UC) that is used at the EV and the URL where data associated with the UC is to be stored.

In at least some embodiments, when a Signing Device (SD) executing one or more signing Events (EVs) is in an "offline" mode, the EV's data/information may be temporarily stored on the SD. Once a secure connection between the Signing Device (SD) and the network is formed, uploading of such data/information to the corresponding URL associated to the EV may be performed.

At the time (or later) the connection is established, the corresponding actual link may be created in the cloud (possibly on a dedicated server). For each EV stored on the SD, a URL link may be formed (e.g., https:// lynx. io/W5h67 r); and upon or after the URL/link is formed, information for the EV associated with the link may be uploaded to the now-existing URL.

In an embodiment, a remote "sign on" process may include the following steps. A user located locally to the presence of the document sends the image of the document page to be "signed" to an Authorised User (AU) located at a remote location for remote approval/signing. The Authorized User (AU) can then review the file and, if approved, identify himself via a biometric device (e.g., a fingerprint scanner). This process including identification may be performed via a computing device, such as a dedicated mobile application running on a mobile device (e.g., an Authorized User (AU) mobile device).

Such a computing device may then send, via secure communication, a confirmation to the local user and to a Signing Device (SD) owned by the local user, in which confirmation the Unique Code (UC) and URL may be formed for use in performing the imprinting process (e.g., EV).

In embodiments, 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 a QR code alone). The content of a message contained in such a QR code type UC may be further hashed by forming, for example, a hash result such as: el8f415ae8fefl02d57e69d6d316d59ef6d30e 85; and the hash result may be transmitted with the public key to form a digital signature.

Message content encryption may include applying compression (Zip) to the message content. In addition to message hash values and compression of messages; additional information may be collected, such as: signer ID, date, location, information from bluetooth connected phones (GPS location, WIFI location, carrier location, IMEI, email).

In an embodiment, a Unique Code (UC) of the QR code type may be established taking into account URLs such as those formed on servers (e.g., https:// lynx. io/W5h67r) and unencrypted messages such as "read messages follow these steps:.

The QR code in at least some embodiments may be formed in consideration of the message and the hash function. For example, the hash result (el8f415ae8fefl02d57e69d6d316d59ef6d30e85) may be considered along with the private key to create a digitally signed Unique Code (UC).

Where the hardcopy document is authenticated by a Unique Code (UC), OCR functions may be applied to extract text and numbers from the document (while commas, dots, and other small symbols may be ignored for better OCR results). After successful completion of OCR and extraction of letters and numbers (possibly removing upper or lower commas, dots, and other small symbols), subsequent steps may be performed, such as applying a hash function with the private key, to create a digital UC signature.

In some embodiments of the invention, the user may perform manual authentication of the message, which may be performed in the event of suspected fraud, and where other processes, such as automated processes, do not provide the required certainty of the authenticity of the signed document.

For example, an Authorized User (AU) who wants to confirm that a previous signature file is authentic (e.g., has not been tampered with), e.g., by using a proprietary software suite, may be guided to select a "verify" or "suspect" option. If the latter is selected, the Authorized User (AU) or an entity associated to the AU may be provided with content associated to the signature file and/or its UC, such as compression or scanning of the file, wherein it is checked whether tampering with the file, such as adding a "comma", a number, etc., may have occurred. Notably, the addition of information such as "commas" may result in the creation of different hash values, which leads to errors in the authentication process.

In the case of a QR code type Unique Code (UC) in which a message contained in such a QR code is compressed into the QR code, the compression may be extracted and decompressed to display the message.

In some cases, the soft copy may be stored in a network, for example, on a dedicated server that stores data/information related to the EV. For example, the soft copy may be stored at a URL associated to an EV for which suspected fraud may have occurred. In the case where the original signature file has been uploaded to its URL by the user or automatically, a soft copy of the previous signature file may be passed to.

Authentication of a suspect tampered signed file (e.g., a legal contract) in connection with a soft copy of a file stored on a network may be performed as follows.

In a possible first step, OCR of the suspect file may be performed and an OCR-based hash function may be derived. The hashes of the two messages (of the now suspect file and the softcopy stored in the server) may then be displayed and matched, possibly automatically. The comparison may provide and display a percentage match score, which may show the inconsistencies/differences, for example, by highlighting them in red. It may also be required to request that the inconsistency/discrepancy be checked on a case-by-case basis to confirm or mark the respective highlighted discrepancy as invalid. And in a last possible step, a summary of the authentication and the result may be displayed.

In another example (possibly in combination with or independent of the former), information may be extracted from the signature to confirm validity. In a first step, an embossed Unique Code (UC) may be scanned and identified, e.g. QR code type UC may be scanned by a QR code scanner. In one example, a link to a WEB server/cloud may be extracted from the scan where information associated to UC may be accessed according to any available restrictions.

In case more information is encoded into UC, such as QR code type UC, further queries may be performed. UC, such as QR code, may contain user information, URL (e.g., https:// lynx. io/W5h67r), unencrypted message (e.g., "read message follows these steps:."), file hash value, compressed message, public key, digital signature (etc.).

In some cases, more than one method for complying with the authenticity of a signature document may be applied at a time.

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 description.

Drawings

Exemplary embodiments are illustrated in referenced figures of the drawings. It is intended that the embodiments and figures disclosed herein are to be considered illustrative rather than restrictive. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

FIG. 1A schematically illustrates an embodiment of a Signing Device (SD) of the present invention, the SD being placed in an embossed/signed state on a surface to be signed according to various methods of the present invention, such as the face of a paper document;

FIG. 1B schematically illustrates a signing device embodiment generally similar to that of FIG. 1A, removed from the surface, revealing a specific Unique Code (UC) of the possible type that is printed/embossed on the surface and remains adhered to the surface;

fig. 2A and 2B schematically illustrate perspective top and bottom views, respectively, of an embodiment of a Signature Device (SD) generally similar to that of fig. 1;

fig. 3 schematically shows possible steps included in an embodiment of the method of the invention, which may make use of a signing device substantially similar to the Signing Device (SD) in fig. 1 and 2, and illustrates a possible formation of a URL associated to a Unique Code (UC) applied by the SD.

FIG. 4 schematically illustrates a possible series of actions taken to form a unique code in accordance with at least some embodiments of the present invention;

FIGS. 5A-5E schematically illustrate a Unique Code (UC) and/or data or information associated with the UC, in accordance with at least some embodiments of the present invention;

FIG. 6 schematically illustrates possible steps included in an embodiment of a method of the present invention, or remote approval of a so-called signing action performed by at least some signing device embodiments of the present invention; and

fig. 7A-7D schematically illustrate flow diagrams that may be used to understand various embodiments of the present invention.

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

Detailed Description

Reference is first made to fig. 1A and 1B, which illustrate an embodiment of a Signature Device (SD)10 of the present invention. In one aspect of the invention, a Signing Device (SD)10 may be used to sign physical files, such as the illustrated file 12. Here, a Signature Device (SD) of a "rubber stamp" like structure is exemplified, which SD forms/imprints a Unique Code (UC)14 on a document.

Referring additionally to fig. 2A and 2B, perspective top and bottom views of one possible embodiment of the Signature Device (SD)10 are illustrated, respectively. The SD 10 in this example has a recognizer 16, here a possible biometric recognizer, configured to detect a biometric of a user attempting to manipulate the SD.

In this example, the recognizer 16 may be a fingerprint recognizer. In a first preliminary step, a user interested in signing a file using the illustrated Signing Device (SD) may be directed/asked to place a number for identification purposes on the identifier 16 in order to be identified. In other embodiments (not shown), the recognizer may be configured to recognize other types of biometrics, such as voice, retina, iris (etc.).

In the illustrated example, the Signing Device (SD)10 is shown to include on its underside a stamping device 140 configured to form a Unique Code (UC)14 on the signed document. The stamping device 140 in this example comprises a number of marks (here five marks) 141 and 145.

Each mark in this example has a configuration tapering down to a ridge 170 configured to form a mark, here a relatively short line segment mark, when SD is used to form a Unique Code (UC). In one example, at least some Signature Device (SD) embodiments may be arranged to form indicia of the "visible" type under normal conditions (e.g. normal "daylight" conditions) by, for example, immersion in ink prior to application of UC, in this alternative example, the ridges of the indicia carry ink which is in turn transferred to the surface on which the SD is pressed.

Certain Signature Device (SD) embodiments may be arranged to form a unique code (such as UC14 or UC 100) that forms a type of indicia that is "invisible" under normal conditions (e.g., normal "daylight" conditions), rather than or in addition to a type of indicia that is "visible". Such "invisible" type marks may be formed by luminescence, e.g. by using fluorescent substances, and when combined with "visible" type marks may be arranged within the "visible" type marks by e.g. doping, selective distribution (etc.). The combination of "invisible" and "visible" indicia may be defined as a colloidal form, wherein the "invisible" indicia may be suspended throughout the "visible" indicia.

Referring back to fig. 1B, the short marks 17 in the Unique Code (UC)14 may be formed by means substantially similar to the ridges of the stamping device 140.

In various embodiments of the present invention, at least some SD embodiments may be provided with a local camera-based scanner (not shown) that may be integrated into the SD to make it more autonomous, self-contained, and secure than an external camera/scanner device such as a smartphone. The camera/scanner may be used to scan the document before and/or after the document is signed, for example for authentication purposes, some of which may be discussed herein.

In at least some embodiments, a Signing Device (SD), such as device 10, may be configured to operate with one or more Authorized Users (AUs); and the identification that a user attempting to manipulate the SD is an authorized user may include the identification process 200 shown in fig. 7A.

A positive identification performed in a preliminary step 201, i.e. the user handling the Signing Device (SD) is an authorized user, may trigger step 202, which collects information that may then be used in a subsequent step 203 to create a Unique Code (UC) to be imprinted by the SD. The recognition performed in step 201 may be performed by the user placing his finger on the recognizer 16.

Such information may include: an ID number associated to the identified Authorized User (AU), a date, a location, and possibly additional bits of information collected from the mobile device, e.g., the identified Authorized User (AU).

In an embodiment, the generation of the Unique Code (UC) to be imprinted by the Signing Device (SD) when used by an authorized user may comprise deriving a shape/structure of the UC, which shape/structure represents at least some of the collected AU information. For example, a function may be applied to all, most, or at least some of the collected information, which results in a particular "score" that may be represented by the shape/structure of the UC.

In the example shown, in a further step 204, the resulting shape/structure of the Unique Code (UC) may be formed by changing the position of the tokens 141 and 145 in order to form a so-called "token combination" representing the calculated "score". In this example, the Signing Device (SD) may comprise one or more internal actuators (not shown) for changing the position of the marks in order to form the desired structure of the Unique Code (UC).

In addition to forming a Unique Code (UC), in step 205, a unique URL may be formed in which information relating to the UC may be stored. The URL may be assigned by a server in communication and/or cooperation with the Signing Device (SD), or by the Signing Device (SD) itself (e.g., by a processor running on the SD).

Various Signing Device (SD) embodiments (not shown) may have different mechanical or other forms and may be configured in step 204 to form a different shape/form of Unique Code (UC) than that shown in fig. 1B and 2B. For example, at least some Signing Device (SD) embodiments may be configured to form various types of Unique Codes (UC), such as QR code types.

For example, the hand-held Signing Device (SD) of at least some embodiments of the present invention may implement a code (possibly QR code) generating device (e.g. a printing device such as an inkjet printer) for applying/imprinting a Unique Code (UC) on, for example, a document to be signed. Such applying UC on the surface to be signed may include first placing the SD on the surface and then dragging the SD sideways along the surface to apply UC.

At least some Signing Device (SD) embodiments may be configured for "offline" operation during which there may be no communication with an external environment such as the internet. During such "offline" extensions, such Signature Device (SD) embodiments may be used to perform one or more signature operations. Individual signature operations may be characterized as distinct signature Events (EVs) if, for example, the individual signature operations relate to at least one of: different Authorized Users (AU), different points in time when signatures occur, different files of signatures (etc.).

In some embodiments, information relating to different signing Events (EV) may be stored on the Signing Device (SD) until such time as external communication is available and/or restored, and thus may be uploaded to a server designed to cooperate with the Signing Device (SD), possibly a dedicated server.

Referring to fig. 3, this figure schematically illustrates such an upload process from the Signing Device (SD)10 to a server 20 (possibly a cloud server) where different signature Events (EV) may each be stored under a dedicated URL, here labelled as URLs (l) to (n) for "n" signature Events (EV) which are executed during their "offline" extension and then stored on the Signing Device (SD).

Referring to fig. 4, this figure illustrates one possible example of generating a Unique Code (UC) to be imprinted/stamped by the Signing Device (SD) of at least some embodiments. Starting from the top side of the figure, a first possible step 101 of collecting information to be considered in forming a Unique Code (UC) is illustrated.

In this alternative example, the collected information includes: current date (here, 11/6/2017); personal ID of the user attempting to use SD; a number representative of a signature Event (EV) to be executed, possibly entered by a user manipulating the SD; and the serial number of the SD being used (etc.).

This information may be passed to a "generator" 32 in a subsequent step 102, which is configured to form an "output" 34 using the input information values. 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 (among others). For example, techniques that may be implemented by the "generator" 32 may include at least one of: rabin cryptosystem, SHA-256 algorithm, SHA-512 hash function (etc.). During such a process of forming the Unique Code (UC), a key, such as a private key, may be utilized/used.

The output 34 in this example comprises a "message" of several "tags", which here comprise numbers and letters, and the content embedded in the "message" (e.g. groups and/or combinations of "tags" in the "message") may be used to determine a Unique Code (UC) to be used by the SD, e.g. in a signature Event (EV) to be executed, here EV 00013.

The illustrated example illustrates the formation of several numerical values (here five such values) from a "message," which are indicated here as X1 through X5. Each of the values X1 through X5 may be normalized to fall within a predetermined range, here optionally a range between "0" and "315". The conversion of the "message" of the output 34 to the values of X1 to X5 is illustrated by the double-headed arrow leading to the right-hand side "output" 34, the values of each of X1 to X5 being illustrated in their respective positions within a predetermined range.

In at least some embodiments, the Signing Device (SD)10 may be configured to advance the relative position of each of its markers 141 through 145 according to values X1 through X5, for example with the following values: x1 affects the position of marker 141; x2 affects the position of marker 142; x3 affects the position of label 143; x4 affects the position of marker 144; and X5 affects the position of marker 145. The Signing Device (SD) may then use the corresponding arrival position of the mark in a signing action to form a Unique Code (UC).

The illustrated alternative example of a process for deriving UC14, along with the steps of its formation discussed, represents a UC type that may be more suitable for organizations that may require a primary internally controlled method for distributing UC. In a non-limiting example, this UC type may be preferred in certain situations in an organization, such as a governmental agency (e.g., customs department), where internal standards for signature authentication may be enforced.

More open type UC types may include, for example, QR code type UC. Referring to fig. 5A and 5D, such a QR code type Unique Code (UC)100 will be discussed, in accordance with at least some embodiments of the present invention, along with a series of possible steps that may be taken to create (fig. 5A and 5B) and read (fig. 5C and 5D) information embedded within such a UC.

In fig. 5A, a first step 1001 of forming "encrypted data" is illustrated, here comprising taking "OCR data" of a signed file of a part of the file (for example using an APP running on a mobile device of an authorized user), and then forming "encrypted data" using a "private key". Step 1001 may be performed at least in part on a dedicated Application (APP) running, for example, on a mobile device (or the like) of an Authorized User (AU).

In a possible second step 1002, an example of data to be embedded within a UC, such as UC100, may be illustrated. The first set of data 36 embedded within the UC100 may be formed by compressing the "encrypted data" created in the previous step. The "public key" that may be used to open the "encrypted message" compressed herein may be embedded as data 38 within the UC 100. Additional possible information that may embed the UC may include "messages" and "links".

This "message" may, for example, explain how to access data within the UC100 (such as go to. The "link" may be to a location on the dedicated server where data associated to the UC may be stored. In some embodiments, steps 1001 and 1002 may be performed automatically by the dedicated APP after imaging at least a portion of the signature file, which results in preparing an output UC (such as UC 100), for example, for printing on the signature file.

In some embodiments, steps 1001, 1002 may be performed in various ways, such as in a cloud-based application, and then transferred to the SD for signing, for example, or possibly also performed locally on the SD designed to stamp UC.

Referring to fig. 5C and 5D, a possible process of reading data embedded within a UC, such as UC100, is illustrated. In a first possible step 1003, the data embedded within the UC100 may be identified to derive encoded data, here illustrated binary data comprising zeros and ones. In this example, the APP used to read the UC100 may identify some data such as data within the regions 40 and 42 of the UC, as a message explaining where to download the dedicated APP used to read the UC and a link to a location where the data associated to the UC may be stored, for example.

The presence of a public key embedded within region 38 may also be identified and, for example, text included within region 40 may guide the user how to decrypt encrypted data embedded within region 36. In some embodiments, access to the public key may be allowed only after performing a "login" at the link provided by the data in the area 42, in order to assist in reading the UC 100.

Thus, the Unique Code (UC)100 may include encoded data within different regions that may be embedded therein. In the examples illustrated in fig. 5B and 5C, such different regions are illustrated as different adjacent rectangular regions for simplicity, however, embedding information in a unique code such as UC100 may be throughout the UC, such as in a scattered region of the UC (or the like).

In accordance with at least some embodiments, links (URLs) in which data/information relating to UC may be stored may be classified as "free access" or "restricted. Referring to fig. 5C, such categories are illustrated, where a so-called "free access" link (URL) may allow the display of information located therein (possibly public information) without the need for any passwords or the like (as illustrated on the left hand side of the figure). A so-called "restricted" link (as illustrated on the right hand side of the figure) may require an "enter" action from the user arriving at the link. This "enter" action may include performing a login process or creating an account (when, for example, no preexisting accounts are available to reach such linked users). After "entering," the user may gain full or partial access to the information within the link, or may deny access.

Referring additionally to fig. 7B, a flow diagram illustrating possible steps for decoding/deriving information within UC100 will be illustrated. In a first possible step 301, a common QR code reader or scanner may be used to read UC 100. At least some of the information embedded within the UC100 (as exemplified with reference to fig. 5) may be configured to be readable by at least some common QR code scanners, and thus may be presented in step 302. Such information may include an area 42 defining a URL in which data associated with UC100 may be stored.

Thus, the additional possible information that may be read by the public scanner and presented in step 303 may be embedded within, for example, the area 40, and may include an indication (such as a message) as to where to download a dedicated QR code reader capable of reading the additional information embedded within the Unique Code (UC)100, which otherwise may remain unexposed or understood. For example, the message may read "hi, read completely the code download. As previously mentioned, the region of UC (such as region 40) may not necessarily be of rectangular form as shown, but may extend to be interspersed around within the UC (or similar structure).

Thus, the region 36 may include a compression of the actual content of the file (or a portion thereof) originally signed by the UC100, and in a certain region, a hash of the file or a hash of a portion of the file may also be embedded. In at least some cases, the compression and/or hash may be formed by scanning the file to be signed before applying the Unique Code (UC)100 to the file.

In embodiments where "invisible" indicia (under normal conditions, e.g., "daylight" conditions) may have been used to form at least a portion of the Unique Code (UC) on the "original" signature file, scanning such "original" file may be arranged to substantially ignore (e.g., not pick up) such "invisible" indicia. This may assist, for example, in avoiding blockage and/or interference of such marks with the content of the "original" file.

In some cases, scanning a Unique Code (UC) that is and/or includes "invisible" type indicia (e.g., fluorescent ink) may be performed by a scanner arranged to pick up such "invisible" material used in the UC.

In some cases, a user or entity wishing to verify a previously signed document with a known UC initially including an "invisible" mark may visually inspect such UC by visual inspection under appropriate lighting conditions designed to invoke the appearance of "invisible" material. The absence of such "invisible" markings may imply a potential for counterfeiting of UC and/or content within a file carrying such UC.

Once a dedicated QR code reader and/or a dedicated application program, possibly downloaded from a URL revealed within the area 42, is used, it is possible to decompress the compression of the original signed file to provide access to the file in step 304. Such a dedicated application may be a mobile application running on a mobile device. The dedicated application/reader may also reveal a hash of the original signature file in step 305.

Viewing or accessing the actual file originally signed by the UC100 may provide a means for comparing between the content of the current file carrying the UC100 and the original file originally signed. Such a comparison may allow verification that the originally signed file has not been altered or tampered with in the time that elapses between its original signature and its current check.

In an embodiment, in an initial step 306, a comparison between the original signed file and the currently checked signed file may be performed by scanning the current file, applying OCR to the scan, and then applying a hash function to the OCR scan in a subsequent step 307, so that a comparison 308 between the hash of the currently checked file and the hash performed on the original signed file may be performed.

If the hashes do not match, a doubt may arise as to the authenticity of the current file. For example, an originally signed file may be a legal contract that states a sum of one million dollars, and tampering with the file since it was originally signed may include changing the sum to the indicated million dollars. Thus, such changes in the value underlying the contract in question may be presented by making a comparison between the hash values of the current and original files.

In some cases, the compression of the signature file embedded in the region 36 of the UC100 may include only a portion of the signature file, while the hash embedded in one of the regions of the UC100 may be performed on the entire contents of the file. For example, a signed file may include ten pages, and it may be impractical to form a compression that includes all of the ten pages of information and embed it in an area 36 of a standard size QR code type UC, since there is not enough space within the area 36 to accommodate the compression of such large information. On the other hand, a hash of ten pages essentially results in a "line" of information that can be easily placed within an area of a standard size QR code.

An aspect of at least some embodiments of the invention improves the certainty of the authenticity of a check document signed by UC due to the dual security provided by compression and hashing. For example, if hashing is used alone, the potential for fraud of a file may arise by tampering with some information in the file on the one hand (such as changing one million to one million) and then changing different portions of the file (possibly through trial and error) to arrive at a resulting hash that appears similar to the hash of the original, untampered file.

Referring to fig. 7D, this figure illustrates possible steps that may be taken after an attempted match (e.g., as those described above) is inferred between "original content" on which a given UC has been imprinted and "current content" carrying such a given UC. Automatic comparison/authentication between such "original" and "current" content may result in, for example, a positive match between the content or identification of a difference between the content, such as identification of a difference between hashes of the "original" and "current" content.

In the case where such automatic verification/authentication fails (indicated by "no" on the upper side of fig. 7D), the user who attempts such verification may be guided to perform manual checking of the difference that leads to such a negative result. In this alternative example, the user may be provided with the "current" content to be authenticated and the "original" content by having both content presented on split screens. The user may then be directed to a non-matching area within the content in order to manually check for discrepancies between the two contents.

If during such inspection the user determines that a certain identified difference is erroneous and thus "false alarm" (e.g. due to an error in OCR on the content), he/she may choose to correct/overwrite this difference and may then be directed to a possible further difference (as indicated by the "next" rectangle marked in fig. 7D) until all differences that lead to a failure in the previous automatic verification are inspected.

If all differences are found to be "false alarms," such manual checks may result in a positive manual authentication, which may then override the previous negative result made during the automated process. On the other hand, if the manual verification process reaches the same previous negative result, then the double verification (automatic first, then manual) may more robustly determine the content of the "current" check as being non-authentic. The true "original" copy of the content may be stored, for example, in a URL associated to UC.

Referring to fig. 6, a diagram schematically illustrates the use of at least some embodiments of a Signing Device (SD)10 in a remote signing process. Fig. 7C, also referred to, provides a flowchart depicting possible steps that may be taken during such remote authentication. In such a remote signing process, the authorized user 30 may be located at a remote location where the Signing Device (SD) is actually located, and may conduct a remote identification and validation process to authorize the signing performed by the SD.

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

Then, in step 403, the remote user can read and validate the file for remote signature by possibly applying his fingerprint to a fingerprint scanner run by the application. This may result in a security confirmation 404 being sent to the local user at the location of the file currently to be signed. In a subsequent step 405, the signing of the file 120 may be performed by a local user assisting the remote authorized user 30 in authorizing the signing.

In the description and claims of this application, each of the verbs "comprise," "include," and "have," and their inflections, are used to indicate that the object of the verb is not necessarily a complete listing of the members, components, elements, or parts of the subject of the verb.

Furthermore, while the application has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; thus, the techniques are not limited to the disclosed embodiments. Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed technology, from a study of the drawings, the disclosure, and the appended claims.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does 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.

The present technology is also to be understood as including such precise terms, features, values, or ranges, etc., if the terms, features, values, or ranges, etc., are referred to herein in conjunction with a term such as "about, close to, substantially, at least," etc. In other words, "about 3" shall also include "3" or "substantially perpendicular" shall also include "perpendicular". Any reference signs in the claims shall not be construed as limiting the scope.

Although the present embodiments have been described to a certain degree of particularity, it should be understood that various alterations and modifications could be made without departing from the scope of the invention as hereinafter claimed.