Computer execution method, computing system, and computer-readable storage medium

The secure intermediary computing platform using UUEK addresses the vulnerabilities of persistent credentials in network exchanges by facilitating credential-free transactions with flexible and secure interfaces, enhancing security and efficiency.

JP7869342B2Active Publication Date: 2026-06-021080 NETWORK INC

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
1080 NETWORK INC
Filing Date
2023-08-03
Publication Date
2026-06-02

AI Technical Summary

Technical Problem

Existing network-based exchange technologies rely on persistent credentials, which expose users to fraud, regulatory risks, and increased transaction costs due to their static nature and lack of security, leading to inefficiencies and vulnerabilities.

Method used

A secure intermediary computing platform utilizing Universally Unique Ephemeral Keys (UUEK) facilitates credential-free exchanges by eliminating persistent credentials, enabling flexible and secure interfaces for value-based transactions through APIs, allowing for dynamic and complex security codes.

Benefits of technology

This approach enhances security and reduces computing resource requirements while increasing network throughput by eliminating persistent credentials, enabling secure, real-time, and flexible value-based exchanges without exposing sensitive information.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007869342000001
    Figure 0007869342000001
  • Figure 0007869342000002
    Figure 0007869342000002
  • Figure 0007869342000003
    Figure 0007869342000003
Patent Text Reader

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.
Need to check novelty before this filing date? Find Prior Art

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 Aug. 3, 2022, and U.S. Patent Application No. 18 / 363,796, filed Aug. 2, 2023, both of which are hereby incorporated by reference in their entirety, including any figures, tables, drawings, and appendices.

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

Background Art

[0003] Various embodiments of the present disclosure address technical challenges related to network - based exchange that take into account the limitations of existing exchange processing technologies and architectures. Existing processes for performing exchanges over computing networks rely on the use of persistent credentials such as payment credentials (e.g., card numbers, usernames, passwords, bank branch codes, account numbers, etc.) and their authorizations, which expose the recipient of the credentials to fraud, regulatory and compliance costs, and reputation risks. Moreover, due to the static nature of traditional credentials, users must accept the risk of financial loss, damaged credit scores, identity theft, and other consequences each time they provide their credentials to enable an exchange. The inherent lack of security of persistent credentials has conventionally been addressed using strict communication protocols, data governance procedures, and authentication schemes, each of which adds costs and complicates network - based transactions without solving the fundamental technical problems regarding data security, resulting in additional technical challenges.

[0004] One technique involves the use of a provider-managed personal identification number (PIN) and / or other security code, which may be set by the user or provider and then used to verify the exchange using a specific account. These codes may be encoded within a physical medium and automatically authenticated each time the physical medium is used to authorize an exchange. Alternatively, the code may provide an exchange request to the provider requesting authorization for each individual exchange.

[0005] Traditional code lacks flexibility and is insecure in several ways. Firstly, traditional code is deployed as a four-digit number and can be brute-forced based on a limited number of possible combinations, thus presenting an attack vector to a malicious party. Furthermore, to function effectively, traditional code must be provided simultaneously with the exchange request. This leads to increased network traffic and higher exchange costs, even when the exchange is declined. Additionally, such code traditionally applies to all exchanges, is not configurable for specific characteristics of the request (e.g., exchange value, time, etc.), is difficult to modify, and increases the responsibility of the user (e.g., if the code is encoded on a physical medium) or provider. These and other technical challenges limit the effectiveness of traditional security code and further present security challenges for implementing network-based exchanges.

[0006] The various embodiments of this disclosure make significant contributions to various existing network-based value exchange processing technologies by addressing each of these technical challenges. [Overview of the Initiative] [Means for solving the problem]

[0007] Various embodiments of this disclosure disclose a secure intermediary computing platform and computing services that facilitate credential-free execution of value-based exchanges by leveraging a Universally Unique Ephemeral Key (UUEK) to eliminate the use of persistent credentials. To do so, the intermediary computing platform can facilitate interaction between one or more member platforms for registering users and / or user instruments in a value exchange system enhanced by a new temporary data structure known herein as UUEK. Unlike conventional exchange systems, the intermediary computing platform does not receive or rely on persistent user or instrument credentials for registering users and / or user instruments. This elimination of credentials enables the use of new and more flexible interfaces, such as application programming interfaces (APIs) described herein, which are leveraged by the intermediary computing platform to communicate with different network members to register users, user instruments, instrument policies, and different security codes without exposing user credentials at any step in the process. Upon registration, the intermediary computing platform can issue a UUEK to the member platform, which can replace traditional persistent credentials. The issued UUEK does not reflect persistent credentials or any other highly 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 persistent credentials), 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 to authorize value-based exchange. In this way, network-based transactions can be authorized in a seamless process without disclosing highly sensitive user or instrument information that could be vulnerable to network attacks.

[0008] Some of the technologies in this disclosure further enhance the security of network-based exchanges by leveraging flexible interfaces, such as APIs, between entities in value-based exchanges to establish a security code for the UUEK. The security code can be used to enable and disable the use of the UUEK to authorize exchanges. Thus, the execution of value-based exchanges can be determined at least in part on the arbitration of the UUEK's security code. Importantly, the security code enables a network-operated, n-character code whose complexity can vary. As described herein, this allows the intermediary platform to enforce instrument-specific security measures without the risk of disclosing sensitive user or financial information before exchange authority is always provided to service providers such as financial institutions. Finally, the technologies in this disclosure 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) while reducing computing power requirements and enabling significantly greater network throughput for exchange processing compared to prior art.

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

[0010] In some embodiments, the computing system comprises memory and one or more processors communicatively coupled to the memory, wherein one or more processors receive a secure information transmission request indicating a security code input and a user identifier; identify a security code tuple for the security code input based on the user identifier; enable the security code input based at least in part on a comparison between the security code input and the security code reference of the security code tuple; and in response to enabling the security code input, (i) store a secure event for the user, and (ii) provide a secure information transmission response indicating the secure event, wherein the secure information transmission response is (a) a universally unique ephemeral key (b) providing an instrument identifier and a secure event, and receiving an exchange request to perform a value-based exchange using the UUEK, and providing an exchange authorization request to a member platform, wherein the exchange authorization request provides an instrument identifier and a secure event, and receives an exchange authorization response indicating at least one of an exchange approval or exchange rejection, wherein the exchange authorization response is at least partially based on the secure event.

[0011] In some embodiments, one or more non-ephemeral computer-readable storage media, when executed by one or more processors, receive a secure information transmission request indicating a security code input and a user identifier; identify a security code tuple for the security code input based on the user identifier; enable the security code input based at least in part on a comparison between the security code input and the security code reference of the security code tuple; and in response to enabling the security code input, (i) store a secure event for the user, and (ii) provide a secure information transmission response indicating the secure event, wherein the secure information transmission response is (a) a universally unique ephemeral key The instruction includes causing one or more processors to: provide, indicate, or (b) at least one of the following: key (UUEK), or secure event for UUEK; receive an exchange request to perform a value-based exchange using UUEK; and provide an exchange authorization request to a member platform, wherein the exchange authorization request provides, indicate, an instrument identifier and secure event, and receive an exchange authorization response indicating at least one of exchange approval or exchange rejection, wherein the exchange authorization response is at least partially based on the secure event.

[0012] Having explained this disclosure in general terms, I will now refer to the attached drawings, but these drawings are not necessarily drawn to scale. [Brief explanation of the drawing]

[0013] [Figure 1] This is an illustrative diagram of a computing ecosystem according to one or more embodiments of the present disclosure. [Figure 2] This is an illustrative schematic diagram of a computing platform according to one or more embodiments of the present disclosure. [Figure 3] This is an illustrative schematic diagram of a client device according to one or more embodiments of the present disclosure. [Figure 4] This is an exemplary block diagram of an exemplary value credential-free exchange system according to one or more embodiments of the present disclosure. [Figure 5] This is an exemplary data diagram illustrating how to facilitate value credential-free exchange according to one or more embodiments of the present disclosure. [Figure 6] This is a process flow for facilitating network-operated security code for users, according to one or more embodiments of the present disclosure. [Figure 7A] This is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 7B] This is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 7C] This is a process flow for establishing a secure cross-entity relationship according to one or more embodiments of the present disclosure. [Figure 8A] This is a process flow for facilitating secure, credential-free information transmission according to one or more embodiments of the present disclosure. [Figure 8B] This is a process flow for facilitating secure, credential-free information transmission according to one or more embodiments of the present disclosure. [Figure 9A] This is a diagram illustrating an exemplary interface for facilitating value credential-free exchange, according to one or more embodiments of the present disclosure. [Figure 9B] This is a diagram illustrating an exemplary interface for facilitating value credential-free exchange, according to one or more embodiments of the present disclosure. [Figure 9C]This is a diagram illustrating an exemplary interface for facilitating value credential-free exchange, according to one or more embodiments of the present disclosure. [Figure 9D] This is a diagram illustrating an exemplary interface for facilitating value credential-free exchange, according to one or more embodiments of the present disclosure. [Modes for carrying out the invention]

[0014] Various embodiments of this disclosure are described in more detail below with reference to the accompanying drawings, which illustrate some, but not all, embodiments of this disclosure. In practice, this disclosure may be embodied in many different forms and should not be construed as an limitation to the embodiments described herein, but rather these embodiments are provided so as to satisfy the applicable legal requirements of this disclosure. The term “or” is used herein in both an alternative and conjunctive sense unless otherwise indicated. The terms “exemplary” and “example” are used herein as examples without indication of a quality level. Terms such as “computing,” “determining,” “generating,” and / or similar words are used herein without distinction to refer to the creation, modification, or identification of data. Furthermore, “at least in part on,” “based on,” and / or similar words are used herein without distinction in a broadly interpretable manner, unless otherwise indicated, so as not necessarily to indicate that it is at least in part on or based on only one or more of the elements referenced. Similar numbers refer to similar 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 can be configured to facilitate a value-based exchange between one or more member platforms without the need for value credentials. These exchanges can be facilitated in real time without persistent credentials that may expose members to financial, legal, reputational, or other risks. Thus, in various embodiments, a client device can purchase, sell, and / or execute value-based exchanges in real time over any network without exposing sensitive information that is vulnerable to network-based attacks.

[0016] Embodiments of the present disclosure provide improved instrumentation-level enabling and enabling technologies 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 through network communications.

[0017] Some of the techniques of this disclosure, for example, retrieve data objects and convert the data objects into unique data keys that can be recognized only by authorized entities. The data keys can be provided and / or established by leveraging an exchange interface between an exchange platform and other member platforms in an exchange network. Once established, the data keys can be mapped to confidential credentials stored within a source platform (e.g., a service provider platform) without requiring network transmission of the confidential credentials. Future communications to facilitate value-based exchanges can replace conventional persistent credentials with data keys in order to enable the source platform to identify persistent credentials and / or perform one or more actions for specific instruments associated with the persistent credentials. In this way, the exchange platform can itself facilitate exchanges using keys (and / or other identifiers) that cannot trace back to underlying confidential information. This further enables the exchange platform to track, facilitate, and distribute network-based communications in their entirety without exposing members to network attacks.

[0018] Some embodiments of this disclosure present network-based exchange processing technology for facilitating credential-free exchanges. To do so, some of the technologies in this disclosure leverage a novel data structure called UUEK, which can replace persistent credentials traditionally used to authorize value-based exchanges. Using the technologies in this disclosure, UUEK can be securely issued across member platforms to enable users to perform value-based exchanges using identifiers recognizable by a single-party exchange platform. 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 is interpretable only by the source platform, and therefore the identifier is unusable by a malicious party not associated with the exchange platform. In this way, the exchange platform can distribute, track, and facilitate exchanges without exposing member platforms to data security risks. Furthermore, the exchange platform can continuously update, modify, and / or redistribute UUEK to member platforms in order to continuously adapt UUEK in real time. Thus, exchange platforms can provide technical improvements to data and network security while reducing computing resource requirements (for example, for securely encrypting persistent credentials) to facilitate value-based exchange.

[0019] Some of the technologies in this disclosure can leverage the credential-free exchange described herein to enable the use of flexible exchange interfaces between members of an exchange network. Unlike conventional exchange interfaces, credential-free exchange enables the use of an interface capable of facilitating complex, network-operated n-character security codes tailored to the UUEK. In this way, the intermediary computing platform can receive the information necessary to establish the UUEK-patterned security code. The security code can be used to activate the UUEK before the exchange is initiated. Thus, the exchange is proactively filtered, at least in part, based on the authenticity of the temporary data structure. This further restricts network traffic to those exchanges that are most likely to be authorized, improving network performance in a robust network-based exchange ecosystem. Moreover, the network operation of the security code can increase the feasible complexity of the actual code, for example, by enabling 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 the traditional four-character alphanumeric code with 1,679,616 combinations.

[0020] Illustrative and technically advantageous embodiments of the inventions of this disclosure include (i) data transformation, mapping, and processing schemes for facilitating network-based credential-free exchange; (ii) exchange interfaces and network-based communication schemes for improving network security for cross-platform communications; (iii) temporary data structures and data management techniques for distributing temporary data structures for facilitating real-time, secure, and dynamic value-based exchange; and (iv) UUEK enabling techniques for enabling and / or disabling UUEK for exchange.

[0021] II. Exemplary Definitions In some embodiments, the term “exchange platform” refers to a computing entity configured to facilitate credential-free 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 similar, physically and / or wirelessly coupled and configured to perform one or more computing tasks collectively (and / or individually) to facilitate value system-independent exchanges. In some examples, the exchange platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication (e.g., requests and responses) between multiple members. As described herein, APIs may be utilized to facilitate secure exchanges 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. For 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 called 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, and thus the member utilizes the exchange platform to provide value in a value exchange of only one member, and then to receive value.

[0023] In some embodiments, a member is a partner when using services provided by a service provider. A partner can include any value-seeking entity in any value system. For example, in a financial value system, a partner can include a merchant (e.g., a retailer, a storefront, etc.) who may use a service provider, such as a financial institution, to access funds for financial transactions. Additionally or alternatively, in an information value system, a partner can include a news publisher (e.g., a newspaper, a press organization, etc.) who may use a service provider, such as a news agency (e.g., a wire service, a news service, etc.), to access information for information transactions. Naturally, the technology of this disclosure may be applied to any value system, and a partner can include any value-seeking entity for any respective value system.

[0024] In some embodiments, a Member is a Service Provider when providing services to a Partner. A Service Provider can include a source of value in any value system. For example, in a financial value system, a Service Provider can include a financial institution (e.g., a bank, a foreign exchange platform, a credit union, etc.) that can provide access to funds for financial transactions between one or more entities. Additionally or alternatively, in an information value system, a Service Provider can include a news agency (e.g., a wire service, a news service, etc.) from which news publishers can source information for publication. Naturally, the technology 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.

[0025] In some embodiments, the term “service provider instrument” refers to a mechanism utilized by a service provider to deliver 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 the service provider’s accounts. For example, in a financial value system, a service provider instrument may include bank accounts (e.g., checking accounts, savings accounts, etc.), securities accounts, credit limits, and / or similar. In an information value system, a service provider instrument may include subscriber accounts and / or similar. In some examples, a service provider instrument may include virtual instruments hosted by the service provider platform.

[0026] In some embodiments, the services provided by the service provider are subject to one or more policies and / or security codes. For example, the service provider and / or service provider instrument may be associated with a security code for verifying the use of the service provider instrument. Additionally or alternatively, the 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 information transfer, such as physical exchange, virtual exchange, enrollment, and / or similar. A security code may include a sequence of one or more distinct characters of dynamic length (e.g., 6 characters, 8 characters, etc.) that can be pre-set by the user and / or provided to the user. A security code may be provided later by the user to validate the user’s presence for information transfer (e.g., by comparing a security code input with a security code reference, as described herein). The one or more distinct characters may include any number of alphanumeric characters, emojis, kanji, wingdings, and / or similar.

[0028] In some embodiments, the security code is a network-operated n-character PIN. As described herein, the security code may be managed as a service through a client device for (i) securely retrieving a UUEK, (ii) registering an instrument with the member platform, and / or (iii) enabling or disabling the use of a UUEK (and / or any other exchange credentials) before an exchange request. Thus, the security code may be deployed for any type of service provider instrument through the retrieval, registration, and / or activation or deactivation of the corresponding UUEK. By managing the security code at the network level, the likelihood of authorization denial due to an invalid PIN is eliminated, so members can benefit from faster exchanges. For example, a UUEK may be disabled until a security code is received to activate it. The exchange platform can 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 the security code in mind. This effectively reduces network traffic between members in a switching network, thereby reducing network congestion in conventional high-traffic communication systems.

[0029] In some embodiments, the security code corresponds to a user. For example, the security code may be pre-set by the user and / or provided to the user through communication with the exchange platform. For 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 direct communication with each member platform or sharing the security code with each member platform. In some examples, the security code may be instrument-specific or member-specific. For example, each security code may be configured to retrieve and / or enable the UUEK of a particular member platform and / or the service provider instrument of a particular member platform. As an addition or alternative, each security code may be configured to register the member platform's account with the exchange network. For example, an exchange platform can control the use of security code to perform one or more secure actions by using multiple security code tuples, each correlating security code to a specific 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 member platforms and / or service provider instruments. A security code tuple may include data objects, records, and / or any other data structure (e.g., linked nodes) configured to represent an association between a security code, 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 context pairing data. Context pairing data may include one or more pairing attributes, such as one or more timing attributes. Timing attributes may include, for example, configuration time (e.g., indicating the time the security code tuple was set), expiration time (e.g., the time the security code must be reset), and / or similar. As described herein, security code tuples can be leveraged by an exchange platform to identify a user's security code reference and, at least in part, perform secure actions on behalf of the user (e.g., enabling the use of UUEK for exchange) based on a comparison between the security code reference and the 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. A security code reference may include an internal representation of a user’s security code (for example, for an exchange platform).

[0032] In some embodiments, the term “security code input” refers to a data entity that defines a sequence of characters provided to perform a secure action. A security code input may include user input provided by the user, as described herein. In some examples, a secure action may be performed for the user if the security code input matches a security code reference. For example, each UUEK assigned to a user may be activated if the security code input matches a user security code reference (such as one defined by a security code tuple).

[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 from a member of the exchange network to the exchange platform. A security code request may refer to a user’s member user reference and, in some examples, a user’s member instrument reference. For example, a security code request containing only a member user reference may be the default for all service provider instruments associated with the user, and can initiate set, reset, and / or remove operations for security codes that apply to all service provider instruments maintained by their respective member platforms for the user. Additionally or alternatively, a security code request containing both member user references and member instrument references can initiate set, reset, and / or remove operations for security codes that apply to specific service provider instruments maintained by their respective member platforms for the user. In addition to references, a 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 transmission request” refers to a data entity that defines a request for secure information transmission using a security code input. A secure information transmission request may be provided from a member of an exchange network to an exchange platform. A secure information transmission request may indicate (i) a user, member platform, and / or a service provider instrument, and (ii) a user’s security code input. Additionally or alternatively, a secure information transmission request may indicate one or more context security attributes. One or more context security attributes may include one or more timing attributes. One or more timing attributes may indicate, for example, a delivery time (e.g., an indication of the time the secure information transmission request is sent), a request time (e.g., an indication of the time requested to perform secure information transmission), and / or similar.

[0035] Secure information transmission requests can be received from member platforms. For example, a user can initiate a secure information transmission request through a member application hosted by a member platform on behalf of a member of the exchange network. In some examples, a secure information transmission request may be generated and / or provided in response to a selection input indicating a service provider instrument, the service provider instrument's UUEK, and / or similar. As one example, a user can select an instrument representation, a UUEK representation, and / or similar (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, a secure information transmission request may be initiated automatically when the user and / or the selected instrument, UUEK, and / or similar are associated with a security code. For example, in response to a selection, a member platform may prompt the user for security code input (e.g., through its respective member application). The user can then enter the security code input to provide a secure information transmission request.

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

[0037] In some embodiments, enablement events are stored in association with secure data entities such as UUEKs, service provider instruments, and / or users. For example, enablement events may be stored in exchange data objects corresponding to UUEKs, system instrument data objects corresponding to service provider instruments, system user data objects corresponding to users, and / or similar. Additionally or alternatively, enablement events may be stored in association with security code tuples. For example, secure events may be stored in response to enabling a user, while insecure events may be stored in response to disabling a user.

[0038] In some embodiments, the activation event includes contextual activation data. Contextual activation data may, for example, indicate the timing of activation. The timing of activation may include timestamps corresponding to the sending, receiving, creation, and / or ruling of the activation request. For example, contextual activation data may include an activation timestamp indicating the time when the exchange platform determined whether a security code entry and security code reference matched or not. In some examples, contextual activation data may indicate a secure period. The secure period may indicate a subsequent timestamp, time duration, and / or similar, during which the UUEK, service provider instrument, and / or similar can be secured in response to a secure event.

[0039] In some embodiments, the term “secure information transmission response” refers to a data entity that defines a response to a secure information transmission request. In some embodiments, the secure information transmission response is provided by the exchange platform to the member that provided the secure information transmission request. The secure information transmission response may indicate an activation 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 a member’s service provider instrument. For example, a member policy may define one or more enablement requirements for using a service provider instrument, at least partially based 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, at least partially based on one or more instrument-specific standards. Member-specific standards may apply to multiple service provider instruments associated with a member, while instrument-specific standards may apply to at least one of multiple service provider instruments associated with a member.

[0041] The activation requirements may indicate one or more attributes of a value-based exchange that require secure information transfer. For example, a pre-issued UUEK may be used without security code to authorize a value-based exchange that does not contain one or more attributes that require secure information transfer. If a value-based exchange contains at least one attribute that requires secure information transfer, the UUEK may be prevented from authorizing the value-based exchange unless 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 an object. For example, a member policy may include multiple object identifiers. Multiple object identifiers may indicate multiple objects that are authorized / unauthorized to acquire (e.g., purchase) without a security code.

[0043] In some examples, the object identifier may also be a global object identifier. For example, the global object identifier may be a minimum stock unit (SKU) code. Additionally or alternatively, the global object identifier may be a manufacturer part number (MPN), global trade item number (GTIN), product or service name, international standard book number (ISBN), unified product code (UPC), international product number (EIN), and / or similar. In some examples, the object identifier may include a system object identifier. The system object identifier may include, for example, an identifier corresponding to a recorded data object that represents an object within the exchange platform (e.g., a table identifier). In some embodiments, the system object identifier and the global object identifier are the same.

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

[0045] In some embodiments, the term “recorded data object” refers to a data object representing an object that may be involved in a value-based exchange. In some examples, a recorded data object may also be an internal representation of an object for an exchange platform. For example, an object may include different units of a value-based exchange in which value is being transferred. A recorded data object of 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 partially on a value system. For example, in a financial value system, an object may be a tangible or intangible item, product, and / or similar that can be purchased in exchange for a unit of currency. In a healthcare value system, an object may be a healthcare procedure and / or similar that can be covered by a healthcare policy.

[0047] In some examples, the exchange platform may maintain and / or access an object datastore containing multiple recorded data objects. As described herein, the object datastore may contain multiple recorded data objects obtained at least partially from one or more members of the exchange network.

[0048] In some embodiments, the term “object attribute” refers to a data entity that represents the characteristics 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 express object characteristics. Spatial attributes may indicate, for example, one or more dimensions of an object (e.g., height, width, weight); value attributes may indicate the value of an object (e.g., price); composition attributes may indicate one or more components, constituents, etc. of an object; category attributes may indicate one or more categories of an object (e.g., restricted substances); and / or similar. For example, one or more category attributes may indicate whether an object is associated with (i) one or more general merchandise categories such as vegetables, fruits, dairy products, meat, grains, seeds, alcohol, tobacco, store consumables, hot food, pharmacies, pet food, and non-food items; (ii) one or more medical categories such as dental, ophthalmology, and general health; or (iii) one or more information categories such as international sources and domestic sources, and / or similar. In some examples, compositional attributes may indicate one or more components of an object, such as the volume percentage of alcohol in the object, one or more ingredients, such as meat, dairy, peanuts, nuts, soy, and / or similar.

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

[0051] In some embodiments, the term “exchange request” refers to a data entity that defines a request to perform an exchange of value. An exchange request may be submitted to an exchange platform by a member of an exchange network. An exchange request may include one or more request attributes. One or more request attributes may include one or more object identifiers, object attributes, and / or similar.

[0052] For example, one or more request attributes may include multiple object identifiers corresponding to multiple objects associated with a value-based exchange. Additionally or alternatively, one or more request attributes may include one or more object attributes of multiple objects. For example, 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 the quantity of an object, the location of an object, and / or similar. For example, an exchange request may indicate the exchange location where the object is being retrieved.

[0053] In some embodiments, the term “exchange authorization request” refers to a data entity that defines a request to a member to perform a value-based exchange. In some embodiments, exchange authorization requests are provided from an exchange platform to members of an exchange network. Exchange authorization requests may also be provided to service providers of an exchange network, for example, in response to an exchange request from a partner of the exchange network. In some examples, an exchange authorization request may indicate an activation event associated with a UUEK. For example, an exchange authorization request may indicate the invalid and / or enabled status of a UUEK used to initiate a value exchange.

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

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

[0056] In some embodiments, the exchange authorization response may indicate one or more contextual response attributes. These one or more contextual response attributes may indicate, for example, one or more contributing factors to the exchange authorization response. Contributing factors may include, for example, bad actor risk and / or fraud checks, errors, full authorization, undisclosed instruments, instrument-based risk and / or fraud checks, insufficient values, invalid UUEKs, limit exceedances (e.g., exceeding UUEK or instrument usage limits), missing line items (e.g., in the case of value exchanges that do not include valid objects), missing instruments, missing accounts, requested PINs, partial authorization, unavailable members, transaction risk and / or fraud checks, unsupported behavior, user contact members (e.g., a user may need to contact a member such as a service provider to resolve an issue), user risk and / or fraud checks, 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 who submitted the exchange request. The exchange response may indicate exchange approval and / or exchange rejection. Additionally or alternatively, the exchange response may indicate valid data objects, invalid data objects, and / or context response attributes. For example, the exchange response may indicate one or more valid objects and / or one or more invalid objects for the exchange request.

[0058] In some embodiments, the term “exchange record” refers to a data entity that provides contextual information for an exchange request. Contextual information may represent one or more forms of an exchange request, exchange response, exchange authorization request, and / or exchange authorization request. For example, an exchange record may represent one or more active objects, inactive objects, the object status of each active and / or inactive object, and / or any other information associated with a 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 that acts on behalf of a partner, a service provider computing platform that acts 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 may be configured to act on behalf of a partner for one value exchange and on behalf of a service provider for another value exchange. In some examples, the same member platform may be configured to act on behalf of both a partner and a service provider in a single value exchange. It should be noted that the term member platform can refer to a partner platform, a service provider platform, or both, and in some examples, it may depend on the role of the member platform in the value exchange (e.g., and / or one or more APIs utilized by the member platform in the value exchange).

[0060] In some embodiments, the partner platform is a computing entity configured to perform one or more actions on behalf of the partner. The partner platform may include one or more processing devices, memory devices, and / or similar, physically and / or wirelessly coupled and configured to perform, for example, one or more computing tasks collectively (and / or individually) for requesting value in a value system-independent exchange. In some examples, the partner platform may include, define, and / or otherwise utilize one or more APIs to facilitate communication with the exchange platform (e.g., requests and responses). In some examples, the 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, the service provider platform is a computing entity configured to perform one or more actions on behalf of a service provider. The service provider platform may include one or more processing devices, memory devices, and / or similar, physically and / or wirelessly coupled and configured to perform, for example, one or more computing tasks collectively (and / or individually) to deliver value in a value system-independent exchange. In some examples, the service provider platform may include, define, and / or otherwise leverage one or more APIs to facilitate communication (e.g., requests and responses) with the exchange platform. In some examples, the service provider platform may be configured to facilitate one or more service provider instruments. In some examples, the service provider platform may be configured to host one or more user-facing applications (e.g., service provider applications) 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 an exchange platform and one or more member platforms and / or internal services. An exchange interface may include APIs, file-based interfaces, message queue-based interfaces, and / or similar. For example, an exchange interface may include APIs, such as one or more Simple Object Access Protocol (SOAP) APIs, one or more Remote Procedure Call (RPC) APIs, one or more WebSocket APIs, one or more Representational State Transfer (REST) ​​APIs, and / or similar. In some embodiments, an 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 similar for exchanging requests and / or responses between the exchange platform and entities participating in value exchange. For example, an exchange interface may include a partner API to facilitate communication with a partner platform and / or a service provider API to facilitate 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 similar for facilitating one or more request messages and / or response messages between the Partner Platform and the Exchange Platform. The Partner Interface may include, for example, APIs that define (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 similar for facilitating value exchange for a Partner. In some embodiments, the Partner Interface defines one or more identifiers for securely identifying one or more parts 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. A service provider interface may define one or more communication instructions, message definitions, and / or similar for facilitating one or more request messages and / or response messages between the service provider platform and the exchange platform. A service provider interface may include, for example, APIs that define (i) requests from a computing entity acting as a service provider platform to the exchange platform, and / or (ii) requests from the exchange platform to the service provider platform. A service provider interface may define, for example, one or more registration messages, session messages, transaction messages, and / or similar for facilitating value exchange using a service provider instrument. In some embodiments, a service provider interface may define one or more identifiers for securely identifying one or more parts 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 number, alphanumeric character, and / or similar that represents a particular computing entity. Entity partitions may include, for example, member partitions representing member platforms, service provider partitions representing service provider platforms, partner partitions representing partner platforms, and / or similar.

[0067] In some embodiments, the term “service provider partition” refers to a unique identifier for a service provider and / or a service provider’s service provider platform. A service provider partition may include a series of numbers, alphanumeric characters, or any other characters or symbols representing a service provider associated with the exchange platform (e.g., onboard, registered, etc.). An exchange platform may include multiple service provider partitions, each identifying a service provider platform attached to the exchange platform (e.g., onboard, registered, etc.). Each service provider partition may represent a service provider platform comprising one or more exchange platform software development kits (SDKs) and / or similar for implementing the exchange platform’s service provider interface.

[0068] In some embodiments, “Partner Partition” refers to a unique identifier for a partner and / or a partner's partner platform. A Partner Partition may include a series of numbers, alphanumeric characters, or any / or other characters or symbols representing a partner associated with an exchange platform. An exchange platform may include multiple Partner Partitions, each identifying a Partner Platform associated with the exchange platform (e.g., installed, registered, etc.). Each Partner Partition may represent a Partner Platform comprising one or more Exchange SDKs and / or similar for implementing the exchange platform’s Partner Interface.

[0069] In some embodiments, the term “user application” refers to a computer program hosted by a computing entity that facilitates the communication of one or more user information. A user application may include software (e.g., computer-readable instructions) designed to perform one or more computing tasks for a computing entity such as a member platform. For example, a user application can facilitate communication between a member and a user. As an example, a user 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 application may be configured to receive user input (e.g., via one or more user interfaces) to receive 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 that acts as a partner for a particular exchange) to facilitate functionality for the partner. The partner application may include software (e.g., computer-readable instructions) 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 communicating with (e.g., browsing, purchasing, scrutinizing, 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 similar. In some examples, the partner application may be configured to receive user input (e.g., via one or more user interfaces) to receive information from the user.

[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) 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 information (e.g., scrutiny, management, inspection, registration, etc.) with one or more service provider instruments facilitated by the service provider. As an example, in a financial value system, the service provider application may enable access to bank accounts, securities accounts, credit limits, and / or similar for managing funds, assets, and / or similar handled by each account. In some examples, the service provider application may be configured to receive user input (e.g., via one or more user interfaces) to receive information, authorizations, and / or similar from the user.

[0072] In some embodiments, the term “instrument data object” refers to a data entity representing 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, one or more instrument identifiers and / or one or more instrument attributes may be at least partially based on the type of instrument data object. For example, a service provider instrument may be represented as a member instrument data object in a member platform. Additionally or alternatively, a service provider instrument may be independently represented by a system instrument data object in an exchange platform. In some examples, member instrument data objects and system instrument data objects may include one or more of the same one or more instrument identifiers and / or one or more instrument attributes. For example, a member platform may register multiple service provider instruments with the exchange platform. During registration, member platforms may provide one or more instrument identifiers and / or instrument attributes, and in some cases, exchange platforms may return a different identifier.

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

[0074] In some embodiments, a system instrument data object is an external representation of a service provider instrument within the 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. The 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., credit-based instrument, debit-based instrument, information-based instrument), an instrument representation, and / or one or more contextual attributes. In some examples, the contextual attributes may depend on a value system. For example, in a financial value system, one or more contextual 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, instrument reference, instrument key, and / or similar, 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 numbers, alphanumeric characters, or any other characters or symbols representing a service provider instrument for a 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 enable the exchange platform to reference instruments maintained on the member platform. In some examples, the instrument reference is the same value as the member instrument identifier. In some examples, the 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 used to represent a service provider instrument within the exchange platform. A system instrument identifier may include, for example, a series of numbers, alphanumeric characters, or any other characters or symbols that represent a service provider instrument for 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. An instrument key may be generated and / or provided by the exchange platform, for example, during the process of registering an instrument 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 one or more of its APIs). The key format may include any number of characters, such as 50 or more. In some examples, the characters may be case-sensitive. A first part 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, the partition may include a service provider partition. A second part of the characters may identify the system instrument identifier. The key formats described herein may include one or more distinct parts, each of which may be arranged in any order.

[0080] In some embodiments, the term “instrument representation” refers to a unique identifier used to represent a service provider instrument for a user. An instrument representation may include, for example, a series of numbers, alphanumeric characters, or any other characters or symbols that visually 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 of persistent credentials (e.g., the last four digits) such as an account number (e.g., a direct debit account, a credit account), a financial account name, and / or similar. Alternatively, in an information value system, an instrument reference may include a portion of persistent credentials (e.g., one or more digits, alphanumeric characters) such as a subscription account and / or similar. For example, an instrument representation may include derivatives of persistent credentials, allowing only entities with prior knowledge of the persistent credentials to use the instrument representation to identify the persistent credentials. As another example, an instrument representation may include a nickname for the instrument, which is assigned and subsequently recognized by the user.

[0081] In some embodiments, the term “user data object” refers to a data entity representing a user communicating with the Member Platform and / or Exchange Platform. A user may include, for example, entities (e.g., people, organizations, groups, etc.) engaged in value exchanges governed by the Exchange Platform. In some examples, a user may indirectly interact with the Exchange Platform by creating user accounts for registered service providers, registering (and / or granting permission to register) service provider instruments, and / or similar. In some examples, the Exchange Platform may function on behalf of a user without the user's direct interaction 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 instruments.

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

[0083] In some embodiments, a member user data object is an internal representation of a user within the member platform. A 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 similar. Additionally or alternatively, a member user data object may include one or more user attributes. One or more user attributes may represent one or more contextual characteristics of the user. In some examples, a user attribute may represent one or more identifiable characteristics of the user. For example, a user attribute may represent the user's first name, last name, email, physical address (e.g., one or more of street, local, region, zip code, country, etc.), date of birth (e.g., birth date, age group, etc.), telephone number, and / or similar. In some examples, a user attribute may include encrypted, hashed, and / or otherwise secure representations of the user's identifiable characteristics. For example, a user attribute may include one or more hashed identifiers and / or similar of the user.

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

[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 numbers, alphanumeric characters, or any other characters or symbols representing a user of the exchange platform and / or member platform. In some examples, a user identifier may include a user reference, user key, system user identifier, member user identifier, and / or similar.

[0086] In some embodiments, the term “system user identifier” refers to a unique identifier used to represent a user within the exchange platform. The system user identifier may include, for example, a series of numbers, alphanumeric characters, or any other characters or symbols that represent a user to the exchange platform. In some examples, the 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 used to represent a user within the member platform. A member user identifier may include, for example, a series of numbers, alphanumeric characters, or any other characters or symbols representing a user to a service provider platform.

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

[0089] In some embodiments, the term “user key” refers to a unique identifier for referencing a system user identifier. A user key may be generated and / or provided by the exchange platform, for example, during the user registration process with the exchange platform. In some examples, a user key may include a packaged system user identifier. For example, a user key may include a string of alphanumeric characters formatted according to a key format established by the exchange platform (and / or one or more of its APIs). The key format may include, for example, a first part of the characters (e.g., the first six characters) which may be reserved as a partition for identifying entities associated with the key (e.g., members). For example, in the case of a user key, the partition may include a service provider partition and / or a partner partition. A second part of the 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, one or more identifiers and / or one or more exchange attributes may be at least in part based on the type of exchange data object. For example, an exchange may be represented as a member exchange data object in a member platform. Additionally or alternatively, an exchange may be independently represented by a system exchange data object in an exchange platform. In some examples, member exchange data objects and system exchange data objects may include one or more of the same one or more identifiers and / or exchange attributes. For example, using some of the technology of this disclosure, an exchange platform may issue one or more unique identifiers to member platforms that may be used to authorize value exchanges.

[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 role of the system exchange data object in a value-based exchange.

[0092] For example, a system exchange data object may include a service provider-specific exchange data object corresponding to a service provider platform. A 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 similar. Additionally or alternatively, a service provider-specific exchange data object may include one or more exchange attributes, such as an expiration date, currency (e.g., for a financial value system), and / or similar.

[0093] Additionally or alternatively, a system exchange data object may include a partner-specific exchange data object corresponding to a partner platform. A partner-specific exchange data object may include one or more identifiers, such as an exchange identifier, instrument key, UUEK, member instrument reference (e.g., a partner-specific instrument reference), and / or similar. Additionally or alternatively, a partner-specific exchange data object may include one or more exchange attributes, such as an expiration date, currency (e.g., in the case of a financial value system), instrument type, previous UUEK identifier, and / or similar. In some embodiments, a member exchange data object is an external representation of a value exchange mediated using the exchange platform. A member exchange data object may include one or more identifiers, such as a member exchange identifier, member instrument identifier, UUEK from the exchange platform, and / or similar.

[0094] In some embodiments, the term “exchange identifier” refers to a unique identifier for value exchange using the exchange platform. An exchange identifier may include a set of numbers, alphanumeric characters, or any other character or symbol representing at least a user and / or service provider instrument. In some examples, a unique exchange identifier may include a universally unique identifier (UUID) that can be mapped (e.g., through a set of identifiers) to users, service provider instruments, and / or members registered with the exchange platform. In some examples, an exchange identifier may be randomly generated using one or more UUID generators. For example, an exchange identifier may include 16 bytes of random information generated according to one or more UUID format standards, such as UUID v4 and / or similar. Thus, an exchange identifier may be leveraged by the exchange platform and / or member platforms for one or more functions, but the same exchange identifier will be useless to external parties without a prior association between the exchange identifier and one or more other identifiers. In some examples, an 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 can be issued (e.g., instead of a service provider exchange identifier and / or partner exchange identifier) ​​to external entities, such as users, partners, and / or service providers, in order to initiate a transaction using the exchange platform. To do so, a UUEK can be generated and issued by the exchange platform to external entities. Each UUEK may contain multiple values ​​(e.g., up to 50 case-sensitive characters and / or more) that represent one or more aspects of a transaction. For example, the multiple values ​​may represent an exchange identifier, a partition (e.g., identifying the recipient of the UUEK), an identifier type, and / or one or more flags. As an example, a UUEK may include a partner-specific UUEK and / or a service provider-specific UUEK. Partner-specific UUEKs may be correlated to partner-specific exchange data objects as described herein, while service provider-specific UUEKs may be correlated to service provider-specific exchange data objects.

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

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

[0098] In some embodiments, “UUEK representation” refers to a viewable representation of the UUEK. The UUEK representation may include a digital representation of the UUEK that is 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, 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, 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 the user to physically perform value-based exchanges using the service provider instrument without referring to persistent credentials for the service provider instrument. The UUEK representation may be scanned 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, “effective UUEK representation” refers to the UUEK representation of a UUEK that was enabled by a previous secure event. The effective UUEK representation may include status indicators and / or one or more other indicators that represent the enabled status of the UUEK. In some examples, the effective UUEK representation may include a readable UUEK representation.

[0100] In some embodiments, “invalid UUEK representation” refers to a UUEK representation of a UUEK that has not been enabled by a previous secure event. An invalid UUEK representation may include a status indicator and / or one or more other indicators that represent the disabled status of the UUEK. In some examples, an invalid UUEK representation may include an illegible UUEK representation. An illegible UUEK representation may include a scannable representation that is, for example, grayed out, obscured, partially covered, and / or similar, preventing 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 a product. Such a computer program product may include one or more software components, for example, software objects, methods, data structures, or the like. Software components may be encoded in any of various programming languages. An illustrative programming language may be a low-level programming language, such as an assembly language associated with a particular hardware architecture and / or operating system platform. A software component comprising assembly language instructions may require conversion to executable machine code by an assembler before execution by the hardware architecture and / or platform. Another illustrative programming language may be a high-level programming language that may be portable across multiple architectures. A software component comprising high-level programming language instructions may require conversion to an intermediary 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 reporting languages. In one or more exemplary embodiments, a software component comprising instructions in one of the aforementioned examples of programming languages ​​may be executed directly by an operating system or other software component without first being converted into another form. Software components may be stored as files or other data storage structures. Software components of similar types or functionally related types 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 runtime).

[0103] A computer program product may include non-temporary computer-readable storage media that store applications, programs, program modules, scripts, source code, program code, object code, byte code, compiled code, interpreted code, machine language, executable instructions, and / or similar terms used herein without distinction. Such non-temporary computer-readable storage media include all computer-readable media (including volatile and non-volatile media).

[0104] In one embodiment, the non-volatile computer-readable storage medium may include floppy disks, flexible disks, hard disks, solid-state storage (SSS) (e.g., solid-state drives (SSDs), solid-state cards (SSCs), solid-state modules (SSMs), enterprise flash drives, magnetic tape, or any other non-transient magnetic medium and / or similar). 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 markings), compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), digital barcodes, etc. This may include non-volatile optical media such as DVDs, Blu-ray discs (BDs), any other non-volatile optical media, and / or similar. 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 similar), multimedia memory cards (MMCs), secure digital (SD) memory cards, SmartMedia cards, CompactFlash® (CF) cards, Memory Sticks, and / or similar.Furthermore, non-volatile computer-readable memory media 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 similar.

[0105] In one embodiment, the volatile computer-readable storage medium is 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). This may include SDRAM, Rambus Dynamic Random Access Memory (RDRAM), Twin Transistor RAM (TTRAM), Thyristor RAM (T-RAM), Zero Capacitor (Z-RAM), Rambus Inline Memory Module (RIMM), Dual Inline Memory Module (DIMM), Single Inline Memory Module (SIMM), Video Random Access Memory (VRAM), Cache Memory (including various levels), Flash Memory, Register Memory, and / or similar. When embodiments for using computer-readable storage media are described, 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 recognized, various embodiments of the present disclosure may also be implemented as methods, apparatus, systems, computing devices, computing entities, and / or similar. Accordingly, embodiments of the present disclosure may take the form of data structures, apparatus, systems, computing devices, computing entities, and / or similar that execute instructions stored in a computer-readable storage medium for performing a particular step or operation. Accordingly, embodiments of the present disclosure may also take the form of entirely hardware embodiments, entirely computer program product embodiments, and / or embodiments comprising a combination of a computer program product and hardware for performing a particular step or operation.

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

[0108] IV. Exemplary System Architecture Figure 1 provides an illustration of a computing ecosystem 100 that may be used with various embodiments of the present disclosure. As shown in Figure 1, the architecture may include a switching platform 102, one or more client devices 104, a network of member platforms 110, one or more networks 120, and / or similar. 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 similar that are attached to (e.g., registered with) the switching 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, the partner platform and / or service provider platform may include a single member platform (e.g., a third member platform 112c). In some examples, the member platform's network 110 may be configured for one or more different services.

[0109] Each component of the computing ecosystem 100 may be electronically communicating with one another via the same or different wireless or wired networks 120, for example, including wired or wireless personal area networks (PANs), local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), or similar. Network 120 may include any network connectivity (e.g., international connectivity including one or more sovereign entities) that includes any of the types of networks and / or span any geographical boundaries. Additionally, while Figure 1 illustrates a particular system as a separate, independent entity, various embodiments are not limited to this particular architecture.

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

[0111] a. Exemplary computing platform Figure 2 is an exemplary schematic diagram of a computing platform 200 according to one or more embodiments of the present disclosure. The computing platform 200, such as the exchange platform 102, member platforms 112a-c, and / or similar in Figure 1, may include, or be communicating with, one or more processing elements 202 (also called processors, processing circuitry, and / or similar terms used herein without distinction) that communicate with other elements within the computing platform 200, for example, via a bus. Naturally, the processing elements 202 may be embodied in several different ways.

[0112] For example, the 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. Furthermore, the processing element 202 may be embodied as one or more other processing devices or circuit equipment. The term circuit equipment can refer entirely to a hardware embodiment or a combination of hardware and computer program products. Thus, the 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 circuit equipment, and / or similar.

[0113] Therefore, naturally, the processing element 202 may be configured to execute instructions configured for a specific use, stored in a volatile or non-volatile medium, or otherwise accessible to the processing element 202. Thus, whether configured by hardware or computer program products, or a combination thereof, the processing element 202 may have the ability to perform steps or operations according to embodiments of the present disclosure as appropriate when configured.

[0114] In some embodiments, the computing platform 200 includes or communicates with non-volatile memory 204 (also known as non-volatile storage, media, memory storage, memory circuitry, and / or similar terms used herein without distinction). In some examples, the non-volatile memory 204 may include one or more non-volatile storage or memory media, including but not limited to hard disks, ROMs, PROMs, EPROMs, EEPROMs, flash memory, MMCs, SD memory cards, memory sticks, CBRAMs, PRAMs, FeRAMs, NVRAMs, MRAMs, RRAMs, SONOS, FJG RAMs, millipede memory, racetrack memory, and / or similar.

[0115] As recognized, non-volatile memory 204 can store data, databases, database instances, database management systems, files, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine language, executable instructions, and / or similar. The terms database, database instance, database management system, and / or similar terms used herein without distinction can refer to a collection of records or data stored on 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 similar.

[0116] In some embodiments, the computing platform 200 includes or communicates with volatile memory 206 (also referred to as volatile storage, media, memory storage, memory circuitry, and / or similar terms used herein without distinction). In some examples, the volatile memory 206 may also include, 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 similar.

[0117] As recognized, volatile memory 206 may be used to store at least a portion of databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or similar items, which are executed, for example, by processing element 202. Thus, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or similar items may be used, with the assistance of processing element 202 and the operating system, to control specific aspects of the steps / operations of the computing platform 200.

[0118] As shown, in one embodiment, the computing platform 200 may also include one or more network interfaces 208 for communicating with various computing entities (e.g., one or more components in Figure 1) by transmitting, receiving, operating, processing, displaying, storing, and / or similar data, content, information, and / or similar terms used herein without distinction. Such communication may be performed using wired data transmission protocols such as Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, Data Over Cable Service Interface Specification (DOCSIS), or any other wired transmission protocol. Similarly, the computing platform 200 may also use General-Purpose Packet Radio Services (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), and CDMA2000 It can be configured to communicate over a wireless external communication network using any of the following protocols: 1X (1xRTT), Wideband Code Division Multiple Access (WCDMA®), Global System for Mobile Communications (GSM), GSM Evolution High Speed ​​Data Rate (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, the computing platform 200 may include or be communicating with one or more input elements, such as keyboard input, mouse input, touchscreen / display input, motion input, motion input, audio input, pointing device input, joystick input, keypad input, and / or similar. The computing platform 200 may also include or be communicating with one or more output elements (not shown), such as audio output, video output, screen / display output, motion output, motion output, and / or similar.

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

[0121] b. Exemplary client devices Figure 3 is an exemplary schematic diagram of a client device 104 according to one or more embodiments of the present disclosure. The client device 104 may be operated by various entities, and the exemplary computing ecosystem may include one or more client devices 104. For example, the client device 104 may be associated with one or more end users, owned by one or more end users, operated by one or more end users, and / or similarly performed by one or more end users. In various embodiments, the end user of the client device 104 may want to engage in a value exchange between a partner and a service provider. As described herein, the user can do so by mutually leveraging one or more functionalities provided by the exchange platform through user input using the client device 104.

[0122] For example, the client device 104 may be a personal computing device, smartphone, tablet, laptop, personal digital assistant, and / or similar. In various embodiments, the computing platform 200 can communicate with one or more client devices 104 and manage value exchanges with one or more client devices 104. As shown in Figure 3, the 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, microprocessor, multicore processor, coprocessing entity, ASIP, microcontroller, and / or controller), respectively, which provide signals to and receive signals from the transmitter 304 and receiver 306.

[0123] The signals provided to and received by the transmitter 304 and receiver 306 may each contain signaling information / data according to the applicable wireless system air interface standard. In this regard, the client device 104 may have the ability to operate with one or more air interface standards, communication protocols, modulation types, and access types. More specifically, 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 certain embodiments, the client device 104 may operate according to a number of wireless communication standards and protocols, such as UMTS, CDMA2000, 1xRTT, WCDMA, GSM, EDGE, TD-SCDMA, LTE, E-UTRAN, EVDO, HSPA, HSDPA, Wi-Fi, Wi-Fi Direct, WiMAX, UWB, IR, NFC, Bluetooth, USB, and / or similar. Similarly, the client device 104 can operate via the network interface 320 in accordance with 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, the client device 104 can communicate with the 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 Identification Module Dialer (SIM Dialer). The client device 104 can also download changes, add-ons, and updates to, for example, its firmware, software (including, for example, executable instructions, applications, and program modules), and operating system.

[0125] In some embodiments, client device 104 includes location determination modes, devices, modules, functions, and / or similar terms used herein without distinction. For example, client device 104 may include outdoor positioning modes, such as a location module adapted to acquire, for example, 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 the field of view and the relative positions of these satellites (for example, using a Global Positioning System (GPS)). The satellites may be various different satellites, including Low Earth Orbit (LEO) satellite systems, Department of Defense (DOD) satellite systems, European Union Galileo Positioning System, China Compass Navigation System, Indian Regional Navigational Satellite System, and / or similar. This data can be collected using a variety of coordinate systems, such as Decimal Angle (DD), Degrees, Minutes, Seconds (DMS), Universal Transverse Mercator (UTM), Universal Polar Centered Transverse (UPS) coordinate system, and / or similar. Alternatively, location information / data may be determined by triangulation of the position of the client device 104 relative to various other systems, including cellular towers, Wi-Fi access points, and / or similar. Similarly, the client device 104 may include indoor positioning configurations, such as location modules adapted to acquire, for example, latitude, longitude, altitude, geocode, course, direction, orientation, speed, time, date, and / or various other information / data. Some indoor systems may use a variety of positioning 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 similar.For example, such technologies may include iBeacons®, Gimbal proximity beacons, Bluetooth Low Energy (BLE) transmitters, NFC transmitters, and / or similar. These indoor positioning methods can be used in a variety of environments to determine the location of someone or something to the nearest inch or centimeter.

[0126] In some embodiments, the client device 104 may include a user interface 316 (e.g., a display screen, speaker, tactile mechanization, etc., coupled to the processing element 308) and / or a user input interface 318 (e.g., a touch screen, 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 as 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 devices. In an example including a keypad, the keypad may include (or trigger the display of) conventional numerals (0-9) and associated keys (#, *), as well as other keys used to operate the client device 104, and may include a set of keys that can be activated to provide a complete set of alphabet keys or a complete set of alphanumeric keys. In addition to providing input, user input interfaces can be used to activate or deactivate specific functions, such as screen savers and / or sleep modes.

[0127] The client device 104 may also include volatile memory 322 and / or non-volatile memory 324, which may be built-in and / or removable. For example, non-volatile memory 324 may be ROM, PROM, EPROM, EEPROM, flash memory, MMC, SD memory card, memory stick, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, millipede memory, racetrack memory, and / or similar. Volatile memory 322 may be RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory, and / or similar. Volatile and non-volatile storage or memory can store databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or similar items in order to perform the functions of the client device 104. As shown, this may include partner applications, service provider applications, and / or similar items that reside on the client device 104 and / or are accessible through a browser or other user interface to communicate with the computing platform 200.

[0128] In some embodiments, the client device 104 may include one or more components or functions that are the same as or similar to those of the computing platform 200, as described in more detail above. As recognized, these architectures and descriptions are provided for illustrative purposes only and are not limited to 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, Amazon Echo Dot, Amazon Show, Google Home, and / or similar. Thus, 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, camera, speaker, voice-activated input, and / or similar. In certain embodiments, the AI ​​computing entity may comprise one or more predefined and executable program algorithms stored in an onboard memory storage module and / or accessible via a network. In various embodiments, the AI ​​computing entity may be configured to retrieve and / or execute one or more of the predefined program algorithms upon the occurrence of a predefined trigger event.

[0130] c. Exemplary Network In some embodiments, two or more of the illustrative components of the computing ecosystem 100 in Figure 1 may be configured to communicate with one another via their respective communicable connections to one or more networks 120. Network 120 may include, but is not limited to, one or a combination of different types of suitable communication networks, such as cable networks, public networks (e.g., the Internet), private networks (e.g., Frame Relay networks), wireless networks, cellular networks, telephone networks (e.g., public switched telephone networks), or any other suitable private and / or public networks. Furthermore, network 120 may have any suitable communication range associated with network 120, which may include, for example, a global network (e.g., the Internet), a MAN, WAN, LAN, or PAN. In addition, network 120 may include any type of medium on which network traffic can be carried, including but not limited to coaxial cables, twisted pair wires, optical fibers, hybrid fiber coaxial (HFC) media, microwave telescopic transceivers, radio frequency communication media, satellite communication media, or any combination thereof, as well as various network devices and computing platforms provided by network providers or other entities.

[0131] d. Exemplary Value Exchange Systems Figure 4 is an exemplary block diagram of an exemplary network-based exchange system 400 according to one or more embodiments of the present disclosure. The network-based exchange system 400 includes a new computing ecosystem and computing platform that provides an end-to-end value exchange solution for replacing conventional exchange processing systems. As described herein, the network-based exchange system 400 may be value system independent and can be applied to any value-based exchange, including, for example, information-based exchange, finance-based exchange, reputation-based exchange, healthcare-based exchange, profit-based exchange, and / or similar. In any value system, the network-based exchange system 400 can leverage intermediary entities and one or more predefined communication interfaces to facilitate network-based exchange between value-seeking entities (e.g., partners) and value-providing entities (e.g., service providers), which may be associated with one or more member platforms of the network-based exchange system 400.

[0132] As described, the network-based switching system 400 may include a switching platform 102, a partner platform 420, and / or a service provider platform 440, which may be configured to communicate through one or more switching interfaces. The partner platform 420 and / or service provider platform 440 may include one or more member platforms 112a-c from the network 110 of member platforms. For example, the partner platform 420 and service provider platform 440 may include a single member platform (e.g., member platform 112c). In addition or alternatively, the 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 a client device 104.

[0133] In some embodiments, the exchange platform 102 is a computing entity configured to facilitate credential-free 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 similar, physically and / or wirelessly coupled and configured to perform one or more computing tasks collectively (and / or individually) to facilitate exchanges independent of the value system. In some examples, the exchange platform 102 may include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communication (e.g., requests, responses, etc.) between multiple members. As described herein, interfaces may be utilized to facilitate secure exchanges between one or more members in any value system.

[0134] In some embodiments, a member is an entity that collaborates with the exchange platform 102 to participate in a value exchange. For example, a member may include (i) a partner that utilizes the exchange platform 102 to receive value, (ii) a service provider that utilizes the exchange platform 102 to provide value, and / or (iii) both a partner and a service provider. As used herein, a member may be called 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, and thus the member utilizes the exchange platform 102 to provide value in a single member value exchange and then receive value.

[0135] In some embodiments, a member is a partner when using services provided by a service provider. A partner can include any value-seeking entity in any value system. For example, in a financial value system, a partner can include a merchant (e.g., a retailer, a physical store, etc.) who may use a service provider, such as a financial institution, to access funds for financial transactions. Additionally or alternatively, in an information value system, a partner can include a news publisher (e.g., a newspaper, a press, etc.) who may use 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 can include a healthcare provider who may have access to a healthcare benefit administrator to access medical benefits to fund medical surgery. Naturally, the technology of this disclosure may be applied to any value system, and a partner can include any value-seeking entity for any respective value system.

[0136] In some embodiments, a Member is a service provider when providing services to a Partner. A service provider can include a source of value in any value system. For example, in a financial value system, a service provider can include a financial institution (e.g., a bank, foreign 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.) from which news publishers can provide information for publication. In a healthcare value system, a service provider can include a healthcare benefit administrator that can provide the healthcare provider with access to medical benefits. Naturally, the technology 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 deliver 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 the service provider's accounts. For example, in a financial value system, the service provider instrument may include bank accounts (e.g., checking accounts, savings accounts, etc.), securities accounts, credit limits, and / or similar. In an information value system, the service provider instrument may include subscriber accounts and / or similar. In a healthcare value system, the service provider instrument may include healthcare benefit accounts and / or similar.

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

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

[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 the client device for enabling and / or disabling the UUEK (and / or any other exchange credentials) before an exchange request. Thus, the security code may be deployed to any type of service provider instrument through enabling and / or disabling the corresponding UUEK. By managing the security code at the network level, the likelihood of authorization denial due to an invalid PIN is eliminated, so members can benefit from faster exchanges. For example, a UUEK may be disabled until a security code is received to enable the UUEK. The exchange platform 102 can prevent a user from initiating an exchange until the UUEK is enabled, thereby ensuring that all exchange authorization requests provided to the service provider are pre-enabled with the security code in mind.

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

[0142] In some embodiments, the security code tuple 424 is a data entity that defines a correlation between a UUEK and a security code. The security code tuple 424 may include a data object, record, and / or any other data structure (e.g., a linked node) configured to represent the association between the security code and the UUEK. The security code tuple 424 may include, for example, a security code reference, a UUEK, one or more derived 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, configuration time (e.g., the time the security code tuple was set), expiration time (e.g., the time the security code must be reset), and / or similar. As described herein, the security code tuple 424 may be utilized by the exchange platform 102 to identify the security code reference of the UUEK and to enable (and / or disable) the UUEK, at least in part, based on a comparison between the security code reference and the security code input provided by the user.

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

[0144] In some embodiments, Member Policy 422 defines one or more enablement requirements for a service provider instrument. Member Policy 422 may apply to a member and / or a member's service provider instrument. 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. Member-specific standards may apply to multiple service provider instruments associated with a member, while instrument-specific standards may apply to at least one of multiple service provider instruments associated with a member.

[0145] The activation requirement may indicate one or more policy attributes of a value-based exchange that require an active UUEK. For example, an invalid UUEK may be used to grant authorization to a value-based exchange that does not include one or more attributes that require an active UUEK. If a value-based exchange includes at least one attribute that requires an active UUEK, an invalid UUEK may be prevented from granting authorization to 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 an object. For example, member policy 422 may include multiple object identifiers. The multiple object identifiers may indicate multiple authorized / unauthorized objects to be acquired (e.g., to be purchased) with an invalid UUEK.

[0147] In some examples, the object identifier may also be a global object identifier. For example, the global object identifier may be a minimum stock management unit (SKU) code. Additionally or alternatively, the global object identifier may be a manufacturer part number (MPN), global trade item number (GTIN), product or service name, international standard book number (ISBN), unified product code (UPC), international product number (EIN), and / or similar. In some examples, the object identifier may include a system object identifier. The system object identifier may include, for example, an identifier corresponding to a recorded data object that represents an object within the exchange platform 102 (e.g., a table identifier). In some embodiments, the system object identifier and the global object identifier are the same.

[0148] In some embodiments, policy attributes include value exchange attributes corresponding to a particular value-based exchange and / or objects included in the value-based exchange. 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 for which each secure event is required for the service provider instrument.

[0149] Service providers and partners can communicate through one or more member platforms associated with the entity, respectively. For 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, the member platform is a computing entity corresponding to a member associated with the exchange platform 102. The member platform may include a partner platform 420 that acts on behalf of a partner, a service provider platform 440 that acts on behalf of a service provider, and / or both. In some examples, the member platform may be both the partner platform 420 and the service provider platform 440. For example, the same member platform may be configured to act 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 act on behalf of both a partner and a service provider in a single value exchange. It should be noted that the term member platform may refer to the partner platform 420, the service provider platform 440, or both, and in some examples, it may depend on the role of the member platform in the value exchange (e.g., and / or one or more interfaces utilized by the member platform in the value exchange).

[0151] In some embodiments, the partner platform 420 is a computing entity configured to perform one or more operations on behalf of the partner. The partner platform 420 may include one or more processing devices, memory devices, and / or similar, physically and / or wirelessly coupled and configured to perform, for example, one or more computing tasks collectively (and / or individually) for requesting value in a value system-independent exchange. In some examples, the partner platform 420 may include, define, and / or otherwise utilize one or more exchange interfaces to facilitate communication (e.g., requests, responses, etc.) with the exchange platform 102. In some examples, the 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 can host an online marketplace for Partners, for example in a financial value system, enabling users to communicate (e.g., search, browse, buy, return, etc.) with one or more products or services offered by Partners. In the case of product purchases, the Partner Platform 420 can work with one or more service providers to access funds for the purchase. Traditionally, access to funds from service providers is facilitated using card numbers, account numbers, and / or other financial credentials, which could 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 can register with the Exchange Platform 102 by configuring one or more software development kits (SDKs), APIs, and / or similar 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, the service provider platform 440 is a computing entity configured to perform one or more operations on behalf of the service provider. The service provider platform 440 may include one or more processing devices, memory devices, and / or similar, physically and / or wirelessly coupled and configured to perform one or more computing tasks collectively (and / or individually) to deliver value in a value system-independent exchange. In some examples, the service provider platform 440 may include, implement, and / or otherwise utilize one or more interfaces to facilitate communication (e.g., requests, responses, etc.) with the exchange platform 102. In some examples, the service provider platform 440 may be configured to facilitate one or more service provider instruments. In some examples, the 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., credit limits, bank accounts, etc.) that enable users to fund exchanges for purchasing products from a partner, for example, in a financial value system. In the case of product purchases, the service provider platform 440 may work with the partner platform 420 to authorize the exchange and / or otherwise provide access to funds for the purchase. Traditionally, access to funds from a service provider is facilitated by presenting card numbers, account numbers, and / or other financial credentials to the service provider platform 440, which can expose users, service providers, or partners to malicious parties, especially when provided over insecure networks (e.g., public networks, and / or similar). To address network security and data privacy concerns with respect to conventional financial systems (and / or other value-based systems), the service provider platform 440 may register with the exchange platform 102 by configuring one or more software development kits (SDKs), APIs, and / or similar to facilitate communication with the exchange platform 102. For example, the 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 the 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 may be configured to facilitate one or more service provider instruments. In some examples, the service provider instruments may include virtual instruments (e.g., virtual accounts, credit limits, etc.) hosted by the service provider platform 440. For example, the service provider platform 440 may be configured to maintain multiple instrument data objects that represent multiple service provider instruments for multiple associated entities.

[0156] In some embodiments, an instrument data object is a data entity representing 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, one or more instrument identifiers and / or one or more instrument attributes may be at least partially based on the type of instrument data object. For example, a service provider instrument may be represented as a member instrument data object in a member platform (e.g., service provider platform 440). Alternatively, a service provider instrument may be independently represented by a system instrument data object in exchange platform 102. In some examples, member instrument data objects and system instrument data objects may include one or more of the same one or more instrument identifiers and / or one or more instrument attributes. For example, a member platform can register multiple service provider instruments with the exchange platform 102 (for example, using the service provider interface 404). During registration, the member platform (for example, the service provider platform 440) can provide one or more instrument identifiers and / or instrument attributes, and in some examples, the exchange platform 102 can return a different identifier.

[0157] In some embodiments, the Member Instrument Data Object is an internal representation of a Service Provider Instrument within a Member Platform, such as the 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 the 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., a Credit-Based Instrument, a Debit-Based Instrument, an Information-Based Instrument), an Instrument Representation, and / or one or more contextual attributes. In some examples, the contextual attributes may depend on a value system. For example, in a financial value system, one or more contextual attributes may indicate (i) the currency associated with the service provider instrument, (ii) the asset availability of the service provider instrument (e.g., balance, coverage, etc.), or (iii) one or more previous transactions and / or similar transactions at the service provider instrument.

[0158] In some embodiments, a system instrument data object is an external representation of a service provider instrument within the exchange platform 102. The 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. The user identifier may include, for example, a system user identifier, as described herein. Additionally or alternatively, the system 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), an instrument representation, and / or one or more contextual attributes. In some examples, the contextual attributes may depend on a value system. For example, in a financial value system, one or more contextual attributes may indicate the 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 enablement service 408 configured to adjudicate secure information transmission requests and / or exchange requests, at least in part, based on a valid security code input and / or member policy 422. To do so, the exchange platform 102 (and / or its enablement service 408) may have access to the security code tuple 424 and / or member policy 422 of the service provider instrument. For example, a member platform may register a security code with the exchange platform 102 (e.g., using the service provider interface 404 and / or partner interface 402). After registration, the security code may be stored as a security code reference of the security code tuple 424, with the security code reference associated with the user, member, service provider instrument, and / or UUEK associated therewith. As an addition or alternative, a member platform may register the member policy 422 with the exchange platform 102 (for example, using the service provider interface 404). During registration, the member platform (for example, the service provider platform 440) may provide one or more policy attributes, attribute updates, and / or similar to enable secure information transmission and / or exchange requests referencing one or more service provider instruments that are maintained and / or similarly maintained by the member platform. In some examples, the member platform may continuously 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., an activation service 408) can use security codes and / or member policies 422 to activate users, service provider instruments, UUEKs, and / or exchange requests. In some examples, the activation of an exchange request may be based at least in part on recorded data objects.

[0161] In some embodiments, a recorded data object is a data object representing an object that may be involved in a value-based exchange. In some examples, a recorded data object may also be an internal representation of an object for the exchange platform 102. For example, an object may include different units of a value-based exchange in which value is being transferred. A recorded data object of 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 partially on a value system. For example, in a financial value system, an object may be a tangible or intangible item, product, and / or similar that can be purchased in exchange for a unit of currency. In a healthcare value system, an object may be a healthcare procedure and / or similar that can be covered by a healthcare policy.

[0163] In some examples, the exchange platform 102 may maintain and / or access an object data store containing multiple recorded data objects. As described herein, the object data store may contain multiple recorded data objects obtained at least partially from one or more members of the exchange network.

[0164] In some embodiments, object attributes of a data entity represent the characteristics of an object. Object attributes can 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 express object characteristics. Spatial attributes may indicate, for example, one or more dimensions of an object (e.g., height, width, weight); value attributes may indicate the value of an object (e.g., price); composition attributes may indicate one or more components, constituents, etc. of an object; category attributes may indicate one or more categories of an object (e.g., restricted substances); and / or similar. For example, one or more category attributes may indicate whether an object is associated with (i) one or more general merchandise categories such as vegetables, fruits, dairy products, meat, grains, seeds, alcohol, tobacco, store consumables, hot food, pharmacies, pet food, and non-food items; (ii) one or more medical categories such as dental, ophthalmology, and general health; or (iii) one or more information categories such as international sources and domestic sources, and / or similar. In some examples, compositional attributes may indicate one or more components of an object, such as the volume percentage of alcohol in the object, one or more ingredients, such as meat, dairy, peanuts, nuts, soy, and / or similar.

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

[0167] In some examples, member platforms, such as the partner platform 420 and / or the service provider platform 440, may be associated with user-facing applications to facilitate the exchange of one or more information with users and / or other associated entities (e.g., through client devices 104).

[0168] In some embodiments, a user application is a computer program hosted by a computing entity to facilitate the transmission of one or more user information. The user application may include software (e.g., computer-readable instructions) designed to perform one or more computing tasks for a computing entity, such as a member platform. For example, the user application can facilitate communication between a member and a user. As an example, the user application may be configured to present one or more user interfaces 406 (e.g., via a client device 104) for communicating with the user on behalf of the member. In some examples, the user 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, security code input to secure the transmission of information for the user.

[0169] In some embodiments, the user application is a partner application 416 hosted by a partner platform 420 (e.g., a member platform that acts as a partner for a specific exchange) to facilitate functionality for the partner. The partner application 416 may include software (e.g., computer-readable instructions) 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) from a standalone partner facility (e.g., a bank with a physical store). For example, the partner application 416 may be configured to present one or more user interfaces 406 for communicating with (e.g., browsing, purchasing, scrutinizing, 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 similar. In some examples, the partner application 416 may be configured to receive user input (e.g., via one or more user interfaces 406) to receive information from the user.

[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, the user-facing application may also 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 standalone service provider facility (e.g., a bank with a physical branch). The service provider application 418 may include software (e.g., computer-readable instructions) 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 communicating with one or more service provider instruments (e.g., scrutiny, management, inspection, registration, etc.) facilitated by the service provider. For example, in a financial value system, the service provider application 418 may enable access to bank accounts, securities accounts, credit limits, and / or similar entities to manage funds, assets, and / or similar entities handled by each account. 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, permissions, and / or similar entities from the user.

[0171] In some embodiments, the partner application 416 and / or the 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 corresponding UUEKs. For example, the partner platform 420 and / or the service provider platform 440 may enable users, organizations, and / or any other entity to configure security codes to initiate secure information transfer. As an addition or alternative, the service provider platform 440 may enable users, organizations, and / or any other entity 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 a service provider application 418 and / or a partner application 416. User input may include, for example, a security code input to initiate secure information transmission. For example, a security code input may be provided to the exchange platform 102 through input to the user interface of the service provider application 418 and / or the partner application 416. In some embodiments, the exchange platform 102 facilitates communication between the partner platform 420 and the service provider platform 440 using one or more exchange interfaces.

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

[0174] The 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 similar for exchanging requests and / or responses between the exchange platform 102 and entities participating in value exchange. For example, an exchange interface may include a partner interface 402 to facilitate communication with partner platform 420, and / or a service provider interface 404 to facilitate communication with service provider platform 440.

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

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

[0177] The exchange platform 102 can facilitate communication between member platform networks. For example, a member network may include multiple entities on which the exchange platform 102 is installed, for example, by registering with the exchange platform 102, configuring their respective interfaces for communicating with the exchange platform 102, and / or similar means. In some examples, the exchange platform 102 may perform one or more individual services for communicating information with each installed entity. Individual services may include, for example, one or more partner services 410 and / or service provider services 412.

[0178] In some embodiments, the exchange platform 102 exemplified a partner service 410, which is a separate partner-specific service for each of the member networks. Additional or alternative, for example in a multi-tenant environment, the partner service 410 may be exemplified for one or more partners from the member networks. The partner service 410 may be configured to perform one or more exchange operations to resolve exchange requests from the partner platform 420. In some embodiments, the exchange platform 102 exemplified a service provider service 412, which is a separate service provider-specific service for each of the member networks. Additional or alternative, for example in a multi-tenant environment, the service provider service 412 may be exemplified for one or more service providers from the member networks. The service provider service 412 may be configured to perform one or more exchange operations to acquire and resolve exchange requests from the partner platform 420. Exchange operations may include any of the steps and / or operations described herein.

[0179] In some embodiments, the partner service 410 and / or the service provider service 412 communicate information with each other and / or with one or more other components of the exchange platform 102 through one or more local communication mechanisms in order to perform exchange operations. For example, the exchange platform 102 may include an enablement service 408. The enablement service 408 may be configured to perform one or more enablement operations of the present disclosure in order to enable the UUEK. Thus, the exchange platform 102 can pre-process exchange requests and authorization credentials for exchange requests on behalf of the member platform in order to enforce the member policy 422 of the member platform.

[0180] Through the performance of one or more exchange operations, Partner Service 410 and / or Service Provider Service 412 may generate and utilize a number of unconventional identifiers for referring to users, service provider instruments, and / or one or more aspects of value exchange. At least some of these identifiers may include universally unique identifiers, such as UUEKs, which may be utilized to provide value credential-free exchanges. Each identifier may be stored at least temporarily in the platform data vault 414. The 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 individual parts of the platform data vault 414.

[0181] As described herein, one or more identifiers may be stored in association with each other to form an identifier mapping that can be utilized by the exchange platform 102 (and / or one or more of its services) to refer to users, service provider instruments, and / or any other aspect of value exchange from communications between the partner platform 420, the service provider platform 440, and / or any other member platform that does not include user credentials. Examples of unconventional identifiers will be described further herewith reference to Figure 5.

[0182] e. Exemplary data structure Figure 5 is an exemplary data diagram 500 for facilitating value credential-free exchange according to one or more embodiments of the present disclosure. Data diagram 500 illustrates several related identifiers of different types. As depicted, each identifier may be associated with at least one related 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 that references service provider instrument 518 without disclosing persistent credentials 514 (e.g., username, password, card number, etc.) associated with the service provider instrument 518, which are susceptible to fraud, abuse, and exploitation by malicious parties. Using some of the technology of the present disclosure as illustrated, persistent credentials 514 may not need to be communicated outside of service provider platform 440. Data Figure 500 illustrates only a fraction of the identifiers that may be generated, stored, and / or utilized by various embodiments of this disclosure. It will be understood that the exemplified identifiers are not exhaustive and may include other identifiers not exemplified. Each identifier may be labeled as an identifier, reference, key, and / or other similar term. These terms are used herein without distinction to refer to units of information for identifying data structures, entities, and / or any other components described herein.

[0183] As illustrated, some of the multiple related identifiers in various embodiments of the present disclosure may, for example, be: (i) one or more user references 502 which can be mapped to member user identifiers 522 of the service provider platform 440; (ii) one or more service provider partitions 504 corresponding to the network of an installed service provider platform, such as the service provider platform 440; (iii) one or more partner partitions 506 corresponding to the network of an installed partner platform; and (iv) member instrumentation of the service provider platform 440. (v) one or more instrument references 520 which can be mapped to instrument identifier 508, (v) one or more keys 516 and / or system identifiers 512 which can be associated with user reference 502 and / or instrument reference 520, (vi) one or more exchange identifiers 510 which can be mapped to either system identifier 512 and / or key 516, and / or (vii) one or more UUEKs 524 which can be mapped to at least one of exchange identifiers 510 and / or 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 refer to the service provider instrument 518, at least in part on identifiers that do not indicate any aspect of the service provider instrument 518, including the persistent credentials 514, by themselves.

[0185] For example, the service provider platform 440 may store, maintain, and / or otherwise access one or more keys 516 that are mapped to one or more system identifiers 512 of the exchange platform 102 (e.g., copies, derivatives, etc., of one or more system identifiers 512). A key 516 may, for example, include a system identifier 512 as part of the key 516. A key 516 may be mapped to a member instrument identifier 508 and / or a member user identifier 522 that may internally reference users and / or service provider instruments 518 of the service provider platform. A key 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, exchange platform 102 may store, maintain, and / or otherwise access one or more references, such as instrument reference 520 and / or user reference 502, which are mapped to one or more member identifiers (e.g., duplicates, derivatives, etc.) such as member instrument identifier 508 and / or member user identifier 522 of service provider platform 440. The references may be provided, for example, during the registration process between service provider platform 440 and / or 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, the entity partition is a unique identifier for a computing entity. The entity partition may include a unique number, alphanumeric character, and / or similar that represents a particular computing entity. The 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 similar.

[0188] In some embodiments, the service provider partition 504 is a unique identifier for the service provider and / or the service provider's service provider platform 440. The service provider partition 504 may include a series of numbers, alphanumeric characters, or any other characters or symbols representing a service provider associated with (e.g., installed, registered, etc.) the exchange platform 102. The exchange platform 102 may include multiple service provider partitions, each identifying a service provider platform 440 that is attached to (e.g., installed, registered, etc.) the exchange platform 102. Each service provider partition 504 may represent a service provider platform 440 comprising one or more exchange platform software development kits (SDKs) and / or similar for implementing the service provider interface of the exchange platform 102.

[0189] In some embodiments, the partner partition 506 is a unique identifier for the partner and / or the partner's partner platform. The partner partition 506 may include a series of numbers, alphanumeric characters, or any / or other characters or symbols representing the partner associated with the exchange platform 102. The exchange platform 102 may include multiple partner partitions, each identifying a partner platform that is attached to the exchange platform 102 (e.g., mounted, registered, etc.). Each partner partition 506 may represent a partner platform that constitutes one or more exchange SDKs and / or similar for implementing the partner interface of the exchange platform 102.

[0190] In some embodiments, entity partitions are generated to identify members when member platforms are installed on exchange platform 102. In some examples, after being installed on the exchange platform, member platforms can leverage one or more exchange interfaces to register one or more service provider instruments with exchange platform 102. Service provider instruments 518 may register with exchange platform 102 by exchanging one or more instrument identifiers with 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 disclosing the service provider instrument's persistent credentials 514. The instrument identifier may include a member instrument identifier 508, a system instrument identifier, an instrument reference 520, an instrument key, and / or similar, as described herein.

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

[0193] In some embodiments, the instrument reference 520 is a unique identifier for referencing the member instrument identifier 508. The instrument reference 520 may be generated and / or provided to the exchange platform 102 by the member platform, for example, to allow the exchange platform 102 to reference a service provider instrument 518 maintained on the member platform. In some examples, the instrument reference 520 is the same value as the member instrument identifier 508. In some examples, the instrument reference 520 is a different value mapped to the 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 a series of numbers, alphanumeric characters, or any other characters or symbols that represent the service provider instrument 518 to the exchange platform 102 without disclosing the service provider instrument 518's persistent credentials 514. 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, the 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 a 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 one or more of its APIs). The key format may include any number of characters, such as 50 or more. In some examples, the characters may be case-sensitive. A first part 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 a service provider partition 504. A second part 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 include one or more different parts, each of which may be arranged in any order.

[0196] In some embodiments, after being deployed on 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. Users may register with the exchange platform 102 by exchanging one or more user identifiers with the exchange platform 102. User identifiers may be used, for example, to generate, maintain, and / or update one or more user data objects that reflect users of the member platform and / or the exchange platform 102.

[0197] In some embodiments, a user data object is a data entity representing a user communicating with the member platform and / or exchange platform 102. The user may include entities (e.g., people, organizations, groups, etc.) engaged in value exchanges governed by the exchange platform 102. In some examples, the user may indirectly interact with the exchange platform 102 by creating user accounts for registered service providers, registering (and / or granting permission to register) service provider instruments 518, and / or similar actions. In some examples, the exchange platform 102 may function on behalf of the 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 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, one or more user identifiers and / or one or more user attributes may be at least partially based on the type of user data object. For example, a user may be represented as a member user data object in a member platform. Additionally or alternatively, a user may be independently represented by a system user data object in an exchange platform. In some examples, member user data objects and system user data objects 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 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 a different identifier.

[0199] In some embodiments, a member user data object is an internal representation of a user within a member platform, such as the service provider platform 440. A member instrument data object may include one or more user identifiers, such as a member user identifier 522, a user key from the exchange platform 102, and / or similar. Additionally or alternatively, a member user data object may include one or more user attributes. One or more user attributes may represent one or more contextual characteristics of the user. In some examples, a user attribute may represent one or more identifiable characteristics of the user. For example, a user attribute may represent the user's first name, last name, email, actual address (e.g., one or more of street, local, region, zip code, country, etc.), date of birth (e.g., birth date, age group, etc.), telephone number, and / or similar. In some examples, a user attribute may include encrypted, hashed, and / or otherwise secure representations of the user's identifiable characteristics. For example, a user attribute may include one or more hashed identifiers and / or similar 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 similar. Additionally or alternatively, the system user data object may include one or more user attributes, such as those described herein. For example, a member platform may register a user with the exchange platform 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 the user's hashed and / or encrypted identifier.

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

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

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

[0204] In some embodiments, the user reference 502 may also be a unique identifier for referring to the member user identifier 522. The user reference 502 may be generated and / or provided to the exchange platform 102 by the member platform, for example, so that the exchange platform 102 can refer to users 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, the user key is a unique identifier for referencing a system user identifier. The user key may be generated and / or provided by the exchange platform 102, for example, during the user 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 one or more of its APIs). The key format may include, for example, a first part of the characters (e.g., the first six characters) which may be reserved as a partition for identifying entities associated with the key (e.g., members). 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 part of the characters may identify the system user identifier.

[0206] As illustrated by Figure 5, keys 516, such as user and instrument keys described herein, may be shared across the exchange platform 102 and the service provider platform 440. In addition, 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 enable the exchange platform 102 to refer to the service provider instrument 518 without knowledge of the service provider instrument 518's persistent credentials 514 (e.g., card number). 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 key 516 and the reference may be provided to the service provider platform 440 in a redundant process that allows the service provider platform to verify that communication is provided by the exchange platform 102 (for example, an entity with access rights to a specific set of keys and references).

[0207] In some embodiments, the persistent credentials 514 for the service provider instrument 518 include highly confidential user and / or instrument credentials, such as card numbers, account numbers, subscription numbers, and / or similar, which could expose users, members, and / or intermediary entities to risk. The persistent credentials 514 may be generated, accessed, and / or otherwise provided to the user by the service provider platform 440 when the user applies for a new service provider instrument 518, is authorized to use the new service provider instrument 518, and / or is otherwise enabled to open the new service provider instrument 518. Conventionally, the persistent credentials 514 are then used by the user to initiate a value exchange using the service provider instrument. By doing so, the user is compelled to disclose highly confidential credentials directly linked to the service provider instrument 518 each time the service provider instrument 518 is used. The key 516, reference, and identifier mapping scheme of this disclosure overcomes these technical shortcomings.

[0208] In some examples, each identifier is interpretable not by the user, but by a computing platform such as the exchange platform 102 and / or the service provider platform 440. To allow the user to select the service provider instrument 518 while maintaining the enhanced security features of this disclosure, in some examples, the identifiers in Figure 5 may be further enhanced by instrument representations.

[0209] In some embodiments, the instrument representation (not depicted in Figure 5) is a unique identifier for representing the service provider instrument 518 to a user without exposing the persistent credentials 514 of the service provider instrument 518. The instrument representation may include a series of numbers, alphanumeric characters, or any other characters or symbols that visually represent the service provider instrument 518 only to entities that have 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 credentials 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 similar. As another example, in an information value system, an instrument representation may include a portion of a persistent credential 514 (e.g., one or more digits, alphanumeric characters, etc.), such as a subscription account and / or similar. For example, an instrument representation may include a derivative of a persistent credential 514, which may allow only entities with prior knowledge of the persistent credential 514 to use the instrument representation to identify the persistent credential 514. As yet another example, an instrument representation may include a nickname for the instrument, which is assigned and subsequently recognized by the user.

[0210] In some embodiments, the instrument representation may be provided to the exchange platform 102 (for example, during the registration process) instead of the persistent credentials 514. Thus, the exchange platform 102 can use the instrument representation to represent the service provider instrument 518 without having knowledge of the persistent credentials 514 from which the instrument representation may be derived. For example, unlike conventional network-based exchange platforms, the exchange platform 102 does not need to require the persistent credentials 514 corresponding to the service provider instrument 518 to implement the various computing tasks of this disclosure. This further allows the exchange platform 102 to operate more flexibly while storing previously unrecorded contextual data, reducing 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 ephemeral keys issued to member platforms to facilitate secure real-time value exchange. For example, exchange platform 102 can facilitate an additional layer of network and data security by implementing exchange identifiers 510 to represent aspects of value-based exchange. Some examples of exchange identifiers 510 may include service provider-specific exchange identifiers and / or partner-specific exchange identifiers. A service provider-specific exchange identifier may include an ephemeral unique exchange identifier that ephemerally represents a service provider instrument 518 and a service provider platform 440. A service provider-specific exchange identifier may, for example, be mapped to a system identifier 512 of a service provider instrument 518. A partner-specific exchange identifier may include an ephemeral unique exchange identifier that ephemerally represents a service provider instrument 518 and a partner platform. A partner-specific exchange identifier may, for example, be mapped to a key 516 of a service provider instrument 518 that can be used to identify a service provider platform 440. In some cases, such mappings can 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, one or more identifiers and / or one or more exchange attributes may be at least in part based on the type of exchange data object. For example, an exchange may be represented as a member exchange data object in a member platform. Additionally or alternatively, an exchange may be independently represented by a system exchange data object in the exchange platform 102. In some examples, member exchange data objects and system exchange data objects may include one or more of the same one or more identifiers and / or exchange attributes. For example, using some of the technology 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 role of the system exchange data object in a value-based exchange.

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

[0215] Additionally or alternatively, a system exchange data object may include a partner-specific exchange data object corresponding to a partner platform. A partner-specific exchange data object may include one or more identifiers, such as an exchange identifier 510, one or more keys 516 (e.g., an instrument key), UUEK 524, a member instrument reference (e.g., a partner-specific instrument reference), and / or similar. Additionally or alternatively, a partner-specific exchange data object may include one or more exchange attributes, such as an expiration date, currency (e.g., in the case of a financial value system), instrument type, and / or similar.

[0216] In some embodiments, the member exchange data object is an external representation of a value exchange mediated using the exchange platform 102. The member exchange data object 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 similar.

[0217] In some embodiments, the exchange identifier 510 is a unique identifier for value exchange using the exchange platform 102. The exchange identifier 510 may include a series of numbers, alphanumeric characters, 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 is registered with the exchange platform 102 and can be mapped (e.g., through a series of identifiers) to a user, a service provider instrument 518, and / or a member. 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 format standards, such as UUID v4, and / or similar. Therefore, while the exchange identifier 510 can be leveraged by the exchange platform 102 and / or member platforms for one or more functions, the same exchange identifier 510 becomes useless to an external 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 can be associated with the exchange platform 102. Therefore, even if the exchange identifier 510 is identified by a malicious party, the malicious party should still be required to impersonate the exchange platform 102 in order to use the exchange identifier 510. Moreover, the malicious party should have to update the settlement account to an account owned by the malicious party, among several other tasks, before the exchange identifier 510 can be used to their advantage. 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 transient nature of the exchange identifier 510, these tasks can become incredibly uneconomical.

[0218] In some examples, the exchange identifier 510 may be represented by a UUEK 524. For example, to facilitate credential-free exchanges, the exchange platform 102 may issue one or more UUEK 524s to one or more member platforms. As described herein, the UUEK 524 can eliminate the reliance on traditional persistent credentials 514 by identifying the mode of value exchange through previously mapped data entities.

[0219] In some embodiments, UUEK524 is an external representation of the exchange identifier 510, which can be issued (for example, instead of the exchange identifier 510) to external entities such as users, partner platforms, and / or service provider platforms, and / or similar, in order to initiate a value-based exchange using the exchange platform 102. To do so, UUEK524 can be generated and issued by the exchange platform 102 to external entities. Each UUEK524 may contain multiple values ​​(e.g., up to 50 characters and / or more, case-insensitive or insensitive) that represent one or more aspects of a value-based exchange. For example, the multiple values ​​may represent the exchange identifier 510, a partition (e.g., identifying the recipient of the UUEK524), an identifier type, and / or one or more flags. As an example, UUEK524 may contain a partner-specific UUEK and / or a service provider-specific UUEK. A partner-specific UUEK may be correlated with a partner-specific exchange data object, as described herein, and may include a partner partition 506, while a service provider-specific UUEK may be correlated with a service provider-specific exchange data object, and may include a service provider partition 504.

[0220] For example, a UUEK524 may be generated according to a key format. The key format may contain multiple characters, including, for example, more than 50 characters, and may be case-insensitive. The first part of the characters (for example, the first six characters) may be reserved as a partition to identify the recipient of the UUEK524. The partition may include, for example, a partner partition 506, a service provider partition 504, and / or any other member partition. For example, a UUEK524 may be issued in response to a request from an authorized member, such as an attached partner and / or service provider.

[0221] As an addition or alternative, at least one character of the key format (e.g., the seventh character) may identify the format of UUEK524. At least another character (e.g., the eighth character) may identify the type of UUEK524. In some examples, the second part of the character may identify the exchange identifier 510 (e.g., a group of 22 characters following the eighth character). The third part of the character may be reserved (e.g., a group of 20 characters following the first part of the character). Exemplary representations are provided below: ppppppFiGGGGGGGGGGGGGGGGGGGGrrrrrrrrrrrrrrrrrrrr Here, 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 × 10^84 unique sortings, which is more than the number of atoms in the known observable universe. This enables the on-demand generation and distribution of new UUEK524s without compromising the security of the underlying data to which the UUEK524 can be mapped, such as identifiers for users, instruments, and / or any other potentially confidential 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 similar entities registered with the exchange platform 102. A security code tuple 424 may also be a data entity that defines a correlation between a security code, a user, and one or more of the member platforms and / or service provider instruments. A security code tuple 424 may include a security code, a user, and, in some embodiments, data objects, records, and / or any other data structure (e.g., linked nodes) configured to represent an association between a member platform, a service provider instrument, or both. A security code tuple 424 may include one or more system identifiers 512, such as a security code reference, a user identifier, one or more member identifiers, one or more instrument identifiers, and / or similar entities, and / or context pairing data. Contextual pairing data may include one or more pairing attributes, such as one or more timing attributes. Timing attributes may indicate, for example, configuration time (e.g., the time when the security code tuple was set), expiration time (e.g., the time when the security code must be reset), and / or similar. As described herein, the security code tuple 424 may be utilized by the exchange platform 102 to identify the user's security code reference and to perform secure actions on behalf of the user (e.g., enabling the use of UUEK for exchange) at least in part on the basis of a comparison between the security code reference and the 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. A security code reference may include an internal representation of a user's security code (for example, for exchange platform 102).

[0224] In some embodiments, a security code is a data entity that defines a sequence of characters for verifying a user during information transmission, such as physical exchange, virtual exchange, registration, and / or similar. A security code may include a sequence of one or more distinct characters of dynamic length (e.g., 6 characters, 8 characters, etc.) that can be pre-set by the user and / or provided to the user. A security code may be provided later by the user to validate the user's presence for information transmission (e.g., by comparing a security code input with a security code reference, as described herein). The one or more distinct characters may include any number of alphanumeric characters, emojis, kanji, wingdings, and / or similar.

[0225] In some embodiments, the security code is a network-operated n-character PIN. As described herein, the security code may be managed as a service through a client device for (i) securely retrieving a UUEK, (ii) registering an instrument with the member platform, and / or (iii) enabling or disabling the use of a UUEK (and / or any other exchange credentials) before an exchange request. Thus, the security code may be deployed for any type of service provider instrument through the retrieval, registration, and / or activation or deactivation of the corresponding UUEK. By managing the security code at the network level, the likelihood of authorization denial due to an invalid PIN is eliminated, so members can benefit from faster exchanges. For example, a UUEK may be disabled until a security code is received to activate it. The exchange platform can 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 the security code in mind. This effectively reduces network traffic between members in a switching network, thereby reducing network congestion in conventional high-traffic communication systems.

[0226] In some embodiments, the security code corresponds to a user. For example, the security code may be pre-set by the user and / or provided to the user through communication with the exchange platform 102. For 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 direct communication with each member platform, such as the service provider platform 440, or without sharing the security code with each member platform. In some examples, the security code may be instrument-specific or member-specific. For example, each security code may be configured to retrieve and / or enable the UUEK of a particular member platform and / or the service provider instrument of a particular member platform. As an addition or alternative, each security code may be configured to register the member platform's account with the exchange network. For example, the exchange platform 102 can control the use of security code to perform one or more secure actions by using multiple security code tuples, each correlating the security code to a respective user, member platform, and / or service provider instrument.

[0227] V. Exemplary System Operation Figure 6 provides a process flow for facilitating network-operated security code for users according to one or more embodiments of the present disclosure. The process flow depicts a network process 600 for establishing network-operated security code for use in implementing secure information transfer between users and third parties. Process 600 can be leveraged to overcome the limited complexity of conventional PINs and the various limitations of conventional exchange systems that rely on limited PIN mechanisms that, as described herein, make network information transfer inadequately secure by the parties operating the PINs. Process 600 can be implemented by one or more computing devices, entities, and / or systems as described herein. For example, through various steps / operations of Process 600, an exchange platform can leverage various communication and enablement techniques to overcome various limitations of conventional mechanisms of network exchange by improving the operation of security code for securing network-based information transfer.

[0228] Figure 6 illustrates an exemplary process 600 for illustrative purposes. While the exemplary process 600 depicts a particular sequence of steps / actions, the sequence may be modified without departing from the scope of this disclosure. For example, some of the steps / actions described may be performed in parallel or in different sequences that do not substantially affect the functionality of process 600. In other examples, different components of an exemplary device or system performing process 600 may perform their functions substantially simultaneously or in their own sequences.

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

[0230] For example, a user may access a member application through a portal, such as a browser, web application, and / or similar, via a client device, as described herein. The user's browser, web application, mobile application, and / or similar may issue a communication session request to the member platform to fetch a platform connectivity widget from a content delivery network (CDN) and establish a security code session. In response to the request, the member platform may generate a communication session request for the exchange platform (e.g., its member services) (e.g., using one or more exchange interfaces). 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 in step / operation 604. For example, an exchange platform (e.g., its partner service, service provider, etc.) can receive security code requests through an established communication session with a member platform. For example, a security code management widget can provide a user with a user prompt about 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 the member application. Thus, 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 from a member of the exchange network to the exchange platform. A security code request may refer to a user's member user reference and, in some examples, a user's member instrument reference. For example, a security code request containing only a member user reference may be the default for all service provider instruments associated with the user, and can initiate security code tuple actions (e.g., one or more set, reset, and / or remove operations) on the security code that applies to all service provider instruments maintained by their respective member platforms for the user. Additionally or alternatively, a security code request containing both a member user reference and a member instrument reference can initiate security code tuple actions (e.g., one or more set, reset, and / or remove operations) on the security code that applies to specific service provider instruments maintained by their respective member platforms for the user. In addition to references, a security code request may include a code action attribute indicating a 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] Thus, the security code widget may be configured to communicate with the user to set, reset, and / or remove specific security codes, allowing the security code to be set, reset, and / or removed without direct communication with member platforms. This improves network security by providing a single access point, or exchange platform, to fix multiple different security codes across numerous different member platforms for a single user.

[0234] In some embodiments, process 600 includes activating a user in step / operation 606. For example, an exchange platform (e.g., its partner service, service provider, etc.) may activate a user by comparing a user reference from a security code request with a set of pre-registered user identifiers. A user may be activated if the user reference corresponds to a user identifier. If a user is activated, 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 activated.

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

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

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

[0238] Figures 7A–7C provide process flows for establishing secure cross-entity relationships according to one or more embodiments of the present disclosure. The process flows illustrate 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-free value exchange between two member platforms. Figures 7A–7C illustrate exemplary process 700 for illustrative purposes. While exemplary process 700 depicts a particular sequence of steps / actions, the sequence may be modified without departing from the scope of the present disclosure. For example, some of the steps / actions described may be performed in parallel or different sequences that do not substantially impact the functionality of process 700. In other examples, different components of an exemplary device or system performing process 700 may perform functions substantially simultaneously or in a particular sequence.

[0239] Various embodiments of Process 700 address the technical challenges of data security and efficiency in network-based exchanges in value exchanges between one or more computing entities. Conventional systems address these challenges using registration mechanisms that require users to expose highly confidential and persistent credentials to third-party registration services. These conventional registration services then activate the user's account ownership and provide persistent credentials to the partner platform for storage and subsequent processing. In doing so, user credentials are transmitted to and exposed to numerous different entities during the conventional registration process, ultimately increasing the risk of exposure to malicious parties during and after network communication. Various embodiments of Process 700 provide improved network communication, data encryption, and data management technologies to enable credential-free exchange registration capabilities that reduce the data security risks imposed by conventional processes.

[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 various steps / operations of Process 700, the exchange platform 102 can leverage credential-free registration techniques to overcome various limitations associated with conventional registration mechanisms by registering service provider instruments with the partner platform without accessing the service provider instruments' persistent credentials. In doing so, the highly confidential information underlying the service provider instruments for engaging in value exchange is never exposed to potentially malicious parties or partner platforms that may be vulnerable to network-based attacks. For example, unlike prior art, the exchange platform 102 never receives user-identifiable or actionable account information, while service providers managing accounts are engaged in the registration process rather than being excluded by potentially insecure registration services. This further eliminates the need to implement resource data governance standards across each device involved in the registration process, resulting in improved computing resource utilization while ultimately enhancing network and data security.

[0241] Figure 7A is a flowchart illustrating an example of the first stage of a registration process 700 for registering a user on an exchange platform without disclosing persistent credentials associated with the user and / or service provider instrument. The flowchart depicts a communication technique for overcoming various limitations of conventional registration systems by bypassing the conventional system's reliance on confidential and persistent credentials. The communication technique 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 the user through a partner application.

[0242] In some embodiments, process 700 includes establishing registration sessions for the user and partner platform in step / operation 702. For example, the 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 allow the user to register their partner account on the partner application with the exchange platform to facilitate access to service provider instruments. The partner platform may enable user registration by initiating a registration session with the exchange platform.

[0243] For example, a user can access a partner application through a portal, such as a browser, web application, and / or similar, via a client device, as described herein. The user's browser, web application, mobile application, and / or similar can issue a communication session request to the partner platform, requesting that it fetch a platform connection widget from a Content Delivery Network (CDN) and establish a registration session. In response to the request, the partner platform can generate a communication session request to the exchange platform (e.g., its partner services) (e.g., using one or more exchange interfaces). The communication session request may include an API request, provided through the partner interface, requesting that the registration widget be initiated to establish a registration session for the user.

[0244] In some embodiments, a communication session request includes one or more registration attributes, such as user data, a user identifier, a user hash, a timestamp, a device identifier, a partner identifier, and / or similar. As described herein, some of the technologies of this 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 retrieve a user's user data (e.g., through user input to a user interface screen, pre-recorded data from a partner account, etc.) and provide the user data to the exchange platform to initiate the registration process. In some examples, user data may be provided by the partner platform (e.g., through one or more API calls to the 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, user data may be encrypted, hashed, and / or similar before being transmitted to the exchange platform. In some examples, user data may include one or more user attributes, as described herein.

[0245] In some embodiments, the exchange platform (e.g., its partner service) receives a communication session request using the partner interface, requesting that a registration session be initialized on the user's client device. In some examples, the communication session request may include the user's user data. Additionally or alternatively, the registration initialization request may include one or more user attributes of 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 in step / operation 704. For example, an exchange platform (e.g., its connection service, partner service, etc.) can identify and / or generate user and / or partner data from data provided in a communication session request. In some examples, user data may include one or more user attributes. In some examples, user data may include one or more encrypted and / or hashed user attributes. In some examples, partner data may include a shared identifier between the exchange platform and a partner platform, such as a partner partition, as described herein.

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

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

[0249] For example, an exchange platform can determine one or more service provider platforms based at least partially on the user attributes of a registration session and match the service provider list to one or more service provider platforms. As an example, an exchange platform may include multiple system user data objects and / or system instrument data objects, as described herein. In some examples, the exchange platform can identify one or more system user data objects corresponding to a user based on user attributes. In some examples, each system user data object can identify the service provider platform associated with the user. Thus, an exchange platform can determine one or more service providers associated with a user based on one or more system user data objects.

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

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

[0252] Next, the registration process 700 can proceed to a second stage, in which an instrument identifier corresponding to the user is identified through information exchange between the exchange platform, the user, and the service provider platform, as will be described in more detail with reference to Figure 7B.

[0253] Referring here to Figure 7B, Figure 7B is a flowchart illustrating an example of the 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 service provider instrument. The flowchart depicts a communication technique for overcoming various limitations of conventional registration systems by bypassing the conventional system's reliance on persistent credentials, such as card numbers and / or similar, provided by the user. The communication technique may be performed by one or more computing devices, entities, and / or systems described herein, such as a switching platform, for establishing a connection between the user, the partner platform, and the service provider instrument.

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

[0255] In response to a request, the exchange platform (e.g., its connection service, partner service, etc.) may receive service provider instrument data that is at least partially based on pre-selected data. The service provider instrument data may indicate one or more service provider instruments of the user, 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] As an addition or alternative, an exchange platform (e.g., one or more of its service provider services) may provide instrument requests for service provider instrument data from a selected service provider platform (e.g., via a service provider interface). An instrument request may include, for example, a user reference corresponding to a member user identifier of the service provider platform. In response to a request, the service provider platform may identify one or more member instrument data objects containing member user identifiers, identify one or more instrument references corresponding to one or more member instrument data objects, and provide the service provider instrument data to the exchange platform, indicating one or more instrument references and / or one or more corresponding instrument representations.

[0257] An exchange platform (e.g., its connection service, partner service, etc.) may initiate the presentation of an instrument registration screen via a user's client device, at least partially based on service provider instrument data, using a partner interface and via a registration user interface. The instrument registration screen may be defined internally 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. As an example, the instrument registration screen may show each of the instrument representations of one or more service provider instruments. In some examples, for example, when the user is associated with a single service provider instrument, the instrument registration screen may include a confirmation prompt to confirm the user's intention to register the service provider instrument.

[0258] In some embodiments, process 700 includes receiving a secure information transmission request in step / operation 712. For example, an exchange platform may receive a secure information transmission request from a member platform using a member interface. In some embodiments, a secure information transmission request is a data entity that defines a request for secure information transmission using a security code input. A secure information transmission request may be provided to the exchange platform from a member of the exchange network. A secure information transmission request may indicate (i) a user, a member platform, and / or a service provider instrument, and (ii) the user's security code input. In some examples, a secure information transmission request may indicate a service-provided instrument selected by the user from a list of service provider instruments.

[0259] In some examples, a secure information transfer request may include one or more contextual security attributes. One or more contextual security attributes may include one or more timing attributes. One or more timing attributes may include, for example, delivery time (e.g., indicating the time when the secure information transfer request is sent), request time (e.g., the time when it is requested to perform the secure information transfer), and / or similar.

[0260] Secure information transmission requests can be received from member platforms. For example, a user can initiate a secure information transmission request through a member application hosted by a member platform on behalf of a member of the exchange network. In some examples, a secure information transmission request may be generated and / or provided in response to a selection input indicating a service provider instrument, the service provider instrument's UUEK, and / or similar. As one example, a user can select an instrument representation, UUEK representation, and / or similar (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, grant it authorization for value-based exchange, and / or similar. In some examples, a secure information transmission request may be initiated automatically if the user and / or the selected instrument, UUEK, and / or similar are associated with security code. For example, in response to a selection, the member platform (e.g., through its respective member application) may prompt the user to enter a security code. The user may then enter the security code to provide a secure information transfer request.

[0261] In some examples, the exchange platform can use a partner interface to receive secure information transfer requests from client-side widgets. These requests may include selection data and / or security code input. The selection data may indicate a selection of service provider instruments from a registration user interface. For example, the selection data may indicate the instrument representation of the selected service provider instrument (e.g., an account nickname). In some examples, the selection data may include at least one of the following: an instrument type, a currency type (e.g., in a financial value system), and / or an instrument identifier (e.g., an instrument representation).

[0262] In some embodiments, process 700 includes verifying a security code input for a secure information transmission request in step / operation 714. In some examples, the exchange platform (e.g., its connection service, partner service, etc.) may compare the security code input to a security code tuple corresponding to the secure information transmission request in order to verify the presence of the user. The exchange platform may generate an enable event indicating the validation and / or non-validation of the security code input. If validated, process 700 may proceed to step / operation 718, where the exchange platform provides a valid secure information transmission response. If non-validated, the exchange platform may proceed to step / operation 716, where the exchange platform provides an invalid secure information transmission response and then returns to step / operation 712 to receive another secure information transmission request.

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

[0264] In some embodiments, enablement events are stored in association with secure data entities such as UUEKs, service provider instruments, and / or users. For example, enablement events may be stored in exchange data objects corresponding to UUEKs, system instrument data objects corresponding to service provider instruments, system user data objects corresponding to users, and / or similar. Additionally or alternatively, enablement events may be stored in association with security code tuples. For example, secure events may be stored in response to enabling a user, while insecure events may be stored in response to disabling a user.

[0265] In some embodiments, the activation event includes contextual activation data. Contextual activation data may, for example, indicate the timing of activation. The timing of activation may include timestamps corresponding to the sending, receiving, creation, and / or ruling of the activation request. For example, contextual activation data may include an activation timestamp indicating the time when the exchange platform determined whether a security code entry and security code reference matched or not. In some examples, contextual activation data may indicate a secure period. The secure period may indicate a subsequent timestamp, time duration, and / or similar, during which the UUEK, service provider instrument, and / or similar can be secured in response to a secure event.

[0266] In some embodiments, process 700 includes providing a valid secure information transmission response to a partner platform in step / operation 718. For example, an exchange platform may provide a valid secure information transmission response to a partner platform. A secure information transmission response can define a response to a secure information transmission request. In some embodiments, a secure information transmission response is provided by the exchange platform to the member that provided the secure information transmission request. A secure information transmission response may indicate an activation event. A valid secure information transmission response may indicate a successful activation event.

[0267] In some embodiments, process 700 includes, in step / operation 720, providing a registration request to the service provider platform corresponding to a service provider instrument in response to the user's network-level activation. For example, a switching platform (e.g., its service provider service) may use a service provider interface to provide a registration request to the service provider platform corresponding to a selected service provider instrument. The registration request may 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 may verify the service provider instrument using one or more identifiers.

[0268] Service provider registration data may include one or more identifiers for referencing service provider instruments without using persistent credentials (e.g., card number, account number, etc.) for service provider instruments during communication between the exchange platform, the service provider platform, and / or partner platforms. One or more identifiers may include various combinations of user identifiers and / or instrument identifiers for enabling users and / or instruments through one or more redundant checks. For example, a user identifier for a user may include a user reference on 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 on the service provider platform and / or an instrument key from the exchange platform corresponding to the instrument reference.

[0269] Service provider registration data may include any combination of references, keys, and / or identifiers as described herein. In one example, service provider registration data may include one of the following: instrument reference, instrument key, user reference, and / or user key. Additional or alternative, service provider registration data may include corresponding combinations of instrument reference, instrument key, user reference, and user key 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 the communication scheme. Thus, a particular combination of identifiers provided in a registration request may be used as an additional verification check to ensure that the registration request is received from an associated platform, such as an exchange platform.

[0270] A service provider can compare an identifier from a registration request with one or more member data objects (e.g., a member instrument data object, a member user data object, etc.) to identify a service provider instrument that responds to a registration request without disclosing the persistent credentials of the service provider instrument.

[0271] Referring here to Figure 7C, Figure 7C is a flowchart illustrating an example of the third stage of the registration process 700 for issuing a UUEK to facilitate value credential-free exchange. The flowchart depicts communication techniques to overcome various limitations of conventional registration systems by bypassing the conventional system's reliance on instrument references, such as card numbers and / or similar, 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 a user instrument record for registering the user on the exchange platform.

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

[0273] In some embodiments, process 700 includes determining in step / operation 724 whether the service provider instrument has been successfully registered. If the service provider instrument has been 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 step / operation 728 in response to successful registration. For example, an exchange platform may generate a UUEK in response to activation of users and / or instruments by an exchange network (e.g., using security codes) and / or a service provider platform. As an example, an exchange platform may generate UUEKs corresponding to users, service provider instruments, and partner platforms. The exchange platform may store the UUEK in a partner-specific exchange data object that associates the UUEK with an exchange identifier, instrument key, and partner-specific instrument reference, as described herein.

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

[0276] Figures 8A and 8B provide process flows for facilitating secure, credential-free information transfer according to one or more embodiments of the present disclosure. The process flows depict a network process 800 for establishing a network-operated UUEK to securely verify the presence of a user for value exchange. Process 800 can be leveraged to overcome various limitations of conventional exchange systems, which rely on limited PIN mechanisms that expose confidential and persistent credentials to numerous third parties, making value-based exchanges inadequately secure, as described herein. Process 800 can be implemented by one or more computing devices, entities, and / or systems as described herein. For example, through various steps / operations of Process 800, an exchange platform can leverage various communication and enablement technologies to overcome various limitations of conventional exchange mechanisms by improving the operation of security code to secure network-based exchanges.

[0277] Figures 8A and 8B illustrate an exemplary process 800 for illustrative purposes. While the exemplary process 800 depicts a particular sequence of steps / actions, the sequence may be modified without departing from the scope of this disclosure. For example, some of the steps / actions described may be performed in parallel or in different sequences that do not substantially affect the functionality of process 800. In other examples, different components of an exemplary device or system performing process 800 may perform their functions substantially simultaneously or in a particular sequence.

[0278] In some examples, process 800 may begin after a registration and / or security code process, such as process 600, where the user may manage network-operated security code to facilitate secure credential-free 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 UUEKs to the registered service provider platforms to initiate value-based exchanges using the registered service provider instruments without referring to the service provider instruments' persistent credentials. Additionally or alternatively, a registration process may be performed to register registered service provider instruments maintained by the service provider platforms with the partner platform. In some examples, the exchange platform may generate and issue UUEKs to the partner platform to facilitate the registration process and, in response to successful registration, to initiate future value-based exchanges. In some cases, upon registration, users can establish network-operated security codes with the exchange platform to facilitate the execution of UUEKs and / or to activate pre-issued UUEKs.

[0279] Thus, using some of the communication technologies of this disclosure, a member platform can enhance the security of a UUEK by establishing one or more security codes for a user. For example, by replacing the persistent credentials of a service provider instrument with a UUEK, the communication technologies of this disclosure can manage access to a service provider instrument by issuing new UUEKs and / or activating or deactivating pre-issued UUEKs to enforce the measure on behalf of the member. In some examples, this includes mandating the use of security codes to verify the presence of a user for secure information transfer. For example, using some of the technologies of this disclosure, an exchange platform can function as an arbitration engine to verify the presence of a user before issuing a UUEK and / or activate pre-issued UUEKs on behalf of the member platform. According to the steps / operations of process 800, the exchange platform can enforce a user's security code, service provider instrument, and / or its UUEK, which can be leveraged to enforce member policies on behalf of the member platform, even without ongoing involvement from the member platform. Thus, network-operated security code can be established that extends the security provided by UUEK in credential-free exchanges.

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

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

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

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

[0284] If security code input is valid, process 800 can proceed to step / operation 808, where a secure event is logged. If security code input is invalid (for example, one or more characters do not match the security code reference), process 800 can proceed to step / operation 810, where a non-secure event is logged.

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

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

[0287] In some embodiments, enablement events are stored in association with secure data entities such as UUEKs, service provider instruments, and / or users. For example, enablement events may be stored in exchange data objects corresponding to UUEKs, system instrument data objects corresponding to service provider instruments, system user data objects corresponding to users, and / or similar. Additionally or alternatively, enablement events may be stored in association with security code tuples. For example, secure events may be stored in response to enabling a user, while insecure events may be stored in response to disabling a user.

[0288] In some embodiments, the activation event includes contextual activation data. Contextual activation data may, for example, indicate the timing of activation. The timing of activation may include timestamps corresponding to the sending, receiving, creation, and / or ruling of the activation request. For example, contextual activation data may include an activation timestamp indicating the time when the exchange platform determined whether a security code entry and security code reference matched or not. In some examples, contextual activation data may indicate a secure period. The secure period may indicate a subsequent timestamp, time duration, and / or similar, during which the UUEK, service provider instrument, and / or similar can be secured in response to a secure event.

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

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

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

[0292] In some examples, security code input may correspond to a user's pre-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 can then generate and issue UUEKs to the registered service provider platforms to initiate value-based exchanges using the registered service provider instruments without referring to the service provider instruments' persistent credentials. Additionally or alternatively, registration processes may be performed to register registered service provider instruments maintained by the service provider platforms with the partner platform. In some examples, the exchange platform can facilitate a security code registration process for issued UUEKs to generate a security code tuple. Once the security code tuple has been generated for the UUEK, the exchange platform can perform one or more steps / actions of process 800 to enable and / or disable the UUEK on behalf of the member platform. Thus, network-operated security code can be provided that proactively prevents the use of UUEK for invalid exchanges.

[0293] In some embodiments, the information transmission request may include an enable request to activate a user's pre-issued UUEK. In such cases, the secure information transmission request may indicate the UUEK, the security code input for the UUEK, and / or one or more contextual security attributes, such as the delivery time (e.g., indicating the time the secure information transmission request was sent), the request time (e.g., the time requested to enable the use of the UUEK), and / or similar.

[0294] In some cases, a secure information transmission 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 grant authorization for value-based exchange. In some cases, a secure information transmission request may be initiated automatically if the selected UUEK is an invalid UUEK. For example, in response to the selection, a member platform (e.g., through its respective member application) may prompt the user to enter a security code. The user may enter a security code to provide a secure information transmission 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 that is viewable by the user. The UUEK representation may be represented in one or more different forms, such as a machine-readable optical image (e.g., a barcode, 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, QR code, non-fungible token, near-field communication sequence, etc.). The scannable representation may be stored in a member account on the member platform to enable the user to perform value-based exchanges using the service provider instrument without referring to persistent credentials for the service provider instrument. The UUEK representation may be scanned 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, an invalid UUEK representation is a UUEK representation of an invalid UUEK. An invalid UUEK representation may include a status indicator and / or one or more other indicators that represent the invalidated status of the UUEK. In some examples, an invalid UUEK representation may include an illegible UUEK representation. An illegible UUEK representation may include a scannable representation that is, for example, grayed out, obscured, partially covered, and / or similar, preventing the scannable representation from being read.

[0297] In some cases, a secure information transmission response can initiate the activation of a UUEK. An activated UUEK may be associated with, for example, an activated UUEK representation. An activated UUEK representation may include status indicators and / or one or more other indicators that represent the activated status of the UUEK. In some cases, an activated UUEK representation may include a readable UUEK representation.

[0298] Moving to Figure 8B, in response to a secure event, process 800 includes receiving an exchange request accompanied by a UUEK (issued, for example, through secure information transfer) in step / operation 816. For example, an exchange platform may receive an exchange request to perform a value-based exchange. The exchange request may include a UUEK and / or one or more exchange attributes. In some examples, the exchange request may depend on prior secure information transfer. For example, the UUEK may be issued and / or enabled through secure information transfer. Thus, the request may be filtered before it is sent to the exchange platform, and also by the exchange platform before it is sent to another member platform. In this way, the exchange request may be minimized to a pre-enabled exchange, which can reduce network congestion between a large number of parties in a high-traffic exchange network.

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

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

[0301] In some embodiments, process 800 includes determining in step / operation 820 whether activation is required for an exchange request. For example, an exchange platform (e.g., its activation service) may determine whether activation is required for an 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. For 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, an exchange request may indicate one or more exchange attributes. One or more activation requirements may correspond to one or more exchange attributes. The exchange platform (e.g., its activation service) may compare one or more exchange attributes with one or more activation requirements to determine whether activation is required for the UUEK of an exchange request.

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

[0303] As another example, 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, if an exchange request includes one or more exchange attributes that identify at least one of the one or more objects, activation may be required for the exchange request.

[0304] In some embodiments, process 800 includes determining, in step / operation 822, whether the UUEK is enabled. For example, an exchange platform (e.g., its partner service, service provider service, etc.) can determine that the UUEK is enabled (or disabled) based at least in part on a membership policy, an exchange request, and / or one or more activation events (e.g., secure events, non-secure events, etc.) associated with the UUEK. As an example, the exchange platform can determine whether the UUEK is enabled based at least in part on the presence of secure events, non-secure events, and / or one or more of its timing attributes.

[0305] In some embodiments, the exchange platform determines whether a UUEK should be enabled based at least partially on the most recent time attribute of multiple activation events. For example, a UUEK may be enabled if a secure event follows any non-secure event. Additionally or alternatively, the exchange platform determines whether a UUEK should be enabled based at least partially on a comparison between a secure period for an exchange request and a time (e.g., reception time, response time, processing time, etc.). For example, a UUEK may be enabled if a time such as the reception time of an exchange request falls within the enabled period.

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

[0307] For example, an exchange platform (e.g., its service provider service) can request exchange authorization from the service provider platform for service provider instruments correlated with the UUEK. In some examples, an exchange platform (e.g., its partner service) can identify member platforms at least partially based on the UUEK (e.g., its entity partition). Alternatively, an exchange platform (e.g., its service provider service) can identify service provider instruments at least partially based on the UUEK (e.g., its exchange identifier).

[0308] An exchange platform (for example, its service provider service) can use a service provider interface to provide an exchange authorization request to a member platform. An exchange authorization request may include at least one of the following: one or more request attributes, an instrument identifier for a service provider instrument, and / or a secure event. For example, an exchange platform may generate an exchange authorization request based at least partially on a system instrument data object identified from one or more aspects of the UUEK. The exchange authorization request may include an instrument key and / or instrument reference from the system instrument data object.

[0309] In some examples, an exchange authorization request may indicate a user identifier associated with a service provider instrument. For example, an exchange platform may generate an 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, a system user data object may be identified at least in part on the user identifier of an exchange data object (e.g., a system user identifier). Additionally or alternatively, a system user data object may be identified at least in part on the user identifier of a system instrument data object (e.g., a system user identifier). In some examples, an exchange authorization request may include a user key and / or user reference from a system user data object.

[0310] Alternatively, an exchange authorization request may include an exchange identifier. For example, an exchange platform may generate an exchange identifier to represent a value-based exchange and provide the exchange identifier to a member platform.

[0311] In some embodiments, process 800 includes receiving an exchange authorization response in step / operation 826. For example, an exchange platform (e.g., its partner service, service provider service, etc.) may receive an exchange authorization response indicating at least one of exchange approval and / or exchange rejection. 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 exchange authorization response is based at least partially on the secure event. For example, the exchange authorization response may be based at least partially on the secure event, the time the exchange request was received, the member policy, and / or similar factors.

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

[0314] In some examples, an exchange authorization response may include one or more response attributes. These response attributes may include one or more error codes and / or similar to characterize the exchange authorization response.

[0315] The exchange platform can generate an exchange record for a value-based exchange, at least partially based on the exchange authorization request and / or exchange authorization response. In some examples, the exchange record may include an exchange identifier, one or more exchange attributes, one or more response attributes, an exchange authorization response, one or more instrument and / or user identifiers, and / or any other data relating to the value-based exchange. In some examples, the exchange platform can store the exchange record in a platform data vault, associated with one or more instrument and / or user identifiers.

[0316] In some embodiments, process 800 includes providing an exchange response in step / operation 828. For example, an exchange platform (e.g., its partner service, service provider service, etc.) may provide an exchange response based at least in part on an 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 rejection.

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

[0318] Figures 9A–9D provide exemplary user interface flows configured for a client device 104. The user interface may be configured to guide the user through a credential-free exchange process to facilitate value-based exchanges between one or more member platforms without disclosing confidential and persistent credentials of service provider instruments used to perform value-based exchanges. The credential-free exchange process can be initiated when the user selects a payment method from the exchange processing screen 902 of the partner application, as shown in Figure 9A. Upon selecting a payment method facilitated by the exchange platform, the user may transition to an instrument selection screen 904, as shown in Figure 9B. The instrument selection screen 904 may include a plurality of selectable instrument icons 906, each of which may accompany a UUEK issued by the exchange platform using the various technologies described herein. The user can perform an exchange by selecting one or more of the selectable instrument icons 906.

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

[0320] VI. Conclusion Those skilled in the art will likely envision numerous modifications and other embodiments that benefit from the teachings presented in the foregoing description and accompanying drawings. Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Certain terms are used herein, but these terms are used only in a general and descriptive sense and not for limitation.

Claims

1. The process involves one or more processors receiving a secure information transmission request indicating a security code input and a user identifier, The steps include: identifying a security code tuple for security code input based on the user identifier using one or more processors; The steps include: enabling the security code input by one or more processors, at least in part, based on a comparison between the security code input and the security code reference of the security code tuple; In accordance with the step of enabling the aforementioned security code input, (i) one or more processors store a secure event for the user indicating that the security code input matches the security code reference and is valid in the comparison, and (ii) A step of providing a secure information transmission response indicating the secure event by one or more processors, wherein the secure information transmission response indicates at least one of the following: (a) a universally unique ephemeral key (UUEK), or (b) a secure event associated with the UUEK indicating that the UUEK is enabled. The steps include: receiving an exchange request from a client device, which includes the UUEK, for performing a value-based exchange using one or more processors; A step of providing the member platform with an exchange authorization request that defines a request for the member platform to perform the value-based exchange, wherein the exchange authorization request includes an instrument identifier indicating a service provider instrument used to provide value and a secure event associated with the UUEK, and causes the member platform to identify the service provider instrument using the instrument identifier, and to determine whether to approve or reject the exchange by comparing the asset availability of the identified service provider instrument with the exchange value related to the value-based exchange. A step of receiving an exchange authorization response from one or more processors indicating at least one of the exchange authorization or the exchange denial, wherein the exchange authorization response is at least partially based on a secure event associated with the UUEK. A computer execution method, including...

2. The secure information transmission request is received using the partner interface corresponding to the partner platform in response to a selection input to an invalid UUEK representation corresponding to the UUEK. The computer execution method according to claim 1.

3. (i) The invalid UUEK representation is presented for display through the user interface, (ii) In response to the secure information transmission response, the exchange interface is modified to present a valid UUEK representation. The computer execution method according to claim 2.

4. (i) the member platform is a service provider platform, (ii) the exchange request is received from a partner platform different from the service provider platform using a partner interface, (iii) the exchange authorization request is provided to the service provider platform using a service provider interface, and (iv) the exchange authorization response is received from the service provider platform using a service provider interface. The aforementioned computer execution method A step of providing an exchange response based at least in part on the exchange authorization response using the partner interface, wherein the exchange response indicates the exchange approval or the exchange rejection. The computer execution method according to claim 1, further comprising:

5. The security code reference comprises an n-character sequence of one or more distinct characters. The computer execution method according to claim 1.

6. The aforementioned one or more different characters comprise one or more alphanumeric characters, The computer execution method according to claim 5.

7. The security code tuple comprises the security code reference and the user identifier, and is pre-generated in response to a security code request from the member platform. The computer execution method according to claim 1.

8. The secure event associated with the UUEK is associated with a secure period, and the exchange authorization response is at least partially based on the secure event associated with the UUEK and the time of receipt of the exchange request. The computer execution method according to claim 1.

9. The member platform is associated with a member policy that defines one or more activation requirements for the service provider instrument. The aforementioned computer execution method A step of determining that the UUEK included in the exchange request is enabled, at least in part, based on the member policy, the exchange request, and the secure event associated with the UUEK. A computer execution method according to claim 1, including the method described in claim 1.

10. The exchange request indicates one or more exchange attributes, and the one or more activation requirements correspond to the one or more exchange attributes. The computer execution method according to claim 9.

11. The one or more exchange attributes indicate an exchange value, and the one or more activation requirements define an exchange value threshold for which a secure event associated with each of the UUEKs is required for the service provider instrument. The computer execution method according to claim 10.

12. A computing system comprising memory and one or more processors communicatively coupled to the memory, wherein the one or more processors Receiving a secure information transmission request that includes a security code input and a user identifier, Based on the user identifier, identify the security code tuple for security code input, Activating the security code input based at least partially on a comparison between the security code input and the security code reference of the security code tuple, In response to enabling the aforementioned security code input, (i) In the comparison, store a secure event for the user indicating that the security code input matches the security code reference and is valid, and (ii) Providing a secure information transmission response indicating the secure event, wherein the secure information transmission response indicates at least one of (a) a universally unique ephemeral key (UUEK), or (b) a secure event associated with the UUEK indicating that the UUEK is activated. An exchange request for performing a value-based exchange, which includes receiving the exchange request containing the UUEK from a client device, Providing the member platform with an exchange authorization request that defines a request for the member platform to perform the value-based exchange, wherein the exchange authorization request includes an instrument identifier indicating a service provider instrument used to provide value and a secure event associated with the UUEK, and provides the member platform with the member platform to identify the service provider instrument using the instrument identifier, and to determine whether to approve or reject the exchange by comparing the asset availability of the identified service provider instrument with the exchange value related to the value-based exchange. Receiving an exchange authorization response indicating at least one of the exchange approval or the exchange denial, wherein the exchange authorization response is at least partially based on a secure event associated with the UUEK. A computing system configured to perform the following actions.

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

14. (i) The invalid UUEK representation is presented for display through the user interface, (ii) In response to the secure information transmission response, the exchange interface is modified to present a valid UUEK representation. The computing system according to claim 13.

15. (i) the member platform is a service provider platform, (ii) the exchange request is received from a partner platform different from the service provider platform using a partner interface, (iii) the exchange authorization request is provided to the service provider platform using a service provider interface, and (iv) the exchange authorization response is received from the service provider platform using a service provider interface. The one or more processors described above are To provide an exchange response using the partner interface, which is at least partially based on the exchange authorization response, wherein the exchange response indicates the exchange approval or the exchange rejection. Configured to do the following: The computing system according to claim 12.

16. The secure event associated with the UUEK is associated with a secure period, and the exchange authorization response is at least partially based on the secure event associated with the UUEK and the time of receipt of the exchange request. The computing system according to claim 12.

17. When executed by one or more processors, Receiving a secure information transmission request that includes a security code input and a user identifier, Based on the user identifier, identify the security code tuple for security code input, Activating the security code input based at least partially on a comparison between the security code input and the security code reference of the security code tuple, In response to enabling the aforementioned security code input, (i) In the comparison, store a secure event for the user indicating that the security code input matches the security code reference and is valid, and (ii) Providing a secure information transmission response indicating the secure event, wherein the secure information transmission response indicates at least one of (a) a universally unique ephemeral key (UUEK), or (b) a secure event associated with the UUEK indicating that the UUEK is activated. An exchange request for performing a value-based exchange, which includes receiving the exchange request containing the UUEK from a client device, Providing the member platform with an exchange authorization request that defines a request for the member platform to perform the value-based exchange, wherein the exchange authorization request includes an instrument identifier indicating a service provider instrument used to provide value and a secure event associated with the UUEK, and provides the member platform with the member platform to identify the service provider instrument using the instrument identifier, and to determine whether to approve or reject the exchange by comparing the asset availability of the identified service provider instrument with the exchange value related to the value-based exchange. Receiving an exchange authorization response indicating at least one of the exchange approval or the exchange denial, wherein the exchange authorization response is at least partially based on a secure event associated with the UUEK. The instruction includes causing one or more processors to perform the following: One or more non-temporary computer-readable storage media.

18. The security code reference comprises an n-character sequence of one or more distinct characters, where each of the one or more distinct characters comprises one or more alphanumeric characters. One or more non-temporary computer-readable storage media according to claim 17.