Network-level user authentication for network-based switching

Abstract

Various embodiments of the present disclosure provide techniques for determining credential-less exchanges over a network using multiple identifier mappings and member interfaces. The techniques may include receiving an exchange request for performing a value-based exchange, the exchange request including a Universally Unique Temporary Key (UUEK) and identifying an object. The techniques may include identifying a user and a tool for servicing the exchange request based on the UUEK. The techniques may include determining valid and invalid objects of the exchange request based on the user and providing an exchange authorization request indicating the valid objects to a member platform associated with the tool. The techniques may include receiving an exchange authorization response that indicates whether the exchange request is approved by the member platform and responding to the exchange request with an exchange response reflecting the exchange authorization response and the invalid objects.

Description

[0001] Cross - reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 370,274, filed on August 3, 2022, and Patent Application Serial No. 18 / 343,438, filed on June 28, 2023, the entire contents of which are incorporated herein by reference, including any drawings, tables, figures, and appendices in their entirety. Technical field

[0003] Embodiments of the present disclosure generally relate to voucher - less value exchange among multiple entities in a value system. Background art

[0004] In view of the limitations of existing exchange - processing technologies and architectures, embodiments of the present disclosure address technical challenges related to network - based value exchange. Existing processes for performing exchanges on a computing network rely on the use of persistent vouchers, such as payment vouchers (e.g., card numbers, user names, passwords, bank routing numbers, account numbers, etc.) and their proxies, which expose the recipients of the vouchers to fraud, regulatory and compliance costs, and reputation risks. Additionally, due to the static nature of traditional vouchers, whenever a user provides their vouchers for a transaction, the user must accept the risk of financial loss, impaired credit scores, identity theft, and other consequences. Strict communication protocols, data governance procedures, and authentication schemes are typically employed to address the inherent insecurity of persistent vouchers, and each of the strict communication protocols, data governance procedures, and authentication schemes introduces additional technical problems due to increased overhead and the complication of network - based transactions, but does not address the underlying data - security technical problems.

[0005] For example, traditional service providers that manage user accounts can limit the exposure of user accounts by using a disclaimer that prevents users from providing their vouchers to certain third parties. This results in network congestion because a limited number of approved parties are overloaded due to requests from the entire group. Additionally, approved parties need to register users by obtaining sensitive persistent vouchers (e.g., user names, passwords, routing / transfer vouchers, etc.) from the users and then manage a large number of persistent vouchers for multiple registered users. This provides a single attack vector for malicious parties to obtain sensitive user information of user groups. To resist such attacks, traditional transaction - processing entities need to adopt costly, resource - intensive, and robust data governance procedures and authentication schemes, but these schemes are not perfect and remain vulnerable to penetration.

[0006] Other techniques for addressing data security issues include restricting switched communications, such as those for financial transactions, to strict messaging standards such as ISO messaging standards, which lack flexibility and are not designed to provide context data (e.g., object identifiers) for transactions. By doing so, these techniques in particular prevent the verification of object-level attributes involved in the switch, which would otherwise provide seamless network-based switching. For example, traditional switched networks lack the ability to (i) convey object-level details and (ii) record user information, and thus lack the ability to determine whether the individual objects involved in a switch request are acceptable for a particular user involved in a value-based exchange. Accordingly, traditional methods for handling restrictions on value-based exchanges require that the restriction be handled at the point of the sales system and rely on manual intervention, which can be unreliable, insecure, and time-consuming. For example, traditional switched networks lack the ability to verify the age details of the user initiating the switch and rely on a corporate representative to request some form of identification from the user and be trained to evaluate the validity of the identification for a particular purchase. Thus, by using such communication standards, traditional switched networks increase network security at the expense of switch functionality.

[0007] Various embodiments of the present disclosure make important contributions to various existing network-based exchange processing techniques by addressing each of these technical challenges. SUMMARY

[0008] Various embodiments of the present disclosure disclose a secure intermediary computing platform and computing service that facilitate credential - less execution of value - based exchanges, which utilize UUEKs (Universally Unique Ephemeral Keys) to eliminate the use of persistent credentials. To this end, the intermediary computing platform can facilitate interactions between one or more member platforms to register user instruments into a value - exchange system driven by a new ephemeral data structure (referred to herein as UUEK). Different from traditional exchange systems, the intermediary computing platform does not receive or rely on persistent user credentials or instrument credentials to register user credentials. The elimination of such credentials enables the use of new and more flexible interfaces (such as the application programming interfaces (APIs) described herein), and the intermediary computing platform utilizes these interfaces to communicate with different network members to register users, users' instruments, and instrument policies without exposing user credentials at any step in the process. Once registered, the intermediary computing platform can issue a UUEK to the member platform, and the UUEK can replace traditional persistent credentials. The issued UUEK does not reflect persistent credentials or any other sensitive user information or instrument information. The interface between the member platform and the intermediary platform can allow (i) the user to present the UUEK issued by the member platform (without explicit reference to persistent credentials) to the intermediary platform, and (ii) the intermediary platform to map the issued UUEK to the instrument key of the same or another member platform and provide the instrument key to the member platform to authorize value - based exchanges. In this way, network - based transactions can be authorized in a seamless process without exposing sensitive user information or instrument information that may be vulnerable to network attacks.

[0009] By doing so, some techniques of the present disclosure enable the use of flexible interfaces (such as APIs) between entities in value - based exchanges. These interfaces can allow requests and / or responses between entities that permit the transmission of context information, such as object identifiers, during the execution of value - based exchanges. In this way, the execution of value - based exchanges can be predicted at least in part based on determinations of object - level details of the value - based exchanges. As described herein, this allows the intermediary platform to enforce user - specific restrictions, such as age restrictions, etc., without the risk of exposing sensitive user information or financial information. Finally, the techniques of the present disclosure achieve additional flexibility (e.g., by using new interfaces, etc.) and security (e.g., by eliminating persistent credentials, etc.), while reducing the computational power requirements for exchange processing and enabling significantly greater network throughput for exchange processing compared to traditional techniques.

[0010] In some embodiments, a computer-implemented method includes: receiving, by one or more processors and using a partner interface, a swap request for performing a value-based swap, where the swap request indicates a Universal Unique Temporary Key (UUEK) that includes a swap identifier; identifying, by one or more processors at least in part based on the swap identifier, a swap data object, where the swap data object includes (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; determining, by one or more processors at least in part based on one or more user attributes corresponding to the user, one or more valid objects and one or more invalid objects of the swap request; providing, by one or more processors and using a service provider interface, a swap authorization request to the member platform, where the swap authorization request indicates the tool identifier and one or more valid objects of the swap request; receiving, by one or more processors and using the service provider interface, a swap authorization response that indicates at least one of a swap grant or a swap denial; and providing, by one or more processors and using the partner interface, a swap response at least in part based on the swap authorization response, where the swap response indicates (i) a swap grant or a swap denial and (ii) one or more invalid objects of the swap request.

[0011] In some embodiments, a computing system includes a memory and one or more processors communicatively coupled to the memory. The one or more processors are configured to: receive, using a partner interface, a swap request for performing a value-based swap, where the swap request indicates a Universal Unique Temporary Key (UUEK) that includes a swap identifier; identify, at least in part based on the swap identifier, a swap data object, where the swap data object includes (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; determine, at least in part based on one or more user attributes corresponding to the user, one or more valid objects and one or more invalid objects of the swap request; provide, using a service provider interface, a swap authorization request to the member platform, where the swap authorization request indicates the tool identifier and one or more valid objects of the swap request; receive, using the service provider interface, a swap authorization response that indicates at least one of a swap grant or a swap denial; and provide, using the partner interface, a swap response at least in part based on the swap authorization response, where the swap response indicates (i) a swap grant or a swap denial and (ii) one or more invalid objects of the swap request.

[0012] In some embodiments, one or more non-transitory computer-readable media include instructions that, when executed by one or more processors, cause the one or more processors to: receive, using a partner interface, a swap request for performing a value-based swap, wherein the swap request indicates a Universally Unique Temporary Key (UUEK) that includes a swap identifier; identify a swap data object at least in part based on the swap identifier, wherein the swap data object includes (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; determine one or more valid objects and one or more invalid objects of the swap request at least in part based on one or more user attributes corresponding to the user; provide, using a service provider interface, a swap authorization request to the member platform, wherein the swap authorization request indicates the tool identifier and the one or more valid objects of the swap request; receive, using the service provider interface, a swap authorization response that indicates at least one of a swap grant or a swap denial; and provide, using the partner interface, a swap response at least in part based on the swap authorization response, wherein the swap response indicates (i) a swap grant or a swap denial and (ii) the one or more invalid objects of the swap request. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Accordingly, having generally described the disclosure, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in which:

[0014] Figure 1 FIG. is an example diagram of a computing ecosystem according to one or more embodiments of the present disclosure;

[0015] Figure 2 FIG. is an example schematic diagram of a computing platform according to one or more embodiments of the present disclosure;

[0016] Figure 3 FIG. is an example schematic diagram of a client device according to one or more embodiments of the present disclosure;

[0017] Figure 4 FIG. is an example block diagram of an example voucherless value exchange system according to one or more embodiments of the present disclosure;

[0018] Figure 5 FIG. is an example data diagram for facilitating voucherless value exchange according to one or more embodiments of the present disclosure;

[0019] Figure 6 A process flow for facilitating voucherless value exchange according to one or more embodiments of the present disclosure is provided;

[0020] Figure 7A process flow for determining an object for value-based exchange according to one or more embodiments of the present disclosure is provided; and

[0021] Figure 8 A messaging process for verifying value-based exchange according to one or more embodiments of the present disclosure is provided. Detailed Description

[0022] The various embodiments of the present disclosure are described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the disclosure are shown. In fact, the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Unless otherwise noted, the term "or" is used herein in both an alternative and a conjunctive sense. The terms "exemplary" and "example" are used only as examples and do not denote a level of quality. Terms such as "calculate," "determine," "generate," and / or similar terms are used interchangeably herein to denote the creation, modification, or identification of data. Additionally, the terms "at least partially based on," "at least based on," "based on," and / or similar phrases are used interchangeably herein in an open-ended manner such that they do not necessarily denote being based solely or at least partially on the recited elements, unless otherwise noted. Like reference numerals always refer to like elements.

[0023] I. Overview and Technical Advantages

[0024] The various embodiments of the present disclosure provide technical solutions for managing network-based exchanges. In various embodiments, an exchange platform may be configured to facilitate a credential-less value exchange between one or more member platforms. These exchanges may be facilitated in real time without persistent credentials, which may expose members to financial, legal, reputational, or other risks. Thus, in various embodiments, a client device may purchase, sell, and / or perform value-based exchanges in real time over any network without exposing sensitive information that is vulnerable to network-based attacks.

[0025] The embodiments of the present disclosure provide improved object-level exchange verification techniques and policy matching techniques that utilize new interfaces and data conversions to increase data security and communication flexibility while reducing the computational resource expenditure requirements for protecting sensitive data communicated over a network.

[0026] For example, some techniques of the present disclosure retrieve data objects and convert the data objects into unique data keys that can only be recognized by approved entities. The data keys can be provided and / or established by leveraging an exchange interface between an exchange platform and other member platforms in a switching network. Once established, the data keys can be mapped to sensitive credentials stored in a source platform (e.g., a service provider platform) without the need for network transmission of the sensitive credentials. Future communications that facilitate value-based exchanges can replace traditional persistent credentials with data keys, enabling the source platform to identify the persistent credentials and / or perform one or more actions on specific tools associated with the persistent credentials. In this way, the exchange platform can use keys (and / or other identifiers) that cannot themselves be traced to potentially sensitive information to facilitate exchanges. This in turn enables the exchange platform to comprehensively track, facilitate, and distribute network-based communications without exposing members to cyberattacks.

[0027] Some embodiments of the present disclosure propose network-based exchange processing techniques for facilitating credential-less exchanges. To this end, some techniques of the present disclosure utilize a new data structure, the UUEK, which can replace the persistent credentials traditionally used to authorize value-based exchanges. Using the techniques of the present disclosure, the UUEK can be securely issued across member platforms to allow users to perform value-based exchanges using identifiers that can be recognized by a single party (i.e., the exchange platform). The UUEK can be mapped to unique identifiers that can reference sensitive information without directly identifying (and thus exposing) the sensitive information. For example, the unique identifier can reference a mapping that can only be interpreted by the source platform, such that malicious parties unrelated to the exchange platform cannot use the identifier. In this way, the exchange platform can distribute, track, and facilitate exchanges without exposing member platforms to data security risks. Additionally, the exchange platform can continuously update, modify, and / or reassign the UUEK to member platforms to continuously and real-time adapt to the UUEK. In this way, the exchange platform can provide technical improvements for data and network security while reducing computational resource requirements (e.g., for securely encrypting persistent credentials) to facilitate value-based exchanges.

[0028] Some techniques of the present disclosure can utilize the credential-less exchanges of the present disclosure to enable the use of flexible exchange interfaces among members of an exchange network. Different from traditional exchange interfaces, credential-less exchanges allow the use of interfaces that can provide context information (e.g., object-level details) associated with the requested value-based exchange. By doing so, the intermediary computing platform can receive the information necessary to verify each object of the value-based exchange against various exchange criteria (e.g., user age restrictions). Finally, this enables a network management solution in which a single computing entity (the intermediary computing platform) can enforce user restrictions on behalf of multiple members in real time.

[0029] The exchange interface provides a transport mechanism for both object-level details and user-level details, thereby implementing a central verification service for verifying individual objects for a particular user involved in value-based exchange. In some examples, user-level details may be associated with a UUEK for authorizing value-based exchange. In some examples, user-level details may be recorded in a system data object corresponding to the UUEK. In any case, secure and virtual UUEKs can replace the traditional reliance on physical forms of identification for user verification purposes. This in turn allows a single intermediate computing platform to handle object verification for a user. By handling exchange verification, the techniques of the present disclosure reduce the requirements for secondary computing entities (and users of secondary computer entities) in the exchange network, thereby allowing new entrants to support unique projects without regard to the complexity of their representation or their computing solutions.

[0030] Example inventive and technical advantage embodiments of the present disclosure include: (i) data conversion, mapping, and processing schemes for facilitating network-based credential-less exchange, (ii) an exchange interface and network-based communication schemes for enhancing network security for cross-platform communication, (iii) temporary data structures and data management techniques for allocating temporary data structures to facilitate real-time, secure, and dynamic value-based exchange, and (iv) real-time user verification techniques for verifying individual objects for users involved in the exchange.

[0031] II. Example Definitions

[0032] In some embodiments, the term "exchange platform" refers to a computing entity configured to facilitate credential-less value exchange for one or more members in an exchange network. The exchange platform may include physical and / or wireless couplings and one or more processing devices, storage devices, etc. configured to jointly (and / or separately) perform one or more computing tasks for facilitating value-system agnostic exchange. In some examples, the exchange platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses, etc.) between multiple members. As described herein, APIs may be utilized to facilitate secure exchange between one or more members in any value system.

[0033] In some embodiments, the term "member" refers to an entity that collaborates with an exchange platform to participate in a value exchange. For example, a member can include (i) a partner that utilizes the exchange platform to receive value, (ii) a service provider that utilizes the exchange platform to provide value, and / or (iii) both a partner and a service provider. As used herein, when a member receives value through a value exchange, the member can be referred to as a partner, and / or when a member provides value through a value exchange, the member can be referred to as a service provider. Thus, depending on the role of the member in the value exchange, the same member can be a partner or a service provider. For example, a member can be a partner that receives value in a value exchange. The same member can be a service provider that provides value in another value exchange. In some examples, the same member can be both a partner and a service provider in the same value exchange, such that the member utilizes the exchange platform to provide and receive value in a single-member value exchange.

[0034] In some embodiments, when a member utilizes a service provided by a service provider, the member is a partner. A partner can include any value-seeking entity in any value system. For example, in a financial value system, a partner can include a merchant (e.g., a retailer, a physical business, etc.) that can utilize a service provider (e.g., a financial institution) to obtain funds for financial transactions. Additionally or alternatively, in an information value system, a partner can include a news publisher (e.g., a newspaper, a media organization, etc.) that can utilize a service provider (e.g., a news agency (e.g., a wire service, a news service, etc.)) to obtain information for information transactions. It should be understood that the techniques of the present disclosure can be applied to any value system, and a partner can include value seekers in any corresponding value system.

[0035] In some embodiments, when a member provides a service to a partner, the member is a service provider. A service provider can include a value source in any value system. For example, in a financial value system, a service provider can include a financial institution (e.g., a bank, a currency exchange platform, a credit union, etc.) that can provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a service provider can include a news agency (e.g., a wire service, a news service, etc.) that can provide source information to a news publisher for publication. It should be understood that the techniques of the present disclosure can be applied to any value system, and a service provider can include any value source for any corresponding value system.

[0036] In some embodiments, the term "service provider tool" refers to a mechanism used by a service provider to provide value on behalf of a particular user. Service provider tools can depend on the value system and / or the service provider. In some examples, service provider tools can include accounts opened at the service provider. For example, in a financial value system, service provider tools can include bank accounts (e.g., checking, savings, etc.), brokerage accounts, lines of credit, etc. In an information value system, service provider tools can include subscription accounts, etc. In some examples, service provider tools can include virtual tools hosted by the service provider platform.

[0037] In some embodiments, the services provided by the service provider are subject to one or more policies. For example, the service provider can be associated with one or more membership policies to verify the use of service provider tools maintained by the service provider.

[0038] For example, the service provider and / or the service provider's service provider tools can be associated with an entity that manages the use of one or more services provided by the service provider. For example, the service provider can facilitate an electronic benefit transfer (EBT) system that provides financial assistance for authorized food and household items, such as for the Supplemental Nutrition Assistance Program ("SNAP"), Temporary Assistance for Needy Families ("TANF"), the Special Supplemental Nutrition Program for Women, Infants, and Children ("WIC"), etc. As another example, the service provider can promote a healthcare program on behalf of a healthcare provider, which restricts benefits based on healthcare eligibility, procedure codes, procedure locations, etc.

[0039] Additionally or alternatively, the service provider can manage the use of its own services. For example, the service provider can maintain service provider tools for the service provider's users. The service provider can restrict service provider tools on behalf of the user, on behalf of one or more internal policies, etc. For example, the service provider can include a financial institution that allows one or more users to restrict access to funds provided by the financial institution. In this way, the user can provide restricted access to service provider tools by establishing one or more membership policies for the service provider tools.

[0040] In some embodiments, the term "member policy" refers to a data entity that defines one or more criteria for validating objects for value-based exchanges. A member policy can correspond to a member and / or a service provider tool of the member. For example, a member policy can define one or more criteria for validating an object based at least in part on one or more member-specific criteria. Additionally or alternatively, a member policy can define one or more criteria for validating an object based at least in part on one or more tool-specific criteria. Member-specific criteria can be applied to multiple service provider tools associated with a member, while tool-specific criteria can be applied to at least one of the multiple service provider tools associated with a member.

[0041] A member policy can indicate multiple authorized and / or unauthorized policy attributes of a value-based exchange. Authorized policy attributes can indicate one or more objects, object attributes, and / or value exchange attributes that are authorized for value-based exchanges using a service provider tool according to the member policy. Unauthorized policy attributes can indicate one or more objects, object attributes, and / or value exchange attributes that are restricted for value-based exchanges using a service provider tool according to the member policy. In some examples, a member policy can define multiple authorized policy attributes, and the multiple unauthorized policy attributes can include multiple undefined attributes. In some examples, a member policy can define multiple unauthorized policy attributes, and the multiple authorized policy attributes can include multiple undefined attributes.

[0042] In some examples, policy attributes can include object identifiers, one or more object attributes, and / or one or more value exchange attributes that identify an object and / or an amount of one or more authorized / unauthorized objects.

[0043] For example, a membership policy may include multiple object identifiers. The multiple object identifiers may indicate multiple objects that have been authorized / unauthorized to use service provider tools for acquisition (e.g., purchase, etc.). In some examples, the object identifier may be a global object identifier. For example, the global object identifier may be a stock keeping unit (SKU) code. Additionally or alternatively, the global object identifier may be a manufacturer part number (MPN), a global trade item number (GTIN), a product or service name, an international standard book number (ISBN), a universal product code (UPC), an international article number (EIN), a European Article Number (EAN), etc. In some examples, the object identifier may include a system object identifier. For example, the system object identifier may include an identifier corresponding to a record data object representing an object within an exchange platform (e.g., a table identifier, etc.). In some embodiments, the system object identifier and the global object identifier are the same.

[0044] As another example, a policy attribute may indicate one or more object attributes that indicate authorized / unauthorized objects. The one or more object attributes may indicate one or more objects that have been authorized and / or unauthorized to use service provider tools for acquisition (e.g., having one or more different object identifiers, etc.). For example, the object attribute may indicate a category of objects that are unauthorized to use service provider tools for acquisition (e.g., restricted substances, etc.) and / or a category of objects that are authorized to use service provider tools for acquisition (e.g., food items, etc.).

[0045] As yet another example, a policy attribute may include a value exchange attribute corresponding to a specific value-based exchange and / or an object included in the value-based exchange. For example, the value exchange attribute may include a threshold exchange value for a value-based exchange using service provider tools. Additionally or alternatively, the value exchange attribute may include a threshold object exchange value, a threshold object exchange quantity, etc. for an object included in the value-based exchange. The threshold object exchange value may indicate the authorized value for using service provider tools to acquire a specific object. The threshold object exchange quantity may indicate the authorized quantity (e.g., weight, unit quantity, etc.) of a specific object that can be acquired (e.g., purchased, etc.) using service provider tools.

[0046] In some embodiments, the term "record data object" refers to a data object that represents an object that may be involved in a value-based exchange. In some examples, a record data object may be an internal representation of an object of an exchange platform. For example, the object may include different units of a value-based exchange, where value is being transferred for the different unit. A record data object of the object may include a data object that records one or more aspects of the object (e.g., object identifier, object attributes, etc.).

[0047] For example, a record data object may include an object identifier and / or one or more object attributes of a particular object associated with a value system. The object may be at least partially based on a value system. For example, in a financial value system, the object may be a tangible or intangible item, product, and / or the like that can be purchased with a monetary unit in an exchange. In a healthcare value system, the object may be a healthcare procedure and / or the like that can be covered by a healthcare policy.

[0048] In some examples, an exchange platform may maintain and / or access an object data store that includes a plurality of record data objects. As described herein, the object data store may include a plurality of record data objects that are at least partially derived from one or more members of an exchange network and / or one or more third parties.

[0049] In some embodiments, data from one or more external data sources is used to generate, update, and / or maintain the object data store. For example, one or more external data sources may include one or more object directories. Each object directory may include a plurality of object identifiers and / or object attributes for each object identifier. For example, an object directory may include 10 data points, 20 data points, 40 data points, or more data points for each of a plurality of object identifiers. Each data point may indicate an object attribute of the object. The object attributes may be obtained by the external data source from a manufacturer, a supplier, and / or any other entity associated with a particular object. In some examples, the object data store may be aggregated according to each of one or more different external data sources to aggregate, verify, and / or augment a plurality of record data objects 424 associated with a plurality of different entities.

[0050] In some embodiments, the term "object attribute" refers to a data entity that describes a characteristic of an object. Object attributes may include object-based attributes and / or exchange-based attributes.

[0051] For example, object-based attributes can include spatial attributes, counting attributes, value attributes, source attributes, composition attributes, category attributes, and / or any other attributes that describe the characteristics of the object. For example, spatial attributes can indicate one or more dimensions of the object (e.g., height, width, weight, etc.), value attributes can indicate the value of the object (e.g., price, etc.), composition attributes can indicate one or more raw materials, components, etc. of the object, category attributes can indicate one or more categories of the object (e.g., restricted substances, etc.) and / or the like. For example, one or more category attributes can indicate whether the object is associated with (i) one or more general store categories (e.g., vegetables, fruits, dairy products, meats, grains, seeds, alcohol, tobacco, in-store consumables, hot foods, pharmacy, pet food, and non-food items), (ii) one or more medical categories (e.g., dental, eye care, general health, etc.), (iii) one or more information categories (such as international sources, domestic sources, etc. and / or the like). In some examples, the composition attribute can indicate one or more components of the object, such as the volume percentage of alcohol in the object, one or more raw materials (e.g., meat, dairy products, peanut products, tree nut products, soybean products, etc.).

[0052] In some examples, object-based attributes can be at least partially based on a value system. For example, at least in a finance-based value system, object-based attributes can include one or more line item attributes, one or more line item adjustments, etc. Line item attributes can include sequence, line item group, product code, item name, item source (e.g., supplier, manufacturer, etc.), description, quantity, quality (e.g., grams, kilograms, etc.), one or more spatial dimensions (e.g., length, width, height, volume, etc.), unit amount, unit tax amount, line amount (e.g., the amount of the line item), line tax amount, etc. Line item adjustments can include adjustment type (e.g., manufacturer discount, store discount, return, pay cash, pay gift card, pay other, etc.), item, product, or service code, item description, item quantity, unit item, item quality (e.g., grams, kilograms, etc.), unit amount, unit tax amount, line amount (e.g., the amount of the line item), line tax amount, etc.

[0053] In some examples, one or more exchange-based attributes may indicate one or more aggregated exchange characteristics. For example, an exchange-based attribute may include a count attribute that describes the number of value-based exchanges involving a particular object. For example, the count attribute may indicate the unit quantity of a particular object obtained through multiple value-based exchanges. For example, as described herein, whenever an object is referenced in a value-based exchange, the exchange platform may increment the count attribute of the object. In some examples, whenever an object is authorized for acquisition, the exchange platform may increment the count attribute of the object. In some examples, a record data object may include multiple count attributes that respectively identify the unit quantity of the object that has been acquired (e.g., acquired count), the unit quantity of the object that has been authorized for acquisition (e.g., authorized count), and / or the unit quantity of the object that has been requested for acquisition (e.g., requested count).

[0054] In some examples, one or more exchange-based attributes may include exchange-specific characteristics. For example, an exchange-specific characteristic may include a source attribute that describes the location (e.g., retailer, physical store, healthcare center, information source, etc.) from which an object is obtained (e.g., purchased, etc.) through a value-based exchange. For example, the location may include a virtual location and / or a physical location. In some examples, the location may depend on the value system. For example, in a financial value system, the source attribute may identify a retailer, a particular physical store of the retailer, an online platform, etc. In a healthcare value system, the source attribute may be a virtual and / or physical healthcare center, etc. In an information value system, the source attribute may be an information source, etc.

[0055] In some examples, a record data object and / or a count attribute may be source-specific. For example, different record data objects and / or count attributes may be maintained for each source from which an object can be obtained. Additionally or alternatively, a record data object and / or a count attribute may be source-independent.

[0056] In some embodiments, the term "restricted object" refers to one or more different types of objects that may be associated with exchange criteria for acquisition through a value-based exchange. For example, a restricted object may include an object that is subject to one or more acquisition restrictions.

[0057] In some embodiments, the term "acquisition restriction" refers to a data entity that defines one or more criteria for validating an object in a value-based exchange. An acquisition restriction may define one or more user-specific rules, location-specific rules, and / or other rules for validating a restricted object.

[0058] Location-specific rules can include one or more geographic restrictions and / or sovereign entity restrictions. For example, location-specific rules can indicate restrictions on obtaining one or more restricted objects in one or more countries, states, counties, etc. within sovereign entities and / or other geographic regions. For example, federal laws that can form the basis of the acquisition restrictions can prohibit the acquisition of one or more restricted objects.

[0059] User-specific rules can include one or more age restrictions, residence restrictions, credit score restrictions, etc. In some examples, the age restriction can indicate one or more age ranges and / or age thresholds for obtaining restricted objects. For example, the age restriction can define one or more age categories for one or more different types of restricted objects. Each age category can define an age range (e.g., age group, etc.) corresponding to different types of restricted objects. For example, the first age category can indicate an age range below the minimum age for obtaining the first object (e.g., tobacco), the second age category can indicate an age range above the minimum age range for obtaining tobacco but below the second minimum age for obtaining the second object (e.g., alcohol), and the third age category can indicate an age range above the second minimum age range.

[0060] In some embodiments, the acquisition restrictions can be at least partially based on the exchange location associated with the value-based exchange. For example, location-specific rules and / or user-specific rules can be modified for different locations. User-specific rules can be formed based on one or more legal requirements corresponding to the exchange location, such as one or more age categories, etc.

[0061] The acquisition restrictions can correspond to the object and / or one or more object attributes. For example, one or more acquisition restrictions can correspond to one or more object identifiers. For example, the record data object of the object can include an indication of one or more acquisition restrictions. Additionally or alternatively, the acquisition restrictions can correspond to one or more object attributes. For example, the acquisition restrictions can correspond to category attributes (e.g., alcohol, tobacco, etc.), composition attributes (e.g., percentage of alcohol, etc.), etc.

[0062] In some embodiments, the term "valid object" refers to an object of a value-based exchange that is authorized according to one or more acquisition restrictions (if applicable). For example, a valid object may correspond to an object identifier and / or one or more object attributes that do not correspond to a restricted object in a value-based exchange and / or do not correspond to a restricted object in a value-based exchange that implements an acquisition restriction corresponding to the restricted object. For example, in a financial value system, a valid object may be a product or service that a user of a service provider tool is eligible to purchase at an exchange location. For example, a product may be a gallon of milk that can be associated with an SKU code and / or one or more object attributes (such as "category: dairy", "quantity: 1 gallon"). If no acquisition restrictions apply to the SKU code and / or one or more object attributes (such as "category: dairy", "quantity: 1 gallon"), then the product may be a valid object of the value-based exchange.

[0063] In some embodiments, the term "invalid object" refers to an object of a value-based exchange that is not authorized according to one or more acquisition restrictions (if applicable). For example, an invalid object may correspond to an object identifier and / or one or more object attributes that correspond to a restricted object in a value-based exchange that does not implement an acquisition restriction corresponding to the restricted object. For example, in a financial value system, an invalid object may be a product or service that a user of a service provider tool is not eligible to purchase at an exchange location. For example, a product may be one liter of alcohol that can be associated with an SKU code and / or one or more object attributes (such as "category: restricted substance", "quantity: liter"). If an acquisition restriction applies to the SKU code and / or one or more object attributes (such as "category: restricted substance", "quantity: 1 liter"), and one or more user attributes and / or the exchange location do not meet the acquisition restriction, then the product may be an invalid object of the value-based exchange.

[0064] In some embodiments, the term "exchange request" refers to a data entity that defines a request to perform a value exchange. An exchange request can be provided from a member of an exchange network to an exchange platform. An exchange request can include one or more request attributes. The one or more request attributes can include one or more object identifiers, object attributes, resolution flags, etc. In some examples, an exchange request can include an exchange location. The exchange location can indicate a physical location (such as a brick-and-mortar store), a virtual location (such as an online retail platform), and / or a geographic region (such as a country, state, county, or other area).

[0065] One or more request attributes may include a plurality of object identifiers that correspond to a plurality of objects associated with a value-based exchange. Additionally or alternatively, one or more request attributes may include one or more object attributes of the plurality of objects. For example, one or more object attributes may include one or more object-based attributes (e.g., one or more line item attributes), one or more exchange-based attributes (e.g., quantity of the object, location of the object, etc.). For example, an exchange request may indicate an exchange location from which to obtain an object.

[0066] In some examples, a request attribute may indicate one or more request resolution flags. A request resolution flag may indicate one or more member requirements (e.g., partner requirements, etc.) of a member issuing a request for a value-based exchange. For example, one or more request resolution flags may be set by a member of an exchange network that provides an exchange request to an exchange platform. In some examples, a request resolution flag may indicate partial exchange authorization or full exchange authorization. Partial exchange authorization may authorize a partial completion of a value-based exchange, while full exchange authorization may only authorize a full completion of a value-based exchange. For example, full exchange authorization may require verification of all objects referenced in a value-based exchange.

[0067] In some embodiments, the term “valid exchange data object” refers to a data object that indicates one or more valid objects of a value-based exchange. In some examples, a valid exchange data object may be based at least in part on a comparison between an exchange request and / or one or more user attributes corresponding to the exchange request. In some examples, a valid exchange data object may include a plurality of object identifiers and / or one or more object attributes of one or more valid objects of a value-based exchange.

[0068] In some examples, a valid exchange data object may indicate an exchange value. The exchange value may be an aggregated value of each of the valid data objects. In some examples, some techniques of the present disclosure may be utilized to modify the exchange value based on an initial exchange value to adjust the exchange value to meet the valid objects of a value-based exchange.

[0069] In some examples, a valid exchange data object may indicate one or more object states of one or more valid objects.

[0070] In some embodiments, the term "invalid exchange data object" refers to a data object that indicates one or more invalid objects of a value-based exchange. In some examples, the invalid exchange data object can be at least partially based on a comparison between an exchange request and one or more user attributes corresponding to the exchange request. For example, the invalid exchange data object can indicate multiple invalid objects of a value-based exchange. Additionally or alternatively, the invalid exchange data object can be at least partially based on the exchange request and a valid exchange data object. For example, the invalid exchange data object can indicate multiple invalid objects of a value-based exchange. For example, the invalid exchange data object can indicate multiple objects of a value-based exchange that are not included in the valid exchange data object.

[0071] The invalid exchange data object can include multiple object identifiers and / or one or more object attributes of one or more invalid objects of a value-based exchange. In some examples, the invalid exchange data object can indicate one or more object states of one or more invalid objects.

[0072] In some embodiments, the term "object state" refers to a data entity that indicates the determination and / or classification of an object with respect to a value-based exchange. For example, the object state of a valid object can include an object eligibility state, etc. As another example, the object state of an invalid object can include an object ineligibility state, etc. The object state of an object not evaluated according to a membership policy can include an object not evaluated state. The object state of an object not processed according to a membership policy can include an object not specified state. In some examples, the object state can indicate an acquisition restriction corresponding to an invalid object. For example, the object state can include an object age restriction state, etc.

[0073] In some embodiments, the term "exchange authorization request" refers to a data entity that defines a request for a member to perform a value-based exchange. In some embodiments, the exchange authorization request is provided from an exchange platform to a member of an exchange network. For example, in response to an exchange request from a partner of the exchange network, the exchange authorization request can be provided to a service provider of the exchange network. In some examples, the exchange authorization request can indicate a valid exchange data object for the exchange request. For example, the exchange authorization request can indicate one or more valid data objects, a valid exchange value, one or more object states associated with one or more valid data objects, etc. In some examples, the exchange authorization request can indicate an invalid exchange data object of the exchange request. For example, the exchange authorization request can indicate one or more invalid data objects, one or more object states associated with one or more invalid data objects, etc.

[0074] In some embodiments, the term "exchange authorization response" refers to a data entity that defines a response to an exchange authorization request. In some embodiments, the exchange authorization response is provided from a member of the exchange network to the exchange platform. For example, the exchange authorization response may be provided by a service provider of the exchange network in response to an exchange authorization request indicating one or more valid objects from an exchange request.

[0075] In some embodiments, the exchange authorization response indicates at least one of an exchange grant or an exchange denial. The exchange authorization response may be at least partially based on a comparison between an exchange value (e.g., modifying the exchange value at least partially based on valid objects, etc.) and the asset availability of the service provider tool. For example, in response to receiving an exchange authorization request, a member may be configured to compare the exchange value with the asset availability of an identified service provider tool. In the case where the asset availability exceeds the exchange value, a value-based exchange may be authorized (e.g., resulting in an exchange grant, etc.), otherwise the value-based exchange may be rejected (e.g., resulting in an exchange denial).

[0076] In some embodiments, the exchange authorization response indicates one or more context response attributes. For example, one or more context response attributes may indicate one or more influencing factors of the exchange authorization response. For example, the influencing factors may include bad actor risk and / or fraud check, error, full approval, tool closure, tool-based risk and / or fraud check, insufficient value, UUEK invalid, over limit (e.g., exceeding UUEK or tool usage limit), missing line item (e.g., for a value exchange that does not include valid objects), tool not found, account not found, need for personal identification number (pin), partial approval, member unavailable, transaction risk and / or fraud check, unsupported operation, user contact member (e.g., the user may need to contact a member (such as a service provider) to resolve an issue), user risk and / or fraud check, and combinations thereof.

[0077] In some embodiments, the term "exchange response" refers to a data entity that defines a response to an exchange request. In some embodiments, the exchange response is provided from the exchange platform to the member that provided the exchange request. The exchange response may indicate an exchange grant and / or an exchange denial. Additionally or alternatively, the exchange response may indicate valid data objects, invalid data objects, and / or context response attributes. For example, the exchange response may indicate one or more valid objects and / or one or more invalid objects for the exchange request.

[0078] In some embodiments, the term "exchange record" refers to a data entity that provides context information for an exchange request. The context information may indicate one or more aspects of an exchange request, an exchange response, an exchange authorization request, and / or an exchange authorization request. For example, an exchange record may indicate one or more valid objects, invalid objects, the object state of each valid and / or invalid object, and / or any other information associated with a value-based exchange.

[0079] In some embodiments, the term "member platform" refers to a computing entity corresponding to a member. A member platform may include a partner computing platform representing a partner, a service provider computing platform representing a service provider, and / or both a partner computing platform representing a partner and a service provider computing platform representing a service provider. In some examples, a member platform may be both a partner platform and a service provider platform. For example, the same member platform may be configured to operate on behalf of a partner for one value exchange and on behalf of a service provider for another value exchange. In some examples, the same member platform may be configured to represent both a partner and a service provider in a single value exchange. Note that the term member platform may refer to a partner platform, a service provider platform, or both a partner platform and a service provider platform, and in some examples, the member platform may depend on the role of the member platform in the value exchange (e.g., and / or one or more APIs used by the member platform in the value exchange).

[0080] In some embodiments, a partner platform is a computing entity configured to perform one or more operations on behalf of a partner. For example, a partner platform may include one or more processing devices, storage devices, etc., which are physically coupled and / or wirelessly coupled and configured to jointly (and / or separately) perform one or more computing tasks for requesting value in an exchange unrelated to the value system. In some examples, a partner platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication with an exchange platform (e.g., requests and responses, etc.). In some examples, a partner platform may be configured to host one or more user-facing applications for interacting with one or more users (e.g., partner applications, etc.).

[0081] In some embodiments, a service provider platform is a computing entity configured to perform one or more operations on behalf of a service provider. For example, the service provider platform may include one or more processing devices, storage devices, etc., which are physically and / or wirelessly coupled and configured to jointly (and / or separately) perform one or more computing tasks that provide value in an exchange independent of a value system. In some examples, the service provider platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication with an exchange platform (e.g., requests and responses, etc.). In some examples, the service provider platform may be configured to facilitate one or more service provider tools. In some examples, the service provider platform may be configured to host one or more user-facing applications (e.g., service provider applications, etc.) for managing one or more service provider tools.

[0082] In some embodiments, the term "exchange interface" refers to a set of instructions for facilitating communication between an exchange platform and one or more member platforms and / or internal services. The exchange interface may include APIs, file-based interfaces, message queue-based interfaces, etc. For example, the exchange interface may include APIs, such as one or more simple object access protocol (SOAP) APIs, one or more remote procedure call (RPC) APIs, one or more websocket APIs, one or more representational state transfer (REST) APIs, etc. In some embodiments, the exchange interface may include one or more RPC APIs, such as one or more gRPC APIs.

[0083] The exchange platform may include, define, and / or otherwise utilize one or more different exchange interfaces to facilitate communication with one or more external platforms (e.g., one or more member platforms, (e.g., partner platforms, service provider platforms, etc.)). Each API may include multiple communication instructions, message definitions, etc. for exchange requests and / or responses between the exchange platform and entities participating in the value exchange. For example, the exchange interface may include a partner API for facilitating communication with a partner platform and / or a service provider API for facilitating communication with a service provider platform.

[0084] In some embodiments, the term "partner interface" refers to an exchange interface for facilitating one or more communications between a partner platform and an exchange platform. The partner interface may define one or more communication instructions, message definitions, etc. for facilitating one or more request messages and / or response messages between the partner platform and the exchange platform. For example, the partner interface may include an API that defines (i) requests from a computing entity serving as the partner platform to the exchange platform and / or (ii) requests from the exchange platform to the partner platform. For example, the partner interface may define one or more registration messages, session messages, transaction messages, etc. for facilitating the value exchange of the partner. In some embodiments, the partner interface defines one or more identifiers for securely identifying one or more parts of the value exchange.

[0085] In some embodiments, the term "service provider interface" refers to an exchange interface for facilitating one or more communications between a service provider platform and an exchange platform. The service provider interface may define one or more communication instructions, message definitions, etc. for facilitating one or more request messages and / or response messages between the service provider platform and the exchange platform. For example, the service provider interface may include an API that defines (i) requests from a computing entity serving as the service provider platform to the exchange platform and / or (ii) requests from the exchange platform to the service provider platform. For example, the service provider interface may define one or more registration messages, session messages, transaction messages, etc. for facilitating the value exchange using the service provider tools. In some embodiments, the service provider interface defines one or more identifiers for securely identifying one or more parts of the value exchange.

[0086] In some embodiments, the term "entity partition" refers to a unique identifier of a computing entity. The entity partition may include unique numbers, alphanumerics, etc. representing a specific computing entity. For example, the entity partition may include a member partition representing a member platform, a service provider partition representing a service provider platform, a partner partition representing a partner platform, etc.

[0087] In some embodiments, the term "service provider partition" refers to a unique identifier of a service provider and / or the service provider's service provider platform. A service provider partition may include a sequence of digits, an alphanumeric sequence, any / and any other sequence of characters or symbols that represents a service provider associated with the exchange platform (e.g., joined to the exchange platform, registered with the exchange platform, etc.). For example, the exchange platform may include multiple service provider partitions that respectively identify service provider platforms attached to the exchange platform (e.g., joined to the exchange platform, registered with the exchange platform, etc.). Each service provider partition may represent a service provider platform that has been configured with one or more exchange platform software development kits (SDKs) for implementing the service provider interface of the exchange platform, etc.

[0088] In some embodiments, the term "partner partition" refers to a unique identifier of a partner and / or the partner's partner platform. A partner partition may include a sequence of digits, an alphanumeric sequence, any / and any other sequence of characters or symbols that represents a partner associated with the exchange platform. For example, the exchange platform may include multiple partner partitions that respectively identify partner platforms attached to the exchange platform (e.g., joined to the exchange platform, registered with the exchange platform, etc.). Each partner partition may represent a partner platform that has been configured with one or more exchange SDKs for implementing the partner interface of the exchange platform.

[0089] In some embodiments, the term "user-facing application" refers to a computer program hosted by a computing entity to facilitate one or more user interactions. A user-facing application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for a computing entity (such as a member platform). For example, a user-facing application may facilitate communication between a member and a user. For example, a user-facing application may be configured to present one or more user interfaces to interact with the user on behalf of the member. In some examples, a user-facing application may be configured to receive user input (e.g., via one or more user interfaces) to receive information from the user.

[0090] In some embodiments, the user-facing application is a partner application hosted by a partner platform (e.g., a member platform of a partner for a particular exchange, etc.) to facilitate the functions of the partner. The partner application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the partner. For example, the partner application may be configured to present one or more user interfaces for interacting (e.g., browsing, purchasing, commenting, etc.) with one or more products provided by a retail-based partner, one or more information units provided by an information-based partner, etc. In some examples, the partner application may be configured to receive user input (e.g., via one or more user interfaces) to receive information from the user.

[0091] In some embodiments, the user-facing application is a service provider application hosted by a service provider platform (e.g., a member platform of a service provider for a particular exchange, etc.) to facilitate the functions of the service provider. The service provider application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the service provider. For example, the service provider application may be configured to present one or more user interfaces for interacting (e.g., commenting, managing, auditing, registering, etc.) with one or more service provider tools provided by the service provider. For example, in a financial value system, the service provider application may enable access to bank accounts, brokerage accounts, lines of credit, etc. to manage funds, assets, etc. processed by the corresponding accounts. In some examples, the service provider application may be configured to receive user input (e.g., via one or more user interfaces) to receive information, authorization, etc. from the user.

[0092] In some embodiments, the term "tool data object" refers to a data entity representing a service provider tool. The tool data object may include one or more tool identifiers and / or one or more tool attributes. In some examples, one or more tool identifiers and / or one or more tool attributes may be at least partially based on the type of the tool data object. For example, a service provider tool may be represented as a member tool data object in a member platform. Additionally or alternatively, the service provider tool may be independently represented by a system tool data object in an exchange platform. In some examples, the member tool data object and the system tool data object may include one or more of the same one or more tool identifiers and / or one or more tool attributes. For example, a member platform may register multiple service provider tools in an exchange platform. During the registration process, the member platform may provide one or more of the tool identifiers and / or tool attributes, and in some examples, the exchange platform may return another identifier.

[0093] In some embodiments, the member tool data object is an internal representation of a service provider tool within a member platform. The member tool data object can include one or more tool identifiers (e.g., member tool identifiers), a tool key from an exchange platform, and / or a user identifier. For example, the user identifier can include a member user identifier. Additionally or alternatively, the member tool data object can include one or more tool attributes such as tool type (e.g., credit-based tool, debit-based tool, information-based tool, etc.), tool representation, and / or one or more context attributes. In some examples, the context attributes may depend on the value system. For example, in a financial value system, one or more context attributes can indicate (i) the currency associated with the service provider tool, (ii) the asset availability of the service provider tool (e.g., balance, coverage, etc.), (iii) one or more previous transactions using the service provider tool, etc.

[0094] In some embodiments, the system tool data object is an external representation of a service provider tool within an exchange platform. The system tool data object can include one or more tool identifiers such as a tool reference for a member platform, a system tool identifier, and / or a user identifier. For example, the user identifier can include a system user identifier. Additionally or alternatively, the system tool data object can include one or more tool attributes such as tool type (e.g., credit-based tool, debit-based tool, information-based tool, etc.), tool representation, and / or one or more context attributes. In some examples, the context attributes may depend on the value system. For example, in a financial value system, one or more context attributes can indicate the currency associated with the service provider tool.

[0095] In some embodiments, the term "tool identifier" refers to any representation of a service provider tool. The tool identifier can include a tool identifier, a tool reference, a tool key, etc., as described herein.

[0096] In some embodiments, the term "member tool identifier" refers to a unique identifier used to represent a service provider tool within a member platform. For example, the member tool identifier can include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols that represents the service provider tool to the service provider platform.

[0097] In some embodiments, the term "tool reference" refers to a unique identifier used to reference a member tool identifier. For example, the tool reference can be generated by and / or provided by a member platform to an exchange platform to allow the exchange platform to reference a tool maintained at the member platform. In some examples, the tool reference is the same value as the member tool identifier. In some examples, the tool reference is a different value that maps to the member tool identifier.

[0098] In some embodiments, the term "system tool identifier" refers to a unique identifier used to represent a service provider tool within an exchange platform. For example, a system tool identifier can include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols that represents a service provider tool to the exchange platform. In some examples, a system tool identifier can include a UUID.

[0099] In some embodiments, the term "tool key" refers to a unique identifier used to reference a system tool identifier. For example, a tool key can be generated and / or provided by the exchange platform during the process of registering a tool with the exchange platform. In some examples, a tool key can include an encapsulated system tool identifier. For example, a tool key can include an alphanumeric string formatted according to a key format established by the exchange platform (and / or one or more of its APIs). The key format can include any number of characters, such as fifty characters or more. In some examples, the characters may be case-sensitive. The first part of the characters (e.g., the first six characters) can be reserved as a partition for identifying the entity associated with the key. For a tool key, the partition can include a service provider partition. The second part of the characters can identify the system tool identifier. The key format described herein can include one or more different parts, and each of the one or more different parts can be arranged in any order.

[0100] In some embodiments, the term "tool representation" refers to a unique identifier used to represent a service provider tool to a user. For example, a tool representation can include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols that visually represents a service provider tool. The format and / or value of a tool representation can be at least partially based on the type of service provider and / or service provider tool. For example, in a financial value system, a tool reference can include a part of a persistent credential (e.g., the last four digits, etc.), such as an account number (e.g., a debit account, a credit account, etc.), a financial account name, etc. As another example, in an information value system, a tool reference can include a part of a persistent credential (e.g., one or more digits, alphanumeric characters, etc.), such as a subscription account, etc. For example, a tool representation can include a derivative of a persistent credential that only allows an entity with prior knowledge of the persistent credential to use the tool representation to identify the persistent credential. As another example, a tool representation can include a tool alias that is specified and subsequently recognized by a user.

[0101] In some embodiments, the term "user data object" refers to a data entity that represents a user interacting with a member platform and / or an exchange platform. For example, a user may include an entity participating in a value exchange managed by an exchange platform (e.g., an individual, an organization, a group, etc.). In some examples, a user may indirectly cooperate with an exchange platform by creating a user account with a registered service provider, registering (and / or allowing registration of) service provider tools, etc. In some examples, an exchange platform may operate on behalf of a user without the user directly contacting the exchange platform. For example, an exchange platform may act as a hidden intermediary between a user-facing application and a user's service provider tools.

[0102] In some embodiments, a user data object includes one or more user identifiers and / or one or more user attributes. In some examples, one or more user identifiers and / or one or more user attributes may be at least partially based on the type of the user data object. For example, a user may be represented as a member user data object in a member platform. Additionally or alternatively, a user may be independently represented by a system user data object in an exchange platform. In some examples, a member user data object and a system user data object may include one or more of the same one or more user identifiers and / or user attributes. For example, a member platform may register multiple users with an exchange platform. During the registration process, the member platform may provide one or more of the user identifiers and / or user attributes, and in some examples, the exchange platform may return another identifier.

[0103] In some embodiments, a member user data object is an internal representation of a user within a member platform. A member user data object may include one or more user identifiers, such as a member user identifier, a user key from an exchange platform, etc. Additionally or alternatively, a member user data object may include one or more user attributes. One or more user attributes may indicate one or more context characteristics of the user. In some examples, a user attribute may indicate one or more identifiable characteristics of the user. For example, a user attribute may indicate the user's first name, last name, email, physical address (e.g., one or more of street, location, region, postal code, country, etc.), birthday (e.g., date of birth, age range, etc.), phone number, etc. In some examples, a user attribute may include an encrypted representation, a hash representation, and / or otherwise a securely protected representation of an identifiable characteristic of the user. For example, a user attribute may include one or more hash identifiers of the user.

[0104] In some embodiments, user attributes may indicate a user's age. For example, user attributes may indicate a user's birthday. Additionally or alternatively, user attributes may indicate an age range. An age range may indicate a user's age category. For example, an age category may indicate an age range customized for one or more acquisition restrictions. For example, in the United States, age ranges may include (i) a minor age range, which indicates users under 18 years old, (ii) a first partial minor age range, which indicates users 18 years old or older but under 19 years old, (iii) a second partial minor age range, which indicates users 19 years old or older but under 21 years old, and (iv) an unrestricted age range, which indicates users over 21 years old. In this way, user attributes can reflect age-related information of the user without exposing sensitive user information such as the user's date of birth.

[0105] In some embodiments, a system user data object is an external representation of a user who is a member within an exchange platform. The system user data object may include one or more user identifiers, such as a user reference for a member platform, a system user identifier, etc. Additionally or alternatively, the system user data object may include one or more user attributes, such as those described herein. For example, a member platform may register a user with the exchange platform. During the registration process, the member platform may provide a user reference for the user and / or one or more user attributes. In some examples, user attributes may include a user's hashed identifier and / or encrypted identifier.

[0106] In some embodiments, the term "user identifier" refers to a unique identifier of a user involved in a value-based exchange. A user identifier may include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols representing a user of an exchange platform and / or a member platform. In some examples, a user identifier may include a user reference, a user key, a system user identifier, a member user identifier, etc.

[0107] In some embodiments, the term "system user identifier" refers to a unique identifier used to represent a user within an exchange platform. For example, a system user identifier may include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols representing a user to the exchange platform. In some examples, a system user identifier may include a UUID specific to a certain user.

[0108] In some embodiments, the term "member user identifier" refers to a unique identifier used to represent a user within a member platform. For example, a member user identifier may include a sequence of digits, an alphanumeric sequence, any / and or any other sequence of characters or symbols representing a user to a service provider platform.

[0109] In some embodiments, the term "user reference" refers to a unique identifier used to reference a member user identifier. For example, a user reference can be generated by a member platform and / or provided by a member platform to an exchange platform to allow the exchange platform to reference a user associated with the member platform. In some examples, the user reference is the same value as the member user identifier. In some examples, the user reference is a different value that maps to the member user identifier.

[0110] In some embodiments, the term "user key" refers to a unique identifier used to reference a system user identifier. For example, a user key can be generated and / or provided by an exchange platform during the process of registering a user with the exchange platform. In some examples, the user key can include an encapsulated system user identifier. For example, the user key can include an alphanumeric string formatted according to a key format established by the exchange platform (and / or one or more of its APIs). For example, the key format can include a first portion of characters (e.g., the first six characters), which can be reserved as a partition for identifying an entity associated with the key (e.g., a member, etc.). For example, for a user key, the partition can include a service provider partition and / or a partner partition. A second portion of the characters can identify the system user identifier.

[0111] In some embodiments, the term "exchange data object" refers to a data entity representing an authorized value exchange between one or more members associated with an exchange platform. In some examples, the exchange data object can include one or more identifiers and / or one or more exchange attributes. For example, the one or more identifiers and / or the one or more exchange attributes can be at least partially based on the type of the exchange data object. For example, the exchange can be represented as a member exchange data object in a member platform. Additionally or alternatively, the exchange can be independently represented by a system exchange data object in the exchange platform. In some examples, the member exchange data object and the system exchange data object can include one or more of the same one or more identifiers and / or exchange attributes. For example, using some techniques of the present disclosure, an exchange platform can publish one or more unique identifiers to a member platform, and the one or more unique identifiers can be used to authorize a value exchange.

[0112] In some embodiments, the system exchange data object is an internal representation of a value exchange using the exchange platform as a mediator. In some examples, depending on the role of the system exchange data object in a value-based exchange, the system exchange data object can include one or more different identifiers and / or exchange attributes.

[0113] For example, system exchange data objects can include service-provider-specific exchange data objects corresponding to a service provider platform. The service-provider-specific exchange data objects can include one or more identifiers, such as an exchange identifier, a system user identifier, a system tool identifier, a UUEK, etc. Additionally or alternatively, the service-provider-specific exchange data objects can include one or more exchange attributes, such as a deadline, a currency (e.g., a currency for a financial value system, etc.).

[0114] Additionally or alternatively, system exchange data objects can include partner-specific exchange data objects corresponding to a partner platform. The partner-specific exchange data objects can include one or more identifiers, such as an exchange identifier, a tool key, a UUEK, a member tool reference (e.g., a partner-specific tool reference, etc.). Additionally or alternatively, the partner-specific exchange data objects can include one or more exchange attributes, such as a deadline, a currency (e.g., a currency for a financial value system, etc.), a tool type, a previous UUEK identifier, etc. In some embodiments, member exchange data objects are an external representation of a value exchange that uses an exchange platform as an intermediary. Member exchange data objects can include one or more identifiers, such as a member exchange identifier, a member tool identifier, a UUEK from the exchange platform, etc.

[0115] In some embodiments, the term "exchange identifier" refers to a unique identifier for a value exchange that uses an exchange platform. The exchange identifier can include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that at least represents a user and / or a service provider tool. In some examples, the unique exchange identifier can include a Universally Unique Identifier (UUID), which can be mapped (e.g., through a series of identifiers, etc.) to a user, a service provider tool, and / or a member registered with the exchange platform. In some examples, one or more UUID generators can be used to randomly generate the exchange identifier. For example, the exchange identifier can include a random sixteen-byte information generated according to one or more UUID formatting standards (such as UUID v4, etc.). Thus, although the exchange identifier can be used by the exchange platform and / or a member platform for one or more functions, the same exchange identifier will be useless to an external party in the absence of a priori association between the exchange identifier and one or more other identifiers. In some examples, the exchange identifier can be externally represented by a UUEK.

[0116] In some embodiments, "Universal Unique Ephemeral Key" or "UUEK" refers to an external representation of an exchange identifier that can be published (e.g., in lieu of a service provider exchange identifier and / or a partner exchange identifier) to an external entity (e.g., a user, a partner, and / or a service provider) to initiate a transaction using an exchange platform. To this end, a UUEK can be generated by the exchange platform and published to the external entity. Each UUEK can include a plurality of values (e.g., up to fifty and / or more case-sensitive characters) representing one or more aspects of the transaction. For example, the plurality of values can indicate an exchange identifier, a partition (e.g., identifying the recipient of the UUEK, etc.), an identifier type, and / or one or more flags. For example, a UUEK can include a partner-specific UUEK and / or a service-provider-specific UUEK. A partner-specific UUEK can be associated with a partner-specific exchange data object, and a service-provider-specific UUEK can be associated with a service-provider-specific exchange data object, as described herein.

[0117] For example, a UUEK can be generated according to a key format. The key format can include a plurality of characters, including, for example, fifty or more case-sensitive characters. A first portion of the characters (e.g., the first six characters) can be reserved as a partition for identifying the recipient of the UUEK. For example, the partition can include a partner partition, a service-provider partition, and / or any other member partition. For example, a UUEK can be published in response to a request from an authorized member (e.g., an affiliated partner and / or a service provider).

[0118] Additionally or alternatively, at least one character of the key format (e.g., the seventh character) can identify the format of the UUEK. At least one additional character (e.g., the eighth character) can identify the type of the UUEK. In some examples, a second portion of the characters can identify the exchange identifier (e.g., a set of twenty-two characters after the eighth character). A third portion of the characters (e.g., a set of twenty characters after the first portion of the characters) can be reserved. An example representation is given below:

[0119] ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr

[0120] Wherein, p represents a partition character, F represents a format character, i represents an identifier type character, G represents an exchange identifier, and r represents a reserved character. The key format allows for 9.8×10^84 unique permutations, which is more than the number of atoms in the known observable universe. This enables the generation and distribution of new UUEKs on demand without compromising the security of the underlying data (e.g., user identifiers, tool identifiers, and / or any other potentially sensitive information) to which the UUEKs may be mapped. The key format described herein may include one or more different parts, and each of the one or more different parts may be arranged in any order.

[0121] In some embodiments, the term "session identifier" refers to a unique identifier used to identify a series of related message exchanges between an exchange platform and an external platform.

[0122] In some embodiments, the term "matching code" refers to a session-unique identifier used to authorize an enrollment session between one or more entities. For example, the matching code may include a sequence of digits, alphanumeric, and / or similar characters that can be provided to multiple entities to ensure that each of the entities is included in the same communication sequence. For example, the matching code may include an eight-character sequence that can be generated by the exchange platform, provided to the service provider platform, and then received from the partner platform to ensure that the exchange platform, the service provider platform, and the partner platform are all interacting with the same end user (e.g., by comparing the received matching code with the generated matching code as described herein). III. Computer Program Products, Methods, and Computing Entities

[0123] The embodiments in the present disclosure can be implemented in various ways, including being implemented as a computer program product including a manufactured article. Such a computer program product may include one or more software components, and the one or more software components include, for example, software objects, methods, data structures, etc. The software components can be encoded in any one of a variety of programming languages in China. Illustrative programming languages can be low-level program programming languages, such as assembly languages associated with specific hardware architectures and / or operating system platforms. Software components containing assembly language instructions may require conversion to executable machine code by an assembler before being executed by the hardware architecture and / or platform. Another example programming language can be a high-level programming language that can be ported across multiple architectures. Software components containing high-level programming language instructions may require conversion to an intermediate representation by an interpreter or compiler before execution.

[0124] Other examples of programming languages include, but are not limited to: macro languages, shell or command languages, job control languages, scripting languages, database query or search languages, and / or report writing languages. In one or more example embodiments, a software component that includes instructions in one of the foregoing programming language examples may be executed directly by an operating system or other software component without having to be first converted into another form. The software component may be stored as a file or other data storage construct. Software components of a similar type or related functionality may be stored together, for example, in a specific directory, folder, or library. The software component may be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified at execution time).

[0125] A computer program product may include a non-transitory computer-readable storage medium storing an application, program, program module, script, source code, program code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, instructions for execution, computer program product, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0126] In one embodiment, the non-volatile computer-readable storage medium may include floppy disks, flexible disks, hard disks, solid state memories (SSS) (e.g., solid state drives (SSD), solid state cards (SSC), solid state modules (SSM)), enterprise flash drives, magnetic tapes, or any other non-transitory magnetic media, etc. The non-volatile computer-readable storage medium may also include punched cards, paper tapes, optical mark sheets (or any other physical media having hole patterns or other optically recognizable marks), compact discs read-only (CD-ROM), compact discs rewritable (CD-RW), digital versatile discs (DVD), Blu-ray discs (BD), any other non-transitory optical media, etc. Such non-volatile computer-readable storage medium may also include read-only memories (ROM), programmable read-only memories (PROM), erasable programmable read-only memories (EPROM), electrically erasable programmable read-only memories (EEPROM), flash memories (such as serial, NAND, NOR, etc.), multimedia memory cards (MMC), secure digital (SD) memory cards, smart media cards, compact flash (CF) cards, memory sticks, etc. In addition, the non-volatile computer-readable storage medium may also include conductive-bridging random access memory (CBRAM), phase change random access memory (PRAM), ferroelectric random access memory (FeRAM), non-volatile random access memory (NVRAM), magnetoresistive random access memory (MRAM), resistive random access memory (RRAM), silicon-oxide-nitride-oxide-silicon memory (SONOS), floating junction gate random access memory (FJG RAM), millipede memory, racetrack memory, etc.

[0127] In one embodiment, the volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type double synchronous dynamic random access memory (DDR2 SDRAM), double data rate type triple synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), two-transistor RAM (TTRAM), thyristor RAM (T-RAM), zero-capacitor (Z-RAM), Rambus in-line memory module (RIMM), dual in-line memory module (DIMM), single in-line memory module (SIMM), video random access memory (VRAM), cache memory (including all levels), flash memory, register memory, and the like. It should be noted that when an embodiment is described as using a computer-readable storage medium, the above computer-readable storage medium may be replaced by other types of computer-readable storage media, or other types of computer-readable storage media may be used in addition to the above computer-readable storage media.

[0128] It should be noted that the various embodiments of the present disclosure may also be implemented as a method, apparatus, system, computing device, computing entity, etc. Therefore, the embodiments of the present disclosure may take the form of a data structure, apparatus, system, computing device, computing entity, etc. to execute instructions stored on a computer-readable storage medium to perform certain steps or operations. Therefore, the embodiments of the present disclosure may also take the form of a complete hardware embodiment, a complete computer program product embodiment, and / or a combination including a computer program product and hardware to perform certain steps or operations.

[0129] Embodiments of the present disclosure will be described below with reference to block diagrams, flowcharts, message passing flows, and other representations of data, operations, and message passing schemes. It should be understood that each block, such as a module, arrow, etc. in the schematic diagram, flowchart, etc. can be implemented in the form of a computer program product, a fully hardware embodiment, a combination of hardware and a computer program product, and / or a device, system, computing device, computing entity, etc. that executes instructions, operations, steps, and similar terms used interchangeably (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium. For example, the code can be retrieved, loaded, and executed sequentially such that only one instruction is retrieved, loaded, and executed at a time. In some example embodiments, the retrieval, loading, and / or execution can be performed in parallel such that multiple instructions are retrieved, loaded, and / or executed together. Thus, such embodiments can produce a machine that executes a specific configuration of steps or operations specified in the representation of the present disclosure. Accordingly, the representations of the present disclosure support various combinations of embodiments for executing the specified instructions, operations, or steps.

[0130] IV. Example System Architecture

[0131] Figure 1 A schematic diagram of a computing ecosystem 100 that can be used in conjunction with various embodiments of the present disclosure is provided. As Figure 1 shown, the architecture can include a switching platform 102, one or more client devices 104, a member platform network 110, one or more networks 120, etc. The member platform network 110 can include a first member platform 112a, a second member platform 112b, a third member platform 112c, etc. that are attached to the switching platform 102 (e.g., registered on the switching platform, etc.). For example, as described herein, the member platform network 110 can include a partner platform and / or a service provider platform. In some examples, the partner platform can include the first member platform 112a, and the service provider platform can include a second member platform 112b that is different from the first member platform 112a. In some examples, the partner platform and / or the service provider platform can include a single member platform (e.g., the third member platform 112c). In some examples, the member platform network 110 can be configured for one or more different services.

[0132] Each component of the computing ecosystem 100 can communicate electronically with, for example, another component via the same or different wireless or wired networks 120 (including, for example, wired or wireless personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), etc.). For example, the network 120 can include any network connection, and the network connection includes any type of network and / or spans any geographical boundary (e.g., an inter-country connection involving one or more sovereign entities, etc.). Additionally, although Figure 1Certain systems are shown as separate, independent entities, but the various embodiments are not limited to this particular architecture.

[0133] Although not explicitly stated, the exchange platform 102 can be part of the client device 104 and / or the member platform network 110. Additionally or alternatively, the member platforms 112a-c can be part of the client device 104 and / or the exchange platform 102. In some embodiments, each of the exchange platform 102 and / or the member platforms 112a-c can include the same computing platform.

[0134] a. Example computing platform

[0135] Figure 2 is an example schematic diagram of a computing platform 200 according to one or more embodiments of the present disclosure. The computing platform 200 (e.g., the exchange platform 102, the member platforms 112a-112c, and / or Figure 1 similar platforms therein) can include one or more processing elements 202 (also referred to as processors, processing circuits, and / or similar terms used interchangeably herein) or communicate with one or more processing elements 202, which communicate with other elements within the computing platform 200 via a bus, for example. It will be understood that the processing element 202 can be implemented in many different ways.

[0136] For example, the processing element 202 can be implemented as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, co-processing entities, application-specific instruction set processors (ASIPs), microcontrollers, and / or controllers. Additionally, the processing element 202 can be implemented as one or more other processing devices or circuits. The term circuit can refer to a fully hardware embodiment or a combination of hardware and a computer program product. Thus, the processing element 202 can be implemented as an integrated circuit, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a programmable logic array (PLA), a hardware accelerator, other circuits, etc.

[0137] Therefore, it will be understood that the processing element 202 can be configured for a specific purpose or can be configured to execute instructions stored in a volatile medium or a non-volatile medium or otherwise accessible by the processing element 202. Thus, whether configured by hardware or a computer program product, or by a combination thereof, when the processing element 202 is configured accordingly, the processing element 202 is capable of performing steps or operations according to the embodiments of the present disclosure.

[0138] In some embodiments, computing platform 200 includes a non-volatile memory 204 (also referred to as a non-volatile storage device, medium, memory, memory circuit, and / or similar terms that may be used interchangeably herein), or communicates with the non-volatile memory 204. In some examples, the non-volatile memory 204 may include one or more non-volatile storage devices or storage media, including but not limited to hard disks, ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory cards, memory sticks, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, and the like.

[0139] It will be appreciated that the non-volatile storage 204 is capable of storing data, databases, database instances, database management systems, files, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, and the like. The terms database, database instance, database management system, and / or similar terms that may be used interchangeably herein may refer to a collection of records or data stored in a computer-readable storage medium using one or more database models (e.g., hierarchical database model, network model, relational model, entity-relationship model, object model, document model, semantic model, graph model, etc.).

[0140] In some embodiments, computing platform 200 includes a volatile memory 206 (also referred to as a volatile storage device, medium, memory, memory circuit, and / or similar terms that may be used interchangeably herein), or communicates with the volatile memory 206. In some examples, the volatile memory 206 may also include one or more volatile storage devices or storage media, including but not limited to RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, caches, register memories, and the like.

[0141] It will be appreciated that the volatile memory 206 can be used to store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. being executed by, for example, the processing element 202. Thus, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. can be used to control steps / operations of certain aspects of the computing platform 200 with the assistance of the processing element 202 and the operating system.

[0142] As shown, in one embodiment, the computing platform 200 may further include one or more network interfaces 208 for communicating with various computing entities (e.g., Figure 1 one or more components thereof), for example, by transmitting data, content, information, and / or similar terms that may be used interchangeably herein, which can be sent, received, manipulated, processed, displayed, stored, etc. Such communication can be performed using wired data transmission protocols, such as using Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, Data Over Cable Service Interface Specification (DOCSIS), or any other wired transmission protocol. Similarly, the computing platform 200 can be configured to communicate via a wireless external communication network using any one of various protocols, such as General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), Time Division - Synchronous Code Division Multiple Access (TD - SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E - UTRAN), Evolution - Data Optimized (EVDO), High - Speed Packet Access (HSPA), High - Speed Downlink Packet Access (HSDPA), IEEE 802.11 (Wi - Fi), Wi - Fi Direct, 802.16 (WiMAX), Ultra - Wideband (UWB), Infrared (IR) protocol, Near - Field Communication (NFC) protocol, Wibree, Bluetooth protocol, Wireless Universal Serial Bus (USB) protocol, and / or any other wireless protocol.

[0143] Although not shown, computing platform 200 may include or communicate with one or more input elements, such as keyboard input, mouse input, touchscreen / display input, motion input, mobile input, audio input, pointing device input, joystick input, keypad input, etc. Computing platform 200 may also include or communicate with one or more output elements (not shown), such as audio output, video output, screen / display output, motion output, mobile output, etc.

[0144] As shown, computing platform 200 may be Figure 1 an example of one or more of the components in, such as switching platform 102 and / or member platforms 112a-c.

[0145] b. Example Client Devices

[0146] Figure 3 FIG. is an example schematic diagram of client device 104 according to one or more embodiments of the present disclosure. Client device 104 may be operated by various entities, and an example computing ecosystem may include one or more client devices 104. For example, client device 104 may be associated with, owned by, operated by, etc., one or more end users. In various embodiments, the end users of client device 104 may wish to participate in a value exchange between a partner and a service provider. As described herein, a user may participate in the value exchange between the partner and the service provider by interacting with client device 104 by utilizing one or more functions provided by the switching platform via user input.

[0147] For example, client device 104 may be a personal computing device, a smart phone, a tablet computer, a laptop computer, a personal digital assistant, etc. In various embodiments, computing platform 200 may communicate with one or more client devices 104 and manage the value exchange for one or more client devices 104. As Figure 3 shown, client device 104 may include antenna 312, transmitter 304 (e.g., a radio transmitter), receiver 306 (e.g., a radio receiver), and processing element 308 (e.g., CPLD, microprocessor, multi-core processor, co-processing entity, ASIP, microcontroller, and / or controller) that provides signals to and receives signals from transmitter 304 and receiver 306, respectively.

[0148] Signals provided to and received from transmitter 304 and receiver 306, respectively, may include signaling information / data in accordance with the air interface standards of the applicable wireless system. In this regard, client device 104 may be capable of operating using one or more air interface standards, communication protocols, modulation types, and access types. More specifically, client device 104 may operate in accordance with any of a variety of wireless communication standards and protocols (e.g., those described above with respect to computing platform 200). In a particular embodiment, client device 104 may operate in accordance with multiple wireless communication standards and protocols, such as UMTS, CDMA2000, 1xRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, etc. Similarly, client device 104 may operate via network interface 320 in accordance with a variety of wired communication standards and protocols (e.g., those described above with respect to computing platform 200).

[0149] Via these communication standards and protocols, client device 104 may communicate with computing platform 200 using concepts such as Unstructured Supplementary Service Data (USSD), Short Message Service (SMS), Multimedia Messaging Service (MMS), Dual Tone Multi-Frequency signaling (DTMF), and / or Subscriber Identity Module dialer (SIM dialer). For example, client device 104 is also capable of downloading changes, add-ons, and updates to firmware, software (e.g., including executable instructions, applications, program modules), and the operating system.

[0150] In some embodiments, client device 104 includes aspects of location determination, devices, modules, functions, and / or similar terms that may be used interchangeably herein. For example, client device 104 may include aspects of outdoor positioning, such as a positioning module adapted to obtain, for example, latitude, longitude, altitude, geocoding, routes, directions, headings, speeds, Coordinated Universal Time (UTC), dates, and / or various other information / data. In one embodiment, the location module may obtain data, sometimes referred to as ephemeris data, by identifying the number of satellites in view and the relative positions of those satellites (e.g., using the Global Positioning System (GPS)). These satellites may be a variety of different satellites, including low Earth orbit (LEO) satellite systems, Department of Defense (DOD) satellite systems, the European Union's Galileo positioning system, China's BeiDou Navigation Satellite System, India's Regional Navigation Satellite System, and the like. This data may be collected using a variety of coordinate systems, such as decimal degrees (DD); degrees, minutes, seconds (DMS); Universal Transverse Mercator (UTM); Universal Polar Stereographic (UPS) coordinate systems, and the like. Alternatively, location information / data may be determined by triangulating the position of client device 104 in combination with a variety of other systems, including cellular towers, Wi-Fi access points, and the like. Similarly, client device 104 may include aspects of indoor positioning, such as a positioning module adapted to obtain, for example, latitude, longitude, altitude, geocoding, routes, directions, headings, speeds, time, dates, and / or various other information / data. Some indoor systems may use a variety of location or positioning technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cellular towers, nearby computing devices (e.g., smartphones, laptops), and the like. For example, these technologies may include iBeacons, Gimbal proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, and the like. These aspects of indoor positioning may be used in a variety of settings to determine the location of a person or thing within inches or centimeters of accuracy.

[0151] In some embodiments, the client device 104 may include a user interface 316 (e.g., a display screen, a speaker, a haptic mechanism, etc. coupled to the processing element 308) and / or a user input interface 318 (e.g., a touch screen, a microphone, etc. coupled to the processing element 308). For example, the user interface 316 may be one or more application screens presented by one or more of the computing platforms described herein. The user input interface 318 may include any of a plurality of devices or interfaces that allow the client device 104 to receive data, such as a keyboard (hard keyboard or soft keyboard), a touch display, a voice / speech or gesture interface, or other input devices. In an example including a keyboard, the keyboard may include (or cause to be displayed) conventional digits (0-9) and associated keys (#, *), as well as other keys for operating the client device 104, and may include a full set of alphanumeric keys or a set of keys that can be activated to provide a full set of alphanumeric keys. In addition to providing input, the user input interface may also be used, for example, to activate or deactivate certain functions (such as a screen saver and / or a sleep mode).

[0152] The client device 104 may also include volatile memory 322 and / or non-volatile memory 324, which may be embedded and / or removable. For example, the non-volatile memory 324 may be ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory card, memory stick, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJGRAM, Millipede memory, racetrack memory, etc. The volatile memory 322 may be RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache, register memory, etc. The volatile and non-volatile storage devices or memories may store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, and / or executable instructions, etc. to implement the functions of the client device 104. As indicated, this may include partner applications, service provider applications, etc., which reside on the client device 104 and / or may be accessible via a browser or other user interface for communicating with the computing platform 200.

[0153] In some embodiments, client device 104 may include one or more components or functions that are the same as or similar to those of computing platform 200 described in more detail above. It will be recognized that these architectures and descriptions are provided for example purposes only and are not limiting to the various embodiments.

[0154] In various embodiments, client device 104 may be implemented as an artificial intelligence (AI) computing entity, such as an Amazon Echo, Amazon Echo Dot, Amazon Show, Google Home, etc. Accordingly, client device 104 may be configured to provide and / or receive information / data from an end user via input / output mechanisms (such as a display, camera, speaker, voice-activated input, etc.). In certain embodiments, the AI computing entity may include one or more predefined and executable program algorithms stored in an on-board memory storage module and / or accessible via a network. In various embodiments, the AI computing entity may be configured to retrieve and / or execute one or more predefined program algorithms when a predefined trigger event occurs.

[0155] c. Example Networks

[0156] In some embodiments, Figure 1 any two or more of the illustrative components of computing ecosystem 100 may be configured to communicate with each other via respective communication couplings to one or more networks 120. Networks 120 may include, but are not limited to, any one or combination of different types of suitable communication networks, e.g., the communication networks are wired networks, public networks (such as the Internet), private networks (such as frame relay networks), wireless networks, cellular networks, telephone networks (such as the public switched telephone network), or any other suitable private and / or public network. Additionally, networks 120 may have any suitable communication range associated therewith and may include, for example, global networks (such as the Internet), MAN, WAN, LAN, or PAN. Further, networks 120 may include any type of medium over which network traffic may be carried, which includes but is not limited to coaxial cable, twisted pair, fiber optic, hybrid fiber coaxial (HFC) medium, microwave terrestrial transceivers, radio frequency communication medium, satellite communication medium, or any combination thereof, as well as various network devices and computing platforms provided by network providers or other entities.

[0157] d. Example Value Exchange Systems

[0158] Figure 4An example block diagram of an example of a network-based exchange system 400 according to one or more embodiments of the present disclosure. The network-based exchange system 400 includes a new computing ecosystem and computing platform that provides an end-to-end value exchange solution to replace traditional exchange processing systems. As described herein, the network-based exchange system 400 can be value-system agnostic and can be applied to any value-based exchange (including, for example, information-based exchanges, finance-based exchanges, reputation-based exchanges, healthcare-based exchanges, welfare-based exchanges, etc.). In any value system, the network-based exchange system 400 can utilize intermediary entities and one or more defined communication interfaces to facilitate network-based exchanges between value-seeking entities (e.g., partners) and value-providing entities (e.g., service providers), where the value-seeking entities and value-providing entities may be associated with one or more member platforms of the network-based exchange system 400.

[0159] As described above, the network-based exchange system 400 can include an exchange platform 102, a partner platform 420, and / or a service provider platform 440, all of which can be configured to communicate via one or more exchange interfaces. The partner platform 420 and / or the service provider platform 440 can include one or more member platforms 112a-c from a member platform network 110. For example, the partner platform 420 and the service provider platform 440 can include a single member platform (e.g., member platform 112c). Additionally or alternatively, the partner platform 420 and the service provider platform 440 can include one or more different member platforms (e.g., member platform 112a and member platform 112b). In some examples, a user can interact with one or more platforms via a client device 104.

[0160] In some embodiments, the exchange platform 102 is a computing entity configured to facilitate voucherless value exchanges for one or more members in a network. The exchange platform 102 can include one or more processing devices, storage devices, etc., that are physically and / or wirelessly coupled and configured to jointly (and / or separately) perform one or more computing tasks for facilitating exchanges that are value-system agnostic. In some examples, the exchange platform 102 can include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communication (e.g., requests, responses, etc.) between multiple members. As described herein, exchange interfaces can be utilized to facilitate secure exchanges between one or more members in any value system.

[0161] In some embodiments, a member is an entity that collaborates with the exchange platform 102 to participate in a value exchange. For example, a member can include (i) a partner that utilizes the exchange platform 102 to receive value, (ii) a service provider that utilizes the exchange platform 102 to provide value, and / or (iii) both a partner and a service provider. As used herein, when a member receives value through a value exchange, the member can be referred to as a partner, and / or when a member provides value through a value exchange, the member can be referred to as a service provider. Thus, depending on the role of the member in the value exchange, the same member can be a partner or a service provider. For example, a member can be a partner that receives value in a value exchange. The same member can be a service provider that provides value in another value exchange. In some examples, the same member can be both a partner and a service provider in the same value exchange, such that the member utilizes the exchange platform 102 to provide and then receive value in a single member value exchange.

[0162] In some embodiments, when a member utilizes a service provided by a service provider, the member is a partner. A partner can include any value-seeking entity in any value system. For example, in a financial value system, a partner can include merchants (e.g., retailers, physical enterprises, etc.), and the merchants can utilize a service provider (e.g., a financial institution) to obtain funds for financial transactions. Additionally or alternatively, in an information value system, a partner can include news publishers (e.g., newspapers, media organizations, etc.), and the news publishers can utilize a service provider (e.g., a news agency (e.g., a wire service, a news service, etc.)) to obtain information for information transactions. In a healthcare value system, a partner can include healthcare providers, and the healthcare providers can access healthcare benefit administrators to obtain healthcare benefits for financing medical procedures. It should be understood that the techniques of the present disclosure can be applied to any value system, and a partner can include value seekers in any corresponding value system.

[0163] In some embodiments, when a member provides services to a partner, that member is a service provider. A service provider can include a source of value in any value system. For example, in a financial value system, a service provider can include a financial institution (e.g., a bank, a currency exchange platform, a credit union, etc.) that can provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a service provider can include a news agency (e.g., a wire service, a news service, etc.) that can provide a source of information for the publication of a news publisher. In a healthcare value system, a service provider can include a healthcare benefits administrator that can provide access to healthcare benefits for a healthcare provider. It should be understood that the techniques of the present disclosure can be applied to any value system, and a service provider can include any source of value for any corresponding value system.

[0164] In some embodiments, a service provider tool is a mechanism utilized by a service provider to provide value on behalf of a particular user. Service provider tools can depend on the value system and / or the service provider. In some examples, a service provider tool can include an account opened at the service provider. For example, in a financial value system, a service provider tool can include a bank account (e.g., a checking, a savings, etc.), a brokerage account, a line of credit, etc. In an information value system, a service provider tool can include a subscription account, etc. In a healthcare value system, a service provider tool can include a healthcare benefits account, etc.

[0165] In some embodiments, the services provided by a service provider are subject to one or more policies. For example, a service provider can be associated with one or more member policies for verifying the use of service provider tools maintained by the service provider.

[0166] For example, a service provider and / or its service provider's service provider tools can be associated with an entity that manages the use of one or more services provided by the service provider. For example, a service provider can facilitate an Electronic Benefits Transfer (EBT) system that provides financial assistance for authorized food and household supplies, such as the Supplemental Nutrition Assistance Program (“SNAP”), Temporary Assistance for Needy Families (“TANF”), the Special Supplemental Nutrition Program for Women, Infants, and Children (“WIC”), etc. As another example, a service provider can promote a healthcare program on behalf of a healthcare provider that restricts benefits based on healthcare eligibility, procedure codes, procedure locations, etc.

[0167] Additionally or alternatively, a service provider may manage the use of its own services. For example, a service provider may maintain service provider tools for users of the service provider. The service provider may restrict the service provider tools on behalf of the user, on behalf of one or more internal policies, etc. For example, the service provider may include a financial institution that allows one or more users to restrict access to funds provided by the financial institution. In this way, a user may provide restricted access to the service provider tools by establishing one or more membership policies for the service provider tools.

[0168] The service provider and the partner may communicate through one or more respective membership platforms associated with the entities. For example, the service provider may be associated with a service provider platform 440, and the partner may be associated with a partner platform 420.

[0169] In some embodiments, the membership platform is a computing entity corresponding to a member associated with the exchange platform 102. The membership platform may include a partner platform 420 that operates on behalf of the partner, a service provider platform 440 that operates on behalf of the service provider, and / or both the partner platform 420 and the service provider platform 440. In some examples, the membership platform may be both a partner platform 420 and a service provider platform 440. For example, the same membership platform may be configured to operate on behalf of the partner for one value exchange and on behalf of the service provider for another value exchange. In some examples, the same membership platform may be configured to operate on behalf of both the partner and the service provider in a single value exchange. Note that the term membership platform may refer to a partner platform 420, a service provider platform 440, or both a partner platform and a service provider platform, and in some examples, the membership platform may depend on the role of the membership platform in the value exchange (e.g., and / or one or more interfaces used by the membership platform in the value exchange).

[0170] In some embodiments, the partner platform 420 is a computing entity configured to perform one or more operations on behalf of the partner. For example, the partner platform 420 may include one or more processing devices, storage devices, etc., that are physically coupled and / or wirelessly coupled and configured to jointly (and / or separately) perform one or more computing tasks for requesting value in an exchange independent of the value system. In some examples, the partner platform 420 may include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communication with the exchange platform 102 (e.g., requests, responses, etc.). In some examples, the partner platform 420 may be configured to host one or more user-facing applications for interacting with one or more users (e.g., partner applications, etc.).

[0171] A partner platform 420 (e.g., in a financial value system) can host an online marketplace for partners that allows users to interact (e.g., search, browse, purchase, return, etc.) with one or more products or services offered by the partners. In the case of purchasing a product, the partner platform 420 can cooperate with one or more service providers to obtain funds for the purchase. Traditionally, credit card numbers, account numbers, and / or other financial credentials that may expose the user to malicious parties have been used to facilitate obtaining funds from service providers. To address the cybersecurity and data privacy issues of traditional financial systems (and / or other value-based systems), the partner platform 420 can register on the exchange platform 102 by configuring one or more software development kits (SDKs), APIs, etc., in order to communicate with the exchange platform 102. For example, the partner platform 420 can include, define, and / or otherwise utilize one or more partner interfaces 402 to facilitate communication (e.g., requests, responses, etc.) with the exchange platform 102.

[0172] In some embodiments, the service provider platform 440 is a computing entity configured to perform one or more operations on behalf of a service provider. For example, the service provider platform 440 can include one or more processing devices, storage devices, etc., that are physically and / or wirelessly coupled and configured to jointly (and / or separately) perform one or more computing tasks for providing value in an exchange independent of the value system. In some examples, the service provider platform 440 can include, implement, and / or otherwise utilize one or more interfaces to facilitate communication (e.g., requests and responses, etc.) with the exchange platform 102. In some examples, the service provider platform 440 can be configured to facilitate one or more service provider tools. In some examples, the service provider platform 440 can be configured to host one or more user-facing applications (e.g., service provider applications, etc.) for managing one or more service provider tools.

[0173] In some examples, a service provider platform 440 (e.g., in a financial value system) can maintain one or more financial assets (e.g., lines of credit, bank accounts, etc.) that allow a user to fund an exchange for purchasing products from a partner. In the case of purchasing a product, the service provider platform 440 can cooperate with the partner platform 420 to authorize the exchange and / or otherwise provide access to funds for the purchase. Traditionally, obtaining funds from a service provider has been facilitated by providing the service provider platform 440 with card numbers, account numbers, and / or other financial credentials that may expose the user, service provider, or partner to malicious parties (especially when provided over an insecure network (e.g., a public network, etc.)). To address the cybersecurity and data privacy issues of traditional financial systems (and / or other value-based systems), the service provider platform 440 can register on the exchange platform 102 by configuring one or more software development kits (SDKs), application programming interfaces (APIs), etc., in order to communicate with the exchange platform 102. For example, the service provider platform 440 can include, implement, and / or otherwise utilize one or more service provider interfaces 404 to facilitate communication (e.g., requests, responses, etc.) with the exchange platform 102.

[0174] As described herein, the service provider interface 404 can enable the exchange platform 102 to identify and request the use of service provider tools to facilitate a transaction. For example, the service provider platform 440 can be configured to facilitate one or more service provider tools. In some examples, the service provider tools can include virtual tools (e.g., virtual accounts, lines of credit, etc.) hosted by the service provider platform 440. For example, the service provider platform 440 can be configured to maintain, for a plurality of affiliated entities, a plurality of tool data objects indicating the plurality of service provider tools.

[0175] In some embodiments, a tool data object is a data entity representing a service provider tool. The tool data object can include one or more tool identifiers and / or one or more tool attributes. In some examples, the one or more tool identifiers and / or the one or more tool attributes can be at least partially based on the type of the tool data object. For example, a service provider tool can be represented as a member tool data object in a member platform (e.g., service provider platform 440). Additionally or alternatively, the service provider tool can be independently represented by a system tool data object in the exchange platform 102. In some examples, the member tool data object and the system tool data object can include one or more of the same one or more tool identifiers and / or one or more tool attributes. For example, a member platform can register multiple service provider tools on the exchange platform 102 (e.g., using the service provider interface 440). During the registration process, the member platform (e.g., service provider platform 440) can provide one or more of the tool identifiers and / or tool attributes, and in some examples, the exchange platform can return another identifier.

[0176] In some embodiments, a member tool data object is an internal representation of a service provider tool within a member platform (e.g., service provider platform 440). The member tool data object can include one or more tool identifiers (e.g., member tool identifiers), a tool key from the exchange platform 102, and / or a user identifier. For example, the user identifier can include a member user identifier as described herein. Additionally or alternatively, the member tool data object can include one or more tool attributes such as a tool type (e.g., credit-based tool, debit-based tool, information-based tool, etc.), a tool representation, and / or one or more context attributes. In some examples, the context attributes may depend on the value system. For example, in a financial value system, one or more context attributes can indicate (i) the currency associated with the service provider tool, (ii) the asset availability of the service provider tool (e.g., balance, coverage, etc.), (iii) one or more previous transactions using the service provider tool, etc.

[0177] In some embodiments, the system tool data object is an external representation of a service provider tool within the exchange platform 102. The system tool data object can include one or more tool identifiers such as tool references for member platforms, system tool identifiers, and / or user identifiers. For example, the user identifier can include a system user identifier as described herein. Additionally or alternatively, the system tool data object can include one or more tool attributes such as tool type (e.g., credit-based tool, debit-based tool, information-based tool, etc.), tool representation, and / or one or more context attributes. In some examples, the context attributes may depend on the value system. For example, in a financial value system, one or more context attributes can indicate the currency associated with the service provider tool.

[0178] In some examples, member platforms (e.g., partner platform 420 and / or service provider platform 440) can be associated with user-facing applications to facilitate one or more interactions with users and / or other affiliated entities (e.g., via client device 104).

[0179] In some embodiments, a user-facing application is a computer program hosted by a computing entity to facilitate one or more user interactions. The user-facing application can include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for a computing entity (e.g., a member platform). For example, the user-facing application can facilitate communication between a member and a user. For example, the user-facing application can be configured to present one or more user interfaces 406 (e.g., via client device 104) to interact with the user on behalf of the member. In some examples, the user-facing application can be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from the user.

[0180] In some embodiments, the user-facing application is a partner application 416 hosted by a partner platform (e.g., a member platform of a partner for a particular exchange, etc.) to facilitate the functions of the partner. The partner application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the partner. In some examples, the partner application 416 may be configured with one or more devices (e.g., point-of-sale terminals, etc.) from an independent partner institution (e.g., a physical bank, etc.). For example, the partner application 416 may be configured to present one or more user interfaces 406 for interacting (e.g., browsing, purchasing, reviewing, etc.) with one or more products provided by a retail-based partner, one or more information units provided by an information-based partner, etc. In some examples, the partner application 416 may be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from the user.

[0181] In some embodiments, the service provider platform 440 may be configured to host one or more service provider applications 418 to manage one or more service provider tools. For example, the user-facing application may be a service provider application 418 hosted by the service provider platform 440 (e.g., a member platform of a service provider for a particular exchange, etc.) to facilitate the functions of the service provider. In some examples, the service provider application 418 may be configured with one or more devices from an independent service provider institution (e.g., a physical bank, etc.). The service provider application 418 may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the service provider. For example, the service provider application 418 may be configured to present one or more user interfaces for interacting (e.g., reviewing, managing, auditing, registering, etc.) with one or more service provider tools provided by the service provider. For example, in a financial value system, the service provider application 418 may enable access to bank accounts, brokerage accounts, lines of credit, etc. to manage funds, assets, etc. processed by the respective accounts. In some examples, the service provider application 418 may be configured to receive user input (e.g., through one or more user interfaces 406) to receive information, authorization, etc. from the user.

[0182] In some embodiments, the exchange platform 102 uses one or more exchange interfaces to facilitate communication between the partner platform 420 and the service provider platform 440.

[0183] In some embodiments, the exchange interface is a set of instructions for facilitating communication between the exchange platform 102 and one or more member platforms and / or internal services. The exchange interface can include APIs, file-based interfaces, message queue-based interfaces, etc. For example, the exchange interface can include APIs, such as, the API includes one or more Simple Object Access Protocol (SOAP) APIs, one or more Remote Procedure Call (RPC) APIs, one or more WebSocket APIs, one or more Representational State Transfer (REST) APIs, etc. In some embodiments, the exchange interface can include one or more RPC APIs, such as one or more gRPC APIs.

[0184] The exchange platform 102 can include, define, and / or otherwise utilize one or more different exchange interfaces to facilitate communication with one or more external platforms (such as one or more member platforms (e.g., partner platform 420, service provider platform 440, etc.)). Each interface can include multiple communication instructions, message definitions, etc. for exchange requests and / or responses between the exchange platform 102 and entities participating in the value exchange. For example, the exchange interface can include a partner interface 402 for facilitating communication with the partner platform 420 and / or a service provider interface 404 for facilitating communication with the service provider platform 440.

[0185] In some embodiments, the partner interface 402 is an exchange interface for facilitating one or more communications between the partner platform 420 and the exchange platform 102. The partner interface 402 can define one or more communication instructions, message definitions, etc. for facilitating one or more request messages and / or response messages between the partner platform 420 and the exchange platform 102. For example, the partner interface 402 can include an API that defines (i) requests from a computing entity serving as the partner platform 420 to the exchange platform 102 and / or (ii) requests from the exchange platform 102 to the partner platform 420. For example, the partner interface 402 can define one or more registration messages, session messages, transaction messages, etc. for facilitating the value exchange of the partner. In some embodiments, the partner interface 402 defines one or more identifiers for securely identifying one or more parts of the value exchange.

[0186] In some embodiments, the service provider interface 404 is a switching interface for facilitating one or more communications between the service provider platform 440 and the switching platform 102. The service provider interface 440 may define one or more communication instructions, message definitions, etc. for facilitating one or more request messages and / or response messages between the service provider platform 440 and the switching platform 102. For example, the service provider interface 404 may include an API that defines (i) requests from a computing entity serving as the service provider platform 440 to the switching platform 102 and / or (ii) requests from the switching platform 102 to the service provider platform 440. For example, the service provider interface 404 may define one or more registration messages, session messages, transaction messages, etc. for facilitating value exchange using service provider tools. In some embodiments, the service provider interface 404 defines one or more identifiers for securely identifying one or more parts of the value exchange.

[0187] The switching platform 102 may facilitate communications between member platform networks. A member network may include, for example, multiple entities that have joined the switching platform 102, such as by registering on the switching platform 102 and configuring corresponding interfaces for communicating with the switching platform 102. In some examples, the switching platform 102 may perform one or more individual services to interact with each joined entity. For example, the individual services may include one or more partner services 410 and / or service provider services 412.

[0188] In some embodiments, the switching platform 102 instantiates a separate partner-specific service, i.e., the partner service 410, for each in the member network. Additionally or alternatively, for example, in a multi-tenant environment, the partner service 410 may be instantiated for one or more partners from the member network. The partner service 410 may be configured to perform one or more exchange operations to address exchange requests from the partner platform 420. In some embodiments, the switching platform 102 instantiates a separate service provider-specific service, i.e., the service provider service 412, for each in the member network. Additionally or alternatively, for example, in a multi-tenant environment, the service provider service 412 may be instantiated for one or more service providers from the member network. The service provider service 412 may be configured to perform one or more exchange operations to obtain and address exchange requests from the partner platform 420. The exchange operations may include any of the steps and / or operations described herein.

[0189] In some embodiments, the partner service 410 and / or the service provider service 412 interact with each other and / or with one or more other components of the exchange platform 102 through one or more local communication mechanisms to perform an exchange operation. For example, the exchange platform 102 may include an authentication service 408. The authentication service 408 may be configured to perform one or more authentication operations of the present disclosure to authenticate one or more objects of an exchange request. In this way, the exchange platform 102 may preprocess the objects of the exchange request on behalf of the member platform.

[0190] In some embodiments, the authentication service 408 is configured to identify and authenticate one or more restricted objects from an exchange request based at least in part on user attributes and / or an exchange location corresponding to the exchange request. In some examples, the authentication service 408 may identify and / or authenticate the restricted objects based at least in part on the record data object 422 and / or one or more acquisition restrictions 424.

[0191] In some embodiments, the record data object 422 is a data object representing an object that may be involved in a value-based exchange. In some examples, the record data object 422 may be an internal representation of an object of the exchange platform. For example, the object may include different units of a value-based exchange for which value is being transferred. The record data object 422 of the object may include a data object that records one or more aspects of the object (e.g., object identifier, object attributes, etc.).

[0192] For example, the record data object 422 may include an object identifier and / or one or more object attributes of a specific object associated with a value system. The object may be at least partially based on the value system. For example, in a financial value system, the object may be a tangible or intangible item, product, and / or the like that can be purchased with a monetary unit in an exchange. In a healthcare value system, the object may be a healthcare procedure and / or the like that can be covered by a healthcare policy.

[0193] In some examples, the exchange platform 102 may maintain and / or access a data store including a plurality of record data objects 422. As described herein, the object data store may include a plurality of record data objects 422 that are at least partially sourced from one or more members of the exchange network and / or one or more third parties. In some examples, the object data store may include at least a portion of the platform database 414.

[0194] In some embodiments, data from one or more external data sources is used to generate, update, and / or maintain an object data store. For example, one or more external data sources may include one or more object directories. Each object directory may include a plurality of object identifiers and / or object attributes for each object identifier. For example, an object directory may include 10 data points, 20 data points, 40 data points, or more data points for each of the plurality of object identifiers. Each data point may indicate an object attribute of the object. The object attributes may be obtained by the external data source from a manufacturer, a supplier, and / or any other entity associated with a particular object. In some examples, the object data store may be aggregated according to each of one or more different external data sources to aggregate, validate, and / or augment a plurality of record data objects 424 associated with a plurality of different entities.

[0195] In some embodiments, an "object attribute" is a data entity that describes a characteristic of an object. Object attributes may include object-based attributes and / or exchange-based attributes.

[0196] For example, object-based attributes may include spatial attributes, count attributes, value attributes, source attributes, composition attributes, category attributes, and / or any other attributes that describe a characteristic of an object. For example, a spatial attribute may indicate one or more dimensions of an object (e.g., height, width, weight, etc.), a value attribute may indicate the value of an object (e.g., price, etc.), a composition attribute may indicate one or more raw materials, components, etc. of an object, and a category attribute may indicate one or more categories of an object (e.g., restricted substances, etc.) and / or the like. For example, one or more category attributes may indicate whether an object is associated with (i) one or more general store categories (e.g., vegetables, fruits, dairy products, meats, grains, seeds, alcohol, tobacco, in-store consumables, hot food, pharmacy, pet food, and non-food), (ii) one or more medical categories (e.g., dentistry, eye care, general health, etc.), (iii) one or more information categories (e.g., international source, domestic source, etc. and / or the like). In some examples, a composition attribute may indicate one or more components of an object, such as the volume percentage of alcohol in an object, one or more raw materials (e.g., meat, dairy products, peanut products, tree nut products, soybean products, etc.).

[0197] In some examples, object-based attributes can be at least partially based on a value system. For example, at least in a finance-based value system, object-based attributes can include one or more line item attributes, one or more line item adjustments, etc. Line item attributes can include sequence, line item group, product code, item name, item source (e.g., vendor, manufacturer, etc.), description, quantity, quality (e.g., grams, kilograms, etc.), one or more spatial dimensions (e.g., length, width, height, volume, etc.), unit amount, unit tax, line amount (e.g., the amount of the line item), line tax, etc. Line item adjustments can include adjustment type (e.g., manufacturer discount, store discount, return, pay cash, pay gift card, pay other, etc.), item, product or service code, item description, item quantity, unit item, item quality (e.g., grams, kilograms, etc.), unit amount, unit tax, line amount (e.g., the amount of the line item), line tax, etc.

[0198] In some examples, one or more exchange-based attributes can indicate one or more aggregated exchange characteristics. For example, an exchange-based attribute can include a count attribute that describes the number of value-based exchanges involving a particular object. For example, the count attribute can indicate the number of units of a particular object obtained through multiple value-based exchanges. For example, as described herein, whenever an object is referenced in a value-based exchange, the exchange platform can increment the count attribute of the object. In some examples, whenever an object is authorized for acquisition, the exchange platform can increment the count attribute of the object. In some examples, the record data object 422 can include multiple count attributes that respectively identify the number of units of the object that have been acquired (e.g., acquired count), the number of units of the object that have been authorized for acquisition (e.g., authorized count), and / or the number of units of the object that have been requested for acquisition (e.g., requested count).

[0199] In some examples, one or more exchange-based attributes can include exchange-specific characteristics. For example, an exchange-based characteristic can include a source attribute that describes the location (e.g., retailer, physical store, healthcare center, information source, etc.) from which an object is obtained (e.g., purchased, etc.) through a value-based exchange. For example, the location can include a virtual location and / or a physical location. In some examples, the location may depend on the value system. For example, in a financial value system, the source attribute can identify a retailer, a particular physical store of the retailer, an online platform, etc. In a healthcare value system, the source attribute can be a virtual and / or physical healthcare center, etc. In an information value system, the source attribute can be an information source, etc.

[0200] In some examples, the record data object 422 and / or the count property can be source-specific. For example, different record data objects 422 and / or count properties can be maintained for each source, from which objects can be obtained. Additionally or alternatively, the record data object 422 and / or the count property can be source-independent.

[0201] In some embodiments, the restricted object is one or more different types of objects that can be associated with exchange criteria for acquisition through value-based exchange. The restricted object can include, for example, an object constrained by one or more acquisition restrictions 424.

[0202] In some embodiments, the acquisition restriction 424 is a data entity that defines one or more criteria for validating an object for value-based exchange. The acquisition restriction 424 can define one or more user-specific rules, location-specific rules, and / or other rules for validating the restricted object.

[0203] The location-specific rules can include one or more geographical restrictions and / or sovereign entity restrictions. For example, the location-specific rules can indicate restrictions on acquiring one or more restricted objects in one or more countries, states, counties, etc. within a sovereign entity and / or other geographical regions. For example, federal laws that can form the basis of the acquisition restriction 424 can prohibit the acquisition of one or more restricted objects.

[0204] The user-specific rules can include one or more age restrictions, residence restrictions, credit score restrictions, etc. In some examples, the age restriction can indicate one or more age ranges and / or age thresholds for acquiring a restricted object. For example, the age restriction can define one or more age categories for one or more different types of restricted objects. Each age category can define an age range (e.g., age group, etc.) corresponding to a different type of restricted object. For example, the first age category can indicate an age range below the minimum age for acquiring a first object (e.g., tobacco), the second age category can indicate an age range above the minimum age range for acquiring tobacco but below the second minimum age for acquiring a second object (e.g., alcohol), and the third age category can indicate an age range above the second minimum age range.

[0205] In some embodiments, the acquisition restriction 424 can be at least partially based on the exchange location associated with the value-based exchange. For example, the location-specific rules and / or user-specific rules can be modified for different locations. The user-specific rules can be formed based on one or more legal requirements corresponding to the exchange location, such as one or more age categories, etc.

[0206] The acquisition restriction 424 can correspond to an object and / or one or more object attributes. For example, one or more acquisition restrictions 424 can correspond to one or more object identifiers. For example, the record data object 422 of an object can include an indication of one or more acquisition restrictions 424. Additionally or alternatively, the acquisition restriction 424 can correspond to one or more object attributes. For example, the acquisition restriction 424 can correspond to a category attribute (e.g., alcohol, tobacco, etc.), a composition attribute (e.g., percentage of alcohol, etc.), etc.

[0207] By performing one or more exchange operations, the partner service 410 and / or the service provider service 412 can generate and utilize a plurality of non-traditional identifiers for referring to one or more aspects of a user, a service provider tool, and / or a value exchange. At least some of these identifiers can include a universally unique identifier (such as UUEK) that can be used to provide a credential-less value exchange. Each identifier can be at least temporarily stored in the platform database 414. The platform database 414 can include any type of storage device as described herein. In some examples, each service and / or one or more groups of services can be associated with a single portion of the platform database 414.

[0208] As described herein, one or more identifiers can be stored correlatively to form an identifier mapping that the exchange platform 102 (and / or one or more of its services) can utilize to refer to a user, a service provider tool, and / or any other aspect of a value exchange between the partner platform 420, the service provider platform 440, and / or any other member platform without including user credentials. Now, reference will be made to Figure 5 for a further description of examples of non-traditional identifiers.

[0209] e. Example data structures

[0210] Figure 5Example data graph 500 for facilitating voucherless value exchange according to one or more embodiments of the present disclosure. Data graph 500 shows multiple different types of related identifiers. As shown, each identifier can be associated with at least one related identifier to form an identifier mapping within one or more platforms (e.g., exchange platform 102 and / or service provider platform 440). The identifier mapping enhances the communication between exchange platform 102 and service provider platform 440, which references service provider tool 518, without exposing the persistent vouchers 514 (e.g., username, password, card number, etc.) associated with service provider tool 518 that are vulnerable to fraud, abuse, and exploitation by malicious parties. As shown, using some techniques of the present disclosure, the persistent vouchers 514 may never need to be transmitted outside of service provider platform 440. Data graph 500 only shows some of the multiple identifiers that can be generated, stored, and / or utilized by various embodiments of the present disclosure. It will be understood that the illustrated identifiers are not an exhaustive list and may also include other identifiers not shown. Each of the identifiers can be labeled as an identifier, reference, key, and / or other similar terms. These terms, which may be used interchangeably herein, are used to refer to information units for identifying data structures, entities, and / or any other components described herein.

[0211] As shown, some of the multiple related identifiers in various embodiments of the present disclosure may include: for example, (i) one or more user references 502, which can be mapped to member user identifiers 522 of service provider platform 440, (ii) one or more service provider partitions 504 corresponding to a network of joined service provider platforms (e.g., service provider platform 440), (iii) one or more partner partitions 506 corresponding to a network of joined partner platforms, (iv) one or more tool references 520, which can be mapped to member tool identifiers 508 of service provider platform 440, (v) one or more keys 516 and / or system identifiers 512 associated with user reference 502 and / or tool reference 520, (vi) one or more exchange identifiers 510, which can be mapped to system identifier 512 and / or key 516, and / or (vii) one or more UUEKs 524, which can be mapped to at least one of exchange identifier 510 and / or partner partition 506 and / or service provider partition 504.

[0212] In some examples, the service provider platform 440 may store one or more identifiers that can be mapped to one or more identifiers of the exchange platform 102 and / or the service provider tool 518, such that the service provider platform 440 can at least partially reference the service provider tool 518 based on the identifier, which itself does not represent any aspect of the service provider tool 518, including the persistent credentials 514 of the service provider tool 518.

[0213] For example, the service provider platform 440 may store, maintain, and / or otherwise access one or more keys 516 that are mapped to one or more system identifiers 512 of the exchange platform 102 (e.g., the one or more keys 516 are a copy, derivation, etc. of the one or more system identifiers 512). For example, the key 516 may include the system identifier 512 as part of the key 516. The key 516 may be mapped to the employee tool identifier 508 and / or the member user identifier 522, which may internally reference the user and / or the service provider tool 518 of the service provider platform. For example, the key 516 may be provided during the registration process between the service provider platform 440 and / or the exchange platform 102.

[0214] As another example, the exchange platform 102 may store, maintain, and / or otherwise access one or more references (e.g., the tool reference 520 and / or the user reference 502), which are mapped to one or more member identifiers (e.g., the reference is a copy, derivation, etc. of the one or more member identifiers), such as the employee tool identifier 508 and / or the member user identifier 522 of the service provider platform 440. For example, the reference may be provided during the registration process between the service provider platform 440 and / or the exchange platform 102.

[0215] In some embodiments, the exchange platform 102 uses one or more entity partitions to reference each member platform of the member platform network. In some embodiments, the entity partition is a unique identifier of a computing entity. The entity partition may include a unique number, alphanumeric, etc. that represents a specific computing entity. For example, the entity partition may include a member partition that represents a member platform, a service provider partition 504 that represents the service provider platform 440, a partner partition 506 that represents the partner platform 420, etc.

[0216] In some embodiments, the service provider partition 504 is a unique identifier of the service provider and / or the service provider platform 440 of the service provider. The service provider partition 504 may include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols representing the service provider associated with the switching platform 102 (e.g., joined to the switching platform, registered with the switching platform, etc.). For example, the switching platform 102 may include a plurality of service provider partitions that respectively identify service provider platforms 440 attached to the switching platform 102 (e.g., joined to the switching platform, registered with the switching platform, etc.). Each service provider partition 504 may represent a service provider platform 440 that has been configured with one or more switching platform software development kits (SDKs) for implementing the service provider interface of the switching platform, etc.

[0217] In some embodiments, the partner partition 506 is a unique identifier of the partner and / or the partner platform of the partner. The partner partition 506 may include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols representing the partner associated with the switching platform 102. For example, the switching platform 102 may include a plurality of partner partitions that respectively identify partner platforms attached to the switching platform 102 (e.g., joined to the switching platform, registered with the switching platform, etc.). Each partner partition 506 may represent a partner platform that has been configured with one or more switching SDKs for implementing the partner interface of the switching platform 102, etc.

[0218] In some embodiments, when a member platform joins the switching platform 102, an entity partition is generated to identify the member. In some examples, after joining the switching platform, the member platform may use one or more switching interfaces to register one or more service provider tools with the switching platform 102. By exchanging one or more tool identifiers with the switching platform 102, the service provider tool 518 can be registered with the switching platform 102.

[0219] In some embodiments, the tool identifier includes any representation of the service provider tool 518 that identifies the service provider tool without exposing the persistent credentials 514 of the service provider tool 518. The tool identifier may include a member tool identifier 508, a system tool identifier, a tool reference 520, a tool key, etc., as described herein.

[0220] In some embodiments, the member tool identifier 508 is a unique identifier for representing a service provider tool 518 within a member platform (e.g., the service provider platform 440). For example, the member tool identifier 508 can include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that represents the service provider tool 518 to the service provider platform 440. In some examples, the member tool identifier 508 can include a table identifier of a member tool data object.

[0221] In some embodiments, the tool reference 520 is a unique identifier for referencing the member tool identifier 508. For example, the tool reference 520 can be generated by and / or provided to the exchange platform 102 by the member platform to allow the exchange platform 102 to reference the service provider tool 518 maintained at the member platform. In some examples, the tool reference 520 is the same value as the member tool identifier 508. In some examples, the tool reference 520 is a different value that maps to the member tool identifier 508.

[0222] In some embodiments, the system tool identifier is a unique identifier for representing the service provider tool 518 within the exchange platform 102. For example, the system tool identifier can include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that represents the service provider tool 518 to the exchange platform 102 without exposing the persistent credentials 514 of the service provider tool 518. In some examples, the system tool identifier can include a UUID. In some examples, the system tool identifier can include at least one of the system identifiers 512.

[0223] In some embodiments, the tool key is a unique identifier for referencing the system tool identifier. For example, the tool key can be generated and / or provided by the exchange platform 102 during the process of registering the service provider tool 518 with the exchange platform 102. In some examples, the tool key can include an encapsulated system tool identifier. For example, the tool key can include an alphanumeric string formatted according to a key format established by the exchange platform 102 (and / or one or more of its APIs). The key format can include any number of characters, such as fifty characters or more. In some examples, the characters may be case-sensitive. The first part of the characters (e.g., the first six characters) can be retained as a partition for identifying the entity associated with the key. For example, for the tool key, the partition can include the service provider partition 504. The second part of the characters can identify the system tool identifier. In some examples, the tool key can include at least one of the keys 516. The key formats described herein can include one or more different parts, and each of the one or more different parts can be arranged in any order.

[0224] In some embodiments, after being added to the exchange platform 102, a member platform can utilize one or more exchange interfaces to register one or more users with the exchange platform 102. By exchanging one or more tool identifiers with the exchange platform 102, a user can be registered with the exchange platform 102. For example, user identifiers can be used to generate, maintain, and / or update one or more user data objects that reflect users of the member platform and / or the exchange platform 102.

[0225] In some embodiments, a user data object is a data entity that represents a user interacting with the member platform and / or the exchange platform 102. A user can include, for example, an entity (such as an individual, an organization, a group, etc.) participating in a value exchange managed by the exchange platform 102. In some examples, a user can indirectly cooperate with the exchange platform 102 by creating a user account with a registered service provider, registering (and / or allowing registration of) a service provider tool 518, and the like. In some examples, the exchange platform 102 can operate on behalf of a user without the user directly contacting the exchange platform 102. For example, the exchange platform 102 can act as a hidden intermediary between a user-facing application and the user's service provider tool 518.

[0226] In some embodiments, a user data object includes one or more user identifiers and / or one or more user attributes. In some examples, one or more user identifiers and / or one or more user attributes can be at least partially based on the type of the user data object. For example, a user can be represented as a member user data object in the member platform. Additionally or alternatively, a user can be independently represented by a system user data object in the exchange platform. In some examples, the member user data object and the system user data object can include one or more of the same one or more user identifiers and / or user attributes. For example, a member platform can register multiple users with the exchange platform 102. During the registration process, the member platform can provide one or more of the user identifiers and / or user attributes, and in some examples, the exchange platform 102 can return another identifier.

[0227] In some embodiments, a member user data object is an internal representation of a user within a member platform (e.g., service provider platform 440). The member tool data object may include one or more user identifiers 522, such as a member user identifier, a user key from the exchange platform 102, etc. Additionally or alternatively, the member user data object may include one or more user attributes. The one or more user attributes may indicate one or more context characteristics of the user. In some examples, the user attributes may indicate one or more identifiable characteristics of the user. For example, the user attributes may indicate the user's first name, last name, email, physical address (e.g., one or more of street, location, region, postal code, country, etc.), birthday (e.g., date of birth, age range, etc.), phone number, etc. In some examples, the user attributes may include an encrypted representation, a hash representation, and / or otherwise secured representation of the user's identifiable characteristics. For example, the user attributes may include one or more hash identifiers of the user.

[0228] In some embodiments, the user attributes may indicate the user's age. For example, the user attributes may indicate the user's birthday. Additionally or alternatively, the user attributes may indicate an age range. The age range may indicate an age category of the user. For example, the age category may indicate an age range customized for one or more access restrictions. For example, in the United States, the age ranges may include (i) a minor age range, which indicates users under 18 years old, (ii) a first partial minor age range, which indicates users 18 years old or older but under 19 years old, (iii) a second partial minor age range, which indicates users 19 years old or older but under 21 years old, and (iv) an unrestricted age range, which indicates users over 21 years old. In this way, the user attributes can reflect age-related information of the user without exposing sensitive user information such as the user's date of birth.

[0229] In some embodiments, a system user data object is an external representation of a user of a member within the exchange platform 102. The system user data object may include one or more user identifiers, such as a user reference 502 for the member platform, a system user identifier, etc. Additionally or alternatively, the system user data object may include one or more user attributes, such as the user attributes described above. For example, the member platform may register a user with the exchange platform 102. During the registration process, the member platform may provide a user reference 502 for the user and / or one or more user attributes. In some examples, the user attributes may include a hash identifier and / or an encrypted identifier of the user.

[0230] In some embodiments, the user identifier includes a unique identifier of a user involved in a value-based exchange. The user identifier may include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that represents a user of the exchange platform 102 and / or the member platform. In some examples, the user identifier may include a user reference 502, a user key, a system user identifier, a member user identifier, etc.

[0231] In some embodiments, the system user identifier is a unique identifier for representing a user within the exchange platform 102. For example, the system user identifier may include a sequence of digits, an alphanumeric sequence, any / or any other characters or symbols that represent a user to the exchange platform 102. In some examples, the system user identifier may include a UUID specific to a particular user. In some examples, the system user identifier may include at least one of the system identifiers 512.

[0232] In some embodiments, the member user identifier 522 is a unique identifier for representing a user within the member platform. For example, the member user identifier may include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that represent a user to the service provider platform 440.

[0233] In some embodiments, the user reference 520 may be a unique identifier for referencing the member user identifier 508. For example, the user reference 502 may be generated by the member platform and / or provided to the exchange platform 102 to allow the exchange platform 102 to reference a user associated with the member platform. In some examples, the user reference 502 is the same value as the member user identifier 522. In some examples, the user reference 502 is a different value that maps to the member user identifier 522.

[0234] In some embodiments, the user key is a unique identifier for referencing the system user identifier. For example, the user key may be generated and / or provided by the exchange platform 102 during the process of registering a user with the exchange platform 102. In some examples, the user key may include an encapsulated system user identifier. For example, the user key may include an alphanumeric string formatted according to a key format established by the exchange platform (and / or one or more of its APIs). For example, the format of the key may include a first portion of characters (e.g., the first six characters), which may be reserved as a partition for identifying the entity associated with the key (e.g., a member, etc.). For example, for a user key, the partition may include a service provider partition 504 and / or a partner partition. The second portion of the characters may identify the system user identifier.

[0235] As Figure 5As shown, a secret key 516 (e.g., a user secret key and a tool secret key as described herein) can be shared across the exchange platform 102 and the service provider platform 440. Additionally, in some examples, references (e.g., a tool reference 520 and a user reference 502) can be shared across entities. These identifiers and the mapping scheme described herein allow the exchange platform 102 to reference the service provider tool 518 without knowing the persistent credentials 514 (e.g., card number, etc.) of the service provider tool 518. As described herein, one or more of the secret key 516 and / or the references can be provided to the service provider platform 440 individually or in any combination. In some examples, each of the secret key 516 and the references can be provided to the service provider platform 440 through a redundant process, which allows the service provider platform to verify that the communication is provided by the exchange platform 102 (e.g., an entity having access to a specific set of secret keys and references, etc.).

[0236] In some embodiments, the persistent credentials 514 of the service provider tool 518 include sensitive user and / or tool credentials (such as card numbers, account numbers, subscription numbers, etc.) that may pose risks to users, members, and / or intermediary entities. When a user applies for, is authorized, and / or otherwise enables a new service provider tool 518, the persistent credentials 514 can be generated, accessed, and / or otherwise provided to the user by the service provider platform 440. Traditionally, the user then uses the persistent credentials 514 to initiate a value exchange using the service provider tool. By doing so, each time the service provider tool 518 is used, the user is forced to expose sensitive credentials directly bound to the service provider tool 518. The secret key 516, reference, and identifier mapping scheme of the present disclosure overcomes these technical deficiencies.

[0237] In some examples, each identifier can be interpreted by a computing platform (e.g., the exchange platform 102 and / or the service provider platform 440), but not by a user. To enable a user to select the service provider tool 518 while maintaining the enhanced security features of the present disclosure, in some examples, the identifier can be further enhanced through a tool representation Figure 5 of the identifier.

[0238] In some embodiments, the tool representation ( Figure 5The tool representation (not shown in [the figure]) is a unique identifier for representing the service provider tool 518 to the user without exposing the persistent credentials 514 of the service provider tool 518. For example, the tool representation can include a sequence of digits, an alphanumeric sequence, any, or any other sequence of characters or symbols that represents the service provider tool 518 only to an entity with prior knowledge of the service provider tool 518. The format and / or value of the tool representation can be at least partially based on the type of the service provider and / or the service provider tool 518. For example, in a financial value system, the tool representation can include a part of the persistent credentials 514 (e.g., the last four digits, etc.), such as a card number (e.g., a debit card, a credit card, etc.), a financial account number, etc. As another example, in an information value system, the tool representation can include a part of the persistent credentials 514 (e.g., one or more digits, alphanumeric characters, etc.), such as a subscription account, etc. For example, the tool representation can include a derivative of the persistent credentials 514 that only allows an entity with prior knowledge of the persistent credentials 514 to use the tool representation to identify the persistent credentials 514. As another example, the tool representation can include a tool alias that is specified by the user and subsequently recognized by the user.

[0239] In some embodiments, a tool representation of the exchange platform 102 can be provided (e.g., during a registration process) in place of the persistent credentials 514. In this way, the exchange platform 102 can use the tool representation to represent the service provider tool 518 without knowing the persistent credentials 514 from which the tool representation can be derived. For example, unlike traditional web-based exchange platforms, the exchange platform 102 may not require the persistent credentials 514 corresponding to the service provider tool 518 to perform various computing tasks of the present disclosure. This in turn allows the exchange platform 102 to operate more flexibly, while storing previously unrecorded context data, reducing operating computing costs, and improving security measures for users and the platform against penetration attacks by malicious computing entities.

[0240] In some embodiments, the identifier mapping scheme is supplemented by a unique temporary key that is issued to member platforms to facilitate secure, real-time value exchange. For example, by implementing an exchange identifier 510 that represents aspects of value-based exchange, the exchange platform 102 can facilitate an additional layer of network and data security. Some examples of the exchange identifier 510 can include service-provider-specific exchange identifiers and / or partner-specific exchange identifiers. A service-provider-specific exchange identifier can include a temporary, unique exchange identifier that temporarily represents the service-provider tool 518 and the service-provider platform 440. For example, a service-provider-specific exchange identifier can be mapped to a system identifier 512 for the service-provider tool 518. A partner-specific exchange identifier can include a temporary, unique exchange identifier that temporarily represents the service-provider tool 518 and the partner platform. For example, a partner-specific exchange identifier can be mapped to a key 516 for the service-provider tool 518, and the key 516 can be used to identify the service-provider platform 440. In certain examples, such mapping can be defined by an exchange data object.

[0241] In some embodiments, an exchange data object is a data entity that represents an authorized value exchange between one or more members associated with the exchange platform 102. In some examples, the exchange data object can include one or more identifiers and / or one or more exchange attributes. For example, the one or more identifiers and / or the one or more exchange attributes can be at least partially based on the type of the exchange data object. For example, an exchange can be represented as a member exchange data object in a member platform. Additionally or alternatively, the exchange can be independently represented by a system exchange data object in the exchange platform 102. In some examples, the member exchange data object and the system exchange data object can include one or more of the same one or more identifiers and / or exchange attributes. For example, using some techniques of the present disclosure, the exchange platform 102 can issue one or more unique identifiers to a member platform, and the one or more unique identifiers can be used to authorize value exchange.

[0242] In some embodiments, a system exchange data object is an internal representation of a value exchange that uses the exchange platform 102 as an intermediary. In some examples, depending on the role of the system exchange data object in a value-based exchange, the system exchange data object can include one or more different identifiers and / or exchange attributes

[0243] For example, the system exchange data object may include a service-provider-specific exchange data object corresponding to the service provider platform 440. The service-provider-specific exchange data object may include one or more identifiers, such as an exchange identifier 510, a system identifier 512 (e.g., a system user identifier and / or a system tool identifier), a UUEK 514, etc. Additionally or alternatively, the service-provider-specific exchange data object may include one or more exchange attributes, such as a due date, a currency (e.g., a currency for a financial value system, etc.).

[0244] Additionally or alternatively, the system exchange data object may include a partner-specific exchange data object corresponding to the partner platform. The partner-specific exchange data object may include one or more identifiers, such as an exchange identifier 510, one or more keys 516 (e.g., a tool key), a UUEK 524, a member tool reference (e.g., a partner-specific tool reference, etc.). Additionally or alternatively, the partner-specific exchange data object may include one or more exchange attributes, such as a due date, a currency (e.g., a currency for a financial value system, etc.), a tool type, etc.

[0245] In some embodiments, the member exchange data object is an external representation of a value exchange using the exchange platform 102 as an intermediary. The member exchange data object may include one or more identifiers, such as a member exchange identifier, a member tool identifier 508, a UUEK 524 from the exchange platform 102, etc.

[0246] In some embodiments, the exchange identifier 510 is the unique identifier for the value exchange using the exchange platform 102. The exchange identifier 510 can include a sequence of digits, an alphanumeric sequence, any / or any other sequence of characters or symbols that at least represents the user and / or service provider tool 518. In some examples, the exchange identifier 510 can include a Universally Unique Identifier (UUID), which can be mapped (e.g., via a series of identifiers, etc.) to the user, the service provider tool 518, and / or the members registered with the exchange platform 102. In some examples, one or more UUID generators can be used to generate the exchange identifier 510. For example, the exchange identifier 510 can include sixteen bytes of information generated according to one or more UUID formatting standards (e.g., UUID v4, etc.). Thus, while the exchange identifier 510 can be used by the exchange platform 102 and / or the member platform for one or more functions, the same exchange identifier 510 will be useless to an external party in the absence of a priori association between the exchange identifier 510 and one or more other identifiers. In addition to the a priori identifier association, the exchange identifier 510 can be associated with the exchange platform 102. Thus, even if an adversary identifies the exchange identifier 510, the adversary still needs to impersonate the exchange platform 102 to use the exchange identifier 510. Furthermore, before the exchange identifier 510 can be used adversarially, among many other tasks, the adversary also needs to update the settlement account to an account owned by the adversary. Each of these tasks increases the amount of work required to overcome the enhanced security layer added by the exchange identifier 510. When paired with the ephemeral nature of the exchange identifier 510, these tasks can become very costly.

[0247] In some examples, the exchange identifier 510 can be externally represented by the UUEK 524. For example, to facilitate voucherless exchange, the exchange platform 102 can issue one or more UUEKs 524 to one or more member platforms. As described herein, the UUEK 524 can eliminate the reliance on traditional persistent vouchers 514 by identifying aspects of the value exchange via previously mapped data entities.

[0248] In some embodiments, the UUEK 524 is an external representation of the exchange identifier 510, and the UUEK 524 can be issued (e.g., in place of the exchange identifier 510) to an external entity (such as a user, a partner platform, and / or a service provider platform, etc.) to initiate a value-based exchange using the exchange platform 102. For this purpose, the UUEK 524 can be generated by the exchange platform 102 and issued to the external entity. Each UUEK 524 can include multiple values (e.g., up to fifty or more characters, which can be case-sensitive or case-insensitive) representing one or more aspects of the value-based exchange. For example, the multiple values can indicate the exchange identifier 510, a partition (e.g., identifying the recipient of the UUEK 524, etc.), the identifier type, and / or one or more flags. For example, the UUEK 524 can include a partner-specific UUEK and / or a service-provider-specific UUEK. The partner-specific UUEK can be associated with a partner-specific exchange data object and can include the partner partition 506, while the service-provider-specific UUEK can be associated with a service-provider-specific exchange data object and can include the service provider partition 504, as described herein.

[0249] For example, the UUEK 524 can be generated according to a key format. The key format can include multiple characters, including, for example, fifty or more characters, which can be case-sensitive or case-insensitive. The first part of the characters (e.g., the first six characters) can be retained as a partition for identifying the recipient of the UUEK 524. For example, the partition can include the partner partition 506, the service provider partition 504, and / or any other member partition. For example, the UUEK 524 can be issued in response to a request from an authorized member (such as an affiliated partner and / or a service provider).

[0250] Additionally or alternatively, at least one character of the key format (e.g., the seventh character) can identify the format of the UUEK 524. At least one additional character (e.g., the eighth character) can identify the type of the UUEK 524. In some examples, the second part of the characters can identify the exchange identifier 510 (e.g., a set of twenty-two characters after the eighth character). The third part of the characters (e.g., a set of twenty characters after the first part of the characters) can be retained. An example representation is given below:

[0251] ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr

[0252] Where p represents a partition character, F represents a format character, i represents an identifier type character, G represents the exchange identifier 510, and r represents a reserved character. The key format allows 9.8×10^84 unique permutations, which is more than the number of atoms in the known observable universe. This enables the generation and distribution of new UUEKs 524 on demand without compromising the security of the underlying data (e.g., the user's identifier, tools, and / or any other potentially sensitive information) to which the UUEK 524 may map.

[0253] As described herein, the unique sequence of identifiers and the mapping scheme between identifiers can facilitate a credential-less value exchange system for registered and / or unregistered entities. In some examples, one or more of the identifiers can be generated through a registration or enrollment process configured to establish cross-entity relationships between users, partners, and service provider entities. Figure 5 The identifiers in can be used to implement a communication interface that serves as a transmission vehicle for object-level attributes. Object-level attributes can be utilized to perform Figure 6 and Figure 7 the verification operations described.

[0254] V. Example System Operations

[0255] Figure 6 A process flow for facilitating credential-less value exchange in accordance with one or more embodiments of the present disclosure is provided. The process flow describes a network-based process 600 for securely determining value-based exchanges at a granular level, object level, using some of the communication techniques of the present disclosure. As described herein, process 600 can be used to overcome various limitations of traditional exchange systems that expose sensitive persistent credentials to multiple third parties, such as lack of flexibility, security, etc. Process 600 can be implemented by one or more of the computing devices, entities, and / or systems described herein. For example, through the various steps / operations of process 600, an exchange platform can utilize communication techniques to overcome various limitations of traditional exchange mechanisms by eliminating the reliance on static, sensitive credentials, thereby providing greater flexibility and control over value-based exchanges.

[0256] Figure 6 An example process 600 is shown for illustrative purposes. Although the example process 600 describes a specific order of steps / operations, the order can be modified without departing from the scope of the present disclosure. For example, some of the illustrated steps / operations can be performed in parallel or in a different order that does not materially affect the functionality of process 600. In other examples, different components of an example device or system implementing process 600 can perform functions substantially simultaneously or in a specific order.

[0257] In some examples, process 600 begins after a registration and / or enrollment process in which the user and / or member platform may receive a UUEK for facilitating voucherless value exchange. For example, as described herein, one or more enrollment processes may be pre - executed between an exchange platform and one or more service provider platforms to enroll multiple service provider tools with the exchange platform. Thereafter, the exchange platform may generate a UUEK and issue the UUEK to the enrolled service provider platforms to initiate value - based exchanges using the enrolled service provider tools without reference to persistent vouchers of the service provider tools. Additionally or alternatively, an enrollment process may be performed to enroll the registered service provider tools maintained by the service provider platform with a partner platform. In some examples, the exchange platform may facilitate the enrollment process and, in response to successful enrollment, generate a UUEK and issue the UUEK to the partner platform to initiate future value - based exchanges.

[0258] In the case where a user wishes to perform a value - based exchange with a partner platform with which the user has previously enrolled a partner account, the partner platform may query the enrolled partner account and identify the issued UUEK for the user based on the partner account to authorize the value - based exchange. In the case where a user wishes to perform a value - based exchange with a partner platform with which the user has not previously enrolled a partner account, the user may provide a previously issued UUEK (e.g., a UUEK issued to a service provider platform, etc.) to the partner platform (e.g., via a partner application, etc.), and the partner platform may use the UUEK to authorize the value - based exchange. For example, the partner platform may use the UUEK to issue an exchange request to the exchange platform to initiate a value - based exchange.

[0259] Using some of the communication techniques of the present disclosure, a member platform may issue an exchange request with object - level details that can be determined by the exchange platform. For example, by replacing the persistent voucher of the service provider tool with a UUEK, the communication techniques of the present disclosure can provide a transmission mechanism for object - level details without compromising the security of the user, the service provider tool, or the member platform. This enables the exchange platform to act as a decision - making engine to determine object - level insights for the exchange request. These insights may be utilized by the exchange platform in accordance with the steps / operations of process 600 to enforce member policies on behalf of the member platform without the continuous participation of the member platform.

[0260] In some embodiments, process 600 includes: receiving a swap request having a UUEK at step / operation 602. For example, a swap platform (e.g., a partner service of the swap platform, etc.) can receive the swap request using a partner interface to perform a value-based swap. The swap request can indicate a UUEK that includes a swap identifier. Additionally or alternatively, the swap request can include one or more request attributes. The one or more request attributes can include one or more object identifiers, object attributes, resolution flags, etc. In some examples, the swap request can include a swap location. The swap location can indicate a physical location (e.g., a brick-and-mortar store, etc.), a virtual location (e.g., an online retail platform), and / or a geographic region (e.g., a country, state, county, or other region).

[0261] The one or more request attributes can include a plurality of object identifiers that correspond to a plurality of objects associated with the value-based swap. Additionally or alternatively, the one or more request attributes can include one or more object attributes of the plurality of objects. For example, the one or more object attributes can include one or more object-based attributes (e.g., one or more line item attributes), one or more swap-based attributes (e.g., the quantity of the object, the location of the object, etc.). For example, the swap request can indicate a swap location from which the object is obtained.

[0262] In some examples, the request attributes can indicate one or more request resolution flags. The request resolution flags can indicate one or more member requirements (e.g., partner requirements, etc.) for which requests are being made for the value-based swap. For example, one or more request resolution flags can be set by a member of a swap network that provides the swap request to the swap platform. In some examples, the request resolution flags can indicate partial swap authorization or full swap authorization. Partial swap authorization can authorize a partial completion of the value-based swap, while full swap authorization can only authorize a full completion of the value-based swap. For example, full swap authorization may require verification of all objects referenced in the value-based swap.

[0263] In some embodiments, one or more object identifiers and / or object attributes correspond to one or more record data objects maintained by an exchange platform. For example, the object identifier of an exchange request may correspond to the object identifier of a record data object. Additionally or alternatively, one or more of the object attributes of the exchange request may correspond to one or more object attributes of the record data object. In some examples, the exchange platform may identify one or more record data objects at least in part based on one or more object identifiers and / or one or more object attributes. In response to identifying a record data object, the exchange platform may increment a count attribute of the object. For example, the count attribute of a corresponding record data object may be incremented in response to an exchange request that references the object represented by the record data object. In some examples, the count attribute may be one of a plurality of count attributes of the object that enable the exchange platform to aggregate object-level insights across multiple different member platforms, locations, etc.

[0264] In some examples, a request attribute may indicate one or more request resolution flags. The request resolution flags may indicate one or more requesting member requirements (e.g., partner requirements, etc.) for a value-based exchange. For example, one or more request resolution flags may be set by a member of an exchange network that provides an exchange request to the exchange platform. In some examples, the request resolution flags may indicate partial exchange authorization or full exchange authorization. Partial exchange authorization may authorize a partial completion of a value-based exchange, while full exchange authorization may only authorize a full completion of a value-based exchange. For example, full exchange authorization may require verification of all objects referenced by a value-based exchange to be executed by the exchange platform.

[0265] In some examples, request attributes may include a member exchange reference (e.g., a member platform's reference to a value-based exchange), a channel (e.g., a money exchange type of a financial value system, such as a push value transfer or a pull value transfer, real-time payment, etc.), a currency (e.g., a currency for a financial value system, etc.), an organization key (e.g., a platform identifier of a member organization), an organization category (e.g., airline, clothing, etc.), an institution key (e.g., a platform identifier of a retail location, etc.), a staff identifier, and / or any other traceable information for a value-based exchange.

[0266] In some embodiments, process 600 includes identifying an exchange data object at step / operation 604. For example, an exchange platform (e.g., a partner service of the exchange platform, etc.) can identify the exchange data object at least in part based on the exchange identifier of the UUEK. For example, the exchange identifier can correspond to the exchange data object. In some examples, the exchange data object can include at least one of the following: (i) a tool identifier of a service provider tool of a member platform and / or (ii) a user identifier of a user associated with the service provider tool.

[0267] For example, as described herein, the UUEK can correspond to a partner platform and / or a service provider platform. For example, the UUEK can include a partner partition that identifies the partner platform in the case where the UUEK is published to the partner platform. In this case, the UUEK includes an exchange identifier corresponding to the partner-exchange data object. As another example, the UUEK can include a service provider partition that can identify the service provider platform in the case where the UUEK is published to the service provider platform. In this case, the UUEK includes an exchange identifier corresponding to the service provider-exchange data object. In some examples, the exchange platform can process the UUEK at least in part based on the member partition.

[0268] In some embodiments, an exchange platform (e.g., a partner service of the exchange platform, etc.) receives a UUEK that includes a partner partition that identifies the partner platform. The exchange platform can use the exchange identifier to identify the partner-specific exchange data object. The partner-specific exchange data object can include a tool key corresponding to a service provider tool of a member platform. The exchange platform can identify the system tool data object at least in part based on the tool key. For example, the exchange platform can identify the member platform at least in part based on the member partition of the tool key and provide the tool key to the service corresponding to the member platform (e.g., a service provider service, etc.). The service can identify the system tool data object at least in part based on the tool key. Then, the system tool data object can be used to identify one or more identifiers (e.g., a user identifier, a tool identifier, etc.) to process the exchange request.

[0269] In some embodiments, a switching platform (e.g., a partner service of the switching platform, etc.) receives a UUEK that includes a service provider partition, and the service provider partition identifies a service provider platform. The switching platform (e.g., a partner service of the switching platform, etc.) may determine that partner-specific switching data objects are unavailable. In response to this determination, the switching platform may identify a member platform at least in part based on the service provider partition, and provide the UUEK to a service corresponding to the member platform (e.g., a service provider service, etc.). The service may identify service provider-specific switching data objects at least in part based on the switching identifier of the UUEK. Service provider-specific switching data objects may be used to identify system tool data objects at least in part based on the member platform and the switching identifier. Then, the system tool data objects may be used to identify one or more identifiers (e.g., user identifiers, tool identifiers, etc.) to process the switching request.

[0270] In some embodiments, process 600 includes: determining, at step / operation 606, one or more valid objects and / or invalid objects of a switching request. For example, a switching platform (e.g., a verification service of the switching platform, etc.) may determine one or more valid objects and / or one or more invalid objects of a switching request at least in part based on one or more user attributes corresponding to a user. For example, a user identifier of a switching data object may be used to identify a system user data object corresponding to a service provider tool. As described herein, the system user data object may include one or more user attributes of the user. In some examples, the switching platform may identify a system user data object corresponding to the switching request, and determine one or more valid objects and / or invalid objects of the switching request at least in part based on the user attributes corresponding to the user.

[0271] In some examples, a switching platform (e.g., a verification service of the switching platform, etc.) may generate valid data objects and / or invalid data objects for a switching request. A valid switching data object may indicate one or more valid objects of the switching request and / or one or more context attributes of the one or more valid objects. An invalid switching data object may indicate one or more invalid objects of the switching request and / or one or more context attributes of the one or more invalid objects.

[0272] In some embodiments, process 600 includes: determining, at step / operation 608, whether the switching request includes an invalid object. For example, a switching platform (e.g., a verification service of the switching platform, etc.) may determine whether the switching request includes an invalid object. If the switching request does not include an invalid object, process 600 proceeds to step / operation 612. If the switching request includes an invalid object, then process 600 proceeds to step / operation 610.

[0273] In some embodiments, process 600 includes: determining, at step / operation 610, whether the exchange request includes a partial authentication flag. For example, the exchange request may include one or more request resolution flags that indicate partial exchange authorization and / or full exchange authorization. The exchange platform may determine whether the one or more request resolution flags indicate partial exchange authorization. In the presence of partial exchange authorization and at least one valid object is identified, the exchange platform may proceed to step / operation 612, in which an exchange authorization request is provided to the member platform. For example, in the presence of at least one valid object, in response to determining that one or more request resolution flags indicate partial exchange authorization, the exchange platform may provide an exchange authorization request to the member platform. In the presence of full exchange authorization and / or in the case where at least one valid object is not identified for the exchange request, the exchange platform may proceed to step / operation 616, where an exchange response indicating exchange rejection is provided to the member platform. In this way, process 600 can save computing resources by continuously screening exchange requests at least partially based on the object-level characteristics of the exchange request. In this way, process 600 enables the exchange platform to preliminarily determine exchange requests, thereby reducing the computing resource requirements of the member platform that maintains the service provider tool.

[0274] In some embodiments, the exchange platform generates an exchange record for a value-based exchange at least partially based on one or more valid and / or invalid objects. The exchange record may record one or more attributes of the value-based exchange. In some examples, the exchange record may be stored in a platform database. For example, the exchange record may be stored associatively with a system tool identifier, a system user identifier, etc. The exchange record may indicate the object status of each of one or more valid objects, invalid objects, valid objects, and / or invalid objects and / or any other information associated with the value-based exchange.

[0275] For example, the exchange platform may record the object status of each object of the exchange request. The object status is a data entity that indicates the determination and / or classification of the object relative to the value-based exchange. For example, the object status of a valid object may include an object eligible status, etc. As another example, the object status of an invalid object may include an object ineligible status, etc. The object status of an object that has not been evaluated according to the member policy may include an object not evaluated status. The object status of an object that has not been processed according to the member policy may include an object not specified status. In some examples, the object status may indicate an acquisition restriction corresponding to an invalid object. For example, the object status may include an object age restriction status, etc.

[0276] In some examples, the exchange platform can identify an object that does not correspond to an exchange request for a recorded data object. In such cases, the exchange platform can use one or more object attributes (such as an object identifier, etc.) of the object from the exchange request to generate a recorded data object for the object.

[0277] In some embodiments, process 600 includes: providing an exchange authorization request to a member platform at step / operation 612. For example, the exchange platform (such as the service provider service of the exchange platform, etc.) can use a service provider interface to provide an exchange authorization request to a member platform corresponding to the service provider tool. The exchange authorization request can indicate a tool identifier and / or one or more valid objects of the exchange request. For example, the exchange platform can generate the exchange authorization request at least in part based on system tool data objects identified according to one or more aspects of the UUEK. The exchange authorization request can include a tool key and / or a tool reference from the system tool data object.

[0278] In some examples, the exchange authorization request can indicate a user identifier associated with the service provider tool. For example, the exchange platform can generate the exchange authorization request at least in part based on system user data objects identified according to one or more aspects of the UUEK. In some examples, the system user data object can be identified at least in part based on the user identifier of the exchange data object (such as a system user identifier). Additionally or alternatively, the system user data object can be identified at least in part based on the user identifier of the system tool data object (such as a system user identifier). In some examples, the exchange authorization request can include a user key and / or a user reference from the system user data object.

[0279] In some embodiments, the exchange authorization request defines a request for a member to perform a value-based exchange. In some embodiments, the exchange authorization request is provided from the exchange platform to a member of the exchange network. For example, in response to an exchange request from a partner of the exchange network, the exchange authorization request can be provided to the service provider of the exchange network. In some examples, the exchange authorization request can indicate valid exchange data objects of the exchange request. For example, the exchange authorization request can indicate one or more valid data objects, a valid exchange value, one or more object states associated with one or more valid data objects, etc. In some examples, the exchange authorization request can indicate invalid exchange data objects of the exchange request. For example, the exchange authorization request can indicate one or more invalid data objects, one or more object states associated with one or more invalid data objects, etc. For example, the exchange authorization request can indicate an exchange record of the value-based exchange.

[0280] In some embodiments, the exchange authorization request includes an exchange value that is at least partially modified based on one or more valid objects of the exchange request. For example, the exchange request may include multiple object values corresponding to multiple objects associated with a value-based exchange and an initial exchange value for the multiple objects. The exchange platform may determine an exchange value for the value-based exchange by at least partially modifying the initial exchange value based on one or more of the multiple object values corresponding to one or more valid objects. For example, the initial exchange value may be modified to include an aggregate value of one or more object values corresponding to one or more valid objects. For example, the aggregate value may exclude object values corresponding to one or more invalid objects of the exchange request. For example, the aggregate value may aggregate multiple object values from valid objects of the exchange request while removing all object values from invalid objects. In this way, the aggregate value may indicate the exchange value of the valid objects authorized to use a particular service provider tool for acquisition, and the exchange value excludes the portion of the initial exchange value corresponding to the invalid objects. In some examples, the exchange platform may use a service provider interface to provide the exchange authorization request to a member platform. The exchange authorization request indicates an exchange value modified with respect to one or more valid objects.

[0281] In this way, process 600 can save computing resources by continuously filtering exchange requests at least partially based on the object-level characteristics of the exchange requests. In this way, process 600 enables the exchange platform to preliminarily determine exchange requests at a granular, object level to pre-validate objects on behalf of the member platform, thereby reducing the computing resource requirements of the member platform for maintaining the service provider tool.

[0282] In some embodiments, process 600 includes: receiving an exchange authorization request at step / operation 614. For example, an exchange platform (e.g., a service provider service of the exchange platform, etc.) may use a service provider interface to receive an exchange authorization response indicating at least one of an exchange grant or an exchange denial.

[0283] In some embodiments, the exchange authorization response defines a response to the exchange authorization request. In some embodiments, the exchange authorization response is provided from a member of the exchange network to the exchange platform. For example, the exchange authorization response may be provided by a service provider of the exchange network in response to an exchange authorization request indicating one or more valid objects from the exchange request.

[0284] In some embodiments, the exchange authorization response indicates at least one of an exchange grant or an exchange denial. The exchange authorization response can be at least partially based on a comparison between an exchange value (e.g., modifying the exchange value at least partially based on a valid object, etc.) and the asset availability of a service provider tool. For example, in response to receiving an exchange authorization request, a member can be configured to compare the exchange value with the asset availability of an identified service provider tool. In the case where the asset availability exceeds the exchange value, a value-based exchange can be authorized (e.g., resulting in an exchange grant, etc.), otherwise the value-based exchange can be denied (e.g., resulting in an exchange denial).

[0285] In some embodiments, the exchange authorization response indicates one or more context response attributes. For example, the one or more context response attributes can indicate one or more influencing factors of the exchange authorization response. For example, the influencing factors can include bad actor risk and / or fraud check, error, full approval, tool shutdown, tool-based risk and / or fraud check, insufficient value, UUEK invalid, over limit (e.g., exceeding UUEK or tool usage limit), missing line item (e.g., for a value exchange that does not include a valid object), tool not found, account not found, pin required, partial approval, member unavailable, transaction risk and / or fraud check, unsupported operation, user contact member (e.g., the user may need to contact a member (e.g., service provider) to resolve an issue), user risk and / or fraud check, and combinations thereof.

[0286] In some embodiments, the exchange platform can increment a count attribute for each record data object corresponding to a valid object of an authorized value-based exchange. For example, in response to authorization of an object represented by a record data object, the count attribute of the corresponding record data object can be incremented. In some examples, the count attribute can be one of multiple count attributes of the object, and the multiple count attributes enable the exchange platform to aggregate object-level insights across multiple different member platforms, locations, etc.

[0287] In some embodiments, process 600 includes: providing an exchange response in step / operation 616. For example, an exchange platform (e.g., a partner service of the exchange platform, etc.) can use a partner interface to provide an exchange response at least partially based on the exchange authorization response. For example, the exchange response can indicate an exchange grant, an exchange denial, one or more valid objects, and / or one or more invalid objects of the exchange request.

[0288] In some embodiments, an exchange response defines a response to an exchange request. In some embodiments, the exchange request is provided from an exchange platform to a member that provided the exchange request. The exchange response may indicate an exchange grant and / or an exchange denial. Additionally or alternatively, the exchange response may indicate valid data objects, invalid data objects, and / or context response attributes. For example, the exchange response may indicate one or more valid objects and / or one or more invalid objects of the exchange request.

[0289] In some embodiments, the exchange platform updates an exchange record at least in part based on the exchange response. For example, the exchange record may provide context information for the exchange request. The context information may indicate one or more aspects of the exchange request, the exchange response, an exchange authorization request, and / or the exchange authorization request.

[0290] Figure 7 A process flow is provided for determining objects for value-based exchanges according to one or more embodiments of the present disclosure. The process flow describes a network-based process 700 for determining objects for value-based exchanges using UUEK, user attributes, and / or record data objects. As described herein, process 700 can overcome various limitations of traditional exchange systems that are unable to determine individual objects for value-based exchanges over a network. Process 700 can be implemented by one or more of the computing devices, entities, and / or systems described herein. For example, through the various steps / operations of process 700, an exchange platform can utilize determination techniques to overcome various limitations of traditional exchange mechanisms by enabling more flexible entities for entity network communication.

[0291] Figure 7 An example process 700 is shown for illustrative purposes. Although the example process 700 describes a particular order of steps / operations, the order can be modified without departing from the scope of the present disclosure. For example, some of the illustrated steps / operations can be performed in parallel or in a different order that does not materially affect the functionality of process 700. In other examples, different components of an example device or system implementing process 700 can perform functions substantially simultaneously or in a particular order.

[0292] In some examples, process 700 may include one or more sub-operations of step / operation 606 of process 600, where process 600 is configured to determine one or more valid objects and / or invalid objects of an exchange request. For example, process 700 may begin with step / operation 606 and end with step / operation 608.

[0293] In some embodiments, process 700 includes: identifying, at step / operation 702, one or more user attributes corresponding to an exchange request. For example, an exchange platform (e.g., a partner service of the exchange platform, etc.) may identify one or more user attributes corresponding to an exchange request. In some examples, the exchange platform may maintain and / or access multiple system user data objects. Each system user data object may correspond to a user associated with a respective service provider tool. In some examples, the exchange platform may use the unique identifier mapping techniques described herein to identify user attributes at least in part based on the service provider tool, the exchange request, and / or the UUEK of the exchange request.

[0294] In some embodiments, a system user data object is an external representation of a user within the exchange platform. The system user data object may include one or more user identifiers, such as a user reference for a member platform, a system user identifier, etc. Additionally or alternatively, the system user data object may include one or more user attributes. In some examples, a user attribute may indicate a user's age. For example, a user attribute may indicate a user's birthday. Additionally or alternatively, a user attribute may indicate an age range. An age range may indicate a user's age category. For example, an age category may indicate an age range customized according to one or more acquisition restrictions. For example, in the United States, age ranges may include (i) a minor age range, which indicates users under 18 years old, (ii) a first partial minor age range, which indicates users over 18 years old but under 19 years old, (iii) a second partial minor age range, which indicates users over 19 years old but under 21 years old, and (iv) an unrestricted age range, which indicates users over 21 years old. In this way, user attributes can reflect age-related information of a user without exposing sensitive user information, such as the user's date of birth.

[0295] In some embodiments, process 700 includes: identifying, at step / operation 704, an object from the exchange request. For example, an exchange platform (e.g., a partner service of the exchange platform, etc.) may identify an object from the exchange request at least in part based on the object identifier and / or object attributes of the exchange request. For example, the object may correspond to an object identifier among multiple object identifiers. Additionally or alternatively, the object may correspond to one or more object attributes (e.g., line item attributes, etc.) of the exchange request.

[0296] In some embodiments, process 700 includes: determining at step / operation 602 whether an object needs to be verified. For example, an exchange platform (e.g., the verification service of the exchange platform, etc.) can determine whether object verification of the object is needed at least partially based on one or more object attributes and / or user attributes (e.g., age range, etc.) corresponding to the exchange request. For example, object verification may be needed for restricted objects. In some examples, the exchange platform can identify one or more restricted objects from multiple objects at least partially based on one or more object attributes of each object.

[0297] For example, the exchange platform can determine whether the identified object is a restricted object at least partially based on the object identifier of the object and / or one or more object attributes. For example, the exchange platform can identify the recorded object data of the object at least partially based on the object identifier, and identify whether the object is a restricted object at least partially based on the recorded data object. For example, the recorded object data can indicate one or more acquisition restrictions, restricted status, and / or one or more object attributes indicating a restricted object.

[0298] Additionally or alternatively, the exchange request can include one or more object attributes corresponding to the object, and the exchange platform can identify whether the object is a restricted object at least partially based on the comparison between the one or more object attributes and one or more acquisition restrictions. For example, one or more acquisition restrictions can correspond to one or more object attributes, such as ingredient attributes (e.g., alcohol percentage, etc.), category attributes (e.g., tobacco, etc.). If one or more object attributes include at least one of the ingredient attributes and / or category attributes covered by the acquisition restrictions, the one or more object attributes can indicate a restricted object.

[0299] In the case where object verification of the object is not needed, process 700 can return to step / operation 704 to identify another object from the exchange request. In some examples, until each object from the exchange request is identified, process 700 can return to step / operation 704 to determine whether each object is a restricted object. In this way, the exchange platform can identify one or more restricted objects from multiple objects of the exchange request.

[0300] In the case where object verification is needed (e.g., the object is a restricted object, etc.), process 700 can continue to Figure 7 step / operation 708.

[0301] In some embodiments, process 700 includes: determining the validity of a restricted object at step / operation 708. For example, the exchange platform can determine whether the restricted object is a valid object or an invalid object at least in part based on a comparison between one or more user attributes and the acquisition restrictions of the restricted object. In some examples, until each object from the exchange request is identified, process 700 can return to step / operation 704 to determine whether each object is a valid object or an invalid object. In this way, the exchange platform can identify one or more valid objects and / or one or more invalid objects of the exchange request.

[0302] In some examples, a restricted object can be associated with one or more acquisition restrictions. The exchange platform can determine whether the object is a valid object and / or an invalid object at least in part based on a comparison between one or more user attributes and one or more acquisition restrictions. As an example, one or more user attributes can indicate the age range of the user. The age range can correspond to at least one category defined by one or more acquisition restrictions. If the age range (e.g., a partial underage range) meets the category required by one or more acquisition restrictions (e.g., 18 to 21), the restricted object can be determined to be a valid object. If the age range (e.g., 18 to 21) does not meet the category required by one or more acquisition restrictions (e.g., over 21), the restricted object can be determined to be an invalid object. In this way, in some examples, one or more valid objects and / or one or more invalid objects can be at least in part based on the age range of the user. The same and / or similar analysis can be performed for each restriction defined by one or more acquisition restrictions.

[0303] In some examples, one or more acquisition restrictions can be at least in part based on the exchange location associated with the value-based exchange. For example, the exchange request can indicate the exchange location. The exchange platform can determine one or more acquisition restrictions at least in part based on the exchange location and apply the one or more acquisition restrictions to the user attributes to determine whether the restricted object is a valid object or an invalid object. In this way, one or more valid objects and / or one or more invalid objects of the exchange request can be at least in part based on the exchange location.

[0304] In some embodiments, a valid object is an object of a value-based exchange that is authorized subject to one or more acquisition restrictions, if applicable. For example, a valid object may correspond to an object identifier and / or one or more object attributes that do not correspond to a restricted object in a value-based exchange and / or do not correspond to a restricted object in a value-based exchange that implements an acquisition restriction corresponding to the restricted object. For example, in a financial value system, a valid object may be a product or service that a user of a service provider tool is eligible to purchase at an exchange location. For example, a product may be a gallon of milk that can be associated with an SKU code and / or one or more object attributes (e.g., "category: dairy", "quantity: 1 gallon"). If no acquisition restrictions apply to the SKU code and / or one or more object attributes ("category: dairy", "quantity: 1 gallon", etc.), then the product may be a valid object of the value-based exchange.

[0305] In some embodiments, an invalid object is an object of a value-based exchange that is not authorized subject to one or more acquisition restrictions, if applicable. For example, an invalid object may correspond to an object identifier and / or one or more object attributes that correspond to a restricted object in a value-based exchange that does not implement an acquisition restriction corresponding to the restricted object. For example, in a financial value system, an invalid object may be a product or service that a user of a service provider tool is not eligible to purchase at an exchange location. For example, a product may be a liter of alcohol that can be associated with an SKU code and / or one or more object attributes (e.g., "category: restricted content", "quantity: liter"). If an acquisition restriction applies to the SKU code and / or one or more object attributes ("category: restricted substance", "quantity: 1 liter"), and one or more user attributes and / or the exchange location do not satisfy the acquisition restriction, then the product may be an invalid object of the value-based exchange.

[0306] In some embodiments, an exchange platform may increment a count attribute of each record data object corresponding to a valid object. For example, the count attribute of the corresponding record data object may be incremented in response to verification of the object represented by the record data object. In some examples, the count attribute may be one of multiple count attributes of the object that enable the exchange platform to aggregate object-level insights across multiple different member platforms, locations, etc.

[0307] In some embodiments, an exchange platform may generate a valid exchange data object for generating an exchange request. A valid exchange data object may be a data object that indicates one or more valid objects for a value-based exchange. In some examples, the valid exchange data object may be at least partially based on a comparison between the exchange request and / or one or more user attributes corresponding to the exchange request. In some examples, the valid exchange data object may include multiple object identifiers and / or one or more object attributes of one or more valid objects for a value-based exchange.

[0308] In some examples, the valid exchange data object may indicate an exchange value. The exchange value may be an aggregated value of each of the valid data objects. In some examples, some techniques of the present disclosure may be utilized to adjust the exchange value by modifying the exchange value according to an initial exchange value to meet the valid objects for a value-based exchange.

[0309] In some examples, the valid exchange data object may indicate one or more object states of one or more valid objects.

[0310] In some embodiments, the exchange platform may generate an invalid exchange data object for the exchange request. An invalid exchange data object is a data object that indicates one or more invalid objects for a value-based exchange. In some examples, the invalid exchange data object may be at least partially based on a comparison between the exchange request and one or more user attributes corresponding to the exchange request. For example, the invalid exchange data object may indicate multiple invalid objects for a value-based exchange. Additionally or alternatively, the invalid exchange data object may be at least partially based on the exchange request and the valid exchange data object. For example, the invalid exchange data object may indicate multiple invalid objects for a value-based exchange. For example, the invalid exchange data object may indicate multiple objects for a value-based exchange that are not included in the valid exchange data object.

[0311] The invalid exchange data object may include multiple object identifiers and / or one or more object attributes of one or more invalid objects for a value-based exchange. In some examples, the invalid exchange data object may indicate one or more object states of one or more invalid objects.

[0312] Figure 8 A message flow diagram is provided that shows steps / operations for determining a value-based exchange adjusted according to user attributes associated with a value-based exchange. It will be appreciated that the steps / operations of the message flow diagram may be performed and implemented using the corresponding steps / operations in Figure 6 and Figure 7 to perform and implement the steps / operations of the message flow diagram.

[0313] At step / operation 804, user 802 initiates a value-based exchange to obtain multiple objects from partner platform 420 using service provider tools maintained by service provider platform 440.

[0314] At step / operation 806, partner platform 420 provides an exchange request to an exchange platform (e.g., a partner service of the exchange platform, etc.) to perform a value-based exchange. The exchange request includes a UUEK and indicates multiple objects. For example, partner platform 420 may send an exchange request with a UUEK and multiple object identifiers to an exchange platform (e.g., partner service 410 of the exchange platform, etc.). In some examples, the multiple object identifiers may include multiple SKUs.

[0315] At step / operation 808, the exchange platform (e.g., partner service 410 of the exchange platform, etc.) provides the UUEK and data indicating multiple objects to service provider service 412 corresponding to the UUEK. For example, the exchange platform (e.g., partner service 410 of the exchange platform, etc.) may use the UUEK and multiple object identifiers of the exchange request to invoke service provider service 412.

[0316] At step / operation 810, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) identifies the service provider tool and / or user corresponding to the UUEK. For example, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) may query system user data objects and system tool data objects associated with the UUEK.

[0317] At step / operation 812, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) determines whether object verification is required for the value-based exchange at least in part based on the user and / or service provider tool. For example, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) may determine whether object verification is required for the exchange request at least in part based on the UUEK, user, service provider tool, and / or object identifiers of the exchange request.

[0318] In response to determining that object verification is required, at step / operation 814, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) provides data indicating the user and / or multiple objects to verification service 408. For example, the exchange platform (e.g., service provider service 412 of the exchange platform, etc.) may use the multiple object identifiers of the exchange request and system user data objects to invoke verification service 408.

[0319] In step / operation 816, an exchange platform (e.g., the verification service 408 of the exchange platform, etc.) identifies one or more acquisition restrictions corresponding to multiple objects and / or system user data objects. For example, the exchange platform (e.g., the verification service 408 of the exchange platform, etc.) can query the object identifiers of the exchange request to identify one or more acquisition restrictions.

[0320] In step / operation 818, the exchange platform (e.g., the verification service 408 of the exchange platform, etc.) verifies one or more of the multiple objects at least in part based on a comparison between the system user data objects and one or more acquisition restrictions. For example, the exchange platform (e.g., the verification service 408 of the exchange platform, etc.) can verify one or more of the multiple objects according to one or more acquisition restrictions corresponding to the multiple objects.

[0321] In step / operation 820, the exchange platform (e.g., the verification service 408 of the exchange platform, etc.) provides data indicating multiple valid objects to the service provider service 412. In some examples, the exchange platform (e.g., the verification service 408 of the exchange platform, etc.) can provide a list of invalid object identifiers to the service provider service 412 to identify valid objects (e.g., by differentiating invalid objects from valid objects). For example, the exchange platform (e.g., the partner service of the exchange platform, etc.) can return a list of ineligible object identifiers for value-based exchanges.

[0322] In step / operation 822, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) modifies the exchange value at least in part based on one or more valid objects. For example, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) can adjust the authorized amount of the service provider platform 440 if applicable (e.g., one or more valid objects), or reject the value-based exchange if appropriate (e.g., no valid objects).

[0323] In step / operation 824, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) provides an exchange authorization request to the service provider platform 440. For example, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) can initiate a call (e.g., an API call, etc.) to the service provider platform 440 to request authorization for the sum of the eligible objects among the multiple objects of the exchange request.

[0324] In step / operation 826, the service provider platform 440 provides an exchange authorization response to the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.). For example, the service provider platform 440 can return an authorization decision (e.g., approve, reject, etc.).

[0325] In step / operation 828, an exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) provides an exchange authorization response to the partner service 410 and / or indicates data of one or more valid objects. In some examples, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) may provide a list of invalid object identifiers to the partner service 410. For example, the exchange platform (e.g., the service provider service 412 of the exchange platform, etc.) may return the authorization decision and details of the object identifiers that are not eligible (e.g., the object identifiers of one or more invalid objects).

[0326] In step / operation 830, an exchange platform (e.g., the partner service 410 of the exchange platform, etc.) provides an exchange response to the partner platform 420. The exchange response may indicate the exchange authorization response and / or indicate data of one or more valid objects. In some examples, the exchange platform (e.g., the partner service 410 of the exchange platform, etc.) may provide a list of invalid object identifiers to the partner platform 420. For example, the partner service 410 may return the authorization decision and details of the object identifiers that are not eligible (e.g., approve $100, remove alcoholic beverages) (e.g., the object identifiers of one or more invalid objects).

[0327] In step / operation 832, the partner platform 420 provides an indication of the exchange response to the user 802. For example, the partner platform 420 may return the authorization decision to the user 802.

[0328] VI. Conclusion

[0329] Benefiting from the teachings presented in the foregoing description and the related drawings, those skilled in the art to which this disclosure pertains will envision many modifications and other embodiments. Accordingly, it is to be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A computer-implemented method, comprising: receiving, by one or more processors and using a partner interface, a swap request for performing a value-based exchange, wherein the swap request indicates a Universally Unique Temporary Key (UUEK) that includes a swap identifier; identifying, by the one or more processors, at least partially based on the swap identifier, a swap data object, wherein the swap data object includes (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; determining, by the one or more processors, at least partially based on one or more user attributes corresponding to the user, one or more valid objects and one or more invalid objects of the swap request; providing, by the one or more processors and using a service provider interface, a swap authorization request to the member platform, wherein the swap authorization request indicates the tool identifier and the one or more valid objects of the swap request; receiving, by the one or more processors and using the service provider interface, a swap authorization response that indicates at least one of a swap grant or a swap denial; and providing, by the one or more processors and using the partner interface, at least partially based on the swap authorization response, a swap response, wherein the swap response indicates (i) a swap grant or a swap denial and (ii) the one or more invalid objects of the swap request.

2. The computer-implemented method according to claim 1, wherein, the swap request indicates a plurality of objects, and determining the one or more valid objects and the one or more invalid objects includes: identifying, from the plurality of objects, one or more restricted objects, wherein the one or more restricted objects are associated with one or more acquisition restrictions; and determining the one or more valid objects and the one or more invalid objects at least partially based on a comparison between the one or more user attributes and the one or more acquisition restrictions.

3. The computer-implemented method according to claim 2, wherein, the one or more acquisition restrictions are at least partially based on a swap location associated with the value-based exchange.

4. The computer-implemented method according to claim 2, wherein, the one or more user attributes indicate an age range of the user, and the one or more valid objects and the one or more invalid objects are at least partially based on the age range.

5. The computer-implemented method according to claim 4, wherein, the age range corresponds to at least one category defined by the one or more acquisition restrictions.

6. The computer-implemented method according to claim 2, wherein, the swap request includes a plurality of object identifiers corresponding to the plurality of objects, and identifying a restricted object among the one or more restricted objects includes: Identify a record data object of an object among the plurality of objects at least in part based on an object identifier among the plurality of object identifiers; and Identify the restricted object at least in part based on the record data object.

7. The computer-implemented method according to claim 6, wherein, the object identifier is a stock keeping unit.

8. The computer-implemented method according to claim 2, wherein, the exchange request includes a plurality of object attributes corresponding to the plurality of objects, and identifies a restricted object at least in part based on a comparison between one or more of the object attributes among the plurality of object attributes and the one or more acquisition restrictions.

9. The computer-implemented method according to claim 8, wherein, the plurality of object attributes includes at least one of a composition attribute or a category attribute.

10. The computer-implemented method according to claim 1, wherein, the exchange request indicates an exchange location, and the one or more valid objects and the one or more invalid objects of the exchange request are at least in part based on the exchange location.

11. The computer-implemented method according to claim 1, wherein, the exchange request includes a plurality of object values corresponding to a plurality of objects associated with the value-based exchange and an initial exchange value of the plurality of objects, and wherein the computer-implemented method further includes: Determining an exchange value for the value-based exchange by at least in part modifying the initial exchange value based on one or more object values corresponding to the one or more valid objects among the plurality of object values; and Providing the exchange authorization request to the member platform using the service provider interface, wherein the exchange authorization request indicates the exchange value.

12. A computing system, comprising a memory and one or more processors communicatively coupled to the memory, the one or more processors configured to: Receive an exchange request for performing a value-based exchange using a partner interface, wherein, the exchange request indicates a Universally Unique Temporary Key (UUEK) including an exchange identifier; Identify an exchange data object at least in part based on the exchange identifier, wherein the exchange data object includes (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; Determine one or more valid objects and one or more invalid objects of the exchange request at least in part based on one or more user attributes corresponding to the user; Provide an exchange authorization request to the member platform using the service provider interface, wherein the exchange authorization request indicates the tool identifier and one or more valid objects of the exchange request; Receive an exchange authorization response using the service provider interface, the exchange authorized response indicating at least one of an exchange grant or an exchange denial; and Provide a swap response using the partner interface at least in part based on the swap authorization response, wherein the swap response indicates (i) a swap grant or a swap denial and (ii) the one or more invalid objects of the swap request.

13. The computing system according to claim 12, wherein, the swap request indicates a plurality of objects, and determining the one or more valid objects and the one or more invalid objects includes: identifying one or more restricted objects from the plurality of objects, wherein the one or more restricted objects are associated with one or more acquisition restrictions; and determining the one or more valid objects and the one or more invalid objects at least in part based on a comparison between the one or more user attributes and the one or more acquisition restrictions.

14. The computing system according to claim 13, wherein, the one or more acquisition restrictions are at least in part based on a swap location associated with the value-based swap.

15. The computing system according to claim 13, wherein, the one or more user attributes indicate the age range of the user, and the one or more valid objects and the one or more invalid objects are at least in part based on the age range.

16. The computing system according to claim 15, wherein, the age range corresponds to at least one category defined by the one or more acquisition restrictions.

17. One or more non-transitory computer-readable storage media, comprising instructions that, when executed by one or more processors, cause the one or more processors to: receive a swap request for performing a value-based swap using a partner interface, wherein, the swap request indicates a Universally Unique Temporary Key (UUEK) that includes a swap identifier; identify swap data objects at least in part based on the swap identifier, wherein the swap data objects include (i) a tool identifier of a service provider tool of a member platform and (ii) a user identifier of a user associated with the service provider tool; determine one or more valid objects and one or more invalid objects of the swap request at least in part based on one or more user attributes corresponding to the user; provide a swap authorization request to the member platform using a service provider interface, wherein the swap authorization request indicates the tool identifier and the one or more valid objects of the swap request; receive a swap authorization response using the service provider interface, the swap authorized response indicating at least one of a swap grant or a swap denial; and provide a swap response using the partner interface at least in part based on the swap authorization response, wherein the swap response indicates (i) a swap grant or a swap denial and (ii) the one or more invalid objects of the swap request.

18. The one or more non-transitory computer-readable storage media according to claim 17, wherein the swap request indicates a plurality of objects, and determining the one or more valid objects and the one or more invalid objects Comprising: Identifying one or more restricted objects from the plurality of objects, wherein the one or more restricted objects are associated with one or more acquisition restrictions; and Determining the one or more valid objects and the one or more invalid objects at least in part based on a comparison between the one or more user attributes and the one or more acquisition restrictions.

19. The one or more non-transitory computer-readable storage media according to claim 18, wherein, The exchange request includes a plurality of object attributes corresponding to the plurality of objects, and identifies restricted objects at least in part based on a comparison between one or more of the plurality of object attributes and the one or more acquisition restrictions.

20. The one or more non-transitory computer-readable storage media according to claim 19, wherein, The plurality of object attributes includes at least one of a composition attribute or a category attribute.

Images