IOT DEVICES

Abstract

A method of operating an Internet of Things (IoT) device, the IoT device capable of communicating with a third-party system in order to perform an autonomous task subject to authorisation by an IoT authorisation device, the method comprising: sending operating parameters relating to the autonomous task to a user for approval; receiving user-approved operating parameters for the autonomous task; configuring the IoT device to perform the autonomous task within the user approved operating parameters; registering the user approved operating parameters with the IoT device management server to enable the IoT authorisation device to check that the IoT device is operating within the user-approved operating parameters when it performs an autonomous task with the third-party system.

Claims

1. A method of operating an Internet of Things (IoT) device, the IoT device capable of communicating with a third-party system in order to perform an autonomous task subject to authorization by an IoT authorization device, the method comprising: sending operating parameters relating to the autonomous task to a user for approval; receiving user-approved operating parameters for the autonomous task; configuring the IoT device to perform the autonomous task within the user approved operating parameters; registering the user approved operating parameters with the IoT authorization device to enable the IoT authorization device to check that the IoT device is operating within the user-approved operating parameters when it performs an autonomous task with the third-party system.

2. The method as claimed in claim 1, wherein the IoT device is associated with a digital wallet containing a tokenized payment card and the autonomous task comprises performing a transaction with the third-party system.

3. The method as claimed in claim 1, wherein sending operating parameters comprises sending a plurality of operating parameters to the user for approval and wherein receiving user-approved operating parameters comprises receiving a user selection of one or some of the plurality of operating parameters

4. The method as claimed in claim 1, wherein configuring the IoT device comprises restricting the IoT device to communicate with specified third-party systems according to the user-approved operating parameters.

5. The method as claimed in claim 1, wherein configuring IoT device comprises restricting the IoT device to carry out specified autonomous tasks according to the user-approved operating parameters.

6. The method as claimed in claim 1, comprising, prior to sending the operating parameters to the user, requesting environment data relating to an environment that the IoT device will operate in and determining the operating parameters to send to the user for approval based on the received environment data.

7. The method as claimed in claim 1, comprising, prior to sending the operating parameters to the user, sending a request for usage data to the user and determining the operating parameters to send to the user for approval based on the received usage data.

8. The method as claimed in claim 1, comprising initiating the autonomous task with the third party system, the autonomous task comprising sending a communication to the third party system via the IoT authorization device.

9. The method as claimed in claim 8, comprising sending an IoT device identifier and a request to the IoT authorization device for authorization to carry out the autonomous task.

10. A method of operating an Internet of Things (IoT) relay device to manage interactions with an IoT device, the IoT device capable of communicating with a third-party system in order to perform an autonomous task subject to authorization authorisation by an IoT device management server, the method comprising: receiving, at the IoT relay device, operating parameters relating to the autonomous task; sending, from the IoT relay device to a user, the received operating parameters for user approval of the operating parameters; receiving, at the IoT relay device, user-approved operating parameters for the autonomous task; sending, from the IoT relay device, the user-approved operating parameters to the IoT device to allow the IoT device to configure itself such that autonomous tasks can be performed in accordance with the user-approved operating parameters.

11. The method as claimed in claim 10, comprising sending, from the IoT relay device, the user-approved operating parameters to an IoT authorization device.

12. A method of operating an Internet of Things (IoT) authorization device, the IoT authorization device configured to manage interactions between an IoT device and a third-party system, the IoT device capable of communicating with the third-party system in order to perform an autonomous task, the method comprising: receiving a request from the IoT device to perform the autonomous task with the third-party system, the request comprising: an IoT device identifier and parameter data related to the autonomous task; looking up user-approved operating parameters for the IoT device using the IoT device identifier contained in the request; comparing the parameter data contained in the request against the stored user-approved operating parameters for the IoT device; authorizing the request to perform the autonomous task in the event that the parameter data conforms to the stored user-approved operating parameters.

13. The method as claimed in claim 12, comprising establishing a communications path between the IoT device and the third-party system

14. The method as claimed in claim 12 claims 12 or claim 13, comprising, in the event that the received parameter data does not conform to the stored user-approved operating parameters, notifying a user or an IoT relay device and requesting approval for the task.

15. The method as claimed in claim 12, comprising, in the event that the received parameter data does not conform to the stored user-approved operating parameters, sending a command signal to the IoT device to disable the IoT device.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0045] One or more embodiments of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0046] FIG. 1 shows schematically an overview of a transaction system in accordance with an embodiment of the present disclosure;

[0047] FIG. 2 is a flow chart of method of operation of the system of FIG. 1;

[0048] FIG. 3 is a flow chart of a method of operating an IoT authorisation device according to an embodiment of the present disclosure;

[0049] FIG. 4 is a flow chart of a method of operating an IoT relay device according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0050] General and specific embodiments of the disclosure will be described below with reference to the Figures.

[0051] The “Internet of Things” (IoT) generally refers to the concept of connecting devices to the Internet and each other. Potentially any device may be made Internet capable and in the context of the present application IoT device may include, without limitation, mobile phone devices, wearable devices (such as smartwatches), TVs, washing machines, printers, fridges, vehicles, smart glasses, headphones etc.

[0052] The systems and methods described herein allow IoT devices to perform autonomous transactions. An IoT server (or “backend” server) facilitates provisioning of IoT devices with a payment application 103 (a “digital wallet”), provisioning one or more payment cards into the payment application and performing transactions between a merchant (or a merchant server) and an IoT device.

Overview

[0053] FIG. 1 illustrates an exemplary system 100 in which one or more aspects of the present disclosure are described. The system 100 includes an IoT device 102 (in FIG. 1 an Internet enabled dishwasher is shown but it is to be appreciated that this could be any IoT device) comprising a payment application 103, a merchant 104 (or merchant server), an IoT server 106 (which as described below may be used to provision a digital wallet/payment application on the IoT device and to handle any tokenization/detokenization processes and to perform security checks on transactions initiated by the IoT device 102), and an issuer entity 108 associated with a cardholder (not shown) who has provisioned (via the IoT server 106 or otherwise) one or more payment cards to the IoT device 102 (such that the digital wallet comprises a digitised payment card). An acquirer entity 110 that is associated with the merchant 104 is also shown in FIG. 1.

[0054] The IoT server 106 comprises an IoT device management processor 112, a wallet processor 114 which is arranged to provision a cardholder's payment card into a payment application 103 within the IoT device 102 (the wallet processor may also be referred to herein as a token service provider) and a merchant connectivity processor 116. The token service provider may also tokenise payment card data and issue tokens to the IoT device 102. The tokens may take the form of a token PAN (primary account number), or a token PAN and a token expiry date.

[0055] It is noted that three separate processing units/processors are shown within the IoT server 106 but the functionality provided by the three units may be provided by a single processing platform.

[0056] The IoT device management processor 112 comprises a data store 118, e.g. in the form of a database, within which a plurality of profiles 120 are stored.

[0057] The IoT device 102 comprises a processor 122 which is in communication with the payment application 103. The processor 122, as described below, is arranged to set operating parameters for the IoT device 102. Setting the operating parameters may comprise issuing a number of operating parameters 124 to a user/owner of the IoT device 102 and receiving user-approved operating parameters 126 in return. The user-approved operating parameters 126 may comprise some or all of the operating parameters 124 that were issued by the IoT device 102. The user-approved operating parameters 126 may also comprise user specified parameters.

[0058] The IoT device 102 comprises an IoT device identifier 128 that may be used by, for example the IoT server 106, to identify the IoT device 102 in order to determine whether to authorise a transaction to be made by the MT device 102.

[0059] The system 100 further comprises a relay device 130 comprising a processor 132. The relay device 130 may take the form, for example, of an Internet of Things hub which is located at a location, e.g. a user's home, and which is configured to manager the operation of one of more IoT devices 102. The system 100 further comprises a user device 134.

[0060] As shown in FIG. 1, the relay device 130 and user device 134 may comprise a payment application 103 of their own. The relay device 130 may forward operating parameters 124 suggested by the IoT device 102 to the user device 134 for approval and may additionally forward user-approved operating parameters 126 from the user device 134 to the IoT device 102. It is noted that the relay device 130 shown in FIG. 1 is shown as a physical device but in alternative configurations may be configured as an application (“app”) on the user device 134.

[0061] The operation of the IoT device 102, relay device 130, user device 134 and IoT server 106 are described below.

[0062] The IoT device 102, merchant 104, IoT server 106, issuer 108, acquirer 110, relay device 130 and user device 134 are each coupled to and in communication with one or more networks which are represented by the dotted and solid arrows in FIG. 1. The networks may comprise any of the following: wired or wireless networks, a local area network, a wide area network, a mobile communications network, the Internet.

[0063] In the system 100, the IoT server 106 and relay device 130 may, depending on the particular configuration of the system 100, be configured to authorise tasks that the IoT device 102 may autonomously undertake in dependence on the user-approved operating parameters that have been set. As such the relay device 130 and/or IoT server 106 may operate as an IoT authorisation apparatus.

[0064] Methods of use of the system of FIG. 1 are shown in FIGS. 2 to 5 and described below.

[0065] FIG. 2 is a flow chart detailing an overall method of operating the IoT device 102 in accordance with an embodiment of the present disclosure. In FIG. 2 the process of configuring and setting the IoT device 102 up for operation within a particular environment is described.

[0066] It is noted that in FIG. 2, the IoT device 102 is considered to comprise a digital wallet that contains a tokenised payment card and that the IoT device 102 is being configured in order to allow it to carry out autonomous tasks with a third party (in this case the merchant 104). It is to be appreciated however that there are alternative configurations for the IoT device 102 to interact with the third party. For example, the relay device 130 may instead comprise the payment application 103 (as shown in FIG. 1) and the autonomous tasks that the IoT device 102 performs with the third party (merchant 104) may instead be routed through the relay device 130.

[0067] Returning to FIG. 2, in step 200, operating parameters 124 relating to an autonomous task that the IoT device 102 can perform are sent, by the processor 122, to the user device 134 in order to be approved. The operating parameters 124 for approval from the user are sent from the IoT device 102 to the user device 134 via the relay device 130. It is noted that in an alternative arrangement the operating parameters may be sent directly to the user device 134 (see arrow 136).

[0068] As described herein, the operating parameters may be sent from the IoT device 102 but in alternative configurations the operating parameters may be supplied from another source, e.g. from the IoT server 106 or the relay device 130.

[0069] The operating parameters 124 that are sent for user approval may comprise predetermined parameters. For example, the operating parameters may relate to a transaction amount limit that the IoT device 102 cannot exceed when carrying out a transaction with the merchant 104. Such a transaction amount limit may be set by the manufacturer of the IoT device and stored within the IoT device 102 during manufacture such that it can be suggested to the user during the set up process.

[0070] The operating parameters may also comprise a selection of autonomous tasks that the IoT device 102 is authorised to undertake. For example, in the transaction example above, the operating parameters may comprise a list of products that the IoT device 102 may obtain from the merchant 104.

[0071] The operating parameters that are sent for approval may also comprise the particular merchants 104 that the IoT device 102 may transact with. For example, a list of all available merchants may be suggested by the IoT device 102 to the user. The operating parameters may alternatively be configured such that the user is locked to a particular merchant 104 for a given period.

[0072] In step 202, user-approved operating parameters 126 are received at the IoT device 102 from the user device 134. It is noted that the user-approved operating parameters 126 may comprise a selection of the operating parameters 124 that were sent in step 200. For example, the user may have selected to restrict the IoT device 102 to interacting with a specific merchant 104 and may have selected a specific subset of autonomous tasks that it can carry out.

[0073] In step 204 the IoT device 102 is configured to operate as per the user-approved parameters 126 received in step 202.

[0074] In step 206 the user-approved parameters are registered with an IoT authorisation device (e.g. the IoT server 106 or the IoT relay device 130). Registering the user-approved parameters may occur because the user-approved parameters 126 are routed through the MT authorisation device as they are sent to the IoT device 102. Alternatively, the IoT device 102 may be configured to register the user-approved parameters with the IoT authorisation device after the IoT device 102 has received the user-approved parameters.

[0075] Where the user-approved parameters 126 are registered with the IoT server 106 then they may be stored within the data store 118 in the profile 120 associated with the IoT device 102.

[0076] It is noted that, following the registration of the user-approved parameters 126 with the IoT authorisation device, when the IoT device 102 undertakes to perform an autonomous task with the third party such task will require the IoT authorisation device to authorise the task to take place (as described below in relation to FIG. 3).

[0077] Prior to sending the operating parameters 124 in step 200 above, the processor 122 within the IoT device 102 may request from the IoT relay device 130 usage data relating to the user and/or environmental data relating to the environment in which the IoT device 102 is situated. The operating parameters 124 that are then sent in step 200 may then be selected in dependence on the usage or environmental data. Such an initial “data gathering” step would allow the IoT device 102 to select operating parameters 124 that are most suitable for the environment in which it is placed and the likely usage it will undertake. In the example of the dishwasher above environmental data may comprise details of the number of individuals in the home in which the dishwasher is located. For a large household the IoT device may determine that it is likely to require more consumables (dishwasher powder, rinse aid etc) and consequently suggest higher limits (higher operating parameters) than for a smaller household. Similarly, the IoT relay device 130 may have access to relevant historical usage data (e.g. in the dishwasher example the relay device 130 may have records indicating how often the dishwasher is run and how often the consumables need replacing).

[0078] The IoT device 102 may additionally or alternatively conduct the initial “data gathering” step by directly contacting the user device 134 and requesting information from the user. For example, the set up process for the IoT device 102 may include sending a short survey to the user device 134 for completion by the user. The results of such survey could be used to determine the initial operating parameters 124 to be sent to the user.

[0079] In step 208, the IoT device 102 initiates an autonomous task in dependence on the user-approved parameters 126. Such an autonomous task comprises sending a communication to the third party via the IoT authorisation device (106, 130). In the dishwasher example described above the autonomous task may comprise ordering consumables and the communication may comprise sending an order (via the IoT authorisation device) to a merchant 104 that sells the consumables.

[0080] In step 210 the IoT device receives a further communication. This further communication may be an acknowledgement from the third party that the communication from the IoT device relating to the autonomous task has been carried out (for example, in the dishwasher example, the further communication could be a transaction receipt). If the further communication received by the IoT device 102 has originated from the third party then this means that the IoT authorisation device has checked and authorised the outgoing communication in step 208 as meeting the user-approved parameters 126 as stored in the data store 118.

[0081] In the event that the communication sent in step 208 did not conform to the user-approved parameters 126 then the further communication may be a command signal to shut the IoT device down. Alternatively, the further communication may be a notification signal to the user device 134. The further communication is discussed further in relation to FIG. 3 below.

[0082] FIG. 3 shows a method of operating an IoT authorisation device in accordance with embodiments of the present disclosure. It is noted that in FIG. 1 either the IoT server 106 or the IoT relay device 130 may be configured to perform the steps below. In the context of the following description however the IoT authorisation device is taken to be the IoT server 106.

[0083] The IoT server 106 in its role as the IoT authorisation device is configured to receive and store the user-approved operating parameters 126 and to manage future interactions between the IoT device 102 and third parties (such as the merchant 104) when the IoT device 102 wants to undertake an autonomous task (e.g. in the dishwasher example, when the dishwasher places an order for consumables).

[0084] In step 300 the IoT server 106 receives a request from the IoT device 102 relating to an autonomous task that that the IoT device wishes to carry out. The request comprises the IoT device identifier 128 along with parameter data related to the autonomous task.

[0085] In step 302 the IoT device management processor 112 uses the IoT device identifier 128 to retrieve the IoT device profile 120 from the data store 118 and retrieves the user-approved operating parameters associated with that IoT device 102.

[0086] In step 304 the processor 112 compares the stored user-approved operating parameters against the parameter data contained in the request received from the IoT device.

[0087] In step 306 the IoT device management processor 112 makes an authorisation decision regarding the request received from the IoT device 102 and, in the event that parameter data in the request conforms to the stored user-approved operating parameters the IoT sever 106 will authorise the autonomous task requested by the IoT device 102.

[0088] In step 308, following a positive authorisation result in step 306, the merchant connectivity processor 116 within the IoT server 106 establishes a communications path between the IoT device 102 and the merchant 104 such that the autonomous task can be performed.

[0089] In the event that the IoT device management processor 112 makes a negative authorisation decision in step 306 (i.e. the parameter data in the request does not conform to the stored user-approved operating parameters) then the IoT server 106 may instruct the IoT device to shut down by sending a command signal. However, the IoT server 106 may, in step 310, send a notification signal to the user device 134 (either directly or via the IoT relay device 130) to request approval of the autonomous task requested by the IoT device 102. In the event that the IoT server 106 then receives approval from the user device 134 the server 106 may move to step 308 and set up communication with the third party.

[0090] FIG. 4 shows the method of operating a relay device according to an embodiment of the present disclosure.

[0091] In step 400 the processor 132 within the relay device 130 is arranged to send operating parameters 124 to the user device 134 for approval. It is noted that the IoT relay device 130 may initially receive the operating parameters 124 that are to be sent to the user device 134 from the IoT device 102. In an alternative configuration however the IoT relay device 130 may, for example, download the operating parameters 124 from an original equipment manufacturer that made the IoT device 102 and/or may generate the operating parameters 124 itself based on the technical details of the IoT device 102 (which may be supplied to the IoT relay device 130 when the IoT device is first associated with the IoT relay device 130).

[0092] In step 402 the IoT relay device 130 receives the user-approved operating parameters from the user device 134. In step 402 it is noted that the IoT relay device may be configured to store the user-approved operating parameters such that it can perform the method according to FIG. 3.

[0093] In step 404 the IoT relay device 130 is arranged to configure the IoT device to perform the autonomous task according to the user approved parameters. This may comprise forwarding the user-approved operating parameters 126 to the IoT device 102 or may comprise sending a configuration signal to configure the IoT device 102.

[0094] In the event that the IoT relay device 130 is not talking the role of the IoT authorisation device then in step 406 the IoT relay device sends the user-approved operating parameters, along with the IoT device identifier 128 to the IoT server 106 for storage in the profile 120.

[0095] Although not shown in FIG. 1 it is noted that each device (IoT device 102, IoT relay device 130 and IoT server 106) comprise a communications interface for sending and receiving the various requests, command signals, notification signals and operating parameters mentioned above.

[0096] In further variations of the above embodiments of the disclosure details of the autonomous tasks initiated by the IoT device with third parties may be sent to the issuer 108 for data enrichment of transactions. For example, details of transactions on a transaction summary (credit card statement) may be enhanced with details of the IoT device 102 that initiated the transaction.

[0097] The user-approved operating parameters 126 discussed above may additionally restrict the IoT device 102 to certain time windows for carrying out transactions with third party systems and may also specify different operating parameters for different categories of goods (e.g. an IoT fridge may have a lower limit for fresh goods compared to frozen goods). The operating parameters 124 suggested by the IoT device 102 may also be restricted (by the original equipment manufacturer, OEM) to specific third parties for consumables. In some examples the OEM may retail the IoT device 102 at a lower price point if a user accepts that the device 102 will be locked to a specific merchant or merchants.