A service-oriented implementation and management method for the IoT-based sharing of financial devices.

Abstract

The present invention discloses a service-oriented implementation and management method for the shared use of the Internet of Things of financial devices. Based on the service-oriented financial devices, the present invention utilizes the customized service registration, release and management mechanism in the field of financial devices, and combines service queue sharing, time-sharing exclusive locking, chip-level data tamper-proof transmission, lightweight local intelligent operation and maintenance and other technologies to provide a safe, reliable, convenient and efficient method for the shared use of the Internet of Things of financial devices, laying the foundation for cost reduction and efficiency improvement in the financial field.

Description

Technical Field

[0001] This invention relates to the field of financial services, and in particular to a service-oriented implementation and management method for the IoT-based sharing and use of financial equipment. Background Art

[0002] Financial equipment is primarily used in bank branches, but these branches themselves currently face significant challenges. Specifically, these challenges include: 1. Reduced business irreplaceability: Online services are largely replacing traditional branch services, with customers increasingly opting for online banking and WeChat banking for personal financial transactions; 2. Increased challenges from online finance: The prevalence of online payments and financial services, coupled with tightened regulations on personal bank card issuance and other intermediary transactions, has led to a sharp decline in customer visits and transaction volume; 3. Reduced stable, high-quality revenue: Downgrading consumption, the repatriation of US dollars, and deflation have resulted in a decrease in stable revenue streams such as mortgages and commercial loans; 4. High operating costs: Inconsistent business practices across multiple channels necessitate the use of different personnel, hindering cost reduction efforts; and high expenses such as rent and personnel remain.

[0003] Faced with declining business volume, reduced revenue, and persistently high operating costs at bank branches, current countermeasures include, but are not limited to, increasing on-site services, building smaller but fully functional branches, increasing self-service capabilities, and streamlining teller staff. This necessitates highly integrated and lightweight business processing terminals to facilitate external expansion and effectively reduce the space occupied by financial equipment within branches. Therefore, large financial equipment such as card issuers, random card issuers, and high-speed printers require IoT and sharing capabilities. This necessitates the service-oriented and shared provision of these large modules and their drivers to offer shared capabilities and services to various lightweight business processing terminals, reducing branch placement and procurement costs. Simultaneously, less frequent and time-consuming media delivery processes are separated and moved to a shared delivery area, streamlining previously sequential business processing into parallel modules. This ensures that common business transactions without media delivery can be processed faster and more smoothly, truly achieving cost reduction while simultaneously improving the business experience and efficiency. Summary of the Invention

[0004] To address the technical problems of low utilization rate and high operating costs of current branch equipment, this invention provides a service-oriented implementation and management method for the IoT-based sharing of financial equipment.

[0005] To achieve the above-mentioned technical objectives, the technical solution of the present invention is as follows:

[0006] A service-oriented implementation and management method for the IoT-based sharing of financial devices includes the following steps:

[0007] Step 1: Establish a shared service network including a business application layer, a service manager layer, and a device service layer, and connect the financial equipment sharing device, customer operation device, service manager, and remote teller center to the shared service network; Step 2: The financial equipment sharing device initiates financial equipment service registration with the service manager;

[0008] Step 3: After receiving all the financial device service registrations, the service manager establishes relationships and publishes a service list including all financial device services to the financial business application via an interface.

[0009] Step 4: Financial business applications use encrypted chips to make secure cross-end calls. Financial business applications trigger calls to financial devices according to the needs of business processes. After the call messages of financial devices are encrypted and verified, they are sent to the service manager via network requests.

[0010] Step 5: The service manager uses the encryption chip to complete the verification and decryption, and routes the service to the specific service address and object based on the service name in the decrypted message, and forwards the corresponding interface call to the specific device service to achieve routing.

[0011] Step six: The interface requests of financial business applications are communicated and tasked at the device service layer to convert the interface requests of business applications into specific hardware actions to be executed by the financial equipment sharing device.

[0012] Step 7: The financial device service returns the result of the interface execution to the service manager, which then returns the reverse route to the business application.

[0013] The method described herein, step two includes:

[0014] Step 1: The service manager's registry center and reverse proxy center service ports are opened for listening, waiting to receive requests from various callers;

[0015] Step 2: Import the whitelist of services and financial devices into the registration center;

[0016] Step 3: The financial device service on the financial device sharing device starts after a delay after power-on, and reads the pre-configured service manager's IP and port during startup;

[0017] Step 4: The financial equipment service initiates a status query to the financial equipment sharing device; the financial equipment service will assign a value to the status field of the financial equipment service according to the actual status of the financial equipment sharing device.

[0018] Step 5: The financial device service initiates a service registration request to the registration center and assigns the status information obtained in Step 4 to the metadata field of the registration interface;

[0019] Step 6: After receiving the service registration request, the registration center retrieves the metadata field from the request information and matches it with the whitelist imported in Step 2. If a match is found, the process proceeds to Step 7; otherwise, a registration failure message is returned and the registration process ends.

[0020] Step 7: The registration center responds to the financial device service with a successful registration and stores the IP address, port, and hardware capability information of the financial device that the service calls.

[0021] Step 8: The registration center synchronizes the relevant information of the financial device service stored in Step 7 to the reverse proxy center through the shared configuration file;

[0022] Step 9: The reverse proxy center will establish a reverse proxy linked list with the service name as the key and the service IP and the hardware capability information of the financial device calling the service as the value. Steps 1-9 will be repeated for each service registration until all services are registered and a complete reverse proxy linked list of the financial device sharing device is established.

[0023] The method described herein, step three includes:

[0024] Step 10: The financial business application dynamically discovers the service manager by polling the candidate service manager port.

[0025] Step 11: After successfully connecting to the service manager, the financial business application obtains all services and information under the service manager through the service publishing interface;

[0026] Step 12: The financial business application sorts out and summarizes the remote service capabilities and local service capabilities, and, in combination with the differences in the necessary financial equipment for different business scenarios, blocks business scenarios in advance where the necessary equipment is incomplete or in an abnormal state.

[0027] Step 13: When a customer clicks a business button in the financial business application, a shared financial device call is triggered; the financial business application translates the call into a message request to the remote service manager.

[0028] Step 14: After receiving the message request, the remote service manager parses the requested service name, routes the request to the specific service address according to the service name, and sends the request to the financial device service corresponding to the service name.

[0029] Step 15: After receiving the interface request, the financial equipment service parses the parameters, converts the request into calls to multiple corresponding hardware instructions, and then combines the returns of these hardware instructions to organize the return parameters of the interface request and return the return parameters to the remote service manager.

[0030] Step 16: The remote service manager routes the return of the device service to the specified service name and returns it in the form of service name + interface; thus completing the service publication.

[0031] The method described, after executing steps two and three, also includes an execution flow that takes into account version compatibility and concurrent calls from multiple applications:

[0032] Step 1) After the financial equipment service starts, it constructs different service interfaces and service event implementation objects based on the hardware capability information and version list of the financial equipment called by the service itself.

[0033] Step 2) After completing the service registration and publishing process, the financial business application will create a list of the capabilities, versions, and statuses of all published services under the service manager after startup.

[0034] Step 3) The financial business application will determine the service interface to be called and its version based on the service list's capability support and the actual service capability required for this business.

[0035] Step 4) Call the version setting interface to transmit the list of version requirements for the application's calling interfaces and events to the device service through the service version setting interface; after receiving the version setting command, the device service establishes an association list of the application ID and the required interface and event versions so that subsequent interface calls can be indexed to the correct version object; thus completing the version negotiation; Step 5) The financial business application sends a function request message to the financial device service through the service manager;

[0036] Step 6) The financial device service first determines the request type. If it is a query request, the device service will directly return the capability and status information stored in memory. At the same time, the financial device service will enable the idle time status update and the status update mechanism after the action is completed to ensure that the memory status is updated in a timely manner.

[0037] Step 7) For execution requests, the financial device service first checks whether the service has been locked and exclusively used by any application. If it is locked, the financial device service obtains the application ID of the currently locked service to determine whether the ID of the application initiating the new request matches the current locked ID and whether the new request is associated with the current execution interface. If so, the new request is added to the emergency execution waiting queue; otherwise, the financial device service adds the new request to the normal execution waiting queue.

[0038] Step 8) The financial equipment service creates a task execution thread specifically to handle requests in the execution waiting queue; after the current command is completed and the lock is released, the urgent execution waiting queue will be processed first. Only after the tasks in the urgent execution waiting queue are completed will the contents of the normal execution waiting queue be executed.

[0039] Step 9) Execute the task obtained from the task queue. If it is necessary to lock the current service, the service will be locked first. If the current service is not locked during the execution process, it is assumed that the current service and the device support concurrent responses to the current command and other commands.

[0040] Step 10) When executing the current command, the device service will assess which atomic capabilities of financial devices are required to execute the current command based on the current status of the atomic capabilities of the financial devices. The device service will then decide to combine one or more hardware instructions of the financial devices based on the assessment results and combine the execution results of the multiple hardware instructions.

[0041] Step 11) Based on the hardware instruction results, combine them into an interface return message, release the lock on the device and service, and put the output results into the service manager;

[0042] Step 12) The service manager maps the service's return to the interface call return of the service name; and forwards the output back to the calling application in Step 5).

[0043] The method described herein, step four includes:

[0044] Step ①: Before the financial business application and the national cryptographic chip are actually put into use, they both generate their own initial SM2 public and private key pairs. Both need to exchange their SM2 public keys and authentication information with the unified authentication center used for user identity authentication and authorization. After the exchange is completed, the encryption platform of the front-end application will store the unified authentication center's SM2 public key - i.e., the authentication center's public key, and store the unified authentication center's SM2 private key, i.e., the authentication center's private key's signature value against the front-end application's public key. The national cryptographic chip of the financial equipment sharing device will store the authentication center's public key and the authentication center's private key's signature value against the financial equipment sharing device's national cryptographic chip public key. At the same time, it will also store a unified authentication center's private key's signature value against the national cryptographic chip ID, which will be used for subsequent whitelist authentication.

[0045] Step 2: The financial business application imports the national cryptographic chip ID whitelist as the basis for subsequent determination of the legality of the national cryptographic chip; Step 3: The financial business application sends a request instruction to the device service to obtain the encryption chip ID.

[0046] Step 4: The device service obtains the national cryptographic chip ID of the financial device sharing device and the signature value of the national cryptographic chip ID by the authentication center's private key, and returns it to the financial business application.

[0047] Step 5: The financial business application uses the public key of the certification center to verify the signature obtained in step 4. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial device are considered illegitimate, and the encrypted transmission ends directly. Step 6: The financial business application matches the national cryptographic chip ID obtained in step 4 with the whitelist in step 2. If the match is successful, proceed to the next step; if the match fails, the encrypted transmission ends directly.

[0048] Step 7: The financial business application sends a request instruction to the device service to obtain the public key of the national cryptographic chip;

[0049] Step 8: After obtaining the chip public key and the certification center private key from the national cryptographic chip and signing the public key, the device service returns it to the financial business application.

[0050] Step 9: The financial business application uses the private key of the certification center to verify the signature value in step 8. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial equipment are considered illegitimate, and the encrypted transmission ends directly.

[0051] Step 10: The financial business application stores the public key of the national cryptographic chip and sends its own public key and the certification center's private key to sign the public key to the device service.

[0052] step The device service uses the public key of the certification center stored in the national cryptographic chip to verify the signature in step 10. If the verification is successful, the public key of the financial business application is saved and the process proceeds to the next step; otherwise, the financial business application is considered illegitimate and the encrypted transmission ends directly.

[0053] step The device service uses a national cryptographic chip to generate a 16-byte random number, encrypts the random number using the public key of the financial business application, and returns the encrypted result to the financial business application.

[0054] step The financial business application decrypts and saves the random number; at the same time, it generates a 16-byte master key, which is used in the following steps. The master key is symmetrically encrypted using a random number, and the encryption result is then signed using the business application's private key. The decryption result and the signature value are then transmitted to the device service together.

[0055] step The device service utilizes the public key for business applications stored in the national cryptographic chip to perform the steps. The signature value is verified. If the verification passes, the following steps are performed. The random number is decrypted to obtain the plaintext of the master key, which is then saved and the financial business application is notified that the master key transmission was successful. Otherwise, the financial business application is considered illegitimate and the encrypted transmission ends directly.

[0056] step After receiving the notification of successful master key transmission, the financial business application generates a 16-byte national cryptographic working key for HMAC calculation.

[0057] step Steps for using financial business applications Steps to generate master key pair The working key is used to encrypt the encryption result, and the private key of the financial business application is used to sign the encryption result. The generated encryption result and the signature value are then transmitted to the device service.

[0058] step The device service utilizes the public key for business applications stored in the national cryptographic chip to perform the steps. The signature value is verified. If the verification passes, the following steps are performed. The master key is used to decrypt the working key in plaintext, which is then saved. Otherwise, the financial business application is considered illegitimate, and the encrypted transmission ends directly.

[0059] step Repeat steps To the steps The financial business application generates another 16-byte national cryptographic working key and transmits it to the device service. This key can be used for encryption of subsequent data transmissions.

[0060] step Financial business applications respond to customer business needs by using message-based methods to invoke functions on financial devices. The request messages are organized according to actual business needs, and the application ID and a unique request ID for each request are added to the interface message, along with the overall message body length. For the strings containing these message fields, the following steps are used... The working key is used to perform SM3 HMAC calculation, and the HMAC value is used as the last field of the message body;

[0061] step Financial business applications will involve steps The generated message body, using steps The generated working key is encrypted with SM4 before transmission, and the encryption result is transmitted to the device service.

[0062] step The equipment service utilizes national cryptographic chips and procedures The generated working key is used to decrypt the SM4 transmission message to obtain the message text, and the HMAC field value is obtained from the received message text;

[0063] step The device service will send a message containing all information except the HMAC field, and will utilize the steps stored in the national cryptographic chip. The working cipher is used to perform HAMC calculations using the SM3 algorithm;

[0064] step , the steps With steps The HAMC value in the data is compared. If the comparison is successful, the next step is performed. If the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly.

[0065] step Device service requests to applications are broken down into multiple hardware instructions, which are then combined and invoked; the invocation results are then combined into an output message.

[0066] step The device service adds steps to the output message. The same application ID and request ID, plus the overall message body length; for the strings containing the above message fields, use the steps... The working key is used to perform SM3 HMAC calculation, and the HMAC value is used as the last field of the message body;

[0067] step The equipment service will take steps The message, using steps The generated and transmitted working key is encrypted with SM4 before transmission, and the encrypted result is transmitted to the financial business application.

[0068] step Financial business applications decrypt the transmitted ciphertext to obtain the message text, and retrieve the HMAC field value from the received message text;

[0069] step Financial business applications will send the message containing all data except the HMAC field, and then use the steps stored in the national cryptographic chip. The working cipher is used to perform HAMC calculations using the SM3 algorithm;

[0070] step Financial business applications will involve steps With steps The HAMC value in the data is compared. If the comparison is successful, the next step is performed. If the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly.

[0071] step Financial applications retrieve information from the returned message to retrieve data from the device and conduct transactions; subsequent device calls will repeat these steps. To the steps .

[0072] The method also includes service monitoring and operation and maintenance processes based on lightweight tools:

[0073] Step a: After the device service manager starts up, in addition to starting the registry center and reverse proxy center, it will also start the operation and maintenance agent for monitoring and maintaining financial devices. The operation and maintenance agent contains the device service status display and operation and maintenance server page, and provides query and execution capabilities to external browsers through the HTTP message interface.

[0074] Step b: When the financial equipment service starts, a pre-stored code table containing hardware error codes, error descriptions, and fault handling suggestions for the corresponding financial equipment model is loaded synchronously for subsequent analysis and troubleshooting.

[0075] Step c: When the financial device service starts, it will send a message to the financial device to obtain the financial device's capabilities and status information. When obtaining the financial device status information, in addition to the common device status and media status, it will also obtain the error code of the hardware's most recent hardware instruction execution failure.

[0076] Step d: After obtaining all the necessary capabilities and status information for registration, the financial device initiates registration with the service management. After the device service performs whitelist matching, it will establish a mapping association between the service name and the service object and the service IP.

[0077] Step e: The device service manager periodically obtains the financial device status, media status, and most recent error code from the financial device service. Only when the financial device status is abnormal will the most recent hardware error code be updated to the operation and maintenance agent. As long as the financial device status is detected to be normal, the most recent hardware error code in the operation and maintenance agent will be set to "000000000", the error description will be "no error", and the handling suggestion will be empty.

[0078] Step f: The branch maintenance personnel enter the IP address and port of the service manager through the browser built into the operating system, and enter the counter account and password.

[0079] Step g: The service manager accesses the bank's intranet authorization center using the account and password obtained in step f to verify the password and obtain account permissions. Ordinary accounts will only have viewing and monitoring permissions and will load the financial device status monitoring page. Operation and maintenance administrators will be granted viewing, monitoring, and remote operation and maintenance permissions.

[0080] In step h, after the branch operation and maintenance manager discovers an abnormal status of a financial device, it will receive further processing suggestions from step e.

[0081] Step i: Based on the handling suggestions, the branch operations and maintenance administrator provides detailed operational guidance for actions that require branch intervention; and remotely controls financial equipment that needs to be remotely reset or restarted.

[0082] Step j: If the measures in step i fail to restore the financial equipment to normal status, the operations and maintenance agent will suggest that the branch operations and maintenance administrator restart the service or the entire machine in order to restore normal use; the service manager will convert such restart requests into system-level commands for the corresponding system platform.

[0083] If steps i and j fail to resolve the issue, the operations agent will automatically provide the device manufacturer's contact information or allow you to contact the manufacturer directly.

[0084] Step 1: The maintenance agent tracks the progress of the equipment manufacturer's reported repairs, providing a WYSIWYG end-to-end maintenance monitoring process until the fault is completely eliminated and the equipment is in normal working order.

[0085] The technical advantages of this invention lie in its provision of a secure, reliable, convenient, and efficient method for sharing and invoking financial equipment via the Internet of Things (IoT). This method leverages customized service registration, publishing, and management mechanisms within the financial equipment domain, combined with technologies such as service queue sharing, time-sharing exclusive locking, chip-level data tamper-proof transmission, and lightweight local intelligent operation and maintenance. This lays the foundation for cost reduction and efficiency improvement in the financial sector. Compared to general financial equipment invocation solutions, the positive effects and features of this solution are as follows:

[0086] This solution provides a complete cross-platform implementation method for financial device services: it offers a complete set of methods for concurrent service calls and responses, providing a complete deployment scheme example and service implementation process for financial device service sharing, laying the foundation for the productization and deployment of financial device IoT sharing. It achieves financial device service-oriented architecture through a cross-platform system architecture, combining the differentiated characteristics of each platform to achieve code-level cross-platform compatibility. For example, on Android systems, this solution leverages Android's permission restrictions, delegating service and hardware port access to Android's built-in APIs. The service itself focuses on combining and converting service capabilities. Overall, this solution achieves cross-platform compatibility across three mainstream business systems: Windows, Linux, and Android, with a code reuse rate exceeding 75%.

[0087] It provides an efficient and lightweight method for service management and invocation: Based on the financial equipment domain, the capabilities and status of financial equipment and services themselves, a set of efficient service registration and publishing and device whitelist management methods are summarized. Based on the mapping and management capabilities of the service manager, a unified gateway-style device invocation scheme is provided to applications, which greatly simplifies the application invocation process. At the same time, based on the service version negotiation and capability negotiation mechanism, a complete production implementation solution is provided for multi-application and multi-version backward compatibility, improving the robustness of the overall architecture.

[0088] A national cryptographic chip-level end-to-end secure communication solution is provided: based on the key storage and encryption computing capabilities of the national cryptographic chip, combined with bidirectional transmission encryption and national cryptographic HMAC, a chip-level implementation solution for cross-end calls of financial devices is realized, which greatly enhances the security level of cross-end IoT sharing and calls, and provides a practical and feasible transmission encryption and data verification solution for the actual implementation of IoT sharing and cross-end calls.

[0089] This solution provides a lightweight, cross-platform operation and maintenance management method for financial equipment services. It focuses on building and strengthening the capabilities of the equipment service and service manager, enabling both to possess specific operation and maintenance management capabilities. This allows for the integration of these capabilities into the implementation of lightweight operation and maintenance tools, enabling the intelligent operation and maintenance functions to be completed. Subsequent service maintenance requires no additional deployment or setup from maintenance personnel; they can simply use a common system browser to achieve real-time monitoring and maintenance of financial equipment and services. Attached Figure Description

[0090] Figure 1 This is a schematic diagram of the network deployment based on the Internet of Things for device services;

[0091] Figure 2 Diagram of device service call architecture and functional components;

[0092] Figure 3 Flowchart of steps for service registration and publishing;

[0093] Figure 4 Detailed flowchart for sharing and calling device services;

[0094] Figure 5 Flowchart for cross-platform secure call;

[0095] Figure 6 A diagram of a local, lightweight monitoring tool based on device services. DETAILED DESCRIPTION

[0096] To reduce costs and increase efficiency in traditional branches, this embodiment utilizes financial equipment (hardware functional modules in financial business auxiliary terminals) that occupy a large area, have high purchase costs, and relatively low usage frequency but involve physical delivery in a service-oriented and shared manner, such as... Figure 1 As shown, future IoT-enabled service points will combine highly integrated portable kiosks with IoT sharing modules. The portable kiosks will serve as flexible, mobile business transaction terminals, while large modules and IoT sharing boxes will form a shared IoT settlement area, providing physical settlement functionality for each portable kiosk to share at different times. Most transactions that do not require physical delivery will be completed using the portable kiosks. For transactions requiring physical delivery, after the customer enters information and authenticates their identity on the portable kiosk, the application and service manager on the portable kiosk will cross-platform call the large module in the shared settlement area via wired or wireless means to complete the issuance of physical media, information reading, and account association. At this point, the customer's transaction on the portable kiosk is complete, and the customer can then move to the physical delivery area to immediately receive their media (bank card, UKey, valuables bag, etc.) by swiping their ID or scanning a code.

[0097] To achieve service-oriented and shared access to financial equipment and its drivers, a service-oriented approach based on a unified message protocol or a hardware firmware approach can be used, combined with Bluetooth, wireless networks, and wired networks to achieve hardware-level sharing and IoT calls. Using service messages as the standard, rather than interface standards, truly achieves cross-platform architecture. Decoupling applications from financial equipment and its drivers via messages enhances the stability of the front-end business system. Based on a cross-platform technology stack of Python / C++ / C, combined with hybrid development and integration architectures such as Chaquopy, core service code can be effectively implemented across Windows, Linux, and Android systems, improving code reusability and reducing development costs. Simultaneously, a unified input and output queue, along with highly integrated interfaces, service locking, and interface association mechanisms, fully realizes the time-sharing and shared use of financial equipment based on device service-oriented architecture.

[0098] To ensure the secure and reliable remote sharing and access of financial devices and their drivers across different terminals, data transmission requires encryption and verification. This solution employs bidirectional transmission encryption based on national cryptographic chips. Hardware-level national cryptographic encryption is performed after both communicating parties are authenticated, ensuring the legitimacy of both parties and the encryption of the data transmission content. Furthermore, to further enhance the tamper-proof protection of sensitive data, national cryptographic chips and the HMAC algorithm are used to achieve chip-level verification and tamper-proofing of sensitive data.

[0099] Based on the service-oriented architecture of financial equipment and its drivers, a unified registration, publishing, management, and operation and maintenance system for these financial equipment services is required. This solution utilizes a created service manager and a unified service registration and publishing mechanism, reducing service call complexity and improving call standardization. By standardizing service registration actions, this solution ensures that service registration messages include module model information, manufacturer information, and version information. The service manager then uses this hardware-related information to perform access control and information statistics for financial equipment and its services. Simultaneously, this solution leverages the capabilities of device services and service management itself to customize and backend-based the operation and maintenance interface of the service manager. Ultimately, this allows for deployment without relying on additional testing tools, enabling users to directly view service status and brief information in a local browser, thus achieving further lightweight control over financial equipment services.

[0100] This addresses three main aspects that need to be achieved in the process of service-oriented architecture for financial devices and their drivers: device driver service-oriented development and design, secure and reliable cross-platform call design, and service registration, publication, and management. Figure 2 As shown, the software implementation framework of this solution may include a business application layer, a middleware conversion service layer, a service manager layer, and a device service layer. The middleware conversion service layer primarily handles the secondary combination of device service interfaces. In common lightweight architectures, the functionality of this layer is often merged into the device service layer. Therefore, this layer is optional in the architecture layering. A brief introduction to each layer follows:

[0101] Business Application Layer: This is the front-end customer service system of a bank, typically adopting a B / S (Browser / Server) model. Upon startup, it directly redirects to the back-end server of the business system to run the actual business code. When it needs to access peripherals, it will call the peripherals via network message requests to obtain peripheral information, etc. This layer is mandatory.

[0102] Middleware platform service layer: This layer primarily implements secondary orchestration and combination of service interfaces, and performs conversion and adaptation of application messages. This layer is optional.

[0103] Service Manager Layer: This layer is responsible for registering, publishing, managing, and supporting device services. Its main functions include, but are not limited to, responding to device service registrations, managing device information, managing whitelists, publishing service lists, and implementing service reverse proxying and routing. This layer is mandatory.

[0104] Device Service Layer: This layer shares the functions of financial devices as services with various bank front-end customer service systems. Internally, this layer can be further divided into a network protocol adaptation layer, a routing layer, a task processing layer, and a device driver layer. It handles tasks including, but not limited to, message sending and receiving, protocol adaptation, event response, task routing, event and result routing, serial task processing, parallel task processing, timeout and cancellation mechanisms, device status, and device capability combinations. This layer is the actual layer that enables service sharing among financial devices and is essential.

[0105] Since the middleware conversion service layer is usually removed in the final lightweight architecture, the following implementation steps will omit the description of this layer. In a lightweight device service shared architecture consisting only of a business application layer, a service manager layer, and a device service layer, after the service manager, financial device service, and financial business application are started sequentially, device calls generally go through the following main steps:

[0106] Step 1: Service registration, which means that the financial device service initiates registration with the service manager.

[0107] Step 2: Service publishing. After receiving all service registrations, the service management system establishes relationships and publishes the service list to financial business applications via an interface.

[0108] Step 3: Interface call, which means that the financial business application calls the services and their interfaces in the service list based on the obtained service and service capability list and the business process requirements. This interface call will first reach the service manager layer.

[0109] Step 4: Service routing, which means that the service manager routes the service to the specific service address and object based on the service name, and forwards the corresponding interface call to the specific device service object.

[0110] Step 5: Function Execution. This involves the business application system's interface requests being processed by the device service layer, including message parsing, parameter parsing, task generation and queuing, and device command combination. This translates the business application's interface requests into specific hardware actions executed by the financial equipment.

[0111] Step 6: Result Return. The result of the API execution will be returned from the device service to the service manager, which will then route the result back to the business application. At this point, a complete business API call is complete.

[0112] In the above interface call implementation process, service registration and verification, service publication, service reverse proxy, and routing are all handled by the service manager. Furthermore, service registration and publication are prerequisites for subsequent service calls; therefore, the implementation process of service registration and publication will be described in detail below. For the complete implementation process of financial equipment service registration and publication, please refer to [link to relevant documentation]. Figure 3 To clearly explain the registration, publishing, and reverse proxy functions of the service manager, its internal implementation divides service management into a registration center and a reverse proxy center. These two centers each have relatively independent processes and resources, synchronizing information through shared configuration files. The complete implementation steps for registering and publishing financial device services are described below:

[0113] Step 1: The service manager starts automatically on system boot, and its registry center and reverse proxy center service ports are opened for listening, waiting to receive requests from various callers.

[0114] Step 2: In the Service Manager registry, import the whitelist of services and financial devices. The matching rules for this whitelist are usually based on the device manufacturer model, device ID, or even device serial number.

[0115] Step 3: The financial equipment service starts after a delay after power-on. During startup, it reads the IP address and port of the branch service manager configured during the previous installation.

[0116] Step 4: The financial device service initiates a query on the device's capabilities and status. This query includes, but is not limited to, the financial device's capability attributes (such as whether it supports magnetic stripe reading, ID card reading, etc.), the current availability status of the financial device, the device manufacturer and model, the device ID, the device firmware version, and the device serial number. If the financial device is currently unavailable, it also needs to return the most recently occurring hardware error code, the reason for the error, and error handling suggestions.

[0117] Step 5: The financial device service initiates a service registration request to the service manager registry center. This request needs to include information such as device capabilities, status, model, and device ID obtained in Step 4. This additional information will be assigned to the metadata storage field of the registration interface.

[0118] Step 6: After receiving the service registration request, the service manager registry center retrieves the metadata fields from the request information and matches the device model, device ID, device serial number, etc., with the whitelist imported in Step 2. If a match is found, the process proceeds to Step 7. If a match fails, the service registration in Step 5 will fail directly, and a registration failure message will be returned to the service via HTTP or other means. The failed service will not be further published, connected, or invoked. At this point, the registration and publication process for that device service ends.

[0119] Step 7: The registration center responds to the device service in Step 5 with a successful registration message and stores information such as service name, service IP port, and service capabilities.

[0120] Step 8: The registry center synchronizes the device-related information stored in Step 7 to the reverse proxy center through the shared configuration file.

[0121] Step 9: The reverse proxy center will establish a reverse proxy linked list with the service name as the key and the service IP and capability information as the values. Each service registration will repeat steps 1-9 until all services are registered, establishing a complete reverse proxy linked list for the branch's shared financial equipment. For services within the portable all-in-one machine, the service registration process also repeats steps 1-9, the difference being that the service manager will no longer be the shared service manager, but a local service manager deployed on the same portable all-in-one machine, with a fixed IP of 127.0.0.1. The primary purpose of service registration and publishing on the same machine is for decoupling the front-end architecture, ensuring independent and clear management of devices and drivers, and not for shared use. Therefore, the service publishing, shared calls, and secure cross-platform communication discussed below are all based on... Figure 1 This applies to remote service managers and financial devices and services that need to be shared.

[0122] Step 10: Financial business applications dynamically discover service managers by polling the candidate service manager ports (12 candidate service manager ports).

[0123] Step 11: After successfully connecting to the remote shared service manager, the application can obtain all services, capabilities, and status information under the manager at once through the service publishing interface.

[0124] Step 12: The application sorts out and summarizes the remote service capabilities and local service capabilities, and combines the differences in the necessary financial equipment for different business scenarios to preemptively block business scenarios where the necessary equipment is incomplete or the necessary equipment is in an abnormal state.

[0125] Step 13: The customer clicks a business button in the financial business application, triggering a shared financial device call (such as out-of-order card issuance or foreign currency disbursement). The financial business system translates this call into a message request to the remote service manager.

[0126] Step 14: After receiving the message request, the remote service manager parses the requested service name, routes the request to the specific service address based on the service name, and sends the request to the financial device service object corresponding to the service name.

[0127] Step 15: After receiving the interface request, the financial equipment service parses the parameters, converts the request into a series of hardware instruction calls, combines the returns of the multiple instructions, organizes the return parameters of the interface request, and returns the return parameters to the remote service manager.

[0128] Step 16: The remote service manager routes the device service response to the specified service name and returns it in the format of service name + interface.

[0129] Step 17: The one-time device service registration, publishing, and simplified call process is now complete.

[0130] With the device service registration and publishing already completed, specific device service calls still need to consider issues such as compatibility with diverse front-end system versions, compatibility with diverse device service versions, and service response to concurrent calls from multiple applications. Therefore, in the specific device service call process, mechanisms such as version negotiation and service locking are introduced to adapt to scenarios such as multi-version compatibility and concurrent calls from multiple applications. The complete device service call process implementation steps are as follows:

[0131] Step 1: Start the financial equipment service and build different service interfaces and service event implementation objects based on its capability list and version list.

[0132] Step 2: After completing the service registration and publishing process, the financial business application will create a list of the capabilities, versions, and statuses of all published services under the service manager after startup.

[0133] Step 3: The financial business application will determine the service interface to be called and its version based on the service list's capability support and the actual service capability required for this business.

[0134] Step 4: Invoke the version setting interface to transmit the list of version requirements for the application's API calls and events to the device service via the service version setting interface. After receiving the version setting command, the device service establishes an association list of the application ID and the required API and event versions, making it easy for subsequent API calls to index the correct version object. Version negotiation is now complete.

[0135] Step 5: The financial business application sends a function request message to the financial device service through the service manager.

[0136] Step 6: The financial device service first determines the request type. If it is a query interface, the device service will directly return the capability and status information stored in memory. Simultaneously, the financial device service will enable idle-time status updates and action completion status updates to ensure that the memory status is updated in a timely manner.

[0137] Step 7: For execution-type interfaces, the financial device service checks whether the current service is locked and exclusively used by any application. If it is locked, the service obtains the application ID of the currently locked service. For newly received requests, it determines whether the ID of the application initiating the new request matches the current locked ID and whether the new request is associated with the current execution interface. If so, the new request is added to the emergency execution waiting queue. Otherwise, the device service adds the request to the normal execution waiting queue.

[0138] Step 8: The device service development task execution thread is dedicated to handling requests in the execution waiting queue. After the current command is completed and the lock is released, the urgent execution waiting queue will be processed first. Only after the tasks in the urgent execution waiting queue are completed will the contents of the normal execution waiting queue be executed.

[0139] Step 9: Execute the task retrieved from the task queue. If the current service needs to be locked, it will be locked first. If the current service is not locked during execution, it is assumed that the current service and device support concurrent responses to the current command and other commands (e.g., encryption and decryption can be performed simultaneously while waiting for password input).

[0140] Step 10: When executing the current command, the device service will, as needed, combine and call one or more hardware instructions from the financial device, and combine the execution results of the multiple hardware instructions.

[0141] Step 11: Based on the hardware instruction results, combine them into an interface return message, release the lock on the device and service, and put the output results into the service manager.

[0142] Step 12: The service manager converts the service's return mapping into an interface call return with the service name. The output is then forwarded back to the calling application from Step 5 (the correct correspondence between the client's send and receive will be determined by combining the application ID and the URL requested by the client).

[0143] The process of sharing and calling device services, that is, the communication between the application and the remote service manager, may be based on external IoT. The security and reliability of its remote access require further encryption and verification protection. For example... Figure 5As shown, this solution implements chip-level HMAC based on a national cryptographic chip. Simultaneously, mTLS encryption during transmission will also be based on the national cryptographic chip for encryption and key storage. Combining the SM4, SM3, and SM2 algorithms of the national cryptographic chip, it fully realizes key generation, encrypted transmission, multi-layer key storage, and salted hash verification. Since bidirectional transmission encryption based on national cryptographic standards is a mature encryption technology during network encrypted transmission, this solution will focus on describing the entire process of tamper-proofing and attack prevention of secure transmitted data through customized HAMC calculations based on national cryptographic standards. In most cases, the national cryptographic chip in this solution is the encryption chip integrated into each financial device. However, for existing devices already online, the financial devices managed within the IoT shared control box (hereinafter referred to as the IoT shared box) can also share the national cryptographic chip in the IoT shared control box to complete relevant encryption calculations. The detailed implementation steps of the cross-terminal secure call process are described below:

[0144] Step 1: Before actual use, both the front-end application and the national cryptographic chip generate their own initial SM2 public-private key pairs and need to exchange SM2 public keys and authentication information with the unified authentication center. After the exchange is completed, the encryption platform of the front-end application will store the SM2 public key of the authentication center (i.e., the authentication center's public key) and the SM2 private key of the authentication center (i.e., the authentication center's private key) with the signature value of the front-end application's public key. The national cryptographic chip of the IoT sharing box will store the authentication center's public key and the authentication center's private key with the signature value of the IoT sharing box's national cryptographic chip public key, and will also store a signature value of the national cryptographic chip ID with the authentication center's private key for subsequent whitelist authentication.

[0145] Step 2: The financial business application imports the national cryptographic chip ID whitelist as the basis for subsequent determination of the legality of the national cryptographic chip; Step 3: The financial business application sends a request instruction to the device service to obtain the encryption chip ID.

[0146] Step 4: The device service obtains the national cryptographic chip ID and the signature value of the authentication center's private key against the national cryptographic chip ID, and returns it to the application;

[0147] Step 5: The financial business application uses the public key of the certification center to verify the signature obtained in Step 4. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial equipment are considered illegitimate, and the encrypted transmission ends directly.

[0148] Step 6: The financial business application matches the national cryptographic chip ID obtained in Step 4 with the whitelist in Step 2. If the match is successful, proceed to the next step; if the match fails, the encrypted transmission ends directly.

[0149] Step 7: The financial business application sends a request instruction to the device service to obtain the public key of the national cryptographic chip;

[0150] Step 8: After obtaining the chip public key and the authentication center private key from the national cryptographic chip and signing the public key, the device service returns it to the financial business application.

[0151] Step 9: The financial business application uses the private key of the certification center to verify the signature value in Step 8. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial equipment are considered illegitimate, and the encrypted transmission ends directly.

[0152] Step 10: The financial business application saves the public key of the national cryptographic chip and sends its own public key and the authentication center's private key to sign the public key to the device service.

[0153] Step 11: The device service uses the national cryptographic chip to verify the signature from Step 10. If the verification is successful, the public key of the financial business application is saved and the process proceeds to the next step; otherwise, the financial business application is considered illegitimate, and the encrypted transmission ends directly. Step 12: The device service uses the national cryptographic chip to generate a 16-byte random number, encrypts this random number using the public key of the financial business application, and returns the encrypted result to the financial business application.

[0154] Step 13: The financial business application decrypts and saves the random number; at the same time, a 16-byte master key is generated, and the master key is symmetrically encrypted using the random number from step 12. The encryption result is then signed using the business application's private key, and the decryption result and the signature value are transmitted together to the device service.

[0155] Step 14: The device service uses the public key of the business application stored in the national cryptographic chip to verify the signature value in step 13. If the verification is successful, the random number in step 12 is used to decrypt the signature and obtain the plaintext of the master key for storage. Otherwise, the financial business application is considered illegitimate and the encrypted transmission ends directly.

[0156] Step 15: After receiving the master key transmission successfully, the financial business application generates a 16-byte national cryptographic working key for HMAC calculation.

[0157] Step 16: The financial business application uses the master key generated in step 13 to encrypt the working key in step 15, signs the encryption result using the private key of the financial business application, and transmits the generated encryption result and the signature value together to the device service.

[0158] Step 17: The device service uses the public key of the business application stored in the national cryptographic chip to verify the signature value of Step 16. If the verification is successful, the master key of Step 14 is used to decrypt the signature and obtain the plaintext of the working key for storage. Otherwise, the financial business application is considered illegal and the encrypted transmission ends directly.

[0159] Step 18: Repeat steps 15 to 17. The financial business application generates another 16-byte national cryptographic working key and transmits it to the device service. This key can be used for encryption of subsequent data transmissions.

[0160] Step 19: The financial business application responds to the customer's business needs by using message method to make function calls to the financial device. It organizes the request message according to the actual business needs, and adds the application ID and the unique request ID for each request to the interface message, and adds the length of the overall message body. For the strings of the above message field contents, the working key in step 15 is used to calculate the HMAC of SM3, and the HMAC value is used as the last field of the message body.

[0161] Step 20: The financial business application encrypts the message body formed in step 19 using the working key generated in step 18 before transmission, and transmits the encryption result to the device service.

[0162] Step 21: The device service uses the national cryptographic chip and the working key generated in step 18 to decrypt the transmitted message and obtain the message text. The HMAC field value is then obtained from the received message text.

[0163] Step 22: The device service will send the message text excluding the HMAC field and use the working password from step 15 stored in the national cryptographic chip to perform HAMC calculation of the SM3 algorithm.

[0164] Step 23: Compare the HAMC values ​​from Step 22 with those from Step 21. If the comparison is successful, proceed to the next step. If the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly.

[0165] Step 24: The device service application request is broken down into multiple hardware instructions, which are then combined and called; the call results are combined into an output message.

[0166] Step 25: The device service adds the same application ID and request ID as in step 19 to the output message, and adds the length of the overall message body; for the strings of the above message field contents, the working key in step 15 is used to calculate the HMAC of SM3, and the HMAC value is used as the last field of the message body.

[0167] Step 26: The device service encrypts the message from step 25 before transmission and transmits the encryption result to the financial business application.

[0168] Step 27: The financial business application decrypts the transmitted ciphertext to obtain the message text, and retrieves the HMAC field value from the received message text;

[0169] Step 28: The financial business application will send the message text excluding the HMAC field and use the working cipher stored in the national cryptographic chip from step 15 to perform HAMC calculation of the SM3 algorithm.

[0170] Step 29: The financial business application compares the HAMC value from Step 27 with that from Step 28. If the comparison is successful, proceed to the next step; if the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly.

[0171] Step 30: The financial business application obtains the information read by the device from the returned message and performs the business transaction; subsequent device calls will repeat steps 19 to 30.

[0172] In the aforementioned secure encrypted transmission process, HAMC calculation slightly increases transmission latency. Therefore, for large amounts of data and non-sensitive data, bidirectional transmission encryption using national cryptographic standards can be directly used, and the application and device service parties can agree to omit HAMC verification for this non-sensitive data. Furthermore, for devices with IoT capabilities, the service can be implemented within the device's firmware; therefore, HMAC verification for such devices can be completed within the device itself, further enhancing the security level.

[0173] Based on shared IoT calls for device services, timely viewing, monitoring, and troubleshooting of financial devices are required. Considering that remote service managers are primarily deployed at the branch-level (i.e., one service manager per branch), this solution designs a lightweight service management and monitoring tool based on the service manager. Please refer to the following for a general implementation process. Figure 6 The specific monitoring and maintenance process based on this lightweight tool is as follows:

[0174] Step 1: After the device service manager starts up, in addition to starting the registry center and reverse proxy center, it will also start the operation and maintenance agent for monitoring and maintaining financial devices. This agent contains the server-side page for displaying device service status and operation and maintenance, and provides query and execution capabilities to external browsers through HTTP message interface.

[0175] Step 2: When the financial equipment service starts, a code table (summarized and provided by the financial equipment manufacturer) containing hardware error codes, error descriptions, and troubleshooting suggestions for the corresponding financial equipment model is loaded synchronously for subsequent analysis and troubleshooting.

[0176] Step 3: When the financial device service starts, it sends a message to the financial device to obtain its capabilities and status information. In addition to common device and media status information, it also retrieves the error code from the most recent hardware instruction execution failure.

[0177] Step 4: After obtaining all the necessary capabilities and status information for registration, the financial device initiates registration with the service management. After the device service performs whitelist matching, it will establish a mapping association between the service name, the service object, and the service IP.

[0178] Step 5: The Device Service Manager will periodically (the time interval is configurable) obtain the status of the financial device, the media status, and the most recent error code from the Financial Device Service. Only when the financial device status is abnormal will the most recent hardware error code be updated to the Operation and Maintenance Agent. As long as the financial device status is detected to be normal, the most recent hardware error code in the Operation and Maintenance Agent will be set to "000000000", the error description will be "no error", and the handling suggestion will be empty.

[0179] Step 6: Branch maintenance personnel can access the single sign-on interface by entering the IP address and port of the service manager through the built-in browser of Windows, Linux, Android, and other systems, and then enter their counter account and password.

[0180] Step 7: The Service Manager accesses the bank's intranet authorization center using the account and password obtained in Step 6 to verify credentials and acquire account permissions. Regular accounts will only have viewing and monitoring permissions, loading the financial device status monitoring page. Operations administrators will be granted viewing, monitoring, and remote operations and maintenance permissions.

[0181] Step 8: After the branch operation and maintenance manager discovers an abnormal status of a financial device, it will receive further processing suggestions from the feedback in Step 5.

[0182] Step 9: Based on the handling suggestions, the branch operations and maintenance administrator provides detailed operational guidance for actions that require branch intervention. This includes remotely controlling financial equipment that needs remote reset or restart.

[0183] Step 10: If the measures in Step 9 fail to restore the financial equipment to normal status, the Operations Agent will recommend that the branch operations administrator restart the service or the entire running machine in order to restore normal operation. The Service Manager will translate such restart requests into system-level commands for the corresponding system platform.

[0184] Step 11: If steps 9 and 10 fail to resolve the issue, the maintenance agent will automatically provide the device manufacturer's customer service phone number, customer service WeChat account, or send a maintenance request email directly to the manufacturer.

[0185] Step 12: The maintenance agent can also further track the progress of the equipment manufacturer's reported problems, achieving full-process maintenance monitoring with what you see and what you get, until the fault is completely eliminated and the equipment is in normal condition.

Claims

1. A service-oriented implementation and management method for the IoT-based sharing of financial equipment, characterized in that, The following steps are involved: Step 1: Establish a shared service network comprising a business application layer, a service manager layer, and a device service layer, and connect the financial equipment sharing device, customer operation device, service manager, and remote teller center to the shared service network; Step 2: The financial device sharing device initiates financial device service registration with the service manager; Step 3: After receiving all the financial device service registrations, the service manager establishes relationships and publishes a service list including all financial device services to the financial business application via an interface. Step 4: Financial business applications use encrypted chips to make secure cross-end calls. Financial business applications trigger calls to financial devices according to the needs of business processes. After the call messages of financial devices are encrypted and verified, they are sent to the service manager via network requests. Step 5: The service manager uses the encryption chip to complete the verification and decryption, and routes the service to the specific service address and object based on the service name in the decrypted message, and forwards the corresponding interface call to the specific device service to achieve routing. Step six: The interface requests of financial business applications are communicated and tasked at the device service layer to convert the interface requests of business applications into specific hardware actions to be executed by the financial equipment sharing device. Step 7: The financial device service returns the result of the interface execution to the service manager, and the service manager returns the reverse route to the business application; Step two includes: Step 1: The service manager's registry center and reverse proxy center service ports are opened for listening, waiting to receive requests from various callers; Step 2: Import the whitelist of services and financial devices into the registration center; Step 3: The financial device service on the financial device sharing device starts after a delay after power-on, and reads the pre-configured service manager's IP and port during startup; Step 4: The financial equipment service initiates a status query to the financial equipment sharing device; the financial equipment service will assign a value to the status field of the financial equipment service according to the actual status of the financial equipment sharing device. Step 5: The financial device service initiates a service registration request to the registration center and assigns the status information obtained in Step 4 to the metadata field of the registration interface; Step 6: After receiving the service registration request, the registration center retrieves the metadata field from the request information and matches it with the whitelist imported in Step 2. If a match is found, the process proceeds to Step 7; otherwise, a registration failure message is returned and the registration process ends. Step 7: The registration center responds to the financial device service with a successful registration and stores the IP address, port, and hardware capability information of the financial device that the service calls. Step 8: The registration center synchronizes the relevant information of the financial device service stored in Step 7 to the reverse proxy center through the shared configuration file; Step 9: The reverse proxy center will establish a reverse proxy linked list with the service name as the key and the service IP and the hardware capability information of the financial device calling the service as the value. Steps 1-9 will be repeated for each service registration until all services are registered and a complete reverse proxy linked list of the financial device sharing device is established.

2. The method according to claim 1, characterized in that, Step three includes: Step 10: The financial business application dynamically discovers the service manager by polling the candidate service manager port. Step 11: After successfully connecting to the service manager, the financial business application obtains all services and information under the service manager through the service publishing interface; Step 12: The financial business application sorts out and summarizes the remote service capabilities and local service capabilities, and, in combination with the differences in the necessary financial equipment for different business scenarios, blocks business scenarios in advance where the necessary equipment is incomplete or in an abnormal state. Step 13: When a customer clicks a business button in the financial business application, a shared financial device call is triggered; the financial business application translates the call into a message request to the remote service manager. Step 14: After receiving the message request, the remote service manager parses the requested service name, routes the request to the specific service address according to the service name, and sends the request to the financial device service corresponding to the service name. Step 15: After receiving the interface request, the financial equipment service parses the parameters, converts the request into calls to multiple corresponding hardware instructions, and then combines the returns of these hardware instructions to organize the return parameters of the interface request and return the return parameters to the remote service manager. Step 16: The remote service manager routes the return of the device service to the specified service name and returns it in the form of service name + interface; thus completing the service publication.

3. The method according to claim 2, characterized in that, After executing steps two and three, the execution flow also includes considerations for version compatibility and concurrent calls from multiple applications: Step 1) After the financial equipment service starts, it constructs different service interfaces and service event implementation objects based on the hardware capability information and version list of the financial equipment called by the service itself. Step 2) After completing the service registration and publishing process, the financial business application will create a list of the capabilities, versions, and statuses of all published services under the service manager after startup. Step 3) The financial business application will determine the service interface to be called and its version based on the service list's capability support and the actual service capability required for this business. Step 4) Call the version setting interface to transmit the list of version requirements for the application's call interfaces and events to the device service through the service version setting interface; after receiving the version setting command, the device service will establish an association list of the application ID and the required interface and event versions so that subsequent interface calls can be indexed to the correct version object; thus completing the version negotiation. Step 5) The financial business application sends a function request message to the financial device service through the service manager; Step 6) The financial device service first determines the request type. If it is a query request, the device service will directly return the capability and status information stored in memory. At the same time, the financial device service will enable the idle time status update and the status update mechanism after the action is completed to ensure that the memory status is updated in a timely manner. Step 7) For execution requests, the financial device service first checks whether the service has been locked and exclusively used by any application. If it is locked, the financial device service obtains the application ID of the currently locked service to determine whether the ID of the application initiating the new request matches the current locked ID and whether the new request is associated with the current execution interface. If so, the new request is added to the emergency execution waiting queue; otherwise, the financial device service adds the new request to the normal execution waiting queue. Step 8) The financial equipment service creates a task execution thread specifically to handle requests in the execution waiting queue; Once the current command has finished executing and the lock has been released, the urgent execution waiting queue will be processed first. Only after the tasks in the urgent execution waiting queue have been completed will the contents of the normal execution waiting queue be executed. Step 9) Execute the task obtained from the task queue. If it is necessary to lock the current service, the service will be locked first. If the current service is not locked during the execution process, it is assumed that the current service and the device support concurrent responses to the current command and other commands. Step 10) When executing the current command, the device service will assess which combinations of atomic capabilities of financial devices are required to execute the current command based on the current status of the atomic capabilities of the financial devices. The device service will decide to combine and call one or more hardware instructions of the financial devices based on the assessment results, and combine the execution results of multiple hardware instructions. Step 11) Based on the hardware instruction results, combine them into an interface return message, release the lock on the device and service, and put the output results into the service manager; Step 12) The service manager maps the service's return to the interface call return of the service name; Forward the output content back to the calling application in step 5).

4. The method according to claim 2, characterized in that, Step four includes: Step ①: Before the financial business application and the national cryptographic chip are actually put into use, they both generate their own initial SM2 public and private key pairs. Both need to exchange their SM2 public key and authentication information with the unified authentication center used for user authentication and authorization. After the exchange is completed, the encryption platform of the front-end application will store the unified authentication center's SM2 public key (i.e., the authentication center's public key) and the unified authentication center's SM2 private key (i.e., the authentication center's private key) with the front-end application's public key. The national cryptographic chip of the financial equipment sharing device will store the authentication center's public key and the authentication center's private key with the financial equipment sharing device's national cryptographic chip public key. At the same time, it will also store a unified authentication center's private key with the national cryptographic chip ID for subsequent whitelist authentication. Step 2: Import the national cryptographic chip ID whitelist into financial business applications, which will serve as the basis for subsequent determination of the legality of national cryptographic chips; Step 3: The financial business application sends a request instruction to the device service to obtain the encryption chip ID; Step 4: The device service obtains the national cryptographic chip ID of the financial device sharing device and the signature value of the national cryptographic chip ID by the authentication center's private key, and returns it to the financial business application. Step 5: The financial business application uses the public key of the certification center to verify the signature obtained in step 4. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial equipment are considered illegitimate, and the encrypted transmission ends directly. Step 6: The financial business application matches the national cryptographic chip ID obtained in step 4 with the whitelist in step 2. If the match is successful, proceed to the next step; if the match fails, the encrypted transmission ends directly. Step 7: The financial business application sends a request instruction to the device service to obtain the public key of the national cryptographic chip; Step 8: After obtaining the chip public key and the certification center private key from the national cryptographic chip and signing the public key, the device service returns it to the financial business application. Step 9: The financial business application uses the private key of the certification center to verify the signature value in step 8. If the verification is successful, proceed to the next step; otherwise, the national cryptographic chip and financial equipment are considered illegitimate, and the encrypted transmission ends directly. Step 10: The financial business application stores the public key of the national cryptographic chip and sends its own public key and the certification center's private key to sign the public key to the device service. step The device service uses the public key of the certification center stored in the national cryptographic chip to verify the signature in step 10. If the verification is successful, the public key of the financial business application is saved and the process proceeds to the next step; otherwise, the financial business application is considered illegitimate and the encrypted transmission ends directly. step The device service uses a national cryptographic chip to generate a 16-byte random number, encrypts the random number using the public key of the financial business application, and returns the encrypted result to the financial business application. step The financial business application decrypts and saves the random number; at the same time, it generates a 16-byte master key, which is used in the following steps. The master key is symmetrically encrypted using a random number, and the encryption result is then signed using the business application's private key. The decryption result and the signature value are then transmitted to the device service together. step The device service utilizes the public key for business applications stored in the national cryptographic chip to perform the steps. The signature value is verified. If the verification passes, the following steps are performed. The random number is decrypted to obtain the plaintext of the master key, which is then saved and the financial business application is notified that the master key transmission was successful. Otherwise, the financial business application is considered illegitimate and the encrypted transmission ends directly. The steps are as follows: After receiving the notification of successful master key transmission, the financial business application generates a 16-byte national cryptographic working key for HMAC calculation. step Steps for using financial business applications Steps to generate master key pair The working key is used to encrypt the encryption result, and the private key of the financial business application is used to sign the encryption result. The generated encryption result and the signature value are then transmitted to the device service. step The device service utilizes the public key for business applications stored in the national cryptographic chip to perform the steps. The signature value is verified. If the verification passes, the following steps are performed. The master key is used to decrypt the working key in plaintext, which is then saved. Otherwise, the financial business application is considered illegitimate, and the encrypted transmission ends directly. step Repeat steps To the steps The financial business application generates another 16-byte national cryptographic working key and transmits it to the device service. This key can be used for encryption of subsequent data transmission. step Financial business applications respond to customer business needs by using message-based methods to invoke functions on financial devices. The request messages are organized according to actual business needs, and the application ID and a unique request ID for each request are added to the interface message, along with the overall message body length. For the strings containing these message fields, the following steps are used... The working key is used to perform SM3 HMAC calculation, and the HMAC value is used as the last field of the message body; step Financial business applications will involve steps The generated message body, using steps The generated working key is encrypted with SM4 before transmission, and the encryption result is transmitted to the device service. step The equipment service utilizes national cryptographic chips and procedures The generated working key is used to decrypt the SM4 transmission message to obtain the message text, and the HMAC field value is obtained from the received message text; step The device service will send a message containing all information except the HMAC field, and will utilize the steps stored in the national cryptographic chip. The working cipher is used to perform HAMC calculations using the SM3 algorithm; step , the steps With steps The HAMC value in the data is compared. If the comparison is successful, the next step is performed. If the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly. step Device service requests to applications are broken down into multiple hardware instructions, which are then combined and invoked; the invocation results are then combined into an output message. step The device service adds steps to the output message. The same application ID and request ID are used, and the length of the entire message body is added; for the strings of the above message field contents, the working key in step ⑮ is used to calculate the HMAC of SM3, and the HMAC value is used as the last field of the message body; step The equipment service will take steps The message, using steps The generated and transmitted working key is encrypted with SM4 before transmission, and the encrypted result is transmitted to the financial business application. step Financial business applications decrypt the transmitted ciphertext to obtain the message text, and retrieve the HMAC field value from the received message text; step Financial business applications will send the message containing all data except the HMAC field, and then use the steps stored in the national cryptographic chip. The working cipher is used to perform HAMC calculations using the SM3 algorithm; step Financial business applications will involve steps With steps The HAMC value in the data is compared. If the comparison is successful, the next step is performed. If the comparison fails, it is determined that the transmitted data has been tampered with, and the encrypted transmission ends directly. step Financial applications retrieve information from the returned message to retrieve data from the device and conduct transactions; subsequent device calls will repeat these steps. To the steps .

5. The method according to claim 2, characterized in that, It also includes service monitoring and operation and maintenance processes based on lightweight tools: Step a: After the device service manager starts up, in addition to starting the registry center and reverse proxy center, it will also start the operation and maintenance agent for monitoring and maintaining financial devices. The operation and maintenance agent contains the device service status display and operation and maintenance server page, and provides query and execution capabilities to external browsers through the HTTP message interface. Step b: When the financial equipment service starts, a pre-stored code table containing hardware error codes, error descriptions, and fault handling suggestions for the corresponding financial equipment model is loaded synchronously for subsequent analysis and troubleshooting. Step c: When the financial device service starts, it will send a message to the financial device to obtain the financial device's capabilities and status information. When obtaining the financial device status information, in addition to the common device status and media status, it will also obtain the error code of the hardware's most recent hardware instruction execution failure. Step d: After obtaining all the necessary capabilities and status information for registration, the financial device initiates registration with the service management. After the device service performs whitelist matching, it will establish a mapping association between the service name and the service object and the service IP. Step e: The device service manager periodically obtains the financial device status, media status, and most recent error code from the financial device service. Only when the financial device status is abnormal will the most recent hardware error code be updated to the operation and maintenance agent. As long as the financial device status is detected to be normal, the most recent hardware error code in the operation and maintenance agent will be set to "000000000", the error description will be "no error", and the handling suggestion will be empty. Step f: The branch maintenance personnel enter the IP address and port of the service manager through the browser built into the operating system, and enter the counter account and password. Step g: The service manager accesses the bank's intranet authorization center using the account and password obtained in step f to verify the password and obtain account permissions. Ordinary accounts will only have viewing and monitoring permissions and will load the financial device status monitoring page. Operation and maintenance administrators will be granted viewing, monitoring, and remote operation and maintenance permissions. In step h, after the branch operation and maintenance manager discovers an abnormal status of a financial device, it will receive further processing suggestions from step e. Step i: Based on the handling suggestions, the branch operations and maintenance administrator provides detailed operational guidance for actions that require branch intervention; and remotely controls financial equipment that needs to be remotely reset or restarted. Step j: If the measures in step i fail to restore the financial equipment to normal status, the operations and maintenance agent will suggest that the branch operations and maintenance administrator restart the service or the entire machine in order to restore normal use; the service manager will convert such restart requests into system-level commands for the corresponding system platform. If steps i and j fail to resolve the issue, the operations agent will automatically provide the device manufacturer's contact information or allow you to contact the manufacturer directly. Step 1: The maintenance agent tracks the progress of the equipment manufacturer's reported repairs, providing a WYSIWYG end-to-end maintenance monitoring process until the fault is completely eliminated and the equipment is in normal working order.

Images