Method and apparatus for automated processing of securities claims

Abstract

This application provides an automated securities claim processing method, comprising the following steps: obtaining server access permissions authorized by the user terminal through a preset encrypted communication protocol; pre-setting securities feature keywords, using the securities feature keywords to perform a full scan of the target data source in the server, and identifying the original data containing the securities feature keywords; analyzing the original data, extracting the core metadata of securities transactions from the original data, performing deduplication and standardization processing on the core metadata of securities transactions, generating standard core metadata; comparing the standard core metadata with a securities violation risk database, identifying the securities violation risk database corresponding to the standard core metadata, and generating a claim case summary.

Description

Technical Field

[0001] This invention relates to the field of securities claims technology, and in particular to methods and equipment for automating securities claims processing. Background Technology

[0002] Securities trading has long been a common investment and wealth management tool for many ordinary people. With the development of the information age, securities trading is now conducted via mobile phones or computers, making it very convenient. Investors profit by purchasing stocks, funds, or bonds. In this process, some brokerage firms offer various software programs that are linked to investors' bank accounts, allowing them to invest their own funds in securities.

[0003] With the continuous fluctuations in the economic environment, especially in recent years with the rapid adjustments in both international and domestic economic developments, China's capital market is currently under strict regulation. Regulatory efforts are continuously strengthening, the number of delisted companies has increased significantly, and civil compensation cases arising from false statements have also risen sharply. However, in practice, many shareholders are often unaware of their right to claim compensation, or even if they are aware, they are deterred by the complex procedures and high professional thresholds required, ultimately choosing to abandon their legitimate rights. Summary of the Invention

[0004] To address the aforementioned technical problems in the prior art, this invention provides an automated securities claim processing method, comprising the following steps:

[0005] Obtain server access permissions authorized by the user terminal through a preset encrypted communication protocol;

[0006] Preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords;

[0007] The original data is analyzed to extract the core metadata of securities trading. The core metadata of securities trading is deduplicated and standardized to generate standard core metadata.

[0008] The standard core metadata is compared with the securities violation risk database to identify the securities violation risk database corresponding to the standard core metadata, and a claim case summary is generated.

[0009] Specifically, the automated securities claim processing method further includes the following steps:

[0010] The claim case briefing is compared with the lawyers in the lawyer information database to identify the matching degree between the claim case briefing and the lawyers, and suitable lawyer resources are selected.

[0011] An online power of attorney signing channel is established, through which the lawyer and the user terminal complete the power of attorney procedures and payment.

[0012] Specifically, the step of obtaining server access permissions authorized by the user terminal through a preset encrypted communication protocol:

[0013] The access request was initiated and the protocol was matched.

[0014] Authentication and verification;

[0015] Obtaining a dynamic authorization token;

[0016] Establish advanced encrypted transmission channels;

[0017] Controlled access and data flow monitoring.

[0018] Specifically, the step of using the preset securities feature keywords to perform a full scan of the target data source in the server and identifying the original data containing the securities feature keywords includes:

[0019] Perform a full scan of the target data source, retrieve only the metadata of the server authorized by the user terminal, and generate suspected metadata;

[0020] Read the title or attachment name of the suspected metadata;

[0021] Based on the title or the name of the attachment, the suspected metadata is further filtered;

[0022] Delete the suspected metadata that is not in the metadata, and temporarily store the suspected metadata.

[0023] Specifically, the steps of analyzing the raw data, extracting core metadata of securities trading from the raw data, and deduplicating and standardizing the core metadata of securities trading to generate standard core metadata include:

[0024] The suspected metadata is parsed to identify the core table area within it;

[0025] The core table area is parsed and converted into atomic fields;

[0026] A unique feature value is generated for the atomic field, and then it is encapsulated and packaged.

[0027] Specifically, the step of comparing the standard core metadata with the securities violation risk database, identifying the securities violation risk database corresponding to the standard core metadata, and generating a claim case summary includes:

[0028] Retrieve the latest securities violation risk database and retrieve the feature value;

[0029] The atomic fields are compared with the securities violation risk database;

[0030] Filter out the user terminals that meet the claims;

[0031] Calculate at least one of the following for the user terminal: the amount of loss, the success rate, and the legal basis.

[0032] Generate a briefing on the claims case.

[0033] Specifically, the step of comparing the claim case brief with lawyers in the lawyer database, identifying the match between the claim case brief and the lawyers, and selecting the most suitable lawyer resources includes:

[0034] Retrieve the matching parameters of the lawyers in the lawyer information database;

[0035] The matching parameters mentioned are at least one of the following: success rate, total amount of compensation awarded, years of practice, location of the lawyer's license, historical frequency of representation in the court with jurisdiction over the case, number of cases in progress, response speed index, or remaining capacity.

[0036] Match the claim case briefing with the matching parameters;

[0037] The system pushes suitable lawyers from the lawyer information database to the user terminal.

[0038] Specifically, the steps of establishing an online power of attorney signing channel, in which the lawyer and the user terminal complete the power of attorney procedures and payment, include:

[0039] Based on the claim case briefing and the lawyers in the lawyer information database, improve the preset legal document template;

[0040] Real-name authentication and electronic signatures are performed on the user terminal and the lawyers in the lawyer information database.

[0041] The fees paid by the user terminal are temporarily stored in a third-party payment platform;

[0042] Based on the case outcome, the fees paid by the user terminal will be allocated to the lawyers in the lawyer information database.

[0043] This application also provides an automated securities claims processing device, comprising:

[0044] The data access and authorization module is used to obtain server access permissions authorized by the user terminal through a preset encrypted communication protocol;

[0045] The feature information retrieval module is used to preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords;

[0046] The structured parsing and cleaning module is used to analyze the raw data, extract the core metadata of securities trading from the raw data, deduplicate and standardize the core metadata of securities trading, and generate standard core metadata.

[0047] The claims logic is automatically matched to compare the standard core metadata with the securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claims case summary.

[0048] Specifically, the automated securities claims processing equipment also includes:

[0049] The legal resource matching module is used to compare the claim case briefs with lawyers in the lawyer information database, identify the matching degree between the claim case briefs and the lawyers, and select the most suitable lawyer resources.

[0050] The dispute resolution and payment module is used to establish an online agency agreement signing channel, through which the lawyer and the user terminal complete the agency procedures and payment.

[0051] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein:

[0053] Figure 1 This is a flowchart illustrating the automated securities claim processing method provided in this application;

[0054] Figure 2 This is a flowchart illustrating another automated securities claim processing method provided in this application;

[0055] Figure 3This is a flowchart illustrating step S1 provided in this application;

[0056] Figure 4 This is a flowchart illustrating step S2 provided in this application;

[0057] Figure 5 This is a flowchart illustrating step S3 provided in this application;

[0058] Figure 6 This is a flowchart illustrating step S4 provided in this application;

[0059] Figure 7 A flowchart illustrating step S5 provided for this application;

[0060] Figure 8 A flowchart illustrating step S6 provided for this application;

[0061] Figure 9 A schematic diagram of the structure of an automated securities claim processing device provided in this application;

[0062] Figure 10 A schematic diagram of another automated securities claim processing device provided for this application;

[0063] Figure 11 for Figure 10 A schematic diagram of the data access and authorization module in the system;

[0064] Figure 12 This is a schematic diagram of the feature information retrieval module in this application;

[0065] Figure 13 This is a schematic diagram of the structured parsing and cleaning module in this application;

[0066] Figure 14 This is a schematic diagram of the automatic claim logic matching module in this application;

[0067] Figure 15 This is a schematic diagram of the legal resource matching module in this application;

[0068] Figure 16 A schematic diagram of the dispute resolution and payment module provided in this application. Detailed Implementation

[0069] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0070] It should be noted that all directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of the present invention are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indication will also change accordingly.

[0071] Furthermore, in this invention, descriptions involving "first," "second," etc., are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0072] In this invention, unless otherwise explicitly specified and limited, the terms "connection," "fixed," etc., should be interpreted broadly. For example, "fixed" can mean a fixed connection, a detachable connection, or an integral part; it can mean a mechanical connection or an electrical connection; it can mean a direct connection or an indirect connection through an intermediate medium; it can mean the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0073] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0074] like Figure 1 As shown, Figure 1 This is a flowchart illustrating the automated securities claim processing method provided in this application. It includes the following steps:

[0075] S1, obtains server access permissions authorized by the user terminal through a preset encrypted communication protocol;

[0076] S2, preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords;

[0077] S3, Analyze the original data, extract the core metadata of securities trading from the original data, perform deduplication and standardization on the core metadata of securities trading, and generate standard core metadata;

[0078] S4. Compare the standard core metadata with the securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claim case summary.

[0079] It should be noted that the specific implementation of the securities violation risk database can be from the Shenzhen Stock Exchange, Shanghai Stock Exchange, or Beijing Stock Exchange, and can also be from announcements from different stock markets such as the US stock market and the Hong Kong stock market.

[0080] It should be noted that common encrypted communication protocols can be IMAP / SSL protocols or RESTful API protocols based on HTTPS.

[0081] It should be noted that securities characteristic keywords can include keywords such as account statements, transaction reports, and settlement cards.

[0082] like Figure 2 As shown, Figure 2 This is a flowchart illustrating another method for automating securities claims processing provided in this application. It includes the following steps:

[0083] S1, obtains server access permissions authorized by the user terminal through a preset encrypted communication protocol;

[0084] S2, preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords;

[0085] S3, Analyze the original data, extract the core metadata of securities trading from the original data, perform deduplication and standardization on the core metadata of securities trading, and generate standard core metadata;

[0086] S4. Compare the standard core metadata with the securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claim case summary.

[0087] S5, compare the claim case briefing with the lawyers in the lawyer information database, identify the matching degree between the claim case briefing and the lawyers, and select suitable lawyer resources;

[0088] S6. Establish an online power of attorney signing channel, whereby the lawyer and the user terminal complete the power of attorney procedures and payment.

[0089] like Figure 3 As shown, Figure 3 This is a flowchart illustrating step S1 provided in this application, which includes:

[0090] S11, Access request initiation matches protocol;

[0091] S12, authentication and verification;

[0092] S13, Obtaining the dynamic authorization token;

[0093] S14, Establish an advanced encrypted transmission channel;

[0094] S15, Controlled Access and Data Flow Monitoring.

[0095] Furthermore, in a specific embodiment, step S11 may specifically include:

[0096] S111, The system receives the data source instruction selected by the user;

[0097] Among them, the common data source types can be the user's terminal's connected email or connected brokerage account;

[0098] S112, The system automatically matches the communication protocol according to the data source type;

[0099] For example, if the data source type is email, it matches the IMAP / SSL protocol; if it is a brokerage firm, it matches the RESTful API interface based on HTTPS.

[0100] It's important to explain IMAP (Internet Message Access Protocol). It's a protocol that allows email clients to retrieve email information from mail servers. Its key feature is that emails are stored on the server, and the client only operates on a copy. Your actions on the app (such as marking emails as read) are synchronized to the server and all your devices.

[0101] SSL (Secure Sockets Layer), now usually refers to its successor TLS (Transport Layer Security). In this context, it serves to encrypt the channel.

[0102] HTTPS (Hypertext Transfer Protocol Secure) is essentially HTTP (HTTP) with an additional layer of SSL / TLS encryption. This ensures that data sent from a mobile app to the server is encrypted.

[0103] RESTful API (Representational State Transfer; Application Programming Interface).

[0104] S113, Initialize security parameters, prepare to establish an encrypted transmission tunnel.

[0105] It should be noted that encrypted transmission tunnels generally use the TLS 1.3 standard, which is the latest standard in the field of network security.

[0106] In some embodiments, step S12 includes:

[0107] The user terminal completes the first verification, which can be at least one of the following: APP login password, facial recognition, or fingerprint recognition.

[0108] The user terminal undergoes a second verification, which can be achieved by sending a dynamic verification code to the user's bound mobile phone or email address, or by calling a time-based one-time password generated by the mobile phone hardware.

[0109] Only after the first and second verifications are completed will the system allow the user to proceed to step S13.

[0110] In some embodiments, step S13 specifically includes:

[0111] The user terminal is prompted to navigate to the official authorization page of the third-party platform, and the user terminal completes the login confirmation.

[0112] The third-party platform returns a temporary Auth Code to the user's terminal.

[0113] The system backend uses the encrypted transmission tunnel to exchange the Auth Code for an Access Token and a Refresh Token from a third-party platform.

[0114] Furthermore, the system explicitly limits the scope of the Token to "reading transaction-related emails / records only" and refuses to modify permissions.

[0115] In some embodiments, step S14 may include:

[0116] The system uses DH (Diffie-Hellman, key exchange algorithm) to generate session symmetric keys;

[0117] Enable the zero round-trip latency feature of the TLS 1.3 protocol to improve efficiency;

[0118] The transmitted messages are encapsulated using AEAD (Authenticated Encryption with Associated Data) to ensure that the data cannot be eavesdropped on, tampered with, or replayed during transmission.

[0119] In some embodiments, step S15 may include:

[0120] The system uses an Access Token to access the target interface and only retrieves specific data streams that match preset keywords (such as "account statement", "transaction" etc.).

[0121] The system monitors the validity period of tokens in real time. Once expired, it automatically and silently updates the token using Refresh Token, or immediately forces the token to become invalid when an abnormal login is detected.

[0122] In this embodiment, the system referred to herein is the carrier on which the method of this application is implemented, and the carrier may be at least one of web pages, mini-programs, and software.

[0123] In one embodiment of this application, a user receives an electronic account statement sent by a brokerage firm via QQ Mail. The specific operation flow for implementing step S1 can be as follows:

[0124] Step 1: The S1-enabled app detects that the user has selected QQ Mail and pops up a guide page to instruct the user to enable IMAP service in the email settings.

[0125] Step 3: The user generates a 16-digit authorization code in their email.

[0126] Step 4: The user enters the authorization code into the APP, and the system immediately connects to the QQ email server via TLS 1.3.

[0127] Step 5: The system performs MFA verification in the background and sends a confirmation command to the user's mobile phone: "The system is requesting to read your email. Do you want to confirm?".

[0128] Step Six: After user confirmation, the system logs in using the authorization code and only retrieves email headers containing the keyword "securities statement".

[0129] It should be noted that QQ Mail can also be 126 Mail, 163 Mail, Gmail, or other email addresses. QQ Mail is used here only as an example and should not be considered as a limitation on the scope of protection of this application.

[0130] It should be noted that the number of bits in the authorization code in step three can be adjusted according to actual needs and does not necessarily have to be 16 bits. This application is only using 16 bits as an example and is not considered as a limitation on the scope of protection of this application.

[0131] like Figure 4 As shown, Figure 4 This is a flowchart illustrating step S2 provided in this application, which includes:

[0132] S21, Perform a full scan of the target data source, retrieve only the metadata of the server authorized by the user terminal, and generate suspected metadata;

[0133] S22, Read the title or attachment name of the suspected metadata;

[0134] S23, perform a second screening of the suspected metadata based on the title or the name of the attachment;

[0135] S24, delete the non-suspected metadata from the metadata, and temporarily store the suspected metadata.

[0136] In step S21, in a specific embodiment, the metadata may only include email header information, excluding email body information. During this process, only emails whose sender domain belongs to a preset brokerage whitelist are matched; or emails whose headers contain terms like "account statement," "trade report," or "settlement card."

[0137] This step is primarily to ensure that reading personal emails on the user's terminal is excluded, thus protecting personal privacy and avoiding the scraping of non-securities-related emails.

[0138] In step S23, suspected metadata is further filtered. During this process, a lightweight natural language processing model is used to "determine the intent" of the email content. The logic in this process is to classify the content of an email and map it to a specific label L (e.g., L∈{Securities Trading, Personal Privacy, Spam}). Through this labeling and classification process, suspected metadata is classified.

[0139] In addition, Boolean logic operations are used, such as the search expression (Stocks OR Securities OR Bonds) AND (Trading Volume OR Commissions OR Balance OR Frozen Data), to filter suspected metadata. "OR" means "or".

[0140] Furthermore, this step can also identify useful potential metadata by searching the table's layout or by searching for stock codes that match the 6-digit characteristic.

[0141] In step S24, for emails that do not match the securities characteristics, the system executes an "instant erase" instruction in the memory buffer. This ensures that data from non-target emails is not written to disk (i.e., not stored on the hard drive), and only the "scan count" is recorded in the system log, without recording any text information from non-target emails. This guarantees the protection of user terminal privacy.

[0142] like Figure 5 As shown, Figure 5 This is a flowchart illustrating step S3 provided in this application, which includes:

[0143] S31, parse the suspected metadata and identify the core table area in the suspected metadata;

[0144] S32, parse the core table area and parse the core table area into atomic fields;

[0145] S33, generate a unique feature value for the atomic field and encapsulate and package it.

[0146] The algorithm that can be used in step S31 can be a coordinate-based heuristic algorithm or a deep learning table detection model.

[0147] The following is an example of a coordinate-based heuristic algorithm:

[0148] For example, in most brokerage firms' standard account statement PDFs, the words "stock code" are usually fixed in the upper left corner, and the "transaction date" is in the right side.

[0149] Define the search area: Based on these inherent areas, delineate the area where the data is located. For example, the rule could be: within a rectangle starting below the stock code title (x=100, y=70) and ending at (x=300, y=500), all horizontally arranged text blocks constitute the stock code list.

[0150] In step S32, OCR (Optical Character Recognition) or DOM tree parsing techniques can be applied to map the text within the located area into atomic fields. Specifically, this step can be:

[0151] Format recognition: Determines whether the user has uploaded an image or an HTML / PDF text file.

[0152] Region location: For images, use TableNet to find the table area; for HTML, use the DOM parser.

[0153]

[0154]

[0155]

[0156]

[0157]

[0158]

[0159]

[0160]

[0161] Figure 6 Figure 6

[0162]

[0163]

[0164]

[0165]

[0166]

[0167]

[0168]

[0169]

[0170]

[0171]

[0172]

[0173]

[0174]

[0175]

[0176]

[0177]

[0178]

[0179]

[0180]

[0181] Figure 7 Figure 7

[0182]

[0183]

[0184]

[0185]

[0186]

[0187]

[0188]

[0189]

[0190]

[0191] Figure 8 Figure 8

[0192]

[0193]

[0194]

[0195]

[0196]

[0197]

[0198]

[0199]

[0200]

[0201]

[0202]

[0203]

[0204]

[0205]

[0206]

[0207]

[0208] Figure 9 Figure 9

[0209]

[0210]

[0211]

[0212]

[0213] Figure 10 Figure 10

[0214]

[0215]

[0216]

[0217]

[0218]

[0219]

[0220]

[0221] Figure 11 Figure 11 Figure 10

[0222]

[0223]

[0224]

[0225]

[0226]

[0227]

[0228]

[0229]

[0230]

[0231]

[0232]

[0233]

[0234]

[0235]

[0236]

[0237]

[0238]

[0239]

[0240]

[0241]

[0242]

[0243]

[0244]

[0245]

[0246]

[0247]

[0248]

[0249]

[0250]

[0251]

[0252]

[0253]

[0254]

[0255] Figure 12 Figure 12

[0256]

[0257]

[0258]

[0259]

[0260]

[0261]

[0262]

[0263]

[0264]

[0265]

[0266] Figure 13 Figure 13

[0267]

[0268]

[0269]

[0270]

[0271]

[0272]

[0273]

[0274]

[0275]

[0276]

[0277]

[0278]

[0279]

[0280]

[0281]

[0282]

[0283]

[0284]

[0285] Figure 14 Figure 14

[0286]

[0287]

[0288]

[0289]

[0290]

[0291]

[0292]

[0293]

[0294]

[0295]

[0296]

[0297]

[0298]

[0299]

[0300]

[0301]

[0302]

[0303]

[0304]

[0305] Figure 15 Figure 15

[0306]

[0307]

[0308]

[0309]

[0310]

[0311]

[0312]

[0313]

[0314] Figure 16 Figure 16

[0315]

[0316]

[0317]

[0318]

[0319]

[0320]

[0321]

[0322]

[0323]

[0324]

[0325]

[0326]

[0327]

[0328]

[0329]

[0330]

[0331]

[0332]

[0333]

[0334]

[0335] Tags. Text Extraction: If it is an image, use OCR to convert the image in the grid into text; if it is HTML, directly extract the text within the tags. Ultimately, the generated text tags in this text extraction can be at least one of the following: stock name, stock code, transaction date, transaction time, transaction direction, securities account number, fund account number, transaction price, transaction quantity, total transaction amount, handling fee, stamp duty, and transfer fee. Specifically, step S33 can be: mapping non-standard names (such as "Ping An Bank") to standard codes through the backend securities master database; converting various heterogeneous times (such as "23 / 05 / 12", "May 12, 2023, 14:30") to the ISO 8601 standard format (2023-05-12 14:30:00); converting transaction quantities to "shares" (excluding the ambiguity of "lots"); and encapsulating the verified data as the data input source for subsequent steps. As shown, this is a flowchart illustrating step S4 of this application. Step S4 includes: S41, retrieving the latest securities violation risk database and retrieving the feature values; S42, comparing the atomic fields with the securities violation risk database; S43, filtering out user terminals that meet the claim criteria; S44, calculating at least one of the user terminal's loss amount, success rate, and legal basis; and S45, generating a claim case summary. The feature values ​​in step S41 can be core legal nodes for each involved company, such as: Implementation Date: the date the false statement began; Disclosure Date: the date the violation was first publicly disclosed or investigated; Base Date: a reference date when market risk has been fully released and stock prices have returned to normal. The specific steps for comparing the atomic fields with the securities violation risk database in steps S42 and S43 can be: comparing and analyzing the transactions contained in the atomic fields with the aforementioned Implementation Date, Disclosure Date, and Base Date to determine whether the transactions contained in the atomic fields meet the claim criteria. For example, only records where the purchase date is after the "Implementation Date" and before the "Disclosure Date," and the purchase was made and then sold or continued to be held after the "Disclosure Date," are marked as "valid claim entries." In step S44, the calculation method for the loss amount includes: Investment difference loss: the difference between the average purchase price and the benchmark price / average selling price multiplied by the number of shares; Commission and stamp duty loss: transaction tax losses calculated proportionally; Systemic risk deduction: automatically calling the industry index volatility for the same period and using a correlation analysis algorithm to isolate non-violation losses caused by market declines.The method for calculating the success rate includes: the system identifies the real-time status of the case corresponding to the stock (e.g., under investigation by the China Securities Regulatory Commission, already in the first instance by the court, or with existing successful precedents); based on historical judgment data and the solvency of the defendant company (e.g., balance sheet data), the estimated recovery rate and success probability score of the claim are calculated. Step S45 may include: template-filling the above identification results, calculated data, and legal analysis; summarizing the total claimable amount, a summary of violations, a warning of the time limit for rights protection (distance to the litigation deadline), and suggested operating procedures; generating a PDF or interactive HTML briefing and pushing it to the user terminal. Further, as shown, is a flowchart of step S5 provided in this application. In some embodiments, step "S5, comparing the claim case brief with lawyers in the lawyer information database, identifying the matching degree between the claim case brief and the lawyers, and selecting the most suitable lawyer resources" includes: S51, retrieving the matching parameters of lawyers in the lawyer information database; S52, matching the claim case brief with the matching parameters; S53, pushing suitable lawyers from the lawyer information database to the user terminal. The matching parameters are at least one of the following: win rate, total compensation amount, years of practice, location of the lawyer's license, historical representation frequency in the court with jurisdiction over the case, number of cases currently being handled, response speed index, or remaining capacity. The matching parameters can be parameters such as the historical win rate for similar stocks, total compensation amount, years of practice, location of the lawyer's license, and historical representation frequency in the court with jurisdiction over the case. The lawyer information database can be derived from lawyer databases of local bar associations and the China Judgments Online website. The matching process in S52 can be a collaborative filtering algorithm or a Euclidean distance algorithm, which will not be elaborated further here. The push notification in S53 can be sent via an app, SMS, or mini-program. Further, as shown in the flowchart of step S6 provided in this application, step S6 includes: S61, refining the preset legal document template based on the claim case summary and the lawyers in the lawyer database; S62, performing real-name authentication and electronic signature on the user terminal and the lawyers in the lawyer database; S63, temporarily storing the payment made by the user terminal to a third-party payment platform; S64, allocating the payment made by the user terminal to the lawyers in the lawyer database according to the case outcome. Specifically, the legal document template includes structured documents such as a "Civil Complaint," a "Power of Attorney," and a "Contingency Fee Payment Agreement." Specifically, step S62 can be: guiding both the user terminal and the lawyer to access the Digital Certificate Authority (CA) interface to perform real-name verification (facial recognition + ID card comparison); applying electronic signatures to the documents using asymmetric encryption technology and simultaneously attaching a judicial timestamp; storing the signed documents in the cloud and optionally synchronizing them to a blockchain node to ensure the signing process has irrefutable legal effect.Specifically, the third-party payment platform can be Alipay, WeChat Pay, or a bank's fund supervision system, etc. Specifically, the steps for allocating the fees paid by the user terminal to the lawyers in the lawyer information database based on the case outcome can be as follows: upon receiving a payment notification that the execution payment has been received, according to the profit-sharing ratio stipulated in the "Contingency Fee Agreement" (e.g., 20%), the automatic disbursement function of the third-party payment platform is used to: automatically transfer the lawyer's service fee to the lawyer's account; automatically transfer the remaining compensation to the user's account; and automatically deduct the platform's technical service fee. A final electronic invoice is generated and the case is archived. As shown is a structural diagram of a securities claim automated processing device provided in this application. An automated securities claim processing device includes: a data access and authorization module 01, used to obtain server access permissions authorized by a user terminal through a preset encrypted communication protocol; a feature information retrieval module 02, used to preset securities feature keywords, perform a full scan of target data sources in the server using the securities feature keywords, and identify the original data containing the securities feature keywords; a structured parsing and cleaning module 03, used to analyze the original data, extract the core metadata of securities transactions from the original data, perform deduplication and standardization processing on the core metadata of securities transactions, and generate standard core metadata; and an automatic claim logic matching module 04, used to compare the standard core metadata with a securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claim case summary. The diagram below shows another automated securities claim processing device provided in this application. An automated securities claim processing device includes: a data access and authorization module 01, used to obtain server access permissions authorized by the user terminal through a preset encrypted communication protocol; a feature information retrieval module 02, used to preset securities feature keywords, perform a full scan of target data sources in the server using the securities feature keywords, and identify the original data containing the securities feature keywords; a structured parsing and cleaning module 03, used to analyze the original data, extract the core metadata of securities transactions from the original data, perform deduplication and standardization processing on the core metadata of securities transactions, and generate standard core metadata; an automatic claim logic matching module 04, used to compare the standard core metadata with a securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claim case summary; a legal resource matching module 05, used to compare the claim case summary with lawyers in a lawyer information database, identify the matching degree between the claim case summary and the lawyer, and select the most suitable lawyer resources; and a dispute resolution and payment module 06, used to establish an online agency agreement signing channel, in which the lawyer and the user terminal complete the agency procedures and payment.Specifically, the processing device can be at least one of a computer terminal, a smartphone terminal, or a tablet terminal (e.g., an iPad). The automated securities claim processing method operates on one or more of these devices by running software, a mini-program, or a webpage. Please refer to the schematic diagram of the data access and authorization module 01. It includes: an access unit 11 for initiating access requests and matching protocols; a verification unit 12 for authentication and verification; an authorization unit 13 for obtaining dynamic authorization tokens; a channel unit 14 for establishing an advanced encrypted transmission channel; and a monitoring unit 15 for controlled access and data flow monitoring. Further, the access unit 11 may also include: a receiving subunit 111 for the system to receive user-selected data source instructions; a matching subunit 112 for the system to automatically match communication protocols according to the data source type; and an initialization subunit 113 for initializing security parameters and preparing to establish an encrypted transmission tunnel. The data source types can be either a user terminal's connected email or a connected brokerage account. For example, if the data source is an email, it matches the IMAP / SSL protocol; if it's a brokerage account, it matches a RESTful API interface based on HTTPS. It's important to explain that IMAP stands for Internet Message Access Protocol. It's a protocol that allows email clients to retrieve email information from a mail server. Its characteristic is that emails are stored on the server, and the client only operates on a copy; your actions on the app (such as marking as read) are synchronized to the server and all devices. SSL: Secure Sockets Layer, now usually referring to its successor TLS (Transport Layer Security). Its role here is to encrypt the channel. HTTPS: Hypertext Transfer Protocol Secure. Essentially, it's HTTP (HTTP) with an additional layer of SSL / TLS encryption. This ensures that data sent from the mobile app to the server is encrypted. RESTful API: Representational State Transfer Application Programming. Interface (Application Programming Interface). It should be noted that encrypted transport tunnels generally use the TLS 1.3 standard. TLS 1.3 (Transport Layer Security version 1.3) is the latest standard in the field of network security, officially released by the IETF (Internet Engineering Task Force) in RFC 8446.In some embodiments, the executable process in verification unit 12 includes: performing a first verification on the user terminal, which may be an APP login password, facial recognition, or fingerprint recognition; performing a second verification on the user terminal, which may be sending an OTP (Dynamic Verification Code) to the user's bound mobile phone, or calling a TOTP (Time-Based One-Time Password) generated by the mobile phone hardware; only after the first and second verifications are completed will the system allow access to the authorization unit. In some embodiments, the executable process in authorization unit 13 includes: prompting the user terminal to the official authorization page of the third-party platform, and the user terminal completing login confirmation; the third-party platform returning a temporary Auth Code; the system backend using the Auth Code through the encrypted transmission tunnel to exchange for an Access Token and a Refresh Token from the third-party platform; furthermore, the system explicitly limits the Token's Scope to "only reading transaction-related emails / records," and refuses modification permissions. In some embodiments, the process executable by channel unit 14 may include: the system generating a session symmetric key using the DH (Diffie-Hellman) key exchange algorithm; enabling the 0-RTT (zero round-trip delay) feature of the TLS 1.3 protocol to improve handshake efficiency; and encapsulating the transmitted messages using the AEAD (Authenticated Encryption of Associated Data) algorithm family to ensure that the data cannot be eavesdropped on, tampered with, or replayed during transmission. In some embodiments, the process executable by monitoring unit may include: the system accessing the target interface with an Access Token (temporary token) and retrieving only specific data streams matching preset keywords (such as "account statement" or "transaction"); the system monitoring the validity period of the Token in real time, and automatically and silently updating it using a Refresh Token (permanent token) once it expires, or immediately forcibly invalidating the Token when an abnormal login is detected. In this embodiment, the system referred to herein is the carrier implementing the method in this application, which may be at least one of a webpage, a mini-program, or software. Please refer to the schematic diagram of the feature information retrieval module in this application. It includes: a full scan unit 21, used to perform a full scan of the target data source, retrieving only the metadata of the server authorized by the user terminal, and generating suspected metadata; a reading unit 22, used to read the title or attachment name of the suspected metadata; a secondary filtering unit 23, used to perform secondary filtering on the suspected metadata based on the title or attachment name; and a temporary storage unit 24, used to delete non-suspected metadata from the metadata and temporarily store the suspected metadata. In a specific embodiment, the metadata may only include email header information, excluding email body information.This process only matches emails whose sender domains belong to a pre-defined brokerage whitelist; or emails whose headers contain "account statement," "trade report," or "settlement card." This approach is primarily to ensure privacy by excluding the reading of personal emails from user terminals and avoiding the scraping of non-securities-related emails. Further filtering of suspected metadata involves using a lightweight Natural Language Processing (NLP) model to "determine intent" in the email content. The logic involves categorizing email content and mapping it to a specific label L (e.g., L∈{Securities Trading, Personal Privacy, Spam}). This labeling process categorizes suspected metadata. Additionally, Boolean logic operations, such as (Stocks OR Securities OR Bonds) AND (Trading Volume OR Commission OR Balance OR Frozen), are used to further filter suspected metadata. Furthermore, the layout of search tables or the presence of stock codes matching a 6-digit number can be used to further identify useful suspected metadata. For emails that do not match the securities characteristics, the system executes an "instant erase" instruction in the memory buffer. This ensures that data from non-target emails is not written to disk (i.e., not stored on the hard drive), and only the "scan count" is recorded in the system log, without recording any text information from non-target emails. This guarantees the protection of user terminal privacy. Please refer to the diagram below, which is a schematic diagram of the structured parsing and cleaning module in this application. It includes: a parsing and identification unit 31, used to parse the suspected metadata and identify the core table area in the suspected metadata; an atomic field unit 32, used to parse the core table area and parse it into atomic fields; and a packaging and packaging unit 33, used to generate unique feature values ​​for the atomic fields and package them. For suspected metadata, a coordinate-based heuristic algorithm or a deep learning table detection model (such as TableNet) is used to accurately locate the "table area" containing transaction details in the document. Here's an example of a coordinate-based heuristic algorithm: For instance, in most brokerage firms' standard account statement PDFs, the words "Stock Code" are usually fixed in the top left corner (x=100, y=50), with "Transaction Date" to its right. Define the search area: Based on these anchor points, delineate the area containing the data. For example, a rule could be: within a rectangle starting below the stock code title (x=100, y=70) and ending at (x=300, y=500), all horizontally arranged text blocks constitute the stock code list. Apply OCR (Optical Character Recognition) or DOM (Document Object Model) to map the text within the located area into atomic fields.Specifically, this step can be: Format recognition: Determine whether the user uploaded an image or HTML / PDF text. Region localization: If it's an image, use a deep learning table detection model to find the table region; if it's HTML, use a DOM parser to find the tags. Text extraction: If it's an image, use OCR to convert the image within the cells into text; if it's HTML, directly extract the text within the tags. Ultimately, the generated text tags in this text extraction process can be at least one of the following: stock name, stock code, transaction date, transaction time, transaction direction, securities account number, fund account number, transaction price, transaction quantity, total transaction amount, handling fee, stamp duty, and transfer fee. The packaging and encapsulation unit 33 can specifically perform the following steps: mapping non-standard names (such as "Ping An Bank") to standard codes through the backend securities master database; converting various forms of time (such as "23 / 05 / 12", "May 12, 2023, 14:30") to standard format (e.g., 2023-05-12 14:30:00); converting transaction quantities to "shares" (excluding the ambiguity of "lots"); and encapsulating the verified data as the data input source for subsequent steps. Please refer to the diagram below, which is a schematic diagram of the automatic matching module for claim logic in this application. It includes: a feature value retrieval unit 41, used to retrieve the latest securities violation risk database and retrieve the feature values; a comparison unit 42, used to compare the atomic fields with the securities violation risk database; a filtering unit 43, used to filter out user terminals that meet the claim criteria; a calculation and processing unit 44, used to calculate at least one of the user terminal's loss amount, success rate, and legal basis; and a generation unit 45, used to generate a claim case summary. The characteristic values ​​can be core legal nodes for each company involved, such as: Implementation Date: the date the false statement began; Disclosure Date: the date the violation was first publicly disclosed or investigated; Base Date: a reference date when market risk was fully released and stock price returned to normal. The specific steps for comparing the atomic fields with the securities violation risk database can be: comparing and analyzing the transactions contained in the atomic fields with the aforementioned Implementation Date, Disclosure Date, and Base Date to determine whether the transactions contained in the atomic fields meet the claim criteria. For example, only records where the purchase date is after the "Implementation Date" and before the "Disclosure Date," and the transaction was sold or continued to be held after the "Disclosure Date," are marked as "valid claim entries." The calculation method for the amount of loss includes: Investment difference loss: the difference between the average purchase price and the benchmark price / average selling price multiplied by the number of shares; Commission and stamp duty loss: transaction tax loss calculated proportionally; Systemic risk deduction: automatically calling the industry index volatility of the same period and using correlation analysis algorithms to isolate non-violation losses caused by market declines.The calculation method for the success rate includes: the system identifies the real-time status of the case corresponding to the stock (e.g., under investigation by the China Securities Regulatory Commission, already in the first instance by the court, existing successful precedents, etc.); based on historical judgment data and the solvency of the defendant company (e.g., balance sheet data), it calculates the estimated recovery rate and success probability score of the claim. The generation unit can perform the following steps: template-filling the above identification results, calculation data, and legal analysis; summarizing the total amount of claimable amount, summary of violations, warning of the time limit for rights protection (distance to the litigation deadline), and suggested operation process; generating a PDF format or interactive HTML briefing and pushing it to the user terminal. Please refer to the schematic diagram of the legal resource matching module in this application. It includes: a lawyer parameter retrieval module 51, used to retrieve the matching parameters of lawyers in the lawyer information database; a matching module 52, used to match the claim case briefing with the matching parameters; and a lawyer push module 53, used to push suitable lawyers from the lawyer information database to the user terminal. The matching parameters mentioned therein include at least one of the following: win rate, total compensation amount, years of practice, location of the lawyer's license, historical frequency of representation in the court with jurisdiction over the case, number of cases currently being handled, response speed index, or remaining capacity. These matching parameters can include historical win rates, total compensation amounts, years of practice, location of the lawyer's license, and historical frequency of representation in the court with jurisdiction over the case. The lawyer information database can be sourced from lawyer databases of local bar associations and the China Judgments Online website. The process executed by the matching module 52 can be a collaborative filtering algorithm or a Euclidean distance algorithm, which will not be elaborated further here. The lawyer push module 53 can push lawyers via APP, email, SMS, or mini-program. The diagram shown is a schematic of the dispute resolution and payment module provided in this application. The dispute resolution and payment module 06 includes: a legal document template improvement module 61, used to improve preset legal document templates based on the claim case briefing and lawyers in the lawyer information database; an electronic signature module 62, used to perform real-name authentication and electronic signatures on the user terminal and lawyers in the lawyer information database; a payment module 63, used to temporarily store the fees paid by the user terminal to a third-party payment platform; and a fee allocation module 64, used to allocate the fees paid by the user terminal to lawyers in the lawyer information database based on the case outcome. Specifically, the legal document templates include documents such as "Civil Complaint," "Power of Attorney," and "Contingency Fee Payment Agreement." Specifically, the electronic signature module 62 can perform the following steps: guiding both the user terminal and the lawyer to access the Digital Certificate Authority (CA) interface to perform real-name verification (facial recognition + ID card comparison); applying electronic signatures to the documents using asymmetric encryption technology and simultaneously attaching timestamps; storing the signed documents in the cloud and optionally synchronizing them to blockchain nodes to ensure the signing process has legal effect.Specifically, the third-party payment platform can be Alipay, WeChat Pay, or a bank's fund supervision system, etc. Specifically, the steps for allocating the fees paid by the user terminal to the lawyers in the lawyer information database based on the case outcome can be as follows: upon receiving a payment notification that the execution payment has been received, according to the profit-sharing ratio stipulated in the "Contingency Fee Agreement" (e.g., 20%), the automatic profit-sharing function of the third-party payment platform is used to: automatically transfer the lawyer's service fee to the lawyer's account; automatically transfer the remaining compensation to the user's account; and automatically deduct the platform's technical service fee. A final electronic invoice is generated and the case is archived. It should be noted that the server in this application that obtains authorized server access permissions to the user terminal through a preset encrypted communication protocol can be at least one of an email software server, a brokerage software server, an email web server, or a brokerage web server. This invention also provides a computer-readable storage medium storing computer instructions, which are used to cause a processor to execute and implement the aforementioned automated securities claim processing method. Since the device and readable medium in this invention employ the above method, their corresponding technical effects will not be elaborated here. The automated securities claim processing method provided in this application can directly locate email content related to securities claims on user terminals without processing other personal email content, thus protecting personal privacy. Secondly, the method provided in this application can efficiently acquire a large number of user terminals that need to file securities claims, improving the efficiency of claims processing. Furthermore, through online matching of lawyers and the participation of third-party payment software, trust is established and transactions are transparent between user terminals that need to file securities claims and lawyers. Finally, the automated securities claim processing method provided in this application is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made using the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for automating securities claims processing, characterized in that, Includes the following steps: Obtain server access permissions authorized by the user terminal through a preset encrypted communication protocol; Preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords; The original data is analyzed to extract the core metadata of securities trading. The core metadata of securities trading is deduplicated and standardized to generate standard core metadata. The standard core metadata is compared with the securities violation risk database to identify the securities violation risk database corresponding to the standard core metadata, and a claim case summary is generated.

2. The automated securities claim processing method as described in claim 1, characterized in that, It also includes the following steps: The claim case briefing is compared with the lawyers in the lawyer information database to identify the matching degree between the claim case briefing and the lawyers, and suitable lawyer resources are selected. An online power of attorney signing channel is established, through which the lawyer and the user terminal complete the power of attorney procedures and payment.

3. The automated securities claim processing method as described in claim 1, characterized in that, The step of obtaining server access permissions authorized by the user terminal through a preset encrypted communication protocol: The access request was initiated and the protocol was matched. Authentication and verification; Obtaining a dynamic authorization token; Establish advanced encrypted transmission channels; Controlled access and data flow monitoring.

4. The automated securities claim processing method as described in claim 1, characterized in that, The steps of using the preset securities feature keywords to perform a full scan of the target data source in the server and identify the original data containing the securities feature keywords include: A full scan of the target data source is performed, and only the metadata of the server authorized by the user terminal is retrieved to generate suspected metadata; Read the title or attachment name of the suspected metadata; Based on the title or the name of the attachment, the suspected metadata is further filtered; Delete the suspected metadata that is not in the metadata, and temporarily store the suspected metadata.

5. The automated securities claim processing method as described in claim 4, characterized in that, The steps of analyzing the raw data, extracting core metadata of securities trading from the raw data, and performing deduplication and standardization on the core metadata of securities trading to generate standard core metadata include: The suspected metadata is parsed to identify the core table area within it; The core table area is parsed and converted into atomic fields; A unique feature value is generated for the atomic field, and then it is encapsulated and packaged.

6. The automated securities claim processing method as described in claim 5, characterized in that, The steps of comparing the standard core metadata with the securities violation risk database, identifying the securities violation risk database corresponding to the standard core metadata, and generating a claim case summary include: Retrieve the latest securities violation risk database and retrieve the feature value; The atomic fields are compared with the securities violation risk database; Filter out the user terminals that meet the claims; Calculate at least one of the following for the user terminal: the amount of loss, the success rate, and the legal basis. Generate a briefing of the claim case.

7. The automated securities claim processing method as described in claim 2, characterized in that, The steps of comparing the claim case brief with lawyers in the lawyer database, identifying the match between the claim case brief and the lawyers, and selecting the most suitable lawyer resources include: Retrieve the matching parameters of the lawyers in the lawyer information database; The matching parameters mentioned are at least one of the following: success rate, total amount of compensation awarded, years of practice, location of the lawyer's license, historical frequency of representation in the court with jurisdiction over the case, number of cases in progress, response speed index, or remaining capacity. Match the claim case briefing with the matching parameters; The system pushes suitable lawyers from the lawyer information database to the user terminal.

8. The automated securities claim processing method as described in claim 7, characterized in that, The steps of establishing an online power of attorney signing channel, in which the lawyer and the user terminal complete the power of attorney procedures and payment in the online power of attorney signing channel, include: Based on the claim case briefing and the lawyers in the lawyer information database, improve the preset legal document template; Real-name authentication and electronic signatures are performed on the user terminal and the lawyers in the lawyer information database. The fees paid by the user terminal are temporarily stored in a third-party payment platform; Based on the outcome of the case, the fees paid by the user terminal will be allocated to the lawyer.

9. An automated securities claim processing device, characterized in that, include: The data access and authorization module is used to obtain server access permissions authorized by the user terminal through a preset encrypted communication protocol; The feature information retrieval module is used to preset securities feature keywords, use the securities feature keywords to perform a full scan of the target data source in the server, and identify the original data containing the securities feature keywords; The structured parsing and cleaning module is used to analyze the raw data, extract the core metadata of securities trading from the raw data, deduplicate and standardize the core metadata of securities trading, and generate standard core metadata. The claims logic is automatically matched to compare the standard core metadata with the securities violation risk database, identify the securities violation risk database corresponding to the standard core metadata, and generate a claims case summary.

10. The automated securities claim processing equipment as described in claim 9, characterized in that, Also includes: The legal resource matching module is used to compare the claim case briefs with lawyers in the lawyer information database, identify the matching degree between the claim case briefs and the lawyers, and select the most suitable lawyer resources. The dispute resolution and payment module is used to establish an online agency agreement signing channel, through which the lawyer and the user terminal complete the agency procedures and payment.

Images