Systems and methods for secure access to assets or information using blockchain

Abstract

This provides blockchain-based systems and methods used to control access to assets or information. [Solution] The key fob system includes a mobile device or other smart device, a key fob or other e-key object, and a server. The mobile device generates an encrypted code and sends it to the key fob. The key fob sends the encrypted code to a computing device embedded in the asset. The asset authenticates the encrypted code and grants access to the asset to the key fob user. The server updates the access log of the key fob within HyperLeisure.

Description

Technical Field

[0001] The present disclosure relates to a system and method for protecting communication data using blockchain. Specifically, the present disclosure relates to a system and method for authenticating communication data before communicating the data and storing the communication data in a hyper ledger using blockchain.

Background Art

[0002] Data communication is critical in most industries. For decades, many industries have utilized satellites for data communication. These industries have invested substantial financial and human resources to protect data communication, especially when data communication is used to control access to various types of assets. Many companies and individuals have developed and continue to develop security systems to protect various types of assets from illegal or unauthorized access or entry and to protect related communication data from hacking or hijacking. Physical locks have been developed according to the needs, requirements, and characteristics of the assets. Physical keys corresponding to the physical locks have been developed as well. However, physical keys are exposed to various risks, including the risk of copying and / or theft. Furthermore, hacking techniques have been developed in counteraction to the advancement of security technology.

Summary of the Invention

[0003] The present disclosure relates to an improvement in the protection of data communication by using blockchain technology to enable unauthorized data communication or access to be easily found and traced and to provide high reliability security against unauthorized violations and potential violations for company assets or personal assets or in data communication.

[0004] One or more computer systems can be configured to perform a specific operation or action by installing software, firmware, hardware, or a combination thereof on the system that causes the system to perform an action while it is running. One or more computer programs can be configured to perform a specific operation or action by including instructions that cause a data processing device to perform an action when it is executed by that device.

[0005] One general aspect includes an e-key system. The e-key system includes a mobile device configured to generate encrypted codes, a key fob configured to receive encrypted codes from the mobile device and transmit the encrypted codes wirelessly to a computing device embedded in the asset, and a server configured to update the access log of the key fob in HyperLeisure. The computing device includes an authentication module configured to authenticate the received encrypted codes, and the computing device authorizes the user of the key fob to access the asset when the authentication module authenticates the encrypted codes. Other aspects of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform actions of the e-key system.

[0006] An embodiment may include one or more of the following features: Wireless communication may be Bluetooth communication. Mobile devices and key fobs may be paired according to the Bluetooth protocol. Asset computing devices and key fobs may be paired according to the Bluetooth protocol. The authentication module may be continuously powered by the asset. The authentication module may be an electronic circuit. Code may be encrypted by the mobile device using a public key. The authentication module may decrypt the encrypted code using a private key stored in the authentication module that corresponds to the public key. The authentication module may send an access log to the server when a network connection to the server is established. The asset may be an aircraft, ship, hovering vehicle, land vehicle, or building.

[0007] Another general aspect includes a method for granting access to an asset to a user of a key fob. This method includes: a mobile device transmitting an encrypted code to the key fob; the key fob transmitting the encrypted code wirelessly to an authentication module operating on the asset's computing device; the authentication module determining whether the encrypted code is valid; granting access to the asset when the encrypted code is determined to be valid; and denying access to the asset when the encrypted code is determined to be invalid. Other aspects of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of this method.

[0008] An embodiment may include one or more of the following features: Wireless communication may be Bluetooth. Assets and key fobs may be paired according to the Bluetooth protocol. Mobile devices and key fobs may be paired according to the Bluetooth protocol. Encrypted code may be encrypted with a public key. The method may further include an authentication module decrypting the encrypted code using a private key stored in the authentication module that corresponds to the public key. The method may further include an authentication module sending an access log to a server when a network connection to the server is established. Assets may be aircraft, ships, hovering vehicles, land vehicles, or buildings. Embodiments of the described technique may include hardware, methods or processes, or computer software stored on a computer-accessible medium.

[0009] Another general aspect includes a satellite data communication system comprising a server configured to authenticate an access key, a first station configured to transmit the access key via the server and satellite, and a second station configured to receive the access key when the server authenticates the access key and to transmit data to the first station via the server and satellite. The server stores transmission logs in Hyperlegia using blockchain. The server transmits the access key in response to a request from the first station. Other aspects of this aspect include corresponding computer systems, devices, and computer programs recorded in one or more computer storage devices, each configured to perform actions of this satellite data communication system.

[0010] An embodiment may include one or more of the following features: The transmission log may include an access key authentication history. The satellite may not be permitted to transmit data from a second station to the first station when the access key is not authenticated. The satellite may be permitted to transmit data from a second station to the first station when the access key is authenticated. The second station may transmit the access key to the server when it receives the access key from the first station. The access key may be encrypted by the server. The server may be further configured to encrypt the data before transmitting it to the satellite. The server may be further configured to store the encrypted data in Hyperlegia. The second station may be further configured to encrypt the data using a public key. The first station may be further configured to decrypt the data using a private key corresponding to the public key. The first and second stations may be military stations. The access key may be valid for data transmission for a period set by the server or the second station. The server may block data transmission between the first station and the second station after a set period has expired. Embodiments of the described technique may include hardware, methods or processes, or computer software stored on a computer-accessible medium.

[0011] Another general aspect includes a method for protecting satellite data communications between a first station and a second station. This method includes the first station sending an access key request to a server via satellite; the first station receiving an access key from the server; the first station transmitting an access key to the second station; the second station transmitting an access key to the server; the server authenticating the access key transmitted by the second station; the server allowing satellite data communications between the first station and the second station when it determines that the access key is valid; and the server storing a transmission log in Hyperlegia. Other aspects of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of this method.

[0012] An embodiment may include one or more of the following features: The transmission log may include an authentication history of the access key. Transmission of data may be blocked when the server determines that the access key is invalid. The access key may be encrypted by the server. Satellite data communications may be encrypted before being transmitted to the first station. Encrypted satellite data communications may be stored in Hyperlegia. This method may further include the second station encrypting the satellite data communications using a public key before transmitting them to the first station. This method may further include the first station decrypting the encrypted satellite data communications using a private key corresponding to the public key. The access key may be valid for satellite data communications for a period set by the server or the second station. Satellite data communications may be blocked between the first station and the second station after the set period. Embodiments of the technique described may include hardware, methods or processes, or computer software stored on a computer-accessible medium.

[0013] Exemplary aspects and embodiments of this disclosure are described in more detail below with reference to the accompanying drawings.

[0014] A better understanding of the features and advantages of the disclosed technology can be obtained by referring to the following detailed description illustrating exemplary embodiments in which the principles of this technique are used. For the sake of simplicity and clarity of the illustrations, please note that the elements shown in the drawings referenced below are not necessarily drawn to actual size. [Brief explanation of the drawing]

[0015] [Figure 1] This figure shows an e-key system that provides a secure and safe form of protection against unlawful or unauthorized access to assets, as described in this disclosure. [Figure 2] This is a block diagram showing the server in Figure 1 that uses blockchain technology according to the manner of this disclosure. [Figure 3] This block diagram shows the procedure for generating a block using blockchain technology according to the aspect of this disclosure. [Figure 4] This is a block diagram showing a user interface displayed on the smart device shown in Figure 1, according to an aspect of this disclosure. [Figure 5] This is a sequence diagram showing the communication procedure of the e-key system according to an aspect of this disclosure. [Figure 6] This block diagram shows a user interface for accepting / denying access to assets in the manner of this disclosure. [Figure 7] This is a sequence diagram illustrating the communication procedure for granting / denying access to a third party in the manner of this disclosure. [Figure 8] This flowchart illustrates how to control access to assets using a mobile application according to the aspects of this disclosure. [Figure 9] This flowchart illustrates a method for controlling access to a maritime vessel or aircraft according to the aspects of this disclosure. [Figure 10]A flowchart showing a method for controlling access to an asset according to an aspect of the present disclosure. [Figure 11] A block diagram showing a computing device used in the e-key system of FIG. 1 according to an aspect of the present disclosure. [Figure 12A] A block diagram showing an example key fob system according to an aspect of the present disclosure. [Figure 12B] A sequence diagram showing the communication procedure of a key fob system according to an aspect of the present disclosure. [Figure 13] A flowchart showing the operation of the example key fob system of FIG. 12A according to an aspect of the present disclosure. [Figure 14] A block diagram showing a satellite communication system using a blockchain according to an aspect of the present disclosure. [Figure 15] A flowchart showing a method for permitting / denying data communication via a satellite according to an aspect of the present disclosure. [Figure 16] A block diagram showing a military communication system using a satellite and a blockchain according to an aspect of the present disclosure. [Figure 17] A block diagram showing the application of the satellite communication system of FIG. 14 to the aviation industry according to an aspect of the present disclosure. [Figure 18] A block diagram showing the application of the satellite communication system of FIG. 14 to the marine industry according to an aspect of the present disclosure. [Figure 19] A block diagram showing an e-key architecture according to an aspect of the present disclosure. [Figure 20] A block diagram showing a general system architecture according to an aspect of the present disclosure. [Figure 21] A block diagram showing a smart chip system according to an aspect of the present disclosure. [Figure 22] A schematic diagram showing the physical layer of a smart card including a smart chip of the smart chip system of FIG. 21. [Figure 23] A schematic diagram showing the contacts of the smart chip of FIG. 23. [Figure 24]Figure 21 is a block diagram showing examples of smart chip components. [Figure 25] Figure 22 is a block diagram showing an example of a smart chip microcontroller. [Figure 26] Figure 21 is a block diagram showing the smart chip reader of the smart chip system. [Figure 27A] This flowchart illustrates a method for reading or writing to an application zone according to an aspect of this disclosure. [Figure 27B] This flowchart illustrates a method for reading or writing to an application zone according to an aspect of this disclosure. [Figure 28A] This flowchart illustrates a method for reading or writing to configuration memory according to an aspect of this disclosure. [Figure 28B] This flowchart illustrates a method for reading or writing to configuration memory according to an aspect of this disclosure. [Figure 29] This is a block diagram showing a smart chip system incorporated into the e-key system architecture according to the aspects of this disclosure. [Figure 30A] This block diagram shows an example of an input component of a biometric system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30B] This block diagram shows an example of an input component of a telecommunications system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30C] This block diagram shows an example of an input component of a supply chain management system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30D] This block diagram shows an example of an input component of a satellite system incorporated into an e-key architecture according to an aspect of this disclosure. [Figure 30E] This block diagram shows an example of an input component of an automotive system incorporated into the e-key architecture according to an aspect of the present disclosure. [Figure 30F]This block diagram shows an example of an input component of an aviation system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30G] This block diagram shows an example of an input component of a healthcare system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30H] This block diagram shows an example of an input component of a financial engineering system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 30I] This block diagram shows an example of an input component of a pharmaceutical industry system incorporated into the e-key architecture according to an aspect of this disclosure. [Figure 31] This is a block diagram showing an IoT gateway module incorporated into the e-key architecture according to an aspect of the present disclosure. [Figure 32] This block diagram shows firmware interfaces and software interfaces that may be implemented on the SBC shown in Figure 29 according to aspects of the present disclosure. [Figure 33] This block diagram shows an example of the hardware of the single-board computer (SBC) shown in Figure 29, according to an aspect of the present disclosure. [Figure 34] This is a block diagram showing an application module that can be run on the SBC of Figure 29 according to an aspect of the present disclosure. [Modes for carrying out the invention]

[0016] This disclosure relates to a system and method for protecting data communications and assets using blockchain technology. Specifically, this disclosure relates to a system and method for protecting satellite and wireless communications between mobile devices and personal or corporate assets using blockchain technology to enhance security levels and protect communication data and assets against unintended, unlawful, or unauthorized attempts to access or tamper with communication data or assets. Various aspects and aspects of data communications and asset protection will be described with reference to the diagrams shown below.

[0017] Wireless key systems have been developed, particularly in the automotive industry. These systems generally use radio signals to communicate with a vehicle. The owner of a wireless key presses a button on the key, which then transmits a radio signal to the asset's communication device, thereby communicating with that device. When the transmitted radio signal matches a code stored on the asset, the owner gains access to the asset. However, radio signals can be intercepted or hijacked by simple electronic gadgets placed near the wireless key. Anyone who intercepts a radio signal can use it to gain access to the asset without the owner's knowledge. Therefore, communication using wireless key systems is at risk of hacking or interception.

[0018] Furthermore, since the radio signals stored in wireless keys are generally predetermined or unchangeable, hackers can copy or mimic those radio signals to gain access to assets. Therefore, even predetermined radio signals are at risk of being hacked or copied.

[0019] Furthermore, data transmitted wirelessly or via wires is generally vulnerable to hacking, potentially resulting in the loss, alteration, or use of sensitive personal, financial, tactical, medical, military, or confidential data for unintended purposes. Therefore, there is a need to develop more secure and reliable forms of communication data protection and the tracking and protection of entry into or access to company or personal assets.

[0020] e-key system The e-key system can be applied to, for example, company buildings, residences, land vehicles, aircraft, or sea vessels. In various aspects, the e-key system can be applied to any asset, including company or personal buildings, assets, safes, vehicles, machinery, or any other thing that requires protection against unintended, illegal, unauthorized, or unapproved access or use (e.g., unlawful entry into a personal home or unauthorized starting of a car engine). Furthermore, the e-key system uses blockchain technology to store access or usage history on HyperLeisure, allowing all access to or use of assets to be tracked, thereby ensuring and guaranteeing security.

[0021] Furthermore, the wireless e-key communicates with a computing device embedded in or associated with the asset using end-to-end encryption (E2EE) to prevent hijacking of communication data, including the code described herein, during transmission, thereby enhancing reliability and security. While this disclosure may refer to wireless e-key systems, aspects of this disclosure may also apply to e-key systems using technologies other than wireless technology. For example, the electrical contacts of a reader device may make electrical contact with the electrical contacts of a smart chip, allowing information to be read from or written to the smart chip via a physical electrical connection.

[0022] Figure 1 shows an e-key system 100 according to an aspect of the present disclosure. The e-key system 100 includes an asset 110, which includes an entry 115, a communication device 111, and a computing device 112 communicating with the communication device 111; a smart device 120; and servers 130a to 130n, which are connected to each other via a network 140. The e-key system 100 wirelessly and selectively grants access to the entry 115 of the asset 110, or wirelessly and selectively grants use of the asset. In other aspects, the e-key system 100 may selectively grant access to the entry 115 of the asset 110 (or access to information), or may selectively grant use of the asset via a wired connection or contact (e.g., via electrical contacts).

[0023] Entry 115 may be a door or a lock. Use may be to start an engine associated with asset 110 (for example, a truck or an electric vehicle) or to power an electric motor. Specifically, if asset 110 is a land vehicle, entry 115 may be a door for boarding the land vehicle; if asset 110 is an aircraft or a sea vessel, entry 115 may be a door on the aircraft or sea vessel; or use may be to start an engine so that a user can control or steer the aircraft or sea vessel; or if asset 110 is a building or a safe, entry 115 may be one or more doors. The above list of asset 110 and associated entries 115 or uses is intended to provide examples and not to limit the scope. Other types of assets, entries, and uses that do not deviate from the spirit of this disclosure will be readily understood by those skilled in the art.

[0024] The smart device 120 acts or functions as a wireless key within the e-key system 100. The smart device 120 receives a code from one or more of the servers 130a-130n. The code may be randomly generated by the servers 130a-130n and act as an authorized key for the use of entry 115 or asset 110. The smart device 120 can receive the code wirelessly via the network 140, which can be the Internet, a local area network, a wide area network, an ad-hoc network, or any other network capable of wireless transmission of data including the code.

[0025] The smart device 120 can be a cell phone, personal digital assistant (PDA), tablet, phablet, computer, portable computer, smartwatch, or any other compatible computing device, capable of communicating with one or more servers 130a to 130n using a first wireless communication method, and capable of communicating with the computing device (not shown) of asset 110 using a second wireless communication method different from the first wireless communication method. The computing device of asset 110 can be the same computing device used to control or operate asset 110.

[0026] When smart device 120 receives a code via network 140, servers 130a-130n also transmit the code to the computing device of asset 110 via network 140 using a wireless communication method, and the computing device of asset 110 stores the code in memory, which may be incorporated into the computing device or asset 110. In this way, the computing device of asset 110 can check whether the code transmitted from smart device 120 is identical to the code stored in the memory of asset 110 or the computing device. The wireless communication method used between a communication device (e.g., a wireless transceiver) coupled to one or more servers 130a-130n and a communication device or communication electronics coupled to smart device 120 or the computing device of asset 110 may be Wi-Fi, 2G-5G GSM, TDMA, CDMA, Long Term Evolution (LTE), or any other communication method used for long-distance communication.

[0027] During code transmission, smart device 120 uses a different wireless communication method than the one used between smart device 120 or the computing device of asset 110 and one or more servers 130a-130n. This different wireless communication method may be near-field communication (NFC), Bluetooth, Bluetooth low energy (BLE), ZigBee, infrared (IR), or radio frequency identification (RFID). This list merely provides examples of wireless communication used between smart device 120 and the computing device of asset 110. However, other types of wireless communication methods may be used without departing from the spirit of this disclosure.

[0028] The communication distance between the smart device 120 and the communication device of asset 110 may be shorter than the communication distance between the smart device 120 and one or more of the servers 130a to 130n, or between the communication device of asset 110 and one or more of the servers 130a to 130n. In various embodiments, the communication device of asset 110 may be directly connected to one or more of the servers 130a to 130n when asset 110 is stationary, such as in a residential building, commercial building, laboratory, residence, etc.

[0029] Smart device 120 can use E2EE to transmit a code to the communication device of asset 110. By using E2EE, eavesdroppers are prevented from intercepting and decrypting the code. Only the true sender (i.e., the user of smart device 120) and the true receiver (i.e., the owner or user of asset 110) can encrypt and decrypt the code, respectively, thereby ensuring that communication between smart device 120 and the communication device of asset 110 is secure.

[0030] Servers 130a to 130n may have the same, similar, or different structures with respect to each other. Regardless of the structures of servers 130a to 130n, each of them may store the same hyperlegia using blockchain technology. When a computing device of asset 110 creates a transaction that reflects an event in which access to the asset is approved or denied, servers 130a to 130n store the transaction as a block in the hyperlegia, for example, as described in application no. 16 / 156570, the entire contents of which are incorporated herein by reference. Thus, when one or more transactions are sent to servers 130a to 130n, one block is created and stored in servers 130a to 130n. Details regarding block creation are described below with reference to Figure 3.

[0031] Figure 2 is a block diagram of a server 200 using a blockchain according to the embodiment of this disclosure, which can be used as each of the servers 130a to 130n in Figure 1. Server 200 may include a code generator 210, a network interface 220, an access history generator 230, a block generator 240, and a hyperleisure 250. The code generator 210 can generate a random code upon receiving a request from a smart device 120. The size of the random code can be 16 bytes, 64 bytes, 128 bytes, 256 bytes, or longer, based on a desired level of security for the asset 110, or based on security requirements specified for the asset 110. For example, the size of the random code may be 16 bytes if the asset 110 is a car or a bicycle. The size of the random code may be 32 bytes or more if the asset 110 is an aircraft. If asset 110 is a single piece of military equipment (e.g., a jet fighter or a submarine), the size can be 128 bytes, 256 bytes, or any other size appropriate for military equipment. The code can be a numeric sequence, an alphanumeric sequence, a hexadecimal sequence, or any other sequence known to those skilled in cryptography.

[0032] The random code generated by the code generator 210 is transmitted via the network interface 220 to the smart device 120 and the computing device of asset 110. The random code is then used by the computing device of asset 110 to check whether the random code transmitted from the smart device 120 matches a code stored in the memory of asset 110.

[0033] A random code can be valid for a predetermined period. After the predetermined period has elapsed, the random code may be invalidated, and access to asset 110 by using that random code may not be permitted. In order to gain access, the smart device 120 must receive another random code from the server 200.

[0034] In one embodiment, a random code may need to maintain access for all predetermined periods. In this situation, the smart device 120 receives the random code for all predetermined periods and transmits the random code to the computing device of asset 110, thereby continuously receiving access to asset 110. If the network 140 has a problem (e.g., a communication error or disconnection) and as a result wireless communication does not work between the server 200 and the smart device 120 or the computing device of asset 110, the count for the predetermined period may be stopped during the period when wireless communication does not work, and the count may be resumed after the problem is resolved.

[0035] If the communication device 111 of asset 110 has a network problem and cannot communicate with the server 200, but the smart device 120 can communicate with the server 200, the server 200 can search the hyperleger 250 to find out which code was the last code sent to the communication device 111 of asset 110, and can send that last code to the smart device 120. In this way, the smart device 120 can gain access to asset 110 in such a situation.

[0036] When a code sent from smart device 120 matches a code stored in memory 113 of asset 110, smart device 120 is granted access to asset 110. When a code sent from smart device 120 matches a code stored in memory 113, smart device 120 is denied access to asset 110. In either case, asset 110 sends the result of granting or denying access to asset 110 to server 200. The access history generator 230 then generates a log of the result. This log may include the addresses or identifiers of smart device 120 and asset 110, and may also include the result of granting or denying access to asset 110. This log may include a timestamp of when the access was granted or denied. In various embodiments, this log may include network conditions between the smart device 120 and the communication device 111 of asset 110, between the smart device 120 and the server 200, and between the communication device 111 of asset 110 and the server 200.

[0037] After the access history log is generated or updated by the access history generator 230, the block generator 240 generates blocks to be stored in the hyperleisure 250. Each block is related to the previous block. For example, Figure 3 shows how the blocks relate to each other, specifically how each block relates to the preceding block. When the current log data 310 (Data_n2) arrives at the block generator 240, the block generator 240 retrieves the hash code from the previous block 320.

[0038] A hash code is generated by a hash function. When a hash function receives data as input, it outputs a sequence of alphanumeric characters. One advantage of using a hash function is that when a second data, slightly different from the first data, is input to the hash function, the hash function will output a sequence of alphanumeric characters that is very different from the sequence of alphanumeric characters generated from the first data. For example, when the first data is "Sarah" and the third data is "Sara", the hash code generated from the first data will be very different from the hash code generated from the second data. Therefore, using hash codes further enhances security and prevents hacking.

[0039] The block generator 240 uses the current data Data_n2 of the current block 310 and the previous hash code Hash_nl of the previous block 320 as input to the hash function executed by the block generator 240. The hash function then generates the current hash code Hash_n2, and the block generator 240 generates the current block 330 by concatenating the hash code Hash_n2 with the current data Data_n2. Since the current block 330 is partially generated from the hash code of the previous block 320, every block is related to the previous block. Therefore, changing the data content of a block is impossible unless the hash codes of all blocks, starting from the first block, are changed.

[0040] Returning to Figure 2, when the current block 330 is generated, the current block 330 is stored in HyperLeisure 250. Because blockchain technology is used in HyperLeisure 250, HyperLeisure 250 is secure against potential changes to the data stored in HyperLeisure 250. Furthermore, the same HyperLeisure 250 is stored in all servers 130a-130n. Unless the hash codes of all blocks stored in all servers 130a-130n are changed almost simultaneously, it is impractical to change the data stored in HyperLeisure 250. The reason behind the almost simultaneous changes is that servers 130a-130n authenticate each block before storing each block in HyperLeisure 250. If an attempt is made to change the data in HyperLeisure 250 stored in the small group of servers 130a-130n, such an attempt will not pass the authentication process, and HyperLeisure 250 cannot be changed.

[0041] Figure 4 shows a user interface 400 displayed on the smart device 120 of Figure 1, according to an aspect of this disclosure. The user interface 400 may be displayed when a user of the smart device 120 installs and runs an application that provides wireless access to the asset's computing device. The application may be a mobile application downloadable from the Google Store for Android-based smart devices or a mobile application downloadable from the App Store for iOS-based smart devices. The application may also be found in third-party application stores.

[0042] The user interface 400 may include three buttons: an open button 410, a close button 420, and a guest access button 430. The guest access button 430 may not be visible to all users, as it may not be available to all users. The open button 410 can be used to send a request to the server 200 to open the door to an asset, the close button 420 can be used to send a request to the server 200 to close the door, and the guest access button 430 can be used to send a request to the server 200 to grant permission to another user to use the asset.

[0043] The process shown in Figure 5 begins when the user clicks either the open button 410 or the close button 420. In block 510, the smart device sends a request to the server to open or close the asset's door. Upon receiving the request, the server generates a code (e.g., a random code) and sends that code to the smart device in block 520 and to the asset's computing device in block 525. The transmission of the generated code to the smart device and the asset can be performed simultaneously or sequentially.

[0044] The length of the code may depend on the level of security implemented in the asset and / or the security requirements defined in the asset.

[0045] When a smart device receives a random code, it encrypts the random code and, in block 530, sends the encrypted code to the asset using E2EE. The asset decrypts the encrypted code and checks whether the decrypted code matches the code received from the server. If they match, the asset, in block 540, accepts that the smart device user can open / close the asset. If they do not match, the asset, in block 540, rejects that the user can open / close the asset. The acceptance / rejection result is also sent to the server in block 545.

[0046] When the guest access button 430 is clicked, another user interface 600, as shown in Figure 6, can be displayed on the smart device. The user interface 600 includes a list of third parties, which have been previously added to the list by the smart device user. The smart device user can add or remove third parties from the list. In various embodiments, the smart device user may be the owner, administrator, or operator of the asset and may have the authority or power to grant access to the asset to a person.

[0047] This list includes people's names and status buttons indicating acceptance / rejection right next to their names. For example, as shown in Figure 6, the smart device user has neither accepted nor rejected Alan Smith and Sophia Zeller, meaning that Alan Smith and Sophia Zeller are not permitted to open or close the property's door. In contrast, Eva Christine and Harper Leon are accepted, meaning that Eva Christine and Harper Leon are permitted to open or close the property's door. Furthermore, Charlotte Dean is specifically indicated as not permitted to open or close the door.

[0048] The status button can be toggled between "Accept / Reject," "Accept," and "Reject." Thus, a smart device user can identify the third party's status by clicking the status button. In various embodiments, there are "Accept / Reject," "Accept," and "Reject" radio buttons, and a smart device user can select one of these radio buttons. The selection of the status between "Accept / Reject," "Accept," and "Reject" can be made in any other form that can be understood by those skilled in the art.

[0049] After completing the selection of the third party and the corresponding situation, the smart device user clicks the "Finish" button. The smart device then sends a request to the server regarding the third party. This request may include information about the third party, such as the name of the third party's smart device, physical address, email address, Internet Protocol (IP) address, telephone number, or Media Access Control (MAC) address. This list of third-party information is not intended to be exhaustive, but rather to provide examples. Further details identifying the third party may be included in this information.

[0050] A smart device can send a message to a selected third party, guiding the third party to install a corresponding mobile application and showing how to open and close the asset's door. In various embodiments, a server can send the message to a selected third party based on the information contained in the request.

[0051] When a selected third party receives a message and installs the mobile application, the user interface 400 in Figure 4 may be displayed without the guest access button 430, meaning that only the open button 410 and the close button 420 may be displayed on the selected third party's smart device. In other words, the selected third party has no authority or power to consent to or deny other third parties opening or closing the door to the asset.

[0052] When a user of a smart device selects a third party and identifies the corresponding situation as a rejection, the smart device can send a message to the selected third party's smart device informing them that the selected third party can no longer open or close the door to the asset. In various embodiments, the mobile application can be disabled so that the selected third party is unable to run the mobile application, or, when run, the mobile application can display a user interface indicating that there are no available options to select.

[0053] Figure 7 illustrates the process by which selected third parties agree or deny access to an asset, according to the embodiments of this disclosure. In block 710, the user selects a group of third parties to agree to access to the asset, clicks the Exit button, and the user's smart device sends the request to the server. In return, the server generates a random code and sends it to the user's smart device and the selected third-party smart devices, respectively, in blocks 720 and 725. Furthermore, in block 730, the server sends the random code to the asset. The transmission of the random code can be performed simultaneously or serially. In various embodiments, in block 720, the server may send a message to the user's smart device indicating, rather than the random code itself, that the random code will be sent to the selected third-party smart devices and the asset.

[0054] In block 740, a selected third-party smart device encrypts a random code and sends the encrypted code to the asset, which then decrypts the encrypted code. When the decrypted code matches a code stored in the asset, the asset accepts the entry to the selected third-party smart device in block 750 and sends the acceptance result to the server in block 755. Similarly, when the decrypted code does not match a code, the selected third-party smart device sends a rejection of the entry to the server in block 755.

[0055] In various aspects, the server or asset may send messages indicating acceptance or rejection of entry to a selected third party, allowing the user to confirm his choice of third party and situation.

[0056] Figure 8 is a graphical flowchart illustrating the acceptance or denial of entry to an asset (e.g., a car) using a mobile application running on a smart device 802, according to an aspect of the present disclosure. In block 805, the user of the smart device starts the mobile application, for example, by selecting an icon representing the mobile application displayed on the smart device's display. The mobile application displays selectable buttons, including an open button, a close button, and an access button. If the open button is selected by the user in block 810, the mobile application sends an open request to the server 852 in block 815 and receives a random code from the server 852. The mobile application encrypts the random code and, in block 820, sends the encrypted random code to the asset (e.g., a car 822), and the user is accepted into the asset by a computing device present in the asset and controlling access to the asset. Then, in block 825, the door to the asset is opened to the user of the smart device by the computing device, which completes the process performed when the open button was selected.

[0057] When the user selects the close button in the mobile application in block 830, the mobile application sends a close request to the server 852 in block 835 and receives a random code from the server 852. The mobile application encrypts the random code and, in block 840, sends the encrypted random code to the asset (e.g., car 822) and is granted permission by the computing device to close the doors to the asset. The doors to the asset are then closed by the computing device, for example, by controlling the automatic locking of car 822 to close in block 845, which completes the process performed when the close button displayed by the mobile application is selected.

[0058] When the user selects a button to access in block 850, the mobile application sends information to server 852 in block 855 that includes status information about the selected third party. If the status information about the selected third party is set to deny, server 852 prevents the selected third party from opening or closing the door to the asset in block 885.

[0059] When the status information for the selected third party is set to Accept, server 852 can send a message to the mobile application causing the selected third party's mobile device to launch the mobile application, which will display buttons including an open button and a close button. The mobile application may also display the accessible buttons in a deactivated state so that the selected third party cannot select the buttons they wish to access.

[0060] In block 865, when the selected third party clicks the open button, the mobile application on the selected third party's smart device encrypts the code received from server 852 in block 870 and sends it to the asset (e.g., car 822). A computing device present in the asset then decrypts the encrypted code and determines whether the decrypted code (e.g., a random code) matches a code stored in the computing device's memory or in memory located within or integrated with the asset. If the decrypted code matches a code stored in memory, the computing device instructs the asset in block 825 to allow the selected third party to open its door (e.g., the asset's computing device signals one or more of the asset's autolocks to transition from a locked state to an unlocked state).

[0061] A code (for example, a random code) can be sent to server 852 after the selected third party clicks the open button, or when server 852 sends a message to a mobile application running on the selected third party's smart device. In various embodiments, the message sent from server 852 to the mobile application may include a random code.

[0062] If the selected third party clicks the close button in block 875, the mobile application on the selected third party's smart device encrypts the code received from server 852 in block 880 and sends it to the asset's computing device. The asset's computing device then uses an appropriate decryption algorithm to decrypt the encrypted code and determines whether the decrypted code matches the code stored in the asset's memory. If the decrypted code matches the code stored in the asset's memory, the asset's computing device causes the asset's door to close in block 845.

[0063] Wireless acceptance or rejection of entry can be applied to ships and air chambers. Figure 9 is a graphical flowchart illustrating acceptance or rejection of entry to a ship or aircraft using a mobile application, according to an aspect of this disclosure. In the aspect of Figure 9, the smart device may be a portable electronic device 910, such as a universal serial bus (USB) device 910, which includes a display. The USB device 910 is just one example of many electronic devices that include a display and can communicate with computing devices present in or integrated with a server 922 and a ship or aircraft 932.

[0064] Ships or aircraft are generally more complex and larger than land vehicles, and therefore require a higher level of security. When a request for entry to a maritime vessel or aircraft is made, server 922 sends a random code in block 920, which may be longer than the random code used for land vehicles. The random code may be valid for a predetermined period. For example, the predetermined period may be 5 minutes, 10 minutes, 15 minutes, 20 minutes, 25 minutes, 30 minutes, or longer, depending on the requirements of the ship or aircraft.

[0065] The received random code can be displayed on the display of the portable electronic device 910. The user of the portable electronic device 910 can type the displayed random code into a ship or aircraft at block 930, or insert the portable electronic device 910 into a port on the ship or aircraft. By typing the random code or inserting the portable electronic device 910, the ship or aircraft receives the random code. In various embodiments, the portable electronic device 910 encrypts the random code and transmits the encrypted code to the ship or aircraft at block 930 using a short-range communication method such as NFC, BLE, ZigBee, IR, or RFID. In this short-range communication method, E2EE is used to ensure protection.

[0066] In block 925, the ship or aircraft also receives a random code from the server. The ship or aircraft decrypts the received encrypted code and determines whether the decrypted code matches a code stored therein. In block 960, if it is determined that the decrypted code does not match, the portable electronic device 910 is made to display "Disabled" on its screen, and as a result, in block 970, the ship or aircraft becomes uncontrollable by the user.

[0067] In block 940, when it is determined that the decoded code matches a stored code, the engine of the ship or aircraft can be powered and operated by the user of the portable electronic device 910, and as a result, in block 950, the user can take control of the ship or aircraft.

[0068] The server can use blockchain technology to store all activity in HyperLeja, including whether the control of the ship or aircraft and the results of random code input are valid or invalid. Furthermore, users can access HyperLeja via a valid random code and check all activity related to the portable electronic device 910 and the ship or aircraft.

[0069] Figure 10 is a flowchart illustrating a method for accepting or rejecting entry to an asset according to the aspects of this disclosure. Method 1000 can be stored in memory as a computer executable instruction. Method 1000 can be executed in whole or in part when a computer or processor executes a stored computer executable instruction. In this form, Method 1000 can be implemented by any electronic gadget including a processor and a storage medium.

[0070] Method 1000 begins in block 1010 by displaying selectable buttons or options on the screen of a smart display. The buttons may include Open, Close, and Guest Access. Open and Close are for opening and closing the property's door, while Guest Access is for granting one or more third parties access to the property.

[0071] Block 1015 determines which option has been selected. If it is determined that open or close has been selected, the smart device sends a request to the server in block 1020 to open or close the entry to the asset. In various embodiments, entry may mean starting the engine of a moving vehicle such as a car, hovercraft, aircraft, and ship. In other embodiments, entry may mean actual entry through its door into a stationary building such as a financial institution, business premises, private residence, and vault.

[0072] The request can include information about the smart device, such as its name, physical address, email address, IP address, phone number, or MAC address. Additionally, the selected button can be included in the request.

[0073] Smart devices can use wireless communication methods via the Internet, which may include Wi-Fi, 2G-5G GSM, TDMA, CDMA, LTE, Bluetooth, or any other communication method used for long-range communication.

[0074] The server generates a random code upon receiving a request and, in block 1030, transmits the random code to the smart device via the same communication method. The size or length of the random code can be less than, more than, or equal to 32 bytes, depending on the required level of security for the asset. The server can transmit the random code to the asset in block 1030.

[0075] The smart device encrypts a random code in block 1035 and transmits the encrypted code to the asset. The communication method used between the smart device and the asset can be a short-range communication method such as NFC, BLE, ZigBee, IR, or RFID. The short-range communication method is different from the communication method used between the smart device and the server. In this short-range communication method, E2EE is used to ensure protection. E2EE allows the smart device to encrypt the random code upon transmission. E2EE can utilize a public key system, so that only the smart device and the asset can decrypt the encrypted code, and other eavesdroppers cannot decrypt it.

[0076] Block 1035 determines whether the decoded code matches a code stored in the asset. If the decoded code matches a stored code, block 1040 accepts the request, and as a result, the user of the smart device can enter or exit the asset. Otherwise, block 1045 rejects the request, and as a result, the user is not allowed to enter or exit the asset. This concludes the open or close option displayed on the smart device.

[0077] Now, referring back to block 1015, when it is determined that guest access is selected, the user of the smart device may allow one or more third parties to open or close entry to the asset. In block 1050, the smart device displays a list of third parties previously added to the list. When the user selects one or more third parties, they can select a corresponding situation for each of the one or more third parties, which can be either accepted or rejected. By selecting the rejection situation, the user can prevent the third parties from opening or closing the door to the asset.

[0078] In block 1055, the smart device receives one or more third-party selections by the user of the smart device. In block 1060, the smart device transmits a request for one or more third-party selections. The selections may include the selected status of each selected third party. In various embodiments, the selections may further include information about the smart device of each selected third party, such as name, physical address, email address, IP address, telephone number, or MAC address.

[0079] In block 1065, the server generates a random code and sends it to each of the selected third parties based on the selected third party information. The server sends the random code to the assets, and the assets store the random code for later verification. In block 1070, each selected third party's smart device receives the random code.

[0080] In block 1075, each selected third-party smart device encrypts a random code and transmits the encrypted code to the asset. Encryption may be performed while transmitting the random code by using E2EE.

[0081] The asset decrypts the encrypted code, and in block 1080, the asset determines whether the decrypted code matches the code stored in the asset. If it is determined that the decrypted code does not match the stored code, the request is rejected in block 1045.

[0082] When it is determined that the decoded code matches the stored code, block 1040 accepts a request to open or close an entry to the asset from the selected third party.

[0083] In various configurations, after blocks 1040, 1045, and 1085, the result of accepting or rejecting a request is recorded as an access history log. A server can generate blocks using blockchain technology and store them in a hyperlegia, which is then stored on multiple servers. The hyperlegia can be accessed and retrieved by smart devices that receive random codes from the servers.

[0084] Figure 11 shows a block diagram of a computing device 1100 representing the smart device 120 or servers 130a-130n of Figure 1, according to an aspect of this disclosure. The computing device 1100 may be the portable electronic device 910 of Figure 9. The computing device 1100 includes a processor 1110, memory 1120, a display 1130, an input device 1140, and / or a network interface 1150. The memory 1120 can store one or more applications and data.

[0085] Memory 1120 is executable by processor 1110 and may include any non-temporary computer-readable storage medium for storing data and / or software that controls the operation of computing device 1100. In various embodiments, memory 1120 may include one or more solid-state storage devices, such as flash memory chips. Instead of or in addition to one or more solid-state storage devices, memory 1120 may include one or more mass storage devices connected to processor 1110 via a mass storage controller (not shown) and a communication bus (not shown). While the description of computer-readable media included herein refers to solid-state storage, those skilled in the art will understand that computer-readable storage medium may be any available medium accessible by processor 1110. That is, computer-readable storage medium may include non-temporary, volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information such as computer-readable instructions, data structures, program modules, or other data. For example, computer-readable storage media may include random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state memory technologies, CD-ROMs, DVDs, Blu-rays or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other media that can be used to store desired information and can be accessed by the computing device 1100.

[0086] Memory 1120 further includes an OS configured to control basic input / output functions and an operating system (OS) file system. A person skilled in the art will recognize that suitable operating systems include, in non-limiting examples, FreeBSD, OpenBSD, NetBSD®, Linux, Apple® Mac OS X Server®, Oracle® Solaris®, Windows Server®, and Novell® NetWare®. A person skilled in the art will also recognize that suitable personal computer operating systems or mobile operating systems include, in non-limiting examples, UNIX-like operating systems such as Microsoft® Windows®, Apple® Mac OS X®, UNIX®, and GNU / Linux®. In some embodiments, the OS is provided by cloud computing. Those skilled in the art also acknowledge that suitable mobile smartphone operating systems include, but are not limited to, Nokia® Symbian® OS, Apple® iOS®, Research In Motion® BlackBerry OS®, Google® Android®, Microsoft® Windows Phone® OS, Microsoft® Windows Mobile® OS, Linux®, and Palm® WebOS®.

[0087] The display 1130 may include a cathode ray tube (CRT), a liquid crystal display (LCD), a light-emitting diode (LED), or any other form of display. The display may be touch-sensitive and can be used as an input device.

[0088] The network interface 1150 may be configured to connect to a network such as a local area network (LAN) consisting of wired and / or wireless networks, a wide area network (WAN), a wireless mobile network, a Bluetooth network, and / or the internet. The input device 1140 can be any device that allows the user to interact with the computing device 1100, such as a mouse, keyboard, foot pedal, touch screen, and / or voice interface.

[0089] Key fob system Figure 12A shows the key fob system 1200, and Figure 12B shows an information flow diagram within the key fob system 1200 according to an aspect of this disclosure. The key fob system 1200 includes an asset 1210, a smart device 1220, a key fob 1230, and a server 1240, all of which are connected via a network. The key fob system 1200 wirelessly grants access to the asset 1210 upon receiving an encrypted code from the key fob 1230. The entry 1215 can be a door, engine, or lock. For example, when asset 1210 is a land vehicle, entry 1215 could be the door to enter the land vehicle or the engine to be started; when asset 1210 is an aircraft or a ship, entry 1215 could be the door of the aircraft or ship or the engine to be started so that a user can control the aircraft or ship; or when asset 1210 is a building or a safe, entry 1215 could be the door or lock of the building or safe, respectively. The above list of assets 1210 and entries 1215 is intended to provide examples and is not intended to limit you.

[0090] The smart device 1220 acts as a control device within the key fob system 1200. The smart device 1220 can be a smartphone, tablet, phablet, computer, mobile device, or any other suitable device that can communicate with the key fob 1230 and server 1240 via different communication methods. For example, the smart device 1220 can communicate with server 1240 via the internet and with key fob 1230 via a Bluetooth connection, wirelessly or via a wired connection.

[0091] The key fob 1230 may include one or more buttons that can be used to access asset 1210. In one embodiment, the key fob 1230 may include one button that sends an encrypted code to asset 1210 to receive access to asset 1210. In another embodiment, the key fob 1230 may include multiple buttons, each of which may be assigned to a function of asset 1210. For example, if asset 1210 is a land vehicle, ship, aircraft, or military vehicle, one button may be for starting the engine.

[0092] To enable the key fob 1230 to communicate with asset 1210 via Bluetooth communication, the key fob 1230 can be pre-programmed to pair with asset 1210. Therefore, an internet connection may not be required for communication between asset 1210 and key fob 1230. Furthermore, the smart device 1220 can be configured to pair with key fob 1230 via Bluetooth communication. Therefore, an internet connection may not be required for communication between key fob 1230 and smart device 1220.

[0093] Server 1240 can store the access history of key fob 1230 in hyperlegia stored on the computing device of asset 1210. Thus, server 1240 can use blockchain technology to generate blocks to store the access history and store the blocks in hyperlegia stored on servers 130a to 130n in Figure 1 as described above.

[0094] Returning to Figure 12B, the smart device 1220 generates an encrypted code that acts as an authorized key to entry 1215 of asset 1210. In block 1250, the smart device 1220 can transmit the generated encrypted code to the key fob 1230. In one embodiment, the smart device 1220 and the key fob 1230 can communicate with each other according to the Bluetooth protocol. In various embodiments, the smart device 1220 and the key fob 1230 can be paired via any suitable communication protocol. Thus, any nearby electronic gadget cannot hack or hijack the encrypted code transmitted from the smart device 1220 to the key fob 1230. Communication between the smart device 1220 and the key fob 1230 can use any suitable communication protocol that ensures communication is only between paired devices.

[0095] In block 1260, the key fob 1230 can transmit the received encrypted code to asset 1210. The key fob 1230 can utilize Bluetooth when transmitting the encrypted code. Since Bluetooth communication is permitted between paired devices, the encrypted code is unlikely to be exposed to hacking or hijacking. In various embodiments, the smart device 1220 can transmit the encrypted code to the key fob 1230 at all times, sporadically, at regular intervals, or upon request from the key fob 1230. In some embodiments, the key fob 1230 can switch from pairing with smart device 1220 to pairing with the computing device of asset 1210 when both smart device 1220 and asset 1210 are within communication range.

[0096] In one embodiment, the smart device 1220 can encrypt the code by using end-to-end encryption (E2EE). For example, a public key and a private key can be used for encryption. Thus, the smart device 1220 can encrypt the code using the public key, and the computing device of asset 1210 can decrypt the code received from the key fob 1230 using the private key. In this way, E2EE can add security to Bluetooth communication.

[0097] After decryption, the computing device of asset 1210 can determine whether the code received from key fob 1230 is valid. Based on this determination, asset 1210 can, in block 1270, grant or deny key fob 1230 access to asset 1210. Furthermore, in block 1280, asset 1210 sends information to key fob 1230 as an access log indicating whether key fob 1230 was granted or denied access to asset 1210. Additionally, in block 1280, asset 1210 can send all activity within the access log to smart device 1220 via key fob 1230.

[0098] In one embodiment, asset 1210 may include an authentication module that performs validity determination of encrypted code. The authentication module may be trained by artificial intelligence (AI) or machine learning as described herein.

[0099] When smart device 1220 establishes a connection with server 1240, smart device 1220 can relay access logs to server 1240 in block 1290. Server 1240 generates a block to store the access logs there and stores that block in Hyperlegia.

[0100] In one embodiment, the smart device 1220 can directly transmit encrypted code in block 1250 to asset 1210. In response, asset 1210 can accept or reject smart device 1220's access to asset 1210.

[0101] The key fob system 1200 can allow a third party to access asset 1210. Figure 13 shows an embodiment of the key fob system 1200 in which access to vehicle 1210' can be shared using a smart device 1220. As shown in Figure 13, vehicle 1210' is a vehicle, but can be other types of assets such as aircraft, ships, land vehicles, military vessels, buildings, rooms, etc. When a user of smart device 1220 installs a mobile application on it, the user must register with smart device 1220 in block 1305. Upon successful registration, smart device 1220 notifies the user of the registration in block 1310.

[0102] In block 1315, the user opens the mobile application and provides login information to the mobile application. If the login information is correct, the user may be able to log in to the mobile application in block 1320. Subsequently, one or more menus are displayed on the screen of the smart device 1220. Based on the user's selection, different functions can be performed in block 1325.

[0103] The menu list may include engine start / stop, door open / close, trunk open / close, car key, and settings. This list of menus can be expanded or reduced according to the functionality of asset 1210. When engine start is selected, smart device 1220 can send a command to asset 1210, and when this command is valid, vehicle 1210' starts its engine. When engine stop is selected and the command received from smart device 1220 is valid, vehicle 1210' stops or switches off its engine.

[0104] Similarly, when a door open / close or trunk open / close is selected and the command received from smart device 1220 is valid, the corresponding car door or trunk door can be opened or closed. The success and failure of these activities are stored in smart device 1220 and may be sent to server 1240 in block 1330 when a network connection is established between smart device 1220 and server 1240.

[0105] In one embodiment, a command may include two parts: a code and a selected function. The two parts are encrypted by the smart device 1220, and the encrypted part is sent to the vehicle 1210'. The vehicle 1210' then decrypts the encrypted part and checks whether the decrypted code is valid. If the code is authenticated, the vehicle 1210' performs the selected function.

[0106] In another embodiment, encryption and decryption can be performed using a private key and a public key. Furthermore, communication between the smart device 1220 and the vehicle 1210' can be protected within a paired device, for example, a device paired via a Bluetooth connection.

[0107] In one embodiment, the smart device 1220 can send commands to the vehicle 1210' via the key fob 1230. That is, the smart device 1220 can send encrypted code to the key fob 1230. When the user of the key fob 1230 presses one of the buttons on the key fob 1230, the key fob 1230 can add a function corresponding to the selected button to the encrypted code and send the encrypted code to the vehicle 1210'. For example, the key fob 1230 may have multiple buttons, including a first button for the car door, a second button for the car engine, a third button for the trunk door, and so on. The car door button can be used to open or close the car door. For example, each press of the button can toggle between opening the car door and closing the car door. In a further embodiment, the key fob 1230 may include two buttons for the car door. For example, one button may be for opening the car door and the other button may be for closing the car door.

[0108] When a user selects a button on the key fob 1230, the key fob 1230 can combine an encrypted code received from the smart device 1220 with a function associated with the selected button. In one embodiment, the key fob 1230 can decrypt the encrypted code received from the smart device 1220, combine the decrypted code with the selected function to generate a command, encrypt it, and send the command to the vehicle 1210'. Upon receiving the command, the vehicle 1210' can decrypt the command, separate the code and the selected function from the decrypted command, and authenticate the code. If the code is invalid, the selected function is not executed by the vehicle 1210'.

[0109] In another embodiment, the key fob 1230 can generate a command by combining an encrypted code that has not been decrypted with a selected function and transmit the command to the vehicle 1210'. In this case, the vehicle 1210' can decrypt only the encrypted code and authenticate the code.

[0110] When the user selects an access button on the screen of the smart device 1220 in block 1335, the user can accept or deny third-party access to the vehicle 1210'. A mobile application can provide the user with a list of third parties, and the user can select one or more third parties from that list to accept or deny access to the vehicle 1210'.

[0111] In block 1340, information regarding the third-party user's selection and the user's acceptance or rejection of access is sent to server 1240, and as a result, the user's selection is stored in server 1240's hyperlegitimate. In one embodiment, smart device 1220 can also send encrypted code or the public key used to encrypt the code to server 1240.

[0112] When a user grants third-party access to vehicle 1210', the third party may, in block 1345, select one of the auto key buttons displayed on the third-party smart device. The third-party smart device can communicate with server 1240 to receive an encrypted code or a public key for encryption from server 1240. In one embodiment, when the user of smart device 1220 selects an accept button, smart device 1220 may send an encrypted code to the selected third-party smart device. In another embodiment, the selected third-party smart device may receive a guest access code that can be authenticated by vehicle 1210'.

[0113] In yet another embodiment, the selected third party may receive an updated access key whenever there is a new attempt by the selected third party to access vehicle 1210'. The selected third party's access capability may be maintained until the user of smart device 1220 denies the selected third party access or until the selected third party's access key expires. In this regard, the access key may be valid for a period set by the user of smart device 1220.

[0114] Key fob 1230 is pre-programmed solely for accessing vehicle 1210'. Therefore, a selected third-party key fob cannot be used to access vehicle 1210', and the selected third party can only use their smart device to access vehicle 1210'.

[0115] In block 1350, a selected third-party smart device sends a command containing an encrypted code or guest access code to vehicle 1210', and the selected third party can access vehicle 1210' after the command is authenticated. In block 1355, the selected third-party smart device can send an access log to server 1240, which in turn allows the access log to be stored in HyperLeisure.

[0116] When a user of smart device 1220 selects a setting button in block 1360, they can change, update, or modify the current settings, personal information, information about vehicle 1210' paired with smart device 1220 via Bluetooth communication, information about key fob 1230 paired with smart device 1220 via Bluetooth communication, or other settings. Such changes, modifications, or updates can be sent to server 1240 in block 1355, and as a result, they can be stored in HyperLeisure.

[0117] When unauthorized access is identified, server 1240 can provide an alert to the user of smart device 1220 via text message, email, phone call, social networking service (SNS) message, audio alert, flashlight, or other means, enabling the user to take the correct course of action.

[0118] In another embodiment, due to the use of Bluetooth communication, the smart device 1220, the vehicle 1210', and the key fob 1230 can communicate with each other even without an internet connection. The smart device 1220 may require an internet connection to store access logs or history on the server 1240's HyperLeisure.

[0119] Satellite communication system Figure 14 shows a satellite communication system 1400 that uses blockchain to protect communication data, and Figure 15 is a flowchart showing a satellite communication method 1500 of the satellite communication system 1400 of Figure 14, according to the aspects of this disclosure. The satellite communication system 1400 can allow data communication over the satellite after authenticating an access key. Therefore, if the access key is not authenticated, data communication over the satellite is rejected and data communication is not initiated.

[0120] The satellite communication system 1400 may include a first station 1410, a second station 1420, and a server 1430. The first station 1410 can communicate with the second station 1420 via the server 1430 and satellite 1440. The authentication results of the access key are stored on the server 1430. Furthermore, the server 1430 can encrypt the data in the communication and store the encrypted data on the hyperleisure 1435. The first station 1410 and the second station 1420 may include any computer, smart device, tablet, phablet, mobile device, server, or data center that can communicate with each other.

[0121] When data is required by the second station 1420, for example, to access an asset item, the second station 1420 sends an access code request to the server 1430 via satellite 1440 in block 1510. Specifically, the second station 1420 sends the access code request by uploading the request via an uplink to satellite 1440, which then relays the request to one or more servers 1430. In one embodiment, when the first station 1410 instructs the second station 1420 to send data to the second station 1420 or to perform some task, the first station 1410 may request in block 1510 that one or more servers 1430 send an access key to the first station 1410.

[0122] Upon receiving a request, one or more servers 1430 generate an access key in block 1520 and transmit it to the second station 1420. The second station 1420 and one of the servers 1430 can communicate with each other using an end-to-end encryption (E2EE) method with a secret key and a public key. This ensures that communication between the second station 1420 and one or more of the servers 1430 is secure. Satellite parabolic antennas can be used between the second station 1420 and satellite 1440 and between one or more servers 1430 and satellite 1440 to transmit data including requests or access keys. Other communication systems and devices can be used in addition to or instead thereof, as will be readily apparent to those skilled in the art.

[0123] In block 1530, the second station 1420 transmits the received access key to the satellite 1440, and in block 1540, the satellite 1440 sends the access key to the first station 1410. After receiving the access key, the first station 1410, in block 1550, sends the received access key to one or more servers 1430 for authentication.

[0124] In block 1560, one or more servers 1430 determine whether the access key received from the first station 1410 matches an access key sent by one or more servers 1430 to the second station 1420. If the access keys are determined to match, one or more servers 1430 authenticate the received access key and notify the first station 1410 of the authentication. The first station 1410 then authorizes communication with the second station 1420. In block 1570, the first station 1410 and the second station 1420 begin communicating with each other via satellite 1440.

[0125] In block 1560, if one or more servers 1430 determine that the received access key does not match an access key that one or more servers 1430 has transmitted to the second station 1420, one or more servers 1430 inform the first station 1410 that the received access key is invalid. In block 1580, the first station 1410 rejects all communication with the second station 1420 using the received access key. If the second station 1420 is a valid station for communication, the second station 1420 may make another attempt to receive a different access code from one or more servers 1430. The satellite communication method 1500 then repeats blocks 1510 to 1580.

[0126] When authentication is successful and when authentication is not successful, one or more servers 1430 create a block relating to such a determination and store that block in Hyperlegia.

[0127] In one embodiment, when the same station continuously transmits erroneous access keys, one or more servers 1430 can create a blacklist that includes that station. One or more servers 1430 can monitor stations and assign status levels to stations based on their behavior. For example, when one or more servers 1430 determine that a station's behavior exceeds a threshold, one or more servers 1430 can change the status of that station from good to bad and / or prevent that station from accessing one or more servers 1430 until that station can provide further verification information. For example, when a station (e.g., a first station) unsuccessfully attempts to obtain one or more access keys a predetermined number of consecutive times or a predetermined total number of times (e.g., three or five times), one or more servers 1430 can recognize that station as a bad station and inform it of its updated status.

[0128] In another embodiment, an access key can be made valid for a predetermined period, so that the second station 1420 can communicate with the first station 1410 during that period, but not after that period. This can prevent a station operator with malicious intent (e.g., a hacker or hijacker) from attempting to obtain valid access in the future.

[0129] In a further embodiment, one or more servers 1430 can encrypt data communicated between a first station 1410 and a second station 1420 via satellite 1440. Specifically, when the first station 1410 transmits data to the second station 1420, it can first transmit that data to one or more servers 1430. The one or more servers 1430 then encrypt the data and store the encrypted data in HyperLeisure. Furthermore, the one or more servers 1430 send the encrypted data to the second station 1420 via satellite 1440. The data stored in the blocks of HyperLeisure can be used as reference data to check whether the data has been hacked, altered, tampered with, or removed.

[0130] In one embodiment, each block may contain a set amount of data, such as 1 megabit (MB), 10 MB, 100 MB, or any size suitable for communication purposes between the first station 1410 and the second station 1420. To conserve memory space, one or more servers 1430 do not have to create blocks periodically. Instead, one or more servers 1430 can create blocks whenever communication occurs between the first station 1410 and the second station 1420. Furthermore, to conserve memory space, one or more servers 1430 do not have to store the data communicated over satellite 1440. Instead, the first station 1410 can encrypt the data before transmitting it to the second station 1420 over satellite 1440 by using E2EE with a public key and a private key.

[0131] In another embodiment, satellite 1440 may prohibit all communications initiated by the second station 1420 when one or more servers 1430 inform it that the access code is not authenticated. Specifically, satellite 1440 may reject all data communications transmitted by the second station 1420 via the uplink. Thus, all further attempts by the second station 1420 cannot reach the first station 1410. At the same time, satellite 1440 may allow all data communications transmitted by the first station 1410 to the second station 1420. That is, all data communications to the second station 1420 via the downlink are not rejected. In this form, even if the access key from the second station 1420 is not authenticated, the first station 1410 may still be able to send data to the second station 1420 via satellite 1440. Nevertheless, the first station 1410 cannot receive data from the second station 1420 when the access key is not authenticated.

[0132] Figure 16 shows a military system 1600 using the satellite communication system 1400 of Figure 14, according to an aspect of this disclosure. In this aspect, the first station 1410 in Figure 14 is the military headquarters station 1610, and the second station 1420 in Figure 14 is the battlefield station 1620. In the same manner that the first station 1410 communicates with the second station 1420, the battlefield station 1620 communicates with the military headquarters station 1610 by using an access key obtained from and authenticated by the server 1630. A detailed explanation of the communication and authentication between the military headquarters station 1610 and the battlefield station 1620 can be found in the description above Figure 14.

[0133] When Battlefield Station 1620 receives data or orders from Military Command Station 1610 via satellite 1640, Battlefield Station 1620 can relay that data or orders to military aircraft, military ocean vessels, or military vehicles. Since the data or orders from Military Command Station 1610 are encrypted, Battlefield Station 1620 can decrypt the received data or orders and perform any task in accordance with that data or orders.

[0134] By using blockchain or HyperLeja, all access history or transmitted data can be securely stored and later retrieved as reference data for verification or authentication. Due to the inherently high security level required in military communications, communications between Battlefield Station 1620 and Military Headquarters Station 1610 can be encrypted using E2EE, which may be different from the cryptographic protocol used between Military Headquarters Station 1610 and Battlefield Station 1620.

[0135] All data returning from military vehicles to Battlefield Bureau 1620 can be sent to Military Headquarters Bureau 1610 and stored in HyperLeisure on Server 1630.

[0136] Returning to Figure 14, the first station 1410 and the second station 1420 can be servers for a corporation or private organization. For example, the first station 1410 and the second station 1420 can be research servers for any other area of ​​research, such as sociology, biology, electrical engineering, materials science, cosmology, astronomy, or science or knowledge-based research. Alternatively, the first station 1410 and the second station 1420 can be servers used for business purposes such as financial transactions, stock trading, email communications, etc. In one embodiment, the first station 1410 and the second station 1420 can be personal computers, mobile devices, tablets, or any personal computing devices used for communications over satellite 1440.

[0137] To ensure data communications are protected, access keys, along with blockchain technology, can be used for any communication between two parties, stations, computers, servers, or any combination thereof, preventing hacking and hijacking with substantial certainty and reliability. As will be readily apparent to those skilled in the art, application examples of the combination of access keys and blockchain can be used in other areas.

[0138] Applications of satellite communication systems Provided in Figure 17 is an application of the satellite communication system 1400 of Figure 14 to the aerospace industry, according to an aspect of this disclosure. The airport 1710, aircraft 1720, and server 1730 correspond to the first station 1410, the second station 1420, and one or more servers 1430 of Figure 14, respectively. The aircraft 1720 receives an access key from the server 1730 at block 1752 when the aircraft 1720 is scheduled to fly to its destination. The access key can remain valid for the duration of the flight.

[0139] Aircraft 1720 takes off from airport 1710 at block 1754 and encounters a potential hijacker at block 1756. In this case, aircraft 1720 can send an alert signal to satellite 1740 using E2EE at block 1758 and change the flight mode from manual to automatic at block 1760. Due to the imminent danger, aircraft 1720 can automatically lock its doors at block 1760. Since the alert signal is encrypted, the potential hijacker may not be able to hear the encrypted alert signal.

[0140] Satellite 1740 can transmit an alert signal to airport 1710, and airport 1710 can also transmit the alert signal to server 1730 for storage in HyperLeisure.

[0141] In block 1762, aircraft 1720 can search for a nearby airport (for example, airports 1750a and 1750b) for an emergency landing, and in block 1764, it can send a request to land to airports 1750a and 1750b. If airport 1750a rejects the request but airport 1750b accepts it, airport 1750b sends an acceptance to aircraft 1720 in block 1766.

[0142] Aircraft 1720 is directed to land at block 1768 and lands on runway 1750b at block 1770. Due to the emergency locking of the doors, passengers on board aircraft 1720 are unable to escape at this time.

[0143] Upon completion of landing, aircraft 1720 may inform airport 1710 of the landing via satellite 1740 in blocks 1772-1776. Airport 1710 may generate and encrypt an unlock code in blocks 1780-1784 and send it to aircraft 1720 via satellite 1740.

[0144] Upon receiving the encrypted unlock code, aircraft 1720 can decrypt the unlock code and unlock its doors. In this application, server 1730 can store all history, including potential hijacking events, emergency signals, unlock codes, and all related events, in HyperLeisure. Thus, by using blockchain-based HyperLeisure, data security in the aviation industry is enhanced and the risk of hijacking is reduced.

[0145] As another application of the satellite communication system 1400 in Figure 14, a marine system according to an aspect of the present disclosure is provided in Figure 18. The ground station 1810, the watercraft 1820, and the server 1830 correspond to the first station 1410, the second station 1420, and one or more servers 1430 in Figure 14, respectively. The watercraft 1820 receives an access key from the server 1830 before leaving port. The access key can remain valid for the entire voyage undertaken by the watercraft 1820.

[0146] Watercraft 1820 departs from ground station 1810 and may encounter potential pirates. In this case, watercraft 1820 can send an alert signal to satellite 1840 using E2EE at block 1872. Since the alert signal is encrypted, potential pirate ships may not be able to listen to the encrypted alert signal.

[0147] Satellite 1840 can transmit an alert signal to ground station 1810 via its satellite parabolic antenna in blocks 1876 and 1878. Ground station 1810 can transmit this alert signal to naval security authority 1860 in block 1880, which in turn instructs patrol vessel 1870 to rescue the watercraft 1820. Ground station 1810 can also send the alert signal to server 1830 for storage in HyperLeisure. Furthermore, ground station 1810 can transmit all history, including potential piracy, emergency signals, and all related events, to HyperLeisure. Thus, by using blockchain-based HyperLeisure, data used in the maritime industry is protected and the risk of piracy is minimized.

[0148] Figure 19 is a block diagram showing a wireless e-key architecture according to an aspect of the present disclosure. The wireless e-key architecture includes various basic components of the e-key system and how they are connected to collect, store, and process data.

[0149] The IoT architecture consists of the following components: things 1901 (e.g., key fobs, smart home devices, baby monitors, currency, passports, driver's licenses, and other IoT-enabled devices) equipped with sensors that collect data and / or actuators that execute commands received from the cloud 1904; gateways 1902 that filter and preprocess data, move it to the cloud 1904, and receive control data 1918 containing commands from the cloud 1904; cloud gateways 1906 that ensure data is correctly transferred between the field gateway and the control server; and a distribution of data coming from sensors among the relevant e-key system components. It may include one or more of the following: a streaming data processor 1910; a data lake 1912 that stores data including defined values, undefined values, and / or sensor data 1911; a big data warehouse that collects valuable data; a control application 1916 that sends control data 1918 including commands to actuators; machine learning 1920 that generates a model 1922 used by the control application 1916; user web applications 1932 and user mobile applications 1934 that enable users to monitor and control things 1901 connected to them; and data analysis theory 1940 for manual data processing.

[0150] Mono 1901, for example, an e-key object, may be equipped with sensors that collect data, which is transmitted via a secure network (including, for example, a Bluetooth or Wi-Fi connection) and actuators that enable the Mono to perform actions (for example, turning the engine on or off, opening or closing doors, or opening or closing the trunk).

[0151] e-key can utilize gateway 1902. Data can be transmitted between thing 1901 (e.g., an Internet of Things (IoT) enabled device) and cloud 1904 via gateway 1902. Gateway 1902 provides connectivity between thing 1901 and the cloud portion of the IoT solution, enabling protected data preprocessing and filtering before moving data to cloud 1904 (e.g., to reduce the amount of data related to detailed processing and storage), and transmits control data 1918, such as commands, from cloud 1904 to thing 1901. The thing 1901 then executes the commands, for example, using its actuators.

[0152] The e-key system can utilize the Cloud Gateway 1906, for example, the API Cloud Gateway. The Cloud Gateway 1906 facilitates data compression and protects data transmission between the Field Gateway 1902 and the IoT server in the Cloud 1904. Furthermore, the Cloud Gateway 1906 ensures compatibility with various protocols, communicating with the Field Gateway 1902 using different protocols depending on which protocols are supported by Gateways 1902 and 1906.

[0153] The e-key system can incorporate a streaming data processor 1910, which ensures the valid transmission of input data or sensor data 1911 to the data lake 1912 and control application 1916, ensuring that no data is lost or corrupted.

[0154] The e-key system can also utilize Data Lake 1912. Data Lake 1912 can be used to store data generated by connected devices in its natural format. Big data arrives in "batches" or "streams." When data is needed for meaningful insights or analysis (for example, in response to a query), the data can be extracted from Data Lake 1912 and loaded into a central system, such as a big data warehouse.

[0155] The e-key system can also utilize machine learning (ML) 1920 and the models 1922 generated by ML 1920. Using machine learning 1920 provides an opportunity to create more accurate and efficient models for control applications 1916. Model 1922 can be regularly updated (e.g., weekly or monthly) based on historical data accumulated in a central system 1915, such as a big data warehouse. The new model is used by control applications 1916 once its applicability and efficiency are tested and approved by data analysts and / or data analysis processes 1940.

[0156] The e-key system may include a control application 1916 that sends commands and alerts to actuators. For example, the e-key system may receive automated commands to actuators to close or open doors in response to user interaction with a user application made by the user.

[0157] The e-key system may include a control application or a central application that can be either a rule-based application or a machine learning-based application. A rule-based application may include a control application that operates according to rules defined by experts. A machine learning-based application may include a control application that uses Model 1922, which is regularly updated (for example, weekly or monthly depending on the details of the e-key system) using historical data stored in a big data warehouse.

[0158] While control applications ensure better automation of the e-key system, the e-key system can offer users the option to influence the behavior of such applications.

[0159] A user application, such as a web application 1932 or a mobile application 1934, can be a software component of the e-key system that enables user connectivity to the e-key system and gives the option to centrally monitor and control smart things while they are connected to a network of similar things, such as automobiles. Using the web application 1932 or mobile application 1934, users can monitor the status of their things 1901, send commands to the control application 1916, and set options for automatic behavior (for example, automatic notification and action when certain sensor data 1911 arrives from the sensor).

[0160] The e-key system may include device management utilities to ensure the full and correct functionality of e-key devices. There may be certain processes and / or procedures required to manage the performance of connected devices (for example, to facilitate interaction between devices and ensure secure data transmission).

[0161] The e-key system may include a device identification routine that establishes the device's identity to ensure that the device is a genuine device with trusted software that transmits reliable data.

[0162] The e-key system may include configuration settings and / or controls to adjust things, such as IoT-enabled devices, according to the purpose of the e-key system. Some parameters may need to be written only once after the device is installed (e.g., unique device ID or blockchain token). Other settings may need to be updated (e.g., time between sending messages containing data).

[0163] The e-key system can include monitoring and diagnostic features to ensure the smooth and secure performance of all devices within the network, such as IoT-enabled devices, and to reduce the risk of failure.

[0164] The e-key system can be configured to perform software updates and maintenance to add functionality, fix bugs, and / or address security vulnerabilities.

[0165] The e-key system may include user management features that provide control over users who have access to the e-key system, along with device management. User management features may include identifying users, their roles, access levels, and / or ownership within the system. User management features may include options such as adding and removing users, managing user settings, controlling different users' access to certain information, granting permission to perform certain actions within the system, and / or controlling and recording user activity, and others.

[0166] e-key systems can include security monitoring features. Connected devices generate large amounts of data that needs to be transmitted securely and protected from attacks by cybercriminals. Another aspect is that internet-connected devices can become entry points for malicious actors. Furthermore, cybercriminals could gain access to and control the "brain" of the e-key system. To prevent such attacks, various components of the e-key system can log and analyze commands sent by the device control application or central application, monitor user actions, and store this data in the cloud. These features can enable the e-key system to address security breaches at the earliest possible stage and take measures to mitigate their impact on the e-key system. For example, the e-key system can block certain commands coming from the control application. Also, the e-key system can identify patterns of suspicious behavior, store these samples, and compare them to logs generated by the e-key system to prevent potential intrusions and minimize their impact on the e-key system.

[0167] The e-key architecture provides stable and secure functionality for things and can also include device and user management components for controlling user access.

[0168] The e-key architecture can offer consistency (for example, paying close attention to all elements of the e-key architecture and ensuring they work together), flexibility (for example, providing opportunities to add new features and logic), and the ability to integrate with enterprise systems.

[0169] The e-key system may include a 64-bit high-performance expandable single-board computer (SBC) that can be integrated with any IoT gateway (e.g., Gateway 1902). A group of system nodes may have the computing power of a supercomputer. The smart chip can be embedded in a card or other object suitable for applications such as access control, authentication, and security key storage. For example, as shown in Figure 22, a smart card may incorporate the smart chip of the smart chip system in Figure 21.

[0170] Smart chips may include embedded memory. This disclosure provides details of a smart chip reader system and its use in conjunction with an object incorporating a smart chip.

[0171] This system is built upon current trends in automation and data exchange in manufacturing and industrial technologies. It incorporates technologies such as 5G and 6G, and in the future, it can integrate 7G data connectivity, cybersecurity systems, cyber-physical systems, IoT, cloud computing, blockchain, and AI cognitive computing. Within a modular smart factory structure, cyber-physical systems monitor physical processes, create virtual copies of the physical world, and make decentralized decisions. Through IoT, cyber-physical systems communicate and collaborate with each other and with humans in real time, both internally and across organizational services provided and used by participants in the chain.

[0172] This system includes two main hardware sections. The first hardware section, sometimes called a smart chip, acts as a passive authentication and application input client. The first hardware section is activated when it is in contact with or within range of a reading terminal. The second hardware section, sometimes called a smart chip reader, receives, processes, and returns input data.

[0173] This system may include a contactless smart chip module that generates the necessary control signals on the smart chip side. Commands or data for accessing the smart chip module are supplied either by a microcontroller interface or configuration logic. A block diagram of the IP interface is shown in Figure 21.

[0174] The smart chip module shown in Figure 24 includes two memory areas: an application zone and a configuration memory area. The application zone can be divided into 16 zones, each with 1024 bits. Access to the application zone is permitted only after security requirements are met. These security requirements may be defined by system software during the device personalization process and stored in configuration memory.

[0175] The configuration memory may include a 2048-bit EEPROM memory used to store passwords, blockchain tokens, token keys, client programming, and code, and to define the security level used for each application zone. Access to the configuration memory is defined within the control logic and cannot be changed by system settings.

[0176] The key can be used to access the configuration memory of the supplied smart chip module. For example, this key may be 0xB6A405. This key may be required to unlock the configuration memory for any changes made to it. The user can access the user zone and configuration memory area in the manner described herein.

[0177] The operation procedure may include the following actions: 1. Connection and activation of contacts by an interface device. 2. Reset the card. 3. Respond to the reset using the card. 4. Information exchange between the card and the interface device. 5. Deactivation of contacts by interface devices. [Table 1] Table 1

[0178] As shown in Table 1 above, an interface device may have four internal registers: a reset register, a transmit data register, a receive data register, and a status register. The reset register resets the smart card. The transmit data register sends data to the CARD_IO bus. The receive data register receives data from the CARD_IO bus. The status register indicates the status of a data transaction. There may also be two counters: a counter and a bit counter. The counter is used to sample each bit at the center of the bits at a rate f (e.g., 1 MHz). The bit counter is used to count 11 bits of a packet. An example of the offset address of a smart card reader register is shown in Table 1 above.

[0179] As shown in Figure 23, the smart chip includes a power supply contact (VCC), a reset signal contact (RST) used to reset the smart card's communications, a clock contact (CLK) that supplies a clock signal to the smart card, a ground contact (GND) that provides a ground voltage or reference voltage, a programming voltage contact (VPP) through which a programming voltage is supplied, input / output contacts (I / O) that provide half-duplex series input / output, and two remaining contacts, C4 and C8, which are used for the USB interface and other functions.

[0180] Figure 24 shows a smart chip circuit block diagram. The smart chip circuit includes a processor, which can be, for example, a processor; random access memory (RAM), which can be configured to store token codes; read-only memory (ROM), which can be configured to store hash codes, for example, 128-bit hash codes; electrically erasable programmable read-only memory (EEPROM), which can be configured to store blockchain tokens and client applications; power supply contacts through which the smart chip is powered; and input / output (I / O) contacts configured for series input / output communication. Figure 25 shows an example of a microcontroller for the smart chip.

[0181] Figure 26 is a block diagram of the smart chip reader of the smart chip system shown in Figure 21. The smart chip reader includes an address decoder, a status register, a reset register, a transmit data register, a transmit shift register, a receive data register, a receive shift register, a counter, and a bit counter. The counter supplies count signals to the status register, the receive shift register, and the bit counter. The bit counter supplies a bit count signal to the transmit shift register. The transmit data register is coupled to a data input line, for example, an 8-bit data input line. The transmit shift register and the receive shift register are connected to card input / output lines.

[0182] The transmit data register contains data that may be sent to the smart chip. An example of transmit data register bit settings is shown in Table 2 below. [Table 2] Table 2 Transmit Data Registers

[0183] The received data includes data that may be received from the smart chip. An example of the received data register bit setting is shown in Table 3 below. [Table 3] Table 3 Received Data Register

[0184] An example of a status register bit setting is shown in Table 4 below. [Table 4] Table 4 Status Register

[0185] By default, the status register can be set to 0x00. When one byte of data is transferred from the transmit register and shifted out in series to the smart chip via the card I / O pins, the status register can change to 0x01. This bit can be monitored by the host to confirm that the data has been fully shifted out to the smart chip. After the complete byte has been shifted out from the transmit register, the status register bit is set to 0x01. The content can be cleared to 0x00 before the next data transfer. Similarly, for read operations, the status register bit can be monitored to check whether the data is available in the receive register. After the data has been read from the smart chip and one byte of information is available in the receive register, the status register bit becomes 1 and can be cleared by the host before the next byte is received.

[0186] An example of reset register bit setting is shown in Table 5 below. [Table 5] Table 5 Reset Registers By default, the reset register can be set to 0x00. For all transactions to be executed, the initial step can be set to reset the chip. For normal operation, the reset register bit can be set to 1.

[0187] Figures 27A and 27B are flowcharts illustrating a method for reading or writing an application zone to a smart chip according to an aspect of the present disclosure. After initiating the system reset process in block 2701, block 2702 applies a smart card or object reset (Card_rst) to the smart chip by writing 0x01 to the reset register (e.g., the reset register shown in Table 2 above). Block 2704 obtains an 8-byte smart chip response (ATR) for the reset from the receive data register (e.g., the receive data register shown in Table 3 above). Block 2706 sends a 5-byte command to "set application zone" to the transmit data register (e.g., the transmit data register shown in Table 2 above). Block 2708 obtains a smart chip acknowledgment byte (identical to the INS byte of the command sent in the previous block) from the receive data register. In block 2710, the smart chip status byte status word 1 and status word 2 are obtained from the received data register (for example, the received data register shown in Table 3 above).

[0188] Subsequently, block 2712 determines whether to read from the smart chip's "Application Zone Read" or write to the smart chip's "Application Zone Write". This determination can be based on the task currently being performed. For example, when authenticating a person's identity, the smart chip is read via blocks 2714-2723, and when updating Hyperleja using context information, that context information is written to the smart chip via blocks 2724-2733.

[0189] In block 2712, if it is determined that a read from "Application Zone Read" should be performed, block 2714 sends the 5-byte "Application Zone Read" command to the transmit data register. In block 2716, the smart card acknowledgment byte (identical to the INS byte of the command sent in the previous block) is obtained from the receive data register. In block 2718, N bytes of data to be written to the application zone are sent to the transmit data register. In block 2720, the smart chip status bytes SW1 and SW2 are obtained from the receive data register. In block 2722, the smart card reset setting (Card_rst) is removed from the smart card by writing 0x00 to the reset register (for example, the reset register shown in Table 5 above). In block 2723, the application zone read cycle is terminated.

[0190] If block 2712 determines that a write to "Application Zone Write" is to be performed, block 2724 sends a 5-byte "Application Zone Write" command to the transmit data register. Block 2726 retrieves the smart card acknowledgment byte (identical to the INS byte of the command sent in the previous block) from the receive data register. Block 2728 sends N bytes of data to be written to the application zone to the transmit data register. Block 2730 retrieves the smart chip status bytes SW1 and SW2 from the receive data register. Block 2732 removes the reset smart card setting (Card_rst) from the smart card by writing 0x00 to the reset register (for example, the reset register shown in Table 5 above). Block 2733 ends the application zone write cycle.

[0191] Figures 28A and 28B are flowcharts illustrating a method for reading or writing to configuration memory according to an aspect of the present disclosure. After initiating the system reset process in block 2801, block 2802 applies a smart card or object reset (Card_rst) to the smart chip by writing 0x01 to the reset register (e.g., the reset register shown in Table 2 above). Block 2804 obtains an 8-byte smart chip response (ATR) for the reset from the receive data register (e.g., the receive data register shown in Table 3 above). Block 2806 sends a 5-byte command for "configuration zone unlock" to the transmit data register (e.g., the transmit data register shown in Table 2 above). Block 2808 obtains a smart chip acknowledgment byte (identical to the INS byte of the command sent in the previous block) from the receive data register. Block 2810 sends a 3-byte security code to the transmit data register (for example, the transmit data register shown in Table 2 above) to unlock the configuration zone.

[0192] Subsequently, block 2812 determines whether to read from the smart chip's "Application Zone Read" or write to the smart chip's "Application Zone Write". This determination can be based on the task currently being performed. For example, when authenticating a person's identity, the smart chip is read via blocks 2814-2823, and when updating Hyperleja using context information, that context information is written to the smart chip via blocks 2824-2833.

[0193] In block 2812, if it is determined that a read from "Configuration Zone Read" is to be performed, block 2814 sends a 5-byte command for "Configuration Memory Read" (i.e., Configuration Memory Read or Configuration Zone Read) to the transmit data register. In block 2816, the smart card acknowledgment byte (identical to the INS byte of the command sent in the previous block) is obtained from the receive data register. In block 2818, N bytes of data are obtained from the receive data register of the configuration memory. In block 2820, the smart chip status bytes SW1 and SW2 are obtained from the receive data register. In block 2822, the smart card reset setting (Card_rst) is removed from the smart chip by writing 0x00 to the reset register (for example, the reset register shown in Table 5 above). In block 2823, the read cycle from the configuration memory is terminated.

[0194] If block 2812 determines that a write to "configuration zone write" is to be performed, block 2824 sends a 5-byte command for "configuration memory write" (i.e., configuration memory write or configuration zone write) to the transmit data register. Block 2826 retrieves the smart card acknowledgment byte (identical to the INS byte of the command sent in the previous block) from the receive data register. Block 2828 sends N bytes of data to be written to configuration memory to the transmit data register. Block 2830 retrieves the smart chip status bytes SW1 and SW2 from the receive data register. Block 2832 removes the reset smart card setting (Card_rst) from the smart chip by writing 0x00 to the reset register (for example, the reset register shown in Table 5 above). Block 2833 ends the write cycle to configuration memory.

[0195] Figure 29 is a block diagram of a smart chip system 2900 incorporated into a wireless e-key system architecture according to an aspect of the present disclosure. The smart chip system 2900 includes a hyper terminal 2902, a single-board computer (SBC) 2904, a smart chip reader 2102, and a smart chip 2104 which may reside on a card or any other suitable object. The SBC 1904 can be a computer, or a readily available 64-bit high-performance expandable single-board computer which can be integrated into any IoT gateway. A group of SBC nodes may have the computing power of a supercomputer. The SBC 2904 may be equipped with a preloaded Linux operating system, blockchain, and AI infrastructure which can be integrated into any IoT gateway, such as biometrics, cameras, sensors, etc.

[0196] As shown in Figure 33, the SBC 2904 may include one or more of the following features: CPU, GPU, RAM memory, flash memory (e.g., NAND flash memory), eMMC memory, ability to operate in extreme industrial temperatures and weather, SATA connector with SATA power jack, HDMI port, USB Low-Full-High-Speed ​​host with power control and current limiter, USB-OTG with power control and current limiter, VGA output, native Ethernet, battery connector with battery charging capability, audio headphone output, microphone input on connector, UEXT connector, LCD connector compatible with LCD modules of different sizes, GPIO connector, MicroSD card connector, SD / MMC card connector, DEBUG-UART for console debugging, status LED, battery charge status LED, power LED, EEPROM for MAC address storage, etc., buttons and reset button with ANDROID functionality, mounting holes, input power, Wi-Fi 802.11n, 5G and 6G GSM board, expandable IoT board, and a heatsink.

[0197] Figures 30A–30I show an example of the IoT gateway module 1902 from Figure 19. The SBC 2904 can be deployed in thousands of systems across a wide range of industries and applications using the expandable IoT gateway module 1902.

[0198] Figure 30A is a block diagram showing an example of an input component of a biometric system incorporated into an e-key architecture according to an aspect of the present disclosure. The input component may include a fingerprint sensor, a fingerprint reader, an iris reader, a facial recognition system, a smart chip reader that may be configured to read a smart chip in a passport, a smart chip in a credit or debit card, and / or a smart chip in a driver's license.

[0199] Figure 30B is a block diagram showing an example of an input component of a telecommunications system incorporated into a wireless e-key architecture according to an aspect of the present disclosure. The input component may include a GSM or CDMA SIM card. The input component may be enabled with respect to 5G and 6G technologies. All events can be recorded on a blockchain. The telecommunications system may feature reliable and secure communication, inexpensive and high-speed communication, and security features that make it difficult to clone or duplicate a mobile phone or smartphone.

[0200] Figure 30C is a block diagram showing an example of an input method for a supply chain management system incorporated into a wireless e-key architecture according to an aspect of the present disclosure. The input method includes unloading a supply chain item, measuring the dimensions of the supply chain item, finding the location to place the supply chain item, recording the event on the blockchain, and storing the supply chain item. After storing the supply chain item, the input method may further include finding and retrieving the supply chain item, managing the inventory of the supply chain item, and identifying the supply chain item using a barcode, QR code, RFID object, or tricolor code.

[0201] Figure 30D is a block diagram showing an example of an input method for a satellite system incorporated into an e-key architecture according to an aspect of this disclosure. The SBC 2904 can be installed on the satellite. According to the input method, all events or data transfers are recorded on the blockchain. The input method eliminates man-in-the-middle attacks and features peer-to-peer communication. Tampered data during communication is retransmitted. According to the input method, the ground station acts as a hyperleisure station. The input method provides reliable and secure data transfer as well as fast and inexpensive data transfer.

[0202] Figure 30E is a block diagram showing an example of an input component of an automotive system incorporated into a wireless e-key architecture according to an aspect of the present disclosure. The input method may include actuators and / or control devices configured to perform one or more of the following: opening and closing car doors, opening and closing car trunks, starting / stopping car engines, turning car air conditioning on / off, and generating alerts or alarms to check car fuel. The input method may also include locating a car, checking tire pressure, and accessing logs.

[0203] Figure 30F is a block diagram showing an example of an input method for an aviation system incorporated into a wireless e-key architecture according to an aspect of the present disclosure. The input method may include monitoring whether the cockpit has been compromised and taking action in response to a compromise event. The input method may include causing the aircraft to enter autopilot mode in response to an event. The event may also automatically trigger one or more actions such as sending an alert to government officials and / or police, collecting passengers' biological details (e.g., health information, blood type, etc.), and initiating a flight in order system.

[0204] Figure 30G is a block diagram illustrating an example of an input method for a healthcare system incorporated into a wireless e-key architecture according to an aspect of the present disclosure. The input method may include a healthcare sensor and may include collecting patient biological details, scheduling appointments, continuously screening patients, and suggesting medical procedures. In response to the detection of an event or condition during continuous screening, it may perform one or more of the following actions, among others: automatically sending alerts to hospital staff, automatically recording all patient health data to a blockchain, and automatically sending medical alerts to patients.

[0205] Figure 30H is a block diagram showing an example of an input method for a financial engineering system incorporated into a wireless e-key architecture according to an aspect of this disclosure. The input method may include entering a receiver address, entering a private key, adding data to a new block on the blockchain, authenticating a transaction by all nodes, and receiving the transaction by the receiver. The input method may also include sending a smart contract. The input method allows peer-to-peer transactions and secure transactions.

[0206] Figure 30I is a block diagram showing an example of an input method for a pharmaceutical industry system incorporated into an e-key architecture according to an aspect of this disclosure. The input method may include entering a drug barcode, entering a private key, adding drug data to a new block on the blockchain, authenticating the transaction by all nodes, and obtaining the drug by the recipient. The input method may also include, among other things, tracking drug shipments and sales, tracking drugs by batch, and finding alternative prescriptions.

[0207] Figure 31 is a block diagram showing an IoT gateway module incorporated into the e-key architecture according to an aspect of the present disclosure. The IoT gateway may be implemented by software and / or hardware that causes the sensor to obtain sensor data, read the sensor data, process the sensor data, and send the sensor data to the single-board computer (SBC) 2904 in Figure 29.

[0208] Figure 32 is a block diagram showing a single-board computer (SBC) interface module incorporated into a wireless e-key architecture according to an aspect of the present disclosure. As shown in Figure 32, the system includes three software interfaces: (1) a firmware interface 3210, (2) a system software interface 3220, and (3) an application interface. The firmware interface 3210 can be permanent and can load configuration files and initial data to boot up the hardware. The firmware interface 3210 can be divided into different levels of firmware. Low-level firmware 3212 can be stored in ROM, OTP / PROM, and / or PLA structures. In some aspects, low-level firmware 3212 is stored in read-only memory (ROM) and cannot be modified or updated. Low-level firmware 3212 can include hardware or driver software.

[0209] High-level firmware 3214 may be stored in flash memory and may include system software and system software updates. Subsystem firmware 3216 may include fixed microcode embedded in the flash chip, CPU, and / or LCD unit. Subsystem firmware 3216 can be considered part of the hardware device and / or high-level firmware 3214.

[0210] The system software interface 3220 can boot up the board's core operating system 3221 and can also preload all required system files 3222, system services 3223, system preferences 3224 including a library of functions, hardware drivers 3225 including drivers for the board and other IoT hardware, security software 3226, other configuration files 3227, and / or a firewall including an artificial intelligence firewall. The system software may also include an assembler, compiler, file management tools, system utilities, and / or a debugger.

[0211] The application interface can incorporate pre-loaded infrastructure and functionality for blockchain, AI interfaces, and IoT. The application interface can support C-based and Python-based programs and applications. The AI ​​interface can act as a smart firewall, monitoring passive and active input / output or user- or system-triggered events, and making intelligent decisions. If the system identifies a potential threat to the system itself or a physical control panel that is hacked or tampered with, it can enter safe mode, send an alert to the appropriate person (e.g., an employee), and enter auto mode.

[0212] This system incorporates blockchain functionality to enable users to add immutable data to HyperLeisure and guarantee the integrity and origin of data, including audio streams, video streams, text messages, images, and documents, which are exchanged as smart contracts from one peer to another. The system verifies and authenticates the data.

[0213] For example, assuming a man-in-the-middle attack is carried out between two parties, after receiving tampered or corrupted data, the receiving peer decrypts the data and sends an acknowledgment token back to the sending peer. If the sending peer finds that the acknowledgment token is invalid, it resumes sending valid data.

[0214] Figure 34 is a block diagram showing an application module 3400 that may run on the SBC 2904 of Figure 29 according to an aspect of this disclosure. The hosting platform 3402 includes multiple API endpoints and storage capabilities used to make requests and obtain responses from online services. Various hosting services can be used. For example, an AWS EC2 m5.12xlarge instance can be used as an application server, and an AWS S3 instance can be used for file storage purposes. The Amazon AWS EC2 m5.12xlarge instance offers a wide selection of cloud computing instance types optimized to suit different use cases. The instance types feature varying combinations of 48 vCPUs, 192GB of memory, EBS storage, 7000 dedicated EBS bandwidth (Mbps), and 10 networking performance (Gbps), giving flexibility to select a suitable mixture of resources for your application. Each instance type includes one or more instance sizes, allowing resources to scale to the requirements of the target workload.

[0215] Amazon AWS S3 instances offer user-friendly management features to organize data and configure fine-tuned access controls to meet specific business, organizational, and compliance requirements. Amazon AWS S3 is designed for 99.999999999% durability, storing millions of records for companies worldwide.

[0216] The server interface 3404 can house multiple pre-loaded servers, including Gunicorn, Redis messaging queuing server, and Nginx web server. The Gunicorn server is broadly compatible with multiple web frameworks, is simple to implement, lightweight on server resources, and fairly fast. The Redis messaging queuing server is an in-memory database project that implements a distributed in-memory key / value store, with optional durability. Redis supports various types of abstract data structures, including strings, lists, maps, sets, sorted sets, hyperlog logs, bitmaps, and spatial indexes. The Nginx web server is a high-performance HTTP server and reverse proxy, as well as an IMAP / POP3 proxy server. NGINX boasts high performance, stability, a rich feature set, simple configuration, and low resource consumption.

[0217] Application module 3400 can include a client application interface 3406 that can use Django 2.1 and the Django REST framework. The Django web framework is a high-level Python web framework that encourages rapid development and clean, actionable design. The Django REST framework is a powerful and flexible toolkit for building web APIs. The Django REST framework provides web-browsable APIs, authentication policies including OAuth1a and OAuth2 packages, and serialization that supports both ORM and non-ORM data sources.

[0218] The Big Data Interface, or Big Data Platform 3408, includes a variety of powerful big data tools. These big data tools may include Apache Hadoop, a collection of software utilities that facilitates the use of networks of numerous computers to solve problems involving large amounts of data and computation. The Big Data Tools may also include Apache Pig, a platform for analyzing large datasets consisting of a high-level language representing these programs, coupled with an infrastructure for evaluating data analysis programs. Pig can run on Apache Hadoop YARN and can leverage MapReduce and the Hadoop Distributed File System (HDFS). The platform's language is called Pig Latin, and it abstracts the Java MapReduce idiom into a SQL-like form.

[0219] Big data tools can also include Apache Hive, a data warehouse software project built on Apache Hadoop that provides data querying and analysis. Hive provides an SQL-like interface for querying data stored in various databases and file systems that integrate with Hadoop. Big data tools can also include MongoDB, a database for modern applications, and MongoDB Atlas, a global cloud database on AWS, Azure, and GCP. These databases make it easy to organize, use, and enrich data in real time, no matter where it is located. MongoDB is a cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with schemas.

[0220] Big data tools can also include Apache Storm, a free, open-source, distributed real-time computing system. Storm does for real-time processing what Hadoop does for batch processing, making it easy to reliably process unconstrained streams of data. Big data tools can also include Apache Spark, a distributed general-purpose cluster computing framework. Spark provides an interface for programming the entire cluster, along with implicit data parallelism and fault tolerance.

[0221] The application module 3400 may include a blockchain platform or blockchain interface 3410, which is a distributed, decentralized public leisure. The blockchain interface 3410 may include software that facilitates the processes of the sender entering the receiving address, the sender adding data, the sender entering a private key to authenticate the data, the miner including the data in the next block, the node verifying that the data is valid, and the receiver receiving the data within a short time, for example, 2-3 seconds. The blockchain may include a hyperleisure and a blockchain explorer.

[0222] Hyperleisure can incorporate distributed leisure technologies that create a decentralized environment rather than a centralized one, allowing for databases shared among computers spread across the globe. There are three types of hyperleisure that can be used: blockchain, directed acyclic graphs, and hash graphs.

[0223] A blockchain explorer is a simple, powerful, easy-to-use, and well-maintained utility for browsing activity on the underlying blockchain network. A blockchain explorer can be one that does not perform any event actions and does not interact with AI or IoT modules. A blockchain explorer can also be a web dashboard that allows system users to view all blockchain activity.

[0224] The Artificial Intelligence Module 3412 can include a variety of artificial intelligence (AI) libraries and techniques for building and driving smart machine intelligence. The AI ​​library can include NumPy, a library for the Python programming language that adds support for large multidimensional arrays and matrices, along with a large collection of high-level mathematical functions for manipulating these arrays. The AI ​​library can also include SciPy, a Python library used for scientific and technical computing. The AI ​​library can also include Scikit-learn, a machine learning library for the Python programming language. Scikit-learn features a variety of classification, regression, and clustering algorithms, including support vector machines, random forests, gradient boosting, k-means, and DBSCAN, and is designed to interact with Python's mathematical library NumPy and scientific library SciPy.

[0225] The Artificial Intelligence Module 3412 may also include TensorFlow, an end-to-end machine learning framework. TensorFlow has a comprehensive and flexible ecosystem of tools, libraries, and community resources that allow users to push the technological boundaries of ML and enable developers to easily build and deploy ML-powered applications. The AI ​​library may also include Keras, a Python deep learning library. Keras is a high-level neural network API written in Python that can run on top of TensorFlow, CNTK, or Theano. The AI ​​library may also include Theano, a Python library that allows users to define, optimize, and efficiently evaluate mathematical formulas containing multidimensional arrays. Theano is built on top of NumPy and features tight integration with NumPy and a NumPy-like interface. numpy.ndarrays may also be used internally by functions compiled by Theano.

[0226] The AI ​​library can also include Pandas, a Python data analysis library that provides high-performance, easy-to-use data structures and data analysis tools for the Python programming language. The artificial intelligence module 3412 can also include Matplotlib, which attempts to make simple things easy and difficult things possible. Users can generate plots, histograms, power spectra, bar graphs, error charts, scatter plots, and more using just two or three lines of code.

[0227] It should be understood that the foregoing description is merely illustrative of the present disclosure. A person skilled in the art can devise various changes and modifications without departing from the present disclosure. Therefore, the present disclosure is intended to encompass all such alternative forms, modifications, and variations. The embodiments described with reference to the accompanying drawings are presented solely to illustrate certain examples of the present disclosure. Other elements, steps, methods, and techniques that are not substantially different from those described above and / or in the accompanying claims are also intended to be within the scope of the present disclosure.

Claims

[Claim 1] The invention described in the specification and / or drawings.

Images