GB2525234A

GB2525234A - Controlling user access in a mobile device

Info

Publication number: GB2525234A
Application number: GB1406934.8A
Authority: GB
Inventors: Andrew Deeley
Original assignee: DUNRAVEN FINANCE Ltd
Current assignee: DUNRAVEN FINANCE Ltd
Priority date: 2014-04-17
Filing date: 2014-04-17
Publication date: 2015-10-21
Also published as: GB201406934D0

Abstract

The permission controller (PCU) 21 is provided by a hardware component functionally separate from the CPU in a portable electronic device (fig. 2), e.g. a mobile phone or tablet computer. The PCU allows user access to functions, such as storage, wireless communication, audio or data input/output based on encrypted permission data received from an external central server (4, fig. 3) or the absence of such receipt. The permission data is generated from user data sent to the server. The PCU controls supply of power, preferably from a battery or transformer, to the functional units of the device, preferably independently of any function of the CPU. Access to a devices functions can be restricted if bad debt is incurred in connection with a hire-purchase (rent-to-own) device. The operating systems of such devices are often easy to alter (to root or jailbreak) in comparison with software/ middleware/ firmware solutions embedded in the device itself and sometimes used in larger consumer devices such as televisions.

Description

CONTROLLING USER ACCESS IN A MOBILE DEVICE

The present invention relates to a controlling user access in a mobile device.

BACKGROUND OF THE INVENTION

Renting or renting with an option to own (known as hire purchase or rent-to-own in some parts of the world) high price products can be the only way that many lower income and credit-constrained households around the world can obtain products that they need or desire. Typically, rental companies and companies that provide specialist credit and hire purchase facilities to consumers to obtain products have many disjointed systems, some automated, some not to manage their customer repayments. A risk associated with renting products is the potential bad debts that companies will experience due to the write off of goods as a result of people absconding or refusing to pay for the goods.

GB2498763 describes a system, method and device for controlling access to large consumer devices, such as televisions. In such a system, the consumer device includes a permission control unit (PCU), which resides in software embedded within the firmware of the device being controlled. The nature of large consumer devices is such that the firmware, which can operate at a device level for the hardware and in a middleware layer for operation of other functionality, is not readily accessible and upgradeable to by the consumer. In fact, it is possible to prevent upgrades to the firmware from any server other than an approved server, using secure encryption and authentication techniques.

Such approaches are difficult to implement on a mobile phone or tablet device because the operating systems are generally relatively straightforward to alter (to "root" or "jailbreak").

Accordingly, it is desirable to provide a portable electronic device which enables the control of user access to functions of that device, in a manner that is not easily avoided.

SUMMARY OF THE PRESENT INVENTION

According to an example, there is provided a secure hardware and software platform to limit the risk of bad debts relating to rented portable electronic equipment by providing companies the means to control the payment behavior of their customers using a real time pay as you use system. The system allows a customer access to the device in question assuming that payments have been made, can track the device if a customer absconds with the device and can limit the functions of the device in situations where a customer is unable to make a full payment or when the customer's payment falls into arrears but they make an acceptable commitment to pay.

A platform according to an example provides an end-to-end solution between a portable electronic device, a payment system used to collect payment from the customer and a control system used to manage device permissions. The control system is able to unlock, limit or lock the product in question or put a trace on the product should the customer abscond with the product, for

example.

According to one aspect of the present invention, there is provided a portable electronic device comprising a central processing unit provided by an integrated circuit and operable to transfer user data relating to the device to a central server external to the device, a plurality of functional units, an electrical power supply, and a permission controller provided by an integrated circuit functionally and operationally separate from the central processing unit, wherein the permission controller is operable to receive, from a central server external to the device, encrypted permission data generated from such user data, and to restrict user access to one or more functions of the device in dependence upon such received permission data, or to restrict user access to one or more functions of the device in the absence of receipt of such permission data, or to control supply of electrical power to the functional units of the device in dependence upon such received permission data.

The plurality of functional units may include a display screen, a user input device, an audio input and output device, a data input and output device, a data storage device, and/or a wireless telecommunication device.

The permission controller may be operable to restrict access to preselected parts of particular functions of the device.

The permission controller may be further operable to compare contents of a data storage area associated with the central processing unit with expected contents thereof, and to exert such control to the functions of the device in dependence upon the result of such comparison in combination with such received permission data.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which: Figure 1 is a schematic block diagram of a system according to an example; Figure 2 is a schematic block diagram of a device according to an example; and Figure 3 is a schematic block diagram of a system according to an example.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system embodying one aspect of the present invention for use with a portable electronic device is illustrated in overview in Figure 1. The system 1 includes portable device hardware 2, portable device software 3 and a central server 4.

The hardware 2 includes a permission controller 21, the software 3 includes a permission control module 31, and the server 4 incudes a central controller 41.

The module 31 operates to control the hardware 21 via internal communications links 5. The module 31 communicates with the central controller 41 of the server 4 via an Internet connection 6, such as that provided by the portable device being controlled.

The system 1 of Figure 1 thereby provides a permission control system for a portable electronic device, which system resides in the permission control module 31 and in the permission controller 21. The portable electronic device will only function properly if the permission controller 21 is able to detect that specific elements of the permission control module 31 are functioning as intended.

This gives two levels of permission control security. Firstly, the module 31 controls access to the device device such that the customer must first interact with the central server 4, through a user interface, either to pay or to make a promise to pay. Secondly] in the event that the consumer hacks the module 31 or replaces the device's operating system entirely, then the permission controller 21 operates to intervene to prevent or restrict access to the portable device.

Figure 2 illustrates one example of the device hardware 2 of Figure 1 in more detail. The hardware 2 includes the permission controller 21 as described. The hardware 2 also includes a power button 22, a power controller 23, a battery 24, a communications device 25 (such as a modem), a main device processor 26, and other components 27 (such as a display screen, microphone, loudspeaker, camera or storage device). In overview, the permission controller 21 is operable to control supply of power from the battery 24 to the other components of the device. In the example shown in Figure 2, the battery is able to supply power to the modem 25 directly so that communications can be maintained with the central controller 41 of the server 4. The permission controller 21 receives control information from the power button 21, and from the main device processor 26, and operates to control the power controller 23.

The power controller 23 is operable to switch the power on and off to the various components of the device. For example, the power controller 23 may be instructed by the permission controller to prevent power being supplied to the display screen, storage device, or camera of the device.

The permission controller 21 also interfaces with the permission control module 31 of the device software 3. The permission controller 21 receives codes from the permission control module 31 that it can decrypt, authenticate, interpret and action accordingly. Multiple codes can be sent at once for the permission controller 21 to action.

The permission control module 31 itself will not have access to the originating algorithms for the transmitted control codes, it will simply pass the code given it by the central server 4, (whether via an Internet connection or a manually entered encrypted key entered by the consumer if there is no Internet connection) straight through to the permission controller 21.

The codes will be encrypted on the central server 4 using a public and private key, so the permission controller 21 will only action codes that have been sent to it by the central server 4.

The pad of the encryption algorithm will rely on unique ID codes specific to the device/customer and date and time calculations; these codes will only be valid for a configurable period of time. This means that the permission controller 21 has access to a date and time clock.

It may be possible to use a date and time clock of the portable device but a clock dedicated to the permission controller 21 that can be synchronised to the central server 4 using an encrypted code designed to keep both clocks in sync This approach means that only the permission controller 21, having firmware that is not accessible outside of the system, and the central server 4 will be the only two systems that have access to the software that develops the codes and then interprets them on the device.

The codes received by the permission controller 21 are then processed and from this the device will either run unrestricted or the permission controller 21 will apply restrictions by preventing power reaching some or all components.

Restrictions applied by the permission controller 21 may be delayed or timed on start-up on the device. This might be to allow the consumer to unlock a device by returning it to an approved state.

A more complex example of the permission controller 21 is able to interrogate the memory of the device that holds the device operating system, which itself incorporates the permission control module 31 elements. In that case, the permission controller 21 will be able calculate a checksum against the binary codes that make up the device's approved operating system. If the checksum does not validate against the checksum that the permission controller 21 is expecting, then the permission controller 21 will apply restrictions The central server 4 would need to be able to provide the permission controller 21 with encrypted checksums that are valid and the permission controller 21 would need to be able to store a list of acceptable checksums that it can validate against. This could be stored in onboard memory within the permission controller 21, but it is possible that it could use external memory elsewhere within the device that is only available to the permission controller 21.

Allowing the server 4 to provide multiple valid checksums enables there to be more than one version of permission control module 31 to be valid at the same time on a single device.

Even when the permission controller 21 has restricted user access to components on the device, it is necessary for the permission controller 21 to receive a code from central server 4, via the permission control module 31 to alter its state. Therefore the permission controller 21 will periodically allow the device to boot in order to receive and process instructions. This may be achieved by allowing the device to be operable for a predefined amount of time.

If in this time no new codes are received then the permission controller 21 will restrict functionality of the device again.

Figure 3 illustrates functional elements of the system of Figure in more detail.

The device software 3 includes the permission control module 31 described above, and also includes a payment module 32, a promise-to-pay module 33, and a restrictions module 34. Each of these modules 32, 33 and 34 provide the permission control module with specific functions.

The central server 4 includes the central controller 41, and also includes a customer payment module 42, an arrears management module 43 and a customer records module 44.

A payment gateway 7, which includes a payment approval module 71, may be provided as part of the system, or may be provided by a third party system.

The permission control module 31 interfaces with the central controller 41 using a suitable communications method. Specific operations will be described below, but, in general terms, the permission control module operates to provide the permission controller 21 of the hardware 2 with suitable control inputs. The control module 31 controls the payment module 32 in order to collect and process payments through the payment gateway directly from the device itself A payment record is then sent from the gateway 7 to the central controller 41, via the customer payments module 42, for processing. The payment record is stored in the customer records module 44. If the payment record indicates that a successful payment has been made, then the central controller 41 instructs the permission control module of the device accordingly.

The arrears management module 43 operates to provide the central controller 41 and hence the permission control module 31 with information regarding any arrears for the customer concerned.

The promise-to-pay module 33 operates to determine form the customer when an appropriate payment schedule has been put in place, and provides the permission control module with appropriate information.

The restrictions controller 34 operates to control access to the functions and components of the device in dependence upon control information provided by the permission control module 31. The module 31 restricts access to the various functions of the device, including but no limited to such elements as access to apps, Internet, music and non-emergency phone functions. The permission control module 31 also serves to provide an interface between the customer and the central server 4.

Access may be denied temporarily until the customer carries out an action required to regain access. The types of actions will include: 1) Making a full payment for arrears outstanding 2) Making a part payment for arrears outstanding and providing a promise to pay date 3) Making no payment but providing a promise to pay date 4) Making a new arranged payment schedule that will replace the contractual repayment schedule for a period of X weeks/months To aid the efficient handling of these interactions with customers the permission control module 31 allows the customer to carry out these actions using the device, making use of the payment control module 32 and the promise-to-pay module 33. This saves significant amount of human systems and time in trying to contact customers to make these arrangements. The permission control module 31 is able to restrict access to the functions of the device until the customer opts for one of the self-serve options to unlock the device.

This leaves the customer service able to focus on the more complex customer situations. Typically action 4 above would be carried out via a conversation with a member of staff, however it is possible that more simple arranged payment schedules might be offered certain customers as a simple button on the device to press. For example, a simple arranged payment schedule to pay an extra £2 for 4 installments could be offered as a one-click option for the customer to accept without having to speak to a member of staff.

The permission control module 31 is in regular contact with the central controller 41 in order to receive both instructions for the permission control module 31 to carry out and encrypted codes for the permission controller 21 to decrypt and process.

Several examples of how the system described above works in different scenarios will now be described.

Case 1 -Customer makes payments on time and is not in arrears with their repayments The device connects to the central server 4 at predefined intervals; a permission file is downloaded from the central server 4. The permission file contains instructions for the permission control module telling the permission control module 31 to allow device to run unrestricted until a future date or time.

It may also contain configuration parameters for the permission control module 31 to apply that effects the way the permission control module 31 functions.

The file also contains an encrypted code that the permission control module 31 will pass to the permission controller 21. The permission control module 31 will simply pass this code untouched to the permission controller 21.

The permission controller 21 will decrypt and interpret the code, which in this use case will be proceed without any restrictions.

The permission controller 21 will also synchronise its date and time clock/counter with the central server 4 from one of the codes received.

Case 2 -Customer is in arrears but on an agreed repayment plan and they make these agreed payments on time In this example, the customer has fallen behind with their repayments but is keeping to an agreed payment schedule designed to get them out of arrears.

The central server 4, in this case, acts in accordance with Case 1 above but with the addition that the permission file may include instructions for the permission control module 31 to apply partial restrictions on the use of the device.

Partial restrictions may take the form of removing access to some of the features of the device, for example the camera or access to some or all apps etc..

Case 3 -Customer fails to make a payment In this case when the permission control module 31 next connects to the central server 4 the permission file received will tell the permission control module 31 to restrict access to the device and force the consumer to interact with the central server 4 to make a full payment to unlock the device, make a partial payment and a promise to pay the rest by a certain date or make a promise to pay the full amount at a later point in time.

The central server 4 will determine the exact parameters around what is an acceptable payment or promise to pay for a specific customer.

The permission control module 31 will restrict access to the device until they have carried out one of the permissible actions described above. At which point the device will reconnect with the central server and receive a new permission file that with have either all restrictions lifted or, in the case of partial payment and promise to pay, only have partial restrictions lifted.

Case 4 -Customer replaces the device software/operating system with an unapproved standard version In its simplest configuration the permission controller 21 will cease to receive periodic codes from the permission control module 31 (since that module will not be included in the newly loaded software) and will apply restrictions based on criteria coded into the permission controller 21. The permission controller 21 will remain in restricted mode until a correctly approved version of the operating system, containing the permission control module 31, is reinstalled on the device and it receives a valid code from the permission control module 31.

Case 5 -Customer hacks the device software in order to bypass the permission control functionality In order to maintain unrestricted access to the device, any hacker would need to be able to send acceptable codes to the permission controller 21 to fool it into accepting instructions to keep device unrestricted. Without knowing how the codes are encrypted and what the codes actually do, it would be almost impossible to do this on a trial and error basis.

If the permission controller 21 receives codes that it does not recognise it will go into restricted mode after a number of failed attempts.

As an extra security measure, the permission controller 21, in a more complex configuration, will run a checksum validation over the memory of the decice in which the device software resides. This checksum is compared with allowable checksums. If unapproved changes to the device software have been made, the device will fail this test and the permission controller 21 will go into restricted mode. This test would be run at startup and periodically to validate that the correct device software is in operation.

Case 6 -Customer tries to pass spoof codes to the permission controller 21 Only the central server 4 will be able to compile and encrypt a code for the permission controller 21 to decrypt and action.

The code however has to be passed to the permission controller 21 by the permission control module 31. This means that a hacker might try pushing data to the permission controller 21 to attempt to find a sequence of data bytes that might effect the operation of the permission controller 21.

In this instance the permission controller 21 will automatically drop into one of a number of lockdown states if a configurable number of failed attempts are made and remain in that state until it receives a valid code to unlock the device.

Case 7 -The customer's payments are paid on time and they are not on an arranged payment schedule If a customer's payment is received on time, then the permission control module 31 will allow full access to the device and all its features Case 8 -The customer's payment is missed and they opt to pay in full by card If the customer misses a payment, the permission control module 31 is instructed by central server 4 to restrict access to the device. The customer may then select the option to make a card payment.

They can select to do this on the device itself, which will then connect, via the payment controller 32, to the payment gateway 7 to conclude a transaction.

Alternatively, the customer can make the payment using a different device and make a payment through a payment page provided.

Once the central server 4 receives confirmation from the payment gateway 7 that a full transaction has been processed, the permission control module 31 is instructed to unlock the device.

Case 9 -The customer's payment is missed and they opt to pay in full using an alternative payment method If the customer misses a payment and choose to make a full payment at a store or other location, then the central server 4 instructs the permission control module 31 to unlock the device for a grace period of X minutes, to allow the customer time to go and make the payment using the chosen payment method, such as by telephone, or in person using a service such as PayPointTM.

If the customer does not pay within that grace period the device will be locked again and the customer may not receive any further grace period during the current period of being in arrears.

Case 10-The customer's payment is missed and they opt to make a partial payment If the device is locked down and the customer elects to make a partial payment then the permission control module 31 processes the payment using the payment module 32. The central server 4 receives information that a partial payment has been made, and then provides the permission control module 31 with a range of acceptable promise-to-pay dates for the customer to choose from.

The permission control module 31 will offer the customer a range of acceptable dates to choose when the balance of the payment will be made. Once selected the date will be passed to the central server 4, which will in turn establish which restrictions should be lifted and send the permission control module 31 instructions to fully or partially lift certain restrictions.

Case 11 -The customer's payment is missed and they opt to promise to pay at a later date If the customer cannot pay they might be offered an option to make a promise to pay. The central server 4 determines, by using customer behavioral algorithms, exactly what time period a customer will be offered when it comes to making a promise to pay. For some customers, they may only have an hour or two to make a payment, for others it could be a number of weeks.

In its simplest form the permission control module 31 displays a range of dates that the central server 4 calculate for the customer and the customer selects the most appropriate date. This date is passed back to the central server 4 and the restrictions are lifted accordingly. It is important to note restriction may only partially be lifted, the exact restrictions will be determined by the customer and how far in the future the promise to pay date is set for.

In a more complex form the date of payment and amount of payment are captured by the permission control module 31 and passed to the central server 4. If the amount of payment is less than the required amount the central server 4 may make suggestions for an arranged payment schedule and instruct the permission control module 31 to offer these suggestions to the customer. If the customer accepts the terms of this new temporary arranged payment schedule the central server 4 will instruct the permission control module 31 to remove some or all of the restrictions.

Claims

CLAIMS: 1. A portable electronic device comprising: a central processing unit provided by an integrated circuit and operable to transfer user data relating to the device to a central server external to the device, a plurality of functional units; an electrical power supply; and a permission controller provided by an integrated circuit functionally and operationally separate from the central processing unit, wherein the permission controller is operable to receive, from a central server external to the device, encrypted permission data generated from such user data, and to restrict user access to one or more functions of the device in dependence upon such received permission data, or to restrict user access to one or more functions of the device in the absence of receipt of such permission data, or to control supply of electrical power to the functional units of the device in dependence upon such received permission data.
2. A device as claimed in claim 1, wherein the electrical power supply is a battery and/or electrical transformer.
3. A device as claimed in any one of the preceding claims, wherein the plurality of functional units include a display screen, a user input device, an audio input and output device, a data input and output device, a data storage device, and/or a wireless telecommunication device.
4. A device as claimed in any one of the preceding claims, wherein the permission controller is operable to restrict access to preselected pads of particular functions of the device.
5. A device as claimed in any one of the preceding claims, wherein the permission controller is further operable to compare contents of a data storage area associated with the central processing unit with expected contents thereof, and to exert such control to the functions of the device in dependence upon the result of such comparison in combination with such received permission data.