WO2019050414A1 - Procédé de transaction flottante retardée et mise en forme de comportement humain par l'intermédiaire d'un système de type dépôt - Google Patents

Procédé de transaction flottante retardée et mise en forme de comportement humain par l'intermédiaire d'un système de type dépôt Download PDF

Info

Publication number
WO2019050414A1
WO2019050414A1 PCT/NO2018/050225 NO2018050225W WO2019050414A1 WO 2019050414 A1 WO2019050414 A1 WO 2019050414A1 NO 2018050225 W NO2018050225 W NO 2018050225W WO 2019050414 A1 WO2019050414 A1 WO 2019050414A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
buyer
seller
trade
user
Prior art date
Application number
PCT/NO2018/050225
Other languages
English (en)
Inventor
Nawaf NAFISEE
Original Assignee
Nafisee Nawaf
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
Application filed by Nafisee Nawaf filed Critical Nafisee Nawaf
Publication of WO2019050414A1 publication Critical patent/WO2019050414A1/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
    • G06Q20/401—Transaction verification
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • 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
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing

Definitions

  • TITLE The Delayed Floating-Transaction Process: Shaping Human Behavior Through An Escrow Like System
  • the Delayed Floating-Transaction Process (DTFP here on in) is an electronic (digital) system and method for influencing human behavior.
  • the invention relates to the process in which a set of digital functions and graphics— created from a combination of vector images (buttons) and computer code (object oriented functions of buttons' behavior)— are combined with core principles of classical conditioning to form a process that enables specific, human behavioral responses in Users that lead to particularly desired out-comes.
  • the DFTP is a complex system of visual aids (vector graphics) and feed-back libraries (object-oriented code) combined to create a fictitious financial mechanism that mimics the escrow banking structure in order to guarantee digital agreements initiated between users within the Nordic territories to, ultimately, become finalized, on-spot transactions.
  • the main objectives of the present invention is to provide:
  • DFTP Delayed Floating Transaction Process
  • the above objectives are achieved through the implementation of the Delayed Floating Transaction Process (DFTP), which is a system comprising of a group of libraries, graphics, and components that creates tangible value through its digital mechanisms by ensuring the integrity of a contractual agreement.
  • the DFTP is simply introduced into a traditional E-commerce transaction after the point-in-time a Buyer initiates a purchase on the Content Management System's platform. This part of a transaction is called the "inflection point", because this is where the type of a transaction is determined.
  • the DFTP successfully avoids triggering any commerce laws that can adversely affect the Seller's level of risk and liability.
  • the present invention attains the above-described objective by executing a system of digital libraries, such as the DFTP and the Transaction Key system, collective and accordingly. Combined, these libraries form an overall processes that reduces, or even removes, any risk involved when executing credit transactions.
  • digital libraries such as the DFTP and the Transaction Key system
  • the present invention comprises a technological advantage over known systems and methods by use of the Transaction Key System, the Payment Gateway API, and custom-written object-oriented code to help all systems effectively interact with one another.
  • the present invention provides several further advantageous effects: )
  • Figs. 1A, 1 B, 1C, 1 D and 1 E show the problem of prior art regarding the floating transaction process in traditional e-commerce sale with shipping, divided in five parts;
  • Figs. 2A, 2B, 2C and 2D show the problem of prior art regarding the floating transaction process in traditional e-commerce sale with no shipping, divided in four parts;
  • Figs. 3A, 3B, 3C and 3D show an embodiment of the invention employing a delayed floating-transaction process, divided in four parts.
  • Fig. 4.7 shows DFTP system initiated, and transaction and trade have commenced.
  • Fig. 4.8 shows Buyer enters in payment information.
  • Fig. 4.9 shows Buyer enters payment address.
  • Fig. 4.10 shows Confirmation of order and further acceptance of contractual agreement terms.
  • Fig. 4.11 shows tutorial screen 1
  • Fig. 4.12 shows tutorial screen 2
  • Fig. 4.13 shows tutorial screen 3
  • Fig. 4.14 shows tutorial screen 4
  • Fig. 4.15 shows Notification system informing both Buyer & Seller of the purchase.
  • Fig. 5.0 shows Transaction Key system (key sent to Buyer), Chat protocol, and the Dispute system activate.
  • Fig. 5.1 shows Chat window
  • Fig. 5.2 shows Buyer & Seller arranging trade day and time.
  • Fig. 5.4 shows Transaction Key
  • Fig. 5.5 shows Seller inputs Transaction Key into his device.
  • Fig. 5.6 shows Transaction and trade have completed.
  • Fig. 5.7 shows Buyer reviews Seller.
  • Fig. 5.8 shows Buyer may leave a comment.
  • Fig. 5.9 shows Seller reviews Buyer.
  • Fig. 5.10 shows Seller may leave a comment.
  • Figs. 1 A, 1 B, 1C, 1 D and 1 E show the problem of prior art regarding the floating transaction process in traditional e-commerce sale with shipping
  • Figs. 2A, 2B, 2C and 2D show the problem of prior art regarding the floating transaction process in traditional e-commerce sale with no shipping. Due to size and
  • the underlying principle is that after the user initiates a purchase an inflection points occur where the transaction becomes either floating (FTP) or delayed-floating (DFTP).
  • FTP floating
  • DFTP delayed-floating
  • Figs. 3A, 3B, 3C and 3D show an embodiment of the delayed-floating transaction (DFTP) because the platform API initiates the DFTP instead of the payment gateway protocol first.
  • DFTP delayed-floating transaction
  • the embodiment of the apparatus according to the invention shown in Fig. 3 comprises a CMS trade set of components indicated in brackets in addition to more traditional components. It should be noted that in the DFTP the platform API initiates gateway API for payment protocol after this bracket.
  • the invention according to the application finds use in multiple environments and case-uses.
  • the DFTP can be implemented in any digital mechanism that requires a verification system that allows for the safe transfer of data between users without having the risk of any liabilities.
  • the Delayed Floating Transaction System (DFTS)
  • this is the first step of the entire Transaction process.
  • a User desires to check out and purchase the item(s) they have added to their digital shopping cart. They must first verify that the items in the cart are what they want by being
  • step #8 buttons in order to return to the previous screen, shown in step #1, and rectify any discrepancies that may have occurred in the order.
  • step #4 This brings User to step #7.
  • step #9 navigates the User to step #1 (via step #9).
  • the User-input then sends the information
  • step #1 as described in step #9.
  • the DFTP initiates a Trade Process Countdown as well as generating a Transaction Key. These elements work as a security measure for the Buyer. If the Transaction Key is not used within 14 days, the transaction will be Terminated for both parties. This is an active process that occurs simultaneously while the other DFTP steps are occurring (Steps #14 through #32).
  • the DFTP takes the information supplied by the Seller's uploaded item(s), along with the Buyer's Shopping Cart, to start the process of generating the different notifications as explained in steps #16 through #21.
  • a Security Key is generated to be used in the On- Spot Transaction that will occur when Buyer and Seller meet for the finalization of the Purchase in step #32.
  • the system generates Notifications to be sent out to both the Buyer and the Seller,
  • the Security Key which was Generated in step # 14c is then sent as a Push-Notification to the Buyer for the On-Spot Transaction that will occur when the Buyer meets the Seller in step #22.
  • the Demerit & Reward System is then opened for the Parties to give their Reviews of the Transaction Process, each other and the Condition of the Item(s) provided.
  • the Communication opens for the Buyer and Seller to agree on time and Location for the On-Spot Transaction to occur, and if there should be any other agreements or questions that they would like to discuss.
  • the Buyer inspects the Item(s) to see if they are in the condition the Seller has described on the product profile, and if all the Item(s) ordered are present at the Time.
  • the Buyer will share the Transaction Key with the Seller for the On-Spot Transaction to occur, in order to initiate step #30.
  • step #30 the User that is affected will be sent to the Dispute Process (step #30), which will determine the outcome, and who will be penalized for it.
  • Dispute Type #1 Dispute Agent(s) figures out who's liable
  • the Trade-data is then forwarded to the Dispute Agent(s) that is assigned to the dispute-ticket, who will, as a policy, first recommend for both Parties to reschedule a new Date, Time & Location for fulfilling the in-limbo trade, but only if either Party did not attend the agreed upon meeting location. If, however, the Buyer does not have sufficient funds to fulfill the transaction within the trade, then the Buyer will be automatically penalized and the transaction will terminate and not occur.
  • the excusable party is then granted access to the Demerit and Reward System to give his feedback to the liable party's User Record.
  • Buyer Dispute Type IB Seller does not show.
  • Dispute Agent(s) recommends both Parties to reschedule a new Date, Time & Location for fulfilling the in-limbo trade.
  • Buyer Dispute Type 2B Item is grossly different from advertised product listing Solution for dispute Type 2B: Each Party must send seven photos to the Dispute Agent(s), depicting the discrepancies. The Part at fault will be penalized, the transaction will terminate and not occur. The excusable party is then granted access to the Demerit and Reward System to give feedback to the liable Party's User Record.
  • Solution for dispute Type 3B The Seller will be penalized, the transaction will terminate and not occur. The excusable party is then granted the access to the Demerit and Reward System to give feedback to the liable Party's User Record.
  • Dispute Agent(s) recommend for both Parties to reschedule a new Date, Time & Location for fulfilling the in-limbo trade.
  • Tvpe 3S Buver attempts to opt out of trade without proper reason Solution to dispute
  • tvpe 3S The Buver will be automatically penalized and the transaction will terminate and not occur.
  • the excusable party is then granted the access to the Demerit and Reward System to give his feedback to the liable party's User Record.
  • the Seller inputs the Transaction Key, that has been provided by the Buyer, to successfully initiate an On-Spot Transaction.
  • the Platform API OpenCart
  • the Platform API checks the Transaction Key's validity. If the
  • step #33 the Payment Gateway API (Stripe) in order to send the trade data to the Payment Gateway API (Strip). Then the system initializes step #33; otherwise, if the Transaction Key is invalid, the System will reject the Key with a rejection message, and return the User to the same field where he/she can input the correct Transaction Key. will be sent to the Dispute Process (step #29), which will determine what happened for the transaction not to occur, and which party that will be penalized for it, which in this case will be the Buyer.
  • the System checks the Buyer's bank card and it does not have the required funds for the transaction on account, the System will reward the Buyer with an automatic demerit, and will be penalized accordingly. This stage is automatic, and will not need any manual dispute resolution.
  • the Amount will be Charged from the Buyers Bank Card
  • the Payment Gateway (Stripe) will then charge the Buyer for amount of the total asking price for the Item(s) as previously agreed upon between the Buyer and the Seller.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système et un procédé de protection des parties commerciales d'une organisation de transaction vis-à-vis du risque et de la responsabilité.
PCT/NO2018/050225 2017-09-07 2018-09-07 Procédé de transaction flottante retardée et mise en forme de comportement humain par l'intermédiaire d'un système de type dépôt WO2019050414A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO20171451 2017-09-07
NO20171451 2017-09-07

Publications (1)

Publication Number Publication Date
WO2019050414A1 true WO2019050414A1 (fr) 2019-03-14

Family

ID=65634137

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NO2018/050225 WO2019050414A1 (fr) 2017-09-07 2018-09-07 Procédé de transaction flottante retardée et mise en forme de comportement humain par l'intermédiaire d'un système de type dépôt

Country Status (1)

Country Link
WO (1) WO2019050414A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002059818A1 (fr) * 2001-01-26 2002-08-01 Accenture Llp Procede destine a une fonction de contrat de depot au cours d'une transaction utilisant un cadre de base de donnees d'adresses electroniques/physiques
US20020125312A1 (en) * 1999-05-15 2002-09-12 Ogilvie John W.L. Automatic broker tools and techniques
US20140089117A1 (en) * 2012-09-24 2014-03-27 Curenci, Llc Secure Escrow Transaction System
US20140214689A1 (en) * 2008-01-31 2014-07-31 The Western Union Company Systems and methods to facilitate payment of shipped goods

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020125312A1 (en) * 1999-05-15 2002-09-12 Ogilvie John W.L. Automatic broker tools and techniques
WO2002059818A1 (fr) * 2001-01-26 2002-08-01 Accenture Llp Procede destine a une fonction de contrat de depot au cours d'une transaction utilisant un cadre de base de donnees d'adresses electroniques/physiques
US20140214689A1 (en) * 2008-01-31 2014-07-31 The Western Union Company Systems and methods to facilitate payment of shipped goods
US20140089117A1 (en) * 2012-09-24 2014-03-27 Curenci, Llc Secure Escrow Transaction System

Similar Documents

Publication Publication Date Title
US11250493B2 (en) System and method for performing social media cryptocurrency transactions
US10497037B2 (en) System and method for managing cryptocurrency payments via the payment request API
TW464809B (en) Systems and digital computers for facilitating trade in goods and/or services
US8392275B2 (en) Identifier-based charge on delivery transaction
US9047639B1 (en) Service participation acknowledgement system
US20150220892A1 (en) Platform for the purchase and sale of digital currency
US9734489B2 (en) Transaction split fees
TW200412524A (en) A small amount paying/receiving system
US20050246268A1 (en) Funds transfer method and system
US9741074B2 (en) Dynamic handling for resource sharing requests
US11270280B2 (en) Obtaining instant credit at a POS with limited information
US20140279451A1 (en) Escrow Payment System for Transactions
US20200380485A1 (en) Product based gift card
US7634440B2 (en) Secure, objective online exchange, confirmation and evaluation methods
JP2022025514A (ja) 情報処理方法、情報処理装置、プログラム、及び現金自動預払機
US20160048815A1 (en) Payment service provision with reduced transaction costs
US20210174348A1 (en) Electronic escrow system
WO2019050414A1 (fr) Procédé de transaction flottante retardée et mise en forme de comportement humain par l'intermédiaire d'un système de type dépôt
US20140244481A1 (en) Online multi payment system
US20170372280A1 (en) System and method for decoupling an e-commerce order from the electronic payment transaction
JP7299713B2 (ja) プログラム、情報処理装置、及び情報処理方法
KR101198404B1 (ko) 기업간 즉시 결제 시스템
US11170419B1 (en) Methods and systems for transaction division
US20220277277A1 (en) Transaction system and method
AU2018220069A1 (en) Systems and methods for enabling group payment transactions

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: 18853322

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: 18853322

Country of ref document: EP

Kind code of ref document: A1