Abstract: Embodiments provide methods and systems for remote device management of connected smart devices. The method, performed by a server system, includes rendering a user interface (UI) on an administrator device to enable an administrator to access a device management portal. The method includes enabling the administrator to access the device management portal to onboard one or more service providers. The method includes registering one or more connected smart devices with each service provider. Each connected smart device is installed with a device management application and associated with a payment plan. The method includes determining whether a payment transaction is not received from the device management application based at least on the payment plan. The method includes controlling a set of device features for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan.
Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)
1. TITLE OF THE INVENTION:
SYSTEMS AND METHODS FOR REMOTE DEVICE MANAGEMENT OF CONNECTED SMART DEVICES FOR FINANCING APPLICATIONS
2. APPLICANT(S):
(a) Name:
(b) Nationality:
(c) Address:
MASTERCARD INTERNATIONAL INCORPORATED
United States of America
2000 Purchase Street, Purchase, NY 10577, United States of America
3. PREAMBLE TO THE DESCRIPTION
The following specification particularly describes the invention and the manner in which it is to be performed.
4. DESCRIPTION
(See next page)
SYSTEMS AND METHODS FOR REMOTE DEVICE MANAGEMENT OF CONNECTED SMART DEVICES FOR FINANCING APPLICATIONS
TECHNICAL FIELD
[0001] The present disclosure relates to commerce application control and, more particularly to, electronic methods and complex processing systems for remote device management of connected smart devices for financing applications.
BACKGROUND
[0002] Connected smart devices such as televisions, refrigerators, mobile phones, tablets, laptops, and any other internet-connected consumer devices are generally financed by a financier. Device financing is a key aspect of the gig economy in developing countries to improve the adoption of smartphones or connected smart devices. The financier pays for the full amount of the purchase upfront to the manufacturer and then receive the payment from the consumer in installments (for example, equated monthly installments (EMIs)). In one example, the connected smart devices may include Internet of Things (IoT) based devices.
[0003] Generally, a smart device may represent any device with the inherent ability to connect with other devices on the internet or any other network. Moreover, IoT may describe physical objects with sensors, processing ability, software, and other technologies to connect and exchange data with other devices and systems over the internet.
[0004] For financing connected smart devices, the financier must be assured that the consumer will make timely payments for the financed amount to the financier. One of the methods to have this assurance is by remotely accessing specific features of the financed device until full payment is made by the consumer to the financier. For example, when a financier finances a mobile phone, the financier may remotely access and enable/disable specific features of the mobile phone until the financed amount is completely paid by the consumer.
[0005] However, in order to control or manage the connected smart device, there is a requirement to rely on different device manufacturers and their operating system capabilities (e.g., Android, iOS, etc.). Thus, it becomes a bottleneck to work with multiple mobile device platforms for different device models to manage device configuration and control. In addition, there is no method to remotely control or access specific features of various connected smart devices since each connected smart device may rely on a different operating system to operate.
[0006] Thus, there exists a need for a technical solution to remotely access or control specific features of connected smart devices.
SUMMARY
[0007] Various embodiments of the present disclosure provide systems, methods, and electronic devices for remote device management of connected smart devices.
[0008] In an embodiment, a computer-implemented method is disclosed. The method includes rendering, by a server system, a user interface (UI) on an administrator device to enable an administrator to access a device management portal. In addition, the method includes enabling, by the server system, the administrator to access the device management portal to onboard one or more service providers. Further, the method includes registering, by the server system, one or more connected smart devices with each service provider of the one or more service providers. Each connected smart device is installed with a device management application and associated with a payment plan. Furthermore, the method includes determining, by the server system via the device management portal, whether a payment transaction is not received from the device management application based at least on the payment plan. Upon determining that the payment transaction is not received from the device management application, the method includes controlling, by the server system, a set of device features for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan. The set of device features is controlled based on a remote communication established between the device management portal and the device management application.
BRIEF DESCRIPTION OF THE FIGURES
[0009] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0010] FIG. 1 illustrates an exemplary representation of an environment related to at least some embodiments of the present disclosure;
[0011] FIG. 2 is a block diagram representation of an interactive environment to remotely enable/disable specific features of connected smart devices, in accordance with an embodiment of the present disclosure;
[0012] FIG. 3 illustrates a sequence flow diagram of onboarding a financier on a device management portal, in accordance with an embodiment of the present disclosure;
[0013] FIG. 4 illustrates a sequence flow diagram of onboarding a financier user on the device management portal, in accordance with an embodiment of the present disclosure;
[0014] FIG. 5 illustrates a sequence flow diagram of onboarding a service provider on the device management portal, in accordance with an embodiment of the present disclosure;
[0015] FIG. 6 illustrates a sequence flow diagram of registering a connected smart device on the device management portal, in accordance with an embodiment of the present disclosure;
[0016] FIG. 7 illustrates a sequence flow diagram of registering a connected smart device on the device management portal, in accordance with another embodiment of the present disclosure;
[0017] FIG. 8 illustrates a sequence flow diagram of performing device rule management via the device management portal, in accordance with an embodiment of the present disclosure;
[0018] FIG. 9 illustrates a sequence flow diagram of remotely enabling/disabling specific features of a connected smart device by the device management portal, in accordance with an embodiment of the present disclosure;
[0019] FIG. 10 illustrates a sequence flow diagram of generating a loan contract, in accordance with an embodiment of the present disclosure;
[0020] FIG. 11 illustrates a UI to register the connected smart device on the device management portal, in accordance with an embodiment of the present disclosure;
[0021] FIG. 12 illustrates a UI to set device management rules for the connected smart device, in accordance with an embodiment of the present disclosure;
[0022] FIG. 13 is a process flow chart of a computer-implemented method for remotely enabling/disabling specific features of connected smart devices, in accordance with an embodiment of the present disclosure;
[0023] FIG. 14 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure;
[0024] FIG. 15 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure; and
[0025] FIG. 16 shows a simplified block diagram of a device, for example, an administrator device capable of implementing the various embodiments of the present disclosure.
[0026] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.
DETAILED DESCRIPTION
[0027] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0028] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0029] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0030] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, an e-wallet account, a checking account, and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization, and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0031] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be presented to a merchant or any such facility in order to fund a financial transaction via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards, e-wallet cards, and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data stored in a user device, where the data is associated a payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0032] The term “payment network”, used throughout the description, refers to a network or collection of systems used for the transfer of funds through the use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard.
[0033] The term "connected smart device", used throughout the description, refers to smart electronic devices, generally connected to other devices or networks via different protocols (say, Wi-Fi, LiFi, NFC, 5G, Bluetooth, etc.). For example, the connected smart device may include an Internet of Things (IoT) device. IoT describes physical objects or devices with sensors, processing abilities, software, and other technologies that connect and exchange data with other systems and/or devices over the internet.
OVERVIEW
[0034] Various example embodiments of the present disclosure provide systems and methods for remotely enabling/disabling specific features of connected smart devices. The present disclosure talks about a universal device-agnostic solution for managing and controlling devices from different Original Equipment Manufacturers (OEMs) for managing device financing end-to-end workflows.
[0035] As stated above, device financing is a key aspect of the gig economy in countries to improve the adoption of devices such as smartphones, laptops, connected smart devices, and the like. However, the financier must be assured that the consumer will be able to repay the financed amount on time. In some cases (such as smartphones), the financier can control specific device features of the smartphone (for example, disable network settings, turn off customization options, etc.) in case the consumer is not able to repay the financed amount. However, this existing control option is limited to smartphones of a particular brand or manufacturer. In addition, the conventional control option is limited to smartphones supporting a particular operating system (for example, Android).
[0036] The present disclosure describes a server system that is configured to provide a universal solution to control and manage devices for various device versions and platforms. In addition, the server system provides the capability to configure various devices via a common plug-and-play solution to manage devices from various OEMs. Therefore, the financier is provided with a single platform from which the financier can access, control, and manage various connected smart devices. The server system includes at least a processor and a memory. In one non-limiting example, the server system is a payment server.
[0037] The server system is configured to render a user interface (UI) on an administrator device to enable an administrator to access a device management portal. The device management portal is a cloud-based portal rendered on the UI of the administrator device. Additionally, the server system is configured to enable the administrator to access the device management portal to onboard one or more service providers.
[0038] The server system is further configured to register one or more connected smart devices with each service provider of the one or more service providers. Each connected smart device is installed with a device management application and associated with a payment plan.
[0039] To register the one or more connected smart devices with a service provider, the server system is configured to send, via the device management portal, a device registration request to the device management application installed in a connected smart device. The server system is then configured to store, via the device management application, a hardware configuration of the connected smart device in a device database.
[0040] Upon storing the hardware configuration of the connected smart device in the device database, the server system is configured to send, via the device management application, the device registration request to a service provider of the one or more service providers. Moreover, the server system is configured to receive, an acknowledgment message from the service provider in response to the device registration request.
[0041] The server system is configured to determine whether a payment transaction is not received from the device management application based at least on the payment plan. Upon determining that the payment transaction is not received from the device management application, the server system is configured to control a set of device features for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan. The set of device features is controlled based on a remote communication established between the device management portal and the device management application.
[0042] The remote communication is established between the device management portal and the device management application based, at least in part, on a hardware configuration of each connected smart device. The set of device management rules is different for each of the one or more connected smart devices. The set of device management rules is defined by the administrator.
[0043] To control the set of device features for each connected smart device, the server system is configured to send, via the device management portal, a device configuration update request to the device management application installed in a connected smart device. The server system is then configured to update, via the device management application, a device configuration of the connected smart device in the device database.
[0044] Upon updating the device configuration of the connected smart device in the device database, the server system is configured to send, via the device management application, the device configuration update request to a service provider of the one or more service providers. The server system is then configured to receive a response status from the service provider in response to the device configuration update request.
[0045] Moreover, the server system is configured to generate a device profile for each connected smart device of the one or more connected smart devices. The device profile includes device information and payment information associated with each connected smart device. The server system is also configured to receive a payment transaction associated with each connected smart device. The payment transaction is received via the device management application.
[0046] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure enables device configuration and device/ service provider management through a device management portal, which in turn, eases the process of integration between technology service providers, payment service providers, financiers, and so on. The present disclosure enables a single platform to manage various connected smart devices from various vendors. In addition, the present disclosure enables a single plug-and-play interface platform to support various connected smart devices with different hardware configurations.
[0047] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 16.
[0048] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, remotely controlling various features of connected smart devices. The environment 100 generally includes a plurality of entities, for example, a connected smart device 104 associated with a user 102, a server system 106, an issuer server 108, a merchant 112, an acquirer server 114, a payment network 116 including a payment server 118, a device management portal 120, a device management application 122, an administrator device 124 associated with an administrator 126, and a database 128, each coupled to, and in communication with (and/or with access to) a network 110. The network 110 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among the entities illustrated in FIG. 1, or any combination thereof.
[0049] Various entities in the environment 100 may connect to the network 110 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future generation communication protocols, or any combination thereof. For example, the network 110 may include multiple different networks, such as a private network made accessible by the server system 106, separately, and a public network (e.g., the Internet etc.).
[0050] The user 102 may be any individual, representative of a corporate entity, non-profit organization, or any other person. The user 102 may have a payment account issued by corresponding issuing banks (associated with the issuer server 108) and may be provided a payment card with financial or other account information encoded onto the payment card such that the user 102 may use the payment card to initiate and complete a transaction using a bank account at the issuing bank. Examples of the payment card may include, but are not limited to, a smartcard, a debit card, a credit card, etc.
[0051] In one embodiment, the issuer server 108 is a financial institution that manages accounts of multiple cardholders (e.g., the user 102). Account details of the accounts established with the issuer server 108 are stored in cardholder profiles of the cardholders in a memory of the issuer server 108 or on a cloud server associated with the issuer server 108. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
[0052] The user 102 may be a person who wants to purchase the connected smart device 104. The user 102 purchases the connected smart device 104 from the merchant 112 and thus, the connected smart device 104 is associated with the user 102. The user 102 may purchase the connected smart device 104 from a financier (e.g., the administrator). For the sake of simplicity, only one connected smart device 104 is shown in FIG. 1; however, it is noted that there can be any number of connected smart devices associated with the user 102. In an example, three connected smart devices (such as a first connected smart device, a second connected smart device, and a third connected smart device) may be associated with a user (e.g., the user 102).
[0053] For example, the first connected smart device is a smartphone, the second connected smart device is a refrigerator, and the third connected smart device is a laptop. In an example, the three connected smart devices belong to the user 102. In another example, the three connected smart devices may belong to various users. For example, the first connected smart device may belong to a user A, while the second connected smart device and the third connected smart device may belong to a user B.
[0054] The administrator 126 may represent a person, or an organization that operates and/or manages the server system 106. In one example, the administrator 126 is a financier that finances the connected smart device 104 to earn a profit as interest on the principal amount (i.e., payment transaction amount). The administrator 126 may access the administrator device 124 to control, manage, and/or access the connected smart device. In some non-limiting examples, the administrator device 124 associated with the administrator 126 may be a smartphone, a tablet, a laptop, a computer system, or any computing device. In an example, an administrator device may include portable devices such as laptop, smartwatch, personal digital assistant (PDA), smartphone, and the like. In another example, an administrator device may include fixed devices such as desktop, workstation, and the like.
[0055] The user 102 may purchase the connected smart device 104 from the merchant 112. The merchant 112 may refer to a seller, retailer, purchase location, organization, or any other entity that is in the business of selling goods or providing services, and it can refer to either a single business location or a chain of business locations of the same entity.
[0056] In an example, a user may transact at merchant terminals to perform the payment transactions for a merchant. Examples of the merchant terminals include Point-Of-Sale (POS) devices, Point-Of-Purchase (POP) devices, Point-Of-Interaction (POI) devices, and the like. The merchant 112 may have a payment account managed by the acquirer server 114.
[0057] The acquirer server 114 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, the merchant 112, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0058] The administrator 126 may access the device management portal 120 on the administrator device 124. In an implementation, the administrator 126 may access the device management portal 120 on a web browser on the administrator device 124. In another implementation, the administrator 126 may access the device management portal 120 as an application installed on the administrator device 124. The device management portal 120 remotely connects with the device management application 122. The device management application 122 is installed in the connected smart device.
[0059] The device management application 122 is a plug-and-play application that can easily be installed in the connected smart device 104. The device management application 122 can be installed in the connected smart device 104 irrespective of the device parameters. The device parameters may include device type, device model, device operating system, device manufacturer, device hardware configuration parameters, and the like. The device management application 122 further connects with the server system 106 remotely.
[0060] In one implementation, the server system 106 renders the device management portal 120 on the administrator device 124. In one example, the device management portal 120 is a web-based system that can be used for provisioning connected smart devices, onboard financiers, define configuration rules (to enable/disable specific features of the financed connected smart device in case the user 102 misses the loan payment), and the like.
[0061] The device management application 122 may include any mobile program, software, or other executable code suitable to remotely connect with the device management portal 120. In an implementation, the device management application 122 may be a general-purpose application, such as a web browser. In an implementation, the server system 106 may enable the administrator 126 to access the device management portal 120 on the administrator device 124.
[0062] The server system 106 is configured to perform one or more of the operations described herein. In an example, the server system 106 coupled with the database 128 is embodied in the payment network 116. In another example, the server system 106 is the payment server 118.
[0063] The server system 106 is configured to render the device management portal 120 on the administrator device 124. The server system 106 is also configured to remotely connect to the device management application 122 installed in the connected smart device 104. In particular, the server system 106 renders a user interface (UI) on the administrator device 124 to enable the administrator 126 to access the device management portal 120. The UI allows the administrator 126 to access, control, and/or manage the connected smart device.
[0064] The administrator 126 may utilize the device management portal 120 to set up certain rules for the connected smart device 104. For example, the administrator 126 may set up separate rules for the first connected smart device, separate rules for the second connected smart device, and so on. The administrator 126 may then use pre-set rules or define a new set of rules for various connected smart devices.
[0065] For example, the user 102 may purchase the connected smart device 104 from the merchant 112. The user 102 may opt for a finance option (e.g., Equated monthly installment (EMI)) option for the connected smart device 104. Therefore, the administrator 126 (e.g., the financier) pays for the full amount of the product (i.e., the connected smart device) on behalf of the user 102 to the merchant 112. In addition, the financier gets into an agreement with the user 102 that the user 102 will pay the financed amount along with the interest, if any, to the financier. The user 102 may choose to pay for the financed amount in weekly, monthly, or half-yearly installments.
[0066] The administrator 126 then registers the connected smart device 104 on the device management portal 120. For example, the administrator 126 may register the device configuration of the connected smart device 104 onto the device management portal 120 once. In addition, the administrator 126 installs the device management application 122 in the connected smart device 104. In an example, the device management application 122 installed in the connected smart device 104 cannot be uninstalled by the user 102. The administrator 126 may then define a set of device management rules to control the financed device (i.e., the connected smart device 104) until the complete payment of the connected smart device 104 is received by the administrator 126 (e.g., the financier).
[0067] In an implementation, the server system 106 is configured to implement a run-time analytics tool in the connected smart device 104 with the facilitation of the device management application 122. In another implementation, the device management application 122 includes the run-time analytics tool. The run-time analytics tool collects insight information associated with the connected smart device 104. For example, the device management application 122 collects insight information such as what kind of application is being used more by the user 102. In an example, the insight information may inform the financier that the user 102 prefers using SMS service to communicate rather than a third-party messaging application. The financier may then utilize this information to configure the set of device features for the connected smart device 104.
[0068] Let us consider that the connected smart device 104 is an iOS-based smartphone. In an example, the administrator 126 can define the set of device management rules to disable the network settings of the smartphone if an installment is not paid after 15 days post the due date. In another example, the administrator 126 can define the set of device management rules to disable customization options (e.g., dark mode settings, wallpaper settings, adaptive brightness settings, etc.) if an installment is not paid after 10 days post the due date. In yet another example, the administrator 126 can define the set of device management rules to completely brick, format, lock, or reset the smartphone if an installment is not paid for more than 90 days after the due date.
[0069] The server system 106 is a separate part of the environment 100 and may operate apart from (but still in communication with, for example, via the network 110) the issuer server 108, the payment server 118, and any third-party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 106 may be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 118, or the issuer server 108. In addition, the server system 106 should be understood to be embodied in at least one computing device in communication with the network 110, which may be specifically configured, via executable instructions, to perform steps as described herein, and/or embodied in at least one non-transitory computer-readable media.
[0070] In one embodiment, the server system 106 is configured to access datasets of historical payment transaction data from multiple data sources including, for example, the database 128, the issuer server 108 (for example, application server, web server, media server, etc.), and other suitable data sources not shown in FIG. 1. Alternatively, the server system 106 can be directly coupled to data sources, as opposed to, via the network 110.
[0071] In an example, the database 128 may implement relational and non-relational databases, big data stations, file systems, and other suitable applications storing datasets with historical payment transaction data. In an example, the database 128 may include historical payment transaction history of the user 102. In another example, the database 128 may include hardware configuration of the connected smart device 104.
[0072] In one implementation, the server system 106 is in communication with the database 128. The database 128 may store trained DRL models and algorithms required for the server system 106 to perform one or more of the operations described herein, for example, to remotely enable/disable specific functions of the connected smart device 104. The database 128 may be incorporated in the server system 106 or may be an individual entity connected to the server system 106 or may be a database stored in a cloud storage.
[0073] The payment network 116 may be used by the payment card issuing authorities as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transaction data between financial institutions that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0074] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown the FIG. 1. Furthermore, two or more systems or devices shown in the FIG. 1 may be implemented within a single system or device, or a single system or device shown in the FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0075] FIG. 2 is a block diagram representation 200 of an interactive environment to remotely control connected smart devices 216a-216c, in accordance with an embodiment of the present disclosure. In some embodiments, the server system 106 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture. In an implementation, the server system 106 is embodied in the payment network 116.
[0076] The block diagram representation 200 includes a loan payment module 202, a payment gateway 204, a device configuration module 206, a service provider module 208, a payment database 210, a device database 212, one or more service providers 214a-214c, and the connected smart devices 216a-216c, a payment module 218, a device module 220, and a financier management module 222. The financier module 222 includes a financier configuration module 224 and a user management module 226. The financier module 222 is connected with a financier database 228.
[0077] In some implementations, the server system 106 runs or implements the device management portal 120 on the administrator device 124. In particular, the server system 106 is configured to render a user interface (UI) on the administrator device 124 to enable the administrator 126 to access the device management portal 120. In one embodiment, the administrator 126 is a financier. In one implementation, the administrator 126 is responsible for onboarding a financier on the device management portal 120.
[0078] For the sake of simplicity, it is mentioned that only one financier is onboarded on the device management portal 120. However, it should be noted that there can be any number of financiers that can be onboarded on the device management portal 120. In an implementation, the administrator 126 is responsible for onboarding the financier on the device management portal 120.
[0079] The financier can then register the connected smart device(s) 104 on the device management portal 120. In addition, the administrator 126 may define roles for the financier. In an example, the administrator 126 may enable the financier to only view the connected smart devices 104. In another example, the administrator 126 may enable the financier to view, control, and/or manage the connected smart devices 104. In some examples, the administrator 126 may also be responsible for the upkeep and maintenance of the device management portal 120.
[0080] The server system 106 is then configured to enable the financier to access the device management portal 120 to onboard the one or more service providers 214a-214c. The one or more service providers 214a-214c includes the service provider 214a, the service provider 214b, and the service provider 214c. In an example, each service provider is associated with each connected smart device. In general, service provider may refer to a range of small, midsize, and large service firms that build and deploy connected smart solution applications.
[0081] With reference to FIG. 2, the connected smart device 216a is associated with the service provider 214a, the connected smart device 216b is associated with the service provider 214b, and the connected smart device 216c is associated with the service provider 214c. It is shown in FIG. 2 that only one connected smart device is associated with an service provider. However, there can be any number of connected smart devices that can be associated with an service provider.
[0082] The server system 106 is further configured to register the one or more connected smart devices (e.g., the connected smart device 216a) with each service provider (e.g., the service provider 214a) of the one or more service providers 214a-214c. In particular, the server system 106 enables the financier to register the one or more connected smart devices (e.g., the connected smart device 216a) corresponding to each service provider (e.g., the service provider 214a). Each connected smart device (e.g., the connected smart device 216a) of the one or more connected smart devices is installed with the device management application 122 and associated with the payment plan.
[0083] To register the one or more connected smart devices 216a-216c with the service provider (e.g., the service provider 214a), the server system 106 is configured to send, via the device management portal 120, a device registration request to the device management application 122 installed in the connected smart device (e.g., the connected smart device 216a). The server system 106 is then configured to store, via the device management application 122, a hardware configuration of the connected smart device (e.g., the connected smart device 216a) in the device database 212. The hardware configuration may include hardware configuration parameters of the corresponding connected smart device (e.g., the connected smart device 216a).
[0084] Upon storing the hardware configuration of the connected smart device (e.g., the connected smart device 216a) in the device database 212, the server system 106 is configured to send, via the device management application 122, the device registration request to the service provider (e.g., the service provider 214a) of the one or more service providers 214a-214c. In addition, the server system 106 is configured to receive an acknowledgement message from the service provider (e.g., the service provider 214a) in response to the device registration request.
[0085] The one or more service providers 214a-214c are then connected with the server system 106 or the payment server 118 via the network 110. In an implementation, the payment module 218 includes the loan payment module 202 and the payment gateway 204. In an implementation, the device module 220 includes the device configuration module 206 and the service provider module 208.
[0086] The device module 220 is in communication with the device database 212. The payment module 218 is in communication with the payment database 210. The service provider module 208 connects the one or more service providers 214a-214c with the device management module. The device configuration module 206, in communication with the device database 212, stores the hardware configuration of the one or more connected smart devices (e.g., the connected smart device 216a) associated with each service provider (e.g., the service provider 214a).
[0087] The loan payment module 202, in communication with the payment database 210, stores the transaction history of the connected smart devices 216a-216c. The loan payment module 202 is responsible to manage the information such as received loan amount, pending loan amothe unt, interest charged, and so on. The payment gateway 204 is responsible for enabling the connected smart devices to make timely payments for the financed transaction amount. Generally, payment gateway 204 is a merchant service provided by an e-commerce application service provider that authorizes credit card or direct payments processing for e-businesses, online retailers, and the like.
[0088] The financier configuration module 224 is responsible for the onboarding and/or management of the financier on the device management portal 120. The user management module 226 is responsible for onboarding and/or management of the financier user (i.e., a person associated with the financier organization) on the device management portal 120. The financier database 228 provides a storage location as the financier details and the financier user details.
[0089] During registering of each connected smart device, the financier may register payment details (e.g., financed amount, number of installments, due date for installments, interest rate, etc.) in the loan payment module 202. The financier then registers the set of device management rules for each connected smart device (e.g., the connected smart device 216a) in the device management module. In case timely payments are not received by the device management portal 120 (or the financier), the financier can control a set of device features of the financed connected smart device (e.g., the connected smart device 216a) remotely. The device management module is an instance of the device management portal 120.
[0090] In particular, the server system 106 is configured to control the set of device features for each connected smart device (e.g., the connected smart device 216a) based, at least in part, on the set of device management rules associated with a payment plan associated with the each connected smart device. The term “payment plan” herein may refer to the terms and conditions of the financier agreed upon by the user 102. For example, the payment plan may include a number of installments, interest rate, payment amount of each installment, and the like.
[0091] The set of device management rules may be configured by the financier. In addition, the set of device management rules depends on the payment plan associated with the corresponding connected smart device. The “set of device management rules" herein may refer to rules, based on which, the corresponding connected smart device (e.g., the connected smart device 216a) will be controlled in case timely payments are not received from the connected smart device. For example, the financier can access the device management portal 120 to completely lock the connected smart device (like 216a).
[0092] In real-time, the server system 106 is configured to determine whether a payment transaction is not received from the device management application based at least on the payment plan. For example, a payment installment of 3000 dollars is to be received for a financed smartphone A1 in the month of February as per the payment plan. The server system 106 determines that the payment transaction of 3000 dollars is not received in the month of February as per the payment plan.
[0093] Upon determining that the payment transaction (here, 3000 dollars) is not received from the device management application 122, the server system 106 is configured to control the set of device features for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan.
[0094] To control the connected smart device 216a, the financier may generate a request at the device management portal 120. The service provider module 208 is responsible to handle the request. In particular, the service provider (e.g., the service provider 214a) identifies the connected smart device (e.g., the connected smart device 216a) for which the request is generated. The service provider (e.g., the service provider 214a) may identify the connected smart device (e.g., the connected smart device 216a) based on the hardware configuration of the connected smart device (like 216a). Upon identification, the service provider (e.g., the service provider 214a) controls the connected smart device (e.g., the connected smart device 216a) as per the request.
[0095] The set of device features is controlled based on remote communication between the device management portal 120 and the device management application 122 installed in each connected smart device. In particular, the remote communication is established between the device management portal 120 and the device management application 122 based, at least in part, on the hardware configuration of each connected smart device.
[0096] To control the set of device features for each connected smart device, the server system 106 is configured to send, via the device management portal 120, a device configuration update request to the device management application 122 installed in a connected smart device (e.g., the connected smart device 216a). The server system 106 is then configured to update, via the device management application 122, a device configuration of the connected smart device (e.g., the connected smart device 216a) in the device database 212.
[0097] Upon updating the device configuration of the connected smart device (e.g., the connected smart device 216a) in the device database 212, the server system 106 is configured to send, via the device management application 122, the device configuration update request to an service provider (e.g., the service provider 214a) of the one or more service providers 214a-214c. The server system 106 is then configured to receive, a response status from the service provider (e.g., the service provider 214a) in response to the device configuration update request.
[0098] The server system 106 is also configured to generate a device profile for each connected smart device (e.g., the connected smart device 216a) of the one or more connected smart devices. The device profile includes device information and payment information associated with the corresponding connected smart device (e.g., the connected smart device 216a). The device information may get stored in the device database 212. In addition, the payment information may get stored in the payment database 210. Further, the server system 106 is configured to update the device profile based, at least in part, on the timely payments made by the user 102 or owner of the connected smart device.
[0099] In an embodiment, the device management portal 120 is a cloud-based portal rendered on the UI of the administrator device 124. The device management portal 120 provides a UI to onboard various financiers, the one or more connected smart devices, and to configure the set of device management rules for each connected smart device.
[00100] In an implementation, the financier is a separate person or organization that wishes to finance the connected smart device (e.g., the connected smart device 216a). The device management portal 120 is accessed by the financier based, at least in part, on a role defined for the financier. The role is defined by the administrator 126 associated with the server system 106. The role can be either administrator 126 or financier.
[00101] In one implementation, the administrator 126 may access the device management portal 120 based on the role. For example, the financier may access the device management portal 120 as the administrator. The administrator 126 has more control over the device management portal 120. For example, the administrator 126 can delete the financier from the device management portal 120. However, the financier cannot delete the administrator 126 from the device management portal 120.
[00102] The device management portal 120 enables the financier to register the one or more connected smart devices. The “one or more connected smart devices” herein may refer to those connected smart enabled devices that the user 102 gets financed by the financier. For example, the user 102 purchases a smart refrigerator from the merchant 112 and gets it financed by the financier. In this case, the financier registers the refrigerator in the device management portal 120 and installs the device management application 122 in the refrigerator. The device management portal 120 can then establish a remote communication with the device management application 122 to remotely control specific features of the refrigerator if timely payments are not made by the user 102 (i.e., owner) of the refrigerator.
[00103] In one example, a smart device is a smartphone, the financier may define the “set of device management rules” as to “discontinue SMS support” if any monthly installment is missed. In addition, the financier may define the “set of device management rules” as to “disable mobile data” along with “discontinue SMS support” if two subsequent monthly installments are missed. Further, the financier can define the “set of device management rules” as to “completely lock the smartphone” if three subsequent monthly installments are missed. In this manner, the financier can define its own set of device management rules for each connected smart device.
[00104] The device management application 122 is a low-level device management application installed in each connected smart device irrespective of the operating system (OS) of each connected smart device. For example, the device management application 122 is installed in connected smart devices supporting operating systems such as iOS, Android, Bada, Symbian, Blackberry, KaiOS, and the like. The device management application 122 communicates with the device management portal 120 with the facilitation of software development kits (SDKs) and/or application programming interfaces (APIs) supported by the OS of the corresponding device.
[00105] In particular, the device management application 122 communicates with the device management portal 120 for pulling configuration and control rules (i.e., the set of device management rules). The device management application 122 provides abstraction as a unified interface communicating with various device management internals specific to the OS it is currently running on. In one example, the device management application 122 communicates directly with the kernel of the connected smart device, in which it is installed, to remotely establish a connection with the device management portal 120.
[00106] In one implementation, the device management application 122 also provides a UI to the user 102 of the connected smart device (e.g., the connected smart device 216a) to perform payment transactions in case the monthly installment is missed by the user 102. For example, the monthly installment may not get auto-debited from the payment account of the user 102 due to insufficient balance. In such cases, the user 102 can access the device management application 122 to perform the payment transaction for the financed connected smart device. The user 102 can perform the payment transaction using payment mediums such as credit cards, debit cards, online payment transactions, and the like. Thus, the server system 106 via the device management application 122, is configured to receive the payment installment associated with the connected smart device (e.g., the connected smart device 216a) in real-time.
[00107] In one implementation, the device management portal 120 provides a UI to the administrator 126 to view the insights associated with the connected smart device 104. In an example, the insights may include information such as the usage of applications installed in the connected smart device 104. In another example, the insights may include payment information such as the financed amount re-paid by the user 102, number of installments left, transaction amount to be paid, and the like.
[00108] The set of device management rules is different for each connected smart device of the one or more connected smart devices. For example, the set of device management rules for a refrigerator will be different from the set of device management rules for a smartphone. Similarly, the set of device management rules for a connected smart car will be different from the set of device management rules for a smart speaker. In an embodiment, the set of device management rules is defined by the financier. In another embodiment, the set of device management rules is defined by the administrator.
[00109] The server system 106 is also configured to transmit notifications to the connected smart device (like the connected smart device 216). In one implementation, the server system 106 is configured to transmit notifications related to the payment information associated with the connected smart device (like the connected smart device 216a). For example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) if payment for the monthly installment is received. In another example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) if payment for the monthly installment is missed or not received. In yet another example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) as a reminder for an upcoming payment, and so on.
[00110] In another implementation, the server system 106 is configured to transmit notifications related to the connected smart device (like the connected smart device 216a). For example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) if a specific device feature has been disabled by the financier. In another example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) if various device features have been disabled by the financier due to various missed monthly installments. In yet another example, the server system 106 transmits a notification to the connected smart device (e.g., the connected smart device 216a) as a reminder that the device is going to be locked in x number of days if pending payment is not completed, and so on, where x is a natural number.
[00111] FIG. 3 illustrates a sequence flow diagram 300 of onboarding a financier on the device management portal 120, in accordance with an embodiment of the present disclosure.
[00112] As discussed above, the administrator 126 may onboard the financier on the device management portal 120. The term “financier” herein may refer to an organization or company that is onboarded for the first time on the device management portal 120.
[00113] At 302, the device management portal 120 onboards the financier in the financier management module 222. To onboard the financier, the device management portal 120 may request for financier details such as the name of the financier, country ID of the financier, branch ID of the financier, and the like from the financier.
[00114] At 304, the device management portal 120 stores the financier details in the financier database 228.
[00115] In case the financier details are already stored in the financier database 228 (i.e., the financier is not a new financier), at 306, the financier database 228 sends an “SQL exception” error message to the financier management module 222.
[00116] At 308, the financier management module 222 sends a “Bad request exception” to the device management portal 120. Thus, the financier details are not stored in the financier database 228 as the financier details are already stored in the financier database 228.
[00117] Otherwise, at 310, the financier management module 222 sends an “onboarding successful” message to the device management portal 120. In this manner, the financier is onboarded on the device management portal 120.
[00118] FIG. 4 illustrates a sequence flow diagram 400 of onboarding a financier user on the device management portal 120, in accordance with an embodiment of the present disclosure.
[00119] As discussed above, the administrator 126 may onboard the financier on the device management portal 120. The administrator 126 can then onboard a financier user on the device management portal 120. The term “financier user” herein may refer to person associated with the financier who is authorized to register or onboard service providers 214a-214c with the device management portal 120.
[00120] At 402, the device management portal 120 onboards the financier user in the financier management module 222. To onboard the financier user, the device management portal 120 may request for financier user details such as the name of the financier user, email address of the financier user, financier ID, contact number of the financier user, username, password, and the like from the financier user.
[00121] At 404, the financier management module 222 validates the financier user details.
[00122] In case the financier user details are invalid, at 406, the financier management module 222 sends a “Bad request exception” to the device management portal 120.
[00123] Otherwise, in case the financier user details are valid, at 408, the financier management module 222 stores the financier user details in the financier database 228.
[00124] At 410, the financier database 228 sends a “financier user onboarding successful” message to the financier management module 222.
[00125] At 412, the financier management module 222 sends the “financier user onboarding successful” message to the device management portal 120. In this manner, the financier user is onboarded on the device management portal 120.
[00126] FIG. 5 illustrates a sequence flow diagram 500 of onboarding a service provider on the device management portal 120, in accordance with an embodiment of the present disclosure.
[00127] In an embodiment, the administrator 126 may onboard the service provider on the device management portal 120. In another embodiment, the financier may onboard the service provider on the device management portal 120.
[00128] At 502, the device management portal 120 may transmit the service provider details to the device management application 122. The service provider details may include name, host, port, digital certificates, email address, and the like.
[00129] At 504, the device management application 122 validates the service provider details.
[00130] In case the service provider details are invalid, at 506, the device management application 122 sends a “Bad request exception” to the device management portal 120.
[00131] Otherwise, in case the service provider details are valid, at 508, the device management application 122 stores the service provider details in the device database 212.
[00132] At 510, the device database 212 sends a “service provider onboarding successful” message to the device management application 122.
[00133] At 512, the device management application 122 sends a connection request to the service provider.
[00134] Upon establishing a successful connection, at 514, the service provider sends a “connection successful” response to the device management application 122.
[00135] At 516, the device management application 122 sends a “connection successful” response to the device management portal 120.
[00136] FIG. 6 illustrates a sequence flow diagram 600 of registering a connected smart device on the device management portal 120, in accordance with an embodiment of the present disclosure.
[00137] In an example, the financier may onboard the connected smart device (e.g., the connected smart device 104) on the device management portal 120. In another example, the administrator 126 may onboard the connected smart device 104 on the device management portal 120.
[00138] At 602, the device management portal 120 may transmit the hardware configuration of the connected smart device 104 to the device management application 122. The hardware configuration of the connected smart device 104 may include device type, device OS, device model, unique identification number of the device (such as IMEI, Universally unique identifier (UUID), etc.) and the like.
[00139] At 604, the device management application 122 validates the connected smart device’s 104 details.
[00140] In case the connected smart device 104 details are invalid, at 606, the device management application 122 sends a “Bad request exception” to the device management portal 120.
[00141] Otherwise, in case the connected smart device 104 details are valid, at 608, the device management application 122 stores the connected smart device 104 and OEM details in the device database 212.
[00142] At 610, the device database 212 sends a “smart device registration successful” message to the device management application 122.
[00143] At 612, the device management application 122 sends a connection request to the service provider to register the connected smart device 104.
[00144] Upon establishing a successful connection, at 614, the service provider sends a “registration successful” response to the device management application 122.
[00145] At 616, the device management application 122 sends a “registration successful” response to the device management portal 120.
[00146] FIG. 7 illustrates a sequence flow diagram 700 of registering a connected smart device (e.g., the connected smart device 216a) on the device management portal 120, in accordance with another embodiment of the present disclosure.
[00147] As discussed above, the server system 106 renders a UI on the administrator device 124 that enables the administrator 126 to register the connected smart device (e.g., the connected smart device 216a) on the device management portal 120. The administrator 126 may also access the UI to control or manage the registered connected smart devices.
[00148] To register a new connected smart device, at 702, the device management portal 120 sends a device registration request to the device management application 122 installed in the connected smart device 216a. In particular, the administrator 126 initiates the device registration request via the device management portal 120 accessed in the administrator device 124. In one implementation, the device management application 122 is installed in the connected smart device (e.g., the connected smart device 216a) by the financier. In an example, the device management application 122 cannot be uninstalled by the user 102.
[00149] At 704, the device management application 122 receives the device registration request from the device management portal 120. In addition, the device management application 122 stores hardware configuration of the corresponding connected smart device (e.g., the connected smart device 216a) (in which the device management application 122 is installed) in the device database 212. The hardware configuration may include device hardware information such as International Mobile Equipment Identity (IMEI) number, OEM details, processor configuration, memory configuration, communication interface configuration, and the like. The hardware configuration may get stored in the form of tables in the device database 212 associated with the device management module.
[00150] At 706, once the device hardware configuration is successfully stored in the device database 212, the device management application 122 may receive a “Device registration successful” message from the device database 212. Otherwise, upon unsuccessful registration due to any reason, the device management portal 120 may again send a request to register the connected smart device 216a.
[00151] After successful registration of the connected smart device (e.g., the connected smart device 216a) on the device management portal 120, at 708, the device management application 122 may send a device registration request to the service provider (e.g., the service provider 214a) to register the connected smart device 216a.
[00152] Upon successful registration of the connected smart device (e.g., the connected smart device 216a) with the service provider (e.g., the service provider 214a), at 710, the service provider sends an acknowledgement message to the device management application 122. The acknowledgement message includes the status of the device registration request with the service provider (e.g., the service provider 214a). The acknowledgement message may include “SUCCESS” if the connected smart device (like the connected smart device 216a) is successfully registered with the service provider (e.g., the service provider 214a). Otherwise, the acknowledgement message may include “FAILURE” if the connected smart device is not registered with the service provider.
[00153] At 712, the device management application 122 transmits the acknowledgement status to the device management portal 120.
[00154] FIG. 8 illustrates a sequence flow diagram 800 of performing device rule management via the device management portal 120, in accordance with an embodiment of the present disclosure.
[00155] As discussed above, the administrator 126 (or the financier) can create the set of device management rules based on the hardware configuration of the connected smart device 216a. In addition, the financier can select multiple features per payment due days to control the set of features in the connected smart device 216a.
[00156] At 802, the device management portal 120 may transmit the connected smart device configuration details to the device management application 122. The connected smart device configuration details may include device type, device OS, OEM details, set of features (with format [payment days: feature]), data service, and the like.
[00157] At 804, the device management application 122 validates the connected smart device configuration details.
[00158] In case the connected smart device configuration details are invalid, at 806, the device management application 122 sends a “Bad request exception” to the device management portal 120.
[00159] Otherwise, in case the connected smart device configuration details are valid, at 808, the device management application 122 adds/updates the connected smart device configuration details in the device database 212.
[00160] At 810, the device database 212 sends an “update successful” message to the device management application 122.
[00161] At 812, the device management application 122 sends a connection request to the service provider to update the connected smart device configuration details.
[00162] Upon establishing a successful connection, at 814, the service provider sends an “update successful” response to the device management application 122.
[00163] At 816, the device management application 122 sends a “connected smart device configuration updated” response to the device management portal 120.
[00164] FIG. 9 illustrates a sequence flow diagram 900 of remotely controlling a connected smart device (e.g., the connected smart device 216a) by the device management portal 120, in accordance with an embodiment of the present disclosure.
[00165] As discussed above, the server system 106 renders a UI on the administrator device 124 that enables the administrator 126 to enable/disable specific features of the registered connected smart devices.
[00166] To control an already registered connected smart device, at 902, the device management portal 120 sends a device configuration update request to the device management application 122 installed in the connected smart device 216a. In an embodiment, the device management portal 120 may automatically send the device configuration update request upon detection that the monthly installment is not received by the financier. In another embodiment, the financier may manually send the device configuration update request to the device management application 122.
[00167] At 904, the device management application 122 receives the device configuration update request from the device management portal 120. In addition, the device management application 122 updates the device configuration of the corresponding connected smart device (e.g., the connected smart device 216a) in the device database 212.
[00168] In an example, the device configuration update request may include request to stop SMS service in the connected smart device 216a. In another example, the device configuration update request may include request to disable specific applications (e.g., WhatsApp, Facebook, etc.) in the connected smart device 216a. In yet another example, the device configuration update request may include request to completely lock the connected smart device.
[00169] At 906, the device database 212 updates the device management application 122 with the configuration update status. In an example, the device database 212 may update the device management application 122 with “Device update successful” message in case of successful update. Otherwise, upon unsuccessful update due to any reason, the device database 212 may update the device management application 122 with “Device update unsuccessful”.
[00170] At 908, the device management application 122 may send a device configuration update request to the service provider (e.g., the service provider 214a). In particular, the device management application 122 integrates with the service provider (e.g., the service provider 214a) to update the device configuration of the connected smart device 216a.
[00171] At 910, the service provider (e.g., the service provider 214a) sends a response status of the device configuration update request to the device management application 122. The response status may include “SUCCESS” if the connected smart device 216a is successfully updated as per the device configuration update request. Otherwise, the response status may include “FAILURE” if the connected smart device 216a is not updated.
[00172] At 912, the device management application 122 transmits the response status of the device configuration update request to the device management portal 120.
[00173] FIG. 10 illustrates a sequence flow diagram 1000 of generating a loan contract, in accordance with an embodiment of the present disclosure.
[00174] As discussed above, the user 102 and the financier may sign the loan contract. The user 102 may purchase the connected smart device from the merchant. The financier finances the connected smart device and pays for the purchase to the merchant on behalf of the user 102. The user 102, in turn, pays for the payment transaction amount to the financier in equated installments.
[00175] At 1002, the device management portal 120 sends contract details to the payment module. The contract details may include amount, currency, duration, duration unit, financier ID, device ID, device configuration ID, and the like.
[00176] At 1004, the device management application 122 validates the contract request.
[00177] In case the loan contract details are invalid, at 1006, the device management application 122 sends a “Bad request exception” to the device management portal 120.
[00178] Otherwise, in case the loan contract details are valid, at 1008, the device management application 122 contract entity is in the payment database 210.
[00179] At 1010, the payment database 210 sends a “contract entity successful” message to the device management application 122.
[00180] At 1012, the device management application 122 sends a “contract entity successful” message to the device management portal 120.
[00181] FIG. 11 illustrates a UI 1100 to register the connected smart device on the device management portal 120, in accordance with an embodiment of the present disclosure.
[00182] In UI 1100, a drop-down list (see, 1102) is shown to select the device type. For example, the device type may include television, refrigerator, mobile, washing machine, and the like. In addition, a drop-down list (see, 1104) is shown to select the device OS. The device OS may include Android, iOS, Windows, and the like.
[00183] Further, a text box (see, 1106) is shown to type the device model. The financier can type in the device model in the text box. Furthermore, a text box (see, 1108) is shown to enter the unique identifier. In an example, the unique identifier is an alpha-numeric code used to uniquely identify the device. Moreover, a drop-down list (see, 1110) is shown to select the service provider ID. Also, a SUBMIT button (see, 1112) is shown to submit the connected smart device details.
[00184] FIG. 12 illustrates a UI 1200 to set the device management rules for the connected smart device, in accordance with an embodiment of the present disclosure.
[00185] In UI 1200, the drop-down list (see, 1102) is shown to select the device type. For example, the device type may include television, refrigerator, mobile, washing machine, and the like. In addition, the drop-down list (see, 1104) is shown to select the device OS. The device OS may include Android, iOS, Windows, and the like.
[00186] Further, a drop-down list (see, 1202) is shown to select the OEM. The OEM may include Samsung, Apple, Whirlpool, and the like. Furthermore, a drop-down list (see, 1204) is shown to select the payment due date. The payment due date may include 7 days, 15 days, 30 days, 45 days, and the like.
[00187] Moreover, radio buttons (see, 1206) are shown to select the feature to be disabled. The user 102 may click on a single radio button to select the feature to be disabled. The user 102 may then click on an “ADD” button (see, 1208) to permanently select the feature to be disabled.
[00188] Also, a text-box (see, 1210) is shown to enter the data service. For example, the data service may include Airtel, Vodafone, and the like. The UI 1200 includes a SUBMIT button (see, 1212) to submit the set of device management rules for the connected smart device.
[00189] FIG. 13 is a process flow chart of a computer-implemented method 1300 for remotely enabling/disabling specific features of connected smart devices, in accordance with an embodiment of the present disclosure. The method 1300 depicted in the flow chart may be executed by, for example, the server system 106. Operations of the flow chart of the method 1300, and combinations of operation in the flow chart of the method 1300, may be implemented by, for example, hardware, firmware, a processor, circuitry, and/or a different device associated with the execution of software that includes one or more computer program instructions. It is noted that the operations of the method 1300 can be described and/or practiced by using a system other than these computer systems. The method 1300 starts at operation 1302.
[00190] At operation 1302, the method 1300 includes rendering, by the server system 106, the user interface (UI) on the administrator device 124 to enable the administrator 126 to access the device management portal 120. The device management portal 120 is a cloud-based portal rendered on the UI of the administrator device 124.
[00191] At operation 1304, the method 1300 includes enabling, by the server system 106, the administrator 126 to access the device management portal 120 to onboard the one or more service providers 214a-214c.
[00192] At operation 1306, the method 1300 includes registering, by the server system 106, the one or more connected smart devices with each service provider (e.g., the service provider 214a) of the one or more service providers 214a-214c. Each connected smart device (e.g., the connected smart device 216a) is installed with the device management application 122 and associated with the payment plan.
[00193] At operation 1308, the method 1300 includes controlling, by the server system 106, the set of device features for each connected smart device (e.g., the connected smart device 216a) based, at least in part, on the set of device management rules associated with the payment plan associated with each connected smart device. The set of device features is controlled based on a remote communication established between the device management portal 120 and the device management application 122 installed in each connected smart device.
[00194] FIG. 14 is a simplified block diagram of a payment server 1400, in accordance with an embodiment of the present disclosure. The payment server 1400 is an example of the payment server 118 of FIG. 1. A payment network may be used by the payment server 1400 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The payment server 1400 includes a processing system 1405 configured to extract programming instructions from a memory 1410 to provide various features of the present disclosure. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 1400 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof. In one embodiment, the payment server 1400 is configured to determine future server failures based on server logs processed within a particular time window. Via a communication interface 1415, the processing system 1405 receives information from a remote device 1420 such as one or more databases. The processing system 1405 is operatively coupled to the communication interface 1415 such that the payment server 1400 is capable of communicating with the remote device 1420 or of communicating with any entity connected to the network 110 (shown in FIG. 1) or any constituents of the server system 106. The payment server 1400 may also include a database 1425 to store transaction history of the plurality of users.
[00195] FIG. 15 is a simplified block diagram of a server system 1500, in accordance with an embodiment of the present disclosure. The server system 1500 shows hardware configuration of the server system 106. The server system 1500 includes a computer system 1502 and a database 1504. In an embodiment, the server system 1500 is integrated, but not limited to, in the issuer server 108 or in the payment server 118.
[00196] The computer system 1502 includes at least one processor 1506 configured to execute executable instructions for providing various features of the present disclosure. The processor 1506 is connected with other components of the computer system 1502 using a bus 1512. The executing instructions are stored in a memory 1508. The components of the computer system 1502 provided herein may not be exhaustive and the computer system 1502 may include more or fewer components than those depicted in FIG. 15. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 1502 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00197] The processor 1506 is operatively coupled to a communication interface 1510 such that the computer system 1502 is capable of communicating with a remote device 1516 such as the server system 106, or the payment server 118 associated with the payment network 116 or capable of communicating with any entity connected to the network 110 (shown in FIG. 1) or any constituents of the server system 106. In an embodiment, the processor 1506 may be capable of accessing the transaction data associated with the users from the database 1504.
[00198] In some embodiments, the database 1504 is integrated within the computer system 1502. For example, the computer system 1502 may include one or more hard disk drives as the database 1504. A storage interface 1514 is any component capable of providing the processor 1506 with access to the database 1504. The storage interface 1514 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 1506 with access to the database 1504.
[00199] FIG. 16 shows a simplified block diagram of a device 1600 for example, the administrator device 124 capable of implementing the various embodiments of the present disclosure. The device 1600 is depicted to include one or more applications 1606. The device 1600 is an example of the administrator device 124. It should be understood that the device 1600 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the device 1600 may be optional and thus in an example embodiment may include more, less, or different components than those described in connection with the embodiment of the FIG. 16. As such, among other examples, the device 1600 could be any of an electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00200] The illustrated device 1600 includes a controller or a processor 1602 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1604 controls the allocation and usage of the components of the device 1600 and support for one or more applications programs (see, applications 1606), such as an application interface in an administrator device (e.g., the administrator device 124) of the administrator 126 or an application interface in an administrator device (e.g., the administrator device 124).
[00201] In addition to the application interface, the applications 1606 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications such as USSD messaging or SMS messaging or SIM Tool Kit (STK) application) or any other computing application. In an example, the applications 1606 may include the device management portal 120.
[00202] The illustrated device 1600 includes one or more memory components, for example, a non-removable memory 1608 and/or removable memory 1610. The non-removable memory 1608 and/or removable memory 1610 may be collectively known as database in an embodiment. The non-removable memory 1608 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1610 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1604 and the applications 1606. The device 1600 may further include a user identity module (UIM) 1612. The UIM 1612 may be a memory device having a processor built in. The UIM 1612 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1612 typically stores information elements related to a mobile subscriber. The UIM 1612 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA7000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00203] The device 1600 can support one or more input devices 1620 and one or more output devices 1630. Examples of the input devices 1620 may include, but are not limited to, a touch screen/a screen 1622 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1624 (e.g., capable of capturing voice input), a camera module 1626 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1628. Examples of the output devices 1630 may include but are not limited to a speaker 1632 and a display 1634. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1622 and the display 1634 can be combined into a single input/output device.
[00204] A wireless modem 1640 can be coupled to one or more antennas (not shown in FIG. 16) and can support two-way communications between the processor 1602 and external devices, as is well understood in the art. The wireless modem 1640 is shown generically and can include, for example, a cellular modem 1642 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1644 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1646. The wireless modem 1640 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the device 1600 and a public switched telephone network (PSTN).
[00205] The device 1600 can further include one or more input/output ports 1650 for establishing connection with peripheral devices including a power supply 1652, one or more sensors 1654, for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the device 1600 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1656 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1660, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00206] With the application (see, applications 1606) and/or other software or hardware components, the device 1600 can implement the technologies described herein.
[00207] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for remote management of connected smart devices. A user interface (UI) is rendered on an administrator device to enable an administrator to access a device management portal. In addition, the administrator is enabled to access the device management portal to onboard one or more service providers. One or more connected smart devices are registered with each service provider of the one or more service providers. Each connected smart device is installed with a device management application and associated with a payment plan. The device management portal determines whether a payment transaction is not received from the device management application based at least on the payment plan. Upon determining that the payment transaction is not received from the device management application, a set of device features is controlled for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan. The set of device features is controlled based on a remote communication established between the device management portal and the device management application.
[00208] The disclosed methods with reference to FIGS. 1 to 16, or one or more operations of the method 1300 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM)), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00209] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00210] Particularly, the server system 1500 (e.g., the server system 106) and its various components such as the computer system 1502 and the database 1504 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00211] Various embodiments of the disclosure, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the disclosure has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the disclosure.
[00212] Although various exemplary embodiments of the disclosure are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
, Claims:CLAIMS
We claim:
1. A computer-implemented method, comprising:
rendering, by a server system, a user interface (UI) on an administrator device to enable an administrator to access a device management portal;
enabling, by the server system, the administrator to access the device management portal to onboard one or more service providers;
registering, by the server system, one or more connected smart devices with each service provider of the one or more service providers, each connected smart device installed with a device management application and associated with a payment plan;
determining, by the server system via the device management portal, whether a payment transaction is not received from the device management application based at least on the payment plan; and
upon determining that the payment transaction is not received from the device management application, controlling, by the server system, a set of device features for each connected smart device based, at least in part, on a set of device management rules associated with the payment plan, the set of device features controlled based at least on a remote communication established between the device management portal and the device management application.
2. The computer-implemented method as claimed in claim 1, wherein registering the connected smart device with the service provider, further comprising:
sending, by the server system via the device management portal, a device registration request to the device management application installed in the connected smart device; and
storing, by the server system via the device management application, a hardware configuration of the connected smart device in a device database.
3. The computer-implemented method as claimed in claim 2, wherein upon storing the hardware configuration of the connected smart device in the device database, further comprising:
sending, by the server system via the device management application, the device registration request to the service provider of the one or more service providers; and
receiving, by the server system, an acknowledgement message from the service provider in response to the device registration request.
4. The computer-implemented method as claimed in claim 1, wherein controlling the set of device features for each connected smart device, further comprising:
sending, by the server system via the device management portal, a device configuration update request to the device management application installed in the connected smart device; and
updating, by the server system via the device management application, a device configuration of the connected smart device in the device database.
5. The computer-implemented method as claimed in claim 4, wherein upon updating the device configuration of the connected smart device in the device database, further comprising:
sending, by the server system via the device management application, the device configuration update request to the service provider of the one or more service providers; and
receiving, by the server system, a response status from the service provider in response to the device configuration update request.
6. The computer-implemented method as claimed in claim 1, wherein the remote communication is established between the device management portal and the device management application based, at least in part, on the hardware configuration of each connected smart device.
7. The computer-implemented method as claimed in claim 1, further comprising:
generating, by the server system, a device profile for each connected smart device of the one or more connected smart devices, wherein the device profile comprises device information and payment information associated with each connected smart device.
8. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, the payment transaction associated with each connected smart device, wherein the payment transaction is received via the device management application.
9. The computer-implemented method as claimed in claim 1, wherein the set of device management rules is different for each of the one or more connected smart devices, wherein the set of device management rules is defined by the administrator.
10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.
| # | Name | Date |
|---|---|---|
| 1 | 202341006445-STATEMENT OF UNDERTAKING (FORM 3) [01-02-2023(online)].pdf | 2023-02-01 |
| 2 | 202341006445-POWER OF AUTHORITY [01-02-2023(online)].pdf | 2023-02-01 |
| 3 | 202341006445-FORM 1 [01-02-2023(online)].pdf | 2023-02-01 |
| 4 | 202341006445-FIGURE OF ABSTRACT [01-02-2023(online)].pdf | 2023-02-01 |
| 5 | 202341006445-DRAWINGS [01-02-2023(online)].pdf | 2023-02-01 |
| 6 | 202341006445-DECLARATION OF INVENTORSHIP (FORM 5) [01-02-2023(online)].pdf | 2023-02-01 |
| 7 | 202341006445-COMPLETE SPECIFICATION [01-02-2023(online)].pdf | 2023-02-01 |
| 8 | 202341006445-Proof of Right [22-02-2023(online)].pdf | 2023-02-22 |