BR102021000725A2 - METHOD AND SYSTEM FOR REMOTE MANAGEMENT OF APPLIANCE ACCESS - Google Patents

Abstract

METHOD AND SYSTEM FOR REMOTE MANAGEMENT OF APPLIANCE ACCESS. The settings described herein include methods and systems for remote device management, which includes enabling communication between the device user and third-party systems. Third-party systems can include any entity that has a relationship with the device user, such as the payments infrastructure that monitors progressive payments for the device and manages access to the device as a result of payments. In some configurations, the device being controlled is a smartphone that also includes third-party operating system software. Various methods to prevent the change or replacement of the third party operating system were also presented.

Description

METHOD AND SYSTEM FOR REMOTE MANAGEMENT OF APPLIANCE ACCESS HISTORIC

[0001] User devices, such as consumer electronics and home appliances, are often sold as a one-time, cash purchase. A television, for example, can be sold in a retail store for $200 to the consumer, who then owns the television and takes it home. However, some people might prefer to pay for the device over a period of time, for example with monthly payments of $20, either with a limited number of payments or for as long as the device is in use.

[0002] There are several systems that help sellers continue to receive payments after the buyer has brought home the television (or other device or appliance). In an earlier system, multiple hardware units need to be connected to the device (or multiple devices), including a device control unit and another unit for managing usage (eg, receiving and monitoring payments). Other systems use a mobile communication network that facilitates the verification of electronic payments. However, these systems also require the device to have a mobile communication capability in order for it to be controlled.

[0003] It would be preferable to have a method and system for remote device management that is easy and cost-effective to implement and that helps to ensure that payments due are made to the seller of the devices on time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 is a block diagram of a remote device management system, according to a configuration;

[0005] Figure 2 is a block diagram of a remote device management system, according to a configuration;

[0006] Figure 3 is a flowchart of a remote device management system, according to a configuration;

[0007] Figure 4 is a block diagram of a system in which the device is being controlled, better illustrating the method to prevent tampering with the control software on the mobile device;

[0008] Figure 5 is a block diagram of a system in which the device is being controlled, better illustrating the method to prevent tampering with the control software on the mobile device;

[0009] Figure 6 is a block diagram of a system in which the device is being controlled, better illustrating the method to prevent tampering with the control software on the mobile device;

[0010] Figure 7 is a block diagram of a system in which the device is being controlled, better illustrating the method to prevent tampering with the control software on the mobile device;

[0011] Figure 8 is a block diagram of a system in which the device is being controlled, better illustrating the method to prevent tampering with the control software on the mobile device;

[0012] Figure 9 is a block diagram that illustrates a configuration that enables financing for smartphone users;

[0013] Figure 10 is a screenshot illustrating the features of a configuration;

[0014] Figure 11 is a screenshot illustrating the features of a configuration;

[0015] Figure 12 is a screenshot illustrating the features of a configuration;

[0016] Figure 13 is a screenshot illustrating the features of a configuration;

[0017] Figure 14 is a screenshot illustrating the features of a configuration;

[0018] Figure 15 is a screenshot illustrating the features of a configuration; and

[0019] Figure 16 is a screenshot illustrating the features of a configuration.

DETAILED DESCRIPTION

[0020] The configurations described in this document include a system that performs a device or appliance management method. In this document, “device” means any electronic device that can normally be purchased by a user. Appliances include, among others: television, refrigerator, freezer, washing machine, dishwasher, electric oven, microwave, blender, food processor, air conditioning, stereo sound system, photo camera, camcorder, smartphone, notebook, desktop computer, tablet, printer, DVD player, video projector, motorcycle, automobile or plane.

[0021] For the purposes of describing the claimed settings, an example of controlling, activating or deactivating a device based on whether scheduled payments are made or not will be presented. However, this is just one example of the need for a third party (such as a payment entity that manages accounts on behalf of the device vendor) to easily and remotely control the user's access to the device or even the way of use.

[0022] The configurations of the invention allow a user to own and make use of a device or device while a third party can control the use of that device or device. This includes the possibility for the third party to determine when the device can be turned on or when it cannot be turned on. This also includes the possibility for the third party to determine how the device can be used, for example which channels can be picked up by a television or how much energy a generator can produce.

[0023] Figure 1 is a block diagram of a system configuration for remote management of access to user devices. The device 104 is activated or deactivated by an AMS device management subsystem (101). In one of the configurations, the AMS is a hardware subsystem built into the device, such as a microcontroller or any other type of integrated circuit (IC). In this configuration, the AMS (101) can be integrated into the instrument core, so that the embedded system cannot be removed without disabling the instrument. When AMS (101) determines that the customer has made the payment, it activates the device for normal use. In other configurations, the AMS (101) is connected after the device is manufactured and not incorporated. However, removal of the AMS (101) can be detected and causes the device to shut down.

[0024] In this configuration, the embedded system does not have a communication function of its own, except a standard USB input (105), through which it can be connected to a device (106) with Internet connection by a USB cable (107 ). In other configurations, various known communication modes for data sharing are within the scope of the invention. In one embodiment, the device (106) is a smartphone running a software application (app) (102), which enables the device (106) to communicate with the AMS (101) in accordance with the methods described. In other configurations, the device with an Internet connection is a notebook, desktop computer, tablet, PDA, or other such device.

[0025] According to the configuration, the device (106) is a smartphone that behaves like a USB storage device. In this case, both the software app (102) and the embedded system can communicate by reading and writing files on the USB storage device. When operating, the AMS (101) communicates a device identification (e.g. serial number) (114) to the software app (102). When the software app (102) determines that payment for the identified device has been made, the app (102) delivers a digital payment receipt (109) with a digital signature (110) to the AMS (101) and the AMS (101) ) activates the device.

[0026] In one of the configurations, the software app (102) communicates using a smartphone communication system, which may use Wi-Fi 802.11 to communicate with the Wi-Fi access point (111) or may use a GSM mobile data network, such as 4G LTE, 3G or 2G EDGE, to communicate with a cell phone carrier's signal tower. Whether over Wi-Fi or mobile data, the smartphone transmits data over the Internet to a third-party infrastructure (103), which includes at least one remote device management server (RDMS) ( 122) that performs the methods described here. The third party infrastructure (103) further includes storage devices (120) to store current data and historical data related to various devices under remote control, as well as the customer's personal and financial data.

[0027] The third party infrastructure (103) can be any Internet-based system with which the user or customer (113) establishes a relationship for the purpose of establishing control of the device (104) through wireless communication of the infrastructure third party (103) with the device (106) and of the device (106) with the AMS (101). Servers (122) and data storage devices (120) are displayed as isolated entities in a discrete location. In reality, servers (122) and storage devices (120) represent various servers and storage devices that can be distributed throughout the network in any way. The servers (122) include several processors that perform the methods described in this document. In this presentation, the 3rd party infrastructure is described as a payments infrastructure and the control of the device is based on the customer's payment status (113), which is transmitted from the 3rd party infrastructure (103) to the user's device (106) and then to the AMS (101). However, the basis of the relationship between the user or customer (113) and the third-party infrastructure and the events or motives that control the device may not be related to payments. For example, the system can be used by parents to control various devices used by children. However, for purposes of illustration, the third party infrastructure (103) will be considered a payments infrastructure in this document.

[0028] In the configuration, the third party infrastructure (103) is a software service that runs on servers. It monitors when the payment for a specific device is made, in addition to controlling the device. The payments infrastructure (103) communicates with the payment provider (112), which receives cash or electronic payments (115) from customers (113). For example, the payment provider could be PayPal, a company that manages electronic payments, a mobile money service such as M-Pesa, or a bank, or Western Union, which allows customers to make cash deposits at a physical location and have the amount credited to an electronic account. The payment method is not considered a new or limiting aspect of the settings. Instead, it is the payment event that causes the system to perform the remote management method, including activating or deactivating the device (104).

[0029] Figure 2 is a block diagram of a configuration where the device (106) is also the apparatus (104). For example, the device (106) may be a smartphone remotely controlled using the software app (102) in a similar manner as described for Figure 1. However, the software/hardware/firmware of the device itself (106/104) is used to enable or disable the device (106/104). Essentially, AMS is software added to the device's operating system (106) or even the operating system itself. Again, when payments (115) are made by a user (113) and accepted by the payments infrastructure (103), the payments infrastructure (103) delivers a digital payment receipt (109) with a digital signature (110) to the app (102), which verifies this receipt and controls the device (106/104) depending on the payment.

[0030] Figure 3 is a flowchart illustrating a method (300) of remotely managing devices in accordance with a configuration such as Figure 1. At 302, the user or customer purchases a device from a supplier. At 304, the customer downloads the device management app (102) to its device (106). In 306, the customer uses the app to register an account online with the payment infrastructure (103). At 308, the AMS subsystem transmits an ID and account information to the device user (106) (via USB cable in one of the configurations) and the device transmits the information to the payments infrastructure.

[0031] In 310, the app determines if the predefined period has passed without the customer making further payments (after the initial payment at the time of purchase of the device). As an example, the period could be one month. If the time has not yet passed, the process continues to check the period deadline. If the period has passed, and there have been no new payments, AMS causes the device to be deactivated (312). Upon deactivation, the device cannot be used or some preset features of the device cannot be used. Disabling may turn off the device or disable preset features.

[0032] In 314, at the time the payment is made to the payment infrastructure, if this occurs, a digital receipt will be created with the ID information and a digital signature. The app receives the digital receipt by remote transmission (over-the-air) at 316. At 318, the digital receipt is delivered to AMS via the USB cable. As described above, the use of a USB cable is not required to run the new invention. Other methods are within the scope of the invention to enable communication with other elements of the system. At 320, AMS attempts to verify the digital receipt and determines (at 322) whether the verification was performed correctly. If verification is not possible, the nature of the error will be determined and an error message will be sent to the app at 324.

[0033] If the digital receipt verification is performed correctly, the AMS will activate the device at 326. Upon activation, any feature or function that was deactivated at 312 will be reactivated. Then the process goes back to 310 to wait for the next period's deadline.

[0034] In other configurations, it is possible to set a period of less or more than one month. In other configurations, the device (106) can communicate with the AMS via Bluetooth, Wi-Fi, DTMF sounds, light modulation, 2D or 3D bar code. The AMS (101) may include standard hardware, originally installed on the instrument, but with custom firmware (software running on an integrated microprocessor).

[0035] The settings also include various user interfaces presented through a smartphone or any device connected to the Internet. The user interface can provide complete information related to the customer's account, such as the time remaining before the device is deactivated. Additionally, any information about the customer's financial account will be available to the customer. This includes an overview of various devices that have been funded according to the described configurations. It also includes a single online point through which customers can manage their accounts and control their devices (eg turn devices on and off).

[0036] Figures 4-8 are block diagrams that illustrate the device management system configurations. In the configurations of Figures 4-8, the device being controlled is a smartphone that also includes control software (such as app 102). Methods to prevent tampering with control software are also illustrated. First, with reference to Figure 4, a device management system (400) includes devices 406A and 406B, which are smartphones that can be configured in a variety of ways as described below. A boot loader (or bootloader program) is a computer software component that runs at the beginning of the activation process. An example is the BIOS (integrated operating system) on a PC. Smartphones have analog systems. In some configurations, the software app (102) is part of an operating system (OS) (416) that operates a device (406). The OS (416) is installed on a device (406) via a bootloader “flash” mechanism (via the bootloader UI mode), which allows the user to customize the OS or install a new OS. new OS. As part of the OS installation (416), the bootloader is “locked” to prevent “re-flashing”, which could be used to uninstall the OS (416).

[0037] As described in more detail below, the various methods to lock the bootloader include:
altering the bootloader's binary code to prevent it from receiving or validating new software packages;
altering operating system files to make them unrecognizable to the boot loader while retaining functionality for the user;
change storage system drivers so the boot loader cannot write new data files;
modify the memory addresses for the storage system of the memory chip built into the device so that the bootloader write operations have no effect on the device; and
in cases where a bootloader program supports a “lock” command, enable the built-in lock and also disable the bootloader “lock” command via one of the following options: change the calling method software function of the “unlock” command, so that it cannot be activated when called by the original method, or change the encrypted keys or add new encrypted keys required by the “unlock” command.

[0038] Still referring to Figure 4, devices 406A and 406B are smartphones that try to open the bootloader UI mode (408) using different methods.

[0039] Boot loader UI mode (408) is the mode in which the operating system or other software can be installed on the device. It is also possible to change operating system software or other software in this mode.

[0040] The 406A smartphone features a pattern or combination of hardware keys (or buttons) that, when pressed simultaneously, allow the user to access the bootloader UI mode (408). The 406B smartphone features an alternate method for accessing the bootloader UI mode (408). As shown in 406B, a USB cable is connected to the 406B device and a computer, allowing you to upload files to the 406B device and change the 406B device and firmware settings.

[0041] Various device software and hardware components (409) can be accessed by the device (406) when it enters bootloader UI mode (408). Components (409) include hardware drivers (412) and a device driver (414), with an associated address scheme (415). Components (409) also include an operating system (OS) and an encrypted key used to control access to the OS. The encrypted key (411) is located in the firmware (411) of the device (406). Another encrypted key (411) is embedded in the third party OS file (416). These keys need to match so that a new OS can be installed on the device (406).

[0042] In one of the configurations, the 3rd party OS (416) is loaded on the device (406) via the bootloader UI mode (408). In another configuration, the third party OS (416) includes, at a minimum, all executable resources of the software app (102), as described above. In many configurations, changing the OS (416) or its resources is prevented by various methods.

[0043] As shown in Figure 4, access to bootloader UI mode (408) is disabled. In one of the configurations, the bootloader's binary code is changed to prevent it from receiving or validating new software packages.

[0044] Figure 5 is a block diagram of a system (500) illustrating a situation where the device being controlled is a smartphone, which also includes the control software/hardware. The 406A and 406B devices are smartphones that open the bootloader UI mode (408) using different methods.

[0045] Boot loader UI mode (408) is the mode in which the operating system or other software can be installed on the device. It is also possible to change operating system software or other software in this mode.

[0046] The 406A smartphone features a pattern or combination of hardware keys (or buttons) that, when pressed simultaneously, allow the user to access the bootloader UI mode (408). The 406B smartphone features an alternate method for accessing the bootloader UI mode (408). As shown in 406B, a USB cable is connected to the 406B device and a computer, allowing you to upload files to the 406B device and change the 406B device and firmware settings.

[0047] Various software and hardware components (409) of devices (406) can be accessed when the device enters bootloader UI mode (408). Components (409) include hardware drivers (412) and a device driver (414), with an associated address scheme (415). Components (409) also include an operating system (OS) and an encrypted key used to control access to the OS. In one of the configurations, the third party OS (416) is loaded onto the device (406) via the bootloader UI mode (408). In another configuration, the third party OS (416) includes, at a minimum, all executable resources of the software app (102), as described above. In many configurations, changing the OS (416) or its resources is prevented by various methods. As shown in Figure 5, the bootloader UI mode (408) is accessed using the methods presented with respect to the 406A and 406B devices.

[0048] In cases where the bootloader software supports a “lock” command, an encrypted key (410) will be located in the device firmware (406). Another encrypted key (418) is embedded in an OS file. To prevent unwanted access to the third party OS (416), the device's encrypted key is changed to a new, unpublished encrypted key (410). It will not be possible to upload a changed OS file to a device (406) if someone tries to do so, because the new OS encrypted key (418) will not match the device's unpublished encryption key (410).

[0049] In other configurations where the bootloader software supports the “lock” command, the built-in lock is triggered and the bootloader “unlock” command is disabled, preventing it from executing a command call “ unlock.” In one of the configurations, this is done by changing the software function call method of the “unlock” command so that it fails to run when called by the original bootloader method.

[0050] Figure 6 is a block diagram of a system (600) illustrating another method to prevent changing the OS or OS functions of the device in a system similar to Figures 4, 5 and 7-8. When the boot loader receives a new OS file, it determines how to integrate the new OS file into the existing OS. This integration can happen by replacing some files or folders (417) in the device drive (414). To prevent this replacement, the third party OS (416) reconfigures the names of files and folders so that they do not match the names of files or folders that will be replaced by the unwanted “new” OS. Otherwise, the functionality of the device will be completely maintained. For example, as shown in 417, a “system” folder can be changed to a “test” folder.

[0051] Figure 7 is a block diagram of a system (700) illustrating another method to prevent changing the OS or OS functions of the device in a system similar to Figures 4-6 and 8. boot receives a new OS file, it determines how to integrate the new OS file into the existing OS. This integration can happen through the replacement of some files or folders in certain addresses of the raw (physical) disk in the device drive (414). To prevent this replacement, the third party OS (416) renumbers raw disk addresses so that they do not match the location(s) designated by an unwanted “new” OS. Otherwise, the functionality of the device will be completely maintained.

[0052] Figure 8 is a block diagram of a system (800) illustrating another method to prevent changing the OS or OS functions of the device in a system similar to Figures 4-7. One of the configurations contemplates a situation where the device user intends to gain read/write access to the device's drive (414) (eg, replace the OS (416)) by changing the device's hardware drivers (412). To prevent this, the device's hardware drivers (412) are modified to not allow control of the various hardware components of the device through the bootloader's UI mode (408). In this way, the user who wants to replace the OS (416) will not get read/write access to the device drive (414).

• (a) Financiamento do smartphone ou
• (b) Qualquer troca que exija garantia, de modo geral. Por exemplo, isso pode abranger a forma de empréstimo em que a opção de controle do dispositivo é garantia suficiente para o fornecedor do financiamento.

[0053] In other configurations, the remote device management system described in this document enables funding modes. In these configurations, the customer obtains credit by offering the smartphone as collateral for:

• (a) Smartphone financing or
• (b) Any exchange that requires warranty in general. For example, this may include a form of loan where the device control option is sufficient collateral for the financing provider.

[0054] A smartphone can become an “on-demand guarantee”, that is, it can be offered as a guarantee at any time the user (consumer, seller, other entity in control of the smartphone) wants. As a result, this enables a new type of technology-based lending business model. More specifically, the user can offer software control of their smartphone as a guarantee. Unlike traditional loans, where some kind of monetary or physical guarantee is required, the smartphone can be offered as collateral without having to actually give it up or prevent its use. Once the loan is fully paid off, the software does not need to exercise control of the device.

[0055] In effect, this makes it possible for lenders to reach new user groups. Lenders may take more risk to provide capital to users who would not be eligible for credit (as these users often do not have other high-value assets to offer as collateral). As a result, countless users could gain access to credits that they would not normally receive (since they would not be able to offer other acceptable forms of collateral).

• 1. Fazer o download de um App de Segurança a partir de uma app store pública, como a Google Play Store, ou diretamente de outro website, como payjoy.com. O usuário concorda em oferecer o smartphone como garantia e o app de segurança atualiza um Bloco de Dados de Controle para marcar o smartphone como seguro.
• 2. Adicionalmente, na inicialização do dispositivo, um app privilegiado verifica o servidor e, se o servidor especifica que o dispositivo deve ser controlado, o app privilegiado instalará o app de segurança automaticamente.

[0056] By way of example, the end user (“user”) generally initiates the transaction to offer the device as collateral. The user's consent to offer the device triggers different software components to “control the device”. The user can access the smartphone app UI (907) to start the process in one of the following ways. User can:

• 1. Download a Security App from a public app store, such as the Google Play Store, or directly from another website, such as payjoy.com. The user agrees to offer the smartphone as collateral and the security app updates a Control Data Block to mark the smartphone as secure.
• 2. Additionally, at device startup, a privileged app checks the server, and if the server specifies that the device should be taken over, the privileged app will install the security app automatically.

[0057] Figure 9 is a block diagram illustrating a configuration that enables financing for smartphone users. The smartphone (900) is a user's mobile device. The smartphone (900) hosts the privileged app (901), the Control Data Block (903), and the security application (906).

[0058] Privileged application (901) includes running an operating system privilege provisioning process to install the security application (906) with the necessary privileges to control the device

[0059] Signature verification (902) is performed by the privileged application (901) to verify that the device will be controlled. The signature verification (902) establishes that the privileged application (901) is authorized to modify the control data block (903). This check is necessary because the control data block (903) is a sensitive area of the system. Only smartphone software (and other authorized apps, typically platform-signed system apps) should be able to access this control data block.

[0060] Control data block (903) consists of a series of bytes reserved in a protected data area that cannot be reset (not erased during “factory reset”), used to ensure correct operation of devices that can be controlled by the device software. The privileged application (901) will inspect this data to detect whether the device will be controlled by the software. If the device is eligible for funding, the privileged application (901) will contact the server (904) to download the security application (906). Only the software (and other system apps with specific permissions) has access to the control data block (903) . The server (904) is analogous to the processor (122) of Figure 1, which is operated by the provider of the financing method and system described herein.

[0061] The server (904) is trusted by the privileged application (901), which contacts the server (904) to initiate control of the device. The server (904) downloads the security application (906), which is installed by the privileged application (901) in the correct location on the device. The security application (906) exercises control by locking and unlocking the device.

[0062] Server communication (905) is secure communication between privileged application (901) and server (904) to initiate security application download (906) and exchange information related to device and settings.

[0063] Security application (906) locks and unlocks the device based on information received from the server (904) or device-side software regarding user payments.

[0064] Figures 10-16 are screenshots that illustrate a smartphone lock application according to each configuration. The smartphone lock application is an element of the security application, presented to the customer/user through a user interface, in this case provided by PayJoy, and illustrated in the Figures. “PayJoy App” generally refers to the smartphone app that performs the functions described in this document and features the user interface also described here.

[0065] Figure 10 is a screenshot showing that the user has 6 credit hours left on the smartphone. It also shows the payment due date. At the bottom are buttons that allow the user to make payments, request help, or navigate to the PayJoy app homepage. Inactive buttons are in light gray.

[0066] Figure 11 is a screenshot showing that the user has 6 credit hours left on the smartphone. It also shows the payment due date. Also, the figure shows that there is no active SIM card in the smartphone. The user cannot make calls, but can access the “settings” area. At the bottom are buttons that allow the user to make payments, request help, or navigate to the PayJoy app homepage. Inactive buttons are in light gray.

[0067] Figure 12 is a screenshot showing a request for the user to make a payment at the nearest PayJoy store. The image also informs that it is necessary to connect the smartphone to the Internet after making the payment for the user's credit to be updated. If the user does not have access to the Internet, it is necessary to contact customer service to obtain a code to update the credit. At the bottom are buttons that allow the user to make payments, request help, or navigate to the PayJoy app homepage. Inactive buttons are in light gray.

[0068] Figure 13 is a screenshot showing options for making emergency calls, calling customer service, or accessing smartphone settings. At the bottom are buttons that allow the user to make payments, request help, or navigate to the PayJoy app homepage. Inactive buttons are in light gray.

[0069] Figure 14 is a screenshot showing a notification that the user does not have access to the Internet. The user is guided to check the Wi-Fi settings or the carrier's data plan. The user can also tap the screen to enter the code received. The figure shows that the user has 6 credit hours remaining and the next payment date is October 21, 2020. At the bottom are buttons that allow the user to make payments, request help, or navigate to the page start of the PayJoy application. Inactive buttons are in light gray.

[0070] Figure 15 is a screenshot showing that the user has no credits. The user is also notified that no SIM card has been detected. The next payment date is displayed. At the bottom are buttons that allow the user to make payments, request help, or navigate to the PayJoy app homepage. Inactive buttons are in light gray.

[0071] Figure 16 is a screenshot showing a notification that the user does not have access to the Internet. The user is guided to check the Wi-Fi settings or the carrier's data plan. The user can also tap the screen to enter the code received. The user is notified that no SIM card has been detected. The figure shows that the user has no credits remaining and the next payment date is October 21, 2020. At the bottom are buttons that allow the user to make payments, request help, or navigate to the homepage of PayJoy app. Inactive buttons are in light gray.

[0072] Other settings can be enabled using the structure of Figures 1-9, as described below. These settings are presented to the user through user interface screens similar to those shown in Figures 10-16, as appropriate, and can be performed through a payments application and/or work through blocking applications.

[0073] In one of the configurations, the smartphone can be unlocked with a code even if, by contract, the smartphone must be locked. The customer (user) is granted a grace period during which he can still use the smartphone, even if he has not made a payment. For example, if the customer has not made the payment and the smartphone has been blocked, it is possible to contact the Lender to obtain a specific “unlock code”. That is, the customer can still use the PayJoy App to contact Customer Service using the contact information in the app, even if the smartphone has been locked. The customer enters the code into the PayJoy App. The PayJoy App checks the validity of the code and unlocks the smartphone for a specified period.

[0074]

[0075] In other configurations, the client receives a “Lifeline” feature. By tapping a specific button on the user interface, the PayJoy app automatically grants the customer a fixed period during which the smartphone will remain unlocked, even if a payment has not been made. This is useful if the customer is in an emergency situation (e.g. natural disaster, personal safety issue, etc.) smartphone access for a period of time.

[0076]

[0077] Another configuration consists of blocking a specific network on the smartphone (for example, a telephone operator or even a Wi-Fi access point). In addition to blocking the smartphone when the user does not make a payment, this setting reinforces the rule that the smartphone must only be used with the specified communication network. This makes it possible for operators and other parties to make device financing work in tandem with other business models. This feature allows, for example, the operator to further reduce the price of financing, as it will be guaranteed that customers will only use the smartphone with the operator's network.

[0078]

[0079] In another configuration, customers receive an additional period before their next payment in exchange for referrals. For example, if the customer refers PayJoy to 10 people, they will receive 10 days of credit before their next payment date.

[0080]

[0081] In another configuration, customers can make payments to friends and family. For example, imagine that a customer creates a joint account with his/her spouse. In this case, the customer can make payments to the spouse's smartphone from their own smartphone. Customer will be subject to device financing terms. That is, he will be able to choose whether he wants his own smartphone or his spouse's smartphone to be blocked in the event of non-payment. The lender who financed the device can also control which smartphone is blocked.

[0082]

[0083] In another configuration, the smartphone is partially blocked due to non-payment. When the customer fails to make a payment, selected features are disabled, not the smartphone as a whole. For example, access to messaging apps like WhataApp and SMS, or video apps like TikTok can be blocked. At the same time, it is possible to allow making and receiving calls.

[0084]

[0085] In another configuration, customers/users can receive “cash back” (credit) in an e-wallet after full payment of the loan.

[0086]

[0087] In another configuration, once it is proven that the user makes payments reliably, a line of credit is granted.

[0088]

[0089] The aspects of the system and the methods described in this document can be implemented, with the programmed functionalities, in several circuits, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs, in ), programmable logic array (PAL) devices, memory devices, electrically programmable logic devices, and standard cell-based devices, as well as application-specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the system include: microcontrollers with memory (such as programmable and electronically erasable read-only memory (EEPROM)), embedded microprocessors, firmware, software, etc. In addition, aspects of the system can be incorporated into microprocessors with software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course, the underlying device technologies can be provided in a variety of component types, for example metal oxide semiconductor field effect transistor (MOSFET) technologies such as complementary metal oxide semiconductor (CMOS, ), bipolar technologies such as emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer structures and metal-conjugated polymer-metal structures), analog mixed technologies and digital etc.

[0090] It is worth mentioning that the various functions or processes presented in this document can be described as data and/or instructions embedded in various electronic media in terms of behavior, register transfer, logic component, transistor, layout geometry and/or other features. Electronic media on which such formatted data and/or formatted instructions may be embedded may include, but are not limited to, non-volatile storage media in various forms (e.g. optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or formatted instructions over wireless, optical or wired media or any combination thereof. Examples of transfers of such formatted data and/or instructions formatted by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols. data (e.g. HTTP, FTP, SMTP, etc.). When received into a computer system via one or more electronic media, these component and/or process expressions based on data and/or instructions in the system may be processed by a processing entity (e.g., one or more processors) in the computer system, in conjunction with the execution of one or more computer programs.

[0091] Unless the context clearly dictates otherwise, throughout descriptions and claims, the words “comprise”, “comprises” and the like should be interpreted in an inclusive sense, as opposed to an excluding or limiting sense, i.e. , in the sense of “include, among others”. Words that use the singular or plural form also encompass the plural and singular, respectively. Additionally, the words “in the present”, “here”, “above” and “below”, and others of similar meaning, refer to the request as a whole and not to specific parts of this request. When the word “or” is used in a list of two or more items, it encompasses all of the following interpretations: any one of the items in the list, all items in the list, and a combination of items in the list.

[0092] The above description of illustrated configurations of systems and methods should not be understood as exclusive or limiting the systems and methods to the exact forms presented. Although specific configurations of system components and methods, followed by examples, are described in this document for illustrative purposes, several equivalent modifications can be made within the scope of systems, components and methods, which may be observed by persons skilled in the field. The teachings related to the systems and methods presented here can be applied to the processing of other systems and methods, and not only those described above.

[0093] The elements and operations of the various configurations described above can be combined to provide other configurations. These and other changes can be made to systems and methods, in view of the detailed description above.

[0094] In general, in the following claims, the terms used must not be interpreted in a way that limits the systems and methods to the specific configurations described in the specification and in the claims, but must be interpreted in a way to include all processing systems that work under the claims. Thus, the systems and methods are not limited by the information presented, but rather the scope of the systems and methods must be determined entirely by the claims.

[0095] While certain aspects of the systems and methods are presented below in some claim formats, the inventors contemplate the various aspects of the systems and methods in various claim formats. For example, while only one aspect of systems and methods is cited as being incorporated into a machine-readable format, other aspects may also be incorporated into a machine-readable format. Thus, inventors reserve the right to add other claims after application submission in order to obtain other claim formats referring to other aspects of the systems and methods.

Claims (12)

A method for remote management of communication devices, characterized in that it comprises:
a processor of a third-party infrastructure that wirelessly transmits the operating system (OS) to the communication system, where the communication device comprises a smartphone, which executes instructions, which comprises
a boot loader that supports “lock” and “unlock” commands; and
an encrypted key in the firmware;
the third party OS, which comprises:
a privileged application that communicates with the processor and the communication device; and
a security application that communicates with a block of control data;
the third party OS that controls the communication device, which control comprises,
selectively enable and disable the communication device and selectively enable and disable specific functions of the communication device;
execute the command “block”;
disable the “lock” command preventing the bootloader from executing the “lock” command call;
prevent the user from tampering with the communication device's control software;
manage payment for device usage; and
change the bootloader binary code of the communication device to prevent the bootloader from receiving new software packages and
prevent the user from changing or replacing the third party OS. The method of claim 1, characterized in that controlling the communication device also comprises altering an encrypted key in the firmware so that the encrypted key in the firmware no longer matches the encrypted key of the third party OS. method of claim 1, characterized in that the privileged application and the security application make it possible for the user to apply for financial credit using the communication device as collateral. The method of claim 1, characterized in that the privileged application and the security application also comprise a user interface that enables:
view the number of credit hours remaining; and
view a payment date. method of claim 4, characterized by the fact that the user interface also enables:
make the payment using the communication device;
receive a request to make payment at a store; and ask for help. method of claim 4, characterized in that the user interface also notifies the user that:
no internet service was detected; and
the user is guided to check the Wi-Fi settings and the operator's data plan. method of claim 4, characterized by the fact that the user interface also enables:
make an emergency call; and
make a call to customer service. method of claim 4, characterized in that the user interface also makes it possible to enter a code to access other functions on the communication device, even if it has been blocked, this code is obtained by the user when contacting customer service , as this feature will be active on the communication device. method of claim 4, characterized by the fact that the user interface also allows the user to access the “lifeline” feature, which causes the communication device to be activated temporarily, even in case of blocking due to non-payment. The method of claim 1, characterized in that the security application blocks a specific communication network on the device. method of claim 4, characterized in that the user interface also enables the user to make payments to other users with whom he shares an account. The method of claim 4, characterized by the fact that the security application blocks selected features of the communication device, including various apps, while allowing calls to be received and made.

Images