Patent Description:
A distributed ledger, as used throughout this document, refers to a computer-only technology that enables a distributed recordation of transactions through the distributed ledger maintained by a network of computers. A blockchain is an example of a distributed ledger. BITCOIN(o:) is an example of a blockchain technology application.

A blockchain is a type of distributed ledger, which includes digitally-recorded, unmodifiable data in packages called blocks. A distributed ledger is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple computers which may be in different sites, countries, and/or institutions maintained by many different parties. A distributed ledger can be public, such as BITCOIN®, where there is no limitation on who may participate in the network, or private, where only approved parties are permitted to participate in the network.

<CIT> describes an automated lending and investment system that uses a matching engine to connect lenders and borrowers based on their risk profiles. <CIT> describes a blockchain-based platform for evaluating individuals' creditworthiness.

The illustrative embodiments provide for a method, system, and computer program product for facilitating peer-to-peer micro-loan transactions. A computer system determines an integrity score for each user of a plurality of users. The integrity score for each user is based on human capital management information for the user and peer-submitted feedback about the user. The computer system receives a loan transaction request from a borrower-user. The computer system determines a risk score for the loan transaction based at least on the borrower-user's integrity score and user information on capital management systems. The computer system identifies a set of lender-users based on the determined risk score and the lender-users' integrity scores. The computer system facilitates a negotiation of transaction terms between the borrower-user and the set of lender-users to determine the transaction terms. Responsive to finalization of the transaction terms, the computer system records the loan transaction and the transaction terms in a distributed ledger, and remitting loan funds to the borrower-user. Responsive to a subsequent repayment of the loan transaction according to the transaction terms, the computer system solicits peer-submitted feedback from at least one of the borrower-user and the set of lender-users. The computer system updates the integrity score for the borrower-user and the set of lender-users based on received peer-submitted feedback regarding the loan transaction.

The illustrative embodiments also contemplate a computer configured to execute program code which implements this method. The illustrative embodiments also contemplate a non-transitory computer-recordable storage medium storing program code, which, when executed, implements this method.

The illustrative embodiments, however, as well as a preferred mode of use, further objectives and features thereof, will best be understood by reference to the following detailed description of the illustrative embodiments of the present disclosure when read in conjunction with the accompanying drawings, wherein:.

The illustrative embodiments recognize and take into account one or more different considerations. For example, the illustrative embodiments recognize and take into account that workers around the globe receive their pay from payroll companies, but they rely on external banks if they need to ask for personal loans in an emergency situation. In almost all situations, external banks need to run detailed risk assessments in order to check if the requester will be able to fulfill repayment of the loan at the end of the contract terms. Another option people tend to use to request loans in smaller quantities is to ask consigned credit companies, which have sometimes cumbersome processes and don't always make clear to their customers all the fees involved in the loan process.

Currently, several startups in the financial technology sector (so-called Fintechs) are making use of data and mobile applications to provide quick, easy-to-use, <NUM>/<NUM> solutions to customers, with very competitive interest rates, closing some gaps that were not being fulfilled by traditional financial institutions. The expected growth rate for Fintech applications is around <NUM>%, with mobile money services that could evolve into a US$<NUM> trillion payments volume opportunity. ng to the same research, the <NUM> key technology enablers for Fintech applications use data analytics, mobile and artificial intelligence.

Currently, loaning of small amounts can be done solely between the financial institution and an individual. Currently, all the loan systems process for small quantities (e.g. microcredit) are cumbersome and don't have clearly stated conditions of the transaction. Usually, the interest rates for people seeking credit are not very enticing, and are not negotiable.

Furthermore, the illustrative embodiments recognize and take into account that payroll companies, as a provider of human capital management services, have lots of employee data and payroll information. Payroll companies, as a provider of human capital management services, are uniquely situated to access risks and understand financial behavior of an organization's employees. This valuable information can be used to quickly assess risks of a loaning process.

The methods and systems of the illustrative embodiments use data analytics based on payroll and HCM systems, in order to connect two profiles of workers: (<NUM>) workers in emergent need of micro-loans and (<NUM>) workers with extra resources willing to loan money at a very enticing rate with very low risk. As the customer base inside payroll and HCM systems is large and potentially spread in several countries; the method could find both people needing micro-loans and also people interested in providing loans at very enticing rates. Also, payroll companies can use the payroll transactions between borrowers and lenders as well to significantly reduce risk in the transaction.

Currently, there is no platform available for people seeking to complete transactions for the welfare of other individuals who have low risk, and in which their profile will be recognized in doing so in future transactions. The methods and systems of the illustrative embodiments simplifies the micro-loaning process and reduces risks, facilitating the process and making everything transparent, with the trust in the transaction being reinforced by the distributed network, and in distributed databases such as blockchain, as well as the payroll reinforcement from the borrowers side. In this case, a lender can be sure that if payment is not fulfilled, it will be directly subtracted from the borrower's payroll in subsequent months. Currently, there is no method or application in which the risk of a loan is enforced in a trust network between individuals.

The flowcharts and block diagrams in the different depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of apparatuses and methods in an illustrative embodiment as it relates to the disclosed application. In this regard, each block in the flowcharts or block diagrams may represent at least one of a module, a segment, a function, or a portion of an operation or step. For example, one or more of the blocks may be implemented as program code.

In some alternative implementations of an illustrative embodiment, the function or functions noted in the blocks may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be performed substantially concurrently, or the blocks may sometimes be performed in the reverse order, depending upon the functionality involved. Also, other blocks may be added, in addition to the illustrated blocks, in a flowchart or block diagram.

As used herein, the phrase "at least one of, " when used with a list of items, means different combinations of one or more of the listed items may be used and only one of each item in the list may be needed. In other words, "at least one of" means any combination of items and number of items may be used from the list, but not all of the items in the list are required. The item may be a particular object, thing, or a category.

For example, and without limitation, "at least one of item A, item B, or item C" may include item A, item A and item B, or item B. Of course, any combinations of these items may be present. In some illustrative examples, "at least one of" may be, for example, and without limitation, two of item A, one of item B, and ten of item C; four of item B and seven of item C; or other suitable combinations.

With reference now to the figures and, in particular, with reference to <FIG>, an illustration of a diagram of a data processing environment is depicted in accordance with an illustrative embodiment. It should be noted that <FIG> is only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the environments in which the different embodiments may be implemented. Many modifications to the depicted environments may be made.

<FIG> depicts a pictorial representation of a network of data processing systems in which illustrative embodiments may be implemented. Network data processing system <NUM> is a network of computers in which the illustrative embodiments may be implemented. Network data processing system <NUM> contains network <NUM>, which is a medium used to provide communications links between various devices and computers connected together within network data processing system <NUM>. Network <NUM> may include connections, such as wire, wireless communication links, or fiber optic cables.

In the depicted example, server computer <NUM> and server computer <NUM> connect to network <NUM> along with storage unit <NUM>. In addition, client computers including client computer <NUM>, client computer <NUM>, and client computer <NUM> connect to network <NUM>. These connections can be wireless or wired connections depending on the implementation. Client computer <NUM>, client computer <NUM>, and client computer <NUM> may be, for example, personal computers or network computers. In the depicted example, server computer <NUM> provides information, such as boot files, operating system images, and applications to client computer <NUM>, client computer <NUM>, and client computer <NUM>. Client computer <NUM>, client computer <NUM>, and client computer <NUM> are clients to server computer <NUM> in this example. Network data processing system <NUM> may include additional server computers, client computers, and other devices not shown.

Program code located in network data processing system <NUM> may be stored on a computer-recordable storage medium and downloaded to a data processing system or other device for use. For example, the program code may be stored on a computer-recordable storage medium on server computer <NUM> and downloaded to client computer <NUM> over network <NUM> for use on client computer <NUM>.

In the depicted example, network data processing system <NUM> is the Internet with network <NUM> representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers consisting of thousands of commercial, governmental, educational, and other computer systems that route data and messages. Of course, network data processing system <NUM> also may be implemented as a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN).

<FIG> is intended as an example, and not as an architectural limitation for the different illustrative embodiments. The illustration of network data processing system <NUM> is also not meant to limit the manner in which other illustrative embodiments can be implemented. For example, other client computers may be used in addition to or in place of client computer <NUM>, client computer <NUM>, and client computer <NUM> as depicted in <FIG>. Moreover, client computer <NUM>, client computer <NUM>, and client computer <NUM> may include a tablet computer, a laptop computer, a bus with a vehicle computer, and other suitable types of clients.

In the illustrative examples, the hardware used may take the form of a circuit system, an integrated circuit, an applicationspecific integrated circuit (ASIC), a programmable logic device, or some other suitable type of hardware configured to perform a number of operations. With a programmable logic device, the device may be configured to perform the number of operations. The device may be reconfigured at a later time or may be permanently configured to perform the number of operations. Programmable logic devices include, for example, a programmable logic array, programmable array logic, a field programmable logic array, a field programmable gate array, and other suitable hardware devices. Additionally, the processes may be implemented in organic components integrated with inorganic components and may be comprised entirely of organic components, excluding a human being. For example, the processes may be implemented as circuits in organic semiconductors.

The computer-readable program instructions may also be loaded onto a computer, a programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, a programmable apparatus, or other device to produce a computer implemented process, such that the instructions which execute on the computer, the programmable apparatus, or the other device implement the functions and/or acts specified in the flowchart and/or block diagram block or blocks.

With reference now to <FIG>, a block diagram of a micro-loan environment is depicted in accordance with an illustrative embodiment. As depicted, micro-loan environment <NUM> includes micro-loan system <NUM>.

In this illustrative example, micro-loan system <NUM> manages micro-loan transactions between users associated with one or more organizations. The organizations may be, for example, a corporation, a partnership, a charitable organization, a city, a government agency, or some other suitable type of organization. Organizations can encompass people who are employed by or associated with the organization. Users of micro-loan system <NUM> can be an employee of one or more organizations of the organizations.

In this illustrative example, micro-loan system <NUM> is implemented in computer system <NUM>. Computer system <NUM> is an example of network data processing system <NUM> of <FIG>.

Micro-loan system <NUM> may be implemented in software, hardware, firmware, or a combination thereof. When software is used, the operations performed by micro-loan system <NUM> may be implemented in program code configured to run on hardware, such as a processor unit. When firmware is used, the operations performed by micro-loan system <NUM> may be implemented in program code and data and stored in persistent memory to run on a processor unit. When hardware is employed, the hardware may include circuits that operate to perform the operations in micro-loan system <NUM>.

In this illustrative example, micro-loan system <NUM> facilitates peer-to-peer micro-loan transactions between borrower-user <NUM> and lender-users <NUM>. The distributed computing, and trust enabled, by micro-loan system <NUM> allows users greater control over the negotiation of transaction termsloan, as well as provides transparency and insight into the lending process.

Micro-loan system <NUM> includes one or more different components. As depicted, micro-loan system <NUM> includes loan coordinator <NUM>, blockchain <NUM>, and funds manager <NUM>. Using predictive modeling/indexing <NUM>, loan coordinator <NUM> determines integrity scores <NUM> for each user of a plurality of users. Integrity scores <NUM> for each user is based on human capital management information <NUM> for the user and peer-submitted feedback <NUM> about the user.

In response to receiving a loan transaction request <NUM> from borrower-user <NUM>, loan coordinator <NUM> determines a risk score <NUM> for the loan transaction. Loan coordinator <NUM> determines a risk score <NUM> based at least on integrity scores <NUM> of borrower-user <NUM>, as well as in the information available in the capital management system.

Loan coordinator <NUM> identifies a set of lender-users <NUM> based on the determined ones of risk score <NUM> and integrity scores <NUM> of potential ones of lender-users <NUM>. In response to identifying the set of lender-users <NUM>, loan coordinator <NUM> sends invitation <NUM> to the set of lender-users <NUM>.

Loan coordinator <NUM> facilitates a negotiation <NUM> between borrower-user <NUM> and the set of lender-users <NUM> to determine transaction terms <NUM>. In one illustrative example, loan coordinator <NUM> functions as an intermediary, passing messages <NUM> between borrower device <NUM> of borrower-user <NUM> and lender device <NUM> of the set of lender-users <NUM>. Lender-users <NUM> can enter initial values for transaction terms <NUM> using one or more of templates <NUM>. One or more values for values for transaction terms <NUM> can be altered during the course of negotiation <NUM>.

Responsive to finalization of the transaction terms, loan coordinator <NUM> records the loan transaction and the transaction terms in blockchain <NUM>. Blockchain <NUM> is a type of distributed ledger, which includes digitally recorded, unmodifiable data in packages called blocks. A distributed ledger, as used throughout this document, refers to a computer-only technology that enables the distributed recordation of transactions through a distributed ledger maintained by a network of computers. A distributed ledger is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple computers which may be in different sites, countries, and/or institutions maintained by many different parties. A blockchain is an example of a distributed ledger.

Stated more formally, blockchain <NUM> is a distributed database that maintains a continuously growing list of ordered records called blocks. Each block contains a timestamp and a link to a previous block, with the hash of the prior block linking the two. By design, blockchains are inherently resistant to modification of the data because, once recorded, the data in a block cannot be altered retroactively. Through the use of a peer-to-peer network, and one or more distributed timestamping servers, a blockchain database may be managed autonomously. Thus, blockchains may be used to provide an open, distributed ledger that can record transactions between parties efficiently and in a verifiable and permanent way.

Responding to finalization of the transaction terms, loan coordinator <NUM> remits lender funds <NUM> to the borrower-user <NUM>. Loan coordinator <NUM> can remit lender funds <NUM> by interacting with funds manager <NUM> as described below.

In this manner, loan coordinator <NUM> can use payroll transactions as a way to further reduce risks associated with providing loans. For example, lender-users <NUM> can be assured of receiving repayment, by discounting borrower funds <NUM> from the paycheck of borrower-user <NUM>, as agreed to and digitally signed by both parties, and as recorded in blockchain <NUM>. Responding to a subsequent repayment of borrower funds <NUM> for the loan transaction according to the transaction terms, loan coordinator <NUM> solicits peer-submitted feedback <NUM> from at least one of borrower-user <NUM> and the set of lender-users <NUM>.

Loan coordinator <NUM> updates the integrity score for borrower-user <NUM> and the set of lender-users <NUM> based on received peer-submitted feedback <NUM> regarding the loan transaction.

Turning to <FIG>, a block diagram of a predictive modeling/indexing is depicted in accordance with an illustrative embodiment. Computer system <NUM> is connected to internal databases <NUM>, and devices <NUM>. Internal databases <NUM> comprise payrolls <NUM>, new hire database <NUM>, and employment termination database <NUM>. Devices <NUM> are comprised of non-mobile devices <NUM> and mobile devices <NUM>.

Computer system <NUM> comprises processing unit <NUM>, machine intelligence <NUM>, and indexing program <NUM>. Machine intelligence <NUM> comprises machine learning <NUM> and predictive algorithms <NUM>. Machine learning <NUM> is a branch of artificial intelligence (AI) that enables computers to detect patterns and improve performance without direct programming commands. Rather than relying on direct input-commands to complete a task, machine learning <NUM> relies on input-data. The data is fed into the machine, one of predictive algorithms <NUM> is selected, parameters for the data are configured, and the machine is instructed to find patterns in the input data through optimization algorithms. The data model formed from analyzing the data is then used to predict future values.

Machine intelligence <NUM> can be implemented using one or more systems such as an artificial intelligence system, a neural network, a Bayesian network, an expert system, a fuzzy logic system, a genetic algorithm, or other suitable types of systems. Machine learning <NUM> and predictive algorithms <NUM> may make computer system <NUM> a special purpose computer for dynamic predictive modelling of the ability of local area economies to hire additional workers.

In an embodiment, processing unit <NUM> comprises one or more conventional general-purpose central processing units (CPUs). In an alternate embodiment, processing unit <NUM> comprises one or more graphical processing units (GPUs). Though originally designed to accelerate the creation of images with millions of pixels whose frames need to be continually recalculated to display output in less than a second, CPUs are particularly well suited to machine learning. Their specialized parallel processing architecture allows them to perform many more floating-point operations per second than a CPU, on the order of 1100x more. GPUs can be clustered together to run neural networks comprising hundreds of millions of connection nodes.

Indexing program <NUM> comprises information gathering <NUM>, selecting <NUM>, modeling <NUM>, comparing <NUM>, indexing <NUM>, ranking <NUM>, and displaying <NUM>. Information gathering <NUM> is configured to gather data from internal databases <NUM>.

Referring to <FIG>, an example table for use with a dataset in machine learning is depicted in accordance with an illustrative embodiment. The dataset used to form predictions is defined and labeled in a table such as table <NUM>. Each column is known as a vector, and the data within each column is a feature, also known. as a variable, dimension, or attribute. Each row represents a single observation of a given feature and is referred to as a case or value. The y values represent the output and are typically expressed in the final column as shown. For ease of illustration the example shown in <FIG> is a simple <NUM>-D table, but it should be noted that multiples vectors (forming matrices) are typically used to represent large datasets. Each category of data calculated in the process flow could be represented by a separate vector (column) in a tabular dataset depending on how the data is aggregated.

<FIG> is an illustration of a distributed ledger in the form of a blockchain depicted in accordance with an illustrative embodiment. Blockchain <NUM> is a blockchain, which is a specific implementation of a distributed ledger. Blockchain <NUM> is described to introduce blockchain concepts.

Blockchain <NUM> starts with root block <NUM>. Blocks indicated with a right-leaning hash, such as block <NUM> or block <NUM>, are part of the main chain. Blocks with a left-leaning hash, such as block <NUM> or block <NUM>, exist outside of blockchain <NUM>.

Thus, blockchain <NUM> is a heaviest path from root block <NUM> to block <NUM> through the entire block tree. The "heaviest" path through the block tree, i.e. the path that has had the most computation done upon it, is conceptually identified as blockchain <NUM>. Identifying blockchain <NUM> in this manner allows a decentralized consensus to be achieved for the state of blockchain <NUM>.

<FIG> should be considered together. <FIG> is an illustration of a first step in creating a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a second step in creating a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a third step in creating a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a fourth step in creating a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a fifth step in creating a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a sixth step in creating a blockchain in accordance with an illustrative embodiment. <FIG> may be implemented on a computer or on multiple computers in a network environment. <FIG> address a technical problem that only exists in computer programming and execution. As used throughout <FIG>, common reference numerals refer to common objects in these figures.

In operation <NUM> shown in <FIG>, account <NUM>, also sometimes referred to as a "node," is a state object recorded in a shared ledger that represents the identity of agents that can interact with the ledger. Account <NUM> includes an owner, a digital certificate identification, and a copy of a ledger. Account <NUM> may sign transactions and inspect the blockchain and its associated state. A user may issue transactions, signed by account <NUM>, to interact with the blockchain. The combined state of all accounts that have interacted with the blockchain is the state of the blockchain.

In operation <NUM> shown in <FIG>, account <NUM> collates transactions and distributions into blocks <NUM>, and adds blocks <NUM> to the shared ledger. Blocks <NUM> function as a journal, recording a series of transactions together with the previous block and an identifier for the final state of the blockchain. Blocks <NUM> are chained together using a cryptographic hash as a means of reference - each block in the shared ledger has a digital fingerprint of the previous block. In this manner, it is not possible to alter previous blocks without being detected.

In operation <NUM> shown in <FIG>, blockchain network <NUM> is formed. Blockchain network <NUM> may include multiple local copies of blockchains such as those shown in <FIG>. Each account, such as account <NUM> or account <NUM>, has its own blockchain.

In operation <NUM> shown in <FIG>, transaction <NUM> is issued from an account, such as account <NUM> or account <NUM> in <FIG>. Transaction <NUM> is an instruction constructed and cryptographically-signed by an account, such as such as account <NUM> or account <NUM> in <FIG>.

Transaction <NUM> can result in message calls to other accounts. Transactions that result in message calls contain data specifying input data for the message. Alternatively, transaction <NUM> can result in the creation of new agent accounts, i.e., "contract creation" transactions.

Transactions are collated into blocks that are added to local blockchain copies by the various accounts. The blockchain is synchronized across the various nodes. Thus, each account in blockchain network <NUM> in <FIG> adds identical blocks to a local copy of the blockchain.

In operation <NUM> shown in <FIG>, leader election takes place. Leader account <NUM> takes priority for deciding which information is the most accurate or up-to-date. Identifying information by leader account <NUM>, and validating this information by other accounts, allows a decentralized consensus to be achieved throughout the blockchain network <NUM> for the state of blockchain <NUM>.

In operation <NUM> shown in <FIG>, data execution and recovery takes place. A query regarding data stored in one or more of the nodes may return a validated answer regarding contents in the blocks.

<FIG> and <FIG> should be considered together. <FIG> is an illustration of a step in creating a smart contract within a blockchain in accordance with an illustrative embodiment. <FIG> is an illustration of a step in creating a blockchain using a smart contract within a blockchain in accordance with an illustrative embodiment. <FIG> and <FIG> may be implemented on a computer or on multiple computers in a network environment.

In operation <NUM> shown in <FIG>, transaction <NUM> is a "contract creation" transaction that results in the creation of smart contract <NUM>. In contrast to data contained in message call transactions, such as transaction <NUM> in <FIG>, transaction <NUM> contains data specifying initialization code for smart contract <NUM>.

Smart contract <NUM> is a type of account existent only within the blockchain execution environment. Smart contract <NUM> is not associated with an external account, but rather is a notional object stored that resides at a specific address on the blockchain. Smart contract <NUM> includes both code, i.e. functions, and data, i.e. state. Smart contract <NUM> has direct control over its own state and storage memory to preserve persistent state variables. When referenced, either through a transaction or due to the internal execution of code, smart contract <NUM> executes its associated functions.

Smart contracts have a number of desirable properties. Execution of the smart contract is managed automatically by the network. Documents are encrypted on a shared ledger that is duplicated many times over on different nodes of the network, ensuring that the data is true and correct. Because smart contracts on distributed ledgers cannot be modified, they provide an immutable record of submitted workflow transactions that is highly resistant to post-transaction changes.

Transaction <NUM> contains data specifying initialization code for smart contract <NUM>. Each account in a blockchain network executes this initialization code to incorporate smart contract <NUM> into the blockchain. At creation, smart contract <NUM>, initialization code is executed to retrieve the associated functions of smart contract <NUM>, after which the initialization code can be discarded.

In operation <NUM> shown in <FIG>, smart contract <NUM> generates message <NUM>. Message <NUM> is an instruction constructed by smart contract <NUM> in response to receiving a message. Because smart contract <NUM> exists only within the blockchain execution environment, message <NUM> is a sort of "virtual transaction" sent by code from one account to another.

Message <NUM> can specify input data that results in message calls for other accounts, allowing smart contract <NUM> to read and write to internal storage. Alternatively, message <NUM> can contain data specifying initialization code, allowing smart contract <NUM> to create additional smart contracts.

The associated functions of smart contract <NUM> can be executed as part of state transition and block validation. If a transaction is added into a block, the code execution spawned by that transaction will be executed by all accounts that download and validate the block.

With reference next to <FIG>, a block diagram of an execution environment for executing a smart contract stored on the blockchain is depicted in accordance with an illustrative embodiment.

Blockchain environment <NUM> includes a number of different components. As depicted, blockchain environment <NUM> includes blockchain engine <NUM> and blockchain state <NUM>.

Blockchain engine <NUM> is responsible for internal-account state and transaction-computation for the blockchain. Blockchain engine <NUM> performs state-transitions for smart contracts. In this illustrative example, blockchain engine <NUM> is a stackbased architecture that uses a last-in, first-out stack. Blockchain engine <NUM> executes transactions recursively, computing the system state and the machine state for each loop. Blockchain engine <NUM> includes non-volatile and volatile components.

Storage <NUM> is non-volatile and is maintained on the blockchain as part of the system state. Every smart contract on the blockchain has its own storage. Storage <NUM> preserves all the state variables for the smart contract that do not change between the function calls.

Code <NUM> are the functions associated with smart contract <NUM> and <NUM> from <FIG> and <FIG>, respectively. Code <NUM> are instructions that formally specify the meaning and ramifications of a transaction or message; code <NUM> executes in response to receiving a message call. Code <NUM> is stored in a virtual ROM that cannot be changed after construction. Blockchain engine <NUM> executes code <NUM> in response to a message call to the smart contract.

Memory <NUM> is volatile and is cleared between external function calls. Memory <NUM> stores temporary data, such as, function arguments, local variables, and return values. Stack <NUM> is used to hold temporary values when conducting calculations in blockchain engine <NUM>.

Blockchain state <NUM> is combined state of all accounts that have interacted with the blockchain, mapping blockchain addresses to accounts and account states. Blockchain state <NUM> may not be stored on the blockchain, but rather in a data structure on a backend state database that maintains the mapping. Blockchain engine <NUM> relies on blockchain state <NUM> for execution of certain instructions.

With reference now to <FIG>, a block diagram of a blockchain in a micro-loan environment is depicted in accordance with an illustrative embodiment. As depicted, blockchain <NUM> of blockchain system <NUM> can be blockchain <NUM> of <FIG>.

In this illustrative example, blockchain system <NUM> manages micro-loan transactions for employees <NUM> of organizations <NUM>. The distributed computing and trust enabled by blockchain system <NUM> simplifies the micro-loaning process by reducing risks, and providing transparency in the micro-loaning process with the trust in the transaction being reinforced by the distributed network.

Responding to finalization of transaction terms <NUM> of <FIG>, loan coordinator <NUM> records the loan transaction and the transaction terms in blockchain <NUM>. Once transaction terms <NUM> are finalized, loan coordinator <NUM> submits transactions <NUM> that includes signature <NUM> of loan coordinator <NUM> and data <NUM> for creating one of smart contracts <NUM> based on the finalized ones of transaction terms <NUM> from <FIG>. In one illustrative example, smart contracts <NUM> may require a separate transaction, signed by each contracting user, for example, borrower-user <NUM> and lender-users <NUM> of <FIG>, accepting the finalized terms of the smart contract prior before any funds are transferred.

Users interact with micro-loan application <NUM> through user input to graphical user interface <NUM> using one or more user input devices, such as a keyboard, a mouse, a graphical user interface (a physical display), a touch screen, a voice interaction, and any other suitable interface for interacting with the computer. In one illustrative example, micro-loan application <NUM> can be a mobile phone application (mobile app) that is available in a variety of mobile platforms, such as but not limited to, Apple iCS, Android, Windows Phone OS, Blackberry OS, webOS, and Symbian OS.

In one illustrative example, client devices <NUM>, which can include one or more of borrower device <NUM> and lender device <NUM> of <FIG>, display graphical user interface <NUM> on display system <NUM>. In this illustrative example, display system <NUM> can be a group of display devices. T, display device in display system <NUM> may be selected from one of a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, and other suitable types of display devices.

External accounts <NUM> are examples of account <NUM> and account <NUM> shown in block form in <FIG>. External accounts <NUM> allow external actors, such as borrower-user <NUM>, lender-users <NUM>, and loan coordinator <NUM> and to interact with blockchain <NUM> by issuing transactions <NUM>, signed using key <NUM>.

Transactions <NUM> submitted from loan coordinator <NUM> and are cryptographically-signed to uniquely identify a particular account. For example, blockchain system <NUM> is able to uniquely identify which of borrower-user <NUM>, lender-users <NUM>, and loan coordinator <NUM> issues the transaction based on the unique signature <NUM> created using key <NUM>. Based on the unique signature <NUM> created, each node in blockchain network <NUM> can use the corresponding one of key <NUM> to identify the corresponding one of external accounts <NUM> that issued the transaction.

In this illustrative example, transaction <NUM> is a "contract creation" transaction that includes data <NUM> specifying initialization code for one of smart contracts <NUM>. Additionally, data <NUM> can specify input data for one or more of smart contracts <NUM>, such as transaction terms <NUM> entered into one or more templates <NUM> of <FIG>. Once created, smart contracts <NUM> store transaction terms <NUM> in its associated storage <NUM> as part of the smart contract's associated state.

In this manner, blockchain system <NUM> records the loan transaction and the transaction terms in blockchain <NUM> by generating one of smart contracts <NUM> for the loan transaction based on transaction terms <NUM> of <FIG>, and recording the smart contract in blockchain <NUM>. Blockchain system <NUM> manages a loan balance within smart contracts <NUM> according to transaction terms <NUM> and based on repayment transactions submitted from borrower-user <NUM>, lender-users <NUM>, and recorded on the blockchain.

Blockchain system <NUM> records transactions <NUM> in blocks <NUM> of blockchain <NUM>. Each of transactions <NUM> is hashed and stored in transactions hash tree <NUM> of an associated one of blocks <NUM>. All of the transaction hashes in transactions hash tree <NUM> are themselves hashed and stored as a root hash as part of block headers <NUM>.

Block headers <NUM> are smaller than the entire associated block <NUM>. Using a distributed hash table as a database, mobile device <NUM> can operate as light client node <NUM> that stores just block headers <NUM> of blockchain <NUM>. Light client node <NUM> can obtain blockchain information by communicating with trusted full node <NUM>. Light client node <NUM> allow users in storage-limited or bandwidth-limited environments, such as in applications on mobile device <NUM>, to maintain a high-security assurance about a current state of some portion of the state of blockchain <NUM>, or verify the execution of transactions <NUM>.

In this illustrative example, smart contracts <NUM> can generate one or more of messages <NUM> in response to the execution of code <NUM>. Messages <NUM> can be sent to other ones of accounts <NUM>, including external accounts <NUM> and other smart contracts <NUM>. Additionally, messages <NUM> generated by smart contracts <NUM> can request external accounts <NUM> to generate external events, such as push event <NUM>. Push event <NUM> can be, for example, a web hook, a web socket, or some other appropriate communication that communicates timeclock information to an external service, such as payroll service <NUM>.

For example, blockchain system <NUM> associates a URL address for payroll service <NUM> with the account of organization <NUM> in blockchain system <NUM>. Blockchain system <NUM> pushes a POST request to payroll service <NUM>. The POST request can comprise a JSON object that includes payroll information to run payroll services for organization <NUM>. Payroll information in the JSON object can be encrypted.

In this illustrative example, payroll service <NUM> is associated with an account, such as one of external accounts <NUM>, of a payroll service provider. Blockchain system <NUM> communicates payroll information to payroll service <NUM> through push event <NUM>. In this illustrative example, push event <NUM> communicates payroll information to payroll service <NUM>, enabling payroll service <NUM> to use payroll information to provide payroll services for one or more of organizations <NUM> and employees <NUM>.

In this illustrative example, the set of lender-users are employees of the set of organizations. In running payroll for a set of organizations, payroll service <NUM> identifies one of smart contracts <NUM> in blockchain <NUM> for a loan between borrower-user <NUM> and lender-users <NUM>. Payroll service <NUM> remits lender funds <NUM> to the borrower-user by subtracting requested funds from scheduled payroll payments to the set of lender-users and adding the requested loan funds to scheduled payroll payments to the borrower-user. Based on the amount of remitted funds, payroll service <NUM> can submit additional transactions to blockchain <NUM>, thereby managing a loan balance that is recorded in storage <NUM> of the associated ones of smart contracts <NUM>.

Additionally, within remitting loan funds to the borrower-user, payroll service <NUM> identifies one of smart contracts <NUM> in blockchain <NUM> for a loan between borrower-user <NUM> and lender-users <NUM>. Payroll service <NUM> remits borrower funds <NUM> to lender-users <NUM> according to the terms recorded in smart contracts <NUM>, by subtracting borrower funds <NUM> from scheduled payroll payments to the set of borrower-user and adding the funds to scheduled payroll payments to the lender-user. Based on the amount of repaid funds, payroll service <NUM> can submit additional transactions to blockchain <NUM>, thereby managing a loan balance that is recorded in storage <NUM> of the associated ones of smart contracts <NUM>.

In an alternative embodiment, funds manager <NUM> ,from <FIG>, has access to an account of both borrower-user <NUM> and lender-users <NUM>. The accounts can be internal to blockchain <NUM>, or external to blockchain <NUM>, such as a bank account, a credit account, or some other source of funds. Funds manager <NUM> remits loan funds to the borrower-user by subtracting requested loan funds from the account of lender-users and adding the requested loan funds to the account of borrower-user. Based on the amount of remitted funds, funds manager <NUM> can submit additional transactions to the blockchain, thereby managing a loan balance that is recorded in storage <NUM> of the associated ones of smart contracts <NUM>.

Additionally, within remitting loan funds to the borrower-user, funds manager <NUM> identifies one of smart contracts <NUM> in the blockchain for a loan between borrower-user <NUM> and lender-users <NUM>. Funds manager <NUM> remits repayment to lender-users <NUM> according to the terms recorded in smart contracts <NUM>, by subtracting repayment loan funds from the account of the set of borrower-user and adding the repayment loan funds to the account of the lender-user. Based on the amount of repaid funds, funds manager <NUM> can submit additional transactions to the blockchain, thereby managing a loan balance that is recorded in storage <NUM> of the associated ones of smart contracts <NUM>.

Turning to <FIG>, an illustration of a flowchart of a process for predictive modeling and indexing is depicted in accordance with an illustrative embodiment. Process <NUM> can be implemented in software, hardware, or a combination of the two. When software is used, the software comprises program code that can be loaded from a storage device and run by a processor unit in a computer system such as computer system <NUM> in <FIG>. Computer system <NUM> may reside in a network data processing system such as network data processing system <NUM> in <FIG>. For example, computer system <NUM> may reside on one or more of server computer <NUM>, server computer <NUM>, client computer <NUM>, client computer <NUM>, and client computer <NUM> connected by network <NUM> in <FIG>. Moreover, the process can be implemented by computer system <NUM> in <FIG> and a processing unit such as processing unit <NUM> in <FIG>.

Process <NUM> begins with aggregate human capital management information, such as human capital management information <NUM> of <FIG> (step <NUM>). After the dataset is aggregated, process <NUM> will scrub the dataset (step <NUM>). Very large datasets, sometimes referred to as Big Data, often contain noise and complicated data structures. Bordering on the order of petabytes, such datasets comprise a variety, volume, and velocity (rate of change) that defies conventional processing, and is impossible for a human to process without advanced machine assistance. Scrubbing refers to the process of refining the dataset before using it to build a predictive model and includes modifying and/or removing incomplete data or data with little predictive value. It can also entail converting text based data into numerical values (one-hot encoding) or convert numerical values into a category.

After the dataset has been scrubbed, process <NUM> will divide the data into training data and test data to be used for building and testing the predictive model (step <NUM>). To produce optimal results, the same data that is used to test the model should not be the same data used for training. The data is divided by rows, usually with <NUM>-<NUM>% used for training and <NUM>-<NUM>% used for testing.

Process <NUM> will then perform iterative analysis on the training data by applying predictive algorithms to construct a predictive model (step <NUM>). The algorithm, through trial and error, deciphers the patterns that exist between the input training data and the known output values to create a model that can reproduce the same underlying rules with new data.

There are three main categories of machine learning: supervised, unsupervised, and reinforcement learning. Supervised machine learning comprises providing the machine with test data and the correct output value of the data. Examples of supervised learning algorithms include regression analysis, decisions trees, k-nearest neighbors, neural networks, and support vector machines. Referring back to table <NUM> in <FIG>, during supervised learning the values for the y column (output) are provided along with the training data (labeled dataset) for the model building process in step <NUM>.

After the model is constructed, the test data is fed into the model to test its accuracy (step <NUM>). In an embodiment the model is tested using mean absolute error, which examines each prediction in the model and provides an average error score for each prediction. If the error rate between the training and test dataset is below a predetermined threshold, the model has learned the dataset's pattern and passed the test.

If the model fails the test: the hyperparameters of the model are changed and/or the training and test data are re-randomized or more data is collected (either through obtaining more samples or through data augmentation), and the iterative analysis of the training data is repeated (step <NUM>). Hyperparameters are the settings of the algorithm that control how fast the model learns patterns and which patterns to identify and analyze. Once a model has passed the test stage it is ready for application.

Whereas supervised and unsupervised learning reach an endpoint after a predictive model is constructed and passes the test in step <NUM>, reinforcement learning continuously improves its model using feedback from application to new empirical data. Algorithms such as Q-learning are used to train the predictive model through continuous learning using measurable performance criteria (discussed in more detail below).

After the model is constructed and tested for accuracy, process <NUM> will use the model to calculate predicted borrower-users and lender-users and populates a database with the predicted values (step <NUM>).

The predicted values are then converted into integrity scores to form an index representing predicted borrower-users and lender-users (step <NUM>).

After the indexes have been calculated, they are rank ordered (step <NUM>). Rank ordering facilitates comparison across different users and integrity scores.

If reinforcement learning is used with the predictive modelling, the integrity scores are compared to the actual observed values (step <NUM>).

Integrity scores are updated based on user feedback and can be fed back into the machine learning to update and modify the predictive model (step <NUM>). The process terminates thereafter.

With reference next to <FIG>, a flowchart of a process for facilitating peer-to-peer micro-loan transactions is depicted in accordance with an illustrative embodiment. The process of <FIG> can be a software process implemented in one or more components of micro-loan system <NUM> of <FIG>.

The process begins by determining an integrity score for each user of a plurality of users (step <NUM>). The integrity score for each user is based on human capital management information for the user and peer-submitted feedback about the user.

The process will then receive a loan transaction request from a borrower-user (step <NUM>). Afterwards, the process will determine a risk score for the loan transaction based at least on the borrower-user's integrity score (step <NUM>). The process will then identify a set of lender-users based on the determined risk score and the lender-users' integrity scores (step <NUM>).

Afterwards, the process will then allow for facilitating a negotiation of transaction terms between the borrower-user and the set of lender-users to determine the transaction terms (step <NUM>).

Responding to finalization of the transaction terms, the process will then record the loan transaction and the transaction terms in a distributed ledger, and remitting loan funds to the borrower-user (step <NUM>).

Responsive to a subsequent repayment of the loan transaction according to the transaction terms, the process then will solicit peer-submitted feedback from at least one of the borrower-user and the set of lender-users (step <NUM>).

The process will then update the integrity score for the borrower-user and the set of lender-users based on received peer-submitted feedback regarding the loan transaction (step <NUM>), with the process terminating thereafter.

The flowcharts and block diagrams in the different depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of apparatuses and methods in an illustrative embodiment. In this regard, each block in the flowcharts or block diagrams may represent at least one of a module, a segment, a function, or a portion of an operation or step. For example, one or more of the blocks may be implemented as program code, hardware, or a combination of the program code and hardware. When implemented in hardware, the hardware may, for example, take the form of integrated circuits that are manufactured or configured to perform one or more operations in the flowcharts or block diagrams. When implemented as a combination of program code and hardware, the implementation may take the form of firmware. Each block in the flowcharts or the block diagrams may be implemented using special purpose hardware systems that perform the different operations or combinations of special purpose hardware and program code run by the special purpose hardware.

In some alternative implementations of an illustrative embodiment, the function or functions noted in the blocks may occur out of the order noted in the figures. For example, in some cases, two blocks shown in succession may be performed substantially concurrently, or the blocks may sometimes be performed in the reverse order, depending upon the functionality involved. Also, other blocks may be added in addition to the illustrated blocks in a flowchart or block diagram.

Turning now to <FIG>, an illustration of a block diagram of a data processing system is depicted in accordance with an illustrative embodiment. Data processing system <NUM> may be used to implement computer system <NUM> and other data processing systems that may be used in micro-loan environment <NUM> in <FIG>.

In this illustrative example, data processing system <NUM> includes communications framework <NUM>, which provides communications between processor unit <NUM>, memory <NUM>, persistent storage <NUM>, communications unit <NUM>, input/output (I/O) unit <NUM>, and display <NUM>. In this example, communications framework <NUM> may take the form of a bus system.

Processor unit <NUM> serves to execute instructions for software that may be loaded into memory <NUM>. Processor unit <NUM> may be a number of processors, a multi-processor core, or some other type of processor, depending on the particular implementation.

Memory <NUM> and persistent storage <NUM> are examples of storage devices <NUM>. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, at least one of data, program code in functional form, or other suitable information either on a temporary basis, a permanent basis, or both on a temporary basis and a permanent basis. Storage devices <NUM> may also be referred to as computer readable storage devices in these illustrative examples. Memory <NUM>, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage <NUM> may take various forms, depending on the particular implementation.

For example, persistent storage <NUM> may contain one or more components or devices. For example, persistent storage <NUM> may be a hard drive, a solid state hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage <NUM> also may be removable.

Communications unit <NUM>, in these illustrative examples, provides for communications with other data processing systems or devices. In these illustrative examples, communications unit <NUM> is a network interface card.

Input/output unit <NUM> allows for input and output of data with other devices that may be connected to data processing system <NUM>. For example, input/output unit <NUM> may provide a connection for user input through at least one of a keyboard, a mouse, or some other suitable input device. Further, input/output unit <NUM> may send output to a printer. Display <NUM> provides a mechanism to display information to a user.

Instructions for at least one of the operating system, applications, or programs may be located in storage devices <NUM>, which are in communication with processor unit <NUM> through communications framework <NUM>. The processes of the different embodiments may be performed by processor unit <NUM> using computer-implemented instructions, which may be located in a memory, such as memory <NUM>.

These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and executed by a processor in processor unit <NUM>. The program code in the different embodiments may be embodied on different physical or computer readable storage media, such as memory <NUM> or persistent storage <NUM>.

Program code <NUM> is located in a functional form on computer readable media <NUM> that is selectively removable and may be loaded onto or transferred to data processing system <NUM> for execution by processor unit <NUM>. Program code <NUM> and computer readable media <NUM> form computer program product <NUM> in these illustrative examples. In one example, computer readable media <NUM> may be computer readable storage media <NUM> or computer readable signal media <NUM>.

In these illustrative examples, computer readable storage media <NUM> is a physical or tangible storage device used to store program code <NUM> rather than a medium that propagates or transmits program code <NUM>.

Alternatively, program code <NUM> may be transferred to data processing system <NUM> using computer readable signal media <NUM>. Computer readable signal media <NUM> may be, for example, a propagated data signal containing program code <NUM>. For example, computer readable signal media <NUM> may be at least one of an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted over at least one of communications links, such as wireless communications links, optical fiber cable, coaxial cable, a wire, or any other suitable type of communications link.

The different components illustrated for data processing system <NUM> are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system <NUM>. Other components shown in <FIG> can be varied from the illustrative examples shown. The different embodiments may be implemented using any hardware device or system capable of running program code <NUM>.

The description of the different illustrative embodiments has been presented for purposes of illustration and description and is not intended to be exhaustive or limited to the embodiments in the form disclosed. The different illustrative examples describe components that perform actions or operations. In an illustrative embodiment, a component may be configured to perform the action or operation described. For example, the component may have a configuration or design for a structure that provides the component an ability to perform the action or operation that is described in the illustrative examples as being performed by the component.

Claim 1:
A method for facilitating micro-loan transactions, comprising:
aggregating, by a micro-loan system comprising a hardware processor, data regarding a plurality of factors associated with human capital management information and a plurality of users;
scrubbing, by the micro-loan system, the aggregated data to generate a refined dataset;
dividing, by the micro-loan system, the refined dataset into a training dataset and a testing dataset;
constructing, by the micro-loan system via execution of machine learning on the training dataset, a model configured to predict categories for the plurality of users, the categories indicating at least one of borrower or lender;
determining, by the micro-loan system, a plurality of integrity scores (<NUM>) for the plurality of users based on human capital information for the plurality of users and peer-submitted feedback about the plurality of users;
receiving (<NUM>), by the micro-loan system, a request for a loan transaction request (<NUM>) from a first user (<NUM>) of the plurality of users, the first user predicted by the model to be a borrower;
determining (<NUM>), by the micro-loan system, a risk score (<NUM>) for the loan transaction based at least on a first integrity score of the plurality of integrity scores (<NUM>) for the first user;
identifying (<NUM>), by the micro-loan system, a plurality of lenders (<NUM>) from the plurality of users based on the determined risk score (<NUM>) and integrity scores of the plurality of integrity scores (<NUM>) corresponding to the plurality of lenders;
facilitating (<NUM>), by the micro-loan system, a negotiation of transaction terms (<NUM>) between the borrower (<NUM>) and the set of lenders (<NUM>) to determine the transaction terms (<NUM>);
recording (<NUM>), by the micro-loan system responsive to finalization of the transaction terms, the loan transaction and the transaction terms (<NUM>) in a first smart contract in a first blockchain;
synchronizing the first blockchain across a plurality of nodes;
soliciting (<NUM>), by the micro-loan system responsive to subsequent repayment of the loan transaction according to the transaction terms (<NUM>), peer-submitted feedback (<NUM>); and
updating (<NUM>), by the micro-loan system based on user feedback, at least one integrity score of the plurality of integrity scores and feeding said updated integrity score back to a machine learning process to modify the model.