EP2724311A2 - Système et procédé pour fournir des confirmations de compte financier - Google Patents

Système et procédé pour fournir des confirmations de compte financier

Info

Publication number
EP2724311A2
EP2724311A2 EP12804079.7A EP12804079A EP2724311A2 EP 2724311 A2 EP2724311 A2 EP 2724311A2 EP 12804079 A EP12804079 A EP 12804079A EP 2724311 A2 EP2724311 A2 EP 2724311A2
Authority
EP
European Patent Office
Prior art keywords
confirmation
computer
client
communications network
confirmation system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12804079.7A
Other languages
German (de)
English (en)
Other versions
EP2724311A4 (fr
Inventor
Charles Brian FOX
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Capital Confirmation Inc
Original Assignee
Capital Confirmation Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Capital Confirmation Inc filed Critical Capital Confirmation Inc
Publication of EP2724311A2 publication Critical patent/EP2724311A2/fr
Publication of EP2724311A4 publication Critical patent/EP2724311A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting

Definitions

  • the present invention pertains to systems, methods and computer program readable medium providing a secure electronic intermediary service between auditors and financial institutions to reduce time, resources, and costs necessary to complete third- party verifications. More particularly, the present invention relates to automated methods and systems for providing business audit responses from legal professionals.
  • the present invention pertains generally to systems and methods for factoring of accounts receivable by businesses. More particularly, the present invention relates to a system and method for obtaining confirmation of a receivable claimed by a business that wishes to factor that receivable to a third-party factor.
  • Fractoring is a financial transaction in which a business sells one or more of its accounts receivable represented by, for example, an unpaid invoice. To raise working capital or to improve or sustain cash flow, the business will sell the accounts receivable to a third-party "factor" at a discount in exchange for immediate cash. If and when the factor collects the receivable, the factor earns a fee represented by the difference between the discounted purchase amount and the amount collected.
  • factoring transaction is different from a loan transaction in that the emphasis is on the value of the receivable rather than on the credit- worthiness of the business. Also, factoring involves three parties: (1) the debtor that owes the receivable to the creditor; (2) the creditor (i.e., the business selling the receivable); and (3) the factor (the entity that purchases the receivable from the creditor at a discount).
  • the confirmation process comprises numerous manual steps.
  • the confirmation process begins when the audited client or auditor fills out a paper confirmation request form supplied by the client's auditor.
  • the current industry practice is to send paper confirmation request forms by mail, overnight delivery, or other like carriers.
  • a financial institution such as a bank, brokerage, or receiving company
  • the arriving mail is then privately sorted, hopefully routed to the appropriate department or departments, and usually dispatched to hired staff engaged in accommodating such requests.
  • the task is generally viewed as a tedious process requiring manual, accurate, and prompt completion.
  • the paper-based confirmation process of confirming information leaves an opening for fraud, thus creating increased liability for the auditor.
  • most accountants ask the client to fill out the paper confirmation form, or ask the client for the mailing address and contact name for where and to whom the confirmation should be sent.
  • the auditor then mails that confirmation to the financial institution to be filled out.
  • the auditor typically abides to certain procedures in sending out that confirmation.
  • confirmations usually cannot be mailed out from or faxed back to the client's office. This is to protect the integrity of the confirmation process.
  • the auditor cannot give the client access to the confirmations after the client has filled out the form for fear the client may intercept them and alter the information. This can pose a problem if the auditor's office is not in the same city or even the same building as their client. If the confirmations are mailed back from the financial institution to the auditor's office, the auditor must either go back to his or her office to retrieve them, or have someone in the office forward the confirmations via mail to the auditor's hotel or designated location.
  • the auditor must either stand by the fax machine waiting on the financial institution to fax them back so the auditor can witness the confirmations as they are received over the fax machine, or the auditor must use an off- site fax machine, at an independent copy center. Such centers typically charge for this service adding additional cost to the audit process.
  • the auditor is usually not allowed to send confirmations to a post office box for fear the post office box is not really the financial institution's address, but rather a third-party who is attempting to defraud the company or auditor.
  • the conventional confirmation process is subject to other fraudulent practices.
  • the auditor instructs the client to fill out the paper confirmation before it is sent for confirmation. This includes directing the client to fill out the proper financial institution address.
  • Most accountants rely solely on the client for this information and do not employ any system for countering incorrect information supplied by the client.
  • the client in an effort to deceive the auditor, could use any erroneous address, which would suggest legitimacy, as long as it is not addressed to a post office box.
  • the auditor may then, unknowingly send the confirmation to the client's own house, erroneous address, friend or relative thus perpetuating and facilitating fraud.
  • the lack of checks and balances in the current process allows for an information imbalance thus creating a liability for the auditor.
  • a method for facilitating auditing comprising storing an audit number in a computer system, receiving identification data from a user, testing the identification data with verification data to authorize the user to further access the computer system, receiving the audit number from the user, testing the audit number to determine it is valid, receiving a confirmation request from the user, indicating the confirmation request to a third party, receiving response data from the third party including account balance data and a date, receiving a request from the user for the response data, providing the response data to the user.
  • a system comprising a database storing first verification data for a first user and second verification data for a second user; and a server operatively connected to the database, the server configured to receive first identification data from the first user and compare it with the first verification data, the server configured to receive a confirmation request from the first user, the confirmation request comprising an audit number, account identification data, and a date; the server further configured to store the confirmation request, the server further configured to receive second identification data from a second user and compare the second identification data with a second verification data, the server further configured to indicate to the second user the confirmation request, the server further configured to receive response data from the second user, the server further configured to store the response data in the database, the server further configures to receive a request from the first user for the response data, and the server further configured to indicate the response data to the second user.
  • a computer readable medium that when executed, performs the steps of receiving input from a first user comprising identification data; comparing the identification data with verification data stored in a database; receiving a second input from the first user comprising an audit number and a confirmation request associated with an audited client; receiving confirmation data in reply to the confirmation request from a third-party, the confirmation data comprising account type data, account identification data, account balance data, and a date associated with the account balance data; and presenting the confirmation data to the first user.
  • a method of confirming accounts receivables in a factoring transaction includes the following steps: (1) the business client logs in to a factoring confirmation system, enters confirmation request data for one or more of its receivables, approves the confirmation request, and submits the confirmation request to the system; (2) the factoring confirmation system may process a credit card for payment; (3) the responder (debtor) logs in to the system, inputs confirmation response data, and approves the confirmation response; and (4) one or more receiver(s) (factors) logs in to the system to retrieve the confirmation response data.
  • a method for obtaining a physical signature from an audited client including the following steps: (a) a requestor logs in to the system, inputs client account data into the audit confirmation system, and makes a request for confirmation to a responder; (b) the client logs in to the system and approves the confirmation request by signing using a form of electronic signature capture; (c) in some embodiments, the system operator processes a credit card for payment; (d) the responder logs in to the system, inputs client response data, and approves the confirmation response; (e) the requestor logs in to the system and downloads the completed confirmation; and (f) in some embodiments, the responder auditor logs in to view responder's response.
  • a method of confirming accounts receivables in a factoring transaction includes the following steps: (1) the business client logs in to a factoring confirmation system, enters confirmation request data for one or more of its receivables, approves the confirmation request, and submits the confirmation request to the system; (2) the factoring confirmation system may process a credit card for payment; (3) the responder (debtor) logs in to the system, inputs confirmation response data, and approves the confirmation response; and (4) one or more receiver(s) (factors) logs in to the system to retrieve the confirmation response data.
  • Figure 1 illustrates the architecture of the various systems interacting with the confirmation system according to one embodiment of the present invention.
  • Figure la illustrates one embodiment of the architecture of the confirmation system according to the principles of the present invention.
  • Figure lb illustrates another embodiment of the architecture of the confirmation system according to the principles of the present invention.
  • Figure 2 is a high-level block and process flow diagram of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 3 is a work flow diagram of a client user of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 4 is an exemplary representation of an initiate-confirmation- requests screen of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 5 is an exemplary representation of a client profile display screen image of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 6 is an exemplary representation of an account display screen image of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figures 7a-b provide a work flow diagram of an auditor as a user of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 8 is an exemplary representation of a pending-requests-listing display screen image of a computer system for third-party confirmations according to one embodiment of the present invent ion.
  • Figure 9 is an exemplary representation of a specific pending request display screen image of a computer system for third- party confirmations according to one embodiment of the present invention.
  • Figures lOa-c provide exemplary representations of a series of display screen images for viewing and purchasing completed confirmation requests of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 11 is an exemplary representation of a screen display image presented to an auditor user for managing client information according to one embodiment of the present invention.
  • Figure 12 is an exemplary representation of a screen display image accessible to an auditor indicating purchased confirmation requests associated with one specific client according to one embodiment of the present invention.
  • Figure 13 is an exemplary representation of a screen display image indicating purchased request information for third-party confirmations according to one embodiment of the present invention.
  • Figure 14 is an exemplary representation of a screen display image indicating a client report comprising third-party confirmations according to one embodiment of the present invention.
  • Figures 15a and 15b provide a work flow diagram of a bank user of a computer system for third- arty confirmations according to one embodiment of the present invention.
  • Figure 16 is an exemplary representation of a display screen image accessible to a bank user for viewing pending confirmation request according to one embodiment of the present invention.
  • Figure 17 is an exemplary representation of a display screen image accessible to a bank user for confirming, denying or holding a pending confirmation request according to one embodiment of the present invention.
  • Figure 18 is a block and process flow diagram of a computer system for third-party confirmations according to one embodiment of the present invention.
  • Figure 19 is a block and process flow diagram of one embodiment of a confirmation system and method in which audit responses are obtained from a legal professional.
  • Figure 20 is a block and process flow diagram of one embodiment of a confirmation system and method in which audit responses are obtained from multiple legal professionals.
  • Figure 21 is a block and process flow diagram of another embodiment of a confirmation system and method in which audit responses are obtained from multiple legal professionals.
  • Figure 22 is a block diagram of one embodiment of a confirmation system and method in which a physical signature is obtained from the audited client.
  • Figure 23 is a block diagram of another embodiment of a confirmation system and method in which a physical signature is obtained from the audited client and there are multiple responders from the same business.
  • Figure 24 is a block diagram of another embodiment of a confirmation system and method in which data is pulled from a responder after obtaining a client physical signature.
  • Figure 25 is a block diagram of another embodiment of a confirmation system and method in which data is pulled from a responder after a personal identification number (PIN) is assigned to the client by the confirmation system.
  • PIN personal identification number
  • Figure 26 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained after a paper confirmation request is made and an electronic signature is received from the client.
  • Figure 27 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained from multiple responders at the same business after a paper confirmation request is made and an electronic signature is received from the client.
  • Figure 28 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained after a paper confirmation request is made and a PIN is assigned to the client.
  • Figure 29 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained from multiple responders at the same business after a paper confirmation request is made and a PIN is assigned to the client.
  • Figure 30 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained after a paper confirmation request is made and the client signs the paper request.
  • Figure 31 is a block diagram of another embodiment of a confirmation system and method in which an electronic response is obtained from multiple responders at the same business after a paper confirmation request is made and the client signs the paper request.
  • Figure 32 is a block diagram of one embodiment of a confirmation system and method used with factoring transactions.
  • These computer program instructions may also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the block or blocks.
  • the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks of the flowchart, or clock or blocks of the diagrams.
  • blocks of the block diagrams and the flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and the flowchart illustrations, and combinations of the respective blocks, can be implemented by special purpose hardware-based computer systems which perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
  • the terms "financial institution”, “auditor”, “client” are used and based on the context, may refer to a computer system operated by the entity, a user, a person affiliated with the entity operating the computer system, or the entity in general. It should be clear from the context the appropriate meaning to be applied. Further, the term “auditor” is frequently also called an “accountant” and the terms are intended to be interchangeable. Further, although the principles of the present invention are illustrated using an “auditor”, this is not limited to an accountant. In a broad sense, any user requesting confirmation of information can be viewed as an "auditor.” The information to be confirmed is not limited to accounting parameters or accounting functions.
  • any type of information may be confirmed, including the disposition of a physical asset, type or identification of an account, status or disposition of an application for a loan or mortgage, debt or investment terms, receivable or payable balance and party associated with, collateral description, name of a signatory of a particular document, tax status, presence and amount of a lien, levied taxes, alimony payments, debt balance, escrow related parameters, investment related data, personal information (e.g., social security number, name, birthday, driver's license number, mother's maiden name), name on or associated with an account, employment history, health care records (surgical records, payment history, medication currently prescribed), judicial records (status of convictions, fines, or judgments entered against) or any other business, financial, medical, health, credit, or personal data subject confirmation in the course of business by another party.
  • personal information e.g., social security number, name, birthday, driver's license number, mother's maiden name
  • health care records surgical records, payment history, medication currently prescribed
  • judicial records status of
  • Figure 1 illustrates one embodiment of the architecture and typical user entities that may interact with the confirmation system 50 in order to achieve the automated third-party confirmations.
  • a confirmation system 50 comprises a server 70 operatively connected to a communications network 40 via a router/switch 60 or other type of network interface.
  • the entities accessing and interacting with the confirmation system 50 include a financial institution's computer 10, an auditor's computer 20 and a client's computer 30 according to one embodiment of the present invention.
  • the financial institution 10 represents one type of a third-party user to which a confirmation is being sought by the auditor.
  • the third-party user can include, but is not limited to, all types of banks, financial service companies, corporations, and credit unions. Further, this could be an independent business entity, government entity or any other type of entity providing confirmation data for the audited client entity.
  • the auditor 20 is an accountant or other individual performing the audit.
  • the auditor is the primary entity that requests confirmations from a third- party, such as the financial institution 10.
  • the client 30 is the entity subject to audits, including, but not limited to, any business, corporation, non-profit organization, government department or any other entity being audited.
  • the confirmation system 50 can be operated by an independent service provider or may be affiliated with a financial institution or auditor. In some embodiments, certain users accessing the confirmation system may be charged for certain fees that may be paid electronically through a credit card company 80. Alternative embodiments are possible, such as directly debiting an account associated with the purchaser. If paid for by a credit card, the credit card company 80 would interact with the system 50 via the communications network 40.
  • the confirmation system 50 can be a client application embedded in one of the other individual user entity's existing system.
  • the confirmation system 50 can be integrated into a banking system run by the financial institution 10. In that way, for the bank user 10, the confirmation data exchange is accomplished through internal communications between different application modules.
  • Figure 1 illustrates the router/switch 60 as being a separate entity from the server 70
  • the router/switch 60 functionality may be integrated in the communications network 40 or incorporated in part into the server 70.
  • the confirmation system 50 may comprise a server 70 but itself without a separate route r/switch 60.
  • Figure la A typical embodiment of the server for executing software providing confirmation servers is shown in Figure la.
  • Figure la illustrates a typical embodiment of a client computer 30, auditor's computer 20, or financial institution computer 10 that may execute the software.
  • FIG. la one embodiment of the server 70 is illustrated that may comprise a computer used to practice aspects of the present invention.
  • the same computer architecture could apply to either of the auditor's or financial institution's computer if the application is executed on those computers.
  • a processor 1 such as a microprocessor, is used to execute software instructions for carrying out the defined steps.
  • the processor receives power from a power supply 17 that also provides power to the other components as necessary.
  • the processor 1 communicates using a data bus 5 that is typically 16 or 32 bits wide (e.g., in parallel).
  • Typical applications involve the processor receiving inputs, such as user input in the form of various numerical identifiers that are stored in the memory using the data bus.
  • the data bus 5 is also used to convey data and program instructions, typically, between the processor and memory.
  • memory can be considered primary memory 2 that is RAM or other forms which retain the contents only during operation, or it may be non-volatile 3, such as ROM, EPROM, EEPROM, FLASH, or other types of memory that retain the memory contents at all times.
  • the memory could also be secondary memory 4, such as disk storage, that stores large amount of data.
  • the disk storage may communicate with the processor using a bus 6 instead or a dedicated bus (not shown).
  • the secondary memory may be a floppy disk, hard disk, compact disk, DVD, or any other type of mass storage type known to those skilled in the computer arts.
  • the processor 1 also communicates with various peripherals or external devices using an I/O bus 6.
  • a peripheral I/O controller 7 is used to provide standard interfaces, such as RS-232, RS422, DIN, USB, or other interfaces as appropriate to interface various input/output devices.
  • Typical input/output devices include local printers 18, a monitor 8, and input devices such as keyboard. 9a and a mouse 9b or other typical pointing devices (e.g., roller ball, track pad, joystick, etc.) that are not shown.
  • the processor 1 typically also communicates using a communications I/O controller 11 with external communication networks, and may use a variety of interfaces such as data communication oriented protocols 12 such as X.25, ISDN, DSL, cable modems, etc.
  • the communications controller 11 may also incorporate a modem (not shown) for interfacing and communicating with a standard telephone line 13.
  • the communications I/O controller may incorporate an Ethernet interface 14 for communicating over a LAN. Any of these interfaces may be used to access the Internet, intranets, LANs, or other data communication facilities.
  • the communications 10 is used by the processor to send data, such as account data or other data comprising a confirmation request response data, as well as receive confirmation requests from a user.
  • the confirmation system 50 comprises a server 70 communicating with a client computer 30, financial institution computer 10, and the auditor's computer 20. In other embodiments, only a subset of the computers may be involved.
  • the server 70 typically comprises a processor 21 that communicates with a database 22. which can be viewed as a form of secondary memory and stores various confirmation requests, both pending and completed, as well as primary memory 24.
  • the processor also communicates with external devices using an I/O controller 23 that typically interfaces with the Internet 27.
  • each of the client's computer 30, financial institution's computer 10, and the auditor's computer 20 incorporate a browser, such as the Microsoft Explorer" executing on a Windows 2000TM operating system.
  • the server 70 may utilize standard Internet protocols, such as HTTP, or secure encryption protocols, like HTTPS or other types of both secure and non- secure communication protocols as is known in the art, for communicating data, such as response data and soliciting confirmation request data from a user.
  • the auditor's computer may include a local printer 28 for printing local reports in order to provide a written record of the confirmation results or other data as described herein.
  • Figure 2 a high-level block and process flow diagram of the interaction between the various aforementioned entities is demonstrated with exemplary steps.
  • Figure 2 represents the step-by- step confirmation process in accordance with one embodiment of the present invention.
  • the first step is to have the client's computer 30 register with the confirmation system 50.
  • Step 1 the client establishes an account with the confirmation system 50 by providing necessary data including company information (name, address, phone number, email, etc.), account related information (name, address, phone number and email) of the accounting firm authorized for auditing the client 30), and account related information (such as the name, address, phone number and email of one or more banks/financial institutions where the client has accounts to be audited).
  • company information name, address, phone number, email, etc.
  • account related information name, address, phone number and email
  • account related information such as the name, address, phone number and email of one or more banks/financial institutions where the client has accounts to be audited.
  • the confirmation system 50 stores such client-provided data into a database, and in turn, in Step 2 provides the client's computer 30 with login information, i.e., username and password for secure access to the confirmation system 50.
  • the login information may be communicated to the client's computer 30 via an email sent from the system 50.
  • This step is illustrated as a dotted line in Figure 2 since alternatively, the login information may be generated by a letter sent via postal mail, communicated via a telephone call, or any other means for secure data transfer.
  • the information could be communicated person-to-person, and does not require automated computer communication.
  • client authorizes the release of the information from the financial institution to the auditor using an AUD number (audit number) or other form of electronic signature as is known in the art.
  • the confirmation system 50 generates an audit number, which can be an authorization number, PIN (personal identification number), or other form of alphanumeric data and transmits the audit number to the client 30, typically via email communication.
  • the audit number functions similar to a key in that it allows access or authorizes, in part, information associated with the client. Only when the client 30 gives the audit number to the auditor 20 is the auditor 20 authorized to access the account confirmation information of the client 30, such as those provided as response data from a third- party such as the bank/financial institution 10 in this illustrative example.
  • the communication shown in step 3 is indicated as a dotted line again that the communication may occur in a variety of ways, and does not necessarily involve electronic communication between the confirmation system and another computer.
  • the confirmation system 50 typically recognizes an audit number as being valid for a limited time (e.g., after 30 days from the time the number is generated, or after the number has been used for a certain number of times, (e.g., three times), or upon a request for cancellation from the client 30). If the audit number is no longer valid, then a new number can be requested by the client and generated by the confirmation system.
  • the system typically sends the number to the client, who in turn, may send it to the auditor. In other embodiments, the client may authorize the confirmation system to send the number to the auditor directly,
  • the auditor 20 can initiate a confirmation request as shown in Step 4. More specifically, the auditor 20 is required to select or identify an account of the client 30 that is associated with the financial institution 10 to which the confirmation request is directed. In addition, the auditor 20 provides the audit authorization number for validation by the system 50. Further, the confirmation request typically includes a date for which account confirmation information is to be associated with (e.g., the account balance for an indicated account as of the end of the indicated date). The indicate date is may be a past date, a current date, or a future date.
  • the confirmation system 50 now has received and stored into memory pending confirmation requests that need to be acted upon by the appropriate financial institution.
  • the confirmation system could "push" the pending confirmation request to the financial institution's computers, or alternatively electronically notify the financial institution that a confirmation request is pending.
  • the financial institution "pulls" the confirmation request from the confirmation system. This embodiment is can be practiced, for example, by a employee of the financial institution (e.g., bank clerk) logging onto the confirmation system in Step 5, entering the appropriate identification and authorization information, to which the confirmation system responds in Step 6 with a list of pending confirmation requests.
  • the bank clerk After receipt of the pending confirmation request, the bank clerk then retrieves from the bank's own databases (not shown) the account data associated with the client 30 on the specified historical date. This can be done manually, or on an automated basis.
  • the financial institution 10 confirms the request by providing the appropriate confirmation data in Step 7.
  • the data is communicated by sending the retrieved account data to the confirmation system 50,
  • Such account data typically, comprises how much cash balance remain in an account of the client 30 and potentially other information. Additionally, the bank clerk may provide identification and/or contact information allowing identification of the person providing the response data. If the auditor 20 provides any incorrect input associated with the confirmation request such as incorrectly identifying the account or providing an invalid date, the response provided by the financial institution in Step 7 will indicate a denial with specific reasons.
  • the confirmation system 50 stores the response from the financial institution 10 in its database, including account data of the client 10 or denial reasons.
  • the confirmation system 50 then provides the response in Step 8 to the auditor.
  • the auditor may log-off, and at a future time log-on again to check whether the confirmation response is available.
  • a similar paradigm for the auditor "pulling" data from the confirmation system or the confirmation system "pushing" the data to the auditor can be defined.
  • the confirmation system may notify the auditor of an answered confirmation request (e.g., response pending) or the auditor may periodically log on and check the status.
  • the confirmation system solicits payment information from the auditor prior to disclosing the confirmation response data to the auditor. This requires the auditor 20 to provide necessary payment information (e.g., credit card information) before receiving the confirmation result from the confirmation system 50. After payment has been made, the confirmation result is said to be “purchased” by the auditor. Thus, the confirmation result is called a "purchased confirmation.”
  • various electronic wallets, "Pay pal” services, debit cards, or direct electronic funds transfer may be employed to effect payment.
  • Figure 2 only represents one embodiment of the present invention wherein the involved third-party is a bank or financial institution.
  • the third-party providing confirmations can be another corporate entity doing business with the client 30, namely a government entity, a charitable organization, etc.
  • the confirmation system 50 is disclosed, namely, the client 30, the auditor 20 and the bank 10, will be described with reference to the Figures 3 - 17 illustrating exemplary flow charts and display screens representing web pages presented to various users accessing the confirmation system.
  • the interactions between the client 30 and the confirmation system start with the initial client registration 300. This may occur by electronic communication between the client's computer and the confirmation system, or the operator of the confirmation system may enter into the confirmation system the necessary client information.
  • the client 30 After the client 30 provides necessary information for establishing a profile in the confirmation system (not shown), the client receives, preferably, an email from the system in step 302 containing typically a username and password that is used by the client to access and log into the confirmation system.
  • a username and password such as electronic signatures may be used to gain access by the user (whether client, auditor or otherwise) to the confirmation system.
  • the confirmation system proceeds to send to the client a second email containing an audit authorization number 304 for it to authorize the auditor to request third- party confirmations.
  • the audit number provided in step 304 will be typically invalidated and re-generated periodically.
  • the client may request regeneration of a new audit number, which can be accomplished by the confirmation system 50 sending out an email to the auditor including the new audit number.
  • the client logs into the confirmation system at step 306 by providing the received username and password 302 through a web page with these fields to be filled in.
  • the confirmation system determines the username and password provided by the client are correct and the client functions in a main menu 310 are displayed.
  • the client functions or main menu typically comprise Confirmation Requests 320, Accounts 330 and User Profile 340.
  • the Confirmation Request menu function is associated requesting confirmation for an identified account. While this is primarily a function used by auditors, this function is also available for the client to invoke.
  • the process steps include selecting or identifying the account for which a confirmation is requested in step 350, providing the desired date for which the account is to be confirmed in step 351.
  • the audit number is provided in step 352.
  • the confirmation system processor compares the audit number entered by the user with audit number stored in memory to determine if the number is valid. If so, then a request is submitted for confirmation in step 357. At this point, the confirmation stores the pending request in its database. If the audit number is not valid in step 354 (e.g., it has expired), a new audit number must be requested in step 356 and proceeds again at step 352.
  • FIG. 4 A sample screen display representing one embodiment of the Confirmation Request 320 menu function is shown in Figure 4.
  • the sample screen display 401 allows the user to indicate or select one or more accounts 410 for submitting a confirmation request 400.
  • Each account 410 comprises an account name 411, an account number 412 and a bank 413 where the account 410 resides.
  • each line corresponds to one record in the confirmation system database.
  • the user is required to enter a request date 420, which sets a time limitation associated with the confirmation request 400. Specifically, in one embodiment the date indicates the date for which the account confirmation data is to be valid.
  • the client is also required to enter a valid AUD number 430.
  • the client may click an icon 440 for requesting a new valid audit number to be sent by the confirmation system.
  • the client can click an icon 450 to submit the confirmation request 400 to the confirmation system.
  • the confirmation system will, store the data in its database and flag the request as a pending confirmation request.
  • the confirmation system will display the request 400 to the bank user as a pending confirmation request when the bank user logs in and checks for pending confirmation requests.
  • other techniques for "pushing" the notification to the bank user may be employed.
  • the main menu for the client in Figure 3 also allows a user to select the User Profile function 340.
  • This function allows the client to administer various client related information, including identification and contact information. This allows the client user to update records pertaining to the client stored in the database of the confirmation system.
  • the screen display 501 includes Client Information 500 comprising name information 502, including First Name, Last Name and Contact title of a contact person, Company Name. Also provided is contact information, such as phone number 503, e-mail address, fax, address, Website information, etc.
  • the client may edit the Client Information 500 and click the "Update Profile" icon 510 to keep the user profile updated in the database of the system.
  • the main menu 310 of Figure 3 also allows a user to select the "Accounts” function 340.
  • One embodiment of the "Account” display screen 601 is disclosed in Figure 6.
  • the function of the "Account” option is to allow the client to add, edit and delete any account information.
  • the client should select a bank, by providing data including account name, account number, account type (i.e., asset or liability), description of the account, due date, year which interest paid through, interest rate, and collateral description.
  • the client may create a new account that will be stored into the database of the confirmation system.
  • Figures 7a and 7b provide the workflow from the perspective of the auditor. Similar to the initial client registration procedure described for the client, the auditor similarly sets up an auditor profile with the confirmation system by providing necessary information (e.g., accountant name, accounting firm, address, phone, fax, etc.) in step 704. Typically, this is done by the auditor using the browser on the auditor's computer to interact with the confirmation server to provide the data according to the prompts provided by the confirmation system. The auditor is then provided with a valid username and password for accessing the confirmation system, typically via a web browser. If the auditor already has obtained the identification and password information, then this step does not have to be repeated and the auditor may select the path incorporating step 702 instead.
  • necessary information e.g., accountant name, accounting firm, address, phone, fax, etc.
  • the auditor may be prompted to invoke "Account Management” 710 or "Client Management” 720 functions. These steps are optional, and may not always be invoked when logging onto the confirmation system.
  • the "Account Management” 711 function allows the auditor to edit profile parameters associated with the auditor, such as name, address, and contact information.
  • the auditor will be capable of performing Auditor Password Management 712 functions that permits the auditor 20 to change and or alter the password for security purposes. This allows the auditor to alter the password given to the auditor by the confirmation system to a password value preferred by the auditor.
  • the auditor can create new client profile 721 as well as edit an existing client profile 722.
  • the auditor 20 is capable of adding 724, editing 726 and deleting an account 728 associated with this client.
  • the auditor confirmation functions listed in the Main Menu 730 comprise "View Pending Confirmation Requests” 731, "View Completed Confirmation Requests” 732 and "View Client Information” 733.
  • the auditor can view pending confirmation requests that were previously submitted.
  • the confirmation system accesses its database to select records of pending requests that are associated with the auditor and presents only these records to the auditor.
  • the auditor must select or identify one of the presented pending requests in step 735.
  • the confirmation system retrieves the associated confirmation response data associated with the identified confirmation request and provides the associated data in step 736. After viewing the data, the auditor then returns to the main menu in step 743.
  • the screen display associated with the "View Pending Confirmation Request" response is embodied in Figure 8.
  • the confirmation system provides a screen display image 850 of all pending confirmation requests 800 that have been submitted to the system by the auditor, but have not yet been confirmed by the corresponding bank.
  • Each pending confirmation request 800 contains Status 801 as "pending,” Account Name data 802, Account Number data 803, Bank data 804, and Clerk data 805. Because the request has not been confirmed, the Clerk data is indicated as "N/A" for "not applicable.”
  • the screen display 950 comprises specific information including Client's Company Information 900, Client's Account Information 910, and Confirmation Request Information 920. More specifically, the Client's Company Information 900 comprises Client Address 901 and Controller contact 902 (i.e., Controller name and email). Other types of information (e.g., multiple controller contacts, telephone numbers, etc. may be indicated).
  • the Client's Account Information 910 comprises Account Name 911, Number 912 and Type 913 (i.e., asset or liability).
  • the Confirmation Request Information 920 comprises Status 921 of the request as pending, Request ID 922 a d a Request Date 923.
  • the Request ID 922 is an identification number that is generated and assigned by the confirmation system to a confirmation request received from the auditor.
  • FIG. 7b Another main menu function indicated in Figure 7b that is available to the auditor is the "View Completed Confirmation Requests" function 732.
  • This function allows the auditor to view data pertaining to a completed request. In other words, this function indicates to the confirmation system to select those records from the database associated with the auditor for which confirmation data has been provided. These may be further limited to those requested in the last 30 days, or in some other fashion.
  • the auditor In order to view the data, the auditor must select the specific complete request to view in step 737.
  • the auditor may be require to provide payment information in step 738 to the confirmation system operator, such in as the form of a credit card or debit account number or other methods, after which in step 740 the auditor is the provided the completed confirmation results.
  • FIGs lOa-lOc The associated screen displays that may be provided to the auditor are disclosed in Figures lOa-lOc.
  • FIG 10a one embodiment of the auditor's homepage 1050 is shown.
  • the screen image 1050 indicates that the auditor may select an icon 1001 or 1002 to see a list of completed confirmation requests or provide payment information, respectively.
  • the screen display 1051 shows a list of confirmation requests 1003.
  • Figure 10c one embodiment of a screen display 1052 for the auditor to provide payment information, including the auditor's identification information 1006 and credit card type is disclosed.
  • the screen display 1301 comprises information about the audited client 1310, including the client's account information 1320.
  • the confirmation request 1330 is indicated with its status 1333, namely that the appropriate fee has been paid to allow viewing (e.g., it has been 'purchased').
  • Other associated information such as the request data 1334, the bank clerk name and contact 1332, the appropriate due data 1335 and the most current data for which interest has been paid through 1336 is indicated as well.
  • the account balance 1337, the interest rate 1338, nature of the account 1340, and any comments or exceptions 1341 are provided.
  • the screen also provides an icon to resubmit the request for re-confirmation 1339 if there is any need to obtain an updated status of the account.
  • FIG. 7b Another menu option presented to the auditor shown in Figure 7b is the "View Client Information” menu function. Turning back to Figure 7b, if the auditor selects "client information" 733, a list of the clients that have authorized the auditor to request third-party confirmations will be provided.
  • FIG 11 One embodiment of the information displayed is provided in Figure 11.
  • the screen display 1101 provides a list of pending confirmation for various clients.
  • one client, "Demo Audit Client" 1102 is shown as having 257 confirmations 1104 available for viewing.
  • the auditor may return to the main menu to select and view a particular confirmation request or may select the appropriate icon to receive the indicated information. If the auditor selects to review a client report by selecting icon 1106, then the auditor is presented with a list of all the confirmation requests (both pending and completed) as shown in Figure 12.
  • the screen display image 1201 indicates a plurality of confirmation requests. Each request includes a field indicating the status 1202 as to whether the confirmation has been responded to and purchased, the name of the account 1204, the account identification 1206, the name of the bank 1208, and the clerk identification, typically the name of the bank clerk who provided the confirmation response data 1210.
  • the auditor may indicate the function of "Initiate Client Confirmation for Pending Requests" in step 744 or the auditor may view a specific client's reports in step 746.
  • the auditor selects initiating of a client confirmation in step 744, then the auditor must obtain an audit number in step 754 if one has not already been obtained and provide it to the confirmation system in step 756 as evidence of authorization from the client to access the client's information. If the auditor requires a new number, the confirmation system typically communicates the audit number to the client, who in turn, communicates it to the auditor. Although the audit number is one embodiment of authorization of the auditor, various other means could be used, such as providing personal information of the auditor (e.g., social security number, mother's maiden name, biometric information, etc.). If the audit number is tested as valid in step 757, then the confirmation request is posted to the appropriate bank in step 758.
  • personal information of the auditor e.g., social security number, mother's maiden name, biometric information, etc.
  • the auditor may print 748, download 750, or request a confirmed request be 'reconfirmed' in step 752.
  • the auditor may also add, delete and edit the account information for each client.
  • the auditor is has similar capabilities as the client itself in maintaining the account information.
  • the screen display 1400 comprises data including the client's name 1401, the name of the account 1404, the account number 1406, the current balance 1408, the current interest rate 1410, the bank serving the account 1412, and the name of the bank clerk that confirmed the account 1414.
  • the report information can be presented in various formats, such as a plurality of pages wherein each page resembles the image of Figure 13.
  • the other user that interacts with the confirmation system is the third- party or financial institution, typically a bank.
  • a bank or financial institution can be viewed as on embodiment of a third-party, and the description of the embodiment herein uses "bank" to illustrate the principles of the present invention, but is not limited to banks only.
  • the principles of the present invention apply to other types of financial institutions as a third party, including mortgage lenders, investment firms, credit unions, etc.
  • nonfinancial institutions such as other businesses, government organizations, charities, etc. may be specific instances of a third party.
  • FIG. 15 the functions performed by the bank user are demonstrated in the flowchart in Figures 15a and 15b. Similar to the other users, the bank user must have an account established. Because a bank may have numerous clerks employed for confirmation processing, a system administrator at the bank is typically used for the bank's administration of the bank clerk's accounts. Typically, a system administrator associated with the operation of the confirmation system establishes the individual bank clerk's accounts. First, bank supervisor's account must be established. This is shown in step 1500 by the confirmation system administrator logging into the confirmation system. Next, the system administrator may invoke various system administrator functions 1510 that include establishing the bank's profile in step 1504, editing the bank's profile 1506, or creating a particular bank's supervisor account in step 1510. In establishing the bank profile, the identification and contact information for the bank is established. This data can be later changed by editing the bank's profile.
  • a bank may access the confirmation system.
  • the initial functions involve the aforementioned bank supervisor logging onto the confirmation system in step 1503 and invoking one of the bank supervision functions 1520. These functions are used to allow the bank to create, edit, or activate/deactivate a particular bank clerk's account on the confirmation system.
  • the "set up bank clerk" function at step 1522 allows a bank clerk to access and process confirmation requests. Information regarding a particular bank clerk's profile may be edited by the "edit bank clerk” function 1524.
  • the bank supervision may act ivate/de activate a particular bank clerk's access to the system. This allows suspending a bank clerk's access without destroying that particular bank clerk's profile. The process then repeats as required, in step 1528.
  • Figure 15b shows one embodiment.
  • the process begins with a bank clerk logging onto the system at step 1503, At this point, the bank clerk may select three functions: review pending request 1531, view in-progress requests 1532 or view follow-up requests 1533.
  • the "pending requests" function 1531 shows all requests that are pending.
  • a sample screen display is depicted in Figure 16.
  • the screen display 1600 comprises records of pending (e.g., unresponded to confirmations) that include the client's name 1602, the client's account number 1604. the nature of the account 1606, and the account type 1608.
  • the bank clerk may "hold” or suspend the request 1535 (for later completion), confirm the request 1527, or deny the request 1539.
  • the bank clerk confirms the request by providing data regarding the requested account. If the clerk is unable to provide the data for the account (e.g., it does not exist or has been closed), the clerk will deny the request.
  • the bank clerk may be presented a screen display as shown in Figure 17.
  • the bank clerk is presented with basic information such as the auditor making the request 1701, the client account information 1703, and the date of the request 1705.
  • the bank clerk provides data indicating the balance 1706, the bearing interest rate 1707, and the selects the "confirm" function 1710. If the bank clerk selects "can't confirm", the bank clerk is required to provide a reason in the comment field 1708 for denying the request.
  • the reasons for denial include, but not limited to, invalid account name, invalid contact name and incorrect client name. If the required account data is temporarily unavailable, the bank clerk alternatively may select to "hold” the request so that the pending confirmation request becomes an in-progress request.
  • the bank clerk may select the "search for in- progress request" function 1542 later for confirming or denying a request put on hold.
  • the bank clerk can search a confirmation request based on a Request ID and then view the specific request information in the same format as the auditor and client.
  • the bank clerk can also search all confirmation requests associated with one specific client 1544 and obtain a list of searched results.
  • a client report 1548 as described above that contains the list of confirmation requests associated with a specific client can be generated by the confirmation system for printing 1552 or may be downloaded 1550 to the bank clerk.
  • a benefit of this approach includes financial institutions eliminating the paper confirmation process, which includes mailroom sorting and distributing the incoming confirmations, having the financial institution's clerks then look up the needed information on the financial institution's computers then fill out by hand the paper confirmation, and finally sending the confirmation back through the financial institution's mailroom for redelivery.
  • FIG. 18 illustrates a scenario of various steps associated with use of the confirmation system to confirm the type and amount of a particular accounts receivable.
  • a pre-existing business relationship exists between a Vendor 18082 and a Third Party Business 1808 that has purchased certain products from the Vendor.
  • Step 1 the products have been provided to the Third Party Business and in return, in Step 2 the Third Party Business promises to pay the Vendor.
  • the Vendor would enter the sum in their accounts receivable, and the Third Party Business would enter the same sum in their account payable.
  • the Vendor 1802 is audited by the Vendor's Auditor 1804.
  • the auditor-client relationship is indicated by the dotted line 1805.
  • the Auditor may be an internal organization of the Vendor, or it may be an independent third party accountant.
  • the Third Party Business 1808 has an Auditor 1806 as well. This again, could be an organization internal to the Third Party Business or an independent third party accountant. This separate auditor-client relationship is indicated by a different dotted line 1807.
  • the Vendor's Auditor may desire to confirm the existence and amount of the account received. Assuming that the relevant parties have established accounts with the Confirmation System 1800, the Vendor's Auditor initiates in Step 3a a confirmation request to the Confirmation System 1800.
  • the information includes an indication of the target Third Party Business from which the confirmation is requested, and the type of information for which confirmation is being requested.
  • the Third Party Business receives the confirmation request in Step 3b from the Confirmation System 1800.
  • Step 4a the Third Party Business indicates the amount it owes to the Vendor, and the Confirmation System provides this information to the Vendor's Auditor in Step 4b.
  • the Confirmation System 1800 can make this information (either the request and confirmation, or just the confirmation data) available to the Third Party Business' Auditor in Step 5. This allows the Third Party Business' Auditor to view the confirmation response provided by the Third Party Business and compare that data with previous data provided to the Third Party Business's Auditor 1806. This ensures the data being reported by the Third Party Business is consistent with data being provided to the Auditor 1806. This further reduces the ability for fraud.
  • the aforementioned techniques of security, notification, identification, payment, etc. can apply to governing the access to the Confirmation System by the various users.
  • the "auditor” is typically a party separate from the audited client, but this is not a requirement to practice the principles of the invention.
  • the auditor may be a person in a group of a corporation delegated with the responsibilities of auditing other groups within the corporation (e.g., an 'internal' auditor).
  • the "third party” e.g., financial institution user or bank clerk
  • the 'third party' may be affiliated with the audited client, such as the third- arty being a person within a group of a corporation delegated with the responsibility of confirming requests initiated by other groups within the corporation.
  • the third party for which a confirmation request is desired does not have an account or user profile established on the confirmation system.
  • the confirmation system may maintain a mailing address associated with the bank (perhaps indicating a certain department, or contact person), and upon receipt of a confirmation request from the auditor indicating that specific bank, the confirmation system generates a paper copy of the request.
  • the confirmation system automatically prints the confirmation request using the stored address, and results in the confirmation request being delivered using the indicated delivery mechanism (typically, the postal service).
  • the confirmation request may include the auditor's address as defined in the auditor's profile as the return address. In this manner, or variations thereof, users that do not have a profile established on the confirmation system are able to interact with other parties that do.
  • the confirmation system may instead generate an email message to a defined contact at the bank,
  • the email message may be to a generic department, or a specific person, and the contents of the message may contain the confirmation request, or a document (e.g., PDF® or Word®) enclosed as an attachment conveying the confirmation request.
  • the confirmation response could be conveyed using an email message to the confirmation system. Such a response could include the appropriate information allowing the confirmation system to validate the sender of the information.
  • the communication between the systems of the present invention and financial institutions can occur via the Internet, as discussed above, or via one or more additional networks using a variety of communication protocols and services, such as virtual private networks, wide area networks, or enterprise networks.
  • the vast majority of financial institutions around the world are interconnected to one sort of network or another.
  • One common network the financial institutions are tied to is the electronic funds transfer network over which the automated teller machines communicate and through which financial institutions accomplish money wire transfers.
  • Figures 19-21 describe additional embodiments wherein client account data of legal professionals is audited or confirmed. Steps performed by the confirmation system are generally performed automatically. That is, the confirmation system responds to receiving the completion of a step prior to a step conducted by the confirmation system by conducting the next step in the process without further intervention or prompting, such as by a user of the confirmation system.
  • FIG 19 is a block and process diagram of one embodiment of a confirmation system and method similar to that described above and particularly including a method of obtaining audit confirmations from legal professionals (e.g., lawyers and/or law firms).
  • the requestor 20 e.g., a CPA or auditor
  • the confirmation system 50 e.g., Confirmation.com
  • client's information and account data e.g., law firms and their corresponding trust account balances, fee accruals, and case amounts in controversy
  • the account data includes the contact information (e.g., email address) of a legal professional for which client account data (e.g., trust account balances, fee accruals, and case amounts in controversy) is entered.
  • client account data e.g., trust account balances, fee accruals, and case amounts in controversy
  • the confirmation system 50 to prompt, such as by sending an electronic mail message to the entered email address of the legal professional, the legal professional to register (i.e., establish a username and password) with the confirmation system 50.
  • the confirmation system 50 sends an audit authorization number (e.g., audit number, authorization number, electronic signature, or personal identification number) to the business client 30.
  • an audit authorization number e.g., audit number, authorization number, electronic signature, or personal identification number
  • the client may review, complete, and/or edit some account data (e.g., attorney contact information) by logging in to the confirmation system 50 with a username and password associated with the client 30.
  • some account data e.g., attorney contact information
  • the client provides the audit authorization number to the requestor (e.g., auditor).
  • the requestor 20 e.g., auditor
  • the responder 1910 e.g., a legal professional, lawyer, or law firm staff
  • the confirmation system 50 prompts the responder 1910 to enter the response data by sending an electronic mail message to the responder 1910 indicating that response data is being requested by the confirmation system 50.
  • the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 1910 completing the confirmation.
  • Figure 20 is a block and process diagram of an embodiment of a confirmation system and method similar to that described above with reference to Figure 19, but including a method of obtaining audit confirmations from multiple legal professionals (i.e., 1910, 1920, and 1930).
  • the requestor 20 e.g., a CPA or auditor
  • the confirmation system 50 e.g., Confirmation.com
  • client's information and account data e.g., law firm identities and the client's trust account balance and accrued bills at each law firm
  • the account data includes the contact information (e.g., email address) of a legal professional for which account data (e.g., trust account balance) is entered.
  • account data e.g., trust account balance
  • the confirmation system 50 prompt, such as by sending an electronic mail message to the entered email address of the legal professional), the legal professional to register (i.e., establish a username and password) with the confirmation system 50.
  • the confirmation system 50 sends the audit authorization number (e.g., audit number, authorization number, electronic signature, or personal identification number) to the business client 30.
  • the client may review, complete, and/or edit some account data (e.g., attorney contact information) by logging in to the confirmation system 50 with a username and password associated with the client 10.
  • the client provides the audit authorization number to the requestor 20 (e.g., auditor).
  • the requestor 20 e.g., auditor
  • the responder 1910 e.g., a legal professional, lawyer, or law firm staff
  • the confirmation system 50 prompts the responder 1910 to enter the response data by sending an electronic mail message to the responder 1910 indicating that response data is being requested on the confirmation system 50.
  • the responders each access the confirmation system 50 with their username and password and enter their response data (e.g., approval or disapproval of account data entered in the confirmation system 50) into the confirmation system 50 at steps 5a, 5b, and 5c.
  • the confirmation system 50 prompts the responder 1910 to enter the response data by sending an electronic mail message to the responder 1910 indicating that response data is being requested on the confirmation system 50.
  • the confirmation response i.e., confirmation response data
  • step 6 the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation (i.e., response data) is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation (i.e., response data) and related reports by, for example, electronic mail in response to the responder 1910 completing the confirmation.
  • Figure 21 is a block and process diagram of a variation of the embodiment of a confirmation system and method described above with reference to Figure 20.
  • the requestor 20 e.g., a CPA or auditor
  • the confirmation system 50 e.g., Confirmation.com
  • client's information and account data e.g., law firm identities and the client's trust account balance and accrued bills at each law firm
  • the requestor may leave some or all data fields of the client information and account data blank for the client to populate and/or edit.
  • the client 10 accesses the confirmation system 50 with their username and password and electronically signs the confirmation request (e.g., provides an audit number, electronic signature, or audit authorization number) at step 2. While accessing the confirmation system 50 at step 2, the client 30 can also enter, review, and/or edit the account data and client information on a confirmation request.
  • the requestor 20 e.g., auditor
  • enters the confirmation system 50 via their assigned username and password can enter, review, and/or edit the client account data, and when satisfied with the client information and account data, the requestor 20 electronically initiates the confirmation request.
  • the confirmation system 50 indicates to the requestor 20 which account data and/or client information has been edited or completed by the client 30 in order to facilitate review of the data provided by the client 30 by the auditor 20 to prevent fraud.
  • the responders e.g., multiple legal professionals such as first responder 1910, second responder 1920, and third responder 1930
  • the confirmation response is not complete until all of the responders (e.g., multiple legal professionals such as first responder 1910, second responder 1920, and third responder 1930) have entered their individual response data into the confirmation system 50. Any responder can enter their response data at any time, so the response data can be received in parallel.
  • paper confirmations by their very nature forced responses to be processed in series because a piece of paper could only be on one person's desk at a time, but because the response data (i.e., confirmations) is received from each responder independently and at the confirmation system 50, the response data or confirmations may be received by the requester 20 simultaneously (i.e., in parallel).
  • step 5 the requestor 20 accesses the confirmation system with the username and password associated with the requester 20 and retrieves the completed confirmation(s), and optionally, any related reports.
  • the confirmation system 50 indicates to the requestor 20 that the completed confirmation (i.e., response data) is available via electronic mail.
  • the confirmation system 50 may send the requestor 20 the completed confirmation (i.e., response data) and related reports by, for example, electronic mail in response to the responder 1910 completing the confirmation.
  • FIG. 22-31 Further embodiments of the invention are shown in Figures 22-31, including methods in which electronic and/or paper signatures are obtained from the client, client personal identification numbers (PINs) are used for authentication, and/or in which there are multiple responders from a single business entity (e.g., employees or divisions of a financial institution, law practice, and/or business doing business with or having one or more accounts with the client).
  • Steps performed by the confirmation system are generally performed automatically. That is, the confirmation system responds to receiving the completion of a step prior to a step conducted by the confirmation system by conducting the next step in the process without further intervention or prompting, such as by a user of the confirmation system.
  • FIG 22 is a block diagram of an embodiment of a confirmation system and method in which a physical signature is obtained from the audited client 30.
  • a public or private digital communications network connection e.g., an Internet connection
  • the requestor 20 remotely logs in to the confirmation system 50 at step 1, inputs client account data into the confirmation system 50, and initiates a request for confirmation.
  • the client 30 logs in to the confirmation system 50 and approves the confirmation request by signing using electronic signature capture.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via a public or private digital communications network connection (e.g., an Internet connection).
  • a public or private digital communications network connection e.g., an Internet connection
  • the credit card information may be provided by the requestor 20 or by the client 30.
  • the responder 2010 logs in to the confirmation system 50 by entering a username and password associated with the responder 2010, inputs client response data, and approves the confirmation response.
  • the requestor 20 logs in to the confirmation system 50 and downloads the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 2010 completing the confirmation.
  • a responder auditor 2810 logs in to the confirmation system 50 to view the responder's response.
  • the responder auditor 2810 is an auditor of the responder 2010, and viewing the responder's responses enables the responder auditor 2810 to detect fraud in an audit of the responder 2010.
  • Figure 23 illustrates a variation of the confirmation system and method shown in Figure 22 in which responses are obtained from multiple responders (i.e., first responder 2010, second responder 2020, and third responder 2030) within the same business or company.
  • FIG 24 is a block diagram of another embodiment of a confirmation system and method in which data is pulled from a responder after obtaining a client physical signature.
  • the requestor 20 e.g., auditor
  • the requestor 20 remotely logs in to the confirmation system 50 using a username and password associated with the requestor 20 via a public or private digital communications network connection (e.g., an Internet connection), inputs client account data, and makes a request for confirmation.
  • the client 30 logs in to the confirmation system 50 with a username and password associated with the client 30 and approves the confirmation request by signing using an electronic signature capture.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via the public or private digital communications network connection (e.g., an Internet connection).
  • step 4 the confirmation system 50 accesses the responder 2010, provides credentials associated with the client 30 (e.g., username and password, a PIN, and/or the captured client signature), and downloads confirmation response data.
  • step 5 the responder 2010 logs in to the confirmation system 50, enters response data, and approves the confirmation response.
  • the response data edits the client account data in the confirmation system 50 and approves a confirmation response having edited client account data.
  • the requestor 20 then logs in to the confirmation system 50 and downloads the completed confirmation in step 6.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 2010 completing the confirmation.
  • the responder auditor 2810 logs in to the confirmation system 50 to view the responder's response.
  • FIG 25 is a block diagram of another embodiment of a confirmation system in which data is pulled from a responder after a personal identification number (PIN) is assigned to the client by the confirmation system and used for authentication of the requestor.
  • PIN personal identification number
  • the requestor 20 logs in to the confirmation system 50 with a username and password associated with the requestor 20 and inputs client account data to initiate a confirmation request.
  • the confirmation system 50 generates and sends a PIN to the client.
  • the client 30 then provides the PIN to the requestor 20 in step 3 which may occur offline or via electronic communications, but occurs without action by the confirmation system 50.
  • the requestor 20 inputs the PIN into the confirmation system 50 for validation and upon validation, the confirmation request is approved in step 4.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via the public or private digital communications network connection (e.g., an Internet connection).
  • the confirmation system 50 requests confirmation response data from responder 2010, and the responder 2010 sends confirmation response data back to the confirmation system 50 in step 6.
  • the response data edits the client account data in the confirmation system 50 and approves a confirmation response having edited client account data.
  • the responder 2010 logs in to the confirmation system 50 and approves a confirmation response including the confirmation response data.
  • the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • FIG. 26 is a block diagram of another embodiment of a confirmation system in which an electronic response is obtained after a paper confirmation request is made and an electronic signature is captured from the client.
  • the requestor 20 logs in to the confirmation system 50 using a username and password associated with the requestor 20, inputs client account data, and initiates a request for confirmation in step 1.
  • step 2 the client 30 logs in to the confirmation system 50 using a username and password associated with the client 30 and approves the confirmation request by signing using electronic signature capture.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via the public or private digital communications network connection (e.g., an Internet connection).
  • the credit card information may be provided by the requestor 20 or client 30.
  • step 4 either the confirmation system 50 or the requestor 20 mails the confirmation request to the responder 2010.
  • the responder 2010 logs in to the confirmation system 50, inputs client response data, and approves the confirmation response in step 5.
  • the response data edits the client account data in the confirmation system 50 and approves a confirmation response having edited client account data.
  • step 6 the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 2010 completing the confirmation.
  • the responder auditor 2810 logs in to view the responder's response.
  • Figure 27 illustrates a variation of the confirmation system and method shown in Figure 26 in which responses are obtained from multiple responders (i.e., first responder 2010, second responder 2020, and third responder 2030) within the same business or company.
  • FIG 28 is a block diagram of another embodiment of a confirmation system and method is illustrated in which an electronic response is obtained after a paper confirmation request is made and a PIN is assigned to the client by the confirmation system for authentication.
  • the requestor 20 logs in to the confirmation system 50 by providing a username and password associated with the requestor 20 through an electronic communications network (e.g., a connection to the Internet) and inputs client account data.
  • the confirmation system 50 generates and sends a PIN to the client 30.
  • the client 30 provides the PIN to the requestor at step 3 which may occur offline or via electronic communications, but occurs without action by the confirmation system 50.
  • the requestor 20 inputs the PIN into the confirmation system 50 for validation and upon validation, the confirmation request is approved at step 4.
  • step 5 either the confirmation system 50 or the requestor 20 mails the confirmation request to the responder 2010.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via the public or private digital communications network connection (e.g., an Internet connection).
  • the credit card information may be provided by the requestor 20 or client 30.
  • the responder 2010 logs in to the confirmation system 50, inputs confirmation response data, and approves the confirmation response.
  • the response data edits the client account data in the confirmation system 50 and approves a confirmation response having edited client account data.
  • the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 2010 completing the confirmation.
  • the responder auditor 2810 logs in to view the responder's response.
  • Figure 29 illustrates a variation of the confirmation system and method shown in Figure 28 in which responses are obtained from multiple responders (i.e., first responder 2010, second responder 2020, and third responder 2030) within the same business or company.
  • FIG. 30 is a block diagram of another embodiment of a confirmation system in which an electronic response is obtained after a paper confirmation request is made and the client signs the paper request.
  • the requestor 20 logs in to the confirmation system 50 by providing a username and password associated with the requestor 20 through an electronic communications network (e.g., a connection to the Internet) and inputs client account data to initiate a confirmation request client account data.
  • the confirmation system 50 provides a paper confirmation request to the client 30 for signing.
  • the client 30 can print the confirmation request by accessing the confirmation system 50, or the confirmation system 50 can mail a paper copy of the confirmation request to the client 30.
  • the client 30 signs the paper confirmation request at step 3 and provides (e.g., mails) the signed request to the requestor 20.
  • the requestor 20 then mails the confirmation request to the responder 2010 at step 4.
  • the responder 2010 logs in to the confirmation system 50, inputs confirmation response data, and approves the confirmation response at step 5.
  • the response data edits the client account data in the confirmation system 50 and approves a confirmation response having edited client account data.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via the public or private digital communications network connection (e.g., an Internet connection).
  • the credit card information may be provided by the requestor 20 or client 30.
  • the requestor 20 accesses the confirmation system 50 with the username and password associated with the requester 20 and retrieves the completed confirmation.
  • the confirmation system 50 may indicate to the requestor 20 that the completed confirmation is available via electronic mail.
  • the requestor 20 can also download related reports.
  • the confirmation system 50 may send the requestor 20 the completed confirmation and related reports by, for example, electronic mail in response to the responder 2010 completing the confirmation.
  • the responder auditor 2810 logs in to view the responder's response.
  • Figure 31 illustrates a variation of the confirmation system and method shown in Figure 30 in which responses are obtained from multiple responders (i.e., first responder 2010, second responder 2020, and third responder 2030) within the same business or company.
  • responders i.e., first responder 2010, second responder 2020, and third responder 2030
  • Figure 32 discloses additional embodiments of the invention wherein factoring transactions are confirmed. Steps performed by the confirmation system are generally performed automatically. That is, the confirmation system responds to receiving the completion of a step prior to a step conducted by the confirmation system by conducting the next step in the process without further intervention or prompting, such as by a user of the confirmation system.
  • FIG 32 is a block diagram of one embodiment of a confirmation system and method implemented in the context of confirming accounts receivables in factoring transactions.
  • a business client 30 that desires to factor its receivables remotely logs in to the confirmation system 50 via the communications network (e.g., the Internet) by providing a username and password associated with the client 30.
  • the client 30 enters factoring request data, approves the factoring request, and electronically inputs the factoring request into system 50 in step 1.
  • the confirmation system 50 processes a credit card for payment by interacting with credit card processor 2800 via a digital communications network.
  • the credit card information may be provided by the first factor 3220, a second factor 3230, or the client 30.
  • the responder 3210 i.e., a debtor of the client 30
  • remotely logs in to the confirmation system 50 inputs factoring response data, and approves the factoring response that includes the input factoring response data.
  • one or more receivers or factors i.e., the first factor 3220 and/or the second factor 3230
  • the confirmation system 50 may indicate to the factor (e.g., the first factor 3220 and/or the second factor 3230) that the completed confirmation is available via an electronic mail message or other notification.
  • the factor e.g., the first factor 3220 and/or the second factor 3230
  • the confirmation system 50 may send the factor (e.g., the first factor 3220 and/or the second factor 3230) the completed accounts receivable confirmation and related reports by, for example, electronic mail in response to the debtor 3210 completing the confirmation.
  • the client 30 may indicate which factors (e.g., the first factor 3220 and/or the second factor 3230) are to receive which completed accounts receivable confirmations by including the email addresses of the factors in the accounts receivable data provided to the confirmation system 50 by the client 30.
  • the confirmation system 50 may receive offers for one or more confirmed accounts receivable in the completed accounts receivable confirmation from one or more factors and provide at least one of the received offers to the client 30.
  • the confirmation system 50 may optionally only provide the highest offer for each accounts receivable to the client 30.
  • a computer or computing device such as described herein has one or more processors or processing units, system memory, and some form of computer readable media.
  • computer readable media comprise computer storage media and communication media.
  • Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Communication media typically embody computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Combinations of any of the above are also included within the scope of computer readable media.
  • the computer or computing device may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer.
  • a remote computer such as a remote computer.
  • embodiments of the invention are operational with numerous other general purpose or special purpose computing system environments or configurations.
  • the computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the invention.
  • the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment.
  • Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, interactive video game consoles, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
  • Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices.
  • the computer-executable instructions may be organized into one or more computer-executable components or modules.
  • program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.
  • aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
  • aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network (e.g., a local area network and/or the Internet).
  • program modules may be located in both local and remote computer readable storage media including memory storage devices.
  • a general purpose processor e.g., microprocessor, conventional processor, controller, microcontroller, state machine or combination of computing devices
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • steps of a method or process described herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

Abstract

Selon l'invention, un système (50) et un procédé facilitent le processus de confirmation ou d'affacturage impliquant un client d'entreprise, un auditeur et un répondant tiers par fourniture de confirmations pour le client lors d'une requête du client ou de l'auditeur. Une requête de confirmation soumise par le demandant (20) ou par le client (30) sera stockée dans un système de confirmation informatique sur le réseau et transmise au répondant tiers pertinent (par exemple un créancier ou un débiteur du client). La tierce partie fournit ensuite des données de confirmation nécessaires (c'est-à-dire des données de réponse) au système de confirmation qui transfert une confirmation achevée à l'auditeur ou à l'affactureur. La tierce partie impliquée peut être une banque ou une institution financière (10), une autre entité en relation commerciale avec le client, ou n'importe quelle autre entité qui a accès aux données demandées, associées au client, telle qu'un professionnel légal ou un consommateur ayant des comptes fournisseurs avec le client.
EP12804079.7A 2011-06-27 2012-06-26 Système et procédé pour fournir des confirmations de compte financier Withdrawn EP2724311A4 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201161501650P 2011-06-27 2011-06-27
US201161501648P 2011-06-27 2011-06-27
US201161501646P 2011-06-27 2011-06-27
PCT/US2012/044223 WO2013003361A2 (fr) 2011-06-27 2012-06-26 Système et procédé pour fournir des confirmations de compte financier

Publications (2)

Publication Number Publication Date
EP2724311A2 true EP2724311A2 (fr) 2014-04-30
EP2724311A4 EP2724311A4 (fr) 2015-03-11

Family

ID=47424768

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12804079.7A Withdrawn EP2724311A4 (fr) 2011-06-27 2012-06-26 Système et procédé pour fournir des confirmations de compte financier

Country Status (4)

Country Link
EP (1) EP2724311A4 (fr)
AU (1) AU2012275567A1 (fr)
HK (1) HK1198489A1 (fr)
WO (1) WO2013003361A2 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030078896A1 (en) * 2001-10-24 2003-04-24 Fox Charles Brian Systems, methods and computer program products facilitating automated confirmations and third-party verifications
US6601175B1 (en) * 1999-03-16 2003-07-29 International Business Machines Corporation Method and system for providing limited-life machine-specific passwords for data processing systems

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562040B2 (en) * 1998-11-05 2009-07-14 Loeper David B Method, system and computer program for auditing financial plans
US7831488B2 (en) * 2001-10-24 2010-11-09 Capital Confirmation, Inc. Systems, methods and computer readable medium providing automated third-party confirmations
US20040083148A1 (en) * 2002-05-13 2004-04-29 Virtualcash, Inc. Software computer application program product whose process, method and system refers, screens, matchs, approves, tracks and transfers prospective potential clients trusts, estates, investment management and other traditional trust products and service accounts whose invention is directed to trust vendors, independent trust companies, state and federal bank trust departments and other financial institutions and professionals
US20050131818A1 (en) * 2003-08-21 2005-06-16 Desal Nishith M. Method for performing Due diligence and legal, financial and other types of audits
US8244643B2 (en) * 2008-11-08 2012-08-14 Fonwallet Transaction Solutions, Inc. System and method for processing financial transaction data using an intermediary service

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6601175B1 (en) * 1999-03-16 2003-07-29 International Business Machines Corporation Method and system for providing limited-life machine-specific passwords for data processing systems
US20030078896A1 (en) * 2001-10-24 2003-04-24 Fox Charles Brian Systems, methods and computer program products facilitating automated confirmations and third-party verifications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HAYES J: "Policy-based authentication and authorization: secure access to the network infrastructure", COMPUTER SECURITY APPLICATIONS, 2000. ACSAC '00. 16TH ANNUAL CONFERENC E NEW ORLEANS, LA, USA 11-15 DEC. 2000, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 11 December 2000 (2000-12-11), pages 328-333, XP010529830, DOI: 10.1109/ACSAC.2000.898887 ISBN: 978-0-7695-0859-7 *

Also Published As

Publication number Publication date
WO2013003361A2 (fr) 2013-01-03
WO2013003361A3 (fr) 2013-04-18
AU2012275567A1 (en) 2014-02-20
HK1198489A1 (en) 2015-05-08
EP2724311A4 (fr) 2015-03-11

Similar Documents

Publication Publication Date Title
US8543475B2 (en) System and method for obtaining automated third-party confirmations in receivables factoring
US8442880B1 (en) Systems, methods and computer readable medium providing automated third-party confirmations
US20200394650A1 (en) Systems and methods for a private sector monetary authority
US20210398121A1 (en) Systems and methods for a private sector monetary authority
US9413737B2 (en) Method and system for using social networks to verify entity affiliations and identities
US7177830B2 (en) On-line payment system
US20020029194A1 (en) System and method of managing financial transactions over an electronic network
US20190019179A1 (en) Vpew digital wallet
US20040230524A1 (en) Charity bundling site
US8510185B2 (en) Systems and methods for obtaining automated third-party audit confirmations including client physical signatures, pin access, and multiple responders
AU2024200307A1 (en) Systems and methods for obtaining accountant prepared financial statement confirmation
WO2014143720A2 (fr) Systemes et procedes pour une autorite monetaire du secteur prive
US8484105B2 (en) System and method for providing business audit responses from legal professional
US20160048845A1 (en) Method for eliminating the use of paper in electronic transactions by legally valid manuscript biometrics, so-called formalised paperless solution
WO2013003361A2 (fr) Système et procédé pour fournir des confirmations de compte financier
Kabir Letter of Transmittal
US20230274350A1 (en) Systems and methods for obtaining accountant prepared financial statement confirmation
WO2019211664A1 (fr) Plate-forme de paiement pour sécuriser des paiements
Chopra et al. Summaries for the 2017 IRS-SJSU Small Business Tax Institute
Deshmukh The Revenue Cycle
WO2016076805A1 (fr) Système d'acheminement de créance datée

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140127

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20150206

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 40/00 20120101AFI20150202BHEP

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1198489

Country of ref document: HK

17Q First examination report despatched

Effective date: 20151207

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20160618

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1198489

Country of ref document: HK