Offline handling of data

Abstract

A client 104 apparatus stores one or more locally hosted rules 116 in association with a validity period. The client receives input data and attempts to process the input data using one or more remote

Description

The present technique relates to data processing and has particular relevance to data processing in an offline scenario. Some technical systems may operate by the interaction of a client and server. However, it is desirable for such client systems to operate, at least to some extent, when the server cannot be reached. Viewed from a first example configuration, there is provided a client apparatus comprising: input circuitry configured to receive input data; storage circuitry configured to store one or more locally hosted rules in association with a validity period; and processing circuitry configured to attempt to cause the input data to be processed using one or more remotely hosted rules to produce a first result and upload to cause the first result to be provided to a first remote server, wherein in response to one or more locally hosted rule conditions being met, the processing circuitry is configured to process the input data using the one or more locally hosted rules to produce a second result and to buffer the second result; the one or more locally hosted rule conditions comprise a first condition that at least one of the remotely hosted rules and the first remote server cannot be accessed by the client apparatus; and the one or more locally hosted rule conditions comprise a second condition based on the validity period. Viewed from a second example configuration, there is provided a method comprising: receiving input data; storing one or more locally hosted rules in association with a validity period; causing the input data to be processed using one or more remotely hosted rules to produce a first result; and uploading the first result to a first remote server, wherein in response to one or more locally hosted rule conditions being met, the input data is processed using the one or more locally hosted rules to produce a second result and the second result is buffered; the one or more locally hosted rule conditions comprise a first condition that at least one of the remotely hosted rules and the first remote server cannot be accessed by the client apparatus; and the one or more locally hosted rule conditions comprise a second condition based on the validity period. Viewed from a third example configuration, there is provided a server apparatus, comprising: receive circuitry configured to receive live data from a client apparatus, wherein the live data is based on data received from a user of the client apparatus; processing circuitry configured to determine a validity of the live data using an active rule set, and to return a result to the client apparatus; and storage circuitry configured to store an offline rule set in association with a validity period, wherein the receive circuitry is configured to also receive offline processed data from the client apparatus, wherein the offline processed data is based on the data received from the user of the client apparatus; and the processing circuitry is configured to determine whether the offline processed data meets the requirements of the offline rule set and whether the offline processed data was processed by the client apparatus within the validity period. Viewed from a fourth example configuration, there is provided a method comprising: receiving live data from a client apparatus, wherein the live data is based on data received from a user of the client apparatus; determining a validity of the live data using an active rule set; returning a result to the client apparatus; storing an offline rule set in association with a validity period; receiving offline processed data from the client apparatus; and determining whether the offline processed data meets the requirements of the offline rule set and whether the offline processed data was processed by the client apparatus within the validity period. The present technique will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which: Figure 1A shows a system in accordance with some examples in which an online behaviour is explained; Figure IB, in which the same apparatus is used to process data in an offline manner; Figure 2A shows a communication flow that occurs during online processing; Figure 2B illustrates an example in which a communications failure occurs. Figure 3 shows a communication flow that occurs when the data provided to the server is invalid; Figure 4 shows an example of the local rules that may be downloaded by the client from the server; Figure 5 shows a flowchart that illustrates a method of handling the local data when it is received at a server after an offline process has been performed by the client; Figure 6 shows an example of how transaction identifiers can be allocated in order to control the extent to which offline processing can be carried out by a client; and Figure 7 is of a flowchart that shows an example of the allocation process in more detail. Before discussing the embodiments with reference to the accompanying figures, the following description of embodiments and associated advantages is provided. In accordance with a first example configuration there is provided a client apparatus comprising: input circuitry configured to receive input data; storage circuitry configured to store one or more locally hosted rules in association with a validity period; and processing circuitry configured to attempt to cause the input data to be processed using one or more remotely hosted rules to produce a first result and to cause the first result to be provided to a first remote server, wherein in response to one or more locally hosted rule conditions being met, the processing circuitry is configured to process the input data using the one or more locally hosted rules to produce a second result and to buffer the second result; the one or more locally hosted rule conditions comprise a first condition that at least one of the remotely hosted rules and the first remote server cannot be accessed by the client apparatus; and the one or more locally hosted rule conditions comprise a second condition based on the validity period. In the above configurations, the client apparatus receives input data that is processed ‘online’ using remotely hosted rules. This might be achieved by the client apparatus sending data to an online server, or could be achieved by the client apparatus downloading information from the online server as to how the data should be processed. Regardless, the processing of the data causes a first result to be produced and this first result is provided to the server (either as a result of the server processing the data or as a result of the client processing the data and then providing it to the server). The client apparatus is also able to store locally hosted rules. In a situation in which the remotely hosted rules cannot be accessed by the client apparatus (e.g. if the client apparatus is offline and therefore unable to cause the input data to be processed online) then the processing apparatus is able to process the input data itself using the locally hosted rules to produce what is referred to as a second result. This second result is buffered. The first data and the second data are not necessarily different and in many cases may actually be identical. Furthermore the locally hosted rules and the remotely hosted rules may be the same or may be the same aside from a rule that indicates whether the input data was processed using the online rules or the offline rules. In any event, the offline / locally hosted rules have a validity period associated with them and the locally hosted rules are used to produce the second results based on this validity period. It may therefore be the case that in an offline situation in which the remotely hosted rules are unavailable, it is also not possible to use the locally hosted rules due to the validity period associated with them. Note that although multiple servers may be referred to here, there is no requirement that the servers are different physical entities. Each of the servers may in fact be one and the same server, virtual machine or servers running on physical apparatus, a hybrid approach in which certain pieces of hardware are shared and others are dedicated and could even extent to a server farm or farms that provide the indicated services. The offline rules can include calculation rules (how to perform the calculation) and validation rules (what must be carried out to ensure that the transaction is legitimate and / or permitted for refund) as well as configurations for the merchant (or even specific merchant store) and form layouts. In some examples, the second condition requires that a current time is within the validity period. The validity period can thereby be used in order to control when the locally hosted rules can be used. In this way, offline or local processing can only be performed for a limited period. This prevents a client apparatus from remaining permanently offline. In some examples, in response to one or more locally hosted rule conditions being met, the processing circuitry is configured to buffer the second result until the second remote server becomes available, at which point the processing circuitry is configured to provide the second result to the second remote server. The detection that the second remote server is available could be achieved in a number of different ways. For instance, the client apparatus could poll the server (e.g. via a ‘ping’) to determine its accessibility on a periodic basis. In some examples, an interrupt based system (such as the server reaching out to the client) could indicate the availability of the server. In any event, the buffering occurs until such time as the server can be contacted, at which time the second result is sent to the remote server. In some examples, if the server is not contacted before the validity period expires then the second data is deleted. In other embodiments, the second data is kept and could be modified to explicitly indicate its invalidity before providing it to the server. In some example, the client apparatus comprises: retrieval circuitry configured to retrieve the remotely hosted rules as the locally hosted rules. Thus in these examples, the locally hosted rules and the remotely hosted rules are initially the same. In some examples, the retrieval circuitry is configured to retrieve the validity period. In these examples, the validity period can be stored and obtained separately from the rules. This makes it possible for a same set of rules to be maintained while the validity window changes. This can help to ensure that a client apparatus is occasionally online to check for any updates made to the locally hosted rules, even if no such changes occur. In some examples, the retrieval circuitry is configured to determine the validity period based on a retrieval time of the remotely hosted rules and a predetermined limit. In these examples, the validity period is not hard coded but is instead based on when the remotely hosted rules were downloaded in order to become the locally hosted rules. In some examples, the validity period comprises a validity start time. Although it may be typical for the validity period to have an ‘end point’ to help prevent old rules from being used, another situation may be that new rules are provided but cannot be used until they come into force. In these situations, the validity period could thereby have a start period to prevent the rules being used prior to that point. In some examples, the input data relates to a transaction; and the one or more locally hosted rule conditions comprise a third condition that an amount of the transaction is less than a predetermined amount. In these examples, offline usage (via the locally hosted rules) is permitted, but only provided that the amount of the transaction is less than the predetermined amount. This helps to reduce a risk by allowing lower risk (e.g. transactions below the predetermined amount) from taking place using rules that are potentially out of date (due to being stored locally). In some examples, the one or more locally hosted rules are used to prepare the input data for a tax refund request. When a foreign visitor purchases goods, they may be entitled to receive back any tax that is included within the purchase price of the goods. The provided rules may be necessary in order to provide sufficient evidence that the legal requirements necessary for a refund to be achieved are met. For instance, the rules may require evidence of a purchaser’s foreign visitor status and that such evidence is valid. An example of this is that a passport number may need to be a certain number of characters and not part of the local tax jurisdiction. In other examples, tax refunds might only be available for transactions under a certain amount (or over another threshold). This amount might differ depending on the nature of what is purchased (e.g. consumables might have one minimum amount, while non-consumable might have another). These tax refunds may be restricted to only taking place using offline / local processing when the amount of tax to be refunded back to the visitor is less than the predetermined amount, which is set at a level of risk that is considered to be acceptable. In some examples, there may be several validity periods set, each with a different transaction amount associated so that as the offline / locally hosted rules become older and older, the transactions must be smaller and smaller in order to be performed. In some examples, the one or more locally hosted rule conditions comprise a fourth condition that a location of the client apparatus is one or more allowed locations. The location of the client apparatus could be explicitly determined, e.g. by using GPS or could be inferred for instance based on an IP address at which the client apparatus works from, or a telephone number that data is transferred from. Other techniques may also be usable. In these cases, by only allowing the offline processing to be performed when the device is in a particular location, further security can be provided. In some examples, the one or more locally hosted rule conditions comprise a fifth condition that an identity of an owner of the client apparatus is one or more allowed entities. Different versions of the client apparatus may be available to different entities. In these examples, the use of the offline / locally hosted rules may only be permitted to certain entities. The identity of each entity (and particularly if it is a permitted entity) could for instance by saved securely within a read-only portion of memory or in secure storage as may be provided by a SIM card for instance. In any event, it is expected that the identity of the client cannot be trivially changed. Software executing on the client apparatus can then be used to determine whether the client identity is one for which offline / local processing is permitted. In some examples, different entities may have different validity periods and different entities may have different combinations of validity periods and transaction amounts. For instance, larger entities or entites that have financially proven themselves may be entitled to take larger risks - either through having larger validity periods, larger transaction amounts, larger ratios of transaction amounts to validity periods or any combination of these. The reverse may be true of smaller entities. In some examples, the storage circuitry is configured to store an asymmetric key in association with the one or more rules; and the processing circuitry is configured to encrypt or digitally sign the second result using the asymmetric key. Asymmetric cryptography is used where the ‘code’ or ‘password’ used to encrypt data is different to the ‘code’ or ‘password’ used to decrypt it. For instance, the passwords may be provided as a pair (A, B), with encryption of key A being possibly only via key B and vice-versa. By providing an asymmetric key for each defined validity period, and by requiring the data to be ‘signed’ or ‘encrypted’ using this key, it is possible to verify that the data is no older newer than the key that was used to perform the encryption. In particular, not knowing what any future key will be makes it possible to prevent an entity from simply asserting that data was produced later than it actually was. At the same time, by requiring the data to be encrypted or signed, it becomes computationally intractable for a newer key to be intercepted from a third party. In some examples, the storage circuitry is configured to store one or more stored unique identifiers, each to identify a set of the input data that is processed together by the processing circuitry and that is provided with the input data. Data may be provided by a user in ‘sets’, e.g. by providing a set of related data. For instance, the set of data might relate to a single transaction. A unique identifier can be attributed to this set so that it can be referred to as a single block. A set of identifiers can be stored by the client apparatus and these can be assigned as data is provided. This makes it possible to control the number of sets of data that can be generated. In particular, if the identifiers can only be acquired in an online scenario, then only a certain number of sets of data can be processed in the offline mode before the client apparatus must be connected once again. The unique identifiers could be provided as a number, an alpha-numeric sequence, or can be encoded in graphical form (e.g. in the form of a barcode or QR code). In some examples, the processing circuitry is configured to transmit a request to a third remote server for the third remote server to provide the one or more stored unique identifiers; and the request comprises a client identifier. In these examples, the processing circuitry is able to obtain further unique identifiers by sending a request to the (third) remote server. The remote server may not always provide the identifiers but may instead make a decision as to whether or not this should be provided. Regardless, the request for further identifiers includes a client identifier that allows the server to track which unique identifiers have been provided to which clients. In some examples, in response to the one or more locally hosted rule conditions being met, the processing circuitry is configured to assign one of the one or more stored unique identifiers to the set of the user input data that is processed together. In these examples, the stored unique identifiers are assigned to sets of input data that are processed together when it is not possible for the remote server to be reached by the client apparatus and the other locally hosted rule conditions are met (e.g. when offline / local processing is permitted). In some examples, in response to the at least one of the remotely hosted rules and the first remote server being accessible by the client apparatus, the processing circuitry is configured to retrieve a remote unique identifier to assign to the set of the user input data that is processed together. In a situation where the remotely hosted rules can be used (e.g. where it is not necessary to fall back on the locally hosted rules), a different type of unique identifier can be used. The remote unique identifier can be provided on demand from the client apparatus potentially by again providing the client identifier to a remote server. Thus, each client can have an allocation of unique identifiers that are specifically used for each ‘use’ of the offline rules. In accordance with a second example configuration there is provided a server apparatus, comprising: receive circuitry configured to receive live data from a client apparatus; processing circuitry configured to determine a validity of the live data using an active rule set, and to return a result to the client apparatus; and storage circuitry configured to store an offline rule set in association with a validity period, wherein the receive circuitry is configured to also receive offline processed data from the client apparatus; and the processing circuitry is configured to determine whether the offline processed data meets the requirements of the offline rule set and whether the offline processed data was processed by the client apparatus within the validity period. The server apparatus is able to receive live data or offline processed data from the client apparatus. In either case, the live data and the offline processed data is based on data that is received from the user of the client apparatus. In particular, the live data might be the data that is received from the user of the client apparatus whereas the offline processed data may have had initial processing performed using the set of offline rules that have been applied to the data received from the user. The server apparatus is able to receive both forms of data. When the live data is received, the data that is used to produce the live data is checked for validity according to an active (online) rule set. In contrast, when the offline processed data is received, the server apparatus determines whether that offline processed data appears to be valid according to the offline rule set. Importantly, the offline rule set (which is available for downloading by the client apparatus) has an associated validity period. The server determines whether the offline processed data was processed using the offline rules within that validity period. This could be achieved by checking time stamps or by performing other validity checks (e.g. using encryption or data signing). In the event that the offline processed data was not produced using the offline rules within the associated validity period, then the offline processed data will be rejected. Otherwise the offline processed data will be accepted and further processing may be performed on it. In some examples, the server apparatus comprises: transmit circuitry configured to transmit the offline rule set and the validity period to the client apparatus. The server can thereby send the rules that are applicable while the client is offline, together with a validity period that defines the validity of that offline claim set. The lifetime of the offline claim set can therefore be controlled. In some examples, the processing circuitry is configured to determine whether the offline processed data was processed by the client apparatus within the validity period based on whether the receive circuitry receives of the offline processed data from the client apparatus within the validity period. The validity period can define not only the period in which the offline rule set is usable, but also a time period by which data processed using the offline rule set must be submitted in order to be considered valid. In some examples, the processing circuitry is configured to determine whether the offline processed data was processed by the client apparatus within the validity period based on either decrypting or successfully matching a signature using an asymmetric key associated with the validity period. For example, a symmetric key can be provided for each defined ‘validity period’. As a consequence of the data being signed using a particular key, it is possible to determine a latest date by which the data was processed. Although this does not mean that the data was not processed earlier (since a previous key could be retained and used), it marks a latest date because keys for later periods would not have been released. In some examples, the storage circuitry is configured to store a plurality of identifiers; and the receive circuitry is configured to receive an association request from a client apparatus and in response to the association request, to associate one of the identifiers with the client apparatus and to transmit the one of the identifiers to the client apparatus, in dependence on one or more association rule conditions. The identifiers could, for instance, be allocated to particular transactions as they are performed by the client - thus acting as transaction identifiers. Each of the identifiers can be associated with a client apparatus, which is able to distribute the identifiers as transactions happen. Such transactions might only be given out if and when the client apparatus is offline. In an online situation, these might be allocated by the server apparatus. In some examples, the one or more association rule conditions comprises a first condition based on a number of the identifiers associated with the client apparatus. The association rule conditions dictate the circumstances under which the identifiers can be initially associated with a client device. For instance, a client device may only be permitted a certain number of identifiers to ‘give out’ over a particular period. In some examples, the offline processed data comprises one of the identifiers that is allocated to the client device; in response to receiving the offline processed data, the one of the identifiers is marked as being used; and the one or more association rule conditions comprise a second condition based on a number of the identifiers unmarked as being used. In these examples the identifiers that are allocated to a client are used with offline processed data - e.g. so that each transaction can be identified. Only a certain number of identifiers can be given to the client at any time - in particular, only a certain number of unused identifiers can be given to a client. If a client has already been allocated a block of X identifiers that are currently unused, then further identifiers will not be allocated to that client. In some examples, in response to the processing circuitry determining that the offline processed data meets the requirements of the offline rule set, the processing circuitry is configured to initiate a tax refund request. Initiating the tax refund may involve the sending of information relating to the transaction performed by the user (including the amount of money / tax paid) and evidence of foreign traveller status to a government department. Particular embodiments will now be described with reference to the figures. Figure 1A shows a system 100 in accordance with some examples in which an online behaviour is explained. In particular a client 104 is accessed by a user 102 in order to provide input data to input circuitry 110. This input data is processed by the processing circuitry. In this example, a first result is produced via one or more transactions with a server 106, which is received by the receive circuitry 118. The exact form of these transactions is unimportant to the present invention. A large quantity of the input data (together with other data provided by the client) could be provided by the client 104 to the server 106 all at once, where it is processed. Alternatively, the server 106 could interrogate the client 104 and request information be provided from the client 104 as required. Suffice to say that as data is received at the receive circuity 118 of the server 106 from the client 104, it is processed using the server’s processing circuitry 120 using an active rule set 126 that is stored in a storage circuit 122. The active rule set 126 contains a number of rules regarding the data that is received, the format is must take, and how it should be processed. Also provided is an offline rule set 124 in the storage circuitry 122 of the server, which can be obtained by retrieval circuitry 112 of the client and stored as a set of locally hosted rules 116 in storage circuitry 114 of the client 104. The purpose of the locally hosted rules 116 will be explained with reference to the following figures. Note that in this description, a number of different server devices are defined. Although these devices may be described as individual servers, they could of course be provided by one overall server or a set of servers such as a data farm. That is to say that the role of server could be describing one single server, a group of servers with dedicated capabilities, or a group of servers that cooperate to provide all functions. Figure IB shows a system 100 in accordance with some examples in which an offline behaviour is explained with the same client 104. In this example, due to communication failure between the client 104 and the server 106 - which could be caused by the server 106 being offline, or by communications between the two devices 104,106 being disrupted, it is not possible for the first result to be immediately generated at the server 106 at a time of an interaction with the user 102. In particular, because of the communication disruption, the active rule set 126 on the server 106 is unavailable. As a consequence of the communication disruption, the input data that is provided by the user 102 is instead processed using the locally hosted rules 116, which have been previously obtained by the retrieval circuitry 112 from the server 106. The locally hosted rules 116 may resemble the active rule set 126 that would be available at the server, but may not be identical. For example, the locally hosted rules 116 may resemble the active rule set 126 but with further restrictions applied. The further restrictions may represent the additional risk that is taken as a consequence of the transaction not being resolved in a live manner. In addition or separately to this, the locally hosted rules 116 may have rules removed from the active rule set 126 in order to provide privacy and / or secrecy. Furthermore, the active rule set 126 may require access to data or information that is only available at the server 106 or that is unavailable due to the communication failure and so such rules are removed from the locally hosted rules 116. Regardless, the application of the locally hosted rules 116 allow local data 128 to be generated using the input data and other data available to the client, which may provide some initial validation of the data that has been supplied. At a later time, when the communication failure has been resolved, the local data 128 can be provided to the server 106. The present technique may be applicable to the idea of foreign visitor / tourist tax refunds. In many jurisdictions, it is possible for a foreign visitor to reclaim the sales tax or value added tax that is added to products and / or services that are available for purchase. The logic behind this decision is that the foreign visitor will not benefit from the services provided by that jurisdiction as a consequence of a sales tax and so the foreign visitor should not have to pay the tax. By allowing the foreign tourist to purchase goods and services more cheaply, they may be encouraged to visit the jurisdiction (e.g. for vacation) and to spend money. Indeed, in some situations, the tourist may even spend money while on holiday in purchasing goods or services abroad rather than in their home jurisdiction. This process, known as tax free shopping, is dependent on the foreign tourist being able to demonstrate that the goods were purchased by them (as a foreign visitor) in the country, and that the goods being purchased are exported from the country. Typically, the registration of the purchase takes place in a store and the registration may take place via the client and server arrangement previously described. The client device may be a point-of-sale (PoS) system that can be used to register the purchase with a government authority that maintains the server. In general, it may be preferable for this to be done ‘live’, e.g. by the server 106 processing the transaction and requesting any particular data that it requires, subject to the current legal and / or technological process. However, in certain circumstances, it may be permissible for a client 104 (in the event of a communications failure for instance) to perform this process offline and provide an initial non-binding view on whether a particular transaction qualifies, with the transaction being formally registered at the server 106 at a later time. The local data 128 may be produced by the client 104 in dependence on a set of conditions being met. The set of conditions may differ between applications and may even differ between clients 104. Some examples of conditions will be discussed below. A first condition to be met is that there is a communications failure or other inability for the active rule set 126 of the server 106 to be used. A second condition to be met concerns a validity period associated with the locally hosted rules 116. The locally hosted rules 116 are considered to only be valid within a certain timeframe. This can be achieved using a ‘valid to’ date if the rules can be used immediately. If the rules cannot yet be implemented or if a delay is required prior to the rules coming into effect (e.g. in respect of a technological or legal change) then a ‘valid from’ date can also be implemented. When local data 128 is to be generated, the current date is checked against these date(s) to see if generation is permitted. An effect of this is that the generation of the local data 128 is dependent on a time since the client 104 last communicated with the server 106. If too long elapses then the generation of local data 128 is prohibited due to potentially out-of-date rules being implemented. Part of the validity period may also indicate how conflicts should be resolved. For instance, if two sets of locally hosted rules 116 exist with overlapping validity periods, then the validity period of one set of locally hosted rules 116 may indicate which of the multiple sets should be given priority. As a default, the system may give priority to the locally hosted rules 116 that are younger or the locally hosted rules having a later ‘valid from date’. Where neither of these items of information are available, the system may default to the rules having a later ‘valid to’ date, since these rules are expected to be valid for longer. Other conditions will be described in more detail below. Having produced this local data, it can be provided to the server 106 at a later time such as well the server 106 becomes available once more. The local data can then be provided to the server 106 where further checks and / or processing can be performed. Figure 2A shows a communication flow 200 that occurs during online processing. At a step 202, input data is received from a user 202. At step 216, input data is received at the client 104 by interaction with the user 102. For instance, this might include the user providing their passport for a digital scan to be made, or providing their passport number and / or details of their visit to provide evidence of their tourist status. The interaction with the user 102 might also include the user 102 providing details of the transaction - although this data may also be obtained automatically or by the merchant. The user 102 might also provide details of how they are to receive a refund of the tax and / or other details such as their home address or other contact details. In the present case, an attempt to process the input data using the server 106 is made at step 204. In this case there is no communications failure and a number of interactions are made between the server and client as the input data is processed using the active rule set on the server at step 206. This results in processed data being produced at the server 208. Note that in other examples, the series of interactions causes the processed data to be generated on the client 104, with the data being transmitted to the server 106. Regardless, with the processed data being generated, a refund is instructed based on the processed data at step 210. Figure 2B illustrates an example in which a communications failure occurs. At step 214, the set of offline rules are obtained as the set of locally hosted rules 116. These are stored in the storage circuitry 114 and contain (or are coupled with) a validity period for those rules. In this example, the rules are provided by the server at step 226. At that point, the server 106 goes offline at step 228 thereby causing the communications failure to occur. Note that in this example, the validity period is explicitly set out as a particular date (e.g. from the server 106). However, the validity period could be determined implicitly using a set of rules. For instance, the validity period could simply be defined as a certain number of days since the offline rules were last downloaded. This can be provided as a specific date from the server 106 or can be inferred from the client 104 (with the validity still being enforced by the server 106). At step 216, input data is obtained via interaction with the user 102 in the manner previously described. Then, at step 218, an attempt to made to process the data using the active rule set 126 on the server 106. Here, the attempt to process the data fails due to the server 106 being offline. Consequently, the first of the two conditions is met. At a step 220, the validity period associated with the locally hosted rules 116 is checked. In this example, it is assumed that the validity period requirements are met and thus the second condition is met. Consequently, at step 222, the input data is processed using the locally hosted rules / offline rules 116 that have been obtained and stored in the storage circuitry 114 of the client in order to generate local data. Sometime later, the server goes back online at step 230. When this is detected, the accumulated local data is sent from the client 104 to the server 106 at step 224. In this example, the local data is set together with a completion time (i.e. the time that step 222 occurred). In other examples, this information may form part of the local data. Then, at step 232, the local data is received by the server 106 and the requirements defined in the local rule set are checked. This step helps to provide security in that the client 104 cannot (in this example) merely attest that the rules were followed. The client also checks. In addition, the server 234 checks that the processing occurred within the validity time associated with the local rules 116 that were used. This latter step can be achieved using the completion time that was sent in step 224 to the server 106. Of course, this means that the client 104 is trusted to provide an accurate time stamp regarding when the processing at step 222 occurred. It is also necessary for the client to know which version of the locally hosted rules 116 were used on the client 104. This information can also be provided by the client but again means that the client is trusted to provide this information accurately. Another possibility is that backdating beyond the current date is not permitted. That is to say that the completion time is taken by the server to be ‘now’ regardless of what the client 104 reports. Thus, if the data has been processed in accordance with the offline rule set 124 currently stored at the server 106 then the offline processing is accepted. Otherwise, if a new version of the offline rules is in effect, then the processing is refused. In some examples, it may be possible to provide attestation that the processing was performed in the required manner at the required time. This can be achieved using trusted computing and encryption for instance and will be discussed in more detail below. If the offline processing has been completed in an acceptable manner (i.e. if the rules have been met), then a refund of the paid tax will be instructed, otherwise an error may be sent back to the client to indicate that the refund will not be paid. Although not illustrated in Figure 2B, it is also possible for further processing to be performed on the local data when the local data is received by the server 106 after it has been determined that the requirements of the local data have been met (e.g. at step 232). This might constitute processing that cannot or must not be performed at the client 104. Figure 3 shows a communication flow 300 that occurs during online processing when the input data is invalid. Although this flow relates to the online / live processing a very similar process occurs with the offline processing once the local data has been transmitted to the server 106. At step 302 the input data is obtained by the client 104. At steps 304 and 308, the data is processed through the interaction of the client 104 with the server 106. In this case, the input data is invalid - one of the active rules 126 is not met. Consequently at step 310 an error is generated, which is sent to the client 104. The error is then showed to the user 102 at step 306. In practice, one or more attempts may be made to resolve the error as the client 104 and server 106 interact with each other. Thus, the process shown in Figure 3 occurs when the error is terminal and cannot be resolved. Figure 4 shows an example of the local rules 400 that may be downloaded by the client 104 from the server 106. In this example, the local rules 400 contain the validity period 404 as well as the data validation rules 406 that dictate how the input data should be validated. In this example, the rules 406 require the requirement that the purchaser is in a visit period. This may be defined based on a travel visa belonging to the user and the date of the purchase lies between the dates indicated by the visa (a copy of which will need to be provided by the user). A further requirement is that their visit to the jurisdiction is at least 24 hours. Thus, a visit to a country of only 12 hours would be disallowed for purchasing. A further requirement is that the passport number is at least 1-9 characters. ICAO 9303 defines a standard for passport numbers, which indicates that they should be a string of up to 9 characters and thus, any supplied passport number with a different number of characters is likely to be invalid. Finally, in this example, the data validation rules 406 also requirement that the user is from outside Europe. In particular, Europe operates a single market in which even some visitors from foreign countries (within Europe) may not be entitled to tax free shopping. Thus, a requirement exists here to disallow tax free shopping from visitors that are from Europe. Obviously these rules 406 are merely examples. The data rules 406 may also include rules that explain how particular forms are to be filled in using the data provided by a user, as well as validation rules. Other forms of rule not shown here are also possible. For instance, the rules may allow only particular stores to operate, or for particular chains to operate. In some examples, the purchase may have to be made during defined business hours. For instance, a store that is open from 9am to 5pm may not be able to make tax free shopping transactions at 2am, since the store would be shut and this might be indicative of a fraudulent transaction being attempted. Data rules could also be conditional. For instance, the requirement that the visitor’s visit is only for 24 hours may only occur if the transaction is below a predefined limit thereby improving security. The rules may also consider particular categories of goods. For instance, a tax refund may only be allowable for a certain quantity of consumable good and / or a certain quantity of non-consumable good. It is also of course an implicit rule that the validity period is met. Where the local rules 400 - and specifically the data validation - cannot take place, an error can be provided to the user. In addition, the local rules 400 contain an encrypted package 402. This package 402 includes a digital signature of the validity period and the data validation rules and a signing key. The package 402 can be used with a trusted computing environment in order to provide attestation that the input data was received and processed at a particular time and that the supplied rules were met. In particular a trusted computing environment is one in which the memory and processing capability cannot be accessed by the user. In this example, it is assumed that the trusted computing environment has a decryption key to the encrypted package 402. Thus, the user cannot obtain the signature or the key, but this can be accessed by the trusted computing environment. Note that neither the data validation rules 406 nor the validity period 404 can be modified without detection because then the digital signature will not match and the process will fail. If, however, the validity period 404 and the data rules 406 have not been modified and if the requirements are met then the trusted computing environment can use the supplied key to sign or encrypt the local data. If the decryption key is held at the server, then it is possible to provide some degree of certainty that the rules 406 that were in effect on the client 104 were met at the time of signing. In some embodiments, even if the rules 124, 126 at the server 106 have changed, the local data could still be accepted provided that (i) the local data was generated while the local rules 406 held at the client were in effect; (ii) the local data meets the requirements of those rules; and (iii) some further time period has not elapsed. For instance, the local data could be allowable if it met the rules that were valid at the time (according to the validity period) provided no more than one month has passed since those rules expired. Note that in this situation, it is assumed that the trusted computing environment has access to some kind of secure clock or other mechanism of securely obtaining the real date / time (e.g. a signed timestamp from a timeserver). Examples of trusted computing environments include Arm’s TrustZone® technology as well as Intel’s Trusted Platform Module (TPM) technology. Note that in these examples, the local rules 400 contain the validity period 404, encrypted package 402, and the data validation rules 406. However, in other examples, the validity period 404 and encrypted package 402 may be included separately. Figure 5 shows a flowchart 500 that illustrates a method of handling the local data when it is received at a server 106 after an offline process has been performed by the client 104. At a step 502, the local data is received. For the avoidance of doubt, this includes the transaction data that is necessary for a tax refund process to be initiated. This might include information regarding the transaction amount, the identification of the user (e.g. a passport number), a refund option (or an account name / number or indication of an account name / number), and so on. It may also include what is termed ‘security data’, which is information used to confirm that the offline process was performed appropriately. This might include the aforementioned digital signature, a time at which the transaction data was received, a time at which the transaction data was processed, a location of the transaction and so on. The security data may be dependent on the particular implementation and may also depend on the transaction. For instance, a higher risk transaction might require more or ‘better’ security data. Of course, the terms ‘transaction data’ and ‘security data’ are artificial and merely presented here to give an idea of the nature of information that might be included. At a step 504, it is determined whether the validity period is met. This may be implicit - if for instance, the local data is to be received while the locally hosted rules 116 on the client are still valid. In other situations, such as where the local data can be accepted after the locally hosted rules 116 have expired (provided they were valid at the time of receipt by the client), an indication of which local rules 116 were used is provided by the client in the local data. Of course, if different sets of local rules 116 are provided for each client then it may be necessary to determine the client identifier in order to establish the specific set of local rules that were in force. If the validity period is not met, then the request fails and at step 514 a rejection process is executed. Otherwise the process proceeds to step 506. Step 506 illustrates an optional step in which the signing is performed at the client to confirm the date on which the data was received and processed. Here, if the local data is invalid (such as if the digital signature does not match or the data cannot be decrypted) then the process fails at step 514. Otherwise, at step 508, it is determined whether the local rules that should have been applied. That is to say that the client 104 may not be entirely trusted and the same checks that should have been performed by the client 104 are applied at the server 106. If the requirements are not met, then the process fails at step 514. Otherwise the process proceeds to step 510. At a step 510, a set of server rules are applied. In practice, the server rules comprise the difference between the local rules provided to the client 104 and the active rules 126. For instance, it might be desirable to reject requests from a particular merchant, but without that information being widely distributed. Such a rule can therefore be presented in the server rules. Such rules may of course not exist and as such step, step 510 is also optional. If there are server rules and the requirements are not met, then rejection occurs at step 514. Otherwise, acceptance occurs at step 512. Figure 6 shows an example of how transaction identifiers can be allocated in order to control the extent to which offline processing can be carried out by a client. In this example, each transaction that is carried out and processed offline for later transmission to a server 106 is allocated a transaction identifier from a list of transaction identifiers that are provided to the client in advance. If a client 104 no longer has any transaction identifiers then it is unable to do offline processing. In Figure 6, three different clients 104 A, 104B, 104C are shown, each of which transmits a request to an allocation server 600. In this case, whether or not a client’s request is fulfilled is dependent on how many unused identifiers remain for each client (a transaction identifier becoming ‘used’ when transmitted to the server 106 in local data). Specifically in this example, five unused identifiers are permitted before further requests will be refused. A first client 104A makes a request for one transaction identifier. In this case, the client has one unused identifier (1175), which is below the limit. The request is therefore successful and a response is provided back to the client that provides the newly allocated identifier (1184). A second client 104B makes a request for two transaction identifiers. In this case, the client already has five unused identifiers (1176, 1177, 1179, 1182, 1183) and so the request is refused. An allocation response is provided back to the user with a null indicator of the identifiers. A third client 104C makes a request for one transaction identifier. In this case the client has one used identifier (1180) and two unused identifiers (1178, 1181). This is below the limit of five unused identifiers and so the request is permitted. A response is therefore provided specifying a newly allocated identifier (1185). Of course, it is possible for each client to have different limits as to how many transaction identifiers can be held. There may be limits for both identifiers and unused identifiers. The number of identifiers permitted may correspond with an amount of trust extended to a client, together with the number of transactions that might be expected for the client to use in the period for which the client is permitted to remain offline. Note that these allocations may not be used for online / active transactions, which may be provided for a different pool of identifiers. Figure 7 is of a flowchart 700 that shows an example of the allocation process in more detail. At a step 702, a request for allocations is received from a client 104 at the allocation server 600. At a step 704, if the number of unused identifiers allocated to the client is greater than or equal to a threshold, then the request is rejected at step 706. Otherwise the request is accepted at step 708. This causes the identifier to be allocated to the client (e.g. by updating an allocation table 602 that matches transaction identifiers to clients), the entry is marked as unused, and then the identifier is returned to the client 104. This is repeated for each requested identifier - multiple allocated identifiers can be returned in a single transmission and in some cases the transmission may be able to indicate a range of identifiers that are allocated. The above description therefore illustrates how offline processing of a normally online process can be performed (at least partly) offline while maintaining security In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of 5 hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. 10 Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. 15 For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. A client apparatus comprising:input circuitry configured to receive input data;storage circuitry configured to store one or more locally hosted rules in association with a validity period; andprocessing circuitry configured to attempt to cause the input data to be processed using one or more remotely hosted rules to produce a first result and to cause the first result to be provided to a first remote server, whereinin response to one or more locally hosted rule conditions being met, the processing circuitry is configured to process the input data using the one or more locally hosted rules to produce a second result and to buffer the second result;the one or more locally hosted rule conditions comprise a first condition that at least one of the remotely hosted rules and the first remote server cannot be accessed by the client apparatus; andthe one or more locally hosted rule conditions comprise a second condition based on the validity period.

2. The client apparatus according to claim 1, whereinthe second condition requires that a current time is within the validity period.

3. The client apparatus according to claim 1, whereinin response to one or more locally hosted rule conditions being met, the processing circuitry is configured to buffer the second result until the second remote server becomes available, at which point the processing circuitry is configured to provide the second result to the second remote server.

4. The client apparatus according to any preceding claim, comprising:retrieval circuitry configured to retrieve the remotely hosted rules as the locally hosted rules.

5. The client apparatus according to claim 4, whereinthe retrieval circuitry is configured to retrieve the validity period.

6. The client apparatus according to claim 4, whereinthe retrieval circuitry is configured to determine the validity period based on a retrieval time of the remotely hosted rules and a predetermined limit.

7. The client apparatus according to any preceding claim, whereinthe validity period comprises a validity start time.

8. The client apparatus according to any preceding claim, whereinthe input data relates to a transaction; and the one or more locally hosted rule conditions comprise a third condition that an amount of the transaction is less than a predetermined amount.

9. The client apparatus according to any preceding claim, whereinthe one or more locally hosted rules are used to prepare the input data for a tax refund request.

10. The client apparatus according to any preceding claim, whereinthe one or more locally hosted rule conditions comprise a fourth condition that a location of the client apparatus is one or more allowed locations.

11. The client apparatus according to any preceding claim, whereinthe one or more locally hosted rule conditions comprise a fifth condition that an identity of an owner of the client apparatus is one or more allowed entities.

12. The client apparatus according to any preceding claim, whereinthe storage circuitry is configured to store an asymmetric key in association with the one or more rules; andthe processing circuitry is configured to encrypt or digitally sign the second result using the asymmetric key.

13. The client apparatus according to any preceding claim, whereinthe storage circuitry is configured to store one or more stored unique identifiers, each to identify a set of the input data that is processed together by the processing circuitry and that is provided with the input data.

14. The client apparatus according to claim 13, whereinthe processing circuitry is configured to transmit a request to a third remote server for the third remote server to provide the one or more stored unique identifiers; andthe request comprises a client identifier.

15. The client apparatus according to any one of claims 13-14, whereinin response to the one or more locally hosted rule conditions being met, the processing circuitry is configured to assign one of the one or more stored unique identifiers to the set of the input data that is processed together.

16. The client apparatus according to any one of claims 13-15, whereinin response to the at least one of the remotely hosted rules and the first remote server being accessible by the client apparatus, the processing circuitry is configured to retrieve a remote unique identifier to assign to the set of the input data that is processed together.

17. A method comprising:receiving input data;storing one or more locally hosted rules in association with a validity period;causing the input data to be processed using one or more remotely hosted rules to produce a first result; anduploading the first result to a first remote server, whereinin response to one or more locally hosted rule conditions being met, the input data is processed using the one or more locally hosted rules to produce a second result and the second result is buffered;the one or more locally hosted rule conditions comprise a first condition that at least one of the remotely hosted rules and the first remote server cannot be accessed by the client apparatus; andthe one or more locally hosted rule conditions comprise a second condition based on the validity period.

18. A server apparatus, comprising:receive circuitry configured to receive live data from a client apparatus, wherein the live data is based on data received from a user of the client apparatus;processing circuitry configured to determine a validity of the live data using an active rule set, and to return a result to the client apparatus; andstorage circuitry configured to store an offline rule set in association with a validity period, whereinthe receive circuitry is configured to also receive offline processed data from the client apparatus, wherein the offline processed data is based on the data received from the user of the client apparatus; andthe processing circuitry is configured to determine whether the offline processed data meets the requirements of the offline rule set and whether the offline processed data was processed by the client apparatus within the validity period.

19. The server apparatus according to claim 18, comprising:transmit circuitry configured to transmit the offline rule set and the validity period to the client apparatus.

20. The server apparatus according to any one of claims 18-19, whereinthe processing circuitry is configured to determine whether the offline processed data was processed by the client apparatus within the validity periodbased on whether the receive circuitry receives of the offline processed data from the client apparatus within the validity period.

21. The server apparatus according to any one of claims 18-20, whereinthe processing circuitry is configured to determine whether the offline processed data was processed by the client apparatus within the validity period based on either decrypting or successfully matching a signature using an asymmetric key associated with the validity period.

22. The server apparatus according to any one of claims 18-21, whereinthe storage circuitry is configured to store a plurality of identifiers; and the receive circuitry is configured to receive an association request from a client apparatus and in response to the association request, to associate one of the identifiers with the client apparatus and to transmit the one of the identifiers to the client apparatus, in dependence on one or more association rule conditions.

23. The server apparatus according to claim 22, whereinthe one or more association rule conditions comprises a first condition based on a number of the identifiers associated with the client apparatus.

24. The server apparatus according to any one of claims 22-23, whereinthe offline processed data comprises one of the identifiers that is allocated to the client device;in response to receiving the offline processed data, the one of the identifiers is marked as being used; andthe one or more association rule conditions comprise a second condition based on a number of the identifiers unmarked as being used.

25. The server apparatus according to any one of claims 18-24, whereinin response to the processing circuitry determining that the offline processed data meets the requirements of the offline rule set, the processing circuitry is configured to initiate a tax refund request.

26. A method comprising:receiving live data from a client apparatus, wherein the live data is based on data received from a user of the client apparatus;5 determining a validity of the live data using an active rule set;returning a result to the client apparatus;storing an offline rule set in association with a validity period;receiving offline processed data from the client apparatus; anddetermining whether the offline processed data meets the requirements10 of the offline rule set and whether the offline processed data was processed bythe client apparatus within the validity period.

Images