WO2020009661A1 - Système et procédé destinés à effectuer une évaluation d'au moins un bien/service - Google Patents

Système et procédé destinés à effectuer une évaluation d'au moins un bien/service Download PDF

Info

Publication number
WO2020009661A1
WO2020009661A1 PCT/SG2019/050330 SG2019050330W WO2020009661A1 WO 2020009661 A1 WO2020009661 A1 WO 2020009661A1 SG 2019050330 W SG2019050330 W SG 2019050330W WO 2020009661 A1 WO2020009661 A1 WO 2020009661A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
good
central server
user
user device
Prior art date
Application number
PCT/SG2019/050330
Other languages
English (en)
Inventor
Timothy M. Lee
Original Assignee
Circl Pte. Ltd.
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 Circl Pte. Ltd. filed Critical Circl Pte. Ltd.
Publication of WO2020009661A1 publication Critical patent/WO2020009661A1/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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0203—Market surveys; Market polls
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0278—Product appraisal
    • 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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0282—Rating or review of business operators 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present invention relates to a system and method for carrying out an appraisal for at least one good/service.
  • a common method of ordering goods and services is for consumers to visit the merchant website, view items, add them to a virtual shopping cart, and then check out using a merchant designed check out flow. Such methods typically require several steps which differ from merchant to merchant. This can be frustrating and inconvenient for consumers.
  • Some payment entity services such as, for example, PayPalTM, Amazon PaymentsTM, Visa CheckoutTM, and MasterCard PaypassTM have attempted to simplify this process by setting up cloud based digital accounts/wallets to carry out requisite transactions.
  • PayPalTM Amazon PaymentsTM
  • Visa CheckoutTM Visa CheckoutTM
  • MasterCard PaypassTM have attempted to simplify this process by setting up cloud based digital accounts/wallets to carry out requisite transactions.
  • these solutions do not normalize the process of browsing and selecting items, and are also exposed to a number of types of fraud attacks.
  • a man-in- the-middle attack can be perpetrated at a merchant whose payment pages have been compromised, whereby instead of redirecting consumers to a cloud based payment solution, consumers are instead redirected to a fraudulent website.
  • Payment information can then be collected at the fraudulent website and subsequently transmitted to the cloud based payment solution, unbeknownst to the merchant, cloud based payment solution, and customer. This stolen payment information can then be used to carry out a fraudulent transaction(s). Fraudulent transactions resulting from such attacks result in billions of dollars of losses for financial institutions. Much of these costs are eventually borne by consumers and merchants.
  • the availability of tablet computers have enabled a new generation of digital ordering solutions.
  • Merchants commonly restaurants, are deploying tablet computer based ordering devices from which consumers may order goods and services when at the premises.
  • the cost of many of such deployments is high since they typically entail costs such as, for example, multiple device purchases, software, staff training, installation, integration, customer support, maintenance and so forth.
  • Many consumers find these devices less intuitive and less desirable compared to traditional ordering.
  • Some of these solutions provide devices that offer self-checkout payment solutions which are typically also not well received by consumers. It is unfortunate if consumers boycott the merchants due to the digital ordering solutions, particularly after the expense laid out by the merchants.
  • Another method of ordering goods and services is by enabling consumers to generate orders by capturing graphical indicia, such as two or three dimensional barcodes which embed information on data representing items and/or locations.
  • graphical indicia such as two or three dimensional barcodes which embed information on data representing items and/or locations.
  • One disadvantage of graphical indicia is that there are typically constraints in order for the graphical indicia to be appropriately captured. For example, capturing three dimensional barcodes (QR codes) requires the reader to be within a certain distance and have minimum lighting conditions.
  • QR codes three dimensional barcodes
  • a second and related disadvantage is that graphical indicia create clutter on menus and catalogs. The combination of these two disadvantages is problematic if the menu is located away from the consumer.
  • a third disadvantage is that many consumers dislike/are averse to scanning graphical indicia. Common consumer complaints include, for example, not knowing how to scan such indicia, confusion as to which mobile app to use, not being able to appropriately
  • NFC near field communication
  • the total number of ratings for X users across Y items is a product of X and Y, which grows exponentially as X and Y increase. Each of these ratings may need to be recalculated with each new rating input. This can result in marginal costs becoming greater than marginal revenue. In addition, marginal processing time may become longer than acceptable latency to users, making personalized ratings difficult.
  • Another shortcoming relates to how existing rating systems do not provide sufficient granularity to easily differentiate top rated items.
  • On a typical 5-star rating system using a single decimal for presentment of ratings there are only 11 rating categories for items with a high rating from 4.0 to 5.0, and this is especially problematic if there are millions of items in a category, e.g. books or restaurants.
  • a 5-star rating system may present its results with three decimals, thus creating 5000 possible rating scores. However, the more detailed rating is not necessarily statistically significant.
  • asking users to rate items on a 5000 point scale will lead to fewer and less consistent ratings.
  • Ordering apps typically accept credit cards as their main form of payment instead of physical currency. Handling physical currency typically adds additional steps/inconveniences/vulnerabilities to transaction processing. However, some users prefer to use physical currency due to long established behavioral habits and are reluctant to embrace full cashless payments.
  • system for carrying out an appraisal for at least one good/service, the system including one or more data processors configured to:
  • the rating is dependent on an aggregation of votes received at the central server.
  • FIG 1 is a flow chart of an example of a method for carrying out an appraisal for at least one good/service
  • FIG 2 is a schematic diagram of an example of a system for carrying out an appraisal for at least one good/service
  • FIG 3 is a schematic diagram showing components of an example user device of the system shown in FIG 2;
  • FIG 4 is a schematic diagram showing components of an example server shown in FIG 2;
  • FIG 5 is a schematic diagram showing components of an example payment system shown in FIG 2;
  • FIGs 6 to 16 respectively show specific examples of a method for carrying out an appraisal for at least one good/service.
  • Embodiments of the present invention provide users with a method and system for carrying out an appraisal for at least one good/service.
  • the method and system can be carried out for a desired merchant in a situation where a user carrying out the appraisal need not be using a device connected to the Internet.
  • the appraisal for the at least one good/service is also carried out in a manner which is less subjective and more equitable.
  • the method can be performed at least in part using one or more electronic processing devices which form part of a user device, such as mobile phones, portable computers, tablet computers, wearable devices, or the like.
  • the user device is typically also in communication with a merchant device and a central server.
  • the merchant device can also be, for example, mobile phones, portable computers, tablet computers, wearable devices, point-of-sale devices, kitchen appliances or the like.
  • the central server can be administered by an entity administering to ratings of respective merchants/goods/services (rating entity).
  • the central server is communicatively coupled to a payment system which may include a number of processing devices associated with each of an issuer, acquirer, stored value payment system, card network and payment gateway, or alternatively, the payment system may be any one or more of these entities and this will be discussed further below.
  • a payment system which may include a number of processing devices associated with each of an issuer, acquirer, stored value payment system, card network and payment gateway, or alternatively, the payment system may be any one or more of these entities and this will be discussed further below.
  • payment is carried out using conventional non-cashless, handing over of currency type of processes. It should be noted that the handing over of currency can be carried out as either an advance payment, or upon completion of a requisite task/service.
  • merchant can be used to refer to a group of merchants, whereby the merchants in the group can be associated by, for example, having a common owner, providing similar goods/services, being part of an alliance, and so forth.
  • the one or more electronic processing devices initiate a request for a good/service into an application provided by the rating entity.
  • the request can include data to identify a specific good/service from a merchant, for example, a serial/item number of a good, a merchant ID providing the service, a name of the good/service, any combination of the aforementioned, and so forth.
  • initiating the request is dependent on a graphical user interface of the application provided by the rating entity (rating application).
  • the rating entity can partner with one or more entities to provide the application.
  • the graphical user interface may be a website, web portal and so forth.
  • the user can key in respective IDs, can select respective goods/services from a list, can choose an image representing the good/service and so forth.
  • the good/service ID can also be determined from, either one dimensional barcodes or two dimensional barcodes. In such instances, images of the barcodes are captured using an image capturing device of the user device.
  • the application is integrated into a third party application, for example, applications provided by the user’s banking institution or by a retailing entity.
  • the one or more electronic processing devices transmit at least one request for the good/service which was input at step 110.
  • the at least one request can be akin to the user making an order for the desired good/service such that a merchant will be informed of what the user desires to purchase.
  • the user will be informed via the application if the order for the good/service cannot be fulfilled by the merchant, which can be helpful in minimising disappointment for the user as the user will be able to seek out another merchant who provides the desired good/service, and/or which can also allow a change for the order.
  • the one or more electronic processing devices initiates a payment request such that the desired good/service can be paid for by the user. This can be carried out either before or after consumption of the desired good/service by the user.
  • the payment can be carried out using cashless processes, such as, for example, by using the digital wallet(s) of the user, whereby funds are credited to the merchant's account digitally for consumption of the desired good/service by the user.
  • the digital wallet application can be provided by a third party, such as, for example, MasterPassTM, AppleTM Pay, GoogleTM Pay, or the like.
  • the application can incorporate a stored value account functionality, which provides the user with access to, for example, a proprietary stored value account, bank accounts, prepaid instruments, PayPalTM accounts, AlipayTM accounts, and so forth.
  • the payment can be carried out using conventional non-cashless, handing over of physical currency type of processes.
  • the payment request (processed by the central server) can include both a request for payment amount by the user, and a request for an acknowledgement of receipt by the merchant. In this regard, once the payment request is appropriately processed, the merchant is able to receive payment for providing the user with the desired good/service.
  • the central server then transmits the funds to the user electronically. It should be appreciated that this timely payment to the merchant is advantageous in relation to loss of takings due to dishonesty amongst staff of the merchants, and the prompt payment for the good/service provided by the merchant also aids in maintaining a positive cash flow for the merchant.
  • step 140 processing is carried out of the at least one request so as to determine a vote allocation for the user.
  • the vote allocation depends on many aspects, for example, the user's spending behaviour, the user's social media influence, the user's activeness on social media, and so forth.
  • Other aspects being considered include, for example, aggregation of transaction counts, transaction amounts, merchant counts, merchant amounts, merchant category counts, merchant category amounts, item counts, item category counts, item amounts, item category amounts, transaction category counts, transaction category amounts, frequency of transactions, regularity of transactions, payment type, transaction status (rejected, refunded), instances of participating in reviewing/rating/ranking/connecting/referring/following/upvoting/liking a good/service, merchant, contributing media (a photo, a video, and/or a sound recording), and so forth.
  • Determining the vote allocation for users aids in preventing biased ratings and unequitable ratings. For example, a user who is more familiar with a particular sort of cuisine (more transactions for meals of the particular sort of cuisine) will have a higher vote allocation for that particular sort of cuisine as the user would be considered to be an expert in the particular sort of cuisine, so the higher vote allocation would be advantageous in ensuring that the users are unlikely to be unaware of what they are voting for.
  • vote allocation includes applying different weights based on demographic data, and/or collaborative filtering. In some embodiments, the voting allocation is also based on a categorisation of the user.
  • Scoring of the votes can include using placed vote data to calculate a count, rank, percentile, weight, rating, grade, award, medal, tier, and/or a proprietary rating.
  • the users when the users participate in voting, the users are provided with recognition for participating in voting.
  • provision of the scoring of the votes is restricted only to some users.
  • incentives like reward points, promotional pricing, and the like are provided to users to incentivise them to provide votes, so that there is a wide base of voters and high numbers of votes which aid in normalizing the scoring of the votes.
  • ratings of the at least one good/service are determined based on aggregation of votes, whereby a wide base of voters and high numbers of votes aid in normalizing the scoring of the votes, correspondingly providing a reliable voting score for the at least one good/service.
  • embodiments of the present invention aid in minimising disappointment for the user as the user will be able to seek out another merchant who provides the desired good/service during instances of a shortage of the desired good/service.
  • Embodiments of the present invention are also able to minimise loss of takings due to dishonesty amongst staff of the merchants, and also aids in maintaining a positive cash flow for the merchant.
  • determining the vote allocation for users aids in preventing biased ratings and unequitable ratings.
  • incentivising users to provide votes also leads to a wide base of voters and a high numbers of votes which aid in normalizing the scoring of the votes, correspondingly provides a reliable voting score for the at least one good/service.
  • the system 200 includes one or more user and merchant devices 220 running a rating application which can incorporate a digital wallet application, a communications network 250, a central server 260, and a payment system 240 in communication with a database 241.
  • the one or more user and merchant devices 220 are in communication with each other, and the central server 260 using a wireless communication technology such as, for example, BluetoothTM, IEEE 802.11, Wi-Fi Direct, AirPlayTM, and so forth.
  • the central server 260 is in communication with the payment system 240 via the communications network 250.
  • the communications network 250 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs). It will be appreciated that the configuration shown in FIG 2 is for the purpose of example only.
  • the user/merchant device 220 of any of the examples herein may be a handheld computer device such as a smart phone or a PDA such as one manufactured by AppleTM, LGTM, HTCTM, BlackberryTM, SamsungTM, HuaweiTM, HuaweiTM, HuaweiTM, HuaweiTM, HuaweiTM, HuaweiTM, GoogleTM, SonyTM, and so forth.
  • the user/merchant device 220 may include a mobile computer such as a tablet computer.
  • the user/merchant device 220 may also include a wearable device like a smartwatch.
  • An exemplary embodiment of a user/merchant device 220 is shown in FIG 3. As shown, the device 220 includes the following components in electronic communication via a bus 306:
  • non-volatile memory 303
  • RAM random access memory
  • transceiver component 305 that includes N transceivers
  • FIG 3 is not intended to be a hardware diagram; thus many of the components depicted in FIG 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG 3.
  • the display 302 generally operates to provide a presentation of content to a user, and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector and OLED displays). And in general, the non-volatile memory 303 functions to store (e.g., persistently store) data and executable code including code that is associated with the functional components of a browser component and applications, and in one example, a rating application (incorporating a digital wallet application) 309.
  • a rating application incorporating a digital wallet application
  • the non-volatile memory 303 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation of one or more portions of the payment application 308 as well as other components well known to those of ordinary skill in the art that are not depicted for simplicity.
  • the non-volatile memory 303 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well.
  • the executable code in the non-volatile memory 303 is typically loaded into RAM 304 and executed by one or more of the N processing components 301.
  • the N processing components 301 in connection with RAM 304 generally operate to execute the instructions stored in non-volatile memory 303 to effectuate the functional components.
  • the N processing components 301 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.
  • the transceiver component 305 includes N transceiver chains, which may be used for communicating with external devices via wireless networks.
  • Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme.
  • each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS networks), and other types of communication networks.
  • the transceiver component 305 can also use a wireless communication technology such as, for example, BluetoothTM, IEEE 802.11, Wi-Fi Direct, AirPlayTM, and so forth.
  • the image capture module 310 includes an image sensor, which may be used for capturing images of either one or two dimensional barcodes for determining the good/service ID.
  • the image capture module 310 can be a camera or a dedicated barcode reader.
  • the central server 260 of any of the examples herein may be formed of any suitable processing device, and one such suitable device is shown in FIG 4.
  • a processing device is provided by a computer system 400 in communication with a database 401, as shown in FIG 4.
  • the computer system 400 is able to communicate with the user/merchant devices 220, the payment system 240, and/or other processing devices, as required, over a communications network 250 or directly with the respective devices.
  • the components of the computer system 400 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 250 for communication. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs) or field programmable gate arrays.
  • ASICs application specific integrated circuits
  • the computer system 400 is a commercially available server computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the computer system 400 are implemented in the form of programming instructions of one or more software components or modules 402 stored on non-volatile (e.g., hard disk) computer- readable storage 403 associated with the computer system 400.
  • At least parts of the software modules 402 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays (FPGAs).
  • ASICs application-specific integrated circuits
  • FPGAs field programmable gate arrays
  • the computer system 400 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 405 :
  • RAM random access memory
  • USB universal serial bus
  • NIC network interface connector
  • a direct interface connector which connects the computer system 400 to the user/merchant devices 220 using a wireless communication technology such as, for example, BluetoothTM, IEEE 802.11, Wi-Fi Direct, AirPlayTM, and so forth; and d. a display adapter 408.3, which is connected to a display device 410 such as a liquid-crystal display (LCD) panel device.
  • the computer system 400 includes a plurality of standard software modules, including:
  • OS operating system 411 (e.g., Linux or Microsoft Windows);
  • web server software 412 e.g., Apache, available at http://www.apache.org
  • scripting language modules 413 e.g., personal home page or PHP, available at http://www.php.net, or Microsoft ASP;
  • SQL structured query language
  • SQL modules 414 e.g., MySQL, available from http://www.mysql.com, which allow data to be stored in and retrieved/accessed from an SQL database 416.
  • the web server 412, scripting language 413, and SQL modules 414 provide the computer system 400 with the general ability to allow users of the Internet 250 with standard computing devices equipped with standard web browser software to access the computer system 400 and in particular to provide data to and receive data from the database 401.
  • the specific functionality provided by the system 400 to such users is provided by scripts accessible by the web server 412, including the one or more software modules 402 implementing the processes performed by the computer system 400, and also any other scripts and supporting data 415, including markup language (e.g., HTML, XML) scripts, PHP (or ASP), and/or CGI scripts, image files, style sheets, and the like.
  • markup language e.g., HTML, XML
  • PHP or ASP
  • CGI scripts image files, style sheets, and the like.
  • modules and components in the software modules 402 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules.
  • the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers.
  • alternative embodiments may combine multiple instances of a particular module or submodule.
  • the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention.
  • Such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC), or the like.
  • CISC complex instruction set computer
  • FPGA field- programmable gate array
  • ASIC application-specific integrated circuit
  • Each of the steps of the processes performed by the computer system 400 may be executed by a module (of software modules 402) or a portion of a module.
  • the processes may be embodied in a non-transient machine-readable and/or computer-readable medium for configuring a computer system to execute the method.
  • the software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module.
  • the computer system 400 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices 408.
  • a computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process.
  • a parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.
  • central server 260 can be administered by a rating entity.
  • a suitable payment system 240 for use in the system described in any of the above examples is shown in FIG 5. It should be appreciated that the payment system 240 as shown can also be known as a payment module with tasks executed on at least one server.
  • the payment system 240 is a server (though in practice, the system 240 will comprise multiple such servers) that includes at least one microprocessor 500, a memory 501, an optional input/output device 502, such as a display, keyboard, touchscreen and the like, and an external interface 503, interconnected via a bus 504 as shown.
  • the external interface 503 can be utilised for connecting the payment server 240 to the communication networks 250, databases 241, other storage devices, or the like.
  • a single external interface 503 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.
  • the microprocessor 500 executes instructions in the form of applications software stored in the memory 501 to allow communication with the central server 260, for example to process payment required at the central server 260.
  • the applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.
  • the payment system 240 may be formed from any suitable processing system, such as any electronic processing device, including a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
  • the processing system is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential.
  • the payment system 240 is formed of multiple computer systems interacting, for example, via a distributed network arrangement. As distributed networking is known in the art, it will not be described further in more detail.
  • the payment system 240 may include or be in communication with a number of processing systems associated with each of an issuer, acquirer, card network and payment gateway, or alternatively, the payment system may be any one or more of these entities.
  • any number of the processing systems is enabled by verification of biometric information of the user.
  • the biometric information of the user can include, for example, fingerprints, retinas, and so forth.
  • the payment system 240 sends the user account information and payment information to the merchant's acquirer.
  • the acquirer requests that the card network get an authorization from the user's issuing bank.
  • the card network submits the transaction to the issuer for authorization and the issuing bank then authorizes the transaction if the account has sufficient funds to cover the amount payable.
  • the issuer then routes payment to the acquirer (in subsequent settlement and clearance processes as known in the art) who then deposits the payment into the merchant's account.
  • the payment system 240 alternatively manages a stored value system whereby users prepay funds into a prepaid account set up for the user to debit or credit.
  • the central server 260 can be configured to validate the number of credits remaining in the prepaid account and deduct from the account as appropriate.
  • the payment system 240 manages a subscription or credit system whereby users pay for a subscription or credit for recurring supply of pre -determined goods/services.
  • the payment system 240 can be configured to do periodic or ad hoc payments. Access to goods/services can be managed according to the level of the subscription and/or the number of credits purchased.
  • the payment processing does not require immediate payment processing, but rather the central server 260 validates whether the user account has a subscription that was previously paid or otherwise granted by the central server 260.
  • the central server 260 can validate the number of credits remaining in the user account and deduct from these credits as appropriate.
  • the first implementation relies on a central server being communicatively coupled to a user device and a payment system.
  • the method is carried out in the following manner:
  • the user device is used to select a merchant, the instructions being input to the central server.
  • the central server then optionally provides a menu associated with the merchant to the user device.
  • the user device is then used to submit at least one request (order) for the at least one good/service to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then optionally transmits an acknowledgement of receipt to the user device. 6) The central server then provides a vote allocation to the user device, possibly in the same message as step 5, in accordance to parameters as mentioned in an earlier portion of the description.
  • the user device is then used to provide a vote to the central server, whereby the central server tracks and/or counts the vote.
  • the central server then applies a requisite payment or credit to a respective merchant account.
  • FIG 7 there is shown a second detailed implementation of the method. It should be noted that the second implementation relies on a central server being communicatively coupled to a user device, a merchant device and a payment system. The method is carried out in the following manner:
  • the user device is used to select a merchant, the instructions being input to the central server.
  • the central server then provides a menu associated with the merchant to the user device.
  • the user device is then used to submit at least one request (order) for the at least one good/service to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the merchant device then optionally transmits an acknowledgement to the central server.
  • the merchant then proceeds to provide the at least one good/service to the user as per the at least one request.
  • the central server transmits an acknowledgement of receipt to the user device.
  • the central server provides a vote allocation to the user device, in accordance to parameters as mentioned in an earlier portion of the description, possibly in the same message as step 7.
  • the user device is then used to provide a vote to the central server, whereby the central server tracks and/or counts the vote.
  • the central server then applies a requisite payment or credit to a respective merchant account.
  • the third implementation also relies on a central server being communicatively coupled to a user device, a merchant device and a payment system.
  • the user device and the merchant device are also communicatively coupled to one another.
  • An ordering step is not contemplated for this implementation, but this implementation is likely to follow an earlier order which has already been placed and associated with a request ID. The method is carried out in the following manner:
  • the user device is used to select a merchant.
  • the user device then transmits a customer ID and at least one payment amount to the merchant device.
  • the merchant device then transmits a payment request to the central server.
  • the central server then optionally carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then optionally transmits a payment authentication request to the user device.
  • the user device then optionally transmits a payment authentication to the central server.
  • the central server then optionally carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then transmits a payment confirmation to the merchant device.
  • the central server then provides a vote allocation to the user device, in accordance to parameters as mentioned in an earlier portion of the description.
  • the user device is then used to provide a vote to the central server, whereby the central server tracks and/or counts the vote.
  • FIG 9 there is shown a fourth detailed implementation of the method. It should be noted that the fourth implementation relies on a central server being communicatively coupled to a user device and a payment system. The user device and the merchant device are communicatively coupled to one another. The method is carried out in the following manner:
  • the user device is used to select a merchant, the instructions for response being input to the merchant.
  • the merchant device then optionally provides a menu associated with the merchant to the user device.
  • the user device is then used to submit at least one request (order) for the at least one good/service to the merchant device.
  • the merchant device then transmits a payment request to the user device.
  • the user device then transmits a payment request to the central server.
  • Payment information can be input into the user device prior to transmission of the payment request.
  • the payment information can be registered and stored at the central server or a module accessible by the central server. If the payment information has been prior registered, the user device can facilitate authentication such that stored payment information is used to process the payment for the transaction.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then transmits a signed token to the user device.
  • the user device also transmits the signed token to the merchant device.
  • the central server then provides a vote allocation to the user device, in accordance to parameters as mentioned in an earlier portion of the description.
  • the user device is then used to provide a vote to the central server, whereby the central server tracks and/or counts the vote.
  • the central server then applies a requisite payment or credit to a respective merchant account.
  • the fifth implementation relies on a central server being unreachable at some junctures, and where the user device and the merchant device are communicatively coupled to one another.
  • the method is carried out in the following manner:
  • the user device is used for a payment registration process with the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then transmits a signed token to the user device.
  • Steps 1, 2, and 3 are typically carried out at a prior juncture before beginning engagement with a specific merchant.
  • Step 4 is initiated once the user begins engagement with the specific merchant.
  • the user device is used to select a merchant, the instructions for response being transmitted to the merchant device.
  • the merchant device then optionally provides a menu associated with the merchant to the user device.
  • the user device is then used to submit at least one request (order) for the at least one good/service and a signed token to the merchant device.
  • the merchant device then transmits a payment request to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then transmits a payment receipt and vote allocation to the merchant device as depicted in 9al. If the user device is connected to the merchant device, the merchant device transmits the payment receipt and vote allocation to the user device as depicted in 9a2, in accordance to parameters as mentioned in an earlier portion of the description. If the user device is not connected to the merchant device, the central server transmits the vote allocation to the user device as depicted is 9b (possibly at a later juncture). 10) If the user device is connected to the central server, the user device is used to provide a vote to the central server as depicted in lOa.
  • the user device is then used to provide a vote to the merchant device as depicted in lOal, and the merchant device transmits the vote to the central server as depicted in l0a2, whereby the central server tracks and/or counts the vote.
  • the central server then applies a requisite payment or credit to a respective merchant account.
  • the sixth implementation relies on a central server being unreachable at some junctures, and where the user device and the merchant device are communicatively coupled to one another.
  • the user device includes a digital wallet which includes a preloaded stored value. The method is carried out in the following manner:
  • the user device transmits an authentication and token request to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with a payment system.
  • the central server then transmits a signed token to the user device.
  • Steps 1 to 3 are typically carried out at a prior juncture before beginning engagement with a specific merchant.
  • Step 4 is initiated once the user begins engagement with the specific merchant.
  • the user device is used to select a merchant, the instructions for response being transmitted to the merchant device.
  • the merchant device then optionally provides a menu associated with the merchant to the user device.
  • the user device is then used to submit at least one request (order) for the at least one good/service.
  • the merchant device then optionally transmits a payment request to the user device.
  • the user device transmits a signed token to the merchant device, (possibly in the same message as step 6).
  • the merchant device then transmits a signed token to the central server (possibly at a later juncture).
  • the central server then instructs a requisite payment to be made to an account associated with the merchant.
  • the central server then transmits a vote allocation to the user device.
  • the vote allocation should be in accordance to parameters as mentioned in an earlier portion of the description.
  • the user device If the user device is connected to the central server, the user device is used to provide a vote to the central server.
  • the seventh implementation relies on a central server being communicatively coupled to a user device, a merchant device and a payment system.
  • This implementation uses a digital stamp, which is a device that can conduct/transmit a unique pattem/signal to a user device using capacitive touch points.
  • the merchant registers at least one unique digital stamp at the central server. Multiple digital stamps may be registered such that each merchant staff member uses a unique stamp. The method is carried out in the following manner:
  • the user device is used to select a merchant, and to submit at least one request (order) for the at least one good/service, the instructions being input to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with the payment system.
  • the merchant device then transmits a request acceptance to the central server.
  • the central server transmits an order confirmation to the user device.
  • the user device then receives a digital stamp.
  • This digital stamp is conducted/transmitted by the merchant on an order confirmation/receipt page shown on the user device.
  • the user device transmits the data of the digital stamp to the central server.
  • the central server validates the data of the digital stamp using data previously associated with the merchant.
  • the central server then transmits a validation response message to the user device.
  • the merchant device and/or the payment system then receive confirmation of payment being carried out.
  • the user device can then be utilised to provide an allocated vote associated with the at least one good/service provided by the merchant.
  • This vote may optionally be limited to a pre-determined duration of time. It should be appreciated that there can be instances when electronic payments involving the payment system is not carried out. In those instances, conventional non-digital payment processes can be carried out at or about step 6 described above.
  • the use of the digital stamp in a physical currency transaction enables a user-friendly way for merchant staff to securely authenticate a transaction.
  • the act of stamping a payment confirmation page on the user device is similar to the real world action of stamping a paper receipt with an ink stamp, so it can be intuitive and symbolic for users who have reservations pertaining to modem payment technology.
  • the digital stamp is conducted/transmitted on the confirmation page shown on the user device, the user device must be present. This reduces the likelihood that the user will dispute the transaction.
  • Another advantage of a digital stamp is that its unique pattern is not easily reproduced, in particular compared to using a PIN code or a gesture pattern.
  • FIG 13 there is shown an eighth detailed implementation of the method. It should be noted that the eighth implementation relies on a central server being communicatively coupled to a user device, a merchant device and a payment system. The method is carried out in the following manner:
  • the user device is used to select a merchant, and to submit at least one request (order) for the at least one good/service, the instructions being input to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with the payment system.
  • the merchant device then transmits an acknowledgement to the central server.
  • the merchant then proceeds to provide the at least one good/service to the user as per the at least one request.
  • the central server transmits an order confirmation to the user device.
  • the user device then captures biometric information from a merchant staff.
  • the biometric information can include, for example, a fingerprint, a retina scan, a facial profile, vocal sequence, and so forth.
  • the user device transmits the biometric data to the central server.
  • the central server validates the biometric data using data previously associated with the merchant.
  • the central server transmits a validation response message to the user device.
  • the merchant device and/or the payment system then receives confirmation of payment being carried out.
  • the user device can then be utilised to provide an allocated vote associated with the digital stamp for the merchant.
  • This vote may optionally be limited to a pre determined duration of time. It should be appreciated that there can be instances when electronic payments involving the payment system is not carried out. In those instances, conventional non digital payment processes can be carried out in place of step 2 described above. Even though the order of steps indicated above is indicated in FIG 13, it should be appreciated that the exact order can be varied, and some steps can be omitted or combined, where appropriate.
  • FIG 14 there is shown a ninth detailed implementation of the method. It should be noted that the ninth implementation relies on a central server being communicatively coupled to a user device, a merchant device and a payment system. The method is carried out in the following manner:
  • the user device is used to select a merchant, and to submit at least one request (order) for the at least one good/service, including data on an amount to be tendered using physical cash, the instructions being input to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with the payment system, and checking that excess currency from the physical cash can be deposited in an account associated with the user. This is check may be required if there is a maximum amount that can be held in the account. It is optional because the transaction could be for a new user.
  • the merchant device then transmits an acknowledgement to the central server.
  • the central server transmits an order confirmation to the user device.
  • the central server then transmits the payment acknowledgement to the user device.
  • the central server then transmits a payment validation message to the payment system to validate that the user’s account should be credited with the excess cash, if any.
  • the central server transmits a payment confirmation to the merchant device.
  • the user account can then be credited with an allocated vote associated with the user device for the merchant up to a pre -determined duration of time.
  • payment systems that utilize the system depicted in FIG 14 may levy a fee on a merchant for every transaction. This would discourage merchants from relying on transactions involving receipt of physical currency. This reduces the likelihood of a merchant trying to generate fraudulent vote allocations.
  • the tenth implementation relies on a central server being communicatively coupled to a user device, a merchant device and a payment system.
  • the method is carried out in the following manner:
  • the user device is used to select a merchant, and to submit at least one request (order) for the at least one good/service, including data on an amount to be tendered using physical cash, the instructions being input to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with the payment system, and checking that excess currency from the physical cash can be deposited in an account associated with the user. This is check may be required if there is a maximum amount that can be held in the account.
  • the merchant device then transmits an acknowledgement to the central server.
  • the central server transmits an order confirmation to the user device.
  • the merchant uses the user device to validate receipt of the cash by placing a digital stamp associated with the merchant on the user device, or by a previously registered biometric authentication of a merchant using the user device, or by inputting into the user device a code and/or pattern previously associated with the merchant.
  • the user device then sends the validation data to the central server.
  • the central server validates the digital stamp, biometric authentication, or other input by merchant.
  • the central server then transmits a payment validation message to the user device.
  • the central server transmits a payment confirmation to the payment system to validate that the user’s account should be credited with the excess cash, if any.
  • the central server transmits a payment confirmation to the merchant device.
  • the user device can then be utilised to provide an allocated vote associated with the digital stamp for the merchant up to a pre-determined duration of time.
  • FIG 16 there is shown an eleventh detailed implementation of the method. It should be noted that the eleventh implementation combines aspects from the aforementioned embodiments. The method is carried out in the following manner:
  • the user device is used to select a merchant, and to submit at least one request (order) for the at least one good/service, including data on an amount to be tendered using physical currency, the instructions being input to the central server.
  • the central server then carries out processing of payment for the at least one request by communicating with the payment system.
  • the merchant device then transmits an acknowledgement to the central server.
  • the central server transmits an order confirmation containing a merchant validation request to the user device.
  • the merchant uses the user device to validate receipt of the cash by placing a digital stamp associated with the merchant on the user device, or by a previously registered biometric authentication of a merchant using the user device, or by inputting into the user device a code and/or pattern previously associated with the merchant.
  • the user device transmits this data to the central server.
  • the central server transmits a validation request to a validation module to validate the merchant validation input.
  • the validation module can be part of the central server. This validation module then sends a response to the central server indicating the status of the validation.
  • the merchant uses the merchant device to transmit a payment receipt notification to the central server.
  • the central server then transmits a payment validation response message to the user device indicating the status of the payment.
  • the central server transmits a payment confirmation to the payment system to validate that the user’s account should be credited with the excess cash, if any.
  • the central server sends a payment confirmation message to the merchant device.
  • the central server then transmits a vote allocation to the user device.
  • the vote allocation should be in accordance to parameters as mentioned in an earlier portion of the description.
  • the user device is used to provide a vote to the central server.
  • the ninth, tenth, and eleventh embodiment users need not worry about receiving change for transactions with merchants, and consequently, digital wallets of the users are regularly topped up without a deliberate effort by the users. This is convenient and helpful for the users to convert their physical currency for use with their digital wallets. It should be noted that in situations where users do not expect receiving change arising from a transaction, the change that is due to the users can be in an alternative form rather than monetary currency. For example, the change can be in the form of loyalty or reward points for any such program.
  • the user can submit multiple votes if certain pre-defmed conditions are met by the user. For example, if the user is a regular patron to a venue where the good/service is consumed, the user is able to submit votes for several of the good/service in a ranked form. For example, the regular patron will be considered a“verified user” such that the votes of the regular patron has a higher weightage.
  • the votes provided by the user can be shared with third parties, typically on social media channels in a manner whereby the user’s votes are trackable. In some instances, tracking of the user’s votes is necessary to enable a commission to be payable to the user should the user’s votes lead to consumption of the good/service.
  • the commission can be enabled by a cloud-based affiliate network system that pays a commission for the referral and deducts it from the merchant during the transaction.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention permet de proposer à des utilisateurs un procédé et un système destinés à effectuer une évaluation d'au moins un bien/service. Le procédé et le système peuvent être mis en œuvre pour un commerçant souhaité dans une situation où un utilisateur effectuant l'évaluation n'a pas besoin de se servir d'un dispositif connecté à Internet. De plus, l'évaluation de ces biens/services est réalisée d'une manière moins subjective et plus équitable.
PCT/SG2019/050330 2018-07-02 2019-07-02 Système et procédé destinés à effectuer une évaluation d'au moins un bien/service WO2020009661A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10201805720W 2018-07-02
SG10201805720WA SG10201805720WA (en) 2018-07-02 2018-07-02 A system and method for carrying out an appraisal for at least one good/service

Publications (1)

Publication Number Publication Date
WO2020009661A1 true WO2020009661A1 (fr) 2020-01-09

Family

ID=69060995

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2019/050330 WO2020009661A1 (fr) 2018-07-02 2019-07-02 Système et procédé destinés à effectuer une évaluation d'au moins un bien/service

Country Status (2)

Country Link
SG (1) SG10201805720WA (fr)
WO (1) WO2020009661A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130218659A1 (en) * 1999-12-20 2013-08-22 Kount Inc Secure money transfer via electronic stamp
US20140214666A1 (en) * 2008-03-13 2014-07-31 Giftya Llc System and method for managing gifts
US9009082B1 (en) * 2008-06-30 2015-04-14 Amazon Technologies, Inc. Assessing user-supplied evaluations
WO2015166255A1 (fr) * 2014-04-30 2015-11-05 Ecrebo Limited Procédé et système pour achever des transactions
US20180053235A1 (en) * 2016-08-16 2018-02-22 International Business Machines Corporation Unbiased search and user feedback analytics

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130218659A1 (en) * 1999-12-20 2013-08-22 Kount Inc Secure money transfer via electronic stamp
US20140214666A1 (en) * 2008-03-13 2014-07-31 Giftya Llc System and method for managing gifts
US9009082B1 (en) * 2008-06-30 2015-04-14 Amazon Technologies, Inc. Assessing user-supplied evaluations
WO2015166255A1 (fr) * 2014-04-30 2015-11-05 Ecrebo Limited Procédé et système pour achever des transactions
US20180053235A1 (en) * 2016-08-16 2018-02-22 International Business Machines Corporation Unbiased search and user feedback analytics

Also Published As

Publication number Publication date
SG10201805720WA (en) 2020-02-27

Similar Documents

Publication Publication Date Title
US20230196355A1 (en) Processing of electronic transactions
JP6810189B2 (ja) 還元ポイントを用いるモバイル支払システム
US10963901B2 (en) Systems and methods for use in facilitating enrollment in loyalty accounts
US20200051073A1 (en) System and method for enhanced token-based payments
US8719158B2 (en) Multi-account payment consolidation system
US8554670B1 (en) Systems and methods for crediting missed location-based electronic check-ins in a social network
US20140207680A1 (en) System and method for providing a mobile wallet shopping companion application
US20150032635A1 (en) System and method for exchanging data with smart cards
US20140279534A1 (en) System and method for providing an account holder a notification
US10510069B1 (en) Variable deposits maximums for a digital cash deposit digitization service
US20130060686A1 (en) Virtual debit card
KR20190041539A (ko) 전자 지갑을 통한 결제 시스템
CA2934342C (fr) Systemes et methodes pour generer des offres a partir de paiements sans contact mis en jetons
US11526882B2 (en) Cryptocurrency rewards for a virtual cash card
EP2817778A1 (fr) Exécution sélective de transactions de commerce électronique basées sur de l'argent liquide
CA3030440A1 (fr) Traitement de transactions electroniques
Turban et al. Electronic commerce payment systems
US20140244487A1 (en) Fund Transfer Using Near Field Communication
US20240119449A1 (en) Rewards for a virtual cash card
KR100897498B1 (ko) 유비쿼터스 환경에서의 통합형 금융 서비스 시스템
WO2020009661A1 (fr) Système et procédé destinés à effectuer une évaluation d'au moins un bien/service
US20130226697A1 (en) Selectively providing cash-based e-commerce transactions
US20200226602A1 (en) Methods and systems for availing offers in card based payment transaction
WO2022119768A1 (fr) Récompenses en cryptomonnaie pour carte de paiement virtuelle

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

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

Country of ref document: EP

Kind code of ref document: A1