AI-based damage analysis-based repair receivable factoring system, method, and program

Abstract

This invention provides an information processing system, method, and program that automatically evaluates the reasonableness of estimated amounts and improves the accuracy of factoring risk assessment. [Solution] In a repair receivables factoring system, the server device includes an AI damage analysis unit that inputs the vehicle identification number and damage images to estimate repair costs from the damaged area and extent of damage; a risk score calculation unit that calculates and integrates the credit score of the repair company, the payment probability score of the insurance company, a validity score based on the degree of deviation between the estimated repair cost and the estimated amount, and the collateral value score of the vehicle to calculate an integrated risk score; a factoring processing unit that determines the purchase rate and commission rate based on the integrated risk score, concludes the factoring transaction, and provides funds; a settlement processing unit that performs automatic settlement by matching the insurance payment received from the insurance company with the factoring transaction; and a log recording unit that records the execution status of the process and saves it in a format that can detect tampering by adding a timestamp and digital signature.

Description

Technical Field

[0001] The related invention relates to an information processing system, a factoring system, an information processing method, and a program. The object in this disclosure includes any entity or concept having identification information and being a target of evaluation. In the following disclosure, it relates to a system, method, and program for analyzing the damage situation of an automobile by AI (artificial intelligence) to estimate the repair cost and executing factoring of the repair claim based on the estimation result. More specifically, it relates to a technology for accurately estimating the repair cost from a vehicle identification number (VIN: Vehicle Identification Number) and a damage image, integrally evaluating the estimation result and a plurality of risk factors to automatically determine the purchase conditions of the repair claim, and enabling immediate fund provision to a repairer before completion of repair. This disclosure is configured as a general-purpose technology applicable to factoring of repair claims for all articles where damage repair can occur, not only automobiles but also motorcycles, ships, aircraft, construction machinery, industrial machinery, home appliances, etc.

[0002] This disclosure is particularly related to the following technical fields. First, the field of damage detection and damage degree determination using image recognition technology. Second, the field of cost estimation and price prediction using machine learning. Third, the field of risk scoring technology for integrally evaluating a plurality of risk factors. Fourth, the field of automatic execution of financial transactions and escrow settlement. Fifth, the field of event-driven processing by API linkage and Webhook. This disclosure integrates these technical fields and constructs a factoring system linked to the entire repair process.

Background Art

[0003] Patent Document 1 discloses a sales support system that can easily convey information about a product to a buyer who wishes to purchase the product. Patent Document 1 discloses a sales support system comprising a seller terminal operated by a seller who sells a product and a buyer terminal operated by a buyer who wishes to purchase a product, wherein the seller terminal includes a first input receiving means for receiving identification information that can identify the attributes of a product, an attribute identification means for identifying the attributes of a product based on the identification information received, and a first display means for displaying attribute information related to the attributes of the product identified by the attribute identification means on the buyer terminal.

[0004] In the automotive repair industry, repair shops often struggle with cash flow during the period between completing repair work and receiving payment from the insurance company. Repair shops pay for parts when ordering them and bear labor and equipment costs during the repair work, but insurance payments are only received after the insurance company reviews and processes the claim after the repair is completed, resulting in a cash gap of several weeks to several months. This cash gap is a significant burden on the operations of small and medium-sized repair shops in particular. Meanwhile, in the used car sales industry, financing services using inventory vehicles as collateral (inventory finance, inventory factoring) are becoming increasingly popular. These services allow for a rapid assessment of the market value of vehicles, enabling businesses to secure working capital without having to sell their inventory. For example, there are services that calculate the approximate value of a vehicle based solely on its vehicle identification number and make a loan decision in as little as 10 minutes. However, in the repair industry, factoring services targeting receivables related to the provision of repair services are not yet fully developed.

[0005] Factoring repair receivables presents different challenges compared to factoring inventory vehicles. While inventory vehicles only require evaluating the market value of the physical asset, repair receivables require a comprehensive assessment of multiple risk factors, such as the likelihood of repair completion, the reasonableness of the estimated cost, and the likelihood of payment by the insurance company. In particular, accurately estimating the relationship between the extent of damage and repair costs is crucial for evaluating the reasonableness of the estimated cost, but this has traditionally relied on visual inspection by skilled appraisers, making rapid and objective evaluation difficult.

[0006] Furthermore, conventional repair process management systems primarily focus on digitizing the workflow from repair requests to estimates, assessments, progress management, and payments, and lack the financing functions necessary to improve the cash flow of repair businesses. When repair businesses need funding, they must individually utilize bank loans or general factoring services, and efficient funding linked to the repair process has not been achieved.

[0007] Furthermore, conventional factoring systems have the following challenges: Firstly, there is a transparency issue, as it is difficult for third parties to objectively verify the execution status of factoring transactions. Secondly, there is a traceability issue, as it is difficult to track the entity executing each process and its execution time when the system is deployed in a distributed environment. Thirdly, there is a verifiability issue, as there is a lack of means for parties other than factoring service providers (e.g., repair shops, insurance companies, auditing bodies) to verify the operation of the system from the outside. These challenges are particularly important from the perspective of ensuring the soundness of factoring transactions and preventing fraudulent activities. [Prior art documents] [Patent Documents]

[0008] [Patent Document 1] Japanese Patent Publication No. 2023-114967 [Overview of the Initiative] [Problems that the invention aims to solve]

[0009] The primary challenge this disclosure aims to address is the accurate and rapid estimation of repair costs based on the extent of vehicle damage. Conventional visual inspections suffer from inconsistent accuracy due to reliance on the evaluator's experience and subjectivity, and are also time-consuming. There is still room for further technical improvement.

[0010] The second challenge this disclosure aims to address is the need to comprehensively evaluate the risks associated with repair receivables and automatically determine appropriate purchase terms. Repair receivables involve multiple risk factors, including repair completion risk, estimate validity risk, and insurance company payment risk. However, there is no established method for comprehensively evaluating these factors to determine purchase rates and commission rates.

[0011] The third challenge this disclosure aims to address is the execution of factoring transactions linked to the repair process and the realization of automated settlement upon insurance payment. Conventional factoring services operate independently of the repair process, and do not involve automated processing linked to the progress of repairs or the status of insurance payments.

[0012] The fourth challenge this disclosure aims to address is ensuring transparency and traceability in factoring transactions. Even in a distributed environment, it is necessary to objectively verify the execution status of each process, thereby facilitating fraud prevention and audit compliance. This challenge is crucial for ensuring the reliability of factoring systems and achieving widespread adoption.

[0013] The fifth issue that this disclosure aims to resolve is to identify the entity executing each process and clarify the rights and obligations, even when systems are distributed or when multiple businesses cooperate to provide services. This issue is also important from the perspective of facilitating the execution of technical verification in situations where verification is a problem. Accordingly, in light of the above circumstances, this disclosure provides improved technology for a goods sales support system. However, the issues that this disclosure aims to resolve are not limited to these, nor should they be interpreted as such. [Means for solving the problem]

[0014] To solve the above problems, the repair receivables factoring system according to the first aspect of this disclosure includes a server device capable of communicating with a plurality of terminal devices via a network, the server device comprising: an AI damage analysis unit that takes a vehicle identification number and damage images as input to detect damaged parts, determine the extent of damage, and estimate repair costs; a risk score calculation unit that calculates a credit score based on the repair company's past performance, a payment probability score based on the insurance company's payment history, a validity score based on the degree of deviation between the estimated repair cost by the AI ​​damage analysis unit and the estimated amount, and a collateral value score based on the vehicle's remaining value, and integrates these to calculate an integrated risk score; a factoring processing unit that determines the purchase rate and commission rate based on the integrated risk score, concludes the factoring transaction upon approval from the repair company, and provides funds immediately; a settlement processing unit that detects the payment of insurance money from the insurance company, matches it with the factoring transaction, and performs automatic settlement; and a log recording unit that records the execution status of each process as a log, adds a timestamp and digital signature, and stores it in a format that allows for detection of tampering.

[0015] The method according to the second aspect of the present disclosure is a method executed by a computer, which includes an AI damage analysis step of identifying vehicle type information from a vehicle identification number, detecting a damaged part and the degree of damage from a damage image, and estimating a repair cost by referring to a parts price database and a wage table; a risk scoring step of evaluating a plurality of risk factors to calculate an integrated risk score and determining a purchase rate and a commission rate; a factoring transaction step of presenting purchase conditions, receiving a commitment to conclude a factoring transaction, and executing an immediate payment; an automatic settlement step of detecting an insurance payment, recovering the factoring principal and the commission, and remitting the difference to a repairer; and a logging step of recording the execution status of each step as a log.

[0016] The program according to the third aspect of the present disclosure causes a computer to function as the AI damage analysis unit, the risk score calculation unit, the factoring processing unit, the settlement processing unit, and the logging unit. According to such an aspect, an improved technology is provided.

Advantages of the Invention

[0017] According to the present disclosure, by performing damage analysis using AI, it is possible to objectively and quickly estimate the repair cost. Thereby, the validity of the estimated amount can be automatically evaluated, and the accuracy of the risk assessment of factoring is improved.

[0018] Also, according to the present disclosure, by comprehensively evaluating a plurality of risk factors such as the track record of a repairer, the payment track record of an insurance company, the validity of an estimate, and the residual value of a vehicle, it is possible to automatically determine appropriate purchase conditions according to the risk of a repair claim.

[0019] Furthermore, according to the present disclosure, since the execution of factoring transactions in conjunction with the repair process and the automatic settlement at the time of insurance payment are realized, repairers can obtain funds before the completion of repairs without requiring complicated procedures and can automatically complete the settlement when the insurance payment is received. As a result, the cash flow of repairers is improved, and stable operation of the business becomes possible.

[0020] In addition, according to the present disclosure, the execution status of each process is recorded as a log, and tampering can be detected by a timestamp and a digital signature, so the transparency and traceability of factoring transactions are ensured. This facilitates the audit response and contributes to the prevention of fraud.

[0021] Furthermore, according to the present disclosure, even when the system is distributed, communication logs between devices are recorded, so it is possible to identify the execution entity of the process. This facilitates the execution of verification even in situations where technical verification is a problem. Specifically, by recording API call logs, Webhook notification logs, database access logs, etc., it becomes possible to retrospectively verify when, by which device, and in what order each process was executed, which is useful in technical verification.

Brief Description of the Drawings

[0022] [Figure 1] FIG. 1 is a diagram showing the overall configuration of a repair claim factoring system according to an embodiment of the present disclosure. FIG. 1 shows the components of each device, the flow of data, and the communication paths between devices, and provides a basis for understanding that communication logs between devices are useful evidence in technical verification. [Figure 2] FIG. 2 is a diagram showing the flow of AI damage analysis and repair cost estimation processing. FIG. 2 shows each processing step from input to output, and the execution of each step is recorded as a log, which is useful in technical verification. [Figure 3]This diagram shows the flow of the factoring risk scoring process. Figure 3 illustrates the process of calculating and integrating multiple risk scores. [Figure 4] This diagram illustrates the factoring transaction and fund flow. Figure 4 shows the processing flow from application to immediate payment, and the externally observable outputs (such as transfer records) generated as a result of each process, which is useful for technical verification. [Figure 5] This diagram shows the flow of the automated settlement process. Figure 5 shows the processing flow from payment detection to settlement completion, clearly indicating the logging points at each processing stage, which is useful for technical verification. [Modes for carrying out the invention]

[0023] <Notes regarding trademarks> The names "QR Code," "SWIFT," "iOS," "macOS," "GPT," and "Blu-ray" used in this specification may be trademarks or registered trademarks of their respective companies. These names are used in this specification for explanatory purposes only and do not indicate any relationship with the trademark holders. Embodiments of this disclosure will be described below with reference to the drawings. The various features shown in the embodiments below can be combined with each other. Incidentally, the program for realizing the software appearing in one embodiment may be provided as a computer-readable non-transitory computer-readable medium, may be provided as downloadable from an external server, or may be provided so that the program is launched on an external computer and its functions are realized on a client terminal (so-called cloud computing). Furthermore, in various information processing according to one embodiment, an input and an output corresponding to the input can be realized. Here, the form of the information referenced in such information processing (hereinafter referred to as reference information) is not limited as long as an output is obtained as a result of the input. The reference information may be, for example, rule-based information such as a database, a lookup table, a predetermined function (including a decision formula such as a regression equation constructed by a statistical method), a trained model that has been pre-trained to learn the correlation between input and output, or a generative AI such as a large-scale language model or a visual language model that can output a desired result by inputting a prompt. Furthermore, in one embodiment, "part" may include, for example, hardware resources implemented by a circuit in a broad sense, and information processing of software that can be specifically realized by these hardware resources. Also, in one embodiment, various types of information are handled, and this information can be represented, for example, by the physical values ​​of signal values ​​representing voltage and current, the high or low values ​​of signal values ​​as a set of binary bits composed of 0s or 1s, or by quantum superposition (so-called qubits), and communication and calculations can be performed on a circuit in a broad sense. Furthermore, a circuit in a broad sense is a circuit realized by combining at least an appropriate combination of circuits, circuits, processors, and memory. The processor may be a general-purpose processor or a dedicated circuit.In other words, this includes application-specific integrated circuits (ASICs), programmable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), etc. Embodiments of this disclosure will be described in detail below with reference to the drawings. Note that the embodiments described below are examples of this disclosure, and this disclosure is not limited thereto. Furthermore, in the following description, the same components will be denoted by the same reference numerals, and redundant descriptions may be omitted.

[0024] <1. Overall System Configuration> Referring to Figure 1, the overall configuration of the repair receivables factoring system according to the embodiment of this disclosure will be described. This system is configured such that a server device 100, an insurance policyholder terminal device 200, a repair company terminal device 300, an insurance company terminal device 400, an escrow account 500, and a financial institution 600 are interconnected via a network N and can communicate with each other. Communication between each device is recorded as a communication log, which allows for post-facto verification and is useful in technical verification.

[0025] The server device 100 is a computer that performs each of the processes related to this disclosure. The server device 100 comprises an AI damage analysis unit 110, a risk score calculation unit 120, a factoring processing unit 130, a settlement processing unit 140, a database 150, a communication control unit 160, an API / Webhook processing unit 170, and a logging unit 180. The server device 100 may be implemented as a single physical server, in a distributed configuration with multiple servers, as a virtual server in a cloud computing environment, or in a combination thereof. In the case of a distributed configuration, communication logs between each server are recorded by the logging unit 180, which is useful for technical verification.

[0026] The AI ​​damage analysis unit 110 takes the vehicle identification number (VIN) and damage images as input, detects the damaged area, determines the extent of the damage, and estimates the repair cost. The AI ​​damage analysis unit 110 includes a damage detection model 111. The damage detection model 111 is a machine learning model using a convolutional neural network (CNN) and detects the damaged area and extent of damage from the damage image. The processing results of the AI ​​damage analysis unit 110 are output as an estimated repair cost, confidence level, and a list of detected damaged areas, and this output is recorded by the logging unit 180. By observing this output from the outside, it is possible to confirm that the processing of the AI ​​damage analysis unit 110 has been performed, which is useful for technical verification.

[0027] The risk score calculation unit 120 evaluates multiple risk factors to calculate an integrated risk score and performs the process of determining the purchase rate and commission rate. The risk score calculation unit 120 refers to the weight coefficient table 121 and the purchase rate table 122. The processing results of the risk score calculation unit 120 are output as individual risk scores (SC1 to SC5), an integrated risk score (RS), and the determined purchase rate and commission rate. This output is recorded by the logging unit 180 and is useful for technical verification.

[0028] The factoring processing unit 130 presents the purchase conditions determined by the risk score calculation unit 120 to the repair company, completes the factoring transaction upon acceptance, and executes the process of immediate deposit via the escrow account 500. The processing by the factoring processing unit 130 generates an externally observable transfer record at the financial institution 600. This transfer record can be used as evidence that the processing by the factoring processing unit 130 has been executed and is useful in technical verification.

[0029] The settlement processing unit 140 monitors deposit notifications from financial institutions 600, detects insurance payments from insurance companies, and performs a process to match them with factoring transactions and execute automatic settlement. The processing by the settlement processing unit 140 generates a transfer record from the escrow account 500. This transfer record can be used as evidence that the processing by the settlement processing unit 140 has been performed and is useful in technical verification.

[0030] Database 150 stores various data necessary for the operation of this system. Database 150 includes a vehicle master DB 151, a parts price DB 152, a labor cost table 153, repair shop performance data 154, insurance company payment performance data 155, a factoring transaction DB 156, and an audit log DB 157. Access to database 150 is recorded by the logging unit 180, which is useful for technical verification.

[0031] The communication control unit 160 controls communication with each terminal device, the escrow account 500, and the financial institution 600 via the network N. The communication control unit 160 executes communication via the HTTPS protocol, the WebSocket protocol, and the API interface. Communication via the communication control unit 160 is logged, recording the source, destination, date and time of transmission, and hash values ​​of the transmitted content, which is useful for technical verification.

[0032] The API / Webhook processing unit 170 handles API integration with external systems and the reception of event notifications via Webhooks. In particular, it is responsible for receiving and processing deposit notification Webhooks from financial institutions 600. API calls and Webhook receptions are logged, recording the caller, call date and time, call parameters, and response content, which is useful for technical verification.

[0033] The logging unit 180 records the processing status of each processing unit within the server device 100 as a log. The logging unit 180 assigns a timestamp to each log entry and enables tamper detection using a hash chaining method. When generating a log entry, the logging unit 180 calculates the hash value of the current log entry, including the hash value of the previous log entry, thereby forming a log chain. As a result, if the log is tampered with afterward, the consistency of the hash chain is broken, allowing for the detection of tampering, which is useful in technical verification.

[0034] The policyholder terminal device 200 is a terminal device operated by the policyholder and is implemented as a smartphone, tablet, or personal computer. The policyholder terminal device 200 is used for operations such as entering damage information, checking estimates, approving payments, and checking progress. Communication from the policyholder terminal device 200 to the server device 100 is recorded as a communication log, which is useful for technical verification.

[0035] The repair company terminal device 300 is a terminal device operated by the repair company. The repair company terminal device 300 is used for operations such as creating and sending estimates, reporting progress, applying for factoring, and confirming settlement results. The repair company terminal device 300 is linked to the repair company's account 300A. Communication from the repair company terminal device 300 to the server device 100 is recorded as a communication log, which is useful for technical verification.

[0036] The insurance company terminal device 400 is a terminal device operated by an insurance company employee. The insurance company terminal device 400 is used for operations such as reviewing estimates, approving payments, and processing insurance claim payments. Communication from the insurance company terminal device 400 to the server device 100 is recorded as a communication log, which is useful for technical verification.

[0037] Escrow account 500 is an account for the temporary holding and distribution of funds within this system. Escrow account 500 is opened at financial institution 600 and executes deposit and withdrawal processing of funds based on instructions from server device 100. Deposits and withdrawals in escrow account 500 are recorded by financial institution 600 and are available as evidence independent of the server device 100's logs, and are useful for technical verification.

[0038] Financial institution 600 manages the escrow account 500 and provides the functionality to notify the server device 100 of deposit information via a deposit notification API and webhook. Financial institution 600 records the history of deposits and withdrawals, and this record is available as evidence independent of the server device 100's logs and is useful in technical verification.

[0039] Network N consists of the internet, a dedicated line, a VPN (Virtual Private Network), or a combination of these. Communication over Network N may be logged by the telecommunications carrier, and these logs can also be used as evidence independent of the logs of server device 100, making them useful in technical verification.

[0040] <2. AI Damage Analysis and Repair Cost Estimation Processing> Referring to Figure 2, the AI ​​damage analysis and repair cost estimation process performed by the AI ​​damage analysis unit 110 will be explained. This process takes the vehicle identification number and damage images as input and outputs the estimated repair cost range and confidence level. The execution of each processing step is recorded by the logging unit 180, which is useful for technical verification.

[0041] In step S201, the AI ​​damage analysis unit 110 receives the vehicle identification number (VIN) from the insurance policyholder terminal device 200 or the repair shop terminal device 300. The VIN is a 17-digit alphanumeric unique identifier for the vehicle. The receipt of the VIN is logged along with the date and time of receipt, the source terminal identifier, and the VIN value, which is useful for technical verification.

[0042] In step S202, the AI ​​damage analysis unit 110 performs VIN decoding. In VIN decoding, the input VIN is analyzed, and vehicle information such as make, model year, grade, and specifications is identified by referring to the vehicle master DB 151. Each digit of the VIN encodes information such as country of manufacture, manufacturer, vehicle type, engine type, model year, manufacturing plant, and serial number, and the vehicle can be identified by decoding this. The results of the VIN decoding process are recorded in the log along with the identified vehicle information, which is useful for technical verification.

[0043] In step S203, the AI ​​damage analysis unit 110 receives input of damage images. Damage images are photographs of the damaged areas of the vehicle taken by the insurance policyholder or repair shop. Multiple damage images may be input. Damage images can be in JPEG, PNG, HEIF, or similar common image formats. The reception of damage images is logged along with the date and time of reception, the source terminal identifier, the number of images, and the hash value of each image, which is useful for technical verification. Recording the hash values ​​of the images allows for verification that the images have not been tampered with after the fact.

[0044] In step S204, the AI ​​damage analysis unit 110 performs damage detection processing using the damage detection model 111. The damage detection model 111 is an object detection model using a convolutional neural network (CNN) and detects damaged areas from the input damage image. The damage detection model 111 is pre-trained using past damage images and annotation data of damaged areas. Examples of detected damaged areas include the front bumper, rear bumper, fenders, door panels, hood, trunk, headlights, taillights, mirrors, glass, and wheels. The results of the damage detection processing are recorded in the log along with the bounding box coordinates and detection confidence of each detected damaged area, which is useful for technical verification.

[0045] The damage detection model 111 may be based on YOLO (You Only Look Once), SSD (Single Shot MultiBox Detector), Faster R-CNN, or similar object detection architectures. Alternatively, the damage detection model 111 may be configured as an architecture based on Vision Transformer (ViT). The choice of architecture for the damage detection model 111 is determined based on a balance between detection accuracy, processing speed, and hardware requirements. Model version and architecture information are logged for use in technical verification.

[0046] In step S205, the AI ​​damage analysis unit 110 performs damage severity determination processing for each detected damaged area. The damage severity is classified as follows: Minor (level 1) is a small scratch or dent that can be repaired by polishing or touch-up. Moderate (level 2) does not require parts replacement but sheet metal work and painting are necessary. Severe (level 3) requires parts replacement. Total loss (level 4) is irreparable or the repair cost exceeds the vehicle's value. Features such as the area, depth, and deformation of the damaged area are used to determine the damage severity. The damage detection model 111 may be configured as a multi-task learning model that outputs damage severity classification simultaneously with the detection of damaged areas. The results of the damage severity determination processing are recorded in the log along with the damage severity level and determination confidence level for each damaged area, which is useful for technical verification.

[0047] In step S206, the AI ​​damage analysis unit 110 performs a parts price reference process. In the parts price reference process, based on the vehicle information identified in step S202 and the damaged area and extent of damage determined in step S205, the AI ​​refers to the parts price DB 152 to obtain the necessary parts and their prices. The parts price DB 152 stores price information for each vehicle and each part, and includes multiple price information such as genuine parts prices, OEM parts prices, used parts prices, and remanufactured parts prices. The results of the parts price reference process are recorded in a log along with a list of the referenced parts and the price of each part, which is useful for technical verification.

[0048] In step S207, the AI ​​damage analysis unit 110 executes the repair cost calculation process. In the repair cost calculation process, it refers to the labor cost table 153 to obtain the man-hours (hours) and labor cost per unit for the repair work for each damaged part, and calculates the repair cost. The labor cost table 153 stores the standard man-hours for each type of work (sheet metal work, painting, parts replacement, adjustment, inspection, etc.) and a correction coefficient according to the difficulty of the work for the vehicle type. The results of the repair cost calculation process are recorded in the log along with the man-hours, labor cost per unit, and calculated cost for each task, which is useful for technical verification.

[0049] In step S208, the AI ​​damage analysis unit 110 performs integrated repair cost calculation processing. In this integrated repair cost calculation processing, the parts price obtained in step S206 and the repair labor cost calculated in step S207 are added together to calculate the estimated repair cost. The estimated repair cost is output as a range consisting of a minimum value, a maximum value, and a mode (or median). The minimum value represents the cost when used parts are used and the repair is completed with minimal work. The maximum value represents the cost when genuine parts are used and the work is performed to the best of one's ability. The mode represents the cost with the highest probability. The confidence level of the estimation (0-100%) is also output. The confidence level is calculated based on the quality of the damage image, the confidence level of damage detection, the completeness of the parts price data, etc. The results of the integrated repair cost calculation processing are recorded in the log along with the minimum value, maximum value, mode, and confidence level of the estimated repair cost, which is useful for technical verification.

[0050] In step S209, the AI ​​damage analysis unit 110 outputs the analysis results. The output of the AI ​​damage analysis process includes the estimated repair cost range (e.g., 450,000 to 550,000 yen), the mode (e.g., 500,000 yen), the confidence level (e.g., 85%), a list of detected damaged areas, the degree of damage for each damaged area, and a list of referenced parts. This output is used in the calculation of the estimated validity score by the risk score calculation unit 120. The transmission of the output is recorded in the log along with the date and time of transmission and the recipient, which is useful for technical verification. This output is externally observable and can be used as evidence that the processing of the AI ​​damage analysis unit 110 has been performed.

[0051] <3. Factoring Risk Scoring Process> Referring to Figure 3, the factoring risk scoring process performed by the risk score calculation unit 120 will be described. This process evaluates multiple risk factors to calculate an integrated risk score and determines the purchase rate and commission rate. The execution of each processing step is recorded by the logging unit 180, which is useful for technical verification.

[0052] In step S301, the risk score calculation unit 120 receives a factoring application from the repair company terminal device 300. The factoring application includes the identifier of the approved estimate, the desired purchase price, and the repair company identifier. The receipt of the factoring application is recorded in the log along with the date and time of receipt and the application details, which is useful for technical verification.

[0053] In step S302, the risk score calculation unit 120 calculates the repair business credit score (SC1). The repair business credit score is calculated by referring to the repair business performance data 154 and based on indicators such as the repair business's past repair completion rate, average number of days delayed, complaint rate, years of business relationship, and cumulative transaction amount. Repair businesses with a high repair completion rate, few delays, few complaints, a long years of business relationship, and a large cumulative transaction amount are assigned a higher score. The calculation process of the repair business credit score is recorded in a log along with the values ​​of each indicator referenced, the calculation formula applied, and the calculation result, which is useful for technical verification.

[0054] The formula for calculating the repair business credit score (SC1) is structured as follows, for example: SC1 = α1 × Repair Completion Rate + α2 × (1 - Normalized Delay Days) + α3 × (1 - Claim Occurrence Rate) + α4 × Normalized Transaction Years + α5 × Normalized Transaction Amount Here, α1 to α5 are weighting coefficients, set according to the importance of each indicator. Normalized delay days, normalized transaction years, and normalized transaction amount are values ​​normalized to a range of 0 to 1. This calculation formula and parameters are recorded in the log and are useful for technical verification.

[0055] In step S303, the risk score calculation unit 120 calculates the insurance company payment certainty score (SC2). The insurance company payment certainty score is calculated by referring to the insurance company payment history data 155 and based on the insurance company's past payment rate, average payment period, denial rate, and financial soundness indicators (rating, solvency margin ratio, etc.). Insurance companies with high payment rates, short payment periods, low denial rates, and high financial soundness are assigned higher scores. The calculation process of the insurance company payment certainty score is recorded in a log along with the values ​​of each indicator referenced, the calculation formula applied, and the calculation result, which is useful for technical verification.

[0056] In step S304, the risk score calculation unit 120 calculates the estimate validity score (SC3). The estimate validity score is calculated based on the degree of discrepancy between the estimated repair cost calculated by the AI ​​damage analysis unit 110 and the estimated amount submitted by the repair company. A lower degree of discrepancy results in a higher score. The formula for calculating the estimate validity score is, for example, constructed as follows. Deviation = |Estimated Amount - Mode of AI-Estimated Repair Cost| / Mode of AI-Estimated Repair Cost SC3 = max(0, 100 - β × deviation degree × 100) Here, β is a sensitivity coefficient that adjusts the degree of score reduction with respect to the degree of deviation. For example, if β=2, SC3=0 at a deviation of 50%. The calculation process of the estimated validity score is recorded in the log along with the AI ​​estimated repair cost, estimated amount, degree of deviation, and calculation result, which is useful for technical verification.

[0057] In step S305, the risk score calculation unit 120 calculates the vehicle collateral value score (SC4). The vehicle collateral value score is calculated based on the residual value of the vehicle to be repaired after repair. The residual value of the vehicle is estimated based on the vehicle type information identified from the VIN and market price data. If the residual value significantly exceeds the estimated amount, a high score is assigned because there is a high probability that the debt can be recovered by disposing of the vehicle even if the repair shop defaults. The formula for calculating the vehicle collateral value score is, for example, constructed as follows. Collateral coverage rate = Residual value after repair / Estimated cost SC4 = min(100, γ × collateral coverage rate × 100) Here, γ is a sensitivity coefficient that adjusts the sensitivity of the score to the collateral coverage rate. The calculation process of the vehicle collateral value score is recorded in a log along with the residual value after repair, estimated amount, collateral coverage rate, and calculation result, which is useful for technical verification.

[0058] In step S306, the risk score calculation unit 120 calculates the repair completion probability score (SC5). The repair completion probability score is a score that evaluates the likelihood of the repair being completed on schedule, based on the type and extent of the damage, the technical capabilities of the repair company, the availability of parts, etc. A high score is assigned when the damage is minor, the repair company has high technical capabilities, and parts are readily available. Indicators such as the damage level, the technical certification level of the repair company, and the parts supply status are used to calculate the repair completion probability score. The calculation process of the repair completion probability score is recorded in a log along with the values ​​of each referenced indicator, the calculation formula applied, and the calculation result, which is useful for technical verification.

[0059] In step S307, the risk score calculation unit 120 calculates the integrated risk score (RS). The integrated risk score is calculated using the following formula. RS = Σ(Wi × SCi) / Σ(Wi) Here, SCi is the score for each risk factor (SC1 to SC5), and Wi is the weighting coefficient corresponding to each risk factor. The weighting coefficients are stored in the weighting coefficient table 121 and are set according to the importance of the risk factor. For example, the insurance company's payment probability (SC2) directly affects the recovery of repair claims, so a high weight may be set for it, while the vehicle collateral value (SC4) is a secondary means of protection, so a relatively low weight may be set for it. The integrated risk score is calculated in the range of 0 to 100. The calculation process of the integrated risk score is recorded in a log along with each risk score, each weighting coefficient, and the calculation result, which is useful for technical verification.

[0060] Examples of weight coefficients stored in weight coefficient table 121 are shown below: W1 (repair shop creditworthiness) = 0.25, W2 (insurance company payment probability) = 0.35, W3 (estimate reasonableness) = 0.20, W4 (vehicle collateral value) = 0.10, W5 (expected repair completion) = 0.10. These weight coefficients may be dynamically optimized by machine learning based on historical transaction data. Changes to weight coefficients are logged along with the date and time of the change, the value before the change, the value after the change, and the reason for the change, which is useful for technical verification.

[0061] In step S308, the risk score calculation unit 120 determines the purchase rate and commission rate. The purchase rate table 122 stores the corresponding purchase rate and commission rate for each range of the integrated risk score. An example of the purchase rate table 122 is shown below. If the integrated risk score is 90 or higher, the purchase rate is set to 95% and the commission rate to 2%; if it is between 80 and 89, the purchase rate is set to 92% and the commission rate to 3%; if it is between 70 and 79, the purchase rate is set to 88% and the commission rate to 4%; and if it is between 60 and 69, the purchase rate is set to 83% and the commission rate to 6%. If the integrated risk score falls below a predetermined threshold (e.g., 60), the factoring application is rejected with error E301. The determination of the purchase rate and commission rate is logged along with the integrated risk score, the applied purchase rate, and the commission rate, which is useful for technical verification.

[0062] In step S309, the risk score calculation unit 120 presents the calculated purchase conditions to the repair company terminal device 300. The purchase conditions include the integrated risk score, purchase rate, commission rate, estimated amount, immediate payment amount (estimated amount × purchase rate), commission amount, and the estimated settlement amount upon insurance payment. The presentation of the purchase conditions, along with the date and time of presentation and the content of the presentation, is recorded in the log and is useful for technical verification. This presentation is displayed on the screen of the repair company terminal device 300 and can be observed externally.

[0063] <4. Factoring Transaction Processing> Referring to Figure 4, the factoring transaction processing performed by the factoring processing unit 130 will be described. This process accepts factoring applications based on approved quotations, completes the transaction after risk assessment, and executes immediate payment. The execution of each processing step is recorded by the logging unit 180, which is useful for technical verification.

[0064] In step S401, the factoring processing unit 130 verifies whether the target estimate has been approved. Only estimates approved after review by the insurance company are eligible for factoring. If the estimate is not approved, an error notification E401 is sent to the repair company terminal device 300, and the process is terminated. The execution of the verification process is recorded in the log along with the date and time of verification and the verification result, which is useful for technical verification.

[0065] In step S402, the factoring processing unit 130 receives a factoring application input from the repair company terminal device 300. The application input includes the desired purchase price and the repair company identifier. The desired purchase price is specified as an amount less than or equal to the estimated price. The receipt of the application input is recorded in the log along with the date and time of receipt and the application content, which is useful for technical verification.

[0066] In step S403, the factoring processing unit 130 calls the risk score calculation unit 120 to perform risk scoring processing (see Figure 3). This call is recorded in the log along with the date and time of the call and the call parameters, which is useful for technical verification.

[0067] The risk scoring process determines whether the integrated risk score is above a predetermined threshold. If the integrated risk score is below the threshold, a rejection notice E402 is sent to the repair company terminal device 300, and the process is terminated. The rejection notice E402 may include the reason for rejection (insufficient risk score) and suggestions for improvement (revise the estimate, submit additional documents, etc.). The judgment result, along with the integrated risk score, threshold, and judgment result, is recorded in the log and is useful for technical verification.

[0068] In step S404, the factoring processing unit 130 generates purchase conditions and presents them to the repair company terminal device 300. The purchase conditions include the integrated risk score, purchase rate (%), commission rate (%), estimated amount, immediate payment amount (= estimated amount × purchase rate), commission amount (= estimated amount × commission rate), and the planned difference settlement amount upon insurance payment. The presentation of the purchase conditions, along with the date and time of presentation and the content of the presentation, is recorded in the log and is useful for technical verification.

[0069] In step S405, the factoring processing unit 130 receives acceptance from the repair company. The repair company reviews the presented purchase conditions and chooses to accept or decline. If accepted, the declaration of acceptance is confirmed by an authentication method such as an electronic signature, one-time password, or SMS authentication. If declined, the application is processed as cancellation E403 and the process is terminated. The receipt of acceptance or decline is recorded in the log along with the date and time of receipt, the selection, the authentication method, and the authentication result, which is useful for technical verification.

[0070] In step S406, the factoring processing unit 130 executes an immediate payment. In the immediate payment process, an instruction is sent to transfer the immediate payment amount from the escrow account 500 to the repairer's account 300A. The transfer process is executed immediately (in real time), on the same day, or on the next business day. The transmission of the transfer instruction is logged along with the date and time of transmission, the transfer amount, and the recipient account information, which is useful for technical verification. The execution of the transfer is recorded by the financial institution 600 and is available as evidence independent of the server device 100's logs, which is useful for technical verification.

[0071] In step S407, the factoring processing unit 130 creates a transaction record in the factoring transaction DB 156 and sends a transaction completion notification to the repair company terminal device 300. The transaction record stored in the factoring transaction DB 156 includes the transaction identifier, estimate identifier, repair company identifier, insurance company identifier, insurance policyholder identifier, estimated amount, purchase rate, commission rate, immediate payment amount, commission amount, transaction completion date and time, status (transaction completed, settlement in progress, settlement completed, etc.), and estimated settlement amount. The creation of the transaction record is logged along with the creation date and time and the contents of the transaction record, which is useful for technical verification.

[0072] <5. Automatic settlement process> Referring to Figure 5, the automatic settlement process performed by the settlement processing unit 140 will be described. This process detects insurance payment from the insurance company, matches it with the factoring transaction, and automatically performs the settlement. The execution of each processing step is recorded by the logging unit 180, which is useful for technical verification.

[0073] In step S501, the settlement processing unit 140 monitors for deposits into the escrow account 500. Deposit monitoring is performed via a deposit notification API or webhook provided by the financial institution 600. When a deposit is made into the escrow account 500, the financial institution 600 immediately sends a deposit notification to the API / Webhook processing unit 170 of the server device 100. The settlement processing unit 140 remains in a waiting state until it receives the deposit notification. The receipt of the deposit notification is logged along with the date and time of receipt, the deposit amount, and the name of the remitter, which is useful for technical verification. Since this deposit notification is received via the API / Webhook processing unit 170, it is also recorded as an API call log.

[0074] In step S502, the settlement processing unit 140 obtains detailed information of the detected deposit. The deposit information includes the deposit amount, the name of the remitter, the date and time of the transfer, the source account information (if available), and the contents of the remarks column. The acquisition of deposit information is recorded in the log along with the date and time of acquisition and the contents of acquisition, which is useful for technical verification.

[0075] In step S503, the settlement processing unit 140 compares the acquired payment information with the transaction records stored in the factoring transaction DB 156. The comparison is performed based on information such as the name of the remitter (insurance company name), the amount received (matching the estimated amount), and the remarks column (deal identifier, insurance policy number, etc.). The comparison process uses methods such as string similarity determination, amount tolerance determination, and scoring based on multiple conditions. The execution of the comparison process is recorded in the log along with the payment information, the transaction records subject to comparison, the comparison score, and the comparison result, which is useful for technical verification.

[0076] If the matching is successful, the process proceeds to step S504. If the matching fails (e.g., no matching transaction is found, multiple candidate transactions exist), a manual confirmation request E501 is issued, requesting confirmation by an operator. The manual confirmation request E501 includes the deposit information and a list of candidate transactions. The issuance of manual confirmation requests is logged along with the date and time of issuance and the content of the issuance, which is useful for technical verification.

[0077] In step S504, the settlement processing unit 140 calculates the settlement amount. The settlement amount is calculated using the following formula. Difference = Insurance payout amount - Factoring principal - Fees Here, the factoring principal is the immediate payment amount, and the fee is the fee amount. The difference is the amount to be sent to the repair company. Note that if the insurance payment amount is less than the estimated amount (partial payment, exemption, etc.), the difference may be negative. In this case, the method of handling the shortfall (repair company bears the cost, additional billing, etc.) will be in accordance with the pre-agreed contract terms. The calculation of the settlement amount, along with the insurance payment amount, factoring principal, fee, and difference, is recorded in the log and is useful for technical verification.

[0078] In step S505, the settlement processing unit 140 executes an automatic transfer. In the automatic transfer process, the factoring principal and fees are transferred from the escrow account 500 to the factoring company's account, and the difference is transferred to the repair company's account 300A. The transfer process may be executed in a single transaction or as multiple transfer instructions. The transmission of the transfer instructions is logged along with the date and time of transmission, the transfer amount, and the destination account information, which is useful for technical verification. The execution of the transfer is recorded by the financial institution 600 and is available as evidence independent of the server device 100's logs, which is useful for technical verification.

[0079] In step S506, the settlement processing unit 140 closes the factoring transaction. It updates the status of the transaction record in the factoring transaction DB 156 to "Settlement Completed" and records the settlement completion date and time. The transaction closure is logged along with the closing date and time and the updated status, which is useful for technical verification.

[0080] In step S507, the settlement processing unit 140 sends a settlement completion notification to the relevant parties. The settlement completion notification is sent to the repair company terminal device 300 and the insurance company terminal device 400. The notification includes the settlement date and time, the amount of insurance money received, the factoring settlement amount, and the difference amount to be sent to the repair company. The transmission of the settlement completion notification is recorded in the log along with the transmission date and time, recipient, and notification content, which is useful for technical verification. This notification is displayed on the screen of each terminal device and can be observed externally.

[0081] In step S508, the settlement processing unit 140 records an audit log. The audit log DB 157 records the processing timestamp, processing details, processing target (transaction identifier, amount, etc.), processing result, and identifier of the system component that executed the processing. The audit log DB 157 has a tamper detection function and can detect subsequent tampering by calculating a hash value for each log record and applying a chained hash (hash chaining method) that includes the hash value of the previous log record. The audit log is recorded in the log along with the date and time of recording, the content of the recording, and the hash value, which is useful for technical verification.

[0082] <6. Details of the data structure> The data structures used in the system related to this disclosure are described in detail. Access to and updates to each data structure are recorded as logs, which are useful for technical verification.

[0083] Vehicle Master DB151 is a database for retrieving vehicle information from Vehicle Identification Numbers (VINs). Vehicle Master DB151 stores VIN patterns (including country of manufacture code, manufacturer code, and vehicle type code) and corresponding information such as vehicle name, year, grade, engine type, body type, destination, and manufacturing plant. Vehicle Master DB151 is regularly updated to add new vehicle models and maintain information on discontinued models. The update history is recorded as a log, which is useful for technical verification.

[0084] The Parts Price DB152 is a database that stores price information for each vehicle model and each part. The Parts Price DB152 stores vehicle identifier, part identifier (part number), part name, genuine part price, OEM part price, used part reference price, remanufactured part price, part supply status (in stock, special order, discontinued, etc.), supply lead time, and last update date and time. The Parts Price DB152 is regularly updated through data exchange with parts manufacturers and distributors. The update history is recorded as a log, which is useful for technical verification.

[0085] Labor cost table 153 is a table that stores the standard man-hours and labor costs for each repair job. Labor cost table 153 stores the job identifier, job name (sheet metal work, painting, parts replacement, adjustment, inspection, etc.), target part, standard man-hours (hours), labor cost unit price (yen / hour), vehicle difficulty coefficient, and regional coefficient. Labor cost table 153 is set based on analysis of industry association standard man-hour data and actual data. The update history is recorded as a log, which is useful for technical verification.

[0086] Repair business performance data 154 stores the past transaction history of each repair business. This data includes the repair business identifier, repair business name, location, certification, cumulative transaction count, completed repairs, repair completion rate, average repair days, average delay days, number of complaints, complaint rate, transaction start date, most recent transaction date, credit score history, and blacklist flag. Repair business performance data 154 is updated upon completion of each transaction. The update history is recorded as a log and is useful for technical verification.

[0087] Insurance company payment history data 155 is data that stores the past payment history of each insurance company. Insurance company payment history data 155 stores the insurance company identifier, insurance company name, cumulative number of payments, number of completed payments, payment rate, average payment days, number of rejected payments, rejection rate, financial health indicators (rating, solvency margin ratio, etc.), and the date of the most recent financial data update. Insurance company payment history data 155 is updated when each payment is completed. The update history is recorded as a log and is useful for technical verification.

[0088] Factoring Transaction DB156 is a database that stores details of factoring transactions. Factoring Transaction DB156 stores the following information: transaction identifier, estimate identifier, case identifier, repairer identifier, insurance company identifier, policyholder identifier, estimated amount, integrated risk score, individual risk scores (SC1-SC5), purchase rate, commission rate, immediate payment amount, commission amount, transaction completion date and time, status, immediate payment execution date and time, insurance payment detection date and time, settlement execution date and time, settlement completion date and time, difference transfer amount, and remarks. The update history of each field is recorded as a log, which is useful for technical verification.

[0089] Audit Log DB157 is a database that stores logs of all system operations. Audit Log DB157 stores the log identifier, timestamp, processing type, processing target identifier, processing content, processing result, processing executor identifier (user ID or system component ID), IP address, session identifier, and the hash value of the log record. The hash value is calculated using a chained hashing method that includes the hash value of the previous log record, which makes it possible to detect log tampering and is useful in technical verification.

[0090] <7. Variation> This disclosure is not limited to the embodiments described above, but includes the following modifications. In each modification, the processing results are recorded as logs, which are useful for technical verification.

[0091] <7-1. Variations of AI damage analysis> The damage detection model 111 of the AI ​​damage analysis unit 110 is not limited to a convolutional neural network (CNN). Other machine learning models, such as Vision Transformer (ViT), YOLO (You Only Look Once), SSD (Single Shot MultiBox Detector), Faster R-CNN, EfficientDet, or a combination thereof, may be used. Damage detection and damage severity determination may also be performed using separate models or a single multi-task model. In these variations as well, the processing results are recorded as logs and externally observable outputs are generated, which are useful for technical verification.

[0092] The input to the AI ​​damage analysis unit 110 is not limited to still images. Moving images may also be used as input, in which case it is possible to extract and analyze multiple frames from the moving images, or to estimate the three-dimensional shape of the damage using 3D reconstruction techniques. In addition, 3D scan data from a LiDAR sensor, depth camera, or stereo camera may be used as input. Even if the format of the input data changes, the basic configuration of logging input reception, logging processing results, and generating externally observable output is maintained, which is useful for technical verification.

[0093] The training of the damage detection model 111 is not limited to supervised learning. Semi-supervised learning, self-supervised learning, transfer learning, fine-tuning, or a combination thereof may be used. Furthermore, it is possible to train the model using damage image data from multiple repair shops without transmitting each shop's data externally, using federated learning. Model training and updates are logged along with the update date and time, the model version before and after the update, and statistical information on the data used for the update, which is useful for technical verification.

[0094] <7-2. Variations of Risk Scoring> The risk factors evaluated by the risk score calculation unit 120 are not limited to the five mentioned above (repair shop creditworthiness, insurance company payment probability, estimate validity, vehicle collateral value, and repair completion probability). Other risk factors may be added, such as seasonal variations (peak / off-peak seasons), regional characteristics (urban / rural areas), economic indicators (e.g., business cycle index), weather / disaster risk, past performance of similar cases, and the workload of repair shops. The addition of risk factors is recorded in the log along with the date and time of addition and the definition of the added risk factor, which is useful for technical verification.

[0095] The weight coefficients for risk factors are not limited to fixed values ​​and may be dynamically optimized using machine learning. For example, it is possible to analyze the correlation between each risk factor and actual recovery results based on historical transaction data and adjust the weight coefficients to maximize the recovery rate. It is also possible to sequentially adjust the weight coefficients based on success / failure feedback of transactions using reinforcement learning. Changes to the weight coefficients are logged along with the date and time of the change, the values ​​before and after the change, and the reason for the change, which is useful for technical verification.

[0096] The formula for calculating the integrated risk score is not limited to a weighted average. Logistic regression, decision trees, random forests, gradient boosting, neural networks, or ensembles thereof may be used. When using these machine learning models, the model's predictions are used directly as the integrated risk score, or the predicted probabilities are converted to the integrated risk score. Model selection and changes are logged along with the date and time of the change, the type of model selected, and the reason for the change, which is useful for technical validation.

[0097] <7-3. Variations of Factoring Transactions> Factoring transactions are not limited to approved quotes. Additional factoring may be performed when repairs have progressed to a certain extent, or package factoring may be performed by bundling multiple quotes. In additional factoring, the risk assessment is updated according to the progress of the repairs, and additional purchase terms are determined. In package factoring, the risks of multiple quotes are assessed in an integrated manner, and purchase terms are determined that take into account the diversification effect. In these transaction forms as well, the processing status is recorded as a log, which is useful for technical verification.

[0098] The buyback rate is not limited to a fixed rate; a variable buyback rate that increases in stages according to the progress of the repair may also be applied. For example, the buyback rate may fluctuate according to the progress, such as 80% before the start of the repair, 85% after parts arrive, and 95% after the repair is completed. The application of the variable buyback rate is logged along with the date and time of application, the progress status, and the applied buyback rate, which is useful for technical verification.

[0099] <7-4. Variations of automated settlement> The deposit detection by the settlement processing unit 140 is not limited to financial institution APIs. A combination of methods may be used, such as periodically scraping (screen capture) bank account details, accepting uploads of account statement CSV files, or accepting manual input. Even if the deposit detection method changes, the basic configuration of logging deposit detection is maintained, which is useful for technical verification.

[0100] The matching process is not limited to simple matching; more advanced methods may be used. For example, similarity determination of remitter names using natural language processing, estimation of matching accuracy using machine learning, and handling of variations in spelling using fuzzy matching may be applied. Even if the matching method changes, the basic structure of logging the matching process and recording the matching results will be maintained, which is useful for technical verification.

[0101] <7-5. Variations of Escrow Accounts> Escrow Account 500 is not limited to bank accounts. Accounts of money transfer service providers under the Payment Services Act, trust accounts, cryptocurrency wallets, or blockchain-based smart contracts may be used. When using smart contracts, the conditions for the completion of the factoring transaction, settlement conditions, etc., are implemented as program code, and the fund transfer is executed automatically when the conditions are met. The execution of the smart contract is recorded as a transaction on the blockchain and can be used as irreversible and tamper-proof evidence, which is useful in technical verification.

[0102] <7-6. Variations of the scope of application> The system described in this disclosure is not limited to automobile repair. It is applicable to factoring of repair receivables for motorcycles (motorcycles, mopeds), bicycles, ships, aircraft, construction machinery, agricultural machinery, industrial machinery, home appliances, housing equipment (air conditioners, water heaters, etc.), and buildings (exterior walls, roofs, etc.). In this case, the damage detection model and parts price database used are tailored to the specific item. Changes to the item are recorded as system configuration logs, which are useful for technical verification.

[0103] <7-7. Distributed Implementation and Indirect Infringement Response> The system relating to this disclosure is not limited to being implemented as a single server device 100. It may be implemented in a distributed manner across multiple server devices. For example, the AI ​​damage analysis unit 110 may be located on the first server, the risk score calculation unit 120 on the second server, and the factoring processing unit 130 and settlement processing unit 140 on the third server. In such a distributed implementation, communication between each server is recorded as a log, making it possible to identify the entity executing the processing, which is useful in technical verification.

[0104] In a distributed implementation, each server may be operated by a different service provider. For example, the AI ​​damage analysis unit 110 may be operated by an AI analysis service provider, the risk score calculation unit 120 by a credit information service provider, and the factoring processing unit 130 and settlement processing unit 140 by a factoring company. In such a case of collaborative operation by multiple service providers, API calls between each service provider are recorded as logs, making it possible to prove the involvement of each service provider. This makes technical verification easier and more useful in situations where indirect or co-infringement is an issue.

[0105] In a distributed implementation, each processing unit may be located in geographically separated locations. For example, the AI ​​damage analysis unit 110 may be located in a data center with high processing power, and the settlement processing unit 140 may be located on a server close to a financial institution. In such geographically distributed cases, the design takes into account communication delays and availability, but the basic configuration of log recording is maintained. The timestamps of each server are synchronized using NTP (Network Time Protocol), etc., making it possible to analyze logs from different servers in a consistent chronological order, which is useful in technical verification.

[0106] <7-8. Details of logging and traceability> The logs recorded by the logging unit 180 include processing logs, communication logs, access logs, and error logs. The processing log records the start, end, and results of processing for each processing unit. The communication log records the sender, recipient, date and time of transmission, and the hash value of the transmitted content. The access log records the date and time of access to the database, the content of the access, and the access result. The error log records the date and time of the error, the content of the error, the cause of the error, and the status of the resolution. These logs are useful for technical verification.

[0107] Each log entry is assigned a timestamp. The timestamp is synchronized with an NTP server to ensure accurate timekeeping. The timestamp precision can be in milliseconds or microseconds. Furthermore, to enhance the reliability of the timestamp, a timestamp certificate from a Time Stamping Authority (TSA) may be obtained. A timestamp certificate makes it possible to prove to third parties that the log existed at a specific point in time, which is useful in technical verification.

[0108] Each log entry may be digitally signed. The digital signature is generated using the private key of the logging unit 180 or the server device 100. The digital signature makes it possible to verify that the log was generated by a legitimate entity and has not been tampered with afterward, which is useful in technical verification. The corresponding public key is used to verify the digital signature. The public key may be issued by a Certificate Authority (CA) as a public key certificate.

[0109] Hash chaining is used to detect tampering in logs. In hash chaining, the hash value of the previous log entry is included as input when calculating the hash value of each log entry. As a result, if one log entry is tampered with, all subsequent hash values ​​will become inconsistent, making it possible to detect tampering, which is useful in technical verification. The hash function used is SHA-256, SHA-3, or a similar cryptographic hash function.

[0110] Logs may be stored in multiple locations. For example, copies of the logs may be stored in storage within the server device 100, in external cloud storage, and on a physically isolated backup server. Distributed storage improves the availability and fault tolerance of the logs. Furthermore, matching logs stored in multiple locations makes it possible to more reliably detect log tampering, which is useful in technical verification.

[0111] Logs may be recorded on a blockchain. Logs recorded on a blockchain are irreversible and tamper-proof, providing strong evidence to prove the time and content of the logs to third parties, and are useful in technical verification. The blockchain may be a public blockchain (e.g., Ethereum), a private blockchain, or a consortium blockchain.

[0112] <7-9. API provision form> The functionality of the system described in this disclosure may be provided externally as an API (Application Programming Interface). The API may be implemented as a RESTful API, GraphQL API, gRPC, or a combination thereof. Logs of API calls are recorded between the external system and the system's functionality via the API. These logs can be used as evidence that the external system has utilized the system's functionality and are useful for technical verification.

[0113] API call logs record the caller's identifier (API key, IP address, etc.), the date and time of the call, the endpoint called, request parameters, response content, processing time, and status code. API call logs make it possible to track which external systems used which functions and when, which is useful for technical verification. This also facilitates technical verification of system usage via APIs.

[0114] The API includes authentication and authorization capabilities. Authentication uses API keys, OAuth 2.0, JWT (JSON Web Token), or a combination of these. Authorization uses role-based access control (RBAC) or scope-based access control. Authentication and authorization results are logged, which is useful for technical verification. Attempts to gain unauthorized access are also logged and used for security monitoring.

[0115] The API may include a rate limiting feature. Rate limiting restricts excessive requests from specific callers, ensuring system stability. The application of rate limiting is logged, which is useful for technical verification. Records of requests exceeding the rate limit can be used for analyzing system usage and technical verification.

[0116] <7-10. Externally observable behaviors> The system described in this disclosure generates externally observable behavior. This externally observable behavior can be used as evidence for a third party to verify that the system's processing has been executed, and is useful in technical verification. The main externally observable behaviors are listed below.

[0117] Externally observable behaviors of the AI ​​damage analysis process include the estimated repair cost, confidence level, and list of damaged areas displayed on the terminal device's screen. These displays can be recorded via screenshots, serving as evidence that the AI ​​damage analysis process was performed and is useful for technical verification.

[0118] Externally observable behaviors of the risk scoring process include the integrated risk score, purchase rate, commission rate, and immediate payment amount displayed on the terminal device screen. These displays can be recorded via screenshots, serving as evidence that the risk scoring process was performed and is useful in technical verification.

[0119] One externally observable behavior of factoring transaction processing is the financial institution's transfer record. The transfer from escrow account 500 to the repairer's account 300A is recorded by financial institution 600. This transfer record is evidence independent of the server device 100's logs and serves as strong evidence that the factoring transaction processing was performed, making it useful in technical verification.

[0120] Externally observable behavior of the automated settlement process includes transfer records from escrow account 500. Transfers of factoring principal and fees to the factoring company, and transfers of the difference to the repair company, are recorded by financial institution 600. These transfer records provide strong evidence that the automated settlement process was executed and are useful in technical verification.

[0121] One externally observable behavior of settlement completion notifications is the notification displayed on the terminal device's screen. The contents of the settlement completion notification (settlement date and time, insurance payment amount, difference transfer amount, etc.) can be recorded by taking a screenshot, serving as evidence that the settlement process has been completed and is useful in technical verification.

[0122] One externally observable behavior of an API call is the request and response logs from the system making the API call. The logs recorded by the API-making system are independent of the logs from server device 100 and serve as evidence that the system's functions were used via the API, making them useful in technical verification.

[0123] <7-11. Addressing Indirect and Joint Infringements> If the system related to this disclosure is implemented in a distributed manner, or if multiple businesses cooperate to provide the service, indirect or co-infringement may become an issue. This disclosure includes a configuration that facilitates technical verification even in such scenarios.

[0124] By recording the execution of each processing unit as a log, it is possible to retrospectively verify when and what processing each processing unit performed. In the case of a distributed implementation, it is possible to grasp the overall picture of the processing by matching the logs of each server, which is useful for technical verification. When multiple businesses cooperate, it is possible to prove the involvement of each business by matching the logs of each business.

[0125] By recording communications between each processing unit as logs, it is possible to track the flow of data between processing units. For example, the content and date and time of each communication are recorded, such as the transmission of estimated repair costs from the AI ​​damage analysis unit 110 to the risk score calculation unit 120, and the transmission of purchase conditions from the risk score calculation unit 120 to the factoring processing unit 130. This makes it possible to verify the coordination status of each processing unit, which is useful in technical verification.

[0126] Externally observable behavior allows a third party to verify that system processing has been executed. Even when access to internal logs is difficult, technical verification can be performed based on externally observable evidence such as bank transfer records, terminal device screen displays, and API call logs, making it useful in technical verification.

[0127] <7-12. Summary> The modifications described above can be arbitrarily combined within the scope of the technical concept of this disclosure. In each modification, the basic configuration of generating processing traces (logging, timestamps, digital signatures, hash chains, etc.) and generating externally observable behavior (screen display, transfer records, API call logs, etc.) is maintained. This ensures that technical verification is easy and useful in technical verification in all modifications.

[0128] <8. Hardware Configuration> The server device 100 has a typical computer hardware configuration. Specifically, it includes a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), memory (RAM), storage (HDD, SSD, etc.), a network interface, and an input / output interface. The inference processing of the damage detection model 111 of the AI ​​damage analysis unit 110 may be accelerated using an accelerator such as a GPU or TPU (Tensor Processing Unit). The hardware configuration of the server device 100 may be scaled up or scaled out depending on the processing load. Changes to the hardware configuration are recorded in a log, which is useful for technical verification.

[0129] The server device 100 may be implemented as a physical server or as a virtual server. The virtual server may be implemented as a virtual machine running on a hypervisor such as VMware, Hyper-V, KVM, or Xen. Alternatively, the server device 100 may be implemented using Docker, Kubernetes, or similar container technology. Using container technology facilitates the deployment and scaling of the server device 100. The implementation configuration is logged, which is useful for technical verification.

[0130] The server device 100 may be implemented in a cloud computing environment. Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), or similar services may be used as the cloud computing environment. Using a cloud computing environment allows for reduced initial investment and flexible resource adjustment in response to fluctuations in demand. Cloud environment usage is recorded in logs, which is useful for technical verification.

[0131] The terminal devices (insurance policyholder terminal device 200, repair vendor terminal device 300, insurance company terminal device 400) are implemented as smartphones, tablets, or personal computers. Each terminal device includes a display, touch panel or keyboard / mouse, camera, communication module, and processor. Applications running on the terminal devices are implemented as native applications (iOS, Android, Windows, macOS, etc.), web applications (HTML5, JavaScript, CSS, etc.), or hybrid applications (React Native, Flutter, Cordova, etc.). Terminal device operations are logged for use in technical verification.

[0132] The terminal device's camera is used to capture images of the damage. The camera's resolution should ideally be sufficient to capture details of the damage (e.g., 12 million pixels or more). Furthermore, the camera should ideally have autofocus, image stabilization, and HDR (High Dynamic Range) capabilities. These features enable the recording of damage details as high-quality images. Metadata of the captured images is recorded in a log, which is useful for technical verification.

[0133] <9. Security> The system related to this disclosure handles information related to financial transactions, and therefore appropriate security measures are in place. Security-related events are logged and are useful for technical verification.

[0134] For communication encryption, communication between the server device 100 and each terminal device is encrypted using TLS (Transport Layer Security) / SSL (Secure Sockets Layer). TLS version 1.2 or higher is used. A sufficiently strong cipher suite is selected (e.g., AES-256-GCM, ChaCha20-Poly1305). The encryption settings are logged, which is useful for technical verification.

[0135] For data encryption, data stored in database 150 is protected by encryption at rest. The encryption algorithm used is AES-256 or a similarly strong algorithm. Encryption keys are managed by an HSM (Hardware Security Module) or KMS (Key Management Service). The management status of encryption keys is recorded in a log, which is useful for technical verification.

[0136] Access to the server device 100 is controlled by authentication and authorization. Authentication uses user ID / password, multi-factor authentication (MFA), single sign-on (SSO), or a combination of these. Authorization uses role-based access control (RBAC) or attribute-based access control (ABAC). The results of access control are logged, which is useful for technical verification.

[0137] To detect unauthorized access, server device 100 is monitored by an IDS (Intrusion Detection System) / IPS (Intrusion Prevention System). Abnormal access patterns, known attack signatures, and brute-force attacks are detected. Detection of unauthorized access is recorded in logs, alerts are sent to security personnel, and this is useful for technical verification.

[0138] As a data backup, the data in database 150 is backed up regularly. The backups are stored in a physically isolated location. Restoring from backups is regularly tested and maintained as part of the disaster recovery (DR) plan. Backup execution and results are logged for technical verification purposes.

[0139] As part of vulnerability management, server device 100 and applications undergo periodic vulnerability assessments. Discovered vulnerabilities are prioritized based on risk assessments, and patches are applied in a timely manner. The results of vulnerability assessments and patch application are logged, which is useful for technical verification.

[0140] <10. Compliance with Laws and Regulations> The system related to this disclosure will be operated in accordance with relevant laws and regulations. Compliance with laws and regulations will be recorded in logs, which will be useful for technical verification.

[0141] In relation to the Money Lending Business Act, factoring is a sale of receivables (assignment of receivables) and does not, in principle, fall under the definition of "lending" under the Money Lending Business Act. However, if it is substantially considered equivalent to a loan, it may be subject to the Money Lending Business Act. In the system related to this disclosure, the repair company does not have an obligation to repurchase the receivables, and the risk of non-payment is transferred to the factoring company, thereby clearly defining its nature as a sale of receivables. Records regarding the nature of the transaction are stored in a log and are useful for technical verification.

[0142] In relation to the Payment Services Act, depending on the operational model of Escrow Account 500, registration as a money transfer business may be required. If registration as a money transfer business is required, the service will be provided after obtaining the necessary registration. Alternatively, it is possible to avoid registration as a money transfer business by entrusting the operation of Escrow Account 500 to a financial institution that holds a banking license under the Banking Act. Records regarding the operational model are stored in logs and are useful for technical verification.

[0143] In relation to the Personal Information Protection Act, the system related to this disclosure handles information of repair companies, insurance policyholders, and insurance companies. Any information that constitutes personal information will be handled in accordance with the Personal Information Protection Act. Specifically, this includes specifying and notifying the purpose of use, obtaining consent from the individual, implementing security management measures, restricting provision to third parties, and responding to disclosure requests. Records regarding the handling of personal information are stored in logs, which are useful for technical verification.

[0144] In relation to the Installment Sales Act, factoring transactions are not subject to its regulations, but they are operated in accordance with the principles of consumer protection. In particular, the clear disclosure of fee rates, explanation of contract terms, and measures similar to cooling-off periods are being considered. Records related to consumer protection are stored in logs and are useful for technical verification.

[0145] In relation to the Act on Prevention of Transfer of Criminal Proceeds (anti-money laundering measures), the system related to this disclosure will implement measures such as verifying the identity of repair businesses, storing transaction records, and reporting suspicious transactions. eKYC (electronic Know Your Customer) may be used as a method of identity verification. Records related to anti-money laundering measures will be stored in logs and will be useful for technical verification.

[0146] <11. Industrial Applicability> This disclosure will contribute to improving the cash flow of repair shops in the automotive repair industry. Repair shops will be able to raise funds before completing repairs, allowing them to smoothly order parts and pay labor costs. This will contribute to the overall efficiency and healthy development of the repair industry. Industrial usage will be recorded in logs, which will be useful for technical verification.

[0147] This disclosure also benefits insurance companies. Improved cash flow for repair companies will reduce repair delays and improve the quality of service to policyholders. Furthermore, AI damage analysis will enable objective evaluation of the validity of estimates, contributing to the prevention of overcharging. The collaboration status with insurance companies will be recorded in logs, which will be useful for technical verification.

[0148] This disclosure also benefits policyholders. Improved cash flow for repair companies will reduce repair delays and allow for faster completion of repairs. Furthermore, it will be possible to monitor the progress of repairs through the factoring system, improving transparency. Notifications to policyholders will be logged, which is useful for technical verification.

[0149] This disclosure also offers advantages to factoring companies. AI damage analysis and risk scoring enable a precise assessment of the risk of repair receivables, allowing for the setting of appropriate purchase terms. Furthermore, automated settlement streamlines the settlement process when insurance payments are received. Factoring transaction details are logged, which is useful for technical verification.

[0150] This disclosure also offers advantages to financial institutions. It creates opportunities for providing new financial services through the provision of Escrow Account 500 and deposit notification APIs. Furthermore, it enables differentiation as a specialized financial service for the repair industry. The status of collaboration with financial institutions is logged, which is useful for technical verification.

[0151] This disclosure is applicable to fields other than the automotive repair industry. The technology described in this disclosure can be applied to fields where repair work occurs and where insurance or compensation payments take time, such as motorcycle repair, ship repair, aircraft maintenance, construction machinery repair, and home renovation. The application to other fields is logged and useful for technical verification.

[0152] <12. Other Embodiments> The embodiments described above are examples of the present disclosure, and the disclosure is not limited thereto. The present disclosure can be implemented in various forms by substituting, adding, omitting, or combining components within the scope of its technical idea. Furthermore, the embodiments and modifications described above can be combined arbitrarily to the extent that they do not contradict each other. Modifications of the embodiments are logged, which is useful for technical verification and is reproducible.

[0153] The system relating to this disclosure may be provided as SaaS (Software as a Service). In this case, repair companies, insurance companies, or factoring companies can use the functions of the server device 100 operated by the service provider without having to own the server device 100 themselves. When provided as SaaS, the service is used through API calls, so API call logs become important evidence in technical verification and are useful in technical verification.

[0154] The system described herein may be deployed in an on-premises environment. In this case, the repair company, insurance company, or factoring company installs and operates the server device 100 in its own data center or server room. Even when deployed in an on-premises environment, the logging configuration is maintained and is available and useful for technical verification.

[0155] The system described herein may be deployed in a hybrid cloud environment. In this case, some processing units may be located in the cloud environment, while others may be located in an on-premises environment. For example, the AI ​​damage analysis unit 110, which requires high processing power, may be located in the cloud environment, while the factoring transaction DB 156, which is highly confidential, may be located in an on-premises environment. Even in a hybrid cloud environment, communication between each environment is recorded as a log, which is useful for technical verification.

[0156] The system relating to this disclosure may be implemented as a microservices architecture. In this case, each processing unit, such as the AI ​​damage analysis unit 110, the risk score calculation unit 120, the factoring processing unit 130, and the settlement processing unit 140, is implemented as an independent microservice. Each microservice can be deployed, scaled, and updated independently. Communication between microservices is performed via APIs or message queues, recorded as logs, and is useful for technical verification.

[0157] The system relating to this disclosure may be implemented as an event-driven architecture. In this case, the completion of each process is issued as an event, and subsequent processes are executed triggered by the receipt of the event. Events are transmitted via Apache Kafka, RabbitMQ, Amazon SQS / SNS, or a similar messaging system. The issuance and receipt of events are logged to ensure traceability of processes and are useful for technical verification.

[0158] The method relating to this disclosure is implemented as a program for execution on a computer. This program may be provided on a computer-readable storage medium or downloaded over a network. Computer-readable storage mediums include hard disks, SSDs, CD-ROMs, DVD-ROMs, Blu-ray Discs, USB memory sticks, SD cards, and the like. The distribution status of the program is recorded in a log, which is useful for technical verification.

[0159] The program relating to this disclosure may be written in a general-purpose programming language (such as Java, Python, Go, C++, JavaScript / TypeScript, or Rust) or in a domain-specific language (DSL) tailored to a particular application. Furthermore, the inference process of the damage detection model 111 may be implemented using TensorFlow, PyTorch, ONNX, or a similar machine learning framework. Details of the program implementation are recorded in a log, which is useful for technical verification.

[0160] <13. Additional variations and detailed examples> Additional modifications and detailed embodiments are described below. These modifications and detailed embodiments can be implemented in combination with the embodiments described above, and in each embodiment, the processing results are recorded as logs, which are useful for technical verification.

[0161] <13-1. Detailed Examples of AI Damage Analysis> A detailed configuration example of the damage detection model 111 is described. The damage detection model 111 consists of a backbone network, a feature pyramid network (FPN), and a detection head. The backbone network may be configured as ResNet-50, ResNet-101, EfficientNet, or ViT (Vision Transformer). The feature pyramid network integrates feature maps of different scales, enabling multi-scale detection. The detection head outputs bounding box coordinates, damage location class, and damage severity class from the feature maps of each scale. The details of the model configuration are logged and are useful for technical verification.

[0162] The training dataset for the damage detection model 111 consists of damage images collected from past repair cases and manually annotated data. The annotated data includes the bounding box coordinates of each damaged area, the class label of the damaged area, and the class label of the degree of damage. The training dataset is constructed considering a balance between vehicle type, damaged area, and degree of damage. Data augmentation (such as image rotation, flipping, color transformation, and noise addition) may be applied to enhance the training data. Statistical information on the training dataset is logged and is useful for technical verification.

[0163] The damage detection model 111 uses mAP (mean Average Precision), Precision, Recall, and F1 score as evaluation metrics. The accuracy of damage severity determination is also evaluated using a Confusion Matrix. These evaluation metrics are recorded when the model is updated and used to track improvements in model performance. The evaluation results are recorded as logs and are useful for technical verification.

[0164] The damage detection model 111 may be retrained periodically. Retraining is performed using newly collected damage image data. Retraining enables support for new vehicle models, improves detection accuracy, and reduces false positives. The date and time of retraining, statistical information on the dataset used, the model version after retraining, and evaluation results are recorded as logs, which are useful for technical verification.

[0165] <13-2. Detailed Examples of Repair Cost Estimation> This section describes the detailed algorithm for repair cost estimation. Repair cost estimation consists of parts cost estimation and labor cost estimation. In parts cost estimation, necessary parts are identified based on the detected damaged area and extent of damage, and their prices are obtained from the parts price database (DB152). If the damage is "minor," it is determined that parts replacement is not necessary, and the parts cost is set to 0. If the damage is "severe," it is determined that parts replacement is necessary, and the price of the relevant parts is obtained. The parts cost estimation process is recorded in a log, which is useful for technical verification.

[0166] When obtaining part prices, multiple price options (genuine parts, OEM parts, used parts, remanufactured parts) may be presented. Genuine parts are the most expensive but offer a quality guarantee. OEM parts are of comparable quality to genuine parts but are relatively inexpensive. Used and remanufactured parts are even cheaper but have varying availability and quality. Presenting these price options allows repair shops to make the best part selection. The presentation of price options is logged and is useful for technical verification.

[0167] Labor cost estimation involves identifying the necessary work based on the detected damaged areas and extent of damage, and obtaining standard labor hours and labor rates from Labor Rate Table 153. Standard labor hours are determined based on industry association standards, analysis of historical performance data, or expert knowledge. Labor rates may be adjusted according to region, repairer certification level, or difficulty of the work. The labor cost estimation process is logged for use in technical verification.

[0168] Monte Carlo simulation may be used to estimate the range of repair costs. Monte Carlo simulation models the uncertainty of part prices and labor costs as probability distributions, and estimates the distribution of repair costs by running numerous simulations. From this distribution, the minimum value (e.g., 5th percentile), maximum value (e.g., 95th percentile), and mode are calculated. The simulation results are logged and are useful for technical verification.

[0169] <13-3. Detailed Examples of Risk Scoring> This section describes the detailed algorithm for risk scoring. Machine learning models may be used in calculating each risk score (SC1 to SC5). For example, to calculate the repairer credit score (SC1), logistic regression, random forest, or gradient boosting models may be used, using historical transaction data as training data. Model details are logged, which is useful for technical validation.

[0170] In risk scoring, Explainable AI (XAI) techniques may be used. For example, by calculating SHAP (SHapley Additive exPlanations) values, it is possible to explain how much each input feature contributed to the risk score. This explanation may be provided when presenting purchase conditions to repair companies, contributing to improved transparency. The generation of the explanation is recorded as a log, which is useful for technical verification.

[0171] External data sources may be referenced in the calculation of risk scores. For example, data from Teikoku Databank, Tokyo Shoko Research, or similar credit rating agencies may be referenced as credit information for repair companies. Rating information from rating agencies may be referenced as financial soundness for insurance companies. References to external data sources are logged and are useful for technical verification.

[0172] <13-4. Detailed Examples of Weight Coefficient Optimization> This section describes the optimization algorithm for the weight coefficients stored in the weight coefficient table 121. The optimization of the weight coefficients is performed to maximize the recovery rate based on historical trading data. The objective function is defined as the recovery rate, profit margin, or a combination of these. Grid search, random search, Bayesian optimization, or a genetic algorithm may be used as the optimization algorithm. The optimization process is logged for use in technical verification.

[0173] In optimizing weight coefficients, techniques are used to prevent overfitting. For example, cross-validation is used to split the training data into test data and evaluate performance on the test data. Regularization (L1 regularization, L2 regularization) is also applied to suppress extreme values ​​of weight coefficients. The execution date and time of the optimization, the optimization results, and the evaluation results are recorded as logs, which are useful for technical verification.

[0174] <13-5. Detailed Examples of the Matching Process> This section describes the detailed algorithm of the matching process performed by the settlement processing unit 140. The matching process matches the payment information with the transaction records in the factoring transaction DB 156. To improve the accuracy of the matching, a scoring method combining multiple matching conditions is used. Details of the matching process are recorded in a log, which is useful for technical verification.

[0175] The following criteria are used for matching: Firstly, the degree of agreement between the remitter's name and the insurance company's name. Not only exact string matches, but also partial matches using edit distance (Levenshtein distance), Jaro-Winkler similarity, or N-gram similarity are evaluated. Secondly, the degree of agreement between the deposit amount and the estimated amount. Not only exact matches, but matches within a specified tolerance (e.g., ±1%, or ±100 yen) are evaluated. Thirdly, the match of the case identifier, policy number, or vehicle identification number listed in the remarks column. The evaluation results for each matching criterion are recorded in a log and are useful for technical verification.

[0176] The matching score is calculated by weighting and summing the scores of each matching condition. If the matching score is above a predetermined threshold, the matching is considered successful. If the matching score is below the threshold, or if there are multiple potential transactions, a manual confirmation request is issued. Details of the matching process (score for each matching condition, summed score, and judgment result) are recorded as logs, which are useful for technical verification.

[0177] <13-6. Detailed Examples of Audit Logs> This section describes the detailed structure of the audit logs recorded in audit log DB157. Each entry in the audit log includes the following fields: log ID (unique identifier), timestamp (ISO 8601 format), processing type code, processing target type, processing target ID, processing content (structured data or JSON), processing result code, processing executor type (user, system, external API), processing executor ID, client IP address, session ID, and chained hash value. The structure of the audit log itself is recorded in the log and is useful for technical verification.

[0178] The calculation of chained hash values ​​is performed as follows: For each log entry, the contents of that entry (log ID, timestamp, processing type code, etc.) are concatenated with the chained hash value of the previous log entry, and a hash function (SHA-256) is applied. For the first log entry, a predetermined initial value is used as the previous hash value. Due to this chaining, if an intermediate log entry is tampered with, all subsequent chained hash values ​​will become inconsistent, allowing for the detection of tampering, which is useful in technical verification.

[0179] Audit log verification is performed automatically at regular intervals. Verification recalculates the chained hash value of each log entry and compares it to the recorded value. If a discrepancy is detected, an alert is issued indicating potential tampering. The date and time of verification, as well as the verification results, are recorded in the log, which is useful for technical verification.

[0180] <13-7. Detailed Examples of Notifications> This section details the notifications sent at each processing stage. Notifications are sent as push notifications, emails, SMS messages, or in-app notifications. Each notification includes the notification type, a summary of the notification content, and a link to further information. Notification sending is logged and is useful for technical verification.

[0181] The AI ​​damage analysis completion notification is sent when the AI ​​damage analysis process is complete. The notification includes the estimated repair cost range, confidence level, and the number of damaged areas detected. This notification allows repair shops or insurance companies to quickly review the AI ​​damage analysis results. Notification transmissions are logged and are useful for technical verification.

[0182] A factoring application acknowledgment notification is sent upon receipt of the factoring application. The notification includes the application ID, application date and time, and that the application is under review. This notification allows the repair company to confirm that the application has been successfully received. The notification is logged and is useful for technical verification.

[0183] The offer of purchase terms notification is sent upon completion of risk scoring. The notification includes the integrated risk score, purchase rate, commission rate, immediate payment amount, and acceptance deadline. This notification allows the repairer to review the purchase terms and decide whether to accept or decline. Notification transmission is logged and is useful for technical verification.

[0184] The factoring transaction completion notification is sent after the repair company accepts the transaction. The notification includes the transaction ID, the immediate payment amount, the scheduled transfer date and time, and the settlement terms. This notification allows the repair company to confirm the completion of the transaction and the scheduled immediate payment. The notification is logged and is useful for technical verification.

[0185] An instant payment completion notification is sent after the instant payment has been processed. The notification includes the transfer amount, the date and time of the transfer, and some of the recipient's account information (such as the last four digits). This notification allows the repair company to confirm the payment. The notification is logged and is useful for technical verification.

[0186] Insurance payment detection notifications are sent when an insurance payment is detected. The notification includes the payment amount, date and time of payment, and that settlement is scheduled. This notification allows repair shops to confirm that the insurance payment has been received. Notification transmissions are logged and are useful for technical verification.

[0187] A settlement completion notification is sent when the automatic settlement is completed. The notification includes the insurance payment amount, factoring settlement amount, difference payment amount, and the date and time of the difference payment. This notification allows the repair company to confirm the completion of the settlement and the payment of the difference. The notification is logged and is useful for technical verification.

[0188] <13-8. Detailed Example of Error Handling> This section describes potential errors that may occur at each processing stage and how to handle them. Error handling is crucial for ensuring system stability and reliability. Each error is logged, which is useful for technical verification.

[0189] Errors in AI damage analysis processing include insufficient image quality errors (blurry, too dark, damage not visible, etc.), VIN decoding errors (incorrect VIN format, vehicle not found, etc.), and model inference errors (model loading failure, inference timeout, etc.). When these errors occur, an appropriate error message is displayed, prompting re-entry or retry. Error occurrences are logged, which is useful for technical verification.

[0190] Errors in the risk scoring process include data acquisition errors (such as the inability to find repair shop performance data or insurance company payment performance data) and calculation errors (such as division by zero or overflow). When these errors occur, default values ​​are applied or the process is moved to manual review. Error occurrences are logged, which is useful for technical verification.

[0191] Errors in factoring transaction processing include estimate rejection errors (E401), insufficient risk score errors (E402), acceptance timeout errors (when acceptance is not obtained within the acceptance deadline), and transfer errors (communication errors with financial institutions, incorrect account information, etc.). When these errors occur, an appropriate error message is displayed, prompting resubmission or inquiry. Error occurrences are logged, which is useful for technical verification.

[0192] Errors in the automated settlement process include reconciliation failure errors (E501), amount mismatch errors (when the insurance payment amount differs significantly from the estimated amount), and transfer errors (when the transfer from the escrow account fails). When these errors occur, a manual verification request is issued, and an operator takes action. Error occurrences are recorded in the log, which is useful for technical verification.

[0193] <14. Considerations for International Expansion> This section explains considerations when deploying the system described in this disclosure internationally. Settings and processes related to international deployment are logged and are useful for technical verification.

[0194] For language support, the user interface and notifications are available in multiple languages. Language selection may be done automatically based on user preferences, browser language settings, or regional settings. The damage detection model 111 is trained to accommodate vehicles in each country. The parts price database 152 and labor cost table 153 are configured to accommodate the pricing structures of each country. Changes to language settings are logged for use in technical verification.

[0195] For currency support, amounts are displayed and processed in the respective currencies. When currency conversion is necessary, real-time exchange rates are referenced. The exchange rate reference history is recorded as a log, which is useful for technical verification.

[0196] In order to comply with legal regulations, operations are conducted in accordance with the financial regulations, personal data protection regulations, and cross-border data transfer regulations of each country. For example, compliance with the GDPR (General Data Protection Regulation) is required within the EU. In order to comply with the GDPR, data subjects' rights (such as access rights, rights to correction, rights to erasure, and rights to data portability), data protection impact assessments (DPIAs) are conducted, and records of data processing are kept. The status of legal and regulatory compliance is recorded in logs, which is useful for technical verification.

[0197] In terms of data center placement, data centers may be geographically dispersed to comply with national or regional regulations. For example, data within the EU may be stored in data centers within the EU. Data synchronization between data centers is performed via encrypted communication, recorded as logs, and is useful for technical verification.

[0198] <15. Future Expansion Potential> This disclosure describes the future scalability of the system. Settings and processes related to scalability are logged and are useful for technical verification.

[0199] As an extension to predictive maintenance, the technology of the AI ​​damage analysis unit 110 can be applied to predict the progression of damage and propose preventive maintenance. By analyzing past damage patterns and repair history data, it is possible to predict potential future damage and propose preventive maintenance. The prediction results are recorded in a log, which is useful for technical verification.

[0200] As part of its supply chain integration, the system can be used to integrate parts ordering, inventory management, and delivery tracking. Parts needed for repairs are automatically ordered, and their inventory and delivery status are tracked in real time. This leads to more efficient repairs and shorter lead times. The status of supply chain integration is logged, which is useful for technical verification.

[0201] As part of its integration with insurance products, it is possible to offer insurance products related to factoring transactions (such as credit insurance and trade credit insurance). These insurance products reduce the risk for factoring businesses, enabling them to offer more proactive factoring services. The status of integration with insurance products is recorded in a log, which is useful for technical verification.

[0202] As part of the blockchain integration, it is possible to record the entire factoring transaction process on the blockchain. Records on the blockchain are tamper-proof and transparent, improving the reliability and auditability of transactions. Furthermore, smart contracts enable the automated execution of transaction terms. The status of blockchain integration is logged, which is useful for technical verification.

[0203] While embodiments of this disclosure have been described so far, this disclosure is not limited to the embodiments described above, and various modifications are possible within the scope of the invention as described in the claims. In any modification, the execution status of the process is recorded as a log, which is useful for technical verification.

[0204] <15. Modified embodiments in international expansion> The variations in the international deployment of the system according to the present disclosure will be described. Implementations corresponding to the regulations, business customs, languages, and currencies of each country are possible. The implementation status of variations in international deployment is recorded in the log together with the implementation region, corresponding regulations, language settings, and currency settings. While conforming to ISO 3779, which is the international standard for VIN (Vehicle Identification Number), it also supports the vehicle identification systems specific to each country. For example, within the European Union, the EU type approval number is used, in Japan, the chassis number and type designation number are used, and in China, in addition to the 17-digit VIN, a Chinese-specific identification code may be used. The process of specifying vehicle attributes from this identification information is recorded in the log together with the type of identification information, identified attributes, and referenced database. As for multi-language support, the user interface, notification messages, and contract documents are provided in multiple languages. Language switching is automatically executed based on the user's settings or regional information. Dynamic translation using a machine translation API is also possible. The execution of language switching is recorded in the log together with the source language, target language, and switching date and time. As for multi-currency support, the display currency and settlement currency support multiple currencies. The exchange rate is converted based on a real-time exchange rate API for obtaining the exchange rate or a fixed exchange rate. The execution of currency conversion is recorded in the log together with the source currency, target currency, used exchange rate, and conversion date and time. Regarding country-specific tax system support, the calculation and declaration of consumption tax, value-added tax (VAT), withholding tax, etc. are carried out in accordance with the tax laws of each country. The automatic generation function of tax documents facilitates the declaration to the tax authorities of each country. The execution of tax calculation is recorded in the log together with the applied tax rate, tax amount, and laws serving as the calculation basis. As for international remittance support, it supports the inter-bank remittance systems of each country, such as SWIFT, SEPA (Europe), ACH (USA), and the Zengin System (Japan). Since the remittance fee, remittance time required, and exchange fee vary depending on the remittance method, the optimal remittance method is automatically selected. The execution of international remittance is recorded in the log together with the remittance method, remittance source account, remittance destination account, remittance amount, and remittance date and time.

[0205] <15-2. Detailed Implementation of Regulatory Compliance> This document explains how the system related to this disclosure complies with various regulations. Compliance with financial regulations, data protection regulations, consumer protection regulations, insurance business laws, road transport vehicle laws, etc., is ensured. The status of regulatory compliance is recorded in the log, along with the type of regulation addressed, the content of the response, and the date and time of the response. In response to financial regulations, we comply with registration and reporting obligations to financial supervisory authorities in each country (such as Japan's Financial Services Agency, the US SEC / CFTC, and Europe's ESMA). Because the criteria for determining whether a factoring business constitutes moneylending differ from country to country, a business scheme compliant with the laws of each country is adopted. Specifically, measures such as ensuring the reliable delivery of notices of assignment of receivables to guarantee the authenticity of the assignment, excluding recourse rights, and registering the assignment of receivables are implemented. The status of compliance with financial regulations is recorded in a log along with the name of the regulation addressed and the measures taken. To comply with data protection regulations, compliance with GDPR (EU General Data Protection Regulation), Japan's Personal Information Protection Act, and the California Consumer Privacy Act (CCPA) will be ensured. This will include obtaining explicit consent when collecting personal data, documenting the legal basis for data processing, realizing data subject rights (right to access, right to correction, right to erasure, right to data portability), conducting data protection impact assessments (DPIAs), and entering into data processor agreements. The implementation of data protection measures will be logged along with the regulations addressed, the measures taken, and the types of personal data covered. To comply with consumer protection regulations, compliance with the Specified Commercial Transactions Act, the Consumer Contract Act, the Installment Sales Act, etc., will be ensured. Measures will include providing clear explanations of contract terms, offering a cooling-off period, eliminating unfair clauses, and fulfilling disclosure obligations. Sufficient explanation periods will be provided before contract signing, contract details will be sent in writing or via email, and a consumer complaint handling desk will be established. The implementation of consumer protection measures, along with the regulations addressed and the measures taken, will be recorded in a log. As a measure to comply with the Insurance Business Act, a mechanism is ensured to prevent the recommendation or solicitation of insurance contracts in cooperation with insurance companies so as not to fall under insurance solicitation acts. In the agency business of insurance claims, the business is limited to the extent where registration as an insurance solicitor or insurance broker is not required. The status of compliance with the Insurance Business Act is recorded in the log together with the implemented countermeasures and legal grounds. As a measure to comply with the Road Transportation Vehicle Act, in the handling of vehicle identification information, measures such as preventing unauthorized use of vehicle inspection certificate information and properly managing maintenance records are implemented. The records of maintenance contents performed by repairers are properly stored as disassembly and maintenance records based on the Road Transportation Vehicle Act. The status of compliance with the Road Transportation Vehicle Act is recorded in the log together with the details of the countermeasures and the recorded maintenance information.

[0206] <15-3. Expandability to Future Technologies> The expandability of the system according to the present disclosure to future technologies will be described. A flexible design that can cope with the emergence of new technologies, changes in social infrastructure, and the evolution of business models is adopted. The implementation of expansion to future technologies is recorded in the log together with the details of the expansion and the expansion date and time. As a measure to cope with quantum computing, in preparation for the possibility that current encryption algorithms (such as RSA and ECC) may be decoded by a quantum computer, a transition to post-quantum cryptography is planned. The design enables a gradual transition to candidate algorithms such as lattice-based cryptography, code-based cryptography, and multivariate polynomial cryptography. The update of the encryption algorithm is recorded in the log together with the names of the old and new algorithms and the transition date and time. As a measure to cope with 5G / 6G communication technologies, new services that utilize an ultra-high-speed and ultra-low-latency communication environment can be provided. For example, real-time transmission and analysis of high-resolution moving images of damaged parts of a vehicle taken from multiple angles, three-dimensional visualization of damaged parts using AR (augmented reality) technology, and remote support for repair work are realized. The utilization status of 5G / 6G technologies is recorded in the log together with the communication band used, the amount of transmitted data, and the communication delay time. To address the needs of autonomous vehicles, damage detection and repair prediction will be possible using data from sensors (LIDAR, radar, cameras, etc.) installed in autonomous vehicles. By linking with the vehicle's on-board diagnostics (OBD), not only mechanical damage but also abnormalities in the electronic control system can be detected early. The utilization of autonomous vehicle data will be logged along with the type of data acquired and the analysis results. In response to the need for support for Central Bank Digital Currencies (CBDCs), if central banks in various countries issue digital currencies in the future, they will be integrated as a means of payment. Wallet integration compatible with CBDCs such as digital yen, digital dollar, and digital euro, as well as automated settlements via smart contracts, can be implemented. Digital currency settlements are logged along with the type of currency used, the settlement amount, and the date and time of the settlement. As part of its support for metaverse digital twins, the system enables the provision of vehicle trading and factoring services in a virtual space. A digital twin model of a vehicle is built in the virtual space, providing features such as damage simulation, visualization of the repair process, and virtual repair estimates. The implementation of metaverse integration is logged along with the name of the integrated platform and the services provided.

[0207] <15-4. Implementation of Disaster and Emergency Response> This disclosure describes the system's response to disasters or emergencies. Mechanisms are implemented to maintain critical functions and achieve rapid recovery even in emergencies such as natural disasters, pandemics, and system failures. The status of disaster and emergency response is recorded in the log, along with the event that occurred, the response taken, and the date and time of the response. For large-scale natural disasters, such as earthquakes, floods, and typhoons, vehicle damage in affected areas increases sharply. To address this situation, the system automatically prioritizes damage analysis requests, dynamically expands processing capacity, and switches to a simplified review mode. Affected areas are automatically identified from disaster information published by public institutions such as the Japan Meteorological Agency, user location information, and EXIF ​​information from damage images. The activation of disaster response mode is recorded in the log, along with the target area, reason for activation, and the measures taken. As a pandemic response, the system addresses situations where face-to-face operations are restricted due to the global pandemic. It provides a function to switch from in-person damage assessment between repair shops and insurance companies to remote damage assessment. This includes integrated video call functionality, guidance for remote damage inspection, and the ability to conclude contracts remotely. Implementation of the pandemic response mode is logged along with the measures taken and the duration of the response. To address system failures, recovery procedures are established for situations where the system stops due to data center failures, network failures, cyberattacks, etc. These include data replication to multiple geographically distributed data centers, automatic failover, and switching to backup sites. System failures and their recovery are logged along with the nature of the failure, its impact, and the time required for recovery. As part of our response to financial system failures, we address situations where transfer processing cannot be executed due to bank system failures. This includes automatic switching to alternative payment methods (electronic money, QR code payments, digital currencies, etc.), queuing and automatic retrying of transfer processing, and guidance on switching to manual transfers. Responses to financial system failures, including the nature of the failure and the countermeasures taken, are recorded in logs. As part of our cybersecurity incident response, we have established procedures for responding to security incidents such as unauthorized access, DDoS attacks, and ransomware infections. These procedures include systematically detecting the incident, identifying the scope of impact, blocking the attack, isolating the system, preserving evidence, notifying relevant authorities, and notifying users. A Computer Security Incident Response Team (CSIRT) is in place, and a 24 / 7 monitoring system is in place. Security incident responses, including the type of incident, the response, and the responders, are recorded in logs.

[0208] <15-5. Introduction to Industrial Applicability> The system disclosed herein is primarily intended for providing factoring services in the automotive repair industry, but its technical configuration is applicable to a wide range of industrial fields. Specific application examples demonstrating its industrial applicability are described below. The implementation status of each application example is recorded in a log, along with the target industry and the details of the implementation. One application in the construction industry is the factoring of receivables for construction machinery repairs. Repair costs are estimated from images of damage to construction machinery (bulldozers, excavators, cranes, etc.), and funds are provided immediately to construction companies. Since the downtime of construction machinery leads to delays in construction projects and significant economic losses, the rapid provision of repair funds is a critical industrial need. Applications to construction machinery are logged along with the type of machinery involved, the estimated repair cost, and the amount of funds provided. One application in the medical device industry is the factoring of medical device repair receivables. This enables rapid repairs of expensive medical equipment such as MRI, CT, and X-ray machines by providing immediate funding to repair companies in the event of malfunctions. Rapid repair is socially important because the downtime of medical equipment results in lost opportunities for patient treatment. Applications in the medical device industry are logged along with the type of equipment involved, the urgency of the repair, and the amount of funds provided. One application in the aviation industry is aircraft repair receivable factoring. This involves providing funds to repair companies for damage to aircraft fuselages, engines, avionics, etc. Since aircraft repairs require approval from aviation authorities and the repair process tends to be complex and lengthy, supporting the cash flow of repair companies is crucial. Applications to aircraft are logged along with the aircraft's registration number, repair details, and the amount of funds provided. One application in the shipping industry is ship repair receivable factoring. This involves providing funds to repair companies for damage to the ship's hull, engine, navigation equipment, etc. Ship repairs are expensive, and the inability to operate the ship during the repair period results in significant economic losses. Applications to ships are logged along with the ship's IMO number, the details of the repairs, and the amount of funds provided. One application in the real estate industry is factoring of receivables for repairs of residential equipment. This involves providing funds to repair companies for damage to equipment such as air conditioning, water heaters, and kitchen appliances. Since malfunctions in residential equipment directly impact residents' quality of life, prompt repairs are essential. Real estate applications are logged along with the type of equipment, the nature of the repair, and the amount of funds provided. Thus, the technical configuration of this disclosure is applicable to any article that sustains damage and requires repair, contributing to improved cash flow and faster repairs for repair businesses in various industries. Therefore, this disclosure has broad industrial applicability. The implementation status of cross-industry applications will be logged along with the industrial sector in which it was applied, the details of the implementation, and the results.

[0209] <16. Separate Implementation Forms of System Components> Although the system described in this disclosure was described as a single server device 100 in the embodiments described above, it is also possible to implement each component separately, either physically or logically. Such separate implementation improves the scalability, maintainability, and availability of the system. Communication between each component is recorded as a communication log.

[0210] As a first form of separate implementation, the AI ​​damage analysis unit 110 can be made independent as a dedicated analysis server. The analysis server is equipped with a high-performance GPU (Graphics Processing Unit) to perform inference processing of deep learning models at high speed. Communication between the analysis server and the main server is performed via RESTful API or gRPC. API calls to and responses to the analysis server are logged along with the date and time of the call, parameters, and processing time.

[0211] As a second form of separate implementation, database 150 can be made independent as a dedicated database server. The database server is equipped with high-speed storage (SSD, NVMe) and memory to process large amounts of data quickly. Queries and responses to the database server are logged along with the query content, execution time, and number of retrieved records.

[0212] As a third form of separate implementation, the logging unit 180 can be made independent as a dedicated log management server. The log management server aggregates and centrally manages logs sent from each processing server. Fluentd, Logstash, or a similar log collection tool is used for log aggregation. The log management server provides functions for searching, analyzing, and visualizing logs. Log transmission and reception are recorded along with the source, transmission date and time, and log size.

[0213] As a fourth form of separate implementation, the factoring processing unit 130 and the settlement processing unit 140 can be made independent as dedicated transaction servers. The transaction servers are equipped with transaction management functions, rollback functions, and double-spending prevention functions to ensure the security and reliability of financial transactions. The processing of the transaction servers is recorded in a log along with the transaction ID, start date and time, end date and time, and processing result.

[0214] <17. Implementation methods in cloud environments> The system according to the present disclosure can be implemented in a cloud computing environment. By implementing in a cloud environment, maintenance of physical server facilities becomes unnecessary, and dynamic increase and decrease of computing resources according to demand becomes possible. The startup, stop, and scaling of each instance in the cloud environment are recorded in a log.

[0215] As a first implementation form of the cloud environment, an IaaS (Infrastructure as a Service) type cloud service can be used. In an IaaS type cloud service, virtual machine instances are generated and applications are deployed thereon. The user manages the OS, middleware, and applications of the virtual machine. The generation, deletion, and setting change of the virtual machine are recorded in a log together with the execution date and time, the executor, and the instance ID.

[0216] As a second implementation form of the cloud environment, a PaaS (Platform as a Service) type cloud service can be used. In a PaaS type cloud service, an application execution environment is prepared in advance, and the user only needs to deploy the application code. The cloud service provider manages the OS and middleware. The deployment, scaling, and setting change of the application are recorded in a log together with the execution date and time, the version, and the number of instances.

[0217] As a third implementation form of the cloud environment, the entire system can be provided as a SaaS (Software as a Service) type cloud service. In a SaaS type service, the user uses the system through a web browser or a dedicated application, and the service provider manages all of the infrastructure, platform, and applications. The user's access, operation, and data processing are recorded in a log together with the user ID, session ID, operation type, and operation date and time.

[0218] Container technology can be used as a fourth implementation of cloud environments. Container technology allows applications and their dependencies to be packaged as a single container image, which can then run in any container execution environment. Docker, containerd, or similar container runtimes are used as container technologies. Container builds, deployments, starts, and stops are logged along with the container ID, image name, version, and execution date and time.

[0219] Container orchestration technology can be used as a fifth implementation of cloud environments. Container orchestration technology automatically deploys, scales, and manages multiple containers. Kubernetes, Docker Swarm, or similar orchestration tools are used as container orchestration technologies. The deployment, scaling, health checks, and automatic recovery of containers through orchestration are logged along with node IDs, pod names, replica counts, and execution dates and times.

[0220] <18. Implementation using a microservices architecture> The system described in this disclosure can be implemented as a microservices architecture. In a microservices architecture, the entire system is divided into multiple smaller services, each of which is developed, deployed, and scaled independently. Communication between each service is logged.

[0221] As the primary service in the microservices architecture, a VIN decoding service can be provided. The VIN decoding service is an independent API service that takes a VIN as input and outputs vehicle information. API calls to and responses to the VIN decoding service are logged along with the calling service ID, VIN, response content, and processing time.

[0222] A damage detection service can be provided as a second service in the microservices architecture. The damage detection service is an independent API service that takes damaged images as input and outputs the detected damaged areas and the extent of the damage. API calls to and responses to the damage detection service are logged along with the calling service ID, image hash value, detection result, and processing time.

[0223] As a third service in the microservices architecture, a repair cost estimation service can be provided. The repair cost estimation service is an independent API service that takes vehicle information and damage information as input and outputs an estimated repair cost. API calls to and responses to the repair cost estimation service are logged along with the calling service ID, input parameters, estimation result, and processing time.

[0224] As a fourth service in the microservices architecture, a risk scoring service can be provided. The risk scoring service is an independent API service that accepts inputs such as repair company ID, insurance company ID, estimated repair cost, and estimated price, and outputs an integrated risk score and purchase conditions. API calls to and responses to the risk scoring service are logged along with the calling service ID, input parameters, scoring result, and processing time.

[0225] As the fifth service in the microservices architecture, a factoring transaction service can be provided. The factoring transaction service is an independent service that handles factoring applications, acceptance of applications, and immediate payment processing. The processing of the factoring transaction service is logged along with the transaction ID, applicant ID, transaction amount, and processing date and time.

[0226] As the sixth service in a microservices architecture, a settlement service can be provided. The settlement service is an independent service that performs deposit detection, matching, and settlement processing. The settlement service's processing is logged along with the transaction ID, deposit amount, settlement amount, and processing date and time.

[0227] A notification service can be provided as the seventh service in a microservices architecture. The notification service is an independent service that centrally manages notifications at each processing stage and executes the sending of push notifications, emails, or SMS messages. The processing of the notification service is logged along with the notification type, recipient, date and time of sending, and delivery result.

[0228] Inter-service communication in a microservices architecture is performed via synchronous or asynchronous communication. Synchronous communication uses RESTful APIs, gRPC, or GraphQL. Asynchronous communication uses message queues or event streaming. All inter-service communication is logged along with the source service ID, destination service ID, hash value of the message content, and date and time of transmission.

[0229] <19. Integrated management via API gateway> In a microservices architecture, an API gateway is used to centrally manage access to multiple services. The API gateway receives requests from clients, routes them to the appropriate backend service, and returns responses to the client. All communication through the API gateway is logged.

[0230] The primary function of an API gateway is authentication and authorization. The API gateway verifies client requests using API keys, OAuth 2.0 tokens, JWTs (JSON Web Tokens), or similar authentication information. If authentication fails, the request is rejected. The authentication and authorization results are logged along with the client ID, authentication method, authentication result, and processing date and time.

[0231] The second function of the API Gateway is rate limiting. The API Gateway limits the number of requests per client or per API endpoint per unit of time. Requests that exceed the rate limit are rejected with a predetermined HTTP status code (e.g., 429 Too Many Requests). The application of rate limiting is logged along with the client ID, number of requests, limit value, and processing date and time.

[0232] A third function of the API Gateway is load balancing. When multiple backend service instances exist, the API Gateway distributes requests across each instance. Distribution algorithms used include round-robin, minimum connection count, IP hashing, or similar algorithms. The load balancing results are logged along with the selected instance ID and processing time.

[0233] The fourth function of the API Gateway is caching. The API Gateway caches responses from frequently accessed resources, reducing the load on backend services. The cache expiration time is set according to the type of resource. Cache hit and miss rates are aggregated and logged for each endpoint.

[0234] The fifth function of the API Gateway is request-response conversion. The API Gateway converts requests when the format of the client request differs from the format expected by the backend service. Similarly, it converts responses from backend services to the format expected by the client. The execution of conversion processes is logged along with the conversion rules, the data size before and after conversion, and the date and time of processing.

[0235] <20. Implementation using an event-driven architecture> The system described herein can be implemented as an event-driven architecture. In an event-driven architecture, each process is driven by the occurrence of an event. The issuance and consumption of events are logged along with the event type, issuer, recipient, and issuance date and time.

[0236] The first event in the event-driven architecture is the "damage information input completion event." This event is issued when the insurance policyholder or repair company has completed inputting damage information. Upon receiving this event, the AI ​​damage analysis service starts the AI ​​damage analysis process. The issuance and receipt of events are logged along with the inputter ID, the hash value of the input content, and the date and time of issuance.

[0237] The second event in the event-driven architecture is the "AI damage analysis completion event." This event is issued when the AI ​​damage analysis process is complete. Upon receiving this event, the risk scoring service begins the risk scoring process. The issuance and receipt of events are logged along with the analysis results, estimated repair costs, confidence level, and issuance date and time.

[0238] The third event in the event-driven architecture is the "risk scoring completion event." This event is issued when the risk scoring process is complete. Upon receiving this event, the notification service sends a buyback offer notification to the repair company. The issuance and receipt of events are logged along with the integrated risk score, buyback rate, commission rate, and issuance date and time.

[0239] The fourth event in the event-driven architecture is the "factoring acceptance event." This event is issued when a repair company accepts the purchase terms. Upon receiving this event, the factoring transaction service immediately begins processing the payment. The issuance and receipt of the event are logged along with the acceptor ID, transaction ID, and acceptance date and time.

[0240] The fifth event in the event-driven architecture is the "insurance payment detection event." This event is issued when an insurance payment is detected via a webhook from a financial institution. Upon receiving this event, the settlement service initiates the automated settlement process. The issuance and receipt of the event are logged along with the payment amount, payment date and time, and payer information.

[0241] In an event-driven architecture, event delivery is handled by either a message queue or an event streaming platform. Message queues may include RabbitMQ, Amazon SQS, or similar message queuing systems. Event streaming platforms may include Apache Kafka, Amazon Kinesis, or similar streaming platforms. Event delivery is logged along with the destination, delivery date and time, and delivery status.

[0242] <21. Details of Database Access Patterns> This document describes the access patterns to database 150 in the system related to this disclosure. Access to the database is logged along with the access type (read, write, update, delete), the table accessed, the date and time of access, and the access source service ID.

[0243] Access to the vehicle master DB151 primarily occurs during VIN decoding. Queries are executed to retrieve vehicle information using the VIN as the key. Although the vehicle master DB151 is frequently read, writes are only made when updating vehicle information; therefore, a read-optimized index is set up. Access is logged along with the search conditions, the number of records retrieved, and the processing time.

[0244] Access to the parts price database (DB152) occurs during the repair cost estimation process. A query is executed to retrieve the price of the part corresponding to the damaged area. Since parts prices may vary depending on the region and supplier, multiple records may exist. The query retrieves multiple parts price records and calculates the average, minimum, and maximum values. Access is logged along with the search criteria, the number of records retrieved, and the calculation results.

[0245] Access to the labor cost table 153 occurs during the repair cost estimation process. A query is executed to retrieve work items and standard labor hours corresponding to the damaged area and extent of the damage. Since labor costs may vary depending on the region and repair company, multiple records may exist. The query retrieves multiple labor cost records and calculates the average. Access is logged along with the search criteria, the number of records retrieved, and the calculation result.

[0246] Access to the repair vendor performance data 154 occurs during the risk scoring process. A query is executed to search for past transaction history using the repair vendor ID as the key. The search results include the number of transactions, average repair completion time, repair completion rate, and complaint rate. Access is logged along with the repair vendor ID, the number of items retrieved, and the aggregated results.

[0247] Access to insurance company payment history data 155 occurs during the risk scoring process. A query is executed to search for past payment history using the insurance company ID as the key. The search results include the number of payments, average payment days, payment completion rate, reduction rate, etc. Access is logged along with the insurance company ID, the number of records retrieved, and the aggregated results.

[0248] Access to the factoring transaction database (DB156) occurs during factoring transaction processing and settlement. Transaction records are created, their status updated, and searches are performed. Transaction records include fields such as transaction ID, applicant ID, transaction amount, integrated risk score, purchase rate, commission rate, status, creation date and time, and update date and time. Access is logged along with the operation type, transaction ID, and changes made.

[0249] Access to the audit log DB157 occurs continuously by the logging unit 180. New log records are created and searches are performed. Because the audit log DB157 experiences frequent writes, write-optimized settings are applied. In addition, to prevent log data from becoming excessively large, logs are compressed or archived after a certain period of time. Access is recorded in the log along with the number of write logs, search conditions, and the number of retrieved records.

[0250] <22. Details of Transaction Management> This section describes transaction management in the system related to this disclosure. A transaction is a mechanism that treats multiple database operations as a single, indivisible unit. The start, commit, and rollback of a transaction are recorded in the log along with the transaction ID, execution date and time, and execution result.

[0251] A transaction in factoring transaction processing involves the following operations: First, creating a transaction record in factoring transaction DB156; second, issuing a transfer instruction to repairer account 300A; and third, executing a withdrawal process from escrow account 500. These operations must either all succeed or all fail; partial execution is not permitted. Transaction execution is logged along with the status of each operation.

[0252] Transaction isolation levels include READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. The choice of isolation level is determined based on a balance between data consistency and processing performance. READ COMMITTED is typically used, but SERIALIZABLE is used for processes requiring high consistency. The isolation level setting is logged for each transaction.

[0253] If an error occurs during transaction execution, a rollback process is performed. The rollback process reverts the transaction to its state at the start. The execution of the rollback is logged along with the error details and the date and time of the rollback. After the rollback, an error notification is sent to the relevant parties, and manual action is requested.

[0254] When distributed transactions are required, either two-phase commit (2PC) or the Saga pattern is used. In two-phase commit, a commit readiness request is sent to all participants, and after all participants respond that they are ready, a commit execution request is sent. In the Saga pattern, the execution and compensation operations for each step are defined, and in case of failure, the compensation operations restore the state. The execution of distributed transactions is logged along with the execution status of each phase.

[0255] <23. Details of Security Measures> This section describes the security measures in the system related to this disclosure. Security measures are important to ensure the reliability and safety of the system. Security-related operations are logged along with the operation type, executor ID, execution date and time, and execution result.

[0256] The primary security measure is communication encryption. Communication between server device 100 and each terminal device, escrow account 500, and financial institution 600 is encrypted using TLS (Transport Layer Security). TLS 1.2 or higher is used. TLS 1.0 and TLS 1.1 are not used due to known vulnerabilities. The establishment of a TLS connection is logged along with the source, destination, TLS version, and cipher suite.

[0257] The second security measure is enhanced authentication. In addition to password authentication, multi-factor authentication (MFA) is used for user authentication. Multi-factor authentication can be performed using one-time passwords sent via SMS, TOTP (Time-based One-Time Password) via an authentication app, or hardware tokens. Authentication is logged along with the authentication method, authentication result, and date and time of authentication.

[0258] A third security measure is stricter authorization. Users are granted access rights based on their roles. Roles include administrator, repair technician, insurance company, and policyholder. Each role has defined operations it can perform. Authorization decisions are logged along with the user ID, role, requested operation, and decision result.

[0259] The fourth security measure is data encryption. Personal and confidential information stored in database 150 is encrypted. The AES (Advanced Encryption Standard) 256-bit encryption algorithm is used. Encryption keys are managed by a dedicated Key Management System (KMS). Data encryption and decryption are logged along with the data type, operation type, and execution date and time.

[0260] The fifth security measure is vulnerability assessment. Vulnerability assessments are conducted on the system on a regular basis. These assessments check for known vulnerabilities, configuration errors, and application-level vulnerabilities. The implementation of vulnerability assessments is logged along with the date and time of the assessment, the scope of the assessment, and the number and severity of vulnerabilities found.

[0261] The sixth security measure is intrusion detection. To detect attempts at unauthorized access to the system, an IDS (Intrusion Detection System) or IPS (Intrusion Prevention System) is implemented. The IDS or IPS monitors network traffic or system logs and detects abnormal patterns. Detected anomalies are logged along with the date and time of detection, the type of anomaly, and the source IP address, and the administrator is notified.

[0262] <24. Details of Backup and Disaster Recovery> This disclosure describes backup and disaster recovery in the system. Backup and disaster recovery are important for ensuring system availability and business continuity. Backup and disaster recovery are logged along with the execution date and time, execution result, and backup size.

[0263] The primary backup method is a full backup. A full backup replicates all data in database 150. Full backups are performed regularly (e.g., every night). The execution of a full backup is logged along with the start date and time, end date and time, backup size, and storage location.

[0264] A second backup method is incremental backup. Incremental backups only replicate data that has changed since the last backup. Incremental backups are performed more frequently than full backups (e.g., hourly). Each incremental backup is logged, including its start and end times, backup size, and storage location.

[0265] A third backup method is differential backup. In a differential backup, data that has changed since the last full backup is replicated. While differential backups are easier to recover from than incremental backups, they result in larger backup sizes. The execution of a differential backup is logged along with its start and end dates and times, backup size, and storage location.

[0266] Multiple geographically separated locations are used to store backup data. This allows data to be recovered from other locations even if a disaster occurs in one location. On-premises storage, cloud storage, or a combination of both are used as backup data storage locations. Backup data storage is logged along with the storage location, date and time of storage, and the results of data integrity verification.

[0267] As disaster recovery goals, Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are set. RTO is the acceptable time from the occurrence of a disaster until the system is restored. RPO is the acceptable range (time) of data loss in the event of a disaster. In this system, the target RTO is set to within 24 hours and the target RPO is set to within 1 hour. The achievement status of RTO and RPO is periodically evaluated and recorded in a log.

[0268] As part of the disaster recovery procedures, a Disaster Recovery Plan (DRP) is developed. The DRP outlines recovery procedures, responsible parties, contact information, and necessary resources for each type of disaster. The DRP is reviewed and updated regularly. DRP reviews and updates are logged along with the date and time of implementation and the changes made.

[0269] As part of disaster recovery training, recovery tests are conducted regularly. These tests involve actually performing the procedure to restore the system from backup data, and verifying that the RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are achieved. The execution of recovery tests, including the date and time, test scope, and test results, are recorded in a log.

[0270] <25. Performance Optimization Details> This document describes the performance optimization of the system related to this disclosure. Performance optimization is important for reducing system response time and improving processing capacity. The implementation of performance optimization is recorded in a log along with the date and time of implementation, the optimization details, and the optimization results.

[0271] The primary method for performance optimization is database query optimization. Appropriate indexes are set for frequently executed queries. Index settings significantly reduce query execution time. Query execution plans are analyzed to identify inefficient processes. Query optimization is logged along with execution time before and after optimization, and index settings.

[0272] A second performance optimization technique involves using caching. Frequently accessed data is cached in memory. Redis, Memcached, or similar in-memory data stores are used as the cache. Cache hit and miss rates are monitored, and cache settings are adjusted accordingly. Cache usage is logged along with the cache key, hit rate, miss rate, and execution date and time.

[0273] A third method for performance optimization is the use of asynchronous processing. Time-consuming processes (e.g., AI damage analysis) are executed asynchronously. Asynchronous processing allows users to continue other operations without waiting for the process to complete. The execution of asynchronous processes is logged along with the job ID, start date and time, end date and time, and execution results.

[0274] A fourth technique for performance optimization is the use of parallel processing. Multiple independent processes are executed in parallel. Parallel processing reduces the overall processing time. For example, the analysis of multiple damaged images is performed in parallel. The execution of parallel processing is logged along with the degree of parallelism, the execution time of each process, and the overall execution time.

[0275] A fifth method for performance optimization is the use of a CDN (Content Delivery Network). Static content (images, CSS, JavaScript, etc.) is delivered via a CDN. A CDN ensures that content is delivered from a geographically closer location to the user, improving delivery speed. CDN usage is logged along with the delivered content, origin, destination, and delivery date and time.

[0276] <26. Monitoring and Alerting Details> This section describes the monitoring and alerting features in the system related to this disclosure. Monitoring and alerting are important for early detection of system anomalies and enabling rapid response. Monitoring data and alert issuance are logged along with the monitoring item, monitoring value, threshold, and issuance date and time.

[0277] The primary monitoring item is server resource utilization. CPU utilization, memory utilization, disk utilization, and network utilization are monitored. If utilization exceeds a predetermined threshold, an alert is issued. Resource utilization is recorded periodically (e.g., every minute) and stored as time-series data.

[0278] The second monitoring item is application response time. The response time of each API endpoint is monitored. If the response time exceeds a predetermined threshold, an alert is issued. Response times are aggregated for each API endpoint, and the average, minimum, maximum, and percentile values ​​are calculated.

[0279] The third monitoring item is the error rate. The number and rate of errors in each process are monitored. If the error rate exceeds a predetermined threshold, an alert is issued. Errors are classified by error type, and frequently occurring errors are identified.

[0280] The fourth monitoring item is the number of database connections. The number of simultaneous connections to the database is monitored. If the number of connections approaches the maximum number of connections, an alert is issued. The trend in the number of connections is analyzed, and peak times are identified.

[0281] The fifth monitoring item is the availability of external services. The availability of 600 APIs and webhooks for financial institutions is monitored. If an external service is unresponsive or returns an error, an alert is issued. The availability of external services is checked and recorded regularly (e.g., every 5 minutes).

[0282] Alerts can be sent to the administrator's email address, SMS phone number, or chat tool (such as Slack or Microsoft Teams). Alerts can be assigned a severity level (Critical, Warning, Info, etc.), and the notification method changes depending on the severity level. Critical-level alerts are notified immediately by phone or SMS.

[0283] <27. Details of A / B testing and phased deployment> This disclosure describes A / B testing and phased deployment in the system. A / B testing and phased deployment are used to safely introduce new features or change algorithms. The execution of A / B testing and phased deployment is logged along with the date and time of execution, the target users, and the results.

[0284] In A / B testing, users are randomly assigned to either Group A or Group B. Group A is subjected to the existing algorithm (control), while Group B is subjected to the new algorithm (variant). The results of each group are compared, and the effectiveness of the new algorithm is evaluated. User group assignments are logged along with the user ID, group, and assignment date and time.

[0285] Evaluation metrics for A / B testing include estimation accuracy, processing time, user satisfaction, and transaction completion rate. For each metric, the average values ​​for Group A and Group B are calculated, and statistical significance is tested. If a statistically significant difference is found, the implementation of the new algorithm is decided. The evaluation results of the A / B test are logged along with the evaluation metrics, Group A values, Group B values, and statistical significance.

[0286] In a phased rollout, the new feature is initially provided to only a portion of users (e.g., 5%). After confirming that the new feature is functioning stably, the rollout is gradually expanded (e.g., 10%, 25%, 50%, 100%). At each stage, the new feature's operation is monitored, and the rollout is stopped if any problems are detected. The progress of the phased rollout is logged, along with the rollout percentage, rollout date and time, and rollout results.

[0287] Feature flags are used as a rollback mechanism in phased deployments. Feature flags are a function that dynamically switches between enabling and disabling new features. If a problem is detected, disabling the feature flag allows for immediate reverting to the old functionality. The switching of feature flags is logged along with the date and time of the switch, the person who performed the switch, and the reason for the switch.

[0288] <28. Detailed Implementation of User Interface> This section describes the user interface details of the system related to this disclosure. The user interface is provided as a web application, a mobile application, or a combination thereof. Operations within the user interface are logged along with the operation type, date and time, and result.

[0289] In implementing web applications, React, Vue.js, Angular, or similar frameworks are used as front-end frameworks. The front-end application is configured as a single-page application (SPA), where content is dynamically updated without page transitions. Communication between the front-end and back-end is performed via RESTful APIs or GraphQL.

[0290] In the implementation of mobile applications, either native applications or cross-platform applications are used. Native applications use Swift or Objective-C for iOS, and Kotlin or Java for Android. Cross-platform applications use frameworks such as React Native, Flutter, or similar frameworks.

[0291] The user interface's responsive design ensures proper display across various screen sizes on devices (smartphones, tablets, desktops). Responsive design implementation utilizes CSS media queries, flexible grid layouts, and relative units (such as %), em, and rem.

[0292] The user interface will be designed in accordance with WCAG (Web Content Accessibility Guidelines) for accessibility. Accessibility considerations include keyboard support, screen reader compatibility, sufficient color contrast, and font size adjustment capabilities.

[0293] Input validation in the user interface is performed on both the client and server sides. Client-side validation allows users to receive immediate feedback. Server-side validation rejects invalid input that bypasses client-side validation. The execution of input validation is logged along with the validation items, validation results, and validation date and time.

[0294] <29. Details of integration with external systems> This section explains the integration between the system related to this disclosure and external systems. Integration with external systems expands the system's functionality and improves user convenience. Communication with external systems is logged along with the communication content, date and time, and results.

[0295] The primary form of external system integration is integration with insurance company systems. This integration automates the inquiry of insurance policy information, the confirmation of insurance claim status, and the receipt of payment notifications. Communication with insurance company systems is conducted via API or EDI (Electronic Data Interchange). The communication includes information such as insurance policy numbers, policyholder information, insurance amounts, and payment status.

[0296] The second form of external system integration is integration with the parts supplier system. This integration automates parts inventory inquiries, price inquiries, and ordering. Communication with the parts supplier system is conducted via API or batch retrieval of catalog data. The communication includes information such as part number, inventory quantity, price, and delivery date.

[0297] A third form of external system integration is integration with credit information agencies. This integration automates the credit check of repair companies. The results of the credit check are used for risk scoring. Communication with credit information agencies is conducted via a dedicated API and is encrypted. The communication includes the repair company's corporate number, credit score, and default history.

[0298] The fourth form of external system integration is integration with map services. This integration automates the acquisition of repair shop location information, route searching, and distance calculation. The map service used will be Google Maps API, Mapbox API, or a similar service. Communication content will include address, latitude and longitude, and route information.

[0299] A fifth form of external system integration is integration with an SMS sending service. Through this integration, notifications are sent to users via SMS. The SMS sending service used may include Twilio, Amazon SNS, or similar services. The communication content includes the recipient's phone number, message body, and transmission result.

[0300] For authentication in external system integration, API key authentication, OAuth 2.0, or mutual TLS authentication are used. Authentication information is securely stored and regularly updated. To prevent the leakage of authentication information, it is not hardcoded but retrieved from environment variables or a dedicated secret management system.

[0301] As error handling for external system integration, a retry process is implemented. If communication with an external system fails due to a temporary network error, retries are performed up to a predetermined number of times. The retry interval is determined by an exponential backoff algorithm. The execution of retries is recorded in the log along with the number of retries, the retry interval, and the execution result.

[0302] To address rate limiting in external system integration, calls are made in accordance with the API usage limits of the external system. The frequency of calls is controlled to prevent exceeding the API usage limit. If the API usage limit is reached, the system waits for a predetermined period before attempting to make another call. The API call control status, including the number of calls, the limit value, and the waiting time, is logged.

[0303] <30. Continuous Improvement of Data Analysis and Machine Learning Models> This disclosure describes the continuous improvement of data analysis and machine learning models in the system related to this disclosure. Continuous improvement enhances the accuracy of AI damage analysis and risk scoring. Data analysis and model updates are logged along with the date and time of implementation, analysis results, and update details.

[0304] The first item in the data analysis is the performance evaluation of the damage detection model 111. The output results of the damage detection model are compared with the damaged areas and extent of damage actually confirmed by the repair shop, and accuracy, recall, and F-score are calculated. Damage types or vehicle types with reduced performance are identified, and additional training data is collected.

[0305] The second item in the data analysis is the evaluation of the accuracy of the repair cost estimate. The estimated repair cost is compared with the actual repair cost, and the mean, median, and standard deviation of the error are calculated. Damage types or vehicle types with large errors are identified, and the parts price DB152 or labor cost table 153 is updated.

[0306] The third aspect of data analysis is evaluating the accuracy of risk scoring. The integrated risk score is compared with the actual recovery rate, and a correlation coefficient is calculated. If the correlation is low, the weighting coefficient table 121 is re-optimized. Historical transaction data is used for optimization to calculate the weighting coefficients that maximize the recovery rate.

[0307] Online training is used as a method for continuously improving machine learning models. In online training, the model is updated whenever new data becomes available. This ensures the model adapts to the latest data and maintains accuracy. The execution of online training is logged along with the number of training data points, training results, and model version.

[0308] Another method for continuously improving machine learning models is periodic retraining. In periodic retraining, the model is retrained using accumulated data at predetermined intervals (e.g., every month). Retraining adapts the model to the latest data distribution, improving its accuracy. Each retraining session is logged along with the number of training data points, the training period, and a comparison of the performance of the old and new models.

[0309] <31. Modified Embodiments of AI Damage Analysis> Although the AI ​​damage analysis unit 110 described in this disclosure uses a damage detection model 111 in the above-described embodiment, various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the execution result.

[0310] One of the primary variations of AI damage analysis is ensemble learning, which combines multiple damage detection models. Ensemble learning integrates the outputs of multiple models trained on different architectures or different training data. Integration methods include majority voting, mean averaging, weighted averaging, or stacking (integration using meta-learners). The execution of ensemble learning is logged along with the number of models used, the output of each model, and the integration result.

[0311] A second variant of AI damage analysis involves constructing damage detection models using transfer learning. Transfer learning uses a model pre-trained on a large image dataset such as ImageNet, and then fine-tunes it on a damaged image dataset. Pre-trained models such as ResNet, EfficientNet, Vision Transformer, or similar models are used. The execution of transfer learning is logged along with the pre-trained model used, the fine-tuning settings, and the learning results.

[0312] A third variant of AI damage analysis involves detecting damaged areas using semantic segmentation. Semantic segmentation classifies each pixel in an image as either a damaged area or not, thereby identifying the precise shape and extent of the damage. Semantic segmentation models such as U-Net, DeepLab, Mask R-CNN, or similar models are used. The execution of semantic segmentation is logged along with the mask image and area of ​​the detected damaged region.

[0313] A fourth variant of AI damage analysis involves determining the extent of damage using depth estimation. Depth information is estimated from the damage image, and the degree of surface irregularities at the damaged area is quantified. Monocular depth estimation models (such as MiDaS and DPT) are used as the depth estimation model. The execution of depth estimation is logged along with the estimated depth map, the maximum and average values ​​of the surface irregularities.

[0314] A fifth variant of AI damage analysis involves damage analysis utilizing 3D models. Damage images taken from multiple angles are used to reconstruct a 3D model of the damaged area. From the 3D model, the volume, surface area, and amount of material required for repair are estimated. Structure from Motion (SfM), Multi-View Stereo (MVS), or Neural Radiance Fields (NeRF) are used for 3D model reconstruction. The generation of the 3D model is logged along with the number of images used, the number of reconstructed point clouds, and the estimated damage volume.

[0315] A sixth variation of AI damage analysis involves damage analysis utilizing video footage. Multiple frames are extracted from video footage captured by the user while walking around the vehicle, and damage detection is performed on each frame. The detection accuracy is improved by integrating the detection results from multiple frames. Frame extraction from video footage is recorded in a log along with the frame rate and the number of frames extracted.

[0316] A seventh variant of AI damage analysis involves damage analysis utilizing text information. A user-entered text-based damage description (e.g., "a large dent on the right side of the front bumper") is analyzed using natural language processing to provide clues about the location and extent of the damage. Integrating text and image information improves analysis accuracy. BERT, GPT, or similar language models are used for natural language processing. The text analysis, along with the input text, extracted keywords, and estimated damage location, is recorded in a log.

[0317] An eighth variant of AI damage analysis involves damage analysis utilizing past repair history. If past repair history for the same vehicle exists in the database, this information is referenced to improve the accuracy of damage location estimation. For example, if the same part has been repaired in the past, that part is estimated to have a high risk of damage. The reference to past repair history is recorded in a log along with the number of history entries referenced and the information obtained from the history.

[0318] <32. Methods for expanding training data of damage detection models> In training the damage detection model 111, data augmentation is used to increase the diversity of the training data. Data augmentation improves the model's generalization performance and enhances its accuracy on unknown data. The execution of data augmentation is logged along with the augmentation method and the number of data points before and after augmentation.

[0319] The primary method of data augmentation is geometric transformation. Geometric transformations include rotation, translation, scaling, inversion, shearing, or combinations thereof. These transformations allow for the simulation of damage images taken from various angles and positions. The parameters of the geometric transformation are determined randomly or varied within a predetermined range.

[0320] A second method of data augmentation is color transformation. Color transformations include brightness adjustment, contrast adjustment, saturation adjustment, hue adjustment, or a combination of these. These transformations can simulate damaged images taken under various lighting and weather conditions. The parameters for color transformation are determined randomly or vary within a predetermined range.

[0321] A third data augmentation technique is noise addition. Gaussian noise, salt-and-pepper noise, speckle noise, or a combination of these can be used for noise addition. These noises can simulate damaged images taken with low-quality cameras or in adverse weather conditions. The noise parameters (intensity, distribution, etc.) are determined randomly or vary within a predetermined range.

[0322] A fourth data augmentation technique is cropping and padding. By cropping a portion of an image or adding padding around it, it is possible to simulate damaged images with various framings. The position and size of the cropping and the size of the padding are determined randomly or vary within a predetermined range.

[0323] A fifth data augmentation technique is advanced augmentation methods such as Cutout, Mixup, and CutMix. Cutout randomly masks a portion of an image. Mixup blends two images. CutMix replaces a portion of one image with a portion of another. These techniques improve the robustness of the model. The execution of advanced augmentation techniques is logged along with the technique and parameters used.

[0324] <33. Modified Embodiments of Repair Cost Estimation> In the embodiment described above, the repair cost estimation process in the AI ​​damage analysis unit 110 of this disclosure refers to a configuration that references the parts price DB 152 and the labor cost table 153, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the estimation result.

[0325] A first variant of repair cost estimation is direct estimation using a machine learning model. A regression model is used that takes damage images and vehicle information as input and directly outputs the repair cost. Linear regression, decision tree regression, random forest regression, gradient boosting regression, or neural network regression can be used as the regression model. The regression model is trained using past pairs of damage images and actual repair costs. The execution of the regression model is logged along with the input data, the output estimated repair cost, and the model's confidence level.

[0326] A second variation of repair cost estimation involves estimation through similarity search. This method searches a database for past damage cases similar to the input damage image and references the repair costs of those cases. Similarity is calculated using the distance between the image feature vectors (e.g., Euclidean distance, cosine similarity). If multiple similar cases are found, the mean, median, or weighted mean of their repair costs is used as the estimated repair cost. The execution of the similarity search is logged along with the number of cases found, the similarity score for each case, and the estimated repair cost.

[0327] A third variation of repair cost estimation involves estimation that considers the choice of repair method for each part. Depending on the damaged location and extent of the damage, replacement, sheet metal repair, paint repair, or a combination thereof is selected. The cost of each repair method is calculated, and the method with the lowest cost is selected. Alternatively, the costs of multiple repair methods are presented, and the user makes a selection. The selection of the repair method is logged along with the selected method, the cost of each method, and the reason for the selection.

[0328] A fourth variation of repair cost estimation involves estimation that takes regional differences into account. Parts prices and labor costs may vary by region. Based on the location of the repair shop or the vehicle, parts prices and labor costs for the relevant region are referenced. The consideration of regional differences is logged along with the referenced region and the price differences for each region.

[0329] A fifth variation of repair cost estimation involves estimation that takes time fluctuations into account. Parts prices and labor costs may fluctuate over time. The latest price information at the time of estimation is referenced, or future prices are predicted based on past price trends. The consideration of time fluctuations is logged along with the referenced time and the rate of price change.

[0330] A sixth variation of repair cost estimation involves integrating quotes from multiple repair companies. Quote requests are sent to multiple repair companies, and the quoted amounts from each company are collected. The average, minimum, and maximum values ​​of the collected quotes are calculated and used as the estimated repair cost. The integration of multiple quotes is logged along with the number of quote requests, the number of responses, and the individual quote amounts.

[0331] <34. Modified Embodiments of Risk Scoring> In the risk score calculation unit 120 described in this disclosure, the risk scoring process is configured to calculate five risk scores (SC1 to SC5) and sum them up with weights, as described in the above embodiment. However, various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the calculated scores.

[0332] One of the primary variations of risk scoring is score calculation using machine learning models. A machine learning model is used that takes the values ​​of each risk factor as input and directly outputs an integrated risk score. The machine learning model could be logistic regression, support vector machine, random forest, gradient boosting, or a neural network. The machine learning model is trained using pairs of historical transaction data and recovery results. The execution of the machine learning model is logged along with the input data, output score, and model version.

[0333] A second variation of risk scoring involves a method that combines it with rule-based judgment. In addition to calculating an integrated risk score, rules are applied that automatically reject factoring or reduce the purchase rate if certain conditions are met. Examples of rules include when a repair company's past default rate exceeds a predetermined threshold, when an insurance company's payment delay rate exceeds a predetermined threshold, or when the discrepancy between the estimated price and the estimated repair cost exceeds a predetermined threshold. The execution of rule-based judgments is logged along with the applied rules and the judgment results.

[0334] A third variation of risk scoring involves integrating external credit information. This method involves obtaining financial information, credit ratings, or default history of repair companies from external credit information agencies and using them for risk scoring. External credit information could include company information from Teikoku Databank, Tokyo Shoko Research, or bank credit ratings. The acquisition of external credit information is logged along with the source, date and time of acquisition, and the information obtained.

[0335] A fourth variation of risk scoring involves considering the risk classification of insurance companies. Payment speed and certainty may vary among insurance companies. Insurance companies are classified by risk level (e.g., high risk, medium risk, low risk), and a payment certainty score corresponding to each risk level is used. The risk classification of insurance companies, along with the classification criteria and the classification results for each insurance company, are recorded in a log.

[0336] A fifth variation of risk scoring involves a method for dynamically estimating the residual value of a vehicle. The residual value of a vehicle fluctuates depending on factors such as make, model year, mileage, and market trends. This method estimates the current residual value of a vehicle by referencing real-time used car market data. Used car market data used may include auction winning bids, listing prices on used car sales websites, or statistical data of these. The residual value estimate is logged along with the referenced data source, the estimated value, and the estimated date and time.

[0337] A sixth variation of risk scoring involves considering seasonality. Repair demand and insurance claims may fluctuate seasonally. For example, snow-related accidents increase in winter, leading to increased repair demand. Seasonal risk coefficients are set and multiplied by the integrated risk score. The seasonality consideration is logged along with the season applied and the seasonal coefficient.

[0338] <35. Variant Implementations of Determining Purchase Conditions> In the above embodiment, the determination of purchase conditions in the risk score calculation unit 120 relating to this disclosure was described as referring to the purchase rate table 122, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the determined purchase conditions.

[0339] One variation of determining purchase terms is dynamic purchase rate determination. The purchase rate is dynamically determined by considering the current factoring balance, available funds, market interest rates, or competitor purchase rates, in addition to the integrated risk score. Linear, nonlinear, or machine learning models are used as the formula for determining the purchase rate. The dynamic purchase rate determination is logged along with the factors considered, the values ​​of each factor, and the determined purchase rate.

[0340] A second variation of determining purchase conditions involves setting a tiered purchase rate. For high-value cases where the estimated amount exceeds a predetermined threshold, the purchase rate is gradually reduced. For example, the purchase rate might be 90% up to 1 million yen, and 80% for the portion exceeding 1 million yen. The application of the tiered purchase rate is recorded in the log along with the applied threshold, the purchase rate at each stage, and the final average purchase rate.

[0341] A third variation of determining purchase conditions involves the individual setting of commission rates. Commission rates are set independently of the purchase rate. Commission rates are determined based on the transaction amount, the complexity of the process, or the business relationship with the repairer. For example, repairers with long-term business relationships may receive preferential commission rates. The determination of commission rates, along with the factors considered and the determined commission rate, is logged.

[0342] A fourth variation of determining purchase conditions involves presenting multiple purchase conditions. Instead of a single purchase condition, multiple options are presented to the repair shop. For example, both a condition with a high purchase rate and high commission, and a condition with a low purchase rate and low commission, are presented, and the repair shop makes a selection. The presentation of multiple conditions is recorded in a log along with the number of conditions presented, the content of each condition, and the repair shop's selection result.

[0343] A fifth variation of determining purchase conditions is conditional purchase. Factoring is performed or the purchase rate is increased only if certain conditions are met. Examples of conditions include the repair company regularly reporting on the progress of repairs, submitting before-and-after photos of the damaged area, or obtaining payment schedule notices from the insurance company. The setting of conditional purchases is logged along with the set conditions and whether those conditions have been met.

[0344] <36. Modified Forms of Factoring Transactions> Although the factoring transaction processing in the factoring processing unit 130 related to this disclosure was described in the above embodiment as having a configuration for immediate payment, various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the execution result.

[0345] One variation of factoring transactions is installment payments. Instead of receiving the full amount of the immediate payment all at once, the payment is made in multiple installments. For example, 50% is paid when the repair begins and the remaining 50% is paid when the repair is completed. Installment payments improve the cash flow of the repair company and reduce the risk for the factoring company. The execution of installment payments is logged along with the amount and date of each payment.

[0346] A second variation of factoring transactions is revolving factoring. Repair companies are given a predetermined credit limit, which they can use repeatedly within. Once each factoring transaction is settled, the used limit is restored and becomes available again. Revolving factoring allows repair companies to use factoring quickly without undergoing a separate credit check each time. The credit limit setting and usage are logged along with the repair company ID, credit limit, amount used, and remaining balance.

[0347] A third variation of factoring transactions involves the provision of a guarantor or collateral. In high-value or high-risk transactions, the repair company's representative may act as a personal guarantor, or the repair company's assets (real estate, equipment, etc.) may be set as collateral. The provision of a guarantor or collateral reduces the factoring company's risk, enabling them to offer higher purchase rates or lower commission rates. The provision of a guarantor or collateral is logged along with the details and date of provision.

[0348] A fourth variation of factoring transactions involves a direct settlement agreement with an insurance company. In this arrangement, the factoring company and the insurance company agree that the insurance payout will be made directly to the factoring company. This eliminates the need for a repair company and reduces collection risk. The conclusion of the direct settlement agreement is recorded in a log, along with the name of the insurance company, the contract details, and the date and time of the agreement.

[0349] A fifth variant of factoring transactions involves the registration of the assignment of receivables. In this form, the assignment of receivables acquired by the factoring company is registered. This registration makes the assignment of receivables public and allows it to be asserted against third parties. The implementation of the assignment of receivables registration is recorded in a log along with the registration details, registration date and time, and registration number.

[0350] <37. Modified Embodiments of Settlement Processing> In the above embodiment, the automatic settlement process in the settlement processing unit 140 of this disclosure was described as performing automatic settlement after the insurance payment was received, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the execution result.

[0351] One variation of the settlement process is a phased settlement corresponding to partial payments. When insurance payments are made in multiple installments, a partial settlement is performed for each payment. In each settlement, the factoring principal and fees corresponding to the amount received are recovered. Once all payments are completed, a final settlement is performed, and any difference is refunded to the repair company. The execution of phased settlements is logged along with the amount received, the settlement amount, and the remaining balance for each payment.

[0352] A second variation of the settlement process involves adjusting the timing of automatic transfers of the difference. If the insurance payout exceeds the estimated amount, the difference is not immediately transferred to the repair company, but rather after a predetermined period (e.g., 7 days). During this period, it is confirmed that there are no reduction notices or refund requests from the insurance company. The adjustment period is recorded in the log along with the number of days and the scheduled transfer date.

[0353] A third variant of the settlement process involves obtaining approval from the repair company before executing the settlement. Upon detection of the insurance payment, the repair company is notified of the planned settlement details, and the settlement is executed only after obtaining the repair company's approval. This allows the repair company to review the settlement details in advance and raise any objections. The acquisition of repair company approval is recorded in the log along with the notification date and time, approval date and time, and approver ID.

[0354] A fourth variation of the settlement process involves conducting a post-settlement audit. After the settlement process is completed, the accuracy of the settlement details is audited within a predetermined period. The audit verifies that the insurance payment amount, factoring principal, fees, and difference remittance amount are correct. If errors are found as a result of the audit, corrective actions are taken. The execution of the audit is recorded in a log along with the audit date and time, audit results, and corrective actions.

[0355] A fifth variation of the settlement process involves settling multiple factoring transactions together. If the same repair company has multiple factoring transactions, they are settled together. Settling them together reduces remittance fees. It also allows for offsetting receivables and payables between multiple transactions. The execution of a consolidated settlement is recorded in the log along with the number of transactions, the settlement amount for each transaction, and the total settlement amount.

[0356] <38. Detailed Modified Embodiments of the Matching Process> The matching process in the settlement processing unit 140 related to this disclosure was described in the above embodiment as a configuration that matches payment information with factoring transactions, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the matching result.

[0357] One variant of the matching process is matching using a machine learning model. A machine learning model is used that takes each field of the payment information and factoring transaction as input and outputs a matching score. The machine learning model is trained using past successful and unsuccessful matching cases. The execution of the machine learning model is logged along with the input data, the output matching score, and the matching judgment result.

[0358] A second variant of the matching process involves presenting multiple matching candidates. If multiple transaction candidates with high matching scores exist, all of them are presented to the operator, who then makes the final matching decision. The operator is shown the matching score, matching items, and mismatched items for each candidate. The operator's matching decision is logged along with the date and time of the decision, the decision-maker ID, and the selected candidate.

[0359] A third variant of the matching process involves requesting matching confirmation from the insurance company. If matching is difficult, a request is made to the insurance company to confirm the payment details. Based on the response from the insurance company, accurate matching is performed. The transmission of the matching confirmation request is recorded in the log along with the date and time of the request, the content of the request, and the response from the insurance company.

[0360] A fourth variant of the matching process involves learning past matching patterns. For deposits from the same insurance company, past matching patterns (such as the format of the remitter's name and the format of the remarks column) are analyzed and learned. The learned patterns are then used in future matching processes. The learning of matching patterns is recorded in a log along with the number of learning data points, the extracted patterns, and the learning date and time.

[0361] <39. Detailed Modified Embodiments of the Notification Function> The notification function in the system described in this disclosure uses push notifications, email, and SMS in the embodiments described above, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the transmission result.

[0362] One of the primary variations of the notification function is notification using a chat tool. This chat tool could be Slack, Microsoft Teams, LINE, or a similar tool. The chat tool's API is used to send notifications as chat messages at each processing stage. This chat-based notification enables real-time, two-way communication. The sending of chat notifications is logged along with the recipient channel, message content, and date and time of sending.

[0363] A second variant of the notification function is notification via voice call. For high-priority notifications (e.g., approaching deadlines for high-value projects, errors in settlement processing, etc.), notifications are made via automated voice call. Text-to-speech (TTS) technology is used for the voice call. The execution of a voice call is logged along with the caller's phone number, call content, call date and time, and response result.

[0364] A third variant of the notification function involves selecting the sending method based on the notification's priority. Notifications are assigned a priority (high, medium, low), and the sending method is selected according to that priority. High-priority notifications are sent via SMS, push notifications, and email. Medium-priority notifications are sent via push notifications and email. Low-priority notifications are sent via email only. The selection of the sending method based on priority is logged along with the notification type, priority, and selected sending method.

[0365] A fourth variant of the notification function is a notification scheduling function. This allows users to specify the time at which notifications should be sent. For example, notifications can be sent only at a predetermined time the following morning, and not during late-night hours. Alternatively, notifications can be sent only during user-defined receiving time slots. Notification scheduling is logged along with the specified sending time and the actual sending time.

[0366] A fifth variant of the notification function is a notification resend function. If the user does not respond to a sent notification, the notification is resent after a predetermined period of time. The number of resends and the interval are set according to the type and priority of the notification. Notification resends are logged along with the number of resends, the resend interval, and the date and time of the resend.

[0367] A sixth variant of the notification function is the notification content customization function. Users can set the type of notification to receive, the notification method, and the level of detail in the notification content. For example, it is possible to set it so that factoring application acceptance notifications are not received, and only purchase condition proposal notifications are received via SMS. Changes to notification settings are recorded in the log along with the user ID, settings, and date and time of setting.

[0368] <40. Detailed Modified Embodiments of Error Handling> The error handling in the system described in this disclosure has been explained in the above embodiment, but various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time, error details, and processing results.

[0369] One of the primary variations of error handling is an automatic retry function. If a temporary error occurs (such as a network error or timeout), retries are automatically performed up to a predetermined number of times. The retry interval is determined by an exponential backoff algorithm. The execution of retries is logged along with the number of retries, the result of each retry, and the final result.

[0370] A second variation of error handling is fallback handling. If the primary handling method fails, it automatically switches to an alternative handling method. For example, if access to the primary parts price database fails, it accesses a backup parts price database. Or, if the inference of the primary damage detection model fails, it uses a lighter alternative model. The execution of the fallback handling is logged along with the reason for the primary handling failure, the type of alternative handling, and the result of the alternative handling.

[0371] A third variation of error handling involves automatic error classification and prioritization. Errors are automatically classified and assigned priorities based on their type and impact. High-priority errors are immediately notified to the administrator. Medium-priority errors are notified in batches at predetermined intervals. Low-priority errors are only logged and no notification is sent. Error classifications are recorded in the log along with the error type, priority, and reason for classification.

[0372] A fourth variant of error handling is an automatic error recovery function. When a specific error occurs (e.g., a database connection error), the system automatically performs recovery processing. This recovery processing may include re-establishing the connection, clearing the cache, and restarting services. The execution of automatic recovery is logged along with the error type, the recovery processing performed, and the recovery result.

[0373] A fifth variant of error handling is a root cause analysis function. When similar errors occur frequently, the error log is analyzed to identify the root cause. Root cause analysis can utilize machine learning for anomaly detection, statistical analysis of logs, or error pattern matching. The results of the root cause analysis are recorded in the log along with the date and time of analysis, the identified cause, and recommended countermeasures.

[0374] <41. Details of the data format> This section describes the data formats used in the system related to this disclosure. The use of data formats is recorded in the log along with the date and time of use and the format type.

[0375] The primary data format is JSON (JavaScript Object Notation). JSON is a lightweight text format for representing structured data. In this system, JSON is used for API communication requests and responses, configuration files, log entries, and more. JSON data is validated using the JSON schema to detect invalid data. The sending and receiving of JSON data is logged along with the data size and schema version.

[0376] A second form of data format is XML (eXtensible Markup Language). XML is a markup language for representing structured data. In this system, XML may be used for data exchange when integrating with external systems (especially insurance company systems). XML data is validated using XML Schema (XSD). The sending and receiving of XML data is logged along with the data size and schema version.

[0377] A third form of data format is CSV (Comma-Separated Values). CSV is a simple text format for representing tabular data. In this system, CSV is used for batch processing of large amounts of data, report generation, and data import / export. CSV data is subject to validation for the presence of a header row, column count, and data type. Processing of CSV data is logged along with the number of rows, columns, and processing date and time.

[0378] A fourth form of data format is Protocol Buffers (protobuf). Protocol Buffers is an efficient binary format developed by Google. In this system, Protocol Buffers may be used for high-speed communication between microservices. Protocol Buffers has a smaller data size and faster serialization and deserialization than JSON or XML. The use of Protocol Buffers is logged along with the message type, data size, and processing time.

[0379] The fifth form of data format is Apache Avro. Apache Avro is a row-oriented data serialization framework. In this system, Apache Avro may be used to store large amounts of log data or historical data. Apache Avro supports schema evolution and offers high data compression. The use of Apache Avro is logged along with the schema version, number of records, and compressed data size.

[0380] <42. Details of the communication protocol> This section describes the communication protocols used in the system related to this disclosure. The use of communication protocols is logged along with the date and time of use and the type of protocol used.

[0381] The primary form of communication protocol is HTTPS (HTTP over TLS). HTTPS is a protocol that applies TLS encryption to HTTP. In this system, HTTPS is used for communication between the web browser and the server, and for communication via the RESTful API. HTTPS prevents eavesdropping and tampering with communication content. The establishment of HTTPS communication is logged along with the TLS version, cipher suite, and certificate information.

[0382] WebSocket is a second form of communication protocol. WebSocket is a protocol that enables bidirectional communication between a client and a server. In this system, WebSocket may be used for real-time progress notifications and chat functions. WebSocket allows for efficient push notifications from the server to the client. The establishment of a WebSocket connection is logged along with the source, destination, and connection date and time.

[0383] gRPC is a third form of communication protocol. gRPC is a high-performance RPC framework developed by Google. gRPC is based on HTTP / 2 and uses Protocol Buffers as its data format. In this system, gRPC may be used for communication between microservices. gRPC enables low-latency and high-throughput communication. The execution of gRPC communication is logged along with the service name, method name, and processing time.

[0384] MQTT is a fourth form of communication protocol. MQTT is a lightweight messaging protocol primarily used for communication between IoT devices. In this system, MQTT may be used in the future for communication with IoT devices (e.g., sensors in repair shops, vehicle diagnostic equipment, etc.). MQTT enables reliable communication even in low-bandwidth and unstable network environments. MQTT communication is logged along with the topic, QoS (Quality of Service) level, and transmission / reception date and time.

[0385] FTP / SFTP is a fifth form of communication protocol. FTP (File Transfer Protocol) and SFTP (SSH File Transfer Protocol) are protocols used for transferring files. In this system, FTP / SFTP may be used for transferring large amounts of backup data or log data. SFTP is a protocol that applies SSH encryption to FTP, enabling secure file transfer. The execution of FTP / SFTP communication is recorded in the log along with the transferred file name, file size, and transfer date and time.

[0386] <43. Detailed Variant Embodiments of Certification and Authorization> While the authentication and authorization in the system described in this disclosure were explained as password authentication and multi-factor authentication in the embodiments described above, various modifications are possible. The execution of each modified embodiment is recorded in the log along with the execution date and time and the authentication result.

[0387] Biometric authentication is a primary variant of authentication and authorization. Biometric authentication methods include fingerprint recognition, facial recognition, iris recognition, or voiceprint recognition. Biometric authentication eliminates the need for password entry, improving user convenience. Furthermore, biometric information is difficult to forge, enhancing security. The execution of biometric authentication is logged along with the authentication type, authentication device, authentication result, and authentication date and time.

[0388] A second variant of authentication and authorization is single sign-on (SSO). Single sign-on allows users to access multiple applications or services after authenticating once. Protocols used for single sign-on include SAML (Security Assertion Markup Language), OAuth 2.0, or OpenID Connect. Single sign-on executions are logged along with the authentication provider, authentication date and time, and a list of accessed services.

[0389] A third variant of authentication and authorization is risk-based authentication. In risk-based authentication, the risk level is assessed based on the login circumstances (IP address, location information, device information, login time, etc.). If the risk level is high, additional authentication (multi-factor authentication, security questions, etc.) is required. If the risk level is low, additional authentication is omitted. The execution of risk-based authentication is logged along with the assessed risk level, the additional authentication requested, and the authentication result.

[0390] A fourth variant of authentication and authorization is certificate-based authentication. In certificate-based authentication, a digital certificate is issued to the user or device, and authentication is performed using that certificate. Certificate-based authentication is particularly used in API access or machine-to-machine communication. The execution of certificate-based authentication is logged along with the certificate issuer, certificate expiration date, and authentication result.

[0391] A fifth variation of authentication and authorization is attribute-based access control (ABAC). In ABAC, access rights are dynamically determined based on user attributes (role, department, location, etc.), resource attributes (confidentiality, category, etc.), and environment attributes (time, location, device, etc.). ABAC enables granular access control. ABAC execution is logged along with the evaluated attributes, applied policies, and authorization results.

[0392] <44. Details of log format and log level> The log format and log level in the log recording unit 180 related to this disclosure are described below. The use of the log format and log level is recorded in the log along with the date and time of use.

[0393] The primary form of log format is structured logging. In structured logging, log entries are recorded as structured data (JSON or key-value pairs). Structured logging makes it easier to search, filter, and aggregate logs. Each entry in structured logging includes a timestamp, log level, log message, and contextual information (such as user ID, session ID, and request ID).

[0394] A second form of log format is unstructured logging. In unstructured logging, log entries are recorded as free-form text. Unstructured logging is easy for humans to read but difficult for machines to process. Unstructured logging may be used in development environments or for debugging purposes. In production environments, structured logging is recommended.

[0395] The following log levels are defined: The DEBUG level records detailed debugging information. The INFO level records important information during normal operation. The WARN level records situations where problems may occur. The ERROR level records situations where an error occurred but processing can continue. The FATAL or CRITICAL level records situations where a fatal error has occurred and processing cannot continue. The usage of each log level is aggregated and monitored per log level.

[0396] The following output destinations are used for logs: File output records log entries to text or binary files. Database output records log entries to a database (such as audit log DB157). Log aggregation service output sends log entries to an external log aggregation service (such as Elasticsearch, Splunk, or CloudWatch Logs). Console output outputs log entries to standard output or standard error.

[0397] Log rotation involves replacing log files with new ones at regular intervals or when they reach a certain size. Old, rotated log files are compressed, archived, or deleted. Log rotation is recorded in the log along with the date and time of rotation, the reason for rotation (e.g., exceeding size limits, expiration of time), and how the old log files were handled.

[0398] <45. Detailed Modified Embodiments of the User Interface> While the user interface of the system described in this disclosure has been explained as a web application and a mobile application in the embodiments described above, various modifications are possible. The use of each modified embodiment is recorded in a log along with the date and time of use.

[0399] A primary variant of the user interface is a voice interface. Users can operate the system using voice commands. Speech recognition can be performed using Google Speech-to-Text, Amazon Transcribe, or similar voice recognition services. Examples of voice commands include "View the latest factoring transactions" and "Check the risk score." The execution of voice commands is logged along with the recognized voice text, the executed command, and the execution result.

[0400] A second variant of the user interface is the chatbot interface. Users can operate the system through interaction with a chatbot. The chatbot implements natural language processing and dialogue management functions. The chatbot answers user questions, collects necessary information, and performs appropriate actions. Interactions with the chatbot are logged, along with the dialogue content, the actions performed, and the results.

[0401] A third variant of the user interface is the Augmented Reality (AR) interface. Repair technicians use AR devices (AR glasses or an AR app on a smartphone) to scan damaged areas of a vehicle. The AR interface overlays information such as repair procedures, necessary parts, and estimated work time onto the scanned damaged areas. The use of the AR interface is logged along with the scanned vehicle, the information displayed, and the date and time of use.

[0402] A fourth variant of the user interface is the dashboard interface. The dashboard visually displays various statistics, progress, and real-time metrics. Display items on the dashboard include the number of factoring applications today, approval rate, average processing time, distribution of integrated risk scores, and trends in recovery rates. Access to the dashboard is logged along with the accessor ID, displayed items, and access date and time.

[0403] A fifth variant of the user interface is a customizable dashboard. Users can freely configure the items, layout, and update frequency displayed on the dashboard. Customized dashboards are saved for each user. Dashboard customizations are logged along with the user ID, settings, and date and time of setting.

[0404] <46. Details of the report generation function> This section describes the report generation function in the system related to this disclosure. The report generation function automatically generates various statistical information, analysis results, and audit reports. The execution of report generation is recorded in the log along with the execution date and time, report type, and output format.

[0405] The primary type of report is the factoring transaction report. This report includes information such as the number of transactions, total transaction value, average purchase rate, average commission rate, and recovery rate for a specified period. Reports can be generated daily, weekly, monthly, or for any specified period. Reports can be output in PDF, Excel, CSV, or HTML formats.

[0406] The second type of report is the risk analysis report. The risk analysis report includes information such as the distribution of the integrated risk score, the distribution of each risk score (SC1-SC5), a list of high-risk cases, and trends in default rates. The risk analysis report is used for risk management and portfolio management.

[0407] A third type of report is the repairer-specific report. This report includes information such as the number of transactions, transaction value, average combined risk score, number of defaults, and recovery rate for each repairer. Repairer-specific reports are used for credit assessment and managing business relationships with repairers.

[0408] The fourth type of report is the audit report. An audit report details all factoring transactions, settlement processes, errors, and security events over a specified period. Audit reports are used for internal audits, external audits, or reporting to regulatory authorities. The generation of an audit report is logged along with the date and time of generation, the period covered, and the number of transactions included in the report.

[0409] <47. Details of Data Retention and Archiving> This section describes data retention and archiving in the system related to this disclosure. Data retention and archiving are necessary for compliance with laws and regulations, audit response, and analysis of historical data. The execution of data retention and archiving is logged along with the date and time of execution, the data subject, and the retention period.

[0410] The primary form of data retention policy is retention based on legally mandated retention periods. Financial transaction data must be retained for a specified period by national laws and regulations. In Japan, the Companies Act and Tax Act require the retention of transaction-related documents for seven years. The application of data retention policies is logged along with the applicable laws and regulations, retention period, and retention start date.

[0411] A second form of data retention policy is retention based on business necessity. Data may be retained beyond the statutory retention period due to business necessity (e.g., long-term statistical analysis, continuous improvement of machine learning models). The retention period for business-related data is set individually depending on the data type and purpose. Business-related retention policies, along with the reason for the setting and the retention period, are logged.

[0412] The primary method of data archiving is hot archiving. In hot archiving, data is stored in high-speed storage and is immediately accessible. Hot archiving is used for frequently accessed data. Data movement to the hot archive is logged along with the date and time of the move and the amount of data moved.

[0413] A second method of data archiving is cold archiving. In cold archiving, data is kept in low-cost storage, and access takes time. Cold archiving is used for data that is accessed infrequently. Tape storage and cloud storage archive tiers (e.g., Amazon S3 Glacier, Azure Archive Storage) are used for cold archiving. Data movement to cold archiving is logged along with the date and time of movement, the amount of data, and the expected retrieval time.

[0414] A third method of data archiving is incremental archiving. In incremental archiving, data is automatically moved from hot storage to cold storage based on the time elapsed since its creation date or last access date. For example, data is kept in hot storage for up to 30 days after creation, in warm storage from 30 days to 1 year, and in cold storage for more than 1 year. The execution of incremental archiving is logged along with the amount of data moved and the source and destination storage tiers.

[0415] As per the data deletion policy, data is automatically deleted after its retention period has expired. Before data deletion is performed, a list of data to be deleted is generated and notified to the administrator. The administrator can approve or postpone the deletion. Data deletion is logged along with the date and time of deletion, the type of data deleted, and the amount of data deleted. Recovering deleted data is generally not possible.

[0416] Regarding the deletion of personal information, we respond to deletion requests from data subjects in accordance with data protection regulations (e.g., GDPR, Personal Information Protection Act). Upon receiving a deletion request, the relevant personal information will be deleted without delay. However, deletion may be restricted for information that is legally required to be retained or that needs to be retained for legitimate business reasons. The execution of personal information deletion is logged along with the requester, the date and time of the request, and the scope of information deleted.

[0417] <48. Contract management and automated generation of legal documents> This document describes the contract management and automatic generation of legal documents within the system related to this disclosure. The legal validity of factoring transactions is ensured through the automatic generation of contract management and legal documents. The execution of contract management and document generation is logged along with the date and time of execution and the type of document generated.

[0418] The first type of automatically generated legal document is the factoring agreement. The factoring agreement includes details of the assignment of receivables, the consideration for the assignment (purchase rate, commission rate, immediate payment amount), settlement terms, late payment penalties, termination conditions, governing law, and competent court. The factoring agreement is automatically generated and electronically signed upon completion of the transaction. The generation of the factoring agreement is logged along with the contracting parties, contract details, and generation date and time.

[0419] The second type of automatically generated legal document is the assignment of receivables notice. An assignment of receivables notice is a document used to notify the debtor (insurance company) of the assignment of repair receivables. The assignment of receivables notice includes information such as the assignor (repair company), the assignee (factoring company), the details of the assigned receivables, and the date of assignment. The assignment of receivables notice is automatically generated after the factoring transaction is completed and sent to the insurance company. The generation and sending of the assignment of receivables notice is recorded in the log along with the recipient, date and time of sending, and method of sending.

[0420] A third type of automatically generated legal document is the settlement report. The settlement report includes information such as the amount of insurance proceeds received, the amount of factoring principal recovered, the amount of fees recovered, the amount of the difference remitted, and the settlement date. The settlement report is automatically generated after the settlement process is completed and sent to the repair company. The generation of the settlement report is recorded in the log along with the transaction in question, the settlement details, and the date and time of generation.

[0421] The fourth type of automatically generated legal document is tax documents. These tax documents include invoices, receipts, or payment statements related to factoring fees. These documents are used for tax filing and tax audits. The generation of tax documents is logged along with the type of document generated, the period covered, and the date and time of generation.

[0422] For electronic signatures on contracts, electronic signatures compliant with the Electronic Signature Law are used. Electronic signatures are time-stamped to prove the signing time. Verification of the electronic signature ensures that the document has not been tampered with after signing. The assignment of electronic signatures is logged along with the signer, signing date and time, and the signature algorithm used.

[0423] For contract storage, generated contracts and other legal documents are stored in a database in an encrypted state. Access control is applied to the stored documents, allowing only authorized personnel to access them. Access to documents is logged, along with the accessor, date and time, and the accessed document.

[0424] <49. Details of Compliance Measures> This document explains the compliance measures taken in the system related to this disclosure. Compliance measures ensure that the system operates in accordance with various laws, regulations, and industry standards. The implementation of compliance measures, including the date and time of implementation and the details of the measures taken, are recorded in the log.

[0425] The first item in compliance is anti-money laundering (AML). Anti-money laundering measures include Know Your Customer (KYC), transaction monitoring, and reporting of suspicious transactions. For identity verification, the company's corporate registration information, the representative's identification documents, and verification of existence are checked. Transaction monitoring detects unusual transaction patterns (e.g., large transactions in a short period, high-value transactions). The implementation of anti-money laundering measures, along with whether any anomalies were detected, is recorded in a log.

[0426] The second item in our compliance measures is dealing with anti-social forces. Before commencing any business relationship, we verify that the repair company is not affiliated with any anti-social forces. Verification methods include inquiries to external databases (National Police Agency database, private anti-social force databases) and reputation checks through internet searches. If there is suspicion that a company is affiliated with an anti-social force, the transaction will be refused. The execution of the anti-social force check is recorded in a log along with the subject of the check, the check result, and the date and time of the check.

[0427] The third item in compliance is the protection of personal information. Personal information is handled in accordance with the Personal Information Protection Act and regulations such as the GDPR. When collecting personal information, the purpose of use is clearly stated and the individual's consent is obtained. Personal information is stored in an encrypted state and access control is applied. The provision of personal information to a third party requires the individual's consent or the provisions of the law. The handling of personal information is recorded in logs along with the content of the handling and the date and time of handling.

[0428] The fourth item in compliance is adherence to the Interest Rate Restriction Law. If factoring fees are effectively considered interest, they are set so as not to exceed the interest rate limits set by the Interest Rate Restriction Law. When setting the fee rate, the effective interest rate, converted to an annual rate, is calculated and compared to the upper limit set by the Interest Rate Restriction Law. The setting of the fee rate is recorded in the log along with the set fee rate, the annualized value, and the results of the compliance check.

[0429] The fifth item in compliance measures is compliance with the Money Lending Business Act. Factoring is the purchase of receivables, not a loan, and therefore, in principle, is not subject to the Money Lending Business Act. However, if factoring is considered to be a loan in substance, it may be subject to the regulations of the Money Lending Business Act. To avoid being considered a loan in substance, the substance of the assignment of receivables is ensured. To ensure the substance of the assignment of receivables, a notice of assignment of receivables is sent, and the receivables are completely assigned (without recourse). The implementation of compliance with the Money Lending Business Act is recorded in a log along with the details and date of implementation.

[0430] <50. Details of potential applications to other items> Although the system described in this disclosure illustrates the factoring of automobile repair receivables in the embodiments described above, it is also applicable to the factoring of repair receivables for other goods. Application to other goods is recorded in the log along with the applicable item and the date and time of application.

[0431] One primary example of its application to other items is its use in motorcycles. In motorcycle damage analysis, the vehicle identification number and damage images are used as input to detect damaged areas, determine the extent of damage, and estimate repair costs. Motorcycle parts prices and labor costs are stored in a separate database or table from those for automobiles. Risk scoring and factoring processes for motorcycles are performed using the same procedures as for automobiles. Applications to motorcycles are logged along with the vehicle models and processing results.

[0432] A second example of application to other items is its use in ships. Ship identification numbers (IMO numbers) are used for ship identification. In ship damage analysis, damage to the hull, engines, navigation equipment, etc., is detected. Since ship repair costs vary greatly depending on the scale of the repair, a more detailed risk assessment is necessary. Applications to ships are logged along with the target ship and the processing results.

[0433] A third example of application to other items is its application to aircraft. Aircraft identification uses the aircraft number (registration number). In aircraft damage analysis, damage to the airframe, engines, and avionics is detected. Aircraft repair requires approval from aviation authorities, and the repair process is complex. These specific characteristics are taken into account in aircraft factoring. Applications to aircraft are logged along with the aircraft in question and the processing results.

[0434] A fourth example of application to other items is its use in construction machinery. Construction machinery includes bulldozers, excavators, cranes, and dump trucks. Serial numbers are used to identify construction machinery. Damage analysis of construction machinery detects damage to hydraulic systems, drive systems, and working equipment. Applications to construction machinery are logged along with the target machinery and processing results.

[0435] A fifth example of application to other items is its use in industrial machinery. Industrial machinery includes machine tools, molding machines, presses, and conveying machines. Damage analysis of industrial machinery can detect damage to precision parts and failures in control systems. Repairing industrial machinery requires specialized skills and can be expensive. Applications to industrial machinery are recorded in a log along with the target machine and processing results.

[0436] A sixth example of application to other items is its use in residential equipment. Residential equipment includes air conditioning systems, water heaters, kitchen equipment, and bathroom equipment. In damage analysis of residential equipment, information such as the equipment model number, installation year, and usage conditions are used in addition to damage images. Factoring of repair receivables for residential equipment may be linked to home insurance or manufacturer warranties. Applications to residential equipment are logged along with the target equipment and processing results.

[0437] The following steps are performed as a common procedure for applying the process to other items: First, obtaining an identifier for the item in question. Second, training or selecting a damage detection model specific to the item in question. Third, preparing parts price and labor cost data for the item in question. Fourth, identifying and evaluating risk factors specific to the item in question. Fifth, setting factoring terms that are suitable for the repair process of the item in question. The execution of these steps is logged along with the type of item in question and the details of the steps taken.

[0438] <51. System scalability and future-proofing> This section describes the system's scalability and future-proofing capabilities. The system's scalability allows for easy addition of new functions, integration of new data sources, and connection with new external systems. System expansions are logged along with the expansion details and date / time.

[0439] The first form of system expansion is the plug-in architecture. In the plug-in architecture, the system's core functions and extensions are separated, and extensions are added dynamically as plug-ins. Plugins include new damage detection models, new risk scoring algorithms, and new integration capabilities with external systems. The addition of a plug-in is logged along with the plug-in name, plug-in version, and date and time of addition.

[0440] A second form of system expansion is the API-driven architecture. All system functions are exposed as APIs and can be used by external systems or third-party applications. The API-driven architecture allows other businesses to utilize the system as a platform. API exposure is logged along with the exposed API endpoint, API version, and publication date and time.

[0441] A third form of system expansion is the dynamic integration of data sources. New data sources (e.g., new parts suppliers, new credit information agencies, new market data providers) can be integrated without rebuilding the system. Standardized data adapters are used for data source integration. The addition of a data source is logged along with the data source name, data type, and date and time of addition.

[0442] The first item on our future-proofing plan is to address new damage detection technologies. In the future, when more accurate damage detection technologies (e.g., 3D scanning, hyperspectral imaging, ultrasound, etc.) become available, we can integrate them. The integration of new technologies will be logged along with the technology name, integration method, and date and time of integration.

[0443] The second item in our future-proofing plan is support for new payment methods. In the future, if new payment methods (e.g., digital currencies, stablecoins, CBDCs, etc.) become widespread, we will be able to support them. Support for new payment methods will be recorded in the log along with the name of the payment method, the method of support, and the date and time of support.

[0444] The third item in our future-proofing plan is compliance with new regulations. If new financial or data protection regulations come into effect in the future, the system will be updated to comply with those regulations. Regulatory compliance updates will be logged along with the regulation name, update details, and update date and time.

[0445] <52. Details of parallelization and distributed processing> This disclosure describes the parallelization and distributed processing of data in the system described herein. Parallelization and distributed processing enable efficient processing of large amounts of data or requests. The execution of parallelization and distributed processing is logged along with the execution date and time, degree of parallelism, and processing time.

[0446] The first form of parallelization is data parallelism. In data parallelism, a large amount of data is divided into multiple parts, and each part is processed in parallel. For example, when analyzing multiple damaged images, each image is analyzed in parallel using a different processing thread or process. Data parallelism reduces the overall processing time. The execution of data parallelism is logged along with the number of data divisions, the processing time for each part, and the overall processing time.

[0447] A second form of parallelization is task parallelization. In task parallelization, different types of processes are executed in parallel. For example, damage detection and risk scoring processes are executed in parallel. However, if there are dependencies between processes, the execution order is determined taking those dependencies into account. The execution of task parallelization is logged along with the types of tasks executed in parallel and the processing time for each task.

[0448] The first form of distributed processing is the MapReduce pattern. In the MapReduce pattern, processing of large amounts of data is divided into a Map phase and a Reduce phase. In the Map phase, processing is performed in parallel for each data point. In the Reduce phase, the results of the Map phase are aggregated. The MapReduce pattern is used for large-scale data analysis or statistical processing. The execution of MapReduce is logged along with the amount of data processed, the number of Map tasks, the number of Reduce tasks, and the processing time.

[0449] A second form of distributed processing is stream processing. Stream processing processes data arriving continuously in real time. For example, it can process deposit notifications arriving continuously via webhooks in real time. Apache Kafka Streams, Apache Flink, or similar frameworks are used as stream processing frameworks. Stream processing executions are logged along with the number of events processed, processing throughput, and processing latency.

[0450] A third form of distributed processing is distributed transaction processing. In distributed transaction processing, transactions are executed across multiple databases or multiple services. To ensure the consistency of distributed transactions, two-phase commit, the Saga pattern, or event sourcing are used. The execution of distributed transactions is logged along with the number of participating services or databases, the transaction result, and the execution time.

[0451] Load balancers are used for load balancing in parallel and distributed processing. A load balancer distributes requests across multiple processing servers. Load balancing algorithms include round-robin, minimum connections, weighted round-robin, or response time-based distribution. The operation of the load balancer is logged along with the destination server, the number of distributed requests, and the load on each server.

[0452] <53. Details of the Cash Strategy> This section describes the caching strategy in the system related to this disclosure. The caching strategy improves the speed of retrieving frequently accessed data and reduces the load on the database or external APIs. Cache usage is logged along with the cache key, hit or miss, and retrieval date and time.

[0453] The primary type of cache is the application-level cache. In an application-level cache, data is cached in the application's memory. Application-level caches can be in-memory hash maps, LRU (Least Recently Used) caches, or similar cache implementations. Application-level caches are only valid within a single server.

[0454] A second type of cache is a distributed cache. A distributed cache uses a cache shared among multiple servers. Examples of distributed caches include Redis, Memcached, or Hazelcast. A distributed cache allows multiple servers to access the cached data. The use of a distributed cache is logged along with the cache server address, cache key, and operation type.

[0455] A third type of cache is CDN (Content Delivery Network) caching. With CDN caching, static content (images, CSS, JavaScript, etc.) is cached on a server geographically closer to the user. CDN caching improves content delivery speed and reduces the load on the origin server. The use of CDN caching is logged along with the delivered content, the originating CDN node, and the delivery date and time.

[0456] A Time To Live (TTL) is set as the expiration date for the cache. The TTL represents the period during which the cached data is valid. Once the TTL has expired, the cached data becomes invalid, and the latest data is retrieved on the next access. The TTL setting is determined based on the data update frequency and freshness requirements. A short TTL is set for data that is updated frequently, and a long TTL is set for data that is updated rarely.

[0457] The following strategies are used to invalidate the cache: First, time-based invalidation invalidates the cache when the Time To Live (TTL) expires. Second, event-based invalidation explicitly invalidates the cache when a data update event occurs. Third, manual invalidation allows administrators to manually invalidate the cache as needed. Cache invalidation is logged along with the reason for invalidation, the date and time of invalidation, and the invalidated cache key.

[0458] The following strategies are used for writing to the cache: The Write-Through strategy writes data to both the cache and the database simultaneously when written. The Write-Back (Write-Behind) strategy writes data to the cache first, and then asynchronously to the database later. The Write-Around strategy bypasses the cache and writes directly to the database when written. The use of a cache write strategy is logged along with the strategy used and the data written.

[0459] <54. Further clarification of externally observable behavior> The externally observable behavior of the system related to this disclosure will be explained in more detail. Externally observable behavior makes it possible to verify the system's operation. The occurrence of observable behavior is recorded in the log along with the date and time of occurrence and the type of behavior.

[0460] A primary example of observable behavior is the HTTP response. In response to an HTTP request from a client to a server, the server returns an HTTP response. The HTTP response includes a status code (such as 200, 400, or 500), response headers, and a response body. By observing the status code and response time of the HTTP response, it is possible to determine whether the process was successful or unsuccessful and how long it took. The sending of an HTTP response is logged along with its status code, response size, and response time.

[0461] A second example of observable behavior is the sending of emails or SMS messages. At each processing stage, an email or SMS is sent to the user. By confirming the receipt of the sent email or SMS, it is possible to confirm that the corresponding process has been executed. The sending of emails or SMS messages is logged along with the recipient, content, date and time of sending, and delivery result.

[0462] A third example of observable behavior is the financial institution's transfer record. When the factoring processing unit 130 executes an immediate deposit, a transfer record to the repair company's account is generated at the financial institution. The repair company can confirm the transfer by checking the transaction details of their own account. The execution of the transfer is logged along with the recipient account, the transfer amount, and the date and time of the transfer.

[0463] A fourth example of observable behavior is the reception of webhook notifications. A webhook notification from financial institution 600 to server device 100 notifies the system of an insurance payment. By checking the webhook notification reception log, it can be confirmed that the payment detection process was executed. The reception of a webhook notification is recorded in the log along with the sender, notification content, and reception date and time.

[0464] A fifth example of observable behavior is database record updates. Each operation creates, updates, or deletes records in database 150. The status of the operations can be checked by querying the database records. Database record updates are logged along with the updated table, record ID, update details, and update date and time.

[0465] A sixth example of observable behavior is the generation of log files. Log files generated by the logging unit 180 are stored in the file system or a log aggregation service. By accessing the log files, the system's operation history can be checked. The generation of log files is recorded along with the log file name, log file size, and generation date and time (however, this recording itself is performed by a separate metalog or monitoring system).

[0466] <55. Forms of component supply as a response to indirect infringement> This section describes the form in which the components of the system related to this disclosure are provided to other businesses as parts or services. By providing parts or services, other businesses will be able to build the system described in this disclosure. The provision of parts or services will be recorded in a log along with the recipient, the content of the provision, and the date and time of provision.

[0467] The first form of component provision is the provision of the damage detection model 111. The damage detection model 111 is provided to other businesses as an API service or a software library. Other businesses can use the provided damage detection model 111 to implement damage detection functionality in their own systems. The provision of the damage detection model 111 is logged along with the recipient business, the form of provision (API, library, etc.), and the date and time of provision.

[0468] A second form of component provision is the provision of a risk scoring engine. The functions of the risk score calculation unit 120 are provided to other businesses as an API service or software module. Other businesses can use the provided risk scoring engine to perform risk assessments in their own factoring services. The provision of the risk scoring engine is logged along with the recipient business, the form of provision, and the date and time of provision.

[0469] A third form of component provision is the provision of an automated settlement engine. The functions of the settlement processing unit 140 are provided to other businesses as an API service or software module. Other businesses can use the provided automated settlement engine to implement automated settlement in their own factoring services. The provision of the automated settlement engine is logged along with the recipient business, the form of provision, and the date and time of provision.

[0470] A fourth form of component provision is the provision of a log recording system. The functions of the log recording unit 180 are provided to other businesses as an API service or software library. Other businesses can use the provided log recording system to implement tamper-detectable log recording in their own systems. The provision of the log recording system is recorded in the log along with the recipient business, the form of provision, and the date and time of provision.

[0471] A fifth form of component provision is the provision of database schemas. The schema for Database 150 (table definitions, index definitions, relationship definitions, etc.) is provided to other businesses. These businesses can then use the provided schema to build a similar database structure in their own systems. The provision of database schemas is logged along with the recipient business, the content provided, and the date and time of provision.

[0472] The sixth form of component provision is the provision of system integration services. This involves providing integration services to build a complete factoring system by combining the components described above. Integration services include component combination, configuration, customization, testing, and implementation support. The provision of system integration services is logged along with the service provider, the integration details, and the date and time of provision.

[0473] <56. Business Models as API Provisioning Methods> This section describes a business model that provides the functions of the system related to this disclosure as an API to other businesses. By providing the API, other businesses can integrate the functions of this disclosure into their own applications or services. The provision of the API will be logged along with the recipient, API type, and date and time of provision.

[0474] The primary form of API provision is the damage analysis API. The damage analysis API accepts vehicle identification numbers and damage images as input and outputs estimated repair costs, damaged areas, and damage extent. The damage analysis API can be integrated into the systems of repair shops, insurance companies, or used car dealers. Calls to the damage analysis API are logged along with the caller, input data, output data, and the date and time of the call.

[0475] The second form of API provision is the risk scoring API. The risk scoring API accepts inputs such as repair company ID, insurance company ID, estimated repair cost, and estimated amount, and outputs an integrated risk score, purchase rate, and commission rate. The risk scoring API can be used by factoring companies for their own risk assessments. Calls to the risk scoring API are logged along with the caller, input data, output data, and the date and time of the call.

[0476] A third form of API provision is the Factoring Transaction API. The Factoring Transaction API handles factoring applications, acceptance of applications, and immediate payment processing. The Factoring Transaction API can be integrated into the services of other factoring companies or fintech companies. Calls to the Factoring Transaction API are logged along with the caller, processing details, processing results, and the date and time of the call.

[0477] The fourth form of API provision is the settlement processing API. The settlement processing API performs payment detection, matching, and settlement processing. The settlement processing API can be integrated into the services of other factoring companies or payment processing companies. Calls to the settlement processing API are logged along with the caller, processing content, processing result, and date and time of call.

[0478] The following models are used for API usage fee models: Firstly, in the pay-as-you-go model, charges are based on the number of API calls. Secondly, in the flat-rate model, a fixed monthly or annual fee is charged. Thirdly, in the tiered billing model, charges are set in stages based on the number of API calls. Fourthly, in the success-based billing model, charges are based on the amount or number of transactions completed using the API. API usage charges are logged along with the user, number of uses or amount used, charge amount, and billing date and time.

[0479] The following restrictions apply to API usage: Firstly, rate limits restrict the number of API calls per unit of time. Secondly, quota limits set a monthly or yearly limit on the number of API calls. Thirdly, feature limits restrict the available API features depending on the usage plan. The application status of API usage restrictions is logged along with the user, restriction type, restriction value, and current usage status.

[0480] <57. Improving the explainability of the model> This disclosure describes a method for improving the explainability of the machine learning models used in the AI ​​damage analysis unit 110 and the risk score calculation unit 120. Improving explainability allows for an understanding of the model's reasoning, thereby increasing its reliability. The application of the explainability improvement method is recorded in a log along with the date and time of application, the model to which it was applied, and the generated explanation.

[0481] One of the primary methods for improving explainability is LIME (Local Interpretable Model-agnostic Explanations). LIME is a technique that approximates the local behavior of a complex model with an interpretable model (such as a linear model). By applying LIME to the judgment of the damage detection model 111, it is possible to visualize which image regions contributed to the judgment. The application of LIME is logged along with the model applied, the input data, and the generated explanation.

[0482] A second method for improving explainability is SHAP (SHapley Additive exPlanations). SHAP is a method that calculates the contribution of each feature to the prediction based on the Shapley value from game theory. By applying SHAP to the model of the risk score calculation unit 120, it is possible to quantify how much each risk factor contributed to the integrated risk score. The application of SHAP is recorded in the log along with the model to which it was applied, the input data, and the contribution of each feature.

[0483] A third method for improving explainability is the visualization of the attention mechanism. If the damage detection model 111 includes an attention mechanism (e.g., Vision Transformer), visualizing the attention weights allows us to see which image regions the model focused on. The visualization of the attention mechanism is logged along with the applied model, input data, and visualized attention map.

[0484] A fourth technique for improving explainability is the use of decision tree models. In risk scoring, when interpretability is important, decision tree models (such as decision trees, random forests, and gradient-boosted decision trees) are used instead of neural networks. Decision tree models allow the decision-making process to be represented as a tree structure, making them easy to interpret. The use of decision tree models is logged along with the model used, the depth of the generated decision tree, and the important features.

[0485] A fifth technique for improving explainability is combining it with rule-based models. This involves combining human-understandable rule-based decisions with decisions made by machine learning models. For example, a rule such as "If a repair company's past default rate exceeds 10%, deduct 20 points from its risk score" is explicitly defined. The application of rule-based models is logged along with the applied rules and their evaluation results.

[0486] <58. Fairness and measures against bias> This disclosure describes methods for ensuring fairness and mitigating bias in the machine learning models used in the AI ​​damage analysis unit 110 and the risk score calculation unit 120. Fairness and bias countermeasures prevent unfair discrimination based on specific attributes (e.g., size of the repair company, location, etc.). The implementation of fairness and bias countermeasures is recorded in a log along with the date and time of implementation, the countermeasures taken, and the evaluation results.

[0487] The primary method for ensuring fairness is the measurement of fairness indicators. This measures whether the model's predictions are unfairly biased by protected attributes (such as the size, location, and years in business of the repair shop). Demographic parity, equal opportunity, or equalized odds are used as fairness indicators. The measurement of fairness indicators is logged along with the measured indicator, measurement value, and date and time of measurement.

[0488] The primary method for reducing bias is balancing the training data. If certain attributes are over- or under-represented in the training data, the balance is adjusted by sampling (oversampling, undersampling) or augmenting the data. The balancing of the training data is logged along with the data distribution before and after the adjustment and the adjustment method.

[0489] A second method for bias reduction is fairness-constrained learning. Fairness constraints are added to the objective function during model training. The fairness constraints minimize bias in predictions due to specific attributes. The execution of fairness-constrained learning is logged along with the constraints used, the training results, and the improvement in the fairness metric.

[0490] A third method for mitigating bias is regular model audits. For models in production, fairness metrics are measured periodically to monitor for bias. If bias is detected, the model is retrained or adjusted. Model audits are logged along with the audit date and time, the fairness metrics measured, and whether or not bias was detected.

[0491] <59. Model Version Control and Experiment Management> This disclosure describes the version control and experiment management of the machine learning models used in the AI ​​damage analysis unit 110 and the risk score calculation unit 120. Version control and experiment management systematically manage the development, testing, and deployment of the models. The execution of version control and experiment management is recorded in a log along with the execution date and time and the details of the management.

[0492] For model version control, each model is assigned a version number. The version number is expressed in the format of major version, minor version, and patch version (e.g., 1.2.3). Significant model changes (such as architectural changes) update the major version, feature additions update the minor version, and bug fixes update the patch version. Model version updates are logged along with the update details and date / time.

[0493] A model registry centrally manages all trained models. The model registry records each model's version, the dataset used for training, hyperparameters, training date and time, evaluation results, and deployment status. MLflow, DVC (Data Version Control), or similar tools are used as the model registry tool. Registration to the model registry is logged along with the registered model, its metadata, and the registration date and time.

[0494] For experiment management, each experiment in model training is recorded. The experiment records the hyperparameters used, training dataset, training time, and evaluation metrics (accuracy, recall, F-score, etc.). By comparing multiple experiments, the optimal hyperparameters can be identified. Experiment records are logged along with the experiment ID, experimental conditions, experimental results, and experiment date and time.

[0495] For model deployment management, the system records which version of a model is deployed to the production environment. Model deployments can be performed using canary deployments, blue-green deployments, or rolling deployments. In a canary deployment, a new model is provided to only a select group of users, and only after verifying that there are no issues is it rolled out to all users. Model deployments are logged along with the deployed model version, deployment method, and deployment date and time.

[0496] <60. Continuous Integration and Continuous Deployment> This document describes the Continuous Integration (CI) and Continuous Deployment (CD) processes involved in the development process of the system related to this disclosure. CI and CD automatically test code changes and deploy them to the production environment. CI and CD executions are logged along with the execution date and time, execution details, and results.

[0497] The first step in continuous integration is committing code. Developers commit the code they've changed to a version control system (such as Git or SVN). The commit triggers the CI pipeline to start automatically. Code commits are logged along with the committer, commit message, and commit date and time.

[0498] The second step in continuous integration is automated builds. Committed code is built. The build process includes compiling the source code, resolving dependent libraries, and generating an executable file or container image. If build errors are detected, the developer is notified. Automated builds are logged along with the build results, build time, and build date and time.

[0499] The third step in continuous integration is automated testing. Automated tests are run on the built code. Automated tests include unit tests, integration tests, and end-to-end tests. If a test failure is detected, the developer is notified. The execution of automated tests is logged along with the number of tests run, the number of successes, the number of failures, and the test execution time.

[0500] The first step in continuous deployment is deployment to a staging environment. Code that has successfully passed automated tests is deployed to the staging environment. The staging environment is equivalent to the production environment and is used for final verification before deployment to production. Deployment to the staging environment is logged along with the version of the deployed code and the deployment date and time.

[0501] The second step in continuous deployment is testing in a staging environment. Manual tests, performance tests, and security tests are performed in the staging environment. If these tests are passed, deployment to the production environment is approved. The test results in the staging environment are logged along with the test type, test result, and test date and time.

[0502] The third step in continuous deployment is deployment to the production environment. Code that has passed testing in the staging environment is deployed to the production environment. Production deployments use strategies to minimize downtime (such as rolling deployments and blue-green deployments). Production deployments are logged along with the version of the deployed code, the deployment method, and the date and time of deployment.

[0503] The fourth step in continuous deployment is post-deployment monitoring. After deployment to the production environment, the system's operation is monitored. If an increase in error rate, deterioration of response time, or abnormal resource utilization is detected, an alert is issued. If a critical problem is detected, the system is automatically rolled back to the previous version. The post-deployment monitoring results are logged along with the monitored items, monitored values, and whether or not an anomaly was detected.

[0504] <61. Details of the Development and Test Environments> This section describes the development and testing environments for the system related to this disclosure. The development and testing environments allow for the development and testing of new features without affecting the production environment. The use of the development and testing environments is logged along with the date and time of use, the user, and the purpose of use.

[0505] The development environment used is either each developer's local machine or a shared development server. Within the development environment, developers can freely modify code and test its functionality. The development environment's database uses dummy test data, not production data. The use of the development environment is logged, along with the user, duration of use, and development details.

[0506] The test environment used may be an integrated test environment, a staging environment, or a performance test environment. In the integrated test environment, tests are performed with multiple components integrated. In the staging environment, tests are performed with a configuration equivalent to the production environment. In the performance test environment, load tests or stress tests are performed. The use of the test environment is logged along with the user, test type, and test results.

[0507] As part of test data management, dummy test data is generated. This dummy data is created to mimic the characteristics of production data (data distribution, data volume, etc.) while ensuring it does not contain personal or confidential information. Data generator tools or masking (pseudonymization, anonymization) of production data are used to generate the dummy data. The generation of test data is logged along with the type of data generated, the data volume, and the date and time of generation.

[0508] As part of inter-environment data migration, data migration from development or test environments to production environments is managed. Data migration includes changes to database schemas, updates to master data, and updates to configuration files. A migration plan is created and reviewed before data migration is performed. Data migration is logged along with the migration details, source environment, destination environment, and migration date and time.

[0509] <62. Example of a user interface screen> This section describes examples of user interface screens in the system related to this disclosure. The screen examples show typical screen configurations on each terminal device, and this disclosure is not limited to these examples. The display of each screen is recorded in the log along with the date and time of display, the content of the display, and the user to whom it was displayed.

[0510] <62-1. Example of a screen on an insurance policyholder terminal device> This section describes an example screen for the insurance policyholder terminal device 200. The insurance policyholder terminal device 200 is used by insurance policyholders to input damage information and check the progress of repairs. In typical implementations, it is provided as a web browser or a dedicated mobile application. The display and operation of the screen are logged along with the session ID, operation details, and date and time of operation.

[0511] The damage information input screen is where policyholders enter information about damage to their vehicles. This screen typically includes a field for the Vehicle Identification Number (VIN), an area for uploading damage images, a field for entering the date and time of the damage, and a text input area for describing the damage. The VIN input field requires a 17-digit alphanumeric code. In practice, a function to automatically input the VIN using a barcode scanner or OCR function may be provided. The information entered on the damage information input screen is transmitted upon completion and logged along with its hash value.

[0512] The damage image upload area allows users to upload images of the damage taken with their smartphone camera. Typical implementations allow uploading via drag-and-drop or through a file selection dialog. Supported image formats include JPEG, PNG, and HEIF. Multiple images (e.g., up to 10) can be uploaded. Upon successful upload of each image, the image file name, image size, and upload date and time are recorded in the log.

[0513] The damage information input screen will have a validation function to check the input content. It will verify whether the VIN format is correct, whether images have been uploaded, and whether all required fields have been filled in. If a validation error is detected, an error message will be displayed on the screen. Examples of error messages include, "Please enter the VIN as a 17-digit alphanumeric string," and "Please upload at least one image of the damage." The occurrence of a validation error will be logged along with the error type and error message.

[0514] Once the damage information has been entered and the submit button is pressed, the entered information is sent to the server device 100. During the submission process, a loading indicator (e.g., spinner, progress bar) is displayed on the screen to notify the user that the process is underway. If the submission is successful, the user is taken to a confirmation screen. If the submission fails, an error message is displayed, and the user is prompted to try again. The press of the submit button is recorded in the log along with the date and time of the press and a summary of the submitted information.

[0515] The AI ​​damage analysis results display screen shows the analysis results from the AI ​​damage analysis unit 110 to the insurance policyholder. This screen includes the estimated repair cost range (e.g., "Estimated repair cost: 250,000 to 350,000 yen"), a list of detected damaged parts (e.g., "Front bumper, headlight (right)"), an indication of the degree of damage (e.g., "Moderate damage"), and an indication of confidence level (e.g., "Estimated accuracy: 85%"). In a typical implementation, the detected damaged parts are displayed overlaid on the original image as bounding boxes or highlights. The display of the AI ​​damage analysis results, along with the displayed content and date and time, is recorded in the log.

[0516] The estimate confirmation screen is used by insurance policyholders to review estimates submitted by repair companies. This screen displays the repair company's name, estimated amount, breakdown of the estimate (parts, labor, and other expenses), estimated repair period, and the date and time the estimate was submitted. In practice, if multiple repair companies submit estimates, a function is provided to display and compare them in a list. The display of the estimate confirmation screen, along with the ID of the displayed estimate and the date and time of display, is recorded in the log.

[0517] The estimate approval button is pressed when the insurance policyholder agrees to the estimate and requests repairs. Pressing the button displays an approval confirmation dialog box with a confirmation message such as, "Do you wish to request repairs based on this estimate?" If the insurance policyholder selects "Yes" in the confirmation dialog box, the estimate approval is sent to the server device 100. The pressing of the estimate approval button and the submission of the approval are recorded in the log along with the estimate ID and the date and time of approval.

[0518] The repair progress screen is used by insurance policyholders to check the current status of repairs. This screen displays the repair status (e.g., "Preparing Estimate," "Repair in Progress," "Repair Completed"), the update date and time for each status, comments from the repair company, and the estimated repair completion date. In typical implementations, the repair progress is visually displayed in a timeline or step indicator format. The display of the repair progress screen is logged along with the ID of the displayed case and the date and time of display.

[0519] The notification settings screen is where policyholders configure the types and methods of notifications they receive. This screen includes on / off switches for each notification type (e.g., "Notification upon estimate submission," "Notification upon repair completion") and selection of notification methods (e.g., checkboxes for "Push notification," "Email," and "SMS"). Changes to the settings are confirmed by clicking the save button. Changes to notification settings, along with the change details and date / time, are recorded in the log.

[0520] <62-2. Example of a repair shop terminal screen> This section describes an example screen for the repair vendor terminal device 300. The repair vendor terminal device 300 is used by repair vendors to create estimates, apply for factoring, and report on the progress of repairs. In typical implementations, it is provided as a web application or desktop application. Screen displays and operations are logged along with the user ID, operation details, and date and time of operation.

[0521] The repair request list screen displays a list of repair requests assigned to repair shops. This screen shows, in a table format, the request ID, vehicle information (make, model year), damage summary, request date and time, and current status (e.g., "Waiting for estimate," "Waiting for estimate approval," "Repair in progress"). Typical implementations provide filtering by status, sorting by request date and time, and keyword search functionality. The display of the repair request list screen, along with the number of requests displayed, filter conditions, and display date and time, is logged.

[0522] The estimate creation screen is used by repair companies to create repair estimates. This screen includes a display area for the estimated repair cost calculated by the AI ​​damage analysis unit 110, a parts list selection section, input fields for the quantity and unit price of each part, input fields for labor costs, input fields for other expenses, and an automatically calculated display of the total amount. In the parts list selection, candidate parts obtained from the parts price DB 152 can be selected using a dropdown menu or a search field. The input content on the estimate creation screen is saved midway through the process using a temporary save function and recorded in the log along with the estimate data being entered.

[0523] The AI ​​estimation comparison display area is part of the estimate creation screen and displays the estimated repair cost created by the repair company side by side with the estimated repair cost calculated by the AI ​​damage analysis unit 110. This area displays the figures in the format "AI Estimate: 250,000 to 350,000 yen" and "Your Estimate: 320,000 yen". If the discrepancy is large (e.g., if it exceeds the upper limit of the estimation range by more than 20%), a warning message (e.g., "The AI ​​estimate is significantly different. Please reconfirm the details.") will be displayed. The contents of the comparison display, along with the displayed estimated value, estimated value, and degree of discrepancy, are recorded in the log.

[0524] The "Submit Estimate" button is pressed when submitting a created estimate to the policyholder and the insurance company. Pressing the button displays a final confirmation dialog for the estimate. The confirmation dialog displays the total amount of the estimate, a breakdown of the main items, and a note that no changes can be made after submission. When the repair company selects "Submit," the estimate is sent to server device 100. The submission of the estimate is logged along with the estimate ID, submission date and time, and estimated amount.

[0525] The factoring application screen is where repair companies apply for factoring. This screen includes fields for selecting the repair case, displaying the amount of the receivable to be applied for (usually the same as the estimated amount), an optional input field for the reason for the application, and a checkbox for agreeing to the terms of service. In practice, a function to apply for multiple repair cases at once may be provided. The display of the factoring application screen and the input of application details are logged along with the input content and the date and time of display.

[0526] The purchase conditions presentation screen is a screen that presents the purchase conditions calculated by the risk score calculation unit 120 to the repair company. This screen includes the display of the integrated risk score (e.g., "Risk score: 75 points"), the purchase rate (e.g., "Purchase rate: 90%"), the commission rate (e.g., "Commission rate: 3%"), the immediate payment amount (e.g., "Immediate payment amount: 273,600 yen"), and the acceptance deadline (e.g., "Acceptance deadline: January 28, 2026, 23:59"). In a typical implementation, a function is provided to expand and display a detailed breakdown of the purchase conditions (values ​​of each risk score, basis for calculating the purchase rate, etc.). The display of the purchase conditions presentation screen is logged along with the displayed conditions and the date and time of display.

[0527] The Accept and Decline buttons are located on the purchase terms presentation screen and are used by repair companies to accept or decline the purchase terms. Pressing the Accept button displays a confirmation dialog box with a confirmation message such as "Are you sure you want to proceed with factoring under these terms?" and the immediate payment amount again. If the repair company selects "Accept" in the confirmation dialog box, the factoring transaction is completed and immediate payment processing begins. The acceptance or decline selection, along with the selection content and date / time, is recorded in the log.

[0528] The factoring transaction history screen is used by repair companies to review the history of factoring transactions they have previously performed. This screen displays each transaction in a table format, including the transaction ID, the target repair project, the application date and time, the purchase rate, the commission rate, the immediate payment amount, and the transaction status (e.g., "Payment Completed," "Awaiting Settlement," "Settlement Completed"). Typical implementations provide filtering by period, status, and transaction amount. The display of the factoring transaction history screen, along with the number of transactions displayed, the filter conditions, and the display date and time, are logged.

[0529] The deposit confirmation screen is used by the repair company to confirm the results of the immediate deposit made by the factoring processing unit 130. This screen displays the recipient's bank account information (only the last four digits of the account number are displayed), the transfer amount, the scheduled transfer date and time, the transfer completion date and time, and the transfer status (e.g., "Processing," "Completed"). Once the transfer is complete, a completion message such as "Transfer completed" is displayed. The display of the deposit confirmation screen is recorded in the log along with the displayed transaction ID and the display date and time.

[0530] The repair progress report screen is used by repair shops to report on the progress of repairs. This screen includes a dropdown menu for selecting the repair status (e.g., "Parts Ordered," "Repair Work Started," "Repair Work Completed," "Ready for Delivery"), a text area for entering progress comments, an area for uploading photos of the repair site, and a field for entering the expected repair completion date. When the submit progress report button is pressed, the report content is sent to the server device 100 and notified to the policyholder and the insurance company. The submission of the repair progress report, along with the report content and submission date and time, is recorded in the log.

[0531] The settlement result confirmation screen is used by repair companies to confirm the results of automatic settlement by the settlement processing unit 140. This screen displays the amount of insurance money received, the amount of factoring principal recovered, the amount of fees recovered, the difference amount to be transferred, and the settlement date and time. If the difference is to be transferred to the repair company, a message such as "The difference of 123,400 yen will be transferred to your designated account on [date]" will be displayed. Conversely, if the difference is to be recovered by the repair company (if the amount of insurance money received is less than the estimated amount), this will be displayed. The display of the settlement result confirmation screen, along with the displayed settlement details and the display date and time, is recorded in the log.

[0532] The repair vendor dashboard screen is designed to provide an overview of the entire operation of a repair vendor at a glance. This screen displays statistical information in widget format, including the number of repair requests received today, the number of requests awaiting estimates, the number of repairs currently underway, the number of factoring usages this month, the total amount of factoring usage this month, the average risk score, and the average purchase rate. In a typical implementation, clicking on each widget will take you to a detailed screen. The display of the repair vendor dashboard screen, along with the displayed statistics and the date and time of display, is recorded in the log.

[0533] The account settings screen is where repair technicians manage their account information. This screen includes fields for displaying and changing the repair technician name, the representative's name, contact phone number, contact email address, and bank account information (bank name, branch name, account type, account number, and account holder name). The password change section provides input fields for the current password, new password, and new password (confirmation). Changes to account settings are confirmed by clicking the save button, and the changes, along with the date and time of the change, are recorded in the log.

[0534] <62-3. Example of a screen on an insurance company's terminal device> This section describes an example screen for the insurance company terminal device 400. The insurance company terminal device 400 is used by insurance company personnel to review estimates and approve payments. In a typical implementation, it is provided as a web application. The display and operation of the screen are logged along with the personnel ID, operation details, and date and time of operation.

[0535] The pending claims list screen displays a list of repair claims that an insurance company representative needs to review. For each claim, the screen displays the claim ID, policyholder name, vehicle information, accident date, estimated cost, AI-estimated repair cost, estimate submission date, and review deadline in a table format. Typical implementations provide sorting options by approaching deadline, deviation from estimated cost to AI estimate, and assignment to a representative. The display of the pending claims list screen, along with the number of claims displayed, sorting criteria, and display date and time, are logged.

[0536] The estimate review screen is used by insurance company representatives to review estimates submitted by repair shops. This screen includes sections for displaying policyholder information, vehicle information, damage images, AI damage analysis results, the repair shop's estimate details, a comparison section with the AI ​​estimate, a text area for entering review comments, and approval and rejection buttons. In the comparison section with the AI ​​estimate, the estimated amount and the AI ​​estimated repair cost are displayed side by side, and any discrepancies are highlighted. The display of the estimate review screen is logged along with the displayed case ID and the date and time of display.

[0537] The estimate approval button is pressed when an insurance company representative approves the estimate. Pressing the button displays an approval confirmation dialog box with a confirmation message such as, "Do you want to approve this estimate?" When the representative selects "Approve," the estimate approval is recorded in the server device 100, and an approval notification is sent to the repair company and the insurance policyholder. The estimate approval is recorded in the log along with the approver ID, approval date and time, and approval comment.

[0538] The "Reject Estimate" button is pressed by the insurance company representative when they reject the estimate. Pressing the button displays a dialog box requesting the reason for rejection. Reasons for rejection can be selected from standard options such as "Estimated amount is too high," "Estimated damage does not match," or "Additional information is needed," or a reason can be entered in free text. Once the representative enters the reason for rejection and selects "Reject," the estimate rejection is recorded in the server device 100, and a rejection notification and the reason for rejection are sent to the repair company. The rejection of the estimate is recorded in the log along with the rejecter ID, the date and time of rejection, and the reason for rejection.

[0539] The payment approval screen is where the insurance company representative approves the payment of insurance benefits after the repairs are completed. This screen displays the contents of the repair completion report, a photo of the vehicle after repairs, the final repair cost (including the reason if there is a change from the estimated amount), the planned payment amount, and the recipient's bank account information. When the payment approval button is pressed, an approval confirmation dialog appears, and if the representative selects "Approve," the insurance payment process begins. Payment approval is recorded in the log along with the approver ID, approval date and time, and payment amount.

[0540] The payment history screen is used by insurance companies to review the history of insurance payments they have made in the past. This screen displays each payment in a table format, including the payment ID, policyholder name, repair shop name, payment amount, payment date, and payment status (e.g., "Processing," "Completed"). Typical implementations provide filtering by time period, repair shop, and sorting by payment amount. The display of the payment history screen, along with the number of payments shown, the filter conditions, and the date and time of display, is logged.

[0541] The statistical analysis screen is used by insurance companies to analyze statistical information on all repair cases. This screen visually displays graphs showing the trend of the number of repairs over time, graphs showing the distribution of repair costs, analysis of the discrepancy between AI estimates and actual estimates, average repair costs by repair company, and the frequency of occurrence by damaged part. The types of graphs used include line graphs, bar graphs, pie charts, and scatter plots. The display of the statistical analysis screen, along with the displayed analysis content, analysis period, and display date and time, is recorded in the log.

[0542] <62-4. Example of administrator screen> This section describes an example of a system administrator screen. The administrator screen is used to monitor the system's operational status and manage its settings. In typical implementations, it is provided as a web application and is accessible only to users with administrator privileges. Screen display and operation are logged along with the administrator ID, operation details, and date and time of operation.

[0543] The system dashboard screen is designed to provide a quick overview of the overall system's operational status. This screen displays real-time information including the current system status (normal, warning, error), the number of factoring transactions for the day, the total transaction amount for the day, the current number of active users, server resource usage (CPU usage, memory usage, disk usage), the number of recent errors, and the number of recent alerts. The status is displayed using color coding (normal: green, warning: yellow, error: red). The system dashboard display, along with the values ​​of each displayed metric and the date and time of display, is logged.

[0544] The Factoring Transaction Monitoring screen is used to monitor currently ongoing and recently completed factoring transactions. This screen displays the transaction ID, factoring company name, application date and time, purchase rate, commission rate, immediate payment amount, and transaction status (application received, under review, transaction completed, payment received, awaiting settlement, settlement completed) for each transaction in real time. Unusual transactions (e.g., extremely high purchase rates, extremely low risk scores) are highlighted. The display of the Factoring Transaction Monitoring screen, along with the number of transactions displayed and the date and time of display, is logged.

[0545] The Risk Score Distribution screen visualizes the distribution of the calculated integrated risk scores. This screen displays a histogram of the integrated risk scores, the distribution of each risk score (SC1-SC5), and a correlation analysis between risk scores and recovery rates. Administrators can check whether the risk score distribution falls within the expected range and consider adjusting the risk scoring algorithm if any anomalies are found. The display of the Risk Score Distribution screen, along with the displayed analysis content, analysis period, and display date and time, is recorded in the log.

[0546] The error log viewing screen is used to view logs of errors that have occurred in the system. This screen displays each error in a table format, including the error ID, date and time of occurrence, error type, error message, location (module name, function name), scope of impact, and resolution status (unresolved, in progress, resolved). Typical implementations provide filtering by error type, sorting by date and time of occurrence, and keyword search functionality. The detailed error view displays the stack trace, logs of related requests, and the system state before and after the error occurred. The display of the error log viewing screen, along with the number of displayed errors, filter conditions, and display date and time, is recorded in the log.

[0547] The parameter settings screen is used to configure various system parameters. This screen contains settings such as the weighting coefficient for risk score calculation, purchase rate table settings, commission rate settings, acceptance deadline settings, and notification sending timing settings. Each setting item displays the current setting value, recommended value, and adjustable range. Changes to settings are confirmed by clicking the save button, and the original and modified values ​​are recorded as history. Changes to parameter settings are logged along with the user ID, changed item, original value, modified value, and date and time of change.

[0548] The user management screen is used to manage the accounts of users who use the system. This screen displays each user's information in a table format, including User ID, Username, User Type (Insurance Policyholder, Repairman, Insurance Company, Administrator), Registration Date and Time, Last Login Date and Time, and Account Status (Active, Inactive, Locked). Administrators can perform operations such as adding new users, editing existing users, deactivating users, and resetting passwords. Operations performed on the user management screen are logged along with the operation type, target user ID, and operation date and time.

[0549] <62-5. Typical Examples of Screen Transitions> This section describes typical screen transitions on various terminal devices. Screen transitions allow users to execute a series of processes in a sequential manner. Screen transitions are logged along with the source screen, destination screen, and date and time of the transition.

[0550] A typical screen transition on the insurance policyholder terminal device 200 follows this flow: The insurance policyholder first displays the damage information input screen and enters the vehicle identification number and damage images. Once the input is complete and the submit button is pressed, the user transitions to the AI ​​damage analysis results display screen, where the estimated repair cost and detected damaged areas are displayed. Subsequently, the user transitions to the estimate confirmation screen to review the estimate submitted by the repair company. After approving the estimate, the user transitions to the repair progress confirmation screen to check the progress of the repairs. This series of screen transitions is logged along with the date and time each screen was displayed and the trigger for the transition (button press, link click, etc.).

[0551] A typical screen transition in the repair vendor terminal device 300 is as follows: The repair vendor first displays the repair request list screen to confirm new repair requests. After selecting a repair request, the vendor transitions to the estimate creation screen and creates an estimate while referring to the AI-estimated repair cost. After submitting the estimate, the vendor returns to the repair request list screen. After the estimate is approved by the policyholder and the insurance company, the vendor transitions to the factoring application screen and applies for factoring. Once the application is accepted, the vendor transitions to the purchase terms presentation screen to confirm the presented purchase terms. After accepting the purchase terms, the vendor transitions to the payment confirmation screen to confirm the completion of immediate payment. This series of screen transitions is logged along with the date and time each screen was displayed and the trigger for the transition.

[0552] A typical screen transition on the insurance compan...

Claims

1. An information processing system, An acquisition unit that acquires first information about the subject, An estimation unit that estimates attribute information about the target using a trained model based on the first information, A determination unit that determines condition information based on the estimated attribute information, A recording unit that records the processing history of at least a part of the acquisition unit, estimation unit, and determination unit. An information processing system equipped with the following features.

2. In the information processing system described in claim 1, The acquisition unit identifies second information to be acquired using the trained model based on the first information, and acquires the second information. The estimation unit is characterized by estimating the attribute information based on the first information and the second information.

3. In the information processing system according to claim 1 or 2, The aforementioned items are the goods subject to the transaction. The attribute information includes at least one of the following: the value, condition, risks, or performance of the article. The aforementioned conditional information is characterized by including at least one of the following: advance payment amount, purchase rate, commission rate, transaction eligibility, or settlement conditions.

4. In the information processing system described in claim 3, The system further includes a risk score calculation unit that calculates multiple risk factor scores and integrates these multiple risk factor scores based on weighting coefficients to calculate an integrated risk score. The information processing system is characterized in that the determination unit determines the condition information based on the integrated risk score.

5. In the information processing system according to any one of claims 1 to 4, The aforementioned recording unit is The date and time information from which the attribute information was estimated by the estimation unit, The types and values ​​of the features used in the estimation, The contribution of the aforementioned feature to the aforementioned estimation, The uncertainty or confidence interval of the aforementioned estimation result, An information processing system characterized by recording a processing history including at least one of the following in a format that allows for tamper detection using a timestamp and hash chain.

6. In the information processing system according to any one of claims 1 to 5, At least two of the acquisition unit, estimation unit, determination unit, and recording unit are located in different devices connected via a communication network. The information processing system is characterized in that the processing history includes communication logs between the different devices.

7. In the information processing system according to any one of claims 3 to 6, An execution unit that executes or instructs settlement processing based on the aforementioned conditional information and generates a transaction record, An information processing system further comprising: a settlement unit that receives a settlement notification, compares the deposit information contained in the settlement notification with the transaction record, and performs settlement processing.

8. A method of information processing performed by a computer, The acquisition process involves obtaining the first information about the subject, An estimation step is performed to estimate attribute information about the object using a trained model based on the first information, A decision step to determine condition information based on the estimated attribute information, A recording step which records the processing history of at least a part of the acquisition step, estimation step, and determination step in a format that allows for tamper detection using a timestamp and hash chain; Information processing methods including

9. In the information processing method described in claim 8, The acquisition step includes the step of identifying second information to be acquired in addition using the trained model based on the first information, and the step of acquiring the second information. The estimation step is characterized by estimating the attribute information based on the first information and the second information.

10. In the information processing method according to claim 8 or 9, The aforementioned items are the goods subject to the transaction. The process of calculating multiple risk factor scores, The process further includes a step of integrating the aforementioned multiple risk factor scores based on weighting coefficients to calculate an integrated risk score, The aforementioned decision step is performed based on the integrated risk score, An information processing method characterized by determining at least one of the following: the advance payment amount, the purchase rate, the commission rate, whether a transaction is possible or not, or the settlement conditions.

11. In the information processing method described in claim 10, An execution step which executes or instructs settlement processing based on the aforementioned condition information and generates a transaction record, A settlement process that receives a settlement notification, compares the deposit information contained in the settlement notification with the transaction record, and performs settlement processing; An information processing method characterized by further including the following.

12. Computers, means for obtaining first information concerning the subject, Estimation means for estimating attribute information about the object using a trained model based on the first information, A determination means for determining condition information based on the estimated attribute information, and The processing history of at least a part of the acquisition means, estimation means and determination means is Recording means that record in a tamper-detectable format using timestamps and hash chains. A program designed to function as such.

13. A program for causing a computer to execute the information processing method described in any one of claims 8 to 11.

14. A computer-readable recording medium having the program described in claim 12 or 13 recorded on it.

15. A terminal device capable of communicating with the information processing system described in any one of claims 1 to 7, An input unit for inputting at least one of the first information and the second information, A terminal device comprising a display unit that receives and displays the aforementioned condition information.

Images