Verification processing methods, devices, and electronic equipment

Abstract

This application provides a verification processing method, apparatus, and electronic device, relating to the field of data processing technology, which alleviates the technical problem of low data management efficiency in medical institutions. The method includes: obtaining verification data provided by the access party; detecting whether the access party has passed verification based on the verification data; if the access party has passed verification, finding the corresponding agent ID based on the access party ID, sending the corresponding Token encryption key to the agent ID, and signing the sent Token encryption key using an RSA private key; monitoring requests to verify the Token encryption key, and if a verification request is sent, verifying the signature using an RSA public key; if the signature verification passes, receiving the Token encryption key; extracting the Token using the received Token encryption key, and verifying the Token; if the Token verification passes, receiving the response result data.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a verification processing method, apparatus, and electronic device. Background Technology

[0002] Currently, electronic prescription review is widely used in major medical institutions. By introducing a professional medication rule database and a pharmacist manual review process, as well as strictly controlling the pharmacist's dispensing process, it is an important method to expose drug abuse problems and eliminate medication safety issues. It also ensures rational and safe drug use and can reduce conflicts between doctors and patients. However, due to data security concerns, hospitals and other medical institutions use multiple versions of data management systems, causing management confusion between different versions and affecting the efficiency of data management in medical institutions. Summary of the Invention

[0003] The purpose of this invention is to provide a verification processing method, apparatus, and electronic device to alleviate the technical problem of low data management efficiency in medical institutions.

[0004] In a first aspect, embodiments of this application provide a verification processing method applied to a gateway device, wherein multiple gateway devices correspond to multiple devices, and the method includes:

[0005] Obtain verification data provided by the access party; wherein, the verification data includes the access party ID;

[0006] Based on the verification data, it is determined whether the access party has passed the verification;

[0007] If the access party verification is successful, the corresponding proxy ID is found based on the access party ID, and the corresponding Token encryption key is sent to the proxy ID. The sent Token encryption key is then signed using an RSA private key. The RSA private key is a private key based on the RSA encryption algorithm.

[0008] The system monitors requests to verify the encryption key of the token. If such a verification request is sent, the system verifies the signature using an RSA public key, wherein the RSA public key is a public key based on the RSA encryption algorithm.

[0009] If the signature verification passes, the device receives the Token encryption key in response; the received Token encryption key is used to extract the Token, and the Token is verified. If the Token verification passes, the device receives the response result data corresponding to the Token encryption key; wherein the response result data is generated based on the Token encryption key and the structured prescription data.

[0010] The step of detecting whether the access party has passed verification based on the verification data further includes:

[0011] If the access party fails the verification, the verification failure information is returned in reverse order of the original path, and the verification data is re-detected;

[0012] The step of monitoring requests to verify the Token encryption key, and verifying the signature using an RSA public key if the verification request is sent, further includes:

[0013] If the signature verification fails, the Token encryption key will not be accepted.

[0014] The step of extracting the token using the received token encryption key, verifying the token, and receiving the response result data corresponding to the token encryption key if the token verification is successful further includes:

[0015] If the token verification is successful, the verification data is forwarded and the verification process is displayed on the graphical user interface.

[0016] In one possible implementation, the step of finding the corresponding proxy ID based on the access party ID and sending the corresponding Token encryption key to the proxy ID, and signing the sent Token encryption key using an RSA private key, if the access party verification is successful, further includes:

[0017] If the access party passes the verification, the corresponding configuration ID is found based on the access party ID, and the corresponding proxy ID is found based on the configuration ID. The corresponding token encryption key is then sent to the proxy ID.

[0018] In one possible implementation, it also includes:

[0019] If the token verification fails, the verification failure information is returned in reverse order of the original path, and the verification failure response result data is received.

[0020] In one possible implementation, the verification data further includes one or more of the following:

[0021] Hospital name, resource name, accessible range, callback address.

[0022] Secondly, a verification processing device is provided, applied to a gateway device, wherein multiple gateway devices correspond to multiple devices, and the device includes:

[0023] The acquisition module is used to acquire verification data provided by the access party; wherein, the verification data includes the access party ID;

[0024] The detection and verification module is used to detect whether the access party has passed the verification based on the verification data;

[0025] The signature module is used to find the corresponding proxy ID based on the access party ID if the access party verification is successful, send the corresponding Token encryption key to the proxy ID, and sign the sent Token encryption key using an RSA private key; wherein, the RSA private key is a private key based on the RSA encryption algorithm;

[0026] The monitoring request module is used to monitor requests to verify the encryption key of the Token. If the verification request is sent, the signature is verified using the RSA public key; wherein, the RSA public key is a public key based on the RSA encryption algorithm.

[0027] The data receiving module is configured to receive the Token encryption key if the signature verification passes; extract the Token using the received Token encryption key and verify the Token; and receive the response result data corresponding to the Token encryption key if the Token verification passes.

[0028] The detection and verification module is further configured to: if the access party fails the verification, return the verification failure information in reverse order of the original path, and re-detect the verification data;

[0029] The monitoring request module is also used to: if the signature verification fails, then not to receive the Token encryption key;

[0030] The data receiving module is also used to: forward the verification data and display the verification process on the graphical user interface if the Token verification is successful.

[0031] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect above.

[0032] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to perform the method described in the first aspect above.

[0033] The embodiments of this application bring the following beneficial effects:

[0034] This application provides a verification processing method, apparatus, and electronic device capable of acquiring verification data provided by an access party. The verification data includes an access party ID. The method checks whether the access party has passed verification based on the verification data. If the access party passes verification, the method finds the corresponding proxy ID based on the access party ID and sends the corresponding Token encryption key to the proxy ID. The method then signs the sent Token encryption key using an RSA private key, where the RSA private key is a private key based on the RSA encryption algorithm. Simultaneously, the method monitors requests for verifying the Token encryption key. If a verification request is sent, the method verifies the signature using an RSA public key, where the RSA public key is a public key based on the RSA encryption algorithm. If the signature verification passes, the method receives the Token encryption key. The method then extracts the Token using the received Token encryption key and verifies the Token. If the Token verification passes, the method receives the response result data corresponding to the Token encryption key. This solution, by building a verification plugin platform, can incorporate information from multiple aspects into a unified system management module, making management more convenient, more controllable, and lower in maintenance costs. It further protects process security and data security, enhances hospital management confidence, facilitates the smooth implementation of the prescription review platform in multiple scenarios, and alleviates the technical problem of low data management efficiency in medical institutions.

[0035] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0037] Figure 1 A flowchart illustrating a verification processing method provided in an embodiment of this application;

[0038] Figure 2 This is a schematic diagram of an overall platform for a verification processing method provided in an embodiment of this application;

[0039] Figure 3 This is a schematic diagram of the structure of a verification processing device provided in an embodiment of this application;

[0040] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this application, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0043] Currently, the electronic prescription review function is a general-purpose function that is not used directly by the platform but is embedded into the HIS system. However, directly embedding the relevant code into the HIS system will cause some intrusive interference to the HIS system, leading to compatibility issues. Moreover, different HIS systems may have some differences, and in order to ensure that all HIS systems work properly, additional code needs to be developed and maintained.

[0044] Secondly, due to data security considerations, hospitals isolate their networks into internal and external networks, making it impossible to deploy the electronic prescription review function to external networks (such as WeChat platforms or other internet application scenarios). The inability to uniformly deploy the code leads to management chaos between different versions, continuous upgrades, and affects the correctness of the prescription review process.

[0045] Based on this, the present application provides a verification processing method, which can alleviate the technical problem of low data management efficiency in medical institutions.

[0046] The embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0047] Figure 1 This is a flowchart illustrating a verification processing method provided in an embodiment of this application, applied to a gateway device, where multiple gateway devices correspond to multiple devices. For example... Figure 1 As shown, the method includes:

[0048] Step S110: Obtain the verification data provided by the access party.

[0049] The verification data includes the access party ID.

[0050] It should be noted that the configuration can include information such as hospital name, token encryption key, token expiration time, refresh token expiration time, whether to enable WeChat verification option, and whether to enable client domain verification option, and the configuration ID is automatically generated according to rules; as well as the proxy service configuration, including resource name, callback key address, corresponding configuration ID, and proxy ID automatically generated according to rules; and the access party configuration, including access party ID (automatically generated according to rules), access party key (automatically generated according to rules), WeChat AppId (automatically obtained through verification stream), caller type (Mini Program, WeChat Web, General), access party name, callback address, client domain (automatically obtained through verification process), access range, and corresponding configuration ID.

[0051] Step S120: Detect whether the access party has passed the verification based on the verification data.

[0052] It accepts and verifies the authentication data (such as access party ID, access party key, etc.) input by the access party.

[0053] In step S130, if the access party's verification is successful, the corresponding proxy ID is found based on the access party ID, and the corresponding Token encryption key is sent to the proxy ID. The sent Token encryption key is then signed using the RSA private key.

[0054] The RSA private key is a private key based on the RSA encryption algorithm; the Token encryption key is a symmetric encryption key, and its decryption key is the same as the encryption key.

[0055] It should be noted that if the access party's key is verified, a verification success message is returned; otherwise, a verification failure message is returned. Additionally, if a unique code (access party ID) provided by the framework platform can be obtained, it can be determined based on the configuration information whether to perform auxiliary verification on the unique code to determine whether the access party has violated regulations.

[0056] Step S140: Monitor for requests to verify the Token encryption key. If a verification request is sent, verify the signature using the RSA public key.

[0057] The RSA public key is a public key based on the RSA encryption algorithm;

[0058] It should be noted that the key data distribution process uses SSL transmission and is signed using an RSA private key.

[0059] By using RSA private keys for signing, the security and stability of data transmission are enhanced, reducing the risk of data leakage. At the same time, the use of SSL transmission technology can effectively protect the access party's data from being hijacked and tampered with, further protecting process security and data security, which is conducive to the smooth implementation of the review platform in multiple scenarios.

[0060] Step S150: If the signature verification is successful, the Token encryption key is received; the Token is extracted using the received Token encryption key and the Token is verified; if the Token verification is successful, the response result data corresponding to the Token encryption key is received.

[0061] It should be noted that when the access party calls the prescription review function interface, the data to be sent includes a token and structured prescription data (or JSON format). During this process, if token verification fails, the verification failure information is returned via the reverse path; otherwise, the corresponding verification result is returned via the reverse path.

[0062] By building a verification plugin platform, information from various aspects can be incorporated into a unified system management module, making management more convenient, more controllable, and lower in maintenance costs. This further protects process security and data security, enhances hospital management confidence, and facilitates the smooth implementation of the prescription review platform in multiple scenarios.

[0063] The steps described above will be explained in detail below.

[0064] Based on step S130 above, the method may further include the following steps:

[0065] Step a) If the access party passes the verification, find the corresponding configuration ID based on the access party ID, find the corresponding proxy ID based on the configuration ID, and send the corresponding Token encryption key to the proxy ID.

[0066] By configuring the ID to find the corresponding proxy ID and sending the corresponding Token encryption key to the proxy ID, control permissions are easier to obtain and data security is effectively guaranteed.

[0067] Based on step S140 above, the method may further include the following steps:

[0068] Step b) If the signature verification fails, the token encryption key will not be received.

[0069] Verifying signatures controls access permissions, eliminates code version fragmentation and code deployment fragmentation, and improves the ease of feature expansion.

[0070] In some embodiments, the method may further include the following steps:

[0071] Step c): If the token verification fails, return the verification failure information in reverse order of the original path and receive the verification failure response data.

[0072] It should be noted that during this process, if the token verification fails, the verification failure information will be returned by reversing the original path; otherwise, the corresponding verification result will be returned by reversing the original path.

[0073] Based on step S120 above, the method may further include the following steps:

[0074] Step d): If the access party fails the verification, the verification failure information is returned in reverse order of the original path, and the verification data is re-checked.

[0075] By promptly returning verification results, real-time workload can be effectively reduced, and the efficiency of data management in medical institutions can be improved.

[0076] In some embodiments, the verification data includes one or more of the following:

[0077] Hospital name, resource name, accessible range, callback address.

[0078] For example, such as Figure 2 As shown, by incorporating various access party information and permission configuration information into a unified system management platform, the convenience and controllability of data management are improved, hospital maintenance costs are reduced, and implementation workload is decreased.

[0079] Based on step S150 above, the method may further include the following steps:

[0080] Step e): If the token verification is successful, forward the verification data and display the verification process on the graphical user interface.

[0081] By visually demonstrating the verification process, the efficiency of data management was improved, process and data security were protected, and the hospital's confidence was enhanced.

[0082] Figure 3 A schematic diagram of a verification processing device is provided, applied to a gateway device, where multiple gateway devices correspond to multiple devices. For example... Figure 3 As shown, the verification processing device 300 includes:

[0083] The acquisition module 301 is used to acquire the verification data provided by the access party; wherein, the verification data includes the access party ID;

[0084] The detection and verification module 302 is used to detect whether the access party has passed the verification based on the verification data.

[0085] The signature module 303 is used to find the corresponding proxy ID based on the access party ID if the access party verification is successful, send the corresponding Token encryption key to the proxy ID, and sign the sent Token encryption key using the RSA private key; wherein, the RSA private key is a private key based on the RSA encryption algorithm;

[0086] The monitoring request module 304 is used to monitor requests to verify the Token encryption key. If a verification request is sent, the signature is verified using the RSA public key; where the RSA public key is a public key based on the RSA encryption algorithm.

[0087] The data receiving module 305 is used to receive the Token encryption key if the signature verification is successful; extract the Token using the received Token encryption key and verify the Token; if the Token verification is successful, receive the response result data corresponding to the Token encryption key.

[0088] The verification processing device provided in this application embodiment has the same technical features as the verification processing method provided in the above embodiment, so it can also solve the same technical problems and achieve the same technical effects.

[0089] An electronic device provided in this application embodiment, such as Figure 4 As shown, the electronic device 400 includes a processor 402 and a memory 401. The memory stores a computer program that can run on the processor. When the processor executes the computer program, it implements the steps of the method provided in the above embodiments.

[0090] See Figure 4 The electronic device also includes a bus 403 and a communication interface 404. The processor 402, the communication interface 404 and the memory 401 are connected via the bus 403. The processor 402 is used to execute executable modules, such as computer programs, stored in the memory 401.

[0091] The memory 401 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 404 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network.

[0092] Bus 403 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0093] The memory 401 is used to store programs. After receiving an execution instruction, the processor 402 executes the program. The method executed by the apparatus defined by the process disclosed in any of the preceding embodiments of this application can be applied to the processor 402 or implemented by the processor 402.

[0094] Processor 402 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 402 or by instructions in software form. The processor 402 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 401, and processor 402 reads the information from memory 401 and, in conjunction with its hardware, completes the steps of the above method.

[0095] Corresponding to the above-described protection and control method for asynchronous motors, this application embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to perform the steps of the above-described verification processing method.

[0096] The verification processing device provided in this application embodiment can be specific hardware on a device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in this application embodiment are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0097] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0098] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, 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 marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive 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 a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0101] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the asynchronous motor protection and control method described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0103] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A verification processing method, characterized in that, Applied to gateway devices, with multiple gateway devices corresponding to multiple devices, the method is used for verifying and processing medical institution data, and the method includes: Obtain verification data provided by the access party; wherein, the verification data includes the access party ID; The system checks whether the access party has passed verification based on the verification data; if the access party fails verification, the system returns the verification failure information in reverse order of the original path and re-checks the verification data. If the access party is verified, the corresponding proxy ID is found based on the access party ID, and the corresponding Token encryption key is sent to the proxy ID. The sent Token encryption key is then signed using an RSA private key. The system monitors requests to verify the Token encryption key. If such a verification request is sent, the system verifies the signature using the RSA public key. If the signature verification fails, the system does not accept the Token encryption key. If the signature verification passes, the device receives the Token encryption key in response; the received Token encryption key is used to extract the Token, and the Token is verified. If the Token verification passes, the device receives the response result data corresponding to the Token encryption key; if the Token verification passes, the device forwards the verification data and displays the verification process on the graphical user interface; wherein the response result data is generated based on the Token encryption key and the structured prescription data. The step of finding the corresponding proxy ID based on the access party ID and sending the corresponding Token encryption key to the proxy ID if the access party verification is successful, and signing the sent Token encryption key using the RSA private key, further includes: If the access party is verified, the corresponding configuration ID is found based on the access party ID, and the corresponding proxy ID is found based on the configuration ID, and the corresponding token encryption key is sent to the proxy ID; If the token verification fails, the verification failure information is returned in reverse order of the original path, and the verification failure response result data is received.

2. The verification processing method according to claim 1, characterized in that, The verification data also includes any one or more of the following: Hospital name, resource name, accessible range, callback address.

3. A verification processing device, characterized in that, Applied to gateway devices, with multiple gateway devices corresponding to multiple devices, the devices are used for verification processing of medical institution data, and the devices include: The acquisition module is used to acquire verification data provided by the access party; wherein, the verification data includes the access party ID; The detection and verification module is used to detect whether the access party has passed the verification based on the verification data; it is also used to: if the access party fails the verification, return the verification failure information in reverse order of the original path, and re-detect the verification data; The signature module is used to find the corresponding proxy ID based on the access party ID if the access party verification is successful, send the corresponding Token encryption key to the proxy ID, and sign the sent Token encryption key using an RSA private key. The monitoring request module is used to monitor requests to verify the Token encryption key; if the verification request is sent, the signature is verified using the RSA public key; it is also used to: if the signature verification fails, the Token encryption key is not received. The data receiving module is configured to: if the signature verification passes, receive the Token encryption key from the device; extract the Token using the received Token encryption key and verify the Token; if the Token verification passes, receive the response result data corresponding to the Token encryption key; and further configured to: if the Token verification passes, forward the verification data and display the verification process on a graphical user interface; wherein the response result data is generated based on the Token encryption key and structured prescription data. The signature module is further configured to: if the access party passes the verification, find the corresponding configuration ID based on the access party ID, find the corresponding proxy ID based on the configuration ID, and send the corresponding Token encryption key to the proxy ID; If the token verification fails, the verification failure information is returned in reverse order of the original path, and the verification failure response result data is received.

4. An electronic device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 2.

Images