Patent Description:
This disclosure relates generally to increasing the security of resource management by preventing fraudulent access to resources.

Resource management, or more specifically resource access control, becomes more and more challenging as various resources now can be conveniently acquired, accessed, and transferred online. For example, a user can acquire an online storage resource for a fixed term through online transactions with a resource provider of the online storage resource, and access the online storage resource over the Internet. If the user later decides that he no longer needs the online storage resource, the user can transfer the unused term of the online storage resource to another user or entity, again through online transactions with the other user or entity. Similarly, for monetary resources, a creditor can acquire the right to the resource, obtain the resource, or transfer the right to the resource through online transactions.

This online nature of the resource access and transfer makes fraudulent accesses of the resources easier than before. For example, a user who acquired a resource and later transferred the resource might still have the means, such as credentials or tokens, to access the resource even after the transfer. Likewise, the user might transfer the rights of the same resource to multiple subsequent users by fraud. As a result, the resource provider might end up providing resources to multiple users and a transferee of the resource might have acquired a resource that has been depleted by other transferees.

The problem might be partially solved by enhancing the security measures at the resource provider by timely revoking the access right of a user if the user has transferred his access to the resource to another user. However, this approach requires the resource provider to implement sophisticated resource access control mechanisms. Not all resource providers have the capabilities to do so. The fraudulent access of the resource described above remains to be a big threat to these resource providers. US patent application publication no. <CIT> describes a system in which an electronic record is stored on a distributed environment with respect to an item.

Various aspects of the present disclosure involve providing a centralized secure resource management system to prevent fraudulent resource access as disclosed by the appended claims.

The subject matter should be understood by reference to appropriate portions of the entire specification, any or all drawings, and each claim.

The foregoing, together with other features and examples, will become more apparent upon referring to the following specification, claims, and accompanying drawings.

Certain aspects and features of the present disclosure involve providing a centralized secure resource management system to prevent fraudulent resource access. The secure resource management system maintains a resource record repository for storing resource records of various resources. The resource records contain information of resource providers of the resources, information of resource users of the resources, and resource transaction histories. A resource user refers to a user authorized to access a resource or having a right to obtain the resource. The resource record repository is implemented in a hybrid blockchain.

The secure resource management system can use the resource record repository to serve verification requests. For example, if the secure resource management system receives a request to verify an authorized user of a resource, the secure resource management system queries the resource record repository to retrieve the resource record and identifies the current authorized user of the resource. The secure resource management system returns the verification result identifying the authorized user of the resource in response to the request. The resource provider can provide the authorized user access to the resource according to the verification result, such as by distributing the resource to the authorized user.

The request can be sent by a resource provider in order to confirm that the resource user requesting access to the resource is an authorized user. The request can also be sent by a subsequent resource user to whom the current resource user is to transfer the right to the resource. In this way, the resource provider (or the subsequence resource user) can verify the authenticity of the resource user and the amount of the resource before distributing the resource (or before acquiring the right to the resource from the current resource user). In some examples, the subsequent resource user may also request the secure resource management system to determine the value of the resource or the likelihood that the resource provider will distribute the resource before accepting the transfer of the resource.

The distribution of the resource can be made directly from the resource provider to the resource user, or through the secure resource management system or a trusted third party. Responsive to each resource distribution, the resource user, the resource provider, or the trusted third party can report the resource distribution to the secure resource management system so that the resource record repository can be updated to include the distribution transaction. Likewise, for each resource right transfer, the current resource user or the subsequence resource user can report the transfer to the secure resource management system so that the resource record repository can be updated to reflect the transfer and the current authorized user of the resource.

As described herein, certain aspects provide improvements to resource management by solving the fraudulent access problems that are specific to the Internet. As discussed above, the online nature of resource access and transfer makes the fraudulent access of the resources easier to implement and harder to detect. The centralized secure resource management system in the present disclosure keeps track of each transaction regarding a resource and maintains a secured copy of the records in a secure repository. This allows the resource provider, subsequent users of the resource, or other entities to verify the authenticity of the resource and the authorized user before distributing or acquiring the resource. By utilizing secure computer technologies, such as data encryption and blockchain, this secure verification solution significantly reduces the chances of fraudulent access to resources.

The centralized secure resource management system can reduce the burden of implementing secure resource access control mechanisms from individual resource providers. Additionally or alternatively, because the secure centralized resource verification system can be implemented with highly complicated protection mechanisms, the security of the resource access control process provided by the system is more secure than the access control implemented by individual resource providers.

These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements, but should not be used to limit the present disclosure.

<FIG> is a block diagram depicting an example of a secure resource management system <NUM> in which resource records concerning parties and transactions related to the resources are securely recorded and maintained. These resource records can be utilized to verify a resource and its authorized user when needed. The secure resource management system <NUM> is a specialized computing system that may be used for processing large amounts of data using a large number of computer processing cycles.

The secure resource management system <NUM> shown in <FIG> includes a secure resource management server <NUM> that is configured for managing transactions involving a resource and for verifying the authorized user of the resource. The secure resource management system <NUM> further includes a resource record repository <NUM> configured for securely storing resource records <NUM> each describing certain aspects associated with a resource. For example, the resource record <NUM> for a resource may include resource information <NUM> that describes the type of the resource, the identifier of the resource, the quantity of the resource, the effective date of the resource, the schedule for resource distribution, the remaining unused amount of the resource, and so on. For instance, if the resource is an online storage resource, the resource information <NUM> can indicate the resource being an online storage resource. The resource information <NUM> for the online storage resource may further include information such as a serial number associated with the online storage resource, the capacity of the online storage resource, the time period that the storage resource can be used, the network address of the storage resource, and so on. For a monetary resource, the resource information <NUM> may include the type or nature of the resource (e.g. a fund or a loan repayment), the total amount of the fund or loan, the schedule for the fund distribution or loan payment, the account number of the fund or loan, the remaining balance of the loan, and others.

The resource record <NUM> for the resource may also include resource provider data <NUM> containing various information about the resource provider of the resource, such as the name, address, identification of the resource provider. Other information, such as data related to the capability of the resource provider timely providing the resource, may also be included. If the resource provider is a company or an organization, such as a company providing an online storage resource, the resource provider data <NUM> can include the name of the company, the network or physical address of the company, the identification (e.g. the taxpayer identification number (TIN)) of the company, the revenue of the company, the total capacity of the resource held by the company, and so on. If the resource provider is an individual or a group of individuals, such as a loan borrower providing loan payments, the resource provider data <NUM> may include the name, address, social security number (SSN) of the loan borrower. The resource provider data <NUM> may also include the income of the loan borrower indicating the capability of the loan borrower to timely distribute the monetary resource to a creditor.

Likewise, the resource records <NUM> also include resource user data <NUM> to record information about the authorized user of the resource. An authorized user of a resource can be an entity or an individual who has the right to access the resource or to receive the distribution of the resource from the resource provider or a trusted third party. An authorized user of a resource may also be referred to as "a user of the resource" or a "resource user" for simplicity. Distribution of the resource can involve providing the resource or a portion of the resource for accessing, exclusively using, claiming ownership, or otherwise executing the rights the authorized user has with regard to the resource.

Because the resource (or access to the resource) may be transferred from one authorized user to another authorized user, the resource user data <NUM> includes the information about the current authorized user and past authorized users of the resource. For each of the resource users, the resource user data <NUM> may include information of the resource user, such as the name, address, identification, and so on.

The resource record <NUM> for a resource further maintains resource transaction history <NUM> describing the transactions involving the resource. For example, the resource transaction history <NUM> may include entries for resource distributions and transfers. An entry for resource distribution in the resource transaction history <NUM> can contain the time of the distribution, the quantity of the resource being distributed, the recipient of the distribution (i.e., the subsequent authorized user), the way the resource is distributed (e.g., via providing authorized user login credentials to access the resource, or via sending the authorized user tokens or other electronic data indicating the distribution), and other information.

In some examples not falling under the scope of the claims, the resource record repository <NUM> is implemented using a secure database by implementing secure mechanisms such as data encryption, access control, integrity control, data backup, or any combination thereof. The resource record repository <NUM> is implemented through a blockchain, where the information contained in the resource records <NUM> is securely stored in the blockchain. The blockchain is updated as new information is received at the resource record repository <NUM>, such as when the resource is transferred from one user to another user, when a portion of the resource is being distributed, and so on.

The blockchain is a hybrid blockchain including a private blockchain that is only accessible by the secure resource management system <NUM> and a public blockchain accessible by the public. The resource record repository <NUM> can store the detailed and sensitive information in the resource records <NUM> in the private blockchain, such as the resource provider data <NUM>, the resource user data <NUM>, detailed information in the resource information <NUM> and the resource transaction history <NUM>. The resource record repository <NUM> can store an encrypted version of the resource transaction history <NUM> on the public blockchain. The encrypted version can include the hash of each of the entries in the resource transaction history <NUM>.

In other examples not falling under the scope of the claims, the blockchain is a public blockchain. Data contained in the resource record repository <NUM> are encrypted and stored in the public blockchain. Although the resource record repository <NUM> is publicly available, the content of the resource record repository <NUM> is not accessible without the decryption key. As such, sensitive information contained in the resource record repository <NUM> is still protected in the public blockchain.

Based on the resource record repository <NUM>, the secure resource management server <NUM> can utilize a resource verification subsystem <NUM> to verify the authenticity of a resource, including the type of the resource, the remaining unused amount of the resource, the authorized user of the resource, the transactions involving the resource, and so on. For example, the resource verification subsystem <NUM> can be configured to receive a request to verify the authenticity of a resource. In response to such a request, the resource verification subsystem <NUM> communicates with the resource record repository <NUM> and query the resource records <NUM> to determine the resource record <NUM> for the requested resource. If the information contained in the request matches the resource record <NUM> for the requested resource, the resource verification subsystem <NUM> returns a message to the requesting computing device indicating the information about the resource in the request is authentic. Otherwise, the resource verification subsystem <NUM> returns a message showing the information about the resource in the request is not authentic.

The resource verification subsystem <NUM> can also be configured to provide authentic information about a resource. For example, the resource verification subsystem <NUM> can be configured to process a request for information such as the current authorized user and the unused amount of the resource. In response, the resource verification subsystem <NUM> can query and retrieve the resource record <NUM> for the resource from the resource record repository <NUM> to identify and return the requested information.

If the resource record repository <NUM> is implemented using a hybrid blockchain, the public blockchain can be utilized to verify the authenticity of transactions involving a resource, such as a transfer of the resource or distribution of the resource. For example, an entity that wants to verify the authenticity of a transaction involving a resource can submit, using a computing device, information associated with the transaction to the secure resource management server <NUM>. The secure resource management server <NUM> generates a hash for the querying transaction using the same hashing method used to generate the hash stored on the public blockchain. The secure resource management server <NUM> can submit the generated hash to the public blockchain for verification. Additionally, or alternatively, the secure resource management server <NUM> can return the generated hash to the requesting entity so that the requesting entity can verify the authenticity of the transaction itself using the public blockchain. If the public blockchain returns a match to the generated hash, the query transaction can be determined to be an authentic transaction that indeed occurred; otherwise, the query transaction is not an authentic transaction.

The secure resource management server <NUM> further includes a resource value prediction subsystem <NUM>. The resource value prediction subsystem <NUM> can be configured to build and use a model for predicting an expected value of a resource based on the data about the resource stored in the resource record repository <NUM>. In some examples, the model is configured to predict a likelihood (e.g. a probability or a possibility) of the resource being distributed within a certain time period. The model is further configured to predict a quantity or an amount associated with the remaining resource. Based on these two predicted quantities, the resource value prediction subsystem <NUM> can calculate the expected value of the remaining undistributed resource. As will be discussed below, the expected value of the remaining resource can be useful to a subsequent user of the resource when determining whether to accept the transfer of the resource from a previous authorized user. Additional details about predicting the value of the remaining resource are provided below with regard to <FIG>.

The secure resource management system <NUM> also includes a client external-facing subsystem <NUM> including one or more computing devices to provide a physical or logical subnetwork (sometimes referred to as a "demilitarized zone" or a "perimeter network"). The client external-facing subsystem <NUM> is configured to expose certain online functions of the secure resource management system <NUM> to an untrusted network, such as the Internet or another public data network <NUM>. In some aspects, the client external-facing subsystem <NUM> can be implemented as edge nodes, which provide an interface between the public data network <NUM> and a cluster computing system, such as a Hadoop cluster used by the secure resource management system <NUM>.

The client external-facing subsystem <NUM> is communicatively coupled, via a firewall device <NUM>, to one or more computing devices forming a private data network <NUM>. The firewall device <NUM>, which can include one or more devices, creates a secured part of the secure resource management system <NUM> that includes various devices in communication via the private data network <NUM>. In some aspects, by using the private data network <NUM>, the secure resource management system <NUM> can house the resource record repository <NUM> in an isolated network (i.e., the private data network <NUM>) that has no direct accessibility via the Internet or another public data network <NUM>. If the resource record repository <NUM> is implemented using the hybrid blockchain as described above, the public blockchain can be accessed directly via Internet or another public data network <NUM>, but not the private blockchain.

Various computing systems may interact with the secure resource management system <NUM> through the client external-facing subsystem <NUM>, such as a resource provider computing system <NUM>, a resource user computing system <NUM>, one or more subsequent resource user computing systems <NUM>, or one or more trusted third party computing systems <NUM>.

A resource provider computing system <NUM> can include any computing device or other communication device operated by an individual, such as a consumer, or an entity, such as a company, an institute, an organization, or other types of entities. The resource provider computing system <NUM> can include executable instructions stored in one or more non-transitory computer-readable media. The resource provider computing system <NUM> can also include one or more processing devices that are capable of executing the resource provider computing system <NUM> to perform operations described herein. In some aspects, the resource provider computing system <NUM> can allow a user to engage in mobile commerce with a resource user computing system <NUM> or a subsequent resource user computing system <NUM>.

For instance, the user or other entity accessing the resource provider computing system <NUM> can use the resource provider computing system <NUM> to engage in an electronic transaction with a resource user computing system <NUM> via an online service. An electronic transaction between the resource provider computing system <NUM> and the resource user computing system <NUM> can include, for example, the resource user computing system <NUM> being used to request a portion of the resource being distributed to or being accessed by the resource user computing system <NUM> through an online service, such as an email service, a VOIP service, a messaging service, or other online services that can deliver a request for the resource to the resource provider computing system <NUM>. For example, the electronic transaction can include the resource user computing system <NUM> sending an email to an email account accessible through the resource provider computing system <NUM> for repayment of the loan. An electronic transaction between the resource provider computing system <NUM> and the resource user computing system <NUM> can also include the resource provider computing system <NUM> being used to distribute or provide access to the resource user computing system <NUM> via an online service, such as a resource distribution platform implemented by a third-party system or by the resource user computing system <NUM>. For example, the electronic transaction can include the resource provider paying a portion of a loan to the resource user computing system <NUM> through an online banking service.

Responsive to each resource distribution transaction, the resource user computing system <NUM> is configured to report the resource distribution to the secure resource management system <NUM> so that the secure resource management server <NUM> can update the resource record repository <NUM> based on the transaction. The update may include an update to the resource transaction history <NUM> to include the resource distribution transaction and an update to the resource information <NUM> to update the remaining unused amount of the resource.

The resource user computing system <NUM> or each subsequent resource user computing system <NUM> may include one or more devices, such as individual servers or groups of servers operating in a distributed manner. A resource user computing system <NUM> or a subsequent resource user computing system <NUM> can include any computing device or group of computing devices operated by a seller, lender, or another provider of products or services. The resource user computing system <NUM> or the subsequent resource user computing system <NUM> can include one or more server devices that include or otherwise access one or more non-transitory computer-readable media. The resource user computing system <NUM> or the subsequent resource user computing system <NUM> can also execute an online service. The online service can include executable instructions stored in one or more non-transitory computer-readable media. The resource user computing system <NUM> or the subsequent resource user computing system <NUM> can further include one or more processing devices that are capable of executing the online service to perform operations described herein.

A user or other entity accessing the resource user computing system <NUM> can use the resource user computing system <NUM> to engage in an electronic transaction with a subsequent resource user computing system <NUM> via an online service. The electronic transaction can include transferring the rights to the resource from the authorized user of the resource to a subsequent resource user. After the transfer, the subsequent resource user becomes the current authorized user and the previous authorized user is no longer authorized to access the resource. Likewise, the subsequent resource user can transfer any remaining rights to the resource to another subsequent resource user.

Before a transfer, a subsequent resource user can utilize the associated subsequent resource user computing system <NUM> to communicate with the secure resource management system <NUM>, e.g. through the client external-facing subsystem <NUM>, to submit a request to verify the resource. The request may include verifying the authenticity of the resource and the transferor (i.e., whether the resource has remaining unused portion as transferor claims) and whether the transferor is indeed the current authorized user of the resource. The secure resource management server <NUM> may process the request as described above. Upon receiving the verification results, the subsequent resource user computing system <NUM> may continue the transfer transaction with the transferor accordingly. That is, the subsequent resource user computing system <NUM> can accept the transfer if the transferor is the current authorized user of the resource and the resource has a remaining unused portion as the transferor claims. The subsequent resource user computing system <NUM> can deny the transfer if the transferor is not the current authorized user of the resource or the remaining unused portion is different from what the transferor claimed.

In some examples, the subsequent resource user computing system <NUM> may also submit a request to the secure resource management system <NUM> to determine the value of the resource before accepting the transfer of the resource. The secure resource management system <NUM> can process such a request using the resource value prediction subsystem <NUM> as discussed above and return the predicted value of the resource to the subsequent resource user computing system <NUM>. Based on the predicted value, the subsequent resource user may decide whether to proceed with the transfer transaction or not.

If the resource transfer transaction occurred, the subsequent resource user computing system <NUM> is further configured to report such a transfer to the secure resource management system <NUM> so that the secure resource management server <NUM> can update the resource record repository <NUM> based on the transaction. The update may include an update to the resource user data <NUM> by adding data about the new subsequent resource user, an update to the resource transaction history <NUM> to include the transfer transaction and other data impacted by the transaction. Likewise, for each subsequent resource distribution, the subsequent resource user computing system <NUM> is further configured to report the distribution to the secure resource management system <NUM> so that the resource record repository <NUM> can be updated accordingly.

In addition to distributing the resource to the resource user computing system <NUM> or subsequent resource user computing system <NUM>, the resource provider computing system <NUM> may also be configured to distribute the resource to one or more trusted third parties through respective trusted third party computing systems <NUM>. Each trusted third party computing system <NUM> may include one or more third-party devices (e.g., computing devices or groups of computing devices), such as individual servers or groups of servers operating in a distributed manner. A trusted third party computing system <NUM> can include any computing device or group of computing devices operated by a trusted third party such as a certified online resource distributor, an online resource platform, an online financial institute, etc. The trusted third party computing systems <NUM> can be configured for forwarding the distributed resource to the current authorized user of the resource and for storing, formatting, and transmitting data regarding the resource distribution transaction to the secure resource management system <NUM>. Additional details regarding the secure resource management system <NUM> and the interactions between the various systems with the secure resource management system <NUM> are provided below with regard to <FIG>.

<FIG> and <FIG> show several flowcharts illustrating several processes 200A, 200B, 200C, and 200D for secure resource management. For illustrative purposes, the processes 200A, 200B, 200C, and 200D are described with reference to implementations described above with respect to one or more examples described herein. Other implementations, however, are possible. In particular, the process 200A illustrates aspects of the resource provider computing system <NUM>, the process 200B illustrates aspects of the resource user computing system <NUM>, the process 200C illustrates aspects of a subsequent resource user computing system <NUM>, and the process 200D illustrates aspects of the secure resource management server <NUM>. The processes 200A, 200B, 200C, and 200D will be described together below.

In some aspects, the steps in <FIG> and <FIG> may be implemented in program code that is executed by respective computing devices such as the resource provider computing system <NUM>, the resource user computing system <NUM>, the subsequent resource user computing systems <NUM>, and the secure resource management server <NUM> depicted in <FIG>. In some aspects of the present disclosure, one or more operations shown in <FIG> and <FIG> may be omitted or performed in a different order. Similarly, additional operations not shown in <FIG> and <FIG> may be performed.

At block <NUM>, the process 200A involves the resource provider computing system <NUM> sending a message granting rights of using or owning a resource to a resource user. The message may also include information about the resource provider and the resource. In an example of an online storage resource, the message includes an agreement that the resource provider company will provide the resource according to terms agreed by both parties. In an example where the resource is a monetary resource, the message can include an agreement of the loan borrower (i.e., the resource provider) to repay the loan amount. The resource provider computing system <NUM> sends the message to the resource user computing system <NUM>.

At block <NUM>, upon receiving the message, the resource user computing system <NUM> further generates a reporting message describing the event of receiving the rights to the resource and information associated with the resource, the resource provider, and the resource user, or any other information needed for creating a resource record <NUM>. In some examples, the resource user computing system <NUM> generates the reporting message in a format specified by the secure resource management system <NUM>. The resource user computing system <NUM> further sends the reporting message to the secure resource management server <NUM>. At block <NUM>, the secure resource management server <NUM> creates or instructs the resource record repository <NUM> to create a resource record <NUM> for this resource based on the reporting message. The information in the resource record <NUM>, such as the resource provider data <NUM>, the resource information <NUM>, the resource user data <NUM>, and the resource transaction history <NUM> may be obtained from the reporting message.

At block <NUM>, the resource provider computing system <NUM> determines or receives instructions that a portion of the resource is available for distribution. For example, if the resource is online storage resource, the resource provider computing system <NUM> may determine a portion of the resource is available by determining that some portion of the online storage spaces is released by existing users and become available for use by other users, or new online storage spaces are added and can be made available by users. If the resource is a monetary resource, the resource provider computing system <NUM> may detect or receive instruction that additional funds are added to the resource provider's account, and a certain portion of the funds can be distributed to the resource user.

At block <NUM>, the resource provider computing system <NUM> distributes the portion of the resource to the resource user computing system <NUM>. The portion of the resource can be distributed by providing a mechanism to the resource user computing system <NUM> for accessing the resource, such as by sending a token or login credentials that can be used to access a system where the portion of the resource can be retrieved or used. At block <NUM>, the resource user computing system <NUM> receives the distributed portion of the resource from the resource provider computing system <NUM> or from the system where the portion of the resource can be retrieved. The resource user computing system <NUM> further reports the distribution of the resource by the resource provider computing system <NUM> to the secure resource management server <NUM>. Similar to block <NUM>, in some examples, the resource user computing system <NUM> generates the reporting message in the format specified by the secure resource management system <NUM>.

At block <NUM>, the secure resource management server <NUM> updates the resource record <NUM> based on the reporting message. For example, the secure resource management server <NUM> adds the resource distribution transaction to the resource transaction history <NUM> and updates the remaining unused amount of the resource in the resource information <NUM> based on the amount being distributed in the distribution transaction. Blocks <NUM>, <NUM>, and <NUM> may be repeated each time the resource provider computing system <NUM> distributes a portion of the resource to the resource user computing system <NUM>.

At some point, the resource user may decide to transfer the unused resource to a subsequent user, because, for example, the resource user no longer has the need of using the resource or the resource user does not expect to receive the entire resource by a certain date. In that case, the process 200B proceeds to block <NUM> where the resource user computing system <NUM> requests to transfer the rights of the resource to the subsequent user. At block <NUM>, the subsequent resource user computing system <NUM> associated with the subsequent user receives the request of the transfer. Before accepting the request, the subsequent resource user computing system <NUM> may send a request to the secure resource management server <NUM> to verify the resource, including the nature of the resource, the remaining unused quantity of the resource, the current authorized user of the resource, and so on. For example, a debt buyer may request the secure resource management server <NUM> to verify the loan, the amount remaining in the loan, the current creditor of the loan, etc. Upon receiving the verification request, the secure resource management server <NUM> performs the verification about the resource and the transferor based on the resource record repository <NUM> as described above with respect to <FIG>.

Based on the verification results, the subsequent resource user may accept the resource transfer at block <NUM>. In another example, the subsequent resource user computing system <NUM> may also request the secure resource management server <NUM> to predict the value of the remaining unused resource. The decision to accept the resource transfer may also be made based on the predicted value of the resource. After the rights to the resource are transferred from the resource user to the subsequent resource user, the subsequent resource user may utilize the subsequent resource user computing system <NUM> to report the transfer to the secure resource management server <NUM>. Again, the reporting message may be generated in a format specified by the secure resource management system <NUM>. The reporting message contains the information required to update the resource record <NUM> in the resource record repository <NUM>, such as the information about the subsequent resource user, the amount of resource being transferred from the resource user to the subsequent resource user, and so on. At block <NUM>, the secure resource management server <NUM> updates the resource record <NUM> based on the reporting message.

At block <NUM>, the subsequent resource user computing system <NUM> sends a request to the resource provider computing system <NUM> to request the resource to be distributed. Because the resource provider might be unaware of the resource transfer between the resource user to the subsequent resource user, the resource provider might want to validate the authenticity of the subsequent resource user. As such, upon receiving the request for resource distribution at block <NUM>, the resource provider can use the resource provider computing system <NUM> to send a request to the secure resource management server <NUM> at block <NUM> to verify the subsequent resource user. At block <NUM>, the secure resource management server <NUM> determines whether the subsequent resource user is the current authorized user based on the resource record <NUM> and returns the verification results to the resource provider computing system <NUM>.

If the subsequent resource user is indeed the current authorized user, the resource provider might distribute the resource or a portion thereof that is available to the subsequent resource user. At block <NUM>, the subsequent resource user computing system <NUM> receives the distributed resource or the token to access the distributed resource. at block <NUM>, the subsequent resource user computing system <NUM> further reports the resource distribution to the secure resource management system <NUM>, such as via a reporting message as described above. Based on the report, the secure resource management server <NUM> updates the resource record <NUM> to reflect the resource distribution.

The subsequent resource user computing system <NUM> may keep receiving the distribution of the resource from the resource provider computing system <NUM> or may transfer the remaining unused resource to another subsequent resource user. For each transaction, the secure resource management server <NUM> receives a report to update the resource record <NUM>. The processes described above may continue until there is no more unused resource or the current authorized user determines that the value of the resource becomes negligible.

Although <FIG> and <FIG> describe that the secure resource management server <NUM> creates the resource record <NUM> for a resource when the resource provider grants the rights of the resource to the resource user, other implementations can also be used. For example, the resource record <NUM> for a resource can be created when the resource is transferred from the initial authorized user to a subsequent user and be updated for each transaction occurred afterward. This is because fraudulent requests for resources mostly occur after the resource is transferred leading to confusion for the resource provider as to which user is the authorized user.

In addition, for some resources, such as monetary resources like loans, regulations, and standards (such as Metro II) provide requirements and a reporting framework for loan origination and repayment information when reported to a credit reporting agency. In such an example, the information regarding the resource and the authorized user has already been recorded and no need to be duplicated in the resource record <NUM>. In this example, the resource record <NUM> can be created after the resource is transferred from the initial creditor (the resource user) to a debt buyer or a debt collector (the subsequent resource user) and based on the reporting message regarding the transfer. From there, the debt buyer or debt collector can configure its subsequent resource user computing system <NUM> to report each payment made by the loan borrower (resource provider) to the secure resource management server <NUM>. Likewise, if the loan is further transferred to another debt buyer or debt collector (another subsequent resource user), the subsequent debt buyer or debt collector can report the transfer and any loan payment to the secure resource management server <NUM>.

Before acquiring the loan (i.e., accept the transfer), a debt buyer or debt collector can request the secure resource management server <NUM> to verify the loan, the amount remaining on the loan and the creditor of the loan. Further, as part of its decision to acquire the loan, the debt buyer or debt collector can request the secure resource management server <NUM> to predict the value of the loan. A similar process can be applied to other types of resources.

<FIG> depicts an example of a resource provider distributing resources through the secure resource management server <NUM> according to aspects presented herein. At block <NUM>, the resource provider determines, similar to block <NUM>, that a portion of the resource becomes available for distribution. At block <NUM>, the resource provider computing system <NUM> distributes the portion of the resource in a way similar to block <NUM>. Different from block <NUM>, the resource is distributed to the secure resource management server <NUM> instead of the current authorized user. This eliminates the burden of the resource user to report the resource distribution transaction to the secure resource management server <NUM>.

At block <NUM>, the secure resource management server <NUM> receives the distribution of the resource in a way similar to a resource user receiving the resource distribution as described with regard to blocks <NUM> and <NUM>. At block <NUM>, the secure resource management server <NUM> determines the current authorized user based on the resource records <NUM> stored in the resource record repository <NUM>. At block <NUM>, the secure resource management server <NUM> redistributes the portion of the resource to the current authorized user through the resource user computing device associated with the authorized user. The resource user computing device receives the distribution of the resource at block <NUM>. At block <NUM>, the secure resource management server <NUM> updates the resource record <NUM> based on the resource distribution.

<FIG> depicts an example of a resource provider distributing resources through a trusted third party according to aspects presented herein. At block <NUM>, the resource provider determines that a portion of the resource becomes available for distribution in a way similar to blocks <NUM> and <NUM>. At block <NUM>, the resource provider identifies a trusted third-party resource distributor. A trusted third party can be a certified online resource distributor, an online resource platform, an online financial institute, etc. The resource provider may identify the trusted third party by querying the secure resource management system <NUM> which may maintain a list of trusted third party resource distributors. Alternatively, or additionally, the resource provider may select a resource distributor that the resource provider trusts based on, for example, the third party's reputation or the resource provider's past experience with the third party.

At block <NUM>, the resource provider computing system <NUM> distributes the portion of the resource to the trusted third party computing system <NUM>. At block <NUM>, the trusted third party computing devices <NUM> receives the portion of the resource and at block <NUM>, the trusted third party computing devices <NUM> determines the current authorized user of the resource by querying the secure resource management server <NUM>. In response to receiving the query, the secure resource management server <NUM> retrieves the information about the current resource user based on the resource record <NUM> stored in the resource record repository <NUM>. Based on such information, the trusted third party computing devices <NUM> distributes the portion of the resource to the authorized user at block <NUM> through the corresponding resource user computing system <NUM> or subsequent resource user computing system <NUM>. The computing system <NUM> associated with the current authorized user receives the distributed resource at block <NUM>.

The trusted third party computing devices <NUM> further reports, at block <NUM>, the resource distribution to secure resource management server <NUM>, e.g. by sending a reporting message in a format specified by the secure resource management system <NUM>. The secure resource management server <NUM>, at block <NUM>, receives the reporting message and updates the resource record <NUM> accordingly. Sending the resource to a trusted third party eliminates the burden of the resource user to report the resource distribution and the burden of the secure resource management server <NUM> for receiving and redistributing the resource.

<FIG> depicts another example of a resource provider distributing resources through a trusted third party according to aspects presented herein. At block <NUM>, the resource provider determines that a portion of the resource becomes available for distribution in a way similar to blocks <NUM>, <NUM>, and <NUM>. At block <NUM>, the resource provider computing system <NUM> communicates with the secure resource management server <NUM> to request the current authorized user of the resource. At block <NUM>, the secure resource management server <NUM> identifies the current authorized user of the resource based on the resource record <NUM> in the resource record repository <NUM>.

At block <NUM>, the resource provider computing system <NUM> communicates with a trusted third-party computing device <NUM> to distribute the resource to the trusted third party. The resource provider computing system <NUM> also transmits the information about the current authorized user of the resource to the trusted third party computing devices <NUM>. At block <NUM>, the trusted third party computing device <NUM> receives the distributed portion of the resource and the current authorized user's information. At block <NUM>, the trusted third party computing device <NUM> distributes the portion of the resource to the current authorized user through the computing system associated with the authorized user. The computing system of the resource user receives the distributed portion of the resource at block <NUM>. At block <NUM>, the trusted third party computing device <NUM> reports the resource distribution to the secure resource management server <NUM>, based on which the secure resource management server <NUM> updates the resource record <NUM> for the resource in the resource record repository <NUM> at block <NUM>.

A resource provider can use any of the resource distribution mechanisms described above with respect to <FIG>. The resource provider may also distribute the resource through other ways as long as the resource distribution is reported to the secure resource management server <NUM>.

<FIG> is a flow chart illustrating an example of a process <NUM> for managing resource transactions to prevent fraudulent access to resources according to certain aspects of the present disclosure. For illustrative purposes, the process <NUM> is described with reference to implementations described above with respect to one or more examples described herein. Other implementations, however, are possible. In some aspects, the steps in <FIG> may be implemented in program code that is executed by one or more computing devices such as the secure resource management server <NUM> depicted in <FIG>. In some aspects of the present disclosure, one or more operations shown in <FIG> may be omitted or performed in a different order. Similarly, additional operations not shown in <FIG> may be performed.

At block <NUM>, the process <NUM> involves receiving a resource transaction reporting message. As described above with regard to <FIG>, the reporting message may be generated in response to the resource provider granting the rights of the resource to the resource user, a portion of the resource being distributed to the resource user with or without a trusted third party, or the resource being transferred from one user to another user.

At block <NUM>, the secure resource management server <NUM> creates or updates a resource record <NUM> for the resource depending on the type of the reporting message. If the reporting message is for the resource provider granting the rights of the resource to the resource user, the secure resource management server <NUM> creates a resource record <NUM> for the resource in the resource record repository <NUM>. If the reporting message is for resource distribution or transfer, the secure resource management server <NUM> updates the resource record <NUM> based on the transaction described in the reporting message. The process <NUM> may repeat blocks <NUM> and <NUM> as new reporting messages are received at the secure resource management server <NUM>.

At block <NUM>, process <NUM> involves receiving a request to verify a resource and the authorized user of the resource. The request may ask the secure resource management server <NUM> to verify the authenticity of a given resource and to determine if the remaining unused amount of the resource and its current authorized user match those stored in the resource record <NUM>. The request may alternatively ask for detailed information about a given resource, including the identification of the resource, the remaining unused quantity, and the current authorized user. In response to the request, at block <NUM>, the secure resource management server <NUM> searches the resource record repository <NUM> to retrieve the resource record <NUM> corresponding to the resource for verification.

At block <NUM>, the secure resource management server <NUM> determines whether the request further asks for a prediction of the expected value of the resource. In some scenarios, such as when a subsequent resource user decides whether to accept the transfer of the resource, the subsequent resource user may request the secure resource management server <NUM> to provide an estimation or a prediction about the expected value of the resource to assess whether it is worth to accept the transfer. For example, a debt buyer may want to know the expected value of the remaining loan before acquiring the loan from the current creditor. If a request for predicting the expected value of the resource is received, the process <NUM> involves, at block <NUM>, training and using a prediction model to predict the expected value of the resource at the time of the request.

In one example, the resource value prediction subsystem <NUM> can be used to construct a statistical model to predict the expected value of the resource. The statistical model requires two elements: a performance definition that stipulates the time frame and behavior necessary to identify what is to be predicted (Y), and predictors that are used to generate parameter estimates associated with a set of variables or attributes used to predict Y. The resource value prediction subsystem <NUM> predicts the expected value of the resource by predicting the likelihood (e.g. the probability or possibility) of the resource being distributed, such as the likelihood of a consumer repaying the loan. The resource value prediction subsystem <NUM> further determines a quantity or an amount associated with the remaining unused resource.

To predict the likelihood of the resource distribution, the performance definition can be defined over a limited time interval, such as one month, two months, six months, or other relatively short interval corresponding to the time span a resource user may attempt to obtain the resource before transferring it to another user. A positive resource distribution behavior is defined as one (<NUM>), and a failure or negative distribution behavior is defined as zero (<NUM>). The predicted outcome is a binary dependent variable.

The set of predictor attributes can be drawn from the resource records <NUM> for the resource provider, or alternative data other than the resource records <NUM>. Knowledge such as how long the resource has been incompletely distributed can be included as attributes for predicting the likelihood of resource distribution. For instance, the resource value prediction subsystem <NUM> can determine the number of times a particular resource has been transferred to a subsequent resource user and how much of the original amount of resource remains in the transfer. These attributes could be used to predict the likelihood of resource distribution by the resource provider.

In one example, the model for predicting the probability of resource distribution is <MAT> where Y takes the value <NUM> if the resource provider has distributed the resource, and <NUM> otherwise. The matrix X contains the candidate predictor attributes selected from the resource record <NUM> or alternative data and the vector B contains parameter estimates that determine the relationship between the predictors and Y. Various functional forms f can be used to estimate the parameters in this model, such as a logistic regression model or a probit model. Machine learning models such as neural networks can also be utilized to estimate the parameters of the model. Based on the selected model, the likelihood of resource distribution, which lies in [<NUM>,<NUM>] and defines the probability of distribution of the entire resource, can be computed.

The model can be modified to accommodate partial resource distribution, which may be more useful to the subsequent resource user, such as subsequent debt buyers of loans. In this example, these debt buyers may not be interested in attempting to recover the entire amount of the loan (though they might like to) since the final recovery effort for the last remaining resources may have a cost that exceeds the return on the effort.

As mentioned above, the resource value prediction subsystem <NUM> is further configured to predict a quantity or an amount associated with the remaining unused resource. In one example, the quantity can be predicted as the amount of resource that has not been distributed to users. In this example, the model for calculating the quantity of resources that a subsequent user of the resource will receive is given by <MAT> In words, the expected value or expected amount a resource user may receive from the resource provider's distribution is determined by the characteristics of the resource provider defined in Eqn. (<NUM>) above, which generates the probability of resource distribution. This probability multiplied by the quantity of the undistributed resources will lead to the quantity of resources a resource user may receive. This model, however, may be simplistic as it does not make assumptions about the characteristics of the resource provider in terms of the provider's ability to distribute the resource.

For example, consider two resource providers each of whom originally granted monetary resources, such as $<NUM>,<NUM> unsecured loans. One of the resource providers has lost his job and not found employment since while the other resource provider remains employed. Assume otherwise that these two resource providers are demographically identical, and that their other data such as credit data is identical. It is likely that the probability of repayment for these two individuals will be identical, which misleads the subsequent users, such as a debt collector, to apply the same recovery effort to both accounts. To provide a better prediction, the quantity of resources estimated to be recoverable can be adjusted by making use of the additional (alternative) datum that one resource provider is unemployed.

A new model for the quantity of resources that may be received can be used to provide a more accurate estimate of the portion of the resource remaining that might be recovered. For example, the amount of undistributed resource used in Eqn. (<NUM>) can be adjusted by considering the resource distribution history of the resource provider. With this adjustment, the model in Eqn. (<NUM>) becomes: <MAT> Factors such as lack of employment will affect the quantity of resources that can be received by the resource user. The expected value of the amounts of resources to be received from resource providers may have a different rank ordering than that from Eqn. This provides resource users with more realistic expectations about which resource providers are likely to provide the full amount of resources. This facilitates a subsequent resource user in its decision of whether to acquire the undistributed resource from the current authorized user and how much to pay for such undistributed resources.

The above process of predicting the quantity of resources to be received can be performed automatically. The data used to estimate each element of the above models are stored in structured data in the resource record repository <NUM>, which is a hybrid chain of custody blockchain. The secure resource management server <NUM> can extract and convert the information from the resource record repository <NUM> to attributes describing amounts of undistributed resource, amounts distributed over time, and other elements used to predict the probability of distribution or to adjust the amount expected to be distributed.

As resource users receive resource distribution and update the resource record repository <NUM>, the updated information can be used to automate the estimation or update estimates of E(received resource). The models that can be utilized to estimate the probability of resource distribution include, but are not limited to, logistic regression models, probit models, or machine learning models. These machine learning models could include neural networks, tree-based models, or deep learning models that can incorporate time into their estimation, such as convolutional neural networks. Log-linear regression, neural networks, or deep learning models can also be utilized to estimate the quantity of resources expected to be distributed. The secure resource management server <NUM> can run these models to predict the quantity of resources to be received on demand (i.e., upon receiving a request) or on a schedule to continuously refine the model and to update E(received resource). The refined model outputs reflect the latest updates in the resource records <NUM> from resource users and the resource provider.

At block <NUM>, the process <NUM> involves the secure resource management server <NUM> transmitting the requested information, including the resource information, the authorized user, and the predicted value of the resource, to the requesting entity. The process <NUM> may repeat until the resource is fully distributed (e.g. the full storage capacity has been used for the full term, or the loan is paid off), or the current authorized user decides not to pursue the distribution of the resource (e.g., the current resource user no longer needs the resource and decides not to transfer it to a subsequent user or the creditor decides that the cost for debt collection exceeds the value of the debt).

Although the above description focuses on predicting the expected value of the resource, the secure resource management server <NUM> may also utilize the resource value prediction subsystem <NUM> or other subsystems to predict the expected loss of the resource. The expected loss of the resource measures the expectation on the amount of the resource for which a resource user or a subsequent resource user will not receive a distribution. Similar to the expected value of the resource, the expected loss of the resource can also be utilized by subsequent resource users to assess whether it is worth accepting the transfer of the resource.

To determine the expected loss of the resource, the secure resource management server <NUM> can construct and use a statistical model or a machine learning model to predict the likelihood of the resource not being distributed within a certain period of time. These models can be built in a way similar to the models used to predict the likelihood of the resource being distributed as discussed above. This predicted likelihood of the resource not being distributed can be combined with the predicted amount or the adjusted amount associated with the remaining unused resource as discussed above to determine the expected loss of the resource. For example, the expected loss of the resource can be determined by replacing P(Y=<NUM>) in Eqns. (<NUM>) or (<NUM>) with the predicted likelihood of the resource not being distributed within the time period.

Any suitable computing system or group of computing systems can be used to perform the operations for the machine-learning operations described herein. For example, <FIG> is a block diagram depicting an example of a computing device <NUM>, which can be used to implement the secure resource management server <NUM>, the resource provider computing system <NUM>, the resource user computing system <NUM>, the subsequent resource user computing system <NUM> or the trusted third party computing device <NUM>. The computing device <NUM> can include various devices for communicating with other devices in the secure resource management system <NUM>, as described with respect to <FIG>. The computing device <NUM> can include various devices for performing one or more secure resource management operations described above with respect to FIGS. <NUM>-<NUM>.

The computing device <NUM> can include a processor <NUM> that is communicatively coupled to a memory <NUM>. The processor <NUM> executes computer-executable program code stored in the memory <NUM>, accesses information stored in the memory <NUM>, or both. Program code may include machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, among others.

Examples of a processor <NUM> include a microprocessor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable processing device. The processor <NUM> can include any number of processing devices, including one. The processor <NUM> can include or communicate with a memory <NUM>. The memory <NUM> stores program code that, when executed by the processor <NUM>, causes the processor to perform the operations described in this disclosure.

The memory <NUM> can include any suitable non-transitory computer-readable medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable program code or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, memory chip, optical storage, flash memory, storage class memory, ROM, RAM, an ASIC, magnetic storage, or any other medium from which a computer processor can read and execute program code. The program code may include processor-specific program code generated by a compiler or an interpreter from code written in any suitable computer-programming language. Examples of suitable programming languages include Hadoop, C, C++, C#, Visual Basic, Java, Scala, Python, Perl, JavaScript, ActionScript, etc..

The computing device <NUM> may also include a number of external or internal devices such as input or output devices. For example, the computing device <NUM> is shown with an input/output interface <NUM> that can receive input from input devices or provide output to output devices. A bus <NUM> can also be included in the computing device <NUM>. The bus <NUM> can communicatively couple one or more components of the computing device <NUM>.

The computing device <NUM> can execute program code <NUM> such as the resource verification subsystem <NUM> or the resource value prediction subsystem <NUM>. The program code <NUM> may be resident in any suitable computer-readable medium and may be executed on any suitable processing device. For example, as depicted in <FIG>, the program code <NUM> can reside in the memory <NUM> at the computing device <NUM> along with the program data <NUM> associated with the program code <NUM>, such as the reporting message, the resource value prediction model, or the predicted value. Executing the program code <NUM> can configure the processor <NUM> to perform the operations described herein.

In some aspects, the computing device <NUM> can include one or more output devices. One example of an output device is the network interface device <NUM> depicted in <FIG>. A network interface device <NUM> can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks described herein. Non-limiting examples of the network interface device <NUM> include an Ethernet network adapter, a modem, etc..

Another example of an output device is the presentation device <NUM> depicted in <FIG>. A presentation device <NUM> can include any device or group of devices suitable for providing visual, auditory, or other suitable sensory output. Non-limiting examples of the presentation device <NUM> include a touchscreen, a monitor, a speaker, a separate mobile computing device, etc. In some aspects, the presentation device <NUM> can include a remote client-computing device that communicates with the computing device <NUM> using one or more data networks described herein. In other aspects, the presentation device <NUM> can be omitted.

Unless specifically stated otherwise, it is appreciated that throughout this specification that terms such as "processing," "computing," "determining," and "identifying" or the like refer to actions or processes of a computing device, such as one or more computers or a similar electronic computing device or devices, that manipulate or transform data represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the computing platform.

The system or systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provides a result conditioned on one or more inputs. Suitable computing devices include multipurpose microprocessor-based computing systems accessing stored software that programs or configures the computing system from a general-purpose computing apparatus to a specialized computing apparatus implementing one or more aspects of the present subject matter. Any suitable programming, scripting, or other type of language or combinations of languages may be used to implement the teachings contained herein in software to be used in programming or configuring a computing device.

Aspects of the methods disclosed herein may be performed in the operation of such computing devices. The order of the blocks presented in the examples above can be varied-for example, blocks can be re-ordered, combined, or broken into sub-blocks. Certain blocks or processes can be performed in parallel.

The use of "adapted to" or "configured to" herein is meant as an open and inclusive language that does not foreclose devices adapted to or configured to perform additional tasks or steps. Additionally, the use of "based on" is meant to be open and inclusive, in that a process, step, calculation, or other action "based on" one or more recited conditions or values may, in practice, be based on additional conditions or values beyond those recited. Headings, lists, and numbering included herein are for ease of explanation only and are not meant to be limiting.

Claim 1:
A method (<NUM>) that includes one or more processing devices (<NUM>) of a secure resource management system (<NUM>) performing operations comprising:
receiving (<NUM>) a request to verify an authorized user of a resource;
responsive to receiving the request, querying (<NUM>) a resource record repository (<NUM>);
determining, from a private blockchain, a resource user currently having a right to obtain the resource as the authorized user of the resource;
transmitting (<NUM>), in response to the request, a verification result to a remote computing device (<NUM>, <NUM>), the verification result identifying the authorized user of the resource, wherein the verification result is useable to grant access to the resource to the authorized user;
characterised in that the resource record repository is implemented in a hybrid blockchain, the hybrid blockchain comprising (a) the private blockchain storing a resource record (<NUM>) that comprises information of a resource provider of the resource (<NUM>), information of resource users having a right to obtain the resource (<NUM>), and a resource transaction history (<NUM>) and (b) a public blockchain storing an encrypted version of the resource transaction history contained in the resource record, such that the public blockchain is usable to verify the authenticity of a transaction involving the resource, and wherein the public blockchain is directly accessible via a public data network (<NUM>) and the private blockchain is only accessible by the secure resource management system.