WO2019200169A1 - Système et procédé de distribution de commerce électronique multi-plateforme sans tête - Google Patents

Système et procédé de distribution de commerce électronique multi-plateforme sans tête Download PDF

Info

Publication number
WO2019200169A1
WO2019200169A1 PCT/US2019/027086 US2019027086W WO2019200169A1 WO 2019200169 A1 WO2019200169 A1 WO 2019200169A1 US 2019027086 W US2019027086 W US 2019027086W WO 2019200169 A1 WO2019200169 A1 WO 2019200169A1
Authority
WO
WIPO (PCT)
Prior art keywords
product
commerce
platform
order
merchant
Prior art date
Application number
PCT/US2019/027086
Other languages
English (en)
Inventor
Brandon SCHULZ
Rhen Zabel
Original Assignee
Violet.io, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/952,974 external-priority patent/US11049160B2/en
Priority claimed from US15/953,071 external-priority patent/US20190318337A1/en
Priority claimed from US15/952,978 external-priority patent/US20190318402A1/en
Priority claimed from US15/953,068 external-priority patent/US11055757B2/en
Priority claimed from US15/953,059 external-priority patent/US20190318413A1/en
Application filed by Violet.io, Inc. filed Critical Violet.io, Inc.
Publication of WO2019200169A1 publication Critical patent/WO2019200169A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present disclosure generally relates to e-commerce systems and methods, and particularly, to headless multi-platform e-commerce distribution systems and methods.
  • e-commerce electronic commerce
  • apps smart phone or other portable computing device
  • a website or mobile app may be the presentation layer of the e-commerce “front end.”
  • this e-commerce“front end” incorporates manual user input (e.g., typing interface, touchscreen, mouse, and the like).
  • e-commerce“front ends” that enable voice interaction for e-commerce purchases (e.g., Amazon or Google Home).
  • E-commerce platforms were a significant advancement in the world of commerce because they allowed people to exchange goods and services using the Internet.
  • the rapid growth and limited front end capabilities of these e-commerce platforms have resulted in highly siloed and ocified e-commerce systems that only function for within specific parameters.
  • these e-commerce platforms store product information, and surface almost exclusively in the form of a website or mobile application to facilitate a transaction.
  • a merchant is a company that sells a product on-line in some manner (/. e. , an on-line store owner). Almost all on-line commerce is conducted through the e-commerce platforms described above. Typically, a merchant sells several different products. The merchant uploads the necessary product information into the e-commerce platform, and the product information is published to the merchant’s website. For example, a company like NIKE (for the sake of example) would be considered a merchant. The XYZ company might use an e-commerce platform, such as Magento, to manage their products. In this manner, XYZ uploads the necessary product information to Magento, and the product information is published to the XYZ’s website. A consumer can then go to www.xyz.com to browse products and make purchases. This is representative of the way that ecommerce works today and has worked for 20 years.
  • Credit card processing for these types of e-commerce platform transactions is usually performed by a third party, not the e-commerce platform.
  • Such credit card processing companies include Stripe, Authorize.net, PayPal, and others. These transaction systems contain no product data and have no integration into ecommerce platforms.
  • on-line merchants are provided with a“plug-in” (i.e., a software component that adds a specific feature to an existing computer program) that opens up an entire distribution network for the on-line merchants’ products that they are then able to leverage.
  • a“plug-in” i.e., a software component that adds a specific feature to an existing computer program
  • on-line merchants can create more instances of their own stores throughout the Internet on different properties.
  • various applications can now‘sell product on- line’ without having to go through the technological impediment of actual inventory purchases and physical transfer of products from warehouse to warehouse before a transaction takes place.
  • a product may be defined as any type of saleable products or services that may be physical, virtual, downloadable, intangible, licensable (e.g., software or software as a service), experiential, as well as other products or services, and the like.
  • apps developers As defined herein, an app developer is any company, individual, or group of individuals that creates an application that exists on the internet.
  • a multi-platform e-commerce distribution system that creates a two-sided digital marketplace may be summarized as including a processor- enabled bi-directional data translation system, a processor-enabled product distribution platform, and a processor-enabled commerce graph Application Program Interface (API).
  • the directional data translation system extracts product data and translates product data.
  • the bi-directional data translation system ingests product information in formats from multiple different merchants and converts the product information into a unified product schema.
  • the bi- directional data translation system also converts the product information in the unified product schema back into one or more formats expected by one or more individual e-commerce platforms.
  • the bi-directional data translation system extracts data from multiple e-commerce platforms and translates the extracted data into the unified product schema.
  • the bi-directional data translation system then translates the product information in the unified product schema into formats expected by the multiple different merchants.
  • the product distribution platform includes a repository of purchasable products containing information that has been converted into the unified product schema.
  • the repository receives ingested product information from the bi-directional data translation system that has been converted into the unified product schema from multiple different merchant company formats.
  • the repository receives ingested product information from the bi-directional data translation system that has been converted into the unified product schema from multiple e-commerce platform formats.
  • the repository of the purchasable products includes multiple product information wrappers, each product information wrapper including product characteristics information and individual merchant purchase offer information that is configured to receive and execute a product transaction request.
  • the commerce graph Application Program Interface receives orders from one or more purchasers via multiple third party
  • the order transaction data in the unified order schema is converted into order write back data in a platform -specific format expected by the e- commerce platform of product origin.
  • the multiple third party applications comprise multiple digital product transaction locations on the Internet.
  • the bi-directional data translation system may receive a product information update from a product merchant and may automatically update the product information at multiple digital product transaction locations. Through the use of event listeners, product offers within the product repository may be automatically updated, when their equivalent entities on a source e-commerce platform are updated.
  • An order may be received from a purchaser via a third party application, the order may be translated into the unified product schema used by the product distribution platform, and then the order in the unified product schema may be re-translated into an individual e-commerce format expected by the e-commerce platform of origin to fulfill the order.
  • the system may update the product inventory status after the received order has been fulfilled.
  • the unified product schema used by the product repository may feature a top-level product wrapper that contains information associated with a product, including metadata, minimum and maximum prices, and possible product options. Possible product options may include, by way of example only, and not by way of limitation, sizes, colors, materials, versions, or combinations thereof.
  • the top-level product wrapper may include nested product offers that may be purchasable entities. Each nested offer is a product that is available by a merchant and that exists within the top-level product wrapper. Additionally, each nested offer may contain pricing and discount information, as well as product options and variants that are not available in other offers nested under the same top-level product wrapper.
  • the product offer on the product repository may be updated automatically to reflect those changes. If a product becomes out of stock on an e-commerce platform, then an equivalent product offer on the product repository may be
  • a multi-platform e-commerce distribution system may be summarized as including a processor-enabled bi-directional data translation system that extracts product data and translates product data, a processor- enabled product distribution platform including a repository of purchasable products containing information that has been converted into a unified product schema, and a processor-enabled commerce graph Application Program Interface (API).
  • the bi-directional data translation system translates product information between formats of one or more different merchants and the unified product schema of the product distribution platform.
  • the bi-directional data translation system translates the product information between the unified product schema of the product distribution platform and one or more formats expected by one or more individual e-commerce platforms.
  • the commerce graph Application Program Interface receives orders from one or more purchasers via multiple third party applications and converts the order transaction data into a unified order schema.
  • the order transaction data in the unified order schema is converted into order write back data in a platform- specific format expected by the e-commerce platform of product origin.
  • the bi-directional data translation system may receive a product information update from a product merchant and may automatically update the product information at multiple digital product transaction locations. Through the use of event listeners, product offers within the product repository may be automatically updated when their equivalent entities on a source e-commerce platform are updated.
  • An order may be received from a purchaser via a third party application, the order may be translated into the unified product schema used by the product distribution platform, and then the order in the unified product schema may be re-translated into an individual e-commerce format expected by the e-commerce platform of origin to fulfill the order.
  • the system may update the product inventory status after the received order has been fulfilled.
  • the unified product schema used by the product repository may feature a top-level product wrapper that contains information associated with a product, including metadata, minimum and maximum prices, and possible product options. Possible product options may include, by way of example only, and not by way of limitation, sizes, colors, materials, versions, or combinations thereof.
  • the top-level product wrapper may include nested product offers that may be purchasable entities. When a merchant modifies a product on an e-commerce platform, the product offer on the product repository may be updated automatically to reflect those changes. If a product becomes out of stock on an e-commerce platform, then an equivalent product offer on the product repository may be correspondingly marked as out of stock on all third party applications linked to the product repository where the product was previously purchasable.
  • a multi-platform e-commerce distribution system may be summarized as including a processor-enabled bi-directional data translation system, processor-enabled product distribution platform, and processor- enabled commerce graph Application Program Interface (API).
  • the bi- directional data translation system extracts product data and translates product data.
  • the bi-directional data translation system ingests product information in formats from one or more different merchants and converts the product information into a unified product schema.
  • the bi-directional data translation system then converts the product information from the unified product schema into one or more formats expected by one or more individual e-commerce platforms.
  • the bi-directional data translation system extracts data from one or more e-commerce platforms and translates the extracted data into the unified product schema.
  • the bi-directional data translation system then translates the product information from the unified product schema into one or more formats expected by the one or more different merchants.
  • the product distribution platform that includes a repository of purchasable products containing information that has been converted into the unified product schema.
  • the repository receives ingested product information from the bi-directional data translation system that has been converted into the unified product schema from one or more different merchant company formats.
  • the repository receives ingested product information from the bi-directional data translation system that has been converted into the unified product schema from one or more e-commerce platform formats.
  • the commerce graph Application Program Interface receives orders from one or more purchasers via multiple third party
  • the system may create a single point of entry for merchants for distribution to the third party applications on the Internet.
  • the system may create a single distribution house in the digital world for third party application developer and end purchasers.
  • a processor-enabled bi-directional data translation system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: for incoming product data from merchants, ingest product information in formats from multiple different merchants and convert the product information into a unified product schema; for outgoing product data to e-commerce platforms, convert the product information in the unified product schema into one or more formats expected by one or more individual e-commerce platforms; for incoming product data from e-commerce platforms, extract data from multiple
  • e-commerce platforms and translate the extracted data into the unified product schema; and for outgoing product data to merchants, translate the product information in the unified product schema into formats expected by the multiple different merchants.
  • the system when updated product information is received from a product merchant, the system automatically updates the product information at multiple digital product transaction locations.
  • product offers within a product repository are automatically updated, when their equivalent entities on a source e-commerce platform are updated.
  • the order when an order is received from a purchaser via a third-party application, the order is translated into a unified order schema used by a product distribution platform.
  • the order in the unified order schema is re-translated into an individual e-commerce format expected by the e-commerce platform to fulfill the order.
  • the product inventory status of the product is updated after the received order for the product has been fulfilled.
  • the unified product schema used by a product repository features a top-level product wrapper that contains information associated with a product, including metadata, minimum and maximum prices, and possible product options.
  • possible product options include sizes and colors.
  • the top-level product wrapper includes nested offers that are purchasable entities. Each nested offer is a product that is available by a merchant and that exists within the top-level product wrapper. Additionally, each nested offer may contain product options and variants that are not available in other offers nested under the same top-level product wrapper.
  • the product offer in a product repository is updated automatically to reflect those changes.
  • an equivalent product offer in a product repository is
  • the processor-enabled data translation system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: receive incoming product data from one or more merchants; ingest product information in one or more formats from the one or more merchants; convert the product information into a unified product schema; store the product information on a product distribution platform that includes a repository of the purchasable products; convert the product information in the unified product schema from storage on the product distribution platform into a plurality of formats expected by a plurality of individual e-commerce platforms; and send outgoing product data to the plurality of individual e-commerce platforms.
  • the processor-enabled data translation system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: receive incoming product data from a plurality of individual e-commerce platforms; extract product information in a plurality of
  • platform-specific formats from the plurality of individual e-commerce platforms; convert the product information from the plurality of platform-specific formats of the plurality of e-commerce platforms into a unified product schema; store the product information on a product distribution platform that includes a repository of the purchasable products; convert the product information in the unified product schema from storage on the product distribution platform into one or more formats expected by one or more merchants; and send outgoing product data to the one or more merchants.
  • the system creates a single point of entry for merchants for distribution to the third-party applications on the Internet. In another aspect of some implementations, the system creates access to a single distribution house in the digital world for third-party application
  • the system enables merchants to individually modify rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers.
  • the system enables merchants to set default rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers, and enables merchants to set custom rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers for specific products.
  • the memory device further stores a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: compare the new product data and determine if there is already a same existing product in the repository of the purchasable products; if there is a same existing product, merge the new product data with the same existing product as an additional offer in the repository of the purchasable products; and if there is not a same existing product, create a new product offering with the new product data in the repository of the purchasable products.
  • a processor-enabled commerce graph API system for a multi-platform e-commerce distribution system may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take that following actions: for incoming order transaction data from one or more third party applications, ingest order transaction data from the one or more third party applications and convert the order transaction data into a unified order schema; for outgoing order write back data to an e-commerce platform of product origin, convert the order transaction data in the unified order schema into a platform specific format expected by the e-commerce platform of product origin; for incoming order write back data from the e-commerce platform of product origin, convert the order transaction data from the platform specific format of the e commerce platform of product origin into the unified order schema; and for outgoing order transaction data to the one or more third party applications, translate the order transaction data in the unified order schema into a format expected by the one or more third party applications.
  • the commerce graph API system further includes a checkout API that has a check-out cart system and an order submission system.
  • the check-out cart system of the checkout API creates a virtual check-out cart and facilitates a transaction with the one or more third-party applications.
  • the order submission system of the checkout API facilitates writing an order back to an e-commerce platform of product origin.
  • the order submission system of the checkout API receives dynamic tax and shipping data from a third-party service or an e- commerce platform when pricing of the virtual check-out cart is initiated via direct integration with tax and shipping APIs.
  • the order submission system of the checkout API generates an external asynchronous cart
  • the commerce graph API system tracks order status of products in submitted orders and provides order status notification to product purchasers. In another aspect of some implementations of the commerce graph API system, when an order is received from a
  • the order is translated into the unified order schema used by the e-commerce platform of product origin, and then the order in the unified order schema is re-translated into an individual e-commerce format expected by the e-commerce platform of product origin to fulfill the order.
  • the product inventory status of a product is updated after the received order for the product has been fulfilled.
  • an equivalent product offer in a product repository is correspondingly marked as out of stock on all third-party applications linked to the product repository where the product was previously purchasable.
  • the processor-enabled commerce graph API system for a multi-platform e-commerce distribution system may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take that following actions: for incoming order transaction data from an application, ingest order transaction data from the application and convert the order transaction data into a unified order schema; for outgoing order write back data to multiple e-commerce platforms of product origin, convert the order transaction data in the unified order schema into platform-specific formats expected by the e-commerce platforms of product origin; for incoming order write back data from the e-commerce platforms of product origin, convert the order transaction data from the multiple
  • the commerce graph API system includes an order submission system that enables concurrent multi-merchant on-line shopping during which products from multiple merchants associated with different e-commerce platforms of product origin are concurrently selected to a single virtual shopping cart.
  • the processor-enabled commerce graph API system for a multi-platform e-commerce distribution system may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take that following actions: for incoming order transaction data from multiple third party applications, ingest order transaction data from one or more third party applications and convert the order transaction data into a unified order schema; for outgoing order write back data to an e- commerce platform of product origin, convert the order transaction data in the unified order schema into a platform specific format expected by the e- commerce platform of product origin; for incoming order write back data from the e-commerce platform of product origin, convert the order transaction data from the platform specific format of the e-commerce platform of product origin into the unified order schema; and for outgoing order transaction data to the multiple third party applications, translate the order transaction data in the unified order schema into a format expected by the one or more third party applications; wherein the commerce graph API system includes an order submission
  • the commerce graph API system creates a single point of entry for merchants for distribution to the third-party applications on the Internet. In another aspect of some implementations, the commerce graph API system creates access to a single distribution house in the digital world for third-party application developers and end purchasers. In still another aspect of some implementations, the commerce graph API system enables merchants to individually modify rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers. In yet another aspect of some
  • the commerce graph API system enables merchants to set default rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers, and enables merchants to set custom rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers for specific products.
  • a processor-enabled multi-platform e-commerce system with an asynchronous virtual cart may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take the following actions: create an internal virtual cart associated with the multi-platform e-commerce system; in response to the creation of the internal virtual cart, create an external asynchronous virtual cart associated with one or more single e-commerce platforms; upon receiving an incoming product order request from one or more third-party applications, add the product order request to the internal virtual cart; in response to adding the product order request to the internal virtual cart, send instructions to add the product order request to the external asynchronous virtual cart associated with the one or more single e-commerce platforms; upon receiving an order completion instruction from the one or more third-party applications, send payment authorization to a payment gateway; upon receiving payment authorization results from the payment gateway, submit a product order to the one or more single e-commerce platforms; send payment capture instructions to the payment gateway; and receive payment capture results from
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving a second incoming product order request from a second third-party application, add the second product order request to the internal virtual cart; and in response to adding the second product order request to the internal virtual cart, send instructions to add the second product order request to the external asynchronous virtual cart.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving an another incoming product order request from another third-party application, add the another product order request to the internal virtual cart; and in response to adding the another product order request to the internal virtual cart, send instructions to add the another product order request to the external asynchronous virtual cart.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving set shipping address instructions from another third-party application, send the set shipping address instructions to the internal virtual cart; and in response to sending the set shipping address instructions to the internal virtual cart, send instructions to set a shipping address to the external asynchronous virtual cart.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving set billing address instructions from another third-party application, send the set billing address instructions to the internal virtual cart; and in response to sending the set billing address instructions to the internal virtual cart, send instructions to set a billing address to the external asynchronous virtual cart.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving set shipping method instructions from another third-party application, send the set shipping method instructions to the internal virtual cart; and in response to sending the set shipping method instructions to the internal virtual cart, send instructions to set a shipping method to the external asynchronous virtual cart.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving price cart contents instructions from another third-party application, send the price cart contents instructions to the internal virtual cart; and in response to sending the price cart contents instructions to the internal virtual cart, send instructions to price cart contents to the external asynchronous virtual cart.
  • a payment captured from the payment gateway includes a merchant’s portion of the captured payment, and the merchant’s portion of the captured payment is sent directly to the merchant without being escrowed by the multi-platform e-commerce system or any other third-party account.
  • the system further includes a return management system that tracks product returns, and a product return automatically triggers reversal of the payment transaction including return of the merchant’s portion of the captured payment, which is sent directly from the merchant to the payment gateway without being escrowed by the multi-platform e-commerce system or any other third-party account.
  • every action taken in the internal virtual cart associated with the multi-platform e-commerce system results in an immediate corresponding action being performed on the external asynchronous virtual cart associated with the one or more single e-commerce platforms.
  • the processor-enabled multi-platform e-commerce system with an asynchronous virtual cart may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take the following actions: create an internal virtual cart associated with the multi-platform e-commerce system; in response to the creation of the internal virtual cart, create an external asynchronous virtual cart associated with one or more single e-commerce platforms; upon receiving an incoming product order request from one or more third-party applications, add the product order request to the internal virtual cart; in response to adding the product order request to the internal virtual cart, send instructions to add the product order request to the external asynchronous virtual cart associated with the one or more single e-commerce platforms; upon receiving an incoming additional product order request from another third-party application, add the additional product order request to the internal virtual cart; in response to adding the additional product order request to the internal virtual cart, send instructions to add the additional product order request to the external asynchronous virtual cart; upon receiving an
  • the processor-enabled multi-platform e-commerce system with an asynchronous virtual cart may be summarized as including one or more processors and a memory device storing a set of instructions that when executed by the one or more processors, causes the one or more processors to take the following actions: create an internal virtual cart associated with the multi-platform e-commerce system; in response to the creation of the internal virtual cart, create an external asynchronous virtual cart associated with one or more single e-commerce platforms; and in response to every action taken in the internal virtual cart associated with the multi-platform e-commerce system, enable performance of an immediate corresponding action on the external asynchronous virtual cart associated with the one or more single e-commerce platforms.
  • the memory device further stores a set of instructions that when executed by the one or more processors, causes the one or more processors to: upon receiving an order completion instruction from one or more third-party applications, send payment authorization to a payment gateway; upon receiving payment authorization results from the payment gateway, submit product order to the one or more single e-commerce platforms; send payment capture instructions to a payment gateway; and receive payment capture results from the payment gateway.
  • the system creates a single point of entry for merchant companies for distribution to the third-party applications on the Internet. In still another aspect of some implementations, the system creates access to a single distribution house in the digital world for third-party application developers and end purchasers. In yet another aspect of some implementations, the system enables merchants to individually modify rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers. In another implementation, the system enables merchants to set default rates of revenue being offered to third-party application developers that helped generate the transaction between the third-party application developers, and enables merchants to set custom rates of revenue being offered to third-party
  • a processor-enabled system for concurrent multi-merchant on-line shopping with a single check-out transaction in a multi-platform e-commerce system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: create an internal virtual cart associated with the multi-platform e- commerce system; in response to receiving new payment method instructions from a customer, add a new payment method associated with the customer to an account of the customer in the multi-platform e-commerce system, wherein the new payment method is tokenized and made available for repeatable use during check-out transactions; in response to receiving new payout method instructions from a first merchant, add a new payout method associated with the first merchant to an account of the first merchant in the multi-platform e- commerce system, wherein the new payout method of the first merchant is tokenized and made available for repeatable use during check-out transactions; in response to receiving new payout method instructions from a second merchant, add a new payout method associated with
  • a merchant’s portion of the product transaction proceeds is made immediately available to the merchant by sending the merchant’s portion of the product transaction proceeds directly from the customer to the merchant.
  • the payment method associated with the customer in the multi-platform e-commerce system is vaulted for payment transactions with any merchant associated with the multi- platform e-commerce system without requiring reentry of any customer information.
  • use of a single payment gateway of the multi-platform e-commerce system for both customer payment methods and merchant payout methods enables the customer to only have to vault a unique payment method once, and the unique payment method of the customer is useable in check-out transactions across all merchants associated with the multi-platform e-commerce system.
  • the system further includes an order submission system that receives dynamic tax and shipping data from a third party service when pricing of the internal virtual cart is initiated via direct integration with tax and shipping application program interfaces (APIs).
  • APIs application program interfaces
  • system further includes an order submission system that generates an external asynchronous cart associated with a receiving e-commerce platform of product origin.
  • the memory device further stores a set of instructions that, when executed by the one or more processors, causes the one or more processors to: upon receiving a single check-out transaction instruction from one or more third party applications, send payment
  • the customer sends a first product order request to the first merchant associated with a first single e-commerce platform, using a first of multiple third party applications, and the customer sends a second product order request to the second merchant associated with a second single e-commerce platform, using a second of multiple third party applications.
  • a processor-enabled system for concurrent multi-merchant on-line shopping with a single check-out transaction in a multi-platform e-commerce system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: add a new payment method associated with the customer to an account of the customer in the multi-platform e-commerce system, wherein the new payment method for the customer is made available for repeatable use during check-out transactions; add a new payout method associated with each of multiple merchants to an account of each of multiple merchants in the multi-platform e-commerce system, wherein the multiple merchants are associated with more than one e-commerce platform, wherein the new payout method for each of multiple merchants is made available for repeatable use during check-out transactions, and wherein the customer payment method and the multiple merchant payout methods are vaulted within the same payment gateway by the multi-platform e-commerce system; upon receiving product order requests from the
  • a processor-enabled system for concurrent multi-merchant on-line shopping with a single check-out transaction in a multi-platform e-commerce system may be summarized as including one or more processors and a memory device storing a set of instructions that, when executed by the one or more processors, causes the one or more processors to take that following actions: in response to receiving new payment method instructions from a customer, add a new payment method associated with the customer to an account of the customer in the multi-platform e-commerce system; in response to receiving new payout method instructions from multiple merchants, add new payout methods associated with each of the multiple merchants to accounts of each of the multiple merchants in the multi-platform e- commerce system, the multiple merchants being associated with more than one e-commerce platform, wherein the customer payment method and the merchant payout methods are vaulted within the same payment gateway by the multi-platform e-commerce system; upon receiving product order requests from the customer to multiple merchants, add the products associated with the product order requests to the internal virtual cart; upon receiving a single
  • the system creates a single point of entry for merchant companies for distribution to the third party applications on the Internet. In still another aspect of some implementations, the system creates access a single distribution house in the digital world for third party application developers and end purchasers. In yet another aspect of some implementations, the system enables merchants to individually modify rates of revenue being offered to third party application developers that helped generate the transaction between the third party application developers. In another implementation, the system enables merchants to set default rates of revenue being offered to third party application developers that helped generate the transaction between the third party application developers, and enables merchants to set custom rates of revenue being offered to third party
  • the memory device further stores a set of instructions that, when executed by the one or more processors, causes the one or more processors to: for incoming product data from multiple merchants, ingest product information in formats from the multiple merchants and convert the product information into a unified product schema; and for outgoing product data to a plurality of individual e commerce platforms, convert the product information from the unified product schema into a plurality of formats expected by the plurality of individual e commerce platforms.
  • the memory device further stores a set of instructions that, when executed by the one or more processors, causes the one or more processors to: for incoming product data from a plurality of individual e commerce platforms, convert product information from a plurality of platform specific formats of the plurality of individual e commerce platforms into a unified product schema; and for outgoing product data to multiple merchants, translate the product information in the unified product schema into formats expected by the multiple merchants.
  • Figure 1 is a schematic diagram that shows on-line merchants connecting to e-commerce functionality through legacy prior art e-commerce platforms in the way that these systems generally work today.
  • Figure 2A is a schematic diagram of an implementation of the multi-platform e-commerce distribution system that is positioned between on-line merchants on one side and consumers (e.g., website, mobile, and various other applications) on the other side.
  • consumers e.g., website, mobile, and various other applications
  • Figure 2B is a schematic diagram of three sections of the multi-platform e-commerce distribution system: the synchronization service system, the product distribution platform, and the commerce graph Application Program Interface, which are all positioned between e-commerce platforms on one side and consumers on the other side, according to one implementation of the disclosed embodiments.
  • Figures 3A, 3B, and 3C are schematic diagrams of sample product schema for the multi-platform e-commerce distribution system in which the different superscripts correspond to values that are being cross-translated by the system.
  • Figure 4 is a schematic diagram of the product distribution platform section of the multi-platform e-commerce distribution system, which shows the microservices architecture, according to one implementation of the disclosed embodiments.
  • Figure 5 is a logical diagram of transactional information for an “order write-back” in the multi-platform e-commerce distribution system, according to one implementation of the disclosed embodiments.
  • Figure 6 is a block diagram of an example processor-based device used to implement one or more of the electronic devices described herein.
  • Figure 1 shows on-line merchants connecting to e-commerce functionality through legacy e-commerce platforms. As such, Figure 1 shows the prior art e-commerce transaction configuration.
  • FIGS 2A, 2B, and 3A-3C present illustrative diagrams of a headless multi-platform e-commerce distribution system 100.
  • an implementation of the multi-platform e-commerce distribution system 100 is shown that is positioned between on-line merchants 120 on one side and consumers 140 (e.g., applications and application developers through which end customers purchase products) on the other side.
  • the applications 140 include, by way of example only, and not by way of limitation: website and mobile applications, social media applications 150, virtual reality applications 160, augmented reality applications 170, voice applications 180, and other applications 190.
  • the three sections of the multi-platform e-commerce distribution system 100 include a synchronization service system 200, a product distribution platform 300, and an application program interface 400 (/. e. , commerce graph).
  • the three sections of the multi-platform e-commerce distribution system 100 are all positioned between e-commerce platforms 500 on one side and consumers 140 (e.g., applications and application developers through which end customers purchase products) on the other side.
  • the product distribution platform 300 includes a product database 310 and an operational database 320, as well as a tax information component 330, a shipping information component 340, a currency information component 350, and a payment information component 360.
  • Each of these different e-commerce platforms has a different architecture, database structure, and method for extracting data, as well as other nuances unique to its system’s architecture and maturity. Many of these different e-commerce platforms are old and archaic. Additionally, the different e-commerce platforms do not work well with others and, more significantly, there are a large number of different e-commerce platforms.
  • each of the different e-commerce platforms listed above allows for“integrations” to be built into the platform.
  • Such integrations provide access into the e-commerce platforms and the data inside of the e-commerce platforms.
  • the system integrates into many or all of the
  • the synchronization service system 200 of the headless multi-platform e-commerce distribution system 100 facilitates (1 ) the bi-directional“data translation” (/. e. ,“product ingestion”), and (2) the “order write-back.”
  • the synchronization service system 200 of the headless multi-platform e-commerce distribution system 100 facilitates single direction data translation in either (1 ) from the one or more merchants to the one or more e-commerce platforms, or (2) from the one or more e-commerce platforms to the one or more merchants.
  • the synchronization service system 200 of the headless multi-platform e-commerce distribution system 100 provides unique new capabilities in the e-commerce transaction marketplace.
  • the synchronization service system 200 of the headless multi-platform e-commerce distribution system 100 is dedicated to the timing and translation activities of data extraction from all the different e-commerce platforms into a format the product distribution platform 400 can ingest.
  • This translation layer exists in the synchronization service system 200 to streamline operations of the headless multi-platform e-commerce distribution system 100.
  • the synchronization service system 200 acts as a bi-directional translation layer for order data coming into (/. e. , ingestion) the headless multi-platform e-commerce distribution system 100 and exiting (/.e., order write-back) the headless multi-platform e-commerce distribution system 100.
  • the synchronization service system 200 (coming from an app via order write-back) the synchronization service system 200 translates these orders back into the format expected by the e-commerce platform of origin, before submitting them. This is the bi-directional nature of the synchronization service system 200 and the headless multi-platform e-commerce distribution system 100 in general. As these orders progress through the acceptance and fulfillment processes within the e-commerce platform of origin, the synchronization service system 200 of the headless multi-platform e-commerce distribution system 100 receives updated order data and translates this order data back into the order schema of the headless multi-platform e-commerce distribution system 100 before updating the order records of the headless multi-platform e-commerce distribution system 100.
  • the product distribution platform 300 of the headless multi-platform e-commerce distribution system 100 utilizes a custom
  • top-level product wrapper that contains all of the relevant information associated with that product.
  • the top-level product wrapper is the source of basic metadata, minimum and maximum prices, and all possible product options like sizes, colors, materials, versions, or
  • the top-level product wrapper is not purchasable itself, but the merchant offers nested within the top-level product wrapper are the purchasable offer entities.
  • Each nested offer is a product that may be made available by a merchant and is existent within the top-level product.
  • a nested offer may contain product options and variants that are not available in other offers nested under the same top-level product wrapper.
  • the offer entities consist of the variations of the product that a merchant 120 is actively selling. Two or more merchants 120 can sell the same variant combinations, completely different variations, or a mix of both. Additionally, merchants 120 can price their products independently of each other. The end developer may then determine which offer or offers to display or purchase.
  • the product offers within the headless multi-platform e-commerce distribution system 100 are constantly updated, as their equivalent entities on the source e-commerce platform are updated.
  • the headless multi-platform e-commerce distribution system 100 uses event listeners to help facilitate the updating.
  • event listeners In other words,
  • event listeners are not used by the headless multi-platform e-commerce distribution system 100 in the updating process.
  • a merchant 120 is not required to take any action to update the information associated with their product once it has been published within the headless multi-platform e-commerce distribution system 100.
  • the product offer on the headless multi-platform e-commerce distribution system 100 is updated automatically to reflect those changes.
  • the equivalent product offer on the headless multi-platform e-commerce distribution system 100 is also marked as out of stock, and will no longer be purchasable.
  • the product schema of the headless multi-platform e-commerce distribution system 100 is normalized. Accordingly, regardless of the source of the product data, the product data is always translated into a single format. Thus, a developer only has to integrate with the schema of the headless multi-platform
  • the headless multi-platform e-commerce distribution system 100 provides the technological improvement to developers of not requiring them to alter their codebases when the external platform data formats are updated or deprecated.
  • the product schema of the headless multi-platform e-commerce distribution system 100 is marketplace oriented such that it enables multiple merchants 120 to sell the same product.
  • a product at the top level is simply a data wrapper that contains basic product data and one or more nested product offers. These nested product offers are the purchasable entities in the headless multi-platform e-commerce distribution system 100. If two or more merchants 120 sell the same item, their items will be listed as offers of the top level product.
  • a developer does not need to search the product catalog for duplicate products.
  • the developer can compare offers across multiple merchants 120 and choose which offer(s) they want to make available in their application. Additionally, the product schema of the headless
  • multi-platform e-commerce distribution system 100 separates variants from SKUs (Stock Keeping Units), and provisions them in an easily consumable format.
  • variants are the individual descriptors of a product like sizes, colors, materials, versions, or combinations thereof, while SKUs are the combinations of variants that together represent an item.
  • the top level product wrapper lists all possible variants across all offers. The individual offers then list all possible variants for that offer.
  • headless multi-platform e-commerce distribution system 100 By using the headless multi-platform e-commerce distribution system 100, a developer may immediately discover and consume all possible product variations without needing to dive into the nested product offers.
  • headless multi-platform e-commerce distribution system 100 a developer is not required to parse variants from SKU data.
  • the requirement of parsing variants from SKU data was a common technological limitation of previous attempts to work across e-commerce platforms.
  • Product level variants are a collection of all possible product variations across all merchant offers for a single product.
  • variants are options that may include but are not limited to sizes, colors, materials, versions, or combinations thereof.
  • Within each variant is a collection of variant values such as small, medium, and large; or black, grey, and white. Making these variants available at the product level allows the developer to discover all possible variants without needing to iterate through the nested product offers.
  • Offers are a collection of a merchant’s offerings of a product.
  • Offer level variants are similar to product level variations; however, the collection is limited to only the product variations offered by a single merchant for a single product. Offer level variants allow a developer to enable option selection, and from there SKU composition, within their app. SKU composition is the process of combining variants to discover the SKU that matches the selected variants exactly. Regarding still another parameter, offer SKUs are combinations of variants that together equal a real product. Offer SKUs map directly to the purchasable entities on the external e-commerce platforms. When external orders are written back to the e-commerce platform, it is these SKUs that are being purchased.
  • the headless multi-platform e-commerce distribution system 100 enables the merging of product data.
  • Data merging is the process of determining if two products are the same.
  • the product is compared to existing products already in the repository of the headless multi-platform e-commerce distribution system 100. If a match is found, the product is added as an additional offer under the existing top-level product wrapper. If a match is not found, a new top-level product wrapper is created with the source product becoming the first offer of that product.
  • a combination of product properties are used to determine if two products are the same. These include, by way of example only, and not by way of limitation: name, SKU (Stock Keeping Unit), brand, variation types, GTIN (Global Trade Item Number), ASIN (Amazon Standard Identification Number), UPC (Universal Product Code), EAN
  • the headless multi-platform e-commerce distribution system 100 ingests three-dimensional spatial data.
  • the headless multi-platform e-commerce distribution system 100 collects all media elements during product ingestion, which can include both video and image elements, related to a product and its variants. Using these media elements, the headless multi-platform e-commerce distribution system 100 builds a visual profile of an individual product. This visual profile ultimately serves (but is not limited to) two primary purposes, product recognition and 3D image composition.
  • Product Recognition is the ability to determine what product or products are present in an image or video. To achieve this functionality, a product’s visual profile is used to train machine learning algorithms how to recognize a product. The larger and more diverse the collection of product media is, the better the machine learning algorithms can be trained.
  • the marketplace product schema used by the headless multi-platform e-commerce distribution system 100 provides technological advantages in this regard, since the system 100 has multiple merchants selling the same product. Accordingly, the headless multi-platform e-commerce distribution system 100 is able to collect a broader array of product media, since most merchants use product media that is unique.
  • Three-dimensional (3D) image composition is the ability to compose a 3D rendering of a product using the media elements collected for that product. This process involves training machine learning algorithms to build a 3D profile using the available media and then, essentially, fill in the gaps to complete the full 3D rendering. Since application developers collect spatial data on products in the physical world, the headless multi-platform e-commerce distribution system 100 is able to facilitate the recognition of products using the collected 3D spatial data.
  • users of applications associated with the headless multi-platform e-commerce distribution system 100 are another source of product media elements. Again, these product media elements may be used to train both product recognition and 3D image composition machine learning algorithms.
  • the headless multi-platform e-commerce distribution system 100 may incorporate 3D image scanning, associate with third-party partners, or provide merchants with the tools to scan their product catalog. These types of actual 3D product scanning are another source of 3D product data.
  • the headless multi-platform e-commerce distribution system 100 consumes all of the relevant product catalog data and transactional data due to the product ingestion and the positioning of the system 100 between on-line merchants 120 and applications 140.
  • Others have attempted to obtain some of this data by“scraping” the information from websites without permission, or purchasing scraped information from others.
  • this type of scraped information is undesirable for a variety of reasons.
  • scraped information is typically incomplete, outdated, and/or inaccurate.
  • some scraped data from industry leaders is known to be accurate less than 50% of the time. Additionally, scraped information only attempts to provide product catalog data. Scraped information does not provide transactional data.
  • the headless multi-platform e-commerce distribution system 100 provides access to instant, clean, accurate, product data, as well as transactional data. For example, one reason that scraped information is often outdated and inaccurate is that retailers change product information all the time, such as when a product’s price changes or a product goes out of stock.
  • Scraped information then becomes inaccurate whenever a change is made. Additionally, there are no notification systems to notify everyone that the scraped information has been changed, particularly since information“scraping” often occurs in an unauthorized manner.
  • the product catalog information is linked and automatically updated in the repository of the product distribution platform. Thus, the headless multi-platform e-commerce distribution system 100 automatically knows of an updated price, new image, stock quantities by size or color, or even new products.
  • the headless multi-platform e-commerce distribution system 100 also includes a product distribution platform 300, as was previously discussed with respect to Figure 2B.
  • the product distribution platform 300 of the headless multi-platform e-commerce distribution system 100 is built with a microservices architecture.
  • the architecture of the system 100 includes several different components, such as API service component 305, synchronization service component 310, merchant service component 315, catalog service component 320, user service component 325, app service component 330, notification service component 335, billing service component 340, tax service component 345, fulfillment service component 350, order service component 355, and compliance service component 360.
  • the API service component 305 of the headless multi-platform e-commerce distribution system 100 is the gateway to the API.
  • the API service component 305 is responsible for authorization/security and request routing.
  • the API service component 305 is powered by Zuul (Netflix). In this regard, all authorized incoming requests are inspected and routed to the correct microservice by the API service component 305.
  • the synchronization service component 310 of the product distribution platform 300 is a bi-directional translation layer that (1 ) translates any incoming data into the equivalent schemas of the headless multi-platform e-commerce distribution system 100 and (2) translates any outgoing data of the headless multi-platform e-commerce distribution system 100 into the equivalent external schemas.
  • the core functionalities of“product ingestion” and“order write-back” are found in this service.
  • the merchant service component 315 of the product distribution platform 300 maintains data related to merchants and their external stores. Additionally, the merchant service component 315 makes this data accessible to other services through internal APIs.
  • the catalog service component 320 of the product distribution platform 300 maintains and makes accessible all product and taxonomy related data.
  • the catalog service component 320 is the only entry point to the product repository.
  • the user service component 325 of the product distribution platform 300 maintains all accounts and account related data of the headless multi-platform e-commerce distribution system 100.
  • the user service component 325 of the product distribution platform 300 is responsible for defining a user’s permissions.
  • the defining of user permissions acts to limit the scope of the user’s access to the services of the headless multi-platform e-commerce distribution system 100.
  • the app service component 330 of the product distribution platform 300 is responsible for maintaining and authorizing developers and their applications with the headless multi-platform e-commerce distribution system 100.
  • the notification service component 335 of the product distribution platform 300 is responsible for all notifications in the headless multi-platform e-commerce distribution system 100. In this regard, all app notifications, email notifications, SMS notifications, and push notifications are managed by the notification service component 335 of the product distribution platform 300.
  • the billing service component 340 of the product distribution platform 300 maintains the
  • the tax service component 345 of the product distribution platform 300 is responsible for maintaining merchant provided tax nexuses/rates. Additionally, the tax service component 345 of the product distribution platform 300 is also responsible for interacting with third-party tax services to provide automated tax rates.
  • tax service component 345 of the product distribution platform 300 is also responsible for inspecting virtual shopping carts to provide accurate tax data during the checkout process.
  • the fulfillment service component 350 of the product distribution platform 300 is responsible for maintaining merchant provided shipping methods/rates. Additionally, the fulfillment service component 350 of the product distribution platform 300 is also responsible for interacting with third-party fulfillment services to provide automated shipping methods/rates. Furthermore, the fulfillment service component 350 of the product distribution platform 300 also inspects carts and provides a list of available shipping methods/rates during the checkout process.
  • the order service component 355 of the product distribution platform 300 powers the Checkout API. Additionally, the order service component 355 of the product distribution platform 300 is responsible for cart creation and order submission, as well as ongoing order updates.
  • the compliance service component 360 of the product distribution platform 300 is responsible for preventing sanctioned entities from interacting with the headless multi-platform e-commerce
  • This service pulls data directly from the United Nations Sanctions List and validates both merchants and users of the headless multi-platform e-commerce distribution system 100 against this data during registration and ongoing activities.
  • the product distribution platform 300 of the headless multi-platform e-commerce distribution system 100 acts as a repository of buyable products.
  • the repository of buyable products in the product distribution platform 300 contains top-level product wrappers, which includes product type characteristics such as simple, configurable, batched, downloadable, and virtual.
  • the product distribution platform 300 of the headless multi-platform e-commerce distribution system 100 acts as a repository of “buyable” products, not merely product catalog data.
  • a repository of product catalog data is interesting for activities such as advertising, however, for the products to be“buyable” products, many surrounding services, e.g., fulfillment, tax, merchant info, and the like are required for those products to be buyable.
  • the headless multi-platform e-commerce distribution system 100 also includes a commerce graph (API)
  • the e-commerce distribution system 100 is a single interface for any and all applications on the Internet to access products of the system 100.
  • Internet applications and their developers
  • these customers consider the commerce graph (API) 400 to be the product they seek to purchase.
  • the commerce graph (API) 400 is a series of endpoints that enable developers to perform end-to-end product transactions. This includes the ability to render full product details, provide a cart experience, submit orders, and track the status of submitted orders.
  • the components of the commerce graph (API) 400 include the catalog API, checkout API, cart, order submission, and order status.
  • the catalog API contains all of the relevant data and details about a given product in the headless multi-platform e-commerce distribution system 100.
  • the catalog API is also referred to as the“product catalog” of the headless multi-platform e-commerce distribution system 100.
  • the applications can request bits of data from the catalog API.
  • the checkout API of the headless multi-platform e-commerce distribution system 100 includes a cart component and an order submission component.
  • the cart component of the checkout API is used to create a cart and facilitate a transaction with an application.
  • the creation of a cart by the checkout API is an intermediate step that is taken before an order may be accepted.
  • the order submission component of the checkout API facilitates the ability to write the order back to the e-commerce platform of origin.
  • the order status component of the headless multi-platform e-commerce distribution system 100 enables application developers with the data needed to provide order status to their users.
  • Status data from the order status components may include, by way of example only, and not by way of limitation: order placed, order accepted, shipped, in transit, delivered, rejected, cancelled, returned, and the like. These types of order status data operate like notifications to the developer.
  • the order state tells the system 100 how far along the order is in the fulfillment process.
  • the fulfillment tracking data gives insight into the tracking numbers generated by the shipping company, and estimated delivery dates.
  • order tracking employs the use of event listeners that are registered through e-commerce platforms, and notifies the system 100 whenever an order is updated.
  • the commerce graph (API) 400 of the headless multi-platform e-commerce distribution system 100 is a unified API that collects data across all integrated platforms. The collected data is then normalized into unified schemas, in which one is a product schema and one is an order schema. The data normalization process occurs anytime data originating from an external e-commerce platform is sent into the headless multi-platform e-commerce distribution system 100 or data originating from the headless multi-platform e-commerce distribution system 100 is sent into an external e-commerce platform.
  • the headless multi-platform e-commerce distribution system 100 performs the necessary actions to keep the integrations updated and performing. In this manner, application developers that are interacting with the commerce graph (API) 400 of the headless multi-platform e-commerce distribution system 100 do not need to modify their integrations over time as the external e-commerce platforms change. Instead, the headless multi-platform e-commerce distribution system 100 provides the technological improvement of accounting for updates to the integrations within the commerce graph (API) 400 so further actions are not required by the application developers.
  • API commerce graph
  • an application developer would be required to write separate code for each e-commerce platform included by their application. Beyond the activities required for the initial integrations, an application developer would also be required to keep updating their code base for each platform over time as the e-commerce platforms updated and retired their own APIs.
  • the commerce graph (API) 400 of the headless multi-platform e-commerce distribution system 100 also enables “order write-back.”
  • The“order write-back” feature is what enables purchases to occur that are located on third-party applications. Without the“order
  • the headless multi-platform e-commerce distribution system 100 becomes an engine of commerce.
  • the“order write-back” feature increases the conversion from purchase initiation to purchase completion, which adds new value to media entities. This increase in conversion changes the value exchange between internet properties, individuals, and sellers of goods.
  • the“order write-back” feature of the headless multi-platform increases the conversion from purchase initiation to purchase completion, which adds new value to media entities. This increase in conversion changes the value exchange between internet properties, individuals, and sellers of goods.
  • e-commerce distribution system 100 enables a mere advertising scheme to be converted into a multi-platform e-commerce marketplace.
  • the headless multi-platform e-commerce distribution system 100 there are two separate techniques for performing“order write-back” on the platform.
  • the first“order write-back” method involves translating the order data from the headless multi-platform e-commerce distribution system 100 into the unique schema of the receiving e-commerce platform and directly submitting this data as a new order in one request. Since only one request is being made to the receiving e-commerce platform, all dynamic tax and shipping data must be obtained from third-party services at the time of cart pricing. To support this acquisition of the dynamic tax and shipping data, the headless multi-platform e-commerce distribution system 100 has direct integrations with tax and shipping APIs that are accessed each time the virtual shopping cart of the headless multi-platform e-commerce distribution system 100 is priced.
  • “order write-back” is performed on the platform by asynchronously creating and modifying an external cart on the receiving e-commerce platform during the checkout experience on the system 100.
  • every action taken in the checkout flow of the headless multi-platform e-commerce distribution system 100 results in an immediate matching action being performed on the receiving e-commerce platform.
  • This method enables the headless multi-platform e-commerce distribution system 100 to collect dynamic tax and shipping data directly from the receiving e-commerce platform without the need to rely on third-party services.
  • e-commerce distribution system 100 is submitted, the“customer selected” or “default payment method” is authorized for the total amount of the order. Upon a successful response that the order was accepted by the receiving
  • the payment authorization is captured and the customer is charged. If the capture of the payment authorization fails and subsequent retries fail, an order cancellation request is sent to the receiving e-commerce platform that automatically cancels the order. Finally, upon successful order payment, the funds are dispersed between the merchant, the application developer, and the headless multi-platform e-commerce distribution system 100. In the event of an order return within a pre-established remorse period, the dispersal of funds may be reversed.
  • event listeners are registered on the receiving e-commerce platform to enable the headless multi-platform e-commerce distribution system 100 to fully track the status and progression of each order as orders are fulfilled.
  • multi-platform e-commerce distribution system 100 are updated each time the external order is modified. Through this type of procedure using the headless multi-platform e-commerce distribution system 100, data such as shipment tracking numbers and order status may be made available to application developers and end customers.
  • the headless multi-platform e-commerce distribution system 100 provides seamless API integration.
  • the headless multi-platform e-commerce distribution system 100 collects and maintains accurate data in a uniform format across all platforms, which is the most complex aspect of the “order write-back” feature.
  • Each e-commerce platform has unique
  • the required data is collected during the checkout process in the headless multi-platform e-commerce distribution system 100 and/or from existing account configurations in the headless multi-platform e-commerce distribution system 100.
  • the required data is then seamlessly interfaced with the unique platform schemas, all while maintaining a consistent user experience on the headless multi-platform e-commerce distribution system 100.
  • the e-commerce distribution system 100 of obtaining real-time shipping and tax rates on the fly while pricing the cart in order to generate and submit accurate price data.
  • the headless multi-platform e-commerce distribution system 100 maintains a consistent state, and submits data at each step in the checkout flow.
  • the headless multi-platform e-commerce distribution system 100 creates and maintains an asynchronous external cart that maps to an internal cart in headless multi-platform
  • each call made to the cart endpoint in the headless multi-platform e-commerce distribution system 100 results in an immediate call in the background to the equivalent endpoint in the receiving e-commerce platform.
  • a request is made to create a new empty cart in the headless
  • an asynchronous request is made to create a new empty cart in the receiving e-commerce platform (e.g ., Shopify).
  • the headless multi-platform e-commerce distribution system 100 then maintains a connection with that new external cart, and as additional requests are performed on the internal cart of the headless multi-platform e-commerce distribution system 100 (/. e. , adding a product to the cart), that same action is performed on the external cart.
  • the data is translated from the unified schema of the headless multi-platform e-commerce distribution system 100 into the unique schema of the receiving e-commerce platform (e.g., Shopify).
  • the technological improvement of this process is that the headless multi-platform e-commerce distribution system 100 can obtain accurate pricing and shipping data directly from the external cart, instead of being required to interact with third-party shipping and tax API's to obtain that data.
  • This process of creating and maintaining an asynchronous external cart using the headless multi-platform e-commerce distribution system 100 is shown in Figure 5.
  • the user of the application 140 instructs the multi-platform distribution system 100 to create an internal cart on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to create an external cart.
  • the receiving e-commerce platform 500 sends an external cart ID back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the created cart information to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to add a product to the internal cart on the
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to add a product to the external cart.
  • the receiving e-commerce platform 500 sends a confirmation of the product addition to the external cart back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the confirmation of the product addition back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to set the shipping address for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to set the shipping address for the product on the external cart.
  • the receiving e-commerce platform 500 sends a confirmation of setting the shipping address for the product back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the confirmation of setting the shipping address for the product back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to set the billing address for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to set the billing address for the product on the external cart.
  • the receiving e-commerce platform 500 sends a confirmation of setting the billing address for the product back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the confirmation of setting the billing address for the product back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to request available shipping methods for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to request available shipping methods for the product on the external cart.
  • the receiving e-commerce platform 500 sends back the available shipping methods for the product back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends back the available shipping methods for the product back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to set the shipping method for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to set the shipping method for the product on the external cart.
  • the receiving e-commerce platform 500 sends a confirmation of setting the shipping method for the product back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the confirmation of setting the shipping method for the product back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to request the cart price for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 asynchronously instructs the receiving e-commerce platform 500 to request the cart price for the product on the external cart.
  • the receiving e-commerce platform 500 sends a confirmation of requesting the cart price for the product back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the confirmation of requesting the cart price for the product back to the application 140.
  • the user of the application 140 instructs the multi-platform distribution system 100 to request the cart completion for the product on the multi-platform distribution system 100.
  • the multi-platform distribution system 100 instructs payment system 700 to authorize payment for the product on the internal cart.
  • the payment system 700 sends payment authorization results for the product in the internal cart back to the
  • the multi-platform distribution system 100 sends a submit order instruction to the receiving e-commerce platform 500.
  • the receiving e-commerce platform 500 then sends order submission results back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 sends a request to the payment system 700 to capture payment for the product on the internal cart.
  • the payment system 700 sends payment capture results for the product in the internal cart back to the multi-platform distribution system 100.
  • the multi-platform distribution system 100 then sends the order back to the application 140.
  • the system 100 enables merchant configuration of necessary shipping, tax, and payment data for order write-back.
  • a merchant was required to go through an onboarding process that involved duplicating all of the relevant shipping, tax, and payment data they had already taken to configure on their e-commerce platform. This was a significant technological limitation.
  • the system 100 configured to interface with a receiving e-commerce platform 500, the system 100 combines data obtained from the merchant’s existing platform with connections to third-party tax and shipping APIs.
  • the connections to third-party tax and shipping APIs generate the available shipping methods, as well as automatically calculating the tax and shipping rates, without the need for additional configuration.
  • a direct connection is made to the merchant’s bank account so that funds may be dispersed directly to the merchant.
  • the system 100 may receive an immediate percentage of the transaction. If the purchase was through a third party (e.g., Facebook or Instagram), the third party may also be paid a percentage. In this implementation, the remainder of the purchase price goes to the original seller of the product.
  • This is a unique revenue splitting architecture that is part affiliate selling, part drop shipping, and part retailing. Notably, this unique revenue splitting architecture provides new ways for individuals, companies, application developers, and merchants to participate in the exchange of goods.
  • a transaction is created for each non-empty bag in the order.
  • a bag contains one or more products provided by a single merchant.
  • the total funds of each transaction are split between the merchant 120, the headless multi-platform e-commerce distribution system 100, and the application developer 140 (who is developing applications designed to interface with the system 100).
  • the transaction payment split is reversed, with each party automatically returning their portion of the funds to the original payment source.
  • the headless multi-platform e-commerce distribution system 100 tracks whether a product has been returned, as well as any actions related to that return, such as a refund of the transaction funds. For example, in the situation where a customer chooses to return one or more products to the merchant 120, a reversal of the transaction payment split is initiated.
  • this reversal of the transaction payment split is automatically triggered by the act of the merchant flagging the order as returned within their e-commerce platform.
  • order event listeners registered on the e-commerce platform notify the headless multi-platform e-commerce distribution system 100 of the one or more products being returned to the merchant 120.
  • the headless multi-platform e-commerce distribution system 100 then initiates the transaction reversal with the payment service provider.
  • the status of the order is updated on the e-commerce platform to flag it as refunded.
  • e-commerce distribution system 100 when a customer adds a new payment method (e.g ., credit card, debit card, bank account, and the like) to their account in the system 100, the payment method is“tokenized” and made available for both immediate and future use, as well as enabling multi-merchant payment check-out. Accordingly, when the customer uses this payment method to making a purchase, the payment method is charged and the transaction funds are directly sent to the merchant’s payout method, less any service fees of the headless multi-platform e-commerce distribution system 100. Significantly, when using the headless multi-platform e-commerce distribution system 100, funds are taken from the customer’s payment method at the time of payment capture, and sent directly to the merchant’s payout method, without first escrowing the funds in any intermediary account.
  • a new payment method e.g ., credit card, debit card, bank account, and the like
  • a‘vaulting’ technique within the headless multi-platform e-commerce distribution system 100.
  • this payment vaulting technique there is only one transaction fee associated with the transfer of funds from a customer to a merchant 120.
  • the merchant’s funds were first collected from the customer by an intermediary system, and then later disbursed to the merchant 120 from the intermediary system, there would be an ACH transaction fee in addition to the initial card processing fee.
  • the merchant’s portion of the product transaction proceeds is made immediately available to the merchant 120.
  • the headless multi-platform e-commerce distribution system 100 (or any other intermediary system) never acts as an escrow account that is responsible for the holding and protection for the merchant’s product transaction proceeds.
  • the headless multi-platform e-commerce distribution system 100 Due to the unique configuration of the headless multi-platform e-commerce distribution system 100, all“customer payment methods” and all “merchant payout methods” are vaulted within the same payment gateway (e.g., Stripe, Braintree, and the like). Accordingly, there is no need to create a new unique payment token for each merchant 120. Thus, the headless multi-platform e-commerce distribution system 100 enables multi-merchant check-out transactions. In the headless multi-platform e-commerce distribution system 100, when a customer adds a new payment method (e.g., credit/debit card) that method is also vaulted in the same payment gateway (e.g., Stripe, Braintree, and the like) as the merchants 120. Accordingly, this single gateway approach of the headless multi-platform e-commerce distribution system 100 enables a user to only have to vault their unique payment method once, and that unique payment method can be used across all merchants.
  • a new payment method e.g
  • Past attempts at multi-merchant applications involved integrating with multiple payment gateways, and required the user to enter their card details each time they shopped from a new merchant.
  • Past attempts at multi-merchant applications also required the merchant to provide access to their account on that payment gateway. Accordingly, when a customer's payment method was vaulted to a merchant’s account, it would only be available for future use when that customer was purchasing from that particular merchant. Thus, such past attempts at vaulted payment methods could not be shared across merchants or payment gateways, and required the customer to re-enter their card details each time they shopped from a new merchant.
  • the headless multi-platform e-commerce distribution system 100 uses a single gateway so that the customer only ever needs to enter their“customer payment method” details once per unique“customer payment method.”
  • the payment source from which funds originate when an order is placed is a secure token that represents a customer’s payment method.
  • This tokenized payment method may be a credit card or a bank account.
  • tokens There is no limit to the number of unique payment methods (i.e., tokens) a user can have.
  • the customer selected defaulted payment method is authorized.
  • the full amount is then charged for each bag on behalf of the merchant’s payment destination.
  • the bags do not have to be from the same merchant 120 since the headless multi-platform e-commerce distribution system 100 enables
  • a purchaser may shop and create a first bag of products from a first merchant, shop and create a second bag of products from a second merchant, shop and create a third bag of products from a third merchant, and then check-out with a single multi-merchant check-out transaction.
  • the merchant payment destination is the tokenized representation of the source merchant’s payout method, which is typically a bank account.
  • This tokenized payout method is where a merchant’s portion of the transaction funds are sent.
  • a customer’s payment method is charged for the total amount of the one or more bags, the charge is made on behalf of the merchant’s payout method.
  • the funds from the customer’s payment method are sent directly to the merchant 120 without requiring any intermediary accounts to be escrowed, as is necessary with some alternative transaction systems.
  • the headless multi-platform e-commerce distribution system 100 deducts application fees from the transaction order charge.
  • the application fees may include the service fee to the headless multi-platform e-commerce distribution system 100 and the commission earned by the developer who originated the sale. For example, in some implementations, if the total price of the products in a“bag” total was $100, and the merchant 120 agreed to a 15% total commission, then the total amount sent to the merchant’s payment destination would be $85, with the remaining $15 being collected by the headless multi-platform e-commerce distribution system 100.
  • the commission owed to the developer 140 is deducted from the $15 collected by the headless multi-platform e-commerce distribution system 100 and sent to the developer’s payment destination, along with any other payments, on a rolling basis.
  • the developer’s payment destination is the tokenized representation of the developer’s payout method, which is typically a bank account. This payout method is where a developer’s portion of the transaction proceeds is sent.
  • the headless multi-platform e-commerce distribution system 100 creates a two-sided e-commerce marketplace with a supply side and a demand side.
  • the supply side of the e-commerce marketplace includes merchants 120 and manufacturers that sell products. These supply side companies can use margin to incentivize different retailers or application developers 140 to sell their product.
  • the suppliers e.g., merchants 120
  • the suppliers are able to individually modify the rate of revenue they are willing to give to the demand-side individual or company that helped generate the transaction.
  • Merchants can increase the rate of revenue they are willing to offer to incentivize the demand-side individuals or companies to want to sell their product. Merchants can also decrease the rate of revenue they are willing to offer, to increase their transaction payout from the demand-side individuals or companies if, for example, their products are extremely popular and, thus, no additional incentives are required.
  • the headless multi-platform e-commerce distribution system 100 certain relationships between supply-side companies and demand-side companies will be created within this new two-sided e-commerce marketplace, as companies identify partners and ways to drive new sales and conversions for merchants.
  • the headless multi-platform e-commerce distribution system 100 facilitates these relationships by allowing a supplier (e.g., merchants 120) to set a“default” percentage rate of revenue, and also to create a“custom” percentage rate of revenue for a single company or even a single product.
  • the headless multi-platform e-commerce distribution system 100 if XYZ company has a really desirable new product, an application developer may really want to sell this product, and be willing to collect only 30% of the proceeds from all those sales, as opposed to the 50% margin that some retailers get.
  • the headless multi-platform e-commerce distribution system 100 facilitates this relationship between XYZ company and ABC application by enabling ABC application to sell this new product at a“custom” percentage rate of 30% of the revenue for this specific XYZ company product.
  • the demand-side companies in the two-sided e-commerce marketplace created by the headless multi-platform e-commerce distribution system 100 are the consumers 140 (e.g., applications and application developers through which end customers purchase products) the headless multi-platform e-commerce distribution system 100.
  • consumers 140 are often Internet application developers. For this demand-side of the two-sided e-commerce marketplace, these application developers 140 look for the supplier (e.g., merchants 120) that provides them with the highest potential for earnings (/. e. , percentage rate of revenue) on each transaction. In some implementations of the headless multi-platform e-commerce distribution system 100, the consumers 140/developers may reach out to certain suppliers (e.g., merchants 120) to try to negotiate a better percentage rate of revenue on each transaction.
  • suppliers e.g., merchants 120
  • the headless multi-platform e-commerce distribution system 100 creates this new two-sided e-commerce marketplace based upon the rate of margin a company is willing to give up in exchange for the sale. This capability has not previously existed in the e-commerce marketplace.
  • a talented developer/consumer 140 may develop a large audience, as well as high level of conversions (/.e., ratio of product views to product sales) based upon the communities that they serve.
  • the headless multi-platform e-commerce distribution system 100 provides a mechanism for such a talented developer/consumer 140 to obtain a better percentage rate of revenue on each transaction from the suppliers/merchants 120 who are desirous to work with such a talented developer/consumer 140.
  • many different types of applications 140 may interact with the headless multi-platform e-commerce distribution system 100.
  • different e-commerce platforms interface with the
  • Corresponding different applications are configured to interface with the commerce graph 400 of the headless multi-platform e-commerce distribution system 100 as part of the application program interface procedure.
  • These different applications may be categorized into groups, including, by way of example only, and not by way of limitation: Web apps, mobile apps, voice apps, messenger apps, augmented reality apps, and virtual reality apps.
  • Web apps are applications that exist almost entirely in a web interface, such as Facebook’s website and Google’s website (e.g., Google search).
  • Mobile apps are applications that exist via mobile devices, such as Instagram and Snapchat.
  • Voice apps are voice assistance applications that exist in various forms. Through voice services, companies create apps that enable users to buy products via voice commands, such as Amazon Echo, Amazon Alexa, Amazon Lex integration, Google Home, Google Cloud Dialog Flow, Cortana Intelligence Services integration, and Cortana native integration.
  • chat/bot/messages Some of which may or may not be automated.
  • Such applications include, by way of example only, and not by way of limitation: Facebook Messenger, Kik, WhatsApp, Signal, and Mezi.
  • augmented reality applications and virtual reality applications are still early in their development and market penetration, these applications can create a unique experience in conjunction with the headless multi-platform e-commerce distribution system 100 to enable individuals to buy products in the augmented reality overlay or virtual reality environment.
  • a virtual reality application may create a virtual reality
  • Figure 6 shows a processor-based device suitable for implementing computing infrastructure for the suppliers/merchants 120 and the developer/consumer 140, as well as the processor-based desktop and mobile devices that support the applications created by the developer for end user purchasers.
  • processor-executable instructions or logic such as program application modules, objects, or macros being executed by one or more processors.
  • processors can be practiced with various processor-based system configurations, including handheld devices, such as smartphones and tablet computers, wearable devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, personal computers (“PCs”), network PCs, minicomputers, mainframe computers, and the like.
  • handheld devices such as smartphones and tablet computers, wearable devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, personal computers (“PCs”), network PCs, minicomputers, mainframe computers, and the like.
  • PCs personal computers
  • network PCs minicomputers
  • mainframe computers mainframe computers
  • the processor-based device may, for example, take the form of a smartphone or wearable smart glasses, which includes one or more processors 606, a system memory 608 and a system bus 610 that couples various system components including the system memory 608 to the processor(s) 606.
  • the processor-based device will, at times, be referred to in the singular herein, but this is not intended to limit the implementations to a single system, since in certain implementations, there will be more than one system or other networked computing device involved.
  • Non-limiting examples of commercially available systems include, but are not limited to, ARM processors from a variety of manufactures, Core microprocessors from Intel Corporation, U.S.A., PowerPC microprocessor from IBM, Sparc microprocessors from Sun Microsystems, Inc., PA-RISC series microprocessors from Hewlett-Packard Company, and 68xxx series microprocessors from Motorola Corporation.
  • the processor(s) 606 in the processor-based devices of the headless multi-platform e-commerce distribution system 100 may be any logic processing unit, such as one or more central processing units (CPUs), microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), and the like.
  • CPUs central processing units
  • DSPs digital signal processors
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • the system bus 610 in the processor-based devices of the headless multi-platform e-commerce distribution system 100 can employ any known bus structures or architectures, including a memory bus with memory controller, a peripheral bus, and a local bus.
  • the system memory 608 includes read-only memory (“ROM”) 612 and random access memory (“RAM”) 614.
  • ROM read-only memory
  • RAM random access memory
  • a basic input/output system (“BIOS”) 616 which can form part of the ROM 612, contains basic routines that help transfer information between elements within processor-based device, such as during start-up. Some implementations may employ separate buses for data, instructions and power.
  • the processor-based device of the headless multi-platform e-commerce distribution system 100 may also include one or more solid state memories; for instance, a Flash memory or solid state drive (SSD), which provides nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the processor-based device.
  • solid state memories for instance, a Flash memory or solid state drive (SSD)
  • SSD solid state drive
  • the processor-based device can employ other nontransitory computer- or processor-readable media, for example, a hard disk drive, an optical disk drive, or a memory card media drive.
  • Program modules in the processor-based devices of the headless multi-platform e-commerce distribution system 100 can be stored in the system memory 608, such as an operating system 630, one or more application programs 632, other programs or modules 634, drivers 636 and program data 638.
  • the application programs 632 may, for example, include panning/scrolling 632a.
  • Such panning/scrolling logic may include, but is not limited to, logic that determines when and/or where a pointer (e.g., finger, stylus, cursor) enters a user interface element that includes a region having a central portion and at least one margin.
  • Such panning/scrolling logic may include, but is not limited to, logic that determines a direction and a rate at which at least one element of the user interface element should appear to move, and causes updating of a display to cause the at least one element to appear to move in the determined direction at the determined rate.
  • the panning/scrolling logic 632a may, for example, be stored as one or more executable instructions.
  • the panning/scrolling logic 632a may include processor and/or machine executable logic or instructions to generate user interface objects using data that characterizes movement of a pointer, for example, data from a touch-sensitive display or from a computer mouse or trackball, or other user interface device.
  • the system memory 608 in the processor-based devices of the headless multi-platform e-commerce distribution system 100 may also include communications programs 640, for example, a server and/or a Web client or browser for permitting the processor-based device to access and exchange data with other systems such as user computing systems, Web sites on the Internet, corporate intranets, or other networks as described below.
  • the communications program 640 in the depicted implementation is markup language based, such as Hypertext Markup Language (HTML), Extensible Markup Language (XML) or Wireless Markup Language (WML), and operates with markup languages that use syntactically delimited characters added to the data of a document to represent the structure of the document.
  • HTML Hypertext Markup Language
  • XML Extensible Markup Language
  • WML Wireless Markup Language
  • a number of servers and/or Web clients or browsers are commercially available such as those from Mozilla Corporation of California and Microsoft of Washington.
  • operating system 630 While shown in Figure 6 as being stored in the system memory 608, operating system 630, application programs 632, other programs/modules 634, drivers 636, program data 638 and server and/or browser can be stored on any other of a large variety of nontransitory processor-readable media (e.g ., hard disk drive, optical disk drive, SSD and/or flash memory).
  • nontransitory processor-readable media e.g ., hard disk drive, optical disk drive, SSD and/or flash memory.
  • a user of a processor-based device in the headless multi-platform e-commerce distribution system 100 can enter commands and information via a pointer, for example, through input devices such as a touch screen 648 via a finger 644a, stylus 644b, or via a computer mouse or trackball 644c which controls a cursor.
  • Other input devices can include a microphone, joystick, game pad, tablet, scanner, biometric scanning device, and the like.
  • ⁇ /O devices are connected to the processor(s) 606 through an interface 646 such as a touch-screen controller and/or a universal serial bus (“USB”) interface that couples user input to the system bus 610, although other interfaces such as a parallel port, a game port or a wireless interface or a serial port may be used.
  • the touch screen 648 can be coupled to the system bus 610 via a video interface 650, such as a video adapter to receive image data or image information for display via the touch screen 648.
  • the processor-based device can include other output devices, such as speakers, vibrator, haptic actuator or haptic engine, and the like.
  • the processor-based devices of the headless multi-platform e-commerce distribution system 100 operate in a networked environment using one or more of the logical connections to communicate with one or more remote computers, servers and/or devices via one or more communications channels, for example, one or more networks 614a, 614b.
  • These logical connections may facilitate any known method of permitting computers to communicate, such as through one or more LANs and/or WANs, such as the Internet, and/or cellular communications networks.
  • Such networking environments are well known in wired and wireless enterprise-wide computer networks, intranets, extranets, the Internet, and other types of communication networks including telecommunications networks, cellular networks, paging networks, and other mobile networks.
  • the processor-based devices of the headless multi-platform e-commerce distribution system 100 may include one or more network, wired or wireless communications interfaces 652a, 656 (e.g ., network interface controllers, cellular radios, WI-FI radios, Bluetooth radios) for establishing communications over the network, for instance, the Internet 614a or cellular network 614b.
  • network wired or wireless communications interfaces 652a, 656 (e.g ., network interface controllers, cellular radios, WI-FI radios, Bluetooth radios) for establishing communications over the network, for instance, the Internet 614a or cellular network 614b.
  • program modules, application programs, or data, or portions thereof can be stored in a server computing system (not shown).
  • server computing system not shown.
  • network connections shown in Figure 6 are only some examples of ways of establishing communications between computers, and other connections may be used, including wirelessly.
  • processor(s) 606, system memory 608, and network and communications interfaces 652a, 656 are illustrated as
  • the above-described components may be communicably coupled in a different manner than illustrated in Figure 6.
  • one or more of the above-described components may be directly coupled to other components, or may be coupled to each other, via intermediary components (not shown).
  • intermediary components not shown.
  • system bus 610 is omitted, and the components are coupled directly to each other using suitable connections.
  • communicative as in“communicative pathway,”“communicative coupling,” and in variants such as“communicatively coupled,” is generally used to refer to any engineered arrangement for transferring and/or exchanging information.
  • exemplary communicative pathways include, but are not limited to, electrically conductive pathways (e.g ., electrically conductive wires, electrically conductive traces), magnetic pathways ⁇ e.g., magnetic media), one or more communicative link(s) through one or more wireless communication protocol(s), and/or optical pathways ⁇ e.g., optical fiber), and exemplary communicative couplings include, but are not limited to, electrical couplings, magnetic couplings, wireless couplings, and/or optical couplings.
  • infinitive verb forms are often used. Examples include, without limitation: “to detect,”“to provide,”“to transmit,”“to communicate,”“to process,”“to route,” and the like. Unless the specific context requires otherwise, such infinitive verb forms are used in an open, inclusive sense, that is as“to, at least, detect,” to, at least, provide,”“to, at least, transmit,” and so on.
  • implementations disclosed herein, in whole or in part, can be equivalently implemented in standard integrated circuits, as one or more computer programs executed by one or more computers (e.g ., as one or more programs running on one or more computer systems), as one or more programs executed by one or more controllers ⁇ e.g., microcontrollers) as one or more programs executed by one or more processors ⁇ e.g., microprocessors, central processing units, graphical processing units), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of ordinary skill in the art in light of the teachings of this disclosure.
  • logic or information can be stored on any processor-readable medium for use by or in connection with any processor-related system or method.
  • a memory is a processor-readable medium that is an electronic, magnetic, optical, or other physical device or means that contains or stores a computer and/or processor program.
  • Logic and/or the information can be embodied in any processor-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a
  • a“non-transitory processor-readable medium” can be any element that can store the program associated with logic and/or information for use by or in connection with the instruction execution system, apparatus, and/or device.
  • processor-readable medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device. More specific examples (a non-exhaustive list) of the computer readable medium would include the following: a portable computer diskette (magnetic, compact flash card, secure digital, or the like), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory), a portable compact disc read-only memory (CDROM), digital tape, and other non-transitory media.
  • a portable computer diskette magnetic, compact flash card, secure digital, or the like
  • RAM random access memory
  • ROM read-only memory
  • EPROM erasable programmable read-only memory
  • CDROM compact disc read-only memory
  • digital tape digital tape

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système de distribution de commerce électronique multi-plateforme qui comprend un système de traduction de données bidirectionnelle, une plateforme de distribution de produits et une interface de programmation graphique de commerce. Le système de traduction de données bidirectionnelle extrait des données de produits et traduit les données de produits. La plateforme de distribution de produits comprend un catalogue de produits des produits pouvant être achetés contenant des informations qui ont été converties en un schéma de produits unifié. Le système de traduction de données bidirectionnelle traduit les informations de produits entre les formats d'un ou plusieurs marchands différents et le schéma de produits unifié de la plateforme de distribution de produits.
PCT/US2019/027086 2018-04-13 2019-04-11 Système et procédé de distribution de commerce électronique multi-plateforme sans tête WO2019200169A1 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US15/952,974 US11049160B2 (en) 2018-04-13 2018-04-13 Headless multi-platform e-commerce distribution system and method
US15/953,071 US20190318337A1 (en) 2018-04-13 2018-04-13 System and method for concurrent multi-merchant on-line shopping with a single check-out transaction
US15/952,978 US20190318402A1 (en) 2018-04-13 2018-04-13 Data translation system and method for multi-platform e-commerce system
US15/953,068 2018-04-13
US15/953,068 US11055757B2 (en) 2018-04-13 2018-04-13 Multi-platform e-commerce system with asynchronous cart
US15/952,974 2018-04-13
US15/952,978 2018-04-13
US15/953,071 2018-04-13
US15/953,059 2018-04-13
US15/953,059 US20190318413A1 (en) 2018-04-13 2018-04-13 Commerce graph api system and method for multi-platform e-commerce distribution system

Publications (1)

Publication Number Publication Date
WO2019200169A1 true WO2019200169A1 (fr) 2019-10-17

Family

ID=68163763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/027086 WO2019200169A1 (fr) 2018-04-13 2019-04-11 Système et procédé de distribution de commerce électronique multi-plateforme sans tête

Country Status (1)

Country Link
WO (1) WO2019200169A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112651800A (zh) * 2020-12-23 2021-04-13 上海阔程信息服务有限公司 一种基于智能算法的聚合跨境商品交易分发系统及方法
CN113592600A (zh) * 2021-08-02 2021-11-02 深圳市鑫启电子商务有限公司 一种多层级电商交易平台的构建方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002075597A2 (fr) * 2001-03-15 2002-09-26 Federation Web Inc. Procede et systeme de creation de depot de contenus de produits unifie virtuel
US20060271446A1 (en) * 2003-03-24 2006-11-30 Siebel Systems, Inc. Product common object
US20120078731A1 (en) * 2010-09-24 2012-03-29 Richard Linevsky System and Method of Browsing Electronic Catalogs from Multiple Merchants
US20130332838A1 (en) * 2012-06-11 2013-12-12 Cellco Partnership D/B/A Verizon Wireless Cross-platform content management interface
US20150339661A1 (en) * 2014-05-23 2015-11-26 Alibaba Group Holding Limited Performing transactions using virtual card values

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002075597A2 (fr) * 2001-03-15 2002-09-26 Federation Web Inc. Procede et systeme de creation de depot de contenus de produits unifie virtuel
US20060271446A1 (en) * 2003-03-24 2006-11-30 Siebel Systems, Inc. Product common object
US20120078731A1 (en) * 2010-09-24 2012-03-29 Richard Linevsky System and Method of Browsing Electronic Catalogs from Multiple Merchants
US20130332838A1 (en) * 2012-06-11 2013-12-12 Cellco Partnership D/B/A Verizon Wireless Cross-platform content management interface
US20150339661A1 (en) * 2014-05-23 2015-11-26 Alibaba Group Holding Limited Performing transactions using virtual card values

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EUGENIYA.: "How to Create a Two-Sided Online Marketplace Platform?", HACKERNOON, 6 January 2017 (2017-01-06), XP055645439, Retrieved from the Internet <URL:https://hackernoon.com/how-to-create-a-two-sided-online-marketplace-platform-6d10eb9c03db> [retrieved on 20190729] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112651800A (zh) * 2020-12-23 2021-04-13 上海阔程信息服务有限公司 一种基于智能算法的聚合跨境商品交易分发系统及方法
CN113592600A (zh) * 2021-08-02 2021-11-02 深圳市鑫启电子商务有限公司 一种多层级电商交易平台的构建方法及系统

Similar Documents

Publication Publication Date Title
US11763283B2 (en) Methods and apparatus for unified inventory and financial transaction management
US11195199B2 (en) System and method for enhanced commerce
US8768834B2 (en) Digital exchange and mobile wallet for digital currency
US20190026726A1 (en) Gift card conversion and digital wallet
US20190318337A1 (en) System and method for concurrent multi-merchant on-line shopping with a single check-out transaction
US20160155103A1 (en) Utilizing an electronic payment system to implement rebate programs
WO2015183901A9 (fr) Système et procédé pour plateforme logicielle de marché
US9477984B2 (en) Social media transactions system and methods
JP2012502377A (ja) 支払いアプリケーションフレームワーク
US20080177635A1 (en) Method, system, and apparatus for suggesting or requesting a proxy transaction
US11810171B2 (en) Multi-platform e-commerce system with asynchronous cart
US20210326953A1 (en) Headless multi-platform e-commerce distribution system and method
US8380624B2 (en) Person-to-person payments: contextual spending
KR20130015041A (ko) 거래 서비스를 제공하기 위한 방법 및 시스템
WO2019200169A1 (fr) Système et procédé de distribution de commerce électronique multi-plateforme sans tête
US20190318402A1 (en) Data translation system and method for multi-platform e-commerce system
US20190318413A1 (en) Commerce graph api system and method for multi-platform e-commerce distribution system
KR102550817B1 (ko) 셀럽을 통한 온라인 중개 서비스 제공 시스템 및 그 방법
Karunakar et al. E-commerce in India: evolution and growth

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19784907

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19784907

Country of ref document: EP

Kind code of ref document: A1