WO2022162346A1 - Système et procédés de paiement - Google Patents

Système et procédés de paiement Download PDF

Info

Publication number
WO2022162346A1
WO2022162346A1 PCT/GB2022/050160 GB2022050160W WO2022162346A1 WO 2022162346 A1 WO2022162346 A1 WO 2022162346A1 GB 2022050160 W GB2022050160 W GB 2022050160W WO 2022162346 A1 WO2022162346 A1 WO 2022162346A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
property
account
transaction
data
Prior art date
Application number
PCT/GB2022/050160
Other languages
English (en)
Inventor
Oliver Muller
Original Assignee
Creid Technologies Limited
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 Creid Technologies Limited filed Critical Creid Technologies Limited
Publication of WO2022162346A1 publication Critical patent/WO2022162346A1/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/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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/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/326—Payment applications installed on the mobile 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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/16—Real estate
    • 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/18—Legal services
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present disclosure relates to a payment system and methods.
  • the disclosure is particularly, but not exclusively, applicable to a method and system for facilitating payments.
  • Existing payment systems often require both parties to a payment related to a property (e.g. the tenant and owner of a home) to share financial details with each other and to use third party payment providers to initiate the payment. For example, when a tenant pays rent to a homeowner, he first receives the financial details of the owner and then initiates rent payment via his bank; or provides extensive financial details to the owner to initiate a direct debit regular payment. Accordingly, the payment may be neither secure nor seamless.
  • the present disclosure seeks to at least partially alleviate the problems outlined above.
  • a method of facilitating payments (and/or transactions) comprising the steps of: connecting to an account of a first user; receiving, from (e.g. a computer device of) the first user, a request for a payment by a second user, and optionally receiving data related to the payment; optionally transmitting a request for the payment to (e.g. a computer device of) the second user; connecting to an account of the second user; and upon approval of the request by the second user, transmitting data related to the accounts of the first and second users (and optionally to the payment) to a payment service provider for completion of said payment.
  • connecting to an account of a (e.g. the first and/or second) user comprises: optionally receiving data related to the user and creating an account for the user and/or creating a unique identifier for the account; transmitting a request for authentication of the connection to a payment service provider; and receiving a URL for authentication from the payment service provider and preferably providing said URL to the user to authenticate the connection.
  • connecting to an account of a user comprises: transmitting a request for authentication of the connection to a payment service provider; and receiving a URL for authentication from the payment service provider, and preferably providing said URL to the user to authenticate the connection.
  • connecting to an account further comprises redirecting said user to said URL.
  • the method includes transmitting data related to the account(s) of and/or to the first and/or second users for storage in an apparatus (e.g. a storage device and/or a database).
  • an apparatus e.g. a storage device and/or a database.
  • said data related to the account(s) and/or to the user(s) is preferably encrypted at rest.
  • said data related to the account(s) and/or to the user(s) is preferably stored temporarily, and is preferably deleted upon transmission of the data to the payment service provider for completion of said payment.
  • data is preferably encrypted prior to transmission to a user and/or the payment service provider.
  • the method includes transmitting data related to the payment for storage.
  • said data related to the payment is encrypted at rest.
  • the method preferably includes, upon a (preferably any) request from an entity (preferably the first user, second user, and/or payment service provider), assigning access rights to the entity in dependence on the rights required to complete the request, preferably the required rights being given even greater weighting in assigning access rights than the entity’s identity.
  • entity preferably the first user, second user, and/or payment service provider
  • the method further comprises transmitting a request for confirmation of completion of said payment to the payment service provider.
  • the method further comprises transmitting a notification of completion of said payment to the first and/or second users.
  • the method further comprises associating the second user as a user of the property.
  • the payment is a payment for use of a property, the method preferably further comprising associating the first user as an owner of the property.
  • Associating a user as a user/owner of a property may comprise receiving a confirmation from a user that they are the user/owner of the property and/or storing information related to said association in a database.
  • associating the first user as an owner of the property comprises one or more (more preferably all) of the following: receiving a proof of ownership of the property by the first user; verifying the proof of ownership; generating a digital record for the property; and/or updating the ownership of the digital record to the first user.
  • associating the first user as an owner of the property further comprises providing a proof of ownership of the digital record to the first user.
  • the method further comprises identifying one or more (further) payments in the transactional history of the account of the first (and/or second) user.
  • the payments may be payments related to the property and/or payments for services.
  • the method further comprises receiving data related to alternative providers of service(s) associated with the further payments, and optionally displaying the data to the user.
  • the displayed data is filtered upon a user input.
  • the method further comprises determining (and optionally presenting) savings associated with alternative providers in comparison to a current provider of one or more services.
  • the method further comprises, upon a user selection of an alternative provider of a service, transmitting data related to the user and to the account to a services module for switching the current provider of the service to the alternative provider via an application of the alternative provider.
  • the data related to the user may comprise personal information, and/or a credit or affordability score.
  • the method further comprises performing a credit check.
  • the data may be received from a connection module and/or from a database.
  • the method further comprises estimating (preferably via a machine learning module) a metric related to the property.
  • the estimated metric is transmitted to the services module.
  • the estimated metric is a valuation of the property.
  • data related to alternative providers is received periodically, and optionally a notification related to one or more alternative providers is transmitted to the user.
  • the user may turn notifications on or off, and/or filter the notifications - e.g. to relate to only certain services and/or when the alternative provider’s offer is sufficiently superior (e.g. in monetary or service (e.g. WIFI speed) terms) than the current provider’s offer.
  • the alternative provider’s offer is sufficiently superior (e.g. in monetary or service (e.g. WIFI speed) terms) than the current provider’s offer.
  • the method further comprises displaying data related to the (further) payments related to the services to the user.
  • Said data optionally comprises any one or more of data related to: amount paid, frequency of payment, and/or service paid for.
  • the service(s) may be related to the property.
  • the service(s) may be any one or more of: maintenance of the property; repayment of a loan (mortgage) related to (for) the property; and/or utilities related to the property.
  • the utilities are any one or more of: energy, water, heating, TV, Internet (WIFI), landline, and/or sanitation.
  • the method further comprises receiving data related to alternative providers of said service(s), and optionally presenting the data to the user.
  • the method further comprises, upon a request from a user (e.g. first and/or second user), disconnecting from the account of the user and preferably stopping one or more (more preferably all) of the user’s payments (optionally related to a/the property).
  • a user e.g. first and/or second user
  • disconnecting from the account of the user and preferably stopping one or more (more preferably all) of the user’s payments (optionally related to a/the property).
  • the method further comprises, upon a request from the second user, disconnecting from the account of the second user and preferably stopping said payment to the first user (e.g. cancelling a standing order).
  • the method further comprises receiving data from the first and/or second user; the method preferably further comprising transmitting the data to a database.
  • the received data may be data related to a property.
  • the method further comprises estimating a metric (of a property) using an artificial neural network based on the data received from the first and/or second users (and optionally data received from a server).
  • the received data related to the payment is transmitted to a database for storage; preferably wherein said data is associated in the database with the identity of the property and of the (first) user.
  • the received data related to the payment may comprise any one or more of: payment start and/or end date; payment amount, payment frequency; and/or second user personal information (e.g. name and/or email address).
  • the method further comprises the step of receiving data related to the accounts of the first and second users.
  • the data related to the accounts comprises one or more of: bank account unique identifiers; bank name (or other identifying information).
  • the method further comprises storing received data in a database (and/or transmitting said data to a database for storage).
  • the payment is one of: a single payment, a standing order, or a scheduled payment.
  • the method further comprises receiving an approval of a/the payment from the second user (and/or the first user).
  • the (requested) payment may be a payment related to a property.
  • the payment related to the property may be a payment for use (rental) of the property.
  • the payment may be a financial transaction.
  • the account may be a bank account.
  • the step of connecting to an account may comprise establishing a connection to a payment service provider (associated with the account).
  • the property may be real-estate property, preferably residential real-estate property.
  • the second user (party) may be renting the property.
  • the second user is a tenant of the property.
  • Connecting to an account of a first and/or second user may be done via a connection module.
  • One or more of the payment(s) may be regular payments.
  • the payment may be a payment for use (rental) of the property
  • the property may be tangible (e.g. a home) or intangible (e.g. a software package).
  • data and/or request(s) are received from / transmitted to a computer device and/or server.
  • the method comprises upon approval of the request by the second user, transmitting data related to the accounts of the first and second users and to the payment to a payment module for completion of said payment for use of the property via a payment service provider.
  • the method is computer-implemented.
  • the method produces an output.
  • the method presents the output.
  • the method presents the output on or to a display.
  • the method further comprises producing an output.
  • the method further comprises presenting the output.
  • the method further comprises presenting the output on or to a display.
  • a method of facilitating transactions comprising the steps of: connecting to an account of a first user; receiving, from the first user, a request for a transaction with a second user; connecting to an account of the second user; and upon approval of the request by the second user, transmitting data related to the accounts of the first and second users to a payment service provider for completion of said transaction.
  • the transaction is a financial transaction and/or a payment.
  • the method includes transmitting the request to the second user, preferably for approval by the second user.
  • receiving, from the first user, a request for the transaction with the second user further comprises receiving data related to the transaction.
  • the method further comprises transmitting data related to the transaction to the payment service provider for completion of said transaction.
  • the method further comprises transmitting a request for the transaction to the second user; preferably after receiving, from the first user, the request for the transaction with the second user.
  • the method includes transmitting data related to the account/ s) of and/or to the first and/or second users for storage.
  • said data related to the account(s) and/or to the user(s) is encrypted at rest.
  • said data related to the account(s) and/or to the user(s) is stored temporarily, and deleted upon transmission of the data to the payment service provider for completion of said transaction.
  • the method includes transmitting data related to the transaction for storage; preferably wherein, in storage, said data related to the transaction is encrypted at rest.
  • the method further comprises transmitting a request for confirmation of completion of said transaction to the payment service provider; and preferably further comprises transmitting a notification of completion of said transaction to the first and/or second users.
  • the transaction is a payment for use of a property.
  • the method further comprises associating the first user as an owner of the property.
  • associating the first user as an owner of the property comprises: receiving a proof of ownership of the property by the first user; verifying the proof of ownership; generating a digital record for the property; and updating the ownership of the digital record to the first user.
  • associating the first user as an owner of the property further comprises providing a proof of ownership of the digital record to the first user.
  • generating a digital record comprises: generating a non-fungible token, and transmitting said token to a node of a blockchain.
  • updating the ownership of the digital record to the first user comprises transmitting a transaction (more preferably comprising data relating to ownership of the digital record) to a node of a/the blockchain.
  • a method of facilitating payments comprising the steps of : connecting to an account of a first user; receiving, from the first user, a request for a payment by a second user; connecting to an account of the second user; and upon approval of the request by the second user, transmitting data related to the accounts of the first and second users to a payment service provider for completion of said payment.
  • a computer program product for facilitating payments comprising instructions which, when executed by a computer program, cause a computer processor to cany out any method as herein described.
  • a computing device for facilitating payments comprising a controller configured to cany out any method as herein described.
  • the computing device further comprises a display configured to display data to a user (e.g. data related to alternative providers).
  • a smart home comprising a computing device as described herein.
  • a system for facilitating payments comprising, a server and a computing device according to any device herein described.
  • the server is configured to receive data and provide the data to the computing device.
  • a system for facilitating payments comprising a connection module, a communication module, and a payment module; wherein: the connection module is configured to connect to an account of a first user; the communication module is configured to receive, from the first user, a request for a payment by a second user, and optionally to receive data related to the payment; the communication module is optionally configured to transmit a request for the payment to the second user; the connection module is configured to connect to an account of the second user; and upon approval of the request by the second user, the communication module is configured to transmit data related to the accounts of the first and second users (and optionally to the payment) to a payment module for completion of said payment via a payment service provider.
  • system further comprises a machine learning module for estimating a metric of the property.
  • system further comprises a services module.
  • a method of authenticating ownership of a property by a user comprising the steps of: receiving a proof of ownership of the property by the user; verifying the proof of ownership; generating a digital record for the property; and updating the ownership of the digital record to the user; and optionally providing a proof of ownership of the digital record to the user.
  • a method of facilitating payments comprising the steps of: connecting to an account of a user; identifying one or more payments for services in the transactional history of the account of the user, receiving data related to alternative providers of said one or more services, and presenting the data to the user; and upon a user selection of an alternative provider of a service, transmitting data related to the user (and optionally to the account) to a services module for switching the current provider of the service to the alternative provider via an application of the alternative provider.
  • a method of estimating a metric of a property comprising the steps of: receiving, from a server, a first dataset of one or more features of the property; receiving, from a user device, a second dataset of one or more features of the property; determining an evaluation dataset of one or more features of the property, wherein the value of a feature in the evaluation dataset is the value received from the user device, or, if the second dataset does not comprise the feature, the value received from the server; and providing the evaluation dataset to an artificial neural network to determine an estimate of the metric.
  • the method further comprises any, some or all of the steps of in any order:
  • the metric may be a valuation (sale price) of the property.
  • a computer device adapted for facilitating transactions comprising a connection module, a communication module, and a transaction module; wherein: the connection module is configured to connect to an account of a first user; the communication module is configured to receive, from (a user device of) the first user, a request for a transaction with a second user; the connection module is configured to connect to an account of the second user; and upon approval of the request by the second user, the communication module is configured to transmit data related to the accounts of the first and second users to a transaction module for completion of said transaction via a payment service provider.
  • the computer device may comprise a processor, a communication interface, memory, and/or a storage device.
  • a payment (service provider) server for facilitating transactions, the server comprising a processor and associated memory (and optionally a communication interface), wherein the server is adapted to: receive data related to accounts of a first and a second user and to a transaction between the first and second users; and process said data, whereby to complete the transaction.
  • a system for facilitating transactions comprising: a computer device adapted for facilitating transactions (preferably as described herein); a payment server (preferably as described herein); and one or more of: a first user device, a second user device, a storage device, and/or a database.
  • the computer device preferably comprises a processor adapted to perform any one of the methods herein described.
  • the computer device preferably includes a communication interface for receiving communications from (and/or transmitting communications to) the payment server, the first user, and/or the second user.
  • the communication interface is preferably adapted for transmitting a request for confirmation of completion of said transaction to the payment server.
  • the communication interface is preferably further adapted for transmitting a notification of completion (e.g. success or failure) of said transaction to the first and/or second user devices.
  • a system for facilitating transactions comprising a connection module, a communication module, and a transaction module; wherein: the connection module is configured to connect to an account of a first user; the communication module is configured to receive, from the first user, a request for a transaction with a second user; the connection module is configured to connect to an account of the second user; and upon approval of the request by the second user, the communication module is configured to transmit data related to the accounts of the first and second users to a transaction module for completion of said transaction via a payment service provider.
  • a method of facilitating a transaction between a first user and a second user comprising the steps of: connecting to an account of the first user; receiving, from the first user, a request for a transaction with the second user; connecting to an account of the second user; and upon approval of the request by the second user, transmitting data related to the accounts of the first and second users to an external server for completion of said transaction.
  • the external server is a payment service provider.
  • a method of facilitating data transmission comprising the steps of: connecting to an account of a first user; receiving, from the first user, a request for a transaction with the second user (and/or for data related to the second user); connecting to an account of the second user; and upon approval of the request by the second user, transmitting data related to the accounts of the first and second users to an external server (preferably for completion of said transaction).
  • the external server is a payment service provider.
  • a computer device adapted to send a transaction to a node of a blockchain.
  • the transaction relates to ownership of a property.
  • a method of facilitating payments via an application on a user device of a first user comprising the steps of: receiving, from a server, a request to connect an account to the application; and transmitting, to a server, a request for a payment by a second user, and optionally transmitting data related to the payment.
  • the method further comprises transmitting a confirmation that the first user is associated with the property (e.g. confirming that the user (of the user device) is the owner of the property)
  • data is transmitted to / received from a server.
  • the present invention provides any, some or all of the features in any order:
  • the methods can be implemented, at least in part, using computer program code.
  • computer software or computer program code adapted to cany out these methods described above when processed by a computer processing means.
  • the computer software or computer program code can be carried by computer readable medium, and in particular a non-transitoiy computer readable medium, that is a medium on which computer code may be stored permanently or until it is overwritten.
  • the medium may be a physical storage medium such as a Read Only Memory (ROM) chip.
  • ROM Read Only Memory
  • DVD-ROM Digital Video Disk
  • non-volatile memory card e.g. a flash drive or mini/micro Secure Digital (SD) card.
  • a signal such as an electronic signal over wires, an optical signal or a radio signal such as over a mobile telecommunication network, a terrestrial broadcast network or via a satellite or the like.
  • the disclosure also extends to a processor running the software or code, e.g. a computer configured to carry out the methods described above.
  • Any apparatus or device feature as described herein may also be provided as a method feature, and vice versa.
  • means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.
  • any feature described as being carried out by an apparatus, an application, and a device may be carried out by any of an apparatus, an application, or a device. Where multiple apparatuses are described, each apparatus may be located on a single device.
  • the disclosure also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.
  • the disclosure also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.
  • the disclosure also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.
  • the disclosure also provides a computer readable medium having stored thereon the computer program as aforesaid.
  • the disclosure also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.
  • Figure la is a flow diagram illustrating an example method of associating a property with a user.
  • Figure lb is a flow diagram illustrating an example method of facilitating payments.
  • Figure 1c is an example user interface of the ‘Property Card’ ready for owners and tenants to use; according to a first embodiment of the present invention.
  • Figure 2 is an example user interface of the ‘Property Details’ part of the Property Card that can be edited/inputted by users; according to a first embodiment of the present invention. It contains property details and inventory.
  • Figure 3 is an example user interface of the ‘Calculator’ part of the Property Card that shows a property valuation and other financials that can be edited by users; according to a first embodiment of the present invention.
  • users can track their live property valuation, profit/loss, and other financial metrics.
  • Figure 4a is an example user interface of the ‘Sell’ journey where owners can list their Property Card for sale; according to a first embodiment of the present invention. They simply select a price, and the Property Card is then listed for sale in the Search page.
  • Figure 4b is an example user interface of Property Card listed for sale in the Search; according to a first embodiment of the present invention.
  • Figure 5a is an example user interface of the ‘Rent journey ’ for property owners to list their Property Card for rent and set up standing orders to collect rent payments from their tenants; according to a first embodiment of the present invention. This sends a rent payment request to the tenant who can then join PropertyCard to sync payments to the owner.
  • Figure 5b is an example user interface of the Property Card listed for rent in Search; according to a first embodiment of the present invention.
  • Figure 6 is an example user interface of the ‘Utilities’ marketplace showing real-time Utilities bundles that can be booked by users; according to a first embodiment of the present invention.
  • Figure 7 is an example user interface of the ‘Mortgage’ marketplace showing real-time Mortgage deals that can be booked by users; according to a first embodiment of the present invention.
  • Figure 8 is an example user interface of the ‘Document Storage’ where users can upload and manage their documents in one place; according to a first embodiment of the present invention.
  • Figure 9 is an example user interface of the Relationships tab showing all users interacting with the Property Card (owner, tenants, agents, inventory clerks, etc); according to a first embodiment of the present invention.
  • Figure 10 is an example user interface of the Wallet, showing all transactions going through the Property Card, along with a user’s credit score and the rewards earned; according to a first embodiment of the present invention.
  • Figure 11 is an example user interface of the ‘Property Card’ ready to be connected by a homeowner or tenant; according to a second embodiment of the present invention.
  • Figure 12 is an example user interface of the ‘Data and Valuations’ part of the Property Card that can be edited by users; according to a second embodiment of the present invention.
  • Figure 13 is an example user interface of the ‘Connect’ journey to connect a user’s account to a property; according to a second embodiment of the present invention.
  • Figure 14 is an example user interface of the ‘Rent journey ’ for property owners and tenants to automate payments; according to a second embodiment of the present invention.
  • Figure 15 is an example user interface of the ‘Energy’ journey to identify alternative service providers for a property; according to a second embodiment of the present invention.
  • Figure 16 is an example user interface of the ‘TV & WIFI’ journey to identify alternative service providers for a property; according to a second embodiment of the present invention.
  • Figure 17 is an example user interface of the ‘Mortgage’ journey to identify alternative service providers for a property; according to a second embodiment of the present invention.
  • Figure 18 is an example user interface of the Property Card following connection to a user’s account; according to a second embodiment of the present invention.
  • Figure 19 is an example user interface of the Property Card showing current service providers; according to a second embodiment of the present invention.
  • Figure 20 is an example user interface of the Property Card showing the notifications related to alternative service providers; according to a second embodiment of the present invention.
  • Figure 21 is an example user interface of the Property Card when disconnected from an account of a user; according to a second embodiment of the present invention.
  • Figure 22 is a snapshot of an example database of property data.
  • Figure 23 is an example user interface showing accuracy statistics for a machine learning module.
  • Figure 24a is a schematic diagram of an example software architecture of the system used for facilitating payments; according to a first embodiment of the present invention.
  • Figure 24b is a schematic diagram of an example software architecture of the system used for facilitating payments; according to a second embodiment of the present invention.
  • Figure 25 is a schematic diagram of an example software architecture of a machine learning module.
  • Figure 26 is a flow diagram illustrating an example method of facilitating payments.
  • Figure 27 shows an exemplary computer apparatus on which the methods described herein may be implemented.
  • the disclosure could be applied to transactions related to a number of other properties, such as commercial real-estate.
  • the present disclosure could equally be applied to transactions related to a number of other property types, in particular properties that are rented and/or have associated regular costs, such as the leasing of vehicles.
  • the disclosure could be applied to transactions related to any kind of property (tangible or intangible).
  • an application (referred to as the “Property Card” from heron) may be installed on a computer device (for example, a mobile phone, tablet, or laptop, or any other computer device) to facilitate payments related to a property.
  • a computer device for example, a mobile phone, tablet, or laptop, or any other computer device
  • a unique identifier (preferably URL) may be assigned to each home, thereby forming a unique Property Card for each home.
  • the Property Card may be accessed from any computer device - e.g. phones (mobile responsive screens, apps), web (desktops, laptops), hardware (in-home panels and other smart devices), and/or as general-purpose software for display on a device.
  • any computer device e.g. phones (mobile responsive screens, apps), web (desktops, laptops), hardware (in-home panels and other smart devices), and/or as general-purpose software for display on a device.
  • owners and tenants may connect their account to automate management of their primary asset seamlessly and securely.
  • the Property Card application is implemented as an application on a user device.
  • the application i.e. front-end
  • the web server is in communication (e.g. via the Internet) with a web server which in turn is in communication (e.g. via the Internet) with a database server.
  • the web server and the database server are preferably located on separate computer devices to the user device.
  • the web server is responsible for implementing the back-end functionality of the Property Card application, and for transmitting data between the user device and the database sever.
  • the database server is responsible for storing data.
  • a user A claims ownership of property X (e.g. a given real-estate property), after which he receives a digital record of ownership of property X, and is able to access various features of the Property Card application as described in further detail in sections below.
  • property X e.g. a given real-estate property
  • the web server (of the Property Card application) receives, from a user device, a request for user A to claim ownership of property X.
  • the request is preferably received via a user interface of the Property Card application on a user device of user A.
  • the webs server transmits a request to the user device for: proof of ownership of property X by user A (e.g. a title deed), and data related to user A (e.g. user A personal information, such as full name, scan of passport, address, and contact details (e.g. email and address)).
  • proof of ownership of property X by user A e.g. a title deed
  • data related to user A e.g. user A personal information, such as full name, scan of passport, address, and contact details (e.g. email and address)
  • the web server receives the proof of ownership of property X by user A and the data related to user A, from the user device of user A.
  • the proof of ownership is received as a PDF document and/or an image (e.g. JPEG or PNG) of user A’ s title deed to property X; and the user A information is received via a user interface of the Property Card application.
  • the proof of ownership and/or user information may be received in a variety of ways - e.g. as a digital record (e.g. NFT), or in encoded (e.g. XML or JSON) format.
  • the proof of ownership is stored in the database server and associated with a digital record (see further details below) of the property.
  • the web server verifies the proof of ownership received at step 106.
  • the verification of the proof of ownership comprises: extracting data from the received proof of ownership file (e.g. via OCR on the received image), and verifying the authenticity of data from the proof of ownership. Verifying the authenticity of the data may comprise: transmitting a request to a third-party server (e.g. a land registry API) comprising data extracted from the proof of ownership (e.g. user A and Property X data extracted from a title deed to Property X) to verify that the extracted data matches a record in a database of the third-party server.
  • a third-party server e.g. a land registry API
  • the verification at step 108 may also comprise verifying the identity of user A based on the received user information at step 106 (e.g. via verifying that the identification document provided by the user is legitimate and that it matches the remaining information provided by the user).
  • verification of the proof of ownership at step 108 is performed manually by an operator of the web server.
  • method 100 terminates.
  • a corresponding ‘failure’ notification is transmitted to the user device of user A.
  • the web server searches a digital record database of the database sever for a digital record associated with property X.
  • the digital record database stores conventional identifying information for properties (e.g. houses or cars) and corresponding unique identifiers (token ids) for digital records of the properties, and thus allows mapping the property information contained in the proof of ownership received at step 106 (i.e. conventional identifying information - e.g. full address for real-estate, or licence plate for a car) and a digital record of property X.
  • properties e.g. houses or cars
  • token ids unique identifiers
  • each digital record of a property comprises a non-fungible token (NFT) - i.e. a non- interchangeable unit of data stored on a blockchain.
  • NFT non-fungible token
  • Each digital record is uniquely associated with a property (e.g. realestate property), and uses a digital ledger to provide a digital proof of ownership of a property - e.g. of ownership of property X by user A.
  • the digital record / NFT therefore functions as a digital title deed to the property.
  • the digital record stores property ownership information (including a chain of ownership - e.g. by storing a transaction history in metadata of the NFT).
  • the digital record preferably also stores further ancillary information related to the property as metadata - e.g. the proof of ownership received at step 106, or data related to features of the property (e.g. inventory of a home).
  • the digital record may store data in a tree structure, with the token id of the digital record acting as a root node for the tree.
  • the information stored on the digital record may be partially publicly accessible and partially private (e.g. the address and valuation of a real-estate property may be public, but the proof of ownership private).
  • the digital records are stored on an Ethereum blockchain. It will be appreciated that the digital records may be stored on alternative blockchains instead of, or in addition to Ethereum - e.g. on a Solana, or Bitcoin Cash blockchain.
  • the web server instead of searching the digital record database, at step 110, the web server searches a marketplace database of the blockchain (on which the digital records are stored) to identify an NFT associated with property X.
  • the web server If a digital record for property X is not found at step 112, the web server generates a new digital record / NFT for property X at step 114. Metadata (e.g. the above-mentioned further ancillary data) related to the property is also stored on the digital record.
  • the web server updates the digital record associated with property X to denote user A as the owner of the digital record.
  • the web server optionally also generates a digital certificate for the digital record associated with Property X, and stores it as metadata in the blockchain.
  • the digital certificate functions as proof of authenticity of the digital record, and may include one or more of: owner information, the NFT’s status, serial number, and/or token ID.
  • the web server transmits a further proof of ownership of the digital record / NFT associated with property X to the user device of user A.
  • the further proof of ownership comprises: a cryptographic key/token associated with the digital record; and/or the above-described digital certificate; either of which the user can safely store and then use to prove his ownership of the digital record.
  • the further proof of ownership may be downloadable as a pass on the user device of user A (e.g. an Apple® Wallet Pass), which user A can use to prove ownership of property X.
  • Method 100 may provide several technical advantages.
  • generating a digital record may provide a more secure and reliable proof of ownership than a conventional proof of ownership due to the security and immutability of the blockchain on which it is stored.
  • the conventional proof of ownership need only be verified once (at step 108), after which the digital record itself can be used as proof of ownership.
  • the digital record on the blockchain can be harder to falsify than a conventional title deed, and so provides improved security.
  • NFTs / digital records can be used as a proof of ownership replacing the title deed.
  • the digital blockchain verified assets are a powerful tool of verifying the owner of a property.
  • the Property Card application/platform may only allow a rent payment request and approval to go through if the owner holds the NFT of that property.
  • the NFT is the digital title deed that cannot be subjected to fraud in the digital world.
  • an NFT / digital record of ownership goes beyond rent payment.
  • the use cases are at least the same as having the physical title deed. This may allow users full control over the property, including but not limited to proof of address, transfer of ownership (e.g. selling via blockchain).
  • Figure 1c an example user interface of the Property Card according to a first embodiment is shown.
  • Figure 1c shows an ‘empty’ Property Card ready to be connected by an owner or tenant.
  • the top section of the card shows the Address.
  • the middle section shows the Property Details of the card, which can be edited by the user.
  • the bottom of the card holds all payments and services related to the home in one place.
  • the Document Storage holds all documents.
  • the user’s Wallet that connects a user’s bank account directly to the Property Card, so that all payments/bills can be automated in one place.
  • FIG. 1c an example user interface of the Property Card is shown.
  • Bellow the gallery of images that can be uploaded by users is the Property Details section.
  • This section contains extensive property details and inventory. Specifically, the inventory allows users to upload images of all sections of the property, with detailed notes and comments on the condition, as well as a time stamp to mark entry.
  • property inventories are carried out by contacting a professional, booking a calendar date, making payment, and waiting for a professional to visit the home and conduct an inventory clerk to carry out an inventory of the home, before providing the data back to the owner of the home in an offline format at the end of a tenancy. This can now be carried out inside the Property Card.
  • the Inventory section allows both users - the owner and tenant - to carry out their own inventory or book a professional, using the app or website, inputting all details/photos/condition of the home into the Inventory section. Normally, the inventory happens offline without sharing data between the parties. With the Property Card, all the data exists in the Property Card ‘Property Details’ section, visible to all parties with a timestamp at the time of entry, so that no disputes arise as to the condition of the home at each interval. This extensive data collection process has not been done before in a shared product visible at all times between owner, tenants, and inventory clerks.
  • the Calculator of the Property Card shows the live valuation of the property, along with other real-time financials. Specifically, users can enter the exact financials of their property: the purchase price, mortgage, stamp duty, closing costs, and refurbishments, to calculate the real-time investment amount, equity, and profit and loss. This is a proprietary real-time calculator that changes based on the live valuation of the property. Property values are not static. And with the Calculator, users can edit the valuation to estimate various sale proceeds. This is particularly useful when planning to sell a home (for owners looking to sell their property) or buying a home (for viewers estimating costs of entering the transaction). No property site online today offers this innovative tool that incorporates a live valuation and real-time finances before purchase.
  • this shows the Sell page where owners can list their Property Card for sale.
  • This is seamless and immediately lists the Property Card for sale in the Search.
  • Other users can they view the Property Card when browsing homes to buy. Viewers may then contact owners directly via the PropertyCard app. Completing the transaction may also happen via the app. Conveyancing and smart contracts can all be done digitally. Once legal and conveyancing costs have been covered, the new buyer may purchase the home from the owner and payments can happen via Open-Banking through PropertyCard. Everything happens in one place.
  • the Property Card ownership transfers to the new owner. The Property Card then appears in the ‘Cards’ page of the new owner. Seamlessly, we transfer digital title from one to another. Offline logistics continue - including paperwork and official registry with UK Land Registry.
  • FIG. 5a, 5b, and 26 a flow diagram illustrating an example method of facilitating payments related to a property.
  • said payment is a payment for rent of a home between an owner and tenant of the home.
  • An owner may setup a rent request, after which a tenant receives an email requesting them to connect their bank account to the same Property Card of the owner.
  • the owner and the tenant both connect their bank accounts to the Property Card application/platform, and are associated with the same home (i.e. the same instance of the Property Card associated with a given home). Once their bank accounts are connected, then said connections can be used across all of their transaction whether as tenant or owner of a given Property card instance.
  • the method may comprise the following steps:
  • Owner creates an account and claims his/her home (confirms association with the home). For example, as described above with reference to Figure la, the owner may upload a copy of their title deed (which is then verified by a person or an automated system, e.g. where the name and address on the title deed are matched to the Property Card account user). Alternatively, the owner may claim his home via the land registry.
  • Owner fills tenancy data, e.g.:
  • Tenant receives the email and creates an account using the same email, which is instantly verified.
  • Tenant receives a successful response with a payment URL and, via the payment URL, gets redirected to the payment service provider server to finish the payment.
  • Owner can deactivate the tenancy or update its details and send a new request to the tenant.
  • the above process may comprise the following steps. Users create an email-based account and connect their bank account. Then they receive an Open-Banking ID and Customer Account which is saved in the database. Then, the TTP-Gateway API is called using the Open-Banking regulatory permission as an Account Information Service Provider (AISP). This API returns a URL redirecting users to select and authenticate their bank account.
  • ALSP Account Information Service Provider
  • TTP -Payment Requests Single Payment, Standing Order, and Scheduled Payment.
  • Standing order TTP -Payment request retrieves the Open-Banking Pay URL to initiate a Standing Order, via a Third-Party Provider (TPP) (payment service providers). This payment may have a start and end date, amount, frequency, as well as sender/receiver bank credentials.
  • steps 4-6 above are instead replaced by the following: the owner invites the tenant to the platform by inputting the tenant's email address; an email notification is sent to the tenant inviting him to sign up to the platform; after the tenant signs up, they will be able to enter a "claim code" to claim the property card as a tenant; after the tenant signs up and claims the card, the owner is able to send a payment request by selecting the tenant from a drop down list of all his tenants on that property.
  • FIG. lb a flow diagram illustrating a further example method 200 of facilitating payments related to a property is shown.
  • the method 200 comprises the following steps:
  • Step 222 connecting to an account of a first user; where step 222 comprises: o Step 202 - receiving a request, from the first user’s user device, to connect to the account of the first user; o Step 204 - transmitting a request for authentication of the connection to a payment service provider; o Step 206 - receiving a URL for authentication from the payment service provider, and providing the URL to the first user to authenticate the connection;
  • Step 208 receiving, from the first user, a request for a payment by a second user, and receiving data related to the payment;
  • Step 210 transmitting a request for the payment to the second user
  • Step 212 connecting to an account of the second user; where step 212 comprises: o receiving a request, from the second user’s user device, to connect to the account of the second user; o transmitting a request for authentication of the connection to a payment service provider; o receiving a URL for authentication from the payment service provider, and providing the URL to the second user to authenticate the connection;
  • Step 214 receiving approval of the payment request by the second user
  • Step 216 upon receipt of the approval of the request, transmitting data related to the accounts of the first and second users (and to the payment) to a payment service provider for completion of the payment.
  • Method 200 may further comprise one or more of the following steps in any order or combination:
  • the above described methods of facilitating payments can improve the security of the payment as it removes the need for parties to exchange sensitive financial information, or the need for manual entry of said information.
  • account data e.g. data including banking client secrets and ids
  • account data is stored only temporarily to complete a payment (and deleted afterwards), and the only data stored after completion of the payment is data related to the payment initiated via the platform.
  • Data is preferably stored encrypted.
  • each entity e.g. first user, second user, and/or payment service provider
  • each entity is given only those privileges / access rights (e.g. read or write rights for various data) needed to complete a given task/action - i.e. the least possible privileges needed to complete the task.
  • privileges / access rights e.g. read or write rights for various data
  • the entity is not granted that right (even if its identity might normally give it access to that right - i.e, the function of the entity (and not its identity) controls the granting of rights).
  • the first user has access rights to his sensitive data (e.g.
  • the first user requests to read this sensitive data during the task of requesting payment from the second user, the first user’s request will be denied.
  • This can improve security, and assist in preventing attacks by third parties (e.g. it may allow preventing a SQL injection attack, as an entity is only given access needed to complete a task, regardless of their identity).
  • data is encrypted prior and/or in transmission.
  • all API communication preferably uses an encrypted HTTPS protocol.
  • open banking standards are preferably adhered to for authentication and verification of users (when connecting to their accounts).
  • Utilities bundles users can pay for all their utilities in one place with our innovative Utilities bundles. These bundles are made available via partner APIs to provide real-time Utilities bundles that users can book to pay for all their utilities in one place. These include Energy, TV/WiFi, Water and Council Tax. Based on the Property Details entered into the Property Card above, the Utilities bundles will re-price in real-time. Several options are made available: gold, silver and bronze packages with varying levels of service. The deals will automatically be chosen and calculated based on the Property Details entered by the user above. So, based on the property’s address and other information like bedroom, bathroom, and area, the relevant deals will be presented. This saves users tremendous time researching the best deals in the market for their home.
  • This search is personalized for the user and their home. This is innovative. It also saves users tremendous time in managing the utilities. Rather than book deals one by one, they book a bundle - and our service providers handle the rest. When it’s time to leave the property and disconnect the utilities, users can simply disconnect their utilities bundle and the services then terminate.
  • Mortgages can be booked directly through our Mortgage marketplace in the Property Card. These deals are provided via our partner APIs and based on the data entered into Property Details above.
  • Mortgage applications normally require significant data to be provided, and users must fill extensive forms. Specifically, applicants must provide personal and property details to apply for a mortgage. Personal details include credit scores, bank statements, and financial documents to assess affordability.
  • Property details include the house valuation and other detailed inventory. All of this information is present inside the Property Card under ‘Property Details’ and the personal information is found in a user’s Profile and Wallet. All the information required for a mortgage application are therefore present and collected in advance inside the Property Card. This speeds up the application process and allows us to show users relevant mortgages only inside the Mortgage marketplace.
  • the Document Storage section allows users to upload documents from their camera or gallery for storage. Every Property Card has a Document Storage section that stores the data. This is where users store their Title Deed, which is verified by our verifications team to ensure accuracy. Additional documents like smart contracts, NFTs, and other digital paperwork may also be stored inside Document Storage.
  • Each Property Card has a ‘Relationships’ section showing the owner, tenants, viewers, agents, inventory clerks, and other users that may interact with the property at any given time. This is innovative and has not been done before via a seamless product that brings all human relationships into the property at any given time. From the ‘Relationships’ tab the owner is the administrator and may invite additional users.
  • the Wallet page allows users to connect their bank account to the Property Card. From the user’s point of view, this may be done simply by clicking the ‘Connect Bank’ button which prompts users to select their bank and perform a KYC check. Once this is done, the Property Card becomes ‘connected’, allowing 1-click instant payments throughout the app. This also allows us to connect a user’s credit score to their Property Card, thereby improving over time. Property payments are the largest portion of household spending however these house payments are not reflected on most credit scores.
  • PropertyCard Wallet links the two together. In the Wallet, every payment made through the Property Card is tracked and linked directly to a user’s bank statement and credit score. And reward points are granted for every pound spent via the Property Card. This is like Visa and Mastercard’s reward programs. Over time, reward points accrue, and lucrative rewards will be given to users. Everything now happens seamlessly in one place.
  • Disconnecting the bank account also happens simply inside the wallet, greatly simplifying the process of vacating a home.
  • a user may immediately stop the flow of payments through the home and can begin check-out.
  • the data collected for the above-described functionality - e.g. data relating to rent, and/or data relating to the utilities (e.g. regarding the terms of the current service providers) is preferably stored as metadata on the digital record of the property and/or is stored in the database server as associated with the digital record. Accordingly, increasing amounts of data relating to each digital record (that is uniquely associated with a property) is collected over time. This data collected data can then be used to streamline various processes for the user - e.g. a mortgage application, as described in further detail below.
  • the recommendation engine may continuously monitor a Property Card for optimal deals to maximize savings for users. In doing so the Property Card may notify a user of saving opportunities to achieve this end. These may be Opt-In notifications that do not spam and bombard users with unsolicited mail.
  • the savings opportunities may be stored and associated with the Property Card, and may be available for display upon request.
  • the recommendation engine may calculate the difference between current deals in the Property Card and one or more other deals in the market. This difference (the available savings) may be presented to the user in real-time, offering the user the ability to switch to cheaper deals to save money.
  • the current services may be calculated on monthly and yearly basis and compared to the available deals in the marketplace.
  • FIGs 24a and 24b schematic diagrams of example software architecture of the system used for facilitating payments related to a property according to first and second embodiments respectively is shown.
  • the system architectures of the first and second embodiments are identical, except in respect of the provided functionality (as shown in the Front-end section of Figures 24a and 24b).
  • the back-end (central) database / database server aggregates and stores all data received from the ‘data lakes’.
  • the backend may consist of one or more (optionally cloud) servers (e.g. servers running Google Cloud Platform) for storing and manipulating data. It may comprise further servers (e.g. Python servers using Flask back-end frameworks) for managing the received data related to each Property Card (to each home). Using this data, the back-end may generate a valuation for each home using a combination of machine-learning algorithms (and transmit this valuation to the front-end). Additionally, the above-mentioned or further servers (e.g. Node.JS servers using Express. JS frameworks) may be used to manage authentication of user accounts.
  • the database may be an Elastic Search Database.
  • the endpoint for fetching and updating property data may thus be the Elastic Search database.
  • the back-end may further comprise on or more modules (APIs) such as a banking module, services module, payment module or a communications module.
  • APIs such as a banking module, services module, payment module or a communications module.
  • banking module such as a banking module, services module, payment module or a communications module.
  • services module such as a banking module, services module, payment module or a communications module.
  • communications module such as a Wi-Fi module, etc.
  • it may comprise an Open-Banking API endpoint for Rent, Energy, TV & WIFI, and Mortgages for authentication, recognition, deals and transactions.
  • the various servers/modules on the back-end are also collectively referred to herein as a ‘web server’.
  • the technology build may use React.JS Web Frameworks and one or more of the following tools and resources for functionality: React hooks function, Redux toolkit for state management, Axios Library for calling APIs, and Firebase for authentication and emails.
  • the front-end system may use server-side rendering for all property pages thereby providing permanent fixed URL/SEO for every Property Card. This may facilitate easy and direct access for homeowners and tenants.
  • meta tags may be used for Facebook, Instagram, Twitter, and other social channels and sites to enhance searchability and indexing.
  • the database server and the web server are cloud servers.
  • the cloud servers are preferably implemented on a Virtual Private Cloud (VPC) environment, e.g. on Amazon Web Services (AWS®).
  • VPC Virtual Private Cloud
  • AWS® Amazon Web Services
  • Each VPC is a logically isolated network which can allow separating data and applications from the cloud provider’s (e.g. AWS®) other clients, while reaping the benefits (e.g. scalability) of a public cloud. This logical isolation may improve the security of the cloud environment.
  • a serverless computing model is preferably used whereby the cloud provider allocates physical severs on demand (as opposed to always using the same specific dedicated severs).
  • a microservices architecture is preferably used for services on the backend.
  • only one server - e.g. a load balancer / API gateway server - is in communication with the client (i.e. user device).
  • the remaining servers communicate with the user device via the load balancer server. This can improve security of the system.
  • the data stored on the database server is preferably encrypted at rest (i.e. encrypted when on disk), and requires encryption keys to decrypt it. This can improve security of the data storage.
  • users Upon login to the Property Card application, users are preferably authorised using a token-based authorisation system, such as Firebase.
  • a token-based authorisation system such as Firebase.
  • Figure 21 shows an example UI for the front-end
  • Figure 22 an example UI for the back end (database).
  • Figures 24a and 24b show how the two systems communicate symbiotically in real-time, facilitating seamless usage of the Property Cards for all users, on all devices.
  • Every Property Card may be connected to the database so that every user and every interaction improves property valuations and services.
  • the system infrastructure may serve to increase value, efficiency, and transparency for all parties involved.
  • the database may centralize and standardize all the data with the purpose of providing ever-increasing valuation accuracy and improved services for all users, so that they can maximize savings of money and time in managing their property.
  • the computer device 2000 comprises a processor in the form of a CPU 2002, a communication interface 2004, a memory 2006, storage 2008 and a user interface 2012 coupled to one another by a bus 2014.
  • the user interface 2012 comprises a display 2016 and an input/output device, which in this embodiment is a keyboard 2018 and a mouse 2020.
  • the Property Card may be an application installed on the computer device 2000.
  • the Property Card may have associated instructions that are also in the form of computer executable code, stored in the memory 2006 and/or the storage 2008.
  • the Property Card may also have instructions for operating, receiving, and/or sending data via the communication interface 2004.
  • the CPU 2002 is a computer processor, e.g. a microprocessor. It is arranged to execute instructions in the form of computer executable code, including instructions stored in the memory 2006 and the storage 2008.
  • the instructions executed by the CPU 2002 include instructions for coordinating operation of the other components of the computer device 2000, such as instructions for controlling the communication interface 2004 as well as other features of a computer device 2000 such as a user interface 2012.
  • the memory 2006 is implemented as one or more memory units providing Random Access Memory (RAM) for the computer device 2000.
  • the memory 2006 is a volatile memory, for example in the form of an on-chip RAM integrated with the CPU 2002 using System-on-Chip (SoC) architecture.
  • SoC System-on-Chip
  • the memory 2006 is separate from the CPU 2002.
  • the memory 2006 is arranged to store the instructions processed by the CPU 2002, in the form of computer executable code.
  • only selected elements of the computer executable code are stored by the memory 2006 at any one time, which selected elements define the instructions essential to the operations of the computer device 2000 being carried out at the particular time.
  • the computer executable code is stored transiently in the memory 2006 whilst some particular process is handled by the CPU 2002.
  • the storage 2008 is provided integral to and/or removable from the computer device 2000, in the form of a nonvolatile memory.
  • the storage 2008 is in most embodiments embedded on the same chip as the CPU 2002 and the memory 2006, using SoC architecture, e.g. by being implemented as a Multiple-Time Programmable (MTP) array.
  • MTP Multiple-Time Programmable
  • the storage 2008 is an embedded or external flash memory, or such like.
  • the storage 2008 stores computer executable code defining the instructions processed by the CPU 2002.
  • the storage 2008 stores the computer executable code permanently or semi permanently, e.g. until overwritten. That is, the computer executable code is stored in the storage 2008 non-transiently.
  • the computer executable code stored by the storage 2008 relates to instructions fundamental to the operation of the CPU 2002.
  • the communication interface 2004 is configured to support short-range wireless communication, in particular Bluetooth® and WiFi communication, long-range wireless communication, in particular cellular communication, and/or an Ethernet network adaptor.
  • the communications interface is configured to establish communication connections with other computing devices and/or a server.
  • the server may be used to store data and to perform certain processing, in particular more computationally complex processing.
  • the server may act to train an artificial neural network, which may then be communicated to a computer device 2000 such that “on-the-fly” calculations can be performed.
  • the storage 2008 provides mass storage for the computer device 2000.
  • the storage 2008 is an integral storage device in the form of a hard disk device, a flash memory or some other similar solid-state memory device, or an array of such devices.
  • removable storage which provides auxiliary storage for the computer device 2000.
  • the removable storage is a storage medium for a removable storage device, such as an optical disk, for example a Digital Versatile Disk (DVD), a portable flash drive or some other similar portable solid state memory device, or an array of such devices.
  • the removable storage is remote from the computer device 2000, and comprises a network storage device or a cloud-based storage device.
  • a computer program product includes instructions for carrying out aspects of the method(s) described below.
  • the computer program product is stored, at different stages, in any one of the memory 2006, storage device 2008 and removable storage.
  • the storage of the computer program product is non-transitory, except when instructions included in the computer program product are being executed by the CPU 2002, in which case the instructions are sometimes stored temporarily in the CPU 2002 or memory 2006.
  • the removable storage 2008 is removable from the computer device 2000, such that the computer program product is held separately from the computer device 2000 from time to time.
  • the web server and database sever may also be implemented on computer devices 2000.
  • FIG. 11 shows an ‘empty’ Property Card ready to be connected by an owner or tenant.
  • the top section of the card shows the Address.
  • the middle section shows the Data and Valuation of the card, which can be edited by the user.
  • the bottom of the card holds all services and payments related to the home in one place.
  • the bottom part connects a user’s bank account directly to the Property Card, so that all services/bills can be automated in one place.
  • a plurality of properties each have their own associated Property Card.
  • the Data and Valuations section may contain all available data about the property which is aggregated and stored in a database and associated with property (so that it may be displayed in the Property Card). This includes three primary sources of data: Crowdsourced (directly from users adding data into the Property Card), Private (e.g. from property portals, data partners, and other suppliers via APIs connected directly to a (central) database), and Public (e.g. sale prices from Land Registries).
  • Crowdsourced directly from users adding data into the Property Card
  • Private e.g. from property portals, data partners, and other suppliers via APIs connected directly to a (central) database
  • Public e.g. sale prices from Land Registries
  • the data may be prioritized in the order described above, with Crowdsourced data having the higher priority, then Private data acquired from partners and suppliers, and finally Public data that is freely available at any time to everyone. This means when there is crowdsourced data entered into the Property Card by a homeowner or tenant, this data will be used to value the property. When this data is unavailable, then private data will be used. And finally, public data will be used (the least valuable and most likely to be outdated and with gaps in the information). Crowdsourced data may have the highest value because homeowners and tenants have the best insight into the latest conditions of a home including refurbishments, extensions, conversions, condition, etc.
  • a machine learning module may then train a machine learning model (preferably an artificial neural network) based on this data to produce an estimate of a metric of one or more homes and store the estimate in the database.
  • a machine learning model preferably an artificial neural network
  • the metric may be a valuation of the property.
  • FIG. 23 is an example user interface showing accuracy statistics for a machine learning module.
  • Figure 23 shows accuracy statistics for a number of predicted home valuations as compared to the true sale price.
  • the machine learning module attempts to simulate non-linear relationships from all the data fields to produce higher accuracy. It is not always clear how different parameters affect a property’s price.
  • the machines can attempt to make relationships between these data fields, all with the purpose of producing more accurate valuations when compared to the actual sales prices. For example, a 3 -bedroom sold in Kent this month may affect another 3 -bedroom sold in Manchester the next.
  • the human agent is unable to capture any meaningful links between these two transactions, however the machine learning module - when analysing millions of transactions and their respective features - can begin to generate associative insights across the database that result in higher accuracy valuation predictions.
  • the format of the database may be standardized and digitalized so it can be viewed and transmitted via an API directly to-and-from a computer device of a user or a data source.
  • the property fields may for example include smart meter readings, and/or the number of bedrooms.
  • the valuation may be converted to any currency.
  • the back-end of the system comprises a database server.
  • the back-end of the system may comprise a database and/or a storage layer using Elastic Search for Indexing, Storing, and Querying large amounts of data.
  • This layer may be on the back-end of a property engine micro-service which handles incoming data from various sources, including third-party integrations and internal APIs which connect the front and back-end.
  • users may connect their (bank) account to the Property Card. From the user’s point of view, this may be done simply by clicking the ‘Connect Bank’ button which prompts users to select their bank.
  • the Property Card may automatically ‘recognize’ financial transactions pertaining to the home, and store them in the database as associated with the given Property Card corresponding to the home. Further, and once a bank account is connected, users may book services instantly with 1 -click real-time switches to ensure they are always on the best deal.
  • the Property Card is ‘Connected’.
  • a new deal may be booked by the user by accessing the Energy Marketplace which aggregates the best service providers and deals in the market at any given time, to provide optimal energy efficiency and maximum savings. Once connected, the Property Card may continue to monitor the market for better deals.
  • TV/WIFI Marketplace which aggregates the best service providers and deals in the market at any given time, to provide optimal choice and the best price. And once a deal is connected, the Property Card may continue to monitor the market for better deals for the user.
  • Mortgages may also be booked directly through the Property Card. Normally the Mortgage process requires extensive property/personal information, takes significant time, and involves multiple parties in the chain. Simplifying this process, the Property Card may already collect the ‘property’ data required for the application. Further simplifying the process, the Property Card may also collect the ‘personal’ data required through your banking connection - e.g. personal affordability and credit checks can be done automatically in the background.
  • the Property Card may provide an estimated valuation of the property, which is normally required by bank surveyors in the application.
  • All pieces of the Mortgage application may thus be available within the Property Card thereby speeding up the MIP (Mortgage In Principle) process tremendously.
  • a user may be able to connect directly through the Mortgage Marketplace.
  • the estimated valuation may be used as a starting point for a mortgage application. This may be a major factor disrupting the mortgage chain, allowing for speedier processing of mortgages and loan re-finances.
  • the Property Card may continue to monitor the marketplace for cheaper mortgages that may arise (which they often do - as most mortgage holders miss out on optimal refinances (they are in fact typically eligible for cheaper refinancing every 2-3 years but seldom capitalize on this)).
  • FIG. 19 shows the recognition and auto-reconciliation process which may happen instantly once a user’s account is connected to the Property Card.
  • Existing property -related deals that are in place may be recognized and reconciled in one place on the Property Card. Once that happens, alternative deals may be recommended to a user.
  • the user’s payments for a service related to a property may first be recognised within the user’s account transactional history.
  • a pattern matching algorithm may be used to detect the user’s energy payments from their aggregated transactional history.
  • a data related to alternative providers of the service may be requested and received from a server (e.g. a third- party API).
  • a server e.g. a third- party API
  • the available energy suppliers and deals for cheaper switching may be received.
  • the transmitted data may comprise any one or more of: the selected quote id (a unique id of the selected alternative provider’s quote), user’s personal information (e.g. name, address), bank account information, accepted terms that protects the suppliers’ rights, supplier info, and the energy deal information.
  • the user may be redirected to the provider’s website to switch the deal.
  • the same process may be done for other services such as TV or WIFI.
  • the list of alternative provider offers may be filtered according to selected filters (see e.g., Figure 16 for example TV/WIFI filters).
  • the Recognition process may be used in conjunction with the below Recommendation Engine for Available Savings.
  • the Property Card may greatly simplify the process of vacating a home. By disconnecting his account from the Property Card associated with the home, a user may immediately stop the flow of payments through the home and can begin the process of checking-out of the home.
  • the owner of the property pays for (preferably all) services associated with property, and the tenant only pays ‘rent’ to the owner.
  • the owner may charge higher ‘rent’ prices to compensate for this.
  • the tenant only needs to stop rent payments, and they may be able to leave the property without any further financial actions (e.g. they may not need to halt energy, TV, or WIFI payments).
  • the tenant may disconnect their account from the Property Card to stop rent payments (which may optionally be set in advance for the tenancy term). Accordingly, on ‘checkout’, a tenant may only need to disconnect their account from the Property Card.
  • the present disclosure is particularly well applicable to facilitating transactions related to a property. It may be used as a form of real estate and property management software - in particular for owners and tenants of residential property. Homeowners and tenants may connect to their account via a Property Card syncing the two directly together. Once this happens, the Property Card may recognize financial transactions relating to the home and present them all in one place. The Property Card may also be able to monitor the owner or tenant’s financial status, credit history and affordability ratios - and use this to identify (preferably continuously) alternative service providers so that a user may optimize their expenditure and the Property Card.
  • the present invention may enable ‘customer-centric’ synchronization and connection of a customer’s account directly to a home, to allow real-time, automated, and personalized management of the home with optimal results.
  • the Property Card may instantly recognize financial transactions linked to the home and present them all in one place. In this way, each user may have their bank account and their home updated and linked in real-time ‘recognizing’ all related transactions in the right compartments.
  • the present invention may further enable connecting a (bank) account to a home, to automate and optimize management of the asset to save users money and time.
  • the present invention may allow ‘connecting’ and ‘syncing’ a bank account directly to a property, so that data flows in real-time between both.
  • the Property Card may be accessed remotely on a computer device (e.g. on the web, mobile, application, tablet (e.g. in-home panels for direct one-touch management).
  • a computer device e.g. on the web, mobile, application, tablet (e.g. in-home panels for direct one-touch management).
  • the Property Card may be incorporated into a ‘smart home’ system.
  • Every Property Card preferably has a permanent URL that exists online and can be accessed directly on all devices.
  • the Property Card (and by extension, the ‘house’) becomes its own ‘unit’ that becomes self-managing. Owners and tenants can come and go, while the Property Card remains in perpetuity to be managed by future owners and tenants who interact with the asset. Most homes outlive humans, so it is convenient for management of this asset to shift over time from the ‘people’ towards the ‘homes’ themselves.
  • the present invention may allow simplified management of all payments related to a property - e.g. it may remove the need for a user to repeatedly fill in financial and/or personal details for each service provider (for services related to the property); and/or it may simplify disassociating from a property - e.g. a tenant who moves out of a home may only need to disconnect their account (so e.g. a user will not accidentally forget to stop paying utility bills).

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Primary Health Care (AREA)
  • Human Resources & Organizations (AREA)
  • General Health & Medical Sciences (AREA)
  • Technology Law (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé (200) pour faciliter des paiements. Le procédé consiste à : se connecter (222) à un compte d'un premier utilisateur ; recevoir (208), du premier utilisateur, une demande de paiement par un second utilisateur, et éventuellement recevoir des données relatives au paiement ; transmettre (210) éventuellement une demande de paiement au second utilisateur ; se connecter (212) à un compte du second utilisateur ; et lors de l'approbation de la demande par le second utilisateur, transmettre (216) les données relatives aux comptes des premier et second utilisateurs (et éventuellement au paiement) à un fournisseur de services de paiement pour l'achèvement dudit paiement.
PCT/GB2022/050160 2021-02-01 2022-01-20 Système et procédés de paiement WO2022162346A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB2101377.6 2021-02-01
GBGB2101377.6A GB202101377D0 (en) 2021-02-01 2021-02-01 Payment system and methods

Publications (1)

Publication Number Publication Date
WO2022162346A1 true WO2022162346A1 (fr) 2022-08-04

Family

ID=74865360

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2022/050160 WO2022162346A1 (fr) 2021-02-01 2022-01-20 Système et procédés de paiement

Country Status (2)

Country Link
GB (1) GB202101377D0 (fr)
WO (1) WO2022162346A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5216594B2 (ja) * 2005-11-14 2013-06-19 エスケー プラネット カンパニー、リミテッド 無線インターネットでのサービスサーバーの認証方法及びこれを用いた決済方法
US20150242834A1 (en) * 2014-02-21 2015-08-27 HomeAway.com, Inc. Split payment engine and method to facilitate electronic transaction aggregation
US20150324762A1 (en) * 2014-05-11 2015-11-12 Ashley Cook Payment processing system, apparatus and method in real estate transactions
US20190356641A1 (en) * 2014-03-31 2019-11-21 Monticello Enterprises LLC System and Method for Performing Social Media Cryptocurrency Transactions
US10621561B1 (en) * 2017-07-26 2020-04-14 Square, Inc. Payment network using tradable financial assets

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5216594B2 (ja) * 2005-11-14 2013-06-19 エスケー プラネット カンパニー、リミテッド 無線インターネットでのサービスサーバーの認証方法及びこれを用いた決済方法
US20150242834A1 (en) * 2014-02-21 2015-08-27 HomeAway.com, Inc. Split payment engine and method to facilitate electronic transaction aggregation
US20190356641A1 (en) * 2014-03-31 2019-11-21 Monticello Enterprises LLC System and Method for Performing Social Media Cryptocurrency Transactions
US20150324762A1 (en) * 2014-05-11 2015-11-12 Ashley Cook Payment processing system, apparatus and method in real estate transactions
US10621561B1 (en) * 2017-07-26 2020-04-14 Square, Inc. Payment network using tradable financial assets

Also Published As

Publication number Publication date
GB202101377D0 (en) 2021-03-17

Similar Documents

Publication Publication Date Title
US11042883B2 (en) Integrated online and offline inventory management
US11244388B2 (en) Methods and systems for assessing performance and risk in financing supply chain
US20180108085A1 (en) Systems and methods for providing enhanced loan qualification
US9916582B2 (en) Systems and methods for generating and using a digital pass
US8326725B2 (en) Method and system for obtaining user data from third parties
US11900373B2 (en) Blockchain agnostic token network
US10043206B2 (en) Facilitating transactions in connection with service providers
US20120254002A1 (en) Centralized financial management tool and method of use
WO2021077099A1 (fr) Plateforme numérique de traitement de transactions immobilières
US20180158039A1 (en) Mobile Vehicle Acquisition System and Method
KR20130017676A (ko) 개인 물품 관리와 중고 거래 기능을 제공하는 서버 및 그를 이용한 중고 물품 거래 시스템
US20150019362A1 (en) System and method for creating fractional ownership of physical goods
US20230334492A1 (en) Blockchain agnostic token network
WO2022162346A1 (fr) Système et procédés de paiement
WO2020056455A1 (fr) Système de transaction

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 23.11.2023)