PAYMENT SYSTEM AND METHODS

Field of the Invention

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.

Background to the Disclosure

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.

Further, people often use multiple parties and service providers to manage their property (e.g. home) and its related services/finances. This requires effort and leads to inefficient and costly management and plenty of savings left on the table. For example, home values make up roughly l/3rd of global wealth and l/3rd of household spending and related finance. However, these payments are scattered across multiple providers, and can be difficult to manage for users. If owners and tenants fail to monitor this asset adequately (which they predominantly do, due to the lack of adequate tools, transparency, and overall solutions available to do this), they miss out on many benefits: money/time. Further, admin around this asset piles up, mail arrives at the door, customer service and the related overall ‘experience’ managing homes is anything but smooth. Existing methods for house management often require multiple parties and are ‘service-centric’ - pushing individual one-off transactions without taking into account the entire picture of the customer and the relating property.

The present disclosure seeks to at least partially alleviate the problems outlined above.

Summary of the Disclosure

Aspects of the disclosure are set out in the accompanying claims.

According to an aspect of the invention, there is provided 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.

Optionally, 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.

Optionally, 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.

Optionally, connecting to an account further comprises redirecting said user to said URL.

Optionally, 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).

For improved security, in storage, said data related to the account(s) and/or to the user(s) is preferably encrypted at rest. For the same reasons, 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. For the same reasons, data is preferably encrypted prior to transmission to a user and/or the payment service provider.

Optionally, the method includes transmitting data related to the payment for storage. Preferably, in storage, said data related to the payment is encrypted at rest.

For improved security, 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.

Preferably, the method further comprises transmitting a request for confirmation of completion of said payment to the payment service provider. Preferably, the method further comprises transmitting a notification of completion of said payment to the first and/or second users.

Optionally, the method further comprises associating the second user as a user of the property.

Optionally, 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.

Preferably, 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.

Preferably, 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.

Optionally, 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.

Optionally, 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.

Optionally, the displayed data is filtered upon a user input.

Optionally, the method further comprises determining (and optionally presenting) savings associated with alternative providers in comparison to a current provider of one or more services.

Optionally, 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.

Optionally, the method further comprises performing a credit check.

The data may be received from a connection module and/or from a database.

Optionally, the method further comprises estimating (preferably via a machine learning module) a metric related to the property. Optionally, the estimated metric is transmitted to the services module. Optionally, the estimated metric is a valuation of the property.

Optionally, data related to alternative providers is received periodically, and optionally a notification related to one or more alternative providers is transmitted to the user.

Optionally, 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.

Optionally, 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.

Optionally, the utilities are any one or more of: energy, water, heating, TV, Internet (WIFI), landline, and/or sanitation.

Optionally, if no further payments are identified, the method further comprises receiving data related to alternative providers of said service(s), and optionally presenting the data to the user.

Optionally, 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).

Optionally, 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). Optionally, 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.

Optionally, 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).

Optionally, 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).

Optionally, the method further comprises the step of receiving data related to the accounts of the first and second users. Optionally, the data related to the accounts comprises one or more of: bank account unique identifiers; bank name (or other identifying information).

Optionally, the method further comprises storing received data in a database (and/or transmitting said data to a database for storage).

Optionally, the payment is one of: a single payment, a standing order, or a scheduled payment.

Optionally, 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.

Preferably, 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).

Optionally, data and/or request(s) are received from / transmitted to a computer device and/or server.

Optionally, 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.

Optionally, the method is computer-implemented.

Optionally, the method produces an output.

Optionally, the method presents the output. Preferably, the method presents the output on or to a display.

Optionally, the method further comprises producing an output.

Optionally, the method further comprises presenting the output.

Optionally, the method further comprises presenting the output on or to a display.

According to another aspect, there is provided 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.

Optionally, the transaction is a financial transaction and/or a payment.

Optionally, the method includes transmitting the request to the second user, preferably for approval by the second user.

Optionally, receiving, from the first user, a request for the transaction with the second user further comprises receiving data related to the transaction. Optionally, the method further comprises transmitting data related to the transaction to the payment service provider for completion of said transaction.

Optionally, 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.

Optionally, the method includes transmitting data related to the account/ s) of and/or to the first and/or second users for storage. Optionally, in storage, said data related to the account(s) and/or to the user(s) is encrypted at rest. Optionally, wherein 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. Optionally, 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.

Optionally, 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.

Optionally, the transaction is a payment for use of a property.

Optionally, the method further comprises associating the first user as an owner of the property.

Preferably, 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. Preferably, 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.

Preferably, generating a digital record comprises: generating a non-fungible token, and transmitting said token to a node of a blockchain.

Preferably, 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.

According to an aspect of the invention, there is provided 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.

According to an aspect of the invention, there is provided 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.

According to an aspect of the invention, there is provided a computing device for facilitating payments comprising a controller configured to cany out any method as herein described.

Optionally, the computing device further comprises a display configured to display data to a user (e.g. data related to alternative providers).

According to an aspect of the invention, there is provided a smart home comprising a computing device as described herein.

According to an aspect of the invention, there is provided a system for facilitating payments comprising, a server and a computing device according to any device herein described.

Optionally, the server is configured to receive data and provide the data to the computing device.

According to an aspect of the invention, there is provided 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.

Optionally, the system further comprises a machine learning module for estimating a metric of the property. Optionally, the system further comprises a services module.

According to an aspect of the invention, there is provided 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.

According to an aspect of the invention, there is provided 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.

According to an aspect of the invention, there is provided 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.

Optionally, the method further comprises any, some or all of the steps of in any order:

• receiving a training dataset relating to a plurality of properties;

• training an artificial neural network based on the training dataset;

• receiving a further training dataset;

• re-training the artificial neural network;

• transmitting the estimate of the metric to a/the server.

The metric may be a valuation (sale price) of the property.

According to another aspect of the present invention, there is provided 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.

According to another aspect, there is provided 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.

According to another aspect, there is provided a system for facilitating transactions, the system 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.

According to another aspect of the present invention, there is provided 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.

According to another aspect, there is provided 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.

Optionally, the external server is a payment service provider.

According to another aspect, there is provided 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).

This may allow more secure and reliable sharing of data of two users with a third-party, whereby the users need not share data with one another.

Optionally, the external server is a payment service provider.

According to another aspect, there is provided a computer device adapted to send a transaction to a node of a blockchain. Preferably, the transaction relates to ownership of a property.

According to an aspect of the invention, there is provided 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.

Optionally, 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)

Optionally, data is transmitted to / received from a server.

In a further aspect, the present invention provides any, some or all of the features in any order:

• Storing data in a database, e.g. data related to the property, the first and/or second users and/or their accounts;

• Assigning a unique identifier (preferably a URL) to the property; preferably wherein the unique identifier does not change over time;

• Displaying data related to the property and/or to the payment(s) related to the property to the first and/or second user.

• Synchronization and Connection of a bank account to a home through the Open-Banking technology network.

• Public, transparent property valuation accuracy statistics for all homes against the government land registry.

• ‘ Crowdsourcing’ data collection process using machine-learning algorithms to produce real-time valuations.

• Centralizing and managing all property -related services in one place, powered by Open-Banking technology.

• Proprietary rent collection/payment peer-to-peer between owners and tenants on the same Property Card.

• Recognition/ Auto-reconciliation of property -related transactions from bank account to the Property Card.

• Proprietary recommendation engine calculating ‘Available Savings’ for all UK properties and in real-time.

• Proprietary notification centre with opt-in/out control system linked to real-time services marketplace.

• 1-click real-time property services and switches, linked to bank account and recommendation engine.

• Central real estate database standardizing and digitizing global property data in a central format.

It can be appreciated that the methods can be implemented, at least in part, using computer program code. According to another aspect of the present disclosure, there is therefore provided 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. Alternatively, it may be a disk, such as a Digital Video Disk (DVD-ROM), or a non-volatile memory card, e.g. a flash drive or mini/micro Secure Digital (SD) card. It could also be 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.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Any apparatus or device feature as described herein may also be provided as a method feature, and vice versa. As used herein, 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.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the disclosure can be implemented and/or supplied and/or used independently.

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.

The disclosure extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

Each of the aspects above may comprise any one or more features mentioned in respect of the other aspects above. In this specification the word 'or' can be interpreted in the exclusive or inclusive sense unless stated otherwise.

Use of the words “apparatus”, “server”, "device", "processor", “database” and so on are intended to be general rather than specific. Whilst these features of the disclosure may be implemented using an individual component, such as a computer or a central processing unit (CPU), they can equally well be implemented using other suitable components or a combination of components. For example, they could be implemented using a hard-wired circuit or circuits, e.g. an integrated circuit, and using embedded software. They could also be made up of a number of separate computers such as a cloud service offering. Examples of cloud service offerings can include Platform as a Service (PaaS).

It should be noted that the term "comprising" as used in this document means "consisting at least in part of’. So, when interpreting statements in this document that include the term "comprising", features other than that or those prefaced by the term may also be present. Related terms such as "comprise" and "comprises" are to be interpreted in the same manner. As used herein, "(s)" following a noun means the plural and/or singular forms of the noun.

The disclosure will now be described, by way of example, with reference to the accompanying drawings.

Brief Description of the Drawings

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. Here, 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.

Detailed Description of Preferred Examples

The present disclosure is described with reference to transactions related to residential real-estate as a specific example of transactions. However, the disclosure could equally be applied to a number of other transactions (e.g. software licences).

Equally, the disclosure could be applied to transactions related to a number of other properties, such as commercial real-estate.

Further, 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. In fact, the disclosure could be applied to transactions related to any kind of property (tangible or intangible).

A person skilled in the art will appreciate that the present disclosure provides a method of conducting financial transactions in a more secure and seamless manner (e.g. where financial details need not be shared between the tenant and owner of a home).

First embodiment

Referring to Figures la to 10, 24a, 26, and 27, a first embodiment of the present invention will now be described.

PROPERTY CARD

According to an example, 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 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. Through this Property Card, homeowners and tenants may connect their account to automate management of their primary asset seamlessly and securely.

In the present example, the Property Card application is implemented as an application on a user device. The application (i.e. front-end) 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.

Referring to Figure la, an example method 100 of associating a property with a user is shown. In the present example, 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.

First, at step 102, 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.

In response to the request at step 102, at step 104, 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)).

Next, at step 106, 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. In the present example, 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. It will be appreciated that 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.

Next, at step 108, the web server verifies the proof of ownership received at step 106. In the present example, 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.

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).

In an alternative example, verification of the proof of ownership at step 108 is performed manually by an operator of the web server.

If the proof of ownership is not verified (i.e. at step 108, the web server determines that the proof of ownership is not authentic), method 100 terminates. Optionally, a corresponding ‘failure’ notification is transmitted to the user device of user A.

If the proof of ownership is verified at step 108, then next, at step 110, 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.

In the present example, each digital record of a property comprises a non-fungible token (NFT) - i.e. a non- interchangeable unit of data stored on a blockchain. 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. For real-estate property, the digital record / NFT therefore functions as a digital title deed to the property.

Further, 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).

In the present example, 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.

In an alternative example, 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.

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.

If a digital record for property X is found at step 112 or after a new digital record is generated at step 114, at step 116, 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.

Finally, at step 118, 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. In the present example, 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. Optionally, 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. In particular, 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. Further, using method 100, 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. Thus, only one party needs to verily the proof of ownership, and further parties can rely on the secure (and verified) digital record as proof of ownership. Notably, the digital record on the blockchain can be harder to falsify than a conventional title deed, and so provides improved security.

Further, 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. In the case of rent payment, 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. Similarly, in the physical world, you will only rent and pay to the person holding the title deed of the property you are renting. The NFT is the digital title deed that cannot be subjected to fraud in the digital world.

Moreover, the value of 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).

Referring to 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. As shown in Figure 1c, 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. At the bottom is the Document Storage that holds all documents. And on a separate page is 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.

PROPERTY DETAILS

Referring to Figure 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 is shown in Figure 2. 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. Traditionally, 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.

CALCULATOR

Referring to Figure 3 - 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.

SELL

Referring to Figure 4a and 4b, 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. Once the transaction is completed, 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.

RENT

Referring to Figures 5a, 5b, and 26, a flow diagram illustrating an example method of facilitating payments related to a property. In Figures 5a, 5b and 26, 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. In other words, 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.

In this way, two users are connected to the same Property Card. By doing this, rent payments flow seamlessly and securely from tenants to owners, through monthly direct debits. This removes friction and unnecessary admin in the rent process. Further, this removes the need to share banking details between owner and tenant, nor with the Property Card platform. All details are provided and validated once the user connects, via open banking, their bank account to their account on the platform. Throughout the tenancy, owners and tenants may be connected to the same Property Card and may be able to view payments easily on any device, anywhere anytime. Both users may access the Property Card using the same permanent URL for the home. This method of collecting and paying rent may enable a secure and direct peer-to-peer payment gateway directly connecting owners and tenants to the same home through ‘Open-Banking’ technology. This may remove unnecessary parties, and provide added security and payment efficiency since neither card details nor account details are shared or inputted by users.

More specifically, the method may comprise the following steps:

1. 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.

2. Owner connects his bank account using 2 Open-Banking APIs which create a customer and ‘TPP-gateway’ (see further details below). Once a user’s bank account is connected to the user's account on the platform, it is available to the user across the entire platform to pay and receive payments from rent and various services offered (e.g. utilities). Hence a bank account is linked to an account on the platform and can be used for all property payments, whether by an owner or tenant.

3. Owner fills tenancy data, e.g.:

• Start/End Date.

• Rent Amount/Frequency.

• Tenant Email and Tenant Name.

4. Owner clicks ‘ Send Payment Request’ button, after which the tenancy data is stored in the database, preferably in addition to unique identifiers for the property and for the owner, after which an email is sent to the tenant (including a unique tenant ‘claim code’ which he can use to claim the home).

5. Tenant receives the email and creates an account using the same email, which is instantly verified.

6. Tenant claims his home (e.g. by entering the unique claim code) and may see the Property Card in ‘Tenant Mode’.

7. Tenant connects his bank account.

8. Tenant clicks the ‘Initiate Payment’ button which results in a standing order TTP payment request being sent to a (Open-Banking) payment service provider for the tenant’s bank account, the request containing:

• Both owner/tenant bank accounts IDs.

• Required payment amounts/currencies.

• Payment frequency.

• F irst/Last payment dates .

• Provider banks for both users.

9. 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.

10. Owner can deactivate the tenancy or update its details and send a new request to the tenant.

In more detail, 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. There are 3 types of 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.

In an alternative example, 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.

Referring to Figure 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; and

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

• Transmitting a request for confirmation of completion of the payment to the payment service provider;

• Receiving a notification of completion of the payment from the payment service; and/or • Transmitting a notification of completion of the payment to the first and/or second users.

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.

To further improve the security of above-described methods of facilitating payments, payment, user, and/or account data (e.g. data including banking client secrets and ids) is preferably encrypted at rest when stored. Preferably, 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.

For further security, each entity (e.g. first user, second user, and/or payment service provider) 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. If an entity does not need an access right to complete the action, 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). For example, even if the first user has access rights to his sensitive data (e.g. to his proof of ownership, such as a title deed), if 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).

Moreover, data is encrypted prior and/or in transmission. For example, all API communication preferably uses an encrypted HTTPS protocol.

Further, open banking standards are preferably adhered to for authentication and verification of users (when connecting to their accounts).

UTILITIES

Referring to Figure 6, 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.

MORTGAGE

Referring to Figure 7, 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. Further, and after booking a mortgage, users will be alerted when cheaper mortgage deals become available so they may refinance their mortgage to lower rates. All of this is completely innovative and never been done in this way before. Mortgages normally take 30 days to turnaround. With the Property Card, this will be reduced significantly to a few days. In the future, the aim is to have instant mortgages booked within minutes. Property Card will facilitate the fastest mortgage turnaround times by having all information present in advance and linking directly to all the banks via Open-Banking. DOCUMENT STORAGE

Referring to Figure 8, 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.

RELATIONSHIPS

Referring to Figure 9 - 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.

WALLET

Referring to Figure 10 - 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. By disconnecting the bank account from the Property Card associated with 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.

RECOMMENDATIONS ENGINE

The recommendation engine (module) 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.

Optionally, the current services may be calculated on monthly and yearly basis and compared to the available deals in the marketplace.

This feature may be most useful with services like Mortgage or Utilities, where the marketplace changes often and most users are unaware of favourable deals that may present themselves. Additionally, mortgages tend to have fixed and floating-rate periods in which rates (and thereby mortgage costs) vary considerably. In these periods, the Property Card may alert users to real-time mortgage refinancing that can save considerable cost. SYSTEM ARCHITECTURE

Referring to Figures 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. For example, 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’.

On the front-end, 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.

Optionally, meta tags may be used for Facebook, Instagram, Twitter, and other social channels and sites to enhance searchability and indexing.

In the present example, 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®). 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.

Further, 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. Preferably, 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.

Upon login to the Property Card application, users are preferably authorised using a token-based authorisation system, such as Firebase.

Figure 21 shows an example UI for the front-end, and 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. In this way, 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.

COMPUTING DEVICE Referring to Figure 27, there is shown a computer device 2000 suitable for executing the methods described herein. 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. In the illustrated embodiment, 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. However, in other embodiments, 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. Typically, 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. In other words, 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. However, in other embodiments, 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. Typically, 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. In particular, 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. In general, 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. In different implementations, 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.

In some embodiments, there is provided removable storage, which provides auxiliary storage for the computer device 2000. In different implementations, 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. In other embodiments, 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 is provided that 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. It should also be noted that 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. In an alternative example, the web server and database sever may also be implemented on computer devices 2000.

Second embodiment

Referring to Figures 11 to 23, 24b, and 25, a second embodiment of the present invention will now be described. The second embodiment is identical to the first embodiment, except where specified below.

Referring to Figure 11, an example user interface of the Property Card according to the second embodiment is shown. FIG. 11 shows an ‘empty’ Property Card ready to be connected by an owner or tenant. As shown in Figure 11, 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. And finally, 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.

Preferably, a plurality of properties each have their own associated Property Card.

DATA & VALUATION

Referring to Figure 12, an example user interface of the Property Card is shown. The first part of the Property Card that may be viewed and edited by a user is the Data and Valuations section as shown in FIG 12. This 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).

Together all this data aggregates from multiple sources and funnels into the database and its relevant Property Cards. 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.

For example, the metric may be a valuation of the property.

Traditionally, property valuation techniques were based on weighting parameters and re-weighting them to achieve greater accuracy. The problem is that linear models cannot achieve reliable accuracy because the relationship between the parameters and valuation is highly non-linear and can only be found in an extremely high multi-dimensional space. What this means in simple terms is that property -valuation is a highly subjective, unique, and creative exercise. House values have an emotional component, and many factors may come into play (more often these factors are not directly tangible). There is also conflict of interest between agents who may inflate house values to win your business. By contrast, the machine learning module may be a self-learning, unbiased system that automatically generates thousands of new complex features from the already extensive set of property data. Its Machine-Learning algorithms attempt to simulate non-linear relationships that fit the given data most accurately. In addition to the obvious property data fields such as bedrooms/bathrooms (like most property valuers consider), the module considers crowdsourced unique data such as refurbishments that can acutely impact the valuation of a 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. Working backwards from these sales figures, 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. In using unbiased algorithms with thousands of related and unrelated features, 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.

CONNECTING

After Data/Valuation - and to access the full benefits of the Property Card, 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. Once this is done, 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’.

SERVICES

A. ENERGY

If a user already has an existing energy deal, it will be recognized automatically on the card. And if there is no energy deal in place, 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.

B. TV & WIFI

If a user already has an existing TV/WIFI deal, it may be recognized automatically on the card. And if there is no TV/WIFI deal in place, a new deal may be booked by the user by accessing the 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.

C. MORTGAGE

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.

Further, 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.

When a user’s mortgage deal is booked, 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)).

RECOGNITION AND AUTO-RECONCILIATION

Referring to Figure 19, an example user interface of the Property Card showing current service providers is shown.

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.

In more detail, the user’s payments for a service related to a property may first be recognised within the user’s account transactional history. For example, a pattern matching algorithm may be used to detect the user’s energy payments from their aggregated transactional history.

Next, a data related to alternative providers of the service may be requested and received from a server (e.g. a third- party API). For example, the available energy suppliers and deals for cheaper switching may be received.

Next, (continuing with the example of energy payments) following retrieval of the existing energy -payment and new energy deals, the savings a user can benefit from when switching energy providers may be displayed to the user.

Next, upon a user’s selection of a provider, data related to the user and/or to the provider may be transmitted to an application of the provider to complete the switch. For example, 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.

DISCONNECTING

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.

Optionally, 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. In this way, in order to vacate the property, 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. As the user connects their account to their house, 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. In particular, the present invention may allow ‘connecting’ and ‘syncing’ a bank account directly to a property, so that data flows in real-time between both.

Moreover, 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). 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. In this way, 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).

ALTERNATIVE EXAMPLES AND EMBODIMENTS

A person skilled in the art will appreciate that many different combinations of embodiments and examples described with reference to Figures la to 27 may be used alone unmodified or in combination with each other. The described examples of the invention are only examples of how the invention may be implemented.

Modifications, variations and changes to the described examples will occur to those having appropriate skills and knowledge. These modifications, variations and changes may be made without departure from the scope of the claims.