System, method, and computing platform for managing network-enabled security codes

Abstract

Various embodiments of the present disclosure provide techniques for facilitating credential-less exchange over a network using multiple identifier mappings, member interfaces, and security code tuples aligned with ephemeral keys. The techniques may include receiving a secure information transfer request and issuing or activating a pre-issued universally unique ephemeral key (UUEK) in response to the secure information transfer request. The techniques may include activating a user, instrument, or UUEK and, in response, storing a secure event for the user, instrument, or UUEK, and providing a secure information transfer response indicating the secure event. The techniques may include subsequently receiving an exchange request to perform a value-based exchange using the UUEK and facilitating the exchange request based at least in part on the secure event.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 370,278, filed August 3, 2022, and U.S. Patent Application No. 18 / 363,796, filed August 2, 2023, both of which are incorporated by reference herein in their entirety, including any figures, tables, drawings, and addenda.

[0002] TECHNICAL FIELD Embodiments of the present disclosure generally relate to network-enabled security codes. [Background technology]

[0003] Various embodiments of the present disclosure address technical challenges related to network-based exchanges, taking into account the limitations of existing exchange processing technologies and architectures. Existing processes for conducting exchanges over computing networks rely on the use of persistent credentials, such as payment credentials (e.g., card numbers, usernames, passwords, bank routing numbers, account numbers, etc.), and their powers of attorney, which expose the recipient of the credentials to fraud, regulatory and compliance costs, and reputational risk. Moreover, the static nature of traditional credentials requires users to accept the risk of financial loss, damaged credit scores, identity theft, and other consequences each time they provide their credentials to enable an exchange. The inherent lack of security of persistent credentials is traditionally addressed using rigid communication protocols, data governance procedures, and authentication schemes, each of which introduces additional technical challenges by adding overhead and complicating network-based transactions without solving the underlying technical problem of data security.

[0004] One technique involves the use of provider-controlled personal identification numbers (PINs) and / or other security codes, for example, that can be set by a user or provider and then subsequently used to verify exchanges using a particular account. These codes can be encoded within physical media and automatically authenticated each time the physical media is used to authorize an exchange. Alternatively, a code can be provided with each individual exchange request to the provider to authorize the exchange.

[0005] Traditional codes lack flexibility and are insecure in several different ways. First, traditional codes are deployed as four-digit numbers and can be brute-forced given a limited number of possible combinations, presenting an attack vector for malicious parties. Furthermore, to function effectively, traditional codes must be provided at the same time an exchange is requested. This leads to increased network traffic and increases exchange costs, even when the exchange is declined. Additionally, such codes traditionally apply to all exchanges, are not configurable for specific characteristics of the request (e.g., exchange value, time, etc.), are cumbersome to change, and increase liability for users (e.g., when the code is encoded on a physical medium) or providers. These and other technical challenges limit the effectiveness of traditional security codes and further present security challenges for implementing network-based exchanges.

[0006] Various embodiments of the present disclosure make important contributions to various existing network-based value exchange processing technologies by addressing each of these technical challenges. Summary of the Invention [Means for solving the problem]

[0007] Various embodiments of the present disclosure disclose a secure intermediary computing platform and computing services that facilitate credential-free execution of value-based exchanges that leverage Universally Unique Ephemeral Keys (UUEKs) to eliminate the use of persistent credentials. To do so, the intermediary computing platform can facilitate interactions between one or more member platforms to register users and / or user instruments in a value exchange system powered by a novel ephemeral data structure, referred to herein as a UUEK. Unlike traditional exchange systems, the intermediary computing platform does not receive or rely on persistent user or instrument credentials to register users and / or user instruments. This elimination of credentials enables the use of new, more flexible interfaces, such as the application programming interfaces (APIs) described herein, that are utilized by the intermediary computing platform to communicate with different network members to register users, user instruments, instrument policies, and different security codes without disclosing user credentials at any step in the process. Once registered, the intermediary computing platform can issue a UUEK to the member platform that can replace a traditional persistent credential. The issued UUEK does not reflect the persistent credential or any other confidential user or instrument information.The interface between the member platform and the intermediary platform can enable (i) a user to present an issued UUEK from the member platform to the intermediary platform (without explicit reference to a persistent credential), and (ii) the intermediary platform to map the issued UUEK to an instrument key for the same or another member platform and provide the instrument key to the member platform for authorization of value-based exchanges. In this way, network-based transactions can be authorized in a seamless process without exposing sensitive user or instrument information that could be susceptible to network attacks.

[0008] Some of the techniques disclosed herein further enhance the security of network-based exchanges by leveraging flexible interfaces, such as APIs, between entities of a value-based exchange to establish a UUEK security code. The security code can be used to enable and disable the use of the UUEK to authorize the exchange. In this manner, execution of a value-based exchange can be predicated, at least in part, based on the determination of the UUEK security code. Importantly, the security code is network-operated, allowing for n-character codes of variable complexity. As described herein, this allows for the enforcement of instrument-specific security measures by the intermediary platform without the risk of exposing sensitive user or financial information before exchange authorization is always provided to a service provider, such as a financial institution. Finally, the techniques disclosed herein enable additional flexibility (e.g., through the use of new interfaces) and security (e.g., through the elimination of persistent credentials, the introduction of new security codes, etc.) while reducing computing power requirements and enabling significantly greater network throughput for exchange processing compared to prior art.

[0009] In some embodiments, a computer-implemented method includes receiving, by one or more processors, a secure signaling request indicating a security code input and a user identifier; identifying, by the one or more processors, a security code tuple for the security code input based on the user identifier; validating, by the one or more processors, the security code input based at least in part on a comparison between the security code input and a security code reference of the security code tuple; and in response to validating the security code input, (i) storing, by the one or more processors, a secure event for the user; and (ii) providing, by the one or more processors, a secure signaling response indicative of the secure event, wherein the secure signaling response includes: (a) a universally unique ephemeral key; receiving, by one or more processors, an exchange request to perform a value-based exchange using the UUEK; providing, by the one or more processors, an exchange authorization request to the member platform, the exchange authorization request indicating the instrument identifier and the secure event; and receiving, by the one or more processors, an exchange authorization response indicating at least one of an exchange approval or an exchange denial, the exchange authorization response based at least in part on the secure event.

[0010] In some embodiments, a computing system comprises a memory and one or more processors communicatively coupled to the memory, the one or more processors receiving a secure signaling request indicative of a security code entry and a user identifier; identifying a security code tuple for the security code entry based on the user identifier; validating the security code entry based at least in part on a comparison between the security code entry and a security code reference of the security code tuple; and in response to validating the security code entry, (i) storing a secure event for the user; and (ii) providing a secure signaling response indicative of the secure event, the secure signaling response including: (a) a universally unique ephemeral key; and (b) providing an exchange authorization request to the member platform, the exchange authorization request indicating the instrument identifier and the secure event; and receiving an exchange authorization response indicating at least one of an exchange approval or an exchange denial, the exchange authorization response based at least in part on the secure event.

[0011] In some embodiments, the one or more non-transitory computer-readable storage media, when executed by the one or more processors, receive a secure signaling request indicative of a security code entry and a user identifier; identify a security code tuple for the security code entry based on the user identifier; validate the security code entry based at least in part on a comparison between the security code entry and a security code reference in the security code tuple; and in response to validating the security code entry, (i) store a secure event for the user, and (ii) provide a secure signaling response indicative of the secure event, the secure signaling response including: (a) a universally unique ephemeral key; and receiving an exchange authorization response indicating at least one of an exchange approval or an exchange denial, wherein the exchange authorization response is based at least in part on the secure event.

[0012] Having thus generally described the present disclosure, reference is now made to the accompanying drawings, which are not necessarily drawn to scale. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is an exemplary diagram of a computing ecosystem in accordance with one or more embodiments of the present disclosure. [Figure 2] FIG. 1 is an exemplary schematic diagram of a computing platform in accordance with one or more embodiments of the present disclosure. [Figure 3] FIG. 1 is an illustrative schematic diagram of a client device in accordance with one or more embodiments of the present disclosure. [Figure 4] FIG. 1 is an example block diagram of an example credential-free exchange system for value, according to one or more embodiments of the present disclosure. [Figure 5] FIG. 1 is an exemplary data diagram for facilitating credential-less exchange of value, in accordance with one or more embodiments of the present disclosure. [Figure 6] 1 is a process flow for facilitating a network-operated security code for a user, according to one or more embodiments of the present disclosure. [Figure 7A] 1 is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 7B] 1 is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 7C] 1 is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 8A] 1 is a process flow for facilitating secure credential-less information transfer in accordance with one or more embodiments of the present disclosure. [Figure 8B] 1 is a process flow for facilitating secure credential-less information transfer in accordance with one or more embodiments of the present disclosure. [Figure 9A] FIG. 10 is a diagram of an example interface for facilitating credential-less exchange of value in accordance with one or more embodiments of the present disclosure. [Figure 9B] FIG. 10 is a diagram of an example interface for facilitating credential-less exchange of value in accordance with one or more embodiments of the present disclosure. [Figure 9C]FIG. 10 is a diagram of an example interface for facilitating credential-less exchange of value in accordance with one or more embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0014] Various embodiments of the present disclosure are described in more detail below with reference to the accompanying drawings, in which some, but not all, embodiments of the present disclosure are illustrated. Indeed, the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that the present disclosure will satisfy applicable legal requirements. The term "or" is used herein in both its alternative and conjunctive sense, unless otherwise indicated. The terms "exemplary" and "example" are used as examples without an indication of level of quality. Terms such as "computing," "determining," "generating," and / or similar words are used interchangeably herein to refer to the creation, modification, or identification of data. Furthermore, terms such as "based at least in part on," "based at least on," "based on," and / or similar words are used interchangeably herein in a broad manner, unless so indicated, so as not to necessarily indicate based at least in part on or solely on the referenced element or elements. Like numbers refer to like elements throughout.

[0015] I. Summary and Technical Advantages Various embodiments of the present disclosure provide technical solutions for managing network-based exchanges. In various embodiments, an exchange platform may be configured to facilitate credential-less exchanges of value between one or more member platforms. These exchanges may be facilitated in real time without persistent credentials that may expose members to financial, legal, reputational, or other risks. Thus, in various embodiments, client devices may buy, sell, and / or conduct value-based exchanges in real time over any network without exposing sensitive information that is susceptible to network-based attacks.

[0016] Embodiments of the present disclosure provide improved instrument-level enablement and enablement techniques that utilize new interfaces, security code operations, and policy matching techniques to improve data security and communication flexibility while reducing computing resource expenditure requirements for protecting sensitive data over network communications.

[0017] Some techniques disclosed herein, for example, take a data object and convert it into a unique data key recognizable only to authorized entities. The data key may be provided and / or established by leveraging an exchange interface between the exchange platform and other member platforms in the exchange network. Once established, the data key may be mapped to a confidential credential stored within the source platform (e.g., a service provider platform) without requiring network transmission of the confidential credential. Future communications to facilitate value-based exchanges may replace traditional persistent credentials with a data key to enable the source platform to identify the persistent credential and / or perform one or more actions for a specific instrument associated with the persistent credential. In this manner, the exchange platform may facilitate exchanges using keys (and / or other identifiers) that cannot be traced back to the underlying confidential information. This further enables the exchange platform to track, facilitate, and distribute network-based communications holistically without exposing members to network attacks.

[0018] Some embodiments of the present disclosure present network-based exchange processing techniques for facilitating credential-free exchanges. To do so, some of the disclosed techniques utilize a new data structure, the UUEK, which can replace persistent credentials traditionally used to authorize value-based exchanges. Using the disclosed techniques, UUEKs can be securely issued across member platforms to allow users to conduct value-based exchanges using identifiers recognizable by a single party, the exchange platform. The UUEK can be mapped to a unique identifier that can reference sensitive information without directly identifying (and thereby disclosing) the sensitive information. The unique identifier can, for example, reference a mapping that can only be interpreted by the source platform, and thus the identifier is unusable to malicious parties not affiliated with the exchange platform. In this way, the exchange platform can distribute, track, and facilitate exchanges without exposing the member platform to data security risks. Moreover, the exchange platform can continuously update, modify, and / or redistribute the UUEK to member platforms to continuously adapt the UUEK in real time. In this way, exchange platforms can offer technological improvements to data and network security while reducing computing resource requirements (e.g., to securely encrypt persistent credentials) to facilitate value-based exchange.

[0019] Some technologies of the present disclosure can leverage the disclosed credentialless exchange to enable the use of flexible exchange interfaces between members of an exchange network. Unlike traditional exchange interfaces, the credentialless exchange enables the use of an interface capable of facilitating complex network-operated n-character security codes aligned with the UUEK. By doing so, the intermediary computing platform can receive the information necessary to establish the security code aligned with the UUEK. The security code can be utilized to validate the UUEK before the exchange is initiated. In this way, exchanges are proactively filtered based at least in part on the authenticity of the temporary data structure. This further limits network traffic to those exchanges most likely to be authorized, improving network performance in a robust network-based exchange ecosystem. Furthermore, network operation of the security code can increase the feasible complexity of the actual code, for example, by allowing n-character codes of varying complexity. Even a simple n-character code can have over 14,776,336 possible combinations, which is dramatically more secure than a traditional four-character alphanumeric code, which has 1,679,616 combinations.

[0020] Exemplary inventive and technically advantageous embodiments of the present disclosure include (i) data conversion, mapping, and processing schemes for facilitating network-based credential-less exchanges; (ii) exchange interfaces and network-based communication schemes for improving network security for cross-platform communications; (iii) ephemeral data structures and data management techniques for distributing ephemeral data structures for facilitating real-time, secure, and dynamic value-based exchanges; and (iv) UUEK activation techniques for validating and / or invalidating UUEKs for exchanges.

[0021] II. Illustrative Definitions In some embodiments, the term "exchange platform" refers to a computing entity configured to facilitate the credential-less exchange of value for one or more members in an exchange network. The exchange platform may include one or more processing devices, memory devices, and / or the like, physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks to facilitate a value system-agnostic exchange. In some examples, the exchange platform may include, define, and / or otherwise utilize one or more APIs for facilitating communication (e.g., requests and responses) between multiple members. As described herein, APIs may be utilized to facilitate secure exchange between one or more members in any value system.

[0022] In some embodiments, the term “member” refers to an entity that collaborates with the exchange platform to participate in a value exchange. By way of example, a member may include (i) a partner that utilizes the exchange platform to receive value, (ii) a service provider that utilizes the exchange platform to provide value, and / or (iii) both a partner and a service provider. As used herein, a member may be referred to as a partner when receiving value through a value exchange and / or 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 both a partner and a service provider. For example, a member may be a partner that receives value for 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 partner and a service provider in the same value exchange, thus utilizing the exchange platform to provide value and then receive value in only one member's value exchange.

[0023] In some embodiments, a member is a partner when it utilizes a service provided by a service provider. A partner may include any value-seeking entity in any value system. By way of example, in a financial value system, a partner may include a merchant (e.g., a retailer, a brick-and-mortar establishment, etc.) that may utilize a service provider, such as a financial institution, to access funds for financial transactions. Additionally or alternatively, in an information value system, a partner may include a news publisher (e.g., a newspaper, a news organization, etc.) that may utilize a service provider, such as a news agency (e.g., a wire service, a news service, etc.), to access information for information transactions. Of course, the techniques of this disclosure may be applied to any value system, and a partner may include any value seeker for any respective value system.

[0024] In some embodiments, a member is a service provider when it provides a service to a partner. A service provider may include a source of value in any value system. By way of example, in a financial value system, a service provider may include a financial institution (e.g., a bank, an exchange platform, a credit union, etc.) that may 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 a news agency (e.g., a wire service, a news service, etc.) that may source information for publication by a news publisher. Of course, the techniques of this disclosure may be applied to any value system, and a service provider may include any source of value for any respective value system.

[0025] In some embodiments, the term "service provider instrument" refers to a mechanism utilized by a service provider to provide value on behalf of a particular user. A service provider instrument may depend on the value system and / or the service provider. In some examples, a service provider instrument may include an account at the service provider. For example, in a financial value system, a service provider instrument may include a bank account (e.g., checking, savings, etc.), a brokerage account, a line of credit, and / or the like. In an information value system, a service provider instrument may include a subscriber account and / or the like. In some examples, a service provider instrument may include a virtual instrument hosted by a service provider platform.

[0026] In some embodiments, services provided by a service provider are subject to one or more policies and / or security codes. For example, a service provider and / or service provider instrument may be associated with a security code for validating use of the service provider instrument. Additionally or alternatively, a service provider may be associated with one or more member policies for authenticating the security code.

[0027] In some embodiments, the term "security code" refers to a data entity that defines a sequence of characters for verifying a user during communication, such as a physical exchange, a virtual exchange, an enrollment, and / or the like. The security code may include one or more different character sequences of dynamic length (e.g., six characters, eight characters, etc.) that may be preset by a user and / or provided to a user. The security code may be later provided by a user to validate the user's presence for communication (e.g., by comparing a security code input to a security code reference, as described herein). The one or more different characters may include any number of alphanumeric characters, emojis, Kanji characters, Wingdings, and / or the like.

[0028] In some embodiments, the security code is a network-operated n-character PIN. As described herein, the security code may be administered as a service through a client device to (i) securely retrieve the UUEK, (ii) register the instrument with the member platform, and / or (iii) enable or disable the use of the UUEK (and / or any other exchange credentials) prior to an exchange request. In this manner, a security code may be deployed to any type of service provider instrument through the lookup, registration, and / or activation or deactivation of the corresponding UUEK. By managing security codes at the network level, members may benefit from faster exchanges because the likelihood of authorization declines due to invalid PINs is eliminated. For example, the UUEK may be disabled until a security code is received to activate the UUEK. The exchange platform may prevent a user from initiating an exchange until the UUEK is activated, thereby ensuring that all exchange authorization requests submitted to the service provider are pre-activated with the security code in mind. This effectively reduces network traffic between members in the switching network, thereby reducing network congestion in traditional high-traffic communication systems.

[0029] In some embodiments, the security code corresponds to a user. For example, the security code may be preset by and / or provided to the user through communication with the exchange platform. By way of example, the security code may be set by the user through communication with an exchange network widget embedded within a member software application. This allows the security code to be set without directly communicating with or sharing the security code with each member platform. In some examples, the security code may be instrument or member specific. For example, each security code may be configured to retrieve and / or enable a particular member platform's UUEK and / or a particular member platform's service provider instrument. Additionally or alternatively, each security code may be configured to register a member platform account with the exchange network. By way of example, an exchange platform may govern the use of security codes to perform one or more secure actions using multiple security code tuples, each correlating a security code to a respective user, member platform, and / or service provider instrument.

[0030] In some embodiments, the term "security code tuple" refers to a data entity that defines a correlation between a security code, a user, and one or more of a member platform and / or a service provider instrument. A security code tuple may include data objects, records, and / or any other data structure (e.g., linked nodes, etc.) configured to represent an association between a security code and a user, and, in some embodiments, a member platform, a service provider instrument, or both. A security code tuple may include, for example, a security code reference, a user identifier, one or more member identifiers, one or more instrument identifiers, and / or contextual pairing data. The contextual pairing data may include one or more pairing attributes, such as one or more timing attributes. The timing attributes may indicate, for example, a configuration time (e.g., indicating the time the security code tuple was set), an expiration time (e.g., the time the security code must be reset), and / or the like. As described herein, the security code tuple may be utilized by the exchange platform to identify a user's security code reference and perform secure actions on behalf of the user (e.g., enabling use of the UUEK for exchange) based at least in part on a comparison between the security code reference and a security code input provided by the user.

[0031] In some embodiments, the term "security code reference" refers to a data entity that defines a recorded security code. The security code reference may include an internal representation (e.g., for an exchange platform, etc.) of a user's security code.

[0032] In some embodiments, the term "security code input" refers to a data entity that defines a sequence of characters provided to perform a secured action. The security code input may include user input provided by a user, as described herein. In some examples, a secured action may be performed for a user when the security code input matches a security code reference. As one example, when the security code input matches the user's security code reference (e.g., as defined by a security code tuple), the respective UUEK assigned to the user may be validated.

[0033] In some embodiments, the term "security code request" refers to a data entity that defines a request to set, reset, and / or remove a user's security code. A security code request may be provided to an exchange platform by a member of an exchange network. The security code request may indicate the user's member-user reference and, in some instances, the user's member-instrument reference. By way of example, a security code request that includes only a member-user reference may default to all service provider instruments associated with the user and, for example, may initiate set, reset, and / or remove operations on security codes that apply to all service provider instruments maintained by the respective member platforms for the user. Additionally or alternatively, a security code request that includes a member-user reference and a member-instrument reference may initiate set, reset, and / or remove operations on security codes that apply to specific service provider instruments maintained by the respective member platforms for the user. In addition to the reference, the security code request may include a code action attribute indicating the desired set, reset, and / or remove action, as well as a security code input indicating a new, modified, or existing n-character PIN.

[0034] In some embodiments, the term "secure information transfer request" refers to a data entity that defines a request to perform a secure information transfer using a security code entry. The secure information transfer request may be provided to the exchange platform by a member of the exchange network. The secure information transfer request may indicate (i) a user, a member platform, and / or a service provider instrument, and (ii) a user security code entry. Additionally or alternatively, the secure information transfer request may indicate one or more context security attributes. The one or more context security attributes may include one or more timing attributes. The one or more timing attributes may indicate, for example, a delivery time (e.g., indicating the time the secure information transfer request is sent), a request time (e.g., the time requested to perform the secure information transfer), and / or the like.

[0035] The secure information transfer request may be received from a member platform. For example, a user may initiate the secure information transfer request through a member application hosted by the member platform on behalf of a member of the exchange network. In some examples, the secure information transfer request may be generated and / or provided in response to a selection input indicating a service provider instrument, a UUEK for the service provider instrument, and / or the like. As one example, a user may select an instrument representation, a UUEK representation, and / or the like to authorize a value-based exchange (e.g., through a partner application associated with a partner platform, a service provider application associated with a service provider platform, etc.). In some examples, the secure information transfer request may be automatically initiated if the user and / or the selected instrument, UUEK, and / or the like are associated with a security code. For example, in response to a selection, the member platform (e.g., through the respective member application) may prompt the user to enter a security code. The user may enter the security code input to provide the secure information transfer request.

[0036] In some embodiments, the term "activation event" refers to a data entity that defines the activation of a user's security code input. The activation event may include a secure event, which may indicate activation between the security code input and the security code reference. Additionally or alternatively, the activation event may include a non-secure event, which may indicate a failed activation between the security code input and the security code reference. For example, a secure event may indicate a determination that the security code input matches the corresponding security code reference. In some examples, a non-secure event may indicate a determination that the security code input does not match the corresponding security code reference. In some examples, the exchange platform may generate a secure event in response to a determination that the security code input matches the corresponding security code reference. Additionally or alternatively, the exchange platform may generate a non-secure event in response to a determination that the security code input does not match the corresponding security code reference. In some examples, the secure event may be associated with a secure period, and the exchange platform may generate a non-secure event in response to a determination that the secure period has expired.

[0037] In some embodiments, the activation event is stored in association with a secure data entity, such as a UUEK, a service provider instrument, and / or a user. For example, the activation event may be stored in an exchange data object corresponding to the UUEK, a system instrument data object corresponding to the service provider instrument, a system user data object corresponding to the user, and / or the like. Additionally or alternatively, the activation event may be stored in association with a security code tuple. For example, a secure event may be stored in response to activating a user, while a non-secure event may be stored in response to disabling a user.

[0038] In some embodiments, the activation event includes context activation data. The context activation data may indicate, for example, the timing of the activation. The timing of the activation may include a timestamp corresponding to the transmission, receipt, creation, and / or adjudication of the activation request. For example, the context activation data may include an activation timestamp indicating the time at which the exchange platform determined that the security code input and security code reference match or do not match. In some examples, the context activation data may indicate a secure period. The secure period may indicate a timestamp, a time duration, and / or the like after which the UUEK, service provider instrument, and / or the like may be secured in response to the secure event.

[0039] In some embodiments, the term "secure signaling response" refers to a data entity that defines a response to a secure signaling request. In some embodiments, the secure signaling response is provided by the exchange platform to the member that submitted the secure signaling request. The secure signaling response may indicate a validation event.

[0040] In some embodiments, the term "member policy" refers to a data entity that defines one or more enablement requirements for a service provider instrument. A member policy may correspond to a member and / or the member's service provider instrument. For example, a member policy may define one or more enablement requirements for using a service provider instrument based at least in part on one or more member-specific standards. Additionally or alternatively, a member policy may define one or more enablement requirements for using a service provider instrument based at least in part on one or more instrument-specific standards. A member-specific standard may apply to multiple service provider instruments associated with a member, while an instrument-specific standard may apply to at least one of multiple service provider instruments associated with a member.

[0041] The validation requirement may indicate one or more attributes of a value-based exchange that require secure communication. For example, a previously issued UUEK may be used without a security code to authorize a value-based exchange that does not include one or more attributes that require secure communication. If the value-based exchange includes at least one attribute that requires secure communication, the UUEK may be prevented from authorizing the value-based exchange unless a verified security code is provided.

[0042] In some examples, a policy attribute may include an object identifier, one or more object attributes, and / or one or more value exchange attributes that identify an object and / or one or more authorized / unauthorized quantities of the object. For example, a member policy may include multiple object identifiers that may indicate multiple objects that are authorized / unauthorized to be acquired (e.g., purchased) without a security code.

[0043] In some examples, the object identifier may be a global object identifier. For example, the global object identifier may be a stock keeping unit (SKU) code. Additionally or alternatively, the global object identifier may be a manufacturer part number (MPN), a global trade item number (GTIN), a product or service name, an International Standard Book Number (ISBN), a Universal Product Code (UPC), an International Item Number (EIN), and / or the like. In some examples, the object identifier may include a system object identifier. The system object identifier may include, for example, an identifier (e.g., a table identifier) corresponding to a recorded data object representing an object within an exchange platform. In some embodiments, the system object identifier and the global object identifier are the same.

[0044] In some embodiments, the policy attributes include value exchange attributes corresponding to particular value-based exchanges and / or objects included in the value-based exchange. The value exchange attributes may include, for example, a threshold exchange value without a security code. For example, one or more exchange attributes may indicate an exchange value, and one or more enablement requirements may define an exchange value threshold at which a respective secure event is required for the service provider instrument.

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

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

[0047] In some examples, the exchange platform may maintain and / or access an object data store that includes a plurality of recorded data objects. As described herein, the object data store may include a plurality of recorded data objects that are obtained at least in part from one or more members of the exchange network.

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

[0049] For example, object-based attributes may include spatial attributes, count attributes, value attributes, source attributes, composition attributes, category attributes, and / or any other attributes that describe object characteristics. Spatial attributes may indicate, for example, one or more dimensions of an object (e.g., height, width, weight, etc.), value attributes may indicate the value of an object (e.g., price, etc.), composition attributes may indicate one or more ingredients, components, etc. of an object, category attributes may indicate one or more categories of an object (e.g., restricted substances, etc.), and / or the like. By way of example, one or more category attributes may indicate whether an object is associated with (i) one or more general store categories, such as vegetables, fruits, dairy, meat, grains, seeds, alcohol, tobacco, in-store consumables, hot food, pharmacy, pet food, and non-food items; (ii) one or more medical categories, such as dental, ophthalmology, and general health; (iii) one or more information categories, such as international sources, domestic sources, and / or the like. In some examples, the composition attribute may indicate one or more components of an object, such as the percentage by volume of alcohol in the object, one or more ingredients such as meat, dairy-derived, peanut-derived, tree nut-derived, soy-derived, and / or the like.

[0050] In some examples, the object-based attributes can be based at least in part on a value system. For example, in at least one financial-based value system, the object-based attributes can include one or more line item attributes, one or more line item adjustments, and / or the like. Line item attributes can include a sequence, a line item group, a product code, an item name, an item source (e.g., provider, manufacturer, etc.), a description, a quantity, a mass (e.g., grams, kilograms, etc.), one or more spatial dimensions (e.g., length, width, height, volume, etc.), a unit amount, a unit tax amount, a line amount (e.g., a line item amount), a line tax amount, and / or the like. A line item adjustment may include an adjustment type (e.g., manufacturing discount, store discount, margin, cash payment, gift card payment, other payment, and / or the like), an item, product, or service code, an item description, an item quantity, a unit item, an item mass (e.g., grams, kilograms, etc.), a unit amount, a unit tax amount, a line amount (e.g., the amount of the line item), a line tax amount, and / or the like.

[0051] In some embodiments, the term "exchange request" refers to a data entity that defines a request to effect an exchange of value. An exchange request may be provided to an exchange platform by a member of an exchange network. An exchange request may include one or more request attributes. The one or more request attributes may include one or more object identifiers, object attributes, and / or the like.

[0052] For example, the one or more request attributes may include multiple object identifiers corresponding to multiple objects associated with the value-based exchange. Additionally or alternatively, the one or more request attributes may include one or more object attributes of the multiple objects. For example, the one or more object attributes may include one or more object-based attributes, such as one or more line-item attributes, one or more exchange-based attributes, such as an object quantity, an object location, and / or the like. For example, the exchange request may indicate an exchange location where the object is being obtained.

[0053] In some embodiments, the term "exchange authority request" refers to a data entity that defines a request to a member to conduct a value-based exchange. In some embodiments, the exchange authority request is provided from an exchange platform to a member of the exchange network. The exchange authority request may be provided to a service provider of the exchange network in response to an exchange request from a partner of the exchange network, for example. In some examples, the exchange authority request may indicate an activation event associated with a UUEK. For example, the exchange authority request may indicate the revoked and / or activated status of a UUEK used to initiate an exchange of value.

[0054] In some embodiments, the term "exchange authority response" refers to a data entity that defines a response to an exchange authority request. In some embodiments, the exchange authority response is provided to the exchange platform by a member of the exchange network. The exchange authority response may be provided, for example, by a service provider of the exchange network in response to the exchange authority request.

[0055] In some embodiments, the exchange authorization response indicates at least one of exchange approval or exchange denial. The exchange authorization response can be based at least in part on a comparison between the exchange value, asset availability of the service provider instrument, and / or an activation event. For example, in response to receiving an exchange authorization request, the member can be configured to compare the exchange value with asset availability of the identified service provider instrument. A value-based exchange may be authorized (e.g., resulting in exchange approval) if asset availability exceeds the exchange value; otherwise, the value-based exchange may be denied (e.g., resulting in exchange denial). In some examples, a value-based exchange may be authorized (e.g., resulting in exchange approval) if the exchange value is within an exchange value threshold; otherwise, the value-based exchange may be denied unless the exchange authorization response indicates that a valid UUEK was used to initiate the exchange of value.

[0056] In some embodiments, the exchange authorization response indicates one or more context response attributes. The one or more context response attributes may, for example, indicate one or more contributing factors to the exchange authorization response. The contributing factors may include, for example, bad actor risk and / or fraud check, error, full authorization, undisclosed instrument, instrument-based risk and / or fraud check, insufficient value, invalid UUEK, limit exceedance (e.g., UUEK or instrument usage limit exceeded), missing line item (e.g., in the case of an exchange of value that does not include a valid object), missing instrument, missing account, required PIN, partial authorization, unavailable member, transaction risk and / or fraud check, unsupported operation, user contact member (e.g., the user may need to contact a member, such as a service provider, to resolve the issue), user risk and / or fraud check, and combinations thereof.

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

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

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

[0060] In some embodiments, a partner platform is a computing entity configured to perform one or more operations on behalf of a partner. A partner platform may include one or more processing devices, memory devices, and / or the like, physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks, for example, to request value in a value-system-agnostic exchange. In some examples, a partner platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses) with the exchange platform. In some examples, a partner platform may be configured to host one or more user-facing applications (e.g., partner applications) for communicating with one or more users.

[0061] In some embodiments, a service provider platform is a computing entity configured to perform one or more operations on behalf of a service provider. A service provider platform may include one or more processing devices, memory devices, and / or the like, physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks to provide value in a value-system-agnostic exchange, for example. In some examples, a service provider platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses) with an exchange platform. In some examples, a service provider platform may be configured to facilitate one or more service provider instruments. 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 instruments.

[0062] In some embodiments, the term "exchange interface" refers to a set of instructions for facilitating communication between the exchange platform and one or more member platforms and / or internal services. The exchange interface may include an API, a file-based interface, a message queue-based interface, and / or the like. For example, the exchange interface may include an API, including, by way of example, one or more Simple Object Access Protocol (SOAP) APIs, one or more Remote Procedure Call (RPC) APIs, one or more WebSocket APIs, one or more Representational State Transfer (REST) APIs, and / or the like. In some embodiments, the exchange interface may include one or more RPC APIs, such as one or more gRPC APIs.

[0063] 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, and / or the like for exchanging requests and / or responses between the exchange platform and the entities participating in the value exchange. By way of 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.

[0064] In some embodiments, the term “partner interface” refers to an exchange interface for facilitating one or more communications between a partner platform and an exchange platform. The partner interface may define one or more communication instructions, message definitions, and / or the like for facilitating one or more request and / or response messages between the partner platform and the exchange platform. The partner interface may include, for example, 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, and / or the like for facilitating a value exchange for a partner. In some embodiments, the partner interface defines one or more identifiers for securely identifying one or more portions of a value exchange.

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

[0066] In some embodiments, the term "entity partition" refers to a unique identifier for a computing entity. An entity partition may include a unique numeric, alphanumeric, and / or similar identifier that represents a particular computing entity. Entity partitions may include, for example, a member partition representing a member platform, a service provider partition representing a service provider platform, a partner partition representing a partner platform, and / or the like.

[0067] In some embodiments, the term "service provider partition" refers to a unique identifier for a service provider and / or the service provider's service provider platform. A service provider partition may include a series of numeric, alphanumeric, and / or any other characters or symbols that represent a service provider associated with (e.g., onboarded, registered, etc.) the exchange platform. An exchange platform, for example, may include multiple service provider partitions, each identifying a service provider platform attached to (e.g., onboarded, registered, etc.) the exchange platform. Each service provider partition may represent a service provider platform that has configured one or more exchange platform software development kits (SDKs) and / or the like to implement the exchange platform's service provider interfaces.

[0068] In some embodiments, a "partner partition" refers to a unique identifier for a partner and / or the partner's partner platform. A partner partition may include a series of numeric, alphanumeric, and / or any other characters or symbols that represent a partner associated with the exchange platform. An exchange platform may, for example, include multiple partner partitions, each identifying a partner platform attached (e.g., onboarded, registered, etc.) to the exchange platform. Each partner partition may represent a partner platform that has configured one or more exchange SDKs and / or the like to implement the exchange platform's partner interfaces.

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

[0070] 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 for a particular exchange) to facilitate functionality for the partner. The partner application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the partner. For example, the partner application may be configured to present one or more user interfaces for interacting with (e.g., browsing, purchasing, reviewing, etc.) one or more products offered by a retail-based partner, one or more units of information offered by an information-based partner, and / or the like. 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 a user.

[0071] In some embodiments, the user-facing application is a service provider application hosted by a service provider platform (e.g., a member platform acting as a service provider for a particular exchange) to facilitate functionality for the service provider. The service provider application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the service provider. For example, the service provider application may be configured to present one or more user interfaces for communicating with one or more service provider instruments (e.g., reviewing, managing, inspecting, registering, etc.) facilitated by the service provider. As an example, in a financial value system, the service provider application may enable access to bank accounts, brokerage accounts, lines of credit, and / or the like for managing funds, assets, and / or the like handled by the respective accounts. In some examples, the service provider application may be configured to receive user input (e.g., via one or more user interfaces) for receiving information, authorizations, and / or the like from the user.

[0072] In some embodiments, the term "instrument data object" refers to a data entity that represents a service provider instrument. An instrument data object may include one or more instrument identifiers and / or one or more instrument attributes. In some examples, the one or more instrument identifiers and / or one or more instrument attributes may be based at least in part on the type of the instrument data object. By way of example, a service provider instrument may be represented in a member platform as a member instrument data object. Additionally or alternatively, a service provider instrument may be independently represented by a system instrument data object in an exchange platform. In some examples, a member instrument data object and a system instrument data object may include one or more of the same one or more instrument identifiers and / or one or more instrument attributes. By way of example, a member platform may register multiple service provider instruments with the exchange platform. During registration, the member platform may provide one or more of an instrument identifier and / or instrument attributes, and in some examples, the exchange platform may return another identifier.

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

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

[0075] In some embodiments, the term "instrument identifier" refers to any representation of a service provider instrument. An instrument identifier may include an instrument identifier, an instrument reference, an instrument key, and / or the like, as described herein.

[0076] In some embodiments, the term "member instrument identifier" refers to a unique identifier for representing a service provider instrument within a member platform. A member instrument identifier may include, for example, a series of numeric, alphanumeric, and / or any other characters or symbols that represent the service provider instrument to the service provider platform.

[0077] In some embodiments, the term "instrument reference" refers to a unique identifier for referencing a member instrument identifier. An instrument reference may be generated and / or provided by a member platform to an exchange platform, for example, to allow the exchange platform to reference an instrument maintained at the member platform. In some examples, an instrument reference is the same value as the member instrument identifier. In some examples, an instrument reference is a different value mapped to the member instrument identifier.

[0078] In some embodiments, the term "system instrument identifier" refers to a unique identifier for representing a service provider instrument within an exchange platform. A system instrument identifier may include, for example, a series of numeric, alphanumeric, and / or any other characters or symbols that represent the service provider instrument to the exchange platform. In some examples, a system instrument identifier may include a UUID.

[0079] In some embodiments, the term "instrument key" refers to a unique identifier for referencing a system instrument identifier. The instrument key may be generated and / or provided by an exchange platform, for example, during the instrument registration process with the exchange platform. In some examples, the instrument key may include a wrapped system instrument identifier. For example, the instrument key may include a string of alphanumeric characters formatted according to a key format established by the exchange platform (and / or its one or more APIs). The key format may include any number of characters, such as 50 characters or more. In some examples, the characters may be case-sensitive. A first portion of the characters (e.g., the first six characters) may be reserved as a partition for identifying an entity associated with the key. In the case of an instrument key, the partition may include a service provider partition. A second portion of the characters may identify a system instrument identifier. The key formats described herein may include one or more different portions, each of which may be arranged in any order.

[0080] In some embodiments, the term "instrument representation" refers to a unique identifier for representing a service provider instrument to a user. An instrument representation may include, for example, a series of numeric, alphanumeric, or any other characters or symbols that outwardly represent a service provider instrument. The format and / or value of an instrument representation may be based at least in part 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 (e.g., the last four digits, etc.) of a persistent credential, such as an account number (e.g., debit account, credit account, etc.), a financial account name, and / or the like. As another example, in an information value system, an instrument reference may include a portion (e.g., one or more digits, alphanumeric characters, etc.) of a persistent credential, such as a subscription account and / or the like. For example, an instrument expression may include a derivative of a persistent credential that may allow only entities with prior knowledge of the persistent credential to identify the persistent credential using the instrument expression. As another example, an instrument expression may include a nickname for the instrument that is assigned by a user and subsequently recognized.

[0081] In some embodiments, the term "user data object" refers to a data entity representing a user communicating with a member platform and / or exchange platform. A user may include, for example, an entity (e.g., a person, organization, group, etc.) that engages in a value exchange governed by the exchange platform. In some examples, a user may indirectly collaborate with the exchange platform by creating a registered service provider user account, registering (and / or providing permission to register) a service provider instrument, and / or the like. In some examples, the exchange platform may act on behalf of a user without the user directly interacting with the exchange platform. For example, the exchange platform may act as a hidden intermediary between a user-facing application and the user's service provider instrument.

[0082] 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 at least in part on the type of the user data object. For example, a user may be represented in a member platform as a member user data object. Additionally or alternatively, a user may be independently represented in an exchange platform by a system user data object. In some examples, a member user data object and a system user data object may include one or more of the same one or more user identifiers and / or user attributes. For example, a member platform may register multiple users with the exchange platform. During registration, the member platform may provide one or more of the user identifiers and / or user attributes, and in some examples, the exchange platform may return another identifier.

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

[0084] In some embodiments, a system user data object is an external representation of a member user within the exchange platform. The system user data object may include one or more user identifiers, such as a member platform user reference, a system user identifier, and / or the like. Additionally or alternatively, the system user data object may include one or more user attributes, such as those described herein. As an 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, the user attributes may include a hashed and / or encrypted identifier of the user.

[0085] 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 series of numeric, alphanumeric, or any / all other characters or symbols that represent a user of the exchange platform and / or member platform. In some examples, a user identifier may include a user reference, a user key, a system user identifier, a member user identifier, and / or the like.

[0086] In some embodiments, the term "system user identifier" refers to a unique identifier for representing a user within an exchange platform. A system user identifier may include, for example, a series of numeric, alphanumeric, and / or any other characters or symbols that represent the user to the exchange platform. In some examples, a system user identifier may include a UUID unique to a particular user.

[0087] In some embodiments, the term "member user identifier" refers to a unique identifier for representing a user within a member platform. A member user identifier may include, for example, a series of numeric, alphanumeric, or any other characters or symbols that represent the user to the service provider platform.

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

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

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

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

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

[0093] 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, an instrument key, a UUEK, a member instrument reference (e.g., a partner-specific instrument reference), and / or the like. Additionally or alternatively, the partner-specific exchange data object may include one or more exchange attributes, such as an expiration date, a currency (e.g., in the case of a monetary value system), an instrument type, a previous UUEK identifier, and / or the like. In some embodiments, the member exchange data object is an external representation of a value exchange mediated using the exchange platform. The member exchange data object may include one or more identifiers, such as a member exchange identifier, a member instrument identifier, a UUEK from the exchange platform, and / or the like.

[0094] In some embodiments, the term “exchange identifier” refers to a unique identifier of a value exchange using an exchange platform. The exchange identifier may include a series of numeric, alphanumeric, and / or any other characters or symbols that represent at least a user and / or service provider instrument. In some examples, the unique exchange identifier may include a universally unique identifier (UUID) that may be mapped (e.g., through a series of identifiers, etc.) to a user, service provider instrument, and / or member registered with the exchange platform. In some examples, the exchange identifier may be randomly generated using one or more UUID generators. For example, the exchange identifier may include random 16 bytes of information generated according to one or more UUID formatting standards, such as UUID v4 and / or the like. Thus, while the exchange identifier may be utilized by the exchange platform and / or member platform for one or more functions, the same exchange identifier is useless to external parties without a prior association between the exchange identifier and one or more other identifiers. In some examples, the exchange identifier may be represented externally by a UUEK.

[0095] In some embodiments, a "universally unique ephemeral key" or "UUEK" refers to an external representation of an exchange identifier that may be issued (e.g., in place of a service provider exchange identifier and / or a partner exchange identifier) to an external entity, such as a user, partner, and / or service provider, to initiate a transaction using the exchange platform. To do so, a UUEK may be generated and issued by the exchange platform to the external entity. Each UUEK may include multiple values (e.g., up to 50 characters and / or more, which may be case-sensitive) that represent 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. By way of example, a UUEK may include a partner-specific UUEK and / or a service provider-specific UUEK. The partner-specific UUEK may be correlated to a partner-specific exchange data object as described herein, while the service provider-specific UUEK may be correlated to a service provider-specific exchange data object.

[0096] By way of example, the UUEK may be generated according to a key format. The key format may include a plurality of characters, including, for example, 50 or more characters that may be case-sensitive. A first portion of the characters (e.g., the first six characters) may be reserved as a partition for identifying the recipient of the UUEK. The partition may include, for example, a partner partition, a service provider partition, and / or any other member partition. By way of example, the UUEK may be issued in response to a request from an authorized member, such as an attached partner and / or service provider.

[0097] Additionally or alternatively, at least one character (e.g., the seventh character) of the key format may identify the format of the UUEK. At least another character (e.g., the eighth character) may identify the type of UUEK. In some examples, the second portion of characters may identify an exchange identifier (e.g., a group of 22 characters following the eighth character). The third portion of characters may be reserved (e.g., a group of 20 characters following the first portion of characters). Exemplary representations are provided below: ppppppFiGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr 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 up to 9.8 x 10^84 unique permutations, which is more than the number of atoms in the known observable universe. This allows for the generation and distribution of new UUEKs on demand without compromising the security of the underlying data to which the UUEK may be mapped, such as identifiers of users, instruments, and / or any other potentially sensitive information. The key formats described herein may contain one or more distinct parts, each of which may be arranged in any order.

[0098] In some embodiments, a "UUEK representation" refers to a viewable representation of a UUEK. The UUEK representation may include a digital representation of the UUEK viewable by a user. The UUEK representation may be represented in one or more different forms, such as, for example, a machine-readable optical image (e.g., a barcode, a quick response code, etc.), a keyword, a virtual widget, and / or the like. In some examples, the UUEK representation may include a scannable representation of the UUEK (e.g., a barcode, a QR code, a non-fungible token, a near-field communication sequence, etc.). The scannable representation may be stored in a member account on a member platform to enable a user to physically conduct a value-based exchange using a service provider instrument without referencing a persistent credential for the service provider instrument. The UUEK representation may be scanned, for example, by a barcode scanner and / or the like to read the UUEK and initiate a value-based exchange with the UUEK.

[0099] In some embodiments, a "valid UUEK representation" refers to a UUEK representation of a UUEK that has been validated by a previous secure event. A valid UUEK representation may include a status indicator and / or one or more other indicators that indicate the validated status of the UUEK. In some examples, a valid UUEK representation may include a readable UUEK representation.

[0100] In some embodiments, an "invalid UUEK representation" refers to a UUEK representation of a UUEK that is not validated by a previous secure event. An invalid UUEK representation may include a status indicator and / or one or more other indicators that indicate the invalidated status of the UUEK. In some examples, an invalid UUEK representation may include an unreadable UUEK representation. An unreadable UUEK representation may include, for example, a grayed-out, obstructed, partially covered, and / or the like, scannable representation that prevents the scannable representation from being read.

[0101] III. COMPUTER PROGRAM PRODUCTS, METHODS, AND COMPUTING ENTITIES Embodiments of the present disclosure may 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, or the like. The software components may be coded in any of a variety of programming languages. An exemplary programming language may be a low-level programming language, such as assembly language, associated with a particular hardware architecture and / or operating system platform. Software components comprising assembly language instructions may require conversion by an assembler into executable machine code before execution by the hardware architecture and / or platform. Another exemplary programming language may be a high-level programming language that may be portable across multiple architectures. Software components comprising high-level programming language instructions may require conversion to an intermediate representation by an interpreter or compiler before execution.

[0102] 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 exemplary embodiments, a software component comprising instructions in one of the foregoing examples of programming languages may be executed directly by an operating system or other software component without first having to be converted into another format. Software components may be stored as files or other data storage structures. Software components of similar types or that are functionally related may be stored together, for example, in a particular directory, folder, or library. Software components may be static (e.g., pre-established or fixed) or dynamic (e.g., created or modified at run time).

[0103] A computer program product may include a non-transitory computer-readable storage medium that stores applications, programs, program modules, scripts, source code, program code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like (also referred to herein as executable instructions, instructions for execution, computer program product, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage media includes all computer-readable media (including volatile and non-volatile media).

[0104] In one embodiment, the non-volatile computer-readable storage medium may include a floppy disk, a flexible 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 flash drive, a magnetic tape, or any other non-transitory magnetic medium, and / or the like. The non-volatile computer-readable storage medium may also include punch cards, paper tape, optical mark sheets (or any other physical medium with a pattern of holes or other optically recognizable indicia), a compact disk read-only memory (CD-ROM), a compact disk rewritable (CD-RW), a digital barcode reader (DBL), a digital video recorder (DVLC ... Such non-volatile computer-readable storage media may include DVDs, Blu-ray Discs (BDs), any other non-transitory optical media, and / or the like. 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 programmable read-only memory (EEPROM), flash memory (e.g., Serial, NAND, NOR, and / or the like), multimedia memory cards (MMC), secure digital (SD) memory cards, smart media cards, compact flash (CF) cards, memory sticks, and / or the like.Additionally, the non-volatile computer readable storage medium may also include conductive bridge 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, and / or the like.

[0105] In one embodiment, the volatile computer readable storage medium is a 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 out 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), or the like. The memory may include memory types such as SDRAM, Rambus Dynamic Random Access Memory (RDRAM), Twin Transistor RAM (TTRAM), Thyristor RAM (T-RAM), Zero-Capacitor RAM (Z-RAM), Rambus Inline Memory Modules (RIMM), Dual Inline Memory Modules (DIMM), Single Inline Memory Modules (SIMM), Video Random Access Memory (VRAM), cache memory (including various levels), flash memory, register memory, and / or the like. Where embodiments are described that utilize a computer-readable storage medium, it will be understood that other types of computer-readable storage media may be used in place of or in addition to the computer-readable storage media described above.

[0106] As will be recognized, various embodiments of the present disclosure may also be embodied as methods, apparatus, systems, computing devices, computing entities, and / or the like. Accordingly, embodiments of the present disclosure may take the form of a data structure, an apparatus, a system, a computing device, a computing entity, and / or the like that executes instructions stored on a computer-readable storage medium to perform certain steps or operations. Accordingly, embodiments of the present disclosure may also take the form of an entirely hardware embodiment, an entirely computer program product embodiment, and / or an embodiment comprising a combination of a computer program product and hardware that performs certain steps or operations.

[0107] Embodiments of the present disclosure are described below with reference to block diagrams, flowchart diagrams, messaging flows, and other representations of data, operations, and messaging schemes. It should be understood that each block, arrow, and / or the like of the diagrams, flowchart diagrams, etc. may be implemented in the form of a computer program product, an entirely hardware embodiment, a combination of hardware and computer program product, and / or an apparatus, system, computing device, computing entity, and / or the like that executes instructions, operations, steps, and similar terms used interchangeably (e.g., executable instructions, instructions for execution, program code, and / or the like) on a computer-readable storage medium for execution. For example, fetching, loading, and execution of code may be performed sequentially, such that one instruction is fetched, loaded, and executed at a time. In some embodiments, fetching, loading, and / or execution may be performed in parallel, such that multiple instructions are fetched, loaded, and / or executed together. Accordingly, such embodiments may produce a specifically configured machine that performs the steps or operations specified in the representations of the present disclosure. Thus, the expressions of this disclosure support various combinations of embodiments for implementing the specified instructions, acts, or steps.

[0108] IV. Exemplary System Architecture FIG. 1 provides an illustration of a computing ecosystem 100 that may be used with various embodiments of the present disclosure. As shown in FIG. 1, the architecture may include an exchange platform 102, one or more client devices 104, a network of member platforms 110, one or more networks 120, and / or the like. The network of member platforms 110 may include a first member platform 112a, a second member platform 112b, a third member platform 112c, and / or the like that are attached (e.g., registered, etc.) to the exchange platform 102. For example, as described herein, the network of member platforms 110 may include a partner platform and / or a service provider platform. In some examples, the partner platform may include a first member platform 112a, and the service provider platform may include a second member platform 112b that is different from the first member platform 112a. In some examples, a partner platform and / or a service provider platform may include a single member platform (e.g., third member platform 112c). In some examples, the network of member platforms 110 may be configured for one or more different services.

[0109] Each of the components of computing ecosystem 100 may be in electronic communication with one another, e.g., via the same or different wireless or wired networks 120, including, e.g., a wired or wireless personal area network (PAN), local area network (LAN), metropolitan area network (MAN), wide area network (WAN), or the like. Networks 120 may include, e.g., any type of network and / or any network connection spanning any geographic boundary (e.g., an inter-country connection involving one or more sovereign entities, etc.). Additionally, while FIG. 1 illustrates certain systems as separate, stand-alone entities, various embodiments are not limited to this particular architecture.

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

[0111] a. Exemplary Computing Platform 2 is an exemplary schematic diagram of a computing platform 200 in accordance with one or more embodiments of the present disclosure. A computing platform 200, such as exchange platform 102, member platforms 112a-c, and / or the like of FIG. 1, may include or be in communication with one or more processing elements 202 (also referred to as processors, processing circuitry, and / or similar terms used interchangeably herein) that communicate with other elements within computing platform 200 via, for example, a bus. Of course, processing elements 202 may be embodied in a number of different manners.

[0112] For example, processing element 202 may be embodied as one or more complex programmable logic devices (CPLDs), microprocessors, multicore processors, coprocessing entities, application-specific instruction set processors (ASIPs), microcontrollers, and / or controllers. Additionally, processing element 202 may be embodied as one or more other processing devices or circuitry. The term circuitry may refer to an entirely hardware embodiment or a combination of hardware and a computer program product. Thus, processing element 202 may be embodied as an integrated circuit, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array (PLA), a hardware accelerator, other circuitry, and / or the like.

[0113] It will be appreciated, therefore, that processing element 202 may be configured for a particular use or configured to execute instructions stored on volatile or non-volatile media or otherwise accessible to processing element 202. Thus, whether configured by hardware or a computer program product, or a combination thereof, processing element 202 may be capable of performing steps or operations according to embodiments of the present disclosure when configured, as appropriate.

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

[0115] As will be appreciated, the non-volatile memory 204 may store data, databases, database instances, database management systems, files, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like. The terms database, database instance, database management system, and / or similar terms used interchangeably herein may refer to a collection of records or data stored in a computer-readable storage medium using one or more database models, such as a hierarchical database model, a network model, a relational model, an entity-relationship model, an object model, a document model, a semantic model, a graph model, and / or the like.

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

[0117] As will be appreciated, the volatile memory 206 may be used to store at least a portion of, for example, a database, a database instance, a database management system, data, an application, a program, a program module, a script, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like, executed by the processing element 202. Thus, the database, the database instance, the database management system, data, an application, a program, a program module, a script, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like may be used to control certain aspects of the steps / operations of the computing platform 200 with the assistance of the processing element 202 and the operating system.

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

[0119] Although not shown, computing platform 200 may include or be in communication with one or more input elements, such as keyboard input, mouse input, touch screen / display input, motion input, movement input, audio input, pointing device input, joystick input, keypad input, and / or the like. Computing platform 200 may also include or be in communication with one or more output elements (not shown), such as audio output, video output, screen / display output, motion output, movement output, and / or the like.

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

[0121] b. Exemplary Client Device 3 is an example schematic diagram of a client device 104 in accordance with one or more embodiments of the present disclosure. The client device 104 may 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, and / or performed by one or more end users. In various embodiments, an end user of the client device 104 may wish to engage in a value exchange between a partner and a service provider. As described herein, the user may do so by interacting with one or more functionalities provided by an exchange platform through user input using the client device 104.

[0122] For example, client device 104 may be a personal computing device, a smartphone, a tablet, a laptop, a personal digital assistant, and / or the like. In various embodiments, computing platform 200 may communicate with one or more client devices 104 and manage value exchanges with one or more client devices 104. As shown in FIG. 3 , client device 104 may include an antenna 312, a transmitter 304 (e.g., wireless), a receiver 306 (e.g., wireless), and a processing element 308 (e.g., a CPLD, a microprocessor, a multi-core processor, a co-processing entity, an ASIP, a microcontroller, and / or a controller) that provide signals to and receive signals from transmitter 304 and receiver 306, respectively.

[0123] The signals provided to and received from the transmitter 304 and receiver 306 may each include signaling information / data in accordance with the air interface standard of the applicable wireless system. In this regard, the client device 104 may be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, the client device 104 may operate according to any of several wireless communication standards and protocols, such as those described above with respect to the computing platform 200. In particular embodiments, the client device 104 may operate according to numerous 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, and / or the like. Similarly, the client device 104 may operate, via the network interface 320, according to numerous wired communication standards and protocols, such as those described above with respect to the computing platform 200.

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

[0125] In some embodiments, the client device 104 includes location determination aspects, devices, modules, functions, and / or similar terms used interchangeably herein. For example, the client device 104 may include an outdoor positioning aspect, such as a location module adapted to acquire latitude, longitude, altitude, geocode, course, direction, orientation, speed, Universal Time (UTC), date, and / or various other information / data. In one embodiment, the location module may acquire data, sometimes known as ephemeris data, by identifying the number of satellites in view and their relative positions (e.g., using a Global Positioning System (GPS)). The satellites may be a variety of different satellites, including a Low Earth Orbit (LEO) satellite system, a Department of Defense (DOD) satellite system, the European Union Galileo Positioning System, the China Compass Navigation System, the Indian Regional Navigational Satellite System, and / or the like. This data may 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, and / or the like. Alternatively, location information / data may be determined by triangulating the position of the client device 104 relative to various other systems, including cellular towers, Wi-Fi access points, and / or the like. Similarly, the client device 104 may include indoor positioning aspects, such as a location module adapted to acquire latitude, longitude, altitude, geocode, heading, direction, orientation, speed, time, date, and / or various other information / data. Some indoor systems may use various position or location technologies, including RFID tags, indoor beacons or transmitters, Wi-Fi access points, cellular towers, nearby computing devices (e.g., smartphones, laptops), and / or the like.For example, such technologies may include iBeacons®, Gimbal proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, and / or the like. These indoor positioning aspects may be used in a variety of environments to determine someone or something's location down to the inch or centimeter.

[0126] In some embodiments, the client device 104 may include a user interface 316 (e.g., a display screen, a speaker, haptic mechanization, etc., coupled to the processing element 308) and / or a user input interface 318 (e.g., a touch screen, a microphone, etc., coupled to the processing element 308). For example, the user interface 316 may be one or more current application screens presented by one or more computing platforms described herein. The user input interface 318 may include any of several devices or interfaces that enable the client device 104 to receive data, such as a keypad (hard or soft), a touch display, a voice / speech or motion interface, or other input device. In examples including a keypad, the keypad may include (or cause the display of) traditional numbers (0-9) and related keys (#, *), as well as other keys used to operate the client device 104, and may include a full set of alphabetic keys or a set of keys that can be activated to provide a full set of alphanumeric keys. In addition to providing input, the user input interface may be used to activate or deactivate certain features, such as a screen saver and / or sleep mode.

[0127] The client device 104 may also include volatile memory 322 and / or nonvolatile memory 324, which may be embedded and / or removable. For example, the nonvolatile 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, Racetrack memory, and / or the like. The volatile memory 322 may be RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, registered memory, and / or the like. The volatile and non-volatile storage or memory may store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine language, executable instructions, and / or the like to implement the functionality of the client device 104. As shown, this may include partner applications, service provider applications, and / or the like that are resident on the client device 104 and / or accessible through a browser or other user interface to communicate with the computing platform 200.

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

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

[0130] c. Exemplary Network 1 may be configured to communicate with one another via respective communicative couplings to one or more networks 120. Networks 120 may include any one or combination of different types of suitable communications networks, such as, but not limited to, a cable network, a public network (e.g., the Internet), a private network (e.g., a frame relay network), a wireless network, a cellular network, a telephone network (e.g., the Public Switched Telephone Network), or any other suitable private and / or public network. Furthermore, networks 120 may have any suitable communications range associated with them and may include, for example, a global network (e.g., the Internet), a MAN, a WAN, a LAN, or a PAN. Additionally, network 120 may include any type of medium over which network traffic may be carried, including, but not limited to, coaxial cable, twisted pair wire, optical fiber, hybrid fiber coaxial (HFC) medium, microwave terrestrial transceiver, radio frequency communication medium, satellite communication medium, or any combination thereof, as well as various network devices and computing platforms provided by network providers or other entities.

[0131] d. Exemplary Value Exchange System FIG. 4 is an exemplary block diagram of an exemplary network-based exchange system 400 in accordance with one or more embodiments of the present disclosure. The network-based exchange system 400 includes a new computing ecosystem and computing platform that provides an end-to-end value exchange solution to replace traditional exchange processing systems. As described herein, the network-based exchange system 400 may be value-system agnostic and may be applied to any value-based exchange, including, by way of example, an information-based exchange, a financial-based exchange, a reputation-based exchange, a healthcare-based exchange, a benefit-based exchange, and / or the like. In any value system, the network-based exchange system 400 may utilize an intermediary entity and one or more predefined communication interfaces to facilitate network-based exchanges 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.

[0132] As depicted, network-based exchange system 400 may include exchange platform 102, partner platform 420, and / or service provider platform 440, which may be configured to communicate through one or more exchange interfaces. Partner platform 420 and / or service provider platform 440 may include one or more member platforms 112a-c from network of member platforms 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 communicate with one or more of the platforms through client device 104.

[0133] In some embodiments, the exchange platform 102 is a computing entity configured to facilitate the credential-less exchange of value for one or more members in a network. The exchange platform 102 may include one or more processing devices, memory devices, and / or the like, physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks to facilitate a value system-agnostic exchange. In some examples, the exchange platform 102 may include, define, and / or otherwise utilize one or more exchange interfaces for facilitating communication (e.g., requests, responses, etc.) between multiple members. As described herein, the interfaces may be utilized to facilitate secure exchange between one or more members in any value system.

[0134] In some embodiments, members are entities that collaborate with the exchange platform 102 to participate in a value exchange. By way of example, members may include (i) partners that utilize the exchange platform 102 to receive value, (ii) service providers that utilize the exchange platform 102 to provide value, and / or (iii) both partners and service providers. As used herein, members may be referred to as partners when they receive value through a value exchange and / or service providers when they provide value through a value exchange. Thus, depending on the member's role in the value exchange, the same member may be both a partner and a service provider. For example, a member may be a partner that receives value for 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 partner and a service provider in the same value exchange; thus, the member may provide value in only one member's value exchange and then utilize the exchange platform 102 to receive value.

[0135] In some embodiments, a member is a partner when it utilizes a service provided by a service provider. A partner may include any value-seeking entity in any value system. By way of example, in a financial value system, a partner may include a merchant (e.g., a retailer, a brick-and-mortar establishment, etc.) that may utilize a service provider, such as a financial institution, to access funds for financial transactions. Additionally or alternatively, in an information value system, a partner may include a news publisher (e.g., a newspaper, a news organization, etc.) that may utilize a service provider, such as a news agency (e.g., a wire service, a news service, etc.), to access information for information transactions. In a healthcare value system, a partner may include a healthcare provider that may access a healthcare benefits administrator to access medical benefits to fund medical procedures. Of course, the techniques of this disclosure may be applied to any value system, and a partner may include any value seeker for any respective value system.

[0136] In some embodiments, a member is a service provider when it provides a service to a partner. A service provider can include a source of value in any value system. By way of example, in a financial value system, a service provider can include a financial institution (e.g., a bank, exchange, credit union, etc.) that can provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a service provider can include a news agency (e.g., a wire service, news service, etc.) that can source information for publication by a news publisher. In a healthcare value system, a service provider can include a healthcare benefits administrator that can provide healthcare providers with access to healthcare benefits. Of course, the techniques of this disclosure may be applied to any value system, and a service provider can include any source of value for any respective value system.

[0137] In some embodiments, a service provider instrument is a mechanism utilized by a service provider to provide value on behalf of a particular user. The service provider instrument may depend on the value system and / or the service provider. In some examples, the service provider instrument may include a service provider account. For example, in a financial value system, the service provider instrument may include a bank account (e.g., checking, savings, etc.), a brokerage account, a line of credit, and / or the like. In an information value system, the service provider instrument may include a subscriber account and / or the like. In a healthcare value system, the service provider instrument may include a healthcare benefit account and / or the like.

[0138] In some embodiments, services provided by a service provider are subject to one or more policies and / or security codes. For example, a service provider and / or service provider instrument may be associated with a security code for validating use of the service provider instrument. Additionally or alternatively, a service provider may be associated with one or more member policies for authenticating the security code.

[0139] In some embodiments, a security code is a data entity that defines a sequence of characters for verifying a user during an exchange. The security code can include one or more different character sequences of dynamic length (e.g., 6 characters, 8 characters, etc.) that can be preset by the user and / or provided to the user. The security code can be provided later by the user to validate the user's presence for the exchange (e.g., by comparing the security code input to a security code reference, as described herein). The one or more different characters can include any number of alphanumeric characters, emojis, Kanji characters, Wingdings, and / or the like.

[0140] In some embodiments, the security code is a network-operated n-character PIN. As described herein, the security code may be managed as a microservice through a client device to enable and / or disable the UUEK (and / or any other exchange credentials) prior to an exchange request. In this manner, the security code may be deployed to any type of service provider instrument through the activation and / or deactivation of the corresponding UUEK. By managing the security code at the network level, members may benefit from faster exchanges because the likelihood of authorization declines due to an invalid PIN is eliminated. For example, the UUEK may be disabled until a security code is received to activate the UUEK. The exchange platform 102 may prevent a user from initiating an exchange until the UUEK is activated, thereby ensuring that all exchange authorization requests provided to the service provider are pre-activated with a security code.

[0141] In some embodiments, the security code corresponds to a user. For example, the security code may be preset by the user and / or provided to the user for a UUEK accessible to the user. In some examples, each security code may be UUEK-specific. For example, each respective security code may be configured to validate a single UUEK. By way of example, the exchange platform 102 may be configured to validate UUEKs using multiple security code tuples 424, each correlating a security code to a respective UUEK.

[0142] In some embodiments, security code tuple 424 is a data entity that defines the correlation between a UUEK and a security code. Security code tuple 424 may include a data object, a record, and / or any other data structure (e.g., linked nodes, etc.) configured to represent the association between a security code and a UUEK. Security code tuple 424 may include, for example, a security code reference, a UUEK, one or more derivative identifiers of the UUEK (as described herein), and / or context pairing data. The context pairing data may include one or more pairing attributes, such as one or more timing attributes. The timing attributes may indicate, for example, a configuration time (e.g., indicating the time the security code tuple was set), an expiration time (e.g., the time the security code must be reset), and / or the like. As described herein, the security code tuple 424 may be utilized by the exchange platform 102 to identify a security code reference in a UUEK and to validate (and / or invalidate) the UUEK based at least in part on a comparison between the security code reference and a security code input provided by a user.

[0143] In some embodiments, a security code reference is a data entity that defines a recorded security code. The security code reference may include an internal representation (e.g., for the exchange platform 102) of the security code of the UUEK.

[0144] In some embodiments, member policy 422 defines one or more enablement requirements for service provider instruments. Member policy 422 may correspond to a member and / or the member's service provider instruments. For example, member policy 422 may define one or more enablement requirements for using a service provider instrument based at least in part on one or more member-specific standards. Additionally or alternatively, member policy 422 may define one or more enablement requirements for using a service provider instrument based at least in part on one or more instrument-specific standards. A member-specific standard may apply to multiple service provider instruments associated with a member, while an instrument-specific standard may apply to at least one of multiple service provider instruments associated with a member.

[0145] The validation requirement may indicate one or more policy attributes of a value-based exchange that require a valid UUEK. For example, an invalid UUEK may be used to authorize a value-based exchange that does not include one or more attributes that require a valid UUEK. If the value-based exchange includes at least one attribute that requires a valid UUEK, the invalid UUEK may be prevented from authorizing the value-based exchange.

[0146] In some examples, a policy attribute may include an object identifier, one or more object attributes, and / or one or more value exchange attributes that identify an object and / or one or more authorized / unauthorized quantities of the object. For example, member policy 422 may include multiple object identifiers. The multiple object identifiers may indicate multiple authorized / unauthorized objects for acquisition (e.g., purchase) with an invalid UUEK.

[0147] In some examples, the object identifier may be a global object identifier. For example, the global object identifier may be a stock keeping unit (SKU) code. Additionally or alternatively, the global object identifier may be a manufacturer part number (MPN), a global trade item number (GTIN), a product or service name, an International Standard Book Number (ISBN), a Universal Product Code (UPC), an International Item Number (EIN), and / or the like. In some examples, the object identifier may include a system object identifier. The system object identifier may include, for example, an identifier (e.g., a table identifier) corresponding to a recorded data object representing an object within the exchange platform 102. In some embodiments, the system object identifier and the global object identifier are the same.

[0148] In some embodiments, the policy attributes include value exchange attributes corresponding to particular value-based exchanges and / or objects included in the value-based exchange. The value exchange attributes may include, for example, a threshold exchange value for invalid UUEKs. For example, one or more exchange attributes may indicate an exchange value, and one or more activation requirements may define an exchange value threshold above which a respective secure event is required for the service provider instrument.

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

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

[0151] In some embodiments, partner platform 420 is a computing entity configured to perform one or more operations on behalf of a partner. Partner platform 420 may include one or more processing devices, memory devices, and / or the like, physically and / or wirelessly coupled and configured to collectively (and / or individually) perform one or more computing tasks, for example, to request value in a value-system-agnostic exchange. In some examples, partner platform 420 may include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communication (e.g., requests, responses, etc.) with exchange platform 102. In some examples, partner platform 420 may be configured to host one or more user-facing applications (e.g., partner applications, etc.) for communicating with one or more users.

[0152] The partner platform 420 may host an online marketplace for partners, for example, in a financial value system, allowing users to interact (e.g., search, browse, purchase, return, etc.) with one or more products or services offered by the partners. In the case of a product purchase, the partner platform 420 may collaborate with one or more service providers to access funds for the purchase. Traditionally, access to funds from a service provider is facilitated using card numbers, account numbers, and / or other financial credentials, which may expose users to malicious parties. To address network security and data privacy concerns for 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 (e.g., requests, responses, etc.) with the exchange platform 102.

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

[0154] In some examples, the service provider platform 440 may maintain one or more financial assets (e.g., a line of credit, a bank account, etc.) that allow a user to fund an exchange to purchase a product from a partner, for example, in a financial value system. In the case of a product purchase, the service provider platform 440 may collaborate with the partner platform 420 to authorize the exchange and / or otherwise provide access to the funds for the purchase. Traditionally, access to funds from a service provider is facilitated by submitting a card number, account number, and / or another financial credential to the service provider platform 440, which may expose the user, service provider, or partner to malicious parties, especially when provided over an insecure network (e.g., a public network, and / or the like). To address network security and data privacy concerns for 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 the like 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 (e.g., requests, responses, etc.) with exchange platform 102.

[0155] As described herein, the service provider interface 404 can enable the exchange platform 102 to identify and request the use of service provider instruments to facilitate transactions. For example, the service provider platform 440 can be configured to facilitate one or more service provider instruments. In some examples, a service provider instrument can include a virtual instrument (e.g., a virtual account, a credit limit, etc.) hosted by the service provider platform 440. For example, the service provider platform 440 can be configured to maintain multiple instrument data objects that represent multiple service provider instruments for multiple attached entities.

[0156] In some embodiments, an instrument data object is a data entity that represents a service provider instrument. The instrument data object may include one or more instrument identifiers and / or one or more instrument attributes. In some examples, the one or more instrument identifiers and / or one or more instrument attributes may be based at least in part on the type of the instrument data object. By way of example, a service provider instrument may be represented in a member platform (e.g., service provider platform 440) as a member instrument data object. Additionally or alternatively, a service provider instrument may be independently represented by a system instrument data object in the exchange platform 102. In some examples, the member instrument data object and the system instrument data object may include one or more of the same instrument identifier(s) and / or instrument attribute(s). As an example, a member platform may register multiple service provider instruments with the exchange platform 102 (e.g., using the service provider interface 404). During registration, the member platform (e.g., the service provider platform 440) may provide one or more of the instrument identifiers and / or instrument attributes, and in some examples, the exchange platform 102 may return another identifier.

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

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

[0159] As described herein, a service provider instrument may be associated with one or more usage restrictions, such as a security code and / or member policy 422. In some examples, the exchange platform 102 may include an activation service 408 configured to adjudicate secure communication requests and / or exchange requests based at least in part on a valid security code entry and / or member policy 422. To do so, the exchange platform 102 (and / or its activation service 408) may access the security code tuple 424 and / or member policy 422 of the service provider instrument. For example, the member platform may register the security code with the exchange platform 102 (e.g., using the service provider interface 404 and / or the partner interface 402). After registration, the security code may be stored as a security code reference in the security code tuple 424, which associates the security code reference with the user, member, service provider instrument, and / or their associated UUEK. Additionally or alternatively, a member platform may register a member policy 422 with the exchange platform 102 (e.g., using the service provider interface 404). During registration, the member platform (e.g., the service provider platform 440) may provide one or more policy attributes, attribute updates, and / or the like to enable secure communication and / or exchange requests that reference one or more service provider instruments maintained by the member platform and / or the like. In some examples, the member platform may continually update the member policy 422 as one or more policy attributes are modified, added, and / or removed.

[0160] As described herein, the exchange platform 102 (e.g., the activation service 408) can activate a user, a service provider instrument, a UUEK, and / or an exchange request using a security code and / or a member policy 422. In some examples, the activation of an exchange request can be based at least in part on a recorded data object.

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

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

[0163] In some examples, the exchange platform 102 may maintain and / or access an object data store that includes a plurality of recorded data objects. As described herein, the object data store may include a plurality of recorded data objects that are obtained at least in part from one or more members of the exchange network.

[0164] In some embodiments, object attributes of a data entity represent characteristics of the object. Object attributes may include object-based attributes and / or exchange-based attributes.

[0165] For example, object-based attributes may include spatial attributes, count attributes, value attributes, source attributes, composition attributes, category attributes, and / or any other attributes that describe object characteristics. Spatial attributes may indicate, for example, one or more dimensions of an object (e.g., height, width, weight, etc.), value attributes may indicate the value of an object (e.g., price, etc.), composition attributes may indicate one or more ingredients, components, etc. of an object, category attributes may indicate one or more categories of an object (e.g., restricted substances, etc.), and / or the like. By way of example, one or more category attributes may indicate whether an object is associated with (i) one or more general store categories, such as vegetables, fruits, dairy, meat, grains, seeds, alcohol, tobacco, in-store consumables, hot food, pharmacy, pet food, and non-food items; (ii) one or more medical categories, such as dental, ophthalmology, and general health; (iii) one or more information categories, such as international sources, domestic sources, and / or the like. In some examples, the composition attribute may indicate one or more components of an object, such as the percentage by volume of alcohol in the object, one or more ingredients such as meat, dairy-derived, peanut-derived, tree nut-derived, soy-derived, and / or the like.

[0166] In some examples, the object-based attributes can be based at least in part on a value system. For example, in at least one financial-based value system, the object-based attributes can include one or more line item attributes, one or more line item adjustments, and / or the like. Line item attributes can include a sequence, a line item group, a product code, an item name, an item source (e.g., provider, manufacturer, etc.), a description, a quantity, a mass (e.g., grams, kilograms, etc.), one or more spatial dimensions (e.g., length, width, height, volume, etc.), a unit amount, a unit tax amount, a line amount (e.g., a line item amount), a line tax amount, and / or the like. A line item adjustment may include an adjustment type (e.g., manufacturing discount, store discount, margin, cash payment, gift card payment, other payment, and / or the like), an item, product, or service code, an item description, an item quantity, a unit item, an item mass (e.g., grams, kilograms, etc.), a unit amount, a unit tax amount, a line amount (e.g., the amount of the line item), a line tax amount, and / or the like.

[0167] In some examples, a member platform, such as partner platform 420 and / or service provider platform 440, may be associated with user-facing applications to facilitate communication with users and / or other attached entities (e.g., via client devices 104).

[0168] In some embodiments, a user-facing application is a computer program hosted by a computing entity for facilitating one or more user communications. A user-facing application may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for a computing entity, such as a member platform. For example, a user-facing application may facilitate communication between a member and a user. As an example, a user-facing application may be configured to present one or more user interfaces 406 (e.g., via a client device 104) for communicating with a user on behalf of the member. In some examples, a user-facing application may be configured to receive user input (e.g., via one or more user interfaces 406) for receiving information from the user. The user input may include, for example, a security code entry for securing the communication for the user.

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

[0170] In some embodiments, the service provider platform 440 is configured to host one or more service provider applications 418 for managing one or more service provider instruments. For example, a user-facing application may be a service provider application 418 hosted by the service provider platform 440 (e.g., a member platform acting as a service provider for a particular exchange) to facilitate functionality for the service provider. In some examples, the service provider application 418 may consist of one or more devices from a stand-alone service provider facility (e.g., a brick-and-mortar bank). The service provider application 418 may include software (e.g., computer-readable instructions, etc.) designed to perform one or more computing tasks for the service provider. For example, the service provider application 418 may be configured to present one or more user interfaces for interacting with (e.g., scanning, managing, inspecting, registering, etc.) one or more service provider instruments facilitated by the service provider. By way of example, in a financial value system, the service provider application 418 may enable access to bank accounts, brokerage accounts, lines of credit, and / or the like to manage funds, assets, and / or the like handled by the respective accounts. In some examples, the service provider application 418 may be configured to receive user input (e.g., via one or more user interfaces 406) to receive information, authorizations, and / or the like from the user.

[0171] In some embodiments, partner application 416 and / or service provider application 418 are configured to maintain, update, and / or register security codes and / or member policies 422 for users, service provider instruments, and / or their corresponding UUEKs. For example, partner platform 420 and / or service provider platform 440 may allow users, organizations, and / or any other entities to configure security codes to initiate secure information transfers. Additionally or alternatively, service provider platform 440 may allow users, organizations, and / or any other entities to configure member policies 422 to govern the use of service provider instruments.

[0172] In some examples, user input may be provided and / or received through service provider application 418 and / or partner application 416. User input may include, for example, a security code entry to initiate a secure information transfer. For example, the security code entry may be provided to exchange platform 102 through an entry into a user interface of service provider application 418 and / or partner application 416. In some embodiments, exchange platform 102 facilitates communication between partner platform 420 and service provider platform 440 using one or more exchange interfaces.

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

[0174] 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, and / or the like for exchanging requests and / or responses between exchange platform 102 and entities participating in the value exchange. By way of example, the exchange interface may include partner interface 402 for facilitating communication with partner platform 420 and / or service provider interface 404 for facilitating communication with service provider platform 440.

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

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

[0177] The exchange platform 102 can facilitate communication among a network of member platforms. For example, the member network can include multiple entities that are on-boarded with the exchange platform 102, such as by registering with the exchange platform 102, configuring their respective interfaces for communicating with the exchange platform 102, and / or the like. In some examples, the exchange platform 102 can execute one or more individual services to communicate with each on-board entity. The individual services can include, for example, one or more partner services 410 and / or service provider services 412.

[0178] In some embodiments, exchange platform 102 instantiates a separate partner-specific service, partner service 410, for each of the member networks. Additionally or alternatively, for example, in a multi-tenant environment, partner service 410 may be instantiated for one or more partners from the member networks. Partner service 410 may be configured to perform one or more exchange operations for resolving exchange requests from partner platform 420. In some embodiments, exchange platform 102 instantiates a separate service provider-specific service, service provider service 412, for each of the member networks. 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 member networks. Service provider service 412 may be configured to perform one or more exchange operations for obtaining and resolving exchange requests from partner platform 420. The exchange operations may include any of the steps and / or actions described herein.

[0179] In some embodiments, partner services 410 and / or service provider services 412 communicate 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 activation service 408. Activation service 408 may be configured to perform one or more activation operations of the present disclosure to activate a UUEK. In this manner, exchange platform 102 may pre-process exchange requests, and authorization credentials for the exchange requests, on behalf of the member platform to enforce the member platform's member policies 422.

[0180] Through the performance of one or more exchange operations, partner services 410 and / or service provider services 412 may generate and utilize multiple non-traditional identifiers to reference users, service provider instruments, and / or one or more aspects of the value exchange. At least some of these identifiers may include universally unique identifiers, such as UUEKs, that may be utilized to provide a credential-less exchange of value. Each identifier may be at least temporarily stored in platform data vault 414. Platform data vault 414 may include any type of memory device as described herein. In some examples, each service and / or one or more sets of services may be associated with a respective portion of platform data vault 414.

[0181] As described herein, one or more identifiers may be associated with one another and stored to form an identifier mapping that may be utilized by exchange platform 102 (and / or one or more services thereof) to reference users, service provider instruments, and / or any other aspects of a value exchange from communications between partner platform 420, service provider platform 440, and / or any other member platform that do not include user credentials. Examples of non-traditional identifiers will now be further described with reference to FIG. 5.

[0182] e. Exemplary Data Structures FIG. 5 is an example data diagram 500 for facilitating credential-less exchange of value in accordance with one or more embodiments of the present disclosure. Data diagram 500 illustrates multiple relational identifiers of different types. As depicted, each identifier may be associated with at least one relational identifier to form an identifier mapping within one or more platforms, such as exchange platform 102 and / or service provider platform 440. The identifier mapping enables communication between exchange platform 102 and service provider platform 440 referencing service provider instrument 518 without exposing persistent credentials 514 (e.g., username, password, card number, etc.) associated with service provider instrument 518, which may be susceptible to fraud, abuse, and exploitation by malicious parties. As illustrated, using some of the techniques of the present disclosure, persistent credentials 514 may not need to be communicated outside of service provider platform 440. Data diagram 500 illustrates only a few of the identifiers that may be generated, stored, and / or utilized by various embodiments of the present disclosure. It will be understood that the illustrated identifiers are not an exhaustive list and may include other non-illustrated identifiers. Each of the identifiers may be labeled as an identifier, reference, key, and / or other similar term. These terms are used interchangeably herein to refer to a unit of information for identifying a data structure, entity, and / or any other component described herein.

[0183] As illustrated, some of the relevant identifiers in various embodiments of the present disclosure may include, by way of example, (i) one or more user references 502 that may be mapped to member user identifiers 522 of the service provider platform 440; (ii) one or more service provider partitions 504 that correspond to a network of onboard service provider platforms, such as the service provider platform 440; (iii) one or more partner partitions 506 that correspond to a network of onboard partner platforms; (iv) one or more member instrument identifiers 522 of the service provider platform 440; The user reference 502 may include one or more instrument references 520 that may be mapped to the user reference 502 and / or instrument identifier 508, (v) one or more keys 516 and / or system identifiers 512 that may be associated with the user reference 502 and / or instrument reference 520, (vi) one or more exchange identifiers 510 that may be mapped to either the system identifiers 512 and / or the keys 516, and / or (vii) one or more UUEKs 524 that may be mapped to the exchange identifiers 510 and / or at least one of the partner partitions 506 and / or service provider partitions 504.

[0184] In some examples, the service provider platform 440 may store one or more identifiers that can be mapped to the service provider instrument 518 and / or one or more identifiers of the exchange platform 102 to enable the service provider platform 440 to reference the service provider instrument 518 based at least in part on an identifier that does not indicate any aspect of the service provider instrument 518, including the persistent credential 514, by the identifier itself.

[0185] As an example, the service provider platform 440 may store, maintain, and / or otherwise access one or more keys 516 mapped to one or more system identifiers 512 of the exchange platform 102 (e.g., being copies, derivatives, etc. of the one or more system identifiers 512). The keys 516 may, for example, include the system identifiers 512 as part of the key 516. The keys 516 may be mapped to member instrument identifiers 508 and / or member user identifiers 522, which may internally reference users of the service provider platform and / or service provider instruments 518. The keys 516 may be provided, for example, during a registration process between the service provider platform 440 and / or the exchange platform 102.

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

[0187] In some embodiments, the exchange platform 102 uses one or more entity partitions to refer to each member platform in the network of member platforms. In some embodiments, an entity partition is a unique identifier for a computing entity. An entity partition may include a unique numeric, alphanumeric, and / or similar identifier that represents a particular computing entity. An entity partition may include, for example, 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, and / or the like.

[0188] In some embodiments, the service provider partition 504 is a unique identifier for a service provider and / or the service provider's service provider platform 440. The service provider partition 504 may include a series of numeric, alphanumeric, or any / all other characters or symbols that represent a service provider associated (e.g., onboarded, registered, etc.) with the exchange platform 102. The exchange platform 102 may, for example, include multiple service provider partitions, each identifying a service provider platform 440 associated (e.g., onboarded, registered, etc.) with the exchange platform 102. Each service provider partition 504 may represent a service provider platform 440 that has configured one or more exchange platform software development kits (SDKs) and / or the like to implement the service provider interfaces of the exchange platform 102.

[0189] In some embodiments, partner partition 506 is a unique identifier for a partner and / or the partner's partner platform. Partner partition 506 may include a series of numeric, alphanumeric, and / or any other characters or symbols that represent a partner associated with exchange platform 102. Exchange platform 102 may include multiple partner partitions, each identifying a partner platform attached (e.g., installed, registered, etc.) to exchange platform 102, for example. Each partner partition 506 may represent a partner platform that has configured one or more exchange SDKs and / or the like to implement the partner interface of exchange platform 102.

[0190] In some embodiments, an entity partition is generated to identify a member platform when the member platform is onboarded to the exchange platform 102. In some examples, after onboarding to the exchange platform, the member platform may utilize one or more exchange interfaces to register one or more service provider instruments with the exchange platform 102. A service provider instrument 518 may be registered with the exchange platform 102 by exchanging one or more instrument identifiers with the exchange platform 102.

[0191] In some embodiments, the instrument identifier includes any representation of the service provider instrument 518 that identifies the service provider instrument without revealing the persistent credentials 514 of the service provider instrument 518. The instrument identifier may include a member instrument identifier 508, a system instrument identifier, an instrument reference 520, an instrument key, and / or the like, as described herein.

[0192] In some embodiments, member instrument identifier 508 is a unique identifier for representing service provider instrument 518 within a member platform, such as service provider platform 440. Member instrument identifier 508 may include, for example, a series of numeric, alphanumeric, or any / or other characters or symbols that represent service provider instrument 518 to service provider platform 440. In some examples, member instrument identifier 508 may include a table identifier of a member instrument data object.

[0193] In some embodiments, instrument reference 520 is a unique identifier for referencing member instrument identifier 508. Instrument reference 520 may be generated and / or provided by a member platform to exchange platform 102, for example, to enable exchange platform 102 to reference service provider instruments 518 maintained at the member platform. In some examples, instrument reference 520 is the same value as member instrument identifier 508. In some examples, instrument reference 520 is a different value mapped to member instrument identifier 508.

[0194] In some embodiments, the system instrument identifier is a unique identifier for representing the service provider instrument 518 within the exchange platform 102. The system instrument identifier may include, for example, a series of numeric, alphanumeric, or any / or other characters or symbols that represent the service provider instrument 518 to the exchange platform 102 without revealing the persistent credentials 514 of the service provider instrument 518. In some examples, the system instrument identifier may include a UUID. In some examples, the system instrument identifier may include at least one of the system identifiers 512.

[0195] In some embodiments, an instrument key is a unique identifier for referencing a system instrument identifier. The instrument key may be generated and / or provided by the exchange platform 102, for example, during the registration process of the service provider instrument 518 to the exchange platform 102. In some examples, the instrument key may include a packaged system instrument identifier. For example, the instrument key may include a string of alphanumeric characters formatted according to a key format established by the exchange platform 102 (and / or its one or more APIs). The key format may include any number of characters, such as 50 characters or more. In some examples, the characters may be case-sensitive. A 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. In the case of an instrument key, for example, the partition may include the service provider partition 504. A second portion of the characters may identify the system instrument identifier. In some examples, the instrument key may include at least one of the keys 516. The key formats described herein may contain one or more different parts, each of which may be arranged in any order.

[0196] In some embodiments, after onboarding to the exchange platform 102, the member platform may utilize one or more exchange interfaces to register one or more users with the exchange platform 102. A user may register with the exchange platform 102 by exchanging one or more user identifiers with the exchange platform 102. The user identifiers may be utilized, for example, to create, maintain, and / or update one or more user data objects reflecting users of the member platform and / or exchange platform 102.

[0197] In some embodiments, a user data object is a data entity representing a user communicating with a member platform and / or the exchange platform 102. A user may include, for example, an entity (e.g., a person, an organization, a group, etc.) that engages in a value exchange governed by the exchange platform 102. In some examples, a user may indirectly collaborate with the exchange platform 102 by creating a registered service provider user account, registering (and / or granting permission to register) a service provider instrument 518, and / or the like. In some examples, the exchange platform 102 may act on behalf of a user without the user directly interacting with the exchange platform 102. For example, the exchange platform 102 may act as a hidden intermediary between a user-facing application and the user's service provider instrument 518.

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

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

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

[0201] In some embodiments, the user identifier comprises a unique identifier of a user involved in a value-based exchange. The user identifier may comprise a series of numeric, alphanumeric, or any / all other characters or symbols representing a user of the exchange platform 102 and / or member platform. In some examples, the user identifier may comprise a user reference 502, a user key, a system user identifier, a member user identifier, and / or the like.

[0202] In some embodiments, a system user identifier is a unique identifier for representing a user within exchange platform 102. A system user identifier may include, for example, a series of numbers, alphanumeric characters, and / or any other characters or symbols that represent a user to exchange platform 102. In some examples, a system user identifier may include a UUID that is unique to a particular user. In some examples, a system user identifier may include at least one of system identifiers 512.

[0203] In some embodiments, the member user identifier 522 is a unique identifier to represent the user within the member platform. The member user identifier may include, for example, a series of numbers, alphanumeric characters, or any other characters or symbols that represent the user to the service provider platform 440.

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

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

[0206] 5, keys 516, such as the user and instrument keys described herein, may be shared across the exchange platform 102 and the service provider platform 440. Additionally, in some examples, references, such as instrument references 520 and user references 502, may be shared across entities. These identifiers, and the mapping scheme described herein, allow the exchange platform 102 to reference the service provider instrument 518 without knowledge of the persistent credentials 514 (e.g., card number, etc.) of the service provider instrument 518. As described herein, one or more of the keys 516 and / or references may be provided to the service provider platform 440 individually or in any combination. In some examples, each of the keys 516 and references may be provided to the service provider platform 440 in a redundant process that allows the service provider platform to verify that the communication is provided by the exchange platform 102 (e.g., an entity with access to a unique set of keys and references).

[0207] In some embodiments, the persistent credentials 514 for the service provider instrument 518 include confidential user and / or instrument credentials, such as card numbers, account numbers, subscription numbers, and / or the like, that may expose users, members, and / or intermediary entities to risk. The persistent credentials 514 may be generated, accessed, and / or otherwise provided to a user by the service provider platform 440 when the user applies for a new service provider instrument 518, is authorized for a new service provider instrument 518, and / or is otherwise enabled to open a new service provider instrument 518. Traditionally, the persistent credentials 514 are then used by the user to initiate value exchanges using the service provider instrument. By doing so, the user is forced to reveal confidential credentials directly tied to the service provider instrument 518 each time the service provider instrument 518 is used. The key 516, reference, and identifier mapping scheme of the present disclosure overcomes these technical deficiencies.

[0208] In some examples, each of the identifiers is interpretable not to a user but to a computing platform, such as the exchange platform 102 and / or the service provider platform 440. To allow a user to select a service provider instrument 518 while maintaining the enhanced security features of the present disclosure, in some examples, the identifiers of FIG.

[0209] In some embodiments, the instrument representation (not depicted by FIG. 5 ) is a unique identifier for representing the service provider instrument 518 to a user without revealing the service provider instrument's 518 persistent credential 514. The instrument representation may include, for example, a series of numeric, alphanumeric, or any / all other characters or symbols that ostensibly represent the service provider instrument 518 only to entities with prior knowledge of the service provider instrument 518. The format and / or value of the instrument representation may be based at least in part on the type of service provider and / or service provider instrument 518. For example, in a financial value system, the instrument representation may include a portion of the persistent credential 514 (e.g., the last four digits), such as a card number (e.g., debit card, credit card, etc.), a financial account number, and / or the like. As another example, in a value-of-information system, an instrument representation may include a portion (e.g., one or more digits, alphanumeric characters, etc.) of a persistent credential 514, such as a subscription account and / or the like. For example, an instrument representation may include a derivative of a persistent credential 514 that may allow only entities with prior knowledge of the persistent credential 514 to identify the persistent credential 514 using the instrument representation. As another example, an instrument representation may include a nickname for an instrument that is assigned by a user and subsequently recognized.

[0210] In some embodiments, the instrument representation may be provided to the exchange platform 102 (e.g., during the registration process) in place of the persistent credential 514. In this manner, the exchange platform 102 can use the instrument representation to represent the service provider instrument 518 without knowledge of the persistent credential 514 from which the instrument representation may be derived. For example, unlike conventional network-based exchange platforms, the exchange platform 102 may not require the persistent credential 514 corresponding to the service provider instrument 518 to implement various computing tasks of the present disclosure. This allows the exchange platform 102 to operate more flexibly while still storing previously unrecorded context data, lowering the computing cost of operations, and improving user and platform protection from intrusion attacks by malicious computing entities.

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

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

[0213] In some embodiments, a system exchange data object is an internal representation of a value exchange mediated using the exchange platform 102. In some examples, a system exchange data object may include one or more different identifiers and / or exchange attributes depending on the system exchange data object's role in the value-based exchange.

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

[0215] 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, such as an instrument key, a UUEK 524, a member instrument reference (e.g., a partner-specific instrument reference), and / or the like. Additionally or alternatively, the partner-specific exchange data object may include one or more exchange attributes, such as an expiration date, a currency (e.g., for a monetary value system), an instrument type, and / or the like.

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

[0217] In some embodiments, the exchange identifier 510 is a unique identifier for a value exchange using the exchange platform 102. The exchange identifier 510 may include a series of numeric, alphanumeric, and / or any other characters or symbols that represent at least a user and / or a service provider instrument 518. In some examples, the exchange identifier 510 may include a universally unique identifier (UUID) that may be mapped (e.g., via a series of identifiers, etc.) to a user, a service provider instrument 518, and / or a member registered with the exchange platform 102. In some examples, the exchange identifier 510 may be generated using one or more UUID generators. For example, the exchange identifier 510 may include 16 bytes of information generated according to one or more UUID formatting standards, such as UUID v4, and / or the like. Thus, while an exchange identifier 510 may be utilized by the exchange platform 102 and / or a member platform for one or more functions, the same exchange identifier 510 is useless to an outside party without a prior association between the exchange identifier 510 and one or more other identifiers. In addition to the prior identifier association, the exchange identifier 510 may be associated with the exchange platform 102. Thus, even if an exchange identifier 510 is identified by a harmful party, the harmful party would still be required to impersonate the exchange platform 102 in order to use the exchange identifier 510. Moreover, the harmful party would need to update the settlement account to an account owned by the harmful party, among several other tasks, before the exchange identifier 510 could be used adversely. Each of these tasks increases the amount of work required to overcome the enhanced layer of security added by the exchange identifier 510. When paired with the temporary nature of the exchange identifier 510, these tasks can become prohibitively expensive.

[0218] In some examples, the exchange identifier 510 may be externally represented by a UUEK 524. By way of example, to facilitate credential-less exchanges, the exchange platform 102 may issue one or more UUEKs 524 to one or more member platforms. As described herein, the UUEK 524 may remove reliance on traditional persistent credentials 514 by identifying aspects of the value exchange through previously mapped data entities.

[0219] In some embodiments, the UUEK 524 is an external representation of the exchange identifier 510 that may be issued (e.g., in place of the exchange identifier 510) to an external entity, such as a user, a partner platform, and / or a service provider platform, and / or the like, to initiate a value-based exchange using the exchange platform 102. To do so, the UUEK 524 may be generated and issued by the exchange platform 102 to the external entity. Each UUEK 524 may include multiple values (e.g., up to 50 characters and / or more, which may or may not be case-sensitive) that represent one or more aspects of the value-based exchange. For example, the multiple values may indicate the exchange identifier 510, a partition (e.g., identifying the recipient of the UUEK 524), an identifier type, and / or one or more flags. By way of example, the UUEK 524 may include a partner-specific UUEK and / or a service provider-specific UUEK. The partner-specific UUEK may be correlated to a partner-specific exchange data object as described herein and may include the partner partition 506, while the service provider-specific UUEK may be correlated to a service provider-specific exchange data object and may include the service provider partition 504.

[0220] By way of example, the UUEK 524 may be generated according to a key format. The key format may include a number of characters, e.g., including 50 or more characters, that may be case-sensitive. A first portion of the characters (e.g., the first six characters) may be reserved as a partition for identifying the recipient of the UUEK 524. The partition may include, for example, the partner partition 506, the service provider partition 504, and / or any other member partition. By way of example, the UUEK 524 may be issued in response to a request from an authorized member, such as an attached partner and / or service provider.

[0221] Additionally or alternatively, at least one character (e.g., the seventh character) of the key format may identify the format of the UUEK 524. At least another character (e.g., the eighth character) may identify the type of UUEK 524. In some examples, a second portion of characters may identify the exchange identifier 510 (e.g., the group of 22 characters following the eighth character). A third portion of characters may be reserved (e.g., the group of 20 characters following the first portion of characters). Exemplary representations are provided below: ppppppFiGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr 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 for up to 9.8 x 10^84 unique permutations, which is more than the number of atoms in the known observable universe. This allows for the generation and distribution of new UUEKs 524 on demand without compromising the security of the underlying data to which the UUEK 524 may be mapped, such as identifiers for users, instruments, and / or any other potentially sensitive information.

[0222] In some embodiments, the exchange platform 102 maintains multiple security code tuples 424 for one or more users, member platforms, service provider instruments, and / or the like registered with the exchange platform 102. A security code tuple 424 may be a data entity that defines an association between a security code, a user, and one or more of a member platform and / or a service provider instrument. A security code tuple 424 may include a data object, record, and / or any other data structure (e.g., linked nodes, etc.) configured to represent an association between a security code and a user, and, in some embodiments, a member platform, a service provider instrument, or both. A security code tuple 424 may include one or more system identifiers 512, such as, for example, a security code reference, a user identifier, one or more member identifiers, one or more instrument identifiers, and / or the like, and / or context pairing data. The context pairing data may include one or more pairing attributes, such as one or more timing attributes. The timing attributes may indicate, for example, a configuration time (e.g., indicating the time when the security code tuple was set), an expiration time (e.g., the time when the security code must be reset), and / or the like. As described herein, the security code tuple 424 may be utilized by the exchange platform 102 to identify a user's security code reference and perform secure actions on behalf of the user (e.g., enabling use of the UUEK for exchange) based at least in part on a comparison between the security code reference and a security code input provided by the user.

[0223] In some embodiments, a security code reference is a data entity that defines a recorded security code. The security code reference may include an internal representation (e.g., for the exchange platform 102) of a user's security code.

[0224] In some embodiments, a security code is a data entity that defines a sequence of characters for verifying a user during communication, such as a physical exchange, a virtual exchange, a registration, and / or the like. The security code can include one or more different character sequences of dynamic length (e.g., 6 characters, 8 characters, etc.) that can be preset by a user and / or provided to a user. The security code can be provided later by a user to validate the user's presence for communication (e.g., by comparing a security code input to a security code reference, as described herein). The one or more different characters can include any number of alphanumeric characters, emojis, Kanji characters, Wingdings, and / or the like.

[0225] In some embodiments, the security code is a network-operated n-character PIN. As described herein, the security code may be administered as a service through a client device to (i) securely retrieve the UUEK, (ii) register the instrument with the member platform, and / or (iii) enable or disable the use of the UUEK (and / or any other exchange credentials) prior to an exchange request. In this manner, a security code may be deployed to any type of service provider instrument through the lookup, registration, and / or activation or deactivation of the corresponding UUEK. By managing security codes at the network level, members may benefit from faster exchanges because the likelihood of authorization declines due to invalid PINs is eliminated. For example, the UUEK may be disabled until a security code is received to activate the UUEK. The exchange platform may prevent a user from initiating an exchange until the UUEK is activated, thereby ensuring that all exchange authorization requests submitted to the service provider are pre-activated with the security code in mind. This effectively reduces network traffic between members in the switching network, thereby reducing network congestion in traditional high-traffic communication systems.

[0226] In some embodiments, the security code corresponds to a user. For example, the security code may be preset by and / or provided to the user through communication with the exchange platform 102. As an example, the security code may be set by the user through communication with an exchange network widget embedded within a member software application. This allows the security code to be set without directly communicating with or sharing the security code with each member platform, such as the service provider platform 440. In some examples, the security code may be instrument or member specific. For example, each security code may be configured to retrieve and / or enable a particular member platform's UUEK and / or a particular member platform's service provider instrument. Additionally or alternatively, each security code may be configured to register a member platform account with the exchange network. As an example, the exchange platform 102 may govern the use of security codes to perform one or more secure actions using multiple security code tuples, each correlating a security code to a respective user, member platform, and / or service provider instrument.

[0227] V. Exemplary System Operation FIG. 6 provides a process flow for facilitating a network-operated security code for a user according to one or more embodiments of the present disclosure. The process flow depicts a network process 600 for establishing a network-operated security code for use in conducting secure information transmissions between a user and a third party. Process 600 can be utilized to overcome various limitations of conventional exchange systems that rely on the limited complexity of traditional PINs and, as described herein, limited PIN mechanisms that insufficiently secure network information transmissions depending on the party administering the PIN. Process 600 can be performed by one or more computing devices, entities, and / or systems described herein. For example, through the various steps / operations of process 600, an exchange platform can utilize various communication and activation technologies to overcome various limitations associated with conventional mechanisms of network exchanges by improving the operation of security codes for securing network-based information transmissions.

[0228] 6 illustrates an example process 600 for purposes of explanation. Although the example process 600 depicts a particular sequence of steps / actions, the sequence may be varied without departing from the scope of the present disclosure. For example, some of the depicted steps / actions may be performed in parallel or in a different sequence without substantially impacting the functionality of the process 600. In other examples, different components of the example device or system performing the process 600 may perform functions substantially simultaneously or in a unique sequence.

[0229] In some embodiments, process 600 includes, at step / operation 602, establishing a security code session. For example, an exchange platform (e.g., its partner service, service provider, etc.) may establish the security code session. In some examples, process 602 may begin on a member application, such as a partner application (e.g., a partner website, a user application, etc.) and / or a service provider application, where the member platform may enable a user to manage (e.g., set, reset, remove, etc.) network-operated security codes. The member platform may enable management of network-operated security codes by initiating a security code session with the exchange platform.

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

[0231] In some embodiments, process 600 includes receiving a security code request at step / operation 604. For example, the exchange platform (e.g., its partner service, service provider, etc.) can receive the security code request through an established communication session with the member platform. For example, a security code management widget can provide a user prompt for information regarding a network-operated security code. The user can respond to the prompt through a client device to generate and provide a security code request to the exchange platform. The security code request is generated and provided through a widget running within a member application. In this manner, the member application can be used as an interface between the exchange platform and the user without the member platform always having access to the security code information provided by the user.

[0232] In some embodiments, a security code request is a data entity that defines a request to set, reset, and / or remove a user's security code. A security code request may be provided to an exchange platform by a member of an exchange network. The security code request may indicate the user's member-user reference and, in some instances, the user's member-instrument reference. By way of example, a security code request that includes only a member-user reference may default to all service provider instruments associated with the user and, for example, may initiate security code tuple actions (e.g., one or more set, reset, and / or remove operations) against security codes applied to all service provider instruments maintained by the respective member platforms for the user. Additionally or alternatively, a security code request that includes a member-user reference and a member-instrument reference may initiate security code tuple actions (e.g., one or more set, reset, and / or remove operations) against security codes applied to specific service provider instruments maintained by the respective member platforms for the user. In addition to the reference, the security code request may include a code action attribute indicating the desired set, reset, and / or remove action, as well as a security code input indicating a new, modified, or existing n-character PIN to replace, modify, or remove the user's security code.

[0233] In this manner, the security code widget may be configured to communicate with a user to set, reset, and / or remove a particular security code, allowing the security code to be set, reset, and / or removed without communicating directly with a member platform. This improves network security by providing an exchange platform that is one access point for a single user to modify multiple different security codes across multiple different member platforms.

[0234] In some embodiments, process 600 includes, at step / operation 606, validating the user. For example, the exchange platform (e.g., its partner service, service provider, etc.) may validate the user by comparing a user reference from the security code request with multiple pre-registered user identifiers. The user may be validated if the user reference corresponds to the user identifier. If the user is validated, process 600 may proceed to step / operation 610 and perform a security code tuple action on behalf of the identified user. Otherwise, process 600 may proceed to step / operation 612 and provide a security code response indicating that the user could not be validated.

[0235] In some embodiments, process 600 optionally includes, at step / operation 608, enabling a service provider instrument. For example, an exchange platform (e.g., its partner service, service provider, etc.) can enable a service provider instrument if the security code request includes an instrument reference. The instrument can be enabled if the instrument reference corresponds to a pre-registered instrument identifier. If the instrument is enabled, process 600 can proceed to step / operation 610 and perform a security code tuple action on behalf of the identified user. Otherwise, process 600 can proceed to step / operation 612 and provide a security code response indicating that the instrument could not be enabled.

[0236] In some embodiments, process 600 includes performing a security code tuple action at step / operation 610. For example, the exchange platform (e.g., its partner service, service provider, etc.) may perform the security code tuple action by setting a new security code for the user, resetting the user's security code, and / or removing the user's security code. To do so, the exchange platform may (i) generate a new security code tuple including the user's user identifier and the new security code, (ii) modify the existing security code tuple corresponding to the user identifier to update the user's security code, and / or (iii) remove the existing security code tuple corresponding to the user.

[0237] In some embodiments, process 600 includes providing a security code response at step / operation 612. For example, the exchange platform (e.g., its partner service, service provider, etc.) may provide a security code response indicating completion and / or failure of the security code tuple action.

[0238] 7A-7C provide a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. The process flow illustrates one or more stages of a registration process 700 for registering a user and / or service provider instrument with another member platform to facilitate credential-less value exchange between the two member platforms. FIGS. 7A-7C illustrate the exemplary process 700 for illustrative purposes. Although the exemplary process 700 depicts a particular sequence of steps / actions, the sequence may be varied without departing from the scope of the present disclosure. For example, some of the depicted steps / actions may be performed in parallel or in a different sequence without substantially impacting the functionality of the process 700. In other examples, different components of the exemplary device or system implementing the process 700 may perform functions substantially simultaneously or in a particular sequence.

[0239] Various embodiments of process 700 address technical challenges related to data security and efficiency of network-based exchanges of value between one or more computing entities. Conventional systems address these challenges using registration mechanisms that require users to disclose confidential and persistent credentials to a third-party registration service. These conventional registration services then validate the user's account ownership and provide the persistent credentials to a partner platform for storage and subsequent processing. By doing so, user credentials are transmitted and disclosed to numerous different entities during the conventional registration process, ultimately increasing the risk of exposure to malicious parties during and after network communications. Various embodiments of process 700 provide improved network communication, data encryption, and data management techniques to enable credential-less exchange registration capabilities, reducing the data security risks imposed by the conventional process.

[0240] One or more embodiments of process 700 may be implemented by one or more computing devices, entities, and / or systems described herein. For example, through the various steps / operations of process 700, the exchange platform 102 can leverage credential-less registration techniques to overcome various limitations associated with traditional registration mechanisms by registering a service provider instrument with a partner platform without access to the service provider instrument's persistent credentials. By doing so, the sensitive information underlying the service provider instrument for engaging in value exchange is never exposed to potentially malicious parties or partner platforms that may be susceptible to network-based attacks. For example, unlike conventional techniques, the exchange platform 102 never receives a user's identifiable or actionable account information, while the service provider managing the account is engaged in the registration process rather than being disintermediated by a potentially insecure registration service. This further eliminates the need to enforce resource data governance standards across each device involved in the registration process, ultimately resulting in improved computing resource utilization while enhancing network and data security.

[0241] 7A is a flowchart illustrating an example of a first stage of a registration process 700 for registering a user with an exchange platform without disclosing persistent credentials associated with the user and / or service provider instruments. The flowchart depicts communication techniques for overcoming various limitations of conventional registration systems by bypassing the conventional systems' reliance on confidential and persistent credentials. The communication techniques may be performed by one or more computing devices, entities, and / or systems described herein, such as an exchange platform, for establishing a secure communication session with a user through a partner application.

[0242] In some embodiments, process 700 includes establishing a registration session for a user and a partner platform at step / operation 702. For example, registration process 700 may begin with a partner application (e.g., a partner website, a user application, etc.), at which point the partner platform may enable the user to register a partner account on the partner application with the exchange platform to facilitate access to service provider instruments. The partner platform may enable the user's registration by initiating a registration session with the exchange platform.

[0243] For example, a user may access a partner application through a portal via a client device, such as a browser, web application, and / or the like, as described herein. The user's browser, web application, mobile application, and / or the like may fetch a platform connection widget from a content delivery network (CDN) and issue a communication session request to the partner platform to establish a registration session. In response to the request, the partner platform may generate a communication session request (e.g., using one or more exchange interfaces, etc.) to an 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.

[0244] In some embodiments, the communication session request includes one or more registration attributes, such as user data, a user identifier, a user hash, a time stamp, a device identifier, a partner identifier, and / or the like. As described herein, some techniques of the present disclosure enable a computing entity to identify a service provider instrument using an identifier that does not include the service provider instrument's persistent credentials along with the communication session request. For example, a partner platform may be configured to obtain user data for a user (e.g., through user input on a user interface screen, pre-recorded data from a partner account, etc.) and provide the user data to the exchange platform to begin the registration process. In some examples, the user data may be provided by the partner platform (e.g., through one or more API calls of a partner interface, etc.) along with the communication session request to the exchange platform (e.g., its partner service) to initialize a widget session. In some examples, the user data may be encrypted, hashed, and / or the like before transmission to the exchange platform. In some examples, the user data may include one or more user attributes as described herein.

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

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

[0247] In some embodiments, process 700 includes, at step / operation 706, generating a session identifier for the registration session. For example, the exchange platform (e.g., its connection service, partner service, etc.) can generate a session identifier for a communication session between the partner platform and the exchange platform for tracking communications exchanged during the registration session. The session identifier can include, for example, a unique number, a string of characters, and / or the like for authenticating messages exchanged during the registration session. The exchange platform can use 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 a 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 the user registration. The connection service can generate a session identifier and return the session identifier to the partner service. The partner service can return the session identifier to the partner platform, which can utilize the session identifier to initialize the client-side widget through an instance of a partner application on the client device. Once the partner application receives the session identifier, the partner application can launch (e.g., run, initialize, etc.) the client-side widget. The user can then interact with the widget to complete the registration process 700.

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

[0249] For example, the exchange platform may determine one or more service provider platforms based at least in part on user attributes of the registration session and align the service provider list with the one or more service provider platforms. By way of example, the exchange platform may include multiple system user data objects and / or system instrument data objects, as described herein. In some examples, the exchange platform may identify one or more system user data objects corresponding to a user based on the user attributes. In some examples, each system user data object may identify a service provider platform associated with the user. In this manner, the exchange platform may determine one or more service providers associated with a user based on the one or more system user data objects.

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

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

[0252] The registration process 700 can then proceed to a second stage in which an instrument identifier corresponding to the user is identified through communication between the exchange platform, the user, and the service provider platform, as described in further detail with reference to FIG. 7B.

[0253] 7B, which is a flowchart illustrating an example of a second stage of a registration process 700 for registering a service provider instrument with a partner platform without disclosing persistent credentials associated with the user and / or the service provider instrument. The flowchart depicts communication techniques for overcoming various limitations of conventional registration systems by bypassing the conventional systems' reliance on persistent credentials, such as card numbers and / or the like, provided by the user. The communication techniques may be performed by one or more computing devices, entities, and / or systems described herein, such as an exchange platform, for establishing connections between the user, the partner platform, and the service provider instrument.

[0254] In some embodiments, process 700 includes, at step / operation 710, determining and providing a user's service provider instrument list. The service provider instrument list may be determined based at least in part on a service provider selection from a pre-registration screen. For example, in some examples, the exchange platform (e.g., its connectivity service, partner service, etc.) may use a partner interface to receive pre-selection data indicating a selection of a particular service provider from one or more service providers presented by the pre-registration screen. For example, a widget may receive the pre-selection data from a partner application and provide an instrument registration request (e.g., via a partner interface) to the exchange platform (e.g., its connectivity service, partner service, etc.). The instrument registration request may include a session identifier and / or a service provider identifier indicating the selected service provider.

[0255] In response to the request, the exchange platform (e.g., its connectivity service, partner service, etc.) can receive service provider instrument data based at least in part on the preselection data. The service provider instrument data may indicate one or more service provider instruments for the user that are facilitated by the selected service provider platform. For example, the service provider instrument data may include one or more system instrument identifiers and / or corresponding instrument representations from one or more instrument data objects corresponding to the service provider and the user. Each of the instrument data objects may include, for example, a system user identifier corresponding to the user.

[0256] Additionally or alternatively, the exchange platform (e.g., its one or more service provider services) may provide an instrument request for service provider instrument data from a selected service provider platform (e.g., via a service provider interface). The instrument request may include, for example, a user reference corresponding to a member user identifier of the service provider platform. In response to the request, the service provider platform may identify one or more member instrument data objects that include the member user identifier, identify one or more instrument references that correspond to the one or more member instrument data objects, and provide service provider instrument data to the exchange platform indicating the one or more instrument references and / or one or more corresponding instrument representations.

[0257] The exchange platform (e.g., its connectivity service, partner service, etc.) can use the partner interface and, via the registration user interface, initiate the presentation of an instrument registration screen through the user's client device based at least in part on the service provider instrument data. The instrument registration screen can be internally defined by the partner and / or provided by the exchange platform. The instrument registration screen may, for example, show one or more service provider instruments associated with the user and the selected service provider. By way of example, the instrument registration screen may show a respective instrument representation for each of the one or more service provider instruments. In some examples, for example, only when the user has subscribed to a single service provider instrument, the instrument registration screen may include a confirmation prompt to confirm the user's intent to register the service provider instrument.

[0258] In some embodiments, process 700 includes receiving a secure communication request at step / operation 712. For example, the exchange platform may receive the secure communication request from a member platform using a member interface. In some embodiments, the secure communication request is a data entity defining a request to perform a secure communication using a security code entry. The secure communication request may be provided to the exchange platform from a member of the exchange network. The secure communication request may indicate (i) a user, member platform, and / or service provider instrument, and (ii) the user's security code entry. In some examples, the secure communication request may indicate a service-provided instrument selected by the user from a service provider instrument list.

[0259] In some examples, the secure information transfer request may indicate one or more context security attributes. The one or more context security attributes may include one or more timing attributes. The one or more timing attributes may indicate, for example, a serving time (e.g., indicating a time when the secure information transfer request is sent), a request time (e.g., a requested time to perform the secure information transfer), and / or the like.

[0260] The secure information transfer request may be received from a member platform. For example, a user may initiate a secure information transfer request through a member application hosted by the member platform on behalf of a member of the exchange network. In some examples, the secure information transfer request may be generated and / or provided in response to a selection input indicating a service provider instrument, a UUEK for the service provider instrument, and / or the like. As one example, a user may select an instrument representation, a UUEK representation, and / or the like (e.g., through a partner application associated with a partner platform, a service provider application associated with a service provider platform, etc.) to register a service provider instrument, authorize a value-based exchange, and / or the like. In some examples, the secure information transfer request may be automatically initiated when the user and / or the selected instrument, UUEK, and / or the like are associated with a security code. For example, in response to a selection, the member platform (e.g., through the respective member application) may prompt the user to enter a security code, and the user may enter the security code to provide a secure information transfer request.

[0261] In some examples, the exchange platform can receive a secure information transfer request from a client-side widget using a partner interface. The request can include selection data and / or security code entry. The selection data can indicate a selection of a service provider instrument from a registration user interface. For example, the selection data can indicate an instrument representation (e.g., an account nickname, etc.) of the selected service provider instrument. In some examples, the selection data can include at least one of an instrument type, a currency type (e.g., in a monetary value system), and / or an instrument identifier (e.g., an instrument representation, etc.) corresponding to the selection.

[0262] In some embodiments, process 700 includes verifying the security code input of the secure information transfer request at step / operation 714. In some examples, the exchange platform (e.g., its connectivity service, partner service, etc.) can compare the security code input with the security code tuple corresponding to the secure information transfer request to verify the user's presence. The exchange platform can generate a validation event indicating verification and / or non-verification of the security code input. In the case of verification, process 700 can proceed to step / operation 718, where the exchange platform provides a valid secure information transfer response. In the case of non-verification, the exchange platform can proceed to step / operation 716, where the exchange platform provides an invalid secure information transfer response and then return to step / operation 712 to receive another secure information transfer request.

[0263] In some embodiments, a validation event is a data entity that defines the validation of a user's security code input. The validation event may include a secure event, which may indicate validation between the security code input and the security code reference. Additionally or alternatively, the validation event may include a non-secure event, which may indicate a failed validation between the security code input and the security code reference. For example, a secure event may indicate a determination that the security code input matches the corresponding security code reference. In some examples, a non-secure event may indicate a determination that the security code input does not match the corresponding security code reference. In some examples, the exchange platform may generate a secure event in response to a determination that the security code input matches the corresponding security code reference. Additionally or alternatively, the exchange platform may generate a non-secure event in response to a determination that the security code input does not match the corresponding security code reference. In some examples, the secure event may be associated with a secure period, and the exchange platform may generate a non-secure event in response to a determination that the secure period has expired.

[0264] In some embodiments, the activation event is stored in association with a secure data entity, such as a UUEK, a service provider instrument, and / or a user. For example, the activation event may be stored in an exchange data object corresponding to the UUEK, a system instrument data object corresponding to the service provider instrument, a system user data object corresponding to the user, and / or the like. Additionally or alternatively, the activation event may be stored in association with a security code tuple. For example, a secure event may be stored in response to activating a user, while a non-secure event may be stored in response to disabling a user.

[0265] In some embodiments, the activation event includes context activation data. The context activation data may indicate, for example, the timing of the activation. The timing of the activation may include a timestamp corresponding to the transmission, receipt, creation, and / or adjudication of the activation request. For example, the context activation data may include an activation timestamp indicating the time at which the exchange platform determined that the security code input and security code reference match or do not match. In some examples, the context activation data may indicate a secure period. The secure period may indicate a timestamp, a time duration, and / or the like after which the UUEK, service provider instrument, and / or the like may be secured in response to the secure event.

[0266] In some embodiments, process 700 includes, at step / operation 718, providing a valid secure signaling response to the partner platform. For example, the exchange platform may provide the valid secure signaling response to the partner platform. The secure signaling response may define a response to the secure signaling request. In some embodiments, the secure signaling response is provided from the exchange platform to the member that provided the secure signaling request. The secure signaling response may indicate a validation event. The valid secure signaling response may indicate a successful validation event.

[0267] In some embodiments, process 700 includes, at step / operation 720, providing a registration request to a service provider platform corresponding to the service provider instrument in response to the user's network-level activation. For example, an exchange platform (e.g., its service provider service) can use a service provider interface to provide a registration request corresponding to the selected service provider instrument to the service provider platform. The registration request can include service provider registration data indicating one or more user identifiers of the user and / or one or more instrument identifiers of the service provider instrument. In response to the registration request, the service provider platform can validate the service provider instrument using the one or more identifiers.

[0268] The service provider registration data may include, for example, one or more identifiers for referencing the service provider instrument during communication between the exchange platform, the service provider platform, and / or the partner platform without using the service provider instrument's persistent credentials (e.g., card number, account number, etc.). The one or more identifiers may include various combinations of user identifiers and / or instrument identifiers, for example, for validating the user and / or instrument through one or more redundancy checks. For example, a user identifier for a user may include a user reference for the service provider platform and / or a user key from the exchange platform corresponding to the user reference. As another example, an instrument identifier for a service provider instrument may include an instrument reference for the service provider platform and / or an instrument key from the exchange platform corresponding to the instrument reference.

[0269] The service provider registration data may include any combination of references, keys, and / or identifiers described herein. In one example, the service provider registration data may include one of an instrument reference, an instrument key, a user reference, and / or a user key. Additionally or alternatively, the service provider registration data may include a corresponding combination of instrument references, instrument keys, user references, and user keys for inherent redundancy. In some examples, the identifier combination may be specified by an interface call. The combination may be service provider-specific and / or may change dynamically according to a communication scheme. In this manner, the specific combination of identifiers provided in the registration request may be utilized as an additional validation check to ensure that the registration request is received from an attached platform, such as an exchange platform.

[0270] The service provider may compare the identifier from the registration request with one or more member data objects (e.g., member instrument data objects, member user data objects, etc.) to identify the service provider instrument that corresponds to the registration request without exposing the service provider instrument's persistent credentials.

[0271] Referring now to FIG. 7C, FIG. 7C is a flowchart illustrating an example of a third stage of a registration process 700 for issuing a UUEK to facilitate credential-less exchange of value. The flowchart depicts communication techniques for overcoming various limitations of conventional registration systems by bypassing the conventional systems' reliance on an instrument reference, such as a card number and / or the like, provided by a user. The communication techniques may be performed by one or more computing devices, entities, and / or systems described herein, such as an exchange platform, to establish a user instrument record for registering the user with the exchange platform.

[0272] In some embodiments, process 700 includes receiving a registration response from the service provider platform at step / act 722. For example, the exchange platform may receive a registration response indicating successful or unsuccessful registration.

[0273] In some embodiments, process 700 includes determining whether the service provider instrument was successfully registered at step / operation 724. If the service provider instrument was successfully registered, process 700 may proceed to step / operation 728. Otherwise, the process may proceed to step / operation 726, where the exchange platform provides a failure response.

[0274] In some embodiments, process 700 includes generating a UUEK in response to successful registration at step / operation 728. For example, the exchange platform may generate a UUEK in response to activation of the user and / or instrument by the exchange network (e.g., using a security code) and / or the service provider platform. By way of example, the exchange platform may generate UUEKs corresponding to the user, the service provider instrument, and the partner platform. The exchange platform may store the UUEK in a partner-specific exchange data object that associates the UUEK with an exchange identifier, an instrument key, and a partner-specific instrument reference, as described herein.

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

[0276] 8A-8B provide a process flow for facilitating secure credential-less information transfer according to one or more embodiments of the present disclosure. The process flow depicts a network process 800 for establishing a network-operated UUEK to securely verify a user's presence for the exchange of value. Process 800, as described herein, can be utilized to overcome various limitations of conventional exchange systems that expose sensitive and persistent credentials to multiple third parties and rely on limited PIN mechanisms that insufficiently secure value-based exchanges. Process 800 can be implemented by one or more computing devices, entities, and / or systems described herein. For example, through the various steps / operations of process 800, an exchange platform can utilize various communication and activation technologies to overcome various limitations associated with conventional mechanisms of exchange by improving the operation of security codes to secure network-based exchanges.

[0277] 8A-8B illustrate an example process 800 for illustrative purposes. Although the example process 800 depicts a particular sequence of steps / actions, the sequence may be varied without departing from the scope of the present disclosure. For example, some of the depicted steps / actions may be performed in parallel or in a different sequence without substantially impacting the functionality of the process 800. In other examples, different components of the example device or system performing the process 800 may perform functions substantially simultaneously or in a particular sequence.

[0278] In some examples, process 800 begins after a registration and / or security code process, such as process 600, in which a user may manage a network-operated security code to facilitate secure, credential-less information transfer. For example, as described herein, one or more registration processes may be performed in advance between one or more member platforms and / or exchange platforms to register multiple service provider instruments with the exchange platform. The exchange platform may then generate and issue a UUEK to the registered service provider platform to initiate value-based exchanges using the registered service provider instrument without reference to the service provider instrument's persistent credentials. Additionally or alternatively, a registration process may be performed to register the registered service provider instrument, maintained by the service provider platform, with the partner platform. In some examples, the exchange platform may facilitate the registration process and, in response to successful registration, generate and issue a UUEK to the partner platform to initiate future value-based exchanges. In some instances, once registered, a user may establish a network-operated security code with the exchange platform to facilitate execution of the UUEK and / or to validate a previously issued UUEK.

[0279] In this manner, using some of the communication techniques of the present disclosure, the member platform can enhance the security of the UUEK by establishing one or more security codes for the user. For example, by replacing the persistent credentials of the service provider instrument with the UUEK, the communication techniques of the present disclosure can manage access to the service provider instrument by issuing a new UUEK and / or validating or invalidating a previously issued UUEK to enforce policies on behalf of the member. In some examples, this includes mandating the use of a security code to verify the user's presence for secure communication. For example, using some of the techniques of the present disclosure, the exchange platform can act as an adjudication engine to verify the user's presence before issuing a UUEK and / or validating a previously issued UUEK on behalf of the member platform. According to the steps / operations of process 800, the exchange platform can enforce the user's security code, service provider instrument, and / or its UUEK, which can be utilized to enforce member policies on behalf of the member platform without ongoing involvement from the member platform. In this way, a network-operated security code can be established that extends the security provided by the UUEK in credential-less exchanges.

[0280] 8A , in some embodiments, process 800 includes receiving a secure information transfer request at step / operation 802. For example, an exchange platform (e.g., its partner service, service provider, etc.) may receive a secure information transfer request from a member platform. As described herein, the secure information transfer request may include a security code entry, a user identifier, and / or an instrument identifier.

[0281] In some embodiments, process 800 includes identifying a security code tuple at step / operation 804. For example, an exchange platform (e.g., its activation service, etc.) may identify a security code tuple corresponding to a user identifier and / or an instrument identifier.

[0282] In some embodiments, process 800 includes, at step / operation 806, determining whether the security code input is valid. For example, the exchange platform (e.g., its validation service, etc.) may validate the security code input based at least in part on a comparison between the security code input and a corresponding security code reference. By way of example, a user identifier and / or instrument identifier may be associated with a security code tuple that includes the security code reference and the corresponding user and / or instrument identifier. The security code tuple may be generated in advance in response to a security code request from a member platform, for example, as described herein with reference to Figures 6A-6C.

[0283] In some embodiments, the security code reference includes an n-character sequence of one or more different characters. The one or more different characters may include one or more alphanumeric characters and / or any other characters. The security code input may include a second n-character sequence of one or more different characters. The security code input may be validated if it matches (e.g., exactly matches, partially matches, etc.) the sequence of characters of the security code reference.

[0284] If the security code input is valid, process 800 may proceed to step / action 808, where a secure event is recorded. If the security code input is invalid (e.g., one or more characters do not match the security code reference), process 800 may proceed to step / action 810, where a non-secure event is recorded.

[0285] In some embodiments, process 800 includes storing the activation event at step / operation 812. For example, the exchange platform (e.g., its activation service) may store data indicating the activation event for a user, an instrument, and / or a security code tuple of the user and / or service provider instrument.

[0286] In some embodiments, a validation event is a data entity that defines the validation of a user's security code input. The validation event may include a secure event, which may indicate validation between the security code input and the security code reference. Additionally or alternatively, the validation event may include a non-secure event, which may indicate a failed validation between the security code input and the security code reference. For example, a secure event may indicate a determination that the security code input matches the corresponding security code reference. In some examples, a non-secure event may indicate a determination that the security code input does not match the corresponding security code reference. In some examples, the exchange platform may generate a secure event in response to a determination that the security code input matches the corresponding security code reference. Additionally or alternatively, the exchange platform may generate a non-secure event in response to a determination that the security code input does not match the corresponding security code reference. In some examples, the secure event may be associated with a secure period, and the exchange platform may generate a non-secure event in response to a determination that the secure period has expired.

[0287] In some embodiments, the activation event is stored in association with a secure data entity, such as a UUEK, a service provider instrument, and / or a user. For example, the activation event may be stored in an exchange data object corresponding to the UUEK, a system instrument data object corresponding to the service provider instrument, a system user data object corresponding to the user, and / or the like. Additionally or alternatively, the activation event may be stored in association with a security code tuple. For example, a secure event may be stored in response to activating a user, while a non-secure event may be stored in response to disabling a user.

[0288] In some embodiments, the activation event includes context activation data. The context activation data may indicate, for example, the timing of the activation. The timing of the activation may include a timestamp corresponding to the transmission, receipt, creation, and / or adjudication of the activation request. For example, the context activation data may include an activation timestamp indicating the time at which the exchange platform determined that the security code input and security code reference match or do not match. In some examples, the context activation data may indicate a secure period. The secure period may indicate a timestamp, a time duration, and / or the like after which the UUEK, service provider instrument, and / or the like may be secured in response to the secure event.

[0289] In some embodiments, if the security code is valid, process 800 includes storing a secure event at step / operation 808. For example, the exchange platform may store a secure event for the user in response to validating the UUEK. In some examples, the exchange platform may generate a secure event in response to determining that the security code input matches a corresponding security code reference. For example, a secure event may be stored in response to validating the security code input.

[0290] In some embodiments, if the security code is invalid, process 800 includes storing an unsecure event at step / operation 810. For example, the exchange platform may store an unsecure event for a user in response to disabling the user. In some examples, the exchange platform may generate an unsecure event in response to determining that a security code input does not match a corresponding security code reference. For example, an unsecure event may be stored in response to disabling a user. In some examples, a secure event may be associated with a secure period, and the exchange platform may generate an unsecure event in response to determining that the secure period has expired.

[0291] In some embodiments, process 800 includes, at step / operation 814, providing a secure signaling response. For example, the exchange platform (e.g., its service provider service, etc.) can provide a secure signaling response indicating the activation event to a member platform (and / or client device) associated with the secure signaling request. In some embodiments, the secure signaling response defines a response to the secure signaling request. In some embodiments, the secure signaling response is provided from the exchange platform to the member that provided the secure signaling request. The secure signaling response may indicate the activation event. In some examples, the secure signaling response may include the UUEK of the user and / or service provider instrument.

[0292] In some examples, the security code input may correspond to a user's previously established UUEK. For example, as described herein, one or more registration processes may be performed in advance between one or more service provider platforms and the exchange platform to register multiple service provider instruments with the exchange platform. The exchange platform may then generate and issue UUEKs to the registered service provider platforms to initiate value-based exchanges using the registered service provider instruments without reference to the service provider instruments' persistent credentials. Additionally or alternatively, a registration process may be performed to register the registered service provider instruments maintained by the service provider platforms with the partner platforms. In some examples, the exchange platform may facilitate a security code registration process for the issued UUEK to generate a security code tuple. Once a security code tuple is generated for the UUEK, the exchange platform may perform one or more steps / operations of process 800 to activate and / or deactivate the UUEK on behalf of the member platforms. In this manner, a network-operated security code may be provided that proactively prevents the use of UUEKs for invalid exchanges.

[0293] In some embodiments, the information transfer request may include an activation request to activate the user's previously issued UUEK. In such cases, the secure information transfer request may indicate the UUEK and a security code entry for the UUEK, and / or one or more context security attributes, such as a provision time (e.g., indicating the time the secure information transfer request was sent), a request time (e.g., the time requested to activate use of the UUEK), and / or the like.

[0294] In some examples, the secure information transfer request may be generated and / or provided in response to a selection input indicating an invalid UUEK. For example, a user may select a UUEK (e.g., through a partner application associated with a partner platform, a service provider application associated with a service provider platform, etc.) to authorize a value-based exchange. In some examples, the secure information transfer request may be automatically initiated if the selected UUEK is an invalid UUEK. For example, in response to the selection, a member platform (e.g., through a respective member application) may prompt the user to enter a security code. The user may enter the security code input to provide the secure information transfer request.

[0295] In some embodiments, the UUEK representation is a viewable representation of the UUEK. The UUEK representation may include a digital representation of the UUEK viewable by a user. The UUEK representation may be represented in one or more different forms, such as, for example, a machine-readable optical image (e.g., a barcode, a quick response code, etc.), a keyword, a virtual widget, and / or the like. In some examples, the UUEK representation may include a scannable representation of the UUEK (e.g., a barcode, a QR code, a non-fungible token, a near-field communication sequence, etc.). The scannable representation may be stored in a member account on the member platform to enable a user to conduct a value-based exchange using a service provider instrument without referencing a persistent credential for the service provider instrument. The UUEK representation may be scanned, for example, by a barcode scanner and / or the like to read the UUEK and initiate a value-based exchange with the UUEK.

[0296] In some embodiments, the invalid UUEK representation is a UUEK representation of an invalid UUEK. The invalid UUEK representation can include a status indicator and / or one or more other indicators that indicate the invalidated status of the UUEK. In some examples, the invalid UUEK representation can include an unreadable UUEK representation. An unreadable UUEK representation can include, for example, a grayed-out, obstructed, partially covered, and / or the like, scannable representation that prevents the scannable representation from being read.

[0297] In some examples, the secure signaling response can initiate validation of the UUEK. The valid UUEK can be associated with a valid UUEK representation, for example. The valid UUEK representation can include a status indicator and / or one or more other indicators that indicate the validated status of the UUEK. In some examples, the valid UUEK representation can include a readable UUEK representation.

[0298] Turning to FIG. 8B , in response to the secure event, process 800 includes, at step / operation 816, receiving an exchange request accompanied by a UUEK (e.g., issued via a secure communication, etc.). For example, an exchange platform may receive an exchange request to conduct a value-based exchange. The exchange request may indicate a UUEK and / or one or more exchange attributes. In some examples, the exchange request may depend on a previous secure communication. For example, a UUEK may be issued via a secure communication and / or validated via a secure communication. In this manner, requests may be filtered before the request is sent to the exchange platform, and again, by the exchange platform before the request is sent to another member platform. In this manner, exchange requests may be minimized to pre-validated exchanges, which may reduce network congestion between multiple parties in a high-traffic exchange network.

[0299] The exchange attributes may indicate one or more characteristics of the requested exchange. For example, the one or more exchange attributes may include at least one exchange attribute indicating an exchange value, such as a monetary value, a reward value, and / or the like.

[0300] In some embodiments, process 800 includes, at step / operation 818, identifying an exchange data object indicating the exchange identifier. For example, an exchange platform (e.g., its partner service, service provider service, etc.) can identify the exchange identifier of the UUEK using some of the techniques described herein. As described herein, the exchange identifier can be associated with an exchange data object corresponding to the UUEK. That exchange data object (and / or one or more identifiers) can be associated with the security code tuple of the UUEK and / or one or more activation events.

[0301] In some embodiments, process 800 includes, at step / operation 820, determining whether activation is required for the exchange request. For example, an exchange platform (e.g., its activation service, etc.) may determine whether activation is required for the exchange request. The exchange platform may determine whether activation is required based at least in part on a member policy and / or one or more exchange attributes of the exchange request. By way of example, a member platform may be associated with a member policy that defines one or more activation requirements for a service provider instrument. In some examples, the exchange request may indicate one or more exchange attributes. The one or more activation requirements may correspond to the one or more exchange attributes. The exchange platform (e.g., its activation service, etc.) may compare the one or more exchange attributes to the one or more activation requirements to determine whether activation is required for the UUEK of the exchange request.

[0302] As one example, one or more exchange attributes may indicate an exchange value, and one or more activation requirements may define an exchange value threshold above which a respective secure event is required for the service provider instrument. In such a case, activation may be required for an exchange request if the exchange value of the exchange request meets the exchange value threshold.

[0303] As another example, the one or more activation requirements may define one or more objects (e.g., object identifiers, object attributes, etc.) for which respective secure events are required for the service provider instrument. In such a case, activation may be required for an exchange request if the exchange request includes one or more exchange attributes that identify at least one of the one or more objects.

[0304] In some embodiments, process 800 includes determining whether the UUEK is to be validated at step / operation 822. For example, the exchange platform (e.g., its partner service, service provider service, etc.) may determine that the UUEK is to be validated (or invalidated) based at least in part on a member policy, an exchange request, and / or one or more validation events (e.g., a secure event, a non-secure event, etc.) associated with the UUEK. By way of example, the exchange platform may determine whether the UUEK is to be validated based at least in part on the presence of a secure event, a non-secure event, and / or one or more timing attributes thereof.

[0305] In some embodiments, the exchange platform determines that the UUEK is valid based at least in part on a most recent time attribute of multiple validation events. For example, the UUEK may be valid if a secure event follows any non-secure event. Additionally or alternatively, the exchange platform determines that the UUEK is valid based at least in part on a comparison between a secure period and a time (e.g., receipt time, response time, processing time, etc.) for the exchange request. For example, the UUEK may be valid if a time, such as the receipt time of the exchange request, is within a valid period.

[0306] In some embodiments, process 800 includes, at step / operation 824, providing an exchange authorization request. For example, an exchange platform (e.g., its service provider service) can provide the exchange authorization request to a member platform. In some examples, the exchange authorization request can be provided to the service provider platform using a service provider interface. The exchange authorization request can indicate an instrument identifier and / or a secure event. In some examples, the exchange authorization request can indicate an enabled time period for the secure event and / or a time of receipt of the exchange request.

[0307] For example, an exchange platform (e.g., its service provider service) can request exchange authorization from the service provider platform for a service provider instrument correlated to the UUEK. In some examples, the exchange platform (e.g., its partner service) can identify a member platform based at least in part on the UUEK (e.g., its entity partition). Additionally or alternatively, the exchange platform (e.g., its service provider service) can identify a service provider instrument based at least in part on the UUEK (e.g., an exchange identifier).

[0308] The exchange platform (e.g., its service provider service) can provide an exchange authorization request to a member platform using a service provider interface. The exchange authorization request may indicate at least one of one or more request attributes, an instrument identifier of a service provider instrument, and / or a secure event. By way of example, the exchange platform can generate the exchange authorization request based at least in part on a system instrument data object identified from one or more aspects of the UUEK. The exchange authorization request can include an instrument key and / or an instrument reference from the system instrument data object.

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

[0310] Additionally or alternatively, the exchange authorization request may indicate an exchange identifier. By way of example, the exchange platform may generate an exchange identifier to represent the value-based exchange and provide the exchange identifier to the member platform.

[0311] In some embodiments, process 800 includes receiving an exchange authorization response at step / operation 826. For example, an exchange platform (e.g., its partner service, service provider service, etc.) may receive the exchange authorization response indicating at least one of exchange approval and / or exchange denial. In some examples, the exchange authorization response may be received from the service provider platform using a service provider interface.

[0312] In some embodiments, the replacement authorization response is based at least in part on the secure event. For example, the replacement authorization response can be based at least in part on the secure event, the time of receipt of the replacement request, member policy, and / or the like.

[0313] In some embodiments, the exchange platform (e.g., its service provider service) can receive, using the service provider interface, an exchange authorization response indicating at least one of transaction approval and / or transaction denial. In some embodiments, the exchange authorization response is based at least in part on a comparison between the value of the transaction and asset availability of the service provider instrument. For example, in response to receiving an exchange authorization request, the member platform can be configured to compare the value of the transaction with asset availability of the identified service provider instrument. A value-based exchange may be authorized (e.g., resulting in transaction approval) if asset availability exceeds the value of the transaction; otherwise, the exchange may be denied (e.g., resulting in transaction denial).

[0314] In some examples, the replacement authority response may indicate one or more response attributes, which may include one or more error codes and / or the like, for characterizing the replacement authority response.

[0315] The exchange platform may generate an exchange record for the value-based exchange based at least in part on the exchange authority request and / or the exchange authority response. In some examples, the exchange record may indicate an exchange identifier, one or more exchange attributes, one or more response attributes, the exchange authority response, one or more instruments and / or user identifiers, and / or any other data related to the value-based exchange. In some examples, the exchange platform may store the exchange record in a platform data vault in association with the one or more instruments and / or user identifiers.

[0316] In some embodiments, process 800 includes, at step / operation 828, providing an exchange response. For example, the exchange platform (e.g., its partner service, service provider service, etc.) may provide the exchange response based at least in part on the exchange authorization response. In some examples, the exchange platform may provide the exchange response to the partner platform using a partner interface. The exchange response may indicate exchange approval or exchange denial.

[0317] The exchange response can be based at least in part on the exchange authorization response. For example, the exchange response may indicate transaction approval and / or transaction denial. In some examples, the exchange response may indicate the replacement UUEK (if generated), one or more exchange attributes, an exchange identifier, and / or one or more response attributes. In some examples, the member platform can be configured to replace the UUEK with the replacement UUEK. For example, the exchange response can be provided to a partner platform. The partner platform can receive the exchange response and replace the UUEK with the replacement UUEK. Thus, having described various operations, processes, methods, functions, and / or the like for handling exchanges on behalf of a user, various user interface screens are provided and described for controlling, initiating, executing, and / or the like such steps / operations. In various embodiments, the user interface screens provided and described in this disclosure are configured to be provided via a user interface of a client device 104.

[0318] 9A-9D provide exemplary user interface flows configured for a client device 104. The user interface may be configured to guide a user through a credential-less exchange process to facilitate a value-based exchange between one or more member platforms without disclosing the confidential and persistent credentials of the service provider instruments used to execute the value-based exchange. The credential-less exchange process may begin when a user selects a payment method from a partner application's exchange processing screen 902, as shown by FIG. 9A. Upon selection of a payment method facilitated by the exchange platform, the user may be transitioned to an instrument selection screen 904, as shown by FIG. 9B. The instrument selection screen 904 may include multiple selectable instrument icons 906, each of which may be associated with a UUEK issued by the exchange platform using various techniques described herein. The user may execute the exchange by selecting one or more of the selectable instrument icons 906.

[0319] In some examples, in response to a selection, a scan screen 908 may be provided for in-store exchange. The scan screen 908 may present a valid and / or invalid UUEK representation 910 corresponding to the UUEK. The user may scan the UUEK representation 910 to complete the value-based exchange. If the UUEK is an invalid UUEK, the user may be transitioned to a verify user screen 912 to provide a security code associated with the UUEK. The user may enter the security code to validate the UUEK and complete the exchange.

[0320] VI. Conclusion Many modifications and other embodiments will come to mind to one skilled in the art to which this disclosure pertains having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the disclosure is not limited to the particular embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. receiving, by one or more processors, a secure communication request indicating a security code entry and a user identifier; identifying, by the one or more processors, a security code tuple for the security code entry based on the user identifier; validating, by the one or more processors, the security code input based at least in part on a comparison between the security code input and a security code reference in the security code tuple; In response to the step of enabling security code entry, (i) storing, by the one or more processors, secure events for the user; and (ii) providing, by the one or more processors, a secure signaling response indicative of the secure event, the secure signaling response indicating at least one of: (a) a universally unique ephemeral key (UUEK); or (b) a secure event for the UUEK; receiving, by the one or more processors, an exchange request to conduct a value-based exchange using the UUEK; providing, by the one or more processors, an exchange authority request to the member platform, the exchange authority request indicating the instrument identifier and the secure event; receiving, by the one or more processors, an exchange authorization response indicating at least one of exchange approval or exchange denial, the exchange authorization response being based at least in part on the secure event; 20. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the secure information transfer request is received in response to a selection input to an invalid UUEK representation corresponding to the UUEK using a partner interface corresponding to a partner platform.

3. (i) the invalid UUEK representation is presented for display through a user interface; (ii) in response to the secure signaling response, the exchange interface is modified to present a valid UUEK representation; The computer-implemented method of claim 2.

4. (i) the member platform is a service provider platform; (ii) the interchange request is received from a partner platform different from the service provider platform using a partner interface; (iii) the interchange authorization request is provided to the service provider platform using a service provider interface; and (iv) the interchange authorization response is received from the service provider platform using the service provider interface; and the computer-implemented method comprises: using the partner interface to provide an exchange response based at least in part on the exchange authorization response, the exchange response indicating the exchange approval or the exchange denial; The computer-implemented method of claim 1 further comprising:

5. 2. The computer-implemented method of claim 1, wherein the security code reference comprises an n-character sequence of one or more different characters.

6. The computer-implemented method of claim 5 , wherein the one or more different characters comprise one or more alphanumeric characters.

7. 2. The computer-implemented method of claim 1, wherein the security code tuple comprises the security code reference and a user identifier and is previously generated in response to a security code request from the member platform.

8. 2. The computer-implemented method of claim 1, wherein the secure event is associated with a secure period, and the exchange authorization response is based at least in part on the secure event and a time of receipt of the exchange request.

9. The member platform is associated with a member policy that defines one or more activation requirements for the service provider instrument, and the computer-implemented method includes: determining that the UUEK is valid based at least in part on the member policy, the exchange request, and the secure event; The computer-implemented method of claim 1 , comprising:

10. 10. The computer-implemented method of claim 9, wherein the exchange request indicates one or more exchange attributes, and the one or more enabling requirements correspond to the one or more exchange attributes.

11. 11. The computer-implemented method of claim 10, wherein the one or more exchange attributes indicate an exchange value, and the one or more enablement requirements define an exchange value threshold at which a respective secure event is required for the service provider instrument.

12. 1. A computing system comprising: a memory; and one or more processors communicatively coupled to the memory, the one or more processors: receiving a secure communication request indicating a security code entry and a user identifier; identifying a security code tuple for the security code entry based on the user identifier; validating the security code input based at least in part on a comparison between the security code input and a security code reference of the security code tuple; In response to enabling the security code entry, (i) storing secure events for said user; and (ii) providing a secure signaling response indicative of the secure event, the secure signaling response indicating at least one of: (a) a universally unique ephemeral key (UUEK); or (b) a secure event for the UUEK; receiving an exchange request to perform a value-based exchange using the UUEK; providing an exchange authorization request to the member platform, the exchange authorization request indicating the instrument identifier and the secure event; receiving an exchange authorization response indicating at least one of exchange approval or exchange denial, the exchange authorization response based at least in part on the secure event; and 1. A computing system configured to:

13. 13. The computing system of claim 12, wherein the secure information transfer request is received in response to a selection input to an invalid UUEK representation corresponding to the UUEK using a partner interface corresponding to a partner platform.

14. (i) the invalid UUEK representation is presented for display through a user interface; (ii) in response to the secure signaling response, the exchange interface is modified to present a valid UUEK representation; 13. The computing system of claim 12.

15. (i) the member platform is a service provider platform; (ii) the interchange request is received from a partner platform different from the service provider platform using a partner interface; (iii) the interchange authorization request is provided to the service provider platform using a service provider interface; and (iv) the interchange authorization response is received from the service provider platform using the service provider interface; and the computer-implemented method comprises: using the partner interface to provide an exchange response based at least in part on the exchange authorization response, the exchange response indicating the exchange approval or the exchange denial. The computing system of claim 12 further comprising:

16. 13. The computing system of claim 12, wherein the secure event is associated with a secure period, and the exchange authorization response is based at least in part on the secure event and a time of receipt of the exchange request.

17. When executed by one or more processors, receiving a secure communication request indicating a security code entry and a user identifier; identifying a security code tuple for the security code entry based on the user identifier; validating the security code input based at least in part on a comparison between the security code input and a security code reference of the security code tuple; In response to enabling the security code entry, (i) storing secure events for said user; and (ii) providing a secure signaling response indicative of the secure event, the secure signaling response indicating at least one of: (a) a universally unique ephemeral key (UUEK); or (b) a secure event for the UUEK; receiving an exchange request to perform a value-based exchange using the UUEK; providing an exchange authorization request to the member platform, the exchange authorization request indicating the instrument identifier and the secure event; receiving an exchange authorization response indicating at least one of exchange approval or exchange denial, the exchange authorization response based at least in part on the secure event; and one or more non-transitory computer-readable storage media comprising instructions that cause the one or more processors to:

18. 20. The one or more non-transitory computer-readable storage media of claim 17, wherein the security code reference comprises an n-character sequence of one or more different characters, the one or more different characters comprising one or more alphanumeric characters.

Images