Goods transaction management system, goods transaction management method and program

Abstract

It provides improved technology in the automotive transaction process, which spans multiple systems. [Solution] Equipped with a processor, it acquires basic information on automobile transactions (including vehicle identification information and transaction party information), manages settlement information, and tracks the status. Based on the basic information, it identifies the necessary procedures and generates integrated data including common data items. Using the integrated data, it executes procedures such as ownership transfer, vehicle registration, and insurance contracts according to the settlement status, and centrally manages all progress. In particular, it features condition-dependent processing control that links settlement status and procedure progress, and an integrated data structure that is observable from the outside. The status of each step is provided through an interface that can be observed and verified from the outside.

Description

Technical Field

[0001] The present invention relates to automobile sales transactions, and particularly to a technology for integrally managing multiple procedures from the conclusion of an automobile purchase contract to the completion of ownership transfer.

Background Art

[0002] Patent Document 1 discloses a sales support system that can easily convey product information to purchasers who wish to purchase products. In Patent Document 1, there is disclosed a sales support system comprising a seller terminal operated by a seller who sells products, and a purchaser terminal operated by a purchaser who wishes to purchase products, the sales support system comprising: first input receiving means for receiving input of identification information capable of specifying product attributes at the seller terminal; attribute specifying means for specifying product attributes based on the received input identification information; and first display means for displaying attribute information related to the product attributes specified by the attribute specifying means at the purchaser terminal.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of Invention

Problems to be Solved by the Invention

[0004] However, in the process of automobile transactions that span multiple systems, there is a demand for a technology that links the payment status and the progress of various procedures, maintains data consistency, and further advances processing more efficiently, and there is still room for consideration of technical improvements in automobile (article) sales support systems.

Means for Solving the Problems

[0005] According to one aspect of the present disclosure, an automobile transaction integrated management system comprises at least one processor, the processor configured to perform the following steps by reading a program: a transaction information acquisition step, which acquires basic information relating to an automobile transaction, the basic information including at least identification information of the automobile being traded and identification information of the parties to the transaction; a settlement management step, which manages settlement information relating to the transaction and tracks the settlement status, the settlement information and settlement status being displayed through an externally observable interface; a procedure identification step, which identifies a plurality of procedures necessary for the automobile transaction based on the basic information; and an integrated data generation step, which generates data that is commonly required for the plurality of procedures. A comprehensive automobile transaction management system is provided, which identifies data items, generates integrated data including input values ​​for the data items, the integrated data is observable from the outside through communication with an external system, in a procedure processing step, performs processing related to a plurality of procedures using the integrated data according to the settlement status, the processing related to the plurality of procedures includes at least two or more of ownership transfer procedures, vehicle registration procedures, and insurance contract procedures, the status and progress of the processing are displayed through an externally observable interface, and in a progress management step, centrally manages the settlement status and the progress of the plurality of procedures, the progress is provided through an externally observable progress management interface.

[0006] According to another aspect of this disclosure, a comprehensive automobile transaction management method is provided, wherein a computer acquires basic information relating to an automobile transaction in a transaction information acquisition step, the basic information includes at least identification information of the automobile subject to the transaction and identification information of the parties to the transaction; manages settlement information relating to the transaction and tracks the settlement status in a settlement management step; identifies a plurality of procedures necessary for the automobile transaction based on the basic information in a procedure identification step; identifies data items that are commonly required for the plurality of procedures in an integrated data generation step and generates integrated data including input values ​​for the data items; executes processing relating to the plurality of procedures using the integrated data according to the settlement status in a procedure processing step, the processing relating to the plurality of procedures includes at least two or more of ownership transfer procedures, vehicle registration procedures, and insurance contract procedures; and centrally manages the settlement status and the progress of the plurality of procedures in a progress management step.

[0007] This configuration provides an improved technology that enables real-time processing in the automobile transaction process while maintaining data consistency across multiple systems, and linking settlement status with the progress of the procedure. [Effects of the Invention]

[0008] The effects include eliminating the following issues, and this is merely one example, not an exhaustive list.

[0009] The process of purchasing a car begins with selecting a vehicle and signing a sales contract, and involves several procedures, including payment and confirmation of receipt of funds, transfer of ownership, vehicle registration, changes to car insurance policies, and payment of automobile tax and acquisition tax. These procedures are carried out with different organizations, such as dealerships, government agencies, financial institutions, and insurance companies, and each requires its own unique documents and procedures. In recent years, while the digitalization of various procedures has progressed, in many cases these procedures are carried out individually, requiring users to enter the same information multiple times. Furthermore, managing the progress of each procedure and the required documents must be done individually, which places a burden on users.

[0010] In particular, in automobile transactions, after the conclusion of a sales contract, settlement (payment of the price and confirmation of receipt of funds) and various procedures (transfer of ownership, change of registration, change of insurance contract, etc.) must be carried out in the correct order, but coordination between these processes is often insufficient. For example, there are cases where the transfer of ownership procedure proceeds without confirmation of receipt of funds, or where there is a discrepancy in the timing between the transfer of ownership and the change of insurance contract, resulting in a gap in insurance coverage. Furthermore, ensuring data consistency across different systems is technically challenging, leading to technical issues such as errors and procedural delays due to information inconsistencies. Additionally, sufficient technical means were not available to automatically determine and control the dependencies and optimal execution order of each procedure. [Brief explanation of the drawing]

[0011] [Figure 1] This figure shows the overall configuration of an automobile transaction management system according to one embodiment of the present disclosure. [Figure 2] This is a block diagram showing the hardware configuration of an automobile transaction management system according to one embodiment of the present disclosure. [Figure 3] This is a block diagram showing the functional configuration of an automobile transaction management system according to one embodiment of the present disclosure. [Figure 4] This figure shows an example of the configuration of an integrated database for an automobile transaction management system according to one embodiment of this disclosure. [Figure 5] This flowchart shows the overall flow of an automobile transaction management method according to one embodiment of this disclosure. [Figure 6] This flowchart shows the details of the integrated data generation process according to one embodiment of this disclosure. [Figure 7]This is a sequence diagram showing the linkage between settlement status and procedural processing according to one embodiment of the present disclosure. [Figure 8] This figure shows an example of a progress management screen according to one embodiment of this disclosure. [Figure 9] This figure shows an external system integration architecture according to one embodiment of the present disclosure. [Figure 10] This figure shows an example of an application of the automobile transaction management system according to another embodiment of the present disclosure. [Modes for carrying out the invention]

[0012] The embodiments of this disclosure will be described in detail below with reference to the drawings. The embodiments described below are examples for implementing this disclosure and do not limit the technical scope of this disclosure. Those skilled in the art can make various modifications and improvements within the scope of the technical concept of this disclosure. The automobile transaction management system provided in this disclosure is a computer-implemented technical solution. This system provides a concrete technical means for efficiently processing automobile transaction processes across multiple systems, particularly by linking settlement status with the progress of various procedures, while maintaining data consistency. This represents a concrete technical improvement rather than merely an abstract idea, and naturally, the various features shown in the embodiments below can be combined with each other.

[0013] The core technical solutions of this disclosure are as follows: Firstly, a "distributed transaction management mechanism" that enables consistent data processing across multiple independent systems, which has an externally observable communication protocol and data structure. Secondly, an "integrated data structure" that centrally manages information used in common across multiple procedures, which is identifiable through an interface with an external system. Thirdly, a "mechanism for linking settlement status and procedure progress," which provides a function to advance various procedures at the appropriate timing according to the settlement completion status.

[0014] These technical elements function in cooperation with each other to solve technical problems in automobile transactions. The technical effects of the present disclosure can be observed in that, compared with the case where conventional individual systems are simply connected, the man-hours for data input are reduced, procedural errors are reduced, and the time until transaction completion is shortened. Furthermore, by linking the payment status and the progress of procedures, the effect of significantly reducing troubles and risks can also be obtained. These effects are attributed to the technical characteristics of the integrated data structure, the distributed transaction management mechanism, and the payment-procedure linkage control mechanism, and solve the conventional problems in the relevant technical field.

[0015] <Definition of Terms> The main terms used in this specification are defined as follows.

[0016] "Automobile transaction" means a series of transaction acts related to the sale and purchase of automobiles, and includes not only the conclusion of a sales contract but also related legal and commercial acts such as settlement (payment of price and confirmation of receipt of payment), transfer of ownership, vehicle registration, insurance contracts, loan and lease contracts, etc., and refers to being part of a juristic act.

[0017] "Settlement" means the process of price payment and receipt confirmation in automobile transactions, and includes methods such as cash transactions, bank transfers, payments under loan and lease contracts. Settlement information can be confirmed through an externally observable interface, and the settlement status (unpaid, paid, receipt confirmed, etc.) directly affects the progress of the transaction.

[0018] "Integrated data" means a data structure that uniformly manages information commonly used in a plurality of different procedures. Specifically, it includes basic items such as vehicle information, transaction party information, and transaction condition information, as well as a relational structure defining their associations, and has externally observable data elements and interface elements with external systems. The integrated data is not limited to a specific implementation technology (database type, data format, etc.), and refers to its functional aspect.

[0019] "Procedure" refers to the steps of legal, commercial, or administrative processing carried out in connection with an automobile transaction. This includes information processing steps such as data entry, verification, transformation, transmission, reception, and storage, as well as interface processing steps such as displaying information to the user and facilitating input, and these steps are performed in a manner that is observable from the outside.

[0020] "External systems" refer to computer systems that exist outside of this system and perform processing related to automobile transactions, including administrative agency systems, financial institution systems, insurance company systems, etc., and can be observed from the outside through communication interfaces with them.

[0021] An "API (Application Programming Interface)" refers to a programmatic interface for exchanging data between this system and an external system. It includes communication protocols, data formats, authentication methods, etc., and functions as a communication pattern that can be observed from the outside.

[0022] In database operations, a "transaction" refers to a function that treats multiple processes as a single unit, and only confirms the result if all processes are successful. In this system, it includes an extended transaction concept to ensure consistency across distributed systems and functions as an externally observable unit of processing.

[0023] A "workflow" refers to a defined sequence of operations in an automobile transaction, embodied as an externally observable processing sequence. In particular, conditional workflows, which include dependencies between settlement status and procedural progress, play a crucial role in this system.

[0024] "Condition-dependent processing" refers to a processing method that proceeds to the next step only when specific conditions (e.g., "payment completed," "document submission completed") are met. In this system, it is particularly used to link the payment status with the progress of the procedure.

[0025] <System Configuration> Referring to Figure 1, the overall configuration of the automobile transaction management system 100 according to this embodiment is shown. The system 100 includes a central processing server 110, an integrated database 120, a user interface unit 130, and an external linkage unit 140. The system 100 is connected to external systems such as user terminals 160, government agency systems 170, financial institution systems 180, and insurance company systems 190 via a network 150 such as the Internet.

[0026] Figure 2 is a block diagram showing the hardware configuration of the automobile transaction management system 100 according to this embodiment. The system 100 includes a processor 210, memory 220, storage 230, communication interface 240, and input / output interface 250. The processor 210 realizes the processing according to this disclosure by executing a program stored in the memory 220.

[0027] Storage 230 is a non-volatile storage device for long-term storage of programs and data. Communication interface 240 is hardware for communicating with external systems via network 150. Input / output interface 250 provides connections to input / output devices such as keyboards, mice, and displays.

[0028] Figure 3 is a block diagram showing the functional configuration of the automobile transaction management system 100 according to this embodiment. The system 100 includes a transaction information acquisition unit 310, a settlement management unit 315, a procedure identification unit 320, an integrated data generation unit 330, a procedure processing unit 340, a progress management unit 350, an external system linkage unit 360, a security management unit 370, a user authentication unit 380, and a notification management unit 390. These functional units are functional modules realized by the processor 210 executing programs stored in the memory 220.

[0029] Figure 4 shows an example of the configuration of the integrated database 120 according to this embodiment. The integrated database 120 includes a transaction basic information table 410, a vehicle information table 420, a customer information table 430, a settlement information table 435, a procedure information table 440, a document template table 450, and a progress status table 460.

[0030] <System Operation> Figure 5 is a flowchart showing the overall flow of the automobile transaction management method according to this embodiment. This method includes a transaction information acquisition step (S510), a settlement management step (S515), a procedure identification step (S520), an integrated data generation step (S530), a procedure processing step (S540), and a progress management step (S550).

[0031] In the transaction information acquisition step (S510), the transaction information acquisition unit 310 acquires basic information related to the automobile transaction. The basic information includes identification information of the automobile being traded (chassis number, make, model, year of manufacture, mileage, etc.) and identification information of the parties to the transaction (seller's and buyer's names, addresses, contact information, etc.). The transaction information is entered from the user terminal 160 via the user interface unit 130 or acquired from an external system.

[0032] In the settlement management step (S515), the settlement management unit 315 manages settlement information related to the transaction (settlement method, amount, payment due date, etc.) and tracks the settlement status (unpaid, paid, received, etc.). The settlement management unit 315 can automatically confirm receipt of funds through API integration with bank systems and payment services. In the case of cash transactions, it also provides a function for manual input of received confirmation.

[0033] The settlement management unit 315 displays the current settlement status through an externally observable interface and notifies the relevant parties (seller, buyer, dealer, vehicle dealership, intermediary, etc.). A particularly important function is the control of procedural processing according to the settlement status, such as automatically suspending the ownership transfer procedure until the receipt of funds is confirmed.

[0034] In the procedure identification step (S520), the procedure identification unit 320 identifies several procedures necessary for the automobile transaction based on the acquired basic information. The procedures identified include the creation of a sales contract, ownership transfer procedures, vehicle registration procedures, insurance contract procedures (voluntary insurance and compulsory automobile liability insurance), loan / lease contract procedures, and tax-related procedures (automobile acquisition tax, etc.).

[0035] The procedure identification unit 320 dynamically identifies the necessary procedures based on the type of transaction (new car purchase, used car purchase, private sale, etc.), the condition of the vehicle (whether or not it has a vehicle inspection certificate), the timing of the transaction (timing within the fiscal year, etc.), and local legal regulations. The procedure identification unit 320 also considers the payment status of automobile tax and the expiration date of the vehicle inspection certificate to determine the specific types of taxes and procedures required at the time of ownership transfer.

[0036] Furthermore, the procedure identification unit 320 analyzes the dependencies between each procedure and determines the optimal execution order. For example, it sets dependencies such as setting settlement completion as a prerequisite for ownership transfer, and ownership transfer completion as a prerequisite for vehicle registration. This dependency information is used in subsequent procedure processing steps.

[0037] In the integrated data generation step (S530), the integrated data generation unit 330 identifies data items that are commonly required for multiple identified procedures and generates integrated data that includes input values ​​for these data items. The data items include vehicle information (chassis number, vehicle type, model, etc.), party information (name, address, contact information, etc.), transaction information (sales price, transaction date, etc.), and settlement information (settlement method, payment status, etc.).

[0038] The integrated data generation unit 330 collects data item values ​​through user input, retrieval from existing databases, or API integration from external systems. The collected data is normalized into a consistent format and stored in the integrated database 120 in an externally observable format. This integrated data structure eliminates the need to repeatedly input the same data in multiple procedures, resulting in the technical benefit of maintaining data consistency.

[0039] The integrated data can also be observed as a data format transmitted and received through interfaces with external systems, and is converted and transmitted in the format required by each external system.

[0040] Figure 6 is a flowchart detailing the integrated data generation process. The integrated data generation process includes a required data item identification step (S610), a data collection step (S620), a data validation step (S630), a data normalization step (S640), and an integrated data construction step (S650).

[0041] In the required data item identification step (S610), the data items required for each identified procedure are retrieved from the database, and common data items and procedure-specific data items are identified. In the data collection step (S620), values ​​for the identified data items are collected from user input, existing databases, and external systems.

[0042] The data validation step (S630) verifies the format and content of the collected data to check for any fraud or errors. The data normalization step (S640) converts data collected from different sources into a unified format. The integrated data construction step (S650) stores the validated and normalized data into the appropriate tables in the integrated database 120.

[0043] In the procedure processing step (S540), the procedure processing unit 340 executes processing for multiple procedures using the generated integrated data according to the settlement status. Processing includes generating necessary documents, electronic signing, sending data to an external system, and submitting procedure applications. The procedure processing unit 340 considers the dependencies and execution order of each procedure and executes the processing in the optimal order.

[0044] A particularly important feature is condition-dependent processing control, which employs a processing method that proceeds to the next step only when specific conditions (e.g., "payment completion confirmation," "all necessary documents available") are met. This prevents situations such as the transfer of ownership proceeding while payment is incomplete, thus ensuring the security of transactions.

[0045] This processing order and conditional dependencies are observable externally through the user interface. For example, a checkpoint called "payment completion confirmation" is displayed before the ownership transfer procedure. Furthermore, the status of integration with external systems (transmission complete, processing, completed, error, etc.) is also displayed in an externally observable format.

[0046] The procedure processing unit 340 tracks the processing status of each procedure and minimizes the impact on other procedures even if a failure occurs in one procedure. For example, even if a temporary failure occurs in the connection to the insurance company system, it is configured to process it independently so that it does not affect the confirmation of settlement status or the transfer of ownership procedure.

[0047] Thus, the procedure processing unit 340 provides a technical means to achieve consistent processing as a whole while coordinating processing between multiple independent systems. In particular, the system's unique technical feature of linking settlement status with various procedures ensures both transaction security and efficiency.

[0048] Figure 7 is a sequence diagram illustrating the linkage between settlement status and procedural processing. It shows how a series of procedures—settlement confirmation after the conclusion of a sales contract, transfer of ownership, vehicle registration, and insurance contract—are processed between system 100 and external systems (government agency system 170, financial institution system 180, and insurance company system 190).

[0049] In particular, Figure 7 shows that confirmation of payment completion is a condition for initiating the ownership transfer procedure, and completion of the ownership transfer is a condition for initiating the vehicle registration change. System 100 generates the data necessary for each procedure using integrated data and exchanges data with external systems at the appropriate time. It also monitors the status of each procedure and starts the next procedure only after confirming that the previous procedure has been completed.

[0050] In the progress management step (S550), the progress management unit 350 centrally manages the settlement status and the progress of multiple procedures. The progress management unit 350 tracks the settlement status (unpaid, paid, received, etc.) and the status of each procedure (not started, in processing, completed, error, etc.) and records them in the progress status table 460 of the integrated database 120. The progress management unit 350 also provides the user with a visualized version of the progress status via the user interface unit 130.

[0051] A particularly important feature is the display of the correlation between payment status and the progress of the transaction. For example, it clearly visualizes situations where a certain procedure cannot be started because payment is incomplete, or where vehicle registration cannot be changed because the transfer of ownership is not yet complete. This makes it easy for all parties involved in the transaction to understand when and under what conditions they need to be met to proceed to the next step.

[0052] Figure 8 shows an example of a progress management screen. The screen displays transaction overview information, settlement status, status of each procedure, dependencies, expected completion date, responsible person, next actions, etc. In particular, the relationship between settlement status and procedure status is clearly visualized, for example, it is graphically displayed that "settlement completion confirmation" is a prerequisite for ownership transfer. From this screen, users can check detailed information for each procedure and perform necessary operations (submitting additional documents, correcting information, etc.).

[0053] <External System Integration> Figure 9 shows the architecture for integration with external systems. System 100 integrates with government agency systems 170, financial institution systems 180, insurance company systems 190, etc., via the external system integration unit 360. Integration methods include REST API, SOAP API, and file transfer. The external system integration unit 360 converts data to match the required format of each external system and establishes a secure communication channel.

[0054] Furthermore, it plays a particularly important role in linking with the financial institution system 180, enabling an automated settlement status confirmation function. The external system integration unit 360 periodically retrieves settlement information from the financial institution system 180 and automatically confirms receipt of funds. This minimizes the time lag between settlement completion and the start of procedures, improving the efficiency of the entire transaction process.

[0055] It also provides a function to monitor the communication status with external systems and take appropriate action in the event of a failure. In particular, measures to minimize the impact of temporary communication failures on payment confirmation and procedure progress (such as a retry mechanism and securing alternative communication paths) are implemented.

[0056] This embodiment has the following technical features regarding external system integration:

[0057] Distributed Transaction Management: This system manages processes spanning multiple external systems as a consistent transaction. It manages communication status, response data, and error information with each external system in a way that is observable from the outside, controlling dependencies and consistency between external systems. A concrete technical benefit is that, for example, in simultaneous processing of procedures between a government agency system and an insurance company system, even if an error occurs in one system, the transaction status is recorded as an externally observable log or notification, maintaining overall system consistency.

[0058] These technical characteristics can be verified through communication protocols with each external system, data formats, and external displays of processing status.

[0059] Dynamic Workflow Generation: Based on the type and conditions of a transaction, the system dynamically determines the optimal procedure order and dependencies, and automatically generates a workflow. In particular, condition-dependent workflows are automatically generated according to the settlement status. This workflow is executed as an externally observable process. For example, if different tax procedures are required depending on whether a vehicle inspection is required, or if different payment confirmation flows are required depending on the payment method, the system automatically displays the appropriate procedure sequence through the user interface and presents the necessary input fields and documents. This function can be monitored externally through the display order of procedures, visualization of dependencies, and display of progress on the user interface.

[0060] Data Redundancy Prevention: Data used in common across multiple procedures is centrally managed to prevent duplicate entries and inconsistencies. For example, basic vehicle information and owner information are used in all procedures, so once entered, they are reused across all procedures. Payment information is also managed as common data referenced by multiple procedures. This function can be observed externally through the automatic display of entered data in the user interface and the consistency of data transmitted to external systems.

[0061] State Synchronization Mechanism: This mechanism synchronizes processing states across multiple systems to ensure consistent progress management. The processing status of each system is periodically synchronized and displayed through a progress management screen and status notifications that are externally observable. Synchronization of payment status and procedure status is particularly important, and a mechanism is in place to immediately reflect changes in payment status (such as confirmation of receipt of funds) in the procedure status. If any inconsistency is detected, the user will be notified and automatic corrective processing will be performed. This function can be externally verified through the progress management screen, notification messages, status logs, etc.

[0062] Smart Procedure Identification: Based on vehicle information, transaction terms, regional regulations, etc., the system automatically and accurately identifies the necessary procedures. For example, in a peer-to-peer used car transaction, it identifies the necessary procedures and documents by considering factors such as whether the vehicle has a valid inspection certificate, the status of automobile tax payments, and the expiration date of compulsory automobile liability insurance. Furthermore, it automatically determines the payment confirmation flow according to the payment method (cash, bank transfer, loan / lease, etc.). This function is externally observable through the display of a list of necessary procedures, presentation of required documents, and procedure guidance in the user interface.

[0063] <Examples> Below, we present three specific use cases as embodiments of this disclosure.

[0064] <Example 1: New Car Purchase Process> This embodiment illustrates the process when a user purchases a new car from an automobile dealer. The following embodiment is merely an example to illustrate the technical concept of this disclosure and does not limit the technical scope of this disclosure. Each processing step, data item, interface element, external system linkage method, etc., shown in the following embodiment can be implemented in various ways while maintaining their essential functionality.

[0065] Transaction Information Acquisition: Dealer staff access system 100 from user terminal 160 and input buyer information (name, address, contact information, etc.) and vehicle information (manufacturer, make, model, color, options, etc.). This input interface itself is an element that can be observed from outside the system, and the entered data is stored in the integrated database 120. The input interface is provided through a web browser, a dedicated application, or other display means.

[0066] Payment Information Registration: The dealer registers the buyer's chosen payment method (cash, bank transfer, loan / lease, etc.) and amount. In the case of a loan / lease, the dealer connects with the financial institution system 180 via API to perform the loan / lease application and review. At this point, the payment status is marked as "incomplete." Payment information and status can be observed externally through the progress management screen.

[0067] Procedure Identification: System 100 identifies the necessary procedures based on the entered information and payment method. In this case, it determines that the following are required: creation of a sales contract, loan / lease agreement (if requested by the buyer), confirmation of payment completion, vehicle registration, automobile insurance contract (voluntary and compulsory insurance), and tax-related procedures (automobile acquisition tax, etc.). The identified procedure list is displayed externally through the user interface.

[0068] Integrated Data Generation: System 100 identifies the data items required for the specified procedure and requests additional input from the user. For example, the user may input additional information such as the purpose and location of use required for vehicle registration, driver information and coverage details required for insurance contracts, whether the vehicle has passed inspection, and previous owner information. The system integrates this information to generate integrated data.

[0069] Payment Status Confirmation: System 100 works in conjunction with financial institution system 180 to monitor payment status. In the case of bank transfers, the payment status is automatically updated to "Completed" once the receipt of funds is confirmed. In the case of loans and leases, the payment status is updated to "Completed" after confirmation of the completion of the screening process and the conclusion of the contract. Payment completion is a prerequisite for the next step.

[0070] Procedure processing: System 100 processes each procedure sequentially according to the payment status. • Sales contract creation: Automatically generates a contract containing the necessary information and prepares it for electronic signature or printing. • Payment Completion Confirmation: All subsequent ownership-related procedures will be suspended until the payment status is "Completed". • Vehicle Registration: After payment is completed, the system will connect to the government agency system 170 via API and send the information necessary for vehicle registration. After registration is complete, the system will receive the vehicle's license plate information, etc. • Automobile insurance contract: The system integrates with insurance company system 190 via API to transmit information necessary for voluntary insurance contracts. It also integrates with the underwriting insurance company's system via API to handle name change procedures for compulsory automobile liability insurance, or provides electronic generation and printing functions for compulsory automobile liability insurance approval requests. It receives insurance policy information and presents it to the user. • Tax-related procedures: Based on the type of transaction (new car purchase, used car purchase, name change, etc.) and the condition of the vehicle (whether or not it has a vehicle inspection certificate, etc.), the necessary taxes (automobile tax, automobile acquisition tax, etc.) are determined, and the appropriate payment procedures are carried out in API connection with the administrative agency system 170. After payment is completed, tax payment certificate information is received.

[0071] Progress Management: System 100 tracks the settlement status and the progress of each procedure in real time and presents this information to dealer staff and buyers. In particular, the dependencies between the settlement status and the progress of the procedures are visually displayed, clearly indicating, for example, that "settlement completion confirmation" is a prerequisite for the transfer of ownership. A notification is sent each time a procedure is completed. Once all procedures are completed, a final results summary is generated and provided to the buyer. This progress management function is provided through an externally observable interface, visually displaying the status of each procedure.

[0072] <Example 2: Used Car Peer-to-Peer Transaction Process> This example illustrates the process of buying and selling a used car between individuals. In person-to-person transactions, synchronizing the timing of settlement and transfer of ownership is a particularly important issue.

[0073] Transaction information acquisition: The seller accesses system 100 from user terminal 160 and enters information about the vehicle being sold (chassis number, make, model, year, mileage, etc.) and seller information (name, address, contact information, etc.). After a potential buyer is found, buyer information is also entered.

[0074] Payment Method Registration: The seller and buyer agree on and register the payment method (bank transfer, cash, cryptocurrency, other digital wallets, etc.) and amount through System 100. The system automatically sets up a payment confirmation flow according to the selected payment method. For example, in the case of a bank transfer, the system provides the seller's account information to the buyer in a secure manner and guides them through the steps until the funds are received.

[0075] Procedure Identification: System 100 identifies the procedures required for a private-to-private used car transaction. In this case, it is determined that vehicle condition verification, sales contract creation, payment completion confirmation, ownership transfer, vehicle registration change, automobile insurance contract (by the buyer), and tax-related procedures are required. In particular, payment completion confirmation is set as a prerequisite for ownership transfer.

[0076] Integrated Data Generation: System 100 identifies the data items required for the specified procedure and requests input from the seller and buyer. Once the necessary information is entered from both parties, integrated data is generated.

[0077] Payment Status Confirmation: In person-to-person transactions, payment confirmation plays a particularly important role. System 100 tracks the payment status according to the selected payment method. For bank transfers, a function is provided for the seller to confirm receipt of funds, and once the seller confirms receipt, the payment status is updated to "completed." For cash transactions, a function is provided for the cash exchange to take place in the presence of both parties, and the payment is considered complete upon confirmation by both parties. As an option, System 100 can also function as an escrow service, temporarily holding the buyer's payment and releasing it to the seller after the transfer of ownership is complete.

[0078] Procedure processing: System 100 processes each procedure sequentially according to the payment status. • Vehicle condition check: The system provides a checklist to record the current state of the vehicle and records the vehicle condition as confirmed by both the seller and the buyer. • Creation of sales contract: Automatically generates a sales contract that meets legal requirements and prepares it for electronic signatures or printing by the seller and buyer. • Payment Completion Confirmation: All subsequent ownership-related procedures will be suspended until the payment status is "Completed". • Transfer of ownership: After payment is completed, the system will connect to the government agency system 170 via API and transmit the information necessary for the transfer of ownership. Instructions and examples of required documents will be provided. • Vehicle registration change: After the transfer of ownership is complete, the system will connect to the administrative agency system 170 via API and send the information necessary to change the registration to the buyer's information. Instructions and examples of required documents will be provided. • Automobile insurance contract: The system integrates with the insurance company of the buyer's choice via API and transmits the information necessary for a new voluntary insurance contract. Furthermore, for compulsory automobile liability insurance, the system supports the name change procedure through API integration with the underwriting insurance company or by providing electronic generation and printing functions for compulsory automobile liability insurance approval requests. • Tax-related procedures: We determine the necessary taxes (such as automobile acquisition tax) based on whether the vehicle has a valid inspection certificate and the timing of the transaction, and provide support for payment procedures as needed.

[0079] Progress Management: System 100 tracks the settlement status and the progress of each procedure, and presents this information to both the seller and the buyer. In particular, the link between the settlement status and the transfer of ownership is clearly visualized, allowing both parties to easily understand the current position of the transaction and the next steps. If there are any incomplete procedures, a reminder is sent. Once all procedures are completed, a transaction completion notification is sent to both parties.

[0080] <Example 3: Vehicle purchase process after lease termination> This embodiment illustrates the process when a lessee purchases a vehicle after the lease period has ended.

[0081] Transaction Information Acquisition: Leasing company staff enter lease vehicle information (chassis number, make, model, year, mileage, etc.) and lease user information (name, address, contact information, etc.) into System 100. Vehicle evaluation information and residual value at the end of the lease are also entered.

[0082] Payment Method Registration: Register the payment method (lump sum payment, installment payments, etc.) and residual value settlement amount agreed upon between the leasing company and the lessee. For installment payments, the payment plan is also set up. The payment confirmation flow is automatically configured according to the payment method.

[0083] Procedure Identification: System 100 identifies the procedures required for purchasing the vehicle after the lease ends. In this case, it is determined that residual value settlement, confirmation of settlement completion, transfer of ownership, change of vehicle registration (change of ownership from the leasing company to the lessee), and change of automobile insurance contract are required. In particular, confirmation of settlement completion is set as a prerequisite for the transfer of ownership.

[0084] Integrated Data Generation: System 100 identifies the data items required for the specified procedure and requests input from the leasing company and the leaseholder. Once the necessary information is entered, integrated data is generated.

[0085] Payment Status Confirmation: System 100 tracks the payment status according to the selected payment method. For lump-sum payments, the payment status is updated to "completed" after the leasing company confirms receipt of the funds. For installment payments, it is possible to set conditions such that ownership transfer is possible after confirmation of the first payment.

[0086] Procedure processing: System 100 processes each procedure sequentially according to the payment status. • Residual Value Settlement: The settlement amount is calculated based on the residual value under the lease agreement and the current vehicle valuation. Payment processing is performed via API integration with financial institution system 180. • Payment Completion Confirmation: All subsequent ownership-related procedures will be suspended until the payment status is "Completed" (or "First Payment Confirmed" in the case of installment payments). • Transfer of ownership: After the settlement conditions are met, the system will connect to the government agency system 170 via API and transmit the information necessary for the transfer of ownership from the leasing company to the lease user. • Vehicle registration change: After the transfer of ownership is complete, the system will connect to the administrative agency system 170 via API and send the information necessary to change the registered name. • Automobile insurance contract changes: By linking with insurance company system 190 via API, changes to voluntary insurance contracts due to changes in ownership are made. In addition, for compulsory automobile liability insurance, the system supports name change procedures through API linking with the underwriting insurance company or by using the electronic generation and printing function for compulsory automobile liability insurance approval request forms. • Tax-related procedures: Determine the taxes (such as automobile acquisition tax) required when purchasing a vehicle after the lease ends, and provide support for payment procedures as needed.

[0087] Progress Management: System 100 tracks the settlement status and the progress of each procedure, and presents this information to both the leasing company and the lessee. In particular, for installment payments, comprehensive progress management is provided, including payment progress and outstanding debt status. Once all procedures are completed, a transaction completion notification is sent to both parties.

[0088] <Technical Features> The system disclosed herein has the following technical features:

[0089] Payment and Procedure Linkage Mechanism: This system provides a technical mechanism that links payment status with procedure processing. This system implements condition-dependent processing control that controls the progress of procedures according to the payment status (unpaid, paid, received, etc.). This technically prevents risks such as ownership transfer proceeding before payment is complete. Furthermore, the system automatically generates an optimal payment confirmation flow according to the payment method (cash, bank transfer, loan / lease, cryptocurrency, other digital wallets, etc.). This technical feature is externally observable through the linked display of payment status and procedure status on the progress management screen, and the visualization of condition checkpoints.

[0090] Distributed Transaction Management: This system manages processes spanning multiple external systems as a consistent transaction. It manages communication status, response data, and error information with each external system in a way that is observable from the outside, controlling dependencies and consistency between external systems. A concrete technical benefit is that, for example, in simultaneous processing of procedures with a government agency system and an insurance company system, even if an error occurs in one system, the transaction status is recorded as an externally observable log or notification, maintaining overall system consistency. This technical feature can be verified through communication protocols, data formats, and external displays of processing status with each external system.

[0091] Dynamic Workflow Generation: Based on the type and conditions of a transaction, the system dynamically determines the optimal procedure order and dependencies, and automatically generates a workflow. This workflow is executed as an externally observable process. For example, if different tax procedures are required depending on whether a vehicle inspection is performed, the system automatically displays the appropriate procedure sequence through the user interface and presents the necessary input fields and documents. This functionality can be monitored externally through the display order of procedures, visualization of dependencies, and display of progress on the user interface.

[0092] Data Redundancy Prevention: Data used in common across multiple procedures is centrally managed to prevent duplicate entries and inconsistencies. For example, basic vehicle information and owner information are used in all procedures, so once entered, they are reused across all procedures. This function can be observed externally through the automatic display of entered data in the user interface and the consistency of data transmitted to external systems.

[0093] State Synchronization Mechanism: This mechanism synchronizes processing states across multiple systems to ensure consistent progress management. The processing status of each system is periodically synchronized and displayed through externally observable progress management screens and status notifications. If any inconsistencies are detected, the user is notified, and automatic corrective actions are performed. This function can be externally monitored through progress management screens, notification messages, status logs, etc.

[0094] Smart Procedure Identification: Based on vehicle information, transaction conditions, regional regulations, etc., the system automatically and accurately identifies the necessary procedures. For example, in a peer-to-peer transaction of a used car, it identifies the necessary procedures and documents by considering factors such as whether the vehicle has a valid inspection certificate, the status of automobile tax payments, and the expiration date of compulsory automobile liability insurance. This function is externally observable through the display of a list of necessary procedures, presentation of required documents, and procedural guidance in the user interface.

[0095] <Variation> In addition to the embodiments described above, the system of this disclosure includes the following modifications:

[0096] Escrow Service Function: To enhance the security of peer-to-peer transactions, System 100 functions as an escrow service, temporarily holding the buyer's payment and releasing it to the seller after the transfer of ownership is complete. This reduces risk for both the seller and the buyer and improves the reliability of the transaction.

[0097] Mobile Compatibility: The user interface is optimized for mobile devices such as smartphones and tablets, allowing users to check and operate payment confirmations and procedures anytime, anywhere. In particular, features such as receiving push notifications for bank transfer payment confirmations and immediately proceeding to the next step are now available.

[0098] Document Digitization Integration: Even when physical documents are required, the system provides a function to automatically extract information from scanned document data using OCR (Optical Character Recognition) technology and import it into the system. This facilitates the integration of paper documents and electronic data, promoting the digitalization of the entire procedure.

[0099] Blockchain Expansion: Blockchain technology is used to record ownership transfers, vehicle history, and payment records, ensuring tamper-proofing and transparency. This dramatically improves reliability, especially in person-to-person transactions, and helps resolve disputes after transactions.

[0100] AI Prediction Function: Based on past transaction data and market trends, this function predicts the time required for procedures, potential problems, and settlement risks, and proposes countermeasures in advance. In particular, the prediction and proposal of countermeasures for settlement delay risks greatly contribute to the smooth operation of the entire transaction.

[0101] Multilingual support: Provides interfaces and guidance in multiple languages ​​for foreign users. It also enables procedural navigation that complies with the laws and regulations of each country and region. This allows for smooth processing of international automobile transactions.

[0102] <Security measures> Because this system handles confidential data such as personal and financial information, it implements advanced security measures, especially for handling payment information.

[0103] Encrypted Communication: All communications are encrypted using the TLS (TRANSPORT LAYER SECURITY) protocol. Strong encryption is applied, especially to payment information and data exchange with financial institutions. Connections to external systems are also encrypted.

[0104] Multi-factor authentication: User authentication employs multi-factor authentication, which combines multiple authentication factors such as biometric authentication and digital certificates in addition to passwords. Additional authentication factors are required, especially for critical operations such as payment confirmation and ownership transfer.

[0105] Access control: Restricts the information and operations that users can access based on their roles and permissions. For example, payment information is only accessible to sellers and buyers, and viewing or editing by third parties is strictly restricted. Also, the scope of information that store staff and buyers can view and edit differs.

[0106] Audit Logs: All operations and information accesses are logged in detail and used to detect unauthorized access and operations. Detailed audit histories are automatically recorded, especially for changes in payment status and ownership-related operations.

[0107] Data Separation: Highly sensitive data (personal information, financial information, etc.) is stored separately from basic data and subject to stricter access controls. In particular, payment information and bank account information are managed with a special layer of protection.

[0108] <Performance Optimization> This system employs the following performance optimization techniques to process a large number of transactions simultaneously:

[0109] Caching mechanism: Frequently accessed data (vehicle information, regional legal regulations, etc.) is stored in the cache to improve access speed. Appropriate caching strategies are applied, especially for frequently accessed information such as payment status and progress displays.

[0110] Load balancing: The system maintains stable responsiveness even under heavy load by distributing processing across multiple servers. In particular, it is designed to prevent delays in settlement confirmation and processing of important procedures, even during periods and times of high transaction volume.

[0111] Background Processing: Time-consuming processes (such as synchronization with external systems and processing large amounts of data) are executed asynchronously in the background to minimize user waiting time. In particular, payment confirmation processes with financial institution systems are executed in the background without blocking user operations.

[0112] Database Optimization: Indexes are optimized for frequently issued queries to improve search performance. Transaction isolation levels are also appropriately set to enhance the efficiency of parallel processing. Join queries for settlement and procedural information, in particular, are highly optimized.

[0113] Microservices architecture: The system is divided into microservices based on its functionality, allowing for independent scaling and optimization. In particular, the payment management service and the procedural processing service are designed to scale independently.

[0114] <Expandability Features> This system offers the following scalability, allowing it to accommodate future functional enhancements and technological advancements:

[0115] Plugin Mechanism: The system features a plug-in mechanism to support new external systems, procedures, and payment methods, allowing for functional expansion without modifying the core system. Even when new payment services or authentication methods emerge, support is provided simply by adding plugins.

[0116] API Framework: We provide an API framework that facilitates integration with external systems and simplifies the addition of new integration partners. In particular, it is designed to flexibly accommodate new integrations with financial institutions and payment services in the future.

[0117] Business Rule Engine: The system employs a business rule engine that defines procedural decisions and processing flows, allowing for flexible adaptation to changes in legal regulations and new transaction forms. In particular, the rules defining the relationship between settlement conditions and procedure initiation conditions can be modified externally.

[0118] Data Model Scalability: The basic data model is designed with scalability in mind, so adding new data items or relationships will not affect existing functionality. The payment information model also has the scalability to accommodate future diversification of payment methods.

[0119] User Interface Customization: For retailers and corporate users, the user interface can be customized to match branding and workflow. Payment confirmation screens and progress management screens can also be customized to suit the user's role and work characteristics.

[0120] The following describes important aspects for tracing and verifying the implementation of the invention of this disclosure. A system implementing the invention of this disclosure has the following observable or verifiable features:

[0121] External characteristics of the payment and procedure linkage mechanism: When the implementer's system employs a mechanism that links payment status and procedure processing, the following externally observable characteristics can be seen. • Payment status (unpaid, paid, received, etc.) and processing status are displayed in conjunction. • Conditional dependencies, such as the inability to initiate the ownership transfer process before payment is completed, are visually displayed. Depending on the payment method (cash, bank transfer, loan / lease, cryptocurrency, other digital wallets, etc.), a different payment confirmation flow will be automatically presented. • Changes in payment status (e.g., confirmation of payment receipt) are immediately reflected in the processing status.

[0122] External characteristics of the integrated data structure: When the implementer's system adopts an integrated data structure, the following externally observable characteristics can be seen. • The same data (e.g., vehicle information) should not be required to be entered multiple times in different procedures (e.g., vehicle registration, insurance contract). • Data entered or modified in one procedure is automatically reflected in another procedure. • Data required for various procedures is structured hierarchically, and related data is displayed consistently. • Payment and procedural information are managed and displayed in an integrated manner.

[0123] External characteristics of distributed transaction management: When the implementer's system employs a distributed transaction management mechanism, the following characteristics are observed. • Processing with multiple external systems proceeds in parallel, and a delay in one process does not necessarily affect other processes. Even if an error occurs in one procedure, other procedures will continue to be processed correctly. • The status of each procedure is displayed in a centralized manner, and progress is managed in an integrated manner. • The overall transaction status, including settlement status, is visualized.

[0124] External characteristics of smart procedure identification: When the implementer's system employs smart procedure identification functionality, the following characteristics are observed. After entering basic information, the necessary procedures will be automatically displayed in a list according to the type and conditions of the transaction. The necessary tax procedures change dynamically depending on whether or not the vehicle has passed its inspection and the status of automobile tax payments. • Required documents and procedures are automatically adjusted according to local laws and regulations. • Specific procedures and verification steps will be automatically added depending on the payment method.

[0125] External features of the user interface: When the implementer's system implements the invention of this disclosure, the following interface features will be generated. • A unified management screen that integrates payment status and processing progress. • A function that visually displays the dependencies between payment conditions and procedure initiation conditions. • Automatic reuse of data entered once • Consistent data validation across multiple procedures • Updates to the processing status linked to payment status change notifications.

[0126] These features are essential technical features of the invention disclosed herein. However, there are various ways to implement these features, and the invention is not limited to any particular implementation technique, as long as it provides an externally observable function.

[0127] This disclosure reveals the essential technical concept of linked management of settlement status and procedural progress in automobile transactions, and its essential function, operation, and effect are defined as follows:

[0128] Essential Function: The ability to manage multiple independent procedures in an integrated manner, linking settlement status and procedure progress while maintaining data consistency and efficiently processing those processes. This function is realized through technical means such as an integrated data structure and distributed transaction management, but the specific implementation methods of these technical means can vary. What is important is that the function of linking settlement status and procedure progress is realized in a way that is observable from the outside.

[0129] Essential function: This function ensures data consistency across multiple systems and enables parallel processing while managing procedural dependencies based on settlement status. This function avoids risks such as ownership transfer proceeding before settlement is complete, while allowing independently processable procedures to proceed efficiently.

[0130] Essential effects: Prevention of payment problems, reduction of duplicate data entry, reduction of procedural errors, and shortening of transaction completion time. These effects are due to the technical characteristics of the payment and procedure linkage mechanism, integrated data structure, and distributed transaction management, and address conventional challenges in this field.

[0131] Embodiments that can be deemed equivalent to the invention of this disclosure have the essential functions, operations, and effects described above, and obtain substantially the same results by substantially the same means as the invention of this disclosure. For example, implementations that have non-essential technical differences, such as implementations that use a distributed database and synchronization mechanism instead of an integrated database, differences in specific communication protocols or authentication methods, or differences in specific implementations of payment confirmation methods, can be considered equivalent to the invention of this disclosure as long as they achieve the essential functions, operations, and effects described above.

[0132] The system disclosed hereby integrates and manages multiple procedures related to automobile transactions in conjunction with settlement status, thereby improving transaction security, efficiency, and accuracy. In particular, it solves the technical challenges of maintaining data integrity and synchronizing processing across multiple systems, and by appropriately linking settlement status with the progress of procedures, it significantly reduces the risks and inefficiencies that existed in conventional automobile transaction processes. Furthermore, the system's scalability and flexibility allow it to adapt to future changes in laws and regulations, as well as new transaction forms and settlement methods. The technical concept of this disclosure is embodied through an externally observable interface and data structure, and its functions and effects can be objectively verified.

[0133] <Application example related to Figure 10> Finally, an example of application will be described. Figure 10 shows an example of application of an integrated automobile transaction management system according to another embodiment of this disclosure. As shown in Figure 10, an extended architecture is formed in which a central integrated automobile transaction management system 100 is at the center, and a dealer sales management system 1000, a lease management system 1011, a mobile application integration system 1020, a peer-to-peer transaction platform 1030, a vehicle history management blockchain 1040, and a maintenance management system 1060 (not shown) are integrated. Each subsystem will be described in detail below.

[0134] <Application Example 1: Sales Management System 1000 for Dealers> As shown in Figure 10, the Dealer Sales Management System 1000 is a subsystem specifically designed for "automating the new car sales process." This subsystem integrates sales operations and payment / procedure management at automobile dealerships, improving operational efficiency and customer satisfaction. In particular, by linking with the automobile manufacturer's production management system, it provides a function to centrally manage all processes from order placement to vehicle delivery, and to link each process with the payment status. The first distinctive feature of the Dealer Sales Management System 1000 is its intelligent sales negotiation management function. This function integrates and manages customer information, vehicle information, and option selection information to support the proposal of the vehicle best suited to the customer's budget and preferences. The system automatically generates an accurate quote based on the selected vehicle and options, and further presents simulation results for multiple payment methods (cash, loan, lease, etc.). Monthly payments, interest rates, and total payments are calculated for each payment method, supporting the customer's decision-making. This quote information is directly linked to the payment process, and once the customer decides to sign a contract, the payment flow according to the selected payment method is automatically constructed. The second distinctive feature of the 1000 sales management system for dealers is its order tracking integration function. This function integrates with the automobile manufacturer's production management system via API to acquire and manage the latest information on the manufacturing process, shipping status, transportation status, and estimated arrival date at the dealer for ordered vehicles. This information is processed in conjunction with the payment status, allowing for control such as confirming the payment of a predetermined advance payment at the start of manufacturing and automatically sending an invoice for the remaining balance at the time of shipment. Furthermore, in the event of production delays or specification changes, the system is equipped with a function to immediately notify the customer and process contract changes as necessary. This enables accurate delivery date management and highly transparent information provision, contributing to improved customer satisfaction. The third distinctive feature of the Dealer Sales Management System 1000 is its digital contract management function. This function automatically generates legally valid contracts based on the selected vehicle, options, payment method, etc., and supports electronic signatures or printing and signing at the dealer's store. The contract clearly states important information such as detailed vehicle specifications, price breakdown, payment terms, delivery date, and warranty conditions, contributing to the prevention of future disputes. It also flexibly handles changes after contract signing (addition / deletion of options, specification changes, etc.), automatically updating the contract and processing the difference settlement according to the changes. This function improves the efficiency and accuracy of contract management, leading to a reduction in the workload of dealers and increased customer confidence. The fourth distinctive feature of the 1000 dealer sales management system is its vehicle delivery process optimization function. This function manages the vehicle delivery preparation process after vehicle arrival (vehicle inspection, registration procedures, vehicle maintenance, pre-delivery check, etc.) and develops an efficient delivery plan in conjunction with the payment completion status. In particular, it sets payment completion as a prerequisite for delivery, and if payment is not completed, it automates the adjustment of the delivery date and notification to the customer. It also tracks the preparation status of documents required for registration procedures and the progress of procedures with government agencies, and has a function to detect and respond to delay risks early. As a result, the transparency of the delivery process is improved, contributing to the management of customer expectations and increased satisfaction. The fifth distinctive feature of the 1000 sales management system for dealers is its automated after-sales support function. This function automates customer follow-up after vehicle delivery (satisfaction surveys, initial inspection guidance, maintenance reservation support, etc.), supporting the building of continuous customer relationships. In particular, it has implemented a function that proposes an optimal maintenance schedule based on vehicle usage and mileage, and processes everything from reservation to payment seamlessly. It also manages the history of malfunctions and recall responses during the warranty period, providing customers with appropriate information and support. These after-sales support functions support the building of long-term customer relationships, not just a single sales transaction, and realize value delivery throughout the entire vehicle lifecycle.

[0135] <Application Example 2: Lease Management System 1011> As shown in Figure 10, the lease management system 1011 is a subsystem specifically designed for "automating lease termination processing." At the end of an automobile lease agreement, complex procedures and settlement processes are required, including vehicle return, condition assessment, settlement calculation, transition to the next contract, or transfer of ownership. The lease management system 1011 automates and streamlines these processes, providing a highly transparent process for both the leasing company and the end-user. The first distinctive feature of the lease management system 1011 is its pre-lease expiration notification and option presentation function. Starting three months before the lease term expires, it gradually notifies the contract holder that the lease is nearing its end and presents options after expiration (return, re-lease, purchase, etc.). For each option, it provides detailed information such as expected costs, procedural schedules, and required documents to support the contract holder's decision-making. In particular, for the purchase option, it presents comparative information between the current market value and the purchase price, as well as estimates of various costs after purchase (automobile tax, insurance premiums, etc.), providing comprehensive information to help the contract holder make an informed decision. These notifications and information provision are also integrated with the mobile app 1020, allowing them to be viewed and operated on smartphones. The second distinctive feature of the lease management system 1011 is its vehicle condition evaluation and settlement calculation function. It provides a digital checklist and evaluation criteria for evaluating the condition of leased vehicles, objectively distinguishing between normal wear and tear due to normal use and excessive damage / wear and tear. Based on the evaluation results, it automatically calculates the settlement amount (excess mileage charges, repair costs for excessive damage, etc.) in accordance with the contract terms. This evaluation result and calculation details are recorded as a digital report, ensuring transparency and serving as basic documentation for dispute resolution. In particular, the evaluation process integrates an image recording function, improving the fairness and transparency of the evaluation by objectively recording the condition of the vehicle. A third distinctive feature of the lease management system 1011 is its buy-back option execution support function. When a contract holder chooses to buy back the vehicle, it provides one-stop support for the necessary procedures (transfer of ownership, change of name, insurance contract changes, etc.). In particular, it implements a condition-dependent processing that links the settlement management of residual value payments with the ownership transfer procedure, and automatically starts the ownership transfer procedure after confirmation of settlement completion. It also provides functions such as calculation and payment support for taxes associated with the buy-back (automobile acquisition tax, etc.), and proposal and contract support for new automobile insurance contracts. This integrates the management of multiple procedures and settlements, significantly reducing the procedural burden on end users. The fourth distinctive feature of the lease management system 1011 is its re-lease process optimization function. When a lessee chooses to re-lease (continue using the same vehicle), the system automatically proposes new lease contract terms (term, monthly lease payment, mileage limit, etc.) based on market conditions and vehicle condition. It handles the electronic signing of the re-lease contract, the management system update accompanying the start of the re-lease, and the updating of related documents (automobile tax declaration, insurance certificate, etc.) all in one go. In particular, it has implemented a function to ensure the continuity between the original lease contract and the re-lease contract and maintain the consistency of contract data. This leads to increased efficiency and accuracy in the re-lease process, reducing the workload of the leasing company. The fifth distinctive feature of the lease management system 1011 is its next-generation vehicle proposal and transition support function. When a contract holder wishes to return their current vehicle and switch to a new lease, the system proposes a next-generation vehicle based on their usage history and preferences. It links the procedures for returning the current vehicle and signing a new lease agreement to ensure a smooth transition. In particular, it implements functions such as settlement processing for the returned vehicle and calculation of offsetting the down payment and initial costs of the new lease, as well as optimizing the timing of switching between old and new contracts. Furthermore, it integrates and manages ancillary services such as selecting customization options for the new vehicle, adjusting delivery dates, and arranging temporary replacement vehicles, contributing to an improved customer experience. This minimizes the burden and risk on customers associated with switching lease vehicles and contributes to maintaining long-term customer relationships.

[0136] <Application Example 3: Mobile App Integration 1020> As shown in Figure 10, the mobile app integration 1020 is a mobile extension subsystem of the automobile transaction management system 100, centered on the "real-time settlement confirmation notification" function. This subsystem provides an environment in which transaction participants can check and operate the transaction status anytime, anywhere via mobile devices such as smartphones and tablets, and particularly enhances the transparency and real-time nature of settlement status and procedural progress. The first distinctive feature of Mobile App Integration 1020 is its push notification-based payment confirmation system. This system immediately sends push notifications to all relevant parties when it detects a change in the payment status (such as payment confirmation, payment processing completion, or payment error). In particular, for bank transfer payments, the function of automatically acquiring payment information from the financial institution system 180 and notifying in real time provides significant value. This reduces the time lag between payment confirmation and the start of the procedure, which previously took several days, to just a few minutes, dramatically improving the efficiency of the entire transaction. In addition, guidance on the next action according to the payment status (such as "Payment confirmation is complete. You can now begin the ownership transfer procedure") is also notified at the same time, allowing users to take quick and appropriate action. The second distinctive feature of Mobile App Integration 1020 is its biometric payment authorization system. This system utilizes the biometric authentication capabilities of mobile devices (fingerprint authentication, facial recognition, etc.) to provide an environment where important payment operations and authorization processes can be performed safely and easily. For example, important operations such as final approval of sales contracts, payment execution instructions, receipt confirmation, and ownership transfer approval are performed using biometric authentication instead of password entry, achieving both security and convenience. Furthermore, the authentication history is recorded as an audit trail and can be used for future dispute resolution and legal proof. This function enables secure transaction operations on mobile devices and creates an environment where important payment processing can proceed smoothly even when on the go. The third distinctive feature of Mobile App Integration 1020 is its document scanning and OCR integration function. This function utilizes the camera of a mobile device to scan paper documents (identity cards, vehicle registration certificates, insurance policies, etc.) and captures them as digital data using OCR (Optical Character Recognition) technology. The extracted data is automatically mapped to the appropriate fields, significantly reducing the effort and risk of manual entry. In particular, it simplifies the input of complex data such as vehicle information (chassis number, model, year, etc.) and owner information (name, address, etc.), improving the efficiency of data collection in the initial stages of a transaction. Furthermore, the scanned document images are saved as evidence, ensuring data reliability and traceability. This function strengthens the integration between physical documents and digital systems, enabling smooth processing even in hybrid transaction environments. The fourth distinctive feature of Mobile App Integration 1020 is the integration of location-based services. This feature utilizes the GPS function of mobile devices to provide optimal support based on the user's current location. For example, during vehicle handover, it recommends safe handover locations near the user's current location (public facilities such as police stations and city halls), and if document submission is required, it provides information on the location and business hours of the nearest government agency. Furthermore, during on-site vehicle verification, it records location and time information to prove that face-to-face verification was conducted. In addition, to prevent problems after vehicle handover, it comprehensively manages records of handover location and time, confirmation signatures (electronic signatures) from both parties, and photographic records of the vehicle's condition, leaving evidence of "when," "where," and "in what condition" the handover took place. These location-based services strengthen the link between real-world transaction activities and digital systems, improving safety and transparency, especially in person-to-person transactions. The fifth distinctive feature of Mobile App Integration 1020 is the real-time progress visualization dashboard. This feature visually displays the progress of the entire transaction in real time, providing an environment where the current situation and next actions can be clearly understood. The dashboard displays settlement status (unpaid, payment in progress, payment confirmed, etc.), document status (preparing, submitted, approved, etc.), and procedure status (not started, in progress, completed, etc.) in an integrated manner, and is designed to allow for a visual understanding of the dependencies between settlement status and procedure progress. In addition, by comparing the scheduled completion date of each step with the actual progress, it helps in the early detection of delay risks. Furthermore, the display is personalized for each stakeholder (seller, buyer, dealer, etc.), and actions that require their attention are highlighted. This dashboard function improves the transparency of complex transaction processes and creates an environment where all stakeholders can collaborate and proceed with the transaction based on the same information.

[0137] <Application Example 4: Peer-to-Peer Transaction Platform 1030> As shown in Figure 10, the peer-to-peer transaction platform 1030 is a subsystem for safely and efficiently conducting peer-to-peer (C2C) automobile sales, with an "escrow service" as its core function. This subsystem mitigates the risks unique to peer-to-peer transactions that do not involve professional intermediaries (fraud, non-payment, breach of contract, etc.) and provides a technical solution, in particular, to the challenge of synchronizing payment and ownership transfer. One of the most distinctive features of the peer-to-peer transaction platform 1030 is its escrow payment protection system. To ensure the security of transactions, this system temporarily holds the buyer's payment (deposit into an escrow account) and only releases the payment to the seller after confirming that the transfer of ownership and vehicle delivery are complete. Specifically, when a buyer makes a payment through the system, the amount is temporarily held in an escrow account and recorded as "paid (in escrow)." Once both the seller and buyer confirm the completion of the transfer of ownership and vehicle delivery, the system automatically processes the transfer from the escrow account to the seller. This eliminates typical risks such as "I paid but the vehicle wasn't delivered" or "I delivered the vehicle but didn't receive payment." Furthermore, rules are clearly defined for refunding or partially paying escrow funds, depending on the circumstances, if a transaction is canceled for any reason. This escrow payment protection system solves the fundamental challenge of synchronizing payment and ownership transfer in peer-to-peer transactions and forms the foundation of a secure transaction environment. The second distinctive feature of the peer-to-peer transaction platform 1030 is its standardized transaction document generation system. This system standardizes important documents such as contracts and confirmations used in peer-to-peer transactions and automatically generates them in a legally valid format. Specifically, it generates necessary documents such as sales contracts, vehicle condition confirmations, receipts, and transfer certificates based on input data such as vehicle information, transaction party information, and transaction conditions. The generated documents clearly state the important terms of the transaction (sales price, payment method, delivery time and location, current condition of the vehicle and presence or absence of defects, scope of warranty and exclusions, etc.), preventing future disputes. Furthermore, these documents support both digital signatures and printed signatures, balancing convenience for transaction parties with ensuring legal validity. Particularly important is that these standard documents are supervised by legal experts and comply with the laws and regulations of each region. This allows even ordinary consumers without legal expertise to proceed with transactions while receiving appropriate legal protection. A third distinctive feature of the peer-to-peer trading platform 1030 is its vehicle valuation support system. This system calculates a fair price for used cars based on objective data and supports the formation of fair transaction prices. Specifically, it analyzes information such as make, model year, mileage, grade, equipment, and vehicle condition in combination with market transaction data (auction winning bids, retail market prices, etc.) to present a range of valuation prices. This valuation result is not merely a reference price, but is provided along with detailed supporting information, including recent transaction examples of similar vehicles and market trends. In particular, the evaluation of vehicle condition is conducted based on standardized checklists and guidelines, with efforts made to minimize subjective elements. Furthermore, the valuation results are shared on the trading platform and serve as the basis for price negotiations between sellers and buyers. This is expected to improve market transparency and prevent unfair transactions caused by information asymmetry. In addition, this valuation information is also used to verify the appropriateness of the settlement amount, and a function is implemented to display warnings for transactions that deviate significantly from market prices. The fourth distinctive feature of the peer-to-peer trading platform 1030 is its trading partner reliability evaluation system. This system visualizes user reliability based on past transaction history, ratings, response speed, etc., on the platform, providing an indicator for selecting reliable trading partners. Specifically, a reliability score is calculated for each user, which is a comprehensive evaluation of factors such as transaction completion rate, commitment fulfillment rate, communication quality, and ratings from other users. This score is not a simple five-point scale, but is weighted according to the transaction amount and frequency, making it a more accurate indicator of reliability. Furthermore, new users are assigned an initial reliability score based on the strictness of their identity verification and the level of personal information verification, which is gradually updated based on their transaction history. In addition, if problems such as fraudulent activity or breach of contract are reported, the platform operator will conduct an investigation and arbitration process, and the reliability evaluation will be appropriately updated according to the results. This system reduces risk at the trading partner selection stage and contributes to preventing fraud, especially in high-value automobile transactions. The fifth distinctive feature of the peer-to-peer transaction platform 1030 is its secure transaction guideline implementation system. This system provides real-time guidance on recommended safety measures and precautions at each stage of peer-to-peer transactions, helping users make appropriate judgments and take appropriate actions. Specifically, it provides guidance tailored to the progress of the transaction, including selecting a location for vehicle inspection (public places and daytime hours are recommended), choosing a payment method (using escrow is recommended), vehicle handover procedures (checklist of necessary documents, points to check), and how to handle problems if they occur. In particular, it explains typical fraud and criminal methods and checkpoints to identify them, helping users to detect fraud before it happens. It also provides information on regional legal requirements and tax-related matters, promoting legal compliance and proper procedures. These guidelines are not merely static information, but an interactive guidance system that is presented at the appropriate time according to the user's actions and the progress of the transaction, and is naturally integrated into the actual transaction flow. This system makes it possible for users, especially those with little experience in automobile transactions, to understand and implement standard safety measures, contributing to the overall improvement of transaction safety.

[0138] <Application Example 5: Vehicle History Management Blockchain 1040> As shown in Figure 10, the Vehicle History Management Blockchain 1040 is a vehicle information management subsystem that utilizes distributed ledger technology, with "recording ownership changes" as its primary function. This subsystem records important information such as vehicle ownership history, mileage, accident history, and maintenance history on the blockchain in an immutable manner, ensuring the reliability and transparency of the information. In particular, it solves the problem of information asymmetry in used car transactions and contributes to the formation of a fairer market. The first distinctive feature of the Vehicle History Management Blockchain 1040 is its ownership transfer record system. This system records changes in vehicle ownership chronologically, providing a complete history of ownership changes. Specifically, it records all subsequent ownership transfer events (sales, inheritance, transfer from corporation to individual, etc.), starting with the initial owner at the time of new vehicle registration. Each record includes the transaction date and time, identification information of the previous and new owners (hashed for privacy), transaction method, and hash values ​​of related official documents. These records are stored in a tamper-proof form using blockchain technology and can be verified by third parties. Particularly important is that the completion status of settlements and the completion of ownership transfer procedures are recorded chronologically, proving the proper transfer of ownership. This prevents fraudulent activities such as "the previous owner double-selling the vehicle even though ownership should have been transferred," and dramatically improves the security of transactions. The second distinctive feature of the Vehicle History Management Blockchain 1040 is its mileage record verification system. This system stores periodic mileage records (during vehicle inspections, maintenance, refueling, etc.) on the blockchain and provides a function to detect tampering with mileage or unnatural changes. Each record includes the date and time of recording, mileage value, the recorder's identification information, the type of record (e.g., official vehicle inspection, inspection at a certified repair shop, self-reporting, etc.), and hash values ​​of supporting photos or documents. The system performs a time-series analysis of the recorded mileage data and sets a warning flag if it detects unnatural decreases or increases that deviate significantly from the average usage pattern of the vehicle type. This makes it possible to prevent and detect "odometer tampering," one of the serious fraudulent activities in used car transactions, and improves market transparency and reliability. In particular, ensuring the reliability of mileage, which is an important factor in used car price formation, has the effect of promoting fair price valuation and transactions. A third distinctive feature of the Vehicle History Management Blockchain 1040 is its accident and repair history transparency system. This system records information such as a vehicle's accident history, significant repair history, and recall status on the blockchain, solving the problem of "hidden defects" in used car transactions. Accident records include detailed information such as the date and time of the accident, the location and extent of the damage, the repair work, the parts used (distinguishing between new and recycled parts), the identification of the repair shop, and the repair costs. This information is collected from reliable sources such as insurance company data, repair shop reports, and public accident records, and is recorded in a format that can be verified by third parties. Particularly important is that significant repairs related to the vehicle's structure (frame repair, repairs after airbag deployment, etc.) are clearly identified, ensuring transparency of potential safety risks. This prevents sellers from concealing or underreporting accident history, creating an environment where buyers can understand the true condition of the vehicle before making a transaction. As a result, it contributes to the formation of a healthy market where vehicles with accident histories are traded at fair prices. The fourth distinctive feature of the Vehicle History Management Blockchain 1040 is its smart contract ownership transfer system. This system utilizes the smart contract functionality of blockchain technology to provide a mechanism that automatically executes ownership transfer processing when specific conditions are met. Specifically, the conditions of the sales contract (payment completion, vehicle delivery completion, submission of necessary documents, etc.) are defined as smart contracts, and when it is verified that these conditions have been met, the ownership transfer is automatically executed and recorded on the blockchain. Linkage with payment conditions is particularly important, and confirmation of the fulfillment of payment conditions according to the transaction type, such as escrow payment completion or loan contract approval, is incorporated. In addition, the payment status of automobile tax and various fees associated with the ownership transfer can also be included as conditions, which also has the effect of preventing risks such as tax arrears. This smart contract function enables the automation and efficiency of the ownership transfer process, which previously relied on human verification and manual work, contributing to a reduction in processing time and the elimination of human error. The fifth distinctive feature of the Vehicle History Management Blockchain 1040 is its integrated vehicle information access control system. This system comprehensively manages various vehicle-related information (ownership history, mileage, accident / repair history, maintenance history, parts replacement history, etc.) and provides a function to control appropriate information disclosure based on access rights. Specifically, all vehicle information can be accessed using the chassis number as a key, but the scope and level of detail of the information disclosed is controlled according to the user's authority level (current owner, prospective vehicle buyer, certified repair shop, insurance company, government agency, etc.). For example, the current owner can access all information, while prospective buyers are only disclosed the anonymized ownership history and important vehicle condition information. Particular attention is paid to protecting personal information, achieving a balance between protecting the privacy of previous owners and ensuring the reliability of vehicle history information. Furthermore, the history of information access itself is recorded on the blockchain, creating an audit trail of "who," "when," and "which information" was accessed. This ensures both the appropriate use and protection of vehicle information, creating an environment that simultaneously meets the demands for increased market transparency and protection of personal information.

[0139] <Example 6: Maintenance Management System 1060> As mentioned above, the maintenance management system 1060 is not explicitly shown in Figure 10, but is described below clearly as an intention not limited to interpretation based on the drawing. It is a subsystem that works in conjunction with the comprehensive automobile transaction management system 100 to integrate and manage vehicle maintenance information. This system records and manages maintenance activities such as periodic inspections, repairs, and parts replacements, providing an objective basis for vehicle condition evaluation and value judgment. In particular, in used car transactions, a proper maintenance history is an important element of vehicle evaluation and directly affects the transaction price and settlement terms. The primary distinguishing feature of the Maintenance Management System 1060 is its integrated maintenance history database. This database integrates data collected from various maintenance-related sources (dealer service records, certified repair shop work records, vehicle inspection data, parts replacement records, etc.) based on the vehicle identification number (VIN) to create a comprehensive maintenance history. Each maintenance record includes detailed information such as the date and time of service, the content of the service, the parts used, the identification of the service provider / workshop, the cost, and the recommended timing for the next service. For particularly important maintenance events (such as replacement of critical engine-related parts, repair of electronic control systems, and repair of safety devices), more detailed information and evidence (before and after photos, part numbers, diagnostic codes, etc.) are recorded. This database is also linked to the Vehicle History Management Blockchain 1040, and important maintenance records have hash values ​​recorded on the blockchain, enabling tamper detection. This creates a highly reliable maintenance history, improving transparency and objectivity in vehicle condition evaluation. The second distinctive feature of the 1060 maintenance management system is its predictive maintenance analysis engine. This engine integrates and analyzes collected maintenance data, vehicle usage data, manufacturer-recommended maintenance schedules, and failure statistics for similar vehicles to predict future failure risks and necessary maintenance. Specifically, it achieves highly accurate predictions through machine learning models that consider typical failure patterns for each vehicle type and year, parts aging models, and influencing factors such as the operating environment (climate conditions of the driving region, etc.). These prediction results are not only notified to owners as preventive maintenance recommendations but are also used in vehicle evaluations in used car transactions. For example, if there is a high probability that expensive repairs will be needed in the near future, this information and the estimated costs will be disclosed as part of the transaction information, serving as a reference for buyer decision-making and price negotiations. This function enables the prediction of vehicle maintenance costs and brings transparency to "hidden costs" in transactions. A third distinctive feature of the 1060 maintenance management system is its parts traceability system. This system provides the ability to track the origin and history of critical parts used in a vehicle (engine, transmission, electronic control unit, etc.). Information on each part includes part number, manufacturing information, date of installation in the vehicle, replacement history (new / remanufactured / used), warranty status, etc. More detailed information is recorded, especially for critical safety parts (airbags, brake systems, etc.). The system also manages the presence and status of recalled parts, and displays a warning if there are any unaddressed recalls. This system also integrates with the parts management systems of parts manufacturers and dealers, enabling verification of genuine parts and detection of counterfeit or inappropriate substitute parts. This improves transparency regarding vehicle safety and quality, providing important information for decision-making in transactions. In particular, in used car transactions, confirming that the correct parts are used directly impacts valuation and price determination. The fourth distinctive feature of the Maintenance Management System 1060 is the maintenance value evaluation system. This system quantifies the maintenance status of vehicles based on accumulated maintenance history data and provides an objective value evaluation index. The evaluation is calculated as a comprehensive score composed of elements such as the status of regular maintenance, the appropriateness of the timing of replacement of important parts, the quality of parts used (distinction between genuine and aftermarket parts), and the quality evaluation of the maintenance factory. This score also includes a relative evaluation compared to the average maintenance status of the same year and model, clarifying its position in the market. In particular, in used car transactions, this maintenance evaluation score is used as an adjustment factor for vehicle prices, and a price premium is attached to vehicles that have been properly maintained. This is expected to create a healthy market mechanism in which the owner's maintenance investment is reflected in the future sales value, and to contribute to the improvement of overall vehicle quality and safety assurance. The fifth distinctive feature of the Maintenance Management System 1060 is the maintenance recommendation guidance system. This system provides a function to propose an optimal maintenance plan based on the vehicle's current condition, usage patterns, and past maintenance history. Specifically, it provides personalized services tailored to the owner's usage, such as scheduling regular maintenance, recommending preventative parts replacement, and suggesting seasonal inspection items. In particular, it proposes recommended maintenance items to maximize sales value for sellers before the transaction and clearly outlines maintenance measures with a high return on investment. Furthermore, it provides buyers with an initial maintenance plan and budget estimate based on the vehicle's condition, supporting a smooth transfer of ownership and proper vehicle management. This guidance system is integrated with the mobile app integration 1020, reminding owners with push notifications when maintenance is due and also providing a function to assist in booking appointments at nearby recommended repair shops. This promotes the long-term maintenance of vehicle value and ensures safety, contributing to the overall qualitative improvement of the automotive transaction market.

[0140] Finally, while various embodiments relating to this disclosure have been described, these are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in a variety of other forms, and various omissions, substitutions, and modifications are possible without departing from the gist of the disclosure. These embodiments and their variations are included in the scope and gist of the disclosure, as well as in the claims of the invention and its equivalents. [Explanation of Symbols]

[0141] 100 Automobile Transaction Management System 110 Central Processing Server 120 Integrated Databases 130 User Interface Section 140 External Liaison Department 150 Networks 160 user terminals 170 Government Agency Systems 180 Financial Institution Systems 190 Insurance Company Systems 210 processors 220 memory 230 storage 240 communication interfaces 250 Input / Output Interfaces 310 Transaction Information Acquisition Department 315 Payment Management Department 320 Procedure Identification Department 330 Integrated Data Generation Unit 340 Procedure Processing Unit 350 Progress Management Department 360 External System Integration Department 370 Security Management Department 380 User Authentication Section 390 Notification Management Department 410 Basic Transaction Information Table 420 Vehicle Information Table 430 Customer Information Table 435 Payment Information Table 440 Procedure Information Table 450 Document Template Table 460 Progress Table S510 Transaction Information Acquisition Step S515 Payment Management Steps S520 Procedure Identification Steps S530 Integrated Data Generation Step S540 Procedure Processing Step S550 Progress Management Steps S610 Step to identify required data items S620 Data Acquisition Step S630 Data Verification Step S640 Data Normalization Step S650 Integrated Data Construction Steps Sales to 1000 dealers (system for automating the new car sales process) 1011 Lease Management System (Automated Lease Termination Processing) 1020 Mobile app integration (real-time payment confirmation notification) 1030 Peer-to-peer transaction platform (escrow service) 1040 Vehicle History Management Blockchain (Record of Ownership Changes)

Claims

1. A transaction management device, It comprises a processing unit, a communication unit, and a storage unit, The processing unit acquires information regarding the transaction of the subject object, acquires settlement information regarding the transaction, monitors the settlement status, identifies multiple procedures required for the transaction of the subject object, identifies data elements required for multiple procedures, generates integrated data including the above data elements and corresponding values, controls multiple procedures based on the settlement status, these procedures include rights processing and registration processing related to the subject object, and centrally manages the progress of the procedures. A transaction management system that connects with multiple external systems via its communications department.

2. The processing unit executes conditional processing control based on the payment status. The above conditional processing control puts rights processing on hold until the settlement status reaches a specific state, as described in claim 1.

3. The processing unit determines the payment method from the payment information and sets a confirmation procedure according to the determined payment method. The transaction management system according to claim 2, which automatically starts any pending procedures when it detects that the settlement status has transitioned to a specific state.

4. The memory unit includes a structured data management system, and the processing unit centrally manages data common to multiple procedures, A transaction management system according to any one of claims 1 to 3, which avoids duplicate data entry and maintains data consistency.

5. The processing unit identifies the necessary procedures based on the type of transaction and the state of the object, analyzes the dependencies between procedures, and determines the execution order. A transaction management system according to claim 1, which generates a processing flow based on dependencies.

6. External systems include administrative systems, financial systems, and contract management systems. The processing unit manages communication protocols with external systems, converts integrated data into the external system's requested format and transmits it, and centrally manages processes that span across external systems. The transaction management system according to claim 1, which maintains processing integrity even if an anomaly occurs in some external systems.

7. A transaction management method, The processing unit takes the step of obtaining information regarding the transaction of the object, The processing unit includes the steps of: obtaining settlement information related to a transaction and monitoring the settlement status; identifying several procedures necessary for the transaction of the subject object; identifying data elements necessary for the several procedures and generating integrated data including the data elements and corresponding values; and controlling several procedures based on the settlement status, wherein these procedures include rights processing and registration processing related to the subject object. A transaction management method comprising the steps of: a processing unit centrally managing the progress of a procedure; and a processing unit coordinating with multiple external systems via a communication unit.

8. The processing unit includes the step of performing conditional processing control based on the settlement status, The above conditional processing control suspends rights processing until the settlement status reaches a specific state, and starts rights processing when the settlement status reaches that specific state. The transaction management method according to claim 7, wherein the registration process is put on hold until the rights processing is completed, and the registration process is started when the rights processing is completed.

9. A computer implementation program, The computer has the function to acquire information about the transaction of the object, the function to acquire settlement information related to the transaction and monitor the settlement status, the function to identify multiple procedures required for the transaction of the object, and the function to identify the data elements required for multiple procedures. A program for realizing the following functions: generating integrated data containing the above data elements and corresponding values; controlling multiple procedures based on settlement status, where these procedures include rights processing and registration processing related to the subject matter; centrally managing the progress of the procedures; and coordinating with multiple external systems via communication functions.

Images