HK40123499A - Systems, methods, and storage media for executing credential-less network-based communication exchanges - Google Patents

Description

Systems, methods, and storage media for performing network-based credentialless communication exchange.

Cross-references to related applications

This application claims the benefit of U.S. Provisional Patent Application Serial No. 63/370280, filed August 3, 2022; U.S. Provisional Patent Application Serial No. 63/370279, filed August 3, 2022; and U.S. Patent Application Serial No. 18/329101, filed June 5, 2023, each of which is incorporated herein by reference in its entirety, including any figures, tables, diagrams, and appendices.

Technical Field

Embodiments of this disclosure typically involve credentialless value exchange between multiple entities in a value system.

Background Technology

Given the limitations of existing transaction processing technologies and architectures, various embodiments of this disclosure address the technical challenges associated with network-based value transactions. Existing processes for executing transactions on computing networks rely on persistent credentials and their proxies, such as payment credentials (e.g., card numbers, usernames, passwords, bank routing numbers, account numbers, etc.), which expose the recipient of these credentials to fraud, regulatory and compliance costs, and reputational risks. Furthermore, due to the static nature of traditional credentials, users must accept the risk of financial loss, damaged credit scores, identity theft, and other consequences each time they provide their credentials for a transaction. While stringent communication protocols, data management procedures, and authentication schemes are typically used to address the inherent insecurity of persistent credentials, each of these schemes introduces additional technical problems by increasing overhead and complicating network-based transactions, without addressing the fundamental technical problem of data security.

For example, traditional service providers managing user accounts might use disclaimers to limit their exposure, preventing users from providing their credentials to certain third parties. This can lead to network congestion as a limited number of authorized parties become overwhelmed by requests from the group. Furthermore, authorized parties need to register users by obtaining sensitive persistent credentials (e.g., usernames, passwords, routing/transmission credentials, etc.) from users, and then manage a large number of persistent credentials across multiple registered users. This provides a single attack vector for malicious actors to obtain sensitive user information from a user group. To counter such attacks, traditional transaction processing entities need to employ costly, resource-intensive, and robust data management procedures and authentication schemes; however, these procedures and schemes are not perfect and remain vulnerable to infiltration.

Other technologies used to address data security include communication exchanges (e.g., financial transaction communications) that are confined to strict information standards (e.g., ISO information standards). However, these standards lack flexibility and are not designed to provide contextual data for transactions. Therefore, such communication standards improve network security at the expense of transaction functionality.

The various embodiments of this disclosure make significant contributions to a variety of existing network-based value transaction processing technologies by addressing each of these technical challenges.

Summary of the Invention

Various embodiments of this disclosure disclose a secure intermediate computing platform and computing service that facilitates credentialless value-based exchanges that utilize UUEKs (Universally Unique Temporary Keys) to eliminate the use of permanent credentials. To this end, the intermediate computing platform can facilitate interaction between one or more member platforms to register user tools in a value exchange system powered by a new, temporary data structure (referred to herein as a UUEK). Unlike traditional registration systems, the intermediate computing platform does not accept or rely on permanent user or tool credentials to register user tools. Eliminating such credentials enables the use of new, more flexible interfaces, such as the application programming interfaces (APIs) described herein, which the intermediate computing platform utilizes to communicate with different network members to register user tools without exposing user credentials at any step in the process. Once registered, the intermediate computing platform can issue a UUEK to member platforms, which can replace traditional permanent credentials. The issued UUEK does not reflect permanent credentials or any other sensitive user or tool information. The interface between the member platform and the intermediate platform allows (i) users to present issued UUEKs (without explicitly referencing permanent credentials) from the member platform to the intermediate platform, and (ii) the intermediate platform to map the issued UUEKs to tool keys of the same or another member platform and provide the tool keys to the member platform to authorize value-based exchanges. In this way, network-based transactions can be authorized seamlessly without exposing sensitive user or tool information that may be vulnerable to network attacks. Ultimately, it achieves additional flexibility (e.g., through the use of new interfaces, etc.) and security (e.g., by eliminating permanent credentials, etc.), while reducing computational requirements and significantly increasing network throughput for exchange processing compared to traditional technologies.

In some embodiments, the method includes: initiating the presentation of a registration user interface via a user's client device by one or more processors using a partner interface, wherein the registration user interface includes a tool registration screen indicating one or more service provider tools associated with the user; receiving selection data indicating the selection of a service provider tool from the registration user interface by one or more processors using the partner interface; generating a matching code for authenticating the user by one or more processors using the service provider interface; providing a registration request to a service provider platform corresponding to the service provider tool by one or more processors using the service provider interface, 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 an authentication message including the matching code by one or more processors using the partner interface; and in response to authentication of the user based on the matching code, (i) generating a UUEK for the user by one or more processors, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) providing the UUEK to the partner platform by one or more processors using the partner interface.

In some embodiments, the computing system includes memory and one or more processors communicatively coupled to the memory, the processors being configured to: initiate the presentation of a registration user interface via a user's client device using a partner interface, wherein the registration user interface includes a tool registration screen indicating one or more service provider tools associated with the user; receive selection data indicating the selection of a service provider tool from the registration user interface using the partner interface; generate a matching code for authenticating the user; provide a registration request to a service provider platform corresponding to the service provider tool using a service provider interface, wherein the registration request includes service provider registration data indicating the matching code, the user's user identifier, and the tool identifier of the service provider tool; receive an authentication message including the matching code using the partner interface; and in response to authentication of the user based 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 the UUEK to the partner platform using the partner interface.

One or more non-transitory computer-readable storage media, comprising instructions that, when executed by one or more processors, cause one or more processors to: initiate the presentation of a registration user interface via a user's client device using a partner interface, wherein the registration user interface includes a tool registration screen indicating one or more service provider tools associated with the user; receive selection data indicating the selection of a service provider tool from the registration user interface using the partner interface; generate a matching code for authenticating the user; provide a registration request to a service provider platform corresponding to the service provider tool using a service provider interface, wherein the registration request includes service provider registration data indicating the matching code, the user's user identifier, and the tool identifier of the service provider tool; receive an authentication message including the matching code using the partner interface; and in response to authentication of the user based 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 the UUEK to the partner platform using the partner interface.

Attached Figure Description

Having provided a general description of this disclosure, reference will now be made to the accompanying drawings (which are not necessarily drawn to scale), in which:

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

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

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

Figure 4 is an example block diagram of an example credentialless value exchange system according to one or more embodiments of the present disclosure;

Figure 5 is an example data diagram for facilitating credentialless value exchange according to one or more embodiments of the present disclosure;

Figures 6A-6C provide a process flow for establishing cross-entity relationships according to one or more embodiments of the present disclosure;

Figures 7A-7D illustrate message flows for establishing cross-entity relationships according to one or more embodiments of the present disclosure;

Figures 8A-8F provide example interfaces for establishing cross-entity relationships according to one or more embodiments of this disclosure;

Figure 9 illustrates a process flow for facilitating credentialless value exchange according to one or more embodiments of the present disclosure;

Figure 10 illustrates a first message flow for facilitating credentialless value exchange according to one or more embodiments of the present disclosure;

Figure 11 illustrates a second message flow for facilitating credentialless value exchange according to one or more embodiments of the present disclosure;

Figures 12A-12C provide example interfaces for facilitating credentialless value exchange according to one or more embodiments of the present disclosure.

Detailed Implementation

Various embodiments of this disclosure will be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, of the embodiments of this disclosure. In fact, this disclosure may be embodied in many different forms and should not be construed as limited to the embodiments described herein; rather, these embodiments are provided to enable the content of this disclosure to meet applicable legal requirements. Unless otherwise stated, the term “or” as used herein has both alternative and conjunctional meanings. The terms “illustrative” and “example” are used as examples and do not indicate a level of quality. Words such as “calculate,” “determine,” “generate,” and/or similar terms are used interchangeably herein to refer to the creation, modification, or identification of data. Furthermore, the terms “at least partially based,” “at least based on,” “based on,” and/or similar terms are used interchangeably in an open manner herein, and therefore, unless otherwise stated, they do not necessarily mean based only at least partially or only on the referenced elements. The same reference numerals always refer to the same elements.

I. Overall Overview and Technological Advantages

Various embodiments of this disclosure provide technical solutions for managing network-based exchanges. In various embodiments, the exchange platform can be configured to facilitate credentialless value exchange between one or more member platforms. These exchanges can occur in real time without requiring permanent credentials that could expose members to financial, legal, reputational, or other risks. Therefore, in various embodiments, client devices can buy, sell, and/or perform value-based exchanges in real time over any network without exposing sensitive information vulnerable to network-based attacks.

Embodiments of this disclosure provide improved instrument enrollment and exchange processing techniques that leverage interfaces and data transformation and encryption techniques to enhance data security while reducing the computational resource expenditure required to protect sensitive data over network communications. For example, some techniques of this disclosure retrieve data objects and convert them into unique data keys that can only be identified by authorized entities. Data keys can be provided and/or established by utilizing exchange interfaces between the exchange platform and other member platforms. Once established, the data key can be mapped to sensitive credentials stored within the source platform (e.g., a service provider platform) without requiring network transmission of the sensitive credentials. To facilitate value-based exchange, future communications may replace traditional permanent credentials with data keys, enabling the source platform to identify permanent credentials and/or perform one or more operations for the specific instrument associated with them. In this way, the exchange platform can facilitate exchange using keys (and/or other identifiers) that themselves cannot trace back to underlying sensitive information. This, in turn, allows the exchange platform to comprehensively track, facilitate, and distribute network-based communications without exposing members to cyberattacks. In this way, the registration technology disclosed herein provides improved data and network security technology that can be practically applied to network-based exchanges to securely register tools with the exchange platform.

In addition to the description above, embodiments of this disclosure also propose network-based exchange processing techniques to facilitate credentialless exchange. To this end, some techniques in this disclosure utilize a novel data structure, UUEK, which can replace persistent credentials traditionally used to authorize value-based exchanges. Using the techniques of this disclosure, UUEKs can be securely issued across member platforms to allow users to perform value-based exchanges using identifiers that are unilaterally recognizable by the exchange platform. UUEKs can be mapped to unique identifiers that can reference sensitive information without directly identifying that information. For example, a unique identifier can reference a mapping that can only be interpreted by the source platform, preventing malicious parties unrelated to the exchange platform from using the identifier. In this way, the exchange platform can distribute, track, and facilitate exchanges without exposing member platforms to data security risks. Furthermore, the exchange platform can continuously update, modify, and/or redistribute UUEKs to member platforms to continuously adapt UUEKs in real time. In this way, the exchange platform can provide technical improvements for data and network security while reducing computational resource requirements (e.g., for securely encrypting persistent credentials) to facilitate value-based exchanges.

Examples of inventive and technical advantages of this disclosure include: (i) data transformation, mapping, and processing schemes for facilitating network-based, credentialless user registration; (ii) exchange interfaces and network-based communication schemes for improving network security in cross-platform communication; and (iii) temporary data structures and data management techniques for distributing temporary data structures to facilitate real-time, secure, and dynamic value-based exchange.

II. Example Definition

In some embodiments, the term "exchange platform" refers to a computational entity configured to facilitate credentialless value exchange among one or more members of a network. An exchange platform may include one or more processing devices, storage devices, etc., physically and/or wirelessly coupled and configured to collectively (and/or individually) perform one or more computational tasks facilitating credentialless exchange within a value system. In some examples, an exchange platform may include, define, and/or otherwise utilize one or more application programming interfaces (APIs) to facilitate communication (e.g., requests and responses) between multiple members. As described herein, APIs can be used to facilitate secure exchange between one or more members in any value system.

In some embodiments, the term "member" refers to an entity that collaborates with the exchange platform to participate in a value exchange. As an example, a member may include (i) a collaborator that receives value through the exchange platform, (ii) a service provider that provides value through the exchange platform, and/or (iii) both a collaborator and a service provider. As used herein, a member may be referred to as a collaborator when receiving value through a value exchange, and/or as a service provider when providing value through a value exchange. Thus, depending on the member's role in the value exchange, the same member may be either a collaborator or a service provider. For example, a member may be a collaborator that receives value through a value exchange. The same member may be a service provider that provides value in another value exchange. In some examples, the same member may be both a collaborator and a service provider in the same value exchange, allowing the member to provide and receive value in a single member value exchange using the exchange platform.

In some embodiments, a member is a collaborator when using services provided by a service provider. A collaborator can include any value-seeking entity in any value system. For example, in a financial value system, a collaborator might include merchants (e.g., retailers, brick-and-mortar stores, etc.) who can use a service provider (e.g., a financial institution) to access funds for financial transactions. Additionally or alternatively, in an information value system, a collaborator might include news publishers (e.g., newspapers, media organizations, etc.) who can use service providers such as news agencies (e.g., news agencies, news services, etc.) to access information for information transactions. It is understood that the techniques disclosed herein can be applied to any value system, and a collaborator can include any value seeker in any given value system.

In some embodiments, a member is a service provider when providing services to a collaborator. A service provider can include a source of value in any value system. For example, in a financial value system, a service provider may include financial institutions (e.g., banks, currency exchange platforms, credit unions, etc.) that provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a service provider may include news organizations (e.g., news agencies, news services, etc.) that provide information sources for news publishers' releases. It is understood that the techniques disclosed herein can be applied to any value system, and a service provider may include any source of value in any given value system.

In some embodiments, the term "member platform" refers to a computing entity corresponding to a member. A member platform entity may 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 may be both a partner platform and a service provider platform. For example, the same member platform may be configured to operate on behalf of a partner in one value exchange and a service provider in another value exchange. In some examples, the same member platform may 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 may refer to a partner platform, a service provider platform, or both, and in some examples, may depend on the member platform's role in the value exchange (e.g., and/or one or more APIs used by the member platform in the value exchange).

In some embodiments, a collaborating platform is a computing entity configured to perform one or more operations on behalf of a collaborator. For example, a collaborating platform may include one or more processing devices, storage devices, etc., physically and/or wirelessly coupled and configured to collectively (and/or individually) perform one or more computational tasks for requesting value in an unknown exchange within a value system. In some examples, a collaborating platform may include, define, and/or otherwise utilize one or more APIs to facilitate communication with an exchange platform (e.g., requests and responses, etc.). In some examples, a collaborating platform may be configured to host one or more user-facing applications (e.g., collaborating applications, etc.) for interaction with one or more users.

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

In some embodiments, the term "exchange interface" refers to a set of instructions used to facilitate communication between an exchange platform and one or more member platforms and/or internal services. An exchange interface may include APIs, file-based interfaces, message queue-based interfaces, etc. For example, an exchange interface may include APIs, such as one or more Simple Object Access Protocol (SOAP) APIs, one or more Remote Procedure Call (RPC) APIs, one or more WebSocket APIs, one or more Representational State Transition (REST) APIs, etc. In some embodiments, an exchange interface may include one or more RPC APIs, such as one or more gRPC APIs.

An exchange platform may 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, service provider platforms, etc.). Each API may include multiple communication instructions, message definitions, etc., for exchanging requests and/or responses between the exchange platform and entities involved in the value exchange. For example, an exchange interface may include a partner API for facilitating communication with a partner platform and/or a service provider API for facilitating communication with a service provider platform.

In some embodiments, the term "partner interface" refers to an exchange interface used to facilitate one or more communications between a partner platform and an exchange platform. The partner interface may define one or more communication instructions, message definitions, etc., to facilitate one or more request messages and/or response messages between the partner platform and the exchange platform. For example, the partner interface may include an API that defines (i) requests from a computing entity 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 may define one or more registration messages, session messages, transaction messages, etc., to facilitate value exchange between partners. In some embodiments, the partner interface defines one or more identifiers for securely identifying one or more parts of the value exchange.

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

In some embodiments, the term "entity partition" refers to a unique identifier for a computing entity. An entity partition may include unique numbers, alphanumeric characters, etc., representing a particular computing entity. For example, an entity partition may include a member partition representing a member platform, a service provider partition representing a service provider platform, a partner partition representing a partner platform, etc.

In some embodiments, the term "service provider partition" refers to a unique identifier for a service provider and/or a service provider platform associated with the exchange platform. A service provider partition may include sequences of numbers, alphanumeric characters, and any/other characters or symbols representing a service provider associated with the exchange platform (e.g., joining, registering, etc.). For example, an exchange platform may include multiple service provider partitions, each identifying a service provider platform associated with the exchange platform (e.g., joining, registering, etc.). Each service provider partition may represent a service provider platform that has been configured with one or more exchange platform software development kits (SDKs) or similar tools to implement the exchange platform's service provider interface.

In some embodiments, a "partner partition" refers to a unique identifier for a partner and/or a partner platform. A partner partition may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols representing a partner associated with the exchange platform. For example, an exchange platform may include multiple partner partitions, each identifying a partner platform associated with the exchange platform (e.g., joining, registering, etc.). Each partner partition may represent a partner platform that has been configured with one or more exchange SDKs, etc., to implement the partner interface of the exchange platform.

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

In some embodiments, the user-facing application is a partner application hosted by a partner platform (e.g., a member platform acting as a partner in a specific exchange) to facilitate the partner's functionality. The partner application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks for the partner. For example, the partner application may be configured to present one or more user interfaces for interacting with one or more products offered by a retail-based partner, one or more information units offered by an information-based partner, etc. (e.g., browsing, purchasing, viewing, etc.). In some examples, the partner application may be configured to receive user input (e.g., via one or more user interfaces) to receive information from the user.

In some embodiments, the user-facing application is a service provider application hosted by a service provider platform (e.g., a member platform of a service provider acting as a specific exchange) to facilitate the service provider's functionality. The service provider application may 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 may be configured to present one or more user interfaces to interact with one or more service provider tools provided by the service provider (e.g., viewing, managing, auditing, registering, etc.). For instance, in a financial value system, the service provider application may have access to bank accounts, brokerage accounts, credit lines, etc., to manage funds, assets, etc., processed by the corresponding accounts. In some examples, the service provider application may be configured to receive user input (e.g., via one or more user interfaces) to receive information, authorization, etc., from the user.

In some embodiments, the term "service provider tool" refers to a mechanism used by a service provider to deliver value on behalf of a specific user. Service provider tools may depend on the value system and/or the service provider. In some examples, service provider tools may include accounts at the service provider's location. For example, in a financial value system, service provider tools may include bank accounts (e.g., checks, savings, etc.), brokerage accounts, credit lines, etc. In an information value system, service provider tools may include subscriber accounts, etc. In some examples, service provider tools may include virtual tools hosted by a service provider platform.

In some embodiments, the term "tool data object" refers to a data entity representing a service provider tool. A tool data object may 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 may be based on the type of the tool data object. For example, a service provider tool may be represented as a member tool data object in a member platform. Additionally or alternatively, a service provider tool may be represented independently by a system tool data object in an exchange platform. In some examples, member tool data objects and system tool data objects may include the same one or more tool identifiers and/or one or more tool attributes. For example, a member platform may register multiple service provider tools with the exchange platform. During registration, the member platform may provide one or more tool identifiers and/or tool attributes, and in some examples, the exchange platform may return another identifier.

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

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

In some embodiments, the term "tool identifier" refers to any representation of a service provider tool. As described herein, a tool identifier may include a tool identifier, a tool reference, a tool key, etc.

In some embodiments, the term "member tool identifier" refers to a unique identifier used to represent a service provider tool within a member platform. For example, a member tool identifier may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols representing a service provider tool on a service provider platform.

In some embodiments, the term "tool reference" refers to a unique identifier used to reference a member tool identifier. For example, a tool reference may be generated by a member platform and/or provided to an exchange platform to allow the exchange platform to reference tools 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 mapped to the member tool identifier.

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 may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that represent a service provider tool to the exchange platform. In some examples, a system tool identifier may include a UUID.

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

In some embodiments, the term "instrument representation" refers to a unique identifier used to represent a service provider's instrument to a user. For example, an instrument representation may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that visually represent the service provider. The format and/or value of the instrument representation may be at least partially based on the type of service provider and/or service provider instrument. For example, in a financial value system, an instrument reference may include a portion of a perpetual credential (e.g., the last four digits, etc.), such as an account number (e.g., a debit account, a credit account, etc.), a financial account name, etc. As another example, in an information value system, an instrument reference may include a portion of a perpetual credential such as a subscription account (e.g., one or more numbers, alphanumeric characters, etc.). For example, an instrument representation may include a derivative of a perpetual credential that may only allow entities with prior knowledge of the perpetual credential to use the instrument representation to identify the perpetual credential. As another example, an instrument representation may include an instrument nickname assigned by the user and subsequently identified.

In some embodiments, the term "user data object" refers to a data entity representing a user interacting with a member platform and/or exchange platform. For example, a user may include entities (e.g., individuals, organizations, groups, etc.) that participate in value exchanges managed by the exchange platform. In some examples, a user may indirectly cooperate with the exchange platform by creating a user account with a registered service provider, registering (and/or allowing registration) service provider tools, etc. In some examples, the exchange platform may act on behalf of the user without requiring direct interaction between the user and the exchange platform. For example, the exchange platform may act as a hidden intermediary between user-facing applications and the user's service provider tools.

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 may be based on the 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 represented independently by a system user data object in an exchange platform. In some examples, member user data objects and system user data objects may include the same one or more user identifiers and/or one or more user attributes. For example, a member platform may register multiple users with the exchange platform. During registration, the member platform may provide one or more user identifiers and/or user attributes, and in some examples, the exchange platform may return another identifier.

In some embodiments, a member user data object is an internal representation of a user within a member platform. The member tool data object may include one or more user identifiers, such as a member user identifier, a user key from an exchange platform, etc. Additionally or alternatively, the member user data object may include one or more user attributes. One or more user attributes may indicate one or more contextual characteristics for a user. In some examples, user attributes may indicate one or more identifiable characteristics of a user. For example, user attributes may indicate a user's first name, last name, email address, physical address (e.g., one or more of street, location, region, postal code, country, etc.), birthday (e.g., date of birth, age range, etc.), phone number, etc. In some examples, user attributes may include encrypted, hashed, and/or other secure representations of a user's identifiable characteristics. For example, user attributes may include one or more hashed identifiers of the user, etc.

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

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

In some embodiments, the term "system user identifier" refers to a unique identifier that represents a user within the exchange platform. For example, a system user identifier may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that represent a user to the exchange platform. In some examples, a system user identifier may include a UUID specific to a particular user.

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 may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that represent a user to a service provider platform.

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

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

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 may include one or more identifiers and/or one or more exchange attributes. For example, one or more identifiers and/or one or more exchange attributes may be based on the type of the exchange data object. For instance, an exchange may be represented as a member exchange data object in a member platform. Additionally or alternatively, an exchange may be represented independently by a system exchange data object in the exchange platform. In some examples, member exchange data objects and system exchange data objects may include the same one or more identifiers and/or one or more exchange attributes. For example, using some techniques of this disclosure, an exchange platform may issue one or more unique identifiers to member platforms that can be used to authorize value exchanges.

In some embodiments, a system exchange data object is an internal representation of a value exchange mediated by an exchange platform. In some examples, depending on the role of the system exchange data object in a value-based exchange, the system exchange data object may include one or more distinct identifiers and/or exchange attributes.

For example, system exchange data objects may include service provider-specific exchange data objects corresponding to the service provider platform. Service provider-specific exchange data objects may include one or more identifiers, such as exchange identifiers, system user identifiers, system tool identifiers, UUEK, etc. Additionally or alternatively, service provider-specific exchange data objects may include one or more exchange attributes, such as expiration date, currency (e.g., for financial value systems, etc.).

Additionally or alternatively, the system exchange data object may include a partner-specific exchange data object corresponding to the partner platform. The partner-specific exchange data object may include one or more identifiers, such as an exchange identifier, instrument key, UUEK, member instrument reference (e.g., partner-specific instrument reference, etc.). Additionally or alternatively, the partner-specific exchange data object may include one or more exchange attributes, such as a deadline, currency (e.g., for a financial value system, etc.), instrument type, previous UUEK identifier, etc. In some embodiments, the member exchange data object is an external representation of a value exchange mediated by an exchange platform. The member exchange data object may include one or more identifiers, such as a member exchange identifier, member instrument identifier, UUEK from the exchange platform, etc.

In some embodiments, the term "exchange identifier" refers to a unique identifier used for value exchange with an exchange platform. An exchange identifier may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols representing at least a user and/or service provider tool. In some examples, a unique exchange identifier may include a universally unique identifier (UUID), which can be mapped (e.g., through a series of identifiers, etc.) to a user, service provider tool, and/or member registered on the exchange platform. In some examples, one or more UUID generators may be used to randomly generate exchange identifiers. For example, an exchange identifier may include a random sixteen-byte information generated according to one or more UUID formatting standards (e.g., UUID v4, etc.). Therefore, while an exchange identifier may be used by the exchange platform and/or member platforms for one or more functions, the same exchange identifier will be useless to an external party if there is no prior association between the exchange identifier and one or more other identifiers. In some examples, the exchange identifier may be externally represented by UUEK.

In some embodiments, a “universally unique temporary key” or “UUEK” refers to an external representation (e.g., in place of a service provider exchange identifier and/or a partner exchange identifier) that can be issued to external entities (e.g., users, partners, and/or service providers) to initiate transactions using an exchange platform. For this purpose, the exchange platform can generate a UUEK and issue it to the external entity. Each UUEK may include multiple values (e.g., up to fifty and/or more characters, possibly case-sensitive) representing one or more aspects of the transaction. For example, the multiple values may indicate an exchange identifier, a partition (e.g., identifying the recipient of the UUEK, etc.), an identifier type, and/or one or more flags. For instance, a UUEK may include a partner-specific UUEK and/or a service provider-specific UUEK. As described herein, a partner-specific UUEK may be associated with a partner-specific exchange data object, while a service provider-specific UUEK may be associated with a service provider-specific exchange data object.

For example, a UUEK can be generated based on a key format. The key format may include multiple characters, for example, fifty or more characters (potentially case-sensitive). The first portion of the characters (e.g., the first six characters) can be reserved as a partition to identify the recipient of the UUEK. For example, this partition may include a partner partition, a service provider partition, and/or any other member partition. For instance, a UUEK can be issued in response to a request from an authorized member (e.g., related to a partner and/or service provider).

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

ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrr

Where p represents the partition character, F represents the format character, i represents the identifier type character, G represents the exchange identifier, and r represents the reserved character. The key format allows for 9.8 × 10⁸⁴ unique permutations, a number greater than the number of atoms in the known observable universe. This enables the on-demand generation and distribution of new UUEKs without compromising the security of the underlying data to which the UUEK can be mapped, such as user and tool identifiers and/or any other potentially sensitive information. The key format described herein may include one or more distinct parts, each of which can be arranged in any order.

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

In some embodiments, the term "match code" refers to a session-unique identifier used to authorize a registration session between one or more entities. For example, a match code may include a sequence of numbers, alphanumeric characters, and/or similar characters, which may be provided to multiple entities to ensure that each of the multiple entities is involved in the same sequence of communications. For instance, a match code may include an eight-character sequence that may be generated by an exchange platform, provided to a service provider platform, and then received from a partner platform to ensure that the exchange platform, service provider platform, and partner platform each interact with the same end user (e.g., by comparing the received match code with the generated match code described herein).

III. Computer program products, methods, and computing entities

Embodiments of this disclosure can be implemented in various ways, including as a computer program product comprising an article of manufacture. Such a computer program product may include one or more software components, including, for example, software objects, methods, data structures, etc. The software components can be encoded in any of a variety of programming languages. The descriptive programming language may be a low-level programming language, such as assembly language associated with a specific hardware architecture and/or operating system platform. Software components including assembly language instructions may need to be converted into executable machine code by an assembler before being executed by the hardware architecture and/or platform. Another example programming language may be a high-level programming language that is portable across multiple architectures. Software components including high-level programming language instructions may need to be converted into an intermediate representation by an interpreter or compiler before execution.

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 from one of the programming language examples described above can be executed directly by an operating system or other software components without first being converted to another form. Software components can be stored as files or other data storage structures. Software components of similar type or with related functionality can be stored together, for example, in specific directories, folders, or libraries. Software components can be static (e.g., pre-built or fixed) or dynamic (e.g., created or modified at runtime).

Computer program products can include non-transitory computer-readable storage media that store applications, programs, program modules, scripts, source code, program code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, execution instructions, computer program products, program code, and/or similar terms used interchangeably herein). Such non-transitory computer-readable storage media includes all computer-readable media (including volatile and non-volatile media).

In one embodiment, a non-volatile computer-readable storage medium may include a floppy disk, a hard disk, a solid-state storage (SSS) (e.g., a solid-state drive (SSD), a solid-state card (SSC), a solid-state module (SSM), an enterprise-class flash drive, magnetic tape, or any other non-transitory magnetic medium, etc.). Non-volatile computer-readable storage media may also include punched cards, paper tape, optical marking sheets (or any other physical medium having a perforated pattern or other optically identifiable markings), optical disc read-only memory (CD-ROM), rewritable optical disc (CD-RW), digital versatile optical disc (DVD), Blu-ray disc (BD), any other non-transitory optical medium, etc. Such non-volatile computer-readable storage media may also include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and electrically erasable read-only memory (EEPROM). Programmable read-only memory (EEPROM), flash memory (e.g., serial, NAND, NOR, etc.), multimedia memory cards (MMC), secure digital storage (SD) cards, smart media cards, compact flash memory (CF) cards, Memory Stick, etc. In addition, non-volatile computer-readable storage media can also include conductive bridged 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.

In one embodiment, a volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data output dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type 2 synchronous dynamic random access memory (DDR2 SDRAM), double data rate type 3 synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), dual transistor RAM (TTRAM), thyristor RAM (T-RAM), zero capacitor (Z-RAM), Rambus through-hole memory module (RIMM), dual in-line memory module (DIMM), single in-line memory module (SIMM), video random access memory (VRAM), cache memory (including various levels), flash memory, register memory, etc. It should be understood that, in the case where the embodiments are described as using computer-readable storage media, other types of computer-readable storage media may be used instead of the computer-readable storage media described above.

It should be understood that the various embodiments of this disclosure can also be implemented as methods, apparatus, systems, computing devices, computing entities, etc. Therefore, embodiments of this disclosure can take the form of data structures, apparatuses, systems, computing devices, computing entities, etc., executing instructions stored on a computer-readable storage medium to perform certain steps or operations. Therefore, embodiments of this disclosure can also take the form of entirely hardware embodiments, entirely computer program product embodiments, and/or embodiments including a combination of computer program products and hardware that perform certain steps or operations.

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.

IV. Example System Architecture

Figure 1 illustrates a computing ecosystem 100 that can be used in conjunction with various embodiments of this disclosure. As shown in Figure 1, 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., associated with 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.

For example, each component in 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 cross any geographical boundary (e.g., connections between countries involving one or more sovereign entities, etc.). Furthermore, while Figure 1 shows some systems as separate, independent entities, various embodiments are not limited to this particular architecture.

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

a. Example computing platform

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 switching platform 102 of Figure 1, member platforms 112a-c, etc., may include or communicate with one or more processing elements 202 (also referred to as processors, processing circuitry, and/or similar terms used interchangeably herein), for example, the processing elements 202 communicate with other elements within the computing platform 200 via a bus. It will be understood that the processing elements 202 may be embodied in a variety of different ways.

For example, processing element 202 may be embodied as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, coprocessor entities, application-specific instruction set processors (ASIPs), microcontrollers, and/or controllers. Furthermore, processing element 202 may be embodied as one or more other processing devices or circuits. The term "circuit" can refer to a completely hardware embodiment or a combination of hardware and computer program products. Therefore, processing element 202 may be implemented as an integrated circuit, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic array (PLA), hardware accelerator, other circuits, etc.

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

In some embodiments, the computing platform 200 includes or communicates with nonvolatile memory 204 (also referred to as nonvolatile memory, medium, memory, memory circuitry, and/or similar terms used interchangeably herein). In some examples, nonvolatile memory 204 may include one or more nonvolatile memories or storage media, including but not limited to hard disks, ROMs, PROMs, EPROMs, EEPROMs, flash memory, MMC, SD memory cards, Memory Sticks, CBRAMs, PRAMs, FeRAMs, NVRAMs, MRAMs, RRAMs, SONOS, FJG RAMs, Millipede memory, racetrack memory, etc.

It should be recognized 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, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. The terms database, database instance, database management system, and/or similar terms used interchangeably herein 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, graphical model, etc.).

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

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.

As described above, in one embodiment, computing platform 200 may further include one or more network interfaces 208 for communicating with various computing entities (e.g., one or more components of FIG. 1), such as transmitting, receiving, manipulating, processing, displaying, storing, etc., by sending data, content, information, and/or similar terms used interchangeably herein. Such communication may 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.

Although not shown, the computing platform 200 may include or communicate 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 may also include or communicate with one or more output elements (not shown), such as audio output, video output, screen/display output, motion output, movement output, etc.

As described above, computing platform 200 may be an example of one or more components in Figure 1, such as exchange platform 102 and/or member platforms 112a-c.

b. Example client device

Figure 3 is an example schematic diagram of a client device 104 according to one or more embodiments of the present disclosure. The client device 104 can be operated by various entities, and an example computing ecosystem may include one or more client devices 104. For example, the client device 104 may be associated with, owned by, operated by, or otherwise controlled by one or more end users. In various embodiments, the end user of the client device 104 may wish to participate in a value exchange between partners and service providers. As described herein, the user can achieve the above operations by utilizing one or more functional interactions provided through user input from the client device 104.

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

The signals provided to transmitter 304 and received from receiver 306 may include signaling information/data according to the air interface standard of the applicable wireless system. In this regard, client device 104 can operate using one or more air interface standards, communication protocols, modulation types, and access types. More specifically, client device 104 can operate according to any of a variety of wireless communication standards and protocols, such as those described above with respect to computing platform 200. In certain embodiments, client device 104 can operate according to a variety of wireless communication standards and protocols, such as UMTS, CDMA2000, 1xRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, etc. Similarly, client device 104 can operate via a variety of wired communication standards and protocols, such as those described above with respect to computing platform 200 via network interface 320.

Through these communication standards and protocols, client device 104 can communicate with computing platform 200 using concepts such as Unstructured Supplemental Service Data (USSD), Short Message Service (SMS), Multimedia Messaging Service (MMS), Dual-Tone Multi-Frequency Signaling (DTMF), and/or Subscriber Identity Module Dialer (SIM Dialer). Client device 104 can also download changes, add-ons, and updates to its firmware, software (e.g., including executable instructions, applications, program modules), and operating system.

In some embodiments, client device 104 includes location determination aspects, devices, modules, functions, and/or similar terms used interchangeably herein. For example, client device 104 may include outdoor positioning aspects, such as a location module adapted to acquire information/data such as latitude, longitude, altitude, geocoding, route, direction, heading, speed, world time (UTC), date, and/or various other information/data. In one embodiment, the location module acquires data, sometimes referred to as ephemeris data, by identifying the number of satellites in the field of view and the relative positions of these satellites (e.g., using a Global Positioning System (GPS)). Satellites can be a variety of 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 Satellite System, the Indian Regional Navigation Satellite System, etc. This data can be collected using various coordinate systems, such as decimal degrees (DD); degrees, minutes, and seconds (DMS); Universal Transverse Mercator (UTM); Universal Polar Stereographic (UPS) coordinate system, etc. Alternatively, location information/data can be determined by triangulation of the client device 104's location in conjunction with various other systems, including cell towers, Wi-Fi access points, etc. Similarly, the client device 104 may include indoor positioning aspects, such as a location module adapted to acquire information/data such as latitude, longitude, altitude, geocoding, route, direction, heading, speed, time, date, and/or various other information/data. Some indoor systems may use various location or positioning technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cell towers, nearby computing devices (e.g., smartphones, laptops), etc. These technologies may include, for example, iBeacons, gimbaled proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, etc. These indoor positioning aspects can be used in various setups to determine the location of a person or object with an error within inches or centimeters.

In some embodiments, client device 104 may include user interface 316 (e.g., a display screen, speaker, haptic mechanism, etc. coupled to processing element 308) and/or user input interface 318 (e.g., a touchscreen, microphone, etc. connected to processing element 308). For example, user interface 316 may be one or more application screens presented by one or more computing platforms described herein. User input interface 318 may include any of a plurality of devices or interfaces that allow 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 the example including a keyboard, the keyboard may include (or cause to display) conventional numbers (0-9) and associated keys (#, *), as well as other keys for operating client device 104, and may include a full set of alphanumeric keys or a set of keys that can be activated to provide a full set of alphanumeric keys. In addition to providing input, the user input interface may also be used to, for example, activate or deactivate certain functions, such as screen savers and/or sleep modes.

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

In some embodiments, as described in more detail above, client device 104 may include one or more components or functions that are the same as or similar to those of computing platform 200. As will be appreciated, these architectures and descriptions are provided for illustrative purposes only and are not limited to various embodiments.

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

c. Example Network

In some embodiments, any two or more of the illustrative components of the computing ecosystem 100 of FIG1 may be configured to communicate with each other via respective communication couplings of one or more networks 120. Network 120 may include, but is not limited to, any one or a combination thereof of suitable communication networks of different types, 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. Furthermore, network 120 may have any suitable communication range associated with it and may include networks such as global networks (e.g., the Internet), MANs, WANs, LANs, or PANs. Additionally, network 120 may include any type of medium capable of carrying network traffic, including but not limited to coaxial cable, twisted pair, optical fiber, hybrid fiber-coaxial (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.

d. Example value exchange system

Figure 4 is an exemplary block diagram of an exemplary network-based exchange system 400 according to one or more embodiments of the present disclosure. The network-based exchange system 400 includes a new computing ecosystem and computing platform that provides end-to-end value exchange solutions 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 exchange, financial exchange, reputation-based exchange, healthcare-based exchange, benefit-based exchange, etc. In any value system, the network-based exchange system 400 can utilize intermediary entities and one or more defined communication interfaces to facilitate network-based exchange between value-seeking entities (e.g., partners) and value-providing entities (e.g., service providers), which may be associated with one or more member platforms of the network-based exchange system 400.

As shown, the network-based switching system 400 may include a switching platform 102, a partner platform 420, and/or a service provider platform 440, and the system may be configured to communicate through one or more switching interfaces. Partner platform 420 and/or service provider platform 440 may include one or more member platforms 112a-c from member platform network 110. For example, partner platform 420 and service provider platform 440 may include a single member platform (e.g., member platform 112c). Additionally or alternatively, partner platform 420 and service provider platform 440 may include one or more different member platforms (e.g., member platforms 112a and 112b). In some examples, a user may interact with one or more platforms through client device 104.

In some embodiments, the exchange platform 102 is a computing entity configured to facilitate credentialless value exchange among one or more members in a network. The exchange platform 102 may include one or more processing devices, storage devices, etc., physically and/or wirelessly coupled and configured to collectively (and/or individually) perform one or more computational tasks facilitating credentialless exchange within the value system. In some examples, the exchange platform 102 may include, define, and/or otherwise utilize one or more exchange interfaces to facilitate communication (e.g., requests, responses, etc.) between multiple members. As described herein, interfaces can be used to facilitate secure exchange between one or more members in any value system.

In some embodiments, a member is an entity that collaborates with exchange platform 102 to participate in a value exchange. As an example, a member may include (i) a collaborator that receives value using exchange platform 102, (ii) a service provider that provides value using exchange platform 102, and/or (iii) both a collaborator and a service provider. As used herein, a member may be referred to as a collaborator when receiving value through a value exchange, and/or as a service provider when providing value through a value exchange. Thus, depending on the member's role in the value exchange, the same member may be either a collaborator or a service provider. For example, a member may be a collaborator that receives value through a value exchange. The same member may be a service provider that provides value in another value exchange. In some examples, the same member may be both a collaborator and a service provider in the same value exchange, such that the member may use exchange platform 102 to provide and subsequently receive value in a single member value exchange.

In some embodiments, a member is a collaborator when using services provided by a service provider. A collaborator can include any value-seeking entity in any value system. For example, in a financial value system, a collaborator might include merchants (e.g., retailers, brick-and-mortar stores, etc.) who can use a service provider (e.g., a financial institution) to access funds for financial transactions. Additionally or alternatively, in an information value system, a collaborator might include news publishers (e.g., newspapers, media organizations, etc.) who can use service providers such as news agencies (e.g., news agencies, news services, etc.) to access information for information transactions. It is understood that the techniques disclosed herein can be applied to any value system, and a collaborator can include any value seeker in any given value system.

In some embodiments, a member is a service provider when providing services to a collaborator. A service provider can include a source of value in any value system. For example, in a financial value system, a service provider may include financial institutions (e.g., banks, currency exchange platforms, credit unions, etc.) that provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a service provider may include news organizations (e.g., news agencies, news services, etc.) that provide information sources for news publishers' releases. It is understood that the techniques disclosed herein can be applied to any value system, and a service provider may include any source of value in any given value system.

Service providers and partners can communicate through one or more member platforms, each associated with an entity. As an example, a service provider may be associated with service provider platform 440, while a partner may be associated with partner platform 420.

In some embodiments, a member platform is a computing entity corresponding to a member associated with exchange platform 102. A member platform may 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 may be both partner platform 420 and service provider platform 440. For example, the same member platform may be configured to operate on behalf of a partner in one value exchange and a service provider in another value exchange. In some examples, the same member platform may 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 may refer to partner platform 420, service provider platform 440, or both, and in some examples, may depend on the member platform's role in the value exchange (e.g., and/or one or more interfaces used by the member platform in the value exchange).

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

For example, in a financial value system, a partner platform 420 may host an online marketplace for partners, allowing users to interact with one or more products or services offered by the partners (e.g., searching, browsing, purchasing, returning, etc.). In the case of purchasing products, the partner platform 420 may partner with one or more service providers to access the purchase funds. Traditionally, users need to use card numbers, account numbers, and/or other financial credentials to access funds from service providers, but this can expose users to malicious attackers. To address cybersecurity and data privacy issues in traditional financial systems (and/or other value-based systems), the partner platform 420 may register with the exchange platform 102 by configuring one or more software development kits (SDKs), APIs, and/or the like to facilitate communication with the exchange platform 102. For example, the partner platform 420 may include, define, and/or otherwise utilize one or more partner interfaces 402 to facilitate communication with the exchange platform 102 (e.g., requests, responses, etc.).

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 may include one or more processing devices, storage devices, etc., physically and/or wirelessly coupled and configured to collectively (and/or individually) perform one or more computational tasks for providing value in an agnostic exchange within a value system. In some examples, service provider platform 440 may include, implement, and/or otherwise utilize one or more interfaces to facilitate communication with exchange platform 102 (e.g., requests, responses, etc.). In some examples, service provider platform 440 may be configured to facilitate one or more service provider tools. In some examples, service provider platform 440 may be configured to host one or more user-facing applications (e.g., service provider applications, etc.) for managing one or more service provider tools.

In some examples, such as in a financial value system, service provider platform 440 may maintain one or more financial assets (e.g., credit lines, bank accounts, etc.) to allow users to fund transactions for purchasing products from partners. If a product purchase occurs, service provider platform 440 may work with partner platform 420 to authorize the transaction and/or otherwise provide access to the purchase funds. Traditionally, facilitating access to funds from a service provider by providing card numbers, account numbers, and/or other financial credentials to service provider platform 440 can expose users, service providers, or partners to malicious parties, especially when provided over insecure networks (e.g., public networks, etc.). To address cybersecurity and data privacy concerns in traditional financial systems (and/or other value-based systems), service provider platform 440 may register with exchange platform 102 by configuring one or more software development kits (SDKs), APIs, and/or similar tools to facilitate communication with exchange platform 102. For example, service provider platform 440 may include, implement, and/or otherwise utilize one or more service provider interfaces 404 to facilitate communication with exchange platform 102 (e.g., requests, responses, etc.).

As described herein, the service provider interface 404 enables the exchange platform 102 to identify and request the use of service provider tools to facilitate transactions. For example, the service provider platform 440 can be configured to facilitate one or more service provider tools.

In some embodiments, service provider tools are mechanisms used by a service provider to deliver value (e.g., on behalf of a specific user, organization, etc.). Service provider tools may depend on the value system and/or the service provider. In some examples, service provider tools may include accounts at the service provider. For example, in a financial value system, service provider tools may include bank accounts (e.g., checks, savings, etc.), brokerage accounts, credit lines, etc. In information value systems, benefit value systems, etc., service provider tools may include member accounts, etc. In some examples, service provider tools may include virtual tools (e.g., virtual accounts, credit lines, etc.) hosted by the service provider platform 440. For example, the service provider platform 440 may be configured to maintain multiple member tool data objects that indicate multiple service provider tools for multiple affiliated entities.

In some embodiments, a tool data object is a data entity representing a service provider tool. A tool data object may 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 may be based on the type of the tool data object. For example, a service provider tool may be represented as a member tool data object in a member platform (e.g., service provider platform 440). Additionally or alternatively, a service provider tool may be represented independently by a system tool data object in exchange platform 102. In some examples, member tool data objects and system tool data objects may include the same one or more tool identifiers and/or one or more tool attributes. For example, a member platform may register multiple service provider tools with exchange platform 102 (e.g., using service provider interface 404). During registration, the member platform (e.g., service provider platform 440) may provide one or more tool identifiers and/or tool attributes, and in some examples, exchange platform 102 may return another identifier.

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

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

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

In some embodiments, a user-oriented application is a computer program hosted by a computing entity to facilitate interaction between one or more users. A user-oriented application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks for a computing entity such as a member platform. For example, a user-oriented application may facilitate communication between members and users. As an example, a user-oriented application may be configured to present one or more user interfaces 406 (e.g., via client device 104) on behalf of a member to interact with a user. In some examples, a user-oriented application may be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from a user.

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 specific exchange) to facilitate the partner's functionality. The partner application may include software (e.g., computer-readable instructions, etc.) designed to enable the partner to perform one or more computational tasks. In some examples, partner application 416 may be configured with one or more devices (e.g., point-of-sale terminals, etc.) from an independent partner institution (e.g., a physical bank, etc.). For example, partner application 416 may be configured to present one or more user interfaces 406 for interacting with one or more products offered by a retail-based partner, one or more information units offered by an information-based partner, etc. (e.g., browsing, purchasing, viewing, etc.). In some examples, partner application 418 may be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from a user.

In some embodiments, 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, a user-facing application may be a service provider application 418 hosted by service provider platform 440 (e.g., a member platform of a service provider acting as a specific exchange) to facilitate the functionality of the service provider. In some examples, service provider application 418 may be configured with one or more devices from independent service provider institutions (e.g., physical banks, etc.). Service provider application 418 may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computational tasks of the service provider. For example, service provider application 418 may be configured to present one or more user interfaces to interact with one or more service provider tools provided by the service provider (e.g., viewing, managing, auditing, registering, etc.). For instance, in a financial value system, service provider application 418 may have access to bank accounts, brokerage accounts, credit lines, etc., to manage funds, assets, etc., processed by the various 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 the user.

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

In some embodiments, an 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 may include APIs, file-based interfaces, message queue-based interfaces, etc. For example, the exchange interface may include APIs, such as one or more Simple Object Access Protocol (SOAP) APIs, one or more Remote Procedure Call (RPC) APIs, one or more WebSocket APIs, one or more Representational State Transition (REST) APIs, etc. In some embodiments, the exchange interface may include one or more RPC APIs, such as one or more gRPC APIs.

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

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

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 may define one or more communication instructions, message definitions, etc., 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 may include APIs that define (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 may define one or more registration messages, session messages, transaction messages, etc., to facilitate value exchange using service provider tools. In some embodiments, the service provider interface 404 defines one or more identifiers for securely identifying one or more parts of the value exchange.

Exchange platform 102 can facilitate communication between member platform networks. For example, a member network may include multiple entities that have joined exchange platform 102, such as by registering with exchange platform 102 and configuring appropriate interfaces for communication with exchange platform 102. In some examples, exchange platform 102 may perform one or more individual services to interact with each joined entity. For example, each service may include one or more partner services 410 and/or service provider services 412.

In some embodiments, the exchange platform 102 instantiates a separate collaborator-specific service, namely collaborator service 410, for each member network. Additionally or alternatively, for example in a multi-tenant environment, collaborator service 410 may be instantiated for one or more collaborators from the network or members. Collaborator service 410 may be configured to perform one or more exchange operations to resolve exchange requests from collaborator platform 420. In some embodiments, the exchange platform 102 instantiates a separate service provider-specific service, namely service provider service 412, for each member network. Additionally or alternatively, for example in a multi-tenant environment, service provider service 412 may be instantiated for one or more service providers from the network or members. Service provider service 412 may be configured to perform one or more exchange operations to acquire and resolve exchange requests from collaborator platform 420. Exchange operations may include any steps and/or operations described herein.

In some embodiments, Partner Service 410 and/or Service Provider Service 412 interact with each other and/or with 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 may include Connection Service 408, which is configured to establish, maintain, and authenticate secure network sessions with member platforms (e.g., Partner Platform 420). In some examples, Connection Service 408 and/or Partner Service 410 may cooperate to register users (and/or users' service provider tools) with Exchange Platform 102. Additionally or alternatively, Partner Service 410 and/or Service Provider Service 412 may cooperate to register users (and/or users' service provider tools) and/or facilitate value exchange between Partner Platform 420 and Service Provider Platform 440. In some examples, Connection Service 408 may be part of Partner Service 410.

By performing one or more exchange operations, partner service 410 and/or service provider service 412 can generate and utilize multiple non-traditional identifiers to refer to one or more aspects of the user, service provider tools, and/or value exchange. At least some of these identifiers may include universally unique identifiers, such as UUEK, which can be used to provide credentialless value exchange. Each identifier may be stored at least temporarily in platform database 414. Platform database 414 may include any type of storage device as described herein. In some examples, each service and/or one or more groups of services may be associated with a separate portion of platform database 414.

As described herein, one or more identifiers may be stored in association with each other to form an identifier mapping, which exchange platform 102 (and/or one or more of its services) may use to reference users, service provider tools and/or any other aspect of the value exchange of communications between partner platform 420, service provider platform 440 and/or any other member platform, without including user credentials. An example of a non-traditional identifier will now also be described with reference to Figure 5.

e. Example Data Structure

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

As shown in the figures, some of the various related identifiers in the various embodiments of this disclosure may 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., service provider platform 440), (iii) one or more cooperative 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 user references 502 and/or tool references 520, (vi) one or more exchange identifiers 510 that can be mapped to system identifiers 512 and/or keys 516, and/or (vii) one or more UUEKs 524 that can be mapped to at least one of exchange identifiers 510 and/or partner partitions 506 and/or service provider partitions 504.

In some examples, the service provider platform 440 may store one or more identifiers that can be mapped to one or more identifiers of the service provider tool 518 and/or the exchange platform 102, so that the service provider platform 440 can reference the service provider tool 518 at least in part based on the identifiers, which do not in themselves indicate any aspect of the service provider tool 518, including its permanent credentials 514.

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

As another example, exchange platform 102 may store, maintain, and/or otherwise access one or more references, such as tool references 520 and/or user references 502 mapped to (e.g., copies, derivatives, etc.) one or more member identifiers, such as member tool identifiers 508 and/or member user identifiers 522 of service provider platform 440. For example, references may be provided during the registration process between service provider platform 440 and/or exchange platform 102.

In some embodiments, the exchange platform 102 uses one or more entity partitions to refer to each member platform of the member platform network. In some embodiments, an entity partition is a unique identifier for a computing entity. An entity partition may include unique numbers, alphanumeric characters, etc., representing a particular computing entity. For example, an entity partition may include a member partition representing a member platform, a service provider partition 504 representing a service provider platform 440, a partner partition 506 representing a partner platform 420, etc.

In some embodiments, service provider partition 504 is a unique identifier for a service provider and/or a service provider platform 440 associated with the service provider. Service provider partition 504 may include sequences of numbers, alphanumeric characters, and/or any other characters or symbols representing a service provider associated with exchange platform 102 (e.g., joining, registering, etc.). For example, exchange platform 102 may include multiple service provider partitions that individually identify service provider platforms 440 associated with exchange platform 102 (e.g., joining, registering, etc.). Each service provider partition 504 may represent a service provider platform 440 that has been configured with one or more exchange platform software development kits (SDKs) or similar tools to implement the service provider interface of exchange platform 102.

In some embodiments, partner partition 506 is a unique identifier for a partner and/or a partner platform of a partner. Partner partition 506 may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols representing a partner associated with exchange platform 102. For example, exchange platform 102 may include multiple partner partitions that identify partner platforms associated with exchange platform 102 (e.g., joining, registering, etc.). Each partner partition 506 may represent a partner platform that has been configured with one or more exchange SDKs, etc., to implement the partner interface of exchange platform 102.

In some embodiments, when a member platform joins exchange platform 102, an entity partition is generated to identify the member. In some examples, after joining the exchange platform, a member platform may register one or more service provider tools with exchange platform 102 using one or more exchange interfaces. Service provider tools 518 register with exchange platform 102 by exchanging one or more tool identifiers with exchange platform 102.

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

In some embodiments, the member tool identifier 508 is a unique identifier used to represent a service provider tool 518 within a member platform (e.g., service provider platform 440). For example, the member tool identifier 508 may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols used to represent the service provider tool 518 to the service provider platform 440. In some examples, the member tool identifier 508 may include a table identifier for a member tool data object.

In some embodiments, tool reference 520 is a unique identifier used to reference member tool identifier 508. For example, tool reference 520 may be generated by and/or provided to exchange platform 102 to allow exchange platform 102 to reference service provider tools 518 maintained on the member platform. In some examples, tool reference 520 is the same value as member tool identifier 508. In some examples, tool reference 520 is a different value mapped to member tool identifier 508.

In some embodiments, a system tool identifier is a unique identifier used to represent a service provider tool 518 within the exchange platform 102. For example, a system tool identifier may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols representing the service provider tool 518 to the exchange platform 102 without exposing the service provider tool 518's persistent credentials 514. In some examples, the system tool identifier may include a UUID. In some examples, the system tool identifier may include at least one of system identifiers 512.

In some embodiments, a tool key is a unique identifier used to reference a system tool identifier. For example, during the registration of service provider tool 518 with exchange platform 102, exchange platform 102 may generate and/or provide a tool key. In some examples, the tool key may include an encapsulated system tool identifier. For example, the tool key may include an alphanumeric string formatted according to a key format established by exchange platform 102 (and/or one or more of its APIs). The key format may include any number of characters, for example, fifty characters or more. In some examples, the characters may be case-sensitive. The first portion of the characters (e.g., the first six characters) may be reserved as a partition for identifying the entity associated with the key. For example, for a tool key, a partition may include service provider partition 504. The second portion of the characters may identify the system tool identifier. In some examples, the tool key may include at least one of keys 516. The key format described herein may include one or more distinct portions, each of which may be arranged in any order.

In some embodiments, after joining exchange platform 102, a member platform may register one or more users with exchange platform 102 using one or more exchange interfaces. Users can register with exchange platform 102 by exchanging one or more user identifiers with exchange platform 102. For example, user identifiers can be used to generate, maintain, and/or update one or more user data objects reflecting users of member platforms and/or exchange platform 102.

In some embodiments, a user data object is a data entity representing a user interacting with the member platform and/or exchange platform 102. For example, a user may include entities (e.g., individuals, organizations, groups, etc.) that participate in value exchanges managed by exchange platform 102. In some examples, a user may indirectly interact with exchange platform 102 by creating a user account with a registered service provider, registering (and/or granting registration permission) with service provider tool 518, etc. In some examples, exchange platform 102 may act on behalf of the user without requiring direct interaction between the user and exchange platform 102. For example, exchange platform 102 may act as a hidden intermediary between user-facing applications and the user's service provider tool 518.

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 may be based on the 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 represented independently by a system user data object in an exchange platform. In some examples, member user data objects and system user data objects may include the same one or more user identifiers and/or one or more user attributes. For example, a member platform may register multiple users with exchange platform 102. During registration, the member platform may provide one or more user identifiers and/or user attributes, and in some examples, exchange platform 102 may return another identifier.

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

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

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

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

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

In some embodiments, user reference 502 may be a unique identifier used to reference member user identifier 522. For example, user reference 502 may be generated by and/or provided to exchange platform 102 to allow exchange platform 102 to reference a user associated with member platform. In some examples, user reference 502 is the same value as member user identifier 522. In some examples, user reference 502 is a different value mapped to member user identifier 522.

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

As shown in Figure 5, for example, the user and tool keys described herein can be shared between exchange platform 102 and service provider platform 440, with key 516. Furthermore, in some examples, references such as tool reference 520 and user reference 502 can be shared between entities. These identifiers and the mapping scheme described herein allow exchange platform 102 to reference service provider tool 518 without knowing the service provider tool 518's persistent credentials 514 (e.g., card number, etc.). As described herein, one or more of key 516 and/or references can be provided to service provider platform 440 individually or in any combination. In some examples, each of key 516 and references can be provided to service provider platform 440 in a redundancy process that allows the service provider platform to verify that the communication was provided by exchange platform 102 (e.g., an entity authorized to access a specific set of keys and references).

In some embodiments, the persistent credentials 514 of the service provider tool 518 include sensitive user and/or tool credentials, such as card numbers, account numbers, subscription numbers, etc., which may expose users, members, and/or intermediary entities to risk. When a user applies for, is authorized, and/or is otherwise able to open a new service provider tool 518, the service provider platform 440 may generate, access, and/or otherwise provide the user with the persistent credentials 514. Traditionally, the user then uses the persistent credentials 514 to initiate a value exchange through the service provider tool. This forces the user to expose sensitive credentials directly bound to the service provider tool 518 each time it is used. The key 516, reference, and identifier mapping scheme disclosed herein overcomes these technical drawbacks.

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. In order 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 identifiers that further enhance Figure 5.

In some embodiments, the instrument representation (not shown in FIG5) is a unique identifier used to represent the service provider tool 518 to a user without exposing the permanent credential 514 of the service provider tool 518. For example, the instrument representation may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that externally represent the service provider tool 518 only to entities with prior knowledge of it. The format and/or value of the instrument 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 instrument representation may include a portion of the 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 instrument representation may include a portion of the permanent credential 514 (e.g., one or more numeric, alphanumeric characters, etc.), such as a subscription account, etc. For example, the instrument representation may include derivatives of the permanent credential 514 that may only allow entities with prior knowledge of the permanent credential 514 to use the instrument representation to identify the permanent credential 514. As another example, a tool representation may include a tool nickname assigned by the user and subsequently recognized by the user.

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.

In some embodiments, the identifier mapping scheme is supplemented by a unique temporary key issued to member platforms to facilitate secure, real-time value exchange. For example, 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 may include service provider-specific exchange identifiers and/or partner-specific exchange identifiers. Service provider-specific exchange identifiers may include temporary, unique exchange identifiers that temporarily represent service provider tool 518 and service provider platform 440. For example, a service provider-specific exchange identifier may be mapped to a system identifier 512 for service provider tool 518. Partner-specific exchange identifiers may include temporary, unique exchange identifiers that temporarily represent service provider tool 518 and partner platform. For example, a partner-specific exchange identifier may be mapped to a key 516 used for service provider tool 518, which can be used to identify service provider platform 440. In some examples, such mapping may be defined by exchange data objects.

In some embodiments, an exchange data object is a data entity representing an authorized value exchange between one or more members associated with exchange platform 102. In some examples, an exchange data object may include one or more identifiers and/or one or more exchange attributes. For example, one or more identifiers and/or one or more exchange attributes may be based on the type of the exchange data object. For instance, an exchange may be represented as a member exchange data object in a member platform. Additionally or alternatively, an exchange may be represented independently by a system exchange data object in exchange platform 102. In some examples, member exchange data objects and system exchange data objects may include the same one or more identifiers and/or one or more exchange attributes. For example, using some techniques of this disclosure, exchange platform 102 may issue one or more unique identifiers to member platforms that can be used to authorize value exchanges.

In some embodiments, a system exchange data object is an internal representation of a value exchange mediated using 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 may include one or more distinct identifiers and/or exchange attributes.

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

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

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

In some embodiments, the exchange identifier 510 is a unique identifier used for value exchange with the exchange platform 102. The exchange identifier 510 may include a sequence of numbers, alphanumeric characters, and/or any other characters or symbols that at least represent a user and/or service provider tool 518. In some examples, the exchange identifier 510 may include a universally unique identifier (UUID) that can be mapped (e.g., through a series of identifiers, etc.) to a user, service provider tool 518, and/or a member registered with the exchange platform 102. In some examples, one or more UUID generators may be used to generate the exchange identifier 510. For example, the exchange identifier 510 may include sixteen bytes of information generated according to one or more UUID formatting standards (e.g., UUID v4, etc.). Therefore, while the exchange identifier 510 may be used by the exchange platform 102 and/or member platforms for one or more functions, the same exchange identifier 510 will be useless to external parties if there is no prior association between the exchange identifier 510 and one or more other identifiers. In addition to previous identifier associations, the exchange identifier 510 may also be associated with the exchange platform 102. Therefore, even if the exchange identifier 510 is recognized by the other party, the other party still needs to impersonate the exchange platform 102 to use the exchange identifier 510. Furthermore, before the exchange identifier 510 can be misused, the other party needs to update the settlement account to an account owned by the other party, and perform many other tasks. Each of these tasks increases the workload required to overcome the enhanced security layer added by the exchange identifier 510. When temporarily pairing with the exchange identifier 510, these tasks can become exceptionally expensive and daunting.

In some examples, the exchange identifier 510 may be externally represented by the UUEK 524. For instance, to facilitate credentialless exchange, the exchange platform 102 may issue one or more UUEKs 524 to one or more member platforms. As described herein, the UUEK 524 can eliminate reliance on the traditional permanent credential 514 by identifying aspects of the value exchange via previously mapped data entities.

In some embodiments, UUEK 524 is an external representation of exchange identifier 510, which can be issued (e.g., in place of exchange identifier 510) to external entities, such as users, partner platforms, and/or service provider platforms, to initiate value-based exchanges using exchange platform 102. For this purpose, exchange platform 102 can generate UUEK 524 and issue it to external entities. Each UUEK 524 may include multiple values (e.g., up to fifty and/or more characters, case-sensitive or case-insensitive) representing one or more aspects of the value-based exchange. For example, the multiple values may indicate exchange identifier 510, partition (e.g., identifying the recipient of UUEK 524), identifier type, and/or one or more flags. For instance, UUEK 524 may include partner-specific UUEKs and/or service provider-specific UUEKs. As described herein, a partner-specific UUEK may be associated with a partner-specific exchange data object and may include a partner partition 506, while a service provider-specific UUEK may be associated with a service provider-specific exchange data object and may include a service provider partition 504.

For example, a UUEK 524 can be generated based on a key format. The key format may include multiple characters, for example, fifty or more characters, and may be case-sensitive or insensitive. The first portion of the characters (e.g., the first six characters) may be reserved as a partition used to identify the recipient of the UUEK 524. For example, this partition may include a partner partition 506, a service provider partition 504, and/or any other member partition. For instance, a UUEK 524 may be issued in response to a request from an authorized member (e.g., related to a partner and/or service provider).

Additionally or alternatively, at least one character of the key format (e.g., the seventh character) may identify the format of UUEK 524. At least another character (e.g., the eighth character) may identify the type of UUEK 524. In some examples, the second part of the character may identify the exchange identifier 510 (e.g., a set of twenty-two characters following the eighth character). The third part of the character may be reserved (e.g., a set of twenty characters following the first part of the character). Example representations are provided below:

ppppppFiGGGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrr

Where p represents the partition character, F represents the format character, i represents the identifier type character, G represents the exchange identifier 510, and r represents the reserved character. The key format allows 9.8 × 10⁸⁴ unique permutations, a number greater than the number of atoms in the known observable universe. This enables the on-demand generation and distribution of new UUEK 524 keys without compromising the security of the underlying data to which UUEK 524 can be mapped, such as user and tool identifiers and/or any other potentially sensitive information.

As described herein, the unique sequence of identifiers and the mapping scheme between identifiers can facilitate credentialless value exchange systems for registered and/or unregistered entities. In some examples, one or more identifiers can be generated through a registration or sign-up process configured to establish cross-entity relationships between user, partner, and service provider entities. An example process for establishing cross-entity relationships will now also be described with reference to Figures 6A-C.

V. Example System Operation

Figures 6A-C provide a process flow for establishing cross-entity relationships according to one or more embodiments of this disclosure. This process flow illustrates one or more stages of a registration process 600 for registering user and/or service provider tools with an exchange platform to facilitate credentialless value exchange between partner platforms and service provider platforms. For illustrative purposes, Figures 6A-C illustrate an example process 600. Although example process 600 describes a specific sequence of steps/operations, this sequence can be changed without departing from the scope of this disclosure. For example, some of the described steps/operations may be performed in parallel or in a different order without materially affecting the functionality of process 600. In other examples, different components of the example device or system implementing process 600 may perform the function substantially simultaneously or in a specific order.

Various embodiments of Process 600 address the technical challenges related to data security and efficiency in network-based value exchange with one or more computing entities. Traditional systems use registration mechanisms to address these challenges, requiring users to expose sensitive and persistent credentials to third-party registration services. These traditional registration services then verify user account ownership and provide the persistent credentials to a partner platform for storage and subsequent processing. In doing so, user credentials are transmitted and exposed to multiple different entities during the traditional registration process, ultimately increasing the risk of exposure to malicious parties during and after network communication. Various embodiments of Process 600 provide improved network communication, data encryption, and data management techniques to enable credentialless exchange registration capabilities, thereby reducing the data security risks inherent in traditional processes.

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

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

In some embodiments, process 600 includes establishing a registration session for the user and the partner platform at step/operation 602. For example, the registration process 600 may begin on a partner application (e.g., a partner website, user application, etc.), where the partner platform can allow the user to register a partner account with the exchange platform on the partner application to access service provider tools. The partner platform can register the user by initiating a registration session with the exchange platform.

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

In some embodiments, a communication session request includes one or more registration attributes, such as user data, user identifier, user hash, timestamp, device identifier, partner identifier, etc. As described herein, some techniques of this disclosure enable computing entities to use identifiers to identify service provider tools without including persistent credentials for the service provider tools in the communication session request. For example, a partner platform may be configured to acquire user data (e.g., through user input on a user interface screen, pre-recorded data from a partner account, etc.) and provide the user data to an exchange platform to initiate the registration process. In some examples, the partner platform (e.g., through one or more API calls to a partner interface, etc.) may provide user data along with the communication session request to an exchange platform (e.g., its partner service) to initialize a widget session. In some examples, the user data may be encrypted, hashed, etc., before being transmitted to the exchange platform. In some examples, the user data may include one or more user attributes as described herein.

In some embodiments, the exchange platform (e.g., its partner service) uses a partner interface to receive a communication session request to initialize a registration session on the user's client device. In some examples, the communication session request may include the user's user data. Additionally or alternatively, the registration initialization request may include one or more user attributes. In some examples, as described herein, user attributes may be encrypted and/or hashed.

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

In some embodiments, process 600 includes generating a session identifier for a registration session at step/operation 606. For example, an 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 unique numbers, strings, etc., used to authenticate information exchanged during the registration session. The exchange platform can utilize the connection service and/or the partner service to establish the registration session. For example, in response to a registration initialization request, the partner service can invoke another service, such as the connection service, to establish a communication session that can be used by a client-side widget to provide an interface between the user and the partner service to complete user registration. The connection service can generate a session identifier and return it to the partner service. The partner service can return the session identifier to the partner platform, which can use the session identifier to initialize the client-side widget using an instance of the partner application on the client device. Once the partner application receives the session identifier, it can start (e.g., execute, initialize, etc.) the client-side widget. The user can then interact with the widget to complete registration process 600.

In some embodiments, process 600 includes determining and providing a member list for the user at step/operation 608. The member list may be a list of service providers. For example, an exchange platform (e.g., its connectivity services, partner services, etc.) may determine the user's list of service providers from a network of service providers associated with the exchange platform (e.g., those registered with it, etc.). In some examples, the service provider list may include each service provider platform associated with the exchange platform. Additionally or alternatively, the service provider list may include a subset of relevant service provider platforms tailored to the user.

For example, an exchange platform can identify one or more service provider platforms, at least in part, based on user attributes from a registration session, and customize the service provider list for those platforms. For instance, the exchange platform may include multiple 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 a user based on user attributes. In some examples, each system user data object can identify a service provider platform associated with the user. In this way, the exchange platform can identify one or more service providers associated with a user based on one or more system user data objects.

Additionally or alternatively, the exchange platform (e.g., one or more of its service provider services) may provide a presence request for user presence data from each service provider platform in the member platform network (e.g., via a service provider interface). The user presence request may include one or more user attributes (e.g., encryption attributes, hash attributes, etc.), which the service provider platform may use to determine whether the user possesses a tool on the service provider platform. In response to this request, the exchange platform (e.g., one or more of its service provider services) may receive presence data from one or more service provider platforms indicating the presence of tools on each service provider platform. The exchange platform (e.g., its partner services) may identify one or more service providers, at least in part, based on this presence data.

In some examples, the exchange platform (e.g., its connectivity service, partner service, etc.) may use a partner interface and a registration user interface provided by a partner application to initiate the presentation of a pre-registration screen, at least in part, based on one or more service providers. For example, the client device may be configured to access a partner application hosted by the partner platform. The registration user interface can be presented to the user on the client device via 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 may display multiple optional icons indicating a list of service providers.

Next, the registration process 600 can continue to the second stage, in which, as described in further detail with reference to Figure 6B, the tool identifier corresponding to the user is identified through the interaction between the exchange platform, the user, and the service provider platform.

Referring now to Figure 6B, which is a flowchart illustrating an example of the second phase of a registration process 600 for registering service provider tools with a partner platform without exposing persistent credentials associated with the user and/or the service provider tools, this flowchart describes communication techniques that overcome various limitations of traditional registration systems by circumventing the reliance of traditional systems on persistent credentials provided by the user (e.g., card numbers, etc.). These communication techniques can be implemented by one or more computing devices, entities, and/or systems (e.g., exchange platforms) described herein, establishing connections between the user, the partner platform, and the service provider tools.

In some embodiments, 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 may be determined at least in part based on the selection of a service provider from a pre-registration screen. For example, in some examples, an exchange platform (e.g., its connectivity service, partner service, etc.) may use a partner interface to receive pre-selection data indicating the selection of a specific service provider from one or more service providers presented on the pre-registration screen. For example, a widget may receive pre-selection data from a partner application and provide a tool registration request (e.g., via a partner interface) to the exchange platform (e.g., its connectivity service, partner service, etc.). The tool registration request may include a session identifier and/or a service provider identifier indicating the selected service provider.

In response to this request, the exchange platform (e.g., its connectivity services, partner services, etc.) may receive service provider-tool data, at least in part, based on pre-selected data. The service provider-tool data may indicate one or more service provider tools offered to the user by the selected service provider platform. For example, the service provider-tool data may include one or more system tool identifiers and/or corresponding 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 may include a system user identifier corresponding to the user.

Additionally or alternatively, the exchange platform (e.g., one or more of its service provider services) may provide tool requests for service provider-tool data from the selected service provider platform (e.g., via a service provider interface). For example, the tool request may include a user reference corresponding to a member user identifier of the service provider platform. In response to such a request, the service provider platform may 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 the exchange platform with service provider-tool data indicating one or more tool references and/or one or more corresponding tool representations.

The exchange platform (e.g., its connectivity services, partner services, etc.) may use the partner interface and, via a registration user interface, initiate the presentation of a tool registration screen via the user's client device, based at least in part on service provider-tool data. The tool registration screen may be defined internally by the partner and/or provided by the exchange platform. For example, the tool registration screen may indicate one or more service provider tools associated with the user and the selected service provider. For instance, the tool registration screen may indicate a corresponding tool representation for each of the one or more service provider tools. In some examples, such as when the user is only associated with a single service provider tool, the tool registration screen may include a confirmation prompt to confirm the user's intent to register for the service provider tool.

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

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

In some embodiments, the client-side widget can be configured to authenticate the user before initiating a registration tool with an account request. For example, the client-side widget can be configured to generate a user verification prompt based at least in part on 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 initiate the presentation of the user verification prompt using a partner interface. In response to user input indicating confirmation of at least a portion of the user data (e.g., one or more user attributes, etc.), the widget can provide the exchange platform with a registration tool with an account request.

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

In some embodiments, a match code is a session-unique identifier used to authorize a registration session between one or more entities. For example, a match code may include a sequence of numbers, alphanumeric characters, and/or similar characters that can be provided to multiple entities to ensure that each of the multiple entities is involved in the same communication sequence. For instance, a match code may include a sequence of one or more distinct characters of dynamic length (e.g., six, eight characters, etc.) that can be generated by an exchange platform, provided to a service provider platform, and then received from a partner platform to ensure that the exchange platform, service provider platform, and partner platform each interact with the same end user (e.g., by comparing the received match code with the generated match code described herein). One or more distinct characters may include one or more alphanumeric characters, emojis, Chinese characters, wingdings, etc.

In some embodiments, process 600 includes, at step/operation 616, providing a registration request with a matching code to a service provider platform corresponding to the service provider tool. For example, an exchange platform (e.g., its service provider service, etc.) may use a service provider interface to provide the registration request to the service provider platform corresponding to the service provider tool. The registration request may include service provider registration data indicating a matching 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 may use one or more identifiers to verify the service provider tool.

For example, service provider registration data may include one or more identifiers used to reference service provider tools in communications between exchange platforms, service provider platforms, and/or partner platforms, without using permanent credentials for the service provider tools (e.g., card numbers, account numbers, etc.). For example, one or more identifiers may include various combinations of user identifiers and/or tool identifiers to verify users and/or tools through one or more redundant checks. For example, a user's user identifier may include a user reference from the service provider platform and/or a user key from the exchange platform corresponding to the user reference. As another example, a service provider tool's tool identifier may include a tool reference from the service provider platform and/or a tool key from the exchange platform corresponding to the tool reference.

Service provider registration data may include any combination of references, keys, and/or identifiers described herein. In one example, service provider registration data may include one of a tool reference, a tool key, a user reference, and/or a user key. Additionally or alternatively, service provider registration data may include a combination of tool references, tool keys, user references, and user keys corresponding to built-in redundancy. In some examples, the combination of identifiers may be specified by an interface call. This combination may be service provider-specific and/or dynamically changeable depending on the communication scheme. In this way, a specific combination of identifiers provided in the registration request can be used as additional verification checks to ensure that the registration request is received from the relevant platform (e.g., an exchange platform).

Service providers can compare the identifier from the registration request with one or more member data objects (e.g., member tool data objects, member user data objects, etc.) to identify the service provider tool corresponding to the registration request without exposing the service provider tool's persistent credentials.

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

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

In some examples, the exchange platform can use a partner interface to initiate the presentation of an authentication user screen via a registration user interface. Essentially, simultaneously, the service provider platform can provide the user with a matching code (e.g., via a client device and/or other pre-configured 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 use the partner interface to receive authentication messages that are at least partially based on user input from the authentication user screen.

In some embodiments, the exchange platform authenticates the registration session in response to user authentication based at least in part on the matching code. As further described in detail with reference to Figure 6C, upon successful registration, control is transferred back to the partner application running on the client device, which requests UUEK.

Referring now to Figure 6C, which is a flowchart illustrating an example of the third stage of a registration process 600 for issuing a UUEK to facilitate credentialless value exchange. This flowchart describes a communication technique that overcomes various limitations of traditional registration systems by circumventing their reliance on user-provided tool references (e.g., card numbers, etc.). This communication technique can be implemented by one or more computing devices, entities, and/or systems (e.g., an exchange platform) described herein to establish a user tool record for registering users with the exchange platform.

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

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

In some embodiments, process 600 includes providing the UUEK to the partner platform at step/operation 624. For example, the exchange platform may use a partner interface to provide data indicating the UUEK to the partner platform. In some examples, the partner platform may provide the UUEK and/or its representation to the user (e.g., for storage in a virtual wallet, etc.). For example, the UUEK may be represented in one or more different forms, such as machine-readable optical images (e.g., barcodes, quick response codes, etc.), keywords, virtual widgets, etc.

Figures 7A-D provide message flow diagrams illustrating the steps/operations for establishing cross-entity relationships related to Figures 6A-C. It should be recognized that these steps/operations can be performed in accordance with the corresponding steps/operations in Figures 6A-C. Typically, as shown in Figures 7A-B, the steps/operations for establishing a secure communication session with a user through a partner application may be applicable to and/or related to the steps/operations in Figure 6A. For example, the steps/operations shown in Figures 7A-B may correspond to and/or be related to certain operations in the first phase of the registration process 600 for registering service provider tools with the partner platform without exposing persistent credentials associated with the user and/or the service provider tools.

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

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

In step/operation 712, connection service 408 stores a partner identifier corresponding to the partner platform 420. In step/operation 714, connection service 408 stores user data. In step/operation 716, connection service 408 generates a session identifier to identify the communication session between the partner and the exchange platform. In step/operation 718, connection service 408 provides the session identifier to partner service 410. In step/operation 720, partner service 410 returns the session identifier to partner platform 420. And in step/operation 722, partner platform 420 returns the session identifier to partner application 416. In various embodiments, the communication session may be initialized when performing step/operation 722.

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

Turning to Figure 7C, after establishing a secure communication session with the partner application, the registration process can continue to the second phase shown in the steps/operations of Figure 7C. Typically, the steps/operations shown in Figure 7C may be suitable for and/or related to the steps/operations of Figure 6B. For example, the steps/operations shown in Figure 7C may be equivalent to and/or related to certain operations in the second phase of registration process 600 for registering service provider tools with the partner platform without exposing persistent credentials associated with the user and/or the service provider tools.

In step/operation 744, the partner application 416 receives input from service providers indicating the list of service providers and sends a service provider identifier to widget 724. In step/operation 746, widget 724 uses a partner interface (e.g., widget registration tool initiation call, etc.) to send a request to connection service 408 to initiate registration of service provider tools on the service provider platform. This request may include a service provider identifier (e.g., service provider partition, etc.). In step/operation 748, connection service 408 uses a partner interface (e.g., widget registration tool initiation call, etc.) to request a list of tools corresponding to the user and service provider. In step/operation 750, service provider service 412 returns the tool list to connection service 408. In step/step 752, connection service 408 returns the tool list to widget 724, which may provide the user with a pre-registration screen indicating the tool list (e.g., one or more tool representations).

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

In step/operation 760, connection service 408 generates a matching code. In step/operation 762, connection service 408 uses a partner interface (e.g., a widget registration tool with account invocation, etc.) to provide a request to register the service provider tool with service provider service 412. This request may include a matching code and a session identifier. In step/operation 764, service provider service 412 uses a service provider interface (e.g., registering a user tool invocation, etc.) to provide a request to register the service provider tool with service provider platform 440. This request may include a tool reference, user reference, user key, tool key, and/or matching code. Service provider platform 440 can register the service provider tool, and in step/operation 766, provides a registration success response to service provider service 412 using the service provider interface. In step/operation 768, service provider service 412 provides data indicating a registration success response to connection service 408. In step/operation 770, connection service 408 provides data indicating a registration success response to widget 724.

Simultaneously, in step/operation 772, the service provider platform 440 provides a matching code to the user using one or more pre-existing communication channels. The user can access the matching code and, in step/operation 774, input the matching code into the verification interface presented by widget 724.

In step/operation 776, widget 724 provides a registration completion response to connection service 408 using the partner interface. In various embodiments, step/operation 776 is performed in response to confirmation of the matching code provided in step/operation 774.

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

Turning to Figure 7D, after authorizing the user based at least in part on confirmation of the matching code as described above, the registration process can continue to the third stage shown in the steps/operations of Figure 7D. Generally, the steps/operations shown in Figure 7D may be suitable for and/or related to the steps/operations of Figure 6C. For example, the steps/operations shown in Figure 7D may correspond to and/or be related to certain operations in the third stage of registration process 600 for registering service provider tools with the partner platform without exposing permanent credentials associated with the user and/or the service provider tools.

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.

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.

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.

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

The registration process may include steps such as selecting a service provider, and the user has tools to register with a partner platform for service providers. The user interface screen 812 of Figure 8C can facilitate service provider selection by providing a list 814 of service providers with selectable icons. In some examples, the service provider list 814 may be automatically matched to user attributes available to the user (e.g., provided via one or more previous user interface screens). For example, the service provider list 814 may be customized for the user, and in some examples, it may be actively limited to service providers associated with the user. As shown in user interface screen 812, service providers may include financial institutions (e.g., banks, etc.) based on financial value exchange. This is provided only as an example. As described herein, the techniques disclosed can be applied to any value exchange system.

After selecting a service provider, the user is directed to another user interface screen (not shown) for selecting the service provider's service provider tools. Once selected, the exchange platform can perform a registration process to register the service provider tools with the partner platform. During registration, the user can be redirected to user interface screen 816 of Figure 8D, which may include a verification prompt 818 for entering a matching code. As shown in user interface screen 820 of Figure 8E, the matching code can be automatically provided to the user via information 822 from the service provider platform. The user can answer the verification prompt 818 by entering the matching code and selecting the submit icon 824 to complete the registration process. The next screen, user interface screen 826 of Figure 8F, can display the UUEK representation 828 for the user. For example, the UUEK representation 828 may include a scannable representation of UUEK (e.g., barcode, QR code, non-fungible token, near-field communication sequence, etc.). The scannable representation can be saved to the partner account on the partner platform, enabling the user to perform value-based transactions using the service provider tools without referencing the service provider tools' permanent credentials.

Figure 9 illustrates a process flow for facilitating credentialless value exchange according to one or more embodiments of this disclosure. This process flow describes a communication and data encryption process 900 for securely authorizing exchanges in value-agnostic exchanges using UUEK. As described herein, process 900 can be used to overcome various limitations of conventional exchange systems that expose sensitive and permanent credentials to multiple third parties. Process 900 can be implemented by one or more computing devices, entities, and/or systems described herein. For example, through the various steps/operations of process 900, an exchange platform can leverage communication and data encryption techniques to overcome various limitations of conventional exchange mechanisms by eliminating reliance on static, sensitive credentials.

Figure 9 illustrates an example process 900 for illustrative purposes. While example process 900 depicts a specific sequence of steps/operations, this sequence can be changed without departing from the scope of this disclosure. For example, some of the described steps/operations may be performed in parallel or in a different order, but this will not materially affect the functionality of process 900. In other examples, different components of the example device or system implementing process 900 may perform their functions substantially simultaneously or in a specific order.

In some examples, process 900 begins after registration process 600 in Figures 6A-C, where the user and/or partner platform can receive a UUEK to facilitate credentialless value exchange. However, process 900 can also be performed before registration process 600. For example, the user can obtain the UUEK directly from the service provider platform without having to complete the partner platform's registration process. If registration process 600 is completed, the partner platform can use the partner interface and a partner platform-specific UUEK to facilitate value-based exchange; otherwise, the partner platform can use a service provider platform-specific UUEK provided by it to facilitate value-based exchange.

For example, when a user wishes to conduct a value-based exchange with a partner with whom the user has a registered partner account, the partner platform can locate the registered partner account and identify the user's issued UUEK from the partner account to authorize the value-based exchange. If the user wishes to conduct a value-based exchange with a partner who has not registered a partner account, the user can present a previously issued UUEK (e.g., issued to a service provider platform) to the partner platform (e.g., through a partner app), and the partner platform can use the UUEK to authorize the value-based exchange.

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

In some embodiments, process 900 includes receiving an exchange request with a UUEK in step/operation 902. For example, an exchange platform (e.g., its partner service, etc.) may use a partner interface to receive an exchange request for performing a value-based exchange. The exchange request may indicate a UUEK and/or one or more transaction attributes.

Transaction attributes can indicate one or more characteristics of the requested exchange. For example, one or more transaction attributes can include at least one transaction attribute indicating the transaction value (e.g., cart amount, etc.). For example, the transaction value can include the sum of one or more line entries in a financial transaction, including one or more modifications (e.g., taxes, discounts, etc.). Taking a financial-based value system as an example, in some examples, transaction attributes can include (i) an order number, (ii) one or more line entry attributes, including order, line entry group, product code, description, quantity, unit-entry, gram, kilogram, etc., unit amount, unit tax, line amount (e.g., the amount of the line entry), line tax, etc., and/or, (iii) one or more line entry adjustments, including order, adjustment type (e.g., manufacturer discount, store discount, return, cash payment, gift card payment, other payment, etc.), product code, description, quantity, unit-entry, gram, kilogram, etc., unit amount, unit tax, line amount (e.g., the amount of the line entry), line tax, etc.

Additionally or alternatively, transaction attributes may include request permission type (e.g., full or partial), partner transaction reference (e.g., partner platform transaction reference), channel (e.g., currency exchange type of the financial value system, such as push or pull value transfer, real-time payment, etc.), currency (e.g., used in the financial value system, etc.), organization key (e.g., platform identifier of the partner organization), organization category (e.g., airline, apparel, etc.), institution key (e.g., platform identifier of a retail location, etc.), employee identifier, and/or any other traceable information based on value exchange.

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

As described herein, a UUEK may correspond to a partner platform and/or a service provider platform. For example, when a UUEK is issued to a partner platform, it may include a partner partition identifying the partner platform. In this case, the UUEK includes an exchange identifier corresponding to the partner's exchanged data object. As another example, when a UUEK is issued to a service provider platform, it may include a service provider partition identifying the service provider platform. In this case, the UUEK includes an exchange identifier corresponding to the service provider's exchanged data object. In some examples, the exchange platform may process the UUEK based on entity partitions.

In some embodiments, an exchange platform (e.g., its partner services, etc.) receives a UUEK, which includes a partner partition identifying the partner platform. The exchange platform can use an exchange identifier to identify partner-specific exchange data objects. Partner-specific exchange data objects may include tool keys corresponding to service provider tools of member platforms. The exchange platform can identify system tool data objects based on the tool keys. For example, the exchange platform can identify member platforms based on the entity partition of the tool key and provide the tool key to the service corresponding to the member platform (e.g., service provider services, etc.). This service can identify system tool data objects based on the tool keys. The system tool data objects can then be used to identify one or more identifiers (e.g., user identifiers, tool identifiers, etc.) to process exchange requests.

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

In some examples, the exchange platform may perform one or more verification actions on the UUEK. For example, the exchange data object may include one or more exchange attributes indicating an expiration status. In some examples, the expiration status may indicate (i) whether the UUEK has previously been used to authorize a value-based exchange and/or (ii) a valid period of time for which the UUEK may be valid. Verification actions may include identifying the expiration status corresponding to the UUEK and verifying the UUEK at least in part based on the expiration status. For example, the exchange platform may verify the UUEK if the expiration status indicates that (i) the UUEK has not previously been used to authorize a value-based exchange and/or (ii) the UUEK has been presented within a valid period of time.

In some examples, the verification action may include verifying whether the sender of the UUEK is related to the original entity to which the UUEK was issued. In some examples, the UUEK may include an entity partition that indicates the original entity to which the UUEK was issued (e.g., a member platform, such as a partner or service provider platform). The exchange platform may use the entity partition of the UUEK to determine the entity corresponding to the UUEK (e.g., the original entity). In some examples, the verification action may include verifying whether 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 may verify the UUEK.

If UUEK is verified, process 900 can proceed to step/operation 906. Otherwise, process 900 can proceed to step/operation 914, where the exchange platform provides an error response to the partner platform using the partner interface.

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

An exchange platform (e.g., its service provider service) may use a service provider interface to provide an exchange authorization request to a member platform. The exchange authorization request may indicate at least one of one or more transaction attributes and/or tool identifiers of service provider tools. For example, the exchange platform may generate the exchange authorization request based on a system tool data object identified from one or more aspects of UUEK. The exchange authorization request may include a tool key and/or tool reference from the system tool data object.

In some examples, the exchange authorization request may indicate a user identifier associated with a service provider tool. For instance, the exchange platform may generate the exchange authorization request based on a system user data object identified from one or more aspects of UUEK. In some examples, the system user data object may be identified based on the user identifier of the exchange data object (e.g., a system user identifier). Additionally or alternatively, the system user data object may be identified based on the user identifier of a system tool data object (e.g., a system user identifier). In some examples, the exchange authorization request may include a user key and/or user reference from the system user data object.

Additionally or alternatively, the transaction authorization request may indicate an exchange identifier. For example, the exchange platform may generate a transaction identifier to represent a value-based exchange and provide that transaction identifier to member platforms.

In some embodiments, process 900 includes receiving an exchange authorization response at step/operation 908. For example, an exchange platform (e.g., its service provider service) may use a service provider interface to receive the exchange authorization response, which indicates at least one of transaction approval and/or transaction rejection. 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 tool. For example, in response to receiving an exchange authorization request, a member platform may be configured to compare the transaction value with the asset availability of the identified service provider tool. If the asset availability exceeds the transaction value, a value-based exchange may be authorized (e.g., transaction approval, etc.); otherwise, the exchange may be rejected (e.g., transaction rejection).

In some examples, the exchange authorization response may indicate one or more response attributes. Response attributes may include one or more error codes, etc., used to characterize the exchange authorization response.

An exchange platform may generate transaction records for value-based exchanges, at least in part, based on exchange authorization requests and/or exchange authorization responses. In some examples, the transaction record may indicate a transaction identifier, one or more transaction attributes, one or more response attributes, an exchange authorization response, one or more tool and/or user identifiers, and/or any other data related to the value-based exchange. In some examples, the exchange platform may store the transaction record in a platform database associated with one or more tool and/or user identifiers.

In some embodiments, process 900 includes optionally generating a replacement UUEK at step/operation 910. For example, the switching platform may automatically generate a replacement UUEK to replace the received UUEK.

In some examples, this may include (i) invalidating the received UUEK in future authorization requests and/or (ii) generating a replacement UUEK. For example, the exchange platform may modify the expiration status of the UUEK, rendering it invalid in subsequent value exchanges. Additionally or alternatively, the exchange platform may move, delete, and/or otherwise modify the exchange data object corresponding to the UUEK to invalidate it. A replacement UUEK may include a new unique exchange identifier (e.g., a different universally unique identifier) corresponding to the service provider's tool, replacing the invalid exchange identifier. In this way, the UUEK can be continuously modified and changed as users complete exchanges on different platforms, thereby limiting the exposure of users and platforms to malicious parties.

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

Figures 10 and 11 provide message flow diagrams illustrating steps/operations for facilitating credentialless value exchange in relation to Figure 9, according to one or more embodiments of this disclosure. It will be appreciated that these can be performed and implemented using the corresponding steps/operations of Figure 9. For example, Figure 10 illustrates a first message flow for facilitating credentialless exchange through a registered partner account, while Figure 11 illustrates a second message flow for facilitating credentialless exchange in the absence of a registered partner account.

In the first message flow, in step/operation 1004, the user initiates a transaction through a registered partner account. In step/operation 1006, the partner platform 420 retrieves the user's UUEK to execute the transaction on behalf of the user. In step/operation 1008, the partner platform 420 uses the partner interface to provide an exchange request to at least one of a plurality of partner services 410 corresponding to the exchange platform 420. The exchange request may indicate one or more transaction attributes of UUEK and/or value-based exchange.

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

In step/operation 1014, service provider service 412 verifies the UUEK (and/or its exchange identifier). In step/operation 1016, service provider service 412 provides an exchange authorization request to service provider platform 440 using the service provider interface. The exchange authorization request may 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.

In step/operation 1018, service provider platform 440 approves the transaction and provides an exchange authorization response to service provider service 412 using the service provider interface. In step/operation 1020, 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.). In step/operation 1022, service provider service 412 provides an exchange authorization response to partner service 410. In step/operation 1024, partner service 410 provides an exchange response to partner platform 420 using the partner interface.

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

In step/operation 1106, the partner service 410 searches for an exchange identifier (e.g., in a partner-specific data store, such as a portion of a platform database) to determine if an exchange data object exists. If no exchange data object exists, in step/operation 1108, the partner service 410 provides UUEK to the service provider service 412 of the exchange platform corresponding to the service provider platform identified from UUEK.

In step/operation 1110, service provider service 412 verifies the exchange identifier of UUEK. In step/operation 1112, service provider service 412 provides an exchange authorization request to service provider platform 440 using the service provider interface. The exchange authorization request may 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.

In step/operation 1114, service provider platform 440 grants the exchange and provides an exchange authorization response to service provider service 412 using the service provider interface. In step/operation 1116, 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.). In step/operation 1118, service provider service 412 provides an exchange authorization response indicative of the response to partner service 410. In step/operation 1120, partner service 410 provides an exchange response to partner platform 420 using the partner interface.

Having described above various operations, processes, methods, functions, etc., on behalf of the user in handling exchanges, 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.

Figures 12A-D provide example user interface flows configured for client device 104. The user interface can be configured to guide the user through a credentialless exchange process to facilitate value-based exchange between one or more member platforms without exposing the sensitive and persistent credentials of the service provider tools used to perform the value-based exchange. As shown in Figure 12A, the credentialless exchange process can begin when the user selects a payment method from the transaction processing screen 1202 of the partner application. After selecting a payment method provided by the exchange platform, the user can switch to a tool selection screen 1204 as shown in Figure 12B. The tool selection screen 1204 may include multiple selectable tool icons 1206, each of which may be associated with a UUEK issued by the exchange platform using the various technologies described herein. The user can perform the exchange by selecting one or more selectable tool icons 1206.

In some examples, in response to this selection, a scanning screen 1208 can be provided for in-store transactions. The scanning screen 1208 can display a scannable UUEK representation 1210 corresponding to the UUEK. The user can scan this scannable UUEK representation 1210 to complete a value-based exchange. Additionally or alternatively, in online settings, the user can be redirected to a user verification screen 1212 to provide a personal identification number (PIN) associated with a service provider tool. The user can enter the PIN to complete the transaction.

VI. Conclusion

Many modifications and other embodiments will arise in those skilled in the art upon which this disclosure pertains, taking advantage of the teachings presented in the foregoing description and the accompanying drawings. Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terminology is used herein, it is used in a general and descriptive sense only and not for limiting purposes.

Claims (20)

1. A computer-implemented method for certificateless value exchange, comprising: The presentation of a registration user interface is initiated by one or more processors using a partner interface via a user's client device, wherein the registration user interface includes a tool registration screen that instructs one or more service provider tools associated with the user; The one or more processors, using the partner interface, receive selection data instructing the selection of a service provider tool from the registration user interface; The one or more processors generate a matching code for authenticating the user; The one or more processors use a service provider interface to provide 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, the user's user identifier, and the tool identifier of the service provider tool; The one or more processors, using the partner interface, receive an authentication message including the matching code; and In response to user authentication based on the matching code, (i) The one or more processors generate a universally unique temporary key (UUEK) for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) The UUEK is provided to the partner platform by the one or more processors using the partner interface. 2. The computer-implemented method according to claim 1, wherein the user's user identifier includes a user reference of the service provider platform and a user key corresponding to the user reference. 3. The computer-implemented method according to claim 1, wherein the tool identifier of the service provider tool includes a tool reference of the service provider platform and a tool key corresponding to the tool reference. 4. The computer-implemented method of claim 3, wherein the selection data indication corresponds to the tool representation referenced by the tool. 5. The computer-implemented method according to claim 1, wherein initiating the presentation of the registration user interface includes: The presentation of a pre-registration screen is initiated using a partner interface and via a registration user interface, the pre-registration screen indicating one or more service providers associated with the exchange platform; The partner interface is used to receive pre-selected data, which indicates the selection of a specific service provider from the one or more service providers; The service provider-tool data is received at least in part based on the pre-selected data, wherein the service provider-tool data indicates one or more service provider tools for the user; and Using the partner interface and via the registration user interface, the presentation of the tool registration screen is initiated at least in part based on the service provider-tool data, wherein the tool registration screen indicates a corresponding tool representation for each of one or more service provider tools. 6. The computer-implemented method according to claim 5, wherein initiating the presentation of the pre-registration screen includes: The communication session request for the user is received through the partner interface, wherein the communication session request includes one or more user attributes; Generate a session identifier for the communication session between the partner platform and the exchange platform; The one or more service providers are determined at least in part based on the one or more user attributes; and The presentation of the pre-registration screen is initiated using the partner interface and via the registration user interface, at least in part, based on one or more service providers. 7. The computer-implemented method according to claim 1, wherein the matching code comprises a sequence of one or more different characters. 8. The computer-implemented method of claim 1, wherein the client device is configured to access a partner application hosted by the partner platform and to use the partner application to present the registration user interface to the user. 9. The computer-implemented method of claim 1, wherein the service provider platform is configured to provide the matching code to the user, and wherein receiving the authentication message includes: Using the partner interface and via the registration user interface, initiate the presentation of the authenticated user screen; and Using the partner interface, the authentication message is received at least in part based on user input on the screen of the authenticated user. 10. A computing system for credentialless value exchange, comprising a memory and one or more processors communicatively coupled to the memory, the one or more processors being configured to: Using a partner interface, the user initiates the presentation of a registration user interface via the user's client device, wherein the registration user interface includes a tool registration screen that indicates one or more service provider tools associated with the user; Using the partner interface, receive selection data indicating the selection tool for choosing a service provider from the registration user interface; Generate a matching code for authenticating users; Using the service provider interface, a registration request is provided to the service provider platform corresponding to the service provider tool, wherein the registration request includes service provider registration data indicating the matching code, the user's user identifier, and the tool identifier of the service provider tool; Using the partner interface, receive an authentication message including the matching code; and In response to user authentication based on the matching code, (i) Generate a universally unique temporary key (UUEK) for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) Using the partner interface, provide the UUEK to the partner platform. 11. The computing system of claim 10, wherein the user's user identifier includes a user reference of the service provider platform and a user key corresponding to the user reference. 12. The computing system of claim 10, wherein the tool identifier of the service provider tool includes a tool reference of the service provider platform and a tool key corresponding to the tool reference. 13. The computing system of claim 12, wherein the selection data indication corresponds to the tool representation referenced by the tool. 14. The computing system of claim 10, wherein initiating the presentation of the registration user interface includes: The presentation of a pre-registration screen is initiated using a partner interface and via a registration user interface, the pre-registration screen indicating one or more service providers associated with the exchange platform; The partner interface is used to receive pre-selected data, which indicates the selection of a specific service provider from the one or more service providers; The service provider-tool data is received at least in part based on the pre-selected data, wherein the service provider-tool data indicates one or more service provider tools for the user; and Using the partner interface and via the registration user interface, the presentation of the tool registration screen is initiated at least in part based on the service provider-tool data, wherein the tool registration screen indicates a corresponding tool representation for each of one or more service provider tools. 15. The computing system of claim 14, wherein initiating the presentation of the pre-registration screen comprises: The communication session request for the user is received through the partner interface, wherein the communication session request includes one or more user attributes; Generate a session identifier for the communication session between the partner platform and the exchange platform; The one or more service providers are determined at least in part based on the one or more user attributes; and The presentation of the pre-registration screen is initiated using the partner interface and via the registration user interface, at least in part, based on one or more service providers. 16. The computing system of claim 10, wherein the matching code comprises a sequence of one or more different characters. 17. The computing system of claim 10, wherein the client device is configured to access a partner application hosted by the partner platform and to use the partner application to present the registration user interface to the user. 18. One or more non-transitory computer-readable storage media for certificateless value exchange, comprising instructions that, when executed by one or more processors, cause the one or more processors to: Using a partner interface, the user initiates the presentation of a registration user interface via the user's client device, wherein the registration user interface includes a tool registration screen that indicates one or more service provider tools associated with the user; Using the partner interface, receive selection data indicating the selection tool for choosing a service provider from the registration user interface; Generate a matching code for authenticating users; Using the service provider interface, a registration request is provided to the service provider platform corresponding to the service provider tool, wherein the registration request includes service provider registration data indicating the matching code, the user's user identifier, and the tool identifier of the service provider tool; Using the partner interface, receive an authentication message including the matching code; and In response to user authentication based on the matching code, (i) Generate a universally unique temporary key (UUEK) for the user, wherein the UUEK corresponds to the user, the service provider tool, and the partner platform; and (ii) Using the partner interface, provide the UUEK to the partner platform. 19. One or more non-transitory computer-readable storage media according to claim 18, wherein the client device is configured to access a partner application hosted by the partner platform and to use the partner application to present the registration user interface to the user. 20. The one or more non-transitory computer-readable storage media of claim 18, wherein the service provider platform is configured to provide the matching code to the user, and wherein receiving the authentication message includes: Using the partner interface and via the registration user interface, initiate the presentation of the authenticated user screen; and Using the partner interface, the authentication message is received at least in part based on user input on the screen of the authenticated user.