Systems, methods, and computing platforms for performing network-based credentialless communication exchanges

Abstract

Various embodiments of the present disclosure provide techniques for facilitating credentialless exchange on a network using multiple identifier mappings and member interfaces. The techniques can include receiving an exchange request to perform a value-based exchange. The exchange request indicates a UUEK and one or more transaction attributes. The techniques include identifying an exchange identifier based at least in part on the UUEK, where the exchange identifier corresponds to an exchange data object that includes a tool identifier for a service provider tool of a member platform. The techniques include providing an exchange authorization request to the member platform, receiving an exchange authorization response indicating at least one of a transaction approval or a transaction denial; and providing an exchange response based at least in part on the exchange authorization response.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 370,280, filed August 3, 2022, U.S. Provisional Patent Application Serial No. 63 / 370,279, filed August 3, 2022, and U.S. Patent Application Serial No. 18 / 329,107, filed June 5, 2023, each of which is incorporated by reference herein in its entirety, including any drawings, tables, figures, and appendices. TECHNICAL FIELD

[0003] Embodiments of the present disclosure generally relate to non-certificate value exchange between multiple entities in a value system. BACKGROUND

[0004] In view of the limitations of existing transaction processing technologies and architectures, various embodiments of the present disclosure address technical challenges related to network-based value transactions. Existing processes for performing transactions on a computing network rely on the use of permanent credentials, such as payment credentials (e.g., card numbers, usernames, passwords, bank routing numbers, account numbers, etc.) and their proxies, which expose the recipient of the credentials to fraud, regulatory and compliance costs, and reputational risks. Moreover, due to the static nature of traditional credentials, each time a user provides their credentials to conduct a transaction, the user must accept the risk of financial loss, damaged credit scores, identity theft, and other consequences. The inherent insecurity of permanent credentials is typically addressed using strict communication protocols, data management programs, and authentication schemes, each of which introduces additional technical problems by adding overhead and complicating network-based transactions, without addressing the underlying technical problems of data security.

[0005] For example, a traditional service provider that manages user accounts can limit its exposure using disclaimers that prevent users from providing their credentials to certain third parties. This can result in network congestion due to the limited number of permitted parties being overwhelmed by requests from the population. Moreover, the permitted parties need to register users by obtaining sensitive permanent credentials (e.g., usernames, passwords, routing / transmission credentials, etc.) from the users, and then manage a large number of permanent credentials across multiple registered users. This provides a single attack vector for malicious parties to obtain sensitive user information from the population of users. To combat such attacks, traditional transaction processing entities need to employ costly, resource-intensive, and robust data management programs and authentication schemes, which are imperfect and still vulnerable to infiltration.

[0006] Other techniques for addressing data security include restricting communications (e.g., financial transaction communications) to within strict information standards (e.g., ISO information standards), but these standards lack flexibility and are not designed to provide contextual data for transactions. As a result, such communication standards trade off transaction functionality for increased network security.

[0007] Various embodiments of the present disclosure make significant contributions to various existing network-based value transaction 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 services that facilitate credential-less execution of value-based exchanges that leverage UUEKs (Universal Unique Endorsement Keys) to eliminate the use of permanent credentials. To this end, the intermediary computing platform can facilitate interactions between one or more member platforms to register user instruments in a value exchange system that is supported by a new, temporary data structure (referred to herein as a UUEK). Unlike traditional registration systems, the intermediary computing platform does not receive or rely on permanent user or instrument credentials to register user instruments. Eliminating such credentials enables the use of new, more flexible interfaces, such as the application programming interfaces (APIs) described herein, that the intermediary computing platform leverages to communicate with different network members to register user instruments without exposing user credentials at any step in the process. Once registered, the intermediary computing platform can issue a UUEK that can replace traditional permanent credentials. The issued UUEK does not reflect permanent credentials or any other sensitive user or instrument information. The interface between member platforms and the intermediary platform can allow (i) users to present the issued UUEK (without explicitly referencing permanent credentials) from a member platform to the intermediary platform, and (ii) the intermediary platform to map the issued UUEK to an 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 or instrument information that can be vulnerable to network attacks. Ultimately, it enables additional flexibility (e.g., through the use of new interfaces, etc.) and security (e.g., through the elimination of permanent credentials, etc.) while reducing computational power requirements and significantly increasing network throughput for exchange processing relative to traditional techniques.

[0009] In some embodiments, a method comprises: initiating, by one or more processors and using a partner interface, presentation of a registration user interface via a client device of a user, wherein the registration user interface includes a tool registration screen indicating one or more service provider tools associated with the user; receiving, by the one or more processors and using the partner interface, selection data indicating selection of a service provider tool from the registration user interface; generating, by the one or more processors, a matching code for authenticating the user; providing, by the one or more processors and using a service provider interface, a registration request to a service provider platform corresponding to the service provider tool, wherein the registration request includes service provider registration data indicating the matching code, a user identifier of the user, and a tool identifier of the service provider tool; receiving, by the one or more processors and using the partner interface, an authentication message including the matching code; and in response to authentication of the user based at least in part on the matching code, (i) generating, by the one or more processors, a UUEK for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) providing, by the one or more processors and using the partner interface, the UUEK to the partner platform.

[0010] In some embodiments, a computing system comprises a memory and one or more processors communicatively coupled to the memory, the one or more processors configured to: initiate, using a partner interface, presentation of a registration user interface via a client device of a user, wherein the registration user interface includes a tool registration screen indicating one or more service provider tools associated with the user; receive, using the partner interface, selection data indicating selection of a service provider tool from the registration user interface; generate a matching code for authenticating the user; provide, using a service provider interface, a registration request to a service provider platform corresponding to the service provider tool, wherein the registration request includes service provider registration data indicating the matching code, a user identifier of the user, and a tool identifier of the service provider tool; receive, using the partner interface, an authentication message including the matching code; and in response to authentication of the user based at least in part on the matching code, (i) generate a UUEK for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) provide, using the partner interface, the UUEK to the partner platform.

[0011] 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: initiate, using a partner interface, presentation of a registration user interface via a client device of a user, wherein the registration user interface comprises a tool registration screen that indicates one or more service provider tools associated with the user; receive, using the partner interface, selection data that indicates selection of a service provider tool from the registration user interface; generate a matching code for authenticating the user; provide, using a service provider interface, a registration request to a service provider platform that corresponds to the service provider tool, wherein the registration request comprises service provider registration data that indicates the matching code, a user identifier of the user, and a tool identifier of the service provider tool; receive, using the partner interface, an authentication message that comprises the matching code; and in response to authentication of the user based at least in part on the matching code, (i) generate a UUEK for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) provide, using the partner interface, the UUEK to the partner platform. BRIEF DESCRIPTION OF DRAWINGS

[0012] Having summarized the present disclosure, reference will now be made to the accompanying drawings (which are not necessarily drawn to scale), and in which:

[0013] Figure 1 is an example diagram of a computing ecosystem in accordance with one or more embodiments of the present disclosure;

[0014] Figure 2 is an example schematic diagram of a computing platform in accordance with one or more embodiments of the present disclosure;

[0015] Figure 3 is an example schematic diagram of a client device in accordance with one or more embodiments of the present disclosure;

[0016] Figure 4 is an example block diagram of an example credentialless value exchange system in accordance with one or more embodiments of the present disclosure;

[0017] Figure 5 is an example data diagram for facilitating credentialless value exchange in accordance with one or more embodiments of the present disclosure;

[0018] Figures 6A-6C A process flow for establishing cross-entity relationships in accordance with one or more embodiments of the present disclosure is provided;

[0019] Figures 7A-7D A message flow for establishing cross-entity relationships in accordance with one or more embodiments of the present disclosure is provided;

[0020] Figures 8A-8FAn example interface for establishing cross-entity relationships is provided in accordance with one or more embodiments of the present disclosure;

[0021] Figure 9 A process flow for facilitating credentialless value exchange is provided in accordance with one or more embodiments of the present disclosure;

[0022] Figure 10 A first message flow for facilitating credentialless value exchange is provided in accordance with one or more embodiments of the present disclosure;

[0023] Figure 11 A second message flow for facilitating credentialless value exchange is provided in accordance with one or more embodiments of the present disclosure;

[0024] Figures 12A-12C An example interface for facilitating credentialless value exchange is provided in accordance with one or more embodiments of the present disclosure. DETAILED DESCRIPTION

[0025] Various embodiments of the present disclosure are more fully described below with reference to the figures, which show, by way of illustration, several but not all embodiments of the present disclosure. Indeed, the present disclosure can 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. As used in this document, the conjunction "or" is used to join

[0026] I. OVERVIEW AND TECHNICAL ADVANTAGES

[0027] Various embodiments of the present disclosure provide technical solutions for managing network-based exchanges. In various embodiments, an exchange platform can be configured to facilitate credentialless value exchanges between one or more member platforms. These exchanges can be conducted in real-time without the need for permanent credentials that can expose members to financial, legal, reputational, or other risks. Accordingly, in various embodiments, a client device can purchase, sell, and / or execute value-based exchanges in real-time over any network without exposing sensitive information that is susceptible to network-based attacks.

[0028] Embodiments of the present disclosure provide improved instrument enrollment and exchange processing techniques that leverage interface and data conversion and encryption techniques to improve data security while reducing the computational resource expenditure requirements to protect sensitive data over network communications. For example, some techniques of the present disclosure retrieve data objects and convert them into unique data keys that can only be identified by permitted entities. The data keys can be provided and / or established through the use of exchange interfaces between exchange platforms and other member platforms. Once established, the data keys can be mapped to sensitive credentials stored within a source platform (e.g., a service provider platform) without requiring network transmission of the sensitive credentials. To facilitate value-based exchanges, future communications can be replaced with data keys in place of traditional permanent credentials to enable the source platform to identify the permanent credentials and / or perform one or more operations for the particular instrument associated therewith. In this way, exchange platforms can facilitate exchanges using keys (and / or other identifiers) that cannot themselves be traced back to underlying sensitive information. This in turn enables exchange platforms to comprehensively track, facilitate, and distribute network-based communications without exposing members to network attacks. In this way, the enrollment techniques of the present disclosure provide improved data and network security techniques that can be practically applied to network-based exchanges to securely enroll instruments with exchange platforms.

[0029] In addition to the descriptions above, embodiments of the present disclosure also present network-based exchange processing techniques for facilitating credential-less exchanges. To this end, some of the techniques of the present disclosure leverage a new data structure, the UUEK, which can replace traditional permanent credentials used to authorize value-based exchanges. Using the techniques of the present disclosure, UUEKs can be securely issued across member platforms to allow users to perform value-based exchanges using an identifier that can be identified by a single party, the exchange platform. The UUEKs can be mapped to unique identifiers that can reference sensitive information without directly identifying the sensitive information. For example, the unique identifier can reference a mapping that can only be interpreted by the source platform such that a malicious party unaffiliated with the exchange platform cannot use the identifier. In this way, exchange platforms can distribute, track, and facilitate exchanges without exposing member platforms to data security risks. Furthermore, exchange platforms can continuously update, modify, and / or redistribute UUEKs to member platforms to continuously adapt the UUEKs in real-time. In this way, exchange platforms can provide technical improvements for data and network security while reducing computational resource requirements (e.g., to securely encrypt permanent credentials) to facilitate value-based exchanges.

[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 user registration, (ii) exchange interfaces and network-based communication schemes for improving network security for cross-platform communications, and (iii) ephemeral data structures and data management techniques for distributing ephemeral data structures to facilitate real-time, secure, and dynamic value-based exchanges.

[0031] II. Example Definitions

[0032] In some embodiments, the term“exchange platform” refers to a computing entity configured to facilitate credential-less value exchanges by one or more members of a network. An exchange platform can include one or more processing devices, storage devices, and the like, that are physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks that facilitate agnostic exchanges of a value system. In some examples, an exchange platform can include, define, and / or otherwise utilize one or more application programming interfaces (APIs) to facilitate communications (e.g., requests and responses, and the like) between multiple members. As described herein, APIs can be utilized to facilitate secure exchanges between one or more members of any value system.

[0033] In some embodiments, the term“member” refers to an entity that cooperates with an exchange platform to participate in value exchanges. As examples, a member can include (i) a partner that receives value utilizing an exchange platform, (ii) a service provider that provides value utilizing an exchange platform, and / or (iii) both a partner and a service provider. As used herein, a member can be referred to as a partner when the member receives value through a value exchange, and / or a member can be referred to as a service provider when the member provides value through a value exchange. Thus, the same member can be a partner or a service provider depending on the member’s role in a value exchange. For example, a member can be a partner that accepts value through 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 can use an exchange platform to provide and receive value in a single member value exchange.

[0034] In some embodiments, a member is a partner when the member uses a service provided by a service provider. Partners can include any value-seeking entity in any value system. For example, in a financial value system, partners can include merchants (e.g., retailers, brick-and-mortar stores, etc.) that can use a service provider (e.g., a financial institution) to access funds for financial transactions. Additionally or alternatively, in an information value system, partners can include news publishers (e.g., newspapers, media organizations, etc.) that can use a service provider such as a news agency (e.g., a wire service, a news service, etc.) to access information for information transactions. It can be appreciated that the techniques of the present disclosure can be applied to any value system, and partners can include any value-seeker of any respective value system.

[0035] In some embodiments, a member is a service provider when the member provides a service for a partner. Service providers can include value sources in any value system. For example, in a financial value system, service providers can include financial institutions (e.g., banks, currency exchange platforms, credit unions, etc.) that can provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, service providers can include news agencies (e.g., wire services, news services, etc.) that can provide sources of information for publication by news publishers. It can be appreciated that the techniques of the present disclosure can be applied to any value system, and service providers can include any value source of any respective value system.

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

[0037] 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 can include one or more processing devices, storage devices, and / or the like that are physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks for requesting value in an agnostic exchange of a value system. In some examples, a partner platform can include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses, and / or the like) with an exchange platform. In some examples, a partner platform can be configured to host one or more user-facing applications (e.g., a partner application, and / or the like) for interacting with one or more users.

[0038] 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, a service provider platform can include one or more processing devices, storage devices, and / or the like that are physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks for providing value in an agnostic exchange of a value system. In some examples, a service provider platform can include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses, and / or the like) with an exchange platform. In some examples, a service provider platform can be configured to facilitate one or more service provider tools. In some examples, a service provider platform can be configured to host one or more user-facing applications (e.g., a service provider application, and / or the like) for managing one or more service provider tools.

[0039] 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. An exchange interface can include an API, a file-based interface, a message queue-based interface, and / or the like. For example, an exchange interface can include an API, 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, and / or the like. In some embodiments, an exchange interface can include one or more RPC APIs, such as one or more gRPC APIs.

[0040] The exchange platform can 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 can include a plurality of communication instructions, message definitions, etc. for exchanging requests and / or responses between the exchange platform and entities participating in a value exchange. By way of example, the exchange interfaces can 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.

[0041] In some embodiments, the term“partner interface” refers to an exchange interface for facilitating one or more communications between a partner platform and the exchange platform. The partner interface 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 and the exchange platform. For example, the partner interface can include an API that defines (i) requests from a computing entity acting as a partner platform to the exchange platform and / or (ii) requests from the exchange platform to the partner platform. For example, the partner interface can define one or more registration messages, session messages, transaction messages, etc. that facilitate a value exchange by a partner. In some embodiments, the partner interface defines one or more identifiers for securely identifying one or more portions of a value exchange.

[0042] 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 the exchange platform. The service provider interface can 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 can include an API that defines (i) requests from a computing entity acting as a 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 can define one or more registration messages, session messages, transaction messages, etc. that facilitate a value exchange using a service provider tool. In some embodiments, the service provider interface defines one or more identifiers for securely identifying one or more portions of a value exchange.

[0043] In some embodiments, the term“entity partition” refers to a unique identifier for a computing entity. The entity partition can include a unique number, alphanumeric, etc. that represents a particular computing entity. For example, the entity partition can include a member partition that represents a member platform, a service provider partition that represents a service provider platform, a partner partition that represents a partner platform, etc.

[0044] In some embodiments, the term“service provider partition” refers to a unique identifier of a service provider and / or a service provider platform of the service provider. A service provider partition can include a sequence of numbers, alphanumeric, any / or other any character or symbol that represents a service provider associated with an exchange platform (e.g., joined, registered, etc.). For example, an exchange platform can include a plurality of service provider partitions that each identify a service provider platform associated with (e.g., joined, registered, etc.) the exchange platform. Each service provider partition can represent a service provider platform that has configured one or more exchange platform software development kits (SDKs) or the like to implement a service provider interface of the exchange platform.

[0045] In some embodiments, a“partner partition” refers to a unique identifier of a partner and / or a partner platform of the partner. A partner partition can include a sequence of numbers, alphanumeric, and / or any other character or symbol that represents a partner associated with an exchange platform. For example, an exchange platform can include a plurality of partner partitions that each identify a partner platform associated with (e.g., joined, registered, etc.) the exchange platform. Each partner partition can represent a partner platform that has configured one or more exchange SDKs or the like for implementing a partner interface of the exchange platform.

[0046] In some embodiments, the term“user-facing application” refers to a computer program hosted by a computing entity for facilitating one or more user interactions. A user-facing application can 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 can facilitate communication between a member and a user. As an example, a user-facing application can be configured to present one or more user interfaces to interact with a user on behalf of a member. In some examples, a user-facing application can be configured to receive user input (e.g., via one or more user interfaces) to receive information from a user.

[0047] In some embodiments, a user-facing application is a partner application hosted by a partner platform (e.g., a member platform acting as a partner for a particular exchange, etc.) to facilitate functionality of the partner. A partner application can include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the partner. For example, a partner application can be configured to present one or more user interfaces for interacting with (e.g., browsing, purchasing, viewing, etc.) 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, a partner application can be configured to receive user input (e.g., via one or more user interfaces) to receive information from a user.

[0048] In some embodiments, the user-facing application is a service provider application hosted by a service provider platform (e.g., a member platform acting as a service provider for a particular exchange, etc.) to facilitate functionality of the service provider. The service provider application can include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks for the service provider. For example, the service provider application can be configured to present one or more user interfaces, interact with (e.g., view, manage, audit, register, etc.) one or more service provider tools provided by the service provider. By way of example, in a financial value system, the service provider application can have access to bank accounts, brokerage accounts, lines of credit, etc. to manage funds, assets, etc. handled by the respective accounts. In some examples, the service provider application can be configured to receive user input (e.g., via one or more user interfaces) to receive information, authorization, etc. from the user.

[0049] 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. The service provider tool can depend on the value system and / or the service provider. In some examples, the service provider tool can include an account at the service provider. For example, in a financial value system, the service provider tool can include a bank account (e.g., checking, savings, etc.), a brokerage account, a line of credit, etc. In an information value system, the service provider tool can include a subscriber account, etc. In some examples, the service provider tool can include a virtual tool hosted by the service provider platform.

[0050] In some embodiments, the term “tool data object” refers to 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 one or more tool attributes can be based at least in part on the type of the tool data object. By way of example, a service provider tool can be represented as a member tool data object in a member platform. Additionally or alternatively, the service provider tool can 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 can include one or more of the same one or more tool identifiers and / or one or more tool attributes. By way of example, a member platform can register a plurality of service provider tools with an exchange platform. During registration, the member platform can provide one or more tool identifiers and / or tool attributes, and in some examples, the exchange platform can return another identifier.

[0051] In some embodiments, the member instrument data object is an internal representation of a service provider instrument within a member platform. The member instrument data object can include one or more instrument identifiers, e.g., a member instrument identifier, an instrument 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 instrument data object can include one or more instrument attributes, e.g., an instrument type (e.g., a credit-based instrument, a debit-based instrument, an information-based instrument, etc.), an instrument representation, and / or one or more contextual attributes. In some examples, the contextual attributes can depend on the value system. For example, in a financial value system, the one or more contextual attributes can indicate (i) a currency associated with the service provider instrument, (ii) an asset availability (e.g., a balance, a coverage, etc.) of the service provider instrument, (iii) one or more previous transactions associated with the service provider instrument, etc.

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

[0053] In some embodiments, the term “instrument identifier” refers to any representation of a service provider instrument. As described herein, an instrument identifier can include an instrument identifier, an instrument reference, an instrument key, etc.

[0054] In some embodiments, the term “member instrument identifier” refers to a unique identifier used to represent a service provider instrument within a member platform. For example, a member instrument identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a service provider instrument of a service provider platform.

[0055] In some embodiments, the term“tool reference” refers to a unique identifier used to reference a member tool identifier. For example, a tool reference can be generated and / or provided by a member platform to an exchange platform to allow the exchange platform to reference a tool maintained on 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.

[0056] 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 numbers, alphanumeric, and / or any other characters or symbols that represent a service provider tool to an exchange platform. In some examples, a system tool identifier can include a UUID.

[0057] 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 an exchange platform during the process of onboarding a tool to 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 APIs thereof). The key format can include any number of characters, e.g., fifty characters or more. In certain examples, the characters can be case sensitive. A first portion of the characters (e.g., the first six characters) can be reserved as a partition used to identify an entity associated with the key. For a tool key, the partition can include a service provider partition. A second portion of the characters can identify the system tool identifier. The key format described herein can include one or more different portions, each of which can be arranged in any order.

[0058] 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 numbers, alphanumeric, and / or any other characters or symbols that appear to represent a service provider. The format and / or value of a tool representation can be based at least in part on the type of service provider and / or service provider tool. For example, in a financial value system, a tool reference can include a portion of a permanent credential (e.g., last four digits, etc.), such as an account number (e.g., debit account, credit account, etc.), a financial account name, etc. As another example, in an information value system, a tool reference can include a portion of a permanent credential (e.g., one or more numbers, alphanumeric characters, etc.), such as a subscription account, etc. For example, a tool representation can include a derivative of a permanent credential that can only allow an entity with prior knowledge of the permanent credential to use the tool representation to identify the permanent credential. As another example, a tool representation can include a tool nickname assigned by a user and subsequently identified.

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

[0060] In some embodiments, a user data object includes one or more user identifiers and / or one or more user attributes. In some examples, the one or more user identifiers and / or one or more user attributes can be based at least in part on the type of user data object. By way of example, a user can be represented as a member user data object in a member platform. Additionally or alternatively, a user can 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 can include one or more of the same one or more user identifiers and / or one or more user attributes. By way of example, a member platform can register a plurality of users with an exchange platform. During registration, the member platform can provide one or more user identifiers and / or user attributes, and in some examples, the exchange platform can return another identifier.

[0061] In some embodiments, a member user data object is an internal representation of a user within a member platform. A member tool data object can include one or more user identifiers, e.g., a member user identifier, a user key from an exchange platform, etc. Additionally or alternatively, a member user data object can include one or more user attributes. The one or more user attributes can indicate one or more contextual characteristics for the user. In some examples, a user attribute can indicate one or more identifiable characteristics of a user. By way of example, a user attribute can indicate a user’s first name, last name, email, physical address (e.g., one or more of a street, place, locality, postal code, country, etc.), birth date (e.g., date of birth, age range, etc.), phone number, etc. In some examples, a user attribute can include an encrypted, hashed, and / or other secure representation of an identifiable characteristic of a user. For example, a user attribute can include one or more hashed identifiers of a user, etc.

[0062] In some embodiments, a system user data object is an external representation of a member user within an exchange platform. A system user data object can include one or more user identifiers, e.g., a user reference of a member platform, a system user identifier, etc. Additionally or alternatively, a system user data object can include one or more user attributes, e.g., as described herein. By way of example, a member platform can enroll a user with an exchange platform. During enrollment, the member platform can provide a user reference and / or one or more user attributes of the user. In some examples, a user attribute can include a hashed and / or encrypted identifier of a user.

[0063] In some embodiments, the term “user identifier” refers to a unique identifier of a user involved in a value-based exchange. A user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a user of an exchange platform and / or a member platform. In some examples, a user identifier can include a user reference, a user key, a system user identifier, a member user identifier, etc.

[0064] In some embodiments, the term “system user identifier” refers to a unique identifier that represents a user within an exchange platform. For example, a system user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a user to an exchange platform. In some examples, a system user identifier can include a UUID that is specific to a particular user.

[0065] In some embodiments, the term “member user identifier” refers to a unique identifier that represents a user within a member platform. For example, a member user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a user to a service provider platform.

[0066] 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 and / or provided to an exchange platform by a member 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.

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

[0068] 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, an 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 one or more exchange attributes can be based at least in part on the type of exchange data object. By way of example, an exchange can be represented in a member platform as a member exchange data object. Additionally or alternatively, an exchange can be independently represented by a system exchange data object in the exchange platform. In some examples, a member exchange data object and a system exchange data object can include one or more of the same one or more identifiers and / or one or more exchange attributes. By way of example, using some techniques of the present disclosure, an exchange platform can issue one or more unique identifiers to a member platform that can be used for authorized value exchanges.

[0069] In some embodiments, a system exchange data object is an internal representation of a value exchange using the exchange platform 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.

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

[0071] Additionally or alternatively, a system exchange data object can include a partner-specific exchange data object corresponding to a partner platform. The partner-specific exchange data object 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, and / or the like), and / or the like. Additionally or alternatively, the partner-specific exchange data object can include one or more exchange attributes, such as a deadline date, a currency (e.g., for a financial value system, and / or the like), a tool type, a previous UUEK identifier, and / or the like. In some embodiments, a member exchange data object is an external representation of a value exchange using the exchange platform as an intermediary. The member exchange data object can include one or more identifiers, such as a member exchange identifier, a member tool identifier, a UUEK from the exchange platform, and / or the like.

[0072] In some embodiments, the term“exchange identifier” refers to a unique identifier for a value exchange using the exchange platform. The exchange identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols representing at least a user and / or a service provider tool. In some examples, a unique exchange identifier can include a universally unique identifier (UUID), which can be mapped (e.g., by a series of identifiers, and / or the like) 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 an exchange identifier. For example, an exchange identifier can include random sixteen-byte information generated according to one or more UUID formatting standards (e.g., UUID v4, and / or the like). Thus, while an 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 outside party if there is no prior association between the exchange identifier and one or more other identifiers. In some examples, an exchange identifier can be externally represented by a UUEK.

[0073] In some embodiments, a“Universal Unique Temporary Key” or“UUEK” refers to an external representation of an exchange identifier (e.g., instead of a service provider exchange identifier and / or a partner exchange identifier) that can be issued 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, the exchange platform can generate and issue a UUEK to an external entity. Each UUEK can include a plurality of values (e.g., up to fifty characters and / or more, possibly case sensitive) that represent one or more aspects of a transaction. For example, the plurality of values can indicate an exchange identifier, a partition (e.g., identifying a recipient of the UUEK, etc.), an identifier type, and / or one or more flags. By way of example, a UUEK can include a partner-specific UUEK and / or a service provider-specific UUEK. As described herein, a partner-specific UUEK can be associated with a partner-specific exchange data object, while a service provider-specific UUEK can be associated with a service provider-specific exchange data object.

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

[0075] Additionally or alternatively, at least one character of the key format (e.g., the seventh character) can identify a format of the UUEK. At least another character (e.g., the eighth character) can identify a type of the UUEK. In some examples, a second portion of the characters can identify an exchange identifier (e.g., a set of twenty-two characters following the eighth character). A third portion of the characters can be reserved (e.g., a set of twenty characters following the first portion of the characters). Example representations are provided below:

[0076] ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr

[0077] where p represents a partition character, F represents a format character, i represents an identifier type character, G represents a swap identifier, and r represents a reserved character. The key format allows for 9.8 x 10 to the 84th power unique permutations, which is more than the number of atoms in the observable universe. This enables new UUEKs to be generated and distributed on demand without compromising the security of the underlying data that the UUEKs can map to, such as identifiers of users, tools, and / or any other potentially sensitive information. The key format described herein can include one or more different portions, each of which can be arranged in any order.

[0078] In some embodiments, the term“session identifier” refers to a unique identifier used to identify a series of related message exchanges between a swap platform and an external platform.

[0079] In some embodiments, the term“match code” refers to a session unique identifier used to authorize a registered session between one or more entities. For example, a match code can include a sequence of numbers, alphanumeric, and / or similar characters that can be provided to multiple entities to ensure that each of the multiple entities is involved in the same sequence of communications. By way of example, a match code can include a sequence of eight characters that can be generated by a swap platform, provided to a service provider platform, and then received from a partner platform to ensure that the swap platform, the service provider platform, and the partner platform each interact with the same end user (e.g., by comparing the received match code to a generated match code described herein).

[0080] III. Computer Program Product, Method, and Computing Entity

[0081] Embodiments of the present disclosure can be implemented in a variety of ways, including as a computer program product comprising an article of manufacture. Such a computer program product can comprise one or more software components, including, for example, software objects, methods, data structures, etc. The software components can be coded with any of a variety of programming languages. An illustrative programming language can be a low-level programming language, such as an assembly language associated with a specific hardware architecture and / or operating system platform. Software components comprising assembly language instructions can need to be translated during execution by an assembler into executable machine code. Another example programming language can be a high-level programming language that is portable across multiple architectures. Software components comprising high-level programming language instructions can need to be translated into an intermediate representation during execution by an interpreter or compiler.

[0082] 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 including instructions in one of the above examples of programming languages can be executed directly by an operating system or other software component without having to be first converted into another form. Software components can be stored as files or other data storage structures. Similar types or functionally related software components can be stored together, for example, in a particular directory, folder, or library. Software components can be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified at execution time).

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

[0084] In one embodiment, the non-volatile computer-readable storage medium can include a floppy disk, flexible disk, hard disk, solid-state storage (SSS) (e.g., a solid state drive (SSD), solid state card (SSC), solid state module (SSM), enterprise flash drive, magnetic tape, or any other non-transitory magnetic medium, etc.). The non-volatile computer- readable storage medium can also include a punch card, paper tape, optical mark sheet (or any other physical medium with patterns of holes or other optically recognizable indicia), compact disc read only memory (CD-ROM), compact disc compact disc-rewritable (CD-RW), digital versatile disc (DVD), Blu-ray disc (BD), any other non-transitory optical medium, etc. Such a non-volatile computer-readable storage medium can also include read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory (e.g., Serial, NAND, NOR, etc.), multi-media storage card (MMC), secure digital (SD) memory card, smart media card, compact flash (CF) card, memory stick, etc. Further, a non-volatile computer-readable storage medium can 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.

[0085] In one embodiment, a volatile computer-readable storage medium can 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 two synchronous dynamic random access memory (DDR2 SDRAM), double data rate type three synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), Twin Transistor RAM (TTRAM), Thyristor RAM (T-RAM), Zero-capacitor (Z-RAM), Rambus in-line memory module (RIMM), dual inline memory module (DIMM), single inline memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory, and / or the like. It should be appreciated that where embodiments are described to use a computer-readable storage medium, other types of computer-readable storage media can be substituted or used in addition to or in place of the above-mentioned computer-readable storage media.

[0086] It should be appreciated that various embodiments of the present disclosure can also be implemented as methods, apparatus, systems, computing devices, computing entities, and / or the like. As such, embodiments of the present disclosure can take the form of an apparatus, system, computing device, computing entity, and / or the like executing instructions stored on a computer-readable storage medium to perform certain steps or operations. Thus, embodiments of the present disclosure can also take the form of a completely functional embodiment, a completely software embodiment, and / or an embodiment combining software and hardware elements that perform certain steps or operations.

[0087] Embodiments of this disclosure will now be described with reference to block diagrams, flowcharts, message flows, and other representations of data, operations, and message passing schemes. It should be understood that each block, arrow, etc., in the illustrations, flowcharts, etc., may take the form of a computer program product, a complete hardware embodiment, a combination of hardware and computer program products, and / or an apparatus, system, computing device, computing entity, etc., that executes instructions, operations, steps, and interchangeable similar terms (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium. For example, code retrieval, loading, and execution may be performed sequentially, such that one instruction is retrieved, loaded, and executed once. In some example embodiments, retrieval, loading, and / or execution may run in parallel, such that multiple instructions may be retrieved, loaded, or executed together. Therefore, such embodiments can produce machines that perform specific configurations of steps or operations specified in the representations of this disclosure. Thus, the representations of this disclosure support various combinations of embodiments for performing specified instructions, operations, or steps.

[0088] IV. Example System Architecture

[0089] Figure 1 Illustrations of a computing ecosystem 100 that can be used in conjunction with various embodiments of this disclosure are provided. For example... Figure 1 As shown, the architecture may include an exchange platform 102, one or more client devices 104, a member platform network 110, one or more networks 120, etc. The member platform network 110 may include a first member platform 112a, a second member platform 112b, a third member platform 112c, etc., related to the exchange platform 102 (e.g., registration, etc.). For example, as described herein, the member platform network 110 may include partner platforms and / or service provider platforms. In some examples, a partner platform may include a first member platform 112a, and a service provider platform may include a second member platform 112b, which is different from the first member platform 112a. In some examples, a partner platform and / or service provider platform may include a single member platform (e.g., a third member platform 112c). In some examples, the member platform network 110 may be configured for one or more different services.

[0090] For example, each component in the computing ecosystem 100 can electronically communicate with each other 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, network 120 can include any network connection, including any type of network and / or crossing any geographical boundaries (e.g., connections between countries involving one or more sovereign entities, etc.). Furthermore, although... Figure 1Certain systems are shown as separate, standalone entities, but various embodiments are not limited to this particular architecture.

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

[0092] a. Example Computing Platform

[0093] 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, such as the exchange platform 102, the member platforms 112a-c, etc., can include one or more processing elements 202 (also referred to as processors, processing circuitry, and / or similar terms used herein interchangeably) or be in communication with such processing elements, e.g., the processing elements 202 communicate with other elements within the computing platform 200 via a bus. It can be appreciated that the processing elements 202 can be embodied in a variety of different ways. Figure 1

[0094] For example, the processing elements 202 can be embodied 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. Further, the processing elements 202 can be embodied as one or more other processing devices or circuitry. The term “circuitry” can refer to an entirely hardware embodiment or a combination of hardware and computer program products. Thus, the processing elements 202 can be implemented as integrated circuits, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), hardware accelerators, other circuitry, etc.

[0095] Accordingly, it can be appreciated that the processing elements 202 can be configured for a particular use or configured to execute instructions stored in volatile or non-volatile media or otherwise accessible to the processing elements 202. Thus, whether configured by hardware or computer program products, or by a combination thereof, the processing elements 202 are capable of performing steps or operations according to embodiments of the present disclosure when configured accordingly.

[0096] ​In some embodiments, the computing platform 200 includes or is in communication with a non-volatile memory 204 (also referred to as non-volatile storage, media, memory, memory circuitry, and / or similar terms used herein interchangeably). In some examples, the non-volatile memory 204 can include one or more non-volatile storage or memory media including, but not limited to, a hard disk, ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory card, Memory Stick, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, etc.

[0097] It should be appreciated that the non-volatile memory 204 can store data, databases, database instances, database management systems, files, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, etc. The terms database, database instance, database management system, and / or similar terms used herein interchangeably can 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.).

[0098] In some embodiments, the computing platform 200 includes or is in communication with a volatile memory 206 (also referred to as volatile storage, media, memory, memory circuitry, and / or similar terms used herein interchangeably). In some examples, the volatile memory 206 can include one or more volatile storage or memory 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, cache memory, register memory, etc.

[0099] It should be recognized that volatile memory 206 can be used to store at least a portion of 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., executed by, for example, processing element 202. Therefore, 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 certain aspects of the steps / operations of computing platform 200 with the help of processing element 202 and operating system.

[0100] As described above, in one embodiment, the computing platform 200 may further include one or more network interfaces 208 for communication with various computing entities (e.g., Figure 1 Communication can occur through one or more components, for example, by transmitting, receiving, manipulating, processing, displaying, storing, etc., data, content, information, and / or similar terms used interchangeably herein. Such communication can be performed using wired data transmission protocols, such as Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, Cable Data 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 of a variety of 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 GSM Evolution (EDGE), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolved 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.

[0101] Although not shown, the computing platform 200 can include or be in communication with one or more input elements, such as keyboard input, mouse input, touchscreen / display input, motion input, movement input, audio input, pointing device input, joystick input, keypad input, etc. The computing platform 200 can also include or be in communication with one or more output elements (not shown), such as audio output, video output, screen / display output, motion output, movement output, etc.

[0102] As described above, the computing platform 200 can be an example of one or more components of the Figure 1

[0103] b. Example Client Devices

[0104] Figure 3 is an example schematic diagram of a client device 104 in accordance with one or more embodiments of the present disclosure. The client device 104 can be operated by a variety of entities, and an example computing ecosystem can include one or more client devices 104. For example, the client device 104 can be associated with, owned by, operated by, etc. one or more end users. In various embodiments, the end users of the client device 104 can wish to engage in value exchanges between partners and service providers. As described herein, the users can achieve the above operations by utilizing one or more functional interactions that are provided through user input of the client device 104.

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

[0106] ​The signals provided to and received from the transmitter 304 and the receiver 306, respectively, can include signaling information / data in accordance with air interface standards of applicable wireless systems. In this regard, the client device 104 is capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, the client device 104 can operate in accordance with any of a number of wireless communication standards and protocols, such as those described above with regard to the computing platform 200. In a particular embodiment, the client device 104 can operate in accordance with multiple wireless communication standards and protocols, such as UMTS, CDMA2000, lxRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, and so on. Similarly, the client device 104 can operate over multiple wired communication standards and protocols, such as those described above with regard to the computing platform 200 via the network interface 320.

[0107] Through these communication standards and protocols, the client device 104 can communicate with the computing platform 200 using concepts such as unstructured supplementary service data (USSD), short messaging service (SMS), multimedia messaging service (MMS), dual-tone multi-frequency signaling (DTMF), and / or subscriber identity module dialer (SIM dialer), among others. The client device 104 can also download changes, additions, and updates to its firmware, software (e.g., including executable instructions, applications, program modules), and operating system, for example.

[0108] In some embodiments, the client device 104 includes location-determining aspects, devices, modules, functions, and / or similar words used herein interchangeably. For example, the client device 104 can include outdoor positioning aspects, e.g., a location module adapted to acquire such as latitude, longitude, altitude, geocode, route, direction, heading, speed, universal time (UTC), date, and / or various other information / data. In one embodiment, the location module can acquire 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)). The satellites can be various different satellites, including Low Earth Orbit (LEO) satellite systems, Department of Defense (DOD) satellite systems, the European Union Galileo positioning system, the Chinese BeiDou Navigation System, the Indian Regional Navigational Satellite System, etc. The data can be collected using various coordinate systems, e.g., decimal degrees (DD); degrees, minutes, seconds (DMS); Universal Transverse Mercator (UTM); Universal Polar Stereographic (UPS) coordinate systems, etc. Alternatively, the location information / data can be determined by triangulating the location of the client device 104 in conjunction with various other systems, including cellular towers, Wi-Fi access points, etc. Similarly, the client device 104 can include indoor positioning aspects, e.g., a location module adapted to acquire such as latitude, longitude, altitude, geocode, route, direction, heading, speed, time, date, and / or various other information / data. Some indoor systems can use various location or positioning technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cellular towers, nearby computing devices (e.g., smartphones, laptops), etc. For example, these technologies can include iBeacons, omnidirectional proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, etc. These indoor positioning aspects can be used in various settings to determine the location of a person or thing to within inches or centimeters.

[0109] In some embodiments, the client device 104 can include a user interface 316 (e.g., a display screen coupled to the processing element 308, a speaker, a haptic mechanism, etc.) and / or a user input interface 318 (e.g., a touch screen connected to the processing element 308, a microphone, etc.). For example, the user interface 316 can be one or more application screens presented by one or more computing platforms described herein. The user input interface 318 can include any of a number of devices or interfaces allowing the client device 104 to receive data, such as a keyboard (hard- or soft), a touch display, a voice / speech or motion interface, or other input device. In examples including a keyboard, the keyboard can include (or have accessible) the traditional numeric (0-9) and related keys (#, *), and other keys for operating the client device 104, and can include a full set of alphabetic 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 can also be used to activate or deactivate certain functions, such as screen savers and / or sleep modes, for example.

[0110] The client device 104 can also include volatile memory 322 and / or non-volatile memory 324, which can be embedded and / or removable. For example, the non-volatile memory 324 can be ROM, PROM, EPROM, EEPROM, flash memory, MMCs, SD memory cards, Memory Sticks, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, etc. The volatile memory 322 can 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 memory, register memory, etc. The volatile and non-volatile memories or storage can 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, executable instructions, etc., to implement the functionality of the client device 104. As indicated, this can include partner applications, service provider applications, etc., that reside on the client device 104 and / or are accessible through a browser or other user interface to communicate with the computing platform 200.

[0111] In some embodiments, the client device 104 can include one or more components or functions identical to or similar to components or functions of the computing platform 200, as described in greater detail above. As will be appreciated, the architectures and descriptions provided are for purposes of example only, and are not limiting of various embodiments.

[0112] In various embodiments, the client device 104 can be embodied as an artificial intelligence (AI) computing entity, such as an Amazon Echo, Amazon Echo Dot, Amazon Show, Google Home, etc. Accordingly, the client device 104 can be configured to provide and / or receive information / data to / from an end user via an input / output mechanism (e.g., a display, a camera, a speaker, a voice-activated input, etc.). In certain embodiments, the AI computing entity can include one or more predefined and executable program algorithms stored within an on-board memory storage module and / or accessible over a network. In various embodiments, the AI computing entity can be configured to retrieve and / or execute one or more predefined program algorithms upon occurrence of a predefined triggering event.

[0113] c. Example Network

[0114] In some embodiments, Figure 1 Any two or more of the illustrative components of the computing ecosystem 100 can be configured to communicate with one another via respective communicative couplings of one or more networks 120. The network(s) 120 can include, but are not limited to, any one or a combination of different types of suitable communication networks, such as wired networks, public networks (e.g., the Internet), private networks (e.g., frame relay networks), wireless networks, cellular networks, telephone networks (e.g., the public switched telephone network), or any other suitable private and / or public networks. Moreover, the network(s) 120 can have any suitable communication range associated therewith, and can include, for example, global networks (e.g., the Internet), MANs, WANs, LANs, or PANs. Moreover, the network(s) 120 can include any type of media suitable for carrying desired information, including, but not limited to, coaxial cables, twisted pair wires, optical fibers, hybrid fiber-coaxial cable (HFC) media, microwave terrestrial transceivers, radio frequency communication media, satellite communication media, or any combination thereof, as well as various network devices and computing platforms provided by network providers or other entities.

[0115] d. Example Value Exchange System

[0116] Figure 4is an exemplary block diagram of an exemplary network-based exchange system 400 in accordance with 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, financial-based exchanges, reputation-based exchanges, healthcare-based exchanges, interest-based exchanges, and the like. In any value system, the network-based exchange system 400 can facilitate network-based exchanges between value-seeking entities (e.g., partners) and value-providing entities (e.g., service providers) utilizing intermediary entities and one or more defined communication interfaces, which can be associated with one or more member platforms of the network-based exchange system 400.

[0117] As illustrated, the network-based exchange system 400 can include an exchange platform 102, a partner platform 420, and / or a service provider platform 440, which can be configured to communicate over 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 the network of member platforms 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 platforms 112a and 112b). In some examples, users can interact with one or more platforms through a client device 104.

[0118] In some embodiments, the exchange platform 102 is a computing entity configured to facilitate credential-less value exchanges among one or more members of a network. The exchange platform 102 can include one or more processing devices, storage devices, and the like, which are physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks that facilitate agnostic exchanges of value systems. In some examples, the exchange platform 102 can include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communications (e.g., requests, responses, and the like) among a plurality of members. As described herein, the interfaces can be utilized to facilitate secure exchanges among one or more members of any value system.

[0119] In some embodiments, a member is an entity that partners with the exchange platform 102 to participate in a value exchange. As an example, a member can include (i) a partner that receives value with the exchange platform 102, (ii) a service provider that provides value with the exchange platform 102, and / or (iii) both a partner and a service provider. As used herein, a member can be referred to as a partner when the member receives value through a value exchange, and / or a member can be referred to as a service provider when the member provides value through a value exchange. Accordingly, the same member can be a partner or a service provider depending on the member’s role in a value exchange. For example, a member can be a partner that receives value through 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 can provide and subsequently receive value in a single member value exchange using the exchange platform 102.

[0120] In some embodiments, a member is a partner when the member uses a service provided by a service provider. 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 brick-and-mortar store, etc.) that can use a service provider (e.g., a financial institution) to access funds for a financial transaction. 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 use a service provider such as a news agency (e.g., a wire service, a news service, etc.) to access information for an information transaction. It can be appreciated that the techniques of the present disclosure can be applied to any value system, and a partner can include any value-seeker of any respective value system.

[0121] In some embodiments, a member is a service provider when the member provides a service for a partner. 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 a financial transaction 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 publication by a news publisher. It can be appreciated that the techniques of the present disclosure can be applied to any value system, and a service provider can include any value source of any respective value system.

[0122] Service providers and partners can communicate through one or more member platforms associated with the respective entity. As one example, a service provider can be associated with a service provider platform 440, while a partner can be associated with a partner platform 420.

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

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

[0125] For example, in a financial value system, partner platform 420 can host an online marketplace for a partner that allows users to interact with (e.g., search, browse, purchase, return, etc.) one or more products or services offered by the partner. In the case of purchasing a product, partner platform 420 can cooperate with one or more service providers to access purchase funds. Traditionally, users are required to use a card number, account number, and / or other financial credentials to access funds from a service provider, but this can expose users to malicious attackers. To address cybersecurity and data privacy issues of traditional financial systems (and / or other value-based systems), partner platform 420 can register with exchange platform 102 by configuring one or more software development kits (SDKs), APIs, and / or the like to facilitate communication with exchange platform 102. For example, 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 exchange platform 102.

[0126] In some embodiments, service provider platform 440 is a computing entity configured to perform one or more operations on behalf of a service provider. For example, service provider platform 440 can include one or more processing devices, storage devices, and / or the like that are physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks for providing value in an agnostic exchange of a value system. In some examples, service provider platform 440 can include, implement, and / or otherwise utilize one or more interfaces to facilitate communication (e.g., requests, responses, etc.) with exchange platform 102. In some examples, service provider platform 440 can be configured to facilitate one or more service provider tools. In some examples, 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.

[0127] In some examples, such as in a financial value system, the service provider platform 440 can maintain one or more financial assets (e.g., lines of credit, bank accounts, etc.) to allow users to fund transactions for the purchase of products from partners. If a product purchase occurs, the service provider platform 440 can cooperate with the partner platform 420 to authorize the transaction and / or otherwise provide access to the purchase funds. Traditionally, access to funds at the service provider is facilitated by providing a card number, account number, and / or another financial credential to the service provider platform 440, which can expose the user, service provider, or partner to malicious parties, especially when provided over an unsecured network (e.g., 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 onboard with the exchange platform 102 by configuring one or more software development kits (SDKs), APIs, and / or the like for facilitating communication 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.

[0128] As described herein, the service provider interface 404 can enable the exchange platform 102 to identify and request the use of a service provider instrument to facilitate a transaction. For example, the service provider platform 440 can be configured to facilitate one or more service provider instruments.

[0129] In some embodiments, a service provider instrument is a mechanism used by a service provider to provide value (e.g., on behalf of a particular user, organization, etc.). The service provider instrument can depend on the value system and / or service provider. In some examples, the service provider instrument can include an account at the service provider. For example, in a financial value system, the service provider instrument can include a bank account (e.g., checking, savings, etc.), brokerage account, line of credit, etc. In an information value system, interest value system, etc., the service provider instrument can include a member account, etc. In some examples, the service provider instrument can include a virtual instrument (e.g., virtual account, line of credit, etc.) hosted by the service provider platform 440. For example, the service provider platform 440 can be configured to maintain a plurality of member instrument data objects that indicate a plurality of service provider instruments for a plurality of affiliated entities.

[0130] In some embodiments, a tool data object is a data entity that represents a service provider tool. A 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 based at least in part on a 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 a plurality of service provider tools with the exchange platform 102 (e.g., using service provider interface 404). During registration, the member platform (e.g., service provider platform 440) can provide one or more tool identifiers and / or tool attributes, and in some examples, the exchange platform 102 can return another identifier.

[0131] 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). A member tool data object can include one or more tool identifiers, such as a member tool identifier, a tool key from the exchange platform 102, and / or a user identifier. As described above, for example, a user identifier can include a member user identifier. Additionally or alternatively, a member tool data object can include one or more tool attributes, such as a tool type (e.g., a credit-based tool, a debit-based tool, an information-based tool, etc.), a tool representation, and / or one or more contextual attributes. In some examples, a contextual attribute can depend on a value system. For example, in a financial value system, one or more contextual attributes can indicate (i) a currency associated with a service provider tool, (ii) an asset availability (e.g., a balance, a coverage, etc.) of a service provider tool, (iii) one or more previous transactions associated with a service provider tool, etc.

[0132] 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 a tool reference of a member platform, a system tool identifier, and / or a user identifier. For example, as described herein, 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 a tool type (e.g., a credit-based tool, a debit-based tool, an information-based tool, etc.), a tool representation, and / or one or more contextual attributes. In some examples, the contextual attributes can depend on the value system. For example, in a financial value system, the one or more contextual attributes can indicate a currency associated with the service provider tool.

[0133] In some examples, a member platform, such as the partner platform 420 and / or the service provider platform 440, can be associated with a user-facing application to facilitate one or more interactions with a user and / or other affiliated entities (e.g., through the client device 104).

[0134] In some embodiments, the 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, such as a member platform. For example, the user-facing application can facilitate communication between a member and a user. As an example, the user-facing application can be configured to present one or more user interfaces 406 (e.g., through the client device 104) to interact with a user on behalf of a member. In some examples, the user-facing application can be configured to receive user input (e.g., via the one or more user interfaces 406) to receive information from a user.

[0135] In some embodiments, the user-facing application is a partner application 416 hosted by a partner platform (e.g., a member platform acting as a partner for a particular exchange, etc.) to facilitate the functionality of the partner. The partner application can include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks for the partner. In some examples, the partner application 416 can be configured with one or more devices (e.g., point-of-sale terminals, etc.) from an independent partner institution (e.g., a brick-and-mortar bank, etc.). For example, the partner application 416 can be configured to present one or more user interfaces 406 for interacting with (e.g., browsing, purchasing, viewing, etc.) one or more products offered by a retail-based partner, one or more information units offered by an information-based partner, etc. In some examples, the partner application 418 can be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from a user.

[0136] In some embodiments, the service provider platform 440 is configured to host one or more service provider applications 418 for managing one or more service provider tools. For example, the user-facing application can be a service provider application 418 hosted by a service provider platform 440 (e.g., a member platform acting as a service provider for a particular exchange, etc.) to facilitate the functionality of the service provider. In some examples, the service provider application 418 can be configured with one or more devices from an independent service provider institution (e.g., a brick-and-mortar bank, etc.). The service provider application 418 can include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks for the service provider. For example, the service provider application 418 can be configured to present one or more user interfaces for interacting with (e.g., viewing, managing, auditing, registering, etc.) one or more service provider tools offered by the service provider. By way of example, in a financial value system, the service provider application 418 can have access to bank accounts, brokerage accounts, lines of credit, etc. to manage funds, assets, etc. handled by the respective accounts. In some examples, the service provider application 418 can be configured to receive user input (e.g., via one or more user interfaces 406) to receive information, authorization, etc. from a user.

[0137] In some embodiments, the exchange platform 102 facilitates communication between the partner platform 420 and the service provider platform 440 using one or more exchange interfaces.

[0138] 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 an API, a file-based interface, a message queue-based interface, and the like. For example, the exchange interface can include an API, 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, and the like. In some embodiments, the exchange interface can include one or more RPC APIs, such as one or more gRPC APIs.

[0139] 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 platforms 420, service provider platforms 440, and the like). Each interface can include a plurality of communication instructions, message definitions, and the like for exchanging requests and / or responses between the exchange platform 102 and entities participating in a value exchange. By way of example, the exchange interface can include a partner interface 402 for facilitating communication with the partner platforms 420 and / or a service provider interface 404 for facilitating communication with the service provider platforms 440.

[0140] In some embodiments, the partner interface 402 is an exchange interface for facilitating one or more communications between the partner platforms 420 and the exchange platform 102. The partner interface 402 can define one or more communication instructions, message definitions, and the like to facilitate one or more request messages and / or response messages between the partner platforms 420 and the exchange platform 102. For example, the partner interface 402 can include an API that defines (i) requests from computing entities acting as the partner platforms 420 to the exchange platform 102 and / or (ii) requests from the exchange platform 102 to the partner platforms 420. For example, the partner interface 402 can define one or more enrollment messages, session messages, transaction messages, and the like to facilitate a partner’s value exchange. In some embodiments, the partner interface 402 defines one or more identifiers for securely identifying one or more portions of a value exchange.

[0141] In some embodiments, the service provider interface 404 is an exchange interface for facilitating one or more communications between the service provider platform 440 and the exchange platform 102. The service provider interface 404 can define one or more communication instructions, message definitions, and / or the like to facilitate one or more request messages and / or response messages between the service provider platform 440 and the exchange platform 102. For example, the service provider interface 404 can include an API that defines (i) requests from a computing entity acting as the service provider platform 440 to the exchange platform 102 and / or (ii) requests from the exchange platform 102 to the service provider platform 440. For example, the service provider interface 404 can define one or more enrollment messages, session messages, transaction messages, and / or the like to facilitate a value exchange using the service provider tool. In some embodiments, the service provider interface 404 defines one or more identifiers for securely identifying one or more portions of a value exchange.

[0142] The exchange platform 102 can facilitate communications between a network of member platforms. For example, the network of members can include a plurality of entities that have joined the exchange platform 102, e.g., by enrolling with the exchange platform 102, configuring a respective interface to communicate with the exchange platform 102, and / or the like. In some examples, the exchange platform 102 can execute one or more separate services for interacting with each joined entity. For example, the respective services can include one or more partner services 410 and / or service provider services 412.

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

[0144] In some embodiments, partner services 410 and / or service provider services 412 interact with each other and / or one or more other components of exchange platform 102 through one or more local communication mechanisms to perform exchange operations. For example, exchange platform 102 can include a connection service 408 configured to establish, maintain, and validate secure network sessions with member platforms (e.g., partner platform 420). In some examples, connection service 408 and / or partner services 410 can operate in coordination to register users (and / or service provider tools of users) with exchange platform 102. Additionally or alternatively, partner services 410 and / or service provider services 412 can operate in coordination to register users (and / or service provider tools of users) and / or facilitate value exchanges between partner platform 420 and service provider platform 440. In some examples, connection service 408 can be part of partner services 410.

[0145] By performing one or more exchange operations, partner services 410 and / or service provider services 412 can generate and utilize a plurality of non-traditional identifiers to reference one or more aspects of users, service provider tools, and / or value exchanges. At least some of these identifiers can include universally unique identifiers, such as UUIDs, which can be used to provide credential-less value exchanges. Each identifier can be stored at least temporarily in platform database 414. Platform database 414 can include any type of memory device as described herein. In some examples, each service and / or one or more groups of services can be associated with separate portions of platform database 414.

[0146] As described herein, one or more identifiers can be stored in association with each other to form an identifier map that exchange platform 102 (and / or one or more services thereof) can utilize to reference users, service provider tools, and / or any other aspects of value exchanges from communications between partner platform 420, service provider platform 440, and / or any other member platforms without including user credentials. Reference will now also be made to Figure 5 Examples of non-traditional identifiers are described.

[0147] e. Example Data Structures

[0148] Figure 5is an example data diagram 500 for facilitating credential-less value exchange in accordance with one or more embodiments of the present disclosure. The data diagram 500 illustrates a plurality of related identifiers of different types. As illustrated, each identifier can be associated with at least one related identifier to form an identifier mapping within one or more platforms (e.g., the exchange platform 102 and / or the service provider platform 440). The identifier mapping authorizes communication between the exchange platform 102 and the service provider platform 440 referencing the service provider tool 518 without exposing permanent credentials 514 (e.g., usernames, passwords, card numbers, etc.) associated with the service provider tool 518 that are susceptible to fraud, abuse, and exploitation by malicious parties. As illustrated, using some techniques of the present disclosure, the permanent credentials 514 can never need to be transmitted outside of the service provider platform 440. The data diagram 500 illustrates only some of a plurality of identifiers that can be generated, stored, and / or utilized by various embodiments of the present disclosure. It should be appreciated that the illustrated identifiers are not an exhaustive list and can include other, non-illustrated identifiers. Each identifier can be labeled as an identifier, reference, key, and / or other similar term. These terms are used interchangeably herein to refer to a unit of information used to identify a data structure, entity, and / or any other component described herein.

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

[0150] In some examples, the service provider platform 440 can store one or more identifiers that can map to one or more identifiers of the service provider tools 518 and / or the exchange platform 102 to enable the service provider platform 440 to reference the service provider tools 518 based at least in part on the identifiers that do not themselves indicate any aspect of the service provider tools 518, including its permanent credential 514.

[0151] For example, the service provider platform 440 can store, maintain, and / or otherwise access one or more keys 516 that map to (e.g., are copies of, are derived from, etc.) one or more system identifiers 512 of the exchange platform 102. For example, the keys 516 can include the system identifiers 512 as part of the keys 516. The keys 516 can be mapped to member tool identifiers 508 and / or member user identifiers 522 that can internally reference users of the service provider platform and / or the service provider tools 518. For example, the keys 516 can be provided during a registration process between the service provider platform 440 and / or the exchange platform 102.

[0152] As another example, the exchange platform 102 can store, maintain, and / or otherwise access one or more references that are, for example, tool references 520 and / or user references 502 that map to (e.g., are copies of, are derived from, etc.) one or more member identifiers, such as member tool identifiers 508 and / or member user identifiers 522 of the service provider platform 440. For example, the references can be provided during a registration process between the service provider platform 440 and / or the exchange platform 102.

[0153] In some embodiments, the exchange platform 102 uses one or more entity partitions to reference each member platform of the network of member platforms. In some embodiments, an entity partition is a unique identifier of a computing entity. The entity partition can include a unique number, alphanumeric, etc. that represents a particular computing entity. For example, the entity partition can 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.

[0154] In some embodiments, the service provider partition 504 is a unique identifier of a service provider and / or a service provider platform 440 of the service provider. The service provider partition 504 can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a service provider associated with the exchange platform 102 (e.g., joined, registered, etc.). For example, the exchange platform 102 can include multiple service provider partitions that each identify a service provider platform 440 associated with (e.g., joined, registered, etc.) the exchange platform 102. Each service provider partition 504 can represent a service provider platform 440 that has configured one or more exchange software development kits (SDKs) or the like to implement a service provider interface of the exchange platform 102.

[0155] In some embodiments, the partner partition 506 is a unique identifier of a partner and / or a partner platform of the partner. The partner partition 506 can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent a partner associated with the exchange platform 102. For example, the exchange platform 102 can include multiple partner partitions that each identify a partner platform associated with (e.g., joined, registered, etc.) the exchange platform 102. Each partner partition 506 can represent a partner platform that has configured one or more exchange SDKs or the like for implementing a partner interface of the exchange platform 102.

[0156] In some embodiments, when a member platform joins the exchange platform 102, an entity partition is generated to identify the member. In some examples, after joining the exchange platform, the member platform can utilize one or more exchange interfaces to register one or more service provider tools with the exchange platform 102. The service provider tools 518 are registered with the exchange platform 102 by exchanging one or more tool identifiers with the exchange platform 102.

[0157] In some embodiments, the tool identifier includes any representation of the service provider tool 518 that identifies the service provider tool without exposing the permanent credential 514 of the service provider tool 518. As described herein, the tool identifier can include a member tool identifier 508, a system tool identifier, a tool reference 520, a tool key, or the like.

[0158] 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., a service provider platform 440). For example, the member tool identifier 508 can include a sequence of numbers, alphanumeric, and / or any other characters or symbols for representing 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.

[0159] 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 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 on 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.

[0160] 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 numbers, alphanumeric, and / or any other characters or symbols that represent the service provider tool 518 to the exchange platform 102 without exposing the permanent credential 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.

[0161] In some embodiments, the tool key is a unique identifier for referencing the system tool identifier. For example, the exchange platform 102 can generate and / or provide the tool key during the process of the service provider tool 518 registering 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 APIs thereof). The key format can include any number of characters, e.g., fifty characters or more. In certain examples, the characters can be case sensitive. A first portion of the characters (e.g., the first six characters) can be reserved as a partition for identifying an entity associated with the key. For example, for a tool key, the partition can include the service provider partition 504. A second portion 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 format described herein can include one or more different portions, which can each be arranged in any order.

[0162] In some embodiments, after joining the exchange platform 102, the member platform can utilize one or more exchange interfaces to register one or more users with the exchange platform 102. The users can be registered with the exchange platform 102 by exchanging one or more user identifiers with the exchange platform 102. For example, one or more user data objects reflecting the users of the member platform and / or the exchange platform 102 can be generated, maintained, and / or updated utilizing the user identifiers.

[0163] In some embodiments, a user data object is a data entity that represents a user that interacts with the member platform and / or the exchange platform 102. For example, a user can include an entity (e.g., an individual, an organization, a group, etc.) that participates in a value exchange managed by the exchange platform 102. In some examples, a user can indirectly work with the exchange platform 102 by creating a user account with a registry service provider, registering (and / or giving permission to register) a service provider tool 518, etc. In some examples, the exchange platform 102 can act on behalf of a user without the user directly interacting with the exchange platform 102. For example, the exchange platform 102 can act as a hidden intermediary between a user-facing application and a service provider tool 518 of the user.

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

[0165] In some embodiments, a member user data object is an internal representation of a user within a member platform (e.g., a service provider platform 440). A member tool data object can include one or more user identifiers, such as a member user identifier 522, a user key from the exchange platform 102, etc. Additionally or alternatively, a member user data object can include one or more user attributes. The one or more user attributes can indicate one or more contextual characteristics of the user. In some examples, a user attribute can indicate one or more identifiable characteristics of the user. For example, a user attribute can indicate a first name, a last name, an email, a physical address (e.g., one or more of a street, a location, a region, a zip code, a country, etc.), a birth date (e.g., a date of birth, an age range, etc.), a phone number, etc. of the user. In some examples, a user attribute can include an encrypted, hashed, and / or otherwise securely represented identifiable characteristic of the user. For example, a user attribute can include one or more hashed identifiers of the user, etc.

[0166] In some embodiments, a system user data object is an external representation of a member user within the exchange platform 102. The system user data object can include one or more user identifiers, e.g., a user reference 502 of a member platform, a system user identifier, etc. Additionally or alternatively, the system user data object can include one or more user attributes, e.g., as described herein. For example, a member platform can enroll a user with the exchange platform 102. During enrollment, the member platform can provide the user reference 502 and / or one or more user attributes for the user. In some examples, the user attributes can include a hashed and / or encrypted identifier of the user.

[0167] In some embodiments, a user identifier includes a unique identifier of a user participating in a value-based exchange. The user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols representing a user of the exchange platform 102 and / or a member platform. In some examples, the user identifier can include a user reference 502, a user key, a system user identifier, a member user identifier, etc.

[0168] In some embodiments, a system user identifier is a unique identifier used to represent a user within the exchange platform 102. For example, the system user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols representing a user to the exchange platform 102. In some examples, the system user identifier can include a UUID specific to a particular user. In some examples, the system user identifier can include at least one of the system identifiers 512.

[0169] In some embodiments, a member user identifier 522 is a unique identifier used to represent a user within a member platform. For example, the member user identifier can include a sequence of numbers, alphanumeric, and / or any other characters or symbols representing a user to the service provider platform 440.

[0170] In some embodiments, a user reference 502 can be a unique identifier used to reference a member user identifier 522. For example, the user reference 502 can be generated and / or provided to the exchange platform 102 by a member platform 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.

[0171] In some embodiments, the user key is a unique identifier for referencing a system user identifier. The user key can be generated and / or provided by the exchange platform 102, for example, during a user's enrollment with the exchange platform 102. 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 APIs thereof). For example, the key format can include a first portion of characters (e.g., the first six characters) that can be reserved as a partition for identifying an entity (e.g., a member, etc.) associated with the key. For example, for a user key, the partition can include the service provider partition 504 and / or the partner partition. A second portion of characters can identify the system user identifier.

[0172] As Figure 5 As shown, for example, the user and tool keys described herein can share a key 516 between the exchange platform 102 and the service provider platform 440. Further, in some examples, references such as the tool reference 520 and the user reference 502 can be shared between entities. These identifiers and the mapping schemes described herein allow the exchange platform 102 to reference the service provider tool 518 without needing to know the permanent credential 514 (e.g., card number, etc.) of the service provider tool 518. As described herein, one or more of the key 516 and / or references can be provided to the service provider platform 440 individually or in any combination. In some examples, each of the key 516 and references can be provided to the service provider platform 440 in a redundancy process that allows the service provider platform to verify that the communication was provided by the exchange platform 102 (e.g., an entity with access to the particular set of keys and references, etc.).

[0173] In some embodiments, the permanent credential 514 of the service provider tool 518 includes sensitive user and / or tool credentials, such as a card number, account number, subscription number, etc., that can put the user, member, and / or intermediary entity at risk. The service provider platform 440 can generate, access, and / or otherwise provide the permanent credential 514 to the user when the user applies for, is authorized, and / or is otherwise able to open a new service provider tool 518. Traditionally, the user then uses the permanent credential 514 to initiate a value exchange through the service provider tool. As such, the user is forced to expose sensitive credentials that are directly tied to the service provider tool 518 each time the service provider tool 518 is used. The key 516, reference, and identifier mapping schemes of the present disclosure overcome these technical deficiencies.

[0174] In some examples, each of the identifiers is interpretable for the computing platform (e.g., exchange platform 102 and / or service provider platform 440), but not for the user. To enable the user to select the service provider tool 518 while maintaining the enhanced security features of this disclosure, in some examples, the tool may be used to represent further enhancements. Figure 5 The identifier.

[0175] In some embodiments, the tool represents ( Figure 5 (Not shown) is a unique identifier used to represent service provider tool 518 to a user without exposing the permanent credential 514 of service provider tool 518. For example, the tool representation may include a sequence of numbers, alphanumeric characters, and / or any other characters or symbols that externally represent service provider tool 518 only to entities with prior knowledge of service provider tool 518. The format and / or value of the tool representation may be at least partially based on the type of service provider and / or service provider tool 518. For example, in a financial value system, the tool representation may include a portion of permanent credential 514 (e.g., the last four digits, etc.), such as a card number (e.g., debit card, credit card, etc.), a financial account number, etc. As another example, in an information value system, the tool representation may include a portion of permanent credential 514 (e.g., one or more numbers, alphanumeric characters, etc.), such as a subscription account, etc. For example, the tool representation may include derivatives of permanent credential 514 that may only allow entities with prior knowledge of permanent credential 514 to use the tool representation to identify permanent credential 514. As another example, a tool representation may include a tool nickname assigned by the user and subsequently recognized by the user.

[0176] In some embodiments, a tool representation may be provided to the exchange platform 102 instead of the permanent credential 514 (e.g., during registration). In this way, the exchange platform 102 can use the tool representation to represent the service provider tool 518 without knowing the permanent credential 514 from which the tool representation can be derived. For example, unlike conventional web-based exchange platforms, the exchange platform 102 may not require a permanent credential 514 corresponding to the service provider tool 518 to perform the various computational tasks of this disclosure. This, in turn, allows the exchange platform 102 to operate more flexibly while storing previously undocumented contextual data, reducing not only operational computational costs but also improving the ability of users and the platform to defend against malicious computational entity infiltration attacks.

[0177] In some embodiments, the identifier mapping scheme is supplemented by unique temporary keys issued to member platforms to facilitate secure, real-time value exchanges. For example, the exchange platform 102 can facilitate an additional layer of network and data security by implementing exchange identifiers 510 for representing aspects of value-based exchanges. Some examples of exchange identifiers 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, the service provider-specific exchange identifier can be mapped to a system identifier 512 of 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 a partner platform. For example, the partner-specific exchange identifier can be mapped to a key 516 for the service provider tool 518 that can be used to identify the service provider platform 440. In some examples, such mappings can be defined by exchange data objects.

[0178] 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, an 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 one or more exchange attributes can be based at least in part on the type of exchange data object. By way of example, an exchange can be represented in a member platform as a member exchange data object. Additionally or alternatively, an exchange can be independently represented by a system exchange data object in the exchange platform 102. In some examples, a member exchange data object and a system exchange data object can include one or more of the same one or more identifiers and / or one or more exchange attributes. By way of example, using some techniques of the present disclosure, the exchange platform 102 can issue one or more unique identifiers to a member platform that can be used to authorize a value exchange.

[0179] In some embodiments, a system exchange data object is an internal representation of a value exchange mediated using the exchange platform 102. 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.

[0180] For example, the system exchange data object can include a service provider-specific exchange data object corresponding to the service provider platform 440. The service provider-specific exchange data object can include one or more identifiers, such as the exchange identifier 510, a system identifier 512 (e.g., a system user identifier and / or a system tool identifier), the UUEK 524, and / or the like. Additionally or alternatively, the service provider-specific exchange data object can include one or more exchange attributes, such as a deadline, a currency (e.g., for a financial value system, and / or the like), and / or the like.

[0181] Additionally or alternatively, the system exchange data object can include a partner-specific exchange data object corresponding to the partner platform. The partner-specific exchange data object can include one or more identifiers, such as the exchange identifier 510, one or more keys 516 (e.g., a tool key), the UUEK 524, a member tool reference (e.g., a partner-specific tool reference, and / or the like), and / or the like. Additionally or alternatively, the partner-specific exchange data object can include one or more exchange attributes, such as a deadline, a currency (e.g., for a financial value system, and / or the like), a tool type, and / or the like.

[0182] In some embodiments, the member exchange data object is an external representation of a value exchange mediated using the exchange platform 102. The member exchange data object can include one or more identifiers, such as a member exchange identifier, a member tool identifier 508, the UUEK 524 from the exchange platform 102, and / or the like.

[0183] In some embodiments, the exchange identifier 510 is a unique identifier for value exchanges conducted using the exchange platform 102. The exchange identifier 510 can include a sequence of numbers, alphanumeric, and / or any other characters or symbols that represent at least the user and / or the service provider tool 518. In some examples, the exchange identifier 510 can include a universally unique identifier (UUID) that can be mapped (e.g., by a series of identifiers, etc.) to the user, the service provider tool 518, and / or a member registered with the exchange platform 102. In some examples, the exchange identifier 510 can be generated using one or more UUID generators. 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 platforms for one or more functions, the same exchange identifier 510 will be useless to an outside party unless there is a prior association between the exchange identifier 510 and one or more other identifiers. In addition to the prior identifier association, the exchange identifier 510 can also be associated with the exchange platform 102. Thus, even if the exchange identifier 510 is recognized by a party, the party would still need to impersonate the exchange platform 102 to use the exchange identifier 510. Furthermore, the party would also need to update a settlement account to one owned by the party, as well as perform a number of other tasks before the exchange identifier 510 can be used to their disadvantage. Each of these tasks adds to the amount of work required to overcome the enhanced security layer added by the exchange identifier 510. These tasks can become exceptionally costly and prohibitive when paired with the exchange identifier 510 on a temporary basis.

[0184] In some examples, the exchange identifier 510 can be represented externally by the UUEK 524. By way of example, to facilitate a credential-less 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 permanent credentials 514 by identifying aspects of value exchanges via previously mapped data entities.

[0185] In some embodiments, the UUEK 524 is an external representation of the exchange identifier 510 that can be issued (e.g., in place of the exchange identifier 510) to external entities, such as users, partner platforms, and / or service provider platforms, etc., to initiate a value-based exchange using the exchange platform 102. To this end, the exchange platform 102 can generate and issue the UUEK 524 to external entities. Each UUEK 524 can include a plurality of values (e.g., up to fifty characters and / or more, which can or can not be case sensitive) that represent one or more aspects of a value-based exchange. For example, the plurality of values can indicate the exchange identifier 510, a partition (e.g., identifying a recipient of the UUEK 524, etc.), an identifier type, and / or one or more flags. By way of example, the UUEK 524 can include a partner-specific UUEK and / or a service provider-specific UUEK. As described herein, a partner-specific UUEK can be associated with a partner-specific exchange data object and can include the partner partition 506, while a service provider-specific UUEK can be associated with a service provider-specific exchange data object and can include the service provider partition 504.

[0186] For example, the UUEK 524 can be generated according to a key format. The key format can include a plurality of characters, such as fifty or more characters, which can or can not be case sensitive. A first portion of the characters (e.g., the first six characters) can be reserved as a partition for identifying a 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. By way of example, the UUEK 524 can be issued in response to a request from an authorized member (e.g., related to a partner and / or a service provider).

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

[0188] ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr

[0189] where p represents a partition character, F represents a format character, i represents an identifier type character, G represents an exchange identifier 510, and r represents a reserved character. The key format allows for 9.8 x 10 to the 84th power unique permutations, which is more than the number of atoms in the observable universe. This enables the generation and distribution of new UUEKs 524 on demand without compromising the security of the underlying data, such as identifiers of users, tools, and / or any other potentially sensitive information, to which the UUEKs 524 can map.

[0190] As described herein, the unique sequence of identifiers and mapping scheme between the identifiers can facilitate a credential-less value exchange system for registered and / or unregistered entities. In some examples, one or more identifiers can be generated through a registration or enrollment process configured to establish cross-entity relationships between users, partners, and service provider entities. Reference will now also be made to Figure 6A -C describes an example process for establishing cross-entity relationships.

[0191] V. Example System Operations

[0192] Figure 6A -C provides a process flow for establishing cross-entity relationships in accordance with one or more embodiments of the present disclosure. The process flow illustrates one or more stages of a registration process 600 for registering users and / or service provider tools with an exchange platform to facilitate credential-less value exchanges between partner platforms and service provider platforms. For purposes of explanation, Figure 6A -C illustrates an example process 600. Although the example process 600 describes a particular sequence of steps / operations, this sequence can be altered without departing from the scope of the present disclosure. For example, some of the described steps / operations can be performed in parallel or in a different order without substantially affecting the functionality of the process 600. In other examples, different components of an example device or system implementing the process 600 can perform this functionality substantially simultaneously or in a particular order.

[0193] Various embodiments of the process 600 address technical challenges related to data security and efficiency of network-based exchanges in value exchanges between one or more computing entities. Conventional systems address these challenges using a registration mechanism that requires users to disclose sensitive and permanent credentials to a third party. These conventional registration services then verify the user’s account ownership and provide the permanent credentials to partner platforms for storage and subsequent processing. By doing so, user credentials are transmitted and exposed to multiple different entities during conventional registration processes, ultimately increasing the risk of exposure to malicious parties during and after network communications. Various embodiments of the process 600 provide improved network communication, data encryption, and data management techniques to enable credential-less exchange registration capabilities, thereby reducing data security risks associated with conventional processes.

[0194] One or more embodiments of the process 600 can be implemented by one or more computing devices, entities, and / or systems described herein. For example, via various steps / operations of the process 600, the exchange platform 102 can leverage credential-less registration techniques to overcome various limitations of conventional registration mechanisms by registering service provider tools with partner platforms without accessing permanent credentials of the service provider tools. In this way, sensitive information behind service provider tools participating in value exchanges is never exposed to potentially malicious parties or partner platforms that can be vulnerable to network-based attacks. For example, unlike conventional techniques, the exchange platform 102 never receives identifiable or actionable account information of users, and the service provider managing the account participates in the registration process rather than being intermediated by potentially insecure registration services. This, in turn, eliminates the need to implement resource data governance standards on each device involved in the registration process, thereby ultimately improving computing resource utilization while enhancing network and data security.

[0195] Figure 6A is a flowchart illustrating an example of a first stage of a registration process 600 for registering a user with an exchange platform without exposing permanent credentials associated with the user and / or service provider tools. The flowchart describes communication techniques that overcome various limitations of conventional registration systems by circumventing reliance on sensitive and permanent credentials by conventional systems. The communication techniques can be implemented by one or more computing devices, entities, and / or systems described herein (e.g., an exchange platform that establishes a secure communication session with a user via a partner application).

[0196] In some embodiments, the process 600 includes establishing a registration session for the user and the partner platform at step / operation 602. For example, the registration process 600 can begin on a partner application (e.g., a partner website, a user application, etc.), at which time the partner platform can allow the user to register for a partner account on the partner application with the exchange platform in order to access the service provider tool. The partner platform can enable the registration of the user by initiating a registration session with the exchange platform.

[0197] For example, as described herein, a user can access a partner application via a client device through a portal (e.g., a browser, a web application, etc.). The user browser, web application, mobile application, etc. can fetch a platform connection widget from a content delivery network (CDN) and issue a communication session request to the partner platform to establish a registration session. In response to the request, the partner platform can generate (e.g., using one or more exchange interfaces, etc.) a communication session request to the exchange platform (e.g., its partner service). The communication session request can include an API request provided through the partner interface to initiate a registration widget to establish a registration session for the user.

[0198] In some embodiments, the communication session request includes one or more registration attributes, such as user data, a user identifier, a user hash, a timestamp, a device identifier, a partner identifier, etc. As described herein, some techniques of the present disclosure enable a computing entity to use an identifier to identify a service provider tool without including a permanent credential for the service provider tool in the communication session request. For example, the partner platform can be configured to fetch user data for the user (e.g., through user input to a user interface screen, pre-recorded data from a partner account, etc.) and provide the user data to the exchange platform to begin the registration process. In some examples, the partner platform (e.g., through one or more API calls of the partner interface, etc.) can provide the user data to the exchange platform (e.g., its partner service) with the communication session request to initialize the widget session. In some examples, the user data can be encrypted, hashed, etc. prior to transmission to the exchange platform. In some examples, the user data can include one or more user attributes as described herein.

[0199] In some embodiments, the exchange platform (e.g., its partner service) receives the communication session request using the partner interface to initialize a registration session on the user’s client device. In some examples, the communication session request can include user data for the user. Additionally or alternatively, the registration initialization request can include one or more user attributes for the user. In some examples, the user attributes can be encrypted and / or hashed as described herein.

[0200] In some embodiments, the process 600 includes setting user and partner data at step / operation 604. For example, the exchange platform (e.g., its connection service, partner service, etc.) can identify and / or generate user and / or partner data from data provided in the communication session request. In some examples, the user data can include one or more user attributes. In some examples, the user data can include one or more encrypted and / or hashed user attributes. In some examples, the partner data can include a shared identifier between the exchange platform and the partner platform, such as the partner partition described herein.

[0201] In some embodiments, the process 600 includes generating a session identifier for the registration session at step / operation 606. For example, the exchange platform (e.g., its connection service, partner service, etc.) can generate a session identifier for a communication session between the partner platform and the exchange platform to track communications exchanged during the registration session. For example, the session identifier can include a unique number, string, etc., for authenticating information exchanged during the registration session process. The exchange platform can utilize the connection service and / or the partner service to establish the registration session. For example, in response to the registration initialization request, the partner service can call another service, such as the connection service, to establish a communication session that can be used by the client-side widget to provide an interface between the user and the partner service to complete user registration. The connection service can generate the session identifier and return the session identifier to the partner service. The partner service can return the session identifier to the partner platform, which can utilize the session identifier to initialize the client-side widget through an instance of the partner application on the client device. Once the partner application receives the session identifier, the partner application can launch (e.g., execute, initialize, etc.) the client-side widget. The user can then interact with the widget to complete the registration process 600.

[0202] In some embodiments, the process 600 includes determining and providing a member list for the user at step / operation 608. The member list can be a service provider list. For example, the exchange platform (e.g., its connection service, partner service, etc.) can determine a service provider list for the user from a network of service providers associated with (e.g., registered with, etc.) the exchange platform. In some examples, the service provider list can include each service provider platform associated with the exchange platform. Additionally or alternatively, the service provider list can include a subset of the associated service provider platforms tailored for the user.

[0203] For example, the exchange platform can determine one or more service provider platforms based at least in part on a user attribute of the registered session, and customize the service provider list for the one or more service provider platforms. For example, the exchange platform can include a plurality of system user data objects and / or system tool data objects, as described herein. In some examples, the exchange platform can identify one or more system user data objects corresponding to the user based at least in part on the user attribute. In some examples, each system user data object can identify a service provider platform related to the user. In this way, the exchange platform can determine one or more service providers related to the user based at least in part on the one or more system user data objects.

[0204] Additionally or alternatively, the exchange platform (e.g., one or more service provider services thereof) can provide a presence request for user presence data from each service provider platform in the network of member platforms (e.g., through a service provider interface). The user presence request can include one or more user attributes of the user (e.g., encrypted attributes, hashed attributes, etc.) that the service provider platforms can utilize to determine whether the user has a tool of the service provider platform. In response to the request, the exchange platform (e.g., one or more service provider services thereof) can receive presence data from one or more of the service provider platforms indicating the presence of a tool on the respective service provider platform. The exchange platform (e.g., a partner service thereof) can determine one or more service providers based at least in part on the presence data.

[0205] In some examples, the exchange platform (e.g., a connection service, a partner service, etc. thereof) can initiate presentation of a pre-registration screen based at least in part on the one or more service providers using a partner interface and via a registration user interface provided by a partner application. For example, the client device can be configured to access a partner application hosted by a partner platform. The registration user interface can be presented to the user on the client device through a widget in the partner application. The widget can be defined internally by the partner or provided by the exchange platform. The pre-registration screen can present a plurality of selectable icons indicative of the service provider list.

[0206] Next, the registration process 600 can continue to a second stage, at which a tool identifier corresponding to the user is identified through interactions between the exchange platform, the user, and the service provider platform, as described in further detail below. Figure 6B Further details of the identification of the tool identifier corresponding to the user through interactions between the exchange platform, the user, and the service provider platform are described below.

[0207] Reference is now made to Figure 6B , Figure 6BTo show a flowchart of an example of a second stage of a registration process 600 for registering a service provider tool with a partner platform without exposing permanent credentials associated with a user and / or the service provider tool. The flowchart describes communication techniques to overcome various limitations of traditional registration systems by circumventing reliance on permanent credentials (e.g., card numbers, etc.) provided to users by traditional systems. These communication techniques can be implemented by one or more computing devices, entities, and / or systems described herein (e.g., an exchange platform) to establish a connection between a user, a partner platform, and a service provider tool.

[0208] In some embodiments, the process 600 includes determining and providing a list of service provider tools for the user at step / operation 610. The list of service provider tools can be determined based at least in part on a selection of a service provider from the pre-registration screen. For example, in some examples, the exchange platform (e.g., its connection service, partner service, etc.) can receive preselection data using the partner interface, the preselection data indicating a selection of a particular service provider from one or more service providers presented in the pre-registration screen. For example, the widget can receive the preselection data from the partner application and provide a tool registration request (e.g., via the partner interface) to the exchange platform (e.g., its connection service, partner service, etc.). The tool registration request can include a session identifier and / or a service provider identifier indicating the selected service provider.

[0209] In response to the request, the exchange platform (e.g., its connection service, partner service, etc.) can receive service provider-tool data based at least in part on the preselection data. The service provider-tool data can indicate one or more service provider tools provided by the selected service provider platform for the user. For example, the service provider-tool data can include one or more system tool identifiers and / or respective tool representations from one or more tool data objects corresponding to the service provider and the user. For example, each of the tool data objects can include a system user identifier corresponding to the user.

[0210] Additionally or alternatively, the exchange platform (e.g., one or more service provider services thereof) can provide a tool request for the service provider-tool data from the selected service provider platform (e.g., through the service provider interface). For example, the tool request can include a user reference corresponding to a member user identifier of the service provider platform. In response to the request, the service provider platform can identify one or more member tool data objects including the member user identifier, identify one or more tool references corresponding to the one or more member tool data objects, and provide service provider-tool data indicating the one or more tool references and / or one or more respective tool representations to the exchange platform.

[0211] The exchange platform (e.g., its connection service, partner service, etc.) can use the partner interface and, via the registered user interface, initiate presentation of a tool registration screen via the user’s client device based at least in part on the service provider-tool data. The tool registration screen can be defined internally by the partner and / or provided by the exchange platform. For example, the tool registration screen can indicate one or more service provider tools associated with the user and the selected service provider. By way of example, the tool registration screen can indicate a respective tool representation for each of the one or more service provider tools. In some examples, e.g., when the user is associated with only a single service provider tool, the tool registration screen can include a confirmation prompt to confirm the user’s intent to register the service provider tool.

[0212] In some embodiments, the process 600 includes receiving selection data at step / operation 612. For example, the selection data can indicate a selection of a service provider tool from the registered user interface. For example, the selection data can identify the service provider tool from the list of service provider tools associated with the user. Additionally or alternatively, the selection data can indicate a confirmation of a single service provider tool associated with the user.

[0213] For example, the exchange platform can use the partner interface to receive a sign-in tool with an account request from the client-side widget. The request can include selection data and / or a session identifier. The selection data can indicate a selection of a service provider tool from the registered user interface. For example, the selection data can indicate a tool representation (e.g., last four digits of an account, an account nickname, etc.) of the selected service provider tool. In some examples, the selection data can include at least one of a tool type corresponding to the selection, a currency type (e.g., in a financial value system), and / or a tool identifier (e.g., a tool representation, etc.).

[0214] In some embodiments, the client-side widget can be configured to authenticate the user prior to initiating the sign-in tool with the account request. For example, the client-side widget can be configured to generate a user verification prompt based at least in part on the user data. The user verification prompt indicates a confirmation request for at least a portion of the user data. In some examples, the widget can be configured to present the user verification prompt to the user. In some embodiments, the exchange platform can use the partner interface to initiate presentation of the user verification prompt. In response to user input indicating a confirmation of at least a portion of the user data (e.g., one or more user attributes, etc.), the widget can provide the sign-in tool with the account request to the exchange platform.

[0215] In some embodiments, the process 600 includes generating a match code at step / operation 614. In some examples, the exchange platform (e.g., its connection service, partner service, etc.) can generate the match code. In some examples, the match code can be generated in response to a user input indicating confirmation of at least a portion of the user data and / or a registration tool with the account request indicating the confirmation. The exchange platform (e.g., its connection service, partner service, etc.) can generate the match code for authenticating the user.

[0216] In some embodiments, the match code is a session unique identifier for authorizing a registration session between one or more entities. For example, the match code can include a sequence of numbers, alphanumeric, and / or similar characters that can be provided to the multiple entities to ensure that each of the multiple entities is involved in the same sequence of communications. By way of example, the match code can include a sequence of one or more different characters of a dynamic length (e.g., six, eight characters, etc.) 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 each interact with the same end user (e.g., by comparing the received match code to the generated match code described herein). The one or more different characters can include one or more alphanumeric, emoji, Hanzi, wingdings, etc.

[0217] In some embodiments, the process 600 includes providing a registration request with the match code to a service provider platform corresponding to the service provider tool at step / operation 616. For example, the exchange platform (e.g., its service provider service, etc.) can provide a registration request to the service provider platform corresponding to the service provider tool using a service provider interface. The registration request can include service provider registration data indicating the match code, one or more user identifiers of the user, and / or one or more tool identifiers of the service provider tool. In response to the registration request, the service provider platform can use the one or more identifiers to verify the service provider tool.

[0218] For example, the service provider registration data can include one or more identifiers for referencing the service provider tool in communications between the exchange platform, the service provider platform, and / or the partner platform without using a permanent credential (e.g., a card number, an account number, etc.) of the service provider tool. For example, the one or more identifiers can include various combinations of a user identifier and / or a tool identifier to verify the user and / or the tool through one or more redundant checks. For example, a user identifier of a user can include a user reference of the service provider platform and / or a user key from the exchange platform corresponding to the user reference. As another example, a tool identifier of a service provider tool can include a tool reference of the service provider platform and / or a tool key from the exchange platform corresponding to the tool reference.

[0219] The service provider registration data can include any combination of the references, keys, and / or identifiers described herein. In one example, the service provider registration data can include one of a tool reference, a tool key, a user reference, and / or a user key. Additionally or alternatively, the service provider registration data can include a combination of tool references, tool keys, user references, and user keys corresponding to built-in redundancies. In some examples, the combination of identifiers can be specified by the interface call. The combination can be service provider specific and / or dynamically changed according to the communication scheme. In this way, the particular combination of identifiers provided in the registration request can be used as an additional verification check to ensure that the registration request was received from the relevant platform (e.g., the exchange platform).

[0220] The service provider can compare the identifiers from the registration request to one or more member data objects (e.g., a member tool data object, a member user data object, etc.) to identify the service provider tool corresponding to the registration request without exposing a permanent credential of the service provider tool.

[0221] In some embodiments, the process 600 includes receiving a matching code from the partner platform at step / operation 618. For example, the exchange platform can receive an authentication message including the matching code and / or the session identifier using the partner API. The authentication message can be received from the partner platform in response to input by the user to the registration user interface.

[0222] The exchange platform can compare the matching code to a previously generated matching code to authenticate the user. For example, the service provider platform can be configured to provide the matching code to the user through one or more pre-existing communication protocols between the service provider platform and the user (e.g., via the service provider application, a registered phone number, an email address, etc.). In the case that the exchange platform receives the matching code from the partner platform, the exchange platform can authenticate that the user interacting with the partner platform is an authorized user of the service provider.

[0223] In some examples, the exchange platform can initiate presentation of the authentication user screen using the partner interface and through the enrollment user interface. Substantially concurrently, the service provider platform can provide the matching code to the user (e.g., via the client device and / or other preconfigured means). The user can enter the matching code (e.g., received from the service provider platform) through the authentication user screen, and the partner platform can forward the matching code to the exchange platform. The exchange platform can receive, using the partner interface, an authentication message based at least in part on user input to the authentication user screen.

[0224] In some embodiments, the exchange platform authenticates the enrollment session in response to authentication of the user based at least in part on the matching code. As referenced above, the exchange platform can use the partner interface to receive the authentication message from the partner platform. Figure 6C As described in additional detail below, upon successful enrollment, control is passed back to the partner application running on the client device, which requests the UUEK.

[0225] Reference is now made to Figure 6C , Figure 6C is a flow diagram showing an example of a third stage of the enrollment process 600 for the issuance of a UUEK to facilitate a credential-less exchange of value. The flow diagram describes a communication technique that overcomes various limitations of traditional enrollment systems by circumventing reliance on a tool reference (e.g., a card number, etc.) provided to a user by a traditional system. The communication technique can be implemented by one or more computing devices, entities, and / or systems described herein (e.g., an exchange platform) to establish a user tool record for enrolling a user with an exchange platform.

[0226] In some embodiments, the process 600 includes verifying the enrollment session based at least in part on the session identifier at step / operation 620. For example, the exchange platform can receive, via the partner interface, a session exchange request that exchanges the session identifier for the UUEK. The session exchange request can include the session identifier and a member tool reference of the service provider tool. The member tool reference can include a partner-specific reference of the service provider tool. The exchange platform (e.g., a partner service thereof) can receive the session exchange request, verify the session identifier (e.g., via a connection service, a partner service, etc. thereof) by comparing the session identifier to a previously generated session identifier, and verify the enrollment session in response to a match.

[0227] In some embodiments, the process 600 includes generating the UUEK at step / operation 622. For example, the exchange platform can generate the UUEK in response to validation of the registration session. For example, the exchange platform can generate the UUEK corresponding to the user, the service provider tool, and the partner platform. As described herein, the exchange platform can store the UUEK in a partner-specific exchange data object that associates the UUEK with the exchange identifier, the tool key, and the partner-specific tool reference.

[0228] In some embodiments, the process 600 includes providing the UUEK to the partner platform at step / operation 624. For example, the exchange platform can provide data indicative of the UUEK to the partner platform using the partner interface. In some examples, the partner platform can provide the UUEK and / or a representation thereof (e.g., for storage in a virtual wallet, etc.) to the user. By way of example, the UUEK can be represented in one or more different forms, such as a machine-readable optical image (e.g., a barcode, a quick response code, etc.), a keyword, a virtual widget, etc.

[0229] Figure 7A - provides an illustration of the steps / operations related to establishing a cross-entity relationship with Figure 6A - C. It should be appreciated that these steps / operations can be performed in accordance with the respective steps / operations of Figure 6A - C. Generally, as illustrated in Figure 7A - B, the steps / operations for establishing a secure communication session with the user via the partner application can be applicable to the steps / operations of Figure 6A and / or related to the steps / operations of Figure 6A For example, Figure 7A The steps / operations illustrated in

[0230] At step / operation 702, the partner application 416 obtains a widget (e.g., a set of instructions such as a javascript widget) from the connection service 408. At step / operation 704, the connection service 408 returns the widget and creates a session. In various embodiments, the step / operation 704 is performed in response to the step / operation 702.

[0231] At step / operation 706, the partner application 416 initializes the widget using the partner platform 420 (e.g., host, etc.). At step / operation 708, the partner platform 420 initializes the widget by calling a widget initialization function of the partner service 410 using the partner interface (e.g., initialize widget call, etc.). In some examples, the widget initialization call can include user data (e.g., one or more user attributes). At step / operation 710, the partner service 410 retrieves and initializes the widget by calling the connection service 408 using the partner interface (e.g., initialize widget call, etc.). In various embodiments, step / operation 710 is performed in response to step / operation 708.

[0232] At step / operation 712, the connection service 408 stores a partner identifier corresponding to the partner of the partner platform 420. At step / operation 714, the connection service 408 stores user data for the user. At step / operation 716, the connection service 408 generates a session identifier for identifying a communication session between the partner and the exchange platform. At step / operation 718, the connection service 408 provides the session identifier to the partner service 410. At step / operation 720, the partner service 410 returns the session identifier to the partner platform 420. And, at step / operation 722, the partner platform 420 returns the session identifier to the partner application 416. In various embodiments, the communication session can be initialized when step / operation 722 is performed.

[0233] Turning to Figure 7B At step / operation 728, the partner application 416 executes the widget 724 and hands over control to the widget 724 to continue the registration process. The widget 724 is provided with the session identifier and the user data. At step / operation 730, the widget 724 sets the session identifier. At step / operation 732, the widget 724 sets the user data. At step / operation 734, the widget 724 requests a public key from the connection service 408 using the partner interface. At step / operation 736, the connection service 408 returns the public key to the widget 724. At step / operation 738, the widget 724 requests a list of service providers from the connection service 408 using the partner interface. And, at step / operation 740, the connection service 408 returns the list of service providers. In some examples, at step / operation 742, the widget 724 returns the list of service providers to the partner application 416 for presentation to the user (e.g., via the client device).

[0234] Turning to Figure 7C After the secure communication session is established with the partner application, the registration process can continue to the second phase, which is illustrated by the steps / operations of Figure 7C Generally, Figure 7CThe steps / operations shown in FIG. 6 can be adapted and / or related to the steps / operations of Figure 6B The steps / operations shown in FIG. 6 can be adapted and / or related to the steps / operations of Figure 7C The steps / operations shown in FIG. 6 can be adapted and / or related to certain operations of the second phase of the registration process 600 for registering a service provider tool with a partner platform without exposing permanent credentials associated with a user and / or the service provider tool.

[0235] At step / operation 744, the partner application 416 receives input indicating a service provider of the service provider list and sends a service provider identifier to the widget 724. At step / operation 746, the widget 724 sends a request to the connection service 408 using the partner interface (e.g., widget registration tool initiate call, etc.) to initiate registration of a service provider tool of the service provider platform. The request can include the service provider identifier (e.g., service provider partition, etc.). At step / operation 748, the connection service 408 requests a list of tools corresponding to the user and the service provider using the partner interface (e.g., widget registration tool initiate call, etc.). At step / operation 750, the service provider service 412 returns the list of tools to the connection service 408. At step / operation 752, the connection service 408 returns the list of tools to the widget 724, which can provide a pre-registration screen to the user indicating the list of tools (e.g., one or more tool representations thereof).

[0236] At step / operation 754, the widget 724 receives input indicating a service provider tool (e.g., a tool representation, etc.). At step / operation 756, the widget 724 confirms user data with the user (e.g., through one or more user verification screens, etc.). At step / operation 758, the widget 724 provides a request to register the service provider tool with the connection service 408 using the partner interface (e.g., widget registration tool with account call, etc.). In various embodiments, step / operation 758 is performed in response to confirmation of the user data at step / operation 756.

[0237] At step / operation 760, the connection service 408 generates a match code. At step / operation 762, the connection service 408 provides a request to register the service provider tool with the service provider service 412 using the partner interface (e.g., widget registration tool with account call, etc.). The request can include the match code and the session identifier. At step / operation 764, the service provider service 412 provides a request to register the service provider tool with the service provider platform 440 using the service provider interface (e.g., register user tool call, etc.). The request can include the tool reference, the user reference, the user key, the tool key, and / or the match code. The service provider platform 440 can register the service provider tool, and at step / operation 766, provide a registration success response to the service provider service 412 using the service provider interface. At step / operation 768, the service provider service 412 provides data to the connection service 408 indicating the registration success response. At step / operation 770, the connection service 408 provides data to the widget 724 indicating the registration success response.

[0238] Meanwhile, at step / operation 772, the service provider platform 440 provides the match code to the user using one or more pre-existing communication channels. The user can access the match code, and at step / operation 774, enter the match code into the verification interface presented by the widget 724.

[0239] At step / operation 776, the widget 724 provides a registration complete response to the connection service 408 using the partner interface. In various embodiments, step / operation 776 is performed in response to confirmation of the match code provided at step / operation 774.

[0240] At step / operation 778, the connection service 408 provides a response to the widget 724 indicating successful registration. At step / operation 780, the widget 724 provides data to the partner application 416 indicating the response.

[0241] Turning to Figure 7D , after the user is authorized based at least in part on confirmation of the match code as described above, the registration process can continue to a third phase as shown by the steps / operations of Figure 7D . Generally, Figure 7D , the steps / operations shown in Figure 6C may be suitable and / or related to certain operations of the third phase of the registration process 600 for registering the service provider tool with the partner platform without exposing permanent credentials related to the user and / or the service provider tool. Figure 7D

[0242] ​In step / operation 782, the partner application 416 provides data indicating successful registration to the partner platform 420. In step / operation 784, the partner platform 420 provides a key request to the partner service 410 using the partner interface. In step / operation 786, the partner service 410 verifies the communication session by providing a session identifier to the connection service 408. The connection service 408 compares the session identifier with an identifier issued for initiating the communication session, and if the identifiers match, in step / operation 788, provides data indicating the verified session to the partner service 410.

[0243] In step / operation 790, the partner service 410 generates a UUEK for the partner and exchanges the UUEK for a session identifier. In step / operation 792, the partner service 410 provides the UUEK to the partner platform 420 using the partner interface. In step / operation 794, the partner platform 420 may provide a successful registration indication to the partner application 416. In some examples, the successful registration indication may include a UUEK representation, such as a barcode, QR code, and / or similar representations used to indicate the UUEK to the user.

[0244] Therefore, after describing various operations, processes, methods, functions, etc., for registered users to perform credentialless exchange, various user interface screens for controlling, initiating, executing, and / or similar steps / operations are provided and described. In various embodiments, the user interface screens provided and described in this disclosure are configured to be provided via the user interface of client device 104.

[0245] Figure 8A The `-F` option provides a sample user interface flow configured for client device 104. This flow can include multiple user interface screens that can be configured to guide the user through a credentialless registration process, facilitating credentialless exchange between the partner platform and the service provider platform. In some examples, these transactions can be managed through the user account on the partner platform. For example, Figure 8A The user interface screen 802 includes an account settings screen for entering user attributes 804 for a user account. The user interface screen 802 may include a selectable account creation icon 806 for initiating the account creation process. Additionally or alternatively, users can register with a partner platform via an exchange screen. For example, Figure 8B The user interface screen 808 includes a registration settings screen for entering one or more user attributes 804 via a widget executed by the partner application. Figure 8B The user interface screen 808 may include an optional registration navigation 810 for continuing to the next step of the registration process.

[0246] The steps of the registration process can include selecting a service provider, the user has a service provider tool that can be registered with the partner platform. Figure 8C User interface screen 812 can facilitate the selection of a service provider by providing a list of service providers 814 of selectable icons. In some examples, the list of service providers 814 can be automatically matched to the user attributes available to the user (e.g., provided through one or more previous user interface screens). For example, the list of service providers 814 can be customized for the user and, in some examples, can be actively limited to service providers associated with the user. As shown by user interface screen 812, the service providers can include financial institutions (e.g., banks, etc.) that facilitate value exchanges based on finance. This is provided as just one example. As described herein, the techniques of the present disclosure can be applied to any value exchange system.

[0247] Upon selecting a service provider, the user can be directed to another user interface screen (not shown) for selecting a service provider tool of the service provider. Once selected, the exchange platform can perform a registration process to register the service provider tool with the partner platform. During the registration process, the user can be transitioned to Figure 8D User interface screen 816, which can include a verification prompt 818 for entering a matching code. As shown by user interface screen 820, the matching code can be automatically provided to the user through information 822 from the service provider platform. The user can answer the verification prompt 818 by entering the matching code and select a submit icon 824 to complete the registration process. The next screen, user interface screen 826, can display a UUEK representation 828 of the UUEK for the user. For example, the UUEK representation 828 can include a scannable representation of the UUEK (e.g., a barcode, QR code, non-replaceable token, near field communication sequence, etc.). The scannable representation can be saved to the partner account of the partner platform to enable the user to perform value-based transactions using the service provider tool without having to reference permanent credentials of the service provider tool. Figure 8E User interface screen 820, the matching code can be automatically provided to the user through information 822 from the service provider platform. The user can answer the verification prompt 818 by entering the matching code and select a submit icon 824 to complete the registration process. The next screen, user interface screen 826, can display a UUEK representation 828 of the UUEK for the user. For example, the UUEK representation 828 can include a scannable representation of the UUEK (e.g., a barcode, QR code, non-replaceable token, near field communication sequence, etc.). The scannable representation can be saved to the partner account of the partner platform to enable the user to perform value-based transactions using the service provider tool without having to reference permanent credentials of the service provider tool. Figure 8F User interface screen 820, the matching code can be automatically provided to the user through information 822 from the service provider platform. The user can answer the verification prompt 818 by entering the matching code and select a submit icon 824 to complete the registration process. The next screen, user interface screen 826, can display a UUEK representation 828 of the UUEK for the user. For example, the UUEK representation 828 can include a scannable representation of the UUEK (e.g., a barcode, QR code, non-replaceable token, near field communication sequence, etc.). The scannable representation can be saved to the partner account of the partner platform to enable the user to perform value-based transactions using the service provider tool without having to reference permanent credentials of the service provider tool.

[0248] Figure 9A process flow for facilitating credential-less value exchange is provided in accordance with one or more embodiments of the present disclosure. The process flow describes a communication and data encryption process 900 for securely authorizing exchanges in value agnostic exchanges with UUEKs. As described herein, the process 900 can be utilized to overcome various limitations of conventional exchange systems that expose sensitive and permanent credentials to multiple third parties. The process 900 can be implemented by one or more computing devices, entities, and / or systems described herein. For example, through various steps / operations of the process 900, an exchange platform can overcome various limitations of conventional exchange mechanisms by eliminating reliance on static, sensitive credentials using communication and data encryption techniques.

[0249] Figure 9 An example process 900 is shown for illustrative purposes. While the example process 900 depicts a particular sequence of steps / operations, the sequence can be altered without departing from the scope of the present disclosure. For example, some of the described steps / operations can be performed in parallel or in a different order, but this does not materially affect the functioning of the process 900. In other examples, different components of an example device or system implementing the process 900 can perform functions substantially simultaneously or in a particular order.

[0250] In some examples, the process 900 begins after the registration process 600 of the user and / or partner platform can receive a UUEK to facilitate credential-less value exchange. However, the process 900 can also be performed prior to the registration process 600. For example, a user can obtain a UUEK directly from a service provider platform without having to complete a registration process with a partner platform. In the event that the registration process 600 is completed, a partner platform can use a partner interface and a UUEK specific to the partner platform to facilitate value-based exchanges, otherwise a UUEK specific to and provided by a service provider platform can be used by a partner platform to facilitate value-based exchanges. Figure 6A -C. When a user wishes to conduct a value-based exchange with a partner that has a registered partner account for the user, the partner platform can look up the registered partner account and identify the user’s issued UUEK from the partner account to use to authorize the value-based exchange. If the user wishes to conduct a value-based exchange with a partner that does not have a registered partner account, the user can present a previously issued UUEK (e.g., issued to a service provider platform, etc.) to the partner platform (e.g., through a partner application, etc.) and the partner platform can use the UUEK to authorize the value-based exchange.

[0251] For example, when a user wishes to conduct a value-based exchange with a partner that has a registered partner account for the user, the partner platform can look up the registered partner account and identify the user’s issued UUEK from the partner account to use to authorize the value-based exchange. If the user wishes to conduct a value-based exchange with a partner that does not have a registered partner account, the user can present a previously issued UUEK (e.g., issued to a service provider platform, etc.) to the partner platform (e.g., through a partner application, etc.) and the partner platform can use the UUEK to authorize the value-based exchange.

[0252] The partner platform can generate an exchange request data object for performing the value-based exchange based at least in part on the UUEK for the particular use case (e.g., a partner UUEK when the user has a registered account, a service provider UUEK when the user does not have a registered account, etc.). The exchange request data object can include request data identifying the UUEK and transaction attributes for the requested value-based exchange. The process 900 can begin when the partner platform issues an exchange request based at least in part on the exchange request data object.

[0253] In some embodiments, the process 900 includes, at step / operation 902, receiving an exchange request having a UUEK. For example, an exchange platform (e.g., a partner service thereof, etc.) can receive an exchange request for performing a value-based exchange using a partner interface. The exchange request can indicate a UUEK and / or one or more transaction attributes.

[0254] The transaction attributes can indicate one or more characteristics of the requested exchange. For example, the one or more transaction attributes can include at least one transaction attribute indicating a transaction value (e.g., a cart amount, etc.). For example, the transaction value can include a sum of one or more line items in a financial transaction, including one or more modifications (e.g., taxes, discounts, etc.). By way of example with a financial-based value system, in some examples, the transaction attributes can include (i) an order number, (ii) one or more line item attributes including order, line item group, product code, description, quantity, units-item, grams, kilograms, etc., unit amount, unit tax, line amount (e.g., amount of line item), line tax, etc., and / or (iii) one or more line item adjustments including order, adjustment type (e.g., manufacturer discount, store discount, return, cash payment, gift card payment, other payment, etc.), product code, description, quantity, units-item, grams, kilograms, etc., unit amount, unit tax, line amount (e.g., amount of line item), line tax, etc.

[0255] Additionally or alternatively, the transaction attributes can include a request permission type (e.g., all or partial), a partner transaction reference (e.g., a transaction reference of the partner platform), a channel (e.g., a currency exchange type of the financial value system, such as a push or pull value transfer, real-time payment, etc.), a currency (e.g., for the financial value system, etc.), an organization key (e.g., a platform identifier of a partner organization), an organization category (e.g., airline, clothing, etc.), an agency key (e.g., a platform identifier of a retail location, etc.), an employee identifier, and / or any other traceable information for the value-based exchange.

[0256] In some embodiments, the process 900 includes verifying the UUEK at step / operation 904. For example, the exchange platform (e.g., its partner service) can look up the UUEK to identify a matching identifier from the platform database 414. For example, the UUEK can include an exchange identifier corresponding to an exchange data object. The exchange platform can identify the exchange identifier based at least in part on the UUEK and utilize the exchange identifier to identify the corresponding exchange data object.

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

[0258] In some embodiments, the exchange platform (e.g., its partner service, etc.) receives a UUEK that includes a partner partition that identifies a partner platform. The exchange platform can use the exchange identifier to identify a 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 a system tool data object based at least in part on the tool key. For example, the exchange platform can identify the member platform based at least in part on an entity partition of the tool key and provide the tool key to a service (e.g., a service provider service, etc.) corresponding to the member platform. The service can identify a system tool data object based at least in part on the tool key. One or more identifiers (e.g., a user identifier, a tool identifier, etc.) can then be identified using the system tool data object to process the exchange request.

[0259] In some embodiments, the exchange platform (e.g., its partner service, etc.) receives the UUEK, which includes a service provider partition identifying a service provider platform. The exchange platform (e.g., its partner service, etc.) can determine that a partner-specific exchange data object is unavailable. In response to the determination, the exchange platform can identify a member platform based at least in part on the service provider partition and provide the UUEK to a service (e.g., a service provider service, etc.) corresponding to the member platform. The service can identify a service provider-specific exchange data object based at least in part on an exchange identifier of the UUEK. Based at least in part on the member platform and the exchange identifier, a system tool data object can be identified using the service provider-specific exchange data object. One or more identifiers (e.g., a user identifier, a tool identifier, etc.) can then be identified using the system tool data object to process the exchange request.

[0260] In some examples, the exchange platform can perform one or more validation actions on the UUEK. For example, the exchange data object can include one or more exchange attributes indicating an expiration status. In some examples, the expiration status can indicate (i) whether the UUEK has been previously used to authorize a value-based exchange and / or (ii) a valid time period during which the UUEK can be valid. The validation action can include identifying the expiration status corresponding to the UUEK and validating the UUEK based at least in part on the expiration status. For example, the exchange platform can validate the UUEK if the expiration status indicates that (i) the UUEK has not been previously used to authorize a value-based exchange and / or (ii) the UUEK has been presented within the valid time period.

[0261] In some examples, the validation action can include validating that a sender of the UUEK is related to an original entity to which the UUEK was issued. In some examples, the UUEK can include an entity partition that indicates the original entity (e.g., a member platform, such as a partner or service provider platform) to which the UUEK was issued. The exchange platform can utilize the entity partition of the UUEK to determine the entity (e.g., the original entity) corresponding to the UUEK. In some examples, the validation action can include validating that the sender of the exchange request matches and / or is related to the original entity of the UUEK. In response to determining that the sender is the original entity, the exchange platform can validate the UUEK.

[0262] In the event that the UUEK is validated, the process 900 can continue to step / operation 906. Otherwise, the process 900 can continue to step / operation 914, in which the exchange platform provides an error response to the partner platform using the partner interface.

[0263] In some embodiments, the process 900 includes requesting exchange authorization from a member platform at step / operation 906. For example, the exchange platform (e.g., its service provider service) can request exchange approval from a service provider platform of a service provider tool associated with the UUEK. In some examples, the exchange platform (e.g., its partner service) can identify the member platform based at least in part on the UUEK (e.g., its entity partition). Additionally or alternatively, the exchange platform (e.g., its service provider service) can identify the service provider tool based at least in part on the UUEK (e.g., the exchange identifier).

[0264] The exchange platform (e.g., its service provider service) can provide the exchange authorization request to the member platform using a service provider interface. The exchange authorization request can indicate at least one of one or more transaction attributes and / or a tool identifier of the service provider tool. For example, the exchange platform can generate the exchange authorization request based at least in part on a system tool data object identified from 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.

[0265] 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 based at least in part on a system user data object identified from one or more aspects of the UUEK. In some examples, the system user data object can be identified based at least in part on a user identifier (e.g., a system user identifier) of the exchange data object. Additionally or alternatively, the system user data object can be identified based at least in part on a user identifier (e.g., a system user identifier) of the system tool data object. In some examples, the exchange authorization request can include a user key and / or a user reference from the system user data object.

[0266] Additionally or alternatively, the transaction authorization request can indicate the exchange identifier. For example, the exchange platform can generate a transaction identifier representing the value-based exchange and provide the transaction identifier to the member platform.

[0267] In some embodiments, the process 900 includes receiving, at step / operation 908, an exchange authorization response. For example, the exchange platform (e.g., its service provider service) can receive, using the service provider interface, an exchange authorization response indicating at least one of a transaction approval and / or a transaction denial. In some embodiments, the exchange authorization response is based at least in part on a comparison between the transaction value and the asset availability of the service provider instrument. For example, in response to receiving the exchange authorization request, the member platform can be configured to compare the transaction value to the asset availability of the identified service provider instrument. If the asset availability exceeds the transaction value, the value-based exchange can be authorized (e.g., such that a transaction approval, etc.), otherwise the exchange can be denied (e.g., such that a transaction denial).

[0268] In some examples, the exchange authorization response can indicate one or more response attributes. The response attributes can include one or more error codes, etc., used to characterize the exchange authorization response.

[0269] The exchange platform can generate a transaction record for the value-based exchange based at least in part on the exchange authorization request and / or the exchange authorization response. In some examples, the transaction record can indicate a transaction identifier, one or more transaction attributes, one or more response attributes, the exchange authorization response, one or more instrument and / or user identifiers, and / or any other data related to the value-based exchange. In some examples, the exchange platform can store the transaction record in the platform database in association with the one or more instrument and / or user identifiers.

[0270] In some embodiments, the process 900 includes optionally generating, at step / operation 910, a replacement UUEK. For example, the exchange platform can automatically generate a replacement UUEK to replace the received UUEK.

[0271] In some examples, this can include (i) invalidating the received UUEK in future authorization requests and / or (ii) generating a replacement UUEK. For example, the exchange platform can modify the expiration status of the UUEK to invalidate the UUEK in subsequent value exchanges. Additionally or alternatively, the exchange platform can move, delete, and / or otherwise modify the exchange data object corresponding to the UUEK to invalidate the UUEK. The replacement UUEK can include a new unique exchange identifier (e.g., a different universally unique identifier) corresponding to the service provider instrument to replace the invalidated exchange identifier. In this way, the UUEK can be continually modified and changed as the user completes exchanges on different platforms, thereby limiting exposure of the user and the platforms to malicious parties.

[0272] In some embodiments, the process 900 includes providing an exchange response to the member platform at step / operation 912. For example, the exchange platform (e.g., its partner service) can provide the exchange response to the member platform (e.g., the partner platform, etc.) using the partner interface. The exchange response can be based at least in part on the exchange authorization response. For example, the exchange response can indicate a transaction approval and / or a transaction denial. In some examples, the exchange response can indicate the replacement UUEK (if generated), one or more transaction attributes, the exchange identifier, and / or one or more response attributes. In some examples, the member platform can be configured to replace the UUEK with the replacement UUEK. For example, the exchange response can be provided to the partner platform. The partner platform can receive the exchange response and replace the UUEK with the replacement UUEK.

[0273] Figure 10 and 11 A message flow diagram illustrating steps / operations related to facilitating a credentialless exchange of value in accordance with one or more embodiments of the present disclosure is provided. It will be recognized that these can be performed and implemented with corresponding steps / operations of the Figure 9 For example, Figure 9 A first message flow for facilitating a credentialless exchange through a registered partner account is shown in FIG. 10, while Figure 10 A second message flow for facilitating a credentialless exchange without a registered partner account is shown in FIG. 11. Figure 11

[0274] In the first message flow, at step / operation 1004, a user initiates a transaction through a registered partner account. At step / operation 1006, the partner platform 420 retrieves the UUEK of the user to perform the transaction on behalf of the user. At step / operation 1008, the partner platform 420 provides an exchange request to at least one of the plurality of partner services 410 of the exchange platform corresponding to the partner platform 420 using the partner interface. The exchange request can indicate the UUEK and / or one or more transaction attributes of the value-based exchange.

[0275] At step / operation 1010, the partner service 410 looks up a partner-specific transaction token (e.g., in a partner-specific data store, such as a portion of the platform database, etc.) to determine the member platform corresponding to the UUEK (e.g., by mapping to a service provider partition, etc.). At step / operation 1012, the partner service 410 provides a service provider service 412 of the exchange platform corresponding to the member platform with data indicating the exchange request.

[0276] ​At step / operation 1014, the service provider service 412 validates the UUEK (and / or its exchange identifier). At step / operation 1016, the service provider service 412 provides an exchange authorization request to the service provider platform 440 using the service provider interface. The exchange authorization request can include one or more keys (e.g., user keys, tool keys, etc.), references (e.g., tool references, user references, etc.), and / or one or more transaction attributes.

[0277] At step / operation 1018, the service provider platform 440 approves the transaction and provides an exchange authorization response to the service provider service 412 using the service provider interface. At step / operation 1020, the service provider service 412 records the value-based exchange associated with one or more keys (e.g., user keys, tool keys, etc.), references (e.g., tool references, user references, etc.), and the like. At step / operation 1022, the service provider service 412 provides the exchange authorization response to the partner service 410. At step / operation 1024, the partner service 410 provides an exchange response to the partner platform 420 using the partner interface.

[0278] In a second message flow, at step / operation 1102, the user 1002 initiates a transaction by presenting the UUEK (and / or its UUEK representation) to the partner platform 420. At step / operation 1104, the partner platform 420 provides an exchange request to the partner service 410 corresponding to the exchange platform of the partner platform 420 using the partner interface. The exchange request can identify the UUEK and / or one or more transaction attributes for the value-based exchange.

[0279] At step / operation 1106, the partner service 410 looks up the exchange identifier (e.g., in a partner-specific data store, such as a portion of the platform database, etc.) to determine whether an exchange data object exists. In the absence of an exchange data object, at step / operation 1108, the partner service 410 provides the UUEK to the service provider service 412 of the exchange platform corresponding to the service provider platform identified from the UUEK.

[0280] At step / operation 1110, the service provider service 412 validates the exchange identifier of the UUEK. At step / operation 1112, the service provider service 412 provides an exchange authorization request to the service provider platform 440 using the service provider interface. The exchange authorization request can include one or more keys (e.g., user keys, tool keys, etc.), references (e.g., tool references, user references, etc.), and / or one or more exchange attributes.

[0281] At step / operation 1114, the service provider platform 440 approves the exchange and provides an exchange authorization response to the service provider service 412 using the service provider interface. At step / operation 1116, the service provider service 412 records the transaction associated with one or more keys (e.g., user keys, tool keys, etc.), references (e.g., tool references, user references, etc.), and the like. At step / operation 1118, the service provider service 412 provides the exchange authorization response indicating the response to the partner service 410. At step / operation 1120, the partner service 410 provides the exchange response to the partner platform 420 using the partner interface.

[0282] After describing various operations, processes, methods, functions, and the like representative of processing exchanges for users, various user interface screens are provided and described for controlling, initiating, performing, and / or the like steps / operations. In various embodiments, the user interface screens provided and described in this disclosure are configured to be provided via a user interface of the client device 104.

[0283] Figure 12A - D. An example user interface flow is provided configured for the client device 104. The user interface can be configured to guide a user through a credential-less exchange process to facilitate a value-based exchange between one or more member platforms without exposing sensitive and permanent credentials of a service provider tool used to perform the value-based exchange. As Figure 12A As shown, when the user selects a payment method from the transaction processing screen 1202 of the partner application, the credential-less exchange process can begin. After selecting a payment method provided by the exchange platform, the user can be switched to a tool selection screen 1204 as shown. Figure 12B The tool selection screen 1204 can include a plurality of selectable tool icons 1206, each of which can be related to a UUEK issued by the exchange platform using various techniques described herein. The user can perform the exchange by selecting one or more of the selectable tool icons 1206.

[0284] In some examples, in response to the selection, a scan screen 1208 for an in-store transaction can be provided. The scan screen 1208 can present a scannable UUEK representation 1210 corresponding to the UUEK. The user can scan the scannable UUEK representation 1210 to complete the value-based exchange. Additionally or alternatively, in an online setting, the user can be transitioned to a verify user screen 1212 to provide a personal identification number (PIN) associated with the service provider tool. The user can enter the PIN to complete the transaction.

[0285] VI. Conclusion

[0286] Those skilled in the art will appreciate many modifications and other embodiments of the present disclosure that arise out of the teaching and knowledge of the field presented in the foregoing description and the associated drawings. As should be apparent, the present disclosure is not limited to the specific embodiments described and are intended to include modifications and other embodiments within the scope of the appended claims. Although specific terms are employed herein, they are used only in the generic and descriptive sense and not for purposes of limitation.

Claims

1. A computer-implemented method comprising: receiving, by one or more processors of an exchange platform and using a partner interface, an exchange request from a first member platform to perform a value-based exchange, wherein the exchange request indicates a universally unique temporary exchange key (UUEK) and one or more transaction attributes, wherein the UUEK includes a partition and an exchange identifier positioned according to a key format established by the exchange platform; identifying, by the one or more processors, an exchange data object based on the exchange identifier in the UUEK, wherein the exchange identifier includes a tool identifier for a service provider tool of a second member platform; providing, by the one or more processors and using a service provider interface, an exchange authorization request to the second member platform, wherein the exchange authorization request indicates the one or more transaction attributes and the tool identifier; receiving, by the one or more processors and using the service provider interface, an exchange authorization response from the second member platform, the exchange authorization response indicating at least one of a transaction approval or a transaction denial; and providing, by the one or more processors and using a partner interface, an exchange response to the first member platform based at least in part on the exchange authorization response, wherein the exchange response indicates the transaction approval or the transaction denial.

2. The computer-implemented method of claim 1, wherein, the partition includes a partner partition identifying a partner platform, the tool identifier includes a tool key for the second member platform, and the computer-implemented method further comprises: identifying a system tool data object based at least in part on the tool key; and generating the exchange authorization request based at least in part on the system tool data object.

3. The computer-implemented method of claim 1, wherein, the partition includes a service provider partition identifying a service provider platform, and the computer-implemented method comprises: identifying the second member platform based at least in part on the service provider partition; identifying a system tool data object based at least in part on the second member platform and the exchange identifier; and generating the exchange authorization request based at least in part on the system tool data object.

4. The computer-implemented method of claim 1, wherein, the exchange data object includes one or more exchange attributes indicating an expiration status, and the computer-implemented method further comprises: validating the UUEK based at least in part on the expiration status.

5. The computer-implemented method of claim 4, further comprising: modifying the expiration status to invalidate the UUEK.

6. The computer-implemented method of claim 1, wherein, the exchange authorization request indicates a user identifier corresponding to the exchange data object.

7. The computer-implemented method of claim 6, wherein, the user identifier includes a user key corresponding to a system user identifier, and the tool identifier includes a tool key corresponding to a system tool identifier.

8. The computer-implemented method of claim 6, further comprising: generating a transaction record for the value-based exchange; and storing the transaction record in a platform database in association with the tool identifier and the user identifier. the transaction record indicates a transaction identifier, the one or more transaction attributes, and the exchange authorization response.

9. The computer-implemented method of claim 8, wherein, ​ 10. The computer-implemented method of claim 1, wherein, The one or more transaction attributes include at least one transaction attribute indicative of a transaction value, and wherein the exchange authorization response is based at least in part on a comparison between the transaction value and asset availability of the service provider tool.

11. The computer-implemented method of claim 1, further comprising: generating a replacement UUEK for the service provider tool, wherein the exchange response indicates the replacement UUEK.

12. The computer-implemented method of claim 11, wherein, The exchange response is provided to a first member platform, and wherein the first member platform is configured to use the replacement UUEK in place of the UUEK.

13. The computer-implemented method of claim 12, wherein, The UUEK includes a universally unique identifier, and the replacement UUEK includes a different universally unique identifier.

14. An exchange platform comprising a memory and one or more processors communicatively coupled to the memory, the one or more processors configured to: From a first member platform and using a partner interface, receiving an exchange request for performing a value-based exchange, wherein, The exchange request indicates a universally unique exchange key (UUEK) and one or more transaction attributes, wherein the UUEK includes a partition and an exchange identifier positioned according to a key format established by the exchange platform; identify an exchange data object based on the exchange identifier in the UUEK, wherein the exchange identifier includes a tool identifier for a service provider tool of a second member platform; provide an exchange authorization request to the second member platform using a service provider interface, wherein the exchange authorization request indicates the one or more transaction attributes and the tool identifier; receive an exchange authorization response from the second member platform and using the service provider interface, the exchange authorization response indicating at least one of a transaction approval or a transaction denial; and provide an exchange response to the first member platform based at least in part on the exchange authorization response using a partner interface, wherein the exchange response indicates the transaction approval or the transaction denial.

15. The switching platform of claim 14 wherein, The UUEK includes a partner partition identifying a partner platform, the tool identifier includes a tool key for the member platform, and the one or more processors are further configured to: identify a system tool data object based at least in part on the tool key; and generate the exchange authorization request based at least in part on the system tool data object.

16. The switching platform of claim 14, wherein, The partition includes a service provider partition identifying a service provider platform, and the one or more processors are further configured to: identify the second member platform based at least in part on the service provider partition; identify a system tool data object based at least in part on the second member platform and the exchange identifier; and generate the exchange authorization request based at least in part on the system tool data object. The exchange data object includes one or more exchange attributes indicative of an expiration status, and the one or more processors are further configured to:

17. The switching platform of claim 14 wherein, validate the UUEK based at least in part on the expiration status. The one or more processors are further configured to modify the expiration status to invalidate the UUEK.

18. The switching platform of claim 17 wherein, ​ 19. One or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors, cause the one or more processors to: receiving, from the exchange platform, and using the partner interface, an exchange request for performing a value-based exchange from a first member platform, wherein, the exchange request indicates a universally unique ephemeral key (UUEK) and one or more transaction attributes, wherein the UUEK includes a partition and an exchange identifier positioned according to a key format established by the exchange platform; identify, by the exchange platform, an exchange data object based on the exchange identifier in the UUEK, the exchange identifier including a tool identifier for a service provider tool of a second member platform; provide, by the exchange platform, an exchange authorization request to the second member platform using a service provider interface, wherein the exchange authorization request indicates the one or more transaction attributes and the tool identifier; receive, by the exchange platform from the second member platform and using the service provider interface, an exchange authorization response, the exchange authorization response indicating at least one of a transaction approval or a transaction denial; and provide, by the exchange platform to the first member platform using a partner interface, an exchange response based at least in part on the exchange authorization response, wherein the exchange response indicates the transaction approval or the transaction denial.

20. The one or more non-transitory computer-readable storage medium of claim 19, wherein, the exchange authorization request indicates a user identifier corresponding to the exchange data object. the exchange authorization request indicates a user identifier corresponding to the exchange data object.

Images