NZ528631A - Securities verification system - Google Patents

Abstract

A lien verification system comprises at least one computer; a means to extract details of a plurality of selected securities that have already been registered on a government registry using one or more of the keys; a means of using at least a portion of the selected securities details as a key to obtain further information from one or more other datasources; a means of comparing at least a portion of the details of the selected securities with at least a portion of the information from the other datasources to identify discrepancies; a means of storing the results of the comparison in a datastore; and a means of notifying an interested party of at least one the discrepancies. The one or more of the keys are i) a secured party identifier, ii) a creditor identifier, iii) a security identifier and iv) a debtor identifier. Patent of Addition Number 548758

Description

Please return form bv mail to: Intellectual Property Office New Zealand PO Box 30 687 Lower Hutt New Zealand 52863 You can confirm the details of registered Intellectual Property at www.iponz.govt.nz IP number/s: Current Owner: 4tAJ f-{ LjC?_ SYDM Your reference: Patents Act 1953 -Office use only- Patent No. 5 - Complete Specification TV&SS I , / l/i o[ol Intellectual Property Office of N,Z.— 2 2 DEC 2004 RECEIVED (*) No.

Date: (a;.

S&.OC.!.T y.... yf.hlA.£>..XT I (b) ....hiU.IZ'S. hereby declare the invention, for which I (ef-we) pray that a patent may be granted to me (or us), and the method by which it is to be performed, to be particularly described in and by the following statement (c) continue application on page 2 ( Signature Date ,0tn/i xj QH Total Fee Paid NZ$ /y 1^1 O.S Telephone ~C^>01 Email AU /g) (M fJTOi?Uj£& Credit card - Please complete Credit card authorisation Direct Debit - Please provide Customer ID Number Customer Number o CjO> . Cheque - Made out the Ministry of Economic Development Your receipt will be automatically emailed to you. Please tick this box if you wish to receive a receipt by post Continued over...

For assistance completing this form please call 0508 4 IPONZ (0508 447 669) COMPLETE SPECIFICATION Dated 20 December 2004 I, RYAN HURSTON, a New Zealand citizen, of 15 Manuka Road, Waiheke Island, Auckland, New Zealand, do hereby declare to be the first and true inventor of the invention for which I pray 5 that a patent may be granted to me, and the method by which it is to be performed, to be particularly described in and by the following statement.

TITLE OF THE INVENTION SECURITY VERIFICATION SYSTEM II CROSS-REFERENCE TO RELATED APPLICATIONS New Zealand provisional patent application No. 528631 filed 01/10/2003 Background of Invention The New Zealand government maintains a public registry called the MVSR (Motor Vehicle Securities Registry) that contains details of security interests registered against licensed road vehicles such as cars, motorcycles, and trucks etc. The Government is now introducing a new public registry called the PPSR (Private Property Securities Registry). This registry will contain 20 details of security interests registered against all private assets such as vehicles, boats, appliances, company shares etc. This new registry will come into effect in mid 2002 and will require security interests to be migrated from the MVSR to the PPSR. After this migration has taken place, the MVSR will be de-commissioned. The responsibility for this migration lies with the security interest holders (creditors) themselves. The Government has not provided a facility for this 25 migration and has suggested instead that creditors use 3rd party agents to undertake the migration. OnTap Information Ltd is one such agent and has developed a system and method to affect this migration in a quick and efficient manner.

The new PPSR legislation also requires that securities be updated to ensure that the collateral/asset 30 is correctly described. Furthermore, the PPSR requires that securities must contain some additional information. Without accurate data and the additional data, the security will be deemed misleading and therefore invalid. There is also an ongoing obligation for creditors to ensure the securities within the PPSR stay accurate. Hence the need for ongoing validation over time. The current invention undetakes this function by automatically performing checks of the data contained in the 35 security to identify any problems, conditions, data discrepancies, change in status regarding the asset, debtor, of creditors. The checks are conducted 1 or more times over a given period, the NZ528631 Complete Patent Specification Page 1 6/7/06 frequency can be determined by the Creditor or owner of the security. The results of the check can then be notified to the Creditor (or other interested party) in a report containing the status of all securities checked or on a security by security basis. One option is to send an electronic message (eg. and email) which conatins a hyperlink to web page that displays the results of the check and 5 provides a means for the recipient to select new data provided, or manually enter new data, with which to update the security to improve its accuracy etc. The web site system would then perform an amendment of the security directly with the PPSR. The web site system could also send a notification of these amendments to other interested 3rd parties (eg. the debtor, or the Government). Another option is to have the system automatically make the required changes with or without a 10 followup notification to interested parties.

For example, a security is registered against a vehicle using the vehicle's registration plate as the key asset identifier. If the vehicles registration plate is changed (see the section entitled Multiple Plate Problem) then a person searching for a security on the vehicle using the vehicles new and 15 current plate, would not find the security and would rightly assume that the vehicle was unencumbered. The creditor could loose their rights to repossess the vehicle since the creditor was negligent in not ensuring the security data was up to date and making the security easy to find.

It is therefore also very important to have the security contain other accurate vehicle identifiers 20 like VIN and Chassis numbers to make the security searchable and valid. These numbers are long alphanumeric numbers which are often mis-read and mistyped (again refer to the Multiple Plate Problem below). The current invention also addresses this issue.

There is also a requirement for the security to correctly identify the Debtor (person owing the 25 money, or the person who owns the asset to which the security applies). If the Debtor is a natural person, then that person's full legal name and date of birth is required. This information can be very difficult to obtain. If the Debtor is an organization, then the organizations full legal name and date of incorporation and company number is required. The current invention makes it much easier to obtain this information as well.

Finance companies must insist that any vehicle they finance is to have insurance on it. This is required to protect the financial and real assets of the finance company and that companies shareholders investment. However vehicle insurance is invalid if the vehicle is on the road unregistered or unlicensed, or does not have a current safety inspection certificate. Therefore it is 35 important for finance companies to know as soon as possible when these certificates etc. have expired and to be able to contact the Debtor or vehicle owner to ask for this to be remedied.

NZ528631 Complete Patent Specification Page 2 6/7/06 Updating the security data and obtaining the additional data is not a trivial matter and hence the need for the current invention to facilitate this.

Furthermore, there are some creditors with tens of thousands of security records which must be migrated, or registered with the PPSR. There are two ways to do this. One is manually via a web site. This requires direct human involvement and data entry which can be slow, costly, and prone to typing errors. The other method is via a computer to computer interface called the 'G2B Interface'. This method allows for direct data transfer and is faster and more accurate. However a 10 number of creditors are small car dealers and finance companies who do not have the expertise, funds or desire to build the complex G2B interface. As such they must use a 3rd party intermediary to affect their registrations via the G2B. The present invention provides such a facility.

The new PPSR has some limitations on how securities can be searched or accessed for 15 modification, deletion or amendment. The full details of a particular security can only be directly obtained by using a unique security identifier called an FSID. This number must be recorded by the Creditor and Debtor along with a user ID, password or PIN in order to make changes or dispute the security. These FSIDs, PINs and user Ids are assigned by the PPSR system and comprise random numbers and letters which are very difficult to remember. There is a need to record these 20 details and provide an easy method to search and retrieve these identifiers using some rational locator such as the license plate of the secured vehicle, or the debtors name. The current invention provides for this.

Finance companies often find that a client will stop making payments on a vehicle loan. It may be 25 some weeks or months before the secured party (finance company) notices this and takes action to repossess the vehicle. By this time the vehicle has usually been sold, and may have actually changed hands several times. This makes it very difficult to locate and recover the vehicle. This invention seeks to minimise these problems by periodically checking to see if the ownership of a specific vehicle has changed during the term of the loan, and advise the finance company of this 30 fact as soon as possible. This will give the finance company advanced notice, and more time to take action to recover the debt or the vehicle.

Multiple Plate Problem Other countries refer to the number plates attached to a car as a 'license plate'. This is because the plates are licensed to a person and must be renewed each year with a sticker attached to them.

NZ528631 Complete Patent Specification Page 3 6/7/06 These license plates are often moved from vehicle to vehicle as a person buys and sells cars. In New Zealand number plates are referred to a 'registration plates' because they are issued only once when the vehicle is first registered as entering the NZ fleet. The plates are registered to the vehicle and are not linked to a person as they are in other countries. The plate generally stays with the 5 vehicle.

In many countries every vehicle is given a unique Vehicle Identification Number (VIN). This is assigned by the manufacturer and includes details of the make, model, location of manufacture, year etc. This makes it very easy to identify a vehicle even if its registration or license plates have 10 been removed or changed. This is why the linking of a plate to a person is not a problem because the VIN can be used to track the vehicles history and legal status.

In NZ, only vehicles which entered the country after 1995 were assigned VINs. However the VINs used in NZ do not comply with the standard numbering codes used in other countries. This makes 15 it difficult to extract any useful information about the vehicle from the VIN. The concept (and importance) of VINs are still not fully understood by many people. And the level of care when reading and transcribing these numbers is poor. VINs are long and complex numbers comprising a mixture of 17 numbers and letters, and confusing the following characters is common: Q & O & 0, 5 & S & Z, I & 1 etc.

This is where NZ has a unique problem with the identification of a vehicle and obtaining the histories of same. The vehicle's plate number is the identifier most commonly (and most accurately) used to attach events like unpaid debts & securities, damage, ownership and stolen flags to. If the vehicle's plate is to change, then the history and events attached to that vehicle can 25 disappear.

In NZ a vehicle's plates can/will be changed under the following conditions: • a plate is damaged in an accident 30 • a plate is lost • a plate is stolen • a personalized plate is assigned or removed from a vehicle • a vehicle is de-registered NZ528631 Complete Patent Specification Page 4 6/7/06 Once a plate has been removed from a vehicle, it becomes very difficult to determine the identify, and full history and legal status of the vehicle. This is especially true if the vehicle was brought into the country prior to 1995 and does not have a VIN.

Here are some particular scenarios: Scenario 1: A person obtains a loan to buy a pre-1995 vehicle. The finance company registers a security against the vehicle's original plate (say 'ABC 123') in the NZ Government's Motor Vehicle Security Registry (MVSR) or the Personal Property Security Registry (PPSR). Since the 10 vehicle is a pr-1995 vehicle it does not have a VIN number, so no other unique identifier is registered.

At some stage later, the person applies for and attaches a personalized plate to the vehicle (say 'GOOD1').

In New Zealand there is no clear mechanism or requirement in law to update the MVSR or the PPSR registry with the new plate. Therefore a person searching the vehicle's current plate 'GOOD1' would be unaware of the 'hidden security' registered against plate ABC123.

Scenario 2: In NZ it is possible to have the registered ownership of the vehicle changed into another persons name without the current owners permission, and without the new owner showing any identification. The registered owner can then request new plates for his new vehicle, citing the previous ones were lost, stolen or damaged. During the change of plate process, no check is done on the old plate to see if the vehicle was reported stolen. Once the plate has been changed, the 25 vehicle effectively disappears from the police since there is no mechanism or requirement of law to advise the police of a vehicle's change of plate.

The NZ Government (LTNZ) does have a vehicle checking service called 'Motochek' which links into the police database to see if a queried vehicle is stolen. However, it only uses the vehicle's 30 current plate to see if there are any police interests in the vehicle. Again the vehicle would come up 'clean' because all the vehicle's current and past identifiers have not been used.

For all the above reasons it is clear that all a vehicle's identifiers must be used to query various databases (eg. securities and police etc.) to obtain a true indication of the vehicles history and legal 35 status. The current invention overcomes these long standing issues and short comings by providing a system and method of vehicle checking which uses a vehicles current plate, all past plates, VIN NZ528631 Complete Patent Specification Page 5 6/7/06 and chassis number to perform queries. The invention also undertakes steps to ensure the information collected is also relevant.

There are additional problems which arise when using multiple plates to check a vehicle's status.

This occurs when one of the vehicles past plates is a personalised plate which has subsequently been assigned to a second vehicle. The system envisaged will extract information regarding the second vehicle. This information would be irrelevant and confusing. This would also happen if incorrect VINs had been entered into any of the data sources searched. Hence the present invention incorporates features which analyse the search results and highlights irrelevant data.

The invention is certainly not obvious, given the seriousness of the problem and the complete lack of any action or solution by the Government, law enforcement authorities, finance companies, and specialist vehicle checking companies. All of which have serious vested interests in overcoming the problem.

Objectives of the Invention The following is a list of the things the invention strives to achieve: 1. to update or validate a security by identifying and correcting any errors in the data which may exist (eg. creditors name and address, vehicle's current plate, vehicle's VIN and chassis number, vehicle's description) 2. to add any new data which may be required in the PPSR record (eg. debtor's legal name, debtor's date of birth, company name and registration number, finance statement identifier, e- mail addresses) 3. to identify any conditions which may be of interest to the creditors, debtors, or other parties such as the Government (eg. vehicle is not registered or licensed or does not have a current safety inspection, stolen, different owner that before, multiple secured parties/liens, one creditor has a lower priority than other creditors, current vehicle valuation, vehicle has been damaged, vehicle is not insured, the license plate has changed). 4. to provide an on-line facility for Creditors to manage their various liens and to check the status of secured assets. . to provide a means for creditors to periodically check their PPSR securities for accuracy and validity and update and modify the securities data as required. 6. to provide a easy means to store and search for security identifiers with which to amend or delete PPSR securities.

NZ528631 Complete Patent Specification Page 6 6/7/06 7. 8. to not have to remember security identifiers and passwords but still be able to deal with the security.

Easily obtain a debtor's legal name, address and date of birth, or date of incorporation. 9. To periodically check, analyse and report on conditions relating to the secured asset (eg. becomes unregistered, uninsured, change of ownership).

. Identify in amore timely manner if and when a vehicles ownership has changed thereby alerting parties with an interest in the vehicle to take action to recover it. 11. Alert interested parties that the insurance cover on a particular vehicle may be invalid, and 10 hence the vehicle, and the interests in that vehicle, are at risk. 12. To automatically notify interested parties of any problems or changes in status that have been detected in assets and securities.

Statement of Inventive Step It is the opinion of the writer that the inventive step(s) of this invention are in the way that existing MVSR and PPSR securities are validated, and the security data is confirmed, updated, and reported on. Specifically, using data supplied by the Creditor and/or obtained from the LTNZ (LANDATA) and other databases to verify and update the details of security interests. 20 Automatically analysing the data to identify issues of interest to creditors etc. And generating reports and communicating the results to interested parties either electronically or as paper records.

The invention utilises the data from other government registries to obtain and validate data which has been used to register securities with the PPSR. Specifically the use of vehicle data from the 25 LTNZ such as description and unique identifiers.

The current invention discloses a novel approach and an inventive step over other inventions that also use information from different datasources to ensure accurate database records. However the current invention operates in a fundamentally different way and in a different order to achieve quite a different outcome as follows: NZ528631 Complete Patent Specification Page 7 6/7/06 Definitions In this specification and the attached claims, the term 'lien' and 'security' are used inter-15 changeably and have the same meaning. A security is a legal registered interest in an asset, such as the interest created in the name of a party who lends money to another party to buy an asset (eg. motor vehicle).

In this specification and the attached claims the term 'secured party' and 'creditor' and 'system 20 user' can be used inter-changeably and have the same meaning in certain contexts. These terms refer to a person or organisation that has a security interest in, or is registering a security over, an asset.

In this specification and the attached claims, the terms 'security database' and 'PPSR' or 'PPSR 25 database' are used inter-changeably and have the same meaning. These terms relate to a database that contains details of assets (collateral), details of owners (debtors) of those assets, and parties (creditors) who have legal registered interests in those assets. Such as the description of the asset, the creditor's details, the debtors details, the start and end date for the legal registered interest.

In this specification and the attached claims, the term 'security check' means the checking of a particular asset within a security database.

In this specification and the attached claims, the term 'LTSA database' and 'LTSA' and 'LTNZ database' and 'LTNZ' and 'Motor Vehicle Registry' and 'MVR' and 'MotorCheck' and 35 'Motochek' can be used inter-changeably and have the same meaning. The terms relate to a database containing details of vehicles registered in New Zealand such as the vehicle's current and NZ528631 Complete Patent Specification Page 8 6/7/06 past owners, registration status, license status, safety inspection status, vehicle identifiers and description, odometer readings etc. Data can be obtained form this database using various methods and services such as CDI, NOF interfaces, and Motochek.

In this specification and the attached claims, the term 'MotorCheck' and 'Motochek' means the checking of a particular vehicle within a LTNZ database.

In this specification and the attached claims, the term 'electoral role' means a database or list of names and addresses of people eligible to vote in general elections.

In this specification and the attached claims, the term Creditor Information and User Data can be used synonymously in certain context.

In this specification and the attached claims, the term 'DriverCheck' relates to an online service 15 offered by the LTNZ for obtaining drivers license details such as drivers license holder's name and date of birth.

The term 'Sniff relates to a service that checks the validity of data contained within a security stored on a security database, using data from a completely different source or database.

In this specification and the attached claims, the term 'vehicle' is to be uses in its widest possible sense and includes; any motorised vehicle, or automobile, or commercial vehicle, or motorcycle, or boat, or jetski, or any other transportation device.

In this specification and the attached claims, the term 'Asset' can also relate to a 'vehicle'.

If the definition of any one of the inter-changeable terms are deemed to be narrower than another, then the term with the broadest definition is to be read as implied within this specification and the attached claims.

Explanation of the Invention A preferred form of the system comprises a central server comprising memory and operating under the control of application software. The computer system may have the instructions for operating 35 the computer system encoded as at least one computer program on a computer-readable medium encoded with a computer program, wherein the computer program defines structural and functional NZ528631 Complete Patent Specification Page 9 6/7/06 interrelationships between the computer program and the medium which permit the computer program's functionality to be realised.

The computer readable medium may include, but not be limited, to optical or magnetic storage 5 media such as a hard drive or CD-ROM.

The application software functions interactively permitting exchange of information within the system. The application software may process information using one or more processors , which may be linked by structured communications channels or unstructured communications channels 10 such as the internet. Similarly, the server may include many disparate information storage media which may be linked to the system by structured communications channels or unstructured communications channels such as the internet or wireless links.

Users may communicate with the server using a PC such as indicated at over an Internet 15 connection or other communications channel. Users PCs may be loaded with common software such as HTML or JAVA and the Internet connection may be either dial-up or dedicated. A user may use an equivalent Internet appliance instead of a personal computer. Other equivalent devices may include but not be limited to, for example, phones, facsimile machines, laptop computers, notebook computers, palmtop computers (PALM PILOT), scanners, cameras, modems, 20 communication access, personal computers (PC), PC terminals (NET PC), and network computers (NC). A firewall may be interposed between the user and the server for security purposes.

Alternatively, users may communicate with the server using a radio paging service, electronic data interchange (EDI) or e-mail facilities.

The server communicates with a number of data sources. These data sources include private and government data stored on, for example, CD-ROM, floppy disks or tapes, Internet web sites, databases and computer servers. These data sources may be accessed by dedicated and dial-up telecommunications facilities using e-mail, electronic data interchange (EDI) and/or 30 communications via Internet web sites. The data sources may also be stored locally on CD-ROMs, floppy disks or other digital storage media.

Alternatively, the user may be provided with terminal emulation or Telnet facilities to directly access data sources.

NZ528631 Complete Patent Specification Page 10 6/7/06 Where necessary, the system converts or translates information from one format to another so that information can be collected and distributed using various communications protocols and devices most appropriate to system users and information suppliers. Translations and conversions supported include: • EDI to electronic mail and vice versa, • Electronic mail to facsimile and vice versa, • EDI to facsimile and vice versa.

The system may either communicate with the server in real time or alternatively may extract information in batch mode, or from a web site or other intermediary delivery mechanism.

The invention comprises both a system and a method, individually and together, to achieve the objectives stated above. The system involves the use of at least one computer server and a 15 telecommunications network. Specifically, a computer server connected to the PPSR and the LTNZ (LANDATA) registries, and other private or public databases and datasources in such a manner that the computer server can communicate information with them. The computer server contains a processor and memory. The computer server can also be accessed via a terminal attached to the computer server, and via other devices (such as PC's) attached to the computer 20 server through a telecommunications network such as the Internet.

One means of software to control the operation of the system is defined in the flow chart of figure 1 and/or as described below: Register a New Security from a System Screen A system user can choose to register a new security using a 'register security' button located on one of a number of different system screens within the system. The security so registered will relate to the vehicle that is the subject of that screen. These screens include; (a) an existing Vehicle Information Report screen, or (b) an existing MotorCheck (vehicle details) screen (c) an existing online change of ownership transaction screen, or (d) an existing online sale & purchase agreement (or some other legal document), or 35 (e) an entry within a transaction history screen, or (f) any other screen (or part of screen) that relates to a specific vehicle.

NZ528631 Complete Patent Specification Page 11 6/7/06 (g) an existing security registration screen.

The system will then take the user to a 'Register Security' screen where the details of the vehicle, and/or the debtor, and/or the creditor, and/or the registration date of the security, and/or the expiry 5 date of the security, and/or the term of the security, and/or the amount of the security, have already been extracted from the above mentioned screen(s) and/or the system database and the relevant fields of the security registration are pre-populated with this data.

Register a New Security from the Menu Button The system user will be able to register a security directly without the vehicle being known to the system in any way. This is accomplished by using the 'Register Security Button' ('the button'). The user clicks on the button and is presented with a screen requesting the details required by the PPSR. This will include; selecting an existing secured party ID, or setting up a new secured party 15 ID, entering the debtor's details, entering the vehicle details, and selecting the expiry date for the security.

Alternatively, the system user can opt to extract the relevant vehicle details from an LTNZ database and this data automatically populate the relevant fields. This is achieved by having the 20 system user enter one of the vehicle's unique identifiers (ie. plate number or VIN) and selecting the "use MotorCheck data" checkbox. The system then uses the vehicle's unique identifier to make a query against an LTNZ database. The relevant portions of the returned data are then displayed and/or automatically entered into the necessary fields of the security registration screen. The system user continues to enter the other relevant security data manually as above.

Extraction of Security Data from Other Sources A system user will have an option to supply certain information that will be used as a key to extract data from one or more datasources. This is done prior to the registration or amendment of a 30 security in order to obtain the most accurate information and data, and hence improve the accuracy and validity of the security so registered.

Storing Security Details On-Line Regardless of how the system user began the security registration process (eg. menu button or existing screen) the user will click on a 'submit/process' button and the system will register the NZ528631 Complete Patent Specification Page 12 6/7/06 security with the PPSR. The system will then receive the response from the PPSR and store these details including the FSID, secured party ID, secured party password, and the creditor and debtor PINs, within the system database. The system user will then be presented with a screen containing all the details of the security (however the PINs may be obscured). The system user can then 5 request that a specially formatted security certificate (eg. in PDF) be printed out by the system as a hard copy record. All securities registered through the system by the system user (and other securities the system has given them authority to view) are listed in the system user's Transaction History. The details of any of these securities can be brought up on screen by clicking on a hyperlink within the Transaction History.

Modification of Securities The system automatically records the relevant security ID (FSID), and Secured Party ID numbers and PINs for each security registered through the system. This allows a system user to amend or 15 cancel the security without having to remember these IDs and PINS. Some companies register tens of thousands of vehicle securities every year, so the automatic storage of these Ids and PINs etc. is very handy.

To amend or cancel a security the system user simply logs into their system account, the system 20 user searches for the relevant security through the Transaction History and clicks on the associated hyperlink. The system displays the details of the security on screen (with or without editable fields). The system user then clicks on the 'amend' of 'cancel' buttons and the system automatically extracts the relevant FSID, secured party ID, and PIN numbers from the system database and sends them to the PPSR along with the relevant commands and arguments to process 25 the request. In this way the system user does not have to know the various IDs and PINs for each security. The system instead determines the users authority to deal with the securities through the system user's account login and password, and/or digital certificates or cookies stored on the system user's machine.

Registration of a Sniff on an Existing Security A system user will have an option to extract an existing security directly from the PPSR by clicking on a 'Security Sniff button in the menu. This will display a screen where the system user enters the securities FSID, the secured party ID and password, and Creditor PIN. The system will 35 then retrieve the security details and display them on screen. The screen will also have the relevant 'security sniff fields on it which can be filled out by the system user (as per the instructions NZ528631 Complete Patent Specification Page 13 6/7/06 below), and a button called something like 'register security sniff. When the system user clicks on this button, the system will register the sniff in its database and process the sniff as appropriate. The system will also record the details of the security and the relevant IDs and PINs so that the security can be searched via the system's transaction history and modified later without the user 5 having to remember the Ids and PINs.

File Registrations of Securities and Sniffs The system is also configured to receive a file containing details of securities to be registered or to 10 be sniffed. This file can be in a variety of formats (eg. excel, XML, CSV etc.) the file can be sent to a particular web page/address on the system using the Internet, or may be manually imported into the system by a system user. This file can be received by the system in batch mode or in real time. Each security record within the file will contain data specifying if a security sniff is also to be registered and the options for same (eg. extent and frequency of sniff). The system will then 15 process these securities and the associated sniffs using the same procedures outlined in this document. With this method, the system will have the option of sending notifications or errors in an'error' file in a format such as XML or CSV format for easy reading and processing by a computer. The processing of 'file registration', the associated sniffs, and the sending of notifications can take place in either real time or batch mode depending upon the system users 20 choice or account settings. All securities processed in this manner will be stored within the system database along with the associated security Ids, Secured Party Ids, and Debtor & Creditor PINs.

The 'Sniff' Regardless of how the system user began the security registration process (eg. menu button, existing screen, of file input), the system user will have the option to activate a security 'sniff. This is a feature that will get the system to periodically check the details of a security to ensure its details are accurate and to identify other important issues of concern. The Sniff works by extracting data from one or more datasources, analysing the results to identify issues, and 30 comparing the resultant data with the data contained within a security to identify changes in status of the asset or debtor, data discrepancies, errors, or omissions which could make the security invalid, misleading or otherwise puts the asset covered by the security at risk.

NZ528631 Complete Patent Specification Page 14 6/7/06 Sniff Options The system user will have the option to determine how costly and how thorough the 'sniff will be by choosing one or more of the following data sources to extract data from for the sniff; (a) an LTNZ database, (b) the PPSR database, (c) the system database, (c) the Post Office database, (d) an Electoral Role database, (e) a drivers license database, (f) any other database identified by the system or the system user.

The system user will have the option to choose the time of the first 'sniff and the last 'sniff by 15 selecting from the following; (a) first sniff immediately, or (b) first sniff within 24 hours, or (c) first sniff at a date or time selected by the system user, and (d) last sniff 1 month before the expiry date of the subject security, or (e) last sniff at a date or time selected by the system user.

The system user will have the option to determine the frequency of the 'sniff by choosing one of the following; (a) once every month, or (b) once every 6 months, or (c) once every year, or (d) once per period of time selected by the system user.

Sniff Analysis One or more of the following activities are undertaken as part of each Sniff. 35 1. Identifying if the subject security is still valid by: NZ528631 Complete Patent Specification Page 15 6/7/06 (a) Comparing the securities registered expiry date with the current date. If expiry date is earlier than current date (by a certain amount) then the security has expired. (b) Using the term of the loan/security and the security registration date to calculate the 5 security expiry date and comparing this to the current date. If calculated expiry date is earlier than current date (by a certain amount) then security has expired. (c) Seeing if the security has been identified by the Creditor as having been discharged. 2. Confirming the accuracy of the debtor's details in the subject security by: (a) Comparing the debtor's present name, address, and/or other contact details with that obtained from the LTNZ database, and/or a NZ Post database, and/or a NZ electoral role database, and/or drivers license database, and/or database of registered 15 companies. 3. Confirming the accuracy of the creditor's details in the subject security by: (a) Comparing the creditor's present name, address, and/or other contact details with that 20 obtained from the PPSR database, and/or a NZ Post database, and/or a NZ electoral role database, and/or the system database, and/or database of registered companies. 4. Confirming the accuracy of the vehicle's details in the subject security by: (a) Using the vehicle's registration plate number and/or VIN used in the security to extract one or more of the following details from an LTNZ database, (i) the vehicles year, make, model, sub-model, colour (ii) the vehicle's current registration plate number, VIN and chassis number, and (b) Comparing those details with the similar details in the security and identifying any differences.

. Determining if the ownership status of the vehicle has changed from that in the subject 35 security by: NZ528631 Complete Patent Specification Page 16 6/7/06 (a) Using the vehicle's registration plate number and/or VIN used in the security to extract the vehicle's current owner name, address, and ownership status details from an LTNZ database, and (b) Comparing those details with the similar details in the security and identifying any differences. (c) Identifying if the date of latest ownership is after the date that the subject security was registered or amended. 6. Determining if other relevant securities have been registered against the same vehicle by: (a) Using the subject vehicle's registration plate numbers, and/or VIN, and/or chassis number used in the security to extract details of securities using those vehicle identifiers from a securities database. (b) Comparing the year, make and model of the vehicle in any securities found with the similar data in the subject security to determine if the securities found relate closely with the subject vehicle. (c) Comparing the expiry date of any securities found with the current date to determine if the securities found are still in force. (d) Comparing the registration date of any securities found with the registration date of 25 the subject security to see if they have priority over the subject security. (e) Determining if any securities found are of importance by selecting those securities which; (i) relate closely enough to the vehicle in the subject security, and (ii) have a registration date before that of the subject security, and (iii) have an expiry date later than the current date. 7. Determining if the vehicle's finance insurance may be void and the vehicle at risk of loss 35 by: NZ528631 Complete Patent Specification Page 17 6/7/06 (a) Using the vehicle's registration plate number and/or VIN used in the security to extract the vehicle's registration, license and safety certificate details from an LTNZ database, and (b) Comparing the expiry dates of the vehicle's registration, license and safety certificates with the current date to determine if any of them have expired or are about to expire within a particular period.

Notification of Sniff Findings Once a Sniff has been completed, the results are stored within the system and also notified to the system user via either an email or a data file.

Any email message will contain a hyperlink to a screen within the system that either allows the 15 system user to log into their account, or alternatively displays a 'security details screen' which contains the original details of the specific security in question along with any errors, discrepancies or other points of concern found by the Sniff. The screen will also display the alternative data that the system user may choose to amend the security with. A combination of checkboxes or user editable data fields could be used by the system user to select what data to use 20 in any amendment, such as that shown in Figure 2. The system user may also use this screen to change the extent and frequency of future sniffs. The amendment can be performed by clicking on an 'update security' button. The system will then send the updated data to the PPSR (along with the stored FSID, secured party ID, and Debtor PIN) and store the results returned by the PPSR within the system database. Once the update is complete the user will be presented with a screen 25 showing the updated security details which can be printed as a hard copy record.

As an alternative, should the system determine that some action may be required on a particular security, a hyperlink flag will be displayed next to that security within the system users Transaction History. For example, if the updating of a security resulting from a sniff has not been 30 completed. Activation of this hyperlink will take the user to the 'security details screen' mentioned above where that required action can be fulfilled.

When a security is updated, the system may optionally send a notification or confirmation message to other interested parties such as the Creditor, debtor, or Government departments.

NZ528631 Complete Patent Specification Page 18 6/7/06 Debtors Name, Address and Date of Birth Details A security requires accurate information about the Debtor in order for the security to be valid. In the case of a Debtor who is a natural person, the system will allow a system user to enter a Driver 5 License number into a system screen, or provide the Driver License number to the system via a data file, and the system will use that as a key to extract the driver license holders name, address and date of birth from a Driver License Database or an LTNZ database such as that used by the LTNZ 'DriverCheck' service. This data will then be displayed and automatically entered into the relevant fields or automatically used in the verification (sniff) and for a registration or amendment 10 of a security. As with all data fields mentioned previously, the user will have the opportunity to overwrite or de-select the Debtor's data so obtained, prior to registration or amendment of a security.

One means of software to control the operation of the system is defined in the flow chart of figure 15 2. Another means of software comprising the following steps (not necessarily in the order stated): 1. Obtaining as much information as possible about the existing securities. This information may come from the PPSR or from a Creditor directly. As a minimum this information will include one of; the vehicle's plate number, chassis number and/or VIN at the time the lien was registered, the date the lien was registered, and possibly the name of the Debtor. 2. Identify which securities are to be checked by obtaining their FSID and PIN numbers. This information may be provided by the Creditor in a data file, manually one at a time, or may be extracted from the systems storage itself. 3. Or, to search and retrieve all securities relating to a particular Creditor by doing a "Creditor Security Search" on the PPSR. 4. Identifying the extent and frequency of security checking by obtaining said information from the Creditor; in a data file or by manual data entry, or by extracting the information from the system itself. 5. Using said checking extent and frequency information to determine when and how to check each security by comparing the system's current date with the last date that security was last checked or last amended or registered to determine if a check is to be performed. 6. Identifying which of the securities to be checked are still valid by: 35 7. Comparing the securities registered expiry date with the migration current date. If expiry date is earlier than current date (by a certain amount) then security has expired.

NZ528631 Complete Patent Specification Page 19 6/7/06 8. Using the term of the loan/security and the security registration date to calculate the security expiry date and comparing this to the current date. If calculated expiry date is earlier than current date (by a certain amount) then security has expired. 9. Identifying if more that one security is registered by the same Creditor against the 5 same vehicle and they are fundamentally the same security interest.

. Identifying if the secured vehicle still exists by seeing if the vehicle still exists in LAN DATA. 11. Seeing if the security has been identified by the Creditor as having been discharged. 12. Identifying any PPSR data which may need adding or updating by: 13. Obtaining and confirming the Creditors information by; 14. Comparing the Creditors present name, address, and contact details that may be stored within the system with that recorded in the PPSR record.

. Comparing the Creditors present name, address, and contact details with that 15 recorded in the Companies Office database. 16. Obtaining and confirming the details of the vehicle. 17. Using the plate # presently assigned to the secured vehicle and obtaining the current details of the vehicle by: 18. Supplying the LTNZ LANDATA system with the original plate # and/or VIN (as shown in the lien) and the date that that plate was actually on the vehicle (the lien registration date). 19. Obtaining from LANDATA details of all vehicles that have ever been assigned that plate, and the plates currently assigned to those vehicles, and the date at which those current plates were assigned. This is currently called an LTNZ "Vehicle History of Plate" transaction.

. Matching the vehicle description and/or lien registration date (supplied by the Creditor or within the PPSR security) to the details returned by LANDATA to identify the correct vehicle and its latest plate. 21. Obtaining the latest vehicle and ownership data from the LTNZ by conducting a "Motochek Query" or other LTNZ vehicle query by supplying the latest vehicle plate # and/or VIN to LANDATA. 22. or, obtaining the latest vehicle and ownership data from the LTNZ by conducting a Motochek "Owner as of Date" transaction and obtain details of the vehicle's current and past owners,, vehicle description, currently assigned plate, VIN etc.

NZ528631 Complete Patent Specification Page 20 6/7/06 Wherein the data obtained from at least one of the MVSR and LANDATA is used as a key to extract data from other data sources; Wherein said other data sources include at least one database selected from the following group: (a) a vehicle valuation database or an address database or an insurance database or a 5 damage and repair history database. 23. Identify other relevant securities against the vehicle by; 24. Using the vehicles present and past plates, and/or VIN, and/or chassis # from the LTNZ to do a comprehensive PPSR search to retrieve all matching securities.

. Identifying which of the matching securities are still valid by: 26. Comparing the securities registered expiry date with the current date migration date. If expiry date is earlier than current date (by a certain amount) then security has expired. 27. adding the loan term to the lien Using the term of the loan and the security registration date to calculate the security expiry date and comparing the resulting date to the current date. If calculated expiry date is earlier than current date (by a certain amount) then security has expired. 28. Identifying if more that one security is registered by the same Creditor against the same vehicle and they are fundamentally the same security interest. 29. Identifying if the secured vehicle still exists according to the LTNZ LANDATA system, by seeing if the vehicle still exists in LANDATA.

. Seeing if the security has been identified by the Creditor as having been discharged. 31. Discarding any of the matching securities which are deemed to have expired or are invalid 32. Obtaining and confirming the Debtor's information. 33. Determine who the Debtor of the security is by matching the vehicles past owner 30 names and their dates of ownership with the date that the security was registered. The Debtor could then be presumed to be the vehicle owner as of the date of the security registration. 34. or, entering the known Debtor's drivers license number into the system and using it to search the LTNZ driver license database to retrieve the Debtor's full legal name and date of birth. This could be done using the LTNZ's 'Driver Check' service. . or, having the system user enter the Debtor's name directly into the system.

NZ528631 Complete Patent Specification Page 21 6/7/06 36. using the Debtors name so obtained to confirm the Debtors legal name and spelling, and obtain the Debtor's latest known address from an address database such as that supplier by New Zealand Post or the Electoral Role. 37. using the Debtors name so obtained to confirm the Debtors legal name and spelling, 5 and obtain the Debtors date of birth from the LTNZ Drivers License database or the NZ Births, Deaths & Marriages database. 38. or, in the case where the Debtor is a non-individual (eg. company or organization),get the Debtors legal organisastion name and registration number from the New Zealand Companies Office by entering the known Debtor's company name and/or company registration number into the system and using it to query the NZ Companies Office database to retrieve the Debtor's full legal name, company registration number, current addresses and contact details, names and addresses and contact details of the company's directors etc. This could be done using the 'B2G' company search query'. 39. or, a system user could directly enter the known Debtor's company name and/or 15 company registration number and/or address and contact details directly into the system. 40. or, a system user could select and query a company name or persons name by clicking on one of the names contained in the, PPSR or LTNZ data. 41. Identify any points of concern, or data discrepancies which could effect the accuracy or validity of a security. 42. using the vehicle description, vehicle plate, and/or VIN, and/or chassis #, and/or the present owners name to determine if the vehicle is insured or not from an insurance datasource. 43. using the vehicle description, vehicle plate, and/or VIN, and/or chassis #, and/or the present owners name to determine if the vehicle is of interest to the police from an police datasource. 44. using the vehicle description, vehicle plate, and/or VIN, and/or chassis #, and/or the present owners name to determine if the vehicle has any problems from a customs datasource. 45. Analysing and comparing the like data from all data sources and identifying conditions of interest or discrepancies such as: 46. vehicle VINs are different 47. vehicle chassis #s are different 48. vehicle's lien plate number in the PPSR record is different from the vehicle's current plate number in the LTNZ record.

NZ528631 Complete Patent Specification Page 22 6/7/06 49. vehicle descriptions (make, model year, colour) are different 50. Identify if vehicle is presently unregistered 51. Identify if vehicle is presently uninsured 52. Identify if the vehicle is presently registered as stolen 5 53. Identify if the vehicle is presently unlicensed 54. Identify if the vehicle is presently out of WoF or CoF 55. Identify if the vehicle's present owner is different than the Debtor 56. debtors details do not match any of the past owners of the vehicle. 57. Identify if other Creditors have a security interest on the vehicle 10 58. Identify if the Creditor is not the priority creditor 59. the present market value of the vehicle is lower than the remaining amount of debt on the vehicle (if known). 60. Identify if the vehicle has had a change of ownership since the date the security was first registered and/or last amended. 61. Record any conditions of interest or discrepancies in the system for later reporting. 62. Advise the Creditor (or other interested parties) of the conditions of interest or discrepancies so found by; 63. Preparing an email message with an appropriate subject line and body text that indicates 20 the nature of the email message and the vehicle or security to which the message applies.

For example, the subject line could be "Problem with Security # 12345678 on 1995 Mitsubishi Magna - plate ABC 123." 64. Including in the body of the email a hyperlink to a web page that contains the details of the security and the problems found. 65. Sending said email message to the Creditor (or other interested parties). 66. Creating a web page to facilitate the correction, an on line migration registration or amendment of a security on the PPSR by: 67. Displaying the various data obtained by the system in a manner that makes it clear 30 where the data originated from. 68. In the case where like data differs, provide a means for a person to select which data is to be used for subsequent PPSR transactions. This could be by the means of activating checkboxes next to the data to be used (for example see figure 2). 69. In the case where like data differs or is missing, provide a means for a person to 35 override existing data and/or add new data by entering the data into a text box. 70. Displaying a summary of all selected or entered data to be used.

NZ528631 Complete Patent Specification Page 23 6/7/06 71. Recording all confirmed or updated information in a record and upon activation of a "Submit command", submitting the data as a 'final' security interest to the PPSR online. This could be done through the real time PPSR G2B computer interface. 72. Should a security interest not be complete, or data is still to be confirmed by the 5 Creditor or another party, then complete an on-line 'pending' security interest in the PPSR. Again this could be done through the PPSR G2B computer interface. 73. Alternatively the system could decide that it has all the required information and will automatically amend or discharge the security itself without a system user's input. 74. All details of a PPSR transactions performed (pending or final) are recorded in the computer system as part of a transaction history Figure 3. These records can be searched, sorted, and viewed on-line by a creditor or debtor who is party to the security. The sort criteria will include; by FSID, by plate, by Debtor, by security status, or by security registration date.

These records will contain a flag to identify if the record has been submitted as a 'final' or 'pending' PPSR security and in the case of a 'pending' registration, will highlight any information which must be confirmed or added. 75. All records within the transaction history will have hotlinks to allow a Creditor to perform real time or batch transactions or to obtain additional information regarding the security such as: 76. Perform a search of the related PPSR 'final' or 'pending' transaction. 77. Perform a credit check on the Debtor 78. Obtain details of the last related LTNZ and/or MVSR and/or PPSR query 79. Obtain details of all conditions of interest and discrepancies recorded 80. Conduct a new 'full query'(ie. an update) of the security which will include: 81. queries of the LTNZ, MVSR, PPSR and any other databases which contain information relevant to the security, 82. performing an analysis of all data to identify conditions of interest and discrepancies 83. Amend or delete the security, or register a new related security, with the PPSR on-line. 84. The transaction history can be down loaded as a file in various formats including XML. 85. The system can be programmed to periodically (and automatically) conduct full security queries as described above and report the results to Creditors and other interested parties. These reports may happen in every event or only when certain conditions of interest or discrepancies are noted (eg. vehicle is unregistered, reported stolen or uninsured).

NZ528631 Complete Patent Specification Page 24 6/7/06 Reports The system will be able to generate a number of reports which are deemed of interest to Creditors, Debtors, and other 3rd parties such as the Government or the migration agent. These reports contain 5 information such as: 1. securities where major data has changed 2. assets where a particular creditor has lower priority than another creditor 3. securities where the asset is stolen, unregistered, or uninsured. 4. A valuation & status report of the secured asset . Any other condition of interest or discrepancy described above 6. A list of securities which resulted in a data error or inconsistency, or an alert condition. Alternative Embodiments There are several alternative implementations of the invention which are anticipated. These include: 1. how data is extracted, and what data is extracted from the LTNZ 2. whether the checking process takes place in real time on a security by security basis, or in bulk as a batch process 3. whether information is extracted from various datasources and databases in real time or via overnight batch processes. 4. what and how information about securities is obtained from Creditors or the PPSR. 5. This may include a Creditors computer sending (in real time) an electronic file/request that contains all the details required by the system to conduct security check on one or more particular securities. The system may then conduct that check in real time or as a batch process, and return the results to the computer electronically as well via an email or XML file in real time or batch mode.

Another embodiment of the invention (not necessarily in the order stated) is: 1. Enter a plate #, VIN #, and/or chassis # 2. Use the identifier(s) above to search and retrieve securities data from the MVSR and/or PPSR.

NZ528631 Complete Patent Specification Page 25 6/7/06 3. Use the plate number(s), and or VIN number(s), and the date(s) of registration of the securities retrieved to search and retrieve other data from the LTNZ database. This step could use the LTNZ's Motochek query called the "owner as at date" transaction. 4. Store the MVSR, PPSR and LTNZ data which will include; the vehicle's identifiers (eg. current assigned plate, VIN and chassis number, make, model, year, colour), the vehicle's current and past registered owners, the vehicles registration status, debtor and creditor information.

. Display the data in a manner so it is clear where the various data originated from (figure 2). 6. Compare like data obtained from the various data sources (eg. compare plate number in PPSR security against the vehicle's current plate number from the LTNZ). 7. Clearly highlight any discrepancies which exist. 8. In the case where like data differs, provide a means for a person to select (eg. via a check box) which piece of like data is to be used for subsequent transactions such as describing an asset for the registration or amendment of a security on the PPSR (figure 2). 9. In the case where data differs or is missing, provide a means for a person to override the data and/or enter a new piece of data (eg. via a text entry box).

. Enter a drivers license number. 11. Use the drivers license number to search and retrieve data from the LTNZ drivers license database (eg. full legal name and date of birth of the drivers license holder). This step could use the LTNZ's 'Driver Check' service. 12. Enter a company name or company registration number. 13. Use the company name and/or company registration number to search and retrieve data from the Government's 'Companies Office' database (eg. full legal name of company, company registration number, company addresses, names and addresses of company directors, date of incorporation etc.). 14. Use the company name and/or company registration number or the drivers license name to search and retrieve data from a Credit Checking Datasource such as that provided by Baycorp Advantage. 15. Alternatively a person could select a company name or persons name by clicking on one of the names contained in the MVSR, PPSR or LTNZ data. 16. Store the data. 17. Compare the data with like data from the MVSR, PPSR and/or LTNZ queries (eg. compare 35 company name or drivers license holder name with the current or past registered owners of the vehicle) NZ528631 Complete Patent Specification Page 26 6/7/06 18. Provide a means for a person to select (eg. via a check box) which piece of like data is to be used for subsequent transactions such as describing the debtor in the registration or amendment of a security on the PPSR. 19. In the case where data differs or is missing, provide a means for a person to override the data and/or enter a new piece of data (eg. via a text entry box).

. Display a summary of the data selected or entered by a person to be used in a subsequent transaction such as the registration or amendment of a security on the PPSR. 21. Upon activation of a 'Submit to PPSR' button, send the selected data to the PPSR in real time and process a PPSR security registration or amendment as specified by the person. is List of Figures Figure 1 - is a flowchart of one possible process followed by the User or the System.

Figure 2 - is a sample screen showing the System User's ability to view security data obtained from different sources, and to select what data to use for the security amendment.

PPSR Change-of-Ownership If the legislation demands, then the system may implement a change of ownership feature that advises the Creditor, Police, or other 'interested parties' when an asset has changed hands. This is 25 similar to an on-line police book feature.

The system will have to determine when an asset has changed hands. This is only likely to happen when an object is bought or sold by an intermediary agent like a Pawnbroker or an Auctioneer. Unlike vehicles that are always in the public eye, there is no efficient means to track down objects 30 that reside in households, so repossession of secured goods is very difficult. Hence it is very unlikely that the public will perform checks on these goods to protect themselves from repossession. And likewise, it is unlikely that the public would feel obliged to notify of a sale.

Notify & Coordinate Interested Parties NZ528631 Complete Patent Specification Page 27 6/7/06 There is a need to alert all interested parties that a security is to be deleted, subordinated, or changed in some other manner, and to obtain approval from said parties before the change is made. This function may be part of the PPSR, however if not, then there is an opportunity to develop a service whereby all interested parties (Creditor, Debtors, Secured Parties, Secured Groups) arc e-5 mailed a link to a kind of 'chat room' or 'news group' where the details of the FS changes are displayed. Each party must enter their particular PIN to identify themselves as an interested party to the FS. Each party can then take part in the collaborative discussion, or to indicate their approval or disproval of the change. If all parties accept the changes then the amendment takes place via the system, if there is a dissenting party then all other parties are advised of this in the 10 chat room/newsgroup or by e-mail and the amendment is halted. This service will require prior knowledge of the interested parties to a particular FSID and their PINs. This information could be obtained from the PPSR registrar, or could be captured by the system if the original FS was processed via the system.

The foregoing describes a preferred form of the invention. Alterations and modifications as will be obvious to those skilled in the art are intended to be incorporated within the scope hereof, as defined in the accompanying claims and drawings.

NZ528631 Complete Patent Specification Page 28 6/7/06 ABSTRACT A method and system of automatically and periodically analysing a Creditor's security data stored in a Government Securities Registry and notifying said Creditor of any data inaccuracies (or other issues of concern regarding the asset described in said security) and providing a means for said Creditor to undertake a correction or update of said security data to ensure it remains accurate and legally enforceable.

NZ528631 Complete Patent Specification Page 29 6/7/06

Claims (48)

What I claim is.

1. A lien verification system comprising; a) at least one computer; b) a means to extract details of a plurality of selected securities that have already been registered on a government registry using one or more of the following keys; i) a secured party identifier, ii) a creditor identifier, iii) a security identifier, iv) a debtor identifier; 10 c) a means of using at least a portion of said selected securities details as a key to obtain further information from one or more other datasources; d) a means of comparing at least a portion of said details of said selected securities with at least a portion of said information from said other datasources to identify discrepancies; e) a means of storing the results of said comparison in a datastore; f) a means of notifying an interested party of at least one said discrepancies.

2. A liens verification system of claim 1 further comprising; a) a means of analysing at least a portion of said details of said selected securities and at least a portion of said information from said other datasources to identify points of 20 concern, b) a means of storing the results of said analysis in a datastore, c) a means of notifying an interested party of at least one said point of concern.

3. A liens verification system of any one of claims 1 and 2 further comprising a means for a system to submit data to said government registry in order to amend said selected security using one or more of the following methods; NZ528631 Complete Patent Specification Page 30 11/9/06 a) automatically without human involvement, b) upon direction by said system user.

4. A liens verification system of claim 1 wherein said keys are supplied in one or more of the following ways: a) from said system user, b) from a data file, c) from said datastore.

5. A liens verification system of claim 1 wherein the receipt of selected security details is accomplished by extracting said details from one or more of the following; a) a data file, b) said datastore.

6. A liens verification system of claim 1 wherein said means of obtaining further information from said other datasource comprises one or more of the following; a) a means to use one or more of an asset's identifiers contained in said selected security as a key to search a LTNZ database to obtain one or more of the following: i) vehicle description (ie. make, model, sub model, colour and year), ii) current vehicle owner name, iii) current vehicle owner address, iii) vehicle's current registration plate number, iv) at least one of vehicle's past registration plate numbers, v) vehicle's VIN, vi) vehicle's chassis number, NZ528631 Complete Patent Specification Page 31 11/9/06 vii) date of last ownership change, viii) vehicle's registration status, ix) vehicle's license status, x) vehicle's safety certificates status; a means to use a vehicle registration plate number contained in said selected security and the date said selected security was submitted or registered as a key to search a LTNZ database to obtain one or more of the following: i) vehicle description, ii) current vehicle identifiers, iii) current ownership details; a means to use a vehicle identifier and/or vehicle owners name as a key to search an insurance database to determine if said vehicle is currently insured; a means to use a company registration number and/or company name as a key to search a companies office database to obtain one or more of the following: i) debtor company name, ii) debtor company registration number, iii) debtor company address details, iv) debtor company contact details, v) name and address details of debtor company directors; a means to use a debtor's drivers license as a key to obtain debtor legal name and/or date of birth from a driver license database and/or a births deaths and marriages database; a means to use a debtor's name as a key to extract address details from an electoral role and/or post office database; ) a means to use a company name and/or company registration number and/or a drivers license name to search and retrieve data from a credit checking datasource; ) a means to use a vehicle identifier and/or vehicle owners name as a key to search a police datasource to identify if said asset is stolen or not; NZ528631 Complete Patent Specification Page 32 11/9/06 i) a means to use an asset identifier and/or description as a key to search a valuation datasource to obtain a market value for said asset; j) a means to use one or more asset identifiers including at least one past registration plate to query a personal property securities register to obtain details of any additional securities lodged against the asset; and store at least a portion of said information in said datastore.

7. A liens verification system of claim 1 further comprising a means to obtain further information from one or more of the following; a) directly from said system user, b) from said datastore, and store at least a portion of said further information in said datastore.

8. A lien verification system of claim 1 wherein said data discrepancies include one or more of the following; a) a mismatch of asset identifiers between said selected security and at least one said other datasources, b) a mismatch of asset description between said selected security and at least one said other datasources, c) a mismatch of creditor details between said selected security and at least one said other datasources, d) a mismatch of debtor details between said selected security and at least one said other datasources.

9. A lien verification system of claim 1 wherein said other datasources comprise one or more of the following: a) an LTNZ database, NZ528631 Complete Patent Specification Page 33 11/9/06 b) the LANDATA database, c) the LTNZ Motochek service, d) the Personal Property Security Registry (PPSR), e) a motor vehicle securities register, f) the LTNZ drivers license database, g) the LTNZ Drivers Check service, h) said systems database, i) a New Zealand Post database of addresses, j) an Electoral Role, 10 k) New Zealand Companies Office database, 1) a database of registered companies, m) a Births Deaths and Marriages database, n) a database containing insurance policy information, o) a police database, p) a customs database, q) a credit checking database.

10. A lien verification system of claim 1 further including a means to receive and carry out instructions regarding said comparison, wherein said instructions comprise one or more of the 20 following: a) when the first comparison is to take place, b) when the final comparison is to take place, c) the frequency of said comparisons, d) what said other datasources are to be queried for the comparison. NZ528631 Complete Patent Specification Page 34 11/9/06

11. A lien verification system of claim 10 wherein said instructions are received in one or more of the following ways: a) from said system datastore, b) from manual entry by said system user, c) from a data file.

12. A lien verification system of any preceding claim wherein each of said selected securities may have a different set of instructions. 10

13. A liens verification system of any one of claims 1 and 2 wherein said notification of interested parties comprises sending an interested party a record pertaining to said selected security wherein said record contains one or more of the following: a) a security identifier, b) an asset identifier, c) a description of one or more of said discrepancies, d) a description of one or more of said points of concern, e) a hyperlink to a security webpage containing details of said selected security.

14. A liens verification system of claim 13 wherein said security webpage displays one or more of 20 the following: a) at least a portion of the data from said selected security, b) at least a portion of data obtained from said other datasources, c) details of said discrepancies, d) details of said points of concern, e) a means to select certain data, f) a means to manually enter data, NZ528631 Complete Patent Specification Page 35 11/9/06 g) a means to submit said selected data and/or said manually entered data to a personal property securities register as an amendment, h) a means to modify the details of future comparisons.

15. A liens verification system of claim 13 wherein said record is sent to said interested party within one or more of the following; a) an email, b) a data file, c) a printed report. 10

16. A liens verification system of any preceding claim further comprising the means for a system user to log on to said system and be presented with a transaction history comprising a plurality of hyperlinks each corresponding to a particular selected security and wherein activation of said hyperlink will display said security web page.

17. A lien verification system of any preceding claim wherein said interested parties comprise one or more of the following: a) a debtor, b) a secured party, 20 c) a creditor, d) a government agency, e) said system user.

18. A lien verification system of claim 2 wherein said points of concern include one or more of the following: a) the asset has changed ownership since the date the security was first registered, NZ528631 Complete Patent Specification Page 36 11/9/06 b) the asset has changed ownership since the last amendment of the security, c) a license and/or registration and/or safety certificate has expired, d) a license and/or registration and/or safety certificate is about to expire within a particular period, e) the presence of other securities against the asset, f) the lack of valid insurance on the asset, g) the asset is identified as stolen and/or of interest to police, h) the asset has customs problems, i) a vehicle's current owner name is different than the security debtor name, j) the security is subordinate to a different creditors security, k) the market value of the asset is below the remaining amount of debt owing in the security.

19. A lien verification system of any preceding claim wherein said asset identifier comprises one or more of the following: a) a vehicle's current registration plate number, b) a vehicle's past registration plate number, c) a Vehicle Identification Number ( VIN), d) a chassis number.

20. A lien verification system of any preceding claim wherein said security identifier comprises_one or more of the following: a) unique security registration number, b) Financing Statement Identification (FSID) number, c) PIN. NZ528631 Complete Patent Specification Page 37 11/9/06

21. A lien verification system of any preceding claim wherein said debtor identifier comprises one or more of the following: a) debtor's drivers license number, b) debtor's name, c) debtor company's registration number, d) debtor company's name.

22. A lien verification system of any preceding claim wherein said creditor identifier comprises one 10 or more of the following: a) creditor's name, b) creditor's company registration number, c) creditor's secured party identifier, d) creditor's password.

23. A lien verification system of any preceding claim wherein said government registry is the Personal Property Security Register (PPSR).

24. A liens verification system of any preceding claim wherein one or more of the actions previously 20 described can take place in real time or in batch mode.

25. A liens verification system of any preceding claim wherein said system user can be a person or a computer.

26. A liens verification system of claim 1 further comprising a means to determine if said selected security is still valid before undertaking said comparison. NZ528631 Complete Patent Specification Page 38 11/9/06

27. A lien verification system comprising at least one computer programmed to automatically compare data contained within a plurality of selected securities against like data obtained from one or more other datasources according to a pre-defined schedule, in order to identify data discrepancies between said selected security and one or more of said other datasources and storing at least a portion of the results of said comparison within a system datastore and automatically notifying one or more interested parties of some portion of said results. 10

28. A lien verification system of claim 27 wherein said notification includes a hyperlink which upon activation by said interested party presents a web page displaying some portion of said results including a means for said interested party to submit some portion of said results to a government database of registered securities in order to amend one or more of said selected securities.

29. A lien verification system of claim 27 wherein said other datasources includes a database containing details of registered motor vehicles in New Zealand and said discrepancies include like data differences for one or more of; vehicle registration plate number; vehicle VIN; vehicle description. 20

30. A lien verification system of claim 27 wherein said other datasources includes a database containing details of registered companies in New Zealand and said discrepancies include like data differences for one or more of; company registration number; company name; company contact details.

31. A lien verification system of claim 27 wherein said other datasources includes a database containing details of driver licenses in New Zealand and said discrepancies include like data differences for one or more of; name, date of birth. NZ528631 Complete Patent Specification Page 39 11/9/06

32. A lien verification system of claim 27 further comprising a means for said system to obtain said plurality of selected securities using one or more of the following methods; by using a plurality of security identifiers supplied by a system user to extract details of said selected securities from a government database of registered securities; from a data file submitted by a system user.

33. A lien verification system of any one of claims 28 and 32 wherein said government database of registered securities is the Personal Property Securities Register (PPSR).

34. A lien verification system of claim 32 wherein said system user can be a person or another 10 computer.

35. A method of improving the accuracy of data within a government database containing a plurality of security records, comprising the following steps: a) obtaining details of a selected security that has been registered on said government database using one or more of the following methods; i) using a unique security identifier to extract said details from said government database, ii) reading from a data file, 20 iv) reading from a computer datastore; b) using some portion of said details as a key to obtain information from one or more other datasources; c) comparing some portion of said details with some portion of said information to identify discrepancies between like data; d) if a discrepancy was found, forming a report that contains some portion of the results of said comparison; e) sending said report to one or more parties who are interested in said selected security. NZ528631 Complete Patent Specification Page 40 11/9/06

36. A method of claim 35 further including the step of selecting some portion of said results and submitting them to said government database to amend said selected security.

37. A method of claim 35 wherein said unique security identifier is a FSID and said government database is the Personal Property Securities Register (PPSR).

38. A method of claim 35 wherein said other datasources is one or more of the following; a) a datasource containing details of drivers licenses; b) a government database of registered vehicles; 10 c) a database containing details of registered companies.

39. A method of claim 35 wherein said discrepancies include one or more of the following; a) a difference between the debtor name in said selected security and the name on a drivers license. b) a difference between a debtor date of birth in said selected security and the date of birth on a driver license, c) a difference between a debtor name in said selected security and a company name in database of registered companies, d) a difference between a debtor company registration number in said selected security and 20 a company registration number in database of registered companies, e) a difference between a vehicle registration plate number in said selected security and a vehicle registration plate number in a government database of registered vehicles, f) a difference between a vehicle VIN number in said selected security and a vehicle VIN number in a government database of registered vehicles, g) a difference between a vehicle description in said selected security and a vehicle description in a government database of registered vehicles. NZ528631 Complete Patent Specification Page 41 11/9/06

40. A method of claim 35 wherein said report includes the address to a web page that contains some portion of said results.

41. A method of claim 35 wherein said interested party is the creditor identified within said selected security.

42. A method of any one of claims 35 and 36 wherein one or more of the steps are performed according to a pre-defined schedule. 10

43. A method of any one of claims 35 to 42 wherein one or more of the steps are performed using at least one computer.

44. A method of improving the accuracy of a plurality of securities registered on the PPSR comprising the following steps: a) obtaining a plurality of FSID numbers; b) using an FSID as a key to extract the details of a security from the PPSR; c) using some portion of said security details so extracted as a key to extract vehicle details 20 from a government database of registered vehicles; i) wherein said security details used as said key comprise one or more of: a vehicle registration plate number, a vehicle VIN, a vehicle chassis number; ii) wherein said vehicle details comprise one or more of: a vehicle's current registration plate number, a vehicle's VIN, a vehicle's chassis number; a vehicle's description; d) comparing said vehicle details with said security details to identify discrepancies between like data; e) creating a report that contains some portion of said security details and some portion of said discrepancies; NZ528631 Complete Patent Specification Page 42 11/9/06 f) sending said report to the secured party identified within said security details.

45. A method of claim 44 wherein said report is sent in electronic format that contains an address to a web site that contain at least a portion of said security details and at least a portion of said discrepancies and a method of selecting certain data within said web page and submitting said selected web page data to the PPSR in order to amend said security.

46. A method of claim 44 wherein said vehicle details further comprises one or more of the following; 10 a) the vehicle's current owner name, b) the date of the last change of ownership.

47. A method of claim 44 further comprising the step of determining if the last date of ownership change is later than the date said security was last amended and/or created and if so recording this fact within said report.

48. A method of any one of claims 44 to 47 wherein one or more of the steps can be performed by a computer as per a pre-defined schedule. NZ528631 Complete Patent Specification Page 43 11/9/06