WO2012000037A9

WO2012000037A9 - Accessing information

Info

Publication number: WO2012000037A9
Application number: PCT/AU2011/000808
Authority: WO
Inventors: Neil Grusd
Original assignee: Cyberpoint Pty Ltd
Priority date: 2010-07-01
Filing date: 2011-06-29
Publication date: 2012-03-15
Also published as: AU2011101729A4; WO2012000037A1

Abstract

There is disclosed a method of providing access to a customer's information (e.g. document (12)) to party ("requester") (16) that requires that information for a service required by the customer (10). The method includes storing the information on a computer system (20), providing the customer with an authorisation code unique to a particular requester, and receiving a request from that requester for access to the information. The request must include a code and the method includes determining if that code matches the authorisation code. If so, the requester is provided access to the information. The invention further relates to a system for effecting the method, and to a method of accessing such information.

Description

ACCESSING INFORMATION

FIELD OF THE INVENTION This invention relates to the accessing of information such as documents. In particular, it relates to methods and a system for enabling documents to be securely electronically stored in a repository, and accessed when required by authorised people or entities. BACKGROUND TO THE INVENTION

There are many circumstances in which a person is required to provide suitably authenticated documentation to prove the identity of the person or to prove the veracity of information mentioned in such a document.

For example, if a person wishes to open a new bank account, it may be necessary for the person to provide to bank personnel some form of documentary evidence to prove, according to applicable standards, that the person is who he or she claims to be. For example, the document may be a passport or driver's license.

In many instances, the original of the relevant document may be provided, but it is usually necessary for the document to be a suitably verified copy, such as a certified or notarised copy, in order for the document to be regarded as a true copy of the original.

If a person has a need to provide such documentation on a number of occasions, this can give rise to inconvenience, as it may be necessary for the person to obtain numerous suitably authenticated copies of the document in question. This can also give rise to legal fees or expenses if costs are incurred in obtaining suitable authentication from a legal practitioner, Justice of the Peace, etc.

A further problem that may arise in relation to the need to present such documents, is that they can become lost or suitable facilities to safely store such documents may need to be obtained. Alternatively, it may be inconvenient or impracticable to provide such documents in situations where the presenters of the documents are not physically in the presence of the parties to whom the documents are presented, e.g. in online transactions.

It is an object of the present invention to address, or at least ameliorate, one or more of these problems, or to provide a useful alternative. SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a method of providing information of a customer to an information requester, the method including :

1 .1 storing information of the customer on a computer system;

1 .2 providing the customer with a retrieval authorisation code unique to a particular information requester;

1 .3 receiving a request from the particular information requester for access to the information of the customer, the request including a request code;

1 .4 determining if the request code matches said retrieval authorisation code;

1 .5 if the request code matches said retrieval authorisation code, providing access to the information to the particular requester.

In a preferred embodiment, the method includes:

2.1 prior to step 1 .1 , receiving the customer's information from a sender, via electronic transmission;

2.2 receiving, from an authenticator, via electronic transmission, an authentication means declaring that the received information is authenticated;

2.3 ascertaining if the authenticator satisfies at least one predetermined qualification criterion indicating that the authenticator is qualified to authenticate the information ; and 2.4 if the authenticator is ascertained, according to step 2.3, to satisfy the at least one qualification criterion, allocating, on the computer system, an authenticated status to the stored information. Preferably, the sender is said authenticator.

Preferably, in step 2.3, the at least one qualification criterion includes that the authenticator logs in to the computer system using at least one login credential, which corresponds to an authenticator login credential stored on the computer system in relation to that authenticator.

Preferably, in step 2.3, the at least one qualification criterion includes that when logging on to the computer system, the authenticator indicates a location at which the authenticator purports to be located.

In a preferred embodiment, the method includes enabling the customer to select from a plurality of information provision criteria according to which said access to the information is provided to the particular requester in step 1 .5. Preferably, said information provision criteria include at least one of:

said access being provided to the particular requester wherein the requester is pre-registered as a requester;

said access being provided to the requester by email ; and

said access being provided to the requester by sending at least one physical document bearing the information to the requester.

Preferably, said information provision criteria pertain to the number of times that the information may be provided to a said particular requester. Preferably, the method includes allocating a charge depending on the information provision criterion selected by the customer. Preferably, said charge is represented by a plurality of purchasable credits allocated to the customer, the credits being redeemable according to the access provided to the requester according to step 1 .5. Preferably, the method includes receiving payment for said charge by at least one of the customer and a said requester, depending on particular information provision criteria selected by the customer.

In a preferred embodiment, in step 1 .5, the providing of access to the requester is constituted by enabling the requester to view a representation of the information.

In a preferred embodiment, in step 1 .1 , the information of the customer is constituted by a copy of at least one document bearing information.

Preferably, the method includes retrieving, and storing on the computer system, separately from the copy of the at least one document, document information being at least part of the information contained on the at least one document.

Preferably, said retrieving of the document information includes at least one of:

retrieving the document information by receiving it in written form from the customer,

retrieving the document information from a face of the at least one document using optical character recognition (OCR) technology, and

retrieving the document information from an electronic means held on the at least one document. Preferably, said electronic means includes a radio-frequency identification (RFI D) device.

Preferably, the method includes:

1 7.1 transmitting said document information to a document verifier; 1 7.2 receiving a response from the document verifier indicating whether, based on said document information, the at least one document complies with predetermined validity criteria;

1 7.3 if said response indicates that the at least one document complies with the predetermined validity criteria, including an indication on the computer system that the at least one document so complies; and

1 7.4 if said response indicates that the at least one document does not comply with the predetermined validity criteria, including an indication on the computer system that the at least one document does not so comply.

In a preferred embodiment, the method includes, prior to the step 1 .2, receiving a request from the customer for a said retrieval authorisation code.

Preferably, the method includes, prior to the step 1 .2, receiving a request from the customer for a said retrieval authorisation code wherein step 1 .2 includes providing the customer with the retrieval authorisation code only if a predetermined condition is met, said condition including that, in step 17.3, the at least one document so complies. Preferably, said request from the customer includes a feature uniquely associated with said particular information requester.

Preferably, the receiving of the request from the customer includes receiving a short message service (SMS) message from the customer, and said uniquely associated feature includes a telephone number to which the SMS message has been sent.

In a preferred embodiment, in step 1 .2, said providing of the customer with a retrieval authorisation code includes sending the retrieval authorisation code to the customer via at least one of:

SMS message,

Smart phone application,

the Internet, and

a telecommunications connection. Preferably, the step of providing the customer with a retrieval authorisation code includes sending the retrieval authorisation code to the customer via a telecommunications connection in the form of a telephone connection, using Interactive Voice Response (IVR) technology.

In a preferred embodiment, the method includes:

24.1 receiving an activation request from the customer to activate an account of the customer on said computer system;

24.2 determining if the activation request satisfies at least one predetermined account activation criterion;

24.3 if the activation request satisfies said at least one predetermined account activation criterion, activating the account of the customer. Preferably, the method includes storing, on the computer system, a customer activation code pertaining to the customer, wherein in step 24.1 said activation request includes a purported activation code, and wherein in step 24.2, at least one predetermined account activation criterion includes said purported activation code matching said customer activation code.

Preferably, the method includes:

26.1 generating a random activation key parameter;

26.2 electronically transmitting said activation key parameter to the customer at an electronic transmission address that has been provided by the customer;

26.3 receiving from the customer, via electronic transmission, an activation code key;

26.4 determining if the activation code key matches the activation key parameter transmitted to the customer according to step 26.2;

26.5 if the activation code key does not match said activation key parameter, determining according to step 24.2 that said activation request does not satisfy said predetermined account activation criterion. Preferably, if in step 26.4 it is determined that the activation code key matches the activation key parameter transmitted to the customer according to step 26.2, and if said purported activation code matches said customer activation code, then determining in step 24.2 that the activation request satisfies said at least one predetermined account activation criterion.

In a preferred embodiment, the method Includes sending a notification to the customer if access to the information is provided to the particular requester in accordance with step 1.5.

According to a second aspect of the invention, there is provided a system for providing information of a customer to an information requester in accordance the method of the first aspect of the invention or preferred embodiments thereof, the s stem including said computer system.

According to a third aspect of the invention, there is provided a method of accessing information of a customer of an Information repository, wherein the repository provides the information in accordance with the first aspect of the invention or preferred embodiments thereof, the method Including::

30.1 requesting, said information as a said particular requester; and

30.2 receiving the Information from the repository in accordance with the manner in which the information is provided by the repository according to step 1.5.

In this specification, unless the context dearly indicates otherwise, a reference to a document includes a reference to a plurality of documents.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figures 1A to 1D together constitute a diagram showing entities and components used in a method according to an embodiment of the invention; Figure 2A is a flow diagram representing Workflow 1 , which is part of the method to which Figure 1 pertains;

Figure 2B is a flow diagram being a continuation of Workflow 1 of Figure 2A;

Figure 3 is an example of a document authorisation form for use in the method;

Figures 4 to 14 are examples of screen displays forming part of the method steps according to Workflow 1 ;

Figure 15 is a flow diagram representing Workflow 2, which is part of the method to which Figure 1 pertains; Figures 16 to 20 are examples of screen displays forming part of the method steps according to Workflow 2;

Figure 21 is a flow diagram representing Workflow 3, which is part of the method to which Figure 1 pertains;

Figures 22 and 23 are examples of screen displays forming part of the method steps according to Workflow 3;

Figure 24 is a flow diagram representing Workflow 4, which is part of the method to which Figure 1 pertains;

Figure 25 is an example of a bank registration/application form for use in the method; Figure 26 is a flow diagram representing Workflow 5, which is part of the method to which Figure 1 pertains;

Figures 27, 28, 29A, 29B and 30 are examples of screen displays forming part of the method steps according to Workflow 5; and

Figure 31 is an example of a screen display relating to a customer's setting up of an account DETAILED DESCRIPTION

Essentially, this invention, at least in preferred embodiments, provides a way of digitally and electronically storing suitably authenticated information, for instance information embodied as documents, in a central repository. In particular, referring to Figure 1 , the invention provides a means for a person 10 who possesses an original document 12 to easily authorise the provision of a copy 14 of such a document, or access to such a document, to a party 16 that requires such document or access.

For the purpose of describing the invention, it will be assumed that the document which the person 10 wishes to allow the party 1 6 to access is a certified copy 14 of the original document 1 2, and that the nature of authentication of the document is the certification thereof as a certified copy, by a person suitably qualified to do so.

In many jurisdictions, a lawyer or Justice of the Peace would be a person suitably qualified to certify a copy. Accordingly, for the purpose of describing embodiments of the invention, it will be assumed that the qualified person is a Justice of the Peace (JP) 18. However, it is to be understood that this is by way of non-limiting example only, and that the nature of person qualified to authenticate the document in question may depend on the particular circumstances, the type of document in question, the nature of authentication involved, and the law of the particular jurisdiction concerned.

Further according to the present example, the party 16 that requires the access to the document is a company in the form of a bank at which the person 1 0 wishes to open a bank account. Indeed, typically when a person wishes to open an account at a bank, the bank will need to confirm the identity of the person by reference to suitable identification documents or suitably authenticated copies of such documents. Accordingly, for the purpose of the present example, the bank 16 needs to view a certified copy of an identity document of the person such as the person's driver's license or passport. As the person 10 is a potential customer of the bank, the person is referred to below as a customer.

Capture and certification of the customer identification documents

Referring to Figure 2A, there is shown part of a flow diagram, also referred to as Workflow 1 . Workflow 1 illustrates a process by which the customer 10 can have the copy 14 of the original document 1 2 suitably certified by the JP 18, and stored on a computer system 20 of a document management service provider 22, in particular in a database 24 of the computer system. For the purpose of illustration only, the service provider 22 is identified herein as Cybercheck (TM).

In order to have the required copy 14 of the document 12 certified and stored, the customer 10 is required to complete a document authorisation form which is to be presented to the JP 18. A copy of such a form 26 is shown in Figure 3. According to the preferred embodiment, the JP 1 8, before being able to access the computer system 20 of the service provider 22, needs to be registered with the service provider as an authorised J P.

The customer 1 0, after completing the document authorisation form 26 and presenting it to the JP 1 8, as indicated at 50, also presents the JP with the original document 1 2 corresponding to the copy 14 which is to be certified, as indicated at 52.

Once the customer 10 presents the original document 12 to the J P 18, the J P is required to access the computer system 20 of the service provider 22, by entering the JP's login identification code and password on the JP's computer screen display 18.1 . These details can be transmitted via the Internet to the website of the service provider 22 as indicated at 54. An example of such a display is shown in Figure 4. According to the preferred embodiment, such transmission is in encrypted form (e.g. employing SSL (Secure Sockets Layer) technology). Indeed, this is the case, according to the preferred embodiments, for any Internet connection or transmission referred to in this specification, unless the context clearly indicates otherwise.

After entering the login identification and password, the JP's login credentials are transmitted via the Internet to the service provider 22, and a confirmatory response is automatically sent to the computer 18.2 of the JP 1 8 as indicated at 56.

The computer system 20 of the service provider 22 is adapted to determine whether the purported login credentials of the JP 1 8 are legitimate. It achieves this by comparing the purported login credentials with credentials stored in the database 24 on the computer system 20.

If the purported credentials fail to match relevant credentials stored on the database 24, then a suitable notification to this effect is sent via the Internet to the JP 18, as indicated at 58.

If, however, the purported credentials indeed match relevant credentials in the database 24 on the computer system 20, then a message is sent via the Internet, to the JP 18, which is presented as a display on the JP's computer screen 1 8.1 , to require the JP to advise on his or her physical location, as indicated at 60. An example of a computer screen display generated by the service provider's computer 20 for this purpose, is shown in Figure 5.

Once the JP 1 8 has entered details of his or her physical location as indicated at 62, the software on the computer system 20 of the service provider 22 is adapted to initiate a transaction session with the JP, while the location details of the JP are sent to, and stored on, the computer system 20 of the service provider 22, as indicated at 64. As indicated at 66, the computer system 20 is adapted then to generate, via the Internet, a display on the JP's computer screen 18.1 requesting the JP 18 to scan the authorisation form 26 completed by the customer 1 0, as mentioned above. Examples of screen displays relating to the JP 18 carrying out this action is indicated in Figures 6 and 7. Following these instructions, the JP 18 can scan the customer's document authorisation form 26 as indicated at 70, whereupon this information is converted to text, by means of suitable optical character recognition (OCR) software on the computer system 20 of the service provider 22, and buffered in the Internet browser memory on the JP's computer system 1 8.2, and displayed on the screen 18.1 . This step is indicated at 72. As a possible alternative embodiment, the OCR software may be on the JP's computer system 1 8.2.

When this occurs, software is adapted to request the JP 18 to confirm that the information on the customer's document authorisation form 26 was accurately converted to text by the OCR software. An example of such a display on the JP's computer screen 1 8.1 is indicated in Figure 8.

Once the JP 18 has confirmed that the details from the document authorisation form 26, converted to text using the OCR software, are accurate, then by means of a suitable link on the JP's computer display 1 8.1 , the JP can confirm the details. This confirmation is transmitted via the Internet to the service provider's computer system 20, and stored in the database 24 on that system, as indicated at 74.

The next stage in the process is that an instruction, transmitted from the service provider's computer system 20 via the Internet to the JP 18, is presented on the JP's computer screen 18.1 , instructing the JP to scan the original document 12 of the customer 10 (that is, the document of which the customer wishes to obtain a certified copy 14). This step is indicated at 76, while an example of the screen display with such an instruction is indicated in Figure 9.

Thereupon, the JP 18 can scan the original document as indicated at 78, to create a computer file with an image of that document 1 2. That image is buffered in the browser memory of the J P's computer 1 8.2 and displayed on the screen 18.1 , as indicated at 80. In addition, the JP 18 is requested to check the image of the document to ensure that the original 12 has been accurately scanned. An example of such a screen display is shown in Figure 1 0.

According to a preferred embodiment the invention provides for the validating or authenticating of the original document 12 itself. This embodiment involves the engagement of a validation or authentication agency, which may, for example, be a suitably authorised government- or other official body. An example of such an agency is the Australian National Document Validation Service (NDVS). For ease of reference, the type of body or agency in question is referred to below as a National Document Verification Service (DVS).

Relevant information about the document 12 is transmitted from the computer system 20 of the service provider 22 via the internet, to a computer system (not shown) of the DVS, as indicated at 200. This computer system is adapted to then check certain details of the document 12 and to determine whether they are legitimate, as indicated at 202. Thus, the DVS enables real-time verification or authentication of the document 12. This embodiment of the invention is particularly suitable where the document 1 2 is of a significant official nature, such as an identity document.

Authentication or verification that might, for example, be carried out by the DVS may include the following :

· that the document 12 has in fact been issued by the authority or agency appearing on the face of the document;

• that information appearing on the document 1 2 corresponds to relevant information in the records of the authority or agency that issued the document;

· that the document still has a valid status (for example, that it has not been cancelled or superseded) ;

• that the document has not been reported as lost or stolen. When the details of the document 12 are to be sent to the DVS, the computer system 20 encrypts the information and transmits it securely in real-time using Hypertext Transfer Protocol Secure (HTTPS) technology. Examples of types of detail pertaining to the document 1 2 that may be sent include, but are not limited to, the following:

• identity of the document issuing agency;

• document number or other official number appearing on or included with the document;

· expiry date;

• name and details of document holder.

If the DVS determines that, for any reason, any aspect of the document 12 is not valid (for example due to the document not being legitimate, not containing correct information, not being in force or current, etc), then the computer system of the DVS sends a response to this effect to the service provider's computer system 20 via the internet in real-time and the service provider's computer system flags the document as "non-compliant" as indicated at 204.

If the DVS determines that the document 12 is valid then the computer system of the DVS sends a response to this effect to the service provider's computer system 20 via the internet in real-time and the service provider's computer system flags the document as "compliant" as indicated at 206.

Whether the document 12 is flagged as compliant or non-compliant, according to the preferred embodiment, the image of the document 1 2 is then transferred to the computer system 20 of the service provider 22 as encrypted data, for storage in the database 24, as indicated at 82. According to the preferred embodiment, it is also stored in an encrypted format. Indeed, according to preferred embodiments, all information pertaining to the customer 10 stored on the service provider's computer system 22 and database 24, is stored in encrypted form. The JP 1 8 is then prompted to submit, via the Internet, to the service provider 22, a signed declaration to the effect that the scanned document, as presented on the JP's computer screen 1 8.1 , is a true copy of the original document 12, as indicated at 84. An example of such a screen display is shown in Figure 1 1 .

According to the preferred embodiment, the manner in which the JP 18 is required to authenticate the copy 14, is by way of an electronic signature. This is a signature actually signed by the JP 18, on an electronic signature pad to capture an image of the signature, as indicated at 86. Also captured is a file containing biometric information (referred to below as a "biometric file") relating to the characteristics of the signature (for example, pertaining to angles, strokes, pressure, and so on). Such a file can be used to enable authentication, at a later time, of a signature which is purported to be that of the JP 18.

The signature and biometric file are captured and buffered in the browser memory of the JP's computer 18.2 and the signature is displayed on the computer screen 1 8.1 , as indicated at 88. An example of such a screen display is shown in Figure 12. The JP 18 is also prompted to send the signed declaration with the biometric file via the internet by clicking on a suitable link.

The signed declaration is transmitted to the service provider 22 and stored in the database 24 on the computer system 20 as indicated at 89.

Apart from simply storing copies of customers' documents 12, a preferred embodiment of the invention also provides for storing details of the documents, in particular, of the information contained in or on the documents. Such information will be stored in encrypted form.

Such details may be captured by the computer system 20 of the service provider 22 in various ways. The methods of capturing the details may include the following : • The customer 1 0 can enter such details on the document authorisation form 26 mentioned above. When the document authorisation form 26 is scanned as described with reference to Figure 2A at 70, the details of the form entered on the document authorisation form can be captured by OCR, and transmitted via HTTPS to the computer system 20 of the service provider 22.

• The details of the document 1 2 can be captured directly from the face of the document by OCR when the document is scanned as described with reference to Figure 2A at 78.

· The details can be electronically read from the document 1 2 by scanning a bar code on the document where this bar code represents those details, or from a radio-frequency identification (RFID) chip contained in or on the document. The storing of such details by the service provider 22 can enable the service provider to notify the customer 10 when the customer's document 12 is about to expire or cease to be valid, for example when a certain date passes. According to this embodiment, a customer 10 can be notified of such an impending event by email, SMS, written message, or other suitable means.

To give the customer 1 0 an opportunity to renew the document 12, or take other steps to ensure that the document is prevented from expiring or is replaced, the service provider 22 may send such a notification to the customer 10, say, two months before the expiry date, and then send a reminder, say, one month before the expiry.

The document authorisation form 26 includes a document activation reference number 27.1 together with a bar code 27.2 representing that number. This number and bar code are presented on a main portion of the document authorisation form 26 and a strip 26.1 which is removable from a remainder of the form. It will therefore be appreciated that, when the JP 18 scans the document authorisation form 26 and transmits a copy to the service provider 22 as mentioned above, this transmission includes the document activation reference 27.1 number and bar code 27.2.

As will be seen, Workflow 1 continues in Figure 2B. Once the signed declaration is transmitted to the service provider 22, as indicated at 90 the transaction session of the JP 18 is automatically terminated (in other words, the JP is automatically logged out of the service provider's computer system 20), with a message concerning the completion of the transaction being generated by the service provider's computer system for display on the JP's computer screen 1 8.1 . An example of such a screen display is shown in Figure 13.

A record of the completed document certification transaction, as effected by the JP 18, is transmitted to the service provider's computer 20 via the Internet and relevant details of the transaction session are stored on the service provider's database 24, as indicated at 92.

One of the items of information required to be completed by the customer 10 in the document authorisation form 26 is the email address of the customer. The computer system 20 of the service provider 22, after completion of the transaction session, is adapted to send an email to the email address of the customer 10, as indicated at 94. This email contains a hyperlink 95 to a web address (Uniform Resource Locator (URL)). An example of such an email is shown in Figure 14.

Once the customer 1 0 receives the email, the customer can click on the hyperlink 95 which is adapted to establish an Internet connection between the computer 1 0.1 of the customer and the computer system 20 of the service provider 22. This is for initiating a session for allowing the customer 1 0 to complete the activation and setup of the customer's account in relation to the stored document copy 14. This process is illustrated in a flowchart, also referred to as Workflow 2, which is discussed below.

However, still with reference to Workflow 1 (Figure 2B), as mentioned above, the document authorisation form 26 and the removable strip 26.1 include a document activation reference number 27.1 . After the transaction session is terminated as indicated at 90, the JP 18 detaches the strip 26.1 from the remainder of the form 26, and hands it together with the original document 12 back to the customer 10, as indicated at 96.

The detached portion 26.1 of the authorisation form 26 is then retained by the customer 10 as indicated at 98. In addition, the JP 18 is required to post the remainder of the document authorisation form 26, which includes a signature of the customer 1 0, to the service provider 22 as indicated at 100. Once received by the service provider 22, the service provider retains this document 26 as indicated at 102. Activating customer ID documents and accounts set up

As was mentioned above, the customer 10 is required to activate and complete the setup of the account and stored documents, and this is illustrated in Workflow 2, shown in Figure 15.

As indicated at 94 in a Workflow 1 , a document activation email is sent to the customer 10. This email includes a hyperlink (or URL) 95 which is generated by the computer system 20 of the service provider 22. The URL 95, apart from being unique to the customer 10 in that it contains parameters referencing the customer's email address, also includes a further parameter in the form of an activation key. This key is randomly generated by the computer system 20 of the service provider 22.

As indicated at 104, the email is sent to the email address included by the customer 10 on the customer's document authorisation form 26 (completion of the form having been indicated at 50 in workflow 1 of Figure 2A).

When the customer 1 0 receives this email, the customer is able to click on the hyperlink (URL) 95 as indicated at 1 06, and this presents a document activation screen on the customer's computer screen 10.2 as indicated at 108. An example of such a display is shown in Figure 16.

As will be seen, the document activation screen on the customer's display 10.2 prompts the customer 10 to enter the document activation reference number 27.1 , which appears on the detached bottom slip 26.1 of the document authorisation form 26, as described above in relation to step 98 in Workflow 1 (Figure 2B). The customer 10 then enters the document activation reference number 27.1 as indicated at 1 1 0, and this number is automatically transmitted to the service provider 22 via the Internet as indicated at 1 12.

The service provider's computer system 20 is adapted to check whether the document activation reference number entered by the customer 1 0 is a valid number, as indicated at 1 14. In addition the URL 95 in the email sent to the customer corresponds uniquely to the customer's email address and contains the random activation key. Accordingly, when the customer 1 0 clicks on the URL 95, apart from establishing an Internet connection with the service provider 22, this also effectively sends the random activation key to the service provider. The service provider's computer system 20 is adapted to check that the URL 95 accessed by the customer 1 0 is the URL uniquely sent to the customer's email address for the purpose of activating the customer's documents. It is further adapted to check that the random activation key which is transmitted when the customer 1 0 accesses the URL, is the same unique key that was sent to the customer.

These features provide an added measure of security to assist in ensuring that document activation is only possible by the customer 10 to whom the document copy 14 belongs, and prevents someone, who may come to know the bar code 27.2 (or the activation reference number 27.1 represented by that bar code) and email address on a customer's authorisation form 26, from taking over the customer's account or accessing the account in an unauthorised manner. If the document activation reference number entered by the customer 10 is not a valid number, or the document activation reference number is a valid number but the activation key entered does not match the corresponding random activation key stored in the service provider's computer system 20, then a notification to this effect, generated by the service provider's computer system, is displayed on the customer's computer screen 18.2, as indicated at 1 16. If the reference number entered by the customer 10 is a valid number and the activation key transmitted when the customer accesses the URL 95 matches the random activation key stored in the service provider's computer system 20 in relation to that customer, thus verifying that the URL accessed by the customer 1 0 corresponds to the unique URL sent to the customer's email address, then the computer system is adapted to retrieve details of the document 12 from its computer system 20 as indicated at 21 0, and to check whether the document is flagged as "compliant" or "non-compliant" as indicated at 212. It will be recalled that the "compliant" or "non-compliant" status of the document 12 was determined in the process described with reference to Figure 2A, at 200 to 206.

If the document 12 is flagged as "non-compliant", a message to this effect and to the effect that the document cannot be activated (i.e. will not be accessible to the customer 1 0 for any purpose) is presented to the customer 1 0 on the customer's computer display 10.2, as indicated at 214.

If the document 12 is flagged as "compliant", then, as indicated at 1 1 8 and 120, the computer system 20 is adapted to retrieve relevant information about the customer 10 from the database 24 and to display details of this information on the customer's computer display 10.2. The relevant information is information that was entered by the customer 10 on the document authorisation form 26, presented by the customer to the JP 1 8 as indicated at 50, and scanned by the JP, as reflected in workflow 1 (Figure 2A). This provides the customer 10 with the opportunity to confirm the correctness of these details, as indicated at 120. An example of such a display is shown in Figure 17. Once the customer 10 confirms these details, the confirmation is transmitted to the service provider 22 as indicated at 122.

In addition, in one preferred embodiment of the invention, the customer 10 is required to effect payment to the service provider 22 for use of the service provider's services in storing the copies 14 of the customer's documents 12 and presenting these on request to companies that request such details, as described further below. The display of the relevant details on the customer's computer display 1 0.2 provides the opportunity for the customer 1 0 to be called on to make such payment. According to a preferred embodiment, such payment is required to be by credit card or other secure electronic payment means such as Paypal (TM) or BPay (TM).

According to one embodiment, the customer 10 may be able to buy credits which will be held in the service provider's computer system 20 against that customer's account for future redemption. These credits can be used by the customer 10 to provide access to the customer's document copies 14 or to determine the criteria by which such access is provided.

Different levels of access (e.g. multiple view access, single view access, etc.), or different access mechanisms (e.g. email access, sending a paper copy via post, etc.) may incur different costs as represented by different numbers of credits.

In this regard, reference is made to Figure 31 , which is an example of a screen display that appears on the customers computer display 10.2 when the customer 10 is setting up his or her account. As can be seen, the display enables the customer 10 to indicate the type of document which is to be held by the service provider 22 ("Australian Passport" and "AU [Australian] Driver's Licence"). The display also enables the customer 10 to enter the manner in which the documents can be accessed. These include access by an organisation registered with the service provider (e.g. "Cybercheck" (TM)), via email, or via a mailing address. The display also indicates the cost, in credits, of these three options, i.e. zero credits, 1 credit, and 2 credits, respectively.

While the example of a display shown in Figure 31 does not indicate options for the customer 10 to enter the desired level of access as mentioned above, this may be provided in other preferred embodiments.

With regard to the option incurring zero credits, according to one preferred embodiment, the service provider 22 may require a payment for this option, but payment is made by the company (i.e. bank 16) rather than by the customer 10. The fact that the bank 16 is prepared to pay for this option may constitute a convenience the bank offers when its customers apply for its services. Then, as indicated at 124 an account activation display is displayed on the customer's computer screen 10.2 allowing the customer 10 to enter relevant account access details, i.e. details to enable the customer to access, via the Internet, information on the service provider's computer system 20 pertaining to the customer. An example of such a display is shown in Figure 1 8.

The customer's account access details are then transmitted to the service provider 22, as indicated at 1 26.

The service provider's computer system 20 is adapted to then automatically send an email to the customer's designated email address, with confirmation of the account creation, as indicated at 128. An example of such an email is shown in Figure 19.

In addition, after the customer's account activation details are transmitted to the service provider 22, a confirmation of the account activation is presented on the customer's computer screen 1 0.2 and the customer 1 0 is prompted to confirm or authenticate the customer's mobile telephone number, as indicated at 130. This is to enable password or PIN activation number information to be received by the customer 1 0 on the customer's mobile telephone 10.3. An example of such a display is shown in Figure 20.

The steps involved for enabling retrieval of such password or PIN number information on the customer's mobile telephone is now described with reference to Workflow 3 (flowchart), as illustrated in Figure 21 , which is a continuation of Workflow 2.

Enabling mobile telephone retrieval of information As shown in Workflow 3, a mobile telephone authentication screen, as generated by the service provider's computer system 20, is generated on the customer's computer screen 10.2, which prompts the customer 10 to enter the customer's mobile telephone number, as indicated at 132. The customer 10 then enters the mobile telephone number as indicated at 134, and this number is transmitted to the service provider as indicated at 136. Also as indicated, a random four digit PIN code is generated by the service provider's computer system 20 and stored in the database 24 in relation to the customer's account in that database.

The four digit PIN code is then transmitted, as indicated at 138, as an SMS (Short Message Service) message, to the customer's mobile telephone 10.3, using the telephone number provided by the customer 1 0. In addition, as indicated at 140, a mobile PIN code verification screen is displayed on the customer's computer screen 1 0.2 and the customer 10 is prompted to enter the four digit mobile PIN code received by SMS, as indicated at 1 38. An example of such a mobile PIN code verification screen is shown in Figure 22.

The customer 1 0 enters the mobile PIN code in the appropriate box on the computer screen 10.2 as indicated at 142. The PIN code as entered is securely transmitted to the service provider 22 via the Internet as indicated at 144. The service provider's computer system 20 is adapted to check whether the PIN code as transmitted is correct in relation to the customer 1 0 as indicated at 146.

If it is not, then a notification of the incorrect PIN code is caused to be displayed on the computer screen 1 0.2 of the customer 1 0 as indicated at 148. If the PIN code in entered is correct, then a notification of the authenticated mobile telephone number provided to the customer 10, and of the successful setup of the mobile telephone identification retrieval service, is presented to the customer as a display on the customer's computer screen 1 0.2 as indicated at 1 50. An example of such a display shown in Figure 23.

Use of mobile telephone retrieval

Reference is now made to Workflow 4 as shown in Figure 24, which pertains to the use of the mobile telephone identification retrieval service. This service may be used, according to the present embodiment, where the customer 10 wishes to authorise the company 16 (i.e. the bank) to access and view the document copies 14 stored on behalf of the customer by the service provider 22. As indicated at 152 in this workflow, the customer 10 sends an SMS message, which includes the mobile PIN code (as transmitted to the customer according to Workflow 3 at 1 38), to a telephone number which is provided on a registration/application form of the bank 16. An example of such a registration/application form is shown in Figure 25.

It is to be understood that according to the preferred embodiment, the details on the registration/application form, including the telephone number to which the customer 10 is required to send the SMS message, are tailored to the particular company 16 (i.e. the bank). Accordingly, if the customer 10 wished to allow another company (other than the bank) to access and view the customer's documents stored by the service provider 22, that other company would have different registration/application forms with different information thereon, including different telephone numbers to which the customer would need to send an SMS message containing the mobile PIN code.

The telephone number used by the customer 10, i.e. which is provided on the registration/application form of the bank 16, is administered by the service provider 22, but that number is assigned to correspond to the particular bank 16. Thus, when the customer 1 0 sends the SMS, the service provider 22 can determine, based on the telephone number to which that SMS was sent, that the customer is in effect making a request to allow that particular bank 16 to access the customer's document copy 10. Also according to this embodiment, the company 1 6 (the bank), is required to be pre-registered as a subscriber to the service of the service provider 22 in order to have the benefit of being authorised to access and view the customer's stored document copies 14. After the mobile PIN code has been sent to the relevant telephone number appearing on the registration/application form as an SMS message, as indicated at 152, and hence transmitted to the service provider 22, it is checked against the mobile telephone number stored on the computer system 20 of the service provider 22 in relation to that customer 1 0, as indicated at 154.

Thus, the computer system 20 is adapted to check, as indicated at 156, that the customer 1 0 to which the transmitted mobile PIN code pertains, and the customer recorded in relation to the telephone number of the mobile telephone 1 0.3 from which the SMS message has been sent (i.e. the purported customer telephone number), are the same.

If there is no match, then a notification of the incorrect PIN code is sent by SMS message to the customer 10 as indicated at 158. If the PIN code and mobile telephone number from which it has been sent both pertain to the same customer 10 as indicated on the service provider's computer system 20, then the computer system is adapted, as indicated at 220, to check whether all of the documents 1 2 of that customer, of which the service provider holds copies 14, have a "compliant" status as mentioned above.

If the answer to this enquiry, as indicated at 222, is that any of the documents 12 is non-compliant, then a notification to this effect is transmitted to the mobile telephone 1 0.3 of the customer 10 by SMS, as indicated at 224.

If the answer to the enquiry indicated at 222 is that each document 12 is compliant, then, as indicated at 160, a randomly selected identification reference number which is generated by the service provider's computer system 20, is both sent to the customer 10 by SMS message, and stored in the service provider's database 24 in relation to the particular company 16 that the customer wishes to authorise (i.e. the bank). It will be appreciated that, as described above, the identity of the particular company (i.e. the bank 16) will be known to the service provider's computer system 20 by virtue of the fact that the telephone number used by the customer 10 to send the SMS message containing the mobile PIN code, as indicated at 1 52, is a number allocated to correspond to that particular bank.

The customer 1 0 can then enter the newly received identification reference number on the registration/application form of the bank 16, as indicated at 162, and the form is then provided to the bank for suitable processing, as indicated at 1 64. In one embodiment, the registration/application form is a paper form, while in another embodiment, it is an online form.

It will be appreciated that the steps involved in Workflow 4 facilitate security of the authorisation process. In particular, the identity of the customer 1 0 is essentially authenticated by the service provider 22 by virtue of the customer sending the correct mobile PIN code to the telephone number allocated to the particular bank 1 6, as indicated at 152. Thereafter, any particular instance of the bank 16 attempting to access or view the customer's document copies 14 (as described below) can be authenticated by virtue of the fact that the identification reference number sent by SMS message to the customer 10 as indicated at 160, is the same number that the customer then enters on the registration/application form of the bank.

According to a preferred embodiment, the customer 1 0 may log into the customer's account with the service provider 22 (i.e. on the service provider's computer system 20) and voluntarily reset or change the PIN code.

According to other embodiments, the customer 1 0 may retrieve an identification reference number by means other than an SMS message, such as via the internet, by way of a telephone call to a predetermined number to a system which enables the customer to retrieve the code using IVR technology, or by way of a smart phone application.

Viewing customer documents by the company

Reference is now made to Workflow 5 in Figure 26 which relates to the steps taken by the company 16 (i.e. the bank) to process the registration/application form submitted by the customer 1 0, and to access and view the relevant certified document copies 14 stored by the service provider 22 on behalf of the customer.

Once the registration/application form is received by the processing department of the bank 1 6 as indicated at 166, a staff member of the bank can access the service provider's customer identification portal via the Internet, this portal containing a prompt for the username and password of the bank (or bank's staff member) as indicated at 1 68. An example of such an identification portal display is indicated in Figure 27.

The staff member then enters the username and password as indicated at 170, these details being transmitted via the Internet to the service provider's computer system 20 as indicated at 172.

The service provider's computer system 20 is adapted to authenticate the user name and password, as indicated at 174.

If these do not appear valid, then a notification of this is generated by the computer system 20 and displayed on the bank's computer screen 16.1 as indicated at 1 76.

If the username and password appear valid, then a customer identification lookup screen is generated by the service provider's computer system 20 via the Internet on the bank's 1 6 (staff member's) computer screen 1 6.1 prompting for the entry of an identification reference number, as indicated at 178. This is the identification reference number that had been transmitted from the computer system 20 to the customer's mobile telephone via SMS message, as indicated above at 1 60. An example of the lookup screen is shown in Figure 28. The staff member then enters the identification reference number which the customer 10 has included on the customer's registration/application form, as indicated at 1 80.

The entered identification reference number is then transmitted to the service provider's computer system 20 via the Internet and checked against the records stored on the service provider's database 24 in relation to the bank 16, as indicated at 182. It will be recalled that when the identification reference number was sent by SMS message to the customer 1 0 as indicated previously at 160, it was also stored in the service provider's database 24 in relation to the bank 16. The present step 182 in the process involves checking the reference number now sent by the bank's staff member against the reference number that had been stored previously.

The service provider's computer system 20 is adapted to check these numbers against each other as indicated at 184, and if there is no match, then as indicated at 186, it is adapted to display a notification to that effect on the computer screen 16.1 of the bank 16. If there is a match between the numbers, indicating that it is a valid request from the bank 1 6 in relation to an authenticated customer 10, then a display showing the document copies 14 of the customer 10, which are available to be viewed, is displayed on the bank's computer screen 1 6.1 . An example of such a display is shown in Figure 29A. The display includes hyperlinks, one for each available document copy 14. This allows the staff member to select the particular document copy 14 to be viewed by clicking on the relevant hyperlink. Once this is selected, the relevant identification document copy 14 is decrypted using proprietary software and algorithms, and displayed on the bank's computer screen 1 6.1 together with a watermark, as indicated at 188. An example of such a display is shown in Figure 29B.

It will be appreciated that there is a correspondence between the particular identification reference number which was sent by SMS message to the customer 10, and the particular bank 16. This is because the customer 10 obtained the identification reference number by sending an SMS message to the particular telephone number provided on the bank's registration/application form, as indicated at 152, this number being uniquely associated with the bank. Accordingly, if a person other than a staff member of the particular bank 16 were to attempt to gain access to a document copy 14 of the customer 10 by using the same identification reference number, this would not be permitted as the number would not be associated with that other person who is not a staff member of the bank.

On the other hand, once the particular identification reference number has been authenticated by the service provider 22, that same bank 16 can use it again in future to view the same document copies 14. In this sense, the identification reference number may be regarded as an access token (and more specifically, an active access token for as long as it may be used by the bank 16 to view the document), and is referred to as such below. It will be recalled from the description above that costs for the services provided by the service provider 22 (i.e. the services of storing and allowing access to copies 14 of the customer's documents 12) could be indicated in terms of credits for which payment could be made, and different numbers of credits could be redeemed depending on the mechanisms and levels of access selected by the customer 10 for accessing his or her document copies 14. It was also described that one of the modes of payment for such services involves zero credits being paid for by the customer 1 0 but rather, payment being made by the bank 16. Such payment can, according to one preferred embodiment, be made by the bank 16 for each instance of the customer 10 being provided with an identification reference number for enabling the bank to access document copies 14 of the customer. For instance, the bank 1 6 may periodically purchase credits, and these may be redeemed (at the relevant cost in credits) for each such instance of the customer 10 being provided with such an identification reference number.

As seen in Figure 29B, the watermark 250, which is dynamically generated, includes the Internet Protocol (I P) address of the staff member of the bank 16 that accesses the document, the current date, and the staff member's user name. The watermark 250 may assist in preventing printing and unauthorised use of the customer's document copies 14.

Also as seen in Figure 29B, the certification 252 of the document copy 14, as signed by the JP 18, is displayed together with the document copy.

In addition, as indicated at 1 90, the service provider's computer system 20 is adapted to automatically send an email message to the customer 1 0 notifying the customer of the date and time when the bank 1 6 accesses the customer's document copies 14 and the identity of the bank itself. An example of a customer identification portal is shown in Figure 30. Although the invention is described above in relation to preferred embodiments, it will be appreciated by those skilled in the art that it is not limited to those embodiments, but may be embodied in many other forms. For instance, although the preferred embodiment is described above in relation to a copy 14 of a document 12 which is accessed by a bank 16, in other embodiments, the invention may involve different uses. For example, the information stored may be, or may include, documents or other information, for instance of a lawyer's client which is to be safely stored. Alternatively, it may be information of a doctor's patient or information or document pertaining to research of a doctor or academic.

Furthermore, while according to the above embodiments, the party 16 is a bank, and the stored document copy 14 can be used to enable the opening of an account at the bank, the invention can be used to store information or documents for enabling the opening of accounts at other types of institution, or the use, establishment, enabling, or joining, of other types of service or funds. Examples are: other financial institutions; unit trusts; finance brokerages; online casinos; social websites (such as dating or social communication sites) ; club memberships; credit unions; telecommunications companies; telephone and mobile phone service providers; government services; real estate agents' services; employers' services for employees; and so on. Ongoing document validation and authentication

According to the preferred embodiment, the service provider 22 will be able to retrieve information from its computer system 20 and to generate reports on customers' documents that are flagged as "non-compliant".

With regard to documents flagged as "compliant", the service provider's computer system 20 will continue, periodically, to check the validity of these documents by sending enquiries to the DVS. It achieves this by regularly transmitting to the DVS computer system batches of encrypted information pertaining to such documents via HTTPS.

In a similar manner to that described in relation to Figure 2A at 200 to 206, if the DVS indicates any document is non valid, it is flagged as "non-compliant" on the service provider's computer system 20, while it is flagged as "compliant" if the DVS indicates that it is valid.

Then, in a similar manner to that described in relation to Figure 15 at 212 and 214, if the document 1 2 is flagged as "non-compliant", a message is presented to the customer 10 on the customer's computer display 1 0.2 that a formerly active document has been deactivated (and the customer will not be able to use this document for identification purposes in future). If a document was previously active and if a company such as the bank 16 was enabled to view the document as described with reference to Figure 26, and if the document is subsequently flagged as "non-compliant", then according to one preferred embodiment the bank will continue to be able to view the document as long as the bank continues to have an active access token (i.e. a functional identification reference number). In one preferred form of this embodiment, this continued accessibility may be by way of a paper version of the document as mentioned below.

Similarly, a document 1 2 that was previously flagged as "compliant" and which is later flagged as "non-compliant", will continue according to one preferred embodiment to be viewable by the customer 10, but the customer will not be able to use this document for identification purposes in future). In addition, the customer 10 will be able to view reports of all accessing or viewing activity that occurred in relation to such a document 12 before it was flagged as "non- compliant". Closing of a customer's account

According to a preferred embodiment, a customer 1 0 will be able to close his or her account (i.e. terminate the service) with the service provider 22 by making a request in a suitable manner. In this event, all the customer's records and certified copies 14 stored on the computer system 20 of the service provider 22 will be deleted from that system.

Depending on the terms of the service provided by the service provider 22 to the customer 1 0, the service provider may then issue a paper version of the certified copies to companies (such as the bank 1 6) that still has an active access token. Each such paper version will have a unique indicator such as a bar code containing or representing information which refers to the original certifying activity in relation to the document in question.

Claims

1 . A method of providing information of a customer to an information requester, the method including:

1 .1 storing information of the customer on a computer system;

1 .4 determining if the request code matches said retrieval authorisation code;

2. A method according to claim 1 , including:

2.3 ascertaining if the authenticator satisfies at least one predetermined qualification criterion indicating that the authenticator is qualified to authenticate the information ; and

2.4 if the authenticator is ascertained, according to step 2.3, to satisfy the at least one qualification criterion, allocating, on the computer system, an authenticated status to the stored information.

3. A method according to claim 2 wherein, in step 2.1 , the sender is said authenticator.

4. A method according to claim 2 or claim 3 wherein, in step 2.3, the at least one qualification criterion includes that the authenticator logs in to the computer system using at least one login credential, which corresponds to an authenticator login credential stored on the computer system in relation to that authenticator.

5. A method according to any of claims 2 to 4 wherein, in step 2.3, the at least one qualification criterion includes that when logging on to the computer system, the authenticator indicates a location at which the authenticator purports to be located.

6. A method according to any one of the preceding claims including enabling the customer to select from a plurality of information provision criteria according to which said access to the information is provided to the particular requester in step 1 .5.

7. A method according to claim 6 wherein said information provision criteria include at least one of:

said access being provided to the requester by email ; and

8. A method according to claim 6 or claim 7 wherein said information provision criteria pertain to the number of times that the information may be provided to a said particular requester.

9. A method according to any one of claims 6 to 8 including allocating a charge depending on the information provision criterion selected by the customer.

10. A method according to claim 9, wherein said charge is represented by a plurality of purchasable credits allocated to the customer, the credits being redeemable according to the access provided to the requester according to step 1 .5.

1 1 . A method according to claim 9 or claim 10 including receiving payment for said charge by at least one of the customer and a said requester, depending on particular information provision criteria selected by the customer.

12. A method according to any one of the preceding claims wherein, in step 1 .5, the providing of access to the requester is constituted by enabling the requester to view a representation of the information.

13. A method according to any one of the preceding claims wherein, in step 1 .1 , the information of the customer is constituted by a copy of at least one document bearing information.

14. A method according to claim 13 including retrieving, and storing on the computer system, separately from the copy of the at least one document, document information being at least part of the information contained on the at least one document.

15. A method according to claim 14 wherein said retrieving of the document information includes at least one of:

retrieving the document information from an electronic means held on the at least one document.

16. A method according to claim 15 wherein said electronic means includes a radio-frequency identification (RFID) device.

17. A method according to any one of claims 14 to 1 6 including:

1 7.1 transmitting said document information to a document verifier;

1 7.2 receiving a response from the document verifier indicating whether, based on said document information, the at least one document complies with predetermined validity criteria;

18 A method according to any one of the preceding claims including, prior to the step 1 .2, receiving a request from the customer for a said retrieval authorisation code.

19. A method according to claim 17 including, prior to the step 1 .2, receiving a request from the customer for a said retrieval authorisation code wherein step 1 .2 includes providing the customer with the retrieval authorisation code only if a predetermined condition is met, said condition including that, in step 17.3, the at least one document so complies.

20. A method according to claim 18 or claim 1 9 wherein said request from the customer includes a feature uniquely associated with said particular information requester.

21 . A method according to claim 20 wherein the receiving of the request from the customer includes receiving a short message service (SMS) message from the customer, and wherein said uniquely associated feature includes a telephone number to which the SMS message has been sent.

22. A method according to any one of the preceding claims wherein, in step 1 .2, said providing of the customer with a retrieval authorisation code includes sending the retrieval authorisation code to the customer via at least one of:

SMS message, Smart phone application,

the Internet, and

a telecommunications connection.

23. A method according to claim 22 wherein the step of providing the customer with a retrieval authorisation code includes sending the retrieval authorisation code to the customer via a telecommunications connection in the form of a telephone connection, using Interactive Voice Response (IVR) technology.

24. A method according to any one of the preceding claims including:

24.3 if the activation request satisfies said at least one predetermined account activation criterion, activating the account of the customer.

25. A method according to claim 24 including storing, on the computer system, a customer activation code pertaining to the customer, wherein in step 24.1 said activation request includes a purported activation code, and wherein in step 24.2, at least one predetermined account activation criterion includes said purported activation code matching said customer activation code.

26. A method according to claim 25 including:

26.1 generating a random activation key parameter;

26.5 if the activation code key does not match said activation key parameter, determining according to step 24.2 that said activation request does not satisfy said predetermined account activation criterion.

27. A method according to claim 26 wherein, if in step 26.4 it is determined that the activation code key matches the activation key parameter transmitted to the customer according to step 26.2, and if said purported activation code matches said customer activation code, then determining in step 24.2 that the activation request satisfies said at least one predetermined account activation criterion.

28. A method according to any of the preceding claims including sending a notification to the customer if access to the information is provided to the particular requester in accordance with step 1 .5.

29. A system for providing information of a customer to an information requester in accordance the method of any one of the preceding claims, the system including said computer system. 30. A method of accessing information of a customer of an information repository, wherein the repository provides the information in accordance with any one of claims 1 to 28, the method including::

30.1 requesting, said information as a said particular requester; and

30.2 receiving the information from the repository in accordance with the manner in which the information is provided by the repository according to step 1 .5.