ZA200906508B - System for storage of verified information - Google Patents

Description

DE r+ E0009 066530 8 : FIELD OF INVENTION

This invention relates to a system for the uploading, storage and access of verified and authenticated documentation which may be required for identification of individuals or other legal entities.

BACKGROUND OF THE INVENTION

Currently when an individual (natural person) or any other legal entity (e.g. close corporation, company, trust, partnership) seeks to enter into a transaction or establish a business relationship (e.g. home loan, personal loan, vehicle finance) with an Accountable

Institution (“Al”) (as defined by the Financial Intelligence Centre Act, 2001 (Act 38 of 2001) (“FICA™) or an Electronic Communication Service Provider (‘ECSP”) (as defined in the

Regulation of Interception of Communications and Provision of Communication-related

Information Act, 2002 (Act 70 of 2002) (“RICA”) or an Additional Transactional Institution ("ATI") which requires a user verification system in order to transact with a client base, that ~ individual or juristic entity is required to produce certain documentation (e.g. proof of identity, proof of address) in accordance with FICA or RICA . It is the Al's/ATI's or ECSP’s responsibility to make sure that the individual or juristic entity in question has supplied the required identity documentation before continuing with the transaction. Failure to meet

FICA or RICA legislative compliance requirements by the AI/ATI or ECSP respectively, can result in hefty fines been imposed by the relevant regulator on the AI/ATI or ECSP : where applicable

The object of the invention is to provide a secure central repository system that houses electronic forms and/or copies of individual's and juristic entity's FICA and/or RICA documents. In addition, the repository can be used to store electronic forms and/or copies of a variety of important documents, such as certificate, contracts, legal documentation etc. Initially the repository will only be used to store natural person’s FICA documents, with "the intention to roll out to other legal entities at a later stage. Al's/ATI's and ECSP’s will then be able to access individual's and juristic entity's FICA/RICA statuses and where necessary be able to request electronic forms or copies of the actual documents wR LT } themselves, subject to the express permission received from those individuals and juristic entities.

THE INVENTION

According to the broadest aspect of the invention, a system for uploading, storage and access of verified and authenticated documentation comprises means for duplicating the documentation, and converting it to electronic form; means for securely transmitting the electronic form of the documentation to one or more servers; means for capturing data relating to the documentation and transmitting this data together with the documentation; means for writing the information received to one or more databases; the database being linked to one or more websites from which enquiries relating to the documentation may be submitted by authorised users from a remote terminal via a suitable secure communication link.

In the preferred form of the invention, the system is used for uploading, storage and access of identification and other information for persons (individuals or legal entities) for : example for the purposes of verification of identity under FICA or RICA or any equivalent or similar legislation. For the purpose of FICA and RICA, the system generates an identity : card bearing a photograph of the individual as well as other personal and or juristic data which may be used as a form of person identification, obviating the need for the individual : and/or juristic entity to submit FICA and/or RICA documentation in every situation in which . the transacting parties are required to undergo FICA/RICA verification. : © In this form of the invention, the system further includes an image recorder for obtaining a. digital image of the individual, the image being transmitted together with the duplicated documentation to the server.

Similarly, in this form of the invention, the system is also used to capture certain biometric information of an individual, such as the individual's fingerprint and/or finger vein image.

This will be done using specific finger vein image and fingerprint readers/modules. The recognition of the pattern of minute blood vessels under the skins and or fingerprint data, offers strong levels of security, authentication, accuracy and convenience to the system.

- . y - BRO09/nETng : Also in the preferred form of the invention, the database is duplicated at least once, but is preferably mirrored by three other identical databases, with two such databases located ) remotely from the first database.

The duplicating means preferably comprises a document scanner capable of scanning documents and converting the scanned documents in the form of full colour electronic images and/or black and white images, for example pdf files. The duplicating also preferably comprises a finger vein image and/or fingerprint reader/module (either combined or two separate readers) capable of capturing an individual's finger vein image and fingerprint. Finally, the duplicating preferably comprises a camera or webcam, capable of capturing a digital image of the individual's face.

In certain instances, for example where the system is used for FICA/RICA, personal information captured may be required to be verified against one or more information databases, for example Department of Home Affairs, South African Fraud Prevention:

Service database, Deeds Office database or the like. Juristic entity information may be : a captured from and/or verified against CIPRO (Company and Intellectual Property

Registration Office) database records, South African revenue services databases, credit . bureau databases and the like databases. : ‘ oo

Furthermore in such - situations, an accredited and trained person (such as a

Commissioner of Oaths) would be required to facilitate operation of the capture and upload system and physically identify the person and/or juristic entity and authenticate the documentation prior to authentication, duplication and transmission thereof. In this form of the invention, the Commissioner of Oaths would be required to insert a-secure dongle (USB storage device) into the system prior to transmission of the captured data and duplicated documentation.

The remote terminal for accessing the stored documentation, may comprise a (1) computer terminal having an internet connection and (2) a finger vein image and/or fingerprint reader, or alternatively may comprise a card reader in which the person

E requiring to be identified submits his/her card to an authorised user of the system who uses the card reader (e.g. credit card point of sale terminal).

Each request for verification may result in the server generating a one-time password which is sent to the cellular telephone or the like of the person or the person representing a juristic entity, requiring to be identified, by means of sms, mms, or similar messaging technology. The stored information may then only be released or made available to the authorised user upon inputting of that password. Alternatively, a biometric reading may be provided by the person who is transacting and validation of the reading conducted in order to authenticate the person, or juristic entity the person represents. The stored information ~~ may then only be released or made available to the authorised user upon successful verification of the biometric reading.

According to a second aspect of the invention, a secure identification card includes a photograph of the person identified (for individuals only), a unique identification number and a magnetic strip or the like electronically readable element, the card providing a means of initially identifying the individual or juristic entity and then accessing oo documentation stored on a secure database for the purpose of verifying the identity of the . person or juristic entity to be identified upon the card being read by a card reading device of an authorised user.

The card preferably includes latent and patent security features adapted to prevent : duplication thereof.

A Commissioner of Oaths (COO) may upload the personal or juristic entity's details and documentation. For example, the COO may be an attorney or bank official or other person accredited and authorised in terms of the system.

A more detailed description of the system process flow follows below which uses the definitions set out below.

0 . : Co. i

WY, 1: BRG09/06308 - DEFINITIONS

Dongle - A USB flash drive together with the application used for document scanning and indexing. The dongle will also have a non-exportable digital certificate installed and comprises a crypto stick with at least 512mb memory.

FICA/RICA Card — A card issued to a client (similar to credit card). A card consists of a photo of the client (natural persons only) as well as other identity information. FICA cards can be presented to Al's/ATI's or ECSP’s to establish and verify clients’ identities.

FICA/RICA Documents — FICA/RICA documents in this document refers to documents ny which can be used as proof of identification, proof of residential/business address and proof of tax number by clients (e.g. Such as an identity document, passport, CIPRO certificate, CK1, CM1,TV license, utility bill, SARS correspondence), as required by FICA and/or RICA.

Digital Certificate — is an electronic document which incorporates a digital signature to bind together a public key with an identity, information such as the name of a personoran - organisation, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual.

In the FICA/RICA Upload and FICA/RICA Update sections that follow, the uploading and ~ updating processes of individuals and juristic entities will be dealt separately. :

Lo re L- w TEE009 70650 g

N ~ : 1 FICA/RICA Upload Process te 1.1 FICA/RICA Upload Process - Individuals: re ee aaa]

Client completes

Client enters COQ's fi - sppicaton

Co original versions of

FICARICA

Documents 2 application forms and and authenticates the into his/her computer contract for client to onginat documents, makes and suthenticates him/ sign copies of the documents herseff on the FICA fo) and certifies the copies Upload Application 3 9 8 : 7

Data ls sent to Rn ep ’ $00 captures cents

L@W's system as scans the originals and yd pt ger an xmi message certified coples as PDF vein es 2 photo documents.

L@W system sends

L@W system om 2 receives @ acknowledgement - data to L@W database .

Client's Apptication is : == EEE 2 sent to client via sms . @Q [= j writes data to FoneWorx database

Figure 1: FICA/RICA Upload Process - Individuals

The FICA/RICA upload process for individuals involves a COO uploading a client's identity information into the system for the first time. The following points describe the FICA/RICA upload process in detail: 1. The client enters a COO place of business with his or her FICA/RICA documents. 2. The client may be given an application form to fill in and a contract to sign. The application form will capture the client's necessary details as required by the

“

E system. The necessary details include the following: name, identity or passport number, physical address, postal address, and contact details (home phone

E number, work phone number, cell phone number and e-mail address), MSISDN number and linked IME| number of the client's cellular phone/s. The contract the client signs, gives permission to the AI's/ATI'S/fECSP’s that are registered users of the system to view that client's identity information and FICA/RICA documents, subject to that client either presenting a FICA/RICA card at the AI/ATI/ESCP and/or the client giving express permission via a one-time PIN sent to the client in an sms or via a biometric reading provided by the client. . 3. The client completes the application form and signs the contract in the presence of - the COO. oy 4. The client hands over his or her original FICA/RICA documents to the COO. 5. The client physically presents him or herself in front of the COO, so the COO is able to establish and verify the identity of the client. Once satisfied with authenticity of the identity and proof of residence documents (by following a specific process of authentication and using tools such as a UV light reader), the COO makes copies of the required documents and certifies them by stamping and signing the documents as a Commissioner of Oaths (note this requirement may later become unnecessary). . 6. The COO inserts his or her pin protected dongle into his or her computer. The

COO authenticates him/herself on the FICA/RICA Upload application using his or - her digital certificate. 7. The COO captures the client's finger vein and/or fingerprint and takes a photograph of the client's face. - 8. The COO scans the originals of all FICA/RICA documents and of any other client . documents (which the client wants scanned for safe keeping) as well as the stamped certified copies, indexes all of the scanned documents and captures the client's information using the FICA/RICA Upload Application. A copy of the client's application form and signed contract will also be scanned and indexed as part of the upload process. The client's identity information along with his or her

FICA/RICA documents (preferably created in PDF format) will be saved to the application Outbox for the L@W system to collect. The L@W client application

No”

E packages and encrypts the data, checks for errors, performs a checksum and places the package in the designated Outbox of the COO. If an error is discovered, - the COO will need to make the necessary adjustments before continuing. 9. The encrypted data is sent by the L@W client application via a secure communication channel (SSL) to the L@W system. 10. The L@W system receives the data, checks for errors and verifies the data against the checksum. In the event of an error the COO can call the FICA Support Centre (being a call centre for assistance). 11. The L@W processor writes an entry to the L@W database as an audit trail. The entry to the database includes the following fields: Transaction ID, Law ID,

Message ID, Sender ID, Sender User, Recipient ID, Recipient User, Transaction :

Date, Action Date and Status as well as the checksum of documents stored. 12. The packaged data is then sent by the L@W system to the FoneWorx system via a fixed secure line (currently a 512Mb dedicated Diginet line) connecting FoneWorx and L@W. 13. The FoneWorx system receives the packaged data. 14. The FoneWorx processor stores the necessary information in the appropriate a. tables in the FoneWorx database. Co 15. An acknowledgement of receipt is sent to the L@W system. : 16. The L@W system receives the acknowledgement. : 17. The client's application is processed by FoneWorx, moderation of the data is completed and a reference number is sent to the client via-sms. 18. The client receives a sms containing his or her reference number from FoneWorx. 19. A FICA/RICA card is posted to the client or to the COO for collection by the client.

Foneworx is responsible for the issuing and support of all FICA/RICA cards. 20. The client receives his or her FICA/RICA card in the post or collects it from the

COO. 21. The card is activated by the client via IVR (Interactive Voice Response), using the registered FICA/RICA Card PIN number the client selected earlier in the process.

Checks are made to ensure that the activation request comes from the same cell phone that the reference number was sent to. The client is also required to supply his or her FICA/RICA card number when activating his or her card.

LR i nn

Cu HR009/06308 we :

K 22. The card is activated by FoneWorx and the client is able to start using his or her card. 1.2 FICA/RICA Upload Process — Juristic Entities: - aaa a 45]

Representative ) Juristic entity Being ~ 2 representative enters and signs a Representatives Entity receives A 8 COO's place of contract receive reference FICARICA ta Mig € business number via sms cards ee 8 Reprasentative [+4 versions of entity's

FICARICA

Documents application forms and and authenticates the into his/her computer contract for client to original documents, makes and authenticates him/ sign copies of the documents herself on the FICA o and certifies the copies Upload Application 3 eo

COO captures entity's

Data is sent to data and scans the an xml message copies 8s PDF documents.

L@W system sends = 2 recelves ® acknowledgement 1 : data to L@W database el [Ee FICARIC, . a cknowtedgment processad al Fone! A cL : 2] via sms } i writes data to FoneWorx database

Figure 2: FICARICA Upload Process - Juristic Entities i y 4 [OY Ts

The FICA/RICA upload process for juristic entities involves a COO uploading an entity's identity information into the system for the first time. The following points describe the

FICA/RICA upload process in detail: 1. A juristic entity's representative enters a COOs place of business with the entity's

FICA/RICA documents.

Ww" - 2. The representative may be given an application form to fill in and a contract to sign.

The application form will capture the entity's necessary details as required by the

B system. The contract the representative signs, basically gives permission to the

AI's/ATI'S/ECSP’s that are registered users of the system to view that entity's identity information and FICA/RICA documents, subject to an entity representative either presenting an entity FICA/RICA card and/or the representative giving express permission via a one-time PIN sent to the representative in an sms or via a biometric reading provided by the representative 3. The representative completes the application form and signs the contract in the presence of the COO. 4. The representative hands the entity's original FICA/RICA documents to the COO. 5. Once satisfied with authenticity of the identity and proof of residence documents : (by following a specific process of authentication), the COO makes copies of the required documents and certifies them by stamping and signing the documents as a Commissioner of Oaths (note this requirement may later become unnecessary). 6. In addition, in order to use the repository as a safe and private vault for a variety of ' documents which an entity client may deem to be important, if presented with such documents, the COO can make copies and certify such documents (which may for . example include entity documentation, contracts, legal documentation etc.). The : system caters for a variety of such documents, by listing such documents in the i. system (which can be expanded or added to at any time). 7 7. The COO inserts his or her pin protected dongle into his or her computer. The ~~ .

COO authenticates him/herself on the FICA/RICA Upload application using his or her digital certificate. . "8. The COO scans the originals of all FICA/RICA documents and of any other entity ye client documents (which the representative wants scanned for safe keeping) as well as and the stamped copies, indexes the scanned documents and captures the entity's information using the FICA/RICA Upload application. A copy of the application form and the signed contract will also be scanned and indexed as part of the upload process. The entity's identity information along with FICA/RICA documents (created in PDF format) will be saved to the application Outbox for the

L@W system to collect. The L@W client application packages and encrypts the

E data, checks for errors, performs a checksum and places the package in the designated Outbox of the COO. If an error is discovered, the COO will need to - make the necessary adjustments before continuing. 9. The encrypted data is sent by the L@W client application via a secure communication channel (SSL) to the L@W system. 10. The L@W system receives the data, checks for errors and verifies the data against the checksum. In the event of an Error the COQ can call the L@W call centre for assistance. 11. The L@W processor writes an entry to the L@W database as an audit trail. The entry to the database includes the following fields: Transaction ID, Law ID, . Message. ID, Sender ID, Sender User, Recipient ID, Recipient User, Transaction

Date, Action Date and Status as well as the checksum of documents stored. 12. The packaged data is then sent by the L@W system to the FoneWorx system via a fixed secure line (512Mb dedicated. Telkom Diginet line) connecting FoneWorx and

L@W. : 13. The FoneWorx system receives the packaged data. 14. The FoneWorx processor stores the necessary information in the appropriate : tables in the FoneWorx database. no Po - 15. An acknowledgement of receipt is sent to the L@W system." ' SR 16. The L@W system receives the acknowledgement. 17. The entity's application is processed by FoneWorx and a reference number is sent a to the entity's representatives via sms. Entity representatives are selected as part : of the upload process. Only representatives who have been uploaded as individuals in the system will be eligible for entity FICA/RICA cards. 18. The representatives receive a sms containing a reference number from FoneWorx. 19. The entity FICA/RICA cards are posted to the entity's postal address (or other specified addresses) or collected from the COO, Foneworx is responsible for the issuing and support of all FICA/RICA cards. 20. The representatives receive their FICA/RICA cards. 21. The cards are activated by the representatives via IVR (Interactive Voice

Response), using the registered FICA/RICA Card PIN numbers (set the same as their individual FICA/RICA Card PINs by default). Checks are made to ensure that

J 0 -

No fo TR i

WR009 /0 650g - the activation request comes from the same cell phone that the reference number was sent to representatives are also required to supply their FICA/RICA card ) numbers when activating their FICA/RICA cards. 22. The cards are activated by FoneWorx and the representatives are able to start using their FICA/RICA cards. 2 Verification of Identity and Address Information

When a client is uploaded into the system, the system may provide functionality to the

COO, to enable the programmatic verification of identity and address information that is supplied by the client. The system will check RSA -identity numbers against the South

African Department of Home Affairs in the case of individuals (South African citizens or residents). The system will check Close Corporation and Company registration numbers against CIPRO (Company and Intellectual Property Registrations Office). :

The system may check residential or business address information supplied against address information held by external 3™ parties. Examples of these 3™ parties include, but ~ -are not limited to the Deeds Office, Municipalities, SARS and Credit Bureaus. If the - address information held by any of these 3 parties does match the information provided by the client at any point in time, the system may use such information to automatically invalidate a client's FICA/RICA profile. Ia :

Where the stored documentation is required to be updated in order to maintain a current status, as in FICA/RICA applications, the system is adapted to permit update of such documentation on the database. This updating process may be conducted manually or automatically. These processes are described below in more detail:

Bh 3 FICA/RICA Updates - 3.1 Manual FICA/RICA Updates - Individuals:

Manual updates for individuals take place when an individual takes his or her up-to-date documents to the COO for updating in the system.

FICA/RICA Update - Individuals 2 ZZ 9 = a Ye with up-to-date Client receives ee 8

Es updated documents Client gives OTP

Rit oyei

Coo ent’ ele}e] i The COO he dient’ orn a etronomas the Rar core on COQ receives OTP liom updated ranidinkurliy original documents, makes authenticates him/herself verification from Upload Application. The capies of tha documents and on the FICA Upload FoneWorx system application packages and [eo] certifios the copies Application encrypts the data. 8

Data i tio ' arequest is sent through to an xmi message the L@W system to. L L@W system sends ' .

The request is forwarded rocaen aaa eo oreo om : : = ‘automatically to FonaWorx 9 by the L@W system receives data io LEW database ~ acknowledgement )

HE ="T— $ sons or tan | tos oa racaives he data £ request verification lo COO writes data to FoneWorx - database

Figure 3: Manual FICA/RICA Update Process - individuals

The following points describe the manual FICA/RICA update process for individuals in detail: 1. The client approaches a COO (e.g. attorney) with his or her up-to-date FICA/RICA documents.

W

E 2. The client hands over the up-to-date documents and his or FICA/RICA card to the

COO.

Bh 3. The COO establishes and verifies the identity of the client, makes copies of the up- to-date documents and certifies them as true copies of the originals by stamping and signing the copies. 4. The COO inserts his or her dongle into his or her computer. The COO authenticates him/herself on the FICA/RICA upload application using his or her password and digital certificate. 5. The COO enters the client's FICA/RICA card number and an OTP request or biometric reading verification request is sent through the L@W/FoneWorx System to authenticate the user. ..- . 6. The L@WI/Foneworx system receives the request and forwards on the request to the FoneWorx system for processing. 7. The FoneWorx system receives the request from L@W's/FoneWorx upload application. - 8. The FoneWorx system generates an OTP and sends it to the client via sms. 9. or verifies the biometric reading and sends verification to the COO.The client receives the sms with the OTP (where applicable) LO +. 10. The client gives his or her OTP to the COO (where applicable). : 11. The COO receives the OTP from the client and enters it into the system or receives : the biometric verification from the L@QW/FW system. . 12. The COO scans the original and stamped copies, indexes the scanned documents : using the FICA/RICA upload application. The L@W client system packages and encrypts the data, checks for errors, performs a.checksum and places the package i in the designated Outbox of the COO. if an error is discovered, the COO will need toy to make the necessary adjustments before continuing. 13. The encrypted data is sent by the L@W client application via a secure communication channel (SSL) to the L@W system. 14. The L@W system receives the data, checks for errors and verifies the data against the checksum. In the event of an error the COO can call the Foneworx Call Centre for assistance.

df : ". 15. The L@W processor writes an entry to the L@W database as an audit trail. The entry to the database includes the following fields: Transaction ID, Law ID,

B Message ID, Sender ID, Sender User, Recipient ID, Recipient User, Transaction

Date, Action Date and Status as well as the checksum of documents updated. 16. The packaged data is then sent by the L@W system to the FoneWorx system via a fixed secure line (512Mb dedicated Telkom Diginet line) connecting FoneWorx and

L@W. 17. The FoneWorx system receives the packaged data. 18. The FoneWorx processor stores the necessary information in the appropriate tables in the FoneWorx database and an SMS is generated and sent to the client. 18. An acknowledgement of receipt is sent to the L@W system. . 20. The L@W system receives the acknowledgement. 3.2 Manual FICA/RICA Updates — Juristic Entities:

Manual updates for juristic entities take place when an entity representative (FICA/RICA card holder) takes the entity's up-to-date documents to the COO for updating in the system.

Bo " ~ +ERgor Jog 3 $Y a id ¥ ’ FICA/RICA Update - Juristic Entities ra 9 aaa kb] lo-date documents via sms

Cc 2 Reprasentative hands a over updated ) R tatve

Coo

COO verifies the enti COO inserts Dongle int The COO scans the entity's identity and tnates ho FA and ’ COO receives OTP or updated documents and origina! documents, makes authenticates him/herself biometric verification amends entity data. The copies of the documents and on the FICA Upload application packages and 0 certifies the copies Application encrypts the data. 8

The COO enters the Data is sent to tative ity FICA/ system “RICA card Taam and Pri message. request is sent through to the : L@W system

Law L@W system sands 2 automatically to FoneWorx 9 by the L@W system

L@W system L@W processor writes acknowledgement data to L@W datatiase

FoneWorx system sends l em (3 thal [e's writes data to FoneWarx ' database

Figure 4: Manual FICA/RICA Update Process — Juristic Entities

The following points describe the manual FICA/RICA update process for juristic entities in ao detail: : 1. An.entity representative approaches a COO (e.g. attorney) with the entity's up-to- he date FICA/RICA documents. 2. The representative hands over the up-to-date documents and his or her entity

FICA/RICA card to the COO. 3. The COO verifies and authenticates the up-to-date documents, makes copies of the documents and certifies them as true copies of the originals by stamping and signing the copies.

E 4. The COO inserts his or her dongle into his or her computer. The COO authenticates him/herself on the FICA/RICA upload application using his or her

BE password and digital certificate. 5. The COO enters the representative's entity FICA/RICA card number and an OTP request or biometric reading verification request is sent through the

L@W/FoneWorx System to authenticate the user. 6. The L@W/FoneWorx system receives the request and forwards on the request to the FoneWorx system for processing. 7. The FoneWorx system receives the request from L@W's/FoneWorx's upload application. 8. The FoneWorx system generates an OTP and sends it to the representative via : sms or verifies the biometric reading and sends the verification to the COO. 9. The representative receives the sms with the OTP (where applicable) 10. The representative gives his or her OTP to the COO (where applicable). 11. The COO receives the OTP from the client and enters it into the system or receives the biometric verification from the LQW/FW system. 12. The COO scans the original and stamped copies and indexes the scanned documents using the FICA/RICA upload application. The L@W client appplication packages and encrypts the data, checks for errors, performs a checksum and places the package in the designated Outbox of the COO. if an error is discovered, the COO will need to make the necessary adjustments before continuing. 13. The encrypted data is sent by the L@W client application via a secure communication channel (SSL) to the L@W system. 14. The L@W system receives the data, checks for errors and verifies the data against the checksum. In the event of an error the COO can call the L@W call centre for assistance. 15. The L@W processor writes an entry to the L@W database as an audit trail. The entry to the database includes the following fields: Transaction ID, Law ID,

Message ID, Sender ID, Sender User, Recipient ID, Recipient User, Transaction

Date, Action Date and Status as well as the checksum of documents updated.

{ -

J065, ". 16. The packaged data is then sent by the L@W system to the FoneWorx system via a fixed secure line (512Mb dedicated Telkom Diginet line) connecting FoneWorx and

L@W. 17. The FoneWorx system receives the packaged data. 18. The FoneWorx processor stores the necessary information in the appropriate tables in the FoneWorx database and an SMS is generated and sent to the representatives. 19. An acknowledgement of receipt is sent to the L@W system. 20. The L@W system receives the acknowledgement. : 3.3 Automatic Updates: | :

Clients (individuals and juristic entities) will have the option to consent to automatic updates of their FICA/RICA documents when they sign up for the solution e.g. every month a municipal bill is automatically sent to the L@W/FoneWorx system for processing.

Possible sources for automatic updates include, but are not limited to the following institutions: municipalities, fixed telephone line providers, fixed line internet service providers, banks, SARS, SABC and DSTV. 4 Expiring of Documents: } All documents will be assigned a document date (date of issue as specified on the oo documents) when they are loaded into the FICA/RICA repository by a COO. The

FICA/RICA solution will automatically calculate a document's validity by applying the - appropriate AlI's/ATI'S/ECSP’s FICA/RICA rule set to that specific document's type (e.g. a utility bill that has a document date greater than three months from the current date will reflect as expired for an AI/ATI/ECSP that has defined the expiry period for this document type to be three months). The FoneWorx system will automatically send out sms and/or email reminders to clients (individuals and juristic entity representatives) at certain time periods, such as two weeks and one week before their documents are about to expire.

“7 : 6) - io

E2009 /0659 4

KE § FICA/RICA Enquiries:

Enquiries may be submitted to the system either by an Al or by a client (the person whose information is on the database, and who holds a card generated by the system).

There are several different methods of enquiry (which are covered separately in the sections that follow). 5.1 Subscribing Institutions:

Subscribing institutions are Als/ATI's and ECSPs that have signed up to receive a fully electronic FICA/RICA solution. The full system includes audit trails, storage of electronic records and the ability to set and change FICA/RICA business rule sets. . Subscribing AI/ATI/ECSP Prerequisites .

Before commencing, a representative from an AI/ATI/ECSP will need to sign a contract on behalf of the Al/ATI or ECSP, authorising L@W and/or FoneWorx to keep electronic copies of their FICA/RICA records. )

All Al/ATI and/or ECSP details in terms of company and user information, company and user preferences, chosen security models (company, department and user levels) and .

FICA/RICA status criteria and rules will need to be provided by the AI/ATI or ECSP. Before = no an end user at an Al/ATI or ECSP is able to start using the system that user will need to be signed up, accredited and trained. . =

All end users at AlI's/ATI's and ECSP’s will need to complete an application form for a digital certificate. L@W will keep copies of the completed digital certificate application forms. All end users will be issued with a digital certificate, unless they have already been issued with one. Law Trusted Third Party Services (Pty) Ltd (a sister company of L@W), through the certificate authority which it operates, will issue all digital certificates for the

Al's/ATI's and ECSP’s as well as provide support for these certificates.

J ; i eT]

YP : hol ER © ga - = £4 52000 /065¢g

End users at Al'sATI's’sECSP’s may perform a dual role in terms of placing FICA/RICA ’ enquiries and uploading and/or updating clients’ FICA/RICA documents. Obviously the end user in question will have to have met all the criteria and pre-requisites with regard to performing both the AI/ATI or ECSP and COO roles simultaneously. Essentially this means that when a client visits an AI/ATI or ECSP, he or she may have up-to-date

FICA/RICA documents uploaded at that Al/ATI or ECSP, rather than having to go to a

COO first.

AlI/ATI/ECSP Web Enquiry — Subscribing Institutions:

AUATI/ECSP Web Request : r = 0a dUdUaa4a4a4a4a4a4a4a4a4a4a4a4a4aaaa

Th

A user logs onto L@wW a search pia prado a Fw website using digital Passport number, juristic entity) in search i 8 RICA card number results . wi _. request actual = User views "documents. te individual's or - = juristic entity's < A roquest is sent to User receives OTP FICARICA ——

L@W system verification L@W system

The L@W database L@W system 2 A request . 8 burs receives data rece a ® forwarded to to FW system , bal Faneworx system FW database FW receives the = o= = client or biometric . 2 verification to the [=] user. w

A the OTP via sms Al user =}

Figure 5: AVATI/ECSP Web Enquiry (Subscribing Institutions)

~/ E2009 /065 8

IE There are two separate FICA/RICA websites, one for FoneWorx clients (https://www.youridentity.co.za) and one for L@W clients (https://www.ficacard.co.za). In a the process details that follow L@W and FoneWorx may be used interchangeably with regard to who receives the initial request and who gets the update i.e. if a FICA/RICA profile is viewed on the FoneWorx website, FoneWorx will record the transaction and send an update to L@W and vice versa. FoneWorx always handles the sending of the one-time

PINs via sms.

The following points describe the Al/ATI or ECSP web request process in detail: 1. A user at an AI/ATI or ECSP logs on to the. FICA/RICA website using a digital - certificate. 2. The user is presented with an option to search for an individual's or juristic entity's

FICA/RICA information and documents by ID/registration number, surname or

FICA/RICA card number. The user performs a search based on any of the aforementioned criteria. 3. The user selects the relevant individual or juristic entity in the search results and clicks to access that individual's orjuristic entity's FICA/RICA information. - 4. An OTP request or biometric verfication request is sent through to the

L@W/FoneWorx system. 5. The request is received by L@W/FoneWorx and forwarded on to FoneWorx. 6. The FoneWorx system sends an OTP to the client where applicable). . : 7. The client (individual or legal entity representative) receives an OTP via sms (where applicable) 8. The client gives the OTP to the AI/ATI or ECSP user where applicable). 9. The user inputs the OTP in the web application or receives the biometric : verification and is given access to the individual's or juristic entity's FICA/RICA profile and FICA/RICA documents. 10. The user establishes and verifies the individual's or juristic entity's identity by opening, viewing and checking the actual FICA/RICA documents available in the system. The user is able to view client details including the following without limitation: |D/registration number, name, thumbnail photo (individuals only),

N J s addresses, contact details, MSISDN number and linked IMEI number of cellular phones and the like, as well as a list of FICA/RICA documents. A separate option a would be to view the transaction history that is pertinent to the AI/ATI or ECSP performing the FICA/RICA. For each document in the list, the name, type and document date will be displayed. The user will preferably only be able to view water-marked versions of the original documents at this point. The user does however have the opportunity to request the electronic form originals and actual certified copies of the FICA/RICA documents — see AI/ATI or ECSP document request below. 11. When the user views an individual's or juristic entity's FICA/RICA information a view message is sent to the L@W system. The message contains a date-time stamp of the view event as well as a list of all documents present at that point in time, together with their types and dates. The system will also record that individual's or juristic entity's FICA/RICA status at that specific point in time. : 12. The L@W system receives the view message. : 13. The L@W system writes the data to the L@W FICA/RICA database. 14. An update is sent to the FoneWorx system in the form of an xml message via the

FoneWorx and L@W system infrastructure. So CL +156. The FoneWorx system receives the update. : . 16. The FoneWorx database is updated with an audit trail entry by the FoneWorx processor. .

od

No

IE Al/ATI or ECSP Document Request (Subscribing Institutions): (Continued from Al/ATI or ECSP Web Request above) rr. nm __—————————— 2 : a which documents to [5 request actual Yes. download and clicks The user receives

Q documents on download fink on downloaded documents w Ca the L@W/FW website bn No 2 cr . tr 4 The L@W syst © system he L@W database is sends an update to the undated wilh an audi !

[4] 2 Foneworx system The FW database is 2 receives the updated with an audit

Figure 6: AI/ATI/ECSP Document Request (Subscribing Institutions) 1. When viewing an individual's or juristic entity's FICA/RICA record, a user at an

Al/ATI or ECSP has the option to request electronic versions of an individual's

FICA/RICA documents. If the user does not take up this option in this branch of the

Al/ATI or ECSP Web Request, the process ends here. a 2. The user selects which documents he or she wants to download and clicks on the K download button on the L@W/FW website. The user may only be able to select a maximum of say five documents per download. A download request is sent through to the L@W system. 3. The L@W system receives the download request. 4. The L@WI/FW system compresses the selected pdf documents, and collates them to a single pdf file. The user is presented with an option to save this pdf file locally.

J n 5. The L@W system writes an entry to the L@W database, effectively recording the details of the download.

BE 6. The user saves the generated pdf file on his or her local file system. The pdf file will be encrypted with the user's public key, so that only that user will be able to open ' and print the downloaded original pdf documents. All pdf documents will be digitally signed by L@W Compliance or FoneWorx. Digital certificates expire every two years and therefore users at Als will only be able to access downloaded documents until their certificates expire. When a user is re-issued with a digital certificate, that user will have to re-download individual's or juristic entity's

FICA/RICA documents if required. 7. The L@W system also sends an update to the FoneWorx system as an xml .- message. 8. The FoneWorx system receives the update. 9. The FoneWorx database is updated with an audit trail entry. 5.2 Non-Subscribing Institutions:

Non-subscribing institutions are AI's/ATI's and ECSP’s that have not signed up for the fully electronic FICA/RICA solution. These institutions will still be able to login and view client's

FICA/RICA information and documents if required, subject to the client: giving them express permission to do so, via a one-time PIN that is sent in -an SMS to the client. These institutions will not enjoy the benefits of the full FICA/RICA solutions as no audit trail will be kept for them to review, no records will be kept electronically and they will not have the option to set their FICA/RICA business rule sets via the website.

Nw

IE Al/ATI/ECSP Web Enquiry — Non-Subscribing Institutions: _ AlI/ATI/ECSP Web Request (Non-Subscribing) . I

The user enters

A user browses transaction details and : p an User dick 3 registration number = posers | [Teves gl iC N < i information and prints a is sent too tha ) a" = — } Bn sent to through lo Al user inputs OTP the L@W system

The L@W database L@W syst : = 2) received and x forwarded to

Te to FW system 16 15 =a

Oo sends OTP to the updated view message = client 2 & 2 the OTP via sms Al user } [&]

Figure 7: AI/ATHECSP Web Enquiry (Non-Subscribing Institutions)

The following points describe the AI/ATI or ECSP web request process in detail: Co 1. A user at an Al/ATI or ECSP browses to the FICA/RICA website. 2. The user enters the transactional details (user's own name, institution's name and transaction reference) as well as the client's FICA/RICA card number and

ID/registration number. 3. The user then clicks on the Send SMS button on the website. 4. An OTP request is sent through to the L@W system. :

Claims (22)

1. . y de Co x 098/065) g ~ CLAIMS:

   ’ 1. A system for uploading, storage and access of verified and authenticated documentation comprises means for duplicating the documentation, and converting it to electronic form; means for securely transmitting the electronic form of the documentation to one or more servers; means for capturing data relating to the documentation and transmitting this data together with the documentation; means for writing the information received to one or more databases; the database being linked to one or more websites from which enquiries relating to the documentation may be submitted by authorised users from a remote terminal via a suitable secure communication link.
2. 2. A system for uploading, storage and access of verified and authenticated documentation according to claim 1 in which an identity card bearing a photograph - of the individual as well as other personal and/ or juristic data which may be used as a form of person identification is generated. :
3. 3. A system for uploading, storage and access of verified and authenticated documentation according to claim 2 which includes an image recorder for obtaining | : a digital image of the individual, the image being transmitted together with the duplicated documentation to the server. : :
4. 4, A system for uploading, storage and access of verified and authenticated : documentation according to any of the above claims which includes a biometric reader device for capturing an individual's fingerprint and/or finger vein image. x
5. 5. A system for uploading, storage and access of verified and authenticated documentation according to any of the above claims in which the database is . duplicated.
6. 6. A system for uploading, storage and access of verified and authenticated documentation according to claim 5 in which the database is mirrored by three R other identical databases with at least one of the databases being located remotely from the first database.
7. 7. A system for uploading, storage and access of verified and authenticated documentation according to any of the above claims in which the duplicating means comprises a document scanner capable of scanning documents and converting the scanned documents in the form of full colour electronic images and/or black and white images into pdf or similar files.
8. 8. A system for uploading, storage and access of verified and authenticated : documentation according to claim 4 in which the duplicating means further includes : a biometric reading device. :
9. 9. A system for uploading, storage and access of verified and authenticated documentation according to claim 8 in which the biometric reading device no comprises a finger print reader and/or a finger vein image reader. -. = -
10. 10. A system for uploading, storage and access. of verified and authenticated documentation according to claims 8 and 9 in which the duplicating means further So includes a camera or web-camera capable of capturing a digital image of the SIE individual's face, ° : : !
11. 11. A system for uploading, storage and access of: verified and authenticated documentation according to any of the above claims in which information captured is compared to and verified against one or more independent databases.
12. 12. A system for uploading, storage and access of verified and authenticated documentation according to any of the above claims which includes physical identification of a person, supervision of the data capture and document

    " duplication, and authentication of the documentation prior to transmission thereof to the database, by an accredited person.
13. 13. A system for uploading, storage and access of verified and authenticated documentation according to claim 12 in which the accredited person is a Commissioner of Oaths.
14. 14. A system for uploading, storage and access of verified and authenticated documentation according to claims 12 and 13 in which authentication by the accredited person requires insertion of a secure dongle into the system.
15. 15. A system for uploading, storage and access of verified and authenticated documentation according to claim 1 in which the remote terminal includes a computer terminal having an internet connection and a finger vein image and/or fingerprint reader.
16. 16. A system for uploading, storage and access of verified and authenticated -

    . documentation according to claim 1 in which. the remote terminal includes a . : Co computer terminal having an internet connection and/ or a card reader. oo oe
17. 17. © A system: for uploading, storage and access .of. verified and authenticated + - - © + documentation according to claim 16 in which an accredited person receives the ~~: card from the person being identified and operates the card reader.
18. 18. A system for uploading, storage and access of verified and authenticated LE documentation according to any of the above claims in which a request for verification submitted to the system by an authorised user resuits in the server generating a one-time password in the form of an sms, mms or the like, sent to the cellular telephone or like device of the person being identified, by messaging technology, the stored information only being released upon inputting of that one- time password by the authorised user.

    : v. HEY pr hg IOV /0¢5,

    8

    ’.
19. 19. A system for uploading, storage and access of verified and authenticated documentation according to claims 1 to 17 in which a request for verification ’ submitted to the system requires taking of a biometric reading and validation thereof prior to release of the stored information to the authorised user.
20. 20. A system according to any of the above claims in which certain documentation is automatically up-dated by the system, the system receiving up-to-date documents from one or more independent databases when these databases generate the relevant documents.
21. 21. A system according to claims 11 and 20 in which the independent databases comprise one or more of the Department of Home Affairs, South African Fraud Prevention Service database, deeds office databases, South African revenue ‘services databases, Companies and Intellectual property registration Office : databases, credit bureau databases and the like databases. Ch oo
22. 22. A secure identification card for use with a system according to any of the above EET 1 claims which includes a photograph ‘or the like image of the person identified, a - PE oe ©. 7. unique identification number and a magnetic strip or the like electronically readable: - =. -

    SL . element, the card providing a means for initially identifying the individual as him or : He i. herself or as a representative of a juristic entity, and thereafter for:accessing. .:": CEE © + ‘documentation stored on a secure database for the purpose of verifying the identity - ~~ : - Co : ~ - of the person or entity upon the card being read by a card reading device of an o authorised user. Dated this 17 dayof September, 7 MORRISON FORSTER INC. APPLICANTS’ PATENT ATTORNEYS