Prepayment meter balance transfer method and system

Abstract

The application provides a prepayment meter balance transfer method and system, which comprises the following steps: after a meter to be cleared receives a balance transfer instruction, a key parameter of a supply group to which the meter to be cleared belongs and a device transmission key uniquely bound to the meter to be cleared are called to encrypt asset transfer information including the balance, a transfer token is generated, and the transfer token is written into a temporary area; a transaction state register in the meter to be cleared is updated to a state in which the transfer token has been generated; the balance of the meter to be cleared is cleared, and the transaction state is updated to a completed state; after a processing system receives the transfer token, the key parameter of the supply group to which the meter to be cleared belongs and the device transmission key uniquely bound to the meter to be cleared are called to decrypt the transfer token, and asset transfer information of the meter to be cleared is extracted. The application can realize safe encryption, atomic controllability, tamper resistance and traceability of automatic transfer and settlement of the balance of the prepayment meter to be cleared in an offline state.

Description

Technical Field

[0001] This invention relates to the field of smart prepaid electricity meter technology, and in particular to a method and system for transferring the balance of a prepaid electricity meter. Background Technology

[0002] The IEC 62055-41 standard (also known as the STS standard) is an internationally recognized specification for token transmission in prepaid electricity meters. This standard defines the generation specifications for recharge tokens in prepaid electricity meters: power companies use a Device Transmission Key (DUTK) uniquely bound to the meter to encrypt and generate a 20-digit digital recharge token. After being entered into the meter, the meter decrypts the token and adds the corresponding amount.

[0003] However, the standard only defines the generation protocol for generating tokens that are "positively" added to the meter, and does not define the generation protocol for generating tokens (balance) that are "negatively" transferred out of the meter.

[0004] In practical engineering, when a user cancels their account or the meter malfunctions and needs to be replaced, the remaining credit (electricity or electricity fee credit) in the old meter needs to be transferred or refunded. Currently, the industry standard is to remotely read the remaining credit from the meter and then manually complete the refund or transfer process.

[0005] The existing solutions described above have the following technical defects: (1) Non-atomic reading of balance status, resulting in delayed and distorted credit limit values: There is a time delay from the initiation of the meter reading to the return of the data. During this period, the user may continue to consume electricity, causing the meter reading value to deviate from the actual remaining credit limit. For example, when closing the account, the remote meter reading is 85kWh, but the user actually used 7kWh. The power company refunds the user based on 85kWh, resulting in financial loss.

[0006] (2) Lack of end-to-end encryption authentication and loss of data integrity: The remaining amount read remotely is in plaintext and lacks cryptographic encryption protection. There is a risk that it may be tampered with by internal personnel or intercepted and modified during transmission, and no irrefutable original certificate can be provided.

[0007] (3) Reliance on communication links, unavailable in offline scenarios: When the meter hardware fails, the communication module is abnormal or the signal coverage is insufficient, the balance data cannot be obtained remotely and can only be handled by a second on-site visit, resulting in high maintenance costs and poor user experience.

[0008] (4) Plaintext transmission, insufficient privacy: Plaintext credit information directly reflects users’ electricity consumption habits and consumption levels, and there is a risk of privacy leakage in multiple stages.

[0009] In summary, there is a clear gap in the existing technology: there is a lack of an offline balance transfer and settlement scheme that does not rely on communication links, has cryptographic integrity protection, and can guarantee the atomic consistency of balance status. Summary of the Invention

[0010] The technical problem to be solved by the present invention is to provide a method and system for transferring the balance of a prepaid electricity meter, which has full-link security protection and atomic consistency of balance status, and does not depend on the communication link.

[0011] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: Methods for transferring prepaid electricity meter balances include: After the clearing meter receives the balance transfer instruction, it calls the key parameters of its supply group and the device transmission key uniquely bound to it to encrypt the asset transfer information including the balance, generate a transfer token, and write it into the temporary storage area; the key parameters include the key revision number KRN, the key expiration number KEN, and the electricity price index TI; Update the transaction status register in the electricity meter to be cleared to the status that the transfer token has been generated; Clear the balance of the electricity meter to be settled to zero, and update the transaction status of the transaction status register to the completed status; After receiving the transfer token, the processing system calls the key parameters of the supply group to which the electricity meter to be liquidated belongs and the device transmission key uniquely bound to it to decrypt the transfer token and extract the asset transfer information of the electricity meter to be liquidated.

[0012] Optionally, the step of encrypting the asset transfer information using the key parameters of its supply group and the device transmission key uniquely bound to it, and generating a transfer token, specifically includes: Retrieve the key parameters of the supply group to which the meter to be cleared belongs; Obtain the fixed constant value of the meter to be cleared; The key revision number KRN, key expiration number KEN, and electricity price index TI from the key parameters called are combined with the obtained fixed constant value to form a calculation factor. The first conversion factor is calculated based on the meter number of the electricity meter to be cleared and the calculation factor. The first conversion factor is rearranged in bits to obtain the second conversion factor; Using the first conversion factor and the second conversion factor, the asset transfer information is encrypted to obtain the ciphertext payload; The encrypted payload is encrypted by invoking the device transmission key uniquely bound to the meter to be cleared; The encrypted ciphertext payload is encoded to generate a transfer token.

[0013] Optionally, the bit rearrangement process employs any one of the following five permutation mechanisms: bit shift, cyclic shift, fixed P-box permutation, key-based dynamic bit permutation, chaotic mapping-based bit permutation, matrix transpose permutation, and bit rearrangement based on a linear feedback shift register.

[0014] Optionally, the step of decrypting the transfer token by invoking the key parameters of the supply group to which the meter to be settled belongs and the device transmission key uniquely bound to it specifically includes: Verify if the format of the transfer token is correct; if incorrect, return that the transfer token is invalid; if correct, parse the transfer token to obtain the encrypted ciphertext payload. Based on user service information, obtain the unique meter identifier of the meter to be settled; the user service information includes the meter number of the meter to be settled. Based on the unique meter identifier obtained, the key parameters of the supply group to which the meter to be cleared belongs and the corresponding device transmission key are retrieved from the Key Management Service System (KMS). Based on the retrieved device transmission key, the encrypted ciphertext payload is decrypted; if decryption fails, the transfer token is returned as invalid; if decryption succeeds, the ciphertext payload is obtained. Based on the retrieved key parameters, the meter number of the electricity meter to be liquidated, and the fixed constant value, the obtained encrypted payload is decrypted; if decryption is successful, the asset transfer information of the electricity meter to be liquidated is obtained; if decryption fails, the transfer token is returned as invalid. Calculate the verification value of the asset transfer information and compare the calculated verification value with the verification value recorded in the asset transfer information; if they do not match, return that the transfer token is invalid. If they match, then based on the return time identifier field in the asset transfer information, determine whether the transfer token is within the preset validity period; if not, return that the transfer token has expired. If yes, determine whether the transfer token is stored in the processed transfer token registry; if yes, return that the transfer token has been used; if no, determine that the transfer token is valid.

[0015] Optionally, the data structure of the asset transfer information includes a return type field, a settlement method field, a return time identifier field, a return amount field, and a verification value field.

[0016] Optionally, the transaction status register is stored in the non-volatile memory of the meter to be cleared; the transaction status register is pre-configured with the following four transaction states: idle state, start state, transfer token generated state, and completed state; After receiving the balance transfer instruction, the meter to be settled also includes: Determine whether the current transaction status of the transaction status register is idle; If not, the balance transfer instruction is rejected and an error is returned; If so, update the transaction status of the transaction status register to the started state and execute the generation of transfer token; When the transaction status in the transaction status register has been set to the completed state for a preset time, the transaction status will be updated to the idle state.

[0017] Optionally, it also includes: After the power outage is restored, the transaction status of the clearing meter is checked in its transaction status register. If the transaction status in the transaction status register is in the started state, then roll back to the key parameters of the supply group to which the call belongs and the device transmission key uniquely bound to it to encrypt the current balance information and regenerate the transfer token; If the transaction status in the transaction status register is "transfer token has been generated", then continue to execute the atomic clearing of the current balance information; If the transaction status register shows a completed or idle state, no action is taken.

[0018] Optionally, it also includes: In the case of account cancellation, the processing system calculates the amount to be refunded based on the asset transfer information of the electricity meter to be settled; In the case of meter replacement, the processing system uses the asset transfer information of the meter to be cleared to call the key parameters of the supply group to which the target new meter belongs and the device transmission key uniquely bound to it to generate an equivalent amount of recharge token.

[0019] Another technical solution provided by this invention is: Prepaid electricity meter balance transfer system, including meters to be cleared and processing system; The electricity meter to be cleared is used to perform the steps executed by the electricity meter to be cleared in the above-mentioned prepaid electricity meter balance transfer method. The processing system is used to execute the steps performed by the processing system in the above-mentioned prepaid electricity meter balance transfer method.

[0020] Optionally, in the case of meter replacement, the target new electricity meter may also be included; The processing system is also used to generate an equivalent amount of recharge tokens by calling the key parameters of the supply group to which the target new electricity meter belongs and the device transmission key uniquely bound to it, based on the asset transfer information of the electricity meter to be cleared. The target new electricity meter is used to receive and verify the recharge token; if the verification is successful, the corresponding amount is written.

[0021] The beneficial effects of this invention are as follows: This invention utilizes the key parameters of the supply group to which the meter to be settled belongs, as well as the device transmission key uniquely bound to the meter, to encrypt asset transfer information and generate a transfer token. This effectively avoids risks of data tampering, information leakage, and illegal forgery, comprehensively ensuring the integrity, security, and reliability of asset transfer information. Simultaneously, by setting a transaction status register for transaction status control, it precisely achieves atomic consistency between the generation of the transfer token and the clearing of the meter balance, eliminating abnormal issues such as data corruption, transaction interruption, and duplicate settlement during the transfer process. This invention can achieve secure, encrypted, atomically controllable, tamper-proof, and traceable automated transfer and settlement of prepaid meter balances even when the meter is offline; significantly improving the security and reliability of asset settlement in scenarios such as meter balance cancellation and meter replacement. Attached Figure Description

[0022] Figure 1 This is a basic flowchart illustrating a method for transferring the balance of a prepaid electricity meter, as provided in an embodiment of the present invention. Figure 2 A schematic diagram illustrating the relationship between transaction status and business process in the power-off recovery mechanism provided for the transaction status register in a specific embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the generation of a digital transfer token according to a specific embodiment of the present invention; Figure 4 This is a schematic diagram of digital transfer token decryption provided in a specific embodiment of the present invention; Figure 5 A schematic diagram illustrating the complete process from token transfer to refund completion in an account cancellation scenario, as provided in a specific embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the complete process of generating a transfer token from the old electricity meter to the new electricity meter in a meter replacement scenario, as provided in a specific embodiment of the present invention. Figure 7 A schematic diagram of the overall process of a prepaid electricity meter balance transfer method provided for a specific embodiment of the present invention; Figure 8 This is an example diagram illustrating the composition and data interaction relationship of the prepaid electricity meter balance transfer system, the electricity meter to be cleared, the power company's dedicated processing system, and the target new electricity meter, provided in another embodiment of the present invention. Detailed Implementation

[0023] To explain in detail the technical principles, specific implementable solutions, possible application scenarios, and achievable objectives and effects of the present invention, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. It is understood that the embodiments described herein and the embodiments shown in the accompanying drawings are only used to more clearly illustrate the technical solutions of the present invention, and are therefore only examples intended to explain the present invention, and should not be construed as limiting the present invention. It should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0024] Explanation of technical terms involved in this invention: Token: A token is an encrypted string used in prepaid systems to transmit credit limits and other management information between the electricity sales system and the electricity meter. Under the IEC 62055-41 standard framework, a token typically consists of 20 digits containing encrypted information such as the electricity purchase amount, validity period, and unique serial number, employing an encryption algorithm to ensure data immutability. The token is generated by the electricity sales system (POS system), and after being entered into the meter by the user, the meter decrypts it and adds the corresponding credit limit. This invention uniquely introduces a "transfer token," enabling the reverse transfer of the meter balance.

[0025] Device Transmission Key (DUTK): Bound to the unique identifier of the electricity meter, it belongs to the decoder key system defined by the STS standard. The DUTK is a secret value and cannot be accepted by the meter in plaintext; it must be encrypted under an existing parent DecoderKey before being loaded. The DUTK is managed uniformly by the key management system to support the allocation of electricity meters to a unique supply group. In this invention, the DUTK, as the uniquely bound device transmission key to the electricity meter to be settled, participates in the encryption of the transfer token, ensuring that the transfer token is unforgeable and non-repudiable.

[0026] Key parameters for the supply group: A supply group is a logical grouping concept in the fields of electricity metering, load management, and energy supply; in this invention, it refers to a set of smart meters sharing the same energy supply system. Key parameters include the key revision number KRN, the key expiration number KEN, and the electricity price index TI; key parameters are the same for the same supply group.

[0027] Key Revision Number (KRN): This stands for Key Revision Number. It is used to uniquely identify a Vending Key within the same Supply Group. Changing the Key Revision Number (KRN) will not change the corresponding Supply Group code (SGC), but will generate a new Vending Key. It can be identified by a single digit (range 1-9).

[0028] Key Expiry Number (KEN): This stands for Key Expiry Number. It is associated with the electricity sales key and is used to define the expiry time of the electricity sales key and its corresponding decoding key. If the high 8 bits of the Time ID field (i.e., the return time identifier field) in the transfer token are greater than the key expiry number (KEN) stored in the electricity meter to be cleared, then the transfer token has expired and will be rejected.

[0029] Tariff Index (TI): This is used to identify the current tariff scheme or rate type used by the meter. It is one of the input parameters of the DecoderKey Generation Algorithm (DKGA) and can be identified by a 2-digit number.

[0030] Atomicity Consistency: In this invention, the "Transfer Token Generation" and "Balance Clearing" operations possess atomicity. They are considered an indivisible transaction throughout the entire business process, with only two possible outcomes: ① Complete Success: The transfer token is successfully generated and the meter balance is cleared; ② Complete Failure: If either the transfer token generation or the balance clearing operation fails, both operations are considered invalid. Atomicity consistency, also known as atomic clearing, prevents the abnormal scenario where only one operation is completed, ensuring the consistency of balance transfer business data.

[0031] Transaction Status Register: The transaction status register is a status identifier register stored in the non-volatile random access memory (NVRAM, such as EEPROM or embedded Flash simulated EEPROM area) of the meter MCU. This register is used to mark the transaction status of the balance transfer business process, ensuring that in case of power failure or other abnormal situations, the incomplete transaction can be recovered and continued. This invention pre-configures four transaction states: Idle state (IDLE), Start state (TXN_START), Transfer Token generated state (TOKEN_GENERATED), and Completed state (TXN_COMPLETE).

[0032] Fixed constant values ​​refer to static parameters that are fixed at the factory and cannot be arbitrarily modified during operation. These parameters are usually stored in the meter's non-volatile memory (such as EEPROM or Flash) and remain unchanged throughout the meter's entire lifespan. In this invention, the fixed constant values ​​are combined with KRN, KEN, and TI to form a calculation factor, which is used to derive the encryption key and enhance the key's randomness and security.

[0033] Cyclic shift: This refers to shifting bits in a binary sequence in a specified direction (left or right), without discarding the shifted-out bits, which are then cyclically added back to the other end of the sequence. In this invention, cyclic shift is used as one of the bit rearrangement permutation mechanisms to rearrange the bits of a first conversion factor, generating a second conversion factor. Its main purpose is to achieve diffusion, improve resistance to attacks, and generate a second keystream.

[0034] Fixed P-box permutation: This method achieves fixed mapping through table lookup. It involves rearranging each bit of the input binary sequence to a new output position according to the rules specified in the predefined fixed mapping table (table lookup method). In this invention, it can achieve diffusion, disrupt statistical structures, generate a second keystream, and reduce resource consumption.

[0035] Key-based dynamic bit permutation refers to a permutation rule (i.e., a bit mapping table) that is not fixed but dynamically derived from the input key. In this invention, the key can be derived from the Device Transmission Key (DUTK) or a derived decryption key. Even with the same input, different meters or sessions will produce different permutation outputs due to different keys. This dynamism significantly enhances resistance to known-plaintext attacks and differential cryptanalysis, preventing attackers from pre-constructing effective statistical models.

[0036] Bit permutation based on chaotic maps: This refers to using the iterative output sequence of chaotic systems (such as Logistic maps, Tent maps, etc.) to control the rearrangement order of bits. Chaotic maps have inherent characteristics such as extreme sensitivity to initial conditions and control parameters, and unpredictable trajectories over long periods. In this invention, the device transmission key or table number can be used as the initial value of the chaotic map to iteratively generate a pseudo-random sequence, which determines the new output position of each bit in the 44-bit data. Due to the strong ergodicity and randomness of the chaotic sequence, it can effectively destroy the statistical correlation between plaintext and ciphertext, improving security against linear cryptanalysis.

[0037] Matrix transpose permutation: This refers to filling the input bit sequence row-wise into a two-dimensional matrix (e.g., m rows × n columns), and then reading the output column-wise, or performing a row-column interchange (transpose operation) on the matrix to change the bit positions. For example, arranging 44-bit data into a 4-row × 11-column matrix, after transposing it becomes an 11-row × 4-column matrix, and then reading it bit by bit. In this invention, matrix transpose permutation, as a simple and efficient bit spreading method, can quickly scramble the spatial distribution of bits without introducing complex calculations. Combined with XOR encryption, it enhances the overall security strength, and has extremely low implementation cost, making it suitable for embedded environments such as electric meter MCUs.

[0038] Bit rearrangement based on a linear feedback shift register (LFSR): This refers to generating a pseudo-random sequence using a linear feedback shift register (LFSR), and then performing position permutation or scrambling operations on the input bit stream based on this sequence. An LFSR consists of a shift register and a linear feedback function, driven by a characteristic polynomial (primitive polynomial). It can generate a long-period sequence with good random statistical properties using only simple XOR and shift operations. In this invention, the LFSR can be used to determine the target position of each bit in the first conversion factor. Because the LFSR hardware implementation is extremely simple, has low power consumption, and is fast, it is particularly suitable for resource-constrained embedded devices such as electricity meters, and can generate stable pseudo-random permutation mappings with very low overhead.

[0039] Please see Figures 1 to 8 This invention provides a method for transferring the balance of a prepaid electricity meter.

[0040] like Figure 1 As shown, an embodiment of the present invention provides a method for transferring the balance of a prepaid electricity meter, which includes at least the following steps S1 to S7: S1: The meter to be cleared receives a balance transfer instruction.

[0041] The meter to be settled, acting as the receiving end of the balance transfer instruction, supports receiving the balance transfer instruction via public wireless network communication links (NB-IoT, 4G, 5G, etc.), power line carrier communication links (PLC), wired communication links (RS-485 communication protocol, Ethernet, etc.), wireless local area network communication links (LoRa, LoRaWAN, Wi-Fi, Bluetooth, etc.), and infrared communication links. It also supports triggering the balance transfer instruction via a local interaction module (dedicated maintenance port, physical button) or local virtual button operation. Therefore, in this embodiment, the issuance of the balance transfer instruction does not depend on a specific type of communication link.

[0042] The sending end of the balance transfer instruction includes, but is not limited to: the power company's main station system, the power operation and maintenance management platform, various portable terminals held by on-site operation and maintenance personnel, user handheld terminals, and the local interaction module of the meter to be cleared.

[0043] In some specific implementations, on-site maintenance personnel or meter users send balance transfer instructions to the MCU processor of the meter to be cleared via the local physical interface (infrared communication port, dedicated maintenance port, or physical button). Subsequently, the generation of the transfer token is also executed by the MCU processor of the meter to be cleared. Therefore, this embodiment supports the entire balance transfer operation being performed locally by the meter to be cleared in an offline state, without relying on any remote communication, and possesses offline availability and communication link independence.

[0044] S2: The meter to be settled, according to the balance transfer instruction, calls the key parameters of its supply group and the device transmission key DUTK uniquely bound to it to encrypt the asset transfer information including the balance, generate a transfer token, and write it to the temporary storage area.

[0045] In some specific implementations, a dual-obfuscation encryption mechanism combined with the STS standard encryption engine is used to perform joint encryption processing on asset transfer information, ultimately generating a transfer token.

[0046] Specifically, it includes the following sub-steps S21 to S27: S21: Call the key parameters of the supply group to which the meter to be cleared belongs.

[0047] When the meter is shipped from the factory, the key parameters of the supply group STS to which it belongs will be permanently stored in its internal non-volatile memory (such as EEPROM or Flash), which can be directly retrieved when needed.

[0048] For example, the key parameters of the supply group STS to which the electricity meter to be cleared belongs are: key revision number KRN=1 (indicating the use of the first version of the electricity sales key within the supply group), key expiration number KEN=0xFF (indicating that the validity of the electricity sales / decryption key expires on a certain base date), and electricity price index TI=01 (indicating that a residential electricity price scheme is adopted).

[0049] S22: Obtain the fixed constant value of the meter to be cleared.

[0050] Specifically, when the meter is shipped from the factory, a preset fixed constant value is stored in its internal non-volatile memory (such as EEPROM or Flash). This value is predefined by the STS key management algorithm and is used to form a calculation factor by concatenating it with KRN, KEN, and TI. When the meter performs encryption operations, its MCU directly reads the internal storage area to obtain the value.

[0051] S23: Combine the key revision number KRN, key expiration number KEN, and electricity price index TI from the key parameters being called with the obtained fixed constant value to form a calculation factor.

[0052] Specifically, the key revision number KRN (1 digit), key expiration number KEN (2 digits), electricity price index TI (2 digits), and fixed constant value (such as CA8FB6) of the supply group STS to which the meter to be settled are concatenated according to a preset concatenation method to form a calculation factor of preset number of digits.

[0053] For example, the calculation factor “1FF01CA8FB6” is formed by sequentially concatenating the KRN="1", KEN="FF", TI="01" and the fixed constant value “CA8FB6” corresponding to the supply group STS to which the meter to be settled belongs.

[0054] S24: First layer of obfuscation processing.

[0055] Specifically, the first conversion factor is calculated based on the meter number of the electricity meter to be cleared and the calculation factor.

[0056] For example, the 11-digit meter number of the meter to be cleared is XORed bit by bit with the calculation factor "1FF01CA8FB6" to obtain the first conversion factor.

[0057] S25: Bit rearrangement processing.

[0058] Specifically, the first conversion factor is subjected to bit rearrangement to obtain the second conversion factor.

[0059] Bit rearrangement (also known as bit shifting) falls under the P-box (permutation-box) operation in cryptography. Its core purpose is to achieve diffusion: any change to a plaintext bit in the original target data (i.e., the subsequent 44-bit payload) can affect multiple bits in the corresponding ciphertext, disrupting the statistical structure of the original data and improving its resistance to differential analysis and linear cryptanalysis. Furthermore, bit shifting can generate a second keystream (i.e., a second conversion factor) with statistical properties different from the first conversion factor, effectively enhancing the security strength of double XOR encryption.

[0060] For the same purpose, the bit rearrangement process may optionally employ any of the following five permutation mechanisms: bit shift, cyclic shift, fixed P-box permutation, key-based dynamic bit permutation, chaotic mapping-based bit permutation, matrix transpose permutation, and bit rearrangement based on a linear feedback shift register.

[0061] Preferably, using bit shifting as a permutation mechanism to achieve bit rearrangement is a trade-off between diffusion effect, implementation complexity, and the resource constraints of the meter MCU: it can ensure sufficient cryptographic security strength without introducing floating-point operations or large-capacity table lookups, making it more suitable for the operation and deployment of embedded devices such as electricity meters.

[0062] For example, the process of obtaining the first conversion factor and the second conversion factor is as follows: First, take the 11-digit number of the meter to be settled (each digit is treated as half a byte, forming a total of 44 bits), and perform an XOR conversion with the calculation factor to obtain a new first conversion factor.

[0063] For example, table number: 37123456789 00110111000100100011010001010110011110001001; The first conversion factor obtained from the corresponding calculation: 9CDCEB444CC 10011100110111001110101101000100010011001100.

[0064] Secondly, the first conversion factor is rearranged by bit shifting to obtain the second conversion factor.

[0065] For example, shifting methods: 10 01 11 00 11 01 11 00 11 10 10 11 01 00 01 00 01 00 11 00 11 00 <-> 00 11 11 00 11 00 11 00 11 00 10 01 01 00 01 01 01 00 11 10 11 10 The calculated second conversion factor: 3CCCC9454EE 0011110011001100110010010100010101010011101110.

[0066] S26: Second layer of obfuscation.

[0067] Specifically, the asset transfer information is encrypted using the first conversion factor and the second conversion factor to obtain the ciphertext payload.

[0068] The asset transfer information, which is the target of encryption, has an exemplary data structure as shown in Table 1 below: Table 1 As shown in Table 1 above, the 44-bit payload, which is the encryption target, not only includes five essential fields for the transfer of remaining electricity meter assets—return type, settlement method, return time identifier, return amount, and check bit—but also incorporates an auxiliary field, the device status word, to support business auditing and traceability.

[0069] For example, the 44-bit payload is XORed sequentially with the first conversion factor and the second conversion factor to obtain the ciphertext payload.

[0070] S27: Transfer Token Assembly.

[0071] Specifically, the ciphertext payload obtained through the above-mentioned double obfuscation encryption mechanism, along with the device transmission key DUTK retrieved in step S2, is first input into the STS standard encryption engine inside the meter to be cleared; the STS standard encryption engine performs the DEA / DES encryption operation specified in IEC 62055-41 to obtain the encrypted ciphertext payload; then the encrypted ciphertext payload is encoded to obtain a digital transfer token of a specified number of bits.

[0072] For example, a 20-digit digital token is ultimately generated. Here, the 20-digit digital token structure and encoding rules specified in the IEC 62055-41 standard are fully reused, and the output format fully complies with international standards, possessing good standard compatibility and universality.

[0073] For example, combined Figure 2 The detailed process of generating a digital transfer token based on the encrypted payload is as follows: ① Initial Token Data Assembly: Take 2 bits of the functional category (Class), 4 bits of the functional subclass (SubClass), 44 bits of the encrypted payload, and 16 bits of the CRC checksum to assemble a 66-bit initial token data. The 16-bit CRC checksum is obtained from the first 50 bits of data through cyclic redundancy check. Here, Class represents the functional category of the token; for example, in this embodiment, "Class 0: Credittransfer" is used to indicate that the generated transfer token is used for topping up or transferring credit limits. SubClass represents a further subclass of the functional category based on Class; the STS standard defines the meaning of each subclass. Here, the type and function of the generated transfer token are defined by "Class + SubClass".

[0074] The format of the assembled initial Token Data is shown in Table 2 below: Table 2 ②Key Acquisition: The device transmission key (DUTK) uniquely bound to the meter to be cleared is retrieved from the specified register.

[0075] ③ Encryption: Remove the "Class 2 bit" from the initial 66-bit Token Data to obtain a 64-bit result. Then, use this as the Data Block and input it together with the device transmission key DUTK obtained in step ② into the STS standard encryption engine to obtain the encrypted 64-bit Token Data.

[0076] ④ Transfer Token Generation: The removed "Class 2 bit" is reinserted into the encrypted 64-bit Token Data according to the method specified in the IEC 62055-41 standard, resulting in a complete 66-bit binary Token Data; then it is converted into a 20-digit decimal string according to the encoding rules specified in the IEC 62055-51 standard, which is the final transfer token.

[0077] By following the steps above, the transfer token can be strictly bound to the key status of the meter to be cleared, ensuring that the transfer token cannot be tampered with and improving the security and trustworthiness of the transfer token.

[0078] S3: Update the transaction status of the transaction status register in the meter to be cleared to the status of "transfer token generated".

[0079] In this embodiment, the electricity meter to be cleared maintains a transaction status register to mark the transaction status of the business process, ensuring that the two operations of "transfer token generation" and "balance clearing" have atomic consistency; and a power failure recovery mechanism is set up to avoid data inconsistency and balance deviation caused by business interruption.

[0080] In some specific implementations, the transaction status register is stored in the non-volatile random access memory (NVRAM) of the MCU processor for the meter to be cleared, such as EEPROM or an embedded Flash emulated EEPROM area, to ensure that the data is not lost after power failure.

[0081] Specifically, the transaction status register is pre-configured with the following four transaction states: (1) IDLE (0x00): corresponds to the idle state; (2) TXN_START (0x01): Corresponds to the start status; indicates that a balance transfer instruction has been received and the transaction has started; (3) TOKEN_GENERATED (0x02): This corresponds to the status of the transfer token being generated; it indicates that the transfer token has been generated and successfully written to the temporary storage area, and the balance is ready to be cleared. (4) TXN_COMPLETE (0x03): Corresponds to the completion status; it indicates that the balance has been cleared and the transaction is completed.

[0082] In some specific implementations, after step S1: the meter to be cleared receives the balance transfer instruction, the method further includes: Determine whether the current transaction status of the transaction status register is "idle". If not, the balance transfer instruction is rejected and an error is returned; If so, update the transaction status of the transaction status register to "TXN_START (0x01)", i.e. "start status", and then execute step S2.

[0083] S4: Clear the balance of the meter to be settled to zero, and update the transaction status of the transaction status register to the completed status.

[0084] For example, clearing the balance specifically means writing "0" to the balance register of the meter to be cleared.

[0085] This completes the atomic clearing of the balance, ensuring the atomic consistency of the two operations: "transfer token generation" and "balance clearing".

[0086] When the transaction status in the transaction status register has been set to "completed" for a preset time, the transaction status will be updated to "idle".

[0087] In this embodiment, the specific implementation process of setting up a power-loss recovery mechanism for the transaction status register is as follows: After the power meter is restored after a power outage, the transaction status of its internal transaction status register is checked first. If the current transaction status in the transaction status register is "started", it means that the transaction has not been completed. The tokens generated before the power failure or not stored in the temporary storage area are invalid. The process is rolled back to step S2 to regenerate the transfer token. If the current transaction status of the transaction status register is "transfer token generated", it means that the transfer token was generated and successfully stored in the temporary storage area before the power failure. The transfer token is valid, so continue to execute step S3 and atomically clear the current balance information. If the current transaction status in the transaction status register is "complete" or "idle", then there is no action, which means the transaction status is consistent and no processing is required.

[0088] Please see Figure 3 , Figure 3 This diagram illustrates the relationship between transaction status and business process in the power-off recovery mechanism provided by the transaction status register according to a specific embodiment of the present invention. Figure 3 The document details the four stages of the transaction state during the generation of the transfer token for the electricity meter to be cleared, the migration conditions, and the automatic recovery logic when power is restored after a power outage in different states.

[0089] S5: After receiving the transfer token, the processing system calls the key parameters of the supply group to which the electricity meter to be liquidated belongs and the device transmission key uniquely bound to it to decrypt the transfer token and extract the asset transfer information of the electricity meter to be liquidated.

[0090] In some specific implementations, the transfer token is transmitted to the processing system by manual input; alternatively, it can be uploaded to the processing system via any of the communication links listed in step S1 above.

[0091] For example, after step S4, the meter to be cleared will display a 20-digit transfer token on the LCD screen; the on-site personnel will then transcribe the token and submit it to the processing system at the power company office / online.

[0092] In some specific implementation methods, please refer to Figure 4 The process of understanding and processing the transfer token after it is received by the system includes the following sub-steps S51 to S54.

[0093] S51: Format validation.

[0094] The format validation items include: length validation and character range validation.

[0095] The purpose of this verification step is to check whether the transfer token conforms to the 20-digit number format requirement, in order to eliminate transcription errors or illegal input.

[0096] If the format is incorrect, the format validation fails and the transfer token is returned as invalid; for example, the error code "ERR_FORMAT" is returned. If the format is correct, the format verification is deemed successful, and the transfer token is parsed.

[0097] For example, the parsing process is as follows: the transfer token is decoded and converted into "66-bit complete binary token data" according to standard encoding rules.

[0098] S52: Cryptographic verification.

[0099] Specifically, cryptographic verification includes the following steps: stp1-Stp6: STP1, Key Acquisition: The processing system obtains the unique meter identifier of the meter to be cleared based on the user's business information (including the meter number of the meter to be cleared); based on the obtained unique meter identifier, it retrieves the key parameters of the supply group to which the meter to be cleared belongs and the corresponding device transmission key (DUTK) from the Key Management Service System (KMS).

[0100] Stp2, Decryption: First, remove 2 Class bits from the decoded "66-bit complete binary Token Data" according to the standard encoding rules to obtain "encrypted 64-bit Token Data"; then use the retrieved device transmission key DUTK to decrypt the "encrypted 64-bit Token Data". If decryption is successful, obtain the decrypted "64-bit Data Block" and perform CRC check; If decryption fails, the cryptographic verification is deemed unsuccessful, and the transfer token is returned as invalid. For example, the error code "DeCode_ERR" is returned, indicating that decryption was invalid and the transfer token has been tampered with.

[0101] STP3, CRC check: Assemble "2 Class bits" + "64-bit Data Block" to obtain 66-bit initial Token Data; take the first 50 bits of data and perform CRC check to obtain the check value; If the check value matches the 16-bit CRC in the decrypted "64-bit Data Block" (see Table 2 above), the check is considered successful, and Stp4 is executed. If there is a discrepancy, the verification fails, and the transfer token is returned as invalid. For example, the error code "CRC_ERR" is returned, indicating a verification error and that the transfer token is invalid.

[0102] Stp4, Extracting Valid Ciphertext Payload: Extract a 44-bit ciphertext payload from the "66-bit Initial Token Data" for use in subsequent decryption steps.

[0103] Stp5, Decrypt the ciphertext payload: Obtain the meter number and fixed constant value of the meter to be cleared; based on the key parameters of the supply group to which the meter to be cleared belongs, the obtained meter number and fixed constant value, decrypt the obtained ciphertext payload. If decryption is successful, the asset transfer information of the electricity meter to be liquidated will be obtained; If decryption fails, the cryptographic verification is deemed unsuccessful, and the transferred token is returned as invalid.

[0104] For example, corresponding to the double obfuscation encryption mechanism implemented in the above sub-steps S21 to S26, the specific process of Stp5 decrypting the ciphertext payload to obtain asset transfer information is as follows: Stp5a-5d: Stp5a: Based on the key parameters called (key revision number KRN, key expiration number KEN, and electricity price index TI) and the fixed constant value of the meter to be settled, obtain the calculation factor; Stp5b: Calculate the first conversion factor based on the meter number of the electricity meter to be cleared and the calculation factor. Stp5c: The second conversion factor is obtained by using the same bit rearrangement and permutation mechanism as the electricity meter to be cleared. Stp5d: Decrypt the ciphertext payload based on the first and second conversion factors to obtain asset transfer information.

[0105] This yields a 44-bit payload containing six fields: return type, settlement method, return time identifier, return amount, checksum, and device status word.

[0106] Stp6. Calculate the verification value of the asset transfer information and compare the calculated verification value with the verification value recorded in the asset transfer information; for example, calculate the CRC check value of the first 40 bits in the 44-bit payload; then compare the calculated CRC check value with the last 4 bits of the CRC check bit in the 44-bit payload.

[0107] If they do not match, the cryptographic verification is deemed unsuccessful, and the transfer token is returned as invalid. If they match, the cryptographic verification is considered successful, and the validity period verification is then performed. S53: Timeliness verification; Specifically, the timeliness verification includes: Based on the return time identifier field in the asset transfer information, determine whether the transfer token is within a preset validity period (e.g., 30 days); If there is a discrepancy, the timeliness verification is deemed to have failed, and the transfer token is returned as invalid; for example, the error code "ERR_EXPIRED" is returned, indicating that the transfer token has expired; If so, the timeliness verification is deemed successful, and the replay protection verification is executed; S54: Anti-replay verification; Specifically, the replay protection verification includes: Query the processed transfer token registry to determine whether the transfer token is stored in the processed transfer token registry; If so, the replay protection verification fails, and the transfer token is returned as invalid; for example, the error code "ERR_REPLAY" is returned, indicating that the transfer token has been used. If not, the anti-replay verification is deemed successful, and the transfer token is valid; at the same time, the transfer token is stored in the processed transfer token registry.

[0108] S6: The processing system obtains the balance of the electricity meters to be settled based on the asset transfer information of the meters to be settled.

[0109] For example, the content of the "Return Quota" field in the asset transfer information is obtained, such as "Quota = X.XXkwh".

[0110] S7: Scenario-based business processing.

[0111] S71: In the case of account cancellation, the processing system calculates the amount to be refunded based on the asset transfer information of the electricity meter to be cleared.

[0112] For example, the amount to be refunded to the user is calculated using the formula: Credit Limit × Electricity Price = Refund Amount; then the refund is returned to the user via bank transfer or e-wallet, thus completing the account closure and archiving.

[0113] Please combine Figure 5 To understand, Figure 5 The diagram illustrates the complete process from token transfer to refund completion in a specific implementation scenario for account cancellation.

[0114] S72: In the meter replacement scenario, the processing system, based on the asset transfer information of the meter to be cleared, calls the key parameters of the supply group to which the target new meter belongs and the device transmission key uniquely bound to it to generate an equivalent recharge token. Subsequently, the target new meter will verify the legality of the input recharge token. After successful verification, the corresponding amount will be written into the table, completing the cross-meter transfer of the balance.

[0115] Please combine Figure 6 To understand, Figure 6 The diagram illustrates the complete process of generating a transfer token from the old meter to the new meter in a meter replacement scenario provided by a specific implementation method.

[0116] Please see Figure 7 This is a schematic diagram illustrating the overall process of a prepaid electricity meter balance transfer method provided in a specific implementation of Embodiment 1. The diagram details the entire business process, starting from the issuance of a balance transfer instruction by on-site personnel (maintenance personnel / users), the generation and atomic clearing of a transfer token on the meter to be cleared, the display of the transfer token on the LCD, the submission of the transfer token by on-site personnel to the processing system for multi-level verification and scenario-based (meter replacement / account cancellation) processing, and finally the completion of the credit transfer or refund.

[0117] Please see Figure 8 Another embodiment of the present invention, based on the above embodiments, provides a prepaid electricity meter balance transfer system.

[0118] like Figure 8 As shown, the prepaid electricity meter balance transfer system provided in this embodiment includes the electricity meter to be cleared and the processing system.

[0119] The electricity meter to be cleared is used to perform the steps executed by the electricity meter to be cleared in the prepaid electricity meter balance transfer method described in the above embodiments; The processing system is used to execute the steps performed by the processing system in the prepaid electricity meter balance transfer method described in the above embodiments.

[0120] The specific steps have been described in detail in the above embodiments and will not be repeated here.

[0121] In the case of meter replacement, the system also includes the target new meter.

[0122] The processing system is also used to generate an equivalent amount of recharge tokens by calling the key parameters of the supply group to which the target new electricity meter belongs and the device transmission key uniquely bound to it, based on the asset transfer information of the electricity meter to be cleared. The target new electricity meter is used to receive and verify the recharge token; if the verification is successful, the corresponding amount is written.

[0123] For example, the composition and data interaction relationship among the electricity meter to be cleared, the power company's dedicated processing system, and the target new electricity meter are as follows: Figure 8 As shown.

[0124] In some specific implementations, such as Figure 8 As shown, the meter to be settled is an STS prepaid smart meter with an embedded MCU; in this embodiment, it mainly undertakes the functions of transfer token generation, atomic balance clearing, and human-computer interaction. Its core functional components include: STS encryption engine, transaction status management register, balance management unit, LCD display driver (responsible for scrolling and displaying the 20-digit transfer token), and local command interface. It has the following security features: key parameters are stored in a secure area and cannot be remotely exported through any external interface; they can only be called by the local encryption engine.

[0125] In some specific implementations, the processing system is a power company's data center or cloud server; in this embodiment, it mainly undertakes the parsing, verification, decryption, and business processing of transfer tokens. Its core functional components include: a token parsing engine, a key management system (KMS), a business logic processing unit, a recharge token generator, an anti-replay verification unit, and operation audit logs. It possesses the following security features: hierarchical key management, operator access control, and full audit logs.

[0126] In some specific implementations, the target new electricity meter is an STS prepaid smart meter with an embedded MCU. In this embodiment, it primarily handles the reception, verification, and credit writing of recharge tokens. Its core functional components include: an STS token verification engine, a credit writing unit, and a local input interface. It possesses the following security features: it only accepts legitimate STS standard tokens that have passed cryptographic verification, and rejects inputs with invalid formats or those that have failed decryption / verification.

[0127] Based on any of the above embodiments, the present invention also provides two specific application scenarios.

[0128] Scenario 1: Balance transfer after meter replacement due to fault (including power failure recovery).

[0129] The user's electricity meter (meter number 37123456789) is faulty, with 85.0 kWh remaining, and needs to be replaced.

[0130] The execution steps are as follows: (1) Issuing instructions: Maintenance personnel issue balance transfer instructions to old meters through infrared interfaces.

[0131] (2) Atomic operations and power-down simulation: 1. The old meter enters the TXN_START (0x01) state, reads the balance as 85.0 kWh, and generates a transfer token: 4729 3861 0584 7291 6315.

[0132] 2. Write the transfer token to the NVRAM staging area and update the status to TOKEN_GENERATED (0x02).

[0133] 3. Suppose that the old electricity meter unexpectedly loses power at this time; 4. After the old meter is powered on again, the meter detects that the status is TOKEN_GENERATED (0x02), automatically clears the balance (85.0→0.0), updates the status to TXN_COMPLETE (0x03), and displays the transfer token on the LCD screen.

[0134] (3) Submission and verification: On-site personnel (maintenance personnel / users) record the transfer token and submit it to the power business hall; the system verifies the verification information and timeliness, and decrypts and extracts 85.0kWh.

[0135] (4) Generate recharge token: The system uses the key parameters of the new meter to generate a recharge token for 85.0 kWh: 18935647 2901 8356 4287.

[0136] (5) New meter entry: Enter the recharge token into the new meter. After verification, the balance increases by 85.0 kWh and the transfer is complete.

[0137] Scenario 2: User cancels account and receives a refund.

[0138] The user has cancelled their account, and the meter still has 32.0 kWh remaining. The electricity price is 1.20 yuan / kWh.

[0139] Execution steps: (1) Generate transfer token: The meter generates transfer token: 7384 6291 5048 3712 9546, and simultaneously clears the balance.

[0140] (2) Submission and verification: The system verifies that the transfer token is valid and decrypts the extraction amount of 32.0kWh.

[0141] (3) Refund calculation: The system automatically calculates the refund amount as 32.0 × 1.20 = 38.40 yuan and refunds it to the user via bank transfer, thus completing the account closure and archiving.

[0142] In summary, the prepaid electricity meter balance transfer method and system provided by this invention utilizes an atomic synchronization mechanism for transfer token generation and balance clearing, along with a power outage recovery mechanism. The balance is immediately cleared upon transfer token generation, avoiding power loss during the meter reading cycle. After a power outage, data is restored using the transaction status register, ensuring accurate, unbiased data and eventual consistency. A dual-layer encryption architecture combining a one-meter-one-key obfuscation encryption mechanism with the STS standard encryption engine is employed for joint encryption processing. The transfer token is encrypted based on the local device's transmission key (DUTK) and key parameters, and the credit limit is stored in ciphertext. Transfer tokens for different meters are non-interchangeable, non-tamperable, and non-repudiable, possessing high security and tamper-proof characteristics. Token generation is supported in the local offline state of the meter to be settled, without relying on a communication link. Settlement vouchers can still be issued on-site even in scenarios of meter failure or communication interruption, reducing maintenance costs. A 20-bit ciphertext token is used, with credit limit information encapsulated within the transfer token in 44-bit ciphertext, preventing direct external parsing and effectively protecting user electricity privacy. This invention is fully compatible with the IEC 62055-41 STS international standard. Existing STS meters can be deployed simply by upgrading the firmware, without any hardware modifications, demonstrating excellent versatility. Furthermore, this invention enables unified token generation for both account cancellation and meter replacement scenarios, simultaneously supporting two types of transactions: balance transfer during meter replacement and refund upon account cancellation, simplifying the logic implementation on the meter side.

[0143] Although preferred embodiments of the invention have been described, those skilled in the art, upon understanding the basic inventive concept, can make other changes and modifications to the embodiments. Therefore, the appended claims are intended to cover the preferred embodiments and all equivalent modifications falling within the scope of protection defined by the claims and their equivalents. Clearly, those skilled in the art can make various alterations and variations to the invention without departing from its spirit and scope. If such modifications and variations fall within the scope of protection defined by the claims and their equivalents, the invention also intends to include them.

[0144] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware.

[0145] In this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "multiple" means two or more, unless otherwise explicitly specified. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone.

[0146] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0147] In this specification, the use of terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refers to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the present invention. The illustrative expressions of the above terms in this specification should not be construed as necessarily referring to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0148] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for transferring the balance of a prepaid electricity meter, characterized in that, include: After the clearing meter receives the balance transfer instruction, it calls the key parameters of its supply group and the device transmission key uniquely bound to it to encrypt the asset transfer information including the balance, generate a transfer token, and write it into the temporary storage area; the key parameters include the key revision number KRN, the key expiration number KEN, and the electricity price index TI; Update the transaction status register in the electricity meter to be cleared to the status that the transfer token has been generated; Clear the balance of the electricity meter to be settled to zero, and update the transaction status of the transaction status register to the completed status; After receiving the transfer token, the processing system calls the key parameters of the supply group to which the electricity meter to be liquidated belongs and the device transmission key uniquely bound to it to decrypt the transfer token and extract the asset transfer information of the electricity meter to be liquidated.

2. The method for transferring prepaid electricity meter balance as described in claim 1, characterized in that, The process of encrypting asset transfer information by calling the key parameters of its supply group and the transmission key of the device uniquely bound to it, and generating a transfer token, specifically includes: Retrieve the key parameters of the supply group to which the meter to be cleared belongs; Obtain the fixed constant value of the electricity meter to be cleared; The key revision number KRN, key expiration number KEN, and electricity price index TI from the key parameters called are combined with the obtained fixed constant value to form a calculation factor. The first conversion factor is calculated based on the meter number of the electricity meter to be cleared and the calculation factor. The first conversion factor is rearranged in bits to obtain the second conversion factor; Using the first conversion factor and the second conversion factor, the asset transfer information is encrypted to obtain the ciphertext payload; The encrypted payload is encrypted by invoking the device transmission key uniquely bound to the meter to be cleared; The encrypted ciphertext payload is encoded to generate a transfer token.

3. The method for transferring prepaid electricity meter balance as described in claim 2, characterized in that, The bit rearrangement process employs any one of the following five permutation mechanisms: bit shift, cyclic shift, fixed P-box permutation, key-based dynamic bit permutation, chaotic mapping-based bit permutation, matrix transpose permutation, and bit rearrangement based on a linear feedback shift register.

4. The method for transferring prepaid electricity meter balance as described in claim 2, characterized in that, The step of decrypting the transfer token by invoking the key parameters of the supply group to which the electricity meter to be settled belongs and the device transmission key uniquely bound to it specifically includes: Verify if the format of the transfer token is correct; if incorrect, return that the transfer token is invalid; if correct, parse the transfer token to obtain the encrypted ciphertext payload. Based on user service information, obtain the unique meter identifier of the meter to be settled; the user service information includes the meter number of the meter to be settled. Based on the unique meter identifier obtained, the key parameters of the supply group to which the meter to be cleared belongs and the corresponding device transmission key are retrieved from the Key Management Service System (KMS). Based on the retrieved device transmission key, the encrypted ciphertext payload is decrypted; if decryption fails, the transfer token is returned as invalid; if decryption succeeds, the ciphertext payload is obtained. Based on the retrieved key parameters, the meter number of the electricity meter to be liquidated, and the fixed constant value, the obtained encrypted payload is decrypted; if decryption is successful, the asset transfer information of the electricity meter to be liquidated is obtained; if decryption fails, the transfer token is returned as invalid. Calculate the verification value of the asset transfer information and compare the calculated verification value with the verification value recorded in the asset transfer information; if they do not match, return that the transfer token is invalid. If they match, then based on the return time identifier field in the asset transfer information, determine whether the transfer token is within the preset validity period; if not, return that the transfer token has expired. If yes, determine whether the transfer token is stored in the processed transfer token registry; if yes, return that the transfer token has been used; if no, determine that the transfer token is valid.

5. The method for transferring prepaid electricity meter balance as described in claim 1, characterized in that, The data structure of the asset transfer information includes a return type field, a settlement method field, a return time identifier field, a return amount field, and a verification value field.

6. The method for transferring prepaid electricity meter balance as described in claim 1, characterized in that, The transaction status register is stored in the non-volatile memory of the meter to be cleared; the transaction status register is pre-configured with the following four transaction states: idle state, start state, transfer token generated state, and completed state; After receiving the balance transfer instruction, the meter to be settled also includes: Determine whether the current transaction status of the transaction status register is idle; If not, the balance transfer instruction is rejected and an error is returned; If so, update the transaction status of the transaction status register to the started state and execute the generation of transfer token; When the transaction status in the transaction status register has been set to the completed state for a preset time, the transaction status will be updated to the idle state.

7. The method for transferring prepaid electricity meter balance as described in claim 1, characterized in that, Also includes: After the power outage is restored, the transaction status of the clearing meter is checked in its transaction status register. If the transaction status in the transaction status register is in the started state, then roll back to the key parameters of the supply group to which the call belongs and the device transmission key uniquely bound to it to encrypt the current balance information and regenerate the transfer token; If the transaction status in the transaction status register is "transfer token has been generated", then continue to execute the atomic clearing of the current balance information; If the transaction status register shows a completed or idle state, no action is taken.

8. The method for transferring prepaid electricity meter balance as described in claim 1, characterized in that, Also includes: In the case of account cancellation, the processing system calculates the amount to be refunded based on the asset transfer information of the electricity meter to be settled; In the case of meter replacement, the processing system uses the asset transfer information of the meter to be cleared to call the key parameters of the supply group to which the target new meter belongs and the device transmission key uniquely bound to it to generate an equivalent amount of recharge token.

9. A prepaid electricity meter balance transfer system, characterized in that, This includes the electricity meters to be cleared and the processing system; The electricity meter to be settled is used to perform the steps executed by the electricity meter to be settled in the prepaid electricity meter balance transfer method according to any one of claims 1 to 8 above. The processing system is used to execute the steps performed by the processing system in the prepaid electricity meter balance transfer method according to any one of claims 1 to 8.

10. The prepaid electricity meter balance transfer system as described in claim 9, characterized in that, In the context of meter replacement, this also includes the target new electricity meter; The processing system is also used to generate an equivalent amount of recharge tokens by calling the key parameters of the supply group to which the target new electricity meter belongs and the device transmission key uniquely bound to it, based on the asset transfer information of the electricity meter to be cleared. The target new electricity meter is used to receive and verify the recharge token; If the verification passes, the corresponding credit limit will be written.

Images