Patent Application
20240020648
Employment opportunities and career roles are increasingly becoming automated. As a result, many job opportunities and professions have ceased to exist or have been otherwise rendered financially obsolete. In some cases, the automation is the result of efficiency, robotics, AI, or other substitutes for human intelligence and labor. The result is an increasing risk of unemployment, which can eventually result in widespread personal financial difficulties for many families. In aggregate, these personal financial crises can cover industries, regions, or nations. Many organizations and agencies, such as local and federal governments, private organizations, charities, and the like, provide benefits and grants to persons creating a social safety net. The benefits can include funds in the form of basic income, guaranteed income, cash benefits, and the like. However, the administration of these programs and processes can be challenging in many ways.
As just one example, a recent fraud scheme involved a ring of co-conspirators stealing approximately $2,000,000 in unemployment benefits from the State of California. In that scheme, the co-conspirators would acquire personally identifiable information (PII) such as names, dates of birth, and social security numbers of individuals who were not eligible for unemployment benefits, including pandemic benefits, because they were employed, retired, or incarcerated. The co-conspirators then allegedly used the information to make fraudulent online applications for benefits from the California Employment Development Department (EDD). Once the applications were approved, members of the conspiracy received EDD-funded debit cards that allowed them to withdraw money from automated teller machines across Southern California.
This incident is just one example of many. For organizations such as governmental, business, academic, or otherwise, which distribute benefits, payments, and the like, some of the biggest obstacles are verifying eligibility of the persons involved, including whether they have told the truth on their registration forms, distributing payments in a way that can subsequently be guaranteed, confirming receipt, recording results, and auditing results.
Features and advantages of the example embodiments, and the manner in which the same are accomplished, will become more readily apparent with reference to the following detailed description taken in conjunction with the accompanying drawings.
Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and/or convenience.
In the following description, details are set forth to provide a reader with a thorough understanding of various example embodiments. It should be appreciated that modifications to the embodiments will be readily apparent to those skilled in the art, and generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the disclosure. Moreover, in the following description, numerous details are set forth as an explanation. However, one of ordinary skill in the art should understand that embodiments may be practiced without the use of these specific details. In other instances, well-known structures and processes are not shown or described so as not to obscure the description with unnecessary detail. Thus, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
As more jobs become automated and rendered obsolete, whether through advances in efficiency, robotics, AI, or other substitutes for human intelligence and labor, the risk of unemployment also increases. To mitigate such crises, organizations (e.g., government agencies, charities, NGOs, universities, etc.) overseeing large communities of people (e.g., town, city, state, country, region, jurisdiction, province, campus, etc.) provide people with financial aid in the form of funds and other benefits. However, ensuring that people are eligible (i.e., meet the requirements for the benefit as set forth by the organization or other governing body, etc.) and ensuring that payments are distributed successfully (and only repeated as intended, if repeat payments are indeed intended, including preventing duplicate payments) can be difficult. For example, fraud is becoming more prevalent, leading to payment of benefits to ineligible persons, overpayments of benefits to eligible persons, lack of payments to eligible persons, and the like. In many cases, the fraud is the result of identity theft.
The example embodiments are directed to a host platform that can verify the eligibility of persons for a benefit (e.g., unemployment benefits, social security benefits, disability benefits, basic income payments, grants, etc.). To do so, the host platform can verify the identity of a person, verify income of the person, verify any other payments received including from the same or similar benefit program, and the like. The platform may include multiple machine learning processes that can enhance data and make it more feasible to match and verify data records, such as payment transactions and data records with personally-identifiable information (PII) including first name, last name, social security number, address, email address, phone number, and the like. Furthermore, the host platform may also manage the disbursements of payments in a way that ensures only one payment is made to the eligible person per benefit period and that such payment is confirmed. The host platform may also create an auditable trail of the payments ensuring that others can subsequently audit the payments to ensure the person was paid properly.
In the example embodiments, a benefit may refer to funding such as basic income, or the like. Basic income is a stream of financial grants paid by governmental and/or non-governmental (e.g., social) organizations to residents and/or citizens of particular localities, regions, or nations, with the goal of wholly or partially satisfying the basic needs that those individual residents and/or citizens have. Distribution may or may not have a means test, and the amount of funds in a given disbursement may or may not depend on means, e.g., such that the amount of funds depends on the means that a person possesses. Additionally, basic income may include but is not limited to universal basic income (UBI), which is a benefit paid to all citizens of a given population, such as a town, city, state, country, etc. Cash benefits are benefits paid to individuals in fungible monetary units, typically on a fixed, periodically-recurring basis, with or without a defined end date. Guaranteed income is a stream of cash benefits payments made by governmental and/or non-governmental (e.g., social) organizations to help stabilize the financial lives of individuals and their families by providing an income floor that aims to address their basic needs.
When an organization, whether governmental, social, business, or otherwise, wants to distribute basic income, guaranteed income, or any other type of cash benefits program funds to individuals, several obstacles exist. Some of the obstacles include verifying whether a participant of a benefit program is eligible to receive such a benefit. In other words, does the person satisfy the criteria for the benefit, which may include restrictions on income, assets, property values, debts, and the like, based on the information provided and/or gathered?
In the example embodiments, the host platform may determine an individual's eligibility for grants and cash benefits, when they are initially applying for or being included in any relevant programs. Also, the host platform may recertify existing users upon request, at predetermined periodic intervals, upon checking whether particular conditions exist, and the like. In addition, the host platform may verify income and prevent fraud, when an eligibility test is performed. Furthermore, the host platform may verify the eligibility for basic income, guaranteed income, and/or any other cash benefits programs, or the like, including but not limited to demographic and residency requirements, as well as current period payment status (e.g., unpaid, pending, paid, hold, etc.). Furthermore, the host platform may verify each individual's eligibility for basic income grants, guaranteed income, and/or any other cash benefits programs, on an ongoing basis, as is appropriate for each particular program.
The host platform may also participate and manage the disbursement of funds/benefits as part of the benefit administration. For example, the host platform may include a scheduler that can schedule payments to a user at future times and trigger those payments at the future times. Furthermore, proof of such payments and proof of confirmation of such payments (e.g., by a financial institution or the person themselves) may be stored in an auditable and immutable trail on a blockchain ledger or other distributed environment. The host platform provides a mechanism for administering basic income, guaranteed income, and/or any other cash benefits programs to individuals in an automated and verifiable manner.
Some of the benefits of the verification platform described herein include the generality of solution, which enables multiple basic income cases to be addressed, including but not limited to partial basic income grants, full basic income grants, universal basic income (UBI) grants, guaranteed income grants, and any other cash benefits payments. The verification platform also provides an automated methodology for administering payments under the benefits program, which can lower administrative overhead, improve delivery reliability, and provide ongoing recertification and funds distribution, as needed. Furthermore, the host platform may serve as a certification authority capable of certifying income, identity, and the like. These verifications may be performed using various machine learning models, which can enhance the data that is ingested and add additional attributes to the data, which can be used to analyze and act based on the data.
In some embodiments, the verification platform may include or otherwise be embodied as a blockchain network of distributed computing machines/virtual machines, however, embodiments are not limited thereto. The blockchain network may be a public, permissioned, or private blockchain network. Examples of the types of blockchain frameworks that can be used include Ethereum, Solana, EOS, Cardano, Hyperledger Fabric, and the like. As an example, an application server may host a mobile application or web application that provides the verification processes described herein. The application server may be coupled to a blockchain network and may transmit results of the verification processes and confirmations of the payments to a blockchain ledger of the blockchain network. The blockchain network may include a plurality of blockchain-enabled peers (e.g., distributed computing machines, virtual machines, etc.) that work together to write to and/or manage the blockchain ledger.
Each of the blockchain-enabled peers may be a member of the blockchain network and may include a local copy of the blockchain ledger. Depending on the choice of blockchain protocol employed for the particular application, the peers may execute consensus-based protocols and network-wide communications including gossip to ensure that no single peer can update the blockchain ledger by themselves and also to ensure that a state of the content stored in the blockchain(s) on the local blockchain ledgers of all of the peers is the same/synchronized. Furthermore, to ensure that the blockchain ledger is “immutable” and thus cannot be changed, each new block added to the ledger may include a hash pointer to an immediately previous block on the blockchain ledger. For example, a committing peer may hash a value from the previous block (e.g., a block header, block data section, block metadata, or the like) and store the hash value in the new block (e.g., in a block header, etc.).
The blockchain-enabled peers may be trusting entities or untrusting entities with respect to each other. In some embodiments, the blockchain-enabled peers may work together to achieve a consensus (i.e., an agreement) on any data that is added to the blockchain ledger before it is committed. In some cases, peers may have different roles and peers may have multiple roles. As an example, a committing peer refers to a peer that stores a local copy of the blockchain ledger and commits blocks locally to its instance of the blockchain ledger. Most if not all peers in the blockchain network may be committing peers. Prior to the data being committed, peers execute a consensus process of some kind to ensure that the requirements for adding the data to the blockchain ledger (e.g., specified by policy of the blockchain, etc.) have been satisfied. Examples of consensus processes include proof of work, endorsement, proof of stake, proof of history, and the like.
An ordering service or ordering peer may receive transactions which are to be added to the blockchain and order the transactions based on priority (e.g., time of receipt, etc.) into a block. After the block is filled, the ordering service may generate a new block and distribute the block to the committing peers.
In some embodiments, blockchain transactions may require “endorsement” by at least a small subset of peers within the blockchain network before being added to a new block. In this example, an “endorsing” peer may receive a new blockchain transaction to be stored on the blockchain ledger, and perform an additional role of simulating content (e.g., within the blockchain transaction) based on existing content stored on the blockchain ledger to ensure that the blockchain transaction will not have issues or fail. The endorsement process may be performed prior to adding the blockchain transaction to the block by the ordering service. Thus, in that case, only “endorsed” transactions may be added to a new block to be committed to the blockchain ledger. In some embodiments, only a subset of peers (e.g., a small group of trusted systems out of a larger group of systems of the blockchain network, etc.) may endorse transactions.
Although the examples herein refer to a host platform that is integrated with a blockchain network/blockchain ledger for storage of data, the data may be stored on other storage types as well and not just a blockchain ledger. For example, any data store such as a database, relational database, topic-based server, cloud platform, distributed database, and the like, may be used.
The host platform may ingest or otherwise collect data of the user via an application programming interface (API) 126. For example, the user may provide account identifiers of bank accounts, credit card accounts, checking accounts, debit card accounts, payroll-related accounts, and the like. The user may also provide access credentials and approve the host platform 120 to access their account information online. In addition, the user may submit account statements, payroll-related documentation, and the like via the API 126. The host platform 120 may use the account numbers and access credentials to ingest data from various external sources (e.g., the host financial institutions of the accounts, etc.), which may be accessed via one or more external APIs, etc.
In the example embodiments, the host platform 120 may make one or more verifications of a user when determining whether the user is eligible for a disbursement of a benefit, such as basic income or other funds. The verifications may include one or more of an identity verification 130, an income verification 140, eligibility verification 150, and the like. During the verification processes, the host platform 120 may execute one or more machine learning models that receive data content of the user as input and output predicted results. In one example, the predicted output may be a predicted, imputed, inferred, extracted, or otherwise estimated attribute of a transaction record where the attribute is not expressly included in the content of the transaction record. The predicted, imputed, inferred, extracted, or otherwise estimated attribute can be used to enhance the transaction record with additional details of the transaction. Furthermore, the “enhanced” transaction record can be easier to match with other transactions, because additional data points now exist.
In addition, the user may provide login credentials or other access means, such as keys, tokens, smart-contract-based credentials, and the like, which enable the host platform to establish an authenticated channel with the user's financial institutions to inspect transaction records from the user's account or accounts, an employer, a payroll provider of the employer, and the like. Also, the user may provide permission to the host platform to access corresponding user records held by any of the user's financial institutions, employer, payroll provider, benefit administration programs, and the like. The blockchain-enabled peer 121 may record the user data obtained from the registration process, including the user's details, in a blockchain transaction stored within a block 171 which is committed to the blockchain ledger 170.
In some cases, the host platform may create a separate instance of a blockchain for each user. In this example, the block 171 would be a genesis block (first block of the blockchain—or block zero) for that specific user upon initial user registration and account creation. As another example, multiple users and their data may be intertwined within the same blockchain, which naturally has a single genesis block, instead of a genesis block per user.
Referring back to
Blockchain-enabled peer 123 executes an income verification process 140 based on the data onboarded by the user including data ingested from the user transaction records held by the user's financial institutions, employer, payroll provider, and the like. Examples of the income verification process 140 are described in U.S. patent application Ser. No. 17/580,721, filed on Jan. 21, 2022, in the United States Patent and Trademark Office, the entire disclosure of which is incorporated herein by reference for all purposes. In addition, examples of income verification are described herein below. The results of the income verification process 140 may be recorded by the blockchain-enabled peer 123 in a block 173 which is committed to the blockchain ledger 170. For example, the result may include a pass/fails status, identifiers of any suspicious data records, identifiers of any other users, and the like.
Blockchain-enabled peer 124 executes an eligibility verification process 150 based on the data onboarded by the user including data ingested from the user transaction records held by the user's financial institutions, employer, payroll provider, and the like. The eligibility verification process may be conditioned on approval by successful execution of the identity verification process 130 and/or the income verification process 140, including any instances of fraudulent behavior that are detected during either verification process. The eligibility verification process 150 may compare information about the user's assets, income, identity, geography, and the like, to requirements for eligibility set forth by the benefits program that the user wishes to obtain benefits from. A result of the eligibility determination may be recorded in a block 174 committed to the blockchain ledger 170. The result may include a pass/fail eligibility determination, an indication of any requirements that the user does not satisfy and why, and the like.
As an example, the blockchain-enabled peer 124 may identify a geographic location of the user based on various data records that are obtained during the registration process or pulled/ingested from connected user accounts (such as bank accounts, etc.) to determine a geographical location where the user is currently residing. This location can then be compared to any geographical requirements of the benefit program. As another example, the blockchain-enabled peer 124 may identify a pattern of income (e.g., monthly, weekly, etc.) for the user based on transaction records which are ingested from connected financial accounts of the user and compare the income to any income requirements of the benefits program.
Blockchain-enabled peer 125 may read the user's onboarded data from block 171, the identity verification results from block 172, the income verification results from block 173, and the eligibility verification results from block 174 and generate a report which includes human-readable information about the results of the different verifications and the eligibility check. The report data and other output may be stored within a digital document that is encrypted and stored within a block 175 on the blockchain ledger 170.
As illustrated in
In response to receipt of the request, the blockchain-enabled peer 204 may create, install, and/or execute a smart contract, which can be deployed in the form of chaincode onto the blockchain ledger 210. The smart contract 211 may be configured to read and write from the blockchain ledger 210. The content of the smart contract 211, including the underlying code of the smart contact 211, may be written to a block 212 on the blockchain ledger 210. Other information about the plan such as connected payment accounts, dates, amount of funds, and the like, may be included within the block 212 as well. Although not shown, each new block added may be approved via a blockchain consensus process such as a validate, order, and commit process, as is known in the art of blockchain.
For example, the scheduler 213 may create a schedule for distributing payments to the user based on the plan data. The schedule may include one or more payments, such as a plurality of payments that each transfer a benefit of funds/income to the user on a recurring basis (e.g., every week, every 2 weeks, every month, etc.). Each payment may be for the same amount or for different amounts. The resulting schedule may include a table, a file, a document, a spreadsheet, or the like, which may be stored in a block 215 on the blockchain ledger 210 for future auditing purposes. Furthermore, the blockchain can add a hash pointer in block 215 that points to block 212 creating a link between the two blocks 212 and 215. In addition, the scheduler 213 may create timers in the form of jobs such as time-to-live (TTL) jobs, cron jobs, or the like. The jobs may be stored in a data store 214. Each job may have a timer that expires at a particular point in time in the future. As an example, when the timer expires, the job may send a message to the scheduler 213 causing the scheduler 213 to invoke a payment as further described in
In particular,
In this example, the host platform 320 may host an application that performs identity and/or income verification such as described herein. Here, a front-end 322 of the application may be downloaded from a marketplace, etc., and installed on a user device 310 such as a mobile device, a smart phone, a tablet, a laptop, a personal computer, etc. It should also be appreciated that the host platform 320 may host a web application, a website, an authentication portal, or the like, which can receive additional input from the user such as account numbers, identity information, images, and the like.
In this example, a user may input account numbers and/or routing numbers, login credentials, or the like, of bank accounts, employer accounts (e.g., gig employers, etc.), payroll company accounts, credit accounts, etc., held by trusted sources of truth such as banks, credit agencies, payroll processors, employers/organizations, institutions, and the like, into one or more input fields displayed within a user interface of the front-end 322 of the application and submit them to the host platform 320 by clicking on a button or the like within the user interface of the front-end 322. For example, the user device 310 and the host platform 320 may be connected via the Internet, and the front-end 322 may send the information via an HTTP message, an application programming interface (API) call, or the like. When the account identifiers are transmitted, a response containing relevant account information and the like may be received.
In response to receiving the account information, the host platform 320 may register/authenticate itself with various trusted sources of truth where the accounts/user accounts are held/issued. For example, the host platform may perform a remote authentication protocol/handshake with a financial institution server 332, a payroll processor server 334, and an employer server 336, another data source 338, and the like, based on user account information that includes an account issued by the bank, a source of funds from the payroll processor, and an employer that pays the user. These accounts provide the host platform with a unique mesh of partially-overlapping data sets that can be combined into one larger data set and analyzed. In the example embodiments, the combination of data from the different sources of truth (e.g., financial institution server 332, the payroll processor server 334, the employer server 336, and the other sources 338) can be combined into a data mesh 324 by the host platform 320. It should also be appreciated that the user may manually upload data such as documents, bank statements, account credentials, and the like, in a format such as a .pdf, .docx, spreadsheet, XML file, JSON file, etc. Furthermore, optical character recognition (OCR) may be performed on any documents, files, bank statements, etc. obtained by the host platform 320 to extract attributes from such documents and files.
The authentication process may include one or more API calls being made to each of the different third-party services (e.g., bank, payroll, employer, etc.) via a back-end of the software application on the host platform 320 to establish a secure HTTP communication channel. For example, the back-end of the software application may be embedded or otherwise provisioned with access credentials of the user for accessing the different third-party services. The back-end may then use these embedded, provisioned, and/or otherwise securely stored credentials to establish or otherwise authenticate itself with the third-party services as an agent of the user. Each authenticated channel may be established though a sequence of HTTP communications between the host platform 320 and the various servers. The result is a plurality of web sessions between the host platform 320 and a plurality of servers, respectively. The host platform 320 can request information/retrieve information from any of the servers, for example, via HTTP requests, API calls, and the like. In response, the user data can be transmitted from the servers to the host platform 320 where it can be combined the data mesh 324 for further processing.
In this example, a value for name 351 is separately identified from each (or most) of the data records, and compared to each other for consistency across records. Here, the corpus of data records 350 can be read by the host platform to identify name values 351 in each of the data records. The name values 351 can be extracted and stored in a table, a file, a document, or the like, and stored together in the same file, record, or other instantiation of a data structure, or the like, within the data mesh 324. If one or more data records do not have a name value, they can be ignored or omitted, or their absence can be part of the consistency checking process and algorithm. In this example, eight (8) name values are identified from PII included in eight different data records where some of the records are from various/differing sources of truth. The name values can be stored in the same file, record, or other instantiation of a data structure, or the like, in the data mesh 324 by the host platform even though they are extracted from different records. It should be further appreciated that in some embodiments, name values can be aggregated by source or account, for example, grouping transaction records to compare names associated with a plurality of different accounts, financial institutions, or the like.
This one consistency check may be enough to perform an identity verification. For example, it may be clear after just one consistency check that this user is not who they claim to be. As another example, it may take multiple different values of PII to be considered.
In
Based on one or more integrity scores, the back-end of the software application may make a decision of Yes or No that the identity is verified. This information may be used to modify or otherwise annotate via reference the original corpus of data records in the data mesh to include a value for such a decision. As another example, the identity verification process result, such as one or more of the integrity scores, may be an input into a decision by the back-end of the software application on whether to activate a new account with the software application based on the identity verification determination. Here, the host platform may only activate the account when the integrity score and/or integrity check values satisfy predefined thresholds. If so, the activation may enable the user to participate in the software application as an active user. This may give the user rights to send messages to other users of the software application, create an account profile, browse web listings, browse employment opportunities, prepare benefit-related applications, and the like.
In the example of
Based on the results of the detection process, the host platform may create different files or records within the data mesh as shown in the process 430 of
Thus, the host platform of the example embodiments is able to read through or otherwise process transaction data sets from different trusted sources and identify common/linked transactions between two or more transaction data sets. In other words, the host platform identifies transactions that overlap and/or otherwise correspond. This redundancy and/or correspondence can be used for verification purposes as noted by the above-incorporated patent applications.
Prior to and/or during the income verification process described in the examples of
Referring to
In some embodiments, the machine learning model 520 may be a neural network designed for the task of named entity recognition, which in this case classifies each word in a transaction string as part of a counterpart entity name, or not. The neural network may reason this by observing word placement and linguistic dependencies formed by other words in the transaction string. Accordingly, the machine learning model 520 is able to generalize over any transaction string format, as there are numerous possible formats that hard-coded rules would miss. The only data passed to the machine learning model 520 to make a prediction is the transaction string itself. Of course, some embodiments could include heuristics and/or rules, which may result from or otherwise inform, modify, and/or enhance machine learning models.
In some embodiments, the input may be the transaction string and the output may be the same data structure (e.g., document, file, table, spreadsheet, etc.) in which the transaction string is input with one or more additional values added including the identified counterpart entity and possibly other data such as date, location, payment type, and the like. In this way, the translation service may modify the input file to include a value or multiple values within a data structure thereof that makes it more helpful for processing by an addition analytics service.
In addition to enhancing the transaction records, the host platform described herein may “reconcile” transaction records prior to and/or during the income verification process described in
Referring to
In response, the machine learning model 630 may identify respective attributes in each of the transaction records. The machine learning model may output transaction attributes 631 identified by the machine learning model 630 from the transaction record 610 and transaction attributes 632 identified by the machine learning model 630 from the transaction record 611. Transaction attributes may include one or more of a payment amount, a payment date, a counterparty entity, a geographical location, and the like. In some cases, no attributes may be identified.
Next, the process 600B may be used to identify whether these two transaction records 610 and 611 reconcile/match a same transaction. Here, the transaction attributes 631 and 632 may be vectorized into a single vector 640 or multiple vectors, and input into a machine learning model 650, which may or may not be a deep learning neural network, other supervised learning model or the equivalent, or any of the other matching models described herein. In response, the machine learning model 650 may output a determination 651 indicating whether or not the two transaction records reconcile to a same transaction and a confidence score 652, indicating a confidence of the prediction (e.g., an accuracy, likelihood, etc.).
When determining whether a user is eligible for a benefit, such as a benefit offered by a basic income benefits program, the host platform may perform one or more of an identity verification, an income verification, a fraud detection, and the like, which are described herein as part of the eligibility verification of a user. The host may also retrieve criteria/qualifications of the benefits program that the user wishes to be certified with and determine whether or not the user qualifies for the benefits program based on the retrieved criteria and user-specific data, such as income data and other data of the user, which may be primarily obtained from authorized accounts of the user.
Referring to
In 706, the process determines whether the user should have one or more of an identity verification, an income verification, and fraud checks. In some cases, the process may perform all three of these checks or just one or more of these checks. In other cases, it may be configured not to check for these potential concerns, depending on the goals of the distribution program. Furthermore, the fraud checks may be embedded within the identity verification process. If the host system determines to execute one or more of the means tests, in 708 the checks are executed to identify whether the user meets/satisfies any income and/or identity verification requirements of the benefits program based authenticated data pulled from connected accounts of the user (i.e., connected to a host financial server of the accounts along with access credentials for accessing the user's account data). If the host system determines not to perform any checks, the process may skip to 710 without step 708. In 710, the process determines whether any additional checks are needed, such as means checks that may rely upon information gleaned and determinations made in 706 and 708, and in 712, the process can then execute the additional checks. If no additional checks are needed, then the process skips step 712 and moves to 714.
In 714, the process may calculate basic income, guaranteed income, grant, and/or cash benefits payment amounts based on user data and eligibility checks or look up amounts for existing users. If external confirmation is required, e.g. confirmation by a governmental or other agency, the host platform can trigger an external confirmation service via an endpoint of the external confirmation service, which is stored by the host platform. In 716, the process may determine a final assessment regarding the individual's eligibility for basic income, guaranteed income, grant, and/or cash benefits payments. Furthermore, the host system may generate any relevant reports, confirming with external parties as needed, prior to storing relevant information, calculation outputs, and other metadata in databases and optionally entering key information into an appropriate blockchain-based ledger for verifiable storage. In addition, the eligibility verification may be repeated or re-verified over time (e.g., prior to each disbursement, etc.).
The host system may receive a request from the user or from the benefits program to disburse payments in an automated manner to the user. In 722, the host system may schedule payments to be made based on administration data pulled from the user's file, blockchain profile, etc. An ongoing scheduler system may schedule future payments and trigger those payments when the time comes using timers such as those embodied in time-to-live (TTL) jobs, or the like. A calculation system can be configured to a particular set of criteria and goals, using user metadata and system settings. The system can determine an amount to pay to a user and a date on which such payment should be made based on details from the user's administration plan. In 724, the host waits until a next payment disbursement time is detected. For example, the host may detect a timer expiring, a time-to-live job expiring, or the like. In this case, the time-to-live job may have a pointer to a scheduled payment stored by the scheduler. Thus, the time-to-live job may also tell the host platform which payment is to be sent.
In 725, the host platform may determine whether or not the user needs to be re-certified. For example, a benefit may require that the user be re-certified prior to each disbursement or on some periodic basis (e.g., once a year, etc.). The recertification process may be performed to ensure that the user is still eligible for the benefit and may include identity verification, income verification, eligibility verification, and the like.
In 726, the host platform triggers the payment. Furthermore, confirmation with external parties regarding report may be received and recorded in 728. In other words, the financial institution that sends the payment can confirm that the payment was sent and even supply proof in the form of a bank statement, transaction record, etc. In some embodiments, the host platform can confirm, then automatically send payment once confirmed. As another example, the host can automatically send payment based on report criteria. Details of the disbursed payment may be stored in application database storage, and optionally stored in an appropriate blockchain storage location. Blockchain storage can vary by use case, including but not limited to using public, private, or permissioned blockchains individually and in tandem. In 730, the process may determine whether or not any additional disbursements exist for the user under the benefits program. If so, the process returns to step 724, otherwise it terminates.
In the example of
The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. A computer program may be embodied on a computer readable medium, such as a storage medium or storage device. For example, a computer program may reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disk, a removable disk, a compact disk read-only memory (“CD-ROM”), or any other form of storage medium known in the art.
A storage medium may be coupled to the processor such that the processor may read information from, and write information to, the storage medium. In an alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application specific integrated circuit (“ASIC”). In an alternative, the processor and the storage medium may reside as discrete components. For example,
The computing system 1000 may include a computer system/server, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use as computing system 400 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, tablets, smart phones, databases, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, distributed cloud computing environments, databases, and the like, which may include any of the above systems or devices, and the like. According to various embodiments described herein, the computing system 1000 may be, contain, or include a tokenization platform, server, CPU, or the like.
The computing system 1000 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. The computing system 1000 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.
Referring to
The storage 1040 may include a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server, and it may include both volatile and non-volatile media, removable and non-removable media. System memory, in one embodiment, implements the flow diagrams of the other figures. The system memory can include computer system readable media in the form of volatile memory, such as random-access memory (RAM) and/or cache memory. As another example, storage device 1040 can read and write to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”) and/or a solid state drive (SSD). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media, and/or a flash drive, such as USB drive or an SD card reader for reading flash-based media, can be provided. In such instances, each can be connected to the bus by one or more data media interfaces. As will be further depicted and described below, storage device 1040 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of various embodiments of the application.
As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module”, or “system.” Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Although not shown, the computing system 1000 may also communicate with one or more external devices such as a keyboard, a pointing device, a display, etc.; one or more devices that enable a user to interact with computer system/server; and/or any devices (e.g., network card, modem, etc.) that enable computing system 1000 to communicate with one or more other computing devices. Such communication can occur via I/O interfaces. Still yet, computing system 1000 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network interface 1010. As depicted, network interface 1010 may also include a network adapter that communicates with the other components of computing system 1000 via a bus. Although not shown, other hardware and/or software components could be used in conjunction with the computing system 1000. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.
As will be appreciated based on the foregoing specification, the above-described examples of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code, may be embodied or provided within one or more non-transitory computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed examples of the disclosure. For example, the non-transitory computer-readable media may be, but is not limited to, a fixed drive, diskette, optical disk, magnetic tape, flash memory, semiconductor memory such as read-only memory (ROM), and/or any transmitting/receiving medium such as the Internet, cloud storage, the internet of things, or other communication network or link. The article of manufacture containing the computer code may be made and/or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.
The computer programs (also referred to as programs, software, software applications, “apps”, or code) may include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus, cloud storage, internet of things, and/or device (e.g., magnetic discs, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The “machine-readable medium” and “computer-readable medium,” however, do not include transitory signals. The term “machine-readable signal” refers to any signal that may be used to provide machine instructions and/or any other kind of data to a programmable processor.
The above descriptions and illustrations of processes herein should not be considered to imply a fixed order for performing the process steps. Rather, the process steps may be performed in any order that is practicable, including simultaneous performance of at least some steps. Although the disclosure has been described regarding specific examples, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the disclosure as set forth in the appended claims.
