System and method for exchange goods with time-based rational pricing and secure transaction control

Abstract

A goods exchange system for the reasonable pricing and secure trading of goods including time is disclosed. The goods exchange system for the reasonable pricing and secure trading of goods including time includes a user terminal device in which a transaction registrant registers transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time; a bidding terminal device in which bid amounts and user information are registered from multiple bidders; and a server that communicates with the user terminal device and the bidding terminal device to determine a successful bidder based on the remaining time until the transaction time, the bid amount, distance information from the transaction location, user trust indicators, and past transaction history information, and performs meeting authentication and settlement between the successful bidder and the transaction registrant. Accordingly, it is possible to select a successful bidder that reasonably reflects the possibility of transaction fulfillment based on the imminent time, reduce the risk of non-fulfillment that may occur in a simple highest bid method, and manage transaction risks in advance by calculating a no-show risk score and adjusting the comprehensive score. Furthermore, it is possible to provide a safe and reliable trading environment by accurately verifying the identity of the transaction parties.

Description

Technology Field

[0001] The present invention relates to a goods exchange system and a control method for the reasonable price calculation and secure transaction of goods including time. More specifically, the present invention relates to a system for determining a successful bidder at the time of transaction for the transaction of goods including time, determining the identity of the successful bidder, and performing settlement. Background Technology

[0002] With the recent advancement of information and communication technology and the widespread adoption of mobile devices, the trading of goods and services is rapidly shifting toward a form conducted through online platforms. In particular, there is an increasing number of platform services that trade not only specific goods but also the user's time itself, while transaction structures based on offline meetings are also being utilized across various fields.

[0003] For example, person-to-person meetings, class participation, accompanying for a set period, consulting, and guide services all involve a fixed time unit as the subject of transaction, and are operated in a manner where a transaction registrant proposes a specific time and location and multiple users express their intention to participate.

[0004] In conventional time-based trading platforms, the following methods are generally used.

[0005] First, regarding the bidding structure, most platforms rely on a highest-bid system or a first-come, first-served reservation method. In other words, the general structure determines the winner as the user who offers the highest amount among those meeting the transaction conditions, or the transaction is concluded by the user who completes the reservation first. While this method ensures transaction speed, it has limitations in that it is difficult to comprehensively reflect various factors such as the time remaining until the transaction, physical distance from the transaction location, user trustworthiness, and past transaction history.

[0006] Second, in conventional technology, the remaining time until the transaction is often not substantially reflected in price determination. For example, even when the transaction is imminent, maintaining a bidding structure based solely on price can lead to the problem of a user with a low probability of actually fulfilling the transaction being awarded the contract. In particular, for transactions contingent on an in-person meeting, the likelihood of fulfillment or the risk of a no-show can vary depending on the time imminent; however, structures that quantitatively reflect these factors are currently inadequate.

[0007] Third, conventional methods for managing user trust primarily rely on post-transaction evaluations provided in the form of star ratings or reviews. However, these ratings are utilized merely as reference indicators for subsequent transactions, and their integration into a structure where weights are dynamically adjusted during the actual process of determining the winning bidder is limited. In particular, a systematic structure is not sufficiently established to quantify risk factors, such as past transaction non-fulfillment history or no-show rates, and incorporate them into bid calculation formulas.

[0008] Fourth, although the procedure to verify the fulfillment of a transaction is crucial in transactions based on offline meetings, conventional methods often rely on formal authentication means such as simple QR code scanning or check button input. This approach has problems, such as failing to sufficiently verify the actual identity or the possibility of forgery or alteration using pre-stored images or audio files. In particular, authentication methods that mandate real-time photography or voice recording and include a structure to compare such data with biometric information stored on a server are generally not implemented.

[0009] Fifth, while conventional settlement structures are linked to transaction fulfillment, the mechanism for partial settlement based on individually assessing each participant's actual attendance in group transactions involving multiple successful bidders is not sufficiently systematized. Furthermore, as simple non-refund or lump-sum refund methods are frequently applied in the event of a no-show, there is a lack of organic integration with structures designed to adjust transaction risks in advance during the price calculation stage.

[0010] Consequently, there is an increasing need for eKE, a new technology designed to solve the aforementioned conventional problems. The problem to be solved

[0011] The objective of the present invention is to provide a goods exchange system and a control method thereof for the reasonable price calculation and safe transaction of goods including time, for the purpose of determining a successful bidder at the time of transaction for the transaction of goods including time, determining the identity of the successful bidder, and performing settlement. means of solving the problem

[0012] A goods exchange system for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention for achieving such objectives may include a user terminal device in which a transaction registrant registers transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time point; a bidding terminal device in which a plurality of bidders register bid amounts and user information; and a server that communicates with the user terminal device and the bidding terminal device to determine a successful bidder based on the remaining time until the transaction time point, the bid amount, distance information from the transaction location, a user trust indicator, and past transaction history information, and performs meeting authentication and settlement between the successful bidder and the transaction registrant.

[0013] Here, the server calculates the remaining time until the transaction time, selects one of a set of different weight calculation functions according to the interval of the remaining time, calculates a comprehensive score by assigning weights to a plurality of elements including the bid amount, distance information from the transaction location, the user trust indicator, and past transaction history information according to the selected weight calculation function, and can determine the successful bidder.

[0014] In addition, the server may assign an increased weight to the user trust indicator and the history of non-fulfillment among the past transaction history information as the time of the transaction approaches.

[0015] Additionally, the server may apply a first weighting formula when the remaining time is greater than or equal to a first reference time, apply a second weighting formula when the remaining time is greater than or equal to a second reference time but less than the first reference time, apply a third weighting formula when the remaining time is less than the second reference time, and the third weighting formula may be configured such that the weight for non-fulfillment history among the user trust indicator and past transaction history information is increased compared to the first weighting formula.

[0016] In addition, the server receives the transaction amount from the successful bidder and deposits it into an escrow account, verifies whether the transaction has been fulfilled through one-time authentication information generated in real-time during an offline meeting to generate a meeting authentication result, and can automatically settle the amount in the escrow account according to the meeting authentication result.

[0017] Additionally, the user terminal device transmits the one-time authentication information, which includes a face image captured in real time at the transaction site or voice information recorded in real time, to the server, and the server determines the identity by comparing the transmitted face image or voice information with the biometric information of the successful bidder stored in advance, and the captured face image or voice information recorded in real time may be blocked from being stored in the user terminal device.

[0018] In addition, the server may calculate a no-show risk score based on the number of times the user has a past non-fulfillment history, the transaction non-fulfillment rate, and the recent transaction success rate, and correct the calculated comprehensive score by reflecting the no-show risk score in the first to third weighting formulas.

[0019] In addition, if the winning bidder is a group including multiple users, the server may individually determine whether each user is attending and partially settle only the amount corresponding to the user for whom the meeting authentication result was generated.

[0020] Meanwhile, a control method for a goods exchange system for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention may include: a step of a transaction registrant registering transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time point through a user terminal device; a step of registering bid amounts and user information from a plurality of bidders through a bidding terminal device; and a step of performing communication with the user terminal device and the bidding terminal device by a server to determine a successful bidder based on the remaining time until the transaction time point, the bid amount, distance information from the transaction location, a user trust indicator, and past transaction history information, and performing meeting authentication and settlement between the successful bidder and the transaction registrant. Effects of the invention

[0021] According to various embodiments of the present invention as described above, by applying different weighting functions based on the remaining time until the transaction, it is possible to select a winning bidder that reasonably reflects the possibility of transaction fulfillment based on the time imminent. Accordingly, the risk of non-fulfillment that may occur in a simple highest-bid award method can be reduced. Furthermore, transaction risks can be managed in advance by dynamically weighting user trust indicators and past non-fulfillment history, and by calculating a no-show risk score to adjust the overall score. In addition, by comparing real-time biometric-based one-time authentication information generated during an offline meeting with the server, the identity of the transaction parties can be accurately verified, and by automatically settling escrow funds based on the authentication result, a safe and reliable transaction environment can be provided. Brief explanation of the drawing

[0022] FIG. 1 is a block diagram illustrating the configuration of a goods exchange system for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention. FIG. 2 is a flowchart illustrating a control method for a goods exchange system for reasonable price calculation and safe transaction of goods including time according to an embodiment of the present invention. FIG. 3 is a block diagram illustrating the specific configuration of the server shown in FIG. 1. FIG. 4 is a drawing relating to a software module stored in a storage unit according to an embodiment of the present invention. Specific details for implementing the invention

[0023] The present invention will be described in more detail below with reference to the drawings. Furthermore, in describing the present invention, detailed descriptions of related known functions or configurations are omitted if it is determined that such detailed descriptions would unnecessarily obscure the essence of the invention. Additionally, the terms described below are defined considering their functions in the present invention, and these may vary depending on the intentions or relationships of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0024] FIG. 1 is a block diagram illustrating the configuration of a goods exchange system for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention.

[0025] Referring to FIG. 1, a goods exchange system (100) for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention may include a user terminal device (110), a server (120), and a bidding terminal device (130), and the user terminal device (110) may allow a transaction registrant to register transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time.

[0026] Here, the user terminal device (110) may include various types of user terminal devices such as mobile phones, PCs, laptops, desktops, etc., owned by the user for selling goods including time.

[0027] Additionally, the bidding terminal device (130) can register bid amounts and user information from multiple bidders, and when the user terminal device (110) registers transaction information, it can register bid amounts and user information, that is, information of the bidding user, for the corresponding transaction information. Here, the bidding terminal device (130) may include various types of terminal devices, such as mobile phones, PCs, laptops, desktops, etc., for registering bid amounts and user information.

[0028] And, the server (120) can communicate with the user terminal device and the bidding terminal device to determine the winning bidder based on the remaining time until the transaction time, the bid amount, distance information from the transaction location, the user trust indicator and past transaction history information, and can perform meeting authentication and settlement between the winning bidder and the transaction registrant.

[0029] Specifically, the server (120) calculates the remaining time until the time of the transaction, selects one of a set of different weight calculation functions according to the interval of the remaining time, and calculates a comprehensive score and determines the winning bidder by assigning weights to a plurality of elements including the bid amount, distance information from the transaction location, user trust indicator, and past transaction history information according to the selected weight calculation function.

[0030] Here, when the transaction registration is completed, the server (120) can calculate the difference between the current time and the transaction time to calculate the remaining time (T) until the transaction time. The remaining time (T) can be converted into hours or minutes, and the server (120) can determine which time interval the transaction belongs to by comparing the calculated remaining time (T) with a plurality of pre-set time intervals.

[0031] According to one embodiment of the present invention, the server (120) may be configured to select one of different sets of weight calculation functions in response to the remaining time (T). Here, a set of weight calculation functions refers to a combination of weight coefficients or a calculation formula applied when calculating a comprehensive score for determining the winning bidder.

[0032] Specifically, the server (120) can collect the bid amount (P), distance information from the transaction location (D), user trust index (R), and past transaction history information (H) for each bidder, normalize them, and then calculate a comprehensive score. At this time, the comprehensive score can be calculated by summing the results of multiplying each element by a different weight. For example, the comprehensive score can be calculated using the following mathematical formula.

[0033]

[0034] Here, P represents the bid amount (normalized value), D represents distance information from the transaction location (proximity score), R represents the user trust index, H represents past transaction history information (including non-compliance penalty), and ω1, ω2, ω3, and ω4 represent weighting coefficients for each element. The total score can be normalized to a range of 0 to 100, and the server (120) can determine the bidder with the highest total score as the winner.

[0035] For example, if the remaining time until the transaction is 24 hours or more, it is determined that there is sufficient preparation time for the transaction to be executed, and the server (120) may apply a first set of weight calculation functions. In this case, it may be set to assign a relatively high weight to the bid amount (P) and a relatively low weight to the user trust indicator (R) and past transaction history information (H). Accordingly, a price competition-centered bidding structure may be formed.

[0036] Here, the first set of weight calculation functions (T 24 hours) is equal to the following mathematical formula.

[0037]

[0038] In other words, the highest weight is assigned to the bid amount (P) and the lowest weight to the history of non-performance (H), because the transaction risk is judged to be relatively low.

[0039] On the other hand, if the remaining time until the transaction is 3 hours or more but less than 24 hours, the server (120) may apply a second set of weighting functions because consideration of the possibility of transaction execution is required. In this case, the weighting for distance information (D) from the transaction location may be increased to give an advantage to the bidder who is actually more likely to reach the location. Additionally, the reflection ratio for the user trust indicator (R) may be maintained or increased slightly to induce the user who is more likely to execute the transaction to win the bid.

[0040] Here, the second set of weight calculation functions (3 hours T (24 hours) is equal to the following mathematical formula.

[0041]

[0042] That is, compared to the first set of weighting functions, the weight of location proximity (D) has increased relatively, the weight of the bid amount (P) has decreased relatively, and the weight of the user trust indicator (R) is maintained.

[0043] Furthermore, if the remaining time until the transaction is very imminent, being less than 3 hours, the server (120) may apply a third set of weighting functions. In this case, it may be configured to prioritize the possibility of transaction fulfillment over the simple bid amount. That is, the weight for non-fulfillment history among the user trust indicator (R) and past transaction history information (H) may be increased compared to the first weighting formula.

[0044] Here, the third set of weight calculation functions (T < 3 hours) is as follows:

[0045]

[0046] Here, H' is a value that incorporates an enhanced correction for penalty deductions for past non-compliance history, rather than a simple history score. Specifically, H' can be defined as shown in the following mathematical formula.

[0047]

[0048] Here, NoShowRate is the historical no-show rate, and α represents the penalty coefficient. In other words, it can be set to work against users with a high history of past non-performance when the transaction time is imminent.

[0049] For example, the score can be adjusted by deducting a no-show risk score, calculated based on the number of past no-shows, the transaction non-fulfillment rate, and the recent transaction success rate, from the overall score. In this case, the no-show risk score can be set to increase proportionally to the number of non-fulfillments, and configured to impose additional deductions as the recent transaction success rate decreases. Accordingly, when the remaining time is very short, users with a history of frequent non-fulfillments naturally receive unfavorable scores.

[0050] Additionally, the server (120) can calculate the total score of each bidder according to the set of weight calculation functions selected as above, and determine the bidder who obtained the highest score among them as the winning bidder. According to this structure, even if the same bid amount is submitted, different evaluation results may be derived depending on the remaining time until the transaction time, and this provides the effect of dynamically reflecting transaction risk according to the time imminent.

[0051] Accordingly, the server (120) according to one embodiment of the present invention can implement a winning bidder determination structure that balances price factors and transaction fulfillment possibilities by switching a set of weighting functions according to the remaining time until the transaction time, rather than a simple highest bid method. Through this, the possibility of a no-show can be reduced and transaction stability can be improved.

[0052] Meanwhile, the server (120) can increase the weight for non-fulfillment history among user trust indicators and past transaction history information as the transaction time approaches.

[0053] Additionally, as described above, the server (120) applies a first weighting formula when the remaining time is greater than or equal to a first standard time, applies a second weighting formula when the remaining time is greater than or equal to a second standard time but less than a first standard time, applies a third weighting formula when the remaining time is less than a second standard time, and the third weighting formula may be set such that the weight for non-fulfillment history among user trust indicators and past transaction history information is increased compared to the first weighting formula.

[0054] Specifically, the server (120) may be configured to gradually increase the weight of user trust indicators and past transaction history information, particularly the history of non-fulfillment, as it determines that consideration of the possibility of transaction fulfillment becomes more important as the remaining time until the transaction decreases.

[0055] Generally, when there is sufficient time remaining until the transaction date, there is a possibility that the bidder will fulfill the transaction by adjusting the schedule or changing the travel plan, so the server (120) may place relatively high weight on factors such as the bid amount or proximity to the location. However, as the transaction date approaches, the possibility of changing the schedule decreases, and if a user with a low probability of actual fulfillment is awarded the bid, the risk of a no-show increases significantly. Accordingly, the server (120) may adopt a structure that gradually increases the weight for user reliability indicators and past non-fulfillment history as the remaining time decreases.

[0056] Specifically, the server (120) may be configured to apply a first weighting formula when the remaining time is greater than or equal to a first reference time. The first weighting formula may be set to assign a relatively high weight to the bid amount and a relatively low weight to user trust indicators and past transaction history information. This is because it is determined that the impact on transaction stability is relatively limited even if economic conditions are prioritized, as there is sufficient time remaining until the time of the transaction.

[0057] Next, if the remaining time is greater than or equal to the second reference time and less than the first reference time, the second weighting formula may be applied. The second weighting formula may be configured to increase the weight for user trust indicators compared to the first weighting formula and to partially expand the reflection ratio of non-fulfillment history among past transaction history information. Through this, users who are more likely to actually fulfill the transaction as the transaction time approaches may be evaluated more favorably.

[0058] Furthermore, if the remaining time is less than the second standard time, a third weighting formula may be applied. The third weighting formula may be configured such that the weight for non-fulfillment history among user trust indicators and past transaction history information is significantly increased compared to the first weighting formula. For example, it may be configured to apply an expanded penalty coefficient to the number of past no-shows, the no-show rate, and whether non-fulfillment occurred within a recent period, or to perform additional penalty deductions if the non-fulfillment history exceeds a certain standard.

[0059] In this way, the server (120) can be configured to apply different weighting formulas according to the interval of the remaining time, thereby increasing the impact of past non-performance history on the overall score as the time of the transaction approaches. As a result, even when the same bid amount is submitted, users who have faithfully performed past transactions maintain a relatively high evaluation, while users who have repeatedly caused no-shows receive an unfavorable evaluation when the time of the transaction is approaching.

[0060] Accordingly, according to one embodiment of the present invention, the server (120) can effectively reduce transaction risk in time-imminent situations by not merely using past history as a reference indicator, but by dynamically adjusting the weight of non-fulfillment history in conjunction with the remaining time until the transaction time. Through this, the probability of a user with a high probability of actual fulfillment being selected as the winning bidder can be improved, and overall transaction stability can be increased.

[0061] Meanwhile, the server (120) can calculate a no-show risk score based on the number of times the user has a past history of non-fulfillment, the transaction non-fulfillment rate, and the recent transaction success rate, and can correct the calculated overall score by reflecting the no-show risk score in the first to third weighting formulas.

[0062] Specifically, the server (120) may be configured to calculate a no-show risk score based on the number of past non-fulfillment history, the transaction non-fulfillment rate, and the recent transaction success rate to more quantitatively reflect the transaction reliability of each user. Here, the no-show risk score is an indicator that quantifies the likelihood that the user will not fulfill a transaction in the future, and can be used to adjust the overall score during the process of determining the winning bidder.

[0063] Specifically, the server (120) can analyze user-specific transaction history information stored in a database to calculate the ratio of non-fulfillment to the total number of transactions. Additionally, by calculating the transaction success rate for a recent period (e.g., the last month or the last 10 transactions), it can reflect not only the simple cumulative history but also the reliability of recent activity. For example, if a record of faithful fulfillment was shown in all past transactions but non-fulfillment has been repeated in a short period recently, the no-show risk score can be adjusted upward.

[0064] Additionally, the server (120) can calculate a no-show risk score by combining multiple elements. For example, the risk score can be set to increase linearly as the number of non-performances increases, and can be configured to increase non-linearly by applying additional weights when the non-performance rate exceeds a certain standard. Additionally, if the recent transaction success rate is low, the risk score can be amplified by applying an additional penalty coefficient.

[0065] The no-show risk score calculated in this manner can be reflected in the first to third weighting formulas and used to correct the overall score. For example, the server (120) can calculate a first overall score for each bidder based on the bid amount, distance information, user trust indicators, and past transaction history information, and then calculate the final overall score by subtracting the no-show risk score from the first overall score. Alternatively, the no-show risk score can be corrected by converting it into a deduction coefficient and multiplying it by the overall score.

[0066] In particular, when the third weighting formula is applied when the transaction time is imminent, the impact of the no-show risk score on the overall score can be further amplified. That is, by configuring it so that a greater penalty effect occurs when the remaining time is short, even with the same no-show risk score, transaction risk in imminent situations can be controlled more actively.

[0067] According to this structure, rather than merely utilizing past history as reference information, the user's transaction reliability can be quantified and directly reflected in the bidder determination stage. As a result, users with a history of repeated non-performance naturally have a lower chance of winning the bid, while users who have consistently and faithfully fulfilled their transactions receive a relatively favorable evaluation.

[0068] Accordingly, the server (120) can calculate a no-show risk score and reflect it in a weighting formula, thereby ensuring transaction stability in advance and implementing a reasonable bidding structure that prioritizes the selection of users with a high probability of actual fulfillment. Through this, the reliability of goods transactions involving time, which are based on offline meetings, can be substantially improved.

[0069] Meanwhile, the server (120) receives the transaction amount from the winning bidder and deposits it into an escrow account, verifies whether the transaction has been fulfilled through one-time authentication information generated in real-time during an offline meeting to generate a meeting authentication result, and can automatically settle the amount in the escrow account according to the meeting authentication result.

[0070] Here, the user terminal device (110) transmits one-time authentication information, including a face image captured in real time at the transaction site or voice information recorded in real time, to the server (120), and the server (120) determines whether the transmitted face image or voice information is the same person by comparing it with the biometric information of the winning bidder stored in advance, and the captured face image or voice information recorded in real time may be blocked from being stored in the user terminal device.

[0071] In addition, as described above, not only is the determination of whether the successful bidder is the same person performed through the user terminal device (110), but the determination of whether the user who registered the transaction information is the same person can also be performed through the bidding terminal device (130).

[0072] Specifically, the server (120) may be configured to receive the transaction amount from the winning bidder and deposit it into an escrow account once the winning bidder is determined. The escrow account serves as a temporary deposit method for holding the amount until the transaction is confirmed to be executed, and the server (120) may control the process so that the offline meeting procedure proceeds only after the transaction amount has been successfully deposited.

[0073] Additionally, when an offline meeting is initiated, the server (120) may be configured to verify whether the transaction has been executed through one-time authentication information generated in real time. Here, “one-time authentication information” refers to authentication information that is valid only for a specific transaction and at a specific time, and means information that can be generated and used only at the transaction site.

[0074] Specifically, the user terminal device (110) can acquire face image or voice information in real time by using a camera or microphone equipped on the terminal at the transaction site. At this time, the acquired face image may be in the form of a video captured for a certain period of time or longer rather than a simple still image, and the voice information may also be voice data recorded immediately through the terminal rather than a file stored in advance.

[0075] Additionally, the user terminal device (110) can immediately transmit one-time authentication information, including data captured or recorded in real time, to the server (120). At this time, the face image or voice information may be blocked from being stored in the storage medium of the user terminal device (110). For example, it may be configured to be encrypted and transmitted to the server (120) simultaneously with the capture or recording, and to exist only in a temporary buffer within the terminal until it is automatically deleted after transmission is complete. This prevents attempts at forgery or alteration using previously stored image or voice files.

[0076] Additionally, the server (120) can determine identity by comparing the transmitted face image or voice information with the corresponding user's biometric information that has been previously registered and stored on the server. For example, it can extract feature points using a face recognition algorithm and compare them with previously registered face data, or analyze voiceprint features to determine whether they match previously registered voice patterns. In this case, it can be determined that identity authentication is complete only when a similarity level exceeding a certain standard is confirmed.

[0077] In addition, the aforementioned identity verification procedure is not performed only on the successful bidder, but can also be performed in the same way on the user who has registered transaction information. That is, at the transaction site, the identity of the successful bidder can be verified through the user terminal device (110) that has registered transaction information, and at the same time, the identity of the transaction registrant can also be verified using real-time biometric information through the successful bidder's bidding terminal device (130).

[0078] Through this, the server (120) can generate a meeting verification result as “transaction fulfillment completed” only when identity verification is completed for both parties to the transaction. If verification of one or both parties is not completed, it can be determined that the transaction fulfillment has not been established, and in this case, the server (120) can be configured to record the reason and perform subsequent procedures according to a pre-set policy.

[0079] When a meeting authentication result is generated, the server (120) can automatically settle the transaction amount deposited in the escrow account according to the authentication result. For example, if both parties' identity authentication is completed and the transaction execution is confirmed, the deposited amount is paid to the transaction registrant, and if authentication is not completed, it can be processed according to a refund or sanction policy.

[0080] According to this structure, the server (120) can more accurately determine whether an actual meeting has taken place through a self-identification procedure based on real-time biometric information, rather than relying on formal authentication that simply relies on a check button or QR code input. In addition, the possibility of forgery or tampering can be reduced by blocking authentication data from being stored on the terminal device, and fairness and reliability of the transaction can be simultaneously secured by performing the same level of authentication on both the winning bidder and the transaction registrant.

[0081] Accordingly, according to one embodiment of the present invention, the server (120) can substantially improve the safety and reliability of time-inclusive goods transactions based on offline meetings by organically linking escrow deposit, real-time biometric-based meeting authentication, and automatic settlement.

[0082] Meanwhile, if the winning bidder is a group including multiple users, the server (120) can individually determine whether each user attends and partially settle only the amount corresponding to the user for whom the meeting authentication result was generated.

[0083] Specifically, the server (120) may be configured to individually determine whether each user has fulfilled a transaction when the winning bidder is in the form of a group including multiple users, and to partially settle only the amount corresponding to the user for whom the meeting authentication result was generated.

[0084] Generally, in structures where multiple successful bidders participate in a single transaction—such as class participation, group gatherings, or escort services for a set period—there may be instances where only some users actually attend while others do not. Traditionally, in such situations, methods involving the lump-sum settlement or refund of the entire transaction amount were frequently used; however, this can lead to problems where the actual scope of performance does not match the settlement results.

[0085] According to one embodiment of the present invention, the server (120) may be configured to manage individual escrow deposit information for each successful bidder when a group transaction is established. That is, when multiple successful bidders each deposit the transaction amount, the server (120) records an independent deposit amount for each successful bidder and can track the amount individually.

[0086] Additionally, during offline meetings, one-time authentication information generated in real-time for each successful bidder can be used to individually determine their identity and attendance. For example, each successful bidder transmits real-time face video or voice information through their terminal device, and the server (120) can compare this with previously registered biometric information to determine whether the user is actually attending. In this case, if a specific successful bidder fails to complete authentication or does not perform the authentication procedure, the system may be configured so that no meeting authentication result is generated for that successful bidder.

[0087] Additionally, the server (120) can individually generate meeting authentication results for each successful bidder and settle only the deposit amount corresponding to the user whose authentication is complete to the transaction registrant. On the other hand, for users whose authentication is not complete, subsequent measures such as processing a refund according to a pre-set policy or returning the remaining amount after deducting a penalty fee can be performed.

[0088] For example, in a group transaction involving 10 successful bidders, if only 7 have completed authentication, the server (120) may be configured to pay only the amount corresponding to 7 of the total deposit amount to the transaction registrants, and the amount corresponding to the remaining 3 may follow a separate processing procedure. By applying a partial settlement structure in this way, fair settlement corresponding to the actual scope of execution becomes possible.

[0089] Additionally, the server (120) can be configured to individually record the attendance and authentication results of each user so that such information is reflected in subsequent user trust indicators or non-performance history information. That is, users who do not participate in a group transaction may have their individual non-performance history accumulated, which may act disadvantageously in the future process of determining the winning bidder.

[0090] According to this structure, even when only some users participate in a group transaction, the relationship of rights and obligations between the transaction registrant and the participating users can be clearly defined, and the irrationality that may arise from a method of processing the entire transaction amount in a lump sum can be prevented. Therefore, according to one embodiment of the present invention, the server (120) can simultaneously ensure fairness and reliability of the transaction by performing settlement corresponding to the actual scope of execution even in a group transaction in which multiple users participate.

[0091] Meanwhile, according to another embodiment of the present invention, the server (120) may be configured to amplify the weights for user trust indicators and past transaction history information based on a non-linear function, rather than increasing them in a simple linear manner as the remaining time until the transaction decreases.

[0092] Specifically, the server (120) can be configured so that the penalty coefficient for the history of non-compliance increases in the form of an exponential function, an inverse function, or a logarithmic function as the remaining time (T) decreases. For example, by configuring the penalty coefficient to increase rapidly when the remaining time decreases below a certain threshold, the impact of past non-compliance history on the overall score can be accelerated when the time of transaction is very imminent.

[0093] According to this non-linear amplification structure, going beyond simply adjusting weights, it is possible to quantitatively amplify and reflect transaction risk based on time urgency, thereby more effectively suppressing the possibility of no-shows in time-sensitive situations.

[0094] According to another embodiment, the server (120) can calculate the probability of reaching the transaction location by comprehensively considering not only simple distance information to the transaction location, but also the current location information of the user terminal device (110) and the bidding terminal device (130), real-time traffic information, and estimated travel time.

[0095] Specifically, the server (120) can calculate the estimated time required from the current location of the bidding terminal device (130) to the transaction location by linking with a map information providing server, and determine whether the estimated time required falls within the remaining time until the transaction time. In addition, a reachability score can be calculated by further considering traffic congestion, information on means of transportation, and past movement patterns.

[0096] These reachability scores may be reflected as separate weighting factors when calculating the overall score, or included in the calculation of the no-show risk score. Accordingly, the system can be configured so that users who are more likely to actually reach the transaction location receive a higher evaluation.

[0097] According to another embodiment, the server (120) may be configured to perform location-based authentication in parallel with biometric-based authentication.

[0098] Specifically, during an offline meeting, the user terminal device (110) and the bidding terminal device (130) can each transmit their respective GPS coordinate information to the server (120), and the server (120) can determine whether the location information of both parties is within a pre-set allowable error range. Additionally, the system may be configured to determine that authentication is complete only when direct signal exchange between the two terminals occurs via near-field wireless communication (NFC, Bluetooth, etc.).

[0099] In this way, by simultaneously performing biometric authentication and spatial identity verification, it is possible to go beyond simple identity verification and even verify whether a meeting took place at the actual same location.

[0100] Meanwhile, according to another embodiment of the present invention, the server (120) may be configured to generate a “Proof of Meeting Token” that can only be generated at the transaction site and to link it with settlement processing in order to more reliably determine whether an offline meeting has actually been performed and to leave evidence in a form that is difficult to falsify or alter even in the event of a subsequent dispute.

[0101] Specifically, at the time when the winning bidder and the transaction registrant arrive at the transaction location and perform the meeting authentication procedure, the server (120) may combine at least two of the following to generate a one-time joint proof token dependent on the transaction: (i) a real-time biometric authentication result (a face image or voice-based identity authentication success value) obtained from the winning bidder's terminal, (ii) a real-time biometric authentication result obtained from the transaction registrant's terminal, (iii) location information (e.g., GPS coordinates) and time information (e.g., timestamp) of both terminals, and (iv) a near-field identification value (e.g., Bluetooth / BLE beacon signal strength, NFC tag / handshake value) exchanged through near-field communication between both terminals.

[0102] For example, the server (120) may generate a token value by combining the aforementioned elements into a single data bundle and then performing a hash operation, and the generated token value may be linked with a transaction identifier (ID) and recorded in the server's storage unit (123). At this time, since the joint evidence token is designed to be generated only for specific transactions and at specific times and places, it has the characteristic that it is difficult for a third party to arbitrarily generate it or reuse an existing token afterward. In addition, the original biometric information (face image or voice data) used in the process of generating the joint evidence token may be blocked from being stored on the user terminal, and the server side may also be configured to generate the token using only irreversible result values, such as features or whether authentication was successful, without storing the original.

[0103] Additionally, the server (120) may be configured to confirm the meeting authentication result as “transaction execution completed” only when the joint evidence token is successfully generated, and to automatically settle the funds deposited in the escrow account. Conversely, even if biometric authentication is successful, if the mutual presence based on near-field communication (simultaneous presence in the same space) is not satisfied, or if the consistency of location and time information does not meet the criteria and the joint evidence token is not generated, the server (120) may process the meeting authentication result as “incomplete” or “additional verification required,” withhold payment settlement, or switch to a dispute resolution procedure.

[0104] Additionally, in the case of a group transaction, the server (120) may be configured to individually generate a joint proof token for each participant and to partially settle only the deposit corresponding to the participant for whom the joint proof token was generated. Accordingly, actual attendees and non-attendees can be technically clearly distinguished, and even in dispute situations where some participants claim to have "attended" afterward or, conversely, claim that "the other party did not come," the server (120) can objectively determine whether the transaction was executed based on the verification results of whether the joint proof token was generated and the time, location, and proximity used for generation.

[0105] According to such a shared evidence token-based structure, going beyond simply handling no-shows through scoring or terms and conditions, it is possible to generate and record technically verifiable data confirming the establishment of offline meetings and directly link this to settlement, thereby significantly improving transaction stability and dispute response capabilities.

[0106] FIG. 2 is a flowchart illustrating a control method for a goods exchange system for reasonable price calculation and safe transaction of goods including time according to an embodiment of the present invention.

[0107] Referring to FIG. 2, a control method for a goods exchange system for reasonable price calculation and safe transaction of goods including time according to an embodiment of the present invention may include: a step (S110) in which a transaction registrant registers transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time point through a user terminal device; a step (S120) in which a bid amount and user information are registered from a plurality of bidders through a bidding terminal device; and a step (S130) in which a server communicates with the user terminal device and the bidding terminal device to determine a successful bidder based on the remaining time until the transaction time point, the bid amount, distance information from the transaction location, a user trust indicator, and past transaction history information, and performs meeting authentication and settlement between the successful bidder and the transaction registrant.

[0108] In addition, the control method of a goods exchange system for reasonable price calculation and safe transaction of goods including time according to one embodiment of the present invention can perform the data processing operation process of each of the user terminal device (110), bidding terminal device (130), and server (120) in the goods exchange system (100) for reasonable price calculation and safe transaction of goods including time described above in the same way.

[0109] FIG. 3 is a block diagram illustrating the specific configuration of the server shown in FIG. 1.

[0110] Referring to FIG. 3, the server (120) may include a communication unit (121), a processor (122), and a storage unit (123).

[0111] Specifically, the processor (122) can control the overall operation of the server (120).

[0112] Specifically, the processor (122) includes RAM (1221), ROM (1222), main CPU (1223), graphics processing unit (1224), first to n interfaces (1225-1 to 1225-n), and a bus (1226).

[0113] RAM (1221), ROM (1222), main CPU (1223), graphics processing unit (1224), first to n interfaces (1225-1 to 1225-n), etc. can be connected to each other via a bus (1226).

[0114] The first to n interfaces (1225-1 to 1225-n) are connected to the various components described above. One of the interfaces may be a network interface connected to an external device through a network.

[0115] The main CPU (1223) accesses the storage unit (123) and performs booting using the O / S stored in the storage unit (123). Then, it performs various operations using various programs, content, data, etc. stored in the storage unit (123).

[0116] In particular, the main CPU (1223) communicates with the user terminal device and the bidding terminal device to determine the winning bidder based on the remaining time until the transaction time, the bid amount, distance information from the transaction location, user trust indicators, and past transaction history information, and can perform meeting authentication and settlement between the winning bidder and the transaction registrant.

[0117] A set of instructions for booting the system is stored in the ROM (1222). When a turn-on command is input and power is supplied, the main CPU (1223) copies the O / S stored in the storage unit (123) to the RAM (1221) according to the instructions stored in the ROM (1222), and executes the O / S to boot the system. When booting is complete, the main CPU (1223) copies various application programs stored in the storage unit (123) to the RAM (1221), and executes the application programs copied to the RAM (1221) to perform various operations.

[0118] The graphics processing unit (1224) generates a screen containing various objects such as icons, images, and text using a calculation unit (not shown) and a rendering unit (not shown). The calculation unit (not shown) calculates attribute values ​​such as coordinate values, shape, size, and color for each object to be displayed according to the layout of the screen based on a received control command. The rendering unit (not shown) generates a screen of various layouts containing objects based on the attribute values ​​calculated by the calculation unit (not shown).

[0119] In particular, the graphics processing unit (1224) can implement objects generated by the main CPU (1223) into a GUI (Graphic User Interface), icon, user interface screen, etc.

[0120] Meanwhile, the operation of the above-described processor (122) can be performed by a program stored in the storage unit (123).

[0121] The storage unit (123) stores various data, such as an O / S (Operating System) software module for operating the server (120) and various multimedia content.

[0122] In particular, the storage unit (123) may include a software module for communicating with a user terminal device and a bidding terminal device to determine the winning bidder based on the remaining time until the transaction time, the bid amount, distance information from the transaction location, user trust indicators, and past transaction history information, and for performing meeting authentication and settlement between the winning bidder and the transaction registrant.

[0123] FIG. 4 is a drawing relating to a software module stored in a storage unit according to an embodiment of the present invention.

[0124] Referring to FIG. 4, the storage unit (123) may include a comprehensive score calculation module (1231), a meeting authentication execution module (1232), a settlement execution module (1233), and a comprehensive score correction module (1234).

[0125] Here, the comprehensive score calculation module (1231) calculates the remaining time until the time of the transaction, selects one of a set of different weight calculation functions according to the interval of the remaining time, and calculates a comprehensive score by assigning weights to multiple elements including the bid amount, distance information from the transaction location, user trust indicator, and past transaction history information according to the selected weight calculation function.

[0126] Additionally, the meeting authentication module (1232) generates a meeting authentication result by verifying whether a transaction has been executed through one-time authentication information generated in real time during an offline meeting, and can determine identity by comparing the one-time authentication information, which includes a face image captured in real time at the transaction site or voice information recorded in real time, with the biometric information of the winning bidder stored in advance.

[0127] Additionally, the settlement execution module (1233) receives the transaction amount from the successful bidder and deposits it into an escrow account, verifies whether the transaction has been executed through one-time authentication information generated in real-time during an offline meeting to generate a meeting authentication result, and can automatically settle the amount in the escrow account according to the meeting authentication result.

[0128] Additionally, the comprehensive score correction module (1234) can calculate a no-show risk score based on the number of times the user has a past non-fulfillment history, the transaction non-fulfillment rate, and the recent transaction success rate, and correct the calculated comprehensive score by reflecting the no-show risk score in the first to third weighting formulas.

[0129] Meanwhile, a non-transitory computer-readable medium storing a program that sequentially performs the control method according to the present invention may be provided.

[0130] A non-transient readable medium refers to a medium that stores data semi-permanently and can be read by a device, rather than a medium that stores data for a short period of time, such as a register, cache, or memory. Specifically, the various applications or programs described above may be stored and provided on non-transient readable media such as CDs, DVDs, hard disks, Blu-ray discs, USBs, memory cards, and ROMs.

[0131] Additionally, the system may further include processors such as a CPU or a microprocessor that communicate with user terminal devices and bidding terminal devices to determine the winning bidder based on the remaining time until the transaction time, the bid amount, distance information from the transaction location, user trust indicators, and past transaction history information, and to perform meeting authentication and settlement between the winning bidder and the transaction registrant.

[0132] Furthermore, although preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above. It is understood that various modifications can be made by those skilled in the art without departing from the essence of the invention as claimed in the claims, and such modifications should not be understood individually from the technical spirit or perspective of the present invention. Explanation of the symbols

[0133] 100: Goods exchange system for reasonable pricing of goods including time and secure transactions 110: User terminal device 120: Server 130: Bidding terminal device

Claims

Claim 1 A goods exchange system for reasonable price calculation and safe transaction of goods including time, comprising: a user terminal device in which a transaction registrant registers transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time point; a bidding terminal device for registering bid amounts and user information from multiple bidders; and a server that communicates with the user terminal device and the bidding terminal device to determine a successful bidder based on the remaining time until the transaction time point, the bid amount, distance information from the transaction location, a user trust indicator, and past transaction history information, and performs meeting authentication and settlement between the successful bidder and the transaction registrant. Claim 2 A goods exchange system for reasonable price calculation and safe transaction of goods including time, wherein, in claim 1, the server calculates the remaining time until the transaction time, selects one of a set of different weight calculation functions according to the interval of the remaining time, calculates a comprehensive score by assigning weights to a plurality of elements including the bid amount, distance information from the transaction location, the user trust indicator, and past transaction history information according to the selected weight calculation function, and determines the successful bidder. Claim 3 In paragraph 2, the server assigns an increased weight to the user trust indicator and the history of non-fulfillment among the past transaction history information as the transaction time approaches, a goods exchange system for reasonable price calculation of goods including time and safe transaction. Claim 4 A goods exchange system for reasonable price calculation and safe transaction of goods including time, wherein, in paragraph 3, the server applies a first weighting formula when the remaining time is greater than or equal to a first reference time, applies a second weighting formula when the remaining time is greater than or equal to a second reference time but less than the first reference time, applies a third weighting formula when the remaining time is less than the second reference time, and the third weighting formula is set such that the weight for non-fulfillment history among the user trust indicator and past transaction history information is increased compared to the first weighting formula. Claim 5 A goods exchange system for reasonable price calculation of goods including time and safe transaction, wherein, in paragraph 1, the server receives the transaction amount from the successful bidder and deposits it into an escrow account, verifies whether the transaction has been fulfilled through one-time authentication information generated in real-time at the time of the offline meeting to generate a meeting authentication result, and automatically settles the amount in the escrow account according to the meeting authentication result. Claim 6 A goods exchange system for reasonable price calculation and safe transaction of goods including time, wherein, in paragraph 5, the user terminal device transmits the one-time authentication information, which includes a face image captured in real time at the transaction site or voice information recorded in real time, to the server, and the server determines the identity by comparing the transmitted face image or voice information with the biometric information of the successful bidder stored in advance, and the captured face image or voice information recorded in real time is blocked from being stored in the user terminal device. Claim 7 A goods exchange system for reasonable price calculation and safe transaction of goods including time, wherein, in paragraph 4, the server calculates a no-show risk score based on the number of times a user has a past non-fulfillment history, a transaction non-fulfillment rate, and a recent transaction success rate, and corrects the calculated comprehensive score by reflecting the no-show risk score in the first to third weighting formulas. Claim 8 A goods exchange system for reasonable price calculation and safe transaction of goods including time, wherein, in the first paragraph, the server individually determines whether each user attends when the winning bidder is a group including multiple users, and partially settles only the payment corresponding to the user for whom the meeting authentication result was generated. Claim 9 A method for controlling a goods exchange system for reasonable price calculation and safe transaction of goods including time, comprising: a step of registering transaction information including at least one of a transaction target time, a transaction location, a minimum bid amount, and a transaction time point through a user terminal device; a step of registering bid amounts and user information from a plurality of bidders through a bidding terminal device; and a step of communicating with the user terminal device and the bidding terminal device by a server to determine a successful bidder based on the remaining time until the transaction time point, the bid amount, distance information from the transaction location, a user trust indicator, and past transaction history information, and performing meeting authentication and settlement between the successful bidder and the transaction registrant.

Images