CN116419228A

CN116419228A - Benefit denial system for unlocking electronic devices

Info

Publication number: CN116419228A
Application number: CN202310018713.XA
Authority: CN
Inventors: M·E·谢菲尔德; J·F·道格拉斯; P·M·西斯内罗斯; M·萨尔科西
Original assignee: Lowes Companies Inc
Current assignee: Lowes Companies Inc
Priority date: 2022-01-06
Filing date: 2023-01-06
Publication date: 2023-07-11
Also published as: CA3175770A1

Abstract

The technology described herein relates to systems and methods for issuing commands to electronic devices, and techniques for transferring device keys to user devices associated with users who have been authorized to issue commands to electronic devices. In some embodiments, the device key may be transmitted directly from the access device to the user device. In some embodiments, the device key may be transmitted to the user device by a mobile application server in communication with the user device upon receiving an indication that an operator of the user device is authorized to issue a command to the electronic device.

Description

Benefit denial system for unlocking electronic devices

Cross Reference to Related Applications

The present application is a continuation-in-part application of U.S. patent application Ser. No. 16/880,692, filed on even 21, 5, 2020, and U.S. patent application Ser. No. 16/880,692 is a continuation-in-part application of U.S. patent application Ser. No. 10,701,561, filed on even 31, 2020, which is hereby incorporated herein in its entirety for all purposes.

The present application is also a continuation-in-part application of U.S. patent application Ser. No. 16/894,591, filed on even 5 th 6/2020, and U.S. patent application Ser. No. 16/894,591 is a continuation-in-part application of U.S. patent application Ser. No. 10,721,224, filed on 31/1/2020, the entire contents of which are hereby incorporated herein by reference in their entirety for all purposes.

The present application is also a continuation-in-part application from U.S. non-provisional application No. 16/779,335, filed 1-31 in 2020, which is incorporated herein by reference in its entirety for all purposes.

Background

One of the biggest costs for retail participants is shrinkage (kringing). Shrinkage refers to any reduction in inventory available for sale and is typically caused by theft (e.g., shoplifting or employee theft), waste (e.g., breakage), vendor fraud, or error (e.g., accounting error). The average shrinkage loss for retail participants was about 2% of sales. According to national retail security surveys regarding retail theft, the loss of shrinkage in 2016 caused retailers to lose over 490 billion dollars.

While security measures that raise alarms, such as cameras and digital labels, help to reduce losses due to shrinkage, retailers are striving to further reduce losses. Some retailers choose to reduce the loss due to shrinkage by locking up high priced items that are typically the target of theft, so these items need to be retrieved by retail personnel before they can be purchased by the consumer. However, this solution places significant stress on retail personnel who may be too busy to retrieve the item. Furthermore, this solution may lead to consumer frustration and departure without completing the intended purchase when the consumer cannot find an employee that can retrieve the item. Locking products tends to inhibit sales and thus tends to negatively impact revenue.

Embodiments of the present invention address these and other problems, individually and collectively.

Disclosure of Invention

The following presents a simplified summary of some embodiments of the invention in order to provide a basic understanding of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some embodiments of the invention in a simplified form as a prelude to the more detailed description that is presented later.

The technology described herein relates to systems and methods for issuing commands (e.g., lock/unlock commands) to an electronic device, as well as techniques for transferring a device key (key) to a user device associated with a user that has been authorized to issue commands to the electronic device (e.g., by purchasing the electronic device). In some embodiments, the device key may be transmitted directly from an access device (e.g., point-of-sale (POS) device) to the user device. In some embodiments, the device key may be transmitted to the user device by a mobile application server in communication with the user device upon receiving an indication that an operator of the user device is authorized to issue a command (e.g., lock or unlock) to the electronic device.

According to embodiments of the systems described herein, each electronic device entering inventory of a resource provider (e.g., a retailer or other merchant) may include circuitry therein that is capable of limiting power to one or more components of the electronic device. In the introduction phase, the resource provider may initialize each electronic device by providing a unique device key (e.g., a device key associated only with the electronic device) recorded by the resource provider. The electronic device is then placed in a locked state that prevents the electronic device from being used. The only way to remove the electronic device from the locked state is to establish a communication session with the electronic device (e.g., via a separate user device) and issue an unlock command. However, the command is only executed by the electronic device if accompanied by the device key. In the described system, a mapping is maintained between each electronic device (e.g., via a device identifier) and its corresponding device key. Upon receiving an indication that the electronic device has been purchased, a purchase record is recorded and a device key is transmitted to the user device. In some cases, the device key is transmitted to a user device operated by an agent (agent) of the resource provider, which then unlocks the electronic device before it leaves the store. In some cases, the device key is transmitted to a user device operated by a purchaser of the electronic device, which is then able to issue commands (e.g., lock/unlock commands) to the electronic device.

One embodiment of the present disclosure relates to a method performed by a mobile application server, the method comprising: receiving an indication of an update to an authorization status of the electronic device, the indication comprising at least an identifier of the electronic device; identifying a device key associated with the electronic device, the device key being associated with the electronic device only; determining a user device associated with an update to an authorization status of the electronic device; and transmitting a device key to the user device, the device key being usable by the user device to issue a command to the electronic device.

Another embodiment of the present disclosure is directed to a mobile application server comprising a processor and a memory, the memory comprising instructions that when executed by the processor cause the mobile application server to at least: the method includes receiving an indication of an update to an authorization status of the electronic device, identifying a device key associated with the electronic device, determining a user device associated with the update to the authorization status of the electronic device, and transmitting the device key to the user device, the device key being usable by the user device to issue a command to the electronic device.

Yet another embodiment of the present disclosure is directed to a user equipment, comprising: a processor; and a memory comprising instructions that, when executed by the processor, cause the user equipment to: the method includes receiving at least an indication of an electronic device identifier, receiving a device key associated with the electronic device identifier and storing the device key in a memory in association with the electronic device identifier, and establishing a communication session with an electronic device associated with the electronic device identifier and issuing a command to the electronic device via the communication session, the command including at least the device key.

For a fuller understanding of the nature and advantages of the present invention, reference should be made to the following detailed description taken together with the accompanying figures.

Drawings

Embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

FIG. 1 depicts an illustrative overview of an example system in which an unlocking operation may be accomplished in accordance with at least some embodiments;

FIG. 2 depicts an example system architecture for a system that may be implemented to perform the functions described in accordance with at least some embodiments;

FIG. 3 depicts a process for sending and using a device key to issue commands to an electronic device in accordance with at least some embodiments;

FIG. 4 depicts an illustrative example of interactions that may occur using an embodiment of the system described herein;

FIG. 5 depicts a first illustrative example of user interaction enabled via a mobile application graphical user interface executing on a user device in accordance with at least some embodiments;

FIG. 6 depicts a second illustrative example of user interaction enabled via a mobile application graphical user interface executing on a user device in accordance with at least some embodiments;

FIG. 7 depicts a third illustrative example of user interaction enabled via a mobile application graphical user interface executing on a user device in accordance with at least some embodiments;

FIG. 8 depicts a flowchart that shows a process for updating an authorization status of an electronic device and providing a device key to a user device in accordance with at least some embodiments;

FIG. 9 depicts a simplified block diagram of a benefit denial system for an electronic device in accordance with at least some embodiments;

FIG. 10 depicts a simplified block diagram of an electronic device including a benefit denial chip in accordance with at least some embodiments;

FIG. 11 depicts a flow diagram illustrating a process for selectively denying power to an electronic device in accordance with at least some embodiments;

FIG. 12 depicts an illustrative overview of an example system in which a device key that can be used to issue commands to an electronic device can be sent between user devices in accordance with at least some embodiments;

FIG. 13 depicts an example system architecture for a system that may be implemented to perform the functions described in accordance with at least some embodiments;

FIG. 14A depicts a state prior to transferring command execution rights of an electronic device;

FIG. 14B depicts states during and after transfer of command execution rights of an electronic device;

FIG. 15 depicts an example ownership registry with respect to an electronic device implementation, which may be in accordance with at least some embodiments of the present disclosure;

FIG. 16 depicts a process for transferring device keys between accounts in accordance with at least some embodiments;

FIG. 17 depicts a flowchart of a process for granting access rights for an electronic device from a first user device to a second user device in accordance with at least some embodiments;

FIG. 18 depicts a flowchart of a process for obtaining, at a first user device, access rights for an electronic device from a second user device, in accordance with at least some embodiments;

FIG. 19 depicts a flowchart that shows a process for electronic device rental, in accordance with at least some embodiments;

FIG. 20 depicts a simplified block diagram of a benefit denial system for an electronic device in accordance with at least some embodiments;

FIG. 21 depicts a process for sending and using a device key to issue a command to an electronic device in accordance with at least some embodiments;

FIG. 22 depicts another process for sending and using a device key to issue a command to an electronic device in accordance with at least some embodiments; and

fig. 23 depicts a flowchart that shows a process for sending and using a device key to issue a command to an electronic device in accordance with at least some embodiments.

Detailed Description

In the following description, various embodiments of the present invention will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiments being described.

FIG. 1 depicts an illustrative overview of an example system in which an unlocking operation may be accomplished in accordance with at least some embodiments. In fig. 1, the electronic device 102 may be capable of establishing communication (via a wireless connection or via a physical connection) with the access device 104 and the user device 106. The access device 104 and/or the user device 106 may further be capable of establishing communication with the mobile application server 108.

The electronic device 102 may be any suitable device that electronically accomplishes its purpose. The electronic device 102 may have installed therein electronic circuitry that enables it to be locked and/or unlocked. In some embodiments, electronic circuitry may be installed between the power source and other components of the electronic device 102 configured to perform certain functions such that the electronic circuitry is able to limit or interrupt power to those components. At least a portion of the electronic circuit may include a secure element that includes encrypted data that cannot be readily accessed outside of the secure element. One or more device keys may be stored within this secure element of the electronic circuit. As described herein, an electronic device may be a dedicated device having primary functionality, such as a device designed to perform a particular task. The special purpose devices may include systems or devices designed for limited use in a particular problem area. The special purpose device may also be a computing device with specific programming that causes the computing device to perform at least one specific task, such that the computing device is a special purpose device. Examples of specialized equipment include power tools (e.g., corded or cordless screwdrivers, routers, screwdrivers, drills, saws (saw), staplers, compressors, impact wrenches and drivers, grinders, adhesive dispensers, etc.), battery chargers, drones, cameras, outdoor power equipment (e.g., corded or cordless hedge trimmers, string trimmers, edgers, blowers, mowers, generators, chainsaws, etc.). The operations or tasks performed by these examples are beyond the scope of computing and processing information alone, and thus, work done far beyond that which can be done using a purely general purpose computer, among others.

One or more device keys may be stored within this secure element of the electronic circuit. The secure element may comprise a cryptographic processor, which is a dedicated microprocessor designed to perform cryptographic operations. Such cryptographic processors are typically embedded in packages having a variety of physical security measures that impart a degree of tamper resistance to the cryptographic processor. The secure element may have stored thereon a cryptographic key (e.g., a private cryptographic key) that may be used to encrypt or decrypt sensitive data received by the cryptographic processor. As will be recognized by those skilled in the art after review of this disclosure, packets encrypted in a two-key system using a public cryptographic key associated with a cryptographic processor can only be decrypted using a private cryptographic key.

The electronic device 102 may be configured to perform a number of functions. In some embodiments, the electronic circuitry may be configured to limit or interrupt, either individually or as a group, certain of the plurality of functions that may be performed by the electronic device 102. Some illustrative examples of electronic devices having electronic circuitry as described herein are described in more detail with reference to U.S. patent application No. 16/779,335 entitled "benfitt DENIAL SYSTEM FOR SELECTIVELY PREVENTING OPERATION OF POWER TOOLS (BENEFIT denial system FOR selectively preventing operation of a power tool)", which is incorporated herein by reference in its entirety FOR all purposes. In some embodiments, the electronic circuitry may operate using a power source separate and/or distinct from the power source of the electronic device 102 itself (hereinafter referred to as a "stand-alone power source"), thereby enabling the operation to be performed using the electronic circuitry even if the electronic device 102 is not powered on (e.g., disconnected from its power source). For example, if the electronic device 102 is a cordless drill with a removable and replaceable rechargeable battery adapted to power the drilling function, a power source (e.g., a compact battery, such as a watch battery) separate and/or distinct from the rechargeable battery may be included in the drill and used to power the electronic circuitry when the rechargeable battery is removed from the drill. In some cases, the independent power source may be recharged by drawing power from the power source of the electronic device 102. In some embodiments, the electronic circuitry may include an induction coil that enables the electronic circuitry to be remotely powered in order to perform the operation.

The access device 104 may be any suitable device capable of managing access to the electronic device 102. In some embodiments, the access device 104 may be a point-of-sale (POS) terminal that is operated by or on behalf of a resource provider (e.g., a merchant) to provide access to goods and/or services. In some embodiments, the access device 104 may include a communication interface configured to interact with other devices (e.g., the electronic device 102, the user device 106, and/or the mobile application server 108). In some embodiments, the access device 104 may include specialized equipment capable of interacting with the electronic device 102. For example, the access device may include an inductive coil that is capable of remotely powering the electronic device 102 to allow the electronic device 102 (e.g., electronic circuitry of the electronic device 102) to perform operations even when a power source that typically powers the electronic device 102 during operation is not electrically connected to the electronic device 102.

User device 106 may be any electronic device capable of establishing a communication session with another device and transmitting/receiving data from the device. The user device 106 may include the capability to download and/or execute mobile applications. User devices may include mobile communication devices, personal computers, and thin user devices (thin-user devices). As illustrative examples, the user device may be a smart phone, a Personal Data Assistant (PDA), or any other suitable handheld device.

In some embodiments, the user device 106 may include a communication interface configured to enable communication between the user device and another electronic device (e.g., the mobile application server 108, the access device 104, the electronic device 102, and/or a wireless router that manages access to a network). Examples of suitable communication interfaces may include Radio Frequency (RF) transceivers configured to transmit and receive communications using Near Field Communication (NFC) or other radio frequency or wireless communication protocols, such as bluetooth, bluetooth Low Energy (BLE), wireless local area network (e.g., wiFi), iBeacon, etc. A second example of a suitable communication interface may include an optical input device capable of obtaining graphical input, such as a camera device or a bar code reader. In this second example, the user device 106 may be presented with a machine-readable code that may be scanned using an optical input device to obtain data encoded into the machine-readable code. In some embodiments, the communication interface may include both long-range and short-range communication devices. For example, the communication interface may include an antenna configured for connection to a cellular network in order to enable communication with various other components of the depicted architecture.

Mobile application server 108 may be any computing device configured to provide remote support for user device 106. The mobile application server 108 may be associated with a set of computer-executable instructions to be installed on the user device 106 (e.g., mobile application) and executed from the user device 106 (e.g., mobile application). Mobile application server 108 may provide any suitable services and/or processing for user devices. For example, mobile application server 108 may perform calculations on behalf of a user device. In some embodiments, the mobile application server may maintain accounts for one or more users. The mobile application server 108 may also store any protocols and/or user preferences related to the operation of the user device.

The mobile application server 108 may be comprised of any computer or cluster of computers. For example, mobile application server 108 may be a mainframe, a small computer cluster, or a group of servers functioning as a unit. In one example, mobile application server 108 may be a database server coupled to a web server. The mobile application server 108 may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing requests from one or more client computers (e.g., access device 104 and/or user device 106). Mobile application server 108 may comprise one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

In some embodiments, at least a portion of the functions performed by the mobile application installed on the user device 106 and executed from the user device 106 may be performed by a mobile application server 108 in communication with the mobile application. For example, in executing a mobile application, the user device 106 may establish a communication session with the mobile application server 108 in which the mobile application server 108 performs at least some of the processing on behalf of the mobile application. In some embodiments, mobile application server 108 may maintain an account associated with the user device and/or its user. The account maintained by mobile application server 108 may store a plurality of data elements related to the user. For example, the application server may store user data, information regarding ownership of an item (e.g., an electronic device), or any other suitable data. Additionally, mobile application server 108 may maintain a mapping of device keys to electronic devices. The application server may automatically (e.g., without manual interaction) identify a device key associated with the electronic device 102 and associate the device key with the user's account upon receiving an indication that the user purchased the electronic device 102. The mobile application server may also automatically identify the user device 106 as being associated with the user (via stored user data) and may send a device key to the user device 106 (e.g., via a push notification). In some embodiments, the device key, once received by the user device 106, May be used to communicate over a communication channel (e.g., bluetooth ^TM ) Interact with the electronic device 102 (e.g., to issue a lock command and/or an unlock command). In some embodiments, the device key may be usable only by mobile applications installed on the user device 106.

The device key may be any suitable string that can be used to authorize an operation (e.g., a lock or unlock operation) with respect to the electronic device 102. The device key may be unique to a particular electronic device. In other words, each electronic device may be associated with a different device key. In some embodiments, the device key may be a random or pseudo-random string such that the device key cannot be easily derived from information related to the electronic device. In some embodiments, the device key may be derivable from an identifier of the electronic device. In these embodiments, the device key may be generated independently by any entity (e.g., an entity that owns the electronic device) that has prerequisite information and access to an algorithm (which may be secret) used to generate such device key. For example, in some embodiments, a device key may be derived for a particular electronic device by applying a hash function to an identifier of the particular electronic device. In this example, the identifier of the electronic device may correspond to a Universal Product Code (UPC) and a serial number or other identifier. Some electronic devices may include an indication of their respective identifiers (e.g., within a bar code or other machine readable code associated with the electronic device). As described further below, a bar code or other machine readable code indicating a UPC may have an extended format to include an indicator (e.g., a number) that distinguishes a particular item from other identical items associated with the same UPC in addition to the indicator of the UPC. This additional indicator (in addition to the UPC) may include, for example, at least a portion of the item serial number or the entire serial number. For the purposes of this disclosure, the term "extended UPC" refers to a UPC that is extended by the addition of such an indicator and that may be represented by a bar code or other machine readable code that represents both the UPC and the additional indicator. The extended UPC may be associated with a device key at the mobile application server 108. In this manner, the mobile application server 108 may receive the extended UPC during the transaction (e.g., during the sale, where the extended UPC may be received from the access device 104) and determine a device key for the transaction based on the association (e.g., to send to the access device 104 and/or the user device 106 after payment is received and before or after the sale is completed). Completion of the sale (or transaction) may be defined by any indication that the sale (or transaction) has been completed, such as printing a receipt at the POS, displaying a "transaction complete" or similar message at the POS, and/or causing the receipt to be electronically transmitted to the user/purchaser (e.g., via email).

As described further below, dynamic data elements may be used in addition to or instead of using device keys for locking or unlocking operations. The dynamic data element data may include expiration time/date of the lease of the electronic device 102 and/or check data for authenticating owners of the electronic device 102, such as a counter value that is incremented with each owner.

The locking or unlocking operation uses the unlocking information. In an example, the unlock information includes a device key. In another example, the unlocking information includes a dynamic data element. In yet another example, the unlock information includes both a device key and a dynamic data element. In general, the unlock information may include any information that may be used by the electronic device 102 to verify ownership or proper possession thereof. Based on the unlocking information, if ownership and proper possession are verified, the electronic device 102 may unlock at least one of its functions so that the function is activated and becomes operational. Otherwise, the electronic device 102 may lock at least one function or maintain the function in a locked state (e.g., deactivated and/or inoperable).

Different techniques may be used to generate the unlock information. In one example, the unlock information includes a device key. In this example, the unlock information may be generated remotely (e.g., at the mobile application server 108) and sent to the electronic device 102 or loaded at the electronic device 102. In this way, the electronic device 102 stores the unlock information. As described further herein, the device key may also be variable. For example, the device key may change upon transfer of ownership and/or may be updated automatically (e.g., updated periodically). The electronic device 102 may receive copies of the device key over time, where each copy is received at a different time and may be different from the other copy. Additionally or alternatively, the unlocking information includes a dynamic data element. In this example, the dynamic data element may be dynamically generated over time (e.g., at mobile application server 108) such that the element may be variable. Here again, the electronic device 102 may receive copies of the dynamic data element over time, where each copy is received at a different time and may be different from the other copy. In yet another example, the unlock information need not be stored at the electronic device 102. Instead, the electronic device 102 may receive the unlock information (e.g., during an unlock procedure) and verify the received information. For example, the unlock information is data encrypted with a public encryption key of the electronic device 102, and is transmitted to the electronic device in an encrypted packet (packet). If the electronic device 102 successfully decrypts the encrypted packet using its private encryption key, the electronic device 102 may extract the unlock information therefrom. In this example, the unlock information may be any random data or may be specific data (e.g., a serial number of the electronic device 102 or a portion thereof). In another example, instead of using encryption, a hash function is used. Specifically, the unlocking information includes random data or specific data. The data is hashed according to a first hashing (hashing) function, resulting in first hashed data. The hashed data and random data or specific data (as the case may be) are sent to the electronic device 102. Here, the electronic device 102 may hash (as the case may be) the random data or the specific data using a second hash function, resulting in second hashed data. The first hashed data and the second hashed data may be compared and if the two hashed functions are the same and the received random data or the specific data is the same as the original data, the first hashed data and the second hashed data will match.

Verification of ownership or possession may use different techniques that may depend on the type of unlocking information. In general, the electronic device 102 determines first unlock information (e.g., unlock information stored in its memory or generated instantaneously) and compares the first unlock information to second unlock information (e.g., received from another device, such as the access device 104, the user device 106, or a beacon device as further shown in the following figures). If there is a correspondence between the two pieces of information, the electronic device determines that ownership is valid or possession is proper. Otherwise, the electronic device 102 determines that ownership is invalid or unoccupied. The correspondence may be an exact match, a fuzzy match or an algorithmic association between the two pieces of information.

To illustrate, the electronic device 102 stores the first unlock information. At some point, the electronic device 102 receives the second unlock information from another device (e.g., the access device 104, the user device 106, or a beacon device as further shown in the following figures). The electronic device 102 compares the two pieces of information and completes the verification depending on whether the comparison indicates a match or correspondence between the first unlock information and the second unlock information.

In another example, the electronic device 102 need not store unlock information and/or any unlock information stored or generated by the electronic device 102 may be different from unlock information received by the electronic device 102 from another device during an unlock procedure. In this example, the electronic device receives second unlock information from another device and, in response, generates first unlock information for comparison with the second unlock information to complete the verification. For example, the second unlock information may include an expiration time/date. The electronic device 102 may determine the current time/date as the first unlock information. If the expiration time/date has not elapsed given the current time/date, the electronic device 102 determines that ownership is valid or in possession is authentic. Similarly, the second unlock information includes an encrypted packet of the serial number of the electronic device 102. Here, the electronic device 102 decrypts the encrypted packet using its private encryption key to extract the sequence number. The electronic device 102 compares the extracted serial number with its own serial number (which is used as the first unlock information). If the two match, the electronic device 102 determines that ownership is valid or possession is authentic. In yet another example, the second unlocking information includes a second hash and random data or specific data. The electronic device 102 generates a first hash of the random data or the specific data and compares the first hash to a second hash. If the two hashes match (based on exact or fuzzy matches), the electronic device 102 determines that ownership is valid or possession is authentic.

For clarity of explanation, various embodiments are described herein by way of example using a device key that is stored at the electronic device 102 and compared to an exact match with the received key. However, embodiments are not so limited and are applicable to any type of unlock information, to storing or generating instant unlock information, and to any type of comparison.

In some embodiments, the device key stored in the electronic device 102 may be changed or varied. For example, the purchaser of the electronic device 102 may replace or overwrite an existing device key with a new device key after completing the purchase of the electronic device and receiving the device key. The replacement device key may be his or her choice, or it may be random. Note that the operation of replacing or overriding an existing device key may require the provision of the current device key. In some embodiments, the electronic device 102 may include a plurality of device keys, each of which may be specific to the electronic device 102. For example, a single electronic device 102 may include two separate device keys, wherein a first device key may be provided to a purchaser of the electronic device 102 (and the first device key may be replaced) and a second device key may be stored by the resource provider and/or the mobile application server 108 without being provided to the purchaser (i.e., the master key).

In some embodiments, the electronic device 102 may be initially in an unlocked state when no device key is assigned to the electronic device 102. The electronic device may be configured to be locked after receiving and storing the initial device key. In an exemplary system in which an electronic device is sold by a resource provider, the resource provider, upon receiving the electronic device 102 from the manufacturer into inventory, may select a device key to be associated with the electronic device. The resource provider may then provide the device key to the electronic device 102, which the electronic device 102 may subsequently initiate a locking operation using. The device key may then be provided to the mobile application server 108, where the device key may be stored in association with an identifier of the electronic device 102. In such a system, any electronic device 102 placed on a shelf or offered for sale by a resource provider may be in a locked state when it is exposed to a potential purchaser. In this way, the electronic device may become inoperable until an unlocking operation is performed using the correct device key. Such a system brings out (devive) a thief with any benefit that may be derived from theft of the electronic device 102.

By showing interactions between various components of the systems described herein, consider the following scenario. The user may enter a retail location where at least one embodiment of the described system is implemented. In this scenario, the user may select the electronic device 102 for purchase and may take the electronic device to a POS terminal (e.g., access device 104) to complete the purchase. Upon receiving payment and/or completing a transaction (e.g., at a POS terminal), the electronic device 102 may be unlocked using the device key. In one example, the electronic device 102 is unlocked after payment is received and the transaction is completed. In another example, the electronic device 102 is unlocked after payment is received and before the transaction is completed. In this example, completion of the transaction may be conditioned on the electronic device 102 being successfully unlocked.

In one potential scenario, the access device 104 may provide the device key directly to the electronic device 102 at step S110. The access device 104 may directly access a device key associated with the electronic device 102 or it may need to perform a lookup operation. In some embodiments, this may involve sending a request to mobile application server 108 to obtain a device key. In some embodiments, the access device 104 may include a short-range wireless communication apparatus capable of transmitting device keys and unlocking commands to the electronic device 102. In some embodiments, the access device 104 may include an inductive coil that may temporarily and remotely (e.g., in a contactless and/or wireless manner) power the electronic device 102 (e.g., the aforementioned electronic circuitry of the electronic device 102) such that device key and unlock commands may be provided to the electronic device 102 even if a power source (e.g., a rechargeable battery) that normally powers operation of the electronic device 102 is not electrically connected to the electronic device 102 during use. It should be noted that in some embodiments, step S110 may be performed even if the device key is provided to the user using other means as described below.

In another potential scenario, the access device 104 may provide the device key directly to the user device 106 at step S112. In some embodiments, the device key may be sent directly to the user device 106 via wireless transmission. In some embodiments, the device key may be encoded as a machine-readable code (e.g., a bar code or Quick Response (QR) code) that is printed on a receipt generated by the access device 104. In this scenario, the user device 106 may obtain the device key after scanning the machine-readable code using a camera or a bar code reader. In some embodiments, the user device 106 may subsequently provide the device key (and the identifier of the electronic device 102) to the mobile application server 108 (e.g., via a mobile application executing from the user device 106), and the mobile application server 108 may associate the device key with an account maintained for the user.

In yet another potential scenario, the access device 104 may provide the device key to the mobile application server 108 at step S114, and the mobile application server 108 may then provide the device key to the user device 106 at step S116. In some embodiments, the user may be prompted to enter a user identifier that may be used to identify and/or contact the user. In some embodiments, the user may present a loyalty (loyalty) identifier that may be used to identify the user account maintained by the mobile application server 108. Upon identifying the account associated with the user, mobile application server 108 may associate an identifier of electronic device 102 and its corresponding device key with the identified account. Additionally, the mobile application server 108 may identify one or more user devices 106 associated with the identified account and may push device keys to those user devices 106.

In some embodiments, the user may provide an email address, a telephone number, or other contact information that may be used to initiate contact with the user using the device key. For example, after the user provides an email address, mobile application server 108 may send an email message to the user that includes the device key or a link that may be used to gain access to the device key. In another example, after the user provides the telephone number, a Short Message Service (SMS) message including the device key may be sent to the user, which may be received on the user device 106.

Once the user device 106 has received the device key associated with the electronic device 102, an operation may be performed at step S118. To this end, a communication session may first be established between the user device 106 and the electronic device 102 (e.g., via a short-range wireless communication channel). Once established, the communication session may be used to communicate commands from the user device 106 to the electronic device 102 along with the device key. In some embodiments, the device key may be encrypted or otherwise hidden during its transmission. Upon receiving the device key, the electronic device 102 may be further configured to compare the received device key with the device key stored in the memory. If the device keys match, the electronic device 102 may execute the received command. If the device keys do not match, the electronic device 102 may not be able to execute the received command. In some embodiments, if the received device key does not match a device key stored in memory of the electronic device 102, the electronic device 102 may also return an error indication to the user device 106 via the communication channel. In some embodiments, the user device 106 may be operated by a consumer or purchaser of the electronic device 102. In some embodiments, the user device 106 may be operated by an agent or employee of the resource provider such that the agent is then able to unlock the electronic device 102 before the electronic device 102 leaves the retail location.

For clarity, a specific number of components are shown in FIG. 1. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include fewer or more than all of the components shown in FIG. 1. Furthermore, the components in FIG. 1 may communicate via any suitable communication medium (including the Internet) using any suitable communication protocol.

FIG. 2 depicts an example system architecture for a system that may be implemented to perform the functions described in accordance with at least some embodiments. As depicted in fig. 2, an exemplary architecture may include an electronic device 102, an access device 104, a user device 106, and a mobile application server 108, as described above with respect to fig. 1. One or more of these components may communicate directly or through a network 201.

Mobile application server 108 may be any type of computing device configured to perform at least a portion of the functions described herein. In some embodiments, mobile application server 108 may be executed by one or more virtual machines implemented in a hosted computing environment. The hosted computing environment may include one or more rapidly provisioned and released computing resources, where the computing resources may include computing devices, network devices, and/or storage devices. The hosted computing environment may also be referred to as a cloud computing environment.

In one illustrative configuration, mobile application server 108 may include at least one memory 202 and one or more processing unit(s) (or processor (s)) 204. The processor(s) 204 may be suitably implemented in hardware, computer-executable instructions, firmware, or a combination thereof. The computer-executable instructions or firmware implementations of the processor(s) 204 may include computer-executable instructions or machine-executable instructions written in any suitable programming language to perform the various functions described. The mobile application server 108 may also include an additional storage device (storage) 206.

The memory 202 may store program instructions that are loadable and executable on the processor(s) 204, as well as data generated during execution of these programs. Depending on the configuration and type of mobile application server 108, memory 202 may be volatile (such as Random Access Memory (RAM)) and/or nonvolatile (such as Read Only Memory (ROM), flash memory, etc.). The mobile application server 108 may also include additional storage devices 214, such as removable storage devices or non-removable storage devices, including, but not limited to, magnetic storage devices, optical disks, and/or tape storage devices. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device. In some implementations, the memory 202 may include a plurality of different types of memory, such as Static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), or ROM. Turning in more detail to the contents of the memory 202, the memory 202 may include an operating system 208 and one or more applications or services for implementing the features disclosed herein, including at least a module (key management module 210) for maintaining a mapping between device keys and accounts and distributing device keys to appropriate user devices. The memory 202 may also include device key data 212 and user account data 214, the device key data 212 providing a mapping of device keys to specific electronic devices, the user account data 214 providing information related to the user and user account (e.g., demographic data and user devices, associated electronic devices, etc.). In some embodiments, the device key data 212 and/or the user account data 214 may be stored in a database.

Memory 202 and additional storage 206, both removable and non-removable, are examples of computer-readable storage media. For example, computer-readable storage media may include volatile or nonvolatile, removable or non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. As used herein, a module may refer to a programmed module executed by a computing system (e.g., a processor) installed on mobile application server 108 and/or executed from mobile application server 108. The mobile application server 108 may also contain communication connection(s) 216 that allow the mobile application server 108 to communicate with a stored database, another computing device or server, a user terminal, and/or other components of the described system. The mobile application server 108 may also include input/output (I/O) device(s) and/or ports 218, such as for example, for connection to a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, and the like.

In some embodiments, the key management module 210 may be configured to provide, in conjunction with the processor 204, a device key to a user device determined to be associated with the electronic device. In some embodiments, the mobile application server 108 may receive an indication (e.g., a purchase or registration notification) that the particular electronic device 102 is now associated with a particular user account. Upon receiving the indication, the key management module 210 may create an association between the electronic device and the account. The key management module 210 may also identify one or more user devices 106 associated with the indicated user account from the user/account data 214. The key management module 210 may also identify a device key associated with the indicated electronic device 102 from the device key data 212. The key management module 210 may then send the identified device key to the identified one or more user devices 106. In some embodiments, this may be achieved via push notifications.

In some embodiments, the user device 106 may include any portable electronic device capable of performing the functions attributed to the user device 106 disclosed herein. The user device 106 may include a memory 220 (e.g., a computer-readable storage medium) storing instructions that, when executed by a processor 222 of the user device 106, enable the user device to perform its intended functions. Turning in more detail to the contents of the memory 220, the memory 220 may include an operating system 224 and at least one mobile application 226, the operating system 224 providing executable program instructions for general management and operation of the user device 106, the at least one mobile application 226 being configured for causing the user device 106 to communicate with the mobile application server 108 in order to receive and utilize device keys. Memory 224 may include a plurality of device keys 228 associated with the electronic device. Additionally, the user device 106 may include a plurality of communication connections 229, the plurality of communication connections 229 enabling the user device 106 to communicate with other electronic devices. Communication connection 229 may include a wireless or direct physical connection. Additionally, the wireless connection may include any combination of short-range or long-range wireless protocols.

The mobile application 226 may be configured to, in conjunction with the processor 222, cause the user device 106 to issue commands to the electronic device 102 using a device key associated with the electronic device 102. In some embodiments, the mobile application 226 may include a Graphical User Interface (GUI) that enables a user to interact with the mobile application 226. The mobile application 226 may present one or more of a list of devices detected by the user device 106, a list of electronic devices associated with the user (e.g., electronic devices for which the user device 106 has received a device key), a current state of one or more electronic devices, and/or commands available to the electronic devices to the user of the user device 106 via the GUI. The mobile application 226 may be configured to receive user input via the GUI and issue commands to the electronic device based on the received user input. For example, the user may select an option to lock or unlock a particular electronic device via the GUI. In this example, the mobile application 226 may cause the user device 106 to send a corresponding lock or unlock command to the electronic device 106, the command including a device key of the electronic device. In some embodiments, the mobile application 226 may receive a status update of the electronic device 102 in response to the sent command.

The electronic device 102 may be any suitable electronic device (such as the electronic devices described above) having electronic circuitry 230 as described herein mounted therein. As described elsewhere, the electronic circuitry 230 may be functionally mounted between the power source and other components of the electronic device 102 configured to perform certain functions such that the electronic circuitry 230 is able to limit or prevent power to those components in order to manage the ability of the electronic device 102 to perform the function (i.e., selectively enable or disable aspects of the electronic device 102 or its functions). At least a portion of the electronic circuitry 230 may include a secure element 232, the secure element 232 including encrypted memory. One or more device keys may be stored within secure element 232 of electronic circuitry 230. In some embodiments, a processor within electronic circuitry 230 (and possibly within secure element 232) may be capable of decrypting device key information in order to process commands received from user device 106. Additionally, the electronic device 102 may include a plurality of communication connections 234, the plurality of communication connections 234 enabling the electronic device 102 to communicate with other devices. The communication connection 234 may include a wireless or direct physical connection. Additionally, the wireless connection may include any combination of short-range or long-range wireless protocols.

The access device 104 may be any suitable device capable of managing access to the electronic device 102. More specifically, the access device 104 may manage access to device keys that may be used to issue commands to the electronic device 102. As described elsewhere, the access device 104 may be a point-of-sale (POS) terminal capable of conducting transactions associated with an electronic device. The access device 104 may include a plurality of communication connections 236, the plurality of communication connections 236 enabling the access device 104 to communicate with other devices. Communication connection 236 may include a wireless or direct physical connection. Additionally, the wireless connection may include any combination of short-range or long-range wireless protocols.

In some embodiments, the access device 104 may be configured to provide the device key directly to the user device after receipt of the payment, and before or after completion of the transaction. This may first require the access device to communicate with the mobile application server 108 to retrieve the device key. To this end, the access device 104 may provide the identifier of the electronic device 102 and an indication that the electronic device 102 has been purchased to the mobile application server 108. The access device 104 may then receive the device key in a response from the mobile application server 108. The access device 104 may then provide the device key to the user device 106. In some embodiments, this may involve encoding the device key as a machine readable code and printing the machine readable code onto the receipt. In some embodiments, this may involve establishing a wireless communication session between the access device 104 and the user device 106, and sending the device key to the user device 106 via the communication session.

In some embodiments, the access device 104 may be configured to cause the mobile application server 108 to provide the device key to the user device 106 after payment is received, and before or after the transaction is completed. To this end, the access device 104 may provide the user identifier as well as the identifier of the electronic device 102 to the mobile application server 108. For example, the access device 104 may be configured to collect user identifiers (e.g., email addresses, loyalty identifications, account identifiers, phone numbers, credit card numbers, etc.) via user input regarding sales of the electronic device 102. This may involve the user manually entering an identifier or having some identification device (e.g., a loyalty card or fob) in communication with the access device 104 (e.g., via a Radio Frequency Identifier (RFID) tag, reading a magnetic medium, or optically reading a bar code or QR code). Once the access device obtains the user's identifier, the access device 104 may send the identifier to the mobile application server 108 along with the identifier of the electronic device 102. Upon receiving the identifier from the access device 104, the mobile application server 108 may identify an account associated with the user via the identifier, identify a device key associated with the electronic device 102, identify the user device 106 associated with the account, and send the device key to the user device 106.

In some embodiments, the communication network 201 may include any one or combination of many different types of networks, such as a cable network, the internet, a wireless network, a cellular network, and other private and/or public networks. Further, the communication network 201 may include a plurality of different networks. For example, the user device 106 may communicate with a wireless router using a 4/5G network, which may then route the communication to the mobile application server 108 over a public network (e.g., the internet).

Fig. 3 depicts a process for sending and using a device key to issue a command to an electronic device 102 in accordance with at least some embodiments. Some or all of process 300 (or any other process described herein, or variations and/or combinations thereof) may be performed under control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). According to an embodiment of the present disclosure, the process 300 of fig. 3 may be performed by at least the access device 104, the electronic device 102, the mobile application server 108, and the user device 106 shown in fig. 2. The code may be stored on a computer readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer readable storage medium may be non-transitory. As depicted in fig. 3, process 300 may involve a separate variation, where two exemplary variations of process 300 (variation 1 and variation 2) are described. However, it should be noted that other variations of process 300 that are within the spirit of the present disclosure will be apparent to those skilled in the art after reading the present disclosure.

The process 300 may begin at 302 when the access device 104 receives an indication that ownership rights in the electronic device 102 should be transferred to a user. In some embodiments, this may be due to the sales of the electronic device 102 being completed at the access device 104. In some embodiments, the access device 104 may obtain user information related to sales. For example, the access device 104 may collect loyalty (or other account) identifiers, phone numbers, email addresses, or some other suitable means for identifying the user.

In some embodiments, the access device 104 may be configured to send an unlock command to the electronic device 102 at 304. For example, after receiving payment, but before or after sales of the electronic device 102 are completed, the access device 104 may be configured to establish communication with circuitry within the electronic device 102 and provide an unlock command for the electronic device 102 and a device key to cause it to unlock the electronic device 102. In some cases, this may further involve the access device 104 retrieving the device key of the electronic device 102 from the mobile application server 108.

In an embodiment of the first variation (variation 1) of the process 300, the access device 104 may transmit registration information to the user device 106, which enables the user to obtain the device key of the electronic device at 306. Registration information may be communicated to user device 106 via a number of different techniques. In some embodiments, the registration information may be encoded into a machine-readable code that is presented to the user device 106 by the access device 104. In some embodiments, the access device 104 may establish a communication session with the user device 106 and may communicate registration information over the communication session. In some embodiments, the registration information may include a device key. In some embodiments, the registration information may include an identifier of the electronic device 102 or an identifier of the transaction conducted at 302.

Upon receiving the registration information, the user device 106 may transmit at least a portion of the registration information to the mobile application server 108 at 308. Additionally, the user device 106 may transmit a user identifier to the mobile application server 108 at 308.

After registration information and a user identifier are received at mobile application server 108, mobile application server 108 may identify an account associated with user device 106 based on the received user identifier at 310. At this step, mobile application server 108 may also identify one or more electronic devices 102 associated with the account based on the received registration information. The mobile application server 108 may further make a determination as to whether one or more electronic devices 102 are legally obtained (e.g., legally sold) at the time. In some embodiments, once one or more electronic devices are identified and the electronic device 102 is confirmed to have been legally sold or otherwise legally obtained, the mobile application server 108 may link the electronic device 102 to the identified account.

Once the device keys of the electronic device 102 have been identified, the mobile application server 108 may send these device keys to the user device 106 at 312. The mobile application installed on the user device 106 and executed from the user device 106 may then store the device key in the local memory of the user device 106 for future use. In some embodiments, the device key may be encrypted prior to storing the device key. Each device key may then be used to issue a command to the corresponding electronic device 102 at 314.

In an embodiment of the second variation (variation 2) of the process 300, the access device 104 may transmit the user identifier (collected at 302) to the mobile application server 108 at 316. As described above, the user identifier may be any identifier that can be used to identify a particular user, communication channel, and/or account. The user identifier may be provided to the mobile application server 108 along with an indication of the electronic device 102 and/or the completed transaction.

Upon receiving the user identifier, mobile application server 108 may identify an account associated with the user identifier at 318. The mobile application server 108 may identify one or more electronic devices 102 associated with the identified account based on the indication of the electronic device 102 or the completed transaction. The mobile application server 108 may also identify a device key corresponding to each of the identified electronic devices 102. Additionally, the mobile application server 108 may identify contact information for the user device 106 associated with the identified account. For example, mobile application server 108 may retrieve a telephone number on a record of an account.

Once the device keys of the electronic device 102 have been identified, the mobile application server 108 may send these device keys to the user device 106 at 320. In some embodiments, mobile application server 108 may send the device key via the contact information identified at 318. The mobile application installed on the user device 106 and executed from the user device 106 may then store the device key in the local memory of the user device 106 for future use. In some embodiments, the device key may be encrypted prior to storing the device key. Each device key may then be used to issue a command to the corresponding electronic device 102 at 322.

FIG. 4 depicts an illustrative example of interactions that may occur using embodiments of the systems described herein. The interaction of FIG. 4 is depicted during four different phases of interaction, labeled 402, 404, 406, and 408. As depicted at 402, the mobile application server 410 may detect an update regarding ownership or authorization status of the electronic device (e.g., as a result of sales or leasing) or other suitable indication that a device key is required. In response, the mobile application server 410 may identify the device key 414 of the electronic device and send the device key 414 to the user device 412 determined to be authorized to access the electronic device. In some embodiments, the mobile application server 410 may send a plurality of device keys 414 to the user device 412. Each of these keys may be mapped to an identifier of the electronic device. It should be noted that the device key 414 may be sent one at a time (e.g., as a separate communication) or as a set of device keys 414. Once received by the user device 412, the device keys (along with their corresponding electronic device identifiers) may be stored in a memory of the user device 412.

As depicted at 404, the user device 412 may be connected with a plurality of electronic devices 416. In some cases, the short-range wireless communication device may be activated on the user equipment 412. Upon activation, the user device 412 may detect a plurality of electronic devices 416 in the vicinity of the user device 412 (e.g., within communication range of a short-range communication apparatus). Each electronic device 416 may provide a corresponding Identifier (ID) by which the electronic device may be identified. In some embodiments, a format or indicator within the identifier may be used to determine the type or class of the electronic device 416. It should be noted that in embodiments of an electronic device in which circuitry (e.g., circuitry 230 of fig. 2) is independently powered, the electronic device 416 may be detected even if the electronic device 416 itself is not powered.

Upon receiving the identifiers from the electronic devices in the vicinity of the user device 412, the user device 412 may determine which electronic devices in its vicinity it has stored the corresponding device keys for. As depicted at 406, user device 412 may compile a list 418 of detected devices 416 that may be presented to the user. In some embodiments, the list 418 of detected devices 416 may be accompanied by an indication 420 of one or more commands available to the user of the user device 412. In some embodiments, the list 418 of detected devices 416 may include all electronic devices detected in the vicinity of the user device 412, including the electronic device 422 for which no device key is available. In some embodiments, the list 418 of detected devices 416 may include only the electronic devices for which the device key is currently stored in the memory of the user device.

As depicted at 408, a user of user device 412 may issue commands to one or more of electronic devices 416. To this end, the user device 412 may be configured to send a command and a device key corresponding to the electronic device 416. It should be noted that in embodiments of an electronic device in which circuitry (e.g., circuitry 230 of fig. 2) is independently powered, commands may be sent to electronic device 416 even if electronic device 416 itself is not powered.

FIG. 5 depicts a first illustrative example of user interaction enabled via a mobile application GUI executing on a user device in accordance with at least some embodiments. The illustrated user interaction results in a command being able to be issued to the electronic device 502 via the user device 504. In fig. 5, the interaction is shown via a mobile application GUI (executed from the user device) that is depicted during two different phases of the interaction, which are labeled 506 and 508. In some embodiments, the mobile application may be associated with an account maintained by a mobile application server (e.g., mobile application server 108 described with reference to fig. 1). To use a mobile application, a user may be required to log into an account, which may involve authenticating the user via login credentials provided by the user or some other authentication means (e.g., biometric).

In accordance with at least some embodiments, receipt 510 may be generated after sales of electronic device 502 are completed. The receipt 510 as described herein may be physical (e.g., printed) or virtual (e.g., digital) in nature and may include registration information 512 that may be used to authenticate the owner of the electronic device 502. In some embodiments, registration information 512 may be formatted in a manner suitable for reading by a human user. In some embodiments, registration information 512 may be formatted in a manner readable by user device 504. For example, registration information 512 may be encoded as machine readable code. In some embodiments, registration information 512 may be provided in both formats.

As depicted at 506, the GUI may display a plurality of electronic devices detected in proximity to the user device 504. In some cases, the short-range wireless communication apparatus may be activated on the user equipment 504. Upon activation, the user device 504 may detect a plurality of electronic devices 502 in the vicinity of the user device 504 (e.g., within communication range of a short-range communication apparatus). Each electronic device 502 may provide a corresponding Identifier (ID) by which the electronic device may be identified. Upon receiving identifiers from electronic devices in the vicinity of the user device 504, the user device 504 may determine which electronic devices in its vicinity it has stored corresponding device keys for. As depicted at 506, user device 504 may compile a list 514 of detected devices that may be presented to the user. In some embodiments, the list 514 of detected devices may be accompanied by an indication 516 of one or more commands available to the user of the user device 504 for the electronic device corresponding to the device key stored in memory.

In some embodiments, upon determining that the user device 504 does not currently have a device key in memory for the detected electronic device 502, the mobile application may enable a user of the user device 504 to attempt to register with the electronic device. In some cases, the user device 504 may send a query to the mobile application server that includes an identifier of the electronic device 502 to determine that the electronic device 502 has not been registered and that the electronic device 502 has been legally sold. In some embodiments, registration information 512 may be generated after legal sale of electronic device 502 such that it is only available for electronic devices that have been legally sold. Additionally, the mobile application server may maintain a sales record for the electronic device, which may be consulted to determine if the electronic device 502 has been legally sold.

Upon receiving an instruction to register electronic device 502 from a user of user device 504, the GUI may provide prompt 520 to provide detailed information from registration information 512 to authenticate that the user is a legitimate purchaser of electronic device 502. In some embodiments, the detailed information may be entered manually by a user (e.g., via a keyboard). In some embodiments, the detailed information may be entered using a bar code scanner or other input device in communication with the user device 504. Upon receiving the detailed information, the user device 504 may communicate the detailed information to a mobile application server, which may compare the entered detailed information with the recorded detailed information. Assuming the details match, the mobile application server may respond by retrieving a device key associated with the electronic device 502 and sending the device key to the user device 504. The list of detected devices 514 may then be updated to indicate that the command is available to be provided to the electronic device 502. The user device 504 may then be used to issue a command to the electronic device 502 using the received device key. It should be noted that in the illustrative interactions described with reference to FIG. 5, the electronic device need not be linked to an account. Additionally, in embodiments where the previous registration is not checked, anyone with a receipt may gain access to the device key. This enables the original owner of the electronic device 502 to sell the electronic device to a new owner and enables the new owner to obtain the device key on his or her own user device.

FIG. 6 depicts a second illustrative example of user interaction enabled via a mobile application GUI executing on a user device in accordance with at least some embodiments. The user interactions shown result in linking the electronic device to the account and enabling commands to be issued to the electronic device via the user device. In fig. 6, the interaction is shown via a mobile application GUI (executed from the user device) depicted during four different phases of the interaction, which are labeled 602, 604, 606, and 608. In some embodiments, the mobile application may be associated with an account maintained by a mobile application server (e.g., mobile application server 108 described with reference to fig. 1). To use a mobile application, a user may be required to log into an account, which may involve authenticating the user via login credentials provided by the user or some other authentication means (e.g., biometric).

As depicted at 602, the mobile application GUI may display a list 610 of electronic devices currently associated with an account linked to the mobile application. In some embodiments, the mobile application may store the list 610 of electronic devices (and corresponding device keys) locally in a memory of the user device on which the mobile application is executed. In some embodiments, the list may be generated after the mobile application causes the user device to communicate with the mobile application server to request the current list 610 of electronic devices. In some embodiments, the list 610 of electronic devices may include only those electronic devices that are detected to be within wireless communication range of the user device. In other embodiments, the list 610 of electronic devices may include all electronic devices that are currently linked to an account associated with the mobile application.

Along with the list of electronic devices 610, the mobile application GUI may display additional information 612 for each electronic device in the list 610. For example, the mobile application GUI may display additional information 612, the additional information 612 including a name (or nickname) of the electronic device, a status of the electronic device, available commands for the electronic device, an indication of whether the electronic device is within range, and the like. In some embodiments, the additional information 612 may be dynamically updated based on information about each electronic device. For example, if the current state of the tool is "locked," then "unlocked" may be displayed as an available command, while "locked" may not be displayed as an available command. As a second example, if the electronic device is not currently within wireless range of the user device, the command may become grayed out or otherwise unavailable on the GUI. In some embodiments, the type of commands available for a particular electronic device may vary based on the type or class of the electronic device.

As depicted at 604, additional electronic devices can be linked to an account associated with the mobile application using a receipt 614 generated from the sale of the electronic device. In some embodiments, the receipt may include a machine readable code 616, with registration details encoded within the machine readable code 616. To link the electronic device to an account associated with the mobile application, the user device may be used to scan the machine-readable code 616. For example, the image 618 of the machine-readable code 616 may be captured using a camera device installed on the user device and accessed by the mobile application. The mobile application may then decode the registration information encoded within the machine-readable code 616. In some embodiments, the mobile application may be caused to automatically (i.e., without human interaction) take action with respect to the registration information.

Registration information encoded into machine-readable code 616 may include any suitable information that may be used to link one or more electronic devices to an account. In some embodiments, the registration information may include a device identifier, such as a serial number, for each of the electronic devices purchased in the transaction. In some embodiments, the registration information may include a transaction identifier that may be used to identify a particular completed transaction. In some embodiments, the registration information may include a link or location indicator that causes the mobile application to access a location where the various electronic device details are stored. In some embodiments, the registration information may include a code or PIN associated with the completed transaction that may be used to verify that the user of the user device actually owns the receipt 614.

In some embodiments, the registration information may include one or more device keys associated with the electronic device. In other embodiments, the registration information may not include those device keys such that the device keys must be retrieved from the mobile application server. For example, after a transaction is completed at a resource provider, the resource provider may independently provide a record of the transaction to a mobile application server. The mobile application server may then update the status associated with each electronic device involved in the transaction to indicate that the electronic device has been legally sold. Continuing with the above example, a mobile application that has obtained registration information associated with an electronic device (or devices) from the machine-readable code 616 may transmit the registration information to a mobile application server. The mobile application server may then determine that the electronic device identified in association with the registration information has been legally sold and has not been registered. After making this determination, the mobile application server may then link the electronic devices to an account associated with the mobile application, identify a corresponding device key for each of the electronic devices, and send each of the corresponding device keys to the mobile application.

As depicted at 606, once the electronic device has been successfully linked to an account associated with the mobile application, a notification 620 may be displayed indicating that the electronic device has been successfully linked to the account. In some embodiments, the mobile application may receive the device key from the mobile application server after the electronic device is successfully linked to the account. In some embodiments, the mobile application may receive a device key from the registration information encoded into the machine-readable code 616, which may then be stored by the mobile application in association with the electronic device.

As depicted at 608, once the electronic device has been linked to the account, the mobile application GUI may display an updated list 622 of electronic devices currently linked to the account associated with the mobile application. The mobile application GUI may also display updated additional information 624 for each of the electronic devices in the list 622. Once the electronic device has been linked to the account, the mobile application GUI is operable to issue a command to the electronic device using the received device key.

FIG. 7 depicts a third illustrative example of user interaction enabled via a mobile application GUI executing on a user device in accordance with at least some embodiments. The illustrated user interaction results in a command being able to be issued (e.g., as a lease) to the electronic device 702 via the user device 704 for a predetermined amount of time. In fig. 7, the interaction is shown via a mobile application GUI (executed from the user device) depicted during two different phases of the interaction, which are labeled 706 and 708.

As depicted at 706, the GUI may display a plurality of electronic devices detected in proximity to the user device 704. As depicted at 706, the user device 704 may compile a list 710 of detected devices that may be presented to the user. In some embodiments, the list 710 of detected devices may be accompanied by an indication 712 of one or more commands available to the user of the user device 704 for the electronic device corresponding to the device key stored in the memory of the user device 704.

In some embodiments, upon determining that the user device 704 does not currently have a device key in memory for the detected electronic device 702, the mobile application may enable a user of the user device 704 to attempt to rent the electronic device (e.g., via a button). In some cases, the user device 704 may send a query to the mobile application server that includes an identifier of the electronic device 702, and the mobile application server may respond to the electronic device 702 being available for lease. In some embodiments, the mobile application server may also provide a link (e.g., a Uniform Resource Locator (URL)) to a location that will enable a user of the user device to initiate a transaction to rent the electronic device. For example, after selecting button 714 to rent electronic device 702, the mobile application GUI may load a web page 716 hosted by the mobile application server. After the user receives the payment and before or after completing the transaction, the mobile application server may send a device key associated with the electronic device 702 to the user device 704, although the device key may be encrypted as described below. Information about leases may be maintained by an ownership registry. In some embodiments, the ownership registry uses blockchain ledgers.

Each electronic device 702 may include a secure memory element having a cryptographic key associated therewith. In some embodiments, the cryptographic key may be part of a cryptographic key pair that may be used to securely communicate with the secure memory element. In these embodiments, the mobile application server may generate a data packet including at least an expiration date/time and a device key after receipt of a rental payment and transaction completion of the electronic device 702 or after completion of the transaction as described above. The mobile application server may then encrypt the packet so that the packet can only be decrypted using the cryptographic key of the secure element. Those skilled in the art will recognize that this will prevent the user device from capturing the device key, despite possession of the encrypted packet. The user device 704 can then issue a command to the electronic device 702 by providing an encrypted packet that includes the device key. In these embodiments, the command will continue to execute until an expiration date/time is reached after which the electronic device 702 may no longer accept the encrypted packet. In some embodiments, the electronic device 702 may revert to the "locked" state after the indicated expiration date/time is reached.

Fig. 8 depicts a flowchart that shows a process for updating an authorization status of an electronic device and providing a device key to a user device in accordance with at least some embodiments. In accordance with at least one embodiment, the process 800 of FIG. 8 may be performed by at least the mobile application server 108 shown in FIG. 2.

Process 800 may begin at 802 upon receiving an indication of an update to an authorization status of an electronic device. The indication may include at least an identifier of the electronic device. The authorization status of the electronic device may be any indication of which users are authorized to issue commands to the electronic device. In some embodiments, the update of the authorization status of the electronic device may be a sale of the electronic device. In some embodiments, the update of the authorization status of the electronic device may be caused by a lease or a lender of the electronic device.

At 804, process 800 can involve identifying a device key associated with the electronic device. The device key may be associated with only a single electronic device. In some embodiments, the device key may be identified by querying a database of mappings between electronic device identifiers and device keys (e.g., device key data 212 of fig. 2) stored in a memory of the mobile application server.

At 806, process 800 can involve determining an account associated with an update of an authorization status of the electronic device. An account may be determined based on the received user identifier. For example, after selling the electronic device, an access device (e.g., a point-of-sale terminal) may provide a user identifier to the mobile application server, which may be used to identify the account. Such a user identifier may be at least one of a loyalty account number, a credit card number, a telephone number, an email address, or a user name. In some embodiments, process 800 may further involve associating an electronic device with an account.

At 808, process 800 can involve determining a user device associated with an update of an authorization status of an electronic device. In some embodiments, the user device is determined by virtue of being associated with the determined account. In some embodiments, process 800 may further involve receiving a request for a device key from a user device, and the user device may be determined by virtue of having provided the request. In these embodiments, the request may include a transaction identifier that can be used to identify an update to the authorization status of the electronic device.

At 810, process 800 can involve transmitting a device key to a user device. Upon receiving the device key, the user device may issue a command to the electronic device using the device key. For example, the user device may issue at least a command to lock the electronic device or a command to unlock the electronic device. In some embodiments, the device key is sent to the user device via a push notification. In some embodiments, the user device is operated by an agent of a resource provider that provides access to the electronic device. In some embodiments, the user device is operated by a purchaser of the electronic device.

Fig. 9 depicts a simplified block diagram of a benefit denial system 150 for an electronic device 102 in accordance with at least some embodiments. The benefit denial system 150 includes the access device 104, the network 110, and the electronic device 102 equipped with a benefit denial component. For simplicity, only the access device 104 is shown in fig. 9. The access device 104 may be a POS system as described above, but may also include a user device 106, a remote server, or other elements of a system as described above. The benefit denial component and the components of the electronic device 102 may all be contained within the housing of the electronic device 102. The benefit denial component includes a benefit denial component 122, a communication component 124, a processor 128, and a memory 130. In addition, there will be functional components 120 and power supply 126 within the electronic device 102 to perform the primary functions of the electronic device. In some examples, some elements of the benefit denial system (such as the communication element 124 or the benefit denial element 122) may be external to the housing of the electronic device 102 and connected to the housing of the electronic device 102. In some embodiments, a power source 126 (e.g., a rechargeable battery pack) may be removably coupled to the electronic device 102.

The electronic device 102 and the access device 104 may communicate via a physical or wireless connection using any suitable communication protocol. As an example, the access device 104 and the electronic device 102, in particular the communication element 124 of the electronic device 102, may use bluetooth ^TM Bluetooth (R) ^TM Low Energy (BLE), RFID, or other such wireless communication communicates to send and receive information. In some embodiments, the communication between the access device 104 and the electronic device 102 may be indirect in that the communication is sent over the network 110. For example, the electronic device may include an internet of things (IoT) device in communication with the network 110. Network 110 may include any suitable combination of wired networks, wireless networks, cellular networks, personal area networks, local area networks, enterprise networks, virtual networks, or other suitable networks.

In some embodiments, the system may include a beacon device 112 capable of providing an unlock command to the electronic device 102. The beacon device 112 may generally be located within the store and interface with one or more other devices in or around the store, such as with one or more access devices 104 and one or more electronic devices 102, and one or more devices remote from the store, such as one or more mobile application servers 108. The beacon device 112 may also be integrated with another device located within the store, such as by being integrated in the access device 104 (in which case multiple beacon devices 112 may thus be included if the store includes multiple access devices). In an embodiment, the beacon device 112 may be placed within a store near its entrance and/or exit. Beacon device 112 may be configured to monitor short-range communication channels of electronic devices within range. Each electronic device 102 may broadcast an identifier (e.g., a serial number) that may be detected by the beacon device 112. As the user approaches the beacon device 112 to leave the store, the beacon device 112 may detect any electronic device 102 that is within communication range of the beacon device 112. Note that in embodiments in which benefit rejection element 122 is independently powered via a dedicated power source, electronic device 102 may be detected even if electronic device 102 is not currently powered (e.g., is in an off state or disconnected from power source 126 that powers functional component 120). Upon detecting an in-range electronic device 102, the beacon device 112 may be configured to communicate an identifier of the electronic device 102 to the access device 104 and/or the mobile application server 108, which access device 104 and/or mobile application server 108 may then check to see if the electronic device 102 has been legally sold or otherwise legally obtained. If the electronic device 102 has been legally sold or otherwise legally obtained, the device key for the electronic device 102 may be provided to the beacon device 112, which beacon device 112 may then provide to the electronic device 102 along with a command to enter an unlocked state. In some embodiments, the command may be provided to the electronic device 102 by the beacon device 112 separately from the device key 102 (e.g., during a communication session established after the device key has been sent from the beacon device 112 to the electronic device 102 and the device key match has been verified, or during a communication session established after information has been provided to the electronic device 102 that otherwise indicates that the beacon device 112 has access to the device key). If the electronic device 102 has not been legally sold or otherwise legally obtained, the beacon device 112 may be configured to refrain from sending any unlock command to the electronic device 102 (or sending a lock command to ensure that the electronic device 102 remains locked and its features 120 remain partially or fully disabled/inoperable) and/or to issue an alarm, record an event including an electronic device identifier (such that a video of the event may be later retrieved), or notify an agent of the retailer.

Electronic device 102 may include any power supply device that performs a function. A non-exhaustive list may include power tools, cameras, cell phones, computers, music players, vehicles, toys, televisions, clocks, vehicles, robots, communications devices, medical devices, appliances, and the like. Functional component 120 may include any number of circuits, motors, transistors, and various elements necessary to perform the functions of any particular electronic device 102. As an example, a cordless drilling machine comprises functional components including a motor, a switch and a drilling machine circuit board controlling the drilling machine. The electronic device 102 also includes a power supply 126, which may be removable or permanently fixed. For example, a cordless drill may include a wired connection to an electrical wall outlet, or may have a removable battery that provides power to drive a motor.

In addition to the functional component 120 and the power supply 126, the benefit denial element 122, the communication element 124, the processor 128, and the memory 130 are electrically coupled together, such as shown in fig. 10, to provide the benefit denial features of the present disclosure. The benefit denial element 122, communication element 124, processor 128, memory 130, and/or functional component 120 may be contained within a single device or chip, or may alternatively be separate components within the electronic device 102. The power supply 126 may comprise a single power supply, such as a removable battery that powers both the functional component 120 and the benefit denial component. In some examples, power supply 126 may include multiple batteries or power supplies, one for functional component 120 and one separate power supply for the benefit denial component.

The communication element 124 communicates with the access device 104, the user device 106, or other system components described herein through the network 110. The communication element may include an RFID chip, bluetooth ^TM A chip, or other short range wireless communication device. The communication element 124 may both transmit and receive signals, although in some examples the communication element 124 may be limited to receiving signals only.

The processor 128 and memory 130 are in communication with the communication element 124 and are capable of performing the method described below with respect to fig. 11 and providing signals or instructions to the benefit rejection element 122 based on signals received by the communication element. There may be multiple processors or memory devices associated with the system 150, although only one is shown in fig. 9. Memory 130 may include one or more enclaves (enclaves) that include protected information that cannot be read or changed by processes external to the enclave. The enclave within memory 130 may include decryption information, such as a decryption key that may be used by the processor to decrypt encrypted communications from access device 104. In general, the processor 128 is configured to execute computer-readable instructions, where execution of the computer-readable instructions by the processor configures the benefit denial element 122 to perform one or more operations. These operations include, for example, determining first unlock information of benefit rejection element 122, and selectively disabling or enabling at least one function of electronic device 102 based on a received command when it is determined that another electronic device has access to second unlock information and that the second unlock information corresponds to the first unlock information.

The benefit rejection element 122 may be a component that enables or prevents the flow of electrons or power from the power source 126 to the functional component 120. The benefit rejection element 122 may include a physical switch in addition to transistors or electronically controlled switches and relays that selectively provide or limit the electrical conduit between the power source 126 and the functional component 120. In some examples, benefit rejection element 122 may include a transistor in communication with a capacitor storing a state. An example of such a component may be a Metal Oxide Semiconductor Field Effect Transistor (MOSFET) to provide an "on" or "off" state corresponding to power deliverable to functional component 120 and power not deliverable, respectively. In some examples, benefit rejection element 122 may include a relay, such as an electromagnet, that is activated by current from power source 126 to open or close a circuit loop that includes feature 120. Additional electronic switches may include solid state relays (based on MOSFETs) and latching relays that maintain contact position indefinitely without power being supplied to the coil. Latching relays require power for switching between open and closed, but do not require a holding current to keep the circuit open or closed. Thus, the electronic switch and relay described above may be well suited for benefit rejection element 122 because less voltage is required to change the switch from "off" to "on" and therefore there is little likelihood of the power source being depleted when stored as inventory, for example, on a shelf in a retail store or in a distribution center.

In some examples, benefit rejection element 122 may include and/or be included with an integrated microcontroller of electronic device 102. The integrated microcontroller may create or generate a signal for transmission to the functional component 120 of the electronic device 102. In such an example, when the code or device key is not received as described herein, the microcontroller will not send a command or signal to functional component 120. In some examples, the microcontroller may include software or other elements to perform the functions of the benefit denial element 122. Thus, any or all of the methods, structures, or systems described herein may be incorporated within an integrated circuit or component of the electronic device 102, such as the microcontrollers described above. In some examples, benefit rejection element 122 and feature 120 may be integrated on the same chip, such as by being a component of a system on a chip (SoC) or microcontroller chip, where the SoC or microcontroller chip (as the case may be) may also include an interface between benefit rejection element 122 and feature 120.

In some examples, benefit rejection element 122 may include a thermal shutdown element of electronic device 102. The thermal shutdown element may include a thermal conditioning circuit mounted within the electronic device 102. Such thermal shutdown elements are configured to detect overheating of a regulator or element (such as the functional component 120 and/or its power supply 126) and automatically shut off power to the functional component to prevent damage to the functional component 120 or its power supply 126 due to overheating. In some embodiments, benefit rejection element 122 may transmit or send a signal to the thermal shutdown element to cause the thermal shutdown element to prevent or allow power to flow to functional component 120.

In some examples, benefit rejection element 122 may be powered by an induction coil instead of a battery or other such power source. For example, when a user purchases an electronic device, the POS system may include an electromagnetic field generator to power the benefit denial element 122, the communication element 124, and the processor 128. While the POS system temporarily powers these components, when the user activates the electronic device 120 (e.g., by pressing an "on" button, switch, or trigger of the functional device 120) to perform its function, the POS system may simultaneously transmit an "unlock" command and cause the benefit reject element 122 to close to the circuitry of the functional component 120 and allow power to flow to the functional component 120.

In some examples, the benefit rejection element may include a mechanical switch, rather than a transistor or relay. For example, the benefit rejection element 122 may include: a latching solenoid that uses an electrical pulse to actuate the solenoid between two stable positions; a magnetically actuated switch that changes between an open and a closed state based on the presence or change of a magnetic field; a motorized potentiometer comprising a motor driven by current from a power source to rotate the motor to rotate or change potentiometer settings to increase or decrease resistance to enable or prevent power flow to the functional component 120; a latching reed switch comprising a flexible reed having a plurality of coils and a reed biased by a permanent magnet, the reed being maintained in a closed or open state upon switching by a current flowing through the coils; a motor-driven rotary switch that is opened or closed by a motor-driven action; or other such mechanical switch. These mechanical switches and other switches similar thereto rely on current to switch between closed and open states, but do not rely on a maintenance current to maintain the closed or open state for the reasons described above.

In an example, the electronic device 102 may be a cordless drill with a feature 120 that includes a drill motor. The power source 126 may be a removable battery of a cordless drill. The second (dedicated) power source may be a small battery separate from the removable battery within the housing of the cordless drill. The benefit rejection element 122, the communication element 124, the processor 128, and the memory 130 may be contained on a single chip to which the second power source is connected, between the removable battery and the drill motor. The removable battery may be electrically connected to the chip and the drill motor may also be electrically connected to the chip so that current may flow through the chip when the benefit rejecting element is closed.

Upon reaching the retailer (distribution center or store), the cordless drill may be in an unlocked state, wherein the switch of the benefit rejecting element is closed. At the time of shipment, the retailer may use the access device 104 to provide a locking command to the cordless drill. After receiving the lock command, and possibly after decrypting the command, the benefit rejection element 122 opens so that no current can flow to the rig motor. Cordless drills may remain on the shelf until purchased by the consumer. When the POS systems complete their purchases, the POS systems may act as access devices 104 and provide unlock commands to the cordless drill. The command may cause the processor to transmit a signal to close the benefit rejection element 122, allowing current to flow to the rig motor when the rig is coupled to its power supply 126 and the user presses the activation trigger of the rig.

In some examples, the electronic device 102 may then be locked or unlocked by the consumer using the user device 106, as described herein. This may include time constraints that selectively lock or provide an unlock time of the electronic device 102, such as when the power tool is rented, or at a job site when the job is limited to a particular job time.

Fig. 10 depicts a simplified circuit diagram of an electronic device 102 including a benefit rejection element 122 in accordance with at least some embodiments. The benefit denial component 122 can include the communication component 124 (shown in fig. 9) and the security component 136. The secure element 136 may be a cryptographically or otherwise secured secure device or set of components that includes the processor 128 and the memory 130 of fig. 9, the processor 128 may be a cryptographic processor as described above, and the memory 130 is a secure memory. Additionally, the secure memory may include device key data 138 and check data 140. In some embodiments, the plurality of device keys may be stored by the device key data 138 portion of the memory 130. For example, the electronic device 102 can be associated with a master key and one or more secondary (secondary) keys. In this example, a retailer or manufacturer of the electronic device 102 may maintain a list of master keys while the consumer is provided with the secondary key. In some cases, the consumer may be able to change or change the device key. By having a master device key, if the consumer loses his or her secondary key (e.g., loses the device on which the secondary key is stored), the system allows the consumer to let the retailer or manufacturer reset the benefit denial element 122.

In some embodiments, the check data 140 may include data that may be used to authenticate the current owner. For example, the inspection data 140 may include a counter value that is incremented with each user. In these embodiments, the electronic device 102 may receive a command from a user device (e.g., the user device 106 in fig. 1) accompanied by an encrypted data packet. Upon receipt of the command, the benefit denial component 122 can decrypt the data packet to retrieve the device key encoded within the data packet. The benefit denial component 122 may then determine whether the retrieved device key is valid. The benefit rejection element 122 may also validate the check data 140 if the device key is valid. To this end, the benefit rejection element 122 may retrieve the check value encoded within the encrypted data packet. For example, assume that the check value is a counter value. In this example, the benefit rejection element 122 may compare the retrieved counter value to the counter value stored in the check value data 140. If the retrieved counter value is less than the counter value stored in the check value data 140, the command may be denied. If the retrieved counter value is equal to the counter value stored in the check value data 140, a command may be executed. If the retrieved counter value is greater than the counter value stored in the check value data 140, the check value data 140 may be updated to reflect the retrieved counter value and the command may be executed.

Each of the elements shown in fig. 10 may be included within a housing of the electronic device 102. The device key(s) 138 are stored on the secure memory 130 and may be used to verify or authenticate the device key received from the access device 104 as described herein. There may be one or more device keys that may be used to unlock/lock the electronic device 102, and there may be corresponding device key(s) 138 stored in the secure memory 130 corresponding to each of the plurality of device keys for use by the access device 104. The benefit denial element 122 may communicate or convey a signal to an interrupt element 134, such as a switch, MOSFET, or other example element described above in connection with the benefit denial element 122 of fig. 9. The interrupt element 134 is used to provide, enable, or prevent current flow to the functional component 120 based on a command or signal from the benefit rejection element 122. In this regard, the interrupt element 134 is adapted to selectively enable or disable the electronic device 102 based on commands that are verified to have been received from an authorized source, and the interrupt element 134 is further adapted to refrain from adhering to such commands if such commands are received from an unverified device (e.g., a device that cannot provide information indicating that it has access to a matching device key).

Feature 120 includes the elements described above, and fig. 10 illustrates the flow of power through electronic device 102 as indicated by the arrows. Specifically, the power supply 126 and secondary power supply 132 as described above provide power to designated portions of the electronic device 102. The secondary power source 132 may be a separate (dedicated) power system to supply power only to the benefit rejecting element 122 and its functions. As described above, in some examples, the secondary power source 132 may be the same as the power source 126, or when the power source 126 is coupled to the electronic device 102 (and, in the case of a battery-based power source 126, when it is sufficiently charged), the secondary power source 132 may be recharged by the power source 126. Alternatively, the second power source 132 may be a non-contact and wirelessly powered power source (e.g., an inductively powered current source) as described elsewhere in this disclosure. In some examples, the second power source 132 is integrated in or on the housing of the electronic device 102, separate from the power source 126. Further, even if the power source 126 is not coupled to the functional component 120 or otherwise prevented from powering the functional component 120, the second power source 132 may be configured to power the benefit rejecting element 122. In some examples, functional component 120 may include more than one functional component capable of performing multiple functions. Some or all of these features may be limited by benefit rejection element 122. In some cases, only a single functional component of the electronic device 102 may be limited, while other functional components are not limited. In some cases, each functional component 120 may include a different interrupt element 134 such that benefit denial element 122 may provide access to some of functional components 120 rather than all of functional components 120 at the same time.

In some examples, the secondary power source 132 may include a secondary battery, a separate power line, or a device for providing power (such as an induction coil). The induction coil may power the electronic circuitry of benefit rejection element 122 to receive the command. For example, an inductive coil may be coupled to the beacon device and provide power to benefit rejecting element 122 when in close proximity to each other. In some examples, the access device 104 may include a transmitter capable of providing a field to power the benefit denial element 122 through an induction coil. As an illustrative example, the access device 104 may be a POS system where a consumer purchases an electronic device from a retailer. The access device 104 may include a wireless field generator, such as a charging coil that generates a magnetic field (e.g., varying). The access device 104 may provide power to the benefit rejection element 122 through the inductive coil during the consumer's checkout and completion of the purchase, and simultaneously transmit an unlock command and a device key to unlock the electronic device 102 when the consumer leaves the store.

As shown in fig. 10, when the power supply 126 is coupled to the electronic device 102 and the electronic device 102 is turned on (or activated by a user to operate), the power supply 126 provides power to the functional component 120 through the benefit rejecting element 122. When the benefit rejection element 122 receives a lock command from the access device 104 or the user device 106 as described above, the benefit rejection element 122 closes the conduit that provides power to the functional component 120, thereby disabling the electronic device. This may be accomplished by using a benefit reject switch or electronic component within the chip as described above.

In an embodiment, the secondary power source 132 is separate from the power source 126. When the electronic device 102 is in a locked state (e.g., disabled, or at least its functionality disabled), the secondary power source 132 provides power to the benefit denial element 122, but not to the functional component 120. When the electronic device 102 is in an unlocked state (e.g., activated, or at least its function is activated), one or both of the secondary power source 132 and the power source 126 may be used to power. As a first example, the power source 126, rather than the secondary power source 132, provides power to the benefit rejecting element 122 and the functional component 120. As a second example, secondary power source 132 continues to provide power to benefit rejection element 122, while power source 126 provides power to feature 120. In this second example, the power supply 126 may recharge the secondary power supply 132.

In these various examples, benefit rejection element 122 may include logic (e.g., program code stored in secure memory 130 and executable by processor 128) to select power source 126 and/or secondary power source 132 for power draw, and may include and/or interface with a switch set (not shown in fig. 10) that is controllable based on the logic for connecting benefit rejection element 122 and/or feature 120 to the selected power source(s) 126 and/or 132. Referring back to the first example, the logic indicates that in the locked state, the secondary power source 132 will be selected to provide power only to the benefit rejecting element 122, and in the unlocked state, the power source 126 will be selected to provide power to the benefit rejecting element 122 and the functional component 120. Thus, the switch set is controlled such that in the locked state, there is a first continuous power draw path between the secondary power source 132 and the benefit rejecting element 122, and in the unlocked state, the first power draw path is open, and alternatively, there is a second continuous power draw path between the power source 126 and the benefit rejecting element 122, and a third power draw path between the power source 126 and the functional component 120. Referring back to the second example, the logic indicates that in the locked state, the secondary power source 132 will be selected to provide power only to the benefit rejecting element 122, and in the unlocked state, the power source 126 will be selected to provide power to the functional component 120 and the secondary power source 132. Thus, the switch set is controlled such that in the locked state, there is a first continuous power draw path between the secondary power source 132 and the benefit rejecting element 122, and in the unlocked state, the first power draw path is maintained, there is a second continuous power draw path between the power source 126 and the functional component 120, and there is a third power draw path between the power source 126 and the secondary power source 132.

In addition to or independent of the locked/unlocked state, the logic may control the switch sets to select the associated power source(s) based on the availability of the power source 126. Specifically, the power source 126 may be a removable, rechargeable power source. Thus, if the power source 126 is not connected to the electronic device or connected but not charged (e.g., the battery charge is less than a predefined threshold, such as one percent of the total battery capacity), the logic may control the switch set such that power is provided from the secondary power source 132 to the benefit rejecting element 122. In this example, if the electronic device 102 is in the unlocked state, the logic may further control the switch set such that power is also provided to the functional component 120 from the secondary power source 132. If the power supply 126 is connected to the electronic device and is charged (e.g., the battery charge is greater than a predefined threshold), the logic may control the switch set such that power is provided from the power supply 126 to the benefit denial element 122. In this example, if the electronic device 102 is in the unlocked state, the logic may further control the switch set such that power is also provided to the functional component 120 from the power supply 126.

As described above, the locked and unlocked states of the electronic device 102 may be controlled by the benefit denial element 122 by controlling at least the flow of power to the functional component 120. Additional or alternative mechanisms may exist to control the locked and unlocked states. For example, a communication interface may exist between benefit rejection element 122 (e.g., processor 128 thereof) and feature 120 (e.g., controller or processor thereof). The lock state is set to a default state if no data is exchanged on the communication interface between benefit rejection element 122 and feature 120. The unlock state is set when data is exchanged through the communication interface between the benefit rejection element 122 and the functional component 120. In this example, the data exchange may be performed according to the communication rate. For example, a heartbeat (heartbeat) may be used in which a ping is sent periodically from benefit rejecting element 122 to feature 120, or vice versa. If the heartbeat is no longer detected (e.g., by feature 120 and/or benefit rejection element 122), the locked state is restored. Additionally or alternatively, the data may be verifiable. For example, the data includes a code, and the code may change (e.g., an incremented counter value) at each data transmission. The recipient (e.g., feature 120 and/or benefit rejection element 122) verifies the code (e.g., verifies that the counter value is correct). If verified, the unlocked state is maintained. Otherwise, the locked state will be restored. Of course, the opposite implementation is also possible, wherein the locked state is set if there is a data exchange, and the unlocked state is set if there is no data exchange.

Fig. 11 depicts a flow chart illustrating a process for selectively powering an electronic device in accordance with at least some embodiments. In accordance with at least one embodiment, process 1100 of fig. 11 may be performed by at least processor 128 of fig. 9.

Process 1100 may begin at 1102 with storing a first device key specific to electronic device 102. The first device key may be stored in a secure memory of the electronic device 102. In some embodiments, the first device key may be stored on the memory 130 of the benefit denial element 122 as described above. The first device key may be stored by the manufacturer or may be provided to the secure memory 130 by the retailer when received in inventory. The first device key may likewise be a plurality of device keys, e.g., a generic device key may be maintained for a manufacturer key while another device key may be assigned to accompany the electronic device when it is sent to a retailer for sale.

At 1104, process 1100 can include receiving a command accompanied by a second device key. The command may include a lock or unlock command and may also include an identifier of the electronic device. The command and the second device key may be received via a communication element of the electronic device, such as RFID or other methods described above. The command and the second device key may be received as a packet from the access device. The packet may be encrypted for security and may also include additional device keys or other authorization data. For example, the command may be transmitted by an access device (such as a POS system or user device) when the retailer purchases or sells the electronic device, either through a private sale. In some embodiments, the second device key may be received by the electronic device separately from the command(s). For example, the command may be sent to the electronic device after a communication session is established with the electronic device and after the electronic device receives information indicating that the source (e.g., user device or access device) has access to the second device key and that the second device key matches the first device key via the established communication session. The commands may then be sent separately via the communication session without having to resend the second device key with each command.

At 1104, transmitting the second device key with the command or separately from the command may include decrypting the encrypted device key(s) or authorization information from the encrypted packet. For example, packets transmitted to the electronic device may be encrypted and decrypted by a processor of the electronic device based on an enclave or secure portion of memory (including decryption keys, algorithms, or other such information stored on the memory of the electronic device and used by the processor to decrypt packets received at 1104).

At 1106, the processor 1100 may involve determining whether the second device key matches the first device key. This may include comparing the second device key with the first device key. Comparison of the second device key with the first device key stored in the secure memory of benefit denial element 112 ensures that the command is considered valid and is only executed by the system when the correct device key is used and authentication is authorized. This may involve comparing user information, inspection data, or other data received in connection with the command with information stored on secure memory. In some cases, the secure memory may be updated based on this information. For example, a second device key providing proper authentication may be sent, and the second device key may also be included with user information that is subsequently updated on secure memory. The user information may then be used as an additional authentication layer, for example, by disabling access to previous users that have retained the device key.

At 1108, process 1100 may include causing a power interrupt element of the electronic device to execute the command. This may include providing or transmitting a signal to benefit rejection element 122 and/or interrupt element 134 described above. For example, when a command to unlock the electronic device is issued and authenticated using the device key, the signal may instruct or cause benefit rejection element 122 to enable one or more functions of the electronic device (e.g., by allowing power to be supplied to one or more functional components of the electronic device through power interruption element 134 when the user "turns on" the electronic device or activates its function (s)). In some examples, this may include completing a circuit, changing the state of a switch, changing the state of a transistor, or redirecting power flow through a gateway in addition to the mechanisms described above for the power interrupt element 134. Similarly, when a command to lock the electronic device is issued and authenticated using the device key, the signal may instruct or cause benefit rejection element 122 to disable one or more functions of the electronic device (e.g., by preventing power from flowing from the power source to one or more functional components of the electronic device through power interruption element 134).

Embodiments of the present disclosure provide a number of technical advantages over conventional systems. For example, embodiments of the present invention may enable an owner of an electronic device to lock and unlock the electronic device in a manner that deprives any unauthorized user of the benefit of the electronic device. When such an electronic device is locked, it remains locked until the electronic device is unlocked using the secret device key. As a result, a device that is stolen while locked is almost literally to any potential thief. The disclosed system deters theft of electronic devices by reducing the value of the electronic device to potential thieves. In the event that a thief is aware that a particular resource provider has locked all electronic devices prior to making a legitimate purchase, such thief is less likely to steal from the particular resource provider.

Additionally, the system enables new functionality to be implemented in existing electronic devices. Employees may lock or unlock their tools after entering/leaving the job site, which may result in reduced accidents due to unintentional tool activation. Owners of tools may rent or lend their tools because they know that the tools will lock after the rental period expires, thereby ensuring that failing to return the tools does not benefit the lendee. Those skilled in the art will recognize many additional benefits that may be obtained from the systems described herein after reading this disclosure.

FIG. 12 depicts an illustrative overview of an example system in which a device key that can be used to issue commands to an electronic device can be sent between user devices in accordance with at least some embodiments. In fig. 12, the electronic device 102 is depicted in communication with a plurality of user devices 106. Ownership registry 107 may maintain a record of the current ownership status of electronic device 102. Each of the user devices 106 (1 and 2) may be associated with a different account maintained by the mobile application server 108. Mobile application server 108 may maintain a mapping of the identifier of each electronic device 102 to a corresponding device key.

The electronic device 102 may be any suitable device that electronically accomplishes its purpose. The electronic device 102 may have installed therein electronic circuitry that enables it to be locked and/or unlocked, as described above. User device 106 may be any electronic device capable of establishing a communication session with another device and transmitting/receiving data from the device. The user device 106 may include the capability to download and/or execute mobile applications, as described above. Mobile application server 108 may be any computing device configured to provide remote support for user device 106, as described above.

In some embodiments, the user device 106 may include a communication interface configured to enable communication between the user device and another electronic device (e.g., the mobile application server 108, the electronic device 102, the other user device 106, and/or a wireless router that manages access to a network). Examples of suitable communication interfaces may include Radio Frequency (RF) transceivers configured to transmit and receive communications using Near Field Communication (NFC) or other radio frequency or wireless communication protocols, such as bluetooth, bluetooth Low Energy (BLE), wireless local area network (e.g., wiFi), iBeacon, etc. A second example of a suitable communication interface may include an optical input device capable of obtaining graphical input, such as a camera device or a bar code reader. In this second example, the user device 106 may be presented with a machine-readable code that may be scanned using an optical input device to obtain data encoded into the machine-readable code. In some embodiments, the communication interface may include both long-range and short-range communication devices. For example, the communication interface may include an antenna configured for connection to a cellular network in order to enable communication with various other components of the depicted architecture.

Ownership registry 107 may be any suitable data store that maintains records related to ownership of electronic device 102. In some embodiments, ownership registry 107 may be implemented on a blockchain network that includes a distributed database that maintains an ever-increasing list of records that are protected from tampering and revisions, referred to as blockchains (or blockchains ww). The blockchain may include a plurality of transaction record blocks for a plurality of user/electronic devices. Each block in the blockchain may also contain a timestamp and a link to a previous block of the blockchain. In other words, transaction records in a blockchain may be stored in the ownership registry as a "blockwise" series or persistent file that includes records of a plurality of transactions that occur within a given period of time. After the appropriate node completes the block and the block is verified, the block may be attached to the blockchain by the appropriate node. In embodiments of the invention, the blockchain may be distributed and a copy of the blockchain may be maintained at each node in the blockchain network. Any node within the blockchain network may subsequently use the blockchain to validate the transaction. The nodes of the blockchain network may be any computing device included within the blockchain network. In some embodiments, mobile application server 108 may also be a node of a blockchain network.

In some embodiments, when the electronic device is initially purchased from a retailer (or other resource provider), the first user device 106 (1) may obtain the device key of the electronic device from the retailer (or other resource provider). When a current owner of the electronic device 102 wishes to sell or otherwise transfer ownership of the electronic device, the device key may be provided to the new owner using the techniques described herein. This may involve removing the device key from the user device 106 (1) and providing the device key to the user device 106 (2) associated with the new owner.

By showing interactions between various components of the systems described herein, consider the following scenario. In the illustrated scenario, a first user having user device 106 (1) may be able to interact with electronic device 102 at S1210 using a device key stored locally on user device 106 (1). The user may wish to transfer (e.g., sell or give) ownership rights in the electronic device 102 to a second user having a second user device 106 (2).

In this example, the first user may obtain information about the second user to be used in the transfer at S1212. For example, the second user may provide an identifier that may be used to uniquely identify an account associated with the second user. In some cases, the second user may also provide a public key (of the public-private cryptographic key pair) associated with the second user. In some cases, information about the second user may be sent via an open communication session between the first user device 106 (1) and the second user device 106 (2).

Upon receiving information about the second user from the user device 106 (2), the user device 106 (1) may generate an ownership transfer transaction record. The generated transaction record may be signed using a private key (of the cryptographic key pair) associated with the current owner and may include an identifier of the electronic device 102 and at least a portion of the information associated with the second user. For example, the transaction record may include an identifier of the second user and/or a public key of the second user. As depicted at S1214, the transaction record may be written to the ownership registry 107. Note, however, that in some embodiments, the transaction records may be provided directly to the mobile application server 108.

After receiving the transaction record, and before the transaction record can be written to the ownership registry 107, the computing node of the network maintaining the ownership registry 107 can verify the authenticity of the transaction record and that the owner of the user device 106 (1) is the current owner of the electronic device 102. To this end, the computing node may verify the electronic signature of the transaction record. To verify the electronic signature, the computing node may perform a cryptographic operation on the signed data and compare the result with expected data. If the signature data matches the expected data, the transaction record may be considered to have been verified. This may also verify that the operator of the user device 106 (1) is the current owner of the electronic device 102, as the user device 106 (1) must possess the private cryptographic key used to create the electronic signature. In some cases, the computing node may identify the latest transaction record associated with the electronic device 102 that is stored in the ownership registry. After retrieving the transaction record, the computing node may verify the current electronic signature using the public key indicated in the transaction record. Once the transaction record (and current ownership status) has been verified, the transaction record is added to the ownership registry.

After verifying the authenticity and ownership of the transaction record and recording the transaction record to the ownership registry 107, the mobile application server 108 may receive an indication of the transaction at S1216. In some embodiments, mobile application server 108 may be notified via a notification module that monitors transaction records recorded to ownership registry 107. In some embodiments, upon receiving an indication of transfer of ownership, mobile application server 108 may identify an account associated with each of user devices 106 and a device key associated with electronic device 102. In some embodiments, this may involve performing a query for a device identifier associated with each of the user devices 106. Mobile application server 108 may then identify contact information for each of the devices stored in association with the respective account. In some embodiments, one or both of the user devices 106 may not be associated with an account maintained by the mobile application server 108. In these embodiments, the mobile application server 108 may identify the contact information for the user device 106 from the transaction records recorded to the ownership registry 106.

After identifying the contact information for at least user device 106 (2), mobile application server 108 may send a device key associated with electronic device 102 to user device 106 (2) at S1218. In some embodiments, the device key may be sent to the user device 106 (2) via a push notification (e.g., push update). The device key may be stored in a secure memory of the user device 106 (2). In some embodiments, the device key may be encrypted. In these embodiments, the device key may be encrypted by the mobile application server 108 before being provided to the user device 106 (2), or the device key may be encrypted by the user device 106 (2) before being stored in memory. Upon receiving the device key, the user device 106 (2) may issue a command to the electronic device 102 using the device key at S1220. The electronic device 102 may include circuitry configured to allow compliance with such commands only when a device key associated with the electronic device 102 is received by the user device 106 (2).

In some embodiments, the mobile application server 108 may also cause the device key to be removed from the memory of the user device 106 (1), thereby preventing it from being able to issue commands to the electronic device 102 in the future, or preventing the electronic device 102 from adhering to such commands. In some embodiments, this may involve the mobile application server 108 providing instructions to the user device 106 (1) that cause the device key associated with the electronic device 102 to be deleted or otherwise removed from memory.

In some embodiments, it may not be necessary to remove the device key from the memory of the user device 106 (1) to prevent the device key from being used to issue commands to the electronic device 102. For example, in some embodiments, the user device 106 (2) may cause the current device key to be replaced with a new device key after receiving the device key and establishing a communication session with the electronic device 102. It is envisioned that to do this, it may be necessary to have the current device key. Once the device key is replaced with the new device key, the new device key may be sent to mobile application server 108, which mobile application server 108 may subsequently store the new device key for future reference. As a second example, in some embodiments, when providing the device key to the user device 106 (2), the mobile application server 108 may provide the encrypted data packet. The encrypted data packet may include a device key and dynamic data elements that may be used to validate the data packet. For example, mobile application server 108 may compile a data packet including a device key and a counter value (e.g., a value that is incremented or decremented after each ownership transfer) that is encrypted in a manner such that it can only be decrypted by electronic device 102. Upon receiving an encrypted data packet having a counter value, the electronic device 102 may verify that the counter value is greater than (or less than) the previously used counter value and may update the current counter value stored in the electronic device to match the counter value received in the most recent encrypted data packet. In this example, when a command received with a data packet is executed, only the data packet including a counter value greater than or equal to the currently stored counter value may be verified. As a third example, in some embodiments, the mobile application server 108 may generate a new device key and send the new device key to the user device 106 (2) at S1218. The new device key may be different from the device key stored in the memory of the user device 106 (1). As explained above, although various embodiments are described in connection with a device key, the present disclosure is not limited thereto, but is equally applicable to any type of unlocking information. Referring back to the second example of the current paragraph, the encrypted data packet represents the type of unlock information. In this example, the unlock information is variable because the counter value is updated, because the encrypted data packet sent to the user device 106 (2) includes the counter value that has been updated. Of course, other examples exist in which the unlock information previously stored in the memory of the user device 106 (1) is different from the new unlock information used by the user device 106 (2). As with the second example, new unlock information may be generated by user device 106 (2) and/or electronic device 102. As with the first example and the third example, new unlock information may also or alternatively be generated by mobile application server 108. In these various examples, previous unlock information need not be removed from the memory of the user device 106 (1), at least in part because such information may no longer be available to unlock or lock the functionality of the electronic device 102.

In some embodiments, mobile application server 108 may compile a data packet that includes a device key and an identifier of user device 106 (2). In this example, the electronic device 102 may be associated with its own cryptographic key pair (e.g., private and public cryptographic keys). The mobile application server 108 may then encrypt the data packets using the public cryptographic key associated with the electronic device 102. This will prevent the user device 106 (2) from accessing the information in the data packet, although the encrypted packet is stored in the memory of the user device 106 (2), since the information is only accessible by the electronic device 102 having the private cryptographic key. In these embodiments, after the user device 106 (2) issues a command to the electronic device 102 at S1220, the encrypted data packet will be provided to the electronic device 102 along with the command to be executed. The electronic device 102 will then use its private cryptographic key to decrypt the encrypted packet, verify the device key, verify that the device identifier of the user device 106 (2) matches the device identifier associated with the user device 106 (2) from which the command was issued, and execute the command after verification. Those skilled in the art will recognize upon reading this disclosure that these embodiments of the system will prevent user devices not authorized by the mobile application server 108 from issuing commands even though they possess encrypted data packets that include device keys.

For clarity, a specific number of components are shown in fig. 12. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include fewer or more than all of the components shown in FIG. 12. Further, the components in fig. 12 may communicate via any suitable communication medium (including the internet) using any suitable communication protocol.

FIG. 13 depicts an example system architecture for a system that may be implemented to perform the functions described in accordance with at least some embodiments. As depicted in fig. 13, an exemplary architecture may include an electronic device 102, one or more user devices 106, and a mobile application server 108, as described above with respect to fig. 1 and 12. The components of the electronic device 102, one or more user devices 106, and the mobile application server 108 are depicted in fig. 2. A description of these components is not repeated here. Additionally, the system may include a plurality of registry network nodes 1302, the plurality of registry network nodes 1302 forming a registry network. One or more of these components may communicate directly or through a network 201.

In some embodiments, the key management module 210 may be configured to receive a request for transfer of ownership rights associated with the electronic device 102. In these embodiments, the request may include a device identifier of the electronic device 102 and information about an operator of the user device 106. The key management module 210 may identify the current owner of the electronic device 102 and contact information for the current owner. Key management module 1310 may then send the received request to the current owner via the identified contact information. In some embodiments, the received request may include an offer (offer) for purchase and/or payment credentials to complete the transaction. Note that the transfer of ownership rights may involve a temporary transfer (e.g., rental) of ownership rights of the electronic device. Upon receipt of the request at the user device associated with the current owner, transfer of ownership rights may be handled as described elsewhere.

In some embodiments, the key management module 210 may additionally identify cryptographic keys and/or dynamic data associated with the electronic device 102. The key management module 210 may be configured to compile a data packet that includes the device key of the electronic device 102 and dynamic data. For example, the key management module 210 may identify a current counter value associated with the electronic device 102. Additionally, the key management module 210 may include an identifier of the user device 106 into the data packet. The key management module 210 may then encrypt the data packet using the identified cryptographic key such that the data packet can only be decrypted by the electronic device 102. The key management module 210 may then provide the encrypted data packet to the user device 106.

In some embodiments, the mobile application 226 may be configured to facilitate transfer of ownership of the electronic device to or from an operator of the user device 106 or from an operator of the user device 104 in conjunction with the processor 222. To facilitate transfer of ownership of the electronic device 102 from an operator of the user device 106 (e.g., whether permanently due to sales of the electronic device 102 or temporarily due to renting of the electronic device), the mobile server 226 may be configured to receive information about the electronic device 102 (e.g., a device identifier) and information about a user to whom ownership of the electronic device should be transferred. In some embodiments, at least a portion of the information may be entered manually (e.g., via a GUI). In some embodiments, at least a portion of the information may be entered electronically. For example, a user of the user device 106 may scan a bar code or other machine readable code (e.g., a bar code of an electronic device or a bar code presented by a transferee) that includes at least a portion of the information. In some embodiments, the user device 106 may receive information about the transferee from the mobile application server 108 (e.g., after receiving a request for transfer of ownership from a potential transferee). Once the mobile application 226 receives the required information, it can complete the ownership transfer transaction. In some embodiments, this may involve generating a transaction record that includes the received information, and causing the transaction record to be written to an ownership registry maintained on the registry network. The mobile application 226 may electronically sign the transaction record using the cryptographic key so that the transaction record may be verified. In some embodiments, each mobile application 226 may be associated with a separate cryptographic key pair (e.g., private and public cryptographic keys) that may be used to encrypt messages to the mobile application 226 and to sign transaction records by the mobile application 226. In some embodiments, the mobile application 226 may be configured to: after the financial transaction is completed, for example, after authorization for a payment transaction from the transferee is received, a transaction record is provided to the ownership registry. In some embodiments, the mobile application 226 may be configured to: upon completion of transfer of ownership of the electronic device 102 from the operator of the user device 106, the device key of the electronic device is automatically (e.g., without any further instructions) deleted or otherwise removed from the stored device key 1328.

To facilitate transfer of ownership of the electronic device to an operator of the user device 106 (e.g., whether a permanent transfer due to the operator purchasing the electronic device 102 or a temporary transfer due to the operator renting the electronic device 102), the mobile server 226 may be configured to communicate information about the operator of the user device 106 to a user device currently associated with the electronic device 102. In some embodiments, the user device 106 of the user to whom the electronic device 102 is to be transferred may detect the electronic device 102 in its vicinity (e.g., via a wireless connection), and such user may request to purchase or rent the detected electronic device 102. In these embodiments, the mobile application 226 may transmit a request for transfer of ownership rights (or lease) to the mobile application server 108, which mobile application server 108 may transmit to the current owner of the electronic device 102. In some embodiments, the mobile application 226 may provide information to be used in the transfer of ownership of the electronic device directly to the current owner of the electronic device. For example, the mobile application 226 may cause the user device 106 to establish communication with a second user device 106 operated by a current owner of the electronic device 102. The mobile application 226 may further cause the user device 106 of the user requesting the ownership transfer to send information about the operator of the user device 106 to the second user device via the connection. In a second example, the mobile application 226 may cause the user device 106 of the user requesting the ownership transfer to compile machine-readable code comprising information about the user, which may then be scanned using an optical reader installed within the second user device. In some embodiments, to facilitate transfer of ownership of the electronic device 102 to an operator of the user device 106, the mobile application 226 may provide a public cryptographic key associated with an account maintained by the operator of the user device 106 to the second user device such that the public cryptographic key may be included in the transaction record.

Registry network node 1302 may be any suitable computing system or component within a registry network. The registry network node 1302 may be configured to perform registry updating/verification actions in accordance with embodiments described herein. In some embodiments, the registry network may be a blockchain network that includes a distributed environment implemented across multiple registry network nodes 1302. In some embodiments, mobile application server 108 may also be a registry network node. The registry network node 1302 may include a memory 1336 (e.g., a computer readable storage medium) storing instructions which, when executed by the processor 1338 of the registry network node 1302, enable the registry network node 1302 to perform its intended functions. Turning in more detail to the contents of the memory 1336, the memory 1336 may include a local copy of the ownership registry data 1340 and a module for managing the registry data (registry management module 1342).

In some embodiments, the registry management module 1342 may be configured to update the ownership registry data 1340 in conjunction with the processor 1338 to include the received transaction records. In some embodiments, the registry management module 1342 (or the ownership registries 107 or 1502 and/or the registry network node 1608) may receive a transaction record from a manufacturer or vendor of the electronic device 102 indicating that ownership of the electronic device 102 has been transferred to a particular distributor (e.g., retailer) of the electronic device 102. The registry management module 1342 (or the ownership registry 107 or 1502 and/or the registry network node 1608) may later receive a transaction record from the distributor (e.g., from the mobile application server 108 or 1606) indicating that the electronic device 102 was purchased by the consumer of the distributor (e.g., during any of the previously described processes for purchasing and/or activating the electronic device 102). With this information, the ownership registry data 1340 (or ownership registries 107 or 1502 and/or registry network node 1608) may be updated to contain records of these purchases (or other transfers, such as gifts) such that the ownership registry data 1340 contains "chain-of-title" records for the electronic device 102. During subsequent attempts to transfer ownership of electronic device 102, the proposed new owner may query ownership registry data 1340 (or ownership registries 107 or 1502 and/or registry network nodes 1608), for example, using his or her electronic device 106 (or otherwise), to determine if there is a break in the title chain from the manufacturer/vendor to the person claiming to transfer ownership. A break in the title chain serves as a warning that the electronic device 102 may have been stolen or not be authentic. To enable querying of the ownership registry data 1340, each electronic device 102 may be caused to carry query information that uniquely identifies the electronic device 102 and/or an electronic device 102 identifier (e.g., a bar code, QR code, or other information that may be read by the user device 106, e.g., wirelessly via bluetooth, BLE, RFID technology, or other means), and when read by the user device 106, cause the user device 106 to initiate a query of the ownership registry data 1340 (or ownership registries 107 or 1502 and/or registry network node 1608) to determine whether the electronic device 102 is authentic or stolen (e.g., based on a break in the title chain). In some embodiments, the

mobile application server

108 or 1606 may be configured to receive a report from a retailer or other party that a particular electronic device 102 was stolen, and to communicate the stolen status of the electronic device to the ownership registry 107 or 1502 and/or registry node 1302 or 1608, such that the stolen status may be communicated to the proposed new owner (e.g., via his or her user device 106) in response to a query to the ownership registry 107 or 1502 and/or registry network node 1302 or 1608. For each transfer of ownership, the ownership registry 107 or 1502 and/or the registry network node 1302 or 1608 may be updated with metadata including vendor and buyer information (which may be anonymous if either party is personal for privacy reasons), product UPC, product serial number, and/or time stamp of each transfer of electronic device 102. The retailer may also query the title chain information to determine if the retailer (and not other retailers) has actually sold the merchandise in the past when someone attempted to return the merchandise. In some embodiments, the registry management module 1342 may receive a transaction record from the user device 106 including at least the electronic device identifier. The registry management module 1342 may verify that the originator of the transaction record is the current owner of the electronic device upon receiving the transaction record. This may involve identifying the latest transaction record currently in ownership registry data 1340, and determining whether the information included in the transaction record matches the information of the sponsor of the transaction record. In some embodiments, the received transaction record may include an electronic signature that includes data within the transaction record that has been obfuscated (obfuscated) using a private key associated with the sponsor of the transaction record. To verify such an ownership registry, the registry management module 1342 can identify the public key associated with the originator of the transaction record and use it to recover data within the transaction record. If the recovered data matches the data in the transaction record, it is typically used as evidence that the signer (e.g., the initiator of the transaction record) has the private cryptographic key. In some embodiments, the registry management module 1342 may identify a public cryptographic key associated with the current owner from the latest transaction record currently in the ownership registry data 1340, and may use the public cryptographic key to verify the electronic signature. In these embodiments, the transaction record written to ownership registry data 1340 may include a public cryptographic key associated with the intended transferee.

Additionally, the registry management module 1342 may be configured to provide a notification to the mobile application server 108 upon successful addition of the transaction record to the ownership registry data 1340. In some cases, the ownership registry data 1340 may generally relate to ownership of electronic devices across multiple mobile application servers 108. For example, the ownership registry may be manufacturer specific (e.g., electronic devices manufactured for a particular manufacturer are maintained), and the plurality of mobile application servers 108 may each be associated with a different retailer selling electronic devices. In embodiments where multiple mobile application servers are associated with the ownership registry data 1340, the registry management module 1342 can be configured to identify the mobile application server 108 associated with a particular electronic device 102. In some cases, the mobile application server 108 may be identified from the latest transaction record for the electronic device as being associated with the current owner of the electronic device (e.g., maintaining an account of the current owner of the electronic device). After identifying the appropriate mobile application server 108 for a successfully added transaction record, the registry management module 1342 may be configured to provide a notification to the mobile application server 108 regarding the transaction record.

Illustrative examples of transferring command execution rights of an electronic device between accounts in accordance with at least some embodiments are depicted in two phases. Fig. 14A depicts a state before transferring command execution authority of the electronic device. Fig. 14B depicts states during and after transferring command execution rights of an electronic device. In each of these respective states, the mobile application server 108 is described as communicating with a plurality of user devices 106 (e.g., user devices 106 (1-2)). The plurality of user devices 106 are further described as communicating with a plurality of electronic devices 102, e.g., electronic devices 102 (1-4).

As depicted at 14A, the mobile application server 108 may provide a device key to each user device 106 based on which the electronic device is associated with the user device. For example, upon determining that the operator of the user device 106 (1) is the current owner of the electronic device 102 (1) and the electronic device 102 (2), the mobile application server 108 may provide the corresponding device key 1 (key 1) and device key 2 (key 2) to the user device 106 (1). Likewise, upon determining that the operator of the user device 106 (2) is the current owner of the electronic device 102 (3) and the electronic device 102 (4), the mobile application server 108 may provide the corresponding device key 3 (key 3) and device key 4 (key 4) to the user device 106 (2). Each user device 106 may store a respective key within a mapping to a device identifier of a respective electronic device.

Each of the user devices 106 may be capable of detecting each of the electronic devices 102 and receiving an electronic device identifier from each of the electronic devices 102. In some embodiments, each user device may automatically detect electronic devices 102 that are within wireless communication range of the respective user device 106. However, whether the user device 106 is able to detect each electronic device 102 or is able to communicate with each electronic device 102, the electronic device may be configured to perform only the following commands: (1) The command includes a valid device key or (2) the command is acknowledged by the electronic device as having been sent by the user device 106 with a valid device key. Thus, each user device 106 can only issue commands to the electronic device 102 for which it maintains the corresponding device key. Thus, in the depicted example, command execution rights for an electronic device are available only for user devices associated with the current owner of the respective electronic device.

As depicted at 14B, the user device 106 (1) may transfer its command execution rights for the electronic device 102 (2) to the second user device 106 (2). This may involve communication with the mobile application server 108 or the ownership registry network 106, as described elsewhere. In embodiments where the user device 106 (1) communicates with the mobile application server 108, the mobile application server 108 may generate a transaction record that may be provided to the ownership registry network for attachment to the current ownership registry. In embodiments where the user device 106 (1) communicates with the ownership registry network 106, the user device 106 (1) may generate a transaction record that may be provided to the ownership registry network 106 for attachment to the current ownership registry. The ownership registry network 106 may then notify the mobile application server 108 of the transfer. As described elsewhere, the transaction record may include a number of details regarding the transferee (i.e., the user to whom the command execution authority was transferred) as well as an electronic signature. The electronic signature may be generated by the user device 106 (1) using a private key associated with the user device 106 (1), or the electronic signature may be generated by the mobile application server 108 using a private key associated with the mobile application server 108, depending on which entity created the transaction record.

Once the transfer of command execution rights of the electronic device 102 (2) to the second user device 106 (2) has been completed, the mobile application server 108 may provide the user device 106 (2) with a device key (key 2) corresponding to the electronic device 102 (2). In some embodiments, the mobile application server 108 may send instructions to the user device 106 (1) that cause the key 2 to be deleted from the memory of the user device 106 (1). In some cases, the key 2 may be automatically removed from the memory of the user device 106 (1) after completing the transfer of command execution rights for the electronic device 102 (2). In this way, the user device 106 (2) may be able to issue commands to the electronic device 102 (2), and the user device 106 (2) may become unable to issue commands to the electronic device 102 (2). In some embodiments, after completing the transfer of command execution rights of the electronic device 102 (2), the user device 106 (2) may replace or alter the key 2 within the memory of the electronic device 102 (2).

Fig. 15 depicts an example ownership registry with respect to an electronic device implementation, which may be in accordance with at least some embodiments of the present disclosure. In fig. 15, ownership registry 1502 may include records of transaction records 1504 related to particular items (e.g., electronic devices) distributed across a blockchain network. In some embodiments, ownership registry 1502 may include a blockchain ledger in which a plurality of transaction records relating to various item transactions are processed in a "chunk" that is then distributed to a plurality of computing nodes of the blockchain network.

As described above, a plurality of transaction records 1504 may be associated with the ownership registry 1502. Ownership registry 1502 may include electronic device information 1506, which electronic device information 406 may be formatted with at least an electronic device identifier. In some embodiments, the electronic device identifier may be generated using electronic device information provided via a user device (e.g., one of the user devices 106 described herein) or during an electronic device registration (ironlment) process. In some embodiments, the electronic device identifier may be generated according to a specified format using information related to the electronic device (e.g., one of the electronic devices 102 described herein). For example, the electronic device identifier may be generated as some combination of item type and serial number. In some embodiments, the electronic device information 1508 included within the ownership registry 1502 may be generated by a resource provider 1506 (e.g., a merchant or manufacturer) that originally provided, distributed, or sold (e.g., at a retail location) the electronic device.

When users conduct transactions (e.g., purchases and/or rentals) with respect to various electronic devices, user devices associated with the users may generate requests and send the requests to an ownership registry network for addition to the ownership registry. After verifying the new transaction record, the new transaction record may be generated and appended to the ownership registry 1502. In some embodiments, each transaction record attached to the ownership registry 1502 may include an electronic signature 1510 that may be used to verify the authenticity of the transaction record. The transaction record 1504 may also include transaction data 1512. In some embodiments, the transaction data 1512 included in the transaction record 1504 may include information related to the transaction being conducted, the user/users conducting the transaction, contact information for the user, a public cryptographic key associated with the user, or any other suitable information. In some embodiments, the electronic signature 1510 may include a portion of the data 1512 that has been obfuscated using a private cryptographic key associated with the user.

When a transaction is conducted with respect to the ownership registry 1502, a transaction record is generated for the transaction and appended to the ownership registry such that the ownership registry may constitute an unalterable history of ownership rights of a plurality of electronic devices (e.g., permanent ownership rights such as in the case of a purchase, or temporary ownership rights such as in the case of a lease). In some embodiments, the transaction record may be generated and signed by the user 1514 and provided to an ownership registry network node that adds the transaction record to the ownership registry 1502. In some embodiments, the transaction record may be generated and signed by the mobile application server on behalf of the user 1514. For example, in some embodiments of the systems described herein, a first user may provide an indication that ownership rights in an electronic device currently associated with his or her account should be transferred to a second user. In this example, the mobile application server may generate a transaction record to be appended to the ownership registry 1502 after authenticating the first and second users (e.g., via login credentials).

As previously described, each transaction record may be signed using a private key to create a signature 1510 of the transaction record. In some embodiments, the transaction record may be signed by a registry network node of the mobile application server or the ownership registry network using a private key associated with the mobile application server or the ownership registry network. In this way, the transaction record may be verified using a public key associated with the mobile application server or the ownership registry network. In some embodiments, the transaction record may be signed by one of the parties 1514 to the transaction (e.g., the current owner) using a private key associated with that party. In this way, the public key associated with the party may be obtained (e.g., from a repository of public keys or from a latest transaction record associated with the electronic device in question) and used to verify the authenticity of the transaction record.

In some embodiments, the transaction includes a lease of the electronic device (or devices). A proof of rights protocol (proof of stake protocol, poS) may be used for transaction records in the PoS blockchain ledger. In a PoS blockchain, transactions may be algorithmically verified using computer hardware based on tokens that are mortgage (like) in the form of a transaction mortgage (collage) in the network (or locked via a cryptographic key and/or information verifiable as authentic). Mortgages may include a deposit of a lease in the form of a payment instrument and a deposit value to be applied to the payment instrument. In this way, a tool rental program can be provided that utilizes the disclosed blockchain functionality. The tool rental facility maintains the electronic device disabled. Via the user device 106, the consumer may select one or more of the electronic devices to rent and pay the rented deposit. The deposit is then mortgage into the blockchain ledger. Thereafter, the user device 106 receives a device key (or more generally, unlock information) that allows the electronic device to be activated via the consumer's user device 106. The device key (or more generally, the unlock information) may be sent from the mobile application server 108 to the blockchain ledger after an update to the ownership registry 107, wherein the update uses the PoS protocol. Mortgage may be released when the electronic device is brought back to the tool rental facility under appropriate conditions (e.g., conditions that justify release of the mortgage value). Release may involve ownership registry 107 updating blockchain ledgers regarding the return of the electronic device and/or the end of the lease. Furthermore, the release may, but need not, involve the mobile application server 108 instructing the consumer's user device 106 and/or electronic device to remove the device key (or more generally, the unlock information) or instructing the electronic device to use a new device key (or more generally, the new unlock information). In embodiments where the unlock information is automatically variable, such instructions of the mobile application server 108 may not be required. For example, and as described herein, the unlock information may include an expiration date/time. After the expiration date/time has elapsed, the unlock information may no longer be available to operate the electronic device, and thus, the electronic device may be automatically deactivated.

FIG. 16 depicts a process for transferring device keys between accounts in accordance with at least some embodiments. Some or all of the process 1600 (or any other process described herein, or variations and/or combinations thereof) may be performed under control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). According to at least one embodiment, process 1600 of fig. 16 may be performed by at least some of the components described with respect to fig. 13. The code may be stored on a computer readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer readable storage medium may be non-transitory.

As depicted in step 1, process 1600 may involve receiving (e.g., via electronic, magnetic, or optical scanning) an indication 1604 (e.g., a serial number, UPC code, device identifier, bar code, QR code, and/or image information) of electronic device 1602 at access device 1601. For example, a user may present the electronic device 1604 for purchase at the access device 1602 (e.g., a point of sale (POS) device), and the access device 1604 may determine (via scanning or otherwise) from the indication 1601 which electronic device 1602 is being purchased. The access device 1604, upon receiving the indication 1602 of the electronic device 1601, may conduct a transaction associated with the electronic device 1602 to transfer ownership rights of the electronic device 1602 to the user.

After completing the transaction transferring ownership rights of the electronic device 1602 to the user, the access device 1604 may transmit an indication of the transaction to the mobile application server 1606 at step 2. In some embodiments, the access device 1604 may provide a device identifier of the electronic device 1602 and information related to a purchaser of the electronic device 1602. The mobile application server 1606, upon receipt of the information, can identify a device key associated with the electronic device. In some embodiments, mobile application server 1606 may provide the device key to access device 1604 or another user device in proximity to access device 1604. In these embodiments, the access device 1604 may be configured to establish a connection with the electronic device 1602 to unlock the electronic device 1602 using the provided device key.

As depicted at step 3, mobile application server 1606 may cause registry network node 1608 to append the transaction record to ownership registry 1610, thereby indicating transfer of ownership of electronic device 1602. In some embodiments, the mobile application server 1606 may create an initial transaction record for the electronic device 1602. In these embodiments, the presence of such transaction records may indicate a valid sale of the electronic device.

The device key associated with the electronic device 1602 may then be provided to a user device 1612 associated with a purchaser of the electronic device. In some embodiments, the device key may be provided by the access device 1604 to the user device 1612, as depicted at step 4. For example, the device key may be encoded within a machine readable code printed on the receipt by the access device 1604. In some embodiments, the device key may be provided to the user device 1612 by the mobile application server 1606, as depicted at step 5. For example, the access device 1604 may provide information about a purchaser of the electronic device 1606 to the mobile application server 1602. The mobile application server 1606 may then identify an account associated with the user based on the information provided. The mobile application server 1606 may then provide the device key to the user device 1612 via the contact information stored in association with the identified account. Upon receiving the device key, the user device 1612 can provide a command to the electronic device 1602 using the device key at step 6.

Process 1600 may continue when a user associated with user device 1612 decides to transfer his or her ability to issue commands to electronic device 1602 to a second user. In some embodiments, the current user may gather information about the second user to be used in the transaction. This may involve an interaction between the user device 1612 and a second user device 1614 operated by a second user at step 7, in which interaction the user device 1612 obtains information about the second user.

As depicted at step 8, the user device 1612 may cause a new transaction record to be appended to the ownership registry 1610 at step 8. In some embodiments, the transaction record may include an indication of the second user (and possibly a public cryptographic key associated with the second user). The transaction record may also include an electronic signature of the user associated with the user device 1612, which may be used to verify the authenticity of the transaction record. In some embodiments, upon receiving a transaction record, the registry network node 1608 may append the transaction record to the ownership registry upon verifying the authenticity of the transaction record.

Once the ownership registry 1610 has been updated to include the new transaction record, a notification module 1616 monitoring the ownership registry may notify the mobile application server 1606 of the transaction at step 9. The mobile application server 1606, after being notified of the new transaction, can identify an account associated with the second user and subsequently identify the user device 1614 associated with the account. The mobile application server 1606 may then provide the device key associated with the electronic device 1602 to the user device 1614 at step 10. Upon receiving the device key, the user device 1614 can provide a command to the electronic device 1602 using the device key at step 11.

Fig. 17 depicts a flow diagram for granting access rights for an electronic device from a first user device to a second user device in accordance with at least some embodiments. The process 1700 of fig. 17 may be performed by at least the user device 106 described with respect to fig. 13. More specifically, process 1700 of fig. 17 is depicted as being performed by a user device currently associated with an electronic device.

Process 1700 may begin at 1702 when a request is received at a first user device (e.g., a transferor user device) for granting access rights to an electronic device currently associated with the first user device.

At 1704, the process 1700 may involve obtaining information related to a second user (e.g., transferee). The information related to the second user may comprise at least an identifier of the second user. In some embodiments, the information related to the second user may include a public cryptographic key associated with the second user or a public cryptographic key associated with an account maintained with respect to the second user. In some embodiments, the information associated with the second user may be received via manual input through a graphical user interface executing on the user device. In some embodiments, information associated with a second user may be received from a second user device. For example, information associated with the second user may be encoded within the machine-readable code by the second user device, and the information associated with the second user may be received when the user device scans the machine-readable code. In a second example, information associated with the second user may be transmitted from the second user device to the first user device using a wireless communication protocol.

At 1706, the process 1700 may involve generating a transaction record. In some embodiments, the transaction record may include at least a portion of the information related to the second user. In some embodiments, the transaction record may include at least an electronic signature generated using a private cryptographic key associated with the first user.

At 1708, process 1700 may involve transmitting the transaction record to a server. In some embodiments, the server may be a registry network node comprising a distributed database. In at least some of these embodiments, the transaction record may be appended to a series of transaction records representing an ownership registry. This series of transaction records may be blockchain ledgers. In some embodiments, the server may be a mobile application server that maintains accounts for multiple users. The second user device may be identified by virtue of being associated with an account maintained by the mobile application server with respect to the second user. In at least some of these embodiments, the mobile application server may record the transaction record in an ownership registry.

The server may be caused to validate the transaction record prior to adding the transaction record to the ownership registry. This may involve verifying that the first user device has the right to grant access to the electronic device and verifying the electronic signature. Verifying that the first user device has the right to grant access to the electronic device may involve determining that an operator of the first user device is a current owner of the electronic device. This may further involve identifying the latest transaction record in the ownership registry associated with the electronic device and determining that it involves transferring ownership to the operator of the first user device. Verifying the electronic signature includes applying a public cryptographic key associated with the first user to the electronic signature and comparing the result to information associated with the second user included in the transaction record.

Upon verifying the transaction record, a device key associated with the electronic device may be caused to be provided to a second user device associated with the second user. The device key grants access rights to the electronic device for the second user device.

At 1710, the process 1700 may optionally involve automatically removing a device key associated with the electronic device from memory of the first user device. In some embodiments, this may be done after receiving an indication that the transaction record has been successfully validated.

Fig. 18 depicts a flow diagram that shows a process 1800 for obtaining, at a first user device, access rights for an electronic device from a second user device, in accordance with at least some embodiments. The process 1800 of fig. 18 may be performed by at least the user device 106 described with respect to fig. 13. More specifically, process 1800 of fig. 18 is depicted as being performed by a user device seeking access rights to an electronic device.

Process 1800 may begin at 1802 when a request to obtain access rights to an electronic device is received at a transferee user device. In some embodiments, the request may be received from a user of the user device via a graphical user interface. For example, after entering the wireless communication range of the electronic device, the transferee user device may detect the electronic device. The user may be enabled to select an option to purchase or rent the electronic device via a graphical user interface executing on the transferee user device, and upon the user making such a selection, the transferee user device may receive a request to purchase or rent.

At 1804, process 1800 may involve transmitting a request for access rights to the transferor user device. In some embodiments, the request is transmitted directly between the transferee user device and the transferee user device. In some embodiments, the request is first transmitted by the transferee user device to the mobile application server, and the mobile application server then forwards the request to the transferor user device after identifying the transferor user device as currently associated with the electronic device.

At 1806, process 1800 may involve receiving a device key associated with the electronic device. In some embodiments, the device key may be included within an encrypted data packet that is accessible by the electronic device. In other words, the transferee user device may be prevented from accessing the device keys stored in the encrypted packets. In some embodiments, the encrypted data packet may include at least one dynamic data element. For example, the at least one dynamic data element may be a counter value that is incremented or decremented with each grant of access rights. In this example, even though the encrypted packet includes a valid device key, the command accompanying the encrypted packet may not be executed as follows: the encrypted packet includes a counter value that is less than or greater than a current counter value stored in the electronic device. In another example, the at least one dynamic data element may include a device identifier of the transferee user device. In this example, even if the encrypted packet includes a valid device key, the command issued by the user device whose identifier does not match the device identifier of the transferee user device may not be executed.

At 1808, process 1800 may involve storing the received device key in local memory. In some embodiments, the user device may store a plurality of different device keys in the local memory, wherein each device key is mapped to a corresponding electronic device (e.g., via an electronic device identifier).

At 1810, the process 1800 may involve providing a command to an electronic device after receiving an instruction to issue a command to the electronic device, after confirming to the electronic device that the user device has a corresponding device key, or by providing the corresponding device key with the command. As described elsewhere, the device key may be provided to the electronic device within an encrypted package that may be decrypted by the electronic device using a cryptographic key stored in a memory of the electronic device.

Embodiments of the present disclosure provide a number of technical advantages over conventional systems. In particular, embodiments of the described system enable access rights (enabled via a device key) of an electronic device to be transferred between accounts automatically and on behalf of a transferor or transferee with minimal effort. Additionally, each party to the transaction can remain relatively anonymous to the other party while ensuring that transfer of access rights can be performed in a secure manner. The system also ensures that access rights are granted quickly and without the risk that the user cannot provide these access rights. Additionally, some embodiments also prevent the previous owner from retaining access rights to the electronic device after the electronic device has been sold, which may also prevent the previous owner from effectively resoling the previously sold electronic device to another party. The system provides a clear title chain that can be used to verify both: current ownership and electronic devices have not been obtained illegally.

Furthermore, in some embodiments of the systems described herein, access rights to an electronic device may be transferred between users without the two users meeting. For example, a user in the vicinity of an electronic device may detect the electronic device via a short-range communication protocol in his or her user device. Upon detecting the presence of such an electronic device, the user may decide to initiate a purchase or lease of the electronic device by submitting a request to a remote server. The remote server may then forward the request to the current owner of the electronic device, and the user may approve or reject the request without having to meet the requester.

FIG. 19 depicts a flow diagram illustrating a process 1900 for electronic device rental in accordance with at least some embodiments. The process 1900 of fig. 19 may be performed by at least a system including the mobile application server 108 and the registry network node 1302 as described with respect to fig. 13. More specifically, process 1900 of fig. 19 is depicted as being performed to manage access rights associated with a rental of an electronic device.

Process 1900 may begin at 1902 when a request to rent a second electronic device is received from a first electronic device while at least one function of the second electronic device is in a locked state. In some embodiments, the first electronic device is a user device 106 operated by a user to request rental. An example of how the request may be placed via the graphical user interface of the user device 104 is shown in fig. 7.

At 1904, process 1900 may update the transaction record to include information related to the rental transaction. In some embodiments, the access rights of the first electronic device are verified and the blockchain ledger is updated to include information about the access rights, the second electronic device, the lease, the first electronic device, and/or the user of the first electronic device. Payment information (including deposit values identifying the payment instrument and applied to the payment instrument) may also be received and included in the blockchain ledger. In an example, the PoS protocol is used to mortgage a deposit.

At 1906, process 1900 may generate first unlock information based on the request and information associated with the second electronic device. In some embodiments, based on the information about the second electronic device (e.g., UPC, extended UPC, and/or serial number) and the information about the lease (e.g., lease date and time), the mobile application server 108 may determine and/or generate a device key (which may itself be variable) and/or a dynamic data element (e.g., which may itself also be variable, such as lease date and time). The first unlocking information may include a device key and/or a dynamic data element. The mobile application server 108 may also encrypt the first unlock information using the public encryption key of the second electronic device.

At 1908, process 1900 may cause at least one function to be unlocked by sending at least first unlock information to the first electronic device. If the first unlocking information corresponds to second unlocking information determined by the second electronic device, at least one function is unlocked. In some embodiments, the mobile application server 108 only sends the first unlocking information to the first electronic device. Further, the first electronic device transmits the first unlock information to the second electronic device. In response, the second electronic device determines and/or instantaneously generates second unlock information from its memory for comparison with the first unlock information to determine a correspondence. After determining the correspondence, the second electronic device may be unlocked. In other embodiments, the mobile application server 108 sends the first unlock information to the first electronic device and the second electronic device. The second electronic device stores the received information as second unlocking information. The first electronic device sends the received first unlocking information to the second electronic device, and the second electronic device compares the first unlocking information with the stored second unlocking information to determine the corresponding relation.

At 1910, process 1900 may determine the completion of the lease. In some embodiments, the user may send a request indicating that the rental has ended and that the second electronic device has been returned by operating the first electronic device. The mobile server application 108 may receive the request and trigger the registry network node 202 to update the transaction record, among other things.

At 1912, process 1900 may update the transaction record. In some embodiments, the registry network node may update the blockchain ledger to indicate that the user no longer has access. The update may also indicate a status of the second electronic device and a deposit value returned to the user.

At 1914, the process 1900 may cause at least one function of the second electronic device to be locked. In some embodiments, the mobile application server 108 may send a lock instruction and/or new unlock information to the second electronic device. Additionally or alternatively, the previously transmitted unlock information may include an expiration date and time. The second electronic device may be automatically deactivated after the second electronic device determines that the rental has expired based on the expiration date and time.

FIG. 20 depicts a simplified block diagram of a benefit denial system for an electronic device in accordance with at least some embodiments. As shown, the benefit denial system includes a plurality of electronic devices 102 (1), a plurality of access devices 104 (1), a plurality of access devices 102 (N), a plurality of access devices (K), a mobile application server 108, and a beacon device 112. Multiple electronic devices 102 (1),. The.i., 102 (N) may be located within a retail location for purchase (or similarly, for rental). Multiple access devices 104 (1),. The..., (K), and beacon devices 112 may also be located within a retail location.

Each access device 104 may communicate with the electronic device 102, the beacon device 112, and the mobile application server 108, where the communications may use different communication mechanisms. For example, the communication with the electronic device 102 may use bluetooth, BLE, RFID technology, or may simply be a bar code or QR code scan of a tag attached to the electronic device 102 (or a container including the electronic device 102). Communication with the beacon device 112 may be through a wired ethernet connection, a wireless WiFi connection, a bluetooth connection, a BLE connection, or some type of short range communication. Communication with the mobile application server 108 may typically be through a data network, such as a public network (e.g., the internet) and/or a private network (e.g., an intranet), and may rely on TCP/IP communication protocols.

Similarly, the beacon device 112 may communicate with the electronic device 102, each access device 104, and the mobile application server 108, where the communications may also use different communication mechanisms. For example, communication with the electronic device 102 may use bluetooth, BLE, or some type of short range wireless communication. Communication with the access device 104 may be through a wired ethernet connection, a wireless WiFi connection, a bluetooth connection, a BLE connection, or some type of short-range communication. Communication with the mobile application server 108 may typically be through a data network and may rely on TCP/IP communication protocols.

By showing interactions between the various components of the benefit denial system, consider the following scenario. The user may enter a retail store and the user may select the electronic device 102 for purchase and may take the electronic device 102 to a POS terminal (e.g., access device 104) to complete the purchase. After receiving the payment and before completing the purchase transaction (e.g., at the POS terminal), the electronic device 102 may be unlocked using the unlock information. After the electronic device 102 is unlocked, the purchase transaction may be completed by, for example, printing a receipt and/or displaying a message regarding completion at the POS terminal.

In one potential scenario, the access device 104 may receive an extended UPC of the electronic device 102 at step S110. For example, a scan of the extended UPC is performed or the extended UPC is transmitted from the electronic device 102 to the access device 104 using one or other of the communication mechanisms shown above. At step S112, the access device 104 may send the extended UPC to the mobile application server 108. After determining the serial number (or a portion of the serial number) of the electronic device 102 based on the extended UPC and determining that the serial number (or a portion thereof) corresponds to a product provided at the retail location, the mobile application server 108 instructs the access device 104 to proceed with the payment process and to receive confirmation that the payment has been processed, also shown at step S112. After determining that payment has been completed, at step S114, mobile application server 108 may instruct beacon device 112 to unlock electronic device 102 (or at least a function thereof), and may receive an indication of successful activation back from beacon device 112. At step S116, the beacon device 112 may activate the electronic device 102 to subsequently send an indication of successful activation to the mobile application server 108. Activation may include, for example, sending first unlock information to the electronic device 102 such that the electronic device 102 may compare the first unlock information to second unlock information stored in its memory or generated instantaneously. Thereafter, at step S118, the mobile application server 108 may instruct the access device 104 to complete the transaction, and may receive an indication of the completion of the transaction back from the access device 104.

In the above example, the extended UPC code is shown to include a serial number associated with a single electronic device. However, embodiments of the present disclosure are not limited thereto. Alternatively, the serial number may be associated with multiple electronic devices 102 (e.g., a bundle package that includes the electronic devices 102). Thus, based on the UPC code, the mobile application server 108 may extract the serial number, determine the electronic devices 102 associated with the serial number, determine whether each of these electronic devices 102 needs to be activated, and determine corresponding unlock information for the electronic devices 102 that need to be activated.

Fig. 21 depicts a process 2100 for sending and using a device key to issue a command to an electronic device 102 in accordance with at least some embodiments. Some or all of process 2100 may be performed under control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). In accordance with an embodiment of the present disclosure, process 2100 of FIG. 21 may be performed by components of the benefit denial system of FIG. 20, including at least electronic device 102, access device 104, mobile application server 108, and beacon device 112. The code may be stored on a computer readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer readable storage medium may be non-transitory.

The process 2100 may begin at 2102 when an extended UPC is provided from a product to the access device 104 (e.g., by scanning a UPC code). The product may include a single electronic device 102 or multiple electronic devices 102 as part of a bundled package. In some embodiments, an operator of the access device 104 may scan for an extended UPC, where the extended UPC may be attached to a product or to a container (e.g., box or package) that includes the product. In some embodiments, at 2104, the access device 104 can be configured to transmit the extended UPC to the mobile application server 108. In turn, the mobile application server 108 may extract the serial number(s) (or portions thereof) associated with the product (e.g., with a single electronic device 102 or with multiple electronic devices forming a bundled package) from the extended UPC and may request the beacon device 112 to determine whether each electronic device 102 of the product is detected at 2106. The mobile application server 108 may also generate and store local data including store ID, cashier ID, transaction ID, serial number(s) (or portions thereof), UPC, time and date. The request may include the extracted serial number (or portion thereof) (or, in the case of a bundle package, multiple serial numbers or portions thereof).

The request may trigger the beacon device 112 to perform a scan (e.g., a bluetooth scan or BLE scan). Upon receiving the advertisement packet(s) (e.g., bluetooth advertisement beacon or BLE advertisement beacon) from the electronic device 102, the beacon device 112 may extract an identifier (e.g., a sequence number or portion thereof) of each electronic device 102 from the advertisement packet(s) and may compare the identifier to the extracted sequence number(s) (or portion(s) thereof) received from the mobile application server 108. In an example, the request may trigger the beacon device 112 to perform scanning, searching, and matching functions. The functions may include scanning the advertisement package, filtering out only the manufacturing code of the product, searching for electronic tool(s) that match the serial number(s) (or portion(s) thereof) in the extended UPC, and returning search results that may contain the Media Access Control (MAC) address(s) of such electronic device.

At 2108, beacon device 112 transmits search results indicating the comparison results. If there is a match, the search result may be affirmative, indicating that a product (each of the electronic devices 102 thereof) was detected. Otherwise, the search result is negative, indicating that no electronic devices are detected (or that all electronic devices 102 of the product are not detected). In the case of a negative search result, mobile application server 108 may send instructions to access device 104 at 2110 to stop the transaction involving electronic device 102. For example, the instructions may be displayed to an operator and may include information to remove the electronic device 102 from the shopping cart. In some embodiments, the search results may simply indicate the detected electronic device(s) 102 (e.g., their MAC address). In such an embodiment, the mobile application server 108 may examine the search results and determine whether each electronic device 102 of the product was found. If the product is found correctly, the access device 104 is notified to proceed with the payment. Otherwise, the access device 104 is notified that the product (e.g., the electronic device 102 or the bundle package, as the case may be) should be removed. Mobile application server 108 may also append search results to the local data.

Assuming the search results are affirmative, at 2110 the mobile application server 108 may send instructions to the access device 104 to proceed with payment. The instructions cause the access device 104 (e.g., POS terminal) to send information about the payment instrument to a clearing house or financial institution, and receive confirmation that the payment has been processed and/or receive cash payment. After payment is completed, the access device 104 sends an indication of the payment result to the mobile application server 108 at 2112. In turn, the mobile application server 108 determines that activation of the product is to be performed. For example, the serial number(s) (or portions thereof) are associated with information indicating that each electronic device 102 is a device type that is operable only in an unlocked state and that the electronic device 102 is currently in a locked state. This information is accessible by the mobile application server 108 and can be queried using the serial number(s) (or portions thereof).

To activate the electronic device, in some embodiments, the mobile application server 108 is configured to send an activation request to the beacon device 112 at 2114. Different types of information may be included in the activation request. In an example of the first type of information, the activation request includes unlock information (e.g., a variable device key and/or a dynamic data element). In this example, the beacon device 112 may use the unlock information to directly activate the electronic device 102. In an example of the second type of information, the activation request includes an identifier (e.g., a unique identifier such as a MAC address) of the electronic device 102. In this example, the beacon device 112 may use the identifier to indirectly activate the electronic device 102. Specifically, based on the identifier, the beacon device 112 may write unlock information to the electronic device 102 and send the information to the mobile application server 108. Thereafter, the mobile application server 108 may communicate the unlocking information to the user device 106 (not shown in fig. 21) for subsequent communication between the user device 106 and the electronic device 102 to complete the activation.

Activation may also include beacon device 112 sending activation information to each electronic device 102 of the product at 2116. Referring back to direct activation, the activation information may include unlocking information. Thus, the electronic device 102 may receive the unlock information for comparison with second unlock information pre-stored in a memory of the electronic device 102 or generated instantaneously by the electronic device 102. If a correspondence is determined, the electronic device 102 returns an acknowledgement of activation and/or an indication that the received unlock information has been verified at 2118. Referring back to indirect activation, the activation information may request a cryptographic random key (or some other type of unlocking information) from the electronic device 102. Further, the beacon device 112 may generate a password (or some other type of unlock information) based on the key and may write the password to the memory of the electronic device 102. Upon successful writing, the electronic device 102 may send a confirmation and/or verification of activation completion at 2118. In both types of activations, the beacon device 112 may use an identifier (e.g., a MAC address) to connect to the electronic device 102 (e.g., establish a communication session using bluetooth or BLE), read a current ownership status of the electronic device 102 (e.g., the electronic device 102 has not been assigned an owner, has not been stolen, or is of some type of anti-theft status), update the ownership status (e.g., by writing a sell status in a memory of the electronic device 102), and then disconnect from the electronic device 102. When the product includes multiple electronic devices 102, the exchange of information between the beacon device 112 and the electronic devices 102 may be sequential, whereby the beacon device 122 activates a single electronic device 102 at a time. Alternatively, the information exchange may be parallel, whereby the beacon device 112 activates multiple electronic devices 102 simultaneously.

In some embodiments, after completing the activation process using the product, the beacon device 112 is configured to send the activation result to the mobile application server 108 at 2120. If the activation fails, the activation result indicates a negative activation. If the activation is successful, the activation result indicates a positive activation. In this case, and referring back to indirect activation, the activation result may also include a key and/or password (or other type of unlock information) written to the memory of the electronic device 102. In the case of multiple electronic devices 102 included in a product, the activation result may be specific to each electronic device 102.

Depending on the activation result, mobile application server 108 may send transaction instructions to access device 104 at 2122. If the activation result is negative, the transaction instructions indicate that the activation failed and request retries using the same or another product. Such transaction instructions may be displayed at the access device 104 so that an operator may perform a retry. If the activation result is affirmative, the transaction instructions indicate that the activation was successful. This type of transaction instruction may trigger the access device 104 to print a receipt indicating that the transaction is complete and/or to display a message regarding successful activation. In addition, mobile application server 108 may record the local data and activation results in a data log. In some embodiments, the data log includes a blockchain ledger.

In the case of indirect activation, the receipt and/or message may include a password(s) (or other type of unlocking information) such that a user purchasing the electronic device 102 may operate their user device 106 to enter the password(s) (or other type of unlocking information) in order for the user device 106 to unlock the product. Alternatively, the receipt and/or message may merely indicate that the activation was successful, and in response, the user may operate their user device 106 to request the password(s) (or other type of unlocking information) from the mobile application server 108 in order to unlock the product.

Fig. 22 depicts another process 2200 for sending and using a device key to issue a command to an electronic device in accordance with at least some embodiments. Process 2200 is similar to process 2100 of fig. 21, as indicated with the same element numbers. For brevity, similarities are not repeated here, but apply equally to process 2200. Unlike the system for performing process 2100 of fig. 21, in the system for performing process 2200, beacon device 112 and access device 104 are integrated into a single device. In this integration, the beacon device 112 is configured as a communication interface to the electronic device 102, and the access device 104 is configured as a communication interface with the mobile application server 108, among other things. Thus, information exchange with the electronic device 102 that the user is purchasing typically occurs via the beacon device 112, while information exchange with the mobile application server 18 occurs via the access device 104.

As shown, rather than mobile application server 108 directly requesting beacon device 112 to determine whether a product is detected, the request is sent to access device 104 at 2106 (a), and access device 104 then passes the request to beacon device 112 at 2106 (B). Similarly, rather than beacon device 112 sending the search results directly to mobile application server 108, the search results are communicated to access device 104 at 2108 (a), and access device 104 then sends the search results to mobile application server 108 at 2108 (B). Further, the mobile application server sends an activation request to the access device 104 at 2114 (a), and the access device 104 then passes it to the beacon device 112 at 2114 (B). The beacon device 112 then causes the electronic device 102 to be activated (using any of the techniques described above in connection with fig. 21) at 2116, and the electronic device responds to the beacon device 112 with an indication of whether the activation was successful (using any of the techniques described above in connection with fig. 21) at 2118. As to the activation result, the beacon device 112 communicates the activation result to the access device 104 at 2120 (a), and then the access device 104 sends the activation result to the mobile application server 108 at 2120 (B).

Fig. 23 depicts a flowchart that shows a process for sending and using a device key to issue a command to an electronic device 102 in accordance with at least some embodiments. The process 2300 of fig. 23 may be performed by at least the benefit denial system (including the mobile application server 108) as described with respect to fig. 20. For clarity of explanation, a single electronic device is described as being activated. However, process 2300 is similarly applicable to activating a product, where the product may include a bundle of electronic devices 102. In this case, the extended UPC of the product may be associated with the electronic device 102 to be activated according to the process 1300.

Process 2300 may begin at 2302 when a transaction indication is received for a sale of an electronic device at a point-of-sale device when at least one function of the electronic device is in a locked state that may be unlocked based on unlock information. In some embodiments, the transaction is a purchase of the electronic device. The indication may be received from a point-of-sale device and may include a UPC or an extended UPC. The unlock information may be a device key, a dynamic data element, or other type of unlock information (e.g., a password generated from a random key as described herein in fig. 21).

At 2304, process 2300 may authorize payment for the sale. In some embodiments, mobile application server 108 determines a serial number of the electronic device based on the indication and requests a beacon device that interfaces or integrates with the point-of-sale device to detect the electronic device. Based on the scanning capabilities of the beacon device, the beacon device sends the search results back to the mobile application server 108. The search results may indicate that the electronic device was detected, or may include a detected device identifier, such that the mobile application server 108 may determine that the electronic device was detected. Based on this detection, mobile application server 108 may instruct the point-of-sale device to proceed with the payment process.

At 2306, process 2300 may receive an indication that payment was received. In some embodiments, after the payment process is completed, the point-of-sale device may send an indication that the payment was received to mobile application server 108.

At 2308, process 2300 may cause at least one function to be unlocked based on the unlocking information. In some embodiments, the mobile application server 108 sends an activation request to the beacon device. The activation request may include unlock information. Alternatively, the activation request may trigger the beacon device to generate unlock information (e.g., as a password based on a key received from the electronic device), and such unlock information or a seed thereof (e.g., a key) may be sent to the mobile application server 108. In both examples, the unlock information may be used by the electronic device to activate at least one function.

At 2310, process 2300 can cause the point-of-sale device to present an indication that the transaction is completed based on at least one function being unlocked. In some embodiments, mobile application server 108 receives an activation result from the beacon device, wherein the activation result indicates that activation is complete. Based on the activation result, the mobile application server 108 sends transaction information to the point-of-sale device, wherein the transaction information causes the point-of-sale device to print a receipt indicating that the transaction is complete, display a message indicating that the transaction is complete, and/or perform another action indicating that the transaction is complete to the point-of-sale device and/or purchaser of the electronic device.

Embodiments of the present disclosure provide a number of technical advantages over conventional systems. For example, embodiments of the present invention may enable an owner of an electronic device to lock and unlock the electronic device in a manner that deprives any unauthorized user of the benefit of the electronic device. When such an electronic device is locked, it remains locked until the electronic device is unlocked using the secret device key. As a result, a device that is stolen while locked is almost literally to any potential thief. The disclosed system deters theft of electronic devices by reducing the value of the electronic device to potential thieves. In the event that a thief becomes aware that a particular resource provider locks all electronic devices prior to making a legitimate purchase, such thief is likely to steal from other resource providers.

Additionally, the system enables new functionality to be implemented in existing electronic devices. Employees may lock or unlock their tools after entering/leaving the job site, which may result in reduced accidents due to unintentional tool activation. Owners of tools may rent or lend their tools because they know that the tools will lock after the rental period expires, thereby ensuring that failing to return the tools does not benefit the lendee. Those skilled in the art will recognize many additional benefits obtained from the systems described herein.

Other variations are within the spirit of the invention. Thus, while the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention, as defined in the appended claims.

The use of the terms "a" and "an" and "the" and similar referents in the context of describing the invention (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted. The term "connected" should be interpreted as including in part or in whole, attached, or combined together, even if there are some intermediaries. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Preferred embodiments of this invention are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, the invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. An electronic device, the electronic device comprising:

a functional component for performing at least one function of the electronic device;

A first power source adapted to be coupled to the functional component to power the at least one function of the electronic device; and

a benefit rejection element, the benefit rejection element comprising:

a communication element for communicating with a second electronic device to receive a command and information indicating whether the second electronic device has access to second setting unlock information;

a memory adapted to store computer readable instructions; and

a processor configured to execute the computer-readable instructions, wherein execution of the computer-readable instructions by the processor configures the benefit denial element to:

determining first unlock information of the benefit rejection element; and

after determining that the second electronic device has access to the second unlock information and that the second unlock information corresponds to the first unlock information, selectively disabling or enabling the at least one function of the electronic device according to the received command.

2. The electronic device of claim 1, wherein the first unlock information comprises a first key, wherein the second unlock information comprises a second key, and wherein determining that the second unlock information corresponds to the first unlock information comprises determining a match between the second key and the first key.

3. The electronic device of claim 1, wherein the second unlock information comprises a dynamic data element.

4. The electronic device of claim 3, wherein the dynamic data element comprises at least one of: a device identifier, ownership data, or date of the second electronic device.

5. The electronic device of claim 1, wherein the execution of the computer-readable instructions by the processor further configures the benefit denial element to:

storing the first unlocking information in the memory;

receiving updated unlocking information; and

the updated unlock information is stored in the memory in place of or in addition to the first unlock information.

6. The electronic device of claim 1, wherein the benefit rejection element is configured to selectively disable or enable the at least one function by selectively sending at least a disable command or an enable command to the feature.

7. The electronic device of claim 1, further comprising a system on a chip (SoC), wherein the SoC includes the functional component, the benefit rejection element, and an interface between the functional component and the benefit rejection element.

8. The electronic device of claim 7, wherein the feature is configured to disable the at least one function upon determining that there is no communication with the benefit denial element through the interface.

9. The electronic device of claim 1, wherein the benefit rejection element is configured to selectively disable or enable the at least one function by at least selectively decoupling the first power source from the functional component or coupling the first power source to the functional component.

10. The electronic device of claim 1, further comprising:

a second power source configured to power the benefit rejecting element even if the first power source is not coupled to the functional component or is otherwise prevented from powering the functional component.

11. The electronic device of claim 10, wherein the second power source is configured to draw power from the first power source.

12. The electronic device of claim 10, wherein the benefit rejection element is further configured to:

determining that the at least one function is in an unlocked state based on determining that the second electronic device has access to the second unlock information and that the second unlock information corresponds to the first unlock information; and

The power supply of the benefit rejecting element is set to the first power supply instead of the second power supply based on the unlock state.

13. The electronic device of claim 10, wherein the second power source is configured to inductively receive power from an external power source and transmit power to the benefit rejecting element.

14. A system, the system comprising:

one or more processors; and

one or more memories storing instructions that, when executed by the one or more processors, configure the system to:

receiving, at a point-of-sale device, an indication of a transaction for sale of an electronic device when at least one function of the electronic device is in a locked state and capable of being unlocked based on unlock information;

authorizing payment for the sale;

receiving an indication that the payment was received;

causing the at least one function to be unlocked based on the unlocking information; and

causing the point-of-sale device to present an indication that the transaction is completed based on the at least one function being unlocked.

15. The system of claim 14, further comprising an access device configured to selectively unlock the at least one function.

16. The system of claim 15, wherein the access device is communicatively coupled with a plurality of point-of-sale devices.

17. The system of claim 15, wherein the point-of-sale device is configured to provide the indication of the transaction, and wherein upon execution of at least some of the instructions, the system is further configured to:

determining an identifier of the electronic device based on the indication of the transaction;

transmitting the identifier to the access device;

receiving an indication from the access device that the identifier is received from the electronic device.

18. The system of claim 15, wherein the indication of the transaction comprises an extended Universal Product Code (UPC), and wherein the unlocking information is based on the extended UPC.

19. The system of claim 18, wherein upon execution of at least some of the instructions, the system is further configured to:

transmitting the unlocking information to the access equipment; and

unlocking the at least one function by sending at least the unlocking information from the access device to the electronic device.

20. The system of claim 15, wherein the system is further configured for: and unlocking the at least one function if the unlocking information corresponds to other unlocking information determined by the electronic device.

21. One or more non-transitory computer-readable media storing instructions that, when executed on a system, cause the system to perform operations comprising:

receiving a request from a first electronic device to rent a second electronic device when at least one function of the second electronic device is in a locked state;

generating first unlocking information based on the request and information associated with the second electronic device; and

and if the first unlocking information corresponds to second unlocking information determined by the second electronic device, unlocking the at least one function by sending at least the first unlocking information to the first electronic device.

22. The one or more non-transitory computer-readable media of claim 21, wherein the first unlocking information comprises a first key associated with the second electronic device, wherein the second unlocking information comprises a second key associated with the second electronic device, and wherein the at least one function is unlocked if a correspondence exists between the first key and the second key.

23. The one or more non-transitory computer-readable media of claim 21, wherein the first unlock information comprises a first counter of the second electronic device that is leased, wherein the second unlock information comprises a second counter of the second electronic device that is leased, and wherein the at least one function is unlocked if there is a match between the first counter and the second counter.

24. The one or more non-transitory computer-readable media of claim 21, wherein the request includes a rental time, wherein the first unlock information includes the rental time, and wherein causing the at least one function to be unlocked includes causing the at least one function to remain unlocked until the rental time expires, wherein the second electronic device is configured to receive the first unlock information and determine the rental time from the first unlock information.

25. The one or more non-transitory computer-readable media of claim 21, wherein the operations further comprise:

the leased record is appended to a series of transaction records, wherein the series of transaction records includes a blockchain ledger.

26. The one or more non-transitory computer-readable media of claim 25, wherein the operations further comprise:

a deposit value for the lease based on a proof of rights protocol is included in the record.

27. The one or more non-transitory computer-readable media of claim 26, wherein the operations further comprise:

determining completion of the lease; and

if the second electronic device is returned under conditions that justify the release of the escrow value, the record is updated to indicate the release of the escrow value.

28. A method, the method comprising:

receiving, at a transferee user device, a request to obtain access rights to an electronic device associated with a transferee device, wherein the electronic device is configured such that at least one function of the electronic device is lockable to prevent use of the at least one function;

receiving, at the transferee device, first unlocking information associated with the electronic device; and

the at least one function is unlocked by sending at least the first unlocking information to the electronic device, wherein the at least one function is unlocked if there is a correspondence between the first unlocking information and second unlocking information determined by the electronic device.

29. The method of claim 28, further comprising:

requesting, by the transferee device, the first unlock information from at least one of the transferee device or a server; and

the first unlock information is received by the transferee device from the at least one of the transferee device and the server, wherein the first unlock information is sent from the transferee device to the electronic device.

30. The method of claim 29, wherein the first unlocking information is different from a third unlocking information that can be used by the transferee device to unlock the at least one function before the transferee device receives the first unlocking information.

31. The method of claim 30, wherein the third unlock information is no longer available to unlock the at least one function after the transferee device receives the first unlock information.

32. The method of claim 29, further comprising receiving, by the transferee device, query information and/or identification information identifying the electronic device from the electronic device for requesting, by the transferee device, the first unlock information from the at least one of the transferee device or the server.

33. The method of claim 32, wherein receiving, by the transferee device, the query information and/or identification information identifying the electronic device comprises scanning a machine-readable indicator identifying the electronic device and carried by the electronic device.

34. The method of claim 29, further comprising receiving, by the transferor device, query information and/or identification information identifying the electronic device from the electronic device for requesting, by the transferor device, the first unlock information from the server.

35. The method of claim 34, wherein receiving, by the transferor device, the query information and/or identification information identifying the electronic device comprises scanning a machine-readable indicator identifying and carried by the electronic device.

36. The method of claim 28, further comprising:

requesting, by the transferor device, the first unlock information from a server; and

receiving, by the transferor device, the first unlock information from the server; and

the first unlocking information is transmitted by the transferee device to at least one of the transferee device or the electronic device.

37. The method of claim 28, further comprising:

storing, by the transferor device, the first unlock information prior to receiving the request;

transmitting, by the transferee device, the first unlock information to the transferee device, wherein the first unlock information is usable by the transferee device to unlock the at least one function;

receiving, by the transferor device, a command to delete the first unlock information; and

deleting, by the transferor device, the first unlock information based on the command.

38. The method of claim 28, wherein the first unlocking information comprises a first key, wherein the second unlocking information comprises a second key, and wherein the correspondence is determined by at least determining a match between the second key and the first key.

39. The method of claim 28, wherein the first unlock information comprises a dynamic data element.

40. An electronic device, the electronic device comprising:

A benefit rejection element, the benefit rejection element comprising:

a memory adapted to store machine-readable instructions;

a second power source integrated in or on the housing of the electronic device and configured to power the benefit rejecting element even if the first power source is not coupled to or otherwise prevented from powering the functional component; and

determining first unlock information of the benefit rejection element; and

41. The electronic device of claim 40, wherein the second power source is configured to inductively receive power from an external power source and transmit power to the benefit rejecting element.