DOCUMENT AUTHENTICATION SYSTEM

Abstract

A secure document verification system is described, for verifying the authenticity of secure documents' The secure documents each comprise a paper document having a radio frequency tag, e.g. a NFC tag, and a document identification code. The system comprises a database storing data representing a plurality of signed secure documents, wherein each document is signed using a pairing of tag and document identification codes, received in a signing or calibration stage. The system is arranged responsive to receiving a verification request from a remote device, which request contains the tag identification data, to compare the tag identification data with the signed documents, and responsive to a match, to transmit back to the remote device a verification message.

Claims

1. A method comprising: receiving from a contactless radio frequency tag document identification data and tag identification data stored on the contactless radio frequency tag on a document; receiving the document identification data provided on and associated with the document; and transmitting data representing the tag identification data and the document identification data as a linked pair to a remote device.

2. The method of claim 1, wherein the document identification data is fixed on the document, at a spatially separate location from the contactless radio frequency tag.

3. The method of claim 1, wherein the document identification data is provided in visible text or a graphic marking.

4. The method of claim 3, wherein the document identification data is provided in a barcode or a quick response (QR) code.

5. The method of claim 1, wherein the document identification data is received from an image data which represents a captured part of the document.

6. The method of claim 5, wherein the image data is received from an image capture application opened responsive to receiving the tag identification data.

7. The method of claim 1, performed using a mobile communications device having contactless radio frequency ID (RFID) or Near Field Communication (NFC) reading capability.

8. A method of authenticating a document, comprising: storing for at least one document a set of linked validation data that includes a tag identification data associated with a radio frequency tag on the document, and a document identification data provided on and associated with the document; receiving a verification request from a remote communications device, which a verification request includes the tag identification data; comparing the received tag identification data in the verification request with each set of stored validation data; and responsive to identifying a correspondence between the received and stored tag identification data transmitting an authentication message back to the remote communications device.

9. The method of claim 8, wherein the receiving of the verification request further includes identifying a user or device, and determining that the user or device is pre-registered before performing the comparing.

10. The method of claim 8, wherein the receiving of the verification request includes an encoded form of the tag identification data, and further includes decoding the tag identification data before the comparing.

11. The method of claim 10, wherein the encoded form of the tag identification data is decoded using a shared secret with the radio frequency tag.

12. The method of claim 11, wherein the decoded tag identification data changes for each subsequent decoding operation.

13. The method of claim 8, wherein the receiving of the verification request is received as a URL.

14. The method of claim 8, wherein the identifying includes providing to the remote communications device the document identification data, or other data associated the document identification data, which corresponds to the verified tag identification data.

15-31. (canceled)

32. A secure document verification system comprising: a document tagged with an NFC Tag which generates unique information each time it is scanned; a signature application which calibrates the document for future verification through digital signing of the document; a verification application which carries out a verification process for the document; and a web server which serves as a repository for the unique information for all signed documents and which can be queried by the verification application during the verification process to return a valid or invalid message to a user of the application depending on the response of the verification process.

33. The system of claim 32, wherein the document comprises a bank note, bank cheque, educational certificate, diploma, stock certificate, or a document that is commonly forged.

34. The system of claim 32, wherein the NFC tag comprises a NFC chip which provides the necessary data and processing circuitry for operation.

35. The system of claim 34, wherein the NFC chip comprises an antenna coil for receiving RF energy from a reader used to enable and power the chip through magnetic induction.

36. The system of claim 32, wherein the verification application runs on a NFC enabled mobile device.

37. The system of claim 36, wherein the NFC enabled mobile device is associated with reader circuitry and software.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0062] The invention will now be described by way of non-limiting example, with reference to the drawings, in which:

[0063] FIG. 1 shows a document which carries a Near Field Communications (NFC) tag and a separate printed identifier, in accordance with preferred embodiments;

[0064] FIG. 2 is a close-up view of the reverse side of the NFC tag shown in FIG. 1;

[0065] FIG. 3 is a schematic view of the FIG. 2 NFC tag;

[0066] FIG. 4 is a functional diagram of the FIG. 2 NFC tag;

[0067] FIG. 5 is a schematic block diagram showing components of a reader smartphone according to preferred embodiments;

[0068] FIG. 6 is a schematic block diagram showing the document and smartphone in relation to an authentication server according to preferred embodiments;

[0069] FIG. 7 is a flow diagram indicating processing steps performed by one or more software applications in a signing or calibration stage, according preferred embodiments;

[0070] FIGS. 8a-8d show screen shots of a graphical user interface (GUI) presented by the smartphone in different stages of the signing or calibration stage;

[0071] FIG. 9 is a flow diagram indicating processing steps performed by one or more software applications in a verification stage, according to preferred embodiments;

[0072] FIGS. 10a-10e show screen shots of a GUI presented by a smartphone in different stages of the verification stage;

[0073] FIG. 11 is a flow diagram, similar to the FIG. 9 diagram, indicating processing steps performed by one or more software applications in a verification stage, according to a further embodiment;

[0074] FIG. 12 shows a typical paper document with a QR code printed on it and the holographic NFC tag attached to the lower part illustrating how the seal works;

[0075] FIG. 13 is an image showing the signature application landing page;

[0076] FIG. 14 is an image showing the signature application login page;

[0077] FIG. 15 is an image showing the signature application, choosing the signing option;

[0078] FIG. 16 is an image showing the signature application's tag scanning operation page;

[0079] FIG. 17 is an image showing the signature application's barcode scanning operation;

[0080] FIG. 18 is an image showing the signature application's certificate digital signature operation in completion;

[0081] FIG. 19 is an image showing the verification application landing page;

[0082] FIG. 20 is an image showing the verification application login page;

[0083] FIG. 21 is an image showing the verification application's tag scanning operation;

[0084] FIG. 22 is an image showing the verification application's scanning operation in progress;

[0085] FIG. 23 is an image showing the verification application's tag scanning operation (loading document details);

[0086] FIG. 24 is an image showing the verification application's successful page;

[0087] FIG. 25 is an image showing the verification application sending the digitally signed copy;

[0088] FIG. 26 is an image showing the verification application selecting an option to scan QR code/Bar code so as to send a digitally signed certificate to a recipient;

[0089] FIG. 27 is an image showing the verification application sending the digitally signed copy by scanning barcode/QR code;

[0090] FIG. 28 is an image showing the verification application to supply the email of the recipient where digital copy of the certificate is to be sent;

[0091] FIG. 29 is an image showing the verification application verification history;

[0092] FIG. 30 is an image showing the verification application top-up screen;

[0093] FIG. 31 is an image showing the verification application credit top-up screen;

[0094] FIG. 32 is an image showing the verification application menu option;

[0095] FIG. 33 is an image showing the verification application invalid document authentication screen;

[0096] FIG. 34 is an image showing the signature application flowchart showing the process for signing a document;

[0097] FIG. 35 is an image showing the verification application flowchart showing the process for validating the authenticity of a document, which has been earlier calibrated, using the verification application;

[0098] FIG. 36 is an image showing the system activity diagram;

[0099] FIG. 37 is an image showing the automated desktop signing application login screen;

[0100] FIG. 38 is an image showing the automated desktop signing application dashboard;

[0101] FIG. 39 is an image showing a sample digitally signed certificate;

[0102] FIG. 40 shows the sample applied on a medical product;

[0103] FIG. 41 is an image of the process of verifying the authenticity of the medical item; and

[0104] FIG. 42 is an image of the verification application availing a successful scanned Dispirin medical drug (as an example) to the user.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0105] Embodiments herein relate to methods and systems for verifying the authenticity of paper documents. In this context, a paper document is also intended to encompass, in general, planar paper-like documents (e.g. made of cardboard) which usually have information printed on them. Examples include certificates, bank notes, bank cheques and so on.

[0106] In overview, the methods and systems utilise Near Field Communications (NFC) technology. NFC is a set of communications protocols which enable two electronic devices to establish data communications, by bringing them close to one another, typically within about 40 mm or less. NFC protocols are related to radio-frequency ID (RFID) standards. In typical NFC systems, one device is a reader and the other is a card or tag. The card or tag may be passive, i.e. it may have no power source of its own, but receives power through magnetic induction from the reader. NFC standards operate at approximately 13.5 MHz.

[0107] A NFC reader may be a dedicated device, or as is becoming common, may be incorporated within a mobile smartphone. It is for example now possible to make contactless NFC payments through smartphones. One or more dedicated NFC applications or Apps may be provided and/or downloaded to such devices to manage the NFC hardware, protocols and provide appropriate security measures.

[0108] Referring to FIG. 1, a paper document 1 is shown; it is assumed that the document carries some important information, e.g. it is an educational certificate or similar.

[0109] Fixed to one side of the document 1 is a NFC tag 3, provided in the form of a label. For example, the NFC tag 3 may be a so called Trusted Tag provided by HID Global Corporation.

[0110] FIG. 2 shows the NFC tag 3 from the rear side. As will be understood, the NFC tag 3 comprises a NFC chip 5 which provides the necessary data and processing circuitry for operation. An antenna coil or loop 7 surrounds the chip 5 in a spiral pattern and is used for receiving RF energy from a reader used to enable and power the chip through magnetic induction. The antenna coil 7 is also used to transmit data back to the reader responsive to the chip 5 being energised. The remaining part of the label, generally indicated 9, is a self-adhesive surface.

[0111] The NFC tag 3 is affixed to the document 1 using its self-adhesive underside so that the tag's chip 5 and antenna 7 are concealed from view and cannot be easily accessed. This fixing is typically performed by the document's issuer, e.g. an examination board or educational establishment. Subsequent attempted removal of the NFC tag 3 will cause visible damage to the document 1 and/or the tag.

[0112] FIG. 3 is a schematic view of the NFC tag 3 described above and shown in relation to a reader device, which in this case is a NFC enabled smartphone 11 with associated reader circuitry and software/firmware. In other embodiments, other forms of NFC reader device can be employed. In use, when the smartphone 11 is brought close to the NFC tag 3 (with the phone's NFC capability enabled) it will energise the said tag causing it to transmit information back to the phone. The term scanned is typically used to denote when the NFC tag 3 is being energised.

[0113] In overview, the NFC tag 3 is configured, when scanned by the smartphone 11, to generate an identifier which changes each time the said tag is subsequently scanned. This identifier may be termed a Transaction Authorisation Code (TAC) or One Time Password (OTP).

[0114] Referring to FIG. 4, the tag chip 5 receives as input a constant value UID.sub.t 13 which is a pre-assigned unique data string stored in memory. A code generator function 15 is also provided, typically an embedded algorithm for generating TAC/OTP using the constant value UID.sub.t 13. The algorithm 15 may also make use of an incrementing register (as one other input) which changes its value after each scan so that the resulting TAC/OTP changes. The same algorithm and register setup is employed at a remote authentication server so that the TAC/OTP can be verified. The two systems therefore employ a form of shared secret. This makes it virtually impossible for a hacker or forger to achieve authentication of a copied document merely by accessing and copying the UID.sub.t 13. Other related forms of encryption or encoding can be used, where the output from the tag chip 5 will change after each scan.

[0115] The TAC/OTP that is generated by the tag chip 5 may be in the form of a URL or in text format. The URL will comprise the TAC/OTP from which can be derived, at the authentication server end, the UID.sub.t for comparison and therefore authentication purposes.

[0116] Referring back to FIG. 1, a separate form of identifier, referred to as the document identifier or UID.sub.d is provided on the document 1 in the form of a barcode 17. As will be appreciated, the barcode 17 can be used to represent a data string which is decoded using a suitable image scanning application. In some embodiments, other forms of visual marking can be used for the UID.sub.d, such as a QR code, a string of alphanumeric characters or the like, to give some examples.

[0117] The barcode 17 is directly printed on the document 1 at a location spatially separate and distinct from the NFC tag 3. The UID.sub.d is a constant value assigned by the issuing authority.

[0118] Thus, the document 1 comprises two different identifiers: UID.sub.t and UID.sub.d. The first is transmitted in an encoded form (TAC/OTP) as a URL or in text format when the NFC tag 3 is energised, and then changes for subsequent scanning operations. The second is printed on the document 1 in visual form and does not change.

[0119] FIG. 5 shows an example schematic diagram of components of the smartphone 11. The smartphone 11 has a controller 21, a display 23, which may be a touch sensitive display, hardware keys 25, a memory 27, RAM 29, and a NFC interface 31 comprising the hardware, firmware and antenna circuitry appropriate for the NFC protocol. The controller 21 is connected to each of the other components in order to control operation thereof.

[0120] The memory 27 may be a non-volatile memory such as read only memory (ROM) a hard disk drive (HDD) or a solid state drive (SSD). The memory 27 stores, amongst other things, an operating system 33 and one or more software applications 35. The RAM 29 is used by the controller 21 for the temporary storage of data. The operating system 33 may contain code which, when executed by the controller 21 in conjunction with RAM 29, controls operation of each of hardware components of the terminal.

[0121] The controller 21 may take any suitable form. For instance, it may be a microcontroller, plural microcontrollers, a processor, or plural processors.

[0122] Referring to FIG. 6, the document 1 and smartphone 11 are shown in relation to a remote, trusted authentication authority 41. The two ends are connected by a network 40, e.g. the Internet and so the authority can be considered a cloud type system. The authentication authority 41 operates a secure webserver 44 which has access to various databases 46, 47, 48. For example, a first database 46 stores a list of issuers and their details. For example, a second database 47 stores a list of verifiers and their details. For example, a third database 48 stores a list of signed document details.

[0123] The software application 35 may be configured to provide either or both of a calibration application and/or a verification application. For convenience, we indicate two such software applications 35A, 35B. Specifically, a first software application 35A is a calibration application and a second software application 35B is a verification application. The two software applications 35A, 35B may be provided on the same or on different smartphones. In some embodiments, the two software applications 35A, 35B may be combined in a single application with different modes.

[0124] Calibration is the stage whereby the issuer of the document 1, e.g. an examination board, registers the document with the trusted authentication authority 41. It may also be referred to as signing the document 1. Verification is the stage whereby a different party, e.g. an employer wishing to authenticate a presented document, communicates with the authentication authority 41 for a response.

[0125] The calibration process will now be explained with reference to FIGS. 7 and 8.

[0126] FIG. 7 is a flow chart showing the various process stages performed by the calibration application 35A when run on the smartphone 11. FIG. 7 also shows related process stages performed at the authentication server 44. The numbering used on FIG. 7 is not necessarily indicative of the order of the steps. It will also be appreciated that some steps can be interchanged or avoided.

[0127] Initially, in step 7.1 the issuer of the document 1 will open the calibration application 35A on the smartphone 11. The application 35A contains an embedded link for communicating over a TCP/IP network with the authentication server 44, using an encrypted protocol such as SSL.

[0128] If not done already, the issuer will be prompted by the calibration application 35A to register their organisation's details with the authentication server 44 via a secure portal, e.g. by entering a user id, a password and additional contact and address details. This information is then stored on the first database 46. If already registered, the issuer simply enters their user id and password on the login screen, as shown in FIG. 8a.

[0129] In step 7.2 the issuer is prompted to read or scan the NFC tag 3 as shown in FIG. 8b. In step 7.3 it is determined if the NFC tag 3 has been read; if not, the process returns to step 7.2. If the NFC tag 3 is read, in step 7.4 the TAC/OTP is received as a URL or in text format and in step 7.5 is stored in memory of the smartphone 11. The URL may include a pointer to the authentication server 44 as well as the TAC/OTP.

[0130] Responsive to reading and storing the TAC/OTP, in step 7.6 the issuer is prompted automatically to read the UID.sub.d. In this example, this is by means of the application 35A opening an image capture application (associated with the smartphone's in-built camera) configured to detect and decode barcodes to obtain the UID.sub.d. As indicated in FIG. 8c, the issuer scans over the barcode 11 (by aligning the camera over it using the screen) until confirmation is received that the barcode is detected and read in step 7.7.

[0131] The UID.sub.d is stored in step 7.8. In step 7.9 the issuer is prompted to tie or link the UID.sub.t and UID.sub.d together. This pairing of the two identifiers is then transmitted in step 7.10 to the authentication server 44 where they are stored in the third database 48.

[0132] Referring to steps performed by the authentication server 44, in optional stages 7.11 to 7.15 the server may first determine whether or not the UID.sub.t has already been stored in the third database 48, which if so, would indicate an unauthorised calibration attempt which is denied. If the UID.sub.t has not already been received and stored, then a message is sent back to the smartphone 11 prompting the next stage 7.6 of calibration.

[0133] Steps 7.16 and 7.17 indicate the receiving and storing stages of the paired UID.sub.t and UID.sub.d at the authentication server 44. UID.sub.t is decoded from the TAC/OTP using the shared secret method mentioned above.

[0134] FIG. 8d shows the user interface output indicating successful signing of the document 1 to the issuer.

[0135] The verification process will now be explained with reference to FIGS. 9 and 10.

[0136] FIG. 9 is a flow chart showing the various process stages performed by the verification application 35B when run on the smartphone 11, or a different NFC enabled device. FIG. 9 also shows related process stages performed at the authentication server 44. The numbering used on FIG. 9 is not necessarily indicative of the order of the steps. It will also be appreciated that some steps can be interchanged or avoided.

[0137] Initially, in step 9.1 the verifier of the document 1 will open the calibration application 35B on the smartphone 11. The application 35B contains an embedded link for communicating over a TCP/IP network with the authentication server 44, using an encrypted protocol such as SSL.

[0138] If not done already, as shown in FIG. 10a, the verifier will be prompted by the calibration application 35B to register their individual or organisation's details with the authentication server 44 via a secure portal, e.g. by entering a user id, a password and additional contact and address details. This information is then stored on the second database 47. If already registered, the verifier simply enters their user id and password on the login screen, as shown in FIG. 10b.

[0139] In step 9.2 the verifier is prompted to read or scan the NFC tag 3 as shown in FIG. 10c. In step 9.3 it is determined if the NFC tag 3 has been read; if not, the process returns to step 9.2. If the NFC tag 3 is read, in step 9.4 the TAC/OTP is received as a URL or in text format and in step 9.5 is stored in memory of the smartphone 11 and transmitted to the verification server 44.

[0140] At the verification server 44 the TAC/OTP is received and decoded in step 9.8 to provide the UID.sub.t using the above-mentioned shared secret method. In step 9.9 the UID.sub.t is compared with those stored in previous calibration steps, i.e. those stored in the third database 48, to determine whether there is a match, in which case the document 1 is authentic (step 9.10). If there is no correspondence, it is determined that the document 1 is fake (step 9.11). The result may be stored in step 9.12 and, in either case, is transmitted back to the verifier's smartphone 11 for displaying the result in step 9.6.

[0141] FIG. 10d shows a user interface following authentication. FIG. 10e shows a user interface following failed authentication.

[0142] In some embodiments, which is particularly applicable if the document is an educational certificate or the like, in response to an authentication result (step 9.10) additional information based on, or associated with, the UID.sub.d may be presented on the user interface, for example as shown in FIG. 10d. In this regard, the UID.sub.d may point to the name of the document owner, the issuing organisation, the document name and/or the issue or creating date. FIG. 11 shows in overview such a method.

[0143] The above described methods and systems help overcome or minimise the problems associated with document forgery, and one which can be applied in a localised or global manner given the nature of the Internet.

[0144] FIGS. 12 to 42 illustrate another embodiment or additional parts to the previous described embodiment of a system for validating the authenticity of a document and/or products through the use of Near Field Technology. The system comprises a holographic NFC tag (Trusted Tag), a bespoke signature application, a bespoke verification application, an NFC enabled mobile device that runs the signature application and an NFC enabled mobile device that runs the verification application.

[0145] A Paper Document with an NFC Tag

[0146] An NFC tag is attached to a document (for example, a certificate, a letter etc) via a simple adhesion technique.

[0147] Issued documents are coded with a Barcode/QR Code printed on document. The Barcode/QR Code is encoded with the encrypted unique identification number (UID) of the document which, in the example shown in FIG. 12, is a student examination number. Other documents (such as letterheads, medical reports etc.) may only have NFC tags attached. The NFC tag used is a secure tag which, when tapped with an NFC enabled device, generates a Transaction Authorization Code (TAC) or a One-Time Password (OTP) as a URL which provides access to validate the authenticity of the document. The TAC or OTP is a security measure which ensures that the tag cannot be cloned as the device generates a different TAC/OTP every time the tag is tapped on the device.

[0148] Each tag has a unique Identification number (UID) which has been encoded within the tag. The Tag UID is the only constant variable the tag generates every instance it is tapped. Consequently, upon scanning of a tag, a different information (TAC/OTP) is generated every time but the Tag UID is constantly generated. This allows each physical tag to be identifiable by their corresponding UIDs.

[0149] The Signature Application

[0150] The signature application is shown in FIGS. 13 to 18. The application is developed to sign documents for future verification.

[0151] For document security, certification signing involves the tying of the unique document ID with the Tag ID. A unique designation is formed which is then stored on a cloud based database containing information data on that document.

[0152] The signing of documents may alternatively or additionally involve the tying of the document issuer details/ID with the Tag ID.

[0153] Product signing involves the tying of the product details (manufactured date, batch no. etc.) with the Tag ID.

[0154] The process of signing the issued documents and product is initiated with having an NFC enabled mobile device which has the associated the signature application running on it. The document issuer securely logs in to the application on their mobile device with username and password, and selects from the options which type of document they wish to sign. The mobile device is then used to tap the Tag which generates a TAC/OTP inform of a URL that contains the unique ID (UID) of that tag. The UID of the Tag is automatically copied by the application.

[0155] As this process is completed, for certificates for example, the application automatically prompts open the device camera so as to capture and read the Barcode/QR code. The information on the Barcode/QR code which is the UID of the document is copied by the application and automatically tied to the Tag ID previously copied. For other documents/products, the tag ID copied may be automatically tied to the document/product issuer's profile (gathered from information that was provided upon signing-up to system and which will be subsequently provided when such document is verified). These signing processes are repeated for all documents. This process is shown by way of example in FIGS. 13-18.

[0156] Document signing can also be done in batches with the automated signature application as shown by way of example in FIGS. 37 and 38.

[0157] The Verification Application

[0158] The verification application is shown by way of example in FIGS. 19 to 24. This application is developed to read the tag and carry out the verification of paper document authenticity.

[0159] An NFC enabled mobile device is tapped on the tag and the verification application is launched (if previously installed) or downloaded to start verification. The document verifier securely logs in and selects an option to either scan Barcode/QR code (to generate digital copy of certificates) or scan NFC tag (document verification). The verifier is prompted to tap twice on the tag to generate a unique TAC/OTP that is authenticated before the document's specific information is retrieved from the cloud service, the verification application returns a message that states that the document being verified is genuine and authentic, or fake.

[0160] The Web Server

[0161] The tag UIDs and document/product UIDs for all items that are tied using the signature application are stored on a database which is housed on a web server. This system ensures that whenever any tag is scanned and a TAC or an OTP is generated, the URL communicates with the web server to confirm if the tag exists or not. If the tag exists, the tag ID would be present on the database which will return a positive report that the document is genuine since the tag has been tied to a specific information on the database. Therefore, every tag issued can be uniquely identified, hence stopping the problems of duplicating or fabricating a document.

[0162] In another embodiment of the invention, the document/product being verified may be a certificate from an educational institution, a product from a manufacturing company, etc.

[0163] The report which is returned by the application may either be a valid response to confirm to the verifier that the issued document/item is genuine, or an invalid response that confirms to the verifier that the issued document or supplied product is not genuine. In this embodiment, a database which contains the UIDs for all the documents is built with the document in this case, being a certificate. In such a case the UID for the document may be a number that uniquely differentiates it. This may be the examination number of candidate or the matriculation number of such candidate for example.

[0164] For products, the UID of the product could be the serial number of the product or the IMEI number of such product i.e. a number that uniquely identifies the product to its brand.

[0165] After a successful check for the authenticity of the tag by the system, the database is securely queried to retrieve document specific data which is then displayed to the verifier on the verification application. The information displayed may be the candidate name, age, date of birth, date the document was issued, grades and other specific information as required by the issuer in case of issued document.

[0166] This information may alternatively be the name of the product, the manufacturer's information, the NAFDAC number of the product, the manufactured date, the expiry date, and the warrantee status of the product/item to be validated.

[0167] Sending a Digital Copy

[0168] A digital copy of a signed certificate can be sent from the verification application as shown by way of example in FIGS. 24 and 25. This is to enable document verifier to send an adobe digitally signed copy of the verified certificate to an authorized recipient.

[0169] A sample of a digitally signed document is as shown by way of example in FIG. 39. A digital copy of an issued document can also be generated and sent to an authorized recipient by just scanning the unique barcode/QR code of the issued document as shown by way of example in FIG. 27.

[0170] It will be appreciated that the above described embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present application.