Carbon emission data access method, device, storage medium and computer program product

Abstract

This application discloses a carbon emission data access method, device, storage medium, and computer program product, relating to the field of Internet of Things (IoT) data security technology. The method includes: receiving a QR code scanning instruction from a user via an IoT device; triggering a carbon emission data access request based on the QR code scanning instruction; verifying a preset validity token according to the carbon emission data access request; querying a fine-grained permission graph with the IoT device as the root node if the validity token verification is successful; and generating a carbon emission data access list based on the query results of the fine-grained permission graph. By verifying the preset validity token and using a fine-grained permission graph with the IoT device as the root node, the security and controllability of carbon emission data access are improved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) data security technology, and in particular to carbon emission data access methods, devices, storage media, and computer program products. Background Technology

[0002] With the increasing adoption of Industrial Internet of Things (IIoT) technology in carbon emission and energy consumption monitoring, carbon monitoring equipment needs to share data externally. Traditional methods of sharing data externally mainly include file sharing, static account authorization, and API interface queries. Among these, file sharing carries the risk of data leakage and cannot be traced; static account authorization cannot be accurate to individual devices or characteristic data fields; and API interface queries also have the drawbacks of interface exposure and difficulty in ensuring data security.

[0003] Therefore, how to improve the security and controllability of access to carbon emission data has become a technical problem that this application urgently needs to solve. Summary of the Invention

[0004] The main objective of this application is to provide a carbon emission data access method, device, storage medium, and computer program product, aiming to solve the technical problem of how to improve the security and controllability of carbon emission data access.

[0005] To achieve the above objectives, this application proposes a method for accessing carbon emission data, the method comprising:

[0006] Receive a QR code scanning instruction from a user for an IoT device, and trigger a carbon emission data access request based on the QR code scanning instruction;

[0007] Verify the preset validity token based on the carbon emission data access request;

[0008] Under the condition that the time-limited token verification is successful, query the fine-grained permission graph with the IoT device as the root node;

[0009] A carbon emission data access list is generated based on the query results of the fine-grained permission map.

[0010] In one embodiment, the step of receiving a QR code scanning instruction from an IoT device sent by a user and triggering a carbon emission data access request based on the QR code scanning instruction further includes:

[0011] A global device ID is assigned to the IoT device, and the hardware identifier of the IoT device is bound to the global device ID to obtain an identity mapping relationship;

[0012] Obtain the user-configured token basic rules, and generate a token payload based on the token basic rules and the identity mapping relationship;

[0013] The token payload is asymmetrically encrypted and signed to obtain the time-limited token, and the time-limited token is encoded into a QR code.

[0014] In one embodiment, the step of receiving a QR code scanning instruction from an IoT device sent by a user and triggering a carbon emission data access request based on the QR code scanning instruction further includes:

[0015] Obtain historical carbon emission monitoring data for each of the aforementioned IoT devices, and organize the monitoring data dimensions for each IoT device based on the historical carbon emission monitoring data;

[0016] A fine-grained permission graph is established with the global device ID of the IoT device as the root node and the monitoring data dimension as the child nodes, and access permissions are configured for each child node in the fine-grained permission graph.

[0017] In one embodiment, the step of receiving a QR code scanning instruction from a user-sent IoT device and triggering a carbon emission data access request based on the QR code scanning instruction includes:

[0018] Receive QR code scanning instructions from users for IoT devices;

[0019] Based on the QR code scanning instruction, the dynamic QR code of the IoT device is parsed, and a carbon emission data access request is generated based on the parsing result of the dynamic QR code.

[0020] In one embodiment, the step of verifying a preset validity token based on the carbon emission data access request includes:

[0021] The expiration token is extracted from the carbon emission data access request. The expiration token includes a token header, a token payload, and a token signature.

[0022] The token signature is decrypted using an asymmetric encryption mechanism to obtain the first hash value;

[0023] The token header and the token payload are decoded and calculated to obtain the second hash value;

[0024] If the first hash value and the second hash value are equal, then the signature verification of the time-limited token is successful;

[0025] Extract the issuance time field and expiration time field from the token payload;

[0026] Verify whether the request time of the carbon emission data access request is within the range of the issuance time field and the expiration time field;

[0027] If the request time falls within the range of the issuance time field and the expiration time field, then the validity period verification of the validity token is successful.

[0028] If the validity period verification of the validity period token passes and the signature verification of the validity period token passes, then the validity period token verification is successful.

[0029] In one embodiment, the step of querying the fine-grained permission graph with the IoT device as the root node, under the condition that the time-limited token verification is successful, includes:

[0030] If the validity token verification is successful, the visitor identity identifier corresponding to the validity token is determined;

[0031] In the fine-grained permission graph, query the permission nodes associated with the visitor's identity identifier, and use the permission nodes as the query results of the fine-grained permission graph.

[0032] In one embodiment, the step of generating a carbon emission data access list based on the query results of the fine-grained permission map includes:

[0033] Traverse the permission nodes and extract the node information of the permission nodes;

[0034] The built-in carbon emission data repository is invoked to retrieve carbon emission data that matches the node information, and a carbon emission data access list is generated based on the carbon emission data.

[0035] In addition, to achieve the above objectives, this application also proposes a carbon emission data access device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the carbon emission data access method as described above.

[0036] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the carbon emission data access method described above.

[0037] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the carbon emission data access method described above.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] By triggering carbon emission data access requests through QR code scanning commands from IoT devices, this approach replaces traditional file transfers or static account logins. It prevents data from escaping enterprise security boundaries at the access point, mitigating the risk of data leakage due to copying and transmission, and providing a proactive safeguard for carbon emission data access security. Verifying pre-set time-limited tokens effectively avoids the long-standing risk of unauthorized access associated with static accounts, further enhancing the security, timeliness, and controllability of access behavior. After successful token verification, a fine-grained permission graph with IoT devices as the root node is queried, enabling refined permission control from the device root node to specific carbon emission data fields. This ensures precise and controllable data access scope, preventing data leakage caused by over-authorization. Finally, a carbon emission data access list is generated based on the permission graph query results, only granting users access to their authorized carbon emission data range, thereby further improving the security and controllability of carbon emission data access. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 A flowchart illustrating the first embodiment of the carbon emission data access method of this application;

[0043] Figure 2 A flowchart illustrating the second embodiment of the carbon emission data access method of this application;

[0044] Figure 3 A flowchart illustrating the third embodiment of the carbon emission data access method of this application;

[0045] Figure 4 This is a schematic diagram of the module structure of the carbon emission data access device according to an embodiment of this application;

[0046] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the carbon emission data access method in this application embodiment.

[0047] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0048] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0049] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0050] The main solution of this application embodiment is: receiving a QR code scanning instruction from a user for an IoT device, triggering a carbon emission data access request based on the QR code scanning instruction; verifying a preset validity token according to the carbon emission data access request; querying a fine-grained permission graph with the IoT device as the root node under the condition that the validity token verification is successful; and generating a carbon emission data access list based on the query results of the fine-grained permission graph.

[0051] In this embodiment, for ease of description, the carbon emission data access system will be used as the execution subject in the following description.

[0052] This application's embodiments take into account that, with the increasing prevalence of Industrial Internet of Things (IIoT) technology in the field of carbon emission and energy consumption monitoring, carbon monitoring equipment needs to share data externally. Traditional methods of sharing data externally mainly include file sharing, static account authorization, and API interface queries. Among these, file sharing carries the risk of data leakage and cannot be traced; static account authorization cannot be accurate to a single device or characteristic data field; and API interface queries also have the drawbacks of interface exposure and difficulty in ensuring data security.

[0053] Therefore, this application provides a solution that triggers carbon emission data access requests by receiving QR code scanning instructions from IoT devices, replacing traditional file transfer or static account login methods. This prevents data from escaping enterprise security boundaries at the access entry point, mitigating the risk of data leakage due to copying and transmission, and providing a proactive guarantee for carbon emission data access security. By verifying a preset time-limited token, it effectively avoids the long-standing risk of unauthorized access associated with static accounts, further enhancing the security, timeliness, and controllability of access behavior. After successful token verification, it queries a fine-grained permission graph with IoT devices as the root node, achieving refined permission control from the device root node to specific carbon emission data fields, ensuring precise control over the data access scope and preventing data leakage caused by over-authorization. Finally, based on the permission graph query results, a carbon emission data access list is generated, only opening the authorized carbon emission data range to users, thereby further improving the security and controllability of carbon emission data access.

[0054] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or carbon emission data access system capable of performing the above functions. The following description uses a carbon emission data access system as an example to illustrate this embodiment and the subsequent embodiments.

[0055] Based on this, embodiments of this application provide a method for accessing carbon emission data, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the carbon emission data access method of this application.

[0056] In this embodiment, the carbon emission data access method includes steps S10 to S40:

[0057] Step S10: Receive the QR code scanning instruction from the user's IoT device, and trigger a carbon emission data access request based on the QR code scanning instruction;

[0058] It should be noted that, in the embodiments of this application, "Internet of Things device" refers to a physical entity that is connected to the Industrial Internet and can generate or report data related to carbon emissions and energy consumption, such as smart meters, sensors, controllers or industrial gateways.

[0059] A QR code scanning command refers to a digital command generated by the terminal device application or browser and sent to the backend platform after the user operates the camera or dedicated application of their terminal device (such as a mobile phone or tablet) to capture and decode the encrypted QR code presented on the target IoT device.

[0060] A carbon emissions data access request refers to a structured web request that aims to access carbon emissions or energy consumption data associated with a specific IoT device. This request should at least carry key credential information parsed from a QR code.

[0061] Understandably, scanning a QR code automatically triggers a controlled data access process, avoiding the tedious operation of users manually entering account passwords or configuring complex APIs, and ensuring that the access request originates from physical contact with the physical device or authorization display, thereby enhancing the credibility of the access source.

[0062] Specifically, when an authorized user's mobile terminal scans the dynamically encrypted QR code displayed on an IoT device, the application or web script on the terminal calls a decoding library to parse the QR code content. The parsed content is a signed token string. Subsequently, the terminal software encapsulates a request with this token as the core parameter, and may include additional information such as the terminal device type and timestamp, and sends it to the designated API interface in the backend of this system. The network service module of the backend system (such as an API gateway) is responsible for listening to and receiving this request, performing preliminary parsing, extracting the token and other relevant information, thereby formally triggering a carbon emission data access process for a specific device.

[0063] Step S20: Verify the preset validity token according to the carbon emission data access request;

[0064] A pre-set time-limited token refers to a digital credential that is dynamically decoded from a QR code on each IoT device and is pre-generated and issued by the system backend. Essentially, it is an encrypted string containing specific information and having time validity.

[0065] Specifically, after receiving a carbon emission data access request, the system backend extracts the specific string of the validity token from the request and disassembles it into three parts according to the standard token format: header, payload, and signature. The system performs validity verification and signature verification based on the specific content of the token disassembly. If both validity verification and signature verification pass, it means that the conditions for validity token verification are met.

[0066] Step S30: Under the condition that the time-limited token verification is passed, query the fine-grained permission graph with the IoT device as the root node;

[0067] In a fine-grained permission graph, each node represents a permission object, and directed edges between nodes represent subordinate or related relationships. The root node uniquely corresponds to an IoT device, and its child nodes represent the data categories under that device (such as "real-time monitoring data", "historical statistical reports", "carbon accounting results"). Each node can have access control lists attached for different users or roles, clearly indicating policies such as "allow read", "deny", or "require additional authentication".

[0068] Specifically, after the time-limited token is verified, the system access control module extracts two core elements from the payload of the verified token: the globally unique identifier of the target IoT device and the visitor's identity identifier. Using the globally unique identifier as an index, it locates the access graph subtree rooted at that device in the storage system. Then, within that subtree, it performs a graph traversal query.

[0069] The purpose of the graph traversal query is to find all nodes in the graph that contain the visitor's identity and whose permissions are set to allowed. The query engine traverses all paths starting from the device root node, checks the access control attributes of each node, and finally returns a set of all nodes that meet the conditions. This set is the "fine-grained permission graph query result," which precisely describes the scope of accessibility of the current user to the target device data.

[0070] In one possible implementation, permission graph queries support complex inheritance and overriding logic. For example, if an intermediate category node is set to "allow read" for a user, and the system is configured so that "child nodes inherit permissions from parent nodes," then all leaf nodes under it that have not been explicitly denied will be automatically included in the authorization scope.

[0071] Step S40: Generate a carbon emission data access list based on the query results of the fine-grained permission map.

[0072] A carbon emission data access list refers to a structured set of instructions or a list of data descriptions. It transforms the abstract set of authorized nodes obtained from fine-grained permission graph queries into specific operational guidelines that can be directly understood and executed by the backend data query service.

[0073] Specifically, each authorized node in the query results of the fine-grained permission graph is traversed, and the metadata attributes stored on the node are read. These attributes include at least: the unique identifier of the data field represented by the node in the underlying database, the data storage type or table name, and any access constraints associated with the node.

[0074] Furthermore, the system organizes the aforementioned metadata attribute information into a structured list, namely the carbon emission data access list, and retrieves data precisely from the corresponding "carbon emission data repository" based on each item in the list.

[0075] This embodiment provides a carbon emission data access method. It triggers a carbon emission data access request by receiving a QR code scan command from an IoT device, replacing traditional file transfer or static account login methods. This prevents data from escaping the enterprise's security boundaries at the access entry point, preventing data leakage risks caused by copying and transmission, and providing a pre-emptive guarantee for carbon emission data access security. By verifying a preset time-limited token, it effectively avoids the long-standing unauthorized access risks associated with static accounts, further enhancing the security, timeliness, and controllability of access behavior. After successful token verification, it queries a fine-grained permission graph with the IoT device as the root node, achieving refined permission control from the device root node to specific carbon emission data fields, ensuring accurate and controllable data access scope and avoiding data leakage caused by over-authorization. Finally, based on the permission graph query results, a carbon emission data access list is generated, only opening the authorized carbon emission data range to the user, thereby further improving the security and controllability of carbon emission data access.

[0076] In one feasible implementation, step S10 may include steps S11-S12:

[0077] Step S11: Receive the QR code scanning instruction sent by the user for the IoT device;

[0078] Specifically, the carbon emission data access system deploys one or more security gateways or API servers at its network boundary. These servers expose a specific HTTPS endpoint, and the network listening module on the server runs continuously, waiting for connection requests from clients. Once the user's mobile terminal application completes the local decoding of the device's QR code, it constructs an HTTP POST request. The request header typically contains authentication information and content type, while the request body encapsulates the core data obtained from the QR code decoding.

[0079] Upon receiving a request, the server-side receiving module first performs basic security checks, such as verifying the validity of the API key, checking if the request frequency exceeds a threshold, and verifying the HTTPS certificate. After passing these checks, the receiving module extracts the payload from the request body and deserializes it into an internal data structure, which represents a received "QR code scanning instruction."

[0080] In one possible implementation, to enhance non-repudiation, the carbon emission data access system requires mobile terminals to include a unique signature generated from terminal hardware information in their requests and to verify it upon receipt to ensure that the terminal device from which the instruction originates is legitimate and has not been tampered with.

[0081] Step S12: Based on the QR code scanning instruction, parse the dynamic QR code of the IoT device, and generate a carbon emission data access request based on the parsing result of the dynamic QR code.

[0082] Specifically, upon receiving a scanning instruction from a user terminal containing encapsulated QR code raw data, the module first extracts the encoded string (i.e., the digital form of the dynamic QR code) from the instruction. Then, it decodes and verifies the structure according to a preset format (such as the JWT standard) to verify the integrity of the header algorithm identifier and the basic fields of the payload. After successful parsing, the module extracts core elements such as the encryption token itself, the target device identifier (device_id), and the issuer information from the decoded payload, and integrates these elements with the terminal metadata (such as terminal ID and timestamp) attached to the scanning instruction. Finally, the module uses this information to construct a structured internal data object containing attributes such as a unique request ID, a complete token string, a target device identifier, and a request context. This object is the formal carbon emission data access request that the system can subsequently process.

[0083] Based on the first embodiment of this application, a second embodiment of this application is proposed. In the second embodiment of this application, the contents that are the same as or similar to those in the first embodiment can be referred to the above description, and will not be repeated hereafter.

[0084] Based on this, please refer to Figure 2 , Figure 2 The flowchart of the second embodiment provided in this application is as follows: Figure 2 As shown, before step S10, the carbon emission data access method further includes steps S01 to S03:

[0085] Step S01: Assign a global device ID to the IoT device and bind the hardware identifier of the IoT device to the global device ID to obtain an identity mapping relationship;

[0086] It should be noted that, in this embodiment of the application, the global device ID refers to a unique identifier that is uniformly managed and allocated by the system backend. It is unique in the global scope of the system and is used to uniquely identify an IoT device at the logical level. It is usually composed of letters, numbers or strings generated according to specific rules.

[0087] Hardware identification refers to the inherent, physical, or fixed identity information of an IoT device, such as the device serial number (SN), MAC address, IMEI code, CPU ID, or an unchangeable unique chip code written by the device manufacturer.

[0088] Specifically, when a new IoT device needs to connect to the system, the system's device management module initiates the device registration process. First, the module's ID generation submodule generates a unique "global device ID" based on preset rules (e.g., combining timestamps, data center codes, and random numbers). Then, the administrator or installer needs to obtain the device's "hardware identifier" through a secure channel (such as the device's local configuration interface, a dedicated configuration tool, or a secure boot process upon first power-on). Next, the device management module submits this "global device ID" and "hardware identifier" to the system's core database through a secure management interface or API. A new record containing these two fields is added to the device identity mapping table in the database. The system typically generates a digital certificate or performs blockchain notarization for this binding operation to ensure the non-repudiation of the binding relationship.

[0089] Step S02: Obtain the token basic rules configured by the user, and generate the token payload based on the token basic rules and the identity mapping relationship;

[0090] User-configured token basic rules refer to a set of parameterized policies pre-set by system administrators or authorized users through the management interface to guide token generation. These rules typically include, but are not limited to: the token's validity period (e.g., 2 hours), the range of allowed access users (e.g., the role "auditor" or a specific user list), the basic permission category (e.g., "read-only - energy consumption data"), and optional additional conditions (e.g., access time period restrictions, geofencing).

[0091] The token payload refers to the structured data set that constitutes the core content of the time-limited token. It contains a series of claims that describe the basic attributes of this access, such as the token issuer, audience, expiration time, and specific information derived from the "token basic rules" and "identity mapping relationship" (such as target device ID, authorized user identifier, permission code, etc.).

[0092] Specifically, taking the JWT standard as an example, the payload is a JSON object. The system sets standard declarations, such as the issuer, the issuance timestamp, and the expiration timestamp calculated based on the validity period in the rules. These standard declarations, along with the custom declarations included in the token's basic rules, are assembled into a structured JSON object, namely the "token payload".

[0093] Step S03: Perform asymmetric encryption signature on the token payload to obtain the time-limited token, and encode the time-limited token into a QR code.

[0094] The token issuance module uses an asymmetric encryption algorithm (such as RSA) to digitally sign the generated token payload with the private key stored in the system. The signature result is then combined with the encoded token header and payload in a specific format to form a complete time-limited token string. Finally, the QR code generation submodule calls an encoding algorithm to convert the token string into a two-dimensional matrix graphic image that can be scanned and recognized by terminal devices, i.e., a dynamic QR code.

[0095] In this embodiment, by establishing a binding relationship between a globally unique identity identifier and a hardware identifier for IoT devices, and combining the token rules configured by the user to generate a time-limited token containing core information such as device identity and access permissions, and encoding it as a dynamic QR code, a complete pre-security system is constructed from device identity confirmation to access credential generation. This achieves unique traceability of device identity, ensures the legality and credibility of access requests, and eliminates the risk of unauthorized access that has long existed with static accounts through the dynamic and encrypted characteristics of the time-limited token. This provides a solid foundation for identity authentication and access control for secure access to carbon emission data.

[0096] Based on the first and / or second embodiments of this application, a third embodiment of this application is proposed. In the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0097] Based on this, please refer to Figure 3 , Figure 3 The flowchart of the third embodiment provided in this application is as follows: Figure 3 As shown, before step S10, the carbon emission data access method further includes steps A01~A02:

[0098] Step A01: Obtain historical carbon emission monitoring data for each of the IoT devices, and organize the monitoring data dimensions of each IoT device based on the historical carbon emission monitoring data;

[0099] Specifically, the system first extracts full carbon emission monitoring data for each IoT device in batches from the historical database of IoT devices through the data acquisition interface, covering multiple types of data such as real-time monitoring, historical statistics, and carbon accounting results; then, it uses data cleaning tools to preprocess the raw data, removing duplicates, missing values, and outliers to ensure data quality.

[0100] Furthermore, the cleaned historical carbon emission monitoring data is analyzed in terms of dimensions, and classified according to the data's business attributes, time characteristics, statistical granularity, etc. For example, the data is divided into major categories such as real-time data, historical energy consumption, and carbon emission reports. Each major category is further subdivided into specific data fields such as instantaneous power, 7-day electricity consumption trend, and annual total carbon emissions for verification. Finally, a standardized monitoring data dimension list corresponding to each IoT device is formed, providing a data foundation for the subsequent construction of the permission map.

[0101] Step A02: Establish a fine-grained permission graph with the global device ID of the IoT device as the root node and the monitoring data dimension as the child nodes, and configure access permissions for each child node in the fine-grained permission graph.

[0102] Specifically, a fine-grained permission graph with a tree structure is constructed using a graph database, with the pre-assigned global device ID of IoT devices as the root node and the monitoring data dimensions as child nodes. After the graph is constructed, the administrator can flexibly configure access permissions on each child node of the permission graph for different users or user roles through the visual permission configuration interface provided by the system, and can choose permission policies such as "allow read", "deny" or "require secondary verification".

[0103] For example, third-party auditors can be configured to have access only to the two sub-nodes "Total Power Consumption" and "Total Carbon Emissions" for "2024", while internal operations and maintenance personnel can be configured to have access to all data dimensions.

[0104] Furthermore, the system supports permission inheritance and overriding logic. If the parent node is configured with permissions, the child node can inherit the parent node's permissions if no separate permissions are configured. If the child node is configured with permissions, the child node's permissions will prevail, thereby enabling refined and flexible permission control of carbon emission data from IoT devices.

[0105] In this embodiment, by sorting out historical carbon emission monitoring data of IoT devices and constructing a fine-grained permission map, the entire process from sorting out device data to fine-grained permission control is achieved. This not only provides a clear data structure foundation for subsequent data access, but also allows for flexible configuration of data access permissions for different users or roles. This effectively solves the problems of coarse granularity and poor flexibility in traditional permission management, and ensures the security and controllability of carbon emission data during the sharing process.

[0106] Based on the above embodiments of this application, a fourth embodiment of this application is proposed. In the fourth embodiment of this application, the same or similar contents as those in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0107] In this embodiment, step S20, which verifies the preset validity token based on the carbon emission data access request, may include steps S21 to S28:

[0108] Step S21: Extract the timeliness token from the carbon emission data access request. The timeliness token includes a token header, a token payload, and a token signature.

[0109] After receiving a request to access carbon emission data, the system extracts the complete expiration token string from the specific fields of the request using a preset parsing algorithm. Then, it splits the string according to the JWT (JSON Web Token) standard format, decomposing it into three independent parts: the token header, the token payload, and the token signature. The token header contains metadata such as the encryption algorithm, the token payload contains core business information such as the device ID and the visitor's identity, and the token signature is an encrypted string used to verify the authenticity of the token, thus completing the initial parsing and structural decomposition of the expiration token.

[0110] The preset parsing algorithm is based on the parsing logic of the JWT (JSON Web Token) standard. For example, it first extracts the token string from a specific location in the HTTP request (such as the Bearer field in the Authorization Header, the token parameter in the request body, or URL query parameters); then, according to the JWT structure rules, it splits the token into three Base64Url-encoded parts: Header, Payload, and Signature, using the period "." as the separator; next, it decodes the first two parts using Base64Url to obtain the JSON header containing the encryption algorithm and the JSON payload containing the business declaration; finally, it performs syntax validation and field verification on the decoded JSON structure to ensure that it conforms to the system's preset token format requirements.

[0111] Step S22: Decrypt the token signature based on an asymmetric encryption mechanism to obtain the first hash value;

[0112] The system employs an asymmetric encryption mechanism, using a pre-stored public key to decrypt the token signature. Specifically, the system retrieves the public key paired with the private key used when issuing the token from the key management module. It then uses this public key to decode and hash the Base64Url-encoded token signature, ultimately obtaining a hash value, the first hash value. This hash value is the original result obtained by the issuer after hashing the token header and payload during token generation, and is used for subsequent verification of the token's integrity and authenticity.

[0113] Step S23: Decode and calculate the token header and the token payload to obtain the second hash value;

[0114] First, the token header and token payload are Base64Url decoded separately and converted into plaintext JSON data. Then, according to the hash algorithm specified in the token header (such as SHA-256), a combined hash operation is performed on the decoded token header and token payload. The operation strictly follows the concatenation rules of the JWT standard, that is, the concatenation is performed according to the format "token header.token payload" before the hash operation, and finally a new hash value is obtained, namely the second hash value. This hash value is used to compare with the first hash value to verify whether the token has been tampered with.

[0115] Step S24: If the first hash value and the second hash value are equal, then the signature verification of the time-limited token is successful;

[0116] The system compares the first and second hash values ​​bit by bit. If the two hash values ​​are exactly the same, it means that the token has not been tampered with during transmission and was indeed issued by the legitimate issuer holding the corresponding private key. In this case, the system determines that the signature verification of the time-limited token has passed. If the two hash values ​​are not equal, it means that the token may have been tampered with or was not issued by the legitimate issuer. The system determines that the signature verification has failed and rejects subsequent data access requests.

[0117] Step S25: Extract the issuance time field and expiration time field from the token payload;

[0118] Specifically, the token payload after Base64Url decoding is parsed into JSON, and the issuance time field (such as the "iat" field) and expiration time field (such as the "exp" field) are extracted. These two fields are usually stored in the form of Unix timestamps. The system converts them into a readable date and time format for subsequent validity verification. At the same time, the system will verify the existence and format of these two fields to ensure that they comply with the JWT standard and the system's business requirements. If the fields are missing or the format does not meet the requirements, the validity token is directly determined to be invalid.

[0119] Step S26: Verify whether the request time of the carbon emission data access request is within the range of the issuance time field and the expiration time field;

[0120] The system first obtains the reception time of the carbon emission data access request as the request time, and converts it into a Unix timestamp with the same format as the issuance time and expiration time fields. Then, it compares whether the request time is greater than or equal to the issuance time field and less than or equal to the expiration time field. If the request time is within this time range, it means that the validity token is still valid, and the system continues with subsequent verification steps. If the request time is less than the issuance time field or greater than the expiration time field, it means that the validity token has not yet taken effect or has expired, and the system determines that the validity verification fails and rejects the data access request.

[0121] Step S27: If the request time is within the range of the issuance time field and the expiration time field, then the validity period verification of the validity token is successful.

[0122] If the verification result shows that the request time for the carbon emission data access request is within the time interval specified by the issuance time field and the expiration time field, the system determines that the validity verification of the validity token has passed, confirming that the token is still valid at the current time, and the subsequent permission verification and data access process can continue. If the request time is not within the time interval, the system determines that the validity verification has failed, returns a prompt message to the user that the token has expired or has not yet taken effect, and terminates the data access process.

[0123] Step S28: If the validity period verification of the validity period token is passed and the signature verification of the validity period token is passed, then the validity period token verification is passed.

[0124] Specifically, the system integrates the signature verification result and the validity period verification result. Only when both the signature verification and the validity period verification pass is the entire validity period token verification considered successful, allowing the user to continue subsequent fine-grained permission graph queries and data access operations. If either the signature verification or the validity period verification fails, the system considers the validity period token verification to have failed and rejects the user's carbon emission data access request. At the same time, the reason for the verification failure and related log information are recorded for subsequent auditing and investigation.

[0125] In this embodiment, by verifying the validity period token from multiple dimensions, strict control is exercised over aspects such as the authenticity, integrity, and validity of the token. This effectively prevents the use of illegal, tampered, and expired tokens, ensuring that only legitimate and valid tokens can pass verification. This provides a solid security guarantee for accessing carbon emission data, avoids the risk of unauthorized access and data leakage, and also lays the foundation for subsequent fine-grained permission control and data access auditing, thereby improving the security and controllability of the entire system.

[0126] Based on the above embodiments of this application, a fifth embodiment of this application is proposed. In the fifth embodiment of this application, the same or similar contents as those in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0127] In this embodiment, under the condition that the time-limited token verification is passed, step S30, which queries the fine-grained permission graph with the IoT device as the root node, may include steps S31 to S32:

[0128] Step S31: Under the condition that the validity token verification is successful, determine the visitor identity identifier corresponding to the validity token;

[0129] After the time-limited token is verified, the system first parses the verified token and extracts the preset visitor identification field from the token's payload. This field is set by the system based on the visitor's registration or authorization information when the token is generated, and is usually stored in the payload in encrypted or plaintext form.

[0130] Furthermore, the system extracts this field from the payload using a specific parsing algorithm and performs format validation and integrity checks to ensure the validity and accuracy of the identity identifier. If the identity identifier field is missing or the format does not meet the requirements, the system will determine that the access is invalid and refuse subsequent operations; if the identity identifier is valid, the system will use it as the unique identifier of the visitor for subsequent permission queries and access control.

[0131] Step S32: Query the permission nodes associated with the visitor's identity in the fine-grained permission graph, and use the permission nodes as the query results of the fine-grained permission graph.

[0132] After obtaining the visitor's identity identifier, the system uses that identifier as the query condition to search within a pre-built fine-grained permission graph. The fine-grained permission graph uses IoT devices as the root node and the device's monitoring data as child nodes. Each node is configured with corresponding access permission information, including a list of allowed users or roles.

[0133] Furthermore, the system uses a graph traversal algorithm to traverse the permission graph layer by layer, starting from the root node. It checks the access permission configuration of each node and searches for permission nodes associated with the visitor's identity. During the traversal, the system determines the visitor's actual access permissions to each node based on permission inheritance rules and priority settings. For permission nodes matching the visitor's identity, the system marks them as accessible nodes and returns the set of these nodes as the query result of a fine-grained permission graph.

[0134] In this embodiment, by extracting the visitor's identity identifier from the verified time-limited token and accurately matching the associated permission nodes in a fine-grained permission graph, refined control over the visitor's data access permissions is achieved. This process not only ensures that visitors can only access the specific device data dimensions and fields they are authorized to access, effectively preventing excessive data exposure and abuse, but also provides an accurate basis for subsequently generating personalized carbon emission data access lists. Thus, while ensuring data security, it improves the accuracy and efficiency of data access, meeting the needs for secure and controllable sharing of device data in different scenarios.

[0135] Based on the fifth embodiment of this application, a sixth embodiment of this application is proposed. In the sixth embodiment of this application, step S40, which generates a carbon emission data access list based on the query results of the fine-grained permission map, may include steps S41 to S42:

[0136] Step S41: Traverse the permission nodes and extract the node information of the permission nodes;

[0137] After obtaining the query results of the fine-grained permission graph, the traversal operation of the permission nodes is initiated. The traversal process adopts a depth-first or breadth-first graph traversal algorithm, starting from the root node and sequentially visiting each permission node associated with the visitor's identity.

[0138] For each permission node, the system extracts detailed node information, which typically includes node ID, data type, data field name, data storage location, access permission level, etc.

[0139] Furthermore, during the extraction process, the system verifies the completeness and accuracy of the node information to ensure that the extracted information meets the requirements of subsequent data retrieval. If missing or incorrect node information is found, the system records the anomaly and takes appropriate action, such as skipping the node or issuing an alarm. Finally, the system summarizes and organizes all the extracted node information to form a structured node information set, providing a foundation for subsequent data retrieval.

[0140] Step S42: Invoke the built-in carbon emission data repository, retrieve carbon emission data that matches the node information from the carbon emission data repository, and generate a carbon emission data access list based on the carbon emission data.

[0141] After obtaining the structured set of node information, the built-in carbon emission data repository interface is invoked to initiate a data retrieval request. The data repository adopts a distributed storage architecture, storing different types of carbon emission data in corresponding database tables or files, and establishing an efficient indexing mechanism.

[0142] The system generates corresponding search queries based on key information such as data type and field names in the node information. These queries undergo syntax checking and optimization to ensure accurate and efficient retrieval in the data repository. During the retrieval process, the data repository quickly locates matching data records in the index based on the query and retrieves them from the storage medium. The system then performs format conversion and cleaning on the retrieved data, transforming it into a unified data format and removing duplicate, erroneous, or invalid data. Finally, the system organizes and sorts the processed data according to the node information's organization method, generating an access list containing all carbon emission data authorized for access by the visitor. This access list is stored and displayed in a structured format for easy viewing and use later.

[0143] In this embodiment, key information is extracted by traversing permission nodes, and an access list is generated by accurately retrieving and matching carbon emission data, achieving a seamless connection from permission configuration to data delivery. This ensures that data access strictly follows fine-grained permission control, effectively preventing unauthorized data leakage, while also significantly improving the efficiency and accuracy of data access through automated data retrieval and organization.

[0144] This application also provides a carbon emission data access device, please refer to... Figure 4 The carbon emission data access device includes:

[0145] The receiving module 10 is used to receive a QR code scanning instruction from the user for an IoT device, and trigger a carbon emission data access request based on the QR code scanning instruction.

[0146] Verification module 20 is used to verify a preset validity token based on the carbon emission data access request;

[0147] The query module 30 is used to query a fine-grained permission graph with the IoT device as the root node, provided that the time-limited token verification is passed.

[0148] The generation module 40 is used to generate a carbon emission data access list based on the query results of the fine-grained permission map.

[0149] The carbon emission data access device provided in this application, employing the carbon emission data access method in the above embodiments, can solve the technical problem of carbon emission data access. Compared with the prior art, the beneficial effects of the carbon emission data access device provided in this application are the same as those of the carbon emission data access method provided in the above embodiments, and other technical features in the carbon emission data access device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0150] This application provides a carbon emission data access device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the carbon emission data access method in the first embodiment described above.

[0151] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a carbon emission data access device suitable for implementing embodiments of this application. The carbon emission data access device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The carbon emission data access device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0152] like Figure 5 As shown, the carbon emission data access device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the carbon emission data access device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the carbon emission data access device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows carbon emission data access devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0153] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0154] The carbon emission data access device provided in this application, employing the carbon emission data access method in the above embodiments, can solve the technical problem of carbon emission data access. Compared with the prior art, the beneficial effects of the carbon emission data access device provided in this application are the same as those of the carbon emission data access method provided in the above embodiments, and other technical features in this carbon emission data access device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0155] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0156] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0157] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the carbon emission data access method in the above embodiments.

[0158] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0159] The aforementioned computer-readable storage medium may be included in the carbon emission data access device; or it may exist independently and not assembled into the carbon emission data access device.

[0160] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the carbon emission data access device, the carbon emission data access device causes the following actions: receiving a QR code scanning instruction from a user-sent IoT device; triggering a carbon emission data access request based on the QR code scanning instruction; verifying a preset validity token according to the carbon emission data access request; querying a fine-grained permission graph with the IoT device as the root node if the validity token verification is successful; and generating a carbon emission data access list based on the query results of the fine-grained permission graph.

[0161] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0162] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0163] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0164] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described carbon emission data access method, thereby solving the technical problem of carbon emission data access. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the carbon emission data access method provided in the above embodiments, and will not be repeated here.

[0165] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the carbon emission data access method described above.

[0166] The computer program product provided in this application can solve the technical problem of accessing carbon emission data. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the carbon emission data access method provided in the above embodiments, and will not be repeated here.

[0167] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A carbon emission data access method, characterized by, The carbon emission data access method includes: Assign a global device ID to an IoT device, and bind the hardware identifier of the IoT device to the global device ID to obtain an identity mapping relationship; Obtain the user-configured token basic rules, and generate a token payload based on the token basic rules and the identity mapping relationship; The token payload is asymmetrically encrypted and signed to obtain a time-limited token, and the time-limited token is encoded into a QR code. Receive a QR code scanning instruction from a user for an IoT device, and trigger a carbon emission data access request based on the QR code scanning instruction; Verify the validity token according to the carbon emission data access request; Under the condition that the validity token verification is successful, query the fine-grained permission graph with the IoT device as the root node; the specific steps include: under the condition that the validity token verification is successful, determine the visitor identity identifier corresponding to the validity token; query the permission node associated with the visitor identity identifier in the fine-grained permission graph, and use the permission node as the query result of the fine-grained permission graph; The carbon emission data access list is generated based on the query results of the fine-grained permission graph. The specific steps include: traversing the permission nodes and extracting the node information of the permission nodes; calling the built-in carbon emission data repository, retrieving carbon emission data that matches the node information from the carbon emission data repository, and generating the carbon emission data access list based on the carbon emission data. In this fine-grained permission map, the root node uniquely corresponds to an IoT device, and the child nodes correspond to the data categories under the IoT device. Each child node has an access control list attached to it. The data categories include real-time monitoring data, historical statistical reports, and carbon accounting results.

2. The carbon emission data access method as described in claim 1, characterized in that, Before the step of receiving a QR code scanning instruction from the user's IoT device and triggering a carbon emission data access request based on the QR code scanning instruction, the method further includes: Obtain historical carbon emission monitoring data for each of the aforementioned IoT devices, and organize the monitoring data dimensions for each IoT device based on the historical carbon emission monitoring data; A fine-grained permission graph is established with the global device ID of the IoT device as the root node and the monitoring data dimension as the child nodes, and access permissions are configured for each child node in the fine-grained permission graph.

3. The carbon emission data access method as described in claim 1, characterized in that, The step of receiving a QR code scanning instruction from a user's IoT device and triggering a carbon emission data access request based on the QR code scanning instruction includes: Receive QR code scanning instructions from users for IoT devices; Based on the QR code scanning instruction, the dynamic QR code of the IoT device is parsed, and a carbon emission data access request is generated based on the parsing result of the dynamic QR code.

4. The carbon emission data access method as described in claim 1, characterized in that, The step of verifying the validity token based on the carbon emission data access request includes: The expiration token is extracted from the carbon emission data access request. The expiration token includes a token header, a token payload, and a token signature. The token signature is decrypted using an asymmetric encryption mechanism to obtain the first hash value; The token header and the token payload are decoded and calculated to obtain the second hash value; If the first hash value and the second hash value are equal, then the signature verification of the time-limited token is successful; Extract the issuance time field and expiration time field from the token payload; Verify whether the request time of the carbon emission data access request is within the range of the issuance time field and the expiration time field; If the request time falls within the range of the issuance time field and the expiration time field, then the validity period verification of the validity token is successful. If the validity period verification of the validity period token passes and the signature verification of the validity period token passes, then the validity period token verification is successful.

5. A carbon emission data access device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the carbon emission data access method as described in any one of claims 1 to 4.

6. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the carbon emission data access method as described in any one of claims 1 to 4.

7. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the carbon emission data access method as described in any one of claims 1 to 4.

Images