Information sender verification method and device, equipment and medium

Abstract

The invention relates to the technical field of data security, can be applied to business scenes of financial science and technology, medical health and the like, and discloses an information sender verification method, device, equipment and medium, comprising: acquiring a verification request and extracting a to-be-verified number, querying first verification information in a cache verification database and judging whether the first verification information is within a preset validity period, and if yes, sending the first verification information to a server; if yes, taking the verification information as target verification information; if not, querying second verification information in the channel binding database and taking the second verification information as target verification information; and if the second verification information is unavailable, acquiring third verification information through the authorization data interface, writing the third verification information into the cache verification database, and generating a verification result based on the target verification information. Through a multistage verification mechanism, the complexity of querying the authenticity of the short message by a user is reduced, the query efficiency is improved, the reliability of verification information is ensured, and the authenticity of a short message sender is rapidly and accurately verified.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to an information sender verification method, device, equipment and storage medium. Background Art

[0002] In the fintech sector, SMS notifications have become a crucial means for banks, insurance companies, lending platforms, and other institutions to deliver information to users. This is particularly true for scenarios like loan collections, repayment reminders, and transaction confirmations, where SMS notifications can reach users quickly. However, due to the open nature of communication channels and the low barrier to entry, users often receive a large number of harassing text messages related to debt collection, lending, and other financial services, many of which are fraudulent messages impersonating legitimate financial institutions. After receiving such messages, users who wish to quickly verify the sender's identity typically visit the Ministry of Industry and Information Technology's website, the Telecom Network Number Resource Use and Adjustment Approval System, or the 12321 reporting platform to manually enter the number and verification code to verify the number's ownership. However, this verification method has the following drawbacks: First, users need to access multiple platforms, making the process cumbersome; second, query results are inconsistent across platforms, making it difficult for users to quickly determine the identity; and third, manually entering numbers and verification codes is prone to errors, resulting in a poor experience, especially for users unfamiliar with the process. Furthermore, some phishing messages may forge the names and formats of legitimate institutions, further complicating the identification of genuine and counterfeit messages.

[0003] In the healthcare sector, medical institutions, health management platforms, and insurance companies also commonly use SMS notifications to deliver health reminders, appointment confirmations, examination reports, and other information to users. However, similar to the financial sector, due to the open nature of SMS channels, users may also receive fraudulent text messages impersonating medical institutions, such as forged appointment confirmations, fake medical examination report links, or health consultation services through informal channels. After receiving such text messages, users who wish to verify the authenticity of the sender must also manually query the Ministry of Industry and Information Technology or the 12321 platform. This method is not only time-consuming and laborious, but users may also find it difficult to distinguish the medical terminology and professional terms used in the text messages, further increasing the risk of misjudgment. In addition, some users may mistake malicious links in phishing text messages for legitimate medical examination appointment links, resulting in privacy leaks or financial losses.

[0004] In existing technologies, due to the lack of an efficient and automated verification method, users must rely on multiple independent platforms to manually query number ownership information. This process is complex and produces inconsistent results, making it difficult to quickly determine the authenticity of text messages. This deficiency in existing technology often leaves users unable to distinguish text messages that may pose financial or health risks, and they may even mistakenly believe false information, resulting in financial losses or privacy leaks. Summary of the Invention

[0005] The main purpose of the present invention is to provide a method, device, equipment and storage medium for verifying the sender of an information message, aiming to solve the technical problem in the prior art that users need to manually access multiple independent platforms to query the attribution information of the text message sender, the operation is cumbersome and the results are inconsistent, making it difficult to verify the authenticity of the text message in a timely and accurate manner.

[0006] To achieve the above object, the present invention provides a method for verifying an information sender, comprising:

[0007] Obtaining a verification request and extracting a number to be verified from the verification request;

[0008] Based on the number to be verified, the cache verification database is searched to determine whether the first verification information of the number to be verified exists and whether the first verification information is within a preset validity period;

[0009] If there is first verification information of the number to be verified and the first verification information is within a preset validity period, the first verification information is used as the target verification information;

[0010] If the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, query the channel binding database based on the number to be verified, obtain the second verification information associated with the number to be verified, and use the second verification information as the target verification information;

[0011] If the second verification information is not obtained by querying the channel binding database, obtaining the third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database;

[0012] A verification result is generated according to the target verification information.

[0013] Furthermore, to achieve the above-mentioned purpose, the present invention provides an information sender verification device, comprising:

[0014] A request processing unit, configured to obtain a verification request and extract a number to be verified from the verification request;

[0015] A cache verification module is used to query a cache verification database based on the number to be verified, and determine whether there is first verification information of the number to be verified and whether the first verification information is within a preset validity period;

[0016] a verification information confirmation module, configured to use the first verification information as target verification information if the first verification information of the number to be verified exists and the first verification information is within a preset validity period;

[0017] a channel association query module, configured to query a channel binding database based on the number to be verified, obtain second verification information associated with the number to be verified, and use the second verification information as target verification information if the first verification information of the number to be verified does not exist or the first verification information is not within a preset validity period;

[0018] an authorization query module, configured to, if the second verification information is not obtained by querying the channel binding database, obtain third verification information associated with the number to be verified through the authorization data interface, use the third verification information as target verification information, and write the third verification information into the cache verification database;

[0019] The verification result generating module is used to generate a verification result according to the target verification information.

[0020] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and an information sender verification program stored in the memory and runnable on the processor, and when the information sender verification program is executed by the processor, the steps of the information sender verification method described above are implemented.

[0021] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which an information sender verification program is stored, and when the information sender verification program is executed by a processor, the steps of the information sender verification method described above are implemented.

[0022] Beneficial effects: The present invention relates to the field of data security technology and can be applied to business scenarios such as financial technology and medical health. A method, device, equipment and medium for verifying the sender of an information is disclosed, including: obtaining a verification request and extracting a number to be verified, querying a cache verification database based on the number to be verified, and judging whether there is first verification information and whether it is within a preset validity period; if the first verification information exists and is valid, using it as the target verification information; if the first verification information is invalid, querying a channel binding database based on the number to be verified, obtaining second verification information and using it as the target verification information; if the second verification information is unavailable, obtaining third verification information through an authorization data interface and using it as the target verification information, and writing it into the cache verification database; generating a verification result corresponding to the target verification information, and feeding it back to the user terminal. The present invention effectively reduces the complexity of users querying the authenticity of text messages through a multi-level verification mechanism, avoids the tedious operation of users manually accessing multiple independent platforms, improves query efficiency through a cache database, ensures the reliability of verification information through a channel binding database and an authorization data interface, can quickly and accurately verify the authenticity of the text message sender, and improves user information security. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0024] Figure 1 A schematic diagram of an application environment of a method for verifying an information sender according to an embodiment of the present invention;

[0025] Figure 2 A flow chart of an embodiment of a method for verifying a message sender according to the present invention;

[0026] Figure 3 Schematic diagram of the functional modules of a preferred embodiment of the information sender verification device of the present invention;

[0027] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0028] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0029] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0030] The information sender verification method provided by the embodiment of the present invention can be applied in the following situations: Figure 1 In an application environment, the user terminal communicates with the server terminal via a network. The server terminal can obtain a verification request from the user terminal and extract the number to be verified. Based on the number to be verified, the server terminal queries the cached verification database to determine whether the first verification information exists and whether it is within a preset validity period. If the first verification information exists and is valid, it is used as the target verification information. If the first verification information is invalid, the server terminal queries the channel binding database based on the number to be verified, obtains the second verification information and uses it as the target verification information. If the second verification information is unavailable, the server terminal obtains the third verification information through the authorization data interface and uses it as the target verification information, and writes it into the cached verification database. The server terminal generates a verification result corresponding to the target verification information and feeds it back to the user terminal. The present invention effectively reduces the complexity of users querying the authenticity of SMS messages through a multi-level verification mechanism, avoids the tedious operation of users manually accessing multiple independent platforms, improves query efficiency through a cached database, ensures the reliability of verification information through a channel binding database and an authorization data interface, and can quickly and accurately verify the authenticity of the SMS sender, thereby improving user information security. The user terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablet computers, and portable wearable devices. The server terminal can be implemented using an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0031] See also Figure 2 , Figure 2This is a flow chart of an embodiment of the information sender verification method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0032] like Figure 2 As shown, the information sender verification method proposed by the present invention includes the following steps:

[0033] S10, obtaining a verification request and extracting a number to be verified from the verification request;

[0034] In this embodiment, the system automatically receives verification requests sent by users during operation. The request is usually in the form of a user reply text message, an in-app request, or other communication methods. The verification request can be a query behavior triggered by the user to confirm whether a specific number belongs to a legitimate sender. In actual implementation, the verification request can be received in a variety of ways, such as the SMS receiving module monitoring user reply information, the application program interface (API) listening for in-app requests, and third-party platform push. Regardless of the source of the verification request, the system parses it into a standardized data structure to ensure compatibility and scalability.

[0035] The system first receives the user's verification request and parses the content of the request. In SMS mode, the verification request usually contains a preset command trigger identifier (such as "check for counterfeit" or "verify") and the number to be verified. The command trigger identifier is a predefined keyword or symbol that the user needs to enter in a fixed format when sending a request, such as "check for counterfeit + target number" or "verify + target number". The command trigger identifier is automatically identified from the request text through regular expressions or string matching algorithms to ensure that it can be parsed normally regardless of whether the user enters uppercase, lowercase, or distorted formats (such as spaces, symbols).

[0036] Once the instruction trigger identifier is identified, the system immediately extracts the number to be verified from the verification request. The number to be verified is the number that the user wants to verify, usually a mobile phone number or a landline number. In the specific implementation, the number to be verified can be a pure numeric string (such as "13812345678"), a format with an area code (such as "+8613812345678"), or it can contain spaces or separators (such as "138-1234-5678"). The system uses regular expressions to remove spaces, symbols or invalid characters, and standardizes the number to a pure numeric format for subsequent queries.

[0037] After extracting the number to be verified, the system converts it into a unified encoding format (such as UTF-8 or ASCII) and generates standardized verification request data. This data structure typically includes the following fields:

[0038] Request timestamp: records the time when the user initiates the request to ensure that the timeliness of the request can be traced.

[0039] User communication identifier: such as a mobile phone number or in-app user ID, used to identify the source of the request.

[0040] Instruction trigger flag: such as "check for authenticity" or "verify", to ensure that the system can correctly identify user intent.

[0041] Number to be verified: A standardized string of pure numeric numbers used for subsequent multi-level queries.

[0042] The standardized verification request data is automatically saved to the system's request processing queue to ensure sequential processing of requests in high-concurrency situations. Furthermore, the system associates the verification request with the user's communication identifier, facilitating the subsequent feedback of the results to the user's terminal.

[0043] In the fintech business field, when a user receives a suspected fraudulent text message (such as a loan promotion or account change notification), the user can directly reply via text message with "check for fraud + target number" to initiate a verification request. The system automatically receives the text message reply from the user, identifies the "check for fraud" instruction, and extracts the target number. If the user's reply contains extra characters (such as "check for fraud 13812345678" or "check for fraud: 138-1234-5678"), the system automatically cleans up the format through regular expressions and standardizes the target number to "13812345678". The system stores the verification request data in a structured manner, including the request timestamp, user's mobile phone number, instruction identifier, and standardized target number.

[0044] In the healthcare sector, users may receive health reminders, appointment notifications, or service promotions from unidentified sources. Users use the in-app "fake verification" feature to enter the target number they received. The system receives the verification request and extracts the target number. Regardless of the format of the number entered by the user (such as "+8613812345678" or "13812345678"), the system automatically standardizes it to a pure numeric format and stores the request data in a structured manner.

[0045] This embodiment automatically receives and parses user verification requests and accurately extracts the number to be verified, achieving flexible compatibility with user input formats. Using regular expressions and string processing techniques, the system automatically standardizes the user-entered number to a pure numeric format, regardless of whether it contains area codes, separators, spaces, or other formats. This standardization ensures a consistent verification request data structure throughout subsequent multi-level queries, reducing manual steps for users and improving verification efficiency and accuracy.

[0046] S20, querying a cache verification database based on the number to be verified, determining whether there is first verification information for the number to be verified and whether the first verification information is within a preset validity period;

[0047] In this embodiment, when querying the cache verification database based on the number to be verified, it is first necessary to ensure that the cache verification database has been pre-configured and remains effectively connected. The cache verification database is an efficient key-value storage system, typically using a memory-based NoSQL database (such as Redis or Memcached) or a relational database with high concurrency support (such as MySQL's InnoDB engine). The advantage of this cache structure is its fast query speed, making it suitable for frequently accessed data.

[0048] After receiving the number to be verified, the system generates a unique query index key based on the number. This query index key typically uses a standardized string format to ensure that the number is uniquely identified within the database. During the index key generation process, the number to be verified is first normalized to remove any formatting artifacts (such as spaces, area codes, and separators). This normalized number is then input into the database query module as a primary key or hash key.

[0049] When performing a query in the cached verification database, the system performs an exact match of the index key to ensure that the query result exactly corresponds to the number being verified. If a match is successful, the database returns the primary verification information associated with the number and its storage timestamp. This primary verification information typically includes the target organization name, number usage, verification status, and the last updated timestamp.

[0050] After obtaining the first verification information, the system immediately enters the validity determination logic. First, the system obtains the current server time and calculates the time difference between the current time and the timestamp stored in the first verification information. This time difference is calculated with high precision in milliseconds, ensuring time comparison at the millisecond level. Next, the system compares this time difference with the preset validity period. The preset validity period can be a dynamically configured time threshold, such as 72 hours or another custom time range.

[0051] If the time difference is less than or equal to the preset validity period, the system determines that the first verification information is still valid and uses it as the target verification information. At this point, there is no need to continue with the subsequent query steps. If the time difference is greater than the preset validity period or the first verification information does not exist in the database, the system will consider the first verification information invalid and trigger a subsequent channel binding database or authorization data interface query.

[0052] This method of calculating the validity period using timestamps ensures the dynamic timeliness of the first verification information, preventing invalid data from persisting in the cache database and impacting query efficiency. The specific value of the preset validity period can be dynamically adjusted based on actual business needs. For example, in high-frequency query scenarios, the validity period can be shortened to increase data update frequency; in low-frequency query scenarios, the validity period can be extended to reduce the pressure of frequent queries.

[0053] In one embodiment, the cache verification database uses a Redis-based key-value storage structure, with the query key for each number to be verified using a standardized string as the primary key. After receiving the user-entered number, it is first processed using a regular expression to remove non-numeric characters and converted to a standardized format (e.g., the internationalized number format: +8613812345678). This standardized number is then used as the query key.

[0054] In the Redis database, execute a GET command to query the first verification information for the number. If the GET command returns a non-empty result, it indicates that the first verification information exists. The returned data includes the last updated timestamp, expressed in UNIX time format. The system obtains the current server timestamp and calculates the difference between the two. The preset validity period is configured as 72 hours (259200000 milliseconds). When the difference is less than or equal to the validity period, the first verification information is determined to be valid.

[0055] In another embodiment, the cache verification database uses the MySQL InnoDB engine, and the numbers to be verified are stored in a dedicated cache table. The table structure includes a number field, a verification information field, and a last updated timestamp field. When querying, the system generates an SQL statement based on the number to be verified:

[0056] SELECT verification information, last update time FROM cache table WHERE number = 'standardized number'

[0057] After returning the result, the system calculates the time difference between the current time and the last updated timestamp through a programming language (such as Java, Python), and makes a judgment based on the preset validity period.

[0058] In another implementation, the preset validity period can be dynamically adjusted based on business scenarios. For example, it can be set to 24 hours during peak periods and 168 hours during off-peak periods. This dynamic adjustment is achieved through the configuration management module, allowing administrators to modify the validity period parameters directly in the backend interface without redeploying the system.

[0059] This embodiment verifies the validity of the first verification information by querying the cached verification database based on the number to be verified and dynamically comparing the stored timestamp with the preset validity period. Precise index key matching avoids full table scans, improving query speed; timestamp calculation ensures data validity and prevents invalid data from continuously occupying cache resources.

[0060] S30, if there is first verification information of the number to be verified and the first verification information is within a preset validity period, use the first verification information as target verification information;

[0061] In this embodiment, when the system finds the first verification information of the number to be verified in the cached verification database, and the validity of the first verification information has been confirmed (i.e., within the preset validity period), the system directly designates the first verification information as the target verification information. The core of this step is to make a quick decision, eliminating the need for subsequent channel binding database or authorization data interface queries, thereby improving system efficiency.

[0062] The first verification information is a verification record related to the number to be verified stored in the cache verification database. It usually contains the following key information: the name of the target organization, a description of the number's purpose (such as notification, marketing, service), the verification status (valid or invalid), the data generation timestamp, and possible other additional information (such as a service description). This information can be text, numeric, Boolean, or structured data (such as JSON format). After the system obtains the first verification information from the cache verification database, it first checks its validity, usually by comparing the timestamp with the current time. When the validity is confirmed, the system immediately designates the first verification information as the target verification information.

[0063] Using the first verification information as the target verification information means that it is confirmed as the final reference data for the current query, eliminating the need to query other data sources. This process simplifies the data flow path and reduces the burden on system calculations and external interface calls. Technically, the system assigns the first verification information to the target verification information variable through a simple assignment operation. This processing logic not only reduces computing resource consumption but also avoids unnecessary data transmission.

[0064] To ensure the efficiency and reliability of this operation, the system adopts the following measures:

[0065] Data security: The first verification information is only valid within the validity period. The first verification information that exceeds the validity period will be deemed invalid to prevent users from obtaining expired or incorrect information.

[0066] Data integrity: The data structure of the first verification information is standardized in the cache verification database, ensuring that there are no missing fields or format errors when it is extracted and used.

[0067] Efficiency: The fast query feature of the cache verification database (such as Redis and Memcached) ensures the reading speed of the first verification information.

[0068] Under this structure, the decision-making efficiency of the system is improved: once the first verification information is confirmed to be valid, the subsequent steps will be automatically skipped, and the system does not need to consume resources to query the channel binding database or call the authorization data interface.

[0069] In one embodiment, the cache verification database uses a key-value pair storage structure based on Redis. The number to be verified entered by the user is returned after querying the first verification information, and the system processes it through the following logic:

[0070] Get the first verification information of the number to be verified from Redis through the GET command. The data format is a JSON object, including the organization name, purpose description, status, and last update time.

[0071] Check the "Last Update Time" field in the first verification information and compare it with the current server time.

[0072] If the time difference is less than or equal to a preset validity period (eg, 72 hours), the first verification information is assigned to the target verification information variable.

[0073] If the time difference is greater than the preset validity period, the first verification information is deemed invalid and is not used as the target verification information.

[0074] In another embodiment, the cache verification database uses the MySQL InnoDB engine, and the first verification information is stored in a table with the following structure:

[0075] Number: VARCHAR(20), indicating the number to be verified.

[0076] Organization name: VARCHAR(100), indicating the organization to which the number belongs.

[0077] Verification status: VARCHAR(10), indicating the verification result (such as "valid" or "invalid").

[0078] Last updated: DATETIME, indicating the date when the verification information was last updated.

[0079] Usage description: VARCHAR(50), indicating the purpose of the number.

[0080] This embodiment achieves a rapid response to verification requests by querying the first verification information in the cached verification database and, once it is confirmed to be valid, directly designating it as the target verification information. This cache-first strategy avoids frequent calls to the subsequent channel binding database and authorization data interface, reducing system computation and bandwidth consumption. First verification information within its validity period is directly adopted, ensuring that users can quickly obtain accurate verification results, improving user experience and system efficiency.

[0081] S40, if the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, querying the channel binding database based on the number to be verified, obtaining the second verification information associated with the number to be verified, and using the second verification information as the target verification information;

[0082] In this embodiment, if the system fails to find the first verification information for the number to be verified in the cached verification database, or if the first verification information has expired, the system switches to the channel binding database and attempts to obtain the second verification information associated with the number to be verified, designating it as the target verification information. The core of this process is to provide a redundant verification path, ensuring that users can still obtain accurate verification results even if the cached data becomes invalid.

[0083] The channel binding database is a structured data store dedicated to storing the association between numbers and communication channels. It contains the following key fields:

[0084] Number: Indicates the number to be verified, which is the verification object entered by the user.

[0085] Channel identifier: indicates the communication channel bound to the number (such as SMS sending channel ID, operator channel code).

[0086] Binding time: Indicates the binding time between the number and the channel, used for validity verification.

[0087] Channel Status: Indicates the current availability status of the channel (such as "Active", "Paused", or "Disabled").

[0088] Channel Owner: Indicates the name of the company or service provider to which the channel belongs.

[0089] The system first generates a channel-binding query key based on the number to be verified. This query key is a standardized string of numbers used to ensure query accuracy. For example, the number to be verified may contain spaces or other non-numeric characters. The system automatically removes these interfering characters and generates a standardized string (e.g., "+8613812345678" is converted to "13812345678"). An exact match query is performed against this standardized string in the channel-binding database.

[0090] The query results are divided into the following situations:

[0091] Match successful: The database returns the associated channel identifier, binding time, and channel status.

[0092] Matching failed: The database does not find the corresponding record. The system will continue with the subsequent steps and try to obtain the third verification information through the authorization data interface.

[0093] If the second verification information is found, the system first verifies the validity of the channel. Validity verification is usually based on the following conditions:

[0094] The binding time has not expired: the difference between the binding time and the current time is within the preset validity period (such as 180 days);

[0095] The channel status is "Active" or "Normal": it means that the channel is still in use and has not been disabled;

[0096] The organization to which the channel belongs is on the pre-stored whitelist of compliant service providers: This prevents users from receiving text messages sent by unauthorized organizations.

[0097] Once the verification is successful, the system designates the second verification information as the target verification information. This mechanism ensures that even if the cached data is invalid, the system can still provide reliable verification results through the channel binding database.

[0098] Example: In the healthcare sector, a user receives a health service reminder SMS message. The system cannot find valid primary verification information in the cached verification database. The system automatically switches to the channel binding database and finds that the number was sent via channel CH-1001, assigned by XX Telecom, with a binding date of 2023-10-01 and an "Active" status. The system then returns "XX Telecom" as the target verification information to the user, ensuring they can verify the authenticity of the SMS message.

[0099] In the FinTech business, a user received a repayment reminder text message. The system could not find valid first verification information in the cached verification database. The system switched to the channel binding database and found that the number was sent through the "XX Financial Services Channel," with a binding date of 2023-09-15 and an "Active" status. The system confirmed that the channel belonged to XX Financial Company and fed the user the company name and channel identifier as target verification information, allowing the user to quickly confirm the authenticity of the text message source.

[0100] This embodiment automatically switches to the channel binding database and verifies the channel's validity when data in the cached verification database is invalid or missing, ensuring that users continue to receive accurate verification results. Using the channel identifier and the organization to which the channel belongs, users can quickly confirm the authenticity of the SMS source. This mechanism improves system robustness and reliability without increasing user operation complexity, ensuring the accuracy of verification results.

[0101] S50, if the second verification information is not obtained by querying the channel binding database, obtaining third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database;

[0102] In this embodiment, if the system fails to retrieve the second verification information associated with the number to be verified from the channel binding database, or if the second verification information is invalid, the system automatically switches to the authorized data interface, calls the external authorized data source to obtain the third verification information associated with the number to be verified, designates the third verification information as the target verification information, and writes it to the cached verification database. This mechanism is designed to ensure that users always receive accurate verification results regardless of the validity of the cached and local channel information.

[0103] The authorized data interface is a secure and compliant external data source, typically provided by national or industry regulatory agencies (such as the Ministry of Industry and Information Technology, telecom operators) or third-party authorized service providers. The authorized data interface includes the following key features:

[0104] Data security: All requests and responses are transmitted using encryption (such as HTTPS and TLS) to ensure that data is not tampered with during transmission.

[0105] Data legitimacy: The data source is officially authorized to avoid fake information sources.

[0106] Data real-time: The verification information returned by the interface is real-time data to ensure the accuracy of the results.

[0107] Before calling the authorization data interface, the system first generates interface request parameters based on the number to be verified. The request parameters include the following core fields:

[0108] Request Type: Indicates the query type of the current request (such as number location query, number verification query).

[0109] Number to be verified: standardized number string (such as "13812345678").

[0110] Security Credentials: Cryptographic tokens used for authentication (e.g., API keys, digital certificates).

[0111] To ensure the security of data transmission, the system encrypts the request parameters and generates a secure request message. Common encryption methods include:

[0112] HTTPS encryption: Full-link encryption of data transmission based on the SSL / TLS protocol.

[0113] AES symmetric encryption: Request parameters are encrypted using a symmetric key, which is distributed through a secure channel.

[0114] RSA asymmetric encryption: Use the public key to encrypt the request data, and the server uses the private key to decrypt it.

[0115] The system sends a security request message to the target server of the authorized data interface via a secure communication protocol (such as HTTPS). Upon receiving the request, the target server parses and verifies the security credentials in the request parameters to confirm the legitimacy of the request. The target server then performs a data query based on the request type and the number to be verified, generates a response message, and returns it in an encrypted form.

[0116] After receiving the encrypted response data, the system first decrypts the data and restores it to plaintext format. After decryption, the system parses the following core fields in the response data:

[0117] Organization identification code: indicates the organization or company to which the number belongs (such as "XX Company").

[0118] Data validity period: indicates the validity period of the data (such as "valid within 72 hours").

[0119] The system verifies whether the institution's identification code exists on a pre-stored whitelist of compliant service providers to ensure the data is sourced legally. The whitelist is a pre-configured set of legal service provider identifiers (such as "XX Telecom" or "YY Bank"). Institutional identifiers that are not whitelisted will be rejected.

[0120] When the verification is successful, the system specifies the organization identification code as the third verification information, associates the third verification information with the data validity period field, and generates a cached data record. The cached data record contains the following fields:

[0121] Number: The number to be verified.

[0122] Institution identification code: The legal institution identification obtained through the authorization interface.

[0123] Data validity period: indicates the time range in which the data is available.

[0124] The system writes the cache data record into the cache verification database to ensure that when subsequent users query the same number, the third verification information can be directly obtained from the cache, reducing the number of interface calls.

[0125] This embodiment automatically switches to the authorized data interface if the channel binding database is invalid or missing data, and obtains real-time third-party verification information through secure encrypted communication, ensuring that users always receive accurate and legitimate verification results. By writing this third-party verification information into the cached verification database, the system eliminates the need to repeatedly call the interface when subsequent users query the same number, significantly improving response speed and reducing interface call costs. The system also uses a whitelist mechanism to ensure that the source of this third-party verification information is legitimate, avoiding security risks caused by counterfeit data sources.

[0126] S60: Generate a verification result according to the target verification information.

[0127] In this embodiment, after obtaining the target verification information, the system enters the verification result generation process. The target verification information can come from the first verification information in the cache verification database, the second verification information in the channel binding database, or the third verification information obtained through the authorization data interface. Regardless of the source of the target verification information, the system converts it into user-readable verification result text using a standardized template.

[0128] First, the system analyzes the source type of the target verification information. The source type is the source identifier of the verification information and can include the following three types:

[0129] First verification information: comes from the cache verification database, usually a short-term valid historical verification record.

[0130] Second verification information: comes from the channel binding database, indicating the binding relationship between the number and the sending channel.

[0131] Third verification information: real-time verification data obtained through the authorized data interface, usually provided by the Ministry of Industry and Information Technology or a third-party authorized service provider.

[0132] Based on the source type of the target verification information, the system selects the corresponding standardized response template. The response template is a predefined text format that contains dynamic placeholders to fill in key fields in the target verification information. Common template examples include:

[0133] First verification message template: "Number ${number} is ${organization name} and is valid until ${validity date}."

[0134] Second verification message template: "Number ${number} was sent via ${channel name}, and the sending organization is ${organization name}."

[0135] Third verification message template: "Number ${number} is authorized to send by ${organization name}, and the data source is legal."

[0136] The system extracts key fields from the target verification information and populates these fields into the standardized response template. Key fields typically include the following:

[0137] Number: The number to be verified, usually a standardized mobile phone number or a virtual number.

[0138] Organization name: Indicates the organization to which the number belongs or to which the number is authorized to be sent (such as "XX Bank" or "YY Health Commission").

[0139] Validity period: Indicates the validity period of the verification information (such as "2023-12-31").

[0140] Channel Name: indicates the name or type of the sending channel (such as "Marketing SMS Channel").

[0141] The verification result after filling the template is in user-readable text format, for example:

[0142] Cached data (first verification information): "Number 13812345678 is XX Company. The verification record is valid until 2023-12-31."

[0143] Channel binding data (second verification information): "Number 13812345678 was sent via the marketing SMS channel, and the sending organization is XX Advertising Company."

[0144] Authorization interface data (third verification information): "Number 13812345678 is authorized by XX Bank to send the data. The data source is legal."

[0145] After generating the initial verification result text, the system performs a grammatical compliance check on the text. The purpose of grammatical compliance checking is to ensure that the text format complies with communication standards and to avoid erroneous or non-standard text that may cause user misunderstandings. Common verification rules include:

[0146] Character length limit: The SMS verification result should not exceed 70 characters (single SMS).

[0147] Special character filtering: Avoid using characters that cannot be displayed (such as line breaks and emojis).

[0148] Data integrity check: Make sure all placeholders are filled correctly (e.g. "${number}" cannot be empty).

[0149] When the syntax compliance check passes, the system marks the text as the final verification result. This result can be stored in the system log in text format or directly used as feedback to the user.

[0150] This embodiment automatically selects a standardized response template based on the source type of the target verification information, and generates grammatically compliant verification result text based on the template, ensuring that the verification results are highly readable and accurate. The system achieves rapid generation of verification results through standardized templates and dynamic field filling, reducing the workload of manual editing. The templated generation mechanism ensures the uniform format and accurate content of the verification results, effectively avoiding text errors caused by manual operations. Through grammatical compliance verification, the system further ensures the text quality of the verification results and avoids user misunderstandings due to format errors or semantic ambiguity.

[0151] The present invention relates to the field of data security technology and can be applied to business scenarios such as financial technology and medical health. A method, device, equipment and medium for verifying the sender of an information is disclosed, comprising: obtaining a verification request and extracting a number to be verified, querying a cache verification database based on the number to be verified, and determining whether first verification information exists and whether it is within a preset validity period; if the first verification information exists and is valid, using it as target verification information; if the first verification information is invalid, querying a channel binding database based on the number to be verified, obtaining second verification information and using it as target verification information; if the second verification information is unavailable, obtaining third verification information through an authorization data interface and using it as target verification information, and writing it into the cache verification database; generating a verification result corresponding to the target verification information and feeding it back to a user terminal. The present invention effectively reduces the complexity of users querying the authenticity of text messages through a multi-level verification mechanism, avoids the tedious operation of users manually accessing multiple independent platforms, improves query efficiency through a cache database, ensures the reliability of verification information through a channel binding database and an authorization data interface, can quickly and accurately verify the authenticity of the text message sender, and improves user information security.

[0152] In one embodiment, the above step S10 includes:

[0153] S101, receiving a reply message to an original message in a user communication account;

[0154] S102, identifying whether the reply information contains a preset instruction trigger identifier;

[0155] S103, if the reply message contains the instruction trigger identifier, extracting the to-be-verified number field in the reply message;

[0156] S104: Associating the instruction trigger identifier with the number to be verified field to generate standardized verification request data.

[0157] In this embodiment, the system receives the reply information to the original information in the user's communication account. This reply information is usually actively sent by the user and may be submitted through various communication methods such as text messages, IM applications, and emails. The original information can be marketing text messages, payment reminders, reminder messages, or other actively sent information received by the user. The user usually enters specific instructions and the number to be verified in the reply information, such as "Verify 13812345678". The system automatically captures and obtains these verification requests actively sent by the user by listening to and parsing the reply information in the user's communication account.

[0158] After receiving the user's reply information, the system uses text parsing and pattern matching technologies to identify whether the reply information contains a preset instruction trigger identifier. The instruction trigger identifier is a keyword or phrase pre-configured by the system and can be any text such as "Verify", "Query", "Verify Number", etc. The system quickly locates the position of the instruction trigger identifier through regular expressions or keyword matching technologies to avoid parsing failures caused by inconsistent user input formats (such as spaces or symbols before and after the instruction). This instruction trigger identifier is used to determine the nature of the user's request, such as verifying whether a number is legal.

[0159] Once the instruction trigger identifier is identified, the system further analyzes the content in the reply information to extract the field of the number to be verified. The field of the number to be verified is the number clearly specified by the user in the reply information, usually a mobile phone number or other communication numbers. The system accurately extracts the number field through regular expressions, string splitting, or keyword-based text capture technologies. To ensure that the extracted number field meets the format requirements, the system also performs data preprocessing, including:

[0160] Removing spaces, hyphens, or other non-numeric characters in the number.

[0161] Ensuring that the length of the number meets the expectation (e.g., 11 digits for domestic numbers, and international numbers include the country code).

[0162] For international numbers, standardizing them to a unified format (such as +8613812345678).

[0163] After completing the number extraction, the system associates the extracted instruction trigger identifier and the field of the number to be verified together to generate standardized verification request data. The standardized verification request data is structured and usually uses key-value pairs or JSON format, for example:

[0164] {"Instruction": "Verify", "Number": "13812345678"}

[0165] XML format can also be used to ensure efficient data transmission and parsing within the system. Through standardization, the system ensures that verification request data is uniform in format and that field meanings are clear, avoiding parsing errors caused by format differences. Standardized verification request data is immediately stored in a cache queue or directly passed to subsequent verification processes, ensuring that user requests can be processed quickly.

[0166] This embodiment automatically receives and parses replies to original messages in the user's communication account, accurately identifying the command trigger identifier and the number field to be verified, thereby automating and standardizing the processing of user verification requests. By associating the command trigger identifier with the number field to be verified and generating standardized verification request data, the system ensures a unified data format and clear field meanings, improving both the system's parsing efficiency and accuracy.

[0167] In one embodiment, the above step S20 includes:

[0168] S201, connecting to a pre-configured cache verification database;

[0169] S202, generating a database query index key according to the number to be verified;

[0170] S203, performing an index key matching operation in the cache verification database;

[0171] S204, if the match is successful, extracting the first verification information and storage timestamp associated with the index key from the cache verification database;

[0172] S205, determining the time difference between the current time and the stored timestamp;

[0173] S206, comparing the time difference with a preset validity period;

[0174] S207: When the time difference is less than or equal to the preset validity period, determine that the first verification information is valid.

[0175] In this embodiment, the system queries the cache verification database based on the number to be verified, and first establishes a connection with the cache verification database. The cache verification database is an efficient temporary data storage structure, usually based on an in-memory database (such as Redis, Memcached) or a local file-type database (such as SQLite). Its core function is to store short-term, high-frequency access data. Through pre-configured database connection parameters (such as IP address, port number, and identity authentication information), the system quickly establishes a connection with the cache verification database. This connection can be a persistent connection (long connection) or a short connection established on demand (closed immediately after connection), which can be flexibly adjusted according to system load and performance requirements.

[0176] After connecting to the cache verification database, the system generates a database query index key based on the number to be verified. An index key is a unique identifier used to quickly locate data records. There are various ways to generate an index key, for example:

[0177] Directly use the number to be verified as the index key, which is suitable for scenarios where the cache database is a key-value pair structure;

[0178] Perform a hash operation (such as SHA-256 or MD5) on the number to be verified to generate a fixed-length hash index key, which is suitable for high-concurrency environments to avoid index conflicts.

[0179] In a multi-node cache cluster environment, the number prefix and hash algorithm are combined to generate distributed index keys to ensure data load balancing.

[0180] Once the index key is generated, the system performs an index key matching operation in the cache validation database. The matching operation is usually a fast query operation of the key-value pair, such as a GET command (Redis) or a SELECT statement (SQLite). The cache validation database can complete the query in milliseconds due to its efficient indexing mechanism (such as skip list, hash table or B-tree). The matching operation here can be:

[0181] Exact match: A match is found when the index keys are exactly the same;

[0182] Fuzzy matching: allows prefix or suffix fuzzy search, suitable for scenarios where partial number matching is required.

[0183] If the index key matches successfully, the system extracts the first verification information associated with the index key from the cached verification database, along with its storage timestamp. The first verification information is typically a structured data record containing key information such as the verification result, data source (e.g., company name), and verification status (valid or invalid). The storage timestamp indicates the time the data record was written or last updated, typically in UNIX timestamp format (e.g., with second or millisecond precision).

[0184] The system reads the current time (usually in UTC) and calculates the time difference between it and the stored timestamp of the first verification information. The time difference calculation can be done in the following ways:

[0185] Direct subtraction operation: current time minus stored timestamp;

[0186] Consider time zone conversion: When the cache database and the system are in different time zones, time zone conversion is required.

[0187] Compare the calculated time difference with the preset validity period. The preset validity period is usually in seconds, minutes or hours, for example, "72 hours". The comparison logic is:

[0188] If the time difference is less than or equal to the preset validity period, it means that the first verification information is still within the validity period;

[0189] If the time difference is greater than the preset validity period, it means that the first verification information has expired.

[0190] If the time difference is less than or equal to the preset validity period, the system determines that the first verification information is valid and uses it as the target verification information. This validity determination ensures the real-time and accuracy of the data in the cached verification database, preventing the use of expired data to mislead users. The target verification information is immediately retained for subsequent verification result generation steps.

[0191] This embodiment ensures the real-time and accuracy of query results by quickly querying the first verification information of the number to be verified in a cached verification database and verifying data validity based on a stored timestamp and a preset expiration date. Through index key matching and time difference calculation mechanisms, the processing speed of verification requests is significantly improved, repeated calls to external interfaces are avoided, and system resource consumption and network latency are reduced. Cached data is directly returned if the data is still valid, achieving low-latency and high-concurrency verification response performance.

[0192] In one embodiment, the above step S40 includes:

[0193] S401, if the first verification information of the number to be verified does not exist in the cache verification database or the first verification information is not within a preset validity period, generating a channel binding query key according to the number to be verified;

[0194] S402, performing a matching operation of the channel binding query key in a channel binding database;

[0195] S403, if the match is successful, extracting the channel identifier and binding time information associated with the channel binding query key from the channel binding database;

[0196] S404, verifying whether the binding time information meets the channel validity condition;

[0197] S405: When the binding time information satisfies a channel validity condition, the channel identifier is used as second verification information.

[0198] In this embodiment, when the first verification information does not exist in the cache verification database, or the first verification information is not within the preset validity period, the system automatically switches to querying the channel binding database based on the number to be verified, in order to determine whether the number is bound to a specific sending channel and to ensure that the channel is legal and valid. First, the system generates a channel binding query key based on the number to be verified. The channel binding query key is an index key used to quickly locate the channel information associated with the number to be verified in the channel binding database. The generation method of the channel binding query key can be flexibly adjusted according to system requirements. For example: directly using the number to be verified as the query key is suitable for the case where the number is used as the primary key in the channel binding database; performing hash processing (such as SHA-256 or MD5) on the number to be verified to generate a fixed-length encrypted index key, which is suitable for data security and privacy protection in a high-concurrency environment; using an international number format (such as the E.164 standard) to standardize the number as a query key to ensure cross-regional and cross-operator compatibility.

[0199] After the channel binding query key is generated, the system performs a matching operation on the query key in the channel binding database. The channel binding database is a database that specifically stores the association between phone numbers and sending channels. It is usually an efficient key-value storage structure (such as a NoSQL database) or a relational database (such as MySQL or PostgreSQL). The matching operation can be:

[0200] Exact match: Returns a result only when the number to be verified exactly matches the database record.

[0201] Prefix or suffix matching: allows matching of partial numbers, used to adapt to special channel rules.

[0202] Fuzzy matching: Implement complex query patterns based on regular expressions or wildcards.

[0203] If the match operation is successful, the system extracts the channel identifier and binding time information associated with the channel binding query key from the channel binding database. The channel identifier is typically a unique identifier (such as a channel ID, channel name, or service provider code) that uniquely identifies the sending channel to which the number is bound. The binding time information indicates the time when the association between the number and the channel was established, typically expressed as a UNIX timestamp or standard date and time format (such as "2023-09-15 12:00:00").

[0204] Next, the system verifies the validity of the extracted binding time information to ensure that the channel is still valid at the current time. The channel validity conditions can be flexibly set based on a variety of criteria, including but not limited to:

[0205] Time-based: The channel binding time does not exceed the preset validity period (for example, the binding is valid within 72 hours).

[0206] Status-based: The channel status field displays "Active" or "Normal" instead of "Pause" or "Deactivated".

[0207] Based on traffic limit: The channel sending frequency does not exceed the preset daily or hourly sending limit.

[0208] Validity verification can be implemented by calculating the time difference (current time minus binding time) and comparing the calculated result with the preset validity period, or querying the channel metadata table to check the channel status and traffic limit. When the binding time information meets the validity conditions, the system determines the channel identifier as the second verification information. At this time, the system marks the second verification information as the target verification information and retains this information for subsequent verification result generation.

[0209] During this process, if the match fails or the binding time information does not meet the validity conditions, the system will continue to try to obtain the third verification information through the authorization data interface to ensure that the user's verification request can be processed smoothly.

[0210] This embodiment provides a reliable backup verification mechanism when the primary verification information is invalid by querying and verifying the channel-associated information of the number to be verified in the channel binding database. The channel binding query key ensures query efficiency, and combined with channel validity conditions (such as binding time and status) enables dynamic verification of channel data, preventing invalid or expired channel data from misleading users. This mechanism effectively ensures that users can quickly obtain accurate channel verification information, reduces the frequency of system calls to external interfaces, and improves overall verification efficiency.

[0211] In one embodiment, the above step S50 includes:

[0212] S501, if the second verification information is not obtained by querying the channel binding database, generating an interface request parameter according to the number to be verified;

[0213] S502, encrypting the interface request parameters to generate a security request message;

[0214] S503, sending the security request message to the target server of the authorization data interface;

[0215] S504, receiving the encrypted response data returned by the target server;

[0216] S505, parsing the organization identification code and data validity period fields in the encrypted response data;

[0217] S506, verifying whether the organization identification code exists in the pre-stored whitelist of compliant service providers;

[0218] S507, when the verification is successful, using the organization identification code as the third verification information;

[0219] S508, associating the third verification information with the data validity period field to generate a cache data record;

[0220] S509: Write the cache data record into a cache verification database.

[0221] In this embodiment, if the channel binding database fails to retrieve valid second verification information, the system will attempt to obtain third verification information associated with the number to be verified through the authorized data interface. This authorized data interface is typically a legitimate and trustworthy third-party data source, such as a Ministry of Industry and Information Technology interface, a carrier data interface, or another legitimate service provider authorized by the government or industry. This step ensures that if local data queries cannot meet verification requirements, the system can obtain accurate verification information from external authoritative data sources.

[0222] First, the system generates interface request parameters based on the number to be verified. Interface request parameters are standardized data structures passed to the authorization data interface, usually containing the following information:

[0223] Number to be verified: Uses international standard format (such as E.164) to ensure global compatibility.

[0224] Interface call token: A security token (such as an OAuth token or API key) that the system uses to authorize and verify the identity of the target server.

[0225] Request timestamp: used to prevent replay attacks and ensure request validity.

[0226] Client identifier: A unique identifier used to identify the source of the request (such as system ID, application ID).

[0227] After generating the interface request parameters, the system encrypts them to ensure that the data is not maliciously intercepted or tampered with during transmission. Encryption can be done in the following ways:

[0228] Symmetric encryption (such as AES-256): Uses a pre-shared key to encrypt request parameters. This method is suitable for scenarios where both communicating parties have already shared a key.

[0229] Asymmetric encryption (such as RSA-2048): Use the public key to encrypt the request parameters, and the target server uses the private key to decrypt it to ensure data security.

[0230] TLS-based encryption: Data is transmitted in the HTTPS secure channel, ensuring the confidentiality and integrity of data during transmission.

[0231] The encrypted interface request parameters are encapsulated into a secure request message. The message format can be flexibly adjusted according to the interface standard. For example:

[0232] JSON format: suitable for RESTful API interface, with clear data structure and easy parsing.

[0233] XML format: suitable for SOAP interface, with stronger structural characteristics.

[0234] Binary data formats (such as Protobuf and Thrift): suitable for binary communication with high performance requirements.

[0235] The system sends the security request message to the target server of the authorized data interface, usually through a secure transmission protocol such as HTTPS to ensure the security and integrity of the data during transmission. The target server for sending the request can be:

[0236] Ministry of Industry and Information Technology data interface: provides official location and company information for numbers within China.

[0237] Operator interface: Provides number authentication services for major operators (such as China Mobile, China Unicom, and China Telecom).

[0238] Industry data service platform: provides industry-specific number data authentication services (such as blacklist and whitelist services in the financial industry).

[0239] After receiving the security request message, the target server parses the request and returns an encrypted response. The encrypted response data typically includes the following information:

[0240] Organization Identifier: A unique identifier representing the company or organization to which the number belongs (such as company name, operator code).

[0241] Data validity period field: indicates the validity period of the returned data (such as 72 hours).

[0242] Status code and message: Indicates the response status (e.g. 200 for success, 401 for authentication failure).

[0243] After receiving the encrypted response data, the system first decrypts it using the same decryption method as the request encryption method (such as RSA private key decryption or AES decryption). The decrypted data is parsed into a structured format (such as a JSON object), from which the system further extracts the organization identification code and data validity period fields.

[0244] To ensure the data source is legitimate, the system compares the extracted institution identification code with a pre-stored whitelist of compliant service providers. The compliant service provider whitelist is a security mechanism used to prevent unauthorized or forged data sources from returning false data. The whitelist can contain the following:

[0245] Legal company name or organization name: such as "XX Financial Company", "XX Health Service Platform".

[0246] Unique identifier (e.g. credit code, company ID): ensures uniqueness.

[0247] Service provider API URL: restricts the legal domain name for interface calls.

[0248] If the organization identification code exists in the whitelist, the verification is successful, and the system uses the organization identification code as the third verification information. At the same time, the system associates the third verification information with the data validity period field to generate a cache data record. The cache data record is a key-value pair structure, where:

[0249] The key is the number to be verified: This ensures that the data can be retrieved quickly.

[0250] The value is the organization identification code and validity period: ensuring that the data remains current in the cache.

[0251] Finally, the system writes the cached data record to the cache verification database. The cache verification database usually uses an efficient key-value pair storage structure (such as Redis and Memcached) to ensure that the third verification information can be quickly hit in subsequent verification requests, avoiding repeated calls to the authorization data interface and improving system performance.

[0252] This embodiment ensures that users always receive authoritative and accurate verification results by invoking the authorized data interface to obtain third-party verification information when local data fails to meet verification requirements. Encryption of interface request parameters and whitelist verification of response data ensure the security and legitimacy of data during transmission and parsing. Writing third-party verification information to a cached verification database effectively reduces the frequency of repeated external interface calls, improves system response speed, and reduces user verification wait time.

[0253] In one embodiment, the above step S60 includes:

[0254] S601, determining a basic response template according to a source type of the target verification information, where the source type includes first verification information, second verification information, or third verification information;

[0255] S602, extracting key fields including number holder name, number usage classification and / or organization identification code from the target verification information;

[0256] S603, filling the key fields into the preset positions of the basic response template to generate a preliminary verification result text;

[0257] S604, performing grammatical compliance check on the preliminary verification result text;

[0258] S605: When the verification passes, the preliminary verification result text that passes the verification is marked as the final verification result.

[0259] In this embodiment, during the verification result generation process, the system dynamically selects a basic response template based on the source type of the target verification information. The target verification information can be derived from the first verification information (cached data in the cache verification database), the second verification information (channel data in the channel binding database), or the third verification information (external data obtained through the authorization data interface). Identifying the source type ensures that the system can generate adaptive response text based on the data structure and attributes of different sources.

[0260] First, the system determines a base response template based on the source type of the target verification information. Base response templates are predefined text frameworks used to construct standardized response text, including dynamic parameter placeholders. These templates can take various formats:

[0261] Text template: For example, "This number belongs to [organization name] and is used for [number purpose]."

[0262] HTML template: Suitable for APP or web page display, including hyperlinks and formatted text.

[0263] JSON template: Applicable to structured data returned by the API, including field names and corresponding values.

[0264] The system automatically selects the corresponding template based on the source type of the target verification information:

[0265] First verification information (cached verification information): uses the "cached data" template, which usually only contains the organization name and validity period.

[0266] Second verification information (channel binding information): uses the "channel information" template, including the channel identifier and usage classification.

[0267] The third verification information (external authorization data): uses the "authoritative certification" template, including the organization identification code, validity period and data source.

[0268] After determining the basic response template, the system extracts key fields from the target verification information. Key fields are the core data that determines the text content of the verification result, and usually include:

[0269] Number holder name: Identifies the name of the company or organization to which the number belongs, such as "XX Financial Company" or "Health Service Platform".

[0270] Number usage classification: identifies the purpose of the number, such as "customer notification", "marketing promotion", "security verification", etc.

[0271] Organization identification code: In the third verification information, the unique code of the company or organization to which the identification number belongs (such as unified social credit code, corporate ID).

[0272] When extracting key fields, the system uses different parsing rules based on the source type:

[0273] First verification information: parse "Organization Name" and "Validity Period" from the data structure in the cache verification database;

[0274] Second verification information: parse the "channel identifier" and "purpose classification" fields from the channel binding database;

[0275] Third verification information: parse the "Organization Identification Code" and "Validity Period" fields from the response data returned from the authorization data interface.

[0276] The extracted key fields are filled into the preset positions of the basic response template. The filling method can be:

[0277] Placeholder replacement: For example, replace "[Organization Name]" in the template with "XX Financial Company";

[0278] Structured data assembly: fill in data by field name in JSON template;

[0279] Formatted Text Embed: Embed hyperlinks or icons in HTML templates.

[0280] After filling in, the system generates a preliminary verification result text. The text may be:

[0281] SMS text: For example, "This number belongs to XX Financial Company and is used for customer notifications."

[0282] Web page display text: such as " The number belongs to <span style＝'color:blue；'> XX Financial Company ,use: Customer Notification ”

[0283] JSON data: such as {"Institution Name":"XX Financial Company","Purpose":"Customer Notification"}.

[0284] The system performs a grammatical compliance check on the preliminary verification result text to ensure that the generated text meets the channel requirements:

[0285] SMS text: The character length must not exceed 70 characters (single SMS) or 670 characters (long SMS) to avoid sending failure.

[0286] HTML text: Make sure tags are closed and formatted in accordance with W3C standards.

[0287] JSON data: Ensure that field names and data types conform to the predefined structure to avoid parsing errors.

[0288] If the syntax check passes, the system will mark the preliminary verification result text that passed the check as the final verification result, indicating that the text is ready for feedback to the user. If the check fails, the system will try to refill the template or change the template type.

[0289] This embodiment dynamically selects a basic response template based on the source type of the target verification information and extracts key fields from the target verification information to populate the template, ensuring the accuracy and readability of the verification results. Syntax compliance verification prevents delivery failures caused by formatting errors or character limits. Verification results automatically adapt to different display formats such as text messages, web pages, or structured data based on the template format, improving the diversity and applicability of verification results.

[0290] In one embodiment, after the above step S60, the method further includes:

[0291] S701, obtaining a user communication identifier associated with the verification request;

[0292] S702, determining a target feedback channel type according to the user communication identifier;

[0293] S703: Convert the verification result into a feedback message adapted to the target feedback channel type;

[0294] S704: Send the feedback message to the user terminal through a data transmission protocol corresponding to the target feedback channel type;

[0295] S705: Record the feedback status and feedback time of the verification result.

[0296] In this embodiment, after completing the generation of the verification result, the system continues to execute the feedback process to ensure that the user can receive the verification result in a timely manner. First, the system obtains the user communication identifier associated with the verification request. The user communication identifier is usually the user's mobile phone number, user ID or other identifier that can uniquely identify the user. In the case where the user initiates a verification request by replying to "Check Fake + Number" via SMS, the user communication identifier is the mobile phone number of the user who sent the request; in the case of initiating a verification request through an APP or web page, the user communication identifier may be a user ID or a device identifier. The system automatically captures and records the user communication identifier when responding to the request to ensure that subsequent feedback can be accurately delivered.

[0297] Next, the system determines the target feedback channel type based on the user's communication identifier. The feedback channel type can be SMS, APP push, email, or other supported data transmission channels. The system dynamically selects the best channel based on the type of user communication identifier (such as mobile phone number, user ID, email address) and user preferences (such as prioritizing APP notifications). For example, mobile phone numbers use the SMS channel by default, user IDs use APP push, and email addresses use the email channel. The channel type can be dynamically determined through a preset rule table or user configuration data.

[0298] After determining the feedback channel type, the system converts the generated verification results into a feedback message adapted to the channel type. The feedback message refers to the message text or data structure formatted according to the channel type:

[0299] SMS channel: Generates SMS messages in plain text format, with a maximum length of 70 characters (single message) or 670 characters (long message).

[0300] App push: The verification result is encapsulated into a JSON-formatted data message, including the field name (such as "Verification Result") and the field value (such as "XX Financial Company").

[0301] Email channel: Generates an email body in HTML format, including the organization logo, result text, and hyperlinks.

[0302] The system sends feedback messages based on the data transmission protocol corresponding to the feedback channel type:

[0303] SMS channel: Send SMS messages via SMPP (Short Message Peer-to-Peer Protocol) or HTTP SMS gateway;

[0304] APP push: Call the push service interface through HTTP / HTTPS protocol to push JSON format data to the user's device;

[0305] Email channel: Send emails to user mailboxes via SMTP (Simple Mail Transfer Protocol).

[0306] After sending the feedback message, the system monitors and records the feedback status and feedback time in real time. The feedback status indicates the execution result of the feedback operation, which usually includes the following:

[0307] Successful delivery: The operator or service platform returns a "successful delivery" status code;

[0308] Sending failure: such as SMS sending timeout, APP push failure, email bounce, etc.

[0309] Pending retry: Temporary failure due to network fluctuations or server busyness.

[0310] The feedback time indicates the specific time the system sends the feedback message, typically accurate to the millisecond level. The system records the feedback status and time in the log table to ensure subsequent troubleshooting or statistical analysis.

[0311] Example: In the fintech sector, user Xiao Li receives a collection SMS message from someone claiming to be "XX Financial Company." The message states, "Your loan is overdue. Please repay as soon as possible. For details, reply 'Check for Fakes +13812345678'." Xiao Li, doubting the authenticity of the message, follows the prompts and directly replies "Check for Fakes +13812345678" to the verification system. The verification system receives Xiao Li's reply and automatically identifies the user communication identifier "13898765432" and the number to be verified, "13812345678." The system first connects to the cached verification database and generates a database query index key based on the number to be verified, "13812345678." A match operation is performed on the index key in the cached verification database. If the first verification information for the number already exists in the cache, and the difference between the storage timestamp of the first verification information and the current time is within a preset validity period (e.g., 72 hours), the system uses the first verification information (e.g., "XX Financial Company") as the target verification information. If the first verification information for the number does not exist in the cached verification database, or if the first verification information has expired, the system will further query the local sending channel database based on the number to be verified. The system generates a channel binding query key and performs an exact match in the channel binding database. If a match is successful, the system extracts the channel identifier and binding time information associated with the query key to verify whether the channel binding time is within the validity period (e.g., 12 months). If the binding information meets the validity conditions, the system maps the channel identifier to "XX Financial Company" and uses this as the second verification information. If valid second verification information is not found in the channel binding database, the system automatically sends a verification request to the designated operator interface through the authorization data interface. The system generates interface request parameters (e.g., the number to be verified), encrypts the request parameters, and generates a secure request message. The secure request message is sent to the target server via the HTTPS protocol and the encrypted response data is received and parsed. The system extracts the institution identification code and data validity period fields from the response data and verifies whether the identification code exists in the pre-stored whitelist of compliant service providers. If verification is successful, the institution identification code (e.g., "XX Financial Company") is used as the third verification information and written to the cached verification database for subsequent quick query. The system generates a verification result based on the target verification information (e.g., "XX Financial Company"). The system selects a basic response template based on the source type of the target verification information (e.g., third-party verification information) and extracts the "number holder name" (e.g., "XX Financial Company") and "validity period" (e.g., "2023-09-25") from the target verification information. These key fields are entered into the preset locations of the basic response template to generate the preliminary verification result text, "This number belongs to XX Financial Company and is valid until 2023-09-25." The system verifies the grammatical compliance of the preliminary verification result text and, upon confirmation, marks it as the final verification result.The system retrieved Xiao Li's user communication identifier, "13898765432," and determined the feedback channel type to be SMS. The system converted the final verification result into SMS format, generating a feedback message stating, "This number belongs to XX Financial Company and is valid until 2023-09-25." This feedback message was then sent to the user terminal, "13898765432," via the SMPP SMS protocol, recording the feedback status as "Sent Successfully" and the feedback time as "2023-09-25 14:30:15.123." Upon receiving the feedback message, Xiao Li immediately confirmed that the collection message was indeed from XX Financial Company, resolving any concerns.

[0312] In the healthcare sector, user Xiao Zhang received a health reminder text message claiming to be from "XX Health Service Platform." The message read, "Your health monitoring data is abnormal. Please contact your doctor promptly and reply 'Check for Fakes +13887654321' for verification." Xiao Zhang questioned the authenticity of this information and initiated a query using the "Number Verification" function of the health service app. The app submitted the user's verification request to the system, which automatically identified the user's communication identifier "UserID12345" and the number to be verified, "13887654321." The system first connected to the cached verification database and generated a query index key based on the number to be verified. A matching operation was performed on the index key in the cached verification database. If the first verification information existed and was within a preset validity period (e.g., 72 hours), the first verification information (e.g., "XX Health Service Platform") was used as the target verification information. If no valid first verification information was found in the cached verification database, the system automatically switched to the channel binding database, generated a channel binding query key, and performed an exact match. If the channel binding information is valid (e.g., the channel ID is bound to "XX Health Service Platform" and has not expired), the system maps the channel identifier to "XX Health Service Platform" and uses this as the second verification information. If valid second verification information is not available in the channel binding database, the system automatically sends a verification request to the designated carrier interface through the authorized data interface. The system generates interface request parameters (e.g., number + area code) based on the number to be verified and encrypts the request parameters. The encrypted request is sent to the carrier server via HTTPS, which receives and parses the response data. The system extracts the organization identifier "XX Health Service Platform" from the response data and verifies that it is on the whitelist of compliant service providers. This identifier is used as the third verification information and written to the cached verification database. The system generates a verification result based on the target verification information "XX Health Service Platform," selects the basic response template, and extracts the "Number Holder Name" and "Validity Period" fields (e.g., "2023-09-30") from the target verification information. The system generates the verification result text, "This number belongs to XX Health Service Platform and is valid until 2023-09-30," and verifies its syntax for compliance. After confirmation, it is marked as the final verification result. The system obtains Xiao Zhang's user communication identifier "UserID12345" and determines the feedback channel type as APP push. The system encapsulates the verification result as JSON format data {"Verification result":"This number belongs to the XX health service platform and is valid until 2023-09-30"} and pushes it to the user terminal via HTTPS. The system records the feedback status as "Sent successfully" and the feedback time as "2023-09-2514:32:45.567". Xiao Zhang receives the verification result in the APP notification bar, confirming that the reminder information did indeed come from the XX health service platform.

[0313] This embodiment automatically obtains the user's communication identifier and dynamically determines the feedback channel type, ensuring accurate and rapid feedback of verification results to the user terminal. The system automatically formats the feedback message based on the feedback channel type and sends it using the appropriate transmission protocol, improving the compatibility and reliability of the feedback process. By monitoring feedback status and time in real time, the system can promptly identify and address transmission anomalies, ensuring that users receive verification results promptly.

[0314] In one embodiment, an information sender verification device is provided, which corresponds to the information sender verification method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the information sender verification device of the present invention. It includes a request processing unit 10, a cache verification module 20, a verification information confirmation module 30, a channel association query module 40, an authorization query module 50, and a verification result generation module 60. Each functional module is described in detail below:

[0315] The request processing unit 10 is used to obtain a verification request and extract a number to be verified from the verification request;

[0316] A cache verification module 20 is configured to query a cache verification database based on the number to be verified, and determine whether there is first verification information of the number to be verified and whether the first verification information is within a preset validity period;

[0317] The verification information confirmation module 30 is configured to use the first verification information as the target verification information if the first verification information of the number to be verified exists and the first verification information is within a preset validity period;

[0318] a channel association query module 40 configured to query a channel binding database based on the number to be verified, obtain second verification information associated with the number to be verified, and use the second verification information as target verification information if the first verification information of the number to be verified does not exist or the first verification information is not within a preset validity period;

[0319] The authorization query module 50 is configured to obtain third verification information associated with the number to be verified through the authorization data interface if the second verification information is not obtained by querying the channel binding database, use the third verification information as the target verification information, and write the third verification information into the cache verification database;

[0320] The verification result generating module 60 is configured to generate a verification result according to the target verification information.

[0321] In one embodiment, the request processing unit 10 is specifically configured to:

[0322] Receive reply messages to original messages in the user's communication account;

[0323] Identifying whether the reply information contains a preset instruction trigger identifier;

[0324] If the reply information contains the instruction trigger identifier, extracting the to-be-verified number field in the reply information;

[0325] The instruction trigger identifier is associated with the number to be verified field to generate standardized verification request data.

[0326] In one embodiment, the cache verification module 20 is specifically configured to:

[0327] Connect to a pre-configured cache validation database;

[0328] Generate a database query index key based on the number to be verified;

[0329] performing an index key matching operation in the cache validation database;

[0330] If the match is successful, extracting the first verification information and storage timestamp associated with the index key from the cache verification database;

[0331] Determine the time difference between the current time and the stored timestamp;

[0332] Comparing the time difference with a preset validity period;

[0333] When the time difference is less than or equal to the preset validity period, it is determined that the first verification information is valid.

[0334] In one embodiment, the channel association query module 40 is specifically configured to:

[0335] If the first verification information of the number to be verified does not exist in the cache verification database or the first verification information is not within the preset validity period, generating a channel binding query key according to the number to be verified;

[0336] Performing a matching operation of the channel binding query key in a channel binding database;

[0337] If the match is successful, extracting the channel identifier and binding time information associated with the channel binding query key from the channel binding database;

[0338] Verifying whether the binding time information meets the channel validity condition;

[0339] When the binding time information meets the channel validity condition, the channel identifier is used as the second verification information.

[0340] In one embodiment, the authorization query module 50 is specifically configured to:

[0341] If the second verification information is not obtained by querying the channel binding database, generating an interface request parameter according to the number to be verified;

[0342] Encrypting the interface request parameters to generate a security request message;

[0343] Sending the security request message to the target server of the authorization data interface;

[0344] Receiving encrypted response data returned by the target server;

[0345] Parsing the organization identification code and data validity period fields in the encrypted response data;

[0346] Verify whether the institution identification code exists in the pre-stored whitelist of compliant service providers;

[0347] When the verification is successful, the institution identification code is used as the third verification information;

[0348] Associating the third verification information with the data validity period field to generate a cache data record;

[0349] The cache data record is written into a cache verification database.

[0350] In one embodiment, the verification result generation module 60 is specifically configured to:

[0351] Determining a basic response template according to a source type of the target verification information, where the source type includes first verification information, second verification information, or third verification information;

[0352] Extracting key fields including number holder name, number usage classification and / or organization identification code from the target verification information;

[0353] Fill the key fields into the preset positions of the basic response template to generate a preliminary verification result text;

[0354] Performing grammatical compliance check on the preliminary verification result text;

[0355] When the verification passes, the preliminary verification result text that passes the verification is marked as the final verification result.

[0356] In one embodiment, the verification result generation module 60 is specifically configured to:

[0357] obtaining a user communication identifier associated with the verification request;

[0358] determining a target feedback channel type according to the user communication identifier;

[0359] Converting the verification result into a feedback message adapted to the target feedback channel type;

[0360] Sending the feedback message to the user terminal through a data transmission protocol corresponding to the target feedback channel type;

[0361] Record the feedback status and feedback time of the verification result.

[0362] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the server side of an information sender verification method.

[0363] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a user-side method for verifying the sender of information.

[0364] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0365] Obtaining a verification request and extracting a number to be verified from the verification request;

[0366] Based on the number to be verified, the cache verification database is searched to determine whether the first verification information of the number to be verified exists and whether the first verification information is within a preset validity period;

[0367] If there is first verification information of the number to be verified and the first verification information is within a preset validity period, the first verification information is used as the target verification information;

[0368] If the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, query the channel binding database based on the number to be verified, obtain the second verification information associated with the number to be verified, and use the second verification information as the target verification information;

[0369] If the second verification information is not obtained by querying the channel binding database, obtaining the third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database;

[0370] A verification result is generated according to the target verification information.

[0371] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0372] Obtaining a verification request and extracting a number to be verified from the verification request;

[0373] Based on the number to be verified, the cache verification database is searched to determine whether the first verification information of the number to be verified exists and whether the first verification information is within a preset validity period;

[0374] If there is first verification information of the number to be verified and the first verification information is within a preset validity period, the first verification information is used as the target verification information;

[0375] If the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, query the channel binding database based on the number to be verified, obtain the second verification information associated with the number to be verified, and use the second verification information as the target verification information;

[0376] If the second verification information is not obtained by querying the channel binding database, obtaining the third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database;

[0377] A verification result is generated according to the target verification information.

[0378] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0379] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0380] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0381] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A method for verifying an information sender, characterized in that: The following steps are involved: Obtaining a verification request and extracting a number to be verified from the verification request; Based on the number to be verified, the cache verification database is searched to determine whether the first verification information of the number to be verified exists and whether the first verification information is within a preset validity period; If there is first verification information of the number to be verified and the first verification information is within a preset validity period, the first verification information is used as the target verification information; If the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, query the channel binding database based on the number to be verified, obtain the second verification information associated with the number to be verified, and use the second verification information as the target verification information; If the second verification information is not obtained by querying the channel binding database, obtaining the third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database; A verification result is generated according to the target verification information.

2. The information sender verification method according to claim 1, wherein: Obtaining a verification request and extracting the number to be verified from the verification request, including: Receive reply messages to original messages in the user's communication account; Identifying whether the reply information contains a preset instruction trigger identifier; If the reply information contains the instruction trigger identifier, extracting the to-be-verified number field in the reply information; The instruction trigger identifier is associated with the number to be verified field to generate standardized verification request data.

3. The information sender verification method according to claim 1, wherein: Querying a cache verification database based on the number to be verified to determine whether first verification information of the number to be verified exists and whether the first verification information is within a preset validity period includes: Connect to a pre-configured cache validation database; Generate a database query index key based on the number to be verified; performing an index key matching operation in the cache validation database; If the match is successful, extracting the first verification information and storage timestamp associated with the index key from the cache verification database; Determine the time difference between the current time and the stored timestamp; Comparing the time difference with a preset validity period; When the time difference is less than or equal to the preset validity period, it is determined that the first verification information is valid.

4. The information sender verification method according to claim 1, wherein: If the first verification information of the number to be verified does not exist or the first verification information is not within the preset validity period, querying the channel binding database based on the number to be verified, obtaining the second verification information associated with the number to be verified, and using the second verification information as the target verification information, including: If the first verification information of the number to be verified does not exist in the cache verification database or the first verification information is not within the preset validity period, generating a channel binding query key according to the number to be verified; Performing a matching operation of the channel binding query key in a channel binding database; If the match is successful, extracting the channel identifier and binding time information associated with the channel binding query key from the channel binding database; Verifying whether the binding time information meets the channel validity condition; When the binding time information meets the channel validity condition, the channel identifier is used as the second verification information.

5. The information sender verification method according to claim 1, wherein: If the second verification information is not obtained by querying the channel binding database, obtaining third verification information associated with the number to be verified through the authorization data interface, using the third verification information as the target verification information, and writing the third verification information into the cache verification database, including: If the second verification information is not obtained by querying the channel binding database, generating an interface request parameter according to the number to be verified; Encrypting the interface request parameters to generate a security request message; Sending the security request message to the target server of the authorization data interface; Receiving encrypted response data returned by the target server; Parsing the organization identification code and data validity period fields in the encrypted response data; Verify whether the institution identification code exists in the pre-stored whitelist of compliant service providers; When the verification is successful, the institution identification code is used as the third verification information; Associating the third verification information with the data validity period field to generate a cache data record; The cache data record is written into a cache verification database.

6. The information sender verification method according to claim 1, wherein: Generating a verification result according to the target verification information includes: Determining a basic response template according to a source type of the target verification information, where the source type includes first verification information, second verification information, or third verification information; Extracting key fields including number holder name, number usage classification and / or organization identification code from the target verification information; Fill the key fields into the preset positions of the basic response template to generate a preliminary verification result text; Performing grammatical compliance check on the preliminary verification result text; When the verification passes, the preliminary verification result text that passes the verification is marked as the final verification result.

7. The information sender verification method according to claim 1, wherein: After generating a verification result according to the target verification information, the method further includes: obtaining a user communication identifier associated with the verification request; determining a target feedback channel type according to the user communication identifier; Converting the verification result into a feedback message adapted to the target feedback channel type; Sending the feedback message to the user terminal through a data transmission protocol corresponding to the target feedback channel type; Record the feedback status and feedback time of the verification result.

8. An information sender verification device, characterized in that: The information sender verification device includes: A request processing unit, configured to obtain a verification request and extract a number to be verified from the verification request; A cache verification module is used to query a cache verification database based on the number to be verified, and determine whether there is first verification information of the number to be verified and whether the first verification information is within a preset validity period; a verification information confirmation module, configured to use the first verification information as target verification information if the first verification information of the number to be verified exists and the first verification information is within a preset validity period; a channel association query module, configured to query a channel binding database based on the number to be verified, obtain second verification information associated with the number to be verified, and use the second verification information as target verification information if the first verification information of the number to be verified does not exist or the first verification information is not within a preset validity period; an authorization query module, configured to, if the second verification information is not obtained by querying the channel binding database, obtain third verification information associated with the number to be verified through the authorization data interface, use the third verification information as target verification information, and write the third verification information into the cache verification database; The verification result generating module is used to generate a verification result according to the target verification information.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and an information sender verification program stored in the memory and capable of running on the processor. When the information sender verification program is executed by the processor, the steps of the information sender verification method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores an information sender verification program, which, when executed by the processor, implements the steps of the information sender verification method according to any one of claims 1 to 7.

Images