EP4348551A2 - Système et procédés automatisés pour transferts de biens électroniques considérables - Google Patents

Système et procédés automatisés pour transferts de biens électroniques considérables

Info

Publication number
EP4348551A2
EP4348551A2 EP22816992.6A EP22816992A EP4348551A2 EP 4348551 A2 EP4348551 A2 EP 4348551A2 EP 22816992 A EP22816992 A EP 22816992A EP 4348551 A2 EP4348551 A2 EP 4348551A2
Authority
EP
European Patent Office
Prior art keywords
payee
payment
data
asset
communication
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.)
Pending
Application number
EP22816992.6A
Other languages
German (de)
English (en)
Inventor
Robert BOWDON
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.)
Veritpay Intellectual Properties LLC
Original Assignee
Veritpay Intellectual Properties LLC
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
Priority claimed from US17/339,697 external-priority patent/US20220391904A1/en
Priority claimed from US17/371,068 external-priority patent/US20220391906A1/en
Priority claimed from US17/574,562 external-priority patent/US20220391907A1/en
Application filed by Veritpay Intellectual Properties LLC filed Critical Veritpay Intellectual Properties LLC
Publication of EP4348551A2 publication Critical patent/EP4348551A2/fr
Pending 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • 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/06—Asset management; Financial planning or analysis

Definitions

  • a rightful owner of an asset must proactively search the unclaimed property databases to look for unclaimed property that have been escheated.
  • a computer-implemented method includes the steps of receiving dormant account data associated with one or more asset owners, the dormant account data including at least an identity of the one or more asset owners, their last known address, and an asset to be returned to individual ones of the one or more asset owners; determining a living status of the one or more asset owners; enriching, with updated contact information, an asset owner data record associated with each of the asset owners; generating a unique communication to the one or more asset owners, the unique communication including at least an identification of the asset and instructions on how to recover the asset; and electronically delivering the asset to the asset owner.
  • the asset is a monetary asset and may include one or more of a payment, paycheck, a refund, securities, IRA account, safety deposit box contents, other personal property, or a deposit.
  • the living status of the one or more asset owners is performed automatically by searching death records.
  • other records may be searched to determine the living status, and may be inferred, for example, by recent payment transactions, updated employment information, and other such information that can be used to infer that an asset owner is living.
  • the step of enriching the asset owner data record comprises updating the asset owner data record with one or more of current contact information, employment information, and financial information.
  • the step of generating the unique communication comprises generating an electronic message.
  • the electronic message may be an electronic mail message addressed to an e-mail address and/or a text message addressed to a cellular telephone number.
  • the electronic message includes asset information, which may include an amount of the asset and a dormant account holder identity of the asset.
  • the step of electronically delivering the asset to the asset owner comprises a funds transfer through a peer-to-peer payment service.
  • a system includes one or more processors; and one or more computer-readable storage media comprising instructions that, when executed on the one or more processors, configure the system to at least: receive dormant account data associated with an asset owner; generate updated account data associated with the asset owner; enrich dormant account data with updated account data to create enriched asset owner data; generate, based at least in part on the enriched asset owner data, a unique communication to the asset owner; and initiate an electronic payment to the asset owner.
  • the unique communication to the asset owner includes an asset owner name, and one or more of dormant account data, asset amount, a dormant account date, and a link for the asset owner to receive the asset.
  • the dormant account data may identify the dormant account holder, a time during which the asset owner had an account with the dormant account holder or worked for the dormant account holder.
  • the instructions further cause the processors to configure the system to verify an identity of the asset owner prior to initiating the electronic payment to the asset owner.
  • the instructions may further cause the one or more processors to configure the system to verify a living status of the asset owner.
  • the instructions may further cause the one or more processors to configure the system to receive a selection from the asset owner of a desired payment platform for receiving the asset.
  • the payment platform may be a peer-to-peer payment platform.
  • the communication is sent to a computing device associated with the asset owner.
  • the computing device may be any type of computing devices, such as a smartphone, a cellular telephone, a laptop computer, a desktop computer, a tablet computer, a smart watch, or a smart vehicle.
  • the instructions further cause the processors to configure the system to generate a hyperlink specific to the asset owner.
  • the hyperlink may allow the asset owner to claim the asset, and may further provide a method for the asset owner to verify his or her identity, and select a payment platform for receiving the asset.
  • the instructions may further cause the one or more processors to configure the system to generate, at a future date, enriched asset owner data as new asset owner data becomes available.
  • the system may be configured to periodically search for updated contact information and then enrich the asset owner data and generate a communication when updated information becomes available.
  • FIG. 1 illustrates a system for automating asset delivery to an owner, in accordance with some embodiments
  • FIG. 2 illustrates a process for automating asset delivery to an owner, in accordance with some embodiments
  • FIG. 3 illustrates a process for automating asset delivery including data enrichment, in accordance with some embodiments
  • FIG. 4 illustrates a process for automatically enriching asset owner data records, in accordance with some embodiments
  • FIG. 5 illustrates a process for automatically verifying asset owner and initiating electronic delivery of asset to asset owner, in accordance with some embodiments
  • FIG. 6 illustrates an automated process for enriching asset owner data, generating a communication to the asset owner, and returning the asset to the asset owner, in accordance with some embodiments
  • FIGS 7A, 7B, and 7C illustrate example generated communications to an asset owner, in accordance with some embodiments
  • FIG. 8 illustrates a system for automating payment delivery to a payee, in accordance with some embodiments
  • FIG. 9. illustrates a process for automatically verifying the identity of a payee and processing a payment to the payee, in accordance with some embodiments;
  • FIG. 10 illustrates a system for automating payment to a payee, in accordance with some embodiments.
  • FIG. 11 illustrates a process for automating payment delivery to a payee, in accordance with some embodiments.
  • This disclosure generally relates to systems and methods for automatically returning assets to their rightful owners.
  • assets There are millions of accounts worth hundreds of millions of dollars, or even billions of dollars, that are held for the rightful asset owners and escheated to governments simply because either the rightful asset owner cannot be appropriately contacted, or because the rightful asset owner is unaware of the assets.
  • a government takes ownership and control of the assets, which may include, without limitation, financial instruments, financial accounts, deposits, refunds, earned paychecks, dormant accounts, royalty payments, insurance proceeds, securities, dividends, IRA accounts, contents of safety deposit boxes, cashier’s checks, personal property, and real property, among others.
  • the dormant accounts may be held by any of a number of companies, which may include financial institutions, former employers, utility companies, real estate lenders, impound accounts, escrow accounts, among others.
  • a company may send correspondence to the last known address of the asset owner.
  • the fee charged to the asset owner may typically be a percentage of the asset value, only the largest value assets provide sufficient motivation for a company to search out the asset owner in exchange for a percentage of the asset value. This leaves millions of asset owners devoid of their property.
  • a system is provided that automatically finds the asset owners and electronically delivers the assets to the rightful owners with little or no human intervention. This results in an efficient process that helps not only the asset owner by reuniting them with their asset, but also the dormant account holder that is no longer required to maintain records of the account or make repeated attempts to contact the asset owner at a last known address.
  • a dormant account holder is any entity that has an asset that has not been returned to the rightful owner.
  • the dormant account holder may include, without limitation, a former employer, a utility company, a company holding a deposit or refund, or any other entity that is holding an asset of value that has not been returned to the rightful owner.
  • a dormant account holder may include a company, a utility, a governmental agency, an educational institution, a real estate company, a landlord, or any other such company that holds a valuable asset for another.
  • an asset owner is the rightful owner of the asset within a dormant account.
  • an asset owner may not know of the dormant account or the asset that belongs to them.
  • the asset owner may have moved and the last-known address on file with the dormant account holder is no longer valid.
  • all the contact information of an asset owner may be out of date according to the dormant account holder’s records. In these cases, the dormant account is at risk of escheatment.
  • a system may be configured to take the existing asset owner data, which may include, without limitation, contact information such as last known address, telephone or cellphone number, email address, place of work, etc.; financial information such as banking institution information, account numbers, etc.; personal information such as marital status, social security number, tax ID number, known relatives, or other such information.
  • contact information such as last known address, telephone or cellphone number, email address, place of work, etc.
  • financial information such as banking institution information, account numbers, etc.
  • personal information such as marital status, social security number, tax ID number, known relatives, or other such information.
  • other information may be available within the existing asset owner data; however, in some cases, the existing asset owner data may be out of date or insufficient to effectively contact the asset owner.
  • a system 100 may include computing resources 102 having access to one or more processors 104 and memory 106 storing one or more modules 108.
  • the computing resources 102 may include any suitable computing resources, which may include one or more server computers, a distributed computing architecture, cloud computing resources, or otherwise.
  • the processor(s) 104 may include a central processing unit (CPU), a graphics processing unit (GPU) both CPU and GPU, or other processing units 104 or components known in the art.
  • each of the processors 104 may have access to memory 106 or may have its own local memory 106, which may store the one or more modules 108 which may include program data, operating system, or other type of instructions that cause the processor 104 to carry out acts.
  • the processor 104 may include multiple processors and/or a single processor having multiple cores.
  • the computing resources 102 may include distributed computing resources and may have one or more functions shared by various computing devices.
  • the computing resources 102 may have memory that includes computer-readable storage media (“CRSM”), which may be any available physical media accessible the by processor(s) 104 to execute instructions stored on the memory 105.
  • CRSM may include random access memory (“RAM”) and Flash memory.
  • RAM random access memory
  • CRSM may include, but is not limited to, read-only memory (“ROM”), electrically erasable programmable read-only memory (“EEPROM”), or any other medium which can be used to store the desired information and which can be accessed by the processor 104.
  • the computing resources 102 are in communication with one or more other computing systems including, but not limited to, private databases, 109, public databases 110, dormant account holder system 112, a communications system 114, a client device 115 associated with an asset owner 118, and a payment system 120.
  • the communications between the variously described systems may be performed over a network 116, as is generally known in the art.
  • the dormant account holder system 112 may include a dormant account holder database 122, that may be populated with data regarding dormant accounts, and may include any information associated with an asset owner.
  • the various computing systems described herein such as, without limitations, the dormant account holder system 112, the communications system 114, the client device 115, and the payment system 120, may all be in communication at one time or another with the computing resources 102 to facilitate the methods, processes, and systems described herein.
  • the computing systems may be local system with one or more server computers, distributed computing system, cloud computing systems, or a combination of variously computer architecture systems.
  • the computing resources 102 may be in communication with an enriched data records 124 database which it may maintain and populate with data associated with an asset owner.
  • the enriched data records 124 populated by the computing resources 102 will contain more recent data, or additional data not found in a corresponding asset owner data record of a dormant account holder database 122.
  • the enriched data records 124 will contain an entry that corresponds with an asset owner data record contained in the dormant account holder database 122, but the enriched data record 124 may contain additional information not found in the dormant account holder database 122.
  • the computing resources 102 receives dormant account data.
  • data associated with a dormant account may be retrieved from the dormant account holder database 122 by the dormant account holder system 112 and send, such as via network 16, to the computing resources 102.
  • the computing resources 102 may store the dormant account data in the enriched data records 124 database prior to, or during, a time in which the computing resources generates additional data to add or replace in the dormant account data record.
  • the computing resources may retrieve, discover, or generate new data to add to the dormant account record in the enriched data records 124 database and either replace or append the new data to create an enriched data record that includes additional or alternative information to the data provided from the dormant account holder database 122.
  • the additional data may be generated based upon searching one or more private databases 109.
  • the computing resources 102 are under control of a licensed private investigator who may have access to private databases that are not generally available to the public.
  • a licensed private investigator is a person that is licensed by one or more states and is able to access sensitive personal information that is not generally available to the public. This is due, in large part, because a licensed professional is required to complete mandatory education, training, and has been evaluated for probable integrity and trustworthiness. A licensed professional is held to a high standard of care with the available information. For example, if the private investigator improperly accesses or abuses the information, the licensed private investigator can lose his professional license and further be subject to penalties.
  • the computing resources 102 may access proprietary databases which may include, without limitation, address history, email addresses, deceased records search, phone numbers, social security records, bank records, credit bureau records, criminal records, property records, vehicle records, domain registrations, aircraft ownership, boat ownership, among other types of information.
  • the computing resources 102 may compare the information from the private databases 109 with the information stored in the enriched data records 124 and may append or replace data fields with more pertinent information. This may include more up to date contact information or adding information that was missing from the data record.
  • the enriched data record may be generated to include an updated email address, cell phone number, last-known job, or a determining of living or deceased. This data may be generated and appended within the enriched data record 124 to generate updated account data associated with individual account holders.
  • the enriched data records 124 may contain tens of thousands, hundreds of thousands, or millions of individual data records associated with unique asset owners.
  • An advantage of the described system and methods is that, in many embodiments, the computing resources are configured with instructions that cause the computing resources to automatically retrieve information from the private databases 109, the public databases 110, and generate enriched data records 124 to store in the enriched data records database.
  • the computing resources 102 may compare retrieved data from private databases 109 and/or public databases 110 with data in the enriched data records 124 and may supplement account data with current data. For example, in the case where an asset owner moves, the computing resources may compare two known addresses and determine which address is the most current and supplement the account data with the current data to generate the enriched data record. The same may be true for any type of data associated with the asset owner 118.
  • the computing resources may automatically generate asset owner contact.
  • the computing resources 102 may send instructions to the communications system 114 with asset owner 118 information, such as from the enriched data record 124 associated with the asset owner 118, and the communications system 114 may initiate contact with the asset owner using information from the enriched data record 124.
  • the enriched data record 124 includes updated information related to an asset owner’s physical address, cellphone number, or email address
  • the communications system 114 may generate a communication to contact the asset owner 118 through any known form of communication.
  • the communications system 114 may generate a message and send the message to the asset owner’s cellphone number.
  • the generated communication may include any of a number of textual elements, graphical elements, hyperlinks, and use any type of messaging protocol such as, without limitation, short message service (SMS), multimedia messaging service (MMS), enhanced message service (EMS), instant message (IM), and other types of messaging protocols.
  • SMS short message service
  • MMS multimedia messaging service
  • EMS enhanced message service
  • IM instant message
  • the generated communication may include personal information about the asset owner, such as, the asset owner’s name, account number, dates for which the asset owner was a customer or employee of a dormant account holder, as well as other information.
  • the generated communication may additionally include a link to allow the asset owner 118 to receive the asset.
  • the computing resources may communicate with a payment system 120 to enable the asset owner to receive the asset.
  • the generated communication may include a link that directs the asset owner to the payment system 120 that may be set up to allow the asset owner 118 to provide verification of identity and then electronically receive payment of the asset.
  • the payment system 120 may be configured to send payment through any suitable electronic means or non-el ectronic means.
  • Current examples of electronic payment platforms include platforms such as Venmo®, Zelle®, Xoom®, PayPal®, Google Pay®, and Apple Pay®, among others. These exemplary payment platforms may also be referred to as peer-to-peer payment services in which funds are transferred directly from a first account to a second account.
  • the second account may be a bank account, a rewards cards, a credit card, a debit card, an account associated with the payment platform, and the like.
  • a payment may be delivered to the asset owner by delivering a physical financial instrument, such as a check, a cashier’s check, a stock certificate, cash, a certificate of deposit, or some other physical financial instrument.
  • a dormant account holder may have hundreds or thousands of dormant accounts that each belong to unique asset owners 118.
  • the described system and methods facilitate the dormant account holder to efficiently find the asset owners by generated enriched data records and providing an electronic means for transferring the monetary assets to the asset owners 118.
  • the described steps may be performed automatically.
  • the computing resources may receive data from the dormant account holder database 122, which may be in a comma delimited file, a database file, a spreadsheet file, or some other data structure and then proceed to automatically search through public databases 110 and/or private databases 109, generate the enriched data record associated with an asset owner 118, generate a communication through the communication system 114 to the asset owner 118, verify the asset owner identity, and electronically transfer the monetary asset to the asset owner 118.
  • the dormant account holder database 122 which may be in a comma delimited file, a database file, a spreadsheet file, or some other data structure and then proceed to automatically search through public databases 110 and/or private databases 109, generate the enriched data record associated with an asset owner 118, generate a communication through the communication system 114 to the asset owner 118, verify the asset owner identity, and electronically transfer the monetary asset to the asset owner 118.
  • FIG. 3 illustrates a process flow 300 for verifying an asset owner.
  • the computing resources may determine the living status of a dormant asset owner. For example, where a data record is received from a dormant account holder database 122, the computing resources 102 may determine whether the asset owner associated with the data record is living or deceased. This may be performed, for example, by retrieving data from a living record database. In some cases, the system may infer a status of living, such as, for example, where an asset owner shows recent activity such as moving history, opening new accounts, changing telephone numbers, and the like.
  • the system automatically enriches the data associated with the asset owner by storing data associated with a living status and any additional details generated during verification.
  • the system generated a communication to the asset owner.
  • the communication may include any of the details found in the enriched data record, and may include, as an example, an identification of the dormant account holder, the dormant account number, a date or date range during which the asset owner had a relationship with the dormant account holder, personal information of the asset owner, and the like.
  • the communication may be sent through any suitable medium, and may include electronic communication (e.g., email, text messaging, etc.), physical mail sent to the asset owners’ last known address, telephone communications, or some other form of communication.
  • the communication may include a link (e.g., hyperlink) to visit one or more websites, such as to verify the identity of the asset owner and/or verify the identity of the dormant account holder, or arrange delivery of the asset.
  • the system may verify the identity of the asset owner. This may be performed through any suitable method, and may include, for example, requesting the asset owner to identify a previous address, telephone number, past or present relationship with a 3 rd party merchant, verify a payment range on a credit or mortgage account, or some other form of verification.
  • a payment is automatically generated to the account owner.
  • the payment is an electronic payment sent through an online payment processing center and the asset owner may be prompted to choose a payment merchant to receive the payment from.
  • FIG. 4 illustrates a logical process flow for enriching an asset owner data record.
  • the computing resources 102 may receive an asset owner data file. This may come, for example, from a dormant account holder who has information associated with an asset owner.
  • the asset owner may have had a prior relationship with the dormant account holder, and the dormant account holder may have assets, such as money, that it owes to the asset owner.
  • the dormant account holder has been unable to return the assets to the asset owner and may use a system, such as those described herein, to return the assets to their rightful owner.
  • the system determines the living status of the asset owner. This may be done, for example, by retrieving or generating data associated with current contact information, recent transactions, and the like. [0064] At block 406, the system may determine contact information of the asset owner. The system may have access to public databases, private databases, as well as other sources of information to find contact information associated with the asset owner.
  • the asset owner data file may be enriched with newly discovered or generated data associated with the asset owner, such as, without limitation, living status, the identification of family members or friends, credit history, telephone number, cellphone number, address, current or past employment, as well as other information.
  • the enriched data file may be used to generate a communication to the asset owner to return assets.
  • FIG. 5 illustrates a logical process flow for generating a communication and initiating an asset return to the asset owner.
  • the system 100 automatically sends a communication to the asset owner, which may include asset owner data.
  • the communication may include a text message that indicates that a company is holding assets that belong to the asset owner.
  • the assets may include, for example, a deposit, an overpayment on an account, a refund, a paycheck, among other things.
  • the communication may further include asset owner data such as the asset owner name, address, information associated with the dormant account holder (e.g., identity of dormant account holder, logo of dormant account holder, account number, dates that asset owner was associated with dormant account holder, and the like).
  • the communication is a one-to-one communication.
  • a unique message is created for each unique recipient.
  • the message includes information specific to the asset owner, such as an account number, a date of service, an identification of the asset, the source of the asset, among other information that make the communication unique to each recipient.
  • the system may verify the identity of the asset owner through any suitable method, such as those described herein in relation to other embodiments.
  • the system receives confirmation of a desired payment method. For instance, the asset owner may be prompted to select a desired payment method, and the system receives confirmation of the desired payment method. This may be done electronically, such as by the asset owner selecting from a list or drop-down menu, and the selection may be transmitted to the computing resources 102.
  • the payment method may include one or more of an electronic payment, automated clearing house payment, physical check, a credit at a merchant, a credit with the dormant account holder, a gift card, and the like.
  • the computing resources 102 may automatically initiate transfer of the asset to the asset owner.
  • the computing resources 102 may instruct the payment system 120 to send money to the asset owner through the desired payment method.
  • FIG. 6 illustrates a logical process flow 600 for automatically enriching asset owner data, generating communications, and delivering asset to asset owner.
  • the system e.g., computing resources 102
  • assets belonging to owners who have deceased can no longer be claimed, but rather, the property is escheated to the government.
  • bifurcating the unclaimed property by living and deceased asset owners increases efficiency by only processing asset owner data for the living asset owners.
  • the unclaimed property data is enriched with contact information for the portion of the data associated with living asset owners.
  • the contact information may include any information described herein and be generated according to any method with respect to any embodiment herein.
  • the enriched asset owner data is sent to the computing resources 102. This may be performed, for example, by a push from a remote computing system t the computing resources 102, by a pull from the computing resources 102, or through some other protocol.
  • the enriched data records 124 are stored in a relational database and may be stored on a physical memory associated with the computing resources 102. In some cases, the enriched data records 124 are stored remotely from the computing resources 102.
  • the system generates a communication and sends it to the living asset owners.
  • the communication may be any form of communication, such as those described herein, and may further include any information that may allow an asset owner to have confidence that the communication is legitimate, as described elsewhere herein with regard to embodiments described.
  • the system verifies the living asset owner identity, such as through challenge questions to the living asset owner.
  • the system presents asset delivery terms to the asset owner. For example, the asset owner is presented with a dollar amount of the owed asset, and the asset owner must agree to provide a portion of the asset as remuneration to a third party facilitating the return of the asset.
  • the terms may also include other terms, such as terms related to delivery time, delivery location, delivery amount, and the like.
  • the system processes payment to the asset owner.
  • the system may send instructions to a financial payment system with a payment amount and a delivery address to initiate the payment to the asset owner.
  • the delivery address may be an electronic address such as an email address, a telephone number address, and internet protocol address, an account number, a username to an account, or some other identifier that allows a payment to be sent to a desired recipient.
  • a dormant account holder may fund an escrow account based upon the volume of dormant accounts that it holds. As asset owners receive their assets and deplete the escrow account, the dormant account holder may replenish the escrow account once an account threshold has been met.
  • the described systems and methods offer numerous benefits to the dormant account holder as well as the asset owner. For example, the record keeping burden on the dormant account holder may be onerous and may be dictated by state laws. Accordingly, a dormant account holder that has locations in multiple states must be aware of, and comply with, the different state laws.
  • FIG 7A represents an initial contact with an asset owner once the asset owner data record has been enriched with current contact information.
  • the generated communication is being sent through a text message to the asset owners cellular telephone.
  • the initial communication may include any suitable information to lend legitimacy to the communication and may include, for example, the asset owners name, an account number, a date of contact between the asset owner and the dormant account holder, a company logo or company name associated with the dormant account holder, and instructions for either claiming the asset or opting out of claiming the asset.
  • FIG. 7B illustrates a communication containing a link, such as a hyperlink, that directs the asset owner to a website to verify the identity of the asset owner and claim the asset.
  • a link such as a hyperlink
  • FIG. 7C illustrates an example communication in which the asset owner has chosen to not receive the asset through the system.
  • an asset owner can decline to claim the asset through the systems and processes described herein, but rather, can either contact the dormant account holder directly to claim the asset, wait until the dormant account has been escheated and turned over to the government and the asset owner can go through the unclaimed property process that is overseen by a local government, or chose not to pursue the asset in which case the asset will escheat to the government.
  • FIG. 8 illustrates a system 800 for verifying the identity of a payee and processing a payment to the payee.
  • a payor owes remuneration to a payee.
  • a payor needs to make copious transfers to a plurality of payees.
  • initiating a payment to a payee may cost a considerable percentage of the payment amount, and in some cases, initiating the payment may cost more than the amount of the payment itself.
  • the cost of administering the payment process may result in a cost that is a significant amount compared with the total of the payments.
  • the costs to process the payments may be greater than 10%, or 20%, or 30%, or 50%, or 80%, or 100% or more compared with the amount of the payment or payments.
  • the payor is disincentivized from issuing owed payments because of the cost of processing the payments when compared to the amount of the payments.
  • the systems and methods disclosed and described herein may provide for an efficient system to handle copious payments, especially those of a smaller amount.
  • the systems described herein such as with reference to FIGS 1-7C, allow for numerous payments to be made by relying on a subset of the components and process steps described.
  • the system 800 includes computing resources 802 that may be any suitable computing resources, such as those described elsewhere herein, and may be one or more localized servers, may be a distributing computing environment, or some other architecture.
  • the computing resources 802 may have one or more processors 804 and physical memory 806 that may store one or more modules 808 executable by the one or more processors 804 to perform acts.
  • the system 800 may have access to one or more private databases 809, public databases 810, and other information.
  • a payor system 812 may be in communication with a payor database 822 that stores one or more payee data records.
  • a communications system
  • the 814 may be in communication with the computing resources 802 and/or the payor system 812, such as through a network 816, as described elsewhere herein with respect to any of the embodiments.
  • the communication system 814 may be configured to generate and/or send a communication to a payee 818, such as by sending an electronic message to a client device
  • a payment system 820 may be in communication with the computing resources 802 and can be configured to process a payment to the payee 818.
  • the computing resources 802 may generate a communication to a payee 818, such as by incorporating data contained in the payee data records, or the enriched data records 824 in order to send a communication to the payee that allows the payee to ascertain the purpose of the communication.
  • Such a system may be configured to allow a payor to electronically send payments to numerous payees with a high degree of automaticity, for a very low cost.
  • the system may be provided as a service and a payor may subscribe to the service.
  • the system may be licensed to a payor.
  • the system is made available to a payor on a per transaction basis.
  • the system may receive a payee data file.
  • the payee data file may include data identifying a payee and an amount of a payment, among other things.
  • the payee data file may include one or more of a payee name, a physical address, an email address, a cellular telephone number, a home phone number, an account number, a payment amount, a date of service associated with the payment, among other things.
  • the system may enrich the data provided in the payee data file, while in other cases, there may not be a need to enrich the data because the provided data is sufficient to carry out the process.
  • the system may enrich the data provided in the payee data file, such as, for example, by discovering updated contact information, in which case the payee data file may be enriched with the new data and updated.
  • the payee data file may be a part of a larger set of data files that may include a plurality of payee data files. For instance, an entity may provide payee data files for numerous payees, such as in a database file, or some other file format that the system can read and use to process payments.
  • the system may optionally determine contact information of one or more payees. For instance, as discussed in relation to embodiments herein, the system may search private and/or public records databases to discover contact information for a payee that may not be provided in the payee data file. The system can therefore enrich the payee data records, if necessary, and use the enriched data records in carrying out the methods described herein.
  • the system generates a communication with one or more payees.
  • the communication may be any type of suitable communication, as described herein, and may include information to allow the payee to ascertain what the payment relates to.
  • the communication may include one or more of a payee identity, an amount of payment, reason for payment, a date the payment became due to the payee, an identification of the payor, an account number associated with the payment, and a way to receive the payment, among other things.
  • the system verifies the identity of the payee and may be done by any suitable method, such as those discussed herein.
  • the payment may be processed and delivered to the payee.
  • the payee is aware that the payment is owed to the payee, while in other cases, the payee may not be aware that the payment is owed.
  • the payee can electronically receive the payment, such as through any suitable electronic payment platform as described elsewhere herein.
  • a class action lawsuit may identify individual members of a plaintiffs class.
  • the class may number hundreds, thousands, tens of thousands, or more individuals.
  • each of the members of the class may be entitled to a portion of the class action proceeds.
  • the members of the class receive a small portion of the class action proceeds, and the cost for processing and delivering the payments may be a substantial cost when compared to the amount of the payments.
  • the discloses system may receive payee data records associated with the members of the class, which may include payee name, mobile phone number, identification of the class action, and a payment amount.
  • the system may automatically generate a unique communication to each class member that may include an identification of the class action, the member name, and a link to verify identity of the class member and/or to receive payment.
  • the class member may follow the link to verify the class member’s identity through any suitable method, and then select to receive an electronic transfer of the payment amount. This process may happen for thousands of class members, or an even larger number of class members.
  • the disclosed system is capable of quickly and efficiently handling large numbers of payments to individuals.
  • the system receives a spreadsheet containing payee names, contact details (e.g., mobile phone number), and payment amounts.
  • the spreadsheet containing payee data records may number tens of thousands, and the system can efficiently process these payee data records, generate unique communications to each payee, verify the identity of each payee, and initiate an electronic payment to each payee.
  • the payee data records will include more than 10 unique payees, or more than 100 unique payees, or more than 1000 payees, and the system can be configure to automatically generate a communication and initiate an electronic funds transfer to the payees.
  • FIG. 10 illustrates a system 1000 for automating a payment to a payee in accordance with some embodiments.
  • the cost of administering the payment process including paying employees, the cost of equipment and supplies to print checks, postage, and the like may result in a cost that is a significant amount compared with the total of the financial transfer.
  • the costs to process the payments may be greater than 10%, or 20%, or 30%, or 50%, or 80%, or 100% or more compared with the amount of the financial transfer.
  • the payor is disincentivized from issuing owed payments because of the cost of processing the payments when compared to the amount of the payments.
  • the systems and methods disclosed and described herein may provide for an efficient system to handle copious payments, and can lead to a great deal of automation while still ensuring privacy, efficiency, and accuracy.
  • the systems described herein such as with reference to FIGS 1-9, allow for numerous payments to be made by relying on a subset of the components and process steps described.
  • the system 1000 may share many of the components as other embodiments described herein, such as those illustrated in relation to FIG 8.
  • the system 1000 includes computing resources 802 that may be any suitable computing resources, such as those described elsewhere herein, and may be one or more localized servers, may be a distributing computing environment, or some other architecture.
  • the computing resources 802 may have one or more processors 804 and physical memory 806 that may store one or more modules 808 executable by the one or more processors 804 to perform acts.
  • the system 800 may have access to one or more private databases 809, public databases 810, and other information.
  • a partner system 812 may be in communication with a partner database 1022 that stores one or more data records that may include the payee 818.
  • the partner system may be in communication with the payee 818, such as through a client device 815 associated with the payee.
  • the payee 818 may have an account with the partner system 1012 and may receive trusted communications from the partner system 1012.
  • the partner may be a bank at which the payee maintains one or more bank accounts
  • the partner system 1012 may be a banking system with which the payee 818 has interactions.
  • the client device 815 associated with the payee 818 may have a banking application installed that facilitates communication between the partner system 1012 and the payee 818 and may allow the payee 818 to view details of one or more bank accounts.
  • the partner system 1012 may include a communications system, and as described, may include an application that can send notifications, alerts, badges, icons, messages, or other forms of electronic communication to the client device 815 for the payee 818.
  • the communications may happen through the network 816, as is generally known in the art.
  • the partner system 1012 is configured to access a partner database 1022 that includes records that may contain data related to one or more payees.
  • the computing resources 802 may transmit data to the partner system 1012 that includes details of one or more payees, and the partner system 1012 may correlate the identity of the one or more payees with data stored in the partner database 1022. For example, where the computing resources send a social security number associated with a payee, the partner system 1012 may query the partner database 1022 to correlate the social number with a data entry in the partner database 1022.
  • the partner system 1012 may send a confirmation of correlation to the computing resources and/or send a communication to the client device 815 associated with the payee 818.
  • the data is used to mean that any identifying data sent by the computing resources 802 to the partner system 1012, is found by the partner system in the partner database 1022.
  • the computing resources 802 sends identifying information, such as a name, address, telephone number, social security number, account number, or some other type of identifying information
  • the partner system is able to find a match between one or more pieces of identifying information sent by the computing resources 802 in the partner database 1022
  • the data is correlated.
  • the data is correlated when the partner system 1012 determines that the payee has a current account or has a dormant account with the partner system 1012.
  • the partner system 1012 may be configured to generate and/or send a communication to a payee 818, such as by sending an electronic message to a client device 815 associated with the payee.
  • the electronic message may be any suitable message, and may include a message sent through an application controlled by the partner system, such as a push notification, an alert, a text message, a dashboard message, or otherwise.
  • the message may include text and/or images.
  • the message may provide information to the payee that the payee is eligible to receive a financial transfer and may provide instructions for receiving the financial transfer.
  • the payee is accustomed to receiving financial information from the partner system, 1012 and may be more likely to trust a notification regarding a financial transfer that is available to the payee than if the message simply came through an untrusted source.
  • a payment system 820 may be in communication with the computing resources 802 and/or the partner system 1012 and can be configured to process a payment to the payee 818.
  • the partner system 1012 may generate a communication to the payee 818, such as by incorporating data contained in the partner database 1022, to send a communication to the payee that allows the payee to ascertain the purpose of the communication.
  • the payment system 820 may be controlled or operated by the partner system 1012 and the financial transfer may be effectuated through the partner system 1012.
  • Such a system may be configured to allow a payor to electronically send payments to numerous payees with a high degree of automaticity, for a very low cost.
  • the system 1000 may receive a payee data file.
  • the payee data file may contain one or more data entries that identify one or more payees.
  • the data file may be in any suitable file type or data structure types.
  • a data entry in the data file is associated with a payee and includes one or more types of identifying information, such as, for example, a name, last known address, social security number, birth date, employment information, relative information, tax identification number, drivers license number, or some other type of identifying information.
  • the data file may additionally include details of a financial transfer to be made to the one or more payees, and may include the source of the financial transfers, the amount of the transfer, a date the transfer became available, and a date at which the financial transfer will be forfeited, among other information.
  • the system 1000 may optionally determine contact information of the one or more payees in the data file. This may be done, as described above, by searching one or more public or private databases to obtain additional information about the one or more payees. Additionally, the system 1000 may search death records to determine that the one or more payees are still living.
  • the system 1000 may enrich the data records, such as by updating employment information, contact information, living status information, and the like.
  • the system 1000 correlates information of the payee with the partner system.
  • the partner system may be a bank, an electronic payment platform (e.g., Venmo®, Zelle®, Xoom®, PayPal®, Google Pay®, and Apple Pay®, among others), or some other type of financial or communication platform.
  • the system 1000 may send the payee information (which may include the enriched data file) to the partner system, which determines that the one or more payees have identifying information that is found in the partner database (e.g., correlated).
  • correlating the payee information in the partner database indicates that the payee has a relationship with the partner, such as by having a financial account, a customer account, or some other type of relationship, with the partner.
  • the payee information may be correlated by matching one or more pieces of data in the payee record with one or more pieces of data in the partner database. For example, where the payee record is received by a partner and it includes a name, a telephone number, an address, a birth date, and a social security number, the partner database may match a social security number to correlate the payee information.
  • the partner system may determine that the name, birthday, and address match a data record in the partner database to correlate the payee information with an entry in the partner database.
  • any piece of data or combination of pieces of data associated with payee information may be used to correlate the payee information with an entry in the partner database.
  • the partner system sends a communication to the payee.
  • the communication may be through any suitable means, but in some cases, is sent as a push notification through an application controlled by the partner.
  • the financial transfer is sent to the payee. This may happen through any suitable mechanism, and may include depositing money into a payee account maintained by the partner, or may include another form of electronic funds transfer into any account associated with the payee.
  • the financial transfer may come through a payment system not affiliated with the partner, or may come through the partner system 1012.
  • the financial transfer may be crypto currency and deposited into a crypto wallet associated with the payee.
  • the terms payment and financial transfer may be used interchangeably. The terms refer to the transfer of anything of value, which may include financial instruments, crypto currency, digital works, non-fungible tokens, currency, or any other thing having value that can be transferred electronically or digitally.
  • the partner system 1012 may include a link on a website of the partner with a notification to all of its customers that may introduce the system 1000 as a trusted source of financial transactions.
  • Such suitable instances include, without limitation, class action settlements, employee paychecks, income tax refunds, property tax refunds, insurance proceeds, retirement account payments, credit balance returns, social security payments, jury duty payments, court deposit refunds, overpayment refunds, event ticket refunds, retail rebate payments, airline ticket refunds, excess proceeds payments, government stimulus payments, manufacturer rebate payments, property tax refunds, prepaid debit card balances, unclaimed property payments, healthcare provider payment returns, dormant account payments, hospital payment returns, jail commissary balances, capital credit distributions, utility deposit returns, dormant bank balance returns, insurance premium returns, account overpayment credits, casino cash-outs, sports betting payouts, multilevel marketing commission payments, credit card perk payments, royalty payments, dormant royalty payments, among others.
  • a payee data file that includes one or more payees can be received by the disclosed system.
  • the payee data file may include identification of the payees and may further include cell phone numbers and payment amounts associated with each payee.
  • the system may automatically generate communications with each of the payees in the payee data file, verify the identity of the individual payees, and then process electronic payments to the payees.
  • the system functions largely automatically, thus reducing cost to the payor, increasing efficiency, and increasing the speed at which the payment reaches the payee.
  • Conditional language such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and/or operations. Thus, such conditional language generally is not intended to imply that features, elements, and/or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or operations are included or are to be performed in any particular implementation.
  • the method steps described and/or illustrated herein may represent portions of a single application.
  • one or more of these steps may represent or correspond to one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks, such as the method step.
  • one or more of the devices described herein may transform data, physical devices, and/or representations of physical devices from one form to another. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and/or any other portion of a physical computing device from one form of computing device to another form of computing device by executing on the computing device, storing data on the computing device, and/or otherwise interacting with the computing device.
  • computer-readable medium generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions.
  • Examples of computer-readable media comprise, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems.
  • transmission-type media such as carrier waves
  • non-transitory-type media such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media),

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système de distribution de paiement automatisé qui combine des procédés de données d'enquête électroniques avec des systèmes de paiement fintech pour distribuer des paiements à des bénéficiaires. Le système peut être conçu pour recevoir des informations sur le compte du bénéficiaire, éventuellement pour enrichir les informations sur le compte du bénéficiaire par l'intermédiaire de données découvertes dans des bases de données publiques et privées, pour générer automatiquement des communications à chaque bénéficiaire, pour vérifier l'identité du bénéficiaire, pour envoyer des communications au bénéficiaire par l'intermédiaire d'un système partenaire, et pour initier un paiement électronique au bénéficiaire.
EP22816992.6A 2021-06-04 2022-06-06 Système et procédés automatisés pour transferts de biens électroniques considérables Pending EP4348551A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US17/339,697 US20220391904A1 (en) 2021-06-04 2021-06-04 Automated systems and methods for electronic asset recovery
US17/371,068 US20220391906A1 (en) 2021-06-04 2021-07-08 Automated systems and methods for copious electronic asset transfers
US17/574,562 US20220391907A1 (en) 2021-06-04 2022-01-13 Automated systems and methods for copious electronic asset transfers
US202217749097A 2022-05-19 2022-05-19
PCT/US2022/032387 WO2022256744A2 (fr) 2021-06-04 2022-06-06 Système et procédés automatisés pour transferts de biens électroniques considérables

Publications (1)

Publication Number Publication Date
EP4348551A2 true EP4348551A2 (fr) 2024-04-10

Family

ID=84324607

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22816992.6A Pending EP4348551A2 (fr) 2021-06-04 2022-06-06 Système et procédés automatisés pour transferts de biens électroniques considérables

Country Status (4)

Country Link
EP (1) EP4348551A2 (fr)
CA (1) CA3221047A1 (fr)
MX (1) MX2023014443A (fr)
WO (1) WO2022256744A2 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150022754A (ko) * 2012-03-30 2015-03-04 아이피 페이오베이션 피티와이 엘티디 결제장치 및 방법
US10846679B2 (en) * 2018-01-16 2020-11-24 Capital One Services, Llc Peer-to-peer payment systems and methods
US11386511B2 (en) * 2019-05-02 2022-07-12 Capital One Services, Llc Systems and methods for automated distribution of digital assets

Also Published As

Publication number Publication date
MX2023014443A (es) 2024-02-28
WO2022256744A3 (fr) 2023-01-19
WO2022256744A2 (fr) 2022-12-08
CA3221047A1 (fr) 2022-12-08

Similar Documents

Publication Publication Date Title
US11080782B2 (en) System and method for providing time to cure negative balances in financial accounts while encouraging rapid curing of those balances to a positive net position
US8781956B2 (en) Systems and methods for making structured reference credit decisions
US20180330342A1 (en) Digital asset account management
AU2007242060B2 (en) Automated budget management, multiple payment, and payment authority management
US20150339671A1 (en) Dynamic fraud alert system
US20120173570A1 (en) Systems and methods for managing fraud ring investigations
US20130103569A1 (en) Systems and methods for predictive modeling in making structured reference credit decisions
WO2012177786A1 (fr) Système et procédé de localisation et d'accès à des données de comptes
US8744962B1 (en) Systems and methods for automatic payment plan
US20120109723A1 (en) Systems and methods for management of credit groups
US20200242600A1 (en) System for leveraged collaborative pre-verification and authentication for secure real-time resource distribution
US20230196363A1 (en) Automated systems and methods for copious electronic asset transfers
US20220391906A1 (en) Automated systems and methods for copious electronic asset transfers
WO2014193324A1 (fr) Système d'établissement de rapport de risque
US20220391904A1 (en) Automated systems and methods for electronic asset recovery
US20200034844A1 (en) Implementing fraud controls on a hybrid network
US20130191248A1 (en) Method and system for providing secure loan-based transactions
EP4348551A2 (fr) Système et procédés automatisés pour transferts de biens électroniques considérables
US20130304629A1 (en) Self fullfilled online financial instrument
US20110307373A1 (en) System and method for Internet based peer-to-peer banking
AU2019229419A1 (en) Automated budget management, multiple payment, and payment authority management
JP7498379B1 (ja) 団信基幹システム及びプログラム
AU2019100225A4 (en) 3D Virtual Human AI Broking System
Mutheiwana Cash to Cashless: Transitioning Gauteng to a Cashless Economy
West et al. Bitcoin and Divorce

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231228

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)